• Please review our updated Terms and Rules here

HOWTO: Improve the performance of the XTIDE controller.

Thanks. I realised that a side effect is that every write to the IDE data bus needs to be 16-bits, but register transfers are 8-bits wide. Presumably the BIOS would could zero-out the high byte and transfer the data word?

To add, looking at V20 instruction timings, it looks that OUTM (Intel OUTSW?) and MOVBKW (Intel MOVSW) both run at about 16 clocks per word (have I understood that correctly?) - but would it run at that rate?
 
Last edited:
I've devised a schematic that I think provides port 300h, 301h ordering for both reads and writes hence should support fast transfers in both directions. For reads it's exactly per the 'chuck-mod'; but it uses dedicated transceivers for reads and writes, a single byte-buffer and a few other bits.

Here it is (image file).



Theory of Operation

IO-Reads:

1. Port 300h.

- /CS0 asserted, /CS1 not asserted, IDE-A0..2 not asserted
- Buffer-load asserted, buffer-/OE not asserted

IDE devices interprets this as a data transfer:

- IDE D0..7 presented to the ISA bus via the read-transceiver
- IDE D8..15 loaded into the byte-buffer


2. Port 301h.

- /CS0 not asserted, /CS1 asserted, IDE-A0..2 not asserted
- Buffer-load not asserted, buffer-/OE asserted

So the IDE device ignores the cycle, and the byte-buffer presents the previously loaded IDE D8..15 onto the ISA bus as D0..7.


This is exactly the same as the Chuck-mod.


IO-Writes:

1. Port 300h.

- /CS0 not asserted, /CS1 asserted, IDE-A0..2 not asserted
- Buffer-load asserted, buffer-/OE not asserted

Data presented on the ISA bus D0..7 is transferred via the write-transceiver and loaded into the byte buffer (this is the LOW byte of the Word transferred from the CPU).


2. Port 301h.

- /CS0 asserted, /CS1 not asserted, IDE-A0..2 not asserted
- Buffer-load not asserted, buffer-/OE asserted

The IDE device interprets this as a data transfer:

- IDE D8..15 are presented via the write-transceiver to the IDE directly
- IDE D0..7 are presented via the byte-buffer


EDIT - I realised this circuit had no way to write any other port, so have added logic so it won't flip the IDE /CS0 & /CS1 signals except for ports xx0h and xx1h - ISA singals /IOW, A1, A2, A3 all need to be low, or put another way, it will aways trigger a write command unless it's port xx0.


A second pair of eyes on it would be very much appreciated :) It would need new BIOS code of course. The idea is for CPLD implementation (I'm not proposing a physical circuit).
 

Attachments

  • xtide-v3-schematic.jpg
    xtide-v3-schematic.jpg
    15.5 KB · Views: 2
Last edited:
Personally, I wonder how much trouble this is worth just to host what amounts to an obsolescent interface. (now I'm just thinking, mind you).

I can run a SDHC card (and micro SDHC) in excess of 24MHz, which is roughly 5 times the sustained speed of an ST412 MFM interface and over 3 times the speed of an ST412 RLL interface. Given that this is a card for 8 bit machines that normally runs an ST412 drive at somewhere more than a 3:1 interleave (i.e. 1/3 the sustained throughput of a drive), it makes no sense to me to complicate this thing with trying to accommodate a 16-bit IDE interface.

If you stuck an MCU or CPLD out there with a little supporting logic, you could include SD card support for little more cost than the original XTIDE V2.

Now, to be sure, the XTIDE V2 represents something that can be built by anyone on the unpopulated PCB. It admits to user programming as well. Neither my proposed scheme, nor the CPLD incarnation admit to that.

Bottom line is that I just don't know.
 
Eeguru, thanks - so does the universal BIOSv2 already support port-based word transfers for reads and writes with the chuck-mod port mappings?

Chuck, I kind of agree with you, especially since ISA USB controllers, with BIOS, can be found on eBay for next to nothing. But for me it's interesting - that's it :)
 
Last edited:
You must log in or register to reply here.
Back
Top