m_rf long $70880000 + hdmi_base<<17 + 800 'visible rfbyte 8bpp LUT->DAC

rjo__

I'm writing a driver for a magnetic field tile sensor https://hackaday.io/project/18518-iteration-8/log/91551-a-third-high-speed-magnetic-imager-tile

I want to use Spin2 and the adorable Parallax 7" HDMI display. And I need a custom LUT All is good. I know how to write and save a custom LUT.

Rayman recently published his spin2 dvi driver --HDMI_WVGA_driver1b.spin2
forums.parallax.com/discussion/172518/wvga-hdmi-8bpp-graphics-driver-works-with-the-parallax-7-hdmi-lcd-in-spin2#latest

It is everything that I dream of... except I want the 8 bit values in the hub bitmap to refer to LUT address from which the streamer would read a long (rgb24) and put the value on the screen... I know it is possible. But for the life of me after a week of scratching, I can't figure it out.

I suspect that it all comes down to a single line of code, the one above from Rayman's code... but I really don't know.

Thanks

Rich

Rayman

Sounds like you want to display data that is in one cog's LUT? I guess this cog is also acquiring the data?

My first thought would be to do LUT sharing with another cog and have this new cog draw on the screen buffer.

But, would be easier if data do be drawn was stored in HUB. Then, any cog could could do the drawing...

Maybe I don't understand the problem, but seems like you just need to call rectangle or setpixel to draw on the screen with the color you want to represent the data...

rjo__

Rayman,

No the data is being generated and put into the hub bit map in sequential bytes.

The color written to the screen however is an RGB24 value stored as a long in the cog lut,

It is very similar to the graphical debug example ... "DEBUG_BITMAP_RGB24_Demo.spin2" which is part of the PNUT download.

I was able to write a custom lut for that debug example, load it up through the debugger and it worked fine. Except that the debug example is too slow. What was interesting is that the source image could be an 8 bit gray scale image. It would be saved as 24 bit but could be imported as an 8-bit gray scaled image.


Rich

Rayman

Ok, do you just need to change the color Lut? That should be easy to do.
The driver actually takes the lut address as a parameter.

If I remember right, that code actually switches the lut from that of the embedded bitmap to the custom colors after 5 seconds.

rogloh

@rjo__ The driver I posted if the first post of this thread can support HDMI output and 8bpp LUT based frame buffers with your own palette and all from one single COG:

https://forums.parallax.com/discussion/170676/p2-dvi-vga-driver

You can tweak the resolution to 800x480 for your display. I believe @dgately already had it working and this is the custom timing he used for that panel (in his text mode example below).

For the 8bpp LUT based graphics mode you need to setup a region in this mode and also pass it the palette address and frame buffer address. For 800x480@8bpp that should still fit in HUB RAM. You can then update your palette as needed and it will use this palette on each scan line of the region.

The complete documentation to do precisely what you want is not present so you'll need to experiment a bit. Also the beta driver might only have supported FastSpin (now FlexSPIN?). I do have an updated driver that I'm still putting together that supports Chip's SPIN2 and is intended to have somewhat nicer documentation and included the new HyperRAM stuff. It's been a while since I've worked on my video driver actually, but I'm intending to get back to it when I can. Been doing other things lately, trying to enjoy more of our freedoms instead, after the very long lockdown in Melbourne finally came to an end.

rjo__

Rayman,

Changing the lut doesn't quite do it. Because the streamer assumes the lut contains words representing 16 bit values and then decodes the words and puts it on the screen... somehow:)

in looking over all the various driver examples... it seems to boil down to that one line...telling the dacs what to do.

rogloh,

I have actually spent quite a bit of time trying to figure it from your driver...
I'm sure it is in there, but between you and Chip, it is a close race to the abstraction line...

I'll keep looking at it because it is really beautiful and incredibly well organized.


Thanks,

Rich

Ariba

rjo

The LUT colors are in 24bit, but they are shifted by 8 bits, so bit 31..8 hold the RBG values.

Andy

Rayman

The color LUT contains 24-bit colors arranged as RGBX quads (where X is don't care). So, it's four bytes of color. One byte each for red, green, and blue and one that doesn't matter...

rjo__

yes, I understand but either the streamer or the color space converter ior both are in the wrong mode...

Ariba

Why do you think so? - There is no mode with 16bit colors in LUT.

Do you see the bird in Raymans code with the right colors? If so then anything with the streamer and color converter is right. This picture uses 8 bit indexes into 24bit LUT colors.

Andy

rjo__

for example.
Ariba does this:

DAT
orgh
org
VideoOrg
                mov     ptrb,ptra
                sub     ptrb,##$400  'point to start of palette instead of start of pixels
                mov     x,#0
                rdfast  #0,ptrb         'load .bmp palette into lut
                rep     @.end,#$100
                rflong  y
                shl     y,#8
                wrlut   y,x
                add     x,#1
.end

But it needs to look like this:

                mov     ptrb,ptra
                sub     ptrb,##$400  'point to start of palette instead of start of pixels
                mov     x,#0
                
                rep     @.end,#$100
                mov    y,x
                mov    lut_temp, y
                shl      y, #8
                or lut_temp,y
                shl     y,#8
                or lut_temp,y
                wrlut   lut_temp,x
                add     x,#1
                mov    lut_temp, #0
.end

But in order for this to work there is a mode change somewhere that needs to be invoked.

in the graphical debugger it looks like this:
debug(`g `uhex_(byte[i+0] + byte[i+1] << 8 + byte[i+2] << 16 ))

Ariba

So your colors that you want to write into the LUT are organized as 3 byte fields, and you don't know how to write it to the 256 longs for the LUT?

> debug(`g `uhex_(byte[i+0] + byte[i+1] << 8 + byte[i+2] << 16 ))

Here you just read the single bytes and concatenate them to the first 24 bits of a long, you could also write:

debug(`g `uhex_(long[i] & $FFFFFF ))

because the P2 can read a long also from an unaligned address.

rjo__

am I or-ing when I should be adding?

y = %00000000 00000000 00000000 00000001
shl y,8 should be %00000000 00000000 00000001 00000000
and then "or" to give %00000000 00000000 00000001 00000001

I'm going to sleep on it:)

Thanks

rjo__

almost going to bed... I don't want to load the lut. I want to calculate it. For magnetic fields it is all about reds and blues. So there is logic to be added depending up the lut index. What we have been looking at would produce a gray scale lut. Which I can use for some of my other projects, but not this one.

Thanks again

Rich

evanh

rjo__ wrote: »

I don't want to load the lut. I want to calculate it.

Ah, I see. I've not tried to fill the LUT for colours mylse before but just a few posts back there is the comment about RGBX formatting. That'll mean your example code needs one more SHL y,#8

                rep     @.end,#$100
                mov    y,x
                shl      y, #8
                mov    lut_temp, y
                shl      y, #8
                or lut_temp,y
                shl     y,#8
                or lut_temp,y
                wrlut   lut_temp,x
                add     x,#1
                mov    lut_temp, #0
.end

evanh

More compact equivalent:

                mov     x,#0
                mov     lut_temp,#0
                
                rep     @.end,#$100
                setbyte  lut_temp, x, #1
                setbyte  lut_temp, x, #2
                setbyte  lut_temp, x, #3
                wrlut   lut_temp,x
                add     x,#1
.end

evanh

And with a revB added auto-increment feature:

                mov     ptra, #0
                mov     lut_temp, #0
                
                rep     @.end, #$100
                setbyte  lut_temp, ptra, #1
                setbyte  lut_temp, ptra, #2
                setbyte  lut_temp, ptra, #3
                wrlut   lut_temp, ptra++
.end

Rayman

Do you just need a grayscale palette? Is that what this is?

I posted a FLIR Lepton driver a couple weeks or so ago that had a few palettes like that you could use...

That's maybe sort of a similar thing...

Rayman

Here's a version of the WVGA 8bpp driver that switches to grayscale palette and draws the screen in a gradient.

rjo__

Exactly,

I had actual found setbyte in my old code and gotten it to work...and then wrote over an entire directory by mistake. What a clown show:)

Thanks,

Rich