PIA-Based LAN for the Atari 8-bit

[Timothy Kline]

Good morning, Atari owners!

 

Considering how Corvus, MPP, the XEP-80, and a few others capably demonstrate using the PIA of the Atari 8-bit's joystick port as more than a game controller interface, I've been wondering for quite a while how I might cobble together a way to connect two or more Atari 8-bits together for purposes of a token ring or LAN.

 

I know that there are SIO-based and MIDI-based options available for similar functionality— but in my scenario I see an Atari 800 being used as the AtariLAN server, given its four ports. This would allow 1 to 4 "slaves" to be connected via PIA, or, using an Atari 400 as a "hub," 3 systems to be directly connected to the A800 and three to each additional A400 added into the LAN.

 

To my simple-minded way of thinking, and lack of electronics experience, I picture this having the double-ended DB-9 cable as the network cable, and data transmission then handled by the driver (running as a VBI or DLI interrupt to check for flags indicating network SND/RCV packets available for transmission) and the software (to act as an emulated IOCB that can be accessed either at ML or BASIC levels), as well as an appropriately-sized buffer in memory to handle streamed data.

 

Data would be handled in 255-byte (??? <--I'm throwing a number here for illustrative purposes) blocks for purposes of transmission, dumped to the buffer for access by BASIC or ML programs. Software driver options would be: half-duplex (1 PIA pin set to receive and 1 PIA pin set to send) or duplex (2 pins, bi-directional but either read or write and the faster throughput option).

 

The XL series would be limited to Port 2, leaving Port 1 available for the user, unless a second PIA was installed along with the required DB-9 port. Since PortB in the XL series is used for memory management, that seems to establish the A800 as the go-to for the role of server.

 

Is this possible outside of my imagined concept? And what would I need to establish the "network" cables? Lastly, how would I integrate LEDs to have a visual indicator of when data is being sent in which direction?

 

Thank you, in advance,

Tim

 

 

________________

References:

 

http://atariage.com/forums/topic/260244-were-atari-8-bit-joystick-ports-designed-to-be-bi-directional-serial-ports/

http://atariage.com/forums/topic/226123-xep80-working-now-what/

http://atariage.com/forums/topic/66380-pia-port-question/

http://atariage.com/forums/topic/252010-bit-bang-serial-rs232-output-via-joystick-pin-porta-bit-0/

https://en.wikipedia.org/wiki/1-Wire

(Second PIA installed in Atari 8-bit)

Images:

Above: Atari XEP-80 Pinouts

Below: Atari XEP-80 Schematics

 

[Rybags]

A major use for such a thing - games.

 

The problem with using PIA - you're occupying at least 1 joystick port which leaves only 1 for a controller on most Ataris.

The other problem - likely you'd be wanting to send a fair number of bytes per frame which means you're using CPU cycles that might be otherwise needed.

Though there's nothing wrong with using DLIs or timer IRQs to drive the IO.

 

Going beyond 2 computers - can get tricky, then you're doing token ring which means a fair proportion of the traffic you're handing isn't even for your own use - plus you'd probably be splitting the available pins in half as you're talking to 2 other computers instead of just 1.

Edited May 14, 2019 by Rybags

[Timothy Kline]

A major use for such a thing - games.

 

The problem with using PIA - you're occupying at least 1 joystick port which leaves only 1 for a controller on most Ataris.

The other problem - likely you'd be wanting to send a fair number of bytes per frame which means you're using CPU cycles that might be otherwise needed.

Though there's nothing wrong with using DLIs or timer IRQs to drive the IO.

 

Going beyond 2 computers - can get tricky, then you're doing token ring which means a fair proportion of the traffic you're handing isn't even for your own use - plus you'd probably be splitting the available pins in half as you're talking to 2 other computers instead of just 1.

 

I'm not convinced there'd be that much data that would be on the LAN at any given point so as to cause any disruptions.

 

To use your example of a multi-box game LAN:

 

Each station would have its own storage system (let's say a SIDE/2 or Ultimate Cart), and the A800 would operate as the server (and, ideally, be capable of acting as a... fifth player ) handling the data that would need to be transferred between the stations (players' positions, assets, score, etc etc., all of which really breaks down to variables (bytes of data) on the PIA lines. There are even two IRQ vectors (VPRCED, VINTER) that are unused yet seem particularly ideal for this type of project, although I think they might be tied to SIO rather than PIA.

 

By the time you add up the number of variables that would be needed for a multi-box game, even if there are 100 variables, even as double-byte (16-bit) values, we're still only talking about 200 bytes of information that would be coming and going on the network in realtime. At some point it would get bogged down, but I can't figure how, let's say, 10 networked systems would be moving more than 2K of data IF someone was passing so many variables. Much more likely, 10-25 variables/values would be the expected operating range. Four stations = 50 bytes (16-bit) of data per station (not including bytes for flags and transmission blocks).

 

In the case of a file transfer, of course, a half-duplex would allow incoming network data to continue while outgoing network data would be paused while the peer-to-peer transfer takes place; full duplex would pause incoming traffic so that both pins could be used to perform the file transfer more quickly, and then resume SND/RCV at that point.

 

BASIC programs would utilize the network as an N: device set up through the IOCB or something similar, but operate from the buffer allocated during configuration similar to how BASIC can use shadow registers to get at hardware registers.

 

--Tim

[JoSch]

That's about the hardest problem in game development: Multiplayer over network.

There are things like timer drift, delays, synchronization etc.

I don't want to discourage you, I like the idea. But you have to consider such things.

Such communication protocols tend to escalate in size.

And, if you are already squeezing cpu cycles into a DLI, you probably have not much time to get the network packets and(!) process them.

[Timothy Kline]

That's about the hardest problem in game development: Multiplayer over network.

There are things like timer drift, delays, synchronization etc.

I don't want to discourage you, I like the idea. But you have to consider such things.

Such communication protocols tend to escalate in size.

And, if you are already squeezing cpu cycles into a DLI, you probably have not much time to get the network packets and(!) process them.

 

All valid points, and especially the DLI comment, and I'm leaning toward VBI deferred being the better route in a gaming LAN, while a "static" Graphics 0 or VBXE-80col mode could offer some DLI hooks for networking in, for example, a business network or Point-Of-Sale network.

 

But before any of that, I still need to know what is required to make the cabling work-- preferrably with inline LEDs for visual reasons. If it can even be done, I mean.

 

I mean it has to be something that works along the lines of an old LapLink cable or null-modem cable (only in a DB-9 cable), right?

 

--Tim

Edited May 14, 2019 by Timothy Kline

[TGB1718]

If memory serves me right, you will have to buffer any output from the Joystick ports as I believe they can only

drive 1 TTL load, I made a Centronics Parallel Port printer interface for my 800 back in the 80's and occasionally

got some bad characters, so I just used a couple of 74 series buffer chips, I only used 7 bits of data as I needed

'ACK' handshaking, this was ok as the printer was only used in ASCII Text

[Forrest]

The PIA project seems like a big project - both hardware and software.

A simpler approach is MIDI - now that Mytek has released the SIO2MIDI board. The 2 port board can be built for $15 each (and $6 of that is for the 5 pin DIN jacks). MidiMaze supports up to 16 computers - so MIDI seems up to the task. k-Pack has MIDI information at http://atariage.com/forums/blog/572/entry-13705-a8-midi-and-the-atari-age-of-rediscovery/

[Timothy Kline]

The PIA project seems like a big project - both hardware and software.

A simpler approach is MIDI - now that Mytek has released the SIO2MIDI board. The 2 port board can be built for $15 each (and $6 of that is for the 5 pin DIN jacks). MidiMaze supports up to 16 computers - so MIDI seems up to the task. k-Pack has MIDI information at http://atariage.com/forums/blog/572/entry-13705-a8-midi-and-the-atari-age-of-rediscovery/

 

At some point I may give the MIDI/SIO-based method a look, given I have enough MidiMazes here.

 

But I'm especially intrigued with the PIA's potential as used by Corvus to provide hard drive storage and the XEP-80 likewise making use of the PIA's capabilities as an I/O device. There's the parallel printer projects that run through numerous Atari user magazines and books pushing the PIA past its baseline D-R-U-L circuit closure detection from joystick interfacing, as well as MPP and a couple other modems that turn that port into an I/O completely isolated from POKEY's own duty roster. Actually, I'm not certain if the modems utilize PIA or POKEY for their operation, but in either case the DB-9 port provides direct access to the I/O plane of the A8 mainboard, if I understand it correctly, similar to how the PBI provides direct lines to the entire system for peripherals.

 

I find that fascinating, and am especially intrigued with adding a second PIA chip specifically for networking and having the option to wire it to the type of plug that would let me use a standard, modern day ethernet cable— mounted into the case (1200XL in my case, no pun intended).

 

But first I want to use what Corvus, Atari's XEP-80, and the others had to use and pulled off so well. Then, hand the work off to a second PIA at a later date.

 

The problem is that I am neither an engineer nor an electrician, and thankfully not ignorant enough to just go ahead and connect two systems together with a p2p joystick cable minus PIN 7 with its +5V to "see what happens." I've asked some people I converse with and a couple others here on AAge via PM, and now am here hoping that someone knows how I will want to go about doing so in a way that stages me for the software aspects. Or a schematic?

 

Appreciating the responses, so thank you everyone for your time.

 

--Tim

Edited May 14, 2019 by Timothy Kline

[ivop]

IMHO the main disadvantage of using the PIA to connect computers together is that you have to bit-bang your bits to PORTA, which is very CPU intensive. Even a few bytes per frame can be a drain on resources. Consider the fastest connection with an XEP-80 is 19k2. The computer can't do much more during transmission of data.

 

On the other hand there's MIDI (or any SIO serial based ring) where you can utilize the serial IRQ's to send 8-bits at the time. Or the new Dragon Carts/PBI/whatever and a hub

[Timothy Kline]

IMHO the main disadvantage of using the PIA to connect computers together is that you have to bit-bang your bits to PORTA, which is very CPU intensive. Even a few bytes per frame can be a drain on resources. Consider the fastest connection with an XEP-80 is 19k2. The computer can't do much more during transmission of data.

 

On the other hand there's MIDI (or any SIO serial based ring) where you can utilize the serial IRQ's to send 8-bits at the time. Or the new Dragon Carts/PBI/whatever and a hub

 

Absolutely spot-on about the bit-banging which would be required of the CPU, ivop, but I'm wondering if that could be handled through a second PIA once I managed to get something going with the original PIA? An add-in PIA would be able to handle the workload without the bit-banging, wouldn't it?

 

--Tim

 

PS. I LOVE the concept of a DragonCart, but because it is cartridge-based, it automatically kills us Atari owners who use SIDE/2s, MyIDE2s, and any other cartridge. I haven't considered whether the WiFi cartridge would be feasible for similar reasons as DragonCart.

Edited May 14, 2019 by Timothy Kline

[Sugarland]

It's a great idea. Why not use a modern device for the server and/or switch? Also since the DragonCart or Bus devices preclude all other cart options anyway, it seems like a reasonable route. If your 'lan' software works over both DB9 or Dragoncart, or uses his the dragon driver as an option, it would be flexible... In otherwords, the network would be device independent and not rely solely on the DB9 ports.

Edited May 14, 2019 by Sugarland

[flashjazzcat]

An add-in PIA would be able to handle the workload without the bit-banging, wouldn't it?

I lack knowledge when it comes to networking protocols, but I think nothing short of a co-processor would relieve the CPU burden. Any number of PIAs still require the CPU to bang their bits.

[gozar]

It's a great idea. Why not use a modern device for the server and/or switch?

This is the idea I had. A computer with a USB port for each 8-bit, and each 8-bit using a simple SIO2PC-USB. The server computer would be able to address each 8-bit individually, booting the machines, allowing communication between 8-bits, and supplying network access.

 

The hardware is already done, only software needs to be written.

 

Along the same line, it would be cool to write the software for a Pi to mimic an XEP-80, along with additional graphic modes. Joystick port would probably not be fast enough for games, but it would be for 80 columns.

 

 

Sent from my iPhone using Tapatalk

[Mathy]

Hello gozar

 

The main chip inside the XEP80 (the NS405) will do as many colors as you want. Read all about it on my special stuff page (including the data sheet).

 

Sincerely

 

Mathy

[gozar]

The main chip inside the XEP80 (the NS405) will do as many colors as you want. Read all about it on my special stuff page (including the data sheet).

 

 

The problem with the XEP80 isn't the lack of color or the slowness, it's the difficulty in finding a monitor that will work with it. I have one old green screen CRT that allows me to use my XEP-80: http://atariage.com/forums/topic/226123-xep80-working-now-what/?p=3003936

 

An XEP-80 Emulator running on a Pi Zero would be a lot more useful. :-)

[Kyle22]

I lack knowledge when it comes to networking protocols, but I think nothing short of a co-processor would relieve the CPU burden. Any number of PIAs still require the CPU to bang their bits.

Sorry, no on the 2nd (or any) PIA. You would just bit-bang the 2nd PIA at its own address. That's why POKEY has register SEROUT/SERIN $D20D where you can read/write a byte and the chip does the rest without using extra CPU cycles.

 

Edit: I should add Co-Pro with its own PIA would be perfect if you want to do it with PIAs.

Edited May 15, 2019 by Kyle22

[Timothy Kline]

 

The problem with the XEP80 isn't the lack of color or the slowness, it's the difficulty in finding a monitor that will work with it. I have one old green screen CRT that allows me to use my XEP-80: http://atariage.com/forums/topic/226123-xep80-working-now-what/?p=3003936

 

An XEP-80 Emulator running on a Pi Zero would be a lot more useful. :-)

 

