The last romance

The first game in the Idol Mahjong series was actually 1988’s Idol Mahjong Housoukyoku, but all the rest of the games in the series followed the lead of this 1991 title: Idol Mahjong Final Romance.

The goal of this game is simple; you have dates with eight different women. And you’re going to play strip mahjong with all of them, as you do. No elaborate Nichibutsu-style plotline here, though it’s also worth noting that unlike Jaleco’s Mahjong Daireikai, you also don’t get a choice of which girl to play against, you always go through them in the same order.

Idol Mahjong Final Romance has a lot of aesthetic, and a lot of it disappears in later games in the series. This guy who runs the item shop that appears between stages, for example, is replaced with a maid– in fact, I’m not sure you ever see a man in the Final Romance series again. (Is that what makes it final?) The way the item shops work, though, is about the same.

When you’re presented with a girl, you get various graphics to set the scene, along with sampled voice at a very low bitrate.

And then, of course, what you do is play the riichi variant of mahjong, with far fewer points than you should have, with the goal of winning three rounds with a girl so she will become sufficiently unclothed. I went over the basics in my first strip mahjong post earlier this year.

A nice thing about this game is that every coin, even the first one, will start you with enough money to buy the item that lets you do a redraw on your initial hand, and even better, you can choose whether to use it or not after seeing the initial draw. This can be pretty useful if you get an awful hand to start with.

This game is definitely more mahjong-centric than Nichibutsu’s; notice the girl doesn’t even show up during the matches, whereas in Mahjong Koi no Magic Potion the picture of the girl dominated the screen, to the point of hiding the opponents tiles. Keep your eyes on the game! And the AI player can do calls like chii and pon, so look out.

I have to say, I really like the rotoscoped actual pictures approach to these games. Let’s put a pin in that, and instead just note how the animations are also very low frame rate. Every once in a while, you might be able to get a strange state for a single frame.

Hardware

The Idol Mahjong Final Romance PCB is exactly standard for contemporary Video System mahjong games of the late 1980’s and early 1990’s. How much so? Here’s my Final Romance, PCB code VS-Z80-7, next to my copy of Mahjong Daiyogen, PCB code VS-Z80-6. Pretty much the only real difference I see is that less of the board is populated.

So, what does this PCB get you? Well, it gets you an audio circuit with a YM2413 (the same syntehsizer used on the Master System FM add-on) and a OKI MSM5205 ADPCM chip for sample playback. It gets you two 6MHz Z80 CPUs. This is all pretty typical so far. (Someone broke off the corner of this PCB, I see)

The audio circuit is somewhat questionable. This is the sort of thing you’d never bother emulating, but there’s a constant buzz. In this clip from the attract mode with attract mode audio disabled, you can really hear how it interacts with sound effects, which is kind of interesting.

Interestingly, the master CPU has no direct access to the audio circuit or the video circuit. Instead, only the sub CPU has access to that. The master CPU, however, gets the VBlank interrupt and reads the controllers. It’s an interesting division of work, and makes me wonder if the master CPU spends most of its time running the mahjong engine. Note that the other mahjong titles I’ve looked at either used a more powerful 68000 CPU, or in Nichibutsu’s case, scaled back the mahjong engine, removing features like the opponent calling.

The video circuit is almost entirely made up of discrete logic, with the exception of one component, the V-System GGA (Graphics Gate Array?). This chip is seen not only in other mahjong boards, but a whole host of non-mahjong games like Pipe Dream and Welltris. My understanding is it primarily provides some timing assistance in a similar way to the Motorola 6845, but don’t quote me on that one.

Interestingly, the GGA on Final Romance is marked 06.5 while the one on Daiyogen is marked 9N.4. I did not bother to try swapping them, because they’re soldered in and have a high pin density.

Tilemaps

The V-System hardware used in this game features two tilemaps, with scrolling capabilities and colors in 5-bit RGB palettes, 16 colors per tile. That’s perfectly fine for the era, though an interesting quirk is that the tiles are 8x4, unlike the almost universal 8x8. I’m not aware of anyone other than V-System using 8x4 tiles, though Commodore 64 multicolor characters are 4x8.

The interesting thing here is that this is all the hardware has. Now, that’s not unheard of in mahjong– Mahjong Dairekai only had tilemaps. But it had four of them. Why does that matter? Think of it this way: the only way for things to move on screen in increments of less than a tile is to put them on their own scrolling layer, or waste a bunch of tile ROM.

In practice, not very much moves in Idol Mahjong Final Romance. No hands over the tiles, tiles just jump into place, and the main way you see anything move is a full-screen call that puts the text over the screen. And that’s where I say this feels a bit like a slideshow.

This is especially true when paired with another choice made. When tilemaps are loaded in, the palette is blacked out, and then the palette is only loaded in afterwards. This is presumably to prevent you from seeing some kind of partial abomination. What’s interesting is that this is done in phases and blocks; so, for example, when a girl loads in, she fades in in separate parts, the body palette and the face palette take turns on each cycle. It’s subtle, but creates an effect.

Overall, in this case the hardware just gives the game kind of a unique “after-dark” feel. Console ports of strip mahjong games were extremely rare (though not non-existent) at the time, but without the slideshow feel and the audio buzz I think it’d actually lose something.

Pictures

So I wanted to end this by saying a bit about the direction the Idol Mahjong Final Romance series went. The sequel, Taisen Idol Mahjong Final Romance 2, came out in 1995. The “Taisen” refers to the fact that the arcade release allowed two cabinets to be connected, allowing actual two-player mahjong (since, of course, you have to stop your opponent from seeing your screen). We’ll ignore that because I don’t have any friends, or two arcade cabinets. In fact, I’ll be playing the Neo Geo CD port, over composite video because I don’t feel like pulling the SCART cable out of its setup. It is making me wonder if the old CDZ needs some recapping, though.

The gameplay in the single-player mode is pretty much the same as ever. You don’t get to choose your girl, but go through a set order. The item shop works the same way, as does the actual mahjong. You’ll see some pointers here rather than letters, but that’s just because this is a home version running with a controller– I do not have a Neo Geo Mahjong controller, and I doubt that’ll change.

The big difference, though, is that all the artwork of the girls is no longer the rotoscoped photograph look, but instead are anime-style.

This is a general shift that happened in this period, and I’m not exactly sure why. It might just be because of the increased popularity of anime, and in particular, hentai pornographic art. Children who had grown up watching anime were now older teenagers and young adults, and were a larger audience than the old mahjong base.

However, Atwiki claims that it was a rights issue, that using actual models became increasingly complicated as they gained additional rights to their portraits. And, as I noted in the intro, Idol Mahjong Final Romance 2-R-4 Special, the modern re-release, didn’t bother throwing in the original. I mean, otherwise how hard could it be to include? But these are all theories; unless we get an interview with someone from Video System at the time, I doubt we’ll ever know.

Talking Brick Game

At least the fundraiser sprung for the fancy “talking” model. This is a pretty typical model, though I don’t see any year on it, even though I do have the packaging.

Notice that it mentions that there are no repeats, and that it’s talking. Therefore I don’t think this is the original “brick game”. However, this one does seem to predate the one we can see on Wikipedia, which promises 576-in-1, and features an “up” button.

Another oddity about the box. Take a look at the screen. Notice that it has square blocks with a square inside, and a number of icons. Now compare it to the real thing.

Now notice on the real thing. The block have spades inside each of them, and the sidebar segments are different too, with an odd child. I don’t really think anything of it, but it is odd.

So, what is the Talking Brick Game 118-in-1? Well, the packaging promises all sorts of games:

Does it talk for real? Oh, you bet. I can’t understand what it’s saying, though.

And it does boot up to a select screen. All of these have a particularly annoying select screen– you don’t scroll through the games using the directional keys as directions. Instead, look at the secondary labels. “Level” increments the level. “Speed” increments the game speed. And “Mode” increments the game type (a letter). “Rotate/Direction” increments the game subtype (a number underneath the letter). You can only increment, but they loop. In this case, the game types go from A to E. The game subtypes vary based on the game.

But there is one game in particular whose name doesn’t appear, but is basically the primary reason for the console: Tetris. Why do I say that? Well, I mean, come on. It even plays Korobeiniki when you choose one of the Tetris-like games.

That’s not to say the other games aren’t real; there are driving games, where your giant pixelated car moves back and forth, and that’s even game “A”. In fact, that’s only game “A”.

Every other game is a Tetris clone with some variant. For example, pieces may fall occasionally that are just one block. These variants are mostly annoying. Honestly, though, it’s hard to state just how big Tetris was at the time. It’s still one of the most addicting games ever made, but it was even more popular then, in an era before Candy Crush on everyone’s phones. (I guess we’re in the era after that now)

What’s inside

What’s inside the Talking Brick Game? Well, there’s an incredibly thin PCB behind the screen with an epoxy blob, the infamous “chip-on-board” packaging that makes it so much harder to understand what’s happening. Underneath this is the die.

And there’s a PCB behind the buttons. The buttons are individual pieces of hard plastic, with rubber contacts underneath. Extremely typical for handheld gaming consoles.

Really, the most interesting thing is the little capacitor that does some filtering of the audio, and the transistor that does… something. Unfortunately, handheld games are pretty integrated. The brick games in MAME mention using CPUs from the “Holtek HT1130” 4-bit microcontroller family, but I don’t see 118-in-1 there.

Did I say 2000’s?

