Homebrew GBARunner2

[Coto]

Hey! Both NesDS and SnemulDS work with regular boot (I've been using them regularly both through the flashcart menu and YSMenu) which surprised me even more. I don't exactly know the build of GBARunner2 I'm using right now, although I believe it is the last one in the wiki (don't really have any way of compiling one myself right now), but it is strange as I've tried every single build and found an old one that for some reason worked, but it seems like my R4 is blocking the dldi or something like that? I'm quite a newbie in this, but that's as far as I can tell. I'm fine with running it from YSMenu, I just wanted to check it out and I was satisfied that I actually got it to work.

OK. Thanks for testing. So the DLDI section is properly patched by loader (regular boot), because SnemulDS uses https://bitbucket.org/Coto88/gccnewlibnano_to_fsfat (gccnewlibnano_to_fsfat driver) (and all ToolchainGenericDS code). Also the sector size and cluster size relative offsets is held by Fatfs itself (so varying cluster sizes on different micro sd cards would iterate, for example, the first 512 byte FAT table and the upcoming data correctly).
And libfat does that as well so regular boot on your card is compatible.

Also, since DLDI Name is different depending on the loader, then the YSMenu DLDI driver could be compatible with the DLDI found in regular boot. (either by rebranding card name, or by very similar IC). This was common in the R4 clones using either DSTT or R4 DLDIs

Perhaps the _DLDI_startup payload (SD Init function) is different in the regular boot kernel, or the SD card commands (read/write) are poorly written in the regular boot DLDI?

 

[Gericom]

OK. Thanks for testing. So the DLDI section is properly patched by loader (regular boot), because SnemulDS uses https://bitbucket.org/Coto88/gccnewlibnano_to_fsfat (gccnewlibnano_to_fsfat driver) (and all ToolchainGenericDS code). Also the sector size and cluster size relative offsets is held by Fatfs itself (so varying cluster sizes on different micro sd cards would iterate, for example, the first 512 byte FAT table and the upcoming data correctly).
And libfat does that as well so regular boot on your card is compatible.

Also, since DLDI Name is different depending on the loader, then the YSMenu DLDI driver could be compatible with the DLDI found in regular boot. (either by rebranding card name, or by very similar IC). This was common in the R4 clones using either DSTT or R4 DLDIs

Perhaps the _DLDI_startup payload (SD Init function) is different in the regular boot kernel, or the SD card commands (read/write) are poorly written in the regular boot DLDI?

My guess is that some dldi drivers do something weird that give problems in the special environment of gbarunner2. Maybe they change irq settings or something. Maybe something else. Might be interesting to compare 2 different dldis that work for the same card, but where one doesn't work in gbarunner2.

 

[Coto]

My guess is that some dldi drivers do something weird that give problems in the special environment of gbarunner2. Maybe they change irq settings or something. Maybe something else. Might be interesting to compare 2 different dldis that work for the same card, but where one doesn't work in gbarunner2.

Yes. When I was writing linker files (ld), for ToolchainGenericDS, I found 2 things:

1) Legacy (older) versions of the DLDI patch routine AND the NDS "loader" embedded in NDS homebrew, for homebrew such as moonshell2 or DSOrganize, would not run homebrew that had misaligned sections relocated (or relocated without the alignment, by default 4 bytes, and placeholders), for either data or code. And the kernel would load these NDS files just fine.

2) The kernel, loader code using old stacks when reloading NDS homebrew: Ninjapass X9SD does that. I think Moonshell2 works (using the DLDI I fixed for NinjapassX9SD) because it inits the stacks, disables interrupts, and then reloading ARM7 code fully. It does not "expect" or take for granted interrupts being enabled.

One of the fixes I did for running moonshell2 (videos, mp3, etc) in NinjapassX9SD was:

Unmasking accidental IRQs if the cart were to eventually raise them.
https://bitbucket.org/Coto88/ninjap...f6e560f82b44241/source/io_sd_card.c#lines-123

 

[Gericom]

Yes. When I was writing linker files (ld), for ToolchainGenericDS, I found 2 things:

1) Legacy (older) versions of the DLDI patch routine AND the NDS "loader" embedded in NDS homebrew, for homebrew such as moonshell2 or DSOrganize, would not run homebrew that had misaligned sections relocated (or relocated without the alignment, by default 4 bytes, and placeholders), for either data or code. And the kernel would load these NDS files just fine.

2) The kernel, loader code using old stacks when reloading NDS homebrew: Ninjapass X9SD does that. I think Moonshell2 works (using the DLDI I fixed for NinjapassX9SD) because it inits the stacks, disables interrupts, and then reloading ARM7 code fully. It does not "expect" or take for granted interrupts being enabled.

One of the fixes I did for running moonshell2 (videos, mp3, etc) in NinjapassX9SD was:

Unmasking accidental IRQs if the cart were to eventually raise them.
https://bitbucket.org/Coto88/ninjap...f6e560f82b44241/source/io_sd_card.c#lines-123

Yes. When I was writing linker files (ld), for ToolchainGenericDS, I found 2 things:

1) Legacy (older) versions of the DLDI patch routine AND the NDS "loader" embedded in NDS homebrew, for homebrew such as moonshell2 or DSOrganize, would not run homebrew that had misaligned sections relocated (or relocated without the alignment, by default 4 bytes, and placeholders), for either data or code. And the kernel would load these NDS files just fine.

2) The kernel, loader code using old stacks when reloading NDS homebrew: Ninjapass X9SD does that. I think Moonshell2 works (using the DLDI I fixed for NinjapassX9SD) because it inits the stacks, disables interrupts, and then reloading ARM7 code fully. It does not "expect" or take for granted interrupts being enabled.

One of the fixes I did for running moonshell2 (videos, mp3, etc) in NinjapassX9SD was:

Unmasking accidental IRQs if the cart were to eventually raise them.
https://bitbucket.org/Coto88/ninjap...f6e560f82b44241/source/io_sd_card.c#lines-123

So is there anything particular that should be done in gbarunner2? Irqs are definitely disabled using cpsr when reading during gba execution (runs in abt->fiq mode). They may not be enabled either. It will cause issues.

 

[Coto]

Well, seeing that about 99% of DLDI drivers out there are already working... and fixing this issue by hand would probably cause more problems that what is worth...


What I did was:
Work around the init code so interrupts are largely ignored (not touching interrupts at all), until the very late stage, which then:
https://bitbucket.org/Coto88/toolch...r=file-view-default#InterruptsARMCores_c.c-53
(in fact this code runs when the new stacks are already set, user mode, right after jumping to main)

What I'd suggest:
I'd rather standardize the SD part (by using some SD API, the lightest possible if size is an issue, because I know GBA Hypervisor must take as little space as possible for optimal MPU Settings). So you would iron out mis-alignment problems. NDS Hardware definitely does not like misaligned code. SD ReadSectors are abused in GBARunner2/gbaemu4ds perhaps much more than it was intended for. (which would make sense for the below message part...)

That said, I'd blame the DLDI SD layer here, not your code because it works, again for the 99% DLDI cases. It probably messes with interrupts

Notes:

ToolchainGenericDS specific IRQ handling:
I assume interrupts are always either enabled or disabled, so it doesn't matter wether the SDReadSectors/SDWriteSectors payload decide to turn off interrupt master enable register, and even if I/F bit in PSR is enabled, and if external hardware eventually raises another, you handle the moment an IRQ should be dealt; that has given a lot of compatibility across all DLDI I have tested so far:
https://bitbucket.org/Coto88/toolch...=file-view-default#InterruptsARMCores_s.S-102

GBAemu4ds specific IRQ handling:
Basically IRQ context is saved by handling the whole GBA IO Map by software (interrupt master enable register read or write event).
Dealing with PSR bits is done only when NDS mode takes place,right after the interrupt master enable register setting event.
By the time SDReadSectors/SDWriteSectors is called, it's already NDS mode so then, I acknowledge the CARD IRQ manually.

About the CARD IRQ, older flashcarts have an issue with it. Basically newer cards raise CARD IRQs differently than olders. IRQ Code should deal CARD IRQ always, but since older cards use polled transfers when issuing IC commands (ie: commands to internal FPGA while the DLDI layer takes place), then sometimes the CARD IRQ is raised while a polled transfer takes place. That fixes NinjapassX9SD at least.

 

[Gericom]

Well, seeing that about 99% of DLDI drivers out there are already working... and fixing this issue by hand would probably cause more problems that what is worth...


What I did was:
Work around the init code so interrupts are largely ignored (not touching interrupts at all), until the very late stage, which then:
https://bitbucket.org/Coto88/toolch...r=file-view-default#InterruptsARMCores_c.c-53
(in fact this code runs when the new stacks are already set, user mode, right after jumping to main)

What I'd suggest:
I'd rather standardize the SD part (by using some SD API, the lightest possible if size is an issue, because I know GBA Hypervisor must take as little space as possible for optimal MPU Settings). So you would iron out mis-alignment problems. NDS Hardware definitely does not like misaligned code. SD ReadSectors are abused in GBARunner2/gbaemu4ds perhaps much more than it was intended for. (which would make sense for the below message part...)

That said, I'd blame the DLDI SD layer here, not your code because it works, again for the 99% DLDI cases. It probably messes with interrupts

Notes:

