Homebrew 3dsgba

  • Thread starter Thread starter dragonfromiso
  • Start date Start date
  • Views Views 56,660
  • Replies Replies 138
  • Likes Likes 16
Status
Not open for further replies.
GBA doesn't have banks to really split, since any memory can be randomly accessed, so no loading things as needed. We tested it with the ROM split between the heap and linearAlloc'd memory but we decided to just hold off until we can get access to all the 3DS memory, which *should* be soon we hope.
It's also the case on the SNES. Well, technically there are banks, but there are long addressing modes that can reach any bank regardless of the current PBR/DBR, so in the end any memory address can be accessed at any time.

lolSNES had a ROM cache system that basically cached a given bank if it was accessed more than 4 times or so. Maybe this can work in your case if you split the ROM in blocks of a given size.
 
It's also the case on the SNES. Well, technically there are banks, but there are long addressing modes that can reach any bank regardless of the current PBR/DBR, so in the end any memory address can be accessed at any time.

lolSNES had a ROM cache system that basically cached a given bank if it was accessed more than 4 times or so. Maybe this can work in your case if you split the ROM in blocks of a given size.

I could possibly see doing this with things like frequently loaded graphics, where if a particular graphic like a background or sprite is being LZ77 decompressed frequently it will cache it and then once another SWI is called to retrieve it you can just pull from the cache, but other than data I'd probably avoid caching parts of the ROM if I can just load it all into RAM. Might help a bit but could also screw up timing as well since LZ77 normally takes the CPU some time (although I think VBA already screws over timing so it might not make a difference).
 
Will we be seeing an option for scaling to the 3DS's resolution/screen size so that there's no or minimal black borders on the top and bottom of the screen (still in 4:3 aspect ratio)?
 
Will we be seeing an option for scaling to the 3DS's resolution/screen size so that there's no or minimal black borders on the top and bottom of the screen (still in 4:3 aspect ratio)?

I would also love to see it upscale as good as it can without messing up the ratio.
 
Could we get a list of confirmed working games? Or are we not even at that point yet? Also, is this taking advantage of the AGB FIRM?
 
Could we get a list of confirmed working games? Or are we not even at that point yet? Also, is this taking advantage of the AGB FIRM?

At this point most games aren't playable so a list of working games would be kinda... pointless. Basically at this point though any games over 16MB won't work, and if the game reads outside of the 16MB range it will crash (ie Fire Red). And no, AGB_FIRM requires kernel access to be had at, this uses a port of vba-next.
 
At this point most games aren't playable so a list of working games would be kinda... pointless. Basically at this point though any games over 16MB won't work, and if the game reads outside of the 16MB range it will crash (ie Fire Red). And no, AGB_FIRM requires kernel access to be had at, this uses a port of vba-next.

So, not at that point yet is what you should have said. Thanks though, didn't know we didn't have access to AGB_FIRM. I got the idea from a trusted source here that coding one from scratch would be pointless since we could take advantage of AGB FIRM.
 
Way I see it is for me SNES ran pretty good on NDS tho it had incompatiblity and couldn't work on games with special chips and on NDS GBA had tons of issues and was unplayable. So with that being said GBA should work relatively well considering it much stronger than the NDS (certainly so if it becomes optimized for the new 3ds)

Really though, the DS was cracked wide open at the time. The 3DS is still active (updating left and right, info being collected), and we still don't have full access. Fancy gpu work and dynamic recompilers will take much more time if these limitations aren't removed.
Still very promising in terms of 3ds homebrew.
 
Not much progress on this, huh? ;m;

Ssshhhhh, let it die slowly.

CitrAGB is probably your best bet for now since VBA doesn't have dynamic recompilation. No offense to Steveice10 ofc, although I doubt he'd take offense at all. It's just that VBA generally isn't a good emulator for slower platforms.
 
Ssshhhhh, let it die slowly.

CitrAGB is probably your best bet for now since VBA doesn't have dynamic recompilation. No offense to Steveice10 ofc, although I doubt he'd take offense at all. It's just that VBA generally isn't a good emulator for slower platforms.
Well, huh... I didn't see the thread for the other one...
 
Not much progress on this, huh? ;m;


Well, now that we have the ability to set RAM as executable and CitrAGB in the works, there isn't really a use for 3DSGBA. It was more of a proof-of-concept to get the ball rolling until better was possible. VBA is purely interpreted, unlike gpsp which has dynarec cores out there, so it would probably take much more work to get this working with dynarec.

Although, I am slightly surprised that gpsp was used for CitrAGB rather than TempGBA. Seems like it would have been a better candidate since it is both based on gpsp and DS-friendly.
 
Thanks for explaining, I kept wondering what happened here. Sucks about the platform choice, but none of your fault, luckily we have a backup ;D

It probably would have just been best to port gpsp in the first place, but I believe Steveice10 ported VBA-Next initially because it's extremely easy to interface with and all it needed was a good front end. I had initially started a port of gpsp before he released 3DSGBA, but I quit halfway through it because I thought that gpsp didn't have an interpreter (making it useless). Once this came out I did work on it in hopes of getting it properly working, but I quickly realized that a GBA emulator with just an interpreter wasn't happening any time soon (unless you did it from scratch). A lot of the people on 3dsdev advised that I port gpsp since it had an interpreter which ran faster, and when I looked into it I found out that there was an interpreter and finished the port, and then finished the dynrec.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum