-
Notifications
You must be signed in to change notification settings - Fork 88
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
Hardware-Accelerated FAT filesystem searching #766
Comments
Positive side effect, is that it will greatly improve the speed of the most common SD card file operations. |
Also, as it only reads the SD card, not modifies it, this functionality can be exposed to applications that want to access the SD card directly. |
An optional extension would be to report if a file is fragmented or not, so that the disk mount logic can be simplified in HYPPO, also. |
First, some house-keeping to track the request:
The request would also need to know:
With those 16 bytes, it has all the information it needs to know to traverse a FAT file system. Then we can add information about where in the traversal we are up to:
That is, with another 42 bytes, we have a complete record of where in the search we are up to. Thus the total request needs to use only 16+42 = 58 of the 512 bytes of the sector buffer, and thus could allow absolute paths of up to 512 - 58 = 554 bytes (null termination can be implied, if the path extends to the end of the sector buffer). For longer paths, multiple calls would be required, and could be handled by munging the starting point of the search. But this should not be required. |
The probable algorithm would be:
|
Is your feature request related to a problem? Please describe.
Considerable discussion is occurring as to how we can make HYPPO and the MEGA65 better live with subdirectories. A key challenge is that the HYPPO ROM is very space-limited, and thus remembering paths is currently a bit problematic. And even if we did, HYPPO is not particularly fast at traversing through a FAT file system to set the CWD to a particular directory. The findfile logic in HYPPO is also already quite large, as well, occupying space that could be better used for other functions, if we could simplify it.
Describe the solution you'd like
Describe alternatives you've considered
Persisting with the software implementation, which continues with the existing challenges.
Additional context
This functionality would allow for the better handling paths in HYPPO, including remembering the full path to each mounted disk image, in parallel to the current working directory of the running application.
The text was updated successfully, but these errors were encountered: