The FYS OS code named Konan

The FYS OS: code named 'Konan'

Last update: 2 Sept 2009

I have started a Blog about my interests and findings about creating
this operating system along with older news.

Recent News
2 Sept 2009 Did a floppy re-write. It isn't complete, but should be much better.
Please check it out and see. I also fixed a few things in the DMA along with a few
other items pertaining to the floppy controller.

Also, if you use the QEmu .zip file, be sure you have at least version 0.10.6 of QEmu or
it may not work so well.

18 July 2009 Simply forgot to "comment out" the parallel debug output, therefore
some machines would have been quite slow going. New image file fixes that.

9 July 2009 I have added support for the EHCI controller. It still needs some work,
it doesn't support hubs yet, but in general, the code is there. UHCI still has a few small
errors, OHCI seems to work pretty good. The Beagle USB Protocol Analyzer from
Total Phase has been indispensable with my work...

(For older news related to FYSOS, go here)

There has been a few differences in the way a few emulators handle the floppy code, therefore I have
added three different images, each specifically coded for that emulator. There should be no difference
other than the way the emulator (or real hardware) detects the Floppy Controller and Drives, and a few
other hardware differences or emulator bugs.

1.44meg floppy image (932k) for Bochs, VMWare, and/or real hardware (2 Sept 2009)
1.44meg floppy image (945k) for QEmu v0.10.6 (2 Sept 2009)
1.44meg floppy image (932k) for MS VPC (2 Sept 2009)

148Meg image (2.5 Meg) (12 Aug 2008) with a eMBR and a FAT12, FAT16, FAT32, FYSFS, LEAN, and a Ext2/3/4 partition.

For some reason the GUI freezes before it even loads when booted from a partition.
It works fine from the floppy. The above demodisk.zip image is mainly to demonstrate and test the different
filesystems on it. For a stable boot, use the floppy image.

I will most likely update the first image on a usual basis, as the other two may lag behind.
QEmu doesn't seem to like my Floppy Controller/Drive code at all. QEmu doesn't recognize
some of the commands I send to it. The QEmu team knows of the problem and should have a fix
in their next release.

If you are new to FYSOS, please read the text below before downloading.
If you have any questions or comments, please let me know at
fys [the at sign goes here] frontiernet [d o t] net

(The zip file now includes an installer to install the a.img file to a 1.44m floppy disk. Please test the
install.com app, for I have not done much testing with it.)

FYSOS is a single-tasking multi-threading kernel that runs on an Intel x86 compatible 80386 with a 80387
coprocessor supporting most of the generic and some of the newer hardware assosiated with this type box.

FYSOS has a Virtual File System layer so that any type file system can be installed and used with only
a detection routine and a driver. There is absolutely no kernel code that is dependant upon the file
systems used.

Here is a list of the File Systems I have and their status. Each FS listed has the framework built,
but unless specified, is not complete.
- Ext2/3/4
I have a Read/Write driver for Ext2/3/4. Ext3 is almost identical
to Ext2 except for the advanced feature of Ext3, namely a journal.
I need to add support for extents (almost completed), as well as
a few other things. I don't have the journal supported, though.
- FAT 12/16 and 32
This FS support is mostly complete. I lack a few LFN services as
well as a few other generic services.
- FYSFS
This is a small FAT style FS that I created mostly to test the kernel
to make sure it was independant of the host file system.
For more information, have a look at: this spec sheet.
I have most of the code done on this FS. I have made a few modifications
to the specs, and am thinking of a few others that I might make, though
not trivial modifications.
- HPFS
This FS has been used with older versions of WinNT, and IBM's OS2.
I am not sure if these specs are the same for each platform.
Each platform may have used a different specification of the same file
system. I am targeting the OS2Warp3 version, FS version 2.2. I have
quite a bit of read-only work done.
- ISO (9660)
This is the FS that is used on some/most CDROM's. I have most of the
read only code finished. I have not written any code for writable CD's
or DVD's.
- ISO (Joliet)
Hardly anything has been written for this FS yet.
- LEAN
This is a FS that is specified at
http://freedos-32.sourceforge.net/doc/lean.html.
It is compared to the FAT file system only as "FAT compaired to LEAN".
i.e.: a play on words. A newer, more detailed and robust version of this
FileSystem is now listed. I have also completed my implementation. I have
a working read/write driver for this FS and will most likely make this my
default FileSystem. There are a few small items here and there that I must
complete, but unless I find some errors, this FS code is complete. I am also
waiting on the author of the LEAN specs to have a few images of his own so
that I may test it more.
I haven't completed it yet, but I am working on a complete and detailed recovery
utility that will thoroughly detect and correct errors and other items on a
volume with this FS installed.
- NTFS
This is the FS used with most modern WinNT versions of Windows including
WinXP. I have a mostly complete and working read-only driver for NTFS. I
lack a few things like security, encryption, and this sort of thing. However,
if the volume is a plain vanilla NTFS volume, FYSOS will read it just fine,
though quite slowly. It has a lot of unneeded code at the moment.

