It seems like I’m covering krikzz’s products a bunch now, with the Turbo EverDrive Pro and now this. But it’s not my fault he keeps making interesting things! Here, we see something particularly interesting: the RGB Blaster, an affordable device that promises Famicom users RGB video directly from the cartridge slot. How is this possible? How does it work? And I’ll say in advance, this one surprised me: things I expected to work didn’t, and things I didn’t expect to work did.

This post is not sponsored in any way, shape, or form. I paid full retail price for the items discussed in this post, and did not have any discussion with krikzz prior to publishing this post.

How?

Behold, the Ricoh 2C02. The Picture Processing Unit; a very capable video chip of its time, with multicolor sprites, scrolling tilemaps, a 54 color palette, and more. This produces all the unique look of Famicom and NES games that are still imitated to this day.

But one thing that the PPU can’t do, is output anything other than composite video. There are a few RGB variants Nintendo created for their arcade systems, but they have strange variations on the color palettes. (This was actually how Nintendo prevented arcade operators from just burning games themselves on pirate EPROMs) So how come there are so many RGB-modded NESes and Famicoms out there?

It turns out that the PPU has a secret up its sleeve. Four pins on the pinout, labeled EXT0-3. These are just grounded on the stock consoles, but it turns out that you can place the PPU in a special mode where it outputs the current color palette index over these pins. The RGB mods sit between the PPU and the console, and take advantage of this, listening to all palette writes, along with some extra trickery to distinguish sprites from backgrounds. The upside is, in an RGB-modded console, the stock PPU draws all the pixels.

You can’t take advantage of those EXT pins on a stock console, though. They’re grounded; putting them in output mode is probably not good for the PPU and could damage it. And even if you did that, they’re not output anywhere. The RGB Blaster, therefore, has to do something a little different.

Back when I discussed NES mappers, I noted that one thing that made them possible is that the PPU does not rely on internal video RAM, like the Sega Master System, ColecoVision, Super Nintendo, or almost every other console does. Instead, it actually exposes the video memory bus, and expects the cartridge to attach things to it. The pinout of the Famicom cart is quite large for an 8-bit system:

In theory, almost everything the PPU uses to draw the screen is done over this bus. The main exception are sprites (their memory is internal to the PPU); but we also have the CPU bus available, so you can also keep track of the writes to OAM memory. (Usually filled using DMA each frame)

And that’s how the RGB Blaster works. Note that compared to the internal mod case, the PPU has to be substantially reimplemented inside the Blaster’s FPGA. This is a much more difficult task. But you can still get a lot of information from the PPU fetches; this isn’t a fully emulated PPU. But it’s doing more work than the NESRGB.

The video is output using a Genesis 2-style connector. This seems to be rapidly becoming the standard for enthusiast RGB devices, as it’s easier to find cables for than the 8-pin Framemeister RGB port that was also popular. Personally, I’m starting to prefer the HD15 “VGA” port (the Axunworks Supergun Mini convinced me), but that may not have fit very well on such a slim device.

Note that the internals of the RGB Blaster don’t really give many details of how it works; all the magic is locked up in that FPGA. Everything else are just a few bus transceivers to handle the level shift, some analog parts, power regulators, and finally a reminder of why, while it sucks for hobbyists, the chip market is all-in on tiny surface-mount parts. Everything perfectly machine-soldered up until the through-hole video port, which require dirty human hands.

You’ll also see that this is revision B: the first round of RGB Blaster devices had a number of issues with the signals. I didn’t manage to get my hands on this until the second round– analog video is hard, so waiting for the revision was probably the best option. A digital output would’ve been nice, but it’s understandable that it’s missing, and honestly it’s not like I don’t have enough upscalers.

Let’s turn it on

So, I broke out my Sharp Twin Famicom. This is what started my interest in interesting retro machines, grossly overpaying for it at an anime convention long enough ago that I don’t actually want to count the numbers, lest I feel old.

So my first thought was to take advantage of this machine’s built-in Famicom Disk System. However, there turned out to be an insurmountable issue.

See, while I was hoping all the necessary signals would still be on the cartridge slot, what I missed is that the Twin Famicom is designed so that the cartridge slot and disk system can’t be used at the same time, physically. Normally a smart move, but now I’m afraid the game can’t be continued. Please press the Reset Button and try again.

And I did try again, but not with the Disk System. Here you can watch along me, my first view of the Famicom RGB Blaster. And what better game than Namco’s Star Wars. In case you’re curious, this Japanese cartridge isn’t the same game we got here in the United States.

The Twin Famicom, much like the Nintendo Entertainment System but unlike the original Famicom, has a built-in composite video output; mine is completely stock, unmodded beyond some scratches in the plastic. It looks pretty decent too. That shimmering on the vertically scrolling text is due to video capture and compression, so let’s look at some still shots.

That being said, there are some giveaways even in this simple example; most notably, look at the left side of the “R” in WARS; that sort of straight vertical line just isn’t well-suited to composite video. RGB, on the other hand:

Very crisp lines as we’d expect. The palette’s a little darker, but NES palettes are a rabbit hole I won’t be going into today. Namco Star Wars uses the Namcot 129 circuitboard, with 128kiB of PRG-ROM bank-switched in 8kiB chunks, 128kiB of CHR-ROM bankswitched in 1kiB chunks, and an IRQ counter; by 1987, Namco were masters of the PPU, even if their games rarely made it outside Japan.

The Namco 129 has expansion audio, but Star Wars doesn’t use it. But that doesn’t matter; the RGB Blaster grabs the audio from the cartridge edge connector, so expansion audio is naturally included. Don’t take my word for it– take the words of Moero! Pro Yakyuu, generated by an NEC µPD7756C ADPCM playback chip.

I was even able to reproduce glitches, such as the area above the status bar on the lower-left in Super Mario Bros 3. A nice thing here is that it’s perfectly safe to use the composite and RGB signals at the same time, since they’re generated via entirely different pathways and no signals are shared.

Bang bang

When you have analog video on the Nintendo Entertainment System, there’s one question everyone will be asking: can it play Duck Hunt? And, since this is a Famicom, and not a Nintendo Entertainment System, we get to use a real six-shooter. Well, er, a plastic one, obviously.

And here’s the thing. I did break out the Hogan’s Alley, my favorite light gun game for you all.

And I did get some hits! Which is good. But I played really badly generally, so I can’t really put this up as more than chance. (I did get more hits over RGB than over composite to compare) It turns out I’m really bad at lightgun games; they weren’t a part of my childhood like they were for a lot of people. Note that this screenshot is composite because the RGB was hooked up to my Trinitron at the time.

So, uh, can it play lightgun games? Maybe? Probably? It’s definitely good for streaming lightgun games, if you want to play on a composite CRT (still quite available, at least here) and give your viewers a nice crisp RGB picture to view on their LCDs at home.

Another thing to note is that Hogan’s Alley is one of the games krikzz mentions that you need to reset the console after booting up. It doesn’t quite wait long enough for the RGB Blaster before it starts writing to the PPU, so the Blaster misses data and can’t display a picture. I don’t consider this a big deal at all, but I guess it might bother some people. As far as I know every Famicom model this is compatible with has a reset button.

No audio?

The astute among you will note that the RGB Blaster has been mentioned on the blog before. Back in the expansion audio post, I noted:

It is theoretically possible for the cartridge to do something with the audio in pin other than mix in expansion audio; for example, it could generate DTMF tones and output them somewhere else, or use a cassette tape. As far as I know, this was never done during the lifetime of the NES– neither the Famicom Network System nor Family BASIC rely on the 2A03’s audio output. But there is something coming up that will– Krikzz’s RGB Blaster. This mod will break audio compatibility with that.

I’m still waiting on the Famicom robo-dialer. But this was in context of a mod I did on this particular Famicom:

Essentially, I cut the audio going from the console to the cartridge slot, so that audio would be mixed with nothing. This was done to keep the “stereo” effect done as part of the composite mod; it sends certain sound channels of the Famicom to either ear.

And now, if I use it with the RGB Blaster, Moero! Pro Yakyuu sounds a little like this:

Now you can only hear the expansion audio. This is pretty much never what you want on the Famicom. For me, though, this turns out not to be a problem at all. See, I’m using the Micomsoft Framemeister, and it has a setting to let you use the audio from external RCA jacks usually associated with composite video. So I can just use those. This isn’t just a Framemeister thing; settings like this are pretty common.

I don’t know if anyone actually copied my mod there; but if they did, hopefully this isn’t a problem for them all. It’s not one for me!

Audio caveats

So since we’re talking audio, let’s compare the audio coming out of the system to the audio coming out of the RGB Blaster. I’ve decided to go with the game Challenger, a basic NROM game for the Famicom which doesn’t use any expansion audio, and just routes the audio directly. I’ve basically decided to just start a level and then die. First off, here’s the Twin Famicom’s AV output.

And here’s Challenger over the RGB Blaster. Both of these were captured via the Micomsoft Framemeister and an Elgato Game Capture HD60S in Audacity.

One thing to note is that the AV Famicom’s signal is much quieter. I’ve normalized the audio here, though, so we can take a closer look at the shape of the waveforms. Twin Famicom AV on top, RGB Blaster on bottom:

The two are definitely from the same root source (the good old Ricoh 2A03, of course), but the Twin Famicom’s signal is significantly more rounded off. The Twin Famicom is known for having a different audio circuit than Nintendo’s consoles; you can even see mods online for making it a bit sharper. But much of this filtering occurs after the cartridge audio is mixed in, so it’s all bypassed with the RGB Blaster.

In general, audio filtering like this is a complex topic, especially on a console whose original variant was RF-only. Until MDFourier fully documents the Famicom’s audio, I think it’s best to just go with what sounds best to your particular ear. For fun, here’s my modded Famicom’s stereo output; it’s very similar to the RGB Blaster, as are most emulators.

Famicom Disk System

It didn’t work on the Twin, but on the regular Famicom it works fine. It looks pretty silly, but as long as you can shove it between the RAM pack and the console, the Famicom Disk System does work fine with the RGB Blaster. Just make sure you don’t touch the tower.

Nintendo Entertainment System games

So, why is this RGB Blaster released for the Famicom and not for the Nintendo Entertainment System? The same reason I mention in the expansion audio and Famicom Disk System audio; the NES didn’t have the audio pins on its cartridge slot. You could grab it from the RCA jacks on the back, but the toploader doesn’t have those, and it isn’t as all-in-one.

That being said, you can certainly play NES games on the Famicom, with a simple adapter that even provides audio. Well, they provide audio when plugged into a Famicom that doesn’t have as many mods as mine does, anyway. (See above)

But I noticed something interesting with this game, Rolling Thunder. Here it is in composite video:

And here it is with the RGB Blaster:

Resetting didn’t seem to help here, nor did reseating the cartridge. I found similar issues with Gauntlet played over the cartridge adapter. This version of Gauntlet is the Nintendo release, by the way, so it’s not Tengen’s fault.

Now this surprised me; I chose Rolling Thunder solely because I thought it would look good in a photograph; it’s a CHR-ROM / PRG-ROM game with a mapper pretty similar to the Namco one in Star Wars. (The Japanese release by Namco themselves uses the even more similar Namcot 163) Gauntlet surprised me less, due to its use of cartridge-side nametable expansion, but still, listening to the PPU bus, that should’ve worked fine.

Concerned, I decided to try a simple NROM game. This is the same cartridge I made back in 2020, so it is an NES one and needs to go through the adapter. Note that the sprite garbage at the top of the screen is supposed to be there, I designed the game for aggressive overscan.

The unlicensed AVE game Pyramid worked fine too. This game uses a pretty simple mapper that bankswitches PRG-ROM and CHR-ROM, but doesn’t do any RAM shenanigans.

The licensed MMC5 game Laser Invasion on the other hand, had a rough time. So it definitely seems to be limited to more sophisticated mappers.

I don’t actually have any of these games on Famicom. (I don’t think Gauntlet even got a release in the Famicom region; Pyramid did but I think it’s a porn game over there somehow?) But all of the games that are problematic on the RGB Blaster do work fine over my Everdrive N8 in the Famicom cartridge slot. As well they should, they’re both from krikzz.

So that’s a bit disappointing– but I took a closer look at the NES to FC adapter, and noticed something. This one is unmodified, which is why I didn’t test the PowerPak’s music capability, and this is the rear side.

The cartridge bridges the audio in and audio out pins, which isn’t surprising. It also bridges two other signals; CIRAM CE' and PPU A13'. CIRAM CE’ is the chip enable for the internal 2kiB of VRAM; this is active-low. PPU A13' is the inverted version of the 14th address line of the PPU address bus. So this is low when A13 is high; when the PPU is looking at the region above 0x2000. This is the normal behavior of an NES game; it means that the internal memory is used for the nametables. Because they’re bridged, the nametable RAM is always active. But some games, like, say, Gauntlet and Laser Invasion, don’t want this.

So this could be resulting in bus conflicts when I play Gauntlet or Laser Invasion, which I suppose could result in the PPU seeing different values than the RGB Blaster; bus conflicts are often weird and should definitely be avoided. I don’t quite understand why this would cause issues with Rolling Thunder, though. The RAMBO-1 pinout seems to imply CIRAM CE' isn’t touched, and you can see the two pins connected on the PCB:

So that’s an odd one. I can’t find anything else on the NES to FC adapter I’m using that looks weird, but nevertheless, Rolling Thunder refuses to roll. It’s possible my converter is dodgy, or that this could be fixed with a firmware update in the future. It’s definitely an odd one; it seems like the RGB Blaster is unable to even determine where the top of the screen is.

Silly time

So far we learned that the RGB Blaster works great with the Everdrive and very well with Famicom games, but could potentially have some issues with NES ones, especially if you have a dodgy region converter.

Now let’s go with something that I don’t expect to work at all:

The RetroUSB AVS doesn’t have any need for this, with its digital video output. Plus, as I saw when running Family BASIC, it’s timing is subtly different than the stock system. The RGB Blaster is so timing-sensitive that it doesn’t even work well on some PPU variants (which I don’t have).

Oh! Well then– it took a few reboots, but that is a surprise.

The Framemeister doesn’t like the signal one bit and is only displaying one frame per every few seconds, but my Trinitron was perfectly happy with the signal with juyst some minor curling. Note that there’s no audio; I assume the AVS does a similar trick as my mod to capture cartridge audio, as when playing Moero! Pro Yakyuu I only hear the sampled sounds like in the video above.

Rolling Thunder through the adapter chain still doesn’t work, though. Hey, I couldn’t not try.

One last thing to note is that you can’t see the menu with no cartridge inserted. I’m guessing it’s just not outputting any signals over the cartridge PPU bus, but it does still output power, so you just get a blank screen.

All of this was, however, just for fun. Just use the HDMI output on the AVS.

Put it in a box

All of this blog post was written with the original case; a sandwich of standoffs and a few PCBs etched with graphics rather than chip routes. It’s perfectly fine and worked without issue, but it can be a little shaky. For those of you who want something a little more sturdy, Humble Bazooka has a case for you.

I’m pretty impressed with this; it’s 3D printed, but feels very solid. And with it installed, the RGB Blaster doesn’t move at all; it’s just as solid as any other cartridge. The fingers on either side of the connector also help with the cartridge’s stability.

Blasting off again

You might see this device used for future Famicom image captures to give a nicer picture while being closer to real hardware. Overall, I think the RGB Blaster is pretty great, even if it doesn’t quite hit it out of the park.

It does have its weaknesses, though– much like the Turbo EverDrive PRO, it makes tradeoffs for ease of use. Unlike the Turbo EverDrive PRO, though, the experience isn’t really compromised at all– when it works, it’s great. When it doesn’t work, it’s not playable at all, though sometimes you can at least see the title screen.

In general, I’m also very excited to see krikzz dipping his toes into the bottomless well that is video output. Curious what we’ll see next!

Sometimes people ask me: “Nicole, how do you convert a Master System game to the NES?”, or some other combination of game consoles. And the answer is invariably the same: there is no way to do so without rewriting the game from scratch. 8-bit games are almost always written in assembly, and also take advantage of the platform-specific features. For you to be able to do this, the two platforms would have to be near-identical to begin with. And the best example, the exception that proves the rule: the Sega Master System and the Sega Game Gear. Thanks to Bob from RetroRGB for the post idea.

Easy Mode

The Sega Game Gear is very similar to the Master System. Let’s take a totally arbitrary game: OutRun Europa. How do I port this game from the Game Gear to the Master System?

