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:
AriX wrote:LocalH wrote: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).
AriX wrote:LocalH wrote:tin wrote: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.
LocalH wrote: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.
LocalH wrote: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.)
LocalH wrote: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).
AriX wrote: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.
LocalH wrote: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.
LocalH wrote: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...
LocalH wrote: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.)
Maybe they still have a manual lying around.
