Prevue Guide (EPG Jr.) Reverse Engineering

[AriX]

Hi all,

 

I'm posting to request some help with reverse engineering the EPG Jr. software that ran on the Atari 130XE and was a forerunner of the Amiga-based Prevue Guide. We at the Prevue Guide forums have figured out a lot about this particular software, mostly thanks to a user named tin, and can now input our own ads (by going to the scroll speed menu, typing an exclamation point, and pressing escape to unlock the ad menus), and send the software a few different types of commands (like telling it about settings, the current time, or a title for the guide).

 

Essentially, the software received listings and commands through the Atari's SIO port. The data was sent nationwide through a satellite transponder, and encoded in the VBI of WGN's national feed. When data is received over serial, it is written to 0x3800 in memory, and the address of the end of the data is written to 0x00c8. (For example, a time command 55 AA 41 2A 00 94 55 AA 4B 00 00 00 00 00 00 00 01 01 b4 would be written to 0x3800, and then 13 38 would be written to 0x00c8 because the data ends at 0x3813). I don't know where the serial format parsing begins exactly, but I can see that at 8ea1, the code branches off into parsing the different possible command modes. The modes listed are P, 0xBB, R, O, E, K, F, M, Z, T, N, L, C, and 0x03. From what we know so far: C is for ads, K is for clock, T is for title, F is for settings, and 0xBB is for an end message. We also know that P is for program and C is for channel, but we don't know what format those are expected to come in as. An overview of the data format can be found here.

 

Every message is checked using a one-byte checksum. A message will start with 55 AA 41, then a serial number called a "select code" to determine which machines should pay attention to the command (or 2A for all machines), then a 00 to end the string, and then a checksum for the select code (for 2A it would be 94). Then, there is another 55 AA, and the mode code (for example, 54 for title, because 0x54 is an ASCII T). Finally, we have the body of the message, which can be just a normal ASCII string, and is terminated by a 00 byte, and lastly there is another single-byte checksum which is computed by starting with a value unique to the mode (for example, for T the checksum would start with 0xAB), and then bitwising the initial value with each byte of the body until the 00.

 

If you want to help bring multiple pieces of iconic software that ran on classic computers like the Amiga and Atari to life, please help out with this project. Thanks!

 

Resources:

UVSG Generator - This will generate commands for all of the modes we know of at this time.

Disassembly of EPG Jr. Cart - This is a disassembly created with dis6502.

EPG Jr. Binary - This is the Atari binary of the EPG Jr. software.

UVSG Satellite Data Format - This is an overview of the format that data was received in on both the Amiga and Atari platforms.

Curday.dat Data Format - This is a thread partially explaining the format used to cache listing data on the Amiga platform, which likely can help in the process of reverse engineering the EPG Jr.

 

 

If you have any more questions about what we know already about the data format, please feel free to ask - I didn't explain it very well or very fully.

Edited October 23, 2010 by AriX

[AriX]

Apparently I can no longer edit the above post, so I'll post my addition here:

 

The software ran on a 130XE, and was discussed in several threads on these forums. (The information in those threads is mostly speculation and is mostly incorrect - it's an interesting read, but don't trust it all too much)

[Rybags]

I had a quick look at the listing.

 

There are parts that seem to be valid code but are just represented as data blocks.

 

There doesn't seem to be any OS calls - not unique but kinda strange. Do you know if this thing handles all the serial I/O itself?

 

IMO the key to the whole thing would be to work out the serial stuff... in all probability the serial routines will have fixed block lengths that might be dependant on individual commands, working that out would go a long way to reverse-engineering the system.

 

Also, do you have the hardware that sends data over to the Atari, or are you working out all this based on the cartridge software alone?

[AriX]

I had a quick look at the listing.

 

There are parts that seem to be valid code but are just represented as data blocks.

There's probably a better way to come up with a disassembly - you would know better than I. However, it seems that most/all of the routines relating to serial command parsing are present in the correct format.

 

