| Author: | Rixa (guest: search) |
|---|---|---|
| Date: | Fri, Apr 10th, 2009 @ 04:22 ( . ) |
I've been playing with an 1541 Ultimate and images of my originals. Fat tracks seem to be a bit of a problem with it but not VICE. Even when helped a bit, I discovered something puzzling that happens most of the time with VICE too. M.U.L.E. is listed in the database as having a fat track on 34/35. I made the image now used with mnib36 or nibtools some years ago, and it boots up in VICE. For it to boot in the 1541u I needed to tweak it manually so that tracks 34, 34.5 and 35 all point to the same data (this is how a fat track is supposed to look like, right?) No other half-tracks are included in the image and it wouldn't work without this one, so I'm guessing that with the 1541u half-tracks are empty unless provided. I wonder what VICE does with unprovided half-tracks? Anyways, I noticed that the game loads twice with both, at least most of the time. When it works correctly in VICE, I think it first loads the loader from track 17, then the game from tracks 1 to 7. Then it moves to track 34 and from there to 35 and back, spending several seconds each step, including the half-track in between. Then the game starts. When it doesn't work just correctly, it doesn't stop here. It moves back to 17.5, then 1.5, and all the way to 7.5 like before but half a track higher. The protection track then loads the same, except it jumps straight to 34.5, skipping the initial 34. THEN the game starts. It also loads twice on the 1541u, but if I'm right about the half-tracks being empty, it can't be loading from them.. Any insight on what could be working against me here? Is there something I've overlooked image-wise or is it just a case of imprecise emulation? I wonder why it doesn't work on the first go but does on the second. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Fri, Apr 10th, 2009 @ 07:56 ( . ) |
Hi Rixa, I can't speak about the 1541u's emulation because I can't afford one currently. However, when written back out to disk, it only goes through the protection check once, of course, 34,34.5,35, then the game starts. I can't write that out to disk aligned perfectly (even with an index hole, it's still off a little) so that wouldn't be the same data, but it still passes on the real 1541. There was no such device in the 80's (or ever, probably) that could actually write a "fat" track- this is just two tracks with a known skew between them (0 in this case) . I think it is just measuring the time between sectors when switching tracks from 34-35 and that must not be quite right with the 1541u. |
| Author: | Rixa (guest: search) |
|---|---|---|
| Date: | Sat, Apr 11th, 2009 @ 01:28 ( . ) |
Interesting. I don't think its quite possible to write 34.5 without messing up 34 and 35, so you're probably not doing it. But I seem to remember it's clearly readable on the original and the image only works on the 1541u if its present. The loader spends several seconds on it. Most of the time the game loads twice in VICE too. I just noticed by accident that if I autoload the image, reset while its loading and then load it manually, it loads only once. There are probably easier ways, but I've not looked for them. Perhaps I should re-image to see if the file is somehow funky. |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sun, Apr 12th, 2009 @ 13:29 ( . ) |
Most copy programs like Fast Hack'em had a special program that would create these fat tracks. How did they do it without access to the index hole sensor? Did they just step to track 34, write the special signature to the disk, then immediately step the head to track 35 and do it again? Assuming the amount of data written was an entire track, this would leave only a small skew between them which the protection would deem acceptable? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Apr 12th, 2009 @ 20:52 ( . ) |
They didn't recreate the protection- they just patched out the check for it like a parameter. It's really easy to do based on a signature and no other part of any of the EA software checks it again. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Mon, Apr 13th, 2009 @ 01:50 ( . ) |
There is a program called "EA Cracker" which does what you mention, but in Fast Hack'em 9.5, the program I'm referring to is called "Fat Track Formatter" and allows you to construct a fat track on any track you want. It would then format that track, the next half-track, and the next full track with a number of sectors containing a specific, repeating GCR pattern (B5 2D 4B 52 D4). I tried this with my non-working mnib-to-g64 image of Mail Order Monsters and it was sufficient to allow the protection to pass. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Apr 13th, 2009 @ 09:28 ( . ) |
Ah, I hadn't ever tried that one since they were so easy to crack back in those days. :) It only needs track 34 and 35 aligned, it doesn't really care about 34.5. The 1541 can't write to the main track without corrupting the halftrack and vice-versa. The head is too wide. |
 | Author: | Womo (guest: search) |
|---|---|---|
| Date: | Mon, Apr 13th, 2009 @ 13:47 ( . ) |
Hi Pete, On 04/13/2009 @ 09:28, Pete Rittwage wrote:
[...] The head is too wide. it is more an issue of the construction principle of the so named tunnel-erase read/write heads. First there comes the main write coil that writes the actual data to the track. Behind that one there sit two erase coils that "sharpen" the lower and upper edge of the track by partly erasing the written data again. This makes the former track narrower and results in less "crosstalking" between two neighbored full-tracks. Womo |
 | Author: | J Achernar (registered user: 36 posts ) |
|---|---|---|
| Date: | Tue, Nov 16th, 2010 @ 18:41 ( . ) |
I have been working on Music Construction Set and have observed the behavior described in this thread. In WinVICE 2.2, the program will load, attempt to read the fat track, then reload aligned to the half tracks, read the fat track successfully and then start. I also tried the trick mentioned in this thread of starting an auto load of the program, resetting and doing a manual load. In this case, the manual load completes successfully in one pass. I believe that this is a limitation in WinVICE. CCS64 reads it successfully in one pass. The other floppies that I have with fat tracks are not EA and don't exhibit this behavior. I have tried this with a G64 made with only full tracks, a G64 made with all half tracks and a G64 patched so that all four half track pointers point at the same track in the G64. None of this makes any difference in WinVICE. This tells me that WinVICE does not actually read the half track data in the G64. Otherwise, it should have failed to load the all half track image, on the second half track aligned read pass, since half tracks 1.5, 2.5, etc. contain garbage data. With CCS64 there is also no difference in behavior between any of these three versions. I don't think that it actually reads half tracks either, but I can't confirm this. In the case of backup programs not being able to reproduce the fat track, I believe that some could. My backup copy is not patched when compared to my original. I believe that I made it using Fast Hackem using my 1571 (if that makes a difference). Also, when looking at an image of it scanned with all half tracks, it looks to me that the NIB contains good data on 34.5 and 35.5. I am not very experienced with the internals of NIB files. I have sent the NIBs of my original and my backup to Pete. Maybe he can confirm whether or not the backup successfully reproduces the half tracks. |