204 lines
10 KiB
Plaintext
204 lines
10 KiB
Plaintext
|
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.
|