1080p tile driver (P1 style)

2»

Comments

  • BTW: I have to thank rogloh for showing me how to do 297 MHz. I didn't realize you could set xdiv to 20 and then xmul to 297...
    Don't thank me, I'm not sure I started the trend. I might have stolen it from someone else, perhaps Cluso or Chip...LOL.
  • potatoheadpotatohead Posts: 10,117
    edited 2020-02-04 - 08:31:43
    [deleted]

    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.
  • It sounds like that monitor is 1680x1050.
  • It is, but I think most new monitors won't complain if given 1080p signal like this one does...

    The TV I'm using that VGA --> HDMI adapter on is actually only 720p native resolution, but doesn't complain about the 1080p signal.
  • 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.
  • That's a good point and I think it used to be that way.
    But now, I think 480p and 1080p are de facto standards and universally accepted...
  • I think this code is in a good place now, so I'll post it to the top post.

    Next, I need to figure out how to add a mouse cursor.
    Have a couple ideas, we'll see if any pan out...
  • For a mouse cursor you just need 1 definable tile that you update with each move, then assign that tile to whatever grid coordinate the cursor is in.

    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.
  • 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
    
  • evanhevanh Posts: 9,956
    edited 2020-02-08 - 01:09:56
    That could have been another SPLITx/MERGEx pair of instructions. There's lots of spare instruction space available for more of those.
  • RaymanRayman Posts: 11,349
    edited 2020-02-08 - 23:56:40
    I've got a graphical mouse cursor mostly working.
    You can see it controlled by USB mouse here:


    If you look close, there are still a couple of glitches to work out...
  • RaymanRayman Posts: 11,349
    edited 2020-02-10 - 17:27:10
    evanh wrote: »
    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...)
  • Rayman wrote: »
    2. A special xcont that doesn't do anything with the pixels, so can show cursor pixels instead.
    There's Imm -> Pins and also Imm -> LUT -> Pins. That's the sort of thing used for blanking time for example.

    (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.

  • 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
  • YanomaniYanomani Posts: 1,057
    edited 2020-02-10 - 22:34:04
    Perhaps I did understood what you intend to do...

    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?
  • evanhevanh Posts: 9,956
    edited 2020-02-10 - 22:41:49
    Rayman wrote: »
    I'm trying to replace data in the RdFast/xcont stream without issuing a new RdFast.
    Okay, I think you're asking the impossible there.

    A RDFAST can be reissued concurrently to an immediate XCONT by using RDFAST's non-blocking bit31 in the D operand.

  • RaymanRayman Posts: 11,349
    edited 2020-02-10 - 23:13:25
    It really just need 8 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?
  • Lack of unique colors for the pointer would be my guess.

    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 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...
  • Yeah, that's always the trouble with making a low bit depth pointer. We've just never had a quick overlay.

    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.

  • roglohrogloh Posts: 2,767
    edited 2020-02-11 - 05:55:28
    Rayman wrote: »
    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.
  • Hey @Rayman

    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.
  • RaymanRayman Posts: 11,349
    edited 2020-10-13 - 10:25:12
    I think it was Fastspin

    I believe it’s the p1 rom font..
  • Actually, I think the latest version of this is at the end of this thread:

    https://forums.parallax.com/discussion/171223/1080p-tiled-gui/p4
  • Rayman wrote: »
    Actually, I think the latest version of this is at the end of this thread:

    https://forums.parallax.com/discussion/171223/1080p-tiled-gui/p4

    Thanks, @Rayman!
Sign In or Register to comment.