microcontroller ROM copy trouble ?
robb
(Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
with a (NEC 23256AC) ROM chip.
i removed the ROM chip (NEC D23256AC) and copied it using a ROM
programmer, then i programmed that ROM image onto a (ST M27C256B)
EPROM
i put the new ROM (ST) onto the microcontroller board and i
t does **NOT** work ... a no go.
i removed the ROM (ST) and put the ROM (NEC) back and works like
a charm... no problems
i download ROM images from both (NEC) and (ST) and compare in
file compare program which declares them as exactly the same
?????
HELP please?? any ideas what is going on here.
the only funny thing about the microboard (that i know) is that
the ROM memory socket has (pin1) tied to (pin 27) that is Addr15
(pin 1) and Addr 14 (pin 27) ??? do not know why ????
thanks for any help i am stuck again,
robb
Rich Webb
> I have a working (ie. tested) microcontroller board uses a
> (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> with a (NEC 23256AC) ROM chip.
>
> i removed the ROM chip (NEC D23256AC) and copied it using a ROM
> programmer, then i programmed that ROM image onto a (ST M27C256B)
> EPROM
>
> i put the new ROM (ST) onto the microcontroller board and i
>
> t does **NOT** work ... a no go.
> i removed the ROM (ST) and put the ROM (NEC) back and works like
> a charm... no problems
>
> i download ROM images from both (NEC) and (ST) and compare in
> file compare program which declares them as exactly the same
> ?????
>
> HELP please?? any ideas what is going on here.
One possibility is that the speed grade of the EPROM is slower than
that of the original ROM chip. There should be a couple of digits
after a dash on each chip, like -12 or -70. What are they?
robb
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
news:13n80ke...@corp.supernews.com...
> robb wrote:
> > I have a working (ie. tested) microcontroller board uses a
> > (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> > with a (NEC 23256AC) ROM chip.
> >
> > i removed the ROM chip (NEC D23256AC) and copied it using a
ROM
> > programmer, then i programmed that ROM image onto a (ST
M27C256B)
> > EPROM
> >
> > i put the new ROM (ST) onto the microcontroller board and
> >
> > HELP please?? any ideas what is going on here.
>
> One possibility is that the speed grade of the EPROM is slower
than
> that of the original ROM chip. There should be a couple of
digits
> after a dash on each chip, like -12 or -70. What are they?
>
Thanks for reply Rich,
I have a variety of ROMs i have tested
i have a set of uv eraseable and OTP
both of the 10 12 15 variety (ie. 100/120/150 ns)
the original equipment is from 1987-89 ...so i do not think it is
terribly fast,
the clock is 12 Mhz. I could not locate an exact datasheet for
the (NEC D23256AC 016 8437k9) but the one 23256ac i did find
was rated at 150 ns
i tried to match or better that number.
faster than spec chip is OK i presume ?
the 8031 processor has a Time of Address Valid to Instruction
Read Valid of 300 ns (max value)
do any of these numbers sound close (bad) ?
****And more info****
... There is no funny business with 8031 processor because i was
able to sub in a **brand new/ not used ** Atmel 8031 processor in
place of the original 8031 and worked great ???? with the
original ROM if that means anything
Thanks again for your help i am really stuck here and wondering
if there is some security measure installed on the original ROM
but that just seems unlikely ???? unless that funny stuff with
the Address line has something to do with it ???
but my reconing on that is.... if i have the same raw image on
the two ROM chips then the processor sould see no difference in
the data it reads from either chip using the same interface to
those two chips ? yes /no /maybe ?
Thanks again for help Rich,
robb
robb
"robb" <so...@where.on.net> wrote in message
news:13n7v4r...@corp.supernews.com...
> I have a working (ie. tested) microcontroller board uses a
> (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> with a (NEC 23256AC) ROM chip.
>
>
> Copied the old ROM to a new chip, verified new chip
> ** but** new ROM chip does not work
>
Thinking there might be some MCU 8031 funny business/security i
swapped a ** brand new / not used** (Atmel 80C31x2-UM) in place
of original 8031 and works like a charm...
........with the **Original ROM ONLY ***
could really use some ideas , i am stumped,
robb
TT_Man
>> the original equipment is from 1987-89 ...so i do not think it is
> terribly fast,
> the clock is 12 Mhz. I could not locate an exact datasheet for
> the (NEC D23256AC 016 8437k9) but the one 23256ac i did find
> was rated at 150 ns
> i tried to match or better that number.
>
> faster than spec chip is OK i presume ?
>
> the 8031 processor has a Time of Address Valid to Instruction
> Read Valid of 300 ns (max value)
>
> do any of these numbers sound close (bad) ?
My guess is that here is a subtle pin difference between the eproms... speed
is definitely NOT an issue.
Rich Webb
>I could not locate an exact datasheet for
> the (NEC D23256AC 016 8437k9) but the one 23256ac i did find
> was rated at 150 ns
> i tried to match or better that number.
>
> faster than spec chip is OK i presume ?
>
> the 8031 processor has a Time of Address Valid to Instruction
> Read Valid of 300 ns (max value)
>
> do any of these numbers sound close (bad) ?
It *looks* like the memory chips are faster than the processor, so
that may not be the issue. The original was probably 160 ns.
The note at the back of the TMM23256P data sheet (I'm guessing that
is the one that you also found) does reference a required initialization
sequence. If you can, scope out which of the two sequences are used
and perhaps determine whether that sequence is disturbing the alternate
chip in some way.
--
Rich Webb Norfolk, VA
John Fields
wrote:
---
If the same image is programmed into both devices and they both have
identical pinouts, then I'd look at I/O level differences.
--
JF
Eeyore
John Fields wrote:
> If the same image is programmed into both devices
You didn't read what he wrote did you ?
He has an *external* ROM.
Graham
gqrxz...@ftml.net
> I have a working (ie. tested)microcontrollerboard uses a
> (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> with a (NEC 23256AC) ROM chip.
>
> i removed the ROM chip (NEC D23256AC) and copied it using a ROM
> programmer, then i programmed that ROM image onto a (ST M27C256B)
> EPROM
>
>
> t does **NOT** work ... a no go.
> i removed the ROM (ST) and put the ROM (NEC) back and works like
> a charm... no problems
>
> i download ROM images from both (NEC) and (ST) and compare in
> file compare program which declares them as exactly the same
> ?????
>
> HELP please?? any ideas what is going on here.
>
> the only funny thing about the microboard (that i know) is that
> the ROM memory socket has (pin1) tied to (pin 27) that is Addr15
> (pin 1) and Addr 14 (pin 27) ??? do not know why ????
>
> thanks for any help i am stuck again,
> robb
Been there (or somewhere similar). Is Vpp connected? (to Vcc?).
In the case I saw EPROM's programmed & verified (in programmer),
but the output disappeared almost instantly in the real circuit
where Vpp wasn't connected (to Vcc). (2716's).
Ryan Weihl
> On Thu, 27 Dec 2007 14:28:49 -0500, "robb" <so...@where.on.net>
> wrote:
>
> > I have a working (ie. tested) microcontroller board uses a
> > (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> > with a (NEC 23256AC) ROM chip.
> >
> > i removed the ROM chip (NEC D23256AC) and copied it using a ROM
> > programmer, then i programmed that ROM image onto a (ST M27C256B)
> > EPROM
> >
> > i put the new ROM (ST) onto the microcontroller board and i
> >
> > t does NOT work ... a no go.
> > i removed the ROM (ST) and put the ROM (NEC) back and works like
> > a charm... no problems
> >
> > i download ROM images from both (NEC) and (ST) and compare in
> > file compare program which declares them as exactly the same
> > ?????
> >
> > HELP please?? any ideas what is going on here.
> >
> > the only funny thing about the microboard (that i know) is that
> > the ROM memory socket has (pin1) tied to (pin 27) that is Addr15
> > (pin 1) and Addr 14 (pin 27) ??? do not know why ????
> >
> > thanks for any help i am stuck again,
>
> ---
> If the same image is programmed into both devices and they both have
> identical pinouts, then I'd look at I/O level differences.
if memory serves me right the 27... is a progamable chip and you
apply a programming voltage to a certain pin. To read that chip
you must change "that" pin to hi or low.
I got on datasheets here.
--
robb
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
> robb wrote:
> >I could not locate an exact datasheet for
> > the (NEC D23256AC 016 8437k9) but the one 23256ac i did
find
> > was rated at 150 ns
> > i tried to match or better that number.
>
so
> that may not be the issue. The original was probably 160 ns.
>
> The note at the back of the TMM23256P data sheet (I'm guessing
that
> is the one that you also found) does reference a required
initialization
> sequence. If you can, scope out which of the two sequences are
used
> and perhaps determine whether that sequence is disturbing the
alternate
> chip in some way.
>
Thanks Rich,
I scoped the working chip in operation and i saw wave forms i was
not expecting ? the (pin 1) was particulalry different
/peculiar.
i will ooku pthe sequence next and see if i can decipher what i
see.
thanks again ,
robb
Eeyore
robb wrote:
> I scoped the working chip in operation and i saw wave forms i was
> not expecting ? the (pin 1) was particulalry different
> /peculiar.
What is pin 1 of the ROM connected to ? It may simply be floating.
Try tying it low.
Graham
John Fields
---
You didn't understand what I wrote, did you?
--
JF
robb
<gqrxz...@ftml.net> wrote in message
news:4f33ad0b-493c-4adf...@e6g2000prf.googlegroups.com...
> On Dec 27, 11:28 am, "robb" <s...@where.on.net> wrote:
> > I have a working (ie. tested)microcontrollerboard uses a
> > (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> > with a (NEC 23256AC) ROM chip.
> >
> > i removed the ROM chip (NEC D23256AC) and copied it using a
ROM
> > programmer, then i programmed that ROM image onto a (ST
M27C256B)
> > EPROM
> >
> > i put the new ROM (ST) onto themicrocontrollerboard and
>
Vcc?).
> In the case I saw EPROM's programmed & verified (in
programmer),
> but the output disappeared almost instantly in the real circuit
> where Vpp wasn't connected (to Vcc). (2716's).
>
well oddly on this board the (pin 1) is hardwired to (pin 27)
for the original chip that is ( NC to Addr 14) on the **new**
27c256 that would be (Vpp to Addr 14)
so i **tried** insert new 27C256 into socket with (pin 1) not
making contact(bend pin and slide to outside of socket) then
attach micro-jumper hooks from (pin 1) to Vcc
and this did not have any effect ??
so now i am wondeing if i am even reading the original Chip
correctly it is ***NOT*** directly supported /mentioned in my ROM
reader but it has similar equivalents by my judgement but the
data does not look like it is thr 8051 processor instructions as
i would expect.
thanks for help ,
robb
Eeyore
robb wrote:
> so now i am wondeing if i am even reading the original Chip
> correctly it is ***NOT*** directly supported /mentioned in my ROM
> reader but it has similar equivalents by my judgement but the
> data does not look like it is thr 8051 processor instructions as
> i would expect.
You could try running the ROM contents through a disassembler. That should
tell you if it's junk or not.
Graham
Rich Webb
[snip...snip...]
> so now i am wondeing if i am even reading the original Chip
> correctly it is ***NOT*** directly supported /mentioned in my ROM
> reader but it has similar equivalents by my judgement but the
> data does not look like it is thr 8051 processor instructions as
> i would expect.
*Reading* is (nearly) universal for memory chips with a standard
pinout. *Programming* is often vendor-specific and not well
documented in end-user data sheets.
Have you tried running the object code through a disassembler?
I've used D52, which is available at http://www.8052.com.
gqrxz...@ftml.net
> for the original chip that is ( NC to Addr 14) on the **new**
> 27c256 that would be (Vpp to Addr 14)
That doesn't sound odd as pin 1 would be A15 on the next
size up ROM.
> so i **tried** insert new 27C256 into socket with (pin 1) not
> making contact(bend pin and slide to outside of socket) then
> attach micro-jumper hooks from (pin 1) to Vcc
> and this did not have any effect ??
OK, so that's not the problem.
> so now i am wondeing if i am even reading the original Chip
> correctly it is ***NOT*** directly supported /mentioned in my ROM
> reader but it has similar equivalents by my judgement but the
> data does not look like it is thr 8051 processor instructions as
> i would expect.
Have you looked at a hex dump of the ROM? Perhaps
it didn't really enabel the ROM when reading it and you
"read" all FF or something like it from the original ROM and
it programmed your new EPROM with that.
Mask ROMs can have additional chip selects (if pins are
available) and these can be (mask programmed) to select
on high or low. There may or may not be an OE (possibly
just the chip select(s)).
It's a 28 pin chip and has to have gnd, Vcc, 8 data,
15 address so that leaves 3 pins. The eprom
has CE, OE, and Vpp; the ROM might have
3 more chip selects or some number of chip selects
plus OE?
It sounds solvable...
robb
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
uhmm....
any ideas on how to scope an initializing sequence ?
it's to fast or my adjusting or triggering is a problem ???
robb
mpm
> thanks for any help i �am stuck again,
> robb
Honestly, I just skimmed the replies, and don't have the time to get
into great detail about what might be wrong....
However, if I recall correctly, parallel EPROMs used to have
"Signature Bytes".
In the old days, that's how a programmer "knew" what programming
voltage / algorithm to use....
Could be the 8031 code is reading this, before allowing normal
operation. (Wild ass guess, btw)
Or, perhaps more likely, your programmer isn't really programming the
new EPROM and its just lying to you.??
Hope you figure it out. Good luck.
-mpm
budgie
>well oddly on this board the (pin 1) is hardwired to (pin 27)
>
>for the original chip that is ( NC to Addr 14) on the **new**
>27c256 that would be (Vpp to Addr 14)
>
>so i **tried** insert new 27C256 into socket with (pin 1) not
>making contact(bend pin and slide to outside of socket) then
>attach micro-jumper hooks from (pin 1) to Vcc
>
>and this did not have any effect ??
>
>
>so now i am wondeing if i am even reading the original Chip
>correctly it is ***NOT*** directly supported /mentioned in my ROM
>reader but it has similar equivalents by my judgement but the
>data does not look like it is thr 8051 processor instructions as
>i would expect.
Vpp needs to be held at Vcc for reading. If it floats you will get garbage
results.
robb
<gqrxz...@ftml.net> wrote in message
news:e16006dc-aebf-4d57...@e23g2000prf.googlegroups.com...
> > well oddly on this board the (pin 1) is hardwired to (pin 27)
> > for the original chip that is ( NC to Addr 14) on the
**new**
> > 27c256 that would be (Vpp to Addr 14)
>
> That doesn't sound odd as pin 1 would be A15 on the next
> size up ROM.
>
i am saying pin 1 and pin 27 of the memory chip are connected on
the controller board so that would cause special consideration if
one wanted to use a 27c512 ?
>
> > so i **tried** insert new 27C256 into socket with (pin 1) not
> > making contact(bend pin and slide to outside of socket) then
> > attach micro-jumper hooks from (pin 1) to Vcc
> > and this did not have any effect ??
>
> OK, so that's not the problem.
>
> > so now i am wondeing if i am even reading the original Chip
> > correctly it is ***NOT*** directly supported /mentioned in my
ROM
> > reader but it has similar equivalents by my judgement but
the
> > data does not look like it is thr 8051 processor instructions
as
> > i would expect.
>
> Have you looked at a hex dump of the ROM? Perhaps
> it didn't really enabel the ROM when reading it and you
> "read" all FF or something like it from the original ROM and
> it programmed your new EPROM with that.
>
close , it is a series of sections of 64 duplicate bytes
followed by another section of 64 duplicate bytes..... all the
waty to the end
each section of byte values is different and i get the exact
same series for each successive chip reading attempts.
unless i choose a different chip size like 27c128 then the series
of byte duplicates changes. where the first set maybe 7A in place
of the 02
here is a clip from begining of my read
:020000040000FA
:1000000002020202020202020202020202020202D0
:1000100002020202020202020202020202020202C0
:1000200002020202020202020202020202020202B0
:1000300002020202020202020202020202020202A0
:100040000202020202020202020202020202020290
:100050000202020202020202020202020202020280
:100060000202020202020202020202020202020270
:100070000202020202020202020202020202020260
:10008000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9E0
:10009000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D0
:1000A000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9C0
:1000B000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9B0
:1000C000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9A0
:1000D000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D990
:1000E000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D980
:1000F000D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D970
:10010000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E68F
:10011000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E67F
:10012000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E66F
:10013000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E65F
:10014000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E64F
:10015000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E63F
:10016000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E62F
:10017000E6E6E6E6E6E6E6E6E6E6E6E6E6E6E6E61F
:1001800039393939393939393939393939393939DF
:1001900039393939393939393939393939393939CF
:1001A00039393939393939393939393939393939BF
:1001B00039393939393939393939393939393939AF
:1001C000393939393939393939393939393939399F
:1001D000393939393939393939393939393939398F
:1001E000393939393939393939393939393939397F
:1001F000393939393939393939393939393939396F
:1002000013131313131313131313131313131313BE
:1002100013131313131313131313131313131313AE
:10022000131313131313131313131313131313139E
:10023000131313131313131313131313131313138E
:10024000131313131313131313131313131313137E
:10025000131313131313131313131313131313136E
:10026000131313131313131313131313131313135E
:10027000131313131313131313131313131313134E
:100280001E1E1E1E1E1E1E1E1E1E1E1E1E1E1E1E8E
.... till the end
>
> Mask ROMs can have additional chip selects (if pins are
> available) and these can be (mask programmed) to select
> on high or low. There may or may not be an OE (possibly
> just the chip select(s)).
>
I mapped the pins on the board so as to be reasonably certain
that the ROM chip was compatible with the 27cXXX series of chips
all the pin/address/data lines seem to be consistent with the
27cXXX series pin out. the data and address lines match to the
MCU adressing pins according to 27cXXX datasheet even the funny 8
through 11 pin jumble.
(pin 22) ROM goes to (pin 29) 8051 (PSEN- prog store enable)
(pin 20) ROM goes to (pin 30)8051 (ALE-Addr Latch Enable)
on the PCB the 8 data lines are all connected with the first 8
Address lines
so D0 is connected to A0 and (D1 to A1) and these shared
connection s all go back to MCU
> It's a 28 pin chip and has to have gnd, Vcc, 8 data,
> 15 address so that leaves 3 pins. The eprom
> has CE, OE, and Vpp; the ROM might have
> 3 more chip selects or some number of chip selects
> plus OE?
>
> It sounds solvable...
>
thanks for the help,
robb
TT_Man
"mpm" <mpmi...@aol.com> wrote in message
news:08ba70e9-b057-4d39...@e25g2000prg.googlegroups.com...
On Dec 27, 2:28?pm, "robb" <s...@where.on.net> wrote:
> thanks for any help i ?am stuck again,
> robb
Honestly, I just skimmed the replies, and don't have the time to get
into great detail about what might be wrong....
However, if I recall correctly, parallel EPROMs used to have
"Signature Bytes".
In the old days, that's how a programmer "knew" what programming
voltage / algorithm to use....
Could be the 8031 code is reading this, before allowing normal
operation. (Wild ass guess, btw)
Or, perhaps more likely, your programmer isn't really programming the
new EPROM and its just lying to you.??
Hope you figure it out. Good luck.
-mpm
Utter rubbish.....the 8031 isn't reading sig bytes...
Your programmer is not reading the eprom correctly.
Ian Malcolm
It would seem your original rom has an internal address latch.
There is *some* evidence that 23256 roms with this feature may have been
used by HP, but I have had no success finding a NEC data sheet for your
rom. This would explain why the eprom reader reads the same value 64
times and also why there is no 8 bit latch chip between the multiplexed
d0-7/A0-7 MCU bus and the rom's A0-7 address inputs. Try a different
algorithm for reading the rom on the programmer. When you've go the
correct contents that dissasemble to something reasonable, you'll need
to put a little board together to insert a latch between the combined
bus and the adddress pins, then program a 27c256 and try it.
HTH
--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
'Stingo' Albacore #1554 - 15' Early 60's, Uffa Fox designed,
All varnished hot moulded wooden racing dinghy.
Eeyore
robb wrote:
Looks like gibberish to me.
What happens if you try reading it as a 27C512 ? Just an idea.
Graham
mpm
> so now i am wondeing if i am even reading the original Chip
> correctly it is ***NOT*** directly supported /mentioned in my ROM
> reader but it has similar equivalents by my judgement �but the
> data does not look like it is thr 8051 processor instructions as
> i would expect.
The above seems to be the problem.
Your programmer is not reading the original ROM (23xxx) chip
correctly.
However, it "is" reading something.
Later you burn another chip, and this chip correctly burns what was
read previously.
The only problem is, the original read was not right, so it matters
not if the two compare!!
I still contend this is a read problem on the original ROM, likely
related to the signature byte.
To my knowledge, you are unlikely to blow up the original ROM using
read voltages.
As long as you don't try to program it.
So, if you feel its worth the attempt, you could try other 27256
settings and see if you can get something that looks reasonably close
to 8031 opcodes. (?)
Another posted commented that your 23xxx might have internal address
latches.
Honestly, I've never heard of that. I doubt they exist, but I could
be wrong.
I am assuming the 23xxx is a factory-masked ROM (i.e., no eprom quartz
window).
If that's the case, very often the 23xxx programming info is on the
same datasheet as the 27xxx of the same manufacturer and model
series. It might be worth googeling...
And of course, if there are pinout differences between the masked-rom
and eprom versions, your programmer would need to know about these...
and hence we're back to the signature bytes. Good luck.
-mpm
mpm
> "mpm" <mpmill...@aol.com> wrote in message
I agree, now that I have read the replies more thoroughly, esp, post
#3, it would appear that your programmer is not reading the original
masked ROM part correctly.
TT_Man
> Hope you figure it out. ?Good luck.
> -mpm
>
> Utter rubbish.....the 8031 isn't reading sig bytes...
> Your programmer is not reading the eprom correctly.
I agree, now that I have read the replies more thoroughly, esp, post
#3, it would appear that your programmer is not reading the original
masked ROM part correctly.
This is what I have found out about UPD23C256E.....
The OE signal is mask option selectable and can be active hi, low or don't
care.
Put the chip in your reader, but bend out the OE leg ( pin 22). Connect it
via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
Look at the data and see if it looks 'real'.
If not, leave pin 22 'not connected 'and read again......
I don't think it's worth trying to connect OE to GND as that is the default
for all generic 27356 devices.
Eeyore
TT_Man wrote:
Not to mention that if /OE is tied in some unusual way on his board, it also
won't work with standard Eproms.
It might be an idea to see if pin22 of the ROM socker is tied low.
Graham
robb
i am really stuck and appreciate your's and everyones efforts to
get me going.
that is exactly what i have been trying since the latest round of
**bad ROM read** diagnosis.
I have been selecting a variety of different chip makers versions
of 27cXXX where XXX is {64,128,256,512}... additionally i have
been choosing different sizes of reads to see if i get anything
that looks like some 8051/8031 op codes. so 0xf to 0x7fff bytes
and in between
the only difference is that sometimes the sequence of bytes i get
have a different values for the different sized chips
so.... that means a (27c128) read will get me a different
sequence of repeated chars than say a (27c256) read
>
> Another posted commented that your 23xxx might have internal
address
> latches.
>
well that advice was based on the fact that i traced the pins
connection on the controller circuit board to try and decipher
what this chip might actaulally be and i found that the
Address lines 0-7 were tied to the Data lines 0-7 and then they
made ther way to the appropriate 8051 lines so being multiplexed
someone though there must be latching operation...
the only 23xxx datasheet i found (toshiba TMM23256P) says ...
that it uses a Address Latch on the falling edge of (CE) and
latches all inputs except for (OE) to provide data bus
compatibility and has a reference to 3-State outputs or Wired
OR capability ????? what that means ????
My pin trace is.....
Where Rom is the same ROM there is only 1 ROM
this views best in fixed width eg. courier
Rom(pin) Rom(pin) 8051 (pin)
------------------------------------------
A0 (p10) D0 (p11) P0.0 (p39)
A1 (p9) D1 (p12) P0.1 (p38)
A2 (p8) D2 (p13) P0.2 (p37)
......
A8 (p25) --- P2.0 (p21)
A9 (p24) --- P2.1 (p22)
.....
A14 (p27) A15 (p1) P2.6 (p27)
.....
OE (p22) --- PSEN (p29)
CE (p20) --- ALE (p30)
> Honestly, I've never heard of that. I doubt they exist, but
I could
> be wrong.
> I am assuming the 23xxx is a factory-masked ROM (i.e., no eprom
quartz
> window).
> If that's the case, very often the 23xxx programming info is on
the
> same datasheet as the 27xxx of the same manufacturer and model
> series. It might be worth googeling...
>
> And of course, if there are pinout differences between the
masked-rom
> and eprom versions, your programmer would need to know about
these...
> and hence we're back to the signature bytes. Good luck.
>
thanks again MPM,
i really do appreciate the help. hopefully i will solve or find
more useful info that someone can give me an indication of what i
need to do to solve this problem
i am thinikng i will need to use some 8051 development board and
write my own application to grab data and put somewhere to upload
or print on serial port or something
sound feasible,...
Thanks again for help,
robb
robb
"TT_Man" <Som...@ntlworld.com> wrote in message
news:rgvdj.17507$745...@newsfe1-win.ntli.net...
ok, interesting experiment,
when i tie the p22 (oe) high then i read all 0xFF all the way
floating gives similar as when connected
reading a troshiba 23256 mask rom datasheet it showed that the
latch occurs at trailing edge of (CE) so (CE) falls about halfway
through the adress valid ... but most timing diagrams for 27cXXX
chips show the (CE) falling at or just before the address valid
section
so i do not know how that timing could affect what i am doing. i
suppose i need to find out what the ROM programmer is doing.
programmer is an "Easypro90" if anyone has any knowledge of
these?
thanks for helping,
robb
Eeyore
robb wrote:
> when i tie the p22 (oe) high then i read all 0xFF all the way
> floating gives similar as when connected
Now tie it low.
AND look at how it's connected on the equipment pcb.
Graham
donald
Plesae post from your reader the first 16 bytes of the ROM file.
If this does not look right, then everything else will be off.
If the reader can not read it, it won't be able to write anything that
makes sense.
You could always run the exorcised binary file thru a dis-assembler,
re-assemble it, program your EEPROM and see if that runs.
donald
robb
"Eeyore" <rabbitsfriend...@hotmail.com> wrote in
message news:47768628...@hotmail.com...
>
>
> TT_Man wrote:
>
> > I agree, now that I have read the replies more thoroughly,
esp, post
> > #3, it would appear that your programmer is not reading the
original
> > masked ROM part correctly.
> >
> > This is what I have found out about UPD23C256E.....
> > The OE signal is mask option selectable and can be active hi,
low or don't
> > care.
> >
> > Put the chip in your reader, but bend out the OE leg ( pin
22). Connect it
> > via a 1K resistor to Vcc and then read as 'any' 27256 EPROM.
> > Look at the data and see if it looks 'real'.
> > If not, leave pin 22 'not connected 'and read again......
> > I don't think it's worth trying to connect OE to GND as that
is the default
> > for all generic 27356 devices.
>
> Not to mention that if /OE is tied in some unusual way on his
board, it also
> won't work with standard Eproms.
>
> It might be an idea to see if pin22 of the ROM socker is tied
low.
>
> Graham
>
I tried out the ideas you suggested.
that is .... select different ROM types and i also tried with
differing read lengths for 0xf to 0x7fff or whatever the max size
is and all the same results
except that different 27cXXX types gives me different sequence of
repeated bytes
i tried the OE pin out and jumpering pins and such
i think maybe my programmer is just crap it is an "Easypro90" and
it supports lots of chips but apparently not the one i need
i highlighted the pinout and traces of the ROM chip in another
post i will put it here ....
My pin trace is.....
Where Rom is the same ROM there is only 1 ROM
this views best in fixed width eg. courier
Rom(pin) Rom(pin) 8051 (pin)
------------------------------------------
A0 (p10) D0 (p11) P0.0 (p39)
A1 (p9) D1 (p12) P0.1 (p38)
A2 (p8) D2 (p13) P0.2 (p37)
......
A8 (p25) --- P2.0 (p21)
A9 (p24) --- P2.1 (p22)
.....
A14 (p27) A15 (p1) P2.6 (p27)
.....
OE (p22) --- PSEN (p29)
CE (p20) --- ALE (p30)
one thing i have come across that may help is that the oly mask
ROM datasheet i have found (Toshiba TMM23256P) says that the chip
has Adress latch on falling edge of (CE) and the timing diagrm
shows the falling CE edge occurs in middle of address valid
section, on most 27cXXX chips the timing diagram shows the
falling edge of CE occurs just at or before the valid address
section but i do not know if that should make a diference ??
Thanks for all the help Graham, as i relly need it to get out of
this jam.
do you think it would be difficult to program a 8051 development
board to read this data and say dump it somewhere to pick it up .
seems like it should be easy enough ??? i have a PJRC Rev 4
board http://www.pjrc.com/
that i got with the ROM programmer pretty cheap
i do not know if my Programmer will alloew you to write a custom
algorithm but i ahve not found any info on the easypro site to
that regard.
thanks again,
robb
robb
"donald" <Don...@dontdoithere.com> wrote in message
news:Wsedncn0c70wPeva...@comcast.com...
Hello donald thanks for the help,
i agree if you getting crap you write crap,
i though i had allready tested the ROM reads previously and had
success but when i went to recheck i found that the other
microcontroller board was using a 8051 with internal programand
not even uing the ROM
so now i realise that it is reading the ROM that is my problem.
so now how to get programmer to read these ROMS ??
here are first lines from "Easypro90B" programmer read
:020000040000FA
:1000000002020202020202020202020202020202D0
:1000100002020202020202020202020202020202C0
any experience dumping memorywith a 8051 development board ?
i have PJRC Rev 4 board http://www.pjrc.com/
easier than getting the EasyPRO90B to do it ???
thanks again for the help,
robb
donald
At address 0x000 should be a jump to a start address.
02 is a long jmp op-code a nd the target address looks like 0x0202.
http://www.win.tue.nl/~aeb/comp/8051/set8051.html
But then all the interrupt vectors are long jumping to the same address.
This is a problem.
If you can share the entire hex file, maybe someone here be able to help
you read it.
Another idea.
Maybe the address lines are mixed up, so a strait copy would be worng.
good luck.
donald
Henry Kiefer
> Ok, here is your first problem.
>
> At address 0x000 should be a jump to a start address.
>
> 02 is a long jmp op-code a nd the target address looks like 0x0202.
>
> http://www.win.tue.nl/~aeb/comp/8051/set8051.html
>
> But then all the interrupt vectors are long jumping to the same address.
>
> This is a problem.
>
> If you can share the entire hex file, maybe someone here be able to help
> you read it.
>
> Another idea.
>
> Maybe the address lines are mixed up, so a strait copy would be worng.
>
> good luck.
>
Hint if you read garbage:
Sometimes there is added simple encryption by mixing address and/or data
lines between controller and memory. You should check that!
This encryption type does allow copying the ROM but makes it hard to
disassemble it.
- Henry
donald
You are correct, the bytes and bits should be in the same location after
the copy, even if the address/data lines are mixed up.
Encryption would imply that the data/address path is moved around.
So, OP, is there any other chips in the data/address path ??
donald
Henry Kiefer
Think simple, for example: Exchange A14 with A15 and D4 with D2 between
controller and memory. Gives garbage in Reader, but controller works (if
the manufacturer wrote a simple exchanger prog before programming the ROM).
- Henry
donald
around.
Looking at the vectors kind of indicated that.
Don't you just love trouble shooting in the dark ?
donald
Henry Kiefer
>>> You are correct, the bytes and bits should be in the same location
>>> after the copy, even if the address/data lines are mixed up.
>>>
>>> Encryption would imply that the data/address path is moved around.
>>>
>>> So, OP, is there any other chips in the data/address path ??
>>
>>
>> Think simple, for example: Exchange A14 with A15 and D4 with D2
>> between controller and memory. Gives garbage in Reader, but controller
>> works (if the manufacturer wrote a simple exchanger prog before
>> programming the ROM).
>>
>>
>> - Henry
>>
>>
> The sample lines the OP showed us looks like the pages may be shifted
> around.
>
That was the trigger for me.
> Looking at the vectors kind of indicated that.
>
I don't spent time to read all posting, sorry.
> Don't you just love trouble shooting in the dark ?
>
That is my job to shot. I like it since 25 years.
Greetings -
Henry
Romdump
> > > Your programmer is not reading the eprom correctly.
>
Exactly.
Robb,
I don't think the Easy Pro 90 can read the D23256ac because the chip
is too slow, (150 to 250ns).
Here what I would do. Build a simple adapter to your printer port and
strobe the address lines to read the data bits off the D23256ac.
Remember the slower the read the better for you.
Also the speed of you computer will affect your reading. If you can
connect an oscilloscope to you printer port (even the Easypro 90 to
pin A1 ), you can figure how fast it is reading the D23256ac.
Once you got the image file you can burn the ST M27C256B (45ns) with
your Easypro 90.
In case you want to update the Easypro 90 software, you can grab it
from http://www.programtec.com/english/main.asp.
Don't bother contacting tech support because they never reply.
Eeyore
robb wrote:
> but when i went to recheck i found that the other
> microcontroller board was using a 8051 with internal programand
> not even uing the ROM
Judging by the age of this system that may typically be an 8751.
Can you provide the exact part number of the 8051 with suspected
internal program please ?
You can tell if it's using the internal ROM because pin 31 (/EA/Vpp)
will be tied high. It's still possible to read an external ROM in this
mode but it will appear as an 'extension' to the interal ROM with a
start address offset by the size of the internal ROM.
I'm beginning to think you might benefit from a cheap and cheerful
Chinese Eprom/uC reader writer btw. Especially if you need to read the
contents of an 8751 type device.
Graham
Eeyore
Henry Kiefer wrote:
> donald schrieb:
> >
> > Maybe the address lines are mixed up, so a strait copy would be worng.
>
>
> Hint if you read garbage:
> Sometimes there is added simple encryption by mixing address and/or data
> lines between controller and memory. You should check that!
I'd love to see someone make an 8051 do that. The 'controller' is the 8051.
None of this would prevent a simply copy working though ! Think about it guys.
Graham
Eeyore
robb wrote:
> I have a working (ie. tested) microcontroller board uses a
> (Philips MAB-8031-AH-12p) MCU a 8051 variant, maybe romless ?
> with a (NEC 23256AC) ROM chip.
Do you have a plain 'vanilla' example of an 8051 application circuit
with external ROM showing the connection of the address and data lines
(and address latch) ?
In view of comments made, I suggest that you 'buzz out' all the address
and data line connections between the 8051 and the ROM on your board and
report back to establish if there's anything unusual here.
Graham
Ian Malcolm
Unfortunately he *has* a chinese multi-device programmer
<http://www.programtec.com/english/products/EasyPRO90B.asp>
It appears likely that it is the source of his problems, and getting
another similar one *UNLESS* it has *FULL* instructions on implementing
one's own programming and reading algorithms
It is *supposed* to have lifetime support so it might be worth it for
the OP to contact them with his part number ;-)
The available evidence suggests that the EasyPRO90 he has reads 27xnn
EPROMS using a 'fast' algorithm that reads 64 bytes at a time,
activating /CE continuously and strobing /OE for each byte.
Unfortunately he needs a 'slow' algorithm that strobes *both* signals,
with adequate setup and hold time :-(
A bit of research leads me to the 87C256 Latched EPROM which is intended
for use in applications with /ALE on pin 20. If his programmer supports
this device or equivalent he should be golden.
If so, and he could source one, or someone can suggest a device with the
same functionality, it would be a drop in replacement, otherwise, well
I've built all sorts of ROM adaptors 'dead bug' fashion using two
stacked turned pin sockets with the top soldered into the bottom one
with various pins I needed to intercept cut away in between them, kynar
wire, some cotton thread to lace the kynar in place, some SMD TTL and a
few drops of superglue to hold everything together. Keeps the pins
clean & fit to insert in the programmer and also avoids needing to mod
the equipment PCB (assuming there is ~1cm vertical clearance). :-)
TT_Man
> i removed the ROM (ST) and put the ROM (NEC) back and works like
> a charm... no problems
>
> i download ROM images from both (NEC) and (ST) and compare in
> file compare program which declares them as exactly the same
> ?????
>
> HELP please?? any ideas what is going on here.
>
> the only funny thing about the microboard (that i know) is that
> the ROM memory socket has (pin1) tied to (pin 27) that is Addr15
> (pin 1) and Addr 14 (pin 27) ??? do not know why ????
>
> thanks for any help i am stuck again,
> robb
>
>
>
Where are you located in the UK?
Mike
Rich Webb <bbe...@mapson.nozirev.ten> wrote:
>*Reading* is (nearly) universal for memory chips with a standard
>pinout.
"Nearly" tell that to Apple and Sinclair.
Apple II Europlus O/S ROMS wouldn't read on my EPROM programmer without
some fiddling about to come up with CS (Chip select) HIGH and VPP/OE LOW.
(Normal would be BOTH low)
Sinclair QL OS ROMS are odder still: OE required to be HIGH, CS is active
LOW on one chip, active HIGH on another. The CS lines are tied together
in the computer, so it makes sense. However, for an EPROM programmer,
it's backwards.
>Have you tried running the object code through a disassembler?
Also run it through an ASCII dump, look for any copyright strings that
make sense.
--
--------------------------------------+------------------------------------
Mike Brown: mjb[at]pootle.demon.co.uk | http://www.pootle.demon.co.uk/
Mike
TT_Man <Som...@ntlworld.com> wrote:
>
>> NEC D23256AC vs 27256
>My guess is that here is a subtle pin difference between the eproms... speed
>is definitely NOT an issue.
Active HIGH versus Active LOW on CS and OE pins? Maybe the EPROM programmer
is able to compensate for that and "do the right thing", but your target
circuit can't? Been through that recently with some EPROM/ROMs and it is
a pain.
Get data sheets for both chips and look closely.
robb
message news:47777354...@hotmail.com...
Appologies for late turn around reply,
finishing up X-mas mode, returned from 4 hour drive to relatives
this PM.
Just wanted to give a quick reply before sleep.... so that you
didn't think i gave up on your much appreciated help.
The ROM/MCU does connect to other chips but does not go through
them. That is, my original pinout diagram of the ROM lines to MC
line relations holds true, there are direct traces from the ROM
Addr/Data lines to MCU's ports 0 and 2.
but also the ROM Addr 0-7 is connected to the inputs 1D,2D
etc.... of 3 diff SN74LS377 (D-Type Flip-Flops) the output of
the Flip-FLops 1Q,2Q ... connect to either a Static Ram chip's
(SRM2016) Address lines and the SRM data lines are also connected
to the I/O port 1 of MCU
the LS377 has connections to other chips around the MCU eg.
(74LS251, 74LS28B, 4049, others)
I will work on a more complete pin connections, i origianlly just
posted to show that the ROM pins were consistent with 27cXXX
series chips.
My chepao chim=nese reader did supoprt the chip that someone
suggested the D87c257 and i get something alot more promissing
shown below...
i do not know if it is good yet as i do not have any more blank
ROM chips to burn and i have not tried to load into a 8051
dis-asembler
thanks for all the help Graham,
robb
D87c257 read....
----------------------
:020000040000FA
:1000000002096FC0D0C0E0020173FFC0D0C0E0029F
:1000100001BEFF30B202D22A32FFFFC0D0C0E0C022
:1000200082C083C000904058E531540F204C073007
:1000300045036001040423F893F58DE80493F58BE0
:10004000E542540790405093F8E541540793C44863
:10005000758360F0206F26D294E530758350F0E50B
:100060002D543F7041C245C28E206F19205D1E1273
:100070000F39D000D083D082D0E0D0D032204DD9FB
:100080007530FF80D4205C4C12154A80E5E5422093
:10009000E002C294E530758350F080D6E54120E05F
:1000A000F353307780EE14601314147002D24CE5D1
:1000B0003130450C540F600215313164316480B227
:1000C000C4B53109C24C1046F1D24580ED104CEA5E
:1000D000053180E6104DC5E520440F20E701C4F549
:1000E00030758DFBD28ED24D53200F80854320F08A
:1000F000E52D543F603AFDF5317842306F0118E646
:1001000030E0021531E531C313B4020575310A80C0
:100110000DC394035001E4C3139246C4F531E6D2F3
:100120004C20E009C24CED1460031201641201641A
:10013000208E20306F06E530C4B53009758DFF750F
...........
...........
:10096000D23D22D23C22E0540F24F650F3808D7504
:1009700090CC797E7802760008D9FB75B8E175894C
:1009800011758CFE75880575A8867583607444F0B2
:1009900075835074FFF530F0758D88D28ED2137543
:1009A000530AD28C120D60308FFA7583507477F52C
:1009B00030F07455758360F0C28F758D88120D60AC
:1009C000308FFA906007E030E002D20A756DE0D215
:1009D00014D2131230A8754400C22C121808C28E0B
:1009E000C28FD2AB1229FCD2192019F82018F5A217
:1009F000B492E0A2B592E1F45403F52B3014102028
:100A0000200D204A472010031218EAC214C2131204
:100A100029FC304A082011E4200DE1800DE5445402
:100A2000F0B4F006202FD52010D220182AD293D26D
:100A300092C295C2D3C2D4A2B492E0A2B592E1F41C
:100A40005403FAE52B5403B5023980B02011BC20C1
:100A50000DB91231A780B4D2193014057553008036
:100A60009B3018C93092298043501E120CAEEA60A8
:100A700030B4030A205A12D25A1213157403120DFD
:100A8000428006EA20E0E250E2532BFC422B21FC9C
:100A9000C293D295C291E543B4569CC290D2A8802D
:100AA00096305AE5C25A120EA5E480DD7552A0C2F6
:100AB00093D292C20A304102D291E543B45602D297
:100AC00090752E00750600D215754D00120CAEC241
:100AD00089D2A8301E04C22AC21EC25A205646E538
robb
"Ian Malcolm" <valid.address...@invalid.invalid> wrote
in message news:fl8008$l8o$1...@inews.gazeta.pl...
> Eeyore wrote:
> >
> > robb wrote:
> >
> >>but when i went to recheck i found that the other
> >>microcontroller board was using a 8051 with internal
programand
> >>not even uing the ROM
> >
> > Judging by the age of this system that may typically be an
8751.
> >
> > Can you provide the exact part number of the 8051 with
suspected
> > internal program please ?
> >
>
> <http://www.programtec.com/english/products/EasyPRO90B.asp>
>
> It appears likely that it is the source of his problems, and
getting
> another similar one *UNLESS* it has *FULL* instructions on
implementing
> one's own programming and reading algorithms
>
> It is *supposed* to have lifetime support so it might be worth
it for
> the OP to contact them with his part number ;-)
>
> The available evidence suggests that the EasyPRO90 he has reads
27xnn
> EPROMS using a 'fast' algorithm that reads 64 bytes at a time,
> activating /CE continuously and strobing /OE for each byte.
> Unfortunately he needs a 'slow' algorithm that strobes *both*
signals,
> with adequate setup and hold time :-(
>
> A bit of research leads me to the 87C256 Latched EPROM which is
intended
> for use in applications with /ALE on pin 20. If his programmer
supports
> this device or equivalent he should be golden.
>
Thanks for the help Ian,
And the EasyPRO90B does happen to support a couple of different
varieties of that chip well its cale a (D87c257 Intel , M87c257
ST) and when i read selecting these devices i get a more
promising read that i will need to test burn or verify in 8051
disasembler.
i show the output at the end of the reply below...
interestingly a different (NEC D23128AC) gives similar trouble
>
> If so, and he could source one, or someone can suggest a device
with the
> same functionality, it would be a drop in replacement,
otherwise, well
> I've built all sorts of ROM adaptors 'dead bug' fashion using
two
> stacked turned pin sockets with the top soldered into the
bottom one
> with various pins I needed to intercept cut away in between
them, kynar
> wire, some cotton thread to lace the kynar in place, some SMD
TTL and a
> few drops of superglue to hold everything together. Keeps the
pins
> clean & fit to insert in the programmer and also avoids needing
to mod
> the equipment PCB (assuming there is ~1cm vertical clearance).
:-)
>
by ROM adaptor ? you mean to make the D23256AC look or behave
like some other chip that is supported ??? eg 27C256 etc...
the only difference these amateur eyes could see with the 87c257
was the addition of a latch strobe on the pin 1 ??? and it
coincided almost nearly with the CE . that seems easy enough to
fabricate ?
any ways below is a dump using the 87c257 device
thank you, i appreciate all the effort and help,
robb
skip
robb
> Henry Kiefer wrote:
[trim]
> > Sometimes there is added simple encryption by mixing address
and/or data
> > lines between controller and memory. You should check that!
> >
> > This encryption type does allow copying the ROM but makes it
hard to
> > disassemble it.
> >
location after
> the copy, even if the address/data lines are mixed up.
>
> Encryption would imply that the data/address path is moved
around.
>
> So, OP, is there any other chips in the data/address path ??
>
> donald
>
Hello Don and Kiefer,
thanks for taking time and trying to help.
I wondered about the encryption myself considering all the
trouble reading a simple ROM chip to burn another,
i wondered if they might have tried to protect it somehow but
then these are very speacialized controlers so the only real
protectin they might want is trying to hide their ideas from a
potential competitor then that would make sense.
but with any of that i should be able to just duplicate the ROM
memory and have it work ?? yes ??
i do not want to debug or decipher just duplicate ROM to replace
my fried ROM
no other chips between the data path and ROM/MCU
**BUT** there are chips connected to those ROM/MCU address lines
- SN74LS377 (D-Type Flip-Flops)
- 74LS251, (data selector multiplexer, 3 state out)
- 74LS28J, (2 input positive NOR buffers )
- 4049
the ROM Addr 0-7 is connected to the inputs 1D,2D
etc.... of 3 diff SN74LS377 (D-Type Flip-Flops) the output of
the Flip-FLops 1Q,2Q ... connect to a Static Ram chip's
(SRM2016) Address lines and the SRM data lines are connected
to the I/O port 1 of MCU p1.0-7
the LS377 has connections to the other chips around the MCU also
eg.
(74LS251, 74LS28B, 4049, others)
i posted a PIC in alt.binaries.schematics.electrionics of all the
chips involved.
i know it is not a schematic but it shows the chips i am talking
about.
thanks again donald for all the help,
robb
robb
"Henry Kiefer" <ehydra_new...@arcor.de> wrote in message
news:4776cc46$0$13122$9b4e...@newsspool2.arcor-online.net...
> donald schrieb:
>
> > Don't you just love trouble shooting in the dark ?
> >
>
> That is my job to shot. I like it since 25 years.
>
> Greetings -
> Henry
>
I have new ROM dump below (bottom of post)using a chip suggested
by Ian an D87C257 this loks better if you could take a peek and
comment i would appreciate that/
i don't want anyone shooting in the dark i want to make it
bright and clear
i give the information i have first and then whatever will help
you experts help me i try to provide as best i can.
I originally tried to approached this as simple as possible...
copy ROM(orig) image , burn ROM(new), test ROM(new) on the
working board
so that i would not need to worry with encryption and adress
shifts and all the other tricks of the trade.
so now the ROM reader is suspect
thanks again,
robb
snip
Ian Malcolm
> "Ian Malcolm" wrote:
>>
>> A bit of research leads me to the 87C256 Latched EPROM which is intended
>> for use in applications with /ALE on pin 20. If his programmer supports
>> this device or equivalent he should be golden.
>
> Thanks for the help Ian,
>
> And the EasyPRO90B does happen to support a couple of different
> varieties of that chip well its cale a (D87c257 Intel , M87c257 ST)
> and when i read selecting these devices i get a more promising read
> that i will need to test burn or verify in 8051 disasembler.
>
> i show the output at the end of the reply below...
>
check it, but it looks too regular to be garbage and doesn't repeat in
the ways I'd expect from a bad read. It dosn't contain any ASCII text
(unless the address and/or data lines are scrambled (not wired 1-1 2-22
etc.)) but I wouldn't expect that unless the original unit has a LCD (or
LED) dot matrix display or a serial port.
> interestingly a different (NEC D23128AC) gives similar trouble
Probably the wrong algorithm. without checking its data sheet, I cant
match it up to a supported device, or are you telling me you tried this
chiptype reading the D23256AC? Unless you have a D23128AC you need to
read, IMHO its not worth the effort.
>
>
>> If so, and he could source one, or someone can suggest a device with
>> the same functionality, it would be a drop in replacement,
*MUCH* the best option if you can get an 87c257 to program.
So you ran out of blank roms :-) If you are doing much of this, you
*need* a UV EPROM eraser. Easy enough to make if you can get the UV
tube and a torch with the same size tube to gut for the tube mounting
and invertor. *DONT* look at the light - if you value your eyes (if you
catch a brief glimpse it wont hurt you). At its minimum, its just the
tube powered up and supported 1 diameter above the window in the EPROM
in a bit of antistatic foam, with a box over it all so you cant see the
light from the tube. The timing is important. You need to find how long
it takes to wipe the chip then add about 50% for reliability. I suggest
starting with 3 minute increments. and expect a result in the 10-20
minute range Once you know how powerful your eraser is, you can just
use that time, but an occasional check for blank at 2/3 time is good
incase yor UV tube is getting weak. Get this project out of the way
then box up the eraser nicely, painting the inside of the box matt black
and maybe add a timer.
>> otherwise, well I've built all sorts of ROM adaptors 'dead bug'
>> fashion using two stacked turned pin sockets with the top soldered
>> into the bottom one with various pins I needed to intercept cut away
>> in between them, kynar wire, some cotton thread to lace the kynar in
>> place, some SMD TTL and a few drops of superglue to hold everything
>> together. Keeps the pins clean & fit to insert in the programmer and
>> also avoids needing to mod the equipment PCB (assuming there is ~1cm
>> vertical clearance). :-)
>
> by ROM adaptor ? you mean to make the D23256AC look or behave like
> some other chip that is supported ??? eg 27C256 etc...
NO, completely the other way round, make a supported 27C256 look like a
D23256AC or 87c257 so it can be used to *REPLACE* the D23256AC in the
equipment after programming it without the adaptor.
> the only difference these amateur eyes could see with the 87c257 was
> the addition of a latch strobe on the pin 1 ??? and it coincided
> almost nearly with the CE . that seems easy enough to fabricate ?
YES, you need to intercept the high address lines (A0-A7 stay directly
connected) and insert a latch between them and the combined address/data
lines clocked by the ALE signal. SMD TTL octal latch chip, some very
fine solid core wire and get at it. N.B. when building SMD 'dead bug'
fashion, solder all the kynar (wire wrap wire) to the chip pins first.
You will probably need a bit of very thin stiff plastic to glue the chip
to. The plastic is glued on top of the frame of the lower socket. You
cut back the pins of the top socket that you need to divert and solder
the wires to the stubs. You solder all the pins left on the top socket
with the top socket not quite fully inserted into the bottom one. do
corner pins first and get it level. The actual sockets on a turned pin
socket take solder quite nicely but you only get one shot to put a pin
in there. Put the bottom socket in another one or some scrap perfboard
while you work to stop the pins moving if the plastic softens from the
heat. Lay off the Coffee for 24 hours before hand and get a good nights
sleep first!
It *MAY* be possible to get away with a normal flat pin socket with the
high address pins bent out and patched to the outputs of one of the
octal latches on the board if the address demultiplexing for the RAM has
its outputs permanently enabled (or pick it up at the RAM). If the
latch has a chip other than the 8051 feeding /OE or CLK, its probably no
good for the signals you need. Pin 20 would need to be tied low.
>
> any ways below is a dump using the 87c257 device
>
> thank you, i appreciate all the effort and help, robb
>
>
> D87c257 read.... ----------------------
> :020000040000FA
> :1000000002096FC0D0C0E0020173FFC0D0C0E0029F
> :1000100001BEFF30B202D22A32FFFFC0D0C0E0C022
> :1000200082C083C000904058E531540F204C073007
> :1000300045036001040423F893F58DE80493F58BE0
<IntelHEX dump snipped>
I recccomend you find a file sharing service to post the dump to then
give us a link for anyone with 8051 experience can then take a look at
it. It would be nice to know make model and description of the unit you
are trying to repair as well.
Good luck with it, I admire your persistance
HAPPY NEW YEAR.
P.S. I have a new year resolution for you: If it aint broke dont fix it!
(Unless you can afford to sacrifice one to your curiosity)
Andy
The address is obviously being latched in the ROM. Otherwise, when the
8051 switches to reading the ROM's data, the address that it was
providing to the ROM will be gone.
donald
> The address is obviously being latched in the ROM. Otherwise, when the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I was wondering about that.
I have not found a data sheet for the D23256.
Is the OP trying to insert a 27256 into the same socket that the D23256
came out of ??
That would explain why the 27256 would not work in the same socket.
donald
robb
Hello OP here,
The reason for trying to use a 27c256 in place of the D23256AC
is.....
that was some advice given on the MCU-Mall user forum where they
sell lots of cheap chinese ROM programmers.
one of the regular posters thought 23256 was just a read only /
mask rom version of the 27c256 ?
so i went with that.
i kind of half convinced myself that the latching mechanism could
be superceeded with a fast enough 27c256 operation ????
the 23256 was 150ns and many 27c256 are 50-90 ns so that 27c256
is ready long before the read occurs ??? that was my thinking
thanks for any help ,
robb
robb
Andy
For such a scheme to possibly work, your replacement ROM has to be a
lot slower, not faster. A 150ns ROM means the MCU has to wait at least
150ns before the data is valid for reading. A 90ns replacement ROM
means the data is guaranteed to have changed at most 90ns after an
address change, long before the MCU is set to read it.
donald
>
> For such a scheme to possibly work, your replacement ROM has to be a
> lot slower, not faster. A 150ns ROM means the MCU has to wait at least
> 150ns before the data is valid for reading. A 90ns replacement ROM
> means the data is guaranteed to have changed at most 90ns after an
> address change, long before the MCU is set to read it.
>
Andy,
I do not believe this is 100% correct.
You are correct that the data is stable 150ns or 90ns after the Chip
Select line is stable. The data will stay stable as long as the CS line
and address lines are stable.
The CPU involve is an 8051. The date of the circuit the OP has (1985) is
old enough to believe that it is a 12Mhz processor with an internal
divide by 12.
So the memory cycle time of the CPU is 1us, the cpu will "wait" most of
that 1us before it latches the data from the ROM.
I'll check an old 8051 data sheet later, but a 90ns ROM will work just fine.
doanld
robb
Donald,
you are correct about the 8051, it is running at 12Mhz .
and in case i have not mentioned before the D23256AC lines/pins
are consistent with the 27c256 in terms of conections made to the
8051
now i am just awaiting new mouser ROMs to test the new style
ROM reads that look like real code.
no readable ascii strings such as copyright strings or company
name in the new style ROM reads though ?? so that has me still
a little suspicious but as code the new ROM download actually
runs and loop in an 8051 simulator so that is promising.
Thanks for all the help donald,
robb
robb
"Ian Malcolm" <valid.address...@invalid.invalid> wrote
in message news:flch39$d1h$1...@inews.gazeta.pl...
> robb wrote:
> > "Ian Malcolm" wrote:
> >>
> >> A bit of research leads me to the 87C256 Latched EPROM which
is intended
> >> for use in applications with /ALE on pin 20. If his
programmer supports
> >> this device or equivalent he should be golden.
> >>
[trim -- lots of very helpful advice]
Thanks Ian,
For all the help and useful advice.
I forgot to thank you for taking time and effort to help.
I do appreciate all the help.
Now, still waiting for new ROMs to try out all the advice.
>
> I recccomend you find a file sharing service to post the dump
to then
> give us a link for anyone with 8051 experience can then take a
look at
> it. It would be nice to know make model and description of the
unit you
> are trying to repair as well.
>
> Good luck with it, I admire your persistance
> HAPPY NEW YEAR.
>
Ah persistance, well i have always enjoyed challenges of big
problems, trying to figure out how things function and
elegant/simple solutions.
>
> P.S. I have a new year resolution for you: If it aint broke
dont fix it!
> (Unless you can afford to sacrifice one to your curiosity)
>
I guess the original problem was not challenging enough to
supress curiosity?
This project happened to be affordable, i usually check
cavalier at the door where affordability is a dominant factor.
thanks again for all the help,
robb
> ---