Amiga disassembly

[tin]

Hmm, what if a 1 is signalled by the serial port going high then low, and a zero is signalled by the serial port staying low? would that make it make any more sense?

so maybe

start bits
1 11110000
1 11110000
----
data byte
0 00000000
0 00000000
1 11110000
1 11110000
1 11110000
0 00000000
1 11110000
1 11110000
----
stop bits
0 00000000
0 00000000
..can continue forever, amiga is waiting for more 1's

I wondered if this might be the case, because of the odd results with sending random stuff to the serial port.

I will unfortunately have to check out the code later, as I am snowed with work (which is great!! )

[AriX]

Hmm, what if a 1 is signalled by the serial port going high then low, and a zero is signalled by the serial port staying low? would that make it make any more sense?

Not really - keep in mind that the H counter counts bytes, not bits (even though it may not look like it)

I completely reverse engineered the whole routine, and it's more like:

start bits
1 111 (last two bits don't matter because it only checks at the beginning)
1 1111111111 (last 9 bits don't technically matter because it only checks at the beginning and then waits)
----
data byte
0 0000000000 (last 9 bits don't technically matter because it only checks at the beginning and then waits)
0 0000000000 (ast 9 bits don't technically matter because it only checks at the beginning and then waits)
1 1111111111 (ditto)
1 1111111111 (ditto)
1 1111111111 (etc.)
0 0000000000
1 1111111111
1 1111111111
----
stop bits
0 0000000000
0 0000000000
...can continue forever, Amiga is waiting for more 1s

[AriX]

tin, I believe you may have speculated about this previously, but on the Amiga, most initial checksum values are calculated by xoring the mode byte with $FF (i.e. mode F, or $46 xor $FF = $B9)

[AriX]

Well, I feel a little bit dumb. tin, remember when you commented that it seemed that the T counter very rarely moved up, and the software seemed to be waiting for something before it would parse the CTRL stream?

Well, it turns out you were right. The CTRL data is not parsed AT ALL while the software is in menu mode. If it is not showing the grid, when the routine to parse the data is called, it just jumps over all of the parsing code and returns.

Indeed, once I sent data to it while in the grid mode, the T counter happily incremented along with the received bytes.

[tin]

Hmmm. I think I knew this but didn't say. It's hard to remember now, but something in the back of my mind says I had to keep flipping between modes when I was testing with the real Amiga (which of course is the only way I've been able to test so far, as UAE doesn't have the serial port lines implemented). Should have said something It makes sense, cos there's no point processing things that are done live (covering up/uncovering parts of the screen) when in diag mode. Unlike receiving and processing listings.

[AriX]

Hmmm. I think I knew this but didn't say. It's hard to remember now, but something in the back of my mind says I had to keep flipping between modes when I was testing with the real Amiga (which of course is the only way I've been able to test so far, as UAE doesn't have the serial port lines implemented). Should have said something It makes sense, cos there's no point processing things that are done live (covering up/uncovering parts of the screen) when in diag mode. Unlike receiving and processing listings.

The E-UAE I use does have support for the special serial pins in the file "serial.c". Of course, I have to roll my own way of getting the information in there (and compile the application myself), but it is supported.

But yeah, it does make sense now that I think about it... although it does make debugging pretty annoying

[AriX]

Okay, so more progress on the CTRL front:

Everything is sent bizarrely - basically, when the machine receives a CTRL byte, it interprets it as the reverse NOT of that byte.

So, for example:

01000100 - $44
10111011 - NOT of $44
11011101 - reverse of NOT of $44 (the same as the last one, but backwards)

in the end, the byte received is $DD.

$00 is $FF, $FF is $00, but $55 is $55 and $AA is $AA

[nwgatwcfan]

Arix,

This is an interesting find. Just what you found at least gives a plausible reason why they used 55 AA as the start code for the data part of the stream, since the start byte wouldn't be affected ( x and NOTx are equivalent in algebraic terms).

But, I wonder how the computer could reverse the binary number on the fly. Is there a simple function (like OR, XOR, etc.) that could do this, or is it quite complicated to reverse the binary number?

I just wonder why they had to go to such extremes as this to encode the data? It's not like the average person had access to beam changes to their data streams.

I guess these answers will be solved later on....

Thanks for the work you are doing Arix,

Steven.

[AriX]

This is an interesting find. Just what you found at least gives a plausible reason why they used 55 AA as the start code for the data part of the stream, since the start byte wouldn't be affected ( x and NOTx are equivalent in algebraic terms).

Well, yeah, although the work I have been doing recently is starting to show that 55 AA might not be used AT ALL in the CTRL stream, contrary to what I thought before. Not 100% sure about that yet though. This bit-inverting stuff only applies to CTRL and not DATA.

But, I wonder how the computer could reverse the binary number on the fly. Is there a simple function (like OR, XOR, etc.) that could do this, or is it quite complicated to reverse the binary number?

I just wonder why they had to go to such extremes as this to encode the data? It's not like the average person had access to beam changes to their data streams.

I don't think they were doing this to hide it from people - just because this is how they chose to implement it or something. It is a bit silly.

In any case, there are assembly instructions (and C operators) that can easily handle OR or XOR, but this is not how they did it - if you look in the readCTRL.txt and readCTRL.asm.txt files that I posted earlier, you might see that a "bit buffer" is used. Basically, instead of reading in bits and then populating a byte bit by bit, they read in bits and add them to a buffer/array that is 8 bytes long. It collects each bit as a byte, where $FF is a 1 and $00 is a 0. So a typical byte might look like $FF $00 $00 $00 $FF $00 $00 $FF (10001001). Once all 8 bits have been collected (plus the start and stop bits), the bit buffer is emptied into the regular buffer. BUT, instead of just converting the 8 bits into a byte normally, they read the byte backwards (because they use a decrementing loop) and they read the NOT of the byte (because they interpret $FF as a 0 and $00 as a 1, even though that is the opposite of how they were read in).

If this doesn't make any sense, let me know, and I can try to make it clearer.

Thanks for the work you are doing Arix

You're very welcome! I really hope to figure this CTRL stuff out.

If anyone is curious, I also wrote a runnable implementation of the routines that read in the CTRL data. It is written in C, and should be compile-able on any Unix-like platform (including Mingw32 and cygwin if you're on Windows). Use "gcc readCTRL.c -o readCTRL" to compile it. The "enter a 0 or 1" prompts simulate reading from the CTS port. I am currently in the process of figuring out how frequently the routine is called in the actual program - once I have figured this out, we can work on creating a way to reliably get the data into the machine.

http://cl.ly/163L460L2W2514301p2I

[AriX]

Lots of progress. Contrary to everything I've said in the past, the data format is completely different from that of the 2400 baud DATA feed (although there are some similar aspects). A lot of it still lines up with what I was told by one of the original software engineers on the project, though.

I was finally able to disassemble ESQ in such a way that I could reassemble it - as in, I can now modify the program to do whatever I want (as long as I can write it in assembly). I took advantage of this to write a little debugging interface for the CTRL system.



As far as what the numbers mean:
H is the same as usual (the current location in the ring buffer, AKA how many bytes have been received up to 500).
Cnt is the amount of bytes that have been received for the current command (the amount after the mode byte).
CRC is the current expected checksum.
State is the current state, where 0 means "waiting for command" (looking for a mode byte), 1 means "in a command" (waiting for data following the mode byte), 2 means "waiting for checksum", and 3 means "got end of command without valid mode byte" (aka everything that it just received is going to be ignored).
Byte shows the byte that was most recently received (at the end of the CTRL buffer).

The basic data format is as follows:

[MODE BYTE] [DATA] $0D [CHECKSUM BYTE]

Notice that there is NO 55 AA in the CTRL feed. The mode byte is not sent as an ASCII character like in the DATA feed, but instead as a control character - that is, anything from $01 to $15. $05, or Control-E (for "event"), is the equivalent of swest77's "NOW!!" command, which fires off the next switch (to show an overlay or an ad or something). Also, I believe Control-S means source, which defines, for both the left and right sides of the screen, what program the clip corresponds to (i.e. a channel ID and timeslot). Control-T allows you to specify a custom title for the overlay, and Control-C does something important as well.

$0D seems to be used as the "end-of-command" byte instead of $00. The checksum appears to be generated by XORing all of data, including the mode byte - so there is no "initial checksum byte" to deal with.

I haven't yet gotten anything exciting to happen, like drawing an overlay, but I feel kinda close.