Today I hacked ...

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
Posts: 1210
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: Today I hacked "The Real You"

Post by Pernod » Mon Dec 12, 2016 12:40 pm

lurkio wrote:Replacing the TOPs with three NOPs made things a little clearer:
Thanks for the explanation. I've also seen this, many years ago, but never understood it until now. It's surprising that DiscDoctor, Exmon 2, etc. never handled this.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Posts: 1577
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara

Re: Today I hacked "The Real You"

Post by lurkio » Mon Dec 12, 2016 1:39 pm

Pernod wrote:It's surprising that DiscDoctor, Exmon 2, etc. never handled this.
Is anyone (with the initials JGH) up for patching Disc Doctor so that it will recognise undocumented 6502 opcodes?!


User avatar
Posts: 1191
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK

Re: Today I hacked "The Real You"

Post by billcarr2005 » Mon Dec 12, 2016 1:45 pm

lurkio wrote:~
What made it tricky was that when I tried to use Disc Doctor's *DIS command to disassemble the machine-code that loads the main program, the machine-code didn't seem to be valid:

Well, it turns out that the hex-byte &7C, followed by two more (random?) bytes, is an undocumented 6502 opcode that's known as "TOP" (or "Triple NOP"), which simply takes up three bytes in RAM but performs no meaningful action when executed! Every other instruction in the loader code was a TOP instruction, the sole purpose of which was to obfuscate the code and make disassembly difficult!
Early Acornsoft disk titles had similar obfuscation. Rob Northen mentions having to redo the protection because it wasn't compatible with the BBC Master here

I've also attached the SSDified version from the FSD I had, even if it's just used to check against the tape files.
Didn't work properly with Watford DFS 1.30, but works OK with Watford DFS 1.44 and Acorn DFS.
The file BOOT appears to do some low level stuff checking the protected track, but it doesn't appear to be *RUN from anywhere!
The Real You
(33.06 KiB) Downloaded 34 times

User avatar
Posts: 3069
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire

Re: Today I hacked ...

Post by flaxcottage » Mon Dec 12, 2016 9:52 pm

Nice detective work Mr Lurkio. =D> =D> =D>
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

Posts: 22
Joined: Sat Dec 10, 2016 6:51 pm

Re: Today I hacked ...

Post by roganjosh » Thu Dec 15, 2016 8:26 pm

For amusement value I just created a special variant of one of my disassemblers
that implements those illegal opcode mnemonics and addressing modes (attached).
I'm afraid it's no DiscDoctor or Exmon though, just a simple little tool.

Hopefully not too many typos added in doing the extension.

Bad opcode disasssembler
(2.83 KiB) Downloaded 33 times

User avatar
Posts: 1577
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara

Today I hacked The Secret Diary of Adrian Mole

Post by lurkio » Tue Feb 14, 2017 12:17 am

The Secret Diary Of Adrian Mole by Level 9 isn't Master-compatible. This is how the game should look, as indeed it does on a Model B:
  • 1.png
    Screenshot of TSDOAM on a Model B
But on a Master it looks like this:
  • 2.png
    Screenshot of TSDOAM on a Master 128
Instead of text below the illustrations, you just get garbage pixels. I decided to investigate, using my new-found BeebEm debugger skills.

I set breakpoints in the OSWRCH and OSASCI code in the OS 1.2 ROM in Model B mode, so that BeebEm would break execution when it hit one of them -- which it never did!

Instead of using OS routines for printing text, the game seems to use custom code, presumably for speed. The game fetches the 8x8 pixel definition of every character of text that it needs to print on screen by peeking into the OS1.2 ROM, where the character definitions are stored at &C000 upwards (eight bytes for every char). The game then pokes the chardef directly to screen RAM.

The problem is that in a Master the chardefs are stored somewhere else! They're in slot 15, in the Terminal ROM, which isn't always paged in and accessible to user code -- and even if it was it wouldn't help because the chardefs are at a different memory location in a Master: at &B900 in the Terminal ROM, as opposed to &C000 in the OS1.2 ROM in a Model B.

