[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USB input devices?



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.

In theory, maybe.  There are serious problems with this as a general
solution.  Just off the top of my head:

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

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

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

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

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

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

I imagine that many of these problems could be worked around by building
a suitably intelligent expansion chassis, with its own power supply and
probably its own processor.  It would definitely need its own clock
source and probably some buffering hardware to deal with the different
bus synchronization and timing requirements.

In limted cases a simple interface may be sufficient, but it would
require quite a lot of extra hardware to implement a general purpose
interface that could support most cards of the appropriate type.

Good luck to anyone who tries.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand