So the general question being asked here was "how does the system know how much DRAM is available?"
There is generally available documentation that leads to the answer.
First, we know how to add a new ROM Extension (REx) to patch the OS, thanks to the ROM Board Designer's Guide. RExes themselves contain multiple parts with different formats of patch data. In fact, the data on the eMate ROM board is a base ROM image with an Apple REx appended to it. The complete list of these is in the include file ROMExtension.h, available in the "Lantern" driver development kit plugin for MPW:
Well, the first one in the list looks interesting
And kRAMConfigTag logically corresponds to the `RAMConfigTable` and related structs defined later on:
Remember, the ROM image has a REx appended to it? Unfortunately it doesn't contain any parts tagged `'ram '`.
However, there's a good chance (I'm an optimist) that there's at least one struct resembling RAMConfigEntry somewhere in the base ROM. If we found it, it would tell us what the parameters are for unmodified eMate hardware. It also means that an additional REx could be appended to the ROM that contains this data; it would take precedence over the base ROM's values.
And there are flash-based ROM boards, so a prototype memory expansion could be tested if these parameters needed to be modified in order for the system to address all available DRAM.
There is generally available documentation that leads to the answer.
First, we know how to add a new ROM Extension (REx) to patch the OS, thanks to the ROM Board Designer's Guide. RExes themselves contain multiple parts with different formats of patch data. In fact, the data on the eMate ROM board is a base ROM image with an Apple REx appended to it. The complete list of these is in the include file ROMExtension.h, available in the "Lantern" driver development kit plugin for MPW:
const ULong kRAMConfigTag = (ULong) 'ram ';
const ULong kRAMAllocationTag = (ULong) 'ralc';
const ULong kDiagnosticsTag = (ULong) 'diag';
const ULong kCPatchTableTag = (ULong) 'jump';
const ULong kFrameExportTableTag = (ULong) 'fexp';
const ULong kFrameImportTableTag = (ULong) 'fimp';
const ULong kPackageListTag = (ULong) 'pkgl';
const ULong kPadBlockTag = (ULong) 'pad ';
const ULong kPatchTablePageTableTag = (ULong) 'ptpt';
const ULong kGelatoPageTableTag = (ULong) 'glpt';
const ULong kROMTimingConfigTag = (ULong) 'romt';
const ULong kFlashTimingConfigTag = (ULong) 'fsht';
const ULong kFlashTimingBankTag = (ULong) 'fshb';
const ULong kFlashDriverConfigTag = (ULong) 'fshd';
const ULong kFlashDriverEntryTag = ULong ( 'fdrv' );
const ULong kFlashAddressTag = ULong ( 'flsa' );
Well, the first one in the list looks interesting
And kRAMConfigTag logically corresponds to the `RAMConfigTable` and related structs defined later on:
const ULong kRAMConfigTableVersion = 1;
struct RAMConfigEntry {
// From Includes:OS600:MemoryLanes.h
ULong ramPhysStart; // physical start of Ram Bank
ULong ramSize; // number of bytes of RAM in bank
ULong tag; // tag of owner
ULong laneSize; // size of a lane (e.g. 128K)
ULong laneCount; // number of lanes (4 if entirely normal RAM)
};
struct RAMConfigTable {
ULong version; // version of this table format
ULong count; // count of entries in the table
RAMConfigEntry table[1];
};
Remember, the ROM image has a REx appended to it? Unfortunately it doesn't contain any parts tagged `'ram '`.
However, there's a good chance (I'm an optimist
) that there's at least one struct resembling RAMConfigEntry somewhere in the base ROM. If we found it, it would tell us what the parameters are for unmodified eMate hardware. It also means that an additional REx could be appended to the ROM that contains this data; it would take precedence over the base ROM's values.And there are flash-based ROM boards, so a prototype memory expansion could be tested if these parameters needed to be modified in order for the system to address all available DRAM.
