Testers needed: AtariSIO with USB / standard serial ports

[HiassofT]

I recently implemented support for USB serial adapters and standard serial ports (like eg on RPi) in AtariSIO.

 

This means atariserver and atarixfer can also be used on non-x86 platforms and with serial ports other than 16550/16950.

 

On x86 PCs with a 16550/16950 serial port it is still (and always will be) recommended to use the kernel driver as it offers a lot more features and is more reliable than the new userspace implementation.

 

It's still very early days but so far things are looking quite good: atariserver worked with pokey divisor 0 on a FTDI SIO adapter and on an RPi2 with the simple "SIO2PI" levelshifter interface, atarixfer could access a 1050 Happy and Speedy in highspeed with these setups as well.

 

Some features of the kernel driver, like XF551 mode or FSK (copy protection) support in CAS files, will probably never make it into the userspace implementation because it's next to impossible to get the very tight timing right.

 

I've uploaded a first preview of the new version here:

http://www.horus.com/~hias/atari/atarisio/testing/atarisio-181019.tar.gz

 

To compile it you need the usual C development tools in linux plus the ncurses and zlib development packages. Eg in Debian/Raspbian just run this command to install those:

sudo apt-get install build-essential libncurses5-dev zlib1g-dev

Then to compile and install AtariSIO withot the kernel driver run these 2 commands in the unpacked AtariSIO source directory (of course you can also use the usual "make" / "sudo make install" procedure on x86 to also build the kernel driver):

make tools
sudo make tools-install

To use atariserver and atarixfer with a USB or standard serial port you have to start it with the "-f /dev/ttyXXX" option (note: this option has to be the very first options, all other options have to be set after these) or set the ATARISERVER_DEVICE and/or ATARIXFER_DEVICE environment variables. eg

atariserver -f /dev/ttyUSB0 -S 0 mydos.atr

By default atariserver will expect the command line to be connected to RING, to use DSR add the "-c" option, to use CTS add "-C" and if you don't have any command line and want to use the less reliable "no command line" mode add "-N".

 

Note: on RPi both the standard UART /dev/ttyAMA0 and the miniuart /dev/ttyS0 have support for RTS and CTS lines on GPIO pins, but these are disabled by default. I've included devicetree overlays to enable these in the contrib/rpi directory. Just copy these to /boot/overlays and then add either "dtoverlay=uart-ctsrts" or "dtoverlay=miniuart-ctsrts" to your config.txt. RTS is then available on GPIO 17 (pin 11 of the 40-pijn GPIO header) and CTS on GPIO 16 (pin 36 of the GPIO header). RTS is essential for using atarixfer (you need a command line to talk to a 1050) and CTS is nice to have because with a command line atariserver will work more reliable.

 

To connect a 1050 to the RPi you have to swap the TxD and RxD lines on the level shifter, connect RTS through the level shifter to the command line of the SIO port and connect the +5V output on GPIO pins 4 or 6 to the +5V line of the SIO port (a 1050 needs both, +5V input to detect the presence of an Atari and a command line).

 

Then you can create an ATR image of the floppy in your 1050 with eg this command ("-S" enables Happy/Speedy highspeed transfer - remove it if you have problems)

atarixfer -f /dev/ttyAMA0 -S -r my.atr

To write an ATR to a floppy use the "-w" option. eg:

atarixfer -f /dev/ttyAMA0 -S -w my.atr

It would be great to get some feedback about these new features, what works and what doesn't work, and I'm pretty sure there'll be some rough edges or bugs in this rather new code. Even if everything works fine on your setup I'd be glad to read a "works fine" or similar line to know about that :-)

 

so long & happy testing,

 

Hias

Edited October 19, 2018 by HiassofT

[lemiel]

My tries with 16550 ended over six years ago, this comp still stays turned off on my desk but RPi and FTDI is much more interesting option for now. RPi 1 will be enough to try?

[HiassofT]

Yes, AtariSIO will work fine on an RPi1. Just tested atariserver on an RPi(1) B+ and it worked both with the on-board UART and an FTDI dongle.

 

If you have an original (non-plus) RPi1 with the 26-pin GPIO header then the CTS signal won't be available (GPIO 16 is used for the activity LED) so the uart-ctsrts dtoverlay won't work as expected. CTS and RTS can be routed to the 8-pin P5 pads though with a modified overlay (change uart0_ctsrts_gpio16 to uart0_ctsrts_gpio30 in the dts).

 

so long,

 

Hias

[E474]

Hi,

 

I will try and give this a test, but I think I have an original RPi. I have to sit down and figure out which SIO pins go to which Pi pins, then see if I have that configuration already, and also have a go at the 10502Pi interface.

 

Thanks for updating your programs!

[dl7ukk]

Hi,

 

kannst Du bitte Deinen ersten Beitrag noch(mal) in deutsch schreiben, würde gern beim Testen behilflich sein.

 

Danke!

 

Andreas

[HiassofT]

Hallo Andreas!

 

