Developper's Notes Addendum
THE RAM FILING STRUCTURE
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
Data | Length | 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 :
Data | Length | 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 :
Data | Length | 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)
CONCLUSION
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.