Issue # 41 DTACK GROUNDED Newsletter - May 1985

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

CACKLE TIME:

A MicroAge retail computer store just one mile from us received an AT&T UNIX PC (nee AT&T 7300) on the day the machine was announced. The other day that store was not able to demo the unit. It seems that some naughty person came in and changed the password on the unit, and since they do not know the NEW password, they can no longer turn it on and run it! (They may not know the SUPERUSER password, but THAT can be changed, too!)

Scenario: small company purchases a UNIX PC and over nearly a year's time gets lots of business records on the hard disk, including all current accounts receivable. Then naughty miscreant slips in and changes the login password AND the SUPERUSER password, effectively trashing the UNIX PC and all of those business records. Wonnerful, wonnerful! We believe that the question of whether Digital Acoustics should buy one of those little gems has been answered. Besides, project engineer does not like sound made by disk drive (suspect is normal).

Aren't passwords neat? Especially passwords which can be changed by any UNIX guru who knows the magical incantations, whether he or she is LEGALLY permitted to change passwords or not? (You DO understand that all of those AT&T machines will be shipped with the same SuperUser password, and that most folks will not change it?) HEE HEE HEE!

FNE DEMOTED (SIGH):

We are no longer an IMPORTANT executive-type. You will remember that an IMPORTANT executive has one of these important-looking computers where the main chassis containing the disk drive(s) and the CPU sits on the floor beside the desk, and where the executive HAS NEVER TURNED THAT COMPUTER ON AND RUN IT! Well, our project engineer has stolen our Tandy 2000 from us and it now resides on - and alongside - HIS desk. He's not IMPORTANT, though - he uses it!

Page 1, Column 2

------------------------------------------------------- 
Windows by TOPVIEW .................................p.2 
68796 newsletter ...................................p.3 
80286 bug(s) report ................................p.5 
The MACK - some reader viewpoints ..................p.6 
New Hitachi graphics controller ....................p.8 
Arthur Clarke watch ................................p.9 
32032 delivery problems ...........................p.12 
Just how slow is C ? ..............................p.13 
We Get Mail .......................................p.17 
68020 assembler ...................................p.20 
HALGOL report .....................................p.22 
REDLANDS ..........................................p.23 
New DTACK price list ..............................p.27 
-------------------------------------------------------

Now we have a choice of computer to replace the Tandy 2000. However, we suspect that the only choice which will keep project engineer from disturbing our desk-midden is either another Tandy 2000 or a 7th Apple II - not the best of choices. Remember when employees were respectful of higher management and did as they were told?

MATH CHIP DOINGS:

Since the subtitle of this rag mentions the Nat Semi 32081 math chip you may have been surprised how little we had mentioned that part the last couple of issues. Well... TADAA! Digital Acoustics now has a version of HALGOL release v.03A which supports that math chip! And if you purchased an experimental math board from us, you should now have in your hot little hands a disk which contains the run-time code! See p.22 for more details.

DRAM PRICES PLUMMET MORE!

As we mentioned on the front page of issue #39, 64K DRAM prices are dropping like a freight elevator. Uh, make that WERE dropping like a freight elevator. You see, 64K prices have just hit bottom, which is about $1 per chip. The reason that is the bottom price is that when prices drop below that point, the manufacturers turn their attention elsewhere. For instance: Toshiba no longer makes 64Ks and has converted that production capacity to custom chips and to 256K production.

This naturally brings us to the next subject, which is the new price list which can be found on the back of this issue: you are now supposed to buy!

A MOMENT OF SILENCE:

Let us all bow our heads for one minute to honor those who died in the mad stampede to purchase the new mass-market AT&T UNIX PC.

Page 2, Column 1

PC MAGAZINE WATCH:

Most of you readers apparently do not follow the IBM PC world or its magazine, which is a shame. Even for dedicated Applephiles for whom IBM is the enemy, it is a good idea to watch what the enemy is up to. You will remember that PC magazine got so thick that it had to go to biweekly publication - and then STILL stayed nearly as thick! Well, it is getting skinnier these days. The April 30 edition, which arrived in the last week of March, is down to 266 pages. Look for PC to return to monthly publication soon...

In that issue, there is an article on the ethics of software piracy. Most of you know that ADAPSO is waging a fierce legal battle against corporate piracy these days, and is suing a division of Standard Brands, Inc - and Standard Brands is about the 50th largest (by sales) U.S. corporation. Big game indeed!

The lawsuit is based on the U.S. copyright law, the same law which protects (for instance) magazines from having their articles photocopied. Yet PC asserts that ADAPSO's prexy Jerry Dreyer "acknowledges that he'll photocopy an article even though it is illegal to do so (p.185)." In other words, ADAPSO is NOT proceeding on moral or even legal principle but on WHOSE OX IS BEING GORED. Tsk!

WINDOWS BY TOPVIEW:

You may remember that we spent some time discussing bit-maps and windows in the last issue of this rag. Well, the same issue of PC devotes considerable space to an in-depth examination of IBM's TopView windowing program and some of its competitors. There are four major articles by four writers plus numerous side excursions. Here are a few quotes:

"TopView is for the birds... Not that TopView isn't a significant program. It's a watershed product, even if no one buys it." (p.111)

(A competing product): "At this point, [DRI's] GEM is extremely small - roughly 100K, and it allows only one task to run at a time." (p.128)

"Although it's heralded as the operating system of the future, the system's long and arduous menu sequence and DOS-crippling features are just two of the reasons why IBM's TopView just doesn't cut the mustard." (p.137)

"I'm now struggling to write this in WordStar, albeit a black-bordered, slowed-down, fickle TopView implementation of WordStar. First, TopView stole my border color. I can run all sorts of programs to get the color momentarily back, but then TopView just up and steals it again." (p.139)

Page 2, Column 2

"Actually, the supremely infuriating aspect of TopView is that it won't scroll automatically. ...you have to move the pointer inside the appropriate window, call up the main menu with the Alt key again, move the pointer up to Scroll, and punch Home. And the scrolling isn't exactly what you'd call speedy. In fact, it's pathetically slow. ...TopView is unnatural. It's balky and slow and unintuitive. It was like making love with your clothes on. It worked, but it wasn't exactly right." (p.140)

"...while it seems designed for greenhorns or casual users, beginners can't possibly answer the arcane questions it asks when changing program information - such as the "Range of Software Interrupt Vectors Swapped" or the amount of memory required by different applications." (p. 141)

On page 120 there is a summary of editor Bill Machrone's review of TopView. Bill concludes that TopView is unusable on a floppy disk PC and that it really needs a CPU AT LEAST as good as the 80286, plus virtual memory and "about 2 megabytes of RAM" (!). Of course, PC-DOS is still limited to 640K (even on the PC/AT, honest!) and, as Bill asserts, "DOS would have to understand virtual memory as well." But if you spend good money on all that hardware, and if Microsoft makes DOS understand virtual memory, then you will have a machine that runs just as efficiently as a regular PC WITHOUT TOPVIEW????

Boy, what we have here is a reprisal of Carl Helmer's "It's O.K. to write 68000 operating systems in PASCAL because the machine is so fast you'll never notice!", with a VENGEANCE!

DELIBERATELY BUSTED !

Can somebody out there please tell us just WHO are the folks who are dedicated to destroying the performance of the new generation of personal computers based on the new generation of micro processors? Apparently there is a large cabal which is frantic with fear that somebody is going to run a 12MHz 68000 20 times faster than an Apple II! Perhaps the problem is that a 68000-based or 80286-based personal computer would make a lot of minicomputers look REALLY BAD if the personal computer were used in an efficient manner! This is the only explanation we can think of for all the new software whose sole purpose, apparently, is to (severely) bust the machine it runs on.

HALGOL ISN'T BUSTED !

As you will discover elsewhere in this issue, HALGOL is nearing completion as a language. When completed, HALGOL will be the entire computer environment: operating system, editor, monitor, interpreter,

Page 3, Column 1

instantaneous compiler - the whole shooting match. And it will be able to run on the 68020 and 68881 which we will (hopefully) be able to purchase for resale in 1986. We are sure you have noticed that the largest selling machine (barring C-64s and such) USED TO BE the Apple II with expansion slots and the largest selling machine NOW is the IBM PC with expansion slots. Both Apple and IBM (but ESPECIALLY Apple) seem to be moving toward eliminating slots, and you have never been able to get the real source code for the BASIC which runs on either the Apple or the IBM machine(s).

Gee. We wonder if we should maybe think about making (in 1986) a 68020/68881 machine with expansion slots and a programming language/environment for which the source code is readily available?

(Our present main product offering, the Grande, has an open-architecture expansion CONNECTOR, which is effectively the same thing as expansion slots. The difference Is that it is not quite as convenient for small add-ons such as a printer interface or clock/calendar, but it makes possible MAJOR expansion, such as our VDHR or POTBOILER graphics systems - and it would be utterly impossible to wedge a VDHR system under the hood of an Apple II. And just like the Apple II and the IBM PC, it is the expandability of the Grande WHICH IN FACT ACCOUNTS FOR MOST OF OUR SALES!)

PORTING HALGOL:

More than a few of you readers have suggested that we adapt HALGOL to whichever 68000 machine you seem to favor. Well, HALGOL is not finished, and some of the machines you want us to port HALGOL to are not yet on sale in the U.S. However, let us assume for a moment that HALGOL is complete and those machines ARE for sale. We will point out that we are not independently wealthy and that Digital Acoustics is not the Ford Foundation or even the Red Cross. Besides that, Digital Acoustics' employees have, over the years, become accustomed to being PAID!

Has anyone noticed that Apple Computer, for example, Is NOT adapting ITS proprietary 68000 software for use with the DTACK boards? Why should WE adapt HALGOL to the Mack (or the QL, or the ST)? Where is the money incentive? And do not speak to us of pie in the sky bye and bye; our employees insist on receiving their paychecks NOW - not bye and bye!

We certainly do hope to prove that HALGOL is a good enough language/environment that SOMEBODY ELSE (perhaps several somebody elses) would like to adapt it to other machines! But not US, chum!

But first, we need to complete the HALGOL language/environment.

Page 3, Column 2

CONTINUED SUPPORT ?

DEC has shut down Rainbow production, on account of it has more completed inventory on its shelf than it can sell in the remaining future history of the universe. IBM and the PCjr, likewise. BUT - get this - both companies have promised to fully support their respective cancelled computers in the future! Just what, exactly, does 'full continued support' mean when the computer has been cancelled? We are glad you asked that question.

'FULL CONTINUED SUPPORT' means two things: first, that the company wishes to find some naive suckers to unload some of the rest of that inventory on. Even dumb suckers are too smart to buy a discontinued computer with no continuing support. Second (and perhaps most important), an announcement of continued support gives the manufacturer a legal argument to prevent its distributors and retailers from forcing it to recall its discontinued computer from dealer showrooms and distributor warehouses. "Heavens! Our computer isn't REALLY discontinued at all! It is just that we stopped manufacturing it because we have so much inventory stacked up that we will NEVER have to build any more!"

(Would you believe that the BYTE letter column once carried a letter from a reader who complained that Apple did not warn folks before suddenly dropping the Apple III? WHAT DID THAT LETTER WRITER EXPECT? "We are going to support the III for another seven months and then drop it?" Boy, would THAT announcement help sales! Nope! All computers are fully supported right up until the day, hour and minute that they are discontinued.)

68796 NEWSLETTER:

