Saturday, October 22, 2016

The Long road to Cromemco login at 19,200 Baud

For the last month I have revived my main 37 year old Cromemco computer system, upgraded it, and have been testing an exciting new Hard Disk interface, that I will document fully here, when it works 100%.

Once the system was stable I was using a ASCII screen terminal emulation using the well know putty emulator program, but putty was talking via a USB to Serial adapter over a serial cable to the Cromemco computer interface

At 9600 Baud.

I wanted faster, namely a reliable 19,200 baud.  But this is not possible using console interface, and so I started to implement a plan ....

What is Baud?
Follow the link if you must, but in summary 9600 baud is reckoned to be the speed 960 characters per second, or thereabouts. Baud rates are often used in the context of Serial Communications.

Serial Terminals and Computers
Before the Advent of [higher speed] Local Area Networks [LANS]  a character based terminal would be connected to a computer via a simple, 3 wire plus Serial Interface   (dubbed RS232)

On top of the 3 wires are handshaking signals, essentially the ability of either side to say pause, which confusingly can be done in several different hardware ways, and other control signals.

So back to the goal:
I wanted a faster rate so that my screen edits, and file listings, and general Vintage archiving could be performed faster

Cromemco and the TUART

At the time of release the TUART was a very advanced product.  It used 2 Texas Instrument Asynchronous Receiver Transmitters to produce a single S100 hardware card with 2 Serial and 2 Parallel Ports.

In fact years later the design and production was pretty much unchanged it was that good
Of course the later cards have some bugs fixes.   Here is a Revision E card that I fixed up, the higher picture is of one of the latest Revision H cards.

I'm sure you are asking.  Now where are all these detailed modifications details.   That would be on my website here.   Well obviously.

Just for interest here is the source code to the RDOS Resident Disk Operating System Monitor showing the Z80 source code to read a byte and also to setup the baud rate of the TUART.

Both the dedicated Cromemco TUART and the console port of the computer which actually is attached to the 64FDC Diskette Controller use the Texas Memory Systems TMS 5501 UART.  In regular mode it can only support Baud rates upto and including 9600 under Cromemco Cromix.

Cromemco Octart Card
By contrast to the simplicity of the Cromemco TUART card the Octart card was necessarily complex.

Cromemco had always been interested in Multi User computer systems.  In 1979 there was Multi User Basic and then their landmark Operating System called Cromix, released in 1980 was UNIXlike and by definition supported multiple users.

As such if the then Zilog Z80 and follow on Motorola 68000 processor was to perform useful work for more than one person there had to be a better way than continuously looking at the users keyboard input buffer.

A first step would be to make user input interrupt driven.  That is to say that the Processor can be doing useful processing for person A and waiting for input for say person B.   When person B presses a key an interrupt is generated so that B's keystroke is detected and processed, then control returns back to person A's program.

But another way was an even more distributed approach.

The Octart was a self contained Z80 computer with 64K of RAM (the maximum) and a 16K Byte ROM and 8 serial ports.  It was announced in 1982 and complimented well the newer Motorola 68000 based version of the Cromix Operating system that had initially been only based on the Zilog Z80.

The Octart card on its own could do the hardware handshaking with serial terminals.  It could buffer data and perform interrupt driven IO to the host Cromemco CPU card and thereby reduce load on the main processor.

Much later in the day it could also be used solely as a satellite processor.  On Cromemco, Motorola 68020 CPU cards there is no Zilog Z80 processor.  So in order to run Z80 programs based on CDOS, the CPM compatible operating system from Cromemco we can

- Repurpose the Octart to act as a satellite processor and don't use it for serial comms at all
- Load a special CDOS emulator into the Octart
- Have that run CDOS and when calls to Disk IO are required go back to the main computers' CPU and disk controller for assistance

Why this Tutorial
Somewhat late in the day I know but I found that I could get an Octart working for either multi port serial communications or for Z80 satellite processing.  But using 2 Octarts for one of each did not work as per the book.  Until I got it working thus:  So let's document it

Using 2 Octarts: One for 19.2K Serial and the other for Z80 Programs

Cromemco 68000 based computer system with DPU or XPU or XXU processors
2 Octart Cards
This worked example is for the XXU processor based system

Device Files

d /dev; ls -l zio* tty*
      0:0   C  1   rewa rewa rewa bin         Jan-19  1990  tty
      1:6   C  1   rewa --wa --wa system      Sep-23 21:32  tty2
      1:7   C  1   rewa --wa --wa system      Feb-06  2036  tty3
      9:0   B  1   rewa re-- re-- system      Oct-07 21:48  zio1

ls -l /dev/z*
      9:0   B  1   rewa re-- re-- system      Oct-07 21:48  /dev/zio1

Directory: /dev/z80
      9:0   B  1   rewa -e-- -e-- bin         Jan-19  1990  zio1
      9:1   B  1   rewa -e-- -e-- bin         Jan-19  1990  zio2
      9:2   B  1   rewa -e-- -e-- bin         Jan-19  1990  zio3
      9:3   B  1   rewa -e-- -e-- bin         Jan-19  1990  zio4

In UNIX or UNIXlike Operating Systems a device file is a file, normally in the /dev or sub-directory of /dev that is seen as a file by the user or program. So to write output to Marcus who is logged onto terminal 2 or /dev/tty2 one would just open /dev/tty2 as a file and write bytes to it.

It is usual for a device file to have a major and minor number. For tty2 as shown above this is major 1 and minor 6. Traditionally simple OS have a 'Jump table' which is basically a set of subroutine handlers for each device. Then inside the subroutine the minor device is passed as an argument.

In Cromix the Minor device number often relates in a direct or codified way to the port address of the hardware. So for tty2 for example the TUART would be address to hex port 60 often written 0x60 or 60H

We now need to consider what terminals are valid for the Octart. Cromix uses physical device names such as otty for Octart Terminal.

Determine Octart Device Numbers

I will be using connector J1

Each J connector can support 4 Terminals but you have to make an impossibly fiddle cable splitter. Without the splitter then the basic pins i.e. 2,3,7 for a single terminal appear in the right places. So without the splitter and using the 2 J sockets you could support 2 ASCII terminals.

Here is a splitter somebody else made for me in 1982. I hope it never breaks!

I calculate that since using connector J1 needs 16 + 8 = 24, and 16 + 8 +1 = 25 as minor device numbers since this is the 2nd character device entry point in the device drive table withing sysdef.

Major device is 2 so I created these devices using the makdev command

system[2] ls -l /dev/ott*
      2:24  C  1   rewa --wa --wa system      Feb-06  2036  /dev/otty1
      2:25  C  1   rewa re-- re-- system      Feb-06  2036  /dev/otty2

Operating System Reconfiguration
To reconfigure the expected memory size the Operating System can use or which device drivers will be loaded you need to configure the /gen/sysdef file. For our desired Octart terminal and Octart Z80 processing dual card option the final file looks like this.

%       XXU Cromix System Generation file

% System memory size:

        maxmem  16              % Amount of supported memory expressed
                                % in 256K units.

% Character devices:

        CDEV    01      utty 0                  % Required utty or tty
        CDEV    02      otty 4                  % Required otty
        CDEV    03      sysdev                  % System driver (required)
        CDEV    04      timer                   % Timer driver (required)
        CDEV    05                              % Suggested ulpt or lpt
        CDEV    06                              % Suggested typ
        CDEV    07                              % Suggested uslpt or slpt
        CDEV    08                              % Suggested sctp
        CDEV    09                              % Suggested oslpt or qslpt
        CDEV    10                              % Reserved
        CDEV    11                              % Suggested tape
        CDEV    12                              % Not used
        CDEV    13                              % Suggested qtty
        CDEV    14                              % Suggested sdd
        CDEV    15                              % Not used
        CDEV    16                              % Not used

% Block devices:

        BDEV    01      cflop                   % Cromemco floppy driver
        BDEV    02      uflop                   % Suggested uflop
        BDEV    03      allmem                  % Amem driver (required)
        BDEV    04                              % Suggested tflop 0
        BDEV    05      ramdsk                  % Suggested ramdsk
        BDEV    06      stdc 1                  % STDC driver
        BDEV    07                              % Removable part of SMD 0
        BDEV    08                              % Not used
        BDEV    09      zio 1                   % Suggested zio
        BDEV    10                              % Not used
        BDEV    11                              % ESDI driver
        BDEV    12                              % Not used
The highlighted lines support the Octart terminal at address 4

Magic Dip Switches
Not in accordance with the manuals that I consulted you need to set the Octart DIP switches like this

Octart setting for Terminals. Manual says its 0x9E 9E Hex

Dip Switches for the Octart being used as a Z80 processor. Manual says 0xCE CE HEx

Rebuild Operating System
d /gen
crogen cromix 201610.sysdef

68020 XXU 172   Link68 source 1.32
    CRC SET  68020 XXU 172   Cromix-Plus Operating System
system[18] ls -l cromix.sys
    114,908    1   rewa ---- ---- bin         Oct-08 19:31  cromix.sys


For Cromix 68020 version 172 these are the modifications to the system startup files

ty /etc/startup.cmd
mode amem xmm ec ic             % Turn on XMM and both Caches
mode timer gmt 0                % Time offset (hours) from GMT
                                % There is no need to run Flush anymore
mode -pa                        % Stop pause for screen fulls

% make a ram disk 2016 styly

ty /etc/iostartup.cmd | match -r "%"

/etc/ioload -r /etc/oct.iop oc4
/etc/ioload -r /etc/zio.iop io1

I always like to look at the error messages inside the binary, which I do on a real UNIX system using the strings command  (not available in Cromix).  Here is ioload

Usage: Ioload [-r] pathname {io1..io4,oc1..oc8}
@(#)ioload.c    1.8 (6/19/87)
AAr68020 XXU 172   Ioload source 1.8
Copyright (c) 1986 Cromemco, Inc.
IO processor is improperly addressed or not in the system
IO processor talking to serial line
No correct response from IO monitor
No response - IO processor is busy
Cannot get address space
@(#)doload.c    1.5 (10/14/86)
@(#)getcode.c   1.6 (2/9/87)

Terminal Logons
ty /etc/ttys

1:n     :console:M100   :system
1:19200 :otty1  :M100   :system
0:9600  :otty2  :M100
0:9600  :tty3   :M100   :system
0:a     :tty4   :dumb

Handling Screen Programs

In the early days an application would be able to write to a terminal screen not line by line, top to bottom, but around the screen, for example when using a Screen Test Editor or a Word Processor.

For Operating Systems like CDOS the application wrote the special sequences directly.  Example to clear the screen and position the cursor at the top left the application would write Escape [ 2 J  (4 characters).

But the catch is that every terminal manufacturer has a different set of Escape sequences.   So years later Cromix they borrowed from UNIX and introduced Termcaps.   You define your terminal in /etc/ttys.  So above we define that Octart terminal 1 is at speed 19200 Baud and is of type M100

Then in /etc/termcaps capabilities for your terminal are listed.  The Application, for example a Screen Editor uses the Escape sequences for your named terminal to write the correct character to the screen in the right place.  So in this way if you change your physical terminal, from say a DEC VT100 to a Cromemco C3102 you only need to change the terminal definition in /etc/ttys.  Further if your terminal is not listed in /etc/termcaps, it is a simple plain text file and you can use the technical manual for your ASCII terminal to generate your own terminal type.

Finally now is the time to test a reboot and see if things work correctly

Test Reboot
Like any decent Operating System you are able to test boot the Generated Operating System.  The bootable hard disk contains a small code segment that tries to load and execute /cromix.sys.   However instead you can use the boot command to boot the test Operating System.  When you have tested that it works fine you can subsequently move it from /gen/cromix.sys to /cromix.sys

d /gen
boot /gen/cromix.sys

System shutdown in progress
System shutdown complete
Address: Memory test by 16K blocks
000000h: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
100000h: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
200000h: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
300000h: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Floppy = 1, STDC = 6, ESDC = 11
Enter major root device number: 6
Enter minor root device number: 0

68020 XXU 172   Cromix-Plus Operating System
20161007 CRO172 XXU OCTART-4 ZIO-1

Checking a Few Settings once Booted

Here is the proof that the Octart is working. The second terminal is running and at 19200 baud. Wahoo!

# Mode Of terminal Port otty1

mode otty1

Octart Terminal 2:24
 ABortenable     Baud 19200     -BINary          BMargin   0
-CBreak          CRDEVice        DELAY     0     DELECho   R
-DIScard         ECho            Erase     ^@   -ESCreturn
-EVenparity     -FFexpand       -FNkeys         -HANDshake
-HUPenable       IMmediateecho  -INL            -LCase
 Length    24    LKill     ^U    NLECho         -ODDparity
 PAuse          -RAW            -SIGAllchars     SIGChar   ^@
-SIGenable      -SIGHUPall      -TABexpand      -TANdem
-TDelay          Width     0    -WRAParound

Some documentation on terminal modes.

Running Z80 Programs

ls -l /bin/z**
     16,265    1  Srewa -e-- -e-- system      Nov-01  1989  /bin/z80.bin

When a Z80 program is named to be run Cromix automatically calls the z80.bin program.  This communicated over the /dev/zio* device that you defined to the Octart.  Recall that the octart had a special program loaded from /etc/iostartup.cmd.  So the Octart is ready and waiting to run any Z80 CDOS or CPM program and pass back the output to the 68020 based Cromix.

One more time for curiosity I will look inside the z80.bin binary:

strings z80.bin
Usage: Z80 [-s] [-d device-pathname] program-pathname [program-arguments]
JSYS #%02lxH    %10l,d calls
Total        %10l,d calls
@(#)z80.c       1.8 (4/8/87)
Ar68020 XXU 172   Z80 simulator source 1.8
Copyright (c) 1986 Cromemco, Inc.
98Unexpected signal number %ld
@(#)syslc.c     1.6 (4/8/87)

Sim.bin CDOS simulator

The 68020 processor card is very rarely found on any Cromemco Computer. usually the CPU card is the DPU or slightly faster XPU. These cards incorporate both a Z80 and Motorola 680x0 processor. So they don't need an Octart to run Z80 programs. They can run them directly using the onboard Z80 and that is called using the sim.bin program

I stress that we don't use this program at all in our example but I'm just detailing it for completeness

Again I am curious to see inside the sim.bin binary for error codes. We see:
strings -n 4 sim.bin
CDOS SIMULATOR version 02.69
Copyright (c) 1980, 1982 Cromemco, Inc.
Illegal options for SIM
Cannot set user/group ids
Error during loading of the program
Batch not allowed
Unimplemented CPM jump at address %04.4xH
Out of signal stacks
Illegal CDOS call %02.2xH at address %04.4xH
Unimplemented CDOS call %02.2xH at address %04.4xH

ls -l /bin/sim.bin
      6,698    1   rewa -e-- -e-- system      May-19  1987  /bin/sim.bin

Proof running a Z80 Structured Basic

To proove that the Z80 is really running

Copyright (c) 1977, 1979 Cromemco, Inc.

>>print "goodbye cruel world": bye
goodbye cruel world

 ps -al
  PID State  UID  GID  Ctty    Pri  Base  Seconds  Command
    1   S     0    0   console   0    6d    1.430  p_one 1 0 0
   22   R     0    0   console   0    a0    0.810  shell -z
   23   S     0    0   otty1     0    a0    3.500  shell -z
   35   S     0    0   otty1     0    75    1.840  z80 /bin/

Checking running processes you can see that 2 shell processes are active and that on the octart terminal the program is running having being called by the program z80

Copy Files Back

d /gen; copy -f cromix.sys /

We are now happy that this Operating System build is good and so we copy this into the root directory so it will be used by default in the future


I did not show you all the failed configurations. There were many :-( I am just documenting what works

Note that for Cromemco UNIX (not Cromix) whilst an Octart can be used to provide high speed Serial terminals as we showed here, Octarts cannot be used as satellite IO processors. This means that whilst you can boot a 68020 processor into 'proper' i.e. traditional UNIX V.2 it cannot also run CPM or CDOS program which is a rather large disadvantage. Overall then Cromemco users might boot UNIX as a curiosity but it is not as practical shall we say as a traditional Cromix 68000 Operating system.

Summary This tutorial showed you how to setup your Cromemco 68000 based Cromix system to use 2 Octart communications processor.  The first we use to provide additional ASCII terminals and run them at the rather fast 19200 baud.

The second Octart is repurposed as an IO processor to be used to run Z80 CPM and CDOS programs.  This is necessary on this Motorola 68020 based XXU processor card because unlike its slower cousins, namely the DPU and XPU processor cards there is no onboard Zilog Z80 processor

LinksCromemco Card Revisions
Cromemco Octart Manual
Cromemco TUART Manual