Now, here’s where things get fun: the Brick Game is still around. You can buy brand new ones, usually for less than $10.

Now, the differences are subtle, but they add up to show that this actually doesn’t have much in common with the older counterpart.

• The screen is larger
• The big center hump has been moved slightly to compensate
• The whole thing is slightly thinner
• The controls are now made entirely of a single piece of rubber; they’re moved closer together to compensate
• There’s an up button and a reset button
• The rear speaker is moved from behind the controls to behind the screen
• The battery compartment has the option for a screw to hold the cover in place (not used, on mine)

All in all, while you can definitely recognize the design heritage, none of the plastic could actually be the same molds as before. Also, even though I ordered this new, there was no box or any real packaging beyond a plastic bag. (What can you expect, for such a low price?)

However, if they just reused the same box design, at least the pixels would actually be a box inside of a box. However, they’re not square! Even brick games aren’t free of the scourge of non-square pixels. And yeah, the screen is indeed noticeably worse in person too.

9999-in-1

You might notice the other thing: we’re no longer being modest and limiting ourselves to 118-in-1. Oh no; we’re all the way at 9999-in-1, which for those of you unfamiliar, just means “a lot of games”. And the music is different too; no more Pac-Man music here. (Korobeiniki is also gone, even though I thought that was public domain)

We’ll confirm once we crack this thing open, but hearing the audio I’m pretty sure they cut that filtering capacitor out of the circuit. This thing has decades of cost-shaving.

The menu’s also different. The controls are no longer labeled, and while they’re similar, they’re still different– the “ROTATE” button now rotates through the game types, and they’re numbered, not lettered. I’m not sure why; there’s only 23 game types, so they could’ve kept the letters.

The racing game is no longer game A, and you can see it’s been completely reimplemented, with a smaller car, and you dodge other cars rather than walls. While Tetris is clearly still the main attraction here and covers the vast majority of the game types, there are some more non-Tetris games, including Breakout.

Possibly the most interesting is game 9, where you drive a tank around the screen, you do indeed need to use the “up” button to move your tank, well, up. So that explains the extra button. These differences add up to enough that I think this is a reimplementation of the Brick Game, without shared code– probably a different microcontroller core. Of course, we haven’t even opened it yet, and we already know we’ll just find a blob.

Crack it open

The inside surprised me. Not only is it completely different from the older model, it combines the controls and LCD connection on a single PCB. But what really blew my mind is the other side.

First off, let’s appreciate that perfectly round, shiny epoxy blob. So much nicer than the older matte misshapen one. They must have a tool for doing this. But the bigger surprise to me was the date: 2025.10.27. So this isn’t something they have a big vault of that they’re just selling off gradually; they’re making new ones of these these, and they’re constantly improving them, as recently as less than a year ago.

Also, like, yes, their English is nearly infinitely better than my Chinese, which consists mostly of me trying to recognize characters I know from Japanese, but I have to call out the “NO/OFF” label. I have to. Surely you understand.

Bricks

So that’s all that I can really say about the Brick Game. I had one of these when I was younger, so it really surprises me that they’re still around, but I guess it makes sense? Tetris is the near-perfect game, and there’s still a lot of children in the world who aren’t going to have easy access to anything else to play games on. In that situation, this is a lot better than nothing.

Not so mighty now, are you

Mighty Bomb Jack, the most iconic bomb-collection platform taking place in a pyramid for the Nintendo Entertainment System. The title screen here, like a lot of title screens, is entirely static. But here, I’m using my composite-modded system, which just amplifies the video signal coming right off of the PPU, and the picture is wobbly.

