Set Side B

Nicole Express on Twin Famicom Compatibility with Guardic Gaiden

Nicole Express is so knowledgable. How many blog posts have you seen about an obscure hardware issue, itself with obscure hardware, and the Japanese version of one specific cult game? Which the writer tested herself with her own unit and cartridge? Then went in to investigate herself with a freaking multimeter? Whaaa?

I won’t keep you waiting for the link: here it is. And here is my grossly simplified summary, intended to inspire you to go to the original article, if you have the time, and get all the deets.

Guardic Gaiden, known in the US as The Guardian Legend, uses a weird trick to put its status bar at the bottom of the screen, instead of, as usually seen in an UNROM game, at the top. To create a fixed status window requires stopping whatever the processor is doing at a very precise time while the display is being drawn to the TV, and then changing some PPU registers to display the status.

More complex and versatile mappers, like the MMC family, have the ability to trigger interrupts at specific screen lines, but Guardic Gaiden/Guardian Legend doesn’t use an MMC. It doesn’t even have a raster line counter, so the game simply doesn’t know where on screen the raster beam is drawing.

There are still lots of games on the system that have status windows, even with MMC chips. The PPU has a built-in feature called Sprite 0 Hit, where the chip can signal when Sprite 0 (of the system’s 64 sprites) is being drawn on top of non-transparent background data. So what older games commonly do is put Sprite 0 in an unobtrusive place at the bottom of the status window at the top of the screen. When the Sprite 0 Hit register indicates a collision, the code knows it’s time to set up the PPU to display the main portion of the game screen.

There is a really big problem with this setup, though. Sprite 0 Hit doesn’t trigger an interrupt. It doesn’t stop the code to let it switch the graphics. It’s not even proper to say it “sends a signal.” It’s up to the code to check if Sprite 0 Hit has been triggered. If it has, then it’s time to set the scroll register to the right place, and maybe switch to the proper background tileset, and do whatever else needs to happen, and the code can then be off to run essential game logic, the actual game part of the game.

If it hasn’t… then, the code has to check again, and immediately. And if it hasn’t triggered then, to do it again. It has to literally check as quickly as it can, because if it delays in its check, the game screen might not get set up at the right moment, which will be perceptible as the bar straying down one extra line that one frame. Not the end of the world, but it looks glitchy. And this code will be running every frame, so if it strays down once, it might do it again, which is a more perceptible glitchiness.

Sprite 0 is set to trigger its hit at the top of the screen, because the code won’t have to spin its wheels checking the hit over and over. It wastes time, but not that much. This is why UNROM games put their status lines, with the score, timer, health bar and life counters, at the top of the screen.

Well, The Guardian Legend is an UNROM game, and maybe because creators Compile wanted to show off, they decided they’d put the bar at the bottom of the screen. And yet, their game doesn’t waste most of each frame just in maintaining the status bar.

How? And what does that have to do with the Twin Famicom? For that I’m going to direct you to Nicole Express’ blog post. May you find it as fascinating as I did!

Nicole Express: Is the Twin Famicom Flawed? The Case of Guardic Gaiden

rodneylives

NESHacker’s Guide to the NES Hardware

More and more I find I should do a blog search to make sure that I haven’t posted something before, and my search for this video didn’t find it. It did find our link to the Copetti Site’s discussion of various console architectures, and a separate link specifically to their explication of the SNES’ construction, but not this particular video from NESHacker, so it’s fair game. Post! (zoop)

It’s only about nine minutes long so you can guess that it doesn’t go into deep detail. Essentially the NES is split into two parts, the CPU and its memory, and the PPU graphics chip and its own memory. A lot of classic consoles and microcomputers had to take special measures to support their display, which often ended up being the most complex part of the unit. Think about it: you have what amounts to a deluxe broadcast character generator right there in a box on your desk, shelf or floor, with lots of extra bells and whistles besides. (In fact, home computers were often used to generate current events channels for local cable companies, and an Amiga was essentially the basis for the old Prevue Guide channel.) It’s like a tiny special-purpose, single-receiver TV station just for your own use.

Graphics hardware is extremely timing sensitive. It has to generate the signal for your TV to display according to standardized picture generation requirements, so special requirements are often necessary. In the Commodore 64, for instance, the VIC-II graphics chip has the power to actually put the 6510 CPU to sleep, so it can have unrestricted access to the computer’s memory, without fear of bus conflicts, when it’s needed. This reduces the overall speed of the processor by a bit, and it’s why C64s turn off the screen when loading programs from cassette tape, in order to keep the CPU timing consistent relative to the data being streamed in off the tape.

