Riley Williams writes:
>
> 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?
>
> 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.
Al
