DOS code in CP/M? Revisited...

Liam Proven lproven at gmail.com
Sun Jul 17 10:09:21 CDT 2016


On 16 July 2016 at 13:12, Peter Corlett <abuse at cabal.org.uk> wrote:
>
> Isn't that mostly down to the difference between polled- and DMA-driven I/O?
> Not that IBM should be given any slack, given what a complete dog's breakfast
> ISA DMA is.
>
> Back in 1987, the Amiga had crap hard disk performance because while the
> controllers generally supported DMA, the disks still had to be formatted with
> that awful filesystem it inherited from Tripos. (This wasn't fixed until 1988.)
>
> I wonder how the Atari ST fared back then. Probably reasonably well given its
> filesystem is a FAT derivative.

If it's a real question, I still know some RISC OS gurus, so I can
probably find out. But RISC OS was, technically, very primitive. I am
not 100% sure it even did DMA.

I recall around '96 or so, when busmastering DMA hard disk drivers for
Windows NT 4 on the Intel 82430FX "Triton" PCI chipset and its PIIX
EIDE controller appeared.

They existed for Win9x too but didn't make as much difference, because
the 9x kernel didn't have the internal multithreading to take
advantage of it. NT did.

The thing is, in a fast PC, they weren't massively quicker in terms of
raw transfer speed. What they did was massively reduce the CPU load of
intensive disk activity. Obviously you could only see this in
Performance Monitor once the machine was booted, but it was
interesting. With the ordinary default MS EIDE drivers, NT used Polled
I/O. Under heavy disk load, such as loading a large modular app, the
kernel CPU usage in PerfMon went very spiky. If the CPU was reasonably
quick -- which around then meant a P1 at 166MHz, or maybe a Pentium 1
MMX at 200MHz, then it didn't max out the CPU, but it was working
hard.

With the DMA drivers, intensive disk activity barely caused a trickle
of CPU activity. You could hardly see it.

The difference was so dramatic, you could hear it from the changing
noise of the movement of the disk heads. With PIO, it was staccato,
clicky; with DMA, it became bursts of buzzing and occasional silences
as the OS digested the new data it received and then requested more.

Of course, if you had some expensive SCSI disk system, this wasn't
anything new -- but then, with a decent SCSI host adaptor, such as an
expensive Adaptec AHA2940, you never heard it in PIO mode, so the
contrast wasn't there. It was harder to compare some cheap terrible
SCSI adaptor with a good one -- nobody sane would put a fast hard disk
on a cheapo ISA-bus AHA1510 meant for driving a scanner.

Whereas with Triton drivers and a good fast EIDE HD -- the de-facto
choice then was a Quantum Fireball 1.2GB -- you could install the OS,
get it working, then take the floppy with the Triton drivers, install
it and reboot. Presto, the machine booted faster and became
significantly more responsive. Big difference.

This is the most dramatic demo of DMA-driven hard disk access that
I've ever personally encountered.

In 1987 or so, the early Archimedes like the A305 and A310 came with
ST-506 controllers and 20-40MB Conner drives. The expensive
workstation-class models -- Dick mentions having an A500, but that was
a series, not a model.

There was, later (1990), the A540:

http://chrisacorns.computinghistory.org.uk/Computers/A540.html

This was the Unix R260, but shipping with RISC OS instead of RISC iX.

The A540 came with a snazzy SCSI HD:

http://www.apdl.org.uk/riscworld/volumes/volume9/issue2/blast20/index.htm

... but then it was the thick end of three thousand quid.

Back in '87, I suspect Dick had an A310 or something, with an ST-506
drive & Arthur (i.e. RISC OS 1 -- an ARM port of the BBC Micro's MOS
with a desktop written in BBC BASIC).

So I suspect no DMA... but I don't know.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)


More information about the cctalk mailing list