Issue # 18 DTACK GROUNDED Newsletter - April 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

SOFTWARE STATUS REPORT:

M000se Systems has added to the operating manual of their chess program so that mere chess players can run the program. We will play a few practice games and then play M000se on the record - and in front of witnesses! The next issue should carry a listing of the game in both FICA and standard U.S. notation. We will have the excuse that we got beat by our own 12.5MHz DTACK board if we lose!

Even better, PHASE ZERO, the folks who sell the 68000 cross-assembler we have standardized on, has announced that they have begun serious development of a 68000 BASIC. They say their version will be similar to Applesoft. It will use the double precision floating point and transcendental package we have published here (with our full blessings). Don't send them a check yet; they have a ways to go. About $100? Yum!

A DTACK FORTH PACKAGE:

Following is a press release from Bruce Walker:

A full fig-FORTH implementation is now available for the DTACK GROUNDED 68000/Apple configuration. It includes the fig editor and numerous other utilities. These include:

1. A file oriented editor for assembly development
2. PL/1 (or COBOL) style data structures
3. Hex and character constants
4. Control structure primitives to build CASE statements or multiple exit loops or...
5. FORTH decompiler
6. Automatic insertion of tracing code during compilation
7. Recompilation of words without recompiling all calling words

FORTH can use Apple DOS text files and binary files. Files can be created from FORTH on either drive. Compiled vocabularies can be saved as binary, avoiding

Page 1, Column 2

reloading from source.

How fast is FORTH on the 68000? About the fastest FORTH around! Here are the results of some benchmarks using an Apple II and a 12.5MHz DTACK board:

 TESTCASE          6502      68000       RATIO 

 string search     37.6 sec   2.28 sec    16.5 
 sieve            208        10.68        19.5 
 Kilobaud          16.9        .63        27 
 random numbers    16.1        .36        45 
 binary search     79.6       1.74        46

String search looks for a 5 character string at the end of a 390 line file using the file oriented editor, utility #1.

Sieve is the 'sieve of Erastothenes' benchmark used in the Jan '83 BYTE. They list another FORTH as taking 27 seconds on an 8MHz 68000.

Kilobaud is Kilobaud BASIC benchmark #7, translated to FORTH. It takes 44.8 seconds in Applesoft.

Random numbers generates 10,000 pseudo-random numbers by the linear congruential (? - FNE) method.

Binary search looks up 1000 numbers in a 4096 word sorted table using binary search.

FORTH is supplied with a 20 page manual. Users who are inexperienced with FORTH should also get a tutorial, such as Leo Brodie's 'Starting FORTH.' It is available at technical bookstores or by mail from the FORTH Interest Group, P.O. Box 1105, San Carlos, CA 94070 ($16 U.S., $20 foreign for paperback; $20 and $25 for hardcover).

68000 FORTH requires a 64K DTACK board, an Apple II/+/e and DOS 3.3. The price is $30 U.S. & CAN, $35 elsewhere. The assembly source is available on disk in PHASE ZERO format for $15 U.S. & CAN, $20 elsewhere. Prices are in U.S. funds and include mailing costs. Send your check or international money order to:

Bruce W. Walker
900 W. 14th Street #10
San Pedro, CA 90731

We have made no secret of the fact that we do not like many aspects of FORTH ourselves. What we have perhaps not emphasized is that we are interested in FORTH to the extent that we have subscribed to 'FORTH DIMENSIONS', the publication of the FORTH Interest Group (fig), since it started and before DTACK started.

Page 2, Column 1

ABOUT EXPORT LICENSES:

The government of the United States has recently become very nervous about shipping militarily useful technology out of the country. As a result, an export license is required, but only if you are making militarily useful technology. In other words, a license is required only if the Department of Commerce decides you need one. If they decide you have been shipping stuff you shouldn't, you can naturally be in big, big trouble with big brother, er, Uncle Sam.

Naturally, we decided to check with the Dept. before exporting our big dynamic RAM board. So we called their L.A. office and found that their phone was answered by an automatic switchboard and a recording in a pleasant contralto: "Thank you for helping to reduce America's export deficit. An operator will be with you in a moment."

Sure enough, an operator came on the line and in surprisingly short order we were connected to an Assistant Undersecretary in charge of computer exports.

"Quiggle P. Fogbottom here! What kind of computer did you say you were planning to export, son?" Sort of a toy computer to work as an attached processor with home and personal computers, we replied.

"Good, good. Sort of a VIC-20 with 4K RAM, I suppose? I know all about computers, son. Been around them twenty years! Incidentally, my friends call me 'Kewpie'. That's a little joke there, son!" Actually, Mr. Fogbottom, we replied, our board has a megabyte of RAM.

"Oh, a wise guy, eh? What's this 'toy' computer called, an IBM 370?" Actually, we weren't kidding, sir. It really is a toy computer.

"With a megabyte of RAM? Come on now! Remember, ol' Kewpie his been around computers since the 360 was wearing training wheels! You talk a megabyte of RAM, you're talking mainframe boy! What kind of CPU you got on your computer? I wanta know about the addressing range, the size and number of the registers and stuff like that." Well, our CPU can address about 16.7 megabytes and it has 32 bit registers. Between 16 and 18 of them, depending on your definition of a register, we answered.

"Son, are you absolutely certain you aren't trying to export a 370? That's the same addressing range and it sounds like the registers might be the same. I'm not sure about that since I left IBM before the 370 came on line. But what I am absolutely sure of, boy," pausing for effect and drawing a breath, "is that what you are talking about is no toy computer! How many MIPS does

Page 2, Column 2

that thing run at anyhow?" Our toy runs at a little over one MIPS, we admitted.

"A little over one MIPS, eh?" Lowering his voice, he continued: "Suppose you tell ol' Kewpie just what this computer of yours is used for?" Actually, we think the most common use of the DRAM version of our toy is to shoot rocks.

"AN AUTOMATIC WEAPONS AIMING DEVICE!! AHA!! Son, I hate to say this but I think you are some kind of Commie lover and we absolutely positively are not going to let you export no mainframe automatic weapons aiming device to those Godless Commie Russkies!" Sir, we explained, we don't want to export to Russia, we want to export to West Germany. The West Germans aren't communists, they are democrats like us. And they aren't Godless. They worship somebody named Martin Luther, we think.

"Shoot rocks, huh? Just what is it that operators use to shoot those rocks, boy?" We never thought about that, sir. We suppose they must use laser beams.

"That's just great! That's just hunky-dory! You want to export an automatic laser weapons aiming device with mainframe capability? Son, if you aren't a Commie you are sure one stupid capitalist. Just how much are you peddling this thing for, anyhow?" About $1800, we replied.

"$1800? Oh, that's right, you export boys talk in thousands of dollars. Like I said, I know computers and I know it's possible to build a mainframe for less than one mill these days. Maybe you're not such a dumb capitalist after all. Now, this is off the record," he continued, "but it sounds like, say, 5% off the top wouldn't damage your bottom line at all, boy." Sir, we explained patiently, the price really is about $1800, NOT 1.8 mill, as you say.

"You're selling that big weapons device to the enemy for a lousy $1800??" he shrieked. "That does it, you dammed traitor! For your information, military intelligence, the CIA and the FBI have all been listening in on this call and I am extraordinarily pleased to inform you that your firing squad will arrive in," (here Fogbottom pauses and a new voice comes on the line) "exactly 41 seconds."

With that the line was cut off and the automatic switchboard came back on with its canned message, "Thank you for helping to reduce America's export deficit." We could hear the sound of marching soldiers outside. The canned message concluded in its pleasant contralto, "Have a nice day!"

Page 3, Column 1

WHAT WAS ALL THAT ABOUT?

We were using a (hopefully) humorous way of letting you know that we are not going to offer our dynamic RAM version of our board for sale overseas. It is not that we are being high-handed or inconsiderate. There are those rules and, until we can convince the appropriate bureaucrats that our board is closer to being a toy than an automatic weapons guidance device, we will restrict sales to the U.S. of A.

Yes, the basic board only holds a half megabyte. You will need an expansion board to get a full megabyte. Anybody want to know our poetic license number?

We don't make-a the rules, guys.

In fact, we have been questioned with increasing frequency lately by our air carrier over our standard board. Remember, our standard board uses Japanese static RAMs and a microprocessor which is also made in Japan. The shipments that are being questioned are the ones to West Germany, where we are competing with the IBS 68000 board, which has more memory at 128K than our 92K static RAM board. And we know of one company which HAS an export license for a complete computer system which includes our DTACK board.

Nevertheless, if enough heat is put on us we will be forced to suspend all shipments outside the U.S. for any of our boards. We do not know whether a tiny company such as ourselves can realistically obtain an export license. We do not know whether a separate license is required for each country of destination.

