Over the last month or so I have been looking at archiving Music Master II, published by AB Euroean Marketing Division. This is a simple recorder tutor with some good graphics and is suited to the intended audience.
The disc was original but did not have a label (although strange I have met several other titles like that).
The copy protection on the disc was really very clever and would have defeated most copying BITD. It defeated ADI on my Master although ADI reported an identical clone of the disc. (The Master has a 1770 disc interface. Maybe a 8271 interface on a Beeb would have coped better?)
The 40T disc was formatted on tracks 0-19. Tracks 20-39 were unformatted. When catalogued there were only three files showing, !BOOT, BOOT and t.set1. I checked the catalogue for hidden filenames but these really were the only three files on the disc.
!BOOT was a machine code file which loaded at &7000, set a few memory locations from &3AA upwards and then ran the file BOOT.
BOOT was a machine code file which resided from &900 to &AFF and which loaded sectors directly from the disc surface into memory, depending on the contents of locations &3AA to &3B1. The code was a mind-numbing maze of internal jumps, repeated self-modification and frequent calls to OSWORD to set the special registers of the 8271 chip.
When I scanned the disc in 40T mode I noted that the logical track numbers were double the physical track numbers. Only even tracks were represented. In 80T mode all odd numbered tracks were blank (filled with E5 from formatting). Most even numbered tracks were also filled with E5. There was little data on the disc, only odd sectors in a track holding data.
Not only that but physical tracks 13-19 had physical sectors numbered logically from 128-137. This layout was enough to defeat my attempts at extracting the programs, especially since the programs were not held in contiguous, consecutive sectors.
However, the program BOOT was able to extract the program code successfully and to run it. Time for another approach.
Even though I was not able to fully understand the intricacies of the machine code I did note that inside BOOT there were the commands OLD followed by RUN, which were placed into the keyboard buffer. This indicated the use of a BASIC program. I modified RUN to be LI., which would list the code after loading.
Examining the BOOT code found *FX200,3 and *FX3 calls to disable VDU output, SPOOL output and Printer output. These were replaced with NOP codes and the modified file was saved on drive 1. !BOOT was modified to run :1.BOOT and saved on drive 1.
Running :1.!BOOT, the modified one, loaded my modified :1.BOOT file which ran, loaded and LISTed a BASIC file from drive 0, the original disc. This BASIC file I saved then examined it. At several points in the code there were statements such as ?&3AA=70:?&3AB=&FF:*RUN BOOT. When executed in immediate mode these loaded files from the disc in drive 0.
All was not as simple as finding these lines, executing them in immediate mode and saving the loaded files. Oh, no! The BOOT file was self-modifying and had to be used in the order set by the programmers in order to extract the right data at the right time. Also some of the files loaded were machine code files or were data and their destination addresses and lengths were not known.
To solve this problem I programmed the function keys to set the page 3 parameters and call :1.BOOT. Key F0 made the first call, F1 the second and so on. Before each call I ran an EXEC file which filled user RAM with zeros. After each call, which was not a BASIC loader, I ran an immediately executed program which searched user RAM from an input start address for the first non-zero data. Then entering EXMON I was able to determine whether this was machine code or data. In either case the end of the non-zero bytes was found and the memory *SAVEed onto drive 1.
Using this method I was able to extract 5 files from the original disc. These were 3 BASIC programs, a MODE4 partial screen for the program title and a machine code routine, which loaded at &4250, above HIMEM, which was set by the BASIC programs.
Each BASIC program required some minor editing, mostly to remove the calls to *RUN BOOT and replace these with appropriate *LOAD or CHAIN commands.
The files have been linked correctly and appear to work now on DFS and ADFS. They will be tested on NFS and RAMFS (they should work) and then I can pronounce this title HACKED!!!