News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

an unpublished tip for pyradev users

Started by gef, 02:12, 03 April 10

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gef

Hi,

this is a flashback from my CPC activities 25 years ago...
...how to hack well protected games.

if anyone of you is still playing with Pyradev, trying to hack games that use the R register,
XOR the hell out of them, play funny tricks with interrupts etc, there is an easy way out:
you need a small patch which I can't supply but, could describe in good detail, since I invented it ;-)

The patch allows you to trace through any Z80 code and is based on two important facts:
* The R register is changing deterministically among subsequent commands (say, by +1 or +2).
* The state of the IFF (Interrupt flag) is actually possible to be found with a "LD I,A" or so.

This latter tip is very crucial since some games/hacking protections require a certain state
of the interrupt, at any given point of the code execution. The funny aspect is that I owned
both a Zilog and a Mostek (=z80 clone manufacturer) manual and the important information
was *only* referenced in the Mostek documentation, though it has been working fine in any
z80 implementation I was ever able to put my hands on. Bingo!

So, the rough sketch of the code patching Pyradev's breakpoint logic was:
a) Store the value of A accumulator immediately in a memory byte "X"
b) Do LD I,A and then branch according the Overflow flag (AFAI remember that's the one),
    effectively storing either of "EI" or "DI" commands, for later use upon exiting - major deal for step (g)
c) Store the value of R in A, then store in memory "Y".
d) Jump back in Pyradev (after having forcing it to exit back to next step "f")
e) Perform your regular Pyradev tasks, as normal (disassembly, breakpoints etc)
f) Put "Y" value in A, and perform subtract in 7-bit logic of a constant "Z" (read how R functions in z80!)
g) do EI or DI, in accordance with step (b) above
h) Store A to R
i) Get value for A from memory "X"
j) jump back to original (game) code as if nothing happened

All the trick was tuning "Z" to the correct value for getting code transparency!
But, that should be a constant number and it's easy to track down with minimal effort.

Needless to say, no hacking-protection attempt was able to resist the patch...
...the first game that fall back then was "Live and Let Die", then "Double Dragon", then many others :)
... if Internet existed, this patch would have been extremely popular; effective and just <50 bytes to patch!

You are the first guys to know: I had a great time when I was using this ;-)

cheers,
F.

gef

#1
So,

Quote from: gef on 02:12, 03 April 10
  [...]
  The patch allows you to trace through any Z80 code and is based on two important facts:
  * The R register is changing deterministically among subsequent commands.
  * The state of the IFF (Interrupt flag) is actually possible to be found with a "LD I,A" or so.
  [...]
  b) Do LD I,A and then branch according the Overflow flag (AFAI remember),
  [...]
 

  OK, the assembly command is actually written LD A,I and the z80 undocumented trick
  is explained here in sections 6 an 8 (it is even buggy in certain implementations, wtf!):
  http://www.worldofspectrum.org/z88forever/dn327/z80undoc.htm
 
  I have obviously been influenced by the Intel mnemonics rather than AT&T over the years!
    http://en.wikipedia.org/wiki/X86_assembly_language#Syntax
 
  btw.
  The clone company' name was indeed Mostek, not Mustek; I've got gray hair since those times ;-)
 
  ps.
  Someone might ask why this has been posted under Emulators...
  ...the reason is that I'd expect people having used Pyradev to be doing this kind of stuff these days;
  if you know better how to navigate in the forum, please supply advice.
 
Also, if people reading this are close to Lugano, Switzerland, please get in contact.

  enjoy,
  F.
 
 

gef

Quote from: gef on 12:18, 03 April 10
  I have obviously been influenced by the Intel mnemonics rather than AT&T over the years!
    http://en.wikipedia.org/wiki/X86_assembly_language#Syntax

Actually, it seems that the common assembly style for CPCs *was* called Intel style... whatever.

Anyway, I will be strictly talking about Emulators now:
* Has anyone managed to get an CPC6128 emulation running at good state in recent smartphone?

I am specifically interested for compatibility in the iPhone vs Android debate
and I am willing to make my buy based solely on this answer :)

It has been a great outcome to use my current Nokia N95 with s60cpc/caprice emulators,
hooked on my HD projector along with a bluetooth keyboard: highly recommended experience!

Also, if you are Spindizzy fans, please report here under what platforms you have revived the game
(including PCs etc).

tia,
F.

