16 Bit IMSAI-8080 System. A most satisfying project

The Unofficial CP/M Web site

The Retrocomputing Archive

The BD Software C Compiler (BDS C)

Harte Technologies IEEE-696 / S-100
Bus Documentation and Manuals Archive

Technology Systems Laboratories web
page dedicated to S-100/IEEE-696 Bus

Honorable Mention

CP/M-86 SOFTWARE REPOSITORY

John Elliott's homepage

Daves Old Computers

Gaby's Homepage for CP/M and
Computer History

Software Development Tools for Z80
Family

Chaos Cottage BBS CP/M file listing as of
17 December 1998

Michael Minn's MMCPM

Vintage Computer Festival

Technology Systems

Obsolete Technology Website

Altair Computer Club

DigiBarn computer museum

Herb Johnson, Retro technology history
and stuff

Getting your own S-100
System
Michael Louie of Micrcomputer
Solutions that was an authorized
CompuPro/Viasyn System Center is
probably the best source of new and used
CompuPro cards. If you are lucky he may
even have a complete CompuPro system
available for sale. I purchased four SPUZ
cards at a good price from him without
incident. He can be contacted via e-mail:
gohim <AT> att <DOT> net.

Hopefully you all know what <AT> and
<DOT> mean.

I learnt from Michael that CompuPro
IEEE-696 systems are still out there with
there 8 inch floppies drives doing good
work in surprising places like NASA and
certain area of the multimedia industry.
The primary reason is the large expense
involved in replacing the software
running on them. So certain people in
these industries are gobbling up certain
types of S-100 cards should any of their
existing cards failed.

Ebay is another good source for boards
and even systems. Just go to the Vintage
computer section and so search with the
keys S-100, IEEE-696, CompuPro,
Cromemco, ALTAIR or IMSAI. One of
those search should get you a hit for
S100 related stuff. Be warned, unless
stated otherwise be prepared to fix
anything you get on e-bay unless you just
want a paper weight.

Vintage Computer and Gaming
Marketplace. I recently found incredible
bargains here.

HAM Radio swap meets.

Electronic parts/components stores.
(Radio Shack has not been that type of
store for more than 40 years now) These
local stores are fading from existence as
the dumbing down of Americans
continues. But the stores you can still find
sometimes have refurbish hardware.
Usually radio equipment

comp.os.cpm news group is definitely a
place to contact people who could help
you find that special S-100 system.

Altair Computer Club . Watch this URL for
announcements about available systems

Your Company Name Here

16 bit IMSAI-8080 system.

IMSAI 8080 with 8088 CPU

click to enlarge image

Introduction
This project is probably one of the most satisfying projects I have worked on in many years; those
were my first thoughts and I said as much to myself at 8:30pm February 19th 2009 as I finally got
Concurrent DOS 816 (CCP/M 816) fully functional on the newly built system. For me there was a
very palpable sense of accomplishment.

The project started February 1st, 2009. My typical work day was between twelve to nineteen hours.
I probably put in about 300 hours in that short time researching all the details needed to make the
project a success.

I guess I was just having too much fun exploring the unknown, tempting fate that the project could
have failed for the sheer number of unknowns, such as the lack of documentation and finding
obsolete parts for boards that might have needed to be fixed.

Why would bringing back to life a thirty year old computer give such great joy and sense of
accomplishment? The answer is the project taxed nearly all my computer-related skills such as:
computer engineering, embedded device programing, operating system generation, system
programming, machine language programming, hardware debugging and in general good
research practices.

The original intention for the usage of the set IEEE-696 boards I had been collecting for a great
many years was to build a S-100 system and then port LINUX to it, fully demonstrating my
expertise in all levels of the LINUX kernel; including embedded LINUX device development. Then
a job requirement came along for FORTRAN. I thought how wonderfully symmetrical to end my
career in a company writing and porting FORTRAN code. In my mind I thought that old computer
language should only be used on old hardware. I had access to FORTRAN on my top of the line
LINUX box, but I wanted to relive the experience writing FORTRAN in the old ways via a
TeleVideo 950 terminal. Truly writing FORTRAN in the old way would require me to revert all the
way to punch cards. Can you imagine me with a punch card station and reader in my home?

