SG-1000 Smörgåsbord! Cartridges and RGB

Did you think I could leave well enough alone with the SG-1000 II? Of course not. There were some follow-up questions raised by the last blog post, so I’d like to take a look. Also, we’ll build a cartridge to allow for some more in-depth testing. And some more thoughts about a way forward for RGB, too.

A cartridge

So, as far as I know, there is no flashcart for the SG-1000. It’s possible the SC-3000 Survivors multicart will work, but I don’t have one of those. It’s also possible the Master Everdrive will work with a custom firmware, but I don’t know anything about the firmware interface to be sure– it makes sense that it would in my head, though.

But who needs a flash cart when you can just build a cartridge for a flash ROM? For that we turn to Leaded Solder, who has a great series on building an SG-1000 from scratch. And that happens to include a ROM cartridge for the thing. A quick trip to OSH Park later (this post is not sponsored by any PCB fabricator), and I’ve got some nice purple PCBs.

The pointy edges are an artifact of how these are manufactured; your boards are combined with other submitted boards onto a large sheet, which is then printed all at once. That’s how you get scale.

As usual, my soldering job won’t get any awards (that crooked jumper), but it works. A non-polarized capacitor would’ve been fine here but these were the first ones I found; the adorable low-profile DIP socket may or may not be necessary to clear the edge, but it can’t hurt. Then it was just a matter of going to town with a file to add a bevel and remove the crenellations from the cartridge edge.

In case you’re wondering, the jumper is to allow you to use a 64kiB flash memory chip; then, you can store the top and bottom halves of the chip with a different piece of 32kiB SG-1000 software. This board doesn’t support any mapper games (which I think is just Loretta no Shouzou), cartridges with extra RAM, or the weird “40kiB” games (but keep reading). But what it does support covers something like 90% of the SG-1000 library.

Champion Boxing is actually pretty fun in my book, even if menu-based real-time fighting games were rightfully a trend that didn’t last long once more buttons came into play.

Pachi pachi pachi

But unfortunately, one of the games that uses the “40kiB” memory map is Pachinko, a game that we probably want since it’s shown up on the blog before. So what’s the deal with this?

Well, the first thing to note is that the ROM isn’t actually 40kiB. That would’ve been a lot of ROM in 1983. Oh sure, the preservation groups have put up a 40kiB ROM; but it’s actually just 16kiB. The problem is, to an external observer, the ROM looks 40kiB. Let’s explain.

On the SG-1000 cartridge port, there are two signals known as EXM1' and EXM2'. These are active-low signals for two regions of memory. Memory chips generally require an active-low signal for their chip enable pins, so having these signals on the cartridge port makes the cartridges themselves simpler.

Our ROM cartridge above only uses the 32kiB EXM2 region, between 0x0000-0x80000. By the way, what signal is low when you’re in the first half of memory, and high in the other half? That’s right, EXM2' is just the highest bit of the address bus, A15. A 32kiB cartridge can easily just include a single ROM chip using EXM2' as the chip enable, and that’s exactly what the cartridge we built does. Using a 64kiB EPROM, we can use the jumper to choose one of two banks.

The 16kiB EXM1 region, between 0x8000-0xbfff, is generally associated with on-cartridge RAM, being used for that regard in things like the higher-level SC-3000 BASIC cartridges, or The Castle. But you can put anything on there. And it turns out for many 16kiB games, Sega found it easier to acquire two 8kiB ROM chips. You hook up the first to EXM2', the second to EXM1', and let them mirror elsewhere. It’s a lot of mirrors, but if you’re the one writing the game code it’s not really a problem.

Notice that one of the two 8kiB ROM is repeated four times over the 32kiB region, but then we get an additional 8kiB region of new data on top of it. 32kiB + 8kiB = 40kiB, and that’s exactly what the “40kiB” memory map is. But our board can only use one ROM chip, and having to write two EPROMs every time would be a pain. So we want the following:

