Prevue Guide Forums

I decided to start playing around with the Amiga software a bit (Prevue Grid/A2-Blue/TV Guide software/whatever you want to call it), since it's pretty cool, and I kinda want to see if we can get our own listings going to it, even if it involves simply editing the curday.dat file. Unfortunately, it takes a VERY long time to edit curday.dat, re-PowerPack it (since I can't find any Mac/UNIX software that can do that, I have to do it inside Workbench), replace the curday.dat on the PREVUE.ADF, and then boot it up and see what happened. A little later, I'll be looking at a way to streamline that process so that we can start doing some cool things with this, but in the meantime, I decided to revisit serial commands.

After a good bit of fiddling (I do NOT understand most of the code of E-UAE, so I kinda had to work around it with what I do know, which is perhaps even more difficult), I was able to build my UDP data listener directly into E-UAE (like I did with Atari800), and now I can send arbitrary serial commands to the emulated machine whenever I want. Here's what I've found:

The DATA Cmds counter in Diagnostic Mode works quite oddly and is confusing. For example, if I boot up the machine and send it a time command, the Cmds counter (which seems to count how many successful commands have been received) says 2 and the CErrs (which seems to count how many unsuccessful commands have been received) says 1. When I send it an "End of Data Burst" (mode 0xBB) command, the Cmds updates to 3. However, if I then send another 0xBB command, it updates to 5. It seems that it sometimes counts the first part of the command (55AA412A0094, which contains the select code of * and a checksum of 94) as an entire successful command, but sometimes it does not. The lack of consistency in the DATA counter makes this research process quite confusing.

Here's a breakdown of the various commands we know of and their impact on the TV Guide software. Keep in mind all of these commands were reverse engineered by tin on the Atari platform on software likely built in 1985, which is why we don't understand their impact on the Amiga platform as much on software built in 1999. Obviously the command structure is still fundamentally the same.

End of Data Burst (Mode 0xBB)
Works completely as expected. Turns off the data light after another command turns it on. Counted as 1 "Cmd" if following another, but counted as 2 if multiple in a row are sent.

Title (Mode T)
Is received as 1 Cmd with no CErrs, but seems to be ignored. I have not tried this command while listings are active, MAYBE it shows up as an announcement or cable provider title somewhere in the listings? (Probably not) If multiple in a row are sent, only the first is recognized as a Cmd.

Ad (Mode C)
Ad commands work as expected - sorta. They only work when the TEXT setting, which is seen in Diagnostic mode and can be changed by typing an exclamation point, is set to either R or S. They have no effect when TEXT is set to L or N. (The TEXT setting probably was changed remotely through the F command.) The other quirky thing about the ad commands is that if an ad is already set in the slot that you are sending it to - whether it was sent over the feed or locally set, sending the ad command will cause an instant Guru Meditation. Really, Prevue software engineers? Didn't bother to put any checking in there? Maybe there's some newer way of sending ads, because that doesn't really make sense. UVSG could have quickly and easily killed every single running Prevue machine by accidentally issuing a simple 55AA412A009455AA4C0100B2. Ad commands are accepted (even in L and N modes) as 2 Cmds the first time, with subsequent ad commands being received as a single Cmd.

Time (Mode K)
Sadly, the time command seems to fail on the Amiga software. It was probably changed slightly since the Atari version, but we don't really know what changed. The time command is received as two successful Cmds and one CErr the first time it is received; if multiple are sent in a row they are received as one Cmd and one CErr. The time and date that the software are using do not change.

Settings (Mode F) (Originally documented here)
Here's an interesting one. I predicted the Atari settings command would do nothing on here, but in fact it has an effect. Issuing an Atari settings block is counted as 2 Cmds, and changes almost all of the settings at the bottom. It clears the VIN, CONT, LINE, and GRPH settings, sets FWD to C, the number of ads to 0@ (instead of 36), and the timezone to 5. Basically, it totally screws up the settings, but the important thing is that it is able to mess with the settings at all. I'll definitely be playing around with this one a bit to figure out what these settings mean and how to change them effectively with the Mode F command. After issuing this command, the menus function a bit oddly and doing basically anything will result in a crash and reboot.

Interesting findings.

Especially those multiple instances of improper programmatic checking. I'll even bet you're looking at one major reason it tended to crash. With a single-byte checksum, you have a 1 in 256 chance that a stray RF noise transient will get parsed as valid data. And if the internal parsing has trouble with the unexpected, I'd say that even with good satellite reception, on a 24/7 duty cycle, you'd experience crashes several times a month. Which is about how often the software did need rebooting in many cases.

