- [Bugfix] Please stop using loveemu's gsfopt (and snsfopt) released before May 2018 by loveemu at 10:26 AM EDT on May 31, 2018
- gsfopt, snsfopt
I am afraid I have to say that there was a the bug of gsflib optimization, which would wipe necessary ROM data unexpectedly. The condition to cause the glitch might not be very common, but it might wipe the ROM data (especially a sample) quite slightly without being noticed.
See more detail of the issue
The glitch occurs when the song A refers to a certain address once, and another song B refers to the same address at least 255 times.
I will verify my own GSF sets and report if there is the one which needs to be fixed.
I apologize for the inconvenience.
Thank you for reading.
edited 10:28 AM EDT May 31, 2018
- by kode54 at 6:09 PM EDT on May 31, 2018
- Oh, you used counters. I never used counters in my coverage system, I just used boolean values. I also designed it so that there were two fields per coverage granularity of RAM regions. One field marked if it was read first before being written, the other marked if it was written first before being read. First field set would protect the other from being written. ROM is a little easier, since there's no write check to be done, heh. (This applies to my 2sf optimizer, and the USF code coverage tools I added to my lazyusf2 library.)
Glad you got that fixed up, though.
- by loveemu at 7:18 PM EDT on May 31, 2018
- @kode54 Thank you for your message.
The reason I used counters for the coverage is because I wanted to detect the loop count for the song length writer (option -t -T, I always overuse it for time-saving).
- by kode54 at 3:06 AM EDT on June 1, 2018
- Ooh, excellent idea. I wish I'd thought of that. Maybe it's not too late for me to add that to something. Oh well, maybe another time.
- by loveemu at 11:59 AM EDT on June 2, 2018
- I have verified my own GSF sets.
I have replaced their gsflib files. Could you update the ones at gsf.joshw.info?
* Yu-Gi-Oh! 7 Trials to Glory - World Championship Tournament 2005 [Yu-Gi-Oh! Duel Monsters International 2] (1 byte damaged)
* Hamtaro - Ham-Ham Games [Tottoko Hamtaro - Ham Ham Sports] (13 bytes damaged)
The following sets are not damaged. I compared reoptimized ROM to the current one and I verified they are the same.
* Donkey Kong Country 3 [Super Donkey Kong 3]
* Hamtaro - Rainbow Rescue [Tottoko Hamtaro 4 - Nijiiro Daikoushin Dechu]
* Yu-Gi-Oh! Worldwide Edition - Stairway to the Destined Duel [Yu-Gi-Oh! Duel Monsters International]
Actually, the bug indicator alerted to those sets, too. Those doubted bytes had been apparently covered later again.
Earlier Sets (I haven't invented my untrustful gsfopt at the time)
I want to redo the ripping of these someday, regardless of the bug.
* Di Gi Charat - DigiCommunication
* DigiCommunication Nyo - Datou! Black Gemagema Dan
* Family Tennis Advance
If there are more sets I have forgotten, I probably will verify them too.
edited 12:13 PM EDT June 2, 2018
- by MoldyPond at 12:05 PM EDT on June 2, 2018
- @loveemu Did you happen to notice when doing DKC3 if it sounded like the gain had been turned up an insane amount. Seems to be doing this since the GSF plugin version 3.0
- by loveemu at 12:24 PM EDT on June 2, 2018
- @MoldyPond No. I have read the relevant thread just now.
Having some trouble playing a few GSF rips.
At the moment, I am not sure it's an emulation bug or bad rip. Should I handle this? (i.e. redoing the ripping)
- by loveemu at 9:21 AM EDT on June 6, 2018
- Reoptimized every my gsf sets (excluding 4 earlier sets, since I want to redo the entire process for them, when I am motivated.) Now they are optimized with slightly loose paranoid parameters, to protect scattered unread samples.
HCS Forum Index
Go to Page 0
Search this thread
Show all threads
Reply to this thread:
Halley's Comet Software
Generated in 0.0025s;