August 22, 2017 at 3:46 PM #14644awe444Participant
Do you know whether 512-column PS2 games use different dot clock than usual 480i games (858 dots per line), or whether PS2 internally scales framebuffer width to usual 640/720 output
I investigated this a while back and measured the following dot clock rates for the PS2’s interlaced modes (assumes a 27MHz source crystal combined with observations from manually tuning the OSSC sample rate on appropriate pixel patterns):
512x480i : 686.4 dots/line = (27MHz * (2/5) / (4.5MHz / 286))
640x480i : 858.0 dots/line = (27MHz * (1/2) / (4.5MHz / 286))
For progressive mode however, both 512 and 640 width games are output in 800 dots/line (the 512 wide games get black borders on the sides).August 22, 2017 at 6:28 PM #14668
@Thomago: You can actually disable the “hidden” upsampling in 240p/288p/384p/480i/576i Line2x modes by enabling “AV3 interlace fix”. That way you can crank sampling rate to 2046 and still get a picture.
@paulb_nl: It’d need a fixed pair of PLL outputs, e.g. 2x for sampling and 5x for output. In theory, Cyclone IV PLLs could be configured dynamically with ALTPLL_RECONFIG, but it’s not very flexible in practice (if I recall right, you can only switch between pre-defined configurations).
@awe444: Are you sure native progressive mode games use 800 dots/line output? From what I could gather from an unofficial PS2 video mode doc, default parameters for DTV-480p indicate standard 858 dot output (sum HSVS and HS columns of SYNCH1 listing). For VESA 640×480 (VESA-1A), the number is spec-compliant 800, but it’d be a bit surprising if progressive scan games really use this mode.August 22, 2017 at 7:14 PM #14673paulb_nlParticipant
@marqs Doesn’t the OSSC use fixed PLLs for everything? If you would implement 5/2 for 480pX2 then it would work for both 640 and 720 sampling right? It would be great to be able to play 480p content without the monitor stretching it to 16:9.August 22, 2017 at 8:10 PM #14678AnonymousInactive
@marks: That works! However, H. samplerate = 2046 gave me a squished picture; with H. samplerate = 2288 (858/720*1920=2288) it looked as intended.
I tried that with a 480i signal. Without manual adjustments, my monitor is compatible to passthrough as well as Line2x and Line4x; with manual adjustments only Line2x mode worked. I’d really like to use Line4x mode, as it might enable “constructing” a crude 1280×960 output mode, which would display in 4:3.
Any ideas about that? I already tried stuff like enabling upsample2x and halving H. active to 960…August 23, 2017 at 12:56 AM #14685awe444Participant
@marqs yes, I can confirm the 800 dots/line value for 480p directly from observations with the OSSC. It was an RGsB signal and I was using “VESA” sampling setting on the OSSC at the time (not the “DTV” setting). Also worth noting that I was using the GSM forced mode with “VGA” in the label (as opposed to the mode with “HDTV” in the label). Hence it is quite possible there’s a 858-dots/line mode for 480p as well.August 25, 2017 at 11:45 PM #14773
Yeah, I’d guess all games that have native 480p support would use HDTV mode.August 31, 2017 at 12:36 PM #14853tcdevParticipant
@paulb_nl: In theory, Cyclone IV PLLs could be configured dynamically with ALTPLL_RECONFIG, but it’s not very flexible in practice (if I recall right, you can only switch between pre-defined configurations).
Not quite. You can configure all the parameters from the NIOS, however they don’t publish the algorithms used to generate those parameters given the desired inputs and outputs.
On a Cyclone V design we have a large number of PLL configurations – 30+ from last count – so I generated them all in the PLL wizard and then post-processed the .mif files to produce a series of arrays in C source for subsequent programming from the NIOS. Once you’ve got the QSYS and NIOS code working it’s pretty quick and painless to add another PLL configuration; in this case about 1 minute.
An earlier incarnation was based on Cyclone III and my colleague ‘reverse-engineered’ the algorithms to produce the – admittedly simpler – PLL parameters on-the-fly for arbitrary clock values. At that time I only had peripheral involvement with the project but AFAIK it was successful for every case they required/tested.
FWIW the above-mentioned designs are video boards that (amongst other functions) sample analogue RGB via the TVP7002 and drive digital video (DVI) out. That 7002 is a PITA, but then again my primary role was FPGA design and NIOS code and little to do with actually getting the video to work. At one stage – with the previous-gen hardware – I built my own cut-down version of the FPGA and was running both a Coco3 and Amiga on a VGA monitor. We had designs on producing a monster video converter for every system/configuration imaginable – there was an option to load composite video input connectors and it already had a triple frame buffer with clipping, scaling etc – but we were too busy with real work to do much about it.August 31, 2017 at 11:13 PM #14868
@tcdev: Yeah, storing relatively large arrays/.mif:s for mostly similar configurations is not optimal considering current memory limitations. Also, many of the desirable fractional ratios are not achievable with Cyclone PLLs (indicated by a PLL wizard warning), limiting benefits of fully dynamic configuration even if that was made available (e.g. via reversing) for Cyclone IV.
Out of interest, what made you select TVP7002 for your project? Did you try any of the alternative RGB video digitizers (which there are not too many publicly available)?September 1, 2017 at 4:40 AM #14871tcdevParticipant
@marqs: Yeah, storing relatively large arrays/.mif:s for mostly similar configurations is not optimal considering current memory limitations.
For Cyclone IV (not III as I previously mentioned, that was the other FPGA on the board), we had 26 bytes for each configuration, though it’s possible that could be optimised. Our NIOS code was stored in external flash (EPCS device IIRC) and ran from DDR, so no such memory limitations for us! For Cyclone V, each configuration requires 6x 32-bit values, so about the same. It probably (also) depends on the number of output clock’s you’re using…
Those design decisions were made by our client, not us (contract design engineers). That particular client was a component distributor and chose most of the silicon for us to use in the design, including the TVP7002. We have it all under NIOS control, so at least it’s trivial for us to tweak the registers.
- You must be logged in to reply to this topic.