Main > Raspberry Pi & Dev Board
Raspberry Pi2 320x240p via translating modeline to <hdmi_timings>
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:
--- Quote from: elvis on November 16, 2015, 07:34:31 am ---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.
--- End quote ---
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: ---hdmi_mode=1
--- End code ---
uses CVT, that is what I was using with
--- Code: ---hdmi_mode=8 # 720x240p
--- End code ---
ultimately
--- Code: ---<hdmi_timings>
--- End code ---
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:
--- Quote from: obcd on November 16, 2015, 06:54:22 am ---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.
--- End quote ---
Hi. Thanks for the info, which thread are you referring to, the only reply I can see is where he said to remove the #?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version