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

Laroquod <laroquod@xxxxxxxxx> wrote:

On Apr 1, 5:44 pm, demp...@xxxxxxxxxxxxx (David Empson) wrote:
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?

Yes. All four bytes change even when I modify a single setting.

OK, so it is likely to be a CRC. It might still be a simpler algorithm
which generates a similar degree of variation in the checksum.

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.

In my first attempt at a reply, I examined these factors in detail and
figured out that this basically added up to 16 or 32 different trials
I would have to conduct (making the assumption that it is 32-bit,
which sounds pretty safe to me). I came up with a couple of questions
as to implementation of these trials. One of them was: if I compile
test code on PowerPC G4 that is also a Motorola CPU will that
eliminate endianness as a factor?

No. The 6502 and 65816 are little-endian. The PowerPC (as used in the
Mac) is natively big-endian.

The 6502 (and derivatives) are not Motorola CPUs. The 6502 was developed
by MOS Technology by some of the people who worked on the Motorola 6800,
so it shares many design features from that processor, but is much
simpler (and cheaper). One of the significant differences is that the
endianness was reversed.

CRC calculations are done working on a single byte of data at a time,
and endian issues could be dealt with by doing a byte order reversal at
the end of the calculation. The body of the loop should be done using
the native endianness of the host platform.

In some cases, you might need to do a full 32-bit reversal of the
remainder to get the same result, as it depends on the shift order of
the CRC algorithm. See my post earlier today else-thread for a typical
example in 6502 assembly language (converted from the CRC-32
implementation I use at work).

If you can save me some time by pointing me in the right direction I
might be able to analyse it myself to identify the specific
characteristics of the algorithm.

The main point that would assist me is knowing the memory location at
which the IIgs stores the RAM-based copy of the PRAM, assuming it is
stored in its entirety inlcuding the checksum. I can then do a few
controlled tests and feed them into an adaptable CRC-32 calculator to
see whether I can spot the details.

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.

Previoiusly I googled a few sites about CRC and posted the addresses
here. One was a CRC online calculator (which unsurprisingly given your
factors didn't work for me). Another was a javascript CRC routine
listing -- and there are several more listings like this online.
Should I be wary of basing my efforts on these for some reason?

They are probably all geared to a specific set of operating parameters,
and the IIgs might have picked a different starting value, bit shift
order, etc.

You also need to know which bytes are included in the CRC: they might
have stopped the calculation at the last byte used by the firmware,
ignoring all the unused $FF bytes (though that seems unlikely).

It is likely to be the same.

Thanks so much David for all your detailed advice on this. I feel you
are definitely guiding me on the right path, but whether it ultimately
leads there or not, I do really appreciate this kind of help in
defining the problem.

Glad to be of service.

For reference: my day job involves data communications, and I'm working
with CRCs on a frequent basis. I've implemented 8-bit, 16-bit and 32-bit
CRC algorithms on a variety of processors, and written a table generator
which accepts an arbitrary polynomial and shift order. I've needed a new
adaptable CRC calculation tool since my Casio calculator stopped
working, so this will give me a good excuse to write one.

(Now ... copy and save BEFORE hitting send, that's a good boy...)

Heh. One of the reasons I like using MacSoup (an offline news reader, in
conjunction with a real news server) is that it keeps its own copy of
everything I've posted (since I started using it in early 1997). 4794
articles and counting...

--
David Empson
dempson@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: Any raw data specs for the Apple IIgs BRAM?
    ... endianness was reversed. ... One was a CRC online calculator (which unsurprisingly given your ... have stopped the calculation at the last byte used by the firmware, ... which accepts an arbitrary polynomial and shift order. ...
    (comp.sys.apple2.programmer)
  • Re: Virtex-II Pro CRC Test Data
    ... and I'm having trouble validating my results. ... into the CRC. ... Architecture Users Guide and the Virtex-II Pro and Virtex-II ... that is feed into the CRC calculation. ...
    (comp.arch.fpga)
  • Re: Recovering CRC32 poly?
    ... >> It's a lot easier to intuit the structure of the CRC algorithm in ... >> question if you can pass in chosen messages X that differ from each other ... the CRC of a single zero byte, ... a quick calculation shows that ...
    (sci.crypt)
  • Re: Any raw data specs for the Apple IIgs BRAM?
    ... so I suspect that they represent a checksum to verify the ... this is a very strong hint that is actually a CRC (cyclic ... The CRC calculation works by treating the source data as an N-bit ... the calculation is repeated and the remainder should ...
    (comp.sys.apple2.programmer)
  • Re: CRC16 Calculation Algorithm
    ... The procedure would serve me in vb6 for the calculation of the CRC on ...
    (microsoft.public.vb.com)