Search This Blog

Friday, 3 March 2017

Benchmarking of Different Floppy Disk Devices


Over at Vogons a little while back, someone asked if anyone had benchmarked different methods of reading and writing floppy disks to see which was best. I performed some tests and found out the following headlines:

- LS-120 drives are awesomely fast at reading floppy disks but terrible when it comes to writing.
- USB drives are around 20% slower at writing than native floppy drives, and only marginally better at reading.
- Mitsumi USB drives are crap.
- In most cases there is no difference between operations performed on a PII running Windows 98 with USB 1.2 and a Celeron D system running Win2K3 Server with USB 2.0. I did observe a 20% improvement in reading from USB devices, however.

So, onto the guts of the testing. It was suggested that the following devices should be included:

Came with all PCs until relatively recently, compared to Apple computers, which did away with them with the advent of the iMac. Iomega Zip discs became the industry-standard external storage medium for Apple hardware and many Power Mac models had an internal Zip drive.

USB Floppy Drive

For laptops, a USB floppy drive was a good alternative to integrating a drive and therefore saving space. It was also the only option for PCs and laptops that had no internal FDD option at all.

Gotek floppy disk emulator

A device that uses the same physical form factor as a floppy drive, but reads virtual floppy disc images from a USB stick and presents them to the computer as 'real' floppy discs.
LS-120 drive (aka SuperDisc)

The spiritual successor to the floppy drive, it used a 40-pin ATA connector rather than a floppy drive interface so it was faster and it fitted in the same slot. It was also more accurate, as lasers were used to guide the magnetic head. Although it used the same magnetic disk technology used in standard 1.44MB floppy disks, it could fit a higher density of data onto the surface. This meant it was also backwards compatible with standard discs and could also read date more accurately than a standard drive.


  • The stated margin for error is +/- 1KB/s.
  • Nearly all drives were tested using Win98 installed on a Pentium II @ 550MHz (Intel BX chipset). The second LS-120 drive was installed in another machine, using Win2K3 Server on a Celeron D @ 2.66GHz (Intel 945GC chipset).
  • Software used was WinImage 6.1.
  • Each test was performed using the same high density floppy disk in each case.
  • Imaging operations were performed with disk 1 from the Windows for Workgroups installer set, which is 1.40MB in size (1,474,560 bytes).
  • File transfer operations were performed using Windows Explorer with the contents of this image (19 files).
  • Operations were timed using a stopwatch and logged in seconds. I then divided the size of the disk by this to get KB/s.
  • I performed further tests with a Windows 8 system on a Core i5 @ 1.7GHz (Intel HM77 Express chipset) and WinImage 9.0 (64-bit) with USB 2.0. I found no variance from the 2K3 system results.
  • A final observation is something I've never observed before: native and USB floppy drives are cached so that if they are read or written to once, subsequent transactions are almost instantaneous. It's the first time I've come across this and I don't know if it's down to flash memory in the drive itself or an operating system feature. Ejecting a disk clears the cache.


As you can see here, USB drive B was the slowest of the bunch at reading a disk to an image file, barely achieving 20MB/s. This is 33% slower than a built-in drive and more than 50% slower than the fastest result, LS-120 drive B.

The shape of the graph is mostly consistent for transferring many files, but the USB drives have an advantage here. The slowest drive is around 50% faster in this test, and each of the other USB drives show improved transfer rates. The internal drives are all marginally slower.

A bit of a switcharound for writing an image file to a disk. Both the internal drives come out on top with identical transfer rates, about 50% slower than their read speeds. USB drive B still languishes in last place with barely over 10MB/s, while the performance of the LS-120s is comparable to the other USB drives.

The story is different again with transferring many files, with the LS-120 drives having a terrible showing. The internal drives perform almost identically to the previous tests, and the USB drives actually come out on top.

Bottom Line

  • If you're reading data from floppies use an LS-120, as it could be more than twice as quick as another device.
  • If you're writing data, use a standard drive as they are about 50% quicker.

Adventures With EISA: Part One - The Motherboard

Home Page


