Heureka - Revision history

Enigma at 22:06, 24 April 2023

2023-04-24T22:06:23Z

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

Enigma at 22:06, 24 April 2023

2023-04-24T22:06:03Z

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

Enigma at 17:50, 3 September 2020

2020-09-03T17:50:29Z

← Older revision		Revision as of 17:50, 3 September 2020
Line 20:		Line 20:
	Note that the following description allows the protection check to work in an emulator only.		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.		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.

Enigma at 11:08, 1 September 2020

2020-09-01T11:08:18Z

← Older revision		Revision as of 11:08, 1 September 2020
Line 5:		Line 5:
	and expects certain values.		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.		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.

Enigma at 16:31, 31 August 2020

2020-08-31T16:31:34Z

← Older revision		Revision as of 16:31, 31 August 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.		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.

Enigma at 22:15, 29 August 2020

2020-08-29T22:15:09Z

← Older revision		Revision as of 22:15, 29 August 2020
Line 29:		Line 29:
	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.

	Now fill up ~~bytes accordingly~~ in the track trail of track 2 to reach the track length of 0x1EEF. Convert the text representation to G64 and check the track length on demand.		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.		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.

Enigma at 21:44, 29 August 2020

2020-08-29T21:44:46Z

@@ 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}}

Enigma at 18:18, 26 April 2020

2020-04-26T18:18:21Z

← 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}}

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}}