True. Or take a dingux powered device with awesome reGBA emulator which will do just that perfectly.
However nothing compares to playing a GBA game on GBA.
True. Or take a dingux powered device with awesome reGBA emulator which will do just that perfectly.
However nothing compares to playing a GBA game on GBA.
Figured it wasn't gonna happen, I mean the whole thing just kinda seems absurd and I assume the method you mentioned would require a lot of time, effort and skill to pull off! But I don't see any reason for someone to develop something like that in the first place.
just don't. You have to do it separately for each and every game you want to do that with. So you'll have to build your own flashcart with the larger SRAM (develop your own kernel and everything), then spend a couple of months figuring out a game and writing a patch for it to do everything I listed earlier, then move on to the next game and spend another couple of months on that game. You'll have to do that for EVERY game you want to be able to do that. There's a reason why something like this wasn't done, even back in the heyday of the GBA.
Even then, it might not be successful, there might be other issues that pop up that prevent it from ever being stable or even working in the first place. There aren't really any extra resources for you to work with, since the GBA games use as much as they can, considering they were designed for the handheld.
For all you folks, just keep in mind that Goomba is also emulating what GBA is natively capable of - running GB programs. And if that would be pointless, it wouldn't be that popular.
Last edited by Sergey,
That was designed with the micro in mind, which was not backwards compatible with the GB. It was also convenient for those just using a GBA flashcart. I also don't think you understand what an emulator is. It would literally be pointless in every sense of the word, as the GBA hardware is already there and being used. Emulation is used to allow hardware to essentially mimic other hardware to run coding designed for that other hardware, to put it basically.
Goomba is very useful for GBA and GBA SP too, although it emulates the hardware it's being executed in. It allows saving current state in say, Super Mario World, at any point, which is what I'm missing for original GBA games.
--------------------- MERGED ---------------------------
Well, let me correct my last wording: not "emulates the hardware it's being executed in" but rather emulates the hardware that exists in where it's being executed. I hope I got it right this time.
--------------------- MERGED ---------------------------
I hope you get the idea.
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,491
- Country
Yes, the GBA can run GB/C games, but the GBA is not emulating that system. It is running natively because the system contains GB/C hardware, and when a GB/C game is inserted, it hits a switch in the cartridge slot, which activates and runs off those components. GBA games can't trigger this switch because of the design of the carts themselves.
Goomba does actual emulation by running off of the GBA hardware.
Goomba does actual emulation by running off of the GBA hardware.
It's funny that people are missing the biggest point of the question:
It's somewhat legitimate - I mean, being able to play games on native hardware but have the extensibility of a savestate or whatnot would be pretty cool. I don't think such thing exists though, but if you were inclined enough, you could pull off a DSTWO and create a GBA cart with additional memory as to have state support.
That was answered earlier. I'm just being foolishly stubborn and trying to get the OP to understand what an emulator is. I know, I should have dropped it by now, sometimes I guess I just get in a masochistic mood.
Actually, for the initial question, I have a far simpler solution if you're running a SP or micro. Just put it to sleep instead. If the game doesn't support a sleep mode, there are a couple of patchers floating around that allows you to implement sleep. When the battery gets low, just recharge it. If you're going not going to use it for long periods of time, then just use the passcode system then. It will cut down on the amount you'll have to use the crappy passcode system.
Last edited by TecXero,
You got the point of my question just right. Thank you!
I indeed think it would be very cool to be able to save progress state on .gba games while running them on real GBA that don't support it natively.
The thing is you have plenty of storage on miniSD/microSD to save state on when running programs on GBA off a flashcart, it's just the technical implementation of a wrapper that's missing. I haven't dealt with that low-level programming before so before even trying something I thought I'd ask about it here but seems like I'm not getting any support so far.
Thank you for all your efforts. I really appreciate your fast replies and have read all of them carefully. I'm not an expert in virtualization and hardware emulation. I couldn't even write a driver for Intel AC 7260 wireless adapter that would make it work on FreeBSD when I wanted it. Most of the programmers from various areas out there wouldn't be able to do that either. That's not the point though. The point is that I'm looking for a way to take .gba program snapshots inside GBA itself and my first guess is to run .gba program inside GBA emulator/wrapper which in addition to proxying commands provides snapshot feature. Is it crazy? Maybe. Can you think of something less crazy besides patching each rom?
That won't work with multiple games.
The emulation nonsense aside, I think the sleep mode is the best bet, just stick to one game until you write down a passcode to shut it off or you beat it. If you're a technical genius, you could probably hardmod the GBA with some sort of module that's connected to the RAM and VRAM that can dump and restore with its own switches. I wouldn't even want to speculate how you'd even do that. It's simply not practical. I wouldn't say impossible, just completely nuts to try to pull off, even with my recommendation earlier. These recommendations weren't meant to be taken seriously, just there to try to convey how close to impossible it would be.
You're just going to have to pick your poison in this instance. You can either run an emulator (as in something that isn't the GBA, like a PSP, Android, potato, whatever that would actually have to emulate the GBA hardware as it doesn't have or can't access the GBA hardware or similar) and accept any imperfections that comes with the emulator, or go with a GBA an accept all the limitations that come with it.
Pretty sure M3 and the Supercard GBA flashcarts support real time saves aka save states as well as cheats.
Interesting. Thanks! I currently have EZ Flash IV and it doesn't provide this functionality.
Will search for Supercard GBA flashcart and see if it does it.
Indeed, the Supercard GBA flashcart supports Save States and they work pretty well most of the times, as well. The interesting part is that you'll end up using them ALL THE TIME even when not needed since the saving system for normal SRAM saves is SO shit on the SuperCards. If you don't quick-power-cycle your Flashcard, it won't write them back to SD. Forget to do that one, BAM, hours of progress lost.
Add to that that some GBA games will have massive slowdowns on it, and you're in for a treat.
To answer the general questions.
Some kind of native emulator/hypervisor with a view to savestates. Afraid not. I can get you stuff for cheats (see GBAATM, gabsharky and various other things, though mainly stick with GBAATM), for slowdown (not sure if GBAATM has the feature right now but it would be easy enough to do the basic CPU flood method as seen in DS flash carts and DSATM), for soft reset (GBATA should have this, if not BOMA), for sleep patches (GBATA again, though for the EZ4 you probably want to instead have a look at what Kuwanger and I think Dwedit might have done for it) and a few other choice things that exist as the logical consequence of those things just mentioned but savestates are not an options.
In theory I might be able to pull something off but I would so much rather have some hardware on the flash cart side of things to help me out there -- the EZ3 (the EZ4's basically direct predecessor -- in the menu it is called EZDisk for a reason it is that close) had savestates, nowhere near emulator grade mind you, but they never made it to the EZ4 and no other worthwhile flash cart (you might be able to find a supercard, unfortunately you would then have to deal with a supercard trying to do GBA and that was never good) you might be able to find today has such a feature either. Likewise no GBA flash cart ever had terribly reliable savestates -- if you were around for the early days of on hardware DS savestates then it was probably better than the GBA ever got.
Password saves... there are certainly some but I have not encountered it as a real problem for most games I might play. What would ultimately be far easier than some kind of generic, or even game specific, savestate engine is to hack the games in question to use a save. It is considerably easier to do on a GBA than it was on older systems, not trivial but if it is not for a silly kids game (I just did a quick search and that is where most seem to be, aside from the obvious things like the GBA video series), so something like Back to Stone* I could see it being worked up for. The general idea will be the passcode is just a means of encoding binary data, it will then have something to decode it and if you can instead feed it something from a bit of SRAM you just made appear (it is always there, well documented and not controlled by a bank switching setup or anything like you might see on the NES, SNES, GB/GBC or anything like that) then you have your save, likewise you will want to be able to catapult the passcode into the SRAM as well but that should not be so hard either. Whether you want to go all in and remove the passcode features is a different matter... personally I would leave it and call it a "backup for those that want it".
*by the way anybody have that passcode generator for Back to Stone, release thread for the generator http://gbatemp.net/threads/password-generator-back-to-stone-u.40851/ ? We (myself and various others) could not find it when looking for it a while back when the game was the game of the week selection ( http://gbatemp.net/threads/gbatemp-game-of-the-week-85.340895/ ).
GBA emulators for the DS that are not on an enhanced flash cart like the iSMM or DSTwo, you are pretty much limited to the ichfly GBA stuff already linked ( http://ichfly.github.io/gbaemu4DS/ ) which is a fantastic proof of concept and some great coding but not really ready for prime time, there is some older stuff but it is even less developed/capable. I am not sure how much further the DSi specifics ever got for that sort of thing.
Some kind of native emulator/hypervisor with a view to savestates. Afraid not. I can get you stuff for cheats (see GBAATM, gabsharky and various other things, though mainly stick with GBAATM), for slowdown (not sure if GBAATM has the feature right now but it would be easy enough to do the basic CPU flood method as seen in DS flash carts and DSATM), for soft reset (GBATA should have this, if not BOMA), for sleep patches (GBATA again, though for the EZ4 you probably want to instead have a look at what Kuwanger and I think Dwedit might have done for it) and a few other choice things that exist as the logical consequence of those things just mentioned but savestates are not an options.
In theory I might be able to pull something off but I would so much rather have some hardware on the flash cart side of things to help me out there -- the EZ3 (the EZ4's basically direct predecessor -- in the menu it is called EZDisk for a reason it is that close) had savestates, nowhere near emulator grade mind you, but they never made it to the EZ4 and no other worthwhile flash cart (you might be able to find a supercard, unfortunately you would then have to deal with a supercard trying to do GBA and that was never good) you might be able to find today has such a feature either. Likewise no GBA flash cart ever had terribly reliable savestates -- if you were around for the early days of on hardware DS savestates then it was probably better than the GBA ever got.
Password saves... there are certainly some but I have not encountered it as a real problem for most games I might play. What would ultimately be far easier than some kind of generic, or even game specific, savestate engine is to hack the games in question to use a save. It is considerably easier to do on a GBA than it was on older systems, not trivial but if it is not for a silly kids game (I just did a quick search and that is where most seem to be, aside from the obvious things like the GBA video series), so something like Back to Stone* I could see it being worked up for. The general idea will be the passcode is just a means of encoding binary data, it will then have something to decode it and if you can instead feed it something from a bit of SRAM you just made appear (it is always there, well documented and not controlled by a bank switching setup or anything like you might see on the NES, SNES, GB/GBC or anything like that) then you have your save, likewise you will want to be able to catapult the passcode into the SRAM as well but that should not be so hard either. Whether you want to go all in and remove the passcode features is a different matter... personally I would leave it and call it a "backup for those that want it".
*by the way anybody have that passcode generator for Back to Stone, release thread for the generator http://gbatemp.net/threads/password-generator-back-to-stone-u.40851/ ? We (myself and various others) could not find it when looking for it a while back when the game was the game of the week selection ( http://gbatemp.net/threads/gbatemp-game-of-the-week-85.340895/ ).
GBA emulators for the DS that are not on an enhanced flash cart like the iSMM or DSTwo, you are pretty much limited to the ichfly GBA stuff already linked ( http://ichfly.github.io/gbaemu4DS/ ) which is a fantastic proof of concept and some great coding but not really ready for prime time, there is some older stuff but it is even less developed/capable. I am not sure how much further the DSi specifics ever got for that sort of thing.
I'll be honest, I didn't know there were flashcarts that did support RTS on GBAs. All my GBA games have a proper save function, so I never really look into save states. I figured implementing an actual save system would be a lot more difficult, even though it wouldn't require anything done hardware side. I couldn't imagine how that could be pulled off without having to reverse engineer most of the game.
EDIT: Well, I guess it could be reasonably done. Still, that would take a lot of work. I guess if you have it load the main bits then, essentially, have the "save loader" have it tell the game you've just entered a room (based on the save file, assuming the game loads room from room), it could work. That's making a few assumptions, but I guess that could be done. It would rely a lot on how the game works, and you wouldn't have many resources to work with.
EDIT: Well, I guess it could be reasonably done. Still, that would take a lot of work. I guess if you have it load the main bits then, essentially, have the "save loader" have it tell the game you've just entered a room (based on the save file, assuming the game loads room from room), it could work. That's making a few assumptions, but I guess that could be done. It would rely a lot on how the game works, and you wouldn't have many resources to work with.
Last edited by TecXero,
Similar threads
