You are not logged in.


#1 2012-02-04 21:30:47

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

fat12 thoughts

Hi!  I'm not sure if I even have enough visitors to ask anything on my own forum but just in case anybody drops in and has anything to add on the subject. tongue

I'm halfway in my FAT12 driver, the VFS part is also mostly done but while thinking about the interfaces towards user programs I'm not sure what would be best.

My initial idea was to have "read_file", "write_file", "del_file", "read_dir", "create_dir" and "del_dir" where the write_file would take arguments for create if it's non-existing, write interval in file only and stuff like that. 6 neat functions that do all, with just extra parameters for special cases and settings. The file path would be needed for each call.

But thinking about it and also having a closer look at how DOS does things have made me doubt this. DOS uses internal file handles for everything where the only function taking a path is "open_file", it then has "file_seek" with handle as input, "file_write" with no. of bytes from current file position, a special function for creating or truncating and one for closing the file.

Is there any good reason to model my API after DOS in this regard, with handles open/close and so on?  With my initial thought it would still be possible to read out part of the file, truncate and everything else you might need but with extra parameters instead of all those extra functions.. Also what if you forget to close the file? I'm sure it has some reasons, like file locking while editing? But, hmm.. should still be a better way?

I also have another question about the "read_dir" function, what should it return and in what format? I'm planning to support LFN, so that also raises the question if it should provide an option to get the short filename or only the long version?  In any case, pointer to zero terminated names in a row after each other with another reg for total size is that enough? Leaving the rest to user programs?  What about file sizes and so on, would a DIR command need to make another call for each file returned to get file information like size, type and last modified date? It wouldn't be hard, but is it bad design to require that? Could use "read_file" with special argument for just getting file info like that.

Anyway, more functions vs less? Any thoughts?

Offline

 

#2 2012-02-05 04:33:40

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

I've decided to use file handles, but I still might go for the simpler approach inside the fat12-driver. Because I just realized that locking files, keeping track of handles and just presenting a unified API is up to the VFS anyway..

Haha almost forgot about that, since the VFS up until now mostly have been responsible for device drivers and internal structs for device->fs. But obviously it will also be the central point for all incoming file read/write requests with stub functions to call each FS-drivers internal functionality.

Offline

 

#3 2012-02-06 01:56:58

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Hi just remembered my password lol
I thought i would put my input.
I am going the Dos way myself, that's because its well documented and alot of asm tut are based on it.
So by using the same reg other then 32/64bits, beginner will be able to translate old tuts.
You will find it easier to port stuff like fasm and c libs etc.

Offline

 

#4 2012-02-06 04:33:23

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

hi, hehe good news and great seeing you here! smile

yeah, a general file handle for opening and seeking is fine, because it's not tied into fat12 so support for that with open, close, seek truncate and everything else is decided. as you said, will probably make my life easier when porting apps too.

but the one thing i'm yet not sure about is how you get a directory listing in dos. all i found was lots of interrupts dealing with what they called FCB (file control block), which seems to be the raw fat12 dir struct for each file, but nowhere do i find an interrupt on how to obtain this fcb block in the first place? and even if i do, i have to basically do a wildcard search for files with the directory FCB...  it all seems confusing and when it comes to getting a directorys content i'm not sure how to handle it, what info to include and so on.

if it's just a list with names, it would still be possible to open each file or request additional info like size and last modify date via other functions with full path&filename.  one thing is for sure, i do not want to include raw fat12 dir/file entries because it won't be portable between different file systems later.

how does the directory listing work in dex, what output can a user program get when wanting a list of files? btw, do you have sub-dir support, if not - i guess you still have some sort of listing call for the root?

Offline

 

#5 2012-02-06 19:51:13

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

First most of the info as to how it works are dos virus lol
But once i new how it works, i must say i realy like it.
Heres a nasm example that helped me

Code:

org 100h
start:
mov ah, 0x1A   ; Set DTA table adress
mov dx, DTA
int 21h

