New P:R: device for the Atari?

[ataridano]

I've been thinking about creating a new R: device for the 8-bit for a long time, it seems like a simple enough device, just a matter of figuring out the SIO bus and maybe creating a new handler (the biggest stumbling block for me). I gave up on the idea when I ordered a MIO, but now things have changed. We use a device at work that was designed to talk to a serial printer. Serial printers aren't easy to come by today, and commercial adaptors seem to run about $100 each. So to cut costs, I've made one from scratch. Well, what I ended up with was a board that has one RS-232 serial port, one parallel port, and a microcontroller that has 2 UARTs running the thing. So what do I do? While I'm at it, I add a 13 pin headder to the board and the hardware needed to connect to the Atari, with different code it should work as an 850 replacement using the same exact hardware. Here's where I'm stuck: If I want to get this thing working in my lifetime, I need to keep it simple As I understand it, the 850 and other Rverter type interfaces basically connect the RS-232 straight to the SIO bus and pass the bits through. I won't be doing that, I'll actually have a UART on each end, so I'll have to talk to the Atari at a standard speed (I may add a high-speed mode but for now one speed) regardless of the baud rate that the external device uses. I'll also need some pointers to documentation about the SIO command structure for R: and P: devices. While this won't be as simple as other devices, it will allow high speed communication and full flow control. I will still have to actually run the boards and will probably need help on the handler side, is there any interest?

[Rybags]

APE/SIO2PC does a similar thing.

 

You could probably expand on that design.

 

You'd probably want the hardware handshaking lines too? (CTS, RTS, etc.). They could be implemented using a joystick port for output.

 

I assume the handshaking lines use the same RS232 voltages. Not sure how many lines the 1489 IC handles - you'd probably need another one.

[ataridano]

Wow, I hope this doesn't get too confusing! SIO2PC and APE probably/maybe do something similar, but my plan is a 3x4" circuit board and no PC so it'd be a bit smaller. What can I say, I like having true "Atari" hardware, if you can call it that. No joystick ports (what if I want to use a joystick or mouse?), everything is controlled via SIO commands, or internally. The board currently includes CTS/RTS and DTR/DSR, it lacks CD and RI (let me know asap if that's bad, but the intended purpose of this device is for serial to parallel printer I/O so I need to keep the deisgn simple). I'm not using the 1488/1489 but rather a Max232 or similar, as only a 5V supply will be included, and it probably could run from SIO voltage. I'll try to give a better description...this device will talk at the standard SIO speed (what is that, 19.2k?) between it and the Atari, and will talk to the outside world at anything from 300 baud to 115.2k. Of course with the higher speed, flow control would be needed as it would be faster than the SIO link. The device would take care of flow control on it's own, or listen for SIO commands from the Atari to toggle flow control, I'm not sure yet which makes the most sence. At this point I will probably just try to get it working at speeds up to 19.2k and without flow control and work on the buffering second. Oh, the Rverter uses the cassette motor line for flow control, right? That could be supported as well.

[+warerat]

As I understand it, the 850 and other Rverter type interfaces basically connect the RS-232 straight to the SIO bus and pass the bits through.

 

The 850 was actually a different animal than the R-Verter-- it had a 1.1 MHz 6507, two RIOTs, and a 4K ROM, so the serial ports were bit-bangers. Hell, add a TIA to it and you'd have a 2600 with twice the RAM (just kidding).

 

But I don't see why you couldn't do a driver to talk to your device and emulate all the XIOs the 850 had. Cool idea. I thought about doing something like that with a 68HC11 a while back but never got around to doing it. I know Percom drives use a 6850 UART to talk to the SIO, but they're fixed at 19.2K.

[ataridano]

 

The 850 was actually a different animal than the R-Verter-- it had a 1.1 MHz 6507, two RIOTs, and a 4K ROM, so the serial ports were bit-bangers. Hell, add a TIA to it and you'd have a 2600 with twice the RAM (just kidding).

 

But I don't see why you couldn't do a driver to talk to your device and emulate all the XIOs the 850 had. Cool idea. I thought about doing something like that with a 68HC11 a while back but never got around to doing it. I know Percom drives use a 6850 UART to talk to the SIO, but they're fixed at 19.2K.

 

For some reason I thought that the 850's 6507 just routed I/O to the right serial port, or did serial -> parallel for the printer. What I really need to get the project going is a detailed description of what I should expect to see from the Atari (like "you'll get X bytes, this is what they mean, and they are sent at 19,200 8N1") as well as someone willing to help out with the handler. I can handle the firmware and hardware but don't know much about SIO, might have to reverse engineer it worst case. Also, I looked at the Rverter schematic and it looks like RI is connected to the SIO Interrupt pin, is that correct? Need to get this board built ASAP so thoughts on this stuff is a big help!

[+warerat]

 

The 850 was actually a different animal than the R-Verter-- it had a 1.1 MHz 6507, two RIOTs, and a 4K ROM, so the serial ports were bit-bangers. Hell, add a TIA to it and you'd have a 2600 with twice the RAM (just kidding).

 

But I don't see why you couldn't do a driver to talk to your device and emulate all the XIOs the 850 had. Cool idea. I thought about doing something like that with a 68HC11 a while back but never got around to doing it. I know Percom drives use a 6850 UART to talk to the SIO, but they're fixed at 19.2K.

 

For some reason I thought that the 850's 6507 just routed I/O to the right serial port, or did serial -> parallel for the printer. What I really need to get the project going is a detailed description of what I should expect to see from the Atari (like "you'll get X bytes, this is what they mean, and they are sent at 19,200 8N1") as well as someone willing to help out with the handler. I can handle the firmware and hardware but don't know much about SIO, might have to reverse engineer it worst case. Also, I looked at the Rverter schematic and it looks like RI is connected to the SIO Interrupt pin, is that correct? Need to get this board built ASAP so thoughts on this stuff is a big help!

 

The 850 was a kludge, which is why it couldn't go past 9600 bps. It had to handle all the bit timing manually as there weren't any real UARTs in it. If I remember correctly the only SIO pins the 850 used was the serial in/out, command, and the power pin as a reset (so when you powered off your Atari you'd reset the 850). But any low level communication with SIO and your device can be however you want. It's the high-level driver that will just use the same 850 commands if you wanted to keep it compatible. You could even put the R: and P: driver on a ROM and send it over like the 850 did (which I thought was kind of cool, the P:R: did it too). Not knowing what hardware you have, you could just have a simple command set you'd use to send data/status back and forth from SIO. The more complex you make the firmware on your embedded CPU, the simpler you could make the information exchange. For example, just have commands to get/put serial a byte, put parallel byte, set uart, get uart stat. Like you said, you would use one of your UARTS at a fixed 19.2K rate, so that would make it easy (8-bit data, one start bit, one stop bit). For starters, look up the Atari Technical Reference manual-- it has the technical specifications how to use the SIO routines in ROM to send data and command frames.

[Rybags]

SIO is fairly straight forward.

 

Since you're creating a new device, you're free to create your own standards in a way, so far as command sets and data frame sizes.

 

You'd do well to check out the OS manual for the SIO protocols - I consulted it when I made a 1050 emulator on the ST years ago (via it's parallel port).

 

Why stick to 19,200 baud? Since you're doing a RAM-resident handler on the Atari side, you could got the extra distance and support faster transfer rates.

[drac030]

The 850 manual is here:

 

http://www.strotmann.de/twiki/pub/Infothek...ro/850ATARI.pdf

 

As it was said before, the device such as 850 contains its own handler, and it sends it to the computer at certain conditions (described in the manual, IIRC - if not, I think I can supply some information).

 

The handler installs as "R:" device in the OS, receives OPEN/CLOSE/GET/PUT/STATUS/XIO commands from applications (the commands are explained in the manual in details and examples in BASIC), and then converts them to SIO commands and talks to the device.

 

As you see, what are the actual SIO commands and what they do is completely up to you. Obviously, it is best to mimic the 850 behaviour, but it is not absolutely necessary.

[danwinslow]

I have some code in C from an ethernet project that reads SIO...I'd be glad to send it to you if you are interested. PM me if so. Or you can just google around for 'atari SIO protocol' and stuff like that and you'll find a bunch of info.

[Mathy]

Howdy folks

 

The 850 can do 19k2 but you have to write to the correct Pokey addresses directly.

 

Would it be possible to link multiple interfaces to each other? That way, one would be able to build a kind of network.

 

Greetings

 

Mathy

[ataridano]

Here's the latest, I have the board done and will order tomorrow. Okay, here's my current plan: I'm not sure how exactly the 850 shares the SIO bus, but I assume that a channel is open to a given serial port, and all communication from that point on goes directly to that port until the command line goes active signaling a halt to communication. Otherwise, how can drive I/O happen as you never know when you might be getting a byte in on the serial port? Assuming something like that is the case, I plan to support baud rates up to 19,2k initally by simply passing bytes back and forth between the SIO and outside world with the assumption that my code overhead won't leave enough time for buffers to overflow. Otherwise, up to 9600 baud. Once that is working, I look into switching the SIO speed to something a little faster than 57.6k (I don't believe the SIO divisior allows that exact speed) which hopefully I can match, and then do the same thing, pass bytes back and forth as fast as I can until another SIO command comes down the bus. Am I on the right track? On the question of linking multiple interfaces, I probably won't do what you have in mind. An adapter to something like RS-422 would allow multiple machines daisy chained, but the code would need to be written. Of course a two computer peer to peer network could be done with a nul-modem. I do plan to use switchs such that up to 4 (more or less?) of these can be used at once just like disk drives, can be addressed so that they share the bus. If I do get the hang of how the SIO command structure works, I might work on a network board next! I also hope to include the handler code for auto loading, but unfortunatly that probably means hand-keying it into my firmware directly! Thanks for the feedback!

[Rybags]

Command frames are the essential driving factor for SIO.

 

Devices on the bus sit idle and wait for a command frame.

 

During the command frame, a device ID (which should be unique for each device on the bus) is sent. Along with devID is the command, Aux1/2 values and the checksum (calculated the standard Atari way).

 

The device should then return an ACK response (assuming the command and aux values are valid for that device).

 

The device then either performs the command or waits for a data frame. Since the command line is no longer active, other devices simply return to idle mode.

 

There are also ACK/NAK/Complete responses expected along the way.

 

Pretty much all the info you need is on pages 135-140 of the OS manual.

[ataridano]

Command frames are the essential driving factor for SIO.

 

Devices on the bus sit idle and wait for a command frame.

 

During the command frame, a device ID (which should be unique for each device on the bus) is sent. Along with devID is the command, Aux1/2 values and the checksum (calculated the standard Atari way).

 

The device should then return an ACK response (assuming the command and aux values are valid for that device).

 

The device then either performs the command or waits for a data frame. Since the command line is no longer active, other devices simply return to idle mode.

 

There are also ACK/NAK/Complete responses expected along the way.

 

Pretty much all the info you need is on pages 135-140 of the OS manual.

 

Is there somewhere on the 'net that I can find the OS manual? Sounds like exactly what I need.

 

So in the case of, say, talking to a modem using an 850, the Atari would send a command frame to the 850 to open a port, and then would listen to the SIO line for any data recieved by the modem. If disk access were needed, it would send a command to the 850 to close the port or send a command to stop I/O via flow control, so that data from the modem and sectors from the disk wouldn't be on the bus at the same time? That's the only place I'm not 100% clear yet, it doesn't make sence to send a frame for "write byte" and "read byte" because a) the framing overhead would way too much, and b) the Atari has no idea when a byte is recieved from the modem without either poling or giving the 850 control of the bus. If I understand things right, this might be easier than I thought. Who wants to help by making a handler for me