FYSOS supports the following hardware with progress as specified:
- ACPI
Little has been done other than detecting and displaying the data
- ATA
FYSOS fully supports the ATA-3 specs, with a majority of the ATAPI-6
specification implemented. I lack a few small details of the ATAPI-6,
and should be pretty close to the ATAPI-7 specs.
- APM
There is not much support for APM since I will include APCI.
- Audio
Not much has been done here. I have a little ac97 and Sound Blaster
code written, but that is about it.
- CPU/FPU
A 80386 Intel x86 compatible CPU and other features that require
a 80586 (Pentium) CPU. I have not used any of the advanced instrutions
of more modern CPU's like MMX, SSE2, etc. However, the CPUID and RDTSC
instructions are used, only if detected though.
- CMOS
FYSOS can detect a 128 byte cmos and use most of the "known" values
in the first block of the cmos.
- DMA
Floppy DMA is supported. Other DMA's are not.
- FDC
The 5 1/4" and 3 1/2" floppy drives are supported with most formats.
- Game
Nothing more than detecting the old style game port.
- Keyboard
FYSOS fully supports the PS2 style keyboard. I am working on the
USB Keyboard code.
- Mice
The serial and PS2 mice are supported, but currently without display since
the GUI is not yet at a point to use one.
A USB mouse is also supported.
- Network
The ISA NE2k network card is supported. With a little more work
with the PCI, the PCI NE2k card should work as well.
FYSOS has the workings of a TCP/IP stack and announces itself
to a LAN of other boxes with various platforms including WinXP
and Win98SE. Each box recognizes FYSOS, but has problems communicating.
I need to do some more work with the network code, so currently
the network detection code is commented out.
FYSOS almost has a working driver for the RTL8139 NIC.
- Parallel
FYSOS detects the four different types of parallel cards and has
generic interface for them.
- PCI
FYSOS supports the generic PCI interface allowing most cards to
be initialized and to be used.
- PIC
The old style PIC is supported. Plans on using the APIC and APCI
are in the works.
- Serial
FYSOS detects the UART serial bus and sets up the hardware and
software for communications. However, that is about it.
- USB (UHCI, OHCI, and EHCI)
FYSOS has a working USB stack. The USB hardware layer should be
mostly complete, with UHCI, OHCI, and EHCI drivers, (the EHCI
driver still needs some work).
The USB code recognizes a (dis)connection, enumerates all devices
on the bus and tries to load drivers for them.
I am using the Beagle USB Protocol Analyzer from Total Phase for my research.
My code will now recognize and read from a USB flash drive. Write
should be a matter of adding a few service calls, nothing more.
It is quite slow, but does work.
However, for some reason, I can't get it to reset most brands of
flash drives correctly (on the UHCI). It has to do with a timing
issue since my code works well in Bochs and other hardware devices
work as expected. More work I guess.
The Beagle mentioned above has helped out well. Just out of curiosity,
if you have one and/or have used one, let me know at fys [at sign] frontiernet [dot] net.
- Video
Other than the 16-bit real mode (or V86 more) BIOS VESA interface,
not much is supported.

I might have missed something, so if you have a question on a certain
type of hardware, let me know.

As for now, the FYSOS code has not been released. You can get a 1.44meg image ready to run in
Bochs or ready to write to a floppy for real hardware boot up.

The Boot code is for a 1.44meg 3 1/2" floppy formatted for the LEAN file system. However, no matter the FS,
the OS should boot the same, though if the image is not FAT12, you may not be able to read/write to/from the
floppy using other platforms and boxes.

The boot code does nothing more than find the loader.sys file, load it to a specified location, then jump to it.
The boot is all in 16-bit real mode code. The loader.sys file can be anywhere on the disk and can
be fragmented, as long as it is in the root directory. With a small stack, I am sure I could make the
code search the directory tree to find the loader.sys file. As long as I have the space, right?

The loader code looks at a list of filenames and loads each file to the specified place. Each file also has a
header appended to the file for just this data. The loader code now supports compressed files.
Originally, the kernel.sys file is more than 900k, but now with bz2 compression,
the kernel.sys file is around 300k and gets decompressed by the loader.

Once the kernel.sys file is loaded, loader.sys gets a few other items from the bios while it is still accessable
in 16-bit mode. An example is the current time is calculated from the bios clock services.

Finally, the loader.sys code puts the CPU in pmode, sets up the segment descriptors and jumps to the kernel.

The kernel.sys file is loaded to 0x00600000 (6 meg) and starts the hardware detection and setup process. It first
creates a multithreading environment with each thread interval at 10ms. It also sets up the interrupt descriptor
table and a few other CPU related items before it starts the round-robin type task switch code.

The boot and loader code are written in x86 assembly using the intel style syntax. They are built with nbasm 00.26.10.

Download the 1.44meg floppy image.

Boot the floppy on a 386+ machine. Once you get to the command prompt, a file has been created on the floppy
called "debug.txt". I would like to see this file. Please send it to
fys [the at sign goes here] frontiernet [d o t] net

From here on, it is up to you what you do with the OS. It isn't very functional, so unless you are just curious,
there isn't much more. For now, I am just interested in the boot up sequence and error codes that are returned
for various machines.

As far as I know, this image will *not* hurt your machine in any way.
Since I do not know for sure,
**** use at your own risk ****.

FYSOS will read from your hosts hard drives, simply to mount the filesystems that are on them. It will not write
to them through out the boot process. *** However ***, if you continue to use the command prompt and happen to
change the current drive to one of the hosts hard drives, your hard drive may be corrupted depending on the
filesystem it holds. I say may, because there is a slight chance that there may be a bug in the filesystem code
that could possible destroy your data. Please use caution when accessing your hard drives. I have tested FYSOS
with hard drives that use the FAT and NTFS file systems and have had no problems yet. However, I am not 100% sure
that it is bug free. The NTFS code is read only and should not effect your data at all. However, you have been
warned.

Thank you for your feedback.

Ben

P.S. Please note again, that I have taken every precaution to make sure that this image will not harm your host
machine. But I must still say:

*** Use at your own risk ****

Here is my bochsrc.txt file for running in a Bochs
session. Please note that I have a few entries in the ATA
lines that you will need to comment out.

I have written a few utilities useful when testing your OS with Bochs.