Heureka

From Software Archive
Revision as of 00:15, 30 August 2020 by Enigma (talk | contribs)
Jump to navigation Jump to search

Heureka protection has tracks with sectors with a slower write speed followed by two sectors with higher write speed to compensate for the track length. The two sectors with the higher write speed are half as fast as the slower written sectors write speed.

The Heureka protection has this pattern on disk on track 31 and on another track, usually between 2 - 5. The protection itself compares the read time of the sectors of both tracks.

Heureka software checks the protection often and on different places in the program, e.g. after every menu selection. Thus, the relevant locations on the disk degrade fast and are often of bad quality when archived (smeared graphcs).

While the G64 generally supports variable rates per sector within a track there is no support in the conversion from Kryoflux Streams to G64 using the Disk Tool Console. Additionally currently no C64 emulator supports that feature of G64 format.

The current approach is to patch the timer comparison values in the G64.

Once G64 support gets better in dtc as well as emulators we might be able to generate working G64 directly from the source data.

Patching

Note that the following only allows the protection check to work in an emulator.

The lower track for the length check is located in speed zone 3, typically one track between 2 - 5. To get the correct timing result in emulation the track length in bytes in the G64 must be in the range of 0x1EE1 to 0x1EF6, recommended length is 0x1EEF.

The upper track is located in speed zone 0 and typically 31. To get the correct timing result in emulation the track length must be lower than 0x1753.

When converting from Kryoflux Streams or NIBs of a real disk, track 2 length is usually smaller and track 31 length is usually longer.

Convert the G64 with G64Conv to text representation. The location of the start of track 2 is encoded in the G64 at 0x0014, e.g. pointing to 0x21A6. Check the first two bytes at this location, they are the current track length.

Now fill up byte difference in the track trail of track 2 to reach the track length of 0x1EEF with "bytes 55 ..." Convert the text representation to G64 and check the track length on demand.

After track 2 has the correct length, go to track 31. Comment all the fill bytes after the sector header, sector data and in the track trail. Convert back to G64 and check the track length if it is lower than 0x1753. The pointer to track 31 data is located at 0x00FB in the G64, e.g. pointing to 0x03A3F8.

Verify if the G64 works.

Pages that refer to this protection