Issue calling BIOS XMOVE/MOVE routines via CP/M 3 BDOS function 50

[Tony Nicholson]

I've received an e-mail report regarding the failure of a test program for HI-TECH C that invokes a call to the CP/M 3 BIOS XMOVE and MOVE routines when using the Digital Research banked BDOS routines (using function 50 to invoke a direct BIOS call).

The issue does not occur when using the replacement BDOS modules by Simeon Cran (ZPM3).

I've summarised my findings in the GitHub issue at

https://github.com/agn453/HI-TECH-Z80-C/issues/24

Has anyone else seen this behaviour from DRI's BDOS?

I'm puzzled why the BDOS is invoking a call to the BIOS MOVE routine in between the C program's lines -

bios(29,0x0101); /* Call BIOS XMOVE for bank 1 to bank 1 */
bios(25,sizeof src, src, dst); /* Copy using BIOS MOVE */

Tony

[Douglas Miller]

My two cents, this is not entirely unexpected. XMOVE/MOVE requires atomicity that can't be guaranteed between two separate BDOS calls. BDOS function 50 does not in any way guarantee that all BIOS calls can be used. You'd have similar problems making calls to disk I/O functions, unless you can guarantee that there are no BDOS file functions called in between. BDOS function 50 is definitely "caveat emptor".

I'm not sure what you mean by "DRI BIOS", as DRI did not provide any BIOSes, only an reference/sample BIOS for vendors to use as an example or starting point. I have not searched the DRI BDOS3 to see how it uses MOVE, and it is entirely possible that a vendor's BIOS may be using MOVE in an unexpected way.

[Douglas Miller]

The explanation for this is that CP/M 3 BDOS needs to copy the BIOSPB into common memory so it can switch to bank 0 before calling the BIOS. You see this in the 'dfctbl' where function 50 has the 'fcbin' bit set. I can't say why ZPM3 doesn't need to do the same thing, or whether it working there is merely accidental (perhaps ZPM3 doesn't use MOVE to copy this in). Probably, DRI should have also called out XMOVE/MOVE as being not supported (along with SELMEM).

[Tony Nicholson]

On Tuesday, March 16, 2021 at 11:21:59 PM UTC+11, Douglas Miller wrote:
> The explanation for this is that CP/M 3 BDOS needs to copy the BIOSPB into common memory so it can switch to bank 0 before calling the BIOS. You see this in the 'dfctbl' where function 50 has the 'fcbin' bit set. I can't say why ZPM3 doesn't need to do the same thing, or whether it working there is merely accidental (perhaps ZPM3 doesn't use MOVE to copy this in). Probably, DRI should have also called out XMOVE/MOVE as being not supported (along with SELMEM).

Thanks Douglas.

I was aware of the SELMEM interception (documented in the CP/M 3 Programmer's Guide), and this all makes sense now.