Extract program from old mask-ROM 80C51?

I have a mask ROM 80C51 in an old computer, made 1992.  The top of the 44 pin
PLCC says:

Philips logo
0290,031-01
WP J399
223380
DfD9240V6 YU
(R) (C) INTEL 1980
(R) PHILIPS 1989

The schematic tells me it's an 80C51, but no other part numbers. 0290,031-01
is the customer's (Acorn's) part number.  I don't know what sort of 8051 it
is inside.  The clock line XTAL1 is driven directly from another chip at
12MHz (according to the technical manual).

Anyone know what flavour of 80C51 it might be?

This was before the days of security fuses and so on, wasn't it?  Is there
any chance of being able to read out the program, or is it a depackage and
stare at the metal layers under a microscope job?

Thanks
Theo

"Theo Markettos" <theom+news@chiark.greenend.org.uk> wrote in message 
news:5xt*HAPns@news.chiark.greenend.org.uk...
>I have a mask ROM 80C51 in an old computer, made 1992.  The top of the 44 
>pin
> PLCC says:
>
> Philips logo
> 0290,031-01
> WP J399
> 223380
> DfD9240V6 YU
> (R) (C) INTEL 1980
> (R) PHILIPS 1989
>
> The schematic tells me it's an 80C51, but no other part numbers. 
> 0290,031-01
> is the customer's (Acorn's) part number.  I don't know what sort of 8051 
> it
> is inside.  The clock line XTAL1 is driven directly from another chip at
> 12MHz (according to the technical manual).
>
> Anyone know what flavour of 80C51 it might be?
>
> This was before the days of security fuses and so on, wasn't it?  Is there
> any chance of being able to read out the program, or is it a depackage and
> stare at the metal layers under a microscope job?
>
> Thanks
> Theo

The original 8051 had a security bit.
Would definitely think a masked part set that bit, but you never know.
Any 8051 programmer should be able to read it, if bit not set.

>
> The schematic tells me it's an 80C51, but no other part numbers. 
> 0290,031-01
> is the customer's (Acorn's) part number.  I don't know what sort of 8051 
> it
> is inside.  The clock line XTAL1 is driven directly from another chip at
> 12MHz (according to the technical manual).
>
> Anyone know what flavour of 80C51 it might be?
>
> This was before the days of security fuses and so on, wasn't it?  Is there
> any chance of being able to read out the program, or is it a depackage and
> stare at the metal layers under a microscope job?
>
> Thanks
> Theo

Try reading it repeatedly, slowly reducing the Vcc..... 

On Sep 24, 8:19 am, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> I have a mask ROM 80C51 in an old computer, made 1992.  The top of the 44 pin
> PLCC says:
>
> Philips logo
> 0290,031-01
> WP J399
> 223380
> DfD9240V6 YU
> (R) (C) INTEL 1980
> (R) PHILIPS 1989
>
> The schematic tells me it's an 80C51, but no other part numbers. 0290,031-01
> is the customer's (Acorn's) part number.  I don't know what sort of 8051 it
> is inside.  The clock line XTAL1 is driven directly from another chip at
> 12MHz (according to the technical manual).
>
> Anyone know what flavor of 80C51 it might be?
>
> This was before the days of security fuses and so on, wasn't it?  Is there
> any chance of being able to read out the program, or is it a depackage and
> stare at the metal layers under a microscope job?
>
> Thanks
> Theo

PLCC44 was a very common package for the 8051 15 years ago.  Odds are
the pin-out will match what you find in the Intel data sheet.

Dumping the code isn't that tough.  Basically you assert 'EA' to use
your own code, which instantly jumps way up in memory (0x8000) and
turns EA off.  Then a routine in your code dumps the CDATA at 0x0000.

LittleAlex <alex.louie@email.com> wrote:
> PLCC44 was a very common package for the 8051 15 years ago.  Odds are
> the pin-out will match what you find in the Intel data sheet.

Thanks, yes it does (found a generic):
http://www.nxp.com/acrobat_download/datasheets/8XC51_8XC52_6.pdf

> Dumping the code isn't that tough.  Basically you assert 'EA' to use
> your own code, which instantly jumps way up in memory (0x8000) and
> turns EA off.  Then a routine in your code dumps the CDATA at 0x0000.

Is that even if the security bits are set?  The above datasheet says there's
a 'Verify code data' mode which is entered by setting control and port pins
to various values.  But it claims not to work if the security bits are blown
(or the XNOR matrix is set).

I was hoping there was a nice serial protocol, but it looks like I'll have
to unsolder it to try this...

Theo

On Sep 24, 1:13 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> LittleAlex <alex.lo...@email.com> wrote:
> > PLCC44 was a very common package for the 8051 15 years ago.  Odds are
> > the pin-out will match what you find in the Intel data sheet.
>
> Thanks, yes it does (found a generic):http://www.nxp.com/acrobat_download/datasheets/8XC51_8XC52_6.pdf
>
> > Dumping the code isn't that tough.  Basically you assert 'EA' to use
> > your own code, which instantly jumps way up in memory (0x8000) and
> > turns EA off.  Then a routine in your code dumps the CDATA at 0x0000.
>
> Is that even if the security bits are set?  The above datasheet says there's
> a 'Verify code data' mode which is entered by setting control and port pins
> to various values.  But it claims not to work if the security bits are blown
> (or the XNOR matrix is set).
>
> I was hoping there was a nice serial protocol, but it looks like I'll have
> to unsolder it to try this...
>
> Theo

The security bits (IIRC) prevent the code from being dumped by a
device programmer.  I can't imagine that they can prevent the 'movc
acc, @a+dptr' opcode from working without breaking a LOT of code.

LittleAlex <alex.louie@email.com> wrote:

>The security bits (IIRC) prevent the code from being dumped by a
>device programmer.  I can't imagine that they can prevent the 'movc
>acc, @a+dptr' opcode from working without breaking a LOT of code.

On at least some Atmel processors a security bit causes the EA pin to be
latched on reset ensuring that external code running from reset can not
access internal code. 
-- 

On Sep 29, 1:42 pm, nospam <nos...@please.invalid> wrote:
> LittleAlex <alex.lo...@email.com> wrote:
> >The security bits (IIRC) prevent the code from being dumped by a
> >device programmer.  I can't imagine that they can prevent the 'movc
> >acc, @a+dptr' opcode from working without breaking a LOT of code.
>
> On at least some Atmel processors a security bit causes the EA pin to be
> latched on reset ensuring that external code running from reset can not
> access internal code.
> --

Clever...  Theo can hope his processor was made before they figured
that one out.

>> On at least some Atmel processors a security bit causes the EA pin to be
>> latched on reset ensuring that external code running from reset can not
>> access internal code.

>Clever...  Theo can hope his processor was made before they figured
>that one out.

A technique that can be used with 8051s that have an external bus and
execute program code from any address above the top of internal ROM
is to fill the external address space with NOPs which lead up to a little
program that does a soft-reset (clear stack etc.) and then dumps the
internal rom area via MOVC - the idea is to start in normal (internal ROM
mode) and then get it to crash and execute "randomly" - bounce the
power, zap it with a very brief hv charge (it helps if you are prepared
to sacrifice a few devices) etc. - If you are lucky, you will eventually
get it to launch your code - be prepared to make lots of attempts, and
try varying timing etc. Consider building a jig to do it (Monitor EA and
-PSEN and hit it until you see external code active).

YMMV - newer parts take steps to block this, but if yours is older, it
might work.

Regards,


--
dave06a@    Low-cost firmware development tools:  www.dunfield.com
dunfield.   Classic computer collection:  www.classiccmp.org/dunfield
com