MagicEngine

[Charles MacDonald]

I recently took apart a Super CD-ROM 2 unit and had a chance to examine the NEC uPD78C14 MCU that controls the CD drive a little more closely. For starters the chipset is mostly (1) identical to what's in the IFU-30 and TurboDuo; I would imagine the same holds true for the chips in the PCE/TG CD-ROM drive itself but opening that thing is a chore.

The MCU has 16K of internal mask ROM and 256 bytes of RAM. One of the gate array chips (uPD6378) sits between it and and a 8Kx8 SRAM. It looks like the MCU interface to this chip consists of all the signals needed for external memory access (PF7-0,PD7-0,ALE,WR,RD) and three other (handshaking?) signals PA2-0. Meaning somewhere in the $4000-$FEFF range there is 8K of RAM is present, I'd guess it's for sector buffering.

What I'd like to figure out is some way to dump the internal ROM. This would be a huge step in accurately emulating the CD hardware. I'm thinking some trickery with the MODE pins could help. The MCU has MODE0 = 0V and MODE1 = +5V which enables the on-chip mask ROM. According to the manual if MODE1 is not set to +5V, the internal ROM is completely disabled. The internal RAM may be disabled too.

This doesn't match up with the mode settings listed for other devices in the series, but it may mean that code execution is done from external memory (e.g. normal behavior for a ROMless MCU). In this case, some modifications could be made to map additional ROM in the lower memory area so that a user program could be executed assuming the gate array doesn't interfere.

The user program could relocate to internal work RAM or external work RAM, MODE1 could be set back to +5V, and hopefully the internal ROM would be enabled with the user program still in control. The data could then be transferred for saving in a number of ways (serial port, send it back over the SCSI interface for the 6280 to read, etc.)

If the MODE pins are only sampled during reset, this may not work. Another method might be to replace the RAM with ROM containing a program, and try to get the MCU to crash so it would run code endlessly up past the 16K point and into the newly added ROM space. For example causing excessive interrupts may overflow the stack and make the MCU program run out of control. Likewise pushing the stack down past $FE00 would put it into the ROM area eventually, where a stack with fixed return addresses corresponding to the user program entry point could be located. There does not seem to be any restrictions or security modes to disable execution out of the external memory area.

One thing I have confirmed is that the external memory access signals are not active during internal execution. So the execution of the ROM program can't be monitored from the outside. That makes sense, but it was worth looking into. There's also a EPROM-verification mode other chips in the series have, it might be worth it to see if it still works for the uPD78C14.

If anyone has ideas or comments I'd love to hear about it.

1. The big glue logic chip is updated, but has almost identical pinouts. Probably tweaked for the "Super" hardware differences.

EDIT: One other interesting thing, the trapdoor expansion port on the bottom of the Super CD-ROM 2 unit is a pass-through connector for the SCSI bus. In theory, other devices (given the time period I guess another CD drive or hard drive is practical, but not really - Tape backup anyone? ) could be connected to it. There seems to be logic to allow the device to enable/disable it's SCSI bus connections so the regular CD-ROM drive can still be used.

[Tomaitheous]

[Charles MacDonald]