Forthcoming XT-IDE Board - Cast Your Vote

[pearce_jj]

Yep - here. Don't look too closely at it though

 

[Trixter]

Yep - here. Don't look too closely at it though

Code is fine, I just wanted to alter it so it didn't write directly to the screen so I could save the output to a file, which I did. I can send you the code and/or diffs if you like (it operates exactly the same way, including the in-place spinner). I also removed the need for a mathco, you don't need IEEE single precision for screen updates.

My results are included for both an AT&T 6300 (8MHz 8086, MFM controller, 42MB Miniscribe MFM drive) and an IBM PC (4.77MHz 8088 + Silicon Valley ADP50 connected to both IDE and CF):

AT&T 6300:

Configuration: 4096 KB test file, 256 IOs in random tests.


Write Speed         : 88.47 KB/s
Read Speed          : 93.30 KB/s
8K random, 70% read : 5.4 IOPS
Sector random read  : 8.8 IOPS


Average access time (includes latency and file system overhead), is 113 ms

IBM+IDE:

Configuration: 4096 KB test file, 256 IOs in random tests.


Write Speed         : 157.00 KB/s
Read Speed          : 272.34 KB/s
8K random, 70% read : 3.5 IOPS
Sector random read  : 4.1 IOPS


Average access time (includes latency and file system overhead), is 246 ms.

IBM+CF:

Configuration: 4096 KB test file, 256 IOs in random tests.


Write Speed         : 155.68 KB/s
Read Speed          : 281.32 KB/s
8K random, 70% read : 9.5 IOPS
Sector random read  : 11.8 IOPS


Average access time (includes latency and file system overhead), is 85 ms.

 

[pearce_jj]

Trixter, many thanks! Interesting that your numbers with the ADP50 don't show the impressive speed as in the Tandy 1000 before. I wonder if the Tandy might have a V20 perhaps?

Anyway, thanks for the code mods - would very much like to include your updates. Re co-pro, the idea originally was to get the fdiv for free by running it in parallel with an IO, but I doubt that ever worked Please do send or post your code.

 

[Great Hierophant]

My Tandy 1000SX has a pure Intel or AMD 8088-2. I do not own a V-20.

I tried the benchmark again and got the same results except for the write speed, which was 233.79KB/s. Write speeds tend to be very variable on CF media. I made sure the Tandy was set to 4.77MHz, not 7.16MHz.

I would suggest that the only explanation is that I am using a faster card or CF. More likely to be the latter, unless later BIOS revisions to the former gave a boost in speed.

 

[pearce_jj]

Thanks for checking that. As you say, BIOS revisions may well give different performance.

 

[Trixter]

And it may not have helped that my BUFFERS=99 buffers were running in an UMB provided by my LIM EMS board. Let me reconfigure to be "stock" and see what the results are on the IDE drive:

Write Speed         : 161.39 KB/s
Read Speed          : 282.48 KB/s
8K random, 70% read : 3.8 IOPS
Sector random read  : 4.3 IOPS

Average access time (includes latency and file system overhead), is 234 ms.

Or, maybe not.

 

[eeguru]

Memory mapped JR-IDE/ISA in a 5150 stock 8088 @ 4.77 MHz - :

w/ a Seagate 7200 RPM Barracuda 80 GB drive.

Write Speed         : 430.14 KB/s
Read Speed          : 421.07 KB/s
8K random, 70% read : 20.1 IOPS
Sector random read  : 49.7 IOPS

I haven't been able to test the DP board as both the BusBlaster and BusPirate I bought were DOA on arrival. I managed to get the Pirate working through bare firmware load. Still working on the Blaster. I had a similar problem with an OLS I bought a few months back - needed a firmware load. I'll poke at it some more this week.

The memory mapped CPLD project in general seems to have a fatal flaw - one that seems to be killing the ISA version completely. It isn't anywhere near as compatible as other similar boards with respect to different hard drive types. And I just can't figure out why. I've put a logic analyzer all over it and everything seems great. I'm starting to suspect that the read latch strobe - which can be asserted as quickly as 1.5 clocks from RD assertion, might be too fast for a lot of devices. I'm not giving up, but I'm extremely frustrated.

 

