Jump to content
IGNORED

Atari SIO transmission oscillogram


RockfordDash

Recommended Posts

Hello,

 

I wanted to share a couple of pictures (mangled by site uploader) showing Atari talking to RPi over SIO line.

 

In the first one we can see command line (red) transmitting request to read a sector from atariserver running on RPi. It's a 5 byte long command ($31 drive D1, $52 'R'ead sector, sector number $001e, $A1 checksum).

Atariserver (green) responds with acknowledge ($41) & complete ($43) followed by sector data. This was captured at standard 19200 baud rate.

 

post-68063-0-01496000-1555731685_thumb.png

 

Next I have a close-up of the first couple of bytes of the same sector read request, this time at 124 kbaud. Red wave is SIO Data Out, while green wave is what RPi sees (behind level shifter).

Far from square, but RPi can still read it reliably.

 

post-68063-0-07800700-1555731741_thumb.png

 

Here's atariserver page: https://www.horus.com/~hias/atari/

It's capable of working at 124 kbaud as opposed to SIO2BSD routines, so that's what I'm using here.

 

So long,

RD

  • Like 7
Link to comment
Share on other sites

Watch how SIO negotiates UltraSpeed protocol. It asks the device first about what speed it is capable of, gets divisor, sets divisor, switches to that divisor, If It gets NAK, it switches back and forth between divisors until it gets an ACK, then locks it in. (In a nutshell, I may have some minor details wrong, but that's basically how it works.)

 

HighSpeed is a different story. It always sends the Command frame at 19.2 (with high bit of command set [+128]), then switches the divisor for faster I/O. USB devices can't handle fast switching speeds like that, so they typically don't work for the HS SIO protocol.

 

I'd like to see it scoped out. Just how laggy are the USB chips / spftware? Could this ever work?

 

Are you able to see this sort of thing?

  • Like 1
Link to comment
Share on other sites

I'm using HISIO driver with RaspberryPi UART, and it didn't occur to me to examine the very first frame to find out if/how it tries to negotiate the speed. That would be interesting. I can check this out tomorrow or just wait for Hias to show up and tell us all about it :) It's his baby.

 

USB chips? Are you referring to USB serial emulators? I'm not using any, nor have any. Only RPi...

  • Like 2
Link to comment
Share on other sites

The rounded start of the pulses caused by 'speed limiting capacitors' in both the Atari computers and drives is a key inhibitor of achieving reliable transfers at higher speeds. (done to limit RF interference for FCC compliance) For example, I've found a stock 130XE may work fine with a Happy or US Doubler that operates at divisor 10 (52K), divisor 9 (55K) or even divisor 6 (69K) for an Indus GT, but will fail miseably when trying to use Speedy's highspeed sector copier fails, which runs much higher, I'm not sure, but I think 72K.

 

In an 800XL, the speed limiting caps are C77 & C78

In the 1050 drive, the speed limiting caps are C55, C56, C58, C61. (Required mod as per the 1050 Speedy installation instructions)

 

There's similar plots showing signals similar to yours here: http://sio2sd.gucio.pl/wiki/HighSpeed_en

 

If you haven't lifted the caps yet in your Atari, maybe the RPi is just very tolerant of the very rounded waveforms?

 

Edit: Maybe someone can explain the reason for the recommendation on that page to also add a 4k7 resistor between SIO DATAOUT and +5V? thanks!

  • Like 2
Link to comment
Share on other sites

If I was to speculate then I'd guess signals on RPi's side are well within CMOS voltage regime. Well above 2V for high and less than 0.5V for low, so it looks good. Although it is not clear what the RPi's spec are (http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications).

 

Regarding caps and pull-up resistors I actually ran some tests because I was curious what difference it all makes.

 

First try: 124k with caps and no pull-up resistors:

 

post-68063-0-44529100-1555738292_thumb.png

 

Then capacitors clipped:

 

post-68063-0-72780600-1555738336_thumb.png

 

And finally 4.7k pull-up resistors added:

 

post-68063-0-79853600-1555738405_thumb.png

 

