The Computer Journal Issue 76

fng Support Around The Worid

"-^ »--:.-

^*5-

*<-

imte Number 76

lS8»t#a748-g331

The
Computer
Journal

November/December 1995

Alternatives to the XT

Small System Support

PC/XT Corner

The European Beat

Real Computing
PC Security System

Dr. S-100

PC Time Clock

Floppy Disk Problems

Centerfold - Jade Bus Probe

The Computer Corner

USS4.00

4

M
-^

J

"3

I

5

■f %

TCJ - For Having Fun With Old Computers!

-4

-rS,

Cross-Assemblers «$ low as $50 oo

ojrnuidtors as low as $100.00

Cross-Disassemblers as low a 10000

Developer Packages

as low as $200.00(a $50.00 Savings)

A New Project
Ctar Wm of macro Cross-assemblers are easy to use and full featured,
-Inahini^ conditional assembly and unlimited include files.

Get It To Market-FAST
Qpal wait until the hardware is finished to debug your software. Our
SMMlators can test your program logic before the hardware is built.

No Sourcel

AlfiinQr glHch has shown up in the firmware, and you cant find the original
•ewM program. Our line of disassemblers can help you re-create the
MtgyiMl mambly language source.

Set To Go

Sby ow daveioper package and the next time your boss says 'Get to work.",
yeuH ba raady for anything.

Quality Solutions

PaaodoCorp has been providing quality solutions for microprocessor
pnMams smca t985.

BROAD RANGE OF SUPPORT

•■ Currently wa support the following microprocessor families (with
mora in davatopmant):
ia048 ' RCA 1802,05

ila6800 Motorola ^1
[6301 Motorola 6809

. tfl65C02 Intal8080,85

Htoehi H064180 Motorola 68000,8

a AH products require an IBM PC or compatible.

So What Are You Waiting For? Call us:

PseudoCorp

Pro/essiemal Development Products Group

921 Countty Club Roa4 Suhe 200

Eugene, OR 97401

0Sm <83-9173 FAX: (503) 683-9186 BBS: (503) 683-9076

Intel 8051 Intel 8096

Motorola 68HC1 1 l^torola 6805
MOS Tech 6502 WDC65C02
ZlogZSO NSC 800

Motorola 68010 Intel 80C196

Journey with us to discover the shortest path between
programming problems and efficient solutions.

The Forth programming language is a model of simplicity:
In about 16K, itcanoffera complete develcHJmentsystem in terms
ofcompiler,editor,andassembler,aswellasaninterpretivemode
to enhance debugging, profiling, and tracing.

As an "(^en" language. Forth lets you build new control-flow
structures,and other compiler-oriented extensions thatclosed
languages do not

Fo'th IXmensions is the magazine to help you along this
journey. Itis one of the benefits you receive as a member of the
non-profit Forth Interest Group (FIG). Local chapters, the
GEnie™ForthRoundTable,andannualFORMLconferencesare
also supported by FIG.Toreceiveamail-ordercatalogofForth
literature and disks, call 510-89-FORTH orwrite to:
Forth Interest Group, P.O. Box 2154, Oakland, CA 94621.
Membership dues begin at $40 for the U.S A and Canada.
Student rates begin at $18 (with valid student I.D.).

CEnie is a trademark of General Electric.

=^

ff; _ ^ ;.,

Mibler Electronics

Serving the

Industrial Electronics Community

since 1978

Specializing In

Hardware Design and

Software Programming

Previous Projects include:

PLC ladder programming (15,000 lines)

8031 Remote I/O using MODBUS

680S Instrumentation Controller

68000 Real Time Embedded Operations

NETBIOS programming and Debugging

Forth Projects and Development

HTML Design and programming

Articles, Training, and Documentation

Bill Kibler

Kibler Electronics

P.O. Box 535

Lincoln, CA 95648-0535

(916) 645-1670

e'tnail: kibler@psyber.com
http://yvyvw.psyber.com/-'kibler

SAGE MICROSYSTEMS EAST

Selling and Supporting the Best in 8-Blt Software

Z3PLUS or NZCOM (now only $20 each)
ZSDOS/ZDDOS date stamping BDOS ($30)

ZCPR34 source code ($15)

BackGrounder-ii ($20)

ZMATE text editor ($20)

BOS for Z-system (only $30)

DSD: Dynamic Screen Debugger ($50)

4D0S "zsystem" for MSDOS ($65)

ZMAC macro-assembler ($45 wHh printed manual)

Kaypro DSDD and MSDOS 360K FORMATS ONLY

Order by phone, mall, or modem and use
Check, VISA, or MasterCard. Please Include
$3.00 shipping and Handling for each order.

Sage Microsystems East

1435 Centre street
Newton Centre MA 02159-2469

(617) 965-3552 (voice 7PM to 11PM)
(617) 965-7259 BBS

The Computer Journal

Founder

Art Carison

Editor/Publisher

Bill D. Kibler
Dave Baldwin

Technical Consultant

Chris McEwen

Contributing Editors

Herb Johnson

Charies Stafford

Brad Rodriguez

Ronald W. Anderson

Helmut Jungkunz

Ron Mitchell
Frank Sergeant

JW Weaver

Richard Rodman

Jay Sage

Tilmann Reh

The Computer Journal Is pub-
lished six times a year and mailed
from The Computer Journal, P. O.
Box 3900, Citrus Heights, CA 95611,
(916) 722-4970.

Opinions expressed in The Com-
puter Journal are those of the re-
spective authors and do not neces-
sarily reflect those of the editorial
staff or publisher.

Entire contents copyright © 1995
by The Computer Journal and re-
spective authors. All rights reserved.
Reproduction in any form prohibited
vwthout express written permission of
the publisher.

Subscription rates within the
US: $24 one year (6 issues), $44
two years (12 issues). Send sub-
scription, renewals, address
changes, or advertising inquires to:
The Computer Journal, P.O. Box
3900, Citrus Heights, CA 95611.

TCJ

The Computer Journal

Issue Number 76 November/December 1995

Registered Trademarks

It is easy to get in the habit of using company
trademartcs as generic tenns, but these trademarks are
the property of the respective companies. It is important
to acknowledge these trademari(s as their property to
avoid their losing the rights and the term becoming put>-
lic property. The following frequently used trademarics
are acknowledged, and we apologize for any we have
overiooked.

Apple II, II+, lie. He, Lisa, Macintosh, ProDos;
Apple Computer Company CP/M, DDT, ASM, STAT,
PIP; Digital Research DateStamper, BackGrounder ii,
Dos Disk; Plu'Perfect Systems Clipper, Nantucket;
Nantucket, Inc. dBase, dBASE II, dBASE III, dBASE III
Plus, dBASE IV; Ashton-Tate, Inc. MBASIC, MS-DOS,
Windows, Word; Microsoft WordStar; MicroPro Inter-
national. IBM-PC, XT, and AT, PC-DOS; IBM Corpora-
tion. Z80, Z280; Zilog Corporation Turbo Pascal, Turtx)
C, Paradox; Boriand Intemational, HD64180; Hitachi
America, Ltd. SB180; Micromint, Inc.

Where these and other terms are used in The
Computer Journal, they are acknovi^edged to be the
property of tfm respective companies even if not specifi-
cally acknowledged in each occurrence

Editor's Comments 2

Reader to Reader 3

Real Computing 7

MINIX and more.
By Rick Rodman.

PC/XT Corner 10

Article by Kirk Lawrence,"Super-Charge that old XT!..
By Frank Sergeant.

The European Beat 15

10 years of support.
By Helmut Jungkunz.

Alternatives to the XT 18

Options and the PT68K-4.
By Bill Kibler.

Dr. S-100 22

GIDE and Jade Bus Probe.
By Herb Johnson.

Center Fold 25

Jade BUS Probe.

PC Time Clock 29

Improving Accuracy.
By Terry Hazen.

PC Security System 30

House security system in BASIC.
By Michael Krabach.

Small System Support 36

C and assembly language tutorial.
By Ronald W. Anderson.

Floppy Disk Problems 41

Trouble shooting floppy design problems.
By Claude Palm.

Support Groups for the Classics 46

The Computer Comer 50

By Bill Kibler.

EDITOR'S COMMENTS

Well here is issue 76 and my last as
editor. Dave is almost stepping on my
heals, tiying to get a start at producing
the next issue for you. He comments
later on this page. Have no fear number
76 is good as usual and I am sure num-
ber 77 will be too, I know I will help
make sure that comes true.

This issue is support of XT and PC sys-
tems and beyond. After letters to the
editor, comes Rick Rodman with MINfIX
is alive and well? Can this be true, read
and see for yourself.

Frank Sergeant has comments on XT/
PC's and a Uttle insert by Kirk Lawerance
on supercharging XT's. Helmut
Jungkunz is next with his report on 10
years of Amstrad support through their
User Group. I follow with my shortened
but interesting article on Alternatives to
using XT/PCs. Herb Johnson gives his
long awaited discussion of the Jade Bus
Probe. I follow that with the schematics
in the centerfold.

Using XT or AT's for guarding your
house is next. Michael Krabach sent me
this article some time ago and I have
been trying to fit it in, so here it is now.
Remember the entire code is on the TCJ
BBS and home page. For those still learn-
ing assembly or C, Ronald Anderson
keeps trying to make us experts, well at
least able to program in those languages.
Speaking of trying, Claude Palm sent
me an article in hard copy which I fi-
nally got into computer form for you to
read. It explains what can happen in
designing systems.

Lastly is my column. The Computer
Comer, where you will be seeing my
words for many more issues to come. I
don't plan to do any big articles right
away, as I know I will be helping Dave
get up to speed on producing the next
few issues. So what does he have
planned?

Dave's own words

Here we go again. The Computer Jour-
nal has a new editor, so the first question
is 'Are there going to be changes?'. Of
course there are. Big changes? Probably
not. I'm going to 'play' around with the
format aivd I'm talking to a couple of
new people about becoming authors. We
now has a BBS and a fax number and the
Web page is attracting a lot of attention
on the Internet. I've been updating the
TCJ files and messages on Genie and
posting some of the info files on
CompuServe.

Of course, our current writers will still
be here and some new ones. David
McGlone of the Z-Letter has agreed to
write an article about his experiences
tiying to get CP/M software and some-
one (I don't know who yet) is going to
write a CP/M and Z-System column.
Another regular item I'm going to try to
get going is a 'Program This Chip' ar-
ticle series. I'm going to do one on the
Z80 SIO which seems to give people fits.

I'm going to have as much fun as I can
with TCJ. I'm going to try out some
little changes here and there and see who
notices. It's also going to be an 'educa-
tional' experience. Bill says that in six
months or so, I'll have found out what I
should have known to start with. What's
Bill going to do? He's going to continue
to write the Computer Comer and be the
rC/Technical Consultant. He lives right
up the road fi^om me and I have his home
and work phone numbers, just in case.

Well, what's the 'new' TCJ going to be
like? A lot like the 'old' one. I'll quote
from our Web page on the Internet
<"http://www.psyber.coni/~tcj/"> (which
I wrote):

The Computer Journal has articles and
reviews on both new and old hardware
and software. In the last year, there have
been articles on most of the popular

microcontrollers, reviews of a new Z 180
system for CP/M, modifications for older
systems, software articles and tutorials
on Forth, 'C, and assembly language,
and the 'Centerfold' schematics for older
computer circuits.

In general, we cover hardware and soft-
ware that one person can work with,
where you can 'do it yourself. This
means boards and systems where you
can identify (and get) the parts and get
code to make it work. In particular, this
means the Kaypro, S-IOO boards, Z80/
180/280 and CP/M systems,
miCTOcontroUers like the 8048, 8051,
and 68HC1 1, and software articles that
include source code. This is also why
we started covering the PC-XT clones
made with identifiable TTL parts. BIOS
code is also available for them now so
you can make them do what you want.

On the other hand, if a project or system
requires an engineering team or access
to custom IC's, you probably won't read
about it in TCJ. The exception to that is
when our authors and/or readers get
together for a project and can provide all
the necessary resources.

TCJ is subscriber supported rather than
advertiser supported. Your suggestions,
requests, and complaints are listened to
and acted on when we can. You have
my name, number, address, email ad-
dress, BBS number, fax number. If you
never suggest, request, or complain, I'm
going to assume you either love what
I'm doing or you're not paying atten-
tion.

Thanks Dave and BYE! Bill Kibler.

(800) 424-8825 or (916) 722-1970

Email: tcj@psyber.com

BBS: (916) 722-5799

FAX: (916) 722-7480

Dave Baldwin: dibald@netcom.com

Bill Kibler: kibier@psyber.com

Home page "http://www.psyber.com/~tcj"

The Computer Journal / #76

READER to READER

Letters to the Editor

All Readers

MINI Articles

Dear Bill:

I have never had any kind of EPROM
programmer, so a nimiber of projects
have been started but not completed. This
simmier I was about to begin again, start-
ing to build a Motorola 680S design-kit
that copied an EPROM into internal
memory. I have been plaiming to build a
programmer by myself using switches
on the address bus and data buses, with
a binary and HEX display for both data
and address using HP Hex di^lays from
Hosfelt and blue disaete LEDs, but
made my decision to buy Needham's
Programmer and clean house for as I
said, I have stacked up a number of
projects and the price was only a little
more than Motorola's Design Kit. Sorry
Motorola, but maybe if your Kit came as
a bare board with ICs 1 might have sprimg
for it, and still might as money becomes
available. Fortunately, I have been ach-
ing to make some sort of IBM Front
Panel with LEDs and switches, so the
planned Eprom Programmer parts list
was easily changed into a new project.
There is no soldering to do with
Needham's PB-10, it is complete with
5.25" 1.2M floppy.

What Comes With The PB-10?

The PB-10 is an 8-bit ISA card to plug
inside the computer, with a ribbon
cableCsui^lied) that leads out the back of
the computer to your Programming
Socket that you get to mount where you
want, the cable is about long enough.
Mounting tape for the socket is supplied,
and it holds the socket well but can be
moved if need be. A 5.25" 1.2M dis-
kette holds the "EMP" program for the
PB-10: the same software they use with
their other programmer, the more ex-
pensive stand-alone.

First, a person ought to back up their
new diskette. I think DISKCOPY is the
easiest way to do that. Then INSTALL
the program on your HardDisk, mine is
on C: and I had no problem I suppose it
could be INSTALLed to a 360k diskette
in the same way, for smaller computers.
I had wanted to install the whole thing
in my XT(XtraTiity) Magnum until I
found out the PB-10 can handle Big
Eproms on the order of 27010, 27020
and 27040. Being able to program these
big EPROMs made the decision to put
the card into my x486 with 8M clear:
that's where it is now. The Magnum
will continue to serve as my test bed for
plug-in home brew projects.

Some EPROMs and the 8748 and the
8752 types are programmed with the
purchase of an adapter. Not inunediately
possible, but not impossible. I'd like to
build a kit to do those devices, but that
isn't how its done. Just soldering one
socket and one plug on a tiny pcboard
sounds like fim. Volunteers to design
adapter kits? Another difficulty lies in
the big EPROMs, the 27040 needs qx-
cial code modifications to the EMP pro-
gram, they must supply it with the adapter
I bet.

That's all I have for the PB-10 Program-
mer by Needham'sfor only $139.95 from
Digi-Key. What have I done with it? I
have unplugged the 2764 EPROMs from
the Magnum, the only ROM inside, and
read it into the buffer then saved the
buffer to a flle and begun to debug it to
leam how a computer boots. I have re-
loaded the flle to the buffer and pro-
grammed a blank 2764 which I've
plugged back into the Magnum and it
works, testing the whole thing from read
to program. I can easily buy 2764s by the
tube of 13 in Portland, and this was one

way to test what I did with it. The Mag-
num booted, the Eprom passed the test.
This is a woik in progress.
Regards,Marshall Montchalin <Obi-
wan@habit.com>

Dear Bill:

I bought a ten-key computer keyboard
from St Vincent's for only $2 and since
it's connector wasn't standard, I pulled
out my Philip' and opened it up. I found
a proto-pack with a 2716 plugged in!

ff the keyboard works, it could be a good
protopack to desolder for other purposes
or it could be a keyboard. Having the
memory already wired for you adds a
degree of confidence and ease to any
project.

Mostek Mk 38P73/D2 D

What is it? (and I want to program it and
use it, ha-ha; I saw them introduce the
F8 back in the beginning at The Jantzen
Beach Red Lion Thundeibird and fell in
love with the Proto-Pack version they
showed flash LEDs or something. It was
also at the WesCon in Las Vegas.) The
keyboard was factory dated August 1983
but my most recent Fairchild catalog is
January of 1978. So it's an F8 between
an F3872 and an F3874 in the
MicroMachine Series shown in my cata-
log.

I read the F3870 is 2k ROM, F38E70 2k
PROM, the F3872 is 3k ROM/64 bytes
RAM, the F3874 is 4k ROM.

Therefore the 38P73 must be 3.5k I
wonder : A close inspection of the
ProtoPak reveals the holes for more ma-
chine-pin sock^ pins above the 2716
plugged into it, as if bigger JEDEC 28-
pin memories could be plugged in com-

The Computer Journal / #76

patibly, had there been four more pins
installed, making it easy for the foimdiy
to add/subtract features offered, and save
them money on one style of ceramic.
Surely I am dreaming, but maybe they
added their options when soldering pins
to the dip. What other F8 ProtoPaks did
they make?

So here I am, staring at this technologi-
cal marvel. If it works, I could just hook
it up to the S^ or my 486 and not
desolder any protopack. Until I find the
right books...

Right now its untested, untraced. Got
any good stories to tell about Mostek or
Fairchild? Why didn't their style cpu
make the big time? I'd bet there's a few
good tales to hear. In this catalog
Fairchikl has both the F8 and 6800 Usted.
Now, that doesn't sound right, does it?

All for now, Marshall

Thcnks for both messages Marshall. Well
it sound like you are about to have plenty
of fan learning to use your new pro-
grammer. I have been using Needhams
for many years and since they are just
across town from us (and past advertis-
ers) we hope to see them back in TCJ
pages soon.

The F8 never really took off and I think
Fairchild was Just a secondary chip pro-
ducer in the case of the 6800. Motorola
had plenty of agreements with other
makers, that way people would use the
chip knowing the could buy it from more
than one source.

The chip carrier idea never caught on.
The idea allowed you to prototype an
actual system using a separate ROM
that later would be burned into the single
chip. I think this was before EPROMs
where built into CPU's, or at least when
those chips were $100 in price and the
F8 and EPROM could be had for less
than $30. The idea died of course as
soon as the other chips came down in
price.

Well that is all I know about those items,
but if you learn more, we would love to
have some articles telling more about
them old days... Bill.

Dear Editor,

I am looking for the following Fairchild

books (original or photocopied).

F8 User's Guide

F8 Microprocessor Family Data book

F8 Guide to Programming

FairBUG User's Guide

OCM-1 User's Manual

I mgently need then to repair and re-
forming of U.S. made microprocessor
controlled radio sets. Unfortunately F8
family itself and F3850 family ICs were
used very rare here in Japan, so these
books are absolutely unobtainable at
present. To my siuprise that the library
of Diet of Japan has no information on
those titles.

1 also looking for some ICs, F3850
(MK3850), F3853 (MK3853), 11C90
and uA757, If you have any information
on above items would you please advise
me where can I purchase them?

Looking further to hearing from you.
Sincerely, Kato Higuchi,
1-16-8 Minami-Senzoku,
Ota-ku, Toyoko 145, Japan

Well Kato, sorry your note to me fell so
far down in the pile that I only found it
now. If you have internet access you
might try contacting Marshall above, it
seems you both have things in common.
I remember now that MK stands for
Mostek and I am not sure but think that
Mostek designed the F8, but it could be
the other way around.

Any other readers out there who can
help Kato and Marshall get straight on
what these chips do.? How about the
documentation? Thanksfor writing Kato.
Bill

TCJ: Your advertisement came to my
attention. Your magazine appears to be
potentially helpful to me in maintaining
my PC/XT computer system.

I am presently trying to add 3 3.5" floppy
drive with PC-DOS 3.2 to help me to
format 3.5" diskettes to 720K. For some
unknown reason, I either get a 360K
format or an error message.

Very truly yours, Keith E. Watkins,
Schenectady, NY.

Well Keith, I see you need a little help
understanding the drive arrangement
with PC 's. First off you might want to
buy one of the XT-AT Handbooks sold
by Annabooks (800)462-1042. They run
about $9 and are often given away at
conventions. On page 86 of mine is tables
of floppy disk formats. I see that they
were first supported by DOS 3. 2, earlier
DOS's would not handle anything other
than 360K drives.

The table also says you need to use the
/F:720 as part of the format command
line. The DRIVER.SYS switch is/F:2 as
in add this line to your CONFIG.SYS
file "DEVICE=\dos\DRIVER.SYS /D:l
/F:2 " and you should then be able to
properly access the drives. You will get
a message that tells you which drive
letter to use for the new drive. The drive
is defined by the /D:l, 1 being the sec-
ond physical drive or B:. The drive gets
redefined so to speak, to talk both the
new disk parameters and the old ones.
By that I mean, put a floppy in the B:
drive and format it format B:), it will be
360K. Reformat it now as the new drive
(the prompt displayed a "D") (format
d:) and it will be 720K.

Any DOS manual, from 3. 2 on will have
a section on CONFIG.SYS parameters
and explain the above again with more
samples. I think in version 3.2 config
came into existence. Before 3. 2 you were
pretty much stuck with BIOS defined
drive support. After 3.2 you could then
reassign, create logical drives, add
ramdisks, and many other functions
through the config.sys options.

So thanksfor asking Keith and hope you
get a better start on upgrading your
system. Bill.

To: TCJ: Enclosed is my check for a 2
year subscription. I've been looking for
a source like this for data on the PC/
XT's for a long time. My current project
is a SCSI device for ATE work working
with DTC 3250C controller, if it works
out I'll try to cobble up a decent article
for publication.

The Computer Journal / #76

Disregarding my 486 for the moment, I
am using a LASER XTSL, NEC V30,
8087, 640K, and an INTEL ABOVE
BOARD. I discovered the motheitoard
had some built in options that I have
enabled, also it has DIP locations for
what appears to be 2 MEG of Expanded
Memory, if I can get my hand on the
necessary driver software.

With your PC/XT owner's readership,
have you accumulated any kind of data-
base on the configurations and options
of versions of the PC/XT and clones,
I'm interested in sources for hardware
and software and possibly correspond-
ing with fellow owner's of the LASER
series. Are there any plans for a BBS in
the future.

I program in Qbasic and MASM, I'm
working on C on my way to C++, I'm
interested mostly in hardware, I've got a
MOD-EMUP programmer and I love to
tinker if I can help anybody out please
drop me a line.

Thomas Rumpf, 1st Floor,
1621 W. South St.
Allentown, PA 18102.

Thanks Thomas for your renewal and
offer to write em article. Well we cer-
tainly could use more hands on informa-
tion on SCSI as it pertains to PC/XTs. A
friend Just dropped by asking about his
SCSI problem. Seems all his software is
set up for certain drives and he just went
to IDE drive from MFM. All is fine until
he puts the SCSI drive in to. Then the
drive letters get all out of whack and his
software will not work.

I told him how most BIOS code checks
for drives, then checks for logical drives.
That means if you have only one drive
and set it up as three, they will be C, D,
E. Add a second physical drive and it
will become D, pushing the two old drives
out to E and F. I remember coming
across this problem and using Disk
Manager to load drivers that swapped
drives around to be in proper order.

Now in your case, it sounds like you
need to just add HIMEM to your
config.sysfile. High memory is suppose
to be the drivers to use the expanded or

extended memory in your motherboard.
That assumes that it was built using one
of the memory management standards
which the software knows about. If it
doesn 't follow the standards, then we
need to find other LASER users for you.
But try the HIMEM switches, you will
find them explained in any DOS manual.
If I remember right LASER is also called
Acer machines and

"DEVICE=HIMEM.SYS /

machine. acer 1100 ... " might work.

We are interested in getting resource
listings and group support indexes setup,
but for now, we do it mostly on the TCJ
BBS or WEB pages. Just stop by either
and we will try and get you in contact
with other users. Since both resources
are new to TCJ, it may take some time to
get more readers corresponding by these
methods. So thanks and keep watching
TCJ pages for more XT support. Bill.

Dear Chuck,

I recently purchased a KAYPRO II com-
puter (sometimes referred to as Darth
Vader's lunch box). I think it is probably
the original "portable" or laptop version
of computers. Anyway what I need is a
source for the software which brings the
beast to life. The manual indicates that
it originally came with a package of 10
diskettes but the only one I really need is
the basic one which brings it to life and
makes it ready to receive other software.
I think this same disk probably holds the
utility software for the system. I am quite
siue the machine operates basicalfy in
CP/M. I already have a ftill set of soft-
ware formatted for the HP 125. How-
ever, I am told that Kaypro software was
very proprietary and will only operate
on the one system for which it was de-
signed. If I can obtain the software I'll
try and have fun with the beast, other-
wise I guess it needs to go to a museimi
or be converted to a very large paper
weight.

Thanks in advance for any assistance
you may be able to provide.

Sincerely, Jerry D. McAtee, Rapid City,
SD.

Well thanks for this letter Jerry, and
hopefully Chuck has helped you out by

now. For our readers, you are a typical
inquiry that we get here at TCJ. First off
Kaypro were not the first lunch boxes
made, I think Osbomes get that honor.
The Kaypro was certainly a very popu-
lar system and they were made for a
very long time. You will see them often
and there are several places to get soft-
ware for them. I usually send people to
Lambda Software in Oregon, his num-
ber is on the back page.

On operating systems, CP/M is NOT
proprietary in any real sense. Kaypro 's
use CP/M, considered the first PC Op-
erating system and mother to PCDOS.
What makes systems non-compatible is
how they talked to keyboards and video
screens. CP/M has the BIOS being part
of the operating system and is loaded
from the boot disk. Later PC/XT ma-
chines, separated out the BIOS, placing
it on the motherboard in ROM. Unlike
CP/M where you must boot from a disk
set up by the manufacturer of the ma-
chine (to get the correct BIOS code),
PCDOS knows nothing of hardware,
other than where and how to call rou-
tines in the ROM BIOS that DOES know
about the hardware.

Another problem was early vendors
could not decided on a standard disk
format. Each company found a way to
setup their disk and ideally give them
some advantage over the competition.
The opposite happened, people just went
to the PC/XT when they came out, since
IBM set standards. You can get for your
"BOX" a program that can read many
different disk formats. That way can copy
programs from your HP 125 to Kaypro
disks and use them.

Using the Kaypro should be fun, once
you get past that initial learning curve.
Later you might even want to consider
ZCPR, which can give you features still
not found in some version of PCDOS.

Thanks for the request Jerry. Bill.

From: PhilMarkDavis@medio.net
Mr. Kibler:

Up here in Seattle, we have been very
pleased to be able to receive and read the
publication rC/. Our group is PNHUG
(Pacific Northwest Heath Users' Group).

The Computer Journal / #76

And now you've made eveiything even
better with the new web page and yoxir
new e-mail address. The page is simply
great and with so much reference infor-
mation plus even a reference to our little
group, as is in the magazine. The
Tilmann Reh e-mail address in Germany
is new to me also. We're all interested
in the IDE expansion project We would
be most ha;^ if it all fit in, as a pack-
age, to the old Z-100 Heath/Zenith Com-
puter. Maybe someday?

May I request an update to ova PNHUG
entry? You have our secretary-treasures
old address which was P.O. Box 12214.
He has a new one which is as follows:
Jim Nfoore,

1554 - 16th Avenue East,
SeatUe, WA 98112-2807
e-mail: be483@scn.org

If you wish to publish, the other officers

can be reached as follows:

Phil Marie Davis (Co-President),

3250 Portage Bay Place East,

SeatUe, WA 98102-3893

e-mail: PhilMarkDavis@medio.net

Don Viele, Vice-President & BBS Sysq),
2732 S.W. 312th Place,
Federal Way, WA 98023-7811
e-mail: DonV820047@aol.com

Our BBS probably contains the now larg-
est collection of PD and Shareware for
the Heath/Zenith Z-100 computer.
Nearly 15 MB! We have just started a
long range project, in which several of
the members, are going to organize a
good collection of CP/M software and
try to produce a CD-ROM of same. This
may turn out to be only for our edifica-
tion or may grow in other directions.
This is a collaboration of one member
who is the sys<^ of one of the oldest CP/
M boards in the Seattle area, Mr. Ludovic
Van Hemeliyck of "Adam's RiBBS".
The telephone number of his BBS is
(206)481-1371 and that of PNHUG is
(206)860-8472. It is our desire to even-
tually establish a web page and possibly
a telnet link to oiu- BBS. We are some
way from this point at this time. Please
feel free to publish any or all of the
above information.

Thanks again for the great job and the

reminder to renew. Will use your 800
number at the earliest time.

Sincerely,

Phil Mark Davis (Co-President)

Thanks Phil for the update. I am now
going to work on a TCJ CD-ROM and
am looking for your type of material to
include. I want to save forever BIOS and
Utility code for the older systems. I guess
since the Z-100 is no longer supported,
I wonder about problems publishing it 's
BIOS source code, got any ideas about
that. I have Helmut's AMSTRAD pro-
grams and tons of old 8 inch CP/M disks
to go through, but hope to have some-
thing by Spring of next year. Maybe we
should work together? Thanks. Bill.

From: schang@huey.csim.edu
Subject: PC/XT: How to read ROM
BIOS FDD info?

Hello! Just ran into your article about
$10 PC/XT in the hopes of getting info
on how to read FDD type info from XT's
ROMBIOS. I've gotMCT BIOS (c)1985
E.S. Oneal (whatever that means, at-
tached on the BIOS chip). I tried Alt-
Ctrl-S, Alt-Ctrl-Ins, and few other keys
at random, including <Del> by itself,
<F1>, etc. No luck so far. Is there any
way to view that info? I picked up a
486DLC board a couple days ago, put in
the old MFM HDD control card. The
HD is about 20 MB big, but can't figure
out the type info like # heads, # cylin-
ders, # sectors, #LZone, etc.

I hope you can help me. Thanks! SS

OK SS, here is the information, get one
of the Annabooks XT-AT Handbooks,
making sure it has the list of hard drives.
They cost about $9, but watch out for
the free ones, they do not have the fill
drive tables. There is also a hard drive
information text file on many BBS 's that
will most likely have your drive in it.

What you are trying to do by hitting
<DEL> during boot up, only works with
AT type machines that have a battery
backed up drive and other information
option. The XT's drive information is
fixed in the BIOS, although most MFM
controllers saved the information on the
hard drive itself and changing control-

lers often means reformatting the drive
and losing all the old data. Another
problem is the BIOS sounds like it was
modified or custom made and as such, I
have no idea what it may do for you.
IBM produced books on their machines,
which contained the source of their BIOS.
Look for these at swap meets, they are
great for knowing what goes on inside
the machines.

Look on the side of the hard drive at the
model number and then look that up in
hard drive table for values. If you can 't
find a book, e-mail me and I will look it
up. Thanks. Bill.

Subject: DEC Rainbow and other
From: fritz_chwolka@AC.CyberCity.de
(FRITZ CHWOLKA)
Hi....

I just got the last issue and it's fimny. As
you know I'm collecting old systems (not
real, I don't throw them away) and now
I get an DEC Rainbow with a segate
ST506. The system nm but I miss the
installation disk for the Harddisk. I've
some other ST506 and want to test them
for replacing the original if it's neces-
sary.

So I need information, software etc. for
the Rainbow. Another problem are my
Zilog Systems MCZ-10/15. I've got the
Zilog- system disks for them (Hard sec-
tored) but no CP/M disk. The manuals
are complete. I've a nice Zilog MCZ 1/
05 , a multiuser system but without some
boot disks it wont run. Maybe there in
US is someone who can help. I need all
about the MCZ- 1/05 because I've noth-
ing for it.

I've a NASCOM Computer. This is a
german product an sold in similar ways.
As a complete system or a kit. Never the
less I've got no system disks for it .
Maybe that someone has these disks and
can make a copy for me. So this are my
wishes and the other systems I have nm
well. Thanks for TCJ and it's a nice
picture on page 51.

Greetings from Germany. .Fritz Chwolka
/ collecting old computers just for fun.

Contact Rick Rodman, Thanks. Bill.

The Computer Journal / #76

Real Computing

By Rick Rodman

32-Bit Systems
All Readers
Rick Moved

Minix is Back

The immediate question is, is Minix 1.7
a contender? I think so. Although it's
acquired lots of new features and lots
more utilities, it's still fairly simple at its
core. For the intrepid Real Programmer
who wants to understand what's under
the hood, Minix 1.7 is definitely worth
considering.

I loaded the Minix-86 1.7 beta on an
ISA-bus 386SX machine with 2MB of
RAM and an 80MB MFM hard drive.
Notice that I used the "86" version.
Minix 1.7 comes in an "86" version, for
8088s and 286s, and a "386" version for
the bigger chips. I'm more interested in
the "86" version, because it's smaller
and simpler.

Minix 1.7 includes a driver for an
Adaptec 154x SCSI host adapter, which
is expensive but common, and, more
significantly, TCP/IP networking. The
networking support is for SMCAVestem
Digital WD8003 or 8013 boards, which
are fairly common. If you've got a dif-
ferent board, well, you have all the source,
write your own driver.

Every software review has to discuss the
installation program, because that's one
of the most important parts of any pack-
age. Minix 1.7's installation program is
excellent You log in as "root" - no
"Geheim" any more - and type "instdist".
From then on, it's smooth sailing.

Especially nice is the new "part" parti-
tioning tool (compare to FDISK). Move
to the first line, over to the "size" col-
unm, and type "m". Then type "w" and
"q" and you're done with what used to
be a daunting task.

That's really about all you have to do,
besides putting in fiof^ies. A "vol"
program automates floppy changes. The
"instdist" script doesn't install the source
disks; you do that by entering just one
command (admittedly cryptic, but that's
Unix):

cd /utr ; vol 720 /dev/WO | uncompreu | tar xvfp -

Source to the whole OS and most of the
utilities is included. The old compiler is
no longer used. Now, the ANSI C com-
piler, which also conq)iles Pascal and
Modula-2 and used to be an extra-cost
item, is supplied. Everything is written
in ANSI C.

