Debug via closed captioning

[HardlyUnique]

In the process of playing around with the Uzebox and hacking apart / together some custom video modes, I often find myself wanting to get some simple info printed to the screen. Most of what I'm playing with isn't tile-based, so it'd involve a lot of extra work to get text output from within my code.

Even w/ tile-based modes, I'm sure I'm not the only one who's just wanted to get some extra info up without changing what you normally want to display on the screen.

It occurred to me that line 21 closed captions would be perfect for the job. It seems well within the capabilities of the Uzebox and might not require too much extra work. The problem I'm having is finding enough details on line 21 captions to actually implement them.

It looks like the wiki entry on the EIA-608 standard (http://en.wikipedia.org/wiki/EIA-608) gives enough info to know how to assemble control codes but I've not been able to find (or figure) out exactly how they'd be transmitted serially. I've seen mention that the standard requires there be no setup on line 21 and that characters are transmitted redundantly and that there's multiple channels on each line, all of which tells me that I don't know enough about the standard to go anywhere with this idea.

If anyone has any more info or thoughts on the matter, please chime in.

[uze6666]

Now that's a cool idea. It would indeed provide some sort of overlay over whatever video modes is currently used. I am not familiar with this standard but it should not be too hard to implement and it would eat a worst a scanline worth of CPU. Thigh games using all ramtiles and music channels could slowdown a bit, but again that would be only debug code not present in a final release.

An idea I got a while ago was to have some sort of debug console overlay at the top or bottom of the screen. However that eats up precious ram and some flash too. Alternatively, in the mean time, the emulator has some sort of console debugging facility that was added some time ago. It's implemented by sending chars to an unused I/O port. You would have to look at the sources since I never personally used it.

-Uze

[HardlyUnique]

Thanks for the encouragement, as well as sharing such a cool project for me to play with .

This is all starting to come together for me. I think I was making it more complicated than it is.

Somehow, I missed / didn't understand this in the wiki:

It uses a fixed bandwidth of 960 bit/s.

So, that would be roughly 960 bit / 60 frames or 16 bits per frame. That makes sense because the fcc docs mention that data is always sent two bytes at a time . I was thrown off by the fact that there's 2 channels on each frame and apparently a 'text' mode on top of that but it looks like most of it I won't have to worry about.

As I understand it so far, I need to split the active video portion of line 21 into 16 digital segments, presumably with white and black representing one and zero respectively. I think the only thing abnormal about line 21 is that the "setup" or "black level" portion that happens right after hsync doesn't happen; the caption data is split up over the 52.6 us active video portion. So, I think sound can be processed normally and you'd only miss out on the CPU time of one line .
(I'm going off of this: http://www.maxim-ic.com/app-notes/index.mvp/id/734)

I'm hoping that there's a bit of leeway w/ the timing of these 16 segments but I won't know until I try; which I'm now off to do!

[uze6666]

Eh, after your explanation it doesn't seem that complicated. Keep us posted, if it turns out well, we'll include it in the kernel and give it it's own compile switch. That will make a very cool -and unique- feature!

-Uze

[HardlyUnique]

Well, I never would have gotten it on my own .

A series of progressive google searches finally yielded the arcane magic of line 21 data.

The final penultimate phrase: line 21 clock run in.

Here's a good source: http://books.google.com/books?id=BtCOgrpzbz4C&pg=PA349&dq=line+21+clock+run+in&hl=en&ei=XbeDTNiwN8GC8gbT-OXTAQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC8Q6AEwAA

I'll summarize some of the important points:
line 21 has a 7-cycle sinusoidal wave after the color burst called the clock run-in. It's meant to go from 0 to 50 IRE. This is followed by two zero's and a one (the "start bit") followed by the actual data. Zero's are 0 IRE, one's are 50 IRE. (less-than-black and gray, not black and white).

So, now I have a much better picture of how to generate CC from the uzebox. My concerns that still linger:
Exactly "How sinusoidal" must the clock run-in be? Can the avr generate close enough? I'm guessing so, since the format is meant to withstand degradation such as what you'd get on a vcr.

I was initially concerned that there would be no way to indicate in software to be using 0 IRE and not 7.5 IRE. I assumed the AD725 handled this but after searching through the code and looking at some old 'scope photos around here, I'm not sure the uzebox even does a setup or elevates black above 0 IRE. Can anyone shed any light?

That's my main concern, the clock run-in. I've seen reference to the fact that the digital data can typically be -2 +12 IRE so we should be good there but my research seems to imply that the clock run-in is less forgiving.

It may be a "try it and see" scenario but if anyone has a better idea of how (im)possible this is for uzebox, please let me know.

[uze6666]

Interestingly I found a book dedicated to closed captioning, perhaps you already saw it: http://books.google.com/books?id=SdGUcz8QV9EC&lpg=PA96&dq=line%2021%20video&pg=PR9#v=onepage&q=line%2021%20video&f=false.

You can't generate sinusoidal waves out of the Uzebox port, at least not at the required frequency (which is what btw?). That said, square waves will most probably do the trick. I saw it used to generate color bursts in some pure software implementation and it worked fine. After the Uzebox generates the sync pulse the AD725 generates the color burst and right after you are free to output data on the DAC. I guess you would have to output some level of pure white to avoid having the color sub-carrier around. Just have to find what RBG value corresponds to 40 IRE. Regarding the 0 vs. 7.5 IRE I'm pretty sure the AD725 deals with that but we would have to confirm this on a scope.

-Uze

[HardlyUnique]

Sorry I didn't get back to you sooner, Uze, I've been away from the Uzebox for a while...

Since I'm back, I've made some progress! (The frequency is 32H, BTW)

It's a humble beginning to be sure, but it all starts here:

Hello.JPG (266.25 KiB) Viewed 574 times

I have a little ways to go; next up is a function to facilitate printing. It wouldn't be very practical to output text the way I'm doing now, two-bytes at a time each frame, with the parity calculated by hand!

However, I think this definitely proves closed-captioning is possible on the Uzebox!!! Everyone, please try it on your TV and report your findings. It seems to work the best when you wait a few seconds before pressing the button (you can press it again and again, though).

It took a LOT of reading and trial and error. I even came across one website of someone who had made a caption decoder and said specifically that a microcontroller couldn't generate captions .

I will include the source soon in another post, it's based off of the beta 4 upgrade. 3 is the maximum number of attachments for now...

[uze6666]

Congrats, I'm impressed! That's a very nifty trick you've pulled there. I tested it on a TV and it works flawlessly. I'm impatient to see the sources!


-Uze

[HardlyUnique]

Thanks for the encouragement! As promised, here's some sources. Just remember that it's very much a WIP .

If memory serves, the changes are mostly to uzeboxVideoEngineCore.s, and some small additions to defines.h and uzeboxCore.c.

[greenpower]

Wow!
Thats really impressive!
I think it's a nice addition to the uzebox for games. Never give up your work!