SIO2PC FAQ

SIO2PC is a hardware interface and software utility package to allow storage of your Atari files on your PC's hard and floppy disks, file conversions in both directions, and Atari printer output redirection to your PC's printer, screen, or file. The most basic function of SIO2PC is to allow the PC to emulate one or several Atari disk drives. This gives the mass storage capability and reliability of PC disks and also increases disk I/O speed significantly. Connection to the PC is via a serial port. Connection to the Atari is via the SIO bus. The SIO2PC devices will co-exist with real Atari devices in the Atari daisy chain.

Here's a short text file about how to use SIO2PC's menu functions: SIOINSTR.TXT

Back to the Top

Where can I get the files and hardware plans?

Right here!

Download the software: SIO419.ZIP (84K Zip File)

View the SIO2PC schematic (click to view GIF file)

View the 1050-2-PC schematic (click to view GIF file)

Build_it.txt contains info on building the circuit, parts list and so on.

Download .BMP file (click for schematic as .BMP file & text file w/ parts list, suppliers, etc.)

AMAC.TXT Looking for an assembler? Click for info on using AMAC.

ATARI.ATR (51K-Zipped) is a disk image with files associated with SIO2PC, such as FILE2PC.OBJ, REMOTE.OBJ, DIAGS.OBJ and my ham radio program KEYER.OBJ. You'll also find some source code and my brother's two-player TANK.OBJ game here.

SOURCE.ZIP (136K) contains all of the source code for SIO2PC. It is written for the A86 assembler.

Atari Source (37K Zip File) contains the source code to some of my atari programs (FILE2PC, DIAGS and some SIO bus experiments) in plain ASCII, PC file format.

Readme.txt: A big rambling collection of technical details, history, amazing facts and weak excuses.

Back to the Top

What does the hardware do?

It's almost possible to connect the Atari and PC together directly. Their communications hardware can be programmed to the same bits/second, number of start & stop bits etc. The only problem is with the voltage levels used to represent logic levels 1 and 0 on the two systems. The PC uses negative and positive voltages of about -10 and +10 volts respectively, while the Atari uses TTL voltages of +5 and 0 volts for logic 1 and 0. The SIO2PC hardware is a simple circuit which converts the signals leaving one computer to the correct voltage levels for the other one. There is no clocking, logic or intelligence in the hardware. That's all in the SIO2PC software.

Click here to jump to the section with detailed technical info.

Click here to view the SIO2PC schematic.

Back to the Top

Alternate, cheaper, simpler designs?

The SIO2PC hardware is pretty simple with just one chip and a handful of other components. But it can be made simpler and cheaper. The reason this is possible is that an RS-232 input will usually recoginze TTL voltage levels as two discrete logic levels. The problem does remain that the higher (more positive) voltage represents logic 1 in TTL logic and logic 0 in RS-232 logic. So it will always be necessary to invert the levels. But TTL inverters are common and cheap. My first design used a 7404 hex inverter. You can run the line from the TTL source (Atari) thru one of these and straight into the PC's serial port and it will usually work OK. There's a slight problem in the other direction, though. Both voltage levels of RS-232 are potentially damaging to a TTL input, so it's necessary to clamp the positive level to 5 volts or less and block the negative voltage such that the TTL gate sees about 0 volts instead. Both of these actions are simply accomplished with a zener diode plus maybe a blocking diode. If you want to be a little fancier than a 7404, you can use a 1489 chip.

The reason I don't do these things is because I made interfaces for other people and I wanted a higher assurance that they would work every time on everyone's hardware. A 7404 might cost a quarter; a MAX-232 maybe $1.60. Not too expensive in either case. There are other areas of conservatism in my design. My blocking diode for the open collector simulation circuit is typically a Schottky or crystal diode, which may cost a quarter or so. But a 1N914 at one or two cents apiece will probably work as well. See, you have the diode's forward drop plus the minimum voltage of the gate being applied to the SIO bus as logic zero, and TTL doesn't like its logic zero being over a few tenths of a volt. (Four tenths per the Atari Technical Reference Notes.) But if I were buliding one for myself and just had 1N914's in my junk box, I'd use one.

