atarist-sidecart-raspberry-pico
atarist-sidecart-raspberry-pico copied to clipboard
diegoparrilla
Problem opening emulated floppy directory with TOS 1.00 and TOS 1.02 (beta 0.14)
Issue: Opening the directory window of emulated drive A: does not work. The window seems to "fly out of the screen" at the upper left corner. Re-trying several times leads to a "too many open windows" error.
This behaviour is independent from the "Disable XBIOS trap" feature. It occurs with or with out the trap enabled.
Impact: Prevents usage of floppy images which do not auto-run a program, e.g. application floppies, data floppies. Makes copying files into a writeable floppy image more inconvenient.
Steps to reproduce with TOS 1.00/1.02:
- create an empty ST image from the SidecarT Configurator (Option 3. or 4.)
- choose the new/empty image for emulation (Option 3. or 4.)
- restart the ST
- try to open floppy A:
Test envionment:
- 520ST TOS 1.00 German 4MB
- 1040STFM TOS 1.02 German 4MB
- issue not present on Mega ST TOS 1.04 German 4MB
This appears to be a regression. The implementation of "Disable XBIOS trap" was specifically designed to address this issue. Disabling the XBIOS traps should resolve the visibility problem with windows. I'll retest and provide feedback shortly.
This issue was previously identified in versions 1.00 and 1.02. Thank you for bringing it to our attention.
When using the frogs13.st from https://anarcholab.itch.io/frogs on the 520ST with TOS 1.00 it launches into the directory window of drive a:. Closing this window and trying to reopen it triggers the described error again. On TOS 1.04 the same .ST floppy image launches into the game directly.
May be this helps to solve and test the issue.
Kind regards, Heinz
I've been diving into the problem with frogs13.st on TOS 1.00 UK, and it looks like I've managed to pinpoint where things might be going awry. Interestingly, the "disable XBIOS interception" feature seems to be picky, working with TOS 1.00 and 1.02 but only if there's an actual disk slotted into drive A. With a disk snugly in place, it magically allows the GEM window to pop back open.
From what I've gathered, it seems like there's a hiccup in TOS 1.00 and 1.02. When we try to shuffle the original disk drive from A to B, making room for the emulated drive to take over as A, something doesn't quite click with these particular TOS versions, leaving our physical drive hanging without properly moving to B.
I'm rolling up my sleeves and getting ready to try out a few different strategies to see if we can cleverly nudge the unit over to B. Or, if it comes down to it, we might just have to wave the white flag and turn off this feature when it's not playing nice. Let's see what we can do!
Thanks a lot for your deep dive. I hope you find a way to fix this issue. The exceptional beauty of SidecarT is to run my 520 without physical floppy which is a nice and clean setup on my desk. So the emulated floppy of the SidecarT is the only drive TOS knows about in my scenario.
Found root cause and it seems to work exactly the same under any TOS and EmuTOS