Re: Write Signal on Disk II Question

Bryan Parkoff wrote:
"Michael J. Mahon" <mjmahon@xxxxxxx> wrote in message news:WoOdndjHi9KJHqbanZ2dnUVZ_t2inZ2d@xxxxxxxxxxxxxx

ferdimh@xxxxxx 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

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
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

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
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.


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.

Yes, you can.

The EDD 4+ board was the first such board.


NadaPong: Network game demo for Apple II computers!
Home page:

"The wastebasket is our most important design
tool--and it's seriously underused."