Issue # 29 DTACK GROUNDED Newsletter - March 1984

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

DON'T BUY THIS SYSTEM!

Below you can see a full-gallon Grande along with a math board - that's the tiny board under the 68000 - and a VDHR-2 graphics subsystem. VDHR stands for Very Damn High Resolution, and -2 means two bit planes are used. We will sell the system illustrated (not including the 16081 math chip) for about $3820 to anyone who absolutely demands to buy it. We will also do our very best to talk you out of buying it!

The simple fact is that no private individuals and only a few companies have any business even THINKING about buying a VDHR-2 graphics subsystem. So don't.

To use the VDHR-2, you will need a mechanical engineer to design an enclosure for the 20 inch monitor (the one made by Video Monitors Inc of Eu Claire, WI) and the board set pictured below. Video Monitors does not provide cases for their monitors for the very good reason that the case would always have to include some electronics such as the boards below, and everyone's

Page 1, Column 2

electronics - and power supply - is different. You will have to learn to make the case into a good RFI shield because the pixel rate of the VDHR-X is 67.888MHz, which happens to be higher than the carrier frequency for TV's channel 4! And you will have to learn to shield your power supply from the CRT because magnetic interference from the power supply can wreck the high quality image that the Video Monitors' unit can provide. These latter considerations indicate that you will need an electrical engineer as well.

You will need a production department to assemble this mess, a technician to check it out, and at least two programmers. Assembly language programmers. Why? We don't provide software support for the VDHR-2 (if we did, we could not sell it for the price we do). And you will also need to program your very own application, hmmm? AT LEAST two assembly language programmers. If you understand company budgets and the 100% overhead which most electronics firms have, you will realize that you will have to commit $250,000 before you can rationally BEGIN to think about buying a VDHR board set.

(And some folks have accused us of overselling our product! Tsk.)

THIS MONTH'S BORING STUFF:

Jobs jobbed, p4. Commodore woes, P25b. 80186 shortage p2b. Inmos transputer, p8. British praised, p6. Bye, bye LISA p3. Idiot systems jerks p20b. 68000 chronology, p9b. High performance micros, p10. F.P. math chips, p12b. Mail call, p15. Unbusted 68000 BASIC, p26b. HALGOL: 'LET' operator, p5; conditionals, p13b; 'LET' program structure, p17; 'FOR-NEXT', p21; standards, p24. REDLANDS, page 29 (Honest!)

BEHEMOTH 68000 BOARDS THAT WON'T FIT INSIDE YOUR APPLE!

Page 2, Column 1

IT'S O.K. TO DROOL!

So why would anyone even THINK about spending upwards of $4000 on something that will cost an additional quarter million dollars, minimum? Because that Video Monitors crt just happens to be the very same monitor found in the Cal Comp IGS-500, that's why. And because the 68000 and the 7220, even without the math chip, can out-perform the Cal Coup system when it comes to updates. By now you have probably figured out that somebody HAS invested a quarter of a million dollars (or more) to develop a product around our boards.

The other day we had an opportunity to get an expert opinion on the performance of our board set, as incorporated into a CAD system. The expert informed us that the system had a response time on redraw equal or superior to systems which sell in the range of $250,000! The CAD system that uses our boards is being marketed for less than $30,000 less plotter. (One plotter can service several CAD stations.) Just shows that if you bet on the right chips (12.5MHz 68000, 5MHz 7220) then you can do well. Oh, yes: the expert also thought the CAD system in question had correctly designed software, something that is largely independent of the electronics used.

(The same expert had less kind things to say about their marketing. For instance, to see one of their ads you will have to locate a copy of the Northeastern Oklahoma Poultry-Raiser's Gazette. They don't seem to think electronics types use CAD systems.)

POOR (SOB!) FNE! (SNIFF!)

You wish you had a system like the one on the cover? YOUR FNE HAS ONE! We walk right past it several times a day! You have maybe heard of heat sinks? That VDHR board set and 20 inch monitor constitute an infinite TIME SINK. So far, we have resisted the obvious temptation. You are still receiving this newsletter, no? And we are still writing about advances in our interpretive compiler, yes?

(Why do we get the impression that not many of you are sorry for us?)

SO WHAT ELSE IS NEW?

We left work today at about 5:15 PM, having integrated the first half of the LET function into HALGOL and having done the final editing of newsletter #28. After having dinner, we put a new ribbon in our EPSON FX-80 and proceeded to print out two copies of the newsletter. This takes about two hours, with disk commands needed every ten minutes. (Our Eagle word-processor can hold four compressed pages of print comfortably but not five.)

Page 2, Column 2

A good activity that's compatible with being interrupted every ten minutes is reading the latest issues of Electronic Engineering Times and Infoworld, both of which arrived in the noon mail. We read with interest Stan Baker's story on the Western Design Center, which asserts that the president of WDC designed the 6502 at Mos Tech in 1975. Uh huh.

Then we read in Infoworld (six weeks ago as you are reading this) the article entitled "New 80186-based micros outpace the IBM PC." This is on pp 59-60 of Infoworld, Vol 6 #5. The title tells it all. On page 82 of the same issue is an interview with Andrew Grove, President and CEO of Intel. Infoworld asks, "How bad is the shortage of 80186 chips right now?"

GROVE: "The shortage is very acute now. The shortage problem will sort of work itself out gradually over the next several quarters. But we have been REALLY STUNNED [emphasis added] by the demand for the product... We really were caught by [the demand]... this ramp is very steep, much steeper than anything we've ever done on the 8086 or 8088."

Naturally everyone would be surprised. There is no way that anyone could have foreseen the explosion of demand for the 8018X micro; in fact, any sensible prognosticator would have predicted intense popularity for the 8088: it is the IBM-compatible de facto standard, no? (Is there anybody out there, anybody at all, who has not read pages 2 thru 6 of our newsletter #21, dated July 1983 and written in early June?)

REAL BAD NEWS DEPT:

Did you know all the hackers are dead? It must be true; we read it some place or another recently. THEREFORE: you will kindly stop fogging the mirror and report to your nearest funeral home for terminal processing - NO! NO! NOT CRT terminal processing...

ANOTHER SCULLY MAN:

The following is reprinted verbatum from EN:

"Veteran Apple Computer Corp. sales vice-president Gene P. Carter left on an indeterminate sabbatical last week and was immediately replaced by former Kodak consumer marketing executive William Campbell, who was brought into the company last year by president John Scully."

You can't have a palace revolution if all the princelings are loyal to the king.

INFOWORLD WATCH:

We can add a tad to John Dvorak's column of Vol 6 #6: A reliable source informs us that the reason Intel is

Page 3, Column 1

having so much trouble with the 80186 mask is that all of the original design team quit, and nobody is left who knows anything about the chip! The fact that Intel pulled back the president of its French subsidiary is a tip-off to the magnitude of the problem. You see, the French don't like Americans at best and the politics of an American-owned French company are very touchy. Yanking the president of that French subsidiary surely did not win Intel any Gallic brownie points...

As to Intel conning IBM out of some cash, Intel desperately NEEDED some cash. It seems the $150-$200 million they blew on the iAPX 432 was their own money, not the Pentagon's. The biggest reason the original 80186 design team quit was that every Intel employee was forced to accept a 10% pay cut and pay freeze back before IBM brought its checkbook to the rescue. For a technical type who had a pay review scheduled for a few days after the cut and freeze, that amounts to a 20% (!) involuntary pay cut. A company can lose employees that way...

LISA: REQUIESCAT IN PACE

The original LISA is now officially dead. Its supporters still insist that the fact that it made an ox cart look like an Indy 500 speedster is unrelated to its demise. Hasn't anybody figured out that the business market, which is where LISA was exclusively targeted, is a TIME IS MONEY market? Fortune magazine recently reviewed the performance of several small business computers, tabulating the results. LISA looked pathetic in comparison to the others. Proving that Fortune has extraordinarily tactful writers, LISA's performance was described as "leisurely!" Look, folks: "leisurely" is what businessmen want on a vacation, not at the office!

The symptoms of LISA's terminal illness were obvious to anybody who knew what it meant when one of two factories was completely closed down and the other was cut back 55%. According to Electronic News, 23 Jan '84, "Sources report that, at the end, the original Lisa was being outsold by the Apple III, a disappointment to the firm in its own right."

Do you realize that exactly one year earlier to the day (23 Jan '83) that we were being inundated by tons of puffery and barrels of pap about how LISA was going to revolutionize computing? Instead we had to wait six months for LISA to be born. Then she let out a horrifying gurgle, spun around once, and collapsed flat on her back, toes up. The body was cold before it hit the ground. Tsk. You would think that we would be treated to a lingering death scene, a la the younger Dumas' Camille.

Page 3, Column 2

INTRODUCING LISA II:

LISA II is a brand new ball game. Still continuing with the Electronic News story:

The new LISA II costs a third as much as the original LISA at $3495. For that you get a 512K machine with a single 3.5 inch Sony microfloppy. Add a 5 megabyte Winchester and add $1000; add a 10 megabyte Winchester and add $2000 (the production cost of a 10 meg Winnie is about 17 cents higher than the 5 meg version - but Apple has lots of 5 meg versions sitting on the shelf). Considering that LISA II has a real CRT, four expansion slots and four times as much RAM for only $1000 more than Mackintosh, she has a real chance to survive and maybe even thrive. For free, we will explain to the Apple Computer Co. the two additional steps that are needed to assure LISA II's continued health and prosperity:

One, make LISA II available with a second 3.5 inch floppy as an alternative to a hard disk.

Two, provide a genuine BASIC, a simple BASIC written in assembly just like the one in the VIC-20, and the Apple II+, as standard equipment.

Why would such a computer prosper? Well, for starters, we would probably buy two! Don't laugh, we have one Eagle II at work and another at home, and the Eagle II is a Z-80 machine with no graphics capability. Oh, the incredibly complex operating system written in (ahem!) leisurely PASCAL? Well, a simple BASIC would necessarily bypass all that incredibly complex crap. Besides, Apple is re-writing that PASCAL into assembly just as fast as it can. And they have decided that (gasp!) ANY Apple dealer can carry the new LISA II! You know, there's hope yet for Apple. They are beginning - but only beginning, as yet - to do things right. Again. Remember, Apple once did things right.

A genuine, simple BASIC, written correctly in 68000 assembly and provided as standard equipment with the new LISA II and with Mackintosh is what Apple needs to continue to grow and prosper.

If they continue to offer busted, incredibly slow BASICs as $750 optional equipment, they are going to go down the tubes, and deservedly so. (This is hard to believe, but the very same folks who were gushing pap about the original LISA a year ago are now claiming that today's personal computer doesn't NEED a BASIC! Some folks never learn.)

This is being written two days after Mack's introduction. At noon two days ago Mackintosh was officially unveiled at our nearest Apple dealer. Tadaa! The next day our other electrical engineering

Page 4, Column 1

type (he does not like being referred to as 'youthful') wandered into that Apple dealer and guess what? There sat Mackintosh, alone and well, ALONE! Can you imagine an IBM PC on display 24 hours after its introduction being lonely?

MACK: AN IMPRESSION

It happens that we hold a higher opinion of Mack than some others. We suspect that the typical DTACK reader has a full-house Apple II, and Mack is not going to appeal (candidate for understatement of 1984) to folks with full-house Apple IIs. Mack is clearly aimed at the first-time buyer, or perhaps someone upgrading from a Timex 1000. The full-house Apple II owner really ought to take a closer look at the LISA II, especially after they get finished converting the PASCAL to assembly.

Our reservations about both Mack and LISA II involve that damn mouse and those damn icons. However, that is just a question of personal taste. Personal taste led to the sales of over one million Apple IIs, over one million VIC-20s, over one million C-64s, over one million Z-80/CPM machines, nearly a million PCs, over a million 99/4As, over a million TIMEX 1000s... The common element in the sales of those millions and millions of computers? You %#&@!* KNOW what the common element was. How many computers with rodents and icons have been sold to date? 20,000 is the figure we read most often. We think Apple would be smart to offer an alternative, which is the familiar simple BASIC environment.

KNIFE IN THE BACK:

Steve Jobs is, apparently, not the favorite person of some people. Well, he DID start out as the resident con artist of the fledgeling Apple Computer Co. Then he made $200 million by his mid-twenties from a standing start, which maybe made him a tad arrogant and maybe made some others just a tad jealous. Still, Time magazine went out of its way a year ago to make Steve look bad. (In the Jan '83 issue naming a COMPUTER as "man of the year!") In the Jan 30 '84 issue Time magazine does not just try to make Steve look bad, it SAVAGES him. Unlike this newsletter, Time magazine has multiple layers of writers and editors. Anything that gets published is scrutinized carefully, many times. There is absolutely no possibility that the latest portrayal of Jobs is accidental - somebody at Time magazine, somebody in a position of high authority, is out to GET Jobs.

We would like to congratulate that person for having the courage to express his/her views openly, not hiding anonymously behind a mass of subservient editors. (We hope that sounded as sarcastic as we intended.)

Page 4, Column 2

INCIDENTAL STUFF:

We do have a diverse readership, some of whom are sufficiently young that their education is as yet limited. For those persons, some incidental stuff:

Walk into a library and locate a book on the modern French sculptor (Francois Auguste Rene) Rodin. Such a book will invariably have a table of illustrations following the table of contents. Look for an illustration of "Iris, Messenger of the Gods."

A bodice is a garment worn by women to cover their chest. The line of paperback books published by Harlequin and generally stocked in your local supermarket - the ones apparently intended primarily for feminine readership - are known in the trade as "bodice rippers".

The January '84 issue of Sky & Telescope magazine carries an illustration on page 25 of a young lady whose bodice has apparently been ripped entirely off. She appears to be riding on the back of a bull. The caption reads: "Europa is carried off on the back of Jupiter (who has taken the form of a bull) in this scene from the classical myth. They are flanked by their planetary namesakes."

Jupiter is the Roman name for the Greek god Zeus, who lived on Mt. Olympus a long time back. As far as we know, there was never a Post-Dispatch published on or around Mt. Olympus - we made that up - but there IS one in St. Louis, founded by a famous publisher. We have forgotten the name of that publisher because they do not give an award in his name for newsletter editors.

We can't tell you why that bull was carrying Europa off because there are laws against that sort of thing these days. (We can't tell you about Leda and the swan, either.) While you are at the library, get a book on Greek mythology and look in the index in back for Europa and Leda. In fact, check the book out and read the whole thing - those Greek gods were always up to something interesting. You may even find out why Hector needs swifter heels, sent c/o Charon, whose address is the river Styx.

POP QUIZ TIME:

The continental land-mass located just east of Great Britain is known as:

[ ] Antarctica
[ ] Europe
[ ] Maylasia

ESSAY QUESTION: In 250 words or less, explain how that continental land-mass got its name.

Page 5, Column 1

THE HALGOL 'LET' OPERATOR

permits folks to write perfectly normal equations just as in BASIC except that the three letters "LET" must precede the equation (make that four letters - a space is needed after the "LET"). The equation can be listed, edited and re-entered, even deleted entirely, and all of these just as fast as the chemical computer at the keyboard can push keys in the correct sequence. When the chemical computer gets around to keying "RUN(RETURN)" the expression to the right of the "=" is computed very swiftly indeed and then assigned to the variable(s) on the left because the run-time code is compiled.

And that is all the average programmer needs to know - HALGOL is easy to program, easy to edit, and it runs very fast. We assume that most of our readers would like to know a little more about the inner structure of the HALGOL program line, so we will explain that now:

The HALGOL run-time code is not just compiled, it is compiled and optimized. That means, among other things, that the run-time code does not look a whole lot like the original equation. In fact, there are no parentheses or anything corresponding to a parenthesis in the compiled code! Just about any programmer, including you and us, would be VERY unhappy if the line which was lovingly written with elegently nested parentheses were listed back out in its compiled form - "Hey! That's not what I programmed!"

For this reason, the program keeps a copy of the original equation in "crunched code" which is not used at run time. It is the "crunched code" which is listed back out on demand for editing purposes. The program also keeps the compiled code - mostly action addresses and variable offsets - so the program goes like a stripe-assed ape when RUN. And yes, this DOES mean HALGOL programs occupy more memory space than conventional BASIC programs written in, say, Applesoft.

There is no such thing as a free lunch. If you want to cast aside 64K limitations and if you want to have a nice friendly interactive program that runs at not just compiled speeds but compiled speeds that exercise all 16 of the 32-bit registers in the 68000 then obviously there has to be a tradeoff. The tradeoff is that your program is going to be longer. (If we are going to discard the 64K limit, then the addresses of our labels and such are 32-bit values, not 16-bit.)

We are going to confront this issue directly, without trying to hide behind crutches such as "You can compile your HALGOL code (throw away the tables of variable names, constant names, label names, line numbers, and all the crunched code, etc. which are not used at RUN time) and make the program smaller." Instead, we tell

Page 5, Column 2

you this: HALGOL is designed primarily for folks who write programs for their own use. Not many people, in the past, have written Applesoft programs in which the body of the program itself is greater than 24K. If a HALGOL program is twice as big (we don't know the exact ratio yet) then 48K of DRAM will be needed for the program. If the HALGOL program is three times as big, which is unlikely, 72K will be needed.

If you will check the price differential between a 128K Grande and a 256K Grande you will discover that the largest program you are ever likely to write will fit into less than $100 worth of DRAM TODAY and the price trend is DOWN. (This trend is discombobulated at the moment because DRAM demand is outstripping supply.) The professionals who write longer programs for sale will always 'compile' their programs so that they can't be listed and modified - and that will compact those longer programs into less than $100 worth of DRAM, too.

HALGOL DATA SIZE:

The fact is, when we think of programs which need a lot of memory we are usually talking about programs which need large data arrays. HALGOL DATA ARRAYS ARE EXACTLY THE SAME SIZE AS THE CORRESPONDING ARRAY IN BASIC, PASCAL OR FORTRAN! The folks who are buying full-gallon Grandes are planning to put big data arrays out there, NOT big programs!

Yes, HALGOL IS (relatively) wasteful of memory. No, that waste does NOT matter in today's world where everybody but Intel has discovered that the world is bigger than 64K. HALGOL IS DESIGNED TO TURN TODAY'S BIG, CHEAP MEMORIES TO THE COMPUTER OPERATOR'S ADVANTAGE!

Why hasn't a language like HALGOL come along before? Look, HALGOL is designed for personal use on a high-performance processor that can linearly address a big, cheap memory! For how long has it been possible for a mostly ordinary individual to own a computing device with those characteristics?

SURE IT'S TRAUMATIC!

Remember, we told you about our shock in going from a Wang 500 with only 320 bytes to a Wang 520 with all of 1848 bytes - and having to use an entire byte to specify a register, instead of just four bits like in the 500! You just gotta grit your teeth and do it! So come out of that 64K broomcloset and look around at the new world. See? It's at least 8 megabytes to the horizon in any direction you look!

And once you have moved to HALGOL, no more trauma in this century. We are all set up for the 68020 and its 4 gigabyte linear addressing space (!) already.

Page 6, Column 1

BRITISH: MANY!

It has been our pleasure for the past 20+ years to subscribe to the British publication Wireless World. More recently, we have also followed Micro Computer Printout magazine. We even visited Britain briefly a long while ago as a guest of Uncle Sam. We can therefore say with some confidence that those of you who think that the British are just like Americans, or just like New Englanders, are wrong, wrong, wrong.

Since lots of our readers are engineers, you might like to know that the status of an engineer in Britain is very slightly higher than that of a janitor in our country. Wait now, you probably think we are exaggerating and we aren't. In this country it is commonplace for an engineer to eventually become the president of the corporation which employs him but not many janitors become presidents. Likewise, in Britain it is unheard-of for an engineer to become a company president, and almost unheard-of for an engineer to rise to any managerial post. Engineers in Britain are paid about 40% of the going rate in this country.

The reasons are the differing educational paths, Britain's class structure, and simple tradition. However, we are more interested in the facts than the reasons behind them (in this case). We suspect that the low esteem in which the engineers are held in Britain is related to what we will discuss next.

British writers as a whole are far superior to American writers as a whole. When writing about technical matters they can often simplify and express clearly things which American writers would obfuscate with clumsy verbiage. On the other hand, we have yet to see any evidence that any Briton truly understands any processing unit more complex than the 6502 or Z80. (Wireless World is still publishing constructional articles centered on the Z80 microprocessor!)

It is said that some primitive societies count thusly: one, two, three, many! In our view, the British technical press has gazed at the Z8000 and the 68000 and the 16032 and even the iAPX 432 and said: many! They do not know that some of these devices are better than others or why. We have hard evidence that they tend, in these matters, to believe the last guy they talked to who is in a position (from the British point of view) of authority.

Micro Computer Printout magazine once asserted that the Nat Semi 16032 has 16 32-bit registers, just like the 68000. Some engineer (we forget who) wrote them a letter providing the correct number. After the letter was published, a manager (i.e., a proper British authority) with a British Nat Semi subsidiary called and said the 16032 did, too, have 16 32-bit registers!

Page 6, Column 2

So MCP dutifully published a retraction! Sigh. (All you have to do is look at the programmer's architectural model on the front page of the (then) preliminary 16032 preliminary data sheet to know EXACTLY how many 32-bit registers are at hand. But only a lowly engineer would stoop to consulting a spec sheet!

Oliver Heaviside, who is surely the greatest engineer in British history, spent his last years not just in poverty, but in abject poverty. He literally could not afford to heat his small hovel! When a couple of representatives of an American engineering society made a pilgrimage to his home (well, hovel) to present an award they were shocked to discover his circumstances. Oliver remarked that the award was very nice, but he would have preferred a ham. He got it, since Americans hold engineers in much higher regard than the British.

When a British journalist wants to know what is happening at a company, he naturally does not want to associate himself with a lowly engineer so he naturally calls - or calls on - the manager, who naturally takes pride in being devoid of any knowledge of engineering, just as we are proud of our lack of knowledge about honey-dipping (either kind). As a natural consequence, British journalists gaze at the new generation of microprocessors and exclaim, "many!"

We have brought this matter up for two reasons: One, it will be interesting to see how the British press deals with Sir Clive's new Trash-68. Two, we wrote in our last newsletter that we would like to learn more about the Inmos Transputer. Immediately after writing that we picked up the latest issue of MCP and found a four-page article on the transputer. Of this, more later.

ANON THE VON:

A long while back Wallace published a paper pointing out that scientific processors (at that time) spent 90% of their time performing multiplication by the shift-and-maybe-add method. He asserted that it would be cost-effective to build a specialized device dedicated exclusively to performing multiplication, even if the specialized device would cost fully as much as the entire computer to which it would be attached! Wallace continued to suggest a particular method of constructing a specialized multiplier in which a particular sub-element could be interconnected in a specified manner to construct a multiplier of any desired size. This structure immediately became known as the "Wallace Tree. "

Wallace's paper, along with Maurice Wilke's brilliant exposition of microprogramming, is one of the most important advances in computing that came along

Page 7, Column 1

(shortly) AFTER the first real computers were up and running. We hasten to add that Mr. Wilkes is British (his first name is pronounced "Morris").

Wallace proved to be absolutely correct in every aspect of his paper - the silicon-baking community later embraced his sub-element by producing it under the part number 74275, which TI's TTL data book (second edition) describes as a "7-bit-slice Wallace Tree." Recent advances in LSI have finally, after all these years, rendered Wallace's circuit design obsolete while further cementing the accuracy of his principal assertion. One simply does not encounter a scientific computer which does not have one or more specialized multipliers attached.

THE WRIGHT BROTHERS

made an ENORMOUS mistake when they invented the airplane. The airplane they invented had to be landed! Pilots have been cussing ever since over this design flaw. If you aren't a pilot, consider that a plane is landed by DELIBERATELY flying the airplane into a very large, very hard object at roughly a hundred miles an hour. The most important rite of passage for any pilot is the day he 'solos' - meaning he has to land the damn plane with absolutely no possibility of assistance from anyone else. (ANYBODY can take off and fly around, that's easy!)

In Tom Wolfe's "The Right Stuff" he writes:

"In the Navy, in addition to the stages that Air Force trainees went through, the neophyte always had waiting for him, out in the ocean, a certain grim gray slab; namely, the deck of an aircraft carrier; and with it perhaps the most difficult routine in military flying, carrier landings. He was shown films about it, he heard lectures about it, and he knew that carrier landings were hazardous. He first practiced touching down on the shape of a flight deck painted on an airfield... "

And then comes the day when the Navy sends the neophyte up with a 90 minute supply of JP-4 and instructs him to land on the deck of a carrier standing close offshore. Unlike the solo, the pilot has a choice: he can land on the carrier or turn around and return to a nice, safe 10,000-foot runway that doesn't move. Before 90 minutes is up, the Navy has either a jet pilot or a laundry officer - or, occasionally, a body to ship home.

von NEUMANN,

like the Wright brothers, made a terrible mistake when he devised the computer architecture which is used by essentially 100% of today's computers. In devising an

Page 7, Column 2

architecture in which both instructions and data are kept in the same memory and fetched on the same (data) bus, he effectively limited the speed of any von Neumann computer to the speed with which instructions and data could be fetched via that bus. This is called the bus-bandwidth, generally measured in megabytes per second. A 12.5MHz 68000 has a bus-bandwidth of 6.25 megabytes per second and an Apple II has a bus-bandwidth of 1 megabyte per second. Since there is an upper limit to the bus-bandwidth that can be attained using existing devices, there is a corresponding upper limit to the maximum performance which can be attained by a computer. (This limit obviously changes as existing devices improve.)

That is, there is an upper limit if the computer is constructed using von Neumann principles. The immediate corollary springs to mind: if the computer is constructed using other principles, there may be no upper limit on performance!

Are there any examples where this is true? Of course! A multiplier constructed using Wallace's principles is definitely a non-von Neumann device and is not limited in speed by bus-bandwidth considerations. (It is generally connected to a von Neumann host computer which IS so limited.)

Are there yet any examples of GENERAL PURPOSE computers which have significantly higher performance by using non-von Neumann architectures? No, or the Cray-I would not be constructed using von Neumann architecture.

Is it POSSIBLE for a general purpose computer to be constructed using an alternate architecture which is both practical and significantly superior in performance to an equivalent von Neumann machine? AH! THAT IS THE QUESTION! The question which every computer designer worth his salt has spent many, many hours agonizing over! Obviously, the answer is not yet "yes". Obviously, we cannot be certain that the answer is forever "no"...

BEATING THE BOTTLENECK:

Aside from the obvious attempt to pursue ever-greater bus bandwidths, here are some of the other methods used to fight the bottleneck: 1) Specialized hardware for specific functions, such as the Wallace multiplier. 2) Parallel processing, which is very useful for some problems but not useful at all for others. 3) Providing the CPU with greater internal resources so that the data bus is less heavily used. The 68000 is a particular example of a CPU with far greater internal resources for data than is usual; the 68020 will keep that characteristic and add a substantial instruction queue, or buffer, so that loops can be executed without using the data bus to fetch instructions. 4) Use of