And you might be tempted to say, now wait a second Nicole, this is composite video. You wrote a whole post on it! Composite video is inferior to other signals because it’s basically a form of video signal compression. And that’s true; but there’s no reason a composite frame should differ from frame to frame, is there? Here’s my beautiful Apple ][ running Shanghai (as referenced in a recent post).

That’s incredibly static!

Explanation Attempt 1: Interference

Interference isn’t actually as big of a problem as you’d expect. It’s probably something you’re thinking about, but interference would generally present as a random pattern, not the cyclic noise seen on the NES screenshot. In fact, the Apple video was captured using a much longer cable, being strewn over my desk where several electronics were running, and you can actually see some noise in the white parts of the image. But it’s noise; it’s uncorrelated to the input signal.

This is the letter “B” from Mighty Bomb Jack above, cropped from the raw capture. Notice the repeating jagged pattern on the left side of the letter “B” where the white meets the blue of the sky. If this was just signal interference from outside, there’d be no reason to expect it to follow the images that closely.

Explanation Attempt 2: The colorburst

If we divide the colorburst frequency of ~3.57 MHz by the NTSC linerate of 15.734kHz, we get a near-exact 227.5. That’s no coincidence; RCA deliberately aimed to have the color carrier a half-integer multiple of the linerate. That’s because if one scanline is similar to the next line, it’ll be a signal with a frequency similar to the linerate. It’s very rare, on the other hand, for the television signal to have components that are a half-integer multiple; so this makes it easier to filter out the color signal. I talked about this a bit in my 2021 post.

You might notice something here. The colorburst is expected to just be a portion of a continuous 3.57 MHz signal. That’s signal doesn’t fit evenly into the line frequency; so as a result, the colorburst should not be the same on every scanline. Could that be the cause of our wobble?

On the Apple, on the other hand, Woz noted it’d be very hard to use his HIRES mode if the pixel arrangements different on every other scanline; differing in every other byte on a single scanline is hard enough. So in this rare case, he took pity, and included extra hardware to stretch the clock cycle; on the Apple, the line rate is altered such that it has 228 color cycles. That is to say, it breaks RCA’s optimization, and allows the luminance to more easily interfere with the chrominance. Which is what artifact color is, after all.

So the Apple was a bad example. Another console with 228 color cycles per scanline is my Japanese Sega Master System, even though it’s seen as a more compliant signal in other ways. It was actually surprisingly hard to find a Master System game with a static title screen without a black background; I went with Ace of Aces.

Where you do see variation in scanline artifacts is in scrolling. Look at the ground in the Alex Kidd in Miracle World shot above. Look at the ground, and the artifacts on the ground in particular– where the artifacts are varies from frame to frame; or it’s more accurate to say, remains constant, while the ground moves, producing a shimmering effect.

What does a system that actually has 227.5 color cycles per scanline look like? Well, the PC Engine! (or, in this case, the SuperGrafx, but that shouldn’t matter)

This might be even more obvious if we zoom in a bit. Here’s a screenshot from the title screen of Space Ava 201– it happens to be in SuperGrafx mode, which seems to have more noise for some reason, but we’ll ignore that today because this is extremely zoomed in.

Look especially at where the blue background touches the yellow letters. Kind of hard to see through the video capture macroblocking, but every other pixel is slightly off. That’s because the color resolution is lower than the pixel resolution.

But compare it to the “B” above– the NES has a three-line pattern, not a two-line pattern. Intriguing.

Explanation Attempt 3: The NES is different

The Sega Master System is a natively RGB animal. Its VDP doesn’t have a composite output; it outputs only an RGB image, which an external chip encodes to composite video. My French Master System 2 doesn’t even have that encoder, and as a result can only output RGB. We might say this is the norm for video game consoles, at least those from the latter half of the 1980’s onwards. The rainbow banding in the Master System screenshots above come from the Sony CXA1145 video encoder, and might be different if you used a different encoder.

The Famicom is a creature of the early 1980’s. It does not have a separate video encoder, and it actually never acts in RGB. The PPU doesn’t just output a composite video signal, it also works in that domain throughout, or with digital video data that isn’t color encoded at all. The lack of the RGB intermediary is what makes getting RGB out of the Famicom a bit complicated.

What does this mean? Well, take the NES palette (please!). This one’s FirebrandX’s “Digital Prime”.

But why did we need to credit someone with the palette? Because this is an RGB PNG image, and the NES knows nothing about RGB. As you can see, there are four different brightnesses (that last column’s a little weird), and there are twelve different hues. The first column has no hue; that’s just raw brightness. The NES internally translates directly from palette indices to these hues and brightnesses; it doesn’t even have an S-Video intermediary, let alone RGB.

The Atari 2600 works in a very similar way, but does have an S-Video intermediary, and has sixteen different hues to boot. So why does the NES only have twelve?

The NES has a 21.47727 MHz crystal oscillator, which is exactly six times the colorburst frequency of 3.579545 MHz. The PPU can do a trick where it uses both the rising and falling edge of this clock when generating the color signal, so it has access to a base rate twelve times the colorburst frequency– and so, twelve possible phases come out of that pretty naturally.

And now we start to see where the NES gets its timing from. The NTSC Famicom only has a 21.47727 MHz oscillator. Every other clock is derived from it; divide that by twelve and you’ll get a beautiful 1.7897725MHz clock speed for the 6502 2A03. Within the PPU, the master oscillator is divided by four to get a 5.3693175MHz dot clock, and each scanline is 341 dots (including the horizontal blanking interval), giving us a linerate of 15.7458kHz. Close enough for government work.

And now we see the trick. The relationship between the divided-by-six colorburst frequency and the divided-by-four pixel clock gives us an awkward 227.33 colorburst cycles per scanline. And that’s why we have a pattern that seems to repeat every three lines. Now we understand the B.

But let’s look at that title screen again. It seems like it’s alternating between two frames, not three. Why?

Ricoh’s engineers noticed this relationship between the line rate and the colorburst meant that across 262 scanlines (including the vertical blanking interval), you’d end up with a three-frame pattern of possible colorburst/scanline alignments. Apparently, this was unacceptable– on NESdev, you can see a good diagram by user lidnariq on how this could produce a moving diagonal pattern across the screen.

Instead, the NES does what might described as the world’s laziest interlacing. In interlacing, the last scanline between fields is half the length of a normal scanline. On the NES, that scanline alternates between 341 dots and 340 dots, a “missing dot”. Effectively, this means that you only see two of the possible three alignments, which alternate every other frame, thus creating an effect superficially similar to something with the “proper” 227.5 giving two possible alignments.

It’s worth stressing again that all of this is only true for the NTSC console. The PAL console naturally has a completely different timing system, with a different master oscillator and different divisors– and it doesn’t bother with the missing dot shenanigan at all. Still, the attention to detail here is impressive. The PPU is really an impressive machine for its time!

Rare is the exception

Another edge case of the missing dot is that it only occurs when the PPU is actually rendering; if both background and sprite rendering are turned off, then the PPU won’t bother; I’m not sure why, but if I had to guess, maybe just due to some implementation detail. A screen rendering nothing isn’t going to have anything complex on-screen that would show artifacts.

Now, why would you want to turn off the screen? The PPU, for all its merits, has a major flaw: during active screen rendering, you can’t write to video RAM at all. Instead, you have to batch your writes to occur during the vertical blanking interval. But if you turn off rendering, the PPU gives full access to the video RAM all the time; this is especially convenient if you’re using CHR-RAM, and need to upload all your tiles into on-cartridge RAM.

One game that does this is Rare’s Battletoads, one of their AxROM games. It goes further than most– in order to get the maximum amount of CHR-RAM access time, it turns off rendering every single frame, using careful timing to turn it back on after a few blank lines that can squeeze out a few more tiles for more animation. Let’s take a look. This isn’t the title screen; it’s in-game, but much of the screen is still stationary. Just ignore my toad getting beat up, I’m sure he’s fine.

It’s a little more noisy sure, but to confirm that’s really what’s happening, here’s a bit of the HUD from four adjacent frames. Like in Alex Kidd in Miracle World above, you can really see the effect in the rainbow banding, which in this case shows up on the partial heart– we are basically looking at a snapshot of the colorburst at this dot.

Notice the first and fourth images are near-identical; this is a three-frame repeating pattern, exactly what the missing dot was supposed to cover for. Rare does it again.

No Expenses Spent

Konami’s Target Panic is a small densely-packed PCB, intended presumably to be sold alongside cabinets like the 1996 Konami “Windy”. We haven’t seen a Konami game from 1996 on the blog yet, but it’s fair to assume they did better for their retail games than a Z80 CPU. (A CMOS Z84, as it turns out) Interestingly, the position that would be taken up by a crystal oscillator is vacant on this board.

Of course, a CPU needs a system clock. Konami just went with a cheaper option– a ceramic resonator rather than a crystal oscillator. For reference, a random datasheet for a ceramic resonator gives a frequency tolerance of up to ±0.5%. A totally random crystal oscillator, on the other hand, measures its frequency stability as ±50ppm– that is, 0.005%. While these aren’t the exact parts used, two orders of magnitude less stable sounds about right.

Now, that would definitely be enough to cause some problems for a composite video signal’s colorburst. It might also just barely be audible to a human with perfect pitch, if there was a sound chip and depending on the frequency. But this is an arcade PCB intended to be run on 90’s cabinets, with RGB CRT monitors, and there’s no sound chip. Obviously Konami considered it worth the tradeoff, though both Sega and Taito used crystal oscillators.

Let’s do some comparisons between the three PCBs.

It’s worth noting that I believe all three PCBs stall the CPU for at least some of the time during the active display, so the 4MHz is more of a theoretical maximum. Similarly, the four colors the Target Panic can draw are actually limited, as black and white are hardcoded. Despite spanning half a decade and three separate companies, the hardware specs barely changed. This was how you made a bare minimum game.

Both Dottori-kun and Mini-Vaders are based off of one of their respective company’s popular 1970’s arcade machines. Konami only really started to get into their stride in the 1980’s, though, so what did they turn to here? Well, they didn’t just dig into the past of their games; they dug into the past of arcades and amusements. (Sorry, Astro Invader diehards)

The game

The first thing I want to say is that despite any concerns you might have from the ceramic resonator, I had absolutely no issue syncing this device with my capture setup. So points on that, Konami; thank you for thinking of people playing your game decades later on hardware it most certainly was never intended to run on. Or for having it coincidentally work. I’ll take either.

The test

Before we start, let’s look at this self-test. This was a hard screenshot to get; I had to time it pretty much perfectly, it only lasts about as long as the Framemeister takes to sync.

So, this might not be worth mentioning. Most arcade games start up with a self test, it’s just good practice. But let’s go back to the part where I say that it was extremely fast. Take a look at what the MAME source says:

Konami Target Panic (cabinet test PCB) It takes a while to boot up, just hold INS for a bit to fast forward.

And if you load the ROM in MAME, you will indeed be stuck on the test screen for quite some time before it finally lets you play the game. What’s interesting is, I dumped my ROM just to be sure, and it’s byte-for-byte identical. So this must be waiting on some edge case that isn’t emulated yet. Proof that even tiny boards can have complications for emulating.

The presentation

Target Panic has the most proper title screen out of any of the arcade test PCBs I’ve looked at so far. Not only does it actually show the name of the game (something both Dottori-kun and Mini-Vaders failed at), it even has copyright information, and a trademark symbol. Apparently Konami’s lawyers are very thorough.

One thing I found interesting are these vertical lines that are visible in the full capture. My guess is that these are gaps in the pixels, nearly instantaneous as the 74LS157 or other logic in the chain clocks out the bits. Worth noting I couldn’t see that at all on my Sony Trintron, but it might just because it’s so small.

No really, the game

So what is Target Panic?

It’s a simple game where one of the eight targets that surround the screen will rotate forwards, showing itself to the player. You control the joystick, and your goal is to push to one of the targets and fire by pressing the action button. The joystick control is actually kind of interesting here; you don’t move the cursor. Instead, the cursor follows the motion of the joystick exactly; when it returns to center, the target does. Hold it left, the cursor is left. Hold down-right, the cursor is down-right. This also makes it more useful as a simple console test.

Color is part of the gameplay; it turns red when you get a hit, and then rotates back afterwards. A fun thing to notice is that when looking through the footage for this screenshot, I went back one frame and found that the game actually toggled the color bit mid-frame. You can see where it changes– I don’t believe this hardware has any way for the Z80 to know when VBlank is to avoid glitches like this.

I think you can probably see why I call Target Panic a throwback to an era from before video gaming. It’s a carnival shooting gallery! The sort of rotating targets might also remind you of Hogan’s Alley. A fun little throwback for sure.

Test, again

Target Panic also contains a small service menu. Since this game is so poorly documented online, I decided to go through it. Plus, there’s a fun little bit.

As you’d expect, GAME MODE just brings you into the game. But what about the other options?

IO Check allows you to test the player 1 controls. It’s a little more thorough than just using the game to test, but it’s worth noting that there’s no player 2 options– in fact, they’re not even connected on the PCB.

Of course, Dottori-kun and Mini-Vaders also lacked any 2P controls.

The screen test is just a very simple grid, used to measure and adjust convergence.

The color test allows you to see the eight colors this PCB can produce. However, it can’t display them all at once, as noted above, so they can’t show color bars. I imagine adjusting color would be very frustrating with this as your only reference.

One neat thing is that if you exit color test mode, it keeps the colors you had set. For example, here I now can play Target Panic in red and green; in this case, it changes to magenta when I shoot, and persists back to red and green afterwards, so this doesn’t appear to just be a failure to reset the color bits, but something deliberate.

How much can I say?

There’s not really too much to say about Target Panic. Is it even really a game, or just a piece of test software that has some game-like characteristics thrown in for fun? In any case, I think it’s neat just to see something that the general public was never intended to. I hope you enjoyed the look as well!

Trademarks and Security and Bears, oh my

This is my Model 1 Sega Genesis, VA3 motherboard. As a result, it has no security of any sort. When you plug in a cartridge, the Motorola 68000 starts executing code from the cartridge, and the VDP will output a video signal based off of the commands sent by the 68000. Even the export Sega Master System had a BIOS to check the cartridge had a valid header; this doesn’t even have that. In this regard, it is very similar to the Atari 2600, the Nintendo Famicom, top-loading NESes without the lockout chip, or Sega’s own SG-1000.

It would be the last Sega console to be this free.

From the beginning, Sega had planned to include the possibility of a security system in the Genesis; it just wasn’t present in the first release. Why? Unclear; perhaps they wanted to see if companies actually would try to release third-party cartridges before investing the time to implement. But in any case, if I turn on my Sega Genesis MD3, or any Genesis from the “VA6” variant of the Model 1 motherboard onwards, I am presented with this:

This is the tell-tale mark of the TradeMark Security System (TMSS). I’ve talked about this before, so I’ll summarize. The TMSS system displays a screen claiming that Sega endorsed the game in question. Therefore, to display the screen would be a trademark violation if Sega did not endorse the game, but the Genesis won’t play a game without displaying the screen.

TMSS-enabled consoles have a tiny boot ROM in the IO controller that does the following:

1. Have the string SEGA or ` SEGA (with a space) at address 0x100` in the ROM. This is what displays the copyright screen, but then the boot ROM turns off the VDP again.
2. To activate it back again, the game must first write the 16-bit word “SEGA” to a certain address on the IO controller, before it turns on the VDP.

Sega’s lawyers believed that doing this without the explicit written permission of Sega League Baseball would be a trademark violation. Courts disagreed, but you can’t blame a megacorporation for trying.

Games

Populous by Electronic Arts is my go-to example of a game that doesn’t work on TMSS-enabled consoles; it doesn’t do either of the steps mentioned above. Therefore, even though it got the Sega Seal of Quality, it won’t run on many Genesis consoles.

Now that we’re on the same page, let’s look at two games:

These two games are the Japanese release of Phantasy Star II, and a pirate game called Mahjong Lady; the pirate game is actually just stolen from an unlicensed game, Dial Q o Mawase. These two games do not work on my Sega CDX, as you’d expect. They do work on the VA3 Genesis Model 1 (though Phantasy Star II doesn’t fit in the cartridge slot). So the same as Populous? Not quite.

That’s coming from my Genesis 3 (“MD3”), but only with the region switch set to Japan. You’d get the same thing on a Japanese Mega Drive 2. These games work on Japanese consoles with TMSS, but not American ones. So what’s special about them? They have the SEGA string where the boot ROM can see it, but they don’t write SEGA to the magic address.

So from this, can we conclude that TMSS in Japan only ever required the BIOS check, making it equivalent to the export Master System’s region check? Well, I’d hope it’d be that simple, but…

Channel

Sega Retro makes some interesting claims about TMSS– for example, the TeraDrive got a cool full Sega logo screen. At the time of this writing, it lacks the information about the region difference I mention above. But more important is the following claim, hidden in a list of official games with partial TMSS support:

• Sega Channel (Japanese version) — All cartridges (skips step 1)

This is the first and only time I’ve ever heard of an official Sega cartridge missing Step 1. But on the other hand, the Sega Channel is kind of an oddball. But it also came out in 1994, by which time the Mega Drive 2 was released in Japan, which always has TMSS, even if it’s export-region TMSS.

So, I don’t have a Sega Channel for Japan or any other region. But there are versions of the BIOS ROM… around… and you can look at the address 0x100.

00000100: 2020 2020 2020 2020 2020 2020 2020 2020
00000110: 2843 2953 4547 4120 3139 3934 2e4a 554c  (C)SEGA 1994.JUL
00000120: 5345 4741 2043 4841 4e4e 454c 2041 4441  SEGA CHANNEL ADA
00000130: 5054 4552 2042 494f 5320 464f 5220 3143  PTER BIOS FOR 1C
00000140: 4849 5020 472f 4120 2020 2020 2020 2020  HIP G/A

The string Sega’s there, but it’s not where TMSS can find it. So something interesting is definitely going on here. Meanwhile, on an American Sega Channel, you see SEGA exactly where it’s expected.

00000100: 5345 4741 2047 454e 4553 4953 0000 0000  SEGA GENESIS....
00000110: 2843 2954 2d58 5820 3139 3934 2e4a 414e  (C)T-XX 1994.JAN
00000120: 5365 6761 2043 6861 6e6e 656c 2020 2020  Sega Channel
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................

So now we have something to confirm. We know Japanese games can work if they don’t do step 2, as long as they have Sega in the right place. We know that games that do neither won’t work at all. But can games run without SEGA in the right place, as long as they still trigger the VDP address? Did Sega release a Sega Channel in Japan that didn’t work with the Mega Drives on store shelves? I wouldn’t put it past them, honestly.

Mind you, it’s also possible that the Sega Channel itself does some ROM-mapping shenanigans on bootup.

Test harness

So, we want to try out some code on a Genesis. Unfortunately, a simple flash cart won’t work for this. Every Genesis flash cart I know of boots into an onboard BIOS when it first runs, even if only to check whether jumping to a game has been activated. Therefore, every flash cart already does the TMSS dance on bootup, if they want to work on most consoles.

What we want is to just shove a EPROM we can write to onto the Genesis’ 68000 bus. And that’s exactly what this cartridge, which I got from this eBay seller, does.

So, easy-peasy, right? Yes, that’s what I thought too, until I tried to put a 27C160 into my EPROM programmer.

Yep, you might notice that it’s got one too many pins. After looking around for a solution to this, eventually I built one of these adapters, which let you treat a larger 16-bit EPROM as several smaller ones. I got this as a kit; it’s very reassuring to solder something and have it work the first time!

Note that you’ll be pretending that your device is an “AM27C4096@DIP40”, but it won’t have the right ID. That’s fine as long as you see something like this; the command line minipro is nice enough to let you know that it detected a 27C160.

Invalid Chip ID: expected 0x1001900, got 0x2000B100 (M27C160@DIP42)
(use '-y' to continue anyway at your own risk)

There is one more problem you’ll have to overcome, though. You see, the EPROM is 16-bit. A Genesis ROM dump intended to be used in an emulator is pretty much always going to be arranged as a “little-endian” 16-bit ROM. This means the byte ordering will match what Intel x86 CPUs use, as well as AMD x86-64 and essentially all ARM CPUs in actual use, including the Apple M3 I’m writing this blog post on. That’s great for your emulator, but the Motorola 68000 is actually “big-endian”. So you need to swap every 8-bit byte with the one next to it. It turns out Stack Overflow taught me the common Unix command dd can do that, which is nice.

Do all that, and you’ll finally get this:

I chose Toaplan’s Hellfire for two reasons:

1. It misuses the YM2612 sound chip in ways that are perfectly fine on the YM2612, but it means on later Genesises that use an integrated YM3438, the sound plays too slowly, so it’s fun to use as a test game.
2. It’s a small enough game that putting the ROM using the adapter doesn’t require me to break it up into parts.

Hellfire as a game is fully licensed by Sega, and follows all the TMSS rules. But it’s extremely easy to overwrite the ROM header. We could even use the name of The Enemy.

00000100: 6e69 6e74 656e 646f 3f3f 3f3f 3f3f 3f20  nintendo???????
00000110: 2843 2954 2d33 3520 3139 3930 2e4a 554e  (C)T-35 1990.JUN
00000120: 4845 4c4c 4649 5245 2020 2020 2020 2020  HELLFIRE

This should run fine in emulators, because there’s no real reason to emulate TMSS. But what about consoles? We’ve overwritten the header, but it still should write to the magic address afterwards. And of course, the Sega Genesis Model 1 VA3…

Runs everything.

Results

So, this basically shows that yes, the header is necessary for TMSS to function, even in Japan. And therefore, Sega Channel must be doing something special, either mapping its ROM in a particular way, or maybe even just taking over the bus on bootup to fake the expected SEGA. I’d need to get my hands on one of those to find out, and likely even a logic analyzer; that’s beyond the capabilities of my setup at the moment.

One thing I do find interesting is that I didn’t even get a video signal I could sync to from the Mega Drive 2, while the others gave a blank output. This might imply that it implements this slightly differently, but I’m not sure. In any case, I think this slightly more elucidates the inner working of Sega’s 16-bit console, and that’s all I wanted to do. I hope you found it interesting!

Born on the PC

The exact origins of the tile-matching game using mahjong tiles are unclear, but making it a video game is usually attributed to Brodie Lockard, who discovered the tile-matching game as he dealt with recovery from an injury that had left him paralyzed, porting it to the PLATO system. But it was the Activision-published 1986 release across computers that really made it a mainstream hit.

Shanghai presents you with an arrangement of mahjong tiles arranged in a multi-level structure. You can remove tiles from the structure, but you have to follow certain rules when doing so: to be removed, they must have an empty space on one side, and nothing on top of them. This is a nice brain teaser, and honestly I’m completely addicted to it.

Take a look at the 1986 Apple ][ version above. This uses the Apple’s “HIRES” directly-addressable pixel graphics mode; and while that’s normal for games on this platform, Shanghai pretty much necessitates using the directly-addressable pixel graphics modes whenever possible. Because the problem is that any tile could be on top of any other tile, and they can be on different levels. There’s no tile grid.

And that’s what makes this game so interesting as a use case for comparing ports. Because while computers of this period generally have directly-addressable graphics modes, game-centric hardware usually did not, and that made this game hard to port. The Famicom port above is particularly pathetic; it uses colors to simulate the layers and tiles are limited to 16x16. It’s actually extremely playable and has catchy music, but it’s highly compromised visually. (Oddly, the CGA IBM PC release also used colors instead of levels)

The Sega Master System version is far superior, with big tiles taking up almost the entire screen. This is because the Master System, while not having directly-addressable pixel modes (other than the legacy mode, used in F-16 Fighting Falcon for exactly this purpose, but thank goodness they didn’t use that), does have video RAM. But it doesn’t actually have enough video ram to tile this whole area. So how’s it doing this? Take a look at the tiles in an emulator like Emulicious.

Certain tiles from the top row of tiles are being redrawn mid-frame so they can fulfill double-duty as also covering the bottom row. You can also see how this game uses the majority of the sprite table in VRAM to act as additional tiles instead; the only sprites used are those that make up the cursor. It seems like such a simple screen, but they’re actually pushing the console here! This port was developed in-house at Sega, usually attributed to the famous Mark Cerny.

It’s not just graphical issues. Look at the video of Shanghai on Famicom below. Notice how long it takes for the game to figure out how many moves the player has remaining. Sure, it’s not more than a few seconds, but that’s a lot of frames. Therefore, this version of Shanghai can’t end your game automatically when you have no moves left. I’ve often complimented the Famicom’s plucky little 1.7MHz almost-6502, but this is a complex combinatorial problem. (It’s a faster CPU than the Apple ][!)

It’s worth noting, though, that Shanghai II on the same platform does detect this automatically (though it still takes a few frames to notice), so it’s likely that the original game could’ve done this. This is all just context to let you know that Shanghai is more complex to support than it looks at first glance. We’ve looked at a lot of arcade game hardware here, and it’s almost all tile-based. Tiles are great for video games! But this game required another approach.

You might wonder if this is another case where a blitter, like Nichibutsu used on almost all their mahjong titles, would be a good fit. After all, it’s very clearly shown that those can copy large mahjong tiles around. Well, maybe it would’ve been. But for their 1988 arcade release, Sunsoft did something else.

Advances in PC

The PCB is large but spacious, festooned with both Sunsoft’s logo and the logo of their parent company, the Sun Corporation of Japan, a Japanese conglomerate that still exists today, owning businesses ranging from the recent Sunsoft revival to, uh, an Israeli phone-hacking firm? Okay then…

In any case, the first interesting thing about this board is the CPU. It’s an 8MHz NEC V30; this is an upgraded version of the Intel 8086, which means it’s a 16-bit CPU with a 16-bit data bus and a 20-bit address bus.

Certainly x86 processors are less common than Motorola 68000s in arcade boards of this time, but they’re not unheard of either. In terms of arcade boards that have shown up on this blog, Panic Road used an NEC V30 clone made by Sony. And of course, this also would’ve been a decent CPU for a home computer of the time, though the high-end was leaving it behind by 1988. Pairing it with 16kiB of RAM, though? Extremely stingy. (Yes, yes, code executes from ROM)

I’m not certain, but I suspect that Seibu Kaihatsu, who developed Panic Road, may have been involved in the hardware side of things for Shanghai. Admittedly, this is mostly just the use of the V30 CPU, and the fact that Success’ Kyuukyoku no Othello used similar hardware, but paired with a Seibu Kaihatsu sound setup, and Seibu Kaihatsu appears to have very frequently did this kind of contract hardware work. (The software is all Sunsoft, as far as I can tell)

That being said, Shanghai does not use a Seibu Kaihatsu sound system; it hooks up a Yamaha YM2203 FM synthesizer right up to the V30’s IO ports. The four-operator three-voice YM2203 was a constant companion of Japanese arcade games in the 1980’s; we’ve seen it most recently in my post on Taito’s Kiki KaiKai, and it was a popular sound expansion option for NEC’s PC98 computer series.

The graphics is where this gets particularly interesting. This is the Hitachi HD63484; their answer to the NEC APC’s μPD7220 (which shared a team with the μPD777 we saw in the past with Epoch’s machines). IEEE Computer World notes that in 1988 24% of the PC graphics cards targeting computer-assisted design (CAD) used it.

It was noted for its elegant command-based interface and very high resolution graphics capability; 4096x4096, for a chip released in 1984! (Though at that high resolution, you’re limited to monochrome) Of course, Shanghai is designed for JAMMA, which is limited to “standard definition” video, so you’d never reach that. That mode also required 2MiB of RAM, apparently; here, it’s paired with 256kiB of RAM; this is also the slower 8MHz version.

Indeed, overall the low RAM (and the 15kHz output) is really the main thing separating this from a PC of the time; otherwise, this is a “professional-grade” video setup and CPU. And for what?

Shanghai

The title screen of Shanghai is the same image that Activision used on the box art for most releases in this time, and was also used in the Famicom support, though this is much higher resolution and pretty good quality. (The kanji characters, 上海, mean “above the sea”, but in this case are likely used because this is the Chinese character rendering of the name of the city of Shanghai)

Before we dig into the gameplay, let’s talk about the video a bit more. I used the Framemeister for this capture, and got some stats from it.

You might notice the screen looks slightly cut-off; this makes sense when you notice the Framemeister identifies this as actually running at 53.44Hz and 279p, a very odd video resolution. Weird frequencies like this were more common in the PC space, but weren’t unheard of in the arcade space either. Generally you’d tune your monitor once for a particular board, and that board would stay in place for awhile, so being off was fine. It’s mostly an issue for those of us who want to switch out boards at random and use upscalers; that was never the target market.

My little 9” Trinitron does sync otot the image, but you can see even more of the top of the image was cropped, and my phone completely failed to sync properly to take a good image. Still, in practice I don’t think this is a bit problem. Let’s shift gears from the video signal to talking about something else that is a prediliction of this blog: talking about the difference between arcade games and home computer games!

Translating Shanghainese

Shanghai, as a game, falls into the same category of “patience” games like the classic card game Klondike Solitaire. It’s a single-player game where the main point is just to complete the challenge by moving things about. There isn’t really a loss condition, other than the game becoming impossible. Indeed, Activision’s game usually provides options for reversing moves and finding new moves. (Peeking, on the other hand, usually ends your game) These features are why it’s so much nicer to play Shanghai on a computer rather than building a tower on your table.

Naturally, this is a great way to sabotage the productivity of office workers. But it’s not a great way to make money in an arcade; obviously, if you could just put in one quarter and play for hours, arcade operators would go and buy someone else’s game instead. It’s a business.

So Sunsoft made some changes. Notice the timer at the bottom of the screen; if you make a pair, the timer replenishes a bit. Being able to “find” is limited to three times; this is what the three sticks labeled “HELP!” are for. Being able to back up is gone entirely. On the other hand, since this was a fairly new game, Japanese text explaining how to play is also added.

If you run out of possible moves, the game kills you, but gives you the option to restart with the same board. You start from the beginning, though, so I hope your memory’s good. The lack of any sort of single-step backup is I think a weakness of this game. The later Sunsoft arcade title Shanghai: The Great Wall (Shanghai Triple Threat), which used the Sega ST-V hardware, allows both a selection of three helps and three backups. Otherwise, it follows the basic pattern of this timer-based gameplay very closely, because it actually works pretty well.

There’s another thing that’s kind of odd. In all the versions of Shanghai I’ve discussed here except the arcade one, the mouse cursor moves freely. This is because it’s a mouse cursor, and that’s what they usually do; even when they’re being moved by a controller or something else that isn’t technically a mouse.

But for this arcade game, your cursor is snapped; it always moves to be on top of something you can click on. Moving left doesn’t move it left by a small amount, it moves it to the next leftmost element that you can click on (presumably a tile). It’s fine, and maybe was done to speed up play, but I can see why the ST-V sequel does away with it.

I’ve never even been to China

This might sound like I’m being harsh on Shanghai. And maybe I am, so let’s be clear: this is a very fun game, and there’s a reason it kicked off a whole series of Sunsoft arcade games. The timer adds an element of urgency that’s lacking in the original. It’s hardly the first game’s fault Sunsoft refined the formula later on.

In fact, I always like to go back to the original Shanghai for the simplicity of design; something about just having a single possible layout and a basic set of controls is appealing. And Shanghai for arcade provides that much. The fact that it does so while also being basically a contemporary PC workstation someone stole all the RAM from? That’s just icing on the cake.

History

The Sega Master System is the direct descendant of Sega’s first console, the SG-1000. In fact, in Japan it was called the “Mark III”; the third redesign, after the SG-1000 II that ditched the hardwired controller. While Sega was a hardware company, there’s pretty much nothing “Sega” about the original SG-1000 design; it’s made of off-the-shelf parts, pairing a Zilog Z80 with Texas Instruments’ SN74689A sound chip and TMS9918A Video Display Processor (VDP).

And that VDP is the starting point here. It was used pretty much everywhere, from TI’s own TI-99/4A computer, to the ColecoVision, the MSX1, the Nichibutsu My Vision, the Tomy Tutor, the CreatiVision… It just keeps going. The TMS9918A introduced the modern concept of “sprites” to home machines.

TMS9918A sprites could be used in any mode except text mode. They were single color, 8x8 or 16x16 pixels, and you had 32 of them at a time, with only four on each scanline. This might seem very limited, but compared to the player/missile/ball of the Atari 2600, it was a game-changer.

The Atari 2600 had the ability to expand the pixels of its movable objects horizontally (of course, on the Atari, everything was horizontal). And the TMS9918A had that capability too, for both horizontal and vertical; the TMS9918A datasheet refers to this bit as “MAG”, for magnification. It expands sprites horizontally and vertically. You can see it used here in Champion Boxing.

Now, “MAG” mode is a single bit in a VDP register. It applies to all sprites on screen at any given time; in Champion Boxing, the reason the boxers aren’t scaled is because they’re actually made of background tiles, not sprites. So this wasn’t the most commonly-used effect, but it’s definitely out there.

Why do I talk about this? Because the VDP on the Sega Master System is a direct descendant of the TMS9918A.

The Sega Master System

The Sega Master System made two major changes to the TMS9918A. The first was that it switched from hard-coded colors to a 6-bit RGB output, producing the infamous compatibility palette I whine about on this blog all the time.

But the second was that it added Mode 4. Mode 4 provided a tilemap made out of 8x8 tiles, 16-color palettes, an an entirely rebuilt sprite system. In a very real sense, Mode 4 is the Sega Master System. Every licensed game used it. Yes, even F-16 Fighting Falcon; it just used it on the title screen, though when actually flying the plane it used TMS9918A modes.

But on the first generation of Master Systems, those that used the Sega 315-5124 VDP (often called “SMS1”), the new mode was built on the ruins of the old. Take, for example, the tilemap mirroring bug. An extra bit, which we call the “mask bit”, in the VDP’s Register 0x02, which is supposed to set the high bits of the tilemap address, ends up interferes with the tilemap scanning instead; if you set this bit to 0, then games using the 315-5124 VDP will repeat the top 12 rows of the tilemap over the bottom 12.

The game Ys relied on this behavior in its Japanese release as part of its status bar. (A full screen status bar in a fixed location at the bottom of the screen is pretty hard on the SMS!) You can see the town looks perfectly normal above, which is on my Japanese Master System. But if I play it on my French Master System 2 instead…

Thankfully, the translated release of Ys no longer relies on this behavior, and every Master System and Mark III sold in Japan had the 315-5124 VDP, so this wasn’t a real issue in practice for this game.

There are all sorts of strange states you can get the SMS1 VDP into by messing with the registers. We actually have Sega’s official Master System documentation, and you can see how they handled this; they basically just told users to always set or unset certain bits, either explicitly, or by only providing valid values with those bits set. One of those bits was MAG, which was ordered to be always set to 0.

Sega Master System sprites

Mode 4 sprites are an entirely new system. There are now 64 possible sprites, not 32. Their arrangement in memory is entirely different. There are only three bytes per sprite attribute table entry instead of four. You can have up to eight sprites per scanline, instead of four. Sprites can still be 8x8 pixels, but the 16x16 sprites are replaced by narrower 8x16 sprites.

But on the 315-5124, the new is based on the ruins of the old. It’s fairly clear to me that Sega or Yamaha’s hardware designers didn’t actually intend for sprite magnification to be a feature of the VDP. But the sprite systems aren’t independent, either. We already know that– the “mask bit” applies to the sprite table register as well. But I don’t know of any games that rely on it; because of the way the memory is laid out, it just limits how many tiles you can use for sprites, which is pointless.

So the sprite magnification bit does work on the SMS1. But there are a few heavy conditions.

First off, only four sprites can be magnified in both directions. Take a look at this dialogue scene from a game I’m working on. Notice that Ava is made up of magnified sprites. But there’s only one character on screen. Ava is made up of magnified 8x16 sprites.

But also, there’s something you can’t see here. Even though Ava is only made up of four sprites per scanline, there are four more sprites on each scanline. They’re just invisible and off-screen. Why would I do that? Do I just like being wasteful? Well, clearly yes, but that’s not relevant here. Because if I don’t have the placeholder sprites, I get this:

The 315-5124 VDP can in fact scale eight sprites per scanline, but only vertically. Horizontally, only the first N-4 out of N sprites on the scanline will be stretched. For example, if I only put two placeholder sprites, I only get two horizontally scaled sprites.

This is kind of a pain to deal with, which is probably why there are no commercial games designed for the 315-5124-capable systems that use sprite scaling. It does create some funky effects, though.

The bare minimum on the Genesis

Sega, in their magnificent wisdom, seems to have completely reimplemented the Master System’s Mode 4 at least twice. The first was for the 1988 Sega Mega Drive, known as the Genesis by me. We’ve already seen a strange bug in the Genesis’ Mode 4 that ALF triggered, but at least in that case, the Genesis VDP also has the capability of sprite collision detections in Genesis mode (“Mode 5”) as well.

Essentially every feature that wasn’t used in Genesis mode is gone in the compatibility Mode 4. While the 315-5124 was built on the ruins of the past, Genesis compatibility is built on the ruins of the future. The TMS9918A modes are gone (sorry, F-16 Fighting Falcon), and the mask bit issues they brought with them are gone too– so this is the one case Japanese users had to run into the bug in Ys.

Magnified sprites on the 315-5124 were a leftover from the TMS9918A, and they’re gone too. For these tests, we’ll be running on my Sega CDX. The Power Base Converter does fit just fine on this, though it looks kind of weird.

If I run my same program from earlier, no matter how many placeholder sprites I have, Ava just explodes.

F-16 Fighting Falcon also doesn’t run, but the title screen works, and few genres have aged as badly as outdated flight simulators anyway. I also don’t have two Master System controllers anyway…

Interestingly, apparently Master System games can trigger Mode 5 by toggling an appropriate bit in the VDP status. I have no idea why anyone would do this, unless you have a grudge against the 68000 and the YM2612 or something, and of course no commercial games did.

A coherent whole

After the Mega Drive, Sega released a cost-reduced model of the Master System, generally called the Master System 2. (But it was the Master System 3 in Brazil) That used, for some reason, a rearchitected VDP, the 315-5246.

Why did they redesign the VDP? I’m not sure, but my suspicion would be that it was because of the Game Gear, which released in 1990 in Japan and 1991 in North America and Europe. The Game Gear is based on the Master System, but has a new mode with a lower resolution and higher color resolution, along with outputting a signal for an LCD rather than a CRT TV.

Whether the 315-5246 is derived from Game Gear work or not (if we had die shots, that might make it clear), it’s clear that it is a new design. Whereas the original SMS VDP was built on the ruins of the past, and the Genesis VDP provided the bare minimum for compatibility, the SMS2 seems to have been designed as a coherent whole. Backwards compatibility with the TMS9918A is still provided in the same colors, which makes me wonder if a Japanese release was planned.

A particularly odd choice on the 315-5246 is that it provides two new graphics modes; 224-line and 240-line variants of Mode 4. (Original Mode 4 is 192-lines, same as the TMS9918A) These have slightly different sprite behavior, and 240-line mode doesn’t work in NTSC or on the Game Gear. In Europe, the SMS2 was by far the most common model, and Codemasters actually used the 224-line mode in some games, like Micro Machines. You can see how my SMS1 can’t handle their absolute brilliance.

Interestingly, it works a little better on the Genesis, and I can get into the game. Where the scrolling is all screwed up, because the Genesis also doesn’t support the 224-line or 240-line modes. (Being an NTSC console probably doesn’t help either) It’s just interpreting all the calls for the usual 192-line mode, and that’s close enough to mostly work on a good day.

UPDATE 3/16/2026: Sik on Bluesky speculates that this redesign might’ve been to enable usage of the SMS VDP as an overlay for the arcade Mega-Tech and Mega-Play systems; the 224 and 240 line modes share timing with similar modes on the Genesis, allowing one screen to overlay the other for when those arcade boards were used in a single-monitor setup.

But we’re here to talk about sprite scaling. And I’m glad to say that the SMS2 just supports sprite magnification the same way everywhere, treating it as an actual feature of the sprites. All sprites are properly doubled in size. Since all Game Gears use a similar VDP, while Sega’s official documentation for the Game Gear still says not to use it, some games did anyway, like X-Men on the title screen.

Most emulators seem to replicate the Master System 2’s behavior. Sometimes they’ll do both, with double-sized sprites acting like the 315-5246, while also having the older mask bit behavior to make Ys work. And of course, even with no placeholder sprites, Ava shows up just fine.

As a developer…

What does this mean for the homebrew developer? Well, the easiest option is what essentially all commercial game developers for the console did: don’t use TMS9918A modes, and don’t use sprite magnification. Mode 4 is good enough. Zoomed sprites are weird anyway, what with having different sized pixels and all.

Know your market. The 315-5246 was more common in Europe, but the 315-5124 was more common in America as far as I can tell, and pretty much universal in Japan. The Genesis in all its forms is way more common than either, and so a lot of modern homebrew players will be using that to play Master System games too, so you probably don’t want to leave them out. (Similarly, make sure you support the Genesis controller, even if you don’t use the extra buttons) Well, not the Genesis 3.

What am I doing? I’m so glad you asked!

When the game boots up, I detect whether zoomed sprites are supported at all by doing a simple test. Two sprites are set up so they will overlap if zoomed sprites are supported, and if they’re not, they won’t. This works perfectly; the Genesis still supports the collision bit, and I know how to avoid the ALF bug. This is very quick and the screen is blacked out while it happens, so you don’t see anything.

On both Master Systems, I just treat it like it’s using the older 315-5124 VDP. The placeholder sprites don’t do any damage on the SMS2. While this means I can only have one character on screen at a time, it also means that I can use the full sprite palette for one character, which is a fair tradeoff in my book, as it means I can reuse sprites from Space Ava 201 more easily.

What about the Genesis? Well, players there will get to see a full sprite as well. Sorcery? No, just using the full eight sprites, and including a pre-doubled fallback image in the ROM.

This takes four times as much VRAM. So what’s the point? Well, on the Master System, I can use that for four frames of animation. Master System players get a slightly better experience, but the game is still playable on Genesis.

…That being said, there is a possible alternative I’m toying with. The Genesis should be able write to VRAM at the full speed of the Z80 during active display (as long as you don’t saturate the FIFO buffer); the Master System VDP in either of its forms can’t. So it’s possible that I might be able to get away with animation by just constantly writing the new frames to VRAM. I’d have to store many more pre-doubled frames in the ROM, though, so even with compression this would be a bit painful, and the doubled-sprites are very large. Maybe I could do some diffing logic as well? My animations are pretty simplistic. Right now it’s not a priority, but watch this space.

Top of the Industry

There were a lot of companies that did strip mahjong. Mitchell, Jaleco, Seta, Toaplan, Capcom, Psikyo, nearly everyone at least gave it a dabble. But the one company above them all is the one who came up with the whole idea, Nichibutsu. Nichibutsu wasn’t just the first company and the last company in the arcade strip mahjong business, they were almost certainly the most prolific. Like seriously, they made a ton of these.

And today’s game is a perfect example of Nichibutsu’s arcade mahjong hardware. None of them have names; Koi no Magic Potion was released in 1992, and MAME groups Nichibutsu games between 1991 and 1995 into a single driver in MAME, but that seems to be a MAME thing. Overall this hardware just seems to have been tweaked and changed over time without regard for creating a single family. This was hardware made en masse for games with a short shelf life.

For CPU power, Mahjong Koi no Magic Potion uses two Toshiba TMPZ84C011 CPUs. The TMPZ84C011 is a surface-mount, CMOS version of the famous Zilog Z80, and the C011 means that Toshiba included a few I/O ports built-in. To the internal CPU core, these are mapped to some of the Z80’s existing I/O port, so from a programmer’s perspective, the TMPZ84C011 is just a Z80. You might compare it to the Commodore 64’s 6510 CPU, which adds an I/O port to the famous 6502.

Sound

The first of those Z84C011’s, running at apparently a whopping 8MHz, handles the sound. A Z80 (~ish) for a sound CPU is nothing new in 1992, and neither is what it’s hooked up to: a YM3812 “OPL2” FM synthesizer, a two-operator chip.

This is an interesting one because I think the YM3812 might be more nostalgic in the west, as it was used in the Ad Lib and Sound Blaster cards for the IBM PC, while the PC98 sound cards usually preferred four-operator synthesizer chips like the YM2608 “OPNA”. Here’s a clip of music from Mahjong Koi no Magic Potion’s attract mode. That twangy sound wouldn’t be out of place in a 1992 MS-DOS game! (Though either my capture or the sound filter circuit don’t sound great on those drums; probably my capture)

For sound effects, two of the Z84C011’s I/O ports are used as 8-bit outputs that can drive basic 8-bit DACs. This might takes up almost all of the CPU time, but that doesn’t really matter at all, because this is a dedicated sound CPU. The sound effects sound… fine. All of the sound samples and music data are contained in a single 128kiB ROM.

Video

Consider the technical requirements. Nichibutsu was making mahjong and hanafuda games. They had short shelf-lives, so they had to be as cheap as possible. Nichibutsu’s non-mahjong arcade business was in steep decline as they moved to consoles (for example, 1992’s Terra Cresta II was a PC Engine exclusive), so they didn’t reuse hardware from that. Card or tile games, on the other hand, don’t rely very much on needing to move a lot of objects around the screen. Having larger, detailed objects is more valuable.

So Nichibutsu went with the blitter. Amusingly, the main example of a 2D blitter-based arcade hardware on this blog has been the CAVE CV-1000, which was specifically made to move a lot of objects around on the screen to accommodate bullet hell shooters. But that’s what ten years will do for you; as well as a 133MHz SH-3 on the CAVE vs. our main CPU, a 6MHz Z80-with-stuff-duct-taped-to-it.

As a quick summary, blitter hardware generally works as follows: a dedicated area of RAM, the framebuffer, is used to directly render the screen. (The Nichibutsu system is paletted) This part is similar to other directly-addressable-pixel systems, like the Apple ][’s HIRES mode. The blitter, however, is dedicated hardware that can receive commands from the CPU, which will cause it to copy blocks of data directly into the framebuffer. It is optimized for the graphics usecase, which involves rows that may need to be shifted or with transparency.

I’m pretty sure these surface-mount NB9010 chips are associated with the frame-buffers, and the Koi no Magic Potion hardware features two of them. That means two framebuffers overlaid on each other; since these also have hardware scrolling registers, this can be used to have a single moving object, or just the usual use, two layers on top of each other. (Plus, you can do linescrolling effects, like in the title screen video above) The CAVE CV-1000 hardware doesn’t have this capability, and I’ve also not noticed slowdown in a Nichibutsu mahjong game. Clearly this is much more advanced.

The pixels on the Nichibutsu hardware are very much not square; in fact, at a 240p row being 640 pixels wide, they’re essentially halved horizontally. Color palettes are 12-bit RGB, which is nothing special in 1992, but good enough to show a pretty girl.

One thing worth noting is that the System11 blog has observed color fringing in some Nichibutsu mahjong games from 1989-1990 as a result of using 74LS-chips that are just a little too slow for the job. It looks like by 1992 they had fixed this, since I don’t see any equivalent here; it looks to me like this hardware was constantly being iterated on over time. As an aside, if you like strip mahjong hardware, check out the system11 blog.

Koi? No, Magic Potion!

So, what is Mahjong Koi no Magic Potion? The title means “Magic Potion of Love”, but I think that choice was made for a simple reason unrelated to the game. Specifically, it’s hard to ignore the popular 1991 song Koi no Magic Potion. (Or, uh “Koi no Magic Portion”. My Japanese is terrible I can’t talk…) Nichibutsu was definitely not above a few pop culture references to get attention in a crowded arcade, but I don’t think the game has very much to do with the song.

The doctor gives you the bad news in the attract mode: your disease is incurable. And maybe they could make a cure, but you won’t live long enough for them to develop it. But then on TV, you find out that a scientist has built a time machine… That’s the magic potion you’re looking for; thankfully, in the future we’ve decided that yes, we should put medical cures in big scientific potion flasks.

As for the stripping? (That’s what you’re all here for) We know that in 1992 Nichibutsu left JAMMA because they didn’t want to follow restrictions that resulted in Mitchell putting out a game that became known as “strip mahjong without stripping”. Mahjong Koi no Magic Potion, though, is honestly to my eyes less sexual than Mirage Youjuu Mahjongden. Yeah, there’s girls in their underwear, but they seem to be enjoying themselves throughout, which is what I think Mitchell’s game used for its edge. Also there’s no giant tongues. You don’t even get to see a nipple.

Gameplay

Mahjong Koi no Magic Potion is a mahjong game. You play a two-player variant of Japanese riichi mahjong. In fact, the gameplay is subtly simplified here. Notice that on screen, the girl’s face is huge, taking up a lot of the game. Like Mirage Youjuu Mahjongden, your opponent doesn’t have points, per se; instead, a love percentage ticks up. Once it reaches 100%, you win, which generally takes three rounds.

But you might notice something is missing: the opponent’s hand. You’ll only have the game scroll up to show you it if you lose. Now, they’re still discarding tiles, and you can call those tiles, but as far as I can tell, your opponent will never make a chii, pon, or kan call. That makes this mahjong engine less advanced than 1989’s Mahjong Daireikai. Your opponent will always have a closed hand, and usually will call riichi, though not always.

Mind you, the game is still good enough to know the rule of furiten, so don’t think you can play too lazily.

So, how do they beat you? Obviously, they just get massively favorable hands at a rate higher than would be expected from random chance. Also, check out something else there: mahjong fans will notice that 三連刻, sanrenkou, is not a common yaku in riichi mahjong. It’s a relatively rare local yaku, which my opponent wields regardless. I’m not sure if this was considered a standard yaku in 1992.

If you do manage to win a round against a girl, you get the obligatory stripping scenes. The game makes an effort to add some gameplay with quiz questions during the stripping scenes. These questions, like “which breast do I have a mole on”, “am I holding a pillow or a stuffed animal”, “what has baggins got in his pocketses”, etc. don’t seem to really be predictable in advance. They kind of remind me of the ZZT game Parell Wars 1, which came out seven years later and features a scene wherein you are asked a password at the bank and are given two options, with no clue to guess which is right.

Parell Wars 1, in true ZZT fashion, kills you if you get the question wrong; Mahjong Koi no Magic Potion just removes a few percent from your love meter. However, if you get too many wrong you’ll end up having to play one more round of mahjong against the same girl rather than getting to see her final picture or advance the plot.

Cheat items in Mahjong Koi no Magic Potion work similarly to Mahjong Daireikai in that you gain points for each han you score in a hand that you can spend on them. Unlike Daireikai, you can reuse the items; each use is what costs points, but you have the ability to choose whether or not to use an item right when you need to. For example, you’ll have the option to use an item that lets you see what the opponent’s riichi wait is when your opponent calls riichi.

Oddly, these items are given out or powered up over the course of the story, so you start out having to play regular mahjong, with only the additional option to switch out tiles you don’t want in your initial hand, a gift from the first girl in the game. (Something so common in video mahjong, “BET” games often give you it for free) I won’t give away too much here, but you do get access to the time machine, and get to go to the future. Thankfully, it’s pretty similar to the present. In fact, I suspect this image is a digitization on top of a photo of an actual place, though I’m not sure where.

Mahjong Koi no Magic Potion also features multiple endings, but I’m not quite sure how to trigger them. There are two full playthroughs of the game on YouTube, one gets the good ending, one gets the bad ending and I don’t know why. Maybe depending on how you treat the scientist? You do get to play against him, but he won’t strip.

Note that I do know which one is good or bad; Mahjong Koi no Magic Potion has a full suite of debug features accessed by dip switches, including an ending select.

Another fun thing in the debug mode is when you go into an option that requires which girl to look at, you’ll see two “JAMA GAL”. Who are these? Are they the incarnation of JAMMA in female form?

No. JAMA is a transcription of 邪魔, which just means “a bother”. These two girls are the incorrect option when you choose one of three girls in the future; you still play a round of mahjong with them, but they won’t strip. You do get smiley-face points for your han if you win, but you will also lose your credit if you lose, so they mostly just serve to lengthen the game and annoy you, and even Nichibutsu recognized that.

Drink the potion

First off, I’d like to thank the flyer for some beautiful close-up CRT pixels. Yep, people in the 90’s knew those looked good too, even when they were just the normal way to see pixels. Also they were easier than having additional art. Click on it for my full 1200dpi scan, 26MiB of CRT glory. Don’t you all do it, though, I pay for my own bandwidth. (Also I just noticed now my scanner cropped off the top, why did it do that, rude)

Mahjong Koi no Magic Potion is the most fun I’ve had with a strip mahjong game. However, the game is pretty much entirely forgotten; I couldn’t find any sources of any worth in Japanese. Which makes sense; as I noted, these games were made in bulk and swapped out fast. Would I call it a hidden gem? I mean, it’s still a strip mahjong game, whose mahjong engine is simple even by genre standards. But I guess the light-hearted plot and pleasant art swept me up.

All of Nichibutsu’s game rights now belong to Hamster Corporation, so I assume that includes Mahjong Koi no Magic Potion. Other mahjong series, like Jaleco’s Idol Janshi Suchie-Pai and Seta’s Super Real Mahjong, have gotten modern compilation re-releases, but nothing of the sort exists for Nichibutsu’s arcade-exclusive titles, and they’re obscure enough that I’d be surprised if that changes. So for now, MAME or this PCB are the best way to play them. Or just watch a video. There isn’t that much gameplay.

DISCLOSURE: I was given the expansion for free, though I did pay for the OSSC Pro myself (quite awhile ago, in fact). Therefore, you should take everything with a grain of salt: believe my factual conclusions, but question any of my subjective opinions.

The device

I didn’t get the prior Legacy AV expansion because I already had a Koryuu, which does a similar transcoding of composite and S-Video. That being said, the Legacy AV is a lot nicer than the Koryuu; it shares a power supply, and doesn’t take up your component inputs. (I had gotten the Koryuu for an original OSSC at first, which doesn’t have the expansion port)

The Legacy AV has three inputs on the rear. (I would’ve preferred on the front, but I think for people who switch devices less than me this is probably better.) Composite, S-Video, and RF, here represented by the coaxial F-connector common in North America. Notice that I have an exposed PCB here with no case.

One downside of the Legacy AV connector is that it’s not actually a legacy AV connector at all; the audio goes through the existing inputs. That can be pretty annoying, but it does save complexity. In any case, after updating my OSSC Pro’s firmware, getting started with composite video is pretty easy

Oddly, in the default line-doubler mode, while my screen synced to the Famicom’s signal fine, I did need to switch to scaler mode to be able to capture the video with my external capture box. I didn’t need to do this for the Koryuu; odd, because this is just my usual Famicom; with some non-standard audio mods but a pretty normal video. By default, the signal has a bit less color vibrancy than composite video does on the Framemeister, but I assume adjusting the picture could help. There are a lot more options here than the Koryuu!

Have we played Atari today?

For a little more fun, and to start trying out the RF mode, I decided to break out the Atari 130XE. This machine has an interesting characteristic: it has composite, S-Video, and an RF modulator, built right in, all running at the same time. Plus, the RF is an RCA jack on the back, so I can bring my own cable. I was warned: cable quality here matters a lot. At least here, I can give it the most fighting chance.

There are two ways to approach channels here. The first is to simply do an automatic scan. That’s probably the easiest for most people.

You can also tune into a particular frequency manually. For the Atari 130XE, the automatic was good enough, though.

For the Atari, Here’s me switching between modes while Pitfall II plays. It’s starting with RF.

Notice that the high-frequency noise is gone on RF, but shows as vertical lines on the other modes. This is a characteristic of the modulation and demodulation; it’s pretty much inevitable that higher-frequency components of the signal will be lost. Some might find this preferable. I’d definitely find it playable.

Colors? In my TV Game?

The Color TV Game 6 is the iconic first Nintendo console. Thankfully, mine is not the first, it’s the later CTG-6V, so it should be much more playable.

My past attempts to take screenshots of this console and its 15-game sibling didn’t turn out that great, with a lot of distortion. This was using a generic AV box; so let’s see if the Legacy RF can handle this any better.

One major downside here is that the Color TV-Game 6 has a built-in cable. Therefore, I won’t be able to use my own nicer one like I could for the Atari 130XE. Honestly, this cable feels thin and weak too. Here’s a quick side-by-side comparison.

And like I was afraid of, unfortunately there is still a lot of noise in the output. You can’t really blame the upscaler for that. I suppose a cable mod would be a lot easier than a composite mod, at least.

In fact, you can really tell it’s the cable’s fault because just moving around the cable, with no impact on the console, causes a lot of distortion and even a brief signal dropout. Also, enjoy some beautiful beeping audio– American Pong-consoles usually had a separate speaker for that!

It’s worth noting that for Japanese consoles like this, you want to search for NTSC-M. You may have heard of NTSC-J, but that’s a matter of how the signal is to be interpreted; the channel layout and encoding is still the same, and that’s what the scan is doing.

Hard mode

In October of 2023, I wrote an article on TV Vader, in which I promised a future article on the Epoch Cassette Vision. And in July of 2024, I finally delivered. What took so long? Well, the problem was that the Cassette Vision I wanted to use was this:

The Epoch Cassette Vision Jr. However, it proved a formidable foe– none of my capture devices could get its signal– though I could see it over an analog TV, my days of television photographing are mostly behind me. But it also resisted a composite mod; the negative voltages make this complicated in a good day, and the Jr.’s circuit board ruined it, providing heavy interference. This interference is probably why it was so hard to capture as well.

It’s a bit funny; the Cassette Vision has all of the game hardware on the cartridge. The only role the console plays is to provide controls, and to encode the video. The Jr. may have a better control scheme for Pak-Pak Monster, but it fails at the video job. It all worked out; getting a full-size Cassette Vision allowed me to cover Big Sports 12. But can the Legacy AV make it work?

Yet again, the Cassette Vision Jr. has a hardwired cable. I also had to switch to “2ch”. Nevertheless, I got a picture on 98.7MHz, but it’s rough. Scaler mode without framelock is the way to go here. (Plus, the Cassette Vision is interlaced!) It also lacked audio.

Dropping to 97.7MHz using the manual tune got me some audio. Definitely playable in this state, though very wobbly. I might’ve just gone with this for the blog post!

One thing I did notice is that while the picture is wobbly, I don’t see all the weird noise that was in the composite mod attempt. To make sure this wasn’t an artifact of the game (after all, most of the hardware is on the cartridge!) I decided to switch to Battle Vader.

In this case, the game showed no picture on 97.7MHz, but did work with audio on 98.7MHz. I don’t really understand…

But it didn’t show the noise. My guess would be the inherent filtering that you get looking over the signal over RF gets rid of it, which is why the engineers at Epoch didn’t care about its presence. Perhaps a sufficient low-pass filter would fix things and allow this to be S-Video modded like its larger counterpart? (In fact, perhaps those colored smears are the noise)

Conclusions

So, what’s my opinion of the Legacy AV with RF attachment for the OSSC Pro? I think, combined with the OSSC Pro’s scaler mode, this is probably the best solution I’ve used for RF on vintage consoles, period.

But of course, it can’t do magic. RF is inherently a compromised video format, encoding things for broadcast and mixing audio and video. 80 column text is right out. But on a good day, with a powerful signal and a high-quality cable, the RF mode comes pretty damn close to composite. And I’d say that’s great. (Do need to tweak those colors, though) Thanks to Matt Buxton at VGP for sending it my way!

But seriously Nicole your Panasonic FS-A1F has RGB, just use that.

But of course

That’s right. The Sega Master System was intended to have Lock-On Technology before the Genesis. However, in 1989, Tonka wasn’t convinced this was the best route, and decided to save money by omitting the cartridge header. And admittedly, Sega made what many researchers have seen since as a questionable decision, partnering with tiny American developer Nexa. But at the time, the massive success of Monopoly was seen to demand a truly dramatic follow-up.

That’s right. ALF for the Sega Master System. We’ve seen it before, already known on this blog for pushing the limits of the Master System hardware farther than even the vaunted “blast processing” of the Sega Genesis could keep up with. But it could’ve gone farther.

That’s right. By spending six weeks digging through various dumpsters, the lost prototype has finally been found: ALF, now enhanced with Lock-On Technology. This version is a bit more primitive than the later Genesis version, without a shield to protect the cartridge port, but that snapped off my Sonic & Knuckles anyway.

That’s right. I should’ve taken better care of my things as a child, but that’s not relevant. What’s relevant is this would’ve been revolutionary. A game-changer, if you will. In that it literally changed games. To add ALF to them.

ALF-lex Kidd in Miracle World

That’s right. Of course, Alex Kidd in Miracle World was basically Sega’s answer to Super Mario Bros. (Wonder who? Is he in a Miracle World? I thought not) so of course, it should’ve been a high priority to support for this. And at first glance, it looks pretty good. There’s ALF. He’s in Miracle World. All is right with the world.

That’s right. Alf’s swimming idea doesn’t fit in this narrow passage. In fact, putting ALF in Miracle World was a silly idea. Let’s just switch out the cartridge and go back to ALF.

That’s right. He’s loose. We’re all doomed.