All you always wanted to know about IPF

3rd Party Software, Tools & Add-ons for KryoFlux
keir
Posts: 35
Joined: Sun Jun 26, 2011 11:03 pm

Re: All you always wanted to know about IPF

Post by keir »

IFW wrote:Both.

Capsdef.h:
CapsImage.sigtype
CapsImage.dentype
CapsBlock.bt.sps.celltype
In the released decoder sources, only the per-track dentype is actually connected to any 'moving parts'. The others may allow future extensions, but at the moment '2us cells' is all that's allowed, and is thus pretty much ignored. I wonder whether you needed/bothered extending the type enumerations for GCR stuff even (e.g., the C64 work you've been doing)? I assume you actually wouldn't need to bother, and renaming the existing '2us' enumeration values to 'uniform density' would work fine.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: All you always wanted to know about IPF

Post by IFW »

DTC uses them, but yes what you say should be possible.
C64 would definitely need different settings :)

User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: All you always wanted to know about IPF

Post by DrCoolZic »

"Pictures" of Theme Park Mystery http://info-coach.fr/atari/hardware/dev ... is.php#TPM

Also attached is output of KFAnalyze if you look at data in sector 11 the 3 sync + FB do not show as hidden as clock info (half bit shifted) but correctly detected in sector 12
Attachments
tha01.rar
TPM KFanalyze output
(12.46 KiB) Downloaded 166 times

User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: All you always wanted to know about IPF

Post by DrCoolZic »

I think that I now have a good idea about the content of IPF file thanks for the information you have provided. ;)

It is quite obvious that the best way to access the information is through the DLL and I have started to write code for this.

Something surprises me: in the IPF file the information is already "decoded": for example the data stream contains only the "data" part of the mfm.
It is only in specific cases (like the sync mark) that the mfm information is present.
However, if I understand correctly, the data buffers returned by CAPSLockTrack() are mfm bits "packed in 8 bits chunk"? Is this correct?

A typical track length is about 12500 bytes of mfm (clock+data)
What is the size of timing buffer? I know it is given by timelen but is it possible for this buffer to have a different value than tracklen? (i.e. may tracklen differ from timelen) ?
My assumption is that if you have timing provided this information is "linked" to data: i.e. timebuf is the timing information for the trackbuf chunk of bits ?
I guess that timebuf is the *total* timing for a chunk of 8 bits?
What is the unit ?
timebuf is of type long (32bits) it is therefore possible to store a large value. So I assume values are in in nano? So a normal chunk would be 8 * 2µs * 1000 = 16000 ns?

Edit:
As a side note very often when storing bit width information this is done using char to save on memory usage. As the char range is small what is actually stored is an differential value from nominal. So standard 2µs value is 0 and variation is +/- 127 units (unit could be 50 ns for example). This is sufficient as timing info does not need to be very accurate

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: All you always wanted to know about IPF

Post by IFW »

It's really simple: you need to store the data content and context.
For MFM encoded data the data content is the data to be encoded, and the context is to apply MFM encoding rules and the cell width.
Nothing else should be stored as these 3 things completely identify the physical layer of encoding at the bitstream level, immediately before bit cells can be converted into flux transitions.

The reason marks are stored "as is" is again: context and content. The possible valid marks under MFM encoding in a single byte is thousands, and the only way to identify those is by storing both the clock bits and the data bits.
But if you think outside of MFM encoding, especially GCR, you can't store clock bits, as there is none - you need the applied mark value "as is", often hand picked by whomever created the encoding tables.
The only uniform way to store marks for all possible encodings is by using their direct physical value.

In FreeForm you'd define a mark by all the clock bits and all the data bits for FM and MFM, and by a direct physical value for anything else.
It's just a more uniform way to actually always have the same physical value specified, regardless of encoding type.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: All you always wanted to know about IPF

Post by IFW »

Locking a track can result in streams that are byte accurate (e.g. multiples of 8 bit cells) or bit accurate (single bit cell).
All parameters and returned values change accordingly to the mode specified for the DLL when calling the functions.
You can further alter behaviour by changing the various flags set for decoding - I really recommend reading the source ;)

User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: All you always wanted to know about IPF

Post by DrCoolZic »

IFW wrote:It's really simple: you need to store the data content and context.
...
Make sense clear and simple ;)

Still have question about timing. I know I should read code but ...

Documentation is extremely convoluted:
The density value supplied by the library is relative to the complete cell time of a track. Each step represents a 1/1000th difference from the default cell density used by normal speed cell groups of the whole track. A value of 1000 represents a cell group in normal - 100% - width; a higher value is a wider cell group (slower/takes more time to read); a lower value is a narrower cell group (faster/takes less time to read).
The normal cell density timing of each bit on a track can be calculated by dividing the amount of time available for one complete revolution of the disk by the number of bits/cells present on the track. The number of cells on a track is always the track data length for one revolution multiplied by 8. ...


So we have => Trklen 12500 bytes = 2µs. More bytes means RPM lower, means width lower than 2µs. So like in stream format you may want to apply a correction to perfect 300RPM

I have completed the code to completely read a track through the IPF DLL :) and I am now working on timing information.
For a normal track I am getting 1000 values for timing which I interpret as: a block of 8 bits is 16µs
so one unit is 16 nanoseconds for 8 bits?
For example a value of 1001 on a nominal track (12500 bytes) means a bit width of 2002 ns ?
I think this is correct but if you can answer just with yes or no it would be perfect :mrgreen:

User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: All you always wanted to know about IPF

Post by DrCoolZic »

Humm looking at the code
copylock ST => GenerateCLST()
time = +50 ?
so my assumption above must be wrong 50 * 2 would be 0.1
therefore most probably 50 * 4 = 0.2 ===> a 4.2 µs width

OK I think I got it: 0.2 is timing variation on mfm data ==> * 2 for data ?

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: All you always wanted to know about IPF

Post by IFW »

For simplicity, with the original timing units selected (via locking) you can think of it as in per mil ‰ units of the selected cell width.
However it actually represents a fraction; you need to sum up all the timing values to get the denominator, and the value in the table is the numerator.
Being a fraction ensures that the timing values for all the cells add up to exactly the expected length of the track - whatever that is (!).

User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: All you always wanted to know about IPF

Post by DrCoolZic »

Next step.
My program can now read track, read addresses, and sectors ;)

But I have the following questions: as mentioned in the doc a disk is a circular entity ...

1. One nice thing about stream format is that it records multiple revolutions and therefore for data "over" index you can continue to read data from one revolution to the next. Of course this provides a perfect "connection" of data from end of track to beginning of track (hope you understand what I mean).
In case of IPF what I hope is that it is possible to perfectly wrap info from end of track to beginning. The "stream bits" are passed as bytes in the track buffer.
The DI_LOCK_ALIGN align on 16 bits. Not sure if this is useful as bits are read in bytes? but lets say this is not set.
Most probably the number of bits of a complete track is NOT a multiple of 8 nevertheless the bits are provided through the API in bytes and tracklen is provided as number of mfm bytes. So my question is: Is there a guaranty that the last byte of bits will connect to first byte of bits perfectly using something like trkbuf[index % trklen] ?

2. Fuzzy bits. How does that works? I assume that if you read multiple time a track with fuzzy bits the information inside the sector will change?
To simulate multiple reads do you have to do CAPSLockTrack() CAPSUnlockTrack() CAPSLockTrack() ?

3. IPF images: can you give me the names of images with the following protections:
- copylockST (density variation on one sector)
- data over index
- fuzzy/weak bits
- long track

Post Reply