How do we make this happen? The cartridge board is already designed to hook up to a 64kiB EPROM (that’s what the jumper is for), so that’s easy– we attach EXM2' to A15. The chip enable is a bit more complicated; for the existing catridge, it’s just hooked up to EXM2'. Now, however, we need it to be low when either EXM2' or EXM1' is low. Maybe a table will help.

	EXM1’	EXM2’	Output
	0	1	0
	1	0	0
	1	1	1

EXM1' and EXM2' should never be both low at the same time, so these are all the cases we care about. And an afficionado of discrete logic will note that this is actually an AND gate. I talk about what an AND gate is in the linked post, so feel free to re-read that section if you want a refresher.

Note that when building, I decided for some reason to use 74LS00 NAND gates; this just means we have to put the output of the first gate into both inputs of another gate, making it an inverter. I also decided to “dead-bug” the chip, letting it dangle and soldering to the legs. If I were to go back and make this from scratch, I think I’d just have designed a new PCB; I need practice doing that anyway. But somehow this worked, so I didn’t.

So now we have access to pretty much every SG-1000 game that didn’t use extra RAM or an on-chip mapper. I mean, of course, after we dump the ROMs from our legitimate copies. Sometimes they’re damaged and you can still extract the chips, after all, and Sega Pachinko is rare so you might want a backup.

Being a little more scientific

Let’s get back to the RGB colors. Another test we can do is to use the SG-1000 M2 Test Cartridge. I’m not sure what the original of this is; if M2 refers to the SG-1000 II here (the “Mark II”?), it’s an early model– Charles MacDonald notes in his research that it appears designed for the DRAM layout of the TMS9918A.

But one thing that should work regardless is the color test.

And for fun, here’s an emulator screenshot.

You might wonder why color 0 and color 4 are the same; in reality they’re not. Color 0 is the background color; right now the background color is set to color 4, but it could be set to anything. Mostly, it’s a legacy of the TMS9918A’s ability to overlay composite video signals.

Resistance is futile

I don’t have comments on my blog posts because I can’t be bothered to moderate them. But one commenter on Hacker News, colanderman, stated the following:

…actually, I wonder whether these are source+load terminated signals – that is very common with analog video signals (e.g. VGA). In which case, if the amplifier the author was using doesn’t load-terminate the signals, they will be 2× too large (a factor of ~4.6 intensity) when they reach the ADC. In which case, a ~75 Ω resistor at the end of each wire should do the trick, while also improving signal quality.

This felt like being worth trying to me, even though the Adapteur R.V.B. does provide input resistors. After all, I did have to adjust the analog-to-digital converter of the Framemeister quite a bit to take the above pictures; using default settings looked more like this:

As you can see, here the signals are so hot that the palettes basically max out all of the R, G, and B signals into an eight-color palette. It’s probably not a good idea to run the Framemeister with overly-high voltage signals like this, but I decided to risk my upscaler for your sake to run the M2 test one more time.

Ouch. However, this also drives home the point that this won’t fix our palette problems entirely; what’s clear here is that the RGB signals output don’t have any additional color to them. In the emulator shot, color 09 is rgb(255, 121, 120). However, if the SG-1000 II RGB output had any signal in the green and blue component, it would’ve maxed out to white, not to rgb(255, 0, 0) red. (Look at the grey color E, for example)

Pro tip: it doesn’t matter how bad your soldering looks if you cover it all in heatshrink at the end.

And as I expected, it does get the colors in the right range, but it’s still the same color palette over overly satured RGB. At least I don’t need to mess with the ADC as much?

So, that’s it for what I can do so far, but I appreciate any suggestions. The rest is some musing.

Thinking about the future

So, how do we get high quality RGB output from the SG-1000, from original hardware, in the correct palette? As far as I can tell, there are a few options.

TMS-RGB

One excellent option is the TMS-RGB, a modification for TMS992xA-based graphics processors; those output a component-like signal by default, but that can be processed to produce RGB. Unfortunately, unlike the ColecoVision, the NTSC SG-1000 consoles uses the TMS9918A.

