1920 lines horizontal sampling/output for all inputs + aspect ratio controls

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).

@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.

@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.

@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.

@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.