If it isn't a high cost, having this on the COGS makes sense.
And it is really easy compared to the mess I have on my laptop right now. Thanks again Chip.
Having a unified color space is really sweet! Not only should we be able to make assets work across multiple display types, we should be able to pick a few really sweet resolutions and have those work in a consistent way.
@jmg, yes. Agreed. Analog display input is just stupid easy and legacy compatable. Repair, enhance, replace projects may be a good niche for this chip.
I've been flirting with getting my radio license back. Found out I can get my old KA7xxx callsign. Having a display and various signals being possible seems compelling.
Here is an 8bpp 256 x 192 image that I got the Prop2 to display tonight onto an NTSC monitor:
Wow.
This will work equally well on PAL too ?
.. and Component Video ?
I think small composite monitors are going to be around for a long time, as they connect so readily to simple cameras.
As the 'Big Iron' parts move to support HDMI, this will be a quite significant niche for Prop 2 - Vehicles, security and monitoring are all growth areas.
This color space converter does it all. You set 9 multiplier terms for the 3x3 conversion matrix, plus 3 offset levels and it takes care of the whole conversion, on every clock. It also has a modulator for composite baseband video.
I spent so much time working on this in the past to get it just right, and I'm really glad it's not going to waste now. For doing video, this is the best way to go. You can display any bitmap on NTSC, PAL, HDTV, and VGA, plus any other oddball format that may exist.
It seems to take 288 LE's, while using the FPGA's built-in multipliers. So, there are six 9x9 signed multipliers that don't go into that LE count.
Roy, this program is GREAT. Thanks for linking it. I actually use the Smile out of the little paint program in windows. It's simple, and often, I need simple. Other tools, like GIMP, etc... are nice, but messy. Takes a bit to get in, remember, do it, get back out and onto other things.
Nice little UX touches in this one. (He's an Apple type guy, hiding out in MS land, it seems )
I've been using paint.net, too for a while.
Because it allows fonts to be any fractional point size, I can take a picture of an FPGA board, label the pins with a many-line text entry, and then fine-adjust the font size so that the line space becomes exactly what is needed to align the text with header pins in the photo.
It has lots of image-saving options, too, but I didn't see anything that looked simpler than the .bmp option.
As the 'Big Iron' parts move to support HDMI, this will be a quite significant niche for Prop 2 - Vehicles, security and monitoring are all growth areas.
My new car only has one video input and it's NTSC:
It's so nice and easy to use, and I love the fact you can have it wrap the pointer!
I'll start on a tile map 640x480 tomorrow and then post source for people to use.
I'd post a pic, but it's late and I'd have to boot up my other computer that has FTP software to upload the pic to the net, then attach a link here. I'll do it when I post tile map.
In the NTSC safe area, there are 160 cycles of the colorburst. That's kind of the "base" resolution. Many old computers did 128 and offered fairly wide horizontal borders.
At that resolution, pixels are clean and clear, and there is no real need for colorphase shifting or anything. 160x200 is kind of a sweet spot in NTSC.
Each resolution double above that overdrives the color signal. Good displays will use advanced filtering to pick it out and display it reasonably well. Most devices from the late 80's on will do a fair job of this. Modern HDTV sets range from scary good to "meh" depending.
320 pixels horizontal is a 2x overdrive. 640 is a 4X overdrive. With good DAC output, nice sine waves, the TV filtering works very well, and the trade-off is generally very high contrast color regions that differ in their color phase will demonstrate some artifacts and fringing. So will text. The better the signal quality, the better modern sets will do with this.
A full frame of NTSC, overdriven to "broadcast" specs, is 720 pixels horizontally (actually 706, if the porches are respected). Just size the porches to get 640, 320, 160, etc... A shift in those porches, gives you 128, 256, 512 too. Lots of other combinations are possible, but those are the most common ones. Your average DVD player / game console drives that kind of resolution all the time.
Vertically, 480 scanlines is well into the overscan. Modern HDTV sets will display all of them, or maybe missing one or two. Older sets will display more like 420...
It's all about making sure the pixel clock is synced up with the colorburst, and what size the borders (porches) are. Overdriving it is typically just fine, so long as detail / art direction takes that into account. Limit high color angle changes and most sets display this kind of thing pretty well.
Of course, when it's then output as component, it's pixel perfect.
The beauty of this circuit is we can basically output composite, component, vga @ 640x480 and display the same colors on anything. It's safe to take this resolution, or multiples (large and small) of it, and call it "Propeller Standard" as it's gonna work out on most displays it's needed on. In the case of larger multiples, some pixels just get lost on a composite display, but it all will still look just fine. That's what this circuit did on the last chip. Made for nice prototyping on a capture card, for example.
I was a little slow to see this thread but am very stoked by these developments!! They may be just what the new P2 was missing to make it complete. Throw on some rudimentary smart pins and let's get this chip made!
How do you get 640x480 from PAL or NTSC Composite frequencies ?
As potatohead put it, and very well I may add it's over scanned, two interlaced frames of 640x240 to give a full image of 640x480, the top and bottom couple of lines aren't visible on my TV but it's there, I've done it that way and not 640x400 because I wanted it to be the same resolution as the Component and VGA drivers that will eventually get done, so it can be the same across all display outputs then.
It's now handy having large compile times at work, means whilst the comp is busy compiling the project I can check out the forum used to hate long compile times lol not now though!
There's one other thing that I want to bring back: the pixel mixer.
Having alpha blending and other effects makes things really neat.
This pixel mixing was done by four instructions in Prop2-Hot.
What is the logic-cost of this ?
One thought I've had, is with the advanced phase modulation going in, how well can a P2 decode this ?
Would a PLL mode be needed to chroma carrier lock ?
Is that then enough to line lock too ?
If P2 can manage both ends of this, it opens scope to push NTSC++ or PAL++, and get Component Video resolutions, on a Composite signal.
I don't remember what the cost of the pixel mixer was, but I'll learn soon, again.
About inputting NTSC/PAL... We don't need analog PLL's. Look at the signal output for the NTSC demo. That was all done at 50MHz using NCO's and a simple CORDIC rotator to modulate (I,Q). It turned out really well. Also, I only used single-precision floating-point to do the math in a CON block, so there is a little rolling of the colorburst against the frame timing. Better math would reduce that to ~1/256th, and it makes no visible difference. What we'd need that we don't have now is a fast ADC to grab, say, 8-bit samples on every clock. Then, we need some demodulator logic to convert back to RGB. That's a little too much to attempt, at this point, for Prop2.
Well, it would be nice one could use a low cost video decoder to capture NTSC...
Was just looking at some on Digikey...
Looks like they all output YCbCr422, at least the two 32-pin ones I looked at.
So, maybe it would be nice if P2 could stream that. Or, have a means of turning it into RGB...
Maybe a cog could be fast enough to do the conversion in real time, I don't know...
Comments
These are the output options:
YCbCr422, RGB565 and Bayer raw RGB ,
So Chip has RGB565, so should be good there. This should allow image preview over NTSC...
Don't know if any cameras are YCbCr422 only...
And it is really easy compared to the mess I have on my laptop right now. Thanks again Chip.
Having a unified color space is really sweet! Not only should we be able to make assets work across multiple display types, we should be able to pick a few really sweet resolutions and have those work in a consistent way.
@jmg, yes. Agreed. Analog display input is just stupid easy and legacy compatable. Repair, enhance, replace projects may be a good niche for this chip.
I've been flirting with getting my radio license back. Found out I can get my old KA7xxx callsign. Having a display and various signals being possible seems compelling.
This color space converter does it all. You set 9 multiplier terms for the 3x3 conversion matrix, plus 3 offset levels and it takes care of the whole conversion, on every clock. It also has a modulator for composite baseband video.
I spent so much time working on this in the past to get it just right, and I'm really glad it's not going to waste now. For doing video, this is the best way to go. You can display any bitmap on NTSC, PAL, HDTV, and VGA, plus any other oddball format that may exist.
It seems to take 288 LE's, while using the FPGA's built-in multipliers. So, there are six 9x9 signed multipliers that don't go into that LE count.
I've been using paint.net, too for a while.
Because it allows fonts to be any fractional point size, I can take a picture of an FPGA board, label the pins with a many-line text entry, and then fine-adjust the font size so that the line space becomes exactly what is needed to align the text with header pins in the photo.
It has lots of image-saving options, too, but I didn't see anything that looked simpler than the .bmp option.
Hmm.. That's creeping up - this does not have to be in every COG, if it starts to impact room for Smart Pins and RAM.
There's one other thing that I want to bring back: the pixel mixer.
Having alpha blending and other effects makes things really neat.
This pixel mixing was done by four instructions in Prop2-Hot.
If there were an easy way to add a pixel clock output to the streamer, that could be useful...
Wait a sec, that doesn't make any sense...
Guess I'd need streamer output redirected from DAC to I/O pins and then a pin for pixel clock...
Never mind, that wasn't a well thought out request...
My new car only has one video input and it's NTSC:
One thought I've had, is with the advanced phase modulation going in, how well can a P2 decode this ?
Would a PLL mode be needed to chroma carrier lock ?
Is that then enough to line lock too ?
If P2 can manage both ends of this, it opens scope to push NTSC++ or PAL++, and get Component Video resolutions, on a Composite signal.
I think that would allow 720p graphics using about 1/2 the HUB RAM...
I now have 640x480 running on composite
It's so nice and easy to use, and I love the fact you can have it wrap the pointer!
I'll start on a tile map 640x480 tomorrow and then post source for people to use.
I'd post a pic, but it's late and I'd have to boot up my other computer that has FTP software to upload the pic to the net, then attach a link here. I'll do it when I post tile map.
How do you get 640x480 from PAL or NTSC Composite frequencies ?
At that resolution, pixels are clean and clear, and there is no real need for colorphase shifting or anything. 160x200 is kind of a sweet spot in NTSC.
Each resolution double above that overdrives the color signal. Good displays will use advanced filtering to pick it out and display it reasonably well. Most devices from the late 80's on will do a fair job of this. Modern HDTV sets range from scary good to "meh" depending.
320 pixels horizontal is a 2x overdrive. 640 is a 4X overdrive. With good DAC output, nice sine waves, the TV filtering works very well, and the trade-off is generally very high contrast color regions that differ in their color phase will demonstrate some artifacts and fringing. So will text. The better the signal quality, the better modern sets will do with this.
A full frame of NTSC, overdriven to "broadcast" specs, is 720 pixels horizontally (actually 706, if the porches are respected). Just size the porches to get 640, 320, 160, etc... A shift in those porches, gives you 128, 256, 512 too. Lots of other combinations are possible, but those are the most common ones. Your average DVD player / game console drives that kind of resolution all the time.
Vertically, 480 scanlines is well into the overscan. Modern HDTV sets will display all of them, or maybe missing one or two. Older sets will display more like 420...
It's all about making sure the pixel clock is synced up with the colorburst, and what size the borders (porches) are. Overdriving it is typically just fine, so long as detail / art direction takes that into account. Limit high color angle changes and most sets display this kind of thing pretty well.
Of course, when it's then output as component, it's pixel perfect.
The beauty of this circuit is we can basically output composite, component, vga @ 640x480 and display the same colors on anything. It's safe to take this resolution, or multiples (large and small) of it, and call it "Propeller Standard" as it's gonna work out on most displays it's needed on. In the case of larger multiples, some pixels just get lost on a composite display, but it all will still look just fine. That's what this circuit did on the last chip. Made for nice prototyping on a capture card, for example.
(and I'm tossing the software mess I had brewing to do it much worse than it's being done with this circuit too --was gonna take a couple of cogs)
Looking forward to getting the charmap driver in possibly tonight if I don't have to crunch too late with work that is. ( deadline for Friday. )
lol so true!
I don't remember what the cost of the pixel mixer was, but I'll learn soon, again.
About inputting NTSC/PAL... We don't need analog PLL's. Look at the signal output for the NTSC demo. That was all done at 50MHz using NCO's and a simple CORDIC rotator to modulate (I,Q). It turned out really well. Also, I only used single-precision floating-point to do the math in a CON block, so there is a little rolling of the colorburst against the frame timing. Better math would reduce that to ~1/256th, and it makes no visible difference. What we'd need that we don't have now is a fast ADC to grab, say, 8-bit samples on every clock. Then, we need some demodulator logic to convert back to RGB. That's a little too much to attempt, at this point, for Prop2.
Was just looking at some on Digikey...
Looks like they all output YCbCr422, at least the two 32-pin ones I looked at.
So, maybe it would be nice if P2 could stream that. Or, have a means of turning it into RGB...
Maybe a cog could be fast enough to do the conversion in real time, I don't know...