Project

General

Profile

Emulator Issues #7481

Emulate Proper Memory Card timings

Added by JMC4789 almost 5 years ago. Updated 5 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Feature request
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
4.0-2227

Description

Game Name?

The Legend of Zelda: The Wind Waker - GZLE01
Metroid Prime - GM8E01
MVP Baseball 2004 - GVPE69

What's the problem? Describe what went wrong in few words.

Simply enough, memcard timings on all games are very, very off. This ignores the fact that the memcard timings cause issues in other games, such as the Japanese version of Wind Waker, and Gauntlet Dark Legacy on netplay (for some reason?) Those are already issues on their own; this is just focusing on save timings

Here's an example of memory card timings tested by me. This was done on saving, because reads were very fast, and I did side-by-side testing with console using a wavebird controller to verify that Dolphin was faster.

Wind Waker

Console - 1.41 - 1.55 seconds
Emulator - about .33 seconds

Metroid Prime

Console - 0.99 - 1.03 seconds
Emulator - Under .2 seconds

MVP Baseball 2004: Owner Mode

Console - 32.4 - 32.8 seconds
Emulator - 4.2 - 4.38 seconds

What steps will reproduce the problem?
1. Go into any game, and attempt to save. Note how long it takes, and compare it to console. In Metroid, this means beating the intro and flying to the main planet, in Wind Waker you can literally save after the first cutscene, and in MVP Baseball, just save in Owner mode or whatever it's called from the game modes menu.

Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?

4.0-2135, 4.0, 3.5, etc. It's never been proper.

What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)

Core i5 3570K, GTX 760, Radeon HD5850, Windows 7 x64

Additional Info:

Pull Request 581 fixes this issue > https://github.com/dolphin-emu/dolphin/pull/581


Related issues

Has duplicate Emulator - Emulator Issues #10828: PoP Sands of Time input delay on overwrite save dialogueDuplicate

History

#1 Updated by tueidj almost 5 years ago

The pull request isn't exactly correct since not all memory cards are created equal. For reading there's a latency amount (hardcoded as part of the card's ID) which necessitates a number of dummy reads to clock the EXI bus/nand chip before real data starts being returned. For writing there are certain cards (using samsung NANDs) that support "fast mode" which require no separate erase commands and can write 512 bytes at a time instead of 128.

#2 Updated by JMC4789 almost 5 years ago

The question is whether or not this is better than the current method. Thank you for the very valuable information about it, though, we're mostly testing via timings between console and emulator right now, without much homebrew assistance.

#3 Updated by JMC4789 almost 5 years ago

For some reason I was going to rename the issue, then decided not to, and left the name a mess. Fixing that.

#4 Updated by tueidj almost 5 years ago

My point was your console timing tests should not be considered valid test data since different physical cards will produce different timings. Changing the code to match them would not be acting like real hardware, it would be acting like YOUR hardware.

#5 Updated by JMC4789 almost 5 years ago

You're absolutely correct. I did try multiple physical cards, and did find that some were slower than others, and some were faster than others. I decided to do my testing with the official gray memory cards; particularly the one that came with my GameCube.

I don't know what else to say than that; I'm aware that the implementation on the Pull Request is not correct due information you gave, and I'm not sure I even have a fast mode memory card to do additional testing. I have Nyko, official black and gray, and an unmarked ones. The goal of the PR was to match the Official Gray memory cards that I had and used for timing.

#6 Updated by JMC4789 almost 5 years ago

I need to add that all the times mentioned in this issue report is using a launch day gray memory card that came with a launch day U.S. NTSC GameCube.

#7 Updated by badkarma12 almost 5 years ago

Being as improper memory card timings only cause issues in a few select games, would it be possible to only implement the proper timings as a game specific setting in the .ini and leave the vast timing for all other games?

#8 Updated by badkarma12 almost 5 years ago

*fast

#9 Updated by JMC4789 almost 5 years ago

While it would be possible, it would make the code much messier and cause possible settings issue for movies, TASes, netplay, etc. For most games, it's the matter of a second or two.

#10 Updated by lpfaint99 almost 5 years ago

no game specific setting please
avg game is likely to be < 10 blocks

only a handful of games are > 50 blocks

#11 Updated by phire almost 5 years ago

I agree, There should only be one setting.

#12 Updated by JMC4789 almost 5 years ago

This issue won't be closed when the PR is merged, or if I do close it, I'm going to make another one "Emulate Proper Memory Card Timings Better" or something, because I don't want people to forget this still isn't perfect.

Otherwise, PR looks primed to merge.

lpfaint99: MVP Baseball 2005 has a save in the 180 block range.

#13 Updated by lpfaint99 almost 5 years ago

maybe a handful was too small a number :)
largest I am aware of is NCAA Football 2005 (takes 220 blocks)

#14 Updated by redherochildboss almost 5 years ago

Would it be possible to have an option in the "hacks" section to use the "bad" fast timings instead, like how we can use fast disk transfer rates instead of the accurately emulated disk speeds?
I know it's only a difference of a second or two, but speaking for myself at least, those seconds do matter to me.

#15 Updated by JMC4789 almost 5 years ago

@ Red - There was a discussion about this. The reason we aren't keeping the fast timings isn't just that their inaccurate/cause glitches, but because it creates a settings dilemma. If you want faster memory card saves with a valid issue, after this is merged you could probably ask for the faster memcard support that was mentioned above.

An emulator's core goal is to accurately emulate the console. The main reason fast-disc speed survived the accurate disc speed merge is that there are other bugs with the DVD loading that required the fast-disc path to still exist for debugging and to keep certain games playable.

If you really think it is an issue for your experience, and I completely understand your concerns, this is exactly the right way to handle it. Your best bet would be for someone to implement the faster memory cards that were introduced for GameCubes, or for a less intrusive method of the fast-path that exists prior to this being merged. Just remember that it would have to survive the review process, and various developers have their own viewpoints.

Considering how poorly people handle fast-disc speed (they enable it for games it does not work on, then complain on the forums about it not working,) I really don't see a good way to handle it. And because of how rare the issues are (and I don't doubt there are more that were unreported) it'll be very difficult to pinpoint the blame outside of the few we know about.

LPFaint99: 220 blocks. And I own that game. May time it if I can fit it on a memory card.

#16 Updated by redherochildboss almost 5 years ago

JMC: So, to be sure I understand what you suggest: after this is merged, I should make an issue asking for emulation of the faster memory cards instead of just the official Nintendo ones?
And yeah, point taken. I know I've messed up emulation on my end by enabling some hacks.

#17 Updated by JMC4789 almost 5 years ago

That's what I think would be the best solution for everyone. It may not be done right away, but considering what was said in this issue report, it's definitely possible and an accurate way to handle things, meaning that when it is done there will be no question whether to merge it or not.

#18 Updated by tueidj almost 5 years ago

Note that the "fast" memory cards are only supported by later games, not all. It might even have been up to individual game developers to implement support for them, I don't remember the details.

#19 Updated by JMC4789 almost 5 years ago

Oh, that makes it a lot more complicated then.

That more or less makes me think that there shouldn't be faster memcard support, but ultimately the goal should be to let the gamecube accurately query the memory card and figure out if it's a fast memory card, and then writing at the increased speed. Whether there should be a user option for it or not, I'm not entirely sure. Burn that bridge when we get there, I guess.

#20 Updated by kodiacktech almost 5 years ago

"An emulator's core goal is to accurately emulate the console."

While "accuracy" may be the core goal, I cannot agree with the complete removal of the current behaviour. In most games, the slower memory card writing isn't going to provide any tangible benefit. If this merge were to go live in its current state, I would simply refuse to include it when I compile my own builds. I suppose that's the joy of an open source project, though. :)

There definitely should be an option somewhere, in my opinion. It could fit comfortably in the GameCube configuration tab, and can be enabled by default.

Also, for what it's worth, I make use of the disc transfer rate speed-up option as well. I try it individually in games. It's also one of the first options I look at disabling if I run into abnormal behaviour. The improvements are vast in some titles, however. Load times may drop from 10+ seconds to becoming near-instantaneous with absolutely no regressions in gameplay.

Again, emulators should strive for accuracy, but in my opinion they should also be open to improving upon an original console's implementation if possible, which the current memory card writing does. Just look at all of the choices available for internal resolutions, texture filtering, anti-aliasing, and custom textures!

#21 Updated by JMC4789 almost 5 years ago

If you think a fast memory card path is so much better, why not implement it yourself after the merge? I really don't want to delay it being merged due to having to implement a UI/INI option + the argument over whether the fast-path should be kept. It may be as simple as setting the read/write speeds extremely high and putting an option somewhere.

