Emulator

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.

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.

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

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.

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.

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.

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?

*fast

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.

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

only a handful of games are > 50 blocks

I agree, There should only be one setting.

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.

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

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.

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

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.

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.

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.

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.

"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!

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.

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.

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.

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/

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.

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.

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.

Yes, it has nothing to do with this though.

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

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.

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.

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

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