Accessing R: handler without device present

[freetz]

Hi everyone,

I'm trying to come up with a Arduino-based device that allows access to Arduino shields, sensors etc. by means of accessing this device via the R: handler.
On the hardware side, I've already set things up (all you need is Data In, Out, Command and GND), and when the device is connected, I can see the typical command frame on the serial interface of the Arduino when the ATARI boots up.

What puzzles me, however, is that no other devices seem to send anything on the SIO bus if the device is not connected. For example, when I tell DOS to list the directory on a printer with

*.*, P:

I only get the error on the ATARI, but no data shows up on the bus.

 

The same goes for accessing the R: handler with any of the drivers known to me which come with Itay's ICE-T disk image, as well as the ARGS drivers (https://atariwiki.org/wiki/Wiki.jsp?page=ARGS%20RS232%20Cartridge). For example, the PRCONN driver loads fine, and when accessing R: through a simple BASIC program, such as

OPEN #1,4,0,"R:":FOR X=1 TO 1000:GET #1, A:PRINT A:NEXT X

prints "1" repeatedly, but nothing comes up on the bus.

 

My plan B would be to implement access via one of the unused disk drive ids (such as D7: ), becaus that apparently seems to work. But having it based on R: would make it more convenient to use with other programs, such as terminals like ICE-T and others.

 

If anone has an idea how to move on from here, I'd be very grateful.

 

Best,

 

F.

[Fox-1 / mnx]

Is there anything in between the SIO bus and Arduino port, hardware wise?

 

An R: handler on Atari usually expects some, quite simplistic, hokey-pokey logic to be present on the SIO bus. I think the most most basic approach would be an R:verter interface.

 

Also, see: http://atariage.com/forums/topic/279135-sio-from-basic/?do=findComment&comment=4034995

[freetz]

Thank you for your prompt response and the helpful link. No, it's directly connected to the Arduino, but there is a SIO2SD device built into my Atari. However, I have turned all SIO2SD disk drives off and I do get the command data frames when the Atari boots up and does not find a disk.

I was assuming that there is some kind of checking taking place to see if the actual hardware is connected, but I'm wondering how this is done without sending anything via Data In / Data Out. I thought that's what the command frame is for - that you send this data package on the bus and see which device responds and how. Because using the other lines would not make it possible to identify which device is connected, wouldn't it?

 

I'm not 100% sure if I tried the RVERTER handler. Do you know if it requires additional lines to be connected other than Data In / Out / Command?

 

I'll check the link and see if going the low-level way would be an alternative, but an R: driver would be better for compatibility.

 

Thanks a lot again,

 

F.

[Fox-1 / mnx]

I noticed your other posts...

 

PRCONN.HND and ATARI850.HND both expect an intelligent device to be present on the bus (P:R:C and Atari 850) so, unless you emulate their CPU behavior on the Arduino, those drivers aren't useful. Not sure about RS232.SYS but this may be a driver for "dumb" devices, like R:Verter.

 

From the top of my head... the required logic juggles a bit with the TX/RX/CMD signals. Without it frames won't pass because CMD has to be low/high or inverted when RX or TX is active, or the other way around. Well, something like that but I hope you'll get it :-)

 

Apart from that, also the baudrate on both devices has to match.

[freetz]

Thanks again, I'll make sure to try RVERTER, and I also understand that the 850 etc. expect a more intelligent device on the other hand, but they still have to send something on the bus in order to get an "intelligent" response, haven't they? And even if the baud rate is wrong, this would be just the "interpretation" of the values that come across the lines. Like when I set a modem to a wrong baud rate and get gibberish, but at least I do get gibberish and not nothing as in my case.

[vitoco]

IIRC, devices like 850 had the driver stored inside them and the Atari must download it as the first communication attempt.

 

I don't know if more complex and recent drivers replaced it completely or still depend on it.

[freetz]

Yes, that is correct, and also the reason why the 850 drivers are just one or two sectors long whereas other drivers are in the range of 10 to 20 sectors. The 850 drivers then make a call to the 850 which behaves initially like a disk drive and thus enables the downloading of the (much larger) driver into RAM. But that also means that the initial access of this driver is not via the R: handler, but through D:.

