MagicEngine
Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 Japanese English 

MCU dumping

 
Post new topic   Reply to topic    MagicEngine Forum Index -> General
View previous topic :: View next topic  
Author Message
Charles MacDonald
Member
Member


Joined: 07 Dec 2005
Posts: 35

PostPosted: Sat Jul 01, 2006 9:08 pm    Post subject: MCU dumping Reply with quote

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? Wink) 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.
Back to top
View user's profile Send private message Visit poster's website
Tomaitheous
Elder
Elder


Joined: 27 Sep 2005
Posts: 306
Location: Tucson

PostPosted: Sat Jul 08, 2006 1:00 am    Post subject: Reply with quote

Quote:
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.


That's a pretty clever idea. I assume the MCU series using a 16bit stack pointer?


Quote:
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.


Maybe it was left over from the developement kits. Tengai Makyo II has a ton of left over text pertaining to a cdrom emulator using a folder on the hard drive. From what I can recal from memory, the programs list were HDbios, HDwrite, "scsi emul", cd emul, along with text of "echo"-ing files to some sort of port on the PC connected to the developement system. I figured the scsi bus was routed to the PC via some sort of port. Maybe the serial port - like back in the days when you could "echo" commands to the serial port of the modem under command.com in DOS.
_________________
www.pcedev.net
Back to top
View user's profile Send private message
Charles MacDonald
Member
Member


Joined: 07 Dec 2005
Posts: 35

PostPosted: Sat Jul 08, 2006 6:43 am    Post subject: Reply with quote

Quote:
That's a pretty clever idea. I assume the MCU series using a 16bit stack pointer?


Yes. It's a tweaked Z80 core, so it's got 8-bit registers that can be used together for 16-bit memory access.

Quote:
Maybe it was left over from the developement kits. Tengai Makyo II has a ton of left over text pertaining to a cdrom emulator using a folder on the hard drive. From what I can recal from memory, the programs list were HDbios, HDwrite, "scsi emul", cd emul, along with text of "echo"-ing files to some sort of port on the PC connected to the developement system.


Very cool, I always wondered if the later games used a HD drive for simulation during development like the next generation of CD-based consoles did. Apparently so!

Actually that has me thinking, with a SCSI pass-through port you could easily have another device control the CD-ROM drive. This would fit into NECs habit of making SCSI interfaces for PCs (thinking of the FX-SCSI for the PC-FX, and the prototype SCSI adapter for the Duo). That makes a little more sense than adding another storage device of some kind to the PCE.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    MagicEngine Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group