Devilmarkus

Sorry, I don't own any cellphone or something like that running an emulator.
I only play games with my real CPC or with the emulator I am coding...

About spindizzy:
Yes, was funny in the 80s, but today I prefer other CPC games ;)

I often have been asked why I don't adapt my emulator for Java-cellphones.
The answer is quite simple:
- in 2004 I found JEMU (http://jemu.winape.net .... yes, JavaCPC has JEMU core inside!)
- I begun modifing it's sources and also adding improvements, new apps, etc...
- I really don't know much about Java. All I did was "doing by learning".
- Also I don't know anything (or maybe 10%) of emulating things... I'm testing around with source modifications.
- Java for cellphones is much different than JDK for PC's
- JavaCPC/WebCPC is also open source. (Like JEMU) So maybe it will be found a person who can adapt it for phones, too ;)
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

Cholo

Thanks for posting. This pretty much answers one of my oldest still lasting questions:
1. how did people hack those tape protections before the multifaces showed up and
2. how did the programmers compile a protection like that.

Back in the 90's i did manage to read 2 books on machine code and did get fairly fluid in assembler. Even tho as a teenager i had a hard time seen the "big picture" in mc/assem.
Did try to dissassemble and later singlestep into a couple of tape protections, but came to a loss on how to continue. Knew there had to be a trick to it of cause. If it was just lack of knowledge and/or/of additional hardware i didnt know.

Seems like i know at least the theory how to get into a protection and i assume a similar trick can be used to compile one too.

arnoldemu

Quote from: Cholo on 20:48, 04 April 10
Thanks for posting. This pretty much answers one of my oldest still lasting questions:
1. how did people hack those tape protections before the multifaces showed up and
2. how did the programmers compile a protection like that.

Back in the 90's i did manage to read 2 books on machine code and did get fairly fluid in assembler. Even tho as a teenager i had a hard time seen the "big picture" in mc/assem.
Did try to dissassemble and later singlestep into a couple of tape protections, but came to a loss on how to continue. Knew there had to be a trick to it of cause. If it was just lack of knowledge and/or/of additional hardware i didnt know.

Seems like i know at least the theory how to get into a protection and i assume a similar trick can be used to compile one too.
I used another trick for hacking tapes to disc but this only works well for 128k machines and you need a reset switch.

You setup the 2nd 64k ram to be a mirror of the 1st.
You switch to it and load the game.
Many times the loader will run and the computer will effectively reset, but the loader is now decoded in the 2nd bank of ram.

Then you could look at the loader to find where the data is loaded and where the program is called.
Then patch the call to the program so that it loops forever.

Again load in 2nd bank. wait for it to finish loading. reset the computer using the switch.
Dump the data from the 2nd bank and convert into files.
Make a loader. job done.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Gryzor

Quote from: arnoldemu on 07:10, 05 April 10
I used another trick for hacking tapes to disc but this only works well for 128k machines and you need a reset switch.


But how are you sure the loader won't overwrite your cloning code?

arnoldemu

Quote from: Gryzor on 08:12, 05 April 10
But how are you sure the loader won't overwrite your cloning code?
The code copies the lower and upper jumpblocks and firmware data.

So that it is almost like having a virtual machine in the 2nd 64k.

But the good thing about the 2nd 64k is that it is not cleared by basic.

If you reset the computer using a reset switch the data remains good.

If you turn the computer off then the data will be corrupted because there will not be power to refresh it.

The reason that some loaders will reset the computer is that they change the memory configuration.
So you can get the state of the memory at that point (when it changes memory configuration it then starts to execute code in the first 64k).

But you are also free to wait until a time of your choosing and press the reset button.

This is how I hacked a lot of games from tape to disc.

The main program was often converted in this way. But of course you have to look at the loader to work out the memory range it actually loads. So that you can save the correct size of data. Also you have to join the bits of memory together because you access the extra ram in 16k pages.

Once the main program had been converted I looked through it to find the level loader code.
Then I wrote another program which called this, loaded each block and then saved this to disc.
When that was done, the main program had to be patched to load the files in.

Often there wasn't enough room to enable the firmware so you have to copy the data in the firmware area into the screen, enable firmware, load files, turn off firmware and copy the data back.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

OCT

Quote from: arnoldemu on 07:10, 05 April 10
I used another trick for hacking tapes to disc but this only works well for 128k machines and you need a reset switch.