Other new things that are included in-
clude rz and sz (Zmodem), bawk, a new
shell called "ash", and the m4 macro
processor.

Glitches? Thus far in the beta, hard disk
controller incompatibilities and booting
seem to be the main problem areas. I
couldn't get it to work on a PS/2 model
60. Unlike 1.5, it doesn't ^pear pos-
sible to run a system from floppies and
RAM-disk alone. Of course, once you
have it ruiming on some machine, you
could generate a fl{q)py-only system or a
driver for any disk controller you hap-
pen to have.

KA9Q TCP/IP

I've gotten numerous inquiries regard-
ing using Tiny-TCP on various platforms,
usually PCs. Now you can certainly do
whatever you want with Tiny-TCP, but
as for me, I intend to keep it very small
and simple. For PCs, small and simple
is not the way people like to do things.

The definitive TCP/IP on PCs is a pack-
age written by Phil Kam and others called

by his call sign, KA9Q. Originally, this
was a fairly simple package not too much
bigger than Tiny-TCP, but it grew and
grew through the years as more and more
features accreted. Once iqwn a time, it
actually compiled and ran under CP/M.

Several versions of KA9Q came out over
the years. The oldest I have dates to
1 987. The version I will describe here is
fi-om the Simtel CD-ROM and is dated
June 1993.

Now, there are several ways to run TCP/
IP on a PC. One way is to Start Up
Windows 95. Another is to run Win-
dows NT, OS/2 Warp Connect, Linux,
or FreeBSD. If you have a Western
Digital ethemet card, you could run
Minix 1.7. You can also use Wolverine
TCP/IP with Windows for Workgroups,
or buy Chameleon, Acadia, Frontier,
LAN Workplace, or one of many other
fine Windows- and/or DOS-based TCP/
IP packages.

But if you want to run TCP/IP on a PC
for transferring files or Telnetting into
other computers, and don't feel like buy-
ing an entire convenience store just to
get a Twinkle, there's KA9Q.

So many people have asked me about it
that it must be one of the Deep Dark
Secrets of the PC World (like most free
and/or good things). I've tried it out and
it works just fine.

If you have the Simtel CD, you'll need
E920603.ZIP from the

\MSDOS\KAQTCPIP directory, and
DRIVERS.ZIP from the

\MSDOS\PKTDRVR directory. The
manual is in MAN_9106.ZIP in the
KAQTCPIP subdirectory. (If you don't
have the Simtel CD, but you do have a

The Computer Journal / #76

PC, go get it It isn't worth not having.)

Unzip E920603.ZIP to obtain NET.EXE.
The DRIVERS.ZIP is an archive of vari-
ous network card drivers. To use SLIP
or PPP on the serial port, you don't need
any of them. I used a 3Com 3C523
board in an IBM PS/2-60 (286 machine),
so I got 3C523.COM out of
DRIVERS.ZIP.

The 3C523 driver is what's called a
"Ciynwyr Packet Driver". It's a TSR,
like a Novell ODI driver. It sits in
memory, and you use a software inter-
rupt to talk to it. The software interrupt
must be selected between hex 60 and
hex 80. When you use this port from
KA9Q, you q)eciiy the same software
intemq>t, and you have a coimection.
All of the packet drivers use the same
method. Packet drivers are sometimes
even supplied by card manu&cturers with
their cards. I don't think this is purely
for KA9Q, however; I think some other
NOSs (network q>erating systems) use
this interface as well.

The following is how I run KA9Q with
3C523. The underlined text is what I
type:

c:\k.aq»?gsa gwW i 0K9W OkWW

c:\l«0q>ntt

nt>att«ch nackrt OxflO ethO 8 1500
nt>iteonfifl «thO UMMrtn 12fl 212.32 8
nt>iteon(iQ thO netmask 255,255.0.0

At this point I can telnet, ftp, ping, etc.
To leave NET running and run a DOS
program, the command "!" or "shell"
can be entered. However, NET won't be
able to do much while you 're doing some-
thing else.

The first line above is the command to
load the 3C523.COM packet driver, with
0x60 (hex 60 in C syntax) as its software
interrupt, 3 as its hardware IRQ, hex
300 as its I/O address, and segment COOO
as its memory address (OCOOOOH as seen
from the Reference Diskette). The sec-
ond line loads NET.EXE, which is re-
ferred to as the "NOS" in the documen-
tation. The third line specifies the host
name, AKA the machine's name; here
at KPCF machines are named for chemi-
cal elements. The fourth line attaches
the packet driver through the hex 60
software interrupt, calls it "ethO", and
specifies a transmit queue of 8 packets

with a maximum packet data size (MTU)
of 1500 bytes. The latter two parameters
are standard for Ethernet. The last two
lines specify the IP address and network
mask for the interface "ethO". By IP
addressing rules, every interface has to
have a different IP address.

By the way, we've talked a lot about
TCP/IP in Real Computing. The IP
addressing scheme is discussed in detail
in TCJ in I. Detailed information on
TCP, IP and FTP is also presented in
TCJs #64 and #66.

To nm a SLIP or PPP connection with
KA9Q, you don't need a packet driver,
because there is an async driver built in
to NET.EXE. Here's how you do that:

C:\KASOqiI

n«> ho«tn«m« zinc

n«l>«tt»ch ««Y 0«3Fa 4 llip iK) 1024 256 9600

rwOrtconfki HO loaMmt 192.9.201.2

neOifcontki HO nelmatk 2S5.2S5.2SS.0

The third line above is the configuration
of COMl, as you'll recognize from the
hex 3F8 I/O address and IRQ 4. The
next word, "slip", can be either "slip" or
"ppp", depending on what protocol you
want to use; "slO" is an arbitrary name
for the interface; 1024 is the buffer size,
256 the MTU, and 9600 the baud rate.

KA9Q is loaded with features, as it ought
to be considering that NET.EXE is al-
most 200K bytes in size. It supports
FTP either as cUent or server, telnet,
UDP, bootp and bootpd for dynamic
address assignment, and on and on. You
can put all the "net>" commands into a
file called AUTOEXEC.NET to save all
that mistake-prone typing every time you
run NET.

When some folks think about network-
ing, they immediately jump to mailing
drives. In the TCP/IP world, this is
usually done with NFS. KA9Q doesn't
include NFS. Neither does Windows
NT, for that matter. Neither does
TinyTCP... so you aren't going to be
able to see network drives on your
Osborne. If this is what you want, you'll
need to write an RSX of some kind. A
network redirector, which is what we
call the piece that makes the virtual drive,
is heavily OS-dependent and complicated
to write. Maybe someone will write one
for the Z-System.

Other folks think of the Worid Wide
Web. You'll need a Uttle more than
KA9Q or Tiny-TCP to get you on the
Web... but not much more. There are
text-only browsers, such as Lynx, with
which we may be able to cobble together
a CP/M or Minix Web browser.

On the other hand, suppose you want to
write a program to transfer data over the
TCP/IP network. The problem in the
DOS enviroimient is that there is no
standard socket library interface. How-
ever, all the source is there on the Simtel
CD. Take what you need and use it.

Building a LED panel for a PC

A TCJ reader named Marshall (AKA
obi-wan of the Internet) has started con-
struction of an LED panel along the
lines of what I talked about in TCI #70.
He writes: "The front panel should dis-
play the ports used to boot the computer
and the keyboard. The address bus could
latch on every fourth clock or some-
thing, with the data bus. I think it should
be binary, except the data bus should be
hex... That makes a long row of address
LEDs, 20+ and four hex data digits, 10
0-port switches and 10 1-port switches
for 20 total switches, 16 port-1 LEDs,
and 16 keyboard LEDs of two colors...
20 red address, 16 yellow, 16 blue, and
16 green LEDs would display well."
Sounds really great!

Marshall accesses the Internet from a
coffee shop in Portland, Oregon called
"The Cafe@Habit.Com". He supplied a
lot of interesting WWW addresses: http:/
/www.digikey.com, same with
marshall.com (no relation, I presimie),
cirrus.com, and cypress.com. Zilog has
a book ordering page on theirs at http:/
/www.zilog.com. Also, the following less
obvious addresses are from Motorola and
supply good information for hardware
experimenters:

http://freeware.aus.sps.mot.com
http://Design-Net.com

Many modem PC BIOSs write "POST
Codes" during boot up to an I/O port. I
don't know what the port is; in feet,
different manufacturers might use dif-
ferent ports. (Isn't it strange, everyone
making identical boxes, yet each fanati-

The Computer Journal / #76

cally guarding their identical secrets?)
For inter&ce debugging I think it'd be
nice to be able to set the I/O port to be
monitored by writing a port number to a
latch. The address or data busses could
be just two of many options.

Some PC manufacturers have recently
taken timid steps toward more visually
attractive machines, adding subtle curves
or slightly less bland colors to their
che^-looking plastic cases. Also, ac-
cessories are available for PCs such as
garishly-colored mouse pads and covers,
"screen fiames", and even horribly ugly
keyboards in childish motifs - ghastly,
but again with the same cheap plastic
look. And they wonder why these
changes make little difference.

Next time

Let's see, I was supposed to review
FreeBSD, but 1 ran out of space and

time. Oh, and Windows 95 came out.
TheviewatKPCF? Other than the new
user look & feel, it's just Windows for
Workgroups and DOS 6 shrink-wrapped
together. If you've got to use a Microsoft
OS, take a look at Windows NT instead.
It's a lot more stable, is really
multitasking, and if you can't Uve with-
out the new look & feel, you can get that
too. Windows 95 is mostly 16-bit code.
If you've got 32 bits, use 'em.

For more information

Real Computing BBS or Fax: +1 703
759 1169

E-mail: Changing! To Be Determined
Mail: 1 150 Kettle Pond Lane, Great Falls
VA 22066-1614

Walnut Creek CD-ROM (Manufacturer

- Simtel/CPM/LD^UX)

1547 Palos Verdes Mall Suite 260,

Walnut Creek CA 94596

+1 510 676 0783

'^LEVUX $49.95

Slaclovare Pro 2.3

Includes 4 CD-ROMs and a

450 page manual

A ready-to-run multitasking Unix clone

for 386 and higher PC compatibles.

TCP/IP, C, C-H-, X Window, complete

Source Code, and much more!

JUST COMPUTERS!
(800) 800-1648

Fax (707) 586-5606 Intl (707) 586-5600
P.O. Box 751414, Petaluma, CA 94975-1414

E-mail: sales@justcomp.com

Visa/MC/Infl Orders Gladly Accepted

For catalog, send e-mail to: infor@justcoinp.com

Include "^Ip" on a single line in the message.

V

Kettle Pond Computing Facility

Asorio/i5/iog5

DbU Fanlium-OO

PS/Z-P70

MBrm 7033 fax

IMS-BOOO
PS/2-50 UBS]

DEC Rainbow

]leriwB20-ll PS/Z-BO

"kernel ^^^^^^^^^„^^„..„,».«.-«^»«i

Lraraui-iniiaKi"'""'"!"""""'"""""''

,„„„.i„»nn« !«■" «'"

,liilllHHi!!ll1!lSllH8"»iil«l"""««"

Token Ring

NCR 3430

NCR 3450
dual^OB

Cubix 486 running
inloractivo Unb

NCR 3430

~E

]

'"«*'»«i

"*«>■■*,

PC-53Z

Scroungamastar

Panasonio

5DBR

optical juicaboK

Compaq
Systampro

Sun Sparostation I

The Computer Journal / #76

Regular Feature

Hardware Support

XT's and More

PC/XT Comer

By Frank Sergeant

Bank Switching on PCs

I thought I'd say a few more words abouf how PCs work. PCs
from the begirming have had a Byzantine memory addressing
system. It could be so simple! The actual address is just the
collection of Os and Is on the physical address bus. A PC or
XT has only 20 address lines. The 386/486/586, when in real
mode, only uses the first 20 address lines. This gives a
maximum plq^sical address range of 2'^20 = 1 MB (one mega-
byte). No matter how you slice it, 20-bits only let you address
within the first megabyte of RAM. This is where all our
troubles come from. Windows and DOS users get "out of
memory" errors whether they have 1 MB or 4 MB or 8 MB of
RAM. Without a great deal of trouble, the extra several
megabytes don't help at all because they cannot be accessed in
real mode. Further, less than 1 MB is available because the
upper 384K of it is used for various system ROMs and video
memory. Thus, programs must fit into the lower 640K of the
first 1 MB. This is where the infamous 640K DOS memory
barrier stems from.

This limitation is built into the architecture of the CPU. The
8088/8086 (and higher, when in real mode) only have 20 bits!
This is a damn shame, because the 20 bits come from a 16-bit
segment register and a 16-bit offset register. If one were the
upper half and the other the lower half of an address, you could
have a fiill 32-bits, giving an address range of 4 GB (gigabytes).
But no, Intel doesn't do it this way. To calculate the physical
address from a segment register and an offset register, the
segment register's value is multiplied by 16 and added to the
ofOset register's value. To determine how many locations can
be addressed, each address line counts as a power of two. Thus,
if you only had 3 address lines, you could address 2'^3 = 8
locations. So, here is how the PC's address bits and address
lines limit us:

