Debug via closed captioning

[uze6666]

Thanks for the sources! I'll have a look to be sure it will still work with the latest kernel beta. Hopefully you will be able to make an API that peoples can simply import in their project. Such a feature will be invaluable , amongst other things, in debugging video mode 7 (video player) where you can't even output text! If you get some time, a wiki page documenting your hard work would be of great value, and not only for the Uzebox community.

-Uze

[uze6666]

An update, I've tested my 2 other TVs with mixed success. The first, a Toshiba 32" LCD, did not respond at all (tried all CC modes). The second, an older Sony Wega CRT, yielded funky results! Through I suspect it's genlock having issues to sync to the Uzebox non-standard timing. For instance, when the TVs menu (and CC caption) overlays the Uzebox image, it periodically jerks a bit every two seconds or so.

cc2.jpg (28.8 KiB) Viewed 7438 times

-Uze

[HardlyUnique]

Thanks for the kind words, greenpower!

Uze, I agree, an API is a must for this, it's high on my uzebox-TODO list. I hadn't considered a wiki page but I'll get to it if I can .
Thanks for doing some more testing. As for the Toshiba LCD, well that's a little discouraging but pretty much to be expected.

The difficulty with this project was "going blind." I don't have any way to look at the signal I'm sending out and when it doesn't work you don't see anything, so you don't know what the problem is .

