jlavin@cie.uoregon.edu (Jeff Lavin) (12/12/90)
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.gomez@enuxha.eas.asu.edu (Jose L. Gomez-Rubio) (01/29/91)
I have both a '386 (running UNIX) and an Amy. On the '386, the NS 16550AFN UART chips have a 16-byte FIFO which greatly reduces interrupt overhead the '386 UNIX. I have it running with a serial driver that supports the FIFO buffer. Is there any reason why the Amy cannot support the 16550AFNs? I do fine with a HST at 19.2K baud.