🚀 go-pugleaf

|>Hi, look for etherboot-1.1 at all good Linux archives.
|
|I recall somebody e-mailing me, who had burned a few ROMS, but found that
|the code wasn't executed by the host BIOS. The same code on a floppy worked
|fine, and they couldn't figure it out. They checked with DOS debug and
|the ROM code appeared where it should, and also had the 0x55 0xAA signature,
|but still no-go.
|
|Since I can't recall who it was, and since I think I have found a possible
|reason for the above, I'll mention it here. According to a Nat Semic.
|application note for a ne2000 clone, they state that the following check 
|can be used to verify a ROMs content is valid. The PC BIOS may be doing 
|this same check (which fails) and hence it ignores the ether-ROM.
|
|	If a boot ROM has been identified as belonging to the adapter
|	undergoing diagnostics, then it is possible to check that its
|	data has not been corrupted. The sum of all the ROM bytes should
|	equal zero. The size of the ROM (in 1/2k segments) is held at
|	byte offset 0x03, and offsets 0x00 and 0x01 should hold values
|	0x55 and 0xaa respectively.
|
|Maybe the above tidbit will help somebody. The etherboot ROM images
|may not be storing their size at 0x03 and checksumming to zero.

Sorry, that's too easy an explanation.  That's a standard BIOS check.
The PROMs in the etherboot-1.1 distribution do have the 55 AA
signature, the size and the bytes do checksum to zero, the build
procedure ensures that.  Also they definitely checksum to zero in my
burner.

Here are some other possibilities:

+ The EPROM is too slow. This happened to me with a 450 ns EPROM.
That's what I get for trying to recycle old chips. It's not always
obvious that something is wrong because debug might show the right
contents for most bytes but it takes only one bit off to wreck the
checksum.

+ The slot is meant for a 16k EPROM but a 32k EPROM is used. This
usually means that the top address line is held high, meaning the
top half of the EPROM, which is blank, is used. This does not
seem to be the case above. To avoid this, just burn two copies
of the boot code, one in each half.

+ The slot is meant for a 8k EPROM and not all the bytes can be seen in
the window so it doesn't checksum to a valid BIOS extension. Sorry but
you will have to find a way to make the BIOS see all 16k of the code.

+ Your BIOS doesn't pay attention to extension BIOSes at that address.
It would be a rare old BIOS (probably from the XT era) that does this.

+ The netboot loader hooks INT19H. This delayed hook is apparently
intended for the boopstrap loader and is meant to be activated after
the BIOS initialises.  I've never been able to find out enough about
INT19H to understand if all BIOSes are supposed to support it. However
there is another way to check. The 16 bit version of the PROMs is
activated from the BIOS at scan time, not later. If you find that the
16 bit version works, and the 32 bit version doesn't, then your BIOS
doesn't support INT19H.

	Ken