Network via SIO

[gpounce]

Back in the day I experimented with a peer-to-peer joystick port network on my 800, I never got it to be really satisfactory- but seeing the still-active Atari mod/demo community got me thinking about it again.   I still have my 800XL and homebrew SIO cable, I have a few concepts related to writing a 'N:' device handler that would permit multiple Atari systems to exchange multiplexed data units via the usual IOCB subsystem; no usr() calls- everything through the usual I/O functions.

 

The idea is to use SIO2PC cables connected to a linux box that is only smart enough to be a sort-of switch eg; it knows ttyUSB0 is station 1, ttyUSB1 is station 2 and so on, such that a block addressed for 2 is queued for output on ttyUSB1.   There are some compromises; some queueing is needed since the Atari systems will have to poll but I think the concept would be sufficient to do things like burst I/O between two systems, or use DOS to copy a disk file over the network to another station which receives it and writes to its own disk and so on.   The network is more like a message broker system, so reliability and in-order delivery are guaranteed by the datalink so as to keep the device handler as small as possible.

 

Clearly its desirable to have a disk emulator built into the linux end, which seems like its turning that box into a file server and I/O hub.   A little Pi would be perfect..

 

I'm aware of the Atari ethernet and the Multidash/Unconventional 2000 approaches, which are cool- my itch is to make a solution that works on top of standard SIO protocols and SIO2PC using the simplest possible server end.

 

I've always wanted to do something with the interrupt/proceed lines on the SIO port but sadly my DIY SIO2PC cable doesn't connect those pins- neither do the standard ones IIRC.   Getting back to the Atari is a nice change of pace from the brutal complexity of modern software.

 

Regards,

 

Greg

 

[Kyle22]

6 hours ago, gpounce said:

Back in the day I experimented with a peer-to-peer joystick port network on my 800, I never got it to be really satisfactory- but seeing the still-active Atari mod/demo community got me thinking about it again.   I still have my 800XL and homebrew SIO cable, I have a few concepts related to writing a 'N:' device handler that would permit multiple Atari systems to exchange multiplexed data units via the usual IOCB subsystem; no usr() calls- everything through the usual I/O functions.

 

The idea is to use SIO2PC cables connected to a linux box that is only smart enough to be a sort-of switch eg; it knows ttyUSB0 is station 1, ttyUSB1 is station 2 and so on, such that a block addressed for 2 is queued for output on ttyUSB1.   There are some compromises; some queueing is needed since the Atari systems will have to poll but I think the concept would be sufficient to do things like burst I/O between two systems, or use DOS to copy a disk file over the network to another station which receives it and writes to its own disk and so on.   The network is more like a message broker system, so reliability and in-order delivery are guaranteed by the datalink so as to keep the device handler as small as possible.

 

Clearly its desirable to have a disk emulator built into the linux end, which seems like its turning that box into a file server and I/O hub.   A little Pi would be perfect..

 

I'm aware of the Atari ethernet and the Multidash/Unconventional 2000 approaches, which are cool- my itch is to make a solution that works on top of standard SIO protocols and SIO2PC using the simplest possible server end.

 

I've always wanted to do something with the interrupt/proceed lines on the SIO port but sadly my DIY SIO2PC cable doesn't connect those pins- neither do the standard ones IIRC.   Getting back to the Atari is a nice change of pace from the brutal complexity of modern software.

 

Regards,

 

Greg

 

Go for it.

:)

 

[gozar]

I had this idea too. The hardware is easy, it's the software that needs to be written. Besides a disk emulator, I could see three other devices to add.

• A modem device for BBSing or connecting to the Linux box as a terminal.
• A raw network device for things like games, give each Atari its own IP address through the Linux box.
• The other would be a REST translation device, allowing the Atari to use various APIs out there. The Linux box would take care of the network and SSL side of things. This would allow things like a Twitter client.

[gpounce]

