Help understanding PROM images

[BJM]

I got access to a PROM reader and dumped out a couple of PROMs data. I am confused as to how the addressing works. I am comparing to the GNTTYPE spreadsheet. It looks like every second address (the even ones) is ignored for most of the tables other than a few odd balls. However, those ignored addresses have some data in them.

Any experts know what I am missing?

Example location 00018 has 98 41 as the HEX data, 41 converts to ~24 degrees of timing. What is the 98 for?

 

[ijames]

Are displaying the data as 16 bit or 8 bit data? I ask because each address should have one byte or 8 bits worth. Most hex editors display 16 bytes per line, so it would look something like this, all in hex, where the first column is the address:

0000 01 44 A1 66 EE FF 33 41 8A 90 77 2F DD 40 AA CC
0010 88 88 88 88 88 88 88 22 22 22 22 22 22 FF AA 00

Here location 0000 contains 01, location 000F is CC, location 0010 is 88, and 001F is 00. The hex editor will start at address 0000 but in the ecm memory map the eprom starts at 3000 so if in the ecm disassembly listing you see the command "LDA $3000", it would load the data value at 0000 as displayed by your hex editor which again, would be 01 in the example above. I don't remember where the spreadsheet addresses start at 0000 or 3000, but by now you should be able to tell . Hope that's enough to get you started.

 

[BJM]

Here is part of the data I dumped

000000 b7 00 19 00 00 00 00 00 00 00 20 00 0f 9e 41 00
000010 41 00 41 00 41 06 41 00 41 98 41 00 44 00 44 0f
000020 44 00 44 08 44 00 44 02 44 00 44 0f 44 00 44 0f
000030 44 9e 4a 08 4a 00 4a 08 47 c0 47 15 47 9e 41 08
000040 41 00 41 08 41 c1 41 15 41 9e 44 62 44 99 44 62
000050 4a 03 4d 15 4d 99 47 62 47 03 47 15 41 9e 41 08


If I look at the above data at location 000E the value is 41 which I believe is ~23 degrees timing at 400 RPM. At location 000F the value is 00. Further along we have location 0015 with another 41 in it. Location 0016 has 06. What is the 06 for? The GNTTYPE spreadsheet makes no mention of theseeven addresses.

 

[tminer]

Does your reader have an option like High Byte/Low Byte? Should be set to Both, not High. Your data is being loaded into every other address in the buffer, so 0002 is byte 0001 of the chip, 000E is 0007 etc. This is what happens when High Byte only mode is used.

Reading every other byte of your buffer display yields this:

000000 b7 19 00 00 00 20 0f 41 41 41 41 41 41 41 44 44

which corresponds to the recall chip, except for the checksum (0000 & 0001).

Might also be caused by having the wrong eprom type selected, but I would think the results would be less systematic. I don't have pinouts handy to check that. Should use 2732, 2732A, 27C32, or 27C32A. It normally doesn't matter which on read, but can on write!

Tom

 

[dennisL]

BJM, the problem is the display you see from the chip read. You get 2 bytes displayed for each one read. Go back and check the settings for the prom reader. Start with the chip type, then check the others. If you're not sure about one of them, post it here and we'll figure it out.

We use 4K chips. The addresses in the chip start at $0000 and go to $0FFF. In the car, the same chip uses addresses $3000 through $3FFF.

 

[BJM]

Figured out what was wrong

I was using the work EPROM programmer. It was set for 16 bit word length from a previous user. It was left on and was filling my chip into the first 8 bit chunk and someone else's chip into the second chunk. It had this other chip still in RAM from who know when! I am not an electrical engineer, they tell me they commonly use two separate PROMS to get the 16 bit word length. The extra data was from something unrelated.