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
208 stars 32 forks source link

MEGA65: Head and side are not maintained across drives #315

Closed jimnicholls closed 2 years ago

jimnicholls commented 2 years ago

Describe the bug In f011_core.c, there is only a single head_track and head_side variable. Switching between drive 0 and drive 1, the emulation doesn't switch to where the heads are for the new drive. head_track and head_side stay with the values for the old drive.

Used version of the project lgblgblgb/next commit 9606dfdf64c28b2f2d2178de7ea260594c9d4ce5

To Reproduce Assuming two formatted disk images: a.d81 and b.d81.

  1. xmega -8 a.d81 -9 b.d81
  2. Using the F011, spin up drive 0, seek to track 0, seek to track 40, and then spin down drive 0. head_track will now be 40.
  3. Spin up drive 1. TK0 will be set. But head_track will still be 40.
  4. Move the heads of drive 1 out by one track. The heads of drive 1 will be on track 1, but head_track will be 41.

Expected behavior When setting F011's DS, xemu's understanding of where the heads are updates to the newly selected drive.

Additional context This is all irrelevant to xemu, because it (today) it doesn't emulate any actually floppy drive. It only emulates an SD card, and doesn't care where the heads actually are. It will always just find the sector. It only uses head_track to set TR0 and prevent the heads passing in beyond track 0 and out beyond track 128.

I'm trying to right code that might work on a floppy disk. So I'm trying to carefully move the heads to the correct track before trying to read the sector. To the end, I've enabled DEBUG and am watching the output when moving the heads and confirming that head_track = track when reading. So I need head_track and head_side to be accurate.

jimnicholls commented 2 years ago

Pull request incoming.

jimnicholls commented 2 years ago

I just read your PR template. So I won't create a PR yet.

You see what I was going to propose at https://github.com/jimnicholls/xemu/commit/2ba32ac993298c4e98eb2605503a7329c5d6a278.

What I did was move head_track and head_side inside drives. Then replaced all the references to head_track with drives[drive].head_track, and similarly for head_side.

I also moved the initialisation of drives[which].head_track and drives[which].head_side inside fdc_set_disk. Maybe controversially I only initialised them when in_have_disk is true. Kind of simulating that if there's no disk in the drive, head_track and head_side are undefined.

lgblgblgb commented 2 years ago

Thanks for your report!

Please note, that these kind of things are currently "WIP" by me (also) because of other issues, mainly this one: #314 Even this case you mention, but it seems there can be more problematic cases, but probably in the other direction (ie, something is split off per drives, which shouldn't be - the opposite in nature than this problem).

Yes, this part of emulation is originally was written with one drive only keeping in mind (also in a way that nobody could tell how it works, so most of F011 emulation is just try&error, it was even before MEGA65 worked with any FDC access, let it be the physical drive or "D81 mount" from the SD-card), and was just "raped" to handle more drives, with the possible problem of forgetting to adjust things. This is what I'm working on, under the issue #314 , what I've mentioned above.

Yes, it's always nice to discuss first (before PR, for example), since in some cases (but surely, not always!!!!!!!) I know about the problem to (at least) some extent and I may be already working on that.

I can say, you're probably right, I haven't tested my private modifications yet (and surely not committed either), that already contains some proposed fixes (since weekend is coming I'll have time, which is usually not the case during weekdays, when I sometimes do some thing, but only preparation and not so much testing). I need to test things first, to be sure. And yes, I forgot to modify #314 to signal that I'm working on it already ... :( My bad.

Additional information: #219

lgblgblgb commented 2 years ago

Huh, sorry, I totally forgot about this, though it was already made in my local working copy, uncommitted ... :(