Re: Write Signal on Disk II Question
- From: "Bryan Parkoff" <nospam@xxxxxxxxxx>
- Date: Tue, 13 Nov 2007 23:02:33 -0600
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
.
- Follow-Ups:
- Re: Write Signal on Disk II Question
- From: Michael J. Mahon
- Re: Write Signal on Disk II Question
- References:
- Write Signal on Disk II Question
- From: Bryan Parkoff
- Re: Write Signal on Disk II Question
- From: Mike Willegal
- Re: Write Signal on Disk II Question
- From: Bryan Parkoff
- Re: Write Signal on Disk II Question
- From: Mike Willegal
- Re: Write Signal on Disk II Question
- From: Bryan Parkoff
- Re: Write Signal on Disk II Question
- From: Mike Willegal
- Re: Write Signal on Disk II Question
- From: Bryan Parkoff
- Re: Write Signal on Disk II Question
- From: ferdimh
- Re: Write Signal on Disk II Question
- From: Linards Ticmanis
- Re: Write Signal on Disk II Question
- From: ferdimh
- Re: Write Signal on Disk II Question
- From: Michael J. Mahon
- Re: Write Signal on Disk II Question
- From: ferdimh
- Re: Write Signal on Disk II Question
- From: Michael J. Mahon
- Write Signal on Disk II Question
- Prev by Date: Re: Apple IIc + Playstation LCD = Success! (Pictures)
- Next by Date: Re: Write Signal on Disk II Question
- Previous by thread: Re: Write Signal on Disk II Question
- Next by thread: Re: Write Signal on Disk II Question
- Index(es):
Relevant Pages
|