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

The story so far: I'm trying to reverse engineer a certain much-
maligned gaming peripheral from circa 1990. I've already interfaced
with it the way microcontroller-God intended and worked out the basic
functionality, but I've reached the limits of trial-and-error. There
are hidden features that never saw the light of day, embedded deep in
the firmware. I can't blackbox them. So I did the only reasonable
thing left to do and tore this thing's brain out!

This leaves me with a 44-pin PLCC-flavored COP888CL (http://
www.national.com/ds/CO/COP888CL.pdf) splayed out on my solderless
breadboard. I've read some encouraging (http://www.national.com/ms/CN/
CN-7.pdf) documents (http://www.national.com/an/AB/AB-4.pdf) which
suggest that massaging a ROM dump out of it (that sounded bad) could
be trivial.

Trouble is, those two documents refer to COP400 family devices, so I
assume it's invalid for my COP888. Also, some closer inspection of the
COP888 datasheet reveals that "Care must be exercised with the D2 pin
operation. At RESET, the external loads on this pin must ensure that
the output voltages stay above 0.8 Vcc to prevent the chip from
entering special modes." Ok, that might be the way to access a "test
mode" similar to the COP400... But there's no further mention anywhere
of what these modes may be, or how to interact with them. Argh.

So it seems to me that there must be some way, somehow, of dumping
this chip's onboard ROM. I mean they had to verify it at least once at
the factory, right? And there are references to special modes on this
chip, and even explicit instructions for doing what I want to do only
with an ancestor chip. And that's where I am right now. I'm about to
solder on an additional 8 lines to the D port so I can blindly try
various combinations of these instructions in the hopes that I'll hit
some dumb luck. But this is going to take a while even if I don't make
any mistakes.

I get the feeling that this is the kind of thing I could spend a
couple weeks on, yet maybe someone out there worked extensively with
this line many years ago and knows exactly what to do off the top of
their head or something. Or maybe there are faster/easier ways to
pursue this.

Any thoughts? :)

On 5/19/2010 6:15 PM, G. Edward wrote:
> The story so far: I'm trying to reverse engineer a certain much-
> maligned gaming peripheral from circa 1990. I've already interfaced
> with it the way microcontroller-God intended and worked out the basic
> functionality, but I've reached the limits of trial-and-error. There
> are hidden features that never saw the light of day, embedded deep in
> the firmware. I can't blackbox them. So I did the only reasonable
> thing left to do and tore this thing's brain out!
>
> This leaves me with a 44-pin PLCC-flavored COP888CL (http://
> www.national.com/ds/CO/COP888CL.pdf) splayed out on my solderless
> breadboard. I've read some encouraging (http://www.national.com/ms/CN/
> CN-7.pdf) documents (http://www.national.com/an/AB/AB-4.pdf) which
> suggest that massaging a ROM dump out of it (that sounded bad) could
> be trivial.
>
> Trouble is, those two documents refer to COP400 family devices, so I
> assume it's invalid for my COP888. Also, some closer inspection of the
> COP888 datasheet reveals that "Care must be exercised with the D2 pin
> operation. At RESET, the external loads on this pin must ensure that
> the output voltages stay above 0.8 Vcc to prevent the chip from
> entering special modes." Ok, that might be the way to access a "test
> mode" similar to the COP400... But there's no further mention anywhere
> of what these modes may be, or how to interact with them. Argh.
>
> So it seems to me that there must be some way, somehow, of dumping
> this chip's onboard ROM. I mean they had to verify it at least once at
> the factory, right? And there are references to special modes on this
> chip, and even explicit instructions for doing what I want to do only
> with an ancestor chip. And that's where I am right now. I'm about to
> solder on an additional 8 lines to the D port so I can blindly try
> various combinations of these instructions in the hopes that I'll hit
> some dumb luck. But this is going to take a while even if I don't make
> any mistakes.
>
> I get the feeling that this is the kind of thing I could spend a
> couple weeks on, yet maybe someone out there worked extensively with
> this line many years ago and knows exactly what to do off the top of
> their head or something. Or maybe there are faster/easier ways to
> pursue this.
>
> Any thoughts? :)

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

On May 19, 8:15=A0pm, "G. Edward" <bsdcolo...@gmail.com> wrote:
>
> This leaves me with a 44-pin PLCC-flavored COP888CL (http://www.national.=
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???

G. Edward <bsdcolonel@gmail.com> wrote:
> I get the feeling that this is the kind of thing I could spend a
> couple weeks on, yet maybe someone out there worked extensively with
> this line many years ago and knows exactly what to do off the top of
> their head or something. Or maybe there are faster/easier ways to
> pursue this.

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

Theo Markettos wrote:
> G. Edward <bsdcolonel@gmail.com> wrote:
>> I get the feeling that this is the kind of thing I could spend a
>> couple weeks on, yet maybe someone out there worked extensively with
>> this line many years ago and knows exactly what to do off the top of
>> their head or something. Or maybe there are faster/easier ways to
>> pursue this.
> 
> 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!

"David Brown" <david.brown@hesbynett.removethisbit.no> wrote in message
news:kvqdncCU-twFgWvWnZ2dnUVZ8mmdnZ2d@lyse.net...
> 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

On 21/05/2010 08:29, Meindert Sprang wrote:
> "David Brown"<david.brown@hesbynett.removethisbit.no>  wrote in message
> news:kvqdncCU-twFgWvWnZ2dnUVZ8mmdnZ2d@lyse.net...
>> 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....
>

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

"G. Edward" wrote:
> 
> Any thoughts? :)

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: news@netfront.net ---

On May 19, 7:15=A0pm, "G. Edward" <bsdcolo...@gmail.com> wrote:
> Any thoughts? :)

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!

G

George Whiteside wrote:

> On May 19, 7:15 pm, "G. Edward" <bsdcolo...@gmail.com> wrote:
>> Any thoughts? :)
> 
> 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!
> 
> G

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

<<http://infiniteunity3d.com/nintendo-power-glove-arduino-and-unity3d/>>
<<http://www.angelfire.com/ok2/stepinto/PowerGlovePage.html>>

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************