But on PAL consoles, this seems straightforward. On the other hand, though, no SG-1000 cartridge game was designed with PAL aspect ratio or timing in mind. This mod is probably the best option for fans of the SC-3000 in Europe and Oceania, though, and eventually my SC-3000 will receive this mod.

Use a different VDP

For NTSC fans, as well as anyone who wants to play the games of the SG-1000 in their original speed and aspect ratio, there is an issue with TMS-RGB. The ColecoVision released with the TMS9928A, but as far as I know, all SG-1000 consoles released with the TMS9918A. And that has a different pinout. I grabbed this from the TMS9918A datasheet on archive.org.

You can see which signals have differed, as some had to be dropped for the component R-Y and B-Y signals; EXTVDP, used for overlaying another output, isn’t a great loss, since the SG-1000 doesn’t use it anyway. But the other, CPUCLK, is another matter.

This is listed in the datasheet as the color burst frequency, for NTSC it is 3.597MHz, and states that it’s typically not used. But as the schematics (note: Japanese site) for the SG-1000 show, Sega simplified their logic by using this clock signal directly as the Z80 CPU clock.

So you’d have two different options here:

1. Add an external oscillator; this might cause the synchronization between the CPU and VDP to drift, but I’m not sure if any games are aggressively tied to make this matter. Some people do this on the Master System as a last-ditch fix to eliminate jailbars. In that case, transient screen garbage due to the synchronization issue has been reported.
2. Add a circuit that derives the CPU clock from the 10.739MHz VDP clock the same way that the ‘9918 VDP does internally. This is a matter of dividing it by 3.

This isn’t really an option on the SG-1000 II, though, since there is no TMS9918A; the Sega 315-5066 integrates several other capabilities (most notably, the audio) so replacing it with a massive new TMS9928A-based circuit would basically require reimplementing half the console.

Oh, and by the way, if we’re actually building a new video circuit anyway, the TMS9928A isn’t our only option– the Yamaha V9938 used in the MSX2 computers is reasonably available (if a bit pricy, much like the TMS9928A) and outputs both an RGB signal and a CPU clock. Of course, the V9938 also only approximates the TMS9918A palette, but it does a much better job of it than the Master System. Still no audio, though, so it can’t replace the ‘5066; it also requires a faster crystal, so this would probably be better as a whole new PCB replacement.

Derive a better signal from the 315-5066 RGB

Let’s take a look at those RGB color bars again.

Notice that essentially, there are only three possible values for red, green, and blue. So even though you would have to go through analog, it should be possible for a microcontroller or FPGA equipped with a analog-to-digital converter to reliably distinguish them as if it was a digital signal.

If that’s the case, it could then output color signals closer to the composite palette, either over analog or digital. I haven’t done any microcontroller projects and haven’t touched an FPGA since college, but this could be a fun project for another time.

Analog passive circuit

This is the one I’m least confident would actually work, but I’ll bring it up anyway. Here’s a circuit to make a video signal from a VGA connector (which must be at 15kHz for this to work) into monochrome composite. (If it’s monochrome, it’s not really composite I suppose? But everyone knows what I mean)

What we’re interested is the luminance, you can see that this adjusts the red, green, and blue signals using resistors to create something that matches the effective brightness, even though it’ll be monochrome.

To create a simulation of the desaturated colors, it seems like it might be possible to mix a luminance signal back with the RGB color signals, so that all channels have at least some brightness when one does. It won’t be a perfect match for the TMS9918A color palette, but in theory if this works it could be done with very little lag and mostly passive components. (Probably some transistor buffers would be needed as well) I’m not up on my analog video signal modification, though, so this would be a pretty difficult project for me.

Any of these are a project for later. For now, I guess I’ll just be pleased that the original release Pitfall II on SG-1000 still looks better over this version of RGB than it does on the Master System.