AriX wrote: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.
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.
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