You setup the 2nd 64k ram to be a mirror of the 1st.
You switch to it and load the game.
Many times the loader will run and the computer will effectively reset, but the loader is now decoded in the 2nd bank of ram.
Quote from: arnoldemu on 08:31, 05 April 10
The code copies the lower and upper jumpblocks and firmware data.

So that it is almost like having a virtual machine in the 2nd 64k.
I understand you use a program to copy over the RAM to the second bank.
There's yet another trick that involves a little hardware hack, which has the advantage of being undetectable by software:
On a 6128, you use a toggle switch to exchange the two bank-select lines, plus a button to ground READY (a.k.a. /WAIT) on the Expansion Port.
Once the loading and decoding is done, hit the button to temporarily freeze the Z80 in its tracks, switch the memory banks and then release the freeze button. If the machine won't already reset on its own, hit the reset button (conveniently also located on the expansion port, as in my "CPC Brake" which also featured slow-motion. There you are in the other bank, ready to switch in and save the 4*16k pages via the usual MEMORY &3FFF:OUT &7F00,&C4 etc. (leaving you just the task of figuring out the jump point and maybe writing a loader to run on 64k machines as well).

arnoldemu

Quote from: OCT on 13:40, 05 April 10
I understand you use a program to copy over the RAM to the second bank.
There's yet another trick that involves a little hardware hack, which has the advantage of being undetectable by software:
On a 6128, you use a toggle switch to exchange the two bank-select lines, plus a button to ground READY (a.k.a. /WAIT) on the Expansion Port.
Once the loading and decoding is done, hit the button to temporarily freeze the Z80 in its tracks, switch the memory banks and then release the freeze button. If the machine won't already reset on its own, hit the reset button (conveniently also located on the expansion port, as in my "CPC Brake" which also featured slow-motion. There you are in the other bank, ready to switch in and save the 4*16k pages via the usual MEMORY &3FFF:OUT &7F00,&C4 etc. (leaving you just the task of figuring out the jump point and maybe writing a loader to run on 64k machines as well).
Nice.

I never thought to use hardware to help.

Is this info on the wiki? because it would be useful to have it there.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

OCT

Quote from: arnoldemu on 17:14, 05 April 10Nice.

I never thought to use hardware to help.

Is this info on the wiki? because it would be useful to have it there.
To the best of my knowledge, the bank exchanger was first contrived (and instructions with a photo -which I have dug up again indeed- sold for a nominal fee) by a German scener changing his pseudo from Khany to Cherry-T in 1993.

Since copyright subsists in these materials as a matter of law, I cannot republish them, but I hope that someone is still in contact with the original author (not a member of this site nor CPC-Forum.de under any of the above user names I'm afraid) to obtain the required permission.

What I may say at this time is that it works by unsoldering the right-hand pins of R160 and R161 and connecting them via pull-ups to the nearest source of +5V which happens to be the top leftmost pin of IC207, and wiring a double-pole double-throw toggle switch to exchange the bank-select lines.

While I wouldn't know how to best place new articles on each in http://www.cpcwiki.eu/index.php/Peripherals, I attach an image showing the "CPC Brake" a.k.a. "CPC Slow Motion", switchable between slowdown and stop for both the "Centronics type" (Plus and German 6128, left, with a slide switch) and "PCB/card type" connectors  (continental 464/664 and UK CPCs except Plus, right on Multiface II, with a jumper), which conveniently feature both the brake/stop (car-like foot pedal) and reset buttons.
The banks are of course exchanged by one of the toggles to the right of the hood (which BTW features the era's Amstrad commercial sticker "computers for people with brains" - as we have always known :)).

redbox

These methods are really cool and it's nice to see how people did it.

One of the (simple) methods I used was if there was a poke for the game (like in 'Cheat Mode' in Amstrad Action) then I knew this had to break the game's copy protection to work.  Therefore I would disassemble the cheat and use it to transfer the game to disc.

Nowhere near as neat as the above, but it worked for me for a few games  ;)

Cholo

Nice, didnt know there was so many ways, to get past a tape protection.

Didnt even get the idea to look at tape pokes as a way to look at the protections, lol. Even tho later on i did look at some pokes to find the right spot to poke games in a emulator.

gef

Quote from: Cholo on 20:48, 04 April 10
Thanks for posting. This pretty much answers one of my oldest still lasting questions:
1. how did people hack those tape protections before the multifaces showed up and
2. how did the programmers compile a protection like that.
[...]

I can answer #2 quite well for the cases I have encountered:
a) Some trivial cases were (XOR) code transformation trickery, _without_ using R register.
b) The most commonly found titles had one or two invocations of loops using the R register.
c) The titles that were bound to become commercial success would use some annoying tricks:
    c1. using features of the magnetic media, that were characteristic of that particular game
      c2. multiple nested XOR-decoding loops using R register in a back-to-back fashion

