Heureka

From Software Archive
Jump to navigation Jump to search

Heureka protection was probably developed by Martin Pfost.

Heureka protection has tracks with sectors with a slower write speed followed usually by two sectors with higher write speed to roughly compensate the track length. The speeds that the sectors were written does not fit one of the four speeds of the 1541. The speed values were chosen in a way, that a 1541 reads these sectors just fine in normal operation. So no bad sectors appear on the disk.

However the track length of these tracks deviates from the default track length. The protection check measures the track length of the tracks containing the off-speed sectors and expects certain values.

The Heureka protection has this pattern on disk on track 31 and on another second track, usually between 2 - 7.

Heureka software checks the protection often and on different places in the program, e.g. after every menu selection. Some releases check only one of these tracks at a time, some check the lower and upper after each other. Thus, the relevant locations on the disk degrade fast and are often of bad quality when archived (smeared in scatter plot).

While the G64 format generally supports variable speed zones per sector within a track (*) there is no support in the conversion from Kryoflux Streams to G64 using the Disk Tool Console. Also as of 2020 no C64 emulator supports that feature of G64 format.

The current approach is to patch the track length in the G64 by adding / removing fill bytes after sector headers/data/track.

  • ) Needs to be verified.

Patching

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

The lower track for the length check is located in speed zone 3, typically one track between 2 - 7. (I take 2 for this example) To get the correct timing result in emulation for the lower track 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 is typically track 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 (low/high).

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 at e.g. 0x21A6 again, if it is 0x1EEF.

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. One might have to add a few bits 111 at the end of track 31 to reach a bit count that is dividable by 8.

Verify if the G64 works.

Pages that refer to this protection