microcontroller ROM copy trouble ?

<gqrxzy8974@ftml.net> wrote in message
news:e16006dc-aebf-4d57-8a46-8a1e9409e066@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 think i may not be clear ?
Click to expand...
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.
Click to expand...
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)).
Click to expand...
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...
Click to expand...
thanks for the help,
robb
 
"mpm" <mpmillard@aol.com> wrote in message
news:08ba70e9-b057-4d39-9962-7f2aafba453f@e25g2000prg.googlegroups.com...
On Dec 27, 2:28?pm, "robb" <s...@where.on.net> wrote:

thanks for any help i ?am stuck again,
robb
Click to expand...
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.
 
robb wrote:

gqrxzy8974@ftml.net> wrote in message
news:e16006dc-aebf-4d57-8a46-8a1e9409e066@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 think i may not be clear ?
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
Click to expand...
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.
 
robb wrote:

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
Click to expand...
Looks like gibberish to me.

What happens if you try reading it as a 27C512 ? Just an idea.

Graham
 
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.
Click to expand...
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.
 
On Dec 28, 12:43�pm, "robb" <s...@where.on.net> 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.
Click to expand...
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
 
On Dec 29, 5:31�am, "TT_Man" <Some...@ntlworld.com> wrote:
"mpm" <mpmill...@aol.com> wrote in message

news:08ba70e9-b057-4d39-9962-7f2aafba453f@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.
Click to expand...
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 wrote:

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.
Click to expand...
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
 
"mpm" <mpmillard@aol.com> wrote in message
news:7744ce75-1258-4abb-8af2-6af4e203cd02@x69g2000hsx.googlegroups.com...
On Dec 28, 12:43�pm, "robb" <s...@where.on.net> 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.

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. (?)

Thanks for all the help and info mpm,
Click to expand...

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.
Click to expand...
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.
Click to expand...
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
 
"TT_Man" <Someone@ntlworld.com> wrote in message
news:rgvdj.17507$745.840@newsfe1-win.ntli.net...
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.

thanks TT_MAN,
Click to expand...

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
 
robb wrote:

when i tie the p22 (oe) high then i read all 0xFF all the way
floating gives similar as when connected
Click to expand...
Now tie it low.

AND look at how it's connected on the equipment pcb.

Graham
 
Lets start with a few basics.

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
 
"Eeyore" <rabbitsfriendsandrelations@hotmail.com> wrote in
message news:47768628.E505059B@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

Thanks for the help,
Click to expand...

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
 
"donald" <Donald@dontdoithere.com> wrote in message
news:Wsedncn0c70wPevanZ2dnUVZ_sqinZ2d@comcast.com...
Lets start with a few basics.

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
Click to expand...
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
 
robb wrote:
"donald" <Donald@dontdoithere.com> wrote in message
news:Wsedncn0c70wPevanZ2dnUVZ_sqinZ2d@comcast.com...

Lets start with a few basics.

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


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
:10 0000 00 02 0202 02020202020202020202020202D0
: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


Ok, here is your first problem.
Click to expand...

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
 
donald schrieb:
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.
Click to expand...
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



--
www.ehydra.dyndns.info
 
Henry Kiefer wrote:

donald schrieb:

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



You are correct, the bytes and bits should be in the same location after
Click to expand...
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
 
donald schrieb:
Henry Kiefer wrote:

donald schrieb:

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



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 ??
Click to expand...
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


--
www.ehydra.dyndns.info
 
Henry Kiefer wrote:
donald schrieb:

Henry Kiefer wrote:

donald schrieb:

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



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
Click to expand...
around.

Looking at the vectors kind of indicated that.

Don't you just love trouble shooting in the dark ?

donald
 
donald schrieb:
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.
Click to expand...
That was the trigger for me.


Looking at the vectors kind of indicated that.
Click to expand...
I don't spent time to read all posting, sorry.


Don't you just love trouble shooting in the dark ?
Click to expand...
That is my job to shot. I like it since 25 years.


Greetings -
Henry



--
www.ehydra.dyndns.info
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top