(2'>l« • 1«) + 2'-16 - (2^16 • I^^ + 2^16 - (2-^20) + 2"I6.
- appfoidinately 2"20 - I MB

So, only 20 bits. Boo!

However, protected mode on '286 or better CPUs gets around
this, even when running in 16-bit protected mode. Here is how
it does it 16-bit protected mode still uses a 16-bit segment
register and a 16-bit offset register. The difference is this: in
protected mode, the segment register's value is not multiplied
by 16. Instead it is used as an index into a table of starting

addresses. Each entry in the table holds a 24-bit (in 16-bit
mode) or a 32-bit (in 32-bit mode) starting address for a
segment. To this, the 16-bit (or 32-bit) offset register's con-
tents are added, giving a 24-bit or 32-bit address. In the
sin:q>lest protected mode, this 24-bit or 32-bit address is the
physical address. In more complicated modes, it may be a
"linear" address which undergoes fiuther translation to con-
vert it to a physical address.

In a nutshell, as far as addressing memory is concerned, the
difference between real and protected mode is whether a seg-
ment register contains the physical address of a block of memory
or whether it contains an index into a table that supplies the
address of the block.

The Internet

The Internet can be a great waste of time. Readiag usenet
newsgroups is addictive and hypnotic. Hours pass with noth-
ing to show for them. On the other hand, I've got to have my
comp.lang.forth and various others. The occasional gem makes
up for the rest of the rocks.

Email

For me, the internet offers three things: email, newsgroups,
and file transfer. Of these, the most important is email. I so
prefer to respond via email than to write a letter, print it,
address the envelope, pay the post office. A phone call may
interrupt someone, but email is always convenient for both
parties. If you don't have email access, at least phone MCIMail
at 800-444-6245 and consider their $35/year service. They
even let you email people who don't have email addresses: they
print and mail a hardcopy.

Newsgroups

Perhaps 15,000 world-wide news groups exist. These are
essentially publicly-posted email messages, separated by topic,
discussing nearly every subject imaginable. I feithfiilly follow
a few groups related to my computer programming interests. I
occasionally browse through others as the mood strikes me.
Email saves time, but newsgroups waste time, but the right
newsgroup article might supply just the answer you need to
solve a tough problem. Together, we are a co-operative techni-
cal support self-help group.

10

The Computer Journal / #76

SUPER-CHARGE THAT OLD XTI

By Kirk Lawrence

I find it difficult to think of a turbo XT-class machine as an "old"
con^uter. Heck, I still use mine every day! While the XT might
technicdiy qualify as an "old" computer, this venerable work>
horse has a lot of life left in it. With a few software tweaks, and
possiUy a hardware change or two, the turbo XT will cwitinue to
serve y<Hi welt right into the 2Ut century.

One of the most common moans I hear about XTs is that they
can't run fte fastcsr IDE or SCSI hard drives. Not true! 8-bit, XT-
compatible IDE and SCSI hard disk host adaptors are widely
available at a modest cost. Check the smaller, non-colw hardware
ads in Computer Shopper magazine; youMl find'em. The
controllw's on-board BIOS on these cards fH-ovidcs total support
for the hard disk, and no AT-style system CMOS is neected.

Another complaint about XTs is the lack of high-density floppy
drives. Again^ this is mi easy fix. If you feel the need for HD
fl<^ptes, just grab yourself an S-bit, XT-compatible high-density
floppy drive controller card, or a multi-I/O card with built-in
high-density drive support. These arc also widely available ...
ciAer new (fi-om Computer Shopper ads), or used. If ttiere's an
iiKlependent, local computer store in your town, ask'em to let you
go through the boxes of "obsolete" used hardware in the back
room. Almost every independent computer shop has a stock of
such stuff which they've accumulated over the years. They're
usually glad to get rid of it at extremely reasonable prices.
EHgging into this "old" stuff often turns up some really good
finds,

VideQ*! Easily upgradeable to VOA, if you so desire. Any 8-bit
VGA card will work just fine in an XT. Simply plug it in, and
you're in bu»ness.

CHcay, that takes care of the hardware. But wliat about overall
system performance? Welt, let's face it: compared to a Pentium,
a turbo XT is slowl The good news is, there are several easy
software tweaks you can do which will greatly increase your XT's
performance. In fact, you'll be amazed at the difference.

The first tiling we can do is increase \he processor speed. Yes,
that's right, we CAN speed up the existing processor, and we can
do it with sofbvare! Here's how: the XT's 8253 timer chip
contr<^ tiie rate at which the system RAM is refreshed. In a
normal generic XT, the RAM is refreshed every 15 microseconds.
These 15-micro8econd into-vals require the processor's attention,
thereby consuming diunks of computing time. But the RAM in an
XT really doesn't need to be refreshed that often. So if we change
Hbe DREQO interrupt from its normal 15 microseconds to a much
kmger period of time, the processor won't have to spend neariy
as much of its time refreshing the RAM ... and this effectively
increases processing speed. This approach will speed up the
processor by 5 to 10 per cent. There are a number of freeware
utilities, such as SPEEDUP and TOAD8253, which will alter the
RAM refresh rate. Run one of them from your AUTOEXEC.BAT
file at boot-up. If you wish, you can compile your own program
from the following source code (use any shareware ASM com-

piler, such as A86). It's a tiny program that'll make a BIG differ-
ence in your XT's system performance,. .and it's not a TSR.

; Increase XT processor speed by altering the RAM refresh rate.

org

lOOh

mov

al,074h

out

043h,al

mov

ax,OODOh

out

041h,al

xchg

al,8h

out

041h.al

int

20h

The next thing we can do to boost XT system poformance is to
increase the speed of video writes. The rooohanfcs involved here
have to do with speeding up certain INT lOh fiinctims, and are
somewhat complicated. Fortunately, the shareware pr<^ram QCRT
Version 2.0 ($5.00 from Glenn K. Smith, RADON Software, 809
South Missouri, Weslaco, Texas 78596) takes care of tiiis for us,
Load QCRT frwn your AUTOEXEC.BAT file, and the speed of
your S(^«en writes will increase by as much as 80 per cent QCRT
can be found on many loc^ BBSes and shareware CD-ROMs as
QCRT207:iP.

Another performance enhancement is to increase tiie XT keyboard's
rqieat rate. While not strictly necessary, increasing the typeamatic
rate makes a world of difference, particulariy if you do a lot of
word processing or other types of data entry. Once you've tried it,
you'll never be able to go back to that pokey old default keyboard
rate! The only catch is, you'll have to find a utility that's designed
specifically for the PC and XT. Most utilities of this type are
designed for AT-class machines, which support Interrupt 16h,
Function 3 (an XT doesn't), i recommend the freeware program
HOTKEY.COM, which can be found on many local BBSes and
shareware CD-ROMs. Load HOTKEY from your
AUTOEXEC BAT file, and your keyboard will si2zlc.

One fmal suggestion: resist the temptation to run DOS versbn S.x
or 6.x on your XT. The memory overhead required by these
versions is too high. Use DOS version 3.2x or 3.3x, instead. When
you're limited to 640K of lower DOS memory, as mo^ XTs are,
you need every extra bit of memory you can get. Almost all of the
fancy "frills and extras" which were included with the higher
versions of DOS (such as MOVE, FIND, etc.) are external com-
mands, and have been available for years as third-party fiieeware.
So if you need'em, find and use the freeware versions of tiiese
utilities, rather than loading a memory-hogging "newer" DOS
version.

Even ttuHigh it'll never be able to run WINDOWS 95 or DOOM,
the turbo XT is a wonderfully useful and versatile machine.
There's still a ton of DOS-based, XT<ompatiblc productivity
software programs out there — text editors, word processors,
databases, spreadsheets, even desktop publishing programs —
which will allow you to do just about anydiing you need to do on
a computer. By implementing a few software tweaks, and maybe
a few minor hardware upgrades, your XT will remain vital and
viable fw many years to come. And the nicest part is, the price
is right!

Enjoy. Kirk Lawrence (klaw@3rdlOOO.com)

The Computer Journal / #76

II

File Transfer

Lots of information is stored on the Internet in the form of files
that can be read on-line or copied to your computer to be read
off-line. It may not be easy to locate and you might waste more
time looking than it is worth. The traditional method is
'anonymous ftp' (file transfer protocol), where you "ftp" into
a remote system, browse its file structure with the 'dir' com-
mand, and transfer the files you want with the 'get' command.
Slick user interfaces are taking over, so more and more the files
are transferred by clicking on the file you want as you "surf the
Wd)." Those with only email access can receive files, even
binary files, via email.

My Internet Solution

I finally decided what to do about Internet access and a perma-
nent email address. The two best deals I've come across are
Eskimo North and Pobox.

charge a little more than I would like, but less than long
distance or Century. The other ISP is Century Telephone
Company (our local phone company). I have a beta testing
account with Century, but don't like the very slow response
fi-om their technical support I expect to drop them when they
start charging me money. A third ISP has just started up,
matching their rates to Century's.

GEnie and SWT

I just dropped my GEnie account to help pay for my Axiom and
Eskimo accounts. My SWT (Southwest Texas University)
accoimt (fs07675@swt.edu) is inactive since I'm "laying out"
this (fall) semester. Even if I enroll in further coiu"ses, I don't
think I'll use my SWT much, due to its ten^rary and unpre-
dictable nature. As Pobox says, "the only thing worse than
losing your job is losing your email."

PC Software Miscellanea

Eskimo North

Eskimo North in Seattle offers a fiill-service internet account
for as low as $6/month for dial-in or $3/month for telnet-only,
when you pay for 5 years at once. Even though I live in Texas,
I just opened a trial telnrt-only account: pygmy@eskimo.com.
I think I'm going to pay them for 5 years. I rather like it so
far. It seems a little slow, but should be fine for reading the odd
newsgroup that my local ISP might not carry. One of its users
said "eskimo is a dog ... albeit a feirly reliable, friendly one."
I'll use my sergeant@axiom.net account, which is a local
phone call, to access the Eskimo account. Apparently, I'll also
be able to use my Eskimo account for a Web page and an ftp
site. Eventually, look for a downloadable version of Pygmy
Forth there. Send email to info@eskimo.com for fiill details.
By togging in as 'new' you can get a free 2-week trial account.

Pobox

Pobox offers an even cheaper solution to the permanent email
address problem. For $ 1 Sfyeai or $75 for 6 years, they provide
an email forwarding service. You get 3 aliases for that price.
ff your real email address changes, just update your listing with
P*ox. I was having a lot of trouble deciding between Eskimo
and Pobox, so I think I will get them both. If one fizzles, the
other should still be good. My permanent address is now
pygniy@pobox.com. Logged into Eskimo, I sent a test mes-
sage to pygmy@pobox.com. It arrived at axiom within 10
seconds. This seems fast enough. Send email to
info@pobox.com for full details. They offer a 3 month free
trial.

Axiom

A year ago I didn't expect any local ISPs in San Marcos. Now
there are three! (Not counting the university.) Axiom was
started by some people who have run a BBS in town for years.
I expect sergeant@axiom.net to be my primary account. They

J and APL and Windows and cetera

I've had a mild interest in the language J for sometime. It is
the successor to the APL language, which is well known for
intensely compact and unreadable mathematical expressions (I
mean this in the kindest way). I more or less gave up on J after
attempting to work through some of its documentation written
by its inventor Kenneth Iverson, but hope to get back to it
someday. The latest news is that Byte magazine recently had
an article on J. Strand Software Inc (19235 Covington Court,
Shorewood MN 55331, USA, (612) 470-7345) is the current
distributor. I received their very nice Jottings newsletter.
Phone, or email Aime Faust at amfeust@aol.com, if you'd like
a c<^ of the newsletter. A freeware version of J for Windows
(and perhaps other computers?) is available by ftp from
watservl.waterloo.edu or wuvieai.wu-wien.ac.at in directory
languages/j.

One reason J interests me is that it apparently can be xised to
develop Windows applications. I may have mentioned that in
spite of trying to think of myself as a Forth purist, I find myself
accepting money for maintaining and enhancing a medical
accounting package written in Clipper (a EXDS-based XBase
language, more or less). Call me a whore, I don't care. There
seems to be pressure in the air toward making the system run
under Windows. (It will run now in a DOS box.) Why slow
it down so Windows can hand-draw ugly fonts? Anyway, I try
to keep an eye open for how to move the application to Win-
dows if the pressure becomes irresistible. J is just kinky
enough I might look into it further. Realistically, there are
several other alternatives to consider. I especially want to look
at Delphi, which I still hope to install any day now. It gets rave
reviews in the Clipper and database newsgroups. VO (Com-
puter Associates' complex, bloated version of "Clipper for
Windows" named Visual Objects) gets mixed reviews. Some
say they hate it; some say they like it. All say it takes a lot of
RAM.

12

The Computer Journal / #76

Speaking of VO, I found a review of it in PC Techniques
magazine (Aug/Sep '95, pp. 88-89) by James Bean to be very
interesting from the standpoint of the English language and
logic. He says "Overall, CA- Visual Objects is extremely pow-
erful and provides many rich features for the client/server
developer..." Wow! Sounds great. "Rich features" ooh... not
just "powerful" but "extremely powerful" ... doesn't that sug-
gest that the product works? Later in the same paragraph he
says "Also, when the build fimction executes correctly and no
errors are noted from the compiler, the resulting .EXE should
be considerably more robust and error free than it actually is."
To what have our collective standards sunk?

Speaking of language implementations, I see Mix Software
(800-333-0330, 214-783-6001) offers a C compiler for $19.95.
From the ad, it sounds as good as Borland's, maybe better, for
straight DOS work. Of course, it's another $19.95 for the
debugger and $8 for shipping. Now you are pretty close to
what Borland's Turbo C/C-h- would cost. Various other add-
ons cost $10 to $30. If anyone tries it out, please let me know
what you think of it.

Bigger Hard Disks and Alternate Operating Systems

Gigabyte Harddrives

I finally succumbed to the lure of under $300 1 GB hard drives.
I added a Maxtor 1.2 GB EIDE hard drive. There are various
FAQs (Frequently Asked Questions) on the internet discussing
IDE vs EIDE. The bottom line is either kind of harddrive will
work with either kind of controller. You'll probably get faster
data transfer with EIDE. There are serious questions involved
in accessing a disk with more than 504 MB because of the way
the PC's BIOS ROM handles disks. Before I was finished, I
almost wished I had bought two 500 MB drives instead of the
1 GB drive. 1024 is the magic maximum number for cylinders.
DOS can't read past the 1024th cylinder. I was reluctant to use
the Disk Manager software that came with the Maxtor drive.
I had heard there might be problems between it and OS/2 and/
or Linux, etc. What finally worked for me was to tell the
motherboard BIOS setup (the "CMOS") that I had a drive with
816 cylinders and 48 heads and 63 sectors (rather than the
2448 cylinders, 16 heads, and 63 sectors printed on the drive).
The product in bytes, either way, is the same. This keeps the
number of cylinders imder the 1024 limit. I also told the BIOS
setup to use "LBA" (logical block addressing). I _think_ this
was necessary. If I understand the problem, DOS can't handle
more than 1024 cylinders while IDE controllers can't handle
more than 16 heads. The LBA mode of the motherboard BIOS
apparently converts between DOS's view of the drive geometry
to a Unear block addressing mode that IDE controllers can
handle. I was tempted to turn off the LBA mode in the BIOS
setup and see if the drive was still accessible, but "let sleeping
dogs lie" came to mind.

could have set a jumper on the Promise EIDE controller to use
LBA. So, it turned out I probably could have used my same old
IDE card without buying the Promise card. Oh well. Maybe
it's faster now. Also, I had a terrible problem with the old
controller. I had a 1.2 MB floppy as drive A and a 1.4 MB
floppy as drive B. Diskette changes in drive B (the only floppy
drive I used, practically) were never recognized. Whenever I
wanted to switch floppies, I had to reboot! This was an
aimoyance, but was only a major problem when installing
software from multiple floppies.

Since the world has moved to 1 .4 MB 3-1/2 inch diskettes, I put
the 1.4 MB drive as A and the 1.2 as B when I installed the new
controller card. Now changing diskettes in drive A works fine.
I suspect the motherboard/controller combination, as I used the
same model IDE controller and same model floppy drive, with
the same switch settings, in another coiiq)uter with no trouble.

I bought the EIDE card and the 1 .2 GB Maxtor hard drive from
the Internet Sh(^ping Network (http://shop.intemet.net). They
shipped fairly promptly, but I paid for next-day deliver and got
2-day in one case and and 3-day in the other. Why two cases?
Because they shipped the items separately and charged me the
separate shipping on each. This automated ordering has its
disadvantages. Next time, if I deal with them, I'll probably ask
for UPS ground.

I put in a "MEI Premium Backup 420" tape drive (about $99
from MEI/MICRO). This uses the QIC-80 tape format and
variants. It is really an IOMEGA drive relabeled for MEI. The
ad said NOTHING, the salesman I spoke to on the phone said
NOTHING about the potential problem of using certain kinds
of tape. After I bought it, after it arrived, I read in the
documentation that using the 2 120 (ordinary QIC-80) tape can
ruin the tape head and that the more expensive QIC-80 WIDE
tape is recommended. The ad listed the 2120 as one of the
several kinds of tapes the drive siq)ported. It's not worth the
trouble to send it back. I'll use it until the tape heads are ruined
and then buy another drive^owi another vendor! A "420" tape
drive really only holds about 2 10 or 220 MB. The "420" comes
from the possibility of compressing the data. Maybe your 420
MB of data can be compressed down to 220 MB, maybe not.
That "420" is on the more ejqxnsive tape cartridges. The
cheap ones I got for about $9 each hold much less.

The actual tape backing up and restoring went smoothly. I'm
really glad to have a tape backup system. One day, I'll
probably get a better one. For now, I'll back up to tape and also
back up the most important files to floppy. For rearranging my
harddrives, the tape was great.

OS/2 Warp

While I was putting in a new drive and having to reformat and
repartition it anyway, I thought this might be a good time to try
out OS/2. It was mostly a waste of time, but I learned a lot.

If I had not had an LBA mode in my motherboard BIOS, I The OS/2 1 read about in one of the FAQs sounded great! I wish

The Computer Journal / #76

13

that had been the version I tried out (joke). It seems that OS/
2 will run essentially all DOS programs and all Windows
programs, plus, of course, any programs actually written for
OS/2. Not only that, it will let you multitask them. The
Internet reported a magazine article claiming Win95 and OS/
2 ran applications approximately the same speed if only a
single app was running, but that once you started to multitask,
OS/2 was perhaps 4 or S times faster. I wanted all that plus the
HPFS file system, which allocates disk space in units of 512
bytes, instead of the 4K to 16K chunks used by DOS.

I never could get OS/2 to talk to my printer, which was on a
serial port. DOS doesn't have any trouble with this. Nor, could
I get OS/2 to give my DOS comm program the data from the
modem quickly. There was about a two second delay between
pressing the "show me the next page" key and seeing the next
page diq)]ayedl DOS has no such trouble. I feel sure there are
work arounds tor these problems, but life is too short. It is this
sort of trouble that softens me up for Windows 95. Even if
Win9S is no danrn good, it will still own the market. Time
sjpeat learning to install, use, support Windows is probably a
better investment than spending it on OS/2.

On the other hand, I mildly complained of my troubles on an
0S2 newsgroup and got very nice email from an IBM em-
ployee offering several suggestions on setting up OS/2 and
where to look fw further information. Later, I also could not
get Linux to work with my serial printer, so I don't see how I
can feel too bad about OS/2. I gave up, moved my printer so
a parallel cable would reach, and put the printer on LPT 1 : (the
first parallel port), where most PCs have their printers. After
that, I re-installed OS/2 and it worked fine with the printer. I
still haven't figured out how to get fast modem response, but
I'm sure it can be done.

Disk Partitioning

Here is how I finally split up the 1.2 GB drive:

1 MB prinuiy partition for Boot Manager

1 1 MB primary partition for booting MS-DOS } Drive C:

43 MB primary partition for booting MS-DOS 6.22 or Drive C:

255 MB FAT data partition for DOS Drive D:

255 MB FAT daU partition for DOS Drive E:

255 MB FAT daU partition for DOS Drive F:

255 MB FAT data partition for DOS Drive G:

53 MB reserved for Linux

66 MB HPFS OS/2 boot partition Drive H:

On a FAT file system, the size of the allocation unit depends
on the total size of the logical drive. I would prefer to combine
logical drives D through G into a single logical drive, but can't
afford the wasted space. That's why I have four 255 MB
partitions instead of a single large partition for my DOS data.
With the small partitions the allocation imit is 4 KB. So, a 200
byte file actually occupies 4 KB on the disk. If I had combined
the four 255 MB partitions into a single 1 GB partition, the
allocation unit would have been 16 KB. Ooh, that hurts.

the single remaining extended partition. Only 4 real partitions
are allowed. If you want more, you must make at least one of
the partitions an "extended" partition, which you then keep
carving up into additional logical partitions. DOS and Boot
Manager will only boot from a primary partition. OS/2 will
boot from a logical partition and so will Linux (so I've heard).
Drive H: is only visible to OS/2, since it is not formatted as a
FAT (File Allocation Table) type of file system. Instead, it uses
OS/2's native HPFS (High Performance File System).

Yes, I left OS/2 on the machine. Its FDISK command works
better than DOS's. When OS/2's boot manager comes up, it
offers me a choice of which operating system to boot, but
defaults to DOS 6.22 if I don't pick another within 30 seconds.

Networking

I also bought two ethemet cards fi-om MEI and installed one in
the 486DX40 and the other in the 386SX25. Their test
programs indicated all was well. They could "ping" and
"pong" data back and forth. Then I tried to install the Little
Big Lan. It sort of worked. It would start a transfer, then lock
up. I gave up on it. When I have more time, I'll try Novell or
Lantastic or Linux to see if they work ok. If so, I'll blame the
Little Big Lan. If not, I'll blame the 386SX25.

Linux

I installed Linux. I bought the "Linux on CD-ROM Slackware
2.3 Slackware ELF Beta" ADRAS July Edition for $10 plus $3
shipping and handling (plus sales tax for Texas destinations)
from

Daniel Jimenez adras@crl.com

ADRAS Computing

PO Box 29391

San Antonio, TX 78229.

Linux and the entire Slackware package are impressive. You
sive get a lot for the $ 1 3 . A massive amount of documentation
comes on the CD. You can install Linux entirely to your hard
disk in its own partition or to your hard disk in a DOS partition
in a regular DOS subdirectory or you can install a minimal
amoimt to your hard disk and nm the rest of Linux from the
CD, as the CD contains a "live file system." The version of the
kernel is 1 .2.8. I believe the CD contains other versions of the
kernel as alternatives, plus source code for even the newest
experimental kernels (the 1.3.x series). (The stable kernels
have an even second nimiber while the kernels under active
development have an odd second number.)

I ran into a little problem. My CDROM drive quit working. I
opened the computer case, removed the drive, opened it up,
reconnected the cables, and watched it try to run. The CD
wasn't spiiming. I started it spinning with my fingers and

Partitions beginning with Drive D are all logical partitions in
14

Continued on page 1 7

The Computer Journal / #76

The European Beat

by Helmut Jungkunz

Regular Feature

All Users
East German 280

Today: Jubilee - 10 Years of Schneider/ Amstrad CPC User
Group Munich!

Fascinating, fascinating ... the unthinkable has happened.
Our User group has survived heavy attacks of Bill Gates and
Co. for many years. We have seen many an operating system
come and go. We ran them all. We loved them and we hated
them, but our secret love still is CP/M. It was such a neat little
system, so much in order, so easy to dive into, so easy to
understand, once the exploring mind had the basics.

In February 1985, 1 got my AMSTRAD CPC 464 (with cassette
drive only), a right angular gray box, with a gray Monitor,
called "Green Monitor" because of the color of its monochrome
output. It cost me a fortune (500 $+) and after a while I found
out, I couldn't do without a disk drive. So, I spent another 350
$ on that little (gray) box. I bought the "CPC Amstrad
International", a national magazine for Schneider/Amstrad
CPCs. For those of you, who haven't been following from the
start of "The Eiu-opean Beat", Schneider was a German com-
pany, working as an agent for AMSTRAD in Germany, who
renamed the CPCs into "Schneider CPC", so that everybody
thought, that Schneider was the maker of the CPCs. I learned
how to type in BASIC programs without mistakes, yes, even
how to correct enors in the programs. Then, I discovered the
CP/M side of the machine. After a short period of A> ? and
A>BDOS error on A: Select!, I managed to work with it - and
was inunediately limited by the low TPA of 39K.

So I went and bought the brand new Vortex RAM expansion
kit. That's when problems started. I couldn't use my disk
drive the way I had, since I kept getting these "hangers" when
switching the computer on: The initial "ROMWALK", that
reset all the ROMs and/or EPROMs, failed to return from the
disk drive controller, that contained the disk ROM. Then I
read about the "VORTEX User Group" and joined them. I was
one of the first seven, which put me on the lucky side, but more
about that later on. Anyway, 1 met a clever guy, called Andreas
Kisslinger, who had the correct explanation for what was
happening. Since you couldn't do a disk catalog command
"CAT', it was named "The CAT Syndrome". After replacing
the ROM in the controller with a new EPROM, the problem
was gone. Also, the BIOS within the e?q>ansion unit was very
poorly written, plans arose to rewrite some of the code.

Another guy in the club soon took some of us aside and pointed
out, that the host of the VORTEX User Group, a clever dealer,
always tried to sell us some stuff and more or less ripped us off.
He said, that he was going to form his own CPC User Group
and invited us to join. After a Powwow, we decided this was
a good plan and sat down for the founding procedures. In
November 1985, the formal foundation of the Schneider/
Amstrad CPC User Group (SCUG) was a fact.

Then followed a period, when the host of the VORTEX User
Group tried to force "membership fees" on us. A couple of us
had heard from the first ones, what was happening, and we
immediately sent our armouncements notes to that guy. He
then wrote back "Oh, but you guys didn't have to pay anyway,
since you were among the first seven ...". We quit anyway.
The others got together an alarmed the district attorney. Thus
we found out, that the dealer played the same trick on people
in other parts of Germany as well, but had his company site
legally in Switzerland(!). He was fined in a law suit at long
last.

The SCUG soon had lots of new members, and the usual
discussions and arguments took place, like in every club,
perhaps. There were a couple of people, that came to us from
the VORTEX User group, who were very much afraid of any
incorrect phrasings in our "membership agreement". After
months, we had it all sorted out, and the group started to
produce usefiil output. Andreas Kisslinger wrote B360K, the
famous first CPC BIOS RSX, that allowed not only to hook up
an 80 track drive to the CPC as drive B:, but to also patch the

The Computer Journal / #76

15

40 track BIOS to accept 80 Tracks single sided, which gave
360K minus reserved system tracks == 348K net capacity
formatted. There was a hardware diagram, allowing you to
buiW your own Z80 PIO. The first Public Domain disc was
collected, and • the first SIG/M programs found their way into
the group.

There was one guy, who sold the disks to members at a
reasonable price (8 Deutschmarics a piece), and I bought a
cou{de. When he armounced his moving to another city, I
decided to bt^ the whole packet firom him (up to #271 then).
I started to browse through the disks soon and found lots of
useful tools, that I put together on another P.D. disk, fi-ee to
club members. Those were tools like NSWEEP (1.99), NULU
(1.5), DELBR,USQ, SAPIO and ALIENS. That was the start
of my haddng into the system. Reading the patch documen-
tation firom ALIENS, I learned how to adapt cursor and other
terminal fiuicti(His to the program. I lodced at other programs,
too and found it pretty annoying, to have to install every
program to our wdrd CPC CP/M 2.2 terminal. The main
IHt)blem was, that most programs were written for TELE VIDEO
terminals, using CTRL-Z to clear the screen and home the
cursor. The CPC in C?M 2.2 uses CTRL-Z to define a true
screen Windowl Imagine, the Syntax would be CTRL-Z,number
of window (0 being the main screen!), starting row, starting
column, end row, and column. Now imagine the CP/M seeing
CTRL-Z by itself This would be the equivalent of "Do a
Window". Now CP/M would look for other characters to
conq>lete the window. In most cases, the CTRL-Z (Clear
Screen) would be terminated by Zeroes. The result was a
catastrophe to the CPC screen: WINDOW 0, row, column,

end, end! - => cursor at home position, stuck in a tiny
spot at the upper left comer, unable to move!

1 got so disappointed, after failing to install Polish Pong, that
I turned away fix)m the SIG/M stuS'for three weeks. After that,
I gave up, trying to install P.D. games. Instead, I started to look
at more sq)histicated stuff, to help increase the performance of
our CPCs. After a short while, I reached SIG/M 101 and got
pulled into the deeps of Richard Conn's ZCPR introduction. I
presented this to our club (end of 1986!) and tried to catch our
programmers interest to implement ZCPR into our CP/M 2.2

I got weak replies, phrases of "missing BIOS source", "no
time", "other projects", and "Is it really worth it?", until the
whole thing just dropped dead. It was then when I bought my
first IBM XT, in order to keep up with the small side jobs at
computer fairs, that I got from "Markt&Technik" (M&T),
when I was connected with their "Happy Computer" magazine.
I bought a 1200 BAUD Worldport pocket modem and started
to "walk the phone Unes". I soon became CP/M Co-Sysop at
a BBS in Munich and made contact to other Sysops from other
BBSs. I met Peter Spaeth, who was a member of the German
Computer Club (forgot the actual name), but also operated as
a Ubrarian for the Osborne User Group. From him ,1 got lots
of new files and insights. The most important thing was, that
he had all the FOG magazines, where many articles dealt with
CP/M programs, hitherto unknown to me an my fellow users.
I read about REMBRANDT (graphics program for the
KAYPRO), and other nice things. There were a lot of men-
tioning of ZCPR and Z-tools.

I also had access to the Morrow Owner's Review (MOR), for
one of our newer members, Timothy Slater, was working on a
Morrow Micro Decision. He is a translator for technical
German into English, since he is American.

I read all these wonderfiil developments in ZCPR in articles
like "Tools for Tyros" and "Forever Z!". The latter series was
written by Rick Chames, a guy, whose phone number hap-
pened to be included. So one night, I sat up and called Rick
Chames "on the dodgy subject: are there or are there not Flying
Saucers" (I can see all them Jimi Hendrix fans grin!). Well,
I asked his opinion on ZCPR. He was so overwhelmed with Z,
he set my phone counter spinning, telling blooming stories of
how Z changed his life and that it was not an operating system
replacement, but a reUgion. Believe me, he made it sound that
way! I was stimned (at five o'clock in the morning, who
wouldn't be!) and decided to watch out for more. I sent some
programs on a disk to Rick Chames and that was all for then.
RepUes died out soon. Then I read about that new development
NZ-COM, available fi-om Echelon! Automatic ZCPR installa-
tion for every system! I showed this to our members and got
a more interest than before. But of course, they would still sit
and wait, if I hadn't tried to contact Jay. The rest of the story
you already know.

SCUG has lots of members with Z-System, of course, and I
provided them with the AMSTRAD terminal definitions. I
initiated the production of the DOBBERTIN hard disk for the
CPC (they asked, if 50 pieces were realistic) and they sold
hundreds of them. The DOBBERTIN RAM expansion is a
lawless unit, fiilly compatible to most everything, the ROM-
Box allows you to add-on further EPROM software and/or
BIOS extensions.

Today, we are facing the fact of "Future OS", the "final
operating system" for the AMSTRAD CPC, written by one of

16

The Computer Journal / #76

our members, a no-compromise solution, that doesn't claim to be compatible to anything.
It plainly isn't. But, it offers nice software hooks for other programmers, plus, it comes with
source.

The official SCUG celebration will be held in our traditional Club home, that we only
shortly regained, the "ASTALLER HOP' in Munich, on Saturday, November 25th. The
fact, that the very next day, the famous Electronic Flea market takes place only 1 mile from
that location, might well help to attract lots of (German) pec^le.

What does the future hold? Well, some of us still have a CPC and run it, some keep it in
a nice, romantic comer of their homes, some have a PCW and most of us have some kind
of x86 machine with emulators like CPE or CPCEMU on them. We use all kinds of
operating systems, like CP/M-80, CP/M86, CP/M-68K, MP/M-80, CP/M Plus, MS-DOS,
IBM-DOS, Novell-DOS, LINUX, Coherent and SYSTEM 7 (MAC). We plan to keep the
CPC in our baimer as a signal to others, showing our tolerance against weaker systems, our
accq>tance of help-seekers and a good will to keep up a piece of tradition in this oh so fast
world.

Regards and cu
Helmut Jungkunz

(P.S: I'd be glad to receive your comments on my articles, best through e-mail, since this
creates a computer file that can be passed to others.)

XT Corner Continued

everything worked but it wouldn't start up reliably by itself. I
fooled around with the upper bracket that clamps the CD in
place, bending it higher and lower, until I finally set it so it
seems to start up reliably. We'll see.

After that, the Linux installation went smoothly. I had planned
to put Linux in its own partition, having left a 54 MB partition
just for Linux on my new 1 GB disk . Well, 54 MB is nowhere
near large enough to install everything. I plaimed to install the
minimum and run the rest from the CD. I think this would be
too slow for comfort, but would be ok for a quick look at Linux.
Since I had the case open any way to fix the CDROM drive, I
took that opportunity to reconnect my 330 MB hard drive and
devote 280 MB ofit to Linux. I installed nearly eveiything. I
occasionally said no to things such as the fonts and macros
needed to typeset Turkisk documents, but I installed damn near
everything else! Far more than I'll ever use. I said it was
impressive. My impression is Linux, like the rest of the
modem software world, is too damn big and complex. On the
other hand, a 330 MB harddisk is pretty cheap these days and
a 120 MB is large enough if you don't install all the extra
packages and source code you'll never use. You don't have to
have a CDROM drive (you can install from floppies), but they
can be had for about $79 now. I don't expect to do much with
Linux, but I wanted to take a look. So fax, I've barely looked
at it. I've used its comm program (minicom) to log into my
intemet accounts. The medical accounting package written in
Clipper partially runs imder Linux's DOS emulator. I think I

need to change some settings related to the type of video
display.

I've been subscribing to the

Linux Journal
P.O. Box 85867
SeatUe. WA 98145-1867
(206) 782-7733
$22^ear for 12 issues

and enjoy it. I think woridng through various back issues will
serve as my Linux tutorial.

Frank Sergeant

pygniy@pobox.com (permanent)
sergeant@axiomnet (current)

The Computer Joiuiial / #76

17

special Feature

XT Support

Different CPU on BUS

Alternatives to the XT

By Bill Kibler

For some time I have been dying to
complete an article on using the PT68K
motheiboard with 0S9 and SKDOS.
Orginally I had intended to cover it in
this article. Now that I am passing on
the control duties of TCJ to Dave, I
decided I will have time later to more
fully explain and document the ideas I
had in mind. It became apparent as I
started (m the topic that an introduction
was needed about systems in general
that give you alternatives to just buying
a fiister XT. I will give some background
of the PT68K card, but this time the
tOfHC is mostly what alternatives you have
avaialable.

The Why

Why would you want to do something
other that use an off the shelf XT system
for your work? Defining work
immedately gets us going and is some-
what reqx>nsible for the change of this
article. At my work, we had a recent
discussion of a proUem requiring better
than one second turnaround from the
time a person touches a screen, request-
ing a <kx)r to be opened, and having the
door actually open.

The use of Touch Screens is very com-
mon, but all seem to have one problem,
they are slow. Generally speaking, a stan-
dard 386/486 PC has a special screen
surface attached and putting your finger
to this sur&ce, generates the equalivalent
of a mouse click at the location your
finger touched. The problem is the ever
present tons of PC overhead, extreme
slowness of conversion as your com-
mands woiks their way through the many
layers of various programs and TSR driv-
ers to eventually appear out the back
into yet more interfaces.

It has not been uncommon for this ac-
tion to take 3 or 4 second to be com-
pleted. That is from the time the finger
hits the screen to have a door open. The
question asked was what alternatives are
possible. We know the times possible for
PC/XT type systems ruiming the latest
CPUs, so the first direction we look at is
fasters CPUs that can use the same hard-
ware. This is where I said "how about a
68000 based XT system running 0S9?"

At this point in my work discussion I
realized that few people are aware that
systems using the ISA BUS format (the
bus structure in a PC/XT) but running
CPU types other than 386/486 do exist.
That same realization said this article
needs to be more general and e^lain the
alternatives.

Same but Different

The option to the problem presented
would be simply cutting down the layers
of software, since 386/486 are basically
speedy processors and DOS is not.
OS9000, the PC/XT varation would be
one answer, EXPRESS by Forth Inc
another. Numerous embedded DOS and
real time variations might also speed up
the system. Moving to PC 104 by itself
would not help, but ROMing code that
only read the screen and sent a com-
mand might. The PC 104 bus is simply a
form factor change of the ISA bus. In-
stead of edge connectors for the bus in-
ter&ce, you have a pin and socket sys-
tem of stacking cards. The main differ-
ence we see here is separate CPU cards
allowing a pure building block approach.

The building block approach is what
most organizations are taking to solve
their problems. This approach is not new,
just the hardware options have become

more interesting. In my last article on
the STD BUS we saw that they started as
a building block solution, giving the users
many choices of small pieces in which to
plug and play. The PC 104 vendors are
providng the same options.

What is new on this front, has been the
wealth of different CPU types now avail-
able. Z- World has moved their Z180
based product line to the PC 104 and ISA
bus as well. This means you can take an
atplication written for the Z80 and make
it talk to regular PC bus devices, say
ethemet cards? I am not sure this would
be faster, but it does show that the wealth
of PC compatible hardware can be used
on other CPU types.

I found one company who has taken this
approach to extremes. The parvus com-
pany from Salt Lake Utah produces sev-
eral CPU types on 2 by 3 inch boards.
All the boards have a memeory mapped
interface that can be plugged onto a
PC 104 or ISA bus interface card. They
can sit as co-processors with one type of
card, or take over the bus if plugged into
another type of card. Their main CPU of
choice is 68HC11, for which they have
written drivers to talk to most of the
standard PC devices (CGA/Mono, floppy,
hard drives, etc.). 8051 and Z180, and
80198 are the other CPU options.

Might any of these varaiation slove the
pr(*lem, I am not sure, but if your old
application needs to talk to newer PC
devices then here is an alternative. The
ISA bus is basically an 8 bit bus with
8MHZ clocking. This 8MHZ clock speed
makes it possible for the smaller CPU's
to use it, but also limits I/O speeds and
is often the reason for poor performance,
even on a Pentium CPU. To change this
we have IBM's approach that foiled, the

18

The Computer Journal / #76

MCA bus. Better performance but re-
quired major changes in hardware and
had numerous compatiblity and licnseing
problems.

The latest option we find is the PCI bus.
This is basicaly a 30 or 50MHZ varia-
tion on the ISA bus. I don't have all the
actual specs yet, but from what I can see,
the industry leaders are jumping on this
bus quickly and from many directions.
Since it is getting major support and
doesn't have aiQ^ licensing agreement
needed for use, I think it will b«:x}me the
high speed bus standard for many years.
An other advantage of this bus is it's
acceptance by several industrial
manufactureres. Prolog which helped
start the standard bus, has said they are
making it their bus of choice. All the
new Mac Power PC's use it as well.

The industrial version of the bus, much
like PC104, uses sockets and form fac-
tors closer to VME or European. Prolog
has gone even farther by using PCI and
STD bus devices in one box, giving the
user access to both worlds. The idea here
is high speed CPU/Memory/Network
conqwnents, while keeping the slower
real world interfaces of STD BUS I/O.

68K Option

Most of the faster q>tions so far use the
standard 486 or Pentium CPU. I have
found these CPU's overkill and
oveibudget for many simple projects. For
those sinq>le items only needing a few
PC based I/O cards or migrating from a
8085 STD bus project to the PC world,
using a 486 is hard to take. You could
use one of the Z180 ISA bus controllers
or try a 68000 system. Why 68K CPU?

I can think of many reasons for using the
68K over the 486. Generally you can
gain some speed using 68000 CPU's just
because of the better internal CPU de-
sign. The instruction set alone is better
optomized and will produce smaller pro-
gram sizes for similar operations. The
68000 has always been a 32 bit CPU
with a flat address space. The dreaded
segmentation that has made programs
on x86 CPU's a night mare, doesn't
exist on 68K.

Generally I find the cost of CPU power
cheq)er in the 68K's than Intel's, al-
though recent CPU Clones have brought
all prices down. The alternatives I Uke
are using the $200 68K based clone
boards ( cost including CPU but no
memory.)

The PT68K

So here we are now looking at an alter-
native. Where did this alternative come
from? Well certainly there were several
vendors who were producing 68K bussed
systems and saw the need for the use of
che^)er PC interface cards. One person
however was looking more for a means
to teach how computers go together. That
person is Peter Staik of Star-K Software
System Corporation, the maker of
SK*DOS.

Peter is a college teacher and came out
with a series of articles in Radio-Elec-
tronics Magazine in October of 1987.
The article had the reader building their
own 68K based PC compatible system.
The kits were available fiom Peripherial
Technology and you could build your
own as the articles explained the various
parts. The idea was to talk about and
teach a different part of the system in
each article and thus over several issues
completely explain how all the different
sections and components woric together
to make the fiill computer.

We have attempted to do similar projects
here in TCJ, but I must say that Peter's
series is excellant and worth hunting
down in your local libarary. Peter also
sells the material as a home course, called
"68000 Hardware Course" at $25 (the
hardware kit cost extra).

So what do you get and is this unusual?
Since getting mine, I have discovered
that at least two or three other vendors
sell similar systems. They appear to all
have similarities in desiga The main
idea is some version of the 68000 CPU
(68K to 68040), on board I/O (serial and
floppy), a number of standard ISA or
ISA/AT bus slots. ROM monitors are
provided that allow for running 0S9 or
SK*DOS and can do some debugging.
Some ROMs may even contain BIOS

like code for accessing PC cards such as
hard disk controllers.

Since the idea is mostly to run these
products as embedded controllers, tb;
serial I/O is normally included. This
means they can be brought alive with a
simple terminal or in the case of the
PT68K and it's floppy controller, you
can boot from floppy disk atuomatically.
I have done some plying with the PT68K
and found the ROM tools good, and the
machine fairly snappy in it's perfor-
mance. A more detailed testing is sched-
uled for a later issue.

Let me take a second of your time to
explain the hardware in more deatils.
First off the board size is that of fiill AT
motherboard. It comes with the standard
PC power supply cotmectors strips. You
can install monochrome or CGA video
cards in one of the seven XT slots. A
connector is provided for one PC com-
patible keyboard. I beleive that later ver-
sions also support VGA cards, if not in
ROM, at least in loadable drivers.

In the case of the PT68K-4, you have
two floi^y disk controllers to chose fi'om.
It comes with both a WD 1772 and the
WD37C65. The 1772 is for XT level
floppy drives, 360 and 720K. The 37C65
will handle all drive types, including the
1.2 and 1.4 meg. The 1772 does not use
the twisted drive cables found in PC's,
while the 37C65 does. This gives you
backward and forward compatiblity.

Standard reset and q>eaker pins are pro-
vided. I have mine mounted in a small
tower case and it now works fine. I did
have problems earlier when I tried
mounting it in a older style case with
metal standoffs. Apparantly there is a
problem existing around one or two of
the mounting holes that you need to
watch out for. ff you think this is only
their problem (PT68K) let me say that
many of the PC motherboards have the
same problem. This explains why al-
most all PC cases come with plastic
mounting studs these days.

What else? Printer cable header is pro-
vided just like the flq)py headers. All
the afore mentioned inter&ces are on the
motherboard as header strips. This means

The Computer Journal / #76

19

you have to make cables that run from
the header strips to the appropriate con-
nectors on the back of your unit. Also
you can use the printer port of your
monitor card, if it has one.

Hard drives are supported by using the
WDXT-GEN2 interface cards. These
were very popular hard disk controller
cards used in XT and early AT systems.
There are many clones of these around
and one that I tried didn't work. Since
all my cards are very old, I haven't had
time to find out why it didn't (might be
bad - 1 certainly don't know - yet) work.
Supposedly you can use IDE drives as
well, but that all remains for the next
article.

To expalin the next part of the design, I
need to review how these systems came
about. The vendors were all 6809 pro-
viders, mostly SS50 BUS nmning 0S9
(this case the "9" stands for 6809 CPU).
0S9 has always been multitasking, or
able to run more than one user. I have
several stories £rom people who were
nmning whole departments on single
6809 systems. Naturally when the 68000
came out the users wanted to migrate to
it and gain all the extra power it offered.
Remember that DOS machines are still
not multitasking unless you go to Unix
or NT boxes. Those early day systems
running Unix in fact where all being
done on 68000 CPU's.

Using Unix, also meant that more than
one user would be on board, and most
users would be on terminals. To help out
the boards come with two 68681'$
DUARTs, set as 4 terminal ports. Here
also is one of my complaints about the
design, mainly that the four header stripes
used for serial terminals are not cable
ready. By that I mean you must hand
wire the header strips to the RS232 sock-
ets. You can't just crimp a header on one
end and a DB25 on the other. Now we
are only talking about faai wires, but
then why a header strip at all?

That minor complaint aside, the board
does come up looking for either terminal
on com port one or a PC keyboard. The
ROM menu is sent to both output op-
tions so you can play with either. The
orignial ROM from Peripherial Tech-

nology is ready for 089 and REX. REX
can also be had from them on disk with
soiure code. This means you could hack
this version for your own personal
project.

If you want to try SK*DOS a different
ROM is needed from Peter. Then you
can run either SK*DOS or 0S9 from
that ROM. The ROM also has BASIC
and HUMBUG. You can partition your
hard disk to boot either 68K system, and
thus try or use either. I think you can
also throw REX in this as well, but not
sure at this moment. I do plan on re-
viewing all three and try some hacking
to find out which system is easiest to
port to other hardware platforms.

Overall the system seems ideal for many
projects needing specialized su{^rt, and
where a 8 bitter will not work. The board
comes with enought sockets for 4MEGs
of RAM, which should be more than
enough for single user projects. Now
0S9 is used in many of the newer
CDROM projects and has been in all the
big name systems, like NASA. It is UNIX
like and a real time system that can
support more than one user. Yet I know
it works well for single users and many
CoCo users fell in love on with their
6809 based systems.

SK*DOS on the other hand is more of a
single user product with it's roots in
FLEX the other 6809 (grating system
of choice. Peter has added some nice
features, like an 6809 emulator that will
run your FLEX code. I plan on trying
that part out and see how it compares
with my GIMIX 6809 system. A good
source of software is the 'C programs
and utilties avaialble from Unix. Many
of these are provided with SK*DOS and
so you get a chance to see how other
code works on this platform.

Closing Words

At this point I leave many items and
topics unexplored, but I will have more
time to devote to this project very soon.
From the hardware side, many compa-
nies are starting to use PC hardware for
their 8 BIT projects. Alternatives to the
Intel CPU's are also out there, the most
common being 68K based mother boards.

What I didn't mention are the numerous
co-processors available and soon multi-
processor system. These systems are of-
ten DSP or Math co-processors that en-
hance the basic PC with more horse-
power of a certain type. There are sev-
eral vendors starting to produce systems
with more than one CPU so that the task
can be brdten up and done in parallel.
Brad Rodriguez's project using 6809's
(on hold while he finishes his degree)
has itself moved to the PC BUS platform
to take advantage of the cheap hard-
ware.

What all the options are giving the user
and designer is the abiltiy to custom fit
any project or task with hardware that
provides the exact range of solutions. In
the past you often simply tossed the same
box at any project and adjusted the soft-
ware to make up for missing hardware
support. Hardware now is so cheap that
it has become more cost effective to cus-
tom fit the hardware than squeeze out
corrections in software.

I hope you found items in this article
that got you thinking. Should you have
more questions, drop me a note or con-
tact the vendors, be sure of course to say
you heard about it in The Computer
Journal.

Star-K Software Systems Corporation,
PO Box 209, Mt. Kisco, New York,
10549, (914)241-0287, BBS (914)241-
3307

The parvus Corporation, 1214
Wilmington Ave., Salt Lake City, Utah
84106, (801)483-1533, BBS (801)483-
1563
parvus@parvus.com

Peripheral Technology, 1250 E. Pied-
mont Rd., Marietta, GA 30062,
(404)973-2156

Z- World Engineering, 1724 Picasso
Ave., Davis. CA 95616
(916)757-3737

20

The Computer Journal / #76

LU

H

>-
O)

(5

<

LU

Q.

o

X

U

05™

0) 03 C
O ^ C

III

e^ !^

— Q. ±-

= " «

E .

CO OJ

DC CC LO .E

DC
O

Q

LU

UJ

CO

ra

M

00

3

CO

>

CO

LU

1-

? CL

CO

CO

<

<a c

CO

-)

£ °

ra

0)

