TV Guide Channel Emulation Working!

[LocalH]

Now I see why they locked speeds 0 and 1...when it comes time to push the new time block headers over the boundary, the scroll slows down for those lines, then speeds back up when they're done, which would be quite jarring to the viewer (not to mention it'd be hard to read at those speeds anyway).

[AriX]

Ok, this is definitely odd...In :C, there is a command called MakeFiles. Looking at it in a hex editor, it appears to be a tool to read the two ROMs from an A3000 SuperKickstart disk and write them out to individual files. I can't figure out why this command would be on the disk, considering that I don't think UV/Prevue/TVG ever, ever used A3000s as standard hardware, did they?

Not as standard hardware, but they did resort to using some 3000s after 2000s became incredibly hard to find. Ask swest77. Maybe that was just a standard tool included in 2.04 releases though?

Taping only C will show date information... such as the Julian day, jday1, jday2, etc.

Huh? I don't see that.

[LocalH]

Re:Makefiles - definitely wasn't a standard part of any AmigaDOS version. I used it on my A3000 years ago, I think it came on one of the old Fred Fish disks.

Re:C - On the diagnostic screen. It's a little slow to respond tho.

Also, got something good:



Shift-A on the listings screen. Going to reboot and confirm that's all it takes.

Edit: Hells yeah. Rebooted, pressed Shift-A, and it popped up. Sweet.

Once we get this thing RE'd and figure out a modern way to feed it data, who's up for a complete overhaul of the branding, font, colors, and everything?

Edit 2: Also, Shift-N on the listings brings up text saying BitPlane1 = 40468. Shift-K reads something from the disk, but I don't know what it is. First time I do it, it reads something from track 62. Next time, it goes to track 6. With a disk editor, might be able to figure out what files it's accessing.

[AriX]

Re:C - On the diagnostic screen. It's a little slow to respond tho.

Ah, cool. I did find out that control-C on the menu will quit the application, dumping you to a DOS window... Rerunning ESQ results in: "YOU CANNOT RE-RUN THE SOFTWARE IN THIS MANNER. PLEASE RE-BOOT!!". :p

Edit: Hells yeah. Rebooted, pressed Shift-A, and it popped up. Sweet.

Once we get this thing RE'd and figure out a modern way to feed it data, who's up for a complete overhaul of the branding, font, colors, and everything?

Awesome, and yes

[LocalH]

/ (forward slash) on the listings cycles between 9 different "ViewMode" tests, with grids similar to Ctrl-G, but on the top half of the screen:

0 - Hires interlace, right half
1 - Hires interlace, left half
2 - Hires interlace, full-width
3 - Black screen (speculation: could be a black grid over color 0, which would key over external video)
4 - Hires interlace, full-width (seems identical to 2)
5 - Lores interlace, full-width
6 - Hires noninterlace, full-width
7 - Lores noninterlace, full-width
8 - Hires interlace, left half (speculation: seems like it might have been for some early PAL porting work that never materialized, as the image seems to be taller than the rest of the tests, which are 240 lines tall and 120 in noninterlace - possibly this test is 288 pixels tall?)

Shift-T seems to bring up the ads, too. Don't know the different, might come into play with multiple ads in rotation.

[tin]

(@arix: see I *SO* went to bed like I said I would)

I have managed to inject data via winUAE, com0com and a terminal program I never heard of before called Hercules. It allows me to paste in the hex from the cgi scripts and send them straight away.

The cursor flashes like you said, but the program doesn't seem to do anything with the data.

What I have noticed however is if you send the data while in the diagnostic screen, that tells you a bit about what's going on. There's what I assume to be write and read pointers (H: and T:) and a Cmds: and a CErrs which I'm taking to mean Commands and Command errors.

I noticed the central message and top line commands are accepted, but I can see how these maybe don't do anything in Amiga Prevue Guide - the clock (mode K) command increases the CErrs counter, and assume therefore the clock command doesn't work quite the same as works for the Atari. These two factors combined mean all of the commands so far reverse engineered are no use in Amiga Prevue guide - i best carry on then