So, if you are one of those Godless Commie foreigners and you find us returning a check for one of our boards instead of shipping you a board, rest assured that we will feel worse about it than you do. (For the altruistic reason that we are not helping reduce America's export deficit, of course!)

Let's sneak in some HALGOL stuff here: you will remember that we intend to start with a language which supports floating point variables and variable arrays only. That in turn raises the question of how we intend to handle constants. Here's how:

We will support constants in an almost identical manner as normal named variables. You will recall that we will have a variable table with 8 bytes per variable. We have a 32 bit pointer, 'SOV' (Start Of Variables) to point to the beginning of the variable table. We will have another 32 bit pointer, 'SOVN' (Start Of Variable Names). To accommodate constants, we define a 16 bit value 'NOC' (Number Of Constants).

Page 3, Column 2

We will refer to constants as 'constant variables'. The first N variables in the variable table will be constants. If there are no constants N is allowed to be zero. The value N is what is stored in 'NOC'.

Now, suppose we encounter a line such as:

 87  LOAD 123

What we want to do is load a floating point number whose value is decimal 123 into the accumulator. However, we know that the keyword 'LOAD' generates an action address where the machine code expects the next word of the HALGOL program to be the offset address from 'SOV' where the value of the variable, as an 8 byte floating point number, is to be found. Also, when the program is stopped for editing purposes, the line should list out just as it is above.

The solution is simple. First we define constants as 'constant variables' to emphasize their similarity to named variables. Then we place all of the constant variables together in the first N positions of the variable table. Suppose that '123' is the 5th constant variable. Then, naturally enough, the corresponding entry in the variable name table is (surprise) "123"!

Note how neatly this solves the problem of listing a constant which is carried in the program as the offset address of its floating point equivalent value. The listing process is exactly the same as listing a named variable! In the case of constant "123", being the fifth offset value from the pointer 'SOV', the address following the action address of "LOAD" in the HALGOL will be hexadecimal 0020 (there are 8 bytes per variable and the first variable number is zero, remember). So, when listing the name of that variable the LIST function will look at the address following 'LOAD', determine that we have here the fifth variable in the variable table and will therefore list the fifth entry in the variable name table. Which is "123". Voila!

In fact, the main difference between constant variables and the named variables is that the named variables are initialized to zero at the start of the program, but constant variables obviously are not initialized to zero. That's why we need the value N stored in 'NOC'. That lets us know where we begin zeroing the variable table at the start of the program.

Obviously we need to save the names of all the variables, including constant variables, when saving the HALGOL program to disk. What is not clear is whether the floating point equivalents of those constant values should be saved to disk also or whether they should be re-created from the constant variable names (stored in the variable name table) when the

Page 4, Column 1

program is loaded from disk. This is probably a judgement call based on whether we have a small slow floppy or a big fast hard disk. Both methods work, and there is much to be said for things which work, so we don't plan to worry about it.

IMMEDIATE VARIABLES:

In addition to named variables and constant variables, we will support immediate variables. An immediate variable is an 8 byte value imbedded in the HALGOL program. The action address (and the program listing function) will obviously have to handle such a variable (really a form of constant variable) differently. So instead of LOADing such a variable, let us LOAD$ the immediate variable. We have already snuck this function into the run-time HALGOL package; see newsletter #17, page 23, lines 122-130.

A line number containing an immediate variable could look like this:

 92 LOAD$ 1001 8000 0000 0000

or

 92 LOAD$ 1001 800000000000

or

 92 LOAD$ 1001800000000000

In other words, spaces within the hexadecimal representation of the floating point number would be permitted for clarity but otherwise ignored. It would seem reasonable to list the line in the form of the first example above.

And if you want to know why we are implementing immediate variables, it is because your FNE has often wished he had such a function available. And that's enough about HALGOL for the time being.

In the last newsletter we picked on what we believed was a mailing list program written by Jim Strasma. Here is Jim's reply:

"FNE had the misfortune, (in issue #17, p. 12), of receiving a less-than-legal and less-than complete copy of my only commercial program. Had it come with the usual several pages of instructions, or the available source code listing, FNE would discover it is not a mail list. $35 buys a machine-language sort; nothing more. Back when some people still used cassettes, the sort came on one side of a cassette, and a demo to prove it works came an the other. It was a good value; next best price, $50+. A.D. (After Diskettes), the sort is still accompanied by the demo and instructions.

Page 4, Column 2

Those who read listings will also find extensive remarks in the demo program. Elizabeth Deal recently reviewed the sort in Midnite/PAPER #11. (Commodore owners are welcome to a sample copy of that issue on request.)

As an example of use, I added a small data file manager to the disk version along with other files, pointing out in the instructions that the extras are free, not sold. It takes no longer to copy a disk full than empty, so why not?

Had FNE asked me for a mail list in one of our many chats, I would have sent Chris Bennett's, a Public Domain package I have supported, documented, and modified for 2-1/2 years. It is currently described in a 6-part series in Micro magazine. Most first-time users like it. Due to the volume of mail I receive, I charge $15 for a copy. But anyone who has it is welcome to give it to friends, including FNE. (signed) Jim Strasma.

(Sigh. You readers are not going to believe this, but we do, on rare occasion, get things straight.)

The following is taken from John Dvorak's column in Infoworld, 28 Feb '83: "Don't throw out your assemblers department: Rumor has it that some of the Pascal software for Apple's LISA will be recoded in assembler to speed up certain routines.

"I thought that these superchips, like the 68000, were supposed to be so fast that they'd allow software development in high-level languages. But time and again people find that compiled code from high-level languages gets outperformed by machine-coded Z80s."

Gosh! We guess we will have to stop recommending to our DTACK readers that they use Pascal rather than assembly code! Now, why didn't we know that assembly outran Pascal??

(The very next paragraph from Infoworld) "UNIX may slow things up even more. One data-base developer in the 16-bit world has found that its DBMS runs 40 times faster in an MS-DOS environment than under UNIX on the same machine. This is all because of operating-system overhead.

"Combining sluggish compiled code with UNIX or other large operating systems will keep the never-ending demand for assembly-language coding alive and well."

Gosh! You don't suppose that that UNIX operating system would run faster on a fast hard disk than a slow floppy, do you?

Page 5, Column 1

MISCELLANEAE:

On the very day that we mailed issue #17, we received an issue of Electronic News with a front page story: IBM announces a 4 inch floppy disk. Gee, we wonder why they developed a floppy that's not compatible with anyone else's?

Beginning this issue, we will stop using capital letters to show emphasis, and use boldface instead. You see, our CBM 8032 with Wordpro 4+ didn't allow boldface. At least, not with the third party IEEE 488 to Centronics interface we use. We think. But we aren't using the 8032 to prepare this issue. We are using two Eagle II computers, one at home and one at work. We are using the Eagle II because it has a very crisp, readable CRT. The 8032 was causing some eyestrain problems for us recently.

Don't ask us how much memory the Eagle has, or what interfaces, or what CPU even. We don't know and we don't care. We are going to use our Eagles exclusively as word processors. It comes with a word processor (with the keys marked to work with that particular processor), a spreadsheet, CBASIC and CP/M on three diskettes, respectively. We'll probably never take the CBASIC & CP/M diskette out of the binder. The spreadsheet will probably get looked it sometime, out of curiosity, but not now or real soon.

The Eagle CRT uses a 9 X 11 dot matrix. The characters are green on a black background and an anti-glare coating is used. There is a nice intelligently planned black 'frame' around the CRT. We are almost certain that the Eagle doesn't have graphics. It is a very dull, businesslike machine which will never ever develop an active user's group.

Here is the latest tally on the computers we have: besides the two Eagles we have three Apple II+s, one Apple IIe, one CBM 8032 and our old, creaky Wang 2200 which is due for imminent retirement. Our future acquisition plans include a Wang 2200 SVP and maybe another Apple IIe, this one for our use at home (68000 software development, you know). Oh, yes: we have a LOBO MAX-80 with two 8 inch single side, double density disks. Shugarts, naturally. The LOBO works absolutely perfectly. We do not currently use it for anything, and, frankly, we are beginning to suspect that we have a well built dinosaur on our hands. Do you realize how big 8 inch floppies look when you have become accustomed to 5 1/4 inch units?

Thus, it is interesting to note that the number of our CP/M machines has gone from none to three in just two months. The LOBO maybe has a good future: an outfit in West Germany is going to (try to) hook our Apple compatible DTACK board up to some S-100 CP/M machines.

Page 5, Column 2

They tell us that they can handle the software, and the hardware interface is simple and easy. Although the LOBO does not use the S-100 bus structure, it does have a nice parallel bus expansion connector on the rear (this is the only thing wrong with the LOBO unit; that connector is labelled 'I/O expansion bus' instead of 'DTACK adaptor').

WEST GERMANS NOTE:

We now have ten or twelve West German customers. Four of them have given us their permission to pass their names along to other West German DTACK customers. We suggest that most of you might want to do the same thing. In fact, you might want to consider forming a user group. We can send updates on floppy disks much more frequently to a user's group than to lots of individuals. The mailing rates are murderous to your country from here.

Apple Computer Co. Report:

We have decided to stop bashing Apple Computer over the head, for two reasons. One is that others are doing the job for us. Infoworld is continuing to bludgeon Apple with regularity. But the editor of Electronic Engineering Times, as we reported last issue, has done a far better job than we or Infoworld could ever manage. The editor's name is Girish Mhatre. He evidently has an English education. You see, the English traditionally bury the knife in your back so delicately that you don't notice.

About that editorial and its shocking last line: we have to explain some background.

Berlin, Dresden, Hiroshima and Nagasaki are thriving centers of commerce where laughing children play in the streets. World War Two, historically speaking, momentarily inconvenienced those cities. We have to go back to Carthage and Troy to find major cities which were permanently destroyed. The Homeric legend includes Cassandra, who accurately foretold the impending disaster. Nobody believed her, of course.

Back to the editorial. That editorial discussed Apple's new products and its management and pricing policies evenhandedly. If you do not read the last sentence of the editorial, you would not know whether the Editor favored those policies or not. Here is that last sentence:

"I, for one, would like to see the naysayers proved to be Cassandras."

We are just an amateurish would-be newsletter editor and there is no way we could hope to compete with rhetoric like that. So we won't try.

Page 6, Column 1

OUR XMAS CARD ARRIVES!

Another reason we are going to stop picking on the Apple Computer Co. is that they hive been incredibly nice to Digital Acoustics lately. They have not only sold 750,000 Apple IIs for us to hang 68000 attached processors on, but they have brought out an improved model, the IIe. They will doubtless sell another 3/4 mill of the IIes, thus doubling our potential customer base. The presence of the IIe also - and this is important - keeps the perception of the II+ as that of an ongoing product worthy of continued attention and support. Without that perception, we would sell a lot fewer attached processors for the II+. That is a fine Xmas card, indeed!

But it gets even better! They have finally introduced LISA, a very good, very expensive 68000 machine (as everyone expected). Now, anyone who can read a price tag knows that LISA is not for the same people who buy IIs or lIes. Apple even admits that LISA is for Fortune 1000 companies (those are big companies, guys). And yet (this is the part that is incredible) Apple is dragging LISA around to shows and user group meetings, such as the one in Boston attended by about 1500 enthusiasts. LISA is bringing standing ovations at those meetings! Xmas card hell, that is a partridge in a pear tree for us!

Apple is sensitising those Apple II owners to the desirability of a 68000 with a large memory space! And guess who is making such a device that works with the Apple II those folks already own, and at an affordable incremental price? Now, we ask you: would you knock an outfit that is as nice as that to your organization?

All of you know that there are a large number of IBM PC clones around. One of them, called Compaq, is distinguishable by its carrying handle. Big difference, right? Well, you will not be surprised to learn that about ten of its design engineers are being sued for stealing anther company's trade secrets. IBM is suing them, right? Well, no. It seems they are being sued by T.I. Hmmm...

We were recently insulted (we think) by one of our readers. Regarding the bit from Wireless World in the last issue he stated, "Somebody must have sent you that clipping. You wouldn't subscribe to one of those idiosyncratic British publications!" We informed that reader that we have subscribed to Wireless World for over 20 years now.

At least, we thought we had been subscribing! Last

Page 6, Column 2

year WW reprinted Arthur Clarke's 1947 article on synchronous communications satellites and some #%@&!* in WW's accounting department decided it would be too expensive to mail that reprint to foreigners!

We will have our revenge! The next time we have a nice, long, useful bunch of source code in the (former) Redlands, we are going to delete that section from issues being mailed to British subscribers! What is sauce for the goose is sauce for the gander...

A Fortune 500 company is, simply, one of the 500 largest companies in the U.S. with size being determined only by their sales in dollars, as determined by the staffers at Fortune magazine. Naturally, IBM, General Motors, Du Pont and the like are to be found on that list.

In their last fiscal year, Wang Laboratories broke $1 billion in sales for the first time and became a Fortune 500 company for the first time. In their last fiscal year both Apple and Tandy sold over $500 million but less than $1 billion and did not make the Fortune 500 list. Apple is projecting sales of about $1.2 billion this year and also predicting that they will become a Fortune 500 company. If they accomplish this, they will set a new record for the shortest time achieving the Fortune 500 honor roll from the time the company is founded (yet another reason why it is a good idea not to pick on the Apple Computer Co!).

Tandy may well break the $1 billion barrier in its next fiscal year; they have a shorter way to go than Apple. We need to keep in mind, of course, that qualifying for the Fortune 500 list involves a moving target. On the other hand, the smokestack industry sales, companies like U.S. Steel, have not been showing spectacular sales increases lately. Small computer sales (in dollars) are supposed to increase by a factor of 1.82 this year (we forget where we read that, but it sounds about right) which is roughly the factor they have increased in recent years.

What this means is that the small computer industry sales are doggone near doubling every year lately. It should be no surprise that some of the leaders are busting into the Fortune 500.

The winners are those companies which increased their sales faster than the industry rate. One way to increase your sales faster than the industry rate is to start from a near-zero base, such as IBM and Digital Acoustics did last year. (As an editor, we have been looking for some time for a legitimate way to mention IBM and Digital Acoustics in the same sentence.)

Page 7, Column 1

Another way is to utilize 'price elasticity' to more than double your sales volume in dollars in one year. This is the route taken by Commodore, which more than doubled its sales in its most recent fiscal year (in the U.S.). You may be interested to know that the VIC-20 was selling for $134.88 in Fed-Mart (L.A.) this past week.

Now, why is this newsletter reading like Mini-Micro magazine? Because we had to establish a background for our next commentary on Mini-Micro, that's why. You may recall that, last issue, we picked on them for making a two order-of-magnitude technical error. Well, that's O.K. because Mini-Micro is not really a technical magazine, it's a sales and financial magazine. Now, if Mini-Micro made a two-order-of-magnitude error in sales or dollars they would be legitimate game for ridicule.

Guess what?

In their Jan '83 issue, on page 23, Mini-Micro asserts that Microsoft, the Industry Standard Basic (ISB) people, are going to sell !!!! $3 billion !!!! this year, just in XENIX licenses! Ye gods and little fishes! Mini-Micro asserts, right there in print, that Microsoft is going to sell enough XENIX licenses to propel three companies into the Fortune 500 ranks! This year!! Can't those people at Mini-Micro get anything right??

You probably know that there are some companies in this business which announce a product to see if they can sell enough units to make it worthwhile to produce the product. One such company is Televideo. (Maybe we are another? There does not seem to be such interest in the 68008 board we 'trial ballooned' with static RAM a few issues back.)

Perhaps you read the article 'Televideo Axes Unix-Based m/C" in EN, Jan 31 '83, p26. If not, here are excerpts from that article:

"Instead, Mr. Zurcher said, demand didn't develop for the Unix-based system in sufficient quantity to satisfy Televideo that volume production should be started.

"Frankly, we haven't seen a lot of excitement for this type of product...

"Mr. Zurcher said the Televideo Unix systems generated a lot of interest, but not a lot of business..."

Perhaps Mr. Zurcher should be reading Mini-Micro, where he will learn that one software company alone is going to sell $3 billion in Unix-compatible licenses this year?

Page 7, Column 2

We go along, trying to find a way to explain that something like the apparent overwhelming popularity of UNIX is in fact a Boojum (i.e. imaginary) when we find that someone else can condense the entire argument into a single sentence. So, with an appreciative nod to Mr. Zurcher, we present the following:

UNIX is generating a lot of interest but not much business.

Not everything published in Mini-Micro is rubbish. When we rub that fact up against the fact that we prefer when possible not to re-publish preceding issues of this newsletter (a la Dear Abby) we discover that this is an excellent time to present a few quotations from Feb '83 Mini-Micro:

From p.84: "Intel had such a large installed base for its 8-bit chip [the 8080] that it had to come out with a 16-bit version of the 8-bit chip to save that base... Intel designed the 8086 so that application software need not be rewritten" (attributed to Miles Rickard of Ryan-McFarland).

Also: "...its upgraded chips have essentially the same instruction set. The 8086 is just patch upon patch. The instruction set (is) unsymmetrical, (and) attributes of instructions change radically from one to another. It's a compiler designer's nightmare" (attributed to Roger Melen of Cromemco).

(An aside from us; the 186 and 286 are object code compatible with the 8086!)

Also: "...(the) break with a more primitive type of instruction occurred when Motorola decided to abandon its 8-bit base. Motorola leapfrogged to a 32-bit chip and then came out with a 16-bit version they could (build). In radically changing its architecture and instruction set, Motorola abandoned existing software as well. In the short term they may suffer but in the long term, they're probably going to have better success" (attributed to McFarland's Rickard).

Those of you with long memories will recall similar assertions in these pages. Like 16 or 17 newsletters (and 1 1/2 years) back.

We more recently asserted that there was a fierce battle going on within Intel over whether to make the 386 a real computer or an 8080 emulator. We can now reveal that the all those warehouses full of 8080 code, not one of which has burned down yet, have caused the 8080 emulator faction to emerge victorious. The iAPX 386 will not be a real computer.

Page 8, Column 1

AN INTRODUCTION TO THE 7220

The NEC 7220 is a powerful and versatile graphics controller chip. We are going to give you a brief introduction to this device which will figure prominently in our plans and in the plans of many other companies.

The part comes in 4MHz, 5MHz and 5.5MHz versions. The -1 part is 5MHz, the -2 is 5.5. Since we had intended to run at 5MHz, our two vanilla 4MHz parts may turn out to be paperweights after all. All of the following discussion will assume the use of the -1 (5MHz) part.

The most important thing to know about the 7220 is that it can draw lines and arcs of circles at the rate of one pixel every 0.8 microseconds. By comparison, a 12.5MHz 68000 can plot pixels (straight lines only) at between 7.5 and 8 microseconds per pixel when mapping into the equivalent of the (very convoluted) Apple II HIRES graphics page. If the mapping of the graphics page is more conventional, it might be possible for the 12.5MHz 68000 to plot pixels at the rate of 5 microseconds per pixel, but certainly not faster. So, the 7220 is about 8 times faster than a 12.5MHz 68000 or 20 times faster than a 5MHz 68000 machine like LISA.

The fact that the 7220 can handle graphics plotting over ten times faster than conventional-speed 60000s is why you are going to see a lot of 7220s built into small computers this next year.

In addition to writing pixels to the display RAM, the 7220 handles the address sequencing and horizontal and vertical sync signals. Therefore, the simplest possible form of 7220 graphics display has same fairly basic constraints. Suppose we have the simplest possible system using 64K DRAMs. This would be a monochrome (black and white) display. Because the 7220 writes 16 bit words, the smallest possible memory configuration using 64K X 1 chips would be 128K (16 chips). That would be a megabit (8 bits/byte times 128K bytes) which would normally be tapped as 1024 X 1024 pixels.

Because the 7220 can only send one 16 bit word to the video refresh circuitry every 400 nanoseconds, the full 1024 X 1024 pixel plane cannot be displayed in a single 1/60 second, or one video frame time in the United States. In fact, since about 25% of that 1/60 of a second is not viewable due to the horizontal and vertical retrace delays, we are limited to what can be displayed in about 12 to 12.5 milliseconds, depending on the exact retrace timings of the video monitor used.

That means we can display only 30,000 to 31,250 16 bit words during one video screen time of 1/60 second. Which is less than half the total available memory.

Page 8, Column 2

The alternative is to use an interlaced screen so that 1/30 second is required to update the screen. This requires the use of a long persistence phosphor, which is undesirable with rapidly changing graphics images. For instance, our demo graphics programs D6 and D6A do not look very good an the monitor which comes with the Apple IIe package because a long persistence phosphor is used in that monitor.

So if we use a conventional short persistence phosphor and refresh the entire screen every 1/60 second, our vanilla 7220 graphics system is limited to that 30,000 to 31,250 16 bit words or 480K to 500K pixels. Before you turn up your nose, remember that the Apple's 280 X 192 HIRES screen contains less than 54K pixels!

Let us digress for a moment and mention something which has nothing directly to do with the 7220. It would be very nice if a graphics display had a unity aspect ratio, meaning that a horizontal line 100 pixels long would be exactly the same length as a vertical line 100 pixels long. This is not true of the Apple II HIRES screen, by the way. Since a CRT is about 1.28 to 1.33 times longer in one dimension than the other that means we need something like a 640 by 480 graphics image. That's 307.2K pixels, which means the slower, cheaper 4MHz 7220 can be used and nice cheap slow DRAMs can be used. That's why you are seeing so many devices coming out with roughly 640 by 480 graphics displays.

Let's calculate the largest display format we can have, assuming about a 1.3 horizontal to vertical ratio and 480K pixels. We take the square root of 480K, which is about 692. The number of horizontal pixels will be the square root of 1.3 times this number and the number of vertical lines will the about 692 divided by the square root of 1.3. This gives us roughly 790 pixels horizontally by 607 pixels vertically.

Next we must remember that our memory is organized as 16 bit words, so that the number of horizontal pixels needs to be an even multiple of 16. This will result in either 49 or 50 16 bit words, or either 784 or 800 horizontal pixels. 800 is a nice even number which permits assigning 10 horizontal bits per character for an 80 column display, so let us choose 800 pixels horizontally. Dividing that into our maximum 480K total pixel display gives us exactly 600 vertical lines. 800/600 equals 1.33, so we are on target for our unity aspect ratio.

Therefore the cheapest 7220 displays will tend to be about 640 X 480 while high performance 7220 displays will be about 800 X 600. We hope it's obvious that neither of these is achievable with the sort of monitor you would connect to your Apple II, for the simple reason that these monitors only have about 262 non-interlaced vertical lines, and part of these are non-

Page 9, Column 1

usable at the very top and the very bottom. On the other hand, we suspect that 640 X 480 displays are going to become so common that they will become a defacto-standard item within a year. 800 X 600 monitors will probably always be custom items and therefore expensive. That 640 X 480 looks better and better as we examine this matter.

The next thing you ought to know about the 7220 is that, since it generates the address sequence for the refresh memory, it cannot write to that memory during the 75% (appx) of the time that the screen is being written to unless you are willing to live with the disrupted display. The 7220 can write to the display RAM essentially all of the time using 'flash mode'. This has nothing to do with deviants in raincoats; 'flash' is descriptive of what the CRT looks like while you are using this mode.

If you do not want the screen to be disrupted then we must use the normal mode, in which the 7220 only writes to memory during the 25% of the time that pixels are not being sent to the CRT. This 25% is, mostly, the horizontal retrace time.

This would seem to drastically reduce the speed advantage of the 68000 versus the 7220, but remember that the 68000 also has the problem of not disrupting the display. Apple's LISA cures this problem by alternating the memory between the CRT and the 68000. Unfortunately, this results in the 68000 being limited to a 5MHz clock rate. We suggest that you read the last 3 or 4 paragraphs on page 106 of Feb '83 BYTE magazine very carefully. In that apparently casual interview, some exceptionally careful words were used describing why LISA does not use the 7220. The last paragraph on that page gives the true reasons: LISA's design predated the 7220 and they decided not to re-design. As far as the argument over cost, forget it. The Epson HX-10, at less than $3K, uses the 7220. One somehow suspects that Apple could have found room in $10K for a 7220 if they had wanted one.

However, the words used in the interview apparently led a BYTE editor to assume, elsewhere in that issue, that the 68000 is a superior graphics machine to the 7220. Not so. You will note that we do not name the specific editor. It does not pay to pick an argument with people who buy ink by the railroad carload!

And we are not picking on Apple on this matter; taking out the memory interleaving (which, like the Apple II, handles the DRAM refresh as well) would mean a total electrical redesign of LISA. Given Apple's desire to introduce LISA as a thoroughly tested product, that was impractical.

Here's more about the 7220. You will remember that we

Page 9, Column 2

had a potential 1024 X 1024 pixel display. The 7720 is capable of writing pixels into that size display and then 'windowing' a portion to the CRT such as our old friends the 640 X 480 or even the 800 X 600. In fact, the 7220 can scroll that window around the 1024 X 1024 area in hardware without redrawing to the memory. So a paddle can be used to scroll the smaller window around the virtual display smoothly.

If you pick up the spec sheet on the 7220 or the user's guide you must be very conscious that the clock (or CLK) and the 2XWCLK are one and the same and are the same frequency and even the same signal! NEC's literature is not always clear about that one point. One can become very bollixed if one assumes that the one is twice the frequency of the other, as we can personally attest.

Incidentally, if we are going to dump 480K pixels to a CRT in 12 milliseconds, that figures to a pixel rate of 40MHz! Better figure on fast shift registers (hint, hint)!

This concludes our brief introduction to the NEC 7220, which was restricted to the use of the 7220 in a simple, vanilla application. In the next issue, we will (possibly) discuss how to use the 7220 in somewhat less simple applications.

We have received several letters recently asking us to comment on LISA. We decline except for specialized comments like those above where our hardware background gives us an advantage over the average reader. Aside from an analysis of the hardware, we don't know more about it (right now, that is) than the well-informed (well-read) reader does.

The important thing about LISA, hardware-wise, is that it sports a 68000 with one megabyte of dynamic RAM.

It seems that the only real question for now is how well LISA will sell to its intended FORTUNE 1000 market. Same observers say it will fall an its face, others say it will go like gangbusters. All of these observers are guessing, of course. We don't know anyone with a properly calibrated crystal ball.

The one thing we know for sure is that the more LISAs Apple manages to sell, the better off Digital Acoustics will be. The reason is simple: lots of LISAs will whet the hobbyist's appetite for 68000 machines with big memories. Guess what kind of board is being laid out for us right now by an outside consultant!

Go get 'em, Apple! We're rooting for ya!

Page 10, Column 1

UNIVERSAL OPERATING SYSTEM?

Most of us are well aware of the extensive advertisements of a certain software company which asserts that it offers a universal operating system. Its ads tactfully suggest that if you do not write your programs on that operating system, then you may eventually find yourself employed as an ice cream vendor, street division, or a peanut salesman in a fair or circus.

As it happens, we have crossed paths with that company a couple of times lately with somewhat surprising (to us) results. One of the things we did was contact them to determine whether it is financially possible for a small company like ourselves to provide their operating system (and three associated languages) with our Apple compatible 68000 board. The answer, as we expected, is no.

We thought you might like to know why it is financially impossible for us to offer that system with our boards. This will require some background. First, it was a letter from a newsletter subscriber who precipitated our call to the software company. He had written that he was interested in doing the BIOS (basic I/O system) to adapt that Operating system to the Apple II/DTACK environment. He then planned to recover his investment by selling that BIOS to the other 10 or 12 (by his estimate) DTACK customers who would be interested in having that system.

It wound up that he called the software house, mentioned his plans, and received their complete confidential price lists. Yes, lists plural. Then we called, during COMDEX as it happened, and were answered by a clerk who really didn't have much information. But she did send us a set of those price lists. The next week we received a phone call from one of their regular salesmen, who asserted that he had been with them for several weeks. He also sent us a copy of those price lists, with his business card attached. The business card asserted that his title was "Senior Sales Representative". (We wonder what his title will be after he has been there, say, six months?)

By our count, that's three sets of price lists sent out with not even a letter on company letterhead requesting them. However, when we specifically asked whether the price list was confidential we were told that it was. Therefore, we cannot give you specific prices but we will let you know what their general pricing policies are. These general policies will explain why we will not be offering that operating system with our boards in the near future.

Let us suppose that there are six companies offering that operating system with their equipment. Five of

Page 10, Column 2

these companies are the same size and the sixth is equal in size to the combined sales of the other five companies taken together. It should not surprise you that the software house will require an advance against royalties (technically, there is no license fee per se) from each of the live small companies that is a fifth of the advance required from the large company. This seems eminently reasonable, to us at least.

However, the per unit royalty charged the five small companies is about five times larger than that charged the larger company! In other words, each company will have to pay a monthly fee (based an unit sales) that is essentiallly the same as the monthly fee based on sales of the larger company.

And that means that, although the five smaller companies are, taken together, shipping the same number of units per month as the larger company, they are collectively paying five times as much as the larger company, for the same volume of sales. Why is the larger company getting the much better per unit royalty rate? The only discernable reason to us is that the larger company paid a larger up-front advance against royalties. The larger the advance, the lower the per-unit royalty.

It seems clear to us that the up-front fee is really the purchase of the right to a large OEM discount an the royalty. The larger the up-front fee, the larger the discount. Which means that large companies can afford to pass this software along cheaply but small companies cannot. And, you will recall, us folks here at Digital Acoustics, Inc. admit that we have here a small company.

As a result, one might expect that small companies won't offer that "universal operating system". Which means the system will become less than universal. Let us point out a corollary: any company, small or not, which does not offer that universal system either goes out of business or becomes a competitor. That is assuming the small company needs an operating system, as we will with HALGOL.

Despite the fact that the pricing policies of this software company clearly favor large companies, it is interesting to note that neither Apple nor Tandy nor Commodore offer that operating system with their products.

We selected the example of companies 5-1 different in size as a convenience. The pricing policies of that company cover a much larger range than that. Keep in mind that we have honored the confidentiality of their price list by not giving dollar amounts and by not giving their exact policies. Our example is pretty close to the facts, though.

Page 11, Column 1

DIOGENES IS SEARCHING YET:

We call your attention to our earlier statement that whatever companies do not adopt that standard operating system become competitors or go out of business. Since we are still here and have not adopted that system, we must be competitors. The little headline above indicates that the Greek philosopher Diogenes, who by legend went searching for a totally honest man, is still looking.

Because we obviously have an axe to grind, we assert that the story which follows is, of course, totally false. You will naturally investigate the matter personally to confirm that falsity.

Back in Sept or Oct '82, we received a letter from someone who had just traded his Apple II in on a medium-priced 68000 based machine which comes with that universal operating system. He wanted to know if our board could be hooked up to his new acquisition, explaining that he was a hardware hacker. We dropped him a short note telling him it was not practical.

As we indicated in the last newsletter, we took advantage of the year-end vacation lull to review our correspondence. On seeing that letter we thought, hey, this guy has owned this 68000 machine for 3 months now! If we call him, he will be able to give us a first-hand idea of what that machine is like! So, we called information at the address given (in a large but not major U.S. city) for his phone number. It turned out to be his home phone, but his wife (?) gave us his work number, where we reached him.

He gave the unit good marks hardware-wise. He also stated that it was nice to have an assembly package that didn't require him to take a 10 minute coffee break every time he ran an assembly. In contrast, the process ran so fast, he asserted, that it was hardly worthwhile to get out of his chair and stretch. We then asked him how many commercial packages were available on the universal operating system that came with his computer (this is the part that you will not believe). "One" he replied. "A spreadsheet."

Wait a minute! That is a universal system! There must be a lot of programs available for your system! (This conversation, which we do not expect you to believe, took place 1 Jan '83 plus or minus 10 days.) "Nope. Just the one commercial program." he insisted.

Are there any more owners of that computer in your area? we asked. "Five more" he replied. What are they doing for software? we asked. "Most of them are working to convert Apple programs written in Apple PASCAL to the PASCAL which comes with our machine" he replied. Not long after this, we hung up.

Page 11, Column 2

We were now in the concluding phase of our (unsuccessful) negotiations with that software house. A couple of days later, we asked them about the lack of commercial software for the "universal operating system." We were told that there was some mistake, that there were hundreds of programs available.

And that is where we left the matter until now. We did not write this up in the last newsletter because we figured absolutely nobody would believe us. In fact, even now we urge you to assume we are lying and to check the facts yourself.

(We have since heard, through rumor and not from the direct owner of one of those computers, that six or seven commercial programs are now available. Whoopee!)

We now call your attention to the Feb '83 issue of "Softalk for the IBM Personal Computer", page 4. In the letter titled "p-System Plaint" we find "...SofTech will not sell directly in the IBM format any of their products. Therefore, while SofTech claims great portability and transferability across machines, they do not support even the machines they advertise. The proof of the pudding is that you cannot buy from SofTech any of their software that you can directly use on the IBM pc."

There is a following reply, signed by Maura Smith, director of communications, SofTech Microsystems. In part the reply states "... (the) statement that SofTech Microsystems does not directly market the p-System for the IBM pc is correct." The letter goes on to explain that it is the responsibility of the vendor of the commercial software package to adapt that commercial software for specific products. And that explains why SofTech can claim that hundreds of commercial packages are available on their universal operating system yet the owner of a particular 68000-based computer can seriously assert that only one commercial package is available for his computer!

For the final time, we urge that you personally investigate this matter. But, please, check with a genuine private party owner of the computer in question. The answers you will get from a dealer (or from SofTech) regarding the number of commercial packages available may be optimistic...

After extensive research we can re-confirm Jim Warren's assertion, now several years old, that Fairchild and Honeywell are not planning a corporate merger, with the successor company to be named Fairwell Honeychild.

Page 12, Column 1

MISCELLANEAE II

In various conversations we have had with others in the personal computer industry lately, we have found no one who disagrees with our assessment that the proliferation of foreign add-ons his tremendously helped IBM sell the pc, just as all the foreign add-ons has (and does) help Apple II sales. Face it, there are four or more magazines devoted exclusively to the IBM pc and these magazines are supported mostly by the ads they carry for foreign add-ons. Not only does each ad necessarily promote the pc itself in addition to the add-on; those 4 or more magazines are each a huge advertisement for the pc.

IBM is, naturally, developing a successor to the pc which is intended to shut down all foreign add-ons. This new unit may be what is being announced March 9, a few days before you receive this issue (today is Feb 23).

As John M. of Las Cruces, NM has pointed out to us, one personal computer which has locked out foreign add-ons is the HP 85. Has anyone noticed, John points out, how many magazines there are which exist to promote the HP 85? It is no coincidence that the current issue of Electronic News (Feb 21) carries a large story on page 74 about the way distributers and retailers are dumping the HP line.

Let's see now, what other small computer has recently been introduced which has no visible support from foreign add-on suppliers? LINDA? No, that's not right...

We have received the promised additional documentation from M000se Systems so that now a mere chess player can run the M000se chess program. They continue to insist that the original instruction manual carried the complete command syntax (it did not, but their new addendum does). We have heard, for instance, the Castle called the Rook and even, in some languages, the Tower. So, what is the abbreviation for that piece? In fact, for a program written in Germany, what is the abbreviation for any of the pieces?

Also they continue to insist that P-K4 is obsolete chess notation, calling it "non-standard and obsolete American notation". It is not obsolete in this country! And, as we recall, M000se Systems expressed a willingness to accept money from the U.S. of A. The customer is always right, fellows...

(Would you believe frequently? How about sometimes?)

Page 12, Column 2

By the time you read this, we may have already held our annual stockholder's meeting. At this meeting we understand that our President will recommend that Digital Acoustics should get the heck out of the acoustic business. It is anticipated that shareholders representing at least 55.4% of the total stock will lend a sympathetic ear to this recommendation.

Nils, it's supposed to be a better mousetrap.

In George Orwell's 1984, a significant proportion of the populace was employed re-writing the history books to conform to (then) current dogma. A little of this can be seen in real life in the article beginning on page 272 of the Feb '83 issue of BYTE magazine. Mark Baretz managed to incorporate a short history of the development of the S-100 standard without once mentioning the fact that the IEEE Microprocessor Standards Committee ever ignominiously rejected a draft of that standard. This happened about a year ago, a time period covered in the last paragraph of the first column on page 276. The first mention of the IEEE committee is in the next paragraph, about 8 months later. Talk about newspeak!

On the other hand, it was apparently Mark himself who led the recovery from the earlier debacle. The new, approved IEEE 488 standard does not have all those old 'levels of compliance'. We wonder how long it will be before the manufacturers who needed those 'levels of compliance' to meet the standard will stop advertising that their products 'meet' IEEE 696? Until then, it will continue to be an exciting event to plug a newly purchased board into an S-100 computer.

We decided to check on this, so we drove over to the plant of a (fairly) local manufacturer of S-100 products. Displaying our "Clark Kent, reporter, Daily Planet, city of Metropolis" press credentials we managed to bluff our way into the President's office. The President was wearing yellow slacks, Nike jogging shoes and an Aloha shirt. A perfect Santa Anita racetrack uniform. We were just able to see the webbing on his forehead which held the toupee in place.

Have you heard that the S-100 standard passed, we asked. "Of course! After all, we are in that business. Why do you ask?" he replied.

Well, we understand that a couple of the S-100 boards you manufacture need some 'level of compliance' exceptions to qualify to meet that standard. And the approved standard omitted all those exceptions. "So?" he replied. So, isn't it true that those boards don't

Page 13, Column 1

meet the standard, we inquired. "No, they don't" he stated forthrightly.

Well, in this issue of BYTE you have this full page ad asserting that they do meet that standard, we insisted. "Aw, come on! You know perfectly well what the lead time is to have an ad agency put together a new ad, and place the ad with BYTE, and then wait four or more months for BYTE to publish the ad!" he retorted disgustedly.

Has your ad agency started re-writing a new ad, we asked. "Hell no! There's a recession on, in case you have'nt noticed. Ad agencies are expensive, you know!" he pointed out.

Is'nt that just a tad dishonest, we asked? He gave us a short, startled look and then walked behind his desk and sat down. "Why don't you have a seat over there and let me explain a few things to you" he suggested grimly.

"Look. No matter how soon we start on a new ad, the old ones will continue for it least six months because that's how long the pipeline is. The next thing you should know is that we may well not stop claiming we comply with the standard. We darn near do, and in most cases the tiny differences won't matter." He continued quickly, before we could butt in: "It just so happens that we have a payroll to meet, and we do care about our employees - maybe you don't?" he slyly suggested. "As you darn well know, it's tough to find another job these days."

"Now," he continued, "you are probably going to say we are dishonest. Just exactly who do you know who is perfectly honest in their ads? As you well know, Sage claims their 8MHz 68000 machine runs at two MIPS. Some 68000 product manufacturers claim a clock rate which is double the true clock speed. And don't you talk about a megabyte board coming up which in fact has less than a megabyte of RAM on it?" he asked. Well, it has almost a megabyte, we replied, squirmingly.

"And our board almost complies with the standard!" he retorted. "But ads are just one way of promoting products. You, for instance, use your newsletter to promote your products. Didn't you assert early an that you were going to build an 8087 accessory board once the part was real? Didn't some of your customers buy a board from your company based on that promise. And didn't" here he pointed at us, "you recently renege on that promise?" he asked, arching his eyebrows.

Well, um, we, er. "I have to leave now or I'm going to miss the third race." he stated, rising. "Anytime you want to come by and discuss Truth with a capital T, I'm available." he offered as we walked out of his office.

Page 13, Column 2

The following paragraph, entitled "ON THE NEED FOR PATIENCE", is reprinted from the Midnite/PAPER, issue #11:

"Two different long-term Pet owners just mentioned being upset with inpatient 64 owners. Those of you who just bought a 64 as your first computer often wonder why some programs aren't available for the 64 yet. What many of you don't realize is that good software takes years to develop. As one old-timer pointed out, in 1978 we were thrilled to have even one new program at a users' meeting. Personally, I am amazed that 64 owners can already buy a compiler (PETSPEED), a word processor (RTC-4 or Word Pro 3+/64), arcade games (Pakacuda, Motor Mania) and a Commodore assembler better than the one for Pet. We waited two years for a word processor, and over three for a compiler..." bylined Ken Penny.

We have forgotten why we reprinted the above. After all, we have been shipping our DTACK board for only fifteen months now and we have plenty of software, right? Even though we have a brand new (relatively speaking) CPU?

WE GET MAIL:

From Chester S., Iron Mountain NY: "I don't know what universities you are acquainted with, but I hope you are wrong about most universities in what you said on page 8, col 2, 2nd complete par. from top (#17). N.Y.U. and I assume many other universities teach a variety of programing languages. There were many sections of (courses on - FNE) BASIC (I taught it myself sometimes) and, I believe, several sections of FORTRAN taught each semester. Also fewer sections of several other programing were taught. The statement that, 'If the language is simple, the computer science profs won't be able to exhibit their obvious superiority.' shows a prejudice which would be better left unspoken."

Chester, we are glad to hear that there are other universities in the northeast besides Dartmouth (which we knew about) which support diverse programming languages. We are sorry to report that the situation here on the west coast is generally less encouraging. PASCAL, a nice pedagogical language, has in many universities become THE language.

Computer Science faculty members roam the campus and environs at night, wearing hooded cloaks and bearing firebrands and clubs, seeking out heretical students using a GOTO statement in the privacy of their own rooms. Torquemada is alive and well and is an associate professor of computer science at U.C. PASCAL.

Page 14, Column 1

WE GET MORE MAIL:

We received the following from Steve H. of Hudson Falls NY: "...in some respects you are all wet. The most obvious case of this is that you maintain that threaded code is the only similarity that HALGOL has to FORTH. Well, what is it that makes FORTH FORTH and not something else?

"First, the use of RPN (Reverse Polish Notation). This, I can't be sure of, because I don't know what HALGOL source code looks like, but the code certainly sounds like it would naturally use RPN.

"Second, the use of two stacks, the Data stack and the program stack. This is certainly the case in HALGOL as well.

"Third, the use of a list of (16-bit!) addresses as the compiled form of a program. HALGOL uses this also.

"Fourth, the 'dictionary' concept, in which all of the routines are linked together to facilitate searches.

"So far, all of the above match HALGOL to FORTH. What is the difference, then?

"Well, for one thing, it isn't that FORTH is written (mostly) in FORTH and HALGOL is written in assembler. There is no requirement anywhere that I have seen that says FORTH has to be written in FORTH. It is true that most of the microcomputer implementations of FORTH are, but that wouldn't disqualify HALGOL as a FORTH dialect.

"Another thing they have in common is that the GOSUB and RETURN code in HALGOL is exactly equivalent to the run-time behavior of ':' and ';' in FORTH. Now we get to the nub of the matter. The only basic (not BASIC) difference that I can detect between the two languages under discussion is that FORTH allows pyramiding of definitions, while HALGOL relies an BASIC-like subroutine calls to allow structured programing. The only major change that would be necessary to make HALGOL a full FORTH is to add a compile-time section to GOSUB and RETURN, equivalent to the compile-time behavior of ':' and ';' in FORTH. This would give you a REAL user extensibility, i.e. in the higher level, not only at machine level. That way, you don't have to be an assembly language programmer in order to improve the facilities available to you in programming. The BASIC subroutine call is a poor excuse for such an ability. That is why there are too many differing dialects of BASIC. DARTMOUTH BASIC is so inadequate for real-world applications that nobody would use it.

"By the way, I am anything but a FORTH fanatic. I see FORTH as not exactly a language, but more of a language kit. The extensible nature of the language has blinded

Page 14, Column 2

its adherents to the fact that you have to start out with some reasonable set of functions if you want serious applications programmers to use the language. For example, if you want to use virtual memory to store your data in FORTH, go right ahead! They won't try to stop you. Of course, you have to do all the disk allocation, etc. yourself, since none of the functions needed to use virtual memory are supplied with, for example, FIG FORTH (the last time I looked). Also, strings are given the old brush-off, since it would take up too such memory to have a string stack (oh, I forgot, there must be exactly two stacks, according to the words of St. Moore, so that would be heretical). Anyway, you see what I mean.

"Nevertheless, user-extensibility at the higher level is an extremely valuable tool in writing large programs, and you should seriously reconsider it as part of HALGOL. It's not that difficult. I know, since I have written a somewhat FORTH-like language including that feature."

Steve, how did you know it has been raining heavily in Santa Ana the past few days? In discussing the differences between HALGOL and FORTH we do have the problem that the 68000 microprocessor is an absolutely ideal vehicle for both languages and that the innermost elements of both languages will each be written in 68000 assembly language. It should not be surprising that some elements of the two languages are similar. However, it seems that most FORTH types believe that threaded language is their property exclusively. Your third point above triumphantly points out that HALGOL uses 16 bit addresses. Well, we said HALGOL uses threaded code, no? Would you have us use 17 bit addresses just to be different from FORTH? Incidentally, did you spot that the HALGOL program pointer is a 32-bit value? And that GOSUB and (gasp!) GOTO have a 32 bit address field?

You have noted that we made provisions for a data stick. We deliberately did that for those programmers who would like to extend HALGOL for use as an RPN calculator or even to make it more FORTH-like than it really is. None of the code that we have or which we plan to use makes use of that stack.

We are puzzled that you seem to think that HALGOL has something even remotely close to the FORTH dictionary. It does not.

We are happy to see that you understand some of the restrictions imposed by FORTH as it is currently implemented. We are opposed to user extensibility in the FORTH fashion because of the run time overhead penalty which that inevitably imposes. We regret that you overlooked the fact that FORTH is death on documentation and readability.

Page 15, Column 1

MORE HALGOL STUFF:

Look: you want user extensibility at a high level? You like reverse Polish? You don't need to read the programs you write? In that case what you want is the real thing. And, as we explained earlier, Bruce Walker has the real thing available for you, now, for $30. (Sorry, Bruce, but we needed to make a point.)

Back to BASICS: let us point out a dual editorial in Feb '83 Micro magazine. In that editorial Phil Daley strongly supports BASIC as a language and programming environment. Then, in the same editorial Bob Tripp asserts that BASIC is crummy and makes 6 specific points to support his argument.

We assert that all six of Bob's points are not criticisms of BASIC at all! Instead, they are criticisms of extant implementations of BASIC such as Applesoft. (It is rumored that a letter to the editor has already been sent to Micro, so you need not forward a copy of this.)

So if HALGOL is really a BASIC with a fast run-time package, and if BASIC is such a crummy language unsuitable for writing long programs, what good is/will be HALGOL? Can we really make threaded code appear to be interactive?

Our (rather obvious) reply is that HALGOL is BASIC with the obvious problems of BASIC (as most of us know it) fixed. Now, about making threaded code appear to be interactive: if it appears to be interactive then it is interactive as far as the operator is concerned and that is all we care about! Who gives a hoot whether the computer thinks it's interactive?

Further: we are not doing anything new, we are merely extending existing techniques to a slightly higher plane. For instance, you enter as a BASIC line the statement '200 GOSUB 5000'. After finishing the program, you save it to disk. The next day you want to modify the program, so you load the program from disk and LIST 200. Voila! We see '200 GOSUB 5000' on the CRT. Our good old 6502 BASIC saved our program just like we entered it, right? With the 'GOSUB' as ASCII G, O, S, U, B, right?

Wrong! Your good old 6502 BASIC recognized 'GOSUB' as a keyword and changed it into a one byte token. Then, when you listed the line the next day, the LIST routine in your good old 6502 BASIC recognized the token and replaced it with 'GOSUB'. The editing package in your 6502 BASIC fooled you! It made you think that the token wasn't there, but that what you typed in was there instead! So there you sit in front of the CRT, thinking that the 6502 BASIC is fully interactive when it really isn't.

Page 15, Column 2

In fact, the editing package does such a good job of concealing all those tokens from the operator that the operator thinks the program is interactive, even though it really is (slightly) compiled. What we are going to do with HALGOL is to utilize the power of the 68000 to extend the degree to which the run-time package differs from what the operator sees. But: just like that 6502 BASIC, the operator will never see that difference. What more can we ask?

POWERING YOUR DTACK BD:

We have unintentionally been guilty of a fib in our past recommendations as to the choice of an external +5V supply for those of you who wish to power the DTACK board separately. What we said was, essentially, "there are about 100 brands of 5 volt regulated power supplies. Any of those supplies will work fine."

Well, the fact is some of them will not power our board. The problem has to do with a design 'feature' known as foldback together with the degree of conservatism utilized in the design of the product. The first occasion this came to our attention was when a local customer came over with a 5V 6A power supply which would not power a 220K DTACK system. Since such a system only draws 2.6A, we were puzzled... until we saw the supply. It was as small as some 3A units!

Because the supply was so small, the 'foldback' circuit is obviously cut pretty 'close' to protect the supply from momentary overloads. Unfortunately, electronic circuitry is a non-linear electrical load. In other words, at 2.5 volts, an electronic circuit board will pull a great deal more than half the current it pulls at 5 volts.

And since we must pass through the 2.5 volt level in the process of turning on the power, some commercial power supplies trip the foldback circuit which shuts down the power supply. (We are not going into theory in greater detail.)

What this means is that we need a power supply designed in a conservative manner, what the British would call 'robust' construction. Many suitable brands are doubtless available but we can't test them all. Suitable supplies are manufactured by Elpac here in Santa Ana. They sell all over the country via electronic distributers (Marshall Industries locally, for instance). For the sales outlet nearest you, give thee a call at (714) 979-4440.

To power a single board their model SOLV 15-5 is rated at 3A, costs about 40 bucks and will do the job nicely. The SOLV 30-5 is rated at 6A and costs about $65.

Sorry about the confusion.

Page 16, Column 1

M.C.P. WATCH:

M.C.P. can stand for Male Chauvinist Pig or, in the movie TRON, for the villainous Master Control Program. In this instance, we refer to the British personal computer publication Micro Computer Printout. In the Mar '83 issue, Julian Allison's HOTLINE column has an interesting tidbit re Atari.

Most of you are aware that the concept behind LISA is, us, 'borrowed' from the Xerox STAR. Several of the engineers who developed LISA were also, um, 'borrowed' from Xerox. But some of you may not have noticed that the biggie behind the development of Softalk (STAR's language) got away to Atari. Some time ago, in fact.

In the past three years Atari's only new product introduction has been the model 1200. The 1200 is so similar to the 800 that the hardware design could have been completed by two UCLA engineering graduates in one week or one USC undergraduate on a weekend.

Julain suggests, in his HOTLINE column, that David Kaye, the other Atari engineers and the large group of Commodore alumni might be bringing something into view soon (hint, hint). We think that David Kaye and the Commodore alumni were recruited to fill out the Atari softball team...

THE NEW AMERICAN WAY:

In the old, old, old days when you bought a farm or house, you paid for it. Since relatively few people (then or now) had the price of a farm or house, few peasants purchased one. The French devised a solution to this problem: if the peasant would literally pledge his life to repay the loan, a banker would under proper conditions loan the peasant the money to purchase the desired property. In the French language, 'morte' means life and 'gage' means pledge.

In America this became the 'mortgage'. Americans took to the time payment plan as though they had invented it. Before long one could purchase not only a farm or a home but automobiles, refrigerators and video tape recorders and well, just about anything on time payment. (The British call this 'hire purchase'.)

The idea was that you didn't actually buy things, you just promised to make X payments of Y dollars each in exchange for what you wanted. Since most people kept their promise, the system worked. This system became the American Way.

We have now developed, in personal computer marketing, the New American Way.

Page 16, Column 2

Here is how this works: a consumer sees a VIC-20 on sale for $135. Since the consumer does not own a computer or know anything about computers except that they are all the rage and that the Joneses next door have one, he buys the VIC-20. What the heck, it's only $135.

During the first month of use, he discovers that he needs something to store his programs on and to load programs written by others. So he goes back down to the store and buys a tape drive.

During the second month the family starts complaining about not being able to watch the TV because it is hooked to the VIC. So he buys a monitor.

During the third month the need for hard copy output becomes apparent. He buys an MX-80.

Now that the computer is able to do same worthwhile things, it becomes apparent in the fourth month that more memory is needed. On the advice of a friend, the consumer locates a copy of Compute magazine and scans the ads for memory add-ons and orders one using his credit card.

In the fifth month it becomes obvious that the tape drive is an inadequate mass storage drive. He buys a disk drive. Nearly two thousand dollars have been sunk into the original $135 investment! If the consumer buys a modem the following month, the total will probably exceed $2K.

At this point our computer-smart readers say be guffawing at the dummy who didn't know what it took to get a real computer up and running and doing useful things. If that is your feelings an the matter, be advised that we strongly disagree with you!

Look, that consumer originally did not know anything about computers. He undoubtedly did know that he did not want to spend $2K on something he didn't know anything about, however! So, did the system cheat the consumer?

Well, that $2K was obviously disposable income. If the money had not been spent on the computer, it would probably have gone toward a projection TV. We ask you: is that consumer better off spending his money on a computer or a projection TV?

And, we ask the reader, didn't you develop your (first) personal computer system in much the same manner?

So, we give you the New American Way: although a purchase is made using time payments, the purchase is initiated with the customer thinking his first monthly payment is the total price!!

Page 17, Column 1

TRANSCENDENTALS (CONT'D):

Here we resume the discussion of the algorithms used to calculate the transcendental functions which we left off at the end of page 14 in newsletter #16.

CALCULATION OF COS(X):

APPLICABILITY: There is a corresponding cosine for any possible argument. Therefore no error testing need be performed. It should be kept in mind that large errors can occur for arguments whose absolute value is large.

IDENTITIES (from Hart et al):

 eqn 6.4.5:

 COS(X) = COS(-X) = SIN(PI/2 + X) = SIN(PI/2 - X)

DISCUSSION:

Since the COS(-X) = COS(X), we can set the sign of FPACC1 positive without changing the result. So we set the sign positive and then subtract FPACC1 from 90 degrees (actually PI/2 since we are working in radians). It is not actually necessary to set the sign positive before the subtraction, see for instance Hart (6.4.5). However, doing so assures the lowest possible roundoff error during that particular operation.

We then calculate the SINE of the result to conclude the COS(X) calculation. See issue #16, page 20, lines 220 - 222.

CALCULATION OF SIN(X):

APPLICABILITY: There is a corresponding sine for any possible argument. Therefore no error testing need be performed. It should be kept in mind that large errors can occur for arguments whose absolute value is large.

IDENTITIES (From Hart et al)

 6.4.4  SIN(X) = - SIN(-X) = SIN(X + 2KPI)

DISCUSSION:

Our first task is to store the sign of the argument and set the sign of FPACC1 positive. See issue #16, page 20, lines 227-8. Next, observe that in (6.4.4) above, 2KPI is just K times 360 degrees where K is an integer 0, 1, 2... So what we do is divide FPACC1 by 2PI (360 degrees) and take the fractional part of the result. (We really multiply by 1/2PI since that is faster than a divide.) What we are left with is a number ranging from zero to almost 1 which corresponds to an angle of zero to almost 360 degrees.

Page 17, Column 2

Since our argument is no longer in radians, we might worry. No huhu, the Chebyshev approximations in Hart are for the SIN(@PIX), not SIN(X). The @ we will use is 1/2, which means we must reduce the range of the argument to zero to almost 90 degrees, and the argument must be zero to almost one to correspond to that 90 degree range.

However, at the moment our argument corresponds to zero to almost 1/4 for an arc of zero to almost 90 degrees, and our argument corresponds to zero to almost 360 degrees. Clearly we need to further reduce the range of the argument and multiply the argument by four in the process.

We begin at line 232 (issue #16, page 20) where we add two to the exponent of FPACC1. This multiplies the argument by four. Next we check whether FPACC1 is under two. If it is, the corresponding angle is less than 180 degrees and we take the branch to 'UNDTWO'. Otherwise we have an argument corresponding to an angle of 180 to almost 360 degrees. Using the identity SIN(X) = - SIN(PI - X) (valid for X = 180 to 360 degrees), we toggle the stored sign of the original argument and subtract two from FPACC1, (Actually, we move - 2 into FFACC2 and then add FPACC1 and FPACC2. It's simpler that way.)

We now find ourselves at line 247. FPACC1 is now zero to almost two. Next we test whether FPACC1 is less than one. If so, we skip to 'UND1'. Otherwise we have an argument corresponding to an angle of 90 to almost 180 degrees. Using the identity SIN(X) = SIN(PI - X) (valid for X = 90 to 180 degrees) we move the number two into FPACC2 and subtract FPACC1 from FPACC2. See lines 252-4.

(You will remember that one of the bug fixes reported in the last issue was to see that the number two, not one, was moved into FPACC2 at this point.)

We now find ourselves at line 259. We now perform the series approximation HART 3344. Now we test the stored sign and set FPACC1 negative if the stored sign is negative. This completes the SINE calculation.

(Another bug fix in the last issue was to test the stored sign by simply moving it back to itself at line 261.)

CALCULATION OF TAN(X):

APPLICABILITY: There is a corresponding tangent for any possible argument. Therefore no error testing need be performed. It should be kept in mind that large errors can occur for arguments whose absolute value is large.

Page 18, Column 1

IDENTITIES (from Hart et al)

 6.4.6: 

 TAN(X) = - TAN(-X) = TAN(X + KPI) = 1/TAN(PI/2 - X)

 6.4.25 

 TAN(X) = 2TAN(X/2)/(1 - TAN(X/2) * TAN(X/2) )

DISCUSSION:

It should be kept in mind that the tangent can be calculated by TAN(X) = SIN(X)/COS(X). This is the technique used in Microsoft's 6502 BASIC, at least the Pet/CBM or Apple variety. In our Microsoft compatible package we used the same technique for the same reason: we were lazy. However, there are significant speed advantages and some accuracy advantage to calculating the function directly. So we will, beginning at line 402 (issue #16, page 23).

The first thing we do is divide the argument by PI (180 degrees) and take the fractional part of the result. (As usual, we actually multiply by 1/PI since that is faster.) Next, we clear A0 and the sign flag byte. Our argument is now in the range of almost -1 to almost +1, corresponding to almost -180 degrees to almost +180 degrees. As in the SINE calculation, our argument is no longer in radians.

We are now at line 410. Next we check the sign of FPACC1. If it is negative, we set the sign flag and then clear the sign bit of FPACC1,

We are now at line 417. We have an argument between zero and almost one, corresponding to zero to almost 180 degrees. Next we test whether the argument is less than 1/2. If the argument is less than 1/2, we skip to 'TUH'. Otherwise, we toggle the sign flag and move the number one into FPACC2. Then we subtract FPACC1 from FPACC2. We are taking advantage of the identity TAN(X) = - TAN(PI - X) (valid for X = 1/2 to one).

We are now at line 427. We have an argument between zero and 1/2, corresponding to zero to 90 degrees. Next we test whether the argument is less than 1/4. If the argument is less than 1/4, we skip to 'TUQ'. Otherwise we set the invert flag, which is the second bit of A0. We do this by adding two to A0. Then we move the number 1/2 into FPACC2 and subtract FPACC1 from FPACC2. We are taking advantage of the last term of HART (6.4.6), or TAN(X) = 1/TAN(PI/2 - X). See the preceding page.

We are now at line 438. We have an argument between zero and 1/4, corresponding to zero to 45 degrees. Next we test whether the argument is less than 1/8. If the argument is less than 1/8 we skip to 'TUE'. Otherwise we set the reduction flag, the least bit of

Page 18, Column 2

A0. Then we divide FPACC1 by two by subtracting one from the exponent of FPACC1 (see (6.4.25)).

We are now at line 449. We have an argument that corresponds to zero to 22.5 degrees, but FPACC1 is in the range zero to almost 1/8. (We had the same sort of situation while doing the SINE calculation.) So we multiply FPACC1 by 8 by adding eight to the exponent of FPACC1. We now have the argument and arc reduced to zero to 1 and zero to 22.5 degrees, respectively. That is a good thing, because that is what is needed to perform the series calculation Hart 4187. So we store A0 (the invert and reduction flags) in EXPADD and perform the series approximation. See lines 449-453

Now that the series calculation is performed, we need to service three flags: reduction, invert, sign.

We are now at line 457. We test the reduction flag by shifting it into the carry bit (this leaves the invert flag in bit 0 of EXPADD). If the reduction flag is not set, we skip to 'NOTRNG'. Otherwise, calling Y the current content of FPACC1, we set the result equal to 2Y/(1 - Y * Y). See (6.4.25).

We are now at line 468. We test the invert flag by shifting it into the carry bit. If the invert flag is not set, we skip to 'NOTINV'. Otherwise we invert FPACC1 by moving the number one into FPACC2 and then dividing FPACC1 into FPACC2.

We are now at line 475. We test the sign flag and skip to 'NOTNEG', which is the end of the TAN(X) calculation, if it is not set. Otherwise we set the result negative, and the calculation of TAN(X) is completed.

CALCULATION OF LOG(X):

The LOG function is the inverse of the EXP function described on page 11 of issue #16. Like the EXP function, we may at times want to calculate the log to the bases 2, e, and 10. In BASIC the base of the LOG (and EXP) function is assumed to be e. For reasons which we hope will be obvious, binary computers calculate the LOG function most efficiently in base 2. The calculation of the LOG function in other bases is accomplished by first calculating the LOG base 2 and then multiplying the result by a stored constant. The stored constant is simply the logarithm of 2, taken in the desired base.

To calculate the log base 10, we first calculate the log base 2 and then multiply the result by the logarithm base 10 of 2. Similarly, to calculate the log base e we first calculate the log base 2 and multiply the result by the logarithm base e of 2.

Page 19, Column 1

Since it is so easy to provide LOG functions in each of the three common bases, we do so. See lines 65, 71 and 76 on page 17 of issue #16.

APPLICABILITY:

The logarithm is undefined for negative numbers, so an error message must be issued if the argument is negative. There is a logarithm for a zero argument, but the value is minus infinity, which cannot be represented as a floating point number. Therefore, we must also test for a zero argument and issue an appropriate error message if one is encountered.

A logarithm can be found for any nonzero positive argument.

IDENTITIES (from Hart et al)

 6.3.1   LOG[EXP(X)] = X = EXP[LOG(X)]  (any base)

 6.3.15   LOG(X * Y) = LOG(X) + LOG(Y)  (any base)

 6.3.17   LOG  (B   * X) = N + LOG  (X)

 6.3.21   LOG  (X) = LOG  (Z) * LOG  (X)

If we assume A = e and B = 2, reduction to the range [1/2, 1] is easily accomplished by (6.3.17). Let:

 6.3.22   X = F * B

where N is the (integer) floating-point exponent and 1/2 < F < 1, then:

 6.3.23   LOG (X) = N + LOG  (F)

(the commentary above is adapted from Hart et al)

DISCUSSION:

Once the logarithm to the base 2 is calculated, obtaining the logarithm to another base is trivial. We will therefore concentrate our discussion on the problem of obtaining the logarithm base 2 of any postive non-zero argument.

First we must test for the presence of a negative or zero argument and report in error if one is encountered. See lines 76-9, page 17, issue #16.

The reader will recall that the exponent of the floating point operand is stored (using the floating point package published as REDLANDS in issue #15) as an 'excess $1000'. At lines 83-4 we convert this format to 2's complement and store it.

Next we must reduce the operand range to a 2 - 1 range.

Page 19, Column 2

Somewhat surprisingly, Hart does not publish its most accurate series approximations for the range [1/2, 1] but instead publishes approximations for the range 1/SQR(2) to SQR(2), or about .707 to 1.414. It may be that the selection of this range minimizes errors in the close vicinity of one. The LOG of one is, of course, zero.

Incidentally, the Microsoft LOG function does use the range [1/2, 1] but they also use one of the Hart series approximations based on the range .707 to 1.414. They correct for this at the end of the series calculation by adding 1/2, which is the logarithm (base 2) of SQR(2), the difference of the two ranges. Our Microsoft compatible package used the same range as Microsoft. The package to be discussed here uses the Hart suggested .707 to 1.414 range.

Having stored the original exponent, we now (in line 88) set the exponent of the argument to zero. Since the value of the mantissa portion of (almost all) floating point packages lies between 1/2 and almost 1, we have already reduced the range of the argument to [1/2, 1]. Now we test whether our argument is equal to or greater than 1/SQR(2). If so, we skip to 'LOG2A'. If the argument is smaller than 1/SQR(2), we add one to the exponent of the argument and decrement the stored exponent to compensate. See lines 89 - 95.

As discussed on page 11 of issue #16, it is often possible to find series approximations to a parameter, usually called Z, which is related to the argument X rather than a series approximation on X itself. This is also the case for the LOG function. The series approximation we will use is of the form:

 LOG (X) = Z * P(Z * Z)

where

 Z = (X - 1)/(X + 1)

We begin the transformation from X to Z squared at line 97. First we store X in temporary register T. Then we set pointer A0 to the LOG constant table. The first value in that table is minus one. Now we call subroutine FPADD, which adds FPACC1 to the value pointed to by A0 and leaves A0 pointing to the next table entry. (See line 608, page 29, issue #15.) FPACC1 is now equal to (X - 1). We store this value in temporary register U (see line 100).

Now we recall X from temporary register T and call subroutine FPADD again. Since A0 is now pointing to the number one in the LOG constant table, the result in FPACC1 is (X + 1). Now we recall (X - 1) from temporary register U to FPACC2 and call subroutine FPDIV1, which divides FPACC1 into FPACC2. The result is equal to Z.

Page 20, Column 1

We now store Z in temporary register U and perform a series approximation on Z squared, then multiply the result by temporary register U, which of course is Z. Because other functions are calculated in this manner, subroutine 'SERSQU', which is called at line 115, performs those housekeeping functions in addition to performing the series approximation itself.

Incidentally, if you have either the Hart 1968 first edition or the 1978 reprint w/corrections, at the top of page 111 it states that the form of the series approximation is P(Z * Z). That is wrong! The correct form is Z * P(Z * Z).

We have selected Hart 2665 as the appropriate series approximation, with precision 16.52, N = 6. Proving that nothing is ever simple, Hart throws us a curve by publishing that series approximation for the LOG to the base e! That base is, of course, inappropriate for use with digital computers. Therefore, we not only had to convert the Pn constants from their decimal value as published in Hart to their binary (or hex, if you prefer) floating point formats, we also had to multiply each constant by LOG (e)! That gave us a series approximation suitable for a base 2 calculation. The Hayden double precision (21 decimal digit) math package was very helpful here.

We have now calculated the second term of the right hand side of eqn (3.3.23). Now we must add N, the exponent base 2, to the second term to complete the calculation of LOG(X) base 2. If you understand why we are adding N, skip this next section (skip to the second dotted line), which will contain a very simplified explanation of why we add N.

Most of you have access to a hand calculator with a LOG base 10 function. You might satisfy yourself that the LOG base 10 of #1 is zero, of #10 is one, of #100 is two, etc. You can also note that the LOG base 10 of #.1 is minus one, of #.01 is minus two, etc. If we express X in exponential form and remember that the LOG (any base) of one is zero, we have:

      100 = 1 * 10EXP(2);   LOG(100) = 2 
       10 = 1 * 10EXP(1);   LOG(10)  = 1 
        1 = 1 * 10EXP(0);   LOG(1)   = 0 
       .1 = 1 * 10EXP(-1);  LOG(.1)  = -1 
      .01 = 1 * 10EXP(-2);  LOG(.01) = -2

(The LOGs above are all base 10)

By equation (3.6.1), LOG[EXP(X)] = X, so the value of the LOG of those numbers above are equal, by equation (3.6.15), to the LOG(1), which is zero, plus the LOG[EXP(N)], which is N.

Page 20, Column 2

In our binary floating point package, the exponent is stored in base 2 form (with excess $1000). Since we are calculating the LOG function base 2, we must add the exponent to the result. Let us look at one very simplified example before continuing. Suppose we want to calculate the LOG base two of the number eight. The floating point representation of eight is:

 $1004 8000 0000 0000

Which has a mantissa of 1/2 and an exponent (base 2) of 4. In other words, two to the fourth power (16) times 1/2 is eight.

We would store the 4 and set the exponent to zero (with excess $1000). We would then check to see whether the result, 1/2, is less than .707. It is. We compensate by adding one to the exponent of FPACC1, with the result equal to one. We also subtract one from the stored exponent, which is now three.

Now we calculate the LOG of FPACC1. Since FPACC1 is equal to one, the LOG is zero. Now we add the exponent, which is now 3, to the result and the final value is 3. This follows, since 2 raised to the 3rd power is eight.

We hope this simplified explanation makes it clear why we must add the stored exponent to the present value of FPACC1 to complete the calculation of the logarithm to the base 2 of our original argument.

Now we are all back together. We have, in FPACC1, the result of performing the series approximation form Z * P(Z * Z). Since the range of the (reduced) argument was .707 to 1.414 (appx), the result of the series approximation must be in the range -.5 to +.5. Any value in that range, including zero, is permitted. Now we are going to add the integer value of the stored exponent to FPACC1 to complete the computation of LOG base 2 of X.

We are at line 122 on page 18, issue #16. First we clear FPACC2 as the first step of converting the exponent into floating point format. Next we move the stored exponent to M2, the most significant 16 bits of M2. If the exponent is zero it will set the Z flag in the 68000 status register. So, at line 125 we BEQ LGEXIT. If the exponent is zero, we need not add it to FPACC1! Remembering the exponent is stored in two's complement form, at line 126 we BMI LGNEG. If the exponent is negative, we will take this branch to line 140. There we set the sign of FPACC2 negative and its exponent equal to #16. Then we convert the negative exponent to its positive equivalent and take an absolute branch back to line 129.

Page 21, Column 1

If we had not taken the branch at line 126, in 127-8 we move the exponent to D1 and set the sign of FPACC positive and its exponent equal to #16.

So we are now at line 129. The exponent of FPACC2 is #16, the sign may be positive or negative, and the absolute value of the former stored exponent is in D1, as a 16 bit value. Note that D1 is never zero at this point or we would have taken the branch at line 125 to exit the routine. The sign and exponent of FPACC2 are stored for now in D0.

Now we simply subtract one from the exponent of FPACC2 (in D0) and shift D1 one bit left. We repeat this until the most significant bit of the word in D1 is a one, corresponding to a properly normalized mantissa. Now we store D0 and D1 in FPACC2 and return from the LOG base 2 subroutine by jumping to subroutine FPADD1, which adds FPACC1 and FPACC2.

And that (pant, pant!) completes the calculation of the logarithm to the base 2.

CALCULATION OF SQR(X):

The square root function is the last of the transcendental functions to be covered. Here we are going to depart from the Chebyshev approximation methods of Hart and adopt a somewhat older algorithm attributed to a fellow named Isaac Newton. This method basically (no pun intended) involves taking a guess at the result and then refining the guess through an iterative procedure. The iterative procedure involves the following formula:

 Y(N + 1) = (Y(N) + X/Y(N))/2

Y(0) would be the first guess and Y(1) the first refinement of that guess. On the second iteration of the refinement process, Y(1) would serve as Y(N) for the calculation of the next refinement, Y(N + 1) or Y(2).

The refinement process is stable and predictable. If we know the upper limit of the relative error of the initial guess, we can know in advance how many iterations are required to provide the best accuracy obtainable given the number of bits in the mantissa of the floating point representation of the number.

It works this way: the number of accurate bits in the mantissa doubles (at least) on every iteration. Suppose that our first guess is only accurate to one bit in the mantissa. Here's how the iterative process would work:

Page 21, Column 2

       ITERATION     # OF ACCURATE BITS 

          1                   2 
          2                   4 
          3                   8 
          4                  16 
          5                  32 
          6                  64??

Since our floating point package has only 48 bits, that means we can quit after the sixth iteration since our result is as accurate as it is going to get. Now, the convergence can get faster but it cannot get slower. All of this assumes that the very first guess is accurate to one bit, and, for our chosen algorithm, that is exactly the (worst-case) accuracy of our first guess.

The next thing you might notice is that the first 4 iterations result in numbers which (are likely) accurate to 16 or fewer bits. This suggests that we eight save some time by using 16 bit integer math for those first four iterations, then going to 48 bit mantissa floating point for the last two iterations.

Now we will get down to specifics about the actual code used. Turn to line 329, page 22, issue #16:

Since we cannot take the square root of a negative number (for data type real), we first check the sign of the argument and report an error if the sign is negative. Next we check whether we have a zero argument, in which case the result is zero.

In the process of checking for a zero operand, we have left a copy of the exponent of the argument in D2. At line 336 we move the most significant 32 bits of the mantissa to D7. Since we have a properly normalized mantissa and a non-zero argument, the most significant bit of D7 is a one, In the next line we set the exponent of FPACC1 to zero. FPACC1 now has a value between 1/2 and almost one.

Next we test (at line 339) whether the exponent of the original argument is add or even. If it is even we skip forward to line 346. Otherwise we subtract one from the exponent of FPACC1 and divide D7 by two by shifting it one bit position right.

At lines 346-9, we calculate the exponent of the result. Since the exponent of the result of the square root operation will be (roughly) half of the exponent of the argument (we hope this is obvious), we shift the exponent in D2 right one bit position. This reduces the 'excess $1000' to 'excess $800'. So we add $800 to D2 with the carry bit resulting from the shift, and store the result in temporary location LOGX.

Page 22, Column 1

We now find ourselves at line 353. Let us review the contents of D7: we do not know whether we shifted D7 one bit right or not. What we do know is that D7 cannot be greater than $FFFF FFFF (32 bits) or less than $4000 0000. It cannot be less because we started out with the most significant bit equal to one.

Now we must guess what the square root of the number in D7 will be. If we are going to work with integer arithmetic, what sixteen bit integer, when multiplied by itself, is equal to the 32 bit product in D7? $FFFF, when squared, is closest to $FFFF FFFF. $8000 when squared exactly equals $4000 0000.

Therefore the range of integer approximations is $FFFF to $8000. If we take $FFFF as our first guess (and we do), then we are guaranteed of a first guess which is within one bit of accuracy in the integer equivalent of the mantissa.

The reason we are taking a guess which is equal to the highest end of the possible range of results is that the 68000's integer divide instruction, which we are going to use, requires that the numerator be smaller than the denominator or the destination (result of the divide) will be unchanged and the overflow flag will be set. (See newsletter #2, page 14.) By setting the first guess equal to $FFFF we are guaranteed to be larger than any value of the numerator (D7) other than $FFFF XXXX.

If D7 is $FFFF XXXX nothing is going to happen at line 360. That's O.K. because we would need an eventual 16 bit integer guess of $FFFF anyway, and that's what we will get in this case.

In line 353 we move $FFFF into the lower 16 bits of D7. In line 358 we move this into D5 as our first guess, having set our loop counter in line 357. Now we are ready to perform the first four iterations of Newton's method using integer arithmetic.

At line 359, the start of the loop, we move X, or D7, to D6 as a scratch register. Note that the iteration formula requires that we retain the original value of X. After the divide in line 360, the dividend will be left in the lower 16 bits of D6. We add this to D5 (which should result in a carry bit being generated). So we divide this sum by 2 in line 362, shifting the carry bit into the most significant position of the word in D5. D5 is now the first refinement of the iterative process.

We repeat the loop four times, after which our approximation will be as accurate as it is gonna get using 16 bit integer arithmetic.

Back to FPACC1. This contains the modified original

Page 22, Column 2

argument. The original mantissa is unchanged but the exponent is now either zero or sinus one (but with the 'excess $1000', however). At line 365 we call a subroutine which stores FPACC1 in both FPACC2 and in temporary register U. This frees up FPACC1, so we convert our integer approximation to floating point form.

The possible range of the modified original argument is 1/4 to almost one. The possible range of the square root of the modified original argument is therefore 1/2 to almost one. The possible range of the 16 bit integer approximation in D5 is $FFFF to $8000. Note that the most significant bit of D5 is a one, in properly normalized mantissa fashion.

Therefore, to float our integer approximation in FPACC1 we need to clear the least 16 bits of M1, the mantissa. We do this in line 371. Next we set the exponent to zero since our result must lie between 1/2 and almost one, and that means a zero exponent. Now we move our nicely normalized D5 into the most significant 16 bits of the mantissa and presto!, we have floated our approximation.

Now we need to perform two more iterations of Newton's approximation using floating point arithmetic. We do this via 'branch to subroutine' calls in lines 374 and 375. Now we replace the exponent of FPACC1 by the stored exponent of the result (in line 379) and our square root calculation is completed.

TRANSCENDENTAL SUMMARY:

We have now covered, in this issue and in issue #16, all of the standard BASIC transcendentals. These include SQR, LOG, EXP, SIN, COS, TAN and ATN (arc tangent). All of these functions have been thoroughly tested given the limited resources of Digital Acoustics, which is after all a small company. Two people expended about 100 hours in the process.

The intended objective, to obtain an accurate and reliable set of transcendentals equivalent in accuracy to the programmable desk calculators of yesteryear, appears to have been attained. Those calculators, the Wang 500, 600, 700 and 2200 series and the HP 9810, 9820, 9830 machines provided calculations accurate to 12 or 13 digits. The package we have been discussing achieves that level of accuracy. It does not achieve a full 14 decimal digit accuracy although the fundamental four math functions do.

The reason a full 14 digit precision has not been achieved has to do with rounding errors during range reduction. The worst example of this is during the arc

Page 23, Column 1

tangent calculation, where at one point we need to subtract a number close to 5 from a number close to 5.1 to obtain the argument to be used in the series approximation.

If you do some error testing on this package, we urge that you take two precautions. First, make sure you are comparing apples and apples. Be sure that the argument used in comparison calculations is identical. This seems obvious, after all the same calculation performed on two different arguments will naturally be different. However, consider testing the arc tangent of the square root of two using our package and the Hayden double precision package. Since the Hayden uses a 72 bit mantissa, the square root is naturally not going to be the same as the square root as taken by our package using a 48 bit mantissa. We know this seems obvious but this little matter caused us continuous grief even though we were aware of the problem.

The second matter is to recognize the unavoidable errors inherent in range reduction. You will undoubtably know that the sine of .000001 degrees is equal to the sine of 179.999999 degrees. Now that you know how our sine algorithm works, can you spot the reason our package will not give equal results for those two calculations? (Hint: it is not primarily due to the fact that the two decimal numbers cannot be completely accurately translated into binary floating point format.)

In a perfect world, we would undoubtedly identify the worst range reduction errors, such as the one encountered for certain arguments during the arc tangent calculation and perform them using a more precision floating point package using, say, a 64 bit mantissa.

But this attitude carried to extremes winds up like counting the number of angels that can dance on the head of a pin. We say that the package provides 13 decimal digits where you would expect it to do so. That's good enough for us.

So such for the trancendental package itself and its putative accuracy. Now we will discuss briefly the explanation of the transcendentals. In other words pages 10 thru 14 of newsletter #16 plus the preceding six pages or so.

It is our sincere hope that we receive complaints that the explanations fell far short of the sort of mathematical exactness and rigor required of textbooks and publication in refereed journals. We also sincerely hope that we receive complaints that the explanations are much to complex to be understood by a

Page 23, Column 2

person with a limited math background, and therefore unsuited for publication in any magazine which uses the word "POPULAR" as the first word of its name.

If we have accomplished our intended objective, we have described the transcendental algorithms at a technical level midway between the extremes in the last paragraph. To the best of our knowledge, transcendental algorithms have never been described in print at this particular technical level. If they had, we could have just given you the reference and saved ourselves a lot of work.

We invite constructive criticism of our transcendental algorithms. This is definitely not the sort of thing that is immune to being improved.

Non-constructive criticism will be ignominiously rejected unless accompanied by examples of superior work done by the critic.

The material we have presented is based heavily on the book "COMPUTER APPROXIMATIONS", John Wiley & Sons, N.Y., 1968. The book is part of the SIAM series in applied mathematics.

HALGOL FORMULAS:

As HALGOL is currently set up, if you want to calculate

 VOLUME = HEIGHT * WIDTH * DEPTH

it is necessary to instead enter the following lines of HALGOL code (line numbers deleted for clarity);

 LOAD HEIGHT 
 MULT WIDTH 
 MULT DEPTH 
 STORE VOLUME

In other words, the formula must be translated into a sequence of steps by the programmer. Although the run-time code which results is very efficient since no parsing is needed, it is inefficient to require the operator to, in essence, compile the formula personally. In fact, one of the criticisms we have of FORTH is that the efficiency of the language is based largely on the fact that the code-writer has to compile the program himself as he goes along, and in reverse Polish no less.

Therefore, one of the things we will have to put on our 'let's do this someday' list is a formula function for HALGOL. We think we have figured out how to do this. Before we give you our solution, we first need to explain how the HALGOL code syntax works. Again, we

Page 24, Column 1

will delete the line numbers for clarity:

Following is the simplest form of HALGOL statement:

 SQR

That statement means to take the square root of the current value of the accumulator and leave the result in the accumulator. (Oh, yes: you did know that HALGOL was an accumulator-based problem-solving language, didn't you?) The run-time code for that line is just the 16-bit action address of the SQR function.

The next simplest form is:

 LOAD HEIGHT

That statement means to take the content of the eight byte floating point number whose offset address is the next 16-bit value following the 16-bit action address of the LOAD function.

It follows that when entering the line above into the HALGOL program, the editing package has to note that there should be a variable name (or perhaps a constant variable) following the keyword 'LOAD'.

We hope it is obvious that we look for a keyword first. If a variable name or constant variable logically follows that keyword, the editing package has to look for the variable name or constant. If none is present, an error message must be displayed and the HALGOL statement rejected. On the other hand, the editing package has to know not to look for a variable after the SQR function.

What, then, does the following line represent? Is the line legal?

 LOAD LOAD

Why, that line means to load the accumulator with the contents of the eight byte floating point variable whose name is LOAD. Since the editing package always knows whether it is looking for a keyword or for a variable, there is no conflict in having variable names which are the same as a keyword. (Contrast this with Atari BASIC, where the variable name 'SCORE' cannot be used because the BASIC keyword 'OR' is imbedded in that name.)

When is the first word of a line of HALGOL code not a keyword? When the first non-space character following the line number is a semicolon or a quote. If that first character is a semicolon, all of the remaining characters an that line are assumed to be part of a remark statement. If the first non-space character is a quote, then all the remaining characters on that line

Page 24, Column 2

are part of a label. (Leading spaces in a HALGOL statement line are ignored.)

So, the following three lines of code are quite legal and there is no possibility of confusion:

 "LOAD" 
 ;LOAD LOAD into the accum. 
 LOAD LOAD

The leading quote an the first line means we have a label. If we enter 'GOSUB LOAD' as a line elsewhere, the 32 bit value following the 16 bit action address of 'GOSUB' will be the absolute address of the line following the line containing the label "LOAD." The second line above starts with a semicolon and so is obviously a remark line. Everything else in the line is ignored.

We could make the second line listing start with a REM (space) instead of a semicolon if we wished.

As we have already discussed, the third line above is quite legal also. In HALGOL, there is never any conflict between keywords, labels, remarks, or variable names.

Back to the question of a formula statement for HALGOL. We will retain this example formula:

 VOLUME = HEIGHT * WIDTH * DEPTH

Now, that obviously cannot be a legal HALGOL line (assuming VOLUME is a variable name) since there is no leading semicolon or quote character, and there is no HALGOL keyword 'VOLUME' (for now, anyway). Hmmm. Let's see, what keyword can we use to turn that into a legal HALGOL statement line? Well, Dartmouth BASIC used the 'LET' statement. So let's try this:

 LET VOLUME = HEIGHT * WIDTH * DEPTH

Which has the form:

 LET      =      M1      M1

Where indicates a variable name and M1 indicates a math operator, in this case multiply.

There are very few math operators as far as precedence levels are concerned. In fact, there are only three: The first level is M0, which is either add or subtract. The second level is M1, which is either multiply or divide. The third level is all of the other math functions. You see, all of the other math functions involve parenthetical values. Examples include SQR, ABS, INT, TAN etc.

Page 25, Column 1

Back to our formula above: if we simplify to simply V, we have:

 V0 = V1 M1 V2 M1 V3

What we need to do is evaluate the expression on the right hand side of the equation, which is simply

 V1 M1 V2 M1 V3

what we want to do is to reduce the above form to a sequence of conventional HALGOL LOAD, MULT, STORE statements. We don't want to do this at run time; we want the run-time package to already be reduced to conventional HALGOL. Hence, we have to do this at the time the line is entered from the keyboard.

There are two possible ways of handling this. One is to compile this into reverse Polish and then translate the reverse Polish into a HALGOL sequence.

AN ALTERNATE METHOD:

If all we have is three possible levels of math precedence, the form

 V1 M1 V2 M1 V3

can be encoded very tightly indeed. In fact, a non-parenthetical expression must consist of variables (or constant variables, which need not be distinguished from named variables at this time) separated by one of four math operators. Indeed, since the third level of math precedence cannot be included in a non-parenthetical expression, only two (!!) bits are required to map the above expression to a pre-compiled HALGOL sequence assuming we have a three-variable expression. (We trust it is evident that there will always be N - 1 math operators in a non-parenthetical expression containing N variables.)

Since only two bits are needed to encode a three-variable expression, it is evident that there are only four possible forms of a three-variable expression. These forms are:

 V1 M0 V2 M0 V3 
 V1 M0 V2 M1 V3 
 V1 M1 V2 M0 V3 
 V1 M1 V2 M1 V3

Since the first variable is HEIGHT, the second is WIDTH and the third is DEPTH we can see that the following HALGOL sequences will calculate the corresponding possible form of the 3-variable expression.

 #1:  LOAD DEPTH 
      M0 WIDTH

Page 25, Column 2

      M0 HEIGHT 

 #2:  LOAD DEPTH 
      M1 WIDTH 
      M0 HEIGHT 

 #3:  LOAD WIDTH 
      M1 HEIGHT 
      STORE 

 

 

 

 

 
      LOAD DEPTH 
      M0 

 

 

 

 

 

 

 

 #4:  LOAD DEPTH 
      M1 WIDTH 
      M1 HEIGHT

In the HALGOL lines above, M0 is either ADD or SUB and M1 is either MULT or DIV. Since we observe the right to left precedence, we can interchange ADD with SUB and MULT with DIV. Note that we need a temporary storage register in the third sequence to maintain the right to left precedence. (System variables will have bracketed names so that is not the same variable as TEMP.) Also, note that we do not use the same variable addressing sequence each time.

The process of evaluating an non-parenthetical expression always begins with a LOAD statement and always finishes with the value of the expression in the accumulator. In fact, for a one-variable expression, the LOAD YARN statement begins and also concludes the evaluation of the expression.

Aside from the names of the variables, each of the above sequences consist of LOAD, STORE, M0 or M1 statements. Remember, M0 can be add or subtract and M1 can be either multiply or divide. Since there are only four possibilities, only two bits are needed to encode each keyword, another two bits per statement to keep track of the particular variable (for a three-variable expression plus a 'temporary' variable), plus an additional three bits to designate how many statements are used,

Therefore, each of the above sequences can be encoded using a maximum of 19 bits (in one case) and a minimum of 15 bits (in the three other cases).

Only 64 bits total are needed to encode all possible (HALGOL) forms of the solution of a three-variable non-parenthetical expression.

(Logic to keep track of whether a particular math operator, M0 for example, is an ADD or SUB can be easily accomplished. Trust us!)

We suggest, without proof, that the number of bytes (not bits) required to encode all possible solutions of

Page 26, Column 1

non-parenthetical expressions with a larger number of variables is roughly proportional to the square of the number of variables. Following are the estimated number of bytes required to encode all possible forms of expressions with up to 9 variables:

 N = 3      9 BYTES 
 N = 4     16 BYTES 
 N = 5     25 BYTES 
 N = 6     36 BYTES 
 N = 7     49 BYTES 
 N = 8     64 BYTES 
 N = 9     81 BYTES

In other words, only (roughly) 280 bytes are needed to encode all possible forms of non-parenthetical expressions having 3 to 9 variables. We will further assert, without proof, that a BASIC program can be written which will automatically generate the solution codes for each possible form. We know it can be done on our WANG 2200 because our WANG supports bit manipulation.

It is also evident that there is no major penalty to extend the possible solutions to higher numbers of variables in a particular expression, but we frankly don't think that is needed. After all, both the Pet and Apple have 'EXPRESSION TOO COMPLEX' error messages.

It is no big deal to break a formula with fifteen variables down into two smaller formulas. .

And we suspect that this method, which we might call 'compilation via template' might run a bunch faster thin the usual method of compiling into reverse Polish because the usual method involves parsing the expression whereas the 'template lookup' technique involves no parsing except when the BASIC program generates the template tables. The resulting operator response time might be significantly faster using template compilation.

Remember, this 'compilation via template' is performed while the operator is keying the program into the computer, not at run time.

As in exercise for the student, try to work out a good form of the formula statement in the HALGOL run-time package (you might even put it on paper and mail it to us). In the next issue we will (probably) present one or two workable forms and discuss their advantages.

Also, can you spot the reason we do not need to maintain separate tables for different numbers of variables (and hence math operators), just one table: the one with the largest number of variables?

Page 26, Column 2

THE FIRING SQUAD COMETH:

Earlier in this newsletter we told you our impression of what the U.S. export laws/regulations were. Since then, we have taken some effort to ascertain more detail. 'We' is literally the case; our secretary attended a two-hour seminar on export regulation and licensing hosted by the U.S. Department of Commerce. The good news is we can ship anything we want to Canada.

The bad news is that we must obtain an export license for each customer in any other country if we are going to ship $500 or more to that customer. That's not $500 per shipment; that's $500 per customer total of all shipments. They keep track of it by putting all the export declarations on a computer.

What this means is that we are out of business except in the U.S. and Canada. We are right now in the process of returning two bank drafts to West Germany and another to England. (Those Englishmen are subversive as hell.)

WHAT'S GOING ON?

What is happening is that the Pentagon is becoming paranoid about shipping good old U.S. of A. technology to the baddies in the black hats. Now, the problem of technology transfer is real. What is paranoid is the way they are going about it. You see, none of the civil servants making the decisions are anywhere near as knowledgeable as (the entirely ficticious) 'Kewpie' Fogbottom.

When you apply for a license to ship a computer, even a toy one, that application goes to a civil servant (bureaucrat) who knows nada about computers. Now, what is constantly an a civil servant's mind is that he or she does not want to make a mistake. So if you ask for in export license, the answer is automatically, "No, you can't have one." It is then your task to prove that it is all right. Since the civil servant in question is in Washington, D.C. that is an expensive and time-consuming task.

In our particular case, the fact that the task is expensive and time-consuming is irrelevant since the regulations require an export license for each customer. Since our method of distribution is to deal directly with the end user, we are effectively out of business for total amounts over $500.

In the future, we may have certain products available for less than $500. We can ship those to overseas customers provided we have not already broken the current export regulations by selling you a DTACK board.

Page 27, Column 1

It's like this: Digital Acoustics is now entering its eleventh year in business. We have been exporting environmental noise measuring systems since one year after we opened our doors and almost all of these systems have contained a microprocessor somewhere, either an Intel 4040 or a 6502.

The drive to limit exports apparently started in this country in 1979. Naturally, we read in the papers about the restrictions on computers and technology, but we never believed those restrictions applied to us, especially the DTACK boards. You see, the only technology an those boards are the fast, low power static RAMs made in Japan and the big 64 pin chip which is made both in Japan and in the U.S. Our interpretation was incorrect, the regulations will not permit us to ship Japanese technology to England or West Germany or even New Zealand, for that matter.

What really brought the matter to our attention is that our export shipper, the one we have been using for ten years now, has been questioning us regularly in the past 60 days over the propriety of our export shipments. So we checked up, with the result which we have related to you.

During U.S. Secretary of State George Schultz's recent visit to the People's Republic of China he was questioned by a U.S. businessman during a press conference: "Why is it so easy in China or in Western Europe to obtain an export license, and so difficult in the U.S.?" Schultz angrily retorted, "Why don't you move to China or to Western Europe?"

In our judgement, that is not the reply of a stupid or mean man; that is the reply of a man who knows that there is a problem and who is frustrated over an inability to find the solution to the problem. As we said earlier, the problem of technology transfer is real. The problem of having non-technical civil servants in control of technical decisions is also real.

We now direct you to the magazine "physics today", published by the American Institute of Physics. In the Feb '83 issue there is an article beginning an page 42 entitled "What price security?" by Dale Corson. Dr. Corson is a former president of Cornell University and led a National Academy of Sciences panel (committee) which looked into the ongoing controversy of which export restrictions are merely a part.

The article is a lengthy one; we are going to provide three short quotations, all taken from page 47:

"The panel believes that there is much room for improvement in targeting the government's efforts to prevent unwanted technology transfer."

Page 27, Column 2

(Translation: the government doesn't know what the hell it's doing.)

"Because the perceived nature of the technology leak problem has shifted only recently, government control mechanisms themselves are still being adjusted to meet the new perceptions."

(Translation: the problem is new, and, to give the government credit it is trying.)

"Let me give you an example of the complexity of the system. In the Export Administrative Act of 1979, an act which has been revised regularly and is the underlying legislation for EAR (Export Administration Regulation - FNE), it was specified that the Commodity Control List should be based on something called the Militarily Critical Technologies List. The Commodity Control List is the basis for licensing exports and the Militarily Critical Technologies List is now undergoing its second revision. The third version of this list is going to be issued some time in the immediate future. The second version was a 700-page book, all of which is classified Secret. If one wants to take this to its logical end, it means that the people who are going to be subject to heavy fines through the implementation of these regulations (that's us, dammit! - FNE) will not be able to know what it is that the violation is based on."

Gentlepersons, we suggest that the above paragraph is worth reading twice. Once again, we remind you that the author is not some dummy but is a former President of Cornell University and headed a National Academy of Science panel looking into the general technology transfer problem. For what it's worth, that panel concluded that America's best bet for security lies in 'security of accomplishment'. As Intel's Bob Noyce puts it, "Let's grab the bill and run like hell."

OBEISANCE TO ADA?

It is indeed fortunate for America's universities that the Pentagon is not unanimous in supporting ADA. Only the Army is fully committed; the Navy is lukewarm at best and the Air Force is essentially hostile.

The reason this is fortunate for America's universities is that much of the funding for those universities arrives via Government grants, especially Department of Defense (Pentagon) grants. If the Pentagon backed ADA unanimously, how long would it be that those universities would either teach ADA exclusively in their Computer Science departments or loose that government funding?

Page 28, Column 1

If you do not have access to physics today, the matter is covered more briefly on page 58 of Feb 24, '83 Electronics magazine. A little flavor: "Currently the (Militarily Critical Technologies) list includes items that can be freely bought almost anywhere in the world." Like Japanese static or dynamic RAMs, hmmm?

And: "Industry and academic leaders in electronics concur with the NAS (National Academy of Science) Panel on Scientific Communication and National Security that tightening controls on federally funded research, presentation, and publication of technical papers and on product exports (emphasis added) will do almost nothing to enhance national security. Tighter controls are more likely to damage both military and economic security..."

However, the Pentagon is pressing hard right now for additional export restrictions. See, for instance, the page one story in Electronic News, Feb 28 '83: "...included a DOD proposal that the new law allow the Pentagon to review every company application for the 'Liberalized Distribution License,' widely used by industry to facilitate high-technology product exports to Free World customers.

"Industry sources stunned by the DOD proposal said such DOD review of all distribution licenses could cause application logjams in exporting U.S. goods in the highly-competitive Free World market.

"DOD hardliners have long wanted to crack down on the widely used distribution licences..."

Why is all this happening right now? Well, you may have noticed that the Pentagon seems to have priority over the civil arena these days, and, if you read the same newspapers we do, you will doubtless note that the head of the civilian part of our government has a less than firm grip on what the heck is going on. We think the Pentagon sees a one-time opportunity to get whatever it wants, and the Pentagon seems to be grasping that opportunity.

And that is as much as we want to discuss a subject that is largely political. We try hard to stay away from religion, sociology and politics in this newsletter.

It is interesting to note that we were criticized by an American Super-Patriot about a year ago for shipping DTACK boards outside the U.S. We sure hope that Super-Patriot never finds out that our West German competitor IBS is shipping to persons who are not American citizens. Some of IBS's customers for their 68000 board are - horrors! - West Germans!

Page 28, Column 2

THE 3M OPTICAL DISK:

There was a short article in Electronics magazine, Feb. 24 '83 an optical disks, the non-erasable first generation variety. Since 3M is actually shipping 100 disks per month as evaluation units, we thought you might like to know more about that unit.

"With a net user capacity of 1.6 gigabytes per side, 3M is targeting the low end of the data-storage market with this disk, competing initially against magnetic tape and microfiche and giving up some density to gain cost advantages." 1.6 gigabytes? Low end??

What we are talking about here is a 12 inch removable two-sided disk. Remember, it's not erasable.

60 FOOT TALL GORILLA?

Back in issue #6 (Jan '82) we told you that the Intel iAPX 432 micro-mainframe had some performance problems. In issue #10, eight months ago, we buried the 432.

In Electronic News, 21 Feb '83 there is a headline story on the 432. Over 63 column inches no less. Their conclusion: the 432 has some performance problems and its survival as a viable product is in doubt. Noooo...

THOSE MEAN 32-BIT MACHINES:

The same issue of EN included another front page story on 32-bit microprocessors. This is a long article; 110 column inches even without its extensive sidebar on the use of CMOS in the new parts coming out. Since there are not a whole lot of genuine 32 bit devices out there (although we insist that if the 8088 is a 16-bit processor, then the 68000 is a 32-bit processor) the article consists almost entirely of speculation. On the other hand, the speculation is from people with leading positions at Intel, Motorola, National, Fairchild, T.I. etc. Translation: manure is being spread, it is being spread heavily and it is being spread by experts. Pull up your pants, it's too late to save the shoes!

Perhaps the most notable thing in the article from our point of view is the first quotation for attribution regarding the iAPX 386. It is from Intel's Microprocessor marketing manager Jeff Miller. He asserts that the 386 will be "completely software-compatible with the 286."

And since the 286 is completely software compatible with the 8086, and the 8086 is source code compatible with the 8080, the 386 will be an 8080 emulator, not a real computer. As we have told you already elsewhere in this issue.

Page 29, Column 1

HINTS FOR THE APPLE CO:

Since you folks are being so nice to us these days, we thought we would explain to you why you lost market share in the early part of last year, and why you have now begun to resume growth near the rate of the rest of the industry.

(An aside to persons who are not employed by Apple Computer: No, we have not gone back on our promise not to pick on Apple any more. This advice is intended to be helpful. As to asserting that Apple lost market share, why, even the Sol of Libes has reported that. See Mar '83 BYTE, page 493, the top of the last column. By the time Sol finds out about something not involving the S-100 world and pushes it through the 4 month BYTE delay line, you can be assured it has become common knowledge.)

First, why you lost market share early last year: you will recall that you cut off most mail order sales (you tried to cut off all mail order sales). Next, you terminated a number of retail outlets over the question of mail order sales and other, more trivial subjects. We seem to remember that you and the Computerland chain parted ways over, it was rumored, your desire to decide which Computerland franchises would carry the Apple while Computerland officials wanted to retain that decision for themselves.

In addition, almost all of the advertising expenditures of the Apple Co. were directed toward promoting the Apple III, not the II. (If this is not the case, it seemed to be the case at the time. We can look back at our file of BYTE magazines and Apple Orchard issues of the time period in question to determine whether we are right, can't we?)

Let us examine the cumulative effect of these actions, as we perceive them:

1) With mail order outlets shut down, advertising for the Apple II essentially vanished from the national magazines except for that paid for by the Apple Co. However, mail order (discount) advertising for the Atari, Commodore and other lines did not dissapear. Since most Apple IIs are purchased by first-time buyers, you lost many customers who had picked up BYTE for the first time and wound up with another brand because they did not know about the Apple II. Hiding the fact of your existence from the public is an excellent way to reduce sales.

2) Americans love bargains. Likewise Canadians, Mongols and Finns. Some Apple II customers were lost when, after saving up their pennies for months until they had enough to buy at the bargain prices formerly featured in the mail order vendor's ads before those

Page 29, Column 2

ads were cut off wound up going to their local Apple dealer, discovered the local prices were hundreds of dollars higher than those featured in their recent BYTE magazines (that 4 month lead time, you know) and wound up buying an Atari instead. In other words, you effectively raised your prices, something which is not commonly done in this industry.

3) (This one is a bit trickier.) By advertising the Apple III more than the II (by our perception) you sent a psychological message to the marketplace that the III was regarded as the successor to the II. Therefore, everyone should forget the II and march into their local Apple outlet and purchase an Apple III, right? People are less likely to purchase a product which they perceive is obsolescent and no longer fully supported by its manufacturer.

4) Now, about marketing psychology: We overheard a very convincing argument during a visit to our nearest Apple vendor a year ago. The argument ran, "The Apple III is really not more expensive than the II by the time you buy all the goodies needed to bring the II up to performance equivalent to that of the Ill. And since the Apple III is ever so such nicer than a cludged-up Apple II, you should obviously buy a III!" The problem with this approach is that anyone who buys a III must pay for it. That antediluvian marketing approach predates the invention of the mortgage. On the other hand, the cludged-up II was purchased using the New American Way, which we thoughtfully explained earlier.

A summary: you hid your best selling product from the public view, you reduced the number of retail outlets for that product, you raised its price, and you tried to force a different, more expensive product on the public, one which had been widely panned in the industry media. Can there be any surprise that your market share took a big drop?

So such for past history; let us review more recent events. Apple sales have been improved recently because you have done the following things:

1) In the last part of your last fiscal year you introduced price cuts by offering packages at prices below the total list price of all the items in that package. Like we said, Americans love bargains.

2) Even better, local vendors began to advertise those bargains in the local media. Here in southern California, that means in the Saturday sports section of the L. A. Times. Those ads let the public know that Apples existed and that they could be purchased at bargain prices. Incidentally, we saw some evidence that you were partly subsidizing some of those ads. If so, congratulations on a smart move. Thus, the last

Page 30, Column 1

quarter of your last complete fiscal year showed improved sales.

3) Although those promotional price cuts had been due to end in Sept, you actually continued them into the first quarter of your current fiscal year. We understand that your sales in December were fabulous! Perhaps this marks the resumption of your keeping pace with the expansion of the personal computer marketplace. More simply, perhaps you will no longer lose market share. (An aside to eavesdroppers: in the personal computer marketplace, one must increase sales it 80 to 85% per year, compounded annually, to maintain market share.)

4) You very intelligently kept those promotional package prices when introducing the IIe in January. Your sales are doing very well indeed right now (the first week of March). How do we know? We carefully examined the personal computer ads in yesterday's (Saturday) Times sports section. We discovered that ads for the IIe outnumbered those for the nearest competing personal computer by about three to one, and the ads for the IIe were generally much larger than those for other personal computers. The number of column inches devoted to the IIe was an order of magnitude, perhaps more, than that devoted to the nearest competitor.

For these recent changes in your policies, we offer our congratulations.

For those eavesdroppers who are wondering what our angle is, this is absolutely straight. Every IIe sold by Apple creates a new potential customer for us, and every LISA that will be sold will create a desire for a 68000 with a big memory among many II and IIe owners. Since our prosperity is inevitably linked to that of the Apple Co. we want to offer constructive suggestions intended to further Apple's future prosperity. In this spirit, we offer these suggestions for the future:

1) Please do not loose sight of the fact that most of your income derives from sales of the II and IIe. Sure it's nice to brag about a 68000 system. We know, we brag about a 68000 board, right? But don't loose track of what is paying the bills.

2) Do not forget that the New American Way is the force behind many, many dollars changing hands in the personal computer marketplace. Many people buy their computer systems a piece at a time.

3) Given changed conditions, you might reconsider your decision barring mail-order sales. The changed conditions involve the fact that there are so many IIs in the field that a new buyer may learn to operate the unit with help from a neighbor rather than needing