Page 8, Column 1

complex and/or unusual logic organizations (e.g. iAPX 432) to provide superior performance. Regrettably, not one such attempt has yet met with success. 5) Most logical of all, use of a non-von (Neumann) architecture. Again, not ome such attempt has yet met with success. (Success is here defined as improving on the performance of an equivalent conventional von Neumann machine.)

SO EVERYBODY HAS QUIT?

In a pig's eye! Commodore avoided following Intel down the iAPX 432 rat-hole only because the chief designer of the 650,000 microprocessor (the number of zeros in the model number is correct) quit and joined an Atari-financed startup. Right now a Japanese company (NEC) is chasing the 432 as well (you would think the word would be out, wouldn't you?).

Are any non-von projects in the works? Well, a British company has spent $100 million of the British taxpayer's money on a thing called a 'transputer'. And we know more about the transputer than we used to because Micro Computer Printout has published a four-page story on the device. Let us pass some of this information along to you:

THE INMOS T424 TRANSPUTER:

The title of the story in Jan '84 MCP is "The T424 Transputer - Processor, Memory and Communications on one 1/4" square chip" The subtitle is: "It is a revolutionary device. It is called the Transputer and it is British..."

The article concludes: "'We are,' says the head of its design team, 'three years ahead of the Japanese. Which means of course that we are also ahead of the Americans... No one else [other than the British] on the planet has yet managed to put all three parts, processor, memory and communications on one chip."

Now that we have covered the beginning and the end, here's some of the stuff in the middle: "INMOS claim that one transputer has the power of one hundred home computers and is eight times faster than even the hottest thing available - National's 32-bit processor... in years to come we may have systems containing hundreds of transputers."

In a sidebar titled "The T424 Specifications" we find: "High performance arithmetic." Wow! Does that mean the chip can start adding two and two at noon and arrive at the answer before sundown or does it mean it can invert a 100 X 100 matrix in a picosecond? (Being an ignorant American and a lowly engineer to boot, we would not dignify "High performance arithmetic" by calling it a description, much less a specification!)

Page 8, Column 2

One last quotation: "INMOS have developed the technology to put all three elements on one chip but the wiring together remains to be done." In other words, they haven't built one and so they haven't turned it on. Having sent for a seed catalog, MCP is feeding the starving hordes in Asia and Africa.

Did you notice the author (Rex Malik) asserts that the Nat Semi 32032 is the hottest thing available? One might almost think Rex has been peeking at the article in BYTE in which Richard Mateosian asserts that all 32-bit processor are faster than all 16-bit processors. In fact, not only is the 32032 not the fastest thing available; it is not even available!

Will the T424 in fact be a high performance device? Who knows? They haven't turned one on yet. Remember, the 432 was going to have high performance right up until the moment they turned one on and benchmarked it. As it happens, Rex obviously has not noted the ignominious demise of the 432.

You don't believe us? Pull out Dec '83 MCP and see Rex Malik's story toward the end of page 22: "the much-rumored NEC processors, whose characteristics are... 'C', Pascal and ADA-oriented architecture... Imagine the speed of a device designed around the powerful languages listed above!" IMAGINE, indeed!

Rex obviously has a better imagination than your FNE. The Intel iAPX 432 is designed around just ONE of those three high level languages and it would be an exaggeration to describe the 432 as a dog. It is not that good.

MORE MANY!

The following letter to the editor was printed in the Nov '83 issue of MCP:

"Dear English Scum:

"I do not mind the ridiculously inaccurate English histories of our Revolutionary War. I do not mind the misguided celebration of victory in the Falklands, which was entirely due to the fact that the majority of the bombs very accurately delivered on target by the brave Argentine pilots were duds, dating from WW2.

"What I do mind is the fatuous and simplistic description of both the 8088 and the 68000, in one sentence in September Micro Computer Printout as being 16-bit computers. A few facts for you backwater foreigners:

"The 8088 has an 8-bit data bus, some 16-bit registers and a smattering of 16-bit instructions. The 68000 has a 16-bit data bus, lots of 32-bit registers, and a

Page 9, Column 1

larger smattering of 32-bit instructions. Surely it must be evident to the dimmest of wits that whatever size is assigned to the 8088, the 68000 must be described as twice as large. But no; MCP in its vast wisdom declaims that the two are equal in size.

"(name deleted) Santa Ana, CA

"P.S. Insulting letter follows."

You will not believe this, but MCP's editorial reply asserted that the 8088 had more business-related software than the 68000! While that is certainly true, it is irrelevent to the described size of the microprocessor, which is the subject addressed by the writer (Santa Ana? A neighbor, perhaps?).

Being unfamiliar with the size of the 8088 ourself, we pulled out our trusty iAPX 86,88 User's Manual. On page 8-27 we find the iAPX 88/10 (8088) 8-BIT HMOS MICROPROCESSOR. By George III, that (somewhat intemperate) letter writer was right! The 8088 IS a size smaller than the 68000!

CRYSTAL BALL TIME:

Will the transputer fly or will it be a bust? We dunno. Considering the number of very bright folks who have tried to figure a way to outdo the von Neumann architecture in the past three decades but who have collectively failed, we would say the odds are the transputer is gonna flop. But the odds against Dark Star were heavy and he still beat Native Dancer in the Derby.

If the transputer succeeds as its proponents expect, it will be possible to connect them in arrays reminiscent of the Wallace Tree, another non-von computing structure, to achieve even greater performance. That's what was meant earlier when Malik wrote "in years to come we may have systems containing hundreds of transputers."

