The following is an excerpt from an article scheduled to appear in the February 1991 issue of Amazing Computing. Please refer to that article for more information about the I/O Board as well as ordering information. -JL Happy Holidays! ============================================================================= 12 December 1990 More Ports for Your Amiga An I/O Expansion board by Jeff Lavin Copyright )1990 The Puzzle Factory Many of you in the Amiga community have built Brad Fowles' excellent "LUCAS" accelerator board, which introduced the idea of "Public Domain Hardware". In this article I will present another public domain hardware project for the Amiga, which will enable you to add two parallel ports and two serial ports to your Amiga 500, 1000 or 2000 for $70. Furthermore, you can easily and inexpensively upgrade to four parallel ports and/or four serial ports at any time. The hardware consists of a small printed circuit board with a 40 pin cable and DIP jumper that plugs into the socket occupied by CIA B, and a small pcb that contains the serial interface. CIA B is physically moved onto the I/O Expansion board. This hardware supports 15 standard baud rates, from 50 to 38,400 baud, plus MIDI (31,250 baud). It also supports full hardware handshaking. Up to four units may be open at one time, although the cpu may not be able to keep up with all four units running above 2400 baud. Raison d'etre ============= As a hardware hacker of long standing, I have a number of small computers with all sorts of hardware attached to them, from extra ports to EPROM prog- rammers, and longed to do the same with the Amiga. Since the Amiga uses a pair of 8520's (actually 6526's) for its I/O, I figured it would be a piece of cake to add more 65/68XX family peripheral chips and be up and running. The only problem was that, because there is no obvious chip select decoding, I could never figure out how the 8520's were addressed. One day a friend came by, and we were able to figure out that the I/O chips are "automatically" selected when certain addresses are generated by logic hidden in the PALS. Now that the final piece of the puzzle was in place, I wasted no time and had a prototype in my Amiga in two weeks. How it works ============ This hardware hack is possible because of two things the designers of the Amiga did for us: 1. The address space where the CIAs live is incompletely decoded. This means the 16 CIA registers are echoed repeatedly over a large range. 2. The locations where software is supposed to address the CIA registers is completely specified over a much smaller range. These two facts make it possible for us to take the chip select from one CIA, and divide it into four parts. The addresses in the upper part are routed to the CIA normally, and we "steal" the addresses from the remainder of the space for our own use. Because the "hard" part, most of the address decoding and the bus timing, has been done for us, we can get away with nothing more complicated than an additional address decoder to split off our address space. Unfortunately, this hack is not possible on the A3000 for the same reason that it is possible on earlier Amigas. The address decoding on the A3000 is complete; there are no "extra" incompletely decoded addresses to "steal". The VIA and ACIA registers are still echoed over a pretty wide address range. We have specified where to address them for the same reason that Commodore has specified addresses for the CIAs: to ensure software compatibility. We would very much like to see enough people build these boards to create an installed software base. So programmers, please use these addresses when you are writing all those neat multi-line BBS programs and multi-user applications, as well as process control programs, robotics demos, etc. Software ======== Of course, hardware is next to useless without software to drive it. This section describes the software available for the I/O Expansion Board. The Serial Driver ----------------- Almost all programs written for the Amiga that use the serial port (with the notable exception of some MIDI software) access it indirectly via a standard software module called "serial.device". As a result, most existing software will work fine with the I/O Board given a suitable driver, and we supply one, named "newser.device". Simply copy it to your "DEVS:" directory and you're in business. Most programs will permit you to change the device name (from serial.device to newser.device) as well as the unit number (indicating which port is to be used), or you may use the supplied IOpatch utility, described below (see "Support Programs"). It is worth noting that, as with all other programs relating to the I/O Board, we supply complete assembly language source code of the driver. If you encounter a problem - and all else fails - it's possible to fix it yourself. The Parallel Driver ------------------- The four parallel ports on the I/O Expansion Board are controlled by the eightbit.device. There are no known differences between this device and the V1.3 parallel.device. Applications should not experience any problems communicating with the eightbit.device on the device level. Full assembly language source code of the driver is supplied with the I/O Expansion board. DOS-Level Support ----------------- "DOS-level support" refers to the ability to get and send data via the serial and parallel ports with standard AmigaDOS commands, such as TYPE or LIST, or with any program that does serial or parallel I/O via AmigaDOS, rather than directly via the Exec-level "newser.device" or "eightbit.device". Although this sort of capability is not frequently used, it is useful from time to time. In a perfect world, DOS-level support would mean nothing more than an appropriate MountList entry, specifying a driver name of "newser.device" or "eightbit.device", and some unit number of your choosing, corresponding to a DOS name such as "SER1" or "PAR2". Unfortunately, Commodore supplied a version of the Port-Handler and Aux-Handler with Workbench V1.3 that doesn't permit this; rather, they're hard-coded to use either "serial.device" or "parallel.device". The printer.device suffers from a similar limitation. At the time of this writing, we don't have a solution, other than using IOpatch. However, we expect to have replacement handlers ready by the time you read this. In addition, the handlers in Workbench V2.0 have the capability to use any device and unit, so this whole problem is non-existent if you have V2.0. Support Programs ---------------- Several programs are available for use with the I/O Expansion Board. SERprefs functions much the same as the serial section of Preferences, but allows you to set and save parameters for all four units of the newser.device. These are saved in "S:Serial-Preferences". Many programs allow you to specify the device name and unit number, so that using an alternate device driver is no problem. For those applications that insist on using a particular device, we have written a nice little hack called IOpatch. This program SetFunction()s the exec OpenDevice call. The user puts this program in his startup-sequence, or otherwise invokes it, before he runs his application program. This patch will make a small window appear, whenever OpenDevice() is called, with a choice of units; 0-4. Unit 0 will select the internal serial or parallel port, and units 1-4 will select one of the newser.device or eightbit.device units. Please note that the names of both drivers have been selected to be the same length as the names of the original devices. This has been done to facilitate file-zapping as a last resort. Of course, software may be written for the newser.device or eightbit.device initially. A suite of simple test programs to check the I/O Expansion Board Hardware can save you hours of hardware debugging time. Chip selects, as well as read and write signals, are generated for all chips. One program simulates a very simple character-oriented terminal program for checking an ACIA. A nice little program to drive a real-time clock-calendar is also available. The clock hardware, based on the OKI MSM5832, is capable of generating interrupts at 1024 hz, once per second, once per minute, or hourly. Software to take advantage of this feature is left as an exercize for the student. Credits ======= I would like to thank Dan Babcock for the many hours he put in writing and debugging the serial device driver. This was surely one of the most difficult parts of this project. Paul Coward, of DigiSoft, provided us with the parallel device driver, no small achievement either. Jim Cooper, of The Software Distillery, made many helpful suggestions concerning software issues, and especially DOS compatibility, and helped us get up to speed. Bill Seymour provided invaluable help in layout and pre-production of the PCBs, and also provided design help. Finally, this task was made easier by the help and encouragment of Doug Sears and Grace Lavin. Conclusion ========== I think this is a pretty neat little hack. I also feel that it is simple enough that if I hadn't come up with it, someone else would have. It provides some much-needed additional I/O for the Amiga 1000 or 2000 at a rock-bottom price. If enough software becomes available to warrant it, I will try to set up some sort of software clearing house for use with this board. Keep an eye on BIX or my BBS, The Symposium, for any news. Meanwhile, I hope you enjoy using this board. And don't let the blue smoke out! ============================================================================= If you need to get in touch with me, here are some possibilities: BIX jblavin USENET jlavin@cie.uoregon.edu The Symposium My own BBS, (503) 935-7883, 24hrs, F8N1 The Puzzle Factory P.O. Box 986 Veneta, OR 97487 (503) 935-3709 The Puzzle Factory, Inc. | Jeff Lavin -- jlavin@cie.uoregon.edu Veneta, Oregon |------------------------------------- Voice : (503) 935-3709 | Remainder of signature line Data : (503) 935-7883 | under construction. .