Raspberry Pi2 320x240p via translating modeline to <hdmi_timings>

[WalkToFreedom]

I posted this in the Pi forums but didn't get a response so thought I would try here

https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=124456&p=835368#p835368

I am trying to get the Pi to output 320x240p. I have had some success, via these settings:

Code: [Select]

hdmi_group=1
hdmi_mode=8

But hdmi_mode=8 is actually 720x240p.

I know this modeline works fine for the CRT (TV conversion RGB via SCART) as I have had it running via an ArcadeVGA (it's actually an ArcadeVGA modeline):

Code: [Select]

Modeline "321x240@59,4Hz 15,7KHz (60Hz)" 6.460 321 336 368 412 240 242 245 264  -hsync -vsync

Modeline syntax: pclk hdisp hsyncstart hsyncend htotal vdisp vsyncstart vsyncend vtotal [flags] Flags (optional): +HSync, -HSync, +VSync, -VSync, Interlace, DoubleScan, CSync, +CSync, -CSync

eg: Modeline "1600x1200" 155   1600 1656 1776 2048   1200 1202 1205 1263
 #           (Label) (clk)     (x-resolution)        (y-resolution)
 #                     |
 #              (pixel clock in MHz)
Is it possible to translate the modeline to an <hdmi_timings>? This is what I came up with, but screen just stays blank? Am I missing some other setting?

Code: [Select]

hdmi_timings=<h_active_pixels> <h_sync_polarity <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

hdmi_group=2
hdmi_mode=87
hdmi_timings=321 0 15 32 76 240 0 2 3 19 0 0 0 60 0 6460819 1
Thanks!

[obcd]

Are you sure your hdmi 2 vga adapter is capable of handling such resolutions?
If I remember well, some are limited in what they can convert.

[WalkToFreedom]

Are you sure your hdmi 2 vga adapter is capable of handling such resolutions?
If I remember well, some are limited in what they can convert.

Yeah, I wondered about that too but my guess is it just converts whatever the HDMI res is, it does work on:

Code: [Select]

hdmi_group=1
hdmi_mode=8 # 720x240p

So it can output as 240p:

[bleck]

These links may be useful. The first is a listing of modelines for different broadcast standards and game consoles, while the second is a timing calculator

http://www.geocities.ws/podernixie/htpc/modes-en.html
http://www.epanorama.net/faq/vga2rgb/calc.html

One bug in it is that the name of the Modeline you enter has to be of the form "HRESxVRES". Any other characters will screw up the the calculation. For example, for NTSC SNES, I use Modeline "256x224" 5.370 256 274 299 341 224 236 239 262 as input and get

[*User-Defined_mode,(256X224)]
PIXEL_CLK   =   5370
H_DISP   =   256
H_FPORCH   =   18
H_SYNC   =   25
H_BPORCH   =   42
H_SYNC_POL   =   0
V_DISP   =   224
V_FPORCH   =   12
V_SYNC   =   3
V_BPORCH   =   23
V_SYNC_POL   =   0
INTERLACE_ENABLE  =  0

[WalkToFreedom]

Hi. Many thanks for your reply. I had actually come across both of those pages. Taking a second look though and punching the numbers has revealed that mine are up the wacky do. Weird, nothing tricky there just plain wrong. Hmmmm. Will try the new ones and see how they work out. Thanks!

Oh, I'm assuming you're not using a Pi??? If so, where do you configure the modelines???

[WalkToFreedom]

No luck I'm afraid. I wonder if the Pi/HDMI standard doesn't support these timings?

[obcd]

Looks like Dom answered on the raspberry thread.
Maybe it's not the answer you are expecting, but he knows the closed binary blob that boots the pi. So, it's a start.

[elvis]

720x240 is a standard trick to use when you can't get your video chipset's pclock low enough to handle 15KHz CGA modes.   320x240 forces your pixel clock (sometimes called "dot clock") down to 5-6MHz, which some drivers won't allow.  You can often hack around this with open source video drivers (this is how tools like AdvancedMAME via Linux XWindows drivers used to work if you didn't use SVGALib, and I think it's how GroovyMAME/GroovyArcade works via patches that simply change this arbitrary value, unless I'm completely wrong).  If you're stick with a pixel clock of 10-12MHz as a bare minimum, then 720x240 us your only option for 240p.

