| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
any crackers left?
i am wondering if one of the remaining crackers remembers a game which uses more than one speed zone on a single track - this is currently missing/unsupported in the VICE drive emulation, and i would like to have one or two real world test cases for it before i start creating artificial test cases.... anyone? |
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
Didn't Main Frame use this?
IIRC (and that's not all that likely), the RapidLok key track (track 36) contains a decryption key recorded in one speed setting and some "weak bits" recorded in another speed setting. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
mmh, no dump of Main Frame in my gb folder..... anyone? :) |
| |
Fred
Registered: Feb 2003
Posts: 284 |
Try this one:
http://cbm8bit.com/8bit/commodore/disk-image/ea05abd2f89da0733a.. |
| |
tlr
Registered: Sep 2003
Posts: 1722 |
@groepaz: you have a bunch of .g64's no? Couldn't you just scan through them with a small program to find ones with density changes? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
fred: a d64 is useless for this....
tlr: yeah, gotta write one :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
no luck.... according to pete rittwage nibtools dont use that feature when converting to g64, so i guess no such images exist at all.. :/ |
| |
tlr
Registered: Sep 2003
Posts: 1722 |
Seems utterly strange that density switching mid-data wasn't used by protections.
Maybe it's just that the data is output correctly in whatever density selected in the current emulation? Then it will break if emulation is fixed.
.fdi's should contain all density magic but an automated scan for images with relevant usage of switching is way harder. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
yeah thats the "problem"... the emulation will always deliver the right data anyway, so most protection checks would pass.
main frame btw does NOT seem to work... unless i made some stupid mistake converting the nib to g64 |
| |
tlr
Registered: Sep 2003
Posts: 1722 |
Maybe you should just fix emulation. Then every .g64 that relies on switching will be easily found. :)
Straight 16 or 32 MHz bit buffer for the full track would probably be sufficient. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
i wont even look at it unless i have a proper real world test case =P
edit: a g64 of mainframe that was converted from a kryoflux dump DOES work
Quote:Straight 16 or 32 MHz bit buffer for the full track would probably be sufficient.
for this btw, we have the p64 format, which would handle whatever :) anyway, the whole point of this discussion is to find some real world title that does actually not work with the current state of g64 handling - so far noone could come up with one, everything just works fine :) |
