search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
207 stars 32 forks source link

MEGA65: All .d81 being accessed on the virtual SD card image are R/O #390

Closed nobruinfo closed 11 months ago

nobruinfo commented 11 months ago

Describe the bug

Used version of the project

To Reproduce

If CLI switch -defd81fromsd isn't used the issue does not appear when mounting mega65.d81 or external.d81. Those are then written/read in the HDOS folder even though -hdosvirt isn't used. Altogether this seems indicating the issue only affects files being accessed within the SD card where probably other files are not written back to.

The versions 20230201 and before did not have this issue. There might be more versions but I only downloaded the later 20230513 with which I first see the behaviour.

To replicate the switch -hdosvirt must not be set. Thanks for fixing.

Expected behavior

All .d81 (no matter if HDOS, default or by -defd81fromsd) should allow writing back into .d81 files.

Screenshots

grafik

Computer/Device (please complete the following information)

Additional context

None.

lgblgblgb commented 11 months ago

NOTE (for myself): Part of #367 in some way, but a very specific issue, so keep it separated but related.

lgblgblgb commented 11 months ago

After issuing MOUNT "SOMETHING.D81" in BASIC65, on the stdout ("sysconsole") of the emulator:

SDCARD: MOUNT: internal mount #0 from SD sector $3320 (R/O)
D81: previous file descriptor (34) is NOT closed, because marked as non-autoclose!
D81: fd 34 has been attached to #0 with 6701056 offset, read_only = 1, autoclose = 0, size = 819200
SDCARD: configuring F011 FDC (#0) with have_disk=1, can_write=0, image_size=819200, d81_access="D81 (M:0,A=$00,B=$07)
HDOS: leaving function #$40 (d81attach0) with carry SET (A,X,Y,Z=$40,$08,$0D,$00)
HDOS: d81attach0("external.d81") = OK

So it's clear that the SDCARD/D81 subsystem is literally asked to do R/O mount (read_only = 1 and can_write = 0). Surely, it's more than likely that the source which asks this is also at Xemu's side, that's true ... But this tighten the problem down a bit, as it's not the mounting itself which does something wrong, it already gets the request this way, to be R/O.

nobruinfo commented 11 months ago

@lgblgblgb Oh, I completely mistook the discussion over at Discord then. I thought the sd_regs[ ] being read from what comes from either the device or the media.

I now could reproduce the exact lines you show. Understood.

lgblgblgb commented 11 months ago

The commit above (already in the newest next release) tries to work around this problem by forcing R/W mount even if HDOS wants to do R/O only. I am not sure if it has any ill side effects, it seems to work for me.

nobruinfo commented 11 months ago

@lgblgblgb Thank you very much. Sound like the dirtiest workaround, so why not? ;) I'm quite busy right now but will definitely test it and give feedback.