search

MiSTer-devel / GBA_MiSTer

GBA for MiSTer
GNU General Public License v2.0
142 stars 44 forks source link

Feature Request: Autoload #87

Closed mirkorean closed 1 year ago

mirkorean commented 3 years ago

I was trying to autoload roms for some console cores i care for and was sucessful with NES (boot1.rom), SNES (boot.rom), GB (boot0.rom), but failed with the GBA core.

I have boot.rom in the GBA folder. I tried boot1.rom, boot2.rom (does nothing). I tried boot0.rom (seems to be loaded, but doesn't advance past the GBA logo).

Can this feature be added? Or maybe i'm doing something wrong and it's already achievable somehow. Thanks!

RobertPeip commented 3 years ago

I also tried it, same result. As the game data is transfered it should be ok from HPS side using boot0.rom There must be some detail inside the core not allowing it, which must be debugged.

bellwood420 commented 3 years ago

I also did a try and look.

boot0.rom(index = 0) and boot.rom(index = 0) are for bios file, so renaming gba file to that name fails. That's natural. gba file is expected to have index greater than or equal to 1 excluding 255. https://github.com/MiSTer-devel/GBA_MiSTer/blob/7232e49807b5e5d598796abd02024dd20dc124e5/GBA.sv#L369


index = 1 when loading from OSD and index = 64 when loading from boot1.rom. So boot1.rom should work, but it doesn't actually.


Here I found a logic where something wrong is happening. https://github.com/MiSTer-devel/Main_MiSTer/blob/383249f20128dccd42092ef0404aa584daeba2d9/user_io.cpp#L2269-L2296

index = 64 matches if ((index >> 6) == 1 || (index >> 6) == 2) That exactly seems to be for handling index = 64.

Then if (!FileOpen(&fg, user_io_make_filepath(HomeDir(), "goomba.rom"))) is evaluated. I don't have goomba.rom (what's this?), so FileOpen fails, it returns 0.

This means we will go inside the if clause. dosend is set to 0. Prints "Cannot open goomba.rom!" on debug log.

The message is correct and I get this. But because dosend is set to 0, file sending logic coming after cannot be not executed.

I don't know how it should be fixed. Anyway that is the reason.

bellwood420 commented 3 years ago

Okay... I understand about "goomba.rom" referencing this commit and some googling.

The logic itself doesn't seem to be wrong for goomba(is it really supported?), but lacking support for GBA file as boot1.rom.

mirkorean commented 3 years ago

I have no idea what i'm doing but i just tried to have a boot1.rom and goomba.rom (both symlinked to my wanted autoload rom) trying to just trick the code that goomba.rom is there and that works somehow :)

bellwood420 commented 3 years ago

@mirkorean Cool! I confirmed autoloading in your way :) I think it would be better to be fixed in code, though.

mirkorean commented 3 years ago

Yeah, i agree. But this works for me in the meantime at least. Thanks for helping!

I did touch goomba.rom instead of symlinking to a real rom, because it reads the whole file before advancing and now its as fast as i would expect.

RobertPeip commented 3 years ago

Ah that's the reason then. Yes the GBA core supports loading goomba and a real GB(C) rom behind.

You probably don't want to use it as it's software emulation, but overall it's not running too bad on the GBA core as it gets CPU Turbo and has ~3x performance of a real GBA. Unlike pure software emulators it also uses the GBAs drawing modules and soundchannels.

RobertPeip commented 1 year ago

closing this, solution/how-to is in the answers