Rename it.

See, as far as OutRun Europa is concerned, the Game Gear isn’t just similar to the Master System. It’s the same console. The Game Gear has a mode where it is literally a Master System, and OutRun Europa, as well as anything using a MasterGear Converter, runs in it.

In fact, in many emulators, OutRun Europa won’t run correctly unless you run the game in Master System mode. Take, for example, the byuu/ares v115 emulator: (Newer versions may have fixed this; I tend to use this version because it’s my fork where I support the SuperGrafx CD from a menu option)

These emulators only emulate the Game Gear mode when you choose a Game Gear game; otherwise, you need to load the ROM in Master System mode. And to be totally, honest, that’s not so different from the hardware. Nothing in the ROM tells the Game Gear whether it’s running a Master System game or not.

Take a look at the pinout of the Game Gear cartridge.

Notice in particular pin 42, on the top right, labeled GG. To be consistent with other usages on this blog, you might call it GG'. When this pin is low (0V), the Game Gear will act as a Game Gear. But when the pin is high (tied to +5V), it acts as a Master System. If you look at the circuitboard, you can actually see a jumper point that differs based on games running in Game Gear mode (Sonic the Hedgehog 2, for example) and Master System mode.

Mode this, mode that

Now, of course, I’m playing a game here– the Sega Genesis does the same thing. Phantasy Star Fukkokuban, which has made many appearances on this blog, triggers a pin on the Genesis cartridge connector to enter Master System mode. And nobody would say this makes porting a real Genesis game to the Master System possible.

And the reason for that is that Genesis mode (“Mode 5”, in developer parlance) adds quite a few things:

• A whole new graphics mode
• Additional palettes (all 9-bit RGB vs 6-bit RGB)
• Extra VRAM
• Extra work RAM
• A new sound chip
• A new CPU!

So what does “Game Gear” mode do?

• Lower resolution output (160x144 vs 256x192/256x224/256x240)
• More colorful palettes (12-bit RGB vs 6-bit RGB), but still the same number
• User-defined colors in SG-1000 modes
• Start button is a button and read like one; on the Master System, the pause button is an interrupt to the CPU
• Stereo sound capability (albiet quite limited)

So quite unlike the Genesis in Genesis mode, the Game Gear in Game Gear mode has:

• The same CPU as the Master System, at the same clock
• The same amount of RAM as the Master System
• The same amount of VRAM as the Master System
• The same sound chip as the Master System
• The same graphics modes as the Master System 2 VDP– just zoomed in

So really, the main thing that the Master System absolutely can’t do are the more colorful palettes, and the SG-1000 mode differences. And nobody uses the SG-1000 modes.

Visible area

It’s worth noting that the higher resolution isn’t always a good thing, though. Take this version of Phantasy Star Gaiden, converted to Master System by the dedicated programmer BcnAbel76.

See, the Game Gear has a 160x144 resolution, but internally, it’s still rendering a full screen size. In fact, the sprites-per-scanline limit even applies to sprites in the full screen area, and you can even use the extra-height SMS2-only modes! But it will only show the middle of the screen. On the Master System, you see the whole thing.

This is fine for games that were developed or ported from the Master System. But a developer making a game that would only ever be on the Game Gear, like Phantasy Star Gaiden, often is only going to care about the part of the screen that’s visible. So things can get pretty wonky if you can see the whole area.

I’ll do it myself!

So, what does it take to port a game? Let’s find out! I’ve chosen what I’m hoping will be a simple enough target: Namco’s Ms. Pac-Man.

I’m choosing this game as a target for a few reasons:

1. It’s a tiny game (1 megabit) compared to others in the library
2. It didn’t appear on Master System– the Master System got an (imo, better) Tengen-designed port
3. It isn’t already on the SMS Power list (However, look out for spoilers later)

So my first step was to disassemble it, which I did using the Emulicious emulator, which has a pretty advanced disassembler built into its debugger. You probably want to play through the game a bit to make sure the code/data logger can figure out what’s code and what is data.

The disassembly can be configured, in this case I went with WLA-DX, so it also created a linkfile. I recommend getting very familiar with your assembler’s build pipeline because they can be finicky. Still, I went through and got what looked like the same game output. You can run it in your Master System emulator if you want:

I don’t recommend it, though. Right now there are two huge issues blocking playability.

1. The palettes are wrong.
2. The Master System doesn’t have a start button, so you can’t start the game.

Disassembly

Disassembled code can be pretty obnoxious to read:

_LABEL_1A2_:
  push bc
  push de
  push hl
  push ix
  push iy
  di
  in a, (Port_VDPStatus)
  ld hl, _RAM_C02B_
  bit 0, (hl)
  jr nz, +
  jp _LABEL_20D_

This is part of the interrupt routine, and Emulicious is nice enough to let us know what port is being used– Port_VDPStatus is a little more obvious than $bf. But overall, it can’t tell most things, so it just gives default labels like _LABEL_1A2_. You can rename them as you go to make things cleaner.

Start Button

The start button is part of IO port $00 on the Game Gear. This port does not exist on the Master System, so any reads from it need to be changed.

If we search our decompilation for in a, we find only one place where a port that isn’t Port_VDPStatus, Port_VDPData, or Port_VCounter is read. Unfortunately, it’s using in a,(c), which allows the use of an arbitrary port using the c register. So we have to actually read the logic.

_LABEL_6033_:
  ld ix, _RAM_C02D_
  ld iy, _DATA_6055_
  ld b, $03