Yeah I'm working up the linux back end now in C++11.   I wrote dos and windows disk emulators back in the day and read off all my old floppies to save them- all that stuff is in my archive so I'm taking bits and pieces from the emulator sources.   I had a lot of difficulty getting the SIO timing to be stable on Windows even with realtime threads- its such a mess of an OS the scheduling latency would jump all over the place whenever anything happened on the gui, regardless of priority.   I expect Linux will do a lot better.

 

The win is likely to be a small relocatable driver on the Atari end- something that could entirely fit in page 6 for instance.   Network I/O block size will probably have to be fairly small to keep the footprint down.   For brevity, I'm thinking of an 8 bit station #, assigned by the server end which each Atari unit can query- that makes for convenient use in the aux parameters of the IOCB open/xio commands.   station 0 is for administrative queries against the server, 255 as broadcast to all stations, not sure yet how to cleanly obtain source address and protocol identifiers from receive messages.. a peek associated with each each stream's rx buffer would work but is kind of ugly.  xio status/note/point seem like the right sort of functions for that and to poll for queued rx packets but theres a lot to do before finalizing these points.

 

I wouldn't be surprised if something like "open #1,0,0,"n:192.168.1.100:80" could be used to open a bidirectional TCP link to the given address & port, with the Linux back end handling the IP.

 

[TheMontezuma]

Perhaps you can consider the API I defined for TCP/IP socket communication over SIO:

http://abbuc.de/~montezuma/Sio2BT Networking.pdf

 

More Info:

There are some code examples here:

http://abbuc.de/~montezuma/SIO2BT.zip

 

[ClausB]

Cool project!

In the day I built a less ambitious SIO network. At PDI, too much of my job was typing endless DATA statements of questions and answers for our Atari educational programs. Then I had to repeat it for our Apple and C64 versions. Instead I built a one-way serial network from the Atari to the others and transmitted the DATA statements. Increased job satisfaction! (I don't recall whether the Atari end was on the SIO port, an 850, or a joystick port. I do recall adding diodes and resistors to adapt to the other systems' serial ports.)

[gpounce]

@dragonstomper - your IOCB ops are very close to what I was thinking of, conforming to them makes sense to me.  From reading over the pdf's, I have the impression the api is designed for bytestream eg tcp service, exchanged blockwise- I see the connect, send, receive semantics but none for listen/accept.  

 

I had been thinking peer-to-peer would be block and message based but generalizing the IPC to be simple localhost tcp on the back end makes a lot of sense... simpler too.  I could see an open command ID that would set up the back end for listen/accept, with polled status indicating connection.   Not sure how to integrate UDP so as to support recvfrom() multiple and broadcast xmits mostly due to packet size issues... maybe some kind of segmentation would work but sounds icky.

 

[gpounce]

 

I've made a bunch of progress on the software end, getting the disk support to where I want it.   For test images I'm using the holmes collection along with my own much smaller one (150 disk images).   SD and DD support is working, and I support pc xformer, and the 4 variations of ATR formats and my old diy format from years ago.  There is a command-line interface to handle enable/disable of emulated disk devices for each of the ports connected to the Atari consoles, as well has handle mounting and unmounting images on the emulated drives.   There is provision for searching, and classification of images into collections.  Similarly, each image has a write-protect state, and provisions for making disk images read-only.   One interesting property of the system is that multiple consoles can be connected and a given image mounted on each- obviously there is no method of preventing contention but it offers interesting possibilities.

 

Before I dig into the network device driver I'd like to get the disk support into a more final state. 

 

- I see a wide variety of ATR sizes, some smaller than the given disk image- my emulator assumes 0 filled sectors to the end of the disk- that seems straightforward and works.  There are claims of some images using > 128 octet sectors where the 1st three are full-size.  I have provisions for configuration overrides to handle these cases, but am wondering how often they are seen.

 

- I'm also wondering what variations are seen in the PC Xformer format eg if & how different sector sizes are implemented.

 

