PIA-Based LAN for the Atari 8-bit

[flashjazzcat]

Sorry, no on the 2nd (or any) PIA. You would just bit-bang the 2nd PIA at its own address.

 

That's exactly what I said.

[Timothy Kline]

That's exactly what I said.

 

I wasn't clear if that was the case if a second PIA was brought into the equation, but I certainly agreed with you as far as the primary PIA was concerned because I know that half the primary PIA is taken by the MMU in XL/XE systems.

 

I think it was Kyle22's mention of the address issue that clinched it, because I didn't think much about that I'd still be dealing with a single address— instead, I was thinking, well, having a second portB to work with a second portA would solve the bit-banging and open things up to either moving more bits at once, or, ideally, allowing a single byte to be exchanged at a time, which seemed more than sufficient to pass an 8-bit value across a network thus decreasing the amount of machine cycles required to break data down into a single bit or pair of bits for data exchange.

 

In my over-simplifying head, I picture how the Atari can PEEK and POKE values, so what can be so difficult about PEEKing and POKEing data on the primary PIA's Pin 1 and 2 for data from another system? If the server POKEs a value to that address, how do I help a connected system to PEEK that value from the address at its end... is where I am stuck. Setting aside the issues involving synchronization, data flow control, and the like for purposes of breaking things down to the core need, I mean.

 

The other part that was/is tripping me up is that by introducing a second PIA which would offer a secondary pair of Ports (Port A and Port B), I still wouldn't be able to move a single byte even though it looks like there would be 16 bits available according to ZZTop Soft's 2nd PIA schematic. But that's where my ignorance of engineering and electronics begins to show, I'm sure. O.o

 

--Tim

Edited May 15, 2019 by Timothy Kline

[JoSch]

Your only chance to not bit-bang the second PIA is if you had some kind of co-processor, which would DMA the data to the PIA, like the Antic does for the screen.

Edited May 15, 2019 by JoSch

[Timothy Kline]

Your only chance to not bit-bang the second PIA is if you had some kind of co-processor, which would DMA the data to the PIA, like the Antic does for the screen.

 

Seems logical enough, given the comments provided so far.

 

But how to go about that on an Atari 8-bit seems to be the million-dollar question... does this mean someone would need to simply adapt ZZTop Soft's schematic for a second 6502 in lieu of the 74LS138 being used to switch between PIAs?

 

Intrigued and curious,

--Tim

[Rybags]

For what it's worth, the 32in1 OS switcher actually shares bit 7 of PORTB with SelfTest ROM - the menu sends commands serially to the PIC using it. So it wouldn't be out of the question "borrowing" some other bits though that means internal modding of your machine.

 

A second PIA - you'd get 16 bits of IO as well as the 2 bits that normally go to motor control and command, and the 2 bits which are Interrupt inputs.

 

So, you could have a byte at a time with one of the other bits as "strobe".

 

Naturally, the 2 computers wouldn't be frame locked, or might even be a mix of PAL/NTSC machines. You'd probably want double the amount of "checks" per scanline vs the number of bytes you want to transmit but the overhead e.g. for 20 bytes per frame shouldn't be too huge.

[Timothy Kline]

For what it's worth, the 32in1 OS switcher actually shares bit 7 of PORTB with SelfTest ROM - the menu sends commands serially to the PIC using it. So it wouldn't be out of the question "borrowing" some other bits though that means internal modding of your machine.

 

A second PIA - you'd get 16 bits of IO as well as the 2 bits that normally go to motor control and command, and the 2 bits which are Interrupt inputs.

 

So, you could have a byte at a time with one of the other bits as "strobe".

 

 

Well, that's pretty much along the lines of what I was thinking, but I'm no longer sure because of FJC's and Kyle's observations, and have to defer to those who have the experience.

 

 

 

Naturally, the 2 computers wouldn't be frame locked, or might even be a mix of PAL/NTSC machines. You'd probably want double the amount of "checks" per scanline vs the number of bytes you want to transmit but the overhead e.g. for 20 bytes per frame shouldn't be too huge.

 

My thoughts run along these lines (because of the potential for PAL and NTSC machines to somehow be on the same LAN):

 

Since I know nothing about clocks and signals, rises and falls of current, and so on, I thought concocting a frame counter (FC) similar to the 6502's program counter (PC) would be an ideal way to keep things synced reasonably well, including the starting FC as part of the data block that gets transmitted at the start and at the FC at the end of the transmission. The starting and finishing FCs would establish the "drift" likely to arise, and allow it to be factored into the process.

 

Again, I'm oversimplifying the actual process to make an illustrative point, hoping I'm making sense.

 

--Tim

[+DrVenkman]

