All you always wanted to know about IPF

3rd Party Software, Tools & Add-ons for KryoFlux
User avatar
mr.vince
Posts: 1873
Joined: Tue Oct 05, 2010 5:48 pm

All you always wanted to know about IPF

Post by mr.vince » Sat Feb 11, 2012 4:13 pm

Exactly. They don't. Just do your own magic...

But making a bulk erase drive is easy and straightforward... Supply DC to the head, or use a permanent magnet...

TeaRex
Posts: 120
Joined: Tue Nov 30, 2010 5:36 am

Re: All you always wanted to know about IPF

Post by TeaRex » Sat Feb 11, 2012 8:19 pm

mr.vince wrote:But making a bulk erase drive is easy and straightforward... Supply DC to the head, or use a permanent magnet...
Pete Rittwage's nibtools can do just that with a Commodore serial drive. The erase mode simply enables writing, sets the data output to 0 (those are GCR drives with direct firmware control over the data line) and spins the disk. Step over all tracks with enough waiting time in between for a full rotation, and the disk will be totally erased.

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

Re: All you always wanted to know about IPF

Post by IFW » Sat Feb 11, 2012 11:19 pm

DTC always completely erases a track during writing.

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

Re: All you always wanted to know about IPF

Post by DrCoolZic » Fri Mar 09, 2012 6:30 pm

IFW wrote:DTC always completely erases a track during writing.
What does that means?
As FD drives do not have erase head do you mean that a random signal is first written?
Writing with no data provided on the write head? (should not do anything in this case as no flux transitions!)

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

Re: All you always wanted to know about IPF

Post by DrCoolZic » Fri Mar 09, 2012 6:43 pm

I would like to get back to NFA and emulation.
The NFA region is transferred as MFM bits with all zero. This makes sense and this is fine. However there is still a problem to emulate the week bits after NFA.

Lets get back to the Theme Park Mystery: the NFA region is at the very end of the track. So on a real Atari if you do a read track you will get the data until you reach the NFA where you get zeros.
However if you do a read sector of the last sector (that contains the NFA) you get data, then you get no data (in the NFA), then you get random data for the end of the sector. The reason is that you are now trying to read the data at the beginning of the track (as the track wrap) but you get random data because the internal DPLL is now totally lost after the NFA.

As IPF gives perfect result you cannot get this behavior. When reading the beginning of the track you get correct bits, and when reading the same bits as part of the last sector you also get the correct bits. i.e. bit is always equal to bit[i % trklen] and this make sense. Therefore if you want to emulate the behavior of a WD1772 you cannot use directly on the bits provided by the CAPS library. When reading a sector that contains NFA (weather or not wrap at end of track) you need to generate random bytes IN THE EMULATOR independently of the bits provided by CAPS Lib for an amount of time that you have to define yourself.

Is this correct. This is not a big deal but it is important to know to get right results

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

Re: All you always wanted to know about IPF

Post by DrCoolZic » Fri Mar 09, 2012 7:09 pm

I have more question about the CAPS/IPF lib API
- I have documented based on your provided info the reading of track info using the T2 version http://info-coach.fr/atari/software/pro ... track_data_
- I have also documented the CapsGetInfo() function http://info-coach.fr/atari/software/pro ... c588044e33
For the later one I have documented how to get weak info as well on how to get sector info (I do not like the interface that use a void* for no good reason). Can you let me know if you see something wrong.

I think that I understand the info returned for sectors. I am still not 100% sure about gapsizemode value 0 (fixed size) http://info-coach.fr/atari/software/pro ... 95c22444ad for the write splice (attached analysis of back to the future - sector 5 is long sector and uses mode 0 ==> all bits are located in the post splice area?)

Talking about splice.
I still not sure about the overlap value return in CapsTrackInfoT2 http://info-coach.fr/atari/software/pro ... fo_t2.html
From what I understand the position of track splice is located by the start position in the CapsTrackInfoT2 (same location as the last gap splice split given by get sector info)
I assume that overlap is =0 when there is a perfect overlap (no write splice?), <0 is there is an open gap (?), >0 is there is overlapping
Attachments
btf00.rar
ipfanalyze of btf
(6.84 KiB) Downloaded 162 times

keir
Posts: 35
Joined: Sun Jun 26, 2011 11:03 pm

Re: All you always wanted to know about IPF

Post by keir » Mon Jun 18, 2012 8:17 pm

DrCoolZic wrote:
IFW wrote:DTC always completely erases a track during writing.
What does that means?
As FD drives do not have erase head do you mean that a random signal is first written?
Writing with no data provided on the write head? (should not do anything in this case as no flux transitions!)
Writing to a track with no flux transitions on the write head *will* erase a track. It will polarise all magnetic particles in the same direction. Current through write head induces a magnetic field which polarises on-disk particles.

You are confusing this with reading, where only the *changes* in flux on disk will induce a current in the read head. *Change* in magnetic field induces a current.

If writing didn't work in this way, it would be rather difficult to ever re-write a track using a normal floppy drive. :D

keir
Posts: 35
Joined: Sun Jun 26, 2011 11:03 pm

Re: All you always wanted to know about IPF

Post by keir » Mon Jun 18, 2012 8:38 pm

DrCoolZic wrote: I think that I understand the info returned for sectors. I am still not 100% sure about gapsizemode value 0 (fixed size) http://info-coach.fr/atari/software/pro ... 95c22444ad for the write splice (attached analysis of back to the future - sector 5 is long sector and uses mode 0 ==> all bits are located in the post splice area?)

Talking about splice.
I still not sure about the overlap value return in CapsTrackInfoT2 http://info-coach.fr/atari/software/pro ... fo_t2.html
From what I understand the position of track splice is located by the start position in the CapsTrackInfoT2 (same location as the last gap splice split given by get sector info)
I assume that overlap is =0 when there is a perfect overlap (no write splice?), <0 is there is an open gap (?), >0 is there is overlapping
Gap mode 0 is csiegmFixed. It means that the gap stream is fixed size and cannot be extended (by looping the final sample) to fill a larger gap. In this case, the backward gap would be extend if and as necessary (since it has gap mode 1 = csiegmAuto).

Start position indicates where first track data stream starts, relative to the index mark. Overlap position is position of the write splice, relative to the index mark. In this case, it appears that the write splice and index mark exactly coincide.

drdanj
Posts: 37
Joined: Sat Dec 29, 2012 9:47 pm

Re: All you always wanted to know about IPF

Post by drdanj » Tue May 28, 2013 2:32 pm

Dredging this topic up from the past. I'm just learning how this format is used to describe the discs.

I've been looking through the IPF library source. Am I correct in my understanding that presently there is no default "FM" block image encoder and hence the Raw type would need to be used to encode FM? Additionally the bitcell sizes required for Single Density and High Density don't seem to be defined. Does this mean that there are currently no single density and high density IPFs, and additionally no CLV ones? Or is it simply that this library won't currently read IPFs in such formats (In fairness I wouldn't expect it to read CLV if the FDC emulated is a 177x)? Am I (more than likely) being horribly naive? :D

Cheers,

Daniel

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

Re: All you always wanted to know about IPF

Post by IFW » Fri May 31, 2013 1:09 pm

Mostly correct (any bitcell size can be automatic thus already supported); these would be fairly straightforward additions.
I can't recommend adding FM as raw data - the whole point of IPF is having mastering quality data and context information - while storing raw data is quite the opposite ;)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest