Developper's Notes Addendum


The RAM filing system is organised around the DOR structure. On each RAM device the files are mixed with the memory pools for the application. A system pool handle is used for allocating memory for file blocks. OZ works with blocks of 64 bytes to store the files. A special coding is defined to link these blocks, it is described below.

1 - RAM Device front DOR

1.1 - Address

It is placed in the first bank of the device ($40, $80, $C0) except for :RAM.1 who is in bank $21 (Bank $20 is the system RAM). The two first bytes define the device. It is always $5A $A5 for writing test as it is a RAM. The third byte is the number of bank in the device ($40 for a 1MEG card). The device DOR starts at $0040.

1.2 - RAM device DOR structure

DataLength Description
$0000FF 3 link to parent (none) (always start with $FF)
$000000 3 Link to brother (none)
3 Link to son (the first file or directory)
$81 1 RAM device type
$09 1 DOR length
'N' 1 Name key
$06 1 Name length
'RAM.1' 6 Name (null terminated)
$FF 1 DOR terminator

1.3 - The RAM.- device

For the virtual RAM.- device, the DOR is placed just after the RAM.0, it starts at $21 $8080. Its filing structure is exactly the same.

2 - Directory

2.1 - Directory DOR structure :

DataLength Description
3 link to parent (RAM device or other directory)
3 link to brother
3 link to son
$12 1 Directory type
$35 1 DOR length (fixed length)
'N' 1 Name key
$11 1 Name length (fixed length)
17 Name (null terminated)
U 1 Update key
$06 1 length
6 Internal date/time
'C' 1 Creation key
$06 1 length
6 Internal date/time
$FF 1 DOR terminator

2.2 - Links

The links are 'classical' : two byte address (in segment 2 mask) followed by a bank number (slot masked).

3 - File

3.1 - File DOR structure :

DataLength Description
3 link to parent
3 link to brother
3 link code to son (see below)
$11 1 File type
$35 1 length
17 name (null terminated)
'U' 1 Update key
$06 1 length
6 Internal date/time
'C' 1 Creation key
$06 1 length
6 Internal date/time
'X' 1 Extent key
$04 1 Length
4 File extent

3.2 - Links

The son is to the first block of the file. A special coding is used. It is three bytes : BLOCK_CODE(E) BANK(B) $00

3.3 - Block coding methode

B is the bank (8bits with the slot mask). E is the address code of the block. It is decoded by shifting bytes for giving : this 16bits address 10eeeeee ee000000. The first two bits are 10 because block management is always done in segment 2 (MM_S2).

3.4 - Block structure

Each block is 64 bytes long. There are 256 blocks in a bank (256*64=16K). For each block the two first bytes link with the next. The first link byte is the codeof next block, the second byte is the bank number of this next block. They are followed by 62 bytes containing the data of the file. For the last block, the first byte is the length of data in that block and the second byte is 00 always.

3.5 - Deleted file consequences

When a file is deleted, all the blocks are freed. The file DOR is overwritten with $00 $00 $DE $AD meaning that its block have been freed. Its parent is relinked with the next file (or directory). When a block is freed, the two first bytes always link to the next block but they are always followed by $DE $AD. In theory it is possible to read a deleted file as its link code is always here but the start of each data block have been overwritten by $DE $AD.

4 - How OZ manage these blocks

The available block is stored in the system RAM variables (bank $20) at ($0246). When no more are available ($0000 value), OZ allocates by a OS_MAL a new 256 bytes blocks with the system pool handle stored at ($0244). This block is divided in 4 new file blocks available for a new file storage. You can get the available block code of each slot at :
Slot 0 : ($023A) Internal Ram

Slot 1 : ($023C)
Slot 2 : ($023E)
Slot 3 : ($0240)


This filing system is good as it works well. It should be improved by using larger block, today people have big RAM devices and 256 bytes would be a good size for memory allocation. An other method could be used for linking DORs and blocks because the file DOR linking takes a lot of machine time. Hoping that these ideas will be implemented in OZ v5.

Thierry PEYCRU (Zlab), February 1998.