C3

=

T3

Z

F =

13
0)

<

<i> S

-J

^ c^

CO

D

_j

O) m

CO

c/1

<

c in

S

CO

t:

3

z

Q) "^

a

CO

a >.

n

cu

1-

2

-»

in 0)

CO

—

o.

= c

CO

X

LU

3

cn

C Q.
m E

5
<

cr

1

CO (0

CO

CO U)

•0

V ^^

^

3

CO

w
<

LU

a

LU

-I

a

Q.

D
W

o

<

^ ? O , DC

'^ 5 <^ Q- m >

LU D U. < LU Q

> CQ D 5 P g

LU

o<

LLI Z
O

< -' Q. C/3 I-

5§

LU LU

a

Q

>-

Q- D.

O <

O N

<5ODcJg5^Qc0LU
lL ^ 2 DC CO

,CLOm|.

LU .

UjW^LUXQliJ^SDC

f;xo^qS»-o

'-lllI^j?D_"-LU>

Q. O

CL

<

1 >- <

LU —

w

H LU a. 2 O 2
< 2 5 f ^ lu

O Q. 3

< 5 Q

O

< LU

X I

LU

IT
0.

« en's

9 - "

S " 5>

8 « ™

Q. cn CJ

— .y < 5

2 E O "

■■ E S §

« LU 8

O

CM

z s

oc 8 <\.

OC « O 3

O £ 2 "

t- >^0•-
— %2
' n c
= o

i 1^^

k^ O) o 2
Jt c o O

13 g -a

" « g
"^ Z -^

CO tt ii
.i2 cn 5

-I

a c
3 o

cn o

cn°
oj tD "a

'- m X

e E E

o o 9

; CO

C/) c/1 "' *-

^O o O 2

5 Q Q 9 E £■ ^

Q.-D
I?

o g Q " E £■ g

£1^0^'=^; i 8

"O TJ "O U P

« 2 ™ S -^ _ -^

tt) O o O 4) -r- Q)
H -J -I -J O) Li- I

H 13 > 5 X N i>-

0) c/)

IP

X O ^
03m

£ O C31

^ -S 00
S o O

^ e 2

9- CO OJ C

™ £.20
g> -O C3) c

m Jt !! o
>.~ >-S

CCJ ^ ^ 3

■5-5 1=^ S

W oJ W 5
Q to Q cIj

S Z O Q. O DC cn

(0 M

.g « o s g E

o o> E y c CO 5

CO S a 2 F °-<^

S " » S S I =

cn OQ ^O ^ ^

CD O Q ti. CD A ^

LU

H
D
0.

O

o
o

<
o

m

LU

-I

o

z

C/)

I

00
(O

Q.

0)
LU
CC

D
I-
<
UJ

£ o

TJ O

r

0*

N

»

y

0)
M

Z

s

CD

00

3

<
n

«

•D

I

CM

5

cc

Q.

UJ

Si

CO

"o

?

>.

<
rr

CD

CM 3

u

to

O)

E

E
«
E

CO

c

£

o^S

CM

a.

S

CO

CM
CO

u. S

or: k-

r o o

Q. O 'i

3 O .-

C X

k. S
2 2

S CM JQ

o c

M

c t;

— o

1 =■

•r = o)

S 3 -

o S.
>o

cn at
r m
20

o
o

o I 2 a £
* I cd n —
i- N a. u) i

51
>. "•

■a c

m "
*" cn

I- B

X CO

c E
« w
c o

T, I

£ c

I 8 >.

C k. CL
*- O) Q.
» S 3

CD u ^

C O

o ^

= r

^1

« c .
>% O to

t- o »« o

? E S -

O » Q.I-

a. E g X

5 o o r

■" " i °

I r I »

I o E =

CO Q. „ O

o9 £ O

Q. ~ «- «

«, O jq

» « 3 »

.>< o o S

>^

00

'/:

3

t^

X

C^

u

•

T3

W X

rt

H

^

OX"^

•^^

U, 00

H^^

ON

-^

^— ^

^Z

»:;

cf-^

M

Im

O)

^-4

H

00

ITS

P!^

T-H

W

P^

The Computer Journal / #76

21

Regular Feature
Intermediate

Dr. S-100

By Herb R. Johnson

Jade BUS Probe

"Dr." S-100 column for Nov-Dec 1995

Heib Johnson, CN 5256 #105, Princeton
NJ 08543. hjohnson@pluto.njcc.com

Even though my grass is now the height
of the average cat, I've decided to lock
up my mower (at least until the grass
dries!) and sit down and write up some
technology. Many people... well, Bill
Kibler... wanted a write-up of the Jade
Computer Products Bus Probe 1 men-
tioned several months ago. Bill discussed
articles and products with the Jade com-
pare - still in business, but not the S-100
bus business of course. While they did
not want to "release" the designs to the
public d(Mnain nor sell licenses to their
designs, they did allow "non-commer-
cial" use of their materials, for which I
thank them and Bill.

In addition, there is progress on the GIDE
front to report! So no letters this col-
umn, but please tell me what you are
running on your S-100 bus, or what you
are looking for, as I am still getting
boards and systems and reports. And,
now that winter is approaching, I can
spend more time in the basement, .uh,
the Archive Lab... sorting and examin-
ing all this technology.

GIDE IDE hard drive to Z80 interface

After a delay in locating parts, Tilmann
Rei has recently shipped some GIDE
development units to the United States!
I have one prototype already, and should
have more by the time you read this.
And several developers will have them
in their hands from mine. I hope to get
software from them to support the IDE
drive in real machines (Kaypros,
Cromemcos, Zoibas, other Z-80 based
machines) in the near futiue. Then the

"rest of us" can buy and use these de-
vices.

For those of you not famiUar with GIDE,
it is a "Generic IDE" hard drive inter-
face card that plugs into a Z80 socket.

Tilmaim Rei in Germany is the designer
of this card, based on his work two years
ago on a Z180 single-board computer
with an IDE interface using a PAL (pro-
grammed array logic) chip for the logic
"glue" to communicate with the drive.
Several people, including myself, sug-
gested he come up with an independent
interface for aity computer; I suggested
he make it pluggable into a Z80 socket,
and that he add a clock chip for a time
of day clock. A year later, he now has
some prototypes available and have im-
ported a few of these into the United
States. Software, of course, is not avail-
able beyond routines to read and write
the clock and the IDE drive: those who
buy this prototypes must be able and
wilUng to write Z80 drivers and share
the code with others. But I'll include
Tilmaim's IDE articles, and some BIOS
software from other folks for other kinds
of devices like RAM disks, and docs on
the clock chip.

I'm taking orders in the USA at $73
each including the clock chip, deliv-
ered unassembled. You will get a board
and parts, with whatever docs and is
available. If you want details, contact me
(Herb Johnson) via mail, phone, or (pref-
erably) e-mail. If you want information
(two years of Tilmann's TCJ articles on
IDE and earlier GIDE, and descriptions
of the clock chip), send $5. Another $2
gets a disk of whatever software we have
(mostly other people's software on do-
ing various BIOS extensions).

Remember, this is development stuff,
not "plug and play", so if you can't write
Z80 assembly language and don't know
your own Z80 system at the BIOS level,
you will not find this useftil at this time.
BUT, a letter or call showing support
and interest when you CAN use it in
your machine will be greatly appreci-
ated. After we get some useftil software,
and when I can manufactive a regular
supply here in the USA, it may become
a product.

People talk about how hard it is to get
support for their old computers. Well,
here's a chance to show some support!

The S-100 bus and the Jade Bus Probe

Through all my years of S-100 work,
there are two systems everyone knows
about and wants. One is the Altair 8800,
of course; the other is the IMSAI 8080,
Why? Not because they want to toggle
all the binary switches on the front panel,
but because they want to see all the
blinking lights on the front panel! Few
other systems offer this display of ad-
dress and data lines and status signals: a
notible exception is the Ithica
Intersystems model with a really slick
front panel design, including an auto-
matic step-through of the program at a
few steps per second. I think it's one of
the prettiest S-100 systems around (ex-
cept for the choice of dark brown for the
case color!).

But a usefiil alternative to the IMSAI/
Altair front panel was available from
Jade Computer Products in 1981 (four-
teen years ago): the Jade Bus Probe.
Jade moved the front panel from the, er,
front panel, to an extended S-100 card
that elevated the display above the card
cage. In addition, they updated the dis-

22

The Computer Journal / #76

play to siq)port interrupt and extended
addressing. Imagine if you will (or look
at the figures) a display of four lines of
24 LED's- almost 100 indicators - dis-
playing status and data in real time! And
keep in mind that at processor speeds of
only a few megaHertz, it's not just a blur
of activity, but a useAil display of pro-
gram activity! In addition, they provided
some simple controls to deselect some of
these displays, and some "logic bits" for
wiring up additional signals for test and
display.

Some background on the S-100 and
the IEEE-696 Bus

It's been a few years since I've listed the
S-100 bus lines, so let's begin with the
original Altair list of S-100 lines. There
are at least two flavors of S-100 buses:
the original Altair 8800, front-panel
supporting bus and, the IMSAI/
Cromemco bus that eliminated some of
the Altair lines; and the IEEE-696 bus
that expanded the address bus from 16
lines to 24, and allowed 16-bit bidirec-

>

S-100 BUS Standard

PIN

AlUir

IEEE

PIN

Ahair

IEEE

1

+8 V

+8 V

51

+8 V

+8V

2

+18 V

+18 V

52

-16 V

-16V

3

XRDY

XRDY

53

/SSW DSBL

GND

4

VIO

A^IO

54

/EXTCLR

/SCLR

5

VI 1

mi

55

RTC(-)

/DMAO

6

VI2

mi

56

/STSTB(— )

/DMAl

7

VIS

rvu

57

DIG1(— )

/DMA2

g

VI4

rvu

58

FRDY(— )

/SXTRQ

9

VI5

rvi5

59

—

A19

10

VI6

me

60

—

/SIXTN

11

VI7

Nil

61

—

A20

12

—

/NMI

62

—

A21

13

—

/PWRFAIL

63

—

A22

14

—

/DMA3

64

—

A23

15

—

A18

65

—

—

16

—

A16

66

—

—

17

—

A17

67

— (/PHANT)

/PHANTOM

18

/STADSB

/SDSB

68

MWRT

MWRT

19

/CCDSB

/CDSB

69

/PS(-)

ravd

20

UNPROT(T5)

GND

70

ROT(GND)

GND

21

SS

—

71

RUN

rsvd

22

/ADDDSB

/ADSB

72

PRDY

RDY

23

/DODSB

/DODSB

73

/PINT

/INT

24

phi2

phi2,phi0

74

/PHOLD

/HOLD

2J

phil

/PSTVAL

75

/PRESET

/RESET

26

PHLDA

PHLDA

76

PSYNC

PSYNC

27

PWAIT

rsvd

77

/PWR

/PWR

28

PINTE

isvd

78

PDBIN

PDBIN

29

A5

A5

79

AO

AO

30

A4

A4

80

Al

Al

31

A3

A3

81

A2

A2

32

A15

A15

82

A6

A6

33

A12

A12

83

A7

A7

34

A9

A9

84

AS

A8

35

DOl

D01|D1

85

A13

A13

36

DOO

DO0|D0

86

A14

A14

37

AlO

AlO

87

All

All

38

D04

D04|D4

88

D02

D02|D2

39

D05

D05|D5

89

D03

D03|D3

40

D06

D06|D6

90

D07

D07|D7

41

DI2

DI2ID10

91

DI4

DI4|D12

42

DI3

DI3ID11

92

DI5

DI5ID13

43

DI7

DI7|D15

93

DI6

DI6|D14

44

SMI

SMI

94

DIl

DI1|D9

45

SOUT

SOUT

95

DIO

DI0|D8

46

SINP

SINP

96

SINTA

SINTA

47

SMEMR

SMEMR

97

/SWO

/SWO

48

SHLTA

SHLTA

98

SSTACK

/ERROR

49

/CLOCK

CLOCK

99

/POC

/POC

.'"

GND

GND

100

GND

GND

tional data transfers instead of 8-bit uni-
directional transfers. I'll explain some
of this later, but for those somewhat
familiar with the bus already, the list
following represents the lines on these
two very similar buses.

These lines are listed as they appear on
the S-100 cards: with the card's IC's
tops facing you, and the bus coimector
below, the leftmost pin is pin 1, and the
pin on the bade of the card behind it is
pin 51. If you turn the card to its back
where all the IC pins stick out, pin 100
is on the left and pin SO is behind it S-
100 cards are always the same width,
10.5 inches; and almost always the same
height, 6.5 inches. The bus connector is
3.5 inches from the left of the card and
4.5 inches from the right edge of the
card, and the pins are separated by .1
inch center-to-center.

Bus lines: Altair(IMSAI) vs. IEEE-
696

Active low signals are shown as "/".
Unused lines are " — ". Reserved lines
are "rsvd". The first column of signals
are Altair signals; if the IMSAI signals
are different they follow immediately in
"()'; and the next column are the IEEE-
696 signals. Signals on lines 24 and 25
refer to the Greek letter "phi". IEEE-696
signals separated by "|" represent the 8-
bit and 16-bit data path signals, respec-
tively.

The most important thing to remsaiaa
about the S-100 bus, and to a lesser
extent about the '696 bus, is that the
original processor for this bus was an
Intel 8080. All the signals and data lines
on the Altair in particular were to sup-
port this processor. In addition, lines
were needed to support front-panel op-
erations. These two considerations de-
fine most of the signals of this bus. Con-
sequently, one of the best references for
figuring out these signals is an Intel
8080 processor book!

Let's quickly run through the more ob-
vious signals. The power lines are the
voltages as noted: +8, -8, +16, -16 volts.
S-100 cards have on-board regulators to
reduce these to more reasonable +5 and
+ and - 12 volts. The address lines are

The Computer Journal / #76

23

A0, Al, and so on through A15 for the
Altair, and through A23 for the '696.
llie-idata lines are DIO through DI7 for
data to the processor (like IN instruc-
tkx&y, and DOO through D07 for data
fhwn the processor (Uke OUT instruc-
tions). Note for the '696 bus, these uni-
directional lines are optionally bi-direc-
tiotial for 16 bits of data. The vector
interrupt lines are VIO through VI7,
niiibh when active force an interrupt of
the current program and a jump to an
jMarupt support program at a specific
address.
■i ji

We status lines are output from the
processor card, and show the status of
tbe^rocessor. These signals usually be-
gn with "s" and are clustered at the
ri|ht end of the card; such as SMI,
SOUT, SINP, SMEMR, SHLTA,
SINTA, /SWO, SSTACk. These are
available from the 8080 processor as
f^dptesenting processor states as follows:
instruction fetch, OUT instruction, IN
instruction, memory read, processor halt,
iitt6mipt acknowledge, write, and stack
(cespectively). These are sneaky signals
aari should be reviewed more carefully
than I've noted here.
as V

fbe command lines are also output from
iffie^ processor card, and more inunedi-
afi^ control the operation of the bus.
'Biese lines usually begin with "p" and
anqclustered in the center of the card:
PWAIT, /PWR, PDBIN, PINTE,
PHLDA, PSYNC. These represent wait
states (stretched read or write cycles),
write (I/O or memory), I/O input, inter-
nipt enabled status, processor hold ac-
Jtaowledge, and a "sync" signal for the
stait of a processor cycle (re^)ectively).
Additional coimnand lines control the
IHQcessor: /PINT, /PHOLD will force an
interrupt or processor hold condition,
re^jectively.

Uie reset lines /RESET will reset the
piocessor and /EXTCLR will reset other
bus devices, and ready lines PRDY and
XRDY will force the processor into a
IK>LD state. Clock lines phil (removed
from the '696) and phi2 are clocks syn-
chronized to the processor's cycles;
\GIj0CK is a free-running 2 MHz clock
signal. The power-up clear line /POC

will be active (low) during the powering
up of the bus.

The bus disable lines will disable groups
of the above lines: /DODSBL disables
the data out lines, /CCDSBL disables
the command lines, /ADDSBL the ad-
dress lines, /STDSBL the status lines.
Not available on the '696 bus are the
front panel lines: SS for single step, /
SSDSBL to allow the front panel switches
to send their data to the processor;
MWRTTE to control writes to the pro-
cessor. A line "T5" (pin 20) on the
IMSAI that the Altair calls "PROT" uses
to unprotect memory (allow writes) AT
THE MEMORY CARD and which is
complimented by the Altair line PROT
(pin 50) to disable memory writes AT
THE MEMORY CARD (not the proces-
sor). A common problem with IMSAI's
is the use of card that have pins 20 and
50 grounded: they will disable the front
panel! Use a piece of paper to cover
these pins, or cut the grounding traces to
these pins.

There are a handfiil of lines used only by
the Altair for who knows what: RTC,
STSTB FRDRY, DIGl. Note that the
'696 has reassigned them to DMA chan-
nel priority signals DMAl, DMA2,
DMA3; and one of the 16-bit transfer
signals SIXTN. When a 16-bit capable
board receives a /SXTRQ signal from a
16-bit capable processor card, the SIXTN
signal is asserted and the processor turns
the two 8-bit data busses into one 16-bit
bus. Neat, eh?

Whew! Even a brief description of the S-
100 bus takes a few hundred words, and
I'm sure I missed some lines! If this
seems like a busy bus, keep in mind the
IBM-PC ISA bus is 68 pins, so this is
not so many more. And, by the way,
many of these signals have their coun-
terparts on the PC bus as well. After all,
the PC bus was designed for an 8088
processor which is not much different
from the 8080 (he he..).

The Jade Bus Probe

In 1981, Jade Computer Products (of
Hawthorne CA at the time) produced a
card to di^lay the state of almost all of
these bus Unes. As I mentioned initially.

the Probe extends five inches above the
standard S-100 card to display four rows
of 24 LEDs, as illustrated elsewhere in
this magazine. Each LED is connected
to a 2-input logic NAND gate, part of a
74LS38 chip. This provides that one
input of the gate, the signal to display,
must be logically active (a 3 to 5-volt
signal level); and the other iiq>ut is tied
in parallel with several other NAND
gates to related signals, to permit a bank
of common signals to be enabled or dis-
ables as the user desires. Bank selection
of signals will be discussed after the
signals and displays are described.

The Bus Probe circuit board display area
has written titles to describe the signals
displayed, and the display is organized
as follows. The top row shows the 24
address lines, with the most significant
bits (A23, A22, etc) to the left and the
least significant address bits (A2, Al,
AO) to the left. The row below shows the
16 data lines on the right, with the eight
data in lines (DI7 through DIO) in the
center and the eight data out Unes (D07
through DOO) to the far right. If you
review the IEEE-696 bus lines corre-
sponding to these, you will note that the
16-bit data lines use the the DO lines for
the upper data byte (D15 through D8),
and the data out lines for the lower data
byte (D7 through DO) so these '696 sig-
nals are displayed in the prc^r order.
On the far left are the four '696 DMA
lines, titled "TMA" from the IEEE-696
specification. Following these are the
bus disable lines of /DODSB, /SDSB, /
ADSB, and /CDSB for data, status, ad-
dress, and control lines disabling respec-
tively.

The next row of LED's displays (from
left to right) the eight interrupt lines,
the utility lines, and the status lines.

The interrupt lines are as noted on the
bus line list. The utility lines are, from
the left, /INT, /NMI, /PHAN, /HOLD, /
PWRFAIL, /ERROR, /SIXTN, and /
MWRT. The eight status lines are, from
the left, SMEMR, SMI, /SWO, SINP,
SOUT, /SXTRQ, SINTS, and SHLTA.
The status line display is also controlled
by a switch (SI) that supports additional

Continued on page 28

24

The Computer Journal / #76

TCJ Center Fold

special Feature

All Users

JADE BUS PROBE

In this issue we actually do some old machine support, but stay
tuned and look closer at what the Jade Bus Probe does for you.
Herb covered most of the ideas in his Dr. S-100 column. Let
me add that this concept is not limited to S-100 products.

The idea of monitoring what happens on your computers BUS
is not new. The orginal IMSAI and Altair MITS both came
with toggle switches and lights. It was absolutely in^rtant in
the early machines, as this was the only way you had to input
your programs.

We have come a long way since then, but monitoring what
hai^ns on the BUS is just as important. The problem is more
difficult as the BUS speeds increase. Logic analyziers are in
essence doing the same thing as the Jade BUS probe. The main
difference is they can store the several hundred operations in
their RAM and play them back for you one step at a time. The
BUS probe instead has you stepping through your instructions
one at a time and watching lights.

Now the lights do make it more fim to explore what is haj^n-
ing. Not letting that become the main idea, experience will
allow you to get the feeling alxHit whether your program is
Aapp&i or locked up. What I mean is you get to feel just what
a proper working set of lights looks like. Their dancing aroimd
has a real specific pattern and you will get to know it so well
that any changes become quickly a sign that you have pro-
grammed a wrong operation.

Can this design be used on other systems. I see no reason that
we couldn't make systems like this for almost all types of
computers in use today or from the past The main problem is
being able to single step the computer so you can see and read
what is happening. There are many very wonder^ ideas and
designs that have been done to enable non-single stepping
CPU's to do single stepping.

You must understand that some computers CPU's must run at
full speed and any form of stepping through the program will
end up in lost or erroneous data. I have even noticed that a
couple of the newest chip do have single stepping and diagnos-
tics built in, although that is all copyrighted and pretty much
a trade secret. Or put an other way, how to do the operations
and get the data is not possible for us normal people. If you
have figured out some of these secrets and how to single step

the more complex systems, how about an article, were all ears!

What IBM decided to do instead of a front panel or a diagnostic
board like the Jade BUS Probe was to do POST processing.
POST is a series of diagnostic programs run as the system is
powering iq). The results of these test are written out to I/O port
80 on the BUS. This means if you put an expansion card in the
BUS and read the data from I/O address 80, it would be the
results of the variuous tests. Should you have a failure some
where, the test munber would tell you what the problem is. The
solution to the problem is left to you to still trouble shoot on
your own.

I think a combination of the POST and BUS probe are the type
of tools we at TCJ should consider building as a project. A long
time ago I started laying out my own logic analyzer, pretty
much like the one that came along for inserting into the PC
BUS. It basically amoimts to a small bit of RAM that just stores
1 or O's as fast as it can. What my new idea is about is a
combination POST storage reader, say store the last 20 post
instructions. The last 20 to 100 BUS addresses and their data
values would also be needed with the option to trigger either
on or off at some preset address or data value.

So lets look over the Jade BUS Probe, see what it gave us, and
how we might be able to do the same with fewer parts or a
different design. What struck me the most, is just how many
parts are used. You have to remember, that some device must
be used to drive each LED, and there are 100 LEDs! This
means that you need at least 100 buffers or data latches to
isolate you from the BUS. There are 48 (14 pin) sockets used
on the board. Now that is a lot of chips to stick on anything.
And let me say that if ever there was a place for PALs or
Programmable devices with many pins this is one of those
cases. Even still, I think some of the largest parts are about 100
pins, so two parts would be needed, and lots of traces.

I really am serious about needing some ways to checkout
systems. They also need to be simple and possible for others
with limited skills to build. I can think of no other way of
getting new people up to speed, than having them see what
they are doing. The blinkirvg lights can guide the new novice
better than any other idea 1 can think of

The Computer Journal / #76

Center Fold Section

25

*<■**■ ^ ■# <

i

^ uj »/l

J a lO

kUfd

' 'I 'I

'A \\i .

- 1 1. 1 ^

1
___!|

'lll lA i

lAlt^l-d-f

U L,

o a o o Oq oq

Q o o o o

D O O O O O

• 5 ;t;'-: i :iS'; I !!|:r 5:^5^:2 V ?!:--■!: S"^ '': s^^' ^fl^^;'' S'' -.'^ J'^ ''-'-'- fS;:

26

Center Fold Section

The Computer Journal / #76

M

Hi'

1 !o o^f

Hi'

I "A "A £°A?A?As

hA^M

M) bA m

O •-* M

I

fF

o p
^ 1

A'

S3*

'

i

f

H ^

it:

so

u

Q

o 1

M -

I ^
i

as

' li

■

i';

1
JJ

!j

ii

ill
ill

!

I

1 '

1

c

\i_^L-X^-i_i_-^i_i„

