Not only would I expect a lot of variation in the beginning, but...
(Not a single Byte has anything in the high nibble?)
At the end I would expect blocks of 'FF'.
When an EPROM is erased, the individual bits are set to '1'. Programming is the process of 'clearing' bits. As programming takes a bit of time for each Byte, unused Bytes will be set to 'FF' to avoid having to program those locations.
Generally, the lower addresses will contain the initialisation code, then main program. Assorted 'premade' functions will be tucked in above that again, and finally and lookup tables, bitmaps and other data.
These data are usually aligned with a 'round number' of some sort, so there will be gaps between them. That means blocks of 'FF' at regular intervals.
Erasing by removing the sticker?
Well, maybe, if you left it out in direct sunshine for the next month or three...
(The windowsill won't work, though, unless you open the window because glass blocks a lot of 'useful' wavelengths )
I want to confirm something. For the EPROM, I am testing that pin1 and pin28 (VCC) are hooked together. Does that sound right?
It could be, for a 32K EPROM.
If you can find some, and a programmer, these are useful for changes : http://media.digikey.com/pdf/Data%20Sheets/Winbond%20PDFs/W27C512.pdf
Those are EPROM pinout, MTP parts, so you can re-pgm in a programmer. (needs Vpp)
Or I think the 27SF512 was the same MTP approach - if you can find those in DIP28
Or you can use an EEPROM and an adaptor-socket stack.
EPROM data.zip Here you go Gadgetman, I think it is right. PST only displays so many entries, so I did it in batches. They are in .CSV format
Let me know if you think they are wrong. I could have the MSB-LSB backwards. I do know the address is correct.
That does look quite wrong,
* A 80C154 is an 80C51 variant, so it starts from 000H usually with a LJMP Address => 02 UU LL in HEX
( more rarely an AJMP may be used )
* Opcodes are full bytes, the data seems to only be low-nibbles ?
Here is a small 8051 HEX snippet, as an example reference :
( has LJMP to 0776H and 32H opcode is a RETI on the interrupt vector area.
Once you have a valid hex file from the EPROM, you could run an 8051 Simulator, which should let you see the command-case tree for serial receive, so you can work out what to send
The sticker covers the rest. I don't want to take it off, because my luck I would erase the chip.
If you slide a blade under the sticker, you can take a picture and replace the sticker.
The access speed may matter, depending on the clock speed. (EPROM can go down to 45ns, EEPROMS tend to be slower)
Any crystals visible neat the 80C154 ? ( eg 11.0592MHz or 22.1184MHz or similar Baud-related values )
That does look quite wrong,
* A 80C154 is an 80C51 variant, so it starts from 000H usually with a LJMP Address => 02 UU LL in HEX
( more rarely an AJMP may be used )
* Opcodes are full bytes, the data seems to only be low-nibbles ?
I had the MSB - LSB reversed.
Here is a small 8051 HEX snippet, as an example reference :
( has LJMP to 0776H and 32H opcode is a RETI on the interrupt vector area.
Once you have a valid hex file from the EPROM, you could run an 8051 Simulator, which should let you see the command-case tree for serial receive, so you can work out what to send
I re-ran the updated program, Here is the updated ROM file. it looks a lot better. I have been having problems with my breadboard, had to move to a different spot. 0000 to 1FFF _V2.zip
If you slide a blade under the sticker, you can take a picture and replace the sticker.
The glue was screwing up a good picture. But the markings are;
AM27C64
-150DC
9520EPB
I looked it up, I found this. I re-did the wiring to match what the datasheet said.
The access speed may matter, depending on the clock speed. (EPROM can go down to 45ns, EEPROMS tend to be slower)
Any crystals visible neat the 80C154 ? ( eg 11.0592MHz or 22.1184MHz or similar Baud-related values )
I re-did the wiring to match what the datasheet said.
I think it is a 7.3728MHz crystal
That looks better, and just an 8K EPROM, so there is not much code in this.
(you can use MTP 512k parts if you want to change anything in this, either just duplicate the 8K image 8x, or place it where you know the Upper-Address pin wiring reads from )
if you can reformat that csv dump into intel hex, you can load into a simulator.
A 7.3728MHz xtal is 64 x 115200, and at that speed, 150ns is fine.
That looks better, and just an 8K EPROM, so there is not much code in this.
(you can use MTP 512k parts if you want to change anything in this, either just duplicate the 8K image 8x, or place it where you know the Upper-Address pin wiring reads from )
if you can reformat that csv dump into intel hex, you can load into a simulator.
A 7.3728MHz xtal is 64 x 115200, and at that speed, 150ns is fine.
I can reformat it, but from what I am seeing the intel HEX format requires a ":" to start each line. I have looked through the data, and I am not finding $3A anywhere. Is there another way that it could be formatted?
I did notice $02 showed up a lot, including address $0000 and $0001. Could that be the marker for the beginning of a line?
You just take the binary data, and prefix the ":", lengthB,AddressW,00, then [YourDataInHex] then append ChecksumB (+CrLf)
Typically each intel line may be 16 or 32 bytes of YourData, (you do not need variable length for Hex dump, so choose fixed 20H is fine)
Last line in file is :00000001FF
You just take the binary data, and prefix the ":", lengthB,AddressW,00, then [YourDataInHex] then append ChecksumB (+CrLf)
Typically each intel line may be 16 or 32 bytes of YourData, (you do not need variable length for Hex dump, so choose fixed 20H is fine)
Last line in file is :00000001FF
Ok, it will take me some time, I am treading new waters.
To get around the display buffer limitations of PST, I often use HyperTerminal. Setting up a serial port is rather obtuse, but the "save text to file" menu option works like a charm for saving CSV dumps from a prop. An added bonus is that HyperTerminal runs just fine on slow/old PCs and prioritizes saving data to disk over display. (so fewer errors in the final file) Oh, and it only resets the Propeller when you close the serial port so "program to RAM" is still useful.
You just take the binary data, and prefix the ":", lengthB,AddressW,00, then [YourDataInHex] then append ChecksumB (+CrLf)
Typically each intel line may be 16 or 32 bytes of YourData, (you do not need variable length for Hex dump, so choose fixed 20H is fine)
Last line in file is :00000001FF
OK, I got little sleep last night trying to figure out how to turn the data from the EPROM to intel HEX format. For the file to be considered a "Intel HEX" format, every line MUST start with a colon ":". no where in the data from the EPROM am I seeing a colon ($3A). I do not have any spectilized equipment to read this EPROM. I am just using a prop to drive the address lines, and to read what is at every address, then display it on "Parallax Serial Terminal". I have looked for programs that will take the EPROM dump data, and convert it to Intel HEX, But you either have to pay for them (not doing it for one time), or they convert HEX to binary format.
I have NO experience with this. I am not afraid to learn, and explore. But I am just shooting in the dark.
rom dump.txt Here is the rom dump. after every byte of data, i added a space, then after every 16th byte I added a "NewLine" Just so the data can be seen easily.
rom dump.txt Here is the rom dump. after every byte of data, i added a space, then after every 16th byte I added a "NewLine" Just so the data can be seen easily.
TC,
That output is looking a lot better.
You will not find a colon, start code, byte count, address, record type or checksum on the EPROM. The INTEL Hex format is output from software, (ie assembler), to be used with an EPROM Programmer. Only the OP Codes, (DATA), get burned to the EPROM.
The first instruction is a Jump to $0278, so we should assume that the init program starts there.
(At this point it would be nice if every line began with the address )
What's weird is that on address $0278 is a SETB for 95.
That is, it sets bit $95 in the Special Function registers, and I can't find that that exact bit is used for anything.
The stuff before $0278 I assume(for now) to be a library of functions or possibly interrupt routines.
Near the end of the file I see a block of 'FF' that ends at the end of a line. Odds are that what follows is a block of data.
Odds are that there's a block of data somewhere in there that contains bitmaps of a character set.
Finding that would reduce the amount of code to sift through.
(If the bitmaps were 8x8, I'd expect a '00' at the beginning and end of each character bitmap, and as each bitmap would be 8Bytes, quite probably aligned to an xxx0H address, so as to make lookup more efficient. Therefore I expected to see '00' at the beginning of quite a few lines, and also a pair in the middle and another at the end, but no... )
rom dump.txt Here is the rom dump. after every byte of data, i added a space, then after every 16th byte I added a "NewLine" Just so the data can be seen easily.
You are actually closer than you think.
You should not expect to find ':' in the ROM, that Char is purely in the HEX ASCII file, just like ASCII '0' '2' etc is not actually in the ROM.
That ASCII info is stripped when the Hex file is loaded, and just the Binary Data is placed into memory
You have now this
02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26
FF FF FF 32 FF FF FF FF FF FF FF 32 FF FF FF FF
just add
':10'+AddressHex+'00'+[02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26]+CheckSumHex+CrLf
(no gaps in the Data hex)
and end the dump with ':00000001FF'+CrLf
Addit : This is what you want to end up with for those 2 lines above :
( A picture is worth 1000 words )
The first instruction is a Jump to $0278, so we should assume that the init program starts there.
(At this point it would be nice if every line began with the address )
What's weird is that on address $0278 is a SETB for 95.
That is, it sets bit $95 in the Special Function registers, and I can't find that that exact bit is used for anything.
The stuff before $0278 I assume(for now) to be a library of functions or possibly interrupt routines.
Near the end of the file I see a block of 'FF' that ends at the end of a line. Odds are that what follows is a block of data.
Odds are that there's a block of data somewhere in there that contains bitmaps of a character set.
Finding that would reduce the amount of code to sift through.
(If the bitmaps were 8x8, I'd expect a '00' at the beginning and end of each character bitmap, and as each bitmap would be 8Bytes, quite probably aligned to an xxx0H address, so as to make lookup more efficient. Therefore I expected to see '00' at the beginning of quite a few lines, and also a pair in the middle and another at the end, but no... )
You have me lost, but that is to be expected since I have no experience with this. But I am very willing to learn. Is there anything that can help me understand (even a little) what each byte represents?
You should not expect to find ':' in the ROM, that Char is purely in the HEX ASCII file, just like ASCII '0' '2' etc is not actually in the ROM.
That ASCII info is stripped when the Hex file is loaded, and just the Binary Data is placed into memory
You have now this
02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26
FF FF FF 32 FF FF FF FF FF FF FF 32 FF FF FF FF
just add
':10'+AddressHex+'00'+[02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26]+CheckSumHex+CrLf
(no gaps in the Data hex)
and end the dump with ':00000001FF'+CrLf
I should be able to do that. I have a question, Where or how do I get the "AddressHex?
I should be able to do that. I have a question, Where or how do I get the "AddressHex?
That's just the 4 hex nibble value, of the Address of the first byte of Following Data.
In your case, with 16 byte lines those 4 ASCII hex chars will be, for each line :
That's just the 4 hex nibble value, of the Address of the first byte of Following Data.
In your case, with 16 byte lines those 4 ASCII hex chars will be, for each line :
Comments
Pop the label with a razor blade and let's see what's under the hood.
And you do realize this is a 5V chip, right. Resistors to all Prop pins.
Not only would I expect a lot of variation in the beginning, but...
(Not a single Byte has anything in the high nibble?)
At the end I would expect blocks of 'FF'.
When an EPROM is erased, the individual bits are set to '1'. Programming is the process of 'clearing' bits. As programming takes a bit of time for each Byte, unused Bytes will be set to 'FF' to avoid having to program those locations.
Generally, the lower addresses will contain the initialisation code, then main program. Assorted 'premade' functions will be tucked in above that again, and finally and lookup tables, bitmaps and other data.
These data are usually aligned with a 'round number' of some sort, so there will be gaps between them. That means blocks of 'FF' at regular intervals.
Erasing by removing the sticker?
Well, maybe, if you left it out in direct sunshine for the next month or three...
(The windowsill won't work, though, unless you open the window because glass blocks a lot of 'useful' wavelengths )
Or I have a Programer that will read it.
It could be, for a 32K EPROM.
If you can find some, and a programmer, these are useful for changes :
http://media.digikey.com/pdf/Data%20Sheets/Winbond%20PDFs/W27C512.pdf
Those are EPROM pinout, MTP parts, so you can re-pgm in a programmer. (needs Vpp)
Or I think the 27SF512 was the same MTP approach - if you can find those in DIP28
Or you can use an EEPROM and an adaptor-socket stack.
That does look quite wrong,
* A 80C154 is an 80C51 variant, so it starts from 000H usually with a LJMP Address => 02 UU LL in HEX
( more rarely an AJMP may be used )
* Opcodes are full bytes, the data seems to only be low-nibbles ?
Here is a small 8051 HEX snippet, as an example reference :
( has LJMP to 0776H and 32H opcode is a RETI on the interrupt vector area.
For a good 8051 reference, with opcodes included, try something like AT89LP51RD2
http://www.atmel.com/Images/doc3714s.pdf
Once you have a valid hex file from the EPROM, you could run an 8051 Simulator, which should let you see the command-case tree for serial receive, so you can work out what to send
This is probably the best simulator
http://turbo51studio.orgfree.com/downloads/turbo51studio-latest-setup.zip
If you slide a blade under the sticker, you can take a picture and replace the sticker.
The access speed may matter, depending on the clock speed. (EPROM can go down to 45ns, EEPROMS tend to be slower)
Any crystals visible neat the 80C154 ? ( eg 11.0592MHz or 22.1184MHz or similar Baud-related values )
I had the MSB - LSB reversed.
I re-ran the updated program, Here is the updated ROM file. it looks a lot better. I have been having problems with my breadboard, had to move to a different spot.
0000 to 1FFF _V2.zip
The glue was screwing up a good picture. But the markings are;
I looked it up, I found this. I re-did the wiring to match what the datasheet said.
I think it is a 7.3728MHz crystal
CON _clkmode = xtal1 + pll1x _xinfreq = 5_000_000That looks better, and just an 8K EPROM, so there is not much code in this.
(you can use MTP 512k parts if you want to change anything in this, either just duplicate the 8K image 8x, or place it where you know the Upper-Address pin wiring reads from )
if you can reformat that csv dump into intel hex, you can load into a simulator.
A 7.3728MHz xtal is 64 x 115200, and at that speed, 150ns is fine.
I can reformat it, but from what I am seeing the intel HEX format requires a ":" to start each line. I have looked through the data, and I am not finding $3A anywhere. Is there another way that it could be formatted?
I did notice $02 showed up a lot, including address $0000 and $0001. Could that be the marker for the beginning of a line?
? Try
http://en.wikipedia.org/wiki/Intel_HEX
You just take the binary data, and prefix the ":", lengthB,AddressW,00, then [YourDataInHex] then append ChecksumB (+CrLf)
Typically each intel line may be 16 or 32 bytes of YourData, (you do not need variable length for Hex dump, so choose fixed 20H is fine)
Last line in file is :00000001FF
Ok, it will take me some time, I am treading new waters.
Marty
OK, I got little sleep last night trying to figure out how to turn the data from the EPROM to intel HEX format. For the file to be considered a "Intel HEX" format, every line MUST start with a colon ":". no where in the data from the EPROM am I seeing a colon ($3A). I do not have any spectilized equipment to read this EPROM. I am just using a prop to drive the address lines, and to read what is at every address, then display it on "Parallax Serial Terminal". I have looked for programs that will take the EPROM dump data, and convert it to Intel HEX, But you either have to pay for them (not doing it for one time), or they convert HEX to binary format.
I have NO experience with this. I am not afraid to learn, and explore. But I am just shooting in the dark.
TC,
That output is looking a lot better.
You will not find a colon, start code, byte count, address, record type or checksum on the EPROM. The INTEL Hex format is output from software, (ie assembler), to be used with an EPROM Programmer. Only the OP Codes, (DATA), get burned to the EPROM.
Refering to the document: http://en.wikipedia.org/wiki/Intel_HEX
Are you using resistors in-line with the Data in to the Propeller? I assume you are powering the EPROM with 5 volts.
(At this point it would be nice if every line began with the address )
What's weird is that on address $0278 is a SETB for 95.
That is, it sets bit $95 in the Special Function registers, and I can't find that that exact bit is used for anything.
The stuff before $0278 I assume(for now) to be a library of functions or possibly interrupt routines.
Near the end of the file I see a block of 'FF' that ends at the end of a line. Odds are that what follows is a block of data.
Odds are that there's a block of data somewhere in there that contains bitmaps of a character set.
Finding that would reduce the amount of code to sift through.
(If the bitmaps were 8x8, I'd expect a '00' at the beginning and end of each character bitmap, and as each bitmap would be 8Bytes, quite probably aligned to an xxx0H address, so as to make lookup more efficient. Therefore I expected to see '00' at the beginning of quite a few lines, and also a pair in the middle and another at the end, but no... )
You are actually closer than you think.
You should not expect to find ':' in the ROM, that Char is purely in the HEX ASCII file, just like ASCII '0' '2' etc is not actually in the ROM.
That ASCII info is stripped when the Hex file is loaded, and just the Binary Data is placed into memory
You have now this
02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26
FF FF FF 32 FF FF FF FF FF FF FF 32 FF FF FF FF
just add
':10'+AddressHex+'00'+[02 02 78 32 FF FF FF FF FF FF FF C0 E0 02 00 26]+CheckSumHex+CrLf
(no gaps in the Data hex)
and end the dump with ':00000001FF'+CrLf
Addit : This is what you want to end up with for those 2 lines above :
( A picture is worth 1000 words )
No, but I am using TI's txs0108e between the prop and the I/O lines on the EPROM. It has not done me wrong yet.
You have me lost, but that is to be expected since I have no experience with this. But I am very willing to learn. Is there anything that can help me understand (even a little) what each byte represents?
I should be able to do that. I have a question, Where or how do I get the "AddressHex?
That's just the 4 hex nibble value, of the Address of the first byte of Following Data.
In your case, with 16 byte lines those 4 ASCII hex chars will be, for each line :
Ahh, that makes sense.
As well as the data sheet I linked above, there is
Atmel 8051 Microcontrollers Hardware Manual
www.atmel.com/images/doc4316.pdf
and another simulator (MC-51) can be found here
http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/index-e.html
TS51 simulator I see has a couple of minor bugs in the DisAsm view of hex loaded data.
MC-51 has cleaner dis-asm until those are fixed.
Wonderful, Thank you