I ran your latest program, and it looks pretty good!
I wouldn't use FSRW for the presentation. Partition the SD card into two volumes, and install FAT on one of them. Use a separate program with FSRW to read the files from the FAT partition and copy them in generic form to the other partition. Then you can use much smaller code during the presentation to read the simplified data format.
One thing I've discovered, BTW, is that unpacking one line of PCX RLE takes longer than displaying one line of 640-bit VGA, sometimes longer than two, depending on how much detail is on it. But, to have two or more cogs doing the work, they need to be able to skip ahead of each other in the file. 'Problem is that each compressed line is a different length, and an index table would take up another 480 bytes or so. So I'm looking at other compression techniques.
Thanks Phil. BTW: How did you generate the monochrome font example you posted? (Just curious if you have a better way than I've found).
I can do it Photoshop, but I don't know if Ken uses Photoshop or not...
Ken, Do you have any thoughts on how to advance slides? Was just looking at PropBOE and I don't see an easy way to do that...
Don't know if you'd consider the option, but the old "Propeller Demo Board" might be simpler to use for this since it has a hardwired VGA connector as well as mouse and keyboard... Ooops, I take that back. I just remembered the demo board doesn't have SD card...
I'm thinking that mouse left and right buttons might be the best way to control the presentation... Wonder if Parallax sells a mouse adapter that can connect to PropBOE...
Or, maybe the C3 would be another option for you? It has VGA, mouse and SD connectors standard...
If it's going to be PropBOE... Maybe use the microphone as tap sensor... Two taps for forward, three for backward...
One more thought: I'm currently using the standard VGA driver with user area of 512x368 pixels.
Another option is to use the XGA driver 1024x768 with 2X scaling to give user area of 512x384 pixels.
Because, by my estimation, 95% of the projectors you're likely to encounter have a real or "native" resolution that is XGA (1024x768) this may be a much better solution because you won't have the strech artifacts you see when the projector tries to scale the input to it's native resolution. So, I'm leaning toward switching over the XGA driver...
How did you generate the monochrome font example you posted?
I used Corel PhotoPaint.
...any thoughts on how to advance slides?
An infrared or XBee remote would work.
-Phil
P.S. One thing I'm really curious about in the Prop BOE design is why the VGA signals weren't hard-wired to P8-P15. I'm sure there's a good reason, but since the VGA outputs are buffered, hard-wiring would not have interfered with other uses for the pins.
I've come up with a simpler compression scheme that can be decompressed on the fly in one cog. It takes advantage of the fact that a huge majority of the 32-bit runs in a text image are background. So only the longs that are not background have to be recorded, along with their positions in the line. I used a single long at the beginning of each line to record those positions as a bitmask. The reason it can operate so fast now is that all hub accesses are longs instead of bytes. Here's what the output (640 x 480) looks like coming from a Prop BOE:
The data file that contains this image is 13 kB. The equivalent PCX file was 15 kB.
Here's the decoding loop for each line in the image:
that's pretty good! Have you watched the video from Linus Akesson about chip-music?
It has a turn over the page effect for switching to the next slide.
If I rember right Ken said SD-card can be viewed as standard hardware. So I think everything is there.
best regards
Stefan
If you see a way to also get a 4-color image on the screen, I'll be onboard...
That'll be coming up. Before I do that, though, I have to be able to define a black window in the text area so an image can be inserted by another cog. Another thing I want to do is begin each line with a 2-color palette, so that colored text can be displayed. Corel PhotoPaint is not cooperating, however. If I switch to a larger palette than two colors, it wants to anti-alias the text, which will just look crappy when converted back to two colors. What I may end up doing is limiting the palette to black, white, and a few primary colors, so that it won't have any options for shading the character outlines. Dunno if that'll work, though. [Edit: 'Just found the button in PhotoPaint that turns anti-aliasing off.]
What do people think about non-proportional fonts? I'm thinking another option could be a vertically oriented "display list", where various options could be enabled. For higher text density slides, non-proportional fonts have serious reuse gains over anything else, leaving room for a significant graph, or images.
Divide the screen into zones.
One might be standard tiles, another might be an image with tiles stacked next to it for text in that region, another might be double high pixels, basically a resolution reduction to scale images up, etc...
So far, I don't see a need for converting to mono-spaced fonts. Proportional fonts not only look better, but they take up less room for a given amount of text. But definitely "yes" to the display list idea. The idea is to divide the display into rectangular windows. The horizontal increment in my implementation will be 32 pixels so everything is on long boundaries. The text VGA will be the boss cog (not to be confused with Boss Hogg), and everything else will sync off of it, using the same display list. Ideally, it will be possible to write a PC program to take a 640x480 image, and convert it directly to a display-list structure, without the user having to hack and combine images. But that may be an overly ambitious objective.
Phil, can you driver cog perhaps do both... Certain lines with compressed 2-color and other lines with uncompressed 4-color?
I doubt it. With four-color pixels, there's only half the amount of time available between waitvids. Moreover, you'd have to change vcfg on the fly, which I don't believe is a register that's double buffered to update on waitvid boundaries. But I could be wrong about that. I think it's simpler just to use another cog that monitors the sync pins and jumps in when needed.
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.
I checked the latest code from Kye and he has one version that does not use the real time clock. That saves around 700bytes. I've taken the remaining code and started commenting things out. There are a whole lot of PUB methods for the time a file was created that are not really needed. Still 7k though. And you want it in 4k. Hmm.
Might need to do what was done in the CP/M emulation and recycle the cog space? You can either pad all pasm up to 512 longs and then get the location of where that memory is and you know at that place is 2k of free space for use as a text buffer etc. Or - split all the code into pasm and spin, compile the pasm into a binary blob which sits on the sd card eg "vgadriver.bin" and read all the pasm parts through one common 2k block (eg the 2k block used by the SD driver as that will always need to be there).
Here is my stripped-down, read only FSRW code. It supports SD/SDHC and FAT16/FAT32.
PropTool says it needs 3.3 kB (with the 2 sector buffers). With BST it will be even smaller, if you not use all the methodes.
The low level SD-SPI code is bases on the old SDSPIQASM version from Tomas Rokicki, so it will not be as fast as lonesock's drivers.
The mask that determines which longs contain detail other than background color for each line uses only 20 bits (640 / 32 = 20). That leaves 12 bits that I can use for color information: six bits for a foreground color, and six bits for background. So I wrote a Perl script that inputs a 640x480x24-bit RGB .png file and for each line, matches each RGB pixel to the Prop's 64-color VGA palette, keeping track of how often each color gets used. It then selects the two most pervasive colors, and chooses the more pervasive of the two as the background color. Then it goes through the original line again, matching each RGB color to the new 2-color palette to produce the line of pixels. Here's one example of the output:
(The brightness gradient seen above is due to the monitor's crappy backlight, BTW, and not to anything that was programmed in.) The size of the encoded image file, in this case, is 8kB, and the total size of the program with the image file in hub RAM is 8.5kB.
The next step is to is to create an array of alternate foreground and background colors. These would be applied to blocks of size 32 pixels wide and eight pixels high, thus enabling black knockouts for photographs and other four-color images, along with other colored rectangles -- possibly containing text -- and lines
Thanks Phil. BTW: How did you generate the monochrome font example you posted? (Just curious if you have a better way than I've found).
I can do it Photoshop, but I don't know if Ken uses Photoshop or not...
Ken, Do you have any thoughts on how to advance slides?
Hey Ray - I've been at Maker Faire this weekend so I didn't have a chance to think about Propeller Presenter much, but I'll return to it Monday or Tuesday when I'm at Parallax.
For advancing the slide I will pass out another PropBOE with an XBee transmitter and have an audience member advance slides.
This week I will get a closer look into the two solutions you and Phil have provided and work towards implementing the most useful one. I sure appreciate what you guys have done to get me going.
I would like to be able to take any old 640x480 image and analyze it to see which parts can be rendered in lines of two colors, and which parts have to be masked off from the "text" image and shown with a different cog as an overlay over the text image. As a start, I'm using a 20W x 32H grid and checking the number of colors that exist in each. Those blocks with more than two colors become candidates for the overlay. Here's a typical image (with a grid overly) and a block-by-block analysis of their color counts (from a Perl script):
Not all blocks with more than three colors need to be overlain if the colors are in different lines, as they are with those text blocks that contain red, white, and black. And not all photo blocks with fewer than three colors qualify to be included in the text image, if their colors conflict with actual text colors in the same line. So a secondary sweep through the image will be necessary to separate the 2-color bitmap from the high-color bitmap. Once the separation is made, the high-color bitmap can be dithered down to four colors on (hopefully) a long-by-long basis, without incurring too much of a memory penalty.
Should an accurate analysis prove too difficult, I may have to resort to requiring a block-aligned color mask in the text image, with additional photo images to be dropped in by my software.
I've started thinking that on paper 4-color text at 512x384 should be better than monochrome at 640x480.
But, I'm not sure I've seen that myself yet...
It could be that it depends how close you are to the screen... Maybe when you're up close monochrome looks better, but at audience distance 4-color is better...
I'm experimenting a bit with this now...
Changed most of the text to monochrome to see if it's better that way and maybe it is:
There are two texts on the bottom that are 3 lines each. One on the left is monochrome and right is still 4-color. I think they both look about the same:
monochrome uses less memory, so it's probably a good trade...
BTW: Thanks Ariba for the smaller FSRW! That will be a big help if we go forward.
Another savings may be to put the driver codes into the heap so that space can be reused for bitmaps.
Thinking about 640x480 instead of 512x384 too... The XGA driver can also do 640x480.
Still, I think QXGA will look better on projector because it won't have to be scaled... Plus, the 4-color photos appear bigger
on the lower resolution...
I'm also thinking about revising the 1-bit bitmap Windows tool... Right now, it assumes there will be an even number of 16-bit rows, just like with the ROM font. But, this excercise has shown that this isn't always true. And, encoding a 48-line tall image results in a 25% waste.
Space wise have you considered Dr_Acula's cogjets approach?
They are composed of COG ASM code saved on the SD, and a small SPIN interface. Maybe they could free some space, after all the SD part is already included.
Massimo
Hey Phil, just taking the first opportunity for a check-in I've had in a couple of days. I can certainly get by with what I'm seeing!
Will I be able to produce multiple slides?
I can't check in until Wednesday evening. Tomorrow SparkFun is visiting Parallax along with a couple of makers who are lingering around after the faire. Then I'm headed down to Walnut Creek to do a presentation. Will the travel chaos ever end for me?
The plan is to read the image data files from SD, so yes. The mechanism for producing the original images still has to be worked out, though. I'm using Corel PhotoPaint, which allows non-anti-aliased text. I'm not familiar with Keynote, so I can't say whether the images it produces would work with my compression program.
Getting photos compressed adequately and still looking good is proving to be the biggest challenge. For example, the knockout in the image above is 288W x 330H pixels, or 96k pixels total. With four-color coding, that reduces to 24kB, exclusive of any palette information. That number needs to be cut in half -- including the palette data. Images with a lot of busy detail (e.g. the BOE Bot in front of the rock wall) are the hardest. So far, I'm having some limited success by using 2x wide pixels, which cuts the memory footprint in half for the pixel data, but not for the palette data. Nonetheless, it's an interesting enough problem to keep hacking away at it.
Content creation is going to be a serious challenge...
I think it would take serious effort to come up with a tool that Ken would suffer through more than once...
Ken, when I get that PropBOE, I'll try to show you how our DVI Graphics Shield can plug right into the P0..P15 header and give you a much less painful approach to this...
With the DVI Graphics Shield installed on the PropBOE, you only have to save your slides as 640x480 Windows bitmap files to the SD card and you're all set...
You can then show your slides over DVI, HDMI, VGA, or even onto a 5" touchscreen, if you like...
Ya'll pardon my foolishness here, but may I ask - why BMP?
That has to be one of the most bloated graphics formats there is.
Ok, it's a straight forward simple thing, but there are other formats that
can save a lot of space...
Comments
I ran your latest program, and it looks pretty good!
I wouldn't use FSRW for the presentation. Partition the SD card into two volumes, and install FAT on one of them. Use a separate program with FSRW to read the files from the FAT partition and copy them in generic form to the other partition. Then you can use much smaller code during the presentation to read the simplified data format.
One thing I've discovered, BTW, is that unpacking one line of PCX RLE takes longer than displaying one line of 640-bit VGA, sometimes longer than two, depending on how much detail is on it. But, to have two or more cogs doing the work, they need to be able to skip ahead of each other in the file. 'Problem is that each compressed line is a different length, and an index table would take up another 480 bytes or so. So I'm looking at other compression techniques.
-Phil
I can do it Photoshop, but I don't know if Ken uses Photoshop or not...
Ken, Do you have any thoughts on how to advance slides? Was just looking at PropBOE and I don't see an easy way to do that...
Don't know if you'd consider the option, but the old "Propeller Demo Board" might be simpler to use for this since it has a hardwired VGA connector as well as mouse and keyboard... Ooops, I take that back. I just remembered the demo board doesn't have SD card...
I'm thinking that mouse left and right buttons might be the best way to control the presentation... Wonder if Parallax sells a mouse adapter that can connect to PropBOE...
Or, maybe the C3 would be another option for you? It has VGA, mouse and SD connectors standard...
If it's going to be PropBOE... Maybe use the microphone as tap sensor... Two taps for forward, three for backward...
One more thought: I'm currently using the standard VGA driver with user area of 512x368 pixels.
Another option is to use the XGA driver 1024x768 with 2X scaling to give user area of 512x384 pixels.
Because, by my estimation, 95% of the projectors you're likely to encounter have a real or "native" resolution that is XGA (1024x768) this may be a much better solution because you won't have the strech artifacts you see when the projector tries to scale the input to it's native resolution. So, I'm leaning toward switching over the XGA driver...
An infrared or XBee remote would work.
-Phil
P.S. One thing I'm really curious about in the Prop BOE design is why the VGA signals weren't hard-wired to P8-P15. I'm sure there's a good reason, but since the VGA outputs are buffered, hard-wiring would not have interfered with other uses for the pins.
The data file that contains this image is 13 kB. The equivalent PCX file was 15 kB.
Here's the decoding loop for each line in the image:
mov long_cnt,#20 rdlong fg_mask,dat_ptr add dat_ptr,#4 dat_loop shr fg_mask,#1 wc if_c rdlong acc,dat_ptr if_c add dat_ptr,#4 if_nc mov acc,background wrlong acc,buf_ptr add buf_ptr,#4 djnz long_cnt,#dat_loop-Phil
that's pretty good! Have you watched the video from Linus Akesson about chip-music?
It has a turn over the page effect for switching to the next slide.
If I rember right Ken said SD-card can be viewed as standard hardware. So I think everything is there.
best regards
Stefan
As it turns out, a separate cog for doing the decompression is unnecessary. So I incorporated the decompression into the video-generation loop:
mov counter,#20 ' 20 x 32-bit tiles = 640 pixels rdlong fg_mask,disp_ptr add disp_ptr,#4 ' Visible Video pix_loop shr fg_mask,#1 wc if_c rdlong pixels,disp_ptr if_c add disp_ptr,#4 if_nc neg pixels,#1 waitvid vis_colors,pixels ' Display the pixels. djnz counter,#pix_loop ' Repeat.It not only saved a cog, but 360 bytes of code and double-buffer space that I no longer need.
-Phil
If you see a way to also get a 4-color image on the screen, I'll be onboard...
That'll be coming up. Before I do that, though, I have to be able to define a black window in the text area so an image can be inserted by another cog. Another thing I want to do is begin each line with a 2-color palette, so that colored text can be displayed. Corel PhotoPaint is not cooperating, however. If I switch to a larger palette than two colors, it wants to anti-alias the text, which will just look crappy when converted back to two colors. What I may end up doing is limiting the palette to black, white, and a few primary colors, so that it won't have any options for shading the character outlines. Dunno if that'll work, though. [Edit: 'Just found the button in PhotoPaint that turns anti-aliasing off.]
-Phil
Divide the screen into zones.
One might be standard tiles, another might be an image with tiles stacked next to it for text in that region, another might be double high pixels, basically a resolution reduction to scale images up, etc...
BTW: Phil, you've got excellent results.
So far, I don't see a need for converting to mono-spaced fonts. Proportional fonts not only look better, but they take up less room for a given amount of text. But definitely "yes" to the display list idea. The idea is to divide the display into rectangular windows. The horizontal increment in my implementation will be 32 pixels so everything is on long boundaries. The text VGA will be the boss cog (not to be confused with Boss Hogg), and everything else will sync off of it, using the same display list. Ideally, it will be possible to write a PC program to take a 640x480 image, and convert it directly to a display-list structure, without the user having to hack and combine images. But that may be an overly ambitious objective.
-Phil
-Phil
I checked the latest code from Kye and he has one version that does not use the real time clock. That saves around 700bytes. I've taken the remaining code and started commenting things out. There are a whole lot of PUB methods for the time a file was created that are not really needed. Still 7k though. And you want it in 4k. Hmm.
Might need to do what was done in the CP/M emulation and recycle the cog space? You can either pad all pasm up to 512 longs and then get the location of where that memory is and you know at that place is 2k of free space for use as a text buffer etc. Or - split all the code into pasm and spin, compile the pasm into a binary blob which sits on the sd card eg "vgadriver.bin" and read all the pasm parts through one common 2k block (eg the 2k block used by the SD driver as that will always need to be there).
PropTool says it needs 3.3 kB (with the 2 sector buffers). With BST it will be even smaller, if you not use all the methodes.
The low level SD-SPI code is bases on the old SDSPIQASM version from Tomas Rokicki, so it will not be as fast as lonesock's drivers.
Andy
(The brightness gradient seen above is due to the monitor's crappy backlight, BTW, and not to anything that was programmed in.) The size of the encoded image file, in this case, is 8kB, and the total size of the program with the image file in hub RAM is 8.5kB.
The next step is to is to create an array of alternate foreground and background colors. These would be applied to blocks of size 32 pixels wide and eight pixels high, thus enabling black knockouts for photographs and other four-color images, along with other colored rectangles -- possibly containing text -- and lines
-Phil
Hey Ray - I've been at Maker Faire this weekend so I didn't have a chance to think about Propeller Presenter much, but I'll return to it Monday or Tuesday when I'm at Parallax.
For advancing the slide I will pass out another PropBOE with an XBee transmitter and have an audience member advance slides.
This week I will get a closer look into the two solutions you and Phil have provided and work towards implementing the most useful one. I sure appreciate what you guys have done to get me going.
Ken Gracey
Not all blocks with more than three colors need to be overlain if the colors are in different lines, as they are with those text blocks that contain red, white, and black. And not all photo blocks with fewer than three colors qualify to be included in the text image, if their colors conflict with actual text colors in the same line. So a secondary sweep through the image will be necessary to separate the 2-color bitmap from the high-color bitmap. Once the separation is made, the high-color bitmap can be dithered down to four colors on (hopefully) a long-by-long basis, without incurring too much of a memory penalty.
Should an accurate analysis prove too difficult, I may have to resort to requiring a block-aligned color mask in the text image, with additional photo images to be dropped in by my software.
-Phil
But, I'm not sure I've seen that myself yet...
It could be that it depends how close you are to the screen... Maybe when you're up close monochrome looks better, but at audience distance 4-color is better...
I'm experimenting a bit with this now...
There are two texts on the bottom that are 3 lines each. One on the left is monochrome and right is still 4-color. I think they both look about the same:
monochrome uses less memory, so it's probably a good trade...
BTW: Thanks Ariba for the smaller FSRW! That will be a big help if we go forward.
Another savings may be to put the driver codes into the heap so that space can be reused for bitmaps.
Thinking about 640x480 instead of 512x384 too... The XGA driver can also do 640x480.
Still, I think QXGA will look better on projector because it won't have to be scaled... Plus, the 4-color photos appear bigger
on the lower resolution...
I'm also thinking about revising the 1-bit bitmap Windows tool... Right now, it assumes there will be an even number of 16-bit rows, just like with the ROM font. But, this excercise has shown that this isn't always true. And, encoding a 48-line tall image results in a 25% waste.
Here's the knockout overlain with a 64-color test pattern, using a separate cog:
The overlay cog just monitors the sync pins and jumps in when necessary to do its thing. Total size, so far, of the program and data is 9kB.
Now I've got to get the photo encoded so that it can be displayed instead of the test pattern. That will increase the RAM footprint considerably.
-Phil
They are composed of COG ASM code saved on the SD, and a small SPIN interface. Maybe they could free some space, after all the SD part is already included.
Massimo
-Phil
Will I be able to produce multiple slides?
I can't check in until Wednesday evening. Tomorrow SparkFun is visiting Parallax along with a couple of makers who are lingering around after the faire. Then I'm headed down to Walnut Creek to do a presentation. Will the travel chaos ever end for me?
Ken Gracey
Getting photos compressed adequately and still looking good is proving to be the biggest challenge. For example, the knockout in the image above is 288W x 330H pixels, or 96k pixels total. With four-color coding, that reduces to 24kB, exclusive of any palette information. That number needs to be cut in half -- including the palette data. Images with a lot of busy detail (e.g. the BOE Bot in front of the rock wall) are the hardest. So far, I'm having some limited success by using 2x wide pixels, which cuts the memory footprint in half for the pixel data, but not for the palette data. Nonetheless, it's an interesting enough problem to keep hacking away at it.
-Phil
What you are trying to do is clearly impossible on the Propeller.
So we look forward to seeing your results soon:)
I think it would take serious effort to come up with a tool that Ken would suffer through more than once...
Ken, when I get that PropBOE, I'll try to show you how our DVI Graphics Shield can plug right into the P0..P15 header and give you a much less painful approach to this...
With the DVI Graphics Shield installed on the PropBOE, you only have to save your slides as 640x480 Windows bitmap files to the SD card and you're all set...
You can then show your slides over DVI, HDMI, VGA, or even onto a 5" touchscreen, if you like...
That has to be one of the most bloated graphics formats there is.
Ok, it's a straight forward simple thing, but there are other formats that
can save a lot of space...