[pearce_jj]

wow!! What is read-latch-strobe?

The IOPS numbers seem a bit suspect on that output though. Did the runs tally to stop-watch?

 

[eeguru]

The current theory for compatibility problems with XT-IDE stems from logic delay/gate racing in the strobe that latches in the off byte of the 16 bit data coming from the IDE drive rising after the /IDE_RD strobe going to the drive has also risen. Depending on how long the drive holds the data line drivers active beyond the /IDE_RD strobe coming up verses the logic delay in the IDE card affects whether you get bad data or not. I've attempted to improve this by creating a latch pulse that is independent from the /ISA_RD line. It basically shortens it to one clock cycle a half clock step in from the fall of /ISA_RD. It can't be any longer as the duration of the memory read cycle is only two isa clocks in most cases. At 4.77 Mhz, this is 209 ns. At higher clocks, it's shorter. I've observed the pulse on a logic analyzer and it's a perfect shorter island sitting in the middle of the /ISA_RD pulse. But it causes some DoMs I have and at least one drive to spuriously return bad sector data but not registers or ID sector data.

I believe PIO 1 requires a read data setup time of > 250 ns. But all modern drives should be far beyond that in performance and I expect data setup to occur much much quicker. It's a bit puzzling.

 

[pearce_jj]

I hope you can figure it out as those numbers are very awesome. This is probably way too simplistic, but could the drive be switched to mode-2 to bypass the problem?

Anyway that aside, I've just got the 'high-speed' CPLD code running on the CF card, which is port-based chuck-mod but with faster writes too. Speed, in a PC/XT, are thus:

Read: 204KB
Write: 186KB
8K random 70:30: 8.6 IOPS
Sector: 13 IOPS

Using the old BIOS the read throughput I think was about 230KB/s, so maybe there is some room to streamline the BIOS for it a bit more too, although I'm personally quite happy with the speed now

 

[pearce_jj]

Hi Alan

I'm wondering if I might be coming up against the same problem with the CF card with "fast" writes (single latch mux) CPLD code. With standard logic per the original XT-IDE controller it works great, but as soon as I add more IDE command decode logic, namely XNOR gates to /CS0 and /CS1 (to invert those lines only for writes to 300h/301h), it won't work with SanDisk 'utlra' 4GB CF card in an IBM PC/XT - but it does work fine in a P200 and in both machines with an 'Industrial' CF-Card. In the XT it paritially identifies the SanDisk card (characters missing etc), and can't boot from it.

I could make the logic for the IDE decode simpler by shifting the IDE register addresses, hence port xx1 would serve only for the high byte transfer, but obviously that will need quite a bit of work in the BIOS.

I'm probably missing something but it is very confusing!

 

[pearce_jj]

I went back to basics and tried to understand the ISA bus timing a bit. It seems we can't tell whether it's going to be an IO port read or write during the address setup, since /IOR or /IOW don't arrive until later, hence explaining why inverting IDE commands (from PIO transfer to null) based on /IOW wouldn't work properly. I guess it shouldn't have worked at all, but there we are. Instead I'm hoping to use A4 to detect the write - need to work on the BIOS next.

But anyway, the bracket prototypes are back. Here it is in a PC/XT:

 

[Trixter]

Those look beautiful. I can't wait for these to go on sale.

 

[twolazy]

Ahhhhh! Good ole transcend CF :D

If I use CF flash, all I use! ^_^
I seem to recall sandisk pulling funky ones over on their customers with older CF ultra. Another perfect example of their ignorance, usb thumbsticks with u2/u3. In any case, have you tried using sandisk's CF utility to fix the removable flag on their CF cards?

http://www.floutsch.com/pub/download/ATCFWCHG.COM

*goes back to silently lurking in this thread

 

[Agent Orange]

Ahhhhh! Good ole transcend CF :D

If I use CF flash, all I use! ^_^
I seem to recall sandisk pulling funky ones over on their customers with older CF ultra. Another perfect example of their ignorance, usb thumbsticks with u2/u3. In any case, have you tried using sandisk's CF utility to fix the removable flag on their CF cards?

http://www.floutsch.com/pub/download/ATCFWCHG.COM


