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

On Apr 2, 8:55 pm, demp...@xxxxxxxxxxxxx (David Empson) wrote:
Laroquod <laroq...@xxxxxxxxx> wrote:
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.

That's interesting. Why have I always had it in my head that the Apple
II was a Motorola? Embarrassing.

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).

So it sounds to me like it is up to 64 trials now, assuming that these
different factors can all interact with each other in any combination.

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 was just about to start researching this when I saw David Wilson's
response. Suddenly, I love the internet again. Is his data sufficient?
If you need more I'll do any missing legwork.

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).

Oh thank you for thinking of this. I asked which byte I should stop
calculating on the first time around, but forgot on the second. So
that's what ... 128? ;) I guess one could just write a single routine
that would iterate through all the possibilities and return 128
results...

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.

Wow I definitely came to the right place then didn't I! That would be
so amazing if you can do that. Keep in mind that there is no rush on
this any longer since I am releasing this in close to its current form
in the next few days, since it is working and after three "private"
upgrades I realise that I am dragging my feet. If your adaptable CRC
comes up with the solution then it will definitely go into 0.5. (BTW
you should know in advance if you are making this offer that I am
doing Public Domain, so if you are uncomfortable with that much
permissiveness then don't show me any code -- I can just apply the
results of your experiment to my own original AppleScript routine --
in any case you would definitely be credited for the work.)

I myself am a writer/filmmaker (though still not consistently "by
trade" -- yet -- so I have two hobbies) and I came to this project if
you can believe it by way of a character I'm writing who plays a lot
of classic games. Started doing "research" (heh heh) and needless to
say, I got sidetracked.

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...

So you're on a Mac! I wonder if you would be interested in a little
casual beta testing? Google is partially obscuring your email address,
but it looks easy enough to figure out. If you'll permit me, I'll can
give this thing I final bug-check this evening and then fire it off in
an email...

Actually the Public Domain licence (or non-licence as it were) is
already written and it's distribution ready, so I wouldn't mind
sending out preview copies to any here who are interested -- it
wouldn't bother me if it got passed around further, either. I feel
it's ready, I have just been more focused on the thick of things
rather than setting up a official download page, etc. (That's the
boring stuff.)

The product is called KEGSlotDroppers, and it works on OS X (at least
10.3, haven't tested yet on earlier versions) and a working
installation of either Kent Dickey's KEGSMAC or KEGS-OSX from casaGS.
If anyone wants a preview, send me an email.

Paul.

.