Hi Alistair.
>> The original setup was actually quite simple, and worked as
>> follows:
>>
>> 1. On power-up, the CPU switches itself into Real mode and
>> starts running the BIOS POST routines.
>>
>> 2. After completing the POST, the BIOS scans through the
>> rest of the BIOS area looking at every 4k boundary for
>> the relevant "Extension ROM marker".
>>
>> a. When it finds one, it looks at the adjoining "ROM
>> length" field to determine how large the ROM is
>> supposed to be, then checksum's the ROM area.
>>
>> b. If this checksum is zero, it assumes the ROM is
>> valid, and calls the "initialise ROM" entry point
>> for that ROM.
>>
>> c. The ROM BASIC pointed this entry point to a routine
>> that inserted a call to the main ROM BASIC entry
>> point in the INT 0x18 vector.
>>
>> 3. Once the ROM SCAN was complete, the BIOS starts its
>> "Find OS" loop, which works as follows:
>>
>> a. If the ROM SETUP has options for it, the list of
>> valid boot devices can be set there. If not, the
>> default is
>>
>> "Primary floppy" then "Primary hard drive".
>>
>> b. For each device in the list of valid boot devices,
>> is it present with media in it? If so, load its
>> boot sector and boot from it. If it ever returns,
>> go to step (b).
>>
>> c. If we fall through, execute INT 0x18 to do whatever
>> that feels like doing.
>>
>> There are various other ROM's that can be plugged in, and all
>> use this same mechanism. Among the ones I'm aware of are:
>>
>> 1. Most Video BIOS's.
> How do Video BIOS make sure they are executed before everything
> else?
By having the lowest BIOS address possible. The standard assignments
are as follows...
C000 - C7FF (32k) = Video ROM.
C800 - CFFF (32k) = EIDE Hard drive ROM.
D000 - D7FF (32k) = SCSI ROM (if any).
D800 - DFFF (32k) = ???
E000 - EFFF (64k) = Network ROM.
F000 - F7FF (32k) = ???
F800 - FFFF (32k) = System BIOS
...and the ROM BIOS area only runs from C000 to F7FF. Note also that
although those allocations were made, it's not necessary for a ROM to
occupy its full region, and on the other hand, an unused area can be
used by another ROM.
>> 2. One to require the user to type in a password before the
>> user can continue. Most modern BIOS's have this internal
>> to the BIOS< but it can be added to those that don't.
>>
>> 3. Hard drive controllers on the XT included a controller
>> ROM that worked this way.
>>
>> 4. As far as I know, network boot ROM's work this way as
>> well.
> So the BASIC is just another boot ROM, so the current code
> should create a suitable image provided the socket will take a
> big enough ROM.
It certainly should.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