Right now I MUST get some kip.....

[LocalH]

Shift-D seems to read something from track 51.

I can see why there might not be much to the clock command - the Amigas generally used as Prevue Guide machines had battery backed clocks. I have noticed that, using WinUAE's "Synchronize clock" function, Prevue shows the time as two hours behind - this makes me think that they had users set the clock to match their central server, and used the time zone setting to modify this. When synchronizing the clocks, WinUAE merely ensures that the Amiga clock stays set to the same time as the Windows clock, so I know it's Prevue modifying it.

Edit: Well, DiskSalv didn't give me anything useful, as AriX mentioned. I was able to determine that Prevue/UV/whoever built this disk by starting with an 2.1 Install disk, and deleted a bunch of stuff (the undeletable files were: Install 2.1.info, Install Languages.info, Install Printers.info, Tools.info, Disk.info, Storage.info, Prefs.info, and t/version.number). t/version.number contained the following:

Code: Select all

version 38.34 (21.7.92)
Disk © Copyright 1985-1992 Commodore-Amiga, Inc.

[AriX]

I noticed the central message and top line commands are accepted, but I can see how these maybe don't do anything in Amiga Prevue Guide - the clock (mode K) command increases the CErrs counter, and assume therefore the clock command doesn't work quite the same as works for the Atari. These two factors combined mean all of the commands so far reverse engineered are no use in Amiga Prevue guide - i best carry on then

Ah... I hadn't looked at the diagnostic screen earlier when I was hacking around with serial data... However now that I look at it, the number of commands == the number of errors, so the K command definitely isn't going through :p
Good that 0xBB still works to stop the data light though. At least we know it's partially the same :p

I can see why there might not be much to the clock command - the Amigas generally used as Prevue Guide machines had battery backed clocks. I have noticed that, using WinUAE's "Synchronize clock" function, Prevue shows the time as two hours behind - this makes me think that they had users set the clock to match their central server, and used the time zone setting to modify this. When synchronizing the clocks, WinUAE merely ensures that the Amiga clock stays set to the same time as the Windows clock, so I know it's Prevue modifying it.

Well, they definitely didn't manually set the time, I think it just synchronized with Amiga time in order to have mostly accurate time immediately on bootup as opposed to Atari's January 1 12:00 :p

What happens is they send out a clock command with serial number "2A 00 94" (Which is just * and then a checksum for it) which sets the clock on every single Prevue/EPG machine connected to the satellite, and then they send out individual F settings blocks for each machine (or each group of machines if the select codes/serial numbers are grouped by region, which they probably somehow are) that set the time zones for each individual machine. What we have here is that the time zone is set for wherever this software image was last used, which is likely why it has an incorrect time.

By the way, LocalH, how do you know what "track" it's reading from?

[LocalH]

AriX: See those "LED" looking things at the bottom of my screenshot? (I'll post it again after this for reference) Nifty function that WinUAE has to display drive LEDs (and a bit more information regarding CPU usage, sound latency, and framerate). From left to right: sound latency, CPU usage (I'm running the CPU as fast as the emulator can do it but still ensuring that the custom chips can do what they need to do, hence the 100), frame rate, power LED (and low-pass audio filter indicator), hard drive LED, CD LED (unused here), DF0, DF1, DF2, DF3.



Also, I think this software may have been used at a Warner Cable setup in California. Found in :OI_00.dat was the following:

Code: Select all

SBP002 :NNNNNNXX00 -1  NNA $29.95   To order call (310) 783-6500 0

and many other similar lines. Did a Google search for the phone number and amongst the results was this link: http://www.livestrong.com/business-time ... -783-6500/

[AriX]

Also, I think this software may have been used at a Warner Cable setup in California.

Yeah, I believe it was used in L.A. judging by some of the local channels in curday.dat.