 Previous Messages |
Posted By
Waz
on 2020-07-22
11:32:23
|  Re: Reset switch disabling
@Luca - thanks for reminding me of the Gremlin titles. Think it was mainly the Jason Perkins coded ones if I recall (a fair few of them as well that he did) - think when I first had the Plus/4 back in 1985 Xargon Wars was one that may have done it, that or Petals of Doom.
|
|
Posted By
Gaia
on 2020-07-22
10:34:53
| Re: Reset switch disabling
@Luca: I lost it  that was my last crack on the plus/4... would be good to recover it somehow... keep an open eye 
|
|
Posted By
Luca
on 2020-07-22
07:57:12
 | Re: Reset switch disabling
Gaia heeeey where is that crack, why we don't have it yet here? 
|
|
Posted By
Gaia
on 2020-07-22
07:50:57
| Re: Reset switch disabling
@gerliczer: obviously there is a little work to do, but the point was that it's possible.
@siz: thanks for the todo list  that's exactly how it should be done. Key is the RAM area around $0473,$0479 etc. which is used by the ROM routines to page in and out the RAM.
I recall I experimented with this back in the day (~1989), mainly to bypass copy protections IIRC. I am not so sure anymore but I believe this was how I cracked Démonok birodalma which had a very tough copy protection.
|
|
Posted By
siz
on 2020-07-22
04:29:56
| Re: Reset switch disabling
It will. Back in the day I did this (I can't remember why). The steps required:
- copy BASIC and KERNAL ROMs to RAM
- change all $ff3e writes in the copied version to $ff3f writes
- change RAM size detection to always detect 32k
- switch off ROM
- reset
It worked like a charm and you could change "ROM" code realtime.
edit: changing $ff3e writes and resetting will recopy all RAM access routines to their proper location thus they will not re-enable ROMs. And this is (of course?) reset proof.
edit2: and if you want to copy protect you BASIC program you should change RESET vector to some of your own - perhaps somewhere in BASIC interpreter. But that could be really hard to catch the proper entry point. Most probably I would do some initialization (that KERNAL does by itself) and then jump to the entry point of RUN command.
|
|
Posted By
gerliczer
on 2020-07-21
15:44:08
| Re: Reset switch disabling
@Gaia: You forgot to mention that some system variables must be changed, too. And, obviously, this will halve the available memory. OTOH, will it really work? Could it be that some common routines like variable accesses will page in the ROM after they finished their jobs?
|
|
Posted By
Gaia
on 2020-07-21
14:15:31
| Re: Reset switch disabling
It can work in BASIC, too, if you copy the entire ROM into the underlying RAM area, disable the ROM as gerlicze suggested and then change the reset vector.
|
|
Posted By
Luca
on 2020-07-21
10:49:23
| Re: Reset switch disabling
Waz manipulating the reset vector was quite common in the commercial games era, for example almost all the C16 library of Gremlin Graphics appeared to be somewhat "protected" against reset
|
|
Posted By
gerliczer
on 2020-07-21
08:31:36
| Re: Reset switch disabling
Doesn't make much sense to do that. People wanting to dissect the program will get in anyway.
|
|
Posted By
Waz
on 2020-07-21
06:12:21
| Re: Reset switch disabling
Thank you for that explanation, good to know potentially what could have been done.
It did make me wonder why more programmers didn't take advantage of that and potentially stop the reset when playing a game, to make it less susceptible to cheat POKEs etc. Unless they were using the reset during development to use the inbuilt monitor for coding, and didn't want to break access?
Apart from the two games mentioned, does anyone know of other games where reset was disabled?
|
|
Posted By
gerliczer
on 2020-07-21
05:28:27
| Re: Reset switch disabling
AFAIK no, no modification of any KERNAL vector will help. To do this, you have to reroute the CPU reset vector at memory locations $FFFC-$FFFD. For that to work you have to page away ROM. Therefore it won't work for BASIC.
|
|
Posted By
Waz
on 2020-07-21
03:57:08
| Reset switch disabling
I was playing the Plus/4 only version of Saboteur on original hardware yesterday, and apart from noting how similar it played to the C64 version, and that the title music is the same as the Spectrum version, I noted something else.
If you attempt to use the onboard reset switch, you find that you can't do so, and it instead resets back to the game's title screen - pretty neat all round to stop anyone potentially hacking their way through parts of the code. (I'll aim to create a listing POKE for infinite lives and time at some point for those who own the original hardware - those of you who know will know I did that a lot on theC64)
I think Finders Keepers was possibly another one where similar methods were performed.
From a programming perspective, were they altering the Kernel jump routines for when the reset switch were pressed, and relocating back to their own code? It'd be nice to have similar if say I was creating a BASIC program and wanted to prevent such actions from being taken.
|
|
