test of command "C"

[tin]

I've done a bit more reverse engineering of Atari command "C" in line with what we now know about the data format for the command.

==

Just to recap as I don't think it's documented yet, the format for "C" is.

55 AA (normal training bytes)
43 (ASCII "C")
[jdate] (the julian date for the date the channel list applies - routine will check it corresponds with either CURDAY or NXTDAY and discard if it does not correspond)

....start of channel definition....
12 (start of entry marker?)
[flags] channel flags (as listed here viewtopic.php?f=5&t=67#p459)
[source] up to 6 ascii chars - unique identifier for the channel, i.e. where there are different versions for affiliates etc, these uniquely identify them, e.g. CBS006
11 (start of channel number marker?)
[channel no] unsure how many digits, but possibly up to 4 ascii chars - channel number on the local cable system
01 (start of callltrs marker?)
[callltrs] up to 6 ascii chars - channel name on the local cable system that will be displayed in the guide, e.g. CBS

....then to begin another record, start again from "start of channel definition" above, or to end.....

00 (end of data)
[cksum] calculated checksum - XOR of $BC followed by all chars from [jdate] onwards


==

In the Atari disassembly, I've got to the part where it basically reads the string as sent into memory at $3000 onwards, then compares the length of the data and the checksum with stored versions of each that were stored after the last reception of the C command. It stores/compares length and checksum separately for CURDAY and NXTDAY. i.e. if it receives the same channel list for either day as it already has, it discards the received data. obviously then it must go onto storing the list in the correct place, which is what I will check out next. Hopefully this will also show if there is any significance to the $12, $11 and $01 markers, and if there are any other values. This may lead me onto the data structures for command P.

However I've noted in the code, that there is a special handling of a channel definition that begins with $14 rather than $12 as listed above. If it does start with $14, it expects exactly 6 bytes of data and handles it differently. AriX or others with working Atari setups, I wonder if you could maybe do a test with $14 in place, or even in the middle of a longer command C somewhere, just to establish what it does.

I'll update this thread with findings.

AriX please edit anything you see wrong here as I am sure you know a couple of bits better than me, anyone else please comment. Once we're sure this is right I'll add to Wiki. I think maybe source and callltrs are the wrong way around, and after going back through our known curday.dat I can see they are definitely 6 chars long - "METMRK" for example.

[AriX]

This is basically exactly what I have although, it seems that there is another attribute - an optional "binary mask" that we can see in the curday.dat file. In order to use this, at the very end of the channel block (after the call letters), you put $14 and then the six-byte mask. I don't know exactly what this is for, but the guy who wrote the EPG Jr. software told me it was a pain to deal with for some reason. When I was messing around with curday.dat, I noted that setting the mask to $000000000000 seemed to cause the channel to not appear, while $FFFFFFFFFFFF, which is what a lot of the masks are set to in curday.dat, allows the channels to show. I don't know what other attributes this can carry.

I will give $14 a try tonight... What does it expect exactly six bytes of data for?

As far as the six-character channels - yes, they definitely do exist on the Amiga, but I'm thinking that they didn't exist on the Atari. I'm pretty sure that while initially they maintained one data feed for both Amigas and Ataris, they later began two separate ones (one on WGN's transponder and one Prevue's C-band transponder), so that they could (1) do 9600 baud on the Amiga and 2400 baud on the Atari (2) do 6-character channels on the Amiga (3) do closed captioning, rating, and stereo symbols on the Amiga, since when you send these to an Atari, it just prints weird shapes. Perhaps they even attached the EPG Sr. to the Prevue C-band version, if it was capable of six-byte channel names and 9600 baud.

EDIT: Oh, wait, I feel like an idiot right now. I just described something involving a $14 and six bytes of data, and then asked what it expected six bytes of data for :p Maybe there's a way to specify the bit mask before the channel instead of after it? Or maybe that's the correct way and I am just doing it wrong. I haven't played around with it much.

EDIT2: Just realized that point 2 above is a bit invalid, since only the display names are required to be 5 bytes or less, and these are communicated in the C blocks. i.e. the controller system could easily send 5-byte names to Atari select codes and 6-byte names to Amiga select codes and there shouldn't be any issues anywhere. One other thing I noticed, though, is that my cable set-top box, which runs i-Guide, has only 5-byte channel names. For those who don't know, i-Guide (which is still TV Guide-branded) is the successor to TV Guide Interactive, which is of course the renamed version of Prevue Interactive. Prevue Interactive at least initially shared programmers and concepts with the EPG products; for example from the diagnostic screens, I can tell that it uses the same "48 timeslot" system as the Prevue Channel.

(Also, Prevue Interactive was initially called TV Guide On Screen.)

[tin]

LOL good post good information in there.

Yeah i have obviously found the handler for $14+(6 bytes) but no idea yet what it does with those 6 bytes once they are in. Will check it out.

Regard 6 char callltrs (the display name) on the Atari, I can't be sure, I will need to go through the handler routines AFTER all the command "C" data has been accepted. Which might be a while. Reason I decided 6 must be OK was "METMRK" in our PG disk, BUT of course, it could be as you suggest, different set of C commands for Atari's and Amigas - of course each different system must have got it's own "C" command - because the channel lineups were different - I guess even between headends owned by the same cableco.

[tin]

Hmmm. AriX, I wonder what you think about this....

I have got parts of a sender suite up and running. at the moment it consists of a sender which repeatedly looks for ASCII files in a directory then sends them verbatim, and 3 generator routines that generate and dump ASCII files in that directory.

So I have generators for P, C and K (K doesn't work obviously) at the moment. The generators grab information out of the same scripts that I wrote for PGweb and create the ASCII files from that information - so they are using live data.

What I find is that if I send C with the select code of our emulated Amiga prevue guide, then P for all the available channels with the * select codes, then the emulated prevue guide fills up with data (with the same time problems, I think doing command F next is a good idea!).

However on the next send of C - all the data clears out, the scroll resets (as in the scroll with the TV guide logo just restarts somewhere in the middle of whatever) and the grid shows no channel lines at all - and no "please stand by" either! I wondered if you found the same with your sender?

What I do know is in the atari code, on receiving command C, it checks to see if the channel lineup is same as the one it already received and discards it if it is the same - obviously the code is expecting the channel lineup to be sent over and over. Any ideas what's happening here in Amiga-land? Seems a bit odd. I would expect the channel lineup has to be broadcast over and over during the day, and having the programmes disappear when that happens is not satisfactory surely?

[nwgatwcfan]

Hmmm. AriX, I wonder what you think about this....

I have got parts of a sender suite up and running. at the moment it consists of a sender which repeatedly looks for ASCII files in a directory then sends them verbatim, and 3 generator routines that generate and dump ASCII files in that directory.

So I have generators for P, C and K (K doesn't work obviously) at the moment. The generators grab information out of the same scripts that I wrote for PGweb and create the ASCII files from that information - so they are using live data.

What I find is that if I send C with the select code of our emulated Amiga prevue guide, then P for all the available channels with the * select codes, then the emulated prevue guide fills up with data (with the same time problems, I think doing command F next is a good idea!).

However on the next send of C - all the data clears out, the scroll resets (as in the scroll with the TV guide logo just restarts somewhere in the middle of whatever) and the grid shows no channel lines at all - and no "please stand by" either! I wondered if you found the same with your sender?

What I do know is in the atari code, on receiving command C, it checks to see if the channel lineup is same as the one it already received and discards it if it is the same - obviously the code is expecting the channel lineup to be sent over and over. Any ideas what's happening here in Amiga-land? Seems a bit odd. I would expect the channel lineup has to be broadcast over and over during the day, and having the programmes disappear when that happens is not satisfactory surely?

I might have a solution on this one. When I was going back through the data, I noticed there is a phrase "DREV05" listed. I looked back at the pieces of the ESQ file and I noticed it had DREV 1, DREV2, DREV3, DREV4, and DREV5 listed. I am wondering if that is what tells the system what revision of the listings it is working on. DREV1 would be the inital listings, then if an update is needed, then DREV2 would be next, etc.

Secondly, regarding the number of characters for channel number, the answer I get is 5 characters. For the Satellite's Superstar Prevue Guide, they had to list the two character satellite id, a dash, and a 2 digit transponder channel number. It may be different on Atari, but it's worth a try.

Lastly, about the $14, check and see if that same checksum appears on the channel that has El Camino College? If it does, it may be a listing that never changes and has the double arrows on both ends.

Hope this helps. Thanks,
Steven.

[AriX]

I might have a solution on this one. When I was going back through the data, I noticed there is a phrase "DREV05" listed. I looked back at the pieces of the ESQ file and I noticed it had DREV 1, DREV2, DREV3, DREV4, and DREV5 listed. I am wondering if that is what tells the system what revision of the listings it is working on. DREV1 would be the inital listings, then if an update is needed, then DREV2 would be next, etc.

Secondly, regarding the number of characters for channel number, the answer I get is 5 characters. For the Satellite's Superstar Prevue Guide, they had to list the two character satellite id, a dash, and a 2 digit transponder channel number. It may be different on Atari, but it's worth a try.

Lastly, about the $14, check and see if that same checksum appears on the channel that has El Camino College? If it does, it may be a listing that never changes and has the double arrows on both ends.

Hope this helps. Thanks,
Steven.

Wow, that's a great discovery. I'm going to play around with that a bunch, because it'd be GREAT if we could get mode K and some other stuff working. I wonder which revision Sneak Prevue used.

As far as the number of characters, I believe the deal is that the internal identifier can be 6 characters across all platforms, but the Atari (and maybe earlier DREVs?) is limited to 5 characters for the display name while the Atari can use up to 6 characters. I do wonder if either platform would allow the use of lowercase/special characters in the channel name, but I don't know.

I believe the thing that indicates whether the never changes is the DITTO flag in the channel parameter flag, but I haven't tested out what that means. I still don't know what the 6-byte channel mask was used for.

Hmmm. AriX, I wonder what you think about this....

I have got parts of a sender suite up and running. at the moment it consists of a sender which repeatedly looks for ASCII files in a directory then sends them verbatim, and 3 generator routines that generate and dump ASCII files in that directory.

So I have generators for P, C and K (K doesn't work obviously) at the moment. The generators grab information out of the same scripts that I wrote for PGweb and create the ASCII files from that information - so they are using live data.

What I find is that if I send C with the select code of our emulated Amiga prevue guide, then P for all the available channels with the * select codes, then the emulated prevue guide fills up with data (with the same time problems, I think doing command F next is a good idea!).

However on the next send of C - all the data clears out, the scroll resets (as in the scroll with the TV guide logo just restarts somewhere in the middle of whatever) and the grid shows no channel lines at all - and no "please stand by" either! I wondered if you found the same with your sender?

What I do know is in the atari code, on receiving command C, it checks to see if the channel lineup is same as the one it already received and discards it if it is the same - obviously the code is expecting the channel lineup to be sent over and over. Any ideas what's happening here in Amiga-land? Seems a bit odd. I would expect the channel lineup has to be broadcast over and over during the day, and having the programmes disappear when that happens is not satisfactory surely?

That's not good
I don't have the same problem at all, no matter if I'm generating the settings or using the stock "Hawthorne, CA" ones. When I first send the C block, the "Please stand by" message disappears and it scrolls just the time blocks, but once I send it programs, the listings start filling up. Once it's full, I send it a channel block for tomorrow's listings, and then all of the programs for tomorrow. Then, I send clock, settings, ads, etc., and then I send another C block. If the new C block is different than the old one in any way, it WILL clear out the listings. However, if they are the same, I see the expected behavior.

Do you want to compare what our outputted C blocks are looking like?

[AriX]

Hmm. Changed DREV to 1 in curday.dat, no discernable difference. Atari K commands still error out, and everything seems to work just as it did before.

[tin]

That's not good
I don't have the same problem at all, no matter if I'm generating the settings or using the stock "Hawthorne, CA" ones. When I first send the C block, the "Please stand by" message disappears and it scrolls just the time blocks, but once I send it programs, the listings start filling up. Once it's full, I send it a channel block for tomorrow's listings, and then all of the programs for tomorrow. Then, I send clock, settings, ads, etc., and then I send another C block. If the new C block is different than the old one in any way, it WILL clear out the listings. However, if they are the same, I see the expected behavior.

Do you want to compare what our outputted C blocks are looking like?

Hmmm, what an arse! It would seem it believes the channel list is somehow different to the old one, and flushes the listings and behaves like you describe.

Here is my example C block. Everything that is non-printable is shown as a hex code in []s. The line feeds are just for ease of reading.

Code: Select all

U[aa]AGA24005[00][8b]
U[aa]C[8b]
[12][01]BBC1NW[11]1[01]BBC 1
[12][01]BBC2NW[11]2[01]BBC 2
[12][01]ITVGRN[11]3[01]ITV 1
[12][01]CH4___[11]4[01]Ch 4
[12][01]FIVE__[11]5[01]Five
[12][01]ITV2__[11]6[01]ITV 2
[12][01]BBC3__[11]7[01]BBC 3
[12][01]BBC4__[11]9[01]BBC 4
[12][01]ITV3__[11]10[01]ITV 3
[12][01]PICKTV[11]11[01]PickTV
[12][01]YEST__[11]12[01]Yestrd
[12][01]CH4P1_[11]13[01]Ch4 +1
[12][01]MORE4_[11]14[01]More 4
[12][01]FILM4_[11]15[01]Film 4
[12][01]4MUSIC[11]18[01]4Music
[12][01]DAVE__[11]19[01]Dave
[12][01]VIVA__[11]20[01]Viva
[12][01]ITV4__[11]24[01]ITV 4
[12][01]DAJAVU[11]25[01]DaJaVu
[12][01]E4____[11]28[01]E4
[12][01]E4P1__[11]29[01]E4 +1
[12][01]FIVEST[11]30[01]Five*
[12][01]FIVEUS[11]31[01]FiveUS
[12][01]ITV2P1[11]33[01]ITV2+1
[12][01]QUEST_[11]38[01]Quest
[12][01]PICKP1[11]44[01]Pick+1
[12][01]CHALNG[11]46[01]Chall
[12][01]CBBC__[11]70[01]CBBC
[12][01]CBEEBI[11]71[01]Cbeebi
[12][01]CITV__[11]72[01]CITV
[12][01]BBCNEW[11]80[01]BBCnew
[12][01]BBCPAR[11]81[01]BBCpar
[12][01]SKYNEW[11]82[01]SkyNew
[12][01]RUSSIA[11]85[01]RT
[12][01]ALJAZ_[11]89[01]Jazera
[12][01]BBCI__[11]301[01]BBC RB[00]:
U[aa][bb][bb][00][ff]

The only thing I wonder about is that my "source"s have underscores in them (for the simulator) maybe I need to remove them in the code...... unless I have made some other error.

[AriX]

The only thing I wonder about is that my "source"s have underscores in them (for the simulator) maybe I need to remove them in the code...... unless I have made some other error.

That looks just like mine except for the underscores - I just use variable length channel identifiers.
Also I don't quite understand what's at the very end of yours (" RB[00]:"?).

[tin]

That looks just like mine except for the underscores - I just use variable length channel identifiers.
Also I don't quite understand what's at the very end of yours (" RB[00]:"?).

Hmm underscores might be it. I will try again without them and variable length (I only initially used fixed length and underscores for PGweb which I'll re-write to handle variable length - I think I assumed it cos it's padded with spaces in curday.dat)

The last bit is

RB - part of the callltrs for the last station ("BBC RB")
[00] - end of command
: - checksum (the checksum just happens to be the ascii code for the colon)