Fudoh wrote:
Quote:
MiSTer has an interesting pixel clock trick that might show promise for better frame rate conversion in a future device.
either I don't understand what he's writing or that's about the silliest text I've ever read to describe a workaround that isn't really a workaround in the first place.
What he describes has been done to frame lock output refresh rates since digital video transmission existed. Timing parameters remain to spec with just the refresh being locked to the input (or emu core in this case). This naturally adjusts the pixel clock slightly up or down depending on the target refresh rate.
So, yes, it's good that frame lock is available on MISTer, but what's the big deal?
I wouldn't call that mode framelock as frames get dropped/duplicated, even if it happens once in a hour (which also means that half of that time has at least 1/2 frame of latency). I recall MISTer having a true framelock mode (vsync_adjust=2) for at least some cores, but for some reason it's not documented on that page
orange808 wrote:
I hooked up an old Extron RGB unit that also reads signal information and it sees the refresh rate at 59.19Hz with the scaler enabled. The OSSC gets funny results. Signal information on the OSSC isn't always reliable, so it's my fault for trusting it.
OSSC's refresh rate information on the main screen is based on measurement data from video ADC which is not always accurate. FPGA provides an accurate measurement which can be checked from info screen (divide 27000000 by the reported number to get Hz).
Speaking of video ADCs, it'd be interesting to make a comparison between the chips in OSSC (TVP7002) and A1 (AD9984A). AD9984A was actually a candidate for OSSC when it was originally designed, but I ended with TVP7002 as it had CSC block and 3:1 input mux (the 3rd input wasn't used in the end, though).
FAQ
Search
Register
Login
