SIO2BSD turbo speed

[RockfordDash]

Hi there,

 

Like many others here I succeeded building virtual Atari drive using Raspberry Pi, level shifter and SIO2BSD. Works like a charm.

However, I'm curious to know if and how it is possible to boot ATRs at speeds higher than 19200 bps.

Is stock OS in Atari 65XE capable of higher transmission rates or do I need a driver, like HISIO.COM?

If driver is needed I can see it working for XEX, where auto boot loader can take care of installing it first and loading XEX next.

But how can I hijack boot process in Atari to make it talk at 2 or 3 times 19200 bps to my Raspberry Pi while booting ATR?

Maybe I'm missing something obvious. For example, can modded floppy disk 1050 boot games at higher speeds?

 

Thanks,

RD

[+Nezgar]

You can achieve this with a patched OS ROM.

 

Check out Hias' Highspeed SIO OS patch:

https://www.horus.com/~hias/atari/#hipatch

 

There is a pre-made patched XL/XE rev 2 OS with this patch, as well as a fast FP math pack: http://atariage.com/forums/topic/206880-130xe-reverse-option-key-for-basic/page-2?do=findComment&comment=3944284

[RockfordDash]

Thanks for the pointers, I think I saw those pages.

Just to be clear, I was hoping for a solution that would work on a stock Atari, no hardware mods.

Hias's patch gets wiped out on a cold reset, so I'm not sure how to use it to boot from ATR.

BTW, any speed increase over 19200 would be great, 2x or 3x. I'm not shooting for the moon.

Can unpatched OS do it?

[TGB1718]

Many moons ago, I resolved this by first using a floppy that I had written with the SIO driver for high speed, it prompted you when loaded

to put your 'boot' disk in, if the disk was formatted as high speed, it would use high speed SIO, if not, then normal boot.

 

If I remember correctly it could use almost any DOS if you had formatted the disk as high speed then install your preferred DOS later.

 

Warm start kept the high speed SIO, but obviously had to reload on a cold start.

 

I might have the code somewhere, but have so many degraded disks, having to clean heads after almost every disk.

[E474]

Hi,

 

I've always wondered if it would be possible to make either an XL translator type disk that included a patched hi-speed SIO OS, e.g. 400/800 OS for XL/XE that included the high-speed code, or even an XL/XE OS disk that included the high speed code, rather than requiring burning an EPROM or using a mod that provides writable OS slots/storage.

 

I originally used the sio2bsd package on a raspberry pi (plus homemade level shifter and SIO connector arrangement), but found it didn't support hi-speed transfer such as used by SpartaDos, etc. However, if you use atarisio/atariserver on a raspberry pi (recently released for the raspberry pi in January, I think), you do get high speed transfers with SpartaDos (if I recall correctly), and if you use Hias's patched XL/XE OS in, for example, one of the OS slots of a Sys-Check 2 card, you get high-speed transfer pretty much all of the time.

 

If you are using atarisio on an original RPI, you need to use the -N flag for no COMMAND line connection if you are only using the GPIO header pins.

 

See https://www.horus.com/~hias/atari/#atarisiofor more info on atarisio.

 

Hope this helps (out of town at the moment, so can't check any of the above).

[RockfordDash]

Thanks for all the info. This is what I suspected. It should in principle be possible to create a boot ATR that loads HISIO.COM and then asks for a next floppy image and continue by simulating boot sequence.

It sounds like you accomplished that with real hardware.

With SIO2BSD I can manipulate content of ATR that my Atari sees. I can inject code to patch OS after cold reset (that's an easy part, it's been done; AspeQt does it with auto boot loader).

The part I'm not clear about is how to best simulate/continue boot process after switching to high speed. I wonder if I need to write some small loader or attempt to jump to OS to reuse boot sequence.

 

At any rate, I played with SIO2BSD and even with HISIO.COM I was only able to read stuff at 2x normal speed. At 3x it errors out. Still, better then nothing. I don't think my 65XE has capacitors on SIO data in/out, but maybe I missed them.

Notes: I'm not using AtariSIO kernel driver for Raspberry Pi, but I suspect it is not needed at 2x or 3x speeds. SIO2BSD runs without command support. I didn't connect command line.

[HiassofT]

The easiest way to trigger another boot is to end the boot code with "SEC, RTS" instead of "CLC, RTS". A set carry flag means boot failed, the OS prints a "BOOT ERROR" message and then does another boot attempt.

 

I had a quick go at it and created a bootable ATR with the highspeed SIO patch (see attachment).

 

Concerning AtariSIO: you don't need the kernel module on the Raspberry Pi (it'll only work on a PC with 16550/16950 UARTs), just use atariserver/atarixfer with the /dev/ttyAMA0 serial port (similar to how you use sio2bsd).

 

