The background story
I love Thunder Force games. My first experience was with Thunder Force III on the Mega Drive, and then Thunder Force IV. Later on Thunder Force V on Saturn was my last experience with a Thunder Force game... until emulation came around that is.
My curiosity first took me to Thunder Force II on the Mega Drive, which was a mixed experience, having played its successors before it. But later, while digging SEGA games to play on MAME, I found out about Thunder Force AC, which is mostly Thunder Force III, with a few differences. The game is nearly identical so there wasn't anything remarkable about it at the time.
From emulated to real arcade games
After I decided to build a System 16 game I purchased an Altered Beast board to start doing the experiments needed to develop a DevKit. That sparked the interest in knowing and understanding arcade boards, especially those made by SEGA.
Among those was the System C. It's a board that shares many commonalities with the Mega Drive hardware, and it comes in two variations, the sequel being called System C2. these two boards are extremely well described in this amazing article by Nicole Express. Suffice to say, the boards are nearly identical, and System C has unpopulated components which are populated on System C2, with a few other differences such as extra jumpers.
One of the games on this interesting little board is Thunder Force AC, which runs on the System C2. I then set out to see if I could find one, but to my shock, all offerings of the System C2 on eBay were extremely overpriced (in the order of $900+). The original variant, however was found at reasonable prices, so I started wondering if the System C could be modified into a System C2 by adding the missing components and hoping System C2 games would run on it. And thus this journey begun.
Starting the modifications
The most obvious difference is the missing µPD7759, it's companion ROM, and the components that handle the sound mixing. But component labels and footprints aren't enough to determine what goes where, so I would need to either find schematics for the System C2 or read the components from the actual board.
Determining the components
It was time to go shopping for components. I tracked the NEC µPD7759 from eBay (note: those are always sold as new, but they are never new. The components missing for µPD7759 are found on the System 16B, and are simply a 640KHz crystal and the accompanying capacitors. That one gave me a headache though. Despite the somewhat familiar number frequency, these crystals aren't easy to find at all. No luck on Mouser or DigiKey. I was able to track one down on an electronics store webpage that I wasn't familiar with: tedss.com. While in there I also picked up the LS373 that would be needed and the capacitors for the crystal.
Now it was time to get the components for the audio part... that's easier said than done. There are no available schematics to be found, and trying to read component values from pictures in eBay announcements is a hopeless task. So I managed to get my hands on a real C2: Poto Poto. Nice puzzle, certainly cooler than variations on Columns or Tetris.
With that board in hand, I was able to map all components that were missing on the audio section. At this point, nothing left to do but to start adding the components to the board.
Starting the tests
I wrote Thunder Force AC to a set of 39SF020 flash ROMs and promptly tested them in the System C2 to verify they were working. With that done, the next step was to test on the converted System C board... so I flipped the jumpers around the board to make them match the configuration on the C2 board: Near the EPROMs (JP5 and JP13) to 256 KB position (2-1); Near the 68000 (JP1, JP2, JP3, JP4 all to position 2-1 to make the slots JEDEC compatible), and powered it on. No smoke, but a white screen was all I got. Needless to say, that was disappointing. So I started poking around.
A new difference has been found. The System C came with 16 KB of RAM memory, while System C2 came with 64 KB. Yeah... I'd say that missing 48 KB of RAM can crash definitely a game. 😛
Luckily, I had the right 32 KB RAM modules that I got (incorrectly) for a System 16B conversion to System 16C, so I removed the original modules and soldering the new ones in. Booted the system and... still white screen.
Without any clues of what to do next, I started poking again, and changed the jumper JP7 from 2-1 position to 3-2. It boots!
Booting the game
Well... kind of boots. The service switch was on when I powered it up, which led me to the service menu, but the game still wouldn't run. A black screen this time. But well, being at the service menu meant that I could do some stuff at least. The test menu revealed some things. I had a "bad" ROM, sound test didn't work, and it seemed that the fire button was stuck ON.
More troubleshooting
More inspections and looking around the board revealed another difference: R30 and R31. On System C, R30 was populated and R31 unpopulated, and on C2 it was the opposite. Measurements revealed that pin 26 was held high when R30 was in place, and it had signals flowing when R31 was in place. That makes sense, since on the 8 KB memory module, that pin is used as CE2, while on the 32 KB module it is A13. Resistor got moved and... the game boots!
That's a nice sight, music is there, and voice samples are there too. Looks like a the first success. Starting the game confirmed that the fire button is stuck... not a big deal on a shoot 'em up game, but definitely something that I could live for at the moment. Playing the game, at a certain point I noticed that the FM crashed. The samples continued to play from the µPD7759, but without music. Moving to the second stage did not restart the music. A new mystery in my hands.
The custom I/O chip
Okay, now to the stuck button. I measured the resistor array and it seemed to be functioning properly. The pin where the affected input goes to was changing states properly when pressed when measured at the I/O chip pin. That could mean only one thing: It was damaged. And it wasn't hard to figure out how... if I were to look at that pin's position - on the other side of the JAMMA slot - it correlated directly with the 12V power supply. So in all likelihood, this board got inserted in reverse to a non-keyed JAMMA slot, sending 12V through the inputs and thus burning those that received the extra voltage.
Finding a replacement
More multimeter measurements done, and I determined that the control signals for the YM3438 were coming from... the SEGA 315-5296 chip as well. Could some issue in that chip caused by whatever got the fire button stuck be affecting the audio as well? It started to appear that replacing that chip would be the next thing to do... but where to find a replacement for a custom chip? Surely getting another System C just for that made no sense... and this chip is also used on System 18 and System 32 boards, but then again, not great candidates for sacrifice.
I started to poke around eBay for random SEGA boards... trying to find something that had those. I found a number of boards with similar footprint chips, but none with the right code... until I stumbled in a listing "Unknow SEGA I/O Board 838-10646" being sold "as is". Two chips with the right footprint. Two 315-2596 chips. Jackpot! There were 3 listings with that board, so I grabbed the cheapest one for $18, and waited for it to arrive.
The board finally came and it had a ton of dust in it. Ultrasonic cleaning gave it a much better appearance, so the next thing I needed was some hot air and lots of flux to remove one of those chips. and then do the same on my experimental System C. Soldering that chip was tricky but it went fine. After it was done, the stuck fire button was no longer a problem, and all inputs were working as expected.
Music woes
Now back to the vanishing FM issue... my observations revealed that the FM would work fine until an ADPCM sample interrupted a current playing PCM sample. The µPD7759 is a single-channel mono ADPCM decoder, so if a new sample is sent for playback it will interrupt whatever was playing before. Somehow this seems to be related to the crashing FM. For example, on the title screen, there's a voice that says "Thunder Force survival mission", and then later it says "Copyright 1993 by Technosoft and SEGA". When a coin is inserted, another voice says "Thank you". If I insert coin while one of the previous message is being played, the FM will crash right then and there. If I do it in between the previous speeches, or after they are done, the game will start normally with FM music.
So there's either: a) a conflict somewhere; b) still a physical difference between the boards; or c) some logical difference that I have not yet determined.
Other things to look at
One other physical difference was in the PLD chips. Both of them come with 3 of those chips. Of those 3, 315-5394 and 315-5395 are common to both boards. The C variant uses 315-5393 and C2 uses 315-5452 in the same spot. So I fetched the chip code from PLD archive and burned myself a copy of 315-5452, which then was used to replace the 315-5393 previously in that spot, but that didn't produce any effect. I left the new PLD there since it was the one supposed to be in the System C2 anyway.
I did some more tests, including running the game without the µPD7759 chip (since it's seated in a slot) and I noticed that the FM would not crash at any spot where it was previously crashing. Something odd happened though, which was the game getting stuck after defeating the boss... I could still move the ship but it would not advance to the next stage. I suppose there's some sort of status waiting from the µPD7759 that was not received and the game stood there waiting forever.
Well, it wouldn't hurt testing other games... which to my surprise... none of the System C2 games booted, except Twin Swash... which would freeze in a few moments after booting, during the demo screens. Columns, Columns II, and Bloxeed still worked fine.
The divine light shines (June 30, 2022 edit)
After this article was posted, an angel came to me and gave me a hint. I follow up on that hint and figured out what was going on.
Turns out, that in the System C, the !RESET pin on µPD7759 (pin 19) is tied to !IC pin on YM3438 (pin 11, it clears all registers, effectively acting as a reset). So why is that a problem?
The µPD7759 is a speech synthesizer as NEC describes it. It wasn't really made with video games in mind. In a crude way to explain this, the way it's wired up in System C/C2 is to operate as a master device. That means it controls the flow of data into it, and it's why it's wired directly into the sound ROM. When the µPD7759 is given a command to play, it just goes. It will read command and data bytes directly from the ROM and there's no way to make it stop until it reaches the end of sample command byte. I suppose by now you can already see why this can be a problem in games... because a sound effects can pop while other sound effect was still playing. And this is accomplished by sending a reset signal to the chip, then telling it what is the next sample to play.
So finally it became clear why FM stops when a sample is played on top of another sample: Since both resets are connected, when that signal reaches the YM3438 it will clear all registers, which include the attenuation register (then it's set to maximum attenuation) which makes all sounds quit.
The solution
To solve the situation we need to separate those two and wire them to where they should be wired to. An analysis of where the reset signal comes from reveal that it's on one of the outputs of the AND gate chip 74F08 (IC23). The two signals "ANDing" on that gate are the master reset signal, and a reset signal that comes from our beloved I/O chip 315-5296, so effectively, if any of the reset signals is triggered, they'll pass through to the output of that gate.
To solve that, fiest we'll separate the pins from this combined reset output. So I tied pin 19 from µPD7759 to the software controlled reset signal which is fed to pin 13 on our AND gate IC23. Next, pin 11 from YM3438 gets tied to the master reset signal fed to pin 12 on IC23. Made sure pin 19 from µPD7759 and pin 11 of YM3438 are no longer connecting to each other, and not connecting to the combined reset output signal on IC23... and time to power it up. It works! No more FM interruption, and the sound test on the service menu now works.
Conclusion
Wow, what a journey. I can't stop being amazed by the power of the community. Had I not made this post this would have been in obscurity until someone came up with this solution somewhere which may have not happened, given the System C isn't that much of interest compared to other boards in the SEGA System series.
It turns out that an oversight on System C led to this issue, and it's obviously clear why they needed a board revision which resulted in the System C2. Most likely they just pushed out the only games that did not use the µPD7759, and held everything else back (which was probably already in their roadmap) until the revision came out the next year.
Thanks to everyone for reading this article and super special thanks to the community angel that came to my aid. I hope someone finds this useful and have lots of fun playing System C2 games on the System C board which is not yet too overpriced.
See you next time!
Hi. I have a doubt if there is a 82KOhm resistor or it's another 8.2KOhm resistor, making three of those in total
ReplyDelete