The 430FX/PIIX was when it became standard. The earliest chip I can think of with any sort of DMA transfer mode is the dreaded CMD-640, but since it never worked right, it was usually stuck in PIO mode anyway. The Promise EIDE2300 VLB card came with a chip that could do MultiWord DMA 2 as well. Both came out in 1994.

In hindsight, it is surprising that Windows 95 Gold didn't come with a DMA capable IDE driver seeing that the hardware was on the market. The OSR2 driver didn't enable DMA by default either. I recall many new out of the box OEM machines with it disabled! The performance benefits of DMA mode were certainly there on Pentium systems with period hard drives.

Well, I guess what makes retail Windows 95 so flaky in hindsight, besides all the obvious bugs, is that it came out right before (and after, in the case of IDE DMA) a lot of new technologies were introduced. The checklist of stuff it doesn't support is huge, WinXP is nothing against this with just being limited to DX9. Unreliable Pentium Pro support isn't worth mentioning since nobody was buying such a system to run 95 on it, but MMX GP faults are serious seeing as it came out just a year later and was of great interest to consumers... it's quite weird to think that for this market original 95 was the best from MS you could buy in retail until 1998.

In the case of IDE DMA I would assume that even though the average PC user back then certainly had more technical understanding than nowadays, a good deal of people wouldn't have realized that they weren't using all the capabilities of their hardware... maybe thinking that the OS would take care of everything when it really didn't 😀

OSR 2 rightly didn't enable DMA IDE by default because the results were unpredictable at the time. Instability or even data corruption could occur. ATAPI drives were particularly iffy.

I think Win2k has it enabled by default though I may be wrong....

BTW the EIDE2300 card does not do DMA to the system. It only does DMA modes between the controller and the drive. It is described in the manual I believe. So you don't really get a DMA benefit.

d1stortion wrote:

Well, I guess what makes retail Windows 95 so flaky in hindsight, besides all the obvious bugs, is that it came out right before (and after, in the case of IDE DMA) a lot of new technologies were introduced. The checklist of stuff it doesn't support is huge, WinXP is nothing against this with just being limited to DX9. Unreliable Pentium Pro support isn't worth mentioning since nobody was buying such a system to run 95 on it, but MMX GP faults are serious seeing as it came out just a year later and was of great interest to consumers... it's quite weird to think that for this market original 95 was the best from MS you could buy in retail until 1998.

In the case of IDE DMA I would assume that even though the average PC user back then certainly had more technical understanding than nowadays, a good deal of people wouldn't have realized that they weren't using all the capabilities of their hardware... maybe thinking that the OS would take care of everything when it really didn't 😀

I run 95 on my IBM Pentium Pros. 🤣 Only because it kept consistent OSs across all my computers. They came bundled with NT with the original CDs and documentation. I still have those and the original boxes.

Back when 95 came out, it was an Intel world. Everything Intel, especially since PCI support was best on their motherboards. It was udring this time Intel really sold the board and the processor whereas the motherboard was usually made by someone else in the x86 days.

Actually, most people had a lot of technical knowledge. You had to know how to edit autoexec's and config's, and there was no plug and play that was reliable like today. 95 was marketed as an answer to all this technical necessity, but in reality it was a dog. You could run DOS/Win 3.1 at lightning speeds on the same system as 95. It was only after hardware became cheaper that people let go. Plus, you started to need 95 with 32-bit applications that didn't run under the win32 driver under wni31.

Today, most people that use computers have almost no clue what they are doing, and people that build systems have it much easier than back in the day. Even the most trivial thing, getting a hard drive to boot, was a lot tougher in the early days and required quite a bit of technical knowhow if something didn't work. It's why there's such an active forum here for old hardware. 🤣

As far as speed, DMA modes made drastic improvements on some drives, and almost nothing on others. The biggest difference I remember was that IDE used the CPU for data transfers, while SCSI didn't. So when someone's IDE-based system was pegged out and getting sluggish, my SCSI one just kept going since the CPU wasn't getting hammered.

It took a long time for this to finally become a non-issue. Even into some of the next generation of chipsets, you'd still see more CPU usage by IDE vs SCSI.

Samir wrote:

I run 95 on my IBM Pentium Pros. 🤣

OK, nowadays people on here are probably even running 95 on P4s with whatever hacks there are to it; I was really talking about back when these CPUs were the best you could buy and I'm pretty sure most used them mainly as NT workstations/servers, which is what they were intended for.

I've read reviews from that time which openly advised against buying a Pentium Pro for gaming, probably all because the early chipsets weren't all that great, the 16-bit issue and them not knowing anything about FASTVID. And after the Pentium II came out with MMX support and superior 16-bit performance the Pro was soon to be obsolete anyway.

