furrtek
patreon
Not Konami : Sega 315-5195
🕑 Added 2021-07-26 05:47:17 +0000 UTCTwo weeks ago I took a hike from Konami land to the Sega mountains to help Jotego with his System16 work, by tracing the smallest of the 3 custom chips used by the system.
The 315-5195 fits in the list of early (bad) attempts at hardware security in arcade PCBs.
Half of the chip is used for memory mapping. This has nothing to do with security but it's an essential function for a CPU-based system to work: it "places" the various other chips (ROM, RAM, video controllers, IO ports...) in dedicated zones in the CPU's memory space so it can access them individually.
The memory mapping part of the 315-5195 is quite flexible, it allows setting up 8 different zones each with their size mask and /DTACK delay (automatic waiting for slow devices). But it could really have been squeezed in a few cheap PALs programmed differently for each game.
The second half is an interface for a supervisor MCU, which was meant to bring some form of copy protection by messing around with interrupts and pausing the main CPU to change values in RAM. The fact that its ROM couldn't be dumped easily meant that pirates would have to observe or guess what it was doing for the game to run correctly.
Basically, the MCU was just adding some unnecessary complexity to delay piracy so that games could bring Sega some money at least during the first few weeks after their release. The 315-5195 was just there to allow the MCU to read and write anywhere in the main RAM whenever it wanted to, and without the main CPU's intervention. How much complexity did it add ? That's the funny story: almost none.
The MCU's program could have been written so that complex RAM modifications would happen while the game is running, so that anything unexpected would cause a crash or obvious game-breaking bugs. Multiple traps occuring at various stages of the game or when very specific conditions were met would have wasted a lot of the pirates time.
If you take a look at MAME's source, the MCUs really didn't do anything other than intercept the v-blank interrupt to do simple stuff the main CPU could have easily done on its own, such as:
-Read a RAM location where the sound code is stored, to inform the sub CPU of new music or SFX to play.
-Write a RAM location with the state of some JAMMA inputs.
-Count up at a fixed interval.
In conclusion, the 315-5195 was an unnecessarily expensive chip (it's a custom ceramic 135-pin PGA !) which could have made pirates life much more difficult if it had been used in a better way...
SVG trace and PDF schematics here: https://github.com/furrtek/VGChips/tree/master/Sega/315-5195/
Big thanks to Seb from Reparcade (rep-arcade.com) who donated the chip, and Sam Bo (@sammargh) and Olivier Galibert (@o_galibert) for helping with the pinout. Equally big thanks to my patrons, even if this is a free post ;)
Comments
Such amazing progress! Any idea whether your hike might someday extend to Sega System C-2 hardware? I have a Puyo Puyo 2 PCB and it's really fun but I wonder how much more I would play it in MiSTer...
foo1138
Just wondering, before you head back to Konami land, could you make a short visit to Game Boy valley? I filed something between 10 to 20 issues on your DMG-CPU-Inside project on github a while ago. I'm not sure if I'm correct on all of them and would love to hear your oppinion about them. I totally understand though if you have more pressuring matters to attend to and this context switch would just take too long. Keep up your good work, thanks. Michael
