I dumped the ROM from Entex Space Invaders. After I type up the wiring diagram, I'll post the link.
I bought one unit a few months ago and decapped the COP444, but the die stuck to the plastic and I had to really torch it to get it off. That toasted the passivation layer, so I couldn't get pics of the top metal layer. I Whinked the die and the results were good, but I couldn't see the ROM bits, so I bought another game to try again. In the meantime, Lord Nightmare posted the app notes on dumping the chip electronically, so I tried that.
I actually took a much simpler route than the app note describes- I put the chip on a breadboard with power and a cap and resistor for the oscillator, used a couple of AA batteries and a couple of resistors to enter ROM dump test mode, then clipped on a Saleae Logic 16 to capture the bytes.
Since the game uses the L pins to drive LEDs, they are set up as outputs, but it also uses the SK pin as an output, so that didn't output the byte valid signal that you get if you follow the app note. But it was very easy to track the bytes outputted and sample them in the middle of the bit times.
The entire 2K gets dumped every 40mS or so, but there's no indication of the beginning of the dump- it just rolls from 7FF to 000 and keeps going. Since I had to enter test mode while the game was running to make sure the L pins were outputs, I had no idea at what address the dump started. I captured for about 2 minutes and verified that all of the 2K sections (about 3000 of them) were identical. The game uses 6 AA batteries, but the datasheet says Vcc is 5V, so I dumped at both voltages and got the same results.
Because the chip breaks ROM up into 32 pages of 64 bytes, it turned out to be pretty easily to figure out the 64-byte boundaries; many of the pages are padded out with zeroes. And the chip has a quirk that requires the first instruction executed after reset (at address $000) to be a CLRA ($00), so I looked for a zero at 64-byte offsets. There were only 5 possibilities, so I used unidasm to figure out which one was most logical for a reset routine (looking for RAM initialization, setting the L pins as output, etc).
That's where I got confused- there were lots of "Invalid" messages in the disassembly. After a bit of investigation, I figured out that the COP444 disassembler imposes the same 1K ROM limits as for the other COP chips, although the COP444 has 2K of ROM. That was causing various instructions like JP, JSR, LDD, XAD and LBI to say the operand was invalid. I patched that up and figured out which 0 was the start of the ROM and shifted the bytes to bring it to the front.
