Re: Write Signal on Disk II Question

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

Michael,

>> On my computer, I need ~650ns to read from the parallel port.
>> This means that I can't read the signal from an original Disk II
>> reliably if it don't process it.
>
> That is correct.  It may be hard for an Apple II-familiar person
> to realize how "remote" PC I/O ports are from the processor.  There
> are several layers of bus conversion involved, each with a step-down
> in clock speed and timing resolution.  On top of that, of course, is
> the timing indeterminacy inherent in modern cached microprocessors.
>
> Several years ago I did some experiments in sampling the read
> signal using a PC parallel port, and I found that I could not
> sample the raw signal fast enough to reliably capture all pulses.
>
> My conclusion was that an external shift register would be needed,
> but its clocking should be based on clock recovery from the data
> stream, which is the entire purpose of the Woz state machine.
>
> That realization was enough to cause me to drop the project.  It was
> clear that an external microcontroller or a Disk ][ Controller would
> be needed.  ;-)

    Are you sure that 3.5" controller card and 5.25" controller card have 
identical Woz state machine chip like logic state sequencer ROM?  You know 
that folks are trying to suggest and use parallel port, but I don't intend 
to discuss this issue.  I only recommend to use USB device.  The USB device 
can depend on 14.3MHz osc chip without having 6502 CPU nor x86 CPU involved. 
The PC floppy drive can be hooked up to the USB device.  You can only send 
the commands through the USB cable using software under Windows XP or other 
Operating System.
    The USB device can always depend on 14.3MHz for timing to run 2 MHz 
clock cycle on Woz state machine chip.  The command can be used to turn on 
the USB drive.  Then another command can be sent for Reading and Writing.  I 
don't know if shifting command is needed because Reading and Writing 
commands can perform shifting itself without any help from software.
    After Reading and Writing commands manipulate the floppy disk, 256 or 
512 bytes are stored into RAM of USB device before another command is sent 
to turn off the floppy drive on USB device.  Then you send the command to 
transfer 256 or 512 bytes from RAM on USB device to another RAM on PC 
machine through the USB cable.
    It is long bit discussion what other folks are trying to do USB device 
project for Apple II disks.  I wonder if you are going to agree that 2 MHz 
out of 14.3MHz can perform reading or writing reliably so you may not need 
Apple II's Disk II controller card.
    It may be perfect for Apple II Emulator to manipulate USB device if you 
like such as Ciderpress can do it.

>> But while I was experimenting with modern 3.5 '' drives on the Apple
>> (I just finished it) it found out that the pulse can be much longer
>> (3�s) without problems. So I would use a monoflop to make the pulse
>> ~2�s long so that I can read it without problems.
>
> Subject, of course, to the remaining timing indeterminacy of an
> interrupt-rich environment and a cached processor...
>
>> But: According to "Understanding the Apple ][" the problem in
>> detecting more than 2 adjacent zero bits is not in the controller, but
>> in the drive. If that is true (I could test it - my 3.5'' drives CAN
>> read more zeroes). We're not improving anything if we're thinking
>> about other controllers.
>
> Correct--after two bit periods without a transition, the MC3470 (?) on
> the analog card continues "turning up the gain" to find a transition,
> and, of course, it succeeds when it interprets noise as signal.
>
> In principle, this period could be extended to reliably handle more than
> two bit periods without a transition, but that would mean lengthening
> the AGC time constant which would make the drive less reliable in the
> presence of short media "weak spots".  The AGC time constant is an
> engineering tradeoff that compromises reliable detection of strings
> of zeroes against tolerance for media fluctuations.  I presume that
> the time constant is chosen for good overall reliability (on the media
> of the time).
>
> The good news is that even copy protected disks seldom relied on reading
> more than two consecutive zeroes.  The exception was nibbles written as
> *all* zero, so that dynamically changing noise could be detected when
> they were read back.  This served to flag a region of the disk as
> unrecorded, which most copy programs did not reproduce.
>
>> And if a copy protected disk works using the Disk ][ controller card
>> it CAN be read. If it can't be copied this can't really be the
>> controller's problem.
>
> More accurately, the data on it can be recovered.  It is possible to
> read data from a disk whose complete transition timing cannot be
> reliably determined.  The trick of some copy protection schemes was
> to have a way of determining that a disk read was "consistent with
> a certain transition string" even though the exact transition string
> could not be determined using the Disk ][ Controller.
>
> The utility of this approach was that a copy program would write an
> "apparent" transition string that was different from the actual
> string, and the difference was detectable by the copy protection code.

    Yes, it is what I am asking to see if special device can read and record 
Read pulse and/or transition into binary image.  Then, exact timing for Disk 
II and Woz state machine can be implemented to simulate.  I hope that 
copy-protected images should function to work by obeying cycle by cycle 
exactly in the perfect timing under software like emulator.  I do know that 
not all NIB images will be able to function using copy-protected scheme 
successfully without any exact timing.
    It is a big challenge to offer a try.  You may be surprised that 
simulating the 5.25" floppy drive's speed (280 - 320 ms) may be able to 
function in a clever design way, but it is always impossible.  Simulating 
the speed is likely to count the total number of bit stream into array 
variable of C++ source code.  If speed is set to fast, the number of 
elements containing individual bit may be full and start to overwriting back 
to the beginning of the array.  If the speed is set to slow, empty elements 
in the array have plenty of room to wait for incoming bit to be stored.  By 
the way, it can fool Copy II Plus on Apple II Emulator into thinking to show 
that variation of speed may look real.
    You use your imaginary in your thought that it may not succeed.  Wasting 
a lot of time is worth a try while you are always retired.  Smile...

Bryan Parkoff