ED64 Plus... my impressions. Any Owners around here?

[Elru]

Hey, so I built the latest Altra64 commit from AriaHiro's fork, in case anyone's interested

https://www.mediafire.com/file/za3wgdm6v7kw5zc/Altra64-20221008.7z/file

Can you build that version, but without the "automatic save backup"? Or isn't possible?

 

[Shadow_The_Hedgehog82]

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?

 

[Xalusc]

Can you build that version, but without the "automatic save backup"? Or isn't possible?

Only if I make changes to the code, which I didn't yet. But I can try when I have the time.

 

[deanodley]

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.

 

[Xalusc]

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.

Interesting. I never noticed those issues before.
Does #2 happen under gameblabla's fork as well?

 

[deanodley]

Interesting. I never noticed those issues before.
Does #2 happen under gameblabla's fork as well?

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.

​

 

[Xalusc]

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.

​

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

 

[deanodley]

The save function has been updated by moparisthebest in this commit:
<link removed>.

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

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: Nov 23, 2022

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...?

 

[Xalusc]

I've been looking into implementing a different way of backing up saves. My idea is, when creating a save:

1. check if romname.sav exists. If it doesn't, create romname.sav
2. if it does, check for romname2.sav, romname3.sav, romname4.sav
3. if all 3 exist, delete romname4.sav
4. rename romname3.sav to romname4.sav etc.
5. create a new romname.sav

Problem is, I don't know how to rename a file in the SD card yet. I don't know if the "normal" C function rename() would work here. But I'll give it a shot.



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.

 

[deanodley]

I've been looking into implementing a different way of backing up saves. My idea is, when creating a save:

1. check if romname.sav exists. If it doesn't, create romname.sav
2. if it does, check for romname2.sav, romname3.sav, romname4.sav
3. if all 3 exist, delete romname4.sav
4. rename romname3.sav to romname4.sav etc.
5. create a new romname.sav

Problem is, I don't know how to rename a file in the SD card yet. I don't know if the "normal" C function rename() would work here. But I'll give it a shot.



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.

interesting ideas. The function to rename a file is called f_rename(). It's declared in "ff.c" and takes pointers to the object and new name.

 

[Xalusc]

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.

 

[deanodley]

I made those changes I mentioned.
<link removed>

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.

Good work!! I will check that out as soon as I get some free time.

 

[Suprapote]

I think this is why the flashram doesn't work properly:

this is at utils.c at line 330. PD: i don't know how to fix it.

 

[saturnu]

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.

 

[MrCokeacola]

So who's gonna be the first person to make the definitive firmware for the ED64/Super 64 in 2023?

 

[Xalusc]

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

 

[Suprapote]

You're welcome, I reopened my repo and i correct some things

PD: the flashram error isn't fixed.

 

[Xalusc]

About FlashRAM...

I think it worked on saturnu's original Alt64, right?
What could have changed that broke it?

 

[Suprapote]

About FlashRAM...

I think it worked on saturnu's original Alt64, right?
What could have changed that broke it?

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.

 

[bum2kev]

Can someone add a feature where I can hide the file extension shown within the Altra64 ui? Ideally it could be configured in the ini for example:

show_extension=0/1