tonyrich@titanic.cs.wisc.edu (Anthony Rich) (02/11/90)
In article <1534@shell.shell.com> svh@shell () writes: >I have recently gotten together an 820-I with 8" drives, and would like to >do some stuff that would require me to MOVCPM down a couple'o K. The >problem is, that the version I have will generate "Synchronization error" >every time. I ran into the "Synchronization error" message recently, too. According to the book "Inside CP/M" by David E. Cortesi, MOVCPM has a kind of copy protection built into it. When it starts up, it does some checking to see whether the copy of CP/M you're trying to generate with MOVCPM matches the copy of CP/M you're currently running. If not, it displays the message "Synchronization error" and quits. (I'm not sure what it actually tries to match. I think it does some kind of checksum.) As a result, you can't run MOVCPM to generate a new copy of your CP/M while running someone else's copy of CP/M. I wanted to do exactly that for a legitimate reason. My CP/M disk won't boot because I replaced my broken 8" DSDD drive with a different manufacturer's that had different seek characteristics, so I needed to generate a newly configured version of CP/M to handle the new drive. Of course, to do that, I have to already be booted up on the new drive and running with SOMETHING, so to get me started, a net person graciously sent me a bootable CP/M disk that allows me to boot and read 8" SSSD diskettes on my new drive. But I can't use it to generate a properly configured version of MY OWN, PAID-FOR, LICENSED COPY of CP/M because of that $*!!#@@! "copy protection" in MOVCPM! Grrr! If anyone has or can invent a workaround for the "Synchro error" copy protection, I'd appreciate being informed so I can get my CP/M reconfigured and booting happily again on my new drive. Apparently the copy protection is smart enough that you can't simply step over it using DEBUG. Tony -- ------------------------------------------------------------------------ Email: tonyrich@titanic.cs.wisc.edu Phone: 608-271-8450 Disclaimer: The opinions above are mine. Others may agree or disagree. ------------------------------------------------------------------------
chad@anasaz.UUCP (Chad R. Larson) (02/12/90)
In article <9719@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: +--------------- | If anyone has or can invent a workaround for the "Synchro error" copy | protection, I'd appreciate being informed so I can get my CP/M reconfigured | and booting happily again on my new drive. Apparently the copy protection | is smart enough that you can't simply step over it using DEBUG. +--------------- Ok, as much as I dislike postings that say "I think this is it" instead of "I know this is it"; I figured all this out a long time ago, and here is what I remember: The copy protection consists of checking the serial numbers of the CCP and/or the current running CP/M and the BDOS image contained in the MOVCPM program. You CAN use "debug" (you meant DDT or SID, right?) to make the serial numbers match. The serial number in the CCP must match the one in the BDOS also, or your CP/M won't boot. It will move the instruction pair DI, HALT to the beginning of the warm start code and jump to it. The serial number is the first 6 bytes in the BDOS (that is why your BDOS address is always something like E406 instead of E400). It is also contained in the CCP at about 0328H offset (if I remember correctly). In the MOVCPM code is a relocatable image of your CP/M, and a table of the offsets to the bytes that will have to be relocated to make a runnable image where you want it. The image is assembled to run at (??? -- for a 20K?? memory) and when you specify a different size memory the new high-order nybble of the addresses are plugged where indicated by the offsets. This is very much like what Digital Research wound up calling "Page Relocatable" (PRL) code in MP/M and CP/M 3.x systems. If you have documentation to either of them it could be helpful. Anyway, a little dissassembly and single-stepping of MOVCPM with DDT will show you where the "syncronization error" message is issued. Use DDT to make all the serial numbers match up (preferably to yours) and you should be OK. -crl -- Chad R. Larson ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020 (602) 870-3330 "I read the news today, oh boy!" -- John Lennon
" Maynard) (02/13/90)
In article <9719@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: >According to the book "Inside CP/M" by David E. Cortesi, MOVCPM has a kind >of copy protection built into it. When it starts up, it does some >checking to see whether the copy of CP/M you're trying to generate with >MOVCPM matches the copy of CP/M you're currently running. If not, it >displays the message "Synchronization error" and quits. (I'm not sure >what it actually tries to match. I think it does some kind of checksum.) >As a result, you can't run MOVCPM to generate a new copy of your CP/M >while running someone else's copy of CP/M. This is not intended as copy protection; it's intended to prevent MOVCPM from building a garbage CP/M image. MOVCPM uses a bitmap to determine which bytes to relocate when moving the CP/M image. This includes the BIOS area as well as the BDOS and CCP. The original intent was that you'd MOVCPM 54 (or whatever...it's been a looo-o-o---oong time :-), then SYSGEN the resulting image, and then boot. Each licensed CP/M distributor had utilities that built the MOVCPM program from his customized image. For those of us who had to install our own BIOSes, you had to MOVCPM, then load the BIOS on top of that, then SYSGEN and boot. The "Synchronization error" message is produced when the resulting image, because of a difference between the systems, would have the wrong bytes relocated, and therefore would be garbaged. Nobody had even *thought* of copy protection when MOVCPM was developed... -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
SLSW2@cc.usu.edu (Roger Ivie) (02/13/90)
In article <9719@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > In article <1534@shell.shell.com> svh@shell () writes: > >>I have recently gotten together an 820-I with 8" drives, and would like to >>do some stuff that would require me to MOVCPM down a couple'o K. The >>problem is, that the version I have will generate "Synchronization error" >>every time. > > According to the book "Inside CP/M" by David E. Cortesi, MOVCPM has a kind > of copy protection built into it. When it starts up, it does some > checking to see whether the copy of CP/M you're trying to generate with > MOVCPM matches the copy of CP/M you're currently running. If not, it > displays the message "Synchronization error" and quits. (I'm not sure > what it actually tries to match. I think it does some kind of checksum.) Rumor has it that MOVCPM compares the serial number of the CP/M that you're trying to move with the serial number of the CP/M that you're running. The serial number is stored in two places in CP/M: the first is just before the BDOS, and the other is near the command line buffer in the CCP. I'm not certain which one MOVCPM is checking. You should be able to zap the serial number in MOVCPM's image using DDT, although I've not tried it. =============================================================================== Roger Ivie 35 S 300 W Logan, Ut. 84321 (801) 752-8633 ===============================================================================