SPS (CAPS) miss list

[Belgarath]

Since the miss list on the first post hasn't been updated since October, can someone list what actually is still missing?

[DamienD]

Originally Posted by Belgarath

Since the miss list on the first post hasn't been updated since October, can someone list what actually is still missing?

Heya Belgo,

From reading haynor666's first post in the thread; and then looking at the "[not in TOSEC] IPFs - Official" + "[not in TOSEC] IPFs - Unofficial" directories... these can now be crossed off:

• CityDefence&FortressUnderground_2588
• DownhillChallenge_2923
• FlyHarder_1382
• KalasPuffsExpressen_1041 [unofficial]
• Punica,Das-Computerspiel_1812
• Sumera&Takado_2590

I would have updated the list myself, but well, not being a GMod anymore, I can't

[ross]

Originally Posted by Keir

I don't know that we can do anything about CTR. The problem is that the track is already decoded to bitcells, and with a base clock of 2us it is quite hard to correctly lock onto the flux stream, as 12us is a long zeroes sequence. This is exacerbated by the closer fluxes tending to superimpose and record further apart unless a lot of write precomp is applied. Hence you can end up with something like 4.5us, 11.5us, ... which is much closer to 1010000 than 10100000. And then the PLL goes haywire.

Sorry, this is a bit off topic, but I'm curious
Anyone know how Paula precompensation actually work?

We're dealing with a CAV drive.
The big problem with magnetic surfaces is that in the inner (shorter) tracks of the disk the 'repulsive' force are stronger because polarity changes can be closer.
With certain bit patterns the attraction/repulsions of several successive bits combine is such a way that it can result in 'bit shifting'
(a 'bit' could moves slightly ahead, or behind, the positions it should occupy on the surface).

This is where the possibility of using precompensation on write comes into play.

Track 79.1 of this game is a perfect example where you can see the effect described: two close polarity changes (where the interaction and the displacement is very strong) separated by a large distance without polarity change (and therefore almost no interaction with the previous change).
Therefore can be detected that the two adjacent 1 are now spaced 4ns+0.5, and the two far 12ns-0.5.

My idea is that Paula applies precompensation every other 1 bit.
But how? One 1 regular and the other -PRECOMP or 1 as +PRECOMP and the other -PRECOMP? or something still different?

Doing some real tests (changing the precomp value in writing) with this peculiar track can help understand?
Maybe someone already has the answer or a better idea

@Keir: what is the precomp value that gave you the best results?

[BarryB]

Originally Posted by DamienD

Heya Belgo,

From reading haynor666's first post in the thread; and then looking at the "[not in TOSEC] IPFs - Official" + "[not in TOSEC] IPFs - Unofficial" directories... these can now be crossed off:

• CityDefence&FortressUnderground_2588
• DownhillChallenge_2923
• FlyHarder_1382
• KalasPuffsExpressen_1041 [unofficial]
• Punica,Das-Computerspiel_1812
• Sumera&Takado_2590

I would have updated the list myself, but well, not being a GMod anymore, I can't

I Think these are the still missing ones:

0817 - Stoppt den Calippo Fresser (unofficial IPF released not official)
1891 - Dungeons of Avalon II - The Island of Darkness & Tetrix
2287 - Amber
2529 - Icerunner
2535 - Hexuma Demo
2545 - Fears Preview
2758 - Flowers of Crystal
2764 - Ratco

DrBong said he had some queued up ready to send to Denis but didn't mention exactly which ones!

[Keir]

Originally Posted by ross

Doing some real tests (changing the precomp value in writing) with this peculiar track can help understand?
Maybe someone already has the answer or a better idea

@Keir: what is the precomp value that gave you the best results?

The usual method for MFM precomp is to apply a sliding window across the MFM stream and consider previous and following bits. Consider bits streaming in from the right, and middle bit is the current bit for processing:

10[1]00 -> Current bit is written early (-PRECOMP)
00[1]01 -> Current bit is written late (+PRECOMP)

The Paula options for precomp amount are pretty standard for MFM.

The extremely long 0 sequence in the Methane Bros track I've found works well with 250-500ns of precomp (both work, but 500ns is probably best in my tests). Note that the sequence ...00001010000... actually applies precomp to both 1s, and they end up being written 2xPRECOMP closer together.

[ross]

Originally Posted by Keir

The usual method for MFM precomp is to apply a sliding window across the MFM stream and consider previous and following bits.
---
The extremely long 0 sequence in the Methane Bros track I've found works well with 250-500ns of precomp (both work, but 500ns is probably best in my tests). Note that the sequence ...00001010000... actually applies precomp to both 1s, and they end up being written 2xPRECOMP closer together.

This is interesting, thanks!

I suppose that only a pair of neighboring bits are considered for the sliding windows check between 'current' 1s.
In a standard MFM stream there can be three consecutive zero but probably even if distant bits are not considered for the "current bit", is a breeze for the PLL to correct little discrepancies.
Different for the big hole in polary changes for Methane Bros track where probably there is not any interaction at all for the 'far' 1's position (and the big PRECOMP make really sense).

All these inquiries because I wanted to understand how it was better to use precompensation for an RLL(1,4) encoding where in fact the presence of 4 zeros could make the 1 shift more.
Probably it would be better to divide the disk into 3 zones (0~26->0, 27~53->125, 54~79/80->250) instead of the natural (2 or none).

Another question: how MFMPREC=0 (i.e. GCR precomp) affect early/late polarity changes? (and is it disabled/ineffective in the case of 2ns cells?)

Cheers!

[Keir]

Originally Posted by ross

This is interesting, thanks!

All these inquiries because I wanted to understand how it was better to use precompensation for an RLL(1,4) encoding where in fact the presence of 4 zeros could make the 1 shift more.
Probably it would be better to divide the disk into 3 zones (0~26->0, 27~53->125, 54~79/80->250) instead of the natural (2 or none).

I would warn about anything but RLL(1,3) as later PC drives are very intolerant of weird bit timings. For example, reading CLV Mac disks, and even some Amiga titles which merely have four consecutive 0s in their sync word! "Dumber" older drives tend to be more permissive.

Another question: how MFMPREC=0 (i.e. GCR precomp) affect early/late polarity changes? (and is it disabled/ineffective in the case of 2ns cells?)

I haven't actually done any tests on Paula precomp at all, MFM or GCR. I'm referencing standard IBM MFM FDC datasheets and experiments with Greaseweazle. And I'm not sure what the rules would be on GCR. At a guess it would change the pattern match to look for adjacent 1s at 4us timing, rather than 101.

[ross]

Thanks

[gothmog]

