I experimented with a VGA and a 2560x1440 monitor using a Propeller Tool's VGA examples and messing with timings in them . I managed to get this resolution but only if P2 clk frequency = pixel frequency. Any non-integer streamer divider = "input not supported". The jitter on sync signals? But then there is madness: i got the pixels at 290 MHz.
Using 1:1 clock means only 4 bpp can be used at this resolution and 16-bit PSRAM, but I can signal 2560x1440 and output 1280x1440 so the monitor will not blur these pixels. To be tested.
Nice. You'll find with VGA instead of HDMI you'll be able to get higher horizontal resolutions out of the P2 with PSRAM. You can still use an external VGA->HDMI adapter too if required and they are cheap and seem to work rather well IMO.
So how many request list items or separate window source changes can do you per scanline with 1080p50 and at what P2 speed are you running this? I'm guessing with reduced blanking you could run at around ~334 MHz or so at 50Hz refresh, still making 3 P2 clocks/pixel. If that's true you'd have 1920x3 = 5760 clocks per active portion which was previously enough for 15 source changes, or effectively 7 windows on a background, right? That took 4300-4600 clocks before so you should still have a small amount remaining for write bandwidth. That's the tradeoff you have there.
EDIT: Actually above I neglected to include the fact that you would need to read 1920 pixels vs 1024 before, so I guess there are another 896 clocks required, so maybe the number of active windows would have to reduce slightly to compensate for that if you want some write bandwidth remaining...
I should also look into whether my own video driver can work with my memory driver's request lists when it calls my PSRAM driver, as a possible option/extension to how it makes the external request. I can see this feature being useful if you can make a windowing GUI out of it, albeit with some restriction on the number of active windows per scan line.
This is still 336 MHz as the frequency is important for the player. My monitor doesn't like reduced blanking and I had to use CVT timings with pixel clock 141.5 MHz - setxfrq ##$35C07228. The pixel clock itself is high, but there is a lot of time in hblanks:
It seems this version can do the same list as 960x540 @ 4bit. The problem I have now with the list and windows is the memory for the lists. It is huge (at full HD it is near 300 KB) so I need to place it also in PSRAM.
Yeah a 300kB list is not a good use of HUB RAM If you can get it read from PSRAM for the same scan line in time that's great, although it's not as easy to manage being indirectly accessed. You'll need a request list to go modify the request list LOL.
There is another problem with the VGA. The voltage is too high. It should be up to 0.7 V, not 1 V. There is of course this color converter available, but this will reduce the color brightness levels from 256 to 192.
At 8 bpp however this is not a problem, so I will switch this converter on, but we can have a true color at 1024x576 or something like this. I will try to experiment with additional resistors.
You could possibly get it down to 0.5Vpp (which is a bit closer than 1Vp-p, albeit a little dim and require some brightness gain) by adding a series 75 ohm resistor (R1) out of the P2 pin, feeding into the normal 75 ohm load and with a parallel 150 ohm resistor (R2) to ground from the junction of the series resistor R1 and the load. This maintains the DAC source impedance at 75 ohms to reduce the effect of reflections at higher speeds etc.
Last night I tried to solve the general equation for a passive resistor network using a series R1 resistor and shunt R2 which would to keep the DAC impedance at 75 ohms and also drive the output at 0.7Vpp into the 75 ohm load from the original DAC level but I kept getting negative resistance results, so either I messed up badly with my math (could have, it was late) or it is actually unsolvable with such a passive resistive network. I was looking at that 123.75 3.3Vpp DAC mode though. Maybe I should retry again with the 2V DAC to see if that works.
I think the 600 ohm and 990 ohm DACs modes have too high an impedance to be usable in this case.
I wonder if a pi network of three resistors can solve this instead of just the two I had used? So R1 shunt from P2 DAC output, series R2, shunt R3 parallel to 75 ohm load.
I did this to my P1 demo board too. 1V VGA is an ancient history.
But there is a very simple solution in P2 land. A 3 cinch plugs with resistors in them, something about 100 Ohm. Then plug them into video outputs on AV board.
I just computed R1 series = 32.1 ohms and R2 shunt of 250.2 ohms with the 2V 75 ohm DAC, this certainly gives 75 ohms source impedance. So I think this works out to 0.7Vp-p into the load. The shunt follows the series resistor in my setup and is parallel to the load.
Comments
Crossover is around 30..40 degrees, die temperature.
...
Wow! Very impressive!
I experimented with a VGA and a 2560x1440 monitor using a Propeller Tool's VGA examples and messing with timings in them . I managed to get this resolution but only if P2 clk frequency = pixel frequency. Any non-integer streamer divider = "input not supported". The jitter on sync signals? But then there is madness: i got the pixels at 290 MHz.
Using 1:1 clock means only 4 bpp can be used at this resolution and 16-bit PSRAM, but I can signal 2560x1440 and output 1280x1440 so the monitor will not blur these pixels. To be tested.
I ported the driver to VGA - 1920x1080x50x8bpp. 16-bit PSRAM required. The picture is in reality sharp and good, YouTube destroyed the quality,
Amazing, Pik33!
Nice. You'll find with VGA instead of HDMI you'll be able to get higher horizontal resolutions out of the P2 with PSRAM. You can still use an external VGA->HDMI adapter too if required and they are cheap and seem to work rather well IMO.
So how many request list items or separate window source changes can do you per scanline with 1080p50 and at what P2 speed are you running this? I'm guessing with reduced blanking you could run at around ~334 MHz or so at 50Hz refresh, still making 3 P2 clocks/pixel. If that's true you'd have 1920x3 = 5760 clocks per active portion which was previously enough for 15 source changes, or effectively 7 windows on a background, right? That took 4300-4600 clocks before so you should still have a small amount remaining for write bandwidth. That's the tradeoff you have there.
EDIT: Actually above I neglected to include the fact that you would need to read 1920 pixels vs 1024 before, so I guess there are another 896 clocks required, so maybe the number of active windows would have to reduce slightly to compensate for that if you want some write bandwidth remaining...
I should also look into whether my own video driver can work with my memory driver's request lists when it calls my PSRAM driver, as a possible option/extension to how it makes the external request. I can see this feature being useful if you can make a windowing GUI out of it, albeit with some restriction on the number of active windows per scan line.
This is still 336 MHz as the frequency is important for the player. My monitor doesn't like reduced blanking and I had to use CVT timings with pixel clock 141.5 MHz - setxfrq ##$35C07228. The pixel clock itself is high, but there is a lot of time in hblanks:
It seems this version can do the same list as 960x540 @ 4bit. The problem I have now with the list and windows is the memory for the lists. It is huge (at full HD it is near 300 KB) so I need to place it also in PSRAM.
Yeah a 300kB list is not a good use of HUB RAM
If you can get it read from PSRAM for the same scan line in time that's great, although it's not as easy to manage being indirectly accessed. You'll need a request list to go modify the request list LOL.
There is another problem with the VGA. The voltage is too high. It should be up to 0.7 V, not 1 V. There is of course this color converter available, but this will reduce the color brightness levels from 256 to 192.
At 8 bpp however this is not a problem, so I will switch this converter on, but we can have a true color at 1024x576 or something like this. I will try to experiment with additional resistors.
You could possibly get it down to 0.5Vpp (which is a bit closer than 1Vp-p, albeit a little dim and require some brightness gain) by adding a series 75 ohm resistor (R1) out of the P2 pin, feeding into the normal 75 ohm load and with a parallel 150 ohm resistor (R2) to ground from the junction of the series resistor R1 and the load. This maintains the DAC source impedance at 75 ohms to reduce the effect of reflections at higher speeds etc.
Last night I tried to solve the general equation for a passive resistor network using a series R1 resistor and shunt R2 which would to keep the DAC impedance at 75 ohms and also drive the output at 0.7Vpp into the 75 ohm load from the original DAC level but I kept getting negative resistance results, so either I messed up badly with my math (could have, it was late) or it is actually unsolvable with such a passive resistive network. I was looking at that 123.75 3.3Vpp DAC mode though. Maybe I should retry again with the 2V DAC to see if that works.
I think the 600 ohm and 990 ohm DACs modes have too high an impedance to be usable in this case.
The 75 ohms is achieved by adding an internal shunt onto the 123.75 ohm dac.
There are some threads about this in P1-land, eg https://forums.parallax.com/discussion/comment/1101527#Comment_1101527
I wonder if a pi network of three resistors can solve this instead of just the two I had used? So R1 shunt from P2 DAC output, series R2, shunt R3 parallel to 75 ohm load.
R1 shunt of 90 ohms and R2 series of 23 ohms is mighty close
I did this to my P1 demo board too. 1V VGA is an ancient history.
But there is a very simple solution in P2 land. A 3 cinch plugs with resistors in them, something about 100 Ohm. Then plug them into video outputs on AV board.
I just computed R1 series = 32.1 ohms and R2 shunt of 250.2 ohms with the 2V 75 ohm DAC, this certainly gives 75 ohms source impedance. So I think this works out to 0.7Vp-p into the load. The shunt follows the series resistor in my setup and is parallel to the load.