Atari EPG jr reverse engineer

[AriX]

c 3800 55 AA 41 2A 00 94 55 AA 46 41 44 32 30 38 00 00 00 00 35 59 00 59 00 00 00 00 00 00 00 00 b3
c 00c8 1f 38

This will set DST to yes, set keyboard to enabled, set speed to two, set timezone to 5, allow up to 8 ads instead of 6, and limit the amount of time blocks into the future shown to 3 (and maybe some other things, I forget :p)

Interestingly, after inputting ads, it now skips every other and only prints ads on every other block. I don't know why this changed after I sent the mode F message.

I wonder if byte 8 and 9 are some kind of when to show ads/how often to show ads kind of setting. 8 is defaulted to $00 and 9 is defaulted to $02 (in the code, those are the values it uses until it gets a F command). Might be worth a play?

Yeah, it must be something like that. Something about ad settings changes after the F command. I'll play around with that a bit later, but setting 8 to 0x02 definitely restores the whole one-ad-every-cycle thing.

[swest77]

@tin-

unfortunately no dice with Ctrl-[ wow, intimite knowledge of keyboards!!! In atari land, it seems (this is all new to me) that the raw keyboard code is 1C, this is translated to ASCII as 1B, no matter what modifier is pressed (and no other keyboard combination returns 1B at this stage) then our code has some funky translation thing that changes it to 5B. The code then looks for an incoming Keypress of 5B to do the escape routines.

Bummer. I suppose at this point, the most logical thing to do would be patching the ROM binary itself so it looks for a different (emulator-supported) key not used elsewhere to enter/exit menus. Maybe something like Ctrl-E (easy to remember, E = escape).

Next thing is to figure out what software to send the data with on the PC end?

Once the tinkering phase is over -- and If you folks are destined to wind up coding a master application for controlling EPG Jr., I'd recommend writing it for DOS. Reasons: (a) all DOS languages (C, C++, Turbo Pascal, whatever) can easily address hardware serial ports; (b) all DOS-based Windows versions (3x/9x) allow DOS programs to directy access hardware serial ports; (c) Under NT/XP/2003/Vista/7, DOSBox can run old DOS software without the usual problems (e.g. divide by 0) and allows them to access hardware serial ports; (d) DOSBox has a Macintosh version too; (e) for people who might want to run a dedicated data feeder PC for feeding data to a real Atari's serial port, DOS has the smallest hardware requirements -- the feeder machine can be a 50 MHz P.O.S. bought for $10 off eBay, run fanless, run without any hard drives (floppy only), etc.

A DOS controller app would basically make it possible to run that app stand-alone on cheap, quiet, low-power-sucking hardware, or under any modern Mac or Wintel OS.

A: timezone, could quite possibly be offset from GMT, with default -6. sent as ascii number ($36 = 6) not entirely sure yet

That's correct. It defaults to 6 even in A2000 Prevue Guide when it's first booted but cannot see data from the satellite. 6 also happens to be Tulsa Oklahoma's TZ as well (non-DST-adjusted anyway; -6 vs. GMT on standard time, -5 vs. GMT during daylight savings time).

B: something to do with timezone, value of $59 (ascii Y) could be DST, but the code that processes this is not clear to me.

That should be the EPG installation-specific "obey DST (Y)es/(N)o" switch, yeah. Some U.S. states (and some areas of some U.S. states) don't honor DST, so each installation needed to know whether or not (for example) TZ -6 should be internally translated to TZ -5 during the summer. Anyway, in the A2000 Prevue Guide software, it also defaulted to Y when it was booted w/o satellite connectivity.

FYI, if it might offer useful hints for the data stream reverse engineering task, the A2000 PG's diagnostics screen (upon boot w/o data connectivity): VIN:N BCK:B FWD:E SSPD:3 #AD:36 LINE:6 TZ:6 DST:Y CONT:Y KYBD:N GRPH:N ... don't know what most of them mean -- though SSPD does mean scroll speed (which defaults to 3 in the A2000 PG). (Incidentally, interesting bit of information that the Jr's scroll speed is effectively the product of a coincidental speed bottleneck -- a code loop's native execution speed. Not sure if it's coded the same for the A2000 PG, but if so, I wonder if that explains why my old cable company's A2000 PG always displayed "Speed 1 not available" on its 'change scroll speed' menu. Maybe it figured one loop would result in too-fast scrolling.)

@Metalguy66 - Awesome! Really, that's just cool hardware brewing. One request though (and applies to anyone else who might upload stuff in the future). Could you upload your video to regular http://www.megaupload.com (instead of http://www.megavideo.com)? Can't figure out why, but Megavideo just doesn't work for me; and worse, they want you to pay to be able to download copies. Megaupload might not be as amenable to instant viewing as megavideo, but at least it'll work for everyone and enables keepsies. Anyway, for now, no luck seeing your video.

[AriX]

Next thing is to figure out what software to send the data with on the PC end?

Once the tinkering phase is over -- and If you folks are destined to wind up coding a master application for controlling EPG Jr., I'd recommend writing it for DOS. Reasons: (a) all DOS languages (C, C++, Turbo Pascal, whatever) can easily address hardware serial ports; (b) all DOS-based Windows versions (3x/9x) allow DOS programs to directy access hardware serial ports; (c) Under NT/XP/2003/Vista/7, DOSBox can run old DOS software without the usual problems (e.g. divide by 0) and allows them to access hardware serial ports; (d) DOSBox has a Macintosh version too; (e) for people who might want to run a dedicated data feeder PC for feeding data to a real Atari's serial port, DOS has the smallest hardware requirements -- the feeder machine can be a 50 MHz P.O.S. bought for $10 off eBay, run fanless, run without any hard drives (floppy only), etc.

Interesting proposition. I have in fact been thinking for the past couple of days about what kind of system we should use for this - I think it would be really cool to simulate UV's system by setting up some sort of centralized server (which I would be happy to host) that continually sends out these various commands at 2400 baud to little PCs or devices that demodulate them (or just forward) to an Atari SIO port or Amiga serial port. The DOS idea sounds cool because it's so compatible, it can be run on a whole lot of things, and it would be pretty simple to do this that way.

I think we could store all of the data in a MySQL database (it's nice that the year isn't 1985, isn't it?) and make a web interface in order to register new serial numbers and configurations for these devices. I pay $20 a year for Schedules Direct, so as long as we make the final software open source, I can grab any TV listings in North America we need, and there are other good data sources for other countries that are free (I believe).

[swest77]

Interesting proposition. I have in fact been thinking for the past couple of days about what kind of system we should use for this - I think it would be really cool to simulate UV's system by setting up some sort of centralized server (which I would be happy to host) that continually sends out these various commands at 2400 baud to little PCs or devices that demodulate them (or just forward them raw) to an Atari SIO port or Amiga serial port. The DOS idea sounds cool because it's so compatible, it can be run on a whole lot of things, and it would be pretty simple to do this that way.

That sounds like a fascinating option, so I say, why not do both? The only thing I wouldn't do is an exclusively internet server-based approach. As much as it sucks to say, your forum may not be here in 15 years, and it would suck if something meant to get the EPG Jr. working again became obsolete itself (a literal repeat of the VBI feed's disappearance). For a project like this, which really does boil down to getting an obsolete system running again in a museum-like context, the "curator" will need a way of falling back to 100% local control.

After thinking about this for a while, I have an idea on how this could all be done...

The DOS program could be called, say, "epgfeed.exe". It would take two command-line parameters: -l=filename.ext and -d=filename.ext. -l would point it to a file that contains listing data. The format should be CSV plaintext and each line would look something like this:

12-25-2010,23:30,HBO,Star Wars (change this in your imagination depending on whatever actual listings data fields it will turn out that the EPG Jr./Sr. accept, of course)

And -d would point it to a data file containing all the other metadata stuff epgfeed.exe should parse and send out via serial in addition to the listings data (top-screen banner, number of ads to allow, number of half hour periods to show -- every last possible option the EPG Jr./EPG Sr. can accept). This data file would also be plaintext, and possibly in a line-by-line format like:

Code: Select all

SERIAL_NO="GA10249"
MAX_ADS="6"
HALF_HOUR_STARTING_OFFSET="0"
HALF_HOUR_BLOCKS_TO_SHOW="6"
TOP_BANNER_LINE1="       JOE'S CABLEVISION       "
TOP_BANNER_LINE2=""
EPGFEED_DIE_MINUTE=":30"

etc.

By having the listings and metadata files in plain text format, you would effectively be future-proofing the epgfeed.exe program. I.e., plaintext would make it very easy for people now as well as in the future to create/edit these files by hand ... and also to write their own software to create/update those files (i.e. assume someone wants to make a program that updates LISTINGS.TXT every 30 minutes with data pulled from an internet-based listings source!). On that note, notice my proposing that the metadata file contain the special line called "EPGFEED_DIE_MINUTE". I.e., a way to tell epgfeed.exe when to auto-terminate back to DOS (in the above example, it :30 would make epgfeed.exe terminate whenever the current time was :30 minutes past the current hour). Reason for this would be, for people running epgfeed.exe under single-tasking mode MS-DOS, it would allow a looping batch file like this:

Code: Select all

@echo off
:top
epgfeed -l="LISTINGS.TXT" -d="DATA.TXT"
if errorlevel 1 goto end
my_own_program_that_overwrites_listings.txt_with_the_latest_listings_data.exe
goto top
:end

I.e. this would allow someone to design their own program (now or 15 years from now) to keep LISTINGS.TXT up to date -- epgfeed.exe quits periodically, the batch file runs their updater, and then the batch file loops around and re-runs epgfeed.exe. Easy.

Then, as far as usage under multi-tasking operating systems (e.g. epgfeed.exe running in DOSBox), almost exactly the same batch file approach could be used:

Code: Select all

@echo off
:top
epgfeed -l="LISTINGS.TXT" -d="DATA.TXT"
if errorlevel 1 goto end
goto top
:end

I.e., a person running epgfeed.exe in a multi-tasking OS under DOSBox could have his own native Mac/Windows program simultaneously running outside of DOSBox that periodically (say at :25 past each hour) updated LISTINGS.TXT's contents. Meanwhile in DOSBox, the batch file would simply be causing epgfeed.exe to restart periodically and reread its data files -- making it see whatever their latest contents happened to be. (One caveat: epgfeed.exe itself would need to be coded so that upon running, it immediately read both files' contents into RAM, and then closed those files' handles -- so it doesn't hold them open as it continues to run. I.e., so it reads the files' contents once upon starting and then never touches the files again. That way, the files would be accessable for updating to processes running outside DOSBox. Just as long as they were set to update the files at an hour offset -- e.g. :10 -- that wasn't the same as epgfeed's auto-terminate time -- e.g. :15.)

Anyway, the beauty of doing it all this way would be -- it keeps things simple and uses methods people already understand: batch file loops, human-readable/editable text files that people can optionally write their own software to easily read/edit, etc. Very future-proof, and also very user-friendly -- even people who can't program would be able to make their own LISTINGS.TXT and DATA.TXT files by hand.

Furthermore, this approach would allow you to integrate your idea. You could run an internet server daemon that coughed up TV listings (real or fake), and then supply people with a Windows/Mac program that downloaded that data from your server every so often, dumping it in CSV format into LISTINGS.TXT. Presto, next time the batch file loops in the simultaneously-running DOSBox, epgfeed.exe is suddenly seeing and parsing the latest listings data and is forwarding it on to the user's EPG Jr. Just make it so your program can be set when to update -- e.g. so if the user is having epgfeed.exe die at :30 past each hour, your program's user can set it to do its thing at :25 past each hour, to avoid file access conflicts.

Anyway the only problem I can imagine with this overall approach would be under multi-tasking environments if someone mistakenly set epgfeed.exe as well as a simultaneously-running LISTINGS.TXT updater to both fire at :30 past each hour. If the latter were writing to the data files when epgfeed.exe tried to read them, a file sharing conflict would occur. But to solve that, epgfeed.exe could -- in addition to only reading each file once upon executing -- be coded to simply exit with an errorlevel if it couldn't find/open/understand the txt files when it did try to read them, etc. (See my "errorlevel" lines in the example batch files above -- they would make the batch looping stop if epgfeed.exe exits with an errorlevel higher than 0.)

Anyway. Just brainstorming here.

[swest77]

Whoops! Looks like you added more to your last post while I was busy replying to the part that was already there. To address the new part:

I think we could store all of the data in a MySQL database (it's nice that the year isn't 1985, isn't it?) and make a web interface in order to register new serial numbers and configurations for these devices. I pay $20 a year for Schedules Direct, so as long as we make the final software open source, I can grab any TV listings in North America we need, and there are other good data sources for other countries that are free (I believe).

Sure, that would be great - you could code your Windows/Macintosh updater program (the one which wrote to LISTINGS.TXT) to also write to DATA.TXT based on information obtained from your server. Thus, you would be able to provide people with accounts, and with a friendly GUI interface for configuring their EPG Jr's metadata.

The only important thing would be for epgfeed.exe itself to still have two text files (for listings and metadata) from which it reads. That way, if we're all struck down by lightning 5 years from now, anyone who still has epgfeed.exe as well as the EPG Jr. ROM will be able to build their own replacements for what you're no longer able to provide.

Guess the bottom line is, keep things "modular".

Anyway, this could turn into a pretty cool project in deed. I can already see people running EPG Jr. in an Atari emulator on their home media center PCs. Just flip over to its window to see "what's on" (with data supplied by your server). How trick!

[curtjr4]

Hello there.
I, too, am a fan of Prevue guide. I wonder though... how can I get the ROM? I would love to run it!

Best regards,
Curt.

EDIT: I should have read the forum first. I found it, and will start posting info about questions and stuff

[AriX]

Guess the bottom line is, keep things "modular".

Anyway, this could turn into a pretty cool project in deed. I can already see people running EPG Jr. in an Atari emulator on their home media center PCs. Just flip over to its window to see "what's on" (with data supplied by your server). How trick!

I really like your idea of not relying on my central server. Sounds like a good way to keep this stuff future-proof (that said, I'll keep the forum and service up as long as I can, and I don't see myself getting rid of my server any time soon :p)

We'll have to start working on and implementing this once we figure out a virtual serial interface (or a real one using SIO2PC/OSX) or real hardware (which I should have relatively soon).

By the way, I find the whole maximum ad setting in the F block command very interesting. Do you think United Video would charge to allow more ads? :O

Hello there.
I, too, am a fan of Prevue guide. I wonder though... how can I get the ROM? I would love to run it!

Best regards,
Curt.

EDIT: I should have read the forum first. I found it, and will start posting info about questions and stuff

Glad you found it. For anyone else reading who is looking for it, it's in one of the three threads on AtariAge.com that come up when you do a search for Prevue. There were several versions of the ROM posted, try a couple and you'll find the right one.

[curtjr4]

Guess the bottom line is, keep things "modular".
Glad you found it. For anyone else reading who is looking for it, it's in one of the three threads on AtariAge.com that come up when you do a search for Prevue. There were several versions of the ROM posted, try a couple and you'll find the right one.

When I went on there, I could only find one ROM. For some reason those "colored blocks" are not dashed (Or are in likes). Any reason why? Where can I find the rest of the roms?

And, I cant seem to be able to assign a time, or a guide title (With this generator: http://prevueguide.com/cgi-bin/index.pl ) When I enter it into the monitor, it is fine. I even checked it using m 3100 and all of that. Then when I type cont, it will not show up. Any solutions?

Thanks!

[AriX]

Guess the bottom line is, keep things "modular".
Glad you found it. For anyone else reading who is looking for it, it's in one of the three threads on AtariAge.com that come up when you do a search for Prevue. There were several versions of the ROM posted, try a couple and you'll find the right one.

When I went on there, I could only find one ROM. For some reason those "colored blocks" are not dashed (Or are in likes). Any reason why? Where can I find the rest of the roms?

And, I cant seem to be able to assign a time, or a guide title (With this generator: http://prevueguide.com/cgi-bin/index.pl ) When I enter it into the monitor, it is fine. I even checked it using m 3100 and all of that. Then when I type cont, it will not show up. Any solutions?

Thanks!

Nono, only one revision of the ROM itself was posted, but it was posted in like 3 or 4 different forms (one as some sort of disk image, one as left and right binaries, one as an entire 16kb ROM, then maybe another like that).

Try resetting the memory location to 3800 instead.

[curtjr4]

Nono, only one revision of the ROM itself was posted, but it was posted in like 3 or 4 different forms (one as some sort of disk image, one as left and right binaries, one as an entire 16kb ROM, then maybe another like that).

Try resetting the memory location to 3800 instead.

Hmm... even resetting the memory location to 3800 didn't work.
I'm putting in this code...

Code: Select all

c 3800 55 AA 41 2A 00 94 55 AA 54 4c 41 4e 53 49 4e 47 20 43 41 42 4c 45 56 49 53 49 4f 4e 00 96
c 00c8 1e 38 

What seems to be the problem? So confusing lol