1. Not old. Vintage. :)

Adding a second PIA to the Atari 8-Bit

Discussion in 'SIG: Atari 8-Bit Hardware' started by Timothy Kline, Feb 15, 2020.

  1. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    Where this begins: https://atari-owner.com/club/articles/adding-a-second-pia-to-the-atari-8-bit.2/

    I am utterly clueless why this is not taken advantage of in the Atari hardware community— but I also don't know anything when it comes to engineering or even how to put the ideas I get in my head into reality in tapping the Atari's 6502 to its thresholds.

    I get it: with the onboard PIA, using the port as an input/output I/O for an attached device reduces data transmission down to bit-bashing it through the inline PIA.

    I get it.

    But adding a second PIA and an additional 9-PIN joystick port removes the bit-bashing aspect, providing the necessary lines to drive data through at arguably significant speed in a full-duplex transmission, and a decent enough half-duplex transmission when the context demands it— such as in a PIA-based LAN interrupt routine or gaming.

    The SIO has its own inherent obstacles that are far more problematic, in my opinion— namely that when SIO talks, everyone else stops and lets SIO talk. Timing appears to be far more of an issue than what I understand a dual-PIA modification presents, since the PIA runs at bus speed as long as the port's gate is open and ticks can be used for timing purposes via VBI or IRQs to synchronize connected machine's internal clocks, for example, to synchronize gamers on the ALAN (Atari LAN) I picture in my head as being possible.

    The only part of the article I understand is how to open and close the gates (ports) once they're available. 8-Bit programmers do that every time they PEEK or POKE an address.

    Don't mistake me on this: I am stoked that a way to ALAN our Atari's is finally making the Atari scene! I just see an SIO-based approach as being too much work for what is already available. I also kind of understand that an SIO-based ALAN is non-invasive: it will require no modifications— whereas a dual-PIA would require, at a minimum, mainboard modifications and a way to make the necessary connections to the outside for cabling.

    I wouldn't suggest that I'm not going to want to use the SIO-based networking, because I hope to! Being able to ALAN my Ataris gives me all sorts of ideas to try out on the software side, and explore the possibilities.

    But the dual-PIA approach would fit those who enjoy modding their Atari up with U1MBs, RAMBO upgrades, and other goodies, it seems to me.

    I wish I understood the engineering and electronic aspects of a dual-PIA network. And I really don't want to trial-by-error!

    Once each machine has a dual-PIA installed, then you have the joystick cable with matching ends as your network cable between them— making certain that 5v pins are never to touch or snap-crackle-pop!

    But what then? Is that where all that's left are the openings and closings of the gateways/ports to handle data transmission, and the PIAs will talk to each other using ALAN's software as an interrupt or VBI-driven networking kernel?

    If that's it, then I think I can handle the soldering and installing an ALAN port— and feel more confident than I do right now, as much as it intrigues me.

    --Tim
     
    Graham likes this.
  2. by M.D.Baker
    M.D.Baker

    M.D.Baker Deckhand

    Blog Posts:
    2
    I agree with you 100%. Just remember, there are multiple solutions out there for just about everything for our Atari's from memory upgrades, OS upgrades, Cart or PBI based HDD, etc., etc., and just because someone is creating a new Atarinet or AtariLAN or whatever, through the SIO doesn't mean others can't do something different and maybe better through controller ports and extra PIA's too. I'd much rather do it that way as, like you said, I have so much working via SIO already and there will be conflicts.

    Just like I would rather have the new on-line Dragon "cart" PBI version instead of the cartridge port version both of which are concurrently being developed by different people, that way I can use my SDX cart and MyIDE II carts still while using Dragon communications through the PBI which only has to share with my Syscheck board there for extended memory. Even though daisy-chaining of the SIO and pass-thru of the PBI and cart ports are possible, spreading devices and communications out to all available I/O possibilities sounds the best to me, with the least chance of conflict.
     
    Graham and Timothy Kline like this.
  3. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    I didn't know that someone was working on a PBI version of the Dragon cart! Very nice!!

    Cartridge-based solutions, I'll confess, are becoming less of an issue than they used to be with options such as the SIDE/2 offering inline OSS carts, for example. Still, something like cartridge-based WI-FI, while cool, are roadblocks to development— especially for A800 owners!

    But I agree that it's Atari's strength to be able to arrive at solutions through more than one avenue. I just wish someone would explore the PIA-based ALAN approach until I someday (yeah, right!) know and have learned enough to put what's in my head out into the real-world. :cool:

    --Tim
     
    Graham likes this.
  4. by Graham
    Graham

    Graham Deckhand

    Blog Posts:
    0
    This is one thought on how to add additional I/O chips. PIA ACIA VIA etc.
    note that the Atari 6520, is pin compatiable with the 6821
    Previously posted on Atari Sector but this is my own work, although I'm sure others including Tim have described something very similar (adding an UART.)
     

    Attached Files:

    Timothy Kline and M.D.Baker like this.
  5. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    _________

    I'm looking forward to checking out the PDF, Graham, and welcome to the Atari Owners' Club! Your name has popped up from time to time amongst the potstirrers here so it's great that you found the place, although it's still dusty and creaky. :rolleyes:

    Everyone has their white whale when it comes to the Atari home computer. Mine were simple from the very start: 80-column, minimum to do anything more serious than gaming and so-so educational-friendly; stereo sound; local area networking.

    The first two I've checked off the list with the VBXE and stereo mods coming onto the Atari 8-bit scene by the time I jumped back into the 8-bit 3 or so years back.

    I'm especially hopeful for FujiNET, of course, because at least it would be networking for the 8-bit, right? AND it has the distinct advantage of being non-invasive as far as bringing a new feature-set to the Atari 8-bit home computer, making it available to even non-modders. :cool:

    I'm always skeptical of SIO-based options because of the way the SIO works— stopping all other SIO traffic until whichever device is done with it. :shifty:

    Mind you, there is a wi-fi cartridge for the Atari 8-bit on the scene, and a cartridge-based LAN option, maybe? Dragoncart, I'm thinking. But there you go again: you drop that Dragoncart into your system to get networking and you want to run a Basic XE-based program because of it's built in advantages when it comes to utilizing the additional memory banks so now what? :facepalm:

    A PBI-based networking option would be ideal for the simple reason how often would it be competing with any other device? It would also have the option to operate directly with every chip. No intermediary SIO chip or PIA to hamper communication— a bona fide environment for the demands of LAN operations! :cigar:

    In my mind, the untapped option for someone who's comfortable with modding (RAM upgrades, chip changes and mini-board additions like the U1MB and VBXE, for examples) is a second PIA since its design lends itself to 8-bit class networking, with available IRQs on-board to use as switches for RX and TX. But, the PIA option is the most-invasive, requiring not only internal modifications, but case cutting, too! :jawdrop:

    Where I fall on my face is how to build the cabling to network two 8-bits and NOT fry something. At that point, it seems like all that would remain is to develop the software, right?

    In my head, I see an Atari 800 being the ideal system for networking, which takes us back to case modifications. :meh:

    Ideal because it has 4 ports compared with later systems having 2. And I see an Atari 400 being used as a hub, since all it would need to run is the communication portion of the networking software to move data through the PIA ports (x4). Any communication routine shouldn't need to tax a 400's RAM capacity, I wouldn't think.

    I should also point out that there is a non-destructive route with the PIA option: limit the LAN to 2-bit traffic. In this scenario, all that would be required is the appropriate interface between two systems (for LAN gaming, for example) and the networking software.

    At first glance, the idea of pushing network data at the rate of 2 bits seems horrid but remember that we already have gameport-based modems and there was even Corvus hard drives. Both were, admittedly, slow for the amount of data that needed to be moved across those 2 available bits of the stock PIA.

    But set that aside for the moment to consider this: the 2-bit route would be ideal for LAN-based gaming, not full-on networking where one might move files across a network which would be better suited in a dual-PIA environment. Not that you couldn't move copious amounts of data across a 2-bit network (hah hah) ... it'd just be slow, but no more slow than the Corvus hard drive was, I imagine. And since I have no personal experience with one I have no real point of reference beyond the rare few individual who report the experience as being slow. Slow is relative. The Atari 1010 is slow when one experiences the speed of a 1050. And a 1050 is slow when you experience the speed of a MyIDE or SIDE2 cartridge. And how much of that speed will be mitigated by the fact that the traffic would be handled in the background via the PIA's own IRQs, for example? An SIO-based option won't be able to make that claim because things STOP with the SIO.

    Now, what if you have two gamers with their SIDE2 carts and their A8's and their interface cable? They each load the multiplayer game up, which loads the drivers to get them connected and networking.

    From that point forward, what data will need to be communicated between the two machines beyond a table of variables to exchange coordinates and other data-- along with a syncing byte of data for RTCLK drifting and variations between the two systems.

    Coordinates would likely be 3-4 bytes of data. X, Y, Z, and whatever. How long would it perceptibly take to move 4 bytes of data across a 2-bit PIA network? And from there, let's say that an 8-bit multi-player game has to exchange 128K of data. Data that includes game resources, for example, may need some elbow room. How long would it perceptibly take to move 128K of data between systems through an interrupt-driven communication driver? The game itself would simply operate from the same address bank of variables, right?, even though they're changing on-the-fly as the two systems go head-to-head.

    But, again... the cabling. What's the necessary interface to get the connection to the point where software can then take over? :banghead: I know not how to build such magical things! :oops:

    Because I'd like to think I can handle the software part and would love the opportunity to find out.

    Anyhoo, the ramblings of an old Atari owner,
    Tim
     
    Graham and Andy Barr like this.
  6. by Paul "Mclaneinc" Irvine
    Paul "Mclaneinc" Irvine

    Paul "Mclaneinc" Irvine Deckhand

    Blog Posts:
    2
    Whilst its not something I'm into I just love the fact people like Thomas Cherryholmes (think that is the spelling) are doing all these wonderful things, WiFi on an Atari, who would have thunk it.

    The only issue for me is that I find being with my router on gives me a headache over time and my face feels like its roasting, I have a mate who suffers very badly with this and has tried to have his new Smart meter removed as he can't even sleep properly now.

    Electromagnetic hypersensitivity (EHS) I believe is what its called.

    But that aside I love all these side projects to use these old machines as new, be it an Atari or Oric etc its so good that folks like yourself are taking them past what was thought to be their final frontier (I had to do it) and doing things that never exited back then.

    Good luck Tim and others....
     
    Graham, Andy Barr and Timothy Kline like this.
  7. by Graham
    Graham

    Graham Deckhand

    Blog Posts:
    0
    Wow that was a long post Tim. and about to do the same :)

    I'll add my thoughts. Firstly the SIO route is very limited due to the Serial Buss Speed, and would only ever be as high as any other High Speed SIO device. And of course stops anything else going on, due in main to it being 'Software driven' so can only go as fast as the combination of CPU and Pokey allows.

    You can by the way use MIDI as a networking transport, and allows I think 16 users all at the same time Network speed is 31-32KBit's have a look Here https://ataribits.weebly.com/midi.html

    Going back to networking, although I've not really looked at either of those described, I do have 1st hand knowledge of using both the ESP8266 & its bigger brother the ESP32 for networking sensors and controllers around the Home.

    To be able to use a Wi-Fi connection that follows the current protocols in general use would tie up a 6502, and be very slow, however by adding a secondary Serial or Parallel port that squirts data back and forth to one of these chips is a good way to use the ESP chips power to run the say TCP/IP or HTTP etc. 'stack'

    The Atari, only commanding the unit to select the protocol, and then the data, the send and reply being dealt with by the ESP, and providing the data back to the Atari. The ESP acting as a buffer.

    I would guess a modern produced VIA would be the best route to add 65c22 as has the addition of two timer counters above and beyond the 65c21 (6821 or 6520 PIA) at a pinch the ACIA 65c51 adds a full proper UART with baud rate generation etc.

    I still think the VIA is a better option though. I'll have a look.

    whatever way is chosen both code for the ESP and for the Atari is required, I wouldn't put myself as a competent programmer in 6502, a bit better C or Assembler on AVR chips. (A little bit with the ESP added to Arduino's IDE.

    Really though I'm a hardware man.
     
    Timothy Kline likes this.
  8. by Graham
    Graham

    Graham Deckhand

    Blog Posts:
    0
    Paul I've heard of EHS but thankfully never experianced similar, I guess lucky as I've worked on many projects from high Power AM/FM broadcast transmitters and lowered powered DAB to Mobile phone base stations, including my home built RF amplifiers to bounce VHF radio signals off the moon. (and a really big antenna array needed)

    Nothing Atari there though ...
     
  9. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    Graham and M.D.Baker like this.
  10. by Graham
    Graham

    Graham Deckhand

    Blog Posts:
    0
    I've had a look at this and I don't really understand why he made it so awkward an upgrade. Nor why he chose not to use the 2nd Port on the additional PIA, it makes no sense to add something and not use it.

    Peter's ATR image maybe of some use however.

    For an 800, whatever way you upgrade it, you have to be able to get the new port lines out, that means in general metal work, the only other way would be to mash up the plastics in the left cartridge port area and have something there. Personally a hole in the left side of the metal screen, going out to the empty area within the left side of the computer with either case mods or cable slotted through the existing grills.
    I'll also mention that Incognito may mess with this although out seems outside the address range I'll have to check
    When I'm back on my feet I'll have a go with the BOOT ATR in Altirra.
     
    Last edited: May 21, 2020
    Timothy Kline likes this.
  11. Graham

    Graham Deckhand

    Blog Posts:
    0
    I've been finding out a little more about some of the upgrades that are usually added, U1MB & Incognito both use Additional address registers for there own use at D380-D3FF in addition they also expose RAM, When PBI ROM is enabled, 895 bytes of I/O RAM are also exposed: 191 bytes at $D100-D1BE, 192 bytes at $D500-D5BF, and 512 bytes at $D600-D7FF. These bytes are from dedicated memory not otherwise accessible due to being shadowed by the I/O address region. When I/O RAM is active, these address ranges are blocked. ( So I guess no problem adding hardware here as the I/O line will not be active whilst the PBI BIOS uses the area as RAM)
    VBXE also has registers at either D640-D65F or D740-D75F so limitations here.
    SIDE/SIDE2 MYIDE etc, use D1xx
    Cartridges SIDE2, OSS, SPARTADOX and many others can all use areas of D5xx
    I've found all of this information in Avery Lee's Altirra Hardware Reference Manual.

    With this in mind I'll re design my circuit to make sure the region D380-D3FF is decoded so that inadvertant writes cannot affect the control registers used by the U1MB & Incognito, so allowing an additional PIA or more to be used in upgraded machines.
    Still not myself at the moment so lots of reading and only a bit of taking pictures and occationally online.
    Not even tried the PokeyMAX out I've had it 3 days or so, got so far and needed some rest.
     
    Timothy Kline likes this.
  12. M.D.Baker

    M.D.Baker Deckhand

    Blog Posts:
    2
    I am on the edge of my seat @Graham , awaiting on you then for my PIA upgrade in the 800. I wasn't planning on a PIA upgrade this round anyway. Right now it's just Incognito, stereo Pokey, and outputs for stereo Pokey and video out the back. Round two would involve making a PBI and the PIA upgrade with extra ports. Round 3 will be a Sophia 2 and a VGA port (DVI is out of the question, for me, as pixels are forced to be square with DVI which means screens not in the proper aspect which is unacceptable to me), but the Sophia 2 was just announced on AA and is not available yet.
     
  13. Graham

    Graham Deckhand

    Blog Posts:
    0
    I'll make sure I get around to it :)
    This attachment is incorrect since I've been reading as I need to add A7 address line to make sure the D380-D3FF region is decoded, any writes to this ouside the U1MB BIOS or PBI BIOS needed to be disabled and this hasn't been. I've just ignored them..
     

    Attached Files:

    Timothy Kline and M.D.Baker like this.
  14. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    This is where I wish I knew and understood more about electronics and how things work at the hardware level.

    But I do have a recurring question maybe someone can explain in a way I can wrap my head around...

    When it comes to piggy-backed chips, such as POKEY, for example, and you write to an address... isn't that address shared by both chips? How does one access the piggy-backed chip over the chip piggy-backing it? Wouldn't accessing both of them generate results, output-wise?

    I'm not even sure I'm asking the question right, but I don't understand how one accesses the top chip in any sort of isolation from the one it's piggy-backing since both utilize addresses in common.

    I'm always confused on this.

    --Tim
     
  15. M.D.Baker

    M.D.Baker Deckhand

    Blog Posts:
    2
    With piggy-backed Pokeys, or any dual Pokey board, only a very select few pins are shared by the second chip, and the 74LS chip used with the upgrade allows them to work together and not step on each other's toes. It definitely wouldn't work if all the pins were connected to each other. The rest is all software driven. Now like you with hardware, I'm that way still with software (though I'm learning), but my understanding is the second chip has it's own addresses programmed.
     
  16. Graham

    Graham Deckhand

    Blog Posts:
    0
    Hi Tim
    Yep the second, piggy backed chip, say Pokey, will have a common clock, data and control lines except the Chip Select, likewise all Pokeys 'port' lines such as audio, keyboard scan, and interupt, are left disconnected, the Chip select line for the piggy back chip has additional logic to select the original or the secondary Pokey, usually address line four A4
    So with this either high or low it selectts the original Pokey, or the piggy backed one depending on the address. I'm out at the moment so can't check the lines but I'll try and write something up, thats easy for people to understand
    The second Pokey as a stereo only addition obviously has its Audio routed out the computer, If you wanted to the keyboard lines could be repurposed for something else a secondary keyboard or something else as you have a few lines that could be controlled separately if you wanted to. Just need the software to issue the commands to the new register addresses in the second Pokey.
     
    Timothy Kline likes this.
  17. by Timothy Kline
    Timothy Kline

    Timothy Kline Administrator Staff Member

    Blog Posts:
    3
    Articles:
    39
    So, with a second PIA... will the second PIA have its own address, then? Otherwise, how would someone access it on the software side?

    --Tim
     
  18. M.D.Baker

    M.D.Baker Deckhand

    Blog Posts:
    2
    Same thing; every new chip installed has it's own addressing. Piggy-backing is just easier sometimes than building a support board for the new chip(s)
     

Share This Page