Blog: The FYS OS code named Konan

Blog: The FYS OS: code named 'Konan'

I thought I might try a Blog. I may keep it up to date, I may not. I guess
it depends on the feedback I get. Thanks.

For questions and comments, please send to: fys [at symbol] frontiernet [period] net.

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.

15 Dec 2006
I have had a little time to work with FYSOS again. I implemented the new version
of the LEAN specs, added multiple FS support for the bootup, and cleaned up a few
things while finding and fixing a few errors.

The bootup sequence now allows multiple FileSystems. All that is needed is an actual
boot sector written for this FS, and a small addition to the loader.sys file. I currently
have FAT12/16/32, LEAN, and FYSFS bootable images.

I am finally going to get back to the USB stuff and see if I can get my USB
to work and finish writing the documentation I have been wanting to for ever.

06 Oct 2006
Modified the EMBR stuff at 16 Apr 2006 blog below.

05 Oct 2006
Well, no interest was made from anyone to add their hardware to the list in the
last blog item. I guess I will delete the page.

I have done a lot to the boot and loader code to allow multiple file systems to
be used rather than just FAT12. Currently FAT12/16/32 and FYSFS are used. A few
others may be in the works soon.

I have also made a few more comments about the EMBR at 16 Apr 2006 blog below.

05 Aug 2006
How about a list of Operating Systems that individuals would like tested and in return
will test yours? How about a page that lists an individuals (or small group) OS to be
tested, with instructions, plus a small detailed description of the test machine(s) that
they have and are willing to test others' OS's on? I think this would be good. How about
http://www.frontiernet.net/~fys/os_testers.htm?.

21 July 2006
- I have been working with my USB code, the USB code for Bochs, and my USB tutorial. I will soon have
the Beagle USB Protocol Analyzer from Total Phase for my research, and will be able to continue with
my code and documentation. Please watch for my first installment of my USB code tutorial which will
include information on how to use and where to get a protocol analyzer such as the above mentioned analyzer.

02 July 2006
- As I was roaming around the other day, I found a filesystem called LEAN that was
going to be used in the FREEDOS32 operating system. It is a contrary to the FAT fs with a
play on words. Fat compared to lean. To have a look, go see here. I found it interesting
and am in communication with the author to add a few items. The author has been
very accommodating. I have been adding the LEAN fs to fysos and studying it a bit
while thinking of adding more to it, like a journaling system. This is a simple
but good FS and should be interesting to those who read it.

16 Apr 2006
- Last night as I was going through some old books, links, and notes, when I came
across a page that reminded me of something I wanted to try out, though the
info on that page was not quite what I have in mind, it still reminded me of
something I want to try.

The standard MBR holds four partition entries. Each partition entry can point
to a partition on that disk (in the forward direction). However, you can only
use 32-bits for starting sector and size in sectors. This leaves
a limit of 2^41 bytes of space on the size of a partition and because the starting
sector value is the same size in bits, without using extended partitions, you
can not have more than this on the whole media device.

This is actually a very large drive. To give an idea, a Terabyte is 2^40
and we are talking about 2^41 bytes. This was and still is lots and lots of space.
However, now that you can buy drives that are 300gig in size and larger, that
32-bit starting sector value is going to start getting too small.

Another thing about the standard partition entry is the ID byte, or System Identifier
byte. With only 8-bits in size, you can only have 256 different identifier values.
With all of the different filesystems, and variations of filesystems, most of the
values are used up.

Wouldn't it be nice to have a more detailed identification for each partition on the
drive? This would make it really nice for a "boot manager" to be able to display the
type and name of a specific partition, since the user could name the partition at
any given time.

So here are my thoughts. What if we had a single partition entry in the MBR that
had a System ID byte of a specified value that stated that this partition entry
pointed to an "Extended MBR". Then this EMBR could have multiple check sum and/or
signature values to verify that this is actually an EMBR. The EMBR could be at
any sector on the disk, granted taking the consideration of the 32-bit
limit talked about above.