Not to beat this dead horse any further but to avoid sucking all the 6502 cycles, again why not just a MIDI-based network? You can plug it into any Atari 8-bit, it’s got an internal chip (a cheap and tiny PIC in Michael’s implementation) and transfers data plenty fast. MIDI-Maze is exactly what you’re talking about: a multi-player networked game that exchanges state data frames across the network with minimal system overhead.

 

I just don’t get the obsession with a second PIA and all the processor overhead that entails.

[Rybags]

Got to agree. I'd put a secondary requirement in that the device should be multifunctional - ie able to interface with other equipment and/or be able to do some sort of processing assistance. Like if it's a PIC then maybe some sort of FMUL/FDIV capability.

[danwinslow]

For my 2 cents, I think that an external component or add-on board of some sort is required here. Midi is a serial connection as far as I know (which isn't all that far), obviously works well enough for midi-maze but if it's significantly different from just SIO I don't know how. My experience with attempts at direct SIO networking lead me to believe it's not a good solution, especially for things like game traffic. Even when supported by an external TCP stack with an SIO interface, it just doesn't cut it for stuff like action games. Maybe if supported by a really fast SIO implementation it could work, but I never tested with anything above the standard SIO speeds commonly available. I would like to see a PBI device with a co-processor, thus avoiding the SIO part. On the device you could have a bare chip like the cs8900a or one of the available all-in-one TCP stack chips. The PBI device would directly drive the chip and would support bus-speed access to the data packets. If someone made the hardware, I'd gladly try to write a driver.

 

PIA networking is a cool idea, but I think a lot of the comments about available CPU are valid. I also think that if it were really possible and worked well, then somebody would have done it by now.

Edited May 15, 2019 by danwinslow

[Timothy Kline]

Not to beat this dead horse any further but to avoid sucking all the 6502 cycles, again why not just a MIDI-based network? You can plug it into any Atari 8-bit, it’s got an internal chip (a cheap and tiny PIC in Michael’s implementation) and transfers data plenty fast. MIDI-Maze is exactly what you’re talking about: a multi-player networked game that exchanges state data frames across the network with minimal system overhead.

 

I just don’t get the obsession with a second PIA and all the processor overhead that entails.

 

I may very well end up having to go the MIDI-based route, and I wouldn't shed tears over it, being quite content with being able to peer-to-peer or workgroup systems together for non-game software.

 

At the risk of taking this PIA-based discussion off-topic, though, it has been my understanding since coming back on the Atari 8-bit scene a few years ago that SIO-based solutions are directly impacted by things like disk reads/writes or similar where timing/clocks demand the full attention of the POKEY. Since MIDI saddles on with SIO, isn't it subject to the same halt issue? For example, system #2 is reading from its floppy drive-- so the MIDI has to go into standby until SIO releases the lines again— in effect, preventing the system from communicating with the MIDI-based network. And if you have several systems on a MIDI network, all performing their disk reads and writes at diverse times, then it seems like this would impact the throughput of the data stream on the MIDI-based network.

 

A PIA-based LAN would bypass the issue, it seems, by staying off the POKEY's duty roster entirely, and thus free from halts for disk i/o or similar. A second PIA would provide greater bandwidth for a LAN, with the caveat being a second 6502 to handle the bit-banging required in a 16-bit PIA configuration. At least in my head. lol

 

Do Corvus drives, since they operate from a PIA-based connection, instead of POKEY-based, offer any insight into the advantages (or DISadvantages) of keeping the PIA data line separate as an I/O interface, since people who have/had Corvus drives likely had floppy drives (SIO) going, too. What happens(happened) at a machine cycle level when someone would copy a file from an 810 over to the Corvus drive, or vice versa? Did this consume all or a significant chunk of the 6502's time?

 

--Tim

Edited May 15, 2019 by Timothy Kline

[Rybags]

Another consideration for a multiplayer game on seperate monitors that probably hasn't been explored and can be done with existing hardware:

VBXE can generate 2 independent displays, the GTIA only one and the GTIA + VBXE display.

 

VBXE can be configured such that the GTIA output is masked (invisible) behind the VBXE graphics which gives the ability for 2 different displays.

 

Of course it's a limited audience and the graphics generation for the same thing is different which means more programming but it's an idea worth looking at.

[danwinslow]

Kurt Vendel might have some info about low-level corvus stuff, I know nothing about it, except that it had it's own add-on board in one of the 800 slots, which very well might have had buffering and a co-processor of some sort...maybe even a PIA...?

 

*edit*

 

I was thinking of the ADS Integrater http://atariage.com/forums/topic/182024-corvus-interface-ads-integrater/, that's the board, but it allowed BOOTING from the corvus. Here's some info on the actual interface, which was a separate device :

 

The Corvus Hard Drive system exploited a little used ability of the powerful interface ports on the Atari 800 computer system. While almost everyone else was using the interface ports for plugging joysticks into and playing games. Corvus Systems used a very simple interface using about a dozen gate-chips to communicate with the PIA interface through joystick ports 3&4 of the Atari 800. Using a specially modified version of Atari DOS 2.0d (most users only had access to DOS 2.0s) or using an OS replacement board by David Small (Creator of MagicSac Mac emulator for the Atari ST's) called "The Integrator" an Atari 800 computer could access and use the Corvus hard drive as 8 DS/DD disk drives. If "The Integrator" was used, the OS board could be set to boot off of the Corvus hard drive and no 810 disk drive would be necessary.

 

So I guess the ADS Integrater actually was a replacement for the external box.

Edited May 15, 2019 by danwinslow

[Timothy Kline]

Kurt Vendel might have some info about low-level corvus stuff, I know nothing about it, except that it had it's own add-on board in one of the 800 slots, which very well might have had buffering and a co-processor of some sort...maybe even a PIA...?

 

*edit*

 

I was thinking of the ADS Integrater http://atariage.com/forums/topic/182024-corvus-interface-ads-integrater/, that's the board, but it allowed BOOTING from the corvus. Here's some info on the actual interface, which was a separate device :

 

The Corvus Hard Drive system exploited a little used ability of the powerful interface ports on the Atari 800 computer system. While almost everyone else was using the interface ports for plugging joysticks into and playing games. Corvus Systems used a very simple interface using about a dozen gate-chips to communicate with the PIA interface through joystick ports 3&4 of the Atari 800. Using a specially modified version of Atari DOS 2.0d (most users only had access to DOS 2.0s) or using an OS replacement board by David Small (Creator of MagicSac Mac emulator for the Atari ST's) called "The Integrator" an Atari 800 computer could access and use the Corvus hard drive as 8 DS/DD disk drives. If "The Integrator" was used, the OS board could be set to boot off of the Corvus hard drive and no 810 disk drive would be necessary.

 

So I guess the ADS Integrater actually was a replacement for the external box.

 

That information was a massive contributor to this whole LAN idea back when I first came across it, actually. Only instead of drives, there would be stations viewed as drives for all intents and purposes, similar to how I can map network drives and using the IOCB as a template. The server becomes N1: in my notion, System 2 becomes N2:, and so on. Let the big-banging commence. O.o

 

Can you picture being able to boot "slave'd" Atari systems off the server, for example, when they didn't have a local boot drive?

 

--Tim

[Forrest]

If you want this project to be successful, you should also consider the cost of the hardware. Mytek's SIO2MIDI board is very inexpensive. I paid $50.22 for all the parts to build 3 assemblies. This includes the cost of the custom printed circuit boards and all shipping/handling and taxes.

 

You would need to add the cost of 1/2 SIO cable and a MIDI cables per assembly. A 10 foot midi cable is $2.69 from Monoprice.com

[+mytek]

If you want this project to be successful, you should also consider the cost of the hardware. Mytek's SIO2MIDI board is very inexpensive. I paid $50.22 for all the parts to build 3 assemblies. This includes the cost of the custom printed circuit boards and all shipping/handling and taxes.

 

You would need to add the cost of 1/2 SIO cable and a MIDI cables per assembly. A 10 foot midi cable is $2.69 from Monoprice.com

 

And I've tested with 25 foot cables, while still having reliable communications.

 

-----

 

BTW, another option would have been The Multiplexer, but someone would need the schematics and any firmware that was required in order to duplicate it. Since it's a Bob Puff thing, I doubt the info has gone public domain.

[+David_P]

There was a similar setup published on GEnie (I think); with both BASIC and ML routines to pass info. I think one version did a Token Ring sort of thing using ports 3 and 4 on the 400/800.

[Timothy Kline]

There was a similar setup published on GEnie (I think); with both BASIC and ML routines to pass info. I think one version did a Token Ring sort of thing using ports 3 and 4 on the 400/800.

 

I'd love to see the info, if it's published anywhere publicly accessible?

 

--Tim

[Mathy]

Hello guys

 

Re: CSS Multiplexer: IIRC Steven J. Carden has bought the last ones. And maybe the rights to it. But I'm not sure.

 

Re: LAN: Curt Wendel should be able to tell us more about Atari's Alan-K network interface.

 

Re: The XEP80 being slow: It isn't. Just like the hardware, Atari did a crappy job at the software for it. The interface is FAST. Check out some stuff Erhard Puetz found out, here on my special stuff page.

 

Sincerely

 

Mathy

[ricortes]

Just some loose ramblings. I thought the CCS Multiplexer was based on the 6526. In any case, the 6526 has a built in, after a fashion, serial port. Non standard if RS232 is the standard but fast in both performance and clock speed. I just bought some 14 MHz 6526 in QFP off eBay. I love the 6520 and have used it in a lot of designs, even serial at 19k, I just think if you are going to the trouble of adding a chip, the 6526 adds some features that make it a better choice.

 

There's also a lot of designs to allow for 8088 type chips to be used with a 6502, separate R/W thing. One of the cutest I've seen requires only a single 74LS00. I'm weak on the need for another serial chip being needed on our Ataris but if there was a real need, a 16550 would probably be the way to go. It has a ~16 byte buffer and current versions can send serial data at ~1 MHz.

 

I've thought for ease of implementation a standard block size would be the best way to connect computers. Something like the host always sends out 8 bytes and all slaves receive 8 bytes but make a decision based on the position of the byte. i.e. 0XXXXXXXX would mean the next 7 bytes are meant for drop 0. 1XXXXXXX means the next seven bytes are meant for drop 1 etc. It would require a little processing but the other 255 computers would just dump the buffer and go back to what they were doing if the block wasn't meant for them. Less then 16 bytes per block would be all handled by the 16550 chip.

 

Then there was Atari Zucchini.

[Timothy Kline]

I've thought for ease of implementation a standard block size would be the best way to connect computers. Something like the host always sends out 8 bytes and all slaves receive 8 bytes but make a decision based on the position of the byte. i.e. 0XXXXXXXX would mean the next 7 bytes are meant for drop 0. 1XXXXXXX means the next seven bytes are meant for drop 1 etc. It would require a little processing but the other 255 computers would just dump the buffer and go back to what they were doing if the block wasn't meant for them. Less then 16 bytes per block would be all handled by the 16550 chip.

 

 

This sounds similar to the information I was checking out per @Curt's mention of the "Drop Networking" back in Post #22 in method, at least.

 

--Tim

[ricortes]

 

This sounds similar to the information I was checking out per @Curt's mention of the "Drop Networking" back in Post #22 in method, at least.

 

--Tim

It would suffer from the lack of response, processor overhead, no interrupt, et al that people have mentioned if it wasn't done by either a co-processor or a serial chip with built in buffer like the 16650.

 

FWIW, I've run the MMP joystick type RS232 modem handlers at 1200 BAUD with a hacked cable and handler. It was usable by a regular modem, tested with Supra 2400 IIRC. I believe the handler has an interrupt set to sample the JS ~1000s of times a second so you don't lose characters. At even 1200 BAUD, interrupts were happening so often the function of the terminal program I was using was terribly lagged. That is a problem with just about anything based on bit banging w/o a buffer.

 

Possible to do something that works but not works well. Even POKEY is better because it can generate an interrupt every time it has an assembled byte ready. Only problem is it only has that one byte and some time before the second byte is assembled and overwrites that byte. The 6502 is excellent responding to interrupts quickly, but that isn't the slow part. The slow part is polling/timing assembling the JS bits back into bytes. You have to essentially have the 6502 multitasking with one of the tasks an extremely slow and inefficient process. Arduino or PIC could do a better job even since they enough RAM to buffer the output so the 6502 doesn't have to poll. Some implementations like Electrotrains ARM on the buss cart could really do the job well, but it is a little odd to throw that much power at this level of problem. Needs to throw a chip or processor made for it. Even the WiFi ESP8266 would be a good choice relative to bit banging and they are only a couple of bucks too.

[Kyle22]

B.I.T.D. (FTe) I was working on a Parallel Bus Z80-SIO and Z-80CTC setup. We didn't get very far with it, but it could have been nice. There MUST be a way to make these chips work together. There must have been something that Mike and I were missing.

[+mytek]

Kyle it would be great if you could someday give us a bit of history about the stuff you were working on at FTe, perhaps in another thread. I can't speak for anyone else, but I personally think it would be fascinating .

[+Stephen]

Kyle it would be great if you could someday give us a bit of history about the stuff you were working on at FTe, perhaps in another thread. I can't speak for anyone else, but I personally think it would be fascinating .

Kevin Savetz should do an interview.

[Curt Vendel]

Just reading this thread...

 

I think the better route to go would be to go off the PBI/ECI bus and build an 8530 based Appletalk compatible LAN interface.   There is more than enough documentation on the protocol, its just a souped up RS-422 network.   This would allow Atari's to be able to connect to Apple IIGS and older Mac machines.  A check of IC stocks shows over 9500 available for purchase, so they are still readily available and this would be the least complicated LAN design.

 

I personally would prefer Corvus Omninet but the protocol and command set are not as widely known and there are very few available devices to use where as the Appletalk products are still plentiful.

 

Or there is the WIFImodem device that plugs into a serial port.    I've posted up the schematics and Driver ROM to the Atari PBI Serial/Parallel board, so making a PBI serial port would be straight forward.

 

At any rate, we need to start focusing more on external expansion devices to plug into the PBI/ECI ports and not doing internal mods.