So this counts as yet another Atari disk emulator- though I view that feature as a convenience to aid development.   The complete indexing of large libraries for easy searching and concurrent support of multiple consoles might make it useful.   In any case I'll release it as GPL open source if there is interest- or at least when the networking features are working.  I call it "a3s"- 3rd of my atari server- the previous two were dos and Windows.  

 

It runs as a daemon or as a foreground application in Linux.  Cygwin on Windows, Mac OS should be straightforward.   The BSD's and Solaris should also work- all the platforms need only a fairly recent gcc and a couple standard libraries.  I've been thinking a small Rasberry PI box with enough USB ports for several consoles would be a nice form factor.

 

 

[tschak909]

I am currently doing the same, for ESP8266 devices, making an SIO based network adapter:

http://github.com/tschak909/atariwifi

 

right now, I am still getting the SIO timing correct, but once I get the test programs working stably, it will progress swiftly.

 

Goal is to have disk (D:) and RS232 (R:) emulation, in addition to an N: device for TCP/UDP/HTTP comms.

 

-Thom

[gpounce]

Cool :)    I'm having good luck with 2ms delays between the SIO handshakes, and a byte-wise framesync for the commands using the checksum.   Took me a while to figure out which dos version to run to support double-density.. but its stable now.  The goal for my network device is Atari peer-to-peer not so much interfacing with TCP/IP.  What disk formats are you supporting with your D:?

 

 

[tschak909]

ATR and XFD initially. ATX support is part of SDrive-MAX, so I may be able to glean the logic from that.

 

I'm still trying to get timing working well:

 

-Thom

[gpounce]

Slowly closing in on finishing the disk support.  I'm completing details relating to creating new images, metadata write-protect vs write-protect set in the ATR header and so on.   I tracked down RWTEST to do some benchmarks, I'm getting

 

DOS writing  1493 B/sec

DOS reading 1613 B/sec

DOS average 1553 B/sec

 

on a (c) 2016 rev of RWTEST running on '83 vintage DOS 2.6f on the 800XL.   This DOS has a drive speed option in the menu, which reports 778rpm - its certainly loads faster than a 810/1050.

 

My host system is a x86_64 core2-duo linux machine, a3s doesn't noticeably touch the cpu when serving sectors so its nowhere near cpu-limited.   I'm using 1ms delays between the ack/complete/sector transfers.   Dropping below that seems to overrun the XL, so this looks like a local maximum in the performance space.

 

[gpounce]

On 11/7/2019 at 11:19 PM, tschak909 said:

ATR and XFD initially. ATX support is part of SDrive-MAX, so I may be able to glean the logic from that.

 

I'm still trying to get timing working well:

 

-Thom

 

I had some timing related issues similar to that, mostly was due to not honoring minimum delays between command & ack, and complete & data.   I ignore the command signal and instead framesync the commands using the checksum byte (my SIO cable does not connect command).   Concur that in a daisy chain situation honoring the command signal is important.

 

[tschak909]

Yup, I managed to get timing right enough to boot jumpman from the internal flash.

 

 

With this code:

https://github.com/tschak909/atariwifi/blob/master/atariwifi.ino

 

I am now borrowing a protocol that was developed by the Spectranet people (it being a network adapter for the ZX Spectrum) to do file serving, it is documented here:

http://spectrum.alioth.net/svn/filedetails.php?repname=Spectranet&path=%2Ftrunk%2Ftnfs%2Ftnfs-protocol.txt

 

and am making a test program to fetch blocks and, for now, return them over the debug channel. once my protocol state machine is working I will hook it up to the SIO test code and see if I can boot from the network.

https://github.com/tschak909/atariwifi/blob/master/tests/tnfs/tnfs.ino

 

-Thom

[gpounce]

