720p full color graphics with EVE3 GPU
Rayman
Posts: 14,641
Had previously gotten VGA resolution working with this adapter on the P2 Eval board:
http://forums.parallax.com/discussion/172283/ftdi-eve3-gpu-vga
It adds an EVE3 GPU chip with an ADV7125 to produce VGA output, now up to 720p resolution.
Now, it's putting out 720p resolution and looks pretty good.
The main trick was using a P2 pin as an NCO to drive EVE's clock input with the right frequency for monitors to accept the signal.
(the white wire in pic)
Also, had to cut some traces on the board to remove some interference on the color signals.
Appears all good now though.
Figured out that the sync signals need a stronger driver that what I have now, but seems to be OK anyway.
Wanted to do fullscreen image, but problem there is that a 720p image doesn't fit in EVE's memory in 16bpp format...
http://forums.parallax.com/discussion/172283/ftdi-eve3-gpu-vga
It adds an EVE3 GPU chip with an ADV7125 to produce VGA output, now up to 720p resolution.
Now, it's putting out 720p resolution and looks pretty good.
The main trick was using a P2 pin as an NCO to drive EVE's clock input with the right frequency for monitors to accept the signal.
(the white wire in pic)
Also, had to cut some traces on the board to remove some interference on the color signals.
Appears all good now though.
Figured out that the sync signals need a stronger driver that what I have now, but seems to be OK anyway.
Wanted to do fullscreen image, but problem there is that a 720p image doesn't fit in EVE's memory in 16bpp format...
4032 x 3024 - 2M
3024 x 4032 - 3M
Comments
Was thinking that PNG was always 24-bit color, but guess doesn't have to be...
PNGs can be anywhere from 1 (paletted) to 64 bit (!) true color
I thought it was just a compilation of the image data needed.
But, it's actually a stream of coprocessor commands that loads the images and also defines the "handles" that make using the images easy.
Was able to create my own program to create these assets (mostly because I couldn't get the Gameduino version to run on my PC).
Anyway, after you load up the assets file from uSD or Plan9, this is all the code you need to create the display below. The assets file contains the info and data from the images.
void loop() { //Set background to dark blue ClearColorRGB(10, 10, 50); Clear(); //show some bitmaps Begin(BITMAPS); Vertex2ii3(80, 80, flowersH_HANDLE); Send_CMD(VERTEX_TRANSLATE_X(700 << 4)); Vertex2ii3(0, 380, springH_HANDLE); //execute display list and start a new one swap(); }One complication with 720p resolution is the Vertex2ii commands being limited to 511 in x and y.
But, see above how to use the Vertex_Translate_X command to work around that.
Won't need a jumper anymore for the NCO clock on EVE.
Also, has a more powerful driver on the sync signals. Copied from the reference circuit.
Added ferrite beads to the RGB signals, also from the reference circuit.
Adds a USB connector, uSD connector, Nunchuck I2C connector.
The EVE audio on the first version didn't work well at all.
This one copies from the reference appnote, so should work.
Using custom fonts can be tricky, but I've added font option to my version of the Gameduino asset builder that make it easy.
See below for program that generated this output.
This is something that took me a while to figure out.
Simple once you know how though...
This is the video from the Gameduino example video1.ino
One can use the Eve Asset Builder to make one's own videos that would work.
I have been using this Spin2 SPI driver up to now.
Worked fine, but only had a burst bitrate of ~1.5 MHz with 297 MHz P2 clock.
This new .c version brings that up to 6.5 MHz, probably due to optimization and not so much being in C. But, since the rest of the code is in C, made sense to adapt.
Need this for video and also more complex graphics.
EVE can go up to 30 MHz though. It appears I'm going to need to use a cog with an assembly driver to get there.
So, I guess I'll make an option to either use this cogless version or use a faster one that needs its own cog.
This uses the sorta fake class feature of FlexProp C.
So, I call use it like:
void SPI_Write(unsigned char c) {//send byte over spi SPI.WRITE8(FT800_MOSI, FT800_CLK, c & 0xFF); }Got the button, toggle switch, and slider working so far...
Getting the keys to work took some math, but you can see here how the individual key changes color when clicked on.
The dial and scroll bars also interact with the mouse.
I've attached the C code that defines everything on the screen.
It just populates a bunch of structures that the "panels" interface uses to draw the screen.
I bet you could make a much better GPU with the P2. You could call it a PEVE.
But, my sense is that if you tried that on 720p, you'd wind up using all the cogs for graphics.
It'd be interesting to see somebody try.
I saw @ozpropdev try it a long time ago, but didn't seem to work as he wanted...
https://forums.parallax.com/discussion/166017/bufferless-text-video-mode
My last thought on this was to try to process the display list into hubexec code for each scanline.
It might work, but the overriding fact is that graphics ram is limited to 512kB at most whereas EVE4 has 1MB of dedicated RAM that is now expandable by up to 32 MB 256 MB by it's QPI flash interface.
I am hoping we will have qpi on the P2 soon too, but there is already HyperRAM that can do 350MB/sec, which is way better than QPI anyways. A pair of them is enough to do double buffered 1080p.
On the P1 Chip had a 1600x1200 mode that used only 6 cogs. Now that cogs are WAY faster, I don't know why it would need even half that many.
Compared to P1, when generating video at 1600x1200 the P2 streamer can easily support this with a single COG now when outputting analog video in a simple bitmap mode. The main issue is how you are generating the video and how much of it it is stored. If it is some type of sprite driver, you could still need extra COGs to partition the workload over more than one scan line, and if it is frame buffer based you may require an additional single COG for external memory if it won't fit in hub RAM. That part is going to be system dependent on what you are intending to do. At 324MHz using my driver you should be able to do monochrome text at 1600x1200 with a single COG but I am writing pixel data back into HUB per scan line to be compatible with my own graphics format but a dedicated driver just designed for doing colour text mode alone could certainly do better than that.
Of course on some future P2/P3 if that ever happened it would be great to have more HW support for higher HDMI serializing speeds so that pixel clocks > ~35MHz could be realized using HDMI on that upgraded system.
Bad news is that I found an error in my board design.
I had the CSn signal of the flash chip tied high for some reason...
Had to run a jumper to an unconnected pin on the EVE chip.
Fortunately, that was possible due to wettable flanks on the chip.
Also, I thought the support for 256 MB of flash was a typo.
Thought it meant 256 Mbit. But, looks like it really is 256 MB, even though these don't exist yet....
EVE works, audio works. USB and uSD work. Just a few layout errors to fix. Next version should fix everything.
Made one with EVE4 chip, but that isn't working out. Turns out the EVE4 has a second PLL for the pixel clock that isn't perfectly synced with the NCO clock. That pretty much kills any chance of using EVE4 for this, I think.
Tried it with a few different TVs and all work with my VGA to HDMI adapter.
There is a slight horizontal artifact in 720p mode that I think is due to the ADV7125 being only the 50 MHz type. Got some 140 MHz types coming that will hopefully fix that.
I'd have to edit the "level" array to make it look actually playable...
Still, gives an idea of what can be done fairly easily...
Taking the Kenney example to the next level (literally
)...
The kenney website has a ton of tiles: https://www.kenney.nl/assets
Scaled them down from 70x70 to 40x40 for this testing. Not 100% sure this is the right size or not yet...
Can now use Ogmo to design levels. Screenshots are one I'm testing out.
Can now use the left joystick of a Wii Classic Controller Pro to move the player around.
But, the player is not connected to the map yet in any way...