a) and b) would fall easily with some mild application of Pyradev, time and patience.

category c) was a different story altogether, since they required fairly good understanding
of many aspects of the system and fiddling with the game in non-trivial ways. examples:

c1. double dragon was becoming very annoying on our cpc6128, since it would force
     disk drive to make worrysome noises and would not always actually start. Eventual
     reverse engineering on both soft-n-hard fronts, forced me to learn the ins and outs
     of NEC765 floppy disk driver (which was a big deal to occupy a single chip back then),
     write a sector reader for it *from scratch* (aka device driver nowdays), understand
     the mechanical properties of my drive and that track #42 was not really available
     until the moment I unscrewed and adjusted a physical limiter inside that drive...
     there were also some other disk tricks with oddly formatted sectors etc and I guess
      tape protections were of similar style with timing-sensitive write/read operations.

c2. OK this was a category on its own. The amount of work involved here was non-trivial.
      Even if you mastered Pyradev and assembly very well, it was not easy at all to push
      breakpoints at interesting code points at will, because that would imply mangling the
      R register which was part of the decoding-soft-logic itself. If the number of loops was
      small (say, <5) with stepwise patience and craft the game could fall. The problem here
      was though that the guys protected the game had time with their side, since they could
      easily automate the creation of multiple nested tough-to-break R-based XOR loops.
      R was difficult because it increased by 1 or 2 with each and every processor operation!
      So, if you run Pyradev or another monitor in between, your breakpoint would ruin it all.
      The antidote to this technique was to patch Pyradev in the way described earlier;
      I think the first game that eventually got hacked like this was quite more >20 loops,
      so there's no easy way someone could circumvent it by manual code-relocation tricks...

      ...or use the trick with bank-shifting, which I didn't know and was ingenious indeed!
 
For the record: when I was doing all these operations I was maximum 14 y.o.
(and my feeling since then is, that I just decline over time! LOL)
  so next time you see a teenager busy with some weird computer problem,
better not underestimate the crap with which he might be fiddling with ;-)

enjoy,
F.

arnoldemu

Quote from: gef on 01:56, 06 April 10
I can answer #2 quite well for the cases I have encountered:
a) Some trivial cases were (XOR) code transformation trickery, _without_ using R register.
b) The most commonly found titles had one or two invocations of loops using the R register.
c) The titles that were bound to become commercial success would use some annoying tricks:
    c1. using features of the magnetic media, that were characteristic of that particular game
      c2. multiple nested XOR-decoding loops using R register in a back-to-back fashion
Yes indeed.
Speedlock protection had about 80 of these XOR type loops. Then it tried to detect the multiface. It was a beast of a protection and always changing.

I too was about 13/14 when I was converting tapes to discs. I did this mostly because the disc games were so expensive.

I initially started learning assembler and I was very lucky because I got a SOFT968 manual and my father could obtain the chip datasheets easily from his company library.

I never tried using Pyradev. First I used the very poor Amsoft assembler (MONA etc). With it's terrible input and line numbers. Then I moved onto Maxam (I had a strange chip on a PCB which connected to the back of the computer. I've not seen another since and I've since sold this.)
I never really found a debugger that I could get on with on the CPC.

It is interesting to read how others hacked and looked at code.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Gryzor

Quote from: OCT on 20:11, 05 April 10
Since copyright subsists in these materials as a matter of law, I cannot republish them,

Copyright issues? What are you talking about? I can publish it if you want, I don't think we should be exactly scared someone will come after us for hacking (again) a game from 1985...

OCT

Quote from: arnoldemu on 08:31, 05 April 10
The code copies the lower and upper jumpblocks and firmware data.

So that it is almost like having a virtual machine in the 2nd 64k.
I wonder what the code was that allowed you to page in the whole 4*16k of second-bank memory without hardware help.
AFAIK the OUT &7F00,&C4+page would only show 16k at a time at &4000 to &7FFF, which is an uncommon location for loaders.

OCT

#17
Quote from: Gryzor on 07:54, 06 April 10
Copyright issues? What are you talking about? I can publish it if you want, I don't think we should be exactly scared someone will come after us for hacking (again) a game from 1985...
I'm not into cracking protections at all, nor scared for that matter - it's just that the author and photographer of a (really nice BTW) writeup on the CPC6128 hardware modification does hold rights to it (and one day even his heirs will, for 70 years post mortem auctoris in most jurisdictions), just like the Heise publishers do for the other piece which first showed how to tamper with bank selection and expand the internal memory, "Aus David wird Goliath: 512 KB RAM für Schneider CPC", c't 10/1987, 156-162, as referenced in http://www.cpcwiki.eu/index.php/C't_512_KB_internal_RAM_expansion and much later picked up again/reinvented for up to 4MB by Yarek.

As for the games themselves, in rare cases there is some commercial interest indeed (in particular in the level maps, audio and artwork) whenever something like the http://en.wikipedia.org/wiki/C64_Direct-to-TV or a port to a mobile phone comes up, but (as for out-of-print books/records) most of the time waiting for infringements (rather than distribution) is the only viable option to still extract money out of these "ancient" rights - so there are firms specialized in monitoring these and sending out nastygrams (with bills attached, or bringing suits right away where they can't) when they occur.
Interestingly in the earliest decisions on video games, courts did have their doubts whether the excessive duration afforded to literary and musical works provided an adequate regime for the short-lived IT products (as we know now it only makes hobbyists' conservation efforts a target indeed), but the political consensus has been to keep applying it (and extend various aspects of overprotection ever since).

arnoldemu

Quote from: OCT on 08:28, 06 April 10
I wonder what the code was that allowed you to page in the whole 4*16k of second-bank memory without hardware help.
AFAIK the OUT &7F00,&C4+page would only show 16k at a time at &4000 to &7FFF, which is an uncommon location for loaders.

10 addr=&c000
20 READ a$:IF a$="*" then call &c000 elsepoke addr,val("&"+a$):addr=addr+1:goto 20
30 data 01,c4,7f,ed,49,21,00,00,11,00,40,01,00,40,ed,b0,01,c6,7f,ed,49,21,00,80,11,00,40,01,00,40,ed,b0,01,c0,7f,ed,49,c9,*


Asm code:

ld bc,&7fc4
out (c),c
ld hl,0
ld de,&4000
ld bc,&4000
ldir
ld bc,&7fc6
out (c),c
ld hl,&8000
ld de,&4000
ld bc,&4000
ldir
ld bc,&7fc0
out (c),c
ret


Run the basic program then type:
OUT &7F00,&C2

now press return a few times and the screen scrolls, you can type basic commands but you can't see results (because video hardware is reading from first 64k).

So now the z80 is executing code entirely from 2nd 64k bank ;)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

OCT

#19
Quote from: arnoldemu on 08:55, 06 April 10type:
OUT &7F00,&C2

[...] now the z80 is executing code entirely from 2nd 64k bank
OIC, thanks, I hadn't realized this could be done in software for an entire 64k bank (the hardware switch still has the advantage of being able to see the video and toggle to another bank to work from at a moment of one's choice, of course - and immune to loaders sending C0 just to prevent such tricks being played on them :)).
Apparently the use of the 2 least significant bits had been documented, albeit in French:
http://cpcrulez.fr/coding_asm34b.htm (not entirely clear about the use for C2 yet, though)
http://quasar.cpcscene.com/doku.php?id=assem:gate_array#le_schema_general_du_gate_array (bottom right)

Gryzor

Quote from: OCT on 08:52, 06 April 10
I'm not into cracking protections at all, nor scared for that matter - it's just that the author and photographer of a (really nice BTW) writeup on the CPC6128 hardware modification does hold rights to it

Hahaha! Thanks - copyright issues are a very dear subject for me, but it never does harm discussing it :)

What I meant was, I thought you mentioned copyright because if the hardware's uses, not of the schematics' copyright itself... But even so, it does sound a bit far-fetched. Personally, I wouldn't have an issue with publishing it - but of course, if the owner objected I'd withdraw it at once... but what are the chances, really???

villain