so long,

 

Hias

hisioboot.atr

[RockfordDash]

Thanks a lot Hias. That's a great idea to force a reboot.

I used your hisioboot.atr with modified SIO2BSD where I chained two commands, with first mounting high speed driver and second mounting program to load.

I think with a little more tinkering I could eliminate "Press Start to boot..." message and just load next disk after short delay.

What doesn't work as well is turbo speed. No matter how much I tried playing with UART clock speed and bauds the highest I could go is 2x19200.

At the moment I don't know why faster rates lead to errors, I don't have any equipment to test. Still, 2x cuts time almost in half.

 

Thanks,

MK

[E474]

Hi,

 

Try using atarisio/atariserver instead, it seems to support much higher transfer rates than sio2bsd on the same hardware.

[HiassofT]

Here's the link to my current highspeed SIO development version, including source code, if you want to play with it: https://www.horus.com/~hias/tmp/hipatch-190407.zip

 

I had another quick go at it and implemented another bootable version (hisioboot-atarisio.atr) that'll automatically swap D1: and D2: via the AtariSIO remote control interface. This means you can simply put hisioboot-atarisio.atr in D1: and the ATR you want to boot in D2: and it'll automatically switch to it and continue booting that after the OS has been patched. Note that this'll only work with AtariSIO/atariserver, for other SIO emulators you'll have to adapt the code (hipatch.src is the main file, atarisio.src contains the code to swap drives on atariserver).

 

Concerning the RPi: make sure you use the full UART (/dev/ttyAMA0), not the mini UART (/dev/ttyS0) - the latter won't work well. On a RPi3 just use the "pi3-disable-bt" or "pi3-miniuart-bt" dtoverlay.

 

so long,

 

Hias

[RockfordDash]

Wow, that's an impressive piece of software, I overlooked atariserver before. Yes, this solution works with RPi well.

My intention is to run it in a headless mode and control it from a web server built for it.

The couple of things I was not able to figure out:

- can atariserver negotiate speed and drop down from say x4 to x3 if it encounters CRC errors?

- I can set speed using POKEY divisor, and it seems to be accepted, but how can I be sure it is being used; is there a logging option for timing?

 

This is the command line I'm using:

sudo ./atarisio-190313/tools/atariserver -f /dev/serial0 -t -t -t -s 1 -N -S 2 hisioboot-atarisio.atr -2 Zorro.atr -o trace.txt

 

Divisor as low as 2 seems to be working, at 1 things slow down to crawl, probably due to errors.

After going past 2x speed gains in loading time are getting smaller and smaller, but that's expected I suppose.

 

Thanks again, that's an amazing project.

[HiassofT]

If pokey divisors 1 and 0 aren't working check if there are really no caps on the SIO data lines in your XE. I'm not too familiar with all variations of the XE line, some seem to have them soldered on board, some directly to the SIO connector.

 

What kind of level shifter did you use and did you add a diode and pull-up resistor in the SIO data in path? If you have the diode you could try removing it (directly connect the level shifter to SIO data in), this won't allow other devices on the SIO chain to be used but helps with capacitive load on the SIO bus as data-in will be driven by a push-pull driver (instead of the open-drain driver you get from the diode).

 

Another thing you could try is adjusting the baud rates. When you choose a pokey divisor you'll get the baud rate used printed in atariserver's log window. You can manually select a (slightly) different baudrate by appending it to the divisor, separated by a comma - eg "0,125000" - this works both on the command line with the -S option and in the curses interface ("S" key). Test with 500 and 1000 baud above and below the nominal baudrate.

 

I recently lowered the baud rates for the highest pokey divisors a bit (eg from 125000 to about 124000 on divisor 0) as Lotharek's USB SIO2PC had issues with that. The currently used baudrates worked fine though in all of my tests (also tested on RPi3 with both PAL and NTSC 800XLs).

 

Automatically downshifting the baudrate / divisor won't work. The highspeed SIO implementations on the Atari query the drive for it's speed on the very first access and then stick to that (some implementation, like mine, do an auto-fallback to standard speed in case of errors).

 

Atariserver doesn't show the currently used baudrate, but you can manually enable additional logging by setting UTRACE_MASK in tools/UserspaceSIOWrapper.cpp - setting it to 0x08 will notify you about baudrate changes. Better disable this additional logging for normal use though as it can screw up the timing.

 

so long,

 

Hias

[RockfordDash]

OK, I tested a few more things and here are my findings so far.

 

Capacitors on SIO lines.