I've been collecting vintage computer gear for some time now but my most recent find is probably the most exciting one yet. And it didn't cost me a thing. Usually with items like this you hunt on the Internet and eBay for ages, eventually find something you're semi-happy with and pay money for it, only to come across a better, free version a week later. This happened to me recently when I decided to acquire an Amiga 500 again, after giving mine away about 10 years ago. This time it was pure luck.

For a while I've wanted to make a video series on the history of PC hardware, charting the development of hardware standards since the first PC, The IBM model 5150. The PC is approaching its 40th birthday and, at the rate the project is going, it will probably be finished when that date comes in 2021! What's amazing is how little things have really changed in that time, as there has been a common theme throughout it all: speed.

Compatibility, Compatibility, Compatibility

While most people associate the speed of a CPU as the defining mark of how fast a computer is, that's not the whole story. How the CPU interacts with the other components in the PC is just as important. This includes the cache, RAM, bus, I/O cards and storage devices among others. Although the development of PC hardware has been defined largely by compatibility, this is dependent mostly on the ability to run software. So long as the hardware was compatible with Intel's instruction set, PC makers could pretty much do what they wanted, while remembering that although some customers will pay a premium for the fastest system, most would prefer something that's future-proofed in some way or the ability to re-use existing RAM and expansion cards.

The Performance Revolution

This all went to pot in the late '80s and early '90s with the dawn of the PC GUI (aka Windows 3) and the realisation that the ISA bus was woefully inadequate for high-bandwidth applications. It was still only 16-bits wide and ran at 8.33MHz, matching IBM's 286-based PC AT. Although EISA and MCA were developed to take advantage of the 32-bit 386 and 486 CPUs, they still ran at around the same frequency as ISA. PCI and AGP eventually established themselves as the new standard in the mid-'90s but, before then, all the big manufacturers came up with their own 'local bus' that could run at the same speed as the CPU: Compaq's QVision (Mar '92), V-Com's 486 Local Bus (Mar '92), NEC's ImageVideo (Sep '91), Epson's Wingine (Feb '93), Swan's Direct Bus (May '92) and Opti's Local Bus (< Dec '92) among others.

Disparate Measures

The problem with proprietary buses is that you can't take a QVision card and put it in an Epson machine, so potentially expensive components become obsolete within a couple of years. In response to this, VESA (Video Electronics Standards Association) developed their own local bus standard, which was widely adopted by the industry and can be seen on many 486-era boards. For high-end workstations, which prioritise bandwidth over speed, VLB on an ISA system was still inadequate - . Running more than one high bandwidth card on VLB often caused compatibility issues. So what was the ideal solution in these pre-PCI times of choice and uncertainty? EISA + VLB. And that's exactly what I inherited this week when the technicians upstairs where I work were having a clear-out:

The Motherboard

This is the PET48PN board by TMC (revision 1.00). Considering it's over a quarter of a century old, this board is in amazingly good condition. No dust, no scratches, no damage. I do not have the manual for it, and cannot find a copy online. This is unsurprising given that manuals were not distributed digitally in 1993 so it would take someone to manually scan an existing physical copy and upload it for that to be possible. Thankfully, TH99 comes to the rescue, and has a full list of jumper settings, plus a schematic:

According to the specs, this motherboard has the following features:

Socket 2 supporting 486 CPUs up to DX2 + Overdrive
CPU speeds of 20MHz to 50MHz (plus clock-doubled models)

OPTI 82C682 chipset

7x EISA slots, 2x VLB connectors

Up to 128MB of RAM in 30-pin or 72-pin parity SIMMs

Up to 512KB of cache RAM


For those unfamiliar with old motherboards, you may have noticed that there are no ports at all aside from the keyboard. While modern motherboards tend to have everything built in, doing the same on early-1990s technology would have a) been massively expensive and b) been impossible to fit onto a standard motherboard size. Also consider that PCs were still predominantly business machines at the time, so there was zero need for decent graphics performance or sound. USB didn't even exist yet. So the following parts would be required in order to get this system up and running:

The Components


