Subject: Re: USB input devices? Newsgroups: comp.sys.apple2 From: dempson@actrix.gen.nz (David Empson) Date: Sat, 30 Jan 1999 03:45:13 +1300 Message-ID: <1dmfcoa.wut1j61rcd6lcN@dempson.actrix.gen.nz> References: <36A84873.F6FF86F3@hotmail.com> <78bm84$8v2$1@chakotay.ncc74656.org> <36AB88EF.52D36BBC@cyberhighway.net> Organization: Empsoft X-Newsreader: MacSOUP 2.3 NNTP-Posting-Host: 202.49.157.176 X-Trace: 30 Jan 1999 01:37:13 -1300, 202.49.157.176 Lines: 60 Path: lobby!newstf02.news.aol.com!portc01.blue.aol.com!news-peer.gip.net!news-stock.gip.net!news.gsl.net!gip.net!news.iprolink.co.nz!news.actrix.gen.nz!dempson Frank Carney 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