;"find_first
mov ah, 0x4E
xor cx, cx      ; no attributes
mov dx, squery
int 21h
jc theend       ; no files matching query found

mov ah, 9
mov dx, fname
int 21h

find_next:
call  clean_name
mov ah, 0x4F
mov dx, squery
int 21h      ; find next matching file
jc theend    ; no more files found

mov ah, 9
mov dx, fname
int 21h

jmp find_next
theend:
mov ah, 0x4C
int 21h

clean_name:
mov cx, 13
mov di, fname
xor ax, ax
repe stosb ; fill name with zeros incase memory has some ugly stuff or smth left from last search
ret

squery db "*.*", 0x0 ; search query, must end with zero

DTA resb 0x15 ; ignore useless DOS data
fattr db 0x0  ; file attribute
ftime dw 0x0  ; file creation/modification time
fdate dw 0x0  ; file creation/modification date
fsize dw 0x0  ; file size
fsmth dw 0x0
fname resb 14 ; file name terminated with zero
      db 0xD, 0xA ; New line
      db "$" ; 0xD - tells DOS to go to new line.

1.First you need to set a new address for "DTA table adress" to send the info about the file

2. then you send the "find_first" function (with search query) of wanted file.

3. test for no files found, if found print it.

4. Then you call "find_next", this over writes the stuff stored in the  DTA, so if i was you i would move it to a safe place to print later.

5. you keep loop the "find_next" function untill no more file.

Now this is for Dos, but you just need to implement the above function in BOS.

I am writing the above along with fat12/16 as a driver for my OS you could just implement the driver interface.

PS: I will post a none gui ver of the way it works so you can test, as the gui seem to be the problem in bochs.

Last edited by Dex4u (2012-02-06 19:57:57)

Offline

 

#6 2012-02-06 20:39:35

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

Oh, ok thanks now when I know what to search for I was also able to find more documentation. It's certainly easier for the OS than giving a complete list of all files - since it's hard to know the size beforehand. I do not have any realloc-thing to resize allocated space so would have to allocate something like 4kb and if thats filled, allocate another 4kb (total 8kb), copy the contents over to the new mem and free the first 4kb. Such techniques would still make it possible to provide a complete list - but as I said, this would be even easier.

Thanks for your input it's been helpful!  If you don't mind letting me have the source temporarily I could debug it myself and try to patch it for you so the GUI works in bochs, I'm not sure what license you'r on right now but if it's closed I could make sure to delete after fixing it.

Offline

 

#7 2012-02-06 21:16:09

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Glad it helped, the GUI source is in the zip you down load from the site (in the GUI, folder).
If any ? just ask.

Offline

 

#8 2012-02-06 21:28:45

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

Okey, I thought the /old/ page meant that the OS source was old too. I'll check that out right away and see if I can't find something out!

Offline

 

#9 2012-02-06 23:05:09

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

No not the old page.
Go here:  http://www.dex-os.com/
And click the download button its in theres.

Offline

 

#10 2012-02-10 20:31:35

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

making some "progress" now, not excatly polished look on anything yet, but working more on the behind the scenes functions:


http://bos.asmhackers.net/screenshots/forum_extras/fat12.png

working on a parse_path function now that still has a few bugs to work out, it doesn't seem to report any consistent numbers for how many parts the path consists of, should be 0 for fd1 or fd1/, 1 for fd1/folder or fd1/folder/ and 2 for fd1/folder/test or fd1/folder/test/
not quite there yet as you can see, not sure if i dare publish the buggy code since it's not very well coded tongue

http://bos.asmhackers.net/screenshots/forum_extras/paths.png

btw, right now i just subtract 0x30 from the ASCII number to get binary, but thats only for 1 number and wouldn't work for fd12 or hd54 in case you have that many devices.  does anybody know of a good ascii2bin function for ax(2) or eax(4) ascii numbers to binary?  should  still subtract 0x30 and then *10 on each level to get base right, but I don't feel like doing it myself - there should be plenty of functions out there but i can't find any. hmm

