HOWTO: Improve the performance of the XTIDE controller.

[Chuck(G)]

I've found that by making a couple of simple changes and reworking the software a bit, a substantial improvement in XTIDE performance (300 to almost 600%).

First, a photo of the mod.

Pay no attention to the capacitor in the photo--that has to do with a mod to provide power for an IDE-to-CF adapter.

The basic idea is to exchange address lines A0 (pin 62 on the ISA bus) and A3 (pin 59 on the ISA bus), both of which have their termination on the PCB component side ISA connector.

Both are fed through to the back side by two "vias"; round holes that are plated to connect wiring from one side of the PCB to the other. Fortunately, they're easy to find--they're the only vias on the lower right-hand side of the back of the PCB.

So, using a very sharp X-acto knife, carefully cut the two traces on the back side that lead to these vias. I make two parallel cuts, separated by a bit and remove the foil isolated by the cuts--you can do it with a single cut, but a little gap in the foil is immediately visible.

Scrape some of the green solder mask from the top of each via, so that there's copper visible to solder to.

Cut two 4" pieces of insulated 28-30 AWG wire and strip the ends for a short distance. I use wire-wrap wire because I've got a lot of it, but other types should work and you could probably go all the way up to about 24 AWG in size.

Insert one end of each wire in the vias you just finished scraping the solder mask from and solder it in the hole. If there's excess sticking through the component side of the PCB, clip it off so it doesn't short out on anything.

Take the wire that comes from the via closest to the bottom edge of the board and solder it to pin 3 of U7--that's the third pin from the right (looking at the back side of the PCB) of the lower row of pins of U7.

