Pasti format - Revision history

>Sofist: /* How it looks in practice ? */

2013-01-07T09:44:51Z

How it looks in practice ?

@@ Line 221: / Line 221: @@
 ==How it looks in practice ?==
-Works well with Steem emulator, and likely with Saint too (that's all with what is usable). We have thousands avaialable around.
+ How Pasti works in practice ?
-But there is a lot of STX images for not copy-protected floppies. Because people can not judge what is really protected, and by some recommendations. Maybe the plan was that some team will verify Pasti images and make list which are really protected ? Nothing from it, for sure. Actually, author did nothing, really and literaly nothing in last 3 years. In meantime count of images groved, and poeple wants some details. I hope that this will at least partially satisfy needs.
+Credits go to Markus Fritze, Klaus Brod and hunderts of people who made Pasti popular by imaging, sending, uploading, hosting image files.
-I already did SW for converting STX to STT format (only with specific protections, but already have about 50 working STT images, usable with HxC and even writeable onto floppies). SW for shrinking oversized STX files by dropping unnecessary track images (only for experts).
+And not to forget Muguk and Dal - 2 admins which banned me for nothing, so I did something useful instead wasting time with useless discussions on forum :-)
-Maybe this can help to add STX support for some emulator ?
+Fortunately, such 'bad' STX images (with little shifted track image) can be used to get 'perfect' copy - by running in Steem Debugger can see fine how copy protection check fails, and correcting STX  image by shifting little  problematic track image.
-And not to forget Muguk and Dal - 2 admins which banned me for nothing, so I did something useful instead wasting time with useless discussions on forum :-)
+Delayed protection problem is likely not only Pasti problem, but general problem with floppy images.

>Wongck at 12:05, 11 October 2011

2011-10-11T12:05:07Z

← Older revision		Revision as of 08:05, 11 October 2011
Line 241:		Line 241:

	Back to [[Data Formats]]		Back to [[Data Formats]]
			<br />
			<br />
			<br />
			[[Category:Data Formats]]

>Sofist at 09:02, 12 September 2011

2011-09-12T09:02:40Z

← Older revision		Revision as of 05:02, 12 September 2011
Line 236:		Line 236:

	P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: Sept. 2011.		P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: Sept. 2011.

	Note: there are updates to this article - see link above. I will not edit here more, it is too time consuming for me.		Note: there are updates to this article - see link above. I will not edit here more, it is too time consuming for me.


	Back to [[Data Formats]]		Back to [[Data Formats]]

>Sofist at 09:02, 12 September 2011

2011-09-12T09:02:09Z

← Older revision		Revision as of 05:02, 12 September 2011
Line 235:		Line 235:
	And not to forget Muguk and Dal - 2 admins which banned me for nothing, so I did something useful instead wasting time with useless discussions on forum :-)		And not to forget Muguk and Dal - 2 admins which banned me for nothing, so I did something useful instead wasting time with useless discussions on forum :-)

	P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: ~~Aug~~. 2011.		P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: Sept. 2011.
			Note: there are updates to this article - see link above. I will not edit here more, it is too time consuming for me.


	Back to [[Data Formats]]		Back to [[Data Formats]]

>Wongck: /* File header (16 bytes) */

2011-08-20T15:46:55Z

File header (16 bytes)