S 9 rf * ( f < <f .(^ rf^ rf :V)-

t • . • • . . = • y

t S I

, ~n

«« m ♦

o o o

\ X ^

4

fl

\^

\^

=1 ♦! ,

'r I- I ^

I? 12 J, i:

32

z O a

MM(|(5l (^

The Computer Journal / #76

Center Fold Section

27

logic to select particular processor states
to display by decoding the status lines
for those states. Processor states are Ml,
memory read, memory write, 1/0 read, 1/
O write, "all", and reset.

The bottom row of LED are grouped as
follows, from left to right: power (+8,
+16, -16); "ticks" (a latched version of
phiO and CLOCK), "clears" (/RESET,
/SLAVE CLR, /POC), processor
(PSYNC, /PSTVAL, PDBIN, /PWR,
PHLDA); "wait" (actually "ready":
RDY, XRDY); "X" (a logically gated
"power" signal explained later); and

"patch". The patch display are 8 LED's
which have their N AND gates connected
to a "patch" area on the board (block
X4) for the user to connect to anything
in their system.

Most of the above-mentioned groups of
gated LED displays can be disabled.
Their common gate enabling connec-
tions are routed to a selection block (XI)
of jumpers that can be removed to dis-
able that set of hues. You can leave them
all enabled, to watch the entire state of
the bus; or disable all but a selected set
or two to monitor specific conditions.

There is also a block of jumpers (X2) to
access a 74LS123, a dual monostable
latch or "one-shots", which provide a
pulse when their logical inputs are trig-
gered by a logical event: inputs and out-
puts are to be wared by the user. The
non-defined bus lines are connected to
another set of jumpers (X3).

It is clear that Jade was very thoughtful
in not only providing a controlled dis-
play of the S-100 bus, but also providing
a few simple but useful bits of logic to
display otiier signals from within your
S-100 system.

n

Computer Product*

The Bus Probe "^

^r-^

■««««««

a a aa a ao'

EXIENDED ADDRESS BUS

23 22 2K W^ '9 1« 17

16

IS

a

14 13 >»^-^:tr:=:»:;-=5;:s;»:;l;;;is.«:_

::*iSt^=3-.-.;;2£^;.;:t.-

'/tK

a aja^s 9 ,« ala a

a o e

^ ^ «. «k <*,

TMA tt DISABLI

; HATft IN 1

DATA OUT

13

2 1
a a

^ ^

Mn STH HNl

lla o a I

a !
1

7
a

6 i 5 4 3

a j a a a

2 110^

7 6

a a

H 0^

5

a

4 3 2 1

a o j a a

INTEFRUPIS \

1 UTILITY I

- STATU::;

ii? ! 6 iSiii* :h3r 2;; 1 ;

ila.j a ia M a '1; c ;i a 1: o ^

0:

MI : iHiinuil )wo;I»F;:em;:»tiI mtr

a ;' a ,: o i^ ; o ^!o :^ a i\ o 'i a :'

« il a j; a^i: ;ia ;i ;:« ';■ '.^i' \u \>\

KMl; Ml;

9 i .'

Opal

m;; i.j miij ui;; iitgj uii

y a !i a 1; a 11 a ,»

M: r^i •.!! *J •. '•

c m-a

■ oof a«»tt

t ;

POWER TICKS! CLEARS I fROCESSOfl. WAIT X

28

Center Fold Sertion

The Computer Journal / #76

PC TIME CLOCK

By Terry Hazen

Special Feature

XT Support

Improving Accuracy

PC Real Time Clock chips are notori-
ously inaccurate and can suffer from
severe drift. Many of them seem to lose
or gain time at about 1 to 15 seconds a
day, with 5 or 6 seconds per day being
typical (although the worst one I've heard
of runs 1.5 hours a day fast!) The accu-
racy of the often-used Dallas Semicon-
ductor DS1216E SmartWatch, for ex-
ample, is specified as +/- 1 minute per
month (about 2 seconds a day) at 25C
(77F).

While these clock chips don't keep very
accurate time, they usually drift at about
the same rate from day to day as long as
the ambient temperatiu-e doesn't vary
wildly. If we make the assumption that
the clock inaccuracy is relatively linear
over time, we can improve things quite
a bit by using some simple linear time
correction when we read the clock.

The PC world already has a utility that
does the job. ClockWrighT is an inex-
pensive commercial PC utility that per-
forms linear time correction on IBM-
compatible PC's, but a simple linear time
correction algorithm can easily be imple-
mented for almost any clock chip on
almost any computer, including com-
mon 8-bit CP/M machines.

For example, I used linear time correc-
tion in SCLOCK, a ZCPR33+ Type 3
utility (loading and running at 8000h)
that runs on 8-bit Z80 Ampro or Z 180
Yasbec systems using SmartWatch chips
for timekeeping. It reads and sets the
SmartWatch, displays the corrected
SmartWatch date and time, automati-
cally adjusting for Daylight Savings
Time, and can update the ZSDOS or
BIOS clock with the corrected
SmartWatch date and time.

Biff Bueffel's CLOCK utility also uses
the same linear time correction algo-
rithm to set the MM58167a chip in the
Kenmore Clock, Anapro Clock for the
Heath H89/90 or CDR Super 89 clock.
CLOCK reads and writes directly to the
MM58167 and automatically adjusts for
leap years and for Delight Savings Time.

If you are using an Ampro or Yasbec
system or a Z80 system that uses the
MM58167 clock chip, you can probably
use one ofthese utilities directly. If you
are using a different system, processor
or clock chip and you want to write your
own clock correction utility, read oa..

Clock Accuracy Calibration

Before a correction algorithm can im-
prove a clock's accuracy, that you must
measure its accuracy over time and save
the accuracy history data. You can do
this by setting the clock to an accurate
and consistent time standard, such as
WWV. This must be done twice, several
days to several weeks apart. Within
reason, longer intervals result in better
long-term correction accuracy. The first
time you set the clock, you save the set
time (as WWVl, for example.) The
second time you set the clock, you save
the clock time that is readjust before the
clodc is reset (TIME2) and the new time
to which it is reset (WWV2.)

Now that the clock is calibrated and you
have the accuracy history, you can cal-
culate a simple linear correction factor.
The time baseline is:

BASE = WWV2 - WWVl

and the clock deviation over the baseUne
period is:

DEV = ITIME2 - WWV2I

which is saved as an absolute value. If
the sign of DEV is positive, the clock is
running fest. If it is negative, the clock
is nmning slow. The sign is also saved
so you can determine later on whether to
add or subtract the time correction.

Given the time baseline and the clock
deviation over the baseline period, the
linear correction factor is:

LCF = DEV / BASE

which is the number of seconds of clock
inaccuracy during the clock resetting
baseline divided by the baseline. You
can calculate LCF the second time the
clock is set and save its value for later
use each time the clock is read.

Each subsequent time the clodc is read,
CLKTIM, the required time correction
is:

CORK = (CLKTIM - WWV2) ♦ LCF

The corrected clock time is then:

CORR_TIME = CLKTIM +/- CORR

In other words, take the difference be-
tween the current time read by the clock
and the last time it was set, and multiply
that difference by the linear correction
factor. If the clock is nmning fast, sub-
tract the correction fix)m the current clodc
time. If the clock is running slow, add
the correction. Pretty straightforward
stuff, but surprisingly effective.

The Computer Journal / #76

29

Time Standards

You should consider your time standard
before attempting tocalibrate your clock.
Telq)hone company times may not al-
ways be reliable or even consistant. For
best results, the clock should be set us-
ing a reliable time standard such as
WWV. WWV (Colorado) and WWVH
(Hawaii) broadcast time information on
2.5, 5 and 10 Mhz. WWV also broad-
casts on 20 Mhz. 2.3,5 and 10 Mhz are
allocated by international agreement as
time and frequency standard frequen-
cies, and at least IS other stations broad-
cast time data on those frequencies in-
ternationally.

WWV reports time as Coordinated Uni-
versal Time (UCT), formerly called
Greenwich Mean Time, which is the
time in Greenwich, England. The US
Eastern Standard Time zone is 5 hours
behind UCT. For example, 2 hours UCT
is 21 hours (9pm) EST (2-5[+24]=21.)
Pacific Standard Time is 8 hours behind
UCT, so 2 hours UCT is 18 hours (6pm)
PST.

Time and Date Format

You can simplify the time conversion
code and speed up yoiu* calculations
somewhat l^ using a reduced range of
available correction and assuming the
clodc deviation will never exceed some
fixed number of seconds between the
times you need to reset the clock so that
you can use simple 8 or 16-bit arith-
metic. I chose to get wild and created a
32-lHt binary "Julian Seconds" time and
date format that can be easily manipu-
lated using some 32-bit arithmetic rou-
tines from ZSLIB, one of the wonderful
ZCPR3 series of Z80 routine libraries.

My systems all run ZCPR3 and ZSDOS,
whose system times are usually kept in a
convenient 6-byte "System Standard
Time" (SST) format. The first two bytes
of the SST are the BCD year, month and
day expressed as a Julian date, which is
defined as the number of days el^sed
since January 1, 1978. Converting the
current year, month and day to the Julian
date is easily done with the BCD-to-
Julian routine from the NZTIM library.

Converting to Julian Seconds just in-
volves converting days and hours to sec-
onds with several simple multiplications.
The resulting 32-bit Julian Seconds times
can then be easily manipulated with the
32-bit addition, subtraction, multiplica-
tion and division routines from the ZSLIB
library.

Clock Accuracy History

The accuracy history for each physical
clock needs to be stored for later use by
the correction algorithm. Because each
clock chip will have a different accuracy
history, only that specific clock chip can
be corrected using its history data.

Some chips have several bytes of inter-
nal nonvolatile SRAM available to the
user which can be used to store the his-
tory data. If like the Smart Watch, yours
doesn't, the accuracy history can be
stored in a one-record history file for
each clodc to be corrected, or in one
record of the clock utility file itself.
SCLOCK, for example, stores the his-
tory data in its first record, which is
updated and rewritten each time the clock
is set from WWV.

Bells and Whistles

While you're at it, you can also provide
some other useful date and time ser-
vices. Some clock chips already have
DST correction available, but if yours
doesn't, you can test the date and correct
to Daylight Savings Time when it's in
efTect between the first Sunday in April
and the last Sunday in October. While
the SmartWatch already takes care of it,
you can also correct your clock for leap
year.

Results

I use several SmartWatch chips that vary
considerably in accuracy. I've used the
SmartWatches in my 8mhz Ampro and
1 8mhz Yad)ec as my SCLOCK test beds.
I calibrated both the Ampro and Yasbec
SmartWatches by seting them just after
Thanksgiving and again on New Years,
35 days apart. In the 42 days since then,

the Ampro SmartWatch has gained 108
seconds and the Yasbec SmartWatch has
lost 97 seconds, but the corrected times
for both SmartWatches remain within 1
to 2 seconds, which is within the normal
SmartWatch read-jitter. Your results
will probably vary by chip type and
ambient temperature variation.

References

1) DS1216E SmartWatch data sheet,
Dallas Semiconductor (1-800-336-6933.)

2) ClockWrighT, Barberry Hill Software
and Engineering, 26 Barberry Hill,
Woodstock VT 05091-1269.

3) Jeff Bachiochi, "A Comparison of
Real-time Clocks", The Computer Ap-
plications Journal, Issue #52, November
1994.

4) Michael A. Lombardi, "Keeping Time
on Your PC", BYTE, October 1993.

5) SCLOCK20.LBR, CLOCK25.LBR
(both libraries include the source code)
and the ZCPR3/ZSD0S REL library
series, including, but not limited to,
LIBS45A.LBR (containing SYSLIB,
ZLIB, VLIB and DSLIB),
ZSLIB36.LBR, NZTIM12.LBR and
PDAT13.LBR (source code for these li-
braries is included or is available in sepa-
rate libraries) are available on Znode #2,
Los Angeles, CA (3 10)670-9465 or your
favorite local Znode. If you're a Z80 or
Z180 assembly language programmer
and haven't taken advantage of these
rich sources of well-tested Z80 REL rou-
tines, do yoiu^lf a favor and check them
out!

30

The Computer Journal / #76

PC Security System

By Michael Krabachi

Special Feature

XT Support

XT and Basic

While I have not engaged in 8 bit ma-
chines lately, I still keq) them for his-
toiy and they all tell a stoiy. The best is
the SB 180 which is built into a WWII
range finder box. The B&W monitor is
built with plexiglas and aluminum perf
board. It would fit right into a 1930's
Buck Rogers movie.

Any way... my latest project was build-
ing an alarm system using a I/O board
given to me by a fiiend. The Micromint
68HC1 1 was to be the core of the alarm
system, but I was going to have to build
TTL interfacing and I didn't have the
time before I was to leave for vacation.
So the initial alarm system was built
around the PC and the Metrabyte I/O
board. When I got back, the system was
cleaned iq), dd>ugged and set up as a two
tier system to prevent false alarm. After
a year of no false alarms and many en-
hancements the system is pretty much
finished.

While this is not an 8 bit project, it is a
hardware/software project and it sure has
taught me alot of subtle tricks in design-
ing a polling program. I have used
PowerBasic 3.0 which sure is nice com-
pared to QuickBasic. It has bit opera-
tions which were necessary for the kind
of control I needed for the I/O board.
Feel fi"ee to run with the program, and
see if you can play Break-In and not get
caught.

The Hardware

The hardware consists of a Keithly
Metrabyte 8 channel isolated relay in-
put/output interface board (Model
PDISO-8). This board plugs into the
ISAbusofa typical IBM type PC. There
are many similar I/O boards that are
modeled after the Metrabyte configura-

tioa Any of the similar interface I/O
boards can be used as long as it con-
forms to the method of accessing the 1/
O board. No special drivers are re-
quired. The board occupies 4 consecu-
tive addresses in the PC I/O address
space, of which only 2 are actually used.
The base address is set up with a dip
switch on the I/O board and again de-
fined in the control program. It can be
any port address from 100 to 3F8. While
port 300 hex is the default address
shipped with the board, I used 280 hex
because when the PC boots up one of the
bits goes high at address 300 hex and the
alarm bell sounds.

The I/O board consists of 8 individually
optically isolated inputs which can ac-
cept AC or DC from 5 to 24V rms.
These inputs are not TTL/CMOS
compatable, so they are easily operated
with on/off switches such as magnetic
reed switches or pressure contact micro
switches.

The 8 individual output rel^s are ca-
pable of handling 3 A at 120 vac or 28V
DC resistive load. Five of the relays are
bipolar (type C) and can be used as nor-
mally open or normally closed, while
the other 3 are normally open (type A)
only.

Both the isolated input and relay output
ports are controlled with an 8 bit byte
with each bit corresponding to each in-
put or output. The bits are controlled by
writing or reading directly to the port.
The base address (280h) controls the
ou^ut which can be either read or write.
The base address plus 1 (28 Ih) is the
input which is only a read address.

The I/O board itself has a DB-37 pin
connector that is e)qx)sed at the back of

the PC when plugged into the ISA bus.
The pins are grouped logically so that a
37 wire ribbon cable can be used to con-
nect to a IDS type dual row standard 1/
10" pinned connector which then con-
nects easily to a standard 1/10" perfo-
rated circuit board. For this system,
standard off-the-shelf components were
used to design a small adapter board to
accq}t the input wires from the sensors
and direct the output wires to the light
control and alarms.

INPUT SENSORS

Each of the 8 ii^ut lines consists of a S
voh circuit with a LED to indicate when
the circuit is closed. Closed is consid-
ered the normal non-alarm mode since it
gives a positive indication that an alarm
sensor is operable. When all input LEDs
are on, the system is active and in a non-
alarm conditioa The LSD (least sig-
nificant digit) bit is controlled by a mi-
cro switch attached to the kitchen
deadboh lock. When the door is locked
the system is activated and all sensors
circuits are continually scanned for an
open circuit which would indicate a house
break in.

A local control panel which contains
indicator LEDs, has 8 local three way
toggle switches which are in parallel
with the 8 individual sensor circuits.
These are used to deactivate any single
sensor or to open the sensor circuit to
test the alarm system.

The actual sensors consist of two types.
The windows and doors are wired in
series using trip wires on the windows
and magnetic sensors on the doors. The
trip wires are such that they will be
broken by either opening or breaking the
windows. Since the downstairs win-

The Computer Journal / #76

31

dows are never qiened, this system works
ok. Upstairs the windows are on mag-
netic sensors. The rooms of the house
are scanned by passive infrared dectectors
(PIRs).

The PIRs are constructed from common
Zenith FIR wall switches. The FIR, a 2
receptacle wall sockd and a 120 VAC
(Radio Shack) relay are packed in a com-
mon plastic wall junction box such that
when the FIR is actuated the rel^ is
(^)ened and the signal is broken with the
alarm controller. The Zenith units re-
quire a load to operate so a small 40 watt
reflector bulb is installed in one of the
receptacle sockets. The FIR can be ad-
justed for daylight intensity so that they
only operate at night or all the time. A
side benefit is that they fimction as auto-
matic night lights. The alarm is not
tripped because the iimer FIRs only come
into play when the outer window or door
perimeter is brdcen. This double layer
of secuity prevents false alarm.

OUTPUT CONTROL

The five bipolar output relays control 5
vdc which is used to power solid state
120 vac relays that in turn control 4
house lights. The fifth relay controls
another solid state relay that activates
the house stereo system to play a mes-
sage to anyone in the house at the time
of the alarm. This can be used for psy-
chological warfare against the burglar
in the mildest sense. It could also be
used to control an automatic phone dial-
ing machine if desired. The other three
output relays are used to supply 12 vdc
to control a bell and two separate 2-tone
power horns. Since the 1st five bits
control bipolar relays, the normally
closed contacts sui^ly 5 vdc to individial
circuits that have LEDs. In this case the
LEDs are on when the respective house
lights (and stereo system) are off. There
is no LED indication for the three alarms
operated by the type A single pole re-
lays.

X-10 MODULES

The output control which is normally
handling the house lights and alarms via
a hardwired circuit, also operates up to
8 X-10 light or appliance modules. The

operation is done with a Circuit Cellar
PLIX module (Power Line Interfece) and
anX-10 TW523 orPL513 module which
sends the signals to the X-10 Ught mod-
ules. The imit is attached to any stan-
dard unidirectional parallel printer port
on the PC. This unit is available from
Micromint, Inc. as a Demo Kit. This
could be used as input if desired, al-
though I prefer using hardwired input
signals.

The system will function without the
PLDC controller.

TEMPERATURE MONITORING

Tenq)erature is monitored through the
PC's Game Port Since a game port
paddle is a pseudo analog input that
measures dual axis lOOK ohm potenti-
ometers, it is simple to install lOOK ohm
thermistors in place of the pots. Cali-
bration is performed with a decade resis-
tance box and a Steinhart & Hart cali-
bration equation. The result is a cheap
ten:q>erature monitor. The accuracy is
about 2 degrees, but so far (for some
reason not understood,) it tends to drift
several degrees over several months.
Sometimes it even drifts back ! Since the
game port has two inputs, 4 tempera-
tures can be measured, one for each floor
of the house and one outside.

SOFTWARE

The control program basically runs in a
loop that continually scans all the input
sensors. If any of the sensors indicate a
non-normal condition, some or all of the
alarms are sounded. While scanning the
sensors it also compares the time since
midnight against the light control
setpoints. If the time is within a setpoint
window, a light is either turned on or
off.

OPERATION

The easiest way to see the operation of
the system is to run the actual software.
The program ALARM12.EXE and
ALARM12N.EXE (for systems with no
coprocessors) is designed so that all the
input functions can be emulated by the
keyboard. All the functions can operate
in real time or compressed time. Com-

pressed time condenses 9 hours into about
2 minutes. The system has two help
screens (Alt-H and Alt-J) to explain the
operation.

The system does not use a key pad to
arm and disarm the alarm system. In-
stead a key switch on the kitchen door
deadbolt lock is used to arm the system
when the door is locked. Unlocking the
door deactivates the alarm system. A
time delay is built into the keyswitch to
prevent felse alarms. The perimeter cir-
cuit is also associated with the keyswitch
so that the keyswitch wires can not be
cut without causing an alarm condition.

If you have a game port on your PC with
a joy stick plugged in, you will see the
temperature monitoring function, al-
though with imrealistic results. For the
temperature function to operate you must
have the file TEMF.INI, which supplies
thermistor caUbration data, in your de-
fault directory. All temperature data
will be saved in an ASCII file
TEMP.LOG.

The program will also record all input
and output, (optionally light control) in
an ASCII file HOUSE.LOG. Each time
a sensor event occurs a menu screen
dump will be made to a binary file
MENU.LOG which can be viewed later
with SEEMENU.EXE.

The purpose of the log files is to not only
preserve what happens during a break-
in, but to allow someone to dial into the
house and view the status of the control
and alarm system. In my system the
alarm computer is connected to a second
computer via peer-to-peer LAN which
has a modem. An alternative would be
to use a multitasking system such as OS/
2 for both the alarm system and the dial
in capabihties. Under any system that
takes time slices on the CPU, the game
port will not operate as consistently.

These programs written by;
Michael Krabach
747 Nate Whipple Hwy
Cumberland, Rl 02864
ph 401-333-5350

Available on TCJ BBS as Alarml2.zip.

32

The Computer Journal / #76

First few pages of Alarmll.BAS

'Home control and alarm system using a Metrabyte PDISO-8,

' an 8 channel Isolated relay Input/output interface PC board.

' With the following revisions;

' an autodialer or spealcer warning using control bit 4,

' wtth enhanced software testing mode,

' wtth IR sensors dependent on activating vi/indow/door sensors,

' wtth three seasons for timing lighting control,

' wtth autoscaling test mode,

' wtth remote access to copy of display menu,

' wtth auto select season,

' wtth 4 sensor temperature monttoring thru game port,

' wtth optkxuil event logging to printer.

' wtth Individual thermistor calibration

' added PLIX controller for X-10 modules, rev 12, 4-6-95

'Copyright, (c) Michael Krabach, 1994
'Wrttten In PowerBASIC 3.1

$EVENT OFF
rev$=''rev12a''
revdate$="4-16-95"

'The I/O output Is attached to the Interface board as:

' btt living room

' btt 1 kttchen

' btt2backroom

' btt 3 bedroom

' btt 4 aux alarm, eg. autodialer or speaker waming

■ btt 5 bell

' btt6hom1

' btt7hom2

'The I/O Input (sensors) Is attached to the interface board as:

' btt kttchen door keylock microswttch

' btt 1 downstairs windows and doors using magnetk: reed swttches

' btt 2 upstairs windows using magnetk; reed swttches

' btt 3 upstairs spare room, and bedroom passive iR sensors

' btt 4 living room passive IR sensor

' btt 5 dining room passive IR sensor

' btt 6 kttchen passive IR sensor

' btt 7 back room passive IR sensor

'Note any variable dealing wtth time has been given a prefix t.

DEFINT a,c,d,e,f,h,i,l,n,p,q,s,u,w,x,y 'integer variables

DEFSNG o.t,r

'single preclsnn

DIM b(4), m(4)

'for ohms from game port

DIM rcoefa(4), rcoerb(4), rcoefc(4) 'for steinhart calibratkin

DIM degFI (4), degF2(4), degF3(4), degF4<4) 'for summing temps

'Set up control setpoints for the seasons.

GOSUB checkseason 'find out wfiat season tt is

setseason:

season$^emp$ Iransfer string

SELECT CASE season$

'Winter setpoint schematic: (EST)

'12hrck)ck 3 4 5 6

7

8 9 10 11 12 1am

'24hrckx:k15 16 17

18

19 20 21 22 23 24 01 hrs

' normal mode |...|...|...|.

1

...|...|...|...|...|

'kttchen 7

-7 7—7

'back mn 7

-7

7 d

'living rm 7 —

7 7— d

'bed mi

d— 7

'clear lights

X

'test mode |...|...|...{...|

i

I...I...I...I...I

' seconds 10 20 30 40 50 60 70 80 90 100

CASE "-Winter-"

•Winter setpoints:

tkttchon=16.00

'kttchen on 4:00 pm

tkttchoff=19.30

'kttchen off 7:30 pm

tkttchon2=21.00

'kttchen2 on 9:00 pm

tkttchoff2=21.45

'kttchen2 off 9:45 pm

tbackmfion=16.45

'backroom on 4:45 pm

tbackrmoff=18.30

'backroom off 6:30 pm

tt)ackrmon2=20.15

'backroom2 on 8:15 pm

tbackrmofr2=23.00

'backroom2 off 1 1 :00 pm

tlivnTKXi'18.00

'living rm on 6:00 pm

tllvnTioff«21.15

'living nn off 9: 15 pm

tllvrmon2=22.00

'living rm2 on 10:00 pm

timeclearsl.15

lum off any extraneous lights at

1:15am

tvariatk>n=0.30

'max random variation to setpoint In

NEWTIME

GOTOcont

'Spring setpoint schematk:: (EST)

'12hrckx;k 3 4 5 6

7

8 9 10 11 12 1am

'24hrctock15 16 17

18

19 20 21 22 23 24 01 hrs

' normal mode |...|...|...|.

1

|...|...|...|...|...|

'kttchen 7

7 7 7

'back rm

7-

7 7-d

'living nn ?-

—7 7 d

'bedrm

d— 7

'clear lights

X

'test mode |...|...|...|...|

1

.i...i...l...i...i

' seconds 10 20 30 40 50 60 70 80 90 100

CASE "-Spring-"

'Spring setpoints

tkttchon=17.30

tkttchoff=20.15

tkttchon2=21.00

lkttchoff2=22.15

tbackrmon»19.45

tbacknTioff«21.45

tbacknnon2>22.30

tt)ackrmofr2*23.00

tlivrmon=18.45

tlivnnoff»20.30

llivrmon2=21.30

timeclear>=1.15

tvariatk>n=0.30

GOTOcont

'User defined setpoints and delay intervals for normal light control.
' Some of these setpoints may be advanced by the NEWTIME routine.
' The folkswing setpoints are in 24 hour time (hr.min format).
' Kttchen, backroom, and living room lights are operated twk^e dally.
' The computer ck>ck needs to be adjusted for Daylight Savings Time.

The Computer Journal / #76

33

'Summer setpoint schematic: (EOT)

'12hr clock 3 4 5 6 7 8 9 10 11 12 1am
'24hrclock15 16 17 18 19 20 21 22 23 24 01 hrs

'normal mode
'kitchen
't)ackrm
'Nvlngrm
'k)ed rm
rlights

,.|...|...|.

7— ? 7 7

7 7 7-cl

7— 7 7-d
<*— 7

■econde 10 20 30 40 50 60 70 80 90 100

CASE "-Summer-"

tkllchon-20.00

tkllchorr-20.45

tMtchon2-21.30

tkitchorr2-22.45

tlMCkmfK)n-20.1S

ttMCkrmorr-21.45

tt)ackrmon2>22.30

tb«cknTK>n2>23.00

tllvrmon-21.15

tHvnnoff-22.00

tNvmK>n2-20.30

timeciaar-1.15

tvariatk)n-0.30

GOTOcont

'Fan setpoint schematk:: (EDT)

'Summer setpoints

'12hrck>ck 3 4 5 6 7 8 9 10 11 12 1am
'24hrckx*15 16 17 18 19 20 21 22 23 24 01 hrs

• normal mode |...|...|...|...!...|...|...|...|...|...|

'kitchen
'backnn
living rm
'k)ed rm
'dev lights
'test mode

7—7 7 f

7 7 7-d

7 7 7— d

d-7

X

10 20 30 40 50 60 70 80 90 100

CASE "-FaH-" 'Fall aetpoints

tkitchon-19.1S

tkitchofr-20.1S

tkitchon2»21.00

tkitchon2>22.15

tt>ackrmon>20.15

tt)acknTK)ff=21.45

tt>ackrmon2*22.30

ttMckrmoff2-23.00

tlivrmon'20.00

tlivrmoff«21.15

tlivrmon2«22.00

timeciear>1.15

tvariatk>n>0.30

cont: 'For ail seasons

'User defined delays in seconds referenced to a prevkxjs setpoint.
tdeiaylivrmoff2s1 '2nd living rti off 1 seconds after 2nd back room off
tdeiayt>edrmon>:8 'tiedroom on 8 seconds after 2nd living room off

tdelayl)edrmoff»60 'Ijedroom off (minimum of) 1 minute after light on

END SELECT

twaltwint)ad=60 'delay tjetvreen event and ignoring windowf sensors
talmoffdelay=300 'delay tjefore shutting off alarms after cleared (5 min)
tdcwncount=60 'initial starting dovm-counler for bell repeat sequence

' this number only valid vvith delay 1 in scanloop
' note since integer, dovmcount can only can be <=32000
tdeiaytemp=900 'read house temperatures every 1 6 minutes,

' to be recorded at 4x interval

'Test mode setpoints generated from above seasonal setpoints.
' Tlie setpoints are adjusted to seconds from ttie start of the test.
' This sequence simulates the real control cycles in compressed time.

testkKchon-INT(makesmall(thrtosec(tkitchon))) 'kitchen on (F2)
testkitchoff=INT(makesmall(thrtosec(tkitchofO)) 'kitchen off
testkitchon2=INT(makesmall(thrtosec(tkitchon2))) 'kitchen on (F2)
testkitchoff2=INT(nfakesmall(thrtosec(tkttchofr2))) 'kitchen off
testbacknTK)n=INT(makesmall(thrto8ec(tbackrmon))) 'back room on (F3)
testbackrmoff=INT(makesmall(thrtosec(tbackrmoff))) 'back room off
testbacknnon2=INT(makesmall(thrtosec(ttiackrmon2))

'back room on (F3)
testbackrmoff2=INT(makesmall(thrtosec(tbackrmoff2))) 'back room off
testllvrmon=INT(makesmali(thrtosec(tllvrmon))) 'living mi on (F1 )
te8tllvrmoff=INT(makesmall(thrto8ec(tllvrmofO)) 'living mi off
testiivrmon2-INT(niakesmall(thrtosec(tlivrmon2))) 'living rm on
te8ttimeciear>INT(makesmall(thrtosec(tinieclear)4'86400))

lum off any lights still on
testvariatk>n=INT((tvariatk>n/0.06)'M) 'max random variatk>n to

setpoint in NEWTIME

'User defined test delay seconds referenced to a prevk>us setpoint.
testdelaylivrmoff2=3 '2nd living rm off after 2nd k>ack room off (F1 re F3)
testdelaybedmfK)n=3 'bedroom on after 2nd living rm off (F4 re F1 )

testdelaybedrmoff=8 'bedroom off after light on (F4 re F4)

'User defined alarm delays In seconds for the test mode.
testyrattbell=5 'delay betvi«en event and bell sounding
testwaithom1=10 'delay between event and bell and horn sounding
testwatthom2=1 5 'delay between event and all three alarms sounding
testwaitaux'25 'delay between event and aux alarm
testvMiitwinbad-2S 'delay between event and ignoring window sensors
testalnioffdelay°5 'delay before shutting off alamis after cleared
testdowncount=5 'initial starting dovm-counter for bell repeat sequence

' this number only valkj with delay 1 in scanloop
testdelaytemp=7 'read house temperatures every 7 seconds,

' to be recorded at 4x interval

'Addttkxial definitions.

bbase-&h380 'base port address for PDISO-6 I/O card

' note that base &h300 comes up on reboot with bell on!

%AX=1
%BX=2
%CX«3
%DX=4

'Equates for temperature measurments

FUNCTION thrtosec(thrs) 'convert hrs to seconds after midnight

thrtosec=INT(thr8)*3600+FRAC(thrs)/0.6*3600
END FUNCTION

FUNCTION makesmall(tsecond)

'convert setpoints to Inten/al for test mode
makesmall=(tsecond-54000)/360
END FUNCTION

'User defined alarm delays in seconds for normal operatkxi.
tvMiitbell»5 'delay between event and bell sounding

twaithomi "1 'delay between event and bell and horn sounding
tvraithom2«1 5 'delay betvi«en event and all three aiamis sounding
twaitaux'60 'delay betvt«en event and aux alarni (alk>w pir's to clear)

34

The Computer Journal / #76

'Set up sounds for alarms.

PLAY "mb" 'play In background thru buffer

bellsound$= 1240 164 04cc.cc.cc.cc." 'a bell sound

hornl sound$='t200 18 03gc" 'a horn sound

hom2sound$='1200 18 03a-d-' 'another horn sound

dlalsound$=1200 132 03dgdgdgdg" 'a phone ringing

KEY (24) ON
KEY (25) ON
KEY (26) ON

'Set up function keys for key trapping
KEY 15, CHR$(&h08, &h02, &h70)
KEY 16, CHR$(4h08, &h03, &h70)
KEY 17, CHR$(4h08. &h04, a,h70)
KEY 18, CHR$(&h08, 4h05, &h70)
KEY 19, CHR$(&h08, &h06, &h70)
KEY 20, CHR$(4h08, 4h07, 4h70)
KEY 21 , CHR$(&h08, 4h08, 4h70)
KEY 22, CHR$(4h08, 4h09, 4h70)
KEY 23, CHR$(&h08, 4h23. &h70)
KEY 24, CHR$(&H08, 4h0b, 4h70)
KEY 25. CHR$(4H08. 4H24, 4H70)
KEY 26, CHR$(4H08, 4H19, 4H70)

ON KEY (1) GOSUB testliving
ON KEY (2) GOSUB testkitchen
ON KEY (3) GOSUB testbackrm
ON KEY (4) GOSUB testbdmi
ON KEY (5) GOSUB testaux
ON KEY (6) GOSUB testbell
ON KEY (7) GOSUB testhomi
ON KEY (8) GOSUB te8thom2
ON KEY (9) GOSUB zero
ON KEY (10) GOSUB shutdown
ON KEY (1 1 ) GOSUB showtog
ON KEY (12) GOSUB settest
ON KEY (13) GOSUB setfakesensor
ON KEY (14) GOSUB k>glights
ON KEY (15) GOSUB bitOon
ON KEY (16) GOSUB bitlon
ON KEY (17) GOSUB bit2on
ON KEY (18) GOSUB bitSon
ON KEY (19) GOSUB bit4on
ON KEY (20) GOSUB bitSon
ON KEY (21) GOSUB bit6on
ON KEY (22) GOSUB btt7on
ON KEY (23) GOSUB help
ON KEY (24) GOSUB deletek>g
ON KEY (25) GOSUB help2
ON KEY (26) GOSUB printevents

KEY (1) ON
KEY (2) ON
KEY (3) ON
KEY (4) ON
KEY (5) ON
KEY (6) ON
KEY (7) ON
KEY (8) ON
KEY (9) ON
KEY (10) ON
KEY (11) ON
KEY (12) ON
KEY (13) ON
KEY (14) ON
KEY (15) ON
KEY (16) ON
KEY (17) ON
KEY (18) ON
KEY (19) ON
KEY (20) ON
KEY (21) ON
KEY (22) ON
KEY (23) ON

'attplusll KEY
'alt plus e2 KEY
'alt plus #3 KEY

'alt plus $4 KEY

'alt plus %5 KEY

'alt plus *6 KEY

■alt plus 47 KEY

'alt plus *8 KEY

'alt plus H key

'alt plus )0 KEY

'alt plus J key

'alt plus P key

lum on living room light
lum on kitchen light
1um on back room light
lum on bedroom light
lum on aux alarm
lum on bell
lum on horn 1
lum on horn 2
lum off all output, and reset flags
'exit program
'show the k>g file
'setup kx»l setpoint test
'fake sensor test setup

loggle the bit
'etc.

'delete the house.k>g file from menu
'spare help file

'Reset all flags and variables.

GOSUB getini get calibratkxi data for temperature measurements

CLS

GOSUB rindplix

'start with clean screen

'Also is restart point for testing light control.

restart: 'reset Indivklual sensor event flags

flagl^
flag2=0
flag3^
f1ag4sO
flag5-0
flag6=0
flag7=0

flagtest=0
talmla^
talm1b=0
talm2a=0
talm2b^
talm3a=0
talm3b=0

twait»0

tevent^

sensor2-2S5

for sensor on btti (bitO Is not a sensor)
'for sensor on bit2
'for sensor on b(t3
'etc.

'used to inttiate light test only once while in scankx)p
'reset alarm level 1 event start
'reset alarm level 1 event cun-ent time
'ditto for alarm level 2

'ditto for alarm level 3

'zero time delay to shutoff the alarms

'zero common time for all alarm levels for twalt test

'set to assume all circuits are ck>sed

'Set up base light control times for real and test mode.

IF kx^ttest^} THEN GOSUB tbase ELSE GOSUB testtbase

GOSUB zero 'reset output ports and generate light control times
count5=5 'Specific reset to prevent 5 sec delay from causing alarm
' w^n door Is open, while booting computer.

GOSUB readscreen

'save a copy of the display screen.

'Start of scanning toop

$EVENT ON 'start key event checking, during compiling

scankx>p:

DELAY 1 liming delay for accurate test timing and cyclebell

this also helps prevent bad cursor placement on screen

'Save copy of display menu to screen.k>g after a sensor or control event.
IF okJcount<>count OR okicount2<>count2 THEN

GOSUB readscreen
okkx>unt>count
okkxxint2>count2
END IF

'Save copy of house temperatures to temp.k)g every delaytemp Interval.
IF kiopcount >* delaytemp THEN

GOSUB readtemp

kMpcount^)
END IF

■NCR k)opcount

IF k)gflag=1 THEN GOSUB readk)g 'show k)g only at this point In code
IF flagtest-1 THEN GOTO restart 'restart if doing kxal light test
'Screen menu for testing the light and alami control.
COLOR 9
LOCATE 1 ,5
PRINT "===«== HOME CONTROL AND ALARM SYSTEM »«=«»«»»•

