»8N • «T4«-IU1
THE COMPUTER JOURMAL
ror Those Who Interface, Build, and Apply Micros
l»su« Numb«f 22 Jonoory— February, 1 966 S2.30US
NEW-DOS
Write Your Own Operating System pages
Variability In The BDS C Standard Library
Porting BDS C To CP/M 86 page 21
The SCSI Interface
Introductory Column To A Series pageis
Indexed Sequential Access Method Files
Using Turbo Pascal ISAM Files page27
The AMPRO Little Board Column
The Computer Corner pagese
page 42
The Computer Journal / Issue #22
THE COMPUTER JOURNAL
190 Sullivan Crossroad
Columbia Falls, M or) tana
59912
406-257-9119
Edltor/Publlsh9r
Art Carlson
Production Assistant
Judie Overbeek
Circulation
Donna Carlson
Contributing Editors
Nell Bungard
C.Thomas Hilton
Jerry Houston
Bill KIbler
Rick Lehrbaum
The Computer Journal* Is a bimort-
thiy magazine for those who Interface,
build, and apply microcomputers.
The subscription rate is $14 for one
year (6 Issues), or $24 for two years (12
Issues) In the U.S. Foreign rates on
request.
Entire contents copyright © 1986 by
The Computer Journal.
Advertising rates available upon
request.
To Indicate a change of address,
please send your old label and new ad-
dress.
Postmaster: Send address changes
to: The Computer Journal, 190 Sullivan
Crossroad, Columbia Falls, Montana,
59912.
Address all editorial, advertising and
subscription Inquiries to: The Com-
puter Journal, 190 Suiilvan Crossroad,
Columbia Falls, MT 59912.
Editor's Page
Restating Our Objectives
When I started TCJ, I wanted to
stress the fact that we would not be
publishing page after page of
product reviews on the latest
spreadsheets and appliance-type of-
fice systems. My intention was to in-
dicate that we would cover subjects
of interest to those who had to im-
plement and interface the systems,
but not for the end-user who only
wanted an appUance-type machine
and who was not interested in the
how and why of making the com-
puter work. But, as pointed out in
Wilkinson's letter in this issue, it
sounded like we were 0^fLY in-
terested in measurement and con-
trol.
This is definitely NOT the case!
What we are interested in is under-
standing the hardware and software
so that we can make the computer do
whatever it is that we want it to do. I
don't want a computer in a sealed
box with canned programs that does
something the way some 'experts'
decided that I should do it. I want to
tear into it and make it do what I
want, the way I want to do it. For my
applications this involves hardware
construction, programming, and a
lot of interfacing to physical devices.
One of the big stumbling blocks has
been the necessity of working around
the limitations of an operating
system— but with Hilton's series
starting in this issue that problem
will also be solved. I'll talk more
about that a little later.
With this issue we are starting sec-
tions on the SCSI interface,
programming in C, writing your own
operating system, Ampro SBC user's
support, and continuing the Turbo
Pascal series with an article on
ISAM files, plus The Computer Cor-
ner and other goodies. We have a
number of excellent articles on hand
and in progress for future issues, so
our coverage will expand and im-
prove.
Write Your Own Operating System
As Tom Hilton points out in his let-
ter, what the user sees is the ap-
plication program and not the
operating system. In a well written
program the user should never see
the system prompt or have to deal
with the system— if he does he
should criticize the program and not
the system. It is only those of us who
program and implement systems
who should have to deal with the
operating system directly.
I have had a love/hate relationship
with CP/M because it does some
things so well while doing other
things very poorly. I finally got ZC-
PR3 running (it came installed on
the Ampro 122), and it eliminates
most of CP/M's limitations. But I
won't be satisfied until I fully under-
stand exactly what the OS is doing
and can mocUfy it to do what I want.
In order to control the computer we
have to be able to control the OS, and
Hilton's series on NEW-DOS starting
in this issue is exactly what I was
looking for.
".... SCSI interface pro-
gramming in C, writing
your own operating
system, AMPRO SBC
user's support ...."
Even those who use other systems
should follow the series in order to
understand what a system
does— and they can envy CP/M
users because we can modify our
system. By the end of the series we
will be able to write our own OS with
the features we want, without paying
any license fees or depending on an
unresponsive company for support.
TCJ will organize a user group to
support NEW-DOS so that we can
help each other. We realize that
there are other systems, and MS-
DOS may be the best choice for some
uses, but a disk-based OS which we
can create and modify gives us great
o[^rtunity to learn and grow.
(Continued on page 49)
The (Computer Journal / Issue #22
Using C
I read with interest your editorial
in Issue 21. It is possible to get most
of the things you wish using some C
compilers (plus add-ons) but unfor-
tunately, the BDS C compiler does
not support them. Many C compilers
support the pre-processor directives
#asm and #endasm. The use of these
directives allows the programmers
to include in-line assembler code in
his or her C code. When the pre-
processor finds these directives, the
code is marked so that it will not be
optimized during the optimization
pass on the compiler (if this pass is
present). This is a great im-
provement over the method which
you have to use with BDS C. In terms
of "flash compiling", it is my im-
pression that this could only be done
using a single pass C compiler (with,
of course, a built in editor). The
problem with single pass C com-
pilers is that they are sensitive to the
order in which #define's are listed in
the code. If several #define
statements refer to each other and
are incorrectly ordered, a single
pass compiler could end up with
unresolved references, which would
halt compilation. A good alternative
would be the use of a C interpreter,
several of which are now on the
market (although I believe all of
them are targeted at the IBM PC en-
vironment, rather than CP ) . These
generally have built in editors which
will point back to the source code if
syntax errors are found (similar to
Turbo Pascal's editor). They are
also generally syntactically com-
patible with major PC C compilers
(Lattice and Microsoft compilers
and occasionally some others). The
problem here is that you are set back
the price of the interpreter (which
can range from $100.00 to $500.00) , as
well as the cost of your compiler
(which, for Lattice and Microsoft
are not cheap).
Don Howes
Pullman, WA
Is CP/M Dead?
Is CP/M dead? Are hammers
dead? Are nails dead? Is cooked food
a thing of the past? There are some
questions we writers should not
dignify with an answer, and would
not, if it weren't so much fun !
To be quite honest, I never saw
pure, virgin, CP/M until I just had to
see what it looked like. Pure CP/M is
an option on the Ampro Series 100
systems. When I first booted it, I
thought my terminal program had
gone into high orbit (again). The
point is, who uses pure CP/M? If
CP/M is dead, then it has been dead
for a long time, and will be dead for
decades to come.
It is only we masochistic system
programmers who ever see CP/M.
We are the only ones who appreciate
it, albeit in a love/hate relationship.
What the user sees, and com-
municates with is the Console Com-
mand Processor, (CPP). While it is
a part of the standard CP/M Disk
Operating System, (DOS), it is
seldom allowed to remain as Digital
Reseach intended it. Perhaps the
greatest gift to computerdom was
Richard Conn's ZCPR, a CPP
enhancement.
I began computing in an industrial
world. The king of the space
program was the RCA CDP1802
microprocessor. This was a CMOS
chip, and has been available literally
for decades. People are just now
discovering CMOS technologies,
though few really understand them.
Hence, my perspective is that of
machine intellect, robotics,
satellites, and deep space probes,
where the machine must fend for it-
self.
My world does not generally in-
volve spiff y graphics displays,
though I appreciate that type of
programming genius. Nor does it
generally involve complex
mathematical process. I am, after
all just a lowly chip mechanic.
As I entered into the world of con-
sumer computers I was spellbound
by all the nifty features of CP/M
machines. After about an hour I had
to say to myself, "this is neat, but
how do I get to the system, and will
all of this spiff get in my way?" With
the exception of the Ampro Z-80
machines, all that spiff did get in the
way. Ampro allows me, the
operator/developer, to decide how
much spiff I want.
These days I design systems for
the disabled community. These are
challenges greater than the space
program, and demand the highest
technology. I need a system that I
can tailor to the specific needs of the
individual. Not only must I be sure
that the system may be used by the
individual with ease, but it must be
reliable.
Now then, for the casual operator,
CP/M does not present a great deal
of flash, nor pretty noises. It must be
remembered that CP/M was
designed as a business workhorse.
For a person who just operates a
computer, or perhaps plays with an
assembler, CP/M type systems have
little to offer. However, it is this type
of computerist that is the most vocal
in what has been termed, "The DOS
WARS." When running an ap-
plications program, the operator
never sees the operating system,
only the applications program.
These vocalists are judging the per-
formance of these programs, not the
operating systems. But, as I think of
it, these people do not read TCJ
either, but dough-files, or BC
Weekly.
The best thing about CP/M type
hardware, as opposed to the CP/M
operating system, is that there is a
reasonably standard way of doing
things. If I didn't have a fully
debugged set of routines to handle
the disks, and terminal, I'd have to
write them. That is just the reality of
computing.
In my work I use equipment
designed to run CP/M. There are a
number of reasons for this choice.
First, is the price. Thousands of
people are maimed daily in
automobile mishaps. When a
disability strikes money is an issue.
In other fields, it is the same con-
The Computer Journal / Issue #22
cept. The boss wants the lowest cost
technology that will do the job. A
large amount of CP/M hardware is
unuseable. Were it not for the way
the Ampro systems allow you to
modify the operating system, I
would have designed a similar
system to run MY operating system ;
not CP/M, an operating system to do
a specific task. CP/M is no longer a
mystery. Those who know hardware
generate operating systems for
special tasks. You can't do that with
the PC clones without new ROMs,
higher end costs, and complexity. As
a matter of fact, TCJ will be doing a
series on how to design your own
operating system for Z-80
technologies. Why buy a DOS when
you can write your own to do what
you want it to?
As the American market turns fiu*-
ther towards the 16, and 32 bit
technologies, the Japanese will in-
vade the CP/M world. They may caU
it something else, but has anyone
been noticing the number of very low
cost Japanese CP/M systems on the
Market? As with most things the
Japanese will take our left-overs,
perfect them, and sell them back to
us. This is like selling an Eskimo
snowballs. But, they keep on doing it,
and we keep going for it. Take the
HD64180 superchip. It is nothing but
a souped up Z-80. Some say its only
real advantage is being able to ac-
cess more memory. Fine, I can live
whith that easily.
The bottom line is that, from the
machine level, or "the other side of
the screen," as I like to say, there
just are not systems as easy to work
with for the price asked.
Creative Computing published a
list of "The World's Worst Com-
puters," in an article by that name.
The IBM PC headed this list, with
PC clones coming in second, and the
IBM PC JR. takii^ third. Comments
ranged from "user hostile," to "an
uninspired design..." I happen to
agree with all of the negative com-
ments about 16 bit machines, and
agree with but two positive commen-
ts: they do crunch numbers, and
they do have neat graphics. The
prices being asked for these
technologies are near criminal. The
sophistication, for most board level
projects, is like putting airbrakes on
a turtle.
Now what would I want for
Christmas, had I all the money I
should want to spend on computers?
A Sanyo MBC-775, (Japanese por-
table PC clone), the Borland "Turbo
Jumbo Pack," and a program to do a
"school newspaper." Now what
would I do with this $5000 Christmas
package? Why develop applications
for the Ampro Z-80 Little Boards,
and The Little Board '186! I need a
compact portable for many personal
and professional functions, to use as
a terminal, and a 16 bit machine to
run the fuU Borland Package.
Is this hyprcritical, or at best
treason? I don't think so. Tools are
tools. My personal, and applications
programming productivity would be
increased 4000% with the Borland
package, especiaUy when applied to
the Uttle Board '186, if I could afford
all this. Why a Japanese clone in-
stead of buying American? The
Sanyo, in my opinion is a superior
implement, cheaper than any
American model, and has a color
monitor built-in.
The key concept is that tools are
tools. For most of my work the Z-80
systems are the best for the job, and
of the lowest cost. I can work with
them. Just by the way they are
designed, and constructed the IBM
machines are not all that great for
board level systems, except for
building super computers. Their cost
is nearly double that of the Z-80
systems. From an applications
progranmiing perspective, however,
more is available for the IBM types,
and I want the full Borland Toolbox
series. So, on the "operator's side of
the screen," I'd like the Sanyo Clone,
for personal and program develop-
ment. For the mainstay of my work,
however, I prefer the single board Z-
80 systems, especially the Ampro
Little Board. Many clients, knowing
no better, want the IBM systems,
just because their neighbor, the used
car salesman, said his brother-in-
law's sister's cousin heard they were
good. The key point is that each are
tools with specific functions, and
people who don't really know better
are demanding systems that are
IBM compatible.
Is CP/M dead? Perhaps, but the
systems that run CP/M, and will
tolerate a user's version of the DOS
will be with us for decades to come.
Is CP/M dead? Who cares, as long as
the hardware that will run it keeps
getting cheaper? The only problem
with hardware that will run CP/M,
and CP/M itself, is that tht skill level
of users is dropping, and the desire
to learn is nonexistent. The popular
trend is to serve the computer, not to
have the computer to serve you.
When viewed in this context, the en-
tire issue is stupid, in my opinion.
Tom Hilton
More on Soldering
I was reading Mr. O'Connor's ar-
ticle about soldering in issue #20, and
I'd like to mention a couple of points
he missed. It's an exceUent piece,
with more useful information about
soldering (and clearer explanations
of what's going on) than I've ever
seen in one place before ; but ever so,
there are a few more details that a
potential kit builder might find
useful.
For example, iron-plated tips for
the soldering iron— why are they bet-
ter than plain copperf They're a lot
more expensive— are they worth it?
Yes, because they don't have to be
cleaned, scraped and re-tinned
nearly as often. In fact, Mr. O'Con-
nor hardly mentioned tinning the tip
at all— and that can make a big dif-
ference in the efficiency of heat
transfer.
About flux— first, the name. Mr.
O'Connor's explanation was ex-
cellent, but he left out one important
point: the reason it's called "flux" is
because it makes the solder flow
over the surfaces being soldered.
Soldering flux is primarily a "wet-
ting agent" for metals. Just as soap
or detergent helps water to coat and
cover a surface, instead of clumping
into little beads and droplets, flux
helps the solder to make a thin,
penetrating film over the metals
being soldered: this improves heat
transfer during soldering, and
provides for more and better metal-
to-metal contact (which means bet-
ter electrical conduction) .
Rosi-core solder is very
useful— but don't sneer at paste or
liquid rosin fluxes (NOT acid
fluxes), old-fashioned though they
may be. For an experiment, try tin-
ning the end of a piece of stranded
wire (coating it with solder, to make
it more manageable before connec-
ting it to a terminal in a tight place) ,
First the usual way, by simply
The Computer Journal / Issue #22
heating the wire and applying rosin
core solder; then do the same again,
but put a little paste of liquid flux on
the wire before you start. You'll find
that the added flux makes for a
much neater and quicker job, and
also requires less heat from the iron.
Only a teeny tiny bit of flux is
required (more will just make a
mess) ; but the difference it makes is
tremendous!
One final, but very important
point: about why (and when) you
need to clean the flux residue off af-
terward. They tell you that rosin is
non-conductive... but that's not quite
true. It's non-conductive, compared
to a piece of wire; but compared to a
ten-megohm resistor, it conducts
quite nicely, thank you !
For instance, if you're trying to get
a long time delay in a 555 timing cir-
cuit, by using a fairly small
capacitor and a very high resistan-
ce, you had better clean off all the
flux when you finish— or the conduc-
tivity of that "non-conducting" flux
may upset your calculations con-
siderably. Or if you're working with
CMOS ICs, you may find that current
leakage from one of the power suply
pins to an adjacent input pin,
through un-removed rosin flux
residue, can shut down the circuit
entirely!
In short, whenever you're working
with high resistances or low curren-
ts, you had better clean all the old
flux off the board before you power it
up, or you may find a nasty bug in
your circuit!
Jock Root
L.A.,CA
Z SETS YOU FREE!
Z Operating System, an S-bit OS that flies) Optimized HO64I80/Z80 assembly language
code — full software development system with proven linkable libraries of productive
subroutines — relocating (ROM and RAM) macro assembler, linker, librarian, cross-
reference table generator, debuggers, translators and disassemblers — ready to free
youl
High performance and flexiDnitv-i Producnviry (esulis from dynamically customized OS e'^v-iron-
rnenis matching operator tasKs and rriachine
Keai-time control kernel option allows quick software development for industrial control
applications otner tools and utilities for office desk-top personal computing functions, local area
■■e^^ork^ to Einemet, AppieTalk Omnmet '\rcNei, PC -Net (Syteki — 'rorr mice to mainframe
. ; mmand coniro: and communications DisiriDuted processing application programs are easilv
developed
• ExtrerTie organizational flexiDtliry eacri directory anotner environment
• Multiple Commands per line
• Aliases (complex series of commands known by simple namesl Ann va'.aoie passmg
• Named Directories with absolute password securii>
• Full-screen command line editing witn previous command recall and execution
• Shells and Menu Generators, with shell variables
• Command-file search Paths, dynamically alterable
• Screen-oriented file manipulaiion and automatic archiving and backup
• 512 megabyte Me sizes 8 gigabyte disks handled
• Auto disk reset ^»vhen changing floppies
• TCAP database handles characteristics of over 50 computers and terminals
more easily added
• Tree-structured online help and dcxumentation subsystem
• 76 syntax-compaliDle support utilities
Your missing link has been found — Zl Now fly with eaglesi Fast response, efficient
resource utilization, link to rest of computing world — shop floor to executive suite.
micro to corporate mainframe. Call 415/948-3820 for literature.
^m •
Echelon, InC* tOIPirsI street • Suite 427 • Los Altos. CA 94022 • 41S,94»-3820
FORTH
Bill Kibler: I have just read your
Computer Comer column in issue #17
and I am interested in your idea of
building a Z-80 FORTH unit. I am
currently learning 64 FORTH from
HES on my Commodore 64 and
would like to put FORTH on a Z-80
board that I have already built.
I became interested in FORTH
because I work with elevators which
are rapidly becoming computerized
and FORTH seems perfectly suited
to this fleld.
Any columns on Z-80 FORTH
would be greatly appreciated. As
usual, you and everyone at The
Computer Journal are doing a great
job.
O.K.
New York
Data Acquisition and Control
I enjoy reading your informative
journal. Mr Jerry Houston's article
on analog data acquisition and con-
trol systems was especially in-
teresting to me.
I wonder if he and/or others might
be interested in elaborating on ac-
tual applications of ADC units, such
as those mentioned in his article. As
you know, some of these devices are
relatively inexpensive and most can
be interfaced through RS-232 with a
number of different micros. In my
opinion, they present a unique oppor-
tunity for us who interface micros
with the real world. I am sure that a
number of your current readers and
potential new subscribers would be
interested in this area.
Thanks for your efforts on editing
and publishing The Computer Jour-
nal.
Matthew K. Rogoyski, Ph.D.
Hotchkiss, CO
( Continued on page 38 )
The Computer Journal / Issue #22
NEW-DOS Write Your Own Operating System
Part 1: The Console Command Processor
by C. Thomas Hilton
We Listen to Our Readers
A number of professional readers have written to
request more technically based articles. While these
readers may be professionals, who use computers in their
work, they may not always be computer professionals.
Most often they use their systems to interface an ex-
periment, or just require more control over their equip-
ment.
We have all heard of the "DOS WARS." Of those
professional computer users who have made comment,
most have stated that the 16 bit systems "have more
features." Most however resent the higher cost of 16 bit
systems.
The point of issue is not which operating system is the
best. The user does not communicate with the operating
system directly, but through a Console Command
Processor, (CCP), which translates human commands
into computer based functions. Hence, the number of
"features" seen is a product of the CCP, not the operating
system.
In this series we will be discussing how to modify your
system to meet your specific needs, or desires. Because
of their price, and versatility, we will be targeting the
Ampro LITTLE BOARD* series of Z-80* machines.
Users of other, or existing, systems may follow these
discussions and implement the projects. The only project
series that non-Ampro users will not be able to im-
plement will be the custom Basic In/Out System, (BIOS),
which is hardware specific. The BIOS we discuss may,
however, serve as a model for implementation on non-
Ampro systems.
We will open our discussion with the CP/M* type CCP.
Some users have either purchased the Ampro "FRIEN-
DLY"* operating environment, or purchased an Ampro
Series 100 system which has ZCPR3 installed for use.
Others may have purchased the "Z" System* from
Echelon. We will term the ZCPR3 systems the "top of the
line," as far as enhancements are concerned. On the
other end of the scale is standard CP/M, which is
available as an option with all Ampro systems. It is with
the stock CP/M system that we will be^ our discussion.
In this series we will develop a system whose function is
mid-way between ZCPR3 and standard CP/M. The best
part of our system will be that it is ours, not someone
else's. Our system will require neither extra system
memory, nor support files on disk for proper functioning.
The Standard CP/M System - Structure and Terminology
Figure 1 shows a standard CP/M memory map. (A
memory map shows where various portions of the system
are located in memory.) In hexadecimal, ("hex")
notation, as applied to an 8 bit system, memory locations
form a four character representation. In hex, memory is
defined as a series of "lines," and "pages." A line is a
smgle digit code, or "byte." A "page" of memory con-
sists of 256 lines of code. The number of lines being
referenced occupies the two "least significant digits" of
the hex representation. Hex is read from right to left. The
number of pages is represented by the left-most two
digits, or 'most significant" digits. Each pair of digits is
capable of a single byte value, of 256 elements. Each
numeric representation begins with the number zero.
BASIC IN/OUT SYSTEM (BIOS)
: STANDARD CP/H DISK 0PERATIM6 SYSTEM
Con«ol» CoM^nd ProcMmor (CCP)
Tr«n«i«nt Proqrmm iUnmr Proqrmmt
(D*p«nd«rit IJQon Anount of Mnwiry)
BIOS and CP/M Hark Af-»«, P*9« Zmro
FFFFH
EEMH
_nv 5y«t»
_nv Sv«t.
"V 3y.t.
D7FFH (End o* n^)
(Start o4 TPAI
(Start Of w.i« Yi
Figure 1 : CP/M memory map.
Figure 2 shows the basic hexadecimal number system.
For most people it is easier NOT to attempt to translate
the hex system into decimal. The key thought is that, in-
stead of ten fingers, we now have 16 fingers. The number
system works the same as the more familiar base ten. We
start at number zero and count to 15, or "F" before star-
ting a new, left-most number colunm.
• Ih
P*
lln«« or bvt««
•quals th« <ir«t tin«.
or byt* o* p*9« zero
Th« «tandard h*x
praqr*«stan i«
• - a
1 • ■
2 - C
3-0
4 - E
3 - F
Figure 2: The HEX numbw system.
This brief introduction to the number system is
inadequate, but will have to be enough. Supplemental
reading is suggested for all parts of this series.
The structure of the operating system is very straight-
forward when related to the memory map in Figure 1. In
"the attic," of our microworld, or top of memory, is the
BIOS. The BIOS is responsible for all hardware depen-
dent functions. That is to say that the BIOS handles all
transfer of data, in and out, on a byte by byte, or charac-
ter by character basis. As the CP/M type operating
systems may be run on any number of different com-
puters some means of compatibility was needed. The
BIOS begins with a 'jump table" to each of its internal
The Computer Journal / Issue #22
functions. Each of these functions is implemented in the
fashion required by the hardware specific to the concer-
ned computer. We will deal specifically with the BIOS in
a future portion of this series.
Underneath the BIOS is the Disk Operating System, or
'DOS." The DOS may be said to handle the system in a
form which is system independent. It does not know, nor
care, what the system specific hardware is, nor looks
like. All the DOS knows is whom to 'call" to perform a
specific function. It is dependent upon the BIOS for all of
its tasks. The BIOS, again, works only in the most
primitive terms. The DOS, however, works in multiples
of these primitives to accomplish a task. As an example,
to print a string of text the DOS sends the string to the
BIOS a character at a time, who sends each individual
character to the terminal, or other hardware. To assure
that a program will run on other computers program-
mers perform tasks by making function calls, or
requests, to the DOS, instead of the BIOS. As the DOS is
the same for all machines, though the bios is not, com-
patibility between differing systems is had. A program
may, however, make function requests of the BIOS by
calling the jump table at the start of the BIOS. The jump
table must remain in the same relative position for all
systems. The DOS assumes function addresses to be in a
given sequence, relative to a given starting address.
Beneath the DOS is the CCP. It is the job of the CCP to
interpret the human's commands and perform simple
tasks with files stored upon a disk. The standard CCP is a
very simple minded fellow, at best. We will add a number
of functions to the CCP. Our main focus will be, however,
to show you how to add your own special commands and
functions.
In "the basement" of our system is an area reserved
for use by the BIOS, DOS, and CCP. This area is the first
page of memory, and is called, "page zero." We will
cover the use of this basement area in great detail, but
later. Finding a place to begin is always the most difficult
part of starting any project. And, as I often say, no mat-
ter where I begin, I should have covered something else
first. With this in mind, let us begin.
Project Support Disk
Because many are not familiar with assembly
language programming, nor the structure of the world on
the other side of the screen, I have prepared a special
assembler. This assembler has proven itself to be of
value to the beginning assembly language programmer.
We have discussed briefly bytes, lines, pages, and other
terms. There are even more terms to learn. For example,
a "word" is a 16 bit address constructed from two bytes.
The hardest thing for a beginning assembly language
programmer to understand is where a byte must be used,
and where a word must be used. This is especially true
when they are often represented by the same series of
symbols such as DEFB, DB, DEFW, or DW. In the
assembler we will be using a byte is called a "BYTE,"
and a word is called a "WORD." I realize this is at best
treason, to the pundits of tradition, but it is easy to work
with.
Additionally, which does one use when representing
string, or character data? You guessed it, "DATA." The
common approach to Z-80 system programming is the
use of the 8080 assembler that came with your system.
8080 mnemonics have many and varied forms, which are
confusing at best. We will use a Z-80 assembler for a Z-80
system, another attack against tradition. Most all of the
instructions have a simple form, with only two
variations, a marked improvement.
This assembler, originally written by Pat Crowe of
England, is provided for this projectas a user disk. It is
available from TCJ at a very reasonable cost, as it is a
public domain program. The source code file can be
assembled with itself. No other assembler is needed for
this project. Additionally, all the source code files to do
all of the projects we will be discussing are provided in
ready to modify and assemble formats.
Due to the fact that Ampro distributes the T/MAKER
system, and bundles it with some system configurations,
all source code files are presented in T/MAKER format.
Word Star, and other editors may read these files without
modification as the files are pure ASCII code.
Getting Started, (Finally)
The first thing that we must do is configure a system
for our use. We do not want all of the spiff and reser-
vations of memory space used by ZCPR3. Our first
project will be to install standard CP/M in our systems,
at the maximum possible memory image. Place a check
mark in the box provided before each step. This is to
assure that all steps are performed in the proper sequen-
ce.
n 1. Format and SYSGEN a blank disk.
D 2. Place the following programs on your fresh disk :
a. M0VCPM.COM
b. SYSGEN.COM
c. DDT.COM
d. CR0WE.COM
e. CCP.CRW
f . CCPA.CRW
g. CCPB.CRW
h. STATUS.COM
D 3. Place our working disk in drive 'A' and boot it.
D 4. Your system should send you to the CP/M com-
mand line and issue the "A0> " prompt. When the prom-
pt appears enter:
A0>MOVCPM61*
What we have done is told MOVCPM, (do not use the
ZMOVCPM program), to construct a CP/M system that
is 61K in size. The "•" tells it to leave this new image in
memory.
MOVCPM will, when it has done its work, instruct you
as to the option to SYSGEN or SAVE the memory image.
When the prompt reappears enter:
A0> SAVE 41 MYSYS.COM
n 5. When the A0> prompt returns, enter:
A0> SYSGEN MYSYS.COM
The Computer Journal / Issue #22
SYSGEN will then ask for a destination drive, enter "A"
to place the standard CP/M image on drive 'A.' The next
time SYSGEN asks for a destination drive, answer with
only a RETURN.
_ 6. "Flip" the reset button. Your system should come
back with the prompt: "A>'. Nothing is wrong, that is
just standard CP/M!
Z 7. Now enter :
A > STATUS
and make note of th? positions reported for the locations
of the BIOS, DOS, and CCP on the memory map in Figure
1, if they are different than those shown.
It is very important to accurately determine the
location of the CCP. If the new CCP does not begin in the
same place as the old one, then the system will not fun-
ction. Each portion assumes another portion to be in a
given spot relative to itself.
G 8. If you do not have my source disks and assembler,
then enter the published source code, and convert the
data representations to those of your assembler.
Be sure to set the equate to be used by the ORG
statement to the proper value in file CCP.CRW, if the
location of the CCP is other than D800H in your system.
If you do have the source disks you may now assemble
the source code by entering :
A> CROWE CROWE.AAZ
This will cause the assembler to look for the source file on
drive 'A,' place the ".HEX" file on drive 'A,' and omit a
".PRN" file. We do not want a PRN file due to the size of
the files being assembled.
n 9. When the source file has been assembled without
error enter:
A> DDT MYSYS.COM
DDT will sign on and present its own prompt, "-', then en-
ter:
-ICCP.HEX
-R3180
when the "-" prompt returns, enter
-GO
which will return you to the "A> " prompt. At this point
enter:
A > SAVE 41 NEW.COM
A> SYSGEN NEW.COM
and place the new operating system on the 'A' drive as
was done in step 5, above. Reset the system and the
command prompt of " A0> " should be returned.
For a summary of your new system commands enter:
AO>HELP
and a help screen will appear.
A Bit Of Digression
An Overview of CCP Commands, Old And New
The standard CP/M CCP has the following commands :
a. DIR which returns a directory
b. TYPE which prints a text file
c. REN which renames a single file
d. ERA which deletes files
e. SAVE which we have already used
f . USER which changes subdirectories
g. ' P (control-P) which sends whatever is
sent to the screen to the printer
h. ^ C which resets the system
i. S which stops screen display when using
the TYPE function
It would be best if you referred to your system manual to
assure that you understand what these commands are,
and do. Our new CCP has all of these commands, and
more, some with expanded functions. The TYPE com-
mand, which is called "READ," now has a built-in single
screen paging function. The basic command set is as
follows:
a. DIR
This command functions in the same manner as the stan-
dard CP/M DIR command. The enhanced variations
available g^^Q-
DIR ♦.• S will display files with the "SYSTEM" at-
tribute
DIR *.• U will display files of any attribute
b.READ
This command functions in the same manner as the stan-
dard TYPE function, but has a built-in paging routine.
That is, it will display 22 lines of text from a text file and
stop, awaiting any keypress by the operator. This paging
function may be disabled by the suffix "N," for no paging
enter:
READ MYFILE.TXT N
c. LIST
The LIST function is a relative of the READ command. It
reads a text file from the disk and sends it to the printer,
instead of the terminal. No paging options are currently
available for this command.
LISTMYFILE.TXT
d.REN
The REN, or rename command, renames one file at a
time, and has the syntax of:
REN NEW.FIL=OLD.FIL
where NEW.FIL is the name that OLD.FIL is to be given.
e.ERA
ERA deletes files individually, or en masse. Wild-cards
may be used. If the wild-card of *.* is used the system will
ask you if you really want to erase the entire directory.
Forms may include:
Little Board ^.«. $249
The World's Least Expensive CP/M Ensine
CP/M 2.2
INCLUDED
• 4 MHz Z80A CPU, 64K RAAA, Z80A
CTC, 4-32K EPROM
• Mini/Micro Floppy Controller
(1-4 Drives, Single/Double Density,
1-2 sidea 40/80 track)
• 2 RS232C Serial Ports (75-9600 baud
4 75-38, 400 baud), 1 Centronics
Printer Port
• Power Requirement -5^^Kat 75A,
> 1 2VDC at 05A / On board - 1 2V
converter
• Only 5 75 x 7,75 inches, mounts
directly to a 5-1/4" disk drive
• Comprehensive Software Included
• Enhanced CP/M 2.2 operating
system with ZCPR3
• Read/wnte/format dozens of
floppy formats (IBM PC-DOS,
KAVPRO, OSBORNE, MORROW .)
• Menu-based system customization
• CJperator-friendly MENU shell
> OPTIONS
• Source Code
• TurtJoDOS
• ZRDOS
• Hard disk expansion to 60
megabytes
• SCSI/PLUS - multi-master I/O
expansion bus
• Local Area f^twork
• STD Bus Adapter
BOOKSHELF
Fast, Compact, Hi^h QualitY, Easrte^sc CP/M System
^etlei 700
Priced from
$895.00
10MB System
Only $1645.00
• Ready-to-use professional CPm
computer system
• Works with any RS232C ASCII
terminal (not included)
• f^letwork available
• Compact 7.3 x 6.5 x 10 5 inches,
12 5 pounds, all-metal construction
• Powerful and versatile
• Based on Little Board
single-board computer
• One or two 400 or 800 KB floppy
drives
• 1 0-mB internal hard disk drive
option
► Comprehensive Software Included
• Enhanced CP/M operating system
with ZCPR3
• Word processing, spreadsheet,
relational database, spelling
checker, and data encrypt/
decrypt (T/MAKER III-)
• Operator-friendly sfKlls, Menu,
Fnendly"
• Read/write and format dozens of
floppy formats (IBM PC-DOS,
KAVPRO, OSBORNE, MORROW. )
• Menu-tjased system customization
AHOtHTINA: FAaORlAL SA 1 4I-0018
TLX 32408 KIGIUM: CENTRE
EiiaRONiQUE lempereur. ;04:: 23-^541,
ILX 4262; CANABA: DYNACOMP
COMPUTER SYSTEMS LTD. 1604; 872-7737
£H04AN0: QUANT SVSTEaaS
10:; 253-8423, TLX 946240 REF 1900313;
FIUNCE: EGAL-, '^^. 502-1800, TLX 620893
VAIN: XENIOS INFORMATICA 593-0822
TLX 50364 AUSTIAUA: ASP
V
MIC8OC0MPUTIRS, 1613; 500^3628
MAZU: CMC-DATA L£AD€R LTDA .
(41} 262-2262 TLX 04 1 -6364 DCNMAJIK:
OANBIT (03; 66-20-20, TLX 43558
HNLAMO; SVMMtTRlC OY, (0) 585-322,
TLX 121394 ISAAU; ALPHA TERMIMAL5
LTD (3; 49-16-95, TU 341667 SVIfDCN;
ABAJGA 108154-20-90, TU 13702 USA:
CONTAO AMPSO COMPtnjRS INC ,
TEL 415! 962-0230 TELEX 4940302
IBM-, IBM Corp, ZBOA", ZikJs. Inc. dPil
Digital R««afcri, 2CPR3- A ZRDCJS",
Ecriclon inc Turtjo DOS", Software 2000
inc 1/MAKER 111 -, T/Mdker Co
COfvlPUTERS iNCOOPGRA^ED
67 East Evelyn Ave . Mountain View, CA 94041 . (415)962-0230. THLEX 4940302 .
The Computer Journal / Issue #22
ERAMYFILE.TXT
ERAMYFILE*
ERA MXT
ERA'.»
ERA MY????.*
and so forth.
f.SAVE
We have already used the SAVE command. However,
DDT and the rest of microworld speaks hex. This has
meant that we have had to translate the number of pages
to save into decimal to use this command. This function
now allows the option of specifying the number of pages
to be saved in a hexadecimal number.
SAVE 41 MYFILE.COM
SAVE 12H HISFILE.COM
To inform the CCP that the number to be worked is in
hex, the "H" suffix is required. If a file name specified
already exists the system will ask you if you want to
overwrite it.
g. USER
This command changes the currently assigned "USER
AREA," or subdirectory. It has the form of:
USER 12
USERS
which would be returned as :
A12>
A8>
in the prompt. The concept of a "USER AREA" is at best
false, as there are no such "areas" on the disk. All this
command does is assign special directory numbers.
Without this ability to assign special directories large
systems would have many screens of directory listings in
response to the DIR command.
h.PATH
The PATH command modifies the search path the CCP
uses in attempting to locate a file for us. In the standard
CCP there is no search path. In this project's CCP the
system will search the current drive, and current direc-
tory, then the current drive and the directory assigned by
the PATH command, (normally zero), then drive 'A'
current user, then drive 'A' PATH assigned directory
before complaining that it cannot find the file. The search
path is not as extensive as ZCPR3's, but doesn't require
any extra memory or disk support files.
i.JUMP
The JUMP command allows the programmer to jump to
any position in memory and execute a program at that
location. The syntax for this command is :
JUMP EEOOH
All address references are assumed to be in hex.
The Computer Journal / Issue *22
j.RUN
The RUN command will nin any program which is
currently in memory, without reloading it from disk.
SYSGENMYSYS.COM
(exit)
DIR
RUN
(system prompts:)
Destination Drive?
k.DO
The DO function is similar to the RUN command, but
allows the passing of parameters to the program residing
in memory.
STAT
(exit)
DO *.♦ $SYS (which sets all files with the
system attribute)
l.LOAD
The load command loads a named file into a given ad-
dress:
LOAD 2345H MYFILE.COM
in which the load address must be in hex, and the file
must be assembled, or compiled, to run at the address
specified.
m. HELP
The help command displays a user created HELP file,
one screen at a time. The help file may be created by any
text editor. The Help file must be named:
SYS.HLP
and must take into consideration the paging effect of the
READ command, which is used to print the HELP file, in
general use the SYS.HLP file should contain an index of
other help files. Once this Index is displayed the user may
enter the command :
or
AOREADHELP.ERA
AOREADST0RY.TXT
Only the name of the system base help file is predefined.
The HELP command may also be used in either the cold,
or warm boot autocommand structure for power-up and
reset screens or menus.
n. ^ P, ^ C, and -^ S
These three control codes operate in the standard man-
ner.
We will deal with all of the commands in greater detail
as we examine the CCP source code. I wanted to give you
a basic overview of what we will be doing in case you
wanted to order the source disks before we got too deeply
fSfSE
is
simp's
S-C so";*! The HER|^,„,ation^
iything 7900 „ HEBo^s'^^r"-^^"']
NJVSA-
»0<»
♦*•»«'
nC»'<l
iccep'
ive<J
tftV^^^
Vn^orrn
^uon
Both as
5279.00
more
!':!:rto8o^^^
to oro^' ■ ation- '^'l
10
The Computer Journal / Issue #22
involved. Of course these commands are only those
which are installed for demonstration purposes. At the
end of this series you will be able to design your own
command structures for the work that you do.
The CCP, A Detailed Look
The CCP we will be examining has a long and varied
history. If one had to trace its history it could probably be
said that the original author was Richard Conn. The ver-
sion shown here has been assembled from a number of
"ZCPR" type CCP implements written for four or five
different assemblers, and untold numbers of machines.
This CCP, as with all of its forefathers is a public
domain program. All persons who claim copyrights to
any given version do so to assure that the program will
remain in the public domain, and will not be used for
direct commercial purpose.
In Figure 3 we begin to look at the source code, as writ-
ten for the CROWE Z-80 assembler. As with most assem-
bler files we begin with a long list of equates for terms we
will be using later in the program. As we progress I will
excerpt from the source code so we do not have to keep
turning pages to see what is being discussed. For now,
make special note of Figure 3.
Note that the first line of our file holds a line of com-
ments which are described as T/MAKER Tab Settings.
The T/Maker editor is, again, suppUed with many Ampro
systems as the only alternative to the CP/M ED.COM
program. Many users therefore will not have a copy of
WordStar or other editor. The target system in this
discussion is the Ampro Series 100. It therefore makes Ut-
ile sense to create files with an editor that is not com-
monly available to Ampro users. A T/Maker file may be
read by any text editor as it produces a "pure ASCII
code." This means that there are no flipped bits nor con-
trol codes hidden in the text file. T/Maker does have a
quirk, however. There is a 300 character "first line" in
the text file where tab settings are stored. The maximum
length a line may assume is 300 characters, in the CP/M
versions. This tab line gives most languages and assem-
blers a fit ! When using T/Maker be sure to save your files
without tabs. This is done by entering:
WHAT NEXT? NOTABS SAVE
In the alternative, and what I have done, is use the
T/MODIFY program to change the default setting of my
T/Maker system. When asked if tabs should be saved
with the fUe, answer "NO." The top tab line in our
program is to set the internal tab settings for assembly
language programming. All that is required to set these
tabs is to place the cursor on this tab line and enter :
ESC
S
'^ I or TAB key
all tabs represented by this model line will be installed in
the system for as long as the power is on.
two boolean symbols. A boolean symbol is a logic
operator which may have either of two states, either
"true," or "false." A negative logic state is, in this
program, called "NO," and a positive logic state "YES."
These boolean elements are used for triggering con-
ditional assembUes.
A conditional assembly is a section of program that
either will be assembled, or will not be assembled,
depending upon the result of an "IF" evaluation. We have
a number of conditional assembly sections in this CCP.
Some commands are considered hazardous in a Remote
CP/M system, (RPCM), as callers may try to "crash our
system," causing damage to files, and possibly equip-
ment. For our personal use we will not inhibit these op-
tions.
CR EQU tfUM
LF EOU «AH
TAB EOU «9H
ESC EOU IBH
CTRt-C EOU eSH
UBOGT EOU ««H
UOTLAG EOU «4H
BDOS EOU «5H
BIOS EOU «EE««H
TFCB EOU 5CH
TSUFF EOU 80H
TPA EOU ClffffH
Icharactaf-: carriage rvturn
(ch«r*ct»*-: lin« f*«<]
t character-: tab
tcharmctmr: »»cap«
Icharactar: control -c
tcp/« Mara boat addraaa
luaar nua in high rtytibla, diak
Ibdoa function call entry pt
;induatrial bioa location
Idefault fcb buffer
Idefault diak t/o buffer
ibaae of tpa
In the equates above we assign symbols for frequently
used codes. The first five equates are for control charac-
ters we will recognize in the program. It is far easier to
remember a symbol than the actual numeric codes. The
next seven equates, starting at "WBOOT" will eventually
tell the program where to go to perform a function, or
find data.
NSIZE
EOU
61
fMVro cp/« •
etrex.p
EOU
•DOMH
tccp location
CBBUFF
EOU
BI054-&2H
far *apro svr i •• 1#0
The equates above give us a picture of what our
memory map is to look like. Remember that we created a
memory image of a 61K CP/M system early in our
discussion. MSIZE equates to the size of the CP/M
system we created.
Equate AMPCCP is set to DSOOH, which is where, in
memory, this program is to begin. Note that there is a
leading zero in the equate. Any time a hex number begins
with a letter we have to place a leading zero. If we did not
do this the assembler would not recognize the hex
representation as a number, but as some kind of strange
human symbol. All numbers must look like a number in
some way.
RCPM EOU
NLINE5 EOU
PGDFLG EOU
HAXUSR EOU
SVSFLG EOU
SOFLG EOU
DEFUSR EOU
I set to tru« 1* ccp !■ 4or a BBS syvtwB
inuaOar o* 1 i n»« on crt scrvwo
(this flaq r«v«f-««« th« dv^ault tt**mct.
twaMiMua usvr nuabwr •ccMm«t)l«
:for dtr coflMaand: I i mt ••v> and *dir
{for dir co M and: list Vmy* f i I •« ontv
tdv^aul t uMr nuat>«r *ar com filva
EOU
EOU
icondi t tonal loqic boo 1 van dvc 1 arat ion«
In the two lines of code above we define the states of
In the next series of equates, which have been sim-
plified from many versions of the CCP, we tell the
program what options we want to use, and what our ter-
minal "looks like." In that our first version of this CCP
will be for internal use, we have set the RCPM equate to a
negative state. That is, we are telling the system that we
do not want a secure remotely operated CP/M system.
We then answer questions, in compuspeak, about the
maximum number of lines on our screen, (24), and the
symbol we wish to use to disable the page scroll feature.
TTiese two equates, therefore, relate to the READ com-
mand of the CCP.
The Computer Journal / Issue *»22
11
, 1
;
5
; ;
; Tab Settings
For T/Maker Ed
itor
Hermit Software's
Modi
f i ed CROME Assemb 1 er
Source Code File
<c>
1985 C. Thomas Hilton
Primary
Hard war
e: Aaipro Series 100, lA CPU |
(Original Li
ttle Board)
Systmi:
CP/M 2.
2
(Ampro
Standard Version) 1
Function: A True
Z-80
Replacement Console Command Processor To: i
1. Rest
ore AUTOCOMMAND Function To Ampro 61K CP/M 1
2. Enhance Standard CP/M Console Functions 1
Index:
CCP.CRW
CCPA.CRW
CCPB.CRN
CROWE Source Code File
CROWE Chain File
CROWE Chain File
LIST
TITLE
'Aaipro Custom
CCP Base File'
»
NLIST
9
5
■
—
terminal
and
'type' customization equates
9
NO
EQU
YES
EQU
0FFH
;conditional logic boolean declarations
CR
EQU
0DH
.character: carriage return
LF
EQU
0AH
•character: line feed
TAB
EQU
09H
; character: tab
ESC
EQU
IBH
; character: escape
CTRLC
EQU
03H
;character: control-c
WBOOT
EQU
0Vr1
;cp/m warm boot address
UDFLA6
EQU
04H
;user num in high nybble, disk in low
BDOS
EQU
05H
;bdos function call entry pt
BIOS
EQU
0EE00H
(industrial bios location
TFCB
EQU
STH
{default fcb buffer
TBUFF
EQU
80H
; default disk i /o buffer
TPA
EQU
0100H
;base of tpa
MSIZE
EQU
61
; ampro cp/m size
AHPCCP
EQU
0I)800H
;ccp location for ampro series 100
CBBUFF
EQU
BIOS+62H
RCPH
EQU
NO
;set to true if ccp is for a BBS system
NLINES
EQU
24
; number of lines on crt screen
P6DFLB
EQU
'N'
;this flag reverses the default effect
MAXUSR
EQU
IS
; maximum user number accessable
SYSFLG
EQU
'U'
;for dir command: list «sy« and «dir
SOFL6
EQU
'S'
;for dir command: list *sys files only
DEFUSR
•
EQU
I default user number for com files
9
•
0R6
AMPTTP
entry:
JP
CCP
; process potential default command
JP
CCPl
; do not process potential default command
Figures
12
The Computer Journal / Issue #22
The MAXUSR equate identifies the legal number of
user areas the operator may request in a USER com-
mand. The number of user areas in most systems is 16,
due to the way that user areas are defined in low
memory. Location 0004 contains a single byte which teUs
us what disk drive we are on, and what the current user
number is The format for this data is ;
FIH
which would indicate that the system was in user area 15,
(remember that hex starts with the number zero which is
a valid number) , and drive 'B' was the currently selected
drive.
SYSFLG and SOFLG are options to display files of all
attributes, or system files. When given the "SYS," or
system attribute, the file will be displayed in a normal
directory listing.
The DEFUSR equate is the number which is to be con-
sidered the default user, or directory number to be used
in a directory search for an operator specified file. This
value may be modified, once the system is running, by
the PATH command.
ORG
AMPCCP
Our ORG statement is set to the value we assigned to
the AMPCCP symbol, which is D800H. In a larger
program we could present a number of different values to
the ORG statement by use of a conditional assembly.
APPLE ][, ](+,///y/e &//C OWNERS
UPGRADE THAT TIRED 6502 TO 16 BITS II
Si^^iQZmi 149.95
16 bit varslon of Uw 6502. P(n for pin tni complataly toflwwt
cotnpttlbl* with Uw 6502 CPU. You c«i upgrad* your ApptaKJ-f .
///y/t or//c to 1 16 bit computM- simply by roplacing Uw 6502
witA tht 65802 without losing Uw Alllty to run aiy oM soTlYnrt.
ProDQSQRCA/M (list $79.95) $69.95
ThltPraOOSv«rsionorORCA/ri comM wlUi Uw coinplcU 65602
insUvtIon s«t. If you inland to dtvakipo soflwsr* for Utis now
CPU, Uwn Utis ptckago is a must. Chosan by Uw dasignars of tha
65802 as Uw standard 65802 assamMar.
16 Rit Upgrade Rtartw^ Parkaye S1Q9.95
This pwkag* inckidat 65802 CPU and Uw ProOOS ORCA/H. All
you naad U) start.
Coming Soon: forth, pascal P-coda Upgrada S. nCREl
TO ORDER, SEND OCCX OR MONEY GRDER TO:
ALLIANCE COMPUTERS
PO BOX 408
CORONA. NY 11366
POST A6E AND INSURANCE INaUDED. (710)426 2900
All CPlTs will ba awtt by PoaUl Sarvica. 1st claat inaurad or UPS.
Insursd. Plaasa apactfy USPS or UPS. UPS doasnt dallyar to POB's.
Soawara will ba sant by UPS Blua Labal . If you want UPS Naxt Day
Air. add $5.00 (CPU^ onlyl). Host all ordars sant out sanw day.
COD add $3.00. APO^ and FPO% walconwd.
Foraign ordars: Plana rnaka paynwnt m US dollars drawn on a US
barit. Add$SrorRaglfltar«d Mail andAlrnall Postaga (axcapt
Canada). No Foraign COD'S.
PLEASE maUDE YOUR PHONE NUTBER WITH ORDER
AMPCCP
AMPCCP
IF
EQU
ENDIF
KAYPRO
GEOOOH
IF AMPRO
EQU OD8000H
ENDIF
A standard CCP has two entry points. The ORG
statement defines where the program actually begins as
the equate statements have no real meaning to the com-
puter. Equates are just there to make life easier for us
humans. Ampro chose not to use the standard means of
entry into the CCP. This is primarily because their BIOS
does not check to see if there is a valid cold boot, or
"autocommand," installed in the position set aside for it.
The Ampro BIOS assumes that the CCP, or other
program will take care of this matter. In a normal
system such a check would be made. If no command was
noted for execution upon restart the BIOS would jump to
location ENTRY -I- 3. In this way no time would be wasted
in determining whether to process this command. Ad-
ditionally determinations must be made as to when to
execute such a command.
This failure to check for the actual presence of a restart
command causes the Ampro to always enter the CCP at
ENTRY, or D800. We will retain this dual entry feature as
other programs may try to use it, being written to be nm
on a standard CP/M machine. Again, this failure to check
for a restart command is why the "autocommand"
feature is lost in the Ampro machines when ZCJPR3 is not
being used. ZCPR3 makes these determinations. We will
perform a test for a restart conmiand ourselves, while
allowing standard CCP entry points.
To summarize, most systems would enter the CCP at
ENTRY -f 3 if they had no intention of processing a restart
command. They would enter the CCP at ENTRY if they
did want to supply a restart command to the CCP for
processing. Ampro systems always enter at the ENTRY
location, whether there is a restart command stored in
the BIOS or not. We will have to make up for this over-
sight in BIOS design to allow the use of the standard Am-
pro "autocommand," while retaining compatibility with
other CP/M systems.
CCP
CCPl
t pr-oc»ms potential dvfault
; do not proc*«« potential d*4«ult
As is noted, the two different entry points are met with
unconditional jumps to routines that either will process a
restart command, or will not attempt to process a restart
command.
Kindly note that our discussion does not follow the
physical layout of the source code listing, but rather the
logical path of program execution. That is to say that
while we will now discuss the routine "CCP" it is not the
next entry in the program listing.
ccp «t«rting point*
*t«rt ccp and don't proc»«« dv^Ault c o aaartd mtorad
CCPi: XOR A (••« no dv^ault co—a
LD
(CBUFF>,ft
From our previous discussion we leam that if the Am-
pro BIOS did its own check for a restart command, and
The Computer Journal / Issue #22
13
ccp starting points
start ccp and don't process default contaand stored
CCPl:
CCP:
NLOG:
CBPROC:
XOR
A
LD
(CBUFF),A
ccp and
possibly p
LD
SP, STACK
PUSH
BC
LD
A,C
RRA
RRA
RRA
RRA
AND
0FH
LD
E,A
CALL
SETUSR
CALL
RESET
POP
BC
LD
A,C
AND
0FH
LD
<TDRIVE),A
JR
Z,NLOG
CALL
L06IN
LD
A, (CBBUFF)
OR
A
JR
NZ, CBPROC
LD
A, (CBUFF)
OR
A
JP
NZ,RS1
JR
RESTRT
LD
BC,9
LD
HL, CBBUFF
LD
DE, CBUFF
LDIR
XOR
A
LD
(CBBUFF), A
JP
RSI
!set no de-fault coounand
> de-fault coanand
; reset stack
5c=user/disk nuaber <see loc 4)
; extract user number
»set user nuiaber
5 reset disk system
;c=user/disk number (see loc 4)
;extract default disk drive
;set it
;skip i-f 0. ..already logged
;log in de-fault disk
;is there system command to execute?
;if not zero there is a command
Figure 4
found that there was none to execute, we would have en-
tered the CCP at ENTRY-l-3. At ENTRY+3 we would
have been ordered to jump to CCPl, which is the entry
point when we do not want to process a restart command,
or there is none to execute. Both circumstances have the
same meaning.
When a command is entered at the prompt, it uses
BDOS function 10, or input a line of text from the logical
console device. This function call requires that a buffer
be defined, and that the first character in the buffer tell
the DOS what the maximum number of characters to ac-
cept should be. Function 10 will return to the caller when
either this number of characters is reached, or the
operator signals the end of a line by pressing the
RETURN key, or control-M, ( ^ M) .
represents the maximum length of the input command
line. This could have just as easily been stated as :
MBUFF: BYTE
80
With this byte as the first byte in our input buffer we tell
DOS function 10 to look here for the maximum number of
characters by saying :
LD D€. MBUFF
LD Etc. 1^
CALL «M5H
; 1 Odd th» «ddr««s o^ buffer in OC
: 1 D«d function nuaAvr into BC p«ir
iMAt* th« DOS CAl 1 by juapinq tnra
; location S. paqs
5UFLEN
EQU
90
MBUFF:
BYTE
&UFLEN
C&UFF;
EtvrE
C I BUFF :
DATA
CieuF:
BYTE
ti'
RSRV
&UFLEN-
(t-CIBUFF
MaxiMUMi ttuiiwr ivngth
fltd^: 1 «uM biiffvr lanqth
nuMbvr of v«lid ct\»r»ctmr% in
dvfaul t <col d boot ) co«a«nd
ccMMiAnd «trinq t»f-«in«teir
*l : total IS 'buf l»n' byt*
A type of buffer for DOS function 10 is shown above, and
is from our CCP. The equate BUFLEN states that the
byte stored in the BYTE at MBUFF should be 80, which
When DOS function 10 has done its job, returning only
when the maximum number of characters has been in-
put, (80), or the operator enters a Carriage Return, (CR),
it will place the actual number of characters input in the
byte at location CBUFF. For entry into the CCP at CCPl
this byte, which contains the actual number of characters
in the returned command line is our focal point :
: %t«rt ccp 4nd don' C proc*«s d»f «ult r n— inn
CCPl: tOR A ;«»t no d«4«ult co^mtmi
LD (CBUFFi .A
In this application of the exclusive OR logic function we
are exclusive ORing the 'A' register with itself, which
14
The Computer Journal / Issue #22
produces a zero figure. Any time a value is exclusive ored
with itself a zero amount is returned. We could also have
said:
LD A,0
with the same result. Our next instruction states that we
are to place this zero value into the byte at CBUFF. When
we leave this instruction, a zero value will be in the byte
at CBUFF. Why did we do this? Well, the quickest way to
determine whether there are any characters in the com-
mand line is to check and see how many characters DOS
function 10 says should be in the command line. Now if we
put a zero value in CBUFF, whose function is to hold the
number of characters in the command line, then when we
check we will be told the command line is empty. If the
command line is empty, as CBUFF tells us, then there is
no use trying to execute whatever is in the conunand line.
It is empty. Computer psychology at work friends, if you
can't dazzle them with your brilliance, dazzle them with
yourbulls#$t.
Having gone 50 miles in a two line program segment we
then drop into CCP, where we would have come if we
wanted to execute a restart command. Yup, now we are
at where we didn't want to go anyway, and took a two
liner "short cut" to get there. Oh well, that's high-tech.
LD
A,C
;c-u»«r /disk
RRA
;«xtr«ct u%m
RRA
PtRA
RRA
AND
eFM
What we have done is shift the user number bits four
places to the right, so they are now the four least
significant bits:
ecfore:
UUUUDDOD
RRA
LXJF<IN6:
KUUUUDDD
RRA
XXUUUUOD
RRA
XXXUUUUD
RRA
AFTER:
XXXXLXiUU
where X means don't really care. We now do a logical
AND with the lower four bits, which house the user area
code, which has the effect of making all the X marks zero
values.
Now we move the value of the disk/user byte, which now
only has the user number, into the 'E' register from the
accumulator, or 'A' register. We make this move in
preparation of calling a subroutine to deal with the user
number.
CM-L
;r» » at disk vyst**
I start ccp and po«stblv procv
LO
PUSH
■ dv^ault c
trwmmt *tack
lc^4aar/dt«k
l«xtract u««r
Having arrived here we have to explain some assum-
ptions we have made and thus far ignored. The first of
these is that the BIOS is supposed to place the current
disk and user area in the 'C register before jumping to
the CCP.
However, the first thing we do when we actually get in-
to the CCP is create our own STACK. A stack is a place
where you stuff things just to get them out of the way,
such as the place to return to after a subroutine CALXi
and data you want to in^serve. A stack builds down, and
you "PUSH" things onto it, and 'POP" things off of it. In
our CCP we have memory reserved for these stack fun-
ctions called, of course "STACK." The register 'SP," into
which this 16 bit value is loaded is used 1^ the processor
as well. Having defined where our closet of values is,
where to stuff things, we immediately stuff the disk data
sent to us in the 'C renter for safekeeping.
Now remember when we were talking about USER
areas a while ago. No? Well go back and look, I'll wait, I
mean I've nothkig better to do than wait on you, just so I
can confuse the 'ell out of you again, so go ahead... go
back and reread that section I'll wait
I am assuming that you now know that the user area
number is held in the upper portion of the disk/user byte
at location four. Now if a byte is eight bits, Uien Uie upper
four bits reiMresent our user area. We first move the
disk/user byte into tiie 'A' register, from Uie 'C register
and then use the command Rotate Right Accumulator,
(the 'A' register) , to extract Uie user number.
These two calls set the user number and disk number,
which we received from the BIOS, into the storage area
at 0004H and reset the disk system so that everything is at
a starting point for further operations. This setting things
up is called "initializing the system."
We then do almost the same thing, separating the disk
number now from the user number. First we get the
original value from off of the stack, put it in 'A,' and then
do a logical and on the lower four bits. This is essentially
the same way we did the user value except that the value
we want is already in the lower four bit position.
LD
A.C
lc-u«OT-/dtmfc rnj^MT- tmmm lei
HMO
•FM
l»tr>ct d^ault tttmk *-tv«
u>
(TntlVEI.A
t«M it
Jll
2.ia.ae
IKkip If •...already loQgad
C«LL
LOSIN
Hog in i>*«ault disk
Now it could be that the system drive, disk 'A,' whose
number is zero, is already assigned. The action of AN-
Ding out drive value would set the 'Z' or Zero Result flag
if it was. The system, or default drive will always be the
lowest drive number. If this is in fact what has happened,
that the drive number is already zero, then we do not
have to log in the system drive. If the value isn't zero then
we have to assign the new drive, or 'log it in. '
Now then, remember all the discussion about the
restart conmiand? We have to deal with the possible oc-
curence of a restart command now. From our discussion
above, can you determine how we will deal with this
determination?
LO
*, <CnUFFI
lis thmrm av«ta« i ii^Miil
OR
«
JR
HZ.CVROC
tif not laro th«r» i« a c
LD
*. (CMTFI
am
*
JP
NZ.RSl
JR
RESTRT
The Ampro "autocommand" or restart conunand is
located 62h bytes above the BIOS eatiy point. Just like
The Computer Journal / Issue #22
IS
CBUFF it has a value of actual characters in the restart
command line. Ampro has limited this amount to just
eight characters. At NOLOG we sneak a peek at the byte
which is to tell us how many characters are in the restart
command. We load the accumulator, or 'A' register, with
that value. We then do a logical OR with the accumulator,
or OR it against itself. We do this to see if there is a zero
value in it. If there is then the 'Z' flag will be set after the
OR function.
If the 'Z' flag is not set then the value was not zero and
we want to jump relative to where we are, upon a nonzero
returned value, to the location represented by CBPROC.
"CBBUFF" means "cold boot buffer," and "CBPROC"
refers to cold boot processing.
Now if there is a zero value in the BIOS restart com-
mand buffer, (CBBUFF), we check to see if there is a
command in CBUFF, which is the CCP command buffer.
If there is a command in this buffer then we will jump to
RSI, else we will jump to RESTRT for normal CCP
processing.
It is important to note that we are checking two restart
buffers, why? Well, in my system you can have a com-
mand in the cold boot buffer and a command in what I
call the warm boot buffer. The BIOS is loaded from disk
only upon a power-up or reset condition. The CCP is
loaded upon every warm boot. In this way it is possible to
configure the system, using either or both restart com-
mand potentials, to assure that the system never reaches
the command line. That is to say that even if the power
goes off the system can recover and reset itself. This is
important where reliability is at issue.
From this point we again have a fork in the processing
road. If there was a cold boot command lurking in CB-
BUFF then we have to discuss its processing. If there was
a command in CBUFF then we have to discuss it, and
then discuss what to do if there were no restart comman-
ds at all to deal with. Let us begin where we jumped off to
do the cold boot command, which would have sent us to
CBPROC.
.CBBUFF
, CBUFF
CBPROC
LD
BC.9
LD
ML. CBBUFF
LD
oe. CBUFF
LDIR
XOR
A
LD
(CBBUFF) ,A
JP
RSI
At CBPROC we perform a transfer of the restart com-
mand string from CBBUFF down into CBUFF. We do
this by using a Z-80 specific assembler code, "LOIR." We
know that the Ampro "autocommand" in the BIOS allows
only an eight character file name. We also know that, like
the CBUFF format, it has a number which indicates how
many characters are in the command line.In the LDIR
instruction the 'BC register pair, (think of them as the
"byte counter"), is loaded with the maximum number of
characters we want to move. In this case the number of
characters is nine. The actual BIOS autoconmiand buffer
looks like this:
ORG B10S-^62H
BYTE •
DATA
BYTE
af«5 AUTOCHO*l»
;nua*^«r of ch«ract*f'« in coai
;bl«nk co w and fil* n^mm
; tvf-Minat inq null ch*r*ct»f-
We next load the 'HL' pair with the source address of the
data we want to move, CBBUFF. We cannot use the
AUTOCMD label as it is unique to the BIOS source code.
We could have used it here as we had defined it with the
value of EE62H instead of using CBBUFF. But, we are
concerned with the Cold Boot BUFFer. The 'DE' register
pair is used to specify the DEstination address for our
move. The destination address is CBUFF. CBUFF is
used for all command processes in our CCP.
Having defined the number of bytes to be moved, by
placing this number into the 'BC register pair, the source
address of the nine bytes to be moved in the 'HL' pair,
and the destination of these bytes in the 'DE' pair, we are
ready to make the move. The move is made by uttering
the magical incantation "LDIR." (Hey! Give me a
break! After all that set up such an anticlimactic ending
needs something. OK, so it isn't magic. I bet you are the
type that pulls back the Wizard of Oz's curtains just to
ruin the show!)
(CSBOFF)
RSI
So, party poopers and all, the move has been made, and
the command hidden away in the BIOS is now in CBUFF,
complete with the number of characters in the line. We
now zero the accumulator with the exclusive or com-
mand, and stuff the zero value into CBBUFF, where we
just moved our restart command from.
In this case we are ignoring the terminating null as we
know how many characters there are we want to move.
Sidekick for CP/M!
Write-Hand-Man
Desk Accessories for CP/M
NEW! Now with automatic screen refresh!
Suspend CP/M applications such as WordStar, dBase, and
SuperCalc, with a single keystroke and look up phone
numbers, edit a notepad, make appointments, view files and
directories, communicate with other computers, and do
simple arithmetic. Return to undisturbed application! All
made possible by Write-Hand-Man. Ready to run after a
simple terminal configuration! No installation required.
Don't be put down by 16 bit computer owners. Now any
CP/M 2.2 machine can have the power of Sidekick.
Bonus! User extendable! Add your own applications.
!p47*7^ plus tax (California residents), shipping Included!
Volume and dealer discounts.
Available on IBM 8 inch and Northstar S irKh disks. Other 5
Inch formats available with a $5.00 handling charge. CP/M Z2
required; CP/M 3 not supported.
COD or checks ok, no credit cards
Poor Person Software
3721 Starr King Circle
Palo Alto, CA 94306
tel 415-493-3735
Wril«-H«Mi-\4«i tridfnuric o< Poor Hnon iaHmtn, CP/M iradmuri al Oi^iul
KnMrcK SUMck ndemvi of lortand Mimalonji dtmi ndtnmk al Aihnn-TjK. WordSur
tradenuHi al M kiofj i a ^pcrOlc t ftdnnaHi ai Sonim.
16
The Computer Journal / Issue #22
Now why did we do that after we just went to so much
trouble to move it down where we could worlc on it?
Remember that the standard Ampro BIOS does not per-
form its own check for a restart command in the
AUT(X;MD slot. Because it does not do this checking it-
self it does not make the decision as to jump into the CCP
at ENTRY, or ENTRY -1-3; "to process or not to process,
that is the question." The Ampro BIOS always jumps into
the CCP at ENTRY, which is the process a restart com-
mand.
The BIOS is loaded from disk only from a power on or
reset. Yet it loads the CCP back into memory after every
warm boot function. A warm boot may be executed after
a program is run, or when we press control-C. Now if the
Bios always jumps into the CCP at ENTRY, to process a
restart command, our restart command will be detected
and executed every time the CCP is entered.
The object of the CBBUFF processing is to execute a
restart command only once, and that is only upon power-
up or reset. To prohibit re-execution, called "reentry,"
we put a zero value in CBBUFF. The next time we come
through and check this position we will be told that there
is no restart command in the BIOS, hence we will not try
to process it.
Having zeroed out the BIOS restart command we jump
to RSI where a normal command in CBUFF, the CCP
restart conmiand buffer, is processed. Before we go to
that routine, however, let's keep in mind what we have
just done with the BIOS restart command and examine
the normal CCP restart functioning.
I heard thatl Someone said, "why don't we just change
the Ampro BIOS so it doesn't create all these problems
with a simple restart command?" Well, Ampro had a
reason for doing a direct ENTRY jump into the CCP. In
the interests of compatibility we don't want to upset
thing s anymore than we have to. When we do our in-
dustrial BIOS this is an option we may explore. But let's
not get ahead of ourselves. For now this is the way we
have to do things.
Let's review for a moment. At NOLOG we made a
determinationas to whether there was a restart com-
mand in the BIOS. Review the code provided below.
LD
A, <CB8UFF
OR
A
JR
Nz.cmtoc
UD
A, ICaUFFI
OR
A
JP
NZ.RSI
JR
RESTRT
II* thOT-a »v«t»« co«iMnd to •K«cot«->
li* not xmro tttmrm i« • commanti
If there was a restart command in the BIOS we would
have jumped to CBPROC, which we just finished
discussing. At CBPROC we moved the command from
the BIOS into CBUFF, in the CCP, and jumped to RSI.
Let us now assume that there was no command in the
BIOS to be processed. In this case we drop into the code
that makes a check to see if there is a command in
CBUFF.
LO
OR
JP
We do the same thing as we did for CBBUFF, that is
check the byte holding the number of characters in the
text string. If it is a zero then there is no command to
process. A nonzero value indicates that there are charac-
ters present, a command to execute. At this point we
would jump, if there were a command, to RSI, where all
roads for execution of a command lead.
Now remember that I said that the CCP is reloaded af-
ter every warm boot, and the BIOS generally only once
per session? Now if we placed a command Une in
CBUFF, the CCP command line, and wrote it to disk,
then every time the CCP was loaded it would execute our
command, wouldn't it? Yes it would. The first thing we
check is to see if there is an initial restart command in the
BIOS. If there is we move it into the CCP and execute it,
over-writing any command that may currently be in
CBUFF. Once we move the BIOS restart command,
however, we zero out the character byte so we do not re-
execute that conunand. But, every time the CCP is
reloaded, had we a command written into the CBUFF
conunand line in the CCP it would be executed after
every warm boot. It would be impossible for the system
to ever reach the "A0> " prompt as it would always take
a priority command from the restart procedures.
Our priority for automation of our system could be
stated as:
BIOS AUTOCOMMAND: Executed Once, Set By
AmproCONFIG.COM
CCP RESTART COMMAND : Executed after every
possible pn^amtermination except a reset or power
loss. Set by a user program or DDT
It is clear that we could produce a system that was ex-
tremely reliable and able to reset itself after an interrup-
tion of power or other fatal error, as well as restart itself
after program termination or process sequence. We are
well on the road to a totally automated system that is both
reliable, and intelligent.
Now then, if no restart commands are detected, (all
roads lead to RSI eventually), then we must get a com-
mand from the human. This is done by a jump over CB-
PROC to RESTART, where all CCP roads return.
u««r
and tnfMit cammmmt linm tram hi
LO
9P, STACK Irwmmt atack
lOR
A
LO
<CBliFF),A
RESTRT is the CCP's internal restart point. When all
internal functions have been completed the CCP will
return here to begin a new sequence. This sequence is a
simide procedure of getting your conunand from the
command line, (M-ocessing the conmiand, if it is an inter-
nal function, or loading the file you specify, and tran-
sferring control of the system to that program.
When we entered the CCP at CCP we set up a local
stack, and repeat that process again hare, why? Because
the stack is kept small, and the i»roces8ing of any restart
command is a sequence all of its own. When we reach this
point we are in the "inner sanctum" of the CCP where we
start anew. We set i^) a new stack, (actually we just reset
the old one as if it were new, and clear our character byte
at CBUFF). In this way we have a fresh stack and tell
anyone who may ask that there are no commands to
execute, everything that needs to be done has been done.
We may now begin a new day.
The Computer Journal / Issue #22
17
prompt user and input command line from him
restrt:
LD
XOR
LD
SP, STACK
A
(CBUFF) ,A
print prompt (du>)
CALL
CRLF
CALL
GETDRV
ADD
A, 'A'
CALL
CONOUT
CALL
BETUSR
CP
10
JR
C,RS00
SUB
10
PUSH
AF
LD
A, ' 1'
CALL
CONOUT
POP
AF
ADD
A, '0'
CALL
CONOUT
RS00:
5
; read input line -from user
»
RS000: CALL REDBUF
process input line
RSI:
CALL
CNVBUF
CALL
DEFDHA
CALL
SETDRV
LD
<TDRIVE),A
CALL
SCANER
CALL
NZ, ERROR
LD
DE.RSTCCP
PUSH
DE
LD
A, (TEMPDR)
OR
A
JP
NZ,COM
CALL
CHDSER
JP
Nz.con
LD
A, <HL)
INC
HL
LD
H, (HL)
LD
L,A
JP
(HL)
; reset stack
;print prompt
; current drive is part o-f prompt
;convert to ascii a-p
;get user number
;user < 10?
; subtract 10 from it
{save it
;output 10's digit
; output I's digit (convert to ascii)
I input command line from user
{capitalize command line, place ending 0,
; and set cibptr value
;set tbuff to dma address
{get default drive number
{set it
{parse command name from command line
{error if command name contains a '?'
{put return address of command
{on the stack
{is command of form 'd: command'?
{nz=yes
{ i m mediately
{scan for ccp-resident command
{not ccp-resident
{found it: get low order part
{get high-order part
{store high
{store loM
{execute ccp routine
entry point for restarting ccp and logging in default drive
rstccp:
XOR
LD
CALL
(CBUFF), A
DL06IN
{log in default drive
entry point for restarting ccp without logging in default drive
RCCPNL: CALL SCANER {extract next token from ct
{get first char of token
{any char?
CALL
SCANER
LD
A, (FCBFN)
SUB
y P
LD
HL, TEMPDR
OR
(HL)
JP
NZ, ERROR
JP
RESTRT
and 1 i n*
Figures
18
The Computer Journal / Issue #22
I print pro
CALL
CRLF
Iprlnt proapt
CALL
8ETDRV
lcuf-r«ot dr-iv* is part o4
ADD
A, 'A'
Iconvsrt to «»cii a-p
CALL
CONOUT
If there was a restart command we would have jumped
over this program segment. We are assuming that we
want to get a command from the human operator. Com-
puters are so willing to please
The first thing we do is clear a line on the terminal, (our
ego demands a clear work space) . We clear a line by sen-
ding a RETURN, (CR, which sets the cursor to the begin-
ning of a line), and a LINE FEED, (LF, which moves the
cursor down a line) , to the terminal. To make life easy for
the human we include a LF every time he, or she, presses
the RETURN key.
In the interest of brevity, as we are running out of space
for this issue we will highlight what each subroutine does.
We will discuss the various support routines in detail
later. This time I only want you to understand the
primary CCP function loop.
GETDRV returns the binary number of the current
disk drive. We then add the value of a capital "A"
character, (41H) to convert the disk drive number into a
value that can be printed by the terminal. If the disk
drive number is "0," then when we add the number for a
capital "A" we have the value of the ASCII code for "A,"
as we have added nothing to it. If the drive number was a
"1" for drive "B" then the base figure of 41H would have
one added to it, which would be the code for "B," and so
on. A standard CP/M system can have up to 16 disk
drives, represented by the letters "A" through "P.*
At the assembler level, and unlike BASIC, just because
we print something doesn't mean a CR/LF sequence is
also printed. With the printable value of the current disk
drive in the accumulator we call the subroutine CONOUT
which sends our character to the terminal. At this point in
time just the letter is printed. We process so fast,
however, that when the prompt is printed it appears as if
the entire prompt appears at once.
SUB
PUSH
LO
COLL
POP
Ksee: ADD
CALL
( q»t usar- numbmr
lu%rr < Ign
;mubtract 10 from i
I %MVW 1 t
(output l«'m diqit
toutput I'm digit (convart to amci
In a similar manner we call a routine that returns only
the current user number. For a hint at how this is done,
basically, refer to our discussion of the entry point CCP
early in this article.
What follows is a simple binary to decimal conversion
routine. We may not just use an offset value to convert
the user number into a printable form, as we did for the
drive number, as the user area is represented as a
decimal number, instead of a letter. Additionally, we
have more than one digit to deal with. If the number is
less than 10 we do not have to formulate the "tens" value,
which must be printed first. (In the number 10 the "1" is
the tens value.)
If the number is greater than 10, then we subtract ten
from it, which wiU leave us with the "ones" value as the
remainder. This remainder will be left in the ac-
cumulator, or 'A' register. As the ones value must be
printed after the tens value, we will save this remainder
on the stack.
LD A,'r ;output lO's digit
CALL CONOUT
POP AF
Having saved the ones value, and because we know that
the maximum number of drives can never be more than
16, we just print the character "1" on the screen any time
the user area is greater than 10. Having the prompt now
appearing as "Al " we must print the remainder, or ones
value. So let's get it back, by popping it off the stack, and
make it printable by adding the lowest possible number
code to it. The ones value is converted into printable form
in the same manner as the disk number, except that the
offset is now the character "0."
RSOO:
ADD
A.'O'
-.output I's digit
; (convert to ascii)
CALL CONOUT
Note that if the value of the user number was deter-
mined to be less than 10 we would have come here and
made this single digit conversion.
id 1 in« fro
Because we are assuming that there were neither a
restart command in the BIOS, or in the CCP buffer, to
execute, we just have to have a command to process. We
have printed the "AO " portion of the prompt on the
screen. REDBUFF supplies the ">" portion of the
prompt while it waits for our input. This uses the same
DOS function 10 sequence we have already discussed.
The buffer for this input is at MBUFF, whose byte con-
tains the maximum number of characters to be accepted
from the console. When this number of characters has
been received, or a CR is entered by the operator, the
number of characters actually in the conmiand is placed
in CBUFF. The characters themselves begin at CIBUFF.
Now then, whether we had a command in the BIOS, one
in CBUFF when we entered the CCP, or we just received
one from the operator, our varied paths gather at RSI.
t proc»«s input 1 i nw
tcApit«liz« coanaod li
i and %mt ctbptr valu*
plmcm andinq •,
The first thing we do to our command is convert all
characters into uppercase format. In this way the
operator can enter command either in upper, or lower
case. We also set a pointer, CIBPTR to point to the first
character in our command. We are now ready to get to
work, after a little bit of preparation.
tm«t tbuf« to dM« addr»«s
The first step in preparation is to set up a buffer for any
and all data from the disk, or terminal.
CALL 8ETDRV
LD (TDRIVE),A
tg«t default driv* m
l««t 1 t
Then we save the value of the drive we are currently on,
so we can **remember*' where to return after we perform
the command to be executed.
CALL SCM4ER
CALL NZ,ERWOR
I p ar m* c oaM«nd
twrrar |4 cammmi
1 1 rm
contain* a ' "*'
The Computer Journal / Issue 4'22
19
All commands must conform to a very standard format
for primitive interpreters. This is the format of VERB -
OBJECT OF VERB. SCANER, we may assume for the
moment, does a quick syntax check to assure that all
commands are properly formed. It checks to see if there
is a disk drive specifier, ( if the command is to be found on
a different drive), and assures that the user isn't trying to
do something outrageous. If all is well SCA^fER returns
with the 'Z' flag set. If there is an error, or an object ap-
pears before the verb, the 'Z' flag is not set, and we are
routed to an error handling routine.
t put return «ddr««« of
;on th» st«ck
When we "CALL" a subroutine, the "way home" to the
caller is placed on the stack. When a RET command is
seen the top two values on the stack are assembled into a
16 bit address, and the processor executes a jump to that
assembled address. The CCP also has to be able to find its
way home so it can accept another command from us;
this is, after all, its function in life. Internal commands
are also called as subroutines, and have to find their way
home. In the code above we set the return address on the
stack so that when a RET command is encountered
program control is sent to a recovery routine.
A. (TEW>D«)
ccMMiand o^ torm ' d:cnwnd' "^
SCANER will set TEMPDR, (TEMPorary command
DRive), if the command, or verb to be executed is
specified to be on another disk drive. To avoid needless
processing, we can check for another drive assignment,
and assume that the verb portion of the command is a file
name. If the value of TEMPDR is other than the system
drive, drive '0,' then we jump directly to the COM file
load and execution routines.
CMDS€R
n; .com
r««) dvnt
If we do not get a clue as to what type of command it may
be, then we must check to see if the verb is an internal
command. CMDSER, (CoMmanD SEaRch), will search
a table of key words, or verbs for a match with the verb in
the command. This table is constructed as follows :
DATA 'COMMA^fD'
WORD COMMAND
DATA ANOTHER'
WORD ANOTHER
The DATA contains the literal verb string. The WORD is
a label representing the address of the concerned routine.
Remember that a binary WORD is a 16 bit value which, in
this case, represents an address in memory. If a match is
found between the command verb and a verb string in the
command table, the end of the character by character
match will be the last verb character, plus one, (as if
looking for another character to match). Hence, on
return, if a matching verb was found, the 'HL' pair will be
pointing at the first byte of the address of the verb's ac-
tion routine. If no match is found then the command verb
is assumed to be a file name to be fetched from the
BVTELLICOMP
Introduces
Inexpensive
S-100 68008
CPU Board
The card pictured above is $65 for the bare board, $210 for the kit, or $265 assembled and tested.
It uses only standard parts. A sample BIOS for CP/M 68K is available on disk for $20. The board works
fine with Digital Research Computers 64K RAM boards and semi disks. A detailed description of the
board appears in Issue 16 of The Computer Journal.
For additional information call Intellicomp, Inc. at (614) 846-0216 (evenings best time) or write to :
Bruce Posey
Intellicomp, Inc.
292 Lambourne Ave.. Worthington. OH 43085
20
The Computer Journal / Issue /^22
current disk drive, and executed. If an internal command
verb is matched then we must jump to the verb's
subroutine for execution.
INC HL
H, (f4.)
U.A
IfCMnd it: g«t loM-ordw part
t9«t hiqh-ard«r part
I star* hiqh
I star * lOM
(•"•cut* ccp routin*
We then load the low order byte of the address into the 'A'
register, from memory, increment 'HL' which then poin-
ts to the high order byte of the 16 bit address, into the 'H'
register. We then load the low order byte stored in the 'A'
register into the 'L' register. Having loaded the address
of the verb's subroutine into the 'HL' pair we jump to
where HL is pointing. Because we have placed our "way
home" on the stack we can return to the main loop of the
CCP by executing a RET instruction.
» •ntry point for rvstwtinq ccp and logging
default dri
RSTCCP: XOR
<CeUFF),A
DL06IN
) 1 og in cl9* au 1 1 dn
RSTCCP is where we return from most internal com-
mands. When a file is used as the verb the program
generally exits to the warm boot loop which rewrites the
CCP and enters it where we originally entered. For those
functions that ret\im here, the first thing we do is make
damn sure that the command line character byte is
zeroed out. We don't really need to do this, as we will just
reset it again when we get backup to RESTRT, but some
programs return to the CCP, and do not terminate to the
BIOS warm boot function, or have mystical, magical
Surplus Parts
Resource
Here's a catalog any serious computer tinkerer needs. It's a
treasure-trove of stepper motors, gear motors, bearings, gears,
power supplies, lab items, parts and pieces of mechanical
and electrical assemblies, science doo-dads, goofy things,
plus project boxes, lamps, lights, switches, computer furni-
ture, and stuff you might have never realized yOu needed.
All at deep discounts cause they are surplus/
Published every couple of months, and consecutive issues
are completely different. Send $1.00 for next three issues.
JERRYCO, INC. 601 Linden Place, Evanston, Illinois 60202
ways of trying to re-execute the restart command. In an
over-kill mode I went in and put "dummy traps"
everywhere to make sure that the two restart commands
are only executed when and where they were supposed to,
every time they were supposed to. When reliability is an
issue, a little redimdant code can sometimes help. . . .
Having once again managed the restart commands, we
want to reassign the system disk drive, drive 'A' or zero,
as the current disk drive. We then "fall into" RCCPNL,
which may also be used as a CCP return point when a
command does not wish to reassign the disk drive being
used in the execution of a conmiand. You will note that
there are sections of code that may not always seem
needed in my CCP. This is because I modify it for nearly
every specialty system I create. When we begin
designing our own commands, you may see why these
sections of code are left here.
1 antry
point
far rwatart
ng
cc
p Mithout logging in da^ault
dn va
RCCPT«_:
CALL
LD
SUB
LD
OR
JP
JP
eCMCR
A, <FCBFN)
^«.,TEMPDR
(HL)
N2, ERROR
RESTRT
laxtract navt tokan from cot
■«and I
Igat ♦irat char o* tokmn
lany char''
Well, this pretty well covers the main loop of the CCP.
In Part Two we will discuss the various support routines
called by the main loop. If we have the space we will also
begin discussion of how to design your own CCP com-
mands to suit your specific application.
I would recommend that you acquire the CCP source
code, and do some snooping before we meet again. By the
time we finish with the CCP section of our series you will
have a great understanding of this module, and be able to
modify it to suit yourself, with far more computing power
than any standard system could have. Remember that,
unlike the CCP's big brother ZCPR3, our system does not
require any additional memory space, nor direct support
files on your disk. When thinking of all the fun we can
have reworking the CCP, just think of what can be done
when we begin discussions upon the design of the BIOS
and DOS systems! ■
* ••
NEW-DOS Disks AvaUable
An AMPRO format 5V4 DSDD with the files for the
Crowe assembler and the CCP is available from The
Computer Journal for $10 postpaid. Inquire about other
formats.
Additional disks with the BDOS and BIOS portions of
NEW-DOS will be made available when these portions
are published. Anyone making extentions to NEW-DOS or
implementing it for other systems are urged to send their
material to TCJ so that it can be shared with others.
Tom is preparing a user disk library for the AMPRO
little board, and the disks will be distributed by TCJ.
Watch for more details in the next issue !
The Computer Journal / Issue m
21
Variability In The BDS C Standard Library
Porting BDS C To CP/M 86
By Donald Howes
1 his overview is aimed at C programmers who don't
own a copy of the BDS C compiler, but stiU wish to be able
to compile some of the large number of programs which
are available from the group, and not become old before
their time in doing so. If you are like me (I do most of my
work in CP/M-86, using the SuperSoft C compiler), the
following scenario has occured at least once (and
possibly, many times). On getting your latest software
disk from the group, you immediately try to compile a
program. Everything works through the compiler, but
then comes the link step (maybe an assemble step first,
but why make things overly complicated). You think the
machine is having a fit, but it's fascinating, who could
have thought that a three hundred line program could
have generated four pages of link error messages 1 !
Ok, maybe that is a little overblown, but it really can be
a problem getting a BDS C program to link and there are
some programs which I had given up on trying to get to
work (if you want to know, Roff is one, I really wasn't
lying about the four pages of linker errors) . I've managed
to solve the problem in a remarkably easy way. I've
bought a copy of the BDS C compiler. This, however, may
not be a viable alternative for people who are either short
on cash, or don't have a machine which will run both
eight and sixteen bit software (I use a CompuPro
(Viasyn, who's Viasyn?) 8/16-A). Hopefully, this over-
view will help to alert those people who do not have ac-
cess to a BDS C compiler to the variations in the "stan-
dard library" . You will notice the quotes ; one thing that I
did find out is that there really isn't such a thing as a
standard library. What I was able to do was compare the
BDS C library functions to the two CP/M-86 compilers for
which I have documentation (SuperSoft and Digital
Research) and note the variability over the three com-
pilers. The SuperSoft documentation states that they
have attempted to stay as close as possible to the Unix
library, while Digital Research is missing a number of
Unix C functions and have implemented some specialized
functions (there are three variations on creatO, for
example) to take the place of a single Unix function. With
this type of mix (admittedly, not a scientific sample, but
you (k) the best with what you've got) I was able to break
the library functions up into three types. First, there are
the functions which all three compilers agree on. Given
the differences between the compilers, I felt that these
should represent as close to a "standard" function as
there is. These functions will be noted by their con-
spicuous absence from the following list. Second, there
are the functions which both BDS C and one of the other
two compilers define in the same way (from my over-
view, this is generally the SuperSoft compiler), while the
other compiler either does not support the function (the
normal case) or the definition is different. Third, the
cases where both the CP/M-86 compilers do not support
the function, or the definition of the function is different.
These are the ones which will cause the most trouble and
I will flag the entry with two asterisks preceding the fun-
ction name (i.e. **peek(n) ).
Finally, a short note about syntax. The initial section
headuig where the function name is given will name the
function with its list of parameters as they are given in
the BDS C User's Guide (i.e. sleep(n) ). If I refer to any
fimction by name in the descriptive material foUowing
the section heading, no parameters will be given (i.e.
sleep( ) ) . Please don't assume from this that there are no
parameters for that fimction. Also, any parameters that
are mentioned in text will be surrounded by single quotes
(i.e. for sleep(n) the parameter 'n' would be quoted). In
deference to those who will be rummaging thnxigh this
listing in the small hours of the morning, I have taken the
liberty of rearranging the functions from their
categorical order as found in the User's Guide into
aljdiabetical order.
A Note on Buffered I/O Functions
In the foUowing list, only those functions which do not
have the same number of parameters being passed are
shown. However, there is a general difference between
the way BDS C handles buffered I/O and the "standard"
form of those functions. As is mentioned below, the BDS
C version of fopenO does not pass a mode parameter
when opening a file. The "standard" version of this fun-
ction has the form: "fopen(filename,mode,iobuf)" and
returns a valid file descriptor, which is vaed by all other
buffered I/O functions to reference the opened file. BDS C
buffered I/O functions do not use a file descriptor, but
rather, directly reference the I/O buffer 'iobuf (fopenO
does return a file descriptor, but it is not used for other
than error checking, since 'iobuf itself maintains a copy
of the file descriptor for use by other buffered I/O fun-
ctions) . It may be necessary, therefore, for you to place a
'mode' parameter in your buffered I/O calls, for them to
operate correctly, check your compiler docimientation.
aUoc(n)
Returns a pointer to a block of memory 'n' bytes long.
This is the dynamic memory (heap) allocation function
used by BDS C. However, this function is obsolete and
being dropped from the standard libraries of some com-
pilers. You should use caUocO at mallocO instead of
alloc( ) , if they are available in your compiler.
**caU(addr,a,h,b,d) , calla(addr,a,h,b,d)
Both of these functions are used to call a machine
subroutine at location 'addr' . If used outside of the CP/M-
80 environment, almost anything can happen, none of it
good. The best that can be done is to try to determine
what the routine was to do, and recode in standard C. The
22
The Computer Journal / Issue #22
use of these functions makes the program essentially un-
transportable ( at least, not easily) .
••cfsize(fd)
The function calculates the exact number of sectors in
the open File given by the descriptor 'fd', without affec-
ting the associated R/W pointer.
••codend( ) .extemsO ,topofmem() ,endext( )
I have grouped these four functions together, since they
all deal with the calculation of different areas of memory
fpr dynamic use in a program. These functions could
cause real problems, but they're so handy that they will
almost invariably be used if the situation is appropriate.
Codend( ) and extemsO are essentially equivalent fun-
ctions. Codend returns the first byte following the
program code and extemsO returns ttie first byte of the
external data area. These wiU normally be the same,
unless the external data area has been explicitly moved
( this could be done so the code could be ROMmed) .
TopofmemO returns a pointer to the last byte of user
available memory (generally the base of the BDOS in
CP/M-80), while endextO returns a pointer to the byte
following the external data area. You can see that the use
of these two functions will allow for the calculation of the
amount of space in the system which can be used as heap
space.
Some compilers may not have any of these functions
available, or some may be present but the action of the
function may be different (for example, the SuperSoft
compiler has a function named topofmemO, but it fun-
ctions the same as endext( ) in BDS C) . If your compiler
has a way of determining the top of the external data
area, and you are using a small memory model (for 16-bit
compilers) , the size of the heap area can be found by sub-
tracting the top of the external data area from OxFFFF
(the top of the data segment in a small memory model).
My thanks to John Johnson of Professional Microware,
who pointed out this fix.
**creat( filename)
Creates the file of name 'filename', erasing any
existing file which already has that name. Your compiler
may require an additional parameter after 'filename',
the mode in which the file has been opened. Check your
compiler documentation for the parameter list.
••csw( )
Returns the byte value of the console switch register.
•*ermo( ), errmsg(ermum)
Does the same as the external variable ERRNO and the
function perror(s) combination found in other compilers.
•*exec v ( f ilename,argvector )
This function allows the passing of a variable number
of argiiments to the chained program 'filename', by
passing 'argvector' a pointer to an array of string poin-
ters. This could require a real software kludge to port a
program.
••exitO
If there is one function that I would have thought would
have been standard between compilers, it is exitO. No
such luck, each of the three compilers handled the closing
of files and flushing of buffers in a different way. In BDS
C, exitO wiU close all open files, but does not flush any
buffers. This means the a BDS C program will have a call
to fflushO to empty any buffers before a call is made to
exitO. This may not be necessary for you. Check your
compiler documentation to see just how exit( ) functions
in your compiler.
••fabort(fd)
The fimction frees the file descriptor 'fd' without
closing the file. This function was present in the Super-
Soft compiler, but only to maintain some compatability
with BDS C. It's not a great idea to use this function even
if it's present in your library, since some or all of the file
input can be lost if the file had been opened for writing.
•*fcreat(filename,iobuf)
Creates the file 'filename' and opens the file for buf-
fered output using a buffer pointed to by 'iobuf . The size
of the buffer is determined from the BDSCIO.H variable
BUFSIZ. This function is needed, since the BDS C version
of fopen( ) does not support the mode parameter. A call to
fopen of the form "fopen(filename,mode,iobuf)", where
mode is declared as "w" (write only) would accomplish
the same. See below for the BDS C version of fopen( ) .
••fgets(str,iobuf)
Reads a line from the input buffer 'iobuf' and loads it
into the string pointed to by 'str'. A third parameter 'n'
( the number of bytes to be read) may be required by your
compiler. The BDS C version reads the buffer until an end
of line is found in the input stream, not until a specified
number of bytes have been read. The alternate version of
fgetsO has the form "fgets(str,n,iobuf)".
••fopen(filename,iobuf)
Opens the file 'filename' for buffered input and
initializes 'iobuf', the input buffer. This function does not
implement the file I/O mode parameter and, therefore,
may be a parameter short for your version of fopen( ) .
The alternate version of fopen has the form
"fopen( filename,mode,iobuf ) " .
getcharC )
The BDS C version of getchar( ) tests for " C and re-
boots the operating system if found. My other compilers
don't, so if you wish to do this type of interrupt test, it
would have to be coded explicitly.
••getline( strbuf .maxlen )
Returns a text line of characters of maximum length
'maxlen' into the space pointed to by 'strbuf'. This seems
to be a special case of gets (), with the maximum line
length given as a parameter (there is an automatic
return with getlineO when 'maxlen' is reached). GetsO
could be used in place of getline( ) , though you would have
to watch that the length of the string did not exceed the
size of the array into which it was being read, since gets( )
does not check this.
The Computer Journal / Issue #22
23
getval(strptr)
'Strptr' is a pointer to a pointer of a string of ASCII
characters separated by comma's. This is the driving
routine used by initwO and initbO to fill their arrays.
This function probably won't be present in compilers
which allow initiahzation (see the descriptions of initbO
and initwO, below).
initb(array,string),initw(array,string)
These functions are used to perform the initialization of
character and integer arrays respectively. They are not
needed in compilers which allow the initialization of
arrays at the time they are declared.
inp(n),outp(n)
The functions read and write 8-bit values to the port 'n'.
If these functions are not present in your compiler, it
would be possible to accomplish the same thing by the use
of pointers.
isspace(c)
Tests whether the character 'c' is space, tab ( \ t) or
newline ( \ n) character. This same functions may be
called iswhite( ) in other compilers.
khbitO
Polls stdin to see if there is a character present, returns
TRUE orFALSE.
movmem(source,dest,count)
Moves 'count' bytes of memory from location 'source'
to destination 'dest'. The original memory is not
modified, unless the destination area partially overlies
the source.
••oflow(fd)
Quoting the manual "returns true (non-zero) if an over-
flow has occured into the high order (third) byte of the
random-record field of the FOB" . Good luck.
**open(filename,mode)
Opens the file specified by 'filename' for I/O as given
by 'mode'. However, the meanings of the mode values are
different in BDS C. BDS modes are: = input (write
only), 1 = output (read only), 3 = input/output
(read/ write).
pauseO
Tests for console input, looping until a key is pressed.
**peek(n), poke(n,b)
These are equivalent to BASIC PEEK and POKE stet-
ments, and are not really necessary, since C supports in-
direction. Peek(n) can be simulated by initializing a char
pointer:
char *bdosjmp = 0x05; '
This won't work in BDS C or other compilers which don't
support initialization. If the compiler doesn't support
initialization use:
char'bdosjmp;
bdosjmp = (char •) 0x05;
(This will only work in the 8086 environment if the DS
register points to the correct segment. This can't be
guaranteed).
As is pointed out in the BDS C manual, poke( ) is better
accomplished by using pointers :
♦n = b;
putchar(c),putch(c)
The BDS C version of putchar( ) is able to detect the in-
put of " C (and ^ S) during character output. Putch( ) does
not detect these control characters. A call to putcho,
therefore, is equivalent to putcharO in other compilers.
If you want to be able to interrupt character output, you
will have to code an explicit test into the output loop.
qsort(base,nel,width,compar)
This function is used by BDS C to conduct a shell sort.
The type of sort that is conducted may be different for
your compiler (Digital Research does a quick sort) even
though the function name is the same. Check your com-
piler documentation.
*»read(fd,buf,nbl)
Reads the number of blocks given by 'nW (1 block =
128 bytes) from the file given by the file descriptor 'fd' in-
to the buffer 'buf'. Other versions of readO require the
number of bytes to be read as the final parameter, rather
than the number of blocks. To pass a valid parameter,
multiply the value of 'nbl' by 128.
rename(old,new)
Renames the file given by filename 'old' to that given
by filename 'new'. Although there are obvious advan-
tages to this function, it is not supported by Digital
Research, and possibly not by your compiler. Check your
compiler documentation. This could be accomplished by
a BDOS call to change the FCB.
**rsvstle(n)
The function limits the closest approach of the stack
(which grows down from the top of memory) and th
heap (which grows up from the end of the external dat
area) to 'n' bytes. Stack/heap management of this type
generally the responsibility of the programmer.
••setfcb( fcbaddr,filename) ,fcbaddr( fd)
Setfcb( ) initializes a CP/M FCB with the string pointe
to by 'filename', while fcbaddrO returns the address c
the FCB pointed to by 'fd' .
setmem ( addr,count, byte )
The function sets 'count' contiguous bytes starting at
'addr' to the value of 'byte'. This function is used to
initialize buffers and arrays. It is not needed in compilers
which support initialization.
sleep(n)
Suspends the execution of a program for a variable
amount of time. Since how the time delay is calculated is
compiler and processor dependent you should consult
your compiler documentation.
**ungetch(c)
The character 'c' is placed on the console buffer and is
returned by the next call of getchar( ) . This function may
24
The Computer Journal / Issue #22
be called ugetchar ( ) or ungetchar( ) by your compiler.
••write(fd,buf,nbl)
The function writes 'nbl' blocks from the memory
location pointed to by 'buf to the file pointed to by 'fd'.
Other versions of write pass the number of bytes to be
written, rather than the number of blocks. It would be
necessary to multiply the value of 'nbl' by 128, to obtain a
valid parameter. ■
The C Users' Group
The above article was reprinted from The C Users'
Group (CUG)September, 1985 newsletter, with their
permission. A language is only as good as what you can
do with it, and CUG maintains a large library of very
useful programs. We will be reviewing and commenting
on some of their disks in the future, but you should con-
tact Donna Stucky Ward at The C Users' Group, Box 97,
McPherson, KS 67460 for details on joining the group and
a catalog of their disks.
Starting with the next issue Donald Howes will be
writing a column on C language programming, and we
would appreciate your comments and suggestions on the
topics to be covered. We would also like to include your
tips, routines, and questions.
APROTEK 1000™ EPROM PROGRAMMER
only
$250.00
ASmiPlf.lf'XXPBtSt/BSOLimONTOPWGMMMINGBVOMS
The APnOTEK 1000 can program 5 volt. 26XX series through 2564 27XX
series through 27256 artd 68XX devices plus any CMOS versions of the above
tvpes Included with each prograrrirner is a personality module of your choice (others
are only S 1 00 ea when purchased with APftOTEK 10OO\ Later, vou mav re
Quire future modules at only $15 00 ea , postage paid Available personality
modules PM2716, PM2732. Pfy12732A PM2764 PM2764A PM27128
PM27266. PM2632 PM2564 PM68764 Imcludes 68766) 'Please specify
modules by these numbersi
APfiOTEK 1000 comes complete with a menu driven BASIC driver programmer
listing which allows READ, WRITE. COPY and VERIFY with Checksum Easily
adapted for use with IBM. Apple. Kaypro. and other microcomputers with a RS-232
port Also included is a menu driven CPM assembly language driver listing with Z SO
IDARTi and 8080 182511 I O port examples Interface is a simple 3-wire RS 232C
with a female DB-25 connector A handshake character is sent by the programmer
after programming each byte The interface is switch selectable at the following
6 baud rates 300 1 2k. 2 4k 4 Bk. 9 6k and 19 2k baud Data format lot program
minq IS absolute code ' it e . it will program exactly what it is sent starting at
EPROM address 0) Other standard downloading formats ate easily converted to
absolute lobiect) code
The APROreK 1000 is truly universal It comes standard at 1 1 7 VAC 50 60 HZ
and may be internally jumpered for 220-240 VAC 50 60 A2 FCC verification
ICLASS B) has been obtained for the APflOTlK 1000
AmOTtK 1000 it eovrmd by m t r—r P*ra and labor wmrrtnly.
f IN ALLY — A Simplm, InmMpmnaivm Solution To Eraaing E PROMS
AfmOTEK 200'" EPPOM ERASER
Simply insert one or two EPROMS
and switch ON In about 10 minutes.
you switch OFF and are ready to
reprogram
APROTEK 200'" onl~/ S4S.0O.
APROTEK 300'" only S60 00.
This eraser is identical to APROTEK
200'" but has a built-m timer so that the
ultraviolet lamp automatically turns off m
10 minutes, eliminating any risk of overex-
posure damage to your EPROMS
APROTEK 300'" onl~, teOOO
APROPOS TECHNOLOGY
1071-A AvMiMa Acno. CanwMo. CA 93010
CALL OUR TOLL FREE ORDER UNES TODAY:
1(8001 962 6800 USA or 1(8001 982 3800 CALIfORMA
TECHNICAL INFORMATION: 1-I80SI 482-3604
Add Shipping Per Item: »3 OOConi U.S. »6,00CAN, M»kico, HI. AK, UPS Blue
RAMgOe^
CLOCKWORKS
The real-time ck>d card for ike Appie" featires:
• PRODOS/APPLEWORKS" ond DOS 3.3 compatible
• 24 hour and 12 hour AM/PM formats
• Time increments of 1 millisecond to 99 years
• Automatically time ond date stamps your files
•Powerful on-board firmware in 4K EPROM
• High capocity LITHIUM* coincell battery
• Displays the date and time on Appleworks- screen
• Eignt BSR serial ports for future expansion
• Full documentation included in a
users manual
• Includes more software on disk
^99
ALL PRODUCTS MADE m USA
S YEAR EXCLUSIVE WARRAMT
FREE SHVnNG CONTINDITAL USA/uaMed itec oocr
VKA, MASTCRCHARGE ACCEPTED
An advanced digital I/O interface
cord for the Apple". Provides four 8-
bit ports ond two additional lines for
handshake per port. Has interrupt
orbitrotion circuit, interrupt routing
switches, and more. Excellent choice
for monitoring and control applica-
tions. New low price 165.
EXTEND-50'
• Extends the lie to 128K RAM
• Adds 80 column video display
• Enhances spreadsheet and word-
processor viewing
• Allows double nigh resolution
grophics
Easily installs in slot 3 of the Apple
lie™. Comes with full documentation.
ITS
MICROPORT32'"
Reliably extends oil 50 signals at inter-
nal slots to a 50 pin DIP. One side plugs
into on Apple" slot, the other plugs
into ony breodboord/protoboord.
Now you con easily wire on interfoce
cord circuit without tedious wirewrop-
ping or soldering techniques. A must
tor every designer. Only 134.
Micro Systems Research
4099 UMttnnt D"
K*nnM«w G«Org'« JO'44
=404/928-9394
The Computer Journal / Issue #22
25
The SCSI Interface
Introductory Column To A Series
By Rick Lehrbaum
X research the history of SCSI, I
had lunch with Larry Boucher, the
founder of SCSI. It all began in the
Spring of 1979 when Larry was the
Director of Design Services at
Shugart Associates, and Shugart
was getting ready to announce
another new Winchester disk drive
product. As usual, it would take IV2
to 2 years before Shugart could enjoy
widespread sales of the new drive
since it took that long for all the con-
troller designers to debug their
phase-locked loops. But that was the
way it had to be back then— there
was no standardized I/O bus in the
micro world. (Unless you want to
count RS-232!)
Larry decided that what Shugart
needed was a way to speed up con-
troller design. Before coming to
Shugart, Larry had worked at IBM,
and it occurred to him that
something like the IBM OEM Chan-
nel also made sense for micro's. So
Larry, along with Bemie Nieman
(who worked for Larry) and Jim
Korpi (who worked for Bemie),
wrote the spec for a new interface to
be proposed for all future Shugart
disk controllers. They called it the
Shugart Associates Standard Inter-
face, or "SASI." According to Larry,
there were two major objectives in
defining SASI: (1) Make it the
cheapest possible interface with an
8080-Iike bus; and (2) Outperform
the IBM OEM Channel bus, which
ran around 500,000 bytes per second
average throughput. Both goals
were met.
The rest is history. Shugart of-
ficiaUy adopted the new SASI inter-
face in July 1979, and commissioned
Data Technology Corporation (DTC)
to do the first SASI disk controller in
August 1979. DTC performed ad-
mirably, under the direction of Dave
Tsang, delivering samples of the
new SASI controller board to
Shugart in December, followed by
delivery of 25 production boards in
January 1980. A new industry stan-
dard was bom. But few knew it. . .
In July 1981, NCR began taking an
interest in SASI. In December 1981,
John Lohmeyer (NCR) and Hank
Meyer (Shugart) formally proposed
to the American National Standards
Institute (ANSI) that it adopt SASI
as a small computer intelligent
peripheral interface. An ANSI
committee called "ANSC X3T9.3"
was in the process of defining "The
next microcomputer I/O interface."
They tumed SASI down! It seemed
all was lost.
But there was another ANSI com-
mittee, currently inactive, which
had been chartered to define a
microcomputer "peer-to-peer"
protocol. "ANSC X3T9.2," as this
other committee was called, took
SASI under its wing, in February
1982. One of the first official orders of
business was to change SASI's
name, since it contained Shugart's
name. They settled on "Small Com-
puter System Interface."
In the months that followed, ANSC
X3T9.2, under the able direction of
Bill Burr (National Bureau of Stan-
dards), hammered out a thorough
and percise specification (currently
over 180 pages long!) which makes
SCSI one of the bext docimiented in-
terface standards in the computer
industry.
Last summer, the members of
ANSC X3T9.2 unanimously approved
the standard, forwarding it to the
ANSI parent organization for public
review and final approval. Short of
editorial and other minor correc-
tions, the final SCSI specification is
in hand.
And now, a few questions from
readers...
WhattoSCIS?
SCSI stands for "Small Computer
System Interface" and is quickly
becoming the most popular interface
for connecting hard disk drives to
small computers of every type. But
as you'll see later, SCSI can be used
for a lot more than that.
Why should I use SCSI?
You should use SCSI if you need an
easy way to make your computer or
computerized device expandable.
Today, SCSI is mostly used for ad-
ding hard disk and tape controllers
and drives. But soon, there will be
lots of other functions to choose
from, including: optical storage,
network interfaces, graphics
displays, co-processors, and more.
SCSI has a number of important
advantages over other ways of at-
taching add-on's to a small computer
system. One of the biggest advan-
tages of SCSI is that is is an easy and
inexpensive interface to add to any
computer. It also simplifies your sof-
tware hassles: when implemented
correctly, SCSI allows you to change
from one brand of device (such as a
hard disk controller and drive) to
another, with little or no software
modifications.
How do you pronounce "SCSI"?
I'm glad you asked that question!
There has really been a lot of time
and energy arguing about how to
pronounce SCSI. Well, it pretty
much boils down to either pronoun-
cing the word SCSI as SKU-zzy, or
spelling it out S-C-S-I. My own per
sonal preference is "SCSI." On the
other hand, surveys show that 78% of
corporate marketing executives
prefer spelling it out.
Where can I get more information?
You have two choices: (1) Read
this colunm in The Computer Jour-
nal, or (2) Be the fvst one on your
block to have an official copy of the
"ANSC X3T9.2 SCSI Specification,"
by sending $20, along with a self-
addressed mailing label to: X3
Secretariat, Computer and Business
Equipment Manufacturers Assn.,
311 First Street NW, Suite 500,
Washington, DC 2000L
Watch for "An Introduction to SC-
SI" in the next issue of The Com-
puter Journal, and send your
26
The Computer Journal / Issue #22
NGS FORTH
A FAST FORTH,
OPTIMIZED FOR THE IBM
PERSONAL COMPUTER ASD
MS-DOS COMPATIBLES.
STAMDARD FEATURES
INCLDDE;
•79 STANDARD
•DIRECT I/O ACCESS
•FULL ACCESS TO MS-DOS
FILES AND FUNCTIONS
•ENVIRONMENT SAVE
& LOAD
rtfULTI -SEGMENTED FOR
LARGE APPLICATIONS
•EXTENDED ADDRESSING
•MEMORY ALLOCATION
CONFIGURABLE ON-LINE
•AUTO LOAD SCREEN BOOT
•LINE & SCREEN EDITORS
•DECC»CPILER AND
DEBUGGING AIDS
•8088 ASSEMBI£R
•GRAPHICS & SOUND
•NGS ENHANCEMENTS
•DETAII£D MANUAL
•INEXPENSIVE UPGRADES
•NGS USER NEWSLETTER
A COMPLETE FORTH
DEVELOPMENT SYSTEM.
PRICES BThia AT $70~
IIEW-*>HP-150 & HP-110
VERSIOMS AVAILABLE
AT
»
MBZT aEMERATION SYSTEMS
P.O.BOX 2987
SAMTA CLARA, CA. 950S5
(408) 241-5909
questions, ideas, or comments to the
Editor at TCJ or to Rick at the
following address. ■
Rick Lehrbaum
VP of Engineering
AMPRO Computers, Inc.
PO Box 390427
Mountain View, CA 94039
SCSI NEWS
This section will bring you the
latest news and information about
SCSI related products and ap-
plications. Your input and experien-
ces will be greatly appreciated.
SCSI RAM-DISK— The AMPRO SC-
SI/RAM suitable for use in both
single- and multi-master system ap-
plications is available with either
512K bytes or 1 megabyte of RAM,
and can be used in any system
having an SCSI (SASI) interface. By
adding one or more SCSI/RAM units
to a host computer, system memory
need not be used as a RAM disk,
thereby freeing the computer's
system RAM for program functions.
Data can be transfered over the SCSI
bus at up to 1.5 megabytes per
second, and effective SCSI/RAM
disk transfer rates are generally as
fast as when using system RAM. In
addition, the SCSI/RAM does not
clear its memory on SCSI bus reset,
thereby allowing the SCSI/RAM to
be used for system memory backup
on power-fail detection.
Inexpensive SCSI host adapters
aUow connection to a wide variety of
host computers, including the IBM-
PC and AT, VME-bus, Multibus, and
S-100. The SCSI/RAM, with 512K
bytes of on-board RAM occupies a
single 5V4 X 7% inch circuit card,
and has the same mounting holes
and footprint as industry standard
5V4 inch disk drives. A daughter
board may be added to expand the
RAM disk size to 1 megabyte.
Available for $395 from AMPRO
Computers, 67 E. Evelyn Ave, Moun-
tain View, CA 94039, (415) 962-0230
SCSI Printer Server— The AMPRO
SCSI/PRN intelligent printer server
is suitable for both single- and mulit-
master systems. Up to seven SCSI
hosts can connect to a single SC-
SI/PRN, sharing printer and spool
buffer resources, and maximum
data transfer rate is 1.5 megabytes
per second. The SCSI/PRN's three
printer interfaces allow
simultaneous connection of one Cen-
tronics compatible printer and two
RS232C serial printers, with host
controlled baud rates of up to 19.2K
baud. Onboard memory of 512K
bytes, expandable to 1MB via
daughter board, is used as a spool
buffer. Available from AMPRO for
$449.
SCSI Real-Time I/O-The AMPRO
SCSI/IOP is an intelligent processor
which adds read-time control and
measurement capabilities to any
computer system having an SCSI in-
terface. The SCSI/IOP plugs into a
normal STD bus card cage, and can
control STD bus I/O boards such as
analog-to-digital converters, video
display controllers, speech syn-
thesizers, network interfaces, etc.
Low cost SCSI host adapters are
available for many computer
systems, and SCSI's bus arbitration
feattu^ permits up to eight host
computers and SCSI/IOP's to share
resources.
The SCSI/IOP includes a 4 or 6
mHz Z80 microprocessor, eight byte-
wide memory sockets for up to 64K
of EPROM/RAM memory, and a Z80
counter/timer controller. Fimrware
on the SCSI/IOP supports a number
of basic operations, and both the
Initiator and Target functions of SC-
SI which include peer-to-peer
message capability. The SCSI/IOP
can be used in hierarchical real-time
control system configurations, or
where either host or I/O device
redundancy is required. Available
from AMPRO with preliminary
pricing of $119.
SCSI Hard Disk Subsystem— The
AMPRO hard disk subsystem con-
sisting of an SASI S1610-4 controller,
10 Mbyte half height hard drive, box
with fan & supply, and cables is
available 100% complete and tested
for $599 from Peripheral Land, 3400
El Camino, Suite 10, Santa Qara, CA
95051 (408) 248-5282. ■
The Computer Journal / Issue #22
27
Indexed Sequential Access Method Files
Using Turbo Pascal ISAM Files
By Jerry Houston
ISAM, or Indexed Sequential Access Method, files are
the type most commonly used for business purposes on
large computers. ISAM file records are accessed accor-
ding to a KEY FIELD for reading, writing, or updating.
This method provides random access to the file records,
aUowing simple updates and quick retrieval of a par-
ticular record.
Operating systems that support ISAM files directly are
usually found on minicomputers and mainframes. There
is certainly a cost to pay in terms of overhead (both in
processing requirements and in media space), but the
advantages are generally thought to be worth the cost.
In the simple example that accompanies this article,
an ISAM-type file is set up as a phone directory. The key
field in each record is the name of a person or a company,
and the rest of the record contains just a phone number.
Now, if the prospect of another phone list program
doesn't exactly make your floppies quiver, consider that
you can easily define more fields for the file, and the key
field can be anything you want it to be— a name, em-
ployee number, stock number, or nearly any other infor-
mation upon which you'd like the file to be organized.
Taking that modification a step further, the index for
the file could be checked to see whether it INCLUDES a
particular key word— easy to do in Turbo Pascal— and a
large file of The Computer Journal articles could be sear-
ched for a particular content.
In the large computer systems that support ISAM files
directly, the key fields are checked against two or more
kinds of index on the disk drive itself. The desired KEY
FIELD is compared to the entries in a short sequential
file called a CYLINDER INDEX, which lists the upper
limits for the key fields that are located on a particular
C¥LINDER (the same track extended through all the
recording surfaces of the disk-pack). Once the head ac-
cess mechanisms have positioned the read-write heads to
access a particular cylinder, then a track index is con-
sulted to determine the track on which the desired record
can be found, and the proper read-write head is elec-
tronically switched into action. Then it's just a matter of
waiting until the right record rotates under the head, a
delay called latency, or rotational delay.
A big advantage of ISAM files over ordinary sequential
files becomes apparent when it's necessary to update
one. A sequential file must be re-created in its entirety
just to change a single record. Records in an ISAM file
can be re-written, making it easy to correct fields in in-
dividual records. It's almost too obvious to point out, but
applications that require access to a limited number of
records from a large file are better served with random-
access files (such as ISAM), so that aU the previous
records don't have to be examined in order to find the one
that's needed.
Random Access On Micros
Most smaU computers have random access capability,
but somehow the program needs to determine which
record is to be read (or written). Random files can be
DIRECT ACCESS FILES, in which case the program
identifies the exact physical location (track and sector)
where the record is located, or they can be RELATIVE
FILES, where each record number is relative to the
beginning of the file. The computer already must know
how long each record is, and it can find the 29th record in
a relative file by passing over the first 28, then accessing
the next.
The trouble with this is, how is the computer to know
that the address and phone number for XYZ, Inc. is in
record number 127, or that the record for product number
C-12285-BR is located on track 2A, sector 09? The answer,
of course, is that it needs an INDEX, as in ISAM.
Using the relative files that are available with every
disk-equiiq)ed computer, and accessible from every
language, it's possible to duplicate the ISAM function
with applications programming. This requires keeping a
small sequential file on the disk that ctHitains the key
fields and corresponding record numbers of the main
(relative) file. At the beginning of the program, and
whenever the file is updated, the index file is read into a
table in memory which can be searched to find the
location of whatever record is needed. If a file is designed
for direct-access, then the index must contain the key
field and the physical track location where the record can
be found. Since relative files are easier to work with and
more versatile in some respects, this article will concert
itself with simulating ISAM with Turbo Pascal relative
files.
Program ISAM.PAS
The Turbo Pascal program that accompanies this ar-
ticle maintains an ISAM file of names and phone num-
bers in such a way that the user can type in a name (the
KEY FIELD) and the computer will deliver up the phone
number associated with it in the file.
This example program was purposely kept simple, but
it would be an easy matter to expand the records in the
ISAM file to hold whatever information is required for a
more complex application. Once we've covered the
example program in detail, I'll mention a way to make it
even better, if you're so inclined.
Portability of Code
In keeping with my philosophy that a programming
process (design, coding, testing) shouldn't be done twice
if once will do, I've written the procedures and functions
of the accompanying program with local variables and
parameter lists (also called argument lists). Thus, these
sections can be stored separately in a Pascal library and
28
The Computer Journal / Issue #22
used whenever a progranuning project requires ISAM
files. They can be read into the source code being
developed, and made a part of the new program with
relatively little effort. If GLOBAL variables (rather than
passed parameters) are used, each procedure and fun-
ction will need to be modified extensively to agree with
the variables used in every new program.
Run-Time Narrative
When ISAM.PAS is compiled and run, it will look for an
index file that shares the name of the ISAM file being
used. The ISAM file will have an extension of .ISA, and
the matching index file will end with .KEY. The first time
the program is nm, of course, neither of these files will
exist, and the file-read sections are coded to understand
this.
The menu that appears at the beginning of the program
will offer the choices :
Q=Quit R=Read A=Add
D=Delete C=Change
ADD will write new records to the ISAM file. The user
is prompted for a name to be used as the key field, then
the phone number to be stored with it. The name and
PHONE number go into the PHONE.ISM file, the name
and the RECORD number (from the ISAM file) go into
the PHONE. KEY file, and also into the table of keys
that's maintained in memory. Trying to add a new record
that has the same key field as an existing record is a big
no-no for ISAM file processing, so an appropriate error
message is displayed if this is attempted, and the ad-
dition is not made.
DELETE will not remove a record physically from the
ISAM file, nor its key from the index, but it will replace
the phone number with a message that says it's been
deleted. This function of the program could be changed so
that the record actually IS deleted (at least, used for the
next ADD), but at a cost of additional complexity that
isn't warranted in such an example. Trying to delete a
record that doesn't exist is taboo, and earns the user a
scolding from the computer.
CHANGE allows the phone number to be edited. In a
more complex application you would want to allow
editing of all the fields EXCEPT the KEY FIELD. If that
needed to be changed, a DELETE would be appropriate
instead. Naturally, an attempt to change a record that
doesn't exist is useless, and will be trapped as an error
condition.
QUIT is just a graceful way out of the program, back to
the operating system. From the menu part of the
program there are no files to close or other End Of Job
processing to do, so it just means a quick trip to the end of
the main logic. All the other functions re-run the main
logic, so that a variety of tasks can be carried out while
the program is running.
The Main Flow of Logic
I wrote this program knowing that I would be ex-
plaining it in detail in this text, so it isn't as full of com-
ments as it ordinarily would be. Remember that you'll
probably want to use this code again and again, so it
wouldn't hurt to add additional comments as you enter
the source. A few extra minutes of typing now can save
hours of debugging later, when you want to use this
method to access complex files in a new application— and
that goes for all source code. (End of Lecture, I promise. )
Let's take a look at the mainline logic first, that last
chunk of code that begins with BEGIN and ends with
END. Because this program is written modularly, the
main logic is short and simple. (It's not easy to write
si>aghetti-c6de in Pascal but believe it or not, I've seen it
done!)
LoadKeys is a procedure that reads the .KEY file from
the disk and loads the values found there into the two
arrays IndexAray[1..200] and KeyAray[1..200] that make
up the file index table in memory. The array limits of 200
were chosen entirely arbitrarily, and might be much
higher in an application program, depending on need and
the availability of variable storage space. You can see
one purpose for the RetumCode that many of these
procedures send back to their calling module— if the ap-
propriate .KEY file can't be found on the disk, the
LoadKeys procedure sends back a return code of — , and
the main logic understands to print an error message to
that effect and bail out to STOP : .
START: is a label that tells the program where to go
when a restart is required. This is done after all the menu
functions except QUIT, which sends control instead to
STOP: at the bottom.
The line that writes the heading and menu items to the
screen starts out with a #26 as the first item printed.
That's a screen-clear character for many computers, and
could have been written just as well with a control Z.
Turbo Pascal also offers a screen clear procedure, but
this is shorter to type. Other WriteO statements in this
program use control M and control J to produce a
carriage-return and a line-feed, respectively. Alter-
nately, those could be coded as #13 and #10.
After Choice is read, it's changed to upper case with the
UPCASEO function that's built-in. This makes it easier
to write the subsequent CASE STRUCTURE so that up-
per and lower case selections will both be honored. The
arguments of the case structure, of course, match the of-
ferings from the menu line at the top of the screen, and all
except 'Q' will execute a particular procedure written as
a demo.
That's all there is to the main logic. Thanks to struc-
tured modular programming, a problem that's too com-
plex to grasp aU at one time can be broken down into
separate tasks that are easily comprehensible. Now those
smaller tasks will be broken down further into individual
steps with an explanation for each.
Of Types, Variables, Functions, and Procedures
Those who are new to Turbo Pascal (and I hope that
many of you are reading this) may be a little unclear
about the use of the TYPE declaration. It's pretty easy to
understand why Turbo (or even BASIC) wants to know
whether a variable is to be treated as a real number or an
integer, as the two are stored differently in memory and
in files. They require different numbers of bytes and are
treated differently by the compiler. Fact is, a Pascal
programmer isn't limited to the pre-declared types of
variables that most languages provide, but is free to
29
SETS YOU
Free to create computer environments right for you . . . free to automate repetitive tasks . . . free to
increase your productivity. Z-System, tlie tiigh-performance 8-bit operating system that flies!
Optimized assembly language code — full software development system with linkable libraries of often
needed subroutines -relocating (ROM and RAM) macro assembler, linker, librarian, cross-reference
table generator, debuggers, translators, disassembler — ready to free you
III
New generation communications package provides levels offlexibility, func-
TERM III tionality, performance not available until now. Replaces BYE and XMODEM
master/server local area network capability . . . public or private bulletin board
and electronic message handling are integral features . . . auto-dial/answer, menu install
XMODEM (CRC/Checksum), MODEM? Batch, Kermit, CIS, and XON/XOFF protocols .
100-page manual $99.00
Rolls Royce of message handling systems , . . mates with TERM III or BYE for
Z-MSG most advanced overall electronic mail/file transfer capabilities . . . menu
installed . extreme configurability . . . many levels of access and security
word, phrase editor, field search . complete message manipulation and database
maintenance $99.95
Elegant, menu and command-line driven file and disk catalog manager.
DISCAT Generates and controls multiple master catalogs, working catalog used for
update quickness. Nine flexible modules easily altered by user for custom
requirements. Works with Z shells (VMENU, VFILER, MENU), aliases, and multiple commands
per line $39.99
ZCPR3: The Manual Bound, 350 pages, typeset book describes features of ZCPR3
command processor, how it works, how to install, and detailed command usage. Bible to
understand Z-System $19.95
ZCPR3 and I/OPS Loose-leaf book, 50 pages, 8-1/2" by 11", describes ins-and-outs of
input/output processing using Z-System Shows how to modify your BIOS to include I/O
redirection . . . complements The Manual $9.95
More missing links found — 2 Application Progams! Fly with eagles! Our programs promote high
perfonnance through flexibility! Productivity results from dynamically changeable work environments,
matching operator to tasks and machines.
Above programs require 48K-byte memory, ZCPR3, Z-Com, or Z-System, and Z80/NSC800/HD64180-
based computer. Shipping from stocl<. State desired disi< format, plus two acceptable alternatives. As
payment, we accept Visa, /Mastercard, personal checks, money orders, and purchase orders from
established companies. We also ship UPS COD.
Call or write to place order or to obtain literature.
m^^ EchelOllf IllC* 101 First street • Suite 427 • Los Altos, CA 94022 • 415/ 948-3820
30
The Computer Journal / Issue #22
define types that are consistent with the present needs.
In this program, the procedures that access the files
will need to be passed a parameter that tells them what
file name to look for. Since the parameter can be called
by one variable name on the sending end, and by
something entirely different on the receiving end, the
procedure must be able to identify it according to (1) its
location in the parameter list and (2) its type. Because
I've defined a TYPE called AnyFile, a string that's able
to contain ten characters, I can pass a file name along
from a "calling" procedure to a "called" procedure in a
list of arguments. The argument list specifies to the
called procedure that the file name is first in the list, and
also what type of variable it is. This helps to make the
code "portable", in that it can be used in various
programs with little or no customizing needed.
Similarly, I'll be using a lot of string variables that con-
tain a 30-character name and a lot of string variables that
contain a 20-character phone number. These are defined
as type NAME and type PHONE.
Even entire records can be defined as a TYPE, as
shown by the next two entries. The records in the ISAM
file will all contain a NAME and a PHONE (which were
previously defined as types of their own, so these don't
need to be spelled out as to how many characters, etc.)
and the INDEX file will contain records that each contain
a NAME and a record number, which is of the ordinary
type INTEGER.
To digress for just a minute, if the number of records
were to be limited to less than 256 for an application like
this, it would be appropriate to use type BYTE instead of
INTEGER for all the variables that have to do with
record numbers and counters. Each variable would then
require only one byte of storage or memory instead of
two.
Now comes the familiar declaration for all the
GLOBAL variables in the program, the ones that are to
maintain their values from one procedure to the next. As
you can see, there are some variables that are declared
as ordinary types, such as INTEGER, and others that are
declared as the special types that were defined above.
FINDEXO
FINDEX is my shorthand for Find Index, a function
that searches through the table of key fields, and for each
key requested finds the appropriate record number in the
ISAM data file. It's a function, rather than a procedure,
because of the way it's written and used. When the ap-
propriate parameters are passed to this function,
referring to FINDEX( ) is all that's needed to get an an-
swer. One way of thinking of it is that you RUN a
procedure, but you MAKE USE OF a function. To find the
record number for a variable called NameIn, for exam-
ple, from among MaxKeys number of entries, all we need
to say is:
RecordNumber : = FINDEX(NameIn,MaxKeys) ;
and we can use a function anywhere a variable would be
at home, such as:
Write(FINDEX(NameIn,MaxKeys) ) ;
FINDEX begins by initializing COUNT to 0. Since
COUNT is declared as a variable within the function
FINDEX, it is LOCAL to this function. Even though there
are other variables called COUNT elsewhere in the
program, they won't get confused. This is one of the
reasons why functions and procedures that use local
variables are so portable from one program to another.
FINDEXCode and FOUND, a Boolean truth flag, are also
declared here, and exist only within FINDEX.
From there on, it's a relatively simple function, and
even TurBeginners (sorry, I just couldn't resist, and this
IS supposed to be a tutorial...) won't have any problems
with the logic. The only line that's not entirely clear is the
one that actually compares the given name with the
names in the table. It starts out with :
If Copy(KeyAray[Count] ,l,Length(IndexKey) )
= IndexKey then...
Rather than requiring the given name to be an exact
match for the key field, I've written the program to allow
a partial— BUT CORRECT— name to be used instead.
The comparison is made to the key fields in the table only
up to the length of the given name. That way, I can find
the phone number for "Remote Measurement Systems,
Inc." by typing just "Rem", if I'm sure that none of the
other records starts with the same three letters. If there
aren't any others that start with "R", I could just type
that, but that would be taking a fair-sized chance. I need
to enter enough of the name that there is no question
which record is required, as the program will read the
record that corresponds to the first match it makes.
LOADKEYS
LoadKeys is a procedure, so it's something to RUN, not
USE. The program doesn't expect LoadKeys to take on a
value like a function, although this procedure does, in
fact, pass a RetumCode back to the calling module. The
return code goes back under its own variable name, not
the name LoadKeys. The object of this procedure is to
read the .KEY file from the disk and load the values it
finds there into the two arrays that make up the index
table in memory.
Following the procedure name is a good example of a
parameter list. I'll discuss just this one in detail, and
you'll be able to see the similarity between this one and
the parameter lists in the other procedures.
First of all, if the procedure is to load a file into
memory, it needs to know from which file to read. The
file name COULD have been declared as a global
variable, but then it would have to be done that way in
every program that makes use of this procedure, and the
procedure would be workable only with one file name per
program. Instead, the file takes on the name that this
procedure associates with the parameter FileName,
which is defined as type AnyFile. The calling logic can
place a literal value, such as a file name of 'PHONE' in
the first spot in the parameter list, and the called
procedure will find it there.
The other way of passing these parameters is shown
next, with two parameters passed as variables. There are
a lot of procedures in this program that make use of the
variables MaxKeys and RetumCode, which have already
The Computer Journal / Issue i^'22
31
been explained, and it's easiest to pass those back and
forth as variables in the parameter list. I happen to use
MaxKeys and RetumCode for the very same purposes
each time I use these procedures in other programs, so
that's not difficult. You'll notice that the keyword VAR
precedes these variables in the parameter list, just as it
would in an ordinary variable declaration. Of course, if I
intend to have a program work with multiple ISAM files,
I have to be sure that MaxKeys is assigned properly
before this procedure is called. RetumCode gets its value
within the procedure and passes it back to the calling
module, so it doesn't have to be initialized before use.
Since this procedure accesses a disk file, it makes use
of the Turbo compiler directives {$1-} and {$1+} which
turn off system disk error handling and turn it back on
again, respectively. If there's a problem like "file not
found", I want to deal with it from within this program,
not have the operating system crash the program on that
account. After the error-checking is turned off, an attem-
pt to open a buffer for the file using the statement
Reset (IndexFile) is all that's needed to see whether the
file exists. The Turbo Pascal function lOResult will
return a value of zero if everything was all right, or an
I/O error number if it wasn't. If things went well, this
procedure turns error checking back over to the system
and continues. If they didn't, a value of -1 is placed into
RetumCode, the parameter that will be passed back to
the module that called LoadKeys, and control is passed to
the label RETURN: at the bottom of this procedure. That
calling module is written so as to understand that a
RetumCode of -1 means the .KEY file wasn't there.
About the only other obscure code in this procedure is
the part that starts out with the line :
WithlndexRecDo...
IndexRec is defined as a variable of type INDEX, which
means that each IndexRec actually contains the
variables ISAMName and ISAMPhone, which are of type
NAME and PHONE, respectively. In order to access
these "buried" variables, we need to enclose all referen-
ces to them between statements like the above, and an
"End;". Otherwise, the compiler will swear that it
doesn't know what variables we're talking about. Trust
me, this is only confusing at first— it becomes pretty in-
tuitive after you've used records this way a few times.
The convenience of being able to refer to entire records
by one variable name (such as when reading or writing to
a fUe) is wonderful. By the way, the WITH statements
can be nested, and if you write some lines that need to ac-
cess variables that are shared by more than one record at
a time (like a variable that's stored in two different files) ,
you can write it such as :
With IndexRec, DataRec Do
End;
It's pretty clear, then, that this procedure reads the file of
the same name as the ISAM file, but with an extension of
HTBASIC
Multitasking BASIC Compiler
Windowing
Multitasking
ROMable code
KetursivR
Prire
R(IH7 suppcirt
Multi-line fiiiu ti{ins
MTBASIC
Y
Y
Y
Y
$49.95
optional
Y
MBASIC
n
n
n
n
$:i5ii 11(1
n
n
TCRBO PASCAL
IBM only
n
n
Y
SH^I MS
opticinal
>■
CBASIC2
n
n
n
n
SwKi no
n
n
BASCOM
n
n
.n
n
S:v)r, on
n
n
MTBASIC, the multitasking Basic compiler, has everything you need!
Complete Package
Interactive Compiler
VITBASIC is an interactive compiler
and a unique Basic language. MTBASIC
is easy to use since you can write pro-
grams in an interactive environment and
them compile them using only one com-
mand. MTBASIC is easy to learn because
it is similar to many other Basics. The
biggest advantage of using a compiled
Basic is FAST PROGRAMS. With
MTBASIC you get speed and advanced
features.
OOFIAiainc^
Features
Multitasking
Windowing
Interactive
Compiles in seconds
Multi-line functions
No runtime fee
Handles interrupts
Fast native code
ROMable code
Formatted I/O
Assembly language calls
In-line machine code
The MTBASIC package includes all
the necessary software to run in inter-
preter or compiler mode, an installation
program (so any system can use win-
dows), demonstration programs, and a
comprehensive manual.
Ordering
MTBASIC is available forCP M. MS-DOS. and
HC-DOS systems for $49.95 MTBASIC with
8087 support is available for MS-DOS for S79 93
Shipping is $3.50 ($10 00 overseasi MD
residents add 5% sales tax ,MC. \'isa. checks
and COD accepted.
P.O. Box 2412 Columbia, MD 21045-1412 301/792-8096
32
The Computer Journal / Issue #22
Program ISAM;
< Demonstration o-f reading and *»riting an ISAM-type -file with Turbo Pascal >
Label Start, Stop; <labels used in main logic only>
Type AnyFile = StringC103;
Name = String[30];
= StringC203;
= Record
ISAMName : Name;
ISAMPhone : Phone;
End;
= Record
KeyField : Name;
RecNum : Integer;
End;
^declaration o-f non-standard types>
Phone
ISAM
INDEX
<6LOBAL variables that retain their>
< values throughout the program >
Integer;
<LOCAL variables that exist anly>
{within the function FINDEXO >
VAR INDEXFile : File of INDEX;
ISAMFile : File o-f ISAM;
INDEXRec : INDEX;
ISAMRec : ISAM;
IndexAray : Array t 1 .. 2003 of Integer;
KeyAray : ArrayC1..200] of Name;
Choice : Char;
Name In : Name;
F^oneln : Phone;
MaxKeys : Integer;
ReturnCode: Integer;
Function FINDEX < INDEXKey: Name; Max : Integer)
Label Return;
VAR Count : Integer;
FINDEXCode : Integer;
Found : Boolean;
Begin
Count := 0;
FINDEXCode := 0;
Found := False;
With INDEXRec Do
Begin
Repeat
Count := Count * 1;
If Copy (KeyArayCCount 3, 1, Length <IndexKey> ) = IndexKey then
Begin
FINDEXCode := IndexArayCCount 3;
Found := True;
End;
Until ((Found = True) or (Count >= Max));
End;
Return:
If (Found = True) then FINDEX := FINDEXCode Else FINDEX :» -2;
End;
<' opens up' INDEXRec to get access)
{to the variables inside it >
Procedure LoadKeys(Fi leName: AnyFi le; Var MaxKeys: Integer ; ReturnCode: Integer) ;
Label Return;
W^r Count : Integer;
Begin
Assign<IndexFile,FileName * '.KEY');
{♦I-> {turns off system error — checking)
Reset ( I ndex File);
{«!-«-} {error -checking back on here)
If lOResult <> then {checks whether any error happened)
Begin
ReturnCode := -1;
Boto Return;
End;
The Computer Journal / Issue #22
33
.KEY, and puts the names it finds there into an array
called KeyAray[1..200] and the record numbers into
another array called IndexAray[l.200]. These two arrays
make up the table in memory that is searched to find the
appropriate record number for any name that's
requested.
From this point on, I'll offer less explanation for each
procedure, just pointing out the logic that may not be ob-
vious, and the syntax that might be unclear to someone
starting out with Turbo.
READISAMO
ReadlSAM is the procedure to read the ISAM file, and
the arguments (parameters) passed to it include the file
name and the key field being sought, with the third
argument— the RetumCode— that goes back to the
calling module to identify an error.
First the function FINDEX( ) is called, and FINDEX( )
will contain either the value of the record number for the
key field that's wanted or a return code that indicates an
error. If it's an error (less than zero), ReadlSAM just
goes back where it came from with RetumCode the same
as what came from FINDEX( ) . If it's a legitimate record
number instead, then the ISAMFile is accessed and a
record read from RetumCode -1. The reason for the -1
is that records are numbered in a Pascal file starting at
zero, but we tend to think more logically when the first
record is numbered "one". If this little irregularity is
tolerated here, then all the rest of the logic can beUeve
that the first record is #1, the second is #2, and so on.
If the ISAM file isn't on the disk, the RetumCode is
changed to -3 before control is retumed to the calling
module, letting it know what the problem was. (A Retur-
nCode of -2 from FINDEXO meant the key field wasn't
found when the index was searched. This way, the
original calling module can be coded to respond to
whatever number of error conditions is necessary. )
WRITEISAMO
WritelSAM is the procedure to write a record to the
ISAM file. The parameters it needs are the file name and
the key field. The only error condition that's anticipated
here is the possible absence of this file from the disk, and
that's not really an error— it just means we haven't writ-
ten the first record yet. Thus the code here tries to
RESET the ISAM file, and if that doesn't work it wiU
REWRITE the file, starting it fix)m scratch. The same
logic follows when the procedure writes the key field and
record number to the .KEY file. If there's an error, the
.KEY file hasn't beax started yet and it's handled the
same way.
Along with writing the record to the .KEY file, the
same information is added to the index table arrays, af-
ter incrementing MaxKeys appropriately. Thus,
whenever a new record is written to the ISAM file the in-
dex is updated in the .KEY file and in memory at the
same time. The index table will remain valid without
having to read the .KEY file into memory again.
REWRITEISAMO
RewritelSAM is very similar, but the differences are
important. In this case an error that will need to be dealt
with is very possible, so one of the parameters is again
RetumCode. Since RewritelSAM is used to update a
record, not write one in the first place, it is indeed a
problem if the file doesn't exist on the dis'-.. Also, in this
case we don't want to seek the end of the file and write a
record there, we want to seek the position of the
requested record and rewrite that same record. Remem-
ber to subtract 1 from the record number— obtained from
FINDEX( )— to account for records that start at zero.
Having written all the code that's required to accom-
plish these basic tasks, making the program do
something useful is easy. The following procedures are
the demonstrations, and I'll continue to point out ususual
syntax and logic, but skip the simple stuff.
READ DEMO
Intended to be used in this program only, ReadDemo
doesn't receive any parameters from the main logic
which calls it, but it must pass some parameters to the
procedures that it calls. First off, ReadDemo asks for the
name that identifies the record to be read. Then it calls
ReadlSAM to read the right record from the file, and
displays the phone number to the CRT. Along the way it is
prepared to deal with values of the parameter Retur-
nCode that indicate the following problems in reading the
file:
Retum Code Problem
-2 Key field not found when the index was
searched.
-3 The ISAM file didn't contain a record for
that record number.
(A retum code of -1 was used by LoadKeys to indicate
that the .KEY file wasn't found. Though these errors
could have been called -1 and -2, 1 prefer to associate
certain RetumCode values with specific problems, so I
don't usually re-use the same numbers, even in different
procedures.)
The statement "Read(Choice) ; " is used just to hold tt
displayed phone number on the screen until the user e
ters a RETURN.
ADD DEMO
Because all the nit-picky details are handled by th
procedures that were coded earlier, this one to demoi
strate adding a record to the ISAM file is very short an.
sweet. It asks for the name (key field) and the i^ne
number, then places them into the record for the ISAM
file and writes it. Notice the section of code that starts out
with the words "With ISAMRec Do".
The problem that's possible when a record is added, of
course, is that there niight be a duplicate of that key field
in the index already. If we were to enter a phooe number
for someone, forgetting that there was already an old and
incorrect one there, the computer would never deliver
unto us the correct phone number. Each time the index
was searched and a matching key field found, it would
point to the record containing the old number
Therefore, the proper way to change a field is with the
CHANGE feature, not by adding another record with the
same key field. This procedure does a quick check of the
index— using FINDEXO— to be sure that a key field
doesn't ahready exist before a record is added to the file.
34 The Computer Journal / Issue #22
Count := 05
With IndexRvc Do
Begin
Repeat
Begin
Read (IndexFile, IndexRec) ;
Count : = Count + 1 ;
KeyArayCCount] := KeyField; {load values from .KEY file into>
Index Ar ay [Count 3 := RecNum; (arrays used for INDEX table >
End;
Until EOFdndexFile) ;
End;
MaxKeys := Fi leSize < IndexFi le) ; {determine how many records in file>
Return:
Clase( IndexFi le) ;
End;
Procedure Read ISAM (Fi 1 eNamelAnyFi le;ReadKey: Name; Var ReturnCode: Integer) ;
Label Return;
Begin
Ret ur nCode : - F I NDE X ( ReadKey , Max Key s > ;
If ReturnCode < then Goto Return;
Assign < I SAMFile,FileName + '.ISA');
{♦I->
Reset <ISAIiFile> ;
{«I + >
If lOResult <> then
Begin
ReturnCode := -3; {file not found - bail out>
6oto Return;
End;
Seek < I SAHFile, ReturnCode -1); {locate the right record>
ReaddSAIiFile, ISAMRec) ; {read it, then close file>
Close (ISAMFile);
Return:
End;
Procedure WriteISAM<Fi leName: AnyFi le; I SAMKey : Name ) ;
Label Return;
Begin
Assign<ISAMFile,FileName + '.ISA');
{«!->
Reset (ISAMFile);
{♦I+J
If lOResult <> then Re»»ri te < ISAMFi le) ;
Seek(ISAMFile,FileSize(ISAMFile> ) ;
Write< ISAMFile, ISAMRec) ;
Assign ( IndexFi le,Fi leName + '.KEY');
{«!-}
Reset (IndexFi le) ;
{♦I + >
If lOResult <> then Re»«-ite( IndexFi le) ;
Seek ( IndexFi le,Fi I eSize(INDEXFile) );
MaxKeys :» MaxKeys -^ 1 ;
With INDEXRec Do
Begin
KeyField := ISAMKey;
RecNum := Fi leSize ( ISAMFi le) ;
Write( IndexFi le, INDEXRec) ;
KeyArayCMaxKeys3 := KeyField;
IndexArayCMaxKeys3 := RecNum;
End;
Close (ISAMFile) ;
CI ose( IndexFi le) ;
Return:
End;
Procedure Re«riteISAM<Fi leName: AnyFi le; ISAMKey:Name;Var ReturnCode: Integer ) ;
Label Return;
The Computer Journal / Issue #22
35
Begin
RsturnCode := 0;
Assign<ISAMFiIe,FileName + '.ISA');
Reset (ISAMFile) ;
{«! + >
I^ lOResult <> then
Begin
ReturnCode := -1; {file not found
Soto Return;
End;
Seek < ISAMFi le.FINDEX < ISAMkey.MaxKeys) -1 > ;
WriteKISAMFile, ISAMRec) ;
Return:
ClosedSAMFile) ;
End;
bail out)
Integer;
to Read:
Procedure ReadDeoo;
Label Return;
Var ReturnCode ;
Begin
WriteC^J'^J'^M, 'Enter Naaw to Read: ');
Readln<Na«neIn) ;
Read I SAM ('PHONE' , Naaein, ReturnCode) ;
Case ReturnCode Of
-2 : Begin
kfc-itelnC-J^J^M, 'Error - KEY NOT FOUND IN INDEX');
Goto Return;
End;
-3 : Begin
WritelnC-J^J'M, 'Error - RECORD NOT FOUND in ISAM FILE');
Goto Return;
End;
End;
With ISAMRec Do Mr i teln ('^J'^J'-M, 'Phone Number:
WriteC^J'^J'^M, 'Press <RETURN> to Continue... ');
Return :
Read (Choice) ;
End;
' , ISAMPhone) ;
If a ReturnCode comes back that indicates the key wasn't
found, it doesn't imply an error this time, it means
everything's OK to proceed. Isn't it great the way we can
use a function like that whenever it's needed!
CHANGE DEMO
ChangeDemo is very similar, but this one requires that
a key field MUST exist before it's legitimate to continue.
Obviously, it isn't possible to change a record that hasn't
been written to the file yet, and any attempt to access a
nonexistant record would certainly result in an 1/ error
that would crash the program but good (attempt to seek
beyond EOF).
DELETE DEMO
By now, this one last procedure needs little or no ex-
plaining. It simply does a re-write of a record, replacing
the phone number with a message that says "*** Deleted
***". In actual practice on large computers, records are
not really deleted physically from an ISAM file by an ap-
plication program, but simply marked with a user-
selected "delete character" in a user-selected position in
the record. A system utility program is occasionally used
that will put the file back into physically-sequential or-
der, working in all the records that have been added, and
leaving out the ones that were marked for deletion.
Assuming that deleted records won't amount to enough
disk space to cause problems, this procedure might be as
far as you would want to go in your own applications. In
fact, in some cases, it might even be an advantage to
leave deleted keys in the index. In this program, for
example, a phone number can be deleted if it turns out to
be a wrong number— no point in continuing to use it— but
then the deleted field can be replaced with the proper
number at a later time by using the CHANGE feature.
Closing Comments
That's about all you might want to know about this
program to simulate Indexed Sequential Access Files
with your micro. If you're NOT a beginner, though, you
may have spotted some possible improvements already,
and I couldn't let you just sit there and smirk without
pointing out that I, too, have thought of some. I'll take up
just a little more room to point out one potential upgrade,
and I welcome suggestions from anyone. This program is
surprisingly fast and capable, but it can be made even
more so at a cost of somewhat increased complexity.
Binary Search
If there are to be a limited number of records in the
ISAM file, say, a couple of hundred friends' phone num-
bers and addresses, a sequential search of the index
array (such as in FINDEX) will be tolerably fast, and
requires very little room in the program. If this principle
is to be applied to an application program that will keep
track of thousands of records, then it would be worth the
36 The Computer Journal / Issue #22
Procedure DeleteDemo;
Label Return;
VAR ReturnCode : Integer;
Begin
Write< -J' J^M, 'Enter Name to Delete: ");
Read 1 n < Name In);
1+ FINDEX<NameIn,Ha>:Keys> <0 then
Begin
Writeln< -J J~^M'Error - KEY NOT FOUND IN INDEX - Cannot DELETE');
Delay (3000) ;
Goto Return;
End;
With ISAMRec Do
Begin
ISAMPhone := ' *«♦ Deleted •»♦';
Rewrite I SAM ('PHONE' , NameIn, ReturnCode) ;
End;
Return:
End;
{ A BEGIN like this, without a procedure or -function name, indicates the }
{ start o-f the main program logic. The program actually starts here, and >
< calls previousl y— coded procedures and -functions as needed. >
Begi n
LoadKeys ( 'Phone' , MaxKeys, ReturnCode) ;
If (ReturnCode = -1) then
Begi n
Writeln ( 'Unable to locate KEY -file... returning to system.');
Goto Stop;
End;
Start:
Write(#26' ISAM Phone File Example C Q=Quit R=Read A=Add D=Delete C=Change
3 ' ) ;
Read In (Choice) ;
Choice := UpCase(Choice) ;
Case Choice Of
'Q' : Goto Stop;
'A' : AddDemo;
'R' : ReadDemo;
'D' : DeleteDemo;
'C : ChangeDemo;
End;
Goto Start;
Stop:
End.
Procedure AddDemo;
Label Return;
Begin
With ISAMRec Do
Begin
Write<'-J''J'~M, 'Enter Name To Add: ');
Readln<I5AMName) ;
I-f FINDEXdSAMNaaie, MaxKeys) >0 then
Begin
WritelnCJ-J'M, 'Error - DUPLICATE KEY - Cannot ADD ');
Delay (3000);
Goto Return;
End;
WriteC-J'J'-M, 'Enter Phone: ');
Read 1 n ( I SAMPhone ) ;
Write I SAM ('PHONE' , ISAMName) ;
End;
Return:
End;
Procedure ChangeDemo;
Label Return;
VAR ReturnCode : Integer;
The Computer Journal / Issue #22
37
Begin
WritBC^J-J-M, 'Enter Na«e: ');
R«ad(Na«eIn) ;
If FINDEX<Na<Mln,MaxKeys) <0 then
Begin
Writeln<-J-J-M, 'Error - RECORD NOT FOUND - Cannot CHANGE');
Del ay (3000);
Goto Return;
End;
ReadlSAM < ' PHONE' , Naeeln , ReturnCode) :
With ISAMRec Do
Begin
>fc'ite<^J'^J-M,'01d NuMber is: ' , ISAMPhone) ;
WriteCJ'-J-'M, 'Enter NeM Number: ');
Read < ISAMPhone) ;
Re*<r i t e I SAM ( ' PHONE ' , Name I n , Ret ur nCode ) ;
End;
Return:
End;
extra programming cost to use a binary search of that in-
dex instead.
Actually, two major changes would be needed. The in-
dex would always need to be sorted into ascending or
descending order (based on the key fields),to use a
binary search. This sort would have to be done each time
a record is added to the file, before the index is accessed
the next time.
Second, the search itself would have to be re-written a
Uttle. The details of all this are a little beyond this par-
ticular article, but for those budding hackers who haven't
already added the binary search to their bag of
programming tricks, I'll give a few hints, at least.
Begin by determining how many entries are in the
array (MaxKeys, in this case). Assign a variable called
FINISH the value in MaxKeys to start with, and initialize
a variable called START to 1. Add START to FINISH and
divide by 2 to find the middle of the array. Compare the
value in the middle to what you're looking for, and see if it
matches. If it does, the search is over alrea(fy.
If it doesn't, determine whether the value you found is
HIGHER or LOWER than the one you're looking for
(that's why the array has to be sorted! ) . If it's higher, set
FINISH to a value that's one less than the subscript you
just checked. If it's lower, set START to one more than
the subscript you just checked. Now, start over again
with these new values for START and FINISH. Sooner or
later, that middle element you check will be the one
you're looking tor.
It usually turns out that it's sooner than you expec-
ted—a binary search is FAST. The reason is very simple
(and you'll probably catch on real quick to why it's called
what it is). After one comparis<ni, you're able to
eliminate fully one-half of the possible elements as being
either higher or lower than the one you're looking for. Af-
ter the second comparis<Hi, you're able to eliminate half
of the ones that were left. It turns out that it takes only 16
comparisons (or fewer! ) to find an element among an
array of 65,536 elements. Using a linear search, it would
take— on average— 16 comparisons to find an element
among an array of only 32 elements.
In actual practice, you won't find yourself getting
bored waiting for this program to find the right record
number for any reasonable size index, and the binary
search really shows its stuff the best whm the numbers
are very large. On the other hand, a quick sort done only
after adding a new record to the ISAM file doesn't add a
lot of overhead, either. Just be sure to re-write the sorted
index file as part of the EOJ (End Of Job) processing as
you quit the program, so it won't have to be sorted again
each time the program is used. After all, you might ac-
cess a file thousands of times without adding new records
to it, depending on the application.
(By the way, a Quicksort is a real jewel in Pascal,
using recursion. That might be a good subject for another
article...) ■
"...received my moneyi \.Morth vvith /usf one
issue..."
— J. Trenbick
■ always stop to read CTM. even though
mast other magazines I receive land i-vrite for)
only get cursory examination.. "
— Fred BIcchman. K6UGT
Mexico, Canada
S25.00
f^oi^eign S35 OO(land)- S55 OO(air)
Permanent lU S. Subscnptio
n) St 00 00
Sample Copy
S3 50
CHET LAMBERT.
W4WDR
1 .'04 Sam Drw.-. . Hir-:- ;
"^i'- AL ]5235
i2C5i d54 i:2.
1
GIVE YOUR COMPUTER
THE ABILITY TO
INTERACT WITH
THE REAL WORLD
*r*%,-
MONITOR AND CONTROL
TEMPERATURES
MANAGE INDUSTRIAL
PROCESSES
MEASURE ENERGY
CONSUMPTION
CONTROL LAMPS AND
APPLIANCES
PROVIDE SECURITY
PROTECTION
PERFORM SCIENTIFIC DATA
COLLECTION
Letters
The ADC-1 serves as a real world
interface for any computer or
modem with a RS-232 serial port.
This sophisticated yet easy-to-operate
data acquisition and control system
includes:
• 16 Analog to Digital Inputs - 12 bits
provide O.lmV resolution over r 0.4V.
• 4 Digital Inputs for security and rotary
encoder sensors.
• 6 Switched Outputs for relays and low
voltage device control.
• AC Line Carrier Transmitter - controls
32 BSR X-10 type remote modules.
• Owner's Manual with detailed
programming examples.
Sensors available from Remote
Measurement Systems include: light,
temperature, humidity, wind, sound,
soil moisture, ultrasonic ranging,
energy consumption and security.
The ADC-1 - an exceptional
purchase at $449.
REMOTE MEASUREMENT
SYSTEMS. INC.
2633 Cattlakt- A»* E . Suite 206
S*allle Washingfon 98102
{206( 328 2255
St-nd tot < ompii^l^ s|jfriHc«ljons
Telephon.- Vi.s* and MMtricard
(Continued from page 4)
Still More On Soldering
James O'Connor:
I enjoyed your article in the Sep-
tember/October issue.
I think that soldering dates back to
the Egyptians— for metals— and the
appUcation to electrical circuits
probably dates to Faraday and his
contemporaties. Electronics is just a
minor off-shoot of electrical
engineering.
Your differentiation between
welding and soldering is a bit ex-
treme. Most welding (not all) in-
volves using a "welding rod" which
is melted and flowed between the
component parts to be joined. The
rod usually melts at a lower tem-
perature than the parts, like solder,
but yes, the component parts melt
too.
On the other hand, metals when
soldered do dissolve into the solder,
a process which is similar to
melting. When thin films of solder
are used to join metals structurally
(brazing), you will find that
desoldering requires a higher tem-
perature than the initial joining
because of the change in com-
position of the solder due to dissolved
metals. The change is a couple hun-
dred degrees in silver
soldered/silver brazed stainless
steel.
This effect is not very noticeable in
most electrical connection soldering
because the quantity of solder used
is so great, compared to the surface
area of the joint, that the concen-
tration of dissolved metal from the
joined surfaces never gets very high.
However, it does become noticeable
at times, such as desoldering a DIP
or socket from a board, where the
pins are reasonably tight in the holes
in the board AND the plating/con-
ductor on the board lines the walls of
all holes.
Personally, I use a 7^2 watt iron
for all my electronics work. I have a
high power iron (15 watt) for use on
heavy duty connections— 8 gauge
wire to a lug on a transformer, etc.
I'm surprised that you made no
mention of the gallium and indium
based special electronic solders.
While the hobbiest isn't liable to use
these, he should know that they
exist, and that there are problems in
trying to bond lead-tin to the
The Computer Journal / Issue #22
speciality solders or to parts "con-
taminated" with them.
In your review of "Sources", you
might add a mention that Heath sells
a kit for learning how to do elemen-
tary electronic soldering— a board,
parts, and instruction manual. That
kit was my starting point and I still
have the manual.
Dave English
Orange, CA
Dave:
Thanks for the comments, Dave.
Actually the Egyptians were also the
first to do VLSI (Very Large Scale
Integration) they just happened to
use large cut stones instead of logic
gates. But seriously, I wanted to
delineate welding from soldering
because I have encountered novices
who were sure that soldering was
just a wimpy form of welding. The
result of that misconception was a
tendency to overheat connections in
the belief that insufficient heat was
the cause of their problems. In the
old days welding and forming were
done concurrently so that the high
heat aided both processes, for
example the gtin barrels of the
famous Brown Bess muskets carried
by Revolutionary War soldiers were
formed and welded from a sheet of
flat metal by means of the high tem-
perature of the gunsmith's forge and
a forming block. Today changes in
shape would be a deformity so the
welding rod which melts at a slightly
lower temperature prevents that. As
you correctly point out, it is still
welding that occurs, but more on the
surface than throughout the pieces.
Supplying and controlling the
precise amount of heat is very
similar to soldering.
Yes, indeed there is a chemical
bond formed during soldering and it
can affect the temperature required
to de-solder a connection. For elec-
tronics work my experience has
been that this bond is not much of a
problem if most of the residual
solder can be removed. As you note
there are situations where that is dif-
ficult due to tight quarters. As as
aside, this bonding effect is also
present with chemical 'glues' and
shows up dramatically in that most
glues produce the strongest possible
bond with the thinnest possible glue
layer. So-called 'Super Glues'
(cynoacrylate) exhibit this to the ex-
The Computer Journal / Issue #22
treme, remember the TV ad where a
man is suspended from a beam with
just one drop, if they had used two
drops he might have fallen. This is
directly opposite to the intuitive
feeling that if a little is good then
more is better.
7Mi Watts! ! ! I had heard of such
low power irons but had to check my
catalogs to determine that, yes, they
are available. Your successful use of
them is testimony to the degree of
proficiency you've developed. Size
and shape of the iron's tip along with
the wattage rating ultimately
determine the tip's temperature so
there is a wide range of suitable
irons that can be used, stiU I would
stick with the recommendations
made in the article for anyone just
getting into soldering.
Specialty solders are used by
people who do craft type
metalworking and in industrial ap-
plications but in my experience are
very rare in electronics work. For-
tunately, most articles that I have
read about these solders do a good
job of explaining where, when, why,
what and how to use them and I en-
deavored to model the series on elec-
tronics soldering on this principle.
The companies that sell these
solders also provide good technical
brochures about them.
Good suggestion about the Heath
Soldering Ck)urse, Catalog No. EI-
3133 list price $19.95, I was not
familiar with this particular course.
Heath's educational courses are in-
variably a good investment. In some
respects the Soldering article and
the two follow-on articles cover
much the same material, so Com-
puter Journal readers may want to
use them as a psuedo course in
soldering. Also, those familiar with
Heath's kits will probably detect the
fact that I diverge from and expand
upon Heath's usual instructions
about soldering. By all means, CJ
readers should obtain a copy of
Heath's catalog and feel confident
about attempting any of the kits or
educational products.
James O'Connor
Randolph, MA
39
^
BD Software, Inc. , maker of ttie original
CP'M-80 C Language Development
System, knows
Time is ppecious
So the compilation, linkage and execution
speeds of 8DS C are ttie fastest available, even
(especially!) on floppy-based systems Just ask
any user! With 15.000 + packages sold since
1979, there are lots of users . . .
New! Ed Ream's RED text editor has been
integrated into the package, making BOSC a
truly complete, self-contained C development
system.
Powerful original features: COB symbolic
source-level debugger, fully customizable
library and run-time package (for convenient
ROM-ing of code), XMGOEM-compatible
telecommunications package, and other sample
applications.
National C User's Group provides direct access
to the wealtti of public-domain software written
in BDS C, including text editors and formatters.
BBS's, assemblers, C compilers, games and
much more.
Complete package price; $150.
All soft-sectored disk formats, plus Apple
CP/M, available off-the-shelf. Shipping: free, by
UPS, within USA for prepa/tf orders. Canada: $5.
Other: $25. VISA. MC, COD. rush orders accepted.
I 'IJ^(3ilf(^mii®a Homo
BO Software, Inc.
P Box 2363
Cambridge MA 02238
617 '576 -3828
40
The Computer Journal / Issue #22
"BMON"
Software In-Circuit Emulator
Links youf CP M computer with any Z80
based compoie' ex controller that you may
develop An '''at is needed is BMON, 8K of
ROM space and a handshakeable bi-
directabie I O pon leither RS232 or Paral-
lel).
Features:
— Full program oevelopment debugger
with Breakpoints, Snaps, Stops, &
Waits
—Single Step program execution.
— Download file from CP/M system to de-
velopment RAM
— Upload Memory from development
RAM to CP/M disk.
— Two versions Master BMON runs in
your CP/M system. Slave BMON runs
in your target system.
Note: Requires Microsoft's M80 & L80
assembler & linker to setup Slave
BMON
8" SSSD Disk containing Master
BMON. Slave BMON. CONSOL
BMONIO. CONSOUO. and Users
Manual $49.95
Shipped Via prepaid UPS
—No COD or PO. Box-
Check or Money Order to:
Barnes Research & Development
750 W. Ventura St.
Altadena, CA 91101
(818) 794-1244
C^Mis a t^ade-^SfH of Digital Research inc
M30 & ^.-0 sre "aie'-narks o' MicrosofT Inc
BLANKENSHIP BASIC
IGIVES YOU
MORE
FofimeAmji-^. msmt/ic
kf=ORYOUR
lMONEY!,
$25
DOS 3 3 VERSION
OR PRODOS VER.
BOTH FOR S 39.95
ADO S2.00 POSTAGE ANO HANOUNG
10 DAY MONEY BACK GIM8ANT1E
itar4 tri«aa«ri
1. Rea
2. WHI
3. Tru
PRI
PRI
90
Ful
Fa>
BOX
Li>
DIS
OEF
99«
All
100
FRB
Mak
1 intarpr
LE-ENDNHI
• :r-THiN
NT. USING.
NT and TA
coluBOB a
I editor
t SORT.
aoxrti
tinfa are
K coaaao
INE ud P
upward
coaaaoda
I of aat
I Dawala
mm your A
etar
IE and R
ELSE-EN
FUB
B coaaa
upported
Hltb AU
EARCH an
L. DRAM
iDdaot
d raplac
ERFORM
coapa t lb
aotarad
xafiad
ttar
ppla int
t a
8PBA
DIF
HERG
nda
on
TO-N
d IN
.USI
ed
aa
la X
nor
uaar
aila
pra-pr
T-UNTI
ua 1 n
E.
work
rit a
UM
STRt c
NG and
auto
DOS'
^ pro
ith Ap
ally,
a wor
ble to
NEW aa
ocaaaor
L ioopa
f IIHEN)
NDOMIZB
n HIRES
nd I!c
d RENUH
oaaanda
SOUND
t ical ly
CHR« 4 I
cadurea
plaaof t
no b' a
Id wida
ownera
cbina ' '
MAIL CHECK TO: JOHN BLANKENSHIP.
P O. BOX 47«M, ATLANTA. GA 303(2
Art: Your prompt response is very
much appreciated.
Good Grief! Looking at your back
issue list is like finding buried
treasure; what a kick. I'm enclosing
a check for all the listed back issues
and a two year subscription.
May you prosper.
Interests, Equipment, etc. We're
principally Z-80, CP based. There
are two homebrew units and an
Ithaca Intersystems system with
front panel. Also, have a little Z-8
(Circia) and a yet-to-be-assembled
MicroAce. There's a Godbout 68K
system languishing in storage as a
result of an abortive "bright idea";
the collapse of the oil business had
much to do with it. I'm interested in
wringing the maximum from the Z-
80/S-lOO system and am looking for a
reason (excuse?) to make a foray in-
to 68K country. Am determined to
know what goes on inside and look to
your journal to aid and abate tje
quest.
Thanks.
Chuck Henderson
Midland, TX
Remax Drives
BillKibler:
I just read your column in the Sep-
tember-October issue and im-
mediately picked up on a comment
about Remex disk drives. You
referred to modified drives. I bought
a couple of them and have had
nothing but trouble. I used them on
an AMPRO Little Board and found
that it was almost impossible to
verify a disk. I concluded that there
was something sloppy about either
the mechanics or the electronics or
both, but didn't quite know what to
do about it.
Could you let me know what you
did to modify the beasts? I enclose a
SASE for a reply. I certainly will ap-
preciate it.
Frank Oechsli
Richmond, CA
Dear Frank:
Thanks for the fan mail, and
hopefully this information will get
you going. Please send us any >fEW
information you might get after
playing with your drives.
The Remex Disk drives that are
currently available for as little as $39
have many problems, but can be
made useable. In the July- August
issue of Computer Journal I covered
several important solutions to the
problems. Other magazines have
also commented on some solutions
(Micro Cornucopia #26) , which agree
in part with my findings. These
drives appear to be made rather
marginally and without much
quality control. A solution may in-
volve one or more of the following :
A) The 12 volt supply needs are
much larger than most, and will ex-
ceed the listed ratings. Limiting the
number of drives per power supply,
as well as adding more capacitance
(2000ufd) has cured poor stepping
problems.
B) Problems with noise have been
noted, and in one case shielding with
steel helped. I found that adding
more bypass caps (.022) can also
improve their operation (the PC
board doesn't have enough) .
C) Precompensation has been
noted as causing problems. Use
125ns or none at all. The schematic
shows some minor value changes in
the read circuit design and I suspect
the design is inadequate. Adjusting
R27 can improve the operation,
sometimes. PLEASE NOTE that
most of my errors have been READ
not WRITE errors.
D) Several signals are fed directly
off of the 12V line and without proper
filtering will cause false write
triggering and possible speed
problems. Adding 0.01 and 10-20ufd
across the input power socket can
help.
E) Speed regulation is controlled
by an MJE210 and this device is in-
sulated from the case by a mica
washer. Excessively tightened
screws will short this device and
cause the drives to run full on
(loosen screw) . I had one of the tran-
sistors fail completely and replaced
it.
F) The guides or rails on which the
head rides can become sticky and
may need cleaning and (Hghtly)
oiling. Head alingment has checked
out good (usually), with only
azimuth being occasionally off (play
with rails to correct) .
G) Check all mechanical and elec-
trical connections as several units
have had broken, loose, and poor
connections. I found one loose wire
on a motor unit and had to
f^ FOR TRS-80 MODELS 1 . 3 A 4
I IBM PC, XT, AND COMPAQ
WHICH ONE?
Which microcomputer word pro-
cessor lets you create and edit
without retyping, but won't slow
down your creative process?
Knows when to capitalize the first
totter while replacing one phrase
with another? Can outdent as well
«8 teident? Will do typesetting at
your command, even with propor-
tional characters, right justifica-
tion and tabbed columns? Lets
you use the same (extra-capacity)
data disks on IBM PC arK^ TRS-80?
And eases your learning with
common-sense keystrokes, l-lelp
menus, good examples and a pro-
fessionally authored manual?
Hint: it can integrate to communi-
cate from home to office, and will
interface with a database for form
letters, data tables, and morel
It's the professional's word pro-
cessor for your IBM PC, Compaq,
orTRS-80Mpdel1,3or4:
FORTHWRfTE
In
41
FOHTH
With an unusually powerful set of
tools and an unusually easy way of
helping you to use them.
The total software environment for
IBM PC, "PRS-SO Model 1 , 3, 4 and
close friends.
• Personal Licertse (raqutrtd):
■—FOHTH ti mm Mm CM PC) . . .
MMWOirrM t)MMi OM (TUMO 1, 1 or 4)
•Pereonal Llcenae (opiiooai moduiM)
rOirtHCOttcammmktIiammoMt .... I
unurm
imM
OATAHAMILBI
MTMUNMp-njM (K a«ty, nw nq^
NMTHVMTC vord pnottKOf
•Corporate Site License
Extensions tmmttJHt
•Some recommended Forth books:
UNDBttTAMMNO FOnN V mnim ) ... I MS
ST Om W W rowTM ( pro gnmiiilng) . .
THWKINQ FOHTH (MchniqMl ....
teOMMIM FOtrm |n MHSFORTH)
Shipplng/TMndNng A tt tufrs. No nrtunw on MHim.
Ask your dMiar to show you ttw wortd of
iMSFORTH, or nquest our free t>rochure.
MILLER MCROCOMmiTEIt SERVICES
61 Lake Shora Road. NMck, MA 017W
P17)6SM136
"recrimp" it.
Remember, these units most
likely have poor quality control, and
any type of problem could be en-
countered. The design appears to be
minimum, and external help (larger
and cleaner supply voltages) will be
necessary.
One of the most important points
in fixing the problems with these
drives is networking. This means
talking and writing to others with
bcih questions and solutions. Only
through networking can both
manufacturers and users keep
poorly designed units either off the
market or at least running.
Best of luck.
BiUKibler
Sacramento, CA
Reconsider TCJ's Emphasis
Your letter seems to indicate an
emphasis on robotics, real time data
collection and process control, at the
expense of "business" topics— yet
your back issue topics suggest a
much broader base. Please consider
that "system integration" issues in
the vertical market business world
are also required for practical ap-
plications on the factory floor, and
thus are a common area of interest
that can expand your subscription
base. As micros move into the
sphere of large MIS departments,
DP types are having to cope with
systems subjects formerly handled
by small outside systems houses.
This is a big market for you! Subjec-
ts include multi-user, LANs, har-
dware integration and interfacing,
micro multi-user operating systems,
database, etc. The recent launch of
Multi-User magazine was a disap-
pointment. Maybe you can fiU the
gap.
L.A. Wilkinson
Van Nuys, CA
Editor's Note:
I appreciate this kind of feedback,
see this month's editorial for my
comments. ■
'i i ■ if/
UCIIIII II
THE AUTONOMOUS ROBOT
IS NOW PRICED FOR
EVERYONE!
Buy each subassembly as a kit
or factory assembled and create
your own GEMINI Robot.
—^—- Or, for
^^^4^ convenience,
{^^^*^ start with
*^ >L^ GEMINEX
our starter
kit, and
expand to
GEMINI
later with
upgrade kits.
Either way.
Buy a piece of tomorrow
TODAY!
CALL or WRITE For Our FREE
Brochure.
arctec]
9104 Red Branch Roaa
Columbia, Maryland 21045
(301)730-1237
Telex 87-781
42
The Computer Journal / Issue #22
The AMPRO Little Board Column
by C. Thomas Hilton
W^hether you are a hobbyist, or commercial
developer, often the desire for a small, yet powerful,
single board computer, (SBC), presents itself. Often the
choice for a good SBC is between commercially available
boards, or in-house manufacturing. This column will
present my personal choice for many SBC requirements,
the Ampro Series 100, or "Little Board® ," microcom-
puter. Tliis system is no larger than a 5.25 inch disk drive,
so it can be mounted in the drive enclosure, and it
operates with very low current demands.
The Little Board is available in a number of forms. It is
available from Digital Research Computers as a kit, and
in a number of different configurations from Ampro
Computers. (See Figure One for vendor listing) .
AMPRO Computers, Inc., 67 East Evelyn Avenue,
Mountain View, CA 94039 (415) 962-0230. THE source for
manuals, systems, and parts.
Digital Research Computers Of Texas, POB 461565,
Garland, TX 75046 (214) 225-2309. Little Board
kits and ZRT terminal card.
Integrand Research Corp., 8620 Roosevelt Ave.,
Visalia, CA 93291 (209) 651-1203 Cases, power supplies,
and wiring harness.
Colonial Data Services Corp., 80 Picket District Road,
New Milford, CT 06776 (203) 355-3178. Disk drives
and accessories.
Figure 1 : AMPRO Series 100 and Little Board source list
When considering SBCs for industrial, instnmien-
tation, or other application, one must consider how he
will develop the system. That is, what manner of
"development system" is also required to use the board
in question. I am using an Ampro Model 122 with my
Kaypro 4-84 as a development system. The '122 is a dual
48 track per inch, (48 tpi), microcomputer. It is a "ter-
minal system." This means that it requires a terminal to
communicate with it. I use the Kaypro as a "dumb" ter-
minal for development of Ampro projects.
The Little Board is a 64K, Z80, system capable of sup-
porting up to four Double Sided, Double Density, (DSDD)
disk drives with a standard Basic In/Out System,
(BIOS), or up to 88 megabytes of hard-disk storage, with
a modified bios. My Kaypro can handle only 10
megabytes of hard-disk storage. With a terminal the Lit-
tle Board is far more powerful, and versatile, in my
opinion, than the Kaypro. In time, if Art allows me to con-
tinue this column, we will explore the Little Board in
great detail. At this point, however, we will assume that
you are either looking for a well supported SBC, and have
chosen the Ampro Series 100, or I have convinced you of
how much computing enjoyment can be had with a Little
Board. This column will begin with the assumption that
you have either just received an Ampro Series 100, or Lit-
tle Board. We will not repeat the material covered in this
column. New Ampro users should be advised to obtain
back issues of The Computer Journal to keep abreast of
all projects. If reader interest warrants, user disks, with
these articles and public domain software tools to per-
form programming projects, will be made available. By
providing public domain software tools, at reasonable
acquisition costs, for use with this series, we will have
some consistency. I will not hide from my readers. I will
review reader contributions for this column, and answer
any questions I receive, quickly, and personally. Though
I have no connection with Ampro Computers, I feel my
function is to assist you in the understanding of, and use
of your Ampro SBC.
The Ampro Series 100 systems have two serial ports, a
printer port, and a disk expansion port. Owners of the
"Little Board Plus" also have a SCSI port which can be
used to interface to a hard disk and other devices. In this
series we will deal primarily with the generic lA CPU
card as found in the inexpensive Little Board kits, and
Series 100 microsystems.
Out of the box the Series 100 "Bookshelf Computer,"
the recommended development system, is ready to run
once a terminal system has been prepared for its use.
Most people interested in SBCs have a system that can be
used as a terminal. Again, I use a Kaypro 4-84. In a like
manner most people have an assortment of cables in
reserve. I am a bit on the cheap side, and prefer to make
my own cables. Constructing a cheap and simple cable
will be the first project in this series. This is a bit
pedestrian for you old salts, but there are a lot of begin-
ners out there who need a little help as well.
1. DB-25 RS 232-C Male Connectors, 2 each
(Radio Shack #276-1547)
2. Six Conductor Cable, (Or Ribbon Cable)
(Radio Shack #278-722 is usable)
3. Soldering Iron & Solder
4. Small hand tools, tweezers, etc.
Figure 2: Materials required.
Cable Construction
Assemble all of the materials noted in Figure two.
Before we get too carried away, let's force ourselves to
tolerate a little theory. The Ampro communicates with
the terminal via RS 232-C ports. In normal operation
"Port A" is the terminal port. This port is wired as "DaU
Communications Equipment," (DCE). This is the format
we will use in building the cable. The Ampro end of the
The Computer Journal / Issue #22
cable must be wired as DCE, but your specific terminal
may require a "Data Terminal Equipment," (DTE),
format. Standard communications cables consist of 25
signal paths. Not all of these 25 lines of a standard cable
are supported by the Ampro/Little Board. We need only
six actual signal paths to get our system on-line :
1. Data Input
2. Data Output
3. Data Terminal Ready
4. Clear To Send
5. Signal Ground
6. Equipment Ground
In the list above. Data Input refers to serial data being
received by the Ampro from the terminal. Data output
refers to serial data being sent to the terminal. Data
Terminal Ready and Clear To Send are "hand-shaking"
signals to assure that the terminal is listening when it
should, and vice versa with the computer. The signal
ground is the common return path for all data signals.
The equipment ground path is generally used to shield the
cable, and assure that both the terminal and computer
are of equal electrical potential.
In this construction project we will use an "A" to in-
dicate the Ampro end of the cable. "K" will indicate the
Kaypro end of the cable.
A statement such as "K2" refers to the Kaypro end of
the cable, pin number two. In a like manner a reference
to "A20" would refer to the Ampro end of the cable, pin
20. Place a mark in the space provided when you have
completed each assembly sequence.
Prepare your connectors and cable for assembly at this
time, marking one end with an 'A' for AMPRO END and
the other end with a 'K' for KAYPRO END.
D 1 . Connect Kl to Al ( One conductor to the same pin on
each end, starting on the Kaypro end. )
D 2. Connect A2 to K2
a 3. Connect K3 to A3
D 4. Connect AS to K5 ( pin K4 and A4 are not connected)
D 5. Connect K6 to K8 (On Kaypro side ONLY, here we
define the unused DCD input state as active)
D 6. Connect K7 to A7
n 7. Connect A20 to K20
At this stage of the assembly only the following pins
should be connected, all others should be left vacant, un-
connected.
Ampro End: 1,2,3,5,7,20
Kaypro End: 1,2,3,5,6,7,8,20
There are six connections on the Ampro end because
there are two ground paths. While only one ground path
needs to be used, we will use two. One is defined as
Little Board'7186...«$495
Hish Performance, Ldw Cost PC-DOS Ensiiw
Boots MM PC-DOS
'not Indudcd)
• Three times ttie COMPUTING POWER of
aPC
• Data and File Compatible with IBM K,
runs MS-OOS seneric" programs
• 8 MHZ 80186 CPU, DM^
Counter/Timers, 188/512K RAM zero
wait states, 16-128K EPROM
• Mint/ Micro Floppy Controller
( 1 -4 Dnves, Sinsle/DoutJIe Density,
1-2 sided, 40/80 trade)
• 2 RS232C Senal Ports (50 -38,400
tjaud), 1 Centronics Printer Port
• Only 5.75 X 7.75 inches, mounts
directly to a 5-1/4' disk drive
• Power Requirement 'SVOC at 1.25*;
n 2VDC at OSAi On board - 1 2V
converter
• SCa/PUJS- multHnaster I, O
expansion txis
• Software IrKludcd
• PC-OOS compatible ROm*OS boots
DOS 2ji and 3ji
• Hard Onk support
• OPTIONS:
• Expansion txMrd with
• 1 28 or 5 12K additional RAM
• 2 Sync/Async RS23S/42S
senal ports
• Battery backed Real rime Clock
• 8087 Math Coprocessor
• BufPered I/O Bus
• STD Bus Adapter
• Utilities source code
• TuitX)0OS/ Networkms
BOOKSHELF'^
Sett'ei 200
Past,
if Myi PfUHn^g WHOM PCvOS 1
aw co*#tJnN6 POMoi et • K
Priced from
$1295.00
10MB System
Only $1945.00
• Data and Fit compatible with BM
PC-OOS ix and 3x
• Runs "MSOOS scncric' programs
( Dbase II, MuMplan, Wordstar,
Supcrcalc 9, Turtx) Pascal; Fortran 77,
Microson C, Lattice C, MM Macro
Assembler, Intel compilcn A tools,
QW Basic, etc )
• Works with any RSS3SC/KSa terminal
(not included)
• Compact 7.3 X 6.5 x tO.S inches,
12.5 pounds, ai metal construction
• Based on Litde Board/ 186
• 5 l2KRAM,no wait states
• IVvo RSS3I serial ports
a One Centronics printer port
• Oieorhwo 360 Kb floppy dnvcs
• 1 0MB inteinal hard diHtctive option
4 F/^TOMM. SA., ( 1 ) 41-0018,
TU 22408 HiaUMi CEN1K
ElfCTRONKXC UeMeatM, (041 ) 23-4S41,
TU 42621 t »H*OA s OtNACOUP
COmPUTU SySHMS no., (604) e7»-7737
DWUtVi QUAMT SySTtMS;
(01) 2S344S3, TLX 946240 >CF:1«)03131
nUMCI: EGAL*, ( 1 ) 502- 1 BOO, TU 690a93
WUHi XDaOS MFOIKVJKA, S910SK,
TU 50364 AUnMUb ASP
So^tMvre Included:
• PC-OOS Compatible ROi»«OS boots
K>S 2j( and 3JI
• Hard Disk Support
• T/Malier III — Word proccsMij
sprcadtfiec^ relational oaubaK,
spdlins checker, and dau
encrypt/ deaypi
Ei«iandablc:
• Floppy expansKXi to >oi> owes
• Hard ijisk and tape CM, iiw m i
• SCSI/PUIS" muB-maBw i- O
expansion b(A
MOOCOMPUTUS. :6I !
■MSL CNC-OAIA LiACCI Jl>A
<4t)26<-«6!,TU941
DAMn, (03) 66-20^2a lU •»)•
IMM»t SyiMMCTK Ov : VW >tt
lU 191394 OMAi •t^w 1»M«Ll
UD, (3) 49.I6.95. lU t4'M' *«iak
AiAxm(o«)54-w>«o nji 'I'otiAki
CONVtCT AMPaO COmA,1US m
TEL: (415) 96>-0«3a tux aMOBt
•M*, *<IC(V1>. ID*!*. ••■ .>«.
Ti««a0O5". SoffMT* arc Ml j«aa 1
AiMnvlMc. «K»MMr. «|w^M MC
St««c«c 9' SoKm .« s.^ .«Mjr*
-. COMPUTEF^S liMCOF^FaOF^ATED LittM. me
^67 East Evelyn »■«.. Mountain Vlesn^CA 94041. (415)969-OS30.rUiXa<«O3O!
J
44
The Computer Journal / Issue #22
equipment ground, the other as signal ground. In both the
Ampro and the Kaypro these lines are tied together.
Later we may wish to use this cable on another terminal
where the two ground systems are different, hence we
use the extra wire now, to avoid problems later.
The Kaypro has two extra connections as pin 6, signal
g)wer path, ( +5 volts), is used to define the unused input
CD, pin 8, to its active state.
A good technician triple checks his work, even when he
knows he has done the work properly. Triple check your
connections now.
D 8. If you are using metal connector shields AND your
cable has a metal braid type shield around the wires,
connect the braid to the metal shield. If you are uncer-
tain, ignore this step.
D 9. Insert the Kaypro end of the cable into the SERIAL
DATA PORT in the rear of the Kaypro. Consult your
Kaypro manuals if uncertain as to which connector this
is.
n 10. Insert the Ampro end of the cable into Serial Port
'A' at the rear of the Ampro. Consult your Ampro
manuals if uncertain of the port's location.
Assuming all of your cable connections are correct,
and you are proud of your work, aUowing no sloppy
soldering, the assembly of your terminal cable is now
complete.
Going On Line:
The Ampro Series 100, Serial Port 'A' is configured for
9600 baud without hand shaking, as a default assignment.
Nearly all of the Kaypro communications programs to be
found do not support hand shaking, nor do the programs
found in Kaypro support magazines. Hand shaking is
very important in data communications. Without it
characters will be lost in transmission and data tran-
smission si>eed will have to be reduced in an attempt to
achieve reliability. The next segment of this article will
concern itself with a high speed, but simple "dumb" ter-
minal program.
Most Kaypro communications programs may not be
used above 2400 baud. This is due to the programmer's
assumption that higher speeds were not possible. In fact
their programs did not implement the system's hand
shaking facilities. KTERM may be run at 19200 baud.
Higher speeds are possible, but the Kaypro CONFIG
program only allows up to 19200 baud. This is more than
fast enough to get the full power from your Ampro Series
100 microcomputer.
KTERM is available on disk preconfigured for easy in-
stallation of the Ampro Series 100. Lacking that, compile
the Turbo Pascal, Version 3.0, program shown in Figure
3. Once you have assured that it has compiled properly,
place it on a newly formatted, Kaypro disk. Add to this
disk the Kaypro CONFIG program. From this point on-
ward it is assumed that you have studied both the Kaypro
and Ampro System Manuals. If you have not studied
them, do so now.
The Kaypro "Serial Data Port" is connected to a Serial
In/Out processing chip, (SIO). This SIO is referred to as
SIOl on the Kaypro Series 84 systems. SIOl, Channel 'A'
is not supported by the Kaypro BIOS. It is, however,
initialized on power-up as the keyboard uses Channel 'B'
of this SIO. Our Program initializes Channel 'A' for its
own use, without disturbing Channel 'B.'
The Kaypro's default modem data transmission rate is
300 baud. It will have to be changed to the rate of 9600
baud. This will allow us to communicate with the Ampro,
whose default data rate is 9600 baud, long enough to
reconfigure the Ampro for higher data speeds. Use the
Kaypro CONFIG program, option 'M,' to set the Kaypro
for a 9600 baud default data transmission rate. Press the
Kaypro RESET button to assert the changes by writing
them onto the system tracks of your disk.
Run KTERM.
Insert the Ampro SYSTEM DISK into drive 'A' of the
Ampro. With KTERM running, turn on the Ampro. The
Ampro log-on message may not be displayed properly,
but it should be readable.
Enter CONFIG
Use the AMPRO CONFIG program, option '6,' to con-
figure Serial Port 'A' as follows :
1.8 data bits
2. 1 stop bit
3. even parity
4. 9600 baud
5. with hand shaking
When you have assured that the system is functioning
properly you may increase the baud rate to 19200, though
9600 is fast enough for most operations.
Changing Baud Rates
To increase the baud rate, or lower it, enter the Ampro
CONFIG program and set the desired baud rate. Install
the changes ON DISK only. Do not install the changes in
memory or communications will be lost. Exit KTERM
and use the KAYPRO CONFIG program to set the
desired baud rate. Press RESET on the Kaypro, and en-
ter KTERM. RESET the Ampro and you should be on-line
again.
The Terminal Program
KTERM is a very simple program. It has no features
whatsoever. I have often been using the Ampro and found
myself changing disks in the Kaypro, instead of the Am-
pro. This is the kind of terminal function I prefer.
KTERM may be easily expanded to suit your own tastes.
We begin our discussion of the Pascal program with the
first functional Hne of code. The entry:
{C-}
is a Turbo Pascal specific compiler option which inhibits
the interpretation of control characters by the program.
This feature is a must. Without it the host computer
would attempt to act upon any control characters input at
the console. We want the Ampro to to be sent control
The Computer Journal / Issue #22 45
Figure 3
HERMIT SOFTWARE
Pascal Program Source File
Program: KTERM
Version: 1.0a
Class : Public Domain Utility
Author : C. Thomas Hilton
Date: July 12th 1985
Hardware Requirements:
Program Comments:
{«C->
type
Kaypro 4-84
Ampro Series 100, Model 122
The maximum speed that knoMn Kaypro communications
programs have been able to interface with the Ampro 122 ha
been 2400 baud.
This dumb terminal program corrects the de-fects of these
programs by allowing the AMPRO 122 to communicate with a
Kaypro 4-84 at 19200 baud, the maximum data transmission
rate allowed by the Kaypro CONFIG program.
Use the Kaypro CONFIG program to set the baud rate in the
KTERM working disk as the default data rate.
This program is in routine use, and shoMS no de-fects. See
the main text of this Application Note for the ATV^RO 122
configuration set by the AMPRO CONFIG program.
Use the ~-9, (null control code), to exit the program.
This is the only user command available, or needed for
particular application.
< Turn off control character interpretation by program
warkstring-string[803| < define a utility variable >
const < define program constants >
txrdy-4» < transmitter buffer ei^ity mask value >
rxrdy-lj t receiver buffer full mask value >
dat«part-4; < SIO-1 'A' data I/O port assignment >
status-6; { SIO-1 'A' control /status port assignment >
DtrH«it»«o8; < 'Hey I'm Busy' DTR flag value >
DtrRdy'«E8; { 'Ready When You Are' DTR flag value }
finis: boolean;
ch:char;
< set system variables
Functions ti Procedures >
FUNCTION ReadSt at: boolean; < turns TRUE if character received }
begin
ReadStat:'< (portCstatus] and rxrdy) <>0>
end; {of ReadSt at}
46
The Computer Journal / Issue #22
wabasK
77
PmmclcSmcs
DISKETTES
%
ea.
CefWied 100% Error Frm
Mnts aN InduslT^ Standirds
Manutacturef o1 Magnetic Media
fix Over 20 years BOXED witli ENVELOPtS and LABELS
Reinforced Hub Ring
Lifetime Warranty ^ « ^ nn
5.25"SSD0,S0R SECTOR, w/hub ring $.95 $.77
5.25"DSD0, SOFT SECTOR, w/hub ring 109 .88
DataTech
Lifetime Warrantv 100% Error Free
UNIQUE EASEL-BACK CASE lurKtions as
Library Boi tor cortveniertt. permanent
storage and easy diskette access
5.25" SSSD. son SECTOR, w/hub ring
5.25" SSDD, SOFT SECTOR, w/hub ring
5.25" DSDD, SOR SECTOR, w/hub ring
5.25" OSOD, SOFT SECTOR, w/hub ring
5.25" SSSD, 10 SECTOR, HARD w/hub ring
8"SSSD, SDR SECTOR, Unformatted
8" SSDD, SOR SECTOR, Unformatted
8" DSDD. SOR SECTOR, Unformatted
3.5" SSDD, 135 TPI
3.5" DSDD, 135 TPI
DISKETTES
10 100
$ ,98 $ .91
1.18
1.28
1.88
1.18
1.79
1.88
1.98
2.79
3.89
.99
1.11
1.59
.98
1.59
1.69
1.89
2.59
3.69
SUPER SPECIAL!!
5.25" HIGH DENSITY DISKEHES lor use on IBM PC-AT
10 / S2.35 each, 100 / S2.20 each
DEALERS! SCHOOLS! USER GROUPS!
CALL FOR VOLUME DISCOUNTS
Terms: Add $3 shipping & handling tor U.S. orders. Outside
USA add $10 to cover postage. In Illinois add 7% sales tax or
provide resale certificate Prices. & terms subject to change
without notice.
CALL TOLL FREE (orders only)
H 1-800-222-1248
in Illinois or for information
312-882-8315
AUTHORIZED WABASH DISTRIBUTOR
DIGITAL IMAGES
1185T0WERRD.SCHAUMBURG.il 60195
codes from the terminal, and to act upon them. Essen-
tially we want the terminal program to make the Ampro
appear as if it were the only system in use.
Pascal TYPE and VARIABLE declarations, as shown
in Figure 3, are generic, and need not t)e modified for
systems other than the Kaypro.
The program CONSTA^fT declarations, however, may
be redefined for non-kaypro users, or owners of differing
models.
Function READSTAT does little more than determine
the the status of the receiver register of the SIO. Function
READCHAR polls READSTAT untU the SIO indicates
that a character has been received. It will then input the
character. A logical AND is performed to mask-off any
parity bit. In some systems, and terminals, the parity bit
may trigger graphics characters.
Procedure INIT initializes the SIO (which the Kaypro
ignores, save for setting the keyboard channel) for data
communications. This set of code sets the data channel
for our default data format of an 8 bit data word length, 1
stop bit, and even parity. Consult a ZILOG manual for the
actual meanings of the codes shown. The operation of the
SIO is beyond the scope of this small program.
Procedure WRITECHAR simply sends a keyboard
character to the Ampro upon demand. Procedure CEN-
TER centers the KTERM log-on message on the host 80
column terminal.
The main program organizes all of the above functions
and procedures to perform the logical exchange of data
between the two systems. This includes the setting and
resetting of the hand shaking signals. A test is made for
an escape character, control @, (^@). If the escape
character is detected, as an input character from the
keyboard, the program aborts to the operating system.
KTERM is one of those simple programs that hardly
rate a comment, but are found in constant use. I use it ex-
clusively with the Ampro, and cannot function without it.
Other programs have features that do not allow me to in-
terface with the Ampro as if it were actually the host
system.
Configuring The System
If you purchase a Series 100 system, you will receive
T/MAKER* , ZCPR3* , the "FRIENDLY OPERATING
ENVIRONMENT* ," and standard CP/M* 2.2 as a "sof-
tware bundle." Those who elect for other configurations
will have these bundled programs as options. The
T/MAKER package is a powerful set of applications
programs, in a single system. WordStar* is not included
in the bundle as T/MAKER has its own word processing
system.
The Friendly system is configured with WordStar,
( WS), cursor commands. T/Maker, uses a more standard
approach. The CP/M version of TM is set to use cursor
control codes which are compatible with the ADM 3-A
terminal, and Kaypro computers. Three different sets of
cursor commands is at best, frustrating, especially if
your system has user definable keys, as does the Kaypro.
There are two options, either change the TM editing
codes, which is allowed by the system, to those of the
operating environment, or change the control codes of the
operating environment. As a WS user this was a hard
decision for me to make, especially since I use two dif-
The Computer Journal / Issue #22
47
FUNCTION ReadChar:char; { read a character from SIO when char
begin
repeat unti 1 (ReadStat ) ;
ReadChar:=char (portCdataport3 and «7f )
end; {of ReadChar>
arr I ves
PROCEDURE Init?
begin
portCstatusJ : =«18;
port t status] : =1 ;
port C status 3 : =0;
port C statusJ : =3;
port C status ]:=«0El;
port CstatusJ : =4;
port t status] : =«47;
port Cstatus] : =5;
port C st atus 3 : =%0cB;
end; <of Init >
{ set SIO-1 'A' for program use
reset Channel 'A'
call SIO interrupt register 1
disable interrupt functions
call SIO receiver parameters register 3
set for 8 data bits, enable receiver
call SIO protocol register 4
one stop bit, even parity, X16 clock
call transmit parameter register 5
set for 8 data bits, enable transmitter
and set Data Terminal Ready, (DTR)
PROCEDURE WriteChar<kc:char>; { send a character to Ampro
{ because no human could ever type so fast that the Ampro Mould miss a
{ character no output handshaking is supported in this program. Other
{ uses might require a treatment similar to that shown below for output
{ handshaking.
begin
repeat unti 1 <portCstatus] and txrdy) <>0; { is buffer empty''
^. ^°':*"***P°''*'^ :=ord(kc); { when buffer empty send character out
end; <of WriteChar>
PROCEDURE Center <S: htorkString) ; { general utility for log-on, log-off >
var R: integer; w^ utt
begin
for R: = l to <80-Length<S) ) div 2 do WriteC ');
writeln (S) ;
end; < of center >
B«gin Main Program
begin
'"^*» i Initialize SIO-1 'A' for our use
clrscr; { begin log-on sequence for Kaypro screen only
center ('Hermit Software" s' ) ;
writeln;
center CK-TERM Version 1.0a');
writeln;
center CA Kaypro 4-84 / Ampro Series 100 Dumb Terminal Program');
center ('Released Into The Public Domain July 1985');
writeln;
center ('Press -^ to Exit');
writeln; writeln; writeln;
writeln ('System Ready'); writeln; { End of log-on sequence
finis:«f*lse; { set initial boolean escape value
repeat < begin main loop
if (keypressed) then < has a key been pressed?
begin
read(kbd,ch); < get it if so }
if (ch--~e) then finis :»true { if exit code then exit without >
< sending to Ampro }
else
end;
WriteChar (ch) ;
< if valid character then send to Ampro >
if (ReadStat) then { check to see if a character has been received >
''*5in { ».t DTR BUSY flag line >
port C status] : =»5; port Cstatus] : ^DtrWai t ;
write (ReadChar); < print the character >
port Cstatus]: -5; portC6]:=DtrRdy; < reset DTR for next character
end;
until (finis); { ^^ 'finis' turns TRUE comes here >
writeln; writeln; writeln;
writelnCExiting KTERM Have A Nice Day! '); < log-off mnsage >
*"**• C termination >
48
The Computer Journal / Issue #22
ferent computers on a daily basis. I chose to alter the
operating environment codes. The size, and number of
commands in the TM system made the choice a little
easier.
ZCPR3 has a portion of the system BIOS set aside for
terminal control code definitions. We will discuss these
stored terminal codes, and how to use them, in a later ar-
ticle. If you are using a popular terminal, or computer as
a terminal, installation is a simple matter. At the com-
mand prompt enter :
AO > TCSELECT MYTERM < RET >
a menu of supported terminals will be displayed to select
from. The "TC" in the command name stands for "ter-
minal cap." This 'cap" is the set of terminal control
codes stored in the system BIOS. The support for these
terminals, and systems, are very generic in nature. I
found that I received better performance from the
system by installing ZCPR3 manuaUy, using the "TC-
MAKE.COM" utUity.
One of the very nice things about the Ampro systems is
the fact that they may be adapted easily to most any kind
of terminal, or display system. In my work for the
visually impaired we have used a serial keyboard as the
input device, and a voice sythesizer as the output device.
While we made extensive BIOS modifications, the actual
hardware interface took only moments to accomplish.
Due to the wide range of devices that may be used as a
terminal, specific installation discussion would be
meaningless to most readers. Everyone would feel that
their system was not covered. The Ampro documentation
is well done, and guides the first time user through the in-
stallation steps required for non- standard terminal
systems.
As TM is the only full featured text editor, (ED.COM is
also provided), I do have a comment to make for those
who will be using TM for programming. TM produces
sterile ASCII code. Unlike some editors, who use flipped
bits and other trash for system use, TM does not put its
flags in the general text. It does have a quirk, however.
TM has a maximum line length of 300 characters in a
Ca»/M system, 400 for 16 bit systems. Yes, 300 characters !
The screen can scroll left and right, as well as up and
down! An off-screen "first line" stores the user's tab set-
tings. A wide number of assemblers and languages get
very upset when the first thing they see in the program
file is a line of 300 characters. This "tab line" is com-
posed of nothing but spaces and tab characters.
When installing TM answer NO to the question "Should
TABs be stored with the file?" By placing the cursor on a
line of text and entering <ESC> S <TAB> TM will
record tab characters, for the current editing session
from this "model line." As TM is the bundled editor with
the Series 100 systems, I will provide a tab line for all
programs. The tab line problem is offset by the ability to
produce extremely high quality printed listings, and
documents with T/Maker.
For those who wish to leave the tab line in their text
files, there is an option. When saving programs enter:
at the "WHAT NEXT?" prompt. Remember that, like
ZCPR3, TM allows command lines of up to 255 charac-
ters.
My only complaint with TM, other than having to learn
new editing keystrokes, is the inability to execute a .COM
file from the command line. Learning to use TM as a
programming tool will be included in future articles as
well.
While I didn't get into very much "good stuff" this
time, it is hoped that this information will help you to get
your system fimctional. Between the time you read this,
and the next issue of TCJ is published, make friends with
your system. In this way you will be ready for the projec-
ts to come. There is a great deal planned for the future. A
new CCP, (console command processor), for a larger
TPA, a voice output enhanced BIOS, and a close look at
the schizoid 'E' drive which allows reading, writing and
formatting of other system's disks, to name but a few. I
didn't know where to start a column. So, I began at the
beginning, and there is a great deal I would like to cover
that I didn't even get close to this time. Of course, if you
have a project you are interested in seeing covered here,
let me know. This is your column, as em Ampro user. ■
• * *
AMPRO User Support
Tom and I are both impressed with the AMPRO Little
Board and their Bookshelf 100 computer series, and we
making a major user support effort for these systems.
In addition to this series of articles (plus the NEW-DOS
series which is aimed at the AMPRO), Tom is preparing
an AMPRO user disk library of 25 to 30 DSDD disks.
These disks will be distributed thru the TCJ office, and
we will provide an on-line RBBS when we can obtain an
additional phone line. New disks will be added to the
library as the material is available.
I am especiaUy interested in SCSI related software,
and plan on establishing separate disk volimins for this
topic. Any SCSI material (whether for the AMPRO or
not) will be greatly appreciated.
NOT ABS SAVE
The Computer Journal / Issue *22
49
Editor
(Continued from page 1)
The SCSI Interface
Interfacing to microcomputers
has been hmited by the lack of a
satisfactory high speed port. Most
Centronics® ports are implemented
as only a printer driver with eight
lines for data output and a few lines
of input for printer status. The RS-
232 configuration dates back to the
slow Teletype® days and is slow
with a lot of non-standard implemen-
tations, and the IEEE-488 doesn't
really fill the needs of the micro
market. The SCSI interface
(originally SASI) was developed by
Shugart as a high speed parallel in-
terface for hard disks, and is being
adopted by many manufacturers as
a general interface.
Almost every issue of the technical
design magazines tell about new
designs incorporating the SCSI inter-
face, and you'll be dealing with it in
the very near future. Some of the
reported implementations are the
expanded Macintosh from Apple, the
next micro from IBM, and the Apple
LaserWriter II (which has 8 Mbytes
of RAM and ROM) . The Ampro little
boards (both the Z-80 and the 80186
versions) provide SCSIplus, which is
one thing which makes these such
great development systems. Star-
ting with th^ issue we'll have a
regular section on SCSI with
technical information, applications,
and product news.
Communications, User Disks, Odds
&Ends
We finaUy have a 300/1200 baud
modem running on MDM740 (the
communications program came in-
stalled an the Ampro), and can
receive and send files over the
phone. We would like to establish a
bulletin board, but the phone com-
pany can not provide a second line
and we can't tie up the existing line.
For now we prefer to receive articles
on disk, but arrangements can be
made to transfer by modem if you
call by voice in the evening. Short
messages and subscriptions by
charge card can be left for Art
Carlson on the Kalispell BBS (406)
257-6117 during the hours of 6pm to
Sam Monday through thursday, 6pm
Friday to 11am Saturday, and all
day on Sunday Mountain Time.
These facilities are provided by The
Computer Place and the storage is
limited, so please don't abuse the
privilage. Would it help if we had a
BBS on line during the limited hours
of 10pm to Sam mountain time until
we can obtain a second line? Leave a
message and let me know.
Tom Hilton will be the librarian
for CP/M user's disks in the Ampro
5V4 inch DSDD format, and the or-
ders will be filled from the TCJ of-
fice. We'll be starting with about 25
disks of general CP/M files, and will
add more as they develop. These
files can be provided on some ad-
ditional formats on request. Watch
for more details in the next issue.
I've been plagued with erratic
read and write errors on one set of
Shugart 8008" single sided drives.
They would almost always read and
write OK on the outer tracks, but
would frequently give problems on
the tracks above about number 60. I
checked the voltages, changed the
head load pads, cleaned the heads,
and tried different disks, but the
problem would alway reappear. I
finally tried the drives in another
cabinet with a linear power supply,
and they worked perfectly so I
THE BEST 280
ASSEMBLER ON
THE MARKET JUST
COT BETTER!
figured that there just had to be
something wrong with the power
supply.
This is a very strange set up with a
low height switching type power
supply mounted directly beneath the
drives, and I have to set the drives
outside the case in order to get at the
supply. I put my old Heath scope on
the output to check for 60 cycle ripple
(again), and it looked clean— but
then I noticed that the line looked a
little fuzzy. When I cranked up the
intensity I could see that there was a
lot of high frequency noise riding on
the DC. I put 20,000 mfd on each of
the outputs and the drives performed
flawlessly while the drives were out
of the case. After reassembling
everything I still get occasional
problems from RFI picked up by the
drives or the wiring. I'll have to pull
the supply and put it in a separate
well shielded enclosure with filtered
output or just replace it with a linear
supply.
It's httle things like this that drive
you nuts! Share your experiences
and problems with others, perhaps
the Kalispell BBS will make it easier
to communicate.
NOW$
ONLY '
DON'T ASK HOW OURS CAN BE SO FAST .
ASK WHY THEIRS ARE SO SLOW!
'. . a breath of fresh air . ."
Computer Language. Feb. 85
". . in two words, I'd say speed &
flexibility",
Edward Joyce, User's Guide #J5
Now fully compatible with M80
in Z80 mode with many exten-
sions. Time & date in listing, 16
char, externals, plus many other
features.
To order, or to find out more
about our complete family of
development tools, call or write:
'LflSystems
1622 N. Main St, Butler. PA 16001
(800) S33-3001, <412) 282-0864
Teles 559215 SLR SYS
■ B
C.O.D.. Check or
Money Order Accepted
mm sec 1:17 3:26 S:2S 6:13
2Mhi
8" SS/SD
32 :4S1M
SMhz
Ram Disk
SHIPPING USA/CANADA • t3 • OTHEB APEAS • 110
Z90 CP^ compeiibtiity required
50
The Computer Journal / Issue #22
The Magazine Marketplace
Now Uiat Creative Computing and
Popular Computing have ceased
publishing, we need to think about
what we want in a magazine. Who
should support a magazine, the
readers or the advertisers? Who
should a magazine support, its
readers or the advertisers? Are
readers only necessary as numbers
to justify high advertising rates?
I have just received a mailing
from Ziff-Davis Professional List
Services offering to rent the mailing
list for Creative Computing (which
Ziff-Davis shut down last month),
and they say that Creative Com-
puting has (or rather had) 233,772
subscribers. If my memory serves
me right, one of the other magazines
had over 500,000 subscribers when
they shut down. These magazines all
gave the same reason for
folding— falling advertising income.
It didn't matter that they had
several hundred thousand sub-
scribers—advertising dollars were
what kept them open.
You would think that the subscrip-
tions from a half-million readers
should be enough to support a
magazine without ANY advertisers,
but producing a slick magazine with
lots of four color illustrations is very
expensive. Magazine rack sales are
another drain. I have seen audited
reports which stated that 60% of the
magazines sent to the magazine
racks were unsold and sent to the
shredders. The specifics in one case
were 90+ thousand sent out and 60+
thousand shredded for that month.
Someone has to pay for the 60,000
magazines turned into scrap
paper— and it isn't the subscriber.
Everthing seems to cost too much,
and subscriptions to the better
magazines are not cheap, but in
many cases the price of a subscrip-
tion does not even cover the cost of
printing and mailing the issues— and
I understand that when subscrip-
tions are placed through the national
subscription agencies all of the
money may go to the agency without
one penny to the publisher. We sub-
scribers have come to expect large,
slick, four-color magazines at low
cost, or even below cost, subscrip-
tion fees. Then we complain about
the large percentage of advertising
(up to 75% of the space) and the
weak editorial content! As Frank
said in issue 402 of Echelon's Z-News
"Many computer magazine editors
have little or no investment in or
emotion for our industry or its har-
dware... You seldom notice jmything
written that offends anyone; you
notice they remind of melba
toast... Remember, their revenue
comes mainly from advertisers, not
from you their readers." It is ob-
vious that if profit and continued
existence depend on the advertisers,
then the readers will be treated
merely as numbers to justify high
advertising rates— and the subscrip-
CP/M
MSDOS
AFFORDABLE
ENGINEERING
SOFTWARE
TRSDOS
PC DOS
• LOCIPRO Root Locus — $69.95
• ACTFIL Active Filter Design/Analysis — $69.95
• STAR Static Thermal Analysis — $69.95
• MATRIX MAGIC Matrix Manipulation — $69.95
• RIGHTWRITER Proofreader & Writing Style Analyzer — $74.95
• ACNAP2 AC Circuit Analysis — $69.95
• DCIMAP DC Circuit Analysis — $69.95
• $PP Signal/System Analysis — $69.95
• PLOTPRO Scientific Graph Printing — $69.95
• PCPLOT2 High Resolution Graphics — $69.95
Engineering
Professional Software
2200 Business Wfly Suite 20 7 • Riverside CA 92501 • (714) 7S1 -0282
ES [M
<
tion rates will have to very low to at-
tract large numbers of readers who
don't gain much from the magazine.
I know that I've subscribed to
magazines which didn't have much
useful content, but they were so thick
and cheap that it seemed a bargain.
We publish TCJ for the readers,
and limit the advertising to products
that we feel our readers should know
about. The limited funds restrict the
amount of promotion we can afford,
and we can't pay the authors as
much as we would like, but we are
free to publish what our readers
want without worrying about offen-
ding any advertisers. If you like an
article, write the author and let him
know, because they aren't doing it to
get rich but rather because they
want the information published ! ■
Registered Trademarks
It is easy to get in the habit of using
company trademarks as generic terms,
but these registered trademarks are
the property of the respective com-
panies. It is important to acknowledge
these trademarks as their property to
avoid their losing the rights and the
term becoming public property. The
following frequently used marks are
acknowledged, and we apologize for
any we have overlooked.
Apple n, II + , lie, He, Macintosch,
DOS 3.3, ProDOS; Apple Computer
Company. CP/M, DDT, ASM, STAT,
PIP; Digital Research. MBASIC;
Microsoft. Wordstar; MicroPro Inter-
national Corp. IBM-PC, XT, and AT;
IBM Corporation. Z-80. Zilog. MT-
BASIC, Softaid, Inc. Turbo Pascal,
Borland International.
Where these terms (and others) are
used in The Computer Journal they are
acknowledged to be the property of the
respective companies even if not
specifically mentioned in each occuren-
ce.
The Computer Journal / Issue #22
51
Mew Products
Bootable Z-System for H89/90
Analytical Products offers a
Bootable Z-System disk for Heath
and Zenith models 89 and 90
machines with no installation
required. Just place the disk in the
drive and press reset and the full Z-
System, completely replacing
CP/M, is up and running. The price
for the bootable disk is $98.00 plus
$3.00 shipping and handling. Source
code for ZCPR3 and its utilities, and
utilities of ZRDOS are also available
at additional cost. The ready-to-run
H89/90 Z-System can be ordered
from Analytical Products, 20663
Avenue 352, Woodlake, CA 93286, or
call Mr. Peter Shkabara at (209) 564-
3687 for literature and more infor-
mation on Heath and Zenith produc-
ts.
Amiga-Lint C Diagnostic Facility
Gimple Software announced their
Amiga-Lint, a diagnostic facility for
the C programming language, run-
ning on the Commodore Amiga.
They state that Amiga-Lint will
analyze C programs and report on
bugs, glitches and inconsistencies, in
effect, providing a strong typing
facility for C. Amiga-Lint looks
across multiple modules and so en-
joys a perspective that a compiler
doesn't have. It aids considerably in
developing reliable programs and in
porting programs from other
machines and operating systems.
Amiga-Lint resembles the Lint that
runs on the UNIX O.S. but has more
feature and is better tuned to the
68000 environment.
Among the many errors reported
on by Amiga-Lint are: type incon-
sistencies across modules,
parameter-argiunent mismatches,
library usage irregularities,
uninitialized variables, value-return
inconsistencies, variables declared
but not used, suspicious use of
operators and unreachable code.
Amiga-Lint has many features, in-
cluding fuU K&R support, one-pass
very fast operation, no fixed-size
tables to overflow, configurable to
arbitrary architectures and special
Lint-style comments to suppress
errors. Amiga-Lint is delivered with
user-modifiable standard library
descriptions for several C compilers.
Amiga-Lint runs under Amiga's
CLI interface. It will use all the
memory available. Amiga-Lint is
available for the special introduc-
tory price of $98.00, including ship-
ping within the continental U.S.
directly from Gimple Software, 3207
Hogarth Lane, Collegeville, PA 19426
(215) 584-4261.
CP/M-80 Emulation for MS-DOS
The ICU Group has annoimced
CP/EM-CP/M 80 Emulation which
they claim gives IBM PC/XT/ AT
and compatible computers the
ability to run thousands of CP/M 80
programs without the expense of ad-
ditional coprocessor boards.
CP/EM efficiently emulates the
CP/M 8060 and Z80 environments on
an MS-DOS based personal com-
puter. CP/EM allows MS-DOS
redirection of input and output
devices used to alter device assign-
ment allowing CP/M access to all
standard MS-DOS devices and any
installed device drivers. CP/EM
uses the standard MS-DOS file
system allowing data files to be
shared between CP/M and MS-DOS
applications. The (Command Interr-
preter provides aU of the standard
conunands provided by the CP/M
console command processor.
CP/EM version 1.2 provides ter-
minal emulations for the Kaypro 10,
ADM 3A/5 and Televideo 950. Serial
conununications programs are in-
cluded with CP/EM to aid in the
transfer of programs and data bet-
ween the CP/M and MS-DOS com-
puters. CP/EM runs on any MS-
DOS, version 2.0 or later, based per-
sonal computer with at least 32K of
memory available for application
programs.
CP/EM can be ordered from The
ICU Group, PO Box 10118,
Rochester, NY 14610 (716) 425-2519
DOS 3.3 Compatibility with Apple's
800K UnlDisk
Apple Computer's new 800K
UniDOS 3.5 drive gives five times the
storage capacity of floppy disks, but
no program support for Apple's DOS
3.3 operating system.
MicroSPARC's new UniDOS 3.3
operating system fills this gap for
programs and data files that exist
under DOS 3.3 by providing big 800K
disk capacity and complete Ap-
plesoft compatibility with Apple's
DOS 3.3.
Key UniDOS features are: (1) Two
400K volumes per disk; (2) Supports
up to two UniDisk 3.5 drives ad-
dressable as drives 1-4; (3) Allows
intermixing 5.25 inch and 3.5 inch
drives; (4) Allows up to 217 catalog
names per disk; (5) Uses only IK of
user memory (in addition to normal
DOS 3.3 memory space) .
UniDOS 3.3 comes with a user
manual and Technical Data Sheet
showing the modified DOS 3.3 ad-
dress for systems progranrniing. It
runs on the Apple II Plus, Apple He,
and Apple lie, smd software
developer licenses are available.
UniDOS 3.3 is available for $49.95
postpaid from MicroSparc Inc., 45
Winthrop Street, Concord, MA 01742
(617) 371-1660
MasterFORTH Supports 8087
MicroMotion MasterFORTH 1.2
for the IBM PC family now supports
the 8067/80287 math co-processor.
This 8067 extension includes a com-
plete macro assembler with local
labels supporting all precisions, op-
codes, and synchronization. The
floating-point package includes a full
complement of transcendental and
high-level functions, as well as for-
matted input and output routines.
Both the assembler and the floating-
point package are provided as sour-
ce files and as relocatable overlays.
A software version of this package,
which completely matches the har-
dware version, is also available. Ap-
plications can test for the presence
( Continued on page S4)
52
The Computer Journal / Issue #22
Back Issues Available:
Volum* 1. Ntimbcr 1 (Ittu* #1):
• The BS-232C Serial Interface, Part One
• Telecomputing with the AppleU: Tran-
sferring Binary Files
• Beginner s Column, Part One: Getting
Started
• Build an "Epram"
Volum* 1. Number 2 (Issua »2):
• File Transfer Programs for CPIM
• The RS232C Serial Interface, Part Two
• Build a Hardware Print Spooler, Part
One: Background and Design
• A Review of Floppy Disk Formats
• Sending Morse Code With an Apple][
• Beginner's Column, Part Two: Basic
Concepts and Formulas in Electronics
Voluma 1 , Number 3 (Issue #3):
• Add an 8087 Math Chip to Your Dual
Processor Board
• Build an AID Converter for the AppleU
• ASCII Reference Chart
• Modems for Micros
• The CPIM Operating System
• Build a Hardware Print Spooler, Part
Two: Construction
Volume 1. Number 4 (Issue #4):
• Optoelectronics, Part One: Detecting,
Generating, and Using Light In Electronics
• Multi-user: An Introduction
• Making the CPIM User Function More
Useful
• Build a Hardware Print Spooler, Part
Three: Enhancements
• Beginner's CoUmn, Part Three: Power
Supply Design
Volume 2, Number 1 (Issue #5):
• Optoelectronics, Part Two: Practical
Applications
• Multi-user: Multi-Processor Systems
• True RMS Measurements
• Gemini- 10X: Modifications to Allow
both Serial and Parallel Operation
Volume 2, Number 2 (Issue #6):
• Build a High Resolution S-100 Graphics
Board, Part One: Video Displays
• System Integration, Part One: Selecting
System Components
• Optoelectronics, Part Three: Fiber Op-
tics
• Controlling DC Motors
• Multi-User: Local Area Networks
• DC Motor Applications
Volume 2, Number 3 (Issue #7):
• Heuristic Search in Hi-Q
• Build a High-Resolution S- 100 Graphics
Board, Part Two: Theory of Operation
• Multi-user: Etherseries
• System Integration, Part Two: Disk Con-
trollers and CPIM 2.2 System Generation
Volume 2, Number 4 (Issue #8):
• Build a VIC-20 EPROM Programmer
• Multi-user: CP/Net
• Build a High-Resolution S- 100 Graphics
Board, Part Three: Construction
• System Integration, Part Three: CPIM
3.0
• Linear Optimization with Micros
• LSTTL Reference Chart
Volume 2, Number S (Issue #9):
• Threaded Interpretive Language, Part
One: Introduction and Elementary
Routines
• Interfacing Tips and Troubles: DC to DC
Converters
• Multi-user: C-NET
• Reading PCDOS Diskettes with the
Morrow Micro Decision
• LSTTL Reference Chart
• DOS Wars
• Build a Code Photoreader
Volume 2, Number 6 (Issue #10):
• The FORTH Language: A Learner's Per-
spective
• An Affordable Graphics Tablet for the
Apple ][
• Interfacing Tips and Troubles: Noise
Problems, Part One
• LSTTL Reference Chart
• Multi-user: Some Generic Components
and Techniques
• Write Your Own Threaded Language,
Part Two: Input-Output Routines and Dic-
tionary Management
• Make a Simple TTL Logic Tester
Volume 2, Number 7 (Issue #11):
• Putting the CPIM lOBYTE To Work
• Write Your Own Threaded Language,
Part Three: Secondary Words
• Interfacing Tips and Troubles: Noise
Problems, Part Two
• Build a 68008 CPU Board For the S-100
Bus
• Writing and Evaluating Documentation
• Electronic Dial Indicator: A Reader
Design Project
Volume 2, Number 8 (lesue #1 2):
• Tricks of the Trade: Installing New I/O
Drivers in a BIOS
• Write Your Own Threaded Language,
Part Four: Conclusion
• Interfacing Tips and Troubles: Noise
Problems, Part Three
• Multi-user: Cables and Topology
• LSTTL Reference Chart
Volume 2, Number 9 (Issue #1 3):
• Controlling the Apple Disk ][ Stepper
Motor
• Interfacing Tips and Troubles: Inter-
facing the Sinclair Computers, Part One
• RPM vs ZCPR: A Comparison of Two
CPIM Enhancements
• AC Circuit Anaysis on a Micro
• BASE: Part One in a Series on How to
Design and Write Your Own Database
• Understanding System Design: CPU,
Memory, and I/O
l»»u» Number 14:
• Hardware Tricks
• Controlling the Hayes Micromodem II
From Assembly Language
• S-100 8 to 16 Bit RAM Conversion
• Time-Frequency Domain Analysis
• BASE: Part Two
• Interfacing Tips and Troubles: Inter-
facing the Sinclair Computers, Part Two
/ssue Number 15:
• Interfacing the 6522 to the Apple ]l and
He
• Interfacing Tips and Troubles: Building
a Poor-Men's Logic Analyzer
• Controlling the Hayes Micromodem II
From Assembly Language, Part Two
• The State of the Industry
• Lowering Power Consumption in 8"
Floppy Disk Drives
• BASE: Part Three
Itaue Number 16:
• Debugging 8087 Code
• Using the Apple Game Port
• BASE: Part Four
• Using the S-100 Bus and the 68008 CPU
• Interfacing Tips and Troubles: Build a
"Jellybean" Logic-to-RS232 Converter
lB9ut Number 17:
• Poor Man's Distributed Processing
• Base: Part Five
• FAX-64:Facsimile Pictures on a Micro
• The Computer Corner
• Interfacing Tips and Troubles: Memory
Mapped 110 on the ZX81
laaue Number 18:
• Interfacing the Apple II: Parallel
interface for the game port.
• The Hacker's MAC: A letter
from Lee Felsenstein
• S-100 Graphics Screen Dump
• The LS-100 Disk Simulator Kit: A
product review.
• BASE: Part Six
• Interfacing Tips & Troubles:
Communicating with Telephone
Tone Control
• The Computer Corner
The Computer Journal / Issue #22
53
IMU* Number 19:
• Using The Extensibility of FORTH
• Extended CBIOS
• A $500 Superbrain Computer
• Base: Part Seven
• Interfacing Tips & Troubles: Part Two
Communicating with Telephone
Tone Control
• Multitasking and Windows with CP/M:
A review of MTBASIC
• The Computer Corner
Issue Number 20:
• Build the Circuit Designer 1 MPB:
Designing a 803S SBC
• Using Apple II Graphics from CP/M:
Turbo Pascal Controls Apple Graphics
• Soldering and Other Strange Tales
• Build a S-100 Floppy Disk Controller:
WD2797 Controller for CP/M 68K
• The Computer Corner
IiiM Nnmber 21:
• Extending Turbo Pascml: Customize with
Procedures and Functions
• Unsoldering: The Arcane Art
• Analog Data Acquisition and Control-
Connecting Your Computer to the Real
World
• BuUd the Circuit Designer 1 MPB: Part 2 -
Programming the 803S SBC
• The Computer Corner
Ordering Information: Back issues are $3.25 in the U.S. and Canada. Send payment with your complete name and
address to The Computer Journal, 190 Sullivan Crossroad, Columbia FaUs. MT 59912. Allow 3 to 4 weeks for delivery.
Book Sale - These books are offered at this
price while the supply lasts.
Zilog Z80-CPU Technical Manual. $1.50
CBASIC Users Guide
by Osborne, Eubanks, and McNiff, $14.00
Introduction to FORTH
by Ken Knecht, $9.00
FORTH Programming
by Leo J. Scanlon, $13.00
These prices are postpaid in the U.S. only.
TCJ, 190 Sullivan Crossroad, Columbia
Falls. MT 59912.
S-100 68008 CPU BOARD. Detailed descrip-
tion in issue 16 of The Computer Journal.
A&T $260, Kit $210, Bare Board $65. Prices
include shipping. INTELLICOMP, INC.,
292 Lamboume Ave., Worthington, OH
43085, Phone (614)8464216 after 6 p.m.
CMOS PROTOYTPING SYSTEM. Uses
NSC-800 I.e. for Z-80 CompatibiUty, 4 STD-
Bus Cards (Dual Serial I/O, CPU, 32K Sutic
Memory, 24-bit Parallel I/O), battery
powered 6-slot card cage, and standalone
debugging monitor. Mates with Industrial
I/O Racks (Opto22, DuTech, etc.) Complete
package only $795 plus S4H, originally cost
over $1200. Brochure sent on request.
Inpot Video, PO Box 20, Randolph, MA
02368, phone (617) 961-4197.
STD-Boa Cards. Wide assortment of STD-
Bus cards, CPU,s. Memories (Sutic &
Dynamic types). Serial I/Os, CRT con-
trollers, etc. Quantities limited, send SASE
for complete listing and prices. lapot Video,
PO Box 20, Randolph, MA 02368, phone (617)
961-4197.
$25 KEYBOARDS FOR COMPUTER
BUILDERS. Full ASCII, numeric pad,
UC/lc, CAPS-LOCK, REPEAT, SELF-
TEST! Brand new, hundreds sold to
builders of Apples, Xerox 820b, Big Boar-
ds, etc. Parallel TTL output, strobe. 5
volts/lOO ma. Custom case available.
Keyboard $25. Documentation (21
pgs.)/cable fkg. $5. Spare CPU/ROM $4.
All 3 ($34 value) $30. UPS additional, 5
pounds. Detailed specs on request. Elec-
trovalue Industrial Inc., Box 376-CJ,
Morris Plains, NJ 07950. (201)-267-1117.
ORDER FORM
Enter my subscription to The Computer Journal for the period checked. Payment in U.S. funds is enclosed.
D one year (6 issues) $14 in U.S. D two years (12 issues) $24 in U.S. D new subscription D renewal
Back Issues #'s.
.@$3.25ea.
D Check enclosed D VISA D MasterCard Card#.
Expiration date Signature
Name
Address.
City
_SUte .
-ZIP.
The Computer Journal, 190 Sullivan Crossroad, Columbia Falls, MT 59912 Phone (406) 257 9119
54
The Computer Journal / Issue #22
Advertiser's Index
Alliance Computers 12
AMPRO Computers 8, 43
Apropos 24
Artec 41
Barnes Research 40
BD Software 39
John Bell 54
Bersearch 9
Blankenship Basic 40
BV Engineering 50
Classifieds 53
Computer Trader 37
Digital Images 46
Echelon, Inc 4, 29
Intellicomp 19
Jerryco 20
Miller Microcomputer Services. . . 41
Micro Systems Research 24
Next Generation Systems 26
Poor Person Software 15
Public Domain Software. 54
Remote Measurement 38
SLR Systems 49
Softaid 31
GET PUBLIC DOMAIN SOFTWARE!
HUNDREDS OF FREE PROGRAMS AVAILABLE TO COPY!
PUBLIC DOMAIN Software is not copyrighted so no lees to pay' Accounting, data-base,
business, games, languages and utilities tree for tfie taking' Some of ttiese programs sold for
liundreds of dollars before being placed in public domain Join hundreds of users enjoying a
wealth of inexpensive software Copy yourself and save'
USER GROUP LIBRARIES
Rinl
IBMPC-SIG 1 -390 Disksides S410 00
IBMPC-BLUE 1-154 Disksides S175 00
SIG/I^ UG 1-240 Disksides S155 00
CP/M UG 1-92 Disksides $45 00
PICO NET 1-34 Disksides $ 25 00
KAYPRO UG 1-54 Disksides S 65 00
EPSON UG 1 -52 Disksides S 65 00
COMMODORE CBM 1-28 Disksides $ 25 00
Get a PD User Group Catalog Disk - S5 00 PP — Specify Format'
Library rentals are for seven (7) days after receipt, three (3) more days grace to return If you use
your credit card — no disk deposit Shipping, Handling and insurance $9 50 per library Call
(619) 727-1015 for 3 mm recording. Call (619) 941-0925 orders and tech info
NATIONAL PUBLIC DOMAIN SOFTWARE
1533 Avohill Drive, Vista, CA 92084
1-800-621-5640 wtit tor torn, dill 782542
Buy
S850 00
S435 00
S650 00
S250 00
$100 00
$200 00
$200 00
S 65 00
DINERS
CLUB
New Products
(Continued from page 51 )
of the 8087 co-processor and select
the appropriate overlay.
MicroMotion MasterFORTH 1.2
runs on all members of the IBM
family and includes a full file inter-
face to MS DOS 2.1-3.1. It is also
available for the Macintosch, the
Apple family, the Commodore 64 and
CP/M. Software can be written on
one system and run on all the others.
MasterForth retails for $125, and
several additional extensions are
available. MicroMotion, 8726
Sepulveda Fl. #A171, Los Angeles,
CA 90045 (213) 821-4340
Computer Voice For The Blind
Artie Technologies announces the
release of SynPhonix 200- VIP, a low
cost voice synthesizer for Blind and
Visually Impaired users of the IBM-
PC/XT/ AT personal computers.
This product works in conjuction
with other programs to speak the
video screen and text files. Blind in-
dividuals can use SnyPhonix in ap-
plications such as word processing,
spread sheet calculators, program-
ming, and other marketable com-
puter skills. As a personal tool Syn-
Phonix can be used to access com-
puter bulletin boards, data bases,
write letters, etc.
A variety of voices and features
can be controlled by the user from
the computer keyboard. Speech can
be set to an extremely fast rate to
MICROCOMPUTERS
AND
INTERFACES
We have six singi
video boards
PC and API '
use our pn
heat cent]
slide
systems,
mated
just to
For catalog call
rd computers, two
nss for the IBM-
:ers. You can
systems,
automated
rrigation
;ems, auto-
t control
liable,
Ite to:
JOHN BELL ENGINEERING, INC.
400 OXFORD WAY
BELMONT, CA 94002
(415) 592-8411
rapidly scan information and slowed
down to examine details. Volume,
pitch, tone, pausing and number
pronuncation can also be controlled.
A voice type can be selected accor-
ding to the users preference, and the
time can also be spoken on demand.
Complete installation and stari-up
instructions are provided on an
audio tape so that a blind user can
perform the installation without a
sighted companion to read the
manual.
SynPhonix 200-VIP retails for $295
and is available from Artie
Technologies, 2234 Star Court,
Auburn Heights, MI 48057 (313) 852-
8344
The Computer Journal / Issue *22
55
Computer Comer
32 Bit System Bus
On a different note, I would like to
propose a new standard for using 32
bit systems. One of the topics of con-
siderable discussion is how to handle
the new 32 bit wide data structures.
For the hobbyist it is a real problem
of cost versus speed. Most new
systems are being designed as stan-
dalone units which do not use a bus
system. This idea doesn't make use
of a hobbyist's already existing sup-
ply of computer stuff. In my case, I
have quite a few S-100 boards and
would like a system that used them.
Currently, S-lOO will handle 16 bits
by multiplexing the data bus after
flagging a sixteen bit move. S-100
also has some known speed limits,
abour 10 to 12 MHz at present.
I find the speed and use of the six-
teen bit flag an acceptable solution,
but the bus doesn't have room for
more data lines. My proposal is to
use two S-100 buses, side by side. The
32 bit only card would be a double
width S-100 card. This would require
a standard spacing between the bus
systems but for 32 bits that's OK.
TTiis newer use of the extra S-100 bus
would not have to be the standard
pinout. However, if the same pinout
was used on both buses it would
make it possible to use the same
memory cards in each side for 16 or
32 bit wide data. The use of different
S-100 pinouts on the other hand,
allows for some special functions
and signals not now supported by the
standard.
Another option to the use of two
buses side by side would be splitting
a 22 slotter in half, by cutting all the
traces (except power and ground) at
the half way point. A special 32 bit
master card would be two separate
cards connected together (by cable
or socket connection) that spanned
the cut traces. In either case, the
signals and pinouts could either be
the same or different, depending on
the standard developed. I know that
Viasyn was looking for a way to han-
dle preregulated power supply
signals, and this could also be han-
dled with two different buses.
This concept isn't new, as several
of the big boys already have systems
in which a standard number of pins
is used, but the number of sockets
per card varies depending on how
;NO OPS TO HELP SET THINGS UP RISHT
;LOAD NUMBER OF SECTORS IN D REGISTER
;ADDRESS TO START WRITING TRA K DATA TO
;LOAD A WITH DRIVE B NUMBER AND DENSITY
; OUTPUT A TO DISK CHIP, SELECT DRIVE
; TAKE CONTROL AND STOP ANY INTERRUPTS
;SET UP LOOP COUNT VALUES
;DATA PORT ADDRESS IN C FOR INDIR
;DISK CHIPS FULL TRACK COMTV^D
; TELL DISK CHIP READ A FULL TRACK NOW
SHAIT A FEW CLOCK CYCLES
;WAIT SOME MORE FOR CHIP TO GET DATA
; Z80 GET DATA FROM I/O AND WRITE TO HL
; COUNT DOWN ON LOOP COUNTER
; ST ILL LOOPING SO BACK AND SET MORE
;GET BACK TO DDT PROMPT.
USE Q9000 TO RUN PROGRAM. MUST BE ON DESIRED TRACK FIRST
9008 WILL CHANGE FOR DIFFERENT DRIVES AND DENSITY. CHECK
BOO*. FIRST AND WATCH OUT FOR INVERTED LOGIC.
TYPICAL ID MARK OF FORMATTED DISK
FF FF FF 00 00 00 00 00 00 FE 02 00 14 00 C3 2D FF FF FF FF FF
9000
00
00
NOP
NOP
9002
16
lA
MVI
D, lAH
9004
21
00
01
LXI
HL , 1 00H
91307
3E
2D
MVI
A, 7D
9009
D3
63
OUT
63
990B
F3
DI
900C
06
00
MVI
B,00
900E
0E
67
MVI
C,67
9010
3E
E4
MVI
A, 34H
9012
D3
64
OUT
64
9014
18
00
J MP
R,0
9016
IB
00
J MP
R,0
9018
ED
B2
INIR
90IA
15
DCR
D
901B
C2
0C
90
JNZ
900C
901E
FF
FF
FF
RST
7
CRC
SECTOR LENGTH
SECTOR NUMBER
SIDE NUMBER
TRACK NUMBER
THIS TELLS CONTROLLER ID FOLLOWS
many hardware extensions are
needed to handle the project. What is
missing from the other ways, which
the S-100 would provide, is the cost of
this solution. This solution makes
use of the already existing supply of
8 and 16 bit boards, disk controllers
and I/O cards. Most 32 or 16 bit
systems still write/read the disk in 8
bits and do their I/O in 8 bits, which
leaves only memory, graphics, and
CPU functions needing a larger data
path.
A project then for the future will be
a 68020, doing 16 bit data transfers.
The CPU will be spread over two
cards for using two halves of a 22 slot
bus. Regular 8 bit memory and I/O
cards will be in either half, only the
data path will be split, lower 8 bits in
front, upper in back. The need for
such a system would be fast 16 bit
wide video mapping, and this video
would make up the other half of the
CPU card. The 24 bit S-100 address
would be the same for front and
back, allowing generic cards to be
used throughout.
The operating system for the
above would be FORTH, and my
project on putting FORTH in ROM is
still moving along. A few good books
for understanding FORTH are :
Threaded Interpretive
Languages by R.G. Loelinger,
BYTE Books. This book discusses
how a FORTH type system is
designed and implemented. The
sample is a Z-80 FORTH. A good
book for those who want to know
more, somewhat entertaining,
also.
Inside F83 by C.H. Ting Phd,
OFFETE Enterprises, Inc. For
those using FORTH 83 this book is
a must. I was stumbling along until
I got it. The introduction and
details will answer almost all
possible questions.
Don't forget the traditional sources
for help on FORTH:
FORTH INTEREST GROUP, PO
Box 8231, San Jose, CA 95155. They
publish FORTH DIMENSIONS
which is included with the $15
membership fee.
MOUNTAIN VIEW PRESS, INC..
PO Box 4656, Mountain View, CA
94040. These people were the
origin] publisher of FORTH
Dimensions, but now are strictly a
resource center for FORTH
publications.
To see and read about some dif-
ferent applications try one of the
special group publications such as
FORML Proceedings and The
Rochester Proceedings, or The
Journal of Forth Applications and
Research. I got a couple of these
books and found some interesting
stuff. The degree of help is limited
however as these were papers
presented at conferences. ■
56
The Computer Journal / Issue #22
THE COMPUTER CORMER
A Column by Bill KIbler
oeveral things have happened
recently to cause me to review some
disk format fundamentals. It seems
that most people have some idea
about how disks are formatted and
used, but some misconceptions
abound about a few simple but im-
portant concepts. What must be kept
in mind when dealing with dissimilar
formats are the software and har-
dware parameters. The hardware
part is how your computer's disk
controller formats, writes, and reads
disks. The software part is the
tricking of hardware to read or write
unusual formats.
Let's review things by looking at
standard eight inch disks, using the
single density format called IBM
3740. This single density
arrangement was established way
back in the beginning and is the only
true standard of any disk format.
The disk has 26 sectors of 128 bytes of
data and plenty of overhead infor-
mation. It is this overhead infor-
mation that can cause some trouble
with varied formats. The disk con-
troller will check the "ID marks" (a
part of the overhead) to find out if it
is on the right track, and then find
the correct sector. Other infor-
mation in the ID is the sector size
(00=80h, 01=100h bytes) and a CRC
flag. A good way to see what a
proper disk format is, is to do a full
track read. I have supplied a simple
listing that will allow the SDSystems
Versa Floppy II to read a full track
(read the comments and change for
other systems). My procedure is to
use SID (or DDT) and clear memory
to A(XX)h and assemble the listing at
9000h. This allows you to exit SID,
change tracks or whatever, and
return to SID to reread a new track.
Now that you have seen a full
track, what do you look for if this is a
disk you have been unable to read? I
look first for the order of sectors, are
they in sequence or skewed?
Skewing is done to get more sectors
read during each rotation of the disk.
Disk read time is not fast enough to
read one sector after the other. The
delay needed to change pointers and
set registers for the next read, is
usually enough that a skew of six
(skipping five sectors and reading
the sixth) works fine. This is part of
the standard and will be handled in
most BIOSs. Some systems however
do it during formatting and will need
the BIOS's skew turned off.
This is actually one of the points of
this whole discussion, as most people
have trouble understanding the dif-
ferences. Looking at a directory
track might help. A non-skewed
system (no skewing of any kind)
would have the sectors numbered in
order and the directory sectors
would correspond with the sector
numbers. A standard disk would
have the sector numbers in order but
the second directory sector would
not be found in sector number two
but in sector numl)er seven. A hard
skewed track would find sector
number two in the seventh sector
from the beginning location. The
standard system will use a skew
table and the hard skew will not.
What most people have problems
with is how the system performs this
operation. The operating system will
ask for a logical sector number. The
BIOS will change (or not) the sector
number into the skewed value (2
becomes a 7 in standard systems).
This value is then stuffed into the
disk controller sector register and
used to find the actual sector. You
must remember that it is you that
tells the controller which sector to
get and it reads the ID mark to find
that sector. A common misunder-
standing is the use of the index hole.
Some early systems counted sectors
starting at the index hole and the
recorded sector number was unused.
Most new disk controller chips
however use the formatted sector ID
mark to find the proper sector.
It is my understanding that on
most new systems you will find the
index hole used only for full track
reads and writes. Some chips like the
NEC 765 also provide their own for-
mat options. The WD179X series
uses a full track write for formatting
(you supply the data string). The
most common use for the Index
timing mark is to check disk size
(five and eight inch timing is dif-
ferent) and for disk status (ready)
condition.
We can conclude this discussion by
reviewing how to copy or use a dif-
ferent formatted disk. First is to do a
full track read through a hand
assembled program or your
system's monitor. This wUl give you
the sector size, skewing information,
and density (single or double). For
double sided drives you will need to
check the track order as some
systems go from side to side (all odd
number tracks on one side of the
disk) while others fill one side before
going to the other side (the ID mark
tells which side, hopefully). The next
operation is to use the listing of your
BIOS (the PRN fUe) and find the
disk's DPBA table (can be found by
using DDT if you know what to look
for). This table has the address for
the DPB (parameter blocks which
tell the system block size, number,
etc.) and the XLT (translation table
for skewing). For no skew systems
the XLT can have all zeros, for
others it will point to a table of skew
values. The translation program
steps through the table based on the
logical skew number. The value in
the table is then sent to the disk con-
troller. Patching \i\e table with DDT
will work for different skews.
Many little things must be kept in
mind however. Your BIOS must
support double density or larger
blocks, to be able to read double den-
sity disks. If the number of sectors or
blocks is different than before, new
values will be needed in the DPB.
Systems can have a different num-
ber of system tracks and the offset in
the DPB must match. Side differen-
ces will need to be checked as
system programmers do it differen-
tly.
