TV Guide Channel Emulation Working!

[tin]

There's a reasonably good discussion of the select code here viewtopic.php?f=2&t=18&start=20. The incoming commands over the air can be addressed with all, none, or part of the select code in the box, to make commands that work on all, none, or part of the EPG/Prevue boxes out there.

Regarding the disk being FFS, this gives me hope. I think (if my brain works correctly at this time of the morning) this would make it impossible to update 1.3 rom based boxes once they got to a certain revision of prevue guide, and therefore there should be at least some of a revision that is much earlier out there - although more than likely all returned to UV.

That said - that might explain the mention of 1.3 in the startup-sequence - older boxes WERE updated over the air, but we have a disk from a machine that had 2.04 (2.1?) ROMS and therefor was supplied with a 2.1 disk.

[AriX]

It's even easier to get random screenshots like that without having to actually change the select code - just boot with no startup-sequence (as I gave instructions for earlier) and do esq <new select code>. Unsure as to the length, but I did a typical esq ? (on the Amiga, it is a common but not guaranteed thing to use a question mark as an argument to get more information on commandline arguments) and it gave me that screen but with a ? where the select code is supposed to go. I have no idea what the length limit is on such a "select code", but might be fun for a few screenshots. Shouldn't be useful in terms of actually using Prevue, however.

Yeah, I don't understand why they have the "sel" command when all you have to do to change the select code is edit uv-er.

For the record, I have decided that I will "officially" call this version of the software "Prevue", since the only difference after essentially TV Guide Channel were the graphic assets. So, we have EPG Jr., EPG Sr. (still lost in the wild), and at least two major revisions of Prevue (the old, EPG Sr. style software, and what we have here).

Huh? We don't have the old (pre-1993) software that you're referring to. All we have is the EPG Jr. and the TV Guide Channel software (which, as you say, is Prevue). I think we should call this TV Guide Channel software, since that's what it is, even if the difference is only some strings and images... That way once we find an earlier build we won't be confused when reading older discussions.

I wonder if the local cable company still has any of their old hardware. My uncle works there as a field technician, next time I talk to him I'll ask him if he knows anyone there he could ask about it. Unless they have really old disks, they're liable to be the same version we have here, as they used the system on-air with this version of the software up until they switched to NT boxes. Still, might gather further information if we were to get another independent copy of the later Prevue.

I doubt it, UVSG recalled all of that equipment in 1999. Good luck though Maybe they still have a manual lying around.

It's also possible to make WinUAE display with the proper aspect ratio, although it requires a bit of setup to do so. Give me a day or two and I'll try to write up a guide explaining how to do it (for example, I have two configurations, once for pixel-perfect windowed mode and another for full-window proper aspect goodness).

E-UAE has a built-in option for correcting the aspect ratio

[LocalH]

Yeah, I don't understand why they have the "sel" command when all you have to do to change the select code is edit uv-er.

I'm thinking there might be something else that sel updates besides just changing the startup - either that or it was just an easier way they made to do it, instead of editing the startup directly and potentially making it unbootable (you have to remember, this software falls in the "embedded" class, so not everyone who operated it was an Amiga expert).

Huh? We don't have the old (pre-1993) software that you're referring to. All we have is the EPG Jr. and the TV Guide Channel software (which, as you say, is Prevue). I think we should call this TV Guide Channel software, since that's what it is, even if the difference is only some strings and images... That way once we find an earlier build we won't be confused when reading older discussions.

That's what I meant when i said "lost in the wild" - by "we have" I should have said "we have knowledge of". I think we should refer to the version number when we talk about it, at least some of the time, so that we can infer it from that. After all, I'm sure right around the time of the changeover that you would have both "Prevue 8.1.5" and "TV Guide 8.1.5" (to pull a version number from thin air), with the only difference being the graphic assets. So, for example, this would be "Prevue 9.0.4". Consensus wins out though, this is just my idea, no problem calling it TV Guide if I'm the only one who wants to call it Prevue

I doubt it, UVSG recalled all of that equipment in 1999. Good luck though Maybe they still have a manual lying around.

Hey, it's possible - otherwise, we wouldn't even have what we have now. I know the chances are low, but we don't know that they're 0 until I have a chance to contact him.

E-UAE has a built-in option for correcting the aspect ratio

I'm not sure if that's the proper option or not - does it make the display less wide or less tall? I remember there was an old option in the old UAE days that was useless, as it merely removed scanlines (in an attempt to make the proper aspect for a PAL Amiga), and looked quite ugly doing it. WinUAE has some nice Direct3D filter options that give a proper NTSC aspect (I can attest to this, having owned multiple Amigas throughout the years, including the two I have now).

