DOS ain't dead

Hello,

my Pentium MMX motherboard INT13h functions do not support disk sizes larger than 8.4GB, but the chipset does. Is there any open source solution to add large disk support that does not require me putting in another controller or burning an XT-IDE rom? At [1] is described that some people succeeded running XT-IDE from floppy. Would be great if XT-IDE could be loaded from the disk instead of a floppy. Out of curiosity, are there some other solutions?

Bernd

[1] https://forum.vcfed.org/index.php?threads/xt-ide-via-floppy-boot-instead-of-eprom.53245/

On a pentium you probably have bios stored i flashrom chip so you don't need extra eprom burning. It's possible to easy mod the bios with proper tool to add rom image with xtbios inside.

Also there was some solutions like Ontrack disk manager installed from a floppy but I don't remember what max. capacity it supported. I doubt it could do LBA48.

---
DOS gives me freedom to unlimited HW access.

For Large Disk support in the BIOS (INT 13h) refer to:

http://www.o3one.org/hwdocs/bios_doc/bios_specs_edd30.pdf

and RBIL (start with INT 13.41).

The extensions support up to 2^64 sectors. A sector can at least theoretically be up to 32k bytes (and maybe even 64k bytes, depending on the exact inmplementation), though in practice are probably limited 4k bytes.

> For Large Disk support in the BIOS (INT 13h) refer to:
>
> http://www.o3one.org/hwdocs/bios_doc/bios_specs_edd30.pdf
>
> and RBIL (start with INT 13.41).
>
> The extensions support up to 2^64 sectors. A sector can at least
> theoretically be up to 32k bytes (and maybe even 64k bytes, depending on
> the exact inmplementation), though in practice are probably limited 4k
> bytes.

Thanks for the reference. I am aware of this spec, but should have mentioned that my BIOS supports these functions. It sadly only makes available the first 8.4GB. The disk is also reported as 8.4GB disk by the BIOS. But other OS like OS/2 can for example access a 256GB disk without problems with appropriate drivers, so chipset support is given.

Looks like I have to replace the INT13 routines, so I will try to get XT-IDE running from floppy. This will reduce conventional memory by 8-12K. I am wondering if there are other side effects than stealing this memory from DOS, especially with things like EMM, protected mode etc...

> On a pentium you probably have bios stored i flashrom chip so you don't
> need extra eprom burning. It's possible to easy mod the bios with proper
> tool to add rom image with xtbios inside.

For me it does not sound THAT easy Not in the mood of bricking my system. So I will stick to less invasive solutions.

> my Pentium MMX motherboard INT13h functions do not support disk sizes
> larger than 8.4GB, but the chipset does. Is there any open source solution
> to add large disk support that does not require me putting in another
> controller or burning an XT-IDE rom?

I think you want an open source alternative to ontrack or ezdrive? You could start with XT-IDE and write a little loader to put it in RAM. The closed source tools mentioned are similar, they come with a MBR to load them in RAM, often allocated via manipulation of 40:13 memory size.

They typically even hide themselves by shifting the entire disk contents, so the initial part where the "driver" resides is only visible until the "driver" gets loaded. As there usually is plenty of space in the first track, I disliked that method. If you write some open source xt-ide loader, avoid such shift tricks if possible. You could even load it "metakern style" from a DOS boot sector and then chain load the normal DOS kernel after the "driver".

Note that most older IDE controllers are not smart, so they have no opinion about CHS versus LBA. Only the different PIO, DMA and UDMA styles available are likely to actually depend on your hardware.

---
FreeDOS / DOSEMU2 / ...

> I am aware of this spec, but should have mentioned that my BIOS supports these
> functions. It sadly only makes available the first 8.4GB. The disk is also
> reported as 8.4GB disk by the BIOS. But other OS like OS/2 can for example
> access a 256GB disk without problems with appropriate drivers, so chipset
> support is given.
>
> Looks like I have to replace the INT13 routines

I think you're confusing some things. INT 13h _is_ the BIOS. So, when you say you're BIOS does support the extended functions, that can't be correct.

I think your problem is that you are trying to access the extended functions for the upper parts of the disk with CHS addresses instead of LBA and that won't work. I suspect that you do not need to replace INT 13h but just have the programs correctly use the INT 13h that's already there.

