110 baud bit-banging

[tin]

Well I have today (after FINALLY getting PG to run on one of my Amigas) figured out one thing - bitbanging the RTS line through emulation does NOT work.

As soon as I connected a serial port to the Amiga and started pulsing the RTS line, the CTRL: H counter began counting upwards The interesting thing is that the DATA@ line increments with how many bytes are sent over the serial port. The CTRL increments once every time the RTS line is brought from high to low.

Now to figure out how to send the data!

[AriX]

Well I have today (after FINALLY getting PG to run on one of my Amigas) figured out one thing - bitbanging the RTS line through emulation does NOT work.

As soon as I connected a serial port to the Amiga and started pulsing the RTS line, the CTRL: H counter began counting upwards The interesting thing is that the DATA@ line increments with how many bytes are sent over the serial port. The CTRL increments once every time the RTS line is brought from high to low.

Now to figure out how to send the data!

That's great! Hopefully once we figure out how to do it on a real machine we can figure it out in emulation, too. I hope to finally have my AP2000 around the beginning of next month.

[tin]

Here's one of the scripts I've been using, in case anyone else wants to have a meddle around

[AriX]

Here's one of the scripts I've been using, in case anyone else wants to have a meddle around

Awesome, I'll take a look. Just a note, if you hadn't thought through this yet,- the CTRL command counter SHOULD increment (even if it's just the CErr) as soon as it receives a 55AA(command byte)(any byte)00(any byte), so you'll know when you're actually sending it real data if it counts a command after it receives something like 55AA54004B.

Good luck!

[tin]

OK while I'm in full flow talking to myself, I'll continue....

As can be seen from the screenshot above, there are two sets of entries, for DATA and for CTRL.

--

The top ones are the commands received successful from serial - i.e. there have been no low level errors in transmission of the data and it's been presented to the code to process.

So far, DATA is the only line we can get to tick over - each full command (starting with 55 AA and a command letter, and ending somehow or other) makes Cmds: tick up one. CErrs: ticks up one if there's a problem, like checksum not right, or some problem in the data (which we see if we try to send a correctly formatted atari style K command, even with the right checksum). I am not yet sure what LErrs: means.

Note that I've totally not been able to get the CTRL one to do anything at all.

--

The bottom ones are to do with the low level serial data handling and (at least the DATA) one is somewhat related to how I know the Atari handles it's serial buffer (from reverse engineering the code).

All data that is received via serial is put into a serial read buffer. This has an internal pointer to where it will next put incoming serial data. This pointer I believe is represented by H:00000 Obviously the program from time to time reads the buffer and acts on the commands, this is a different pointer, as it might not always be exactly where the next arriving bit of data might go. This is T:00000. The C:00000 entry shows the difference between the two - i.e. the amount of data that is waiting in buffer to be processed, and MAX:00000 indicates how big C:00000 ever got. Note that T:00000 will always race up to the value of H:00000 pretty quickly. It doesn't wait for anything in particular, not even a full command to be sent.

OK so far, for serial data, normal style on the TX and RX pins is fine. You send a char with serial mode 2400 baud 8N1 from your PC/Mac/Whatever and the sending system and Amiga handles how this actually works electrically on the pins of the serial port.

So now we have the problem of the CTRL: line. As far as we know, this is a 110-baud manually signalled/read data stream sent over the RTS pin. i.e. you should not ever be able to send data over this, and both the PC/Mac and Amiga don't have the usual buffers and stuff to send the data for you. The pin must be manually manipulated all the time to successfully send the data over to the Amiga.

Testing with Hercules SETUP utility (as I have done throughout), clicking the RTS pin on then off (note the order) will make the CTRL: H:00000 and C:00000 counters increment by one. Clicking off then on does nothing. What is happening here I don't know. Maybe it's thinking it's received a byte of data which all 1s and ended with a 0 or two, or it's read the change from high to low as a single bit, and the counter represents a bit. That would mean that the only way to send data is by turning the line from high to low at the right time, rather than high representing a 1, and low representing a 0 for example.

I have also tried the aforeposted serialport testing script (and some variants of, that, for example, cycle through all the possible combinations of serial port bit formats I can think of) and in each case the H:00000 doesn't count up as fast as I would expect. The strange bit is that the T:00000 doesn't come up to meet the H:00000 very often at all, it's as if the system is waiting for something to kick that off.

[tin]

Progress:-

If I send 0111110110001110011011001100111110011011000110110000111100101001010101011010011110000111001000111011111100100100010100111001000001111101110000100101010111010111 via this bitbanging method, it registers a command. What exactly is still going on is unclear, but I suspect at the moment that this is NOT 110 baud.

[swest77]

So now we have the problem of the CTRL: line. As far as we know, this is a 110-baud manually signalled/read data stream sent over the RTS pin. i.e. you should not ever be able to send data over this, and both the PC/Mac and Amiga don't have the usual buffers and stuff to send the data for you. The pin must be manually manipulated all the time to successfully send the data over to the Amiga.

Testing with Hercules SETUP utility (as I have done throughout), clicking the RTS pin on then off (note the order) will make the CTRL: H:00000 and C:00000 counters increment by one. Clicking off then on does nothing. What is happening here I don't know. Maybe it's thinking it's received a byte of data which all 1s and ended with a 0 or two, or it's read the change from high to low as a single bit, and the counter represents a bit. That would mean that the only way to send data is by turning the line from high to low at the right time, rather than high representing a 1, and low representing a 0 for example.

[...]

Progress:-

If I send 0111110110001110011011001100111110011011000110110000111100101001010101011010011110000111001000111011111100100100010100111001000001111101110000100101010111010111 via this bitbanging method, it registers a command. What exactly is still going on is unclear, but I suspect at the moment that this is NOT 110 baud.

Maybe you're thinking too literally here.

Yes, the 2400 baud data stream, after demodulation by the data demod card, is delivered "as is" to the Amiga serial port.

But who says the data demod card delivered the demodulated 110 baud data stream "as is" to the Amiga serial port at all? As you say yourself, RTS is a high/low affair. Maybe the demod card not only demodulated the 110 baud data, but also was the sole interpreter of it -- sending nothing more than a simple pulse to the RTS pin based upon what it interpreted from said data.

Remember the two unexplained wires I was theorizing about in my post in this thread? Some of the information in that post has since been revealed to be incorrect (i.e. that listings/control data was VBI-based). But what I conjectured about, at another level, as far as the possible purposes of the two unexplained serial port wires, may still be plausible -- even if my theory of how they worked wasn't correct at the level of minutia.

Specifically, in that post, I was saying that most of the serial port's pins would've been dedicated to listing data, and that those extra wires may therefore have been connected to some of the serial port's non-data, "stateful" pins (high/low type pins, like DTR or RTS). And that maybe some kind of pulse-based control signalling would have been done on those pins (via those two mystery wires). "One pulse for left, two pulses for right." Or maybe "one 100ms pulse for left, one 50ms pulse for right," etc. That kind of stuff.

Well, you say "clicking the RTS pin on then off (note the order) will make the CTRL: H:00000 and C:00000 counters increment by one." If that's so, maybe just by discovering that alone, you already cracked the mystery in full. That it's not a matter of 110 baud data bits being expected by the serial port, but that it's a matter of the data demod card receiving a "NOW!" command in the form of 110 baud data, and simply translating that "NOW!" into a single high pulse to the Amiga serial port's RTS pin.

Anyway, one of those two mystery wires could have been for carrying "NOW!" pulses from the data demod card to the software ... while the other wire could have been from the software to the audio demod/switcher card. Via the former, the software would be able to receive the necessary instantaneous "switch now" stimuli required to precisely time its switching in the upper half of the screen ... while via the latter, the software might have passed that stimuli on to the audio switcher card (telling it to switch to left vs. right vs. instrumental music, perhaps with one quick pulse meaning "go left", two quick pulses meaning "go right", and three quick pulses meaning "go to the instrumental audio" subcarrier -- or something like that).

At least that would jive with something else that I theorized about in that post (slightly edited here -- see red -- to correct for past misconceptions):

Moreover, here are two things I've always noticed about the A2000 Prevue Guides. One, when they were powered up from an off state, you would hear nothing (not even the background/theme music) until the Prevue Guide software was started. And two, if the A2000 was rebooted while powered on, whatever audio the card was already switched to would stay switched to until the Prevue Guide software was running again. I.e., if the card was currently switched to LEFT audio when the A2000 was suddenly rebooted, the card would leave the left audio on continuously -- right through several promos -- until the PG software got going again. These two observations would seem to affirm my speculation that the audio card was "controlled" only through one-way contact closure signalling. One ground pulse = left, two ground pulses = right, three ground pulses = background ... such signals would not have been able to happen unless the Prevue Guide software was running and sending them. Therefore, if the last instruction the audio demod card received was "switch to left audio", it would have stayed that way, mindlessly continuing to feed the left audio to its "BALANCED AUDIO OUT" punchblock unless and until a new switching signal arrived once the Prevue Guide software got started back up again. (And of course, when the card was off and suddenly received power, the most logical thing would have been for it to not switch ANY audio to its "BACKGROUND AUDIO OUT" punchblock -- not until a signal arrived from the PG software telling it what audio subcarrier to switch to.)

So, yeah. If the software crashes, or if the Amiga is suddenly rebooted, and audio card continues pumping out whichever sound subcarrier it was last told to switch to -- because the software itself is no longer "there" to control-pulse the audio switcher card. But when the software is running, maybe something like this happens:

01:29:15 AM - 2400 baud listings data stream - "Upon next 'NOW!' signal, left will be WGN (banner text is: [...]), right will be HBO (banner text is: [...])"
01:29:30 AM - 110 baud control data stream - "NOW!"
01:29:30 AM - Data demod card - pulses PG software via RTS
01:29:30 AM - PG software - sees pulse; checks if cable system carries HBO = nope; checks if cable system carries WGN = yep; switches genlock to left; sends one pulse to audio switcher card ('left audio')
01:29:30 AM - Audio demod/switcher card - switches to left
(entire chain reaction happens within 50ms or so, viewer is now seeing and hearing WGN promo)
~
01:29:51 AM - 2400 baud listings data stream - "Upon next 'NOW!' signal, go full screen, audio will be on right"
01:30:00 AM - 110 baud control data stream - "NOW!"
01:30:00 AM - Data demod card - pulses PG software via RTS
01:30:00 AM - PG software - sees pulse; lets entire top half of C-band video show through; sends two pulses to audio switcher card ('right audio')
01:30:00 AM - Audio demod/switcher card - switches to right
(entire chain reaction happens within 50ms or so, viewer is now seeing 1-900-ASTROLOGY commercial)
~
01:30:22 AM - 2400 baud listings data stream - "Upon next 'NOW!' signal, left will be STARZ (banner text is: [...]), right will be ENCORE (banner text is: [...])"
01:30:30 AM - 110 baud control data stream - "NOW!"
01:30:30 AM - Data demod card - pulses PG software via RTS
01:30:30 AM - PG software - sees pulse; checks if cable system carries STARZ = nope; checks if cable system carries ENCORE = nope; plasters local text/graphical advertisement into top half of screen; sends three pulses to audio switcher card ('instrumental/theme audio')
01:30:30 AM - Audio demod/switcher card - switches to instrumental music audio subcarrier
(entire chain reaction happens within 50ms or so, viewer is now hearing Amiga mod music and seeing tasteless ad for local mortuary)

Etc.

Grand guesswork all, but I reckon there's an air of plausibility to it? Your discovery that a high pulse is a "command", plus those two wires, plus the two otherwise unexplained GND punchblock connectors on the data and audio cards themselves (which appear to be the only places the two wires could've terminated to) ... all three make me think "plausible".

