All you always wanted to know about IPF

[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 ?

Because it does not have any - intentionally, that is

Therefore what do you have to do to provide right data in an emulator?

Do you have to generate random data yourself if you find that the mfm bit data are all at zero?

Would have been nice that the CAPSLib do it for you?

[IFW]

NFA is an area with no flux change whatsoever as expected and checked for by a program.
So you don't have to do anyting with it, since the emulated program expects an area with no flux change whatsoever - and that is exactly what you get from the library.
For writing to a real disk it depends on a few things, which DTC knows about and as I said requires dedicated hardware.

Weak bits - which are not NFA areas - can be generated by the library, so it does it for you, if you select updates, or leaves weak bits as unchanged - in that case you need to query the exact weak bit areas from the library.

[DrCoolZic]

You are right the IPF lib has to return all 0 mfm bytes so we know we are in a NF area.

But inside a machine emulator the FDC emulation will need to generate random bits in this area and this is what have confused me. Sorry
More traditional pseudo-preservation formats do not have capability to store nfa information and therefore they generate random bits

[TeaRex]

DrCoolZic, if I understand correctly what IFW is saying there are actually TWO VERY DIFFERENT KINDS of NFA:

1.) Really no flux transitions are present on the disk, a normal FD controller sees random data.

2.) There are in fact flux transitions on the disk, but they're arranged in an ingenious way, so that a normal controller sees only zeros.

Since these are two very different things it is perhaps confusing to call both of them NFA.

As I understand IFW, Theme Park Mystery is 2.) above. And the library does emulate it by giving you zeros, which in an emulator should be passed as-is to the emulated controller and NOT replaced with random data. For case 1.) the library does indeed give you random data (if you call it the right way), which again should be passed as-is to the emulated controller.

Please correct me if I got this wrong. Also I wonder how you create 2.) above? Very short "blips" in magnetic flux?

[IFW]

TeaRex is spot on
You basically abuse the summing/filtering.

[DrCoolZic]

DrCoolZic, if I understand correctly what IFW is saying there are actually TWO VERY DIFFERENT KINDS of NFA:

1.) Really no flux transitions are present on the disk, a normal FD controller sees random data.

2.) There are in fact flux transitions on the disk, but they're arranged in an ingenious way, so that a normal controller sees only zeros.

Since these are two very different things it is perhaps confusing to call both of them NFA.

This is a never ending debate among specialists
In my opinion the first one does not exist as it would require extremely specific drives with erase capability and as far as I know duplication machine like trace could not do that.
But as you and IFW mentioned by using clever flux transition sequence you end up with exactly the same thing: NO FLUX coming out from the drive. So in both cases the FDC does not receive any flux transitions (apart from possible random transitions due to the fact the ACG is boosted to a max but I have never seen this to happen on all samples that I have done)

As I understand IFW, Theme Park Mystery is 2.) above. And the library does emulate it by giving you zeros, which in an emulator should be passed as-is to the emulated controller and NOT replaced with random data. For case 1.) the library does indeed give you random data (if you call it the right way), which again should be passed as-is to the emulated controller.

I am sorry because I have created confusion and this is due to the fact that a standard so called preservation format usually does not have the capability to store (and in most case to detect) NFA. So usually what is stored is what is read from a FDC that is fuzzy bits. These fuzzy bits are due to the fact that the internal DPLL of the FDC get lost (no more transition) and therefore when the flux come back the bits are not decoded correctly ....
KryouFlux and IPF format are smart and therefore they can detect and store the fact that there is a No Flux Area and this information is directly passed to the client.
- if the client is for example a KryoFlux board that wants to write back the original disk, then the SW will generate specific transitions to create the NFA
- if the client is a machine emulator (FDC emulator) it will take this information and generate for example strings of 0 followed by fuzzy bits ...

Please correct me if I got this wrong. Also I wonder how you create 2.) above? Very short "blips" in magnetic flux?

IFW already replied: abuse of bit shifting You can have a look at my web page http://info-coach.fr/atari/hardware/FD-Hard.php#writing
I need to write a more specific section on NFA

[DrCoolZic]

DrCoolZic, if I understand correctly what IFW is saying there are actually TWO VERY DIFFERENT KINDS of NFA:

1.) Really no flux transitions are present on the disk, a normal FD controller sees random data.

2.) There are in fact flux transitions on the disk, but they're arranged in an ingenious way, so that a normal controller sees only zeros.

Since these are two very different things it is perhaps confusing to call both of them NFA.

This is a never ending debate among specialists
In my opinion the first one does not exist as it would require extremely specific drives with erase capability and as far as I know duplication machine like trace could not do that.
But as you and IFW mentioned by using clever flux transition sequence you end up with exactly the same thing: NO FLUX coming out from the drive. So in both cases the FDC does not receive any flux transitions (apart from possible random transitions due to the fact the ACG is boosted to a max but I have never seen this to happen on all samples that I have done)

As I understand IFW, Theme Park Mystery is 2.) above. And the library does emulate it by giving you zeros, which in an emulator should be passed as-is to the emulated controller and NOT replaced with random data. For case 1.) the library does indeed give you random data (if you call it the right way), which again should be passed as-is to the emulated controller.

I am sorry because I have created confusion and this is due to the fact that a standard so called preservation format usually does not have the capability to store (and in most case to detect) NFA. So usually what is stored is what is read from a FDC that is fuzzy bits. These fuzzy bits are due to the fact that the internal DPLL of the FDC get lost (no more transition) and therefore when the flux come back the bits are not decoded correctly ....
KryouFlux and IPF format are smart and therefore they can detect and store the fact that there is a No Flux Area and this information is directly passed to the client.
- if the client is for example a KryoFlux board that wants to write back the original disk, then the SW will generate specific transitions to create the NFA
- if the client is a machine emulator (FDC emulator) it will take this information and generate for example strings of 0 followed by fuzzy bits ...

Please correct me if I got this wrong. Also I wonder how you create 2.) above? Very short "blips" in magnetic flux?

IFW already replied: abuse of bit shifting You can have a look at my web page http://info-coach.fr/atari/hardware/FD-Hard.php#writing
I need to write a more specific section on NFA

[mr.vince]

1. Does exist. Write DC or use a permanent magnet. The latter could be used to erase a specific track only if built into a drive.

[DrCoolZic]

This is exactly what I mean: anything and everything is feasible

I do not think that "commercial drives" have the capability to erase? I am not taking of tunnel erase or straddle erase heads see
http://www.retrotechnology.com/herbs_st ... html#erase
http://www.pcguide.com/ref/fdd/constHeads-c.html
http://books.google.fr/books?id=O6ccTe2 ... se&f=false

But according to Fyberoptic it is possible to erase a FD just by not applying any signal to data
http://www.fybertech.com/forums/index.php?topic=1020.0
Pretty neat experiment. May be I should try

All other references seems to indicate that on an FDC it is not necessary to erase before writing. This is in contrast with analog recording that requires a separate erase head ...

[DrCoolZic]

For more info: Magnetic Storage handbook: http://books.google.fr/books?id=O6ccTe2 ... &q&f=false

Select chapter 3: Data storage on flexible disk
Goto page 3.25 second section: A FDD have neither full-track erase heads nor a separate erase ....

Excellent reading