Tony Mantler wrote:
>At 6:10 PM -0500 9/4/2000, Peter wrote:
>[...]
>>So if the bootloader uses the system ROM to download and run on-card ROM then
>>at least the card should stop annoying the system?, thus allowing a peaceful
>>netbsd loading ;)
>
>Except that the ROM drivers are often very buggy. For example, the ROM
>driver for the built-in video on the IIsi (perhaps other models, I don't
>recall off the top of my head) will crash when you call the slot int set
>function. Since MacOS never uses that call, it was never properly debugged.
>Some other ROM drivers just don't do anything when you call the slot int
>set call (built-in SONIC driver, for example).

Ok, so maybe we have to do some debugging :). Maybe it will at least give a
clue how to control the chip(s).

Some ideas came up this morning. Firstly maybe some clues can be reverse
engineered from the old A/UX unix which are supposed to run on Mac's asfair.
I guess DarwinOS is out of the question, because it's engineered for G4's.
(what I remember). Any addresses for where to get a booting A/UX ?

All this buggy ROM code makes me start to think on attacking the chips directly
after all ROM is just software, and seems only useful in this case for giving
clues what to look at. Hardware is the thing in control after all. Maybe some
PCB debugging needs to be done too. I guess there's not much official
documentation on these chips .. ?

When the Mac boot, does it read and execute some sector(s) like PC. Or is the
OS hard-rommed so that you can't even get anything executed without a MacOS
partition?

The 1 Gb (21 bit) limit I seen in the netbsd/mac68k doc's, where is that limit?
I mean 1 Gb is not that much nowadays.. :-)
Btw, maybe IDE interface for a MAC is not that hard? Considering that it does
not support any DMA anyway.. Should almost be able to just solder some adress
decoding + IDE connector to get it running (but slow).

[..]
>Well, there's really two ways to call non-native-os code. The first is to
>make the native OS (bsd in this case) look enough like the os the code is
>expecting for it to execute and exit without incident. I belive this is
>what MRG does. It tends to be a big big hack, and much more trouble than
>it's worth.
>
>The other way is to write an 'emulator' of sorts that reads in and
>reinterprets the instructions, following them in a way that's more
>appropriate for the native OS. This method can be summed up conviniently in
>5 letters: B L O A T.

Ok, more debug.... giving clues how to control the chips.

[..]
>Video mode switching comes to mind. I know there's no mode switching code
>in Linux (except maybe for the Valkyrie video), and I don't recall there
>being any in BSD or I would have stolen it by now. ;) The rom sets the
>video mode to whatever is specified in the PRAM on startup. Changing that
>would require booting into MacOS or reverse engineering more drivers, so
>having the computer boot directly into BSD/Linux would make that much less
>convinient.

I guess we have to start with some simplistic video mode to begin with, if at
all. After all SCSI or Networking + running CPU is the essential. The rest
can wait.

>IOP systems (IIfx, 9x0) would suffer, since there were many microcode
>updates for that subsystem that fix huge bugs that the version loaded from
>ROM contains.
>
>I don't think PSC systems (660, 840) are well enough understood to say for
>sure that something evil won't happen if an early-booter were used. Lots of
>DMA voodoo there.
>
>>What I know only IRQ, NMI, DMA. Can disturb a running computer program in a
>>normal enviroemnt. So if IRQ's are told to shut up. DMA is nonexistent. And
>>hopefully nothing triggers NMI except for things like parity error on RAM or
>>similar. One should have a working instruction execution.
>
>"IRQ" and "NMI" are treated identically on M68k, they're both just
>interrupts. DMA can (and does) do evil things to the kernel on AV macs if
>not switched off before loading the kernel. (Penguin has code to deal with
>this, I don't know if the BSD booter does or not)
>
>All in all, it's a whole lot of work for not much gain. Feel free to put in
>the effort if you feel it's worth it though.

Well I thought to have it like a poke-around-for-fun on Mac. Machine code and
low level hw interfacing are kind of a challenge ;)
But I will concentrate on SCSI + CPU. And just get everything else to not
interfere. Then I might go ahead with other chips.

          /Peter