End of UtVng lor TCJ

The Computer Journal / #76

35

Regular Feature

68xx/68xxx Support

C & Assembly

Small System Support

By Ronald W. Anderson

Good griefl I am so far ahead with these lessons that they will
be <dd when you get to read them. I will keep them and do some
touch up before they are mailed to TCJ. First let's look at the
next lesson in C programming.

C Tutorial #5

This time we have a few little items to clean up. First let's look
at fimctimis again briefly. C fimctions can "return" a value to
the calling function. In some cases it is obvious that this is the
case. For examine, how would a function like getcharQ be of
any use if you didn't get some value bade from it.

char ch;

ch = getcharQ;

When you define a function you generally have to declare the
type of the value that is returned:

double sin(angle);
double angle;
{

}
char getcharQ;

The first is an exanq>le of a fimction that has a value passed to
it and also returns a value. The trigonometric functions are
defined in math.h, part of the standard Ubrary. All arithmetic
in C is done in double format. If you use a function that retiuns
a double but assign the result to a float type, half of the digits
are simply thrown away!

The second example is a Amotion that returns a character. If a
function returns an integer you don't need to declare that fact
explicitly since it is the default, but you may and it is a good
idea since it is a double check that you have declared the type
of the return value of all fimctions in yaai program. Since no
return type means integer, ANSI C wants you to tell it that your
function doesn't return any value by using the keyword "void".

Many of the standard library functions return a value (which,
incidentally you can use or you can ignore). Some of them
retiun a value that can be used to indicate the success or the
failure of the fimction to do what was requested. For example

there is a function called mallocQ which allocates memory to
a program. Such memory can be used and deallocated within
the program so it is a form of memory management. If you
want to allocate a block of memory, malloc returns the address
of the first byte of the block. If for some reason malloc can't
allocate the requested memory it returns or NULL. You can
test for null to see if the fimction was successful.

A more commonly used function is one to open a data file. It
also returns an address in memory where the file handling
takes place. If the file couldn't be opened (e.g. you tried to open
a file for read, but it didn't exist), the fimction returns NULL.
The file opening function is "fopenQ" It requires two param-
eters, a filename and a mode, infile = fopenC'data.dat","r");
This opens a file named data.dat for reading (use "w" for
writing). If it is successful it returns an address that is assigned
to "infile". Infile is a pointer to a file, a topic we will cover
later. We can detect the error and exit the program. If I am in
a hurry doing a one of a kind quick filter program for my own
use, I sometimes assume there won't be any errors, and don't
test for them. If the program is going to be used for a while, I
will add the error testing and handling code as well.

A "filter" program by the way, is one that does some transfor-
mation on an input file and writes the result to an output file.
A filter may be as sin:^)le as a program that converts all upper
case alfa characters to lower case or vice versa. It might convert
all tab characters to three spaces. Perhaps it would find linefeed
carriage return combinations and delete the linefeeds, etc. A
filter is not necessarily limited to working on a text file. It could
just as well read a file of floating point numbers and convert
them from one format to another.

infile = fopen(data.dat,"r");
if (infile = NULL)

{

printfC'Can't open the input file\n");

exit(l);

}

Exit is another fimction in the standard library. In some cases
when multiple programs are being run returning the value 1 for
an error or for a suocessfiil completion of a program is useful
to the operating system. ("Some cases" basically means UNIX
systems).

36

The Computer Journal / #76

The "return" mechanism only allows for one value to be
returned. If a function must return more than one result a
different method must be used. We will get to one of those
methods shortly when we discuss pointers. A simple possibility
that might be ai^>ealing on first thought is to use global
variables, ones accessible by both the calling program and the
function, and simply have the function assign it's multiple
results to multiple global variables (pricisely how BASIC does
it). A bit later we are going to talk about the "scope of vari-
ables". At that time we will discuss why this is a messy solution
that can lead to serious "side effects" that can make a program
hard to dd>ug.

Assignment Statements Revisited

We discussed assigiunent statements earlier. We didn't men-
tion a coiq)le of things about them. First, you can stack assign-
ment statements, for example to initialize a bunch of variables
to zero.

a=b=d=y=q=0;

The assignment works from right to left so it puts in q and
then the value of q in y etc.

The second thing about an assigiunent statement is that the
statement itself takes on the value of the assignment. For
exanq>le the statement (a=3) has the value 3. That is why so
many new C programmers get tripped up by the "=" compari-
son:

if (a=3) is guaranteed to be TRUE ALWAYS, since it is
assigning the value of 3 to a Since 3 is not equal to zero, the
statement a=3 is always TRUE.

if(a==3) on the other hand is a valid comparison test.

Since the first construct if(a=3) is syntactically correct, it is not
an error, but generally it is not what you wanted to do. Turbo
C issues a warning that says "Possibly incorrect assignment
statement" or something close to that.

Is there a place where you might want to use this value of a
statement?

while((ch = getc(infile)) !=EOF) putc(ch,outfUe);

The statement gets a character from the input file and tests the
value of the character (i.e. the value of the assigimient state-
ment) to see if it is EOF. C's file handUng requires that ch is
an integer and it returns -1 when it reaches the end of a file.
That is, a true integer 16 bit -1 so it is different from a signed
character -1, hexadecimal FFFF as compared to hexadecimal
FF.

The while loop has one statement. If the test passes it writes the
character that it got out to the output file. All you need is to
open two files and then this single line copies the contents of

infile to outfile. When you exit the loop because EOF was
detected you simply close the two files and quit the program.

Pointers

This is perhaps the one most difficult part of C to grasp
initially. A pointer variable contains a memory address of
another variable. The symbol "♦" is used to indicate a pointer.

char *ptr;

This declares a variable named ptr to be a pointer to a data item
of type character.

char message[] = {"Hi there"}

ptr = &message[0];

ptr now contains the address of the character "H" in the
message. We talked about how an array name is a synonym for
the address of the first element in the array so we could equally
well say:

pfr = message;

Now we access the "H" by using:

putchar(*ptr);

The combination *ptr means "the character pointed at by ptr".
The "♦" is said to "dereference" the pointer. Now with this in
mind let's do a function to print out our familiar character
string "message" two different ways:

ptr_print_string(string);
char ♦string;

{

while(*string)
putchar(*string-H-);

}

array_print_string(stiing);
char stringd;

{

while(string[n])
putchar(string[n-H-]);

}

The two methods are so much equivalent that we can mix and
match:

mixed_print_string(stiing);
char ♦string;

{

int n=0; while(string[n])
putchar(string[n-H-]);

}

The Computer Journal / #76

37

In the calling function, remember "message" is the address of
the first location in the array, exactly what we want in
mixed_print_string. char ♦string is exactly equivalent to char
stringU. In the first example of the three, the expression
•string-H- increments the pointer value, not the value pointed
at. Further a pointer to an integer or a long will be appvopn-
atety incremented by 2 or 4 because integers are two bytes long
and longs are 4 bytes. C takes care of this automatically. You
can increment the thing pointed at by a pointer by using
parentheses as:

(•string)++;

One more thing will show the equivalence a bit better:

char messageQ = ("Hi there")};
char* ptr;

ptr = message;

// OT ptr = &message[0];

Now, we can use message[3] to point at the space in message
or we can use *(ptr+3). The two are exactly equivalent*. C
gives the name "message" a constant value that is the address
of message[0]. In other words it points at the first element in
the array.

* Well, not EXACTLY equivalent. The name "message" is a
constant pointer. That is it will always contain the address of
the message array's first byte. We can assign this value to a
pointer, and the pointer can then be incremented (but "mes-
sage" carmot). That is, the pointer's value is iwt constant, but
the value of "message" IS a constant.

We can initialize a pointer with an address or with a literal
constant as well, using an initializer when we declare it just as
we can say int x=3;. Of course if we use an initializer like the
following, we must have defined (but not necessarily initial-
ized) a character array named message[].

char *ptr = message;

or

char ♦ptr = {"Hi There"};

Now we can print the string with: puts(ptr);

Of course you don't have to call a pointer "ptr" but it might
help someone reading the program if you include the letters ptr
or at least append a "p" (or maybe a "ptr") to the end. For
example a pointer to a message could be caUed messagep or
messageptr or mesptr.

There is one other way in which pointers and arrays are not
equivalent. Several issues ago 1 was chastised for my remarks
that a textbook that I have indicates that array references in a
program are converted by the compiler to generate the same

code as when pointers are used. One reader disassembled some
output code of a compiler and found that using pointers gen-
erates less code than using arrays. 1 did the same for my Turbo
C output code for some simple cases and 1 did find that code
that used pointers generated smaller object code than array
references. The difference was small, however. With an older
compiler and an "antique" computer you may well want to do
whatever is necessary to save memory and speed up the pro-
gram execution. With Turbo C on a 486 system with 8 megs
of RAM and a 500 Mbyte hard drive, who cares? (I'm sure
someone is going to tell me that HE cares!, but in general, I
don't).

This ought to leave you with a few things to think about until
next time! Maybe you've gotten your curiosity arroused enough
to get hodced and go to buy a textbook on C in a bookstore. If
so, this series is accomplishing its purpose. I've been trying to
adapt my original lessons that were based on ANSI C, and 1 am
afi'aid the translation is not as clean as a start-from-scratch
series would have been. Part of the problem is that my mind set
has been "converted" and I've (purposely) forgotten the "old
way". I remember fiissing and finning about some of my older
C programs having to have a bunch of things changed before
they would successfully compile under an ANSI C compiler
version, but now that I am converted, I really like the new way
much better.

Some Thoughts

These are current notes added to the end of my old class note.
I realize that we haven't really covered files in C just yet, but
this is not terribly profound, and it is of ciurent and immediate
relevence to me. Something I've been having trouble with (for
a very long time) is a simple matter of detecting an end of file.
A loop that starts:

while ((ch = getc(infile)) !=EOF)

worksjust fine since it tests every character that it gets for the
end of file condition. I tend to make this nty outer loop and then
process words or lines or paragraphs or whatever inside the
loop. I very frequently forget that I have to test for end of file
every time I get a character (except for some unusual file
structiues that signal the last item in a list). The result is that
my program goes into an infmite loop and I spend a while
figuring out why and correcting the problem. A case in point
is one that I did last night to use for this series. I wrote the C
class notes using WordStar for Windows on a PC. I wanted to
translate them to straight ASCII files. WS lets me "export"
them in several modes, one being "stripped ASCII". Stripped
means that all non printable characters and such things as font
descriptions are removed.

Most text processors treat a paragraph as one long line. When
you type a paragraph in, you don't have to type a CR at the end
of the line. The word processor wraps the text around to the
next line, but it doesn't insert a CR. The result is that a
paragraph is really just one long line with a CR at the end. My

38

The Computer Journal / #76

ASCn editor needs lines with CR's and it doesn't automati-
cally insert them. I therefore wrote a program in C to copy any
line shorter than a number of positions I set up as a #defme
constant LINLEN in the program without change. If a line
(paragraph) exceeds this length, the program backs up to the
preceeding space and outputs that much as a Une, adding a cr
or a \n in the terms of C. It then starts at the character after that
space and counts characters etc. When it gets to the end of the
paragraph (as defined by text ending with \n) it reads another
paragraph and starts over again.

I found a shareware program called RAP (as in wrap) the other
night, that makes each line X characters long. You specify X
in the conunand line. The problem is that if there are short
lines (as in a program listing) it combines them to make a
longer line. I wanted to split long paragraph-lines but not touch
program listings etc. so I thought I would do it for myself.

I finished my program and it went into orbit. I found my
problem with end of file and it began to work. After a few more
bugs were removed it worked fine and I used it to modify the
text file for the above lesson. Since this is a short program
(about two pages of source) that is complex enough to be a little
more challenging than "printf("Hi ThereVn"); I am going to
present it later as an example, with a discussion of how it
woiks.

Lest you all think that I have "arrived" simply because I can
write some simple tutorials on basic "C" programming, let me
tell you that I found a program on my hard drive the other day
that I vaguely remembered doing for a project that never
materialized. One part of it was a program that reads a text file
and a data file containing search - replace pairs, and generates
an output file in which each search word is deleted and the
corresponding replace word is inserted. Apparently I had
dunq)ed this program into my computer and never started
debugging it. Now that I think about it a while, I suspect it was
written in "Whimsical" for a 68000 machine and translated to
C but never tested at all.

Well, the thing didn't work. First I had trouble with allocating
a couple of large buffers in which to shuttle the text file back
and forth once for each search replace pair. Then I found that
I tteeded to use a larger memory model in the compiler. All in
all, I think I spent about 16 hours on the project before I finally
got it all working. Part of the problem was the End of File
problem discussed above. The rest of it finally boiled down to
my not having initiaUzed an array index at the start of each
pass through a nested loop. Along the way, the program got so
bad it would hang the computer and I would have to reset it and
try again.

As I look back on the "good old days", when I spent that much
time working on a program, I ended up with something that
took 15 minutes to compile and at least a few minutes to run.
This program for a fairly large text file and a list of 15 or so
substitutions, seems to nm in less time than it takes to type the
command line. In fact, it is done about the time I get my finger

off of the ENTER key! What must I do to write a program that
takes more than a few seconds to execute?

Assembler

I'm going to "chicken out" a little this month and discuss an
assembler program that is just a slight variation of COPY that
we have done previously. The difference is significant, how-
ever. I want to introduce an example of a "filter" program.
COPY, as you probably remember if you have been following
this series, reads a file named on the command line and writes
a copy to another file named on the command line.

As I mentioned above, a filter program does a little more than
copy a file. It makes some significant modification to the data
in the file as it reads one file and writes another. As a fairly
sinq>le example I present a program called UPLOW that reads
an input ASCII text file and converts all uppercase letters to
lower case, otherwise passing the text straight through. To do
that we simply add a few lines between the reading of charac-
ters and the writing of characters. To keep things si^^)le we are
assuming an ASCII text file.

• A Fn.TER PROGRAM TO CONVERT UPPER TO LOWER CASE

NAM

UPLOW

PUTCHR

EQU

SCD18

WARMS

EQU

JCD03

RPTERR

EQU

$CD3F

FMS

EQU

$D406

FMSCLS

EQU

SD403

NXTCH

EQU

$CD27

SETEXT

EQU

KD33

WRKDRV

EQU

SCCOC

PCRLF

EQU

JCD54

GETFIL

EQU

$CD2D

CR

EQU

tOD

FOPENR

EQU

Ml

FOPENW

EQU

J02

FCLOSE

EQU

$04

SfART

LDX

*IFCB

JSR

GETFIL

LDA

•1

JSR

SETEXT

SETS EXTN TO TXT IF NONE SPECinED

LDA

»FOPENR

OPEN FOR READ CODE

STA

0,X

JSR

FMS

BNE

ERROR FMS SETS NON ZERO ON ERROR

• NOW DO IT AGAIN FOR THE OmTUT RLE

LDX

mOFCB

JSR

GETFIL

LDA

• 1

JSR

SETEXT

LDA

•FOPENW

OPEN FOR WRITE CODE

STA

0.X

JSR

FMS

BNE

ERROR

• LEAVE FILES AS TEXT RATHER THAN BINARY
LOOP LDX «IFCB

JSR FMS READ A CHARACTER TO ACCA

BNE ERROR

• NOW LET'S BUILD A "HLTER"

CMPA •'A

BLT CONTIN IF LESS THAN CHAR A LEAVE ALONE

CMPA «'Z

BGT CONTIN IF GREATER THAN CHAR Z LEAVE ALONE

ADDA «J20 ELSE MAKE IT LOWER CASE

" END OF OUR SIMPLE FILTER TO CONVERT UPPER CASE ASCII TO LOWER

CONTIN

LDX

KOFCB

JSR

FMS

WRITE A CHARACTER

BNE

ERROR

BRA

LOOP

00 AROUND AGAIN

The Computer Journal / #76

39

ERROR

LDB

1,X

CMPB

»$08

TEST FOR END OF FILE

BEQ

DONE

JSR

RPTERR

TELL USER WHICH ERROR ■ X POINTING AT FCB

JSR

FMSCLS

CLEAN UP BY CLOSING ALL OPEN FILES ON ERROR

JMP

WARMS

DONE

LDX

»IFCB

LOA

«04

STA

0^

CLOSE THE HLE

JSR

FMS

LDX

•OFCB

LOA

•$04

STA

0J{

CLOSE THE RLE

JSR

FMS

JMP

WARMS

ORG

S200

IFCB

FCB

0.0,0.0,0.0,0.0.0.0.0,0,0.0.0

RMB

305

OFCB

FCB

0.0.0.0.0.0.0.0.0.0.0,0,0.0,0

RMB

305

END

START

I d(m't remember if we have discussed the TSC Assembler's
com^ention for an ASCII character code. It uses an apostrophe
befcve a character to stand for the ASCII code for that charac-
ter. Thus 'A, $41 and 65 are all equivalent. Since we are
manipulating characters here, it makes the program more
readable to use the ASCII character representation.

The ASCn code for the letter "A" is $4 1 . That for the letter "a"
is $6 1 . Since all upper and lower case letters are in alphabetical
order, the lower case letter's code is $20 larger than that for the
same letter in upper case. ($20 is decimal 32).

The program therefore checks to see whether each letter is in
the range of the codes for the capital letters. If the code is less
than that for A or greater than that for Z, it is sinqjly passed
through. Otherwise it has $20 added to it before being written.

Here is a test file for input to this program:

01234567890@{}D

abcdefghijklmnopqrstuvwxyz

ABCDEFGHIJKLMNOPQRSTUVWXYZ

This is the result of a run of the program:

01234567890@{}[]

abcdefghijklmnopqrstuvwxyz

abcdefghijklmnopqrstuvwxyz

A word is in order concerning testing. When you do something
like this it is easy to get the test "off by one". It is a good idea
to check the codes immediately before "A" and immediately
after "Z". These are "©" ($40), and "[", ($5B) respecUvely.
You will note that they both went through the filter unchanged,
and that all the upper case letters were nicely replaced by their
lower case versions. The test shows that codes $41 through
$S A are modified but codes $40 and $5B are not. The program
therefore works as we expect.

Though the example code is simple, the idea can get as com-
plex as you like. For example a TAB character ($09) has a

different meaning in a FLEX text file than it has in an MS-
DOS text file. As we have mentioned previously, in a FLEX
text file a $09 means that the next byte is going to contain a
space count. $09 $08 would mean to insert 8 spaces. FLEX
does this tranqwrently. It is built right into the operating
system. A string of spaces is converted into an $09 and a count
when a file is written, and back to a number of spaces when it
is read. If it is opened as a binary file this is not the case. You
could write a filter to read a FLEX file and convert all tab
sequences to a number of spaces, which would be dumb be-
cause FLEX does it automatically when you read the file as a
text file. Better you could translate an MS-DOS file into a
FLEX file by reading it as a binary file and inserting, say, three
spaces whenever you encoimter a $09. Then you could write it
in TEXT mode so the spaces would be compressed to a $09 and
count sequence.

Above I referred to the problem of breaking a long line (a
paragraph from a text formatter) into shorter lines by adding
CR and LF at appropriate word breaks. I described doing such
a program in C, but you could easily do the same in Assembler.
Our COPY program is a nice template for doing all sorts of
filter programs. All you have to do is to add the filter action
between the read and the write. Obviously you would have to
read and store characters until you had enough to make a line
before writing a line to the output file.

You could write a program to recognize words and substitute
other words in a text file. You would have to buffer whole
words and compare them with a search word, then replace that
with a replace word. It would be just like the search and replace
function of many editors. You could write a program that
would accept input filename, output filename, search word,
and replace word as parameters on the command line. Such a
utility might be useful, but if you decide to try one watch out
for some traps. If you want to change "the" to "a" you have to
include leading and trailing spaces or you will end up changing
"theodore" to "aodore". Also you will have to handle capitali-
zation in order to make a useful utility for a text file. Change
"The" to "A" and change "the" to "a" in other words.

If anyone out there is interested in moving files between a PC
and a 6809 running FLEX, I have written two pair of utilities,
one for each machine that allow copying a disk of text files in
either directioa My FLEX to MS-DOS transfer program is a
bit specialized to handle Extended BASIC integer and floating
point numbers as well since it is set up for reading virtual
arrays in Extended BASIC and converting them to ASCII
number arrays on the DOS end. I can remove some code and
clean them up to handle TEXT files only if anyone would like
copies. There are some cautions, but I would be glad to share
these with anyone wanting them. They work over a simple
serial cable with no hardware handshakes, so it is not very hard
to make the prc^r cable for them. The PC programs are
written in Turbo C and the 6809 end is written for John Spray's
6809 Whimsical compiler.

40

The Computer Journal / #76

Floppy Disk Problems

By Claude Palm

Special Feature

Beginning Forth

Trouble Shooting Design

/ received this article a rather long time ago, and had asked
Claude to send me the disk. Well somewhere in time, the
messages got lost and I finally broke down and scanned it in.
It is important for several reasons that you should read it.
Mainly it talks about the floppy chip used in PC clone ma-
chines, but more importantly it explains about finding prob-
lems. Maintaining your own system is mostly about learning
how to hunt down those elusive problems that others would
simply use as an excuse to "throw the #$%''&* machine
away. " Fortunately Claude didn 't give up, even better he
documented his actions fijr you to see. Thanks. Claude! Bill
Kibler.

CASE OF THE CONFUSED FDC.

This is a detective story. The clues lead in one direction, then
another, and the solution found in yet another. Is it software,
hardware, buggy chips, or a bit of everything? I got into
electronics in the 60's, computers in the 70's but this is the
most con&sing bug I ever came across. It may interest your
readers, and some may even learn something from it.

It all happened while designing the CPUZ180 SBC and con-
cerned interfacing a National DP8473 FDC (FloH)y Disk
Controller) to a Z180 CPU. Before I come to the problem I
have to give a reasonably detailed description of what was
involved, as it is rather technical and caused by some of the
finer points of the behavior of both chips.

THE CHIPS

The DP8473 was designed to interface with the IBM PC bus,
thus all its interface logic and I/O ports are IBM compatible.
The FDC is accessed via its STATUS and DATA ports (plus
a few others). The STATUS port holds 8 bits and indicates
things like BUSY, DATA REQUEST, and whether the request
is to receive a byte or if it wants to send a byte. The byte itself
is transferred through the DATA port. To select the chip there
is a CS (Chip Select) pin, then 3 address lines (AO-2) to specify
the required port. One of the RD or WR pins must then be
assertoi before a byte is transferred.

To execute a command you send a ^)ecified number of bytes to
the DATA port, wait for the commaivd to execute which may
involve sending/receiving sector data. On completion the FDC
issues an interrupt, after which you read the result, again from

the DATA port. For example, to read a sector you write 9 bytes
of command and sector information, and afterwards read 7
bytes of result. The STATUS port informs you of the progress,
the BUSY bit will be set after the first byte of the command,
and the sector read will commence after the 9th byte is written.
These operations are referred to as the 'command phase',
'execution phase', and 'result phase'.

Ehuing the execution phase, sector data can be transferred in
several ways. The polled method lets you read it byte for byte
via the DATA port as it comes to hand, then you put it
somewhere. The STATUS port will advise when, but if you
miss a byte then it it's lost When the entire sector is trans-
ferred the FDC will issue an intemq>t and the result phase
conunences. After the last result byte is read, the FDC clears
its BUSY bit so you don't have to coimt the bytes.

PolUng works ok, but holds up the CPU for long periods, as it
may take some time for it to find the particular sector. Iitter-
rupts must be disabled so an interrupt driven keyboard could
easily loose a character. If left enabled you probably loose
some data instead. There is also an interrupt driven method,
but I won't go into that.

The DMA (Direct Memory Access) method is by far the best
way to transfer sector data, but it requires extra hardware. You
must have a DMA controller (the Z 180 has two of them built
in) to do the actual transfer. While it is shuffling data the CPU
can go about its normal business, handling interrupts and so
on. The FDC sends out a DRQ (Data ReQuest) signal to the
DMA controller. The DMA replies with a DACK (Drq
ACKnowledge) then transfers a byte between the FDC and
memory. This takes only a fraction of a microsecond per byte
and the CPU is disabled for that time <Mily. Before starting
DMA the controller must of course be instructed with what to
do, memory locations and so on, but after that the operation is
con^)letety transparent to the CPU.

As the FDC interrupts the CPU when transfer is complete, the
interrupt routine can read out the result and store it some-
where, then return to the main program. The FDC also
interrupts on completion of other commands, such as a RE-
STORE or after it has been reset. These interrupts are distin-
guished by the BUSY bit being clear, when you must issue an
SI (Sense Interrupt) command to the FDC, and read the result
to see what the interrupt was about In case there were several

The Computer Journal / #76

41

conditions causing intemq>t you should repeat the SI com-
mand until the result byte is 80h, which is the same result as
an illegal command i.e. the first (and only) result byte is 80h
if the FDC didn't understand the command. The rest of the
stoiy hinges on that.

THE HARDWARE

Now for some hardware description. The Z 1 80 DMA reacts to
a DRQ signal by transferring a single byte between the FDC
and memory, but it won't issue a DACK. Instead it performs
a n(»mal Z180 I/O cycle by asserting its lORQ signal (to advise
the outside world that this is a data transfer to/from an I/O port)
together with the specified I/O address and a RD or WR strobe
to denote the direction.

With the FDC in DMA mode, data can only be transferred after
receipt of the DACK and RD/WR signals, regardless of the CS
(Chip Select) and address lines. The FDC only enters the
DMA mode during actual sector data transfers, it is always in
the polled mode during the command or result phases. Then
it uses the CS, RD/WR, and address inputs to work out what
action to take. The RD/WR signals come from the CPU but are
ANDed with the lORQ line so they won't appear during
memory accesses.

The CPUZ180 uses a simple address decoder (74ACT138) for
all its I/O port selects. As it only decodes-S address lines, it
will also send out select signals when a matching address is
during ncHinal program execution. The data sheet for the FDC
states that a CS may not occur during DMA, and further that
any DACK received will effectively clear a DRQ, regardless of
any RD or WR signal. Another point is that a Zl 80 INT ACK

(Interrupt ACKnowledge) cycle is similar to its I/O cycle, it
asserts lORQ but also an Ml signal which is not used, during
I/O.

Bearing all that in mind I conditioned the FDC select signal
fi-om the decoder by ANDing it with lORQ and disabling it
during Ml. That way there wouldn't be any stray FDC CS
pulses. I then devised a DACK signal by picking an unused
port address ftom the decoder and conditioning it the same
way. As the DMA would be the only user of that port, there
wouldn't be any stray DACKs either, or so I thought.

NO PROBLEMS

Lets put it all together now. I had the same FDC working with
a HD64180 using polled I/O so I used that software to test the
FDC in the CPUZ180. After a lot of changes I ended up with
a working floppy disk system. Next step was to change from
polled to DMA data transfer because as expected, the keyboard
did loose characters when you typed during floppy access.
Secondly, polled I/O is not a very neat way of doing things and
I already had the hardware setup.

The whole exercise ended up being relatively straight forward,
as &r as these things go anyway. An interrupt routine was
written so that it would read out the FDC's result to a buffer,
handling other FDC interrupts and so on. The sector I/O
routine would put the command in another buffer, then write
it out to the FDC which would then start any required seeks,
find the sector etc. While it was doing that, the DMA control-
ler was loaded with addresses, byte count, and also set to work
waiting for the first DRQ fix)m the FDC. Then all that was left
was to sort out some housekeeping and settle down to wait until

WR

RD

ZORQ
CPU
Z180

M1

A7
A6
AS
A4-
A3

A2

A1
AG

/

>o-

68-6F
ho

74-
' 13e

60-07

-o-
-o-

\

OR o-
/

-o-

-o-

OR

OR

OR

