Image Map Image Map
Page 1 of 11 12345 ... LastLast
Results 1 to 10 of 105

Thread: HOWTO: Improve the performance of the XTIDE controller.

  1. #1
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,716
    Blog Entries
    18

    Default HOWTO: Improve the performance of the XTIDE controller.

    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.
    Attached Files Attached Files

  2. #2

    Default

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

    Could you explain the theory behind this ?

  3. #3

    Default

    Quote Originally Posted by slincolne View Post
    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.
    Current systems owned by me:
    Vintage:IBM PC/XT submodel 087 ( 1983 ), [Kon]tiki-100 rev. C (1983), Compaq Portable I ( 1984 ), IBM PC/XT submodel 078 ( 1985 ), IBM PC/XT286 ( ~1986 ), 3x Nintendo Entertainement Systems ( 1987 ).
    Obsolete:Commodore A500 ( ~1990 ), IBM PS/2 model 70/386 type 8570-161 ( 1991 ), Atari Lynx II ( ~1992 ), Generic Intel 486SX PC ( ~1993 ), AT/T Globalyst Pentium w/FDIV bug MB ( 1994 ), Compaq 486DX4 laptop ( ~1995 ).

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,716
    Blog Entries
    18

    Default

    Quote Originally Posted by per View Post
    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.

  5. #5

    Default

    Quote Originally Posted by Chuck(G) View Post
    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.
    Last edited by per; February 15th, 2011 at 03:37 AM.
    Current systems owned by me:
    Vintage:IBM PC/XT submodel 087 ( 1983 ), [Kon]tiki-100 rev. C (1983), Compaq Portable I ( 1984 ), IBM PC/XT submodel 078 ( 1985 ), IBM PC/XT286 ( ~1986 ), 3x Nintendo Entertainement Systems ( 1987 ).
    Obsolete:Commodore A500 ( ~1990 ), IBM PS/2 model 70/386 type 8570-161 ( 1991 ), Atari Lynx II ( ~1992 ), Generic Intel 486SX PC ( ~1993 ), AT/T Globalyst Pentium w/FDIV bug MB ( 1994 ), Compaq 486DX4 laptop ( ~1995 ).

  6. #6
    Join Date
    Dec 2010
    Location
    Frederick, MD
    Posts
    298

    Default

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

    http://www.vintage-computer.com/vcfo...-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!

  7. #7
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,716
    Blog Entries
    18

    Default

    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.

  8. #8

    Default

    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 ...

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,716
    Blog Entries
    18

    Default

    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.
    Last edited by Chuck(G); February 15th, 2011 at 01:40 PM.

  10. #10
    Join Date
    Mar 2009
    Location
    Dublin, CA USA
    Posts
    2,811
    Blog Entries
    1

    Default

    Quote Originally Posted by Chuck(G) View Post
    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.

    IBM 5160 - 360k, 1.44Mb Floppies, NEC V20, 8087-3, 45MB MFM Hard Drive, Vega 7 Graphics, IBM 5154 Monitor running MS-DOS 5.00
    IBM PCJr Model 48360 640kb RAM, NEC V20,, jrIDE Side Cart, 360kb Floppy drives running MS-DOS 5.00
    Evergreen Am5x86-133 64Mb Ram, 8gb HDD, SB16 in a modified ATX case running IBM PC-DOS 7.10

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •