Re: USB input devices?

[Charles Stephens <devnull@dobbs.eng.sun.com>]

>>>>> "DE" == David Empson <dempson@actrix.gen.nz> writes:

 DE> Frank Carney <frankcNOSPAM@cyberhighway.net> wrote:
 >> There is another possible solution to all these wants for the Apple II.
 >> We could find out more about interfacing existing I/O cards (Mac, IBM,
 >> etc) to the Apple Bus and write drivers for them.

I am still betting on USB being somewhat practical for the Apple II
(perhaps just the GS).

 DE> - Data bandwidth.  The Apple II slot bus cannot transfer data faster
 DE> than 1 megabyte per second, and then only with DMA in a IIgs.  CPU loops
 DE> or pseudo-DMA techniques limit the transfer rate to more like 100
 DE> kilobytes per second.  Some I/O cards for other busses would require
 DE> faster transfer rates than this for practical operation, or even to work
 DE> at all.

True.  USB can handle upto 12Mbps.  Although keyboards and mice are
slow serial devices, so most input devices can be handled without
problems.  For faster devices, you can always use buffering.  Let's
not kid ourselves.  No way is a USB camera going to work with the A2,
but scanners and printers and generic input devices could work easily
without much trouble.

 DE> - Bus width.  The Apple II bus only transfers 8 bits at a time.  Some
 DE> cards may require 16-bit or larger transfers.

USB is not concerned with the hosts' data path size.  The controller
itself could easily be interfaced with a 8-bit data bus.

 DE> - Address space.  Each slot in the Apple II has 16 bytes plus 256 bytes
 DE> dedicated to it, and there is a further 2 kilobytes that can be shared
 DE> between all slots.  Some other I/O busses provide megabytes of address
 DE> space to their cards.  This would require some kind of sandwiching
 DE> mechanism to access the full address space.

Again, buffers on the card could be banked switched or it could use DMA.

 DE> - Power supply, both in terms of voltages provided and current
 DE> requirements.

External power could be provided by a second power supply and plugged
into a USB card.

 DE> - DMA requirements.  The Apple II DMA mechanism really only works as a
 DE> CPU-controlled burst transfer mechanism.  It cannot safely be used to
 DE> transfer data at arbitrary times under control of an I/O card.  This is
 DE> particularly true in the case of the IIgs, but also to a lesser extent
 DE> for other models.  Some cards may expect to be able to use DMA transfers
 DE> to access the host machine.  This also raises the issue of addressing
 DE> requirements, as DMA can only access 64K of memory.

Again buffering on the controller card would be more useful.

 DE> - Executable code.  In some busses, the cards have firmware on them
 DE> which is called by the driver.  This would require processor emulation
 DE> (of a more powerful processor by a less powerful one), unless the
 DE> appropriate processor was used in the expansion chassis.  I don't think
 DE> this is likely to be much of an issue - ISA only uses firmware on cards
 DE> for boot ROMs or BIOS extensions, as far as I am aware; PCI may require
 DE> Open Firmware (a Forth implementation, I believe).

N/A on USB, everything is driver side on the host.

I suspect the best way to implement USB is in the IIgs's memory
expansion bus.  It could use banks C0-DF as a shared memory area.  RAM
is cheap and dense, so adding 8MB of DRAM would be an option.

Just some ideas.

cfs
-- 
Charles F. Stephens               = cfs  AT  eng.sun.com
Software Psychic and Illuminary   =
Solaris Network Sustaining        = "We don't make mistakes, we make
Solaris Software                  =  happy accidents."
Sun Microsystems, Inc.            =            -- Bob Ross
Menlo Park, California, USA       =