New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the mechanism to access mounted files #93
Merged
Konamiman
merged 12 commits into
v2.1.1-beta2
from
change-file-mounting-to-sector-based
Mar 22, 2022
Merged
Change the mechanism to access mounted files #93
Konamiman
merged 12 commits into
v2.1.1-beta2
from
change-file-mounting-to-sector-based
Mar 22, 2022
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
This stores the first data sector of the file that's mounted, relative to the start of the drive (3 bytes, we assume 4th byte is always 0). Also, _GDLI temporarily returns that first sector number.
When mounted files were accessed via file access functions some extra code to save and restore variables was needed since these functions are not reentrant. Now that the mounted files are accessed via direct sector access, this extra code is not needed anymore.
Once mounted files are accessed via direct sector access there's no need to keep the mounted file open. So: - Remove the code that opens/closes the file on mount/unmount. - Store the file name in the unit descriptor, for _GDLI. - Check the read only mount flag explicitly in CALL_UNIT. - Remove no longer needed auxiliary code and variables.
_MAPDRV will return an .ICLUS error if the file to mount is not stored across consecutive clusters (i.e. it's fragmented).
Also reword "Invalid cluster number" error message to "Invalid cluster number or sequence".
* Add new "Invalid cluster sequence" BASIC error to user manual. * Mention that a file must be stored across consecutive sectors to be mountable in the user manual. * Mention that MAPDRV requires a file to be stored across consecutive sectors to be mountable, in the programmers reference. * Mention that .ICLUS is returned by MAPDRV if a file to be mounted is not stored across consecutive sectors, in the programmers reference.
Konamiman
force-pushed
the
change-file-mounting-to-sector-based
branch
from
September 1, 2021 10:47
8f51a36
to
2a9b551
Compare
theNestruo
suggested changes
Jan 13, 2022
Konamiman
changed the title
Change the mechanism to access mounted files from file based to sector based
Change the mechanism to access mounted files
Mar 22, 2022
Is there an easy way to defragment a file? It is something that people encounter, and the current fix that I know of is “copy everything to your PC, format the drive, and copy it back” which is not so nice. Would be nice if there was a DOS2 call for it (a conditional copy to unfragmented space), this could then be used by a utility command as well as MAPDRV, EMUFILE, etc. |
Merged
Konamiman
added a commit
that referenced
this pull request
Mar 22, 2022
vipoo
pushed a commit
to vipoo/Nextor
that referenced
this pull request
Oct 4, 2023
Change the mechanism to access mounted files from file based to sector based. - A new restriction is introduced: a file needs to be stored across consecutive sectors in disk in order to be mountable. - Message for error .ICLUS has been changed from "Invalid cluster number" to "Invalid cluster number or sequence". - New BASIC error code introduced: code 82, message "Invalid cluster sequence". - The _GDLI function call will now return two extra values for a drive that has a mounted file: "start cluster" and "start sector"
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.
Nextor allows mounting disk image files to drives since version 2.1.0.
Internally, the mounting mechanism was originally implemented as follows: the mounted file is kept open and whenever sector access is needed for the mounted file, the sector number is translated into a file location which is set as the current file pointer for the mounted file, then the regular file read/write functions are invoked.
This mechanism worked but it was somewhat convoluted since the file access code was not originally designed to be re-entrant and now it was calling itself (reading from a file inside the mounted drive involved executing the file read/write functions, which would in turn invoke themselves again); a "calling level" variable had to be kept and some internal variables had to be backed up before the second call and restored afterwards. This never worked really well, there were instances where accessing a mounted file would cause a computer crash.
This pull request modifies the way files are mounted. Now a mounted file isn't kept open; instead, the unit descriptor for the drive where the file is mounted will store the sector number where the file begins (absolute device sector number), and this number will be added to the sector in the mounted drive being accessed.
This implies that a new restriction is introduced: a file needs to be stored across consecutive sectors in disk in order to be mountable. If that's not the case, trying to mount the file to a drive via the
_MAPDRV
function call will return an.ICLUS
error (whose message has been changed from "Invalid cluster number" to "Invalid cluster number or sequence"); when trying to mount the file viaCALL MAPDRV
in BASIC, an "Invalid cluster sequence" error will be thrown (this error has code 82 and didn't exist previously).Note that this change applies only to the mechanism for mounting files to drives using
MAPDRV.COM
orCALL MAPDRV
after booting Nextor in normal mode. The disk emulation mode has been using a "sector offset" based approach and requiring consecutive clusters since the very beginning.Additionally, the
_GDLI
function call will now return two extra values for a drive that has a mounted file: "start cluster" and "start sector", see the programmers reference for the details.