Offline

 

#11 2012-02-10 21:36:27

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Nice work smile, if you take a look in the functionPM folder in DexOSv5 code theres a include thats called convert.inc, you will find the function you need in there.
"testhex" is the one you call, with number in eax and zero terminated string out put is in numbuff2
Hope that helps.

Offline

 

#12 2012-02-10 22:14:53

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

thanks but I mean the other way around, like:

mov eax, '1234'
call ascii2bin
eax->1234 or 0x4d2 (real number)

eax as input would be enough since i only need for two ascii numbers to convert into int, but why not support 4 bytes while i'm at it wink  anyway, have been searching for a ready made function, but maybe ascii2bin isn't right, might have more luck with ascii2int or something?  i'll continue looking.

eh. nevermind... made my own special case function that works ok on two ASCII chars to number:

ASM code:

     ; ah = first ASCII like 2, al = second ASCII like 1 = making number 21
     .convert_cont:
          push    ecx
          xor     ecxecx
          cmp     ah0
          jne     .cont_convert
          pop     ecx
          sub     al0x30                            ; only one ASCII char.
          jmp     .number_found                       ; done.
     .cont_convert:
          mov     clah
          sub     cx0x30                            ; take care of first
          push    ecx                                 ; save it for later..
          mov     clal
          sub     cx0x30
          shl     cx1                               ; multiply with 10 using
          mov     eaxecx                            ; x*8 + x*2 =
          shl     cx2
          add     axcx                              ; x*10
          pop     ecx
          add     axcx                              ; add first number
          pop     ecx       

     .number_found:

maybe not the most elegant solution there is, but made it work so, will have to do. i feel rusty, like most my current code could have been better.  well well, now to debug the other aspects of the function, it will take cl as second parameter, if it's filled = return only that part of the path... so i can loop a path with this and take it one level/dir at a time.

Offline

 

#13 2012-02-11 17:46:16

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

Finally.  Everything seems to work now, so now sub directory support will be easier to achieve.  Here's a screenshot on how it looks in action, with the parsed parts outputed in a loop after the first call to check how many they are:

http://bos.asmhackers.net/screenshots/forum_extras/paths_done.png

and here's the full function source, in case anybody has some remarks on it. Since it's the first bigger thing I've done in assembly for like 5 years.

ASM code:

;--------------------------------------------------------------;
;   parse_path  -  parse path to get info on each part         ;
;--------------------------------------------------------------;
;                                                              ;
;             in:  esi = pointer to full ASCIIZ path           ;
;                  cl  = part no. to extract or 0 for none     ;
;                                                              ;
;             out: bl  = drive no. (VFS assigned) or zero      ;
;                  bh  = number of elements or zero for none   ;
;                  edi = pointer to ASCIIZ part of path in     ;
;                        cl, or 0 on error or no input         ;
;--------------------------------------------------------------;
parse_path:
          push    eax
          push    ecx
          push    edx
          push    esi

          cmp     byte [esi], 0
          je      .error
          cmp     byte [esi+1], 0                     ; minimum 3 chars drive
          je      .error
          cmp     byte [esi+2], 0
          je      .error

          and     byte [esi], 11011111b               ; (0xDF) to uppercase
          and     byte [esi+1], 11011111b             ; (0xDF) to uppercase

          mov     bl0x00                            ; fd base is 0x00
          cmp     word [esi], 'FD'                    ; fd check
          je      .drive_found
          mov     bl0x0F                            ; hd base is 0x0F
          cmp     word [esi], 'HD'                    ; hd check
          je      .drive_found
          mov     bl0x5F                            ; cd base is 0x5F
          cmp     word [esi], 'CD'                    ; cd check
          je      .drive_found
          mov     bl0x7F                            ; rd base is 0x7F
          cmp     word [esi], 'RD'                    ; rd (ram drive) check
          je      .drive_found
          mov     bl0x8F                            ; rm base is 0x8F
          cmp     word [esi], 'RM'                    ; rm (removable/usb)
          je      .drive_found
          mov     bl0xAF                            ; nd base is 0xAF
          cmp     word [esi], 'ND'                    ; nd (net) check
          je      .drive_found

          jmp     .error                              ; no valid drive found

     ;-----------------------;
     ;   get drive number    ;
     ;-----------------------;
     .drive_found:
          xor     edxedx                            ; esi offest for first /
          cmp     byte [esi+3], 0                     ; end of path
          je      .one_number
          cmp     byte [esi+3], '/'                   ; one number
          je      .one_number

          mov     edx4                              ; first / after numbers
          xor     eaxeax
          mov     axword [esi+2]                    ; get 2 bytes number
          jmp     .convert_cont
     .one_number:
          mov     edx3                              ; first / after numbers
          xor     eaxeax
          mov     albyte [esi+2]                    ; 1 byte ASCII number
     .convert_cont:
          push    ecx
          xor     ecxecx
          cmp     ah0
          jne     .cont_convert
          pop     ecx
          sub     al0x30                            ; only one ASCII char.
          jmp     .number_found                       ; done.
     .cont_convert:
          mov     clah
          sub     cx0x30                            ; take care of first
          push    ecx                                 ; save it for later..
          mov     clal
          sub     cx0x30
          shl     cx1                               ; multiply with 10 using
          mov     eaxecx                            ; x*8 + x*2 =
          shl     cx2
          add     axcx                              ; x*10
          pop     ecx
          add     axcx                              ; add first number
          pop     ecx

     .number_found:
          add     blal                              ; add number to base

     ;------------------------;
     ;  parse parts of path   ;
     ;------------------------;
          mov     bh0                               ; start at zero
          add     esiedx                            ; add start offset

          cmp     byte [esi], '/'
          jne     .end                                ; root, no parts
          xor     eaxeax                            ; counter
     .parts_loop:                                     ; loop for path parts
          inc     esi
          cmp     byte [esi], 0                       ; end of path?
          je      .end                                ; no inc in parts
          cmp     byte [esi], '/'                     ; end of part?
          je      .new_part
          cmp     eax0
          jne     .cont_parts
          inc     bh                                  ; inc no. of parts
     .cont_parts:
          inc     eax                                 ; char count inc

          cmp     clbh                              ; check for part to
          jne     .parts_loop                         ; save, if match:
          mov     edi.filename_buffer               ; get buffer
          dec     edi                                 ; offset starts at 1,
          add     edieax                            ; not 0 - so fixed now
          push    eax
          mov     albyte [esi]
          mov     byte [edi], al                      ; put the byte
          mov     byte [edi+1], 0                     ; make ASCIIZ
          pop     eax

          jmp     .parts_loop
     .new_part:
          xor     eaxeax                            ; reset char count
          jmp     .parts_loop                         ; loop again

     ;------------------------;
     ;   cleanup and return   ;
     ;------------------------;
     .end:
          mov     edi.filename_buffer
          pop     esi
          pop     edx
          pop     ecx
          pop     eax
          ret
     .error:
          pop     esi
          pop     edx
          pop     ecx
          pop     eax
          mov     edi0                              ; not a valid part
          mov     bl0                               ; not a valid drive
          mov     bh0                               ; not a valid path
          ret

     .filename_buffertimes 256 db 0

Offline

 

#14 2012-02-11 19:48:29

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Nice, i am sure you will soon be back to speed, i started doing some avr asm coding, i was surprised how easy it was to pick it up.

I am working on my file sys, but i am going to stick with the dos method of doing stuff.
It works well and is well documented.

I was thinking of a very simpe VF sys where you us a floppy image.
You load the image in memory at startup read/write every thing to it and on close you write the whole image back to disk.