← Older revision		Revision as of 11:46, 20 August 2011
Line 50:		Line 50:


	[~~image:~~http://atari.8bitchip.info/stxh1.png] this is by images made with public tool and stock Atari ST .		[http://atari.8bitchip.info/stxh1.png] this is by images made with public tool and stock Atari ST .


	[~~Image:~~http://atari.8bitchip.info/stxh2.png] images made with DC .		[http://atari.8bitchip.info/stxh2.png] images made with DC .


	[~~image:~~http://atari.8bitchip.info/stxh3.png] with DC too, I guess.		[http://atari.8bitchip.info/stxh3.png] with DC too, I guess.

>Wongck at 14:10, 20 August 2011

2011-08-20T14:10:44Z

← Older revision		Revision as of 10:10, 20 August 2011
Line 236:		Line 236:

	P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: Aug. 2011.		P. Putnik, [http://atari.8bitchip.info/STXdesc.html STX description] Latest update: Aug. 2011.



			Back to [[Data Formats]]

>Wongck at 14:09, 20 August 2011

2011-08-20T14:09:57Z

← Older revision		Revision as of 10:09, 20 August 2011
Line 14:		Line 14:

	===File header (16 bytes)===		===File header (16 bytes)===
			{\|class="wikitable"
	:0x00 : 'R','S','Y',0 - File ID		\|-
	:0x04 : 0x0300.w - Probably the version number of the format		\|0x00
	:0x06 : 0x0100.w - for public, or 0xCC00 for DC type		\|'R','S','Y',0
	:0x08 : 0.w *		\|File ID
	:0x0a : tracks.b (e.g. 80 or 160 for double sided)		\|-
	:0x0b : 1.b *		\|0x04
	:0x0c : 0.l *		\|0x0300.w
	:(w-word, 16 bits, b-byte, l-long, 32 bits. Little endian)		\|Probably the version number of the format
			\|-
			\|0x06
			\|0x0100.w
			\|for public, or 0xCC00 for DC type
			\|-
			\|0x08
			\|0.w
			\|*
			\|-
			\|0x0a
			\|tracks.b
			\|(e.g. 80 or 160 for double sided)
			\|-
			\|0x0b
			\|1.b
			\|*
			\|-
			\|0x0c
			\|0.l
			\|*
			\|}
			(w-word 16 bits; b-byte; l-long 32 bits. Little endian)


Line 40:		Line 62:

	===Track Header (16 bytes):===		===Track Header (16 bytes):===
			{\|class="wikitable"
	:~~0x00.~~l : length of the track in bytes. This value plus the current position in the file points to the following track header.		\|-
	:~~0x04.~~l : bytes of fuzzy sector mask in this track		\|0x00
	:~~0x08.~~w : number of sectors in the track		\|style="width:4%;text-align:center"\|l
	:~~0x0A.~~w ~~: bitmask~~ with flags		\|length of the track in bytes. This value plus the current position in the file points to the following track header.
	:~~0x0C.~~w : length of the track image in bytes (around 6kb is normal)		\|-
	:~~0x0E.~~b : track number - it is: 0 - last track on side A (usually 79 or 81), and 128 - last track on side B (128-207/9) . So, side is determined by bit 7 (clever) .		\|0x04
	:~~0x0F.~~b : sometimes 0, sometimes 0xCC . DC ?		\|style="width:4%;text-align:center"\|l
			\|bytes of fuzzy sector mask in this track
			\|-
			\|0x08
			\|style="width:4%;text-align:center"\|w
			\|number of sectors in the track
			\|-
			\|0x0A
			\|style="width:4%;text-align:center"\|w
			\|bit mask with flags
			\|-
			\|0x0C
			\|style="width:4%;text-align:center"\|w
			\|length of the track image in bytes (around 6kb is normal)
			\|-
			\|0x0E
			\|style="width:4%;text-align:center"\|b
			\|track number - it is: 0 - last track on side A (usually 79 or 81), and 128 - last track on side B (128-207/9) . So, side is determined by bit 7 (clever).
			\|-
			\|0x0F
			\|style="width:4%;text-align:center"\|b
			\|sometimes 0, sometimes 0xCC . DC ?
			\|}

	The bitmask for the flags (word at 0x0A in track header)		The bitmask for the flags (word at 0x0A in track header)
Line 74:		Line 118:

	===Sector Header (16 bytes):===		===Sector Header (16 bytes):===
	{\|		{\|class="wikitable"
	\|0x00		\|0x00
	\|style="width:4%;text-align:center"\|l		\|style="width:4%;text-align:center"\|l

>Wongck: /* Sector Header (16 bytes): */

2011-08-20T13:57:06Z

Sector Header (16 bytes):

← Older revision		Revision as of 09:57, 20 August 2011
Line 76:		Line 76:
	{\|		{\|
	\|0x00		\|0x00
	\|l		\|style="width:4%;text-align:center"\|l
	\| sector offset inside the track data		\| sector offset inside the track data
	\|-		\|-
	\|0x04~~<br /><br /><br />~~		\|style="vertical-align:top"\|0x04
	\|w ~~<br /><br /><br />~~		\|style="vertical-align:top;text-align:center"\|w
	\| position of the sector header relative to the beginning of the track as a time stamp. The position timing is depended on the RPM speed of the drive, but for a ~6250 byte track the value for a full rotation is around 50000 (for 300 rpm). This allows software to simulate the time it takes to find the sector and read it, something certain copy protection schemes test.		\| position of the sector header relative to the beginning of the track as a time stamp. The position timing is depended on the RPM speed of the drive, but for a ~6250 byte track the value for a full rotation is around 50000 (for 300 rpm). This allows software to simulate the time it takes to find the sector and read it, something certain copy protection schemes test.
	\|-		\|-
	\|0x06~~<br /><br /><br />~~		\|style="vertical-align:top"\|0x06
	\|w ~~<br /><br /><br />~~		\|style="vertical-align:top;text-align:center"\|w
	\| read timing of the sector data, certain copy protections write sectors so, that it takes longer to read them. The protection measures the time to read the sector. 16384 is the default value, larger values mean that it takes longer to read the sector than normal. However if the measured value by PASTI is within 2% of this value (16384 +/- 320), the value written to the stx file is 0 as a sign for a stable read speed.		\| read timing of the sector data, certain copy protections write sectors so, that it takes longer to read them. The protection measures the time to read the sector. 16384 is the default value, larger values mean that it takes longer to read the sector than normal. However if the measured value by PASTI is within 2% of this value (16384 +/- 320), the value written to the stx file is 0 as a sign for a stable read speed.
	\|-		\|-
	\|0x08		\|0x08
	\|b		\|style="width:4%;text-align:center"\|b
	\| Track number from the address block identifying the sector (typically 0..79)		\| Track number from the address block identifying the sector (typically 0..79)
	\|-		\|-
	\|0x09		\|0x09
	\|b		\|style="width:4%;text-align:center"\|b
	\| Side from the address block identifying the sector (typically 0 or 1)<br />Note\| above 2 may be false, as part of the protection (Gold of the Aztecs) .		\| Side from the address block identifying the sector (typically 0 or 1)<br />Note\| above 2 may be false, as part of the protection (Gold of the Aztecs) .
	\|-		\|-
	\|0x0a		\|0x0a
	\|b		\|style="width:4%;text-align:center"\|b
	\| Sector from the address block identifying the sector (typically 1..9)		\| Sector from the address block identifying the sector (typically 1..9)
	\|-		\|-
	\|0x0b		\|0x0b
	\|b		\|style="width:4%;text-align:center"\|b
	\| Size of the sector from the address block identifying the sector (typically\| 2=512 or 3=1024 bytes)		\| Size of the sector from the address block identifying the sector (typically\| 2=512 or 3=1024 bytes)
	\|-		\|-
	\|0x0c		\|0x0c
	\|b		\|style="width:4%;text-align:center"\|b
	\| First byte of the CRC over the address block		\| First byte of the CRC over the address block
	\|-		\|-
	\|0x0d		\|0x0d
	\|b		\|style="width:4%;text-align:center"\|b
	\| Second byte of the CRC over the address block		\| Second byte of the CRC over the address block
	\|-		\|-
	\|0x0e		\|0x0e
	\|b		\|style="width:4%;text-align:center"\|b
	\| FDC status register after reading the sector		\| FDC status register after reading the sector
	\|-		\|-
	\|0x0f		\|0x0f
	\|b		\|style="width:4%;text-align:center"\|b
	\| Sector flags, always 0x00		\| Sector flags, always 0x00
	\|}		\|}

>Wongck at 09:50, 20 August 2011

2011-08-20T09:50:59Z

← Older revision		Revision as of 05:50, 20 August 2011
Line 63:		Line 63:
	Above description may little confuse. In practice, there are some typical values:		Above description may little confuse. In practice, there are some typical values:

	:0xC1 - made with DC - track is not saved with WD1772 read track command, but with DC. Typical track length is about 7KB. Sector datas are inside track data.		#0xC1 - made with DC - track is not saved with WD1772 read track command, but with DC. Typical track length is about 7KB. Sector datas are inside track data.
			#0x61 : made with public tool. There is track image, as WD1772 read track command readed it. There are all sector datas too. It means that total track data is about 10KB. But in practice, track image is needed only for couple tracks (protections) or for none. So, there is overhead, caused by reason that images are made usually by people not able to determine what tracks are protected.
	:0x61 : made with public tool. There is track image, as WD1772 read track command readed it. There are all sector datas too. It means that total track data is about 10KB. But in practice, track image is needed only for couple tracks (protections) or for none. So, there is overhead, caused by reason that images are made usually by people not able to determine what tracks are protected.		#0x21 : there are only sector datas. No track dump. Usually by DC type. By public not - all tracks are usually with flag 0x61.<br />Empty tracks are with flag 0x21 and 0 sectors. Actually, then there is only track header present.
			#If Bit 0 is clear, the track is unprotected and the number of sectors as stored in the track block header are simply saved as 512 byte blocks directly after the header. The track is therefore 16 + 512 * sectors bytes long. - I never saw such.
	:0x21 : there are only sector datas. No track dump. Usually by DC type. By public not - all tracks are usually with flag 0x61 .		#If Bit 6 and 7 are clear, there is no track image and the sectors are stored just by order end length - just like the fuzzy sector mask, except this time for all sectors. Warning: sectors can be missing, if only a header was read, but the data was missing. The FDC status has Bit 4 (Record not found) set in this case.
			#If Bit 6 is set and 7 is clear, the track image is written with a track image header and the sectors follow the track image in the usually order and length. The track image header is just a word (little endian, as usual) that contains the length of the track image.
	Empty tracks are with flag 0x21 and 0 sectors. Actually, then there is only track header present.		#Bit Bit 6 and 7 is set, the track image is written with a track image header that has two words: the first one is a byte offset to the first 0xA1 address mark sync, the second word is the length of the track image in bytes. DC type.
			#If Bit 7 is set, the sector data is usually merged inside the track image, the sector offsets then point inside the actual track image. However, it is possible for single sectors to have an offset _behind_ the track image, if PASTI couldn't map them correctly into the track image. A software should always read the sectors based on the sector offset in the sector header. DC type.
	If Bit 0 is clear, the track is unprotected and the number of sectors as stored in the track block header are simply saved as 512 byte blocks directly after the header. The track is therefore 16 + 512 * sectors bytes long. - I never saw such.		#If Bit 0 is set, the track header is first followed with the sector headers. One for each sector in the track, again 16 bytes per header.

	If Bit 6 and 7 are clear, there is no track image and the sectors are stored just by order end length - just like the fuzzy sector mask, except this time for all sectors. Warning: sectors can be missing, if only a header was read, but the data was missing. The FDC status has Bit 4 (Record not found) set in this case.

	If Bit 6 is set and 7 is clear, the track image is written with a track image header and the sectors follow the track image in the usually order and length. The track image header is just a word (little endian, as usual) that contains the length of the track image.

	Bit Bit 6 and 7 is set, the track image is written with a track image header that has two words: the first one is a byte offset to the first 0xA1 address mark sync, the second word is the length of the track image in bytes. DC type.

	If Bit 7 is set, the sector data is usually merged inside the track image, the sector offsets then point inside the actual track image. However, it is possible for single sectors to have an offset _behind_ the track image, if PASTI couldn't map them correctly into the track image. A software should always read the sectors based on the sector offset in the sector header. DC type.

	If Bit 0 is set, the track header is first followed with the sector headers. One for each sector in the track, again 16 bytes per header.

	===Sector Header (16 bytes):===		===Sector Header (16 bytes):===
			{\|
	:0x00.l : sector offset inside the track data		\|0x00
	:0x04.w : position of the sector header relative to the beginning of the track as a time stamp. The position timing is depended on the RPM speed of the drive, but for a ~6250 byte track the value for a full rotation is around 50000 (for 300 rpm). This allows software to simulate the time it takes to find the sector and read it, something certain copy protection schemes test.		\|l
	:0x06.w : read timing of the sector data, certain copy protections write sectors so, that it takes longer to read them. The protection measures the time to read the sector. 16384 is the default value, larger values mean that it takes longer to read the sector than normal. However if the measured value by PASTI is within 2% of this value (16384 +/- 320), the value written to the stx file is 0 as a sign for a stable read speed.		\| sector offset inside the track data
	:0x08.b : Track number from the address block identifying the sector (typically 0..79)		\|-
	:0x09.b : Side from the address block identifying the sector (typically 0 or 1)		\|0x04<br /><br /><br />
	Note: above 2 may be false, as part of the protection (Gold of the Aztecs) .		\|w <br /><br /><br />
	:0x0a.b : Sector from the address block identifying the sector (typically 1..9)		\| position of the sector header relative to the beginning of the track as a time stamp. The position timing is depended on the RPM speed of the drive, but for a ~6250 byte track the value for a full rotation is around 50000 (for 300 rpm). This allows software to simulate the time it takes to find the sector and read it, something certain copy protection schemes test.
	:0x0b.b : Size of the sector from the address block identifying the sector (typically: 2=512 or 3=1024 bytes)		\|-
	:0x0c.b : First byte of the CRC over the address block		\|0x06<br /><br /><br />
	:0x0d.b : Second byte of the CRC over the address block		\|w <br /><br /><br />
	:0x0e.b : FDC status register after reading the sector		\| read timing of the sector data, certain copy protections write sectors so, that it takes longer to read them. The protection measures the time to read the sector. 16384 is the default value, larger values mean that it takes longer to read the sector than normal. However if the measured value by PASTI is within 2% of this value (16384 +/- 320), the value written to the stx file is 0 as a sign for a stable read speed.
	:0x0f.b : Sector flags, always 0x00		\|-
			\|0x08
			\|b
			\| Track number from the address block identifying the sector (typically 0..79)
			\|-
			\|0x09
			\|b
			\| Side from the address block identifying the sector (typically 0 or 1)<br />Note\| above 2 may be false, as part of the protection (Gold of the Aztecs) .
			\|-
			\|0x0a
			\|b
			\| Sector from the address block identifying the sector (typically 1..9)
			\|-
			\|0x0b
			\|b
			\| Size of the sector from the address block identifying the sector (typically\| 2=512 or 3=1024 bytes)
			\|-
			\|0x0c
			\|b
			\| First byte of the CRC over the address block
			\|-
			\|0x0d
			\|b
			\| Second byte of the CRC over the address block
			\|-
			\|0x0e
			\|b
			\| FDC status register after reading the sector
			\|-
			\|0x0f
			\|b
			\| Sector flags, always 0x00
			\|}

	The CRC is a CCITT CRC16 calculated by the FDC. It is initialized with 0xFFFF and includes the sync marks, therefore typically 0xA1,0xA1,0xA1,0xFE plus the 4 bytes from the address block.		The CRC is a CCITT CRC16 calculated by the FDC. It is initialized with 0xFFFF and includes the sync marks, therefore typically 0xA1,0xA1,0xA1,0xFE plus the 4 bytes from the address block.

>Wongck: /* How it looks in practice ? */

2011-08-20T09:29:41Z

How it looks in practice ?

← Older revision		Revision as of 05:29, 20 August 2011
Line 162:		Line 162:

	Maybe this can help to add STX support for some emulator ?		Maybe this can help to add STX support for some emulator ?



	Credits go to Markus Fritze and hunderts of people who made Pasti popular by making, sending, uploading, hosting image files.		Credits go to Markus Fritze and hunderts of people who made Pasti popular by making, sending, uploading, hosting image files.