Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

HOWTO: Improve the performance of the XTIDE controller.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    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
    Reach me: vcfblackhole _at_ protonmail dot com.

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

    Could you explain the theory behind this ?

    Comment


      #3
      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 ).

      Comment


        #4
        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.
        Reach me: vcfblackhole _at_ protonmail dot com.

        Comment


          #5
          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 15, 2011, 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 ).

          Comment


            #6
            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!

            Comment


              #7
              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.
              Reach me: vcfblackhole _at_ protonmail dot com.

              Comment


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

                Comment


                  #9
                  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 15, 2011, 01:40 PM.
                  Reach me: vcfblackhole _at_ protonmail dot com.

                  Comment


                    #10
                    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

                    Comment


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

                      Code:
                      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
                      Last edited by dabone; February 15, 2011, 06:03 PM.

                      Comment


                        #12
                        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

                        Comment


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

                          Comment


                            #14
                            Originally posted by aitotat View Post
                            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.
                            Last edited by per; February 16, 2011, 03:00 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 ).

                            Comment


                              #15
                              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?

                              Comment

                              Working...
                              X