But for now i will just read write to real disk when needed, as VF sys are more for multi-tasking OS.

[Edit] Have got a copy of that game you ported to DexOS ?.

Last edited by Dex4u (2012-02-11 20:00:31)

Offline

 

#15 2012-02-11 20:34:48

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

I think we mean different things with vfs, I mean the functions and interface for user apps, that take filename or path and drive no. as arguments and then reads or writes no matter if it's a floppy or hd, fat12 or fat32. it would accomplish this by having vars for each drive with info on type and fs so it knows what drivers to use/call. using the floppy as a kind of ram-disk is another possibility of course, and I'll have a ram disk driver that can use any size and any of the installed fs's.

I'm not sure if I still have it, will take a look. But as far as I remember it never fully worked as it was supposed to, not sure.. The porting to 32-bit was a bigger problem then to dex-os since it used lots of multiplications and other things very 16 bit specific.. I can remember trying to clear the upper half of every register and such to make it work.

Offline

 

#16 2012-02-14 13:08:11

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

Hi, I found the DEX-OS sources for pitman in a folder on this server! tongue
Here's the URL: http://dex4u.asmhackers.net/

Seems to have a compiled version named .dex but not sure if it runs correctly?  as i said, think i got problems with 16->32 bit converting..?

Offline

 

#17 2012-02-14 22:42:14

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Thanks i will see if i can update it to the new DexOS ver.

Offline

 

#18 2012-03-01 20:12:26

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Any news, on the fat12 front ?

Offline

 

#19 2012-03-02 00:17:04

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: fat12 thoughts

Hi, yes I'm making progress even if it's slow.. I've broken up the things that needs to be done into (internal) sub functions like this for now:

ASM code:

;--------------------------------------------------------------;
;   get_dir_entry  -  get a directory entry or amount          ;
;--------------------------------------------------------------;
;                                                              ;
;       in:  esi = pointer to prev dir entry or 0 for root     ;
;            cx  = entry no. to extract or 0 for none          ;
;                                                              ;
;       out: cx  = number of entries or unchanged if set       ;
;            edi = pointer to dir entry or unchanged if cx=0   ;
;--------------------------------------------------------------;
get_dir_entry:
          ;......
          ret

;--------------------------------------------------------------;
;   get_fat_entry  -  get a fat entry/cluster number           ;
;--------------------------------------------------------------;
;                                                              ;
;       in:  cx  = fat entry/cluster number                    ;
;                                                              ;
;       out: cx  = next fat entry/cluster no. or 0 if none     ;
;--------------------------------------------------------------;
get_fat_entry:
          ;...
          ret

;--------------------------------------------------------------;
;   get_cluster  -  get a cluster                              ;
;--------------------------------------------------------------;
;                                                              ;
;       in:  cx  = fat entry/cluster number                    ;
;                                                              ;
;       out: edi = pointer to cluster or zero if none          ;
;--------------------------------------------------------------;
get_cluster:
          ;...
          ret

Everything is kind of halfway done, but there is quite some dependencies between functions so I'll basically have to wait with testing and debugging until all of it is done.

How about you, any news on DexOS development?

Offline

 

#20 2012-03-02 01:24:23

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: fat12 thoughts

Great minds think alike, i am working on a better file functions and am doing the same as you, i have broken everything down into small functions (so they can be used many times).
But you have to write so many functions, before you can test them, you hope your not making a debugging nightmare for yourself lol.

Ps: As a side note, i am coding mine as a module, so it will need to be loaded.
That way you can change to any file sys easily, i will remove any form of file read/write from the kernel.
The main problem is how do you load the driver without read/write, well i will include it as a file in the kernel, so it can be relocated to top of memory, then other drivers can be load by using the fat driver.

Last edited by Dex4u (2012-03-02 01:32:41)

Offline

 

 

Board footer

Powered by PunBB
BOS homepage © Copyright 2005 Christoffer Bubach
Strict XHTML and valid CSS.