The FYS OS code named Konan

The FYS OS: code named 'Konan'

Last update: 06 February 2008

I have started a Blog about my interests and findings about creating
this operating system.

(1 April 2008) I have been adding a GUI to FYSOS. It is based on (but heavily modified)
the work of Doug Eleveld's DEPUI at http://www.deleveld.dds.nl/depui30/depui.htm.
In no offense to his work, I didn't like the way some of the code was done so I decided to write
my own based on some of the code I did like :-) I have added quite a bit more function too.
Here is a screenshot.

I am not yet releasing it due to it will only run on MS VPC. I have a bug in my task switching
code that seems to only effect Bochs. VPC doesn't seem to catch it. QEmu has a few other issues
with the GUI, and VMware has a few other issues. I will have to work on them some more before
a release of the GUI.

I am just including a note here saying that I haven't given up on FYSOS. I am still slowly but
surely working on it. Thanks to all of you who have shown interest and reported errors and
the such.

(24 Dec 2007) FYSOS now supports USB external hubs. You can plug in an external hub, then
plug in your device and FYSOS will recognize it. You can even plug in multiple downstream hubs.
However, please note that I have only tested this on a UHCI controller and low/full speed devices.
Also, even though FYSOS will recognize your device, that is all it will do so far. I haven't done
much else after the set up of the device. It will recognize some flash drives and mount them, but
it has been returning errors on most. It also will recognize a USB mouse and all the code is
written to use that mouse. However, there are no app's to use the mouse :-). Anyway, the USB
code is moving along well. Merry Christmas to all.

(21 Dec 2007) FYSOS should, and I use that loosely, should emulate most DOS commands. Therefore, you
should be able to run almost any 16-bit DOS app in FYSOS. However, I am sure that there will be many
items that I have forgotten and FYSOS will let you know. If you would, please send me the
report it displays about an invalid DOSemu function call, or what ever message you get. To try it out,
simply copy the DOS app to the fat12 image/floppy and boot FYSOS. At the prompt, run the DOS app.
(I suggest you try it in Bochs instead of real hardware since the DOS emulation has not been tested well)
If the DOS app is freely available, a simple email stating which app it is, where you got it, and
what errors it produced will be enough. Thank you.

(1 Oct 2006) I have updated my FYSFS specs to be more detailed and added a few items
to make it more usable.

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.

1.44meg floppy image (440k) for Bochs, VMWare, and/or real hardware (24 Dec 2007)
1.44meg floppy image (475k) for QEmu v0.9.1 (5 Feb 2008)
1.44meg floppy image (440k) for MS VPC (23 Dec 2007, 18:27)

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 the 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
Very little work has been done on this FS. I have been looking at
this FS and the ReiserFS and haven't decided which I like better.
- 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, IBM's OS2, and the
Apple Mac. 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
FYSOS has a working USB stack. The USB hardware layer should be
mostly complete, except for external hubs down the line.
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.
Update: 9 Dec 2007
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. 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 helpped 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.

You can get these files and their include files below along with the 1.44meg image file that has the complete
binary set of files including the kernel and a few extras.

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.