Do you think he could benefit from the gbaemu4ds code? I mean they both seem to meant to be hypervisors. Ichfly did many things right, wonder if his work turns out to be helpful for @Gericom
Well you need a GBA bios to compile it and place the ROM in your flashcart's SD card as "runner.gba"
So far I've only tested two games: a homebrew shmup called vulkanon and Metroid Fusion. Both worked (no sound on Fusion tho).
Hi guys,
Yes, I knew of the existence of gbaemu4ds, however, only after finishing the base for gbarunner2 I found out it was a bit the same. I'm also doing a couple of things different, preventing sprite glitches and providing better sound. Everything is written from scratch though, and in assembly for speed. And I'm still optimizing it (self-modifying code, large jump tables etc.). The only thing that gbaemu4ds is better at currently is the sd access speed, but I'm working on that.
I'll make a separate topic tomorrow, to keep everything on topic.
Here you go: http://gbatemp.net/threads/gbarunner2.451970/
Edit: Since I posted that topic about nocash and low vectors, I've been able to modify desmume to support gbarunner2 somewhat, so it became a little easier to debug.
Yes, I knew of the existence of gbaemu4ds, however, only after finishing the base for gbarunner2 I found out it was a bit the same. I'm also doing a couple of things different, preventing sprite glitches and providing better sound. Everything is written from scratch though, and in assembly for speed. And I'm still optimizing it (self-modifying code, large jump tables etc.). The only thing that gbaemu4ds is better at currently is the sd access speed, but I'm working on that.
I'll make a separate topic tomorrow, to keep everything on topic.
Here you go: http://gbatemp.net/threads/gbarunner2.451970/
Edit: Since I posted that topic about nocash and low vectors, I've been able to modify desmume to support gbarunner2 somewhat, so it became a little easier to debug.
Last edited by Gericom,
You can already test it out if you want.Thank you for your hardwork dude, I can't wait to test this out
1. Make sure you have devkitpro installed
2. Download the git repo
3. Follow the steps for setting up the bios
4. Run make in the root, it gives you an error about a missing nitrofiles directory, so create it (git didn't upload that empty folder)
5. Run make again, it should work this time
6. Make sure your sd card is fat32 formatted
7. Put Gbarunner2.nds on your sd
8. SRAM patch your gba rom with gbata if needed
9. Put the rom as runner.gba on the root of your sd
10. Run gbarunner2.nds
This is not the topic to mention this anyway. But I was thinking about the same:
The way gbaemu4ds handles streaming reads is:
https://github.com/ichfly/gbaemu4DS...up/code_container/arm9/source/fatfile.c#L1227
so
allocedfild marks cache as either used or not
sectortabel holds the actual stream data, given chucksizeinsec size (the size of a sector fetch)
However these rely on:
https://github.com/ichfly/gbaemu4DS...up/code_container/arm9/source/fatfile.c#L1222
which is Libfat (arm7dldi (no custom handler on FIFO/IPC streaming) - arm9 libfat)
how about you add another branch that uses that instead the cache system the actual gbarunner2 uses?
Reasons: default dldi works well along arm7 setups like this:
https://github.com/cotodevel/SnemulDS/blob/master/arm7/source/main.c#L153
So you´d have an easier to read/maintain arm7 library. Just my 2 cents!
edit:
want to know how somewhat gbaemu4ds work?
https://github.com/ichfly/gbaemu4DS/issues/4
2nd post
Last edited by Coto,
This emulator is buggy and out-of-date, so I recommend using GBARunner2, which is a GBA hypervisor, and currently in development.
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.
Last edited by Coto,
why would you even use this when it barely works and gbarunner2 is way better?
Because why not? The more the merrier.
maybe if gbaemu4ds could do something that gbarunner2 could not but I don't think this is the case.
That is not something up to you to decide anyway, say if I want to release a new version and gbarunner2 does more things then that's bad?
Whatever dude
It works fine in twloader. You need to put bios.bin and the roms in a "GBA" folder on the root of the SD.
Similar threads
-
- Portal
