Old News (11/07)

I've updated SMS Plus to version 1.5 to fix a save-state loading bug, and to add partial support for the Korean game Janggun-ui Adeul. Thanks to Akop Karapetyan for the bug report and Omar Cornut for technical information about the game.

• sp-110710-src.zip Source code
• sp-110710-win.zip Windows binary

I've also updated the PLA disassembler to fix a bug that was causing it to crash; as it turns out some device programmers do not specify a pin count in the JED file. Now the pin count is inferred from the fuse count. Thanks to the Dumping Union, we found it is possible to dump CK2605 PLAs as PLS153s, which results in an overdump as the PLS153 has more array rows than the CK2605 does.

So I added an option to trim these rows and convert a PLS153 fusemap back to a CK2605 fusemap. The newest version is here:

• plad-081710.zip (Windows binary and source included)

Old News (8/17)

I've finished a tool for disassembling CK2605, PLS153, and PLS173 fusemaps:

• plad-08172010.zip (Windows binary and source included)

You can also recompile the source code to target other devices, for example fitting a CK2605 or PLS153 design into a GAL16V8, or a PLS173 design into a GAL22V10D. This allows these older parts to be replaced with inexpensive modern equivalents.

Of course these PLA devices have a different internal architecture from PALs, so not every design can fit. A PLA has a global pool of AND gates that any OR gate can include, whereas a PAL has a fixed set of AND gates per OR gate. It's possible for a PLA to specify many AND gates for any one input, and for multiple OR gates to share multiple AND gates from the pool.

Here's an example of how the tool works. Shinobi uses a Signetics CK2605 PLA for part 315-5214 which implements glue logic for the Z80. Invoking the tool like so will disassemble the fusemap using the assigned pin names and produce a CUPL file that can be used with WinCUPL:

    > plad 315-5214.jed -signal a15,a14,a7,a6,mreq,iorq,m1,mrd,wr,
    > busy,zd7,samoe,prgoe,bnkck,updcs,fmcs,ramcs,cmdck > output.pld

Device    pls153;

pin 1      = a15;   
pin 2      = a14;   
pin 3      = a7;    
pin 4      = a6;    
pin 5      = mreq;  
pin 6      = iorq;  
pin 7      = m1;    
pin 8      = mrd;   
pin 9      = wr;    

pin 11     = busy;  
pin 12     = zd7;   
pin 13     = samoe; 
pin 14     = prgoe; 
pin 15     = bnkck; 
pin 16     = updcs; 
pin 17     = fmcs;  
pin 18     = ramcs; 
pin 19     = cmdck; 

// global and gate pool
and_node00 = !a15 & !mreq;
and_node01 =  a15 & !a14 & !mreq;
and_node02 =  a15 &  a14 & !mreq;
and_node03 = !a7 & !a6 & !iorq &  m1;
and_node04 = !a7 &  a6 & !iorq &  m1;
and_node05 =  a7 & !a6 & !iorq &  m1 & !wr;
and_node06 = !busy;
and_node07 =  a7 &  a6 & !iorq &  m1;

// assign and gate outputs to or gate inputs
or_node02  = and_node06;
or_node03  = and_node01;
or_node04  = and_node00;
or_node05  = and_node04;
or_node06  = and_node05;
or_node07  = and_node03;
or_node08  = and_node02;
or_node09  = and_node07;

// assign polarity and output levels
 wr        = 'b'1;
 busy      = 'b'1;
!zd7       = or_node02;
!samoe     = or_node03;
!prgoe     = or_node04;
!bnkck     = or_node05;
!updcs     = or_node06;
!fmcs      = or_node07;
!ramcs     = or_node08;
!cmdck     = or_node09;

// assign pin buffer enables
wr.oe      = 'b'0;
busy.oe    = 'b'0;
zd7.oe     =  a7 & !a6 & !iorq &  m1 & !mrd;
samoe.oe   = 'b'1;
prgoe.oe   = 'b'1;
bnkck.oe   = 'b'1;
updcs.oe   = 'b'1;
fmcs.oe    = 'b'1;
ramcs.oe   = 'b'1;
cmdck.oe   = 'b'1;

 wr        = 'b'1;
 busy      = 'b'1;
wr.oe      = 'b'0;
busy.oe    = 'b'0;

Later I will add an option for more compact output that folds the AND and OR gate definitions together. Keeping them split makes it clear which resources each pin uses, but it does decrease readability. And I plan to merge the 22V10 disassembler and this tool together too.

Old News (7/19)

I've been working on the prototype PAL reader and finally hit a development milestone, I was able to dump two PAL16R4s through an automated process. Unlike dumping combinatorial PALs, registered PALs have no straightforward reading procedure.