[Rybags]

Since I/O to other devices is transparent (refer command frames), there's no real reason to have to close a modem connection just so you can write a disk sector.

 

The concept of Atari SIO is for a shared bus, where I/O is not simultaneous, but can be performed among devices at random without having to close files, empty buffers etc.

 

If you're talking to a modem, wouldn't you be mostly doing record oriented I/O anyway? Even if many of those records were only several characters long (e.g. Telnet to a BBS).

 

Writing a handler should be fairly easy. It would probably be best if you could get your device to adhere to the basic SIO standards if possible - that would allow the OS routines to be used (although faster I/O would require custom routines).

 

C016555_part3.zip

 

That's the part of the OS manual I was referring to before. Can't remember where I DL'd it from.

 

I'd suggest XL-Search might have a link for the full manual.

[ijor]

Command frames are the essential driving factor for SIO.

 

Devices on the bus sit idle and wait for a command frame.

...

 

That's the only place I'm not 100% clear yet, it doesn't make sence to send a frame for "write byte" and "read byte" because a) the framing overhead would way too much, and b) the Atari has no idea when a byte is recieved from the modem without either poling or giving the 850 control of the bus.

 

That's right, the above bus protocol has an exception. Look in the manuals for concurrent mode.

[ijor]

I was trying to find official Atari specs for the concurrent mode, but I couldn't find them.

 

At quick glance the OS manual doesn't seem to mention concurrent mode at all. It is described in the 850 manual. There the CIO interface seems to be complete, but the SIO level is only briefly described.

 

It is possible that this was never formally documented by Atari. I don't know/remember. I also don't remember if the source of the 850 R: handler and/or ROM was published or not.

 

What I did find is a complete description of how the P:R: connection handles concurrent mode. I don't know the level of compability with the 850. But probably this is not very important for you. So just check the user P:R manual, it describes everything in technical details and also includes full source listing for their R: handler.

[drac030]

URL?

[ijor]

