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

8 bit IDE (XTA) Replacement Project

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

    8 bit IDE (XTA) Replacement Project

    I've recently started work on a solid state replacement for 8 bit IDE hard drives. It is looking like it will be a substantial undertaking so I thought I would share progress here as I go. And if I am lucky, maybe some other folks will jump on board to help with the development.

    I bumped this project to the top of my queue since it seems most needed out of the projects I have in mind. That, and I am terrified that my working drives I need for reference could die at any moment.

    At the moment, I am focussed on understanding the technical requirements better. I have been analyzing my ST05X IDE card. I disassembled the BIOS with Ghidra and understand much of what it is doing. I am now in the process of creating a 386 protected mode tool (based on TNDY.COM) for logging all port access. This is to understand the access protocols better. This work is shared here: https://github.com/JayesonLS/8bit-ide-analysis

    My current plan is to first emulate the drive(s) in PCem. PCem emulation isn't low level enough to test the planned circuit/logic. It will however allow me to get the register protocols down. PCem already has an emulation for the original IBM Xebec controller. This is likely most of the way there. I was half expecting it to work with the ST05X BIOS without modification. The ST05X BIOS does detect a drive but it is not accessible. Once the ST05X is working, then in theory I could configure emulation of other XTA PC's (Tandy's, etc.) and make sure those all work.

    After that is done, then figure out the hardware. A decent amount of firmware to write also. In addition to the ST05X, I have a Tandy TL/2 to test on. And then if that all works out, look at making the IBM edge connector work. I do have a PS/1 and a PS/3 Model 30, with one working hard drive between them. Hopefully it hangs in there long enough.

    The hardware is looking like it will involve a CPLD, microcontroller, SD card, a pin header/power connector on one end, and the IBM edge connector on the other end. I was originally hoping to just use an SPLD and keep the entire design through-hole and programmable with a TL866. Unfortunately, the BIOS code does 6 register writes in rapid succession. On the original controllers, these were stored directly into the sector RAM. I don't know of any suitable microcontroller that allows writing to its RAM in this way. The IBM connector includes IOCTL so that could be used to slow the PC down. Unfortunately, the "standard" 40 pin connector does not. So I think the next best option will be to hold the 31+ bits of essential data in a CPLD.

    #2
    For those interested, here is a some knowledge I have gleaned so far. The most important detail is that XTA essentially just moves the XT MFM hard drive controller onto the drive. So it is very different to 16 bit IDE (ATA) which are based on AT MFM controllers. While XTA is not explicitly documented anywhere I can find, XT MFM controllers are very well documented. I’ll share a bunch of relevant links below.

    Drive size selection on XTA is very limited. It retains the two bit drive size specification from XT MFM. That is only 4 possible sizes. The ST05X only supports 3 unique drive sizes: 20MB, 30MB and 40MB. I suspect these sizes are not entirely consistent across different BIOSes. I would be surprised if any support > 40 MB. The Seagate ST351A/X drive has quite a number of possible jumper configurations. So a general purpose replacement will likely also have complicated jumper settings. And be limited to 40MB in size.

    XTA does not support ATA style master/slave. That is, it does not support two drives on the same interface. Cards/PCs supporting two drives implement two interfaces. In practice, this just ends up being a second select line. That is why some PC’s use two connectors with two wires swapped on the second connector. An unused pin is being used to carry the second select line. It also means that supporting two drives uses double the number of IO ports in the system. Not a big deal since an XTA interface uses less than half the ports of an ATA interface.

    I was originally thinking of putting two connectors in the drive replacement so it would behave like two 40mb drives. It would complicate the implementation a lot though in trying to keep the two virtual drives behaving completely independently. It would also complicate things a bit if there were two drives on the same SD card.

    Some links:
    Stack Exchange question which links to some controller IC docs. I did not find these super useful: https://electronics.stackexchange.co...specifications
    Russian language page linked to from the Stack Exchange question. This is where I learned that 8 bit IDE is essentially XT MFM. Also has a pinout: http://wiki.sensi.org/dokuwiki/doku.php?id=hddxt

    WD XT MFM controller documentation - very detailed: https://ibm.retropc.se/manuals/Weste...M%20Manual.pdf

    Pinouts of both “standard” and IBM connectors: https://ardent-tool.com/misc/IBM_HD_pinouts.html

    PS/2 Model 25 tech reference manual which has a little more info and confirmation of the IBM pinouts: https://ardent-tool.com/docs/pdf/PS2...ence_Jun87.pdf

    - Jayeson

    Comment


      #3
      Interesting project!

      I have been thinking about something similar for a while, but have not been able to put nearly as much time into it.
      Wouldn't it be possible to use one of the beefier STM32 controllers and let it handle everything in software in an interrupt-based fashion?
      I figured that a Cortex M with >100 MHz should be able to bit-bang a 4.77 MHz bus, but I could be mistaken.
      The integrated USB host support on some of these controllers would make them particularly interesting for this kind of use case.

      Comment


        #4
        I got to wondering whether the IBM drives are the standard XTA with a custom connector. After a little digging, I think that is not the case. The IBM drives with the edge connector are a different implementation of 8 bit IDE.

        The IBM connector has an additional address line as well as the IOCNTL signal. This suggests a different implementation although it could be that they are unused. So I did some disassembly on the PS/2 Model 30 286 BIOS and the routines I found are not consistent with XTA. One routine polls port 322 with a timeout, waiting for bit 2 to be set. Port 322 on XTA is for the drive size bits and it does not make sense to wait for a single size bit to be set. Also, there are routines to read port 324. On XTA this would be for the second drive. However on the IBM, this all decoded for the one drive. Also, on XTA, access patterns for are the same for the respective ranges of 320-323 and 324-327. In the IBM BIOS, it is not like this at all.

        So the IBM looks to be something different. Maybe it is more like ATA. Or maybe IBM came up with something new. It would certainly be possible - the XT MFM / XTA protocols are a little goofy IMO - no doubt necessitated by the optimising the design of the controller hardware.

        If anyone has any additional knowledge, I would be keen to hear it. With no documentation of the protocols, I think the only approach is to reverse engineer the BIOS. This would be a lot of work.

        Comment


          #5
          Originally posted by Benedikt View Post
          Interesting project!

          Wouldn't it be possible to use one of the beefier STM32 controllers and let it handle everything in software in an interrupt-based fashion?
          I figured that a Cortex M with >100 MHz should be able to bit-bang a 4.77 MHz bus, but I could be mistaken.
          The integrated USB host support on some of these controllers would make them particularly interesting for this kind of use case.
          I have looked at using fast ARM controllers on an 8 bit computer bus (< 2MHz) before and it looked like maybe it could be fast enough, although probably not. I never got around to trying it. One gotcha is that while the core may be very fast, the external IO rate may not be nearly so fast. That said, it is probably fast enough to read bytes out of some simpler marshalling hardware that just buffers one byte. The down side is that those controllers are not through hole unless a dev board is used. A good idea that warrants some more thought.

          Comment


            #6
            Your requirement seems to be a solved problem. Why not just use an inexpensive Transcend parallel-IDE Disk-on-Module (DOM)? Example: https://www.ebay.com/itm/193738886321 (4GB for $8.90, shipped)

            For more DOM info: https://www.cactus-tech.com/resource...n-application/

            Comment


              #7
              http://nerdlypleasures.blogspot.com/...rface.html?m=1

              Comment


                #8
                Originally posted by pbirkel@gmail.com View Post
                Your requirement seems to be a solved problem. Why not just use an inexpensive Transcend parallel-IDE Disk-on-Module (DOM)? Example: https://www.ebay.com/itm/193738886321 (4GB for $8.90, shipped)

                For more DOM info: https://www.cactus-tech.com/resource...n-application/
                Because they don't work..? Do you actually know the difference between XTA (8-bit) and IDE/ATA (16-bit)?

                Comment


                  #9
                  For those unfamiliar with them, here's my video about IDE-XT (XTA) drives and interfaces:

                  Comment


                    #10
                    If I needed an XTA emulator, I'd build on one of the existing ATA emulators, such as this one using an RPi zero. Doubtless there are others not using a GHz MPU to do the work...
                    Reach me: vcfblackhole _at_ protonmail dot com.

                    Comment


                      #11
                      Originally posted by JayesonLS View Post
                      I have looked at using fast ARM controllers on an 8 bit computer bus (< 2MHz) before and it looked like maybe it could be fast enough, although probably not. I never got around to trying it. One gotcha is that while the core may be very fast, the external IO rate may not be nearly so fast. That said, it is probably fast enough to read bytes out of some simpler marshalling hardware that just buffers one byte. The down side is that those controllers are not through hole unless a dev board is used. A good idea that warrants some more thought.
                      My gut feeling is that something like the STM32 on a Blue Pill should be able to keep up with this. Possibly not with interrupts, apparently the pin-triggered ones have fairly high latency, but they can poll like gangbusters, and they also have a DMA engine that might do the needful. (Presumably you'll also want to implement DMA for data transfer, an XT BIOS will probably expect it.)

                      Of course with Pi Zeros costing five bucks maybe it isn't worth bothering with something as lowly as that.
                      My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                      Comment


                        #12
                        There are a lot of MCUs that could serve as candidates, but the Pi Zero sort of skews the picture--lot of compute horsepower for cheap.
                        Reach me: vcfblackhole _at_ protonmail dot com.

                        Comment


                          #13
                          The Blue Pill boards with their 72 MHz Cortex M3 STM8F103C8T6 are also what I initially had in mind, but they might be a tad bit slow and you would then be limited to SD cards. Being able to use USB flash drives, perhaps combined with a USB slot bracket, would be quite nice.

                          Comment


                            #14
                            Originally posted by Eudimorphodon View Post
                            My gut feeling is that something like the STM32 on a Blue Pill should be able to keep up with this. Possibly not with interrupts, apparently the pin-triggered ones have fairly high latency, but they can poll like gangbusters, and they also have a DMA engine that might do the needful. (Presumably you'll also want to implement DMA for data transfer, an XT BIOS will probably expect it.)
                            I did a bit of investigation and it does not look to me like a Blue Pill is not close to being fast enough to directly service the ISA bus. At 8.33MHz, we get at best 8 guaranteed cycles of a 72MHz STM32. The GPIO ports are sampled at 1/2 the clock rate, so that adds 2 cycles of latency. To service an ISA bus read, we would have some fraction of the 6 remaining cycles to read the GPIO register, branch on the decoded address, then set up the data on the ISA bus. And that is before taking into account the effect of the latency of the polling loop. The performance seems to be about an order of magnitude off.

                            That would suggest a 1GHz core would be able to it. However it is my understanding that the GPIO registers are not internal to CPU core and can not be read nearly as fast as a CPU register or data in the L1 cache. Instead they are handled as an uncached read.

                            I an not even confident at this point that an STM32 could store off the 6 command bytes as they are written to the XTA controller. The data is only present on the bus for part of the bus cycle so the loop time of the polling loop must be <= that time. And that is before taking into account other latencies in the external logic and the GPIO port sampling.

                            Comment


                              #15
                              You are aware that an 8088/8086 bus cycle is four clock cycles and that data (in the case of a read or write) isn’t sampled until the third cycle, correct? Not saying that it’s going to make it *that* much easier, you’re still only going to get two 8088 clock ticks to interpret the address bus and return the expected register value in the case of reads, that’s kind of intimidating , but for writes you could always toss a latch in there to loosen up the timing requirements. Effectively you need to poll at 2mhz, not 8mhz… with conditions.
                              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                              Comment

                              Working...
                              X