Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi > Hi, > > have you considered EFLS ? I have > a friend that already used it and said that it worked out of > the box. > One suposed advantage is that it was designed for embedded > and has a > small footprint. The licence is LGPL! I know the project,

Re: [Freedos-devel] Porting the FAT filesystem (18)

Hi Imre, > Eric told me you where working on something similar as me, > namely a portable FAT file system. that's right :-) > I am not aware of what your intentions are with this port, > so I am not going to try to steel this from you. > > But have you considered: > - that FreeDOS doesn't ha

[Freedos-devel] Porting the FAT filesystem (18)

Hi guys, here I'm back on track. I've been pretty busy in the past two months so I couldn't finish the port. At the end of the month I'll have the time to continue. How about if I post somewhere the work done so far? It's a "Microsoft Visual C 6.0" project and the test needs just an usb flash

Re: [Freedos-devel] Porting the FAT filesystem (16)

Hi Eric, > The difference in the current implementation is that we now > have a "cache" with two "near" fnodes in the kernel data > segment. That way, fewer far pointers are needed, but > several functions got more complicated. For example > get_f_node. The other difference is that > you use

[Freedos-devel] Porting the FAT filesystem (16)

Hi guys, during the weekendd I made some tests in my port, and wanted to report the results. - 1. dos_mkdir(), dos_rmdir(), dos_delete() - All these fun

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Eric and Bart, yes, upcasing filenames in dos_open() is not a problem. I'll add that in my port. The port status is the following: 1. dos_open(), dos_close(), (*) dos_read(), (*) dos_write() work. I still need to write some more test cases, but I'm quite sure that the FAT calculations are

Re: [Freedos-devel] Porting the FAT filesystem (15)

Hi Eric, I did many debug sessions and that allowed me to study the filesystem code quite well: there are no "toupper" or similar function calls from dos_open() down to exechr(). Enrico > > Hi Enrico, > > > I noticed that in this version of FreeDOS, the function: > > Upmem (unsigned c

[Freedos-devel] Porting the FAT filesystem (15)

Hi, I'm finally able to read files from my USB flash disk :-) I noticed that in this version of FreeDOS, the function: Upmem (unsigned char* str, unsigned int len) is missing and the filesystem seems case sensitive. I indeed can't open an existing file, named "foo.txt", when I call: dos_o

[Freedos-devel] Porting the FAT filesystem (13)

Hi Eric, I'm porting the following function: int rqblockio (unsigned char command, struct dpb *dpbp); In particular, the command I need to emulate is: C_BLDBPB (which builds the Bios Parameter Block) to do that, I'm gonna: 1. Read the boot sector of the volume 2. Make some calculati

[Freedos-devel] Porting the FAT filesystem (9)

Hi Eric, I'm debugging the code and I can't understand the following line: UBYTE bootdrv = peekb(0, 0x5e0); Do you happen to know who writes at this address and what's the content of bootdrv after the peek call? Thanks for any help, Enrico ---

[Freedos-devel] Porting the FAT filesystem (9)

Hi Eric, >> In principle, I would like FFS to be able to handle >> pathnames longer than 67 and possibly read Unicode filenames. > > But then it would not be compatible to FAT. I see... Let's stick with FAT :-) > If you want to > have long unicode file names, then you have to implement > exactl

[Freedos-devel] Porting the FAT filesystem (8)

Hi Eric, > That is not a compile time thing. Most of those variables are in > kernel.asm and the List of Lists, where they either have hardcoded > initial values (f_nodes_cnt is 0) or are initialized by zeroing > out memory areas or by calculating values during kernel init. > yes, I read carefull

[Freedos-devel] Porting the FAT filesystem (7)

Hi Eric and all, thanks for your last answer. The port is almost done and I started to debug the code. I figure that it will take me 2 to 3 months to have a solid and reliable port. I'm using Microsoft Visual Studio 6.0 to debug the filesystem and I temporarily created a simple ram disk. Wh