Next, do the same with the wire connected to the other via, but solder its free end to pin 5 of U7 (that's the fifth pin from the right). Clip any loose ends and if desired, tack the wires to the PCB using clear nail polish, hot glue or a dab of silicone caulk. Use just enough so that there's no danger of the wires getting snagged.

Now, install the attached software BIOS image onto the XTIDE. It's Hargle's BIOS, modified for this change.

If you're using the 2864 EEPROM as specified in the BOM, use the oprom.bin image. If you're programming an EPROM (e.g. 2764) externally, use the "shuffled" image oprom_s.bin.

It's probably best to use the default port setting of 0300h to begin with.

Enjoy!

P.S. If you want to reverse the mod, just swap the wires connected to pins 3 and 5 of U7 and you'll be back to the original configuration. Of course, the attached BIOS will not work with the board in its original configuration.

 

[slincolne]

OK - so far 14 people have viewed this, but as nobody has yet asked:

Could you explain the theory behind this ?

 

[per]

OK - so far 14 people have viewed this, but as nobody has yet asked:

Could you explain the theory behind this ?

The XT-IDE latches the 16-bit data as two 8-bit segments. Because of this, you will have to read/write first to one register and then to the other register.

The IDE interface originally uses I/O port base + 0-7, so the additional latch is originally mapped to base + 8. What this mod do is to shuffle the ports around which puts the two data I/O ports next to each other. Now a word can be read using one 16-bit input instruction instead of a pair of 8-bit input instructions, and this really helps on performance in an 8088.

I don't know if this makes DMA transfers possible, though.

 

[Chuck(G)]

I don't know if this makes DMA transfers possible, though.

No, it doesn't, but then I don't know that DMA on a 5160 can run any faster than a IN/STOSW combination. My tests on a "turbo" XT indicate that there isn't any read speed difference between 4.77MHz and 8MHz. If the CPU loop were the bottleneck, you'd expect to see a difference (indeed, the old code does show this). Tests run with a CF card so that rotational latency doesn't play a part.

With DMA you also have 64K physical memory boundary crossing issues.

Try it--if you don't like it, you can always reverse the change pretty easily.

 

[per]

No, it doesn't, but then I don't know that DMA on a 5160 can run any faster than a IN/STOSW combination. My tests on a "turbo" XT indicate that there isn't any read speed difference between 4.77MHz and 8MHz. If the CPU loop were the bottleneck, you'd expect to see a difference (indeed, the old code does show this). Tests run with a CF card so that rotational latency doesn't play a part.

With DMA you also have 64K physical memory boundary crossing issues.

Try it--if you don't like it, you can always reverse the change pretty easily.

I/O takes 5 clock cycles (1.05uS). This is the case for both processor I/O and DMA, which means that if nothing but I/O takes place; it's possible to reach about 952381 transfers (a little less than 1MB) per second. Of course this is not the case since the bus is mostly used to fetch new CPU instructions and DMA refresh. In addition, the CPU also uses some cycles to execute fetced instructions.

The fastest 16>8-bit IDE adapter I have seen (Silicon valley ADP50) can do up to 300 KB per second, which is about the transfer rate of memory R/W. This is mostly because the card uses memory mapped I/O.

 

[Holmes]

If anyone's interested, this modification discussion really developed here, with lots of technical discussion of the change:

http://www.vintage-computer.com/vcforum/showthread.php?23845-XT-IDE-Hardware-Setup-Gallery/page2

It seems there were ideas for it earlier on in the XT-IDE life-cycle, but the initial emphasis was on making a solid working product (and rightly so), rather than performance tweaks like this.

A great example of collaboration leading to improvement of an already great thing!

 

[Chuck(G)]

I found a copy of CORETEST 3.03 here. It was one of the old standards back in the early days of the PC AT and was considered to be reliable.

A quick check on my system running at 4.77MHz gives a read transfer rate of 1168KB/sec. on the modified controller using a 192MB CF card. Does anyone want to run CORETEST on the regular setup (I don't want to pull out my soldering iron) and report the results?

At first blush, I don't think it's possible to do much better on an 8088-based system.

 

[mbbrutman]

I'd be suspicious of that number. I found that when I was benchmarking the XT-IDE that I was loosing an excessive number of clock ticks, thus skewing the results of the benchmark. (The Hargle BIOSes kept interrupts disabled for quite a long time.)

You should double check with a stop watch if it runs long enough ...

 

[Chuck(G)]

It's not as accurate as it should be perhaps, but we're not really after an absolute number here are we? Benchmarks are just another forms of "lies, damn lies and statistics". I'm more interested in comparatives. The latest Hargle BIOS doesn't disable interrupts--there was no point to it anyway.

CORETEST includes data for other drives for comparison within the test and I think that's the value. There should be a wealth of comparatives lurking around from the 1980s using CORETEST, for example, this.

I'd also be interested in some other MFM/RLL datapoints.

 

[Lutiana]

I'd also be interested in some other MFM/RLL datapoints.

My 42Mb MFM drive gets a Buffered read of 165kb/s, sequential read of 165kb/s and a random read of 138kb/s using Coretest.

EDIT: The machine is a 5160 w/ and NEV V20 CPU and 640k of RAM.

 

[dabone]

I tried this mod and must not have been holding my teeth right, So I redid it, and flashed the _s image to the eeprom with my burner and finally got a boot bios.
These tests were in a Tandy 1000sx with a Sandisk 512M CF card.


7Mhz
640K
AST 6 Pack Card No Ram, just using it for the clock.

Coretest 2.92

			KB Per Second.			Performance Index.

Original Bios -		156.2				48.226
Modded Card -		723.4				115.684

Wow!

Now thats impressive.

Later,
dabone

 

[slincolne]

Oh dear - is this where the Osborne effect sets in ?

Oh dear - is this where the Osborne effect sets in ?

Talk about a nice modification - that's a serious bang for effort improvement on the card.

Congratulations - now we all hold our breath waiting for the next rev of the PCB

 

[aitotat]

Does this mod change register mappings in any other way that to locate the second data register? Does this make the XTIDE work just like any 16-bit IDE controller? If so, then NEC V20/V30 and 286+ users should just configure XTIDE Universal BIOS to 16-bit interface. I'll add support to XT build once I have time to try the mod.

 

[per]

Does this mod change register mappings in any other way that to locate the second data register? Does this make the XTIDE work just like any 16-bit IDE controller? If so, then NEC V20/V30 and 286+ users should just configure XTIDE Universal BIOS to 16-bit interface. I'll add support to XT build once I have time to try the mod.

Nope. In order to add support for direct true 16bit operation, the entire 16-bits of the bus has to be present. The "16bit" I/O of the 8088 is only pseudo-16bit as it is based on two 8-bit I/O transfers.

In general, the new code for the modded card saves 11.7uS per 2 bytes, and an additional 10.1uS per 8 bytes due to a reduced number of loops. In other words, about 14.2uS are saved on every word transfer, which is quite a lot. In a 4.77MHz computer, this should bring the performance from 85KB/s to 220KB/s. By halfing the number of loops; by adding 4 more "In ax,dx"+"movsw" instruction pairs (8 per loop), the speed should be able to get up to 234KB/s. By adding 12 more (16 per loop), around 240KB/s is expected. How many of these loops we can cut depends on the ROM size, and this is certanly a limitation. The fastest would be to lay out the 256 instruction pairs with no loops at all, where about 247KB/s transfer rate is expected. Compared to memory>accumulator/accumulator>memory operation, which is about 300KB/s, this is not bad at all.

These calculations are based on an assumption that the ratio between bus-active/bus-idle is the same for both the old and new routine.

 

[dpatten]

Will this increase or decrease the speed in a true 16 bit processor system? I'm planning on using my cards in an 286 AT and a PS/2 model 30 with an 8086 so I can sit the old Seagate St-4026 and the PS/2's oddball HDD on a shelf.

I'm not sure I am asking this correctly. Is this solution specifically tailored for the 8088's 8 bit bus and how will it affect (if at all) a true 16 bit processor?

 

[Quagmire]

Will this increase or decrease the speed in a true 16 bit processor system? I'm planning on using my cards in an 286 AT and a PS/2 model 30 with an 8086 so I can sit the old Seagate St-4026 and the PS/2's oddball HDD on a shelf.

I'm not sure I am asking this correctly. Is this solution specifically tailored for the 8088's 8 bit bus and how will it affect (if at all) a true 16 bit processor?

Why would you worry about a 16-bit system with this particular card? This project was originally about getting IDE HD's to the 8088 pc's in lieu of MFM/RRL HD's at a relatvely low cost to all. There are scads of ISA 16-bit controllers out there (real cheap) that will give you excellent performance on a 286 with having to modify anything. Who knows, there might be a slight performace gain on 286, but why bother?

 

[Raven]

What kind of soldering iron would you guys recommend/do you use for this kind of precise work? I've got some cheap-feeling thing from the 70s that doesn't even have a ground plug, it's like a resistor you plug into the wall. I don't think it would ever be able to do this kind of work.

dpatten: I used my XT-IDE in a 486 box for a while, and when I mentioned I was doing so was chastised, including some solid reasoning not to.

- It's an 8-bit bus, meaning it is inherently impossible for this card to be as fast in those boxes as contemporary cards for them.
- The real value of this card in a newer system (286+) is it's BIOS, it's capable of working with all sorts of devices, the most modern I tested was a 768GB IDE disk.
- The BIOS is available in alternative formats, including an "AT" version that can be flashed onto other controllers, even a network card - anything that injects it's ROM into the boot sequence - and it will take over IDE functions for the machine, from what I gather.

Regarding the last point: unfortunately I haven't pulled that off myself, yet, as I bought a ROM burner that can't seem to write to anything, and though the XT-IDE can write to a specific chip, I haven't had the chance to purchase one yet. I may well, though, and put it on a network card to replace the drive overlay I use in my Presario 425 - should speed it up a fair bit, at least disk-access-wise.

@the board devs (or whoever else knows):

One reason I used the card was I needed another set of IDE devices, four wasn't enough. This gave me those. Most IDE cards disable the on-board or other IDE cards and vie for control, they don't coexist. Does this BIOS let them do that? Does this BIOS just being IN the system anywhere let them do that? I'm rather confused about transplanting it's BIOS(es) onto other devices - how does it know what card to handle, what to not? Does it handle all cards? If I burn it to a 16-bit IDE controller, will it affect a VLB IDE controller that's on the mobo? It's rather unclear what the "rules" are, since in the "natural" world of these machines there are no rogue BIOSes as such..

Let's say I want to stuff a system with IDE headers and hard disks, for example. If I put a network card with the AT variant of the BIOS into the first slot, and then a wide array of random 16-bit IDE controllers in the rest, will they all be controlled by the BIOS and coexist happily and "just work"? What if I put the XT-IDE itself in the first slot instead of a network card with that BIOS? What if I put an IDE controller (16-bit) with the AT BIOS in that first slot?

You see I just have no idea which is the right path, what would do what, etc..

Doing this to a network card will only disable it's boot capability, right? It'll still act as an ordinary network card in all other respects? Will the BIOS be shadowed to the RAM on ANY machine, or will the card be continually accessed whenever the disk is..?

 

[Chuck(G)]

Raven, it'd be more easier to respond if you limited your topics to one per posting.

The issue of a soldering iron has been brought up before. I vote for the Weller WTCP irons, but that's only because I've been using one for more than 30 years and don't know any better. Last year, I replaced the heating element on my 1970's iron after it gave out--the old one had many many hours on it.

That being said, Xytronics makes some affordable irons that are quite good. There's a $30 Elenco temperature-controlled iron that's actually quite acceptable. I'm an advocate of temperature controlled irons--they make it harder to damage (i.e. lift the traces) on a PCB and won't burn the soldering flux.

It's inevitable that tips will need replacing, so consider the cost and availability of them when selecting your iron.

That being said, there are plenty of acceptable irons out there.
--------------
Generally, older motherboards (i.e. 286/386 and even some 486) have support for only one IDE channel; later ones have support for two. Beyond that, you need an IDE adapter with its own BIOS.

SCSI used to be the only way to get lots of drives on a PC. 16-bit SCSI can support up to 16 devices on a single SCSI bus and there exist multi-channel SCSI controllers.

 

[hargle]

One reason I used the card was I needed another set of IDE devices, four wasn't enough. This gave me those. Most IDE cards disable the on-board or other IDE cards and vie for control, they don't coexist. Does this BIOS let them do that? Does this BIOS just being IN the system anywhere let them do that?

The trick to it is IO space.
IO space is a limited resource, and for compatibility and to avoid IO conflicts, most IDE controllers use a fixed location of where they exist, either the primary location (1f0) or secondary (170) location. Your 386+ motherboard might also have onboard IDE controllers, and they too will typically be at 1f0 or 170. This is why when you install a new IDE controller into a mobo that has onboards, you will probably have to disable the onboard ones.

Our card exists at 300h, and therefore is typically conflict free with most IDE controllers.

I'm rather confused about transplanting it's BIOS(es) onto other devices - how does it know what card to handle, what to not?

It works because the entire system is available to any software that is running.
A BIOS, installed in a NIC, an XTIDE controller, your motherboard, or anywhere else, has complete and total visibility to the entire system, including other cards. So in our example here, BIOS installed in a NIC card can "see" the IO space used by the XTIDE controller at 300h. IOW, when you install any card into your machine, that card becomes part of the whole system, it does exist in isolation.

Let's say I want to stuff a system with IDE headers and hard disks, for example. If I put a network card with the AT variant of the BIOS into the first slot, and then a wide array of random 16-bit IDE controllers in the rest, will they all be controlled by the BIOS and coexist happily and "just work"?

This would likely fall on its head because of the fact that most normal IDE controllers use those 2 IO spaces. You could put 8 XTIDE controllers in, but each one of them would have to be set to different IO spaces so there are no conflicts.

What if I put the XT-IDE itself in the first slot instead of a network card with that BIOS? What if I put an IDE controller (16-bit) with the AT BIOS in that first slot?

First slot, last slot, it doesn't matter. It becomes part of the system.

Doing this to a network card will only disable it's boot capability, right? It'll still act as an ordinary network card in all other respects?

Correct. You likely aren't booting from your NICs anyway, so the ROM isn't being used. The NIC card is just a means of getting the IDE BIOS into the system.

Will the BIOS be shadowed to the RAM on ANY machine, or will the card be continually accessed whenever the disk is..?

BIOSes on machines with less than 1MB of memory are not shadowed at all. Shadowed here meaning "copied to RAM". Otherwise, yes, anytime the card is accessed, it would likely require a read of code from the eeprom.

we are now way off topic. sorry.

 

[dpatten]

Why would you worry about a 16-bit system with this particular card? This project was originally about getting IDE HD's to the 8088 pc's in lieu of MFM/RRL HD's at a relatvely low cost to all. There are scads of ISA 16-bit controllers out there (real cheap) that will give you excellent performance on a 286 with having to modify anything. Who knows, there might be a slight performace gain on 286, but why bother?

Firstly, because the prices of Acculogic style cards for machines that are BIOS limited to 528 or 2048 MB are quite pricey. You can't just drop an 8GB HDD on a 1994 era dumb HDD controller card.

Second, The IBM PS/2 model 30, while having an 8086 processor, still only has 8 bit ISA/XT slots. Standard AT Bus 16 Bit ISA HDD controller cards are useless for this machine. That's why.