Author Topic: Odd behavior with save_db.txt (ED64 V3)  (Read 1198 times)

0 Members and 1 Guest are viewing this topic.

Offline IRL Random Hajile

  • Bounty Hunter
  • Full Member
  • ***
  • Posts: 137
  • Karma: +13/-0
    • View Profile
Odd behavior with save_db.txt (ED64 V3)
« on: May 08, 2021, 11:59 AM »
Alrighty, so this is something I wanted to share in regards to save_db.txt behavior.
So basically, I was playing on my EverDrive 64 V3 last night, nothing out of the ordinary at the surface. Then I randomly decided to look into this one game called Air Boarder 64 (heard some not-so-good things about it from others who have played through it, but I've been meaning to try it out of curiosity).
Have this PAL to NTSC patch applied to it since my CRT TV that I play my N64 games on only accepts 60Hz signal, and the patch actually works with no distorted video signal.
So starting it up, boots up fine with the logos and such, but then it just freezes to a black screen. Initially thought that maybe something went wrong with the patching process, but looking at the ROM info, the savetype lists it as EEPROM16k.
Odd... because looking into the database, I could have sworn that this game is supposed to save to EEPROM4k. At this point, I was starting to think that perhaps the entries added in my save_db.txt was causing a conflict here...? So as an experiment, I replaced my save_db.txt file in my ED64 OS folder with one that barely has any entries added. Looking at the game's ROM info again, now it correctly says that the game saves to EEPROM4k!
This doesn't make any sense to me because nowhere in my own personal save_db.txt file do I have Air Boarder 64's CRC HI value nor its ROM ID anywhere inserted in there. I also don't have any emulator CRC HI values added either as that can cause conflicts to happen to some random N64 ROM savetypes if said emulators are recognized in the "ED64" folder, at least with older firmwares.
Heck, even copying and pasting the entire list of entries from Kerr Avon's save_db.txt thread into a new .txt file, and looking at Air Boarder 64's ROM Info again says that the game savetype is EEPROM16k.
I should mention that I am currently using JonesAlmighty's Unofficial-Official ED64 OS v2.12.8 on my ED64 V3.
Now I'm starting to think that perhaps there's a weird bug with the old 2.xx firmware in how the save_db.txt values are handled. Of course, I can simply add the game's ROM ID or CRC HI value to get the correct savetype to show, but by doing that, would that end up making some other random N64 game unintentionally change its savetype? This admittedly has me rather confused.
"BH75001, Random Hajile... that's
R-A-N-D-O-M H-A-J-I-L-E."

Offline jonesalmighty

  • Sr. Member
  • ****
  • Posts: 252
  • Karma: +23/-0
    • View Profile
    • GitHub
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #1 on: May 08, 2021, 01:23 PM »
What is the roms ID and CRC High? I will check the db later.

Also, the 2.x OS does not recognise the second parameter like the new os (which sets region and rtc), so wondering if you have it on any of your entries.
Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth...

Offline IRL Random Hajile

  • Bounty Hunter
  • Full Member
  • ***
  • Posts: 137
  • Karma: +13/-0
    • View Profile
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #2 on: May 08, 2021, 02:37 PM »
What is the roms ID and CRC High? I will check the db later.

Also, the 2.x OS does not recognise the second parameter like the new os (which sets region and rtc), so wondering if you have it on any of your entries.

Air Boarder 64's ROM ID is "AB". The Unmodified ROM's CRC HI is "0x27C425D0" whereas the one with the PAL to NTSC patch applied is "0x89A498AE".
As for my own personal save_db.txt file that I use, it doesn't have a second parameter in any of the entries. I specifically removed the second number on all of them incase something weird does happen in advance (the second parameter is only meant to be detected on X7 OS, that I'm already aware of), but even so... this behavior still persists which confuses me even more.
"BH75001, Random Hajile... that's
R-A-N-D-O-M H-A-J-I-L-E."

Offline jonesalmighty

  • Sr. Member
  • ****
  • Posts: 252
  • Karma: +23/-0
    • View Profile
    • GitHub
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #3 on: May 08, 2021, 06:10 PM »
Looking at the internal save database, it is definitely set to "EEPROM4K", and there is no conflict with the ROM CRC that you have mentioned. I am wondering if the patched version is using the correct ROM ID (i.e. still "AB")?!

