The Mystery of the Equipped Device Table

EDIT: I have made a followup post detailing the answer to this mystery!

There is yet one more puzzling aspect of the 3B2 that I do not yet understand, and that is the equipped device table, or EDT. I’ve documented the nitty-gritty details on my main 3B2 reverse-engineering page, so I won’t bore you with the details. But here’s the short version.

The EDT is what tells the system what I/O boards are installed. On startup, the ROM code probes each I/O slot to see what kind of card is in it. Each card has a read-only register that returns the board’s 16-bit Option Number, and the ROM fills in a special table in RAM with the Option Number for each card it discovers. It doesn’t fill in any other information, just the Option Number. For example, the SCSI expansion card returns option number 0x100, and the EPORTS card returns option number 0x102. That’s the only information the ROM gets from the card. Later, the user can run a program called filledt that looks up all kinds of other information about the card in a database held on disk.

So here’s today’s puzzler: How does the system decide that there’s nothing in a slot?

This is what I see when I boot my emulator:

Enter name of program to execute [  ]: unix
	Possible load devices are:

Option Number    Slot     Name
---------------------------------------
       0          0     FD5
       1          1
       2          2
       3          3
       4          4
       5          5
       6          6
       7          7
       8          8
       9          9
      10         10
      11         11
      12         12

But, this is what I see when I boot my real 3B2/310 (with no hard disk attached):

Enter name of program to execute [  ]: unix
	Possible load devices are:

Option Number    Slot     Name
---------------------------------------
       0          0     FD5

Clearly, the real 3B2 has discovered that there’s nothing in the expansion slots. I have confirmed this by running filledt on both the real system, and on the simulator.

This raises the question of how exactly the real 3B2 uses an option number read to determine there’s nothing in the slot. The ROM code should reveal all, but the code is very simple and straightforward: It just reads an address from each card and sticks it into memory, that’s all. It doesn’t branch on any magic values or anything: Just read a number, put it in memory.

The ROM also sets up an exception handler during the card slot read such that any exception causes the entire boot process to fail, so apparently it does not expect there to be any kind of bus read error.

So how? I’ve tried the following experiments:

• Making each empty slot return 0xffff on read.
• Making each empty slot return 0x0000 on read.
• Making each empty slot raise an External Memory Exception on read.
• Making each empty slot raise an External Memory Exception on write.

None of these, it seems, does the right thing. This is another problem that could probably be solved easily by having access to the right documentation, but that’s a rant for another time.