*goes back to silently lurking in this thread

I may be wrong on this one, but I thought that the "ULTRA's" were the good guys.

 

[Ole Juul]

. . . But anyway, the bracket prototypes are back. Here it is in a PC/XT:

Very nice! I didn't look at this thread in time to vote, but I do think you're going in the right direction.

Which makes me think. A big reason for using these cards is to be able to run old machines in the future when HDD replacements will be troublesome or impossible. CF is good because it interfaces directly with IDE, but how long will it be around? It seems that it's likely on the way out as well.

 

[twolazy]

I may be wrong on this one, but I thought that the "ULTRA's" were the good guys.

I seem to remember the Ultra II 2gb cards needing to use that utility... Meh i don't use sandisk anymore unless I HAVE too... I rather use transcend or wintec industrial, have much better luck with those. :D

 

[pearce_jj]

CF is good because it interfaces directly with IDE, but how long will it be around? It seems that it's likely on the way out as well.

It's still the standard for pro and semi-pro DSLRs Canon 5D Mk.III for example, and media for commercial appliances too, so I don't personally think it's going anywhere anytime soon. Of course it won't last forever, but nothing in IT does.

Thanks for the comments on this though

 

[pearce_jj]

I've been chipping away at memory-mapped IO and have something working at last! My design has parallel address decoders, so works entirely using IO ports by default, and by sending the high 8-bits of the memory-mapped window to a normally unused port (Base+0Fh) sector transfers can be made via that window too. So memory-mapped IO could potentially be switched on or off on-the-fly for example with a configuration utility, or at least the window set in autoexec.bat to suit the system.

This is very early testing but performance wise (tested with my simple file-system disk tester), it's giving 255KB/s reads using a CF card, 300KB/s reads using a Seagate ST1 microdrive, both measured using a stock 5160 with DOS 6.22. Extended pattern tests have shown no issues and Trixters legendary 8088 Corruption runs through OK.

(On the 8088-corruption thing, I've long had my eye on running the full 30 fps video without a pause. With 300KB/s available, I was hopeful... but it's still not enough.)

There's some work to do in the BIOS to fully support microdrives; as-is the disk only boots on the second attempt, I suspect the drive isn't spinning up & calibrating quickly enough when the read comes (per the CF spec it can't spin until an actual read is received since it's only allowed to draw c.70mA during device ID). And random IO performance is awful, I've not looked into that yet.

Also I've not cracked memory-mapped writes yet.

I've started a technical reference page for the card, with some BIOS code examples, for anyone interested in the details of what's going on.

 

[Trixter]

I've been chipping away at memory-mapped IO and have something working at last! My design has parallel address decoders, so works entirely using IO ports by default, and by sending the high 8-bits of the memory-mapped window to a normally unused port (Base+0Fh) sector transfers can be made via that window too. So memory-mapped IO could potentially be switched on or off on-the-fly for example with a configuration utility, or at least the window set in autoexec.bat to suit the system.

Glad to hear of this progress!

This is very early testing but performance wise (tested with my simple file-system disk tester), it's giving 255KB/s reads using a CF card, 300KB/s reads using a Seagate ST1 microdrive, both measured using a stock 5160 with DOS 6.22. Extended pattern tests have shown no issues and Trixters legendary 8088 Corruption runs through OK.
(On the 8088-corruption thing, I've long had my eye on running the full 30 fps video without a pause. With 300KB/s available, I was hopeful... but it's still not enough.)

A 5150/5160's memory speed is simply not fast enough to do this in a triple-buffering setup (read from disk to buffer, copied from buffer to user space, user space copies to screen). A 5160 never will be able to play back 30fps without pausing unless I re-engineer the playback program to read directly from disk sectors instead of from a file, eliminating a memory copy. I attempted to enhance the player once by reading bigger chunks, but I found on a really slow system this caused a race condition (if a read takes too long and I attempt another read from inside the interrupt handler while the first read is in progress, the machine locks up because DOS is not re-entrant).

For an alternate stress test, use http://www.oldskool.org/pc/8088_Corruption/pop.zip as the video file -- it's 60fps and requires a sustained data rate of 120KB/s. It should play fine, but with some pauses for buffering of course.