Beginner questions about rogloh's p2videodrv
mpark
Posts: 1,305
in Propeller 2
Hi all. I'm slowly trying to learn how to use rogloh's p2videodrv (thread) and I have questions. Let's start with this:
- How does one determine an appropriate _clkmode and _clkfreq?
For example, in complexdemo.spin2 (from p2videodrv0_91b), I see
CLK108MHz = %1_000100_0000011010_1111_10_00 '(20MHz/5) * 27/1 = 108 MHz _clkmode = CLK108MHz ' setup a default clock _clkfreq = 108_000_000
but in P2_CharacterMapDemo.spin2 (from Quick Bytes) I see
_clkfreq = 252000000 ' initial clock rate (would be changed for a given video mode)
and in helloworld.spin2 (from p2textdriver0.93) I don't see _clkfreq or _clkmode at all!?
What's going on here?
Comments
From memory, sysclock frequency is set by the driver according to the screen-mode presets. Yes, very chaotic structures in the API.
I once wrote a wrapper routine that automated the building of a custom screen-mode structure according to a desired clkfreq, resolution and refresh. It'll be somewhat out of date now I suspect.
EDIT: I found this inserted into a more recent copy of the driver (p2videodrv.spin2), it might okay:
PUB computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor, vblank, hblank, hfp, hbp {{ So there is a total of four effective parameters to build complete HDMI timings from: 1 - sysclock frequency (p2freq) 2 - horzontal resolution (hres) 3 - vertical resolution (vres) 4 - vertical frequency (vfrq) Remaining timings are: (currently out of date, since there is now a bias toward a vblanking of 45) dotfrq (>= 25 MHz) = p2freq / 10 htot = hres + 80 hfp = 8 hsw = 64 hbp = 8 vtot = dotfrq / (htot * vfrq) vblank = vtot - vres vsw = 2 vfp = (vblank - vsw) / 2 vbp = vblank - vsw - vfp negative hsync and vsync both }} p2freq #>= 250_000_000 'minimum DVI link speed divisor := 10 'fixed ratio dot-clock, DVI hardware is locked to 10:1 vfreq #>= 10 'sane minimum hres &= $7f8 '8-bit range (x8) vres &= $7ff '11-bit range vblank := vres / 10 'kick-off with desired mid-range vblank vblank := 45 r := divisor * vfreq * (vres + vblank) 'htot = dotfreq / (vtot * vfreq) hblank := (p2freq + r/2) / r - hres 'hblank = htot - hres ' hblank := ((hblank + 4) & $fff8) #> 80 'bound to min 80 hblank, multiples of eight hblank := hblank #> 80 r := divisor * vfreq * (hres + hblank) 'vtot = dotfreq / (htot * vfreq) vblank := (p2freq + r/2) / r - vres 'vblank = vtot - vres vblank := 20 #> vblank <# 960 'bound blanking, possibly break vfreq ' hfp := ((hblank - 64) >> 1) & $7ff8 'multiples of eight hfp := (hblank - 64) >> 1 hbp := hblank - 64 - hfp long[timing][2] := hres >> 3 long[timing][2] |= (hfp & $7f) << 24 'hfp (bit31 high for positive sync) long[timing][2] |= (64 & $ff) << 16 'hs long[timing][2] |= (hbp & $ff) << 8 'hbp long[timing][5] := ((hfp << 1) & $ff00) 'hfp ' long[timing][5] |= ((64 >> 4) & $f0) 'hs long[timing][5] |= ((hbp >> 8) & $f) 'hbp r := ((vblank - 2) >> 1) <# $ff long[timing][3] := vres long[timing][3] |= r << 23 'vfp (bit31 high for positive sync) long[timing][3] |= 2 << 20 'vs r := (vblank - 2 - r) <# $1ff long[timing][3] |= r << 11 'vbp long[timing][0] := 0 'use auto-compute of clock mode long[timing][1] := p2freq ' long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor long[timing][4] := $0CCC_CCCC+1 'DVI TMDS encoding hardware is wired for 10:1 only long[timing][6] := 0 'Calculate final vertical scan frequency (in tenths of hertz) ' vblank := long[timing][3].[30..23] + 2 + long[timing][3].[19..11] ' r := (hres + 80) * (vres + vblank) 'htot * vtot ' r := (p2freq + r/2) / r 'vfreq = dotfreq / (htot * vtot) return timing@mpark, your confusion is probably related to some detritus left lying around in demo code that you have found or just a result of my own sloppiness. I believe these days that typically the final P2 clock frequency and mode is being setup by the choice of video mode using the values in the first two longs of the selected timing structure, unless you configure the value of the clock frequency as 0 (as given in the information and logic below). It is good practice however for an application to setup a default P2 startup clock frequency before this video initialization step happens so it doesn't take too long to boot if it just defaults to the RC clock initially.
' Optional PLL adjustment logic: ' This code attempts to be flexible in that you can choose to have this driver setup the P2 PLL ' for the pixel frequency setup and optional clock mode indicated in the timing structure, ' or leave the clock alone and have it configured elsewhere. ' ' Two longs are part of the timing structure: the new optional clock mode, and the new P2 frequency. ' These are used to determine what to do and one of these three cases will be handled: ' ' (a) If the new P2 frequency is 0 or equal to the current P2 clock frequency nothing will be changed. ' ' (b) If the new P2 frequency is non-zero and the clock mode is non-zero, then that clock mode and ' frequency will be used in a CLKSET operation called by this driver. ' ' (c) If the new P2 frequency is non-zero and the clock mode is 0, an attempt is made to auto-configure ' the PLL based on the specified new frequency. The crystal or input clock frequency are required to ' be specified as well as the tolerance in Hz. The closest PLL settings are computed based on these ' criteria and will be used in CLKSET. If the tolerance is not met then no PLL timing will be changed. ' Take that into consideration when setting up the tolerance and don't set values that are unachievable. newmode := long[timing][0] ' get new clock mode newfreq := long[timing][1] ' get desired frequency if newfreq and (clkfreq <> newfreq) if newmode == 0 newmode := computeClockMode(newfreq) if newmode CLKSET(newmode, newfreq) <snip>OK, thanks!
@rogloh, question about versions: in p2textdriver0.93.zip, both p2textdrv.spin2 and p2videodrv.spin2 are version 0.92b according to internal comments, which is confusing. Meanwhile, the P2 Character Map Demo (Quick Byte) contains p2videodrv.spin2 version 0.93b. I'm surprised to see it there but not in your "P2 DVI/VGA driver" thread. Is there some other place you're publishing your code?
Yeah it seems there was probably a missing one line version update in the files in version 0.93b (which I think was a simple VAR order change or something to get a newer flexspin build working again so I must have missed updating the lines in the file - my bad). The P2 Quick Byte one was probably something I'd given directly to VonSzarvas who did the Quick Byte demo when I provided him with some of the other graphics code he used. So it might have been changed locally in my tree but is not yet an official release but was just pending the next release. I'll have to see what exactly was different there.
UPDATE: Just checked the version in the Quick Byte. It does include a later bug fix I found in VGA output mode with incorrectly enabled parallel output pins colliding with the DAC pins in some special cases and it looks like this code also made it into a memory driver demo according to the version comment in the file. So for now best to use that latest named version you found in the Quick Byte or if encounter any problems with VGA and want a fix. I'll need to release this fix officially at some point in my P2 video driver thread. Still on my (long) list of things to do...
Thanks @rogloh. Sorry for the late reply.
Is there an example demonstrating how to get NTSC composite output with your driver?
There is probably something I wrote a while back that used composite, will just need to dig it up for you when I get a spare moment...stay tuned.
I found this old thing...it includes an older version of the video driver but hopefully gives you the basic idea of how to set it up. It can be setup for SVIDEO or Composite output depending on which initDisplay line you enable. If you want to use S-VIDEO you need to build a cable taking the signals from 2 P2 sequential pins (luma+chroma) from the base pin, while composite just uses the base pin.
I am still working on improvements to NTSC/PAL pixel and timing quality using Chip's computations which I also found elsewhere in my folders as another NTSC demo but that might confuse you as it is in a state of flux right now and adds lots of computations and debug stuff initially.
So see if this helps for now...
I have a version where I properly fixed the colorspace parameters (as good as they get, anyways). Rogers original ones were bad and Chip's parameters cause AGC issues in some devices. Will have to dig that out later.