• Please review our updated Terms and Rules here

CP/M 2.2 BDOS serial number clobbered

K

Koolstar42

Experienced Member
Joined
Sep 24, 2019
Messages
68
Location
Netherlands
I noticed that my CP/M 2.2 implementation would sometimes crash after completion of certain programs. Examples are Turbo pascal, toolworks C/80, Digital Link v1.31.
I have determined that this is caused by said applications overwriting the first 6 bytes of BDOS, which contains the serial number. After reloading the CCP it checks this serial number and halts when it is incorrect. I could fix this easily by reloading the first sector of BDOS too. Basically pretending that the CCP is 1 sector longer. But I feel this should not be necessary. Apparently top of TPA is derived from the BDOS call in the base page address 0005h. Is this just bad behavior of the applications or am I missing something?
 
The "normal" warm boot procedure is to reload both BDOS and CCP. Any memory before the BDOS entry (typically XX06, overwriting the serial number) is fair game for programs that make BDOS calls. Also, any memory before the BIOS is fair game for programs that only make BIOS calls. So, warm boot should reload both BDOS and CCP to be safe.
 
Then Why use a serial (version) number at all? I can understand you don't want to load a CCP which does not match the BDOS, but when you always load both there is no point to it is there?
 
Koolstar42 said:
Then Why use a serial (version) number at all? I can understand you don't want to load a CCP which does not match the BDOS, but when you always load both there is no point to it is there?
Click to expand...

I just load CCP during a warm boot, and the reg pair used for the destination write address just happens to point at the first byte of the serial number when the load is completed. I just added a quick loop that zeros out the 6 byte serial number field, just in case something trampled on it (ms basic does it too).
 
I checked, My Ampro littleboard BIOS also loads both CCP and BDOS at warm boot. This seems to be the best practice then.
Thanks for the help
 
Koolstar42 said:
Then Why use a serial (version) number at all? I can understand you don't want to load a CCP which does not match the BDOS, but when you always load both there is no point to it is there?
Click to expand...
Traditionally, the CCP, BDOS, and BIOS are stored on the boot track(s) of the disk. They are always matched (via MOVCPM and SYSGEN) unless the user did something strange. Especially now days, there are versions of CP/M that have been neutered of the serial number checks. DRI's serial numbering was an attempt to verify and track the products. That faded in later years, even at DRI, partly due to it being problematic and also ineffective. I'm not sure if DRI ever officially discontinued it, but it was a requirement for a long time that each vendors' copy of CP/M sold had a unique serial number that included their DRI-assigned vendor ID.
 
Most notable among error messages was "SYNCHRONIZATION ERROR", where the next thing that was done was a hard hang. This out of MOVCPM when the MOVCPM serial number didn't match the BDOS one. If you were an OEM, you were granted a license for a certain number of copies and the OEM kit came with instructions on how to insert the serial number into the relevant programs.
 
I understand why you would consider serial numbers. Microsoft does this all the time. I have difficulty understanding why you would want to forcefully match BDOS and CCP when you were supposed to treat them as monolithic anyway.
I Guess the possibility of overwriting (part of) BDOS became something of an "industry standard" later in time. Not much later though, as DRI's own linker does this, and it's from april '83 Ampro littleboard is from march '83 and has implemented this as well.
On the other hand, Andy Johnson-Laird's "The Programmers CP/M Handbook" from '83 does not even hint at the possibility.
Anyway I have sorted the issue Thanks everyone for putting me straight
 
You must log in or register to reply here.
Back
Top