This is where the onboard processing power of the 20 MHz 68000 and the large amount of work RAM came in handy. The program starts by resetting the device and mapping other states that are connected to the reset state. While it does this, it builds up a list of state transition values so that it can search states that are more deeply linked. All the states and all their transitions are explored recursively, and in the end the state machine has been fully exercised and all possible outputs are recorded. The processing involved is moderately complex and requires efficient access to large data structures and multi-dimesional arrays in RAM, which the 68000 addressing modes are well suited for. In fact, a 68020 would do a better job but sadly it appears Freescale no longer makes them. As much as I'd like to put a 68060 in this thing it has to stay inexpensive.

The next step is to generalize the algorithm so that 16R6 and 16R8 PALs can be read, and then support 16V8s. At that point I think all registered PALs within those device families could then be dumped and preserved. It will be possible to support registered 22V10 designs in some configurations, but any device that can be programmed to hide its internal state has the potential to be undumpable, such as the 18CV8 which has buried registers.

The final step is to develop analysis software that can examine a registered PAL dump and turn it back into logic equations for recompilation and/or retargeting. Already it's clear that this step will produce results that will be functionally equivalent but certainly not representationally equivalent, and determining what the original registered structure was (FIFO, latch, counter, etc.) will likely be impossible. It will be up to the user to make a judgment call about the original implementation. This is more of a documentation issue than anything else.

It's great to finally be at this point because reading registered PALs was one of the two 'big' PAL problems that I've been working on for about 3 years now, the other being feedback analysis. Getting this to work also validated some of the design decisions that went into the prototype PAL dumper, now I know which features to keep and which to drop for the next version.

In other news I have finished a CK2605/PLS153 disassembler and am working on a CK2605 to PLS153 fusemap conversion tool. I'll try to get those released shortly.

Old News (6/20)

I've been investigating Free Kick, an arcade game that uses a security module in place of the CPU. Currently the bootleg version is emulated in MAME.

Photos of a disassembled module show four, possibly five chip dies on one side and what is likely a Fujitsu MB3771 on the other side. One of the dies has an exceptionally high pin count and connects directly to the Z80 related pins, so it may be a Z180 (HD647180). Because of these direct connections there are probably no buffers in place to isolate internal bus activity from the outside world. However monitoring the data and control bus has not yielded any clear results.

The module has an internal CR2032 battery that powers some SRAM which contains the game's program code. If the battery dies the module still functions and will print a "PROGRAM ERROR" message, so there must be internal ROM (the HD647180 has 16K of built-in ROM) that contains a start-up program which validates the SRAM before passing control to it.

Typically for high score retention, the work RAM of a game is powered by a battery. Free Kick has such a battery, but it only connects to the module and not to any of the RAMs. If you consider that the bootleg games replace the security module with a daughterboard that has an EPROM for the program code and a 8Kx8 RAM, it seems likely that the work RAM is inside the module and is powered by the external battery. Since the power supplies are split across two batteries, I don't think the work RAM and program code RAM are the same chip but are two separate ones.

