VOGONS


First post, by retro games 100

User metadata
Rank l33t
Rank
l33t

It says on Wikipedia here that "32-bit disk access was introduced with Windows 3.1, and file access with Windows for Workgroups 3.11." Consequently, that must mean that MS-DOS never uses any kind of 32-bit disk or file access. Is that correct?

If the above is correct, then if I am using any IO controller (16-bit or 32-bit), and also I am not using Windows 3.x/wfwg (but only using MS-DOS), then is it true that I do not need to put *any* device driver for any IO controller in to any hardware configuration file, eg Config.sys?

It also says on that Wikipedia page that "Windows 95, Windows 98, and Windows Me use native, protected mode 32-bit disk drivers during normal operation". Native - what does that mean exactly? Does it mean that these 3 OSes do not need any "3rd party IO hardware" written device driver? That these OSes exclusively use their own Microsoft written "built-in IO programming code" to talk to *whatever* IO controller I am using?

Actually, that can't be correct, because when I install a chipset driver in Windows 9x, it usually adds a "mobo chipset specific" hard disk controller to the System resources area. That's for the integrated IO controller, of course. But I wonder if you can install a Windows 9x based device driver for an "add on" IO card? Perhaps the Microsoft written "built-in IO programming code" is always 32-bit, but it can be "overridden" and "enhanced" in some way by a "3rd party mobo chipset or IO card specific" driver?

Thanks a lot for any info! 😀

Reply 1 of 11, by megatron-uk

User metadata
Rank l33t
Rank
l33t

Back when Dos/WIndows 95/98 were still in vogue and Dos still had a big market share, most motherboard manufacturers supplied bus mastering IDE drivers for Dos. I imagine you could probably find generic Intel versions that would support the PIIX3 and PIIX4 devices on most Intel chipset motherboards.

You can certainly get DMA transfers going in Dos with the right drivers. I'm not sure what effect the BIOS settings (eg DMA or PIO modes) for block devices have in Dos - as far as I know I think Dos just uses programmed IO. For Dos-only use, you may want to try searching for 'Intel Triones busmaster drivers'... as I think they were the dominant drivers that were used back then.

My collection database and technical wiki:
https://www.target-earth.net

Reply 2 of 11, by retro games 100

User metadata
Rank l33t
Rank
l33t

Introduction
Thanks a lot for the info, megatron-uk. I am testing a GoldStar Prime 2c 9433 multi-IO ISA controller card. My test mobo is an Asus (486 based) PVI-486SP3 revision 1.8. I have an 80-pin IDE cable attached to the single IDE connector on this card. At the end of it, I have a compact flash drive. In fact, I've tested 3 CF drives: 128MB (DOS and Windows 3.11 wfwg), 512MB (Windows 95), and 2GB (Windows 98SE) which didn't boot. In the middle of the IDE cable, I have a DVD-ROM reader device, operating in slave mode.

I have also tested the floppy port, and the COM port. I attached some "random" COM port cable to it, and plugged a serial mouse on to it. It worked, so I'm happy about that.

The card
gs.jpg
reverse.jpg

Jumpers
Link to a webpage containing the manual and jumper settings. If you read the section titled "Specifications and jumper use on the Prime2c-based IDEPLUS4 card", you can click on the links for Page 1 and Page 2 to examine the card's settings.
man%252520jump.jpg

Mobo's BIOS
Using the mobo's IDE detection feature, it sees the Lexar 512MB compact flash drive attached to the GoldStar IO card, but Windows 95 won't boot if I choose the LBA option. I must choose the NORMAL option, and then Windows 95 boots OK. I also tried a 2GB CF drive, and the same thing happened. Also with a couple of 2GB CF drives, I selected NORMAL but Windows 95 and Windows 98 did not boot. All of these problems appear to be related to using compact flash drives. The reason is outlined after this BIOS screenshot, below.
bios.JPG

Mobo's BIOS again
This time, I didn't use any of the different CF drives, and tried a "real" 2.5inch 80GB IDE HDD instead. It had no jumpers, so I could not set it to "master" (and have my DVD-ROM drive set to "slave".) Luckily, after a couple of no POST boot attempts, the BIOS POST appeared on the LCD, and it worked. That's a useful tip, BTW. If you see no BIOS POST on the screen, simply switch off power and switch on power again. It's just possible that the mobo's BIOS gets confused by changes in hard drive hardware, and doesn't POST on the first attempt.

Anyway, it worked but look at the screenshot below - the mobo in conjunction with the IO card "sees" ~8GB of data. Does this mean that this crappy ISA IO controller is a "super IDE" IO controller? I have disabled the mobo's integrated IDE controller. I hope the mobo isn't getting confused, and is using the mobo's controller chip's "super IDE" specification to give me an incorrect reading. (I'm assuming that the PVI-486SP3 revision 1.8 mobo's onboard IO controller chip is super IDE.)