-:
  ld c, (iy+0)
  in a, (c)
  cpl
  ld c, a
  xor (ix+3)
  and c
  ld (ix+0), a
  ld (ix+3), c
  inc ix
  inc iy
  djnz -
  ret

; Data from 6055 to 6057 (3 bytes)
_DATA_6055_:
.db $DC $DD $00

So what’s going on here? First, a RAM address is loaded into ix. A ROM address is loaded into iy, and a loop is done going three times, using djnz to count using the b register. The IO ports come from iy. $dc and $dd are the joystick ports on both the Master System and Game Gear, so $00 is definitely the input port.

This is the code we’re looking for. So what does it do? The cpl is there because the bits are reversed for the joystick buttons– 0 means a button is pressed, 1 means it isn’t– but the developer wanted it to work the other way around.

You often want to know if a button has been newly pressed, but don’t care if a button is just being held down. That’s what the rest of this routine, the xor and the and, does.

  ld c, (iy+0) ; Load c with the IO port
  in a, (c)    ; Pull the IO port data into A
  cpl          ; Flip all bits in A (1 -> 0, 0 -> 1)
  ld c, a      ; Store a in c for later
  xor (ix+3)   ; Take the XOR with the last value
  and c        ; Only select the bits that are active
               ; This gives us the buttons that have
               ; changed since the last update.
  ld (ix+0), a ; Store the changed buttons in RAM
  ld (ix+3), c ; Store the full pressed buttons too
  inc ix       ; Continue the loop
  inc iy
  djnz -

Many conversions of Game Gear to Master System games will let you use the down arrow direction on the second player controller as a start button. That might seem weird, but looking at this code, it makes sense.

You see, the start button is bit 7 of port $00. The player 2 down arrow is bit 7 of port $dc. In this case, it’d be a one-byte change.

But let’s say I don’t want to rely on bit 7 of port $dc. I rarely even have a player 2 controller plugged in, because I have no friends left willing to play Master System with me. So let’s see if we can find where the start button is actually read.

ix, our RAM address, is set to $c02d at first. But because it’s the last value in in the loop, the data for port $00 is being stored in RAM addresses $c02f for the changed buttons, and $c032 for the raw data. Our disassembly has generated a label _RAM_C02F_, so that’s probably the easiest place to look.

It turns out it’s used in quite a few places, but in every single one, it’s followed by a bit 7,a.

  ld a, (_RAM_C02F_)
  bit 7, a

So let’s change that to use _RAM_C02D_ and bit 4, a. This will use player 1 button 1 instead. Notice that I’m just replacing it everywhere; I’m not bothering to check which one is our title screen. This will also allow you to pause by pressing button 1; in some games that might be an issue, but this is Ms. Pac-Man, a game that doesn’t require in-game button presses, so it’s a feature.

And now, we can get into the game!

If we wanted to release this as Ms. Pac-Man Techno Night Edition, I guess we could be done. But instead, let’s get to palettes.

Palettes

Palettes are stored in Color RAM, frequently called CRAM. Color RAM accesses are distinguished only by the top two bits of the second write to $bf being set. Given the layers of indirection, this could get complicated. (Color RAM is also distinguished from VRAM in that the processor can’t read it, only write to it.)

On the Game Gear, it’s a bit more complex (you can only write a full 16-bit, or actually 12-bit, palette entry at once), but the general sense is that color RAM is twice as big: a palette entry is one byte on the Master System, two on the Game Gear.

Palettes in the Master System and Game Gear are done through the VDP data port, $be. This is definitely bothersome, because it means we’ll need to understand what’s happening around the situation, we can’t just look for a dedicated port– the same port is used for sending graphics to VRAM. And Ms. Pac-Man uses the VDP data port a lot, as will, well, any Sega 8-bit game really.

I used Emulicious again to set a “watchpoint” on the first byte of the CRAM.

By the time the Sega screen loaded, the following events had already shown up:

ROM01:6073: PALETTES Watchpoint hit: Writing 00 to 0
ROM00:01F4: PALETTES Watchpoint hit: Writing 00 to 0
ROM00:01F4: PALETTES Watchpoint hit: Writing 00 to 0
ROM00:01F4: PALETTES Watchpoint hit: Writing 00 to 0...

With the bottom line repeating each frame.

Let’s take a look at what’s at 0x6073. In our disassembly, this is part of _LABEL_6069_.

_LABEL_6069_:
  xor a
  out (Port_VDPAddress), a
  ld a, $C0
  out (Port_VDPAddress), a
  xor a
  ld b, $40
-:
  out (Port_VDPData), a
  djnz -
  ret

In Z80, xor a is a slightly more efficient way of doing ld a,0; it does an XOR of the a register with itself, which always gives 0. So all this is doing is clearing color RAM. Since color RAM is half the size, we might as well change ld b, $40 to ld b, $20, but other than that there’s not really anything to change here. This seems to be an initialization function.

The second part, at 0x01f4, is deep in the interrupt routine. This is running on every frame.

  xor a ; ld a,0
  out (Port_VDPAddress), a
  ld a, $C0 ; set the top 2 bits high: color RAM write
  out (Port_VDPAddress), a
  ld b, $40
  ld hl, _RAM_C040_
  ld c, Port_VDPData
  otir

Here’s a common Master System/Game Gear programming technique. There’s a block of RAM, here 0xc040, which is being used as a “mirror” of the palette. The game logic can change the palette whenever it wants as easily as changing RAM, and it’s updated at each frame.

It’s potentially safe to assume this is where all future palette changes will happen, since it’ll run in the interrupt routine and would overwrite any other attempts at changing it. (However, be careful of anywhere disabling interrupts!)

