Re: Write Signal on Disk II Question

["Bryan Parkoff" <nospam@nospam.com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
WoOdndjHi9KJHqbanZ2dnUVZ_t2inZ2d@comcast.com">news:WoOdndjHi9KJHqbanZ2dnUVZ_t2inZ2d@comcast.com...
> ferdimh@gmx.de wrote:
>>>(BTW, have you
>>>checked for sampling jitter using an oscilloscope?  I was under the
>>>impression that queueing in bus conversion could still introduce
>>>short unpredictable delays.)
>>
>> I'm not sure if I have done in the past, so i've done it again. With
>> interrupts turned off i get 4�s jitter after 1 ms which is much better
>> than I need, and in the same range as my oscilloscope's time base
>> stability. The same instability was also found on the clock, which is
>> fed through the outputs to a little extent. So I suspect, the timing
>> is as good as possible.
>> But I noticed another shocking thing: The timing loop I used to find
>> out the access time has a bug. It counted for approx. 1.7 seconds
>> instead of one. So the access time I mentioned earlier is incorrect.
>> The fixed routine  measures 877000 cycles/sec, or an access time of
>> 1140ns. And this time I double checked with my oscilloscope: It showed
>> the same.
>> Some time ago I used a PCI parallel port card which gave faster access
>> times (around 600us, so I wasn't surprised about the value at all this
>> time).
>
> The longer time of 1140ns sounds more like what I was observing, too.
>
>> And yes, now it IS a serious problem. In theory it should be possible
>> to decode the data, as the rate is still more than twice as high and
>> the timing resolution is quite high, since the delay loop on the main
>> processor can be used for fine-adjustment (I just measured the jitter
>> values with a delay loop set to the right value to yield exactly
>> 250kHz clock).
>> There is another problem though: When calibrating the delay I need to
>> let the loop run with interrupts turned on or I won't be able to get
>> the current time. This could be fixed, for example, by looping for a
>> fixed number of times and THEN checking the clock. but this would be
>> highly inaccurate, since the hardware clock does only have 1-second
>> resolution.
>> I found out that the error is not too great, as the average of about 4
>> million cycles is used. The loop with interrupts just runs a little
>> too slow, meaning that the timing will be a little too fast (On my
>> Oscilloscope I don't see any difference). So this is propably ok.
>> Just if you are interested:
>> I use an Athlon 1700+ on a Gigabyte GA-7VT400. I can say that accurate
>> timing is possible at least with this combination.
>> To simplyfy detection to the extent possible I would use a toggle-
>> flipflop so I only need to check for a toggle and not for a pulse.
>
> That makes sense.
>
>> So what has to be done now?
>> At first I need to write an assembler routine to do the low-level
>> reading stuff.
>> I also need to build a little adapter board containing some wiring, a
>> power supply (i.e. three wires that will be hooked to the pc's power
>> supply) and a '74 as a decoding aid.
>> If this works, I will add arm movement routines and maybe a write
>> capability.
>
> Sounds exactly like what I built before giving up, except that I
> used an external power supply for the drive.  ;-)
>
>> For reading, I would use the following algorithm:
>> 1 Read the data as fast as possible
>> 2 If there wasn't a toggle loop back,
>> 3 store the current byte in memory.
>> 4 shift the byte.
>> 5 Delay for ~2�s maximize jitter margin.
>> 6 Read the data with delay loop.
>> 7 if there was a toggle, loop back to 3.
>> 8 loop to 5 for an given number of times (calculated by calibration
>> routine).
>> 9 Assume there was no toggle and loop back to 3.
>
> It will be interesting to hear the results of your experiments.
>
>>>The only way to determine that a region of a track is unrecorded
>>>(all zeroes) is to read it multiple times and get different results
>>>(as a result of noise).
>>
>> This would mean if a noise are is detected, we just need to write some
>> all-0 bytes to make the noise appear.
>
> Right--but I thought we were just talking about reading...and the need
> to do multiple reads to distinguish "unrecorded" areas of a track.
>
> BTW, there are other things that can cause unrepeatable read data, such
> as reading parts of two recorded tracks--an issue that can arise on
> disks that use fractional-track seeks or "spiral" tracking.

Michael,

    It is annoying to discuss PC floppy using parallel port on the 
newsgroups.  It is interesting.  I wonder why you cna't build another 
controller card instead if Disk II controller card on Apple II's 
motherboard.  You may have more chance to record all read pulses into RAM 
reliably.  I wonder.

Bryan Parkoff