| |
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... :)
|
|
... 83 posts hidden. Click here to view all posts....
|
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