A Game Gear palette entry is two bytes: ggggrrrr 0000bbbb A Master System palette is one byte: 00bbggrr. So there’s a problem: converting these won’t be easy. With the controls, we managed to replace all the code that needed to change in-place. Now, we’re going to need more space in the ROM.

When I’ve been assembling this ROM in WLA-DX, the link output has always ended with:

-------------------------------------------------
---                 SUMMARY                   ---
-------------------------------------------------
ROM: 0 bytes (0.00%) free of total 131072.
RAM: No .RAMSECTIONs were found, no information about RAM.

Having zero bytes free of ROM is very concerning, because it makes things hard to patch. Thankfully, this is actually because the disassembler is very thorough. After all, who knows if a part of the ROM filled with $00 is used as empty tiles in graphics? These groups of repeating $00 are denoted with the .dsb directive. This just means to fill a certain number of bytes.

One section is see is at $007f. This is ideal because it’s in the same bank (I don’t want to talk about bankswitching in this post!), and the _DATA_7F_ doesn’t appear to be referenced anywhere.

; Data from 7F to FF (129 bytes)
_DATA_7F_:
.dsb 129, $00

_LABEL_100_:

So first, let’s remove that .dsb statement. I use an orga to keep the alignment; while you’d hope a disassembly wouldn’t require everything to be at the same address, it often does due to various code shenanigans.

; Data from 7F to FF (129 bytes)
_DATA_7F_:
;.dsb 129, $00

.orga $100
_LABEL_100_:

As for our function, the folks at the SMS Power forums have written a routine which you can see in the attached thread, by user vingazole. It’s mostly a lot of bit-shifting; we’ll only keep the highest (“most significant”) bits. Losing some color information is inevitable here– but hey, could you really make out that 12-bit color on the original Game Gear’s screen anyway?

Make sure to also add an orga on the block immediately after the interrupt routine so you don’t shift everything. Forgetting that will break things; ask me how I know. But if you get it right, you get: Ms. Pac-Man.

Just play the Tengen version

After all, this is just an example project anyway. But nevertheless, I’d feel like a fool if I didn’t show you it running on REAL HARDWARE: my French SMS2. Surely there’ll be no surprises.

Why did it stall? Why is it not doing anything?

Well, in this case it’s my fault for not using Emulicious– both byuu/ares and MEKA don’t handle the correct emulation here that would’ve caught the bug right away. See, I forgot one more hardware difference: the stereo sound. How do you add stereo sound to a system that only has a mono output? The Game Gear adds an additional IO port at $06. And our game’s music code writes to it.

But why does it crash the entire game?

On the Master System, Charles MacDonald’s documentation signifies that writes to even addressses between $00-$3f go to the memory control register. The memory control register, by the way, has the capability to among other things, disable the cartridge slot or the system RAM. Why does it crash when a game starts? The game crashes as soon as it tries to play sound.

This register is really only for the BIOS to use; there’s no real reason a game would ever need to disable the cartridge it’s running off of. Therefore, it’s understandable that some emulators don’t actually emulate it properly.

In any case, let’s comment that out, and remember to .orga the next data table so we don’t lose our offsets.

So you might wonder, will I post a download link? Well, I was going to, but it turns out people on the SMS Power forums already did, they just hadn’t posted it on the site yet. And their version is better than mine, as they do some more adjustments– go check out this post from user Stokes. Sorry about that!

Another option

So, of course, the big downside here is that to play a Sega Game Gear game on your Master System, you have to do the following:

1. Dump the game
2. Reverse engineer it if someone hasn’t already
3. Get a flashcart

What if there was a device that could do all of this for you? Of course, that’d be impossible and

This converter comes courtesy of Apocalypse. If you saw Bob from RetroRGB’s video on the topic, rest assured that this is the same device– I mean literally the same device, thank you to Bob for sending it my way.

The only real difference between the manual conversion I just did and the automatic conversion is that my conversion remapped the buttons, whereas this cartridge is not so smart, and simply always maps the pause button to the start button on the port $00. Therefore, if you’re going to use this adapter, make sure you’re sitting near your console. (The switch on the side is for the region bits that are also on $00, and are almost never used on the Game Gear)

The colors are converted automatically, but that’s not a huge deal, since the adapter is almost certainly doing the same thing as the code I grabbed– just taking the most significant bit. There’s not much reason to do anything else. I was asked not to reverse-engineer the adapter, though, so I can’t give you all the juicy details. Only fair to respect the effort Apocalypse put into this thing.

Sonic The Hedgehog 2

Early Game Gear games were often ports or worked on alongside Master System games, and therefore they tend to work pretty well in a conversion. Indeed, I ended up being surprised at even small differences, like this offscreen wall in Sonic the Hedgehog 2, which as the Master System version shows, isn’t there in reality.

In general, Sonic the Hedgehog 2 has very little reason to play the Game Gear version this way. I guess the level select cheat is a little easier since it doesn’t require a second controller.

Psychic World

Psychic World is a port of an MSX game, and honestly, the Sega Master System version would make you think it was a port of an MSX1 game, with its weird red sprites. (It wasn’t; it was actually a port of an MSX2 game) I guess it’s just really easy to get a sunburn in the psychic world.

Interestingly, the Game Gear version is a pretty large improvement graphically, and even with the palette downscale, that comes across with the adapter pretty well. Unfortunately, the rewrite also means that you get the screen garbage. Still, for this game it starts to make a bit more sense that you might want to play the Game Gear version.

Of course, in this case the version you want to play is most definitely the ROM hack; it’s a case where the hackers have gone out of their way to remove most of the screen garbage, giving you the best of both worlds.