There doesn't seem to be any OS calls - not unique but kinda strange. Do you know if this thing handles all the serial I/O itself?

I'm not entirely sure - the data just comes in as raw serial input to the SIO port at 2400 baud. I don't think it really matters all too much though. The important part is that after the data is received, it is written to 0x3800 in memory and parsed from there.

 

IMO the key to the whole thing would be to work out the serial stuff... in all probability the serial routines will have fixed block lengths that might be dependant on individual commands, working that out would go a long way to reverse-engineering the system.

Also, do you have the hardware that sends data over to the Atari, or are you working out all this based on the cartridge software alone?

 

Again, I'm not sure the raw I/O routines really matter as much as the routines that parse the commands. Of course, I don't know much about this, so I'm probably just talking out of my ass, but this is just what I understand I don't have any hardware that sends data to the Atari other than a regular SIO2PC; as I said we have already reverse engineered parts of the data format and can successfully send it many types of messages, but not listings (the P and C commands that were used to define what channels were in a machine's lineup and what programs were on those channels)

Edited October 23, 2010 by AriX

[phaeron]

From what I can tell, the software uses $3800-3FFF as a continuous input ring buffer. The serial I/O receive routine is at $ACE4 and uses ($C8) as the write pointer, while the main loop follows it using ($F0) as the read pointer. $B235 is a routine used to wait for a specific byte sequence, while $B272 is the low level get byte routine. The code at $8F16 initiates the wait for the 55 AA 41 header, after which $9046 grabs the command byte into $0480 and the code at $8E9E dispatches it. I can't find the connection between $8F16 and $9046, but I don't think that's necessary to decode the packet formats.

[AriX]

From what I can tell, the software uses $3800-3FFF as a continuous input ring buffer. The serial I/O receive routine is at $ACE4 and uses ($C8) as the write pointer, while the main loop follows it using ($F0) as the read pointer. $B235 is a routine used to wait for a specific byte sequence, while $B272 is the low level get byte routine. The code at $8F16 initiates the wait for the 55 AA 41 header, after which $9046 grabs the command byte into $0480 and the code at $8E9E dispatches it. I can't find the connection between $8F16 and $9046, but I don't think that's necessary to decode the packet formats.

 

Cool, thanks Sounds like you've got the low-level stuff figured out.

[Savetz]

Here's a dump of another EPG Jr. Rev 6 that came across my desk.

 

Provenance: the guy from this YouTube video posted the EPROM dumps up as he couldn't get them to work, an interested party downloaded and trimmed them to the correct size, and passed the file to Twitter user @halftheisland, who passed the ROM to me.

 

I was going to also tell the folks at the Prevue Guide Wiki but can't find any contact info there.

 

-Kay 

EPG Jr. Rev 6 (19xx)(Prevue)(US)[HMJR6].bin

[AriX]

8 minutes ago, Savetz said:

Here's a dump of another EPG Jr. Rev 6 that came across my desk.

 

Provenance: the guy from this YouTube video posted the EPROM dumps up as he couldn't get them to work, an interested party downloaded and trimmed them to the correct size, and passed the file to Twitter user @halftheisland, who passed the ROM to me.

 

I was going to also tell the folks at the Prevue Guide Wiki but can't find any contact info there.

 

-Kay 

EPG Jr. Rev 6 (19xx)(Prevue)(US)[HMJR6].bin 16 kB · 1 download

This is awesome, Kay! Wonderful find and thanks for sharing!

 

Fwiw, I'm the guy behind the Prevue Guide Wiki, so you reached the right place

 

If you're interested, feel free to post this on our Prevue forums over here, also: http://ariweinstein.com/prevue/index.php (otherwise I'm happy to share it there!)

[+MrFish]

3 hours ago, Savetz said:

Here's a dump of another EPG Jr. Rev 6 that came across my desk.

 

 

Using file compare, the only differences between this Rev. 6 ROM and the other Rev. 6 ROM I have are first two characters that follow "B:" on the boot screen. This ROM has "HM" and the other ROM contains the characters "NJ" instead.

 

