Hi Arkady,
> BC> I would like to see if possible support in the kernel to see
> BC> partitions that are bigger than the BIOS allows.
> Wrong way. DOS is portable accross many different disks types only
> because it uses BIOS to access them.
> BC> In my case, I have a
> BC> 386 and its kernel only allows for hard drives up to 201 MB...
I think there CAN be a situation where such support would make sense!
Sometimes the BIOS just lets you pick from a fixed list of geometries
or does not support LBA48 (i.e. has a limit of 128 GB / 134 GB).
In such cases, we could introduce a SYS CONFIG option that would tell
the kernel that it can "safely" ignore the "number of cylinders" or
"total sector" counts for drives OTHER than C: - the user would, by
using this option, "promise" to load a variant of the UDMA2 driver
before accessing data beyond the first 128 GB.
The UDMA2 driver supports LBA48 in a direct hardware access way, but
you would need a variant because it does not transparently handle
DMA boundary crossing and therefore occasionally lets the BIOS do
disk accesses instead of doing them itself. The variant of UDMA2
would allocate an extra low memory buffer and make sure to do all
disk accesses itself without relying on the BIOS.
The other aspect of the SYS CONFIG option would be to ignore a
number-of-cylinders limit below 1024: I think such a limit can be
safely ignored right away without any further drivers, for the
described "BIOS 201 MB limit" to push the limit to 504 MB, yet again
putting responsibility to ONLY enable the option on own risk!
The limit of 504 MB would remain, because NO extra drivers are loaded
and the BIOS "number-of-heads" and "number-of-sectors-per-track"
values are still in use.
Again, such an option would allow users to use more of their disk,
at cost of a small kernel modification, at limited risk, and with
the default kernel (before you change the config with SYS CONFIG)
still behaving in the current safe way.
The problem is to find somebody who can improve UDMA2 as described :-(.
Eric
PS: One UNSAFE aspect of the kernel is that bldbpb() returns the
default BPB ("if you format the disk, use those fat / cluster sizes...")
if the 55 aa magic of the boot sector is missing (i.e. for unformatted
disks), which protects you from a few "division by zero" and similar
errors but is inherently insafe by pretending that the unformatted disk
would be "partially formatted". But that was an off-topic comment X-).
PPS: Our DEBUG kernel recently had the wrong format string when showing
the max-cylinder (clipped to 1023) of a disk. Not sure if it got fixed.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
