| |
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 |
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 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
