Re: "There are only two native VGA modes: 2-color and 4-color." Actually, one can do lots of things with the VGA beyond that, and the question about 16 colors had to do with palette optimization. That number of colors might make a difference, and if so, COGS could be doing lookups and other things... Before going that route though, it was worth it to raise the question on image viability, etc...
I see what you mean. Here's an image where each line uses an optimized sub-palette of 16 colors from the 64 available:
That's probably acceptable quality. But there's no way to fit that into 32 kB or less, even with compression. Moreover, there are sure to be blocks of 16 pixels that use more than four of the 16 sub-palette colors, so setting up VSCL for 16 pixels per frame would not work.
Here's another example, virtually identical to the previous one. In this case, each block of 16 pixels has its own optimized palette of four colors out of the 64 possible. This would allow VSCL to be set up for 16 pixels per frame.
Baggers has a RLE compression engine. Not sure if he posted it but, I remember the thread because the title was something like "Can Prop2 do this?"...
Showed a photo of his family...
BTW: I do think showing a photo from 1 or 2 flashpoint modules is possible. The regular VGA demo is set for a 20 MHz dot clock, which is right at the limit of what Flashpoint SQI can do. Regular 640x480 VGA has a 25 MHz dot clock though, so that might now work...
But, I must say that I've been thinking about this stuff for a very long time and the SSD1963 is a much, much better solution (assuming you can afford the extra expense and real estate).
BTW2: Done some thinking today about what to do for Ken... Think I'll try 512x384 resolution bas with a middle section that is 2X expanding in X&Y to blow a 6-bit graphics to large size...
I've been struggling with the compression aspect. There are compression algos that could probably do it, but the fly in the ointment is the decompression, which has to be done by the Prop in real time to keep up with the VGA driver, line-by-line. That rules out most of the commonly-used compression techniques. RLE decompression is probably doable in real time, but I'm beginning to doubt that its compression ratio is high enough to be of any value here.
Each line has to be decompressed in about 30 uS. That's only 600 PASM instructions to decompress 640 pixels.
PNG takes a macroblock (16x16px block), Calculates delta in a zig-zag fashion, then LZ77 compresses it in the same zig-zag pattern. The delta calculation would probably make RLE far more efficient, but the zig-zag pattern would probably make compression more efficient for images, and still be fast enough to be decompressed in real time.
That would mean working on the next 16 lines while the previous 16 lines are decompressing. Do we have room for that?
Rayman, it was a 15bit 256x192 image compressed into 64x48 4x4 4 colour tiles ( pretty much like DXT1 ) you wouldn't get it running higher though, because A, that 256x192 took 24K, and decompression took a good few cogs, so you wouldn't get much higher even if you had more hub-ram.
I all your adventures... Did you ever have a problem with the projector sync'ing up to the VGA output?
Asking because the regular VGA mode is actually a bit non-standard... I'm a little worried about using it because you might have sync issues...
I seen a few posts about people having this problem with monitors. Not sure about projectors though...
I'm thinking that 640x480 or 1024x768 standard modes (or scaled down versions thereof) might be more conservative...
This whole conversation wouldn't be an issue with Prop2 - though I think then the issue would be whether to display bitmaps from the SD card or dynamically generate a presentation on screen.
I all your adventures... Did you ever have a problem with the projector sync'ing up to the VGA output?
Asking because the regular VGA mode is actually a bit non-standard... I'm a little worried about using it because you might have sync issues...
I seen a few posts about people having this problem with monitors. Not sure about projectors though...
I'm thinking that 640x480 or 1024x768 standard modes (or scaled down versions thereof) might be more conservative...
Hey Rayman,
No problems, anywhere I've been. That includes VGA projectors in Europe, Rocklin, Texas, Minnesota, Taiwan, Hong Kong, and one in San Francisco. At all of these places I've connected Propellers to them for low-res VGA examples. I think my demos are using 640x480.
It would probably be best to stay at 640x480 (or 800x600) as you never know if you are going to wind up hooking to an older LCD monitor.
There are still a bunch out there in circulation.
I'm thinking divide-and-conquer now. If you choose the right font(s), you can get by with one bit per pixel for the text. Not all typefaces are monochrome (i.e. 1-bit) safe, but the fonts in the following image are, even at font sizes other than those shown:
"Monochrome safe" means that a font will render nicely without applying anti-aliasing. I noticed that the text in Ken's slides were anti-aliased -- even in other than grayscale tones. This leads to a much bigger file requirement. The above image, by contrast, requires only 15kB and, without the font examples, 9kB, when saved as a PCX file. The PCX file format uses a very primitive RLE scheme which would be easy to decode with the Prop. For an image with 1-bit pixels, though, there are probably even more efficient schemes. BTW, the two colors don't have to be black and white: they can be any two colors in the 64-color palette. Moreover, any monochrome graphic (e.g. schematics, flowcharts, boxes, lines, etc.) could be accommodated in the text area. Precluded, however, would be red headlines and black text on a white background, since that's three colors.
I think that takes care of the text. Small embedded images could be handled in a manner similar to what I've been experimenting with. They would require window definitions, so that the text generation will blank while the cog generating the image does its thing. (The blanking would not be required if the text background were black, however.)
Finally, since the bottom graphic is common to all the slides, something could be formulated to be generated algorithmically on the fly, thus reducing the size of the text area and its RAM footprint even further.
Anyway, I'm optimistic that something can be done to make everything fit. However, breaking it up into pieces like this shifts a burden to the slide designer (or design software) to crate the individual pieces and define where they go..
Anyway, I'm optimistic that something can be done to make everything fit. However, breaking it up into pieces like this shifts a burden to the slide designer (or design software) to put the pieces together. -Phil
Remember what kind of person you're working with. . .still optimistic? hahah...
Phil, are the monochrome-safe fonts the ones in the left column? Verdana and Parallax could both work for me.
But I appreciate constraint-driven design and don't mind locking certain elements in place for every slide, and having a minimal number of choices for format. I realize that the resolution will look a bit poor on a large screen, but the benefits of running it from a Propeller are still very strong.
You guys are spending a lot of time on this project. Puts some pressure on me to deliver a great presentation, and I welcome the contribution. But feel free to abandon anytime.
Rather than attempt images that one would expect to be good, and have them not be so good, maybe a style play makes sense? If images are small, or resolution limited, then leverage that. Think cartoon character image of somebody as opposed to a photograph. A photo reduced to a limited palette is recognizable, but crappy on average. However, that same palette can render that character image nicely, conveying precisely what the photo should have, without all the issues, because it's done without all the expectations.
Although my opinion doesn't count much because I can only use the basic VGA objects in the OBEX, let alone understand how to tweak them for advanced needs, I was thinking the same idea that potatohead basically pointed out as I was reading this thread. Rather than trying to accomplish something that is just outside the Propeller's limits by creating some very unique driver that using non-standard code modifications, why not start with Ken's template in post #70 to get a "Propeller Presenter Rev 1" accomplished? A clean way to show some text and a small bitmap would be useful in many ways by a large number of people. Then, in parallel or afterwards, go after the "limitation mods" to get a photo, etc in as well.
I think a lot of people think the "VGA_Demo" is regular 640x480 at 60Hz, but my monitor shows sync at 720x400 @ 70 Hz...
But, anyway if that mode has worked for Ken everywhere, then I might just stick to it...
Ray, what you just said seems to clear up some confusion. For a long time, I've felt like I haven't really known what resolution I was using and I would continually question the actual resolution of my setup. While I thought I've always been 640x480 or 800x600 I think I've seen projectors make slight adaptations to whatever the Propeller puts out to be a third resolution.
Now I know that maybe I'm not really crazy after all and that the monitors/projectors may have tweaked the input to display it in some other resolution.
I don't think monitors can really determine the number of horizontal pixels in a VGA signal, but they can determine the number of lines. If there are truly 400 lines then the 720 value is probably just determined by multiplying 400 times 16 divided by 9 and rounding to some standard value.
I am experimenting with video drivers and monitors now. It seems they have some preset resolutions and its internal logic tries to selects one based on signal it get.
One of monitor I tested with my "vga nostalgic" driver thought it is 768x576 instead of 800x600 when it was 50 Hz vblank. After set it to 53 Hz via frqa, so all these porch and sync lines stuff remained unchanged, it recognized 800x600 resolution. Maybe it think 50 Hz is PAL signal 768x576... and 53 Hz is something like standard 800x600x56Hz It switches resolutions at about 52 Hz.
Another monitor recognized 800x600 even at 48 Hz
Tried 800x600x53 Hz with some weird timings (way too long horizontal porches) on 4 different monitors, they all recognized this as 800x600 and displayed good stable picture.
Sync polarisation can matter. I tried to set 1920x1200 resolution (really 960x1200) but monitor thinks it is 1600x1200. These resolutions have different sync polarisation in specification, maybe when I set this right, this monitor can recognize this as 1920, and not 1600 horizontal pixels.
Ken, Finally had a second to work on this...
Here's a first cut at the text. This doesn't have SD support or 6-bit photo support, but does still have 22 kB free:
This text is with 2-bit color... I don't think monochrome will be better, but I'll try it out to see...
Update: Just tried title in monochrome using Arial font. Put it right underneath the above 2-bit title for comparison:
These look pretty similar to me actually... If we were just doing text, I think that instead of doing 2-bit text, we'd do 1-bit text at 2x the size and at higher screen resolution... The problem is getting in the photo, which will either have to be at low screen resolution or with a special custom driver to strecth the photo area....
This is all reminding me a little of my LCARS test: http://forums.parallax.com/showthread.php?101965
I think I actually had the monochrome, variable-pitch font in memory and drew the text at runtime...
Thanks pedward.
Memory storage code is now the big hurdle...
If Ken just wanted to show 1 slide, then we're already done. But, I think he wants to show a few.
If it were 2 slides, we could fit it in upper 32kB of EEPROM.
First choice is SD card, but FSRW wants 5 kB and I only have 4 kB free.
I'll have to convert all the text from 4 color to monochrome to fit it.
If it were for me, I'd just use a Flashpoint SuperQuad module because the Spin driver is only 1 kB, leaving lots of room...
But, I think Ken would rather use SD.
Just downloaded Kye's SD driver to see if it were smaller, but it's even bigger at 8 kB.
Anyway, looks like I'm headed for monochrome text. Phil posted a nice example. I'll see if I can get that looking nice.
Comments
I see what you mean. Here's an image where each line uses an optimized sub-palette of 16 colors from the 64 available:
That's probably acceptable quality. But there's no way to fit that into 32 kB or less, even with compression. Moreover, there are sure to be blocks of 16 pixels that use more than four of the 16 sub-palette colors, so setting up VSCL for 16 pixels per frame would not work.
-Phil
But, uncompressed, such an image requires 153 KB.
-Phil
Some sort of compression?
Ken Gracey
Showed a photo of his family...
BTW: I do think showing a photo from 1 or 2 flashpoint modules is possible. The regular VGA demo is set for a 20 MHz dot clock, which is right at the limit of what Flashpoint SQI can do. Regular 640x480 VGA has a 25 MHz dot clock though, so that might now work...
But, I must say that I've been thinking about this stuff for a very long time and the SSD1963 is a much, much better solution (assuming you can afford the extra expense and real estate).
BTW2: Done some thinking today about what to do for Ken... Think I'll try 512x384 resolution bas with a middle section that is 2X expanding in X&Y to blow a 6-bit graphics to large size...
I've been struggling with the compression aspect. There are compression algos that could probably do it, but the fly in the ointment is the decompression, which has to be done by the Prop in real time to keep up with the VGA driver, line-by-line. That rules out most of the commonly-used compression techniques. RLE decompression is probably doable in real time, but I'm beginning to doubt that its compression ratio is high enough to be of any value here.
Each line has to be decompressed in about 30 uS. That's only 600 PASM instructions to decompress 640 pixels.
-Phil
That would mean working on the next 16 lines while the previous 16 lines are decompressing. Do we have room for that?
I all your adventures... Did you ever have a problem with the projector sync'ing up to the VGA output?
Asking because the regular VGA mode is actually a bit non-standard... I'm a little worried about using it because you might have sync issues...
I seen a few posts about people having this problem with monitors. Not sure about projectors though...
I'm thinking that 640x480 or 1024x768 standard modes (or scaled down versions thereof) might be more conservative...
Hey Rayman,
No problems, anywhere I've been. That includes VGA projectors in Europe, Rocklin, Texas, Minnesota, Taiwan, Hong Kong, and one in San Francisco. At all of these places I've connected Propellers to them for low-res VGA examples. I think my demos are using 640x480.
Ken Gracey
There are still a bunch out there in circulation.
OBC
"Monochrome safe" means that a font will render nicely without applying anti-aliasing. I noticed that the text in Ken's slides were anti-aliased -- even in other than grayscale tones. This leads to a much bigger file requirement. The above image, by contrast, requires only 15kB and, without the font examples, 9kB, when saved as a PCX file. The PCX file format uses a very primitive RLE scheme which would be easy to decode with the Prop. For an image with 1-bit pixels, though, there are probably even more efficient schemes. BTW, the two colors don't have to be black and white: they can be any two colors in the 64-color palette. Moreover, any monochrome graphic (e.g. schematics, flowcharts, boxes, lines, etc.) could be accommodated in the text area. Precluded, however, would be red headlines and black text on a white background, since that's three colors.
I think that takes care of the text. Small embedded images could be handled in a manner similar to what I've been experimenting with. They would require window definitions, so that the text generation will blank while the cog generating the image does its thing. (The blanking would not be required if the text background were black, however.)
Finally, since the bottom graphic is common to all the slides, something could be formulated to be generated algorithmically on the fly, thus reducing the size of the text area and its RAM footprint even further.
Anyway, I'm optimistic that something can be done to make everything fit. However, breaking it up into pieces like this shifts a burden to the slide designer (or design software) to crate the individual pieces and define where they go..
-Phil
Remember what kind of person you're working with. . .still optimistic? hahah...
Phil, are the monochrome-safe fonts the ones in the left column? Verdana and Parallax could both work for me.
But I appreciate constraint-driven design and don't mind locking certain elements in place for every slide, and having a minimal number of choices for format. I realize that the resolution will look a bit poor on a large screen, but the benefits of running it from a Propeller are still very strong.
You guys are spending a lot of time on this project. Puts some pressure on me to deliver a great presentation, and I welcome the contribution. But feel free to abandon anytime.
Ken Gracey
http://www.deater.net/weave/vmwprod/apple/presentation/
An Apple ][
Rather than attempt images that one would expect to be good, and have them not be so good, maybe a style play makes sense? If images are small, or resolution limited, then leverage that. Think cartoon character image of somebody as opposed to a photograph. A photo reduced to a limited palette is recognizable, but crappy on average. However, that same palette can render that character image nicely, conveying precisely what the photo should have, without all the issues, because it's done without all the expectations.
-Phil
But, anyway if that mode has worked for Ken everywhere, then I might just stick to it...
Ray, what you just said seems to clear up some confusion. For a long time, I've felt like I haven't really known what resolution I was using and I would continually question the actual resolution of my setup. While I thought I've always been 640x480 or 800x600 I think I've seen projectors make slight adaptations to whatever the Propeller puts out to be a third resolution.
Now I know that maybe I'm not really crazy after all and that the monitors/projectors may have tweaked the input to display it in some other resolution.
Ken Gracey
One of monitor I tested with my "vga nostalgic" driver thought it is 768x576 instead of 800x600 when it was 50 Hz vblank. After set it to 53 Hz via frqa, so all these porch and sync lines stuff remained unchanged, it recognized 800x600 resolution. Maybe it think 50 Hz is PAL signal 768x576... and 53 Hz is something like standard 800x600x56Hz It switches resolutions at about 52 Hz.
Another monitor recognized 800x600 even at 48 Hz
Tried 800x600x53 Hz with some weird timings (way too long horizontal porches) on 4 different monitors, they all recognized this as 800x600 and displayed good stable picture.
Sync polarisation can matter. I tried to set 1920x1200 resolution (really 960x1200) but monitor thinks it is 1600x1200. These resolutions have different sync polarisation in specification, maybe when I set this right, this monitor can recognize this as 1920, and not 1600 horizontal pixels.
Here's a first cut at the text. This doesn't have SD support or 6-bit photo support, but does still have 22 kB free:
You can try it yourself:
KenSlide1a - Archive [Date 2012.05.18 Time 15.04].zip
This text is with 2-bit color... I don't think monochrome will be better, but I'll try it out to see...
Update: Just tried title in monochrome using Arial font. Put it right underneath the above 2-bit title for comparison:
These look pretty similar to me actually... If we were just doing text, I think that instead of doing 2-bit text, we'd do 1-bit text at 2x the size and at higher screen resolution... The problem is getting in the photo, which will either have to be at low screen resolution or with a special custom driver to strecth the photo area....
This is all reminding me a little of my LCARS test: http://forums.parallax.com/showthread.php?101965
I think I actually had the monochrome, variable-pitch font in memory and drew the text at runtime...
Here's what one board looks like at 19 kB:
Here's the other one. It's also 19kB, so you could only do one at a time...
If you make them both smaller, we can get them both on the same slide:
This is using the stock VGA driver, just with rows increased to 23 from the usual 16. Monitor sync should be exactly the same.
Text centering could be improved, this is just a rough cut to see where things stand...
I'm about 500 bytes short of being able to include FSRW...
For better or worse, think we'll have to switch to monochrome graphics for the text...
Memory storage code is now the big hurdle...
If Ken just wanted to show 1 slide, then we're already done. But, I think he wants to show a few.
If it were 2 slides, we could fit it in upper 32kB of EEPROM.
First choice is SD card, but FSRW wants 5 kB and I only have 4 kB free.
I'll have to convert all the text from 4 color to monochrome to fit it.
If it were for me, I'd just use a Flashpoint SuperQuad module because the Spin driver is only 1 kB, leaving lots of room...
But, I think Ken would rather use SD.
Just downloaded Kye's SD driver to see if it were smaller, but it's even bigger at 8 kB.
Anyway, looks like I'm headed for monochrome text. Phil posted a nice example. I'll see if I can get that looking nice.