MultiBootROM - setup for multiple bootroms in single chip.

Overview.

During boot the following will be shown (example):
	Choose boot: digit=ROM, F=Floppy, H=Hard Disk
	1. X-terminal boot from dhcp-server.my.net
	2. NetWare/DOS boot from nw-server1.my.net
first line shows ability to boot from local disk (if it is),
next two show descriptions of bootrom images available.

-------------------------------------------------------------

How to use it?

To get it working: first of all, make bootrom images for every
case (X-terminal and NetWare in the example above). Then use
programs from this package. Important files in it are:

MLTBOOT  TXT     3,812 05-26-00   5:33p this documentation

MLTBOOT  BIN       493 05-26-00   8:28p MultiBootROM header
MLTBOOT  BIT       493 05-26-00   8:28p (test version)
MLTBOOT  ASM     7,882 05-26-00   8:24p (TASM/ArrowAsm source)

MAKEMLTB EXE     7,657 05-26-00   8:40p MultiBootROM builder
MAKEMLTB C       3,777 05-26-00   8:40p (TC 1.5 source)

VFYCKSUM EXE     7,275 05-26-00   7:26p (contains source - unzip to get)


Making MultiBootROM: must have MLTBOOT.BIN in current directory
and run the builder. First it asks for two numeric parameters:

- size of the ROM to be made (in kB, seems best is to specify
 true size, or 64, whichever is less, the ROM cannot be > 64kB),

- selection timeout in seconds (during boot when the time elapses
 without keystroke, automatic selection is done: if floppy can be
 used it is chosen, else if there is any bootrom inside the first
 is chosen, else hard disk is tried and fails if unavailable);

and then for every bootrom to be put inside:

- image name - name of a binary file containing image of the
 bootrom which is to be put inside this multibootrom;

- description - it must be non-empty string for boot menu.

These questions will be repeated until empty line is entered.
Or the builder can be invoked with input redirection to get these
answers from a file (it will not show these questions then).

Name of the resultant file is MLTBOOT.ROM.


The program does some primitive compression of these ROM images
- just to avoid filling space by large amount of 'FF'-s usually
present in ROM. Since it was not tested thoroughly, it shows some
compression info (lines like nnnn..nnnn nnnn*nn telling offsets
of compressed records - maybe the info can be useful if a bug is
found, they also show what addresses are used in produced image).

Caution: it does not check for 64kB or specified size overflow!

I recommend thorough testing resultant ROM image before burning 
an EPROM - first step can be verifying the checksum. The VFYCKSUM
can be used for it - it tests checksum of a ROM image (sums all
bytes, just as BIOS does it), and displays the checksum as word -
look at low byte of the word, it must be 00 for valid ROM image.

Since I am not sure about my compression: it is possible to use
test version of the MLTBOOT.BIN (produced by defining TESTMODE
during assembly) - then the resultant "ROM image" can run under
DEBUG, it gives control to the DEBUG by INT 3 when original ROM
image is uncompressed - ES:0 is start of the image, ES:DI - end.
You can then compare the image with original. The test version
is included as MLTBOOT.BIT - rename it to .BIN to use it.

-------------------------------------------------------------

Technical info - data structures.

Structure of the "multibootrom": code of the MLTBOOT.BIN
followed by ROM1structure, ROM2structure, ..., FF FF.
Byte at offset 2 contains 'pages' - size in 512-byte units
(seems it is best to set the 'pages' to full EPROM size, to
 be able to add more ROM images later, to the burnt EPROM),
it is required by BIOS, also BIOS issues call to ROM offset
3, so there is a short jump; byte at 5 contains timeout,
word at 6 contains offset where ROM1structure starts.

Every ROMstructure consists of:
word containing offset of next ROMstructure (-1 means none);
ASCIIZ string containing description; compressed ROM image.

The compressed ROM image consists of one or more parts, each
contains header word specifying its size, then odd parts (ie.
first, third, fifth...) contain specified number of bytes),
and even parts have no data except the header word, they mean
repeating last byte of preceding odd part. Header word 0000
is end-of-image marker, and is followed by checksum computed
so filling remainder of the ROM by 'FF'-s would produce good
checksum value. The header word of ROMstructure points to the
next byte after the checksum. Then next ROM image may follow.

This way next ROMstructure can be added by replacing 'FF'-s
by it - this means after burning an EPROM it is possible to
add another ROMstructure if needed ('FF'-s are unprogrammed
EPROM cells), as far as EPROM size allows it.

Technical info - what it does?

- attempts to read bootsector from A:, keeps info if succeded
 (a success is if sector was read and contains boot indicator)
- attempts to read bootsector from HD, keeps info if succeded
- scans its data structures, and counts bootrom images found
- displays info what can be chosen
- waits for key or timeout, on timeout it simulates 'f' (if
  boot sector on floppy is available), '1' (if bootrom image
  is available), or 'h' (if first two fail)
- boot from floppy or hard disk is done by:
  - reading bootsector (Master Boot Record from HD) to 0:7c00h
  - jumping to its start (with AX,BX,CX,DX,ES as after INT 13h)
- boot from bootrom image is done by:
  - displaying CRLF, its description, CRLF
  - unpacking the bootrom image to 2000h:0
   (if TESTMODE is defined, 7000h:0 is used instead, and
    instead next step is INT 3 followed by infinite loop;
    previously I tried 0800h:0, but it crashed with my bootrom
    simulation from a floppy which used 0:7E00h to load image)
  - far call to 2000h:3, then repeating INT 19h

-------------------------------------------------------------
