Re: Any raw data specs for the Apple IIgs BRAM?

Laroquod <laroquod@xxxxxxxxx> wrote:

Through trial and error, I have pinpointed the slot assignment data to
the following line:

bram3[20] = 01 00 00 00 00 00 00 01 00 00 00 00 05 02 02 00

If I alter the Startup Slot in the Apple IIgs control panel to Slot 6,
the line will change to look like this:

bram3[20] = 01 00 00 00 00 00 00 01 06 00 00 00 05 02 02 00

At this point, I felt like I had solved it, and all I had to do was
change one byte. Then I noticed that the last four bytes of the BRAM
also change with the configuration in a way I am having trouble
nailing down. I am talking about the last four bytes of the final
line:

bram3[f0] = ff ff ff ff ff ff ff ff ff ff ff ff 36 2d 9c 87

Those four bytes seem to change no matter what configuration settings
I twiddle, so I suspect that they represent a checksum to verify the
validity of the BRAM.

Is this the case?

Almost certainly. I know there is a checksum in the parameter RAM, but
don't recall ever being aware of the specific details.

A little educated guesswork will help narrow it down.

For starters, it is a 32-bit value. Does it appear to change
significantly for a small change in the data?

If so, this is a very strong hint that is actually a CRC (cyclic
redundancy check). There is a standard CRC algorithm which uses a 32-bit
polynomial (known as CRC-32), using a specific polynomial value (though
other values are possible).

(I could be wrong - this might be something simpler than a CRC.)

A CRC of a block of data produces a number which is a special type of
checksum, equal in size to the number of bits in the polynomial. Its
primary function is to detect common types of errors in communications
(one-off bit errors and short error bursts) but it is often used for
doing a checksum of memory-based data.

The CRC calculation works by treating the source data as an N-bit
polynomial and doing modulo-2 division by the CRC (which is the same as
an exclusive-OR on straight binary data). The calculation involves
feeding the result back into itself for each subsequent bit of the input
data, ultimately ending up with a remainder which is used as the
checksum.

To verify the CRC, the calculation is repeated and the remainder should
match.

A single bit change in the source data will produce a significant change
in the remainder.

The main issue is identifying the specific parameters of the algorithm
used in this case:

1. Which polynomial is used. There is only one standard polynomial I
know of for a 32-bit CRC (but I've encountered two standard ones and one
other obscure one for 16-bit CRC).

2. Whether the calculation uses a preset value of all zeros or all ones.
Zero is more likely, but some implementations use all ones.

3. Which order the bits are processed within each byte of source data.
The more common convention is to process the LSB first.

4. Whether the remainder is complemented before being stored. This
typically goes along with the preset value: if zero, the CRC is probably
stored directly, but if all ones, the CRC is probably complemented. This
isn't a hard rule.

5. Which byte and bit order is used to store the remainder. This may
depend on the endianness of the host platform, and whether the data is
to be transmitted over a serial line.

I'm sure there are utility programs available which can calculate a
CRC-32 for a chunk of data, but they might not be customizable for all
of the above parameters, so it may be difficult to determine exactly
which permutation is used by the IIgs parameter RAM.

And if so, can I recalculate this checksum outside of a running IIgs so
that it will still pass muster?

If you can find the right algorithm, then yes.

P.P.S If I solve this for the ROM 03 BRAM I am going to try to do the
same thing for the ROM 01 BRAM so any tips in that regard, if the
formula differs between the two, would also help.

It is likely to be the same.

--
David Empson
dempson@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: CRC versus CheckSum
    ... I have a situation where I have a byte in which to place either a checksum ... Our packets cannot have bytes in a packet swapped in order (the transport ... jsut as good as the CRC. ... Neither detect all errors (there are after all the same number of states for the sum in either case). ...
    (comp.arch.embedded)
  • Re: Opinions on 16-bit checksums.
    ... it's no longer a checksum, ... >> cancel themselves out, but a CRC would. ... I've witnessed no failures or oddities. ... I don't think it can be assumed that ROMs ...
    (comp.arch.embedded)
  • Re: Opinions on 16-bit checksums.
    ... >> possibly result in an unchanged CRC checksum. ... > There are two big reasons CRCs are used in serial communications: ... algorithms that consider the order of the data as well as the value - a ...
    (comp.arch.embedded)
  • Re: Crc16 on power failure
    ... a checksum is faster to calculate than a CRC by software. ... True, they are faster, but they are not nearly as good at detecting ... coonsider running an EEC on each parameter instead of a block check. ...
    (comp.arch.embedded)
  • Re: Opinions on 16-bit checksums.
    ... out there besides CRC and "add up the bytes". ... There are other checksum ... I don't think it can be assumed that ROMs ... ROMs do have the same error characteristics as a serial data ...
    (comp.arch.embedded)