Data out signal got progressively better, but not on an RPi side... Not sure if I haven't messed something up, although I was careful.

 

  • Like 3
Link to comment
Share on other sites

HighSpeed is a different story. It always sends the Command frame at 19.2 (with high bit of command set [+128]), then switches the divisor for faster I/O. USB devices can't handle fast switching speeds like that, so they typically don't work for the HS SIO protocol.

 

Not quite sure what you’re trying to explain here, Kyle. I’ve got two SIO2PC USB-based devices - one standalone widget with an FTDI chip built into a USB plug, and the other a Sparkfun FTDI USB-serial breakout board in my 1088XEL. Both handle POKEY divisor 0 transfers at 125,000 kbps just fine.

Link to comment
Share on other sites

Not quite sure what youre trying to explain here, Kyle. Ive got two SIO2PC USB-based devices - one standalone widget with an FTDI chip built into a USB plug, and the other a Sparkfun FTDI USB-serial breakout board in my 1088XEL. Both handle POKEY divisor 0 transfers at 125,000 kbps just fine.

Yes, they can handle the high bitrate, which is good for the 'Ultraspeed' protocol since both command and data frames use the faster rate once negotiated.

 

But USB serial devices cannot switch speeds fast enough to do the XF551 style 'Highspeed' protocol, where the command frames are sent at 19200 and data at 38400. Indus GT Syncromesh protocol is similar, with data frames sent at 68K I believe.

  • Like 3
Link to comment
Share on other sites

Yes, they can handle the high bitrate, which is good for the 'Ultraspeed' protocol since both command and data frames use the faster rate once negotiated.

 

But USB serial devices cannot switch speeds fast enough to do the XF551 style 'Highspeed' protocol, where the data frames are sent at 19200 and data at 38400. Indus GT Syncromesh is similar, with data frames sent at 68K I believe.

Meh. Why would anyone in this day and age actually WANT that? :)

 

Also, as a general principle, I don’t think that’s necessarily accurate these days. Modern computers, running modern hardware and operating systems, operate at VASTLY higher data rates than our ancient Ataris. USB-C/Thunderbolt devices negotiate data rates among multiple devices, all operating at different data rates, up to the gigabits per second range. I can connect a basic USB keyboard, a 16K dpi mouse, and a 4K video display all to one port.

 

So while a typical FTDI USB-serial interface chip that we’re used to working with on Ataris can’t switch rates fast enough, USB itself can switch quickly and transparently when used with modern devices just fine.

  • Like 1
Link to comment
Share on other sites

If I was to speculate then I'd guess signals on RPi's side are well within CMOS voltage regime. Well above 2V for high and less than 0.5V for low, so it looks good.

 

Maybe the 2V high is the key allows the RPi to tolerate the rounded waveform better than the Atari itself, or some disk drives.

  • Like 3
Link to comment
Share on other sites

Maybe the 2V high is the key allows the RPi to tolerate the rounded waveform better than the Atari itself, or some disk drives.

 

Almost surely. I know of someone that put schmitt triggers on the SIO lines and managed divisor 0 without cutting the caps.

  • Like 5
Link to comment
Share on other sites

But USB serial devices cannot switch speeds fast enough to do the XF551 style 'Highspeed' protocol,...

