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.

So, first off, a few ground rules.

1. What happened to the modded ToyShock? Destroyed in a move, unfortunately. Apartment life is rough for projects like that. If I went back and did it again, “being able to be taken apart” is something I would have taken more seriously. Sadly, this means I can’t directly compare the two.
2. I contributed to the Kickstarter for this pinball machine. That being said, I spent all my own money on it, and have had no contact with Wonderland Amusements beyond the usual Kickstarter updates. Still, some might consider that a personal investment.

Wonderland

Wonderland Amusements is a new company, though they have some pedigree– many of the same minds behind Arcade1up, whose Street Fighter cocktail table I played back in 2019. So when they had a project for a sub-$1000 home actual pinball machine, I decided to take the risk.

A few things happened since then between ordering and getting the machine; this most significantly included moving back to an apartment. So I probably wouldn’t have bought it today. Hey, that’s Kickstarter for you, right? So my dear wife will just have to deal when two large cardboard boxes were delivered to the apartment, full of goodies.

Building the Rabbit-Hole

Unfortunately, this is a lot more of a DIY project than the ToyShock. The ToyShock came in more or less two pieces, the headboard and the table itself, and you just put one on top of the other. The mechanics of the machine are in one piece, but you have to build the box around it.

Now, the boxes are easy enough to build if you’ve built IKEA furniture before, or for that matter an Arcade1up. While the pieces were thoroughly packed, I did get hit with some shipping damage. A side panel on the table suffered a puncture from something.

It doesn’t look too bad here, and is thankfully below the playfield. Unfortunately, it’s also visible from the outside. I have not contacted Wonderland Amusements about this; this is a hard piece to replace once installed and I just wanted the damn machine by the time I noticed this. The “wood” here is very thin MDF, much like Arcade1up cabinets. It’s fine, but it’s not resilient or durable. (The playfield does seem to be actual plywood)

As for assembly, I will note a few issues; the first of which is that they used these little wooden pins for spacing and for alignment. The problem is the pins are smaller than the holes, so they just fall out, making this more finicky than it needs to be.

The bigger issues are my own fault, but I will include for your elucidation, should you choose to build this. Here’s a photo I took while building. You can also see the power supply here.

Notice there are four pillars sticking up. Those were pre-installed; at the time, I misread the assembly instructions and assumed that I was supposed to install them, and therefore that as often happens with Kickstarter pieces, the instructions were out of sync with what I got, and therefore the four pillars were just pre-installed now.

This was wrong, and I only learned this much later, when I went to add in the playfield mechanics. The four pillars are just for convenience while shipping, and play no role in the final game, and in fact foul the playfield. While struggling to get it to fit, I slightly damaged one of the playfield pieces– unfortunately, while the damage is almost invisible, it was to the Queen of Hearts’s castle, and everyone familiar with Alice in Wonderland knows that the integrity of my neck is likely not long for this world. Alas.

The other error I made was putting the acrylic top on. (Yes, acrylic, not glass. I get it, shipping is expensive– still, glass would’ve been nice, and ToyShock managed it) You can not slide it in, you have to remove the side rails. No really, you have to, even if you think you can make it. I was hoping I could make it and slightly damaged things. Minor issues, but hopefully you won’t make the same mistakes I did.

Honestly, putting it together was kind of fun. The best part is getting to install playfield toys; a bouncy Mad Hatter, the Queen of Hearts’ Castle, the Hookah Caterpillar. All the electronics are self-contained, and the most you have to do is attach a few cables between them. I got a shot of the CPU while it was outside the box.

An STM32F103ZET6 ARM, a Cortex-M3 32-bit ARM CPU core. That’s more than plenty; there might be some additional pieces behind the screen for video output, but remember, all the gameplay comes from the real world. Still, the bootup time is pretty long, so a faster CPU might’ve helped there.

One minor complaint– the instructions never actually tell you where to put in the balls! Eventually I realized you just roll them down the field into the outlane.

The machine

So, now you have a pinball machine in your slightly pink-lit house. So what?

The playing height is pretty good for me at 6’1”, which is good; I ended up replacing the ToyShock’s legs with reproduction legs meant for a Gottlieb wedgehead, and I was expecting to have to do the same here. Given Arcade1up’s small default height and reliance on risers, I was afraid of the same.

The playfield is simple, but has a few loops and pop bumpers. If you like 1980’s machines I think you’ll be right at home here, and I like 1980’s pinball machines. It’s definitely less elaborate than some modern tables, though.

Though it’s clearly a thinner MDF, there are definitely a few nice points towards long-term use. For example, the area around the flipper buttons, where your hands will rest, has a plastic layer. There’s a protective film covering that you can remove, but overall this should protect the art in those areas a little longer. Damaged control panels from usage was a big problem on Arcade1ups with heavy use so that’s good to see.

The launcher is purely mechanical. In fact, it’s completely disconnected from the playfield and features no electronics at all. Alice Goes to Wonderland does have a multiball, but it’s based around locking in balls first, because the machine physically can not fire balls onto the playfield on its own. Tons of pinball machines do this, so it’s not a big problem. I have noticed a few glitches during multiball where it seems to lose track of how many balls are on the playfield; hopefully firmware updates will fix this. A neat thing about the “ball lock” area is that you can reach it with a skill shot off the launcher.

I know there are a lot of very good pinball machines that don’t have mechanical launchers– Terminator 2, Attack from Mars, etc. But I am glad Wonderland went with one here. Especially on simpler tables, a mechanical launcher adds a lot of control. This one feels pretty good.

The flippers similarly feel nice, with a quick reaction to the buttons, and a nice solenoid thud. Despite this, the flippers are my biggest long-term concern, but only because growing up, we had a Firepower II and that thing never could keep its flippers working for long.

Notice the big “SAFE” light, by the way. I notice that this machine is pretty generous with giving you a new ball when you drain yours, especially early on; that’s a nice touch that most modern pinball machines have, so it’s good to see here. Especially for home use, where you’re not really trying to extract every quarter.

The screen’s the thing

The score is displayed on a small LCD screen. This is pretty typical, and while I would’ve loved an LCD or a big clicky 1960’s style score counter, I have to admit the LCD has a lot of advantage over them for this usecase, especially if you connect to the internet services; have fun punching out your Wi-Fi password without a screen. And there are a few effects like timers, graphics, and the sort to make it fun. The screen is colorful, bright, and has a high enough resolution that I won’t complain.

There are a series of controls on the front, in lieu of a coin slot. A bit of an annoyance is that the two buttons are the same color, but are not the same; the left one is a “confirm” button and the right one is a “back” button. Still, it’s not like you’re going to be looking at them; as far as I have seen the front controls don’t play a role in the game. Obviously the audio controls only control the audio from the screen; those ball noises are real, how would controlling them even work?

Like a lot of modern pinball machines, Alice can go on several missions throughout the game, noted by series of lights surrounding her and different graphics on screen. The game is definitely tuned for ease of play. There’s plenty of speech (though Alice with an American accent is so strange! I’m sorry) and basic images; no real video, though, but why are you playing a pinball machine and expecting to look at the screen?

One thing that might a useful update though, is some kind of attract mode when you’re not playing.

Conclusions

A lot of companies have tried to enter the home pinball market. And none of them have lasted long. The problem is, pinball is inherently expensive. Alice Goes to Wonderland, if you buy it today, doesn’t meet the sub-$1000 price point the Kickstarter aimed for, though it’s still a lot less than something like Stern Pinball’s $6000 home models, you do get a lot more machine. For example, Alice Goes to Wonderland lacks proper drop targets, relying on LED lights on the drop-like panels instead.

Still, overall for someone just a week or two in, I’m happy I got in on this one. Only time will tell how long it remains usable, and how repairable issues end up being. (Already, the Mad Hatter has fallen off his spring; that should be an easy fix, at least) Judging by their website, Wonderland isn’t a one-and-done, at least– they claim to have a Teenage Mutant Ninja Turtles licensed game coming soon.

Of course, there’s the other problem with this market. See, I’m in an apartment now. I’m pretty happy with the one machine, but that’s one and done for me. I just don’t have room for a whole bunch of these, and I imagine a lot of other people have the same problem– this also proved an issue for Arcade1up. But hey, I’m not here to run a business, I’m here to play a game. And so far I’m enjoying this one.

Point of Divergence

Let’s look at the timeline of field-sequential color in the United States.

• January 12, 1950: CBS reveals their system to the public.
• October 11, 1950: Formal authorization of the field-sequential system
• October 17, 1950: RCA files a lawsuit against the FCC
• October 18, 1950: New York Times condemns incompatible system’s adoption
• November 1950: Public tests begin
• May 28, 1951: Supreme Court rules against RCA
• June 25, 1951: CBS begins full broadcasting in field-sequential color in NYC
• October 20, 1951: Color broadcasting ends
• March 26, 1953: CBS abandons their system

In alternate history, the “point of divergence” is the point where an alternate timeline (“ATL”) splits off from the original timeline (“OTL”). There is a very simple point of divergence for this project: avoid the Korean War. This, of course, would have huge effects on geopolitics, on the lives of people not killed in the war, their families, basically everyone in Korea, on the Cold War generally, and we’re just going to ignore all of that nonsense to focus on a niche computer industry difference. In this timeline, the 38th parallel holds.

Why is the Korean War relevant? Well, the southern invasion of the north began on June 25, 1950. UN forces landed at Inchon on September 15, 1950. And during the Korean War, the American National Production Agency wanted the end of color television to free up resources for the war effort; this is why things fizzled out so quickly in late 1951. The war ended (-ish) in July 27, 1953, by which point NBC had a “compatible color” system we all know and love raring to go. So we need to get rid of the Korean War to give CBS time to gain market share.

To be clear, compatible color is better than the CBS field-sequential system in basically every way. We are saddling this timeline with a weird spinning-disc system. But we are saving the lives of ~3 million people so who’s to say what is bad

The standard

In broad strokes, CBS field-sequential color is interlaced in both lines, and in colors.

But to actually make something here, we’re going to need to look into the standard in more details than that. So I started with looking at US Patent 2,304,081, granted December 8, 1942, in the midst of World War 2. Unfortunately, this patent has a lot of nice diagrams, but is focused on the broad concept, not the specifics of the standard adopted in 1951.

Wikipedia cites a 1999 IEEE publication, which is behind a paywall. However, searching for the DOI did allow me to at least uncover this table:

And eventually I was able to get ahold of a copy of the paper in question. The first author is listed as Peter Goldmark, who, it’s worth noting, died in 1977. So this is seems to be a republish of an original paper from 1942. I notice that none of the tables apparently match the claimed characteristics of the CBS field-sequential system, but System 3 is the chosen one from the paper.