FORTRAN was my very first programming language that I taught myself in high school. Later at
university I made money writing other students computer science homework. I was really good at
FORTRAN coding. In fact I was so good that a FORTRAN instructor became very suspicious when
he could not understand a complex set of format statements I used to produce fancy formatted
output for a group of my then student clients take home assignments. He offered the group of
students the option of redoing their homework assignment. Luckily he never made much to do
about who was writing their FORTRAN assignments.

It is interesting to note that apart from university it was not until very recently that anyone ever
asked me to do FORTRAN coding. The project was to port a set of C API's to FORTRAN. Until then
I really though that FORTRAN was a dead language. After "Googling" I now know better and dare
not say anything bad about it and suffer the wrath of FORTRAN enthusiasts

I had another fully functional Z80 based IMSAI-8080 running CP/M 3.x that I used to play, with
FORTRAN and other software and hardware, for my amusement. That system had a relatively
modern disk controller called "Super I/O Controller" by Harte Technologies, LLC that allowed the
use of EIDE hard-drives. The hard-drive to that system was filled to capacity with just about every
CP/M 80 program I could find.

The hard-drive on that system chose to fail no the day I needed to use the system for something
other than playing around --that is practicing FORTRAN 77. Worse yet, the Super I/O Controller
did not want to function properly after replacing the hard-disk. After much frustration and my faint
memory of modifying the firmware on the Super I/O Controller years earlier, I decided to build a
system exclusively with components that existed prior to 1982, leaving the Super I/O Controller for
a later project, perhaps to be used in my other Z80 based IMSAI-8080 system keeping the ALTAIR-
8800b pure in the sense I would only use S-100 boards exclusively from the late 1970's when I
rebuild the ALTAIR-8800b.

NOTE: Clicking on any of the images located on the left will give an enlarged view. The images
are high resolution photos that allow you to zoom in and get significantly detailed views of the
components.

NOTE: The text next to the images will take you to PDF documentation of the particular board.

The Project
This project brings to light several skills the typical modern computer professional and hobbyist no
longer has. Those skills are:

The ability to read and understand the Electrical Engineering theory of operation. You
need this ability in order to properly configure each IEEE-696 (S-100) board in the given
system.
The ability to understanding the timing characteristic between electrical components on
an S-100 board. You need to understand this when you debug a board using an
oscilloscope and logic probes.
The ability to read the electrical design schematic. This skill is a must if you happen to
need to debug the hardware. Trust me. Don't try fixing a board if you don't have the
design schematics. I wasted about 18 hours being able to get a board (not shown)
partially working using a probe and my understanding of how S-100 memory boards are
generally designed. NOTE: Don't trust 100% the schematics diagrams of these old
systems. Unlike many modern systems they seem to have been hand-drawn and subject to
some human errors. Always use the latest version of the schematics of any particular
board.
The ability to understand and write machine or assembler language code. In early
machines often the only language available was an assembler. You will note the blue
and red toggles/switches on the front of the IMSAI-8080. They are designed to put the
CPU into a state so as to allow the depositing of machine language programs (8088 or
8085 in my case) into memory to be executed. You then read the result of you program
by looking at the binary number as displayed on the front panel. -- the good old days
before terminals were affordable. Luckily I had CP/M 2.2 to start with.
The ability to write device drivers Interrupt Service Routine (ISR) and Direct Memory
Access (DMA) software and then regenerate the operating system (OS).
The ability to effectively use a soldering iron without destroying a circuit board or its
components.

The first task was selecting and configuring the boards at hand into a workable system. In addition
to having the manuals to many of the boards used in this system I found a number of other web
sites that had later versions of manuals --remember what I said about not trusting 100% the
schematic diagrams. Use them as a guide trusting them about 98% of the time. --that last 2% can
be very frustrating.

The initial set of boards installed onto the IMSAI-8080 S-100 motherboard are the CompuPro CPU
8085/88, DISK 1, System Support 1, Interfacer 4, and two RAM-20.

Dual floppy subsystem:
There was some difficulty in booting the system with a version of CompuPro CP/M-80 I discovered
I had. After cleaning the connectors to both QUMETRACK 842 eight inch floppy drives in the dual
floppy subsystem I was able to get the system to boot reliably.