Probably it is just a matter of the software interface. Devices like Atarimax SIO2USB surely could switch speed as fast as you need it (don't know if it currently actually supports this or not).

 

Also, as a general principle, I don’t think that’s necessarily accurate these days. Modern computers, running modern hardware and operating systems, operate at VASTLY higher data rates than our ancient Ataris. USB-C/Thunderbolt devices negotiate data rates among multiple devices, all operating at different data rates, up to the gigabits per second range. I can connect a basic USB keyboard, a 16K dpi mouse, and a 4K video display all to one port.

So while a typical FTDI USB-serial interface chip that we’re used to working with on Ataris can’t switch rates fast enough, USB itself can switch quickly and transparently when used with modern devices just fine.

 

Bandwidth is one thing, latency is another. Modern hardware has interfaces that transfer at very high bitrates, that's the bandwidth. Several orders of magnitude higher than our Atari. OTOH, latency is usually much worse on modern hardware.

 

The time since since you press a button on your wireless controller until the software actually receives the event, is measured in milliseconds. An ATARI can read the joystick in couple of microseconds, and the actual hardware "transfer" is measured in nanoseconds. This is latency. Check other forums here in Atariage about the problem of how lag affects modern hardware emulating (or cloning) retro devices.

 

Of course that modern hardware could, in theory, have much lower latency. But nobody cares (or didn't care until recently). If you want to download a huge file, what matters is if the download would take a couple of minutes or a couple of hours (that mostly depends on bandwidth). It doesn't matter if the download would start in a couple of seconds, or in a few microseconds (latency).

 

Only recently, modern gaming has established some demand to reduce latency. So gamers, i.e., don't use wireless controllers. But the demand is to reduce latency by magnitudes measured by human perception. From, say, tenths or hundreds of milliseconds, to a couple of milliseconds. That's still far from a magnitude of a few microseconds that you would require in our case.

 

Edit: Btw, it is not about switching the USB bit rate. There is no need to that at all. You only need to change the speed of the SIO bit rate.

Edited by ijor
  • Like 3
Link to comment
Share on other sites

As ijor already mentioned latency is the big issue, and we'll have latency in the (USB/serial) driver code, the USB controller/protocol and the USB-serial adapter.

 

A couple of months ago I did some measurements with FTDI chips on Linux, with the serial driver configured to low-latency mode (to avoid delays when sending data, plus IIRC that also configures the FTDI chip to use the lowest latency timer setting of 1ms).

 

On a USB3 (XHCI) controller or on a USB2 (EHCI) controller with an USB2-hub inbetween (so the EHCI controller doesn't route the USB traffic to one of the UHCI or OHCI companion controllers) the minimum roundtrip latency was near the 125us microframe interval.

 

On an UHCI controller it was near the standard 1ms frame interval, on an OHCI controller it was twice that - not sure if that is an issue with the OHCI controller or the Linux driver.

 

In addition to that the FTDI chip won't send data packets faster than 1ms (the minimum latency timer setting). So, for example, when you receive a command frame ACK plus COMPLETE byte from a peripheral these two bytes (which are specced to have a gap of at least 250us between them) will be received as a single packet with 2 bytes by the PC. While that's no big deal for sector reads (which often take a long time) other commands like "get status" will have about that minimum gap.

 

That alone is a nasty thing, as when talking to a XF551 you should switch from 19200 bit/sec to 38400 bit/sec immerdiately after the ACK, before the COMPLETE

 

When acting as a SIO device you have all the time you want before switching speed and sending the complete on Read commands, but on write commands the Atari will start sending data (at high speed) about 1ms after it received the command frame ACK.

 

You can imagine that you won't have much chance on a full speed USB connection with 1ms frame interval (you also need to repeatedly query the USB adapter if it has finished transmitting the byte), and even with a 125us interval it's rather hard to get the timing right - other devices on the USB bus may be blocking it (so you're at 250-500us round trip time) and/or latencies in the OS/driver will ruin the timing.

 

With "real" serial ports things already look a lot better. There you don't have the latencies from the USB bus and if talking to the chip directly (bypassing the stanard drivers from the OS, like what I do with the atarisio kernel driver for 16550/16C950 UARTs) latencies can be reduced a lot and the XF551 protocol is no problem.

 

OTOH with other USB-serial adapters like the prolific 2303 things are even worse, they (or at least the linux drivers) don't seem to support querying the transmitter empty status - so one has to "guess" if transmission is actually finished and wait blindly for a rather long time until it's safe to switch serial speed.

 

so long,

 

Hias

Edited by HiassofT
  • Like 3
Link to comment
Share on other sites

Forgive me if this is common knowledge. In general ICs suck at supplying current while pretty good at sinking current. That is why you are seeing the wave forms you do with slow rise times but rapid shut off. It's something that has been around for decades, just a physical characteristic of what you can do with an integrated circuit. That is the reason why people have a tendency to prescribe pull up resistors as the first attempt at a cure for timing just about anything. Pull up resistors on everything! That is why reading a nothing there address on an Atari in the $D000 to $D7FF memory map returns $FF.

 

Also some POKEYs are better then others, I'm not sure why. Not all my 8 bits were bought new so it is possible they got hit with a static discharge.

 

Everything, EVERYTHING, you put on the SIO lines increases load. Some things like the 1489 or MAX232 intentionally load the lines with on chip resistors to comply with RS232 standards. Kind of surprising they work with anything else like a real 1050 ever, we got lucky. I'll have to look at a RPi schematic but I wouldn't be surprised if they add some type of pull up or down on their serial lines. It is considered BOO BAD!!! to leave anything not hooked to a logic level. Some early computers made this mistake and ended up oscillating themselves to death.

 

Yes, Schmitt trigger would clean up the wave form, but think about it a minute. It would still have the delay in turn on of the signal feeding it. What you would end up with is a narrow HIGH width that would be just as bad. See what I am getting at? The RPi doesn't see the transition state until a threashold is reached, a Schmitt trigger will be just like it.

 

IDK. Doesn't look good for ever getting beyond 112k anyway. Physical limitation of POKEY is that it is running as fast as possible at 112k anyway.

 

Something that may solve it would be a circuit with less load and earlier turn on then existing ICs. Talking something like a FET circuit that turns on at .3 Volts or something which may open its own can of worms.

 

Atari drives took an interesting<to me> approach to line load. It is like they said "If somebody buys one drive they are likely to buy four!" The 1050 use a 6 transistor on a chip IC to buffer the lines. I seem to recall something like only presenting a 200k Ohm load per line with their design.

 

I'm not faulting the Atari 8 bit designers. I'm sure at the time saving $.20 per computer meant they could keep their job vs. get a demotion. :)

  • Like 1
Link to comment
Share on other sites

Edit: Maybe someone can explain the reason for the recommendation on that page to also add a 4k7 resistor between SIO DATAOUT and +5V? thanks!

That's to shorten the signal rise time. Together with the 3k3 pull-up resistor in the Atari total resistance is down to about 2k, and that's often enough to get reliable transmission at divisor 0, even with the 1nF caps in place. It can also help with a lot of SIO devices hooked up to the bus as that will also increase total bus capacitance.

 

so long,

 

Hias

  • Like 3
Link to comment
Share on other sites

Forgive me if this is common knowledge. In general ICs suck at supplying current while pretty good at sinking current.

This is mainly true for TTL chips where the output stage is basically an open collector transistor coupled with a pull-up resistor.

 

Current sinking capability of those devices (through the transistor to ground, on low level output) is usually about 5-10 times higher than current source capability (through the pull-up, on high level output).

 

CMOS devices with totem-pole / push-pull output stages have (almost) symmetrical current source/sink values. See eg. the RPi GPIO specifications here https://www.raspberrypi.org/documentation/hardware/raspberrypi/gpio/README.md

 

SIO data in (peripheral data output, Atari computer input) is typically open-collector output as well - eg the diode in SIO2SD converts the push-pull output of the Atmel to an open-collector equivalent, and only the pull-up resistor in the Atari (plus the optional one on the SIO2xx side) make the signal actually go high.

 

The Pokey data sheet doesn't seem to contain output current specs (I_OH, I_OL) so checking the waveform on SIO data out would be interesting - I'm sure I did this at some point but can't find any traces stored on my PC, so not sure if the rising edges are steeper than the ones on SIO data in with the pull-up or not.

 

Anyways, rising edges both on SIO data in and out will be flatter than falling edges, the critical point to look for though is around 1.2-1.5V, which is the typical lo/hi switching point both for inputs to the pokey and the RPi (and also most other TTL compatible inputs). Anything that happens above 2-2.5V is (in general) unimportant.

 

so long,

 

Hias

Edited by HiassofT
  • Like 2
Link to comment
Share on other sites

be interesting to see schmidt triggers put in a sio dongle, plugs into the Atari SIO and then a SIO cord plugs into it... might be something to handle the whole chain... no muss no fuss for all Atarians... the dongle would have to have the SIO jack stair stepped either up or down to allow black box to be attached at the same time ;)

Edited by _The Doctor__
Link to comment
Share on other sites

The Pokey data sheet doesn't seem to contain output current specs (I_OH, I_OL) so checking the waveform on SIO data out would be interesting - I'm sure I did this at some point but can't find any traces stored on my PC, so not sure if the rising edges are steeper than the ones on SIO data in with the pull-up or not.

 

Pokey SIO output signals are open drain.

Edited by ijor
  • Like 1
Link to comment
Share on other sites

Hello ijor

Sorry for being a pain in the a.., but AtariMax didn't make the SIO2USB, some guys from Frankfurt did. AtariMax makes SIO2PCviaUSB.

Hi Mathy,

 

No problem, I stand corrected :) I did mean AtariMax's device anyway. I know Lotharek makes a similar device, but don't know exactly what kind of hardware has and if it can be programmed as AtariMax's one (unfortunately, the interface was never undisclosed).

  • Like 1
Link to comment
Share on other sites

 

Pokey SIO output signals are open drain.

 

Thanks for refreshing my memory!

 

Just checked the 800XL schematics, pull-ups on the SIO data lines are 4k7, not 3k3 as I posted before.

 

So it'd probably be worth re-checking if the additional pull-up is actually needed. ISTR transmission was more reliable with it when I tested back then (with SIO2SD, SDrive and SIO2PC), but that was before I had a scope so I didn't check the actual traces.

 

so long,

 

Hias

Link to comment
Share on other sites

I did some tests with my serial SIO2PC interface (MAX232, diode plus 4k7 pull-up on SIO data in). Only the SIO2PC and an 800XL were on the SIO chain and the cable was rather short (~15cm) and I tested at pokey divisor 0 (~125kbps).

 

First on an 800XL with the caps in place:

 

SIO data out, first byte of command frame:

post-9299-0-47534100-1555844311.png

 

 

SIO data in, command frame ACK

post-9299-0-76186700-1555844302.png

 

Then on an 800XL with the caps removed:

 

SIO data out, first byte of command frame:

post-9299-0-73559400-1555844328.png

 

SIO data in, command frame ACK

post-9299-0-84663200-1555844320.png

 

So, with the caps in place the additional 4k7 pull-up on data-in indeed improves signal rise time (whether that's actually needed is another thing). Compared to SIO data out even single 1-bits make it near 5V whereas on SIO data out the edges are less steep and the signal only goes to about 4V.

 

Compared to the measurements with the caps removed (with about perfect signal quality) one can see though that the signal high time (at the typical threshold of about 1.5V) is significantly shorter (especially on SIO data out). This means the headroom for variations in baud rates is smaller, too, which can be a problem in some cases (PAL and NTSC rates are a tad different, UARTs usually can't be configured to exact Atari baudrates or may have jittery clocks - like I saw on the Lotharek SIO2PC USB interface).

 

So, instead of trying to doctor around symptoms with schmitt triggers (whcih can't compensate for the shorter signal high time) it's better to just remove the caps if you want good signal quality and reliable highspeed transmission. If you add more devices to the SIO chain with additional caps in place (like a bunch of 1050ies) things will get a lot worse.

 

so long,

 

Hias

  • Like 4
Link to comment
Share on other sites

I don't see similar improvement on an Atari 130 XE I bought on eBay, but then signal looks OK to begin with. I tried with and without capacitors, and no external pull-up resistors.

 

Green waveform is ACK byte on data in, red is RPi driving it.

 

With capacitors:

post-68063-0-92651700-1555861157_thumb.png

 

Without caps signal rises higher:

post-68063-0-15043600-1555861167_thumb.png

 

Caps on 130 XE are right next to the SIO connector:

post-68063-0-33714700-1555861236.jpg

 

I don't understand how signal with caps present can rise so quickly that slope looks almost vertical. But I suppose level shifter has pull-ups too and a lot depends on it.

 

Thanks,

RD

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...