Non-standard resolution: testers needed
pik33
Posts: 2,416
This is 1024x576 @ 49.86 Hz using a P2 at 319_220_550 Hz which is 180x Atari 8bit PAL or 45x Amiga PAL CPU frequency and also Atari 8-bit refresh rate.
My 32" 2560x1440 AOC Q3279VWFD8 works with these parameters; tomorrow I will try this on another 3 or 4 types of HDMI monitors I have at the university, but there are hundreds of them, so I want to know if such non-standard resolution can work on most of them, or only on a few.
This is of course PAL retrocomputing oriented test. For NTSC zone 960x540x60 is much more standard thing and should be usable on all or near all monitors.
CON
hdmi_base = 48 'must be a multiple of 8
_clkfreq = 319_220_550 'system clock frequency must be 250 MHz for HDMI
var
long line_buf_ptr
byte line_buf[64]
pub test1()| iii
repeat iii from 0 to 63
line_buf[iii]:=$AA
line_buf_ptr:=@line_buf
coginit(7,@hdmi, @line_buf_ptr)
repeat
iii:=iii
DAT org
hdmi setcmod #$100 'enable HDMI mode
drvl #7<<6 + hdmi_base 'enable HDMI pins
wrpin ##%001001<<8,#7<<6 + hdmi_base 'set 1k-ohm drive on HDMI pins
setxfrq ##$0CCCCCCC+1 'set streamer freq to 1/10th clk (25 MHz)
wrlut rgbp,#0 'set 2 colors in LUT
wrlut rgbc,#1
rdlong linebuf,ptra
rdfast #1,linebuf '
' Field loop
field mov hsync0,sync_000 'vsync off
mov hsync1,sync_001
callpa #2,#blank 'top blanks
mov ii,#480 'set visible lines
add ii,#96
line1 call #hsync 'do horizontal sync
'
xcont m_luttest,rgbp 'do visible line
djnz ii,#line1 'another line?
callpa #2 ,#blank 'bottom blanks
mov hsync0,sync_222 'vsync on
mov hsync1,sync_223
callpa #1,#blank 'vertical sync blanks
jmp #field 'loop
' Subroutines
blank call #hsync 'blank lines
xcont m_vi,hsync0
_ret_ djnz pa,#blank
hsync xcont m_bs,hsync0 'horizontal sync
xzero m_sn,hsync1
_ret_ xcont m_bv,hsync0
sync_000 long %1101010100_1101010100_1101010100_10 '
sync_001 long %1101010100_1101010100_0010101011_10 ' hsync
sync_222 long %0101010100_0101010100_0101010100_10 'vsync
sync_223 long %0101010100_0101010100_1010101011_10 'vsync + hsync
rgbp long %00000000_10000000_10000000_00000000 'background
rgbc long %11111111_00000000_00000000_00000000
m_bs long $70810000 + hdmi_base<<17 + 16 'before sync
m_sn long $70810000 + hdmi_base<<17 + 48 'sync
m_bv long $70810000 + hdmi_base<<17 + 16 'before visible
m_vi long $70810000 + hdmi_base<<17 + 1024 'visible
m_luttest long $70820000 + hdmi_base<<17 + 1024 'rflong+lut
ii res 1
linebuf res 1
hsync0 res 1
hsync1 res 1
Comments
My TV needs a minimum of 8 vert blanking for that mode. And 64 horiz blanking is enough. Sadly it also just reports it as 576p@50Hz, which means it may be assuming the DVD video standard of 768x576. Not sure, it might be clocking correctly and just not reporting fully. It is very good at detecting oddball resolutions exactly when connected over HDMI.
My old DVI monitor needs minimum 80 horiz blanking, and 8 vert blanking. It is reporting resolution correctly.
My Dell 2405FPW monitor reports this as 1024x576 at 50Hz and displays okay. I see vertical reddish stripes.
Oh, I forgot to highlight: Neither of my displays worked correctly without first increasing the vertical blanking. The initial setting of 5 was too little.
Yep, fine reddish vertical stripes is the picture.
Yes, that is the correct result. Red/cyan 1-pixel wide stripes, made by filling the buffer with AA is Spin .
The problems I am most afraid of are: (1) very reduced blanking (2) 29 kHz horizontal refresh. There is of course room for the blanking, the P2 can be clocked higher, but then Chip said there are ADC problems over 320 MHz
Haven't played with the ADC at the higher rates but I can hit 350MHz video output. That's usually about as high as I'm game to go.
EDIT: I should say the P2 is clocked at that speed, but the pixel clock is divided down from that. Would be quite good if you could go to 371.25MHz (5x74.25MHz).
Up to 375 worked for me at least with SimpleSound and module player. 376..377 is where this P2 gives up and plays garbage.
Those frequencies are temperature dependant. The warmer the room, or the harder the prop2 is working, or the less thermal dissipation in the board design, the hotter the die becomes so the lower that limiting frequency becomes. They additively combine to raise the die temperature.
Philips 243V: failed: needs 20 lines vblank to work. Achievable with Amiga*50 clock=354_354_690.
Philips 272B: passed
AOC E2470SW: failed
AOC E2460S: passed
Couldn't get it to display on Philips 221B... will try some others tomorrow
Tubular,
Add 3 to the vblanking, that takes it to 8 total.
Ok thanks will give that a try tomorrow
It seems too many monitors need more vblank. I will try to recalculate timings to enable more blanking and still use Amiga * const as a CPU freq. As I have now, the "failed" philips 243V works when added some more vblank lines and then raise the CPU freq to keep the frame rate about 50 Hz. Maybe Amiga * 50 can be a good choice. It is 354_354_690. I still didn't test the ADC.
In theory, you should need 49 blank/sync lines (625 total) for a standard-compliant PAL EDTV signal.
Although standards aren't everything, I have CRT monitors where standard SVGA timings have visible H retrace and I have to edit the blanking times, haha