Did I know that there's a MAX-233 which works like a MAX-232 but doesn't require capacitors? Yes, but this time I opted for lower cost and the same performance. The '232 is very popular, second sourced by other manufacturers, and available from a number of parts houses cheap. The '233 is less popular and hence costs about three times as much and isn't available from many places.

I've been asked a few times why I specified 22 uF capacitors. Some data sheets show other values.

The 232 chip is made by various manufacturers. One of the first data sheets I saw showed 22 uF capacitors, although it indicated that the value was not critical.But the question has been raised before, and when I researched the issue I decided to change the sizes somewhat.

I now use 10 uF caps at terminals 2 and 6 and 4.7 uF at 1,3 and 4,5.

I know that there are chips that don't need caps at all, or perhaps use much smaller caps. If you use those versions of the chip, then just go by the data sheet.

Back to the Top

What does the software do?

Glossing over a million details concerning SIO2PC's extra features, at its simplest level it emulates the Atari disk drives (and other peripherals) in responding to a basic set of commands sent out by the Atari over the SIO bus. It's because these commands are so basic that SIO2PC can work independent of Atari DOS versions and also work with boot files, boot loaders, sector editors etc. The basic commands are PUT SECTOR, GET SECTOR, GET STATUS, FORMAT. The protocol for these commands is unique to Atari and rigidly prescribed. A certain set of information, initiated by the Atari computer and responded to by the disk drive must be sent within certain time limits for an action to be completed successfully. SIO2PC creates a virtual Atari drive on the PC by mapping sector data to the PC's ram space and/or disk space.

What's required to use SIO2PC?

You need an Atari 8-bit computer, a PC computer equipped with a serial port and an SIO2PC interface (cable). SIO2PC will run on the oldest, slowest PC hardware. If you're using the system to transfer Atari files to the PC, you will also need (at least initially) an Atari compatible disk drive such as the 810 or 1050.

I don't believe SIO2PC will work on an Atari ST emulating the PC.

Back to the Top

How fast is SIO2PC?

Because the Atari is running in its fully native mode (no drivers or modifications needed) when using SIO2PC, the serial bus is running at the same 19,200 bits/second speed it uses with real drives. But with SIO2PC, disk latency is eliminated. (This refers to the time it takes for the disk to spin around and position the correct sector under the head.) When I timed typical file loads, SIO2PC was approximately twice as fast as an 810 drive as a result of this.

Could it be made faster? Yes, there are a couple of ways this could be done. One way is to increase the speed of the serial bus. There is a version of SPARTADOS which does this with specially modified Atari drives. I have programmed SIO2PC to work with this DOS and jump to about 38,000 bits/second when it is used. There's a limit to how fast we can go with this method, primarily because the discrete speeds attainable on the Atari and the PC start to diverge as we move much above 19,200.

Another method would be to use some sort of unclocked, bit-banging/handshaking method using the joystick ports or lines available in the SIO port. Again, doing this would require a modified Atari DOS which would redirect normal SIO bus I/O to a special handler. Since I'm not aware of such a DOS, the option isn't available to me at this time. (I have written software to link two Ataris by this method using joystick ports. It worked well and was pretty fast.)

Back to the Top

Can I convert my Atari files to PC files instead of disk images?

Yes. Using the supplied SIO2PC utility FILE2PC, you can convert Atari files to native PC files, ready to be picked up by your PC's word processor (or whatever ...). SIO2PC will not directly (without an Atari computer connected) extract files from an existing disk image and convert them to PC files. However, there are utilities by others that will do this. Follow the Atari Web Ring links to find a number of programs that will display the directories of .ATR disk images, extract files from them, etc. Another way to do this is to use the PRINT-THRU option of SIO2PC.. You will print the file on the Atari and have the printer's output captured to a file on the PC. An advantage of this method is that you can have the system do conversions of Atari specific ATASCII codes to plain ASCII codes.

Back to the Top