I saw pictures of them soldered directly on the SIO connector. This is not the case in my 65XE, as seen in the picture. What looks like 1k resistors are most likely 100 nF capacitors. A give away is label C<num> and two silver stripes instead of one.

Here's a link of interest talking about benefits of removing them: http://sio2sd.gucio.pl/wiki/HighSpeed_en

I haven't clipped them yet. I wanted to see how far I can go without modifications.

 

Level shifter.

I bought two on Amazon, 5 USD each (1pcs IIC I2C Logic Level Converter Bi-Directional Module 5V to 3.3V For Arduino; pictured). I didn't want to go for the cheapest ones as they have a reputation of distorting signals. No idea if those are much better though.

 

Yes, I have a diode on Data IN. I did not use pull up resistor. So I soldered one (4.7k) between SIO 5V and Data IN. I tested transmission with and without it; no difference at divisors 2 and 1. At zero no luck yet. I haven't tried bypassing a diode.

Schematic of what I've done so far is attached (sans pull up resistor).

 

Adjusting baud rates.

That change alone had an impact at divisor 1. After bumping speed up to 109300 and 109800 I could read ATRs fine. This is on an NTSC Atari 65XE. After taking a look at source code I realized atariserver uses PAL Pokey speed. My change to 109800 amounts to using slightly higher NTSC Pokey frequency instead of PAL one. Constant ATARISIO_ATARI_FREQUENCY_NTSC is already there; just not used.

This speed works with or without pull up resistor on data line (caps still in place).

Next I tried divisor 0. Speed 123500, 124000, 124500, 125000, 125500... No dice. Tried with and without pull up resistor.

Still, very happy with 109800.

 

Thanks,

RD

Edited April 8, 2019 by RockfordDash

[E474]

Hi,

 

That's a very nice write-up, if you are using a pi0, I think you should be able to connect up the COMMAND line too. I have a first generation pi, and all my connections go through an IDE cable (40 pin), and because I move things round I don't want to solder the COMMAND line to the P5(?) header.

 

Glad you liked atariserver!

[RockfordDash]

Thank you E474. While I could connect command line, it is not clear to me what we could gain by doing so... Any idea?

[HiassofT]

Thanks a lot for the detailed info and the pictures!

 

It looks like your 65XEs has 1nF caps on the SIO lines, if the schematics I have here are correct C77 and C78 (looking like resistors) should be the one's on data in/out - if in doubt check with a continuity tester. It'd be good to remove them (desoldering the end connected to SIO or just clipping this side off is fine).

 

Concerning baud rates: POKEY has a bit quirk in receive mode, it doesn't sample in the middle of a bit but it's skewed by about 7 clock cycles. This means for the highest baudrate the transmit baudrate has to be a tad lower otherwise it won't work. So for NTSC Ataris using the calcualted PAL baud rates is already sufficient, but for PAL Ataris it needs to be set still a bit lower. This is why I don't use the NTSC frequency in my calculations but base everything on PAL frequency.

 

In my tests this worked quite fine (both on NTSC and PAL systems) and there's some upper and lower headroom we can operate in. It's all a bit tricky as UARTs usually can't operate at any given baud rate but will round it up or down to the next closest supported baud rate.

 

So knowing that 109800 worked for you is really helpful information! It could well be that I need to manually tweak the fastest baudrates up again a bit.

 

Concerning the command line: having that connected (and enabled in atariserver) will help atariserver detect command frames more reliably, especially if you have other SIO devices connected to the SIO chain. With just the RPi / atariserver connected the "no command line" mode seems to work rather well though (actually better than I had expected). If you like you can give it a try, copy over the dtbo files from contrib/rpi to /boot/overlays and enable the uart-ctsrts dtoverlay to get CTS on GPIO pin 36 (see README.rpi for details).

 

so long,

 

Hias

[+Nezgar]

It looks like your 65XEs has 1nF caps on the SIO lines, if the schematics I have here are correct C77 and C78 (looking like resistors) should be the one's on data in/out - if in doubt check with a continuity tester. It'd be good to remove them (desoldering the end connected to SIO or just clipping this side off is fine).

C77 and C78 match the ones I lifted on my 800XL as well:

[RockfordDash]