It was at that time I discovered the B drive can only reliably read floppies; writing to a floppy sent
data into la-la land without errors from the OS. The A drive suffered from a minor mechanical
problem, It did not always eject the inserted floppy. As I worked with the A drive I realized when I
changed floppies the drive would not reliably write to the newly inserted 8" floppy.

Obviously, these drives needed to be repaired. However, I had a work around for these unreliable
drives. The solution was to manually configure the drives to swap roles in the boot process. That
quick and dirty solution meant I did not have to study the QUME manuals and spend maybe a
week making sure the electronic circuits on the floppy control board was in order.

NOTE: It was just recently I stumbled upon documentation to reliably mechanically align these
old 8" floppy drives using a n oscilloscope and some software. The oscilloscope I have. The
software to help in alignment I will probably have to write from scratch using Turbo Pascal or
Assembler.

At some future date either when the floppy drives completely fail or I have some free time will I
tackle the issue of properly aligning the drives. But for now I have a very usable system for
development when the M-Drive/H memory drives were installed.

Memory drives via M-Drive/H:
Only one drive being able to read and write is somewhat a painful proposition given the fact that:

Swapping out a floppy from the drive can cause write issues to the newly inserted floppy
unless the system was rebooted, which would cause memory to be reset, and loss of data.
The development environment I use tend to be on more than one floppy; Turbo Pascal
environment is my primary editor to do Pascal, Assembler and C coding.
Compiling C or Assembler code via floppy drive is slow even though it is fun watching the
lights on the front panel dance as data, status, and address bus changes --Turbo Pascal
allows all but extremely large pascal code to be compiled and run from memory without
ever saving to disk.

Throughout the years I set my sight on unusual S-100/IEEE-696 boards, I consider the CompuPro
M-Drive/H memory drive boards sufficiently unusual and have four of them. The four IEEE-696
cards allow me to have one drive that is 2 Megabytes in size. That is about the same as the
content of four different 8 inch floppies.

With that amount of space I am able to load everything I need for development from different
floppies into the memory drive and not worry when the system is reset. Only a total power down will
destroy the content of the memory drives.

I often have to reset the system when I am ready to save my work located on the M-DRIVE/H
because of alignment issues when I swap out floppies on the floppy-drive that still allows reading
and writing.

I tend to have top of the line LINUX and MS Windows systems for software development where I
expect the build time of code will not test my patience. I was very surprised and happy with the
build time of FORTRAN, PASCAL, and Assembler code afforded me by the M-DRIVE/H.

Parallel processing via SPUZ slave processor
To have an openMosix super computer in a home shows that the science of parallel processing
holds great interest and pleasure in how to effectively solve problems in using processors in
parallel.

Besides the SPUZ's, M-DRIVE/H, I have voice production and recognition, video, analog to
digital, digital to analog, phone answering boards. I even have a board that allows control of the
home/environment. What these boards highlight is the fact that conceptually there has not been
anything truly new in computer science and engineering for at least the past thirty to forty years.
This is my perspective on the state of the art. Only density of silicon and the waste of CPU cycles
has increased.

Think about it Object oriented, Declarative, and Functional programming has been around since
at least the late 1970's. Only rewrite theory via MAUDE seems new. Where is my HAL 9000 and
Colossus AI?

Being able to demonstrate parallel processing in such an old system via six SPUZ slave boards
and one CPU 8085/88 bus master would be cool thing to do, so into this system's bus they went.

Remember this is an IMSAI-8080 S-100 box. The IMSAI-8080 is not IEEE-696 compliant so I had
to modify some of the SPUZ bus connections in order for the SPUZ's to functional properly. I had
initially hoped that the modification done in 1998, to the IMSAI-8080 front panel, would have
been sufficient to allow unmodified IEEE-696 to function properly. The modification was a simple
cutting of a signal that was now a voltage input.

Software from the INTERNET:
Now that I have the system booting CP/M 80. I wanted to get development software other than
Assembler or Z80 machine language. There were a great many places on the INTERNET (see
links) to get CP/M software free of charge. The problem was how to get them onto the CP/M
machine when there is no file transfer programs available.

I wrote a utility program to transform the binary code of the CP/M programs into INTEL HEX
format. It was my hope that

PIP filename=CON:

would have allowed INTEL HEX formatted data streaming into the console would have been
saved to the file "filename".