\
(
/

\
/

\
(
/

Relevant: part; o-P the circuit.

(note: OR gates drawn as NAND gates with inverted inputs as all signals are active low)

WR

RD

FDC
DP84.73

CS

DACK

A2
A1
AC

42

The Computer Journal / #76

the FDC interrupted things and the result was read into its
buffer. The interrupt routine would set a flag to signal comple-
tion. Finally the result buffer would be checked to see if any
error had occurred.

After sorting out the usual bugs that crop up in this sort of
work, eveiything was working satisfactorily. The routines had
been working out of RAM during the trials, so I moved them
into

FLASH (semi-permanent like EEPROM) memory with the rest
of the BIOS code to keep the RAM as free as possible. Final
testing of the new FLASH based BIOS showed no problems
concerning the floppy access, so I went on to other things, and
that would have been the end of an uneventful story.

PROBLEMS EMERGE

However, the 'other things' involved several additions and
modification to the FLASH resident BIOS code, not directly
involving the FDC routines. I had been using a serial commu-
nication line to transfer programs between the CPUZ180 pro-
totype and my main computer, but one day I needed a program
that I had on a floppy disk nearby. The easiest way was to
insert the disk and copy the file to the hard drive, which I did.
Only I got an 'Undefined Error' with a query if I wanted to
rdx)0t, retry or skip the sector. Retry or reboot didn't help, so
I shut it down, cold started, and tried again. Same result, I tried
another disk, still no go. I tried reading the disks in the main
computer and they were ok. I tried another disk drive but that
didn't help either. I could not see why because it had worked
flawlessly before.

Well, it wasn't the obvious, so what was it, software, hardware,
or a bad chip. I don't believe in bad chips, they almost never
go bad if looked after properly. Maybe I inadvertently changed
something in the FLASH memory during my other modifica-
tions? I checked against my Ustings, but apart from residing in
a different location, there were no discrepancies. I reassembled
the code and did a byte for byte compare in case of a bad
memory cell. Same code. All right, try the chips involved, but
that made no difference either.

Maybe the processor ^jeed. You can insert up to 3 extra wait
states in the Z180, each wait holding the processor (and DMA
controller) up for another clock cycle. It had been ruiming at
9 MHz with no waits, so I set it up for the slowest possible
performance with an extra 300 nS per machine cycle. That
ought to fix a slow memory cell or some marginal FDC inter-
face. It didn't.

Could it be in the board itself? It was a double sided board
produced in house. It used copper eyelets for feed-throughs
(350 of them) in lieu of plating, and everything hand soldered.
E>efinitely a suspect. But a thorough checkout with an oscil-

loscope only showed that all signals were present and correct
and still no go. Some old fashioned prodding also failed.

UP THE GARDEN PATH

Into the debug monitor and there I got a surprise. There was
defmitely floppy disk data in the main sector buffer. It must
be reading something. The command buffer showed the cor-
rect command and sector address, but the result buffer had 80h
in the first location. If you remember the previous discussion,
SOh stands for either an illegal command or some other inter-
rupt caused the interrupt routine to issue SI commands until
the result was SOh. As everything was legal in the command
buffer, some other interrupt must have caused it As SOh is not
a valid result after a read command, BIOS reported it as
undefined.

But where did the extra interrupt come from? I went through
the code several time, but could find nothing. The dd)ug
monitor is unable to set breakpoints in FLASH memory as it
can't be written to readily (only in 16KB blocks), but is capable
to single step through it by moving each instruction into RAM.
Very tedious as I had to single step through a large number of
unimportant instructions before arriving at the business end of
the code. Then I had to start the DMA manually because it is
only milliseconds before the FDC starts sending data and I was
stei^ing through each instruction via the keyboard.

The end was a complete anticlimax. The sector was trans-
ferred with no error at all, so I had to try another tack. The
BIOS will retry an undefined error once, by resetting the FDC,
reloading all parameters and then executing the command
again. This could easily be altered to up to four resets, which
I did. That actually worked, with the occasional error reported
and, by

replying 'retry' to BIOS's query, I could load an entire file.
Next step was to log the errors. That didn't shed any more
light on the problem. A particular sector might read at first go
in one load, but needed half dozen retries the next time.
Completely random, but only about 1 sector in S got through
on the first try.

FURTHER UP THE GARDEN PATH

I started thinking about a timing problem. Maybe something
was extremely marginal. One way to upset timings is to either
heat the board or freeze it. I tried the fridge and then a heat
shrink blower, but neither made any difference. The errors
occurred at about the same rate, cold or hot. That seemed to
discount the timing theory.

Then I thought of the original test program, the one that
resided in RAM. At least I could set breakpoints, and move
around in it a lot easier, as I seemed to be in for the long haul.
I dug it out, loaded and ran it, and would you believe, perfect.
I even zeroed out all retries, and still no errors, yet it was the
same code. Must be in the FLASH memory, but it had previ-
ously compared ok when tested, tried at a slow speed without

The Computer Journal / #76

43

iminovement. Still, I set up a routine to constantly cx)n:q>are
the FLASH with its supposed contents that I had loaded into
RAM. I let it nin for awhile and it could not find any
mismatches. Yet the disk I/O routine would execute properly
out of RAM but not from the FLASH memory.

I concentrated on the RAM based disk program. I had it
woridng without errors, so I started to modify it to use some of
the routines in the FLASH memory. It kept on working
perfectly imtil I added some code so that it would use the
FLASH based interrupt routine. Then the errors started up
again. Only occasionally mind you, about 1 error in 4 reads,
instead of the other way arouitd as before, but with exactly the
same result. That was the queer part: running partly out of
RAM only changed the frequency of the same error. Running
entirely out of RAM produced no error. I rechecked FLASH
error rate but it was unchanged. It just didn't make sense.

Now, with much of the code in RAM, I set a few breakpoints
through the ddwgger. One just before the command was
issued another one at the interrupt entry point. Then ran it.
The first few times there were no errors, but then, after I let the
read command start executing, the interrupt routine caught on
another breakpoint and I single stepped through the result
readout as I had done 3 or 4 time before. This time however
the very first byte read out from the DATA register, supposedly
the first byte in the result, was the by now dreaded 80h. Yet
after cheddng, the DMA controller had finished and the sector
had been transferred to the sector buffer with no apparent error.
Befwe commencing each read I had cleared the buffer to all
O's, and now it contained 512 bytes of directory data. At least
I had watched the bug in action. I should have continued to
single step through the entire result phase as the STATUS
register would have indicated that there was more to come, but
I didn't (hindsight). I was instead trying to work out how the
FDC could report an illegal command after it had just trans-
ferred a sector correctly. No way that it could do that.

I changed the code to accept the result of 80h as a no-error
result and ran it. After several file transfers and compares, I
was satisfied that the software and the disk system was working
correctly. The FDC was just giving out the wrong result.
Problem was: how to trap a real error if one occurred?

byte. Before, when I was using 0,0,0 as sector address I
wouldn't have noticed it.

GETTING WARM

I went back to the FLASH based system where I was almost
certain to end up with an error, while relinquishing my ability
to set breakpoints. I then cleared the result buffer and did a
read on one of the outer tracks. To top it off I had put in a non-
zero sector number, on head #1. Sure enough, BIOS reported
an undefined error, and straight in with the debugger rather
than replying. First check the result buffer. It started with 80h
all right, but it also contained the track, sector, head, and size.
Only they were in the 3rd to 6th byte NOT in the 4th to 7th
location where they ought to be. Although they didn't ought
to be there at all. The FDC is only supposed to send a single
byte result on an illegal command, and in any case the routine
that checks the FDC's SI results only reads up to two result
bytes.

Then the penny dropped: 80h is a valid 2nd status byte, in fact
it is the expected 2nd status byte, indicating that the last sector
in the command has been processed (bit 7 set) The other bits
represent certain errors when set It just hadn't entered my
mind before, I was so sure that the 80h was the illegal com-
mand result. The whole buffer was shifted one byte down. The
first result byte which ought to be 40h was nowhere to be
found.

Now I knew what was happening, but not why. Something was
reading a byte out of the FDC before the result routine got to
it. After finishing the housekeeping, the program was singly
sitting in a tight loop waiting for the 'interrupt complete' flag
to be set, and also checking for time-out in case the interrupt
never occurred. As soon as the last data byte is transferred the
FDC should generate the interrupt, indicating the end of the
execution phase, then enter into the polled result phase. That
would invoke the routine responsible to read the result. Not
much in between, yet something got that first byte. While
single stepping the result routine I had seen that the 80h really
was the first byte read (if I had continued that time, I would
also have seen the track, sector, and other information come
forth, but that's life)

When doing single sector reads, I had used track 00 sector 0,
simply because the command buffer was automatically cleared
to these values. Now I was going to try writing to the disk, and
as it had a valid directory there, I started using some empty
trades between 70 and 79. The undefined error condition
occurred in their usual frequency during writes but the writes
themselves were successful. I was examining the result buffer
after another 80h found its way to it. Hie buffer should
actually hold 3 bytes of status information (bit records), final
trade, head, sector numbers, and the sector size. I noted that,
apart fix)m the &miliar 80h in the first location, it also had a
track number in it. It could have got there fi'om a previous non-
error read, but it was in the wrong place, the 3rd instead of 4th

Then I had a gUmmer of an idea. The address decoder only
uses the lower bits of an address (actually bits 3-7). It assumes
anything between 60 and 67h is fi'om the DMA controller and
sends it on to become the DACK signal. Similarly 68 to 6Fh
goes on to become the FDC's CS signal, as long as they occur
in conjunction with the lORQ signal while Ml is oflF. The
sector data I/O uses 60h, sent by the DMA controller, the main
STATUS port is at 6Ch while 6Dh is the DATA port. The loop
waiting for the interrupt to occur in FLASH memory ^nt
considerable time around addresses ending in those ranges.
Coincidence? I reloaded the last RAM based program I had

44

The Computer Journal / #76

used, the one that produced the odd error, and that loop had
used two addresses with the low 8 bits in the same range!

CAUGHT IT

I put in a few NOPS to shift the loop out of that range,
reassembled, and ran it. No errors. I did it again, just to prove
the point, this time shifting the loop so it executed right in the
range. The 8 low bits in every address were sixty something
hex. Plenty of errors this time. I had foimd it, but I still
couldn't figure out why.

I wrote another tight loop around those addresses, then an
interrupt routine that did nothing. I shut the machine down.
As the RAM is battery backed it would hold the program. Next
I pulled the FDC chip from its socket and hooked a pulse
generator onto the interrupt pin so that the CPU would receive
the pulses on its INTO input without fighting another output.
Then I powered iq) in the debug monitor and set the whole
thing running with the oscilloscqie nearby.

The 'scope showed the expected pulses fi'om the decoder as the
loop executed, but nothing on the conditioned DACK or FDC
select lines. So far so good. Then I applied the interrupt pulses
from the generator, and there they were. Rather short pulses
on both the DACK and FDC CS lines. That did explain the
problem, but also posed new questions such as: why were they
there, and why did the FDC react to them to the extent of
loosing a byte. The first question was answered by the Z180
manual on interrupts: the Ml signal appears and ends half a
clock before the lORQ signal during an INTACK cycle. Also,
the address present on the bus at that time points to the
instruction following the interrupted instruction. The conclu-
sion was that for the last half clock cycle during INTACK we
have an address - in this case the low bits are 6x, which the
decoder recognizes. We also have lORQ without Ml which my
system control PLD recognizes as a valid DACK or FDC CS
and thus sends out either signal, albeit for a brief period.

HI

lORQ

DACK

r

The INTACK cycle as shown on the 'scope.

I shut down, removed all gadgets, put the FDC chip back in
place and fired up again. Then I went back to the RAM based
disk I/O routines and shifted the loop as before, this time so
,that it ended with the 8 low bits at 66h i.e the extra pulses
would be recognized as DACK signals only, as the FDC select
starts at 68h. Rurming that produced the errors as before.
Then I shifted it again, this time starting the loop with the low

address bits at 68h. No D ACKs but should get some extra FDC
CS pulses. Ran it again, this time with no errors.

The exercise proved that an extra DACK pulse, even a very
narrow one, will remove a status byte, but there is nothing
about that in the data sheet. It also proved that extra CS pulses
makes no difference, which is something the data sheet warns
you against. The DP8473 data sheet actually specifies that
'During DMA operations the Chip Select input must be held
high' end quote. I think they got that back to front. It ought
to read: 'During polled I/O the DACK itq>ut must be held high'
It just shows that you carmot,believe everything you read.

THE FIX

I had to do something a bit more permanent. Just by putting
the loop in another area would not be a good-idea. A timer or
keyboard internet could occur, then the FDC interrupting
while these being attended to. That could be at any address,
quite possibly generating a spurious DACK signal to cause an
FDC error.

The solution was not hard to come by, all I had to do was to
quaUiy the DACK signal with the CPU's RD or WR strobe -
either had to occur during DMA but not during INTACK - as
well as the lORQ signal. The Ml signal could be dispensed
with. It required some cut traces, a col^)le of wire jumpers and
a redesigned PLD. All up it took about an hour to fix what had
taken a week to find. It proved to be a permanent solution too,
as the floppy disk part of the system has behaved flawlessly
ever since.

AS AN ASIDE

A month or so later I had installed an 1 8Mhz CPU and nmning
at ftill ^)eed (with a fair few changes to FLASH memory
contents). I wanted a printout of something, and the board was
ruiming without a printer as it does for most of the time, so I
plugged one in. Would it print anything? No way. It didn't
even hang or anything, just a short pause then continued as if
the printing was completed. A sense of deja vu if I ever had
one. First thing was to try manipulating the printer ports from
the monitor, and it did print that way. A quick check through
the printer driver listing revealed a likely culprit. With the
CPU operating at 18 MHz an instruction does not take very
long to execute and the entire operation of loading the data
then pulsing the printer strobe would have taken well under the
specified 1 uS. Probably not long enough for the printer to
recognize the strobe. Insert an extra instruction to waste some
time and that was that. Bug found, tried and executed in a
quarter hour. I wish all bugs were like that.

The Computer Journal / #76

45

Regular Feature SUPPORT GROUPS FOR THE CLASSICS
Contact Lifting

!*i 'il' *" ■''■■'' ■ '' ' '' ' ' '■''"'' I,;

TCJ Staff Contacts

TCJ Editor Dave Baldwin, Voice (916)722-4970, FAX (916)722-
7480 or TCJ BBS (916) 722-5799 (use "computer", "journal", pswd
"subscriber" as log on), Internet dibald@netconi.com, CompuServe
70403,2444, tcj@psyber.com.

Bin D. KiWer, PO Box 535, Lincoln, CA 95648, (916)645-1670,
OEnie: B.Kibler, CompuServe: 71563,2243, E-mail:
kibler@psyber.com.

Z-System Support: Jay Sage, 143 5 Centre St. Newton Centre, MA
02159-2469, (617)965-3552, BBS: (617)965-7259; E-mail:
Sage@ll.mit.edu. Also sells Z-System sofbvare.

32Bit Support: Rick Rodman, 1150 Kettle Pond Lane, Great Falls,
VA 22066. BBS/FAX (703)769-1 169.

Kaypro Support: Charles Stafford, 4000 Norris Ave., Sacramento,
CA 95821, (916)483-0312 (eves). Also sells Kaypro upgrades, see
ad inside back cover. CompuServe 73664,2470 (73664 .2470@cis).

S-100 Support: Herb Johnson, CN 5256 #105, Princeton, NJ 08543,
(609)771-1503. Also sells used S-100 boards and systems, see inside
back cover. E-mail: hjohnson@pluto.njcc.com.

6800/6809 Support: Ronald Anderson, 3540 Sturbridge Ct., Ann
Arbor, MI 48105.

Regular Contributors:

Brad Rodriguez3ox 77, McMaster Univ., 1280 Main St. West,
Hamilton, ONT, L8S ICO, Canada, E-mail: bj@headwaters.com..

Frank Sergeant, 809 W. San Antonio St., San Marcos, TX 78666, E-
mail: pygmy@pobox.com.

Tilmann Reh, Oemumy, E-mail: ttlmann.reh@hrz.uni-siegen.d400.de.
Has many programs for CP/M+ and is active with Zl 80/280 ECB
bus/Modular/Embedded computers. Microcontrollers (8051).

Helmut Jungkunz, Munich, Germany, ZNODE #51, 8N1, 300-14.4,
+49.89.961 45 75, or CompuServe 100024,1545.

USER GROUPS

Connecticut CP/M Users Group, contact Stephen Griswold, PO Box
74, Canton CT 06019-0074, BBS: (203)665-1100. Sponsors Z-fests.

Sacramento Microcomputer Users Group, PO Box 161513, Sacra-
mento, CA 95816-1513, BBS: (916)372-3646. Publishes newsletter,
$15.00 membership, meetings at SMUD 6201 S St., Sacramento CA.

CAPDUG: The Capital Area Public Domain Users Group, Newslet-
ter $20, Al Siegel Associates, Inc., PO Box 34667, Betherda MD

20827. BBS (301) 292-7955.

NOVAOUG: The Northern Virginia Osborne Users Group, Newslet-
ter $12, Robert L. Critics, 7512 Fairwood Lane, Falls Church, VA
22046. Info (703) 534-1186, BBS use CAPDUG's.

The Windsor Bulletin Board Users' Group: England, Contact Rodney
Hannis, 34 Falmouth Road, Reading, RG2 8QR, or Mark Minting,
94 Undley Common, Lakenhcath, Brandon, Suffolk, IP27 9BZ, Phone
0842-860469 (also sells NZCOM/Z3PLUS).

L.I.S.T.: Long Island Sinclair and Timex support group, contact
Harvey Rait, 5 Peri Lane, Valley Stream, NY 11581.

ADAM-Link User's Group, Salt Lake City, Utah, BBS: (801)484-
5114. Supporting Coleco ADAM machines, with Newsletter / BBS.

Adam International Media, Adam's House, Route 2, Box 2756,
1829-1 County Rd. 130, Pearland TX 77581-9503, (713)482-5040.
Contact Terry R. Fowler for information.

AUGER, Emerald Coast ADAM Users Group, PO Box 4934, Fort
Walton Beach FL 32549-4934, (904)244-1516. Contact Norman J.
Deere, treasurer and editor for pricing and newsletter information.

MOAUG, Metro Oriando Adam Users Group, Contact James Poulin,
1146 Manatee Dr. Rockledge FL 32955, (407)631-0958.

Metro Toronto Adam Group, Box 165, 260 Adelaide St. E., Toronto,
ONT M5A INO, Canada, (416)424-1352.

Omaha ADAM Users Club, Contact Norman R. Castro, 809 W. 33rd
Ave. Bellevue NE 68005, (402)291-4405. Suppose to be oldest
ADAM group.

Vancouver Island Senior ADAMphiles, ADVISA newsletter by David
Cobley, 17885 Berwick Rd. Qualicum Beach, B.C., Canada V9K
1N7, (604)752-1984.

Northern Dliana ADAMS User's Group, 9389 Bay Colony Dr. #3E,
Des Plaines IL 60016, (708)296-0675.

San Diego OS-9 Users Group, Contact Warren Hrach (619)221-
8246, BBS: (619)224-4878.

ACCESS, PO Box 1354, Sacramento, CA 95812, Contact Bob Drews
(916)423-1573. Meets first Thurdays at SMUD 59Th St. (ed. bldg).

Forth Interest Group, PO Box 2154, Oakland CA 94621 510-89-
FORTH. International support of the Forth language, local chapters.

The Pacific Northwest Heath Users Group, contact Jim Moore, 1554
- 16th Avenue East, Seattle, WA 98112-2807. be483@scn.org.

46

The Computer Journal / #76

The SNO-KING Kaypro User Group, contact Donald Anderson,
13227 2nd Ave South, Burien, WA 98168-2637.

SeaFOG (Seattle FOG User's Group, Formerly Osborne Users Group)
PO Box 12214, Seattle, WA 98102-0214.

OTHER PUBLICATIONS

The Z-Leller, supporting Z-System and CP/M users. David A.J.
McGlone, Lambda Software Publishing, 149 West Hillard Lane,
Eugene, OR 97404-3057, (541)688-3563. Bi-Monthly user oriented
newsletter (20 pages+). Also sells CP/M Boot disks, software.

The Analytical Engine, by the Computer History Association of
California, 1001 Elm Ct. El Cerrito, CA 94530-2602. A ASCH text
file distributed by Internet, issue #1 was July 1993. E-mail:
kcrosby@crayola.win.net.

Z-IOO Lifeline, Steven W. Vagts, 2409 Riddick Rd. Elizabeth City,
NC 27909, (919)338-8302. Publication for Z-100 (a S-100 machine).

The Staunch 8/89'er, JCirk L. Thompson editor, PO Box 548, West
Branch lA 52358, (319)643-7136. $15/yr(US) publication for H-8/
89s.

The SEBHC Journal, Leonard Gcisler, 895 Starwick Dr., Ann Arbor
MI 48105, (313)662-0750. Magazine of the Society of Eight-Bit
Heath computerists, H-8 and H-89 support.

Sanyo PC Hackers Newsletter, Victor R. Frank editor, 12450 Skyline
Blvd. Woodside, CA 94062-4541, (415)851-7031. Support for or-
phaned Sanyo computers and software.

the world of 68' micros, by FARNA Systems, PO Box 321, Warner
Robins, GA 31099-0321. E-mail; dsrtfox@delphi.com. New maga-
zine for support of old CoCo's and other 68xx(x) systems.

Amstrad PCW SIG, newsletter by Al Warsh, 6889 Crest Avenue,
Riverside, CA 92503-1162. $9 for 6 bi-monthly newsletters on
Amstrad CP/M machines.

Historically Brewed, A publication of the Historical Computer Soci-
ety. Bimonthly at $18 a year. HCS, 2%2 Park Street #1, Jackson-
ville, FL 32205. Editor David Greelish. Computer History and more.

IQLR (International QL Report), contact Bob Dyl, 15 Kilbum Ct.
Newport, RI 02840. Subscription is S20 per year.

QL Hacker's Journal (QHJ), Timothy Swenson, 5615 Botkins Rd.,
Huber Heights, OH 45424, (513) 233-2178, sent mail & E-mail,
swensotc@ss2.sews.wpaft3.af.mil. Free to programmers of QL's.

UpdaU Magazine, PO Box 1095, Peru, IN 46970, Subs $ 1 8 per year,
supports Sinclair, Timex, and Cambridge computers.

Other Support Businesses

Hal Bower writes, sells, and supports B/PBios for Ampro, SB 180,
and YASBEC. $69.95. Hal Bower, 7914 Redglobe Ct., Severn MD
21144-1048, (410)551-5922.

Sydex, PO Box 5700, Eugene OR 97405, (541)683-6033. Sells
several CP/M programs for use with PC Clones C22Disk' format/
copies CP/M disks using PC files system).

Elliam Associates, PO Box 2664, Atascadero CA 93423, (805)466-
8440. Sells CP/M user group disks and Amstrad PCW products. See
ad inside back cover.

Discus Distribution Services, Inc. sells CP/M for $150, CBASIC
$600, Fortran-77 $350, Pascal/MT+ $600. 8020 San Miguel Canyon
Rd., Salinas CA 93907, (408)663-6966.

Microcomputer Mail-Order Library of books, manuals, and periodi-
cals in general and H/Zenith in particular. Borrow items for small
fees. Contact Lee Hart, 4209 France Ave. North, Robbinsdale MN
55422, (612)533-3226.

Star-K Software Systems Corp. PO Box 209, Mt. Kisco, NY 10549,
(914)241-0287, BBS: (914)241-3307. SK'DOS 6809/68000 operat-
ing system and software. Some educational products, call for catalog.

Peripheral Technology, 1250 E. Piedmont Rd., Marietta, GA 30067,
(404)973-2156. 6809/68000 single board system. 68K ISA bus com-
patible system. See inside front cover.

Hazelwood Computers, RR# 1 , Box 36, Hwy 94@Blufnon, Rhineland,
MO 65069, (314)236-4372. Some SS-50 6809 boards and new
68000 systems.

AAA Chicago Computers, Jeny Koppel, (708)681-3782. SS-50 6809
boards and systems. Very limited quanity, call for information.

MicroSolutions Computer Products, 132 W. Lincoln Hwy, DeKalb,
IL 60115, (815)756-3411. Make disk copying program for CP/M
systems, that runs on CP/M sytcms, UNIFROM Format-translation.
Also PC/Z80 CompatiCard and UniDos products.

GIMIX/OS-9, GMX, 3223 Arnold Lane, Northbrook, IL 60062,
(800)559-0909, (708)559-0909, FAX (708)559-0942. Repair and
support of new and old 6800/6809/68K/SS-50 systems.

n/SYSTEMS, Terry Hazcn, 21460 Bear Creek Rd, Los Gatos CA
95030-9429, (408)354-7188, sells and supports the MDISK add-on
RAM disk for the Ampro LB. PCB $29, assembled PCB $129,
includes driver software, manual.

Corvatek, 561 N.W. Van Buren St. Corvallis OR 97330, (503)752-
4833. PC style to serial keyboard adapter for Xerox, Kaypros, Franklin,
Apples, $129. Other models supported.

Morgan, Thielmann & Associates services NON-PC compatible
computers including CP/M as well as clones. Call Jerry Davis for
more information (408) 972-1965.

Jim S. Thale Jr., 1150 Somerset Ave., Deerfield IL 60015-2944,
(708)948-5731. Sells I/O board for YASBEC. Adds HD drives, 2
serial, 2 parallel ports. Partial kit $150, complete kit $210.

Trio Company of Cheektowaga, Ltd., PO Box 594, Checktowaga NY
14225, (716)892-%30. Sells CP/M (& PC) packages: InfoStar 1.5
($160); SuperSort 1.6 ($130), and WordStar 4.0 ($130).

Parts is Parts, Mike Zinkow, 137 Baridey Ave., Clifton NJ 07011-
3244, (201)340-7333. Supports Zenith Z-100 with parts and service.

DYNACOMP, 178 Phillips Rd. Webster, NY 14580, (800)828-
6772. Supplying versions of CP/M, TRS80, Apple, CoCo, Atari, PC/
XT, software for older 8/16 bit systems. Call for older catalog.

The Computer Journal / #76

47

The Computer Journal

Back Issues

Sales limited to supplies in stock.

Numb«r42:

VoluiiwNumbtfl:

« I M U M 1 tD>

• SwW Mwladng and Modem transfwB

• Floppy dU torniatt, Print tpoolar.

• Adding 8087 ktatti CMp, Rbw opiic*
^S-100 HI-RES graptiic*.

• ConbDllIng DC molan, MuW-uur column.

• VIC-20 EPROM Pregmmmw, CP/M 3.0.

• CP/M uMr function* and intagraUon.

ilOtol*

• Foilh tutorial and Wrtta Yow Om.

• 88008 CPU tor S-100.

• RPM w CP/M, BIOS Enhancamants.

• Poor Man's DiaWbutad Procaaaing.

• CorNraMng Appla Stappar Motoia.

• FaeaMla Pietiifaa on a Micio.

• Mamory Mappad I/O on a ZX81 .

• Iwua8 20lo28

• Daaigning an 8035 SBC

• Uahig /^ppla Oraphica from CP/M

• SoMaring ft Olhar SHanga Talaa

• BuHd an S-100 Floppy Diak Controllar
WD2797 ConboNar tor CP/M 88K

• EidMidlng Turbo Paacal: aaria*

• UnaoMaring: Tha Arcana Art

• Analog Data /koquiaibon ft Control:
Connoting Your Cemputar to tha Raal

• Pregrammirtg tha 8036 S8C

• NEW-DOS: aariaa

• VarlaWMy In tha BOS C Standard Library

• Tha SCSI Intarfaoa: aariaa

• Uaing Turbo Paacal ISAM Fllaa

• Tha Ampro LMIa Board Column: aariaa

• C Column: aariaa

■ Tha Z Column: aariaa

• Tha SCSI Intarfaca: introduction to SCSI

• Editing tha CP/M Oparatf ng Syatam

■ INDEXER: Turbo Paacal Program to Craata
anlr<da«

■ S ali cB n g ft BuHdlng a Syatam

• inbodudion to Aaaambia Coda tor CP/M

• /\mpro 186 Column

• ZTima-l : A Raal Tima Clock tor tha Ampro
Z-80 LMIa Board

126 to 11

• Bua Syatama: S ila et lna a Syatam Bus

• Uaing tti* S8180 Raal Tima Ctock

• Tha SCSI Intartaoa: SoNwara tor tha SCSI

• knida Ampro Computar*

• NEW-DOS: Tha CCP Commands
(continuad)

•ZSIOComar

• /Mtordabia C Compllars

• Corteurrant Multitasking: A Ravlaw of
DoublaDOS

• 680C0 TinyOlant Hatwlhoma's Low Coat
1»bit sac and Oparabng Syatam

• Tha M of Sourca Coda Qanaration:
Dt saaa a m bling Z-SO Softwara

• Faadback Conbol Syatam Analysis: Using
Root Locus Analyaia ft Faadback Loop

• Tha C Column: A Oraphica Primltiva
Padcaga

• Tha KWacM HOO4180: Naw LH* tor 8-blt

• ZSIO Comar Command Lin* Ganarators

• A Tutor Program In Forth: Writing a Forth
Tutor in Forth

• Diak Paramatars: Modifying the CP/M Disk
Parai n ata r Block for Foraign Disk Formats

• Starting Your Own BBS

• Buikl an A/D Convartar for tha Ampro LKNa
Board

• HD64180: Sailing tha Walt Statas ft RAM
Rafrash uaing PRT ft DMA

• Using SCSI lor Raal Time Control

• Opan Lattar to STD Bus Manufacturers

• Patching Turbo Pascal

• Chooaing a Language for Machine Control

• Ballar Softwara Fillar Design

• MDIStC Adding a 1 Mag RAM Oiskto
Ampro Little Board, Part 1

• Using the Hitachi hd64180: Embedded
PiLN asuj Daalon

• 68000: Why use a new OS and the 680007

• Detecting the 8087 Math Chip

• Floppy Disk Track Stniclura

• Double Density Fkippy Controller

• ZCPR3 lOP lor the Ampro LitU* Boerd

• 3200 Hackers' Language

• MDISK: Adding a 1 Meg RAM Diskto
Ampro Little Boerd, Part 2

• Non-Praampllve Multitasking

• Scftwai* Tlnwrs for tha 68000
•LilMputZ-Ncde

• Using SCSI for Qenersltatad I/O

• Communicating wHh Ftoppy Disks: Disk
F>aramater* ft their vaiiatnns

• XBK)S: A Replacemant BIOS for the
SB180

• K-OS ONE and the SAGE: Demystifying
Operating Systems

■ Remote: Dealgning a RsnralB System
Program

• The ZCPR3 Comer ARUNZ
Documentation

laaue Number 32:

- 15 copiee now available -

ittwNgniHfH;

• Data File Conversnn: Writing a Filter to
Convert Foraign File Formats

• Advanced CP/M: ZCPR3PLUS ft How to
Wiila Self Rakwating Code

• DataBaaa: The First In a Series on Data
Baaes and Informatkm Processing

• SCSI for the S-100 Bus: Another Example
of SCSrs Versatility

• A Mouaa on any Hardware: Implementtng
the Mouaa on a Z80 Syatam

• Syatematic Elimlnatton of MS-DOS Files:
Part 2, Subdirectories ft Extended DOS
Sarvicea

• ZCPR3 Comer ARUNZ Shells ft Patching
WordStar 4.0

laaue Number 34:

• Davatoping a File Encrypdon System.

• Database: A continuation of the data base
primer series.

■ A Simple Multitasking Executive: Designing
an embedded cor<troller multitasking
executive.

• ZCPR3: Retocalabia code, PRL files,
ZCPR34, and Type 4 programs.

• Naw Microoontrollers Have Smarts: Chips
with bask: or Forth In ROM are easy to
program.

• /Kdvancad CP/M: OS axtanstons to BDOS
and BIOS, RSXs lor CP/M 2.2.

• Macintoah Data File Convetskxi In Turbo
Pascal.

• All This ft Modula-2: A Pascal-like
aitamatlve with scope and parameter
passing.

• A Short Course in Source Code Generatkxi:
Disassembling 8068 softwara to produce
modifiable asaem. sourca code.

• Real Computing: The NS32032.

• S-100: EPROM Bumerproiect for S-100
hardware hadtars.

• Advanced CP/M: An up-to-dato DOS, plus
datalla on file structure and formats.

• REL-Styla Assembly Language for CP/M
and Z-Syatam. Part 1: Selecting your
asaambier, linker and debugger.

