[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware musings

Linards Ticmanis wrote:

Michael J. Mahon wrote:


And even the USB isochronous modes are more geared to keeping a buffer
from emptying than to precise real-time reactions in a communication
that is 2-way.  It is not possible, AFAIK, to control something on the
other end of a USB link with microsecond precision.



Hello Micheal,

in what situations would we really need to react that fast to a
situation at the other end?

Obviously we'd need a buffer at the drive end anyway. You'd fill that
buffer with a mixture of bits-to-be-written and drive start/stop + head
movement phase triggering commands from the PC side, then kick off the
writing process. If the buffer is large enough to hold a whole disk's
worth of that data, you should be able to write everything that a real
Apple II can write to disk (and maybe some things that it can't write).


That works for writing, as long as the bits-to-be-written is kept for
every nibble to be written to the disk, and the buffer indeed holds a
whole disk worth.

I expect that's somewhat different from what was originally envisioned.
And, of course, it doesn't easily support update writes, so it really
only works for whole-disk transfers.

The real problem is how you know what to write, since you can only
find out by having a program actually write the disk, and most protected
disks never shipped with a program that could write them.

The practical answer is that you determine exactly what must be written
by observing exactly what the program reads and how it reads it--but
that is more of a human reverse-engineering job than an algorithmic job.


For reading you'd fill the buffer with your 2MHz sampled bit data,
mixing in some information on when exactly you triggered the phases. You
could chose between a small number of different reading algorithms -
like "1.5 rotations on every full track" or "three rotations on every
quarter track". That algorithm would be carried out autonomously and
then you'd "only" need software on the PC side to run the right data
through your state machine and puzzle it all together.

This is certainly a more flexible and universal approach than emulating
a 6502 and a full state machine on the drive end of things.


No, it's *less* flexible than what can be done with an arbitrary program
running on an Apple II controlling a Disk ][.

And there is no way of knowing how to interpret the data without running
or simulating the Apple II code that reads the disk.  It could, for
example, read nibbles until it encounters a magic nibble sequence, then
seek forward two phases in a precise number of cycles, then continue
reading nibbles from the new location.

Reading a disk and seeking is *exactly* the case where there is a fine-
grained 2-way communication between the Apple and the drive.  (To deal
with that, each nibble read from each fractional track would have to be
associated with a "rotation angle".)

No matter how many different things you can pre-program for the external
drive to do, there will always be another program that uses *another*
scheme that you haven't thought of.

And, of course, since you don't know what scheme will actually be used,
the "worst case" must be assumed for every disk, which is very much
worse than the typical actual case.

You can execute code and it will exhibit its behavior, but you can't
mechanically "examine" code and determine what its behavior will be.

Designing an asynchronous external drive is exactly equivalent to
implementing a file format capable of exactly representing all possible
disks that can be read by (not necessarily written by) an Apple II.

This has been discussed several times in the past, and is, I think, a
worthwhile thing to do--but it will be many times the size of a .dsk
image, or even a .nib image.  The irony is that its full complexity
is wasted even on the vast majority protected disks, and yet there
are almost certain to be compromises in its design that make it unable
to represent *some* disks faithfully!

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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