| |
6R6
Registered: Feb 2002
Posts: 245 |
Disabling AR freeze button
Is it possible to disable the Action
Replay freeze function 100% ?
In that case, please enlighten me... :)
|
|
| |
yago
Registered: May 2002
Posts: 333 |
The Action Replay (and almost any other Freezer) works via IRQ or NMI, then the AR-ROM is switched in.
If you disable all IRQs (e.g. SEI), and disable all NMIs (forcing a NMI and never acknowledging it), the freezer button should not work anymore.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats true.... however it can be pain in the ass to write a non trivial program with both nmi and irq disabled ... :=P |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Freezers don't use IRQs, or they wouldn't be able to freeze anything with an SEI in it. Final Cartridge and Action Replay trigger an NMI together with a kernal replacement.
|
| |
6R6
Registered: Feb 2002
Posts: 245 |
It has come to my knowledge that it is possible by
setting the Ultimax mode for zeropage $01.
I havent tested it yet, ehm..
I'll let you know....
|
| |
chancer
Registered: Apr 2003
Posts: 347 |
I have a few things which have AR freeze stopping.. an intro someone coded in TA. years ago.. it only works after the button has been pressed and u try to do a restart
i can dig out the code if ya that interested.
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
I noticed a number of NMI routines mess with it bad. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
anything based on cia timers that is not resynced to the rasterbeam each frame will fuck up after freeze+restart. check mathematica 4x4 parts for example, or any other demo with timer-based raster-routines. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
ar also freezes with irq+nmi disabled, it only fails if you enable the ultimax mode. then, however, your code must run from $0000-$0fff. quite a pain in the ass to code ;) |
| |
Style
Registered: Jun 2004
Posts: 498 |
Sorry to zombify this old thread, but here's something I dont understand:
You cant stop an action replay from driving the NMI line low, because it itself drives it high by default.. this is from my (albeit limited) understanding.
Question is, why doesnt having an AR cart plugged in mean that it becomes impossible to disable the restore key with the "avoid acknowledging an NMI" trick? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i'd also like krill to explain how ar would freeze with nmi and irq disabled, because i cant see that working ... |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
Why would you want to disable the freeze button on a cartridge. In this modern 64 day, free of 'group spies', rival sabotage and coders secrecy, would we not want everyone to have the ability to study our work? Our demos, games and Pal/NTSC fixes? Any future fixes I do will have text embedded in the $2a6 checker and template, as a flag to welcome people to pick apart my fixes and learn something new. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: i'd also like krill to explain how ar would freeze with nmi and irq disabled, because i cant see that working ...
Im pretty sure the cart itself drives the NMI line high itself..... Remember, the reason you can disable NMIs is by not acknowledging an NMI, therefore leaving the NMI line low. From what I can tell from the circuit diagram, the AR itself itself drives the NMI line high with a 74LS74 (from memory).
I dont have a problem with this. However, wouldnt this make it impossible to disable the restore key as well?
Or perhaps the AR only drives the NMI line high when you press the button, and then a short while later grounds it again? If thats the case, I cant see it in the circuit.....
|
| |
Mace
Registered: May 2002
Posts: 1799 |
If it was possible to disable such a cartridge feature, wouldn't that have been one of the better piracy protections? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
not really, it only works if you disable IRQ _and_ NMI (cause then there is no way for the AR to kick in).
a much easier way is however, to sync a timer to the raster, and every now and then check if the timer is still in sync.... if it isnt, then the program has been frozen (and restarted). and this has indeed been done in some games :) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quoting The ShadowWhy would you want to disable the freeze button on a cartridge. In this modern 64 day, [...]
Curiosity; "can it be done, if so, how"? To give other people something to put their head against? Just for the hell of it? |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: not really, it only works if you disable IRQ _and_ NMI (cause then there is no way for the AR to kick in).
a much easier way is however, to sync a timer to the raster, and every now and then check if the timer is still in sync.... if it isnt, then the program has been frozen (and restarted). and this has indeed been done in some games :)
Have you tested your theory groep? ie, disable NMI and IRQ and try to freeze the program?
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
actually, no...but since what the freeze button does is causing an NMI, i dont feel like doing it either, its obvious =) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I remember some compo-pic which (by accident, it seemed) jammed the machine after making sure the gfx was visible. Another way to do it perhaps. :) |
| |
Style
Registered: Jun 2004
Posts: 498 |
Are you really really sure its that obvious groep?
:D
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes, how do you think freeze works? |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Stopping the NMI will stop most freezers from working. Unless the freezer is actually watching the data and address bus and is able to dump the whole of memory. To restore all the freezer needs to do is dump out touched memory, restore CIA, VIC, SID state (it's possible to read the SID for protection purposes for example) and then start the CPU. Such hardware based freezers that watch the internal buses are practically impossible to stop. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Somebody write a short article on the mechanisms of common c64 freezers and put up on http://codebase64.org :) |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
On original hardware you can actually crash system with well know de00 read bug. However in case of Retro Replay you can use it's extended register de01 bit 2 to disable freeze button. Remember that this is write-once register so next write to it will succeed only after system restart.
The following code will hang the system with RR and disable freeze button (however reset button will still work due to obvious reasons):
SEI
LDA #$04
STA $DE01
CLI
RTS
So in case of RR it is possible to disable Freeze button in 100% until next reset.
As a side note: Actually disabling NMI can cause interesting effects on some carts. For example Expert when is on will break on code that mask NMI (due to trigger). Disabling NMI will cause ESM led to be lit and need for ESM button to be pressed to re-enable NMI again (ESM button in connected to NMI line). You can't observe this behavior in Vice. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Doesn't RR ROM write $de01 during boot?
(I use the freeze button for disk swapping in MMC64 disk image mounter, that works because RR ROM doesn't get run before the plugin.) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Somebody write a short article on the mechanisms of common c64 freezers and put up on http://codebase64.org :)
I second that. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: I second that.
I'll have a short write up on different bugs and features not mentioned in codebase. I'll try to clean it up during weekend and post it here for review first. I need to recheck $de01 access by different roms too. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
great! |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Doesn't RR ROM write $de01 during boot?
(I use the freeze button for disk swapping in MMC64 disk image mounter, that works because RR ROM doesn't get run before the plugin.)
You are right. I've took a peek at 3.8 and at $817F there is the following code:
LDA #$40
STA $DE01
which enables REU comaptybility and Freeze button as well. So my code will not work if run after RR setup however it stills hangs the system so one can say it is disabling freeze option ;) |
| |
titan_ae
Account closed
Registered: Jun 2002
Posts: 46 |
best "protection" against freezing i saw in an german adventure game called "mit jeans und hellebarde" from markt und technik verlag.it checked he exp. port, if something was conected there, game didnt start and ofcourse freeze button didnt werk.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
uhm but...both FC3 and AR5 can switch off themselves completely (and will be switched on again when you press freeze) so its pretty much impossible to detect them programatically. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: uhm but...both FC3 and AR5 can switch off themselves completely (and will be switched on again when you press freeze) so its pretty much impossible to detect them programatically.
Most of those methods will also fail against Trilogic Expert. It can also be switched to off and than re-enabled after PC register passes protection code. In some games you will also lack time in IRQ to recheck again.
Some older version - if memory serves me well - of AR were leaving certain values on stack during freeze.
In case of AR you can also enable it's memory and store your code there which will get overwritten due to freeze.
IMHO the best option is to use VIC, SID and timer registers to detect freeze has been triggered. Also synchronization issues can screw up code execution so that return after freeze will not be possible. Those methods are also very flexible as they work against different carts not just AR.
You can also play with disk drive memory in order to detect any writes (but today it's real use is rather limited unless you are afraid of piracy).
|
| |
sailor
Registered: Jan 2002
Posts: 90 |
Hello.
Started a topic about cart-detection for some time ago, there was some mention about freeze-detection too. If anyone is interrested, check this one: How to detect a cartridge..?
Regards:
Jani
|
| |
Necronomfive
Account closed
Registered: Dec 2004
Posts: 20 |
It's impossible to detect a AR/RR Cartridge once the freezer software has disabled it. The only way to prevent freezing is fire an NMI and not acknowledging it. On RR/MMC Replay, nothing will happen in this case when the Freeze button is pushed. On AR, I am pretty sure that the system will be fucked up once freeze is pressed, because the cartridge will map in Ultimax mode without the CPU jumping to the NMI vectors. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@AlexC: Looking forward to that codebase article! ;) |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Ok, here it is - please post your comments as it still needs a lot of work to be finished.
0. Versions used
Vice 1.22
C64C Pal
Action Replay MK VI
1. Detecting cartridges
Most cartridges (including RR if active) can be detected by writing to range DE00-DEFF and checking if value written there will be persistent. This allows to detect: Action Replay MK VI, Final Cartridge III and Retro Replay. This method will fail against Trilogic Expert.
start: lda $de10
ldx #$0a
ldy #$00
compare:
cmp $de10
bne nocart
delay: dey
bne delay
dex
bne compare
cartfound:
jsr print
rts
nocart: rts
1.1 FCIII
FCIII can also be detected by analyzing system vectors starting from $0302:
$0302 = $DE41
$0304 = $DF8D
$0306 = $DE49
$0308 = $DE73
$030a = $DE4F
$0330 = $DE21 (LOAD)
$0332 = $DE35 (SAVE)
Following code can be use to detect FCIII vectors:
lda #$de
cmp $0303
beq crtfound
rts
crtfound: jsr $fce2
The following code will restart system into clean basic FCIII extensions will not be available until freeze, however cartridge led will be lit.
Another methods to detect FCIII can be based on its control register: $DFFF.
Bit 0: number of bank to show at $8000 ($3)
Bit 1: unused
Bit 2: unused
Bit 4-5: 00 turn all 16kb of ROM
01 start freezer
10 enable first 8kb of ROM
11 disable FCIII ROM
Bit 6: unused
Bit 7: 1 (always show 16kb of bank 0)
FCIII has following banks:
0 BASIC, Monitor
1 Notepad, BASIC (Bar)
2 Desktop, Freezer/Print
3 Freezer
To jump into freezer you can use following code:
lda #$9f
sta $dfff
The above code works however only in Vice on real C64 (at least on my original copy of FCIII this enters freezer and hangs system). [this needs further research]
Using #$B3 value instead will give you interesting result on real C64 and will jam CPU if you are using Vice.
How to use FCIII control register for detection? Simple: you can read from it, however it will not return the value that has been written to it. Instead in case of default system start it will always return #$FF. This leads us to following code:
10 for i = 1 to 10: print peek(57343):next
Both on real C64 and Vice in case of FCIII you will get ten $FF results. This allows to detect cart even if kill command has been used. If you disconnect the cartridge you will get different results: at least two 0 values from above basic test (other values than 0 and FF are possible too!). Check it out yourself!
$DFFF read value can differ if any writes has been done to it besides normal system start (using BASIC option from System menu).[this needs further research]
Another detection method is based on the fact that 512 bytes of FCIII ROM cant be turned off this code is always there at $DE00-DFFF. At $DE01 you will find following code:
DE01 8D FF DF STA $DFFF
DE04 60 RTS
So to detect FCIII you can check if those bytes are there. If not FCIII is not connected to the system.
1.2 Action Replay
Original Action Replay on real C64 will crash system if its control register at $DE00 is being read. Check the following code:
start: ldy #$0a
lda $de00
dey
bne start
rts
Actually one read is enough to crash system in case of all AR and its clones I have.
Ever tough INC $D020 can be dangerous for AR? I must be kidding right? Than check the following code on real C64:
$9000 nop
$9001 inc $d020
$9004 jmp $9000
Now try to freeze it few time. You will quickly find out that usually either the PC value is incorrect or after restarting you will hit BRK and enter monitor again.
As stated above AR has control resister at $DE00. Here is a list of possible values you can write to it:
$00 enable bank 0
$06 disable cart and I/O area for it
$08 enable bank 1
$0A disable cart
$10 enable bank 2
$18 enable bank 3
$20 enable RAM at $8000 - $9FFF write to C64 memory underneath is enabled
$23 enable RAM at $8000 - $9FFF write to C64 memory underneath is disabled
Writing $23 to $DE00 will result in jump to the freezer if PC is above $0FFF.
Here is the meaning of bits:
Bit 0: Game low (=1)
Bit 1: Exrom high (=1)
Bit 2: disable cart (=1) turns off $de00 register
Bit 3: Rom bank selector low
Bit 4: Rom bank selector high
Bit 5: enable ram at $8000 and I/O
Bit 6: resets freeze mode
Bit 7: unused
1.3 Retro Replay
Detection unless ZAP command has been used is quite easy: use the code from section 1.
You can use following routine to jump into main menu (works with AR too):
sei
lda #$00
sta $de00
jmp $fce2
You can disable it (works with AR too) by following code:
sei
lda #$14
sta $de00
jsr $e453
cli
rts
Please note that this will not affect freeze button.
RR has in fact 2 control registers (from official RR manual): $DE00 and $DE01. There is theoretically possibility of disabling freeze button due to bit 2 of DE01. Bit 2 has NoFreeze name and can disable freeze button if set to 1 but can be written only once. RR 3.8 set it to 0 (enables freeze) at $817F.
Consult RR manual for further Information: http://rr.c64.org/rr_manual.html#appb
1.3.2 Freeze vs breakpoint
If you ever wondered about differences between freezepoints and breakpoint here it is: breakpoint will work only if vector at $FFFE and $0316 has not been changed (it uses BRK). Freezepoint is using however JSR $DFD3. [this needs further explenation]
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: ar also freezes with irq+nmi disabled, it only fails if you enable the ultimax mode. then, however, your code must run from $0000-$0fff. quite a pain in the ass to code ;)
According to my experiments this is not entarly true. Take a look at following example (KickAssembler):
.pc = $1000
start: sei
lda #$35
sta $01
jsr disirq
jsr disnmi
loop: jmp *
disirq: lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dc0d
//disable screen
sta $d011
ora %00010000
sta $d011
//read VIC IIR
lda $d019
//no irq's from vic
lda #$00
sta $d01a
//setup own handler
ldx #<irq
ldy #>irq
stx $fffe
sty $ffff
rts
disnmi: lda #$00
sta $dd0e
sta $dd04
sta $dd05
lda #$81
sta $dd0d
lda #$01
sta $dd0e
//setup own handler
ldx #<nmi
ldy #>nmi
stx $fffa
sty $fffb
rts
irq: rti
nmi: rti
Run it with sys 4096 and try to use freeze RR or AR button. The interesting part is that Expert has no problems with it - actually this code will enter Expert monitor during execution. If you have Expert you can test ESM led by setting cart into OFF position and running this code. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
Ever tough INC $D020 can be dangerous for AR? I must be kidding right? Than check the following code on real C64:
$9000 nop
$9001 inc $d020
$9004 jmp $9000
Now try to freeze it few time. You will quickly find out that usually either the PC value is incorrect or after restarting you will hit BRK and enter monitor again.
did you actually check this on a real c64? never forget, the freezer stuff in vice is BROKEN. atleast with emulated AR or RR, repeatedly freezing and restarting _anything_ will fail (and it works just fine on the real thing). |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Quote:
Ever tough INC $D020 can be dangerous for AR? I must be kidding right? Than check the following code on real C64:
$9000 nop
$9001 inc $d020
$9004 jmp $9000
Now try to freeze it few time. You will quickly find out that usually either the PC value is incorrect or after restarting you will hit BRK and enter monitor again.
did you actually check this on a real c64? never forget, the freezer stuff in vice is BROKEN. atleast with emulated AR or RR, repeatedly freezing and restarting _anything_ will fail (and it works just fine on the real thing).
According to my tests it works only on real C64. Could not reproduce the same effect on Vice even after switching to different AR ROMS.
Also please note the first line of quote - "on real c64" ;)
Speaking about broken freezer it also applies to Expert (at least NMI's are not emulated properly on hardware level). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:
at least NMI's are not emulated properly on hardware level
yeah, NMI seems to be generally broken... i played around with some other stuff a while ago which used restore as a "panik" button, and on vice it would trigger the nmi only once (but on real c64 it worked like it should). |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Yes in VICE the NMI can only trigger once, which is a bug :) It also seems to always trigger from the restore key near the top of the screen raster. Unless it is triggered by a timer of course.
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Yes in VICE the NMI can only trigger once, which is a bug :) It also seems to always trigger from the restore key near the top of the screen raster. Unless it is triggered by a timer of course.
That's interesting - I've never done much research on Vice after I've discovered that handling NMI is broken. Thanks for the tip Martin. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
You are very welcome. :) Like most things it was discovered by accident. I was testing my screen split and noticed the border colour change would trigger at the top of the screen raster time (viewable with full debug borders) when holding down the "restore" key. On the real C64 the restore key NMI is triggered on a logic edge, not logic state.
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@AlexC: Thanks for the article! Sorry that I didn't notice that you posted it until now. It is available here:
http://codebase64.org/doku.php?id=base:cartridge_detection |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: @AlexC: Thanks for the article! Sorry that I didn't notice that you posted it until now. It is available here:
http://codebase64.org/doku.php?id=base:cartridge_detection
You're welcome - new version of it is in production ;) I want to add some more things and info about Expert. |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
In dem old days, we used to kill carts by using NMI timer interrups (which never got restarted due to the CART taking over the NMI), and by placing the stack near $100 rather than $1ff.
If you leave just enough space on the stack for your game, and use (say) $1030 onwards, then whtn the stack wraps, it kills your data and a restart is again messed up.
I had to jumpo through hoops and write a little bit of restart code to get some frozen games to work again.
"Some" later carts might have fixed the stack one... but Im not sure. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
For the people who are desperate to defeat carts, I think nowadays the 1541-ultimate is the newest toughest enemy :)
I talked a bit with Gideon about how the freezing works, and it is pretty nifty! ;)
According to Gideon, there are 2 modes, the first mode freezes when the cpu is being stalled due to badlines or sprites, and just keeps the cpu frozen by keeping BA low (or is it high?)
Then it does all its stuff, and when it's ready to let go of the c64 it will wait for a badline/sprite on the same line again and let go. (It immediately occured to me that this might lead to problems f.e. with multiplexers -> the sprite might not be in the same lines! or the badlines may not be there.. etc!)
In the 2nd mode (it will try this if it does not detect badlines) the cart keeps checking the bus for a RWR from the cpu, since then it's sure the next will be a R also, at which point it takes over. (i'm not exactly sure why the cart cannot take control during a write, but according to gideon the bus would become a total mess).
Anyhow, in mode 2, there's no need for IRQs,NMIs or whatnot, so it will be impossible to stop the freeze. The only possibility is to detect the freeze afterwards.. f.e. by checking the position of sprites, or if the screen is still "open" if you have one of those open-border-no-badlines-screens. |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
LOL I did that back in '89! :)
(kind of)
I downloaded a little program to the 1541, and the game "ticked" it several times a frame, then when someone pressed a cart button the comms would stop and the disk would crash. This meant that when the game restarts, the game locks up (or something) as it gets no comms back from the disk.
I wasn't allowed to use it though... :(
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: LOL I did that back in '89! :)
(kind of)
I downloaded a little program to the 1541, and the game "ticked" it several times a frame, then when someone pressed a cart button the comms would stop and the disk would crash. This meant that when the game restarts, the game locks up (or something) as it gets no comms back from the disk.
I wasn't allowed to use it though... :(
but 1541u freezes the drive aswell ;)
Only thing it can't freeze is the Vic-II, SID and CIA. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Nice revival of the thread :)
@AlexC: very nice article on codebase - didn't read it completely but thought you'd like this:
"Freezepoint is using however JSR $DFD3. [this needs further explenation]"
Using a freezepoint requires the $DExx/$DFxx area to be active and CLI - otherwise it will fail (hope I am correct on the CLI :) ) -- DFD3 is AR specific to V5 and V6 only - DExx to 64k ROMs on RR and DFsumthing on AR V4 and even on some V5.2 versions.
Basically what happens on SF in monitor freeze mode is that the 3 bytes which are going to be trashed by the JSR $DFD3 are stored, the 20 d3 df inserted and on entering the freezer the bytes are restored --- there was some interesting small difference between using JMP and JSR - you might want to experiment. :)
Otherwise there is no real difference nor a way to detect whether the program was frozen using a freezepoint or the button.
Defeating the button is senseless anyhow - take it as the debugger it is supposed to be. :)
(Some nice posts and some interesting assumptions as well here - keep it up :))) )
l8r
Count Zero/CyberpunX/SCS*TRC |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
I'd have to agree. Rather than just the fun of trying to "disable the button", there probably isn't a real reason anymore. In the past you used to try to stop people from copying you game or seeing some cool tech you'd worked for months on. Now.... I suspect not.
Still - its good fun trying! :)
I still remember the 1st time I saw a Plus4 game diable the reset into the montior. I didn't know anything back then (some might say not much has change..), and it was just so impressive. Course.... My plus4 was fab, you could actually turn the power off/on and the data would still be there! |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Nice revival of the thread :)
@AlexC: very nice article on codebase - didn't read it completely but thought you'd like this:
"Freezepoint is using however JSR $DFD3. [this needs further explenation]"
Using a freezepoint requires the $DExx/$DFxx area to be active and CLI - otherwise it will fail (hope I am correct on the CLI :) ) -- DFD3 is AR specific to V5 and V6 only - DExx to 64k ROMs on RR and DFsumthing on AR V4 and even on some V5.2 versions.
Basically what happens on SF in monitor freeze mode is that the 3 bytes which are going to be trashed by the JSR $DFD3 are stored, the 20 d3 df inserted and on entering the freezer the bytes are restored --- there was some interesting small difference between using JMP and JSR - you might want to experiment. :)
Otherwise there is no real difference nor a way to detect whether the program was frozen using a freezepoint or the button.
Defeating the button is senseless anyhow - take it as the debugger it is supposed to be. :)
(Some nice posts and some interesting assumptions as well here - keep it up :))) )
l8r
Count Zero/CyberpunX/SCS*TRC
Thanks man. As for my article what happened is: I've sent working version to codebase for review and they posted it right away. Anyway a new version is in the works including some of Expert cart hacking. Now that I finally could get my hands on MMC Expert driver I will post some info regarding it. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: I'd have to agree. Rather than just the fun of trying to "disable the button", there probably isn't a real reason anymore. In the past you used to try to stop people from copying you game or seeing some cool tech you'd worked for months on. Now.... I suspect not.
Still - its good fun trying! :)
I still remember the 1st time I saw a Plus4 game diable the reset into the montior. I didn't know anything back then (some might say not much has change..), and it was just so impressive. Course.... My plus4 was fab, you could actually turn the power off/on and the data would still be there!
Well I agree that today there might be not a good reason to try to detect and/or disable different cartridges. Cracking with emulator is too easy anyway. However this is part of C64 knowledge base and important one. This is why I think it is important to talk about it and document it just like many disk protection systems got their description.
Just my 2 cents, |
| |
Zaphod
Registered: Jun 2012
Posts: 63 |
Yeah, stopping the freeze button is no help with emulator cracking.
This is because you can always use breakpoints and stop it before the anti freezer code runs, and remove it.
Emulator breakpoints are REALLY powerful tools.
I suppose in theory if you set up the anti freeze routine inside the loader, such that it's active before the main program loads, it should work, but making a loader that actually works under these constraints is non trivial.
TO avoid emulator cracking, you must write anti-emulator code. which is a great way to reveal emulator bugs, and get them fixed.
Also as far as i know you CANNOT detect a tri-logic expert in off mode (physically disabled by flipping the switch). Has anyone confirmed beating 1541U or Tri Logic Expert? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
to avoid emulator cracking, implement a proper protection and ship on disks :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
yeah but zoomfloopy etc lets you get a G64 to which you can then start to look at the disk and find the parts if you can't just load it into VICE to start with... |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Maybe Tape is the way to go, as all Leet crackers ditched their tape drives years ago and hence won't be able to read it? |
| |
Tao
Registered: Aug 2002
Posts: 115 |
Quote: Maybe Tape is the way to go, as all Leet crackers ditched their tape drives years ago and hence won't be able to read it?
Except the Leet gamers also ditched their tape drives years ago; I think it's more likely that you'll find crackers with tape drives than gamers--and if there are no gamers, what's the point of releasing the games on tape?
But yeah, tape protections are fun to crack. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:yeah but zoomfloopy etc lets you get a G64 to which you can then start to look at the disk and find the parts if you can't just load it into VICE to start with...
there are a couple things you can do that will make it at least non trivial to create a proper g64, ie requiring manual analyzing of the protection first and manual patching of the g64 to make it work. basically requiring to crack the protection before you can make a g64 :=) not many ppl in this cracking scene left who would be able to do this :)
a tape on the other hand is rather easy to dump, and it will certainly work in the emulator. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZaphodAlso as far as i know you CANNOT detect a tri-logic expert in off mode (physically disabled by flipping the switch). Has anyone confirmed beating 1541U or Tri Logic Expert? Not sure what "beating 1541U" means in this context, but the drive portion can definitely be detected as being a 1541U.
FWIW, 1541U (up to and including current versions) detection code.
drvch1541u: .byte "m-e", .lobyte($0205), .hibyte($0205); read forward
sei
ldx #$ff
stx $0300
stx $1803; set all port pins as outputs
lda #$a4; bit 0 may be forced to GND (1541-II) or connected to track 0 sensor (1541-C, normally 0 = not on track 0)
sta $1801
cmp $1801
bne is1541u
anc #$8a; and #imm, but no asl/rol, bit 7 of result goes to carry
beq is1541u
bcc is1541u
txa
arr #$7f; bit 6 of result goes to carry
ror $0300
is1541u: inc $1803; set all port pins as inputs
cli
rts
drvchkued:If $0300 has a negative value after execution, 1541U detected. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Yeah, stopping the freeze button is no help with emulator cracking.
This is because you can always use breakpoints and stop it before the anti freezer code runs, and remove it.
Emulator breakpoints are REALLY powerful tools.
I suppose in theory if you set up the anti freeze routine inside the loader, such that it's active before the main program loads, it should work, but making a loader that actually works under these constraints is non trivial.
TO avoid emulator cracking, you must write anti-emulator code. which is a great way to reveal emulator bugs, and get them fixed.
Also as far as i know you CANNOT detect a tri-logic expert in off mode (physically disabled by flipping the switch). Has anyone confirmed beating 1541U or Tri Logic Expert?
Actually Expert can be programmed with switch set to OFF position. Take a look at this release: MMC Expert V2.10c
So yes, it is possible to beat it. Secondly there were different versions of Expert. First batch used only NMI generated by Restore key so blocking NMI resulted in Expert being dead. The ESM circuitry if I remember correctly acknowledges NMI to simple NMI lock based on issuing it without ACK is not working any more. (This works in ON mode obviously).
In case of 1541U are we talking about any particular freezer ROM? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the 1541U freezer can also "beaten" easily by using CIA timers.(*) in the VICE testrepo are some testprograms you can use to confirm this :)
(*) if you need regular timers - there are two TOD clocks for you that can finally be put to good use. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, relying chip-internal states that cannot be backed up and restored reliably is a very good way to beat any freezer (except in an emulator, of course). :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quote: Quote:yeah but zoomfloopy etc lets you get a G64 to which you can then start to look at the disk and find the parts if you can't just load it into VICE to start with...
there are a couple things you can do that will make it at least non trivial to create a proper g64, ie requiring manual analyzing of the protection first and manual patching of the g64 to make it work. basically requiring to crack the protection before you can make a g64 :=) not many ppl in this cracking scene left who would be able to do this :)
a tape on the other hand is rather easy to dump, and it will certainly work in the emulator.
There are in the lamer lands you know their names.. that have people who love a good tape loader, there are even people who play the retro games on Twitch and have a camera showing the tapedeck while it loads for "true authenticity" ... yeah me too...
I mean while the g64 will need some patching, it would still be trivial for it get most of the data off the disk, and reading it would be easy to in dirmaster right. Yes you have to crack the image, but you could also load it and see where it goes wrong in VICE etc right? Any disk game we make now has to be mastered on a 1541 or 1571 Ablex are long gone and so are the machines that can write the wafers however we want. So if a 1541/71 can write the disk, a zoomfloppy can read it right? I guess the number of people with RAM expansion and Parrallel mods are low, so that might help?
Now for a 1571 128 release, that I can do some serious heckling with ;) I mean we don't even have a G71 image format for starters :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:it would still be trivial for it get most of the data off the disk, and reading it would be easy to in dirmaster right.
no no no and no. lol
Quote:I mean we don't even have a G71 image format for starters
VICE supports that for a while now >_< |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ozyphantomSo if a 1541/71 can write the disk, a zoomfloppy can read it right? Not so sure about... weak bits, syncless tracks, number of bits not divisible by 8, and possibly a few more. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
indeed. and even with kryoflux there are things that will effectively defeat making a useful image. without a lot of manual work anyways. the most obvious thing are multiple different speedzones on a single track, which is something i'd abuse extensively for such protection. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: indeed. and even with kryoflux there are things that will effectively defeat making a useful image. without a lot of manual work anyways. the most obvious thing are multiple different speedzones on a single track, which is something i'd abuse extensively for such protection.
Still, reading such disk as slow as you can you can still interpret the "stretched" GCR-data. You really need to step away from GCR but then comes severe timing issues. But as long as you have a "clock" embedded into the encoding, such as GCR, it would be trivial to read. Assuming you can get a long line of 0 and 1 from a reader and then post-process on PC. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yeah, i also thought flux images were (or could be) sampled at 16 MHz so the actual mix of speeds on a single track doesn't matter? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the problem arises when you want to make a G64 from the raw data. this requires manual analyzing and manual recreating of the speedzones. and then even when you did all that you will notice that none of the emulators actually gives a shit about the speedzone info in a g64, so the resulting image will still not work :)
the reason for why things like kwikload (which is one for the few originals which actually uses different speedzones on a track) work as g64 in VICE is that its protection only ever checks for "do i read the right data at this position with this speedzone". now if you'd add another check that looks for "when using the wrong speedzone, will i read garbage" it would all fall apart and no more work in any existing emulator (including 1541U etc) because currently all emulators just provide the GCR data from the g64, regardless of what speedzone is being used.
edit: when you omit g64 completely, and use the raw data in emulation directly, all of this _should_ be no issue indeed. but noone actually tested this stuff by now, so it probably doesnt quite work right either =P |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, G64 is the culprit here, as it cannot represent the content of a disk in all its nuances. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes and no. the problem isnt so much that g64 can not represent the disk - it can for the most part. the problem is that the conversion from raw data to g64 is a process that is close to impossible to do automatically (in a 100% generic way) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
It can if you fold knowledge of the protection's expectations into the data distilled to G64 (as that mapping is ambiguous). No such knowledge is required for raw images. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yesyes. thats what i am saying - you need to analyze (and basically "crack") the protection to make a working g64 |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
So... make all damn emulators work with raw images, it's not like we don't have the storage or RAM space. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
VICE has support for it, so does micro64 (p64) - but as said, since almost nothing requires it, its not really tested, and probably has bugs :=) (hoxs64 also has support for some kind of raw images, but no idea if our how that works).
for something like 1541U the size of the image is actually still a problem (it must fit into the ram completely, and non compressed) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
One would think that they compress rather well, with a simple algorithm which allows for efficient on-the-fly decoding in hardware... :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
that just cant be done, you need a raw bitstream - else you cant implement writing in any practical way. you also want to be able to "rotate" all tracks in perfect sync, which also rules out compression. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Being restricted to mounting an image read-only isn't such a bad thing, especially with protected commercial software. As for the other drawback, i'm sceptical. Indices have been invented. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
in the worst case you'd have to decompress an entire track at once. that kind of thing just doesnt work in hardware. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I was thinking of on-the-fly RLE decompression or Huffman or something along those lines. Can be indexed for quasi-random access and aligned rotation. No need to decompress entire tracks. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
even then - you never want to do this. in hardware you always want to do small things in regular intervals, never one huge operation that has to happen "now". |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
There is no huge operation involved, and every sub-operation has an upper bound for data to be accessed and logical complexity.
Anyhow, this discussion doesn't really belong here, plus bigger/faster FPGAs and other devices will come along eventually, allowing for straight-forward raw image operation. |
| |
enthusi
Registered: May 2004
Posts: 677 |
I still think you can master a tape that will always load but never on emulator. I should maybe give that a try :) |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: I still think you can master a tape that will always load but never on emulator. I should maybe give that a try :)
But will you be able to duplicate during manufacturing process? I remember that company duplicating Rubicon tapes had such problems.
Very interesting challenge indeed :) |
| |
chancer
Registered: Apr 2003
Posts: 347 |
I'm sure there have been a number of things that have tripped up folk over the years, exile by audigenic comes to mind and more. I guess being subtle about it, instead of "FU you ain't getting it to work" , is a better approach / catches out more folk. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats a totally different thing :) but indeed, subtle ingame protections are the only ones that *really* work. (spyro on ps1 comes to mind... what a fucking bitch) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
or go RA2... everything is fine, 10mins in to a match and every unit and every building just explodes ;) |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Please note that I am not an expert on tape mastering hardware but I wonder did anyone ever did a tape protection scheme that would load on original C64 with stock Datasette but would fail on duplicate done with hardware like Datel Clonemaster? |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
seems they did https://www.lemon64.com/forum/viewtopic.php?t=69305 |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: seems they did https://www.lemon64.com/forum/viewtopic.php?t=69305
I've seen this topic but I am not sure it was copy protection issue - I mean it could be one of the possible reasons. I never took a peek into how those devices operate but they must be very simple looking at the PCB. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
with high quality tape decks there is very little you can do about dubbing. the usual problems with dual tape copies were almost all related to phase-inverting and some silly auto-gain stuff. both problems do not exist when using two datasettes (but then, you dont have high quality tape decks..) |
| |
Highlander (HLD)
Account closed
Registered: Dec 2018
Posts: 3 |
Quote: even then - you never want to do this. in hardware you always want to do small things in regular intervals, never one huge operation that has to happen "now".
What could work here would be to make the compression format actually be based on a vector of the magnetic phase change information for all tracks, i.e., indicating if a phase change occurs on each given track (or possibly half-track) at each time step. It probably wouldn't compress as well as doing it track-by-track, but I think it would solve the problems that have been raised, in particular, being insensitive to the current bit rate on a given track at a given point in time, and keeping all tracks in sync. It doesn't solve the question of how you acquire the image, but it should at least be implementable in an FPGA easily, and allow regular SD reads to feed it. For writeability, the compression would have to be carefully thought out, so that the compressed size is relatively constant, but the in-memory requirement for the whole disk would at least be solved, assuming you can write to the SD card fast enough, which might be a problem, since 6 complete revolutions per second x ~80 half tracks x ~1MHz sample rate = 480mbit/second (= ~60MiB/second!) raw. Since flux change rates are reasonably low, and limited over a given time period, it should be possible to reduce that figure by some reasonable factor. It might still be impractical. My feeling is that ~1MiB/sec would be required for practicality, which means ~60x compression being required. I'll have to think about the numbers more, as well as what the flux change density is etc, to see if it could be done. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
waste of time imho. just give the device enough RAM and use raw flux pulses. |