P.S.: Is LBA enabled in your BIOS/CMOS settings?

> I think you're confusing some things. INT 13h _is_ the BIOS. So, when you
> say you're BIOS does support the extended functions, that can't be
> correct.

That for sure is correct. To be specific, EDD-2.1 is supported. I am using these functions right now with FDISK in LBA mode. Supporting ext INT13 (LBA access) and supporting disks larger than 8.4GB are two different things. I thought that the first would implicate the latter, but to my own surprise this not always seems to be the case. Therefore I want to substitute the INT 13 routines, and not the BIOS as a whole (which btw. is more than INT13).

>
> I think your problem is that you are trying to access the extended
> functions for the upper parts of the disk with CHS addresses instead of LBA
> and that won't work. I suspect that you do not need to replace INT 13h but
> just have the programs correctly use the INT 13h that's already there.
>

Well, the disks get only detected as 8.4GB in the BIOS setup screen, and there is no way for me to manually enter larger sizes. CHS access will NOT fail because of cylinder values >1023, because there is no exposed cylinder >1023.

> P.S.: Is LBA enabled in your BIOS/CMOS settings?

Yes.

> > my Pentium MMX motherboard INT13h functions do not support disk sizes
> > larger than 8.4GB, but the chipset does. Is there any open source
> solution
> > to add large disk support that does not require me putting in another
> > controller or burning an XT-IDE rom?
>
> I think you want an open source alternative to ontrack or ezdrive? You
> could start with XT-IDE and write a little loader to put it in RAM. The
> closed source tools mentioned are similar, they come with a MBR to load
> them in RAM, often allocated via manipulation of 40:13 memory size.
>
> They typically even hide themselves by shifting the entire disk contents,
> so the initial part where the "driver" resides is only visible until the
> "driver" gets loaded. As there usually is plenty of space in the first
> track, I disliked that method. If you write some open source xt-ide loader,
> avoid such shift tricks if possible. You could even load it "metakern
> style" from a DOS boot sector and then chain load the normal DOS kernel
> after the "driver".
>
> Note that most older IDE controllers are not smart, so they have no opinion
> about CHS versus LBA. Only the different PIO, DMA and UDMA styles
> available are likely to actually depend on your hardware.

Hi Eric,

as far as I know these disk utilities (they seem to be called dynamic drive overlay) increased the maximum disk size from 503 MB to 8.4GB. Probably one or another of them also supports larger disk sizes. Interesting that there does not seem to be an open source equivalent to these tools. Perhaps too exotic

I will try the "XT-IDE loaded from floppy" route, and perhaps the "XT-IDE -> original boot sector chainloading" in another step.

I am still not sure what the implications are of stealing a few KB from conventional memory by decreasing 0x13 of the BIOS data area.

Hi!

I think Ontrack and EzDrive did both: Implement a geometry transform to make the best use of MS DOS CHS limits to reach 8.4 GB with "more heads" and implement LBA. And even if they did not: If you wrote a loader for XT-IDE compiled with LBA enabled, it will help you to use LBA and far more than 8.4 GB on LBA-enabled DOS versions like FreeDOS

Eric

PS: Other things like BDA (BIOS data area) also steal a few KB from conventional memory, so I guess people are used to that.

---
FreeDOS / DOSEMU2 / ...

> I am still not sure what the implications are of stealing a few KB from
> conventional memory by decreasing 0x13 of the BIOS data area.

Beside having a few KB less conventional memory, there should be no side effects. The BIOS has stored data at 639K for ages.

> That for sure is correct. To be specific, EDD-2.1 is supported.

EDD back as far as version 1.1 (I have a copy of the spec) supports 64-bit LBA. If yours isn't doing that, it doesn't _really_ support EDD.

> I am using these functions right now with FDISK in LBA mode.

If you're using FDISK and EDD works, why do you say it doesn't work?

> ...

> Therefore I want to substitute the INT 13 routines, and not the BIOS as a
> whole (which btw. is more than INT13).

The BIOS is indeed more than INT 13h and is also more than disks. But INT 13h is the BIOS interface to the outside world for disk-related items.

If you end up writing your own, you'll need to do it at the hardware-specific level (PATA, SATA, etc.). While that's possible to do, it defeats the purpose of having a BIOS.

> ...

