I'm back on linux-m68k

I'm back on linux-m68k

[Joshua Juran]

Hello,

I thought I'd mention that I'm back lurking on linux-m68k.  Some of  
you may remember me as one of the Penguin contributors.

My interests with regard to hacking tend to remain on the Mac OS side  
(and to support this I've picked up some 68K asm knowledge), but  
perhaps this can be useful -- at least, I would have liked to have a  
Mac program that downloaded the necessary files, copied the floppy  
images, and verified the drive setup.

Please let me know if you would find anything running on the Mac OS  
side helpful.

Josh

Re: I'm back on linux-m68k

[Finn Thain]

Hi Josh,

On Wed, 15 Oct 2008, Joshua Juran wrote:

> Hello,
> 
> I thought I'd mention that I'm back lurking on linux-m68k.  Some of you 
> may remember me as one of the Penguin contributors.
> 
> My interests with regard to hacking tend to remain on the Mac OS side 
> (and to support this I've picked up some 68K asm knowledge), but perhaps 
> this can be useful -- at least, I would have liked to have a Mac program 
> that downloaded the necessary files, copied the floppy images, and 
> verified the drive setup.
>
> Please let me know if you would find anything running on the Mac OS side 
> helpful.

Thanks for the kind offer! There are several minor bugs in Penguin that 
I'd love to see fixed but I never got as far as setting up Code Worrier... 
The source code is on sourceforge if you want to try compiling it,

http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/

Aside from that, we could use an Emile* installer on the MacOS side. I'm 
thinking something similar to Ryan Rempel's excellent XPostFacto program 
for booting Mac OS X on Old World h/w.

Laurent can fill in the details (and probably correct me here), but I 
would imagine that, like XPostFacto**, we'd need to copy the boot loader 
to the helper volume, copy the kernel binary, set kernel arguments, 
configure boot blocks on the helper device and set the boot device in 
PRAM. The tools to do all this from the linux side are part of Emile. But 
if/when something goes awry, it may be most easily fixed from MacOS.

Regarding your suggestion WRT downloading, floppy images and drive setup: 
I think that the tools already exist. They aren't for novices, but then 
only enthusiasts really use the port anyway.

I think downloading is pretty much covered by Fetch, iCab etc.

The BSD projects have a port of Apple's pdisk program, which is fine for 
setting up/verifying disk partitions. It's basically an early version of 
the Mac OS X cmd line utility of the same name. Penguin can also dump scsi 
partition maps.

The SUntar program provides raw access to floppy devices (and almost any 
other device for that matter), and can read and write floppy images. I 
think perhaps apple's Disk Copy can too.

Regards,
Finn

* http://emile.sourceforge.net/index.php
** http://eshop.macsales.com/OSXCenter/XPostFacto/

> 
> Josh
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: I'm back on linux-m68k

[Tony Mantler]

On 15-Oct-08, at 9:20 AM, Finn Thain wrote:

> Thanks for the kind offer! There are several minor bugs in Penguin  
> that
> I'd love to see fixed but I never got as far as setting up Code  
> Worrier...
> The source code is on sourceforge if you want to try compiling it,


MPW, not codewarrior.


Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler - Master of Code-fu
-- nicoya@ubb.ca -- http://www.ubb.ca/ --

Re: I'm back on linux-m68k

[Laurent Vivier]

Le 15 oct. 08 à 16:20, Finn Thain a écrit :

>
> Hi Josh,
>
> On Wed, 15 Oct 2008, Joshua Juran wrote:
>
>> Hello,
>>
>> I thought I'd mention that I'm back lurking on linux-m68k.  Some of  
>> you
>> may remember me as one of the Penguin contributors.
>>
>> My interests with regard to hacking tend to remain on the Mac OS side
>> (and to support this I've picked up some 68K asm knowledge), but  
>> perhaps
>> this can be useful -- at least, I would have liked to have a Mac  
>> program
>> that downloaded the necessary files, copied the floppy images, and
>> verified the drive setup.
>>
>> Please let me know if you would find anything running on the Mac OS  
>> side
>> helpful.
>
> [...]
>
> Laurent can fill in the details (and probably correct me here), but I
> would imagine that, like XPostFacto**, we'd need to copy the boot  
> loader
> to the helper volume, copy the kernel binary, set kernel arguments,
> configure boot blocks on the helper device and set the boot device in
> PRAM. The tools to do all this from the linux side are part of  
> Emile. But
> if/when something goes awry, it may be most easily fixed from MacOS.

It's a good idea but the primary goal of EMILE is to totally remove  
MacOS from the disk...

Now, as we are able to boot linux directly from a CD the tools can  
stay on linux side.

EMILE in fact is a MacOS application :-P , perhaps you can make some  
developments for EMILE.

Like PC bootloaders which use BIOS to access devices (disk, screen,  
keyboard, ...) EMILE uses MacOS ROM to access devices.

Inside EMILE, I've written libmacos which is a "wrapper" between the  
linux side of EMILE and the MacOS side of EMILE (yeah, EMILE is almost  
like Darth Vader... )

So perhaps Joshua can help me to write some parts, in my TODO there are:

- save/change/restore the gamma of the screen (I don't like the green  
display of my Q610)
- save/change/restore the video mode
- save/change/restore the boot device

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay





--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I'm back on linux-m68k

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1207 bytes --]



On Thu, 16 Oct 2008, Laurent Vivier wrote:

> 
> Le 15 oct. 08 à 16:20, Finn Thain a écrit :
> 
> >[...]
> >
> >Laurent can fill in the details (and probably correct me here), but I 
> >would imagine that, like XPostFacto**, we'd need to copy the boot 
> >loader to the helper volume, copy the kernel binary, set kernel 
> >arguments, configure boot blocks on the helper device and set the boot 
> >device in PRAM. The tools to do all this from the linux side are part 
> >of Emile. But if/when something goes awry, it may be most easily fixed 
> >from MacOS.
> 
> It's a good idea but the primary goal of EMILE is to totally remove 
> MacOS from the disk...

That argument would be much more compelling if Linux supported more Mac 
hardware (by which I mean, co-processor network cards, more powerful 
display cards, duo docks, audio, scsi ethernet adapters, scsi HBA 
cards...) and MacOS software.

But even if we supported everything, MacOS will always be a better 
operating system for certain tasks, since it makes different compromises.

I think dual-booting would make Emile more useful to more people. But it's 
quite possible that no-one else would want this.

Finn

Re: I'm back on linux-m68k

[Laurent Vivier]

Le 16 oct. 08 à 02:44, Finn Thain a écrit :

>
>
> On Thu, 16 Oct 2008, Laurent Vivier wrote:
>
>>
>> Le 15 oct. 08 à 16:20, Finn Thain a écrit :
>>
>>> [...]
>>>
>>> Laurent can fill in the details (and probably correct me here),  
>>> but I
>>> would imagine that, like XPostFacto**, we'd need to copy the boot
>>> loader to the helper volume, copy the kernel binary, set kernel
>>> arguments, configure boot blocks on the helper device and set the  
>>> boot
>>> device in PRAM. The tools to do all this from the linux side are  
>>> part
>>> of Emile. But if/when something goes awry, it may be most easily  
>>> fixed
>>> from MacOS.
>>
>> It's a good idea but the primary goal of EMILE is to totally remove
>> MacOS from the disk...
>
> That argument would be much more compelling if Linux supported more  
> Mac
> hardware (by which I mean, co-processor network cards, more powerful
> display cards, duo docks, audio, scsi ethernet adapters, scsi HBA
> cards...) and MacOS software.

Who use MacOS 7-8-9 ?
  I you really need it, Basilisk II works faster...

>
> But even if we supported everything, MacOS will always be a better
> operating system for certain tasks, since it makes different  
> compromises.
>
> I think dual-booting would make Emile more useful to more people.  
> But it's
> quite possible that no-one else would want this.

I agree. I tried to make dual-booing but I failled.

Laurent

----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay





--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: I'm back on linux-m68k

[Finn Thain]

On Thu, 16 Oct 2008, Laurent Vivier wrote:

> >But even if we supported everything, MacOS will always be a better 
> >operating system for certain tasks, since it makes different 
> >compromises.
> >
> >I think dual-booting would make Emile more useful to more people. But 
> >it's quite possible that no-one else would want this.
> 
> I agree. I tried to make dual-booing but I failled.

What I mean by dual-boot is <cmd>-<option>-<shift>-<backspace>. This skips 
the default boot device set in PRAM, and searches for another one. (I 
think this combination has slightly different meaning on early models.)

With XPostFacto (open firmware), you'd hold down <option> to get the same 
result (i.e. boot MacOS instead of Mac OS X).

Finn



> Laurent
> 
> ----------------------- Laurent Vivier ----------------------
> "The best way to predict the future is to invent it."
> - Alan Kay
> 
> 
> 
> 
> 

Re: I'm back on linux-m68k

[Joshua Juran]

On Oct 15, 2008, at 4:05 PM, Laurent Vivier wrote:

> It's a good idea but the primary goal of EMILE is to totally remove  
> MacOS from the disk...
>
> Now, as we are able to boot linux directly from a CD the tools can  
> stay on linux side.

That's certainly nice to have as an option, but so are MacOS-hosted  
tools.

> So perhaps Joshua can help me to write some parts, in my TODO there  
> are:
>
> - save/change/restore the gamma of the screen (I don't like the  
> green display of my Q610)
> - save/change/restore the video mode
> - save/change/restore the boot device

Based on the information at <http://okmij.org/ftp/xPRAM.html> (some  
of which is wrong) and some experimentation, I'm able to read the  
extended PRAM, and I've added a read-only /sys/mac/xpram file to Lamp  
(Lamp ain't Mac POSIX), my Unix-like environment for classic Mac OS  
(like MPW, only much better).  In other words, I have working sample  
code for reading the xPRAM (and writing it is almost identical).

Josh

Re: I'm back on linux-m68k

[Joshua Juran]

On Oct 15, 2008, at 4:05 PM, Laurent Vivier wrote:

>> On Wed, 15 Oct 2008, Joshua Juran wrote:
>>
>>> I thought I'd mention that I'm back lurking on linux-m68k.  Some  
>>> of you
>>> may remember me as one of the Penguin contributors.
>>>
>>> Please let me know if you would find anything running on the Mac  
>>> OS side
>>> helpful.
>
> So perhaps Joshua can help me to write some parts, in my TODO there  
> are:
>
> - save/change/restore the boot device

I've written ReadXPRam(), seen at the top of this file:

FSTree_sys_mac_xpram.cc
http://lamp.cvs.sourceforge.net/viewvc/lamp/Genie/Genie/FileSystem/ 
FSTree_sys_mac_xpram.cc?revision=1.3&view=markup

WriteXPRam() is identical, except with a different trap number.  Each  
routine is passed the address of a buffer, how much data to transfer,  
and the offset into XPRam at which to start reading or writing.

The startup device info is stored in 4 bytes starting at offset  
0x78.  For SCSI devices, this is the driver reference number, which  
is the one's complement of the unit table index, which (again) for  
SCSI devices is 32 plus the ID number.

So, for example, SCSI ID 0 has unit number 32, driver refnum -33, and  
XPRam data 0xFFFFFFDF, and SCSI ID 6 is 38, -39, and 0xFFFFFFD9  
respectively.

I don't remember if 68K machines can have multiple SCSI buses.  If  
so, we'll need to figure out how to address external vs. internal.

Setting the RAM disk as the boot device on my system sets the value  
0x0006FFCC.  Interpreting the low word as a signed integer yields  
-52, corresponding to unit number 51, which is the .EDisk driver.  I  
don't know what the high word means, but it's clear that it will be  
-1 for a SCSI device.

This should be enough info to get you going on save/restore and  
setting a bus 0 device.

Josh

Re: I'm back on linux-m68k

[Geert Uytterhoeven]

On Mon, 3 Nov 2008, Joshua Juran wrote:
> I don't remember if 68K machines can have multiple SCSI buses.  If so, we'll
> need to figure out how to address external vs. internal.

At least the Quadra 900 and 950 have two SCSI buses, as deducted from Finn'ss
recent patch.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: I'm back on linux-m68k

[Brad Boyer]

On Mon, Nov 03, 2008 at 01:01:01PM +0100, Geert Uytterhoeven wrote:
> On Mon, 3 Nov 2008, Joshua Juran wrote:
> > I don't remember if 68K machines can have multiple SCSI buses.  If so, we'll
> > need to figure out how to address external vs. internal.
> 
> At least the Quadra 900 and 950 have two SCSI buses, as deducted from Finn'ss
> recent patch.

It is also possible to add SCSI buses. I have a NuBus SCSI card that has
a 53c9x chip of some flavor on it, although I haven't tried it and suspect
that it would take some work to get it supported in Linux. Having a NuBus
SCSI card was a good option to upgrade performance of some of the mid-range
systems where Apple was still using the NCR5380 but better chips were
available. I'm pretty sure Apple supported booting off these as long as
they had the correct software in the ROM on the card.

	Brad Boyer
	flar@allandria.com

Re: I'm back on linux-m68k

[Michael Schmitz]

Hi,

> > At least the Quadra 900 and 950 have two SCSI buses, as deducted from Finn'ss
> > recent patch.
> 
> It is also possible to add SCSI buses. I have a NuBus SCSI card that has
> a 53c9x chip of some flavor on it, although I haven't tried it and suspect
> that it would take some work to get it supported in Linux. Having a NuBus

The 53C9x won't be that hard, but you'll have to write register access code 
going through NUBUS instead of memory mapped IO. The NUBUS ethernet drivers 
should have plenty of sample code. Leaves the exercise of locating the chip in 
the slot address space :-) 

> SCSI card was a good option to upgrade performance of some of the mid-range
> systems where Apple was still using the NCR5380 but better chips were
> available. I'm pretty sure Apple supported booting off these as long as
> they had the correct software in the ROM on the card.

Possible, but someone will just have to report what XPRAM data this would set. 
And booting Linux off these without having a way of writing the kernel to that 
bus won't make much sense. 

	Michael

Re: I'm back on linux-m68k

[Brad Boyer]

On Mon, Nov 03, 2008 at 10:15:41PM +0100, Michael Schmitz wrote:
> > It is also possible to add SCSI buses. I have a NuBus SCSI card that has
> > a 53c9x chip of some flavor on it, although I haven't tried it and suspect
> > that it would take some work to get it supported in Linux. Having a NuBus
> 
> The 53C9x won't be that hard, but you'll have to write register access code 
> going through NUBUS instead of memory mapped IO. The NUBUS ethernet drivers 
> should have plenty of sample code. Leaves the exercise of locating the chip
> in the slot address space :-) 

Well, I did buy the card with the intent of getting a Linux driver working
at some point. It's just not that close to the top of my list. I also have
not really looked at the esp code (either the old or new version) other
than a superficial look at mac_esp.c when Finn was making some fixes. It
doesn't sound too bad from the way you describe it. If it's as easy as
taking mac_esp.c and copying it to nubus_esp.c and writing a new probe
function to detect and setup the card, that shouldn't take long. I notice
that mac_esp.c already uses nubus functions to do some of the work, and
the address space the driver uses for PDMA is in a range normally used
by the nubus code while the device registers are in regular IO space.
This could also be an excuse to dig in to nubus.c as well and get a real
device model framework there.

> > SCSI card was a good option to upgrade performance of some of the mid-range
> > systems where Apple was still using the NCR5380 but better chips were
> > available. I'm pretty sure Apple supported booting off these as long as
> > they had the correct software in the ROM on the card.
> 
> Possible, but someone will just have to report what XPRAM data this would
> set. And booting Linux off these without having a way of writing the kernel
> to that bus won't make much sense. 

I guess I'll try booting from the card whenever I actually put it in something.

	Brad Boyer
	flar@allandria.com

Re: I'm back on linux-m68k

[Michael Schmitz]

Hi,

> > The 53C9x won't be that hard, but you'll have to write register access code 
> > going through NUBUS instead of memory mapped IO. The NUBUS ethernet drivers 
> > should have plenty of sample code. Leaves the exercise of locating the chip
> > in the slot address space :-) 
> 
> Well, I did buy the card with the intent of getting a Linux driver working
> at some point. It's just not that close to the top of my list. I also have
> not really looked at the esp code (either the old or new version) other
> than a superficial look at mac_esp.c when Finn was making some fixes. It

The new esp code is much cleaner and should be easier to adapt to a new bus 
model (I won't deny Nubus might not have quirks of its own there - bus width may 
be an issue, bytes may come spaced by null bytes, you name it, Apple thought of 
it).

> doesn't sound too bad from the way you describe it. If it's as easy as
> taking mac_esp.c and copying it to nubus_esp.c and writing a new probe
> function to detect and setup the card, that shouldn't take long. I notice
> that mac_esp.c already uses nubus functions to do some of the work, and
> the address space the driver uses for PDMA is in a range normally used
> by the nubus code while the device registers are in regular IO space.

No idea how PDMA would work - may there is a DMA chip even? 

> This could also be an excuse to dig in to nubus.c as well and get a real
> device model framework there.

The best excuse :-) 
 
	Michael

Re: I'm back on linux-m68k

[Brad Boyer]

On Tue, Nov 04, 2008 at 08:25:31AM +0100, Michael Schmitz wrote:
> The new esp code is much cleaner and should be easier to adapt to a new bus 
> model (I won't deny Nubus might not have quirks of its own there - bus width
> may be an issue, bytes may come spaced by null bytes, you name it, Apple
> thought of it).

The generic nubus code already has some of the bus width problems handled
because it needs to be able to read the ROM chips. It is something of a
pain since it has to support nearly arbitrary arrangements of byte lanes.

> No idea how PDMA would work - may there is a DMA chip even? 

Well, I do know that some NuBus cards have real DMA. The problem is that
it's always card specific. There is never a bus-level DMA controller. I
would hope that a high performance SCSI card would have that, but I've
only seen explicit mention of it on video cards. I'll probably try PIO
first, then try to see if it does DMA. It's possible the card just has
a bunch of local memory for buffers like some ethernet cards.

> > This could also be an excuse to dig in to nubus.c as well and get a real
> > device model framework there.
> 
> The best excuse :-) 

Now I just have to find the time.

	Brad Boyer
	flar@allandria.com

Re: I'm back on linux-m68k

[Joshua Juran]

On Nov 3, 2008, at 1:15 PM, Michael Schmitz wrote:

>>> At least the Quadra 900 and 950 have two SCSI buses, as deducted  
>>> from Finn'ss
>>> recent patch.

I have a Quadra 950 (in addition to the Q650 which I've been using so  
far).  I'll set it up and check at some point if someone doesn't beat  
me to it.

>> It is also possible to add SCSI buses. I have a NuBus SCSI card  
>> that has
>> a 53c9x chip of some flavor on it, although I haven't tried it and  
>> suspect
>> that it would take some work to get it supported in Linux. Having  
>> a NuBus
>> SCSI card was a good option to upgrade performance of some of the  
>> mid-range
>> systems where Apple was still using the NCR5380 but better chips were
>> available. I'm pretty sure Apple supported booting off these as  
>> long as
>> they had the correct software in the ROM on the card.
>
> Possible, but someone will just have to report what XPRAM data this  
> would set.

