ferdimh@gmx.de wrote:
I have done a lot of timing-critical stuff over the parallel port. It works very well, if you - run a single-task operating system (Plain DOS) - make use of the CLI instruction while doing critical timing - access the parallel port in every timing loop (this keeps the ISA- bus loaded all the time and gives quite accurate delays) - make all timing-critical code and data fit inside the L1-cache. The timing I yielded with it was VERY stable, so I don't see the problem here. I think the problem is not to miss any pulse and to find out when to stop. I would like to read a whole track and decode it then, but how do I find out when the track is finished...? I want to keep the logic in the timing-critical part as simple as possible. Maybe it's best read for at least 2 revolutions and to hopt that the sectors are somewhere in the track. I will think of it...
Certainly using DOS helps--I was using it in my tests, too--buteven in DOS there may be consequences for keeping interrupts disabled for a couple of disk revolutions at a time (to capture a full track
reliably). But maybe missing some timer ticks is OK. (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.) Reliable pulse detection would still require stretching the 1us read pulses produced by the drive. Timing *resolution* would still be less than that given by the 2MHz sampling of the Disk ][ Controller, so clock recovery reliability would be reduced--only experiment would determine whether the reduction was tolerable in practice (though repeated reading might resolve this issue). 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). -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."