[Fox-1 / mnx]

Wrong baudrates will give rubbish data, but rubbish is indeed data too.

 

The 850 has an R: driver in it's ROM, ready to download by an Atari, but that's just one way to load the driver into RAM. One can load the same, or similar, driver afterwards from disk as well. At boot, the Atari O.S. does some polling on the SIO bus. If looks for a connected, intelligent device. If it finds a disk drive, CIO will try to boot from it and that's it. You'll end up with anything the disk drive spits out. In most cases this is DOS or a game or what but there are more advanced disk drives that push data from their ROM first, like Speedy disk drives.

 

If it finds an 850, it'll boot from that, which means the R: driver will be downloaded. Part of this process is the +5V line on the SIO bus. The 850 knows the Atari did a cold start (was powered up) because it monitors the status of it.

 

It's one or the other. If a disk boot happened, the 850 keeps silence. If the 850 booted, the disk drive does nothing.

 

This way you can easily boot the R: driver without using a disk drive, like when using cassettes. This is also why you need to execute a short piece of code when booted from disk to trigger the 850 and download the driver. Some terminal programs have this trigger built in (Bobterm), others don't (IceTerm).

 

At boot the Atari doesn't really look for a D: or R: device. It just looks for "a" device and acts upon. But still, it does look for something (or should be at least) at power-up as long START isn't pressed. That's why I think the little logic on the SIO bus is required because frames may not be sent when the Atari gets the wrong initial feedback.

[ivop]

You don't see any data when the command line is asserted or you don't see any data at all? Because dumb R-Verter-like devices don't use the command line at all. They turn on motor control to enable pass-through of the pokey serial lines which then behave as a full-duplex raw serial line.

[freetz]

Sorry for the delay in response, and thanks for your replies.

@Fox-1: Yes, I also read about this quite sophisticated way of getting the driver into the RAM of the Atari. And in the meantime, I also found the source code of the 850 driver (not just the 1-2 sector piece of code that initiates the loading process), will have to try it.

But during boot-up, the Atari does look for a D1: device at bootup because...

 

@ivop: that is the byte sequence I see when I boot up the Atari and have my Arduino connected to the SIO port:

0x31 0x53 0x00 0x00 0x84

This is a perfectly define command frame: The 0x31 is for D1:, 0x53 is the ASCII code for 'R' (i.e. read), then two zeros for AUX1 and AUX2 and finally the checksum. I get this sequence a couple of dozen times until the Atari gives up and jumps into Basic.

I would expect something like this when I access other SIO devices as well, like P: or R:, but nothing comes up.

 

What you mention about RVERTER not using the command line at all is interesting - so it just dumps data on the SIO bus without sending the command frame with information on the "recipient"? But what do they (have to) use the motor control line for? This is one of the lines I thought would not be necessary in my self-made SIO cable, so I left it out and just used 5V, GND, Data In, Data Out and Command Line.

 

The fact that even a built-in handler such as P: does not send anything on to the SIO bus (or at least nothing visible to me on the Arduino output) still puzzles me - or makes me wonder what other ways there are for the Atari to determine if a peripheral device is really connected before sending data out on the bus...

[ivop]

There are different versions of the R-Verter. The original uses MOTOR as RTS output and the PROCEED line for CD input (carrier detect) and optionally INTERRUPT for RI (ring indicator). The 2nd version also uses MOTOR to enable the serial bus, i.e. the connection to the MAX232 level shifter. This is fairly similar to how MIDI devices behave, but they even use the motor line as a power source. Anyway, in both cases a low MOTOR line disables the devices, so you can leave it plugged in during normal SIO operation.

 

But, to answer your question, depending on the R: device type and its driver, you might not see such a command frame. And yes, in the R-Verter case, it just dumps its data stream on the serial bus, without any SIO commands. And if the baud rate does not match that of your arduino, you might see garbage, but you might just as well see nothing if it turns out to be rare for a perfect start/stop bit combination to show up in your signal.

[dmsc]

Hi!

 