Since we do not know whether the transputer will succeed, let us tell you something we DO know: when INMOS managers looked around for some top-notch engineers they discovered that the British engineers were all failed greengrocers, a natural consequence of the low esteem conferred on the (surely not profession) in Britain. So the INMOS managers set up shop in a foreign country, one where engineers are more respected, and hired some engineers to develop the transputer THERE. So it seems that a major portion of the $100 million the British taxpayers have invested in the development of the transputer has gone into the pockets of foreign engineers! Because of the great tact for which your FNE is justly famed, we will not reveal the name of this foreign country.

Page 9, Column 2

A 68000 CHRONOLOGY:

1975: design study of advanced microprocessor commences.

1976: design solidifies; 32-bit registers and address pointers adopted.

1977: availability of 68000 is promised for 1978.

1978 - 1979: continual promises that the 68000 will be available "real soon now"

1979: Motorola sees first silicon for the 68000.

Feb 1980: 4MHz 68000 available as part of $2000 demo board.

Nov 1980: first sale of 8MHz 68000 across the counter.

Jun 1982: 12.5MHz 68000 available across the counter.

Aug 1982: 8-bit data bus version of 68000 sees first silicon and - gasp! - works!

1983: virtual-memory version (68010) developed.

1983: Hitachi shrinks mask set to 2.7 micron design rules and becomes second source for 12.5MHz 68000s.

Sep 1983: floating point math chip support for 12MHz 68000 arrives - the Nat Semi 16081 (engineering samples only).

Feb 1984: Motorola anxiously awaits impending 68020 first silicon.

A review of that chronology should establish that nothing happens quickly in the world of advanced silicon products. Let us emphasize that the above chronology is absolutely typical - in fact, development of Intel's 8087 and National's 16032 was even more leisurely. And do you remember that Intel was supposed to be shipping 80186s in large quantities beginning in Dec 1982? WE well remember the grinning teenager who walked into our office in the summer of 1982 and demanded to see our prototype 68020 board!

A complete chronology would include Motorola's spring 1980 decision to deliberately withhold the 68000 from the personal computer marketplace, its reversal of that decision in summer 1982 and its late 1983 decision to suppress knowledge that the 16081 is a good 'fit' to the 68000. (Nat Semi has evidently taken the other approach: we have spotted more than one Nat Semi sales type or technical representative openly pushing the 16081 for use with the 68000.)

Page 10, Column 1

(We sort of apologize for the following, which repeats stuff printed in previous newsletters and is at a very low technical level as well. You have been warned!)

THE MOTOROLA 68000,

at 12.5MHz, is today's highest-performing microprocessor. In addition to the fast clock, it has more internal resources than any other microprocessor (except others in the 68000 family). Having enormous internal resources, more things can get done with less use of the data bus. Despite this, the 68000 manages to keep the data bus very busy indeed - imposing wait states or sharing memory with video (e.g. LISA) results in a nearly proportional decrease in performance. Like the 6502, the 68000 has a zero page which can be used for exceptionally efficient programming; unlike the 6502, the 68000's zero page is 64K bytes unless the hardware manufacturer is incompetent, in which case the zero page is only 32K bytes (ahem!).

Because the 68000 addresses 16 megabytes as easily as the 6502 addresses 64K bytes, it is the correct machine to have for you hackers who now have - or will soon have - a half megabyte of DRAM to rummage around in. In addition, the 68000 happens to be very easy to program for us assembly freaks. This is due not only to the large zero page and the huge linear addressing range but also to some instructions that were clearly added to the instruction set just to please us assembly freaks. That includes MOVEQ, ADDQ, SUBQ as well as address register indirect with predecrement or postincrement.

The 68000 is the first of a family of microprocessors with varying performance but identical register sets - they all have 16 ea 32-bit registers - and very nearly identical instruction sets.

THE 68010

is a 68000 with a couple of extra features. The most important is the ability to "back up" one clock cycle in the event of a bus fault. This is accomplished by having a bunch of "shadow" registers to remember everything which was happening one clock ago. Motorola is pushing this feature primarily as a 'hook' for virtual memory, something which you will never encounter if you are lucky. We think this feature is most useful to permit error checking and correction for computers being used in very crucial situations, such as banking or missile control.

The 68010 also has TWO, not one, prefetch registers. As a result, it is up to 15% faster than the 68000 for a given clock speed. However, it is only available at 10MHz, and so is slower than a 12.5MHz 68000.

Page 10, Column 2

THE 68008

is an 8-bit version of the 68000. It is only available at 8MHz, and has half the bus-bandwidth of an 8MHz 68000. It does have EXACTLY the same instruction set and EXACTLY the same number of 32-bit registers. (It bears the same relationship to the 68000 that the 8088 does to the 8086.) Also, a complete system can be made using only one ROM and only 8 DRAMs. The 68008 is ideally suited for those persons who wish to shoot rocks using 32-bit registers, as Uncle Clive is about to prove.

THE 68020

is going to be a real 60 foot tall gorilla when it becomes available. (The latest slippage predicts first silicon in April '84.) It has the same register set as the 68000 and an upwardly compatible instruction set, so rock-shooting games written on Uncle Clive's toy can also run on a beast that can eat any currently existing VAX alive - without seasoning. The 68020 has a true 32-bit data bus and 32 bit addressing so that you will no longer need to worry about the 68000 only addressing 16 megabytes. Since the device will be built using 2 micron design rules, it will undoubtedly EVENTUALLY run at Motorola's predicted 16MHz.

In addition to the obvious speed advantages due to the far greater bus-bandwidth, the 68020 will introduce significant additional internal resources besides the usual 16 ea 32-bit registers. A large prefetch queue is used (the exact size has not yet been publicized) which is intelligent enough to know when a backwards loop is made. Instructions are then fetched directly from the queue, (approximately) doubling the effective speed of the 68020. [This latter feature actually works today on the 68010 if the loop only has two words - e.g. CMP -(Ax),-(Ay) BNE LOOP.] With this large queue, the 68020 will outperform the 68000 even more than the bus-bandwidth (16 megabytes/second!) implies.

If Motorola actually sees first silicon in April, there is a 50-50 chance that Digital Acoustics will be able to get a sample before Jan '85 and a 50-50 chance that we can design a board in the spring of '85 for sale in the summer of '85. The board will initially be very high priced with 32ea 256K DRAMs (that's a one-megabyte minimum configuration!) and probably won't run at 16MHz that early in the game.

In other words, the 68020 is, now, a paper tiger. So are most of the other microprocessors we will be discussing!

THE 16032:

We wrote about the 16032 here for the first time in

Page 11, Column 1

issue #4 (Nov '81), on the last page. Both the 68000 and the 16032 have about 70,000 transistors and are made using 3.5 micron design rules. Both micros have about the same performance at the same clock rate. The problem the 16032 has is TIME. It's LATE! As we told you in issue #4.

The 68000 became available at 12.5MHz (across the counter) in June '82. The National 16032 is not yet available across the counter at 10MHz. If it were, it would still be slower than the 12.5MHz 68000. And the 68000 has a head start, software-wise.

If the 16032 and the 68000 have about the same complexity and the same design rules, then why can Motorola turn out 12.5MHz parts while National is currently struggling to produce a limited number of 10MHz samples? Because it takes time to perfect the production process, that's why (we call it calibrating the cookie-cutter). When the first 68000s became available, 8MHz parts were in short supply and Motorola was actually selling 4MHz parts - remember?

Hardware-wise, the 16032 should be compared with the 68010 since both of them have hardware 'hooks' for virtual memory. Somehow we can't get too excited about virtual memory in a personal computer. That letter we received from BDM asserting that a virtual memory Corvus 68000 machine ran more than 100 times slower than a DTACK board with less memory might have something to do with that, although we had EARLIER asserted that virtual memory would run about 100 times slower - before we received confirmation from BDM!

Software-wise, the 16032 is very similar to the 68000. Having said that, let us concentrate on the differences: the 16032 has nearly as many 32-bit registers as the 68000, but almost half of them are specialized rather than general purpose as in the 68000. The reason for this is that the 16032 design is deliberately optimized for compilers (e.g., COBOL). In addition, the instruction set of the 16032 is almost perfectly 'orthogonal', meaning that any addressing mode that can be used with one instruction can be used with any other instruction (almost). Compiler writers can get very excited over this.