Feel free to DM me the ROM(s) and your Save_db if you want me to check the same on my console...
Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth...

Offline IRL Random Hajile

  • Bounty Hunter
  • Full Member
  • ***
  • Posts: 137
  • Karma: +13/-0
    • View Profile
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #4 on: May 09, 2021, 12:38 AM »
Looking at the internal save database, it is definitely set to "EEPROM4K", and there is no conflict with the ROM CRC that you have mentioned. I am wondering if the patched version is using the correct ROM ID (i.e. still "AB")?!

Feel free to DM me the ROM(s) and your Save_db if you want me to check the same on my console...
The patched version also uses the same ROM ID "AB". That part hasn't changed during the patching process. I can send you my own personal save_db.txt through DM to see what the heck is going on here because this just isn't making any sense.
Just to clarify, this behavior is happening on both the original unpatched ROM (No-Intro), and PAL to NTSC patched ROM since both have the same exact ROM ID.
« Last Edit: May 09, 2021, 01:47 AM by IRL Random Hajile »
"BH75001, Random Hajile... that's
R-A-N-D-O-M H-A-J-I-L-E."

Offline IRL Random Hajile

  • Bounty Hunter
  • Full Member
  • ***
  • Posts: 137
  • Karma: +13/-0
    • View Profile
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #5 on: May 12, 2021, 10:56 PM »
After some time spent troubleshooting, I finally found out what was causing this to happen in the first place.

In my save_db.txt file, there were two entries that were conflicting with each other, and those entries were:

"DP=5   (Dinosaur Planet)"
and...
"0x0DD4ABAB=2   (Donkey Kong 64 (U) (Demo) (Kiosk))"

Even though both of these games have entirely different CRC HI values, the ROM ID for both are shared, and having both of these included in the save_db.txt file causes Air Boarder 64's savetype to change from EEPROM4k to EEPROM16k. Pretty strange, but at least an answer has been found!
Gonna be waiting patiently for the upcoming OS v2.12.9 update from JonesAlmighty, as it's going to address both Dinosaur Planet, and Donkey Kong 64 Kiosk Demo's savetypes internally. That way, these games don't need to be mentioned in save_db.txt anymore.
« Last Edit: May 12, 2021, 11:06 PM by IRL Random Hajile »
"BH75001, Random Hajile... that's
R-A-N-D-O-M H-A-J-I-L-E."

Offline jonesalmighty

  • Sr. Member
  • ****
  • Posts: 252
  • Karma: +23/-0
    • View Profile
    • GitHub
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #6 on: May 13, 2021, 02:24 AM »
Lol, third time through the Dino Planet intro cutscene to get a save state  (why is it so long!!!)...

I will see if I can think of a way to handle duplicate entries, but might not be worth the effort (given how rare). BTW, DP has an internal save db entry for a different rom and the crc is checked after. I have adjusted that in my latest preview release, so would be interested if it leads to a different outcome. 
« Last Edit: May 13, 2021, 05:01 AM by jonesalmighty »
Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth...

Offline IRL Random Hajile

  • Bounty Hunter
  • Full Member
  • ***
  • Posts: 137
  • Karma: +13/-0
    • View Profile
Re: Odd behavior with save_db.txt (ED64 V3)
« Reply #7 on: May 13, 2021, 06:29 AM »
Lol, third time through the Dino Planet intro cutscene to get a save state  (why is it so long!!!)...

I will see if I can think of a way to handle duplicate entries, but might not be worth the effort (given how rare). BTW, DP has an internal save db entry for a different rom and the crc is checked after. I have adjusted that in my latest preview release, so would be interested if it leads to a different outcome.

Same outcome happens when those entries are left in save_db.txt using v2.12.9.PREVIEW, but it's not so much a big deal anymore since you've addressed Dinosaur Planet + DK64 Kiosk Demo savetypes in your latest OS update! So no need for those games to be in the .txt file anymore thankfully! Would be cool to have duplicate entries fixed up since it does kinda act like buggy behavior, but if it's too much work, then it's understandable. There's probably other things that are higher priority anyways in the development of your Unofficial-Official ED64 OS!
"BH75001, Random Hajile... that's
R-A-N-D-O-M H-A-J-I-L-E."