Edited June 13, 2020 by MrFish

[Savetz]

On 6/12/2020 at 3:37 PM, AriX said:

This is awesome, Kay! Wonderful find and thanks for sharing!

 

Fwiw, I'm the guy behind the Prevue Guide Wiki, so you reached the right place

 

If you're interested, feel free to post this on our Prevue forums over here, also: http://ariweinstein.com/prevue/index.php (otherwise I'm happy to share it there!)

 

Go for it, feel free to post it there yourself. Glad I found you

 

-Kay

[tschak909]

would love to actually put some actual data in it.

-Thom

[Savetz]

On 6/12/2020 at 3:37 PM, AriX said:

This is awesome, Kay! Wonderful find and thanks for sharing!

 

Fwiw, I'm the guy behind the Prevue Guide Wiki, so you reached the right place

 

If you're interested, feel free to post this on our Prevue forums over here, also: http://ariweinstein.com/prevue/index.php (otherwise I'm happy to share it there!)

Well, http://ariweinstein.com/prevue/index.php doesn't seem to work anymore, so I sure hope @AriX is still around here.

 

Yesterday at Portland Retro Gaming Expo I acquired an EPG Jr. (!!!), serial number MDJR6. I really want to help figure out how to get program data into it. What do we know about this? I read somewhere that no one has figured it out yet, but maybe that information is out of date. I hope it's something easy like cassette audio data, in which case I know @tschak909 can make it work. (I think the baseband cable signal might be converted to audio before being passed to the SIO cable.)

 

My EPG main menu says "FFFD" and also "KB N". What's FFFD mean? When I use the Atari keyboard to navigate to View Ads or Edit Ads, it says KEYBOARD NOT ACTIVE, even though the Atari keyboard clearly works. I can navigate to Change Scroll Speed to change the scroll speed.

 

When I unscrewed the unit to reveal the ROMs, I found that the EEPROM windows were uncovered! I have never moved so fast to turn out the lights and find some electrical tape to cover the windows.

 

-Kay

 

 

[Savetz]

Small update: FFFD seems to be the amount of memory left for advertisements. To make the keyboard active, go to Change Scroll Speed then press ! then ESC. (I learned this via https://prevueguide.neocities.org/guides/EPGJr/2)

 

I spent a lot of time today looking at EPG Jr. source code, but figuring out how to add program listings is beyond me. Some people apparently did figure out how to inject program listings (https://www.youtube.com/watch?v=XZG3K0Ngcmc and https://www.youtube.com/watch?v=yd08MOLl_qg) but the Prevue Guide Forums (http://ariweinstein.com/prevue/) are gone, and I couldn't find much of them in the Wayback Machine.  

 

I wrote a python script to help me inject settings into memory using the debugger in Atari 800 — the script's main benefit is to compute the checksum value. It's attached in case anyone else cares. 

 

I realized that in emulation, one can avoid dealing with the continuous input ring buffer by always writing the data to $3800, and resetting the read pointer to $3800 immediately after every write. (On a real system getting data via SIO — if we ever get far enough to try this on a real system — this step isn't necessary... it's handled automatically as the data is received.)

 

Anyway, I think I'm stuck until @AriX shows up and reveals what he knows about injecting channel/program data, but hasn't published.

 

Useful web sites for this project: https://prevueguide.com/cgi-bin/index.pl — for injecting Time/Date and Title.

     https://prevueguide.com/PREVUE.txt — source code

     https://prevueguide.com/index.php/UVSG_Satellite_Data#Command_Modes — UVSG Satellite Data

     https://docs.google.com/document/d/1uayZAO1sXRZzp9EUvIYl-jQ7GD_Jk7L0yR7igYjnDu8/edit — "Inputting listings, stuff to know" (but I think the checksums are bad)

     https://prevueguide.neocities.org/guides/EPGJr — general info

     https://prevueguide.com/wiki/EPG_Jr. — ROMs and more general info

 

-Kay

checksum.py