IDE drives insist on using mode 0 instead of a faster mode. Performance issue not present w/ SCSI.
Closed this issue · 24 comments
What happened?
I have observed that when trying to set up a 386/486 class machine, for whatever reason almost every system chosen wants to use mode 0 no matter what, which results in a transfer speed of about 1500 KB/s. My physical hard drives can definitely do better than mode 0 even on older machines that offer up to mode 4 support in the BIOS. Some 86Box configurations I was able to try were able to do 3000 KB/s in mode 2, but I wasn't able to get a higher mode than that.
I thought perhaps it was related to dynamic vhd, nope, same issue with fixed size. Possibility it is a CHS issue since I entered in a size in MB instead of choosing one from the dropdown.. but here is the thing.. SCSI does not have this transfer issue! SCSI-2 has a max bandwidth afaik of 10000 KB/s and I can get about 8400 KB/s on the same image that is getting 1500 when in "IDE" mode.
So what this means is 86Box has functioning transfer speeds to spec if using SCSI.. so the issue as I understand it, isn't with the emulation of the system, but rather the IDE module specifically.
Changing the IDE speed to 5400/1997 doesn't make much difference compared to the fastest RAM option offered. I feel if RAM is an option, then the speed should be at least PIO mode 4 at a minimum.
You can do benchmarking of the disks using https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester
Good utility!
There is also a modded version at https://github.com/foone/DiskTest?tab=readme-ov-file where the .fil is deleted automatically afterward, but if you don't mind typing del *.fil then you can use the first link.
Configuration file
[General]
vid_renderer = qt_software
dpi_scale = 0
confirm_save = 0
force_43 = 1
video_filter_method = 0
hide_status_bar = 1
hide_tool_bar = 1
[Machine]
machine = 4saw2
cpu_family = i486dx2_pc330
cpu_speed = 66666666
cpu_multi = 2
cpu_use_dynarec = 1
fpu_softfloat = 0
time_sync = local
fpu_type = internal
mem_size = 16384
[Video]
gfxcard = et4000ax
[Input devices]
mouse_type = none
[Sound]
fm_driver = nuked
mpu401_standalone = 1
sndcard = sbprov2
midi_device = mt32
[Network]
net_01_link = 0
net_02_link = 0
net_03_link = 0
net_04_link = 0
[Storage controllers]
hdc = internal
cassette_mode = load
scsicard_1 = ncr53c810
[Hard disks]
hdd_01_parameters = 17, 8, 963, 0, scsi
hdd_01_fn = C:/Users/Peter/Documents/test2.vhd
hdd_01_speed = ramdisk
hdd_01_scsi_location = 0:00
[Floppy and CD-ROM drives]
fdd_01_type = 35_2hd
fdd_02_type = noneOperating system
Windows 10
CPU
Core 2 Duo
86Box version
v4.1.1 build 5634
Build architecture
Windows - x64 (64-bit)
Build type
- New recompiler
- Debug build
Download source
Official website (Jenkins, GitHub)
Additional context
No response
I set up a machine in Linux flatpak and with the ali chipset I was able to get lba on, 32 bit on, block 16sec, pio mode 4 but the transfer was only 2000 KB/s.
Your drive's CHS is such that it's below the minimum for LBA, and we default such drives to an earlier ATA standard which only supports PIO mode 0.
Also, on non-DMA-capable controllers, all drives are defaulted to said older standards. We really need to change this.
This is interesting and worth testing further.. what minimum size is required to allow above pio 0?
I just mounted a CDROM, and it also was mode 0 on the screen.. so this leads into the next question.. you said non-DMA-capable controllers.. right now it's "Internal Controller".. to get DMA, should one change that to a card and disable the chipset IDE in the CMOS?
Update: Tested, doesn't look like it. Stayed mode 0, so there is no difference whatever you're using so I left it at internal controller. SCSI cdrom CAN boot under certain circumstances, but only if the image is a specific format.. for the vast majority, it will not work because the cd drivers are for IDE and ATAPI is a must for cdroms, so ATAPI CDROMs would definitely benefit from LBA and DMA.
As I said, on non-DMA-capable controllers, all drives are defaulted to said older standards. I need to change this. I don't recall any ISA IDE DMA controllers existing, IDE DMA only really became a thing in the PCI era.
As for LBA - CD-ROM's and other ATAPI devices are by definition LBA, LBA only even, since ATAPI is basically SCSI over IDE, and that's LBA only.
And old machines aren't going to be able to boot from CD-ROM - El Torito support only came on later BIOS'es.
DMA
What about PIO modes higher than 0, though?
OBattler, for later 486 motherboards, they do offer DMA for the onboard chipset controller in the bios. These are also the boards with PCI and VLB slots.
To be clear with my understanding, is "Internal Controller" just a generic card like any other, or does it actually query the features of a chipset?
I have discovered that the Tekram SCSI DC-390, if you enable the bios checkbox, it will let you go in and mark a CD as bootable and it does work, so that's nice.. I have also finally found the aspi.sys driver for DOS. Really hard because tekram's ftp site is long gone and amd's amsida.sys file enumerates but freezes 86Box. This one works, attaching it here in case someone wants it. So this is a good workaround.. bootable scsi cd and dos aspi driver.
DC390_321.ZIP
No 486 chipset provides on-board IDE DMA. Which BIOS do you see with that option? Because the earliest chipsets that provided on-board IDE DMA, were Pentium chipsets.
And "Internal Controller" is on-board IDE, if present. "None" currently has the same meaning, confusingly enough.
Apologies.. it was a misunderstanding on my part.. I just assumed there was support due to boot screens like this one on the Ali M1489 chipset that implied the possible existence of DMA:
But weirdly.. there is a IDE driver for it that is supposed to enable DMA..
Turbo! Ok, let's see how it does with the MSI since the sys file sees the HD on this motherboard and the other AMI bios motherboard did not..
No change with the disk test results with the driver active.. but you have already explained that it isn't currently possible to go beyond PIO 0.
Reminder that that is a very late BIOS which itself does support DMA on appropriate chipsets, which ALi M148x certainly is not.
Most later 486 boards support DMA, just not UDMA, but it's not available via the BIOS but will work with DOS/Windows drivers. Basically any board that supports PIO 3-4 will also support DMA 1-2 since it's part of the same ATA standard. These boards usually just allow you to set the PIO mode in the BIOS.
(Ali 1489 for example absolutely supports DMA and you can enable it on real hardware with something like uide.sys).
ALi M148x absolutely does not support IDE DMA according to the datasheet - already at the very beginning, it explicitly only lists PIO modes as supported.
Basically any board that supports PIO 3-4 will also support DMA 1-2 since it's part of the same ATA standard.
No, the controller must have DMA functionality, either according to the SFF standard or a proprietary implementation. One such example is the UMC chipset DMA which is entirely proprietary and does not even support scatter/gather. And it is the only 486 chipset I know that supports IDE DMA.
Now, I do believe that ALi M148x boards exist that have a separate IDE controller chip that is DMA-capable. But that's not the ALi M148x built-in IDE, which is basically ALi M5213.
Ok - I'd seen people posting about Ali 486 chipset boards getting DMA working but didn't realise it wasn't in that chipset.
But if a chipset supports ATA-2 it will support DMA. My guess is that many of the 486 chipsets offer "IDE support" but haven't actually implemented ATA-2 and just kludged on PIO modes on top.
No, that's not how it works. For the ATA-2 PIO modes, all the chipset needs is the ability to make some accomodations for the timings. The interface itself remains identical to pre-ATA-2 PIO, ie. read/write on port 1F0h (or 170h for secondary IDE). For DMA, on the other hand, the chipset needs to implement either some kludgy way to use regular ISA DMA with IDE, or a proprietary interface (eg. UMC), or the later SFF standard (eg. Intel PIIX and later, and all ALi, VIA, SiS, etc. chipsets from later Pentium onwards).
I don't mean the controller magically supports DMA, rather that if they say they it supports ATA-2, it has to support all of that standard, which includes DMA. Otherwise it's just supporting IDE with extra functionality. I looked at the Ali datasheet and it doesn't claim to support ATA or ATA-2, just IDE (with PIO modes), which explains the lack of DMA support.
IDE is ATA (ATA, short for AT Attachment, is the formal name for the AT version of IDE, ie. for what is commonly referred to as just IDE), the only other IDE standard is XTA (XT Attachment) which, as its name implies, is for XT, and has a completely different interface. Early Super I/O chips did, in fact, support both ATA and XTA, usually with a jumper or strap to decide between the two.
For AT, pre-ATA, you get MFM/RLL and ESDI, which have largely the same interface as ATA/IDE, just that the controller is on the card instead of on the drive (all that original IDE/ATA did, was to move the controller to the drive, leaving the card (or the motherboard) only to handle the physical interfacer, the bus timings, and, later, DMA).
Now, the formal ATA standards apply to the drives, not to the part that is on the card (or the motherboard). This is the ATA-2 specification: https://www.karry.cz/files/ata2.pdf . It clearly says DMA support is optional (has a flag to indicate whether or not DMA is supported, and all DMA commands are listed as optional). So something that supports PIO-3 and PIO-4 but not DMA, is still adhering to the ATA-2 specification.
Well, IDE isn't strictly ATA. IDE existed long before the ATA standard (1986 I think), though the controllers and drives that were around in the 90s when ATA-1 was formalised had moved beyond the original IDE controllers. The original IDE controllers/drives used a different LBA method than ATA-1 ones for example (limiting them to 2GB maximum).
I didn't realise DMA was an optional part of the ATA standards though. I knew it was part of it and assumed it was required to support it.
The original IDE controllers/drives were CHS-only, which limited them to 503 MB maximum. That was the standard inherited from the WD AT interface originally used for MFM/RLL and ESDI controllers.
The 504MB limit comes from BIOS/DOS limitations, not IDE. The BIOS limits disk IO addressing to 1024/256/63 (i.e. 8GB) while the ATA interface used 65535/16/255 (137GB) or 28bit LBA for the same. For earlier IDE it was 1024/16/255 or 2GB limit. Combining the two gives 1024/16/63 (504MB).
From the wikipedia article on ATA:
The first drive interface used 22-bit addressing mode which resulted in a maximum drive capacity of two gigabytes. Later, the first formalized ATA specification used a 28-bit addressing mode through LBA28, allowing for the addressing of 228 (268435456) sectors (blocks) of 512 bytes each, resulting in a maximum capacity of 128 GiB (137 GB).
(I wasn't trying to say that early drives all used LBA addressing, just that this is one of the differences between earlier IDE and the first ATA standard)
OK, so 28-bit CHS was introduced in the 1990 revision: https://www.os2museum.com/files/docs/ata/ata-r21.pdf . Prior to the 1990 revision, when it was still called DAD (Disk ATBus Definition) instead of ATA, cylinders were limited to 10 bits, which meant a maximum of 1024 cylinders.
Here are all of them: http://www.os2museum.com/wp/historical-ata-standard-drafts/ .
Yes, when Western Digital introduced IDE it could at first use 10 bits for the cylinders (1024), 4 for the head (16) and 8 for the sectors (256 but only 255 usable). That seems to be carried over to DAD in 1989.
According to things I've read Western Digital's spec supported using those 22 bits for LBA addressing instead of CHS, but I don't know if this was used in practice since the PC BIOS (since the XT up until the late 90s) could only use CHS addressing. The DAD spec you linked mentions this is optional and drive dependent.
Actually, revision 2.1 from 1990 is the first ATA revision. The DAD revision from 1989 does not mention LBA at all.
It's not standardised until then. Before then it refers to logical sector addressing rather than using a geometry, which is translated by the drive (which is just LBA before it was a standard), though it's optional and implemented by the drive so could be done in any way.
Since this is technically not a bug, I'm converting this to a discussion.