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

26 August 2025 Well, it has been a while. Just wanted to say that the rewrite is progressing well. To the right is a screen shot.
Currently, I don't have a bootable image for you to download, but as it progresses futher, I will soon upload one so that you may try it out.

Watch for future updates.




*** Previous versions and screenshots past this point ****

(削除) 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.

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


AltStyle によって変換されたページ (->オリジナル) /