CP/M/CPM_CDROM.iso/kaypro/kpmovcpm.doc

Text File | 1994-07-13 | 10KB | 200 lines

TITLE:    KPMOVCPM.DOC
SUBJECT:  Making MOVCPM work on a Kaypro 1
AUTHOR:   Barry Siegfried
DATE:     April 21, 1986

I am a big fan of software that works, particularly when it is soft-
ware that is supplied by the company that manufactures my computer.
I recently purchased a Kaypro 1 with the 2.2u1 Universal ROM in it.
This ROM, in addition to having made other enhancements to the basic
8-bit Kaypro CP/M machine, contains much of the working BIOS object
code which has served to drastically reduce the amount of disk-based
BIOS object code in the 2.2u1 CP/M system.

The good news here is that there is much more space up in high memory
where you can make patches to your system than there was with previous
Kaypro CP/M BIOSs and ROMs.  This is very valuable to anyone that
hacks extensively with his operating system, such as I do to get pack-
ages like full implementations of ZCPR3 running.

The bad news is that much of the code that you would expect to find in
the disk-based BIOS running up in high memory is simply not there, be-
cause it has been relocated to the ROM.  Every time the BIOS is called
to perform I/O, the code up in high memory acts primarily like a traf-
fic director, which bank-switches in the Universal ROM to perform the
real low-level BIOS I/O functions.  This can initially be very confus-
ing to the experienced BIOS hacker, however, after you work with this
configuration for a while, you can and do get used to it.

Kaypro provided, on the System Disk that came with the Kaypro 1, a
copy of MOVCPM.COM, which is a utility program by Digital Research
that serves to relocate your CP/M system to a new address.  This is a
valuable capability, because it permits you to move your CP/M system
down, thereby lowering your TPA, but creating free space up above your
BIOS so that you can load and run programs that won't get crashed by
activities in the TPA.  This is excellent for I/O redirection programs
such as BYE, or any other I/O redirection package which might patch
your BIOS and that you wish to have "memory-resident" all the time.

Another useful aspect of CP/M system relocation is that it permits you
to install the external support packages of a fully-implemented ZCPR3
system up in high memory above the BIOS where they will be "memory-
resident" all the time and not be in danger of getting crashed by ap-
plication programs.  It was for this reason that I set about to use
MOVCPM.COM to relocate my CP/M system.

I quickly found out however that after using MOVCPM to relocate my
CP/M system, and then using SYSGEN to write a new system disk, this
new disk was not bootable, that is, the cold boot sequence was inter-
rupted with a message from the Universal ROM that told me I had no op-
erating system present on my disk.  I thought it a little odd that
Kaypro would provide a program on its System Disk that did not appear
to function properly, particularly one as important as MOVCPM.  I de-
cided then to do a little snooping around on the system tracks of my
disks with DU.COM to see if I could locate the source of the problem.

It didn't take long for me to spot the problem.  I discovered on Track
0, Sector 1, two "mystery bytes" in the last two positions of the sec-
tor.  They represented two 8-bit values (or one 16-bit value) that ap-
parently were specific only for the 62K system that came with the mac-
hine.  Those same bytes, when added to the same positions in Track 0,
Sector 1 of my newly relocated CP/M system disk did not remedy the
problem.  It was obvious that these two bytes bore some kind of rela-
tionship to the data in the rest of the sector, but what that rela-
tionship was was not immediately apparent.  It was also obvious, that
MOVCPM apparently had not been updated to place the proper byte values
in these two positions to compensate for the checking that was now be-
ing done by the Universal ROM.  I decided that it was time to call
Kaypro's software support people.

Kaypro, unfortunately, was just a little less than being no help at
all.  In fact, I was a bit surprised to find that the people to whom I
was talking were having a hard time understanding exactly what I was
talking about.  They attempted to tell me that in order to do any BIOS
patching, or revise the BIOS in any way, I needed to purchase their
"toolkit."  I gently informed them that I had all the tools I could
ever possibly need, and that revising the BIOS was not what I was
talking about.  I was talking about a new ROM that was now getting in
the way of MOVCPM.COM performing its function completely.  I didn't
want a "toolkit," I wanted the algorithm to solve the problem.  I
pointed out to them that if they had not wanted the user to have the
capability of relocating CP/M, then they should not have included
MOVCPM.COM on the System Disk.  I have a real problem with companies
who provide commercial software that doesn't work.  Needless to say,
I did not get very far with them and we parted company.

I told this story to a friend and member of our small users' group,
who passed it on to our dealer.  Our dealer had been very helpful with
getting some other hardware-related problems resolved, and my friend
thought that perhaps he might be able to look into this situation with
MOVCPM, and get us an answer about it.  The result was that an East
Coast representative of Kaypro called my friend and discussed the
problem with him, and while he did not fully understand and had not
heard of the problem before, he promised to look into it.  This led to
a telephone call from the programmer who wrote the code for the Uni-
versal ROM and the 2.2u1 BIOS to my friend.  The programmer told him
that he was aware of the "mystery bytes" and that yes, they would in-
deed get in the way of MOVCPM providing a new bootable system, but that
he would not divulge the algorithm of the bytes' values.  It appeared
again that Kaypro was not willing support a program which THEY provided
and should have worked in the first place.

I decided, therefore, to take action on my own because frankly, I was
a bit disturbed at Kaypro's attitude toward all of this.  My procedure
was to get the Universal ROM object code into a disk file, and then de-
bug the routine that outputs the error message to the machine.  I offer
below, a patch that you can make to the version of MOVCPM.COM that came
bundled with the Kaypro 1, which will calculate the proper values for
those two "mystery bytes," and will store them at the proper location
in your newly relocated CP/M system image:

1. Load MOVCPM.COM into DDT (or ZDT):

   A0>DDT MOVCPM.COM
   DDT VERS 2.2
   NEXT  PC
   2500 0100
   -

2. Check and patch the exit JMP at the following address:

   -S033D
   033D C3 C3  (JMP)
   033E 00 A0  (03A0 address of checksum routine)
   033F 00 03
   0340 0D .
   -

   IMPORTANT:  Make sure you have C3 00 00 in the above 3 bytes
   beginning at 033D before you go any further.  If you do not,
   then it would appear that you do not have the same version of
   MOVCPM.COM that was supplied with the Kaypro 1.

3. Create the routine which calculates the proper value of the
   checksum bytes:

   -S03A0
   03A0 00 21   (LXI H)
   03A1 00 00   (0900 address from which to start summing)
   03A2 00 09
   03A3 00 01   (LXI B)
   03A4 00 7E   (007E bytes to sum)
   03A5 00 00
   03A6 00 DD   (LXIX)
   03A7 00 21
   03A8 00 00   (0000 to initialize the summing register)
   03A9 00 00
   03AA 00 16   (MVI D)
   03AB 00 00   (00)
   03AC 00 5E   (MOV E,M)
   03AD 00 DD   (DADX D)
   03AE 00 19
   03AF 00 23   (INX H)
   03B0 00 0B   (DCX B)
   03B1 00 78   (MOV A,B)
   03B2 00 B1   (ORA C)
   03B3 00 20   (JRNZ)
   03B4 00 F7   (to 03AC)
   03B5 00 DD   (PUSH X)
   03B6 00 E5
   03B7 00 E1   (POP H)
   03B8 00 22   (SHLD)
   03B9 00 7E   (097E address to store checksum)
   03BA 00 09
   03BB 00 C3   (JMP)
   03BC 00 00   (0000 to exit)
   03BD 00 00
   03BE 00 .
   -

   IMPORTANT:  Make sure you have zeros in all the above bytes
   beginning at 03A0 before you go any further.  If you do not,
   then it would appear that you do not have the same version of
   MOVCPM.COM that was supplied with the Kaypro 1.

4. Exit DDT (or ZDT) and save patched MOVCPM.COM:

   -G0  (return to CP/M)
   A0>SAVE 41 MOVCPM.COM

Your newly SAVEd MOVCPM.COM will now execute properly and cause SYSGEN
to write bootable disks with the Universal ROM.  It is really a shame
that Kaypro did not come to the aid of their customers on a program as
important as this.  This is a capability that you, as a Kaypro 1 owner,
have the right to have because you, as a Kaypro 1 owner, were supplied
with MOVCPM.COM by Kaypro.  To my mind, this program should have work-
ed from the start, and, since it did not, there is absolutely no ex-
cuse for Kaypro refusing to support it.

For those of you who might be interested in implementing ZCPR3 and its
support packages in high memory above the BIOS, instead of low memory
below the CPR where a BIOS warm boot patch is required to fake up the
BDOS entry address in order to fool application programs into protect-
ing this space below the CPR, watch for an installation file shortly.
This author has installed a fully implemented ZCPR3 system on the Kay-
pro 1 using both methods, and the one involving use of MOVCPM to relo-
cate the CP/M system is by far the preferred one.


End of KPMOVCPM.DOC