I use an amber Magnavox 80 with my XEP-80 and apart from the slow flow of the text (which isn't that slow most of the time), they work swimmingly together.

 

My understanding where the XEP-80 is concerned is that its slow display output was the fault of the XEP-80 itself, and not because of a bottleneck where the A8 fed the XEP-80 its data. Bit-banging two pins of the PIA must've been more than up for the job as far as streaming what the XEP-80 needs— as a proof-of-concept in utilizing the PIA as a proto-LAN interface for the Atari 8-bit.

 

For gaming, I see a second PIA in the future, much like a second POKEY provides certain quality-of-life improvements for us Atari owners.

 

Again, looking at where contemporary LAN interfacing has evolved, gamer computers usually offer dual LAN connections to get down to some serious data streaming and networking. A second PIA would provide a much more expansive interface by allowing the bit-banging to become moderated through the provision of 8-bit values exchanged intact— a significant performance improvement for our 6502, I suspect.

 

I think FJC makes a valid point, the bit-banging required may very well make such a notion unfeasible.

 

Without a way to connect the two systems, it's moot.

 

--Tim

[Timothy Kline]

Sorry, no on the 2nd (or any) PIA. You would just bit-bang the 2nd PIA at its own address. That's why POKEY has register SEROUT/SERIN $D20D where you can read/write a byte and the chip does the rest without using extra CPU cycles.

 

ZZTop Soft's topic (which I forgot to include in my footnotes in the original post) has him working with a second PIA installed:

 

http://atariage.com/forums/topic/254008-add-extra-pia-800xl/#entry3538365

 

If I'm understanding you, it wouldn't make a difference as far as data throughput when a second PIA is in play in the XE/XE series Ataris to provide an additional port (lost as Port B to the MMU on the original PIA on XL/XEs).

 

--Tim

 

___________

 

[Rybags]

An idea to reduce the data requirements for a game - if the same game on 2 computers has them exchanging controller input and collision information (the 2 players might have different viewports) and the game uses software generated random numbers with a shared seed then in theory the game could be written to remain in sync with that bare minimum of information exchange.

[Kyle22]

Yeah. No matter the address of the chip, it's still a PIA, so you must bit-bang it to get serial I/O.

[Timothy Kline]

Sorry, no on the 2nd (or any) PIA. You would just bit-bang the 2nd PIA at its own address. That's why POKEY has register SEROUT/SERIN $D20D where you can read/write a byte and the chip does the rest without using extra CPU cycles.

 

Edit: I should add Co-Pro with its own PIA would be perfect if you want to do it with PIAs.

 

Glad I caught the edit, Kyle22, about the Co-Pro...

 

So, using ZZTop Soft's schematic, one would take the 74LS138 out of the picture and go to a 6502 instead (as connected in the primary PIA to the on-board 6502, I mean). But doesn't that still leave the problem of data throughput/bit-banging? And what changes would need to be made according to his schematic?

 

--Tim

[Curt Vendel]

Actually it should be possible to do an RS422 Drop Network through the 2nd joystick port.

 

Server could be set as ID 1 and others as 2...255 IDs for the slaves.

[Timothy Kline]

Actually it should be possible to do an RS422 Drop Network through the 2nd joystick port.

 

Server could be set as ID 1 and others as 2...255 IDs for the slaves.

 

This is what I found that might be helpful to the discussion, then...

 

https://en.wikipedia.org/wiki/RS-422

https://en.wikipedia.org/wiki/9-Pin_Protocol

https://en.wikipedia.org/wiki/AppleTalk

 

The section on Appletalk was very interesting to me, with the following snippets especially:

 

"the entire networking stack required only about 6 kB of RAM, allowing it to run on any Mac."

 

"The system was designed for future expansion; the addressing system allowed for expansion to 255 nodes in a LAN (although only 32 could be used at that time), and by using "bridges" (which came to be known as "routers", although technically not the same) one could interconnect LANs into larger collections. "Zones" allowed devices to be addressed within a bridge-connected internet. Additionally, AppleTalk was designed from the start to allow use with any potential underlying physical link."

 

"The main advantage of AppleTalk was that it was completely maintenance-free. To join a device to a network, you simply plugged the adaptor into the machine, then connected a cable from it to any free port on any other adaptor. AppleTalk's internal protocols negotiated a working network address number, automatically gave the computer a human-readable name, and collected up a list of the names and types of other machines on the network so the user could browse the devices through the GUI-based Chooser. AppleTalk was so easy to use that ad-hoc networks tended to appear whenever multiple Macs were in the same room.^[15] Apple would later use this in an advertisement showing a network being created between two seats in an airplane."

 

From the 9-Pin Protocol, I noted the following as interesting:

 

"It uses an DE-9 D-Sub connector with 9 pins (hence the name), where bi-directional communication takes place over a four wire cable according to the RS-422 standard. The communication parameters are 38,400 baud, 8 data bits, odd parity and 1 stop bit (38k4/8O1)."

 

That RS-422 began on a DB-9 also caught my attention:

 

"The most widespread use of RS-422 was on the early Macintosh computers. This was implemented in a multi-pin connector that had enough pins to support the majority of the common RS-232 pins; the first models used a 9-pin D connector, but this was quickly replaced by a mini-DIN-8 connector. The ports could be put into either RS-232 or RS-422 mode, which changed the behavior of some of the pins while turning others on or off completely. These connectors were used both to support RS-232 devices like modems, as well as AppleTalk networking, RS-422 printers, and other peripherals."

 

AppleTalk sounds very similar to what I'm picturing for this AtariLAN or AtariNET notion, for sure, as a protocol or basis for one.

 

--Tim

Edited May 15, 2019 by Timothy Kline

[+mytek]

All of these methods via the PIA would require a lot of CPU cycles. However you could do as Curt suggested, but do it by hanging a real UART off the main bus or via the PBI. The RS422 aspect is simply a differential transceiver that would interface to the UART, just converting the TTL level signals. If you want to stay within the 6500 series family the UART could be a 6551 ACIA. Here's an article about using one of those: http://www.6502.org/users/andre/icaphw/c64ser.html

 

Jameco still sells them for about $6 (Jameco P/N: 43318). Jameco also sells the RS422/485 transceiver chip (Jameco P/N: 1371604). They have datasheets for each.

[Dropcheck]

The problem with using the 6551 is that it has no buffer of it's own, so any data coming in would have to be handed off to the 6502 for processing immediately or loose it. Now you are back to tasking the 6502 again.

 

Actually the article is about replacing the 6551 with a 16550 UART. Better perhaps, but still CPU intensive.

 

Maybe a better option would be to have an arduino handle the networking and have it feed and take information to and from the Atari via the serial bus. At least then the 6502 isn't messing with the networking framework, only the data. You might need to write a handler though.