Ken, since you're sending me a PropBOE, I can surely comp a DVI Graphics Shield.
Also, I finally have the production analog VGA plugin boards, so I'll include one of those too, for cases where DVI is not available...
We don't have to call it a shield, but I think that might be what's printed on the board...
Of course, for $75 I can have ExpressPCB make you one with anything you want printed on it
Actually, a couple stickers would be just as good, right?
I'll make a sticker that says "PropBOE DVI Adapter"...
Hey Ray,
DVI Graphics Shield
Analog VGA Plugin in case DVI is not available (usually is not available)
It's okay to keep the word "shield" for now but if we start selling these we'll need to rename it. I've been selling the Propeller BOE for what it is: everything, in a single package, with no stackers being required.
Let me take a look and we'll decide together what to do. Use my Parallax address:
Ken Gracey
Parallax Inc.
599 Menlo Drive
Rocklin, CA 95765
You can use our UPS account too. I'll e-mail it to you.
In retrospect, I probably should have made these boards with VGA the normal output... But, at the time, DVI seemed way cooler...
So, maybe this board will give you an interim solution...
I'll think about if I can quickly do a more PropBOE targeted board with VGA output...
Might take a few weeks though... Still have until July?
In retrospect, I probably should have made these boards with VGA the normal output... But, at the time, DVI seemed way cooler...
So, maybe this board will give you an interim solution...
I'll think about if I can quickly do a more PropBOE targeted board with VGA output...
Might take a few weeks though... Still have until July?
Yeah, Ray, I have until the end of July. An interim solution is fine, especially if we can work towards a long-term design around the PropBOE. You could make something that plugs into the header and passes signals to the VGA, or plugs directly into the VGA port to avoid passing too many wires between the breadboard and then back to the VGA. I don't know what's best here but I'm sure you'll figure it out.
This weekend I hope to talk to Phil about his solution as well.
One thing we could try is to run the most significant 6-bits from the DVI Graphics board over to the PropBOE VGA input header...
Not sure how appealing that would be, but it would let you use the PropBOE's VGA connector...
It might look a little messy though, not sure...
Anyway, it that case you have 6-bit color over the whole screen and the slide would look like this:
It's a most appropriate question and one that warrants an explanatory answer. I also welcome any input on my approach.
I'll tell you the direction I'm taking with my presentations for education, distributors and universities. I'm not focusing on the Propeller architecture, design, technical features and specifications directly. In the beginning, we'd present too many block diagrams and technical details while people yawned waiting for examples. This was partially a result of not having the huge code base we have today, which let's me promote the idea:
It's all just a matter of high-level integration! Well, at least getting started should be. And that's important since I just want us to break the barrier of it being different, or being "hard" as I heard from a very capable engineer who has never used it, or that it uses a proprietary language that somebody can't learn.
I'm taking an approach which shows the following:
How easy it is to program the Propeller, using a very simple example first (with LEDs) but then going straight into examples that integrate Objects.
Learn.parallax.com and what can be done very easily with the PropBOE and little accessory hardware (robot chassis, sensors, XBee, etc.). And showing how anyone (like the high school freshmen I'm teaching) can use our material to succeed with the Propeller.
Spin, ASM and C, with a focus on the open[ing] tool chains.
Impressive load-and-run demonstrations, like WAV file playback, video display with sensors, etc.
The technical details are conveyed through the examples. Through each of them I show how the program runs in the architecture (number of cogs, objects used, etc.) along with any special Prop-specific features (counters, shared memory) and where the code comes from. There's a change I'm introducing in our Educational agenda related to this same method. The goal is that customers of different levels of skill (and interest) can jump in the Propeller. For example, a high school student should be able to load wav files and run them from a robot without understanding how it all works. But an engineering student in the university could understand the design of the application from our same documentation. This lets us present the information first in a load and run (learn by doing) format followed with explanation about how it works for those who are interested.
The commercial customers will receive a mix of the above with customer examples in renewable energy, robotics, from Parallax Semiconductor's technical and business perspective. They obviously program specifically for their product design.
So, running a presentation from the Propeller itself is the ultimate show-and-tell, without actually selling a product. Although I'd love to show the raw Prop, I don't think either of these audiences would truly discount our demonstration if we tell them how it works with accessory hardware. Therefore I should certainly have a DVI adapter (do we have to call it a shield?). How do I order one? I should take a look for myself as the various solutions around these forums start to emerge.
Perhaps the best example of what Parallax has to offer is conveyed by people posting on this thread: solutions, collaboration, and contributions from people who use our products.
Ken Gracey
From an engineering design/programming background, this sounds like the best approach to me too. Let them see what can be done, then show where the blocks came from, and how easy it is to put together. Hopefully that gets the interest and inquisitiveness to look deeper.
From this perspective, it would be preferable to not use any complicated peripheral chips (such as the DVI). So here is a few thoughts...
1. First show off the standard prop VGA with just a bitmap. They can then see how good the VGA can be.
2. Then show the reduced resolution bitmaps and at this time you can explain that the memory used in the demo is such that you are replacing a PC and therefore need to reduce the resolution because the prop does not have GB of memory. This should now make sense - the prop is not really a full PC replacement.
3. Then show off your main screen (I presume you can/will have a large main screen at the front of the lecture room) using the DVI addon so they can see what is possible. The students can just see the lower resolution VGA bitmaps to follow along. (i.e. you run a higher resolution of the same show that they can personally follow along with)
If you have your own monitor, then you can also show off TV output as well. This demonstrates all the video options of the Prop/PropBOE.
Of course, the sound generation from the prop is great too. Perhaps you can show some snippets of the organ (see the other threads) as well. A couple of slides of the Quadcopter would also show what can be done with just a gyro addon.
I am thinking that you require the prop to be running one of the OS'es so that various programs (binaries) can be launched to show off these various aspects of the prop. Otherwise, you clearly are not going to have enough prop memory available.
You can try it on your own system with the attached archive. Enjoy!
-Phil
I would call that quite acceptable, especially considering that it's a MICROCONTROLLER! Heck, a retail DB15 cable probably costs more than the chip!
Could you imaging surreptitiously installing Propellers inside old LCD monitors, then putting them on the shelf at Best Buy and turning them on! How about an overlay gizmo that puts random stuff on the screen at random times?
A little quirk: I can't get it to work on pin-group 0, only on 1 and 2.
Yeah, my bad. I was using that block for debugging on the scope. I've got the dira's commented out in the attached version.
Here's the slide with the two boards side-by-side:
I had to increase the size of the color-swap FIFO buffer, since so much is happening in each scan line while it's doing the much wider inset.The reson for the FIFO buffer in the first place is that unpacking the color swap information is slower than displaying the colored pixels. So there has to be some elastic storage for the unpacked colors. The attached archive is for this one.
That one looks great too. Noticed a lot of shimmering in the photo areas with my NEC Multisync 1960NXI monitor with this driver... Anybody else see that?
Phil, your file starts with "VGA 640 x 480 2-bit with 4-bit inset driver", but I think you mean "VGA 640 x 480 2-color with 4-color inset driver", right?
Actually, the insert is more than 4-colors, right?
Ken, started looking at your other slides with DVI graphics board...
Output looks exactly like your pictures, but I think your pictures could actually be a bit better.
I think maybe whatever subsampling was used to reduce it to 640x480 wasn't ideal...
This is a very minor thing, but if you could post a higher resolution image of the slide or the actual slide in PowerPoint or some other format my PC can read,
I'd like to take a quick look at other subsampling methods to try to make it even better...
Maybe "slide 46.bmp" would be a good one to test this with. If it's too big to post, can you email it to me?
Again, this is just fine tuning, not that important...
Noticed a lot of shimmering in the photo areas with my NEC Multisync 1960NXI monitor with this driver...
Yes, I had an issue with shimmering in the inset area, too, but thought I fixed it. Now that you bring it up, I notice that one of the three monitors I used for testing exhibits it to a small extent. The problem relates to the way the inset gets synchonized to the VGA signal generated in another cog. I'm doing a waitpne/peq on the horizontal sync, followed by resetting phsa of the video clock. But this still leaves a little bit of uncertainty in the relationship between the clock in the overlay driver and the one in the VGA driver. I guess I'll have to figure out a better way to synchronize them.
Phil, your file starts with "VGA 640 x 480 2-bit with 4-bit inset driver", but I think you mean "VGA 640 x 480 2-color with 4-color inset driver", right?
Right. The inset driver is four-color on a tile-by-tile basis (a tile being 16 horizontal pixels by 1 row), but it uses 16 colors total within the inset.
This is a very minor thing, but if you could post a higher resolution image of the slide or the actual slide in PowerPoint or some other format my PC can read,
I'd like to take a quick look at other subsampling methods to try to make it even better...
Maybe "slide 46.bmp" would be a good one to test this with. If it's too big to post, can you email it to me?
Again, this is just fine tuning, not that important...
OK, I'll be sure to do that today. I need to participate in the local trash cleanup day and then I'll post some high-res files. Is there a preferred format?
I don't know why I didn't think of this sooner, but the right way to do what I'm attempting with the overlay is to show everything in two-bit (four-color) mode. The stuff that's actually two-color would be recoded, such that 32 two-color bits originally encoded:
abcdefghijklmnopABCDEFGHIJKLMNOP
would be interleaved (in the same way that the ROM font bits are interleaved):
aAaBcCdDeEfFgGhHiIjJkKlLmMnNoOpP
This long would then be shown twice in succession, but with different colors, arranged thus:
1st time: BkndBkndFgndFgnd, which keys on bits 0, 2, ..., 30
2nd time: BkndFgndBkndFgnd, which keys on bits 1, 3, ..., 31
[Edit:Or just use one palette and shift the pixel bits by one position.]
That way, the four-color stuff can be included in the same scan line, with only a change to vscl, which is synchronized to waitvid (as opposed to vcfg, which is not). In fact, both the 2-color and 4-color pixel data can be mixed together, with a line-leading bitmap to indicate which longs are two-color and which are four-color.
This will not only cure the shimmering but also free up a cog. The color unpacking cog is still necessary, though, for the four-color stuff.
Phil, Do you see this idea being expandable to 1024x768? Also, is some kind of text reader possible with this (using variable pitch font)?
Ken, I think most new projectors support widescreen mode... Since the DVI Graphics chips support widescreen mode (like 16:9),
you can actually get better looking slide because of the slightly higher resolution like 800x480.
Powerpoint now supports widescreen mode and I bet Keynote does too.
Just a thought, I don't think anybody would rely on a widescreen projector yet...
Here's one PropBOE specific idea for SSD1963 based VGA graphics.
This board would sit on top of where the proto area is, maybe with stackable headers.
Would need some work to make it fit though:
Do you see this idea being expandable to 1024x768?
For two-color only? Yes, assuming the foreground is sparse enough.
Also, is some kind of text reader possible with this (using variable pitch font)?
That's less likely. The typeface would have to be stored in RAM, and it wouldn't be scalable. Plus, the kerning rules would have to be executed in real time.
Hmm... Well, I guess you can still have every page stored on SD...
This might also be very useful for a game like chess...
I had a real problem coding chess with memory, but this kind of compression should save a ton of space...
In your new scheme, is the 4-color part also compressed?
All,
I think the pictures of the PropBOE would look more impressive if you switched to a 4 color CAD model of the board - such as the one in the middle of this page http://learn.parallax.com/node/78
The model would use the colors white, black, blue and gray, and these pictures could be higher resolution that the digital pictures because pixel data is now represented in just 2 bits.
That is precisely what I was thinking to maximize "on prop" video. 3D cad models can be presented in similar ways, using solid colors and outline edges in black. Total on-screen colors isn't high, but the object is still highly recognizable.
Phil,
I went back and reread your explanation at the top of the page, and am very amazed at the level of detail you were able to squeeze out of 4 colors - great job.
Forrest
Used Photoshop to resize slide 46 to 640x480 using bicubic scaling with and without sharp...
Looks like without sharp works better for this slide.
I think it's much better now. Especially the red ribbon on the top left corner and the symbol in the bottom right corner.
You can also kinda read the small text now (using some imagination maybe). Slide46_PS2.bmp
Original:
Bicubic reduced:
It's also not so bad to just to use Zoom inside PowerPoint to make it the right size and then do a screen capture:
I've eliminated a cog, as I laid out in post #228 above. The 2-color and 4-color data are now handled by the same driver on a block-by-block basis. The nice thing about this arrangement is that the 4-color data no longer has to be in one contiguous group of blocks, but can consist of disjoint blocks spread over the screen. That way several small photos can be present at different locations. Also, without having to sync an overlay cog to the main cog, all of the shimmering is gone. Finally, I've combined both the 1-bit data and the 2-bit pixel and color data into one .dat file, which could be read into RAM from an SD card.
The attached archive contains the new Slide 17 demo program.
Very nice Phil. Display is rock solid, no more shimmering. I think it's also great to have everything in one file.
Not much space left now, probably going to need Ariba's slimmed down FSRW to make it work...
BTW: For the pictures from post#239, one you have one loaded, you can just keep clicking where the "next" buttun is to cycle through them...
The differences may be very subtle, but once is blown up on a projector screen, I think the photoshop one will look significantly better...
Comments
Hey Ray,
DVI Graphics Shield
Analog VGA Plugin in case DVI is not available (usually is not available)
It's okay to keep the word "shield" for now but if we start selling these we'll need to rename it. I've been selling the Propeller BOE for what it is: everything, in a single package, with no stackers being required.
Let me take a look and we'll decide together what to do. Use my Parallax address:
Ken Gracey
Parallax Inc.
599 Menlo Drive
Rocklin, CA 95765
You can use our UPS account too. I'll e-mail it to you.
Thanks,
Ken Gracey
So, maybe this board will give you an interim solution...
I'll think about if I can quickly do a more PropBOE targeted board with VGA output...
Might take a few weeks though... Still have until July?
Yeah, Ray, I have until the end of July. An interim solution is fine, especially if we can work towards a long-term design around the PropBOE. You could make something that plugs into the header and passes signals to the VGA, or plugs directly into the VGA port to avoid passing too many wires between the breadboard and then back to the VGA. I don't know what's best here but I'm sure you'll figure it out.
This weekend I hope to talk to Phil about his solution as well.
Ken Gracey
Not sure how appealing that would be, but it would let you use the PropBOE's VGA connector...
It might look a little messy though, not sure...
Anyway, it that case you have 6-bit color over the whole screen and the slide would look like this:
You can try it on your own system with the attached archive. Enjoy!
-Phil
From an engineering design/programming background, this sounds like the best approach to me too. Let them see what can be done, then show where the blocks came from, and how easy it is to put together. Hopefully that gets the interest and inquisitiveness to look deeper.
From this perspective, it would be preferable to not use any complicated peripheral chips (such as the DVI). So here is a few thoughts...
1. First show off the standard prop VGA with just a bitmap. They can then see how good the VGA can be.
2. Then show the reduced resolution bitmaps and at this time you can explain that the memory used in the demo is such that you are replacing a PC and therefore need to reduce the resolution because the prop does not have GB of memory. This should now make sense - the prop is not really a full PC replacement.
3. Then show off your main screen (I presume you can/will have a large main screen at the front of the lecture room) using the DVI addon so they can see what is possible. The students can just see the lower resolution VGA bitmaps to follow along. (i.e. you run a higher resolution of the same show that they can personally follow along with)
If you have your own monitor, then you can also show off TV output as well. This demonstrates all the video options of the Prop/PropBOE.
Of course, the sound generation from the prop is great too. Perhaps you can show some snippets of the organ (see the other threads) as well. A couple of slides of the Quadcopter would also show what can be done with just a gyro addon.
I am thinking that you require the prop to be running one of the OS'es so that various programs (binaries) can be launched to show off these various aspects of the prop. Otherwise, you clearly are not going to have enough prop memory available.
Just my 2c
I would call that quite acceptable, especially considering that it's a MICROCONTROLLER! Heck, a retail DB15 cable probably costs more than the chip!
Could you imaging surreptitiously installing Propellers inside old LCD monitors, then putting them on the shelf at Best Buy and turning them on! How about an overlay gizmo that puts random stuff on the screen at random times?
Can you do the first slide with the BOE and PropBOE side by side and also slide46?
If you can do those equally well, I think Ken's going to have a touch choice...
The robot on my VGA monitor looks a bit different, but I think that is intended
A little quirk: I can't get it to work on pin-group 0, only on 1 and 2.
Andy
Here's the slide with the two boards side-by-side:
I had to increase the size of the color-swap FIFO buffer, since so much is happening in each scan line while it's doing the much wider inset.The reson for the FIFO buffer in the first place is that unpacking the color swap information is slower than displaying the colored pixels. So there has to be some elastic storage for the unpacked colors. The attached archive is for this one.
-Phil
Phil, your file starts with "VGA 640 x 480 2-bit with 4-bit inset driver", but I think you mean "VGA 640 x 480 2-color with 4-color inset driver", right?
Actually, the insert is more than 4-colors, right?
Output looks exactly like your pictures, but I think your pictures could actually be a bit better.
I think maybe whatever subsampling was used to reduce it to 640x480 wasn't ideal...
This is a very minor thing, but if you could post a higher resolution image of the slide or the actual slide in PowerPoint or some other format my PC can read,
I'd like to take a quick look at other subsampling methods to try to make it even better...
Maybe "slide 46.bmp" would be a good one to test this with. If it's too big to post, can you email it to me?
Again, this is just fine tuning, not that important...
Yes, I had an issue with shimmering in the inset area, too, but thought I fixed it. Now that you bring it up, I notice that one of the three monitors I used for testing exhibits it to a small extent. The problem relates to the way the inset gets synchonized to the VGA signal generated in another cog. I'm doing a waitpne/peq on the horizontal sync, followed by resetting phsa of the video clock. But this still leaves a little bit of uncertainty in the relationship between the clock in the overlay driver and the one in the VGA driver. I guess I'll have to figure out a better way to synchronize them.
Right. The inset driver is four-color on a tile-by-tile basis (a tile being 16 horizontal pixels by 1 row), but it uses 16 colors total within the inset.
-Phil
OK, I'll be sure to do that today. I need to participate in the local trash cleanup day and then I'll post some high-res files. Is there a preferred format?
Ken Gracey
Besides that, PNG in the largest resolution you can would be ideal..
would be interleaved (in the same way that the ROM font bits are interleaved):
This long would then be shown twice in succession, but with different colors, arranged thus:
2nd time: BkndFgndBkndFgnd, which keys on bits 1, 3, ..., 31
[Edit:Or just use one palette and shift the pixel bits by one position.]
That way, the four-color stuff can be included in the same scan line, with only a change to vscl, which is synchronized to waitvid (as opposed to vcfg, which is not). In fact, both the 2-color and 4-color pixel data can be mixed together, with a line-leading bitmap to indicate which longs are two-color and which are four-color.
This will not only cure the shimmering but also free up a cog. The color unpacking cog is still necessary, though, for the four-color stuff.
-Phil
Ken, I think most new projectors support widescreen mode... Since the DVI Graphics chips support widescreen mode (like 16:9),
you can actually get better looking slide because of the slightly higher resolution like 800x480.
Powerpoint now supports widescreen mode and I bet Keynote does too.
Just a thought, I don't think anybody would rely on a widescreen projector yet...
This board would sit on top of where the proto area is, maybe with stackable headers.
Would need some work to make it fit though:
That's less likely. The typeface would have to be stored in RAM, and it wouldn't be scalable. Plus, the kerning rules would have to be executed in real time.
-Phil
This might also be very useful for a game like chess...
I had a real problem coding chess with memory, but this kind of compression should save a ton of space...
In your new scheme, is the 4-color part also compressed?
-Phil
You might find some remnant garbage from the export from Keynote on Mac to PPT on Mac, and now to PPT on Windows.
Look forward to seeing what's possible with potentially better images.
Thanks,
Ken Gracey
I think the pictures of the PropBOE would look more impressive if you switched to a 4 color CAD model of the board - such as the one in the middle of this page
http://learn.parallax.com/node/78
The model would use the colors white, black, blue and gray, and these pictures could be higher resolution that the digital pictures because pixel data is now represented in just 2 bits.
@Phil: Awesomeness.
I went back and reread your explanation at the top of the page, and am very amazed at the level of detail you were able to squeeze out of 4 colors - great job.
Forrest
Looks like without sharp works better for this slide.
I think it's much better now. Especially the red ribbon on the top left corner and the symbol in the bottom right corner.
You can also kinda read the small text now (using some imagination maybe).
Slide46_PS2.bmp
Original:
It's also not so bad to just to use Zoom inside PowerPoint to make it the right size and then do a screen capture:
The attached archive contains the new Slide 17 demo program.
-Phil
Not much space left now, probably going to need Ariba's slimmed down FSRW to make it work...
BTW: For the pictures from post#239, one you have one loaded, you can just keep clicking where the "next" buttun is to cycle through them...
The differences may be very subtle, but once is blown up on a projector screen, I think the photoshop one will look significantly better...