"Sense Keys are messages generated by the storage target
These messages indicate that the server successfully submitted the IO to the target, but the target REJECTED our IO request with an error message."

you can try setting slower speed for the cf card
https://man7.org/linux/man-pages/man8/hdparm.8.html -d -p -X

Last time I had those types of I/O errors was because of the card reader going bad. Could also just be the cable, in case there is one, so if you could try another cable or card reader it should help check if this is the problem or not.

It's not exactly the same scenario, but I'm not having issues accessing DOS-formatted CF cards on my Raspberry Pi 4 (my main rig).
The Pi runs Raspbian/Raspberry Pi OS and has an USB card reader.
The CF cards are used in my various DOS systems and use FAT16, often with CHS.

Silly question: The 386SX handles a 16GB ide block device?

flynth wrote on 2022-11-11, 22:32:

I've been using this generic CF card to IDE drive adapter with a 16GB CF card (in a 386SX system with AMI bios 1.0). I found out CHS settings for the CF card in its datasheet.

Linux is still going to use the BIOS calls to boot
https://www.thegeekstuff.com/2011/02/linux-boot-process/

Very unlikely that a 386 bios from somewhere in the 1990-94 range is going to support >1024 Cylinders, >16 Heads, >63 Sectors/Track even if it lets you enter those values in the BIOS drive table.
https://www.vogonswiki.com/index.php/Storage# … age_Limitations

Maybe you can enter small values in the BIOS and Linux might be able to boot if the boot loader is in the CHS defined space and the boot loader is to smoothly transition to LBA when it takes over from the BIOS. Maybe. Seems like a long shot.

Perhaps dynamic drive overlay software is the way to go. I see that some people have been able to use it with linux. I recommend trying EZ drive, but you will need to reformat.
EZ-Drive Dynamic Drive Overlay

You can download it here:
https://www.vogonsdrivers.com/index.php?catid … menustate=59,57

Irq5 wrote on 2022-11-13, 11:52:

Silly question: The 386SX handles a 16GB ide block device?

I'm amazed myself but it indeed does. The partition is 2GB as per the fat16 limit, but the 1024 cylinder limit doesn't exist for this motherboard. It is this motherboard with a 386sx-25. Perhaps it is because 386sx came out later? Could someone with another 386sx confirm if this limit exists for them?

(the board link)
https://theretroweb.com/motherboards/s/ald-dat302-rev-b

I've found the pdf doc about the CF card and it specifies CHS of 33149,15, 63. I entered it in the user setting and it even reported the size correctly (15.9or so GB I don't remember the exact number, but it was slightly below 16gb).

Also I run DOS 6 (it might be 6.22).

I have another 386 board. This one is 386dx-40 by AMD. I fully expect it not to work so I already ordered smaller cf cards too.

douglar wrote on 2022-11-13, 13:23:

flynth wrote on 2022-11-11, 22:32:

I've been using this generic CF card to IDE drive adapter with a 16GB CF card (in a 386SX system with AMI bios 1.0). I found out CHS settings for the CF card in its datasheet.

Linux is still going to use the BIOS calls to boot
https://www.thegeekstuff.com/2011/02/linux-boot-process/

Probably I haven't made this clear before, but I run Linux on a modern pc. Then I insert the CF card into the USB reader. So there is no Linux boot involved.

Also (when card works) I sometimes dismount it and I run Qemu setting the card's device as C drive in raw mode. This allows me to boot qemu from that cf card under Linux. This is how I installed some software on it without having to wait a long time. However, although as far as I can tell all DOS software runs fine. Windows 3.11 hangs on the splash screen. I suspect it doesn't like my emulated ne2k_isa nic.

The issues before happened regardless if I used qemu, or not. It seemed to happen every 2-3 mount attempts.

douglar wrote on 2022-11-13, 13:23:

Unlikely, yes, but it works. If someone tells me "it's impossible" etc I might record a video to prove it. However, as it works […]
Show full quote

