Advice/info about extracting ROM dump from 20-year-old COPS microcontroller?

Your Wavoes are much bigger then mine !!!! ;-)

You must really love this game to want to subject your self to reversing assembly on a defunct and obscure chip like this.

Please let us know how you end up.

hamilton

com/ds/CO

NS sold some of these as mask parts and some as "mask" parts. The mask parts have no readout capability. The "mask" parts are EPROM parts in a windowless plastic package, so they're really OTP. The OTP parts can be read out using most reasonably high-end burners of the era (older BP Micro and Advin programmers for instance). But in a retail product, what chance do you really think you have that this chip is unprotected???

I don't know the chips concerned (and haven't read the datasheets), but on some micros you can attach an external ROM. If you can convince the micro to execute code from that ROM, you can fill it with a routine that dumps out the internal ROM contents on an I/O port.

For example, if you can manage to set a high bit of the program counter you can have an external ROM contents that looks something like this

NOP NOP NOP NOP ...thousands of NOPS... init: MOV x,#0x10000 dumpcode: LD a,[x] ST a,PORTA DEC x BNE dumpcode

The big list of NOPs acts as a landing pad so you just have to abuse the device enough to flip one bit and then you can execute the external code.

Do you know if there were EPROM versions of the device and how they were programmed? You could try the programming interface and see if that gives anything useful.

Theo

The COP's don't have external ROM support. And even if they did, you couldn't write such a program - the only "read from code space" instruction loads a byte from code space within the same 256-byte page you are executing from.

One of the weird things about the COP is that the rom is connected internally by a serial interface to the processor core. These are not high-speed devices!

And I used to think that PICs were weird....

Meindert

PICs /are/ weird (at least, the "real" PICs, not these modern MIPS devices...). The COP8 (don't know so much about the COP4) is not bad from the programmers' viewpoint. It's the implementation that's odd - it's basically a bit serial machine (it's not just the rom access that is serial - the ALU is also serial). An "instruction cycle" takes 10 clock cycles - and some instructions take 4 instruction cycles...

The COP888 is a very different processor. We wrote a C compiler for it and worked on the instruction set when it was developed. My guess is the only folks who might really know if the contents can be dumped are Metalink who made emulators for the COP888 and were very much involved in emulator support technology as the part was developed.

If you get a hex dump I have some internal tools the would go a long way to make it understandable. Contact me offline.

w..

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

An update, though not much to report. I've prodded the chip for several days and the only thing I'm reasonably sure of is that performing the "pulling-D2-low-during-reset" maneuver does seem to put the chip in some kind of special mode, as hinted at by the datasheet. Haven't made much progress beyond that yet.

The reason I'm playing with this old relic is because it's inside the Power Glove, that thing for Nintendo. Yeah it's been a while, but it only gets older every day. We know how to interface it just fine these days, but what it's actually thinking/doing is still a mystery. So there's more to be known. There was a glove list talking about all of this (way back when), but very little pertaining to the actual onboard chip. I'll continue my trial-and-error while I resume searching for more information and people with helpful hints.

Having said all that, mostly I just wanted to post this to make sure to thank everyone for the hints and advice so far... every bit helps. So thank you everyone, I really appreciate it!

Don't know if these will be useful at all.