I like that TNFS- having been down deep in NFS I profoundly appreciate its simplicity!   For this purpose it seems as if it could be implemented for disk-sector size I/O blocks, maybe not even implement the directory functions, though something directory-like to permit some kind of image search and selection from the atari would make sense.  Given the relative speed of the wifi and (presumed) PC on the back end and your device, the backoff protocol might be skipped as well though I would expect the block sequence numbering & perhaps retry to be important.

 

 

[ivop]

+1 to TNFS. We talked about network boot before and BOOTP/TFTP was deemed too simple, and FTP, NFS, SMB was too complex. Seems like this sits right there in the middle. Plus side is that some clients and servers are already written (ZX Spectrum, tnfsd). Wouldn't it be nice to boot your Atari over WiFi, served by a ZX Spectrum   Could be something for Atari Invasion and/or the Spectrum day in Maarssen

[tschak909]

@ivop This is exactly what I am doing. I am making the ultimate Atari Network Adapter.

 

The plan:

 

the "D:" devices can either be disk images, or a directory (synthesized to look like a disk)

the "R:" device provides a modem emulation

the "N:" device provides TCP/UDP/HTTP, and control of the adapter (to mount images, establish connections, etc.)

 

I can do it all, but it would be nice to get some help. as my arduino code is, most definitely naive.

 

-Thom

[gpounce]

I've been doing a bunch of work on the a3s software; SD and DD working, xex, atr and xformer images all working with the various disk sizes they implement.   I'm polishing, debugging, enhancing the command interface to get closer for a release.  I started the N: driver I want to write.   The open & status handler entries are working as expected but I'm finding the close vector is not being called; eg

 

OPEN #1,4,0,"N:XYZPDQ" turns into a call to the open vector and I perform an SIO transaction to the server to set up the network connection, STATUS #1 calls the status vector and I can do a SIO status transaction to fetch that info- but CLOSE #1 doesn't call the vector.   I am returning NOERR in Y from all these routines.  From looking at the various docs it seems like I should get a call thru the close vector so I assume I'm omitting some detail.   Any hints would be much appreciated...  thanks!

 

Greg

 

[tschak909]

1 minute ago, gpounce said:

I've been doing a bunch of work on the a3s software; SD and DD working, xex, atr and xformer images all working with the various disk sizes they implement.   I'm polishing, debugging, enhancing the command interface to get closer for a release.  I started the N: driver I want to write.   The open & status handler entries are working as expected but I'm finding the close vector is not being called; eg

 

OPEN #1,4,0,"N:XYZPDQ" turns into a call to the open vector and I perform an SIO transaction to the server to set up the network connection, STATUS #1 calls the status vector and I can do a SIO status transaction to fetch that info- but CLOSE #1 doesn't call the vector.   I am returning NOERR in Y from all these routines.  From looking at the various docs it seems like I should get a call thru the close vector so I assume I'm omitting some detail.   Any hints would be much appreciated...  thanks!

 

Greg

 

@gpounce This is a prototype CIO driver that i've done in "C"

https://github.com/FujiNetWIFI/atariwifi/tree/master/tests/cio5-interrupt/atari/src

 

p.s. you should be joining forces with us.

 

-Thom

 

[gpounce]

Hi Thom,

 

Yeah I will be hooking up with you all, just need to get the server into a more final state so I have something to offer.  I intend to integrate a service that fujinet can mount, sio2bt xio conformance, maybe support for a couple of the emulators.   I'm not much interested in running emulators but it sure would be handy to have a couple running do do compiling etc.   A3s offers support for any # of "stations" ie atari systems concurrently in use, disk index searchable for description, filenames, collections.  Right now its supporting the entire Holmes collection (10,000+ images), there are some oddball images on there for sure.   It runs out of a tty using textual commands so can scale to multiple systems and many disks a lot more easily than the click-and-drool interfaces.  Still have to add "all station" support eg mount a given disk on all stations with one command and so on.    Eventually it would be nice to cleanly support faster pokey divisors but thats a ways off.

 

Greg