Today I hacked ...

discussion of beeb/electron applications, languages, utils and educational s/w
duikkie
Posts: 2711
Joined: Fri Feb 07, 2014 3:28 pm

Re: Today I hacked ...

Postby duikkie » Wed Jan 21, 2015 8:55 pm

playing with the 6845 chip is not easy :) , it is the most difficult thing to start with :)

duikkie
Posts: 2711
Joined: Fri Feb 07, 2014 3:28 pm

Re: Today I hacked ...

Postby duikkie » Wed Jan 21, 2015 8:58 pm

it is register 6 , vertical displayed register
it is not turning your screen off :) , it makes it very small in rows

leenew wrote:Cheers Simon,
Call me old-fashioned, but why would a menu program for a games disc need to program the 6845?
In the BASIC menu listing, I also find:
?&FE00=6 and ?&FE01=1
?&FE00=6 and ?&FE01=25

Is this approach going to make these menu's less friendly to the Master?

My menus had "Press A to play game A, and press B to play game B!" :roll:

Lee.

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

Re: Today I hacked ...

Postby lurkio » Thu Jan 22, 2015 11:22 am

leenew wrote:SO, the bit I am not sure about is at &1E23 ... This is something to do with interrupts (NMI) what does it actually do? ... In the BASIC menu listing, I also find: ?&FE00=6 and ?&FE01=1 ... ?&FE00=6 and ?&FE01=25 ... Well unless I am mistaken, these pokes turn the screen off, and then turn it back on. The original one at &1E23 seems to turn the screen off too...
duikkie wrote:it is register 6 , vertical displayed register ... it is not turning your screen off :) , it makes it very small in rows

Here's my guess.

The first poke, to CRTC register 1, sets the number of chars per line to zero, which in effect "disables" the screen, turning it black. I think the point of this is to prevent the *KEY0 commands from flashing up on screen as they're executed. Makes for a "cleaner" display.

The second poke, to CRTC register 6, sets the number of text-lines on screen to 1, but I think the intended effect is the same as before: to prevent anything appearing on screen till the whole menu has been printed out completely, at which point the third poke restores the display. So you don't see the menu items appear line by line -- they all seem to appear at once. It's a visual effect.

Is that correct?

I still don't understand what's happening with the data in &1EE0 to &1EFF, which gets copied to &A0 to &BF (which apparently comprises "Current NMI owners workspace", "Transient command space" and "Filing system scratch space"!) because if you disable the copying by replacing the contents of &1E39 to &1E3B with &EAEAEA, the menu still works!

Michael Brown
Posts: 1896
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham

Re: Today I hacked ...

Postby Michael Brown » Thu Jan 22, 2015 11:56 am

Hi all,

Yes the ?&FE00 commands on the menu were designed to simply switch part of the screen off whilst the menu is printed and then switch it back on once done to make the menu look like it as been printed much faster than it normally would.

The code that is moved from &1E80 down to &40 is simply the code that is normally stored at &40 when the machine is switched on. This is included in the menu to poke this code back into that location after playing each game as some games go a bit funny if previous code from games is left at that location as *FX200,3 does not wipe this area.

This code is for the BBC B, but you could save code from any machine at that address and then load it in over the !BOOT file at &1E80 and then *SAVE back to the !BOOT file.

regards,
Mick.

PS Eagle Empire and Martian Attack were 2 games that played up without this code in place IIRC.

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

Re: Today I hacked ...

Postby flaxcottage » Wed Apr 29, 2015 9:39 pm

I came across another protection method whilst archiving Ecce Romani by Longman. To date Longman titles have been unprotected and have been very good. To have a protected title must mean it is really good, I thought.

The protection was in a several layers.

First the disc was formatted with a non-standard track 2. This had 5 sectors each of 512 bytes. The track does not contain any data but that was not obvious at the start. Second the catalogue contained a file !.LMSdsp1, whose catalogue data showed it to occupy the whole of track 2. Thus the disc was protected from *BACKUP and *COPY *.*, enough to deter the casual teacher copier BITD.

The next layer of protection involved the program MENU. This was a hybrid BASIC/Machine code file. It had to be *RUN. Disassembling the code revealed that the BASIC program was at the start. The code loaded at &1B00. However a quick PAGE=&1B00 followed by OLD gave the Bad program error.