On the other hand, that means that National left out a bunch of stuff that makes the 68000 such a neat chip for us assembly freaks. The first thing is that the 16032 does not have predecrement [-(An)] or postincrement [(An)+] addressing modes. Well, if you don't have those addressing modes then you just HAVE to have ADDQ #x,An - right? Of course! But the 16032 doesn't have that instruction (or SUBQ #x,An). The 16032 also does not have MOVEQ (byte). What does all this mean?

Page 11, Column 2

It means that the 16032 may appeal to COBOL freaks who don't mind adopting a chip that is a little over three years behind its competition.

(Please remember that we have exaggerated the differences between the 680X0 and the 16032. An Intel fan would say the two devices are VERY similar. The real difference is measured in TIME, like 3+ years.)

THE 32032

is essentially identical to the 16032 except for a true 32-bit data bus. We have recently learned that its performance edge over the 16032 is closer to 25% than 35%, so if you could buy a 10MHz 32032, which is what Nat Semi is advertising, it would run at the same speed as a 12.5MHz 68000 and be optimized for COBOL compilers to boot.

The 32032 trails the HP 32-bit CPU and the (formerly) BELLMAC 32, which are both in production. However, neither are available across the counter. It does appear that the 32032 will probably become the first 32-bit microprocessor which can be purchased across the counter. Nat Semi brags a lot about this in its ads.

Keep in mind that Nat Semi was ALSO first with a 16-bit CPU! You may have forgotten the IMP-16, followed by the PACE, followed by the INS8900 SUPER-PACE! All of these were early 16-bit Nat Semi parts that didn't catch on.

THE 8086,

at 10MHz, is the highest performance micro that you can buy from Intel today. This fact may surprise you, especially if you have read Intel's assertion that the 286 is 6 times faster than the 8086! Well, that ain't so. It never has been so and never will be (we explained why, in detail, on page 10 of issue #10 - 20 months ago!). And as long as the fastest 286 you can (barely) get your hands on runs at 6MHz, the 10MHz 8086 will be Intel's fastest available micro.

But you should know all about the 8086 by now, so we'll move right along to

THE 80186,

which is in the strange position of being so popular that you cannot buy one unless you got in line a long time ago. It seems that only about one out of ten of the chips that have been ordered will be shipped in 1984. It is not clear yet whether the chips that will shipped in 1984 will be completely bug-free. Even Intel may not know the answer to that one! (An explanation for this strange state of affairs is offered elsewhere in this issue.)

Page 12, Column 1

The 80186 is the industry's first attempt to deliberately develop a microprocessor which is NOT a state-of-the-art part, but instead is designed to make possible the cost-effective construction of small computer systems - small, STANDARDIZED computer systems because all the features are frozen in silicon. Last July, we predicted that this chip was going to be wildly successful and that millions of small computers would be based on it. Well, about ten million chips have been ordered for 1984 delivery! How's that for an accurate prediction?

Too bad Intel can only deliver one million.

THE 80286

is actually easier to get hold of than the 80186, especially if you are willing to settle for a 4MHz or 6MHz part. Naturally, Intel is advertising 8 and 10MHz parts. Naturally, you cannot get one.

Because Intel and AMD are running ads which prove conclusively that the 286 is a bunch faster than the 68000, and Motorola is now beginning to run ads which assert that the 68000 is a bunch faster than the 286, you might be confused. If you realized that BOTH companies were basing their comparisons on the SAME set of benchmarks (the EDN/Heminway tests) then you would be even more confused! Let us clarify matters for you: each CPU is superior to the other! Honest!

(We will assume here for the sake of discussion that the 8MHz 286 is available. Remember, it isn't!)

The 286 is significantly superior to the 68000 if we can live with 64K chunks of memory. Examples: IBM PC BASIC, which limits one to 64K program and 64K data. SofTech UCSD PASCAL, which limits one to 64K program and 64K data. If this sort of limitation tickles your fancy then the 286 is just the chip for you. It's also a pretty good chip for the folks who want to chain 16 users to one CPU - each will be allocated their very own personal 64K, naturally. Any way you look at it, the 286 is a great 64K machine; better and faster than the 68000.

The instant you need 1 byte more than 64K the 286 falls flat on its face. The one-man-one-CPU folks with 256K or more DRAM should avoid the 286 like the plague. In addition to having inferior performance to the 68000, it is about five times harder to program in assembly (what SEGMENT am I innnn...).

THE ZILOG Z80000:

That's EIGHTY thousand, with four zeros. The vice president of engineering who was in charge of developing that chip just departed, hastily. An Zilog

Page 12, Column 2

spokesman asserted that Zilog was not at all unhappy at his departure on account of the development of the Z80000 (and the Z800) was proceeding at a, well, LEISURELY pace! You would not want to hold your breath until the Z80000 arrived.

THE INMOS T-424 TRANSPUTER

is, according to an industry insider, about a year away from first silicon. If the British taxpayers' money holds up and if the theory behind the transputer proves correct then we may be able to buy transputers across the counter two years from now. If the theory proves correct and one can indeed increase performance by interconnecting a phalanx of transputers, then you are going to read a great deal about a programming language called OCCAM (after 'Occam's razor'), designed by C.A.R. (Tony) Hoare.

If the theory behind the transputer does not work, it will not be the first time over a hundred million dollars has been wasted in an unsuccessful attempt to unseat the von Neumann computer architecture.

FLOATING POINT MATH SUPPORT

is ALMOST available for all microprocessors. Almost on account of the Nat Semi 16081 has not yet reached production status (it is close, though). Once the 16081 is in production all 16-bit micros, and even 8-bit micros, will have high performance floating-point math support. This fact is not generally known, yet, to persons who do not read this newsletter. If Motorola had its druthers, this fact never WOULD be known. (There are times when we do not follow Motorola's logic.)

But knowledge that the 16081 can be used as a peripheral to the 68000 is spreading - we understand that Nat Semi is preparing an application note on that subject. But we would bet a six-pack of Heineken's Special Dark that the application note will not reveal that a 6MHz 16081 can be mated to a 12MHz 68000! It is amusing to note that the fastest Intel-based micro that could be built today would be a 10MHz 8086 coupled to a 5MHz (or 10MHz) 16081! Yes, Nat Semi is getting some (slight) yield at 10MHz on the 16081.

Like the 286-68000 comparison, the Intel 8087 and Nat Semi 16081 math chips are each superior to the other. The 8087 can be used only with Intel processors (unless you have $70 million or so to diddle the microcode, as IBM has done to mate the 8087 to the 68000 in its XT/370). If you are not going to use an Intel microprocessor, then your choice is limited to the 16081 and performance comparisons are irrelevant.

For the record, the 8087 is faster and more accurate

Page 13, Column 1

when performing most transcendental functions and square roots. The 16081 is about three times faster than the 8087 and just as accurate when performing simple arithmetic, for example calculating A = B * C where all three operands are kept in main memory. Therefore, the 16081 will also be much faster when performing vector dot products and performing matrix operations. A truly optimized microcomputer which sells for $10,000 or more could logically contain BOTH math chips, using each where it works best. (That means using a 40-pin clock generator called the 8086.)

We strongly suspect that a scientific-oriented high performance microcomputer will have more than one 16081...

The Motorola 68881 floating point math chip will likely be superior to both the 8087 and the 16081, but is a long way off. (We will cover this chip in more detail in the next issue.)

(End of boring, repetitious, non-technical stuff.)
ADVERTISING MANAGERS:

A colleague is moving up into the wonderful world of slick magazine covers and advertising managers. In the past this colleague has been known to review software for his newsletter and express candid opinions, pro and con. He still reviews software and he still writes candid opinions. The slick magazine which his newsletter has evolved into now has a publisher and an advertising manager, so those candid opinions get, um, modified.

It seems our colleague recently panned one software package as being simply a very bad product, while praising a competing software package as being excellent and a good value. What got printed was that the first product was very nice but was missing a minor touch or so, while the second product was very nice and had a couple of nice additional touches. In other words, what got printed was unrelated to the original reviews.

After all, if the original package is panned then they won't advertise, right? And if the other package is praised and the original package ISN'T, then they STILL won't advertise, right? So what we get are homogenized reviews, but keeping the original reviewer's name because he built up a reputation back when he didn't have an advertising manager. Wunnerful, wunnerful!

We have promised not to reveal the name of this colleague. Most of you would not recognize his name anyhow because he is active in Commodore land.

Page 13, Column 2

HALGOL CONDITIONALS:

"IF A > 0 GOTO 5210" is your prototypical conditional statement in the BASIC language. We are going to explain here what the equivalent is for the initial release of HALGOL. The HALGOL conditional statement takes the following form:

     100 IF OBJ1 [rel] OBJ2 [oper1] ELSE [oper2]

In the line above 100 is the line number, IF is the HALGOL keyword, OBJ1 is a named variable, [rel] is one of the six possible numeric relational tests, OBJ2 can be a named variable or a constant (special notice is taken if the constant is zero). 'Oper1' is the operation which will be performed if the result of the relational test is true. 'Oper1' can be an assignment operation preceded by THEN (e.g. THEN P = Q + R), a GOTO "label", or a GOSUB "label". The 'ELSE' is optional. If 'ELSE' is present then 'oper2' is the operation which will be performed if the result of the relational test is false. Like 'oper1', 'oper2' can be an assignment operation ('THEN' is superfluous), a GOTO, or a GOSUB.

Here are the six legal relational operators:

     =  EQUAL 
     <> NOT EQUAL 
     >  GREATER THAN 
     >= GREATER THAN OR EQUAL 
     <  LESS THAN 
     =< EQUAL OR LESS THAN

The following are all valid lines of HALGOL code. Their purpose is obvious if you know BASIC.

     100 IF A < B THEN C=D+LOG((E+1.4)/(F-357)) 
     110 IF A <> 0 GOTO "OOPS" ELSE B=560 
     120 IF A =< 45 GOSUB "URP" ELSE GOTO "MEW"

The following lines are invalid HALGOL code:

     130 IFA <0 GOTO "OOPS" 
     140 IF A <= 45 GOTO "OOPS" 
     150 IF A =< 45 GOTO 350 ELSE B=560 
     160 IF A+2 > B GOTO "OOPS" 
     170 IF A <> BGOTO "OOPS" ELSE GOSUB "WUMP" 
     180 IF 3 < B GOTO "OOPS"

Line 130 is invalid because the keyword 'IF' is not delimited on both sides by a space. Line 140 has an invalid relational test (try '=<' instead). In line 150, you cannot GOTO a line number (try GOTO "OOPS" instead). In line 160, OBJ1 is an expression instead of a named variable. In line 170, the keyword 'GOTO' is not delimited on both sides by a space. In line 180, OBJ1 is a constant, not a named variable.

Page 14, Column 1

Single-letter variable names were used above for brevity. Long variable names are perfectly acceptable and in many cases preferable; remember that HALGOL only stores that long name once and that subsequent appearances of the long name occupy no more space than a single-letter variable name. All of the letters of a variable name are significant; the two following variable names will be correctly identified as separate variables:

     ANTIDISESTABLISHMENTARIANISM1 
     ANTIDISESTABLISHMENTARIANISM2

RUN-TIME CODE:

We will recall that we want our code to not only run correctly but, this being HALGOL, we also want it to run swiftly. Therefore the compiler code for the 'IF' statement will first generate one of three action addresses, depending upon whether OBJ2 is a named variable, a constant whose value is other than zero, or a constant whose value is zero. (If we have a constant whose value is zero, the comparison code can be simpler and hence faster. So this necessitates six extra small code segments for the comparison; the resulting speed increase will be worth it. The HALGOL compilation process is somewhat optimizing. More important, the permissible forms of HALGOL functions have been chosen to permit if not require efficient, optimized code.))

Here are the initial forms of the three possible 'LET' statements:

     < LET1 > 
     [linlink] 
     [offset1] 
     [offset2] 
     <rel #n>

The first line above is the action address for the first type of numeric LET statement. The second line is the link which lets us know where the start of the next line is. The third line is the offset of the first named variable (OBJ1), and the fourth line is the offset address of the second named variable (OBJ2). The fifth line is the action address which performs one of the six relational tests between two floating point values.

The second form of 'LET' statement is identical to the above except that [offset2] is the offset address of a constant. Following is the third type of numeric LET statement:

     < LET3 > 
     [linlink] 
     [offset1] 
     <rel #nA>

Page 14, Column 2

Here the second offset address is not needed because OBJ2 is known to be zero. This permits simplified forms of the relational tests so '#nA' is a different relational test than '#n'. That means we have TWELVE, not six, numeric relational test action addresses! (Well, you DID want HALGOL to run fast, didn't you?)

When listing < LET1 >, the list link points to code which knows that the second offset address points to a named variable, the < LET2 > list link points to code that knows the second offset address points to a constant. The < LET3 > list link points to code that knows that there is no second offset address and that OBJ2 is 0 (zero). It also knows that the relational test action addresses are different.

This brings us up to the portion of the code which is performed if the relational test is true. This can take three forms:

     THEN C=C+LOG(E+357) 
     GOTO "MUMP" 
     GOSUB "MUMP"

In the first case, 'THEN' may be considered to be a conditional 'LET', where the LET is to be performed only if the condition is true. In the second two cases, the 'THEN is considered superfluous and can - in fact must - be omitted.

The HALGOL code for the first case is essentially identical to the HALGOL code for the LET statement except the first action address is < THEN > rather than < LET >. The HALGOL code for the other two forms is NOT identical to the regular action addresses for GOTO or GOSUB, followed by the label offset. These are, after all, CONDITIONAL functions.

CONDITIONAL GOTO:

The (first) conditional GOTO is simply the action address which first looks at the condition and performs the GOTO only if the condition is true. If the condition is false, the HALGOL program pointer A6 is incremented past the label offset and program execution continues. The HALGOL code is:

        <CGOTO1> 
     [label offset]

CONDITIONAL GOSUB:

The (first) conditional GOSUB is a little different from the (first) conditional GOTO in that we have to worry about preserving the condition. If the code performed during the subroutine does a conditional test, the present condition will be overwritten.) So our conditional GOSUB looks like this:

Page 15, Column 1

        <CGOSUB1 > 
     [label offset] 
     <restore cond>

The (first) conditional GOSUB pushed the condition onto the HALGOL data stack before performing the GOSUB (if the condition is true). Upon returning from the subroutine, an unlisted HALGOL function pops the condition from the data stack and restores it. If the condition is false, the HALGOL program pointer A6 is incremented past the <restore cond> and program execution continues. In other words, if the condition is false we do not save the condition on the stack, thus saving a little bit of time.

OPTIONAL ELSE:

This brings us to the optional ELSE portion of the HALGOL numeric relational statement. This can take three forms:

     ELSE C=C+LOG(E+357) 
     ELSE GOTO "MUMP" 
     ELSE GOSUB "MUMP"

If you think these forms look familiar, you are right. They look at first glance the same as the possibilities following the relational tests, with the addition of (do nothing) if ELSE is omitted, which is legal.

The action address <ELSE> is obviously different from the action address <THEN>. It is less obvious that the conditional GOTO and GOSUB are different from the first forms of those conditional functions. But the decision to take the 'GOTO' branch is reversed; the branch is taken if the condition is false. Similarly, the decision to take the 'GOSUB' branch is also reversed and, in addition, there is no need to save the condition!

WE GET MAIL:

"...the following account is completely true except the names have been changed to protect the innocent.

"There is a current large scale project, Worldwide Navigation System (WNS), which is being programmed by Multinational Office Products (MOP) Defense Systems Division. The program is written for the 4044N, produced by the MOP commercial division, and a successor to the highly successful TWO-PI series. The 4044N is rated at 4.8 MIPS. The program is over 500,000 lines of new code, and, for both technical and political reasons, is being written in the pet language of the Space Force (the branch of the Department of Defense which is running the project). This language, HILARIOUS, has a compiler produced, not by MOP, but by OCEAN, a small (about 15 people) software house.

Page 15, Column 2

"Naturally, the program is a real time one, and must run in less than real time. In fact, the Space Force has specified a scenario which WNS must run using 65% of the 4044, to allow for future expansion.

"The HILARIOUS language has a CASE statement, as modern languages do. It turns out that CASE statements are invoked about 1000 times per second on the scenario. (It used to be 10,000!) CASE statements call a library routine and when MOP ran into throughput trouble, they timed the CASE library routine and found that it takes, on the average, 1840 instructions. That works out to more than 38% of the 4044, which was judged excessive. MOP got busy and rewrote the CASE library routine themselves, reducing it to an average of 154 instructions, only 3.2% of the machine.

"How is it possible to make such a great improvement? The answer is that the HILARIOUS library is, itself, written in HILARIOUS, while MOP is rewriting it in TWO-PI assembly." Bruce W., San Pedro CA

Bruce, you have disguised your subject matter too well - next time write it up so that us dummies can recognize the true dramatis personae, O.K.? - FNE

"I came across the enclosed article in the February issue of Computer Shopper which is an excerpt from a book by Don Lancaster. He sounds just like you! Is he a subscriber? ...I am revising my music book this year and for certain the 68000 with the 16081 math chip will get top billing in place of the moribund DEC LSI-11." Hal C., Wake Forest NC

Here is the excerpt from Lancaster's book(s) "Enhancing Your Apple II, Vols I & 2":

"Check into the top thirty Apple programs used today and guess what? At this writing, thirty out of thirty are written wholly, or at least partly, in machine language!

"So, while BASIC language people are busy foisting computer literacy off onto the unwashed masses, and while Pascal people are stuffily trying to salvage what few shards that remain of the once mighty computer science theocracy, and while FORTH people are out acting like spoiled brats... while all this is happening...

"Machine-Language programmers are laughing to themselves all the way to the bank!

"The evidence is in and it is overwhelming. Cash on the line. If you want to write a classic program or a best selling program, it must be done wholly, or in part, in machine language.

Page 16, Column 1

"Why? Because machine language is far and away the fastest running, the most compact, the most flexible, the most versatile, and the one and only language that most fully utilizes all of the Apple's resources."

Hal, Don does not subscribe to our rag - in fact, he once read it (about 18 months ago) and did not like it, according to a DTACK board owner who was visited by Don. it seems (seemed) that we are too opinionated and brash. (An aside to our other readers - not one bit of the above is made up, honest!) Incidentally, Hal C. is with Micro Technology Unlimited (MTU) and is a noted authority on computer music. - FNE

P.S. Hal, if you persist in misspelling "ELOI", we will drop the "lain" and substitute "pot"!

"Although I find your issues informative, I find them less so than earlier issues. I would like to see your newsletter contain more information about your products and less about other people's products." Eugene S., Cherry Hill NJ

Eugene, we are sending you our Information Pack, which contains the information you are looking for. You realize that lots of folks hold opposing views, in that they perceive this rag as one long ad for Digital Acoustics? One such person happens to be the president of Digital Acoustics, who subsidizes this rag because of its value as an advertisement. If we spend more time lately discussing other's products it is because there are now more 68000 products from others to discuss - something which was not true a year ago.

Of course, we COULD restrict our coverage to those companies which sell the 68000/16081 combination...

(Actually we would LOVE to have more info about Pinnacle and Dimension and Sir Clive's new toy. Mack you will be able to read about elsewhere.)

"In issue #26, Benchmarks revisited, your comments about the precision of IBM's single precision number cruncher are valid. I am currently writing an air to air dogfight simulation in FORTRAN on an IBM 3081. During the simulation a variable is initially set equal to zero; the variable is then incremented by 0.01 2000 times yielding 19.997. My much maligned Apple gives better results!

"Halgol is beginning to appear like a useful language (local and global variables and a screen editor, too!)." Douglas F., Lafitte, LA

Hope you enjoy the HALGOL stuff this issue (there's sure enough of it!) - FNE

Page 16, Column 2

"Loathe to be an object of ridicule, I have often hesitated to write to you in the past. I have very much enjoyed your firmly held and entertainingly conveyed convictions, however; and I thank you for the occasional reference you have made to my published works.

"I now, therefore, break my silence to send you a copy of "Real Programmers Don't Write Pascal", from issue #11 of USUS News and Report. Basset is almost as entertaining as you, I think, although he clearly has different biases.

"Ever cautious, I remain your devoted reader," A. Nony Nony (postmarked Marina del Rey CA)

"P.S. The postmark, naturally, bears little relation to my mailing address. "

A truly devoted reader would have noticed our story about 'Real Programmers Don't Write PASCAL' on page 13 of issue #23. Besides, unless you are employed by Mini-Micro Systems magazine, your fears are unjustified. Most of the authors we write about are darned worthy - FNE

"It is with some trepidation that I broach the following with the bludgeon-tongued FNE, but fools rush in...

"I enjoyed your discussion of collective pronouns as related to corporations, (Issue #27, p16). But, if you can be so caring about the mother-tongue would you please stop missusing "hopefully", see, e.g: Issue #26, p6 (I recall several other instances of this offense against grammar, but, since you have the word processor with the "find" button and the text on file, I leave further searches to you). "Hopefully" describes the feelings with which the activity is being performed, not its desired outcome. It means filled with hope. Thus, your sentence should read

'So we go into the log/exp pair (hopefully) using our original integer.'

"should have read

'So we go into the log/exp pair using (we hope) our original integer.'

"because we do not care whether we are using our original integer hopefully, frugally, passionately or incontinently... all we hope for is that the integer is still being used, regardless of its (or our) mood.

"I am sure you have gone into this in earlier newsletters (I started with #19), but a number of us chose S-100 CP/M systems over Apples because they do

Page 17, Column 1

not tie us down to any specific manufacturer. You have discussed running your boards on Commodores, IBMs and, of course, Apples. May we hold any hope for an S-100 version?" Ivan S., Berkeley CA

Ivan, you are probably aware that William Safire is the reigning arbiter in these matters, T. H. White having reached emeritus status. While Safire is vastly more qualified than us as a writer, we understand that he does not know a whole lot about high performance microprocessors. While we are sure that your argument is correct, we only semi-follow it. It seems very likely that we will continue to make that mistake, and others, in the future.

Jack H. and friend already have a DTACK board hooked up to an S-100 board in NJ and Earl R. and friend are working on a similar project in CA. (It seems to take one hardware type and one software type to do the job.) We do not know what the commercial intentions of these folks are. Eric L. across the big creek has adapted the DTACK board to an OSI and intends to sell the necessary hardware and software, details to be printed here when he is ready. By the way, 'missusing' is correctly spelled 'misusing' - FNE

"Dear Eloi: Please send me (gasp!) a full gallon. Still under $2,000, right? I own an Apple II+ with two disk drives, etc. Regards," Carol Ann E., Newark DE

Carol Ann, we somehow feel that you are not regarding our little endeavor with the respect which it richly deserves. If you had not enclosed a check in the amount of $1995 our feelings would have been hurt badly - FNE

"...(we) use Corvus Concepts here at Hughes Aircraft. Wish they would sell ram disks, Grandes and/or floating point processors like yours. Or, better yet, array processors. I hope to encourage them to ask about the possibility." H. Burt W., Orange CA

H. Burt, you aren't going to believe this but a guy just bought a Grande cum math board to use with a Concept, and we understand he has it working! We hope he'll write and tell us what he is up to (assuming the application is not proprietary) - FNE

'LET' PROGRAM STRUCTURE:

The 'LET' program structure is the action address for LET, denoted <LET>, followed by two links, followed by the bytewise crunched code which ends on an even word (either one or two $00s are at the end as needed), followed by the HALGOL primitives which perform the indicated function.

Page 17, Column 2

The first link points past the crunched code to the HALGOL action primitives. The second link points past the HALGOL action primitives to the next HALGOL (non-primitive) line. The content of each link is always even, and the size of its parm filed LESS the link itself. If the first link is $001A, that means its parm field is the second link (2 bytes) and the crunched code (24 bytes). #2 + $24 = $1A. If the second link is $0034, then its parm field is the crunched code (24 bytes) and the HALGOL primitives (28 bytes or 14 words). #24 + #28 = #52 or $34.

In the case of the two links following the <LET> action address, their parm field is the amount of code to skip at the appropriate time. At run time the first link is used to skip the second link and the crunched code, when editing the second link finds the next HALGOL line, and when listing the crunched code is always located behind the two links and is terminated by one or two nulls ($00).

Here is the example program found on the second page overleaf in detail:

     $3E68    <LET> 
     $001A   [LINK1] 
     $0034   [LINK2] 
     $0100      A 
     $9A        = 
     $82        - 
     $88        ( 
     $0101      B 
     $83        * 
     $8D       LOG( 
     $0300      1 
     $82        - 
     $0102      C 
     $84        / 
     $0103      D 
     $87        ) 
     $81        + 
     $0301     347 
     $87        ) 
     $0000    (END) 
     $2222   <LOADV> 
     $0010     [C] 
     $21C6    <DIVV> 
     $0018     [D] 
     $2260  <REVSUBC> 
     $0000     [1] 
     $2374    <LOG> 
     $21BA   <MULTV> 
     $0008     [B] 
     $2242   <ADDC> 
     $0008    [347] 
     $21A6    <CHS> 
     $2232  <STOREV> 
     $0000     [A]

Page 18, Column 1

(In crunched code, named variables start with $01 or $02, constants with $03 to $04. $01 and $03 can identify the first 256 variables and constants, respectively.)

DEBUG/DEMO FACILITY:

We built some stuff in for debugging purposes that is getting left in for demo purposes - for a while. Since this stuff is invoked as commands, we needed to provide unusual names that would not be entered by mistake, yet short enough not to be time-consuming. So we use the command 'MURKX', where X (for now) is a digit 1 thru 4, to invoke a debug facility that would not normally be present, and 'MUMPX' to kill that debug facility. For now, all of the MURK commands are related to the LET statement (for now the most complex HALGOL function).

'MURK1' will provide a hexprint of the crunched code, followed by the double-crunched code and the variable types (bytes) and the variable offsets (words). "A" on the next page is an example of the printout provided by 'MURK1'. To turn off this facility, enter the command 'MUMP1'.

'MURK2' will provide a hexprint of the crunched code, followed by the byte-wise compiled code for the right-hand side of the expression. "B" on the next page is an example of the printout provided by 'MURK2'. 'MUMP2' turns this off.

'MURK3' provides a named listing of the compiled and optimized equation. Keep in mind that the meaning of the non-commutative operations 'SUB' and 'DIV' are reversed from the old programmable HALGOL primitives, which were designed to be compatible with programmable calculators. In other words, 'DIV WIDTH' means, in a compiled 'LET' statement, that the floating point accumulator is divided by the value of the named variable 'WIDTH'. On the other hand, 'REVDIV WIDTH' means that the floating point accumulator is divided into the value of the named variable 'WIDTH'. "C" on the next page is an example of the printout provided by 'MURK3'. 'MUMP3' turns this off.

'MURK4' turns off the post-compilation optimization. With this demo facility invoked, perfectly usable code that is longer and a little slower will be generated. If 'MURK4' is used in conjunction with 'MURK3' a printout can be obtained of the unoptimized compiled code. "D" on the next page is an example. 'MUMP4' turns this feature off.

All of the printout generated by 'MURK' 1-4 is directed to the device selected for print. The command 'SELECT PRINT 1' will direct this output to the printer in slot 1, which is how we got the hard-copy printouts on the next page.

Page 18, Column 2

TRANSPORTABLE HALGOL:

A long while back we mentioned that there would have to be a mechanism to transport a HALGOL program from one version of HALGOL to the next. Since the HALGOL program is mostly a bunch of threaded action addresses, which are listed and edited using links located just behind those action addresses, there is an obvious problem. If the next version of HALGOL has action addresses even slightly different then old HALGOL programs would not run.

We thought about this problem during lunch a couple of weeks back, and came up with an idea. All of the HALGOL commands are subroutines, ending in RTS instead of JMP (A4) as run-time HALGOL functions do. So it is trivially easy to call LIST as a subroutine. Now, if we change the address of LISTER, which determines the listing device, we can LIST the program text into high memory and keep track of the character count.

Then, all we have to do if there is no regular program in memory (easily achieved using NEW or CLEAR) we can cheat and change the address of the GETCHR routine in the screen editor to fetch a character of that text, decrementing the character counter with each character fetched. So the screen editor happily thinks there is a very fast typist at the keyboard and recompiles each line as soon as the $8D (carriage return) char is detected. The result is that the program is recompiled at a speed which is limited by the ability of the 6502 to scroll the screen. (Since the screen editor thinks somebody is typing, the "typed input" is echoed to the screen. )

We thought of this during lunch, and we had it working by 2:30 PM. The code in its original form is on the back page of this issue. We needed names for the two commands, so we used CLIST and CINPUT (for no particular reason). If you will glance at the back page, CLIST saves the listing device, replaces with a new one (subroutine SUBCLIST, located just below CLIST), clears the byte count, calls the HALGOL command LIST, restores the original listing device, and that's it, folks, we're done. With only a 90-line program, it is not possible to distinguish any delay after the command CLIST is entered until the cursor is back and we are ready for the next command.

CINPUT works pretty much the same way - check the count, save the old keyboard address, substitute as the "keyboard" the address of subroutine "SUBCINPUT", set up the start of text in the text pointer, and that's it! Now that very fast typist is in charge, and the program is "re-entered" very swiftly. When the character count reaches zero, the original keyboard subroutine address is replaced, and the chemical computer is back in charge.

Page 19

 EXAMPLE "A" 

 10 LET A=-(B*LOG(1-C/D)+347) 

 3E68 001A 0018 0100 9A82 8801 0183 8D03  (<LET> followed by 
 0082 0102 8401 0387 8103 0187 0000 XXXX   two links, then 
 XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX   crunched code) 

 019A 8288 0283 8D03 8204 8405 8781 0687  (doubly-crunched 
 00XX XXXX XXXX XXXX XXXX XXXX XXXX XXXX   code) 

 0000 0100 0001 XXXX XXXX XXXX XXXX XXXX  (F.P. value types) 

 0000 0008 0000 0010 0018 0008 XXXX XXXX  (F.P. offsets) 

 
 EXAMPLE "B" 

 10 LET A=-(B*LOG(1-C/D)+347) 

 019A 827C 0083 7D81 0687 0005 8781 0687  (doubly-crunched 
 00XX XXXX XXXX XXXX XXXX XXXX XXXX XXXX   code again) 

 9A04 8405 8603 8D83 0281 0680 00XX XXXX  (compiled and 
                                           optimized HALGOL 
                                           byte-primitives 

 EXAMPLE "C" 

 10 LET A=-(B*LOG(1-C/D)+347) 

   LOAD   C                      (interpreted printout of 
   DIV    D                       compiled and optimized 
   REVSUB 1                       HALGOL byte-primitives 
   LOG                            which evaluate the right- 
   MULT   B                       hand side of the equation) 
   ADD    347 
   CHS 

 
 EXAMPLE "D" 

 10 LET A=-(B*LOG(1-C/D)+347) 

   LOAD   1                      (interpreted printout of 
   STORE  TREGO                   compiled but unoptimized 
   LOAD   C                       HALGOL byte-primitives 
   DIV    D                       which evaluate the right- 
   REYSUB TREGO                   hand side of the equation) 
   LOG 
   STORE  TREG2 
   LOAD   B 
   MULT   TREG2 
   ADD    347 
   STORE  TREG3 
   LOAD   TREG3 
   CHS

(We cheated and entered this page by hand for a dark printout)

Page 20, Column 1

Here is the trick - we can load, say, HALGOL v.X, load a program and CLIST it. Now we load HALGOL v.X+1 and execute CINPUT. The program is now re-compiled using the NEW action addresses, and can be saved to disk!

Not only that, but if the RENUM command is re-written with (optional) parms, we have the ability to append programs - something that can't be done with Applesoft as we understand it. Just load one of the two program modules and RENUM it (to the front or back of the line address range - it does not matter which of the two modules is renumbered first.) Then load the next program, renumber it to a non-conflicting line number range, and execute CINPUT. The original program will be added to the most recent! (This works as this is being written.)

We were very pleased to get a couple of essential items done and out of the way. This left us with the problem of 'garbage collection' in the HALGOL program tables.

FNE = SHEER GENIUS!

The second morning after getting CLIST and CINPUT working - in two hours, remember - we sat over breakfast coffee and gave thoughtful consideration to the problem of 'garbage collection'. Here is the problem: for our very first program line, we key:

     10 INPUT A

Then we change our mind and, using the screen editor, change that line to:

     10 INPUT X

Here we have only the first line of our program and already we have collected some garbage. The variable name A is still in the variable name table and in the variable value table. Why don't we check all the other lines to see if there is an A? The 68000 is fast, but not fast enough to re-compile a program that might be 2,000 lines on each program line entry.

There are lots of other ways garbage can be picked up: in the label tables, in the constant name tables and the constant value tables - lots of places. We poured another cup of coffee and gave the matter some more thought. And the more we thought about it, the more complex the problem seemed. After about 2 1/2 hours of this, we gave up for the time being and decided to go to work. We walked out to the car, opened the door, lifted our right foot - and froze!

CLIST. NEW. CINPUT. What garbage? We had already solved the garbage collection problem TWO DAYS AGO! #@%&*%(#$! Boy, what a genius! Anybody out there got some smart pills to spare?

Page 20, Column 2

THE IDIOT SYSTEMS JERKS:

(If you do not sense that we are just a tad angry, we are not writing this one correctly.)

A major story beginning on the front page of Electronic News, Feb. 6 tells about the realignment of T.I. management as J. Fred Bucy moves up to CEO and Mark Shepard plans to first retire to the board of directors and then to retire, period. It turns out that all of the folks moving up come from the "equipment" side of T.I. and NONE from the integrated circuit or "chip" side.

It turns out that this has been going on for years. Once a T.I. chip person reaches the division-manager level, he NEVER gets promoted further. This fact is well-recognized both in and outside of T.I. with the result that the T.I. chip division is a fertile training-ground for executives of other companies. The article in EN mentions by name Clough, Ritchie, Tombs, Haberecht, Brooks, Carnell, Chang and Moyers: all executives who moved up through the chip ranks and then O - U - T out! It seems the chip folks are not held in high regard by top-level management in T.I.

Why? As the EN story points out:

"On the other hand, the performance of the semiconductor operations in recent years, epitomized by the loss of the mainstream microprocessor market to Intel and Motorola, has been the source of anguish to the T.I. heirarchy. Most of the sales in semiconductors at T.I. have come from relatively mature products..." For "relatively mature products" read: "low technology."

OF COURSE T.I.'s chip factory is stuck with low technology! That's because the idiot systems jerks have been standing on the throat of the chip-making division since 1973, making absolutely certain that the chip division didn't do anything to obsolete the system's folks 990-series controller (they claimed it was a minicomputer) or any of the software the idiot systems jerks had developed for that controller! As a result, T.I.'s chip folks WERE NOT PERMITTED to make a microprocessor! They were forced to develop that dumb 9900 and that dumber 99000 instead! (We wrote about this in more detail almost 2 1/2 years ago, on pages 13 and 14 of issue #4. If you do not have issue #4, send a S.A.S.E. to "systems jerks" c/o DTACK GROUNDED and we will send you a reprint.)

Having cut the legs off the chip makers, the idiot systems jerks who run T.I. are now "promoting them O - U - T out" because they cannot run fast! Look, the chip makers, even with the systems-imposed handicaps, were the ones who saved T.I.'s fanny as the idiot

Page 21, Column 1

systems jerks poured $700 million into a rathole called the 99/4A! So now the idiot systems jerks are the ones being promoted to higher management? Having long-since reached their level of incompetence, they are being promoted so that they can exercise even more incompetency!

(The story in EN focuses on "equipment" types moving up, not systems types. We don't think there is a distinction any longer, especially in a company like T.I. With microprocessors (plural) in cars, microwave ovens and even alarm clocks, how do we separate equipment from systems?)

This is not the first time we have vented some spleen against the idiot systems jerks. Intel's lead oven Motorola despite Motorola's obvious technical superiority can be directly attributed to Motorola's idiot systems jerks deliberately withholding the 68000 from its major marketplace for two years. As Nat Semi is rediscovering, you cannot give away two years leadtime in a fast-moving marketplace like microprocessors without paying a sizable penalty.

(THEY-NEVER-LEARN DEPT: Motorola has decided to do everything in its power to keep people from learning that the 68000 ALREADY HAS hardware floating point support, preferring to make its customers wait two or three years until the 68881 reaches production status. The Intel sales managers are cackling with glee as a result, and the Intel microprocessor sales types (they prefer "applications engineers") are clubbing the poor Motorola sales types over the head with their 8087. And Intel is selling [well, booking] more microprocessors than they can make! Sigh.)

We would recommend that all idiot systems jerks be led into the street and shot except for one little problem: that dingus pictured on the front page of this issue is a SYSTEM, and we are partly responsible for it! So much for consistency.

HALGOL FOR - NEXT:

     FOR I = 1 TO N [STEP S]

is the familiar loop construct beloved of BASIC programmers. It's such an impressive looking construct, obviously much more important than the dinky little 'NEXT' that terminates the loop. Sure. Suppose N is 10,000. That means the complex, impressive FOR statement gets executed once and the NEXT is executed 10,000 times! Sort of like discovering that the homely girl has rich parents, isn't it?

When figuring out how to program the 'FOR' statement, it becomes quickly evident that one first figures out what the 'NEXT' statement has to do, assumes that the

Page 21, Column 2

loop parameters are placed on the loop stack in the most efficient form possible for the 'NEXT' statement, and only THEN do we program the FOR statement - to do whatever is necessary to set up the data in that most efficient way!

You probably know that 'NEXT' and 'NEXT I' perform the same function except that 'NEXT I' checks to see whether the current loop variable is really 'I' and issues an error message if it is not. So the first thing we will find on the loop stack is the offset address of the loop variable. Next we will find the 8-byte floating point step value, which is to be added to the loop varn. Next we have a flag (the step sign) to tell us which direction the comparison takes. (Are we stepping up or are we stepping down?) After that we find the 32-bit loop address, which is the address in the HALGOL program of the first HALGOL instruction past the FOR - NEXT instruction. Finally, there is the 8-byte floating point limit value. This means that each active FOR - NEXT loop eats 12 words or 24 bytes of memory.

The maximum number of active FOR - NEXT loops is determined by how much memory we want to dedicate to this purpose. Since this number is very easily changed (especially if one has access to the source code) we are going to set aside space for 10 active FOR - NEXT loops and not worry about it.

The HALGOL 'FOR - NEXT' parm stack:

     (most accessible item) 
                : 
     loop varn offset - 1 word 
     step value - 4 words 
     loop address - 2 words 
     step sign - 1 word 
     limit value - 4 words

[A confession: since 68000 stacks traditionally grow downward in memory, we have referred to the 'most accessible item' on the stack as located at the bottom of the stack. PHASE ZERO's David R. has pointed out to us that the 'most accessible item' is traditionally called the 'TOP of stack'.]

Now that we know the most efficient form of data storage for the 'NEXT' statement (which is looking prettier, no?) we know what the run-time 'FOR' code has to do. It has to place those items on the stack in the reverse order. First the limit value offset, then the loop address, then the step value offset, and then the loop varn offset. It also has to transfer the initial value to the loop varn. (We trust it is obvious that the loop address is the address of 'FOR', plus ten.) This really defines the HALGOL run-time code for 'FOR':

Page 22, Column 1

          <FOR> 
         [LIMIT] 
          [STEP] 
     [INITIAL VALUE] 
       [LOOP VARN]

First we have the action address for 'FOR'. Next we have the offset values for the limit, step, and initial value. Each of these can be a constant or a variable. That means we actually have eight differing action addresses for 'FOR', depending on the particular combination of constants or variables. (Lazy programmers would use just one address and let the code interpret which offset is which. That takes time, and we want HALGOL to run FAST - and we are not lazy programmers!)

The 'NEXT' action code is simple: we have only two action addresses, one of which is followed by the offset of the loop variable.

Ah! But what if the optional step parameter is left off, you ask? Then we still have a step - it just happens to be the constant whose name is "1" and whose value in hex is $1001 8000 0000 0000. And since the program might not otherwise contain that particular constant, a 'CLEAR' or 'NEW' has to store that constant name in the constant name table and that value in the constant value table. And our HALGOL 'FOR' code is always five words whether the 'STEP' parameter is specified or not!

HALGOL STATUS REPORT:

This is being written on the evening of Feb 9. The 'LET' statement, definitely the most complex HALGOL function yet implemented, appears to be working correctly. We believe that we fixed the last bugs in the 'IF' statement as presently implemented this afternoon before leaving work. "As presently implemented" means that only the GOTO and GOSUB functions for the true and false portions of the code are presently implemented because we have just, a couple of days ago, gotten the 'LET' function to work - so we have not had time to incorporate a conditional 'LET' statement into the 'IF' statement.

As you can see by the above, we have a pretty good handle on the FOR - NEXT construct. In about a week we should have the FOR - NEXT construct working. It is MUCH simpler than the 'LET' or even the 'IF" function. Allow another week to incorporate the conditional 'LET' into the 'IF' function (unless we decide to downgrade its priority).

The 'LET' statement is actually quite complex due to the requirement that it be both interactive and compiled, and not only compiled but substantially

Page 22, Column 2

optimized. We suspect that the code is not FULLY optimized - we know for a fact that you can happily multiply all day long by the constant 1 (ONE) if that is what tickles your fancy - but dozens of spot checks of medium-complex expressions suggest that the optimization is 95% to 99% effective. There is some stuff that we reject that some BASICs will accept. For instance,

     LET A = B/-C

will give a syntax error in HALGOL. We do not apologize for this; that is an UGLY expression! One of the nice things about writing your own language is that you do not have to permit ugly expressions if you don't want to.

Unless you know something we don't, we are almost done doing whatever can be done with simple numeric variables. We have INPUT and PRINT working, not as many varieties as some would like but enough to be useful. VTAB and HTAB work. You can direct print and list to other devices as HALGOL commands but not as programmable functions; that will have to be given some priority. We have some HIRES graphics functions implemented as far as compilation and listing is concerned - HPLOT X1,Y1 TO X2, Y2 is one - but we have artificially blocked these off because the run-time code has not yet been incorporated. Those of you who have been following DTACK, or who own boards, know that we know how to do graphics on the Apple HIRES screen from the 68000.

It may appear that we are making progress swiftly - at least we hope that is your perception. There are two reasons for this. One: until one reaches a certain point, nothing seems to be happening. In fact, during 1983 a lot of work went into the screen editor, parsing the line input, etc. Most of this work was done by our resident full-time HALGOL programmer (a recent UCI computer science graduate) working mostly alone because we were too busy with hardware to work on HALGOL. The bills DO have to be paid, and HALGOL does not yet produce income for Digital Acoustics.

But we have a window of opportunity. The Nat Semi math chip is not yet quite ready for production, and that chip is featured in our future product plans, such as the array processor. We do have enough working hardware, high performance working hardware, to pay the bills for awhile. So we are now working essentially full time (about 32 hours a week) on HALGOL in addition to our regular HALGOL programmer. Things go a lot faster with the two of us working together because in combination we have both lots of assembly language programming experience and a knowledge of computer science - a combination which neither of us alone possess.

Page 23, Column 1

We have already distributed ten sample HALGOL disks to alpha sites for evaluation. We are encouraged by the response we received. We well know how rarely most folks will sit down and type or write a two-page letter helpfully pointing out bugs. In about two weeks - about when you will be reading this - we will send out a second version which will be considerably advanced over the first, which did not have LET or IF or FOR.

The progress we have made in the ten weeks that two of us have been working on the language is encouraging. We suspect that we will have a minimally functional equivalent to BASIC operational by the end of April, including strings, string arrays and numeric arrays, plus HIRES graphics. The DOS will undoubtedly be very simplistic then - but that is the version that we are going to send to every DTACK board purchaser. Free.

After that the price goes to $8,000 per CPU because this is really 68000 code, you know...

CONVERSATION OVERHEARD:

"I hear you have a new IBM PC! How do you like it?"

"I don't know yet. There's no software for it."

"No software? What are you talking about? There's got to be more software available for the PC than any other personal computer! Just look at the ads in the PC magazines! "

"Yes, but you have to BUY that software! I have hundreds of programs for my Apple II and I didn't buy ONE of them! BUY software? You think I'm crazy?"

REVERSE LAUGHTER:

We have received a highly critical letter (for a change?) severely taking us to task for not revealing that the MINI-MICRO prediction of decreasing sales of single-user small computers was restricted to computers in the $6K to $25K range. The assumption is that the "high" $6K starting price would exclude most personal computers. Not so.

Individuals generally purchase personal computers out of discretionary funds using the "NEW AMERICAN WAY." First buy the CBM 64 and a cassette drive. Later discover the cassette is worthless and buy a floppy disk drive. Later discover a printer is needed. Even later buy a monitor so the family can still watch Gilligan's Island re-runs. Even later yet buy a modem. And all the while, various pieces of software are being bought.

Now ask that guy how much his CBM 64 cost and he will tell you, $197! And that, folks, is why the MINI-MICRO

Page 23, Column 2

salesmen would laugh themselves silly at the stupid personal computer folks! (With some justification.)

For some reason, it has become traditional in the personal computer field not to include the cost of the printer and software in the price of a personal computer. Our predicted price for Mackintosh did not include a printer for that reason. We will tell you that our two Eagle IIs, purchased specifically as word processors, cost us $2500 each. Does that include the printer? No. Is a word processor useful without a printer? No.

In the MINI-MICRO world of small business personal computers, the price is for a COMPLETE small computer, including all needed software (general ledger, spreadsheet, word processing, maybe communication...), a real business printer such as an NEC spinwriter with a cut sheet feeder at $3000 and either a hard disk or two high-capacity floppies. An IBM PC computer that a personal computer buyer would describe as a $2800 machine (after a $400 discount) is an $8,500 machine to MINI-MICRO types.

Look: an IBM XT at $6000 and that NEC spinwniter alone come to $9000 and we don't have any software or modems and other add-in stuff yet. A MINI-MICRO type would tell you with a straight face that you cannot touch an XT for less than $11,000 and he would be correct, from his point of view. Now that IBM's production has caught up, YOU would probably say that the XT is a $5500 machine with discount. That's a 2-1 difference! It's all in the point of view.

In fact, we know of one $37,000 personal computer sitting on a former subscriber's desk as his very own single-user computer (2 megabytes, a 10MHz 68010, a FAST 76-megabyte winchester with streaming tape cartridge backup and graphics almost as good as our VDHR board). It is, naturally, one of those very good UNIX boxes. No, the $37,000 does NOT include the printer or software - we are a typical personal computer user and we do not think to include those prices. The point is, this is a PERSONAL, single-user small computer that is priced WAY OVER THE $25,000 MINI-MICRO UPPER LIMIT!

By MINI-MICRO's standards, virtually EVERY single-user small computer sold into a business application costs over $6000. And MINI-MICRO showed that such sales DECREASED in 1983 when anyone with two brain cells to rub together knows that such sales in fact more than doubled in 1983!

Oh, yes: the irate letter-writer demanded that we reveal how much is left of a newsletter editor when all the bullshit is stripped away. Heck, everybody knows

Page 24, Column 1

HALGOL STANDARDS:

Halgol is being implemented in that manner which is compatible with the largest number of DTACK board owners and which requires the purchase of the minimum amount of extra equipment. That means vanilla HALGOL works with a 40 column screen, a simple Epson printer interface in slot 1 and an Epson printer, and of course a DTACK board in slot 2. Yes, we know some folks own complex printer interfaces which are not compatible with HALGOL - about half of the 10 original alpha sites had that problem. Another alpha tester sent us a HALGOL disk back and when we tried to run it we just got garbage all over the place - apparently his Apple has some sort of upper/lower case mod. None of ours do, so we have no idea what he sent us back.

You, sir, over there: You have a Wraggler printer interface, while that lady over there has a Himmelfarb B and the youngster across the room has an Excelsior II. We don't have any of those. We aren't going to have any of those. We aren't going to write code for any of those. Ever.

Bob P. was thoughtful enough to tell us what address in the Apple starts up his particular variety - the Wragglen, as we recall - and we remembered what he said for at least 30 seconds. Bob has forgotten how to write letters but that really doesn't matter because if he DID tell us how to program it we couldn't test it. We don't write software we can't test. Bob P. and others with non-conforming hardware have several options:

1. Forget HALGOL.
2. Buy the source code and modify the software themselves.
3. Buy a simple Epson printer interface.
4. Hope somebody else buys the source code, modifies it, and contributes the code to Digital Acoustics, which is NOT a non-profit organization. Then we might include that in an "installation program". No, we will NOT BUY the software - we don't need it.

We do believe that an 80 column display is needed. Again, there are an untold number of differing devices. The one we are considering supporting is the relatively new VIDEX board. What we would do is provide that installation program so that you could select the standard 40 column display or the new VIDEX. We do not plan to support the 80 column IIe display because it looks ugly and because we own only one IIe - which is used in test.

Page 24, Column 2

Yes, we KNOW how limited Apple's Disk IIs are, But that is what everybody has. If a good hard disk comes along we may make that an alternate selection, again via the installation program. What we are looking for here is the greatest good for the greatest number.

INFOWORLD WATCH:

We cannot understand why we get so many letters from folks thinking we are gonna lambast them with our editorial keyboard. In fact, we hardly ever say anything really bad about anybody who is not an officer of a very large company. Now, if you want to see somebody really chewed up, you can read Time magazine and see Steve Jobs get it in, um, the neck or read John Dvorak's column in Infoworld. John, the Louella Parsons of personal computerdom, has an especially harsh word for his fellow columnist Doug Clapp.

Now, it is true that the outermost limits of Doug's admiration for all things Apple cannot be detected even by Palomar's 200-inch telescope, but for John to call Doug a "bootlicker" was unkind...

WE GOT IT RIGHT!

We told you, right on the front page of the last issue, that we probably had the wrong West German as the author of that p-code FORTRAN. Well, we were right. Instead, you will have to send $40 to:

PETER SIEBERT
EINSTEINSTRASSE 186
4040 NEUSS 1
WEST GERMANY

Sorry, Peter. We really did have the flu that last week. You will have to get someone to write a review for us for your PASCAL-based FORTRAN. Please? In the meantime we will see if we can find a PASCAL/FORTRAN person at this end to test the review copy you sent us. Maybe Tom in rainyland or John in clean-skies land?

DOWN THE TUBES:

SofTech has announced that a fall-off in orders will reduce its earnings in the most recent quarter versus the same quarter a year ago ($386,000 then). Their p-system is supposedly a UNIVERSAL system (remember?), targeted at the ENTIRE personal computer market. Well, that market is doubling (or more) every year - and p-system sales are down AND SOFTECH IS LAYING OFF PERSONNEL! Lotus, with a single product just for the PC and SOME of the clones, has reported a PROFIT for that same quarter of $6.7 million! A soft-headed reader of ours claims that the UCSD p-system is becoming the de facto standard for the 68000. It is? Then why is SofTech laying off?

Page 25, Column 1

COPYRIGHT FEVER:

We stopped at a bookstall to buy a paperback novel. Dropping $2.50 plus tax on the counter top, we proceeded to walk off. Suddenly this guy rushed up behind us and grabbed our arm. "Where do you think you're going?" he demanded. Home to read this science fiction novel, we replied. Why?

"You can't do that!' he exclaimed. "You come right back here!" he ordered, half-dragging us back to the bookstall. When we arrived he reached behind the counter and whipped out a legal document. "You have to register the serial number of that novel" he asserted. Pointing at the document, he said, "Put your name and address here, your home phone number there and your work phone number right under that. Then you have to initial down here that you will not reveal the plot to anyone. Finally, you sign down here that you will not permit anyone else to read the book."

Frankly, we were a bit worried, and the guy didn't seem to want to let go of our arm. The simplest and safest solution seemed to be filling out the form, which we did. As we completed the form, the guy reached behind the counter again and pulled out some sort of label. Then he licked it and thrust it toward our face. Hey! we exclaimed, jumping back. What the heck are you doing?

"Why, I'm putting your license sticker on your forehead!" he explained. "You are not permitted to read that novel unless you have a serialized sticker on your forehead." YOU'RE NUTS! we exclaimed. We managed to wrench loose from his grasp and hurried off with our novel. "Your soul will burn in hell forever if you read that novel without an authorization sticker!" the guy shouted after us. And then we woke up.
It just so happens that the copyright notice, on ONE PAGE ONLY, is the only protection the author and publisher of that novel have or need. It also happens that the copyright law for paperback novels is the SAME law that protects software! The provisions are in no way different!

We recently bought DIVERSI-DOS and we like it. We're going to buy another copy, this time with the statement that we own DOS TOOLKIT, and see if it helps speed up the PHASE ZERO assembler. But DIVERSI-DOS comes with, you guessed it, a gummed, serialized label (actually, a rather tacky-looking Avery label). Guess what one is supposed to do with that thing. Guess what we have NOT done with that thing? We sure hope hell is air-conditioned!

Page 25, Column 2

Even some of you readers seem to be confused. Many of you have repeatedly confused making HALGOL source code available, complete with copyright notices, with placing HALGOL in the public domain. Ain't the same thing at all. We have no intention of placing HALGOL in the public domain - we have spent too much time and money developing it, and it is beginning to work much too well. All we are going to do is let anyone who has purchased a DTACK board buy the source code on unprotected floppy disks for our cost (as a tax-paying company with paid employees and overhead). At the moment it looks like that is going to be in the $40 to $50 range for about 4 disks and a manual, with shipment by UPS. (First class mail or overseas will cost more.)

Since anybody who has bought a DTACK board is licensed to own the HALGOL source code, this means anybody who buys the disks can legally give copies to any other DTACK owner. So those commie West Germans can chip in together to get the source code.

Since the disks are not copy protected, it is even possible to copy them and give them to someone who (gasp!) does NOT own a DTACK board! That would be highly illegal, of course.

Right now the source code is not so useful (so PLEASE do not send us a check yet!) but considering that we have just finished implementing the LET statement it will be likely be useful in the (near) future. There is only one catch to our making copyrighted HALGOL code available to DTACK owners: you will have to wear this serialized sticker on your forehead...

HOW TO KILL SUCCESS:

It's simple. Just copy what Commodore is up to now. Since kindly Uncle Jack left, four other top executives have jumped or were kicked. And remember, there were VERY few executives between Jack and the working stiffs. So who is in charge? This you are not going to believe. Sol Davidson is in charge. Sol joined Commodore last October after spending more than 40 (forty) years in the garment industry! Next we have the wonderful management decisions being made which are doubtlessly enormously popular in Boca Raton and in Cupertino. Let us quote from the WSJ (Jan 31) on this one:

"Commodore also has delayed the April introduction of its new 264 computer... Mr. Davidson said executives are 'reexamining' the product and will introduce it 'when there is a need for it.'

"Mr. Davidson said yesterday that Commodore still hasn't decided which programs to include, what price to charge and other details. Too low a price, he said, might hurt sales of the company's popular Commodore 64

Page 26, Column 1

computer. He said the debut (of the recently announced 264) 'could come before the end of 1984, we'll just have to watch carefully.'"

Which programs? Well, they have a spreadsheet and a word processor and a data base manager as their major items and a whole bunch of minor items. Let us tell you what Uncle Jack would have done: he would have put in all three programs and introduced the computer at $495 and later rode the price down to $345 and then $195. The 264, even with three ROMS (programs), is cheaper to make than the 64. Why? The 64 has a sprite-graphics chip and a really superior sound chip and the 264 doesn't! That's also why the 264 would not hurt 64 sales.

In any event, Uncle Jack would not have worried about impacting sales of the 64. He didn't worry about the 64 impacting the VIC-20, did he? Even when the VIC was at the height of its popularity, Jack cut the 64 price to $193 (wholesale) and dropped VICS's price under $100. Result? The VIC became even more popular than ever! And it continued to be profitable!

Why doesn't the 264 have the sprite video chip and the sound chip? Partly because Commodore literally cannot make enough. Commodore's production schedule called for 400,000 computers to roll off the production line in January - yes, computers, not combined computers and disk drives! One reason for the development of the 264 was so that Commodore could sell something without having to build more of those neat video and sound chips. Another, since the 264 is clearly aimed at business-type applications, was to cut the legs out from under IBM's PCjr.

Well, Boca Raton can rest easier. Commodore has a garment industry type deciding to hold back introduction of the 264 lest it hurt 64 sales. He is also deciding how to maximize the profit on those three major programs. In the process, the 264 is going to DIE - in terms of the kind of overwhelming success that Jack would have achieved with the same hardware.

So what has Uncle Jack decided to do about this? He has just registered with the SEC a proposed sale of a third of the $200+ million in Commodore stock he holds. In case you didn't know, when an insider (Jack is a Commodore director) decides to move some stock, it has to be preannounced by registering a public announcement with the SEC (Securities and Exchange Commission). You should ALSO know that insiders who part with a third of their stock often follow up with the sale of another third or two...

How to kill success, indeed.

Page 26, Column 2

ATTN: 68008 FANS

The Feb '84 issue of Call Apple carries a review of the Qwerty 68008 board, which is essentially the cheap, simple board that we offered to make but didn't because all of you wrote that our cheap, simple 68008 board had to have 128K DRAM and expansion capability! Well, the Qwerty has 2K RAM expandable to 8K. Read all about it starting on page 23.

Incidentally, there are a bunch of Apple-compatible 68000 boards discussed in that issue. Those of you who think we have been overlooked are wrong: right there on page 23 we find: "...it can fit completely inside your Apple (unlike certain other behemoth 68000 boards)."

CALL Apple's overlooking us might not be an accident. We just discovered that they have been carrying a bill to us in the amount of $855 since July last year. When we researched the matter we discovered that our ex-secretary had not paid the invoice because the advertisement in question had been pre-paid (check #9642) on Mar 27 when the ad copy was sent in. It turns out the ad copy goes to a different office which is not averse to cashing checks. Hey, you guys at CALL Apple: we do not now nor did we ever owe you $855. (We often pre-pay ads because there is usually a substantial discount for such pre-payment.)

MACK: AN OPINION

Death March Dunkerson, who is not a computer person, asked us to explain what Mackintosh was like. Here is what we said: If Mack were an automobile, it would be among the most comfortable, luxurious and beautifully styled automobiles available - truly a magnificent vehicle. The one flaw of this vehicle is that it will only travel north. If you happen to be headed north, Mack is superb. If you are headed in another direction, you have big problems.

UN-BUSTED BASIC:

Microsoft has announced Mackintosh BASIC, which is to be available this summer. InfoWorld (the Mackintosh issue, page 17) reports that "It runs ten times faster than Microsoft BASIC on the IBM PC and is incrementally compiled. This means that every time the user types a line of code and presses Return, the code is compiled into a pseudocode to run faster." Gee! What a neat idea! Why didn't we think of that ourselves?

An unbusted Microsoft 68000 BASIC? Has IBM announced a 68000-based product lately?

You may recall that we use our two Eagle IIs exclusively for word processing because they do not

Page 27, Column 1

come with an interpretive BASIC. Well, Microsoft offers just such a Z80 BASIC which will run under the CP/M operating system provided with the Eagle II. Why don't we use it? It costs (choke) $350 per copy! We wonder how much Mackintosh BASIC will cost? (Microsoft has asserted that HALF of its dollar volume in 1984 will come from Mackintosh-related software sales! IBM's gonna sell 2.5 million PCs in 1984, too. Hmmm... We, of course, believe everything we read.)

MYSTERY MANIA:

Will the real Mack please stand up? The promotional brochure for Mack speaks proudly of Mack BASIC, but none of the Apple dealers speak of such. The only 68000 BASIC Apple has, to our knowledge, is the severely busted BASIC (busted by being written in PASCAL) that Microsoft delivered to Apple, for LISA, in June 1982. This BASIC is such a turkey that Apple has hidden it - you have to pay $750 for a "programmer's kit" to get that BASIC for LISA. The new, unbusted BASIC ain't here yet and won't be for a while. (All software which is advertised as available in six months really arrives on schedule six months later, right?)

NOSTRADAMUS II:

We trust that each of you has noticed that we scored a direct hit on our prediction of Mack's price. We specified two disk drives, four or five application software packages AND a BASIC. Ron Jeffries, who is a competing newsletter writer, was even nice enough to call us and congratulate us. Thanks, Ron.

But even we were surprised at the speed with which our prediction of a LISA with a list price under $5000 came true. That prediction, like the Mack prediction, was written earlier in the month. It's true that there were rumors of LISA II beginning to circulate before we mailed the last newsletter.

Apple sent - or planned to send - three Macks to each Apple dealer; two for sale and one for show. That means they managed to scrape up about 5000 Sony microfloppies. Because they did not place the purchase order for large production quantities with Sony until last November (we told you this last issue - remember?) true production quantities of Mack will not begin rolling off the line for another six to eight weeks, meaning you won't see more Macks until about the first of March. At leat, that's the optimistic delivery schedule that one Apple dealer was given.

You do recall that everybody else was saying that Apple had learned its lesson about having product ready to go on announcement and WE said BS, delivery of Mack is gonna be real late, don't you?

Page 27, Column 2

EVERYBODY MAKES MISTEACKS:

We do our own proofreading, mostly in the last week before we go to press. Well, we came down with the flu in the last week of the last issue and there were more typos than usual. But we plain goofed when we asserted, on the front page yet, that Mike Markulla resigned at Apple just after Apple reached $1 billion in sales. Actually, he resigned just after Apple made the Fortune 500. Meantime Ron Jeffries asserted that Commodore became the first personal computer company to reach $1 billion in annual sales. In fact, Apple and Commodore became the "first" company to reach $1 billion in sales for four consecutive quarters SIMULTANEOUSLY, at the end of the 4th quarter '83. Neither has reached $1 billion in a corporate fiscal year yet - Commodore's fiscal year ends June 30 while Apple's ends Sept 30. That means that Commodore is a cinch to become the first personal computer outfit to reach $1 billion in sales in a company fiscal year, and Apple will be the second three months later. Verstad?

When we heard that LISA had a 5MHz clock we naturally assumed that what that really meant was that it really had an 8MHz clock which was time-shared with the video memory - Apple's usual cheap but time-consuming method of refreshing the DRAMS. Four wait states on an 8MHz 68000 results in an effective 4.8MHz clock, close enough to 5MHz. Wrong! LISA has a 5MHz clock which it time-shares.

(Under "OOPS!" on the front page of last issue we mis-reported that a letter written by Ulrich Schmidt was written instead by Thomas Wieland. Well, we TOLD you we had the flu. And it WAS the OOPS! dept.)

THE THIRD (OR FOURTH)

largest computer company in the world is in the process of filing Chapter 11, voluntary bankruptcy. It seems Victor owes various folks $110 million. Well, look at the good side: last May a share in Victor Technologies would have cost you $22. This morning (7 Feb) you can buy a share for $20.75 less!

SCULLEY MEN WATCH:

Apparently some of the new 'Scully men' at Apple Computer aren't working out. We told you about John Cavalier being hired as Personal Computer division vice-president and general manager. We assumed at the time that a headhunting outfit had brought Cavalier to Scully's attention. Well, Cavalier doesn't have that job anymore and in fact has been shunted aside to an "offshore sales and marketing post." (EN 6 Feb p.23) He is now in complete charge of Apple Computer sales in Borneo, Sumatra and New Guinea. We suspect he will be more watchful for headhunters this time...

Page 28, Column 1

THE OLD AND THE NEW:

Most of the original crowd are still whooping it up on the UNIX bandwagon. This crowd can really get whipped into a frenzy by a new product announcement, such as IBM's release of yet another UNIX clone. For some reason, they never bother counting end users (after all, it wouldn't take long!). What gets us is that none of them have noticed that their bandwagon has not moved an inch since they climbed on board.

We politely suggest that you will not wish to be the last to notice the NEWEST bandwagon. Mitch Kapor is driving, Mack's 64K ROM is riding shotgun and LISA II is just now climbing aboard. A chap named Sir Clive is sitting quietly in back, and Bill Gates is chasing it furiously down the street, grasping a 64-pin integrated circuit firmly in hand. The shadowy figure slinking into an alley is Carl Helmers, who is no longer telling folks that it's O.K. to write an operating system in p-code. No, the new bandwagon is not painted green, it's just that there is so much money...

Yes, folks, there really IS a brand-new bandwagon in town, and it really IS an assembly language bandwagon, and it really IS moving, aided by that most effective of all lubricants - money! Now, will all of you please stop calling us and writing us to point out that Mack's 64K ROM is entirely written in lovingly hand-tweaked assembly? We know that!

It's really too bad that we did not spot this bandwagon earlier. (Please excuse us for one moment. %#@*&(!*#@$! There! We feel better now...)

[Since we wrote the above we have bounced that theory off some other folks, especially folks whom we would expect to be opposed. To our astonishment, we detected various stages of agreement. An example: a long-time C and UNIX fan who is in the software business listened and sort of grunted, not really agreeing or disagreeing. We chatted about some other things and then he asked, "Have you bought an IBM PC yet?" When we replied no, he said: "That's too bad. We are just releasing a program editor for the PC that is the best and the fastest program editor I have ever seen. It was really developed as a by-product of another project. The thing is written entirely in assembly language and honestly, I have never seen an editor like it!"]

SPLITSVILLE?

Is the long-established romance between Microsoft and IBM breaking up? IBM chose a UNIX clone that was NOT XENIX. Bill Gates announces a 68000 BASIC which is NOT busted to protect BIG BLUE. He also announces that half of Microsoft's dollar income in 1984 will come

Page 28, Column 2

from Mackintosh-related sales. Look, folks, when Bill said that he was either drunk, kidding, or trying hard to get himself committed. There is absolutely no possible way that Bill - and Mack - can pull that off. (Bill was NOT the source of that ridiculous assertion that Microsoft was going to sell $3 BILLION in XENIX licenses in 1983.)

Observers - that's us and some other folks sitting around the cracker barrel - think that IBM is trying to break completely away from Microsoft. Most of those observers think that IBM will have trouble pulling that off, on account of the mass-market customers AIN'T gonna give up MS-DOS for either a UNIX clone or for CMS or for whatever they call the 370 operating system these days (OS/370 ?). Some of you probably have not followed BIG BLUE in the past and so do not know that IBM tried to break away from an established software standard (anything related to the 360) once before and was confronted by MASSIVE consumer resistance. Consumer, in this case, refers to the dp managers responsible for recommending what mainframe to buy/ upgrade to. IBM had to back down. If they try to completely cut off Microsoft, we predict that they will be confronted by exactly that sort of massive resistance again.

(This is not startling stuff; all the folks sitting around that barrel seem to be in agreement on this matter.)

PERMISSION TO COPY:

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, SOS, ProDOS, LISA, Mackintosh?: Apple Computer Co. Anybody else need a 174th million ack, have your legal beagles send us the usual threat.

SUBSCRIPTIONS: Beginning with issue #19, 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. The address is:

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

As the son slinks sowly in the east, we - OOPS - oh, yes, REDALANDS: REDALANDS this moth consorts of the brillig code what we tolde you aboat their on the lost page. All the other pages are the optimization code for the LET compiler.

Page 29

                         2          LIST 
                         3 ; THE FOLLOWING ARE LEGAL MATHOPS FOR THE 
                         4 ; NEXT OPTIMIZATION PASSES: 
                         5 ; 
                         6 ;    $81 = <ADD> 
                         7 ;    $82 = <SUB> 
                         8 ;    $83 = <MULT> 
                         9 ;    $84 = <DIV> 
                        10 ;    $85 = <^> 
                        11 ;    $86 = <REVSUB> 
                        12 ;    $87 = <REVDIV> 
                        13 ;    $88 = <REV^> 
                        14 ; 
                        15 ; WARNING:  THE NON-COMMUTATIVE MATH OPS 
                        16 ; (E.G. SUB) OPERATE IN THE REVERSE MANNER 
                        17 ; THAN IN THE PROGRAMMABLE HALGOL PRIMITIVES. 
                        18 ; 
                        19 ; THAT IS IRRELEVANT TO THE HALGOL PROGRAMMER 
                        20 ; SINCE THE COMPILATION PROCESS IS INVISIBLE, 
                        21 ; BUT KEEP IT IN MIND WHEN READING THIS 
                        22 ; SOURCE CODE! 
                        23 ; 
                        24 ;-------------------------------------------- 
                        25 ; 
                        26 ; ELIMINATE STORE - LOAD PAIRS OF THE FORM: 
                        27 ;    <STORE> (TEMPREGX) 
                        28 ;    <LOAD>  (TEMPREGX) 
                        29 ; 
                        30 ; A4 = START OF COMPILED PRIMITIVES 
                        31 ; A5 = POINTER PAST END OF PRIMITIVES 
                        32 ; 
 007654: 4215           33 L4500    CLR.B   (A5)           ;MARK END OF CODE 
 007656: 4EF8           34          DC.W    $4EF8          ;JMP $AAAA 
 007658: 765A           35 CLET10   DC.W    L4505          ;(NEXT LINE) 
 00765A: 48E7FFF0       36 L4505    MOVEM.L D0-D7/A0-A3,-(A7)  ;SAVE REGS 
                        37 ; 
 00765E: 304C           38 L4510    MOVE.W  A4,A0          ;PRT TO START 
 007660: 7A9A           39          MOVEQ   #$9A,D5        ;D5 = <LOAD> 
 007662: 7C9B           40          MOVEQ   #$9B,D6        ;D6 = <STORE> 
 007664: 4A10           41 GETST    TST.B   (A0)           ;END ? 
 007666: 6728           42          BEQ     L4520          ;DONE IF END 
 007668: BC18           43          CMP.B   (A0)+,D6       ;<STORE> ? 
 00766A: 66F8           44          BNE     GETST          ;IF NOT 
                        45 ; 
 00766C: 1618           46          MOVE.B  (A0)+,D3       ;TEMPREGX TO D3 
 00766E: 6700FD64       47          BEQ     CE01           ;ERROR IF END 
                        48 ; 
 007672: 4A10           49          TST.B   (A0)           ;NEXT BYTE 
 007674: 671A           50          BEQ     L4520          ;IF END 
                        51 ; 
 007676: BA10           52          CMP.B   (A0),D5        ;<LOAD> ? 
 007678: 66EA           53          BNE     GETST          ;IF NOT 
                        54 ; 
 00767A: 5248           55          ADDQ.W  #1,A0          ;PTR PAST <LOAD> 
 00767C: B618           56          CMP.B   (A0)+,D3       ;TEMPREGX ? 
 00767E: 66E4           57          BNE     GETST          ;IF NOT 
                        58 ; 
                        59 ; ELIMINATE THE <STORE> - <LOAD> PAIR 
                        60 ; 
 007680: 6102           61          BSR     ELIMPAIR 
 007682: 60DA           62          BRA     L4510          ;ANOTHER PAIR ? 
                        63 ;

Page 30

 007684: 3248           65 ELIMPAIR MOVE.W  A0,A1          ;A0 = SOURCE 
 007686: 5949           66          SUBQ.W  #4,A1          ;A1 = DEST 
 007688: 3449           67          MOVE.W  A1,A2          ;SAVE START 
 00768A: 12D8           68 ELIMPR   MOVE.B  (A0)+,(A1)+    ;MOVE A BYTE 
 00768C: 66FC           69          BNE     ELIMPR         ;CONTINUE TO END 
 00768E: 4E75           70          RTS                    ;PAIR ELIM'D 
                        71 ; 
                        72 ; ELIMINATE LOAD - STORE PAIRS OF THE FORM: 
                        73 ;    <LOAD>   (ORIGVARN) 
                        74 ;    <STORE>  (TEMPREGX) 
                        75 ; 
                        76 ; THIS WILL BE FOLLOWED LATER BY: 
                        77 ;    <MATHOP OR LOAD> (TEMPREGX) 
                        78 ; 
                        79 ; REPLACE THIS WITH: 
                        80 ;    <MATHOP OR LOAD> (ORIGVARN) 
                        81 ; 
                        82 ; (NOTE:  THE COMPILATION PROCESS HAS ALREADY 
                        83 ; REVERSED MOST NON-COMMUTATIVE MATH OPS) 
                        84 ; 
 007690: 304C           85 L4520    MOVE.W  A4,A0          ;PRT TO START 
                        86 ; 
 007692: 4A10           87 GETLD    TST.B   (A0)           ;END ? 
 007694: 6746           88          BEQ     L4550          ;DONE IF END 
 007696: BA18           89          CMP.B   (A0)+,D5       ;<LOAD> ? 
 007698: 66F8           90          BNE     GETLD          ;IF NOT 
                        91 ; 
 00769A: 1618           92          MOVE.B  (A0)+,D3       ;ORIGVARN TO D3 
 00769C: 6700FD3C       93          BEQ     CE02           ;ERROR IF END 
                        94 ; 
 0076A0: 4A10           95          TST.B   (A0)           ;NEXT BYTE 
 0076A2: 6738           96          BEQ     L4550          ;IF END 
                        97 ; 
 0076A4: BC10           98          CMP.B   (A0),D6        ;<STORE>? 
 0076A6: 66EA           99          BNE     GETLD          ;IF NOT 
                       100 ; 
 0076A8: 5248          101          ADDQ.W  #1,A0          ;PTR PAST <STORE> 
 0076AA: 1218          102          MOVE.B  (A0)+,D1       ;TEMPREGX TO D1 
 0076AC: 6B00FD32      103          BMI     CE03           ;ERROR IF > $7F 
 0076B0: 0C010068      104          CMPI.B  #$68,D1 
 0076B4: 6500FD30      105          BCS     CE04           ;ERROR IF < $68 
                       106 ; 
                       107 ; ELIMINATE THE <LOAD> - <STORE> PAIR, THEN FIND 
                       108 ; <MATHOP OR LOAD> (TEMPREGX) AND REPLACE IT. 
                       109 ; 
 0076B8: 61CA          110          BSR     ELIMPAIR 
 0076BA: 304A          111          MOVE.W  A2,A0          ;PTR PAST PAIR 
 0076BC: 4A10          112 GETTMPRG TST.B   (A0)           ;END ? 
 0076BE: 6700FD26      113          BEQ     CE04           ;IF SO 
 0076C2: B218          114          CMP.B   (A0)+,D1       ;TEMPREGX ? 
 0076C4: 66F6          115          BNE     GETTMPRG       ;IF NOT 
                       116 ; 
 0076C6: 5548          117          SUBQ.W  #2,A0          ;PTR TO MATHOP 
 0076C8: 1410          118          MOVE.B  (A0),D2        ;MATHOP TO D2 
 0076CA: B405          119          CMP.B   D5,D2          ;<LOAD> ? 
 0076CC: 6708          120          BEQ     MATHOK         ;IF SO 
                       121 ; 
 0076CE: 4EB878E6      122          JSR     LEGLMATH       ;LEGAL MATHOP ? 
 0076D2: 6700FD30      123          BEQ     CE09           ;ERROR IF NOT 
                       124 ;

Page 31

 0076D6: 10C2          126 MATHOK   MOVE.B  D2,(A0)+       ;MATHOP1 
 0076D8: 10C3          127          MOVE.B  D3,(A0)+       ;ORIGVARN 
 0076DA: 6082          128          BRA     L4510          ;ANOTHER PAIR ? 
                       129 ; 
                       130 ; LOOK FOR A LOAD - CHS - STORE TRIPLET: 
                       131 ;    <LOAD>  (ORIGVARN) 
                       132 ;    <CHS> 
                       133 ;    <STORE> (TEMPREGX) 
                       134 ; 
                       135 ; THIS WILL BE FOLLOWED LATER BY: 
                       136 ;    <MATHOP> (TEMPREGX) 
                       137 ; 
                       138 ; THE ORIGINAL TRIPLET CAN BE ELIMINATED.  THEN 
                       139 ; REPLACE THE LATER <MATHOP> (TEMPREGX) WITH: 
                       140 ; 
                       141 ; IF <ADD>,    <SUB>    (ORIGVARN) 
                       142 ; IF <REVSUB>, <ADD>    (ORIGVARN) <CHS> 
                       143 ; IF <MULT>,   <MULT>   (ORIGVARN) <CHS> 
                       144 ; IF <REVDIV>, <REVDIV> (ORIGVARN) <CHS> 
                       145 ; 
                       146 ; THE NET SAVINGS IS A LOAD-STORE PAIR AND, 
                       147 ; PERHAPS, ONE <CHS> 
                       148 ; 
 0076DC: 304C          149 L4550    MOVE.W  A4,A0          ;PTR TO START 
 0076DE: 5448          150          ADDQ.W  #2,A0          ;1ST POSS <CHS> 
 0076E0: 7880          151          MOVEQ   #$80,D4        ;<CHS> TO D4 
                       152 ; 
 0076E2: 4A10          153 GETCHS   TST.B   (A0)           ;END? 
 0076E4: 676A          154          BEQ     L4600          ;DONE IF END 
 0076E6: B818          155          CMP.B   (A0)+,D4       ;<CHS> ? 
 0076E8: 66F8          156          BNE     GETCHS         ;IF NOT 
                       157 ; 
 0076EA: 4A10          158          TST.B   (A0)           ;END ? 
 0076EC: 67000062      159          BEQ.L   L4600          ;IF SO 
 0076F0: BC18          160          CMP.B   (A0)+,D6       ;<STORE> ? 
 0076F2: 66EE          161          BNE     GETCHS         ;IF NOT 
                       162 ; 
 0076F4: 1218          163          MOVE.B  (A0)+,D1       ;TEMPREGX TO D1 
 0076F6: 3248          164          MOVE.W  A0,A1          ;SAVE 'NEXT' ADR 
 0076F8: 5B48          165          SUBQ.W  #5,A0          ;PTR TO POSS LOAD 
 0076FA: BA18          166          CMP.B   (A0)+,D5       ;<LOAD> ? 
 0076FC: 6704          167          BEQ     GOTLOAD        ;IF SO 
                       168 ; 
 0076FE: 5648          169          ADDQ.W  #3,A0          ;CORRECT THE PTR 
 007700: 60E0          170          BRA     GETCHS         ;CONTINUE SEARCH 
                       171 ; 
 007702: 1610          172 GOTLOAD  MOVE.B  (A0),D3        ;ORIGVARN TO D3 
 007704: 5348          173          SUBQ.W  #1,A0          ;START OF TRIPLET 
 007706: 3448          174          MOVE.W  A0,A2          ;SAVE START ADR 
 007708: 10D9          175 ELIMCHS  MOVE.B  (A1)+,(A0)+    ;MOVE A BYTE 
 00770A: 66FC          176          BNE     ELIMCHS        ;CONTINUE TO END 
                       177 ;

Page 32

                       179 ; NOW FIND <MATHOP> (TEMPREGX) AND REPLACE IT. 
                       180 ; 
 00770C: 304A          181          MOVE.W  A2,A0          ;SEARCH START 
 00770E: 4A10          182 FTMPREGX TST.B   (A0)           ;END ? 
 007710: 6700FCDA      183          BEQ     CE05           ;IF SO 
 007714: B218          184          CMP.B   (A0)+,D1       ;TEMPREGX ? 
 007716: 66F6          185          BNE     FTMPREGX       ;IF NOT 
                       186 ; 
 007718: 5548          187          SUBQ.W  #2,A0          ;PTR TO MATHOP 
 00771A: 1410          188          MOVE.B  (A0),D2        ;MATHOP TO D2 
 00771C: 4EB878E6      189          JSR     LEGLMATH       ;LEGAL MATHOP ? 
 007720: 6700FCD0      190          BEQ     CE06           ;IF NOT 
                       191 ; 
 007724: 0C020081      192          CMPI.B  #$81,D2        ;<ADD> ? 
 007728: 6604          193          BNE     CHS1           ;IF NOT 
                       194 ; 
 00772A: 7482          195          MOVEQ   #$82,D2        ;REPLACE W/<SUB> 
 00772C: 6008          196          BRA     CHS2           ;DONE 
                       197 ; 
 00772E: 0C020086      198 CHS1     CMPI.B  #$86,D2        ;<REVSUB> ? 
 007732: 6602          199          BNE     CHS2           ;IF NOT 
                       200 ; 
 007734: 7481          201          MOVEQ   #$81,D2        ;REPLACE W/<ADD> 
                       202 ; 
 007736: 10C2          203 CHS2     MOVE.B  D2,(A0)+       ;MATHOP1 
 007738: 10C3          204          MOVE.B  D3,(A0)+       ;ORIGVARN 
                       205 ; 
                       206 ; IF MATHOP IS NOT <SUB>, INSERT A <CHS>. 
                       207 ; 
 00773A: 0C020082      208          CMPI.B  #$82,D2        ;<SUB> ? 
 00773E: 6700FF1E      209          BEQ     L4510          ;IF SO 
                       210 ; 
 007742: 7480          211          MOVEQ   #$80,D2        ;<CHS> 
 007744: 1610          212 INSERCHS MOVE.B  (A0),D3        ;SAVE NEXT CHAR 
 007746: 10C2          213          MOVE.B  D2,(A0)+       ;REPLACE IT 
 007748: 6700FF14      214          BEQ     L4510          ;DONE IF END 
                       215 ; 
 00774C: 1403          216          MOVE.B  D3,D2          ;NEXT BYTE 
 00774E: 60F4          217          BRA     INSERCHS 
                       218 ;

Page 33

                       220 ; LOOK FOR A STORE - LOAD - VARN TRIPLET: 
                       221 ;    <STORE>  (TEMPREGX) 
                       222 ;    <LOAD>   (DIFFVARN) 
                       223 ;    <MATHOP> (TEMPREGX) 
                       224 ; 
                       225 ; WHERE <MATHOP> CAN BE ADD, SUB, REVSUB, 
                       226 ; MULT, DIV, OR REVDIV. 
                       227 ; 
                       228 ; REPLACE THE TRIPLET WITH: 
                       229 ;    <MATHOP1> (DIFFVARN) 
                       230 ; 
                       231 ; (NOTE:  THE COMPILATION PROCESS HAS ALREADY 
                       232 ; REVERSED NON-COMMUTATIVE MATH OPS IF X = 0 OR 1) 
                       233 ; 
 007750: 304C          234 L4600    MOVE.W  A4,A0          ;PTR TO START 
 007752: 4A10          235 GETST1   TST.B   (A0)           ;END ? 
 007754: 674A          236          BEQ     L4700          ;DONE IF END 
 007756: BC18          237          CMP.B   (A0)+,D6       ;<STORE> ? 
 007758: 66F8          238          BNE     GETST1         ;IF NOT 
                       239 ; 
 00775A: 1618          240          MOVE.B  (A0)+,D3       ;TEMPREGX TO D3 
 00775C: 6700FC9A      241          BEQ     CE07           ;ERROR IF END 
 007760: 4A10          242          TST.B   (A0)           ;NEXT BYTE 
 007762: 673C          243          BEQ     L4700          ;IF END 
                       244 ; 
 007764: BA10          245          CMP.B   (A0),D5        ;<LOAD> ? 
 007766: 66EA          246          BNE     GETST1         ;IF NOT 
                       247 ; 
 007768: 5248          248          ADDQ.W  #1,A0          ;PTR PAST <LOAD> 
 00776A: 4A18          249          TST.B   (A0)+          ;END ? 
 00776C: 6700FC90      250          BEQ     CE08           ;ERROR IF SO 
 007770: 1418          251          MOVE.B  (A0)+,D2       ;MAYBE MATHOP 
 007772: 672C          252          BEQ     L4700          ;DONE IF END 
 007774: B618          253          CMP.B   (A0)+,D3       ;SAME TEMPREG ? 
 007776: 6704          254          BEQ     CHKMATH        ;IF SAME 
                       255 ; 
 007778: 5548          256 NOPE     SUBQ.W  #2,A0          ;CORRECT PTR 
 00777A: 60D6          257          BRA     GETST1         ;RESUME TEST 
                       258 ; 
 00777C: 4EB878E6      259 CHKMATH  JSR     LEGLMATH       ;LEGAL MATHOP? 
 007780: 67F6          260          BEQ     NOPE           ;NOPE, NOT LEGAL 
                       261 ; 
 007782: 0C03007E      262          CMPI.B  #$7E,D3        ;0 OR 1 ? 
 007786: 6404          263          BCC     MATHOPOK       ;IF YES 
                       264 ; 
 007788: 4EB878FA      265          JSR     REVMATH        ;REVERSE MATHOPS 
 00778C: 3248          266 MATHOPOK MOVE.W  A0,A1          ;A0 = SOURCE 
 00778E: 5749          267          SUBQ.W  #3,A1          ;PTR TO DIFFVARN 
 007790: 1611          268          MOVE.B  (A1),D3        ;DIFFVARN TO D3 
 007792: 5749          269          SUBQ.W  #3,A1          ;PTR TO DEST 
 007794: 12C2          270          MOVE.B  D2,(A1)+       ;STORE MATHOP1 
 007796: 12C3          271          MOVE.B  D3,(A1)+       ;STORE DIFFVARN 
 007798: 12D8          272 ELIMTRIP MOVE.B  (A0)+,(A1)+    ;MOVE A BYTE 
 00779A: 66FC          273          BNE     ELIMTRIP       ;CONTINUE TO END 
 00779C: 6000FEC0      274          BRA     L4510          ;ANOTHER TRIPLET ? 
                       275 ; 
 0077A0: 4CDF0FFF      276 L4700    MOVEM.L (A7)+,D0-D7/A0-A3  ;RESTORE REGS

Page 34

                       126          LIST 
                       127 ;-------------------- 
                       128 ;-- COMMAND: CLIST -- 
                       129 ;-------------------- 
                       130 ; 
                       131 ; LIST A PROGRAM TO MEMORY FOR LATER RECOMPILATION 
                       132 ; 
 005E80: 2F3820B0      133 CLIST    MOVE.L  LISTER,-(A7)   ;SAVE LIST DEV 
 005E84: 21FC00005EA0  134          MOVE.L  #SUBCLIST,LISTER  ;NEW SUBR ADR 
 005E8C: 4278FFFE      135          CLR.W   LCTR           ;CLEAR COUNT 
 005E90: 31FCFFFCFFFC  136          MOVE.W  #LPTR,LPTR     ;INIT LIST PTR 
 005E96: 4EB8485C      137          JSR     LIST           ;LIST THE PROG 
 005E9A: 21DF20B0      138          MOVE.L  (A7)+,LISTER   ;RESTORE DEVICE 
 005E9E: 4E75          139          RTS 
                       140 ; 
                       141 ; SUBROUTINE;  LIST A CHAR AT A TIME TO HIMEM 
                       142 ; 
 005EA0: 2F0D          143 SUBCLIST MOVE.L  A5,-(A7)       ;SAVE A5 
 005EA2: 3A78FFFC      144          MOVE.W  LPTR,A5        ;SET PTR 
 005EA6: 1B07          145          MOVE.B  D7,-(A5)       ;STORE BYTE 
 005EA8: 31CDFFFC      146          MOVE.W  A5,LPTR        ;STORE PTR 
 005EAC: 5278FFFE      147          ADDQ.W  #1,LCTR        ;INCR CTR 
 005EB0: 2A5F          148          MOVE.L  (A7)+,A5       ;RESTORE A5 
 005EB2: 4E75          149          RTS                    ;DONE 
                       150 ; 
                       151 ;--------------------- 
                       152 ;-- COMMAND: CINPUT -- 
                       153 ;--------------------- 
                       154 ; 
                       155 ; RECOMPILE A PROGRAM LISTED TO HIGH MEMORY 
                       156 ; 
 005EB4: 3E38FFFE      157 CINPUT   MOVE.W  LCTR,D7        ;FETCH COUNT 
 005EB8: 6712          158          BEQ     CINPUTX        ;DONE IF ZERO 
                       159 ; 
 005EBA: 31F83A5A10FE  160          MOVE.W  GETKEY+2,LINK-2  ;SAVE ADR 
 005EC0: 31FC5ECE3A5A  161          MOVE.W  #SUBCINP,GETKEY+2 
 005EC6: 31FCFFFCFFFC  162          MOVE.W  #LPTR,LPTR     ;INIT PTR 
 005ECC: 4E75          163 CINPUTX  RTS                    ;DONE ! 
                       164 ; 
                       165 ; SUBROUTINE; MOVE A CHAR FROM HIMEM TO SCREDIT 
                       166 ; 
 005ECE: 3878FFFC      167 SUBCINP  MOVE.W  LPTR,A4        ;FETCH CHAR PTR 
 005ED2: 1E24          168          MOVE.B  -(A4),D7       ;FETCH BYTE 
 005ED4: 00070080      169          ORI.B   #$80,D7        ;SET BIT B7 
 005ED8: 31CCFFFC      170          MOVE.W  A4,LPTR        ;STORE CHAR PTR 
 005EDC: 5378FFFE      171          SUBQ.W  #1,LCTR        ;DECR COUNTER 
 005EE0: 6702          172          BEQ     SUBCINPX       ;DONE IF ZERO 
                       173 ; 
 005EE2: 4E75          174          RTS                    ;SUBR DONE 
                       175 ; 
 005EE4: 31F810FE3A5A  176 SUBCINPX MOVE.W  LINK-2,GETKEY+2  ;RESTORE ADR 
 005EEA: 4E75          177          RTS                    ;RECOMPILE DONE 
                       178 ;