Reply 20 of 24, by flynth
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. […]
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.