I would be interested in hearing how the PS1 handles it, as it's the console that immediately comes to mind when I think of disc swapping tricks.
I can't be sure it's safe to proceed without this technical insight. Does anyone know this detail, or maybe where to look for it?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
So we're hitting a bottleneck with PCem (which will be the same for 86Box and even PCBox). Maximum speeds of fastest CPUs they emulate are not enough for some newer (compared to CPUs) games that would otherwise work fine on them.
People have tried simply increasing the clockrate of Pentium2 up to 2GHz and it really helped with a lot of lag. But Pentium2 never worked at anything like that, best it could do was 450MHz. 2GHz was out of reach until Pentium4 in 2001.
Emulation of P4 is not gonna happen soon, because people who work on those emulators consider even emulated P3 too slow for usage, and P4 is not only a faster CPU (hence slower emulation) but also has lots of features P3 didn't have.
There's progress in making QEMU work in libTAS, but I'm pretty sure I'm the only person who tried it aside from keylie who made it work in the first place.
So until we make qemu+libtas stable, I feel we should allow speeding up PCem if it doesn't cause glitches. It wouldn't be emulation of an overclocked CPU, but rather overclocking the emulation of a CPU.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 10/12/2011
Posts: 6558
Location: The land down under.
As one of the people who cannot actually run the verification movies for either 95/XP, because I get desyncs on them.
I'm against it, due to it's being just another level of inaccessibility that I'm personally having, so having a higher core just makes it more of a headache to me personally.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Strong for yourself and also others.
To note a few things. This won't suddenly enable every modern game to be played in PCem, because of processor instruction sets (like SSE) that Pentium 2 doesn't support, and other limitations.
There has been a TAS created with the 2GHz CPU:
Link to video
I don't know how difficult the process was and what FPS they got while making it (450 MHz is already quite slow to work with).
I wasn't aware of anyone experiencing desyncs on existing PCem movies from poor performance. If that's the case then it's probably worth making a couple of test movies to check sync with others.
Also I assume this discussion will also apply to DOSBox in BizHawk, which may be more popular and I could see people requesting this in the future.
Staff discussion so far resulted in agreeing to allow this, just noting everywhere relevant that it's an impossible hack and should not be used unless it's needed. And when it's needed, it's best to be explicit about its usage (and reasons).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
There has been a TAS created with the 2GHz CPU:
Link to video
Actually, I believe the guy who made that TAS (I helped him set up pcemcompiled, his name is LookingForDreams) ran the game on both 800 and 2000mHz, and he chose to do 800 because of the same loading speed, but I made a TAS of the game that only worked on 2000mHz, even though the requirement said Pentium II 450mHz, when I tested the game, it lagged drastically. As for the emulation speed, only the Windows XP startup slows down drastically, everything else feels about the same or tiny bit slower than 450mHz.
Here is the TAS:
Link to video
And also, I posted LFD's Zuma TAS on my channel, I encoded it myself (there's an encode on his channel too, but due to it being on original resolution, 800x600, the youtube converted the 50fps video to 30, so I wanted to make sure high quality encode is uploaded somewhere, along with his permission, which he gave me), the movie does sync only IF everyone has the same hashes as the TASer's, so I asked him to send me .img, .nvr, .bin, and everything synced perfectly.
I would be interested in hearing how the PS1 handles it, as it's the console that immediately comes to mind when I think of disc swapping tricks.
I can't be sure it's safe to proceed without this technical insight. Does anyone know this detail, or maybe where to look for it?
I talked to people on PSX.Dev discord and they told me this:
It's possible for games to detect lid opening ("the mechacon sends an error interrupt if you open the shell; no, most games did not handle this"), which resets the "disc valid" flag.
It's impossible to detect disk removal.
If you open the lid, replace the disk, and close the lid, that disk will be checked for validity (by trying to read the wobble groove, which restores the "disc valid" flag if it succeeds) and then the TOC will be read. Then the game could "check for some expected file on the disc when the lid is closed again" to see if it's a disk it wants. Retail PSX games didn't do this tho.
It's impossible to detect disk swap altogether if the lid sensor was manually pressed and held in place. Lid opening won't be detected until you release the sensor. The old TOC persists and any new disk you insert is treated like the old disk is still there.
It's possible to periodically verify data on a given "current" disk, but it's completely impossible to bail out the instant it's wrong-swapped. Because no matter how often you check validity of the current data, the swap may happen between the checks and then there'd be completely different code running. Reading from the disc is not instant either.
Thanks to Stenzek, spicyjpeg, and smf!
So we can't say that "failing to detect an erroneous swap" is the developer's fault and a bug, if the disk was swapped without letting the lid sensor know that the lid was opened. If we close the lid normally, play the game, open it again and put in the wrong disk, or the right disk but at the wrong time, then it's up to the game to check its validity and refuse to proceed.
But it'd be weird to differentiate those 2 in emulation, because there we're not forced to close the lid in order to launch the game, and there's no way to emulate whether it was closed for real or whether we just fooled the sensor without closing it...
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