Can SIO2PC give my Atari access to plain PC files not installed in disk images?

Yes. SIO2PC has a feature which lets you install a PC file as a virtual disk image compatible with Atari DOS 2. Your Atari will see the file name in the directory and can access it via normal DOS commands.

Can SIO2PC emulate different disk densities and different sizes?

Yes. It works with both single and double density and it emulates the various standard Atari disk sizes as well as custom sizes, including very large disk images. The README.TXT file discusses tips and pitfalls of large/custom disk image sizes in tedious detail. Fire up the espresso maker before reading.

Back to the Top

Can SIO2PC be used as an RS-232 interface?

Well, yes … I mean no … sort of. It does take care of the translation of voltage levels. But RS-232 includes data in, data out and a number of handshaking lines. The reason for my equivocation is that different applications will use zero or more handshaking lines. The SIO serial bus only requires one, the command line, so that's all SIO2PC gives you. And it's connected to the seldom used RI (Ring Indicator) line on the PC end. So it comes down to what is required by the software you plan to use on both computers. Some software is configurable--you can specify XON/XOFF and use just the data lines, etc. But in general if you want to use software that requires more than a command line to RI conversion, you need to figure out what your software needs. Then take my schematic, add more MAX-232's if necessary and carry more lines through.

This question could also be taken to mean, "Does SIO2PC emulate the R: device of the 850 interface?" The answer to that is no, it doesn't..

Back to the Top

What is 1050-2-PC?

1050-2-PC is a device used to allow the PC to communicate directly with an Atari disk drive. It requires hardware which is very similar to the SIO2PC but configured differently. It allows direct sector I/O with the Atari drive and can be used to create disk iamges which will emulate copy protection schemes when run on SIO2PC. For more information, see 1050-2-PC.TXT. To view the schematic, click here.

Back to the Top

Can SIO2PC be used with copy protected Atari programs?

Yes, SIO2PC is capable of emulating bad sectors, which will allow many copy protected programs to run after being loaded from SIO2PC. The method of analyzing the disk to be copied and getting the data into the SIO2PC disk image is somewhat complicated and is discussed in detail in SIO2PC's README.TXT file. It can be done manually using sector analysis tools, or automatically if a 1050-2-PC interface is available.

Heres a text file that tells more about 1050-2-PC and its usage: 1050-2-PC.TXT

Back to the Top

Where do you find detailed technical information on the Atari?

One of the best things about the Atari 8-bit computers is the availability of very detailed technical information. In order of preference I recommend, Atari Technical Reference Notes, De Re Atari and Mapping the Atari.

Technical Reference Notes is a great reference and actually three books in one: OS Manual, Hardware Manual and OS Source Code. Together they provide details on all facets of the OS and hardware including schematics and logic diagrams. I believe this book is still available and reasonably priced.

De Re Atari is a well written little book containing not only technical details on use of CIO, SIO, Antic etc., but also also providing valuable thoughts on things like human factors considerations in programming.

Mapping the Atari is a listing, in numerical order, of Atari memory addresses and how they're used by the OS, SIO, CIO, Basic, DOS and so forth. But it's the depth of discussion, insiders tips and examples of how functions associated with these addresses are used that make the book more than a mere memory map.

Back to the Top

Please provide basic technical information on serial bus protocol(?)

I thought you'd never ask. I'll attempt to provide you with the information you need to create your own device and put SIO2PC and APE out of business!

Bus protocol: 19,200 baud, one start bit, one stop bit

All bus operations are initiated by the sending of a command frame by the Atari. The command frame consists of five (5) bytes:

Device ID
Command
Aux1
Aux2
Checksum

Device ID is $31 thru $38 for D1: thru D8:
Commands are 'R' for Read, 'W' for write, 'P' for put, 'S' for status request.
Aux1 and Aux2 contain the low and high bytes of the sector number, for commands involving sector I/O.
Checksum is the sum of the above four bytes with the carry added back in.

