Let's talk about a Mini-DOS
Posted: Tue Jan 31, 2006 12:00 am
In these last years, I've been talking with a number of people that had (like me) some large scale projects on the Oric.
Some wanted to port games, some wanted to port applications, some wanted to create demos.
The common point of all these projects is that they use the floppy disc drive, the other common point is that the Oric operating systems are not adapted to these projects.
The reason is simple. The Oric DOSes are mainly way to add disc support for BASIC users. I will take the example of Sedoric.
I you look at the Sedoric manual, you will see that it implements the following new BASIC instructions:
Directory: DIR,LDIR
Load and Save: LOAD,SEARCH,SAVE,SAVEO,SAVEM,SAVEU,ESAVE
Erasing: DEL,DESTROY,DELBAK
File changes: REN,STATUS,PROT,UNPROT
Sector access: PMAP,SMAP,CRESEC,FRSEC
Disc operations: INIT,BACKUP,COPY,DSYS,DNAME,INIST,DKEY,TRACK,DTRACK,DNUM,SYSTEM
Programing commands: RENUM,MERGE,DELETE,SEEK,CHANGE..TO..,NUM,NUM END
Keyboard handling: KEY,KEYIF,QWERTY,AZERTY,ACCENT,KEYDEF,KEYUSE,KEYSAVE,VUSER
String handling: TKEN,UNTKEN,STRUN,INSTR
Error handling: ERR SET,ERR OFF,ERRGOTO,RESUME,ERROR
Formated I/O: LINPUT,CREATEW,WINDOW,USING,LUSING,WIDTH
Printer: OUT,PR SET,PR OFF
Graphics: LINE,BOX,LCUR,HCUR
Misc: USER,],QUIT,RESET,RESTORE,MOVE,OLD,RANDOM,SWAP
Files: OPEN,CLOSE,PUT,TAKE,APPEND,REWIND,JUMP,BUILD,TYPE,LTYPE,&(),PUT,TAKE,FIELD,LSET,RSET
I guess that everybody will agree on the fact that most of this is of absolutely no use for people that are not using BASIC as their programming language of choice, specially considering there is no easy way to call any of these functions from an assembly code routine.
And the fact that the notion of handle, partial file loads, folders structures, etc are missing... makes it impossible to implement something like the C standard library.
Sedoric is quite good as a DOS. You can list files, launch commands, copy stuff between discs, etc...
But quite frankly, if you write games or demos, you have very specific needs:
- The maximum amount of free room both on disc and in memory
- Easy and fast way to load data to memory (not necessarily stored as files with filenames and dates, just bunches of data)
- Eventually possibility to save data (like high score tables for a game)
- Being compatible with a maximum of hardware (oric 1/atmos/telestrat but also microdisc/jasmin)
The Defence Force demos actually only needed a simple ReadSector routine associated with a small table containing three informations:
- track/sector position of the first sector of the file to load
- number of sectors to read
- adress in memory of where to put data
Obviously this is a primitive directory structure, but since all the data were generated with a floppy maker tool, it was possible to get these information as a generated source code included in the loader to avoid having to load the table at startup.
A real new os good enough to be able to get something like Contiki to run, would require at least the following:
- Hardware level: Disc structure informations, ReadSector/WriteSector
- File level: Directory structure and sector allocation management
- Library level: Buffered loads, file handling, etc...
I am not sure that beeing compatible with Sedoric at structural level is a good idea, because the disc layout is quite complicated. If necessary, Sedoric format compatibility could be implemented easily as a small C conversion program that would use the three layers describes previously.
What would be an ideal format ?
Obviously, in a form or another we need to get for each file:
- name
- size in bytes
- location on disc
If we assume (like in a demo) that we do not have fragmented files, then the location can just be an indication as track/sector of the first sector.
But if we use if in normal OS usages patterns, we will need to create and erase files, so this will lead to some fragmentation. (of course it is still possible to defragment in realtime when writing new files, but this will kill the floppies very fast, so this is not a good idea).
So if we handle fragmentation, this means that we need the location of each single sector of the file.
The size taken by of all these data depends of three parameters:
- The maximum number of files we can store on the disc
- The number of sectors that are allocated on the disc
- The size of individual metadata for each file (lenght of filename for example).
If we have a (fat) disc that contains 2 sides, 82 tracks per side, and 18 sectors (of 256 bytes), we have 2x82x18=2952 sectors that can be possibly allocated. A candid approach of the problem is to store positions as simple sectors numbers in the range 0-2951, and using a 12 bits value for that purpose.
Many other operating systems have the notion of cluster. Instead of allocating sectors one by one, you allocate them by blocks of fixed size. This diminished the size of metadata to keep, but also increase the amount of waste when storing size.
With a cluster of size=2 sectors, we now have only 1476 clusters to manage, but it also means that each file is rounded to the upper 512 bytes limit. With a cluster size of 4 sector, we have only 738 cluster, with files rounded to 1024 bytes.
All suggestions about ideal disc layout are welcome !
You can read more about some existing floppy formats here:
Wikipedia
MS-Dos/AtariST format
Some wanted to port games, some wanted to port applications, some wanted to create demos.
The common point of all these projects is that they use the floppy disc drive, the other common point is that the Oric operating systems are not adapted to these projects.
The reason is simple. The Oric DOSes are mainly way to add disc support for BASIC users. I will take the example of Sedoric.
I you look at the Sedoric manual, you will see that it implements the following new BASIC instructions:
Directory: DIR,LDIR
Load and Save: LOAD,SEARCH,SAVE,SAVEO,SAVEM,SAVEU,ESAVE
Erasing: DEL,DESTROY,DELBAK
File changes: REN,STATUS,PROT,UNPROT
Sector access: PMAP,SMAP,CRESEC,FRSEC
Disc operations: INIT,BACKUP,COPY,DSYS,DNAME,INIST,DKEY,TRACK,DTRACK,DNUM,SYSTEM
Programing commands: RENUM,MERGE,DELETE,SEEK,CHANGE..TO..,NUM,NUM END
Keyboard handling: KEY,KEYIF,QWERTY,AZERTY,ACCENT,KEYDEF,KEYUSE,KEYSAVE,VUSER
String handling: TKEN,UNTKEN,STRUN,INSTR
Error handling: ERR SET,ERR OFF,ERRGOTO,RESUME,ERROR
Formated I/O: LINPUT,CREATEW,WINDOW,USING,LUSING,WIDTH
Printer: OUT,PR SET,PR OFF
Graphics: LINE,BOX,LCUR,HCUR
Misc: USER,],QUIT,RESET,RESTORE,MOVE,OLD,RANDOM,SWAP
Files: OPEN,CLOSE,PUT,TAKE,APPEND,REWIND,JUMP,BUILD,TYPE,LTYPE,&(),PUT,TAKE,FIELD,LSET,RSET
I guess that everybody will agree on the fact that most of this is of absolutely no use for people that are not using BASIC as their programming language of choice, specially considering there is no easy way to call any of these functions from an assembly code routine.
And the fact that the notion of handle, partial file loads, folders structures, etc are missing... makes it impossible to implement something like the C standard library.
Sedoric is quite good as a DOS. You can list files, launch commands, copy stuff between discs, etc...
But quite frankly, if you write games or demos, you have very specific needs:
- The maximum amount of free room both on disc and in memory
- Easy and fast way to load data to memory (not necessarily stored as files with filenames and dates, just bunches of data)
- Eventually possibility to save data (like high score tables for a game)
- Being compatible with a maximum of hardware (oric 1/atmos/telestrat but also microdisc/jasmin)
The Defence Force demos actually only needed a simple ReadSector routine associated with a small table containing three informations:
- track/sector position of the first sector of the file to load
- number of sectors to read
- adress in memory of where to put data
Obviously this is a primitive directory structure, but since all the data were generated with a floppy maker tool, it was possible to get these information as a generated source code included in the loader to avoid having to load the table at startup.
A real new os good enough to be able to get something like Contiki to run, would require at least the following:
- Hardware level: Disc structure informations, ReadSector/WriteSector
- File level: Directory structure and sector allocation management
- Library level: Buffered loads, file handling, etc...
I am not sure that beeing compatible with Sedoric at structural level is a good idea, because the disc layout is quite complicated. If necessary, Sedoric format compatibility could be implemented easily as a small C conversion program that would use the three layers describes previously.
What would be an ideal format ?
Obviously, in a form or another we need to get for each file:
- name
- size in bytes
- location on disc
If we assume (like in a demo) that we do not have fragmented files, then the location can just be an indication as track/sector of the first sector.
But if we use if in normal OS usages patterns, we will need to create and erase files, so this will lead to some fragmentation. (of course it is still possible to defragment in realtime when writing new files, but this will kill the floppies very fast, so this is not a good idea).
So if we handle fragmentation, this means that we need the location of each single sector of the file.
The size taken by of all these data depends of three parameters:
- The maximum number of files we can store on the disc
- The number of sectors that are allocated on the disc
- The size of individual metadata for each file (lenght of filename for example).
If we have a (fat) disc that contains 2 sides, 82 tracks per side, and 18 sectors (of 256 bytes), we have 2x82x18=2952 sectors that can be possibly allocated. A candid approach of the problem is to store positions as simple sectors numbers in the range 0-2951, and using a 12 bits value for that purpose.
Many other operating systems have the notion of cluster. Instead of allocating sectors one by one, you allocate them by blocks of fixed size. This diminished the size of metadata to keep, but also increase the amount of waste when storing size.
With a cluster of size=2 sectors, we now have only 1476 clusters to manage, but it also means that each file is rounded to the upper 512 bytes limit. With a cluster size of 4 sector, we have only 738 cluster, with files rounded to 1024 bytes.
All suggestions about ideal disc layout are welcome !
You can read more about some existing floppy formats here:
Wikipedia
MS-Dos/AtariST format