Let derived CDROM devices asynchronously lag their calls #2622
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously these calls would return within the same tick, producing result that were not typically possible on real hardware. With real hardware, delays were made up of the query and response trasvering: 1. MSCDEX to 2. CDROM Driver to 3. IDE controller to 4. CDROM controller board to 5. (possibly) actuators to move the head positioning 6. (possibly) Picking up the track and reading the data 7. Sending the query response back up the chain. The first generation of 1x and 2x CDROM drives had worst-cast repsonse times of up to half a second, but typically were in the 300 ms range (most of it spent in the track seek). Faster drives and hardware caching brought these times down to fractions of these. Some software expects (and worse, even assumes) that back-to-back responses cannot occur essentially isntantaneously, as ripsaw8080 explains for Chasm: The Rift: ~~~ Chasm: The Rift does indeed decide not to loop audio tracks, and ultimately it is an issue of timing. When using an image, the game concludes that playing has failed because the current frame appears not to advance over three successive checks. DOSBox processes the checks so quickly that the frame doesn't have time to advance. I haven't tested this, but playing audio from a physical CD might loop because of delay in reading the device. On real DOS systems there would be code overhead in MSCDEX and the CDROM device driver, but in DOSBox there is practically none. The attached TSR program adds overhead to the MSCDEX function that reads the current frame, ensuring that the frame counter will have advanced between checks. This workaround could be useful for anyone who is using an image and would like the CD audio to loop; simply run the program before running the game. Assembler source is included in the archive. Ref: https://www.vogons.org/viewtopic.php?p=225579#p225579 ~~~ Thanks, ripsaw8080!
kcgen
added
bug
johnnovak
reviewed
Jun 20, 2023
johnnovak
reviewed
Jun 20, 2023
johnnovak
reviewed
Jun 20, 2023
3 tasks
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR simulates the delay a physical CD-ROM drive took to respond to queries.
This fixes picky games that (expect/assume) that real hardware always had some delay, and therefore back-to-back queries should report monotonically increasing Minute-Second-Frame (MSF) time values.
Fixes Chasm : the Rift's music, which previous failed to loop (resulting in the game eventually going silent), as ripsaw8080 nicely explains: https://www.vogons.org/viewtopic.php?p=225579#p225579