OK. All peripherals are hearing all transmissions from the Atari at all times. How do they know a command frame is coming? That's the function of the Command Line, the only handshaking line used by the SIO bus (and SIO2PC). It is normally held at a logic 1 or high voltage level. When the Atari lowers (sets to logic 0 or 0 volts) the Command Line, the peripherals are being told to "listen up."

Described below is what actually happens on the bus during common operations involving disk I/O:

For sending data (a sector) to the drive:

1) The computer lowers the command line. Then a delay of 750 to 1500 uS (microseconds), then
2) The computer sends the five byte command frame described above. After the last bit has been sent, there is a delay of 650 to 950 uS, then
3) The computer raises the command line.
4) The peripheral is permitted to delay 0 to 16 mS (milliseconds) before,
5) The peripheral sends an 'A' for "acknowledge", the computer then delays 1000 to 1800 uS, then
6) The computer sends the data frame, which is 128 bytes of sector data plus a checksum byte with end-around carry, then
7) The peripheral is expected to delay 850 uS (min) to 16 mS (max) and send another 'A', then
8) The peripheral can do whatever it may need to do to process the data, taking 250 uS (min) to 255 seconds (max), then sending a 'C' (Complete) byte to end the transaction.

It should be noted (and obvious) that for the above operation, the command frame bytes contained the ID for the drive being addressed, the command byte of 'W' (or 'P' for Put), Aux1 & Aux2 contain the sector number to be written, and the checksum is the sum of the above.

For receiving data (a sector, or status) from the drive:

1) The computer lowers the command line. Then a delay of 750 to 1500 uS (microseconds), then
2) The computer sends the five byte command frame described above. After the last bit has been sent, there is a delay of 650 to 950 uS, then
3) The computer raises the command line.
4) The peripheral is permitted to delay 0 to 16 mS (milliseconds) before,
5) The peripheral sends an 'A' for "acknowledge", the computer then delays 1000 to 1800 uS, then
6) The peripheral is allowed to take 250 uS (min) to 255 seconds (max) to complete the operation, then
7) The peripheral sends a 'C' for Complete, then
8) The peripheral sends the data frame (sector data plus checksum)

For Immediate (no data) command (such as format):

1) The computer lowers the command line. Then a delay of 750 to 1500 uS (microseconds), then
2) The computer sends the five byte command frame described above. After the last bit has been sent, there is a delay of 650 to 950 uS, then
3) The computer raises the command line.
4) The peripheral is permitted to delay 0 to 16 mS (milliseconds) before,
5) The peripheral sends an 'A' for "acknowledge", the computer then delays 1000 to 1800 uS, then
6) The peripheral is allowed to take 250 uS (min) to 255 seconds (max) to complete the operation, then
7) The peripheral sends a 'C' for Complete, then

There. Now that you know that stuff, you can start programming your own thingy to emulate the behavior of an Atari computer or peripheral. How would you even start? You would want to write routines that:

Put one byte to the bus (and put a buffer of bytes ...)
Get one byte from the bus (and get a buffer ...)
Timer routine to generate delays of variable length
A routine to set or monitor the status of the command line
A routine to do the initial configuration of the serial chip (UART)
Routines to assemble or receive command frames and act upon them
Routines to get/put sectors to and from memory and/or files
Lots of other bells and whistles

If you decided to do something as crazy as writing a program to interact with the Atari SIO bus, what other info and tools would you need? Well, assuming you're going to use assembly language and write the program on the PC, I'd recommend these items:

A great assembler. Go with A86, the shareware assembler and eliminate all the brain damage associated with learning weird and unnecessary commands and directives you must get exactly right before you even type the first opcode. With A86 there's no preamble and no END statement, plus it's faster and better than big name assemblers.
A data sheet for the serial chip (UART), which is an 8250 or 16550 or somewhere in between. These chips are backward compatible, so you could generally use any data sheet.
A data sheet for the timer chip, the 8254 will be useful if you're going to be reprogramming that chip. (Not absolutely necessary.)
A book or books on the PC which includes: DOS calls (interrupts), BIOS calls and hardware addresses. There are a lot of books out there based around listings of DOS and BIOS calls and they can get a bit redundant. I recommend The Waite Group's MS-DOS Bible (Howard W. Sams) and Dettmann's DOS Programmer's Reference (Que). For hardware info, Thom Hogan's The Programmer's PC Sourcebook (Microsoft Press) is good. It's a big book of nothing but tables of info. The Hardware Bible is OK too. You can probably find a lot of the hardware info on the net and save the cost of another book, though.
Of course you need a book or books on assembly language programming for the 8088. If you already do assembler, just a reference book like one from Intel is the best. I use Intel's 80286 and 80287 Programmer's Reference Manual.
And of course, Atari technical info, which I listed under another section of this FAQ

