search

davidgiven / cpm65

CP/M for the 6502
BSD 2-Clause "Simplified" License
264 stars 24 forks source link

Set active_drive in BDOS when changing drive #122

Closed venomix666 closed 5 months ago

venomix666 commented 6 months ago

Small fix to set the active_drive variable in BDOS when changing drives, so that bdos_GETDRIVE returns the correct drive number.

A small fix in the CCP to reselect the drive after running a transient program is also included.

Fixes several issues mentioned in #113

davidgiven commented 6 months ago

Thank you!

The BDOS change LGTM but I'm unsure about the CCP change. I agree the current behaviour is counterintuitive, but changing the CCP to restore the original drive will only work if the program returns to the CCP. If it instead triggers a warm boot because it's overwritten the CCP, then the CCP gets reloaded and GETDRIVE is called again. (e.g. in asm.com.) I suspect it's better to be consistent here.

venomix666 commented 6 months ago

I see what you mean, I did not consider that case.

I ran some tests with copying files larger than my available TPA in order to try and trigger this issue, and as far as I can see there is no inconsistent behavior. I am using three drives to test this, so as an example I ran:

C>A:COPY A:LARGE.TXT B:LARGE.TXT

And it is still on C: as expected when the copying has finished, even though I guess it would have overwritten the CCP and the last active drive used by copy was B:. Or does copy.com not overwrite the CPP when copying large files?

I also tried to run asm.com on the largest assembly file I could find (bedit.asm):

A>ASM BEDIT.ASM B:BEDIT.COM

This also runs successfully and returns to A: when exiting.

davidgiven commented 6 months ago

If you access another drive via setting the drive byte in an FCB, that doesn't change the current selected drive; that's why COPY works. It's only when you call the SELECT_DISK (a.k.a. LOGIN_DISK) call that the current drive changes.

venomix666 commented 6 months ago

Never mind the original content of this comment, it was just me getting confused due to some corruption in CPM65.INC on B:.

I have reverted the changes to the CCP. I never managed to trigger any problem related to this, but I see how this could potentially cause some inconsistent behavior.

davidgiven commented 5 months ago

Belatedly: merged. Thank you!