Thanks for extra data & corrections. Plugging in capacitor color bands from my board (https://www.dcode.fr/capacitor-color-code) yields 1 nF answer. That's reasonable. Original 100 nF I found cited seemed excessive.

Ohm meter testing reveals those are not resistors.

I will definitely connect command line and report if that made a difference. I'll still keep caps in place for further testing.

 

Regarding UART speed I'd be curious to know if I can tell the real speed. Supposedly RPi's main UART has integer and 6-bit fractional dividers. That's quite a resolution, but I'm not certain how to tell what the clock speed is.

I've seen 3 MHz and 48 MHz tossed around. In SIO2BSD software reports 3 MHz clock.

 

I reran atariserver test to get the idea of what the accepted range could be for 108000 baud rate. I've had success reading disks in this range: 108940 to 112120 baud (108930 & 112130 failed).

 

Time to play with command line next...

 

Thanks,

RD

[HiassofT]

Removing the caps would be most interestnig as that can have an effect on the actual supported baud rates - the marginal ones could start working reliably as the signal rise time is then a lot faster (signal fall time will be affected too, but rise time changes a lot more due to the diode / open drain connection).

 

Getting the real baud rate back from the driver is practically impossible, the only reliable way is to check with a scope. The termios2 ioctl (TCSETS2/TCSETSW2) used by atariserver/atarixfer allows the driver to use fractional dividers which gives really good accuracy with the RPi ttyAMA0 UART, but there's no corresponding call to get the actual baud rate back. The baud base reported can't be trusted too much (eg PCIe based 16C950 UARTs on a PC report 4MHz although it's actually 62.5/16=3.90625MHz), the TIOCSSERIAL ioctl as used by RespeQt only supports integer divisors. On the RPi mini UART the divisor calculation is a bit off, but fortunately that's only a problem on really high baudrates. And last but not least the UART clock could be quite jittery (as observed with FT232R on Lotharek's SIO2PC USB adapter).

 

so long,

 

Hias

[RockfordDash]

I see, so testing without caps is the way to go...

In the meantime I have a few more numbers to report. This time I used Raspberry Pi 3 Model B+ instead of Zero W. Just for curiosity I reran speed checks and the range has shifted. On RPi 3 I can now transfer (without command line enabled) at speeds 107000 to 111850 baud.

 

The next thing was to hook up command line. After copying overlays from atarisio/contrib/rpi I enabled CTS/RTS with supplied dtoverlay=uart-ctsrts in boot/config.txt. I ran atariserver with -C switch instead of -N.

Now I no longer need to bother specifying speeds! With command line divisors all the way up to 0 work, and those that worked before without command (like div 1) are *faster* still with handshake (in a sense effective transfer rates are higher).

Again, this is with caps in place and without pull up resistor. I haven't tested any ranges after command line handed me easy victory.

 

Updated schematics to include command line connection. Well worth extra soldering efforts.

Also included poor man's SIO plug... That is, using just socket contacts from 1 dollar DB15 socket for now.

 

[E474]

Hi,

 

That's a nice simple SIO connector, I usually 3D print mine, and use metal connectors salvaged from ATX PSUs, or Molex 396 KK clips and a crimping tool.

 

If you are using several RPi, it can be easier to use a 40 pin IDE cable (80 pin cables will fry your pi) and solder in a couple of rows of header pins for the RPi0. Which is exactly what I am going to do, as I like the sound of that COMMAND line speedyness.

[RockfordDash]

Hello,

 

I heard about ATX PSU method, but I disposed of those power supply units long time ago. I think I will sacrifice real Atari SIO cable and cut it in half. Will be good for two connectors...

 

For the time being wires will have to do.

 

[HiassofT]

It's great that you got everything working nicely on your RPi3B+!

 

The slight speedup with CTS command line is to be expected (forgot to mention that) as it'll allow atariserver to detect the command frame more precisely without having to wait for a short dead-time (as it does in no-command-line mode).

 

Still puzzling why the speed range is different on RPi0W and divisor 0 doesn't work. I'm not 100% convinced that the caps are responsible for that (they could be, though).

 

As for a SIO connector replacement: you could put a piece of blank PCB between the female connectors and hot-glue them in place. I tried that once and it worked quite nicely. Similar to the improvised SIO connector in this post: http://atariage.com/forums/topic/94188-sio-connector-alternative/?do=findComment&comment=1144922

 

so long,

 

Hias

[_The Doctor__]

Hello,

 

I heard about ATX PSU method, but I disposed of those power supply units long time ago. I think I will sacrifice real Atari SIO cable and cut it in half. Will be good for two connectors...

 

For the time being wires will have to do.

 

I've made sio cords using the method of spraying the sio socket, doing the wires as in the picture... and potting the cavity ending up with a cheap molded sio plug.

the socket used was a spare that was not in a machine. After it cured on both end, you plugged it in to whatever as usual... I am have been known to be creatively cheap...

Edited April 9, 2019 by _The Doctor__

[RockfordDash]

I like molded SIO plug, I didn't think about that...

 

So yes, rate ranges differ for some reason. I retested them to be sure and that's what they are on RPi 3. Let me connect command line to RPi Zero, add dtoverlay and see if it changes anything.