I'm not saying you're wrong, but, in most games memory card saves are better now. In Tony Hawk Pro Skater 3/4, the memory card saves/loads actually get faster with the more accurate timings (they take abnormally long in Dolphin right now, and are a bit faster with more accurate timings. Don't ask me why)

If it's an important feature, I really implore you not to keep it to yourself.

#22 Updated by kodiacktech almost 5 years ago

I've been thinking about how I would implement an option, and if I believe I end up with good solution, I'd love to share it.

I don't have anything against the merge itself proceeding in its current form, by the way. It's good to fix issues and be more accurate. I just don't want to see the possibility of having an option to toggle the speeds be shot down.

#23 Updated by JMC4789 almost 5 years ago

I'm not shooting it down as much as saying that it probably doesn't belong in this commit. I think a new fast path (where we set higher write/read speeds) may not cause issues and still be very fast. If it doesn't break the games that were fixed by the higher accuracies, then it'd be safer than the old fast-path.

#24 Updated by JMC4789 almost 5 years ago

I will make a new issue before closing this one, as I don't want it to be forgotten that Dolphin is not perfect with how memory cards work.

The issue I was reporting is fixed in 4.0-2227 > https://dolphin-emu.org/download/dev/963e1a698cbeaa976a7f8e8020880a50267ecd69/

#25 Updated by JMC4789 almost 5 years ago

So, things get more confusing. Tueidj, you said that mostly newer games would be able to act with the faster memory cards, but Cosmo was having the save error in WW-J on console with a third party memory card he was having. Are there other ways for a memory card to just be faster?

The more I look at GameCube speedrunning, the more I think a fast memory card option may actually be viable and wanted, even if it causes problems in a few games. It really does appear memory cards can approach those fast speeds. I have three third party memory cards, and none of them are that fast, so I really can't get timings.

I think fast-memcard would be a game-ini option at best? I think I'd need to buy whatever memory card Cosmo and others are using to get faster save times, and then compare them to Dolphin and try to figure out what timings/speeds are changed. It'd be neat for the memcard files/folders in Dolphin to have identifiers that could point out their speed, much like real GameCube memory cards apparently can tell their speed to the console/games.

#26 Updated by JMC4789 almost 5 years ago

I managed to find an old memcard that was fast enough to reproduce the WW-J hang on console. The goal now is to make Dolphin robust enough to accurately handle memory card read/write speeds regardless of what they're set to. Currently, that's just not happening.

We're also trying to figure out how the Dummy Reads work.

#27 Updated by progamer96 almost 5 years ago

You guys know about the memcard related crashes in dolphin when exiting the emulator after saving to the memory card? Because it's reproducible about 90 percent.

#28 Updated by JMC4789 almost 5 years ago

Yes, it has nothing to do with this though.

#29 Updated by tueidj almost 5 years ago

"The goal now is to make Dolphin robust enough to accurately handle memory card read/write speeds regardless of what they're set to."

I don't really understand this statement. It's the games (not Dolphin) that are making assumptions about card speed, for example I bet this WW-J hang is caused by the game setting an asynchronous callback after initiating the asynchronous operation (so the operation finishes before the callback is set and it never gets called). The same issue occurs with almost any DMA operation such as disk reads and ARAM transfers. Unfortunately nothing can be done about it besides matching the original timing.

#30 Updated by JMC4789 almost 5 years ago

But there are memory cards on console that can cause that problem. If Dolphin is robust enough, we should be able to have memory cards with different speeds. If someone set a memory card to run as fast as the Max Drive Pro and caused games to glitch, then I think that should be an option. Faster memcard saving can be done on console; my understanding when I opened the issue was pretty poor. I've learned so much about memcard timings and how much they can vary based on the device, and how much it's aged. Third Party cards are all over the place.

Memory card timings are fairly good with write speeds in Dolphin compared to the default gray memcards, but the read speeds are very slow. Dolphin's EXI emulation has a bunch of weird problems right now that are being looked at. I mostly did a bunch of memory card benchmarks. If you'd like to see the information, it's in this spreadsheet.

https://docs.google.com/spreadsheets/d/1W2BfG27hU7kKPvPIhiHNREb6z7GT2d2zZeKK53ph6lE/edit#gid=0

they've recently gone much lower level than that test application, but Dolphin is acting a bit weird with things, so it may be a while until things are acting properly.

#31 Updated by tueidj almost 5 years ago

Read timing can't vary, it's driven at a fixed rate by the current EXI clock. The only difference between one physical card to the next is the number of dummy reads required (also referred to as latency), which is identified by the first memory card ID byte.

#32 Updated by loganstromberg over 4 years ago

I think the new timing changes are a good idea because I agree with the principle of making the emulator be as close as possible to the actual console, but it feels like the new change wasn't coded very well (I'm playing r2826, the Aug 31 build). Is it using a spinloop to simulate the delay or something? Games like Animal Crossing and F-Zero will feel like they're freezing up, running at 1-2fps while loading is going on and messing with the audio and stuff. It's very annoying, especially in games that autosave frequently when other action is going on. Just wanted to bring this issue up here

#33 Updated by JMC4789 over 4 years ago

It's not the new timing changes causing the stuttering, it's a threading change by shuffle2.

#34 Updated by JMC4789 about 1 year ago

#35 Updated by JosJuice 5 months ago

  • Fixed in set to 4.0-2227
  • Status changed from Accepted to Fixed

Also available in: Atom PDF