If anybody wants to take Genie/Lamp for a spin, you can get it here:

Lamp Ain't Mac POSIX
http://www.metamage.com/lamp/

Once running, /sys/mac/xpram is a read-only virtual file  
corresponding to the 256-byte XPRam.  You can either hack it with  
perl or cat the whole thing into a real file and view it with HexEdit.

Also, the 'drvr' script will iterate through /sys/mac/unit and list  
all the installed drivers.

Bear in mind that at present I am Lamp's only user, so some gotchas  
are to be expected.

Josh

Re: I'm back on linux-m68k

[Riccardo]

Hey

On Monday, November 3, 2008, at 01:01  PM, Geert Uytterhoeven wrote:

> On Mon, 3 Nov 2008, Joshua Juran wrote:
>> I don't remember if 68K machines can have multiple SCSI buses.  If 
>> so, we'll
>> need to figure out how to address external vs. internal.
>
> At least the Quadra 900 and 950 have two SCSI buses, as deducted from 
> Finn'ss
> recent patch.

the quadras 9x0 have them but you could also add scsi cards via NuBus. 
The Q9x0 I think even supported a third ultra-scsi card especially 
designed as an upgrade for servers. I have seen just one recently and 
it is not in my possession.


Riccardo

Re: I'm back on linux-m68k

