The FYS OS: code named 'Konan'

Last update: 15 July 2017

Books My book series on creating a minimal operating system from the ground up is available here.

Recent News

15 July 2017 I have been able to do a little work on the GUI: Lastest GUI Screenshot

2 May 2017 I did some work on my Loader code and now using the SmallerC compiler, I can write 95% of the code in C, using unreal mode, using all available memory. Have a look at this page for some notes and this page for some screen shots.

04 Oct 2016 As promised, I now include a EFI GPT formated image of the latest code that will boot both Legacy and EFI on most emulators. Please be sure to read all of the included "readme.txt" file in the following .zip file (1.5Meg) before using any of the images. Thank you.

29 Sept 2016 I have been able to do a little work on this project and decided to add a few screen shots, of course including the ones from the GUI.
UEFI Boot
During bootup
After bootup
Desktop view with Menus
Desktop view with many Message Boxes
Desktop view with Transparent Titlebars
Misc Desktop view (3rd and 4th images in row at bottom left, animate)
'H' in the LucidaC Font
'A' in the Courier New Font

I have a working GTP partitioned image that boots both Legacy BIOS and UEFI BIOS in multiple emulators as well as on real hardware. Once I get a few more items wrapped up, I will include a link to that disk image here, as well as a 1.44meg floppy image.

9 July 2016 Wow! A year ago to the day. Anyway, I have released Vol 6, The Graphical User Interface, which has some screen shots of the GUI for this OS. I need to work on integrating the GUI core back into this code. I also have done some work with other parts of the kernel that now need integrating and commenting. So much work on other things (let alone my real job) that I haven't gotten back to this project in a while. A year to be exact :-)

9 July 2015 I did a bit of work with the USB stuff to support a much wider range of devices, reading and writing to, and mainly the USB floppy drive so that I could boot non-FDC machines. Before the OS takes over, the BIOS treats the USB floppy as a standard FDC floppy. However, once the OS takes over, it treats it as a standard CBI UFI USB floppy drive. You can read and write to it just fine. I haven't checked yet, but I think you can write the a.img to a thumb drive as a bootable drive and do that same there. I will have to check this to be sure.

2 July 2013 Not much work has been done on this project. I have made a few minor additions and changes. I have deleted the two "blog" and "news" pages that were here and now will write all news to this blog. I have updated and posted a specification for the eMBR partition scheme. Some time I might work on the BTRFS implementation.

21 Feb 2011 Now includes the xHCI driver. Should be able to access devices just as if they were connected to UHCI, OHCI, or EHCI controllers.

15 Jan 2010 Did a bit of work with the ATA(PI) code. Corrected a lot of hardware detection related items. Should now detect more drives and return correct geometery. If you would like to test your File System code and/or help me with mine, please visit here.

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...

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.

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




1.44M Floppy and EFI GPT formatted Hard Drive Image: fysos_efi.zip (1.5Meg)
Please be sure to read all of the included "readme.txt" file before using any of the images. Thank you.

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/lean/.
   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.  There is also an app to create and check image
   file lean volumes.
   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.  Though not complete yet, 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.
- Minix FS
   I have about half the work on this driver done.  I don't know if I will
   finish it yet.  It was just a "side track" I started a while back.  Don't
   know if I will get back to it.
- 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.
(If you would like to test your File System code and/or help me with mine, please visit here)

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 and with USB, the USB keyboard.
- Mice
   The serial and PS2 mice are supported.  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, EHCI, and xHCI)
   FYSOS has a working USB stack.  The USB hardware layer should be 
   mostly complete, with UHCI, OHCI, EHCI, and xHCI drivers.
   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 and write to a USB flash drive.
   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] fysnet [dot] net.
   Please see this page for more information.
- 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 FAT12 file system.

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 prefixed to the file for just this data. The loader code now supports compressed files. Originally, the kernel.sys file was 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 accessible 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 0x00800000 (8 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.

Boot the floppy on a 486+ 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] fysnet [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, LEAN, 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.