The FYS OS: code named 'Konan'


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

Recent News

Latest Binary: fysos.zip (8.34Meg) (7 Dec 2021) (previous version)

18 April 2022 After looking over FYSOS on a whole, I have come to the conclusion that my code is due for a complete re-write:
10 May 2021 Just adding a screenshot. Not much has been done. A few fixes here and there. I had hoped to be able to return to this project with more frequency, but haven't found the time lately.

8 Dec 2020 Ported the 64-bit code back to 32-bit so that the 32-bit kernel now boots. The 64-bit kernel and the 32-bit kernel should do exactly the same thing, as far as the user is concerned.

28 Nov 2020 Updated the code to allow sector sizes larger than 512 bytes. LeanFS and the FAT file systems now support 512-, 1024-, 2048-, and 4096-byte sectors. Now supports the NVMe Solid State Disk Controller. Fixed a few other minor bugs and enhancements.

13 Oct 2020 Fixed a few bugs here and there--one nice one in the ACPI code--and added support for NVMe Solid State Storage Controllers.

Please Note: My IOAPIC code must be slightly off. If you have VirtualBox with a setting of ICH9 *and* IOAPIC, you won't get an interrupt for some devices. You can by-pass this by using the system setting of PIIX3 and IOAPIC where you should now see interrupts on these devices.

6 July 2020 Fixed a bug in the loader file. A (BIOS handled) hardware interrupt could happen after we get the old handler address and before we store the new handler address in our saved handle. Rare, but could happen. Also, the handlers assume FS to be zero. Somewhere in my code, I destroy FS after setting it to zero and before the handler gets called. The more I look into it, the more I think the BIOS on this particular machine sets and uses FS without preserving it. I will do a bit more research. Maybe a do-nothing loop allowing the BIOS interrupt handler(s) to be called, checking for the preservation of FS. We shall see. [Update: (I believe) it was a conflict with the System Management of the (simulated) realmode. Everytime I modified FS, it would throw a SMI (System Management Interrupt) and slow the machine considerably. I removed the dependancy for FS and all is good.]

2 May 2020 Currently will detect a network and send the required DHCP sequence to obtain an IP address. More work needs to be done on the network stack.

6 Mar 2020 Fixed a bug in the EHCI Interrupt/Periodic initialization, fixed/enhanced the 'sprintf()' library function, and a few other fixes and enhancements.

17 Feb 2020 Fixed a bug in the PNG decompression code.

16 Feb 2020 Fixed a few bugs here an there and added the code to monitor a laptop battery, as well as a few enhancements throughout.

7 Feb 2020 I fixed the bug in the ACPI code. The 32-bit kernel had a small bug with the length of the header, while both the 32-bit version and 64-bit version were allocating 32k of ram for every ACPI Package. With all the packages within the ACPI data, this was allocating more memory than I had available for the ACPI. Hence the Page Fault crash. :-) The kernel should now boot as legacy or UEFI firwmare, with both 32-bit or 64-bit kernels, on either a machine type of i440fx or q35. (The .zip file now contains the latest versions of the UEFI firmware)

6 Feb 2020 I re-wrote the way the EHCI handles interrupts, which now makes my OS support the USB Attached SCSI protocol for high-speed devices (this protocol was already supported for super-speed devices). I also modified a few other things and the kernel now runs much faster on QEMU with the '-machine q35' parameter, emulating a more modern machine. However, for some reason, when booting EFI with the '-machine q35' parameter, my 64-bit kernel crashes. I don't know if it is due to the old EFI firmware version I am using or my actual code. I will have to have a look at this. [update: I believe it may be a bad ACPI module in the EFI firmware I am using. It has a recursive Package (within a Package) that never ends...I will have to investiage this to see if it is my code or the firmware's ACPI module]

28 Jan 2020 Lots of work has been done. I now have a working 64-bit kernel. Included in the fysos.zip file is a single fysos.img file that will allow a boot in 32-bit AND 64-bit as well as Legacy AND UEFI, both 32-bit and 64-bit. All in one image file. Included is a readme.txt file showing how to boot using QEMU, Bochs, and Virtual Box. The Legacy loader file is built to load either the 32-bit or the 64-bit kernel depending on the machine it found. Please note the 64-bit kernel is still in a test phase and may or may not work as expected.

19 Mar 2019 Updated the EHCI code to fix a small bug. Thank you MrLolthe1st for finding this.

08 Mar 2019 I have done some updates and improvements to hardware detection and drivers as well as some of the GUI, with minimal GUI, but mostly functional hardware detection. It now includes hd.img which is a LeanFS hard drive image ready for a thumb drive install.

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.

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)
Re-write of the LIST object now allows groups (14 Sept 2018)
'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.

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.zip
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 80486 with RDTSC and CPUID instructions or an Intel 64-bit compatible machine, 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 
     https://www.fysnet.net/leanfs/index.php.
   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.
- SFS
   This is a small and simple file system described here.

FYSOS supports the following hardware with progress as specified: 
- ACPI
   I have a mostly complete ACPI/AML interpreter and parser.  I can extract
   necassary data as well as other information, such as battery status.
- APIC
   The APIC is supported and used by default, falling back to the Legacy PIC 
   as needed.
- ATA/AHCI/SATA/NVMe/BusLogic
   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.
   Supports a few of the most modern storage controllers.
- APM
   There is not much support for APM since I will include APCI.
- Audio
   A minimal AC97 audio driver is supported.  It will (mostly) play
   most .wav, .voc, .au, etc., type files.  No recording yet though.
   A little Sound Blaster code is 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.
   The 64-bit version is now my main line of work.  I don't keep the 32-bit
   version up to date as much any more.
- 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 (ISA) 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.
- HPET
   The High Precision Event Timer is supported and used by default, falling
   back to the PIT when necassary.
- 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.
   Support for the PCNet and E1000 NICs is mostly complete.
   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.  PCIe is also supported.
- PIC
   The old style PIC is supported.
- PIT
   This Programmable Interval Timer is fully supported.
- Serial
   FYSOS detects the UART serial bus and sets up the hardware and
   software for communications.  However, that is about it.
- UEFI
   FYSOS boots either Legacy BIOS or the new UEFI and has loader files
   for both.
- 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.
   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.
   Supported devices:
   - Thumb drives, hard drives (MSDs)
   - HIDs (mouse, keyboard, tablet)
   - Video (EHCI mostly, very little on the others)
   - External HUBs
   - USB to Serial Port
   - USB printer
- Video
   Other than the 16-bit real mode (or V86 more) BIOS VESA interface,
   not much is supported.  It does handle "large" resolutions as long
   as the VESA BIOS shows it.
   
I might have missed something, so if you have a question on a certain
type of hardware, let me know.

Known issues: 
- Command line prompt:
   My path parser has a few issues.  It doesn't parse the correct path.
- Background image in Command Prompt Window:
   If image is larger than screen, image "bleeds" to top/right. 
- GUI
   Mouse handler needs work.  Double clicks are not handled correctly.
- Others
   I am sure there are many others.

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 have made the code search the directory tree to find the loader.sys file in specified folders.

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 supports compressed files. Currently the kernel.sys file is more than 1500k, but now with bz2 compression, the kernel.sys file is around 550k 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 (or long mode), sets up the segment descriptors and jumps to the kernel.

The kernel.sys file is loaded 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.

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