[AriX]

But who says the data demod card delivered the demodulated 110 baud data stream "as is" to the Amiga serial port at all? As you say yourself, RTS is a high/low affair. Maybe the demod card not only demodulated the 110 baud data, but also was the sole interpreter of it -- sending nothing more than a simple pulse to the RTS pin based upon what it interpreted from said data.

Hey Steve,

It's a good theory, but having talked to the guy who designed parts of it, I can tell you that this is not the case. In fact, he told me that the data stream for the 110-baud "control" feed has the same syntax as the stream for the main data feed. Your 2400-baud theory is a bit flawed in that the 2400-baud feed would need to be synced up with the programming in order for it to work; the beauty of the control & data system is that the 2400-baud feed operates completely separately from everything else, and if, for example, the software is being updated over satellite, the top half of the screen won't be tied up while receiving the huge file. I actually know about some of the syntax of the control feed commands, which is why if we were able to reliably get data sent to it, I think I'd have a good chance of being able to make it work.

[tin]

BUT I love the theory and wonder if there's still something in it for switching the audio. The Amiga must decide which audio to pick, so it has to somehow send it back to the audio demod, and I still haven't seen how that's done yet....

[swest77]

But who says the data demod card delivered the demodulated 110 baud data stream "as is" to the Amiga serial port at all? As you say yourself, RTS is a high/low affair. Maybe the demod card not only demodulated the 110 baud data, but also was the sole interpreter of it -- sending nothing more than a simple pulse to the RTS pin based upon what it interpreted from said data.

Hey Steve,

It's a good theory, but having talked to the guy who designed parts of it, I can tell you that this is not the case. In fact, he told me that the data stream for the 110-baud "control" feed has the same syntax as the stream for the main data feed. Your 2400-baud theory is a bit flawed in that the 2400-baud feed would need to be synced up with the programming in order for it to work; the beauty of the control & data system is that the 2400-baud feed operates completely separately from everything else, and if, for example, the software is being updated over satellite, the top half of the screen won't be tied up while receiving the huge file. I actually know about some of the syntax of the control feed commands, which is why if we were able to reliably get data sent to it, I think I'd have a good chance of being able to make it work.

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.

BUT I love the theory and wonder if there's still something in it for switching the audio. The Amiga must decide which audio to pick, so it has to somehow send it back to the audio demod, and I still haven't seen how that's done yet....

The half of my theory that pertains to communication between the software and the audio switcher card may still be correct. Pulse based signaling was a common thing back in those days. And with there having only been three "commands" for the software to ever send the audio switcher card (left, right, instrumental), some kind of pulse-based high/low signaling could very plausibly have been in use there.

Ah well. Time will reveal all.