Yeah SCSI is another good point. I've never used it myself but I'm sure it's a lot faster than IDE. Problem is that it's supposed to be expensive and loud so again obviously not something that was to be found in the common household PC.

I seem to recall DMA being disabled by default in Windows 2000...or perhaps it could autodetect and disabled it for the drives that didn't support it. I knew a lot of people with Windows 2000 that ran without DMA enabled, and the performance was crap.

According to Microsoft, with Windows 98 DMA is activated by default for HDDs, but not for CD-ROM drives... although on my 98SE machine it's also not activated for the "GENERIC IDE DISK" tab which is most likely the CF card. There is a "PCI Bus Master IDE Controller" tab however, so the OS does obviously detect the hardware as being capable of DMA.

d1stortion wrote:

OK, nowadays people on here are probably even running 95 on P4s with whatever hacks there are to it; I was really talking about […]
Show full quote

Samir wrote:

I run 95 on my IBM Pentium Pros. 🤣

OK, nowadays people on here are probably even running 95 on P4s with whatever hacks there are to it; I was really talking about back when these CPUs were the best you could buy and I'm pretty sure most used them mainly as NT workstations/servers, which is what they were intended for.

I've read reviews from that time which openly advised against buying a Pentium Pro for gaming, probably all because the early chipsets weren't all that great, the 16-bit issue and them not knowing anything about FASTVID. And after the Pentium II came out with MMX support and superior 16-bit performance the Pro was soon to be obsolete anyway.

Yeah SCSI is another good point. I've never used it myself but I'm sure it's a lot faster than IDE. Problem is that it's supposed to be expensive and loud so again obviously not something that was to be found in the common household PC.

Ah yes, back in the day NT was it for the Pentium Pros and DEC Alphas (remember those?). These were the entry level IBM workstations at the time, so they definitely weren't set up for 95. I'm glad they did support it though as NT didn't work with Lantastic, which I ran for all my DOS to W95 networking.

The main thing that was bad about a Pentium Pro was it's non-32-bit execution. It actually feels more like a Pentium vs a Pro in regular usage under 95. But any program/game that uses protected mode can go into 32-bit code, and I'm sure this happened more often once the Pentiums were more popular. And this is where the Pentium Pro might actually be a good gamer. The biggest thing that helped these was the on-die cache running at full speed. That's what really gave them their speed.

Back in the day, SCSI drives were about the same price except you had to buy a separate controller. Once you got over that hurdle, it was not much more, but the speed was. The SCSI-1 interface bandwidth was a full 5MB/sec, even on an 8-bit controller. Fast SCSI turned this up to 10MB/sec, and coupled with the disconnect/reconnect feature, the bus was utilized even less. 10MB/sec meant about 1-2MB/sec in realtime from one drive to another on our 486dx2-66, but that's pretty solid for a 16-bit bus that was limited to only 15MB/sec.