NBA Jam Tournament Edition

Finally, a Game Gear game that isn’t available on the Master System at all, though its non-tournament predecessor almost got a release on the long black slab. Honestly I like the bright high-contrast colors here, though it would be nice if half of each team weren’t covered in the gray pallor of the dead.

An interesting thing about running this game on the adapter is that the garbage on the formerly-invisible area isn’t just garbage. While the Acclaim logo is displayed, it’s actually a secret message from Iguana Entertainment UK developer Chris Kirby.

It’s a human connection.

Mortal Kombat

The big downside of an all-purpose adapter like this is that it can’t convert everything automatically; if it fails to intercept palette changes, things might not work out very well.

What I find interesting here is that Mortal Kombat also made it to the Master System in Europe and Brazil. And look at the broken sides of the HUD on the Game Gear and compare it to the Master System. It looks to me like this game was done on the Game Gear first and ported to the Master System second.

Of course, a look at the tiny title screen logo could’ve told you that.

The GG Shinobi

This game is not a port of the Master System Shinobi! It is, unfortunately, another case where the palette decoding didn’t quite work. In this case, the entire second palette (the one used by sprites) is never loaded for some reason.

However, I find it interesting how much of this game does work without issue. See, The GG Shinobi is a 1991 Game Gear game, early in the console’s life– but unlike many Game Gear games, this one never got a port to the Master System, and I wondered if this adapter would reveal a game heavily restricted to the Game Gear screen area. Perhaps between Shinobi, The Cyber Shinobi, The Secret of Shinobi, and Alex Kidd in Shinobi World, Sega just figured Master System owners were Shinobi‘d out.

X-Men

The last game here. And let’s change things up– for all other games, I’ve been using that same French SMS2 with RGB out and a cable with a big box on it. Here, I’ll use an NTSC American Master System 1. Unfortunately, this adapter doesn’t work on the Japanese Master System or the Power Base Converter.

Woah! Why’s the logo all broken? Let’s try it on the Sega Master System 2.

Notice the title screen logo rises from behind the titular X-Men. The Game Gear and the Master System only have one background tile layer, so the logo is made up of sprites. Because you can only have 64 sprite pixels on a scanline, the developers of this game used the rarely-used zoomed sprite feature to make it work. This feature makes all sprites double-size; it applies to all sprites on screen.

Unfortunately, as I noted when talking about Earthworm Jim in my Master System writeup, these zoomed sprites are buggy on the first iteration of the console. On the Game Gear, though, they always work.

There’s an excellent manual port of this game that cleans up much of the garbage and even adds support for the start button on a Genesis controller. But if you run it on a Genesis, even the best ROM hackers can’t re-add features that are missing from the silicon. The Genesis doesn’t have zoomed sprite mode at all, rather than the buggy version on the Sega Master System VDP1.

Thankfully, this is a rarely used feature.

Oh yeah, and on the subject of system variants, you can also use this adapter or the manual ports to play Master System games in 50Hz mode. While this often does work, it’s worth noting that even in Europe, the Game Gear is always 60Hz. So games aren’t likely to try to do any adjustment at all for the speed change.

That is, unless their Master System versions did and nobody bothered to delete the code; like the case of Sonic the Hedgehog 2, which does in fact compensate in its music logic.

Master Gear

Was Sega right to reuse their Master System hardware for the Game Gear? Well, given the Game Gear’s tendency to eat batteries, that might not be true– but then again, much of that can be attributed to the color screen and backlight. We’re not here to question Sega’s decisions anyway. After all, the game

If nothing else, this little adapter gave me a good excuse to start getting Game Gear games again. And, having spent all this time, I wonder if it’s worth going the other way, porting my ongoing Master System game to the Game Gear; or just make Game Gear users use a Master Gear Converter. I think I’ll give that a try once the initial Master System version is released. But that’s a story for another post.

This is going to be a bit out there for Nicole Express, but I have to let you all know the truth. A terrible truth that only I, Nicole Express, could have discovered. A dark secret that shows that everything the ever-ominous they have told us about our world and our place in it is a lie. A truth that, yes, can be revealed only through 1980’s arcade boards. Maybe it’s not so out of place for this blog after all.

Introduction

Today we confront our greatest fears, and with any luck, will come away from it stronger and greater than before. For today, we meet… Mr. Do. The arcade machine that proves it’s all wrong. After all, whether he’s eating, throwing, or crushing, Mr. Do is always very active. “Mr Do” in Jewish Gematria matches “I am an Imbecile”. As an imbecile myself, I obviously had to dig in to learn more.

According to the supposed history, Mr. Do was released in 1982 by Universal. But this isn’t the Universal we all know and love for revealing the plans to resurrect the dinosaurs. Oh no, this is a much more sinister Universal… whose modern entity, Universal Entertainment, is the same company that when known as Aruze is responsible for the death of SNK’s original incarnation.

And yet the one whose quest we must understand today goes further than that. You see, Mr. Do’s first game was released in 1982– this is questionable, as we’ll see, but the sequence of events is the same. After releasing several more Mr. Do games, though, Universal was forced to flee the video game industry entirely in 1985. By 2005, they had been corrupted enough to merge with Aruze. What did you do, Mr. Do?

The circuit board

Before we can look upon the acts of evil itself, we must first look at its source: the Mr. Do PCB. It is here where the reality of what this board represents, what it means, starts to show up.

The Mr. Do board connects to its cabinet using an edge connector that looks suspiciously like JAMMA. But JAMMA came out in 1985. Suspicious, that… The edge connector, of course, is not JAMMA at all, and in fact, requires an adapter that includes audio amplification. The bulk of the board is discrete logic, with resistor ladders that are presumably for the video DAC, as they’re labeled R, G, and B.

