Old News (9/19)

I was recently sent a Gaelco "Master Boy" PCB from ClawGrip to examine. It's entirely implemented in TTL logic and a few PALs which I've desoldered, socketed, and dumped. All of the hardware functions have been mapped out except for the video timing and tilemap generation. One surprise was the inclusion of a Phillips SAA1099 stereo programmable sound generator which I haven't seen before, to go along with MSM5205 ADPCM decoder. I can't get sound out of the board, but it seems like quite a capable chip compared to other PSGs like the AY8910 or SN76489.

It uses a Hitachi HD647180 MCU, a Z80 clone with a number of features added such as I/O ports, a MMU, DMA, and so on. However none of the special function pins are not brought out to the connector that joins the CPU module to the main board. In effect, it's just used as a Z80 with internal ROM. Some clever tweaking of the address lines (and assumed use of the MMU) allows the MCU to address 16K of internal ROM and 64K of external space, but the actual game board's memory map only uses 48K with a 16K gap at the beginning.

Now that it's known that the ROM data is accessed in banks rather than linearly (something I was sure the MMU would have allowed for) this means some trojaning methods won't work, and others might. The game has several pointers and offset tables in the ROM which may be useful for accessing the internal ROM data. It all depends on the game doing any validity checks on the table contents before using them.

Thanks to ogoun and Stiletto the Namco C68 MCU has been positively identified as a M37450 and I now have some documentation for it. I modified an existing PC-Engine USB / flash memory card I made to interface with the MCU (hooking up through the EPROM and PAL sockets) which has allowed some experiments to be run, but didn't result in the internal ROM being dumped. There are plenty of other things to try - one big advantage is that external memory can be mapped into the stack range (due to limited on-chip RAM) which may allow for a stack overflow technique to be used. Currently I am working on some better development hardware for the 68000 side so I can have external control of the dual port RAM the MCU has access to.

With the success of the Choko dump from a while ago, I'm working to get the CPS-2 dumping tools and instructions updated. Changes were made from the last version, mostly bugfixes and speed-ups to decrease the amount of time it takes to dump a full table set. There's also a minor modification that needs to be done to the PCB, to ensure stability, though now that it's known which features are absolutely needed, I might redesign it. Admittedly not many people have been interested in getting more of the games dumped, probably because all the popular ones we wasted tons of quarters on are already emulated! :)

Old News (7/24)

When I was working on the C69 MCU found in the Namco NA-1 hardware, it came to my attention that later Namco System 2 boards had a C68 MCU instead of the HD63705 which earlier revisions used. It seemed reasonable to assume Namco used a M37702 as well considering the C68 and C69 are physically identical. I had picked up two Suzuka 8 Hours boards to examine the C68 and see what possibilities there were for trojaning it.

The MCU interface is virtually unchanged for the C68 compared to the previous System 2 boards, except for some slightly different connections and a new address decoding PAL. However the C68 pinout doesn't match any of the M377xx series. After disassembling some of the external program ROM dumps used by the C68 in a few games, investigation of the code shows it's actually a Mitsubishi 740 series based MCU, which is a 6502 core with extra instructions and features. Of course when Mitsubishi's microprocessor division was transferred to Renesas, they dropped support (and documentation!) of the older chips. I was able to reverse engineer the PAL outputs to put together the original equations and come up with a memory map, as well as make a partial pinout of the C68.

However, I need some help locating a datasheet (user manual) for it, and I don't know the official part number. The C68 is a 100-pin QFP plastic chip, rectangular in shape with pin counts of 24, 16, 24, and 16 pins going around the perimeter from pin 1. The part has a date marking of 1991. While there are many modern parts that are similar to this chip, most of them are for USB or LED segment drivers and do not have an external address/data bus, which the C68 does. The 3806 group of the 740 series, particularly the M38063M6-XXXFP seems like a very close match, but the pins are shifted around. I already have the 740 software manual (e740sum.pdf).