During the days of ATA, SCSI was definitely more expensive, up to 5x the price for a drive. But that was because almost all SCSI drives were 'enterprise grade' with 1 million+ MTBFs and low failure rates--crucial for business-class RAIDs and storage arrays, while ATA drives were aimed at the consumer and had much higher failure rates. SCSI were still faster too because they had the edge of not using the main CPU as much, although this benefit dwindled as the CPUs became so much faster. Once SATA came around, things changed once again. SCSI went serial as well with SAS (Serially Attached SCSI), which only has a slight difference in the pinout to all an SAS controller to also use SATA drives (I think, or it was the drives that could be used with either--can't remember). The SAS drives are still made to an 'enterprise' spec, but so are many higher end SATA drives (like the Western Digital RE series), so that gap has closed somewhat today.

d1stortion wrote:

According to Microsoft, with Windows 98 DMA is activated by default for HDDs, but not for CD-ROM drives... although on my 98SE machine it's also not activated for the "GENERIC IDE DISK" tab which is most likely the CF card. There is a "PCI Bus Master IDE Controller" tab however, so the OS does obviously detect the hardware as being capable of DMA.

I can't remember both of them exactly, but there's always two options under each drive that I set up in 95. One was to turn off write caching and the other was to turn on 32-bit disk access or something like that which probably equated to DMA.

Original retail 95 does not have DMA IDE support without 3rd party drivers btw. The other options on that page related to ATAPI / SCSI and there is also an option for auto-insert notification (autorun).

swaaye wrote:

Original 95 does not have DMA IDE support without 3rd party drivers btw.

Interesting. What about OSR2?

I guess I may not have noticed this because I always get the third party chipset drivers as the stock ones defeinitely leave a lot of speed on the table.

OSR2 and later do have DMA IDE.
http://support.microsoft.com/kb/258757

Ya with early versions of 95 you would get 3rd party drivers for DMA IDE.

Windows 2000 and XP had a nasty habit of only enabling DMA for the master device on each IDE channel by default. This wasn't a problem if you just had a hard drive and CD-ROM drive on each controller. When one added a slave device, it was pretty obvious going by the performance hit.

d1stortion wrote:

According to Microsoft, with Windows 98 DMA is activated by default for HDDs, but not for CD-ROM drives... although on my 98SE machine it's also not activated for the "GENERIC IDE DISK" tab which is most likely the CF card. There is a "PCI Bus Master IDE Controller" tab however, so the OS does obviously detect the hardware as being capable of DMA.

If your card says its UltraDMA compatible than your CF adapter may not be wired properly for UltraDMA usage. http://www.fccps.cz/download/adv/frr/cf.html

The card in question is a Transcend 133x. It supports UDMA. The adapter I'm using is advertised as being DMA capable as well, although just up to 33 MB/s, with the appropriate black IDE connector. I've seen some with blue IDE connectors as well so presumably they support higher speeds, although I wouldn't know what the difference here would be seeing as they are all passive anyway.

Device manager actually did offer an option for turning on DMA for the CF. I never had to manually force any fallback modes, it just looks like it was on PIO 4 from the beginning. With 16.7 MB/s maximal transfer rate it's capable of exactly what my card is supposed to offer in real life. I guess DMA would just cut down on CPU usage in this case.

NJRoadfan wrote:

This wasn't a problem if you just had a hard drive and CD-ROM drive on each controller. When one added a slave device, it was pretty obvious going by the performance hit.

One other thing that slows down the whole master/slave setup is that the transfers are basically controlled by the first (master) drive. So you can't have both drives on the bus at the same time anyways. This was really apparent when you tried to copy a CD from a slave to an HD on the master. It was definitely slower than a CD and HD both on master.

d1stortion wrote:

The card in question is a Transcend 133x. It supports UDMA. The adapter I'm using is advertised as being DMA capable as well, although just up to 33 MB/s, with the appropriate black IDE connector. I've seen some with blue IDE connectors as well so presumably they support higher speeds, although I wouldn't know what the difference here would be seeing as they are all passive anyway.

Device manager actually did offer an option for turning on DMA for the CF. I never had to manually force any fallback modes, it just looks like it was on PIO 4 from the beginning. With 16.7 MB/s maximal transfer rate it's capable of exactly what my card is supposed to offer in real life. I guess DMA would just cut down on CPU usage in this case.

You're probably right about the CPU usage, although at 16.7, you're running only PIO mode 4 vs DMA speeds. If the flash card itself can transfer more than 16.7, I'd look to see what setting is holding it back. Even if it is maxed out at 16.7, getting the bus to 33 will help reduce the cpu usage since it's not waiting on the bus.

There are IDE DMA modes below UDMA. 16.7 MB/s is called Multiword DMA Mode 2 (aka WDMA). Some CDROM drives continued to use this mode because there was little need for more bandwidth for a CDROM. This is also the top mode supported on PIIX and PIIX3 of 430FX/HX/VX and 440FX.

d1stortion wrote:

The card in question is a Transcend 133x. It supports UDMA. The adapter I'm using is advertised as being DMA capable as well, although just up to 33 MB/s, with the appropriate black IDE connector. I've seen some with blue IDE connectors as well so presumably they support higher speeds, although I wouldn't know what the difference here would be seeing as they are all passive anyway.

See this post for my own testing with a Transcend 133x with various IDE controllers and a CF-to-SCSI adapter. The card easily shows a speed boost running in UDMA modes vs. PIO mode (motherboard ports). Two posts down shows the card running at PIO0 on an ISA IDE card.

http://68kmla.org/forums/viewtopic.php?f=16&t … art=125#p217340

It also leads to another peeve of mine, the fact that motherboard BIOSes don't enable any DMA transfer modes by default when using onboard IDE ports. The Asus P5A has a 33MB/sec UDMA controller on board. The ROM on Promise cards enable the fastest transfer mode of the connected drives by default resulting in much better DOS performance without needing a device driver.

Samir wrote:

One other thing that slows down the whole master/slave setup is that the transfers are basically controlled by the first (master) drive. So you can't have both drives on the bus at the same time anyways. This was really apparent when you tried to copy a CD from a slave to an HD on the master. It was definitely slower than a CD and HD both on master.

This is a myth that has been around for years. The drive's on-board controllers operate independently of each other.

http://en.wikipedia.org/wiki/Integrated_Drive … e_clarification

I won't get into "why" here, but your computer never truly accesses multiple devices simultaneously. It just appears that way due to the speed it runs at. Pick up a good book on operating system theory (one that covers semaphores, task scheduling, and multi-threading) if you want to learn more.