The NES gets around this by giving the PPU RAM and address bus for its own exclusive use, and to put stuff in it the CPU has to use the PPU as an intermediary. And what’s more the NES exposes both the CPU and PPU’s address busses through the cartridge connector (which is why it’s got so many pins), allowing carts to supply dedicated ROM and RAM to both chips.

Even though it’s just a high-level overview, I found it a worthwhile use of those nine minutes, and you may very well enjoy it too.

NES Hardware Explained (from NESHacker, on Youtube, 9 minutes)

rodneylives

Displaced Gamers on Mega Man 3 Glitches

A bit of scanline flickering is a fairly common problem on the NES. Even Super Mario Bros. 3 had it, and that game was made by Nintendo themselves.

Game graphics in the 8- and 16-bit ages often came down to tricky hardware manipulation. The art of doing raster effects, changing the registers in the video hardware so as to divide the screen into different sections, ultimately comes down to timing. On the Atari VCS/2600, nearly all the graphics had to be done that way, but it was still a useful technique for over a decade after that.

A lot depends on the specifics of the video chip, a custom-built piece of silicon developed for the express purpose of taking graphics defined in memory and folding it, like electronic origami, into a shape that the TV would perceive as a broadcast signal. At that time, while it might still have been possible with clever coding, CPUs weren’t nearly fast enough to do that job themselves and still produce acceptable graphic quality and run game logic. (If you want to see what it would be like, I refer readers interested in doing it the very hard way to the amazing Freespin demo, which runs on a 1541 disk drive, and no video hardware at all.)

Older NES games used a supported bit of hackery called the “Sprite 0 Hit,” a signal the PPU would send at the moment the first of the system’s 64 sprites began to be drawn. By watching for it, games could do rudimentary raster effects on a system not designed for them. The issue there was processor time: the Sprite 0 Hit feature wasn’t hooked up to an interrupt line, so the program had to continually watch for it, checking a memory location repetitively over and over until it changed. Some games spent large portions of their runtime in a tight loop checking for the Sprite 0 Hit. Since, from the program’s perspective, the signal might come at any time, the loop needed to be tight, meaning the game couldn’t spend that time doing other work or else it might be delayed in responding to the extremely time-sensitive signal.

The MMC3 mapper had a special function though that could time out when a programmable scanline was reached, and send the processor an interrupt request at that time, greatly freeing up the processor for doing other things with that time. But not all programmers understood the best way to use it, which is why Mega Man 3 has some scanline glitching in a couple of very visible places, in the pause window and on the level select screen.

Displaced Gamers’ Behind the Code series, which we’ve linked to multiple times in the past, has done an exposé looking into how Mega Man III’s glitches happen (28 minutes), and even wrote some code that erases all trace of them. As usual for Behind the Code, the explanation is fairly technical, especially of the fix, but the first half of it is fairly comprehensible. No one says you have to watch the whole thing. Or, indeed, any of it, but I always enjoy them!

rodneylives

What is a Game Dad?

I refer you to the question in the title. It’s not GamerDad, or The Game Dad Blog, or Board Gamer Dad, or Video Gaming Dad, or the Youtube channel GameDad. It’s a GameDad, as opposed to a GameBoy.

A Game Dad is a frankly awesome idea! It’s any portable, pocket-sized game-playing device that has a focus on emulation. I myself would say it needs physical controls, not a touchscreen, to control well, but that’s not part of the “official” spec given by Dan over at gamedad.club. It looks like site owner Dan agrees with me to an extent.

Game Dad is not a brand name. No company yet calls their device a Game Dad, it’s more an adjective that you can apply to things. Two special cases: A Steam Deck is not a Game Dad because it’s not pocket-sized. A smartphone is not a Game Dad because it’s not dedicated to playing games. Game Dads shouldn’t be something you do work on, or will pester you while you play. Game Dads don’t host apps. Game Dads don’t try to feel you algorithmic bullshit. Most Game Dads, when you turn them off, they don’t go to sleep. They turn off.

The picture here, from the site’s header, might help to fix the idea in your head. Notice that unlike a Gameboy it has four buttons and dual analog sticks, but it otherwise looks a lot like a Gameboy.

Lots of companies make Game Dads, or Game Dad-adjacent devices, and you should be able to get a pretty good one for around $70. That will typically get you something capable of playing up to PS1-era games. N64 games are a little more challenging since its processor was weirder. But as the site says, the best Game Dad is the one that plays the games you want to play. Dan’s site is full of advice and opinions, and all of them are good. The one he has personally is an Anbernic RG353V/RG353VS. Both run Linux, but the V version also has an Android partition and a touchscreen, two features that Dan considers inessential to Gamular Dadiness, and lowers the price by $20 to about $78, but the more expensive one also has more RAM and built-in storage, if those things matter.

Please ignore that the page says that it “let you fondle admiringly,” the device is not emotionally needy.

At this moment a lot of the interest in retro gaming circles is in FPGA devices like the Analogue Pocket, which will be more expensive than this. This isn’t a device for complete cycle-accurate recreations, it’s for inexpensive, pretty-nice emulation for good-enough gaming fun.

By the way, Dan is on Mastodon as @ifixcoinops@retro.social. Yes, I’m still using Mastodon. You should too! I’m on Bluesky because I feel like I have to be, but I’m on Mastodon because I want to be.

gamedad.club

rodneylives

Doing Weird Things To A Sega 32X

The Youtuber: MattKC Bytes
What he did: Unexpected things to Sega’s aborted Genesis/Mega Drive add-on.
The address: here.
The length: about seven minutes.

The explanation: Did you ever play around with a 32X? Evidently not a lot of people did. It was straaaange. Unexpectedly powerful! A bit misjudged! Hosted a port of DOOM! Had a port of Virtua Racing that compares favorably with the Saturn version! Had that crazy hard-to-play Knuckles game that gave us Vector the Crocodile!

Have you ever hooked one up though? Its hardware is odd. It’s like a completely separate console to itself. The Mega Drive wasn’t made to support add-on processors and chips like that, so Sega used a clever solution: the 32X has its own video output, and also a video input. You plug the Genesis’ output into the 32X, and then the 32X into your TV. The 32X mixes the Genesis’ signal into its own, as if it were chromakeyed. Since the 32X cartridge supplies the program running on the Genesis as well as itself and they can talk to each other, the two processors and graphics chips should be able to sync perfectly, if awkwardly.

But: because the Genesis’ video signal emerges from that console through this external wire before reentering the 32X, it’s possible to do things to it while in transit. The Genesis supplies video timing information that the 32X relies on, so you can’t get a signal from the add-on without the Genesis’ AV plugged into it, but the Genesis does produce a viewable video signal that you can see on its own.

All the details are in the video, which has been embedded below for your convenience and amusement.

rodneylives

Excellent Breakdown of Wii Music Capabilities

By that title, I don’t mean the capabilities of the Wii title called Wii Music*. The video below, from Dublincalif, is about the properties of the Wii’s sound system itself. It’s 24 minutes, but pretty interesting for all that, and it’s presented really well. It’s a model explainer video, and a great first effort in that style from its maker!

You might think that all the music on the Wii is just streamed, either from audio tracks or files, but it isn’t. The Wii has fairly little NAND storage, and music is a major consumer of storage space, so a lot of its music is sequenced, essentially MIDI files played with sample banks, with optional effects added. The video is a great overview of its features and capabilities.

* Of random interest: Wii Music’s data is amazingly small! Of that 4.7GB DVD it resides on, it uses less than 10 MB!

The Wii’s Music Is A Bit Complicated (Youtube, 24 minutes)

rodneylives

Youtube Series: Inside the Famicom

It’s only two episodes in, but this series from the Youtube channel What’s Ken Making is already really interesting, with episodes averaging at around 16 minutes each. The first part is titled “The Design of a Legend,” which doesn’t really grab me much, but the second is about the main processor, “The 6502 CPU,” which Ken admits near the start isn’t exactly accurate. The Famicom/NES’s processor isn’t precisely a MOS 6502; it’s a Ricoh 2A03 in NTSC territories, and a 2A07 in others. The 2A03 is licensed from MOS, but lacks the original’s Binary-Coded Decimal mode, and includes the Famicom/NES’s sound hardware on-die.

Episode 1 (15 minutes):

Episode 2 (17 minutes):

That removed BCD feature. Why? The video notes that the circuits are right there within the chip, but have been disabled by having five necessary traces severed. The video notes that the 6502’s BCD functionality was actually patented by MOS, and asks, was the feature disabled because of patent issues? Was Ricoh trying to avoid paying royalties?

rodneylives

Sharopolis Looks Into NES Technical Feats

Youtuber Sharopolis has a 20-minute video up examining several specific NES games and how some unexpected tricks were pulled off in each: Rescue: The Embassy Mission, Crash and the Boys Street Challenge, Castlevania III and Jurassic Park. I love learning about how developers overcame hardware limitations, and if you’re reading this, I’d wager there’s a good chance you do too!

rodneylives

How Speedrunners Get N64 Control Sticks