Feature-wise, it has eight analog channels, possibly 6 or more I/O ports (going by Mitsubishi's nomenclature, ports 0,1,2 are the data, address low, address high buses, and ports 3,4,5 are used for general I/O), internal RAM of at 256 to 512 bytes at $0000-007F/$0100-013F, and internal mask ROM of an unknown size. Another unusual feature is that the SFRs are at $D0-$FF instead of $00-$3F which may help in identifying it. In the following pinout, the address/data buses, CNVss, and analog converter channel inputs have to match whatever chip is being looked at as a potential candidate, the others are not critical. I've been through everything I can find at the Renesas website and in my collection of manuals, so I'm fairly sure the C68 corresponds to a part that is no longer in production or supported.

If anyone has any tips or ideas about which chip this part is based on, I'd certainly like to hear your suggestions!

C68 pinout:
  1 - ???
  2 - I/O port; IK1 pin 7
  3 - I/O port; IK1 pin 9
  4 - I/O port; 1P/2P mux input group IF3 1Y
  5 - I/O port; 1P/2P mux input group IF3 4Y
  6 - I/O port; 1P/2P mux input group IF3 2Y
  7 - I/O port; 1P/2P mux input group IF3 3Y
  8 - I/O port; 1P/2P mux input group IJ3 1Y
  9 - I/O port; 1P/2P mux input group IJ3 4Y
 10 - I/O port; 1P/2P mux input group IJ3 2Y
 11 - I/O port; 1P/2P mux input group IJ3 3Y
 12 - I/O port; GOUT2
 13 - I/O port; GOUT1
 14 - I/O port; GOUT0
 15 - I/O port; COIN1 (was PA6)
 16 - I/O port; COIN2 (was PA5)
 17 - To PAL pin 3
 18 - I/O port; LOCK (was PA3)
 19 - I/O port; !VBLANK (was PA1)
 20 - To PAL pin 6, 2F pin 1 (DIR on RD7-0 bus which was IOR|W)
 21 - To PAL pin 5
 22 - To PAL pin 4 (and 2C C149 pin 27, was IOR|W)
 23 - 
 24 - 

 25 - CNVss (To JP18.2)
 26 - /RESET (!SUBRES)
 27 -
 28 - CLK input (8 MHz, same as 2A p11)
 29 -
 30 - ???
 31 - To PAL pin 2
 32 - GND (Vss)
 33 - CPU D7
 34 - CPU D6
 35 - CPU D5
 36 - CPU D4
 37 - CPU D3
 38 - CPU D2
 39 - CPU D1
 40 - CPU D0

 41 - ???
 42 - CPU A15 (To PAL pin 7)
 43 - CPU A14
 44 - CPU A13
 45 - CPU A12
 46 - CPU A11
 47 - CPU A10
 48 - CPU A9
 49 - CPU A8
 50 - CPU A7
 51 - CPU A6
 52 - CPU A5
 53 - CPU A4          
 54 - CPU A3
 55 - CPU A2
 56 - CPU A1
 57 - CPU A0
 58 - A-D channel ?/8 input (from C16)
 59 - A-D channel ?/8 input (from C17)
 60 - A-D channel ?/8 input (from C18)
 61 - A-D channel ?/8 input (from C19)
 62 - A-D channel ?/8 input (from C20)
 63 - A-D channel ?/8 input (from C21)
 64 - A-D channel ?/8 input (from C22)

 65 - A-D channel ?/8 input (from C23)
 66 -
 67 -
 68 -
 69 - +5V (Vcc)                      
 70 - GND (Vss) (through filter)
 71 - +5V (Vcc) 
 72 - +5V (Vcc) 
 73 - GND (Vss) 
 74 - I/O port; Group IF3/IJ3 mux select output
 75 - I/O port; RSCLK (was PC2)
 76 - I/O port; SCOUT (was PC0)
 77 - I/O port; Input from optocoupler using SCINA/SCINK (was PC1)
 78 - I/O port; IK1 pin 3
 79 - I/O port; IK1 pin 5
 80 - ???

I'm looking forward to writing code for the C68 as I've been wanting to work with the 740 series chips for a while now. And hopefully, a method to read the internal ROM can be figured out.

Old News (5/28)

I recently had some time to work on my PC-Engine development board again, with the help of a logic analyzer to aid in debugging. It turns out the data bus was not being driven strongly enough to a low level for the USB module to recognize zero bits when latching a byte. After adding some pull-down resistor networks on the data bus to help bias the weakly driven lines to ground and running a few transfer tests, it looks like all the bugs have finally been worked out.

Old News (4/6)

Guru kindly sent another NA-2 board for me to work with. I've got the NA-1 USB hardware hooked up to it and have tried running some of the C69 trojans as well as new programs to figure out what's going on. Namco did a good job patching up the holes in the C69's security. ;) I'm sure in time the C70 can be dumped.

I recently had a HD crash and was able to recover most of my projects, which has motivated me to release more things on my webpage before they get lost. Hopefully in the next few updates I'll add more content. The CPS-2 dumping software update that was used to get Choko decrypted as well as the NA-1 tools are on the top of the to-finish list.

SDL updates of SMS Plus and Genesis Plus are underway and getting close to a releasable state - no more DOS. ;) Steve Gilissen has contributed some excellent artwork for the GUI, and I've added support for Blargg's amazing NTSC video signal processing libraries which gives an authentic display with minimal overhead. Once you start using it, you won't want to go back to anything else!

I've been revisiting some older hardware research I did with a fresh viewpoint and have been examining video timings for several PCBs as well as other functions:

Sega 315-5197 tilemap chip (System 16B, Outrun, X-Board)

400 pixels per scanline:
 29 pixels from /HSYNC high to /BLANK high (left border)
321 pixels from /BLANK high to /BLANK low (active display)
 18 pixels from /BLANK low to /HSYNC low (right border)
 32 pixels from /HSYNC low to /HSYNC high (horizontal sync. pulse)

