Heureka - Revision history

Enigma at 22:06, 24 April 2023

2023-04-24T22:06:23Z

Enigma at 22:06, 24 April 2023

2023-04-24T22:06:03Z

Enigma at 17:50, 3 September 2020

2020-09-03T17:50:29Z

Enigma at 11:08, 1 September 2020

2020-09-01T11:08:18Z

Enigma at 16:31, 31 August 2020

2020-08-31T16:31:34Z

Enigma at 22:15, 29 August 2020

2020-08-29T22:15:09Z

Enigma at 21:44, 29 August 2020

2020-08-29T21:44:46Z

Enigma at 18:18, 26 April 2020

2020-04-26T18:18:21Z

Enigma: Created page with "==== Pages that refer to this protection ==== {{Special:Whatlinkshere/Heureka}}"

2020-04-17T23:43:27Z

Created page with "==== Pages that refer to this protection ==== {{Special:Whatlinkshere/Heureka}}"

New page

==== Pages that refer to this protection ====

{{Special:Whatlinkshere/Heureka}}

← Older revision		Revision as of 22:06, 24 April 2023
Line 1:		Line 1:
−	~~Was~~ probably developed by [https://www.c64-wiki.de/wiki/Martin_Pfost Martin Pfost].	+	Heureka protection was probably developed by [https://www.c64-wiki.de/wiki/Martin_Pfost 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.		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.

← Older revision		Revision as of 22:06, 24 April 2023
Line 1:		Line 1:
		+	Was probably developed by [https://www.c64-wiki.de/wiki/Martin_Pfost 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.		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.		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.

@@ Line 20: / Line 20: @@
 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 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.

@@ Line 5: / Line 5: @@
 and expects certain values.
-The Heureka protection has this pattern on disk on track 31 and on another second track, usually between 2 - 5.
+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.

@@ 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.
-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.
 ==== 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.
-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.
-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 ..."
-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.
 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.

@@ Line 14: / Line 14: @@
 Once G64 support gets better in dtc as well as emulators we might be able to generate working G64 directly from the source data.
 ==== Pages that refer to this protection ====
 {{Special:Whatlinkshere/Heureka}}

← Older revision		Revision as of 18:18, 26 April 2020
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.
		+	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.
		+
	==== Pages that refer to this protection ====		==== Pages that refer to this protection ====

	{{Special:Whatlinkshere/Heureka}}		{{Special:Whatlinkshere/Heureka}}