I found a piece of software that looked excellent for this called VBI Scope. I had actually already purchased a TV capture card online with the hopes of making this software work but to my surprise and delight, I had captions working before the card arrived . Hopefully, when it gets here it will shed some light on the situation. (If someone else has a capture card, I'd be interested to know if you can get VBI Scope to work).

Meanwhile, I might play with the RGB values for 50 IRE and see if I can find out what's "nominal." That might help.

As for the Wega - that's too funny! That had me chuckling and scratching my head for quite a few minutes.

For instance, when the TVs menu (and CC caption) overlays the Uzebox image, it periodically jerks a bit every two seconds or so.

Just to be clear, this happens with other uzebox titles and the TV's menu, not just my test app?

You think it's the 262 lines vs 262.5? That would make sense. Because it can't sync properly, the poor thing can't distinguish between odd and even fields. My code doesn't either, so it picks up on the extraneous line 21 data that's being mirrored on the even field. That can be fixed...

[D3thAdd3r]

Very cool must have missed this thread before. If it doesn't take much resources and becomes easy to encode messages, Id definitely use this. Could be used for a lot of things I bet, nice work.

[uze6666]

Just to be clear, this happens with other uzebox titles and the TV's menu, not just my test app?

That's right, it's not your test app, does it will all games.

You think it's the 262 lines vs 262.5? That would make sense. Because it can't sync properly, the poor thing can't distinguish between odd and even fields. My code doesn't either, so it picks up on the extraneous line 21 data that's being mirrored on the even field. That can be fixed...

So normally the text should be sent only on line 21 of one of the two fields? That would explain the doubled sequence of characters on the Wega. I have a scope, so I could help determine exact timing if required.

-Uze

[HardlyUnique]

So normally the text should be sent only on line 21 of one of the two fields?

Correct. CC channels 1 and 2 are output on line 21. Channels 3 and 4 are output on line 284.

This might be a dumb question: can your scope show just the data for line 21? If I could see that, it would be most helpful!

p.s. Here's some preliminary files for the kernel beta 5. I found a bug with the way I was trying to send a sync pulse but Beta 5 allowed me to fix it by removing the buggy code completely . Disregard all TCNT1= comments; they need updating.

[uze6666]

This might be a dumb question: can your scope show just the data for line 21? If I could see that, it would be most helpful!

It sure can!

[HardlyUnique]

Okay Uze, any time you can get me a line 21 scan of my uzebox code... . Also, if you can scan a CC-enabled DVD, that would be perfect! If you do, I'll add timing info and post it to Wikipedia. They're missing waveform information.

...Here's my latest WIP on the Closed-Captioning API for Uzebox. Compare the old:

Code: Select all

// roll-up captions, 2 rows
		/*	caption_bytes[0]=148;
			caption_bytes[1]=37;
			WaitVsync(2); // send the ctrl code twice, (on odd frames)
			// channel 1, no underline, white text, row 15
			caption_bytes[0]=148;
			caption_bytes[1]=224;
			WaitVsync(2); // send the ctrl code twice, (on odd frames)
			caption_bytes[0]=200;	// 'H'
			caption_bytes[1]=0xe5;	// 'e'
			WaitVsync(1);
			caption_bytes[0]=0xec;	// 'l'
			caption_bytes[1]=0xec;	// 'l'
			WaitVsync(1);
			caption_bytes[0]=0xef;	// 'o'
			caption_bytes[1]=0x2c;	// ','
			WaitVsync(1);
			caption_bytes[0]=0x20;	// ' '
			caption_bytes[1]=0x57;	// 'W'
			WaitVsync(1);
			caption_bytes[0]=0xef;	// 'o'
			caption_bytes[1]=0xf2;	// 'r'
			WaitVsync(1);
			caption_bytes[0]=0xec;	// 'l'
			caption_bytes[1]=0x64;	// 'd'
			WaitVsync(1);
			caption_bytes[0]=0xA1;	// '!'
			caption_bytes[1]=0xA1;	// '!'
			WaitVsync(1);

			//caption_bytes[0]=CNUL;	// NULL
			//caption_bytes[1]=CNUL;	// NULL

with the new:

Code: Select all

PrintCaption( PSTR("Hello, World!!"),0 );

p.s. PrintCaption returns immediately if there are no captions already waiting to be sent .
Now uses conditional compilation; checks if CAPTION == 1

Of course, I had a little more fun that just "Hello, World" once I had it working, please check out the latest demo .

Also, Uze, the demo has functionality that may fix your Wega issues and demonstrates what I said in the other thread about curr_field having a different meaning depending on how the SD launcher launches the game. Don't bother trying it with the Toshiba, though, I haven't changed any timings or IRE levels yet.

D3thAdd3r, thanks for the encouragement! To get back to you, it looks like it won't take many resources at all. Last I checked, enabling the CAPTION code and calling each API function at least once adds about 1.1k of Flash, <2 lines of CPU every two lines, and ~10 bytes of RAM.

The flash is the worst, IMHO but there's LOTS that can be done to optimize my code! You probably won't need every last API function, either. Once it's optimized, I'd expect that to shrink to the 256-byte range for a typical usage. What this means is that Uze's latest kernel upgrade should free more than enough resources for captioning .

Coming soon: beta-6 port, Caption code in it's own files, functions to print numbers...

[uze6666]

Woa, awesome demo, we're in the major league now! I think it's ready to spread the news with a youtube video, post on Hack-a-day, Uzebox news and all. Anther first for the thousands year old console!

Much improved API and the compile switch was indeed required. A couple comments/ideas:

• I think you may well use a loop for the bits ouput no? That would reduce flash size for sure.
• To avoid blocking, why not have a small "stack" to allow queuing many messages in the background? Only the pointers to the strings would need to be put on the queue.
• Define and use special characters in the strings themselves similar to \n: like \i to switch to italics, \c0x34 for colors, etc. Another could be used for vsync delays.

I will try to get a scan, but that will go after the holidays, too busy right now. Also I will have to find a way to trigger the capture on a specific frame.

In any case, great work! Happy holidays and a happy new year!

-Uze

[HardlyUnique]

Woa, awesome demo, we're in the major league now! I think it's ready to spread the news with a youtube video, post on Hack-a-day, Uzebox news and all. Anther first for the thousands year old console!

Wow, thanks! I wanted to wait until it was working properly on every TV but really, I'm not the best person for making snazzy demo videos, anyway.

I know someone who is, though! Have fun!

Much improved API and the compile switch was indeed required. A couple comments/ideas:

• I think you may well use a loop for the bits ouput no? That would reduce flash size for sure.

Oh yeah, totally! It's just BEGGING to go in a double-nested loop; I just found it easier to develop and pay attention to the timings with the loop unrolled like that. I like to make things work 1st with a straightforward approach then optimize later.

• To avoid blocking, why not have a small "stack" to allow queuing many messages in the background? Only the pointers to the strings would need to be put on the queue.

I like that idea! To be clear, the current behavior really WAS meant to be a feature, not a bug .
I was mostly trying to save RAM with the current implementation. However, we're just storing pointers so a stack, or ring buffer would be negligible! I bet the size could even be configurable at compile time.

[*]Define and use special characters in the strings themselves similar to \n: like \i to switch to italics, \c0x34 for colors, etc. Another could be used for vsync delays.[/list]

That's another good idea! One I'd considered but didn't yet know how to do (define custom escape sequences) (plus I was lazy and excited to get a demo out ).
After a quick search, it looks like we'd have to use a different escape sequence like ~i instead of \i, but that's not a huge deal - these are already things that won't fit in one byte. I'll research it more later. Putting the delays in this way would also be a must for the above to work correctly.

I will try to get a scan, but that will go after the holidays, too busy right now. Also I will have to find a way to trigger the capture on a specific frame.

Cool, whenever you get a chance. FWIW, captioning requires an active data stream be sent out at all times, even if it's just NUL bytes. Having both fields enabled on my demo *should* make it so that either field looks the same for NUL's...

In any case, great work! Happy holidays and a happy new year!

Thanks! Right back at ya!