All you always wanted to know about IPF

[DrCoolZic]

Just to make sure ...
Short and long track are NOT done using density. In other words the timebuf (if requested) will return 1000 in all entries.
For the short/long track the "density" for the compete data track (all data and gaps of all sectors) is obtained by taking a "global" density of 0.2 / (tracklen* 8) for 300 RPM FD.

Can you please give a name of an Atari IPF image that contains weak bits
I have tested about 50 ipf files but I did not found one with weak bits
So either I am not doing the right things in the call or there are not so many ipf with weak bits?

[keir]

Yeah, a uniform-density track has to return 1000 for every entry in the timebuf, by definition. You have that figured out fine.

I think weak bit protection is quite rare. I've never analysed one myself.

[mr.vince]

Actually not _that_ rare, at least on the Amiga. Although I don't recall anyone on the ST, but again, I am more used to Amiga. Older ones are possibly the better choice if one was going to check. In later years Rob Northen and some others dominated...

Hey wait, try Magic Lines by Thalion. The Amiga checks a flakey track 50 (!) times.

[DrCoolZic]

That's correct.
NF areas would always yield the exact same data, therefore it is not needed to call an upate for each revolution - what the flag represents.

???? !!!!
This sound strange. I understand that in IPF you can make it perfect but in real life reading a sector with NFA should result in weak bit(s)?

[DrCoolZic]

I have just completed the test of 414 Atari IPF files (using a batch file ) and I could not find any weak bits !!!
The test has been done looking at the IPF content (ipfinfo) and through the API (ipfdump) but without succes.

So question is: Is there at least ONE IPF game imaged with weak bits on ATARI ST platform (I know there are plenty on other platforms).
Is weak bits supported for Atari in CTA (specific format?)

I am using the following (partial) code

Code: Select all

	uint32_t flag=DI_LOCK_DENVAR|DI_LOCK_UPDATEFD|DI_LOCK_TYPE;
	CapsTrackInfoT2 pti;
	CapsDataInfo pinfo;

	for (uint32_t head = pii.minhead; head < pii.maxhead; head++) {
		for (uint32_t track = pii.mincylinder; track < pii.maxcylinder; track++) {
			pti.type = TRK_INFO_T2; // =2
			CAPSLockTrack(&pti, image, track, head, flag);
			bool fuzzy = ((pti.type & CTIT_FLAG_FLAKEY) == CTIT_FLAG_FLAKEY);
			int type = pti.type & CTIT_MASK_TYPE;
			if (fuzzy) fprintf(stderr, "*********************************** Fuzzy bits *********************************\n");
			fprintf(out, "\nTrack %02d.%d type=%d (%s) sectors=%d (size=%d) trklen=%d timelen=%d ovl=%d start=%u wsd=%x wcnt=%u%s%s\n", 
				pti.cylinder, pti.head, type, track_type[type], pti.sectorcnt, pti.sectorsize, 
				pti.tracklen, pti.timelen, pti.overlap, pti.startbit, pti.wseed, pti.weakcnt,
				pti.timelen ? " Timing" : "", fuzzy ? "Fuzzy" : "");
			for (int i = 0; i < pti.weakcnt; i++ ) {
				status = CAPSGetInfo(&pinfo, image, track, head, cgiitWeak, 0);
				fprintf(out, "Fuzzy bits %d start=%d size=%d\n", i, pinfo.start, pinfo.size);
			}
			if (pti.tracklen == 0) break;

[IFW]

That's correct.
NF areas would always yield the exact same data, therefore it is not needed to call an upate for each revolution - what the flag represents.

???? !!!!
This sound strange. I understand that in IPF you can make it perfect but in real life reading a sector with NFA should result in weak bit(s)?

Writing NFA is one way to achieve weak bits - but there are other ways as well, as discussed plenty of times.
NFA read is the result of clever manipulation of flux transitions.

The idea is to create data that cannot be copied by either an analog copier or software.
An analog copier just routes the data read line from one drive to the data write line of the other drive.
Therefore, when you read NFA and you write NFA, the result is: NFA on the original - weak bits on the copy, you know instantly that it is a copy
Software simply cannot write NFA even if it knows what it is, as it requires dedicated hardware, like KryoFlux or a Trace machine that allows arbitrary bitcell sizes.

[IFW]

Yes, CTA automatically detects most generic MFM (including ST) based weak bit protections.
Usually older games have weak bits (apart from a few exceptions), as copying such a disk on an Amiga (be it targeted for the ST or Amiga or anything else...) with a nybbler is not a problem (apart from not being able to verify the data...!), since for the Amiga controller the bit stream defining the flux transitions to be written can be freely defined, ie clock bits are not preset by the hardware.
For ST weak bit protections, try old US Gold and Gremlin titles like Wizard Warz, Gauntlet, Solomon's Key, Shackled, North Star, Deflektor, Dark Fusion etc.
Those should be in upcoming IPF releases

[DrCoolZic]

Writing NFA is one way to achieve weak bits

So back to my original question: why the IPF file on ThemeParkMystery does not show any weak bits "records" in it ?

[DrCoolZic]

For ST weak bit protections, try old US Gold and Gremlin titles like Wizard Warz, Gauntlet, Solomon's Key, Shackled, North Star, Deflektor, Dark Fusion etc.
Those should be in upcoming IPF releases

I only have the 2900+ ipf files from http://capsdi.free.fr/
and it "only" includes about 300 Atari ST games but unfortunately none of the title you mention
Can you send one please?

[IFW]

Writing NFA is one way to achieve weak bits

So back to my original question: why the IPF file on ThemeParkMystery does not show any weak bits "records" in it ?

Because it does not have any - intentionally, that is