Here's the pin-out of a couple of important connectors:

1 2 3 4 5
6 7 8 9

Above is the view of a DB-9F connector, which is what plugs into the serial port of your PC. This is the rear view, so it's looking at the back of the connector, where you'd solder your wires. This also makes it the front view of the connector on your PC. Sorry I couldn't indent the second row and make it look more like the actual layout, but html is html. Anyway, the pin assignments are:

PC serial port connector (DB-9) pins used by SIO2PC:

2 data in (to the PC)
3 data out (to Atari, modem or whatever)
9 RI (ring indicator), which is an input to the PC that I use for the command line
7 RTS (request to send) an output from the PC I use with 1050-2-PC
5 Ground

Not used by SIO2PC:

8 CTS (clear to send) is an input to the PC
1 CD (carrier detect) is an input to the PC
6 DSR (data set ready) is an input to the PC
4 DTR (data terminal ready) is an output from the PC

SIO connector on the Atari:

2 4 6 8 10 12

1 3 5 7 9 11 13

Above is the view looking into the connector on the Atari computer or peripheral.

Clock In
Clock Out
Data In
Ground
Data Out
Ground
Command
Motor Control
Proceed
+5 Volts/Ready
Audio In
+12 volts (not available on XL/XE
Interrupt

Note that the Atari hardware has stuff designed into this port that was never used by the OS. The clocks, for example. Also note that some of the lines are connected to POKEY and some to the PIA chips. You need the Technical Reference Notes if you want to get into all of this weirdness. Also, I've seen some debates about the mysterious differences between the two ground pins, but I'm pretty sure on my old '800's motherboard they're both soldered to the same circuit board pad.

Help!! What if my SIO2PC hardware (or software) won't work right?

Hardware: First, if your Atari won't even come up with the familiar blue screen with READY or Memo Pad prompts or whatever, shut it off. You may have a short in the interface pulling the power supply down to nothing. Besides the screen, check the pilot light on the Atari if your model has one. Check resistance between the +5 V and ground points in your interface and make sure it's not zero ohms or close to it before proceeding.

Assuming that things light up but you aren't getting any response at all, you need to make sure the hardware is working. Make sure you have 5 volts between pins 16 and 15 of the '232 IC chip. Then make sure the charge converters and gates are working by checking the following with the interface plugged into the Atari but not necessarily to the PC:

About -10 volts, pin 6 of the IC to ground
About +10 volts, pin 2 of the IC to ground
About -9 volts at pin 14 of the IC, also seen at pin 2 of the serial connector
About -9 volts at pin 7 of the IC and also seen at pin 9 of the serial connector
With the cable plugged into Atari and PC, you should see about -9 volts on pin 3 of the PC cable, carried thru to pin 13 of the IC. This should be converted to about 3.5 to 5 volts on pin 12 of the IC and 5 volts at pin 3 (orange wire) of the SIO cable.

Please note that the + and - 9 or 10 volt readings above can vary by a couple of volts or maybe more. I usually see about 9 volts magnitude.

OK, you think the interface is wired right and working. Now, are you sure you selected the right serial port number on the PC? Make sure of this. Do you see any action on the status line of SIO2PC (the bottom row of the screen) when you turn on the Atari? If you're seeing stuff appear in the command field and sector number field, your hardware is probably working. If you see the command line status flicker from H to L a few times but nothing else, then maybe the command line is working but the data line isn't.

Diagnosing individual lines:

Strangely enough, I have seen some PC serial ports working on some lines but with other lines dead. Perhaps not so strangely, I've also seen some lines of recently completed SIO2PCs not working because of a wiring error. I wrote a program (two, actually) to diagnose this. You can wiggle a line's status on one computer and see it change on the other. On the SIO2PC program, the diagnostic menu is under the "A" menu choice as another sub-menu. On the Atari, you have to run a program called DIAGS.OBJ. This can lead to a Catch-22 situation. How are you supposed to run DIAGS on your Atari when SIO2PC won't work? Well, maybe you can find a way to copy it from the native PC file or .ATR image to an Atari disk. Or if you want, send me a mailer and I'll send you a copy.

Here's a text file with details on the diags program/function: DIAGS.TXT

Software Problems:

Usually reported as working haltingly, sputtering along, etc. Here are some causes:

Running under windows in a DOS box. I found that you could run under windows 3.1 if you set up parameters (a PIF file?) giving SIO2PC top priority. The big problems running SIO2PC (or any serial communications program) under windows is that windows likes to keep checking and interferring with things, even when there are no other applications running. It assumes if the running program is not receiving any keystrokes it doesn't need any processor time. Windows 95 is much worse (surprised, eh?). You can't give your program top priority under W-95 so don't even try to run it in a DOS box; just start up in DOS.
Interference from another serial device. Just because you've unplugged your mouse, don't assume the driver isn't still there causing trouble. Also, a mouse on the same odd/even basis may cause trouble, e.g. having SIO2PC on COM3 and the mouse on COM1.
Timing problems. This one has driven me crazy over the years. If you've waded thru the technical information part of this FAQ, you see that there are some well defined timing limits between elements of the SIO2PC data transfer protocol. You'd think that by using actual hardware timers rather than relying on cycle counting, you could make the system immune to problems with PCs having vastly different clock speeds. You'd be wrong! Anyway, after moving various time values up and down in roller-coaster fashion in response to users' input, I finally made the time delays adjustable by the user. Nowadays, I hesitate to knee-jerk to a hard coded change to default values when I hear of problems. I pass along the info instead. My latest good tip on the subject is from Bo and Ernest Schruers who reported that on their Pentium 133 Mhz, changing T4 and T5 from 0300 all the way down to 0010 got rid of some erratic operation they were seeing.

I guess I should tell you how to make these changes. On the SIO2PC menu is choice "A" for Alter Timings. This brings up the list of timing values and displays the default values and current values. Don't be afraid to experiment with them if you are having problems. In my README.TXT document, I tell how to use DEBUG to make changes become permanent.

Back to the Top

What is the structure of an ATR disk file?

STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:

There is first a 16 byte header with the following information:

WORD = special code* indicating this is an Atari disk file

WORD = size of this disk image, in paragraphs (size/16)

WORD = sector size. (128 or 256) bytes/sector

WORD = high part of size, in paragraphs (added by REV 3.00)

BYTE = disk flags such as copy protection and write protect; see below:

The 9th byte of the header contains information in individual bits. Bit 4 = 1 means the disk image is treated as copy protected (has bad sectors). Bit 5 = 1 means the disk is write protected.

WORD=1st (or typical) bad sector; see below:

The 10th and 11th bytes of the header are a word which contains the number of the first (or of a typical) bad sector. What I mean by typical is that it does contain both bad sector status and good sector status. See the section in README.TXT or in 1050.TXT on copy protection emulation to learn what goes in those sectors.

SPARES 5 unused (spare) header bytes (contain zeroes)

After the header comes the disk image. This is just a continuous string of bytes, with the first 128 bytes being the contents of disk sector 1, the second being sector 2, etc.

* The "code" is the 16 bit sum of the individual ASCII values of the string of bytes: "NICKATARI". If you try to load a file without this first WORD, you get a "THIS FILE IS NOT AN ATARI DISK FILE" error message. Try it.

Back to the Top

Errors? Unclear parts? More Questions? email me ...

Nick Kennedy is kennnick@gmail.com