towson@Amsaa.ARPA (06/30/84)
From: David Towson (CSD) <towson@Amsaa.ARPA>
David - Here are three messages I saved from a while ago which apply to your
recent query concerning MOVCPM "synchronization error". If you work out the
patches to MOVCPM that will disable this feature, please let us know. I
realize the feature was put there to prevent people from doing bad things to
CP/M by trying to move it with the wrong version of mover, but it is a
nuisance at times, isn't it.
Dave
towson@amsaa.arpa
----- Forwarded message # 1:
Received: From Brl.ARPA by BRL-BMD via smtp; 29 Jul 83 16:17 EDT
Date: Fri, 29 Jul 83 15:56:47 EDT
From: Rick Conn <rconn@brl>
To: ACB.TYM@office-2
cc: info-cpm@brl
Subject: Re: BDOS secrets
Hi --
1. The first six bytes of the BDOS (before the entry point) contain the
serial number. In CP/M systems, the serial number is contained within
the CCP and the BDOS.
2. The four byte-pairs after the entry point are addresses of subroutines
to be executed when certain BDOS errors occur. Specifically, these four
byte pairs have the following meanings:
1st Pair: Address of Permanent Disk Error routine; this
routine is executed when bad block is encountered
2nd Pair: Address of Select Error routine; this routine
is executed when a select to an invalid disk
(such as E when the BIOS allows for up to D)
is made
3rd Pair: Address of Disk R/O Error routine; this routine
is executed when a write to a R/O disk is attempted
4th Pair: Address of File R/O Error routine; this routine
is executed when a write to a R/O file is attempted
As a rule, these routines usually print an error message and then do a
warm boot. Utilities may use these to trap out errors they cause and
perform other functions besides warm boot.
To summarize, the picture looks like this:
Base of BDOS: DS 6 ;Serial Number
JMP BDOSE ;Enter the BDOS at the command processor
DW PERSUB ;Permanent Disk Error
DW SELSUB ;Select Disk Error
DW ROSUB ;R/O Disk Error
DW RONSUB ;R/O File Error
BDOSE: ... ;BDOS command processing
Rick
----- Forwarded message # 2:
Received: From Brl.ARPA by BRL-BMD via smtp; 30 Jul 83 20:58 EDT
Received: From Mit-Mc.ARPA by BRL via smtp; 30 Jul 83 20:52 EDT
Date: 30 July 1983 20:50 EDT
From: Ronald G. Fowler <RGF@mit-mc>
Subject: [RGF: BDOS secrets]
To: INFO-CPM@mit-mc
Date: 30 July 1983 18:50 EDT
From: Ronald G. Fowler <RGF>
To: ACB.TYM at OFFICE-2
cc: RGF
Re: BDOS secrets
1) Those six bytes at the beginning are the CP/M serial number; they
have little significance to anything other than the MOVCPM program
(which disables interrupts and halts if these numbers do not match
MOVCPM's internal serial number). I'm also told that some rather
rude implementations of CP/M come with utilities that take it upon
themselves to do this serial number check also.
2) The four vectors are pointers to the following routines (in order):
a. Permanent error subroutine (ie, BDOS ERROR ON X: BAD
SECTOR)
b. Select error
c. Disk read/only error
d. File read/only error
The BDOS uses these addresses to find the corresponding error-
handling subroutine; in theory, a transient program could overlay
this table with pointers to its own routines, and thereby circum-
vent the unfriendly BDOS error handlers, replacing the routines
with more human-oriented messages. In practice, few programs do
this; it's a risky practice, and not quite as clear-cut as it
sounds. --Ron Fowler
----- Forwarded message # 3:
Received: From Brl.ARPA by BRL-BMD via smtp; 1 Aug 83 2:46 EDT
Received: From Rand-Relay.ARPA by BRL via smtp; 1 Aug 83 2:41 EDT
Date: 1 Aug 1983 01:26:05-EDT
From: goldfarb.ucf-cs@rand-relay
Return-Path: <goldfarb.UCF-CS@Rand-Relay>
Subject: Re: [RGF: BDOS secrets]
To: RGF@mit-mc
Cc: info-cpm@brl
Via: UCF-CS; 31 Jul 83 23:28-PDT
Have you ever noticed that when MOVCPM halts with a serial number
disparity, it prints:
SYNCRONIZATION [sic] ERROR
This goes back as far as I can remember (version 1.?). Maybe they
were looking for one byte to save in MOVCPM and dumped the 'H'? :-)
Ben
----- End of forwarded messagestowson@Amsaa.ARPA (06/30/84)
From: David Towson (CSD) <towson@Amsaa.ARPA> David - I suggest that you just disable the serial number checking in MOVCPM, and leave all else alone, which is what I believe you intend to do. MOVCPM contains the actual code of the CP/M operating system, along with a bit-map showing which bytes must be relocated for the different size versions. If you diddle the wrong thing, you'll screw it up. I have been wanting to have a hack at this myself, but just haven't gotten to it. It sounds like you have already located the area where you have to change things. Dave