Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 34

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

  1. #1

    Default 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 YouTube channel: Old Computer Fun!
    Looking to Buy/Trade For (non-working is fine): TRS-80 Model II,12,16,6000, Mac IIci hard drive sled and one bottom rubber foot, Hercules card + mono monitor (preferably IBM 5151), Multisync VGA CRTs, 040 or 601 card for Mac IIci, Decent NuBus video card, Commodore PC(286+), PC-era Tandy stuff, Aesthetic Old Serial Terminals, Amiga 2000 or 3000UX

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,396
    Blog Entries
    18

    Default

    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.

  3. #3
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,406

    Default

    Quote 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 1st, 2020 at 06:42 PM.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. Default

    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.

  5. #5

    Default

    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 1st, 2020 at 09:18 PM.

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,396
    Blog Entries
    18

    Default

    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 1st, 2020 at 10:11 PM.

  7. #7
    Join Date
    Aug 2017
    Location
    New York, Rome, London
    Posts
    131

    Default

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

  8. #8

    Default

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

  9. #9

    Default

    Quote 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

  10. #10
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,406

    Default

    Quote 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

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
  •