[Joshua Juran]

On Nov 3, 2008, at 4:01 AM, Geert Uytterhoeven wrote:

> On Mon, 3 Nov 2008, Joshua Juran wrote:
>> I don't remember if 68K machines can have multiple SCSI buses.  If  
>> so, we'll
>> need to figure out how to address external vs. internal.
>
> At least the Quadra 900 and 950 have two SCSI buses, as deducted  
> from Finn'ss
> recent patch.

So far, I haven't been able to boot my 950 while a drive connected to  
the external bus was powered on.  The external drive's access light  
goes on immediately after the screen lights up grey, and startup gets  
as far as drawing the Mac OS splash screen and maybe 12 pixels of  
progress before halting, resuming normally if I power off the  
external drive.

Any ideas?

Josh

Re: I'm back on linux-m68k

[Finn Thain]

On Sat, 8 Nov 2008, Joshua Juran wrote:

> So far, I haven't been able to boot my 950 while a drive connected to 
> the external bus was powered on.  The external drive's access light goes 
> on immediately after the screen lights up grey, and startup gets as far 
> as drawing the Mac OS splash screen and maybe 12 pixels of progress 
> before halting, resuming normally if I power off the external drive.
>
> Any ideas?

I see the same issue sometimes. I don't think it is a termination problem 
but it is hard to say. You could try installing drivers from HD SC Setup, 
Drive Setup, Silverlinig or HDT etc.

Finn

> 
> Josh

Re: I'm back on linux-m68k

[Joshua Juran]

On Nov 8, 2008, at 5:12 AM, Finn Thain wrote:

> On Sat, 8 Nov 2008, Joshua Juran wrote:
>
>> So far, I haven't been able to boot my 950 while a drive connected to
>> the external bus was powered on.  The external drive's access  
>> light goes
>> on immediately after the screen lights up grey, and startup gets  
>> as far
>> as drawing the Mac OS splash screen and maybe 12 pixels of progress
>> before halting, resuming normally if I power off the external drive.
>>
>> Any ideas?
>
> I see the same issue sometimes. I don't think it is a termination  
> problem
> but it is hard to say. You could try installing drivers from HD SC  
> Setup,
> Drive Setup, Silverlinig or HDT etc.

I had no such problems using a removable storage drive, although I  
had to tighten the cable before it was recognized, so it may have  
been a cabling issue originally.

Anyway, with regards to startup devices, there's no distinction  
between the buses.  If you select the device at SCSI ID 5 on bus 1,  
the XPRam value is set to 0xFFFFFFDA, just as it would be for bus 0.   
And if a SCSI ID is shared by devices on each bus, selecting the  
external one in Startup Disk beeps and sets the XPRam value to  
0x00000000.

Solution:  Pretend it's all one bus and give everything a unique SCSI  
ID.  Or, just don't 'upstage' the boot disks (with a device of the  
same ID on a lower-numbered bus).

(Bad news if you were hoping to have eight or more different startup  
disks...)

Josh

Re: I'm back on linux-m68k

[Brad Boyer]

On Sat, Nov 08, 2008 at 08:14:01AM -0800, Joshua Juran wrote:
> Solution:  Pretend it's all one bus and give everything a unique SCSI  
> ID.  Or, just don't 'upstage' the boot disks (with a device of the  
> same ID on a lower-numbered bus).
> 
> (Bad news if you were hoping to have eight or more different startup  
> disks...)

The classic MacOS doesn't track bus numbers internally anyway. It's
just a fundamental issue with the SCSI manager implementation that
Apple used. It only knows about device IDs. Since the ROM includes
chunks of the MacOS to do its own work, the limitation carries over
for the boot sequence.

	Brad Boyer
	flar@allandria.com