To double-check that this 2.5" 80GB HDD works, and correctly uses ~8GB of data, I will reformat it and install Windows98SE on it. I will then copy over a lot of data to the disk, in order to fill up the disk to at least >2GB. ATM, it's just got FAT16 / DOS 6 on it. I'll do that tomorrow...
bios2.jpg

Windows 3.11 (wfwg)
ATM, I have no device driver installed inside my Config.sys file. (Where would I find one anyway? Would one even exist?) The GoldStar ISA card must be 16-bit, because it's an ISA card. So why does Windows 3.11 (wfwg) work OK with disk access set to 32-bit? Could it be that this GoldStar card uses the same 32-bit IO chips found on their VLB cards for these ISA cards, and there's some kind of 32-bit to 16-bit onboard "conversion" that takes place? (Wacky guess.)

Actually, it's probably because before I installed this ISA IO controller, I was using a 32-bit VLB IO controller, and forgot to delete any configuration settings for it. Perhaps my Windows 3.11 wfwg installation will get flakey and fail, the more I use it, with this ISA IO controller set to use 32-bit disk access?
diskAcc.jpg

Windows 95
Shows the Microsoft Windows 95 "built in" disk drivers. One is for a compact flash drive, and the other is for the DVD-ROM reader device, which I have attached to the IDE cable as a slave mode device.
w95_disk.jpg

Reply 3 of 11, by megatron-uk

User metadata
Rank l33t
Rank
l33t

When IDE devices are talking about 32bit transfers, it doesn't refer to the width of the physical bus or controller chips that it is connected to, it refers to the number of words of data it transfers at once. It's quite possible to have 32bit transfers using a 16bit host interface (as long as the controller is happy to send and receive data to the drive at that width; not all do).

That ISA controller is unlikely to have DMA support, so I wouldn't think there were ever any drivers available.

My collection database and technical wiki:
https://www.target-earth.net

Reply 4 of 11, by elianda

User metadata
Rank l33t
Rank
l33t

Why don't you just use c't magazines ATBUS tool to check what your drive supports and in which mode it currently runs?

Disk Access in DOS does use the BIOS routines, so it depends on them. Also quite early BIOSes / HDDs support at least Multi Word DMA Mode. So there is no reason to assume that DOS uses always PIO (where did you got this info from anyway?!?).

I'am not sure what this 32 Bit Access from within Win 3.1 means. I guess it is just a protected mode replacement for the BIOS routines to prevent cpu mode switching when reading from disk. (This is done by default by all the DOS4GW extenders btw.)
So it probably has not much to do with 32 Bit access, like doing a STOSD to VGA RAM. There is also no reason at all that a 386 systems BIOS does not use 32 bit machine code aswell.

Anyway, I guess what you really want to know is, if your HDD is accessed using DMA or PIO. So just read it using the ATBUS tool. If it supports MW-DMA and is running in PIO Mode you might consider loading some DMA supporting driver. As the ISA ATA-Controllers are quite standard any driver will do fine. Maybe already some Int 13h BIOS extension driver for large HDDs supports DMA in its BIOS replacement routines. So you would resolve two common limitations at the same moment.

link: ftp://ftp.tu-ilmenau.de/Mirrors/heise/ct/ctsi/ctatb47.zip

Reply 5 of 11, by retro games 100

User metadata
Rank l33t
Rank
l33t

Thanks a lot for the info people.

elianda wrote:

Why don't you just use c't magazines ATBUS tool to check what your drive supports and in which mode it currently runs?

When I run this utility, it shows me this information.
PICT2630.JPG
Using this information, can I infer information about the controller? Because that is all that I am interested in. I am not interested in learning about what my HDD can do, or not do. I am only interested in what the controller is capable of doing, or not doing. Thanks.

elianda wrote:

Disk Access in DOS does use the BIOS routines, so it depends on them. Also quite early BIOSes / HDDs support at least Multi Word DMA Mode. So there is no reason to assume that DOS uses always PIO (where did you got this info from anyway?!?).

Unfortunately, you have misinterpreted one of my earlier sentences. When I talked about Windows 95 and "built-in IO programming code", I was not referring to "PIO". I was attempting to describe the general Input-Output computer programming code (eg written in the C language) inside the Windows 95 operating system.

elianda wrote:

