-
Notifications
You must be signed in to change notification settings - Fork 381
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
Add IMD floppy file format support #711
Comments
This is something I could potentially help with, given I have the time (occasional weekends), if you like @joncampbell123 . Probably not this weekend. |
@Shane32 I appreciate the help! Hold off until after the next release I have planned for June 1st. |
No problem. I noticed you were working in the relevant files, and certainly won't be making modifications while you're actively updating those files. Although I've been busy, I was thinking that ideally when loading an image, the code (whether initiated by imgmount or boot) would loop through the supported file types, scanning for a match for the 'magic code' and/or checksum, or match on a file extension. Finally, a user might manually define the chs. Make sense? The question is, in which order are these applied? For example, as it is today, manually entering a chs value when mounting a static vhd file ignores the vhd footer and loads it as a raw file -- and since there's no bounds checks, the footer can potentially be overwritten by the vm. I'm thinking the logic should be:
There is a final question as well: what is the determining factor whether the mounted image is a floppy? Right now it's based on if the file size <= 2880kb. What about zip disk / superdisk emulation? Ignore that? We could also search for a MBR or similar to make the determination. I guess just let me know if you think anything besides the <=2880kb check would be better. I'd suggest leaving it as-is, but allow for the -t switch (-t floppy or -t hdd) to override the interpretation of the image. As long as you approve of these global changes, if and when i have time, I'll add a function to each class for detecting if a given FILE (handle) matches the header/footer of the class. A loading function will open the file (readonly if necessary), detect the file type via each class's detect function, and select and load the file with the detected file type. Format detection code will me moved out of the fatDrive constructor to a more appropriate location within the new structure. Classes will all be modified to have basic support of readonly images, and include bounds checks on read/write operations. And finally, imgmount and boot will both be modified to use the same loading function when mounting an image. (In addition to supporting the new file format mentioned above, of course.) |
The only other think I'm thinking about is if you'd want to add a imgmount command line switch to force mounting as a raw image, without file type detection. Since renaming the file to .raw (for example) wouldn't be effective any more. |
Coming from Linux and it's "mount" command, I would add it as the "-t" flag except in DOSBox/DOSBox-X that's already used to specify whether the image is hdd, floppy, or cdrom. So the image type would have to be a different parameter. Perhaps "-it" or "--image-type"? |
Right: -t would remain to override the floppy/hdd detection (normally <= 2880kb is floppy). So -it could specify the image type. If we did that, I would suggest deleting -t ram and using -it ram instead to specify a ramdisk. So the new parameter would be something like this: Specifying the new parameter should result in a more meaningful error being displayed if the file fails to open. |
How i can mount an hdi image file ? . i need extract files from one |
You should be able to mount it with IMGMOUNT: IMGMOUNT C: FILE.HDI |
Thank you very much |
https://www.vogons.org/viewtopic.php?f=41&t=31881&sid=26d0885e377d1db39344be83269a8928&p=671163#p671163
See some source code here:
https://github.com/atsampson/dumpfloppy
Games to test:
The text was updated successfully, but these errors were encountered: