I'm curious, Does the (Very) Little extra CPU clock speed that the DSTWO's Mips processor has,(333mhz Vs 396) gives it any extra edge on GBA emulation?
Hacking TempGBA: NDSGBA revival
- Thread starter Deleted member 319809
- Start date
- Views 505,561
- Replies 1,326
- Likes 22
I'm pretty sure he means versus the PSP, which is also MIPs (333mhz "stock" max), and where gpSP (the original source for these ports) came from...
I assume you mean fast-forward here, and not rewind. It's not much faster in TempGBA if you disable the sound while fast-forwarding, unlike in the SNES emulator with its 8 SNES sound channels.
I'm not sure what to say about the TempGBA/NDSGBA versus gpSP and MIPS clock speed stuff. I'll pass a build to Rydian for testing and bug reporting because the cheats support has stopped crashing thanks to BassAceGold (but UI coordinates may be wrong). Rydian will know more than me about the clock speeds, because he uses gpSP on the PSP. I'm now at the point where most of the stuff is hooked in that can be hooked in from the source, so maybe after that private release a general alpha can start.
I surmise Surkow was talking about gbaemu4ds, which runs on the NDS side, thus ARM. The comparison was indeed between NDSGBA and gpSP, MIPS to MIPS.
The PSP's CPU is stock 333mhz, but for the life of the system most official software ran at 222mhz to save on battery life and make less heat, though some later games gave a 333mhz option (Kingdom Hearts and God Of War IIRC) due to needing more power.
Most homebrew took advantage of the variable clock rate, I could downclock it to like 45mhz or something for Gameboy emulation, while most higher system emulators (like gpSP) ran at 333mhz by default, and I don't think anybody bothered lowering it for those.
EDIT: Small clarification.
Most homebrew took advantage of the variable clock rate, I could downclock it to like 45mhz or something for Gameboy emulation, while most higher system emulators (like gpSP) ran at 333mhz by default, and I don't think anybody bothered lowering it for those.
EDIT: Small clarification.
Yes, I assumed the discussion was about native performance (on the DS) versus running it on the DSTWO.
Did any homebrew use the GPU on the PSP? The DSTWO uses a JZ4740. On the Dingoo a320 (also using a JZ4740) you could overclock the processor from 336mhz to over 400mhz depending on the batch. At times this resulted in stability issues.
gpSP, NDSGBA, and TEMPGBA don't run on the DS. They need the PSP/DSTwo's CPU and run on that.
The mecm branch of the SNES emulator used the media engine of the PSP (hardware media decoding) for some stuff if that's what you mean?
The mecm branch of the SNES emulator used the media engine of the PSP (hardware media decoding) for some stuff if that's what you mean?
- Joined
- Nov 24, 2008
- Messages
- 428
- Trophies
- 0
- Location
- Somewhere in cali
- Website
- www.youtube.com
- XP
- 370
- Country
I think rewinding is slightly broken right now, in that it corrupts a 128 KiB save file (.sav) if it's used even once during a game. It's also possible that the creation of saved-states altogether is breaking a 128 KiB .sav.
CALL FOR TESTERS
Please test this build, identified as TempGBA alpha 2, with your favourite huge-save game (mine's Pokémon Emerald): http://filetrip.net/dl?7FTJeVC25G
If you experience a save file corruption error, like Pokémon Emerald's "The save file is corrupt. The previous save file will be used." message, please take note of anything you did for the error to occur, as specific as possible. This includes the following:
* Putting the DSTWO into another DS whose clock is off, making the save appear to be in the future to the first DS.
* Saving in-game then exiting.
* Saving in-game without exiting, just shutting down the DS.
* Saving in-game and loading an unzipped ROM.
* Saving in-game and loading a zipped ROM.
* Loading or saving states.
* Enabling or disabling rewinding.
* Using rewinds.
* Using fast-forwarding.
CALL FOR TESTERS
Please test this build, identified as TempGBA alpha 2, with your favourite huge-save game (mine's Pokémon Emerald): http://filetrip.net/dl?7FTJeVC25G
If you experience a save file corruption error, like Pokémon Emerald's "The save file is corrupt. The previous save file will be used." message, please take note of anything you did for the error to occur, as specific as possible. This includes the following:
* Putting the DSTWO into another DS whose clock is off, making the save appear to be in the future to the first DS.
* Saving in-game then exiting.
* Saving in-game without exiting, just shutting down the DS.
* Saving in-game and loading an unzipped ROM.
* Saving in-game and loading a zipped ROM.
* Loading or saving states.
* Enabling or disabling rewinding.
* Using rewinds.
* Using fast-forwarding.
A hypervisor is something that oversees the execution of code written for the same processor architecture as the chip that's actually running it (e.g. ARM code on an ARM CPU) but redirects certain other resources. This is similar to virtual machine software on a PC.
An emulator is something that converts code written for a foreign processor architecture so that the chip can run it (e.g. Zilog Z80 code, like for a Game Boy, on an ARM CPU).
Yesterday and today in the TempGBA repository: [
]
I just discovered an issue with game-specific configuration appearing to reset itself when reloading the same game after exiting the emulator. Commit 4fc1794 fixes this by writing the correct header. It's not in the alpha 2 release.
What's in the alpha 2 release, though:
* commit 0a6a76a, "Add button remapping, both global and overridable per-game." You can test this, but do know that the overrides won't stick until I make a new alpha release. The button mappings are in the Tools menu.
* commit b9c0ed0, "Add rewinding as the first user-definable hotkey." This commit created the hotkey menus, also in Tools. L+Y is the default hotkey for rewinding, but you can now set it to anything you want.
]I just discovered an issue with game-specific configuration appearing to reset itself when reloading the same game after exiting the emulator. Commit 4fc1794 fixes this by writing the correct header. It's not in the alpha 2 release.
What's in the alpha 2 release, though:
* commit 0a6a76a, "Add button remapping, both global and overridable per-game." You can test this, but do know that the overrides won't stick until I make a new alpha release. The button mappings are in the Tools menu.
* commit b9c0ed0, "Add rewinding as the first user-definable hotkey." This commit created the hotkey menus, also in Tools. L+Y is the default hotkey for rewinding, but you can now set it to anything you want.
well, I've tested 2 unzipped roms on my old DS2 . The Roms are Super Robot Taisen OG1 and Mega man and Bass and both performed great . I love the Button Remap!!!!!!!
* A bit of an update I've also worked with Metroid fusion, it and the other 2 roms both have a small buzzing in the back ground. I was playing on my old DS phat and then decided to give my daughter's DSi try just see if wasn't just my old machine's speakers.
* A bit of an update I've also worked with Metroid fusion, it and the other 2 roms both have a small buzzing in the back ground. I was playing on my old DS phat and then decided to give my daughter's DSi try just see if wasn't just my old machine's speakers.
There any chance to make the gba video run on it well
even Classic-nes gba too
so it will feel more like that you actually gba games on it you know?
even Classic-nes gba too
so it will feel more like that you actually gba games on it you know?
You're an American, right?
Try to use proper English.
I can make out the first part, but that last sentence makes no sense whatsoever.
Alright, so I think I figured out what the problem with .sav files is. It's pretty bad.
Every time I compiled a new version, the in-memory address of EVERYTHING changed. So one time the in-memory representation of the current game's save data started at address 02005AF4*, and the next time, it started at 02005A56*. That means that, every time I saved a state, compiled a new version, loaded the state and saved a .sav, it was writing to the DSTWO's RAM at a different place.
Well, if the save data was 128 KiB like in Pokémon Emerald, the data would be split into two 64 KiB "banks", and a pointer to the current bank was kept around so the emulator would know where the next save command should go, either in the first bank or in the second bank. But the saved state kept a record of where that data was, at the time of saving, in the DSTWO RAM! And when loading a state, that bank would be made to point to the old location of itself in memory. So change the position of the data, and BOOM, all future .savs generated after loading a state from an older version would be corrupt because they write "the data" to somewhere and the .sav ends up being "e dataHH" or "HHthe da", unreadable to the game. And it doesn't help matters if you load a state made with an older version, save it immediately under the new version, and create a .sav, because the bank pointer is permanently pointing to garbage.
With that said, I shall announce that I will make saved states saner in TempGBA, but that it will have lost saved state compatibility with all versions of gpSP, gpSP Kai, NDSGBA and even TempGBA alphas 1 and 2.
* = not actual addresses, just examples
Every time I compiled a new version, the in-memory address of EVERYTHING changed. So one time the in-memory representation of the current game's save data started at address 02005AF4*, and the next time, it started at 02005A56*. That means that, every time I saved a state, compiled a new version, loaded the state and saved a .sav, it was writing to the DSTWO's RAM at a different place.
Well, if the save data was 128 KiB like in Pokémon Emerald, the data would be split into two 64 KiB "banks", and a pointer to the current bank was kept around so the emulator would know where the next save command should go, either in the first bank or in the second bank. But the saved state kept a record of where that data was, at the time of saving, in the DSTWO RAM! And when loading a state, that bank would be made to point to the old location of itself in memory. So change the position of the data, and BOOM, all future .savs generated after loading a state from an older version would be corrupt because they write "the data" to somewhere and the .sav ends up being "e dataHH" or "HHthe da", unreadable to the game. And it doesn't help matters if you load a state made with an older version, save it immediately under the new version, and create a .sav, because the bank pointer is permanently pointing to garbage.
With that said, I shall announce that I will make saved states saner in TempGBA, but that it will have lost saved state compatibility with all versions of gpSP, gpSP Kai, NDSGBA and even TempGBA alphas 1 and 2.
* = not actual addresses, just examples
The question is : Good progress, but will this only be compatible with the SCDSTwo? Or now that the source is released and you are working hard does this mean a possibly port to other carts?
People can look at my repository for improvements. If they're portable enough, anyone can implement them. I doubt they'll make it into gpSP itself, though, because Exophase has been unresponsive ever since that Japanese guy made gpSP Kai.
TempGBA Alpha 3, the Lesser Data Loss Edition, is available here: http://filetrip.net/dl?htWSmKND6d
Changes:
* Per-game configuration like button mappings, the rewind hotkey and the CPU speed, are now preserved and correctly re-read.
* .sav files and saved states should be immune to TempGBA memory-map changes from this version onwards.
Changes:
* Per-game configuration like button mappings, the rewind hotkey and the CPU speed, are now preserved and correctly re-read.
* .sav files and saved states should be immune to TempGBA memory-map changes from this version onwards.
Aside from the iSmartMM, nothing else has any form of a remotely powerful onboard CPU, and the DS by itself isn't strong enough for GBA emulation. So in other words, most likely no.
Similar threads
-
-
@
Psionic Roshambo:
Mame should be two sets one for preservation of everything and one set for people who just want to play and enjoy the old old ganes -
-
-
-
@
SylverReZ:
@Psionic Roshambo, Believe Japan was going to make it legal at some point, according to a Kotaku story.+1 -
@
Psionic Roshambo:
I swear like 99% of arcade games wouldn't even exist these days outside of MAME the arcade machines are old and busted very few ever saw any sort of home conversion
-
-
@
SylverReZ:
@Psionic Roshambo, There's a lot of obscure Japanese arcade titles that are either lost to time or dumped.+1
-
-
@
Psionic Roshambo:
I mean if a company could use AI to do the work of a home conversion for essentially free why not? The rights for some games are completely lost though
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
But other than PC and Amiga ports I don't think Time Soldiers had any game system ports after the Master System
-
-
-
@
Psionic Roshambo:
Ohhh just noticed that myself I bet it makes the Master System port look amazing by comparison lol
-
-