Just use the SCDS2's menu to delete files.
Just enter the menu make sure you set it to show all files.
Hacking TempGBA: NDSGBA revival
- Thread starter Deleted member 319809
- Start date
- Views 505,555
- Replies 1,326
- Likes 22
Just enter the menu make sure you set it to show all files.
That is correct. TempGBA is an emulator, not a file manager - if you want a good file manager, use BassAceGold's BAGPlug or the EOS Menu.
Wait what? You're saying that 20fps sucks, yet your automatic frameskip only does 60(42) and 20... what's going on here? Are you saying that it _hasn't_ always been that way? As in the 20fps one. Also are you saying that 30fps is ill advised now? Finally does this include the memory access stuff? Or is this just some minor stuff? I'm asking because I want to keep testing this thing since it's faster and at 30fps no crackling @240mhz is damn sweet.
Ah OK, so it's not including the faster memory stuff then? Also I'd love it, if it was 30fps, since 42 is a weird number. If there's a config file to set the default as "30fps" for everything that'd be nice. Although I think it's already done that thanks to me using it before. The only other thing is if it's including the faster stuff. And yeah 20fps is awful. I can stand it, but it just feels weird.
- Joined
- Nov 2, 2012
- Messages
- 2,247
- Trophies
- 1
- Location
- Unknown region of space
- Website
- www.metroidwiki.org
- XP
- 2,175
- Country
I found something that i annoys me a little. When i load TempGBA emulator and go to new game, it shows me root folder instead of last folder i have been, so i must always nawigate to my GBA games folder so i can load some Games from it.
I know it does have "recently played games", but it saves only couple of games in the list.
I know it does have "recently played games", but it saves only couple of games in the list.
The new auto frameskip works pretty well, however I've had the emulator freeze while playing metroid fusion, requiring me to reboot the dstwo. I can't narrow down an exact cause, but it seems to happen when the emulator is switching between frameskip levels repeatedly at times when there's a lot of stuff on the screen.
Going back from the start here - I don't know how much you know about TempGBA's past. Sit back and get ready to read, but this will be a good story, don't worry.
In the beginning, there were only NDSGBA 1.21 and NDSGBA 1.30. The users did not like how version 1.30 dropped support for games that worked in 1.21 via the game_config.txt file. It also crashed often, had a GUI you couldn't touch at all despite it being 9 big buttons on the Main Menu, its performance in Mario Tennis was about 6 FPS with lots of crackling in the sound, and its automatic frame skipper was always at 2 or more, giving games a maximum of 20 FPS. The users were generally not pleased.
Having improved upon ShadauxCat's and BassAceGold's work a lot in CATSFC, the users started to look towards a revival of the NDSGBA project. Nebuleon did want to at least add the GUI changes from CATSFC into NDSGBA, but did not have the source code. So the community requested the source code from the Supercard team (see the first 7 pages of this thread) and finally got it. There were initially two versions of the project in parallel, one being a fresh port of gpSP Kai and one being an improvement of NDSGBA. And the GUI worked better in the fresh port, due to Normmatt's and BassAceGold's help, so Nebuleon merged NDSGBA 1.21's code into the new project, TempGBA.
TempGBA ran games exactly as well as NDSGBA 1.21, and could make 128 KiB saves, but it quickly gained some features in the GUI department (see pages 8 to 20 or so), such as the ability to remap all the buttons to new DS buttons, a hotkey system inspired by CATSFC's, and the automatic versus manual frameskippers were made to work better. Unfortunately, frameskip 0 (60 FPS rendered) wreaked havoc when the user tried to run some heavy games on it, and crashed TempGBA. This is the infamous Issue #3 (Crashes at frame skip 0). The users were told that frame skip 0 was only for certain games that gave TempGBA absolutely no trouble, and things were mostly good... but the users kept asking about frame skip 0.
It was possible at this point to make the automatic frame skipper start at 1 (30 FPS), but many games have flashing objects that flash at 30 Hz, so if TempGBA skipped 1 frame, the objects were either always visible, or always invisible! So Nebuleon decided against, and left it at 2 (20 FPS).
Around beta 8, Nebuleon started to ask about the game-specific crashes and slowdowns, looked into the code for some optimisations, and got pieces of information from Exophase and Normmatt, who had more experience dealing with ARM code. And Nebuleon started to optimise things, little by little, not understanding any of the GBA-to-DSTwo recompiler at first. The users were happier, but some games still ran very slowly.
So Nebuleon struggled with the recompiler for a while until all of a sudden it started to make sense. Having had some experience with machine code (assembly) on Intel processors in the past, Nebuleon did not struggle with the low-level details, but rather the high-level ones. "Why doesn't this optimisation work?" "Why did Exophase code this assumption into the code?" "What is the cause of all of those crashes?" So in betas 8 to 10, TempGBA got some new features... but they were not for the mere mortal playing games. They were for developers, statistics and crash information to be gathered for easier debugging and optimisation.
Then, TempGBA got a new GBA-to-DSTwo recompiler base, coded piece by piece -- sometimes breaking the old code completely to remake it into a better foundation. Some new features were added in parallel, but the mainstay was the emulation core. Many games were made to work better; however, some games started to crash (in betas 13 and 15). The bugs were so odd in beta 15 that Nebuleon requested help, and it was provided by the Supercard Team in the form of a special Supercard with a serial line. With this, Nebuleon was able to write, in real-time, information to a computer!
After a few reversions of code and reimplementations of things that did not work well, which Nebuleon called memory-access-3, many games that previously got very few FPS (Mario Tennis's 6, Golden Sun 2's 17-20, Doom II's 4-12) were suddenly getting way more FPS, almost 60. The users rejoiced. But Nebuleon did not: Issue #3 still made games freeze the emulator if they were too heavy but the users selected frame skip 0 (expecting 60 FPS on the screen).
So the serial line proved itself to be useful, narrowing down the problem to the frameskip code. Surely enough, a loop in the frameskip code was waiting for the audio code to signal that the DSTwo was ready to accept more sound data. Except, that loop was never to end, because the DSTwo signalled that it had enough audio to play for years!
The bug was fixed, and both Nebuleon and the users rejoiced. The emulator became stable enough to support 60 FPS rendered, not just 20 FPS. So automatic frameskipping was deemed to be better if it was at 0 (60 FPS) initially. It dropped down to 2 (20 FPS) if the game couldn't keep up. Because many games have flashing objects that flash at 30 Hz, Nebuleon did not want automatic frameskip to be 1 (30 FPS), making them always visible, or always invisible. So the next best thing was to alternate between 60 FPS and 20 FPS depending on the need. It would provide the users with a smooth experience, while not making the sound crackle or flashing objects disappear when the game couldn't keep up. The users were pleased, but not enthralled.
The DSTwo ran TempGBA at 60 FPS and sent its images to the DS's screen, but could not keep up with the sheer amount of data that needed to be transferred. It needed to send 60 images of 256x192 at 16 bits per pixel, so 5.89 MB per second, but it had only 4.3 MB to spare! That gave it a limit of about 42 FPS, which the user could see the most in scrolling areas, because they were scrolling with a staircase effect.
This being a limitation of the communication link, the users wanted to know whether the communication link could be improved in some way... say, with compression. This created a debate of compression methods, among which there were Deflate, LZ4 and RLE.
And this is the story of TempGBA and its 60 or 42 or 20 FPS.
tl;dr: Important parts are in bold, go read them if you just want quick context
- Joined
- Nov 2, 2012
- Messages
- 2,247
- Trophies
- 1
- Location
- Unknown region of space
- Website
- www.metroidwiki.org
- XP
- 2,175
- Country
Interesting history of TempGBA 
Ah just for 1.59 MB and it would be 60 FPS
About those compression methods.......... ?
Ah just for 1.59 MB and it would be 60 FPS
About those compression methods.......... ?
The users wondered if compression would help, but Nebuleon and BassAceGold received word from Normmatt that the communication protocol between the DSTwo and the DS was coded on each side, and that the code on the DS's side, to read the DSTwo's packets, was compiled with an old version of devkitARM and libnds that was no longer available, and did not compile anymore with the latest version.Interesting history of TempGBA
Ah just for 1.59 MB and it would be 60 FPS
About those compression methods.......... ?
Following this revelation, Nebuleon and BassAceGold gave up.
More recently, Normmatt found the version of devkitARM, with libnds, that was used to compile the reader on the DS side. However, Normmatt forewarned: "it's Windows-only". Thus it was quickly dismissed as making no sense that the DSTwo SDK had a compiler that ran on Linux and needed to communicate with a part that needed to be compiled on Windows if it was modified. Nebuleon, in particular, did not want to impose lots of complexity upon future users wishing to compile new versions of TempGBA with their own improvements in them.
The users and the developers both debated extensively among themselves as to what would be needed to achieve enough compression to reach 60 FPS in most or all games. It was generally agreed upon that we would need an algorithm that would:
- compress the incoming frames by at least 29%;
- not cause lots of processing to occur on either the DSTwo's side or the DS's side; and
- be implementable in as little memory as possible, to allow both sides to avoid wasting their instruction caches on nifty compression.
- Joined
- Nov 2, 2012
- Messages
- 2,247
- Trophies
- 1
- Location
- Unknown region of space
- Website
- www.metroidwiki.org
- XP
- 2,175
- Country
So what are your predictions about the future of TempGBA?
I mean i got to say, despite some minor issues, this emulator is Awesome!
I'm wondering When 3DS gets hacked and emulators starts to come out for it, i wonder how GBA emulator would be, considering that 3DS has a lot Hardware power! (at least much more than DS that's for sure)
I mean i got to say, despite some minor issues, this emulator is Awesome!
I'm wondering When 3DS gets hacked and emulators starts to come out for it, i wonder how GBA emulator would be, considering that 3DS has a lot Hardware power! (at least much more than DS that's for sure)
I've done and tried (but sometimes failed) a lot of things. I'm very satisfied with how the emulator has turned out, so I'll keep a role in the program, but it will be a more passive one. For example, getting rid of some of the smaller bugs that are left behind, and accepting patches and the like.
Trades off battery usage for CPU power. A higher one may help the emulator run some intense games. A lower one gives you more battery time if you're running simpler games like Marios and Pokémons.
dot_clean /Volumes/nameofdrive........type that into the terminal it will delete all the double ._ files
30FPS is not the setting you want because:
So unless you want flashing objects to stop flashing, frameskip 1 (aka 30FPS) is not recommended.
I've not seen any flashing objects that stopped flashing(having to replay a game that the emulator did didn't use a standard format for) and @240mhz, I don't believe i'd be able to get stable 42fps. That always visible/invisible whilst kinda bad, I can deal with them being invisible if it means I can run everything at a smooth 30fps, if I can do the same with the games I have on my agenda atm(not too many at this exact moment and time) then I will try frameskip 0 but since the memory access stuff hasn't been answered yet I'm not upgrading. He never said whether or not 1.42 did the memory access stuff or not.
It does. But your first question post was just so full of stuff that I didn't understand it.
1.42 is issued from 1.41+memory-access-3.1 with more stuff on top, so Golden Suns and Mario Tennis run fast etc.
The Classic-Nes Gba-Rom still don't work. Not the clean or the patched roms. Always shows "Guru Meditation Error". Try both load mode with no luck
Similar threads
- No one is chatting at the moment.
