I won’t spend much time or space extolling the virtues of a “big” printer for your ZX/TS computer. Suffice it to say that a full-width printer can be the most useful investment you make since you first bought your computer. Such printers allow you to print full-width text and program listings in a variety of type styles and widths, on normal 8-1/2″ paper. SWN is produced on a ZX81 with such a printer; I also use it to write all my letters, mailing labels, cassette labels, etc. (For this re-edit, and in fact for SWN Vol, 2, we have upgraded to a daisy-wheel printer instead of dot-matrix; the comments here in LPRINT HINTS apply for the most part to these as well.) Unfortunately there are some myths circulating to the effect that hooking up such a printer is difficult and tricky; in fact, it’s not much rougher than using the TS2040, but there are some guidelines you should follow to get the most from your system.
First of course, you must decide on a printer. There are a good many decent dot-matrix printers available to do the job, from Epson, Okidata, Seikosha, Star Micronics, and others. Which one you choose depends on your budget, requirements, and tastes. Most manufacturers supply both an 80-column and a wider 132-column version; for most applications the 80-column type will be adequate. “Standard” features include double-width and compressed characters, an emphasize mode (each column of dots is struck, then moved half a dot and struck again, doubling the apparent resolution) and double-strike mode (each line printed twice). Also, rapidly becoming “standard” on most machines are block graphics and “special” characters (more about this later).
An important specification is the character matrix. The traditional “cheap” printers (including the awful Gorilla Banana) use a 5×7 matrix, adequate for caps but with funny-looking lower case letters g, P, q, and y. More recently, competitive printers have a larger matrix (e.g. 9×9 for the Star Micronics “Gemini” on which the original SWN Vol. 1 was printed) which allows “true descenders” or lower-case letters whose tails actually drop below the line. Alternate character sets (e.g. italics) are available on some, as are a host of other features, some of which are nice to have and others you can do without. Look at the type of feed allowed – competitive units allow both tractor-feed (for perforated “computer paper”) and friction-feed (for single sheets of bond, etc.).
But let’s assume you’ve compared price and specs and have found a printer you like. You also need a “printer interface” to connect the computer to the printer, as the T/S and the printer “don’t speak the same language,” and we need a “translator” to allow them to communicate. There are two types of interface, serial (RS232) and parallel (“Centronics”), in general use. Which system you’ll need depends on the printer you choose. Older printers (like surplus bargains, etc.) will probably be serial, but most of the designs currently on the market use the Centronics-standard type of parallel interface (though most have a serial option available at additional cost). Recently, serial ports are once again preferred, as the same port or ports can be used to service printers, modems, and other I/O peripherals.
In either case, as far as the ZX/TS is concerned, the function of the interface is to, 1) control the operation of the printer from the computer, and 2) translate the data from “Sinclairese” to ASCII (the semi-standard code used by the printer). It does this with a combination of hardware and software (usually on PROM) and generally uses the uncommitted 8-16K region of memory. So now you can tell the computer what to do, which in turn, via the interface tells the printer, which executes and (via the interface) acknowledges completion.
The reason I referred to ASCII as being “semistandard” is that while the codes from 0 to 127 are agreed upon, those from 128 to 255 are not. This is because originally most printers used only 7 bits, whereas modern machines generally employ all 8. As a result, what characters and control codes are placed in the high block is up the individual manufacturer, and may even vary from one model to another. This is where the block graphics and most of the special characters are. Interface manufacturers so far have solved the problem by avoiding it, though well designed units leave you the option of accessing these codes if you supply the appropriate translation routine. The two “biggies” at the time this article is written are CAI and Memotech, though there are others and we would welcome your comments, good, bad, or indifferent, if you’re using another brand.
I decided on the Memotech unit because it supports the T/S LPRINT, LLIST and COPY commands, whereas the CAI uses USR calls to perform printer functions. I find these USR calls more awkward to use, also they eat up more memory if your program calls the printer often. What I don’t like about the Memotech is that some printer codes have to be accessed in a roundabout way. Overall though, I’m quite happy with it, so this series of articles will concentrate on how to put Memotech’s CIF to work. Again, I’d love to hear from CAI (and other) users so we can balance things out some. An important thing to remember is that in general, the various systems are not inter-compatible. (Boy do I know about this! More about that later.) For example, if you get the Memotech, you won’t be able to use the CAI stringy-floppy at the same time. And so on, so decide on a system carefully as you’ll pretty much be locked into it.
Some 64K Rams Won’t Work
If you try to use Memotech’s CIF printer interface with 64K RAMs by manufacturers other than Memotech, you can run into problems due to conflicts, as the CIF unit occupies memory in the same region (8-16K) as the RAM. Memotech RAMs use a small ROM to do the block-switching/decoding necessary to use the I/F; by using this proprietary approach they help lock you into their system. On some 64K RAMs, however, including JLO’s and some others, it is quite possible to get the printer interface to work in harmony with the RAM.
First off, you’ll have to disable the 10-12K block of RAM to keep the RAM from fighting the CIF PROM which occupies 10-10.5K. The simple gate circuit shown below does this by inhibiting MREQ NOT when this block is addressed. You can now read data in the PROM without RAM getting in the way.
By adding lines to A10 and A9 as well, connecting them through inverters to two of the unused inputs of the LS30, you can narrow the “shutoff” to 10-10.5K, leaving 10.5-12K free for other programming or data.
On units that use ROMCS NOT, you’ll also have to diode OR the ROMCS NOT by placing a 1N914 diode in series, with the anode toward the RAM. (Thanks to John Oliger for this fix, which works fine on his 64K pack.)
Unfortunately, these simple fixes are not enough in the case of my little JRS 64K pack. Reports indicate that the same holds true for the Byte-Back UM64. These apparently use a different decoding scheme that inhibits proper CIF operation.
Memotech UK suggested linking edge connector pin 15A to pin 23A RFSH NOT. Doing this did not improve matters in my case. In addition this interfered with the proper operation of LDIR and LDDR into and from high memory.
If these suggestions don’t help, and if you’re not a consummate hardware wizard, you should probably consider getting another RAM (like JLO’s) which does work with CIF. But if you want a challenge, here it is: can you find a way to make other high-mem RAMs work with this I/F? This would be a boon to people who already have someone else’s RAM and would like to use the popular Memotech I/F. Hope my experiences have helped.