MENU begins execution at &1D0D, which, after setting some zero page data values in &82 to &87 and disabling Break and Escape, read the sector IDs of track 2. The code checked for 512 byte sectors and returned a Bad Copy error if they were not found. Apart from that the code did not attempt to read any data from the 512 byte sectors. Modifying the code to jump over the checking routine would allow the program to continue.

The next step the code did was to make the BASIC program part runnable. To prevent listing the BASIC code had been deliberately made invalid. This had been done by putting an end-of-program marker as the first byte of the program and by changing the line pointers by EORing with &D6. The machine code put a carriage return character at the start of the program and ran through the BASIC code restoring the line pointers.

The BASIC would now be runnable so PAGE=&1B00|MXFX2,0|MOLD|MRUN|M was put into the keyboard buffer and the program finished, displaying the main menu.

The protection still had not finished. A *INFO *.* command showed that all the component programs had been saved from PAGE &1B00, leading the casual copier to think that they ran from there. They actually loaded at PAGE &1200 unless PAGE was currently set below that when they ran at the lower value.

In the end, all I needed to do was to change only three bytes in the MENU program and the package ran correctly. And when the package ran it was clear that all that effort to protect the programs was more than the effort that had been put into the programs themselves. :lol:
- 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

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

Re: Today I hacked ...

Postby richardtoohey » Wed Apr 29, 2015 9:46 pm

flaxcottage wrote:In the end, all I needed to do was to change only three bytes in the MENU program and the package ran correctly. And when the package ran it was clear that all that effort to protect the programs was more than the effort that had been put into the programs themselves. :lol:
:lol:

You find that, don't you? Takes hours to work out what the protection was, unwrapping the onion layer-by-layer, and then ultimately a NOP here or there overcomes it. And then you realise you spent more time doing that than using the software. :D

=D>

User avatar
george.h
Posts: 1027
Joined: Wed Apr 13, 2011 5:32 pm
Location: Chelmsford Essex

Re: Today I hacked ...

Postby george.h » Fri May 01, 2015 2:59 pm

flaxcottage wrote:In the end, all I needed to do was to change only three bytes in the MENU program and the package ran correctly. And when the package ran it was clear that all that effort to protect the programs was more than the effort that had been put into the programs themselves.


Ah, ye olde software version of "pass the parcel (bomb)".

You spend ages carefully removing layer upon layer of wrappings......... only to find an empty box at the end..... :?
Pic Caption: "One day son, this will all be yours..."

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

Re: Today I hacked ...

Postby billcarr2005 » Fri May 01, 2015 9:48 pm

flaxcottage wrote:Thus the disc was protected from *BACKUP and *COPY *.*, enough to deter the casual teacher copier BITD.

But the file "onecopy" allows for a backup to be made :)

flaxcottage wrote:...after setting some zero page data values in &82 to &87

This is "BASIC"+CHR$(13) which is later OSCLI'd

flaxcottage wrote:In the end, all I needed to do was to change only three bytes in the MENU program and the package ran correctly.

For the ultra minimalist, you could've changed just 1 byte and had it check for a 256 byte sized sector :wink:

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

Re: Today I hacked ...

Postby flaxcottage » Sat May 02, 2015 7:45 am

billcarr2005 wrote:But the file "onecopy" allows for a backup to be made :)

For the ultra minimalist, you could've changed just 1 byte and had it check for a 256 byte sized sector :wink:


OK, fair cop. :oops:

This is why many heads are better than one. :D

I still think it wasn't worth hacking apart from the intellectual challenge. :twisted:
- 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

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

Re: Today I hacked ...

Postby flaxcottage » Fri Jul 03, 2015 7:19 pm

Found another software protection method today whilst archiving LTS Space Adventure.

The disc was a single-sided 40T disc with no bad sectors. It even catalogued with no problem. However ...

    the number of files on the disc and the disc size were both set to zero
    filename 1 was seven zero bytes and had a start sector of &3FF which made it past the end of the disc
    the properly named files would copy from the disc but not run from the copy
    the original would not run on my Master that I use for hacking


So, *BACKUP and *COPY were both out of the picture as was *EXPORT on my datacentre. :(

!BOOT was a simple exec file to CHAIN"MENU". Loading MENU and LISTing and wow! :shock: The screen froze with lots of beeps. Ahah! Time for the BASIC editor.

This wasn't much better. Three lines and then gobbledegook. The three lines did a *FX200,3 (pretty standard), checked PAGE was at &7000 and reloaded if necessary and then ran a subroutine at 22000.

At 22000 the code did some clever stuff.

    first it read memory locations &F07 and &F0F and added them together
    used this number to seed the random number generator
    parsed the BASIC program and EORed each byte of BASIC code with RND(255)
    stopped when it reached line 22000
    returned to the main program where it, presumably, continued with running the menu program


Location &F07 contains the low 8 bits of the disc size and &F0F contains the low 8 bits of the starting sector of the first file on the disc (this was the one with no name). ADI showed these values to be 0 and 255 respectively, hence the program was seeding the random number generator with 255 so that it would produce a repeatable sequence of random numbers for decrypting the rest of the code.

This is not the case in a Master, which I was using. I even tried poking the right values into &F07 and &F0F on the master then executing the subroutine but it didn't work! :(

I needed a BBC model B to try. The snag was all my beebs have 3.5" discs. Simple though. I have a Master with dual 5.25" and 3.5" drives - use that and ADI to copy the discs. Oh yeah?

Switched the Master on and nothing, no beep no lights, zilch. Now it was working an hour before because I had used it. The PSU was dead (another job to do at a later date). OK, switching the PSU for one from my spare. Should I change the caps? Nah, it will be OK. Horrible smell they make after sizzling. :oops: :oops:

But the machine was still working OK so I used ADI to transfer the disc to 3.5" format. (Now I have two PSUs to repair!)

On the BBC model B the copied disc ran from shift-break - great. =D> So a model B was needed to run the software.

From then on it was easy. Load MENU at PAGE=&7000. Call GOSUB22000 to decrypt and save on my network as MENU1. Looking through the program showed that the two main programs were also encrypted in the same way. A quick modification to stop the code at a crucial point and I had these programs decrypted and saved on my network.

A little bit of modification to the menu program and the title now runs on everything I've tried.

The original disc is one for billcarr2005 to archive as an FSD to preserve this method of protection.
- 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

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

Re: Today I hacked ...

Postby billcarr2005 » Sun Jul 12, 2015 8:41 pm

Picked this up today in Bolton.

Since there's no straying from the track containing 10 x 256 bytes sectors, and no jiggery pokery with the IDs, it happily becomes an SSD :)
It contains some nice methods to deter casual *COPYing and alteration of the disk.
As stated above, it won't play nicely on a BBC Master :(
Attachments
Space Adventure.zip
Space Adventure
(19.32 KiB) Downloaded 37 times

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

Re: Today I hacked ...

Postby flaxcottage » Sat Aug 06, 2016 5:24 pm

It has been very quiet on the archiving/hacking front for me for a long time. :(

To make up for this I took a look at an ESM title, Colour/Shape Snap. To make matters even worse the disk was partially corrupted too so that only some of the programs worked but they were for a concept keyboard so I had a look.

Firstly the disk catalogue only contained one entry, !BOOT and this was a machine code file. Sometimes discs have the catalogue hidden so on examining track 0 sector 0 with ADI I found that there was only !BOOT showing. And this is where the fun started!! :?

!BOOT was encrypted and when it ran it decrypted itself and then ran the decrypted code. Previously when I have found files like this there has been a back door to get into the code. Not this time. All bytes of the machine code file were used in the decryption key. I could not alter a single one!

The solution to this was to write my own decryption program that worked on the original code using the decryption algorithm. This worked well and I now had the decrypted code to examine. This code had clearly been written to confuse. It copied code from itself to different parts of the computer and executed the code from there to load data directly from the disk surface using OSWORD &7F.

Examining the code loaded directly from the disk not via any catalogue I could see that the code performed a *BASIC and a CHAIN"BOOT" command. It also re-directed the read character vector so that any keyboard input caused the program to hang after the *BASIC command. The code was very hard to follow as it copied routines all over the place before executing them and over-wrote itself using OSWORD &7F so that execution continued with the new overlaid code.

Time for another approach. :idea:

If the code performed a CHAIN "BOOT" then there must be a directory set up in RAM so that the CHAIN command could work; there was not a BOOT entry in the disk catalogue. Back to ADI to examine the contents of the disk sector by sector. There it was on track 0 sectors 3 and 4. All the entries were ordinary BASIC programs.

I then wrote a program to copy the directory from the original disk T0 S3&4 onto a newly formatted disk in drive 1. This catalogued correctly. *INFO * gave me the details of where the files were on the original disk so I then completed the copy program to copy the data for each program directly sector by sector.

Unfortunately the original disk was partly corrupted so that about half the code could not be copied. The end result is all the usable code on a SSD file archived. If I ever find a good copy of the disk, running the copier program will produce a new working copy.

After all this detective work was the code so brilliant it needed such obscure protection? No. It was fun while it lasted though. :lol:
- 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

User avatar
leenew
Posts: 3402
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire

Re: Today I hacked ...

Postby leenew » Sat Aug 06, 2016 6:32 pm

Good work John!
As usual, the challenge and fun of cracking the protection far outweighs the rewards of using the software at the end of it!

Lee.

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

Re: Today I hacked ...

Postby flaxcottage » Sun Aug 14, 2016 3:58 pm

Another protection method unravelled ...

I looked at the Longman title "Shallow Hill". This is an archaeology title on 40T floppy disk. The protection was layered.

1. firstly the floppy disk catalogue was protected with VDU21 in a strategic filename thus making most of the files invisible; the last file in the catalogue was named with a VDU6 making the VDU output work again

2. only 20 tracks of the disc were formatted

3. the logical track numbers differed from the physical track numbers

4. Track 1 sector 0 had an undefined error which returned a non-zero value from using OSWORD &7F to read the sector

5. two of the main programs on the disk checked T1S0 for the error before running

6. two BASIC programs on the disk were presented as machine code files.

Defeating this protection was a lovely detection story and certainly exercised the old grey matter! Points 1-3 were easily defeated by simply copying the files individually, having used ADI to read T0S0 on the disk to find the titles.

The two protected files both loaded at &1B00. The front part and the back part were machine code programs. The front part checked whether the disk protection was present. The end part moved the BASIC code down to &1B00, returned to BASIC, set page to &1B00, performed an OLD command, poked nonsensical data into &1B00 and &1B01, removed the &FF flag from TOP-1 (to make the BASIC code un-LISTable) and then ran the code.

After disassembling the code for these protected programs it was found that the simplest and smallest change to make the programs copyable and runnable from the copies was to change the BNE command at &1B58 to BEQ, that is a change from &D0 to &F0. 8) :D

If anyone is interested in this protection method I have attached the working code. The two files P.ARCHEO and P.ARMain contain the protection. To see it in action change &1B58 to &D0 in both programs. As is so often the case, the protection method was far cleverer that the main program code!!
Attachments
Shallow Hill.zip
(23 KiB) Downloaded 24 times
- 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

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

Re: Today I hacked ...

Postby richardtoohey » Mon Aug 15, 2016 4:32 am

flaxcottage wrote:...the protection method was far cleverer that the main program code!!
Answered my question before I even asked it! :D

Thanks for the write-ups, always interesting and appreciated.

Maybe one day you'll find a title that is better than the copy-protection? :?:

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

Re: Today I hacked ...

Postby flaxcottage » Mon Aug 15, 2016 6:36 am

richardtoohey wrote:Maybe one day you'll find a title that is better than the copy-protection? :?:


Oh, I have, Richard. The Sherston titles are generally superb and the W1S method of protection is quite simple to defeat (well once I understood it!).

So far, thankfully, the protection has been devious rather than technically challenging. The authors have always left a 'back door' available. Even protection that has involved some quite clever manipulation of track and sector parameters has allowed me to put a break point into their code to extract the 'hidden' data. :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

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

Re: Today I hacked ...

Postby lurkio » Sat Aug 20, 2016 6:09 pm

Today I hacked The Seventh Star (1984), a text adventure game by David Hampton and Acornsoft for the BBC Micro Model B. (Sorry this post is so long. This is hardly the greatest hack in the world, but it was the first game I'd hacked in a serious way, and I was horribly pleased with myself.)

This is all part of my and Lee's continuing quest to produce "definitive" versions of Beeb text adventures by making sure that they're all as bug-free as possible, that they run on a range of machines and emulators, and that they include full, long, and painstakingly digitised and proofread instructions, for which we're using our patented (i.e. ripped-off) MODE 7 text-scroller program. This is obviously an epic task that's unlikely to be completed in our lifetimes. We are clearly insane.

Anyway...

As we didn't have access to any original hard copies of the game, I was hoping we'd just be able to take the .SSD disc image from the STH archive, stick our instructions on the front, and say Bob's your second-degree male relative with 25% genetic overlap.

The first problem we ran into was that the STH disc version of the game could be put into an "illegal" state if you QUIT and restarted: you'd end up back at the beginning of the game, but you'd still have any objects you'd been carrying at the end of your previous session! This was a handy way to cheat if you realised what was going on, but also quite disorienting -- for new players and serious solvers alike.

(By the way, does anyone know if there ever were any serious players of Seventh Star? It's said to be the "rarest" of the non-Atom Acornsoft adventures, and it's one of only two that don't have a solution on CASA. (The other one is Spooky Manor, but that at least has a map.) In fact, there were no known solutions to Seventh Star at all -- until now! See below.)

Anyway, the .SSD version of Seventh Star from STH clearly wasn't going to meet our exacting standards, so we decided to go back to the UEF tape image. That too was taken from the STH archive, but it seemed to be less unpredictable, and the game files would hopefully be closer to those from the original release. And so they seemed, if the protection was anything to go by.

Unknown.jpeg
The main game file was protected

Not only was the main program file locked (so you couldn't just *LOAD it from tape), but also I found that you could run it just by typing */|M (star slash bar M) at the commandline! This baffled me for ages till Lee explained that the file had cunningly been given a filename that consisted solely of the Carriage Return char (CHR$ &0D), which the BeebEm Tape Control window interprets as "<No name>"! The solution was simply to select the "Unlock Tape" option in BeebEm, and then do *LOAD "", and then *SAVE to disc.

Next, we came across some machine code at the high end of user memory (&7A7C and up) which seemed to be checking that the game had been loaded by the custom tape loader that would normally have run at &400. The checkup-code at &7A7C was EORing and doing various other tricky things I don't fully understand -- all to make sure you weren't trying to run a cracked, transferred-to-disc version of the game, which, unfortunately, was exactly what we were trying to do! Luckily, though, it seemed that the checks could be bypassed fairly easily -- simply by not calling them in the first place!

Once we'd eliminated the copy-protection code, we were left with the main BASIC program which handled game-setup, user input, message output, saving and restoring position, and puzzle logic. The BASIC program was dense, and called several machine code routines below PAGE, which was raised to &5400 to accommodate all the machine code and the game data.

So, if I've analysed the game correctly, the memory map for the tape version of The Seventh Star is as follows:

    0900 - 0AA3 : Sound envelope data. (But why does this spill over from page &09 into page &0A?)

    0AA4 - 0AFF : Empty (all zeroes).

    0B00 - 0BFF : Junk! Seems to be fragments of BASIC and game data that are incomplete, useless, and never called! Weird that this junk was left here because it overwrites any soft-key definitions that the user might have set up, and thus makes it impossible for players to use function-key text-input shortcuts!

    0C00 - 0CFF : Machine code routines called by the BASIC program.

    0D00 - 0DFF : Unused. I don't think the game uses this page.

    0E00 - 0EFF : Game data and/or game code.

    0F00 - 0FFF : The player's current position and the current state of the gameworld. It's this page of data that the game saves to tape when the player enters the SAVE command.

    1000 - 53FF : Lots more game code and/or game data.

    5400 - 7A7B : The BASIC program.

    7A7C - 7B44 : Copy-protection machine code that can be eliminated.

When the tape version of the game is run, it first loads the initial-position data from a file called INIT into &F00-&FFF (i.e. page &0F), and it reloads INIT from tape every time players QUIT and restart the game.

The trouble with the STH disc version is that although it can load the INIT data into &F00 when it's first run, it immediately has to relocate the large main game file down to &E00. This makes subsequent use of the disc filing system impossible! So the game now has no way to reload the INIT data when the player wants to restart! That's the problem we wanted to solve.

Unknown-2.jpeg
QUIT and restart: STH tape (left) vs. STH disc (right)

And the solution was obvious: stash the INIT data somewhere where it would be safe for as long as the player wanted to keep playing (and re-starting) the game. But to do so, we'd need to find a whole page of free memory -- which is in short supply in a Beeb running a game that occupies most of the available RAM! The only likely candidates were page &0B and page &0D. The latter is allocated to (it says here) "NMI and ROM workspace", which I didn't want to mess with because I wasn't entirely sure what it was, and its name gave me the willies. So that just left &B00-&BFF, which, since it was only filled with garbage anyway, looked like the ideal spot to secrete the INIT data till it was needed. So that's what I did.

I then needed to very carefully tweak the BASIC program so that it would copy the INIT data from &B00 to &F00 on load and restart. While I was at it, I also added tweaks to allow players to specify a filename when loading a saved position, which is necessary for loading savegames from disc, which you can do with my version of the game if you run it on a Master 128 (real or emulated). Here again, though, there was a problem: how much could I add to the BASIC program and still leave enough room in memory for the heap and the stack? My paranoia about this issue led me to squeeze some machine code and some text strings into that unused patch of RAM between &AA4 and &AFF. It seemed to work.

That was all very well, but it would mean nothing if I couldn't prove that my new, hacked version of the game was functionally equivalent to the original tape version in every way. And this was the last and possibly the biggest problem of all because, as I said, there was no known solution or walkthrough for The Seventh Star. So I had to solve it myself. And I did. And it was tricky. But that's probably a story for another time and another place.

Suffice it to say that my version of the game does seem to work, and it appears to be functionally equivalent to the original tape version. So, yay for me.

Finally, then, here are the main features of my version of The Seventh Star:

  • It's been transferred to a .SSD DFS disc image.

  • Comes with full original instructions, including original hints.

  • You can QUIT and restart the game without error.

  • On a Model B, you can save and restore your position to and from tape.

  • On a Master 128, or any machine with an &E00 DFS, you can save and restore your position to and from disc. (An &E00 DFS is a disc filing system that leaves PAGE at &E00.)

  • Playing my version will bring you "good luck".

Here's my version of the game on a .SSD disc image:


You can also play my version online in JSBeeb:


Here's my solution to the game. I've broken it into sections separated by asterisks. You can copy and paste it into BeebEm, one section at a time:

Code: Select all

GET CROW
GET MICRO
GET BUCKET
N
JOE
BLOGGS
N
GET CARD
N
N
N
INSERT CARD
3013
GET MONEY
S
S
S
SE
JUMP E
JUMP E
N
GET WATER
S
JUMP W
JUMP W
NW
E
DROP CROW
BUY SCANNER
DROP MONEY
GET CROW
DROP MICRO
W
D
IN
S
GET UNIT
INSERT UNIT
E
SE
U
E
GET MICRO
W
SW
IN
USE SCANNER
S
E
W
S
S
THROW WATER
DROP BUCK
U
GET CANDL
D
N
N
N
OUT
NE
N
N
GET MATCH
NE
GET GRAT
DROP CROW
D
S
E
W
D
D
DROP SCAN
DROP MICRO
LIGHT CANDL
THROW CANDLE
D
GET TUBE
U
GET MICRO
U
E
E
U
W
W
S
SE
SE
GET BROW
NW
NW
W
D
S
E
E
U
IN
DROP BROW
OUT
W
W
S
S
SE
E
JUMP E
N
THROW COIN
********************** Note password
S
JUMP W
JUMP W
NW
W
IN
********************** Enter password
OUT
DROP MATCH
E
N
W
D
S
S
SEARCH
GET ROBOT
N
E
E
U
W
W
S
S
SW
IN
S
S
W
NE
BREAK LOCK
W
W
W
LOOK
S
E
GET WIRE
S
S
W
E
N
N
OUT
NE
N
W
D
S
E
W
D
D
DROP TUBE
DROP MICRO
DROP TAG
DROP WIRE
D
E
E
D
GET SAND
SE
S
SE
U
GET WIRE
GET TUBE
GET MICRO
GET TAG
U
E
E
U
W
W
S
S
NW
GIVE SAND
W
W
GET GLOV
E
E
S
E
DROP MICRO
GET MONEY
BUY CASE
OPEN CASE
PICK LOCK
GET ROD
DROP WIRE
GET MICRO
DROP TUBE
W
SE
JUMP E
JUMP E
GET BRANCH
N
N
E
VAULT FENCE
GET EGG
S
JUMP W
JUMP W
NW
SW
IN
S
S
W
S
SE
E
DROP EGG
S
E
NW
SE
E
N
SW
S
W
N
SW
S
RUB ROD
DROP ROD
DROP GLOV
N
N
S
E
N
NE
S
W
W
S
W
N
N
N
N
INSERT TAG
W
N
E
HELP
NE
DROP MICRO
SE
S
GET BLUE
N
NW
GET MICRO
HELP
SW
W
S
E
S
S
W
W
NW
N
NE
W
E
N
N
OUT
NE
W
IN
********************** Enter password
OUT
E
N
W
D
S
E
W
D
D
DROP MICRO
D
E
W
E
UNLOCK HATCH
E
N
N
W
SEARCH
GET INSTRU
EXAM INSTRU
E
S
S
W
W
N
SE
U
U
E
E
U
W
W
S
S
E
GET TUBE
W
SW
IN
S
S
W
NE
N
IN
PRESS BUTTON
BLOW TUBE


Do have a go at the game. If you run into any problems, please contact Lee. ;-)

8)
Last edited by lurkio on Thu Sep 01, 2016 3:23 pm, edited 6 times in total.

User avatar
leenew
Posts: 3402
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire

Re: Today I hacked ...

Postby leenew » Mon Aug 22, 2016 11:13 am

*cough* :shock:
Thanks for that Mr. Lurkio...

Good work by the way =D>
It really is amazing how many of these adventures don't work properly.
Did anyone ever check them after "copying" them to disk I wonder? *tssssk*

Seventh Star - the most overlooked Acornsoft adventure, is actually rather good :wink:

Lee.

Michael Brown
Posts: 1896
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham

Re: Today I hacked ...

Postby Michael Brown » Tue Aug 23, 2016 10:36 am

Oh Dear!!!
This means my version on disc092 also doesn't work properly either then.

I will amend it using the method used here and re-post the disc asap.

thanks for sorting another faulty game
Mick.

User avatar
leenew
Posts: 3402
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire

Re: Today I hacked ...

Postby leenew » Tue Aug 23, 2016 1:10 pm

I will send you the image later Mick.
You can pick which bits you can fit on the DSD.
Lee
EDIT; the image is above... of course

Michael Brown
Posts: 1896
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham

Re: Today I hacked ...

Postby Michael Brown » Tue Aug 23, 2016 4:10 pm

Hi Lee,
I think I have done it.
I will send you a copy of disc092 by email first.

Mick.

User avatar
CMcDougall
Posts: 5618
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Today I hacked ...

Postby CMcDougall » Tue Aug 23, 2016 7:00 pm

lurkio wrote:Playing my version will bring you "good luck"

nice one =D> =D> =D>
password for old lady is : Vodel
Attachments
FIN.png
ImageImageImage

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

Re: Today I hacked ...

Postby lurkio » Tue Aug 23, 2016 9:02 pm

CMcDougall wrote:
lurkio wrote:Playing my version will bring you "good luck"

nice one =D> =D> =D>

Thanks!

CMcDougall wrote:password for old lady is : Vodel

Are you absolutely sure about that, Col...?!
:-k :wink:

ThomasHarte
Posts: 364
Joined: Sat Dec 23, 2000 5:56 pm

Re: Today I hacked ...

Postby ThomasHarte » Wed Aug 24, 2016 2:47 pm

Apologies for another slight segue: did the community ever agree on a disk image format suitable for protected titles? Is there an archive of them anywhere? I'm aware of plenty of options — FDI, Kryoflux draft or stream files, various others.

Michael Brown
Posts: 1896
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham

Re: Today I hacked ...

Postby Michael Brown » Wed Aug 24, 2016 3:22 pm

With ref to Seventh Star.
According to my database, this was the only game written by this author.
I have had a look through some other Acornsoft adventures and they all seem to reset upon quitting and restarting, so hopefully... this was the only problem.

Mick.

PS I will now add the corrected version to my disc 092 and repost it in the other thread.

User avatar
1024MAK
Posts: 6791
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Today I hacked ...

Postby 1024MAK » Wed Aug 24, 2016 4:35 pm

Another member has been using Kryoflux to archive some protected disks I believe, but I don't know if he has put them online anywhere :?

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Today I hacked ...

Postby Rich Talbot-Watkins » Fri Aug 26, 2016 12:27 pm

I split off the posts about protected disc image formats to a new topic so they don't get lost in the discussion.

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

Today I hacked Programmer's Revenge

Postby lurkio » Sat Oct 08, 2016 5:21 pm

.
1.png
Screenshot: title screen of Programmer's Revenge


Today I hacked Programmer's Revenge (1984) by Colin Jack of Colisoft.

My starting point was the UEF tape-image from the STH archive. The problem was that the main program loaded at &E00 from tape and then immediately proceeded to read in the values of many, many variables from a data file, using OPENUP and INPUT#.

2.png
Screenshot: the original main program


This all worked well on a Beeb with a tape recorder -- and also on a Master 128 with its DFS that leaves PAGE at &E00. In fact, the Master can run a simple tape-to-disc transfer of the game that hasn't been altered in any other way, and it will even save and restore the player's position to and from disc.

But what about the poor old Model B with its DFS that raises PAGE to an uncomfortably high &1900 by default? You want to run the game off disc, but there just isn't enough memory left in a Model-B-with-DFS to accommodate the main program, the file-input routine, and the data. The game won't even let you set PAGE at &1300 ("No room [above PAGE]" error). But then if PAGE is lower than &1300, there isn't any room below PAGE for the DFS file buffer that's required by INPUT# when it's trying to read in all that init data from disc...

(Incidentally, duikkie got round the problem by taking the radical approach of actually hacking out bits of game-content, apparently including the message that's supposed to be displayed when you win the game! Which is a bit drastic. ("duikkie's Revenge"?!))

If only you could take a snapshot of the state of user-memory once the data had all been read in from tape and setup had finished: you could then save that snapshot to disc and reload it whenever you wanted to play the game...

Well, it turns out that you can. If you load the game as usual and wait for the data values to be read in, you can then save off all the memory between PAGE (&E00) and VARTOP (&7A36 in this case): this area of RAM stores all the values of the variables that the running program has assigned so far. You also have to save off the variable-pointers in Page 4 (&400 - &4FF).

Then, for the next time you want to play the game, you create a loader that reloads all the saved RAM, relocates the main-prog-plus-variable-storage down to &E00, sets up the BASIC pseudo-variables so as to "fool" BASIC into thinking it's already part-way through running the main program, and then does a GOTO to the jumping-in point in the program, bypassing the file-input routine. (It was actually much trickier to engineer all this than I'm making it sound. Believe me, this is the TL;DR version of the story.)

3.png
Screenshot: the loader program (EXEC file)


The BASIC pseudo-variables to which the loader has to assign values are PAGE, LOMEM (&00-&01), VARTOP (&02-&03), TOP (&12-&13), and HIMEM. You have to use direct-to-memory pokes to set most of these up because otherwise you risk erasing the variable-pointers that you just loaded into Page 4. (For example, if you type LOMEM=&2C62 (or whatever value) at the BASIC prompt, you'll find that Page 4 has been wiped clean!)

Here's the result of my hacking: a .SSD DFS disc-image that includes the original version of the game, which can be run on a Master 128 (or BeebEm in Master 128 mode), and which saves/restores to disc. The .SSD also includes my hacked version, which can be run on a Model B (or BeebEm in default Model B mode), and which saves/restores to tape. Version-selection is automatic, based on the value of PAGE.

    proghak6.ssd.zip
    .SSD DFS disc-image of Programer's Revenge, including original and hacked versions
    (26.57 KiB) Downloaded 19 times

Play online:


Please try it and let me know about all the mistakes I'm bound to have made...

:idea:
Last edited by lurkio on Sun Oct 09, 2016 4:54 pm, edited 4 times in total.

User avatar
roland
Posts: 2808
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Today I hacked ...

Postby roland » Sat Oct 08, 2016 9:49 pm

A Paypall payment to a webshop [-X

Schermafbeelding 2016-10-08 om 23.43.21.png


The redirection to Paypal went wrong and I could change the payment information with Firebug. And now wait if they still deliver the goodies. If not then I lost €0.03 :mrgreen:
256K + 6502 Inside
MAN WOMAN :shock:

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

Today I hacked "The Real You"

Postby lurkio » Mon Dec 12, 2016 12:28 pm

~
I was hacking StairwayToHell's tape image of The Real You to try to transfer it to disc for the bbcmicro.co.uk archive.

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:

    screenshot.png
    Screenshot of Disc Doctor trying to disassemble machine-code
And yet, as you can see above, if you call the code, it seems to run, and starts loading in the main program from tape without any problem! How is that possible?!

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!

Replacing each TOP with three NOPs made things a little clearer:

    screenshot2.png
    Screenshot of Disc Doctor disassembling modified machine-code

First time I've seen these undocumented 6502 opcodes in the wild.

:idea:
Last edited by lurkio on Mon Dec 12, 2016 1:27 pm, edited 1 time in total.


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 3 guests