I tried to work around the problem by saving the chardefs to disc and then loading them into memory at &C000 in the Master so that the game code would find the chardefs in the same place that they'd be in in a Model B. Things went well until I tried saving my position in the game -- at which point all the chardef data at &C000 was promptly overwritten by the Master's DFS!

Eventually I came up with a solution that actually seemed to work. In the game code, I changed the chardef lookup address from &C000 to &B900. I then used BeebEm's debugger to locate a point in the code where I could splice in my own short routine that paged the Terminal ROM in -- so that whenever the game looked up a chardef, the chardef was actually there, waiting to be found.

Code: Select all

Alterations to file $.CODE2 for Master-compatibility:

P%=&22AE:[OPT 3:JSR &1D70:RTS:]:REM shim

P%=&1D70:[OPT 3:LDA #15:STA &F4:STA &FE30:LDA #0:STA &229C:RTS:]:REM shim target

P%=&1D6A:[OPT 3:JSR &1D70:JMP &6B00]:REM new start address

?&2130=&B9:REM hi-byte of chardefs location in Terminal ROM
Download my Master-compatible version of the game here:

User avatar
Posts: 3563
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: Today I hacked ...

Post by richardtoohey » Wed Feb 15, 2017 7:46 pm

=D> Master conversions are fun - challenging without needing too much work (especially compared to trying to find enough bytes to shuffle tape games around DFS!)

User avatar
Posts: 3069
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire

Re: Today I hacked ...

Post by flaxcottage » Sun Nov 26, 2017 5:29 pm

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!!! =D> =D>
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

User avatar
Posts: 3069
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire

Re: Today I hacked ...

Post by flaxcottage » Tue Jan 30, 2018 5:37 pm

The protection on some John Wiley Software titles had me stumped for a while. The title comprised two discs.

The discs were 40 track but only 35 tracks were formatted on the first. *VERIFY ran and stopped at track 23 with no errors so within this formatted section there appeared to be no rogue sectors.

*CAT was 'disabled'. Only the title showed then nothing. Using ADI to examine T0 S0 showed a fairly standard method of disabling the output from *CAT. The first filename on the catalogue was CHR$(3) followed by CHR$(21), which together would stop output to the printer and screen. The last filename on the catlogue had an identical name. ADI gave the filenames of the other files on the disc.

I attempted to clone the disc using ADI but the clone did not work. Again this is a common occurrence with disc protection.

The boot option was set to RUN. I examined !BOOT using Exmon2 and found that it essentially ran a file called BOOT, having first placed a value in location &03AA.

BOOT did many things;

- it disabled all ROMs except for BASIC,
- it reset many vectors in page 2,
- it checked that track 36 was not formatted,
- it read the disc catalogue directly from sectors 0 and 1 of track 0,
- it loaded and ran a machine code program starting at 0B18,
- it loaded and ran some hidden BASIC programs (these were hidden at the end of some of the normal titles on the disc) directly from the disc surface,
- it loaded a machine code keyboard input routine into &0900 to &0AFF
- it loaded and ran a couple of BASIC programs, getting the value of PAGE from the disc catalogue,
- it used the values stored in &03AA and &03AB to determine which code to load and run and for &03AB whether the code was BASIC or machine code.

Disassembling the file BOOT showed that it ran machine code programs after loading them by executing a jump indirect through zero page and it ran BASIC programs by placing *BASIC[CR]OLD[CR]RUN[CR] in the keyboard buffer. An easy way in was to replace the JMP command for the jump indirect with a RTS command to return to BASIC and to replace RUN with LI. (short for LIST).

Four values in all were passed to BOOT via &03AA. These loaded memory from &0900 to &0AFF and loaded three BASIC programs, START, INTRO and CONTS2. Using the modified BOOT file these hidden files were loaded and saved to a new disc. This disc had to be 80 track in order to have enough storage space to include the original files as well for the archive.

Minor changes were made to these BASIC titles. The changes removed the commands such as ?&3AA=66:*RUN BOOT with CHAIN"CONTS2" for instance, *LOADed the machine code into pages &900 to &AFF and added a line to read the CHARS file using BGET# and to VDU23 the character definitions. The original used *LOAD CHARS, which only works on a model B or B+.

The title now runs properly without needing the file BOOT on a model B, B+ and Master with the exception of the Break key not working according to the documentation. If either Break or Ctrl-Break are pressed the machine hangs with a * prompt. Fixing this is on my to-do list. :?
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

User avatar
Posts: 539
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands

Re: Today I hacked ...

Post by vanekp » Tue Jan 30, 2018 9:29 pm

nice P.M. :)

