Re: hfs boot floppy versions
On Tue, Nov 01, 2005 at 01:59:11AM +0100, Christian M?ller wrote:
> @Sven: 20051031 boot.img works, but it will not throw out the floppy
> when it asks for the second disk root.bin - there is no soft eject
> command issued, I guess. As you surely know, apple forgot the
> hard-eject knob on most of their floppy drives and that makes it a
> slight problem to continue at this point...
This was fixed at one point, but that was a long time ago. I suspect
that the fix got broken and noone noticed. Not that many people do
the two-floppy boot on a pmac machine.
> >I'm pretty sure my 7600 reset everything on a mac boot sequence. I know
> >it cleared out the patch for the control video mode bug.
> >
> >
> Which was a forth function you somehow stored in nvram (the control
> cidmode patch)?
I don't remember the exact details, but it was forth code. I probably
have a copy of it if you want it. It pulled some tricks with the
drivers for /chaos/control and via-cuda to stabilize the display.
> Well, Sven actually does build those vmlinuz.coff, but they don't fit
> onto a floppy anymore - anyway, I tried to just let OpenFirmware search
> and load vmlinuz.coff directly from an iso9660 cd (which I tried with
> the above VMLIN.., wait - did I append ;1? - have to check that...).
> This ought to, if it were not for the huge size, work - I had OF boot
> the tiny ofwboot.xcf code successfuly either way - from a dos floppy and
> from an iso9660 cd. The size difference suggests the following
> problem: OF simply does not memcpy such a huge file into the mac memory
> and starts it. Another problem might be the kernel itself - does it
> expect to live somewhere in memory space (sorry, noob question)? With
> system disk patches applied vmlinuz.coff would start at 0x600000 in
> memspace. Still another thing I can think of is memory collision - does
> anybody have a little more insight what the real-base var effects?
> Right now I'm guessing (this is probably terribly wrong) that
> OpenFirmware is shadowed into the RAM somewhere, maybe @real-base?
The only thing I remember for sure is that some models needed the
load-base changed to get things to work. The xcoff wrapper should
be able to relocate the kernel as long as it all got loaded into
memory, but some models were fond of overwriting the video buffer,
or other such tricks. It was much more reliable on some machines
than others. The older 7x00/8x00 machines were probably best, since
that is what was the original hardware support.
Brad Boyer
flar@allandria.com
Reply to: