VGA 1920x1080x4bpp @148.5MHz - Rock Stable and 240 chars x 135 lines :)
Cluso99
Posts: 18,069
Rock stable now 
The screen buffer uses 506.25KB of HUB RAM which is 1/2 screen, so it is duplicated.
(see post 21-22 Nov 2018 below)
The visible portion is smaller than 1920x1080 (1440x540) as currently there isn't enough time to setup the full width pixels, nor enough hub ram for the full pixel display. These can all be worked on as we are not at the silicon limits.
FWIW I have just reduced the visible pixels and increased the front & back porches. This is not the right way to do it.
After some time, the P2 is somewhat hot to the touch - no fan, no heatsink, ambiant ~25C
(jmg: please don't ask for temperature, fans, heatsinks, etc)
The screen buffer uses 506.25KB of HUB RAM which is 1/2 screen, so it is duplicated.
(see post 21-22 Nov 2018 below)
The visible portion is smaller than 1920x1080 (1440x540) as currently there isn't enough time to setup the full width pixels, nor enough hub ram for the full pixel display. These can all be worked on as we are not at the silicon limits.
FWIW I have just reduced the visible pixels and increased the front & back porches. This is not the right way to do it.
After some time, the P2 is somewhat hot to the touch - no fan, no heatsink, ambiant ~25C
(jmg: please don't ask for temperature, fans, heatsinks, etc)
Comments
We need to make a tile driver. Then, we could have instant text, as well as graphical windows made from tiles.
Was this demo 4 bits per pixel?
Hopefully there is also scope in the P2 for doing even more than 1080 including analog VGA@1920x1200 which happens to be the resolution of two of my 24 inch Dell monitors. I think the dot clock for that is about 193MHz or thereabouts (VESA) so it could require officially overclocking but you can always try to play about with the timings a bit.
I know there is insufficient space in internal hub RAM for full graphics framebuffer (perhaps external RAM still has a chance), but sprites and text modes would be rather good to have at this high res.
What happened to the shivers ? Did that have a software cure ?
Can ozpropdev duplicate his loss of picture issue is also fixed ?
I am using 150MHz 180MHz. As I said, moderately hot. After a number of minutes (perhaps more as I have been testing and then resetting so the chip etc may not have cooled properly) the display starts to quiver. Touching the chip cools it sufficiently as the quiver goes away almost immediately I touch the chip.
The streamer is flat out, and there is quite a lot of maths going on in another cog.
Now this problem. Here is the setup code for the sync & porches. I can center the screen top and bottom fine. I have adjusted to have the display full width but I only get around 2/3 width. Not sure what is happening. I am not out of hub ram. $753DF is last used and I have to <$7C000. Here is the streamer code... I've noticed we can use _ret_
rdfast ##w*h/128,##@video_buffer 'set rdfast to wrap on bitmap setxfrq ##fset 'set transfer frequency to xxMHz dirh #vsync 'make vsync pin output 'the next 4 lines may be commented out to bypass level scaling setcy ##intensity << 24 'r set colorspace for rgb setci ##intensity << 16 'g setcq ##intensity << 08 'b setcmod #%01_0_000_0 'enable colorspace conversion wrpin dacmode_s,#0 'enable dac modes in pins 0..3 wrpin dacmode_c,#1 wrpin dacmode_c,#2 wrpin dacmode_c,#3 setnib dira,#$f,#0 ' Field loop field mov x,#top_blanks call #blank mov x,##h 'set visible lines line call #hsync 'do horizontal sync xzero m_rf,#0 'visible line djnz x,#line 'another line? mov x,##bottom_blanks call #blank outnot #vsync 'sync on mov x,#sync_blanks call #blank outnot #vsync 'sync off jmp #field 'loop ' Subroutines blank call #hsync 'blank lines xcont m_vi,#0 djnz x,#blank ret hsync xcont m_bs,#0 'horizontal sync xcont m_sn,#1 xcont m_bv,#0 ret dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync is 123-ohm, 3.3V dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B are 75-ohm, 2.0V m_bs long $CF000000+before_sync m_sn long $CF000000+sync m_bv long $CF000000+before_visible m_vi long $CF000000+w 'visible m_rf long $6F000000+w '4bit RFLONG LUT x res 1 y res 1Do you notice any part of the chip is better/worse when touched ?
ozpropdev reported almost the opposite effect - maybe he can test this new code too ?
165MHz= doesnt work
168MHz=excellent, no shiver
180MHz=single pixel shiver
By single pixel shiver I mean that a vertical bar shows the edge to be varying by 1 pixel back and forth.
I have to say that the P2 is getting quite hot to touch after it's been running a while. I am hoping the properly packaged chips do a better job.
I am still not getting full screen width. I think the code should be generating color pixels to the edge of the display.
Monitor : Signal
Internal Interface Analog/Digital
Frequency Horizontal: 54.2-83.8KHz
Vertical: 49-75Hz
Sync Type Not Specified by Manufacturer
Resolution 1920 x 1080
I find this
http://hamsterworks.co.nz/mediawiki/index.php/VGA_timings
says
1920x1080x60 (aka 1080p) 148.50MHz /2200 H /1125 V
148.5M/2200 = 67500 Line scan, ans/1125 = 60 Hz Frame
( above Monitor tolerated H values are appx 67500 +/- 24% )
Did you try exactly 148.5MHz, which should have no sampling errors ?
Try changing this line of code.
Depending on the mode one or the other seems to help.
Change xzero m_rf,#0 'visible line to xcont m_rf,#0 'visible lineAcer X233H: 165MHz= doesnt work 168MHz=excellent, no shiver 180MHz=single pixel shiver Acer G246HL: similar results to above, but slightly off-screen to left Acer X233H#2: doesnt work (menu not wkg, VGA to laptop OK)jmg: 148.5MHz doesnt work
What visible raster does this have.
I've found the hi-res monitors can be a 'little too intelligent', and they look for a valid visible (non black) limit, to perform their centering and sampling calcs.
If you are feeding less than 1920 visible, that could throw things ?
I've also found pixels in the blanking time, can confuse LCDs intelligence sense, whereas CRTs simply ignore them (of course)
Sounding better - at least it works while meeting some spec. I see the V is out slightly there, with 1045L total , whilst the reference link says 1025L - I doubt that affects X-Lock, but you never can be certain...
Does Acer X233H#2 now work at 148.5 ? - strange two with the same model # differ ?
re: P2 chip temp. When the P2 is hot to the touch on top, what is the temp of the bottom of the board below the chip? I'm wondering if your particular board got a good solder connection from the chip ground pad to the PCB?
Chip seemed to indicate that his setup was not getting that hot when running at 180Mhz, and even wasn't bad at 250Mhz. I know he drilled out the hole in the PCB and loaded up a lot of solder into that connection.
Unlikely, as the main thermal path is to the large copper pad under the die. The plastic above the die makes little difference.
4 layer PCB should reduce the hot-spot temperatures significantly.
That suggests the monitor is not seeing a full raster, or decided it is different for some reason ?
Also when running the frequency vs temperature tests recently, we might have seen a bit of "frequency slippage" on the dmm. This occurred many seconds after the test started and we had been deliberately heating the chip by running at 350 MHz for many seconds, without fan. I'll revisit this and see what we can deduce. If the frequency slips, one would also expect current to drop correspondingly, and we'll watch this closely
To achieve that frequency (350 MHz), what value was used at the crystal or clock oscillator?
And the divisor and multiplier? What values were used?
Ah, so that's exactly on spec - great. No shivers, at any temperature ?
Does it work nicely on all Monitors you have ?
1920+88+44+148 = 2200
1080+4+5+36 = 1125
Did the change in V (from above) fix this ? Or did the H changes, around the porch settings, (same totals) fix this ?
You mean it slips at 350MHz ? Not really suprising, as the counters stop dividing properly as they heat up....
its a 12MHz osc like on all the P2D2s. I think it was
/1 divisor (works best at high freq)
* 29 to give 348MHz
However, I'll double check this because I was pretty sure I saw 350 not 348 MHz, and it would pay be to be sure. At the time, we were really just trying to heat things we didn't care exactly what frequency.
Another test idea for anyone that see's a temperature-related quiver...
Did you try disconnect and re-connect of the monitor, to force a readjust ?
If things are exactly lined up, and it locks to a native resolution, then the sampling tolerance over 1 H line of 2200 units, is 454ppm, or ±227ppm, which should be inside Xtal tolerances.
( Hopefully that latest 148.5MHz settings, shows no effects and it is well margined and aligned )
Now, imagine things are not quite lined up, and it selects some 'best match' sampling, it may be that it is more on one edge and now perhaps 50ppm of drift is enough ?
The oscillator is physically quite close to the P2 - do you have an exact part number for that ?
It'll be very good if you can confirm it latter.
When you say that a division by 1 works better, in order to achieve consistent results at high frequencies, is it due the fact you are using a clock oscillator, not a crystal?
Also, when you have time, please try multiplying by 27 and 28, while keeping the same basic division ratio (÷1).
It would be also interesting to verify what are the limits (divisor/multiplier) that could be achieved, if a crystal is used instead.
Henrique
Why would you expect a crystal to be any different, in Digital divider choices, from an Oscillator module ?
The VCO range & counter ability, is what sets the divider choices, and the Fin value, so the MHz matters, not if a Xtal is used.
There is likely some upper limit where the Xtal oscillator is unreliable starting, but that not a PLL Divider issue.
Using 2-color mode you need 256 kB for your FB and it will fit in P2 hub. Use good old Commodore/Atari/Amiga tricks - display list, attribute memory, reducing horizontal res while adding colors, doing HAM - my P1V retromachine uses al these kind of tricks.
This should make colorful (with some restriction) picture @ full HD mode possible without a tile driver.
This came from the early overclocking tests. I don't know why exactly, but we found we could push further with the /1 divider than the other divisor options. The /1 just let us push the furthest (372 MHz OK with coolant, 384 not). But everything is a bit marginal up there
Maybe the /1 just allows a lower division from the VCO ?
eg 372 MHz is /31 to get to 12MHz, which is right on a 5 bit threshold - lower PFD frequencies, mean higher dividers, and the carry chain in the counter will run out of time...
eg maybe 384MHz is ok, with a 48MHz Oscillator, as that only expects the counter to /8. ?
I'm not sure how much a reload counter speeds up with lower reloads ?
I vaguely remember you and JMG discussing adding extra inverters into the crystal/PLL circuits, for the purpose of slowing it down, after the test die came back from the shuttle run. I don't remember anything particular though.