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

Best way to implement a 16-bit bidirectional IO port on the AT bus?

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

    Best way to implement a 16-bit bidirectional IO port on the AT bus?

    What would be the best way to implement a 16-bit bidirectional IO port on the AT bus? Would one just use a pair of 8255s in tandem, or is there a better PPI to use for 16-bit stuff that my substandard google-fu isn't sending me to?

    (I assume that a 16-bit port read on the AT bus would be about twice as fast as a pair of 8-bit reads, right?)
    -- Lee

    If you get super-bored, try muh crappy Odysee channel: Old Computer Fun!

    Looking For: QBus SCSI Controller, Type 4 HDC for Tandy II/12/16/6000, Mac IIci drive sled, PC-era Tandy stuff, Old Unix Stuff, Serial Terminals (HP and DG in particular)

    #2
    Use plain old TTL - you'll save space and money. See my comments on the PC printer port thread. You could even modernize it a bit perhaps by using an LS646 (bidirectional register); I haven't looked in detail, but certainly looks possible.
    Reach me: vcfblackhole _at_ protonmail dot com.

    Comment


      #3
      Originally posted by bladamson View Post
      (I assume that a 16-bit port read on the AT bus would be about twice as fast as a pair of 8-bit reads, right?)
      I would do some research on how to make that happen. My memory is very vague on this but I think if a card wants to do 16 bit wide transfers there's some kind of process the card has to do to assert that it's capable of 16 bit transfers? Maybe that's just memory transfers.

      Edit: A supporting citation, maybe?
      Last edited by Eudimorphodon; May 1, 2020, 06:42 PM.
      My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

      Comment


        #4
        Not sure what your application is, but ATA a.k.a. IDE is literally a 16-bit bidirectional I/O interface for the AT bus...

        16-bit access on the ISA bus is generally more than twice as fast as two 8-bit accesses. For 8-bit I/O, there are extra waitstates by default, to accomodate slower cards designed for 8088 systems.

        Comment


          #5
          The IBM ISA XT Printer adapter card is actually an 8 bit bidirectional port, though they didn't hardware configure it that way , but they designed it so it can work. If you change a link on this pcb, I think un-ground pin 1 IC U4 and connect it to pin 15 on U7. On the actual pcb it was set up to do it with some pads and tracks. But if you want 16 bits you could just take the data in a sequence of two bytes in your software, or send it out that way too, if your peripheral device was configured to accept it, say using a handshake line on the port. The card is helpful as its all more or less ready to go and it is a high quality card.Though I'm not sure if this applies to the AT bus, but it will probably still work with the XT card.
          Last edited by Hugo Holden; May 1, 2020, 09:18 PM.

          Comment


            #6
            Hugo, I think I said something to that effect here earlier today.

            You can do 16 bits parallel--it shouldn't be difficult once you get past the little bit of 16-bit ISA port gymnastics.

            It really depends upon what you need the 16 bits for.
            Last edited by Chuck(G); May 1, 2020, 10:11 PM.
            Reach me: vcfblackhole _at_ protonmail dot com.

            Comment


              #7
              Originally posted by Eudimorphodon View Post
              I would do some research on how to make that happen. My memory is very vague on this but I think if a card wants to do 16 bit wide transfers there's some kind of process the card has to do to assert that it's capable of 16 bit transfers? Maybe that's just memory transfers.

              Edit: A supporting citation, maybe?
              Indeed - the card needs to assert /IOCS16 to let the system know it is capable of and is willing to perform a 16-bit I/O cycle. This is an open collector line so it can be driven low but it should not be driven high.

              Comment


                #8
                Originally posted by Eudimorphodon View Post
                I would do some research on how to make that happen. My memory is very vague on this but I think if a card wants to do 16 bit wide transfers there's some kind of process the card has to do to assert that it's capable of 16 bit transfers? Maybe that's just memory transfers.

                Edit: A supporting citation, maybe?
                You have to assert IOCS16#

                The timing requirements for IOCS16# on an AT system are much more lenient than MEMCS16#. You don't have to qualify it on early (LA) address decoding.

                Comment


                  #9
                  Originally posted by bakemono View Post
                  Not sure what your application is, but ATA a.k.a. IDE is literally a 16-bit bidirectional I/O interface for the AT bus...

                  16-bit access on the ISA bus is generally more than twice as fast as two 8-bit accesses. For 8-bit I/O, there are extra waitstates by default, to accomodate slower cards designed for 8088 systems.
                  that's an interesting idea - just take a super basic COTS IDE card and hack it to match a different I/O port address, boom done

                  Comment


                    #10
                    Originally posted by maxtherabbit View Post
                    that's an interesting idea - just take a super basic COTS IDE card and hack it to match a different I/O port address, boom done
                    Actually not sure that adds much value, since an IDE port is pretty literally just the data portion of the AT bus with a decoded chip select in place of the full address bus. A ‘688 and a pair of ‘245s should mostly do that part. The IDE adapter doesn’t include logic for asserting IOCS16, looks like the drive does it itself.

                    So... in theory it should be as easy as asserting iocs16 as a mirror of chip select via an open collector buffer?

                    This might be a good use for a GAL like a 20v8 instead of a ‘688. It has enough inputs to decode all 10 low address lines and a few spares that might come in handy for arbitration for... whatever this is for.
                    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                    Comment


                      #11
                      Originally posted by Eudimorphodon View Post
                      Actually not sure that adds much value, since an IDE port is pretty literally just the data portion of the AT bus with a decoded chip select in place of the full address bus. A ‘688 and a pair of ‘245s should mostly do that part. The IDE adapter doesn’t include logic for asserting IOCS16, looks like the drive does it itself.
                      it adds the value of a pre-built PCB with a hard gold edge connector, and having the bus transceivers already in place - seems like a good place to start to me

                      you're right about needing extra logic for the IOCS16# assertion, I forgot the drive does it for IDE
                      Originally posted by Eudimorphodon View Post
                      So... in theory it should be as easy as asserting iocs16 as a mirror of chip select via an open collector buffer?
                      yeah that should work just fine for I/O ports, MEMCS16# would be substantially more complex

                      Comment


                        #12
                        ... I guess without knowing more about what the application is we donít know if there is any requirement for this host adapter to actually latch-and-hold incoming/outgoing data or if just a buffered I/O decode is enough.
                        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                        Comment


                          #13
                          Originally posted by maxtherabbit View Post
                          it adds the value of a pre-built PCB with a hard gold edge connector, and having the bus transceivers already in place - seems like a good place to start to me
                          I just don’t know how common cards that would trivially allow you to change the address to something arbitrary really are. IDE host adapters were shrunk down into ASICS pretty quickly.
                          My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                          Comment


                            #14
                            Yeah, I'll need to latch and hold data. I am trying to figure out the highest throughput way to interface a raspberry pi gpio header to an ISA IO port, without getting too awfully complicated.

                            Thanks for the advice, guys.
                            -- Lee

                            If you get super-bored, try muh crappy Odysee channel: Old Computer Fun!

                            Looking For: QBus SCSI Controller, Type 4 HDC for Tandy II/12/16/6000, Mac IIci drive sled, PC-era Tandy stuff, Old Unix Stuff, Serial Terminals (HP and DG in particular)

                            Comment


                              #15
                              Huh. I think you might be better off looking at PPI-category devices again if you want some kind of handshake and latching. It might be *just* within the Raspberry Pi's powers to respond in real-time fast enough to keep up with an ISA bus posing as a dumb peripheral but it's going to be a stretch.

                              My uneducated guess would be that handshaking and latching is also likely to slow things down enough it's not going to matter a lot if it's 8 or 16 bits wide. Are you thinking the sort of handshaking that a parallel port does, where you have to check a status bit to see if the partner can take a byte, generate a strobe, wait for an ack, etc?
                              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                              Comment

                              Working...
                              X