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: Refactor how image mounting works #367

Open nobruinfo opened 1 year ago

nobruinfo commented 1 year ago

Is your feature request related to a problem? Please describe.

Steps to reproduce:

Describe the solution you'd like

Describe alternatives you've considered

If it is not possible to image mount on the emulators level the now existing behaviour maybe could be slightly improved by simply exchange EXTERNAL.D81 on the emulator's level. To do so maybe a CLI option for Xmega65 could be the solution.

Additional context

See the now behaviour in this video:

https://user-images.githubusercontent.com/67829169/218261982-695492b4-24d5-4f04-9efb-dcd0d7d59d2f.mp4

nobruinfo commented 1 year ago

@lgblgblgb In version of December 21, 2021 I could reach this:

grafik

In later versions this config is a white page. Could it be that those unreachable settings have impact on what is in the issue description?

lgblgblgb commented 1 year ago

@nobruinfo Thanks for the report. Some points here:

  1. The configure screen you showed does not work in Xemu any more because of an unknown reason. I'd be happy to tell you why (and I would fix then) but no idea ... [yet ... but since a while already]
  2. The setting is not "unreachable" just the config utility, those settings are stored on the sd-image and seen by HYPPO always.
  3. It has no impact on the problem anyway since HYPPO works OK, it mounts what it want the problem that Xemu overrides that immediately because it must handle their own stuff HYPPO does not know about.
  4. EXTERNAL.D81 has nothing to do with anything. It's just there, I planned to use one day, but it does absolutely nothing, so it's not even relevant here for us.

Really, the only problem here, that HYPPO works nicely, just Xemu can't figure out what HYPPO did and what it should do, and what's the relation ;) If Xemu wouldn't override HYPPO's work you will find, that everything is perfect. Yes, just then no way to mount external D81 on your win/linux/mac filesystem, and no way for -8 or UI menu mount, etc. The hard part is to make these things together without conflict.

The configure (and by the way even fdisk too) utility inaccessibility is indeed a problem which should be fixed, but nothing to do with this issue at least.

nobruinfo commented 1 year ago

@lgblgblgb I see. Let us track the white screen thing as a separate ticket #368.

To 4.: But if a save a BASIC programme to the disk in U8 wouldn't this end up in EXTERNAL.D81 ? I'm going to test and report back in here.

nobruinfo commented 1 year ago

From Discord:

One suggestion you can try though it's a highly work-in-progress stuff: enable HDOS virtualization, you can do it from the UI menu as well (in advaned/debug). Then try DIR U12. What you will see hopefully at this point that it shows the hdos sub-dir (or hdos-root depending on your version of Xemu) content in your preferences directory (if you don't know where it is: UI menu again then debug/advanced -> browse system folder). At this point you don't even need to deal with the sd-card image at all. You can just put D81s into that directory, and you'll see its content immediately with DIR U12 and you should be able to mount it as well with the BASIC65 MOUNT command. Though again, it's a relative new and unfinished area of Xemu, some HDOS calls won't work when using HDOS virtualization like loading files directly from SD-card then (not from a mounted D81).

  1. I activated HDOS virtualization from the context menu.
  2. This successfully showed me an alternate SD-CARD DIRECTORY.
  3. Then used MOUNT "MEGA65.D81" from the dir listing directly.
  4. Unfortunately this then gave me only the same DIR result as before:

grafik

Please correct me if I did this wrong. Otherwise if this way the hard coded EXTERNAL.D81 mount cannot be worked around it is simply how it is. We can leave this ticket open until anyone comes up with new ideas.

