Weird problem writing 'weak flux' pattern
#1
Hi there,

I'm experimenting with reliably writing 'weak flux' areas to disk, as short as 64 MFM bitcells (128us), which will read back randomly. I've settled on the following repeated pattern of 12 flux values: 25us, 0.5us*6, 19us, 0.5us*4

This works well. However for convenience I want to use the same pattern even for much larger weak areas. I have one track which is 44894489 ... a few bytes of header ... 8192 MFM weak bitcells (16ms). Remainder of track is normal null filler.

When I generate above track with my chosen weak pattern, write to disk with Supercard Pro, and then read back, my 44894489 header is missing Sad It seems related to the large number of short (500ns) fluxes I am emitting. If I remove those I get my 44894489 sync back.

I can provide before and after SCP files. Of course these are generated entirely by my own tools, so can't discount I've done something stupid  Wink

 Regards,
 Keir
Reply
#2
This is a bit of a black art because what is written is completely dependent on the disk drive electronics themselves.  Some drives can write weakbits just like normal data, while other drives add random amounts of extra time.  I found that I have to test the drive before writing to determine exactly how many bitcells are actually written when writing a weakbit pattern.

To make sure that you don't have some issue, you could use my editor/analyzer to write a flux pattern and then read it back to see the results.  This is how I was able to determine what was really going on with writing weakbits.
Reply
#3
I can do that but note my problem is not with the weak bits themselves. I am generating a nice 200ms-long track which contains a sync (44894489) and a weak region, separated by a few hundred well-defined MFM bitcells (null padding). I therefore can't figure out why my sync pattern doesn't seem to make it to disk!

I agree that the generating of weak bits is itself tricky, I have a long pattern that works and a short pattern that works, on a couple of drives and various floppy disks. So that's okay for now as far as I'm concerned. It's just something somewhere is getting confused when I repeat the short pattern in a long weak region and I think track data is getting corrupted on its way to the disk.
Reply
#4
I guess I mean: I know the drive will not write the weak cells exactly as I specify them, for my weak close-together pulses pattern. That's kind of the point, to weaken and distort the flux pattern and thus the induced signal at the read head.

But the weak region as a whole should stay within its region plus or minus a few microseconds, and shouldn't muck with other non-weak areas getting written out.
Reply
#5
I've not (yet) tried writing weak data out using the SCP, but it's on my list once I've restored write support.

Though I have been successfully writing weak areas using the standard PC floppy controller, with a few multi-pass formatting tricks.  For weak areas on 250Kbps (@300rpm) tracks I found writing 0x07 byte filler at 300Kbps worked well enough to be read back unreliably at 250Kbps.  I was doing something similar to you, but writing a full ID header and the DAM of the data field, with at least part the data field left weak using that technique.

It's relatively coarse in terms of technique, but seemed effective enough to lose FDC sync on all the drives and systems I've tried it on.  I was planning on trying the same on SCP when I got to it, even though the SCP hardware is capable of something much finer grained.  I'd be interested to hear if you find a better approach / pattern to achieve it.
Reply
#6
(02-06-2016, 10:56 AM)obo Wrote: I've not (yet) tried writing weak data out using the SCP, but it's on my list once I've restored write support.

Though I have been successfully writing weak areas using the standard PC floppy controller, with a few multi-pass formatting tricks.  For weak areas on 250Kbps (@300rpm) tracks I found writing 0x07 byte filler at 300Kbps worked well enough to be read back unreliably at 250Kbps.  I was doing something similar to you, but writing a full ID header and the DAM of the data field, with at least part the data field left weak using that technique.

It's relatively coarse in terms of technique, but seemed effective enough to lose FDC sync on all the drives and systems I've tried it on.  I was planning on trying the same on SCP when I got to it, even though the SCP hardware is capable of something much finer grained.  I'd be interested to hear if you find a better approach / pattern to achieve it.

It does somewhat depend how long you have in which to lose sync. I don't know so much about weak regions typically found in IBM/ISO style sectors but I get the impression you find weak regions of at least a millisecond? For that kind of region I emit a repeated fixed pattern but with a moving clock bit. Standard stuff.

However there are some pretty strict (read, stupid) protection formats on Amiga: I have one which reads 16 bits immediately following a sync word, and requires *those* to be non-deterministic. That's tough!  Big Grin
Reply
#7
(02-06-2016, 11:13 AM)keirf Wrote: However there are some pretty strict (read, stupid) protection formats on Amiga: I have one which reads 16 bits immediately following a sync word, and requires *those* to be non-deterministic. That's tough!  Big Grin

I think my simplistic PC FDC approach does usually show a change at the start of the data field, so there must be something there that is good enough.  Though that does contain a write splice between 250Kbps format and 300Kbps format, so it's a bit unpredictable what you actually get when writing it.  My common case only requires a difference somewhere in the sector data, which is much easier!

There is one Amstrad CPC case where there is a 4-byte signature followed by a 4-byte weak area that needs to change.  That will require something a bit closer to what you're looking at for the Amiga, but it's still not as tight.  Finding a reliable de-sync pattern would be good...

Another cheating approach I took for weak sectors was to duplicate them later on the track.  When the software read it multiple times, it actually read different deterministic copies, which fooled it into thinking it was non-deterministic.  That was needed for a motherboard with a buggy FDC, which couldn't handle my multi-pass formatting tricks.  I don't know if that'd work for your Amiga case, or whether changing the original track representation too much would be undesirable.
Reply
#8
Ah that's interesting. I think it partly depends on the drive you're writing with, too. As you say it's unpredictable, but a well-timed write splice should indeed work well. However I can't place arbitrary splices with Supercard Pro -- afaik that is always solely placed at the index mark. Hence my search for other tricks, and it took a good while of fiddling to find the one I describe in the OP.

Writing the same sector/sync twice is pretty cunning, I like that. I guess you need lots of cunning to produce these tricks via a standard IBM-format controller chip Smile It wouldn't work on the specific track I mentioned as the copy protection waits for the index pulse on each iteration.
Reply
#9
You can place the write splice where ever you like.  You don't have to use the index as a reference... however, I do both... by writing more than 1 rev (starting at the index) and terminate the write in an exact location.  This is how SPLICE mode works.

You can write a track starting at any random location by not using the index flag when doing the write.  Using the index as a starting point and writing more than 1 revolution gives you the ability to put the write splice anywhere you like in reference to the index pulse.  For example, you can could put the write splice exactly 180 degrees from the index pulse by calculating the number of bitcells that would need to be written over the course of time of 1 1/2 rotations of the disk.  If the drive is spinning at 300 RPMs, that's 200ms per revolution, so 180 degrees would be 100ms.  Now, you just need to add up the bitcell times to equal 200ms (1 rev)+100ms, and you know exactly how much data needs to be written.  You can of course be exact and factor in the exact length of the track vs. the drive speed.  You can make it +/-1 bitcell if you have a stable drive speed.
Reply
#10
(02-06-2016, 02:35 PM)admin Wrote: You can place the write splice where ever you like.  You don't have to use the index as a reference... however, I do both... by writing more than 1 rev (starting at the index) and terminating the write in an exact location.

Ah, yes makes sense. So to place the splice at offset x, you issue an index-synced write to SCP with x filler at the front and then the real track data.

It's a shame it's not convenient to represent that in a single-revolution-per-track SCP image. A data-starts-at-x, and/or write-splice-is-at-x, field would be handy. As it stands everything is implicitly index-aligned. Unless I'm missing something here too?
Reply




Users browsing this thread: 1 Guest(s)