I was in regular contact with Khany/Cherry-T back in the 90s. But I don´t remember his real name in case anybody wants to contact him... Maybe he published his bank exchanger in the paperfanz Rundschlag. So if someone could take a look through the issues... I can´t to this because my collection is still stored at the home of my parents.

OCT

#22
While all I have available here is  a Linux machine, I dug up a disk from 1993 on which -besides his real name- he does give permission for unaltered distribution of his article in German and sketches (RUN"#HI), which I converted using dskdump -itype floppy -otype dsk -iside 0 -idstep /dev/fd0 BankSwap.dsk (libdsk-1.3.0) and successfully tested against http://java.cpc-live.com/jemu/JavaCPC.jnlp (not sure which compression would be universally accepted, or how I should link it to launch in a JavaCPC right away).

HTH... :)

gef

#23
Quote from: arnoldemu on 07:19, 06 April 10
Yes indeed.
Speedlock protection had about 80 of these XOR type loops. Then it tried to detect the multiface. It was a beast of a protection and always changing.

I too was about 13/14, when I was converting tapes to discs. I did this mostly because the disc games were so expensive.

So, Speedlock was the name of it, hm? Nice to know after all this time. :-)

I don't know if the number of loops was close to 80, but it could easily be,
since I remember I got bored trying loop after loop; I kept pressing forward,
mostly as a matter of testing the functionality of the patch on Pyradev!

btw.
A good motive for spending time on doing all this reverse engineering, was indeed cost issues:
The teenager budget of me and my brother was easily overwhelmed by the cost of floppy disks
at that time, and protected games tended to occupy a complete 180KB side of a 3" disk. Insulting!
The "Live and let die" I think was the first to get factorized in files & a small nice custom bootloader
and the size of it became 1/6th of what it was before, a testament to its programmers' efficiency!

Some other times it was just a matter of being efficient, eg. Discology's sector editor was
a mere 22KBs (why do I still remember these numbers??? ;-), and was handy to move around,
so that it was not necessary to swap floppies in and out, a heavy tax time-wise, while hacking.
(along with the regularly needed reboot which needed a mere handful of seconds)

Quote from: arnoldemu on 07:19, 06 April 10
I never tried using Pyradev. First I used the very poor Amsoft assembler (MONA etc). With it's terrible input and line numbers. Then I moved onto Maxam (I had a strange chip on a PCB which connected to the back of the computer. I've not seen another since and I've since sold this.)
I never really found a debugger that I could get on with on the CPC.

Pyradev suite was -and probably still is!- the best name in the field.
People in this emulator forum, should at least be able to call it by name :) ,
so that in case of funny emulation interactions they can resort to it for testing.
I recommend you check for its "monitor" screenshot to get an idea.

With its help, It was possible to disassemble and understand good parts of the BASIC ROM
of the cpc6128 and even load basic programs in memory at will, many of them at once,
calling them *from* assembly code and in effect using them as subroutines.
This can be quite important at moments, because that was the only substitute available
for a high level language... assembly is good, but you need tools around it.

Also, for any people around here studying Computer Science and such, I highly recommend
to disassemble/study the routines on mathematical operations (sqrt, sin, cos ...) of the lower ROM.
That was very educating stuff, involving both theoretical and practical aspects (eg. premade matrices).

> It is interesting to read how others hacked and looked at code.

Indeed. We urge others to step forward and let be known what they were doing at the time!
There were so many games hacked, that there must be dozens of tricks like the above!
If you have references to such discussions/articles, please provide them.

cheers,
F.

Cholo

Was looking thru some AA mags and happened to notice that no. 24 & no. 25 actually had something about hacking on the "Hackers only" (usually this page had very little with actually hacking i recall  ;D ..  usually was just some random machine code math).

No. 24 about Xor and such:
http://img64.imageshack.us/img64/1589/aa24p33.jpg

No. 25 about the bank switching:
http://img189.imageshack.us/img189/8905/aa25p29.jpg

Never would have guessed any of that (especially the bank switching, cant recall any book speaking of it at all).

Ah yes, disc space. Had a friend back then who had a 6128 and during the perhaps 5-6 years he had the 6128 he managed to get about 15-17 "empty" discs in all. As a kid those discs was way to expensive, so had to squeezing ever byte. Cant complain about speed of cause, but i still wonder if the amstrad had had 5.25" drives like C64, then i may have been even more popular (at least kids friendly).

Powered by SMFPacks Menu Editor Mod