Re: How do I add firmware to a card?

[dempson@actrix.gen.nz (David Empson)]

<aiiadict@gmail.com> wrote:

> Linards Ticmanis wrote:
> > David Wilson wrote:
> >
> > > 2) The UniDisk 3.5 uses the following Smartport calls to allow custom
> > > code to run on the 65c02 in the drive itself:
> > >
> > > $05 Execute - the 65c02 runs the subroutine previously loaded into its
> > > RAM passing the register contents to be used
> > > $06 SetAddress - tells the UniDisk 3.5 where to put the code
> > > $07 Download - transfers code into the UniDisk 3.5 RAM
> >
> > Belated question - are any programs known to use this?

Its primary purpose is to allow copy protection schemes with a 3.5"
disk. I don't know of anything which uses it, and it is only compatible
with a UniDisk 3.5, not with any other 3.5" drive.

> I missed the David's  post until now..
> 
>   I wonder if the Unidisk could be used as a co-processor,
> doing non-disk access computations?

In theory, yes. It would be a rather pointless exercise, unless you were
transferring a relatively small amount of data, doing a long and complex
calculation (with the Apple II doing something else at the same time),
then transferring back the result (also a relatively small amount of
data).

The overhead of the data transfer wipes out any gain in having access to
a second processor, except when the computation time outweighs the
transfer time.

>   Could you set it up as an audio streamer..  or a video
> player for the GR screen?  Does the unidisk 65c02 have
> direct access to the apple bus, or does it communicate
> through the slot through Cx00 I/O locations?

The UniDisk 3.5 cannot access memory in the Apple II. All communication
is under control of the Apple II, which organises data into packets
containing 7 bits of data per byte, and transfers them to or from the
UniDisk 3.5 via the drive bus, using the SmartPort protocol.

If you were to try to use it to compute anything, it would be the rough
equivalent of writing data to a floppy disk, waiting for the computation
to complete (doing something else at the same time), then reading back
the derived data. It would a little faster than a 5.25" disk, because
the encoding method is simpler and would be no seek delay.

The amount of data you could transfer would be in the order of 1 KB,
since the UniDisk has very little RAM.

If you went a little further, you could write a larger amount data to a
3.5" disk and the UniDisk could read it back again in pieces, do the
computation, write the results back to disk, then the Apple II could
read all the data from the disk.

I don't recall whether the 65C02 in the UniDisk 3.5 runs at a higher
clock speed than the Apple II: if data is transferred between the
UniDisk CPU and the 3.5" drive mechanism under processor control then it
would need to run at about 2 MHz (or faster) to be able to keep up with
the data rate (16 microseconds per byte, which is twice as fast as a
5.25" drive). If they used some form of DMA, then the UniDisk's CPU
could be running at the same clock speed as the Apple II.

Assuming you were just transferring 1 KB of data to/from the UniDisk
RAM, the transfer time would be in the order of 4.5 ms each way (9 ms
total).

If the UniDisk runs at 1 MHz, the computation would have to take more
than 9 ms (with the Apple II working on another block of data at the
same time) before you would gain anything from the "parallel computing".

If the UniDisk runs at 2 MHz, the computation would have to take more
than 4.5 ms (with the Apple II working on a half-size block of data at
the same time) before you would gain anything.

This all assumes you actually have a UniDisk 3.5. They are relatively
rare, compared to an Apple 3.5 Drive.

-- 
David Empson
dempson@actrix.gen.nz