flynth wrote on 2022-11-11, 22:32:

Very unlikely that a 386 bios from somewhere in the 1990-94 range is going to support >1024 Cylinders, >16 Heads, >63 Sectors/Tr […]
Show full quote

Very unlikely that a 386 bios from somewhere in the 1990-94 range is going to support >1024 Cylinders, >16 Heads, >63 Sectors/Track even if it lets you enter those values in the BIOS drive table.
https://www.vogonswiki.com/index.php/Storage# … age_Limitations

Maybe you can enter small values in the BIOS and Linux might be able to boot if the boot loader is in the CHS defined space and the boot loader is to smoothly transition to LBA when it takes over from the BIOS. Maybe. Seems like a long shot.

Perhaps dynamic drive overlay software is the way to go. I see that some people have been able to use it with linux. I recommend trying EZ drive, but you will need to reformat.
EZ-Drive Dynamic Drive Overlay

You can download it here:
https://www.vogonsdrivers.com/index.php?catid … menustate=59,57

Unlikely, yes, but it works. If someone tells me "it's impossible" etc I might record a video to prove it. However, as it works for me (I wasn't even aware of the 1024 cyl limit) it can't be this rare. If it is I really want to know about it. I can make a Rom dump of the bios if it is anything special.

However, coming back to the issues with reading of the card in Linux(on a modern pc-via USB) I think I'm close to resolving it. I've recently started to not just click "eject" in the GUI, but every time I want to remove the card I now go to the terminal and I eject actual device by running "sudo eject /dev/sdh". The GUI eject function (gnome 43)seems to just dismount the volume, but it doesn't actually eject the media for me. Once I run this cli command the CF card reports size of zero and it will not work until removed and reinserted.

Since yesterday morning when I started doing that I had no issue. Previously I woukd have trouble every few "move to Linux, write files, dismount, put back in 386" cycles.

flynth wrote on 2022-11-11, 22:32:

It seems it happens mostly when I write a lot of data to it on linux.

Are you removing the card immediately after writing? Are you not running the sync command before dismounting/removing the card from the usb reader?

Hi! Please note, the BIOS and the CMOS Setup Utility aren't the same thing. ☝️🤓

The BIOS is the thing that does hold all the service routines, does initialize the hardware on power-up etc.

The Setup technically is a separate configuration program in ROM.
Just because it accepts and shows the correct drive geometry doesn't mean the BIOS does, as well.

Older machines like the PC, PC/XT and the AT didn't have a Setup Utility in ROM.
They either used DIP switcheds/jumpers or a configuration program on diskette.
Compaq PCs continued to do this for years..

EduBat wrote on 2022-11-13, 18:05:

flynth wrote on 2022-11-11, 22:32:

It seems it happens mostly when I write a lot of data to it on linux.

Are you removing the card immediately after writing? Are you not running the sync command before dismounting/removing the card from the usb reader?

As mentioned before when this was happening I would use the eject feature of the gnome file manager. Then I would wait about 10s and remove the drive. Also if I copied data prior I made sure to "give it time" to make sure it finished writing.

Still It would corrupt the drive every 2/3 uses. Until I started opening a terminal and running "sudo eject /dev/sdh" (where /dev/sdh is my cf card reader, if someone reading this has the same problem you need to find out your cf device name.)

Now that I started doing that it has been working perfectly with no problem. I've moved the CF card between the modern Linux pc and the 386sx over a dozen times and there is no problem. So my conclusion is. If one is using fat16 on Linux one has to use the cli eject command or it will corrupt the filesystem in a weird way.

Jo22 wrote on 2022-11-13, 18:20:

Hi! Please note, the BIOS and the CMOS Setup Utility aren't the same thing. ☝️🤓 […]
Show full quote

Hi! Please note, the BIOS and the CMOS Setup Utility aren't the same thing. ☝️🤓

The BIOS is the thing that does hold all the service routines, does initialize the hardware on power-up etc.

The Setup technically is a separate configuration program in ROM.
Just because it accepts and shows the correct drive geometry doesn't mean the BIOS does, as well.

Older machines like the PC, PC/XT and the AT didn't have a Setup Utility in ROM.
They either used DIP switcheds/jumpers or a configuration program on diskette.
Compaq PCs continued to do this for years..

Yes, of course. However, as mentioned before. I haven't just entered 33k cylinders in bios and decided "Wow, my BIOS is special". I have this computer running. It boots, it runs games. I successfully installed Windows 3.11 for workgroups which runs fine. I installed the Oki sound card software, I run terminal emulator (procomm) etc. All this using a 16gb cf card. The only software I couldn't install was Internet Explorer. I tried versions 3 to 5. The installer would just flash and quit. Everything else runs fine. Windows as well as DOS both report 2gb partition size correctly. I haven't written over 512mb of data to it yet so I don't know if doesn't brake then, but so far it works fine.

As the only floppy drive I have is in my 386sx pc and I have no physical floppies anyway I had to get creative about copying data from floppy images to my cf card and how to install DOS for the first time. If anyone is interested I'll describe those processes too.

So now I'm trying to establish if this is indeed something special I should preserve by dumping the bios's eprom. Or perhaps many 386sx motherboards behaved the same, but no one noticed?

You can't say all 16GB of the card is accessible if you haven't written beyond the first 512MB...

flynth wrote on 2022-11-14, 11:38:

Yes, of course. However, as mentioned before. I haven't just entered 33k cylinders in bios and decided "Wow, my BIOS is special". I have this computer running. It boots, it runs games. I successfully installed Windows 3.11 for workgroups which runs fine.

My apologies, I didn't mean to question your competence or something along these lines.
It's just hard to explain/diagnose things from the distance/over the internet.

It's just highly uncommon for a 386 era system.
Also, it predated ATA-2 specifications, which is a possible stumbling stone for compatibility (with new HDDs or CF cards).
386 PCs usually didn't even know about IDE, they just used the ancient WD1003 controller language from the mid-1980s.
Which is the same as used by MFM/RLL controller cards.
It's the IDE HDD who has to be able to emulate that WD1003 behavior, essentially.

That's how the classic HDD limit was caused:

Of course, these aren't set into stone. There are a few exceptions.
Problem is, that they're non-standard.
For example: Some older, 286/386 era BIOSes allowed for a higher cylinder count, for example (via int13h). Virtual PC 2004/2007 does, too.
That's why it was possible to make DOS 5 use about 3GB per partition.

Patch: Re: Browsing a harddisk under DOS without using BIOS routines (INT13H)

However, that BIOS "feature" was latter scrapped for the sake of stability/compatibility.
Newer BIOSes nolonger allow this via the normal int13h, they require the OS to use extended interrupt 13h instead.
So there's a real problem with interoperability.

And there are old DOS utilities that expect that there's a 1024 cylinder limit.
Either because they didn't know any better or for ancient things like diagnostic cylinders.

Anyway, what I meant to say, was, that those two (BIOS/Setup) are two components.
Which can lead to odd/strange combinations sometimes.:
AMI and Award had their modular BIOSes in which the BIOS and its GUI/TUI (the Setup utility) could be modified independently.

That causes situations in which the underlying BIOS has more features than what the GUI/TUI admits. And vice versa.

It's technically possible to combine a shiny new GUI/TUI from, say, 1994 -like AMI WinBIOS- with an old AMI BIOS binary from ~1989.
(Or, alternatively, use an entirely independent, external configuration program from DOS.)

That way, an old chipset can be attractively sold years later still without the need for investing hard work to update/rewrite the hardware-dependant BIOS itself.

Of course, that wasn't the only intention for the modular design.
It's also about feature sets and the OEM market.
A modern Setup Utility has an internal BIOS update facility, HDD auto-detection etc.
Compaq loved this idea so much that it had the Setup Utility stored on a hidden HDD partition.
The configuration program was based on DOS/Windows 3.1 files - and looked a bit like WinBIOS.
The only problem was if the user replaced the HDD without knowing this.
Then, it was needed to get the setup diskettes from Compaq.
They had the ability to run off floppy, but also to recreate the hidden partition.

Edit: The "best" solution maybe is to use XTIDE Universal BIOS on a network card.
In its later versions, at least, it's quite compatible with the LBA algorithm used in modern Windows PCs.

MS-DOS 6.22 itself (and prior) don't know about LBA or CHS.
They just use any drive geometry the BIOS does report via normal int13h.
However, past 1024 cylinders things may get weird.
That's why L-CHS (logical CHS aka "fake values"), E-CHS (Extended CHS aka "LARGE") were used after the original/real CHS was nolonger adequate (aka P-CHS, Physical CHS; MFM/RLL HDDs..).

Edit: Please read.
The 1024-Cylinder Limit Is Alive and Well
https://www.informit.com/articles/article.asp … 31238&seqNum=14

Workarounds for the MS-DOS 1024-Cylinder Limit
https://jeffpar.github.io/kbarchive/kb/073/Q73033/

This should help scope out BIOS capabilities.

Are there any utilities available to test BIOS disk access routines for reliable LBA28 functionality ?

Jo22 wrote on 2022-11-14, 12:41:

flynth wrote on 2022-11-14, 11:38:

Yes, of course. However, as mentioned before. I haven't just entered 33k cylinders in bios and decided "Wow, my BIOS is special". I have this computer running. It boots, it runs games. I successfully installed Windows 3.11 for workgroups which runs fine.

My apologies, I didn't mean to question your competence or something along these lines.
It's just hard to explain/diagnose things from the distance/over the internet.

No worries. I wasn't even thinking along those lines. More that perhaps what I wrote previously was missed (I did make a mistake with quotes in one of the prior posts, so some of it is hidden unless expanded). It is not easy to convey precise emotion over text 😀

Jo22 wrote on 2022-11-14, 12:41:

It's just highly uncommon for a 386 era system. Also, it predated ATA-2 specifications, which is a possible stumbling stone for […]
Show full quote

It's just highly uncommon for a 386 era system.
Also, it predated ATA-2 specifications, which is a possible stumbling stone for compatibility (with new HDDs or CF cards).
386 PCs usually didn't even know about IDE, they just used the ancient WD1003 controller language from the mid-1980s.
Which is the same as used by MFM/RLL controller cards.
It's the IDE HDD who has to be able to emulate that WD1003 behavior, essentially.

That's how the classic HDD limit was caused:

limits.gif

Of course, these aren't set into stone. There are a few exceptions.
Problem is, that they're non-standard.
For example: Some older, 286/386 era BIOSes allowed for a higher cylinder count, for example (via int13h). Virtual PC 2004/2007 does, too.
That's why it was possible to make DOS 5 use about 3GB per partition.

fat.gif
Patch: Re: Browsing a harddisk under DOS without using BIOS routines (INT13H)

However, that BIOS "feature" was latter scrapped for the sake of stability/compatibility.
Newer BIOSes nolonger allow this via the normal int13h, they require the OS to use extended interrupt 13h instead.
So there's a real problem with interoperability.

And there are old DOS utilities that expect that there's a 1024 cylinder limit.
Either because they didn't know any better or for ancient things like diagnostic cylinders.

Anyway, what I meant to say, was, that those two (BIOS/Setup) are two components.
Which can lead to odd/strange combinations sometimes.:
AMI and Award had their modular BIOSes in which the BIOS and its GUI/TUI (the Setup utility) could be modified independently.

That causes situations in which the underlying BIOS has more features than what the GUI/TUI admits. And vice versa.

It's technically possible to combine a shiny new GUI/TUI from, say, 1994 -like AMI WinBIOS- with an old AMI BIOS binary from ~1989.
(Or, alternatively, use an entirely independent, external configuration program from DOS.)

That way, an old chipset can be attractively sold years later still without the need for investing hard work to update/rewrite the hardware-dependant BIOS itself.

Of course, that wasn't the only intention for the modular design.
It's also about feature sets and the OEM market.
A modern Setup Utility has an internal BIOS update facility, HDD auto-detection etc.
Compaq loved this idea so much that it had the Setup Utility stored on a hidden HDD partition.
The configuration program was based on DOS/Windows 3.1 files - and looked a bit like WinBIOS.
The only problem was if the user replaced the HDD without knowing this.
Then, it was needed to get the setup diskettes from Compaq.
They had the ability to run off floppy, but also to recreate the hidden partition.

This is interesting. I'll do more checking about which versions of firmware components it has in EPROM. I never realised AMI bios can have one version number and the Setup utility another. I wonder if one can check both numbers easily or is eprom dump required. I do plan to wash this motherboard properly soon and as a part of this I'll be removing the eprom. I do have a reader so I could read the contents then.

That MS KB article is interesting. It doesn't even mention a possibility of this limit not being there in some firmwares. They just call it "AT ROM BIOS interface's maximum of 1024 cylinders" and that's it.

Also the other article. They talk about various ways to go around the limit, but BIOSes that "don't have a limit" are not mentioned.

So I'm starting to think it might be a bug. Perhaps the programmers used a 16bit number and just assumed bo one would use the upper 6 bits. I don't know what language would a typical bios be written in around ~1989 but if it was C it woukd be easy to just use an unsigned short rather than create own 10 bit type for the sake of saving 6 bits... Even in assembler, although I have no knowledge of x86 assembler, I suspect if one wrote code that handles numbers over 8 bits, it could be easier to use 16 bits rather than 10. Then someone forgot to implement checking for the limit in the Setup (or the setup came much later as you say) and we have my result. That's just a theory however.

flynth wrote on 2022-11-14, 13:32:

That MS KB article is interesting. It doesn't even mention a possibility of this limit not being there in some firmwares. They just call it "AT ROM BIOS interface's maximum of 1024 cylinders" and that's it.

Also the other article. They talk about various ways to go around the limit, but BIOSes that "don't have a limit" are not mentioned.

Because it's not possible for a BIOS to "not have a limit".
The INT13 calls used to read/write sectors use registers to pass parameters. 8 bits for the head (255 max), 10 bits for the cylinder (1023 max) and 6 bits for the sector (63 max). The cylinder and sector are stored together in the same register, there are no "spare" bits.
This is a hard limit, there may also be soft limits (due to the BIOS not supporting large/absolute addressing) that can be worked around with XTIDE/drive overlay software but the hard limit cannot be bypassed without changing the function specification, which would break compatibility with DOS (among other things).

jmarsh wrote on 2022-11-14, 14:42:

Because it's not possible for a BIOS to "not have a limit". The INT13 calls used to read/write sectors use registers to pass par […]
Show full quote

flynth wrote on 2022-11-14, 13:32:

That MS KB article is interesting. It doesn't even mention a possibility of this limit not being there in some firmwares. They just call it "AT ROM BIOS interface's maximum of 1024 cylinders" and that's it.

Also the other article. They talk about various ways to go around the limit, but BIOSes that "don't have a limit" are not mentioned.

Because it's not possible for a BIOS to "not have a limit".
The INT13 calls used to read/write sectors use registers to pass parameters. 8 bits for the head (255 max), 10 bits for the cylinder (1023 max) and 6 bits for the sector (63 max). The cylinder and sector are stored together in the same register, there are no "spare" bits.
This is a hard limit, there may also be soft limits (due to the BIOS not supporting large/absolute addressing) that can be worked around with XTIDE/drive overlay software but the hard limit cannot be bypassed without changing the function specification, which would break compatibility with DOS (among other things).

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

That's what I meant when I essentially confirmed flynth's experience.

Please have a quick look at the documents part of that MS-DOS 5 patch. They explain most it. 🙂

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 .

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.

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. 😅

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...)