kannst Du bitte Deinen ersten Beitrag noch(mal) in deutsch schreiben, würde gern beim Testen behilflich sein.

Ja, klar, ich poste dann (vermutlich morgen) mal eine Kurzversion im ABBUC Forum.

 

so long,

 

Hias

[HiassofT]

I uploaded a slightly updated version today:

http://www.horus.com/~hias/atari/atarisio/testing/atarisio-181025.tar.gz

 

This version fixes issues building the kernel module on older (eg 4.4) kernels and adds 2 more device tree overlays for the older RPis with 26-pin GPIO header:

 

uart-rts enables the RTS line on GPIO 17 (pin 11 of the header). GPIO 16 (which is used for CTS in uart-ctsrts) isn't available on the older RPis, that GPIO is used for the ACT LED.

 

uart-ctsrts-p5 enables the CTS and RTS signals on the P5 pads (CTS on GPIO 30 / pin 5, RTS on GPIO 31 / pin 6). Note: pin numbering on P5 is swapped left/right compared to the GPIO header, pin 1 (marked with a square on the PCB) is on the outer row, not the inner one like on the GPIO header.

 

With uart-rts you'll get the necessary RTS line for 1050-2-PC mode and can use the "no-command-line" mode for SIO2PC with all signals being on the GPIO header.

 

so long,

 

Hias

[HiassofT]

I didn't get much feedback here but fortunately dl7ukk helped me a lot with testing - see the thread on the German ABBUC forum for details http://www.abbuc.de/community/forum/viewtopic.php?f=3&t=9715

 

So, first of all: thanks a lot, Andreas!

 

Most issues seem to be ironed out and here's a link to my latest version: http://www.horus.com/~hias/atari/atarisio/testing/atarisio-181113.tar.gz

 

Please have a look at Changelog and READMEs, I changed a few command line options, reworked current docs and documented the new features.

 

AtariSIO seems to be working fine now with USB FTDI interfaces, Lotharek's SIO2PC USB and 1050-2-PC/SIO2PC USB interfaces and the RPi onboard UART, down to pokey divisor 0.

 

atarixfer also worked fine reading from / writing to Happy, Speedy and 1050 Turbo drives in highspeed mode - 1050 Turbo drives have rather strict timing requirements, you need to manually enable strict SIO timing mode (even at standard speed) which may not work with all interfaces / USB controllers (connecting a FTDI interface via a USB2.0 hub often helps).

 

so long,

 

Hias

[HiassofT]

Before I get too many questions here's a short summary of the changes in AtariSIO and test results buried in the ABBUC thread. The (FTDI) USB test results are probably helpful to AspeQt/RespeQt users with an FTDI based SIO2PC interface as well.

 

If you connect the USB serial interface directly to a PC with USB 2.0 ports you'll get rather large latencies - about 1ms roundtrip time on EHCI USB 2.0 controllers with an UHCI USB 1.1 companion (eg Intel chipsets) and about 2ms on controllers with an OHCI companion (eg AMD chipsets).

 

While the 1ms is okay-ish, the 2ms is too long to reliably detect command frames at tha highest speeds, as the command frame can be shorter than check interval. The solution to that problem is rather easy though: connect the USB adapter via an USB 2.0 hub (then USB transfer will be handled by the EHCI controller) or connect it to a USB 3 port - then faster microframe USB scheduling will be used an the latencies are a lot lower. The USB controller on the Raspberry Pi is fine, too.

 

The internal oscillator of the FT232R (eg used in the Lotharek SIO2PC interface) doesn't seem to be too great, the internal oscillator of the newer FT-X chips (eg in Lotharek's 1050-2-PC/SIO2PC interface) or the external oscillator of old FT232B chips are a lot better.

 

As 125kbit/sec (used by AspeQt/RespeQt and AtariSIO test versions) is very near the limit of what PAL Ataris can handle slight variations in speed can cause transmissions to fail. Again there's a rather simple solution, reduce speed a bit - current AtariSIO versions use ~124kbit/sec for Pokey divisor 0 and slightly reduced speeds for divisor 1-4 as well.

 

When testing 1050-2-PC mode with the RPi's on-board UART and GPIO connection/level-shifter I noticed occasional issues at highspeed. The reason for this was that I forgot to add a (4k7) pull-up resistor on the SIO data in line like it's present in Atari computers. Some level-shifters have built-in pull-ups (to do level up-shifting) but mine didn't... Yeah, stupid mistake.

 

The Raspberry Pi specific on-board UART / GPIO things are now documented in README.RPi - please read this, most questions should already be answered there.

 

I've changed the highspeed mode options in atarixfer a bit so it's now possible to enable XF551/Happy Warp and Happy/Speedy Ultra Speed/1050 Turbo modes separately. Therefore the example from the first post is no longer correct, instead of "-S" you now have to use "-s 2". eg:

atarixfer -f /dev/ttyAMA0 -s 2 -r my.atr

