Recently Paul (Ziggy72) provided me with his tape dumps of “Action Pack 2”, which have been baffling me a good deal. They turn out to be excellent research material for a number of reasons, so here’s some insight on this case.
First of all, most titles on this tape use what appears to be an early, and very slow, variant of “Mega-Save”, which is now supported in TAPClean (since commit tag v0_37_pre_22) as “Mega-Save T4”.
The second thing worth mentioning is that there was a mastering error for “Z” on Side B. Long story short, when mastering the last turbo file to tape for this title, it looks like a typo was made at the execution address input.
Here’s a screenshot from the Mage-Save masterer itself, masterer that was submitted to me by Paul himself a while back when he found out that it is this tape masterer that recorded what were referred to as “CHR Loader” tapes:
Mega-Save masterer: execution address selection
Rather than 2304, i.e. $0900, I think the value 2404 was used, i.e. $0964, resulting in a JMP to the wrong execution address at the end of the load.
Realistically, this seems a case of typo as the chance that the byte $00 would be altered to $64, i.e. %01100100, at some time in between the mastering and the dumping process, are very slim.
BTW, the typo might have been significantly harder to make if the execution address input were to accept hexadecimal values instead of decimal ones 🙂
The issue had baffled me because the overall CRC-32 value computed by TAPClean on all files for this title from Side A and Side B was the very same. In fact, TAPClean does not compute CRC-32 values on the whole contents of a file (sync+header+payload+check byte+post data+…), but simply on the payload itself. As the execution address for this format is stored in the header section of turbo files, TAPClean is not useful to detect these differences using CRC-32 values. It was only when I decided to compare the report it generated for both sides that I spotted the issue:
Z: comparison of TAPClean’s report between Side A and B
I’ve now added an item to TAPClean’s TODO list to optionally extend the CRC-32 calculation to all bits of information in a file, albeit cases as the one above seem to be extremely rare for it to be an urgent change 🙂