110 baud bit-banging

[tin]

Well, naturally, this new contact you have overrides any theories on my behalf, no matter how plausible information derivable from those A2000 photographs make them . But in that case, then, I become terribly confused by how the verbatim 110 baud data could have made its way from the data demod card to the Amiga's serial port. The only possibilities I see are (a) one of those two wires, or (b) some equivalent of time division multiplexing of the two streams over the standard data pins, and with the serial port-to-data demod card baud rate actually being higher than 2400.

I am sure we have that bit sussed to a degree. The demod card sends the 110 data on the RTS pin, in a similar fashion to how it would send the 2400 over the TX pin. Of course, the Amiga has no hardware/system software to handle the reception of data on that pin, so it has to re-check the status of the pin regularly in software and re-assemble the raw electrical signalling into data. Hence why we understand it to be 110-baud - as it could not realistically be checked any quicker than that. I have scripts that will modulate the RTS pin with data, the problem is for me what format the data needs to be in. I can send random stuff and sometimes the Amiga sees it as valid CTRL commands. If I could discover what format the 110-data should be in (bitwise, stop bits, etc etc), a program that sends 2400 and 110 data at the same time would be trivial to write.

Of course there's no reason why the other pins can't be used for more signalling from the Amiga back to the demod. there is an RTS pin in the other direction at the very least. In fact I am sure these are used to some degree. These might be over those bare wires you mention, or there may be more wires in the main serial cable that we can't see from the photos.

[AriX]

I am sure we have that bit sussed to a degree. The demod card sends the 110 data on the RTS pin, in a similar fashion to how it would send the 2400 over the TX pin.

Exactly.

[nwgatwcfan]

I am sure we have that bit sussed to a degree. The demod card sends the 110 data on the RTS pin, in a similar fashion to how it would send the 2400 over the TX pin.

Exactly.

I've been "banging" my head trying to figure something out. I noticed that you mentioned that the 110-baud commands that you have seen from UV's test suite are of the same syntax as the regular data commands. I have been trying to do some research on the RTS pin and from what I gather online that the RTS pin was a output pin only. Most of the terminal software you find online only treats the RTS pin as a output-only pin. I have been trying to find a free or close to free software that would allow us to change the RTS from an output to an input. So far, it has been an impossible task to find. I'm not too savvy on the C++ / C# to create a program that does just this. Anyway, I was thinking of a possible theory that the RTS pin acts like a "Shift" key on a keyboard and when the RTS is activated, it allows the other commands to be entered.

Arix, I was wondering also if you had a chance to message back with the ex-UV employee to see if we can be allowed to see a few of the 110 baud commands that you may have in the test software. I was able to find a software that kept the RTS line on all the time and I was hoping to try a 110 command and see if it would increment the CTRL data in the Diagnostic screen with a valid command.

Thanks very much,
Steven (nwgatwcfan)

[AriX]

I've been "banging" my head trying to figure something out. I noticed that you mentioned that the 110-baud commands that you have seen from UV's test suite are of the same syntax as the regular data commands.

Unfortunately that's not the case... I do not have any 110-baud commands. I just know enough about the 110-baud protocol that I think I could get it to work.

I have been trying to do some research on the RTS pin and from what I gather online that the RTS pin was a output pin only. Most of the terminal software you find online only treats the RTS pin as a output-only pin. I have been trying to find a free or close to free software that would allow us to change the RTS from an output to an input. So far, it has been an impossible task to find. I'm not too savvy on the C++ / C# to create a program that does just this.

Unfortunately, I don't understand enough about RS-232 to fully answer your question. Maybe tin can do it. However, I think you're mistaken. RTS is an output pin only, as you say. However, RTS is an output pin that exists on both sides - i.e. the Amiga has an RTS pin that goes to the demod, and the demod has an RTS pin that can be received by the Amiga. I don't know how it is received on the other side exactly, but I'm pretty sure that it can be done.

Anyway, I was thinking of a possible theory that the RTS pin acts like a "Shift" key on a keyboard and when the RTS is activated, it allows the other commands to be entered.

Nope - that would cause huge problems... The demod card would have to pause transmission of the 2400-baud stream while 110-baud data was coming in, which would be bad. Plus, this isn't bit-banging.

Arix, I was wondering also if you had a chance to message back with the ex-UV employee to see if we can be allowed to see a few of the 110 baud commands that you may have in the test software. I was able to find a software that kept the RTS line on all the time and I was hoping to try a 110 command and see if it would increment the CTRL data in the Diagnostic screen with a valid command.

Unfortunately, as I said before, I don't have any 110-baud commands. Also, I don't really have any "test software", just a directory with some plain binary files in them with commands. If you would like to see these files, feel free to PM me and I'll send them to you - however, there isn't a ton of information in there that isn't already on these forums or on the wiki (http://prevueguide.com/index.php/UVSG_Satellite_Data)

[tin]

Hi Steven

As you say the RTS pin is indeed only output but it is connected to the CTS pin on the other side which is like it's input brother. Like TX is only output but is connected to RX on the other side.

So in our case the RTS pin of the demod board is connected to the CTS pin on the Amiga, and it is this pin that the software repeatedly checks to see what status it is in. i guess probably the RTS pin of the Amiga is connected to the CTS pin of the demod card for reverse signalling (amiga->demod) maybe.

I have posted some scripts earlier in this thread (written in perl) that manipulate the RTS pin (on a Win32 PC only probably) according to certain parameters which are guessed from the normal "standard" serial settings that you often see (like 1 start bit, 1 stop bit, even/odd/none parity etc) but all combinations don't seem to come up with a consistent response on the Amiga side (apart from acknowledgement that data is coming across the RTS/CTS pins and some of it actually manages to form a valid command).

Again because we're manually modulating data onto a pin that is just usually on or off, it's a guess as to exactly how the programmers/hardware engineers decided to represent the data across those pins at a bit/signalling level. So far it appears I haven't been able to guess.

In addition for a really simple test (if you have the Amiga to do it with) try the Hercules setup utility from here http://www.hw-group.com/products/hercules/index_en.html you can toggle the RTS pin on the PC side, and see the Amiga registers this as CTRL data coming in.

Unfortunately, this kind of testing does NOT work on UAE..... it seems it probably didn't bother to emulate the RTS/CTS pins (why would you ever need to!? it's not like some crazy fools would want to start emulating a TV guide from the 90s and push real data over to it?)

So, so far, we have definitely worked out that there is definitely 2400 (maybe 9600) baud data going across the TX/RX pins in a usual serial data kind of style, and a completely separate probably 110 baud data manually modulated in some not-quite-discovered style going on at the same time, with a separate data stream on the RTS/CTS pins.

Once I discover the actual bit/electrical format to send a single byte over to the Amiga successfully, I can then work on the actual commands, which we understand to be somewhat similar to the 2400-baud commands, but obviously will contain some differences because they operate different bits of the system. However I anticipate making them up will be a bit easier than trying to work out what the original designers decided to do electronically!