Edit: Just found out something bad with regards to getting it running on my A2000 - the software has massive visual glitches on Kickstart 3.1. No wonder the various versions of the software are pretty much tied to Kickstart versions - they probably used some undocumented parts of the system that later versions broke. My guess is that EPG Sr. and the early EPG-style Prevue builds only ran on 1.3, and died or gave similar visual glitches on 2.0. This probably also means that it won't run properly on an AGA Amiga, since they all run at least 3.0 (not to mention the chipset differences themselves). At least I have enough fast RAM on my A2000 to be able to softkick 2.04 for the purposes of running this, so it should still work, just in a roundabout way.

Edit 2: Just tested it with an "AGA A500+" configuration, using a 2.04 ROM - it seems to work fine, need to test it sometime with a "proper" A1200 configuration, just using a 2.04 ROM instead. Seems like the incompatibility is entirely down to the ROM used, at least at this point.

[AriX]

That's what I meant when i said "lost in the wild" - by "we have" I should have said "we have knowledge of". I think we should refer to the version number when we talk about it, at least some of the time, so that we can infer it from that. After all, I'm sure right around the time of the changeover that you would have both "Prevue 8.1.5" and "TV Guide 8.1.5" (to pull a version number from thin air), with the only difference being the graphic assets. So, for example, this would be "Prevue 9.0.4". Consensus wins out though, this is just my idea, no problem calling it TV Guide if I'm the only one who wants to call it Prevue

Ah, OK, sorry for my misunderstanding, and I guess it doesn't really matter - we'll probably know what each other are talking about anyway. Including the version number sounds like a good plan.

Hey, it's possible - otherwise, we wouldn't even have what we have now. I know the chances are low, but we don't know that they're 0 until I have a chance to contact him.

Right, good point... I really hope you do find something

I'm not sure if that's the proper option or not - does it make the display less wide or less tall? I remember there was an old option in the old UAE days that was useless, as it merely removed scanlines (in an attempt to make the proper aspect for a PAL Amiga), and looked quite ugly doing it. WinUAE has some nice Direct3D filter options that give a proper NTSC aspect (I can attest to this, having owned multiple Amigas throughout the years, including the two I have now).

I don't know, I'll have to take a look and get back to you.

[Bolt96]

Not sure if anybody still cares but if you want to run it in proper aspect ratio it's fairly easy. In WinUAE under "Host", go to "Filter". Under filter settings choose "Null filter" and "No autoscaling". From there you can set up the verticle & horizontal size/positioning to your liking and it will run with those settings in any resolution. I have mine set up to Horiz. size: 0, Vert. size: 35, Horiz. position: 0, Vert position: -5.

[LocalH]

What version of WinUAE are you using? The newer ones have options on the Filter page for aspect ratio, where you don't even have to do that, just set it to automatic aspect ratio (where it lets you pick the aspect of your display) and below that, check "Keep aspect ratio" and choose between VGA or TV (I use TV here, but the difference is almost imperceptible). This works best in full-window (or full-screen), because to keep it from looking ugly you have to change the point/bilinear slider to the right (the slider just to the right). I'm using one of the later 2.0 betas, I know there are newer betas out, but I tried the most recent one and I had the emulator itself crash about 6 times, so I reverted to the earlier version I had here.

[Bolt96]

What version of WinUAE are you using? The newer ones have options on the Filter page for aspect ratio, where you don't even have to do that, just set it to automatic aspect ratio (where it lets you pick the aspect of your display) and below that, check "Keep aspect ratio" and choose between VGA or TV (I use TV here, but the difference is almost imperceptible). This works best in full-window (or full-screen), because to keep it from looking ugly you have to change the point/bilinear slider to the right (the slider just to the right). I'm using one of the later 2.0 betas, I know there are newer betas out, but I tried the most recent one and I had the emulator itself crash about 6 times, so I reverted to the earlier version I had here.

Yeah I noticed "keep aspect ratio". I guess you could do it either way. I just liked the other way better because the positioning remains the same in both modes.

[swest77]

Holy cow. I disappear for a day and look what happens. Everything comes unhinged and breakthroughs rain from the sky.

Well, a warning. This post is going to be a monster! Apologies in advance, but hopefully what I'm contributing makes up for it.