Anyway, I guess what you really want to know is, if your HDD is accessed using DMA or PIO. So just read it using the ATBUS tool. If it supports MW-DMA and is running in PIO Mode you might consider loading some DMA supporting driver. As the ISA ATA-Controllers are quite standard any driver will do fine. Maybe already some Int 13h BIOS extension driver for large HDDs supports DMA in its BIOS replacement routines. So you would resolve two common limitations at the same moment.

Unfortunately, I'm not exactly sure what the ATBUS tool's output is telling me. Do you think I should look for a DMA driver? You say that a DMA driver would resolve two limitations. 1) it would allow the controller to "see" a larger HDD, but what is the second limitation? Speed? Thanks a lot.

BTW, I have just installed Windows 98 SE on to an 80GB HDD, using the controller seen in my o.p. I am now about to copy over several gigabytes of data to this HDD, so that it will fill up with data to well over 2GB. I am hoping that the controller will work OK, and that the controller will correctly "see" up to ~8GB of data on this HDD.

Reply 6 of 11, by elianda

User metadata
Rank l33t
Rank
l33t

rg100: Looks like you are messing different things up.

1. The controller does not limit the accessible size of the HDD. It is all about addressing the sectors on the HDD. The IDE Bus is a interface where you write directly in one of two microcontrollers/DSPs in the HDDs electronics. The controller limits then only the method how the sectordata is transferred.

According to the ATBUS screenshot the 80 GB HDD is capable of functions defined in the ATA standard version 9. It can transfer data by PIO upto Mode 4, Multi Word DMA upto Mode 2 and UDMA upto Mode 5. It shows that from this methods Multi Word DMA Mode 2 is active. This is most probably the fastest mode the Goldstar Prime 2 is capable of for transferring sector data.

2. There are three main methods to address sectors. By setting Cylinder Head Sector, Large Block Addressing with 28 Bit counter and LBA with 48 Bit counter.
CHS is old and typically limited to 1024 / 16 / 63 which results with a 512 byte sector size in the typical 504 MB barrier. As ATBUS shows you your BIOS already extended the Cylinder number bit representation to 16383 which gives you 8 GB max.
LBA28 just counts sectors directly which results in 2^28 * 512 byte roughly 128 GB. Your 80 GB HDD fits well within this limits.
LBA48 -> 2^48 calculate yourself.

Now: If you got an older BIOS that knows just CHA addressing then the barrier is at 504 MB. Thus there was a BIOS extension defined that allows to use more modern routines using LBA28 addressing. Those are using Int 13h and can be installed as a replacement of the old CHS routines. Like Ontrack Disk Manager f.e. With such an extension your BIOS can address 128 GB.
This has nothing to do with DMA transfer, just with addressing sectors.

This means that even with the oldest controller you can address your HDDs sectors using LBA48. Though there was no BIOS extension for LBA48 defined for DOS.

The PIIX3 drivers from Triones were programmed because the PIIX3 features PCI Bus Master DMA for transferring data which is somewhat faster than Multi Word DMA 2.

Maybe this helps a bit to clean everything up.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 7 of 11, by TheMAN

User metadata
Rank Oldbie
Rank
Oldbie

I can tell you that the 32-bit mumbo jumbo in win3.1x has nothing to do with DMA access.... my 386 had some crappy super I/O card that worked fine with both options enabled in 3.11... it was noticeably faster! it's obvious it has nothing to do with the bus as the card was just 16bit ISA... so it must be protected mode stuff and how the CPU handles the blocks of data... the card is so old that it predates even the ATA standard... back when 20-40mb HDDs were just known as IDE, so definitely NO DMA mode whatsoever!

if you have any i430 series boards, I have the latest triones drivers.... they are newer than anything you'll find out there... that's because my copy is legit! 😁 They work fine even in virtualized DOS systems, but some stuff may interfere with it and causes lockups on boot

Reply 8 of 11, by retro games 100

User metadata
Rank l33t
Rank
l33t

Thanks a lot for the info. BTW, I copied over ~4GB of data from a DVD-ROM to the 80GB HDD (which is "seen" as an ~8 GB drive) via the ISA controller, and it worked.

Reply 9 of 11, by TheMAN

User metadata
Rank Oldbie
Rank
Oldbie

I'm surprised that card supports ATAPI... maybe it's new enough?

Reply 10 of 11, by retro games 100

User metadata
Rank l33t
Rank
l33t

I'm surprised too.

Reply 11 of 11, by swaaye

User metadata
Rank l33t++
Rank
l33t++

I've read that busmastering IDE has little benefit in DOS because DOS is a single task OS. But sure you could get higher transfer rates which can be useful in some scenarios like disk to disk transfers. The CPU utilization savings would be less tangible though and also I can see potential for application conflicts... DOS games sometimes don't like drivers they don't know of.