Changes in january version :
- ASCAL : Fixed rightmost line for some input resolutions (C64, Minimig)
- ASCAL : Fixed downscaling offset
- ASCAL : Half-frame updates of interleaved vided (50-60Hz instead of 25-30Hz output)
- ASCAL : Fixed image properties header writes. Updated content. Change endianness.
- ASCAL : removed debug.
- HDMI_PLL_ADJ : Support updates of multiplier registerChanges in current version :
- ASCAL : Support shorter horizontal blanking, use DE instead of HS (screen_rotate for arcades)
- HDMI_PLL_ADJ : Updated.What remains to do:
- More non-regression tests.
- Low lag mode. Again.
- I have tried some tweaks in the phase and to rounding, for better image quality, but the results are not really convincing.Notes:
- I have moved all image sizing code from ASCAL to HDMI_PLL_ADJ. They must be updated together. The o_lltune signal must be connected in sys_top.v for the low-lag mode to work.
- Various off-by-one and pipelining bugs triggered the extra line on the right on AMIGA and C64.
- The low lag mode stilll uses the older method (The version with exact serlai multiplier/divider is temperamental).
The Altera PLL reacts nicely to continuous small adjustments, there is IMHO no need of an external component.
All attempts of slow transitions for seamless mode changes have failed with my screen, but, as reported by paulbnl :
paulbnl wrote:I have done some tweaking on the minimum off_v & ofp_v values on lines 126,128 of pll_hdmi_adj.vhd and with off_v at 8 and ofp_v at 7 both my TV and monitor don't lose sync when loading a rom.
...in the SNES thread, some screens may better support slow changes (I can add an input to pll_adj for a slow mode).
- Half frame refresh now uses independent triple-buffer pointers for half frames in interlaced mode. Each output image is composed
from the latest two completed input half-fields.
- The image properties header insertion was fixed and storage format was changed to ease access from the ARM side (endianness).
- The problem with screen_rotate was principally the horizontal sync duration from screen_rotate.v: 4 cycles.
Pixels are pushed in a shift register then copied to a buffer 128 bits at a time.
At the end of each line, pixels still in the shift register need to be copied as well, which can take a few additional cycles (up to 6 cycles actually to shift out). The worst case is when these stray pixels need a new burst to the Avalon bus.
Because of the asynchronous clocks between Avalon and input video, some delay is put between consecutive writes to allow proper resynchronisation. And then counters are reset to prepare for the next line. And then a divider calculates the vertical phase for downscaling...
I have optimised that part, but it still needs more than 4 cycles. So screen_rotate need to be changed.
(btw, screen_rotate has a 2 cycles offset between pixel data and the HS/VS/DE signals and the first line is shorter by one clock cycle)