> Well, the disks get only detected as 8.4GB in the BIOS setup screen, and
> there is no way for me to manually enter larger sizes. CHS access will NOT
> fail because of cylinder values >1023, because there is no exposed cylinder
> 1023.

The "standard" setup for disks larger than 8.4 GB is to set CHS to the maximum 8.4 GB (CHS = 1024-256-63). That is supposed to work as a "flag" that tells the rest of the world (including the BIOS) that the disk is actually larger than 8.4 GB. Does that not work for you?

> EDD back as far as version 1.1 (I have a copy of the spec) supports 64-bit
> LBA. If yours isn't doing that, it doesn't _really_ support EDD.
>

This is NOT about LBA access. LBA access is working perfectly fine. And I did not claim otherwise. The problem is that the BIOS detects the disk as 8.4GB, and there is nothing I can do about it. Even INT13,48h returns the disk size as 8.4GB, while querying the ATA interface directly yields the correct sector count.

> If you end up writing your own, you'll need to do it at the
> hardware-specific level (PATA, SATA, etc.). While that's possible to do,
> it defeats the purpose of having a BIOS.

I will not write my own. I merely try to replace parts of it with XTIDE BIOS functions.

> The "standard" setup for disks larger than 8.4 GB is to set CHS to the
> maximum 8.4 GB (CHS = 1024-256-63). That is supposed to work as a "flag"
> that tells the rest of the world (including the BIOS) that the disk is
> actually larger than 8.4 GB. Does that not work for you?

No.

Bret, I thank you for your input, but I think we are talking past each other. So I suggest we stop discussing it at this point.

> Beside having a few KB less conventional memory, there should be no side
> effects. The BIOS has stored data at 639K for ages.

Thanks

> Beside having a few KB less conventional memory, there should be no side
> effects. The BIOS has stored data at 639K for ages.

Might be a bit pedantic, but it most likely will prevent the EMM from extending conventional memory up to 736 kB. It may succeed to move the XBDA to an UMB, but if there's additional code/data between "top of conv. emory" and the video ram, it has to give up.

---
MS-DOS forever!

The best guru of hard disk stuff is Lubomir Cabla, author of diagnostic program HDAT2.
You should, by the way, check his page at https://www.hdat2.com/ read the FAQ section and eventually run the program. (runs from DOS)
Or you can ask him directly.
Modern harddisks have severeal technologies how to arteficialy limit its size.

---
DOS-u-akbar!

> The best guru of hard disk stuff is Lubomir Cabla, author of diagnostic
> program HDAT2.
> You should, by the way, check his page at https://www.hdat2.com/ read the
> FAQ section and eventually run the program. (runs from DOS)
> Or you can ask him directly.
> Modern harddisks have severeal technologies how to arteficialy limit its
> size.

Thanks to all that provided some explanations and tips. I succeeded to load XT-IDE from floppy. On a machine with 640K conventional memory this loads to segment 9E00, and takes 8K conventional memory.

My Pentium system can now access the full capacity of the attached SSD under DOS, so I consider this done, unless someone is interested in a floppy image. In this case I would have to improve my quick and dirty, proof-of-concept like code...

> I will try the "XT-IDE loaded from floppy" route, and perhaps the "XT-IDE
> -> original boot sector chainloading" in another step.

Booting another boot loader is not terribly difficult, you can look a bit at MetaKern to learn how to do that. Basically you should load a file (up to 8 KiB) to linear address 7C00h, and transfer to it with CS:IP = 0:7C00h, DL = boot load unit, UP, and for a PBR you can pass DS:SI -> absolute partition table entry with LBA start sector (or pass an "empty" block of 16 zero bytes to tell the PBR that you do not give a partition table entry).

You can also implement replacements for specific DOS loaders in your application, like lDebug does. I documented some of these in the lDOS boot documentation.

> I am still not sure what the implications are of stealing a few KB from
> conventional memory by decreasing 0x13 of the BIOS data area.

This should generally not be a problem because any current kernels query the word [40h:13h] either directly or using interrupt 12h. The bootable lDebug mode does also steal memory for itself this way, and Enhanced DR-DOS and FreeDOS have no problem with this. (In lDebug I opted to also relocate the EBDA if it exists and is placed just atop the int 12h memory. You can find the size of the EBDA by reading the first byte of the EBDA segment, which gives a size in KiB.)

---
l