del@dataio.UUCP (Eric Lindberg) (07/17/84)
< nonononono please... > < leave a line for me.. > OK everyone, I'll talk. I have enjoyed all the discussions on the net about how to avoid the SYNCHRONIZATION error. Digital Research sure has you bozos pegged :-). D-R figured you'd try something like this, and anticipated most of your moves. To patch the package to work the way we would all like is definitely not worth the effort (I know, I have a fully disassembled listing stuck on a backup disk somewhere). KEEP READING>>>>> I will divulge the solution after I indulge myself :-). What they did was check the serial number, nothing new to all of you by now, of the running operating system and compare with an internally stored serial number within MOVCPM. You folks have all been taken for a ride, BECAUSE THEY DO IT TWICE!!! So even after the clever individual has come to the point of finding the first check, and fixes it, said problem does not go away. ha-ha. Like I said, they got you pegged (me too). Most of us go looking somewhere else once we find this first check. I have seen some other solutions, like one guy (not on the net) that had an incredibly involved patch to cause MOVCPM to look at it's OWN serial number. Not worth the effort. I have done so many configurations for people that I plumb run out of toes and fingers to count with. In each instance it was the same thing, MY system (actually running CDOS) trying to assemble and incorporate some CBIOS into the OTHER GUYS CPM. While I can appreciate D-R's desired to protect their software, they left the user with a classic chicken and egg problem - can't run the software till it's configured, can't configure the software till it runs. So, I now keep two versions of MOVCPM around: MOVCPM, and MOVXCPM. One runs under an operating system with the correct serial number, one runs under any other serial number. If you run the wrong one, you still get the SYNCH. ERR. What I did is so simple it will make you laugh. I've been chuckling for years over it. Naturally if you do a test, there is a conditional branch after it. I simply reversed the sense of the conditional!!! Now the MOVXCPM program checks to see if the operating system DOES NOT have the correct serial number (jokes on you, D-R). I don't have a copy of my listing handy, but I remember the task VERY well. So, take this patch, and apply to your MOVCPM with a grain of salt: meaning I may be off a byte or three (no more than that, I promise), and the sense of the conditional may be wrong. Just remember that the idea is to use the opposite conditional. Get out your debugger and look at the location 234h. I am positive of this location to the extent that it has been at this location in every MOVCPM that I have seen. JP NZ,025A Change this instruction to the opposite: JP Z,025A ; (or vice-versa, whichever is appropriate). Now look around 2CBh. You will find an identical instruction! Now you take and do the same hack to this guy and call your new program something unique (how about HAHA$DR.COM? :-) Just remember that after you have your new CPM up and running, use the unmodified version of MOVCPM, or you get halted, same as before. Please send mail, I want to hear about your success and gratitude. :-) Erik Lindberg AKA del @ dataio Redmond, WA ( I used to call myself a hacker.... )