SPS (CAPS) miss list

[Keir]

I tried loading the IPFs I just uploaded to the Zone in WinUAE 4.4.0. It didn't work.

Toni: Any chance you could take a quick look. The IPF track should decode as MFM 2us timing, 105500 bitcells, and I was hoping that would then get automatically converted to GCR 4us timing according to ADKCON.

As said above, I have successfully written the IPF to disk and tested it, so it is sort of basically right. But an IPF that doesn't work in emulation is no good. One of us has a fix to do.

[Toni Wilen]

Originally Posted by Keir

I tried loading the IPFs I just uploaded to the Zone in WinUAE 4.4.0. It didn't work.

Toni: Any chance you could take a quick look. The IPF track should decode as MFM 2us timing, 105500 bitcells, and I was hoping that would then get automatically converted to GCR 4us timing according to ADKCON.

As said above, I have successfully written the IPF to disk and tested it, so it is sort of basically right. But an IPF that doesn't work in emulation is no good. One of us has a fix to do.

There is no conversion, stream is assumed to be in correct "format" already.

But if it isn't, how is emulator supposed to know if it is 4us or 2us stream? (if 4us, use it as is, if 2us "convert" it). Or is caps library data always returned in 2us format? (there does not seem to be define for 4us in any header file..)

And how to convert it? It surely isn't as simple as dropping every other bit
(I am not interested in trying to emulate some PLL...)

[ross]

Sorry Toni maybe I oversimplify the situation and miss some key point because I've no idea how CAPS dll works, but even if it return only 2ns cells when you know by ADKCON that cells are 4ns cannot you convert it in real time?

You do not need a PLL emulation if you trust the flux that is actually 4ns and not 2ns because it must necessarily be consistent with the enlarged cells.

Just an exemple relative to this situation (1 as switch polarity, 0 not):

2ns cells: 10 10 00 00 10 10 00 00 
4ns cells:  1  1  0  0  1  1  0  0

that is exactly what game protection expect.

I suppose in the IPF there is a similar repeated sequence.
What you need is simply to 'sync' to a 1 in the flux.

EDIT.
Yes, just checked, disk 2, last track, contain a long sequence of $82828282... that exactly one of the expected patterns

[Toni Wilen]

Library returns raw decoded data, not flux changes. Library does all the heavy lifting. Which is nice. But in this case it means emulator gets 2us raw data (perhaps even decoded as MFM so some important data might be already lost?) when it should have been 4us.

[Keir]

Yes there's the question: Should the bit stream from CAPS library be 4us or 2us cells for this track?

Since IPF only enumerates 2us cells in its type fields, that made sense to me. You could also auto-detect the average cell size by 200ms / #cells.

From that, I was hoping you would basically do what ross says.

Emitting a track with 4us cells is an option, too. I don't think it really matters either way to any of my own IPF routines.

EDIT: This track is stored in the IPF as raw, since it is not valid MFM. The CAPS library will simply spit out the raw bitstream stored in the IPF. It really doesn't do any processing on it.

[Keir]

Also, if the game is being played from a CTRaw or SCP dump, you can expect 2us bitcells. The former I don't think you can do anything about (the flux->bitcell conversion is done in the Amiga or Kryoflux software). The SCP you could, because there's a PLL in UAE's SCP handler, and you could poke the base clock based on ADKCON.

[Toni Wilen]

Originally Posted by ross

Sorry Toni maybe I oversimplify the situation and miss some key point because I've no idea how CAPS dll works, but even if it return only 2ns cells when you know by ADKCON that cells are 4ns cannot you convert it in real time?

You do not need a PLL emulation if you trust the flux that is actually 4ns and not 2ns because it must necessarily be consistent with the enlarged cells.

Just an exemple relative to this situation (1 as switch polarity, 0 not):

2ns cells: 10 10 00 00 10 10 00 00 
4ns cells:  1  1  0  0  1  1  0  0

that is exactly what game protection expect.

I suppose in the IPF there is a similar repeated sequence.
What you need is simply to 'sync' to a 1 in the flux.

EDIT.
Yes, just checked, disk 2, last track, contain a long sequence of $82828282... that exactly one of the expected patterns

I can't see any long repeating sequences when looking at the buffer that caps library returns.

If I use above decoding, there is only few dozens of complete $3333, $6666 or $9999 words. Protection code expects 2752(!) of them.

[Keir]

Originally Posted by Toni Wilen

I can't see any long repeating sequences when looking at the buffer that caps library returns.

If I use above decoding, there is only few dozens of complete $3333, $6666 or $9999 words. Protection code expects 2752(!) of them.

Really? Track 159 (aka 79.1) of Zoned smb.zip:b.ipf? I see 141414... for full track returned by CAPS lib.

[Toni Wilen]

Originally Posted by Keir

Really? Track 159 (aka 79.1) of Zoned smb.zip:b.ipf? I see 141414... for full track returned by CAPS lib.

I didn't notice smb.zip. It does work fine with above logic. (*.ct files don't work)

[Keir]

Originally Posted by Toni Wilen

I didn't notice smb.zip. It does work fine with above logic. (*.ct files don't work)

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.

Regarding IPF, what would you rather do: Implement 2us->4us conversion, or have 4us directly in the IPF?

[Toni Wilen]

Originally Posted by Keir

Regarding IPF, what would you rather do: Implement 2us->4us conversion, or have 4us directly in the IPF?

I added conversion (everything is assumed to always 2us except if image is extended adf and track size "too small" for 2us) but I am not sure which option is best.

There is always need for conversion at least in theory if someone decides to read the 4us track using 2us mode and expect something specific. (It probably does not exist but still..)

[Keir]

Perhaps the answer is both then. It's hard to say what is "morally right" to put in the IPF. It's a hack either way. I have it working with 4us bit times on that track now, so I think I will go with that. Then it also works with existing releases of UAE.

[Keir]

Ok, disk-analyse is updated (in github) and the final unofficial IPFs are in the Zone. These work for me in WinUAE 4.4.0, no problem!

I am also able to write back to real disk using Greaseweazle. Does anyone else have one and can also give it a try? Kryoflux is untested.

[BarryB]

Yes, now works in WinUAE

It also passes the protection check on Disk 2 for me when written back to real disks with a Kryoflux Wrote with my usual Sony MPF920 to random DD disks, tested on an A500, 1.3 with 1mb and loads just fine

[Keir]

Originally Posted by BarryB

Yes, now works in WinUAE

It also passes the protection check on Disk 2 for me when written back to real disks with a Kryoflux Wrote with my usual Sony MPF920 to random DD disks, tested on an A500, 1.3 with 1mb and loads just fine

Case closed then! Thanks Mr B!

[BarryB]

Thanks for creating a working IPF too

[DamienD]

I've now uploaded "Super Mathane Bros.zip" to the Amiga File Server under the directory /Non TOSEC IPFs - Unofficial

[dlfrsilver]

excellent ! thanks for the work guys !

[jurassicman]

Originally Posted by DamienD

I've now uploaded "Super Mathane Bros.zip" to the Amiga File Server under the directory /Non TOSEC IPFs - Unofficial

Great!
Thanks Damiend!

[DamienD]

Originally Posted by BarryB

In The Zone Das Telekommando, SPS #1810

Big thanks to Denis for sending me the IPF

Seems I missed this...

Now uploaded to the Amiga File Server under the directory /Non TOSEC IPFs - Official