No matter what baud rate I chose I was getting garbage entering the "filename". I even wrote a
small Z80 Assembler program that took control of the UART. That did not work either; the UART
receive data register would overrun.

The idea was, after spooling across the INTEL HEX formated data and force a <Ctrl-Z> to close
the file on the PIP command, I would then regenerate the binary with the CP/M development
tools. Although the idea seemed reasonable it just never worked in my case. Could never get the
entire INTEL HEX formatted data to spool across reliably in one shot.

XMODEM and YMODEM
Not being able to get the programs to my S-100 system I looked into using the
XMODEM/YMODEM file transfer protocol. A quick trip to Google and I had the documentation to
those protocols

Turbo Pascal to the rescue
I was going to write the XMODEM in Z80 assembler but I lucked out in that I found I had a version
1.x of Turbo Pascal and I was able to read the floppy that it was on. The only problem was that the
Turbo Pascal only generated code for 8088/8086/80286 CPU's. Turbo Pascal is a great tool to
avoid the writing of assembler code in the CP/M environment. There is a wide range of Turbo
Pascal API's that give you direct access to the hardware such as all CPU registers, ports and
memory. These features allow you to directly contact the CP/M OS, write ISR and DMA routines,
thereby bypassing the need to write in assembler unless you really need hand optimized assembler
code.

After studying the System Support 1 manual I was able to write XMODEM/YMODEM program in
Turbo Pascal that programmed and used the "System Support 1" UART while the console
displayed the status of the transfer via one of the "INTERFACER 4" serial ports. The program
polled the UART registers so the best performance that could be achieved was 2400 Baud.

An ISR based program probably would have given better performance but polling of the UART
registers was a nice quick solution.

Shortly after writing XMODEM I wrote a YMODEM program. So the 2400 baud did not seem like
an impediment; I would just start a YMODEM batch transfer and walk away. --LINUX YMODEM via
minicom seems to have a limit of 11 files per batch.

Into the 16 bit world via CP/M-86
Initially I did not carefully read the manual for the SPUZ boards, so my belief that I would be able
to use anything less than a 8088 processor to interact with the SPUZ boards was incorrect. The
SPUZ board are controlled by I/O ports above the 256th I/O port available to the Z80, 8085,and
8080 eight bit processors.

Even though eight bit processor boards I have are designed to give access to memory above 64K,
that memory primarily behaves as banked memory. The SPUZ needed the host processor or bus
master to access its RAM that was memory mapped above 64K in the host memory. So it was
necessary to configure the boards in the system to boot using the 8088 rather than the 8085
processor. Only the "System Support 1" board needed be configured in order for the CPU 8085/88
board to choose its 8088 processor over the 8085 processor.

CP/M-86 was now functional but MFORM, a program used to format the M-DRIVE/H based drive,
would lock up whenever I had more than three M-DRIVE/H cards installed. I figured it was just a
version issue so I looked around and discovered CDOS-816. It had a MFORM program.

A number of CDOS-816 programs first check their OS and version number before continuing to
execute. This did not seem to be the case for CDOS-816 MFORM.

Multiuser & multitasking via CDOS-816
CDOS-816 had a number of features that made it desirable to me. It was multiuser, multitasking
and even more interestingly it could run Z80/8080/8085 base CP/M-80 in an 8086/8088/80286
CPU CDOS-86 environment. Additionally it could run most early versions of MS-DOS programs.

With my YMODEM program it was easy but time consuming downloading all four disk of CDOS-
816 to the system. Once that was done I regenerated CDOS-816 for my unique environment.

An intriguing thing about the CCDOS-816 OS was how it hosted eight bit CPU code in a sixteen
bit CPU. It could either run an eight bit emulator OR send off the task to one of any sixteen SPUZ
boards located on the S100 motherboard. It is able to do this via two programs SW!.CMD and SPZ.
CMD.

The SPZ.CMD command is loaded and stays resident in memory. It should only be executed
once. The SW!.CMD seems to be the work horse program that some how manages to choose a
SPUZ slave processor that is not busy (that is it load balances), copies the CP/M 80 program to
one of the four banks of the 256K RAM of the selected CPUZ board and allows the CP/M 80
program to run seamlessly in the CDOS-86 environment.

