P2 DVI/VGA driver
rogloh
Posts: 5,530
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.
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.
Comments
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.
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.
region could be used as hub address without clearing size.
With the fields swapped I think I can match it:
[/quote]
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...
(my post did take, wrong thread. Oh well, I'm leaving both. )
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?
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.
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.
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.
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 ....
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
Not having luck with the capture of vga via hdmi, so far.
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.
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.
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).
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.
Still doesn't make the capture card work tho
I may get another capture device from altronics.. failing that blackmagic