NTSC 8bpp Greyscale (256 levels)
Tubular
Posts: 4,702
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
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
1024 x 768 - 40K
Comments
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.
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
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.
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!
That look Yours Greyscale on my PAL TV monitor.
Don't have any NTSC one But 2 that ones as on picture.
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.
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.
I know that -- It is why I asked Chip for values that I can start with and what ones it is ?
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.
Thanks
One more picture from Chip's texture driver._______________ texture_NTSC_256x192.spin
Good site with info on NTSC/PAL.
http://www.videointerchange.com/pal_secam_conversions.htm
For anyone that will/can help. I post differences on both types of signals NTSC/PAL
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.
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???
V-H Frequency is correct now only some moire on picture - But still not color.
Thanks
'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
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".
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.
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)
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.
But, I think they are actually used for the video DACs... Well, maybe I could use DAC3 though...
Correct same on my monitor
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?
It function now on my one.