Harddisk corruption when expanding to 32M

[sjaaq]

I am working on a MSX application that is running in DOS2.xx from a HD image. I have put all the files in a zip and are using the following parameters to run the image, ie:

https://webmsx.org/?M=MSX2E&Z80_CLOCK_MODE=2&P=OPL4&MOUSE_MODE=1&HARDDISK_FILES_URL=https://host.com/download/disk.zip&MOBILE_MODE=0

This worked until the image expanded from 16M to 32M. Now it won't boot DOS anymore but goes straight to BASIC. If I do a FILES command in basic it throws an "Bad drive name" error.

The 32M size is reported when webmsx starts, the 16M size I was able to verify using the CALL FDISK command. CALL FDISK with a 32M partition actually freezes the interface:

The strange thing is, the image still had 4M free, so I am not sure why it changed to a 32M image. I am also building a disk image file to use for OpenMSX, which still reports 4MB free. If I use the (16M) image in webmsx, it does boot, but fails at the command2.com (assumed):

I guess those images are not compatible.

[sjaaq]

I have found a workaround. I have created a new HD images from WebMSX (32M). This image is mountable in linux. So I just insert the files in the WebMSX image and use that one with the HARDDISK_URL parameter.

[ppeccin]

Hi! Regarding your first message. Are you running the emulator and loading an already made Harddisk IMAGE file, or are you loading a ZIP file with several files for IMPORTING into the disk? Those are 2 different functions! For the first one (IMAGE), you use the HARDDISK_URL parameter, for the second one (import FILES) you use the HARDDISK_FILES_URL parameter. On the first form, the emulator will first try to find an IMAGE file among the files or ZIP file you specified. On the second form, it will always create a new disk image automatically and then import all the files, it will never try to find an existing image. Since you said "I have put all the files in a zip", I believe you are using the wrong parameter! Please always import a single file or a bunch of files from a ZIP using the HARDDISK_FILES_URL parameter. Can you please change it and test again? About the image size... When you use the auto import of files to a new automatic image, the emulator chooses the image size based on the total size of the files you are importing + 30% of free space, so you can create additional files. That explains why the image size increased from 16M to 32M. You might have found some bug on the file import function... But I believe it may just be the wrong function being used. For instance, if your bunch of files includes any valid disk image, the emulator will mout it instead of auto-importing all files when you use the wrong parameter. Please let me know if it works! Regards, Paulo

…

On Thu, Feb 4, 2021 at 8:30 AM sjaaq ***@***.***> wrote: I have found a workaround. I have created a new HD images from WebMSX (32M). This image is mountable in linux. So I just insert the files in the WebMSX image and use that one with the HARDDISK_URL parameter. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLIE2VRUYXWKNGXFHX43S5KAMPANCNFSM4W5ER35Q> .

[sjaaq]

Hello Paulo,

In the opening post, I was using HARDDISK_FILES_URL which pointed to a zip file. That one broke when it expanded from 16 to 32M.

The application am I working on has been in development in the past year and I was able to run it on multiple devices in that time with the HARDDISK_FILES_URL parameter.

I can only assume it is some kind of bug in the import function, as you described.

Best regards,
Maarten

[ppeccin]

Are you sure you were using HARDDISK_FILES_URL and not HARDDISK_URL? Because it is wrong on the link you provided. Can you check that please? Is there any chance that your files might include any valid disk image file? Maybe the emulator is trying to load it instead of importing the files. It would surely do this if you use the wrong parameter. Could you possibly send me your ZIP file (in private, of course) that caused the problem so I can debug this? Thanks! Paulo

…

On Thu, Feb 4, 2021 at 12:50 PM sjaaq ***@***.***> wrote: Hello Paulo, In the opening post, I was using HARDDISK_FILES_URL which pointed to a zip file. That one broke when it expanded from 16 to 32M. The application am I working on has been in development in the past year and I was able to run it on multiple devices in that time with the HARDDISK_FILES_URL parameter. I can only assume it is some kind of bug in the import function, as you described. Best regards, Maarten — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLIHI3G4WC2HSDW2UGFTS5K65FANCNFSM4W5ER35Q> .

[sjaaq]

Hello Paulo,

Yes, I am sure about the parameter used. I did some testing:

• When creating, for instance, a zip file with 22M of MOD files, the DOS2 files and the NMP.COM mod player, the image is correct.
• When creating a zip file with my "application" it does not. This is because the "application" uses a 12M data file currently. I think there is something about large files that breaks the disk image.

I will send you a link to the zip file containing a 12M dat file and the mod player. This results in an non bootable image. I'm not sure how to send you anything in a private message. Does github support that?

Here is the link:
https://webmsx.org/?M=MSX2E&Z80_CLOCK_MODE=2&P=OPL4&MOUSE_MODE=1&HARDDISK_FILES_URL=https://nopmsx.nl/download/temp/webmsx_issue69.zip&MOBILE_MODE=0

Maarten

[ppeccin]

Thanks a lot! Waiting for the link! Paulo

…

On Thu, Feb 4, 2021 at 3:03 PM sjaaq ***@***.***> wrote: Hello Paulo, Yes, I am sure about the parameter used. I did some testing: - When creating, for instance, a zip file with 22M of MOD files, the DOS2 files and the NMP.COM mod player, the image is correct. - When creating a zip file with my "application" it does not. This is because the "application" uses a 12M data file currently. I think there is something about large files that breaks the disk image. I will send you a link to the zip file containing a 12M dat file and the mod player. This results in an non bootable image. Maarten — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLIGFTC76EABMIP7CS3LS5LOOVANCNFSM4W5ER35Q> .

[sjaaq]

Not sure if you read my previous post correctly but I cannot send you private links, I do not have any other way to contact you. So i have posted the link in public, see above!

[ppeccin]

I was following the conversation via email, and the link simply got omitted... I can see it now on Github. Thanks! Paulo

…

On Mon, Feb 8, 2021 at 4:32 AM sjaaq ***@***.***> wrote: Not sure if you read my previous post correctly but I cannot send you private links, I do not have any other way to contact you. So i have posted the link in public, see above! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLICKMXYBMV4TVZS7T5DS56HO7ANCNFSM4W5ER35Q> .