User avatar
Posts: 1191
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK

Re: Today I hacked ...

Post by billcarr2005 » Sat Feb 24, 2018 11:41 pm

The Taroda Scheme (started a few days ago)

The game wouldn't work with my Watford Electronics DFS 1.30 - when "B" is executed, "Bad sum - file disconnected" is displayed... works with WE DFS 1.44 though!
Disk was formatted 80 track, reported as 40 track with the last 40 tracks unformatted.
Catalogue was prevented from viewing by control codes, although *INFO * shows the files...
BOOT executes an OSWORD &7F block to load an extra 256 bytes of data immediately following the code to do it, this then loads the title screen "S" and kicks off the copy protection...

Tracks 2,3 and 4 report incorrect sector sizes - of 512, 2048 and 4096 bytes, so wouldn't work on 1770 DFS
The "skew" of the tracks is checked on tracks 2,3,4 and 5... if the first sector isn't numbered 6, 2, 9 and 9 respectively then "Copy !!" is displayed.

The main program "B" is *RUN to an RTS and then EOR'd by &FF and RUN
There was also a check for the original disk after a SAVE command has been issued, using

Code: Select all

B50 LDA #&05
B52 LDX #&59
B54 LDY #&0B
B5A 5C
B5B 0B
which then puts the disk title length, the disk title and the boot option into &B5C, and then checking that &B62 is ","

Non standard tracks, ie. not 10 x 256, were as follows

Code: Select all

Title: The Taroda Scheme 

80 Tracks
Tr.#  No.S  Sec.# Tr.ID Head# SecID IDsiz REsiz Error

02    09    00    02    00    06    0200  0100  OK
            01    02    00    07    0200  0100  OK
            02    02    00    08    0200  0100  OK
            03    02    00    09    0200  0100  OK
            04    02    00    00    0200  0200  Deleted data
            05    02    00    02    0200  0100  OK
            06    02    00    03    0200  0100  OK
            07    02    00    04    0200  0100  OK
            08    02    00    05    0200  0100  OK

03    0A    00    03    00    02    0800  0100  OK
            01    03    00    03    0800  0100  OK
            02    03    00    04    0800  0100  OK
            03    03    00    05    0800  0100  OK
            04    03    00    06    0800  0100  OK
            05    03    00    07    0800  0100  OK
            06    03    00    08    0800  0100  OK
            07    03    00    09    0800  0100  OK
            08    03    00    00    0800  0100  OK
            09    03    00    01    0800  0100  OK

04    0A    00    04    00    09    1000  0100  OK
            01    04    00    00    1000  0100  OK
            02    04    00    01    1000  0100  OK
            03    04    00    02    1000  0100  OK
            04    04    00    03    1000  0100  OK
            05    04    00    04    1000  0100  OK
            06    04    00    05    1000  0100  OK
            07    04    00    06    1000  0100  OK
            08    04    00    07    1000  0100  OK
            09    04    00    08    1000  0100  OK

05    0A    00    05    00    09    0100  0100  OK
            01    05    00    00    0100  0100  OK
            02    05    00    01    0100  0100  OK
            03    05    00    02    0100  0100  OK
            04    05    00    03    0100  0100  OK
            05    05    00    04    0100  0100  OK
            06    05    00    05    0100  0100  OK
            07    05    00    06    0100  0100  OK
            08    05    00    07    0100  0100  OK
            09    05    00    08    0100  0100  OK
Download is available here

Post Reply