It's funny, cos the atari code has a bundle of error checking in it. Anything slightly dodgy in the data, and it dumps the lot and waits for the next command. I realise I'm no 6502 expert but the rest of it (that i've seen so far) looks pretty neat and tight as well. As you say, the reason prevue guide was so famous for crashing seems obvious.

I was able to play around with this software a little more. You can use the software without using a VBI by setting up a COM port emulator. I found two pieces of software that so far have worked on my Win 7 machine that you may be interested in trying,

The first is called VSPE - (Virtual Serial Port Emulator) by Eterlogic. The 32-bit version of this software is now freeware.
The second is from AGG Software and its call COM Port Data Emulator. This is also freeware.

The VSPE software creates a virtual RS-232 serial port on a Windows 7 system. The second software uses the virtual port that was created on VSPE and allows you to write data and traffic to the COM port, including hex files and and text files.

I have been able to get the Prevue Guide to accept some of the commands like Arix listed above to work without having to use a VBI or another machine to send code to. I'm not sure about Mac or Linux support, but it's worth a look.

What I have been able to find out about the software might intrigue you and could help determining a possible solution to a question that has come up before regarding the top half of the screen and if any communication is sent through the system. The answer to that question is yes.

I tried sending commands through the system. What's good about the COM Port Data Emulator software is that it also shows when a command is sent back through the COM port. What I was able to find is that everytime the top half screen is changed (the Logo.lst files) an acknoledgement is sent through the serial port. In fact it is a HEX 03 that is sent.

This information may now put to rest that the top half data must also come through the same information in the listings data and is passed through the ESQ software and flags the top half to work.

Also, I was looking around the main ESQ program file with another nice program for Win 7 called Notepad++. This software shows you all of the control characters and text that come up in the program. What I think is happening during the software download is that the files for curday.dat and nxtday.dat and the other files associated are actually written on the local machine and not sent over the datastream. If you look carefully towards the bottom of the ESQ file, you will find the DISKIO.c file being used, which tells me that all of the listings data is being sent through and when the system recognizes the Channel needed, it is added to the Curday.dat file. Once all of the channels is filled with data, the system must know to stop the programming and I think it writes the $LA21 code at the bottom of Curday.dat, showing that the data is complete and kicks back to the program as a subroutine.

Anyone may want to validate this information, but I'm pretty sure this is what is happening with the ESQ software (which I found ESQ is short for E-Squared, which on Wikipedia is a type of data control (yeah I know Wikipedia isn't exactly a good source, but it works in this case)).

I hope this information may help anyone out there trying to emulate the Prevue Channel data.

Thanks,
Steven

nwgatwcfan wrote:I have been able to get the Prevue Guide to accept some of the commands like Arix listed above to work without having to use a VBI or another machine to send code to. I'm not sure about Mac or Linux support, but it's worth a look.

Sounds good - unfortunately this method won't work on the Mac with existing software like E-UAE, which is why I had to hard-code a UDP serial listener into UAE myself.

nwgatwcfan wrote:I tried sending commands through the system. What's good about the COM Port Data Emulator software is that it also shows when a command is sent back through the COM port. What I was able to find is that everytime the top half screen is changed (the Logo.lst files) an acknoledgement is sent through the serial port. In fact it is a HEX 03 that is sent.

Interesting stuff, however I don't quite understand what you've discovered here. That's cool that a serial notification is sent over RS232 when the top half changes - either this is for debugging purposes, or it is in fact, as described here, a notification to the audio card to switch audio channels. In any case, it will definitely be useful to me for my simulator project if/when I implement the emulated Prevue Grid into it.

nwgatwcfan wrote:This information may now put to rest that the top half data must also come through the same information in the listings data and is passed through the ESQ software and flags the top half to work.

I don't understand what you're saying here. What is "top half data"? Do you mean the information for what to display in the top half of the screen? (i.e. ad, preview, text ad, promo, etc?) What do you mean "come through the same information in the listings data"? Are you saying that this information is or is not coming through the P and C messages, which presumably make up the curday.dat file? "flags the top half to work"?

