flat assembler
Message board for the users of flat assembler.

Index > OS Construction > FOOL disk as file system?

Thread Post new topic Reply to topic

Joined: 20 Feb 2006
Posts: 4282
Location: Now
edfed 15 Jun 2008, 11:28
now, what is a file?

a file is a string of bytes with a name and a date of creation, and a location.

it is a muldimensional object then.

for a CVS tool, a file is mainly an entity with an identifier, and a set of updates.

then, now, what can be made to have a very good file system?

an ID (UUID for example, but better of course, cause we just made better things, if not, don't do anything at all and return to holidays), and this id is an entry connecting to the current state of the document, and it's history.

but make it simple please, nobody wants to deal with complex stuff where it can be simple.

then, the version control should just be an overlay, or a plugin, or something like this. an option. This option to have a version control is one option into many others. theses options should be stackable, treeable, modifiable, and so on.

an other option can be the cryptography layer, the connection to a software , a class, or anything. it can also be a linkage, a stringage of documents, a machine, an user, and so on. anything can be optionnal, but the file itself is not an option.

this file is then the element we need to handle.

what is a file? really?

it is a string of bytes, somewhere.
even the meta data of a file is an option if we consider this design.

then, a file is an item described by it's location, its size and that's all.
if we need overlay, we should then create another structure, like filemeta.

filemeta will then be a set of metadata used to describe the file as a document.

for example, filemeta will have a name, a datetime, and a pointer to a fileitem.

now if we need crypto or anything, we should make it a fileitem.
this fileitem is just a set of the cryptotool flag and a pointer to the fileitem.

what is now to consider is the fact that to exploit a crypted file, we also need to get the file location and size. these datas are given by the file structure. the file tool will then scan the tree of items to get theses data from the corresponding item.

means that tools to handle files should work only on theirs datas, and ignore the datas from others elements from the tree.

this feature is transparent with fool due to the .call pointer at the beining of every items.

the stacking and pluging feature is also transparent in the fool design, then, this speach end there, and just tell a file is a name, and a pointer to a fptr.


then a filemeta is


.option there is a plugin or a tree of plugin. this item will then be used to pipeline the .file item.

as the problem is not simple ( create new objects in the structure) i plan on the basic functions:


will read the drive and copy the bytes in the ram. or write from ram to drive.


drives are mainly fixed size and will not change during os running.
the disk structure i use for the moment is big:
.call=0    ; function
.cmd=4     ; drive command read or write
.drv=5     ; drive number, BIOS based
.cnt=6     ; count of sectors to read
.s=8       ; starting sector
.h=9       ; starting head
.c=10      ; starting cylinder
.off=12    ; where in segment
.seg=14    ; where in ram
.s0=16     ; number of sectors
.h0=17     ; number of heads
.c0=18     ; number of cylinders
.kb0=20    ; number of kilobytes

needs to reserve 24 bytes for all disk objects.
the idea to correct the problem will be to reserve only one drive access object for each drives.
the applications will ask the system to r/w the device via the only structure for hte drive or application.
no need to make 10 objects for all drive accesses.
only one for all drive accesses from all application.

to do so, a little object is needed.
the minimal unit of data to lacate and quantifies a file.
LBA(32) + bytes(32)=64. to start.
a 4 gigabytes file is very big for me.

the problem is:
.s0=16     ; number of sectors
.h0=17     ; number of heads
.c0=18     ; number of cylinders
.kb0=20    ; number of kilobytes

apparentlly it is a big waste of memory to use them for each disk objects, and a big waste of ressources to build them.

as stated above, this object, drive geometry at least, will be globalised.

let see the procedure itself:

        call .id
        mov al,[si+.s]
        mov ah,[si+.h]
        mov bx,[si+.c]
        mov cx,[si+.cnt]
        mov dx,[si+.off]
        push cx dx es
        dec word[si+.cnt]
        jl .end
        push ax bx
        mov cx,bx
        mov bl,cl
        mov cl,ch
        mov ch,bl
        shl cl,6
        and cl,0c0h
        or cl,al
        mov dh,ah
        call .atom
        jnc @f
        call .atom
        jnc @f
        call .atom
        jnc @f
        pop bx ax
        jmp .tchao
        add word[si+.off],512
        pop bx ax
        inc al
        cmp al,[si+.s0]
        jne @f
        mov al,1
        inc ah
        cmp ah,[si+.h0]
        jl @f
        mov ah,0
        inc bx
        cmp bx,[si+.c0]
        jl .next
        mov bx,0
        jmp .next
        call .reset
        mov bx,[si+.seg]
        mov es,bx
        mov bx,[si+.off]
        mov ah,[si+.cmd]
        mov al,1
        mov dl,[si+.drv]
        int 13h
        mov dl,[si+.drv]
        mov ah,0
        int 13h
        cmp byte[si+.drv],0
        jnl .floppy
        call .reset
        jc @b
        mov ah,8
        mov dl,[si+.drv]
        int 13h
        inc dh
        mov [si+.h0],dh
        mov bx,cx
        and cl,not 0c0h
        mov [si+.s0],cl
        mov cl,ch
        mov ch,bl
        shr ch,6
        inc cx
        mov [si+.c0],cx
        movzx ax,byte[si+.s0]
        movzx bx,byte[si+.h0]
        mov cx,word[si+.c0]
        imul ax,bx
        imul ax,cx
        shr ax,1
        mov [si+.kb0],ax
        mov word[si+.c0],80
        mov byte[si+.h0],2
        mov byte[si+.s0],18
        jmp @b
        pop es dx cx
        mov [si+.off],dx
        mov [si+.cnt],cx

as you can see, it use the BIOS int13h and for all disk operation, it will build the disk size field using BIOS drive ID.
but, it can be avoided by using a global drive identification for exemple.
this ID, where to put it?

then, it reloop the problem somewhere in the kernel, if the kernel is really modular, it will not have a fixed location for drives IDs.

th emodularity will be killed a little.
for example, an application that will access the drives will have it's own drive context, but only one time, at a specified location.
for example the application will enter with [desk], and the related drive context is [drive]

desk as ram, and drive, as hard disks and floppies.

Last edited by edfed on 09 Nov 2020, 11:39; edited 2 times in total
Post 15 Jun 2008, 11:28
View user's profile Send private message Visit poster's website Reply with quote

Joined: 20 Feb 2006
Posts: 4282
Location: Now
edfed 21 Sep 2008, 23:42
finally, i adopt this sheme previouslly aborded.
it works very well, need some bugfix ( very meticulous work).
bug's are theses:

if you don't mov value at [esi+disk.drv] with the right dl, it don't work at all.

3 essentials functions use disk structure.
reboot, to read the bootsector and jump to it at 0:7c00h, need plain dos ( not tested).

bootcopy, to copy the bootsector on a drive

install, to install the current settings on a drive.

be carefull, use only with test drives.
test config:
 ali chipset
 1025 MB Compact Flash as secondary master
 LG DVD player as secondary slave
 floppy drive 
 RTL ???? retwork card
 SIS 6215 ( hard 24bit/pixel )
 SB PCI128
 serial mouse
 AT keyboard

it don't works when i type:
install 128 <enter>
bootcopy 128 <enter>
reboot 128 <enter>

but it has worked only one time with:
x <enter>
and don't hav the time to test more tonight...

Description: is there a letter before alpha?
Filename: shell.zip
Filesize: 189.33 KB
Downloaded: 145 Time(s)

Post 21 Sep 2008, 23:42
View user's profile Send private message Visit poster's website Reply with quote

Joined: 20 Feb 2006
Posts: 4282
Location: Now
edfed 09 Dec 2009, 05:14
now, f.disk uses a pointer to a fptr to access memory.
and the best, it uses LBA instead of CHS, even for floppy.

it gives this structure:
.geometry=16 ;returned by disk operation
.kb0=20 ;returned by disk operation


to do a drive id,call an empty disk item (.ptr=0)
.ptr îs a 32bit offset in current address space (org ???)
id ptr=0, then, it is not a valid pointer, and it ends.

i like this '0' value.

next step, link it to a file system.
the first attempt is in bootwriter06

it uses DOS int21h

3Dh, 3Fh, 3Eh.
open, read, close
the dos handle is only used inside this linear stream.

then,it limits my needs from file system to that:

.ptr=4 ; same structure as one pointed to by disk. Smile
.name=8 ; ascci path and name of the file, a command line parameter for example.
.handle ; value returned by dos, but not used by fool.

knowing theses needs, it is easy to do a singular structure around fptr

effectivelly, fptr have all the chances to become a file system structure.


.size is used by disk and updated by fileread.

if you want to read 321 bytes from a 32 bytes file, it will be usefull.

if you wan to set the file size to a sector boundary.
etc etc.

a file would be represented by this on the disk:

xfile:  ;lol

there, you see it can be possible to set a ram location for the file.
just to show it is still in ram,at the fptr location.
if fptr = 0, then, the file is on the drive, or nowhere.
this value is not modified on the drive. only moded in ram.
the cached folders will contain the xfiles, xfiles are only file descriptors.
like the DOS handle

then, a file in ram will be descripted by it's descriptor in folder (in ram too). if not in ram, then, read it from drive. and update fptr.

file access can be only with the 'path/folder/file' style.
but after loading, the path is converted into a fptr.

and this fptr is a DOS-like handle.
a little more fool.

to update fptr, i need memory management .
Post 09 Dec 2009, 05:14
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.