When the module is removed from the board a number of pins have measureable voltages on them:

    Pin 22 (INT#)    = 2.74V
    Pin 23 (NMI#)    = 2.74V
    Pin 30 (WAIT#)   = 2.74V
    Pin 12 (CLK#)    = 2.74V
    Pin 48 (RSTOUT#) = 2.74V

All Z80 address and data pins as well as RD#, WR#, MREQ#, and what I believe is IORQ# measure 0.009V which could be due to some kind of leakage, say from the program code RAM through the ESD protection diodes of the Z180 data and address bus.

The pin that should be M1# is used to directly set a flip-flop which triggers the 120 Hz video interrupt. If this signal was a combination of IORQ# and M1# then that would indicate an interrupt acknowledge cycle and this connection would make sense. If it is just M1# directly then the interrupt acknowledge won't work as intended, instead any opcode fetch after the interrupt flip-flop has been set will clear it. It's hard to tell if that is intentional or not. For some reason one bootleg drives this same signal when a specific memory range is read or written which does not seem like compatible behavior.

I made a circuit that requested the bus using the BUSREQ# and BUSACK# pins, and was able to halt the CPU while it ran the internal ROM program. In addition the WAIT# input is usable as it connects to the four SN76489s on the main board to cause wait states to lengthen PSG writes. I think these can be used to probe the internal memory space of the module, or if that failed, log internal bus activity. I'm developing some hardare to assist with that but it is still at an early phase.

Assistance needed

If anybody has a bootleg of Free Kick or Counter Run with a daughterboard, I need to get some connections verified by using the continuity test function of a multimeter. It doesn't matter if the game works or not, and you don't have to power it up. Any bootleg will work, there are several different types. Please contact me if you can help.

Old News (6/10)

I finished most of the technical documentation and schematics for Royal Queen. Kale did some fantastic work getting it emulated!

• Royal Queen Hardware Notes
• Royal Queen Schematics (PNG, 200K)

Between this and the System E efforts it has been a fascinating experience to figure out how a board works by making your own schematics and piecing everything together chip-by-chip. It's a completely different perspective from doing pure software testing.

I've been working on a new 512K EPROM emulator for future work with several 68020-based Atari boards and an upcoming trojaning effort. The PCB design is finished, so the next step is to get the boards fabricated, assembled, and write the client software. I'll have an update about that later on.

I also trojaned the internal ROM from the CPU module used by "Pinkiri 8". This game uses an external program ROM that is not encrypted (like Lucky Girl was), so I used my 32K ROM emulator to run a small program that relocated to work RAM and copied the internal 16K ROM of the HD647180 CPU to the emulator RAM, and then saved that RAM to disk. The only hard part was probing around the board to find the circuit that generated the memory write strobe, and after that it was pretty easy.
UPDATE: Turns out this method worked for three related boards Brian Troha sent earlier, so now those are all dumped too!

Old News (5/30)

I recently got a Sega "System E" arcade PCB (Tetris) and wrote some documentation for it:

• System E Hardware Notes

• Royal Queen Schematics (PNG)

And finally, here is a maintenance release of SMS Plus for the new decade. Both 32K and 8K-banked Korean games are now supported thanks to information and ROM dumps from Omar Cornut.

• SMS Plus (Windows binary)
• SMS Plus (Source code)

Old News (2/14)

New PAL analysis board

The hardware consists of the following:

• Freescale 68EC000 CPU @ 20 MHz
• 1MB work RAM (can be used as ROM overlay)
• 512K Flash (boot loader)
• 128K page-mode EEPROM (non-volatile storage)
• Support for dumping 20 and 24-pin DIP PALs
• Support for dumping 20 and 28-pin PLCC PALs
• Lattice ISP programming interface (for ispGAL22V10C)
• High speed USB interface
• Expansion port

The software for dumping 20/24-pin DIP PALs and 28-pin PLCC PALs works, and some of the basic ISP functions for entering ISP mode and reading the device ID also work. The bootloader allows software to be uploaded to RAM and has functions for memory upload/download, remote soft-reset, and diagnostics. I used a 68EC000 as it has an 8-bit data bus mode which simplified the process of manual routing for such a large 2-layer board. Several 22V10s were used to implement an address decoder, clock generator, programmable wait state generator (not unlike the one used in the System 16B boards), and I/O strobes for the PAL interface hardware. Needless to say with such a fast CPU and available RAM this system is very convenient to program for.

Currently I'm working on an update to jed2cupl which will generate EPROM-type dumps from JED files. It will allow for virtual programming and dumping of a device based on CUPL code without having to program any real chips. This will be used to identify more edge cases for PAL analysis and to further validate the output of WinCUPL and the PAL dump analysis tool. I've also cleaned up and generalized the source quite a bit in anticipation of future 16V8 device support.

News (1/18)

2010 already

CUPL is a language used to describe the logic implemented in a PAL or GAL device, similar to other ones like ABEL and SNAP. Atmel offers a free compiler called WinCUPL which targets popular devices such as the 16V8 and 22V10.

WinCUPL is a great program but was written quite a while ago and has a number of unusual quirks, perhaps related to using it with Windows XP. For example it commonly crashes with a "Automation error", something which you can remedy by saving your file with Ctrl+S after typing every line or two. I suspect it has something to do with accumulating too much Undo information (a feature which also does not work in XP) and trashing memory as a result.

Editor issues aside, a bigger problem is that the statements which you write can become malformed during compilation, for example assigning an output enable term to a field may not result in all field elements having the same output enable setting. Problems like these are hard to track down and the ".sim" file which shows intermediate results isn't easy to read due to the lack of formatting.

To resolve this issue, I developed a JEDEC to CUPL converter for 22V10 fusemaps. The output is directly compilable by WinCUPL and explicitly states all settings where possible to minimize the amount of guesswork WinCUPL has to do. All GAL22V10 features relating to combinatorial and registered modes are fully supported, including the electronic signature field (UES data).

• jed2cupl-011810.zip (Windows binary and source code)

The JEDEC fusemap loading may be too closely tied to WinCUPL's output, so if anyone has fusemaps written by another application that do not work correctly please let me know. I may add 16V8 support in the future, though oddly enough it is more complicated than the 22V10. Ideally I'd like jed2cupl to become a modern replacement for the old jed2eqn program National Semiconductor developed in the early 90's.

Previously I had been working on an MP3 player for a project which unfortunately ran past the deadline and was not finished. It was the first time I had dealt with getting consistently bad parts from a single vendor, and was a good lesson in second-sourcing components as well as evaluating their reliability. I wrote a lot of code for file management, browsing, and a GUI with a variable width font system for LCD displays. On the hardware side I came up with circuitry for mixing 3.3V and 5V peripherals on a SPI bus and implemented a serial FRAM for configuration and a SD card interface for MP3 storage. Time allowing, I'll try to find suitable replacement components and put the finished design information online.