HDMI Tutorial for P2, please...

JonTitus

The 7-inch LCD works nicely with my P2 EVAL board and it displays the rotating colorful spirals. Now I want to do useful things such as display signal traces, ASCII characters, and other information. Could we please have a tutorial that explains how to create and use a buffer of data and how to send it to the HDMI display? The spiral-display code is difficult to understand. A few simple examples and explanations might help P2 programmers. Perhaps an HDMI object will be available soon? Cheers. --Jon

Rayman

There's Chip's old scope code... Maybe that can be adapted:
https://forums.parallax.com/discussion/170820/hdmi-4-channel-oscilloscope-demo/p1

But, HDMI and VGA are nearly identical under the hood. So any 640x480 VGA code you find can probably be made to work with HDMI...

evanh

Rayman wrote: »

... So any 640x480 VGA code you find can probably be made to work with HDMI...

Jon,
Note that mode. DVI/HDMI, direct from the prop2, needs the sysclock ten times faster than the same VGA mode. So, a 25 MHz VGA mode needs 250 MHz sysclock when sent via DVI signalling. There is some wiggle room for different modes but not a lot. The minimum data rate is spec'd at 250 MT/s, and the max is limited by the prop2 to somewhere between 300 MT/s and 350 MT/s.

Bending the rules also works in many cases. Particularly with reduced blanking timings.

iseries

Sound like HDMI is at the bleeding edge of the P2. Maybe we need a Click board or a Dazzler board that has the appropriate amount of memory and speed to do things like 1080p.

Then we can build our screen data and let the hardware do the work it was designed for.

Mike

whicker

Either that or use an inexpensive vga to hdmi or vga to display port cable.

rogloh

whicker wrote: »

Either that or use an inexpensive vga to hdmi or vga to display port cable.

Yes I found they work fairly well and are quite cheap. From the P2-EVAL I was able to get my 1080p VGA driver stuff going out to a Dell (DVI) monitor via a VGA-HDMI converter box and HDMI to DVI cable. It's an easy way instead of trying to get high resolutions directly via HDMI (which as mentioned above is limited to a 10:1 CPU to pixel clock ratio and pushes the P2 very hard).

iseries

That's so 70's. We're taking digital data and converting it to analog just so we can turn it into digital data again.

Why don't we take some of those FPGA's that were used to build the P2 and make them into an HDMI device that maybe can give us 4K.

Mike

evanh

To be honest, I'm quite okay with lower resolutions. It suits the memory limits better anyway. My biggest gripe is that 640x480 is the lowest resolution allowed.

TonyB_

evanh wrote: »

To be honest, I'm quite okay with lower resolutions. It suits the memory limits better anyway. My biggest gripe is that 640x480 is the lowest resolution allowed.

Pixel-repetition is part of the HDMI spec. It doesn't lower the HDMI clock but it does reduce the resolution. Some anyway, I don't know whether 320x240 would work with HDMI pixel-repetition and line-repetition.

evanh

640x360 would give the right 16:9 aspect. But to keep the dot clock at 25 MHz would need a lot of blanking or higher scan rates, and many displays probably won't recognise it.

Rayman

Here's the HDMI example from the docs. Maybe that could be adapted for this display...
Update: I hacked it for Parallax 800x480 LCD

JonTitus

Hello, Rayman. Thanks for your example.

1. Where in your example code does the data get taken from the buffer and sent to the display?
2. What does this portion of the code do?

'Bitmap
'
orgh   $1000 - 70   
file     "birds_16bpp.bmp"

Why do you subtract 70 from the $1000 address?
How does the "birds_16bpp.bmp" data get into the buffer?

Given your program I just want to try to put some bits, bytes, or words in the buffer to see what happens. What is the format for the 16bpp.bmp data, 16 MSB, 16 LSB, or other..?

Thanks. --Jon

evanh

That tacks the data file at the end of the assembled program, well with some blank space in between - the ORGH fills it out to $1000 - 70. They become a single large binary file that is then loaded into the prop2 as one. The -70 is there just to make the start of the bitmap a round number of $1000. There is some unneeded header in the first 70 bytes of BMP files.

The program then uses the streamer hardware to feed the bitmap data out to the VGA or HDMI pins. The CMOD and pin config determines which.

evanh

Streamer is managed with SETXFRQ and XINIT/XCONT/XZERO. And to read or write hubRAM the streamer needs the assistance of the hubRAM FIFO. The same FIFO that is used for hubexec. This is setup with RDFAST or WRFAST.

Note: Hubexec will automatically force a hidden RDFAST itself if you use it.

evanh

Amusingly, the old 640x400 @ 70 Hz comes out not bad on wide screens.

EDIT: And with a little reduced blanking it'll even do 75 Hz still on 25 MHz dot clock. Disappointingly, my old 16:10 aspect DVI monitor doesn't know the 75 Hz mode. Or even 72 Hz. Oh for the analogue days, when the syncs only had to be in range to get a picture.

evanh

Oh, wow! Both monitors are happy with quarter FHD: 960x540 @ 60 Hz. It needs the whole of hubRAM at 8 bpp but it fits and displays with notably reduced blanking and 350 MHz sysclock.

dgately

An interesting tutorial would be to show how in code, to place a pixel of a specific color at an x,y coordinate on either an HDMI or VGA display. Wouldn't that be a "core" function for teaching basic graphics that can be extended to create lines & more complex shapes? All examples so far seem to be at such a lower level than "mere mortals" like myself can use to display basic graphic items.

dgately

evanh

Roger has added drawing and fonts to his drivers, well at least the ones he was using for the hyperRAM development. I didn't try too hard to make use of them myself, I think there's quite a bit of reading to discover all the setting up.

EDIT: Rayman might have something too.

dgately

evanh wrote: »

Roger has added drawing and fonts to his drivers, well at least the ones he was using for the hyperRAM development. I didn't try too hard to make use of them myself, I think there's quite a bit of reading to discover all the setting up.

EDIT: Rayman might have something too.

Roger's code that I was testing did not do any drawing (maybe that wasn't the hyperRAM version), just text as far as I could tell.

rogloh

Well my driver code mainly just sets up a frame buffer to read from in any region and the driver outputs data from that buffer in the selected bit depth. You just need to put data into that buffer for drawing. For all those example posts I did with frame grabs I had just used quickly hacked up code for generating simple graphics test patterns but nothing like that was included in the driver. It's not too hard to find code on the Internet to plot pixels, lines, circles etc into memory buffers. A lot of the drawing algorithms are in available in C which you just need to translate into SPIN2 or native PASM2 if you want even higher performance.

I would have liked to add a simple graphics library to the driver, but until SPIN2 supports dead code elimination that is not really going anywhere as it would bloat too much to have a whole collection of uncalled methods linked into the driver all the time. Because the memory format changes you need to code several copies of some functions for the various bit depths etc.

TonyB_

evanh wrote: »

Oh, wow! Both monitors are happy with quarter FHD: 960x540 @ 60 Hz. It needs the whole of hubRAM at 8 bpp but it fits and displays with notably reduced blanking and 350 MHz sysclock.

Are they 1920x1080 monitors that repeat pixels automatically when given 960x540? Have you tried @ 50 Hz with ~ 300 MHz sysclock.

Rayman

Here's another example for the Parallax WVGA HDMI LCD.

It shows a 256 color indexed image using LUT (with offset fix)

Update: See three posts ahead for a better version of this Spin2 file.

Rayman

This 800x480 resolution works with my tiny projector too:
https://www.amazon.com/Projector-PVO-Portable-Cartoon-Interfaces/dp/B08B8DKYPS

Might be a good fit as the native resolution is actually lower than this...

evanh

720x480 and 800x480 and 848x480 all seem to not work properly for me:
- My cheapo widescreen TV I'm testing with just says "480p" in the display info when using anything higher than 640 across. I have no idea what it perceives the horizontal resolution is set to.
- My old DVI monitor just refuses to recognise anything above 640 across.

evanh

TonyB_ wrote: »

Are they 1920x1080 monitors that repeat pixels automatically when given 960x540? Have you tried @ 50 Hz with ~ 300 MHz sysclock.

They all have built-in scan converters between the external cable and the raw LCD so, theoretically, they all can do anything within bounds. But in reality it's all down to an arbitrary preset mode list.

Yep, 50 Hz with 300 MHz works .

Rayman

Here's a better version of the WVGA example from three posts ago.

Now with Spin2 to start assembly and removed assembly clock setting code.

250 MHz seems to be working for me, but maybe should be faster.

Coley

@Rayman
It doesn't work for me on the 7" Parallax screen but it does on my 4K monitor.
On the 7" Screen I get the occasional flicker of the image, I'd say 99% of the time the image is black.
I've experienced this with all your demos but all the Parallax ones (Spiral etc) are fine.

Rayman

@Coley Hmm... I'm doing this with the Parallax screen too...

You did change the basepin to match your setup, right?

I can't think of what else it could be, except maybe using too much power due to higher clock frequency...

I just did it on the P2 Eval board too (was using a different board). It does need two USB inputs to give it enough power if powering from the board...

dgately

rogloh wrote: »

Well my driver code mainly just sets up a frame buffer to read from in any region and the driver outputs data from that buffer in the selected bit depth. You just need to put data into that buffer for drawing. For all those example posts I did with frame grabs I had just used quickly hacked up code for generating simple graphics test patterns but nothing like that was included in the driver. It's not too hard to find code on the Internet to plot pixels, lines, circles etc into memory buffers. A lot of the drawing algorithms are in available in C which you just need to translate into SPIN2 or native PASM2 if you want even higher performance.

Yes, that's kind of what I thought. I really was just looking for that place in your demo code where I could plot a pixel (I admit, I'm quite at a loss in figuring that little bit out:-) Once I figure that out, I would create only the drawing functions, I needed for a particular project.

Just the boost I needed... Bresenham's line algorithm was helpful: https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm#Algorithm_for_integer_arithmetic

Coley

Rayman wrote: »

@Coley Hmm... I'm doing this with the Parallax screen too...

You did change the basepin to match your setup, right?

I can't think of what else it could be, except maybe using too much power due to higher clock frequency...

I just did it on the P2 Eval board too (was using a different board). It does need two USB inputs to give it enough power if powering from the board...

I'm pretty sure it's not power related, I've only had trouble with your demos so far ;-)
I've tried with various power supplies, with the same result.

My pin group is the same as yours (48), I know it's right because I've plugged into my monitor and it's fine.
This problem is more related to the 7" screen I think, maybe it's on the edge of it's tolerances.

I've been looking at differences in the code in a bid to understand how all the modes are set etc.

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

I'm interested in how this value is calculated, I've looked through the docs and it's not entirely clear to me how this works.

Can anyone shed some light on this for me please?

Rayman

Look in the docs under the streamer section for the definition...

Do you have a rev.a board?
These values changed between rev a and rev b as I recall...