I have not been able to locate the source code for SW!.CMD and SPZ.CMD. So the following
presentation is only to the best of my current understanding and based on my experiments.

The only thought I had about why you would have 256K on the SPUZ board was to allow the Z80
to execute code in one 64K banked memory undisturbed while the host or temporary bus master
processor load programs into the other three banks. It was my initial belief one SPUZ could only
execute one CP/M-80 program at a time, I have come to believe that this is not true from my
experimentation. It would seem that each SPUZ board is able to execute simultaneously several
CP/M-80 programs Right now I am guessing four per SPUZ, but this has not been confirmed.

There are a number of smart ways to allow one SPUZ to execute an arbitrary number of CP/M-80
programs simultaneously. Why does this intrigue me so much? The SPUZ only has a Z80H,
memory and a UART; no timer circuity of any sort to interrupt the Z80H for rudimentary multi-
tasking. The Z80H can only be reset by the host, so once it starts executing code in its memory it
runs to completion. Therefore task switching to another CP/M-80 program should in theory only be
possible on request of I/O to the host system. The SPUZ can only alert the host via a high priority
makable interrupt. --Vector Interrupt 0. I am guessing that SPZ.CMD is primarily responsible for
managing these interrupts.

Since I do not have the original code for SW!.CMD and SPZ.CMD (please someone out there tell
me you have the code and will send it to me) I was using the DDT86 debugger to trace the 8086
assembler code for SW!.CMD and then realized I was exceeding the parameters of the original
intent of this project. So this will remain for a later project.

Parallel processor via CDOS-816
A future project is to port the Message Passing Interface (MPI) to this platform after I fully
understand SW!.CMD and SPZ.CMD via DDT86.

It will be interesting to note how much performance I can squeeze from seven processors of a
thirty year old system. It is really a shame how wasteful we have become because of high
performance silicon.

The effort that will be involved in this future project will surly demonstrate and promote my skills in
being a better parallel processing developer.

FORTRAN
Ha .... :-) Thanks Richard, Ankur and Venky. If not for you guys I would not have so soon enjoyed
myself doing this project. It probably would have been another six to nine months before this
project saw the light of day in any form; that includes the LINUX the port to this hardware.

FORTRAN started this project before its time so I have several FORTRAN application to
demonstrate my FORTRAN skills. Hopefully I will be able to do one FORTRAN project per week.

Text based Casino Games holds more interest to me than the video versions. There is something
about holding the images of the game in my head than having some video game spoon feeding
me how the game should look. To that end every week at least one of the following games should
be completed. The first one to start. February 16th 2009.

Trente-et-Quarante
Roulette
Chimin-de-Fer
Craps
Blackjack

But first a bit of Probability Theory (link to be added).

Now I have to get back to the Colossus M1-20 project as my primary project

Turbo PROLOG
Turbo PROLOG had been for many years my favorite programming language until I found the
MAUDE programming language. PROLOG is often referred to as the highest level programming
language.

I found a complete copy it via Google and it seems to execute under CCDOS-816; but the video
display of its IDE output is being sent to la-la land. So either I research how the old 640x480 vga
cards worked and thereby mapping that graphic (hopefully) onto a TeleVideo screen via character
set graphics or a I get a S100 PC Video card; I think I would prefer a S100 PC-Video card.

Conclusion
I remember when growing up it was common knowledge (common knowledge to the people I
knew) how to build a car from scratch. Today you need an expert to fix your car should something
go wrong. Even worse, most cars have become a commodity that are discarded, thrown out, or
swapped before any real attempt is made to fix a problematic car.

Have cars become more complex and difficult to fix? In my opinion the answers is cars have
become more complex. But because of that complexity it is easier to identify the cause of a
problem and fix it; computer sensors everywhere. What seems to has happen is people became
lazy and therefore dumber about fixing cars thereby the creation of the so called expert repair
man.

I think a similar thing has happened to the computer hobbyist skills; that includes the computer
professional. Components have become so inexpensive that it is much easier to throw away a
computer board and now a whole computer ($399 gets you a nice mini laptop) than taking the
time to understand the hardware and fixing it.