Your CRT generally won't know the difference (horizontal "resolution" is meaningless to a CRT) and you can use various scale modes in MAME to work around the odd resolution.  If you dig way back in the archives on this forum, you'll find some discussion about it.  Ditto in the readme for tools like lrmc (Low Resolution Modeline Calculator).

With that said, following a few links on the RPi forums lead me here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679

Talk of "CVT" modes is very interesting.  I *still* haven't wired up my Gert VGA 666 adaptor yet, but it's on a list of things to try.  Getting it working with a proper 15KHz modeline is high on my list of wants.

Also, getting progressive scan modes out of the RPi's composite TV Out would be amazing.  But I fear that falls under the same "vendor binary driver limitation" nonsense.

[WalkToFreedom]

720x240 is a standard trick to use when you can't get your video chipset's pclock low enough to handle 15KHz CGA modes.   320x240 forces your pixel clock (sometimes called "dot clock") down to 5-6MHz, which some drivers won't allow.  You can often hack around this with open source video drivers (this is how tools like AdvancedMAME via Linux XWindows drivers used to work if you didn't use SVGALib, and I think it's how GroovyMAME/GroovyArcade works via patches that simply change this arbitrary value, unless I'm completely wrong).  If you're stick with a pixel clock of 10-12MHz as a bare minimum, then 720x240 us your only option for 240p.

Your CRT generally won't know the difference (horizontal "resolution" is meaningless to a CRT) and you can use various scale modes in MAME to work around the odd resolution.  If you dig way back in the archives on this forum, you'll find some discussion about it.  Ditto in the readme for tools like lrmc (Low Resolution Modeline Calculator).

With that said, following a few links on the RPi forums lead me here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679

Talk of "CVT" modes is very interesting.  I *still* haven't wired up my Gert VGA 666 adaptor yet, but it's on a list of things to try.  Getting it working with a proper 15KHz modeline is high on my list of wants.

Also, getting progressive scan modes out of the RPi's composite TV Out would be amazing.  But I fear that falls under the same "vendor binary driver limitation" nonsense.

Ah thanks for the info. Probably relating to the dot clock then. Have made a post in the Raspberry Pi forums too. I know of the Gert VGA666,was considering getting one. I contacted one of the guys who works with Gert and he seems to think it would be possible to get to work at 15Khz - there is some info in the forums about this too.

Code: [Select]

hdmi_mode=1 uses CVT, that is what I was using with

Code: [Select]

hdmi_mode=8 # 720x240p ultimately

Code: [Select]

<hdmi_timings> gives you the most control, but you need to know blanking times etc. I'm pretty sure I've got that right now but still doesnot work so as you say it might be a driver/hdmi restriction

[WalkToFreedom]

Looks like Dom answered on the raspberry thread.
Maybe it's not the answer you are expecting, but he knows the closed binary blob that boots the pi. So, it's a start.

Hi. Thanks for the info, which thread are you referring to, the only reply I can see is where he said to remove the #?

[elvis]

HDMI does have a specific list of supported video modes:
https://en.wikipedia.org/wiki/Uncompressed_video#HDMI_Specifications

Back in the analogue days you could work around those limits as you pleased, but I'm not sure how that works at a hardware/firmware level with HDMI.  Right there is the list of reasons why I don't like firmware as a solution to anything, and why I especially dislike hardware and software that prevents me doing as I please.

The Linux community is working on open source drivers for the GPU in the Raspberry Pi.  I believe the latest 4.4 Kernel includes kernel modeset drivers to replace the proprietary blobs provided by Broadcom which are currently in use by most RPi distros.  Hopefully that means in months to come, we as end users will have the control we want of the hardware we've purchased, rather than having the manufacturers artificially limit what we can do with the things we buy.

[workspace]

Hello,

I managed to drive my Sony PVM with the VGA666 Adapter (via the UMSA - Ultimate SCART Adapter to get a csync instead vsync and hsync).
As wpt-nathan pointed out, the pixelclock has to be a divider of 19.2 for lower pixelclock speeds.
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=112735

By try and error I found that this is the case for pixelclocks lower 31253817 Hz

This is my configuration/modeline/hdmi/dpi_timing that works:

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=336 1 10 30 34 252 1 15 3 42 0 0 0 50 0 6400000 1 # 336:252 6.4MHz progressive
#hdmi_timings=500 1 14 45 56 375 1 240 5 5 0 0 0 50 1 9600000 1 # 500:375 9.6Mhz interlaced

As far as I see these are the only two resolutions at 15.625kHz the gpu can generate through the dpi interface (due the limitations on the pixelclockspeed. I would rather call it a bug)
But I might be wrong.

[WalkToFreedom]

Hello,

I managed to drive my Sony PVM with the VGA666 Adapter (via the UMSA - Ultimate SCART Adapter to get a csync instead vsync and hsync).
As wpt-nathan pointed out, the pixelclock has to be a divider of 19.2 for lower pixelclock speeds.
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=112735

By try and error I found that this is the case for pixelclocks lower 31253817 Hz

This is my configuration/modeline/hdmi/dpi_timing that works:

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=336 1 10 30 34 252 1 15 3 42 0 0 0 50 0 6400000 1 # 336:252 6.4MHz progressive
#hdmi_timings=500 1 14 45 56 375 1 240 5 5 0 0 0 50 1 9600000 1 # 500:375 9.6Mhz interlaced

As far as I see these are the only two resolutions at 15.625kHz the gpu can generate through the dpi interface (due the limitations on the pixelclockspeed. I would rather call it a bug)
But I might be wrong.

Interesting! Will have to try a few things out, will post results. Thanks!

[bleck]

Hello,

I managed to drive my Sony PVM with the VGA666 Adapter (via the UMSA - Ultimate SCART Adapter to get a csync instead vsync and hsync).
As wpt-nathan pointed out, the pixelclock has to be a divider of 19.2 for lower pixelclock speeds.
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=112735

By try and error I found that this is the case for pixelclocks lower 31253817 Hz

This is my configuration/modeline/hdmi/dpi_timing that works:

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=336 1 10 30 34 252 1 15 3 42 0 0 0 50 0 6400000 1 # 336:252 6.4MHz progressive
#hdmi_timings=500 1 14 45 56 375 1 240 5 5 0 0 0 50 1 9600000 1 # 500:375 9.6Mhz interlaced

As far as I see these are the only two resolutions at 15.625kHz the gpu can generate through the dpi interface (due the limitations on the pixelclockspeed. I would rather call it a bug)
But I might be wrong.

I tried this out on my Raspberry Pi 2 with an HDMI-> VGA adapter and I get a blank screen. So it looks like the VGA666 or something similar is needed to get those resolutions.

I've just been running at 720x240 using CEA mode 8 and setting RetroArch to integer scale and run at a 3:1 aspect ratio. That works for everything except for non-4:3 games and the extra black space is not visible thanks to my TV's overscan.

[WalkToFreedom]

Hello,

I managed to drive my Sony PVM with the VGA666 Adapter (via the UMSA - Ultimate SCART Adapter to get a csync instead vsync and hsync).
As wpt-nathan pointed out, the pixelclock has to be a divider of 19.2 for lower pixelclock speeds.
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=112735

By try and error I found that this is the case for pixelclocks lower 31253817 Hz

This is my configuration/modeline/hdmi/dpi_timing that works:

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=336 1 10 30 34 252 1 15 3 42 0 0 0 50 0 6400000 1 # 336:252 6.4MHz progressive
#hdmi_timings=500 1 14 45 56 375 1 240 5 5 0 0 0 50 1 9600000 1 # 500:375 9.6Mhz interlaced

As far as I see these are the only two resolutions at 15.625kHz the gpu can generate through the dpi interface (due the limitations on the pixelclockspeed. I would rather call it a bug)
But I might be wrong.

I tried this out on my Raspberry Pi 2 with an HDMI-> VGA adapter and I get a blank screen. So it looks like the VGA666 or something similar is needed to get those resolutions.

I've just been running at 720x240 using CEA mode 8 and setting RetroArch to integer scale and run at a 3:1 aspect ratio. That works for everything except for non-4:3 games and the extra black space is not visible thanks to my TV's overscan.

Arrrggghhhh, I haven't had a change to try it out yet, but I expect I'll get the same result. You can see in my first post I used the same settings but didn't know about the RetroArch config. Where would I set that? Also, what is your connection to the CRT? HDMI -> VGA to ?

[bleck]

My setup is:
     Raspberry Pi 2
-> VicTsing active HDMI to VGA + audio
-> ArcadeForge UMSA VGA to SCART
-> Panasonic PAL CRT TV (supports NTSC and PAL60)

As for the aspect ratio, make sure the option
video_aspect_ratio = 3
is set in
/opt/retropie/configs/all/retroarch.cfg