First off, amazing work, all of you, on this. Wow, wow, and just ... triple wow! I do believe I've never seen such ravenous dedication to unlocking the secrets of a famous software program. And on that note, I can't believe how many "easter eggs" and backdoors they put in the software. No wonder it was easy for cable companies to screw up: one stray cat walking across its keyboard, and 20 undocumented functions fire off.

Anyway, I had never considered the possibility of running the Prevue Guide software with an emulated genlock card. UV told me their UVGEN cards were "non-standard," and I always believed that "non-standard" implied proprietary software<->hardware I/O. Yet generic genlock card emulation is in deed working for you guys, proving that at the software<->hardware I/O level, there's nothing special about the UVGEN cards after all!

Which begs this question: if the software's needs were satisfiable with any genlock card from day one, then with existing genlock cards already on the market back then, why did UV go to the trouble and expense of R&D'ing and manufacturing their own? The only answer I can imagine at this point (which fits the facts discovered here) is, maybe the UVGEN cards were in deed "non-standard" ... but just not at the software<->hardware I/O level. Normal genlock cards work with baseband video. But since (98% sure) what cable companies fed their A2000s was a demodulated version of the C-band multiplex (i.e. 0-5 MHz baseband video + audio subcarriers still modulated at 5.8/6.2/6.8 MHz above it), then perhaps the proprietary additional circuitry in the UVGEN cards was nothing more than circuitry tasked with lowpass filtering that input signal to remove those audio subcarriers ... so the normal baseband genlock circuitry further in wouldn't mistake them for high frequency video interference.

It's a shot in the dark, but that's all I can think of for now. Bottom line is, UVGEN would be a standard genlock, just "non-standard" for its filtering abilities.

One thing that I'm a little embarrassed about is my saying in an older post that Prevue Guide also wouldn't work without UV's proprietary audio demod/switcher card. The reason that's embarrassing is, I had proof to the contrary sitting right in front of me the whole time, and I just didn't see it!

Okay, dig this:

In the A2000s, by Amiga's design, the ISA motherboard slots were not active. They only supplied voltage to any ISA cards plugged into them, making them glorified electrical wall sockets.

And I'd already pointed out that Prevue Guide would operate without its VBI decoder card because as an ISA card, the software had no way, through the motherboard, of communicating with it (or of realizing that it was missing). The ISA VBI decoder card was only inside the A2000 for power purposes. Otherwise it was completely autonomous: simply decoding VBI data from incoming video and spewing that decoded data out its own serial port at 2400 baud (which a short cable patched to the A2000's own RS-232 serial port).

What I completely overlooked however was that the audio demod/switcher card was also completely autonomous. It too was an ISA card, and therefore, the Prevue Guide software also had no way -- through the motherboard -- of communicating with it (or of realizing it was missing).

Here is proof (5 rear views of 4 different Prevue Guide A2000s):
http://img691.imageshack.us/img691/8421/13878601.jpg (unit select code = GA24913)
http://img100.imageshack.us/img100/3084/25150532.jpg (unit select code = GA24913)
http://img232.imageshack.us/img232/3862/bv10.jpg (unit select code = GA25159)
http://img689.imageshack.us/img689/8044/bv11r.jpg (unit select code = GA24062)
http://img689.imageshack.us/img689/3092/bv1z.jpg (unit select code = GA29270)

In all units, the card on the right is the VBI decoder card, and the card in the middle is the audio demod/switcher card. (The card on the left in all units is the SCSI/FAST RAM card -- it has a DB25 connector, but that connector was never used because the card was only used for RAM.)

Now look at the VBI decoder card itself:
http://img63.imageshack.us/img63/5186/ac1b.jpg
http://img4.imageshack.us/img4/9931/ac2f.jpg

And then look at the audio demod/switcher card:
http://img715.imageshack.us/img715/2791/sc1.jpg
http://img175.imageshack.us/img175/2926/sc2y.jpg

And finally look inside an A2000 with all cards removed:
http://img225.imageshack.us/img225/1346/iv2.jpg

These photos show that both the VBI decoder and audio demod/switcher cards were ISA, and both were always placed in A2000 slots that had ISA sockets (the ones closest to the A2000's rear). Only possible conclusion: the Prevue Guide software had no motherboard software<->hardware connectivity to either the VBI or audio cards! Hence the software running just dandy under emulation (with only an emulated genlock card).

Of course this does create one small mystery. The Prevue Guide software needed to control its audio demod/switcher card -- to tell it when to switch to left audio vs. right audio. And at 06:57 in this Prevue Guide video we even see that the software was able to instruct the audio demod/switcher card to switch "unexpectedly" to the satellite-delivered theme music (immediately upon a cable company technician hitting ESC to raise its menus).

Yet ... we still have the fact staring us in the face that there was no way for the software to communicate over ISA with the audio demod/switcher card.

So how did this happen? Well, after staring at those photos for a while, I believe I may see the answer. (Gotta warn, this will be speculation, but I'll try to at least keep it within the realm of "deductive speculation.") Look again at the rear view photos of the A2000s. Notice that each A2000's RS-232 port has a connector with three wires coming out of it. One of those wires (grey) goes to the DB9 serial connector attached to the VBI decoder card. So that grey wire surely carries the bulk of the RS-232 pin lines, for the 2400 baud data flow. But if you look closely (especially at http://img100.imageshack.us/img100/3084/25150532.jpg and http://img689.imageshack.us/img689/8044/bv11r.jpg), the other two wires (one grey, one brown) appear to have stripped-bare, single wire ends. That got me thinking. Perhaps the extra grey wire is connected to just one pin of the A2000's serial port, and perhaps the brown wire is connected to just one other pin of the A2000's serial port.

With that in mind, compare this close-up view of the GA24913 A2000's cards:
http://img691.imageshack.us/img691/8421/13878601.jpg
To this close-up view of the wiring label just above those cards:
http://img519.imageshack.us/img519/4421/bv8.jpg

Aaaand let's examine all those connections.

First, on the right, we see the VBI decoder card has a DB9 connector (for its decoded 2400 baud serial output) but also a green three-wire punchblock ("CART SWITCH", "GND"). "CART SWITCH" is how the Prevue Guide A2000 signalled cable company VCRs to insert local commercials on Prevue Guide's cable TV channel. In the broadcasting and cable world, contact closure (direct electrical shorting of a single wire circuit) is the traditional method for this kind of VCR playback signalling, and anyone familiar with electronic schematics will understand that the little ---o---|\ and ---o--- symbols indicate that the VBI decoder card shorts the top and middle contacts together on its green punchblock to accomplish that contact closure signalling.

The thing is ... with the contact closure method, you don't need a ground. It works like the light switches in our houses' walls, where only the "hot" side is opened/closed (unshorted/shorted) by the switch. So why does this punchblock have "GND" on the bottom pin?

Hold that thought, and now look at the audio demod/switcher card. It has two green punchblocks. The label says that the punchblock on the bottom is "BALANCED AUDIO OUT". Since I know how balanced audio works, I can say with confidence that this entire bottom green punchblock is dedicated to delivering the Prevue Guide's "fully produced" (switched) audio to the cable company's equipment (i.e. audio ready for placing on the Prevue Guide's cable TV channel). A balanced audio connector is just like an RCA phono plug (center conductor + shield/ground) ... except that with balanced audio, you have three connections: the equivalent of shield/ground, the equivalent of center conductor (audio), and the equivalent of another center conductor carrying exactly the same audio but just with its waveform inverted. Read Wikipedia's article on balanced audio if you want to know why this is done. But suffice it to say, balanced audio connectors are just the "professional version" of RCA phono connectors. By sending the center conductor twice (with one copy's voltage waveform inverted), cancellation of hums and buzzes that might induct into the wiring from nearby equipment becomes possible. Anyway, bottom line: the bottom green punchblock is fully explainable.

What isn't fully explainable is the top green punchblock on the audio demod/switcher card. According to the label, the top pin is "BACKGROUND AUDIO OUT", and the bottom pin is "AUDIO IN". And if you look again at the photos, you will notice that on all of the A2000s, there is a jumper wire (blue or green) connecting those two punchblock pins together. Well, we know that "background audio" is what Prevue Guide called the satellite-delivered theme music subcarrier. So apparently, what the audio demod/switcher cards did was make the theme music "available" there, probably so cable technicians could remove that jumper to silence that theme music. I.e., raw demodulated theme music exits on "BACKGROUND AUDIO OUT" pin, then goes back into the card via "AUDIO IN" where at various times it will become part of the switched "BALANCED AUDIO OUT" mix -- but only if the jumper isn't removed. (Remember, the Prevue Guide software had no ISA control of the audio demod/switcher card, so there would not have been a way to put a "play silence instead of theme music" option in its software menus. Evidently they made that option available instead as a hardware jumper. Etc., etc.)

But here's the thing about that jumper. It's not a balanced audio connection. In fact, as a mere positive/center conductor jumper for audio, the ground (shield) side for its audio is gonna be internal, the card's own internal chassis ground. I.e., there's no reason to make the theme music's shield side accessable on the card's external back. So ... why is there a GND pin there? Seems like along with the VBI decoder card's unexplained GND punchblock pin, we have an unexplained GND punchblock pin on the audio demod/switcher card too!

Which means in total we have: (a) Two unexplained GND punchblock pins (one on the VBI decoder card, one on the audio demod/switcher card), and (b) Two unexplained single-strand wires with stripped ends coming from the Amiga's RS-232 port. Hmm.

So I'm already thinking: more contact closure style signalling. That yep, if I haven't made it obvious enough already, the two "extra" (grey and brown) wires coming from the A2000 RS-232 port went to the otherwise-unexplainable GND punchblock pins on the VBI and audio cards. In fact, if you look closely at all the photos, you will notice that the background music jumper wire on every A2000's audio demod/switcher card is very "intentionally" bent out of the way, as if to ensure access to the center "GND" punchblock pin. And if memory serves, the RS-232 serial specification itself has numerous ground lines: i.e., if at least two of them weren't needed for the 2400 baud data connection from the VBI card's serial port to the A2000's serial port, then maybe those two ground lines were directly toggled/manipulated by the PG software as a way of directly sending rudimentary (one-way) signalling to the VBI and audio cards.

Of course, I can't say how that contact closure style signalling might have worked, exactly. But it could have been something simple, like adding/removing ground from the extra grey and brown wires' RS-232 pins in quick pulses. E.g., one quick ground closure = "switch to left", two quick ground closures "switch to right", three quick ground closures "switch to background". (Really, just guessing.) And as far as what kind of ground signalling would have gone from the A2000's RS-232 port to the VBI decoder card's GND pin, and most importantly, for what purpose ... I can only guess wildly (and therefore won't).

But either way, this would explain:
* How the software runs in an emulator without the VBI and audio cards (reason: it's trying to signal them via one-way RS-232 contact closure, which provides no means of verifying the VBI and audio cards are actually getting those signals);
* How the software could, in the first place, control the audio switching at all, despite no ISA connectivity.

Moreover, here are two things I've always noticed about the A2000 Prevue Guides. One, when they were powered up from an off state, you would hear nothing (not even the background/theme music) until the Prevue Guide software was started. And two, if the A2000 was rebooted while powered on, whatever audio the card was already switched to would stay switched to until the Prevue Guide software was running again. I.e., if the card was currently switched to LEFT audio when the A2000 was suddenly rebooted, the card would leave the left audio on continuously -- right through several promos -- until the PG software got going again. These two observations would seem to affirm my speculation that the VBI and audio cards were "controlled" only through one-way contact closure signalling. One ground pulse = left, two ground pulses = right, three ground pulses = background ... such signals would not have been able to happen unless the Prevue Guide software was running and sending them. Therefore, if the last instruction the audio demod card received was "switch to left audio", it would have stayed that way, mindlessly continuing to feed the left audio to its "BALANCED AUDIO OUT" punchblock unless and until a new switching signal arrived once the Prevue Guide software got started back up again. (And of course, when the card was off and suddenly received power, the most logical thing would have been for it to not switch ANY audio to its "BACKGROUND AUDIO OUT" punchblock -- not until a signal arrived from the PG software telling it what audio subcarrier to switch to.)

So! That leaves us with this speculative configuration:

1) Cable company: delivers the Prevue Guide C-band feed in demodulated but still multiplexed form (video below 5 MHz, background theme music on the 5.8 MHz subcarrier, left audio on the 6.2 MHz subcarrier, and right audio on the 6.8 MHz subcarrier) to three points on each A2000: UVGEN card, VBI decoder card, audio demod/switcher card.

2) UVGEN card: pays attention to just the multiplex's baseband video (with the card being proprietary only in that it is built to additionally filter out the audio subcarriers above the video)

3) Audio demod/switcher card: pays attention to just the multiplex's audio subcarriers -- demodulates them to baseband and, at any given moment, is delivering just one of them to its BALANCED AUDIO OUTPUT (according to ground-based "contact closure" type signals from the PG software via the A2000's RS-232 port). And, that it had an apparent theme music interrupt wire jumper for optionally causing silent local ads. (Note: I'm really pretty sure this wire was meant to disable the theme music, not to replace it. Replacing it in a professional environment would've required ... yup ... balanced audio in. Yet we don't even see the potential for balanced input on that punchblock. So disabling the theme music its only possible purpose IMHO.)

4) VBI decoder card: pays attention to just the multiplex's video (perhaps filtering off the audio subcarriers as well) in order to decode the VBI data and feed that decoded VBI data from its DB9 serial port to the PG software via the A2000's serial port. Also accepts ground-based "contact closure" signalling from the PG software via the A2000's RS-232 port (but unknown for what purpose).

How's all that for a deductive theory?

One note. The two reasons I'm "98% sure" cable companies delivered the Prevue Guide C-band feed in "demodulated multiplex" form to their Prevue Guides' three inputs are: first, those three inputs (VBI/audio/genlock cards) all have RF connectors; and second, most all analog C/ku-band satellite receivers in the professional world, as a common and standard feature, were and are capable of outputting the demodulated multiplex of whatever transponder they're tuned to. Considering cable companies would have all had such receivers, it would have made sense from the Prevue design engineers' standpoint to make the genlock, VBI, and audio cards work with demodulated multiplex input because that would keep hardware setup/maintenance requirements simple for the cable companies. Cable company X just tunes a single C-band receiver to Satcom F4 transponder 8, and then connects that receiver's coax output through a three-way splitter to the A2000. No other fuss, no other muss.

Anyway. As far as those extra grey and brown wires and the unexplained GND contacts on the audio and VBI cards ... only way to verify my theory of rudimentary one-way ground-based "contact closure" signalling would be ... reverse the ESQ and see if routines exist that oddly seem to flash ground on two of the A2000 RS-232 port's pins.

One last thing. The VBI decoder and audio demod/switcher cards each have two RF connectors. The bottom one (on each card) has gotta be the demodulated C-band multiplex input. Because the top two on each card, on every Prevue Guide A2000 I've seen, are always connected together with a very short RF patch cable. I have no idea whatsoever might be going over that patchcable, though. (Someone really does need to score this thing's manual!)

Pfew. Okay, some responses:

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?

Toward the end of the Amiga years, yes, fresh A2000s were getting so hard to scrounge up that they began using A3000/A4000 machines -- but by butchering their motherboards into custom cases (because all the existing Zephyrus ISA cards were full size and wouldn't fit the stock A3000/A4000 cases).

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

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.

agreed. I would speculate that there's no way in hell UV relied in good faith on cable techs to keep their A2000s' clocks accurate. With the split-second timing requirements of the audio and video, my guess is the VBI contained regular current_GMT_time updates addressed to all GA2* machines and that each of those caused the PG software in each A2000 to update its A2000's clock to continuously correct for clock drift throughout the day.

Double-posting to notify - I have located a program called Fony that will import Amiga bitmap fonts and save as Windows bitmap fonts. Not really gonna try to make a TrueType font out of this right now, but there are three fonts on the disk, with some different internal names that appeared when I imported them into Fony. [...] Gimme a little time and I'll get Windows .FON files prepared and uploaded.

*spits beer all over screen* WHOA! Actual Prevue fonts on MAH screen! That's awesome! Thanks!!

One little "bug report" though: in prevueC.fon, some of the name fields appear to be broken in that they end with 25 spaces instead of being null-terminated/padded. As a result, when I import prevueC.font into Windows, "PrevueC" appears twice in my font list in Notepad - once as "PrevueC", again as "PrevueC (twenty-five spaces here) ".

To fix, I uninstalled prevueC.fon, patched it (20h -> 00h for all bytes in offsets 229h - 241h and 4E5Bh - 4E73h), and re-installed it. Works fine now. You/others may want to do the same.

h26f is called FinalH26f internally, and is the ad font. Nothing weird about it, except the dire lack of international glyphs.

One thing I'm amazed nobody has mentioned is ... FinalH26f is the CLASSIC EPG Sr./black Prevue Guide font with only minor modifications! It even has the time header glyph still in it! Look, something I typed out in Notepad: http://img696.imageshack.us/img696/8950/snapxd.png (to get the time header glyph, I just put two ASCII 0x127 characters in a row.) Anyway from there I screen-captured that Notepad window, and went into Photoshop with it and scaled it horizontally to account for the A2000's non-square pixels. Presto, it lined up exactly with a screen capture of Prevue Guide. Load both of these in two separate browser tabs and swap back and forth between them to compare: http://img204.imageshack.us/img204/8924/snapa.png vs. http://img99.imageshack.us/img99/7431/snapba.png ... In Photoshop, all I had to draw by hand were the divider lines. Everything else (all lettering, the time header glyphs) are from the Notepad screen capture, not modified in any way except for horizontally squishing the whole lot of them (and paint-bucketing the time header glyphs as appropriate). Another comparison: Look at the "Push ESC to make another selection. / Push HELP for other edit functions." text in the blue grid software's menus vs. here: http://www.youtube.com/watch?v=190dS5kmlPA (EPG Sr). Neat. (Heh, oh, and also looks like in EPG Sr., they let people have a maximum of 8 lines for ads, not just 6.)

For the record, I have decided that I will "officially" call this version of the software "Prevue", since the only difference after TV Guide Channel were the graphic assets. So, we have EPG Jr., EPG Sr. (still lost in the wild), and at least two major revisions of Prevue (the old, EPG Sr. style software, and what we have here).

I think we should call this TV Guide Channel software, since that's what it is, even if the difference is only some strings and images... That way once we find an earlier build we won't be confused when reading older discussions.

I think we should refer to the version number when we talk about it, at least some of the time, so that we can infer it from that. After all, I'm sure right around the time of the changeover that you would have both "Prevue 8.1.5" and "TV Guide 8.1.5" (to pull a version number from thin air), with the only difference being the graphic assets. So, for example, this would be "Prevue 9.0.4". Consensus wins out though, this is just my idea, no problem calling it TV Guide if I'm the only one who wants to call it Prevue

Until more version numbers are known ... how about we just use generic umbrella terms? EPG Jr., EPG Sr., A2-Black, and A2-Blue? That way until more information is known, we'll have clear discriminating terms, and at the same time need not let the sands of time (pre/post-TV guide branding) get in our lunches.

I really want the older, Sr-style Prevue though. I'd be really stoked if someone found a copy of EPG Sr itself (which I think is actually more likely, relatively speaking, as I don't think it was updated in the same manner as Prevue).

Same here, EPG Sr. is the one I really want myself most of all. OTOH, there is one thing I'd like even more than that -- having EPG Jr., Sr., A2-Black, and A2-Blue together. And on that note, we're already 50% toward that goal...

I'm thinking there might be something else that sel updates besides just changing the startup - either that or it was just an easier way they made to do it, instead of editing the startup directly and potentially making it unbootable (you have to remember, this software falls in the "embedded" class, so not everyone who operated it was an Amiga expert).

That sounds most logical to me as well. Imagine how the phone support would go from UV to a cable technician when a select code needed to be changed. "Okay, press CTRL-C to exit to DOS, now do you have a text editor, right? Okay good, open it. Then open this startup script in it. Now find this line -- no not that line, this line. Okay good, now backspace over that word, now type this in its place, now save the startup script, now reboot." ... versus ... "Okay, now press CTRL-C, type 'sel GANEW123', press enter, reboot." #2 = win.

Okay, responses out of the way, just one last thing in case anyone stumbles on photos of a UV A2000 whose rear looks like this:

http://img85.imageshack.us/img85/5337/bv13.jpg
http://img99.imageshack.us/img99/5143/bv2c.jpg
http://img263.imageshack.us/img263/4695/bv3a.jpg

Know that this is for a Sneak Prevue A2000, not to be confused with EPG Sr/PG. The extra card you see (with the four BNC connectors) is the satellite video switcher card. (Sneak Prevue ran off a hybrid of UVGEN genlock-keyed laserdisc, and satellite video. More info here.)

[LocalH]

but we have a disk from a machine that had 2.04 (2.1?) ROMS and therefor was supplied with a 2.1 disk.

No such thing as a 2.1 ROM - 2.1 was Workbench-only. There were 2.0, 2.04, and 2.05 ROMs. 2.0 was the initial version supplied with the earliest A3000s as a SuperKickstart ROM image (in other words, the early A3000's hardware 1.4 ROM would load either 1.3 or 2.0 from the hard drive), and 2.04 and 2.05 were the versions seen in actual ROM chips for the A500/A600/A2000 (although both are called version 2.05, early A600s came with revision 37.299 which did not support the A600's ATA or PCMCIA interfaces - later A600s came with revision 37.300 which supported both). The relationship between versions and revisions is more or less out of the scope of this project - there was an early pre-1.0 Kickstart that was revision 27.3, while the release 1.0 was revision 30.x. Just some useless Amiga information for you all

For the record, the metric that Prevue uses to check for sufficient ROM version is to check for a graphics.library (which is built into ROM) of revision 36 or greater. 1.3 ROM system have revisions in the 34.x range, except for a fairly obscure 1.3 upgrade to work with the A2024 monitor, which used revision 35.x. There are some prototype 1.4 ROMs out there that have revisions in the 36.x range - I wonder (out of pure curiosity) if this will boot on those ROMs. I'll test sometime tomorrow once I've gotten some rest, it's 6am here and I'm tired.

Edit: Holy shit, swest. You got all that typed in while I was going back and forth between typing this post up, and editing the wiki. Time to soak all that in

Edit 2: Ok, I actually remember seeing the "dashed lines" glyph in FinalH26f when I was converting it to a .FON. I do notice that some of the letterforms are different, however (specifically from that screenshot, the M, 2, 3, and P look slightly different). Perhaps one should try to compare to some of the other videos (unfortunately, 99% of EPG/Prevue videos are shit quality, although I think there were some ones linked from here that I snagged that were at full 480-line resolution, and hadn't even been deinterlaced! I converted them to MPEG-2 so that I could play them back with bad-ass 60Hz fluidity). Perhaps sometime tomorrow, after I get some sleep, I'll grab the video that showed someone editing ads on EPG Sr. and check for other letterform differences.

Oh, for the record, they did have a text editor - :C/UVed - so it'd be more like "ok, hold both mouse buttons while rebooting, click 'Advanced Options', disable startup-sequence, click 'Use', click 'DF0', type 'UVed s:uv-startup', and put the new select code after 'run >nil: esq' where the current select code is". Still much harder than "ok, hold both mouse buttons while rebotting, click 'Advanced Options', disable startup-sequence, click 'Use', click 'DF0', type 'sel new select code'". Or, what swest said about Ctrl-C, although that's not useful for much else, given that it shrinks the Workbench screen to what looks like 50-75 lines tall and cuts it down to one bitplane (in order to save on precious chip RAM).

And on that note, I can't believe how many "easter eggs" and backdoors they put in the software. No wonder it was easy for cable companies to screw up: one stray cat walking across its keyboard, and 20 undocumented functions fire off.

To be fair, these probably aren't really "undocumented" functions, insomuch as they are just unknown to us. I guarantee you that 99% of these functions are detailed in the manual.

Oh, and also for the record - the genlock means jack shit. I disabled "Genlock connected" in the WinUAE configuration and the software still booted and functioned properly. Doesn't surprise me, to be honest. The only thing I would guess that the software actually controlled was whether or not the Amiga graphics were overlayed over incoming video or not - it stands to reason that this feature (as seen in some of the earlier A2-Black videos) might be specific to the UVGEN cards. If my SuperGen 2000S were functioning properly in this regard, I'd test that. I bet this thing would run on a bog-standard A500+ with a sidecar holding at least 1MB fast RAM, with no other hardware necessary.

Also, I can't imagine they'd use A4000s, given the incompatibility I've found with anything other than 2.x ROMs at this point. AGA hardware works, but 3.x ROMs do not. I can see them using modified A3000s though, given that the later ones came with hardware 2.04 ROMs (and the early ones softbooted 2.0 ROM images unless you held both mouse buttons and made them boot 1.3). No way they're going to expect cable headends to not only deal with the hackish software that is A2-Blue, but also deal with softkicking 2.0 on top of this - this would require either a hard drive, or taking up every bit of extra free space on the disk for a 2.0 ROM image.

And now I have spent almost 45 minutes typing up this post and editing it about five times to add something. I guess that's to be expected when software one has been dreaming about playing with for some 15-odd years finally shows up. I'm off to bed now, for reals

[tin]

Just wanna say swest, that was a great post I also think you're on to something

I guess the software functions on our emulators cos it tells it cards to do something (by whatever means) and doesn't care if the right response comes back.
Regard the multiple F-connectors on the cards, surely that's for looping through a single signal from the sat-recieve through the several cards?
*EDIT* - aha the stickers on the back reveal all - the baseband was looped through the serial and then the audio card. I guess there's an out on the audio card for if you want to use the signal somewhere else too.

The input for the genlock is labelled video - so unless that's just a lazy person not thinking, that suggests to me that the input to the genlock is the video from the sat-reciever, not the baseband. Of course that's more conjecture....

BTW I guessed the amigas with the BNCs were for Sneak - but what was the one that looks like it's got 7s-video connectors in the same slot (one of your pics from before)?

I agree with LocalH about the use of 4000s as well - unless of course we find there was ANOTHER version of PG, if for example the changes required to get it working on 3.0/3.1 were not much.

and.... damn Commodore for being so short sighted, surely they could have just kept manufacturing A2000s for PG? It would be more expensive of course, but I am sure UV would have preferred to carry on rather than struggle, given that they were probably priced at a real premium to the cable cos.