I just figured out that can do 1280x768 with 80 MHz pixel clock and my monitor will take it.
This looks a lot better because it's a widescreen monitor, and the stretching isn't so obvious.
Unfortunately, I can't unroll the main loop for showing the cursor cause run out of cog ram.
But, I'm fairly confident that either a better programmer or a 160 MHz P2 would let it work...
I just figured out that can do 1280x768 with 80 MHz pixel clock and my monitor will take it.
This looks a lot better because it's a widescreen monitor, and the stretching isn't so obvious.
Unfortunately, I can't unroll the main loop for showing the cursor cause run out of cog ram.
But, I'm fairly confident that either a better programmer or a 160 MHz P2 would let it work...
I'm not quite following - can the P2 80MHz FPGA do 1280 x 768 , or is that what the Monitor can accept, but P2 does not quite manage ?
There are two main screen buffers.
one is the 2bpp pixel buffer at 1024*768/4 bytes
The other is a tile color array, one nibble for every 16*16 pixel tile.
I'm sure P2 at 80 MHz can do 1280x768, just not with the cursor spliced in, like I'm doing here.
I could revert to a block cursor... On the fence on this one...
...
I'm sure P2 at 80 MHz can do 1280x768, just not with the cursor spliced in, like I'm doing here.
How close is it to reaching 1280 ?
I wonder if it makes sense to do some overclocking releases, that go a little above 80MHz where designs dictate a clock speed.
Probably on selected FPGA boards only ?
If I'm seeing it right, it lets you have a variable like say, "nNibble", that you can increment beyond 7. So, it lets you index a block of cog ram as nibbles.
This is useful here as each horizontal line has an array of nibbles, one for every 16 horizontal bits.
The way this driver works is that with every 16 horizontal bits the xcont destination is modified to select between 1 of 16 sets of colors by setting the LUT offset.
Anyway, with a few more MIPS and this instruction, I could roll up the video loop and make it work for higher resolutions....
If I'm seeing it right, it lets you have a variable like say, "nNibble", that you can increment beyond 7. So, it lets you index a block of cog ram as nibbles.
This is useful here as each horizontal line has an array of nibbles, one for every 16 horizontal bits.
The way this driver works is that with every 16 horizontal bits the xcont destination is modified to select between 1 of 16 sets of colors by setting the LUT offset.
Anyway, with a few more MIPS and this instruction, I could roll up the video loop and make it work for higher resolutions....
Can you write the maths of what it does ?
Is it like a variant of INCMOD ?
hehe, oops, when you said " this new instruction might help me roll up the video loop"
I thought you proposed a new instruction, rather than referencing a recently added instruction.
Very interesting project. I can not wait for the Prop 2, as I can not afford an FPGA board. Good to see that there will already be a lot of things done for the Prop 2 before we ever see it in person.
Well, since you appear to like "iso" (30 and 45 degree repeated patterns),
Perhaps an image from the GDSII viewer thread (adjusted to the correct angle) might be meaningful
Was just thinking that for 1080p, we'd have to do 1bpp.
In that case, might want to see about a 1bpp base with 2bpp and 4bpp tiles optionally spliced in...
If you look at this gui screen, it's almost all 1bpp except for things like the button borders:
It's been a struggle, but I finally got the 4bpp cursor working on top of a 2bpp screen buffer. It was going horribly wrong at the edges of the screen previously...
I've also integrated garryj's cursor code so an attached USB mouse moves the cursor.
Still wondering if a 1bpp screen buffer (perhaps with optional 2bpp tiles) might be better so as to allow higher resolutions... But, the current 80 MHz streamer limit doesn't allow for higher resolutions anyway, so will have to put that off...
Bufferless display (Like P1) is also an option, but that would eat up cogs. We do have a lot of cogs though...
I fixed the cursor so it now leaves a shadow. It's subtle effect, but I like it.
BTW: This resolution is actually XGA (1024x768) even though the filenames say 640x480...
I know it may be an old topic but I'd finally like to work a bit on the P2 hardware (BeMicro Board). On which board does this nice code work ? Are there any hw DACs ? or how does it work ? could you spell it to me ? thx !
I believe it does have a few hardware dacs connected to the VGA ports.
As I recall, I'm using P0...P3, which are somehow connected to DAC chips on the P123 board and then to one of the VGA connectors...
Comments
I just figured out that can do 1280x768 with 80 MHz pixel clock and my monitor will take it.
This looks a lot better because it's a widescreen monitor, and the stretching isn't so obvious.
Unfortunately, I can't unroll the main loop for showing the cursor cause run out of cog ram.
But, I'm fairly confident that either a better programmer or a 160 MHz P2 would let it work...
So good, in fact, that I tried to click the button when viewing the image.
ALTGN D,{#}S
Might be close...
I'm not quite following - can the P2 80MHz FPGA do 1280 x 768 , or is that what the Monitor can accept, but P2 does not quite manage ?
There are two main screen buffers.
one is the 2bpp pixel buffer at 1024*768/4 bytes
The other is a tile color array, one nibble for every 16*16 pixel tile.
I'm sure P2 at 80 MHz can do 1280x768, just not with the cursor spliced in, like I'm doing here.
I could revert to a block cursor... On the fence on this one...
I wonder if it makes sense to do some overclocking releases, that go a little above 80MHz where designs dictate a clock speed.
Probably on selected FPGA boards only ?
What exactly does that do, and how close is it to existing opcodes...?
This is useful here as each horizontal line has an array of nibbles, one for every 16 horizontal bits.
The way this driver works is that with every 16 horizontal bits the xcont destination is modified to select between 1 of 16 sets of colors by setting the LUT offset.
Anyway, with a few more MIPS and this instruction, I could roll up the video loop and make it work for higher resolutions....
Is it like a variant of INCMOD ?
https://docs.google.com/spreadsheets/d/1J-CyOON6QUvB8lMIlAMlrru7dpWtL8XInvHiAxBwStI/edit#gid=0
hehe, oops, when you said " this new instruction might help me roll up the video loop"
I thought you proposed a new instruction, rather than referencing a recently added instruction.
I always get hung up thinking about the background tile options...
Perhaps an image from the GDSII viewer thread (adjusted to the correct angle) might be meaningful
Was just thinking that for 1080p, we'd have to do 1bpp.
In that case, might want to see about a 1bpp base with 2bpp and 4bpp tiles optionally spliced in...
If you look at this gui screen, it's almost all 1bpp except for things like the button borders:
I've also integrated garryj's cursor code so an attached USB mouse moves the cursor.
Still wondering if a 1bpp screen buffer (perhaps with optional 2bpp tiles) might be better so as to allow higher resolutions... But, the current 80 MHz streamer limit doesn't allow for higher resolutions anyway, so will have to put that off...
Bufferless display (Like P1) is also an option, but that would eat up cogs. We do have a lot of cogs though...
BTW: This resolution is actually XGA (1024x768) even though the filenames say 640x480...
There are 16 possible sets of 4 colors each in 2bpp mode.
Using the second 8 sets to make a darkened version of first 8 to allow shadows.
This screen uses 5 of the 8 sets, leaving only three sets left.
Think that's enough. If not, will have to drop the shadows...
I believe it does have a few hardware dacs connected to the VGA ports.
As I recall, I'm using P0...P3, which are somehow connected to DAC chips on the P123 board and then to one of the VGA connectors...