From: Theo Markettos on
G. Edward <bsdcolonel(a)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
From: David Brown on
Theo Markettos wrote:
> G. Edward <bsdcolonel(a)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!
From: Meindert Sprang on
"David Brown" <david.brown(a)hesbynett.removethisbit.no> wrote in message
news:kvqdncCU-twFgWvWnZ2dnUVZ8mmdnZ2d(a)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


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