Issue Number 86:

• Information Engineering: Introduction.

• Modula-2: A list of refeter)ce books.

• Temperature Measurement ft Control:
Agricultural computer appik^bon.

• ZCPR3 Comer Z-Nodos, Z-Plan, Amstrand
computer, and ZFILE.

• Real Computing: NS32032 experimenter
hardware, CPUs in series, software options.

• SPRINT: A review.

• REL-Style Assembly Language for CP/M ft
ZSystams, part 2.

• Advanced CP/M: Environmental

programming
Issue Number 37:
C Pointers, Arrsys ft Structures Made
Easier Part 1, Pointers.
ZCPR3 Comer Z-Nodes, patching for
NZCOM. ZFILER.

Information Engineering: Bask: Concepts:
fields, field deAnitkxi, client woricsheets.
Shells: Using ZCPR3 named shell
variablea to store deto variaWas.
Resklent Programs: A detailed kiok at
TSRs ft how they can leed to chaos.
Advanced CP/M: Raw and cooked console
VO.

ZSDOS: Anatomy of an Operating System:
Parti.

laaue Number 38:

C Math: Dollars and Cents With C.

Advanced CP/M: Batch Processing and a

NewZEX.

C Pointers, Arrays ft Structures Made

Easier Part 2, Anay*.

Z-Systsm Comer Shells and ZEX, Z-Node

Central, system security under Z-Systems.

Information Engineering: The portable

Information Age.

Computer Akied Publishing: Introduction to

publishing snd Desk Top Publishing

Shells: ZEX and hard disk backups.

Real Computing: Tha National

Samkxmductor NS320XX

ZSDOS: Anatomy of an Operating System,

Part 2

laaue Number 3»:
Programming for Performance: Assembly
Language technk;ues.
Computer Akjed Publishing: The HP
LaaerJel

The Z-System Comer System
enhancements with NZCOM.
Generating LaserJet Fonts: A review of
Digi-Fonts.

Advanced CP/M: Making oki programs Z-
System aware.

C Pointers, Arrays ft Structures Made
Easier Part 3: Sbuctures.
Shells: Using ARUNZ alias with ZCAL.
Reel Computing: The National
SemkXHiduclor NS320XX.

Issue Number 40:

Programming the LaserJet Using the

escape codea.

Beginning Forth Column: Introduction.

Advanced Forth Cokrmn: Variant Records

and Modules.

LINKPRL: Generating the bit maps for PRL

files from a REL file.

WordTech's dBXL: Writing your own

custom designed business program.

Advanced CP/M: ZEX S.O'The machine

and the language.

Programming for Performance: Assembly

language technk)ues.

Programming Input/Output With C:

Keyboard and screen functions.

The Z-Systam Comer Remote access

systems and BOS C.

Real Computing: The NS320XX

Issue Number 41:

F'^rth Column: ADTs, Object Oriented

Concepts.

Improving the Ampro LB: Overcoming the

B8Mb hard drive limit

How to add Data Structures in Forth

Advanced CP/M: CP/M Is hacker's haven,

and Z-System Command Scheduler

The Z-System Comer Extended Multiple

Command Lir>e, and aliases.

Disk ar>d printer functions with C.

LINKPRL: Making RSXes easy

SCOPY: Copying a series of unrelated

• Dynamu Memory Altocation: Altocating
memory at runtime with examples in Forth.

• Using BYE with NZCOM.

• C snd the MS-DOS Character Attribute*.

• Forth Column: Lists and object oriented
Forth.

• The Z-System Comer Genie, BDS Z and
Z-System Fundamentals.

• 68705 Embedded Controller Applk^atioii: A
single-chip microconboller application.

• Advanced CP/M: PluPerfect Writer and
using BOS C with REL files.

issue Number 43:

• Standardize Your Ftoppy Disk Drives.

• A New Hiatory Shell for ZSystem.

• Heath's HDOS, Then and Now.

• The ZSystom Comer Software update
ssrvne, and customizing NZCOM.

• Graphics Programming With C: Routines
for the IBM PC, and the Turtio C library.

• Lazy Evaluation: End ttie evaluation as
soon as the result Is known.

• S-100: There's still life In the okl bus.

• Advanced CP/M: Passing parameters, and
complex error recovery.

laaue Number 44:

• Animation with Turtjo C Part 1 : The Basic
Tods.

• Multitesking in Forth: New Mk:ros FeSFCII
and Max Forth.

• Mysteries of PC Floppy Disks Revealed:
FM, MFM, and the twisted cable.

• DosDisk: MS-DOS disk emulator for CP/M.

• Advanced CP/M: ZMATE and using k)okup
and dispatch for passing parameters.

• Forth Column: Handling Strings.

• Z-Systom Comer MEX and telecommuni-
cations.

Issue Number 48:

• Embedded Systems for the Tenderfoot
Getting sterted with ttie S031 .

• Z-Systom Comer Using scripte with MEX.

• The Z-Systom and Turbo Pascal: Patching
TURB0.COM to access the Z-Systom.

• Embedded Applkntions: Designing a ZSO
RS-232 communications gateway, part 1.

• Advanced CP/M: String searches and
tijning Jetfind.

• Animation with TurtJO C: Part 2, screen
interactions.

• Real Computing: The NS32000.

Issue Number 46:

• Build s Long Distance Printer Driver.

• Using tt<e 8031 'a built-in UART .

• Foundational Modules In Module 2.

• The Z-System Comer Patching The Word
Plus spell checker, and the ZMATE macro
text editor.

• Animation with Turbo C: Text In the
graphica rrxxla.

• ZSO Communications Gateway
Prototyping and using the ZSO CTC.

Issue Number 47:

• Contrdling Stopper Motors with the
88HC11F

• Z-System Comer ZMATE Macro Language

• Using 8031 Intemjpte

• T-1 : What It is ft Why You Need to Know

• ZCPR3 ft Module, Too

• Tipa on Using LCDs: Interfacing to the
68HC705

■ Real Computing: Debugging, NS32 Multi-
tasking ft Distributed Systems

• Long Distonce Printer Driver correction

• Roeo-soGgo

Issue Number 48:

• Fest Math Uaing Logarithms

• Forth and Forth Assembler

• Modula-2 and tha TCAP

• Adding a Bernoulli Drive to a CP/M
Computer (Buikjing a SCSI Interface)

• Review of BDS "Z"

• PMATECMATE Macros, PI 1

• Z-System Comer Patching MEX-Plus and
TheWord, Using ZEX

Issue Number 49:

• Computer Networic Power Protection

• Floppy Disk Alignment w/RTXEB, PI 1

• Motor Control with the F88HC1 1

48

The Computer Journal / #76

• Controlling Homa Healing & Lighting, Pt 1

• Gatting Started In Aaaembly Language

• PMATE/ZMATE MacnM, Pt 2

• Z-Syatam Comer/ Z-Beat Software

• Offload a Syatam CPU vwith the Z181

• Floppy Oiak Alignment w/RTXEB, Pt 2

• Motor Control wnth the F68HC11

• Modula-2 and the Command Line

• Controlling Home Heating & Lighting, Pt 2

• Getting Started in Aaaembly Language Pt 2

• Local Area Nelworka
•LMngtheZCPR3IOP

• PMATBZMATE Macroa, Pt 3

• Z-Syatem Comer, PCEDI Z-Beat Software

• Real Computing, 32FX16, Cachea

'«"» number 51:

• Introducing the YAS8EC

• Floppy Oak Alignment w/RTXEB, Pt 3

• High S peed ModeiTW on Eight Bit Syatema

• A ZS Talker and Hoat

• Local Area Nelworka— Ethernet

• UNIX Connectivity on the Cheap

• PC Hard Diak Partitkin Table

• A Short Introductkm to Forth

• Stepped Inference in Embedded Control

• Real Computing, the 32CG160, Swordfish

• PMATE/ZMATE Macioa

• Z-Syatem Comer, The Trenton Festival

■ Z-Beat Software, the Z3HELP System

l8tu«NumbT52:

• YAS8EC, The Hardware

• An /M)itrary Waveform Generator, Pt 1

• B.Y.O. Aaaembler...in Forth

• Getting Started in Aaaembly Language, Pt 3
•TheNZCOMlOP

• SenaeandtheF68HC11

• Z-Syatem Comer, Programming for
Cornpatibillty

• Z-Beat Software

• Real Computing, X10 Revisited

• PMATBZMATE Macrae

• Controlling Home Heating & Lighting, Pt 3

• The CPU280, A High Performance SBC

l««ua Number 53:
•TheCPU280
' Local Area Itletworks
■ Am Arbitrary Waveform Generator
' Zed Feat '91

' OelUng Started in Aaaembly Language
•TheNZCOMlOP

Issue Number 54:

' B.Y.O. Aaaembler

' Local Area IMworks

' Advanced CP/M

' ZCPR on a le-BH Intel Platform

■ Real Computing

' Intemjpta and ttie Z80

' 8 MHZ on a Ampro

- Hardware Heavann

' What Zilog never told you about the Supers

' An Arbitary Waveftxm Generator

' The Development of TDOS

Issue Number 55:

■ Fuzzitogy 101

The Cyclk; Redundancy Check in Forth
The Internetwork Protocol OP)
' Hardware Heaven
Real Computing

- Remapping Diak Drives through Virtual
BIOS

The Bumbling Mathmatician
YASMEM

Issue Number 86:

TCJ - The Next Ten Years

Input Expanskm for 8031

Connecting IDE Drives to 8-Bit Systems

8 Queens in Forth

Kaypro-84 Direct File Transfers
' Anak)g Signal Generation

Issue Number 5T:

Home Aulomatnn with X10

File Transfer Protocols
' MOISK at 8 MHZ.
' Shall Sort in Forth
' Introduction to Forth

DR. S-100

Z AT LaatI

Issue Number 88:

- Multitaakir>g Forth

* Computing Timer Values
Affordable Devek>pment Tools

' Mr. Kaypro
DR. S-100

Issue Number 59:
' Moving Forth

Center Fokl IMSAI MPU-A

Devek>ping Forth Applk»tions

Mr. Kaypro Review

DR. S-100

lasue Number 60:
' Moving Forth Part II
Center Fokj IMSAI CPA

■ Four for Forth

- Debugging Forth

' Support Groups for Classica

- Mr. Kaypro Review
DR. S-100

Issue Number 61:

' Multiprocessing 6809 part I

Center FoM XEROX 820

Quality Control
' Real Computing

Support Groups for Classk»

Operating Sy^ems - CP/M

Mr Kaypro SMHZ

Issue Number 62:
SCSI EPROM Programmer
' Center FoM XEROX 820
■OR S-100

- Moving Forth part III

" Programming the 6526 CIA

- Reminiacir>g and Muainga
Modem Scripts

Issue Number 63:

SCSI EPROM Programmer part II

Center FoM XEROX 820

OR S-100
' MuWpiocessing Part II

6809 Operating Systems
- Reminiscing and Musings

IDE Drives Part II

Issue Number 64:

Small-C?

Center Fold last XEROX 820

DRS-10O

Moving Forth Part IV

Small Systems

Mr. Kaypro
' IDE Drives Part III

Issue Number 68:

' Small Syatam Support

Center FoW ZX80«1

DR S-100
' Real Computing
' European Beat

PC/XT Comer
' Little CircuKa
' Levels of Forth
' Sinclair ZX81

Issue Number 66:

Small Syatem Support
' Center FokJ: Advent Decoder

DR S-100

Connecting IDE Drivea

PC/XT Comer

Little Circuits
' Multiprocessing Part III

Z-System Comer

Issue Number 67:
' Small Syatam Support
Canter FoM: SS-SOrSS-30
•DR S-100

' Serial Kaypro Interrupta
' Little Qrcuits

■ Moving Forth Part S
- European Beet

Issue Number 68:
Small Syatem Support

' Center FoM: Pertec/Mits 4PIO
Z-System Comer II

■ PC/XT Comer
Little Qrcuits

' MuKipiocessing Forth Part 4
' Mr. Kaypro

Issue Number 69:
Small Syatam Support
' Center Fold: S-100 IDE
' Z-System Comer II
' Real Computing
• PC/XT Comer
' OR. S-IOO
' Moving Forth Part 6
' Mr. Kaypro

Issue Number TO:

Small Syatem Support
' Center FoM: Jupiter ACE
■ Z-System Comer II
• PC/XT Comer Stepper Motors

DR. S-100

Multiprocessing Part 5

European Beat

Issue Number 71:

Computing Hero of 1994
' Snnall System Support

Center FoM: Hayes 80-1 03A

Power Supply Baaica
' PC/XT Comer Stepper Motors

DR. S-100

Moving Forth Part 7
' Mr. Kaypro
' 8048 Emulator Part 1

laaue Number 72

- Beginning PLO

' Small Syatem Support

Centw FoM: Rockwell R65F11
' Playing Witt) Mksroa
' Real Computing

Small Toola Part 1
' DR. S-IOO

Moving Forth Part 7.5

8048 Emulator Part 2

Issue Number 73

$10 XT

Small System Support

Center FoW: 640K XT

IDE Parte

Real Computing

Small Toota Part II

DR. S-100

Mr. Kaypro
■ PC/XT Corenr
'8048 Emulator Part 3

laaue Number 74

Antique or Junk
' Small Syatem Support

Center FoM: S-100 Power Supply
' Movirig Forth part 8

Real Computing

AMSTRAD PCW Now

DR. S-100
' Mr. Kaypro
' Palmtech CPLIZ180
' Disk IA3 in Forth

Issue Number 75
' The European Beat
' Small System Support

Center FoM: Standard Bua VO

Moving Forth part 8
' Real ComfMjting
' Embedded Control Using ttie STD Bus

DR. S-100
' EPROM Simulator
' High-Speed Serial I/O for ttw PCPI Applteard

Disk I/O in Forth, Pt 2
' TSeoO Source Code

U.S. Canada/Mexico Europe/Other

Subscriptions (CA not taxable) (Surface) (Air) (Surface) (Air)

1year (6 issues) $24.00 $32.00 $34.00 $34.00 $44.00

2years (12 issues) $44.00 $60.00 $64.00 $64.00 $84.00

Back Issues (CA tax) add these shipping costs for each issue ordered

Bound Volumes $20.00 ea -i-$3.00 ■i-$3.50 +$6.50 -t-$4.00 -»- $17.00

#20 thru #43 are $3.00 ea. -i-$1.00 +$1.00 -i-$1.25 -i-$1.50 -t-$2.50

#44 and up are$4.00ea. +$1.25 +$1.25 +$1.75 +$2.00 +$3.50

Items:

Back Issues Total

h4ame:

California Residents add 7.25% Sales TAX

Shipping Total
Subscription Total
Total Endosed

Address:

Credit Card #

.«P.

J_

Payment is accepted by check, nrwney order, or Credit Card (M/C,
VISA, CarteBlanche, Diners Club). Checks must be in US funds,
drawn on a US bank. Credit Card orders can call 1 (800) 424-8825.

TCI ] The Computer Journal

P.O. Box 3900, Citrus Heights, CA 95611-3900
Phone (916) 722-4970 / Fax (916) 722-7480

The Computer Journal / #76

49

Regular Feature

Editorial Comment

New Editor?

The Computer Corner

By Bill Kibler

Welcome to issue 76's Computer Comer
and n^ last as editcv. Next time I'll be
doing this column as just a contributing
editor. Will it be different, yes and no.
Mostly I'll have more time to ponder
and do research. I have considered fo-
cusing more on aae topic which is what
I did before becoming editor. But I think
I might still hit a few "take this world"
tcqncs even still. Take for instance the
last Embedded Systems Conference.

ESC

The Embedded System Conference this
year, was not v/txen I thought it was.
Like many readers, you get so much
mail, that when it comes in, you half
look at it I did that with the flyer from
the conference. Fortunately, I tack it with
me, for when I arrived in front of last
years meeting hall, no conference. I fi-
nally decided to read the flyer very closely
only to discover it was in San Jose Con-
vention center, about ten miles east some-
where.

After getting k>st more than once by
following incorrect signs, I did get to the
big new center that was packed with
peoide. The opening day is called Octo-
ber Feast as free beer and munches are
provided after 7PM. I over heard a few
of the ladies responsible for setting the
show up, and they were commenting on
how two to three times the number of
peoide showed up that they had pre-
pared for. Needless to say many went
away hungry and iq>set from the food
festival portion. I did get my usual beer
mug however, so I have no complaint in
this area.

As to vendors, they all seemed to be
there, the big guys that is. I always find
the show a bit strange, since very few

small vendors can afford to go there. It
pretty much is like most things in
America. All the hoopla is over the big
vendors which have a small part in the
overall market, while the little guys who
do all the real work can't even afford to
pay the floor space fees. It is sort of like
the fortune 100 get all the publicity,
while something like 95% all business
income comes fit)m con:q>anies with less
than 25 workers and who most people
have never heard of Embedded control
is really like that too.

A FEW Surprises.

I was stuprised by a few of the displays.
Heading the list was IBM. I didn't ex-
pect to see them at all, but they had three
booths. The main large one was pushing
OS/2 and e^)ecially OS/2 Connect. I
asked so many question about connect,
that I got a free copy of DOS 7 so I would
go away. The fimny thing about DOS 7
was what I did before the show. I needed
a copy of CP Backup and had tried to
find one without luck. When I got home
and opened my free DOS 7 package, I
was pleasantly surprised to find CP
Backup is now a part of DOS 7. For
those who have not tried DOS 7 by IBM
do so, you will like it. I found it better
and I think IBM may keep making it
better, while Microsoft has definitely
abandoned the DOS market.

Microsoft was there, but so low key, they
might as well have not bothered. IBM
on the other hand also had a booth for
their RISC chip for embedded systems. I
think it was a version of the RISC CPU
used in their RS6000 system. That con-
cept is sort like the Intel 386 version for
embedded controllers. The idea here is
to make moving programs from an de-
velopment platform into the real world

simpler and easier. My problem is, who
needs another high powered CPU to do
what a cheaper and simpler 8 bit CPU
can do.

IBM is also starting to confront the op-
erating system people, with their version
of a real time kernel. Somewhat based
on OS/2, they have a group starting to
develop a real time operating system. It
is just starting to take off and they said
next year it will be a full package. I think
they will have problems competing with
all the other vendors, especially OS/9
which I think is probably number one.
I'll be reviewing OS/9 in a later article.

Of Note

Motorola was there and I asked about
their latest HC05 development board. It
seems they changed the development
package and you must now use an
EPROMs to load from. In the past it was
possible to do serial loading, but they
dropped that. The person there didn't
like my comments and reaction to find-
ing out about the change. I guess they
don't want to heard about the bad things
they do.

Now don't get me wrong, most of the
vendors were only selling $10,000 sys-
tems and support products, yet a few of
the others were able to show up. You do
feel like your running around in the land
of the giants until you get back into the
small booth area. Here you find all the
small guys and even a few who's prod-
ucts you might be able to afford.

I was feeling still a little lost till I came
across parvus Inc. These people have
done their homework and provide an
incredible line of products (801 483-
1533). I am interested in PC based.

50

The Computer Journal / #76

memory mapped 8031 interface cards.
Not oiJy did they have one, but I could
have my choice of Z 1 80, 68HC 1 1 , 803 1 ,
or 80166 onISAorPC104 formats. They
had all types of industrial software inter-
faces and even real 1/0 cards (relays and
opto/isolators). It was like the concept of
"one stop shopping." A single verjdor
who can fill your every need. Pricing
was fair, neither high nor low, but the
options just got me, like the choice be-
tween being a co-processor on the PC
bus, or taking the bus over and talking to
expansion cards. How about a 68HC1 1
nmning the PC bus? Sounds interesting
to me!

Another item of note, was Siemens way
of getting you a development systems.
Instead of charging the usual low show
price, they were giving them away. That
is right, free if you got four of the six
support vendors to sign their card off.
The idea here was to make you sit through
the support vendors lectures (typically
about a half hour each and trying to sell
you a $ 10,000 support package) and then
you get the free system. 1 figured it would
have taken me all day to do that, so I
didn't get the free unit. Nice idea if you
have the time and I expect to see more
sales approaches like it next year.

Other fronts

I finally had the chance to use AP Cir-
cuits of Canada last month. We had a
board needing proto typing and opted to
use them. I couldn't be happier. I up-
loaded the file on Tuesday morning, and
we had the board in house Friday morn-
ing. Cost was $99 for two boards about
3 by 6 inches each. The work was excel-
lent, although all we had them do was
their proto 1 service (two sided no silk or
solder mask). Most proto houses want
$200 to $300 setup charges before mak-
ing even one board. Their BBS has free
layout programs and information for
"would be" circuit builders. Cost wise it
beats doing it yourself, for all but the
simplest of boards. (AP Circuits (403)
250-3406 voice, (403) 291-9342 BBS or
mcmuldd@cadvision. com. )

I am considering trying to setup a deal
with them for TCJ circuits. The idea
would be based on giving them the

Gerber files needed to make a TC/ board.
Readers wanting one of the boards would
just call up and give them a credit card
number and two days later you get two
cards. I am not sure why, but all their
runs are based on producing two cards at
a time. The cost would be a little higher
than us producing a large run of cards,
but then we don't get stuck with order-
ing, shipping, handhng and storage cost.
You need the board, simply call and zap
it is in the mail faster than we would be
able to do so.

I would like to hear from readers who
have found a cheaper or faster option to
get two sided platted through boards. (1
checked out several units at WESCON,
only the cost of the machines that would
put a light plating in the were expensive,
and the cost per hole was 5 cents each!)
We checked many places and they by far
are the cheapest and seem to be very
good. Like I say the boards looked great
and we had them NOW!

On the software front, I am starting to
look at Linux as my operating system of
choice. It has so much going for it, it
gets really hard not to become hooked
on it. You should also get one of the
Linux bibles or FAQ reprints. These
books (typically 1200+ pages) have tons
of usefiil information about Linux and
PC's in general. I have started using
mine as a reference book about PC parts.
Found out why not to use 3C50 1 etherrvet
cards on 486's, too slow and too small
buffer space.

Now with Linux and unlike Microsoft
products, you always get source code
with the CDROM release and it seems to
exceed any other product for power and
options. If your looking for "how to"
write some driver code, or how a
CDROM works, consider looking at the
source code inside Linux. They talk to
most all the PC devices available.

What little I have done so &r has im-
pressed me to no end. I recently got a
Sony 3 IB CDROM and had trouble find-
ing a driver that worked on DOS. Linux

found it and was able to run from it,
right from the floppy.

1 tried many of the Sony DOS device
drivers, all with no luck. I was told that
maybe the older drivers might work. I
eventually found a box of cheap disks
that were from a sound card. The label
said drivers for Sony and Panasonic
CDROMs and were 10 cents each. The
driver label was SLCD.SYS and it works
just fine. Since I have had many requests
for CP/M systems being able to talk to
CDROMs, I have been a bit more inter-
ested in talking to them now. I was about
to try writing my own driver, based on
using the Linux code until I fourtd SLCD.
My early reading however, brought up a
minor problem with a CDROM for CPM.

If I remember right, CP/M has a maxi-
mum drive size of 32 megs. My studies
so far indicate at least 512 megs must be
minimum limit. So right off, we got one
problem, how to deal with 660 megs of
file system. The file format is not even
DOS compatible, which is why you need
MSCDEX on DOS boxes, to convert the
CDROM directory to one DOS can un-
derstand. The only approach I can think
of would be a separate program that
treats the CDROM as a database, where
entries are files, allowing you to retrieve
records and save them to a local drive.
This is some early musings about the
problem and I certainly would like to
hear your ideas on the subject.

Mail

Since I no longer am editor of TCJ, you
need to use my personal or Kibler Elec-
tronic business e-mail address. The PO
Box 535 Lincoln is still a good mailing
address, but e-mail is
kibler@psyber.com. I have started a per-
sonal web page at http://
www.psyber.coni/~kibler and will try and
put things of interest there as well as in
TCTs web page. So far the web page is
{TCJ's that is) getting lots of good re-
views, even though it is not the fanciest
one aroimd. We keep ours a little sim-
pler so peq}le downloading the files don't
have a lot of extra text to deal with. That
means non-windows users can still get
information from us on the n^. So till
next issue. Keep hacking.

The Computer Journal / #76

51

TCJ CLASSIFIED

CLASSIFIED RATES!
$5.00 PER LISTING!

TCJ Classified ads are on a prq>aid basis
only. The c»st is $5.00 per ad entry.
Siqjport wanted is a fi:ee service to sub-
scribers who need to find old or missing
documentation or software. Please limit
your requests to one type <£ system.

Conunercisd Advertising Rates:

Size Once

4+

FuU $120

$90

1/2 Page $75

$60

1/3 Page $60

$45

1/4 Page $50

$40

Market Place $25

$100/yr

Send your items to:

The Computer

Journal

P.O. Box 3900

Citrus Heights, CA

95611-3900

Historically Brewed. The magazine of
the Histwical Computer Society. Read
about the people and machines which
changed our world. Buy, sell and trade
"antique" computers. Subscriptions $18,
or try an issue for $3. HCS, 2962 Park
Street #1, Jacksonville, PL 32205

Start your own technical venture! Don
Lancaster's newly updated INCRED-
IBLE SECRET MONEY MACHINE

n tells how. We now have autogr^hed
copies of the Guru's underground classic
for $21.50. Synergetics Press, Box 809-
J, Thatcher AZ, 85552.

THE CASE AGAINST PATENTS

Throughly tested and proven alternatives
that work in the real world. $33.50.
Synergetics Press, Box 809- J, Thatcher
AZ, 85552.

FOR SALE: TRS80 Model III, 48K, 2
flq}pies, 5meg hard drive, hi res graph-
ics, carrying case, excellent confition,
with many books and much software,
spare Model ni mother board for parts.
TRS80 Model 4, works but needs repair.
Disk drive for TRS80 Model 100, like
new, bodes, and software. Orginal TRS80
Pocket Computer with cassette and
printer interface, software and books.
Sinclair 2K80, extra memory module,
books and software. Jerry Owen, 1264
T.R. Smith Rd., EUabell, GA 31308.

/r

TCJ ADS WORK!

Classified ads in TCJ

get results, FASTI

Need to sell that special older

system - TRY TCJ.

World Wide Coverage

with Readers interested in what

YOU have to sell.

Provide a support service,

our readers are looking for

assistance with their older

systems - all the time.

The best deal in magzines,

TCJ Classified

it works!

V

J

FOR SALE: Kaypro hard disk con-
troller cards, WD series for 2/4/ 10s.
Motherboards for all models now in
stock. Complete replacement monitors
and other new items for yoiu Kaypro
needs. Mr. Kaypro, Chuck Stafford.
(916) 483-0312, eves/weekends.

THE LOWEST COST!!
PLD PROGRAMMER

Get started with Programmable Logic without the
higti costs! Partial kits start as low as $40 00
Complete kit as shown $179 00 Plans and SW
on disk (PC format) $10 00 Programs the
GAL16V8. 20V8 and 22V10. Call or use our
FAX-BACK for information.

ALTA ENGINEERING
(860) 489-8003 VISA/MC

CMBs

Electronic Design

Dave Baldwin

6619 Westbrook Dr.
Citrus Heights, CA 95621
Voice (916) 722-3877
Fax (916) 722-7480

BBS (916) 722-5799

TCJ

Library

Subscriptions

Thank you to our subscriber's that

have donated subscriptions to their

public libraries around the world.

Paul MacDiarmid

has contributed a

subscription to the

Rotonia Public Library

in Rotorua, New Zealand.

This is an excellent way to support

TCJ and spread the word.

52

The Computer Journal / #76

Market Place

TCJ-

neCom^u^rJouma^

Discover
The2^Letter

Tltc Z-letter is the only publication
OBEfaavely for CP/M and the Z-System.
Sagje oomputera and Spelllnnder support.
Ijeeaaed CP/M distributor.

^iMeriptions: $18 US. S22 Canada and
iSaaeo, S36 Overseas. Write or call for
8w sample.

The Z-Letter

Lambda Software Publishing

149 West HiUiard Lane

Eugene, OR 97404-3057

(S41) 688-3563

CP/M SOFTWARE

[100 page Public Domain Catalog,
($8.50 plus $1.50 shipping and
ladling. New CP/M 2.2
(nanual $19.95 plus shipping.
[Also MS-DOS software. Disk
[coining including AMSTRAD.
id self addressed, stamped
slope for free Flyer, Catalog
|$1.00.

€lliam Associates

Box 2664
Atascadero, CA 93423

S-100/l€€€-696

lAASfll filtQir

Compupro Morrouu

Cromemco

-m

ond morel

Cards* Docs •Systems

Dr. S-lOO

Herb Johnson,

CN 5256 #105.

Princeton, NJ 08543

(609)771-1503

hjohnson@pluto.njcc.com

Advent Kaypro Upgrades

TurboROM. Allows flexible

configuration of your entire

system, readAwrite additional

formats and more, only $35.

Replacement Floppy drives and
Hard Drive Conversion Kits. CaH
or write for availability & pricing.

Call (916)483-0312

evss, weekends or write

Chuck Stafford

4000 Norrls Ave.

Sacramento, CA 05821

Kibler Electronics

Hardware Design &
Software Programming

8051, 6805, Z80, 68000, x86

PLC Support and
Documentation

Bill Kibler

P.O. Box 535

Lincoln, CA 95648-0535

(916) 645-1670

4-mall: klbltr@piyb»r.com
\ htlp://www.psyb»r.com/~kibl»r ,

THE FORTH SOURCE
Hardware & Softwara

MOUNTAIN VIEW
PRESS

Glen B. Haydon, M.D.

Route 2 Box 429
La Honda. CA 94020

(415) 747-0760

TCJ MARKET PLACE

Advertising for small business

First Insertion: $25

Reinsertion: $20

Full Six Issues $100

Rates Include typesetting.

Payment must sccompany order.

VISA, MasterCard, Diner's Club,

Carte Blanche accepted.
Checks, money orders must be

US funds. Resetting of sd

consitutes a new sdvertlsement

at first time Insertion rates.

Mall ad or contact

TAe Compufr Journal

P.O. Box 3900

Citrus Heights, CA 9SC11-3000

MORE POWER!

68HC11,80C51a80C166

More Microcontrollers.
EI Faster Hardware.
Faster Software.
EI More Productive.
B More Tools and Utilities.

Low cost SBC's from $84. Get I

it done today! Not next month.

For brochure or applications:

AM Research

4600 Hidden Oaks Lane

Loomis, CA 95650

1(800)949-8051
sofia@garlic.com

$79

.95

8K EEPROM for More
Program Spsotf

SBI-*C.Op«aMllK
_ ^^^

68HC11

Single Board
Computar

SBC-8K

jab«, 33'«3y<'

Low Pb^nt, <ia MA

sinsnnEEnioM

TStBrtftUM
I»»SS-232
24-TTLnOBito
S-A/DI

SMhEdock
LoaDitewiftSBB-eC

A CofflpMa saHCII Oevatopnant Sysiaai.
Naw 'CodaLoad-f 2.0' and Sampla PrograMia.

No EPROMserEPROM Programmersl

500 PagM of Mamiala, 3.5* UIMly DMt.

LOG Electronics fR

1445 Parran Road vaiM/tai

St Leonard, MO 20685 410-586-2177