Reading and Programming Chips using offsets

[EagleMark]

Programming chips using offsets. From Moates article! (http://support.moates.net/2010/04/05/programming-chips-using-offsets/)


File Size ----- Chip ------ Buffer Start -> End ----- Chip Start -> End
4k ( 4096 ) - AT29C256 - 000000 -> 000FFF ------ 007000 -> 007FFF
16k (16384) - AT29C256 - 000000 -> 003FFF ----- 004000 -> 007FFF
32k (32768) - AT29C256 - 000000 -> 007FFF ----- 000000 -> 007FFF
4k ( 4096 ) - 27SF512 - 000000 -> 000FFF -------- 00F000 -> 00FFFF
16k (16384) - 27SF512 - 000000 -> 003FFF ------- 00C000 -> 00FFFF
32k (32768) - 27SF512 - 000000 -> 007FFF ------- 008000 -> 00FFFF
56k (57344) - 27SF512 - 000000 -> 00DFFF ------- 002000 -> 00FFFF
64k (65536) - 27SF512 - 000000 -> 00FFFF ------- 000000 -> 00FFFF
-------------------------------------------------------------------

Now the reading of chips I can't find anywhere so we will start one here.

File Size ------ Chip-----Buffer Start-> End ----- Chip Start -> End
4k - (4096) - 2732a --- 000000 -> 000FFF ----- 00F000 -> 00FFFF
27C128
27C256
64k (65536) 27C512 --- 00000 -> 0FFFF ------- 00000 -> 0FFFF


Anyone who has information just post it up and I will complete this so everyone has a place to go for the proper offsets to read and write chips. Thanks!

[1project2many]

Not sure why you had to use those offsets. Chip / file address should be 000 to FFF on the 2732 or 2732A. Otherwise, reading the chip is the same as programming in terms of addressing. The most consistent method I know is to read the entire address range then view the file in a hex editor. If you see the chip "repeating" at the 1/2 or 1/4 point then you know the actual file size is a fraction of the chip size.

[EagleMark]

I don't know much about the offsets or hex but I read the chip with your offsets and the ones listed above and they both look the same in the hex editor.

[Six_Shooter]

Not sure why you had to use those offsets. Chip / file address should be 000 to FFF on the 2732 or 2732A. Otherwise, reading the chip is the same as programming in terms of addressing. The most consistent method I know is to read the entire address range then view the file in a hex editor. If you see the chip "repeating" at the 1/2 or 1/4 point then you know the actual file size is a fraction of the chip size.


This is what I do.

The only ones that through a loop into that (or make you think) are the ones that don't have anything at the beginning of the chip and start an 1/8 or so into the hex editor addressing.

[1project2many]

I don't know much about the offsets or hex but I read the chip with your offsets and the ones listed above and they both look the same in the hex editor.

We're using different tools to read the chip and that may explain why the Moates article recommends different addresses. You should learn some basics about using hex and working with addresses and a hex editor. There are times when you might want to hand edit a calibration or when you might want to confirm that a file isn't corrupt that would require the hex edit tool.


The only ones that through a loop into that (or make you think) are the ones that don't have anything at the beginning of the chip and start an 1/8 or so into the hex editor addressing.

Some of the 2.3 cals have data all over the place. I thought my disassembler was broken when I first started working on one because it just wasn't arranged like a normal GM cal. And the coding is different, too. I think the code was generated by a newer compiler than what's used for many of the more common cals.