My experience lately has been there are too many developers who know just enough to be
dangerous to some software projects. The reason is the usage of high level tools without
understanding how these high level tools work. I actually encountered a C++ developer with five
year plus experience who did not know C++. For those five years he was using a GUI system to
build his application. Only a very minor amount of C++ knowledge was needed to bind the GUI
application together. He was not looking to apply his C++ skills to system level application
development. --He did very poorly when tested.

The reason I don't have the same issues by using the STL, ACE, QT, WinForm and other high
level libraries is I have been around so long that at various points in the past I had to write some
variant of those high level libraries.

Again, if you really don't care to know how things work, the power of complex systems to simplify
your life will dumb you down. The result is a tremendous waste of resources; code bloat and waste
of silicon.

For the short term a good thing, but for the long run it will be devastating as observed on one
particular project I worked on at a major financial company on Wall Street.

Think about this a multiuser, multi-tasking, parallel processor system, with virtual CPU, and OS
emulation running in about 400 kilobytes or RAM, that allowed as many as sixteen or more people
to do their accounting, word processing, analytics etc simultaneously just because people had
such a fantastic understanding and limitation of the hardware and software environment.

A passing note:
Thanks to Pascal, Turbo Pascal in particular, I was forced learn how to write programs in a very
formal way and I have not to the best of my memory had a program fail because of programming
errors since 1989. Again to the best of my memory the only type of failure I have seen in any
program written by me was as a result of missing specifications. Even then my code would always
indicate that the parameters of the program had been exceeded.

I realized how influential Turbo Pascal was on me as I started to work with Turbo Pascal again. It
has been twenty years since I actually used the environment. After the first day of usage it was as if
I was still using it for months prior. After all these years I believe Turbo Pascal to be most elegant.
It is too bad it is falling out of popularity as the first programming language someone would learn.
It is sorely needed based on a number of the TYPICAL CS students I have met. I live within three
blocks of several universities.

These days I swear by C++, PROLOG, MECURY, and MAUDE. Compared to Pascal, PROLOG,
MECURY and MAUDE have a radically different approach to solving a problem. However the
discipline of Pascal is ever present. Perhaps that is the only reason I know none of my programs
have every failed as a result of programing errors in more than twenty years.

To me a funny story:
I was taking a technical interview via teleconferencing using VPN and my phone. It was for a C++
position but for some silly reason the two people, both of whom relatively recent PhD graduates,
wanted me to write a binary tree sorting, and tree traversal and fast find routines within an hour.
The limitation being to exclusively use C and C low level library routine; strcpy etc. During the test
these people were there watching over my virtual shoulder harping on how I was putting the two
subroutines together. Can you imagine the pressure I was under. As I was assembling the code I
noted that they had little idea how the code was coming together based on a number of questions
they kept asking. To them the assembly of the code was nonlinear. Not until near completion of
the code did they start to understand what I was doing. Happily I completed and tested the code
with time to spare. They all agreed that my solution was optimal and looked great, so I thought I
was sure to get the position. Later from the headhunter I learned that the one and only reason that
they did not hire me was they did not like how I put together the code. I really had a good laugh at
that comment because even after looking over the code and testing it they did not see an error in
one line of code. Although a typographical error on my part, it would have caused the tree lookup
to fail under special condition. I realized this after I had been congratulated on successfully taking
the test and disconnected. (I executed the C code in my head. I use to be quite good a executing
FORTRAN code in my head. In old the days you had to do this since it was so time consuming
punching a deck of cards and submitting it to be compiled and tested.)

My recent re-exposure to Turbo Pascal made me realize that what they thought was nonlinear
assembly of code was in reality an application of the very linear discipline enforced by Pascal
coding development. The nonlinearity only occurred because they could not see most of my
coding was being done in my head and only pieces of the final solutions were being placed into
the IDE.

Again, that is probably the only reason my C++ code never suffers any programming error. The
only failures have been those that exceed the known specification at the initial writing of the
code. Even then my code always notifies you that you have exceeded the specifications.

For a price I am willing to take on anyone who doubts my ability. These days programming C++,
PROLOG, or MAUDE is really second nature as is the English language. I am actually cheating a
bit adding PROLOG, MECURY and MAUDE to the mix. Unlike imperative Object Oriented
Programming languages as C++ the specification is the program :-D

Maybe I should not have said that since I screw up my written English all the time...LOL!

Any takers? :-)