Re: Commodore 64 kills APPLE II

[mjmahon@aol.com (Michael J. Mahon)]

David Empson replied:

>Michael J. Mahon <mjmahon@aol.com> wrote:
>
>> Roger Johnstone wrote:
>> 
>> >The Apple UniDisk 3.5 is programmable. It has it's own processor and
>> >enough RAM to hold a program sent to it from the host computer.
>> 
>> It is my understanding that the UniDisk 3.5 is a smartport device.
>> So the question is whether there is a command implemented in
>> its firmware that allows transfer of control to a program stored in
>> its SRAM.
>
>Yes, there is.  It was specifically designed to support copy protection
>mechanisms - you can download code into the drive (and execute it) but
>cannot upload the code back to the computer.
>
>> >The Apple IIgs is fast enough to control the 3.5" disk drive directly,
>> >so the Apple 3.5 Drive doesn't have a processor. However, the IIgs can
>> >store the same routines in it's own memory and run them in the same way
>> >as the processor in the UniDisk 3.5 does.
>> >
>> >That said, does anyone know if any software used this ability, rather
>> >than just using the routines in ROM? Copy protection schemes perhaps?
>> 
>> All the usual tricks permitted by the SWIM chip, which has capabilities
>> and limitations very similar to the Disk ][ controller, though at a higher
>> data rate.
>> 
>> I'm unaware of the full panoply of copy protection tricks employed
>> on 5.25" disks being applied to 3.5" disks, however.  Is there some
>> limitation on direct control of the head positioning motor on the 3.5"
>> drive?  (Or had the industry simply outgrown most of that by the
>> time the IIgs and 3.5" drive became common?)
>
>The 3.5" drive mechanism is inherently "smarter" than the 5.25" one.  It
>probably has a microcontroller on the drive itself, which is responsible
>for details like stepper motor control.  The only head movement
>supported is complete tracks.  (The drive mechanism uses a command
>interface for operations like moving the head, with something like a
>three or four bit command code and one data bit.  It has a similar
>mechanism for reading status information like the write protect sensor.)
>
>Code downloaded to the UniDisk 3.5's on-board 65C02 processor is able to
>change details like the address marks, but there isn't enough RAM in the
>drive to do things like entire raw track dumps.

Very interesting, David.

Is there a source for documentation on this capability?

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/