Sorry for the delay in response, and thanks for your replies.

@Fox-1: Yes, I also read about this quite sophisticated way of getting the driver into the RAM of the Atari. And in the meantime, I also found the source code of the 850 driver (not just the 1-2 sector piece of code that initiates the loading process), will have to try it.

But during boot-up, the Atari does look for a D1: device at bootup because...

 

@ivop: that is the byte sequence I see when I boot up the Atari and have my Arduino connected to the SIO port:

0x31 0x53 0x00 0x00 0x84

This is a perfectly define command frame: The 0x31 is for D1:, 0x53 is the ASCII code for 'R' (i.e. read), then two zeros for AUX1 and AUX2 and finally the checksum. I get this sequence a couple of dozen times until the Atari gives up and jumps into Basic.

I would expect something like this when I access other SIO devices as well, like P: or R:, but nothing comes up.

 

What you mention about RVERTER not using the command line at all is interesting - so it just dumps data on the SIO bus without sending the command frame with information on the "recipient"? But what do they (have to) use the motor control line for? This is one of the lines I thought would not be necessary in my self-made SIO cable, so I left it out and just used 5V, GND, Data In, Data Out and Command Line.

 

The fact that even a built-in handler such as P: does not send anything on to the SIO bus (or at least nothing visible to me on the Arduino output) still puzzles me - or makes me wonder what other ways there are for the Atari to determine if a peripheral device is really connected before sending data out on the bus...

Read the Altirra Hardware Manual, chapter 9.2 "Polling".

 

Basically, the OS directly access only disk devices (0x31) as boot devices, and some devices implement the type 1 poll, but it is uncommon. So, for "normal" devices, you need loading your own driver that installs the CIO handler, this loading normally is via de disk drive.

[freetz]

Thanks again for the input.

@ivop: I'll check for other baud rates as well and see what comes up (or hook up the scope to see what goes on "live")

@dmsc: Thanks for the pointer to this chapter, that clarifies things a bit. But as I said, for those SIO devices that already have their driver residing in the ROM (such as P:), some data (or gibberish) should be visible on the bus. But maybe it's for the reason that ivop mentions. Does anyone know the default baud rate for R-VERTER or P: devices?

[dmsc]

Hi!

Thanks again for the input.

@ivop: I'll check for other baud rates as well and see what comes up (or hook up the scope to see what goes on "live")

@dmsc: Thanks for the pointer to this chapter, that clarifies things a bit. But as I said, for those SIO devices that already have their driver residing in the ROM (such as P:), some data (or gibberish) should be visible on the bus. But maybe it's for the reason that ivop mentions. Does anyone know the default baud rate for R-VERTER or P: devices?

Only the "P" driver is in ROM (with "C", "E", "S" and "K"), all of the "R" devices use loadable drivers, same as the "D" devices.

[freetz]

Yes, that's what I meant: As P: is already in ROM and needs no further loadable driver, a command such as

LPRINT "HELLO WORLD"

should show some activity on the SIO bus and therefore on my Arduino device, shouldn't it? But it doesn't, so I was wondering about the baud rate for printers in case that's the reason I don't even see gibberish...

[dmsc]

Hi!

 

Yes, that's what I meant: As P: is already in ROM and needs no further loadable driver, a command such as

LPRINT "HELLO WORLD"

should show some activity on the SIO bus and therefore on my Arduino device, shouldn't it? But it doesn't, so I was wondering about the baud rate for printers in case that's the reason I don't even see gibberish...

Here, LPRINT "HELLO" sends a STATUS command to the bus: " $40 / $53 / $53 / $00 / $E6 ", at 19200 bauds.

[freetz]

Thanks a lot for checking! Then something must be wrong with my setup that I can see disk access but not the rest. Will double check and get back.

 

Thanks again,

 

F.

[freetz]

Ok, I don't know what changed after I returned to the Atari, but now I get to see the transmissions also for P: and R: (both with Bob-Verter as well as the Datatari handler). Ice-T also works like charm at 9600 Baud, both sending and receiving. But... how can I mirror this behaviour in BASIC?

When I run this little program three times:

