Skip to content
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

Open
Shane32 opened this issue May 10, 2018 · 9 comments
Open

Add IMD floppy file format support #711

Shane32 opened this issue May 10, 2018 · 9 comments

Comments

@Shane32
Copy link
Contributor

Shane32 commented May 10, 2018

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:

  • Knight Force
  • Where in the world is Carmen Sandiego?
@Shane32
Copy link
Contributor Author

Shane32 commented May 10, 2018

This is something I could potentially help with, given I have the time (occasional weekends), if you like @joncampbell123 . Probably not this weekend.

@joncampbell123
Copy link
Owner

@Shane32 I appreciate the help! Hold off until after the next release I have planned for June 1st.

@Shane32
Copy link
Contributor Author

Shane32 commented May 31, 2018

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:

  1. Scan the file to determine the file type, based on 'magic code' and checksum in the header
  2. For other file types (without a well-defined header/footer), select file type based on file extension
  3. Fall back to a raw image
  4. If the chs value is specified, override the chs values of the mounted image with those provided by the user

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.)

@Shane32
Copy link
Contributor Author

Shane32 commented May 31, 2018

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.

@joncampbell123
Copy link
Owner

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"?

@Shane32
Copy link
Contributor Author

Shane32 commented May 31, 2018

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:
[-it raw|fdd|fdi|d88|vfd|vhd|vhdx|hdi|imd|qcow2|iso|ram]

Specifying the new parameter should result in a more meaningful error being displayed if the file fails to open.

@inukaze
Copy link

inukaze commented Apr 22, 2019

How i can mount an hdi image file ? . i need extract files from one

@joncampbell123
Copy link
Owner

You should be able to mount it with IMGMOUNT:

IMGMOUNT C: FILE.HDI

@inukaze
Copy link

inukaze commented Apr 22, 2019

Thank you very much

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants