[rescue] AT&T 3b1 Starlan software

[James Lockwood]

On Thu, 13 Feb 2003, Jonathan C. Patschke wrote:

> On Thu, 13 Feb 2003, Scott Newell wrote:
>
> > Does each slot have X amount of memory space allocated to it?  Seems to me
> > the simple backplane has an advantage if you've got cards that require
> > almost no memory space, and some cards that require a large chunk.
>
> I'm not really clear on how the Apple ][ handled that.  But, yeah, that
> could be a problem.

>From memory, so it's a bit fuzzy.

256 bytes from Cx00 to CxFF dedicated to each device where x was the slot
number (1-7).  This usually held bootstrap and core code.  C000-C0FF was
for onboard hardware control.

2KB from C800 to CFFF that any card could map in at a time.  When a card
that needed this space got control it would map itself in, do its
operations, and then map back out.  Overhead was only a couple of cycles.
2KB doesn't sound like a lot but with a 64KB address space, it was plenty
for hardware control.  The entire low level primary boot loader and low
level I/O routines (including 6&2 decoding) fit with a pile of room to
spare.

Low level I/O to a 5.25" floppy disk on the Apple ][ was about as low
level as it's possible to get.  All timing, framing and decode was driven
through software with precisely timed loops.  The boot loader was a work
of demented genius.

As far as locating devices in different slots was concerned, there wasn't
really a problem.  Just about any program that needed to muck with
expansion cards at a low level asked you for a slot number to operate on.
Certain choices were defaults (such as 5.25" drives on slot 6, a mouse on
slot 4, etc) but I can't remember any drivers that actually hardcoded the
slot except for really weird cards that dug deeply into how memory was
addressed.

The IBM PC approach of user-specifying the address ranges is the worst of
all possible worlds.  The only thing that can settle out reasonable
defaults is convention, and convention takes a long ugly period to settle
down from initial release.

Nubus was another bus that got it right.  Not surprising, since it has VME
heritage.  The VME BGxx/IACK lines are another interesting way to
implement flexible interrupt handling, though I wish they could have
solved the empty slot problem better.

-James