Can you build that version, but without the "automatic save backup"? Or isn't possible?
ED64 Plus... my impressions. Any Owners around here?
- Thread starter Bonny
- Start date
- Views 217,572
- Replies 437
- Likes 6
I saw people saying on reddit that these carts have problems with stadium 2 and the save will get corrupted was thinking of getting one but now wondering if i should just get a repro instead. can anyone confirm/deny this?
Only if I make changes to the code, which I didn't yet. But I can try when I have the time.
Howdy all, I've just purchased a Super 64 which I understand is a rehoused ED64P to revistit my old dusty n64.
I have tried some of the Altra64 builds linked in this forum and I noticed some things I don't see mentioned:
1. in the latest akaihiro builds, the mempak save funtion does not work, but it works in earlier builds. In all cases the mempak is identifed as a rumblepak when in a 3rd party controller, but when the save works I have been able to manupulate these dumps with mempak-master found online. This is great.
2. the handling of flash saves is broken. If I save from a game, such as Paper Mario 64, the save is present (in game) on reload. If I then save again, the save becomes corrupt and the save slots show "Empty". This corruption is verified by comparing the before-and-after flash saves in a hex editor - there are changes introduced that render the save file invalid.
Ok, so I'm thinking of forking the code and fixing up a few other things I notice are off, such as the cursor appears in the wrong place on first access of the c-right ROM screen, and adding missing games to the database, or better still pull it out to an editable XML or similar file that anyone can add to. I would also like to expand the config file to specify all colors used in the code, and also to add an option to switch on/off the save versioning.
My question is to any other developers on here - does anyone have an idea what's happening with the flash saves? It could be a memory allocation issue, or some other data handling error. Any steers would be appreciated. The flash saving function works perfectly in the "stock" ED64P firware 1.28, so I know the cart can at least handle it.
One last thing, the font seems to be set in stone. There is a font.h file in the source but it does not get pulled into the build. I'm now assuming that the font is coming from the libdragon library which is pre-compiled. I know it's possible to insert a new font into the os64p binary, but this quickly becomes a pain when you are in a edit-test-compile loop. So if anyone has a tip here I'd welcome any help.
Thanks.
I have tried some of the Altra64 builds linked in this forum and I noticed some things I don't see mentioned:
1. in the latest akaihiro builds, the mempak save funtion does not work, but it works in earlier builds. In all cases the mempak is identifed as a rumblepak when in a 3rd party controller, but when the save works I have been able to manupulate these dumps with mempak-master found online. This is great.
2. the handling of flash saves is broken. If I save from a game, such as Paper Mario 64, the save is present (in game) on reload. If I then save again, the save becomes corrupt and the save slots show "Empty". This corruption is verified by comparing the before-and-after flash saves in a hex editor - there are changes introduced that render the save file invalid.
Ok, so I'm thinking of forking the code and fixing up a few other things I notice are off, such as the cursor appears in the wrong place on first access of the c-right ROM screen, and adding missing games to the database, or better still pull it out to an editable XML or similar file that anyone can add to. I would also like to expand the config file to specify all colors used in the code, and also to add an option to switch on/off the save versioning.
My question is to any other developers on here - does anyone have an idea what's happening with the flash saves? It could be a memory allocation issue, or some other data handling error. Any steers would be appreciated. The flash saving function works perfectly in the "stock" ED64P firware 1.28, so I know the cart can at least handle it.
One last thing, the font seems to be set in stone. There is a font.h file in the source but it does not get pulled into the build. I'm now assuming that the font is coming from the libdragon library which is pre-compiled. I know it's possible to insert a new font into the os64p binary, but this quickly becomes a pain when you are in a edit-test-compile loop. So if anyone has a tip here I'd welcome any help.
Thanks.
Last edited by deanodley,
Yes, from what I can see the code that handles saves has not been changed in a long time. I saw it mentioned in a thread somewhere that it is known that the save game function in altra64 is buggy. It's a positive that the first-time save works, just not the "reloads" - so hopefully the fix may not be too involved.
Update: the thread "ED64 Plus Altra64 (Custom Firmware) saving problems" seems to describe the same issue, but it went nowhere.
Last edited by deanodley,
The save function has been updated by moparisthebest in this commit:
https://github.com/ariahiro64/altra64/commit/3733e676f9e52632f1015a86a8e422e54fc18f22
I think gameblabla accepted a pull request that includes it, but he didn't publish a new release after that.
Oh, and about the thread you mentioned...
I asked OP for details and he never bothered to reply lol
Last edited by Xalusc,
Yes I saw that, but the change only creates a new file for each save. I'm still seeing corruption in second and subsequent saves. Using Paper Mario as an example, I copied a Level 1 save from Slot 1 to the other three slots but when I reloaded the game, two of slots were empty again. This happens in all the forks I have tried as they all share the same source.
Post automatically merged:
Looking at this some more, I started from scratch and created two first-time FLASH saves with exactly the same set up and then compared the files with a binary diff. They were not the same. Now I'm thinking that the issue might possibly be that the memory on the ED64 used to emulate the cart memory is somehow filled with random data at power on. In the case of the larger saves like FLASH, where there might be gaps in the written data, could this be causing issues? I wonder would it be a good idea to zero out this memory on boot and see does that help things...?
Last edited by deanodley,
I've been looking into implementing a different way of backing up saves. My idea is, when creating a save:
Also, I added a new configuration in Alt64.ini called save_backup. It enables backing up saves when set to 1, and disables it when set to 0.
I haven't committed any changes to my fork yet, by the way.
- check if romname.sav exists. If it doesn't, create romname.sav
- if it does, check for romname2.sav, romname3.sav, romname4.sav
- if all 3 exist, delete romname4.sav
- rename romname3.sav to romname4.sav etc.
- create a new romname.sav
Also, I added a new configuration in Alt64.ini called save_backup. It enables backing up saves when set to 1, and disables it when set to 0.
I haven't committed any changes to my fork yet, by the way.
I made those changes I mentioned.
https://github.com/Xalusc/altra64
I haven't compiled a new build or tested any of it yet.
Oh, and thanks @deanodley! Couldn't have done it without your tip.
https://github.com/Xalusc/altra64
I haven't compiled a new build or tested any of it yet.
Oh, and thanks @deanodley! Couldn't have done it without your tip.
Last edited by Xalusc,
No, this is "correct".
The menu doesn't need to write through the flashram emulation at all, so i didn't write the functions for it.
The Flashram content is at the same location as the sram on the cartridge memory, so it init the space via the sram function and put the cart in flashram emulation mode.
after hitting reset, the menu uses the sram funtion again to get the flashram save.
it's only a workaround. in theory the ed64 doesn't need to access the savegames in the same way as the game, because it can read and write to it's own shared game/savegame memory without the emulated interface the firemware provides.
The menu doesn't need to write through the flashram emulation at all, so i didn't write the functions for it.
The Flashram content is at the same location as the sram on the cartridge memory, so it init the space via the sram function and put the cart in flashram emulation mode.
after hitting reset, the menu uses the sram funtion again to get the flashram save.
it's only a workaround. in theory the ed64 doesn't need to access the savegames in the same way as the game, because it can read and write to it's own shared game/savegame memory without the emulated interface the firemware provides.
Here's the latest version, with changes made by someone called Suprapote.
They deleted their fork of the repo, but I pulled their changes into my fork before they did. If they're reading this, thanks.
Edit: use the release from their GitHub instead.
https://github.com/Suprapote/altra64/releases
They deleted their fork of the repo, but I pulled their changes into my fork before they did. If they're reading this, thanks.
Edit: use the release from their GitHub instead.
https://github.com/Suprapote/altra64/releases
Last edited by Xalusc,
You're welcome, I reopened my repo and i correct some things
PD: the flashram error isn't fixed.
PD: the flashram error isn't fixed.
It doesn't work too (idk if that is correct beacose i used a modified version for ED64P). Saturnu said the flashram is emulated beacose uses the same locations as sram.
Last edited by Suprapote,
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
The only CoD game I played that I truly enjoyed was Black Ops 1, and only the single player game. I just found the plot pretty interesting. -
-
-
-
@
Psionic Roshambo:
I think if I was making a list Modern Warfare 1 would be my second place spot, with stopping a crazed terrorist from starting world war three and all.+1
-
@
Psionic Roshambo:
I really didn't like playing online against other people always felt like I was being matched against children... Sorry it's your 7th birthday but I guess I'm supposed to mow you down anyway...
-
@
Psionic Roshambo:
I have reflexes a cat would be jealous of and a near psychic ability to read people, makes online play feel incredibly unfair. Ironically I have been booted from online servers for being a bot.... Or aim assist lol
-
-
