Closed venomix666 closed 5 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.
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.
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.
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.
Belatedly: merged. Thank you!
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