| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Tue, May 03rd, 2011 @ 19:40 ( . ) |
It uses the drive's job queue to read track 1, sector 0. Unfortunately, like Mainframe, this returns a read error (error 20, "Header block not found" in this case), so it retries 5 times, but adjusts the disk ID registers to match the last read track/sector (which happens to be from track 18). When there's 2 tries left, it bumps the head and reads again. Eventually it runs out of retries and just continues on. It then generates a short list of GCR bytes it needs to find after a sync mark, which is based on the track/sector that was requested to be read, as well as the disk ID and some other values. It never finds this series of bytes and searches forever. I'm thinking that there was a problem imaging track 1 and the image is corrupt. Perhaps there is something intentionally wrong with this track, but it seems odd that a protection from 1989 would rely on bumping the head for a reason other than a actual error situation. Especially one that has it's own GCR reading routine. Unless someone can verify that the original works fine in a real C64 on the drive its being imaged from, I'm going to assume it's a bad image or disk. |
--- 0 Users Online --- 0 Recent Unique Posters |