yes but still white screens.Did you press START, then "Select rom type" then "start gbarunner2"?
yes but still white screens.Did you press START, then "Select rom type" then "start gbarunner2"?
Weird. Is the card formatted to FAT32 with 32K clusters? That's how mine's set up and it works fine.yes but still white screens.
I saw your TGDS repo, does TGDS-build of gbaemu4ds work now?I think we should ask @ichichfly first. The current source code compiles in older devkitarm, but generates several .LUB files (which are really standalone, recompiled versions of the gbaemu4ds source code). Then you use hbmenu as launcher to boot these .LUB files. The hbmenu launcher chooses a file, which then is passed as a fullpath to each standalone version, so game boots.
The problem:
- the source code has several parts unused, some VBA ARM/THUMB cpu core is recompiled as arm assembly, really un maintainable and not required. Since the ARM/THUMB code is recompiled from sources (C/C++)
- the shared stacks: depending on the part gbaemu4ds runs from (say, a irq interrupt or data abort) the stack is shuffled. It is not linear: say, the usual way for an ARM program would be two interrupts to happen at the same time, the context is saved to stack then restored in full descending nature by default. In gbaemu4ds case, depending on code section, the stacks are mixed (interleaved)
- the gbaemu4ds code recompiles the SAME VBA ARM/THUMB cpu core at least twice. One for normal VBA CPU Core and another for half software emulation + MPU aborts (which just redirect to NDS map that is the same as GBA map), which is faster. Best case scenario (which I tried at some point years ago), was to have the first cpu core (full software), but either some games would stop working or the interrupts would have to be handled through software, because MPU layer would just redirect to actual NDS interrupts (for instance reading and writing IE/IF would be available from GBA mode only if that map was MPU protected)
- overall code was a bit messy, but nothing too terrible when you know already how everything goes together.
To be fair, I would rather update the code so it runs on devkitpro, THEN I would move it to ToolchainGenericDS. For now I just have the barebone stuff for building in TGDS. So homebrew would be equally maintained I guess.
It is a 16GB FAT32 card.Weird. Is the card formatted to FAT32 with 32K clusters?
nope it does not. I just added some TGDS parts so it would compile in TGDS. I just succeeded at thatI saw your TGDS repo, does TGDS-build of gbaemu4ds work now?
Your best bet.Isn’t there a more user-friendly option? I lost my 3ds so I’m completely out of options
1) Added Pokemon Sapphire / Ruby (any region) proper Save Format [Flash 128K]. Will prevent the "Save is Corrupted" screen. You can start a new game and the savefile will be generated correctly. On the other hand if you don't want to lose your savefile, but you have the former error screen, keep reading!
2) Added Save-Fix mechanism: Since the only games I could test was Pokemon Sapphire /Ruby... if you have a savefile from Pokemon Sapphire / Ruby that shows "Save is Corrupted" screen whose filesize is 64K (ie: Corrupted savefile, but still readable), gbaemu4ds will fix that savefile for you into a fully correct CRC save.
Case scenario: make sure to use the same filename for both the gba file and the sav file (say, 64K sav file). Boot up gbaemu4ds and run the gba file. If the save was detected as corrupted, the DS console will show a "SaveFix" message, mentioning, that you must save in-game, and then, press Y to write back to file the fixed savefile.
A+B+SELECT+START, as stated above.Which button is soft-reset button?
once assembled, the object behaves and relates totally to the machine it was compiled for. Reverse Engineering a game that uses specific hardware (such as writing to hardware registers) ends up in emulating the pieces it requires, so it can run. This is the birth of an emulator.Hey guys I just had an idea, I'm not sure if this was already thought of, or if I'm retarded or something, but would it be possible to take a disassembled GBA ROM and then assemble it into a NDS ROM instead of trying to emulate it? Again I'm not sure if that is possible/compatible etc.
Nope, not possible. That's why it's called ROM (Read-Only Memory). Flashcards have a flashable ROM.Ok thanks. Also, is there any way to remove the game image from a commercial GBA cart and use it as a slot 2 flash cart for the NDS?
That means either your card wasn't DLDI patched or you didn't have a gba folder in root SD folderHi,
I have downloaded gbaemu4nds alive and copied the gbaemu4nds.nds file in the root folder but there is a problem... it tells that it couldnt open the directory. What should I do?
Latest build very good!
Unfortunately hack roms doesnt work at all...
Unfortunately nope Stuck at loading/creating save file with a white screen...Does this build work with romhacks? In this build, just paste the gbaemu4ds.nds somewhere and run it. It should read the /gba folder