URL?

 

You mean for the P:R: Connection user manual? Sorry, no idea. I checked a hardcopy. It is the standard manual that comes with the device. So being so common, I suppose it is available on-line somewhere. Or it isn't?

[+warerat]

URL?

 

You mean for the P:R: Connection user manual? Sorry, no idea. I checked a hardcopy. It is the standard manual that comes with the device. So being so common, I suppose it is available on-line somewhere. Or it isn't?

 

I have a P:R: user manual I can scan up if it isn't already out there.

[drac030]

Well, I don't know, if it is available on-line or not. Maybe it is me, who just can't find a copy - but maybe it is really not available

[ataridano]

Thanks for all the help, I think I know enough now to be dangerious Yes, concurrent mode is definetally what I need. If you could scan that manual, that would be a great help. Actually, I might even be able to have some level of compatibility with the P:R: Connection. Also, the OS manual is missing Appendix I which has all the SIO commands listed. My first project is going to be to make the board output all SIO commands to a terminal, just so I can prove to myself that it is working. Then I'll try to actually make it work with an R: handler. One last question about concurrent mode: If I have a connection open, and get a command on the SIO bus for another device (say a write to a disk drive) do I close the connection or just use flow control to "pause" it until the SIO bus is free? Or will the Atari tell me that I'm not going to be in concurrent mode any more? I should have boards by Monday!!

[Rybags]

If you get a command for another device, just ignore it.

 

As I said before, command frames are used to define the start of I/O operations, therefore the device merely needs to ignore the SIO bus completely until the appearance of the next command frame.

 

So, you'll obviously need firmware on the device side. The APE interface just passes everything through, but obviously, in it's case, all the intelligence is contained within the APE software on the PC.

[ataridano]

If you get a command for another device, just ignore it.

 

As I said before, command frames are used to define the start of I/O operations, therefore the device merely needs to ignore the SIO bus completely until the appearance of the next command frame.

 

So, you'll obviously need firmware on the device side. The APE interface just passes everything through, but obviously, in it's case, all the intelligence is contained within the APE software on the PC.

 

I understand that normally I would ignore command frames for other devices, but I was also told that I didn't have to close my RS-232 connection in order to send data to another device, like the disk drive. I just want to know if my firmware should ignore other commands *while in concurrent mode* as well, or is that even possible? If I'm getting a stream of data from a modem, and want to write to a floppy, I need to stop the modem somehow while I talk to the floppy, and then resume recieving data from the modem. Yes, I will do in firmware what APE does on the PC, maybe Steve of Atarimax fame is listening? I know he knows this stuff! The problem I have right now is that I know I have to use concurrent mode yet I have no documentation to give me any clues as to how exactly it works.

 

One more question, is there a way to switch between hardware/software flow controls in most terminal emulators, or do I need to provide a switch for that?

 

Sorry if I'm slow in getting all this stuff!

[ijor]

If you could scan that manual, that would be a great help.

 

I don't have any easy/quick way for scanning the manual. If it's indeed not available on-line and warerat (or somebody else) can't scan it, I will try. warerat, you'll do me a big favor if scanning is not a big trouble for you.

 

I understand that normally I would ignore command frames for other devices, but I was also told that I didn't have to close my RS-232 connection in order to send data to another device, like the disk drive.

 

When in concurrent mode, nothing at all is allowed in the SIO bus except plain data. Because that's what concurrent mode is all about. The computer sends bytes over the SIO bus without any framing or records, and the device send them over the RS-232. The devices in turn forwards any bytes coming from the RS-232 to the SIO bus.

 

So you must exit concurrent mode before doing anything else.

 

I just want to know if my firmware should ignore other commands *while in concurrent mode* as well, or is that even possible?

 

Any command while in concurrent mode automatically exit concurrent mode. More precisely, lowering CMND is the standard way to end concurrent mode. The ICD handler just pulses CMND for a small period without any actual command frame when it wants to exit concurrent mode.

[Rybags]

On the Atari side, your device driver isn't even aware of I/O over SIO, unless it receives a GET or PUT request for your device.

 

Therefore, legacy I/O type ops to stuff like disk drives and Atari type printers will be totally transparent.

 

For modem I/O, I assume you're device will need some sort of way to poll the Atari to let it know a packet of data is incoming?

 

In such a case, you'd probably be looking at using the Interrupt line over SIO.

 

Unsure of the standards there - most (all?) existing drivers on the Atari only initiate I/O, unsure if they respond to unsolicited external requests.

 

One thing in your favour is that the Atari is single-tasking, although in a way it is multitasking by having multiple files open over SIO devices at once.