It only makes sense in a system like this to make it as high-end and kick-ass as possible. The fastest CPU this motherboard will support is probably AMD's 486DX2/80, which has an internal speed of 80MHz and runs on a 40-MHz bus. I don't think I own one of these. I do have a DX2/50 or 66 though, but what I'm most curious about is the DX/50. While this was a short-lived CPU (many PC makers had issues producing stable systems), it was at the centre of the fastest pre-clock-doubling PCs. While the DX2/66 was technically a faster CPU, it ran at 66MHz internally but the other components such as the cache, RAM and expansion cards, ran at 33MHz. With the DX/50, all these components run at 50Mhz (that's a 50% increase). Theoretically a DX/50 system should be faster than a DX2/66 system. Obviously CPU-centric benchmarks would show the latter to be faster, but real-world, fully rounded tests should show the DX/50 coming out on top.


Some kind soul clearly stripped this board of all of all useful parts. Fortunately I have a good stock of SRAM chips to go in this thing, and I can probably fit the total 512KB possible. Interestingly the tag chips have been left on the board, and they are 15ns. This is actually great because tag chips are generally quicker than the actual cache chips, and 20ns would be sufficient for a 50MHz system.


As illustrated, the board supports 30-pin SIMMs (to be installed in pairs, because they are 16-bit wide each and the CPU is 32-bit) or 72 pin SIMMs. This was usually a cost-saving measure, as RAM was damn pricey back then, and people obviously wanted to carry over what RAM they had already purchase. I've never tested out the difference in speed between the two types of RAM so it could be interesting to do a comparison. I love boards like this that include two different types of technology.

Graphics card

As there are 3 buses available here (ISA, EISA, VLB) there are technically 3 ways to approach this. But not really. With graphics, bandwidth is all important and the VLB slots provide the highest bandwidth. With a 50MHz CPU in the socket, that means 50MHz graphics, too. Although graphics cards were produced for the EISA bus, they were expensive and hard to find (and still are) and while they were 32-bit, they only ran at 8.33MHz. VLB really was the way to go with graphics and, on a 50MHz system, should theoretically outperform a similar PCI-based system, as that ran at only 33MHz. Still, this board presents a good opportunity to benchmark and compare just how big the performance difference is between ISA, EISA and VLB cards.

I/O card

As I'll be using Windows 3.11 on this system, I will need at least one serial port for the mouse, but I probably don't need the parallel port. ISA is fine for this as the bandwidth requirement is low.

At least one storage controller

I will need an interface card for the hard disk and floppy drive (CD-ROM not required). Choices for HDD are IDE (possibly EIDE) or SCSI and I could technically do either, but there is a choice to be made over which bus is used with which interface technology. So let's try to find the best solution on paper:

ISA: 16-bit, 16MB/s
EISA: 32-bit, 30MB/s
VLB: 32-bit, 190MB/s (@ 50MHz)

For SCSI I have both an ISA and an EISA card:

The Adaptec AHA-2742AT

The pictured model is the EISA SCSI card, is apparently SCSI-2 and supports 2 floppy drives with up to 10MB/s data transfer rate. That's not very fast. Theoretically the ISA bus is 16MB/s, so I don't know how much of an advantage EISA presents. Most of the benefit will come from the bus being able to push 32-bit transfers to the CPU.

For IDE I have caching controllers in both ISA and VLB so I will probably have to test out all configurations to find out which one is actually fastest. I'd be interested to see the performance difference between EISA + SCSI and VLB + IDE.


As you can see, there is no battery on this board. That is mostly an excellent thing because, typically, a board of this age would have had a rechargeable barrel-style battery on it, which have a habit of leaking corrosive fluid all over the board and destroying any traces it encounters. It's happened to me more than once. The empty socket above the BIOS chip accommodates a Dallas real-time clock, but not your run-of-the-mill DS1287, no. EISA boards have to save information regarding the expansion cards in memory, so this board came with a DS1387, a RAMified version containing 4K SRAM. While you can buy a DS12887A to replace a standard RTC, the EISA one is no longer manufactured in any form. I can apparently buy one relatively cheaply from China, but it may be more worthwhile to perform the popular coin cell battery mod:

I haven't tested the RTC or the board yet so I don't know if either works. That's the end of part one. The next chapter will be dealing with the build itself.