Today I hacked ...

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

Re: Today I hacked "The Real You"

Postby 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, etc.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Today I hacked "The Real You"

Postby 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?!

:wink:

User avatar
billcarr2005
Posts: 1102
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Today I hacked "The Real You"

Postby 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
http://codetapper.com/amiga/interviews/rob-northen/

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!
Attachments
THE REAL YOU.zip
The Real You
(33.06 KiB) Downloaded 27 times

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

Re: Today I hacked ...

Postby flaxcottage » Mon Dec 12, 2016 9:52 pm

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

Currently running Level 4 Econet with BBC B, BBC B+ 128K, Master 128K, 4Mb A3000, 4Mb A3020, 4Mb A4000, 4Mb A5000 dual FDD; UK101; HP41CX setup; Psion 3a, 3mx and 5mx; Z88; TI-58c, TI-59 and printer, HP-16C programmer's calculator

roganjosh
Posts: 16
Joined: Sat Dec 10, 2016 6:51 pm

Re: Today I hacked ...

Postby 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.

Alan
Attachments
bod.zip
Bad opcode disasssembler
(2.83 KiB) Downloaded 28 times

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Today I hacked The Secret Diary of Adrian Mole

Postby 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:


:idea:

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

Re: Today I hacked ...

Postby 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
flaxcottage
Posts: 2799
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire

Re: Today I hacked ...

Postby 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

Currently running Level 4 Econet with BBC B, BBC B+ 128K, Master 128K, 4Mb A3000, 4Mb A3020, 4Mb A4000, 4Mb A5000 dual FDD; UK101; HP41CX setup; Psion 3a, 3mx and 5mx; Z88; TI-58c, TI-59 and printer, HP-16C programmer's calculator


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 5 guests