NTSC 8bpp Greyscale (256 levels)

Tubular · 2013-03-14 17:14

Here's a first attempt at a hub ram byte-per-pixel greyscale driver for NTSC. There are 255 grey levels in NTSC, much better than the 6 or so we had on the P1!

The 256*192 screen buffer in hub ram takes 48kB (DE2-115),
edit: For 256*96 DE0 version scroll down to post 30 below

Big thanks for the texture demo yesterday, I was otherwise stuck on a multi threading approach. The "rendering" routine that expands the byte into 2:8:8:8 sRGB doesn't have any spare cycles at 60MHz on Altera, but it will when we get the real silicon soon

Ariba · 2013-03-14 19:56

Hello Tubular

Have you seen the LUMA8 Video-Mode ($B)? With this mode the greyscale rendering is done in hardware!
You can even choose various colors which are luma scaled by a byte value.
I had to try it out, and my code gives the same result as yours just with a little extra and plenty of spare cycles (I think you even can do a second thread).

Andy

BTW: Just change the mode from $B to $C or $A and you have color pixels instead of greyscale.
Mode $C gives RGB 3:3:2 format, and $A a color/intensity format wirth 3:5 bits per pixel.

Tubular · 2013-03-14 20:32

Hey Andy,

Thanks for that. I like your way better! Looking at my notes I had accidently discounted mode B for not having as many grey levels, but I see now that is not the case, and mode B also has 8bits. I started with mode A, then tried mode 4, then went to F for maximum flexibility.

Earlier I was able to run a second thread as long as it was a lower priority eg SETTASK = %%0030, and it didn't affect the ntsc much other than the occasional very slight jump. I'll get back to trying that shortly when trying to simultaneously read an adc.

cheers
Lachlan

Cluso99 · 2013-03-14 22:40

These modes are fantastic. Just having a quick look at the various code posted shows huge savings with the new instructions such as REP, use of PTR++, etc.

cgracey · 2013-03-14 22:58

The luma modes should be really useful for displaying 3D measurements, with Z represented by pixel brightness. And because you can switch modes on every WAITVID, you could do a pane of memory-efficient luma display within a context of other graphics and text.

Tubular · 2013-03-15 03:52

cgracey wrote: »

The luma modes should be really useful for displaying 3D measurements, with Z represented by pixel brightness. And because you can switch modes on every WAITVID, you could do a pane of memory-efficient luma display within a context of other graphics and text.

Yes, what incredible flexibility. I like how easy it is to do the borders/porches and sync timing too.

We have to make sure this kind of flexibility is explicitly stated in the documentation, as its not obvious at first glance, and is a very useful and memory efficient feature.

Bill Henning · 2013-03-15 07:03

I really, really like the flexibility of the video subsystem.

Right now, I am playing with the "true color per pixel" modes, as I've been wanting high color depth for a while.

Nice work on the greyscale drivers!

Sapieha · 2013-03-15 15:33

Hi Tubular.

That look Yours Greyscale on my PAL TV monitor.

Don't have any NTSC one But 2 that ones as on picture.

Tubular wrote: »

Here's a first attempt at a hub ram byte-per-pixel greyscale driver for NTSC. There are 255 grey levels in NTSC, much better than the 6 or so we had on the P1!

The 256*192 screen buffer in hub ram takes 48kB (DE2-115), or 256*112 takes 28kB (DE0).

Big thanks for the texture demo yesterday, I was otherwise stuck on a multi threading approach. The "rendering" routine that expands the byte into 2:8:8:8 sRGB doesn't have any spare cycles at 60MHz on Altera, but it will when we get the real silicon soon

Tubular · 2013-03-15 15:36

Bill Henning wrote: »

I really, really like the flexibility of the video subsystem.

Right now, I am playing with the "true color per pixel" modes, as I've been wanting high color depth for a while.

Nice work on the greyscale drivers!

Thanks Bill.

Its the weekend here and I left the DE2-115 at work, and I now realize the error of my ways. I might take a trip to fetch it and have a look at your nice work too.

Tubular · 2013-03-15 15:42

Sapieha wrote: »

Hi Tubular.

That look Yours Greyscale on my PAL TV monitor.

Don't have any NTSC one But 2 that ones as on picture.

PAL shouldn't be hard to get going. The problem I have is that all my monitors also seem to display NTSC as well as PAL, so its hard to know whether you've achieved a pure PAL result.

Sapieha · 2013-03-15 15:48

Hi Tubular.

I know that -- It is why I asked Chip for values that I can start with and what ones it is ?

Tubular wrote: »

PAL shouldn't be hard to get going. The problem I have is that all my monitors also seem to display NTSC as well as PAL, so its hard to know whether you've achieved a pure PAL result.

Tubular · 2013-03-15 15:56

Sapieha,

I just realized I do have a bit of equipment at work that would let me check the pure PAL video... will have a look at it early next week for you if nobody beats me to it. The equipment is fussy about timing so probably a good test.

Sapieha · 2013-03-15 16:01

Hi Tubular.

Thanks

One more picture from Chip's texture driver._______________ texture_NTSC_256x192.spin

Tubular wrote: »

Sapieha,

I just realized I do have a bit of equipment at work that would let me check the pure PAL video... will have a look at it early next week for you if nobody beats me to it. The equipment is fussy about timing so probably a good test.

Sapieha · 2013-03-15 17:56

Hi Tubular.

Good site with info on NTSC/PAL.

http://www.videointerchange.com/pal_secam_conversions.htm

Sapieha · 2013-03-15 19:08

Hi.

For anyone that will/can help. I post differences on both types of signals NTSC/PAL

NTSC.

'Line Frequency - 15.734 kHz
'Scanning Lines - 525
'Field Frequency - 60 Hz
'Color Signal Modulation System: Suppressed Quadrature Modulation System
'Color Signal Frequency - 3.579545 MHz (also known as the color burst freq.)
'Burst Signal Phase settled
'Video Bandwidth - 4.2 MHz
'Sound Carrier - 4.5 MHz

PAL. [COLOR=#008080]Sweden [B]PAL-D[/B][/COLOR]

'Line Frequency  - [B][COLOR=#008080]15.625 kHz[/COLOR] [/B]    (PAL-M is 15.750)
'Scanning Lines  - [COLOR=#008080][B]625            [/B][/COLOR](PAL-M is 525)
'Field Frequency - [COLOR=#008080][B]50 Hz[/B][/COLOR]          (PAL-M is 60 Hz)
'Color Signal Modulation System: Suppressed Quadrature Modulation System
'Color Signal Frequency - 4.433618.75 MHz
'Burst Signal Inversion by 1H
'Video bandwidth - [COLOR=#008080][B]PAL-D: 6.0 MHz[/B][/COLOR]; B, G, H: 5.0; I: 5.5; N, M: 4.2
'Sound Carrier   - PAL-B, G, H: 5.5 MHz; I: 6.0; [COLOR=#008080][B]D: 6.6;[/B][/COLOR] N, M: 4.5

Ariba · 2013-03-15 20:37

I tried to make a PAL version of the simple_NTSC_256x192 code, but it does not really work yet.
I have changed all the timings and the Y-I-Q coefficients (according the values in Prop-Docs), but I don't get the right colors (or even no colors on another PAL TV).
What I don't know is how and when I have to make the Phase Flip of the burst.

Here is a draft of what I have done so far, perhaps someone with more knowledge about PAL can add the missing pieces.

Andy

cgracey · 2013-03-15 20:49

Ariba wrote: »

I tried to make a PAL version of the simple_NTSC_256x192 code, but it does not really work yet.
I have changed all the timings and the Y-I-Q coefficients (according the values in Prop-Docs), but I don't get the right colors (or even no colors on another PAL TV).
What I don't know is how and when I have to make the Phase Flip of the burst.

Here is a draft of what I have done so far, perhaps someone with more knowledge about PAL can add the missing pieces.

Andy

PAL is a real pain! I would do it here, but I don't have a PAL TV, anymore. You need to do the phase flipping via VID's configuration bit 0. It's more than just a matter of timing values.

Cluso99 · 2013-03-16 01:55

I don't have any sets that will do only PAL. It would have to be a quite old CRT TV.

The advantage of PAL is/was that you get more lines on the older TVs. I cannot confirm the saying "Never The Same Color". Just wondering if PAL is important anymore???

Sapieha · 2013-03-16 04:01

Hi Ariba.

V-H Frequency is correct now only some moire on picture - But still not color.

Thanks

Ariba wrote: »

I tried to make a PAL version of the simple_NTSC_256x192 code, but it does not really work yet.
I have changed all the timings and the Y-I-Q coefficients (according the values in Prop-Docs), but I don't get the right colors (or even no colors on another PAL TV).
What I don't know is how and when I have to make the Phase Flip of the burst.

Here is a draft of what I have done so far, perhaps someone with more knowledge about PAL can add the missing pieces.

Andy

nutson · 2013-03-16 04:48

It is not a matter of line and frame frequency. In a PAL signal the colorburst reference is rotated 180 degrees in the even lines compared to the odd lines. By averaging these signals a more robust color reference signal is obtained that makes PAL insensitive to many types of signal degradation. A PAL TV cannot display color receiving an NTSC signal

Sapieha · 2013-03-16 05:03

Hi nutson.

'The PAL color burst changes phase 270 degrees from frame to frame so 8 fields are required to repeat
' the orginal SCH phase relationship, plus there is an additional 1/625 of a subcarrier cycle shift for each line
' in the frame. Consequently, the PAL color burst creates an envelope that is completely filled with overlapping
' sine waves which gives the impression that the color burst has jitter.

' PAL uses a frequency of exactly 4.43361875 MHz, with its phase alternating between 135° and 225° from line to line

nutson wrote: »

It is not a matter of line and frame frequency. In a PAL signal the colorburst reference is rotated 180 degrees in the even lines compared to the odd lines. By
averaging these signals a more robust color reference signal is obtained that makes PAL insensitive to many types of signal degradation. A PAL TV cannot display color receiving an NTSC signal

cgracey · 2013-03-16 09:02

Cluso99 wrote: »

I don't have any sets that will do only PAL. It would have to be a quite old CRT TV.

The advantage of PAL is/was that you get more lines on the older TVs. I cannot confirm the saying "Never The Same Color". Just wondering if PAL is important anymore???

It is said that PAL stood for "Pay A Lot", as the European TV's were more expensive than the American ones.

My favorite was the French SECAM: "Something Essentially Contrary to the American Method".

potatohead · 2013-03-16 09:18

LOL

Those are great, particularly the SECAM one.

The problem with PAL on P1 came down to jitter. PAL needs that fundamental frequency to be rock solid stable, or the color information ends up a mess! We were never able to really get a solid signal on P1 due to jitter. The driver Chip wrote was the best one, and it required some fiddling on each prop setup to compensate for minor variations in frequency we would ignore otherwise...

Do PAL sets have component video inputs these days? That might be a great alternative. It's easy to get the frame acceptable. Getting color working rock solid is where the jitter doesn't play out well. I suspect a PAL driver on P2 will suffer some of the same color issues at our current low 60Mhz clock. Maybe the much higher P2 clock will resolve this.

The only PAL testing device I have is a PC capture card that will display PAL, and variations of it. I don't think it was very good, but then again I don't have a real PAL display to compare it to, nor a PAL source for reference... I did find that every single one of the P1 boards I used in an attempt to get decent PAL output varied!

Oh, one other PAL related thing: I've read that the "tint" control NTSC users are familiar with isn't present on many PAL devices due to the very tight color frequency tolerance. Is that true? If so, that speaks to the precision problem right there.

nutson · 2013-03-16 10:48

Correct, the color carrier frequency 4.43361875 MHz needs to be quite precise for the receiver to work. But it is the averaging of in phase and 180 degree fase shifted signals that obsoletes the need of a user "color compensation"'.

In the Netherlands the significance of PAL is rapidly diminishing. There are no more aerial transmissions (replaced by DVBT), and on the cable the number of analog PAL channels is steadily going down in favor of digital transmission (the bandwith of one analog channel is good for 4 didgital channels).

All modern TV's sold here have analog PAL input, as well as HDMI, VGA, component and SCART (basically a baseband RGB signal)

Rayman · 2013-03-16 15:45

I'm going to try something with this driver on my DE0...

The RamPage2 board with dual SQI flash and dual SQI SRAM can fairly easily plug into Chip's DE0 board:

I think this will give me fairly fast access to a byte on P0..P7.
Haven't figured out the timing, but I think this should be good for showing a grayscale photo.
Think that could work?

Maybe later I could try PropGCC in XMM mode...

David Betz · 2013-03-16 15:49

Rayman wrote: »

I'm going to try something with this driver on my DE0...

The RamPage2 board with dual SQI flash and dual SQI SRAM can fairly easily plug into Chip's DE0 board:

I think this will give me fairly fast access to a byte on P0..P7.
Haven't figured out the timing, but I think this should be good for showing a grayscale photo.
Think that could work?

Maybe later I could try PropGCC in XMM mode...

Well, it will have to be a lot later for testing XMM mode on P2. There isn't an XMM kernel for P2 yet. It's on my list right after I update propeller-load to be able to write to the boot flash so we can load programs on reset rather than having to always download them over the serial link.

Rayman · 2013-03-17 08:09

I think my idea for RP2 isn't going to work... I was thinking that the pins on the 40-pin header labelled "PINS" were free.
But, I think they are actually used for the video DACs... Well, maybe I could use DAC3 though...

Martin Hodge · 2013-03-17 12:01

This is what I see on my Panasonic NTSC production monitor with a DE0. (linestot set to 112)

Sapieha · 2013-03-17 12:04

Hi Martin.

Correct same on my monitor

Martin Hodge wrote: »

This is what I see on my Panasonic NTSC production monitor with a DE0. (linestot set to 112)

Tubular · 2013-03-17 13:07

Sorry, I didn't actually test it on a DE0 at the time.

Here's a fixed up version that has been tested on a DE0 successfully. I've just repeated every scan line twice (halves the hub ram buffer to 24kB) but used an offset of 1 pixel so the diagonal is still as sharp as you'd get with 256x192 buffer if you had the full ram, if that makes sense?

Sapieha · 2013-03-17 13:12

Hi Tubular.

It function now on my one.

Tubular wrote: »

Sorry, I didn't actually test it on a DE0 at the time.

Here's a fixed up version that has been tested on a DE0 successfully. I've just repeated every scan line twice (halves the hub ram buffer to 24kB) but used an offset of 1 pixel so the diagonal is still as sharp as you'd get with 256x192 buffer if you had the full ram, if that makes sense?

NTSC 8bpp Greyscale (256 levels)

Comments