nwgatwcfan wrote:Also, I was looking around the main ESQ program file with another nice program for Win 7 called Notepad++. This software shows you all of the control characters and text that come up in the program. What I think is happening during the software download is that the files for curday.dat and nxtday.dat and the other files associated are actually written on the local machine and not sent over the datastream. If you look carefully towards the bottom of the ESQ file, you will find the DISKIO.c file being used, which tells me that all of the listings data is being sent through and when the system recognizes the Channel needed, it is added to the Curday.dat file. Once all of the channels is filled with data, the system must know to stop the programming and I think it writes the $LA21 code at the bottom of Curday.dat, showing that the data is complete and kicks back to the program as a subroutine.

"during the software download" - What is this "software download"? I just have no idea what you're saying here - I think you may be saying that this file is written locally and dynamically as opposed to being sent bit-for-bit to each machine, which we already know.

I think you may have figured out some interesting things here, but you are a bit too vague in your descriptions for me to understand what you mean. Can you rewrite your discoveries, being a bit clearer?

Thanks!

i apologize for being vague on my last post. I guess I was too happy that I was able to get something to work.... Anyway, I will try to clarify:

What I was meaning to say is that the command to display the background, channel, date/time, and channel number of the promos at the top of the screen come through the same datastream as the listings information, not necessarily the same packet of information. I believe the data stream sends a certain command to start writing the PromoID.dat file and then sends the information that is needed on what background, channel name, date/time of program, and timing of when to show the data on screen. It then reads the channel number information from the curday.dat file or another source that contains the channel information. It will then write all of this information to the PromoID.dat file and then a data burst will be sent to end the writing of the file. I think that is why the software that you have provided currently shows No Data on the PromoID.dat file. I also think a certain and different command is sent to tell the system to write data to the files Curday.dat and Nxtday.dat, in a similar fashion (maybe with a different command sequence). I believe that Prevue Networks probably set up a specific time during the day to send these commands. So the Listings data was probably sent in the overnight and maybe the data for the Promos was sent a few hours later. That might explain why they used Paid Programming during the overnight hours, because they knew the Promo data was needed to be written and couldn't because it was being used. I think the key is if we can find the specifc sequences that tell the system to start writing data to these files automatically and also the information that the system is requiring to set up PromoID.dat, then we might can get the top portion of the screen to start working.

I hope that is a little better to understand. My English teacher in high-school used to tell me that I take the long way of saying something. I have a tendency to start rambling. So sorry....

What do you think about this?

Steven

nwgatwcfan wrote:i apologize for being vague on my last post. I guess I was too happy that I was able to get something to work....

No problem at all! I'm very happy to have people coming in and helping to figure out how exactly this whole thing works

nwgatwcfan wrote:What I was meaning to say is that the command to display the background, channel, date/time, and channel number of the promos at the top of the screen come through the same datastream as the listings information, not necessarily the same packet of information.

Yes, this is what we've thought for a while.

nwgatwcfan wrote:I believe the data stream sends a certain command to start writing the PromoID.dat file and then sends the information that is needed on what background, channel name, date/time of program, and timing of when to show the data on screen. It then reads the channel number information from the curday.dat file or another source that contains the channel information. It will then write all of this information to the PromoID.dat file and then a data burst will be sent to end the writing of the file. I think that is why the software that you have provided currently shows No Data on the PromoID.dat file. I also think a certain and different command is sent to tell the system to write data to the files Curday.dat and Nxtday.dat, in a similar fashion (maybe with a different command sequence).

Right, we've already partially reverse engineered that. This is achieved via the P and C commands, where the C commands are sent to each machine (or groups of machines) to inform them of their channel lineup, then P commands are sent to every machine and contain information on what program was on which channel and when. If a P command is received for a channel that is not in the local machine's lineup, it will ditch the information. Otherwise, it will write it out to curday/nxtday.dat.

nwgatwcfan wrote:I believe that Prevue Networks probably set up a specific time during the day to send these commands. So the Listings data was probably sent in the overnight and maybe the data for the Promos was sent a few hours later. That might explain why they used Paid Programming during the overnight hours, because they knew the Promo data was needed to be written and couldn't because it was being used.

I think you're right that promo data was probably saved in PromoID.dat, but I doubt that this has anything to do with what they aired on the channel at night. I know for a fact that they did not always do this, and... that would just be a silly way of doing things. I think they probably didn't send out all of the promo information for the whole day at once, but more likely every hour or something. Plus, it's not like computers aren't capable of multitasking - I'm sure the Amigas were capable of writing PromoID.dat and reading it at the same time (not literally at the same time, of course).

