Would a design approach like this be possible using one of your Flashpoint SQI designs on a PropBOE breadboard? Seems like this video circuitry is built into your display PCBs and not all that portable to a PropBOE without a new breadboard.
In case it helps I've put one of Rayman's FlashPoint SQI modules onto a PropBOE and have it working with PropGCC.
In case it helps I've put one of Rayman's FlashPoint SQI modules onto a PropBOE and have it working with PropGCC.
Yes, it does. I'll order one of these from Rayman tomorrow so I can run your code, David. With a few examples I'll be able to take off on my own at some point.
I think the picture is reasonable. Was it rendered to the 64 color palette of the Prop VGA, or just 64 colors?
@Rayman: Yep. I missed you doing that. IMHO, using that code with tiles would make a lot of slides possible.
I agree, Doug. The picture seems perfectly reasonable and about what I expected. If it could be dropped into a tile and text could be placed above (and maybe below) I'd have a framework upon which to build a little show. We'll see what Rayman comes up with. I have a feeling he's working on an example of some kind.
Sounds like we have a plan then... That picture should be in the 6-bit VGA palette. But, it's been a very long time since I've used the 6-bit photo tool, I'll need to check.
Also, I have some dithering code I should probably add in too. That might make it better.
Wish I knew how to get all three color cogs perfectly sync'd... Maybe I'll peek at kuroneko's latest drivers and see if I can learn something...
I'll see what I can come up with for Ken.
I think each slide will be made up of a number of pictures that will be loaded from SD into some kind of heap.
Hey, we can call it "PropPoint". Maybe add in some transitions, sound effects, movies...
Spent a little time looking at the PropBOE schematic last night trying to figure out which pins were used for VGA...
Took me a while, but I finally figured out that you need to run jumper wires from the P0..P15 header to the VGA header,
so you can hook it up a couple different ways. I suppose this makes it more flexible.
Don't know if it's just me but if I was demonstrating a prop, I would stick with the things that it excels at and leave the presentation stuff to Prezi:
You know, there is another tool we might find useful. A loooong time ago, Cardboard Guru made a simple presentation program. I'm struggling to recall the title, but he did it shortly after Donkey Kong. It did text, animations, and such... Was for TV, but that's not a big deal to map over to VGA. I'll search. Maybe somebody can recall it.
Ken
Back in *the days when I was working in the video industry, the speed of microprocessors was not fast enough to actually generate video. Instead, we would synchronize to the incoming video and use the micro as an insert keyer. The keyer would cut out a portion of the incoming signal and insert its own graphical information.
Maybe trying to generate the actual video and the graphical images without added ram, is forcing the prop to the point where the images would be greatly compromised on a projected image. *If the propeller were acting as a video keyer and a presentation controller, it would be utilizing it's strengths without compromising the overall quality of the presentation. *OBC's animated graphics keyed over a photo quality background would be truly impressive.
*If the propeller controls *the video generation device, Mac, remotely through its USB port and provides the keying of graphical signals into the projected image, would that not provide a really impressive demo? A keyboard could be added to the propeller to provide "real time" input such as an audience question or selection of another set of graphical images from an SD card or even sending a command back to the primary video generator to select a different set of slides. In this manner, the propeller remains the star of the show, and the computer is relegated to the role of slide projector.
These are just a few random thoughts that occurred to me while reading all of the above great thoughts toward solving your problem.*
David, have you posted the PropGCC code for Flashpoint on PropBOE?
I'd like to try that out...
The code is in Google Code and probably also in Steve's recent release. It's a cache driver called 'sqi_flash_cache.spin" in the propgcc/loader/spin directory. It isn't specifically for the FlashPoint module. It should work with any QuadSPI chip or module. You configure it by setting pin numbers in the board configuration file. I can provide an example but it depends on how you hook up the module of course.
Did I mention that Dithering helps? I'm sure I did...
Also - play to the prop's strengths. Cartoons work better than real life as the colors are cleaner. And no reason the slide can't be moving.
That is with Kye's 160x120 VGA driver. (The white line moving up the screen is the camera and vga display synching. It is not there in real life). I never got sound working though and the inspiration for that was a Rayman video where he did have sound. *Kudos* So - combine audio, moving pictures, dithering and I think all the building blocks are there for a pretty impressive demo.
I think much can be accomplished if we dispense with the notion that the images have to be stored in any known file format. To this end, I've been playing with Ken's 640x480 image to see if a reasonable approximation that fits into RAM could be had, while maintaining the 640x480 pixel count. My plan of attack is to confine each line in the image to a four-color (out of the 64 available) palette, so that 16 pixels can be stored in each long. The palette for each line is selected by picking the four most-used colors out of the 64 that most closely match the RGB values from the original image. Then, each pixel in the line is assigned to the closest color of those four. After that takes place, an array of "deficits" for the line is created, which is the desired RGB color for each pixel, minus the assigned RGB value, divided by two. In the next line, the desired RGB value of each pixel will then be the RGB value from the original image, plus the corresponding deficit from the previous line. This results in a linear dithering of sorts.
In this manner, a 900K RGB image can be reduced to 76_800 bytes. This is still too big to fit the Prop's RAM, of course. But I suspect that many presentation-worthy images could be reduced to fit by using run-length encoding (RLE) in each line. That way one or two cogs could be assigned to unpack lines, while another is displaying them.
Anyway, this is what I've got so far. Here's Ken's original image:
Here's a rendering of the converted image (created with a Perl script), which could be packed into 76.2 kB (plus 4 bytes in each line for the line palette), without RLE:
I haven't yet had a chance to see how much RLE will reduce this file, but it has enough white space that I'm guessing that it might fit the Prop.
One potential issue is that the PropBOE continues Parallax's tradition of using the wrong resistors for the VGA DAC. As I explained awhile back in this thread the 470/240 combo produces a 1V P-P RGB output, whereas the VGA spec calls for 0.7V P-P. The result is a somewhat washed-out color rendering, which effectively reduces the palette from 64 colors to 48. Here's the palette that could be obtained with the correct resistors:
Here's what's available with the current resistors:
What about a different approach - Spinneret and HTML? HTML is all about presentation. Mix in a little JavaScript for cool interactive pages.
The browser takes care of rendering images. Presentations are scalable since they live on an SD Card. The setup would require a laptop and a patch cable.
What if you ran the VGA driver on 2 COGs and had 2 R2R ladders comprised of 4 different values, one COG would handle one gamut and the other COG would handle the other gamut, when combined together on the same VGA lines, you could anywhere from 8x8x8 to 16x16x16 color palette.
I'm sure the resistor values could be selected which would provide a nicely linear approach where 1 COG takes the low half and 1 takes the high half, or the data is pre-processed to effectively combine into 4 bits per color instead of 2+2.
The problem with adding to the palette depth is that the image size increases again. Plus, the objective here is to wring as much performance as possible from the standard hardware, not to make structural changes to it.
Did you change the analysis/plotting code? Perhaps it might work better if the source image was divided into two 320x480 halves, rendered using the independent palettes, and then recombined. But that is probably what you are doing already...
You can do it 2 ways, a 512 entry palette, or a 4096 entry palette. I don't think your script is generating the palette accordingly. The storage is doubled, since it's 12 bits per pixel instead of 6 bpp, but that's understood.
I've got a design on the board for a 512KB/16MB RAM/FLASH memory board that has an 8bit wide data bus.
Perhaps it might work better if the source image was divided into two 320x480 halves, rendered using the independent palettes, and then recombined. But that is probably what you are doing already...
You can do it 2 ways, a 512 entry palette, or a 4096 entry palette. I don't think your script is generating the palette accordingly.
No, nor is that my intent. The stated objective of this thread is to work as much as possible with the Prop's native 6-bit VGA palette, not to invent new hardware. In that light, my objective is to create a way to show 640x480-pixel images of reasonable quality that will fit within the Prop's hub RAM. It's all well and good to try to improve quality with hardware modifications and additions, as several forumistas have already demonstrated. But that's a subject for a different thread.
One potential issue is that the PropBOE continues Parallax's tradition of using the wrong resistors for the VGA DAC. As I explained awhile back in this thread the 470/240 combo produces a 1V P-P RGB output, whereas the VGA spec calls for 0.7V P-P. The result is a somewhat washed-out color rendering, which effectively reduces the palette from 64 colors to 48. Here's the palette that could be obtained with the correct resistors:
Here's what's available with the current resistors:
-Phil
If you "write off" the brightest level as being hardly any brighter than the next brighter level (just the 240 resistor driven), you effectively have 3x3x3=27 distinct colors, which can be represented in 5 bits, or 4.76 bits if you could be bothered packing more densely.
Then for a 4:3 aspect image, the prop has enough memory (just) to hold a 270x202x27 color image
... you effectively have 3x3x3=27 distinct colors ...
You're right, of course. I said 48, which was completely off-base. I'm glad you can see an advantage in having fewer than half of the colors that would be available, given the right resistors.
Not all images are amenable to the striping treatment. Designing an image for any process requires consideration of the process's pluses and minuses, as the following two examples demonstrate. Both are graphs taken from Tom's Hardware. The first has text within a horizontal color fountain. This doesn't work because the multiple fountain shades almost always win against the text, and the text gets obliterated. Also the color legend would work better if stacked vertically, so the individual colors show up better.
Original:
Treated:
Text within a vertical fountain works fine, though, since the number of colors in each line is limited to start with.
Thank you for everybody's work here. Looks like Phil is taking the resource-limited approach of running some default hardware. It's looking possible, but limited. microSD can be included as "default hardware".
Phil, if you decide to take an alternative approach where we have a graphic occupying a portion of the VGA field and the rest being used for text that could also be acceptable as well.
Rayman has a PropBOE now and he's in the mix too.
If somebody is able to make a driver that I can use it'll run my presentation at the "Sketching in Hardware" conference in July, and probably for every other presentation I do. I'd love to show up without a computer and have the Propeller run the show.
Ken, can you post up some variety of images and presentation slides? I assume you've got graphs and such, along with text. Would be interesting to see those.
Ken, can you post up some variety of images and presentation slides? I assume you've got graphs and such, along with text. Would be interesting to see those.
Yeah, of course. What resolution would be helpful, Doug?
Comments
@Rayman: Yep. I missed you doing that. IMHO, using that code with tiles would make a lot of slides possible.
Yes, it does. I'll order one of these from Rayman tomorrow so I can run your code, David. With a few examples I'll be able to take off on my own at some point.
I agree, Doug. The picture seems perfectly reasonable and about what I expected. If it could be dropped into a tile and text could be placed above (and maybe below) I'd have a framework upon which to build a little show. We'll see what Rayman comes up with. I have a feeling he's working on an example of some kind.
Also, I have some dithering code I should probably add in too. That might make it better.
Wish I knew how to get all three color cogs perfectly sync'd... Maybe I'll peek at kuroneko's latest drivers and see if I can learn something...
I'll see what I can come up with for Ken.
I think each slide will be made up of a number of pictures that will be loaded from SD into some kind of heap.
Hey, we can call it "PropPoint". Maybe add in some transitions, sound effects, movies...
Spent a little time looking at the PropBOE schematic last night trying to figure out which pins were used for VGA...
Took me a while, but I finally figured out that you need to run jumper wires from the P0..P15 header to the VGA header,
so you can hook it up a couple different ways. I suppose this makes it more flexible.
www.prezi.com
Cheers
Richard
Back in *the days when I was working in the video industry, the speed of microprocessors was not fast enough to actually generate video. Instead, we would synchronize to the incoming video and use the micro as an insert keyer. The keyer would cut out a portion of the incoming signal and insert its own graphical information.
Maybe trying to generate the actual video and the graphical images without added ram, is forcing the prop to the point where the images would be greatly compromised on a projected image. *If the propeller were acting as a video keyer and a presentation controller, it would be utilizing it's strengths without compromising the overall quality of the presentation. *OBC's animated graphics keyed over a photo quality background would be truly impressive.
*If the propeller controls *the video generation device, Mac, remotely through its USB port and provides the keying of graphical signals into the projected image, would that not provide a really impressive demo? A keyboard could be added to the propeller to provide "real time" input such as an audience question or selection of another set of graphical images from an SD card or even sending a command back to the primary video generator to select a different set of slides. In this manner, the propeller remains the star of the show, and the computer is relegated to the role of slide projector.
These are just a few random thoughts that occurred to me while reading all of the above great thoughts toward solving your problem.*
Jim
I'd like to try that out...
Also - play to the prop's strengths. Cartoons work better than real life as the colors are cleaner. And no reason the slide can't be moving.
That is with Kye's 160x120 VGA driver. (The white line moving up the screen is the camera and vga display synching. It is not there in real life). I never got sound working though and the inspiration for that was a Rayman video where he did have sound. *Kudos* So - combine audio, moving pictures, dithering and I think all the building blocks are there for a pretty impressive demo.
In this manner, a 900K RGB image can be reduced to 76_800 bytes. This is still too big to fit the Prop's RAM, of course. But I suspect that many presentation-worthy images could be reduced to fit by using run-length encoding (RLE) in each line. That way one or two cogs could be assigned to unpack lines, while another is displaying them.
Anyway, this is what I've got so far. Here's Ken's original image:
Here's a rendering of the converted image (created with a Perl script), which could be packed into 76.2 kB (plus 4 bytes in each line for the line palette), without RLE:
I haven't yet had a chance to see how much RLE will reduce this file, but it has enough white space that I'm guessing that it might fit the Prop.
One potential issue is that the PropBOE continues Parallax's tradition of using the wrong resistors for the VGA DAC. As I explained awhile back in this thread the 470/240 combo produces a 1V P-P RGB output, whereas the VGA spec calls for 0.7V P-P. The result is a somewhat washed-out color rendering, which effectively reduces the palette from 64 colors to 48. Here's the palette that could be obtained with the correct resistors:
Here's what's available with the current resistors:
-Phil
The browser takes care of rendering images. Presentations are scalable since they live on an SD Card. The setup would require a laptop and a patch cable.
Why don't you give each line two palettes - one each for the left and right sides?
I think that would make it look MUCH better!
I'm sure the resistor values could be selected which would provide a nicely linear approach where 1 COG takes the low half and 1 takes the high half, or the data is pre-processed to effectively combine into 4 bits per color instead of 2+2.
The problem with adding to the palette depth is that the image size increases again. Plus, the objective here is to wring as much performance as possible from the standard hardware, not to make structural changes to it.
-Phil
I tried a version with two palettes per line: left half and right half. First, the full-line version:
Then the split version:
It does show some improvement in the green on the left PCB.
-Phil
Did you change the analysis/plotting code? Perhaps it might work better if the source image was divided into two 320x480 halves, rendered using the independent palettes, and then recombined. But that is probably what you are doing already...
Bill
I've got a design on the board for a 512KB/16MB RAM/FLASH memory board that has an 8bit wide data bus.
-Phil
-Phil
If you "write off" the brightest level as being hardly any brighter than the next brighter level (just the 240 resistor driven), you effectively have 3x3x3=27 distinct colors, which can be represented in 5 bits, or 4.76 bits if you could be bothered packing more densely.
Then for a 4:3 aspect image, the prop has enough memory (just) to hold a 270x202x27 color image
-Phil
Original:
Treated:
Text within a vertical fountain works fine, though, since the number of colors in each line is limited to start with.
Original:
Treated:
-Phil
Phil, if you decide to take an alternative approach where we have a graphic occupying a portion of the VGA field and the rest being used for text that could also be acceptable as well.
Rayman has a PropBOE now and he's in the mix too.
If somebody is able to make a driver that I can use it'll run my presentation at the "Sketching in Hardware" conference in July, and probably for every other presentation I do. I'd love to show up without a computer and have the Propeller run the show.
Ken Gracey
Ken, can you post up some variety of images and presentation slides? I assume you've got graphs and such, along with text. Would be interesting to see those.
Yeah, of course. What resolution would be helpful, Doug?
Thanks,
-Phil
There are various ways we can encode things, and we've a lot of COG's. Just wanting to see the range of stuff you present Ken.
Well, three basic thoughts:
1. There are likely ways of forming the images that are optimal. Need to sort those out.
2. Dynamically drawing things, or the use of tiles / overlays will help to improve slide diversity.
3. I like where Phil is going. 4 colors is rough, but what about 16?