Calculating the Checksum

[Roger Heflin]

A couple of questions.  I have a 93 Z28  (32kb) eprom.  I am working on the
disassembly.   I have put the eprom in memory at several locations, the
location that seems to work is $8000, with it there, the code seems to
be writing to things listed as ram in my databooks, any only reading from
things that are known to be rom.   Is this a resonable method to use?

Another thing, I assume the checksum code is in the build in rom, and not
in the rom I have, since you really can't validate a checksum with code
you don't even know if works.

Mostly right now I am just decoding what looks like initialization stuff.
I assume that probably the block learns/integrators would be initialized to
128. I also would guess that alot of the other things would be initialized to
0.  So far things look pretty simple, but I am only into the simple stuff.

I have a 68hc11 disassembler program, a detailed 6809 instruction book and
decoder card, and a 1988 vintage motorola single chip microcomputer data 
book that lists quite a few variants that all use pretty much the same
instruction set with a few additions, and extra ram/rom/portio/ad varing
depending on what was specified.    I would guess that GM is using a 
custom one of these chips, probably with a burned into the chip rom, for
default operation.

				Roger

On Fri, 11 Sep 1998, Georg Faustmann wrote:

> If the system is a Delco unit, then the Checksum on/off byte may be at
> $0008, set this to $AA, the checksum (stored at $0006,$0007) should be the
> total of all the bytes from $0008 to then end of the chip. 
> 
> In some cases the address of the checksum switch could be offset, eg $3008,
> $8008.
> 
> Notes on how to find checksums:-
> 
> If you had access to an emulator with a Romwatch (real time trace) type
> function where the actual bytes being read at that moment in time are
> highlighted, then you can sit there and watch where the bytes start to be
> sequentially accessed by the CPU (usually every 10 seconds or so), you can
> then scroll down until you find out where they stop being accessed, and
> will give you the start and end point of the checksum. Then add these range
> of numbers up, and look for a 16 bit value that is the last 16 bits of this
> sum, and search for this number outside of the checksum range, because it
> can't be in the checksum area.
> 
> Georg
>