Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9411

Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman)

Show all headers | View raw

"Mike Gonta" <mikegonta@gmail.com> wrote in message 
news:ne16rm$1aqu$1@gioia.aioe.org...
> The first draft of The AOD Virtual Partition Specification
> is out and at:
> https://groups.google.com/forum/#!topic/alt.os.development/xog2w8JqOmI
> as well as your favorite newsreader.
>
> 1. Is everyone happy with the specification?
> 2. Is everyone happy with making this an AOD community
>   project?
> 3. Does anyone else have something to say? Alex, Ben,
>   Bernhard, JJ, Steve, others? Now is the time to speak up.
>
> Everyone's comments have really been a big help (especially
> Robert).

To be honest, I don't have much to say about it.

As said before, the code it takes to allow for a (mostly) unlimited
sized FAT32 root directory and FAT32 FAT is irrelevant to me.

For example, once the kernel file(s) are found on this FAT32,
you have to read the FAT table and transverse through it to
read all sectors of that file(s).

If you know you already have to do that, why can't you just
integrate it into your FAT32 boot code and read the Root Directory
just like it was a file?

As for the size of the FAT, most of the time, say 99% of the time,
all needed files for booting are in the same place, relative to
each other.  Once you figure out where, you really only have
to read that part of the FAT table.

My FAT32 boot code is three 512-byte sectors, and as you know,
one of those sectors has absolutely no code in it.  Just the
first and the last of the three have code.  With those two
sectors, 1024 bytes, I can find all my kernel files no matter
where they are on the disk, as long as they are in the root
directory, size of the root directory being non-limiting.
The only limit I have in the code is that the FAT entries in
the FAT table are within the first 128 sectors.

  (128 * 512 = 65536 bytes)   64k.  16-bit addresses.

I just looked, my source says I still have 237 bytes free
in the third sector.  I could use those 237 bytes to allow
for unlimited FAT size by loading the next 128 sectors,
recursively, until I found the correct entries.  Then start
over for the next file.

On another note, my code even checks for and uses the
BIOS read extension service(s), so size of partition is only
limited to its capabilities.

Now please don't get me wrong, I am being honest here, I
don't see any reason to support this virtual FAT32.  Sorry.

This is just my opinion, and I am sorry if it sounds
destructive.  It is not intended to be.

I do appreciate your comments and posts.  It was you whom
posted to osdev.org about my work when I started writing my
books, and I thank you for that.

Ben

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Mike Gonta" <mikegonta@gmail.com> - 2016-04-05 16:22 -0400
  Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-04-05 19:21 -0700
    Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Mike Gonta" <mikegonta@gmail.com> - 2016-04-10 18:22 -0400
      Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-04-10 17:42 -0700
        Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Mike Gonta" <mikegonta@gmail.com> - 2016-04-11 04:55 -0400
    Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Mike Gonta" <mikegonta@gmail.com> - 2016-04-11 05:15 -0400
      Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-04-11 13:15 -0700
        Re: Silence is golden but The AOD Virtual Partition waits for no man (or woman) "Mike Gonta" <mikegonta@gmail.com> - 2016-04-11 18:21 -0400

csiph-web