You might notice in the table above, there’s a distinction between “color frames”, “frames”, and “color pictures”. Terminology is a little clunky to the modern eye because we ended up with a system where every frame contains full color information. I’ll create the term “progressive color frame rate”; if you weren’t interlacing, what would be your rate of full-color frames? In NTSC, this is the same thing as the field rate. In field-sequential System 3, this takes three fields.

I was unable to find a description of how the blanking periods worked in System 3. However, frustratingly, despite being the main citation, System 3 is not the CBS color system that was adopted in 1951! The first citation I could find proving this was this 1951 Radio and Television News article, transcribed here. But yes, this was a 144Hz system! Presumably that adjustment was made after 1942.

Finally, I was able to get my hands on the Federal Register for October of 1950, wherein the linked PDF the color information starts on page 10. 144 Hz is indeed the correct value, not System 3’s 120 Hz.

Unfortunately, the synchronization information is difficult to figure out because of the low-quality scan of the diagram of Appendix I, but it looks like there is a “color pulse” on red fields, placed within the vertical blanking interval, replacing the horizontal sync pulse with a narrower one. I’m going to assume the color pulse is being shown as having a width of 0.45 times the normal horizontal blanking sync width.

What’s it like in the 1970s?

Here’s a question; what kind of screens do we see in the 1970’s? The electro-mechanical spinning disc system is incredibly cool, but it puts a lot of limitations on how big your monitor is.

Well, it may be tragic, but I think the spinning disc would probably be gone by this point. I’m not an expert on, well, anything really, but I’m really not an expert on analog vacuum tube electronics, but it feels plausible to me that you could produce a longer-lived color phosphor, and a shadow mask technology wherein only one colored electron beam is active for each field. It should still produce a decent picture. (Eventually, you could use an LCD! “JVC LCD CRT” is a fun search term.)

CBS was known to be demonstrating how their video system could be decoded entirely electronically without a spinning disc as early as April 1950, but I don’t know what their system there was.

The Computer