WINDOWS: console is open
HDOS: entering function #$12 (opendir) A=$12 X=$00 Y=$00 Z=$00
HDOS: VIRT: returning OK (A=$00) from virtualized function #$12 bypassing Hyppo
HDOS: leaving function #$12 (opendir) with carry SET (A,X,Y,Z=$00,$00,$00,$00)
HDOS: VIRT: was marked as virtualized, so end of opendir in hdos_leave()
HDOS: entering function #$14 (readdir) A=$14 X=$00 Y=$13 Z=$00
HDOS: VIRT: hdos_virt_readdir(): accepted filename = "mega65.d81"
HDOS: VIRT: returning OK (A=$14) from virtualized function #$14 bypassing Hyppo
HDOS: leaving function #$14 (readdir) with carry SET (A,X,Y,Z=$14,$00,$13,$00)
HDOS: VIRT: was marked as virtualized, so end of readdir in hdos_leave()
HDOS: entering function #$14 (readdir) A=$14 X=$00 Y=$13 Z=$00
HDOS: VIRT: hdos_virt_readdir(): end-of-directory
HDOS: VIRT: returning ERROR (A=$85) from virtualized function #$14 bypassing Hyppo
HDOS: leaving function #$14 (readdir) with carry CLEAR (A,X,Y,Z=$85,$00,$13,$00)
HDOS: VIRT: was marked as virtualized, so end of readdir in hdos_leave()
HDOS: entering function #$16 (closedir) A=$16 X=$00 Y=$13 Z=$00
HDOS: closing directory descriptor #$00: 0
HDOS: VIRT: returning OK (A=$16) from virtualized function #$16 bypassing Hyppo
HDOS: leaving function #$16 (closedir) with carry SET (A,X,Y,Z=$16,$00,$13,$00)
HDOS: VIRT: was marked as virtualized, so end of closedir in hdos_leave()
HDOS: entering function #$2E (setname) A=$2E X=$00 Y=$04 Z=$00
HDOS: VIRT: unvirtualized DOS function #$2E pass-through to Hyppo
HDOS: leaving function #$2E (setname) with carry SET (A,X,Y,Z=$2E,$00,$04,$00)
HDOS: setname: selected filename is [mega65.d81] from $0400
HDOS: entering function #$40 (d81attach0) A=$40 X=$08 Y=$0B Z=$00
SDCARD: D81: sdcard_force_external_mount(0, "C:\Users\Superuser\AppData\Roaming\xemu-lgb\mega65\hdos\mega65.d81", "(null)");
SDCARD: D81: external mount #0 but no change, "C:\Users\Superuser\AppData\Roaming\xemu-lgb\mega65\hdos\mega65.d81" = "C:\Users\Superuser\AppData\Roaming\xemu-lgb\mega65\hdos\mega65.d81"
HDOS: VIRT: mount of image "C:\Users\Superuser\AppData\Roaming\xemu-lgb\mega65\hdos\mega65.d81" on unit 0 went well.
HDOS: VIRT: returning OK (A=$40) from virtualized function #$40 bypassing Hyppo
HDOS: leaving function #$40 (d81attach0) with carry SET (A,X,Y,Z=$40,$08,$0B,$00)
HDOS: VIRT: was marked as virtualized, so end of d81attach0 in hdos_leave()
nobruinfo commented 1 year ago

@lgblgblgb Ahh, dang. I made a mistake. XEMU EXTERNAL is actually what is in this .D81 . So stupid of me. If a throw in more .D81 into the subdir it is actually possible to mount them - also as U8.

This looks like the perfect workaround to me. I'm now investigating this further.

So please forget my before post. Thank you for the advice you made.

lgblgblgb commented 1 year ago

@nobruinfo Yeah, tricky, since MEGA65.D81 is actually in that directory by default, so you won't see too much difference until you put extra files there ;) btw another source of possible confusion:

The disk image "title" says XEMU EXTERNAL, that is nothing to do with EXTERNAL.D81 ;) Just named this way since originally the default mounted D81 (on real MEGA65 as well) is on the SD-card, called MEGA65.D81. When I introduced the way that Xemu stores that file "externally" (not on the emulated SD-card, since people were complaining that how they can manipulate the content of the default U8 without easy way to directly accessing it) I decided to have the disk name ("title") XEMU EXTERNAL for that external default MEGA65.D81 to allow to tell the difference between that an the internal default MEGA65.D81. Again the file EXTERNAL.D81 on the SD-card is not related at all to this topic ;) Confusing, I know ... To be honest even for myself sometimes, the fact that I wrote all of this mess, does not always help ;)

In my opinion, 99% of people would be happy with HDOS virtualization used by default so they don't need to deal with the SD-card image at all, anymore (let alone this kind of bug like this whole issue we're in, for example). The only reason it's not the default, that it has some problems with certain HDOS (HDOS - HYPPO-DOS - is the part of HYPPO which is about giving API/ABI to access files on SD-card nothing to do with CBDOS which is part of the ROM, ie "Computer Based DOS") functionalities then, like loading file directly from SD-card (not within a D81, ie loading files from U12) which won't work if enabled yet (but honesty even on a real MEGA65 it's somewhat buggy, ie only works on pure BASIC programs for example). Again, 99% people (I guess) may feel that having the SD-card image is just an annoying fact and would be happy to avoid using it at all and having all-files, directly accessible at both of sides eg on their OS (Mac/Linux/Win) and inside the emulation as well! That is what "HDOS virtualization" is supposed to do. The only scenario when it's a problem (even when this feature is finished): if a program does direct I/O disk access like some kind of "disk block read/write program" or such, but otherwise ...

nobruinfo commented 1 year ago

@lgblgblgb Yesterday evening I for myself came to similar conclusions and as I wanted to share with you Today I read your last post in here. Yes, to me hdos virtualisation also sounds more like the better default.

I think we need to take care of testing, right? Pre-attaching and having .d81 stitched is neither the real hardware's behaviour as you already stated, nor is it something that we would confront beginners with. But somehow this made it as the default, funny. So we're simply at a point of many-year-development where such things might be for a change. One that certainly had to be discussed in the Mega's committee.

Speaking of which, not yet in Discord for Today, Yesterday I got the impression from Gürçe he could have had the same line of thoughts while implementing the intro disk 2. Funny number two. ;)

And for the last your first paragraph: Yes, EXTERNAL.D81 being not the same as "EXTERNAL" as a title really caught me, ha ha. Now all good.

lgblgblgb commented 1 year ago

@nobruinfo The reason "HDOS virtualization" is not yet the default: it's incomplete and may fault badly in case of some programs wants to do more than just using MOUNT/UMOUNT HDOS system calls ("traps"). Surely it's maybe not so common to have those kind programs but would confuse people a lot when some of the HDOS functions refers to the normal host OS directory, but some of them still to the (emulated) SD-card. Also, maybe good idea to again, doing a big hyppo&co update in Xemu from the MEGA65 project. That is also a bumpy read and takes 'ages' to make everything working again and test things.

nobruinfo commented 1 year ago

@lgblgblgb I'm not expecting hdos virtualisation to be the default right now. It's fully okay to have it at a point of stability that of course you decide.

As a matter of fact my first KickC tests were possibly unsuccesful because of the now state of things. But I'm still unsure as I see assembly projects like Manche making full use of navigating withing the SD card using hyppo traps. — On the other hand, I haven't seen this working for me in Xemu. Will investigate in this aswell, this time for me on the low prio side.

lgblgblgb commented 1 year ago

@nobruinfo Just to make it clear, partly I do these issues for myself too, since I can easily forget the process of some fix, feature, etc later, especially if needed a year from now (even if it's closed, can be seen/searched). So when I wrote "HDOS virtualization" is not made default, I didn't mean you expect that etc, I expect that to be the default, ie I am on that road ;)

nobruinfo commented 1 year ago

@lgblgblgb I think I got you right in the first place. – I wanted to test-compare my little C-programmes Yesterday. Wanted to find out whether they behave differently doing file access things with or without hdos virtualisation. But I still have other errors in my setup that need fixing and I didn't come round to.