Page 30, Column 2

support from a dealer. We would like to point out that the VIC-20, among others, is offered for sale via mail-order discounters without damaging Commodores' sales or their bottom line.

4) Please, please send the persons responsible for your pricing policies back to school to learn about 'price elasticity.' It can be enormously profitable to drop your prices! An example: Commodore had intended last year to drop the VIC-20 in favor of the new MAX machine. So they dropped the price of the VIC to what would provide a smaller (but still substantial) profit margin to clear inventory and to keep the factories busy while tooling for MAX was accomplished. To Commodores' astonishment, sales of the VIC took off dramatically, to the extent that Commodore was forced to cancel the MAX since the VIC was so profitable and was taking up all their available production capacity. (Got that, Ron?)

5) We both know about the 'not invented here' syndrome. Nevertheless, we suggest that it might be a good idea to watch for personal computer manufacturers who are growing at a rate significantly exceeding that of the general marketplace, and to examine the reasons for their success. You just might learn something that could be profitably applied to your operation.

After all: the one thing that you and your FNE undeniably have in common is a fond regard for profit, and a fonder regard for larger profits. Hmmm? Finally: go forth and prosper!

The reader is advised that this newsletter continues under its original management. FNE has experienced no recent brain damage, nor has he received any threats of either the legal or illegal variety. As we said (well, wrote) such earlier in this newsletter, we have changed our policy because we do not want to redundantly repeat what is being covered (very well) elsewhere.

