MTS2000 Toolproof

[gatekeep]

So being the curious type, I purchased a MTS2000 (now I purchased it for parts so, I could careless if it functions) from the *bay that has the F01/93, now I know from experience, this typically means the radio is a brick.

Now, from what I understand from SRN 1173, the toolproof error is generated based on checksum differences, and the only way to clear it was to push an s-record from *THAT* radio. However from reading, I see that later labtools such as R03.02 can clear the F01/93. The question is how exactly does R03.02 manage to clear these toolproof errors?

Some information on toolproof say's some "internal" parameters of the radio on the masked ROM are checked for the checksum generation [of course these are old posts from the late and great Monty]. Of course wouldn't this make ALL labtools useless? Or is there "extra" data read off the radio during a read from this masked area that is then in turn used by the newer RSS and CPS to regenerate the proper checksums in the codeplug? In the case of "extra" data, when saving the codeplug does RSS/CPS save the "extra" data with the codeplug so that it can be properly modified by just loading the plug from disk?

The theory I have (which I'm sure is incorrect simply due to the way the checksum is generated), is if I were to use lab to read a good radio without unpack (one that is >5.42) that has the toolproof checksums, then write it into the donor radio would I still trigger F01/93? Conceivably, from what I understand the answer would be "yes". But, what is preventing regular RSS/CPS from then rewriting those checksums if I were to re-write the radio using standard RSS/CPS? Some areas of the codeplug that standard RSS/CPS does not normally write or change?

[motorola_otaku]

Give this procedure a try: http://batboard.batlabs.com/viewtopic.p ... 75#p399075
Note that you need to use Lab version 02.00.01 and start it with the "mtsx" command, NOT "runtime."