Re: How do I add firmware to a card?

["mdj" <mdj.mdj@gmail.com>]

Tristan Mumford wrote:

> The apple is fast enough depending on how it's done.
> If one were to bit-bang the interface it would be far too slow. However the
> USB controller IC that I am using (and many others) are the rough
> equivalent of an USB UART. A frame of USB data (should be) smaller than the
> size of the onchip buffer. So it can be raided for information at the
> computer's leisure. Then the computer tells the peripheral via the
> controller that its ready for the next frame. So overall data transfer is
> slow but it shouldn't drop anything. That is unless it's a HID device. They
> pretty much just blindly vomit data once initialised correctly.

It seems much simpler to me (if you're planning to implement USB for
storage devices) to use the microcontroller to handle the entire job of
communicating with the USB slave device(s) and present a simple block
interface back to the Apple II.

This would allow the firmware on the Apple side to be very simplistic,
and also get you pretty decent performance. Most microcontrollers have
enough memory to buffer a 512 byte block (or two) in memory, which can
then be transferred a byte at a time back to the Apple. If you design
this such that the byte pointed to by the hardware register
auto-increments on read, you can easily achieve the peak PIO speed
possible over the Apple II bus.

With a bit of extra cleverness, you could take advantage of the
performance differential between USB1.1 and the Apple II and on each
read, read-ahead 3 or 4 (or however many blocks will fit into the spare
RAM in the uC) to minimise the 'seek' overhead as the biggest
performance issue is likely to be round-tripping to the uC for every
block of data read.

Of course, you could still implement direct USB access via 'proxy' as
well, but even that would probably benefit from a layer of abstraction
provided by the uC. That would satisfy those who want to write custom
applications to handle non-storage oriented USB devices.

Providing a rich firmware interface to USB on the Apple II side seems a
little redundant, since no existing software will access it. Better to
utilise the firmware space to provide compatibility with existing
protocols, and leave potentially large and complex code in 'soft'
space. It'll simplify the design, and make it future proof.

Just my 2c...

Matt