Page 1 of 1
Support for ultrawide resolution
Posted: Fri Jul 09, 2021 9:19 am
by Crystal
Since we now have a core for GBA2P, with horizontal splitscreen support, adding a support for 21:9 ultrawide resolution as 2560x1080 would be really nice for this mode. Resolution of 2 GBA at horizontal splitscreen with 5x scaling would be 2400x800. Can we then get support for at least 2560x1080@60? It's less than the current maximum supported resolution 2048x1536@60
Re: Support for ultrawide resolution
Posted: Fri Jul 09, 2021 11:36 am
by mapf
This is the mode for 2560x1080@60 but I think this is exceeding the limits of the fpga. Try at your own risk.
Code: Select all
video_mode=2560,168,272,440,1080,1,3,34,230760
Re: Support for ultrawide resolution
Posted: Fri Jul 09, 2021 1:59 pm
by Crystal
mapf wrote: ↑Fri Jul 09, 2021 11:36 am
This is the mode for 2560x1080@60 but I think this is exceeding the limits of the fpga. Try at your own risk.
Code: Select all
video_mode=2560,168,272,440,1080,1,3,34,230760
Tried it but didn't work out as expected
I assume this is due to the limits of FPGA?
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 1:02 am
by FoxbatStargazer
I think there's some issue with such high width and the scaler, which is a separate problem from the pixel clock. I had similar results even doing 2560x240 to CRTs. (and this is something direct_video does all the time...)
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 12:32 pm
by Grabulosaure
You need to recompile the core with .OHRES(4096) for ascal in sys/sys_top.v :
Code: Select all
+ .OHRES(4096),
.N_DW(128),
.N_AW(28)
)
ascal
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 7:29 pm
by Crystal
Grabulosaure wrote: ↑Sat Jul 10, 2021 12:32 pm
You need to recompile the core with .OHRES(4096) for ascal in sys/sys_top.v :
Code: Select all
+ .OHRES(4096),
.N_DW(128),
.N_AW(28)
)
ascal
without having any prior experience, i got quartus prime 17.0.2 lite, forked GBA2P repo, loaded GBA.qpf, edited sys_top.v adding said modification but im geting this error
Code: Select all
Error (10170): Verilog HDL syntax error at sys_top.v(654) near text: "."; expecting "(". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10149): Verilog HDL Declaration error at sys_top.v(742): identifier "LFB_EN" is already declared in the present scope
Error (10112): Ignored design unit "sys_top" at sys_top.v(34) due to previous errors
Error (10112): Ignored design unit "sync_fix" at sys_top.v(1661) due to previous errors
Error (10112): Ignored design unit "csync" at sys_top.v(1695) due to previous errors
this is how i inserted it, at line 654m pushing everything by 1 more line. the error message, saying that "." should be instead "(" doesnt make sense to me
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 7:34 pm
by KnC
remove the + at start of line 654
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 9:47 pm
by Crystal
KnC wrote: ↑Sat Jul 10, 2021 7:34 pm
remove the + at start of line 654
thank you! now it has compiled with no error, just one critical warning and bunch of non-critical warnings, but it did compile. took the new compiled core and its a hell of a bigger improvement.
osd is stretched but at this point, im happy if its only stretched and not distorted. im surprised to see it scale edge to edge horizontally. for 2xgba, thats 480, 5x integer gets 2400px wide but the resolution set in video mode is 2560. shouldnt there be at least some black bars on side? or am i just too blind for 80px wide black bars?
however, i guess its not viable after all, as i was getting drop outs every few seconds now, which again, i assume is the fpga limitation?
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 9:49 pm
by Crystal
if someone feels adventurous, here is the compiled core with aforementioned modifications. dont forget to modify the video_mode in ini as well
Re: Support for ultrawide resolution
Posted: Sat Jul 10, 2021 10:11 pm
by Grabulosaure
@Crystal
You need to reduce clock frequency :
video_mode=2560,168,272,440,1080,1,3,34,230760
230MHz is far too high.
For example the 2048x1536 mode uses a 209.318MHz clock (which is already beyond reasonable)
Either try 50Hz modes.
Or find a mode compatible with your screen but with reduced blanking, for example :
2560,48,32,80,1080,1,3,34,182460
The rule is to keep similar horizontal and vertical frequencies.
Vertical :
230760*1000/(2560+168+272+440)/(1080+1+3+34)= 60Hz
182460*1000/(2560+48+32+80)/(1080+1+3+34) = 60Hz
Horizontal :
230760*1000/(2560+168+272+440) = 67kHz
182460*1000/(2560+48+32+80) = 67kHz
You may need to try many combinations though...
Re: Support for ultrawide resolution
Posted: Sun Jul 11, 2021 4:19 am
by FPGAzumSpass
Make sure that the critical warning is not failed timing, otherwise you are overclocking the core and may introduce bugs or even the loss of sync.
The GBA2P core often has timing failure due to being so full.
After you built the core it should look like the left side, not like the right side.
If you have failed timing, you can go assignment -> settings -> compiler settings -> advanced settings(Fitter)... -> Fitter initial Placement seed
Set something else there and try again.
It's a random number that alters placement and gives you a new try.
GBA2P in latest version (with additional VGA out) takes me about 10 runs to build with timing closure.
I know that it's a pain, but i really recommend that, at least when you found something that works for you. and you want to use it for longer.
- timing_closure.png (58.61 KiB) Viewed 18681 times
Re: Support for ultrawide resolution
Posted: Sun Jul 11, 2021 1:13 pm
by Crystal
FPGAzumSpass wrote: ↑Sun Jul 11, 2021 4:19 am
Make sure that the critical warning is not failed timing, otherwise you are overclocking the core and may introduce bugs or even the loss of sync.
The GBA2P core often has timing failure due to being so full.
After you built the core it should look like the left side, not like the right side.
If you have failed timing, you can go assignment -> settings -> compiler settings -> advanced settings(Fitter)... -> Fitter initial Placement seed
Set something else there and try again.
It's a random number that alters placement and gives you a new try.
GBA2P in latest version (with additional VGA out) takes me about 10 runs to build with timing closure.
I know that it's a pain, but i really recommend that, at least when you found something that works for you. and you want to use it for longer.
it was exactly as you've suspected, failed timing critical warning. it looked like the right screenshot. ive made adjustments to 'Fitter Initial Placement Seed, set it to 4 and it have compiled it without the failed timing critical warning. in the report, timing closure recommendations now looks like the left screenshot
Code: Select all
This design does not contain any failing setup paths. The worst-case slack is 0.027 ns.
No paths fail setup timing.
Grabulosaure wrote: ↑Sat Jul 10, 2021 10:11 pm
@Crystal
You need to reduce clock frequency :
video_mode=2560,168,272,440,1080,1,3,34,230760
230MHz is far too high.
For example the 2048x1536 mode uses a 209.318MHz clock (which is already beyond reasonable)
Either try 50Hz modes.
Or find a mode compatible with your screen but with reduced blanking, for example :
2560,48,32,80,1080,1,3,34,182460
The rule is to keep similar horizontal and vertical frequencies.
Vertical :
230760*1000/(2560+168+272+440)/(1080+1+3+34)= 60Hz
182460*1000/(2560+48+32+80)/(1080+1+3+34) = 60Hz
Horizontal :
230760*1000/(2560+168+272+440) = 67kHz
182460*1000/(2560+48+32+80) = 67kHz
You may need to try many combinations though...
after loading the new core on sdcard, ive still tried to run it under first attempt for video_mode
Code: Select all
video_mode=2560,168,272,440,1080,1,3,34,230760
there were no blackouts or drops of signal as before. not sure if this is just because i havent played for too long in this mode. after that, ive tried the configuration with reduced blanking
Code: Select all
video_mode=2560,48,32,80,1080,1,3,34,182460
nothing has really changed for me, as in, it works great with no issues. ive been playing on this mode for about 45 minutes now, with no issues at all[that ive noticed]. end result here
https://i.imgur.com/ByzbRSO.mp4
i've attached the compiled core again, for anyone who wants to try it too. it still uses the "GBA2P" locations for game and save, so you dont have to duplicate it. it also shares the "gba2p" parameters in ini file, which i how i set the video_mode.
thank you all who helped me! dare i to say, this is perfect![hope i didnt just jinxed it]. at least perfect for this usecase. it seems to work really well now. once again, thank you all for helping me and thank you FPGAzumSpass for all your hard work and help!
Re: Support for ultrawide resolution
Posted: Sun Jul 11, 2021 2:45 pm
by FoxbatStargazer
Is there any reason the limits were set lower? Like shouldn't this be a part of main at some point? Wide resolutions are useful for more than just 2P gameboy core.
Re: Support for ultrawide resolution
Posted: Sun Jul 11, 2021 10:32 pm
by Grabulosaure
Supporting wide resolution uses lots of memory in the FPGA, It's not really useful for most cores.