Could close captioning be fudged by a carefully timed kernel?

[tschak909]

Title says it all.

 

Closed captioning is carefully timed pulses over line 21 of the vertical blank, so I wonder....

 

The thought entered my twisted little mind, and I was wondering what everybody else thought?

 

-Thom

[Rybags]

I had a similar thought some time back to do similar with the 8-bit computer.

 

Technical hurdles for both systems:

- an interlaced signal might be required (both can do this)

- bandwidth, many CC/Teletext systems equate to a bitrate equivalent to about 320 pixels per scanline. 2600 simply can't do it.

- outputting video on scanline 21. 2600 should have no trouble, the computer normally only has 240 available scanlines for normal display but a hardware bug exploit can be employed to allow PM graphics to appear elsewhere.

 

Problem with using PMGs is effective resolution equates to 160h, graphics data has to be stored by the CPU and there's simply not enough objects and time to reload/reposition to cover the entire scanline.

 

2600 has the repeat mode for Players which could help, but there'd still be gaps. Also most of these systems have stuff like leaders and parity to deal with.

 

Other problem regarding both is horizontal capability for graphics. The computer can for the most part output video to ~ 177 colour-clocks, AFAIK the 2600 is limited to 160 colour-clocks.

 

Possibly the Playfield could be used on 2600 and extra resolution fudged by colour register changes to give half-pixels giving perceived 80 pixel width instead of 40 in places. Still, nowhere near the CPU speed required is available.

Edited December 15, 2013 by Rybags

[Rootbeer]

I'm no electrical engineer, but if the timing diagrams I've found regarding NTSC captioning are accurate, and I'm reading them correctly, it looks like one CC data bit is about 1/32 of a full scanline (including HBlank and colorburst). There's also clock lead-in signal which would require about twice the precision to represent digitally.

 

Given the TIA's precision of 228 color clocks per line, that puts us at about ~7.1 color clocks per data bit, or ~3.6 clocks per half-cycle of the lead-in signal. If these can safely be rounded up to 8 and 4 respectively, then it might not be difficult to build something that looks like a CC signal out of player sprites and playfield bits.

 

That would be something like a 15% deviation from the spec, though, and I'm not sure whether the tolerances of CC decoder implementations would be that large.

 

 

[Andromeda Stardust]

I'm no electrical engineer, but if the timing diagrams I've found regarding NTSC captioning are accurate, and I'm reading them correctly, it looks like one CC data bit is about 1/32 of a full scanline (including HBlank and colorburst). There's also clock lead-in signal which would require about twice the precision to represent digitally.

 

Given the TIA's precision of 228 color clocks per line, that puts us at about ~7.1 color clocks per data bit, or ~3.6 clocks per half-cycle of the lead-in signal. If these can safely be rounded up to 8 and 4 respectively, then it might not be difficult to build something that looks like a CC signal out of player sprites and playfield bits.

 

That would be something like a 15% deviation from the spec, though, and I'm not sure whether the tolerances of CC decoder implementations would be that large.

Even if the VCS can be made to spit out garbage characters, it would be pretty funny. I'm not sure what practical application it would serve though. I've seen random garbage in the past output on the TV due to poor reception of NTSC analog broadcasts.

 

EDIT: I can't imagine closed captioning being useful in a video game. Most game consoles and DVD players have their own settings for displaying text onscreen. There's no set standard for formatting of CC data, and different manufacturers display different font sizes or place text in different positions, etc. On many sets there is no transparency option so large areas of video are blocked. The text could very likely block crucial gameplay elements making gameplay klutzy. I also have a feeling that since analog is depreciated and future displays will only offer legacy support for analog A/V, support for many advanced features such as closed captioning, SAP, ratings, etc over analog signals may be spotty at best (they were only widely supported initially due to government mandates), and I'm sure A/V - HDMI converters will likely ignore these embedded legacy signals altogether.

Edited December 16, 2013 by stardust4ever

[SeaGtGruff]

The most commonly suggested use for closed captioning is to display text that's better than what the 2600 can do normally, such as for a text adventure-- or any other type of game where text is displayed for whatever reason.

[+thegoldenband]

I love this idea, and would be happy to test proof-of-concept ROMs on real hardware + my Toshiba CRT. I don't see it being used in an action game during gameplay, but it'd be a brilliant surprise/Easter Egg during a cutscene or title screen.

 