262 scanlines per frame:
 20 scanlines from /VSYNC high to /BLANK high (top border)
224 scanlines from /BLANK high to /BLANK low (active display)
 14 scanlines from /BLANK low to /VSYNC low (bottom border)
  4 scanlines from /VSYNC low to /VSYNC high (vertical sync. pulse)   

Using 6.293780 MHz pixel clock, 60.05 frames per second

Sega 315-5292 tilemap chip (System 24, Model 1)

656 pixels per scanline:
 69 pixels from /HSYNC high to /BLANK high (left border)
496 pixels from /BLANK high to /BLANK low (active display)
 43 pixels from /BLANK low to /HSYNC low (right border)
 48 pixels from /HSYNC low to /HSYNC high (horizontal sync. pulse)

424 scanlines per frame:
 25 scanlines from /VSYNC high to /BLANK high (top border)
384 scanlines from /BLANK high to /BLANK low (active display)
 11 scanlines from /BLANK low to /VSYNC low (bottom border)
  4 scanlines from /VSYNC low to /VSYNC high (vertical sync. pulse)

Using 16 MHz pixel clock, 57.52 frames per second

I've been doing *tons* of work on the PC-Engine chipset, including tests on several consoles and a Bloody Wolf PCB to see how the VDC operates without the VCE influencing it's timing. I also revamped my PCE development card and will see if the USB glitches can be fixed, which should allow some serious research to begin. Of course in the meantime I can just play games on it which is fine. ;)

Old News (1/11)

I've put together a brief tutorial on doing conversions of FD1094 based games to use decrypted ROM sets and a standard 68000. This explains the steps I went through when working on Alien Storm. I'll add more details and maybe some tools later:

• FD1094 Game Conversion

Also, I've tried to package and clean up all the CPS-2 related development stuff I have that was used for table dumping. Here is the current release:

• cpstool-v1.zip

I recently purchased two Suzuka 8 Hours PCBs (Namco System 2) and will see what can be done about trojaning the M37702-based C68 custom chip used on it. This would be helpful for System 2 and System 21 games. Also I'd like to take a closer look at the alternate type of video hardware this game has, since there seem to be some minor emulation issues in MAME.

Progress on the C70 trojan has temporarily halted. After Guru had run a bunch of tests to help determine what was going on, it appears that the MCU commands used by the C69 trojan are implmented as do-nothing functions in the C70, so it isn't possible to simply upload code or do a memory transfer in the opposite direction to read the internal ROM out. Luckily, Guru has offered to send a NA-2 board for me to experiment with, and hopefully some methods for reading the internal ROM can be derived from the C69 BIOS which may apply to the C70.

Old News (1/4)

Some information is needed about the M37702 MCUs used in various Namco games. If anyone can help, the following needs to be determined:

• Which games use the C71, C72, or C73 chips.
• Which games use the C77 (or higher numbered) chip.

    C68  = System 2 (Final Lap 3, Suzuka 8 Hours), System 21
    C69  = NA-1 (World Court Tennis)
    C70  = NA-2 (Quiztou, Numan Athletics)
    C71  = System 22 (Master TMS32025 DSP BIOS)
    C72  = ?
    C73  = Found on a test board, but used in any games?
    C74  = System 22
    C75  = NB-1 (Nebulas Ray), NB-2 (Out Foxies), System FL
    C76  = System 11 (Xevious 3D/G) 

It looks like all the System 2 games that have C68 do not use the external program ROM socket. Do any System 21 games use it, if such a socket is present?

Updated the chip list based on information from Justin (thanks for the PCB pic!), Kayama, Fujix, Oliver, Guru and R. Belmont.

Old News (1/2)

I've been running tests on the Namco NA-1 hardware over the last few days, and figured out how to dump the internal ROM of the M37702 MCU used in Super World Court. This may be applicable to other NA-1 games, and it may not. Time will tell.

Recently I converted a dead System 18 FD1094-based game (Alien Storm) to use a decrypted ROM set. It works perfectly, and can be done with a ROM replacement and a simple circuit that goes between the 68000 and program ROMs.

News (11/19)

Thanks to a generous donation from Razoola and the CPS2Shock team, I've been given B-boards for the following games: sfzj, csclubj, and sfz3. I have dumped complete table sets from the first two, and am doing tests on the latter. It has no battery, so I can see how the hardware works when the battery-backed SRAM is erased.

With a much larger data set (32 GB) spanning four games, hopefully some patterns will be discovered. I'm still interested in dumping a regional variant for one of the currently dumped games to see what kinds of similarities might exist between the two.

Most likely I will revise and release the tools and specifications for my CPS-2 development setup in the future. Then other people could dump table sets from their games and contribute to this project. There are so many CPS-2 games out there that I couldn't possibly do it all myself, nor would I want to.

I've also done some work mapping out the Model 1 video board and designing an adapter to read bankswitched SMS / MegaTech ROMs. I'll have more information on these topics later on. Congratulations in advance to visitor 400,000! :)