Closed patryckpo closed 7 years ago
I know this, but as I said before. If it wouldn't be able to read the sd card right, it would have given another error. Just wait for me to make that test nds so we can properly debug what's the problem.
Run this and see which files it shows (shows 23 files max! because the screen isn't bigger xD)
Edit: Try this one, I placed the debug code in the wrong spot: GBARunner2.zip
Sorry for the wait went to sleep. Just we're clear what I'm testing at this point this is (r4i-sdhc YSMENU 4kb Clusters Fat32):
Debug ran the rom fine actually. Is it a debug of the arm9 read branch or master...? arm9 read branch alone still does not load the rom. Here are the files it found: SYSTEM-1 GBARUN-1 TTMENU BIOS
It's the arm 9 debug branch. Which is a sub branch of the arm 9 branch. So if the debug works, the non debug should work too actually.
Can you send me a compiled arm9 branch maybe I'm not compiling it right or something...
I can't do that right now. I'll post it here tomorrow. Maybe different versions of devkitarm could yield different results. Would be strange though.
Oh I didn't see you uploaded the debug branch okay I'll try building both the debug and the arm9 branches myself and then test to see if it something due to that because the .zip you uploaded works fine.
EDIT: Yup it's something to do with my devkitarm...
I've a bit older version of it. You could try a couple of versions. I would like to have your non working builds to compare what's different.
There you are. Includes both the debug and the regular arm9 branches.
If it matters here's my build script and I'm using the latest devkitarm. GBARunnerBuildScript-Cruplezone.txt
@Cruplezone Could you upload the arm9 elf file instead. It's hard to compare, because nds roms do not contain symbols of course.
@Gericom Hopefully these are correct? Am I getting these from the arm9 folder after making it? arm9_ELFS.zip
@Cruplezone You know what the problem is? For some reason the newer version of devkitarm will translate this:
for(int i = 0; i < sizeof(vram_cd->cluster_cache) / 4; i++)
{
((uint32_t*)&vram_cd->cluster_cache)[i] = 0;
}
for(int i = 0; i < sizeof(vram_cd->gba_rom_is_cluster_cached_table) / 4; i++)
{
((uint32_t*)&vram_cd->gba_rom_is_cluster_cached_table)[i] = 0xFFFFFFFF;
}
for(int i = 0; i < sizeof(vram_cd->cluster_cache_info) / 4; i++)
{
((uint32_t*)&vram_cd->cluster_cache_info)[i] = 0;
}
into 3 memset calls. But of course, memset is not available, and that's the reason I was using these loops. In fact, I commented out these 3 lines that were there previously:
//memset(&vram_cd->cluster_cache, 0, sizeof(vram_cd->cluster_cache));
//memset(&vram_cd->gba_rom_is_cluster_cached_table, 0xFF, sizeof(vram_cd->gba_rom_is_cluster_cached_table));
//memset(&vram_cd->cluster_cache_info, 0, sizeof(vram_cd->cluster_cache_info));
-ftree-loop-distribute-patterns is added in the new version of the compiler to the O3 options, so that's the reason. Could you try using O2 instead and see if it works?
Tried the latest O2 patch still no go GBARunner2-sound_improve.elf.zip
EDIT: Sorry for slow responses... 'tis the season
@Cruplezone The calls to memset are gone now, but for some reason your build ignores my MI_WriteByte function, and emits an STRB instruction instead! This doesn't work, because we're in vram. It will be ignored! I think I'll have to add the
__attribute__ ((noinline))
to that function. Could you try if that does the trick for you?
okay so I think I can get quick tests for you now. Also just tested and it works great, amazing work :) I think it's safe to say this issue can now be closed! Thanks once again @Gericom this is no lie the project I'm most hyped for atm. just awaiting that save functionality, rts, and most importantly for me some kind of solution to the video scaling issue! Happy holidays @Gericom thank you!
Thanks a lot! Nice that this is resolved. Did you see that I added masking and centering in the latest commit on sound improve. You have to uncomment a define, since it's still experimental.
@Gericom no I did not notice haha thanks for pointing it out! But trying it on my 3ds it does not look so good... the screen is pretty glitchy, not properly cropped, and the top actually appears on the bottom instead of the top (like it loops vertically and is cut off). Basically the overall picture looks pretty bad, worse than it normally does because of the looping, which I guess is expected from it being experimental! Do I even both making an issue on this at this point? Haha great work once again though glad you're implementing it although you said you had lack of resources before. How'd you get around that I wonder...?
It appearently doesn't work on a 3ds. Only on ds and dsi. Must be some hardware difference. Maybe by tweaking the values used, it could work
@Gericom Is there a workaround?
I don't know, I also found out that there were some problems on a ds too. Apparently affine bgs don't shift correctly. VBlank line 263 (vcount 262), which is the last one, seems to reset the lcd to start drawing from the top again, so it needs to appear at the right physical line in order to work correctly, but I think it initializes the affine counters too, shifting them.
Seeing as soundhax and mgba is out for the 3ds now, I don't see this project NEEDING to be compatible with the 3ds, although it would be cool.
@Cruplezone mgba is an emulator,and it's laggy. This is native support for gba,so it would be very good to have 3ds compatibility....
@mariogamer2 mgba (non-libreto/retroarch) runs every rom 100% on n3ds that i've tried. what game are you having issues with, is it because you have o3ds (if so you should upgrade). although yes native support would be a cool project.
The 3DS has AGB_FIRM anyway, which IS native gba support.
@Gericom true, I recommend you focus mainly on ds and dsi for now as I'm sure anyone on 3ds has gba running by now just fine. then fix the 3ds bugs after :) (although I will be eagerly waiting, mgba does not have fullscreen support or at least i cannot find it)
I don't have a 3ds myself, so I wouldn't be able to test it anyway. Also it's not my fault that the nds bootstrap dldi needs this irq handler patch, because the sd is only accessible from arm 7. And there are dldi problems with some flashcards too (acekard 2i for example).
I know,the problem is that there's most likely no tool for gba2ciaing on linux :(.
Would probably be not very hard to port, and you could probably use wine, a vm or just windows anyway
I'm testing here and got this error for several games and they're showing the same code. 01007364 E3A00405 4000001F 0200A1D0
On a sidenote: This emu is only for DS and DS Lite? I'm testing on a DSi.