ROM Headers and Front DORs

Applications are set up as linked lists of DORs, an object linking structure which is explained in 'DORs', one list for each ROM card (including the internal one in Slot 0). The application DORs contain such vital information as where the application entry point is and whether caps lock should be set on entry; more of this below. The root of each link is the 'front DOR'. The first application is linked as a son to this DOR, and subsequent applications are linked together as brothers. For instance, in the internal ROM, the arrangement of application DORs is as follows:

When the operating system searches for applications it looks at each slot in turn, starting with the internal ROM or slot 0. The top bank of each slot is examined for the presence of 'OZ' in the uppermost two bytes - if this is found then the card is identified as containing applications. Filing system EPROMs are identified by 'oz' in the top two bytes. The full header which an application card should incorporate at the top of its highest bank is as follows:

The Card Header:

(seen from top of card, downwards)

$3FFE'OZ'Card holds applications
$3FFD$00Subtype of card - future expansion
$3FFCxSize of card in banks, eg. $02 for a 32K card
$3FFB$80Marks external application
$3FFA@0000xxxx4 bit country code
$3FF9@0xxxxxxxHigh byte of card ID
$3FF8@0xxxxxxxLow byte of card ID


The country codes is as follows: The high nibble of the country code byte must be 0 (@0000). The low nibble indicates the language variant of the application, and is coded as follows:

The country codes:

0000 (00h)USA1000 (08h)Japan
0001 (01h)France1001 (09h)Iceland
0010 (02h)Germany1010 (0ah)Norway
0011 (03h)UK 1011 (0bh)Switzerland
0100 (04h)Denmark1100 (0ch)Turkey
0101 (05h)Sweden1101 (0dh)reserved
0110 (06h)Italy1110 (0eh)reserved
0111 (07h)Spain1111 (0fh)reserved


Before commercial release it is necessary to obtain a card ID. If two commercially released cards shared an ID, then inserting both into the machine could cause serious problems for the card manager, and it is most important that this should not happen. The bits explicitly given above will be true for all external IDs - alternative settings of these bits are reserved for future internal applications.

Next, the card manager expects to find the application front DOR starting in the top bank of the slot, at bank offset $3FC0. This section should be identical for all application cards, apart from the address of the first application DOR. The 3 byte links consist of a 2 byte offset within a bank (low byte, high byte) followed by a bank number.

It is recommended but not necessary that all the application header information, including menus and help, are placed in the top one or two banks. The space between the application front DOR and the card header above it should be padded with zeros.

Note: The bank numbers should be offset from the top bank. ie. the top bank should be $3F, the one below $3E etc. In a 128K EPROM the lowest bank should be thought of as $38 and not as $00.

The application front DOR:

3 bytes0 0 0Extended pointer to parent
3 bytes0 0 0 Extended pointer to brother - this may point to the HELP front DOR
3 bytesx x xExtended pointer to son - this points to the first application DOR
1 byte$13DOR type, ROM Front DOR
1 byte8DOR length
1 byte'N'Key for name field (DT_NAM)
1 byte5Length of name and terminator
5 bytes'APPL', 0NULL-terminated name
1 byte$FFDOR terminator

web analytics