Re: [PATCH] Add SWIM floppy support for m68k Macs.

[Joshua Juran <jjuran@gmail.com>]

On Nov 5, 2008, at 2:31 AM, Finn Thain wrote:

> On Tue, 4 Nov 2008, Joshua Juran wrote:
>
>> On Nov 4, 2008, at 12:06 PM, Brad Boyer wrote:
>>
>>> On Tue, Nov 04, 2008 at 07:34:41PM +0100, Riccardo wrote:
>>>
>>> Hopefully there's a logical way to detect this upgrade, but it  
>>> would be
>>> interesting to know if the update changes the gestalt ID.
>>
>> You would detect an upgraded ROM by reading the ROM, I imagine.
>
> Good point. But I think we'd need the ROM base to be supplied by  
> Penguin?
> Or even just the ROM checksum.

It's probably a good idea for the kernel to know the address and size  
of the ROM, and given those (or just the former) it can determine the  
checksum.  Penguin can get these from low memory and Gestalt()  
respectively.  EMILE can too iff they're set up in ROM -- I don't know.

>> By the way, does anyone know how to calculate a ROM checksum, or  
>> will I
>> have to reverse-engineer CopyROM or somesuch?
>
> I assumed that CopyROM etc did not validate anything, they just  
> reported
> the checksum contained in the ROM (first 4 bytes).

Oh.  Red herring, then.  So for our purposes it's just a magic  
number, and the "checksum" algorithm would be:

	inline unsigned long checksum( const void* rom, unsigned long size )
	{
		return *(const unsigned long*) rom;
	}

:-)

> The code must be part
> of the POST though, since a bad rom checksum is a sad mac error. So  
> you
> could reverse engineer that. But IIRC there is a card ROM checksum
> algorithm given in Designing Card and Drivers for the Mac II and  
> Mac SE.
> It's probably the same algorithm. I don't have access to my copy at  
> the
> moment.

Might be interesting, but not necessary -- if we really wanted to  
verify the ROM was intact we could use any checksum algorithm we  
wished, with a table mapping one to the other.

But one of these days I should spend some quality time disassembling  
ROM anyway.

Josh