Do you know if it is possible to use TD_RAWWRITE on a real Amiga ( http://amigadev.elowar.com/read/ADCD.../node00F8.html )
to write a long series of 0 bits (violating the MFM timing rules)? In order to create fuzzy bits when reading that area, because of the AGC?
I would say yes but I'm not 100% sure...
Maybe there are copy programs on Amiga able to reproduce disks that would use this trick?

[ross]

Originally Posted by gothmog

Do you know if it is possible to use TD_RAWWRITE on a real Amiga ( http://amigadev.elowar.com/read/ADCD.../node00F8.html )
to write a long series of 0 bits (violating the MFM timing rules)? In order to create fuzzy bits when reading that area, because of the AGC?
I would say yes but I'm not 100% sure...
Maybe there are copy programs on Amiga able to reproduce disks that would use this trick?

Sure you can (ab)use TD_RAWWRITE or bit banging to custom registers to write what you want on tracks.

But I highly doubt you can generate fuzzy bits with a normal floppy head.. if for any reason the polarity changes, I suppose it changes sharply, even if not explicitly requested by the flux.

Take this with a grain of salt, I've no hardware to test it.
The more experienced however will be able to answer better

[gothmog]

If that works, such a "no flux area" should create fuzzy bits (or weak bits, use the name you prefer) because of AGC (Automatic Gain Control):
Read an explanation in the "Magnetic Flux" section at https://diskpreservation.com/dp.php?pg=floppyhow

(Fuzzy bits are not created with actually "weak" signal, this would not be reliable)

[jurassicman]

Hi guys, Am I the only one having issues with the ipf of Super Methane Bros?
When I try to install the game with WHDLoad the installation fails reading the last track of disk "B" for a "checksum error" (actually something similar, maybe "no sync" or so, I don't remember exactly what DIC says but it says that the installation has failed).

[Keir]

Originally Posted by gothmog

If that works, such a "no flux area" should create fuzzy bits (or weak bits, use the name you prefer) because of AGC (Automatic Gain Control):
Read an explanation in the "Magnetic Flux" section at https://diskpreservation.com/dp.php?pg=floppyhow

(Fuzzy bits are not created with actually "weak" signal, this would not be reliable)

Yes this will work. As you say, this is how weak bits are created. On readback: Absence of flux -> crank the amplifier -> noise.

[Keir]

Originally Posted by jurassicman

Hi guys, Am I the only one having issues with the ipf of Super Methane Bros?
When I try to install the game with WHDLoad the installation fails reading the last track of disk "B" for a "checksum error" (actually something similar, maybe "no sync" or so, I don't remember exactly what DIC says but it says that the installation has failed).

I haven't looked but I wouldn't be surprised if the installer needs tweaking to actually do a GCR bit-time read. Or alternatively you may need a very up to date (even beta?) WinUAE which should convert take the GCR bits returned by the IPF library for an MFM read. I'm pretty sure Toni has updated WinUAE in the last few days to do MFM-GCR bit-time conversion in both directions.

EDIT: It's a shame the installer even bothers to read the protection track. Is that a standard choice on WHDLoad installers? In this case there's no data to read. No protection key. Nothing but a repeating pattern.

[ross]

Originally Posted by Keir

I haven't looked but I wouldn't be surprised if the installer needs tweaking to actually do a GCR bit-time read. Or alternatively you may need a very up to date (even beta?) WinUAE which should convert take the GCR bits returned by the IPF library for an MFM read. I'm pretty sure Toni has updated WinUAE in the last few days to do MFM-GCR bit-time conversion in both directions.

EDIT: It's a shame the installer even bothers to read the protection track. Is that a standard choice on WHDLoad installers? In this case there's no data to read. No protection key. Nothing but a repeating pattern.

It seems to be solely a problem of skipping the protected track by the Installer.
I created an ADF from the IPF by clearing the last track and using it together with the existing slave and the game starts.

Therefore only a small update is needed in the WHDLoad game package.

[ross]

Originally Posted by Keir

Yes this will work. As you say, this is how weak bits are created. On readback: Absence of flux -> crank the amplifier -> noise.

Here I could remember badly, too much time has passed, but it seems to me that at the end of the 80s I made some tests by writing a zero flow with my A500: in reading I received random data but they were replicable, so for some reason the ADC always resolved the data in the same way.
The case was different for the unformatted tracks, where the data were actually totally random at each different reading.

This test however is quite simple to do with a real floppy

[gothmog]

Originally Posted by ross

This test however is quite simple to do with a real floppy

True, but I don't have an amiga to make the test myself

[DamienD]

Could a GMod please move all posts discussing disk formats / flux / weak bits etc. to a new thread?

This one is about tracking down / obtaining the last missing .IPF releases.

[jurassicman]

Sorry DamienD I didn't want to start a discussion about copy protections, etc... I was just asking if the ipf of disk "B" of Super Methane Bros was defective in some way and, as far as I understand, it isn't defective but it is the WHDLoad installer that does a check that it should skip...
Thanks again for uploading the ipf files...

[DamienD]

My post wasn't directed at you jurassicman; just in the way in which this thread has gone off topic and taken a different direction.

Easy to have a new thread for this disk formats / flux / weak bits discussion