A quadrant of the board is left unpopulated. While this is normal on arcade boards, where capabilities not needed by a particular game were often just left off (why pay for the extra parts?), one can’t help but look upon this particular game having this characteristic as being a bit off. It’s unfinished, and as such, doesn’t it remind you of the unfinished pyramid on the back of the Great Seal of the United States?

New world order or not, the capabilities of this board are quite impressive. For example, look at this full-screen particle effect, shown across three frames. This is possible because the Mr. Do board can layer multiple tilemaps.

What kind of sinister CPU would power such a board?

The Zilog Z80

Think about it. The Mr. Do board uses a Z80 chip. Doing some research on the Z80, I learned some things that definitely weren’t taught in my elementary school:

• The Z80 was created by Zilog and hit the market in 1976
• The lead designer, Frederico Faggin, was formerly at Intel and created the first microprocessor, the 4004
• The Zilog Z80 is a software-compatible extension and enhancement of the Intel 8080 and, like it, was mainly aimed at embedded systems.
• It was also common in military applications, musical equipment such as synthesizers (like the Roland Jupiter-8), and coin operated arcade games of the late 1970s and early 1980s, including Pac-Man.

In fact, they didn’t teach anything about the Z80 at all in my elementary school! They didn’t teach about the 6502 either, admittedly, but at least we had an Apple ][_plus, which is pretty much a 6502 education in and of itself. Even if it’s just to give the kindergarteners something to play Number Munchers on and not to care so much if they break it. Kids are kids, after all, and I did go to elementary school in the 1990’s.

Speaking of children, and most shockingly of all, Zilog still makes the Z80. It’s even still used in products sold to students. Ask yourself: who benefits from your children getting indoctrinated by this dangerous processor? And are they to blame for the fall of the Austro-Hungarian Empire?!

So to summarize, whenever you see a Z80 CPU, you should assume something’s up. But we’ll need to look at Mr. Man’s dossier later. Back to Mr. Do.

Gameplay

Mr. Do appears to be a simple single-screen game like the good old-fashioned American game Dig Dug. But one thing we see in its gameplay echoes the Georgia Guidestones. Mr. Do wishes to help us bring about the New World Order. It does this by presenting the three ways you can beat a level.

The first is by killing all the enemies, either with Mr. Do’s ball, or with apples. Apples are, of course, the very same fruit that in the Book of Genesis (if you use a Latin pun, anyway) led to the fall of Adam and Eve. This lets us know that this way of finishing a level represents feudalism, when Europe was at its most religious, and was governed by those who were strongest in war.

Notice that this is the only way to complete a level in Dig Dug. The implications are clear– Universal mocks their freedom-loving competition by calling them old-fashioned and feudalist.

The second way to complete a level is to collect all of the cherries. Collecting all the items in a maze is the only way to beat a level in Pac-Man, and the analogy to consumption is clear. This represents capitalism.

Finally, the superior method is presented: collecting all the letters E-X-T-R-A, by defeating the correct enemies. (The enemies, as it were, of the People) This awards you with an extra Mr. Do, and therefore represents communism, since Mr. Do, with his capability for Action (“doing”), obviously represents the New Soviet Man.

Notice that Mr. Do co-exists with a dinosaur here. Yet in their history books, they tell us that dinosaurs went extinct 65 million years ago, but the classic clown makeup design only began being developed at the beginning of the 1800s. This could never happen… unless the earth is much younger than we thought. And of course, Mr. Do’s world is a flat plane…

If you believe the history books, America at the time of Mr. Do’s release was in a cold war, dominated by capitalist forces like President Reagan, who would never have allowed such obvious communist propaganda to spread throughout American arcades. This means, obviously, that history has been falsified and the 1980s never happened. The earth is much younger than we thought.

The proof

Once all the enemies have spread throughout the map, they leave behind a cake. Taking this cake (the vanguard party) causes Mr. Do to take the “red pill”. The enemies he thought he knew stopped, and new enemies (consuming ghosts, a reference to Pac-Man and therefore capitalism, and one of the EXTRA letters) appear. The world turns red; Mr. Do is taking humanity down the path to hell.

But you might ask yourself, how could Mr. Do, a game from 1982, reference The Matrix, a move from 1999? It’s completely impossible. But yet… Both the Wachowski sisters, who directed and wrote The Matrix, later came out as transgender. It’s often believed that the “red pill” is a reference to premarin, a drug used in female replacement hormone therapy in the 1990s.

And now we look at Neo Mr. Do, the sequel to Mr. Do, released for the Neo Geo in 1997. (Remember, Aruze-Universal would later destroy SNK to prevent this secret from getting out) In this game, there is a powerup that is a pink circle over a cross. Clearly, this is a reference to the ancient Egyptian Ankh, a symbol of life. It’s also visible in Ultima Exodus, which much like The Matrix, features an evil supercomputer.

Collecting the Ankh transforms Mr. Do… into Mrs. Do. Well, Ms. Do, since I don’t think our titular clown’s marital status is confirmed in the game.

Do I need any more proof that our history has been falsified? Mr. Do is a clown. The purpose of a clown is to make the people laugh and tell jokes. But now the joke is on us. Why would they do this? They know that we could easily find this all out, they left the clues right there, yet Mr. Do smiles instead.

And if the 1980s never happened where did the Z80 come from? It’s enough to make you say

The video is titled "Veterinary Technician Training: Handling a Fractious Cat."

After several viewings, it occurs to me that they mean "cat" as in "hepcat."