PDA

View Full Version : 286 Disk Controllers - How Fast, is Fast Enough?



pearce_jj
May 8th, 2012, 12:14 PM
Just looking for opinions - how fast does a disk controller need to be, for it to be useful in a 286?

SpidersWeb
May 8th, 2012, 12:33 PM
Well ST4038 is rated 625KB/s which was a 5170 option, so that'd be realistic but I'd more expect > 1MB/s with modern attachements. Can't perfectly remember what my 286 does, but I think it was around 1300KB/s using a 200Mb IDE drive.

Chuck(G)
May 8th, 2012, 01:43 PM
Compared to what? A decent early 286 controller could keep up with an interleave of 2:1 on a 3600 RPM drive (17 sectors/track), so that's 17x256*60 bytes every second or about 260KB/sec. Later controllers had more local buffering and could read 1:1.

You might find an old copy of CORETEST and look at the sample values presented there.

Unknown_K
May 8th, 2012, 03:15 PM
On a 286 using ISA BUS anything close to 1MB/Sec would be plenty.

Fredbug
May 8th, 2012, 03:54 PM
Define fast enough. I remember using a 286 with a boot floppy and $25 network software to use
a network drive over a serial port. It was fast enough for the task at hand.

Chuck(G)
May 8th, 2012, 04:51 PM
On a 286 using ISA BUS anything close to 1MB/Sec would be plenty.

Sustained? An ST-506 interface (MFM) drive can't transfer that fast.

marcoguy
May 8th, 2012, 04:55 PM
Sustained? An ST-506 interface (MFM) drive can't transfer that fast.
What about SCSI, or with 16 bit ISA, IDE? They can get to be pretty fast. MFM isn't the only option for an AT PC.

RBARDY
May 8th, 2012, 04:57 PM
286 computer went from 6mz to 26mz chips obvious faster machine could take the faster drives 286 were at the time formfm and rll drives controllers went from 3to1 interleave to 1to1 interleave to find what a specific does use coretest

twolazy
May 8th, 2012, 04:58 PM
I'll chime in and say provided its over 500kbs read and write, seek time would be more important then transfer rates... it's why the older SCSI setups tend to be faster then their ide counterparts, and a big reason why I suggest CF/Microdrives nowadays for vintage systems. :thumbsup:

Unknown_K
May 8th, 2012, 07:13 PM
I was thinking IDE or SCSI controller, we are talking a 286 with 16BIT ISA slot correct? My generic 286 systems tend to have SCSI cards because I like connecting old storage devices to them. One of my native brand name 286 systems might have MFM or RLL but I don't recall benchmarking it, the rest are IBM PS/2 systems with SCSI.

pearce_jj
May 9th, 2012, 02:25 AM
Thanks for the replies. I asked because I'm looked at ways to generate enough demand for my 8-bit compact flash board to get to a short run, and perhaps a single-slot CF / microdrive board could be useful in a 286 too if it were fast enough.

Google 'how fast is an 8-bit ISA slot' and there are many answers, but it seems they *should* run at effectively 4.77MHz(ish) by way of wait-states being added when the CPU clock is higher, giving 1.3M transfers-per-second. On AT hardware, we have /NOWS signal though which can be used to reduce the number of wait states to basically double throughput to 2.6M transfers per second, with 8-bits per transfer this being 2.5MB/s.

So here are the numbers my 8-bit XT-CF board achieves in an Amstrad PC2286 (12.5MHz) with a microdrive:

Standard - 750KB/s read, 850KB/s write
With NOWS asserted - 1,400KB/s read, 1,700KB/s write

Drive write cache was enabled for this test which was performed by simply grounding B8 for the test (a 32MB transfer through the file system), so on a finished board with NOWS being correctly asserted results might be a bit lower. Pattern tests ran OK.

The Tandy 1000 286's seem prime targets for this, but sadly according to the tech references they implement pure XT slots without the NOWS signal.

Chuck(G)
May 9th, 2012, 09:14 AM
Have you tried the controller in slot 8 of an XT wit the XTIDE asserting NOWS (the pin B08 has a different function on slot 8 of an XT, but the outcome may be similar)?

