DrCoolZic wrote:IMPORTANT MODIFICATIONCurrently Bit 5 of TrackFlags is marked as not used. But in fact it is used!Sarnau describe it as: 5 - with PASTI 0.4b always set, if Bit 0 is set (= track protected)Files that I have generated with Aufit did not have this bit set and the resulting file was not working.

I have looked at many stx files and here what I believe is the meaning of bit 5:

- If bit 5 is set (bit 5=1) then this is the new format that implies that the readTime from Sector Descriptor HAS to be used (i.e. this time must not be equal to zero) unless the sector has the RNF flag set in which case readTime=0 For example this is the case in Maupiti Island where you haveTrack 00.1 6293 bytes 1 sect FuzBytes=No Flag=61 TImage SDesc RecSize=6328 (11102-11117) Sector T=7 H=0 SN=7 S=183 CRC=6607 bitPos=440 Time=0 Flags=18 Off=0 (11118-11133)

- if bit 5 is not set (bit 5=0) this is old format and in that case he readTime behave as explained in the doc: value of 0 means normal sector, value !=0 means you have to use the provided value

This need to be confirmed before I modify the Pasti DocAny feedback is welcome

HelloI haven't checked any file, so I can't confirm or not, but in that case, I don't see what information bit 5 is adding to the decoder library ?Because in all cases, whether bit 5 is 0 or 1, you will always do : if sector has RNF flag, stops and readtime is 0 else if readtime is != 0, use it directly else if readtime == 0, use the standard delay for a sector

I don't see where bit5 is needed ; but maybe the meaning of bit5 is what you describe, it's just that from what I see so far in STX format, there's no extra bit added when information can be deduced from others values.

I will have a look at PASTI.PRG from PastiImgKit.zip to see how images are created, this will be the best way to get the answer (assuming images with bit5=1 were produced with v0.4 beta).

npomarede wrote:HelloI haven't checked any file, so I can't confirm or not, but in that case, I don't see what information bit 5 is adding to the decoder library ?Because in all cases, whether bit 5 is 0 or 1, you will always do : if sector has RNF flag, stops and readtime is 0 else if readtime is != 0, use it directly else if readtime == 0, use the standard delay for a sector

I don't see where bit5 is needed ; but maybe the meaning of bit5 is what you describe, it's just that from what I see so far in STX format, there's no extra bit added when information can be deduced from others values.

I will have a look at PASTI.PRG from PastiImgKit.zip to see how images are created, this will be the best way to get the answer (assuming images with bit5=1 were produced with v0.4 beta).

Nicolas

Nicolas

From a reading point of view you apparently should not care about bit 5 and do exactly what you say. But what is strange is that the Pasti DLL is using this bit because in some cases if not set then the file is not emulated correctly.

I believe the the early Past files where more optimized to generate smaller files and may be to image faster.Pasti file generated with latest version of the imager seems to always have all information possible available: Sector Descriptor with timing length are always present as well as track image and no optimization to reuse track data to output sector.Without any optimization a pasti file is about 1.8MB. As file size is not really an issue anymore it is more easy and safe to always output as much information as possible without going into complex algorithm to find out what is really necessary.

For Pasti writer it is important to also understand how some of the flag are used. In case of bit 5 this is definitively used by the PAsti DLL because when I was writing file without it did not work on some cases. And the cases where it failed where the cases with bit width variation (Rob Northen) so this seems to be related to timing information.

If you disassemble the writer I would be of course interested by anything you find out

DrCoolZic wrote:For Pasti writer it is important to also understand how some of the flag are used. In case of bit 5 this is definitively used by the PAsti DLL because when I was writing file without it did not work on some cases. And the cases where it failed where the cases with bit width variation (Rob Northen) so this seems to be related to timing information.

In that case, doesn't bit5 means "some timing data for each block of 16 bytes are available at the end of the track record" ?In the image you tested, is bit5 always set when some timing blocks are at the end of the track record ?

This is just a part of the code, but we can see the values for file header and track header.Version is always "3", tool is always "1", revision is always "2", reserved_1 and reserved_2 are always "0".

For the track header :- if the track only contains the sector data (similar to a .ST image), then all fields in the track header are set to "0", except TrackBlockSize ($00.l), SectorCount ($08.b) and TrackNumber ($0E.b)- else, the track will contain some sectors header + optional data. In that case TrackFlag ($0A.b) has : bit0=1, bit5=1, bit6=1 if MFM track image is included, bit7=1 if track image has a 2 words header.