10 OPEN #1,8,0,"R:"
20 XIO 36,#1,15,0,"R:" : REM Judging from the 850 manual, "15" is for 9600 Baud, 1 start and 1 stop bit, no parity
30 PRINT #1,"ABCDE"

The Arduino receives the following data (in hex, each line is the result of one execution of the program above):

84 84 84 84 14 B0 FE F0 FD FE F3 
88 84 88 84 88 10 D0 FF FE F8 
84 88 84 88 84 10 D0 8F FE

Probably Bob-Verter does not use the same Baud-encoding for the XIO command, because each output is different, so I assume that a different Baud rate than 9600 is used.

 

Does anyone have an idea how to set the Baud rate properly so that it works the same way under BASIC as it does under Ice-T?

 

Thanks a lot again for your patience and support,

 

F.

[dmsc]

Hi!

 

Ok, I don't know what changed after I returned to the Atari, but now I get to see the transmissions also for P: and R: (both with Bob-Verter as well as the Datatari handler). Ice-T also works like charm at 9600 Baud, both sending and receiving. But... how can I mirror this behaviour in BASIC?

When I run this little program three times:

10 OPEN #1,8,0,"R:"
20 XIO 36,#1,15,0,"R:" : REM Judging from the 850 manual, "15" is for 9600 Baud, 1 start and 1 stop bit, no parity
30 PRINT #1,"ABCDE"

The Arduino receives the following data (in hex, each line is the result of one execution of the program above):

84 84 84 84 14 B0 FE F0 FD FE F3 
88 84 88 84 88 10 D0 FF FE F8 
84 88 84 88 84 10 D0 8F FE

Probably Bob-Verter does not use the same Baud-encoding for the XIO command, because each output is different, so I assume that a different Baud rate than 9600 is used.

 

Does anyone have an idea how to set the Baud rate properly so that it works the same way under BASIC as it does under Ice-T?

 

Thanks a lot again for your patience and support,

 

F.

 

Most devices always use 19200 baud for SIO command frames, this is the only way you can share the bus (as each device listen and don't respond to requests for other devices). Also, SIO expect replies to the command frames (an ACK), missing that the driver will retry until timeout.

 

As @ivop said, R-Verter like devices are different, don't use the SIO protocol by keeping the command line always de-asserted, and using MOTOR line to enable the serial transmission. So, other devices ignore the data and R-Verter only enables when MOTOR line is high. This type of device will be the simpler to emulate, you only need to monitor the MOTOR lines from the Arduino, and you can share the bus with a disk drive to load the driver.

[freetz]

Thanks, yes, I understand that for separating the R-Verter data from other SIO data, the MOTOR line will be necessary, but for the moment I'm still trying to figure out how to get "readable" data to and from the device in BASIC. Since it works perfectly with Ice-T, I assume it's just a matter of settings. Does anyone know how to set the transmission speed with R-Verter from BASIC using XIOs?

 

EDIT: I hooked up a scope to the SIO port and found a signal length of approx. 3ms, i.e. 300 Baud. Have to go to bed now, though, but will try if it works first thing in the morning ...

Edited June 20, 2018 by freetz

[_The Doctor__]

Chris, aka Cybernoid, did a complete R: handler FAQ and someone around here probably has it....

check the 1030 T: handler as well and write ups about making your own handler and basic programs is where you start... the XM301 builds on that as well as the other rverters out there including the sx212, you might want to take a peak at 'bit banging' drivers as well (mpp etc).... The 850 and P R are also well documented, as are their counterparts the MIO and black box....

Bob's (puff) 850 polling is the best at launching 850 drivers.... if you are going to give any of it a shot I would look at his work on the 850 and the XM301, as well as SX drivers.

If anyone digs up what I have mentioned, please post it again, it would be good to see these resources again.

You do not need and 850 if you load an RBIN but you may have to emulate a few of it's responses to utilize such things

Edited June 20, 2018 by _The Doctor__

[freetz]

Thanks, these are helpful pointers, I'll have a look at them, but as you mentioned, if anyone has those at hand, here would be a good place to share them ...