The Nintendo 64 broke ground for Nintendo in many ways, but arguably the worst part of that was the controller.

I’m not one of the people who complains about not understanding the controller or how to hold it. That part’s pretty easy to understand: you hold it one way, with the central prong in your left hand and the right handle in your right, for games that use the control stick like Super Mario 64; you hold it with one handle in each hand for games that instead use the Control Pad. It makes sense that Nintendo still wanted to feature the Pad prominently since it was one of the defining characteristics of the NES and SNES era.

The Control Pad is durable and easy to use, even if it does result in bruised thumbs when pressed with force, as can happen in challenging games. What’s not so durable is the N64’s signature control device: the Analog Stick. A special design that didn’t see much update after the Nintendo 64, because of the “white dust of death,” a mysterious fine powder that emerges from the inner workings of the stick after heavy use. Along with the powder always came degraded control performance: the stick would lose some of its tight feel, wobbling when shaken, and would no longer recognize the full extend of its range. All official N64 control sticks would succumb to the dreaded dust with time.

During the console’s life the source of the powder wasn’t common knowledge. It turns out it’s the result of the control stick grinding against its housing and actually rubbing itself in a fine dust. The looseness came from the powder getting into the tight confines of the stick’s mechanism, and from the pivot chamber getting looser as it was ground away by the joystick.

Some games were notorious for decreasing a controller’s working life. The Mario Party series was infamous for demanding rapid spins of the control stick, that could produce the dreaded dust and wobble after surprisingly few games. But with use, it seemed that all the official joysticks would succumb to it eventually. Third-party sticks, such as the then-ubiquitious MadCatz sticks, didn’t suffer from the problem, but their control sticks weren’t as sensitive, and required a smidge more force to push. For demanding play, the official sticks are a must.

This has resulted in a big problem. Since all the Nintendo-made N64 sticks degrade eventually with use, and Nintendo isn’t making them any more, speedrunners playing on original hardware have few options for playing games the way they were intended by their designers. Some jealously hoard pristine sticks, which have become expensive, while others work to make replacements.

Retromeister on Youtube has made a 24-minute video explaining the problem, and the lengths to which runners have resorted to keep themselves playing. And this, following, is that very thing:

rodneylives

A Guided Tour of the NES

This tab has been open on my browser for literally months, so I’m finally excising it from the bar….

A while back the site HackADay did a teardown of the NES, going through how to take it apart and reassemble it, and going through some of the elements of its assembly. It doesn’t go into a lot of detail, but that lets it be fairly short, at only nine minutes.

NES Hardware Explained (HackADay post, Youtube video)

rodneylives

The Lost Sound Code of Sinistar

Sinistar was a game that had quite an impressive sound design. It borrowed a bunch of its sound effects from earlier Williams games, with which it shared common hardware that was originally design for pinball machines. A cockpit version of Sinistar, of which only around 200 units were made, was the first arcade game to have stereo sound. And of course all versions of the game have the Sinistar’s famous digitized threats and taunts.

While Sinistar’s main program source code was found and made available on Github, the source of the code that drove its sound hardware has long been lost. Youtube user SynaMax has done the best he could at recreating that code, and has made a video talking about the process, the sound design of Sinistar and other early Williams games, and even found unused sounds in the code.

Contained within the code is the revelation that the sound chip that drove the rear speakers in the cockpit version ran slightly different code than contained within the main sound ROM. The data from that version of the game was only dumped this year, meaning that the game running in MAME was somewhat incorrect.

Now that the right version of the chip has been dumped, the cockpit version of Sinistar now sounds properly in MAME. Although this does mean that users running up-to-date MAME have to refresh their romset for this version of the game. Such are the tradeoffs of MAME emulation.

Another revelation of the video was that the parametric sound generators used by Williams arcade games from that time often produced interesting noises if it was fed with random data. Sound programmers sought out different sets of numbers to give them, including by asking passers-by for numbers off the top of their heads and garbage values found in RAM when dev systems were powered up, in order to produce strange sound effects.

Devs using more recent parametric generators like bfxr, LabChrip, ChipTone, sfxia, rFXGen, wafxr and jfxr can produce noises by similar means using those programs’ Mutate or Randomize buttons!

I feel like I should warn however, near the end of the video is mention of a bit of drama concerning the MAME developers, in getting code supporting the change integrated into the software. I’m not weighing in on this, not the least reason being I don’t know enough about it. But I feel like you should know it’s coming, ahead of time, before embarking on the 51-minute journey.

Rescuing the Lost Code and Stereo Sound to Sinistar (Youtube, 51 minutes)

rodneylives