hawk.ro / stories / Snoopy, HC-91 & Robotron

Snoopy, HC-91 & Robotron

The printer

One of the slightly unusual items in my collection is an old (East-)German dot matrix printer, Robotron K 6313. I like that it has an adapter that allows the use of typewritter ribbon (the old open reel style) instead of "proprietary" ribbon cassette. This means it can use any printer ribbon with just a little bit of effort. In fact it does have a printer ribbon on one of the reels and it is still usable (after who knows how many years).

The communication interface is user-replaceable and it supports both parallel, serial (V24), serial (current loop) and others. The only interface I have, however, is the serial V24 but with an unusual connector and the manual only lists the standard DB-25 connector. Surprisingly, I was able to find the pinout at www.robotrontechnik.de, thanks guys! I soldered an adapter and once everything was set the printer was working without any trouble.

And its partner

While the printer could very well print from a contemporary machine, somehow this wouldn't seem right. In my childhood I saw a similar printer used with an HC-90 computer (very similar to the HC-91 in my collection) and I think this would be a fitting pair. Similar ages and backgrounds, they had a history together. In fact, the IF-1 manual for HC even mentions this printer model (and gives a rudimentary pinout for that strange connector!) Of course, despite having a DB-9 connector, this interface has a completely non-standard pinout. The manual also gives an unusual description:

Original description from the IF-1 manual
1	- CTS (OUT)
2	- DTR (IN)
3	- RxD (OUT)
4	- TxD (IN)
5	- N/C
6-9	- GND

My description based on the IF-1 manual
1	- RTS (OUT)
2	- DSR (IN)
3	- TxD (OUT)
4	- RxD (IN)
5	- N/C
6-9	- GND

Some soldering later I had a triple headed cable, with a male DB-9 for the HC, another DB-9 male connector wired as standard DTE (computer) with RTS/CTS flow control (for interfacing with a regular PC) and another DB-25 male wired with DSR/DTR flow control, for the printer.¹ Of course, the cable is meant to be used with only two connectors at a time (it can be used to either connect the HC to a PC or the HC to the printer).

What to print?

My memories regarding this printer also included an editor program - Tasword - I think it was used at the time for printing learning materials. My first impulse was to use this and print a simple document. Although somewhat appealing, this didn't really fit, I wouldn't want to reduce the computer to a mere word processor. It has to generate something. The answer was... SNOOPY!

The Snoopy calendar program is written in FORTRAN, so I had to either rewrite it, or find a way to run it on the HC. I was able to find 3 compilers with documentation:

• Mira FORTRAN (Spectrum)
• Microsoft FORTRAN v3.43 (CP/M)
• Nevada FORTRAN v3.0 (CP/M)

The first one was quite the surprise but then again, there is also a C compiler for the Spectrum, so there's that. However, SNPCAL is too I/O intensive for a Spectrum compiler that has no disk support. This leaves only the 2 CP/M options.

Nevada FORTRAN

In fact I started with F80 but run into some difficulties, then tried Nevada FORTRAN and it proved somewhat easier. The first issue was that it threw lots of "label not found" and "improperly nested DO" errors. I eventually realised that it needed to be configured for larger symbols table as well as label table (run CONFIG.COM, choose 100 instead of the default 50). As an aside, I like that it has a separate LOPEN that will convert ASA control characters to regular ASCII upon writing.

Next, an issue with the pictures: all lines were shifted one character to the right, and since the first character of a line has special meaning (ASA control character) this was quite visible. After some debugging, I found the cause: the way SNPPIC is written, the program would pass over a DO loop that should not execute, since at that point its start value is greater than the end value. However, Nevada FORTRAN executes any DO at least once. Manual states (page 37):

Irrespective of the relation of the initial and ending values,
the DO will always be executed once.

With SNPPIC modified, everything seemed to be working, slowly. Avoiding file output (sending output directly to printer) did speed things up considerably.

A slight diversion

Content that I had something working, I went for more. In the ibiblio archive where the "original" SNPCAL was found, there is another Snoopy generating program called PICKET, that seems to better show off this setup, if only I could get it to work. However, PICKET relies on EQUIVALENCE statement and Nevada does not implement that. It was at this point that I went back to F80.

Microsoft F80

First issues with F80 and SNPCAL were that DIMENSION statement can't span multiple lines and CALL OPEN requires filename and extension (11 characters) without a dot and with padding spaces where needed:

C     This does not work with Microsoft F80:
      CALL OPEN(6,'SNPCAL.DAT',0)
 
C     The required form is:
      CALL OPEN(6,'SNPCAL  DAT',0)

Also, Logical Unit Numbers (the 6 above) for external files must be between 6 and 10.

As per the manual, LUNs 1,3,4,5 are preassigned to the console and unit 2 is preassigned to the Line Printer. It is not very clear to me whether those can be reassigned but 2 LUNs are enough for now. In fact, output to file is not really possible for this task since file output appears to be limited to 128 bytes records (as opposed to console or printer output that can go up to 132 bytes). Oh and by the way, DO can't use array values, so a temporary variable is needed.

When trying PICKET, I found that F80 supports EQUIVALENCE, even though it is somewhat fussy about its placement. ENCODE can only output to the beginning of an array (so a temporary array is needed). The main problem however, was that it didn't seem to read the data file correctly. I should note that both PICKET and SNPCAL abuse the language somewhat, by reading ASCII characters into multi-dimensional arrays of type REAL and INTEGER. After some experimentation I isolated most problems to FORMAT statements that are used for reading data. I think that F80's runtime uses only CR to separate records and as such, the following LF (CP/M uses CR+LF line separators) gets read into the array. Adding "1X," at the beginning of each format solves this problem.

The rest of the changes are related to PICKET being 136 characters large in places (both the printer and F80 are limited to 132), F80 not supporting more than 2 levels of parentheses in FORMAT statements and other minor things. I also refined and corrected the fonts, made the calendar start on Monday and added an option to choose language and output device (TTY/LST) at runtime. The modified version of both the program and the data are available at the end of this story.

F80 also converts ASA control characters to ASCII (at least when output is console or printer). After I was satisfied with PICKET, and having gained experience, I was able to adapt SNPCAL to F80 as well. And when compiled with F80 it proved to run much faster then the Nevada version.

Files

Note: Diskette images are in both raw (.DSK) and IMD formats. They can be written using either CPMIMG by George Chirtoaca (for the raw files) or IMD by Dave Dunfield for the IMD ones. To boot the HC using a CP/M diskette, enter the BASIC command PRINT USR 14446 after RESET.

• SNPCAL and PICKET sources and data
• HC bootable diskette with F80 version of PICKET and SNPCAL
• HC bootable diskette with Nevada FORTRAN version of SNPCAL

---

¹ Soldering DTR (from computer to printer) later proved to be a mistake: If the DTR input (on printer side) is low, the printer will not print anything sent to it. It must be left floating or high.

---

Published 2020-06-14 by Mihai Gaitos - contacthawk.ro