FAT32 again

FAT32 work is still going on. Yes it's a pain in the ass, but it's moving. LFN code is written. FAT code is written. Just file and dir code left

FAT32

FAT32 is a terrible filesystem. Fat16 and 12 are ok because the FAT is small enough to fit in memory (max 128K) so that it can be fast. FAT32 FAT can be up to 256 MB in size, and cannot be fit in memory. Since FAT32 does not feature a free cluster bitmap, finding free clusters on a moderately-filled FS can be a big pain. My FAT32 driver attempts to optimize this by creating a compressed free-cluster bitmap in memory and fills it lazily as FAT sectors are read for general use. This means that the longer one uses a FAT32 volume, the faster file creation and writes get. This is a strict improvement over most other FAT32 drivers, which start slow ad remain slow.

General Project Status

I get asked a lot what the project status is, and when i can release a beta. First let me say that this question is rather pointless. No, not because I want to be cruel and keep it a secret. It's because I really do not know and have no way of knowing. I work on this in my free time, so while I can estimate the percentage completion of the project, I cannot estimate the time remaining because I do not have any hard time commitment to this project.

That being said, it is also worthwhile to point out that normally a whole modern OS (even a simple one) is work for hundreds of engineers and a year or two of work, while I am just one guy and working in my free time.

---

The heart of any OS is the kernel. It provides memory, scheduling, storage, and arbitration of other resources. DGOS kernel is written from the ground up by me over the last few months. IT provides full protected-memory processes with multitasking and support for multiple hardware storage and filesystem drivers. It has a plugin architecture, which functions in a way not unlike the way microsoft windows drivers work. The kernel works, and I do not forsee much more work in it coming up, since all new things will be loadable kernel plugins, and not work on the kernel itself. The kernel is written in C and arm assembly and is compiled by the metrowerks codewarrior compiler. All plugins have to be compiled by GCC. (There is no support in CodeWarrior to produce working plugins, though with enough effort, it can be done)

Close to the kernel are the drivers. They provide various services and methods to work with hardware. DGOS kernel currently best supports the PXA270 processor (such as the one in a Palm LifeDrive). There are drivers for timers, real time clock, LCD, sound and touchscreen, the notification LEDs, the built-in hard disk, and the SD card. This, of course, leaves out WiFi, Bluetooth, and USB. Work on USB is ongoing, and WiFi and bluetooth will be done later or provided by PalmOS drivers wrapped in special DGOS wrappers (not unlike ndiswrapper does on linux). Currently written drivers are in the kernel, all future ones will be loadable plugins.

Above the kernel sits RtLib. It's the userspace library that wraps the usually-strangely-called system calls into ARM-EABI compatible function calls, as well as providing basinc runtime services like heap management. You can read all about it in a recent post about RtLib => [here] <= . RtLib is still being written, but it already provides many useable things, and simple apps have run on top of it.

Userspace apps run on top of RtLib and may use any number of other libraries, as they wish. Currently two uch libraries exist. The DGOS port of jpeglib (which is interesting in that it required no code changes and built form the original source just fine, and ran) and GfxLib (which is a simple library that currently provides abilities to draw rectangles, lines, circles, and a very very simple fixed-width font). In the future it will probably be expanded slightly, but in general it's expected to be the basic simple drawing library.

The UI will be provided by UiLib, which still needs to be written. Luckily this is not a huge effort, since a lot of SkinUI code can (and will) be reused for it.

PalmOS compatibility will be provided by an application whose job will be to

• Provide a full R9-table of functions that NAtive PalmOS apps need
• Host such apps and handle their hardware accesses in appropriate ways
• Parse and access PalmOS's data structures on disk, so that PalmOS and DGOS can share PalmOS files(reboot into PalmOS and your datebook has the entries you just added in DGOS
• Allow Palm's PACE to run, or implement DGOS's own version of PACE
• Provide access to things like network and expansion cards

Of course no OS is complete without its own userspace apps, and an SDK. The SDK is hard since putting one together is a monumental task. Luckily for DGOS this is not hard, since almost any linux library will run on DGOS is recompiled for it. Of course the UI toolkit will be different, BUT to PalmOS programmers the UI apiw ill be familiar and simple, so the SDK will be a mix of linux standard APIs and PalmOS UI apis, with a mix-in of user-requested features I choose to implement.

So so summarize, the project is doing well, and there is a chance of a release of something of interest to developers (but likely not to final users yet) really soon.

FAT32

the fat32 library i had apparently is more worthless than i had imagined, and i had pointlessly spent time outfitting it with LFN support. Writing a new one now

On Architecture: RtLib

RtLib is the main runtime library that all apps will dynamically link against. While it is technically possible to write a DGOS app that does not use RtLib, it's needlessly complicated and pointless(One would have to do manual heap management, manually initialize all libraries, manually get and parse app params, manually make systemcalls, and not use any delay-loaded dynamic libraries). It provides useful things like

• Runtime functions needed for support of float and double types (no need for each app to have a local copy and waste memory on it)
• Systemcall wrappers (like VfsFileOpen or GetCurTid)
• Memory management (like malloc, free, and realloc)
• Other commonly useful things (like CreateThread or CreateProcess)
• Manual library management(RtLibLibLoad, RtLibLibUnload, RtLibLibFindSym)
• Syncronization primitives (like mutexes, semaphores, mailboxes, events, and request queues)
• Startup code (init libraries, init heap, allow libraries to self-initialize, get app command and parameter block from the kernel, find main(), call main() )

It is currently my intention to make RtLib open source, just like all other non-kernel pieces of the OS.
Just like all non-kernel components of the OS, RtLib is compiled using the arm-elf-gcc toolchain (I use version 4.2.3). As a sidenote, the kernel is compiled using CodeWarrior, but all loadable kernel modules will be written using GCC as well.

Work Continues

I'm back from my vacation, and work goes on. Now will be doing some RtLib work for app startup.