I keep CC turned on all the time at home, and I love it when the system goes haywire and/or captions stay onscreen for longer than intended, resulting in inappropriate combinations. Political ads are great for this, since they don't usually seem to use CC, so you'll get a politician giving a speech with "May cause drowsiness" captioned underneath.

[iesposta]

I remember reading about this subject in the Stella List.

I don't recall how far they got.

[+thegoldenband]

Here's a post from Eric Ball with some code, and here's an earlier thread about it.

[RevEng]

There are a number of things that we can't do to spec when trying to generate a line-21 CC signal from the 2600, in addition to the mentioned resolution difference...

• The run-in is supposed to start well before the visible screen, right after the color burst signal. AFAIK, the playfield and players can't be positioned/drawn in the non-visible part of the screen.
• Using 4 and 8 pixel sizing, valid line 21 CC data would be 180 color clocks wide, and we have 160 color clocks on the visible screen.
• The run-in is supposed to be a sine wave. I don't know if the extra harmonics would be a deal breaker or not, but certainly square waves are out of spec.

In a previous test I tried generating the run-in, start bits, and byte 1 (without byte 2) on the visible screen, but no-go. I don't know if the issue was the lack of byte 2 throwing off the serial decoder, or one of the other issues I mentioned.

 

If anybody else is going to take a whack at it, this site has some nice on-screen representations of the bytes, and a handy line-21 waveform graph.

[+Gemintronic]

I always dreamed of somehow overlaying the output of the TellyMate onto the 2600 screen:

https://www.sparkfun.com/products/9313

 

If the joystick port can do I2C then maybe it could talk to the TellyMate?

[yllawwally]

You would need a video overlay circuit such as https://www.sparkfun.com/products/9168

The tellymate is more of video card for a microcontroller.

[RevEng]

If we stick to non-RF composite video like the previously mentioned devices, than it can be done a lot cheaper. The game kernel itself can provide an external signal to begin the text output, so the usual composite sync detection and timing complexity can be skipped. It would probably take a $2 microcontroller and not a whole lot more to overlay text.

 

That said, I'm not sure if it would be worthwhile to produce another piece of specialized hardware.

[Kyle22]

Would this be easier on the 8 bit ANTIC / GTIA system?

[Rybags]

Computer has much better chance of being able to do it but a big problem is the fact that Antic graphics can only be generated in the 240 scanline zone which is outside of what CC or Teletext uses.

 

GTIA graphics ie PMGs can be made to appear outside that area (even in the VSYNC scanlines) but the problem there is the CPU has to do all the work, and using a reasonable resolution means reposition + reload of graphics registers required.

 

The lead-in waveform is also a potential problem in itself. Multicolour mode PMG might be sufficient but then the objects need to be repositioned during the scanline to cover the data generation.

[SeaGtGruff]

If you turn off ANTIC, can you draw anywhere as on the 2600?

 

Can you turn off Antic during the vertical front porch before line 21, then turn it back on after line 21, or does something like that mess with the picture?

[Rybags]

I worked out (with some help) the software exploit of Antic's hardware bug to allow doing PMGs outside the normal 240 scanline area and being able to force extra HSync pulses outside the 240 scanline area a few years back.

 

There's no known way to fool Antic into displaying it's graphics outside the normal display area. The graphics we have available are just the PMGs that GTIA shows as well as being able to change Playfield colour register/s to change the background colour.

 

In the normal scheme of things, changing DMACTL in Antic outside the normal 240 scanline area does nothing special.

Antic keeps track of what scanline is in progress, there seems no way of altering that.

 

So essentially we get to play around with 40 bits of PMG data only for the required scanline/s.

Whether that's enough to fool a TV into thinking captions are in the signal - unknown.

 

Generating the sine wave just for the leadin would be challenge in itself, then a whole bunch of register changes are needed to reposition, resize and reload graphics for the PMGs.

 

Might be doable.

 

Also, I think we need to distinguish between simple Closed Captions (CC) and Teletext. Although there are also differences between analog PAL/NTSC, and it would seem that Teletext uses somewhat higher bitrate and multiple scanlines per field.

 

Closed Captioning is somewhat less capable, but still it would be interesting if it could be made to work.