I don't think they sent out different types of data at different times, necessarily (although perhaps software upgrades at night), I think they probably just constantly sent out as much as they could - I would guess that they had a loop, where it would send out all the channels, then all the programs, then all the settings (mode F), then all the guide titles, all the ads, all the promo information, or something like that, with current times sent every little while as well.

nwgatwcfan wrote:I think the key is if we can find the specifc sequences that tell the system to start writing data to these files automatically and also the information that the system is requiring to set up PromoID.dat, then we might can get the top portion of the screen to start working.

Yes, in order to tell the guide what we want to show up on the top, we'll probably have to somehow reverse engineer ESQ to figure out what commands need to be sent to get that working.

Can't wait to get some of this figured out!

AriX wrote:I decided to start playing around with the Amiga software a bit (Prevue Grid/A2-Blue/TV Guide software/whatever you want to call it), since it's pretty cool, and I kinda want to see if we can get our own listings going to it, even if it involves simply editing the curday.dat file. Unfortunately, it takes a VERY long time to edit curday.dat, re-PowerPack it (since I can't find any Mac/UNIX software that can do that, I have to do it inside Workbench), replace the curday.dat on the PREVUE.ADF, and then boot it up and see what happened. A little later, I'll be looking at a way to streamline that process so that we can start doing some cool things with this, but in the meantime, I decided to revisit serial commands.

Given that, I'm going to see if there isn't a way we can install this bad boy to a hard drive (even if you have to have a "work" floppy in DF0: to write certain files). Might make things a little more palatable if you can reboot, open PowerPacker, compress the files, then just open up ESQ (or a script that sets up what's necessary for ESQ then launches it).

Also, seeing as I just got Mom's DVD recorder back from my uncle, I should be able to make a real hardware video within a week or two, as soon as I can find the damned remote for it (it records perfectly fine without a remote, but the front-panel interface is especially spartan, and won't even allow finalization, meaning that with no remote, discs it records are only playable on Samsung DVD recorders, unless anyone knows a generic way to finalize DVD recorder discs on a PC). If I have to, I'll spend $25 to order a replacement remote from Samsung.

Have a ganders here viewtopic.php?f=5&t=67&start=10#p535

I've got it installed on a virtual (windows folder) HD under UAE, and on a real HD on an Amiga 2000 both with the above startup-sequence (albeit modified for the Amiga, its harddrive is WHD0:). You don't need a floppy disk but you do need the DF0: dismount bit in startup-sequence as DF0: is hardcoded in several places.

I've been doing all my information gathering work on un-powerpacked versions of the files in the virtual HD on the PC. I can update the curday.dat and nxtday.dat files in windows (with gvim ) while the Amiga is running, then have it reload the files with Shift-D.

The Amiga install was done by using a USB hard drive adaptor, prepping, formatting the drive and copying the files under UAE, then moving the HD to the Amiga. The the only thing is once the Amiga gets to the stage where you would see the "Please Stand By" message, nothing happens - at all - no disk access, no errors, no picture, no response to keyboard. Really odd. I suspect there's a compatibility issue with the PG software and the hard drive controller.

AriX wrote:Ad (Mode C)
Ad commands work as expected - sorta. They only work when the TEXT setting, which is seen in Diagnostic mode and can be changed by typing an exclamation point, is set to either R or S. They have no effect when TEXT is set to L or N. (The TEXT setting probably was changed remotely through the F command.) The other quirky thing about the ad commands is that if an ad is already set in the slot that you are sending it to - whether it was sent over the feed or locally set, sending the ad command will cause an instant Guru Meditation. Really, Prevue software engineers? Didn't bother to put any checking in there? Maybe there's some newer way of sending ads, because that doesn't really make sense. UVSG could have quickly and easily killed every single running Prevue machine by accidentally issuing a simple 55AA412A009455AA4C0100B2. Ad commands are accepted (even in L and N modes) as 2 Cmds the first time, with subsequent ad commands being received as a single Cmd.

Interesting! I get a different result. If I set to mode S I can sent my test advert to the box, and it will show. However it seems to create a second (single) advert that contains the text of whatever program it's currently writing onto the bottom of the grid (way off screen) at the time the Ad is displayed. More lovely PG programming I guess.

I tried mode R as well and once got a guru, and once worked better than mode S. Interesting. I think we're missing some advert delimiter, and some control parameters that tell the box which adverts are enabled.