Difference between revisions of "Heureka"

From Software Archive
Jump to navigation Jump to search
Line 1: Line 1:
−
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.
+
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 two sectors with the higher write speed are half as fast as the slower written sectors write speed.
+
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.
  
−
The Heureka protection has this pattern on disk on track 31 and on another track, usually between 2 - 5.
+
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
−
The protection itself compares the read time of the sectors of both tracks.
+
and expects certain values.
  
−
Heureka software checks the protection often and on different places in the program, e.g. after every menu selection.
+
The Heureka protection has this pattern on disk on track 31 and on another second track, usually between 2 - 5.
−
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.
+
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.
−
Additionally currently no C64 emulator supports that feature of G64 format.
+
Thus, the relevant locations on the disk degrade fast and are often of bad quality when archived (smeared in scatter plot).
  
−
The current approach is to patch the timer comparison values in the G64.
+
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.
  
−
Once G64 support gets better in dtc as well as emulators we might be able to generate working G64 directly from the source data.
+
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 ====
 
==== Patching ====
  
−
Note that the following only allows the protection check to work in an emulator.
+
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 - 5. To get the correct timing result in emulation the track
+
The lower track for the length check is located in speed zone 3, typically one track between 2 - 5. (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.
−
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.
+
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.
 
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.
+
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.
+
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 ..."
 
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.
+
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.
 
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.
 
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.
 
Verify if the G64 works.

Revision as of 18:31, 31 August 2020

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 - 5.

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 - 5. (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

Retrieved from "https://preservation64.de/index.php?title=Heureka&oldid=15852"