Atari SIO transmission oscillogram

[RockfordDash]

Hi Nezgar, as you wish... With and without caps, no extra resistor (in above post).

[HiassofT]

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.

Did you have the diode in place in this test? The traces look a lot like it's missing - you have a steep rising edge from the push/pull outputs on the RPi up to 3V3 and then a slow rising edge from the pull-up resistor on the levelshifter up to 5V.

 

so long,

 

Hias

[RockfordDash]

I do have a diode in place. Signal is measured behind it, on SIO side.

 

Thanks,

RD

[ivop]

Please tell us more about this upgrade.

From what I remember, he put very fast schmitt triggers on data in/out and command of an SDrive. Maybe Mr. Atari can chime in. It was his friend that did this. I'm only faintly acquainted.

[HiassofT]

Some more traces of SIO data in (command ACK byte) with the pull-up removed

 

no caps:

 

caps:

 

and here a zoom-in on the first bit of the ACK plus in comparison zoomed in traces with the pull-up in place.

 

no pull up, no caps:

 

pull up, no caps:

 

no pull up, caps:

 

pull up, caps:

 

so long,

 

Hias

[ricortes]

IDK. I think one of the things I subscribe to is a robust design as long as it isn't me that is doing the design. j/k What I said about a Schmitt trigger is true but properly chosen and placed it would let people hang 3-4 drives, an 850, RPi, et al on the SIO chain and still work. Wouldn't be needed for a single drop device of course.

 

In my experience the more complex the design the fewer people that can execute it. Anything above ~14 pins and half the people out there can't get it done. Even the RPi according to the link provides 50k pull ups if my cursory reading got it right.

 

Some of the things we have to worry about are future devices that may use CMOS and 2.5V switching levels. Buffered and fast rise times to 2.5V would be a good thing. On the other hand, the old equipment is slowly wearing out. The new stuff, SDrive, RPi, SIO2PC USB, all don't load the lines that bad when used alone and even the old stuff like 1050's buffered in the device. Just me, I'm not going to worry about it until a problem pops up. I mean something like a POKEY replacement in CPLD that runs at 40 MHz and outputs serial data at 1 MHz or something. What we have now, cutting caps & pull up, is good enough. Heck, I like this discussion; moves me to think.

 

For the new stuff, it would be best to have a buffer included, SIO through second plug, aux 5V supply that is isolated from the computer but supplies a couple of amps on the 5V line, and "Plug me in first" so everything down stream would get clean signals and juice. Probably more stuff I am missing these things would be nice.

[+DrVenkman]

Hias -

 

I'm curious; how are you capturing the SIO traces? Not how you're triggering the scope, I mean physically connecting things. Do you have a breadboard or something rigged to plug into the SIO chain to clip your scope probes to, or are you actually grabbing signals from POKEY, SIO port or some other points on the Atari?

[HiassofT]

In these tests I used my self-built serial SIO2PC interface where I added a 0.1" header so I can easily access the SIO signals.

 

When I tested with the RPi and level shifter some time ago I used the SIO part of the PCB of a dead 1020 which I sawed off. Also with some headers added so I can easily grab signals. A picture of that is here: http://www.abbuc.de/community/forum/viewtopic.php?f=3&t=9715#p80170(the second SIO connector from that PCB now lives in my eclaire daugherboard, if it would still be there that PCB could serve as an easy method to get signals from a SIO chain).

 

On other occasions I grabbed signals directly from the SIO port inside the Atari, one time I soldered headers into the holes of the (removed) SIO caps on the in/out/cmd lines - then I could attach dupont wires and have the keyboard of my 800XL in place.

 

so long,

 

Hias

Edited April 21, 2019 by HiassofT

[ivop]

I have something similar. Here's an image I posted earlier: http://atariage.com/forums/topic/269207-midi-interface/page-2?do=findComment&comment=3853733

 

All SIO signals are available on two straight and one angled header.

[+Nezgar]

Thanks for the additional visuals!

 

I've disconnected the caps in a couple of my machines, but didn't add the 4k7 resistor. (yet) I can see the resistor appears to be just a small incremental improvement over disconnecting the caps. Will still look into adding the resistor when I'm next working on the machines though. I honestly haven't done much faster than divisor 3 or 4, but mostly because that's the upper limit of the SpartaDOS UltraSpeed handlers. Will have to try pushing it further with the HiassofT patched OS.

[_The Doctor__]

use the pclink driver with respeqt and see if that doesn't take you to divisor zero under spartados x.

[+Nezgar]

use the pclink driver with respeqt and see if that doesn't take you to divisor zero under spartados x.

 