However, if we had an EMBR, most likely this EMBR would cover the entire disk
and the MBR would only need the single MBR entry for compatibility issues. Typically
the EMBR could be at LBA 1, or the second sector of the media. This would also
allow compatibility for the CHS values in the MBR. (Who uses the CHS values anymore. :-)

Now, how much room should the EMBR take up? Is one 512 byte sector enough?
Let's see, if we have 64 bits of signature spread around somewhere, 64-bits of
sector counts and offsets, say 64 bytes of 8 bit Unicode, how many partition
entry's could we have in the 512 byte space?

// 120 bytes
struct S_EMBR_ENTRY {
bit64u starting_sector;
bit64u sector_count;
utf8 description[64];
bit8u reserved[16];
bit64u date_created;
bit64u date_last_booted;
bit64u OS_signature;
};

struct S_EMBR {
bit32u sig0;
bit16u entry_count;
bit16u crc;
bit8u resv1[20];
bit32u sig1;
struct S_EMBR_ENTRY entry[4];
};

This is a bit quick and dirty and could probably use a few more ideas, but with the
general idea, you could have 4 partition entries per sector and use up to
65536 sectors for a total of 262,144 partition entries.

The first sector of the EMBR has the entry_count field that states how many
entries there are. If there are more than four entries, multiple sectors
continuing with the next sector are used. For example, if the entry_count
field states that there are 10 entries, two more sectors after the initial EMBR
sector are used, while the last two entries in the last sector are empty.

Each field in the EMBR and consecutive sectors are used for that sector only,
with exception to the entry_count field. In the first sector, it is
used as the count. In consecutive sectors it is reserved and should be zero.

For example, the crc field in each sector is a 16-bit sum of all words
in that sector only. Therefore, when set correctly, if one was to take the
sum of all the 256 words in the sector (losing the carry after each addition)
the sum would be zero.

5 Oct 2006

Some additions: The standard traditional MBR at LBA 0 of the disk would point to
another sector that would have a boot menu code to parse and display the entries
in the EMBR described above. Then the EMBR entries would start just after this
code. This way, as long as the entry in the traditional MBR was marked as the
active partition, this EMBR menu code would be executed. Typically, the other
three remaining partition entries in the traditional MBR would be inactive and
zero'd.

Why have the traditional MBR in the first place, you ask? This is to keep
it compatible with other partition scanning software. If older/other
software doesn't see a traditional MBR in LBA 0 of a disk, it may think the
disk is unformatted and will prompt for a format.

So, where to place the EMBR code? Since most traditional format utilities have
the MBR at LBA zero, and most disks have 63 sectors per track (not physically now-
a-days, but as far as we are concerned), they traditional way is to place the first
partition at the first of the next cylinder. This leaves 62 sectors unused.
We could use these 62 sectors, but they way it is coded, any starting sector in the
traditional MBR partition entry will be fine. Personally, I will use LBA 1 as the
new residence of the EMBR code and entries.

The code that resides at this predefined area should have a general structure of
simply loading in the remaining sectors, a count could be in the first sector,
parsing the EMBR entries, displaying the found entries, then prompting for user
input to see which entry to boot. If user input is not found after a specified
amount of time, choose the last entry that was booted from.

There should be a table in this code at the first sector so that it gets loaded
by the MBR code, that contains a few items of interest. Things like, how many
more sectors to read, what entry was that last booted from, etc. This table
probably should be located at offset 446 (dec), the same place a traditional
MBR partition table would be with the Boot Id and System ID bytes of each entry
zero, so that any tradition MBR code will not try to parse this table.

I will code one and see how it works.

I have made a small page at fysos_embr.htm with my results. Hope this works.

Again, this is just something that I was thinking of a while back. I may implement
it in fysos, I may not.

If you have any questions or comments, please let me know at the address at the
top of this page.

Thanks,
Ben