So, I’m calling the fantasy computer here the Columbia ][, Columbia for CBS, and ][ because I want to have the “spirit” of the Apple ][. We’ll use the MOS 6502 as our CPU; this is questionable from a pure alternate history perspective (the close ties between the semiconductor industry and the defense industry mean the lack of Korean War would be expected to change a lot), but it makes it, you know, feasible to talk about specifics.

Similarly, due to the reduced resolution of sequential-color TV, you might instead imagine a world where computers just don’t bother to try to display on TV monitors. After all, both the TRS-80 and Commodore PET used dedicated monitors. But that’s less fun. The Columbia ][ is like its Apple counterpart; the goal is to create an affordable computer with color video using the existing environment that could be implemented with discrete logic.

I wrote a pretty detailed post on how the Apple ][ works, and what you’ll see is everything is dictated by the video timing, which in turn comes from a single 14.318180MHz oscillator. That oscillator frequency was chosen first and foremost because of is the NTSC colorburst frequency. So the Columbia ][ won’t use it. We’re back to square one.

Start with the picture

So, as you probably guessed from the “progressive color frame rate” above, we’re dropping into progressive scan here and are going to ignore interlacing. In 525 line interlaced, we get 262 lines in progressive mode. In 405 line interlaced, we get 202 lines in progressive mode.

It gets worse. We want to know the visible area. On NTSC, the vertical blanking interval is approximately 22 lines per field. My reading of the FCC standard is that that should remain the same for color relative to the line frequency. So 262 becomes 240p, and 202 becomes 180p. Technically, it could get even worse. Vertical overscan is a thing; the Apple ][ places only 192 lines under computer control. But let’s stick with 180 horizontal lines. Here’s a size comparison on the vertical axis, ignore the horizontal.

The horizontal

Alright, so this is where it gets fun. Since we don’t have the colorburst, let’s use a 14MHz crystal that is exactly 14MHz. The pixel clock on the Apple circuit is 7M, so on the Columbia ][ the pixel clock is exactly 7MHz. So we output a pixel every 0.1429μs.

But our line rate has increased! We need to accommodate a 29.160kHz line rate, 34.29μs. So with a fixed 7MHz pixel clock, our horizontal resolution is 240.05 pixels per scanline. To compare these numbers to the Apple, I’ll use the same ratio, since it looks like relative timing is the same in the sequential-color system.

A 7MHz pixel clock gives us a resolution of 148x180. It’s tempting to make a diagram like this to compare the relative resolution, but remember the pixels really won’t be square.

So can we increase that 7MHz? Well, the DRAM used in my Apple ][_plus is Motorola MCM4116BC20.

According to the data sheet, this has 200ns access time, or 0.2μs, but read on in the datasheet to find 375ns cycle time.

We need to read the memory once to crank out 7 pixels. At 7MHz pixel clock, we should have 1μs to do this, which at first glance, seems fine to double the pixel clock to 500ns?

But it won’t work. See, the entire Apple architecture is based around interleaving graphics and CPU accesses, so we’d also need a faster CPU. Unfortunately, in 1976, the 6500 series datasheet noted that the maximum speed was 1MHz. So wide pixels it is.

Oh, but we’re not done yet. I really wanted to keep the 180 pixel height, but it’s not divisible by eight. This causes issues for an 8-pixel height text mode; remember, the Apple ][ used an off-the-shelf chip for its font. So let’s drop that by just 4 pixels; 176. And finally, one last thing. 148 isn’t divisible by 7. 147, on the other hand, is; it’s 7 * 21.

You might wonder why I’m sticking with 7 bits per byte, when the Apple ][ uses the last bit for a half-pixel shift, the one that lets you choose between pink/green or blue/orange. But the very first models of the Apple did not have that half-bit shift; the 7M comes from dividing down the clock. But why would we divide down the clock when there’s no need for the 3.5MHz colorburst?

My gods, alternate history is hard!

Graphics modes

TEXT and HIRES Mode

The first mode we want to implement is text mode. After all that effort above, we got a 21-character wide text mode with 22 rows, worse than the VIC-20. Those are some wide characters too. I used the Signetics 2513 font, but I copied it by hand into my graphics editor, so if there are any differences, it’s uh, the butterfly effect.

Let’s set some ground rules. For one thing, this is only 21x22 = 462 bytes. This is less than half the 40x24 = 960 bytes left for the Apple’s text mode, but I’m assuming it’s still going to be oddly spread over a 1kiB page, because of the need to refresh DRAM. Still, we’ll give two possible text mode pages, just like the regular Apple, in less RAM. That 4kiB system doesn’t seem as bad.

The Apple also has the capability of running with only the bottom four rows of text. Let’s reproduce that here too.

For HIRES mode, I’ve already established 7 bits per byte, so it’s a fairly straightforward effort to adapt it. LORES mode relies on specifics of how repeating bit patterns are treated as video by composite video decoders; artifact colors are not an option here.

But the thing is, this is all monochrome. How do we get color?

You can’t kill me, but you can interrupt me

The Apple had a circuit called the “color killer”, which tried to eliminate the color burst. The good news with field-sequential color is that we have eliminated the color burst entirely, so our text, while blocky, will always be. But what if we had some sick color tricks?

I am making an executive decision that will dramatically change the Columbia ][ from its Apple counterpart, by giving it a built-in IRQ'. I’m killing LORES mode entirely for this, so it’d better be worth it.

• SCRIRQON - Writing to this hooks up the IRQ line to the 144Hz field rate
• SCRIRQOFF- Writing to this turns off the field IRQ.

Additionally, the first IRQ triggered after SCRIRQON is written to will always be that which also has the “color pulse” mentioned above. In this way, the skilled developer can always know what field they’re on.

This means that you can write to the text page select register, or you can change text in real time, and you’ll know exactly which field is being drawn. A character written on the red pulse fields, and then removed in the next two fields, will be red. With RGB as our colors, we are limited to a very familiar eight-color palette:

Planar palettes

We have two text pages, and two HIRES pages. This means that with a simple page-switching IRQ, you could easily have two colors in addition to white and black. Essentially, you write your text to both pages, and switch between them in your IRQ. The two pages act like bitplanes; a letter written to both will be white, but if it’s only written to one of the two pages, it’ll be one of the colors below.

• G=B: Red - Page 1, Green-Blue - Page 2
• R=G: Blue - Page 1, Red-Green - Page 2
• R=B: Green - Page 1, Red-Blue - Page 2

This is a very simple IRQ to code, so these palettes could be very common options. You could think of them as the sequential-color world equivalent of the CGA palettes. It’s essentially a planar graphics mode at this point. I think this is something that could be straightforwardly implemented for a BASIC programmer to be able to choose a palette at will. (While it requires both pages be in use at all time, note that the lower resolution means they take up as much space as one OTL screen page)

Real-time edits

So, let’s assume you want to have all possible RGB colors. Now we have to get a bit fancy; technically, you can edit any byte of memory at any time, but let’s say you want to keep your edits to the vertical blanking interval, avoiding any risk of screen tearing.

The vertical blanking interval is 22 lines, but our line rate is 29.16 kHz. Our CPU clock cycle is 1MHz, so we have 754.5 cycles.

This is an extremely limited amount of time! But what did you expect? Still, since we can write to RAM at any time, it’s probably enough time to get ahead of the beam and copy a screen from a buffer, but it doesn’t leave you a lot of time for actually running game code. Which actually makes it kind of similar to how double-HIRES mode ended up on the OTL Apple ][.

Text mode you might have a better shot since it’s less data, and full-color text might be nice. Shame about that resolution.

Little Brick Out

Little Brick Out is, in a sense, the reason the Apple ][ exists. As the legend goes, having made Breakout in hardware for Atari, Steve Wozniak wanted to make it in software, but needed a computer capable of doing so. Is the Columbia ][ such a computer? Well, no, because I got rid of LORES mode. But let’s see anyway.

The first thought I had was to use text mode with two pages, as I suggested above. Something even the 4k version should be able to do. The limited resolution really lends itself to a vertical playfield. Here the palette is the G=B configuration, but the palette could be switched on the fly, creating some psychedelic colors. The big downside is having the limited Signetics 2513 font. A few semigraphics characters really wouldn’t hurt, and hey, Tandy had them.

A bigger problem is that the grid resolution is pretty low, so this is almost going to feel like playing Breakout on an LCD screen, or maybe an RCA Studio II. (Moving objects on a field-sequential system can have some funky color effects, but these blocks will be moving too slowly to enjoy them) To fix that, we’d have to go into HIRES mode.

I stuck with text mode here, but it might be fun to make some mockups of pixel-accurate mode. However, remember the RAM requirements; I stuck with text mode for this breakout game (“Little X Out?) because I was thinking about what it would need to be able to run on the most limited model.

Could this have been the machine?

Honestly, it’s hard for me to imagine the Columbia ][ being as successful as the Apple was in our world. The resolution pain of supporting domestic TVs is just too high here. VisiCalc can already be hard enough to parse with 40 columns! (And no, 147 pixels is not enough to do a decent software 40 column mode)

But here’s some more thoughts on the concept.

RGBI…ish

I have put seven pixels per byte to match the original Apple ][; the Apple uses that extra bit to shift the color signal slightly; by moving from half a pixel, you change from the “pink and green” artifact colors to the “blue and orange”. That doesn’t do anything for us; I mean, it moves things slightly, which might be useful when our resolution is so low, but what about something else?

One thought I had was an intensity bit. Essentially, there’s some sort of attenuator circuit; when the intensity bit is not set, the video signal is reduced for that set of seven pixels. For our two-page graphics mode setup, this would allow us to attenuate the colors separately, expanding our four-color palette, within 7x1 blocks. And remember, each page could be attenuated separately.

For the “G=B” palette, above, I treated it as a four-color variant. But really, you have the following:

• White
• Attenuated White
• Black
• Attenuated black - This might actually be distinguishable from black on some TVs if you mess with brightness
• The normal, full colors
• Attenuated colors
• Attenuate one page and not the other

That’s a nine-shade (but ten for marketing) palette at the cost of a fairly simple IRQ routine and some complex 7x1 pixel block limitations, but honestly nothing worse than wrapping your head around composite artifacts and shifting pixels on the Apple.

And of course, if you’re doing something to shift graphics on every field, then you basically have an IBM EGA-style RrGgBb setup, only with 7-pixel wide intensity fields. Pretty good for 1977!

The Columbia 2600

What if we took the “line at a time” approach of the Atari 2600 in the field-sequential world? At first glance, this seems perfectly feasible; the TIA’s 8 luminance bits look like they should provide a pretty good range of colors. 24-bit RGB is nothing to sneeze at. We need a way to programmatically make the “color pulse”, of course, but on the other hand, maybe we can use the space freed up by the chroma to fit in a full-length playfield register.

But the big thing that keeps biting us bites us again: the increased line rate means less time for mid-scanline effects, and less code that can run on a scanline. The OTL Atari 2600 has 76 cycles per scanline, derived from its 1.19MHz clock and a linerate slightly off from the spec 15.734kHz. The ATL’s higher line rate drops that budget down to about 40, and then even lower if you drop to a 1MHz clock. And now consider what the 2600’s dot clock is, 3 times the cycle clock. Those are some even chunkier pixels, and remember, the achievable resolution of the 2600 is much lower due to sprite and playfield pixels being wider than the dot clock. We might not need that extra playfield register.

The vertical resolution is somewhat arbitrary on the TIA, since it is only concerned with lines. 192 seems a typical value, and I gave the Columbia 2600 as much credit as possible. In reality, I bet developers would often want to go below 180 lines to give themselves more time for game logic.

Another way to get more time for game logic might be to leave out the one of the fields. Blue is the color the human eye is least sensitive to, so black out the screen during the blue fields. Is it that weird? It does make it so Pitfall Harry is now swimming in oil.

Actually, the Fairchild Channel F’s framebuffer approach might give it a better shot in the market in this timeline. RCA is probably still screwed though.

The Columbia Entertainment System

The NES’ OAM DMA takes 513-514 cycles to copy sprites from system RAM to the internal sprite memory (OAM). The good news is, the faster 1.7MHz NES CPU spends 1282 cycles in vblank, so you can update sprites, but the amount of other stuff you can do during vblank will be pretty low.

Of course, that 1.7MHz is also derived from a colorburst crystal.

Is this a thing?

I think a reasonable question to ask is, I’ve described the technical details of a system, but could you make this? Well, I don’t have a CBS Color System monitor to try it out, and I doubt you do either. If you just want field-sequential color, get a Vectrex 3d Imager, it’s way more attainable than a failed color TV system only sold for a few months during the Korean War.

What about an emulator as a programming challenge, a fantasy console like the PICO-8? I thought about it; you’d have to make some decisions about the memory map that I left to “eh”, but I don’t see why you couldn’t; but I just figured it wasn’t the interesting part. Prove me wrong if you want to, I’d love to see it!

The MD3

This was being sold as “Golden 16 Bit Genesi 3 Mega Drive III Superior Quality Pcb with stereo output”, which is, of course, a beautiful stream of words. But… just what are the Orcos?!!!!!

It’s a Genesis 3, of course. And I have to say this is a beautiful case; not just because of the fox art, but it feels great. I have to assume this is injection molded; I don’t actually have a legit Genesis 3 to compare, but if you told me they found the original molds in an abandoned warehouse somewhere I’d believe you. (Though unlicensed clones using Genesis 3-like shells have a long history)

On the side is the AV out, and you can also see the nice two-tone orange and white. I need to stress something here, though: this is a Saturn-style video pinout. Do not spend a ton of time trying to wedge a Genesis 2-style AV cable into it. I don’t know anyone who would do something silly like that, do you?

UPDATE Dennis van den Broek mentioned that this might be based off of his replacement shell design.

What’s inside

First off, I have to say, it’s almost a shame the shell of this system is so nice because the PCB is gorgeous.

What distinguishes the Genesis 3 from later licensed Genesis consoles, like the Radica hardware or the AtGames “Firecore” system, is that it is entirely Sega hardware; I don’t believe Majesco played any role in hardware design. There are two variants of the Genesis 3; the first was basically equivalent to later models of the Genesis 2 in a smaller container. The second used the Sega 315-6123-01.

This is a “GOAC”, a Genesis on a chip. Everything, from the 68000 and Z80 CPUs, to the graphics chip, the PSG, and the FM synthesizer, are all in this square. (Not even an epoxy blob! Beautiful) It wasn’t just used in the Genesis 3 either; it also made its way to certain models of the Sega Pico. The other two ICs on the PCB are just some SRAM and a Sony CXA1645M RGB video encoder. I’m a little surprised they went with the vintage CXA1645M, actually, but it does provide composite and S-Video encoding as well.

The only clue as to the creation of this board is this logo, noting that it was made in China in 2024, and provides the motivations for using a new PCB: optimization and low noise. The Genesis 3 was a discount product, after all.

Getting it to work

I spent a long time trying to figure out the power supply, and tried to question the seller, who seemed confused as well. (Language barrier, I assume) You see, there’s a sticker on the bottom:

The sticker mentions 9V DC 0.7A. I think anyone who gets too far into old video game consoles or music equipment will end up with a bunch of 9V power supplies. But it doesn’t mention the polarity. The original Genesis 3 used a center-positive power supply that was compatible with the Genesis 2, but that power supply doesn’t fit in the hole. The classic trick of measuring polarity is to use a multimeter to see which side is connected to ground, but in this case, that revealed neither was.

Eventually, I figured it out. This tiny chip is an ABS210, and it’s a bridge rectifier. Typically, bridge rectifiers are used to convert AC to DC, but in this case we’re told to use a rectified 9V DC supply. So all this bridge rectifier is actually doing here is ensuring that the polarity doesn’t matter; any 9V power supply should work.

Which would explain why the seller was confused.

Sega!

The use of the 315-6123 GOAC has tradeoffs. The upside is the design simplicity. The downside is that it lacks signals that Sega didn’t need for its use-case. In 1998, the Master System had been off the market in the United States for six years. The 32X had been off the market for two years. So Sega didn’t include those signals. The Sega CD was discontinued at the same time as the 32X, and as a result, there’s no provisions for the expansion port either.

As a result, the Genesis 3, even in MD3 form, can only really play Sega Genesis games. This is disappointing, but on the other hand, the Genesis still has one of the best libraries of any game console. So what if I can’t play Phantasy Star Fukkokuban?

Another game I can’t play is Populous. My copy of the game is from the original run, which means that it doesn’t follow the rules of Sega’s TradeMark Security System (TMSS). Unfortunately, the Genesis 3 enforces that at the silicon level. So much for the Sega Seal of Quality.

What I can play is Burning Force, the Namco classic. Here’s a screenshot taken on my Japanese Mega Drive 2, which is unmodified, with the “PC BD MD2 VA0” label, a 315-5487-10 ASIC and a Fujitsu MB3514 video encoder, through an Insurrection Industries cable. Click either image for a larger capture.

And here is the Genesis 3 “MD3”. This is using a Saturn Insurrection Industries cable, but admittedly, this cable has a lot of issues with inconsistent pictures. I think there’s a loose connection, but if so, it’s inside the molded end.

The green is definitely a little stronger in the green and weaker in the red. However, that sounds like the cable; it’s why it’s frustrating that this doesn’t use an MD2 cable. I’m sure there are good reasons for it. Other than that I don’t really see any issue; perhaps the MD3 signal is just a tad softer, but it’s within the range of capture artifacts.

To confirm whether it was because of the cable, I bought a cheap replacement Saturn cable. (Unfortunately, the Insurrection cable appears to be out of production) This one had some sync issues so I can’t recommend the cable, but it did get rid of the greenish tint.

Of course, the MD3 isn’t meant to be compared to a Mega Drive 2; it’s designed to be compared to the Genesis 3’s default motherboard. According to RetroRGB, the Genesis 3 is already nothing to complain about in terms of video output, but audio is lacking. Before that, though…

Has this ever happened to you?

There you are, innocently putting in Virtua Racing for the Genesis. After all, you think. Virtua Racing doesn’t work on the original Genesis 3 motherboard, but with this PCB, it should be possible.

Oh! You’ve hit a classic flaw with later Sega Genesis games; the region lock. The Sega Genesis has bits that can be read by the game itself to see what region the game is in, and this game is rendering in the 60Hz Japan mode, which means that my US copy of Virtua Racing just won’t run; I’d get the same result on my Mega Drive 2.

But my Mega Drive 2 doesn’t have this:

The two switches are directly configurable; they’re positioned next to the cartridge port, so even with the shell on, you can just reach them with a little plastic spudger or other tool. U/J is the overseas/Japan switch, and 6/5 is 60Hz or 50Hz. This GOAC has it all!

And with that set properly, you can play what is objectively the best version of Virtua Racing. If you define objectivity the best by having the most dithering, and being a really interesting technical achievement; how I’d love to see what the SVP could’ve done if used in other titles.

In case you’re wondering, yes, the 50Hz mode also works. I don’t usually have much reason to use 50Hz mode on Genesis, but hey, some people like their Sonics a bit slow and squished. There are systems where PAL had advantages (hello, Commodore 64), but I don’t think this is one of them.

Note that while the system claims to have S-Video and composite support, when I tried either of them with a cable I had lying around, it did not work very well. Not sure what the cause of that is, it actually had a drop out right at the screen I was using to test above, so here’s the title screen.

I pretty quickly realized the flaw: I was using the Framemeister, which my past comparison showed really does not work well with composite signals out of the Sega Genesis. (I believe 256-pixel-wide mode works better, but my usual test for that is Master System mode) My little baby Trinitron handles S-Video from this like a champ.

Audio

One of the more noteworthy flaws of the original Genesis 3 was that it only output mono sound. To test this, I will go with the usual tool of art, the 240p Test Suite, which has a convenient audio test mode.

A quick try is left, center, then right. And what I got was…

Right, center, and then left. Which makes it seem like the left and right channels are swapped. And I beeped out my channels to be sure; so this is stereo, but wired wrong. Unfortunate; but if you’re using an audio cable that separates out L and R, this isn’t a huge deal. (On SCART… it’s kind of awful) So here’s Emerald Hill Zone, objectively the best piece of music on the Sega Genesis, totally not just because of my nostalgia.

For contrast, here’s how that sounds on my Mega Drive 2, notorious for having a “poor quality” sound filter. I’d say the MD3 sounds pretty good, but the Mega Drive 2 is more effective at blowing out your ears.

Apparently, this is also wired properly for cartridge audio; however, the only way I have to play cartridge audio on the Genesis is via my Powerbase FM, which doesn’t work here for unrelated reasons. If you have a Mega SD or Mega Everdrive Pro, though, I don’t see any reason why the CD audio wouldn’t work. With reversed audio. It is worth noting that like all Genesis consoles that use an integrated system on a chip, it uses a YM3438, so your music in Hellfire will be too slow but Earthworm Jim should sound fine.

Getting all Soggy

The “SG-1000 SC-3000 Retro Game Console, Compatible Cartridges & Flash Card, AV Output, 5V USB, 3D-Printed Case” is a very different animal from the MD3 above. Where the MD3 has a sleek molded case, the SG-1000 has a 3d-printed black case. Where the power supply was confusing through a bridge rectifier, the SG-1000 uses a USB-B to provide 5V to its chips. Where the MD3 used hex screws, the SG-1000 uses standard Philips head.

Robertson screws might’ve been more appropriate, though. Because while I purchased this one from China, the PCB here is of a decidedly Canadian design: this is the Soggy-1000, designed by Leaded Solder, whose blog is almost certainly a must-read for anyone here. And how do I know it’s the Soggy-1000?

Because it says so right inside. Initially I described this as a clone Soggy-1000, but it’s not really a clone, because this is open hardware, including the 3d-printed case. This is just a pre-made Soggy-1000. They did remove the name “Soggy-1000” from the case, though.

There’s no Sega ASICs here. The SG-1000 is that rare console built out of off-the-shelf parts; the TI graphics and sound chips used here (the TMS9918A, here heatsinked, and the SN76489A) were available and used by other buyers, and the logic that makes this an SG-1000 is all in discrete logic. This is quite the contrast with my SG-1000 II, which uses a Sega ASIC for everything but the CPU.

I got a controller with the system as well; this is a simple NES controller rewired with a DE-9 head at the end set up in the Master System and SG-1000 “joypad with two buttons” fashion; select and start don’t do anything (and pause is on the console, naturally). Many people don’t like the Master System’s d-pad, while I don’t hate it, I can’t deny this is a nice step up.

Testing stuff

So the Soggy-1000 is a well-documented project and I wouldn’t want to steal any of Leaded Solder’s thunder; go read his blog. Plus I don’t have the prerequisites for a full test anyway; for example, the Soggy-1000 has an expansion port for the SK-1100 keyboard, an accessory I lack.

But we can do the basics. Of course, the console can play the standard tombstone-like SG-1000 cartridges, like Monaco GP. Here’s a screenshot I took back on my SG-1000 II, which has a very easy composite mod.

And here it is on the Soggy-1000, which needs no composite mod. Note that the difference here is mostly due to using a Sega integrated system vs. a discrete TMS9918A. I’m also not sure why my older screenshot is a bit squished vertically, it almost looks like PAL.

And it can play games on the “My Card” format as long as you have a Card Catcher. My Card Catcher’s in a rough shape, but it’s nothing a little duct tape won’t fix.

I’ll even break out a fancier title– Sherlock Holmes: Loretta no Shouzou. This is a late SG-1000 title that uses a mapper for larger memory capability. While The Castle had 8kiB of onboard RAM, I believe this is the only SG-1000 cartridge that banks ROM.

Taking a look at the box next to Double Target, a Mark III exclusive, you can see that Sega even branded it the same as a game for that newer system, known for its “Mega Cartridges”. But it runs fine here, whereas Double Target did not.

The Soggy-1000 includes the provision for a built-in game, should such a pre-programmed ROM pop into the relevant socket through means unknown to modern science. Oddly, the game here is Uranai Angel Cutie. (“Uranai”, 占い, means fortunetelling)

This is a fortune-telling game for the SC-3000. And I do mean the SC-3000, in that it’s not really possible to get very far without a keyboard attached; perhaps this is set up to allow quick testing of SK-1100 support?

Note that the Soggy-1000 does not have support for the coin button necessary for the SG-1000-based arcade games. I can’t imagine it’d be difficult to hack it in there, though.

Segagaga– wait no that’s something else

So that’s all I wanted to get at with this post, was to look at some of the cool stuff coming out of the fan community. Very cool to see the ways that, while we’re decades after the replacement of the Sega Genesis by now and even further from the SG-1000, the systems are still living on one way or another. At least until Hiromi is on every channel.

Phantasy Star Fukkokuban

This is Phantasy Star Fukkokuban, a Japanese Sega Genesis game released in 1994 to commemorate the release of Phantasy Star IV by re-releasing the original. It has an interesting component: it is the Master System game, just packaged into a Genesis cart. The PCB wires the Genesis lines the same way your Power Base Converter would. My guess is the reason for this is because the Master System wasn’t very popular in Japan, and Phantasy Star IV tied together the whole series with a lot of tiebacks to the first one in particular.

As a Master System game disguised as a Genesis one, this game is technically interesting. Some Genesis consoles can’t play Master System games, and those ones can’t play this game either. Also, I love the Phantasy Star series; even if 2 is my favorite. This makes this cartridge a perfect subject for my interest, so I’ve talked about it before and will talk about it again. In fact, I have a post I’m working on where I mention it.

So there I was, writing a blog post, and wanted to look up the release date. The first result I found in DuckDuckGo, my search engine?

GameFAQs is at the top; a titan since the 1990’s. The second result is The Cutting Room Floor, a wiki much beloved by myself. And then the third result is “Press Start Gaming”.

And here’s a thing about me. I want to trust new websites. I have a bias towards clicking on articles from sites I don’t know, because to be quite honest, I’ve read the TCRF page on Phantasy Star a thousand times. How else do you learn something new?

Also, I clicked it because the headline was “Phantasy Star Fukkokuban: A Classic Reimagined”. Because here’s the thing. It talks about how the graphics were improved:

Phantasy Star Fukkokuban breathes new life into the classic with its updated graphics and sound design. The visual overhaul retains the charm of the original’s 8-bit aesthetics while incorporating modern graphical techniques. Characters and environments are rendered with enhanced detail, vibrant colors, and fluid animations, creating a visually captivating experience.

The art style honors the game’s roots, with character designs and enemy sprites redesigned to reflect contemporary standards while maintaining their recognizability. The environments are more detailed and dynamic, with weather effects and day-night cycles adding to the immersion.

Well, compare the title screen shots of Phantasy Star above. Which one is Fukkokuban and which one is my personal copy, played through the same Genesis? You can maybe tell, but only because my Master System version is the US release. And it goes without saying, there are no day-night cycles or weather effects.

I should’ve known. The first sentence of the article was “Game data not found,” after all.

And that’s the thing

Large language models are described sometimes as “fancy autocorrect”; this is dismissive, but not inaccurate, in the sense that the core loop of an LLM is to predict the next token in a sequence. Phantasy Star Fukkokuban is an obscure title that is likely not well-represented in the training data. But relations do exist:

• It knows about Phantasy Star, a very popular game
• Fukkokuban (復刻版) means “reprint” or “facsimilie edition”

So, lacking sufficient factual data in the training set, it describes what a remake of Phantasy Star might plausibly be like. There might even be knowledge in the data set of the actual remake, Phantasy Star generation:1 that gets looped in.

To reproduce this myself, I went to ChatGPT, and asked it Please describe the game "Phantasy Star Fukkokuban". Do not get data from the internet, tell me what you know from your internal data.. And what did I get in response?

Phantasy Star Fukkokuban is not a brand-new entry in the series, but a retro compilation release of the original Phantasy Star, created for the Sega Sega Saturn era…

There was a retro compilation release of Phantasy Star for the Sega Saturn in Japan; it’s called Phantasy Star Collection. Indeed, the description of the game it continued from there isn’t too far off from that game’s version of Phantasy Star.

And it’s not just Phantasy Star Fukkokuban. I describe in my post on Mahjong Daireikai that that game is so obscure, the only Japanese source I could find was another “this is plausibly what a game called ‘mahjong daireikai’ might be like”. Well, what Mahjong Daireikai is actually like is a lot different than what’s in your training data, and that’s exactly the sort of information people want to read websites to find out.

Is this the end

And here’s the thing– this blog post can’t do anything about it. I don’t know who Press Start Gaming is; the site’s footer says “©2025 Cloud Gears Media”, who might be this marketing company (but it might not be! Company names don’t have to be unique globally); Press Start Gaming is almost certainly a tool for making money off of ads and sponsored posts, and posts like the Phantasy Star Fukkokuban misinformation exist mostly to give the site more juice of looking like a real website. If someone goes out and buys a copy of Fukkokuban expecting a new and improved Phantasy Star with better graphics and new sidequests, what do they care? The article wasn’t really meant to provide information.

The trampling of the internet with SEO-mongers predates AI, but what LLMs do is massively increase the ease it can be done, and also hallucinate a ton. If they hired a person to write about Phantasy Star Fukkokuban for pennies, maybe that person would’ve found the Sega Retro page or something and at least grabbed some facts. Now you don’t need to do even that. And no one making these decisions reads Nicole Express, or even cares about actually providing information with their sites. That’s not what they’re for.

Anyways, eventually models will do a better job integrating Nicole Express, and will know more information about Phantasy Star Fukkokuban. And is this the worst thing the AI boom is doing? No, not even close. Even the fully automated hit piece against an open-source developer is probably worse than this.

But it’s a real shame. The commons of the internet are probably already lost, and while I might want to learn new things from new sites, I’ll just have to stick to those with pre-LLM reptuations that I trust. Well, until those sites burn their reputations to make a few extra pennies with AI, like Ars Technica seems to just have. (link goes to a Mastodon thread in lieu of a better source for now)

This post is just a rant. Thanks for listening, at least.

UPDATE 2/15/2026 Ars Technica has admitted the article had fabricated quotations and has retracted it.