darry wrote on 2022-11-14, 18:09:

Assuming that the BIOS version matches https://theretroweb.com/motherboards/s/ald-da … rev-b#downloads (31-0100-009999-00101111-121291-TD70- with a core version of 121291 ), this can provide some insight into theoretical BIOS capabilities in regards to disk size : https://bios.miraheze.org/wiki/AMIBIOS# ... 91_-_1994) .

See also Are there any utilities available to test BIOS disk access routines for reliable LBA28 functionality ? , which I previously mentioned which references a DOS utility written by Jan Steunebrink (aka Chkcpu) http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm that can be run to test what standards the BIOS conforms to in terms of INT13h functionality .

I'll use the tool later this week (weekend at worst). Unfortunately I don't have that much time for playing with my old hardware during the week as I would like to 😀

Jo22 wrote on 2022-11-15, 02:51:

Maybe, but DOS 5 and its FDISK aren't aware of the extended int13h - merely of the traditional BIOS calls.. That's my point. […]
Show full quote

jmarsh wrote on 2022-11-15, 01:28:

Jo22 wrote on 2022-11-14, 15:57:

Correction: 12 bits - in some situations, at least.. 😉

Incorrect. We are talking about the BIOS calls only - the registers are 16 bits wide, not 12, making the hard limit 10+6. Which is exactly what I said.

Maybe, but DOS 5 and its FDISK aren't aware of the extended int13h - merely of the traditional BIOS calls.. That's my point.

"[..] Futhermore, many BIOS manufacturers have added support for INT 13 access to drives with more than 1024 cylinders.
The original INT 13 specification uses a 10-bit cylinder number for a maximum value of
1023 (hex 3FF). [..]"

The technical details are described in the text files supplied in that zip archive.

Please everyone take your time and read it.
The author explicitly wanted the mechanism to be understood, so he did write everything carefully.

The patch works on real hardware, depending on the BIOS, as well with the BIOS used in Virtual PC 2004/2007.
I've used the latter to take the screenshot. ^^

Personally, I believe that's a possible explanation why flynth was able to configure
more than 1024 cylinders without trouble (no boot failure, no data corruption etc).
Even though his unpatched copy of MS-DOS itself perhaps didn't use cylinders past 1023/1024 yet (flynth used a small partition).

Edit: Maybe we can use PCem/86Box to analyze the behavior. It has many 286/386 machines in its list.

Edit: Text edited.

Edit: I hope my wording was fine now.
These days, it's really hard to be diplomatic without losing integrity. 😅

I'll read that text too. One important thing to mention is that I am using a 2GB partition (dos reports correct size), but it wasn't created and formatted in the 386sx pc. Also I don't think I have written more that 64mb to the partition. When I run scandisk on the partition I only waited long enough for the surface scan to go through the part with data on it.

So it is possible DOS may have never actually try to read/write beyond the 1024 cylinder boundary.

As I didn't have any floppy disks I created a 2gb partition in dosbox on the modern Linux pc during ms-dos installation. Then I imaged it to the CF card. Then once I could boot the 386sx all subsequent software was installed running on 386sx by copying contents of multiple floppy images into a single c:\install folder then running it from dos. This is how win3.11 was installed and so on.

I don't remember if I used dosbox or qemu to install ms-dos 6, but I do remember the disk wouldn't boot (in qemu and in the 386sx pc) after ms_dos 6 was installed until I copied the boot sector from another booting dos drive image and I wrote it to the first sector of this drive. I used linux's dd tool (it can read/write raw data of specified size to disk's and files). From then on it works fine.

So here we are. I'll post more info using the tools provided later in the week.

I suspect that the 386sx doesn't write to the expected geometry once it goes past 1024 cylinders. Have you run fsck on the volume lately?

When I want to reliably use devices with capacity > 528MB on both a legacy system with BIOS older than June 1994 and on contemporary systems, I need to either:

• Get an option rom like XTide Universal Bios or SIIG Enhanced BIOS that can patch INT13 pre-boot
  -- or ---
• Install dynamic drive overlay like EZ Drive which supports standard partition types that can patch INT13 during the early part of the boot process

I had one funky C&T 386sx board that wouldn't reliably boot if any storage larger than > 528MB was attached to the IDE controller, unless I used an IDE controller with a SIIG Enhance BIOS option rom, regardless of whether I used the factory system ROM or MR BIOS.

https://theretroweb.com/motherboards/s/jc-inf … -ii-model-2050b

jmarsh wrote on 2022-11-15, 03:56:

Jo22 wrote on 2022-11-15, 02:51:

Maybe, but DOS 5 and its FDISK aren't aware of the extended int13h - merely of the traditional BIOS calls.. That's my point. […]
Show full quote

Maybe, but DOS 5 and its FDISK aren't aware of the extended int13h - merely of the traditional BIOS calls.. That's my point.

"[..] Futhermore, many BIOS manufacturers have added support for INT 13 access to drives with more than 1024 cylinders.
The original INT 13 specification uses a 10-bit cylinder number for a maximum value of
1023 (hex 3FF). [..]"

The technical details are described in the text files supplied in that zip archive.

I'm not talking about the extended functions, I'm talking about functions 2 (read) and 3 (write). They use an 8-bit register for the heads parameter and a 16-bit register for the cylinder and sector. If you trade bits from one value for the other (like the patch you linked), you don't increase the overall addressable capacity nor do you achieve anything that drive overlay software couldn't already do - you only end up breaking software that relied on the old behaviour and the hard limit remains 8GB.

(An extra fact: MSDOS5 only supports FAT16 with a limit of 32KB clusters / 2GB total size, so it would not recognize a 3GB FAT16 partition correctly...)

Pardon ? Why are you so upset ? 🤷‍♂️
It seems to me you're talking in defense about things I never even questioned.

I merely dared to say that it's possible that the cylinder count can be 12-Bits in certain situations.

I didn't talk about the total numbers of bits, I didn't talk about maximum capacity, overlay software etc.

I just essentially said that flynths 386 BIOS might not cap the cylinder count at 1024.
That it might be showing a non-standard behavior thus.

Which is exactly was both my own experience with Virtual PC, as well as the document in the patch from 1991 confirms.
Some BIOS variants act that way, some don't. It didn't work in Qemu/Vbox for example, if memory serves.

Edit: Personally, I'm a bit sad how things ended up.
I just could have quoted the whole document here without further comment,
but decided against it for face-saving reasons.

I have finally found the time to mess with this system and the results are not very enlightening.

I did run the utility that checks ios int13 support and all it said was this:

Then here are some more photos:

Interestingly fdisk is the only utility that seems to say this is a ~500mb disk, but still happily shows a 2gb partition.

So here it is. I'll post another photo of the BIOS version in the next post.

Here is another photo of the motherboard

And the BIOS version