Re: Hardware musings

["Michael J. Mahon" <mjmahon@aol.com>]

eeastman@gmail.com wrote:
> Ed Eastman wrote:
>
> > Lets see, 4us per bit
>
>
> I just figured out that emulators need a clock advance signal to tell
> the hardware how 'fast' they are clocking.  The timer on this device
> needs to be guided by the A2 clock pulse in order to be bit accurate in
> it's timing.  Rather than have an asynchronous clock in such a device,
> there should be some feedback to the device of the clock advance to
> allow it to calcualte the rotation of th disk and track seek time
> accurately to reproduce synchronized tracks.

For any emulator to be useful for this purpose, it needs to maintain
an accurate cycle counter, as many of them do.

But there is no way for the PC to interact with an external device
with timing accuracy anything like 4us--especially through USB, which
has trouble even with millisecond-level determinism.

The precise timing part of a PC-attachment project must be done in
the microcontroller outside the PC.  If this meant only the read
timing of nibbles, the problem would be somewhat more manageable,
but, as I noted early in this thread, that is not the case.

Accurate timing must also apply to the seek signals originating
in the copy-protected program being emulated, and there is no way
to preserve their *actual* timing.

All timing would have to be managed in the external microcontroller,
with every request from the PC (to send a signal or interrogate a
signal) cycle-stamped, so that the external controller could do this
job correctly.

This is the problem that led to the notion of the external controller
simply capturing *every* response that a Disk ][ Controller could make
to *any* request and storing it in an "image" that could then be
interpreted by an emulator.

This approach breaks the stimulus-response loop between the external
controller and the PC, and, to the extent that an image can correctly
capture every possible response in advance, allows a sufficiently
accurate emulator on the PC (or anywhere) to run the copy-protected
software.

We then collectively observed that such an image format could be
propagated independent of the device that created it or the device
that interpreted it, to be a new "comprehensive" Apple II image format
capable of representing *almost* all protected Apple II software.

We then agreed that it would be easiest to create such images using
real Apple II hardware.  Such images could support "read-only"
emulation on any platform.  With some additional "decoration" in the
image file, it would be possible to re-create copies of the original
protected media using an Apple II (again, for the vast majority of
protected disks that can be written using a Disk ][).

> Of course this revolation also needs to be applied to the disk II
> bitstream emulated in software if you really want copy protected disks
> to work.  Of course in the event such a signal is not available or
> possible, then real-time emulation should be assumed and have an
> asynchronous clock.
>
> Now I'm trying to remeber if this hareware was to hook to a disk II
> controller or a PC for emlation.  This clock issue could make it not
> totally feasable for both.

To a PC--the relevant part of the original post is:

> Second topic, disk transfer from a Windoze PC to A2 disks.  Since there is
> no way to directly connect a disk ][ drive to a PC (unlike other 8 bit
> computer's disk drives), why couldn't a "magic" box be built that would
> connect a disk ][ to a USB port.  It should be fairly easy to find a USB to
> TTL device that could talk to a PIC, and the PIC could directly manage the
> drive.  On the PC side, it shouldn't need to look like nothing more than a
> USB to serial device, therefore a simple protocol could be developed that
> the PIC code could interpret and perform the necessary functions.
> Considering the amazing CiderPress program, it should be easy for Andy to
> implement a way of sending data down the USB port that includes the protocol
> handshake and a raw disk image (in a predefined format.)  Again, I have
> forgotten most of what I knew about A2 hardware, but I can't imagine it
> being horribly difficult to "emulate" a disk ][ controller with a PIC
> considering it should have to ability to do the timing critical functions.

As noted above, the notion of such a device, attached to a PC, permitting
real protected Apple II disks to be "run" on a PC emulator, seems not to
be practical.

But the "offline" image capture approach could be workable.  (There are still
some issues for programs that write back to the protected disk either for
functional reasons or in support of their copy-protection.)

-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."