So, bit5 is always 1 ; if your conversion tool creates STX images with these values, I think it should be compatible with images created by Pasti 0.4

Thanks for this information.Unfortunately this does gives information about the usage of TrackFlags bit 5 by Pasti DLL? We know that latest versions of imager set ti to 1 but the problem is should you care when reading stx file?

DrCoolZic wrote:Thanks for this information.Unfortunately this does gives information about the usage of TrackFlags bit 5 by Pasti DLL? We know that latest versions of imager set ti to 1 but the problem is should you care when reading stx file?

npomarede wrote:

DrCoolZic wrote:For Pasti writer it is important to also understand how some of the flag are used. In case of bit 5 this is definitively used by the PAsti DLL because when I was writing file without it did not work on some cases. And the cases where it failed where the cases with bit width variation (Rob Northen) so this seems to be related to timing information.

In that case, doesn't bit5 means "some timing data for each block of 16 bytes are available at the end of the track record" ?In the image you tested, is bit5 always set when some timing blocks are at the end of the track record ?

My understanding of this is:- bit5 means some timing data for each block of 16 bytes are available at the end of the track record.- bit5 is always set.

Hippy Dave wrote:My understanding of this is:- bit5 means some timing data for each block of 16 bytes are available at the end of the track record.- bit5 is always set.

Not really, most STX files made with recent pasti have bit 5=1, but no specific timing data for each block of 16 bytes.My guess is more that bit5 has a different meaning in STX version < 3, now that version 3 made with pasti 0.4 seem to always put more detailed info (instead of leaving sometimes defaut values), maybe this bit is not needed anymore (bit5 could mean "precise dump mode" for example, and this mode would now be the default one in pasti 0.4 / STX v3)

Just a wild guess here: it is being used as quick check (possibly the OR result of several conditions) that makes the DLL treat the track using different processing.IPF files have a similar shortcut as well, in order to save on scanning a lot more data to find out whether a track has e.g. variable density or changes content with each revolution.

Pasti DLL used by Steem perform the following operations on reading Pasti file[*] If program try to do a read track on image that do not contains a track data record Pasti gives a warning message (can be disabled) and returns a completely empty track if no sector is present. If sectors are found then the track is filled with appropriate gap information. For example 0x4E followed by 0x00 before sync etc. Before the first sync these value may be shifted as explained below.[*] Read track on an imaged track returns for the bytes located before the first sync: either the bytes recorded in the file or bytes that corresponds to decoded MFM equivalent shifted right by one bit. For example 4E=9524 can be changed to 90=492A. This behavior can be useful when reading certain track like in Barbarian where the read track can return data 00 or FF or AA or 55 before the first sync. However for images done by Pasti or new version of Aufit (0.4b) this may not be required (see below)

Image content creation:When doing a read track the value of the bytes located before the first sync are somewhat unpredictable. For example the character 0x4E present in GAP can take the following values:4E=9254 21=24A9 9C=4952 42=92A4 39=2549 84=4A92 72=9524 09=2A49 E4=5492 12=A924 C9=5349 24=A492 93=4925 48=924A 27=2495 90=492A 4EIn normal case this is not relevant. However in some cases the decoded values are tested as part of a protection and therefore the way it is sampled and stored in stx file becomes important (for example Barbarian or Falcon).IN barbarian or Falcon a train of 8µs flux transition is used that results in a MFM string like this ...10001000100010001000100010001... Depending on where the sampling starts this can result in MFM 1111 2222 4444 8888 that decodes into 55 00 AA 00 respectively.This kind of protection usually test for presence of 00 or FF in bytes before the first sync. Pasti imager and new Aufit 0.4b+ make sure this kind of sequence is stored in the stx file as 00 and therefore the protection check should succeed even if bytes before sync are not shifted as described above

Attached is a Pasti DLL version that is newer than the one available to the public. I don t remember for sure exactly what is new and changed. I would need to check, but I didn t want to delay giving you this update. I do know that some things were fixed, and then some (or all) of the images that didn t work should work now. But, considering that this wasn t widely tested, it is also possible that some things were broken and things that worked in the past didn t work now.

I have been using it for the last three years without problem.But I have also not found any improvements?