I also added a tool to switch the Lotharek 1050-2-PC/SIO2PC interface from SIO2PC mode (which it's in after powerup) to 1050-2-PC mode. See README.lotharek for details.

 

so long,

 

Hias

[HiassofT]

Today I released an official version of AtariSIO with the enhancements discussed above on my website http://www.horus.com/~hias/atari/#atarisio

Direct link to the latest version: http://www.horus.com/~hias/atari/atarisio/atarisio-190111.tar.gz

 

No major changes since the last testing version, mainly documentation and other minor cleanups, but if you update from earlier versions of AtariSIO please have a look at the Changelog and README, a few command line options and other things have changed.

 

A big thank you to all who helped with testing or provided feedback, especially dl7ukk, you helped me a lot!

 

so long,

 

Hias

[Pob]

I've just started using this instead of SIO2BSD on Raspberry Pi.  I've managed to hack an old version SenorRossie's WebGUI for SIO2BSD to work with it.

 

It's working great for XEX and ATR files.  I was hoping to get CAS files working at a decently fast speed, but I couldn't get more than 125% speed up on the ones I have tried.

[HiassofT]

2 hours ago, Pob said:

I was hoping to get CAS files working at a decently fast speed, but I couldn't get more than 125% speed up on the ones I have tried.

This is about to be expected. The cassette routines in the Atari OS only allow a bit of variation in speed.

 

Back in the old days there a couple of "Turbo Tape" systems existed (most of them requiring modification of the cassette recorder) but these are not implemented/emulated in AtariSIO.

 

so long,

 

Hias

Edited July 13, 2019 by HiassofT

[ivop]

Perhaps you should check out Mr. Atari and his MyBIOS. If I'm not mistaken, he has some code incorporated to load normal CAS files at about 5000 baud. Perhaps even faster. Can't remember. Obviously this needs an altered OS on the Atari side, but that's easily done these days with U1MB or other multi-OS extensions.

Edited July 13, 2019 by ivop
MyIDE-OS is called MyBIOS :)

[DKONGsr]

Hi there, I am fairly new user here, but did use my Atari 800XL quite intensely back in the 80s.

I have a question relating to atarixfer on x86 PC with an FTDI dongle - hope this is the correct topic - if not I am sorry.

So I have actually started playing around with it and so far was pretty succesfull, everything seems to be working and I had some fun time programming Basic, like it's 1984!

Also the atarisio set of tools let me recover most of my old disks using atarixfer (I only had a 1050 stock drive) and was able to use those on a self programmed SIO device using an atmega pro micro. So all i s good to perfect - thanks a lot for the great programs. So I can confirm that they work as advertised, without kernel driver and cheap dongle. atarixfer with dtr, atariserver without any handshaking.

Now I wanted to make my SIO device a little bit more user friendly (I know there are tons of nice options out there, but for me the fun part is basically understanding how it works and not really using it in the end....) so I thought it should be possible to use atarixfer to get data to my SIO emulator, just to make debugging easier an not having to hook up the Atari for that  - this however does not work at all, so maybe someone can give me a pointer what goes wrong I have a few Ideas after going through quite some research of the SIO protocoll.

Some very old manual I found (Atari Home Computer System Serial Input/Output Interface User's Handbook) had the timings but claimed (in a flowchart) that an 'N' is sent when the device is wrong (I suspect that would cause trouble if every hooked up device tries to do that prertty much at the same time the correct device tries to send 'A'...) - so I was not too sure how reliable the information is. Then the Altirra manual has a nice section with pretty much the same timing information abou the rest. So going from here I think the timing should be like: (A: Atari, D:Device) A: pulls down command, sends 5 bytes and raises CMD within 650-950µs (the OS however is qicker but cmd should go HIGH again) , then some time (1-16ms) ist left for from D: to reply

As far as I can tell that is already where the communication goes wrong. If I am not mistaken, atarixfer does not raise the command again - I can log several tries with a command 4E and then several for a status byte - however I loose all timing information, since my only point of reference is the starting point of pulling cmd low - the serial port from the atmega has a buffer, the rest could have arrived any time after that. I did not do a very thorough investigation, but an LED at the cmd line turns off, then the data comes and after the atarixfer times out with two failure messages (percom and status) the LED lights up again. So I  suspect that maybe using the DTR from the FTDI as command does not even allow correct use as command?

I am just a little bit stumped why the original Disk Drive works like that?? (now unfortunately I have one more source of uncertainty, I transferred my disks from a different computer and now had to compile atrixfer again using the latest release - but have no acces to a 1050 any more... but I have tried atariserver from the same package with the real Atari and that still worked fine)

 Anyways nothing depends on this I am just curious, so if someone has an idea, woud love to hear it.

One little thing I noticed: Maybe add the hint in the README that ATasm needs to be installed, I tried 

apt-get install build-essential libncurses5-dev zlib1g-dev

But failed first - all I had to (Debian) do was also to

apt-get install ATasm

Thanks again to HIAS for the great work.