VGA Graphics Shield: (Now Available!)
Rayman
Posts: 14,537
The VGA Graphics Shield is now available here:
http://www.rayslogic.com/Propeller/Products/VgaGraphics/VgaGraphics.htm
This is a new shield sitting on top of a Propeller Platform Express board.
Together, they give most of the features I wanted for the SDPC project:
Works directly with Propeller Platform Express, DNA, or other Propeller Platform boards but can be added to other Propeller setups with wires.
http://www.rayslogic.com/Propeller/Products/VgaGraphics/VgaGraphics.htm
This is a new shield sitting on top of a Propeller Platform Express board.
Together, they give most of the features I wanted for the SDPC project:
- True color VGA graphics (up to 800x480 at 24-bit color)
- Keyboard
- Mouse
- Stereo audio output
- Microphone
- Micro SD card
- USB power and programming
Works directly with Propeller Platform Express, DNA, or other Propeller Platform boards but can be added to other Propeller setups with wires.
1024 x 768 - 74K
1024 x 768 - 88K
1024 x 768 - 92K
1024 x 768 - 86K
Comments
Nice combination of features for a standalone computer/terminal.
The RTC board might also work in some of the QuickStart expansion boards that have an extra EEPROM socket.
Just have a couple more checks to do on these prototypes and then I'll do the order.
Then, it would be 2 weeks to get the boards and a few days to make some for sale.
So, I think 3 weeks is fairly realistic...
Here's a video of it showing how it can mimic VGA_Text_Demo with an 8x12 font (copied from VGA_HiRes_text) and also arbitrary text with an 8x16 font:
re is the propeller driving the VGA or another chip? Back of envelope that needs 800x600x3 = 1.4 megabytes.
Thread on DVI version is here BTW: http://forums.parallax.com/showthread.php/138121
Are these chips easy to solder?
(Hopefully, that's because I'm smart and not because I'm dumb
If you mean solder by hand, yes, it is a bit difficult. Took me 3 tries the first time...
Easier with stencil and oven, but still often needs rework.
On the other hand, it is the same exact package as Prop2. So, it might be good practice
How can I get one of your VGA shield boards and associated Propeller Platform Express board. I'm assuming it will work only with your propeller board. I currently have a Gangster Gadget Propeller Platform USB (that I used with your 16x32 6 port Adafruit RGB board shield) and a recently purchased Propeller Quickstart for use with OldBitCollector's new PMC256 BASIC interpretor board. Let me know any other accessories I would need (as I saw on your board there is an empty 8 pin DIP socket and Microphone placement).
Thanks,
Tim
But, it's going to take me a few more weeks to get these ready for sale...
This same code works with the DVI Graphics Shield that is already for sale though, in case you can't wait...
The VGA Shield will have some extras like kb, mouse, and audio amp though...
Tim
Because you are very smart!
Indeed, a quick search on google for this chip and VGA took me to .... rayslogic.com
I'm thinking ahead here. When I first got a touchscreen working I was very impressed with both the color depth and the resolution. But as I pushed things further I found limitations with the speed. There were three things where it was not fast enough to move data from an SD card to the display and where the propeller didn't have enough ram.
1) Decent fonts and updating a page of text rapidly
2) Windows elements - box corners, radio buttons, check boxes
3) Games such as pacman where blocks of graphics are moved around rapidly
The design of these chips led both myself and averagejoe to look at a 16 bit bus rather than an 8 bit bus, and with a 16 bit bus and two sram chips and some counters it was possible to dump data out to the display with one pixel in (I think) 5 pasm instructions.
Now that you have cracked the VGA solution it would be really nifty to do something similar with VGA. But ...l I don't think I could solder one of those chips.
So maybe there is some sort of breakout interface one could think about?
On your website you say
For dumping data it decreases the instructions by working in 16 bit mode rather than 8 bit mode. So the interface would be very similar - just 16 data lines instead of 8. I think there might be one or two extra control pins as well:
D0-D15
RS
RD
WR
CS
RESET
So that is 21 pins instead of the 12 you are using. Would there be room on the board to bring out these pins to a header?
If so, such an arrangement would be backwards compatible with 8080 8 bit mode. Just a few startup instructions that set 8 or 16 bit mode.
Attached is one schematic I have been thinking about. It uses less propeller pins than some of the other touchscreen designs. On the propeller side it is 13 propeller pins, and on the display side, the 21 pins above (interfaces to the 40 pin header standard that seems to be out there on a lot of ebay touchscreens, where the SPI touch interface, and the SPI SD interface are separate circuit blocks).
So propeller to sram is slower than using a 16 bit bus as it is an 8 bit bus, but I figured that the data transfer from propeller to sram is not so critical. For example, just once on startup you send all the pacman sprites, but then you send those sprites many times from the sram to the display as the sprites move around.
Your thoughts would be most appreciated.
I'd say the main reason I picked 8-bit is because the Prop only has 32 pins.
There's no question though that working with a 16-bit interface and in 16-bit color would be faster in many cases.
But for me, having more free Prop pins was more important.
One other thing to consider is if the graphics chip can actually deliver 24-bit color depth.
I think the ones in small displays can only do 18 at best, so you really don't lose anything going to 16-bit color.
Another thing is that what this is mainly about is being able to quickly display images from a PC.
24-bit color is the usual default mode for Windows bitmaps.
So, you'd either have to make sure you saved in the correct 16-bit format, or you'd lose time on the Prop side doing the conversion.
Shame the pixels are not square any more though.
I agree. That circuit I posted uses 13 propeller pins. Everything is a compromise. If only the propeller had more pins...
The touchscreen is 16 bits packed as RRRRRGGG GGGBBBBB
Given that circuit uses two ram chips, one could perhaps consider a circuit that uses three, and then you could do 24 bit color.
I wrote some pasm routines to convert standard .bmp into the packed 16 bit format. It is just some shifts and logical or's. So all the pictures I display are standard .bmps on an SD card. The limiting factor seems to be much more the SD card speed than the conversion speed. All that code is in the public domain.
This is all cutting edge stuff and great fun! Keep up the good work.
I'd like to encorporate a flash driver inside the display driver. 1-bit flash may not be a whole lot faster this way, but maybe 4-bit would be worth it.
8-bit (dual SQI) flash interface on the same 8-bit bus as the SSD1963 is my ultimate weapon for fast display.
That makes things a lot more complicated though.
I've managed to get the driver to handle a 1-bit per pixel variable pitch font (Arial).
It doesn't look too bad. But, when I compare to a 24-bit font, you can see the difference.
Here's a screen capture:
In the top left is the 1-bit font.
Along the right side is the 24-bit font.
It would be a pretty big effort to use the 24-bit font and I'm trying to decide if it's worth it...
I'd say that it would be. The general population has some things that they have "just gotten used to" -- and one of them is crisp text
One thing I wasn't sure would work is a mouse cursor. The SSD1963 doesn't include cursor support and I wasn't sure I'd be able to draw it on top of the screen without flicker...
Anyway, I found a couple tricks to make it work and can now do things like this little Paint app (kids tested it a little for me too):
I love how the SSD1963 can take care of all of the LCD timing and has the built-in frame buffer. But when I started playing with it (I'm reluctant to say "working with it" at this point), I discovered that it does have a lot of limitations. For example, although there are several bit-depths and/or formats available for sending data, they are pretty limited, especially if one wants to use reduced color depth. Of course, the 8-bit RGB serial mode is pretty nice (as it only needs 8 data pins and provides for full/24-bit color, at the expense of slowing down writing the buffer), but a lot of potentially useful (conceivable) "modes" aren't offered. Also, when driving a VGA/WVGA screen at high color depth, one has basically used up all the framebuffer and therefore one can't buffer another screen of info off screen to which one could rapidly switch. It'd be nice for users if Solomon Systech would release an enhanced version of the chip with at least twice the frame buffer memory (maybe pin-compatible, as there are no address lines). Nevertheless, this chip is what is available and it gets the job done in many, if not most, situations, and, as I recall, provides for higher resolution than some other companies' offerings. Moreover, the SSD1963 is starting to become kind of "mainstream," as a lot of products are using it now. And I'm glad to see that you're using it (or is the word "abusing" it beyond its design goals, ha-ha, since you also have a VGA option via another chip).
However, I've been wondering how things will play out with the Prop 2. Of course, the Prop 2 could still be used with the SSD1963, but that might not be the best option, depending on the application. For example, VGA driver boards are readily available for some screens, and the Prop 2 will excel at generating VGA signals. Moreover, with the Prop 2's in-cog color look-up table (CLUT), one could change every pixel of a certain color (or, more specifically, certain color index in the CLUT as there could be more than one index with the same color) in one frame update...without the need to redraw/recalculate anything. Probably that would be an advantage over the SSD1963. Of course, if one can redraw everything fast enough while using an SSD1963-based approach, then the user wouldn't see any difference, but that would make the code more complex and could eat up a lot of memory for screen data or drawing functions.
I suppose the most flexible solution is to have the frame buffer managed by the Prop 2 in an external SRAM/DRAM. That way, one could double-buffer, change among multiple screens, more easily use transparency or multiple layers and so on. Such could be done regardless of whether one was using the Prop 2's built-in VGA circuitry (with cog help, of course) to drive a VGA screen/board or using an SSD1963. In the latter case, though, having the tearing effect signal would seem highly desirable to avoid flicker if doing animation or any video. That is, one could still let the SSD1963 take care of LCD timing (if utilizing a screen with an RGB interface instead of a VGA board-screen combo), but the content in its built-in frame buffer would just (or mostly) be a copy of data in another framebuffer managed by the Prop 2 (i.e., hub RAM or external SRAM/DRAM), not taking into consideration any stuff drawn on-the-fly by the Prop 2. Of course, one could only utilize the SSD1963's frame buffer without any additional/separate Prop-2 managed buffering, but that has the above limitations.
When it comes to smaller screens (such as in the 5" to 8" range, typically WVGA (800x480)) that don't have driver boards built-in, if one doesn't want to drive them directly with the Prop/Prop 2 (due to not wanting to generate various LCD voltages or deal with the flex connector or whatever, apparently trivial stuff for Rayman, lol), one has to use an external driver board (or circuitry), such as a VGA driver board or something like an SSD1963-based driver board (like Rayman's), and the prices (and size) of such boards have basically equalized, though the VGA driver boards usually can also handle composite or component signals as well. Well, it's off-topic, but I've also been wondering which way people will be going: the VGA/Composite/Component route likely using a Prop 2-managed frame buffer or the driver chip w/frame buffer route (e.g., SSD1963) supplemented by another frame buffer. I suppose both will be used. But considering the Prop 2's circuitry that eases generation of VGA, I'd almost feel ashamed not to take advantage of it. Of course, if one is using a monitor with a built-in driver board, then its interface dictates the design and no design selection is needed. Anyway, for now with the current Prop, SSD1963-based solutions like Rayman's are quite effective (and now with cursor effects, too).
By the way, Rayman, any chance you'll be posting a video showing the cursor in action with the SSD1963? Perhaps someday. Regardless, I'm glad you've got it working satisfactorily in terms of smoothness/absence-of-flicker. Congratulations on coming up with some tricks. It's always facinating to see what you've come up with and thanks for sharing.
I too thought I'd need the TE signal to do this, but I found a better way: the Get_ScanLine command.
This is better for 2 reasons. First, I don't lose a Prop pin. Second, it tells me exactly what scanline it's on, not just when it gets to some certain line.
So, that's the main trick. Also, I have a quick cursor draw function, a ScreenToHub function and a HubToScreen funtion. All these pieces make it work very well...
Thanks for those specific details regarding your tricks. I intended to just casually ask; hope I didn't cut into any of your "trade secrets" (though you're so far ahead that any revealed trade secrets would leave people like me in the dust). And, certainly, I wholly trust you in your saying that the cursor movement is "rock solid" with "zero flicker." I can easily imagine the cursor smoothly gliding along (via your clever software); no video evidence would add to that. Thanks again for your comments. And Congrats again!
I ran into some problems with flicker on the mouse and would be interesting in hearing how you solved this. If the mouse cursor happens to move more than the width of the cursor itself (?16 pixels) then all you can do is erase it and redraw it. But that doesn't tend to look like flicker.
The problem is where it moves less than 16 pixels. Say you move it one pixel to the right. The simple code solution is to erase it and redraw it and that is what causes the flicker. Another way is to look at which pixels change. If the cursor is white (say) and it moves to the right, most of the pixels remain white. Only the ones on the edge change. So there is no need to erase and redraw those pixels that do not change.
The code becomes more complicated though as you have to test every pixel. I think there might be some xor solutions with the pixel and the background but I never really understood that part of gaming graphics when I was a kid. Must go back and re study it!
The problem I came up against (which may not apply in your case) is that writing individual pixels ends up slower than writing out tiles. Refreshing the mouse cursor one pixel at a time is too slow. In the 'olden days' usually some of the microprocessor ram was dedicated to video ram and so you could poke values into the ram and hence onto the screen very fast. I guess it comes back to the pipeline speed - how fast can you send data from the propeller to the display - esp wrt to serial vs 8 bit vs 16 bit pipeline.
What would be nice is if it were possible to offload some of these graphics functions (like xor and tile moves) somehow to the graphics chip, but I don't know if that would be possible. The gamers on this forum might be able to add something there.
BTW - brilliant Paint program. Keep up the good work!
1. Get new mouse position
2. Copy the screen area where the mouse will go to buffer in HUB
3. Draw cursor, pixel by pixel
4. Poll SSD1963's current output line until it is far from where want to draw
5. Paint over the mouse using data from that buffer in HUB
I look forward to the next update
What's the latest development on this VGA sheild. Is it ready for sale yet?
Tim
Bad news is that this is behind my earlier, more optomistic schedule.
Still, I hope to have some for sale in 2 weeks.