P2 DVI/VGA driver

rogloh

EDIT: Beta driver code now available below:

Original Post:

In preparation for the release of the source for my P2 DVI/VGA driver that we've been discussing in this thread:

http://forums.parallax.com/discussion/170601/all-pasm2-gurus-help-optimizing-a-text-driver-over-dvi#latest

I am providing some preliminary documentation for any feedback. The driver is now getting close to completion and I may be able to modify it slightly if there are obvious things to do that would fit in the remaining space left.

Not everything is currently implemented precisely as defined here yet but I am heading towards this target, so both the code and this documentation is still subject to change if any problems are found or if I make other alterations or add other features resulting from feedback.

Here's the current documentation. It's formatted as 80 column text so it can be printed out using fixed width fonts for easy reading offline (it's too long for a forum post so I had to post it in a zip file).

UPDATE:

Beta Release 0.8b is now available in the attached zip file. It's included documentation supersedes that in the original early driverdoc.zip originally posted here as there have been changes to some registers, to allow better control from high level languages and other optimizations, plus additional features.

UPDATE (1 July 2020):

Beta Release 0.9b is now available in the attached zip file. It only fixes a single bug that caused video timing issues depending on the state of port B input pins at startup time. No new features yet, they will come in the next full release.

UPDATE (2 July 2020):

Beta Release 0.91b is now available in the attached zip file. I missed the opportunity yesterday to include my second bug fix for the setCursor method and its flags argument handling. That is also now fixed in v0.91b.

UPDATE (15 February 2021):

Beta Release 0.92b is now available in the attached zip file. It includes a new text driver API which simplifies the setup for applications requiring single region text screens over DVI or VGA. The driver now works with PropTool instead of just flexprop/fastspin as it did before. New documentation is not included because it is not yet up to date (there are a few differences now related to reading external memory and the display structure format order, etc), and I'm still rewriting it. In the meantime you'll need to refer to the code itself rather than the prior released documentation if/when you locate discrepancies.

UPDATE (2 April 2021):
A problem was found by evanh with the text driver in recent FlexSpin compilers - the order of VAR and OBJ sections has now been changed to fix this. It should build again now. Tested with 5.3.1 of FlexSpin.

TonyB_

For consistency, would it be better for the region pointers to be right aligned to match the other memory address fields that start from bit 0?

rogloh

Well I had my reasons. I did it like that because thought it would be best to keep the low part for updating region sizes, while region link pointers may not need to change as much or all. In many cases the region size will be 9 bits or less allowing an optimization changing it with sets or setbyte in some cases for animations etc. If I had the region size left aligned I couldn't do this. But it's funny as I thought the same thing when I looked at it. Nice to be neat and tidy, isn't it.

AJL

rogloh wrote: »

Well I had my reasons. I did it like that because thought it would be best to keep the low part for updating region sizes, while region link pointers may not need to change as much or all. In many cases the region size will be 9 bits or less allowing an optimization changing it with sets or setbyte in some cases for animations etc. If I had the region size left aligned I couldn't do this. But it's funny as I thought the same thing when I looked at it. Nice to be neat and tidy, isn't it.

If you right align the pointer, and then use a setq muxq construct as standard, then you get arbitrary region size changes for a consistent instruction count and no need to test for a special 'optimised' case.
Probably overall smaller and faster code, although I haven't tried writing it.

rogloh

Well I am still considering changing the field placement for maintaining consistency, but I found it was simple for me the way it currently is designed.

Here's how I crack it open in the driver. When I need to read in a new region I use the current region register as a pointer to the next region (this is called when the region limit scan line count decrements and hits zero in the calling code - not shown). If I arrange the fields in the other way I think it takes more instructions but maybe I can be proved wrong. I get to shift down the next pointer into its place and test for zero in the same instruction which is nice.

Manipulating 12 bit quantities is not as simple as bytes, words, or 9 bit quantities, but the nibble instructions saved me.

newregion
            mov     palselect, defcolour    'set default black colour
            shr     region, #12 wz          'check for any more regions?
if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
if_z        mov     videomode, #nullmode
if_z        ret     wcz                     'and exit if no more regions

            setq    #12-1                   'read region parameters from hub
            rdlong  region, region   
            getnib  regionlimit, region, #2
            rolbyte regionlimit, region, #0
...

TonyB_

If region pointer right aligned:

newregion
            mov     palselect, defcolour    'set default black colour
            test    region, ptrmask  wz     'check for any more regions?
if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
if_z        mov     videomode, #nullmode
if_z        ret     wcz                     'and exit if no more regions

            setq    #12-1                   'read region parameters from hub
            rdlong  region, region   
            mov     regionlimit, region
            shr     regionlimit, #20
...
ptrmask     long    $000_FFFFF

region could be used as hub address without clearing size.

AJL

rogloh wrote: »

Well I am still considering changing the field placement for maintaining consistency, but I found it was simple for me the way it currently is designed.

Here's how I crack it open in the driver. When I need to read in a new region I use the current region register as a pointer to the next region (this is called when the region limit scan line count decrements and hits zero in the calling code - not shown). If I arrange the fields in the other way I think it takes more instructions but maybe I can be proved wrong. I get to shift down the next pointer into its place and test for zero in the same instruction which is nice.

Manipulating 12 bit quantities is not as simple as bytes, words, or 9 bit quantities, but the nibble instructions saved me.

newregion
            mov     palselect, defcolour    'set default black colour
            shr     region, #12 wz          'check for any more regions?
if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
if_z        mov     videomode, #nullmode
if_z        ret     wcz                     'and exit if no more regions

            setq    #12-1                   'read region parameters from hub
            rdlong  region, region   
            getnib  regionlimit, region, #2
            rolbyte regionlimit, region, #0
...

With the fields swapped I think I can match it:

newregion
            mov     palselect, defcolour    'set default black colour
            zerox    region, #19 wz          'clear region size, check for any more regions?
if_z        setnib  m_rf, #1, #4            'setup streamer for immediate data
if_z        setnib  m_rf, #7, #7            'setup streamer for immediate data
if_z        mov     videomode, #nullmode
if_z        ret     wcz                     'and exit if no more regions

            setq    #12-1                   'read region parameters from hub
            rdlong  region, region   
            getword  regionlimit, region, #1
            shr regionlimit, #4
...

[/quote]

rogloh

Hey I quite like your solution AJL to this with the zerox. It takes the same instructions as I have, while Tony_B's adds that overhead mask. If I used that mask elsewhere it would be okay, but I don't have/need that mask yet, but perhaps might one day. I generally don't mask off those upper pointer bits because I don't need to, and that's why I typically put extra data up there.

rogloh

Now that AJL showed an equivalently fast way to do the 12 region bits from the top, I think I'll change the code and documentation to maintain the consistency of pointers in the low part of all the longs. In any high level user code that is configuring the display region sizes/links, it is not that hard to mask and shift to get/set the data fields and having the pointer in the low part is still similarly useful at times, certainly for dereferencing pointers and traversing the linked list stuff anyway. The only minor potential benefit of my current way was for any PASM clients changing the size and there may not be that many cases where it helps too much, so I'll try to change it.

rogloh

Beta driver code is now available! Just pulled an all nighter to get this out. Check the first post. You will need FASTSPIN to build it, otherwise you'll have to extract the PASM component and wrap it yourselves.

I hope it works out as I need to sleep now so you're all on your own for a bit. Two demos are in the zip along with the main driver, plus documentation. Patch the VGA/TV pins according to your setup or use DVI if you are game...

potatohead

Awesome! Get your sleep. We are gonna play. Hope you know my productivity at work just tanked big time.

(my post did take, wrong thread. Oh well, I'm leaving both. )

ozpropdev

Got to see Roger demo this driver today, simply brilliant!
I already am thinking of all the cool stuff we can do with it.
Congrats Roger, a real work of art!

rogloh

Cheers Brian. It should come in handy...

cgracey

ozpropdev wrote: »

Got to see Roger demo this driver today, simply brilliant!
I already am thinking of all the cool stuff we can do with it.
Congrats Roger, a real work of art!

Roger, could you make a short video showing your driver in action?

rogloh

I will see if I can try to do that, Chip. Now I've caught up more sleep I am hoping to work more on it today and see if I can add anything more to the demo too.

Tubular

My J5create hdmi capture dongle doesn't like the P2's hdmi output

I'm going to pick up a VGA to HDMI converter from our wholesaler this arvo. Then we should be able to capture the higher res stuff too (hopefully)

rogloh

Given we render most data into external HUB memory it would be rather cool at some point with the P2 to develop a capture COG and pathway to extract the scan line information and somehow create a video file from that directly...though USB serial output to a PC will be a bottleneck. Maybe under clocking and writing data to SD card is another option. This will still be a lot slower than external real-time capture though (or just filming the screen with a phone which is obviously the simplest way, but has the lowest quality).

cgracey

Tubular wrote: »

My J5create hdmi capture dongle doesn't like the P2's hdmi output

I'm going to pick up a VGA to HDMI converter from our wholesaler this arvo. Then we should be able to capture the higher res stuff too (hopefully)

There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.

Tubular

Yeah we'll find it eventually. I hope its not too fussy about voltage levels being sent from the dacs. I suspect that its more to do with Sync etc though.

Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)

rogloh

Tubular wrote: »

Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)

Yeah the FleaFPGA Ohm had it's FPGA pins AC coupled with 0.1uF on each of the 8 HDMI pins IIRC. That worked ok for my devices at least, and adds some degree of galvanic isolation, though some voltage spikes could couple straight through.

cgracey wrote:

There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.

I hope so. Your latest 1.5k pullup method (which is my default in the driver) doesn't work on my Dell. I get a picture but some pixel colours are bad, it's colour dependent, though I did see it working okay yesterday on a Philips monitor that Tubular had. The BITDAC levels I tried failed completely on my setup. I believe I tried levels 0001_0000 up to 0111_0000 and nothing really worked. Not sure why it wouldn't unless the slew rate is affected somehow through the BITDAC, or there might be some additional ringing with those settings. I didn't scope it, I don't have the high end scope needed for the HDMI bandwidths.

cgracey

rogloh wrote: »

Tubular wrote: »

Remember the fleaohm had caps in series with the hdmi output, didn't it Roger? (ac coupled?)

Yeah the FleaFPGA Ohm had it's FPGA pins AC coupled with 0.1uF on each of the 8 HDMI pins IIRC. That worked ok for my devices at least, and adds some degree of galvanic isolation, though some voltage spikes could couple straight through.

cgracey wrote:

There must be a standard recipe for drive type/strength and sync positions, so that HDMI output will always work, without any problems.

I hope so. Your latest 1.5k pullup method (which is my default in the driver) doesn't work on my Dell. I get a picture but some pixel colours are bad, it's colour dependent, though I did see it working okay yesterday on a Philips monitor that Tubular had. The BITDAC levels I tried failed completely on my setup. I believe I tried levels 0001_0000 up to 0111_0000 and nothing really worked. Not sure why it wouldn't unless the slew rate is affected somehow through the BITDAC, or there might be some additional ringing with those settings. I didn't scope it, I don't have the high end scope needed for the HDMI bandwidths.

Maybe we just need to carefully match impedance with an external resistor on each pin.

rogloh

Actually when I retested just now with the BITDAC settings I do see a stable DVI picture, but all red and blue colours, no green at all. Would the BITDAC output be different somehow on the green output pins? I get a red/blue picture from 0011_0000 down to 0001_0000, but no green on the birds image.

When I go to 0100_0000 I get all green/yellow birds but no blue. Its like each channel needs its own separate bit DAC level ....

rogloh

This BIT DAC setting appears to work by centering the hi/lo voltages to the middle of the range. Not sure if that is good for current use though.

wrpin ##%10110_1011_0100_10_00000_0, a '123 ohm BITDAC for pins

Update:
This also worked for me too.
wrpin ##%10110_1010_0110_10_00000_0, a '123 ohm BITDAC for pins

This also worked on my Dell at the upper voltage end which is probably better for less current draw with CML.
wrpin ##%10110_1111_1100_10_00000_0, a '123 ohm BITDAC for pins

Tubular

I'll give those a try.

Not having luck with the capture of vga via hdmi, so far.

potatohead

Input impedance is supposed to be 100ohms. What is the impedance on the Eval Board?

At these pixel rates, ringing especially on a longer or marginal cable, could be a factor.

Also, I posted the Tektronix basic requirements on one of these threads. I do not fully understand them, but it appears minimum swing can be 100mV and as high as 3.3mV. That seems crazy, unless it is all triggering on zero crossings or something.

I just picked up an HDMI monitor. What's the risk of damage? I guess I am asking what we think allowable experimentation limits are. Anyone really know?

I also have a short, good quality cable. Figured that would not hurt.

Rayman

I'd wonder if it needs 5V on the 5V pin or maybe I2C comms for HDMI capture device to work...

rogloh

potatohead wrote: »

I just picked up an HDMI monitor. What's the risk of damage? I guess I am asking what we think allowable experimentation limits are. Anyone really know?

This may help you decide (excerpt from DVI 1.0 spec). The P2 pins are acting as the Transmitter. If the AVcc voltage on the equipment is 4V there could be issues. I don't think the P2 should hurt the monitor if it is only powered up to 3.3V, it would be the other way around, if anything, but spikes could be an issue.

rogloh

Rayman wrote: »

I'd wonder if it needs 5V on the 5V pin or maybe I2C comms for HDMI capture device to work...

It might want to see the 5V, we are not driving that, but it can be strapped on the breakout (best done via a small resistor first perhaps). I doubt it would need the I2C, that is more for determining the capabilities of the monitor from the P2 side (DDC stuff).

rogloh

Tubular wrote: »

I'll give those a try.

Not having luck with the capture of vga via hdmi, so far.

Don't worry if it doesn't work Tubular, I am heading off to get a tripod so I can try to film my screen without the jerky cam look. But I think basic VGA capture should work fine from the P2, there's not much different there. Try a real PC's VGA output to see if your new VGA to HDMI capture equipment setup works.

Tubular

Guess what... 1 kohm resistor makes my TCL work with HDMI (DVI?)

Still doesn't make the capture card work tho

I may get another capture device from altronics.. failing that blackmagic

Tubular

This is back on %%001001