Re: Write Signal on Disk II Question
- From: "Michael J. Mahon" <mjmahon@xxxxxxx>
- Date: Wed, 14 Nov 2007 00:24:04 -0800
Bryan Parkoff wrote:
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, as discussed previously, any such external device will need to
incorporate all the functionality of the Woz machine plus RWTS, and
this strategy only works for *standard* RWTS. A non-standard RWTS
could not be "executed" by the external device, unless it was the
logical and timing equivalent of an Apple II!
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...
I've already given considerable thought to it over the space of twenty
years, and reading Apple II disks with an Apple II still seems like the
simplest and most satisfying solution to me. ;-)
The discussion about general image formats suitable for representing
any Apple II disk has been pretty well beat to death (and I still like
the FDI format).
-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."
.
- Follow-Ups:
- Re: Write Signal on Disk II Question
- From: ferdimh
- 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
- Re: Write Signal on Disk II Question
- From: Bryan Parkoff
- Write Signal on Disk II Question
- Prev by Date: Re: Write Signal on Disk II Question
- Next by Date: Re: Apple IIc + Playstation LCD = Success! (Pictures)
- Previous by thread: Re: Write Signal on Disk II Question
- Next by thread: Re: Write Signal on Disk II Question
- Index(es):
Relevant Pages
|