Those numbers are far in excess of anything even a 16-bit SCSI controller could do for sustained transfers from a single drive in the 5170 era. So you should be fine (basically, you can't move data any faster than the disk spins).

pearce_jj
May 9th, 2012, 10:44 AM
Hi Chuck, thanks for the suggestion. I did try the card in J8 but it didn't work. Reviewing this old thread (http://www.vintage-computer.com/vcforum/showthread.php?24037-IBM-XT-8th-Slot-Video-Card) it's pretty apparent why; as it needs to generate the card select signal - which, it seems, would happen to be interchangeable with the /NOWS signal I'm looking at for ATs, if I'm understanding things correctly?

So by including a switchable output on that line from the address decoders (in the logic) the board should work in slot 8 on the XT as well as running faster in an AT? Unfortunately I need to order new prototype boards to test any of this properly, as I grounded the unused CPLD pins in the current board and I think they're too small to cut into (by me, anyway).

Mad-Mike
May 9th, 2012, 11:04 AM
I have a 12 MHz GEM 286 (Georgia "local" brand), and it's got plenty of speed in the hard disk department, I'm just running a standard I/O card similar to those used in 386/486 era machines, and a 540MB Seagate EIDE drive with a disk overlay on it. 32-bit code aside, it feels a lot like using a 386 SX based machine at the same clock speed.

I've had several 286, seems to me most of them came with MFM/RLL technology under the hood, my Deskpro 286 that I had did, as well as th 2-3 IBM PS/2 units I had (a Model 50Z and 2 Model 30 286). I have run SCSI on the GEM once in awhile to install O/S, Drivers, and Networking on the Tandy 1000 before I had some 360K diskettes made up for it, feels about the same speed-wise to the EIDE setup it usually runs.

Chuck(G)
May 9th, 2012, 11:44 AM
Hi Chuck, thanks for the suggestion. I did try the card in J8 but it didn't work. Reviewing this old thread (http://www.vintage-computer.com/vcforum/showthread.php?24037-IBM-XT-8th-Slot-Video-Card) it's pretty apparent why; as it needs to generate the card select signal - which, it seems, would happen to be interchangeable with the /NOWS signal I'm looking at for ATs, if I'm understanding things correctlly

So by including a switchable output on that line from the address decoders (in the logic) the board should work in slot 8 on the XT as well as running faster in an AT? Unfortunately I need to order new prototype boards to test any of this properly, as I grounded the unused CPLD pins in the current board and I think they're too small to cut into (by me, anyway).

I believe so. Fortunately it'd be easy to test with a patch or two, no?

pearce_jj
May 9th, 2012, 11:59 AM
I suppose I could use one of the DIP switch lines, will apply the matter some thought :)

pearce_jj
May 9th, 2012, 12:52 PM
Potential problem with this - as we can't distinguish IO access from memory access until it's too late (i.e. when /IO[R|W] arrive) it would spuriously generate card select for passing memory accesses. Shouldn't be a problem for /NOWS generation as we only need to bother for ROM and memory-mapped transfer anyway.

pearce_jj
May 10th, 2012, 01:57 PM
I decided to have a crack at this and have some success using the various chip select lines (i.e. address decoding) and the IOW/IOR or MEMR/MEMW as required inside the CPLD to generate B8 signal.

In the Amstrad 286 at 12MHz it runs 1460KB/s write & 1160KB/s read. This is slower than before as the /NOWS line is being properly controlled rather than just set permanently - so the system was properly stable - and I guess by just shorting it for the initial test, it may have been running at 0 WS before, and 1 WS now (which is per spec).

Next for the XT. The slot-8 card-select signal seems to be needed only for read operations, and when asserted in writes it doesn't work. There is a note in the tech-ref about the line "setting direction" so I guess that figures. That being the case, generating the signal only for reads the card now works in PC/XT slot 8 :) Actually in this state it works in any slot.

Thanks Chuck!

NB no performance change in the XT unfortunately.