Victor Frank has four of his newsletters (see #39, p.18, col.2) in print now, and his publication seems to be evolving. Originally targeted solely and exclusively at folk reworking old surplus Wicat boards, the two most recent issues are much more general in their appeal. Hell, to tell the truth it is turning into a gossip rag much like this one!

Victor obviously owns a modem (we don't) because a significant portion of his newsletter (now) is reprints of stuff from various computer bulletin boards.

INTERESTING stuff such as more about the limitations of the Nat Semi 320XX architecture and information about the NCR 32-bit chip set. Also, the following item (apparently from "uucp#BRL-TGR.ARPA" ):

EVATT, 20 Mar 85: "Does anybody know the details of the demise of the jr? Please fill us in."

Page 4, Column 1

Ed Nather, 21 Mar 85: "Exactly this pattern of events was predicted last fall in the newsletter 'DTACK Grounded'. The author (Felgercarb N. Eloi) colorfully described the huge inventory of PC jrs piling up in the warehouses, and predicted IBM would 'enhance' the jr just enough to get things off the shelves and save the corporate image, then drop the product -- exactly what has happened.

"I dread reading the next issue -- Felgercarb is not terribly modest."

AWWW... just as we had managed to convince about 800 readers that we WERE modest, Victor and Ed have to go and blow our carefully developed image!

(Victor tells us that he has to search through an awful lot of dross to find the gems he publishes from those computer bulletin boards. If it is worth $20 a year to have somebody do this for you, here's where you send your $20 [U.S. residents]:)

Victor Frank
12450 Skyline Blvd.
Woodside CA 94062

MACKWORLD WATCH:

MACKWORLD is a magazine which, until now, was published exclusively for the purpose of cheerleading the Mack and of serving as a shill for Mack-related products. We have been buying McW on the assumption that we might want to look up a product review at some time in the future. We can usually thumb through the magazine and set it aside in about 20 seconds.

We were, therefore, astounded to discover an article (column?) in the April issue which addresses the Mack in an honest manner. See "The Inconvenience of Convenience", by Adrian Mello, on page 17. This article, all 56 column inches of it, is guaranteed to infuriate Mack lovers whose attention span is over three minutes (the critical stuff is toward the middle and end of the article). Uh... there ARE some Mack-lovers with an attention span longer than three minutes, aren't there??

Most interesting was the bald assertion, three column-inches before the end, that Mack really has to have MORE THAN 512K to perform in an adequate manner! That is NOT good news for the folk who have expanded their unexpandable 128K $2500 machines to an unexpandable 512K by spending another $1,000. Well, (sigh), some of the Japanese chip-vendors are already firing up their 1 megabyte DRAM pilot production lines. Perhaps Apple will offer a $2500 upgrade to expand the unexpandable 512K Mack to an unexpandable 2 megabytes?

Page 4, Column 2

(Bob P. has pointed out to us that the March issue (p.72) carried a review of the MACK MEMORY DISK software package which spoke of the Mack in less than flattering terms - and right at the start of the article where Mack-lovers would still be paying attention, too!)

Infoworld has recently run an interview with Microsoft prexy Jon Shirley. Commenting about IBM PC and Mack purchasers, Jon asserts: "(Mack) customers wanted ease of use, ease of learning, and they perceived the machine as being high-powered and fast, which is interesting because as you know, the Mackintosh can be quite slow."

April Dr. Dobb's, p.12 col.1: "For experienced programmers, [the Mack] Interface can get in the way, and the bulk of the bandwidth of the microprocessor is swallowed up by the graphics."

It does not matter how good a CPU you have; if you have to fight bit-mapped graphics, overly-complex operating systems and languages which are busted by being themselves written in another high-level language, your computer is going to be QUITE SLOW! It is interesting to note that some other folks are beginning to notice these facts - but there are not enough yet to overcome the cabal who are deliberately destroying the performance of the new-generation microcomputers.

ELECTRONIC NEWS WATCH:

EN is the WSJ of the electronics industry. It is a very reliable source of information, in our opinion the MOST reliable in our industry. It accordingly makes dull reading at times but sometimes the facts aren't dull. The April 8 issue, for example, is a doozie. Take these quotes from page 24 for example:

"Following a $14.9 million fourth quarter loss, Fortune Systems is said to be about to resort to a major reorganization and layoff in an attempt to cut costs. Fortune's board of directors is said to have approved the reorganization and cuts late last week. Insiders say Fortune's board is frustrated by the company's continuing losses and shrinking cash on hand."

"IBM, in the wake of its decision to halt production of PCjr, last week moved to address reportedly bloated PC XT inventories by dropping prices and adding diskette-based versions of the machine... IBM reportedly has a PC XT inventory of some 600,000 machines."

Gee, and we thought WE were the only one to notice that Fortune was unfortunate. Since Fortune has already gone through two complete management changes it seems unlikely that management is the problem. Do you

Page 5, Column 1

suppose their PRODUCT might be the problem? And we (and PC WEEK) have suspected for some time that excess XT inventory might be behind the shortage of ATs. Not incidentally, when EN suggests that IBM "reportedly" has a PC XT inventory of some 600,000 machines, we suggest that you might give SERIOUS consideration to the possibility that IBM's XT inventory is on the close order of 600,000 machines. EN is NOT a gossip rag.

We have written from time to time about Encore Computer Corp and its business plan which was apparently put together by Henny Youngman and the two dumbest of the Three Stooges. Well, this issue of EN carries a feature story about 47 column-inches long about Encore.

It seems that Encore, which still has no hardware product (they do have a very minor software product), is having a hell of a time putting together an underwriting syndicate for their initial public offering. Morgan Stanley, Merrill Lynch and Salomon Brothers are among the firms which have declined to touch Encore's IPO with the proverbial ten foot pole. EN reports:

"Encore's public offering has been the subject of much debate within the financial community. Observers have drawn comparisons to Trilogy Ltd., which is one of the few high technology companies to go public during its product development stage primarily on the strength of its founder's reputation. Trilogy's subsequent troubles, however, highlight the risk involved in such a venture and has made some underwriters wary of Encore."

It did not help that Encore, once it belatedly decided to develop its own product, decided to build around the 10MHz Nat Semi 32032. As EN reports:

"...Wall Street firms were wary of the Encore deal because the company has already disclosed that its system is late, due in part because of National's delays on the 32-bit chip... Encore's prototype system for Sperry, sources said, will use an 8MHz National 32032 instead of a 10MHz part as originally planned." Gosh! 10MHz 32032s are in short supply? Gee! We didn't know that!

EN adds, "Encore has gone through a metamorphosis of sorts, discarding its original plans to fund and guide fledgling firms in favor of developing its own machines." As we reported earlier, Encore has gone to Plan C.

Another feature story in that same issue is on DRI, GEM, and bugs in the Intel 80286. DRI is laying off - again - 10% of its current workforce, this time. It seems that GEM, which is a wonderful windowing program that is designed to take advantage of wonderful bit-

Page 5, Column 2

mapped graphics, is a severe cash drain. [Let's see, now: VisiOn destroyed VisiCorp, IBM's TopView has bombed, but Microsoft's windowing program has NOT bombed because it is LATE LATE LATE and has not yet been released. Obviously, windows and bit-mapped graphics are wonderful? EN notes, "No firm has yet succeeded at marketing GEM-like products."]

In addition to GEM's cash drain, DRI's Concurrent DOS 286 is running late because the Intel 80286 has bugs. You know that fabled built-in memory protection the 80286 has? The memory protection which slows the chip to a walk if switched on? Well, that memory protection - and some other stuff - DOES NOT WORK! If you will not take our word for this, perhaps you will accept Intel's word? EN quotes Intel's George Alexy, marketing manager for high-performance microprocessors, thusly: "There is a legitimate bug in the part. [The memory protection and DOS emulation capabilities] worked in the B-1 step but not in the C-step. We're going to make a change in the E-1 step."

EN further notes, "He said the part's shortcomings were discovered by DRI once Intel had advanced to the D-1 step, in which it attempted to make speed enhancements. Intel is currently in production on the C step 80286... It plans to start producing the version corrected for Concurrent DOS 286 capability in the third quarter. The scheduled shipment date to DRI is 'confidential', he said."

[Note that Intel is desperately trying to enhance the speed of the 80286, with little success. IBM is still shipping ATs with 6MHz parts. And it was two years ago that AMD was running its 'busted tricycle' ads telling us what a hot performer the 10MHz 286 was! Let's see, now: we shipped our first 12.5MHz 68000 board product, using a processor routinely purchased across the counter of Hamilton Electro Sales, on 1 June 1982! Also, we reported recently that the 80286 was bug-ridden and received an indignant letter from an Intel employee, who shall remain anonymous, that "there ain't either any bugs in the 286!" SUUURRE there aren't.]

EN's story covers 27 column inches and covers much more detail on DRI's woes and the 80286's bugs than we are reporting here. This issue of EN has lots more interesting stuff, such as yet ANOTHER feature story, this one on IBM's becoming its own supplier of hard disks for the AT. It seems lots of disk manufacturers, having noted the way IBM hard disk suppliers have a strong tendency to go belly up, have declined IBM's kind invitation to bid for the business.

Since Victor and Ed have already blown our modesty image, we do not mind pointing out that ALL of the above stories In that issue of EN were printed (in greater or lesser detail) here FIRST!

Page 6, Column 1

MACK PERCEPTIONS:

Here are two - maybe three - reader viewpoints on the Mackintosh:

"Greetings and salutations. This letter is inspired by the phone conversation we had last Saturday morning re. the Mack, its disk access problem and the paradoxical position that I have staked out that even though the Mack (128K) accesses a slow disk too often, nevertheless the INFORMATION BANDWIDTH between computer and human is an order of magnitude greater than a plain vanilla CP/M or MS-DOS machine.

"I strongly believe after months of reflection that this particular bandwidth problem is the single most important issue in computing in the mid 1980s (but) not many experts explicitly recognize the problem in these terms yet. I would cite as examples the Xerox Star, LISA, Mack, Jackintosh, and Amiga. Also the integrated applications such as 1-2-3, Context, Ovation, Open Access, Aura 5, Trakker, Jack2, Dayflo and a dozen others. The final example of this trend toward greater bandwidth are the integrated environments including VisiOn, Desq, Gem, Windows, TopView and others.

"I am not quite prepared to write the definitive paper on the topic but I am eager to bounce some ideas off a skeptical curmudgeon such as yourself.

"For example, punched cards fed into a batch mainframe (circa 1960) resulting in a printout some hours (or days!) later is an example of LOW INFORMATION BANDWIDTH between human and computer. The recognition of this fact by Kemeny and DEC and others directly led to the development of the timeshared minicomputer around 1965. A timeshared machine handling 4 or 16 or 128 users communicating through 110 baud TTYs was a dramatic improvement in human/computer bandwidth.

"Because the information bandwidth between the typical user and the timeshared minicomputer proved to be so much higher than batch mode mainframes, much more productive work could be accomplished in a given time period AND FOR THIS REASON THE MINICOMPUTER INDUSTRY TOOK OFF, building such companies as DEC and Data General. I believe this analysis is the primary explanation of the computer revolution we have been witnessing for the past twenty-five years.

"Consider the following: CRTs replaced TTYs as primary I/O devices because their greater speed increased human/computer bandwidth. And the computer revolution marched on.

"32-bit VAXes replaced 16-bit minis because their greater speed increased bandwidth. And the revolution marches on.

Page 6, Column 2

"But this comes as no surprise to an old-time ASM speed freak such as yourself. You know these observations are true and significant. Let me try to summarize these observations in a statement we can both agree on before probing some more controversial positions.

"The computer revolution is fueled by increases in the human/computer information bandwidth which effectively translates into greater productivity for the individual worker. One way to increase this bandwidth is to provide a given amount of information in a shorter period of time (e.g., speed things up).

"Here comes the controversy: I would argue that this idea I am calling human/computer information bandwidth is not a simple or one-dimensional concept. I believe that you must consider at least one other component in this bandwidth equation and that is INFORMATION DENSITY.

"The classic example of what I meant is contained in the ancient Chinese observation "A PICTURE IS WORTH A THOUSAND WORDS". Cliches like this do not survive 3000 years without having some grain of truth. I think it becomes obvious to anyone who seriously and objectively (not two of your stronger suits) contemplates this poor, stupid cliche that is self-evidently true. Not only is it true, it is important for the future of computing. Not only is it true and important but it explains the rabid devotion that Apple Mackintosh owners feel for their machines. The wimpy little nine inch B&W screen on the Mack is the most information dense medium in the personal computer world today. I wouldn't trade it for anything else in the market.

"The fact that I can freely mix arbitrary graphics (MackPaint) and structured graphics (McDraw) and highly structured graphics (Chart) with almost any type of textual material I want (different fonts and sizes and effects) means the [the following expression was printed in a humongous font - FNE] MAC IS THE MOST INFORMATION DENSE MICRO IN EXISTENCE. And even though the Mack relies too heavily on a slow disk drive nevertheless the human/computer bandwidth is at least an order of magnitude greater than traditional command line interfaces in a single typeface on a character mapped display.

"By the way, as someone who considers keyboards the biggest kludge in computerdom (thank God I'm not Japanese!) I consider the little mouse you are skeptical of as a dream input device... again, because of the bandwidth consideration.

"Felg, I fully expect the problems of the Mac to be ironed out in a relatively short amount of time. The Finder can be rewritten and condensed and fully debugged. When it is placed in ROM it will smoke. The

Page 7, Column 1

floppy can be double-sided and interfaced via DMA. A hard disk with controller and DMA can be made integral to the Mack. A 68010 and/or 68020 with a floating point chip is somewhere in Mack's future. In other words, the vintage 1984 Mackintosh is an extremely impressive machine and the vintage 1986 Mack is going to be a killer." John B., Burlingame CA

Another reader viewpoint:

"My perceptions about the Mackintosh are slightly different than fair FNE's, who has compared it to a luxurious car that has every conceivable comfort and option but only goes north. I think of my Mack as rather like a Saint Bernard puppy who urinates and defecates all over my house, chews my shoes, often slowly responds to any command and yet is possibly trainable as a real working, ah er computer.

"My other observation is that the most vocal defenders of the Mack are persons who have graduated from Apple IIs. I know of all three breeds of Mack owners - those for whom the Mack is really a first computer (Commodore 64s excluded), those for whom the Mack stole love of an Apple II, and those who have experience with IBM PC style computers.

"All of these breeds will admit that the Finder could be faster, and that the graphics of the Mack are a step above most other computers. But I find that the new user does not want to defend the Mack. He simply knows that it works, does what he wants, and of course he is comparing it to a calculator and pencil & paper.

"The graduate (from Apple II land) will defend the Mack on whatever grounds he can find. He will tell you first that the software will improve (which it has), that Finder will be rewritten and be better (which it is), that more software will be available (which is true), that you can wait for color (hmmmm), that a Fat Mack with two drives is the only fair way to compare the Mack with other (read IBM) personal computers, that the Mack does so much more than a PC and that you can simply plug it in and do what you want.

"The third group are those that have significant dealings with IBM PCs or equivalent (e.g., fair FNE and his Eagles). That group will not put up with the urinating, defecating lovable puppy dog unless forced to do so. I for one was forced to do so in writing a book on the Mack, which in the beginning and now at the end seemed like a good idea. The middle part of the exercise, though, was not so much fun. What I found was that as I used the Mack, even though the disks were slow, even though I could get myself into swapping disks 50 times (I bought my second drive two days after the Mack arrived and still had an elbow session that tried my patience), even though I had to wait on Finder

Page 7, Column 2

like the cold start on the IBM, even though the keyboard leaves lots to be desired, even though the mouse needs two buttons but has only one, etc. I began to like it just like some beqin to love a urinating, defecating puppy dog.

"I am more relaxed when I Mack because I have to be - to do otherwise is to go into psychotherapy. I find the mouse useful since I can hold my drink in the other hand (one has to drink when one Macks if one has used a real computer) while Macking around. And, I suppose just as importantly, there is more Hacking while Macking. On COMPUSERVE, the activity concerning the Mack in the last year, and especially the last three months, is about triple the activity of the IBM PC. I guess that the PC, even though a great hacking machine, does not breed hackers as much as a Mack does. Maybe it's that PC users are either more interested in getting work done, or maybe they are just not as verbose and friendly as Mackers are. Whatever, there is a lot more activity on the Mack portion of MAUG than on the PC bulletin board.

"My co-authors are not PC users. They love the Mack and defend it in circumstances when they should know better. Yet they graduated from the Apple II and not from a PC. Most of the comments that I have seen seem to carry that thought out. Apple II users are in love with the machine, which is to be expected, while PC users are not, also to be expected. In fact you can get a feel of what kind of machine the Mack is by noting that there is a great music program (MUSICWORKS), there are at least 10 data base programs, there are 4 C compilers, a rather appealing BASIC (Microsoft 2.0), a FORTRAN, etc. but only two (about which I know) word processors - Mackwrite and Microsoft Word.

"The Mack is being trained at my house, it urinates and defecates less and less on me and my diskettes, and with such programs as MUSICWORKS and the C compilers and a 384K upgrade/addition (the Saint Bernard starts running like a greyhound), I think it will earn a membership in the family.

"I think that ends the debate (apologies to Jeff H. and Frank H. p.12 #39) at least for me. I no longer bother to debate about it. If someone has not a PC, has not computer savvy, needs not 1-2-3, and can use a mouse, then the two drive Fat Mack may be a good choice." Bob P., St. Louis MO

John, the Magna Carta which King John signed in 1215 at Runnymede, and from which most of our personal liberty devolves, was NOT a series of pictograms. Shakespeare did NOT draw comic books. The Neandertals drew real purty pictures on their cave walls but they are not, in

Page 8, Column 1

retrospect, regarded as civilized. Be careful how hard you ride a cliche.

You say you dislike keyboards and love mice? Well, how would you like to turn out this newsletter using a mouse, not a keyboard? Like 41 issues of it?

As Bob points out, we constantly use a CP/M machine with disks which we never swap more than once, which we can and do remove from the machine anytime we want (provided the activity light is off - and it goes off FAST after we save a text file), and which has a lovely 80-column 12-inch display which NEVER falls behind our typing, even though with all the practice we've had we are a fairly fast typist. We believe that Bob explains our attitude toward the Mack very well. And we do not have any interest whatever in spending several months housebreaking a St. Bernard puppy. Thanks for providing a rational basis for our obvious anti-Mack attitude. (signed) Skeptical Curmudgeon, aka FNE

Stick around for a bit, John - we are going to examine a third point of view regarding graphics and the human/computer information bandwidth. The following is yet another letter from an Aussie correspondent, who apparently has a lot of spare time on his hands:

A THIRD MACK VIEWPOINT:

"I have heard that 7220 systems are as slow as a wet week, except when emulating a plotter or using really fast static RAM - that they are so much slower than the Mack when doing raster ops, such as text, pattern fill, or animation.

"If this report is true it would explain why you believe so strongly that bit-mapped text is unacceptable. You would be basing that belief on the sluggish performance of your own 7220 board and on the sluggish bit-mapped text that dawdles onto the IBM graphics screen.

"How does your high performance 7220 board compare to the Mack on raster ops?" James 0., Dundas Australia

James, our 7220 board stinks when compared to the Mack on raster ops. 7220 systems are indeed slower than a wet week when used in a Mackish manner.

On the other hand, when used for 2 or 2 1/2 dimensional CADD (Computer Aided Design and Drafting), the 7220 is blindingly faster than a Mackish bit-mapped system. What we are doing, James, is comparing a Porsche with an 18-wheeler Mack truck - and that is a big, big mistake. If we know anything at all about what we are going to use a vehicle for, there should NOT EVER be any question whether the Porsche or the 18-wheeler is best!

Page 8, Column 2

Since the last issue, we have had the pleasure of discussing "The Hacker's Mack" with Lee Felsenstein. In addition to designing the old Processor Technology SOL and the Osborne 1, Lee also designed the very old VDM-1, which you REAL old-timers will remember was an S-100 graphics board.

Although early information provided on a computer bulletin board by Lee asserted that a purpose of "The Hacker's Mack" included hardware modifications to the Mack or perhaps even a complete redesign/replacement of the expansion-slotless Mack CPU board, Lee has now reduced the scope of "The Hacker's Mack" to software.

And here we need to apologize to Lee and his fellow Mackers because we thought he greatly favored the sort of complex, inefficient interface provided by the Mack. We were pleasantly surprised to discover that Lee favors FAST, EFFICIENT code! Sorry, Lee - we thought that anybody who liked the Mack could not be interested in fast and efficient.

Porsches are obviously used in attempts to impress personages of an opposing gender while 18-wheelers are used to perform large amounts of economically beneficial work in a short period of time. In case you were wondering, the cutesy Mack, with its tee-niny B&W screen and loverly trash-can icon, is the Porsche.

As an engineer, we are biased toward the kinds of graphics that the 7220 is good at. And, since we lay out multilayer PC boards, we strongly favor color graphics. Dragging menus up and down or files over to a trash-can icon is not what floats our boat.

A NEW GRAPHICS CONTROLLER:

By the way, the 7220 was the FIRST of the mass-market graphics controller chips. Having created a market which did not previously exist, the NEC 7220 is now attracting competition. The latest graphics controller to enter production is the Hitachi 63484, of which we currently have two in house and 100 more on order - at $77.80 each. According to our calculations, this part is about 6.4 times faster than the 7220 when performing 2 or 2 1/2-D CADD - and, for reasons which we will not explain now, makes raster ops virtually impossible if you are working with multiple bit-planes (gray scale or color). However, the chip DOES do pattern fill in hardware and even provides a method of intermixing text with the graphics. Not a cheap or simple method, but a method... an OPTIONAL uncheap, unsimple method...

Thanks for writing, James. We are featuring your insight into the overhead of the C (and other) high-level languages elsewhere in this issue - FNE

Page 9, Column 1

ARTHUR CLARKE WATCH:

For the few of you who have never heard of Arthur C. Clarke, he is a pretty interesting fellow. In 1947, at the age of 17, he had published in the British magazine Wireless World an article in which he pointed out that an artificial satellite in a west-to-east equatorial orbit at a certain distance from the earth would seem to 'hang' in the sky at the same place all of the time. He then pointed out that such an artificial satellite would be ideally situated for use for communications!

At that time, the American altitude record was held by a two-stage rocket at 250 miles. (The bottom stage was a captured German V-2, the second stage a WAC Corporal solid-fuel sounding rocket made, we believe, by Aerobee.) Considering the then state of the technology, that was pretty advanced stuff for a British teenager.

Clarke went on through the 50s and 60s to have a successful career as a novelist in the rather restricted world of science fiction, which at that time was regarded with less respect than now. (Sometime in July, 1969 science fiction suddenly became more respectable. We forget why.) During this period, Clarke also had published a very short story called "the Sentinel". Hollywood took that short story and expanded it into the movie 2001. Since all of the kids are in bed we will tell you a secret: that movie bore remarkably little resemblance to Clarke's short story.

We are not sure what happened at this point. Perhaps the fame that the movie brought Clarke in the mainstream world instead of the greatly restricted science fiction world unsettled him. Perhaps he simply thought it was time for a career change. In any event, he and a cohort decided, of all things, to go look for sunken treasure, as in gold, in the East Indian ocean.

They found it.

Clarke has now been a resident of Sri Lanka (formerly Ceylon) for many years. According to all reports, he is regarded as a sort of national treasure by the government of Sri Lanka. So, with all financial pressures a thing of the past, Clarke has given up writing science fiction novels? Wrong. True, he now writes SF novels at longer intervals than in his youth but they are of greater quality. We would like to tell you enough about his 1978 novel "The Fountains of Paradise" - so that you might buy and read it (it is available in paperback: Ballantine 25356).

This novel carries the thread of TWO adventures - one in the distant past, one in the not-so-distant future. In the distant past, the story is of the creation for the local king of a garden of unsurpassed magnificence,

Page 9, Column 2

a wonder of the world. The future thread is the story of the creation of a skyhook, which is a thing as close to a free lunch as you are likely to encounter in your lifetime.

Here is how this works: take an artificial satellite orbiting at the correct altitude to appear to be motionless in the sky. Postulate two other satellites which are orbiting at the same angular velocity with respect to the earth; one 10% less distant from the earth and the other 10% more distant. In our imagination we will put these new satellites in place and release them. What happens?

Well, the lower of the two is not orbiting fast enough to maintain its - shall we say, altitude? So it enters an elliptical orbit whose apogee is its initial altitude. The higher of the two is orbiting too swiftly to stay in such a low orbit (even though it is the higher of the two) and also enters an elliptical orbit whose perigee is its initial altitude. Although each of our hypothetical satellites will periodically return to its initial altitude they will in general not do so at the same time. Hmmm.

Back to our original satellite in its nice stable 24-hour orbit, appearing to hang at the same point in the sky over the equator. Let us wave our engineering wand and cause the physical structure of that satellite to be extended 10% down and also 10% up, in a rigid structure. We will suppose that the center of mass of our vastly overgrown 'vaulting pole' remains at the correct 24-hour orbit, and we will give the 'pole' a bit of a spin so that the bottom end remains pointed at the earth. The extreme ends of the pole are now in the same location as our former hypothetical satellites. So the bottom end of the pole is being pulled toward the earth by the force of gravity and the top end of the pole is being pulled away from the earth by centrifugal force.

Let us now wave our magical engineering wand once more and extend the bottom end of our 'pole' to reach and touch the surface of the earth, while extending the outer, or 'top', end of the pole enough so that the center of mass remains at the 24-hour orbital altitude and the downward pull of the lower part of the pole is in equilibrium with the upward centrifugal pull of the upper part of the pole. Let us further suppose that our pole is 'fat' - that is, massive. And strong enough to serve as an elevator shaft for, say, a two-hundred-ton spacegoing vehicle.

If you know anything at all about space travel or orbital mechanics, you will know that once you are mostly out of the earth's 'gravity well' that you are already 90% of the way to any point in the solar system. Especially if you are not in a hurry.

Page 10, Column 1

Now we climb into our elevator with our 200-ton space vehicle and ride to the top of the pole. The top is really whizzing along out there WELL past the 24-hour orbit level; it has a LOT more linear velocity than is needed to maintain its 'altitude'. So we will wait until the top is traveling in the optimum direction for the desired orbit (generally tangential to the earth's orbit around the sun) and cast off! Our 200-ton space vehicle will be quite literally thrown into an orbit leading to the asteroids at a high velocity! No fooling!

We can hear the laughter already: "OUR STUPiD FNE HAS FORGOTTEN ABOUT STUFF LIKE CONSERVATION OF ENERGY, OF ANGULAR MOMENTUM AND MAYBE A FEW OTHER THINGS!"

Well, uh, that's not quite right. For starters, this is not OUR story, it is Arthur C. Clarke's. Let us finish with this outline:

THE ALMOST FREE LUNCH:

Suppose, at the very instant that our 200-ton space vehicle (50 tons structure, 150 tons fuel) is leaving for the asteroids that another 200-ton vehicle (50 tons structure, 150 tons precious minerals) has matched (tangential) velocity with the end of our pole and attaches just as the other vehicle casts off. Net result: suddenly, our angular momentum is conserved.

Ah, you say. But it takes energy, lots of it, to haul that 200-ton vehicle from ground level to the 24-hour orbital level, and more energy to haul the returning 200-ton vehicle DOWN (yes, DOWN!) from the 'top of the pole' to the 24-hour orbital level. That is true.

We now postulate FOUR 200-ton vehicles. Two are ascending the 'pole', one on each side of the 24-hour orbital level. Two are descending the 'pole', one on each side of the 24-hour orbital level. If we have a simple rope-and-pulley arrangement, we can imagine the ascending vehicle being towed to the 24-hour orbital level from ground by the descending vehicle. Similarly, the ascending and descending vehicles above the 24-hour orbital level will tend to 'balance out'.

(It is true that the average forces balance but we do not in general have a balance of forces between two vehicles at a specific time. This difficulty is overcome by simply postulating lots more than 4 vehicles in transit, a continuous stream - not unreasonable for an elevator 30,000 miles high!)

The principles of Clarke's skyhook which we have just outlined are physically correct and do not violate conservation of energy, angular momentum or other laws provided we have a steady, balanced traffic to and from space. It is truly a free (energy-wise) ride into

Page 10, Column 2

space, only requiring frictional forces to be overcome. As advertised, you are unlikely to encounter anything closer to a free lunch in your lifetime.

True, there would be certain practical difficulties with actually implementing such a skyhook - but why not read Clarke's novel?

THE GARDEN OF PARADISE:

Oh, yes: we did say that novel had two parts, one of which takes place in the past. Well, the architect/artisan, having created the greatest, most magnificent garden on earth for the local king, is in trouble. You see, the local king wants to own the SOLE AND ONLY greatest garden on earth. He certainly does NOT want to own merely one of two, or three, or four great gardens. And he certainly does not want a neighboring king to have anything remotely competing with his own wonder.

The artisan got word that he was to be blinded when the job was completed and committed suicide. The king was bitter at those who had spread the rumor; he had intended only to sever the artisan's hands - both of them - at the wrist.

THREE YEARS AGO

we made a big mistake. Lured by a flyer promising discussion of the Intel 8087 math chip, we attended a seminar put on by Intel exclusively for 'chief executive officers and decision makers'. At that seminar, we discovered that Intel was going into competition with its customers. We were told that development costs were far too high for us to design and build our own boards. The speaker proved conclusively that a company (such as Digital Acoustics) could not afford to build its own boards unless it was producing at least 1,500 boards a month. If a company was building fewer boards a month than that, it was economically imperative that it purchase completed boards from, you guessed it, Intel!

Well, that did not seem quite right. So we dug into the substantial stack of literature Intel had provided to see what they had to say about the 8087. It turned out that the flyer was highly misleading; the 8087 was mentioned only in passing. Having driven nearly ten miles to get to the seminar, we started digging further through that literature stack. While doing this we overheard the speaker asserting that if a company was building fewer than 35,000 boards a month, then it was economically imperative that it stop designing its own boards and instead purchase boards from Intel.

Finally, we decided that there was nothing of interest in the outline of the (all-day) seminar. So we

Page 11, Column 1

(grunt!) picked up the substantial stack of literature and left. On our way out of the sizeable hall where the seminar was being held we heard the speaker assert the if a company was building fewer than 5 million boards a month then it was economically imperative that it stop designing its own boards and instead purchase completed boards from Intel. (We learned later that our colleague LeRoy L. attended that seminar and reacted the same way we did, but he had hitched a ride with somebody else and COULDN'T leave!)

When we actually left the seminar, there was a local Intel technical representative pacing up and down outside in the hallway. We asked him why he wasn't sitting in on the seminar? "I can't stand listening to that crap!" he replied.

(Part of the economic analysis was the savings which could be achieved by firing all of your design engineers and all of your production workers. Well, at the time WE were the design engineer! Having fond regard for our own life and limb, we never discussed Intel's plan with Digital Acoustic's production workers. We wondered how many of the CEOs and decision makers were going to swallow Intel's thesis?)

TWO YEARS AGO

it became evident that not many had, because Intel's Oregon-based board manufacturing group was not doing well. And Intel had instituted a 10% across-the-board pay cut and wage freeze. Some of the engineers at Intel's Oregon board manufacturing facility decided that their careers could best progress elsewhere, and left Intel to form a company called 'Sequel'. They quickly learned that the name 'Sequel' was already spoken for and changed the name to 'Sequent'.

A very peculiar thing happened: Intel honcho Bob Noyce began to denounce the departed group as HIGHLY disloyal, and threatened them with a lawsuit. Noyce did this repeatedly using different forums for his attacks on the legality and morality of that group leaving Intel. From what we read in the media, Noyce's attacks were much more virulent and incensed than is the usual custom in the industry. It was abundantly clear that Noyce, and presumably Intel, looked with disfavor upon that group leaving Intel's employment.

The reason this was very peculiar is that Bob Noyce had TWICE jumped ship himself - first as one of the 'TRAITOROUS EIGHT' who left Shockley labs in 1956, with Noyce winding up at Fairchild, and later (1968) when he left Fairchild to form Intel along with Gordon Moore and Andy Grove (see issue #22, p.10). Apparently others were not to be permitted to further their careers as Bob himself had. (Yet another example of WHOSE OX IS BEING GORED.)

Page 11, Column 2

A second peculiar thing happened: Bob Noyce did NOT drop the matter after a decent interval but CONTINUED to incessantly rant and rave over the departure of the disloyal so-and-so's!

ONE YEAR AGO:

Perhaps it was a coincidence. Perhaps Bob Noyce, and Intel, were not involved at all. But A YEAR AFTER the departure of the 'Sequent' group from Intel, an editorial appeared in the magazine ED (Electronic Design) which personally infuriated us. The editorial was not signed and we were unable to get past the secretary in the ED office to discuss the editorial. So we tore the damn thing up and discarded it.

A year has passed and we have (mostly) calmed down. We are going to tell you about that editorial from memory. It seemed that the ED editor(s) had been speaking with a highly placed executive in the electronics industry (neither Noyce nor Intel were specifically mentioned) and the executive was crying about all the unfaithful engineers (sob!) leaving large companies to start their own endeavors. And after a full discussion of the issues with this highly placed executive THE ED EDITOR(S) DECIDED IT SHOULD BE ILLEGAL FOR AN ENGINEER(S) TO LEAVE A LARGE COMPANY TO START HIS (THEIR) OWN COMPANY! (We are not making this up, folks!)

Since slavery has been outlawed in the U.S., there must be SOME basis by which an engineer can quit the employment of a large company such as Intel. Perhaps if we merely cut off both hands at the wrists... or do we have to take the more draconian measure of blinding the departing employee?

SEQUENT'S GAME PLAN:

We do not know whether Sequent's original plans called for them to make a computer product based on Intel mIcroprocessors. What we do know is that their current plans call for them to provide a multi-micro architecture based on the National Semiconductor 32032. This architecture uses 1 to N processors depending on the customers' data processing needs. The theory is, the customer can start out with just one processor and then add more processors as his requirements grow.

By an astonishing coincidence, Encore Computer's latest plans just happen to be absolutely identical to the plans of Sequent.

The problem with these plans is that both are based on a 10MHz 32032 - and THERE AIN'T NO SUCH THING, production-wise. So Encore's "...system is late, due in part because of National's delays on the 32-bit chip... Encore's prototype system for Sperry, sources

Page 12, Column 1

said, will use an 8MHz National 32032 instead of a 10MHz part as originally planned (EN, 8 Apr p.8)." Geez! Encore can't even get ONE LOUSY 10MHz 32032 FOR A PROTOTYPE from National? Encore just completed (with some difficulty) its first public stock offering. "In its prospectus [for the public offering], however, Encore disclosed that National had experienced 'significant' delays in the completion of the microprocessors and only a limited quantity of prototypes had been made available to Encore for its development work (EET, 15 Apr p.76)."

EET then quoted from the [legally required] prospectus: "If National Semiconductor is unable to complete development of these microprocessors on schedule, or if these microprocessors become unavailable, fail to meet specifications [as in 10MHz - FNE] or cannot be produced in adequate volume to meet the company's needs, the company's business will be materially and adversely affected." Remember, Encore plans to sell its 1-CPU model for about $120,000!

DEPT OF TRUE FACTS:

If you wish to check on the status of the 10MHz 32032, just contact Nat Semi marketing for its advanced microprocessors. They will tell you that all is well, the product is on schedule and that you will be able to buy all the 10MHz parts you want starting tomorrow. The fact is, all is NOT well, the product is NOT on schedule and you most certainly will NOT be able to buy all the 10MHz 32032s you want starting tomorrow. Hell, Encore Computer can't even get one lousy 10MHz part to deliver a proof-of-product prototype system to its major intended OEM, Sperry!

All microprocessor makers lie about delivery of their new or improved micros. Sometimes this is simply due to optimism, but the fact is all microprocessor makers want you to design THEIR product into your product now rather than a competitor's product - and that is an ENORMOUS incentive to be somewhat, ah, OPTIMISTIC about delivery dates. However, our perception over the last 11 years is that Nat Semi lies the most, probably because Nat Semi consistently has the most problems bringing a product to life. And THAT, in turn, is probably because Nat Semi is a smaller company than Motorola or Intel and so generally tries to develop its microprocessors on the cheap.

'Way back in 1974, Hal Chamberlin (the computer music guru from MTU), along with a couple of his friends, decided to start a newsletter entitled "THE COMPUTER HOBBYIST". The fourth issue, dated Feb '75, carried an article by Hal comparing the 8008, 8080, and IMP-16 microprocessors. You haven't heard of the IMP-16? It was A 16-BiT MICROPROCESSOR! Made by Nat Semi! Available in 1974!

Page 12, Column 2

Yes, Nat Semi DID produce the first 16-bit micro. It also produced the SECOND 16-bit micro, called the PACE. We forget whether Nat Semi's INS-8900, aka SUPER-PACE, was the third or fourth 16-bit micro because General Instrument came along with an eminently forgettable 16-bit offering at about the same time as the INS-8900. Naturally, being such an early leader in the 16-bit micro market, Nat Semi eventually dominated that market, yes? Uh, nnoooo...

And last year Nat Semi became, (yawn) the VERY FIRST commercial vendor to produce working samples - SLOWLY working samples - of a 32-bit micro. So Nat Semi will eventually dominate the 32-bit market, yes? Uh, nnoooo...

(By "commercial vendor" we are excluding H.P., AT&T and others who have produced 32-bit chips exclusively for in-house use.)

Let us lay it on the line - there are a lot of companies out there who have planned products based on the 10MHz 32032 and on Nat Semi's promises to produce same, and these companies are HURTING! At least one such company - Syte (formerly) of San Diego - went out of business, reportedly because of "delays in bringing its product along." Betting a company on Nat Semi promises can be hazardous to your company's health. (You might want to review what we wrote about Nat Semi and the 16032 'way back in issue #4, p.14 - that's 3 1/2 years ago. Given the benefit of 20-20 hindsight, were we correct or were we correct?)

As we reported in issue #4, Nat Semi is a pretty well-run company if you ignore its microprocessor division(s). Yes, we know we have used a quote from EN twice in this issue, once in a commentary on Encore's problems and just above in discussing Nat Semi's problems. Different subjects.

WHERE'S THE SPEED?

As we reported elsewhere in this issue, Intel is also having problems producing bugless 80286's that run faster than 6MHz. On the other hand, Motorola has been routinely selling 12.5MHz 68000s, available across the counter at your friendly local authorized Motorola distributor, since spring of 1982. That's three years ago! And Hitachi has been second-sourcing the 12.5MHz part for well over a year and even Thompson CSF (a French company) is, perhaps, second-sourcing the 12.5MHz part now.

We don't know why Intel and Nat Semi are having so many problems getting their parts up to speed. One could speculate about the complexity - and the number of sequential gate delays - involved in the memory management built into the 80286. One could speculate

Page 13, Column 1

about the carry propagation delays involved in the 32032's 32-bit ALU and about Nat Semi's ability to produce parts using small geometries.

Meanwhile, you can buy 12.5MHz 68000s, and (it is rumored) 12.5MHz 68010s if you knock three times and ask for Joe. We have had two prototype 68020s which run (with a bug list, true) at 12.5MHz for four months now. Sample 12.5MHz 68881 math chips are available. Both the 68020 and the 68881 are built with 2 micron CMOS technology and no one that we know of doubts that Motorola will be able to produce 16MHz (actually 16.67MHz - the clock period is specified as an even 60 nsec) parts in due time, meaning in a year or less.

AMD is producing 10MHz 80186 CPUs, which does not do Intel much good and doesn't do the Intel followers much good either because IBM is apparently going to bypass the 186 and all the lemmings are following right along behind IBM. Nat Semi is producing some 10MHz 32081 math chips - we have one - and they may be producing 10MHz 32016s. The problem is, nobody seems to be interested in the 32016s because the 32032 is the same part except with a 32-bit data bus. What do you reply when a prospective customer asks why your design uses a crummy 16-bit micro when a software-compatible 32-bit version is (purportedly) available?

Both the Intel 80386 and the Zilog Z80000 (Dave, that still looks like 5 zeros to us) are at least a year behind the 68020. The Z80000 may be FOREVER behind; Zilog just got a new prexy and he promptly chopped a LARGE percentage of Zilog's work force! And the 68881 outperforms the Intel math chip(s) by a BIG, BIG margin.

Unless you know something we don't, that puts Motorola in the catbird seat where high-performance micro market is concerned. It does appear that we made the correct choice back in Nov 1980 when we went with the 68000. Now if Motorola would only stop shooting itself in the foot by trying to keep its high-performance products out of the mass marketplace! There are a very limited number of sockets to be filled in high-performance minicomputers, guys, and we haven't started to run out of silicon yet!

About C's HLL Overhead:

Daniel Lunsford's writeup in the last issue, in which he claimed that the abysmal performance of existing application programs written in 'C' was due either to poor UNIX-based run-time I/O libraries or to poor algorithms received much favorable notice, mostly regarding his assertions about the run-time libraries. For instance, an anonymous source at Sun Microsystems tells us that Sun re-wrote its I/O libraries and got a 30 to 40% speed improvement in its programs. However,

Page 13, Column 2

The other day, Lee Felsenstein, who has a LOT of experience with 8080/Z-80 micros, told us about his first encounter with a 16-bit microcomputer enthusiast. Lee asked, what do we need 16-bit computers for? "To get a larger address space." Why do I need a larger address space? "So you can have a lot more RAM." Why do I need a lot more RAM, Lee pursued? "So you can run programs written in high level languages." Why do I need to run programs written in high level languages? "So you can hire cheaper programmers!" the 16-bit enthusiast concluded.

there is a lot more than 30 or 40% overhead in WORDSTAR 2000, DRI's Personal BASIC and other such application programs and languages written In C.

Daniel L. would have us believe that the ONLY other source of HLL inefficiency aside from the I/O libraries is bad algorithms, but we don't believe that! (Sorry, Dan.) For one thing, it leaves open the possibility that the ASSEMBLY LANGUAGE PROGRAMMER might be the one to choose the bad algorithms, which could leave us with a C-based application program which runs TEN TIMES FASTER than the equivalent application program written in assembly! In fact, there are no such examples in existence (we are talking about real commercial programs).

Therefore, we need to look further into the question of C's HLL overhead. We begin with a letter from down under which apparently addresses the 90-10 rule but continues with the question of why C runs slowly compared to assembly:

"About the mythical 90-10 rule: the rule is correct, but the conclusion is a myth.

"The problem is that the programmer must represent the concepts, data, and algorithm of the problem that he wishes to solve in terms of the concepts, data types, and commands of the language he Is using.

"The 'efficient' code produced by optimizing compilers is an efficient representation of the concepts, data types, and commands of the language, not necessarily an efficient representation of the problem that (the) language is itself representing.

"The task of the programmer is to represent the data and translate the algorithm into terms the machine can handle. The rest is just detail. Naturally this translation will be most efficient if the programmer translates into things that may be directly represented in the architecture of the machine, rather than things that are directly represented by the HLL.

Page 14, Column 1

"Most C compilers have about a 'two to one overhead', in the sense that if you look at a small block of C code, it executes about half as fast as the same thing hand assembled. But if you were writing your whole program or a major conceptual section of your program in assembler you would not express your solution in a way such that a small chunk of your program was directly equivalent to a small chunk of C code. In other words an assembly language program is not 'the same thing hand assembled' so it runs a hell of a lot faster than 'the same thing hand assembled' - usually about 15 times faster.

"As a result your assembly language program would typically run about 30 times faster, not two times faster. In some cases the speedup can be as much as 1000 times, rather than two times. This is the case when your program is doing a lot of non-numerical symbol manipulation stuff.

"Because the speedup arises from the way in which concepts are represented, not from humans being more efficient than compilers, writing 90% of your program in a HLL, and then hand optimizing 10% in assembly can at most give a two to one speedup, and is generally not worth doing unless your HLL is interpreted rather than compiled.

"I repeat: humans are not much better at compiling than computers, so it is seldom worthwhile to rewrite the 10% in machine code, unless you are using an interpreter such as PASCAL or BASIC. The assembly language speedup comes from the way in which concepts are represented, not from the efficiency with which the representation is compiled, hence the 90-10 rule is irrelevant.

"By the way, some IBM mainframe FORTRAN compilers have a ratio of better than 1 to 1 - in the sense that they produce object code more cunningly optimized than most humans could manage. But because FORTRAN is extremely poor for representing many classes of problem, notably compilers, the effective ratio on that class of problem is about 400 to 1 - FORTRAN compilers written in FORTRAN are usually horribly slow and amazingly huge.

"Furthermore, in most large companies the job of optimizing the 10% is given to some low-grade bloke, who has not got permission to change the way in which concepts are represented and (who) usually does not have the knowledge - he is just being used as an optimizing compiler. As a result the speedup obtained by applying the 90-10 rule is usually insignificant, whereas the speedup obtained by writing the whole thing in assembly is usually overwhelming.

"A program written in assembly will usually run about five to twenty times faster than an equivalent program

Page 14, Column 2

written in C on an optimizing compiler with a 1.25 to 1 overhead and assembly language optimization of the 10% that takes 90% of the time, although this depends very much on the program, the programmer, and the way that the organization works.

"In a large organization where a number of programmers are organized in a hierarchical fashion, assembly language will frequently fail to produce a significant speedup because the inefficiency in concept representation derives mainly from the human to human interface rather than the human to machine interface, hence the tendency for large companies to use HLLs even in time-critical utilities." James D., Dundas Australia

James, we thank you for pointing out a way in which HLL languages inherently produce code which runs a great deal slower than assembly, optimizing compilers or no optimizing compilers. (James has three letters in this issue, two of which arrived in the same envelope.) Uh, we hope you do not mind that we agree with your comments completely - FNE

"Assembly vs. HLL: In issue #38, FNE put the issue where many of the readers have failed to find it. Namely, can operating systems or HLL be written in HLL? This excludes applications such as KEDIT which I am using to write this letter. KEDIT is written in PASCAL except for about 300 lines of assembly to do screen management. For those who know IBM CMS XEDIT, KEDIT surpasses XEDIT. For those who do not know, KEDIT is an extensible editor with full keyboard redefinition, intelligent macros, fast paging, fast Changes, many DOS commands, etc. etc. It is not a formatter and hence not a word processor but it is the best editor that I know of. Since it is written in (horror of horrors) PASCAL, we know that applications can be written in HLL. (The verdict still seems to be in doubt as to whether 123 is really all assembly or mostly C as Dvorak's challenge is unanswered.)

"So, can HLL or Operating Systems be written effectively in HLL. The empirical evidence seems to say NO NO NO. At least, the examples offered in DTG say NO NO NO. HLL operating systems and HLL HLL seem to be slow slow slow. There is a missing ingredient in the arguments though and that is who is doing the programming. An assembly programmer, especially in the cesspool of 8086, is going to be a good programmer and will be paid accordingly. In fact, good programmers will learn assembly to do what other good programmers do. On the other hand, if one decides that something will be written by a large group of programmers in a HLL, one does not hire assembly programmers who have the skill to program very well in HLL but rather average programmers (for an average salary) who will

Page 15, Column 1

produce average code. Compound this with too many cooks doing the cooking, and you have the empirical evidence.

"What can be done to refute the evidence? Nothing. Ask a single good programmer to program an operating system in HLL and he will laugh since he knows the things that he wants to do can not be done effectively in an HLL. Ask a group of good programmers to program an operating system in HLL and you bust the budget even if you could get them to do it. So, although I agree with FNE that no good operating system currently used nor good fast HLL currently available is programmed in HLL, it is for very different reasons. Since very substantial, fast applications (at least KEDIT) have been programmed in HLL there does not seem to be a completely technical barrier to programming an operating system or HLL in an HLL. There does seem to be an operational reason though.

"On that compiler overhead that FNE constantly disbelieves, namely a 2 to 1 overhead. Well, some preliminary work with MEGAMAX C on the MACK can show a less than 2 to 1 overhead using C vs. assembly. Briefly, a C program that 'flips' the Mack's screen (all 22K worth) can do as badly as flipping it 7 times a second. With making two loop variables and the screen pointer variable register variables, we can flip 17 times per second. Coding the flip portion in assembly while leaving a loop of 50 times in C, gets a flip rate of about 31 times a second. Now, in my book that says that the compiler, on this example, with good C coding, has less than a 2 to 1 overhead! More complete details will follow since such programs as the Sieve and this one are not good benchmarks as they do not make many function calls. But let one note that in the benchmarks in BYTE Jan '83 none of the programs appear to be particularly optimized and especially note that there are no register variables used in the C code. On the IBM, for example, assembly was reported to be 1.9 (seconds) while C came in at 6.0. That's 3 to 1 overhead which should fall to better than 2 to 1 with register variables." Bob P., St. Louis MO

Bob, C seems to match up better with assembly when a very simple, even simplistic, task is at hand - such as flipping a screen. When more complex tasks are at hand (e.g., WORDSTAR 2000), C seems to fare much more poorly. What we are trying to discover here are the reasons why C fares much more poorly.

When assigning "register variables" when using C, is one writing in an HLL or is one in fact writing very crude assembly? We'll betcha that IBM PC C will NOT EITHER speed up to 2-1 merely by assigning "register variables", Bob. The C language specification does not REQUIRE the compiler to accede to the request of the programmer to assign a variable to a register. After

Page 15, Column 2

all, there might not be a register available! And the Intel 8088 does not have many (any?) spare registers available when running C. The 68000 generally has LOTS of spare registers, meaning the C compiler is letting many of the resources of the 68000 lie fallow.

Writing a program in a HLL to accept input from a slow chemical computer sitting at a keyboard is no trick at all. We first did that on our old (and slow by today's standards) Wang 2200 eleven years ago. But when it came to interpreting the imbedded format commands... DEATH! When we got our 6502 attached processor going in the spring of '76 one of the first programs we wrote was a machine language formatter to accept and print (to a 300LPM TTY model 40! Yes, a real, honest 300LPM!) the text generated by the keyboard editor written in slow interpretive BASIC. - FNE

Daniel L. kicked off this somewhat serious discussion of why C-based application programs run slowly. Here is additional input from Dan:

"Let's look at some things about compilers in general, and C in particular. There are two main ideas that dominate the design of any compiler, these being the design of the language being compiled (is recursion permitted? Are procedures implemented, and are they permitted to be nested? What control structures are there? Are there reserved words? Etc.), and the design of the target machine (is the architecture accumulator-based? Is there a hardware stack? Can data objects be easily transformed into machine objects? Etc.). Looking at the first set of questions, we can see that they are in some sense analogous to the second set, in that the answers define what might be called a "pseudo-machine" (PASCAL, anyone?) or "virtual" machine, whose opcodes can be considered as the primitives of the language (by the way, Felgercarb, what are your opinions on the PASCAL Microengine? I really would like to know). A C-machine, for example, would have a "pre-increment memory instruction, that would correspond to the "++" operator.

"What most compiler designers choose to do is concentrate on the virtual machine, rather than the target machine. This allows them to separate the compilation process into two phases, broadly speaking: 1) syntax checking, lexical analysis, and parsing, and 2) generation of an intermediate code (generally in the form of parse trees and flow diagrams) which is then worked on in a machine independent manner to produce more compact intermediate code. The is then fed into a code generator for the target machine, and sometimes (not nearly often enough, to my way of thinking) this is subjected to further manipulations, which shrink the result in a machine dependent manner.

Page 16, Column 1

"It should be clear, from this, that the closer the structure of the virtual machine is to the target machine, the better the code generated will be. At least, "better" in the sense that the program's semantics will be preserved in the least space on the target. This is one reason that C will never be the language of choice on the Z-80, say; the contortions necessary to implement the full semantics of a C program on the Z-80 are extremely painful and SLOW. On the 68000, however, we have machine primitives that correspond quite closely with the C primitives, so it's no surprise that good 68000 code can be gotten from C.

"Notice how I keep harping on the FULL semantics of a program; this is really the crux of a lot of misconceptions. To use one instance, suppose that you want to compute 400! (factorial). In C, we may code this recursively, since C specifies that all functions are recursive (potentially). This potential recursion is part of the semantics of the program, since the meaning of "function" in C includes recursion. A compiler that ignored this would not be a valid compiler of the C language. An assembler programmer attempting to duplicate the full semantics would also have to implement the function in such a way as to allow recursion, or (put it another way) reentrancy. In short, I am saying that the assembler programmer who computes using non-reentrant techniques (which might well yield faster and/or shorter code), is not solving the same problem the compiler is!

"There are several other problems with various forms of "optimization" (a misnomer, actually) on micros, and on mainframes as well, and some of them are really thorny. First- and second-generation languages such as FORTRAN and COBOL can be handled on a more or less local basis, since neither permits recursion, local data areas, etc. A compiler for these languages is free to do a great many things. I once read (I forget the exact reference, if you wish, I will attempt to locate it) of a FORTRAN compiler, one of the early versions of IBM FORTRAN H (I think), that made some very astonishing manipulations of the input to get the output. There was a test subroutine that did nothing, but computed a lot, whose purpose was to exercise the compiler. I gather it was a VERY sizeable routine. The people were very surprised to find that the output object code was just a few bytes! BUG! they thought. Very careful analysis yielded the interesting dictum that the compiler was doing just what it had been designed to do. It seems the compiler had looked at the subroutine, invoked some global analysis algorithms, and discovered that the routine had no input, no output and no side effects; since the routine was not doing ANYTHING, the compiler THREW IT AWAY! Needless to say, this is not what was intended, since the compiler was not preserving the semantics of the program, in fact wasn't preserving the program at all!

Page 16, Column 2

"What you would like, I suspect, is a compiler that could detect when recursion (for example) is not necessary, and generate the more compact code that would result. If all routines called in the program actually reside in the same source file, this is indeed possible. If not, you have some problems. Suppose that function A calls routine B. B in turn calls library function L. Then no analysis of the source file containing A can assure that L is re-entrant or not, and hence the compilation of the program must proceed as if it is. The compiler can hardly read the programmer's mind.

"...Your point on the 3B2/200's floating point routines is well taken. I agree completely that the UNIX I/O garbage could hardly affect floating point. But remember that I had TWO possibilities for C inefficiency: bad libraries and bad algorithms... *SIGH*. Please note that I am just as disgusted at those timings as you are." Daniel L., Carmichael CA

ANY OTHER KIBITZERS ?

We seem to have some very useful inputs from various readers at hand (not all are reprinted here by any means). By combining all of these inputs, we are beginning to get a clearer idea of the REASONS for the observed fact that application programs and languages written in C have considerable HLL overhead, something which C enthusiasts would prefer that we not know about.

We would especially like to thank Otherwise Intelligent for taking the time to come by and give us a private lesson on compilers, optimization and like matters. Otherwise is an expert in these matters (he makes his living working with that stuff). A funny story: after several years of very successfully making a living at programming, Otherwise decided to return to college and pick up a Bachelor's in computer science. Fortunately, he told US about how the computer science profs were teaching compilers and programming, NOT the profs. Otherwise, we are certain that he would have been instantly kicked out of the school! You should hear Otherwise's opinions of UNIX-based YACC (Yet Another Compiler Compiler)!

Those of you who have been reading this rag for a few years will remember that Otherwise Intelligent is a guy who prefers the Nat Semi microprocessors over the 68000 series but is otherwise intelligent. His interest in the Nat Semi micros has recently been rekindled, so we are resurrecting his alias.

The subject of C's HLL overhead is not yet closed. Do YOU have anything to add to the issue? We don't know about YOU, but WE are learning quite a bit in the course of this discussion.

Page 17, Column 1

WE GET MAIL:

"Because you refuse to deal with me at all, Fargo John is getting a MUCH BETTER deal than me, no?" Allan A., Calgary AB CANADA

If we assume that our products are worthwhile, the answer to the above (regrettably) has to be yes. On the other hand, consider that Caspar Weinberger will not permit us to ship to any other country than Canada and that for a period of approximately 20 months we sold $0.00 to Canada. That puts certain constraints on what is practical from a business standpoint. If Digital Acoustics did not intend to be (NEED to be) a profitable business we could operate in a more friendly fashion. (Sometimes we feel like the Grinch that Stole Christmas!) - FNE

"...Yesterday I met a guy from the image processing lab at a certain large midwestern university (not U of MI). He told me they were building an image processing machine using a number of processors working in parallel. Although their pilot project has only 16 processors, the finished unit will have 1024. The processor being used? Why, the 68010 no less. Well, they called Motorola to see if they could get a few chips for nothing. Big M was receptive and asked, "How many do you need?" They said 16. BM said, "But how many altogether?" They said 2000 (seems they will use some to control the other functions of this beast). BM said, "Fine, we'll give you 2000." Not only did they send them the chips, but they also sent them the protoboards they plug into. Apparently the protoboards were already filled with the pin compatible 68000s. "What should we do with the 68000s?", they asked BM. "Oh, just throw them out", BM responded, casually. They're also going to use BM's floating point chip in this system. Are they getting 2000 of them for zip? Probably, but I don't remember the guy saying so.

"I'll end this now so you can go wash the green color out of your cheeks with your favorite brew." Tom F., Ann Arbor MI

#%*&@$!! - FNE

"Ref. pp 22-24, #40: Indeed the Mack documentation is so extensive (if measured by the pound). How it can be said to be easier to program than the DG board? Only if one means that there are more supplied subroutines. The information density, however, is not high. If those guys had written the 68000 User's Manual it would exceed the Brittanica. (By the way, I have both the Mainstay and Apple assemblers so 'tis not all ignorant ranting.) Maybe it is fair to say that by PASCAL standards the documentation is high density.

Page 17, Column 2

"What is this crap about writing code to use zero page only - I thought we were trying to get away from 64K address spaces. (Only partly in jest - surely as a temporary measure it makes sense (for HALGOL) but on a 68020 will it make sense?)" Eric E., Norman OK

Eric, anyone who has ever programmed the 6502 knows that its 256-byte zero page is an enormously beneficial resource - even though nobody tries to write code to fit INSIDE 256 bytes. Similarly, the 64K DG zero page (only 32K in inferior 68000 machines, meaning every commercial 68000 machine except DG's) is VERY beneficial even though we have no intention of writing programs to fit inside that space.

Among other things, HALGOL is intended to take maximum possible advantage of ALL of the 68000's resources - and that 64K zero page is an important resource! - FNE

"About operating systems:

"I disagree vehemently with what you say about operating systems. An operating system performs two closely related, but distinct, functions. One function is to give the programmer convenient access to the machine resources.

"The other, far more important function, is to give him device independent access to these resources, so that software from party A, a card from party B, a computer from party C, and some more software from D, E, and F will all work together even though A, B, C, D, E, and F were totally unaware of each other's existence and projects at the time that they produced their stuff. This is what CP/M sort of does, Commodore's stuff fails to do, and UNIX does very well within very narrow limits. (Meaning it does well in those areas where it does it at all.)

"You don't seem to be aware of this second function.

"One of the great things about the Mack is that it really does do this (apart from the horrible defect that it has no external bus). For example, most Mack software will use most graphics drivers successfully, even thought the guy writing the driver never saw the software and the guy who wrote the software never imagined the driver or the device being driven.

"About Mackintosh:

"The lack of software for the Mack is not due to the inherent limitations of the Mack, but due to the limitations that Apple imposed upon the Mack and continues to impose. They support software development on the Mack the way a rope supports a hanged man. They want to control software development and control the

Page 18, Column 1

software developed. That is why it is so hard to get hold of Mack assemblers and Mack documentation. They do not want 'unauthorized' people poking around inside, and they don't like 'unathorized' software being distributed. They are actively trying to prevent the distribution of assemblers and monitors.

"The Mack operating system, and the Mack design, is the cat's whiskers. It is great (except for the appalling 'finder' and the lack of a bus). Your criticisms of the OS are invalid. It is not overcomplex, just powerful and flexible (apart from the 'finder'). It is the hardware pricing and software control that chokes the Mack, (plus the fact that the mouse should have been a trackball and they need cursor keys).

"A trackball is cheaper, simpler, occupies almost no desk space, is much less likely to go wrong, and allows far more dynamic range (fast movement plus precise positioning), and it has the enormous advantage that you can use it without having to look down and take your hands away from the keyboard.

"Obviously, they felt that trackballs were too suggestive of video games, not business-like enough, not cute enough - wrong image. They want a tie and shiny shoes image and grey flannel software. The software drought is not because there is anything wrong with the Mack operating system, but because there is a shortage of gray flannel programmers who wear ties, shine their shoes every morning, and always use both sides of the toilet paper." James D., Dundas Australia

James what YOU seem to think is an operating system is what WE think is a BIOS (Basic I/O System). An operating system does not need ANY of that excess junk to run one computer which has one configuration. Only when you try to sell the operating system for many computers with many configurations do we need BIOS options. In the last issue, Daniel L. told us about what happens when an operating system tries to be all things to all computers - in other words, to be universally transportable - and that IS what you are driving at, is it not? - FNE

"Nick and I pay for our subscriptions with our own money.

'Regarding 'Defining Bit-Maps' and 'Observations in re Bit-Maps' (#40, pp14-15): I felt generally confused. I took the pages to one of the guys in the group who (had) built a graphics card. He had trouble understanding the paragraphs too. I decided the term 'bit-mapped' must imply a set of ways to display text and graphics. And that this set of ways includes the concept of 'raster ops.' But this set of ways is too

Page 18, Column 2

slow for displaying text, assuming cost cannot be infinite. The problem of displaying text on a bit-mapped display reminds me of the problem of accessing non-boundary-aligned operands in a CPU. The number of memory accesses goes way up and it takes more CPU time?" Brion S., Yorktown Heights NY

Sorry, Brion. As we pointed out once, 'bit-mapping' and 'raster ops' are not yet defined in a universally agreed-upon manner. However, the problem is indeed one which increases the number of memory accesses and one often encounters non-boundary-aligned operands. We personally do not like to 'define by example', but when Mack is printing text on the screen, what you are seeing is 'bit-mapping' (as opposed to character-mapping as in the usual personal computer such as the IBM PC - or our Eagle II - when using the ordinary text video card). And when a menu is 'dragged down' on the Mack CRT what you are seeing is 'raster ops'.

We can well understand that you and Nick have to use your own funds to subscribe to this rag. Why, we just read earlier this week that your mutual employer's profits are down 18% - FNE

"As I understand it, the 68000 only uses one out of four cycles, so a typical 8MHz system, using cheap RAM, can give one out of two cycles to video without the 68000 seeing anything wrong at all. Or should I be looking at Florida real estate?" Paul W., NY NY

Sorry, Paul, the 68000 uses all four of those cycles. Assuming the program running is in RAM, you cannot share video cycles at all without slowing down the 68000 approximately linearly. On the other hand, you have approached the correct party regarding Florida swamp real estate - we have some choice lots set aside especially for you. (By the way, the best information we have is that the custom graphics chips for the Amiga Lorraine have not yet been operationally displayed in public. We can well believe that the REMAINDER of the hardware, and software, works - FNE)

"Though I am never one to look a gift horse in the mouth, I am writing this letter about your recent gift (HALGOL v.03). I like it. It is limited in use in its present condition. WHY HAVEN'T YOU IMPLEMENTED A HCALL, HUSER, OR HSYSTEM? Robert L., York PA

Like we said, HALGOL v.03 is about 77% complete, implying that it is (let's see, borrow the four...) about 23% INCOMPLETE. It is our considered opinion that the functions you have named, along with DATA and READ, fall into the 23% of the functions which are least important. You are permitted to disagree, but unless you like to spend a great deal of your own time

Page 19, Column 1

programming you are not permitted to do anything about it except holler - which you just did. Surely you do not intend to follow the example of a subscriber from St. Louis who bitterly invoked CAVEAT EMPTOR over a product, in his case HALGOL v.02, for which he had paid $0.00? - FNE

"Hard disk backup? FNE has forgotten to mention the obvious backup, which is a second hard disk. For example, currently COMPUADD sells Microscience 20 meg hard disks for $849 with an external box and power supply for $200. The second drive is under $700 (prices fall daily). Now, for me, that appears to be the best and cheapest and safest backup that there is. Comments FNE?

"Has FNE counted the percentage of words DTG uses in denouncing UNIX? No other topic except 68000 assembly and HALGOL have occupied more space in the double columns than has UNIX. Methinks possibly FNE protests too much. On the other hand, not a word has appeared about CMS which agreeably is not for micro computers in general, is almost as hard to learn as UNIX, but has many of its features and a far better editor than UNIX ever dreamed about. And it does not support multi-tasking.

"A final parting comment. HALGOL does not yet support my printer interface. Now with lots of other toys like Desmet C on the PC or Megamax C on the Mack, I find myself somewhat less interested in spending the time to do my own interface (as FNE once suggested) than once was the case. I wonder how many others feel the same way?" Bob P., St. Louis MO

Bob, language designers provide multiple device drivers to support sales of their profit-making software packages, and of course the salaries of the multiple folk sitting around writing device drivers are paid out of those profits. HALGOL, up until now, has most definitely not shown a profit and there is $0.00 in the sugar bowl earmarked for supporting multiple device drivers. Instead, we are programming HALGOL to support the most common Apple II devices, which includes the simplest parallel printer interface. You could easily solve your problem with about $25 in green, which is less than you would pay for a commercial HALGOL software package if one existed. You will pardon us if we shed no tears over your pore liddle WRAGGLER interface. Uh, have you noticed that HALGOL is completely interactive while the languages you evidently prefer to spend your time with are compilers with fun fun fun compilation, linking debugging rewriting source recompiling relinking reloading no, that doesn't work right, rewriting source recompiling more debugging... You have peculiar ideas of fun, Bob!

Page 19, Column 2

Since this is sort of a "journal of simple systems" we think it is O.K. for us to provide some counterarguments to the massive onslaught of Toro Poo-Poo shoveled out by so-called "experts" asserting that UNIX is appropriate for the mass personal computer market. When those "experts" stop shoveling the Poo-Poo, we will write about other things than UNIX. We don't write about CMS because it is a mainframe operating system for the most part. Perhaps we should have a special St. Louis edition with all mentions of UNIX deleted and replaced by in-depth discussions of software piracy? We are sure that the dozen OTHER St. Louis-area DTACK subscribers would thank you for that!

Besides, we do NOT denounce UNIX, which is a fine operating system for some people and some applications. What we denounce is the stupidity of the "experts" who assert that UNIX is going to become the defacto-standard operating system for the new generation of personal microcomputers.

A second hard disk does not provide for multiple or remote backup copies. In case of fire or flood (ever notice how many computer labs are in the basement? Did you know that downtown Phoenix, AZ, which is located in the middle of the desert, floods badly at times?) the backup (make that the ONLY backup) will be destroyed along with the original. This might even happen in the event of an electrical storm. And then there is the occasional socially unintegrated miscreant who shops for computer systems featuring a four-finger discount. For some reason these miscreants cannot be depended upon to leave the second hard disk, the one with the backup software, behind... And the damaged file might have gotten damaged four backups ago and only now discovered. We prefer tape or removable disk, both of which allow for multiple backups - FNE

NEW 68000, 68020 ASSEMBLER:

"Enclosed please find (try out?) my new 680XX assembler. Would you print the first four paragraphs of the User's Manual as a product release in your esteemed journal? The price for the assembler is $95.

"Incidentally, I have used your HALGOL source code as test input for my assembler. The output generated in .PHASE0 mode was 'almost' byte for byte identical to the ASSEM68K output; all deviations could be tracked down to 'alternate op code' substitutions, which my assembler avoids if possible.

"Naturally, I couldn't test the 68020 op codes and address modes as there doesn't seem to be any 68020 board around (except for Motorola's $19,000 kit) - do YOU know by any chance a manufacturer of affordable 68020 boards?" Ulrich S., Aachen W. Germany

Page 20, Column 1

O.K., Ulrich, here are the four paragraphs:

"FEATURES AND REQUIREMENTS:

"Asm68020 is a macro assembler for the 68000, 68010 and 68020. It runs under the lnter68 P-code interpreter (v1.2 or later); its output can be linked to PASCAL and FORTRAN programs or can be used as stand-alone code. In the latter mode, PHASE ZERO compatible code is generated. All assembler programs meant to be linked to other programs must be position independent.

"Asm68020 is a one-pass assembler. Such assemblers are significantly faster than two-pass assemblers but pay for this advantage with a larger symbol table and a few restrictions in label usage. In a pure RAM disk environment, Asm68020 achieves throughputs of 3000 lines/min. The actual performance measured for a 15000 line program was 2600 lines/min.

"Asm68020 supports all op codes and address modes of the 68000 family with the exception of the 68020 coprocessor op codes as they are dependent on the hardware characteristics of each individual coprocessor. As soon as the 68881 Floating Point Coprocessor and the 68851 Paged Memory Management Unit are released, their respective instructions will be incorporated into Asm68020. Other features supported by Asm68020 are local labels and conditional assembly.

"To use Asm68020, you must have the Inter68 package v1.2 or later (older versions will not work). Familiarity with the 68000 assembly language is also required. If you plan to use the 68020 op codes/address modes then it is absolutely essential that you obtain Motorola's "MC68020 User's Manual", May 1984. This document describes in loving (if sometimes inconsistent) detail everything you might want to know about the hardware and software aspects of the 68020."

Ulrich Schmidt
An der Junkersmuhle 33/35
5100 Aachen
W. Germany

The review manual provided by Ulrich has 26 pages. It looks professionally prepared except for the absence of a padded cover (padded covers add $400 to the price tag, yes?). Syntax is defined, and the definitions are immediately followed by example(s).

For you newcomers, Ulrich's Inter68 is a 68000 adaption of Apple Pascal which runs on the DTACK boards. So you need to have - and be familiar with - Apple PASCAL to run Asm68020. And a DTACK Grande with lots of memory for that one-pass compiler, of course. Ulrich, if we have that wrong, please let us know? - FNE

Page 20, Column 2

ST: REQUIESCAT IN PACEM ?

This is being written on Apr 24. As recently as ten days ago, several persons were assuring us that the Jackintosh was REALLY gonna ship to retailers the end of this month. Well, that was NEVER gonna happen and by now you can confirm that. These incurable optimists have forgotten about Kindly Uncle Jack, it would seem.

KUJ is FAMOUS for announcing machines, even displaying prototypes, which never became real. And KUJ has a big, big problem now which he did NOT have back in the old days when he regularly announced machines which never saw the light of day: NO MONEY! Or, rather, not NEARLY enough money to put the ST into mass production. According to KUJ himself, he needs $150 million to finance MASS production of the ST and achieve the economies of scale to produce prices in the range Atari has been mentioning. What KUJ and Atari have available is closer to 150 cents than $150 million!

However, experienced KUJ-watchers have learned how to read the tea leaves. First, you scan the WSJ every day looking for the headlines which will appear if KUJ gets that $150 million or if he even TRIES to get it via some financial instrument such as a public stock offering, debenture or industrial bond. Nothing like that has happened.

What HAS happened is that KUJ has decided that Atari WILL NOT MAKE AN appearance at the summer Chicago CES (Consumer Electronics Show) - and Atari most certainly WOULD make an appearance if it had something - such as the ST - ready to move into commercial channels. Translation: the ST will NOT be ready to sell into retail channels this summer. And if it is not ready this summer then it will NEVER be ready... yes? Uh, maybe NNOOOO?

The Hanover Fair in W. Germany is just over and guess what? KUJ announced a workstation-level product based on the 32000 series microprocessors! Should we now shed a tear over the stillborn mass-market Atari ST? (A 23 column-inch story on Atari's withdrawal from the Chicago CES appeared in the Apr 18 issue of the WSJ. The WSJ is watching KUJ's progress VERY closely. And its reporters (editors?) appear to be somewhat skeptical about many of KUJ's claims.)

Nope! KUJ is taking the obvious course, considering the circumstances: if he cannot put the ST into MASS production, he CAN put it into mass production - and STILL undercut Apple's Mack, pricewise. But you should look for the Jackintosh later in the year, in smaller production quantities, and at significantly higher prices than the ones KUJ had previously bandied about. Dut those smaller production numbers are not going to please potential third-party software suppliers...

Page 21, Column 1

LAST MINUTE STUFF:

This rag has been reviewed recently in the WHOLE EARTH Review, from which we have received about 40 new subscribers so far, and by Micro Cornucopia, from which we have received 1 new subscriber so far. One of the reviews asserted that this rag is unintelligible and the other called FNE an old relic. To paraphrase the old saw, with reviewers like these we don't need any enemies!

(Truthfully, we do not understand the juxtaposition of healthful natural living and high technology in the WHOLE EARTH Review. Could somebody explain that combination to us? In an intelligible manner?)

We have just received the May issues of BYTE and MACKWORLD but have not had time to read through them in detail. However, it is evident that the Mack controversy - good or bad, pro or con - continues unabated in the letters columns of those magazines. Be sure to read Don Slaughter's letter on p.26 of the May BYTE.

Strong rumors are afloat that IBM's new PC II will finally be announced on Apr 30. If things proceed according to plan, this rag will be in the printers on that day. Maybe by our NEXT issue we will have the answer to the burning issue of the day: what CPU will the PC II sport?

Having stolen our Tandy 2000, our project engineer now wants us to buy him an IBM PC. No, he has not gone 8088 happy, It's just that one of our subscribers makes a PROM/PAL programmer which needs an MS-DOS-based communications program to download some data to program PALs. And they have such a program for IBM PCs but have not been able to make it work on the Tandy 2000. Ah, the joys of being incompatible with IBM! (With the PC II not quite released, and the consequent severe price cuts on the PC not yet announced, this has to be a world-class bad time to buy a PC!)

So NOW our project engineer naturally wants to move the Tandy 2000 back onto our desk to make room for the IBM PC on HIS desk. No way! The so-and-so has already learned to use MultiMate and 1-2-3 on the Tandy - both work really well - and we can NEVER keep our desk-midden in order if our project engineer is rummaging things around (to make room for the keyboard) every time our back is turned.

THOSE PC/AT DISK PROBLEMS:

Many of you know that there are about 20 or 30 rumors floating around explaining why the AT hard disks are so unreliable, as well as a few more IBM-sponsored rumors asserting that all is well with the AT hard disks.

Page 21, Column 2

We think there is more than one problem. In fact, we see THREE problems. One is that cheap hard disks are often sensitive to mechanical shock and stress after being formatted. What kind of shock and stress? The kind you get when you pick the AT up to move it across the desk or such. This torques the hard disk, and when you set the AT back down the head alignment doesn't match the formatted tracks anymore.

This one is actually pretty obvious. And the torquing might be done at night by the maid conscientiously lifting one corner of the AT high in the air to dust thoroughly under the unit, hmmm? When the XT came out a few years back it had this problem too, but folks forget.

Problem number two is DOS 3.0, which is highly reliable except when it has to work with faster hard disks than the really slow units used in the XT. And the PC/AT has much faster hard disks than the XT. DOS 3.1 is supposed to fix this problem. We forget whether we read about this in PC WEEK or InfoWorld, but it makes sense and explains why folks have been pointing fingers at DOS 3.0 for some time now, but without being specific.

Problem number three is that there is a logic error in one of the Western Digital chips used in IBM's hard disk controller card. Control Data Corp. found out about this logic error some time back, so when you upgrade a floppy-disk AT using a CDC drive you get a replacement chip which has the error fixed. CDC has been very quiet about this fix, but EN blew the story a couple of weeks ago, which is where we learned about it.

So wait for DOS 3.1, buy a floppy-based AT and upgrade it with a CDC disk, and make damn sure nobody jerks the AT around on your desk (such as the maid lifting the chassis by one corner to dust under it at night), and you have a perfectly good AT. As soon as you buy a streaming tape to back the hard disk up, that is.

THEM NO-BACKUP BLUES:

Pete S. tells us about a colleague at his workplace in a large West Coast aerospace firm's research labs who recently purchased an AT and feverishly recorded data on the big hard disk for a period of six weeks, at which time the hard disk went BLOOEY! Bye, bye, six weeks of data. IBM offered sympathy and a new replacement hard disk.

It is hard to believe, but it continues to be a fact that 90% of the folks who own IBM personal computers with hard disks DO NOT BACK UP THEIR HARD DISKS! Not EVER! Incredible!

Page 22, Column 1

HALGOL REPORT #1:

There is much to report this time around. First, we now have a version of HALGOL v.03 which fully supports the Nat Semi math chip. This is courtesy of Ulrich Schmidt, with some (ahem!) encouragement from Digital Acoustics. By 'fully supports' we mean that the transcendentals are written in straight-line code similar to that which we published as REDLANDS in issue #26, for instance.

Issue #26 also carried, on p.5, a number of timings of the Terry Peterson benchmark, which is an improved version of the benchmark which has been featured in Dr. Dobbs. This benchmark runs in about 586 seconds on Mack using the first release of Microsoft's Mack BASIC (double precision), in 488 seconds on the Apple II running Applesoft, and in 16.8 seconds on a DTACK Grande running standard HALGOL. Well, the 32081-supported HALGOL runs that benchmark in just under 3.7 seconds, with an error of 1.28E-13.

In issue #26, on p.5, we had predicted 4.0 seconds with an error of 1.3E-13. Not bad, huh?

Unless we are seriously mistaken, HALGOL and Ulrich Schmidt's Inter68 version of Apple PASCAL are the only languages available anywhere which fully support the Nat Semi 32081 math chip. Some larger companies do have some software which performs the transcendental functions by a series of subroutine calls to the basic 4-banger functions (+,-,*,/) but that is a whole bunch slower than doing the job right. Thanks, Ulrlch!

Two days after receiving the disk, we sent copies to the folks who had purchased either of the two experimental math boards - the discontinued one-holer or the current three-holer. It turned out that we had sold 42 of those boards, beginning Nov. '83, to 31 different customers. That's a lot of (experimental) boards to sell with very little software support!

It will be interesting to see if we sell a few more three-holers now. (The new math-chip version of HALGOL only supports one of those three holes in the three-holer, but does not INTERFERE with the other two holes, in case you were planning to write some custom software.)

HALGOL REPORT #2:

We are making substantial progress fleshing out HALGOL. Since shipping v.03, we have added integer FOR-NEXT loops, integer comparisons (IF-THEN), alpha (string) comparisons (more on this in REDLANDS), programmable SELECT PRINT, and a (string) EDIT function that we thought was utterly unique until somebody told us that one of the new Mack BASICs had it too... sigh.

Page 22, Column 2

You see, any time you have something like a mail list program you need the ability to edit a string. This means you print the string on the CRT and then use insert, delete, overwrite, or left and right arrows without changing anything. Use RETURN (CR/LF) to exit EDIT. What you wind up with is about 20 lines of convoluted BASIC which might or might not work. So we just made it a HALGOL function, whose syntax is:

     100 EDIT A$

or

     200 EDIT B$(K%,5)

Anyhow, with integer FOR-NEXT and integer comparisons working we implemented the Jan '83 BYTE Sieve of Erastothenes benchmark. It ran more slowly than we had expected at 29 seconds, so we investigated and found there was about 20% overhead (!) just involving checking CTL-C on every HALGOL statement. So we did something tricky involving the refresh Interrupt and dropped the time down to 24.4 seconds! (This only works on a Grande, of course.)

That 24.4 seconds makes HALGOL BY FAR the fastest interactive high-level computer language around! (FORTH is a macro assembler, not a HLL. Very few persons can program in FORTH. NOBODY can read a FORTH program who did not write that program.)

For instance, Jan '83 BYTE reports that the Apple II runs the Sieve in 2806 seconds (Applesoft) or 1850 seconds (Integer BASIC). The Z-80, running MBASIC, clocks in at either 1476 or 1920 seconds, depending on the version. The IBM PC runs from 1950 to 2400 seconds, depending on whether Integer BASIC or BASICA is used. Although BYTE listed a number of benchmarks for the 68000, NONE of them were for an interactive language.

Please note that we do not claim that HALGOL is the FASTEST language around, just the fastest FULLY INTERACTIVE language around in the microcomputer world, as measured by that BYTE Sieve benchmark. We also claim that HALGOL is the fastest FULLY INTERACTIVE language around in the microcomputer world when running the Dobbs/Peterson benchmark, either in the "math chip division" (<3.7sec) or the "sans math chip division" (<16.8 sec). You are cordially invited to try to disprove this. Good luck!

We do NOT claim that HALGOL is as fast as compiled languages such as FORTRAN, MODULA, or C. If you have to go through that source/compile/link/load nonsense, you really SHOULD wind up with a faster program, else why put up with all that nonsense? (In a future issue, we will discuss some of the inherent differences

Page 23, Column 1

between compiled and globally optimized languages and incrementally compiled languages, which cannot be globally optimized.)

We believe that we are in the final stages of achieving our original objective, which was to produce a very fast fully interactive BASIC-like language which fully utilizes the resources of the 68000 and does not put up with any Toro Poo-Poo HLL overhead. "OUR", in this case, means Digital Acoustics and all of the folks who have contributed to developing HALGOL. In addition to your FNE, that notably includes Reginald Boyd and, lately, Ulrich Schmidt. HALGOL has not been a one-man show and we do not wish to grab all the credit, or to APPEAR to try to grab all the credit (there is a fine distinction there).

A PEEK AHEAD:

James S. has just received prototype boards for what is hoped to be our next experimental board, or QD-3W. This one has a Western Digital floppy disk controller chip and ancillary circuitry to work with the new 1.28 Mb (formatted) floppy disks. And we have begun laying black tape on clear acetate for our next generation graphics boards, based on the Hitachi chip, which we WILL support with software.

PERMISSION IS HEREBY granted to anyone whomever to make unlimited copies of any part or whole of this newsletter provided a copy of THIS page, with its accompanying subscription information, is included.

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; II, II+, IIe, soft: ProDOS, Mackintosh?: Apple Computer Co. Anybody else need a 199th million ack, have your legal beagles send us the usual threat.

SUBSCRIPTIONS: Subscriptions are $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. All back issues are kept in print; write for details. The address is:

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

REDLANDS:

REDLANDS returns this issue with the run-time code to perform alpha (string) comparisons. Uh, just HOW do we compare strings? Unlike numeric arguments, two strings being compared can have different lengths, for instance. Well, we have made no secret that HALGOL strings work in the same manner as those in Wang's 2200 BASIC. So we went to the source:

Page 23, Column 2

The following paragraph is a quotation from page 185 of Wang Laboratories' BASIC-2 Language Reference Manual:

"Comparison of two alphanumeric operands proceeds character-by-character, from left to right. The comparison of any two characters is based upon the respective values of their hexadecimal codes. (For example, the hex code for an "A" is 41 and the hex code for a "B" is 42. Thus, the relation "A"<"B" is true, while "A">"B" is false.) This character-by-character comparison continues until unequal characters are found. The first pair of unequal characters determines the relationship between the two values. If no unequal characters are found, the two values are equal. In general, trailing spaces in an alpha-variable are not included in the comparison. Thus, "YES"="YES " is true. However, if two character strings of unequal length are compared, the shorter string is automatically extended to the length of the longer string with one or more space characters (HEX(20)), and these characters are then used in the comparison. For example, if "ABCD" is compared to "ABC", the shorter string is padded with a space character, yielding "ABC ". The first pair of unequal characters in this case are "D" and "space". The relation "ABCD">"ABC " is true since the hex code for "D" (HEX(44)) is greater than that of the space character (HEX(20))."

NOW do you see why we like Wang's 2200 BASIC? Why, even WE can understand the definition of string comparisons listed above! Now, about our implementation of that definition in 68000 assembly:

Lines 5-7 define the eight possible forms of the string relational statement. Note that (elements of) string arrays can be used on both sides of the relation. Lines 9, 14, 20, 26, 32, 37, 51 and 66 give examples of the eight possible syntax forms.

Subroutine LOADSTR loads the length of a string into register D0 and a pointer to the start of the string into A0. Subroutine LOADSTRA performs the identical function for an element of a string array. The eight action addresses call a minor variant of these subroutines which first skip a link which is ignored at run time but required when listing the relation (is there an 'ELSE' clause or not?). The variants are named LDSTRK and LDSTRAK; see lines 60, 61.

Since a string literal (e.g. "ABC") and a hex string (e.g. HEX(A1A2A3)) are stored in the HALGOL program in exactly the same form, the run time action code is also identical (although the action ADDRESSES are different). Note that action address AIF0, line 12, simply jumps to action address AIF1 at line 17. However, separate list links at lines 11 and 16 assure that the literal or hex string is listed correctly.

Page 24

                         2          LIST 
                         3 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC 
                         4 ; 
                         5 ; IF (STR ARG1) (RELATION) (STR ARG 2) THEN... 
                         6 ; STRING ARG1 CAN BE A STR VARN OR A STR ARRAY 
                         7 ; STR ARG2 = LITERAL, HEX(), STR VARN, OR STR ARRAY 
                         8 ; 
                         9 ; SYNTAX:  IF A$="ABCD" THEN... 
                        10 ; 
 004076: 4A60           11          DC.W    LAIF0 
 004078: 6002           12 AIF0     BRA     AIF1           ;LIT SAME AS HEX 
                        13 ; 
                        14 ; SYNTAX:  IF A$=HEX(0A0A0A) THEN... 
                        15 ; 
 00407A: 4A64           16          DC.W    LAIF1 
 00407C: 4EB83D52       17 AIF1     JSR     LOADSTRK       ;DO COUNT, A0 PTR 
 004080: 6018           18          BRA     AIF5A          ;CONTINUE 
                        19 ; 
                        20 ; SYNTAX:  IF A$=B$ THEN... 
                        21 ; 
 004082: 4A68           22          DC.W    LAIF2 
 004084: 4EB83D52       23 AIF2     JSR     LOADSTRK       ;DO COUNT, A0 PTR 
 004088: 6028           24          BRA     AIF6A          ;CONTINUE 
                        25 ; 
                        26 ; SYNTAX:  IF A$=B$(I%,3) THEN... 
                        27 ; 
 00408A: 4A6C           28          DC.W    LAIF3 
 00408C: 4EB83D52       29 AIF3     JSR     LOADSTRK       ;DO COUNT, A0 PTR 
 004090: 6034           30          BRA     AIF7A          ;CONTINUE 
                        31 ; 
                        32 ; SYNTAX:  IF A$(5,K%)="ABCD" THEN... 
                        33 ; 
 004092: 4A70           34          DC.W    LAIF4 
 004094: 6002           35 AIF4     BRA     AIF5           ;LIT SAME AS HEX 
                        36 ; 
                        37 ; SYNTAX:  IF A(5,K%)$=HEX(0A0A0A) THEN... 
                        38 ; 
 004096: 4A74           39          DC.W    LAIF5 
 004098: 6122           40 AIF5     BSR     LDSTRAK        ;DO COUNT, A0 PTR 
 00409A: 3200           41 AIF5A    MOVE.W  D0,D1          ;ARG1 COUNT 
 00409C: 2A08           42          MOVE.L  A0,D5          ;ARG1 PTR 
 00409E: 7E01           43          MOVEQ   #1,D7          ;RDY EVEN ADR 
 0040A0: 101E           44          MOVE.B  (A6)+,D0       ;ARG2 COUNT 
 0040A2: 204E           45          MOVE.L  A6,A0          ;ARG2 PTR 
 0040A4: DE40           46          ADD.W   D0,D7          ;-- EVEN ADRRESS 
 0040A6: 08C70000       47          BSET    #0,D7          ;   CALCULATION -- 
 0040AA: DDC7           48          ADD.L   D7,A6          ;CORRECT PROG PTR 
 0040AC: 6022           49          BRA     AIF7C          ;CONTINUE 
                        50 ; 
                        51 ; SYNTAX:  IF A$(5,K%)=B$ THEN... 
                        52 ; 
 0040AE: 4A78           53          DC.W    LAIF6 
 0040B0: 610A           54 AIF6     BSR     LDSTRAK        ;DO COUNT, A0 PTR 
 0040B2: 3F00           55 AIF6A    MOVE.W  D0,-(A7)       ;SAVE ARG1 COUNT 
 0040B4: 2F08           56          MOVE.L  A0,-(A7)       ;SAVE ARG1 PTR 
 0040B6: 4EB83D54       57          JSR     LOADSTR        ;ARG2 COUNT, PTR 
 0040BA: 6010           58          BRA     AIF7B          ;CONTINUE 
                        59 ; 
 0040BC: 548E           60 LDSTRAK  ADDQ.L  #2,A6          ;SKIP THE LINK 
 0040BE: 4EF87F24       61 LDSTRA   JMP     LOADSTRA       ;GET COUNT, PTR 
                        62 ;

Page 25

                        64 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC 
                        65 ; 
                        66 ; SYNTAX:  IF A$(5,K%)=B$(I%,3) THEN... 
                        67 ; 
 0040C2: 4A7C           68          DC.W    LAIF7 
 0040C4: 61F6           69 AIF7     BSR     LDSTRAK        ;DO COUNT, A0 PTR 
 0040C6: 3F00           70 AIF7A    MOVE.W  D0,-(A7)       ;SAVE COUNT 
 0040C8: 2F08           71          MOVE.L  A0,-(A7)       ;SAVE AUG1 PTR 
 0040CA: 61F2           72          BSR     LDSTRA         ;ARG2 COUNT, PTR 
                        73 ; 
 0040CC: 2A5F           74 AIF7B    MOVE.L  (A7)+,A5       ;ARG1 PTR 
 0040CE: 321F           75          MOVE.W  (A7)+,D1       ;ARG1 COUNT 
                        76 ; 
                        77 ; MOVE THE SMALLER OF D0 AND D1 TO D2 
                        78 ; 
 0040D0: 3401           79 AIF7C    MOVE.W  D1,D2          ;ASSUME D1 SMALLER 
 0040D2: B400           80          CMP.B   D0,D2          ;BUT IS IT 
 0040D4: 6302           81          BLS     AIF7D          ;IF IT IS 
                        82 ; 
 0040D6: 3400           83          MOVE.W  D0,D2          ;NO, D0 IS SMALLER 
 0040D8: 1602           84 AIF7D    MOVE.B  D2,D3          ;DUPLICATE COUNT 
                        85 ; 
                        86 ; COMPARE TWO ALPHA STRINGS (ARG1, ARG2) 
                        87 ; 
                        88 ; RESULT: D7 =   0 IF ARGS ARE EQUAL 
                        89 ;         D7 =   1 IF ARG1 > ARG2 
                        90 ;         D7 = 255 IF ARG2 > ARG1 
                        91 ; 
                        92 ; A5 = POINTER TO STRING ARGUMENT 1 
                        93 ; A0 = POINTER TO STRING ARGUMENT 2 
                        94 ; 
                        95 ; D1 = ARGUMENT 1 BYTE (CHAR) COUNT 
                        96 ; D0 = ARGUMENT 2 BYTE (CVHAR) COUNT 
                        97 ; D2 = LESSER OF D1, D0 
                        98 ; 
 0040DA: 7E00           99          MOVEQ   #0,D7          ;IN CASE ARGS EQUAL 
 0040DC: 31C71542      100          MOVE.W  D7,COND        ;IN CASE REL FALSE 
 0040E0: B10D          101 ACOMP    CMPM.B  (A5)+,(A0)+    ;COMPARE CHARS 
 0040E2: 6624          102          BNE     ANOTEQ         ;IF NOT EQUAL 
                       103 ; 
 0040E4: 5303          104          SUBQ.B  #1,D3          ;DECR STR COUNT 
 0040E6: 66F8          105          BNE     ACOMP          ;LOOP 'TIL ZERO 
                       106 ; 
                       107 ; SHORTER STRING - LONGER STRING (SO FAR) 
                       108 ; 
 0040E8: 9202          109          SUB.B   D2,D1          ;MORE ARG1 STR ? 
 0040EA: 6610          110          BNE     MARG1          ;IF SO 
                       111 ; 
 0040EC: 9002          112          SUB.B   D2,D0          ;MORE ARG2 STR ? 
 0040EE: 670A          113          BEQ     AEQ            ;IF NOT 
                       114 ; 
                       115 ; LET A SPACE CHAR REPRESENT AN EXTENDED ARG1 
                       116 ; 
 0040F0: 0C1800A0      117 MARG2    CMPI.B  #$A0,(A0)+     ;ARG2 = SPACE ? 
 0040F4: 6612          118          BNE     ANOTEQ         ;IF NOT 
                       119 ; 
 0040F6: 5300          120          SUBQ.B  #1,D0          ;DECR ARG2 COUNT 
 0040F8: 66F6          121          BNE     MARG2          ;LOOP 'TIL ZERO 
                       122 ; 
 0040FA: 4ED4          123 AEQ      JMP     (A4)           ;STRINGS ARE EQUAL 
                       124 ;

Page 26

                       126 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC 
                       127 ; 
                       128 ; LET A SPACE CHAR REPRESENT AN EXTENDED ARG2 
                       129 ; 
 0040FC: 7CA0          130 MARG1    MOVEQ   #$A0,D6        ;D6 = SPACE CHAR 
 0040FE: BC1D          131 MARG1A   CMP.B   (A5)+,D6       ;ARG1 = SPACE ? 
 004100: 6606          132          BNE     ANOTEQ         ;IF NOT 
                       133 ; 
 004102: 5301          134          SUBQ.B  #1,D1          ;DECR ARG1 COUNT 
 004104: 66F8          135          BNE     MARG1A         ;LOOP 'TIL ZERO 
                       136 ; 
 004106: 4ED4          137          JMP     (A4)           ;STRINGS ARE EQUAL 
                       138 ; 
 004108: 6204          139 ANOTEQ   BHI     ARG2L          ;IF ARG2 LESS 
                       140 ; 
 00410A: 5407          141          ADDQ.B  #2,D7          ;ARG1 > ARG2 
 00410C: 4ED4          142          JMP     (A4)           ;EXECUTE RELATION 
                       143 ; 
 00410E: 5307          144 ARG2L    SUBQ.B  #1,D7          ;ARG1 < ARG2 
 004110: 4ED4          145          JMP     (A4)           ;EXECUTE RELATION 
                       146 ; 
                       147 ; STR ARG1 = STR ARG2 ? 
 004112: 0000          148          DC.W    0 
 004114: 4A07          149 AREL0    TST.B   D7 
 004116: 672C          150          BEQ     ATRUE 
 004118: 662E          151          BNE     AFALSE 
                       152 ; 
                       153 ; STR ARG1 <> STR ARG2? 
 00411A: 0001          154          DC.W    1 
 00411C: 4A07          155 AREL1    TST.B   D7 
 00411E: 6624          156          BNE     ATRUE 
 004120: 6726          157          BEQ     AFALSE 
                       158 ; 
                       159 ; STR ARG1 > STR ARG2 ? 
 004122: 0002          160          DC.W    2 
 004124: 4A07          161 AREL2    TST.B   D7 
 004126: 6720          162          BEQ     AFALSE 
 004128: 6A1A          163          BPL     ATRUE 
 00412A: 6B1C          164          BMI     AFALSE 
                       165 ; 
                       166 ; STR ARG1 >= STR ARG2 ? 
 00412C: 0003          167          DC.W    3 
 00412E: 4A07          168 AREL3    TST.B   D7 
 004130: 6A12          169          BPL     ATRUE 
 004132: 6B14          170          BMI     AFALSE 
                       171 ; 
                       172 ; STR ARG1 < STR ARG2 ? 
 004134: 0004          173          DC.W    4 
 004136: 4A07          174 AREL4    TST.B   D7 
 004138: 6B0A          175          BMI     ATRUE 
 00413A: 6A0C          176          BPL     AFALSE 
                       177 ; 
                       178 ; STR ARG1 <= STR ARG2 ? 
 00413C: 0005          179          DC.W    5 
 00413E: 4A07          180 AREL5    TST.B   D7 
 004140: 6702          181          BEQ     ATRUE 
 004142: 6A04          182          BPL     AFALSE 
                       183 ; 
 004144: 31CC1542      184 ATRUE    MOVE.W  A4,COND        ;CONDITION TRUE 
 004148: 4ED4          185 AFALSE   JMP     (A4)           ;EXECUTE 'THEN' 
                       186 ;

Page 27

                   3 May '85 

YE DTACK GROUNDED PRICE LIST 
---------------------------- 

DTACK Grande: 12.5MHz 68000: 
(for Apple II, 1 wait state) 

less aux. bd:  with aux. bd: 

128K   $650      640K   $925 
256K   $690      768K   $965 
384K   $730      896K  $1005 
512K   $770     1024K  $1045 
                  : 
                  : that's a megabyte, folks! 

Accessories included: 

   HALGOL release 3.0 disk, unlocked, plus 28-page manual 
   3 additional unlocked disks demo & utility software 
   hard copy of monitor routines source code 
   hard copy of floating point source code 
   interface cable & Apple II, IIe interface adapter bd 

Accessories required but not included:  case & power supply 

Dimensions:  15 inches by 6 1/2 inches 
Power required:  +5 volts regulated at 3 Amps (max) 
                       (1.8A/128K & 2.2A/1024K typ) 

Grande AUXILIARY MEMORY BOARD 
(When purchased separately: 
    128K  $255    384K  $335 
    256K  $295    512K  $375 

'POTBOILER' COLOR GRAPHICS BOARD 
(INCLUDES 512K Grande 68000 board) 

    $1455 with Grande documentation 
    $1435 without documentation 

640 H X 400 V pixel resolution, 8 colors, 22.4MHz pixel rate 
60Hz refresh rate, absolutely NOT interlaced! 
Drives Tandy 2000 color monitor or its Mitsubishi equivalent 
Self-contained 128K byte refresh RAM 

Accessories included: 

   interface cables to DTACK board 
   1 unlocked disk with test & demo programs 

Accessories required but not included: 

   Graphics support software 
   Tandy 2000 (or Mitsubishi) color monitor and video cable 
   case & power supply 

Dimensions:  15.75 inches by 6 1/2 inches 
Power required:  +5 volts requlated at 3 Amps (max)

Page 28

(Our VDHR (very-damn-hi-res) graphics systems are now in 
production.  The graphics controller uses a 5MHz NEC 7220; -2 
indicates two bit planes and -3 three bit planes.  These systems 
include a 512K DTACK Grande 68000 board and are sold without the 
Grande documentation and without graphics software support. 
WARNING:  these boards are NOT suitable for private party hacker 
use!  See newsletter #29.) 

  VDHR-2, $2390:  VDHR-3, $2855 

EXPERIMENTAL 32081 MATH CHIP BD: 
 (SOLD LESS THE 32081 MATH CHIP(S)) 
 Compatible with both static and dynamic RAM DTACK boards 

   3-holer  $135 

Accessories included: 

   1 unlocked HALGOL release 3.0/32081 disk with 28 page manual 
   1 unlocked disk with logarithm routine source & object code 
   complete schematic and interface cables to DTACK 68000 bd 

Accessories required but not included: 

   Nat Semi 32081 floating point math chip(s) 
   DTACK 68000 board (static or dynamic) and power supply 

 
Stuffer BLOCK DMA INTERFACE 
(for Apple II, II+, IIe):  $130 
  (WORKS WITH Grande or GROUNDED) 

Accessories included: 

   complete schematic and 1 unlocked disk with demo prog & source 

 
GENUINE STAINLESS STEEL DTACK CASE 
    Designed to contain a DTACK 68000 bd and three accessory boards 

   bare case:  $60   complete:  $195 

The complete case includes a 5V 10A power supply, line filter, and 
power cord;  wired and tested. 

Accessories required and/or included:  none 

SCHEMATICS: 

   Apple/static DTACK interface schematic      $5 
   Pet/CBM/static DTACK interface schematic    $5 

(Like HP, DEC and Wang we consider our CPU circuitry proprietary) 

All prices are in U.S. funds. 
6% California sales tax must be included when applicable.  We pay 
for (UPS) shipment if paid fully in advance;  else send us 10% down 
and we will ship UPS with the balance, plus shipping and COD 
charges, to be paid COD.