Weird problem writing 'weak flux' pattern
#11
Everything is deliberately index referenced as that is the only way to align tracks correctly.  I don't mind that there is more than 1 rev per track in an image.  This actually helps in determining the write splice location, weak bits, strong bits, etc.

I don't use "filler", I use the actual track data.  So, rev 1 is written followed by however much of rev 2 is required.

When only a single rev is needed (Atari ST, PC, etc.) then it is easy enough to calculate the destination drive speed and compress/expand the track data so that the write splice is dead on.
Reply
#12
(02-06-2016, 03:18 PM)admin Wrote: Everything is deliberately index referenced as that is the only way to align tracks correctly.  I don't mind that there is more than 1 rev per track in an image.  This actually helps in determining the write splice location, weak bits, strong bits, etc.

I don't use "filler", I use the actual track data.  So, rev 1 is written followed by however much of rev 2 is required.

When only a single rev is needed (Atari ST, PC, etc.) then it is easy enough to calculate the destination drive speed and compress/expand the track data so that the write splice is dead on.

Ok. At the moment I only generate images with a single revolution, for both emulation and for write-to-disk. Tracks which have data straddling the index I simply rotate so that the splice is at the index, with the splice usually at the midpoint of the track gap. I get worried about theoretical issues with this simple approach, but in practice I haven't yet found any formats that both straddle the index and care about their offset relative to the index.

For weak regions in a single-revolution image, I inject randomness during 'replay' (emulated read) by jittering samples a little and also randomly ignoring short (<1us) pulses. I only do this in my disk-analyser right now, though it's also a candidate for porting across to the SCP parser in UAE. That said I'm not sure many people use SCP as an image format for generated/analysed images, so UAE is probably mostly seeing multi-revolution raw dumps.
Reply
#13
The rotation of the data will work for all cases *except* disks where they locate a header, step the head, and expect the data to be exactly what is needed (track skew protection).  I ran into quite a few cases of this with the Supercard Ami for the Amiga (which handled this), and this is why I have a SPLICE mode for the SuperCard Pro.

Typically, you don't need to introduce any type of randomness for weakbit data - just write the data you get. If the flux is invalid, it will remain invalid.  Most all .scp images being used in UAE are single revolution, because almost all commercially produced disks were index aligned.   As you know, bitcells are spooled in under WinUAE and the number of bitcells is almost always not an exact even number for decoding to MFM, so that shifts the data by one bitcell (back and forth), which is enough for weakbit protections to see changing data on every revolution.  I have not seen a single weakbit protected game for the Amiga have a problem.  Same holds true for strongbit protections.  Trust me, I tried numerous types of protections that I thought might be a problem, and so far I have yet to see a single failure with anything.  You did a great job with that code.
Reply
#14
(02-07-2016, 09:04 AM)admin Wrote: The rotation of the data will work for all cases *except* disks where they locate a header, step the head, and expect the data to be exactly what is needed (track skew protection).  I ran into quite a few cases of this with the Supercard Ami for the Amiga (which handled this), and this is why I have a SPLICE mode for the SuperCard Pro.

Typically, you don't need to introduce any type of randomness for weakbit data - just write the data you get. If the flux is invalid, it will remain invalid.  Most images for UAE are single revolution, because almost all commercially produced disks were index aligned.

Yes I've seen several such protections on Amiga. None have straddled the index so they all work fine with my simple-minded method Smile

I'm not sure I'm convinced about the "write back what you read" argument. Some floppy read circuits seem to have a tendency to pull bits into the timing window, so what you read is not what was originally written, and if you were to write it back I'm not sure it would work well, at least for short weak regions. It's a moot point for emulation anyway: if you only have one revolution then something has to inject randomness or you generate the same bitstream on every revolution.
Reply
#15
No deliberate randomness is ever required unless the bitcells decoded perfectly for the entire track, and that just doesn't happen because the write splice is almost always a weakbit.  However, it is very easy to determine weakbits in a single revolution and just change the existing weakbit pattern on every rev into a different one if it concerns you.

There are several protections with weakbit and strongbits that do straddle the index, and those work fine under UAE, even with a single revolution.
Reply
#16
(02-07-2016, 09:42 AM)admin Wrote: No deliberate randomness is ever required unless the bitcells decoded perfectly for the entire track, and that just doesn't happen because the write splice is almost always a weakbit.  However, it is very easy to determine weakbits in a single revolution and just change the existing weakbit pattern on every rev into a different one if it concerns you.

There are several protections with weakbit and strongbits that do straddle the index, and those work fine under UAE, even with a single revolution.

Well it works better than I designed it then. Can't complain. Smile It still surprises me that the splice is sufficient randomness, plenty of protections look for a sync pattern and then for weakbits following that. Even if sync were lost at the splice, it would be regained at the sync pattern. Perhaps I'm tilting at windmills here.
Reply




Users browsing this thread: 1 Guest(s)