ToolchainGenericDS specific IRQ handling:
I assume interrupts are always either enabled or disabled, so it doesn't matter wether the SDReadSectors/SDWriteSectors payload decide to turn off interrupt master enable register, and even if I/F bit in PSR is enabled, and if external hardware eventually raises another, you handle the moment an IRQ should be dealt; that has given a lot of compatibility across all DLDI I have tested so far:
https://bitbucket.org/Coto88/toolch...=file-view-default#InterruptsARMCores_s.S-102

GBAemu4ds specific IRQ handling:
Basically IRQ context is saved by handling the whole GBA IO Map by software (interrupt master enable register read or write event).
Dealing with PSR bits is done only when NDS mode takes place,right after the interrupt master enable register setting event.
By the time SDReadSectors/SDWriteSectors is called, it's already NDS mode so then, I acknowledge the CARD IRQ manually.

About the CARD IRQ, older flashcarts have an issue with it. Basically newer cards raise CARD IRQs differently than olders. IRQ Code should deal CARD IRQ always, but since older cards use polled transfers when issuing IC commands (ie: commands to internal FPGA while the DLDI layer takes place), then sometimes the CARD IRQ is raised while a polled transfer takes place. That fixes NinjapassX9SD at least.

What is not entirely clear to me is why cards use the irq in the first place. The dldi can't change the irq handler anyway. Do they only poll the if register then?
Also, so you do suggest to backup and restore the ie/ime registers around dldi calls?

Also I'm sure the code is aligned. I think I did 32 byte alignment for the buffer.
And what do you mean with readsectors being abused?

 

[Coto]

What is not entirely clear to me is why cards use the irq in the first place. The dldi can't change the irq handler anyway. Do they only poll the if register then?
Also, so you do suggest to backup and restore the ie/ime registers around dldi calls?

Also I'm sure the code is aligned. I think I did 32 byte alignment for the buffer.
And what do you mean with readsectors being abused?

Abused meant : since dldi is called consecutively, this issue arises faster in older cards. Specifically older cards
can raise IRQ CARD even if polled transfer takes place( stuck retrieving sd card data from io ports, without a timeout), while other ( I think ) newer DLDI drivers do DMA, but i am not sure of that/ don't care enough, irq timings might be fucked up eventually, leading to an unhandled irq, which is, freezes.

At least that's what I have had to dealt with before.

 

[Disturbo]

I'd like to point out that my card was bought in December last year, an R4i 3DS RTS from nds-card.com, so it is rather new and it uses the original firmware so I'd assume it is not a fake.

 

[Gericom]

Abused meant : since dldi is called consecutively, this issue arises faster in older cards. Specifically older cards
can raise IRQ CARD even if polled transfer takes place( stuck retrieving sd card data from io ports, without a timeout), while other ( I think ) newer DLDI drivers do DMA, but i am not sure of that/ don't care enough, irq timings might be fucked up eventually, leading to an unhandled irq, which is, freezes.

At least that's what I have had to dealt with before.

If a dldi driver uses dma (which it shouldn't), it will likely give problems as well.

 

[Arnold101]

dsi with hiya and dsimenu++. i have gba folder in root of sd and roms and bios.bin in that folder, when i start gbarunner i got a white screen, why??? and i can't see any game in gba folder

 

[bobrocks95]

dsi with hiya and dsimenu++. i have gba folder in root of sd and roms and bios.bin in that folder, when i start gbarunner i got a white screen, why??? and i can't see any game in gba folder

I got a white screen the first time I tried it with this setup. The second time it booted correctly. This is with dsimenu++'s built-in version of GBARunner2

 

[brunocar]

dsi with hiya and dsimenu++. i have gba folder in root of sd and roms and bios.bin in that folder, when i start gbarunner i got a white screen, why??? and i can't see any game in gba folder

try the arm7 builds, it works just fine for me

 

[Arnold101]

bruno can you link please? i can't find

--------------------- MERGED ---------------------------

try the arm7 builds, it works just fine for me

 

[Deleted User]

@Arnold101 you will find the latest and older arm7 build of gbarunner2 here: https://wiki.gbatemp.net/wiki/GBARunner2

 

[Arnold101]

no one worked for me tried the last amr7 and arm9

 

[zfreeman]

no one worked for me tried the last amr7 and arm9

Have you tried with YSMenu?

 

[Arnold101]

i see, http://home.usay.jp/ not work for me where i can download it?

 

[Deleted User]

i see, http://home.usay.jp/ not work for me where i can download it?

The RetroGameFan package contains a YS.nds: http://www.mediafire.com/file/4o1ikndt60070x9/RetroGameFan+Multi+Cart+Update+v7.05.7z

 

[Jawman]

I tried to play Emerald thorugh GBARunner2 with DSiMenu++, and it got as far as loading the GBA boot screen before getting stuck on a white screen. Any ideas about what happened?

 

[SkepticBlaze]

It says that pokemon ruby runs well on gba runner but it does not work for me btw I have r4i gold pro. after it says game boy nothing else happens