We have used the expression 'bottom line' several times recently. For those of you who say not be familiar with that term, in explanation follows:

Publicly traded companies such as General Motors are required by law to provide an audited annual financial report to each of its registered stockholders. Among those things which must be revealed is the net operating profit (loss) after all adjustments, including taxes. So, the first thing you should know is that the phrase 'bottom line' refers to the net operating profit (loss).

Page 31, Column 1

The second thing you should know is that the 'bottom line' is not the bottom line of an annual financial report. The next-to-bottom line(s) of an annual financial report is the auditor's opinion. If all is well, the auditor's opinion will say something like, "This report has been prepared following usual and customary accounting practices." Then we reach the true bottom line: the auditor's signature!

Most stockholders do not read the annual financial report issued by the company (all they read is the stock price in the financial pages of their newspaper). But, since stock market analysts are reputed to read those reports carefully, the annual financial reports, especially of larger companies, are huge, glossy works of art. So who actually reads these works of art? Almost nobody!

Your typical market analyst picks up a financial report, notes the name of the company on the front cover and immediately turns to the last page. There he reads the net profit (loss) and then the next thing on the last page, the auditor's report. If the auditor's report is vanilla, he closes the report and sets it aside. Has he read the true bottom line? No!

Only intelligent, thoughtful analysts read the true bottom line: the auditor's signature, which identifies the firm performing the audit. Why is this of interest? Well, for starters, it's nice to know whether this year's auditor is the same as last year's. Who cares whether there is a change? Well, it's like this:

The auditor's opinion is an opinion. Not fact. An opinion as to the worth of slow-moving, somewhat perishable inventory is influenced by the auditor's estimate of the dedication of the management of the company to move that inventory. If sales efforts to move that inventory have ceased entirely, we can expect a certain adverse opinion. If management is determined to move that inventory via extensive advertising and re-introduction, the auditors might let the slow-moving inventory pass without comment (why does this sound so familiar?).

You think this auditor's opinion stuff is dull? Here's how dull it can get: about a year ago, the new management of a major U.S. electronics firm approached its auditors with the suggestion that a certain non-profitable subsidiary be closed and 'written off.' The phrase 'written off' means that the assets of the subsidiary may be (considerably) less than the value of the assets as carried on the books if the operation is terminated. Example: if you close a buggy-whip manufacturing operation, the automatic leather braiding machine say be worth less thin the $150,000 that is carried an the books.

Page 31, Column 2

The auditors replied, "O.K., it's fine with us if you shut down that operation. We'll just deduct the loss from this year's operating profit as a one-time charge due to discontinuation of an operation."

Before we continue, you need to know that there had just been a successful proxy battle (What? You don't speak proxy battle? Another time, O.K.?) and the dissidents had displaced old management (this is a true story about a real American company). Naturally, the new management wanted to look good as compared to the old management.

So, they told the auditors, "We think the operation was essentially defunct last year. We want to write the operation off on last year's statement. We realize that will require the report to be redone and a revised IRS report to be sent in, but this is a minor item compared to our desire to issue financial reports which are as accurate as possible." (Translation: We want to hang that loss on the old, deposed management, not us!)

The auditors pointed out, "But we have already, nearly a year ago in fact, issued an opinion that last year's annual report, which carried the assets of the operation you want to terminate, was properly prepared. You are asking us to sign a report which states that our previous opinion was erroneous? We respectfully decline."

(New) management replied, "In that case you are fired and we will find a new auditor who is more amenable to our wishes!"

We did not follow the above story, which did occur one year ago, beyond that point. The auditing firm naturally 'leaked' the story to cover their fanny, and so it came out in Electronic News, which is where we read it. But, and let us emphasize this, the company is not in the personal computer game. Which is why we did not follow the story.

Now you know why, after reading the 'bottom line', an alert person will then read the 'next to bottom line(s)' and finally the real bottom line: the auditor's signature.

IBM STUFF:

Although we have not seen the complete press release, leaked info says the PC II (or 2) is an intermediate step in the direction of getting rid of all those foreign add-ons. It is still an 8088 machine, but with a new mother board and more built-in memory. That figures; March seemed too early to release the

Page 32, Column 1

dramatically different iAPX 186 machine we believe is coming down the line.

Page 21 BLUES:

A couple of weeks ago, we were chatting on the phone with a long-time reader of this newsletter. To our surprise, he asked what was happening at IBM. We pointed out that we had presented our opinion of that matter on page 21, column 1, of the latest newsletter (which had been mailed over two weeks previously). Just one hour later the mail arrived. Another long-time reader wrote to ask whether we had heard of a competing 68000 gadget called the Acorn. We sent him a note pointing out that we had covered the Acorn on page 21 of the latest newsletter, in column 2.

We think there is a message there someplace.

We think this newsletter is getting too doggone long. With no ads, cartoons, (few) illustrations or figures, there is an awful lot of editorial material to wade through. It is not surprising that some people either never get as far as page 21, or, if they do, are not paying real close attention.

THE 20 PAGE SOLUTION:

Beginning with the next volume, we beleve we will limit the size of this newsletter to about 20 pages, and try to return to a roughly monthly publication interval. Note that we said roughly ; we aren't about to hang a deadline around our own neck!

Some of the next issues may look a lot like product releases; we finally have some of the additional hardware we discussed many issues ago coming along.

Also, we have just attracted enough subscribers that we now order a 'press' run of 500 newsletters. We discovered this is the magic number at the place that does our printing for us; per-copy costs drop noticably at that point. Now they tell us; printing 500 copies is cheaper than printing 400!)

Let us summarize the above: we will be producing a smaller newsletter that will often look like a product release, and it is costing less per page to print it. Unless you folks know something we don't, it looks is if we need to fine tune our subscription policy (again, already). Sigh.

OUR LATEST NEW POLICY:

Our new subscription policy-of-the-month is, beginning with issue #19, there are ten issues per 'volume'. If you have already subscribed to the next volume, your subscription will automatically be extended.

Page 32, Column 2

DISMOUNTING THE TIGER:

Since your FNE really has no intention of becoming a full-time writer, or even a permanent part-time writer, the question arises once again, how long do we keep this show on the road?

One necessary condition to continuation is a perception on our part that this newsletter is useful for more purposes then lining a bird-cage. We have seen a slow but steady growth in the number of subscribers; we suppose this is a good sign. And this does help sell boards, which is how we make a living these days. But we are now running full page ads in four magazines (Micro, Peelings II, Nibble and now CALL A.P.P.L.E.). The newsletter is not as essential to sales now.

We can put an upper limit on the life of this newsletter: when mention of the 68000 produces yawns the way mention of the 6502 or Z80 does today, we will have been out of print for several months already.

BUG REPORT: What would life be like without another bug to report? It's like this: in issue #17, at the end of page 3, we told you about a bug we had found in the floating point package and told you about the two fixes for it. Well, we just came across our yellow-lined original in which we marked up the fixes, and horrors!, there are three patches needed. The third was so simple we had forgotten it. In issue #16, at the top of page 34, change line 880 from MOVE.L D4,D5 to MOVE.L D4,D0.

What's even worse, the source code of the floating point package which we've been sending as text file MAT.S to purchasers of Apple compatible boards did not have that line corrected, although the other two fixes were included. We just plain forgot.

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, IIe, III, soft, LISA: Apple Computer Co. Anybody else need a 152nd millionth ack, have your legal beagles send us the usual threatening note.

SUBSCRIPTIONS: Beginning with issue #19, subscriptions will be $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. The address is:

DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705

GOODBY MAYBE YET AGAIN: For over half of our readers, this is the last issue they will receive unless they send us another negotiable token of their esteem.

(Formerly) REDLANDS will return next issue.