TVs will generally handle down sampling, I don't recall seeing a "monitor" that does down sampling. The EDID is there to ensure the video card and monitor cooperate. You're using VGA, so the interface is approximate at best anyway.
On a screen with such a potential high density of tiles it may be a good idea to have a blinking cursor that alternates between two distinctive colors.
Yes, it'd be easy to do a "block cursor".
I may fall back to that if I can't figure out how to do an arrow...
Think I wanted to do something with the streamer that can't be done:
I tried to stick in some 4bpp cursor into the 2bpp stream.
Tried replacing some of the RFAST LUT XCONT instructions with IMMEDIATE LUT XCONT instructions.
But, the problem is getting rid of that data that RFAST was going to use...
I tried just doing RFLONG, but the issue seems to be that this doesn't wait for the streamer to catch up, it just grabs last thing on FIFO, which isn't the data I wanted to replace.
Chip recently reminded me of the rczl instruction.
This turns out to be really useful for doing this cursor, where I need to turn a 2bpp long into two 4bpp longs:
'convert one long of 2bpp data into two longs of 4bpp data
rdlong sx,ptrb '2bpp data
rep @.end1,#8
shl stile2,#2
rczl sx wcz
rczl stile2 'first long of 4bpp data
.end1
rep @.end2,#8
shl stile1,#2
rczl sx wcz
rczl stile1 'second long of 4bpp data
.end2
That could have been another SPLITx/MERGEx pair of instructions. There's lots of spare instruction space available for more of those.
If there were such an instruction, I could have made the scanline buffer as 4bpp instead of 2bpp. Would have been much nicer for integrating 4bpp graphics and made the cursor easier...
I could still do 4bpp by changing the font to be 4bpp, but I'd give up on the screen area that could be covered by graphics...
So, the two things that would have made this easier are:
1. This instruction that takes a 2bpp long and turns it into either the upper or lower 4bpp long.
2. A special xcont that doesn't do anything with the pixels, so can show cursor pixels instead.
(it might also be nice to have a RFWORD option for the RDFAST ⇢ LUT ⇢ Pins/DACs streamer modes. That would let me do 8x8 tiles more easily...)
I'm trying to replace data in the RdFast/xcont stream without issuing a new RdFast.
Seems you have to use data in the stream.
Maybe you can set the #pixels to use to 1, but you can't set it to 0
You are trying to switch between two bitstreams, on-the-fly, back and forth (perhaps forth and back do better applies), if possible, while using a single streamer, and, at the same time, achieving a one-pixel granularity?
Here's the issue...
I start a RDFAST to read in a new row of 2bpp pixels for a new horizontal line.
In the middle of this line I need to splice in 24 (could be 32) pixels of immediate 4bpp LUT data.
Would be nice if there were a fake xcont that would just not do anything with the RFLONG it gets.
I'd do that immediate data in it's place
But there isn't...
I got around this limitation, but it wasn't easy...
You've got an array of tile pointers that are indirectly referenced, right? Why can't you update the pointer tile with a copy of the original tile, with the pointer overlaid, then update the pointer to tiles to point to your cursor tile?
The problem is that the scanline buffer is 2bpp and the cursor data is 4bpp (has to be to show black and white on top of other two colors).
The solution was something like what potatohead is saying. But, it's a convoluted mess...
Finally had a chance to have a look through your 1080p tile driver code Rayman. I do like how you were able to get the colour changing per tile so quickly via the novel LUT sharing approach and dynamic palette updating. You are achieving under 1 instruction per coloured pixel (12 instructions/16 pixels) which is very fast and also required for the 148.5MHz pixel clock with a 297MHz P2. Any other classic scanline based renderers at this 2bpp depth probably would not be able to get so high because working with sequential 2 bit values from a long is generally slow and there is a lot of data manipulation needed for looking up colour tables. We'd need multiple COGs for that most likely as well. In fact I'd expect that using higher bit depths like 4 or 8 would probably be faster to translate. 2bpp is sort of nasty from a performance standpoint, but good for compatibility with the P1.
In my own driver, for the mouse cursor I found it was simplest to keep the scan line bit depth and cursor bit depth the same which worked well. Only real downside was that this did mean you needed to setup a different cursor sprite for each bit depth desired. I can see in your case given how the software works that it would be complex to render a sprite in a different bit depth if you want to use the streamer the way you do.
Just in case you still want to do this, this version has a FlexProp C main interface and more separated Spin2 drivers.
Compiles with latest version of FlexProp C (4.5.0).
I'm curious as to how one can use Spin drivers with Catalina...
Would you run Spin2Cpp on it and then include assembly as binary blob?
This just shows a blue screen, but the mouse works.
Comments
Got it.
So it is super consistent error per line. If it were me, I would move that around, like put it at blank, etc...
Perhaps that error could be better distributed.
The TV I'm using that VGA --> HDMI adapter on is actually only 720p native resolution, but doesn't complain about the 1080p signal.
But now, I think 480p and 1080p are de facto standards and universally accepted...
Next, I need to figure out how to add a mouse cursor.
Have a couple ideas, we'll see if any pan out...
For transparency you can use masked writes, so you'd need a sprite tile, the saved BG tile, and the tile written to the screen.
When the mouse moves from that grid coordinate, restore the original tile for the old grid location and repeat.
I may fall back to that if I can't figure out how to do an arrow...
Think I wanted to do something with the streamer that can't be done:
I tried to stick in some 4bpp cursor into the 2bpp stream.
Tried replacing some of the RFAST LUT XCONT instructions with IMMEDIATE LUT XCONT instructions.
But, the problem is getting rid of that data that RFAST was going to use...
I tried just doing RFLONG, but the issue seems to be that this doesn't wait for the streamer to catch up, it just grabs last thing on FIFO, which isn't the data I wanted to replace.
This turns out to be really useful for doing this cursor, where I need to turn a 2bpp long into two 4bpp longs:
'convert one long of 2bpp data into two longs of 4bpp data rdlong sx,ptrb '2bpp data rep @.end1,#8 shl stile2,#2 rczl sx wcz rczl stile2 'first long of 4bpp data .end1 rep @.end2,#8 shl stile1,#2 rczl sx wcz rczl stile1 'second long of 4bpp data .end2You can see it controlled by USB mouse here:
If you look close, there are still a couple of glitches to work out...
If there were such an instruction, I could have made the scanline buffer as 4bpp instead of 2bpp. Would have been much nicer for integrating 4bpp graphics and made the cursor easier...
I could still do 4bpp by changing the font to be 4bpp, but I'd give up on the screen area that could be covered by graphics...
So, the two things that would have made this easier are:
1. This instruction that takes a 2bpp long and turns it into either the upper or lower 4bpp long.
2. A special xcont that doesn't do anything with the pixels, so can show cursor pixels instead.
(it might also be nice to have a RFWORD option for the RDFAST ⇢ LUT ⇢ Pins/DACs streamer modes. That would let me do 8x8 tiles more easily...)
I don't see why an existing mode can't be used. You might need to explain what you want.
Seems you have to use data in the stream.
Maybe you can set the #pixels to use to 1, but you can't set it to 0
You are trying to switch between two bitstreams, on-the-fly, back and forth (perhaps forth and back do better applies), if possible, while using a single streamer, and, at the same time, achieving a one-pixel granularity?
Did I got it right?
A RDFAST can be reissued concurrently to an immediate XCONT by using RDFAST's non-blocking bit31 in the D operand.
Here's the issue...
I start a RDFAST to read in a new row of 2bpp pixels for a new horizontal line.
In the middle of this line I need to splice in 24 (could be 32) pixels of immediate 4bpp LUT data.
Would be nice if there were a fake xcont that would just not do anything with the RFLONG it gets.
I'd do that immediate data in it's place
But there isn't...
I got around this limitation, but it wasn't easy...
Way back early on, I tried a use case where mid scanline, the bpp got changed. It would be off timing wise. Chip fixed it.
Should be possible to do something like
2bpp
8bpp
2bpp
The streamer is double buffered for these kinds of things.
Then, just render a small bit into 8bpp where the pointer is.
The solution was something like what potatohead is saying. But, it's a convoluted mess...
If one wants a white one, I wonder what happens when a setdac command gets tossed in?
I have yet to try it, and can't where I am. Working with sound right now. Headphones only.
In my own driver, for the mouse cursor I found it was simplest to keep the scan line bit depth and cursor bit depth the same which worked well. Only real downside was that this did mean you needed to setup a different cursor sprite for each bit depth desired. I can see in your case given how the software works that it would be complex to render a sprite in a different bit depth if you want to use the streamer the way you do.
This looks interesting. I'd like to try it with Catalina, to run some of my graphics demos on the P2. A couple of dumb questions ...
1. What tool are you using to compile this demo? I can't get it to compile with any of the tools I have.
2. Where did you get the "p1_font.dat" file?
Thanks,
Ross.
I believe it’s the p1 rom font..
https://forums.parallax.com/discussion/171223/1080p-tiled-gui/p4
Thanks, @Rayman!
Compiles with latest version of FlexProp C (4.5.0).
I'm curious as to how one can use Spin drivers with Catalina...
Would you run Spin2Cpp on it and then include assembly as binary blob?
This just shows a blue screen, but the mouse works.
Presume you’re using Gary’s USB code to provide the mouse code (on an iPad so cannot look at your zip code)