With PCLINK, and a Lotharek SIO2PC-USB plugged to the back of 1 1050 (this one still has it's own speed limiting caps present) which is then chained to the Atari, I can reliably transfer at divisor 3. divisor 2 barfs.

 

And also same with the Lotharek SIO2PC-USB directly plugged to the 800XL, Divisor 3 works, Divisor 2 barfs. (Can't even get directory)

 

But... this is using SpartaDOS 4.49c's own highspeed SIO driver which I was thinking 3 was the limit. To prevent SDX from loading it's own drivers and use the OS based SIO drivers

 

I just created a custom CONFIG.SYS with SIO.SYS /A to use the OS based Hias HSIO routines, and found it also only functions up to divisor 3. PCLINK drives only work at 19200, probably because the OS handler doesn't recognize those drives...

 

So I wonder if the 4k7 resistor will help here?

[+Nezgar]

An update. Finally put the 4k7 resistor in. I didn't feel like lifting my 'main driver' 800XL's motherboard out of the case since there's things attached to the case, so with some continuity testing I figured out where I could install the resistor on the top side. Connect the 4k7 resistor between the right side of C78 to top side of C80.

 

Some quick testing showed no improvement with SDX 4.49c native drivers, divisor 3 max. Sometimes I can get PCLINK.SYS to copy a file at divisor 2, but takes a few retries and NAKs and hangs.

 

Using SIO.SYS /A in config.sys (To access OS based Hias SIO patch) now lets me access normal ATR based RespeQt ATR media at divisor 0 reliably. However, PCLINK.SYS access only operates at 19200 in this mode.

 

So I guess the hardware works, but the software is kinda finicky.

[HiassofT]

Using SIO.SYS /A in config.sys (To access OS based Hias SIO patch) now lets me access normal ATR based RespeQt ATR media at divisor 0 reliably. However, PCLINK.SYS access only operates at 19200 in this mode.

Good to hear this is working now!

 

My OS SIO patch only accelerates D1:-D8:, so PCLINK will run at standard speed - so the result is to be expected. If you have a U1MB you could try using it's PBI SIO driver, IIRC this will accelerate PCLINK as well.

 

I had a look at the SIO connection part of the 1050 schematics:

 

The caps C56,C57,C58 (which are recommended to be clipped off) create a path from SIO data in to ground (C61 which is also recommeded to be removed is behind the CA3086's transistors so won't affect the SIO bus directly). With a 4k7 resistor in series and a total capacitance of about 19pF that won't be a huge load - though it'll still affect the SIO bus even if the drive is powered off.

 

I also measured the parasitic capacitance of a SIO cable (between SIO data in/out lines and GND lines) and got about 110pF.

 

So the worst "offender" seems to be the 1nF caps in the Atari, followed by SIO cable, then parasitic capacitance in the SIO device (like the caps in the 1050), each about one order of magnitude apart.

 

The additional pull-up may help a bit in extreme cases (caps in the Atari plus a few SIO devices connected), but I'd guess a similar pull-up would be needed on SIO data out as well.

 

so long,

 

Hias

[flashjazzcat]

Yes: the U1MB PBI implementation of Hias' driver can optionally handle the PCLINK device, and does away with the need for the /A switch in CONFIG.SYS. I never had any luck with divisor 0 using the SDX SIO driver, but I use the U1MB driver at 127Kb/s 100 per cent of the time without a single problem.

[ricortes]

Would have been nice to have that LM3086 under the hood in our Atari. I just looked at the data sheet and it will handle 300 mWatt/transistor up into the VHF range. It is more complex then a simple design like a ~hex Schmitt trigger but fan out and frequency response would have been hails. Min Hfe is 40 so if you really wanted to drive a herd of stuff on the SIO chain, that would be the way to do it.

 

I do know people that had Atari back in the day. For some of them the extra expense would have been pointless. They just had Atari 400s and the only thing they used were carts and joysticks.

[Kyle22]

Yes: the U1MB PBI implementation of Hias' driver can optionally handle the PCLINK device, and does away with the need for the /A switch in CONFIG.SYS. I never had any luck with divisor 0 using the SDX SIO driver, but I use the U1MB driver at 127Kb/s 100 per cent of the time without a single problem.

 

Same thing exactly here on the Incognito PBI BIOS. It's flawless.

[+Nezgar]

I'd like to remove the speed-limiting capactors from a Rev5 130XE as I did with an 800XL. Everything I've read says that it's the same C77 and C78 as the 800XL, but there's actually second set of capacitors at C303 and C304. Anyhow, I've removed those as pictured here, but I would still like to remove C77 and C78 and can't see under the components enough to tell where they are. Can anyone let me know which they are in this picture? Couldn't find a silkscreen online with a short search...

[+Nezgar]

Found the locations of C77/C78 in the Atari 130XE Reference Manual on AtariMania.

 

For future reference:

[+Nezgar]

On 4/20/2019 at 11:37 AM, HiassofT said:

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.

Is there an appreciable difference between using a 3k3 resistor and a 4.7k resistor for the pullup? I ask because I have a lifted 3k3 resistor at R206 on a 130XE from a previous 320K RAM upgrade that I could re-purpose for a short wire jump from C78.

[HiassofT]

15 hours ago, Nezgar said:

Is there an appreciable difference between using a 3k3 resistor and a 4.7k resistor for the pullup? I ask because I have a lifted 3k3 resistor at R206 on a 130XE from a previous 320K RAM upgrade that I could re-purpose for a short wire jump from C78.

Hard to say, I'd guess that should work fine, too. SIO devices will then need to pull down harder though.

 

If you clip off the caps there's in general no need though for any additional pull-up. That may help a bit in some extreme cases, usually you should be fine with just the caps removed.

 

so long,

 

Hias

[_The Doctor__]

I've never had to remove anything other than c303 and c304 on an XE to get DIV 0

not sure about removing other caps that may have been renumbered for a different pcb relative to the 800XL etc.

Edited September 20, 2019 by _The Doctor__

[+Nezgar]

Thanks. In the 800XL I previously modified, I found that the additional pull-up made the difference for reliable divisor 2,1,0, so I just went straight for the 'extreme' in this 130XE. Removing the caps that were there since the 800XL, as well as the additional layer added on the 130XE, so they should now be the same.

I used a nearby source of +5V from the left side of R89 to the right side of the (now missing) C79 for the 4k7 resistor. I left the previously disabled 3.3K resistor alone.

 

Now it performs like a champ at Divisor 0. In the stock configuration it divisor 10 was about the limit.

Here is an RWTEST result with RespeQt serving a DD disk at divisor 0 with 270 μs response delay:

 

[atariry]

Fascinating thread. Great to see scope captures! Thank you.

 

Back in 1985 I was very interested in the SIO, and made myself a SIO to parallel printer circuit using a INS8048.

 

I recently found my old notes from back then. Posting a relevant pages in case anyone is interested.

 

Back in 2001(?) I made a SIO to IDE hard disk drive circuit. I even got as far as getting a commercial PCB made (much easier and cheaper nowadays!). The project never got finished, but the hardware did work. Must dig it out.

 

Not sure if this is the right thread to ask, perhaps there is a more relevant older thread, if so please advise.

 

I have often wondered how the high speed SIO works. In high speed mode does the command packet still get sent at the standard baud rate, with only the data payload packet at the higher baud rate? I was thinking that if all SIO traffic was sent at the higher baud rate other "normal" devices (e.g. non Happy FDD) on the SIO bus might get very confused. My printer circuit used bit banging for the SIO and only was interested in command packets, and the data payload only if it was selected, otherwise it would completely ignore traffic on the SIO. I keep meaning to revisit this and use an Arduino as a SIO peripheral. With a hardware UART it gets even more easy to implement. And yes I know about S-Drive MAX, but I've never looked at the source code (if it can be viewed). For fun I would like to implement high speed SIO. I know that there is at least one web site which lists some of the other than Atati SIO commands, but not in great detail. Is there any more detailed information (even if you tell me to look for some old threads!) somewhere? Also at the Atari end is it as simple as changing the POKEY divider?

 

regards...

 

--Atariry

[HiassofT]

2 hours ago, atariry said:

I have often wondered how the high speed SIO works. In high speed mode does the command packet still get sent at the standard baud rate, with only the data payload packet at the higher baud rate? I was thinking that if all SIO traffic was sent at the higher baud rate other "normal" devices (e.g. non Happy FDD) on the SIO bus might get very confused.

Well, there are both variants - some protocols (eg XF551) transmit the command in standard speed, some others (eg Happy / Speedy) in highspeed. As the command frame contains a checksum, which will very likely be not matching if the device is receiving at the wrong speed it's not too bad (yeah, there are some pitfalls still).

 

Quote

Also at the Atari end is it as simple as changing the POKEY divider?

Yes and no. Some protocols (eg 1050 Turbo) are really simple to implement, the driver just hooks into the OS IRQ handler and changes speed to high when the command frame is sent. Happy eg is quite simple, too, as everything is sent in high speed. But that doesn't work easily with the OS SIO code, a highspeed driver has to implement the whole SIO protocol.

 

If you want to use the fastest possible rate it gets very tricky. Using IRQs no longer works as they take too long. Even with polling code it's nasty as the OS VBI can mess up timing. With a standard graphics 0 screen there's not too many CPU cycles left. It's possible to do but it took me a while until I got that working.

 

If you are interested check out the README.txt and the source code of my highspeed SIO patch, most of the important stuff should be in there

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

 

so long,

 

Hias