Issue # 37 DTACK GROUNDED Newsletter - November/December 1984

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

BILLY BATSON ?

Yes, Billy Batson. Some of you may have thought we went overboard on the front page of the last issue with the 60-foot white ape and the magical acronym 'TANSTAAFL' but there really was a reason behind it. All of us have our heroes (at least, us lucky ones do) and many of those heroes are fictional or mythical. Fictional or mythical heroes tend to be acquired at a very young age.

In our youth, we were voluntarily exposed to two sets of competing heroes. One set was Achilles and Hector. Achilles was the mightiest warrior of the Greeks and Hector was his equivalent amongst the Trojans. This pair we met in a book on mythology (we suppose) found in our grandparent's bookcase during WWII.

The other pair we met in comic books at about the same time: Superman and Captain Marvel. Shortly aftmr WWII, the Superman trademark holders (Action Comics) took the Captain Marvel folks to court and won; Captain Marvel quietly passed from the comic book scene. Most of you have probably never heard of Captain Marvel. 'Most' does not include Semi-Faithful correspondent Nils D. Jr; he read the front page of the last issue and shouted 'Aha! Billy Batson!'

What we mean by 'voluntarily exposed' was, if you had tried to take that book or those comics away from us you would not have escaped unscathed.

GIRLS? BLECH!

Why Hector rather than Achilles? That has to do with our age at the time, which was about 8. Eight-year-old boys do not have a lot of use for girls, who were generally, back in those days before anybody heard of women's lib, playing with dolls. Let's explain about Superman and Captain Marvel first. Superman, as all of you know, had a girl friend named Lois Lane. Superman spent a lot of time rescuing Lois from various black-hat types. Captain Marvel did not waste time hanging

Page 1, Column 2

Incredibly slow 'SUPERMICRO', p.3. RISC vs. CISC, pp 6-7. The obscure 96-50 culture, p.10. Competition II, p. 11. The MICRO DTACK-compatible board, p.12. Static board status, p.13. Modula-2 for DTACK, p.15. Trump Card report, p.19. BLUE SKY report, p.20. Pournelle's book, p.22. Mean, mean FNE! p.23. 68020 report, p.23. Math chips, p.23. HALGOL report, p.24. REDLANDS p.24.

around girls and so spent most of his time capturing Axis spies and bank robbers and doing other useful stuff unrelated to (ugh!) girls. (How many of you know what an Axis spy was? Well, we were at war then with Germany, Japan and Italy and their alliance, equivalent to our current Nato, was called the 'Axis'.)

It gets a bit more subtle than that. What's the fun of being a kid and having a hero if you can't imagine that YOU are HIM? To be Superman, you had to be born on a distant planet that had blown up and your parents had to be dead. Add that to Superman's totally inexplicable behavior in spending so much time chasing after Lois... Captain Marvel was a very different story. When he was off duty, he did not just wear a disguise, no sir. Off duty he was a crippled newspaper-boy, probably about 12 years old at most since he didn't seem to have much time for girls either. Heck, ANYBODY could pretend to be Billy Batson, which is the proper name of that newspaper-boy.

It seems that Billy had somehow been selected by some ancient gods (did any of you see 'CLASH of the TITANS' on TV recently?), presumably because of his honest demeanor, to bear super-powers. All he had to do was invoke the magical acronym 'SHAZAM', a bolt of lightning would strike him from the sky (by way of Mount Olympus?) and he would turn into Captain Marvel! The 'S' stood for the wisdom of Solomon, 'H' for the strength of Hercules, 'Z' for something about Zeus, and 'M' for the speed of Mercury. The two 'A's we have forgotten about. About 'crippled': Billy had a bad leg, presumably due to polio, which was too damned common back then. The typical picture of Billy was of him using just the one crutch to hold himself up on the bad-leg side while the hand on the good-leg side held up the latest edition for sale to passing motorists. Oh, yes: that was before most child labor laws, too.

Hector-Achilles was pretty much the same story. In the Iliad, Achilles kills Hector - but then the victors always write the history books, right? There are some careless translations of those Greek writings closest to Homer's time (Homer was illiterate, but then all the other Greeks at that time were illiterate, too). In some of those careless translations, Achilles faces

Page 2, Column 1

Hector on foot and Hector turns and runs ('shows swift heels'). Achilles has to chase him a couple of times around the walls of Troy before catching and killing the cowardly Hector.

We are now fortunate enough to have the much more careful and authentic translations of both the Iliad and the Odyssey by one W.H.D. Rouse. Hector still gets killed, but the circumstances are quite different. But why did we personally identify with Hector rather than Achilles, who by all accounts killed Hector?

It seems that the commander-in-chief of the Greeks, one Agamemnon, pulled rank and light-fingered (so to speak) a female slave from Achilles' tent. As a result of this trivial impropriety - what was one cook or such worth? - Achilles refused to participate in the battles. (You will remember that we were about eight years old when we formed these impressions.) While Achilles sulked in his tent, the Trojans, led by Hector, scored several impressive victories both in single combat and in mass assaults - the Trojans at one point, led again by the heroic Hector, literally chased the Greeks into the sea! (Troy really existed, as the archaeologist Schliemann spectacularly proved. There is general agreement that Homer's epic describes an actual war. Whether Achilles or Hector existed as described we have some doubts about. The Greek gods? Well...)

In fact, the Greeks were pretty much losing the war. A friend of Achilles, despairing at his indifference to the suffering and defeats inflicted on his fellow Greeks by the Trojans under the brilliant leadership of Hector, decided that the only salvation for the Greeks was to kill Hector and that absent Achilles, HE (gulp) was the logical man for the job. So this guy, name of Patroclus, borrowed Achilles' armor and issued a challenge to Hector for single combat. Hector (yawn) won, as usual.

The Trojans then displayed what the Greeks called Hubris: they treated Patroclus' body shamefully. Whether it was this, or the fact that Patroclus was his best friend, or just that it was HIS armor being dragged around out there, Achilles finally felt anger sufficient to overcome his loss of a (mere) female slave and made his peace with Agamemnon. With Achilles' help the tide of battle changed. Finally came the climactic single-combat battle between Achilles and Hector!

SINGLE combat? HAH!

That business about Achilles and Hector meeting on foot is so much B.S. Peasants then fought on foot, as pikemen did in the days of mythical King Arthur or under the very real French and English kings in the age

Page 2, Column 2

of chivalry. The Trojan-war equivalent of a knight was the driver of a horse-drawn chariot who carried a spear and had a passenger (bearer) on the chariot whose job was to hand him another spear when the first one missed. The foot-fighting with swords came only after the two spears were expended.

So Hector, with the Trojans facing ultimate defeat, rode out to face the hopeless task (with only his own chariot) of facing Achilles and MANY other chariots. ("...And Achilles had signalled to his own men that no one should let fly a shot at Hector, and take his own credit away if he came in second.") Hector cast his first spear, which struck Achilles' shield but rebounded. When he turned to his bearer for his second spear, the bearer was not there! One of the many gods who favored Achilles had intervened. Hector took foot, drew sword, and attempted to fight Achilles, who was still in his chariot with two spears and his bearer. Achilles' first spear did the job, and Hector - and Troy - fell. ('Showed swift heels' indeed!)

Times change, and kids grow older and learn different values, On the front page of the last issue we paid homage not only to Billy Batson and Captain Marvel but to Melville's Mohy Dick and Captain Ahab's vengeful quest for the white whale. The famed opening line/paragraph of "Moby Dick" is "Call me Ishmael."

(Sensitive folk should skip the next two paragraphs.)

To the Superman fans out there: we call your attention to Larry Niven's paperback short story collection "All the Myriad Ways". Larry Niven is a science-fiction colleague of Jerry Pournelle's, and is better known than Jerry in the science-fiction world. "All the Myriad Ways" contains a hilarious send-up of Superman entitled "Man of Steel, Woman of Kleenex". In this story Larry points out, among other things, that Superman is a product of separate, independent evolution and hence is not human. Therefore, any sexual congress between Superman and Lois Lane would, by both civil and church law, constitute sodomy.

In the movie Flesh (not Flash) Gordon, one of the opening ('establishing') scenes shows a 1930s city with folk going about their business as a young, crippled newspaper boy braces himself on one crutch and hawks the latest edition with his other hand. Suddenly the group is struck by 'sex rays' from the planet Mongo. All of the adults, men and women alike, turn on the crippled newspaper boy...

(Sometimes we get tired of enumerating which IBM clone-makers just went bust. Writing a newsletter is a very non-linear process!

Page 3, Column 1

UNIX/WORLD WATCH:

If you have a real interest in the high-end micro and/or UNIX world, you really should subscribe to this magazine. They have a special on now; 12 issues for $18. Call (415) 949-3737, CA time. Considering this is the usual commercial magazine with the usual advertising, it is remarkably if not TOTALLY candid.

For instance, Vol 1 #5 asserted editorially that UNIX was not EITHER a standard, and then published lots of material to prove that. Vol 1 #6, the current issue, editorially asserts that UNIX is not even transportable, and then they publish lots of material to prove that too.

Every magazine has a problem (aside from the necessities associated with those darn ads) and UNIX/WORLD's problem is its publisher, John Knapp. His techno-politics are somewhere to the right of Daddy Warbucks - in issue #5 he seriously proposes to stick a .45 handgun into the ear of all you personal computer users to force you back onto time-sharing systems with variable response times of up to 30 seconds. Knapp obviously believes that instant response and isolation from 'the computer is down!' isn't worth anything and in fact is a roadblock to true progress (what he means is a roadblock to the sales of his advertisers, who ALL make multi-user systems). He also obviously believes all that advertising crappola about how many users a given system will support - more on this real soon.

YOU WILL NOT BELIEVE THIS:

Beginning on p.69 in issue #6 UNIX WORLD has a review of A T & T's 3B2/300 desktop uh, supermicro. This micro is based on a 7.5MHz WE32000 (nee BELLMAC 32). The WE32000 is an honest 32-bit micro which has, for instance, a 32-bit barrel shifter. In that latter sense it is akin to the 68020. However, we have reported in the past that the WE32000 is not an especially hot performer and that in fact it is slower than a 68000 (and the Z8000, and the 80286, and...).

We are about to talk about horrendously slow WE32000s, but darn it, it does not (necessarily) support our assertions about the relative speeds of those micros because of BIG BIG problems elsewhere!

The next thing you should know is that the performance data we are going to be writing about has been confirmed by A T & T: "After running the benchmarks, I just did not believe the numbers. First, the machine was much too slow; second, the single precision was slower than double precision. I was sure that there must be a bug somewhere or that I was doing something wrong. I called Ram Chelluri (a benchmark expert) at A T & T Technology and confirmed the numbers."

Page 3, Column 2

Here are the numbers that even the guy doing the benchmarking did not at first believe:

         32-BIT  64-BIT 

  ADD     3922    2128 
  MULT    9346    7463 
  DIV     5319    3663

Those times are in microseconds! Gentlepersons, the numbers above are IMPOSSIBLE, even though we ARE talking about an IEEE-compatible implementation. That is, they are impossible if you make the assumption that the folks who implemented that floating point package on the WE32000 knew what they were doing. There are AT LEAST three readers amongst the 700+ DTACK subscribers who can confirm what we are about to tell you (right Chet, David, Ulrich?):

Before we go on, keep in mind we are talking about a brand-new $16,000 supermicro - it says supermicro right here in the promotional literature - and IT IS 5 TIMES SLOWER THAN A $69.97 VlC-20!

CRASH AND BURN:

The idiots at A T & T obviously wrote that (IEEE compatible) floating point package in a high level language! Yes, 'C': you didn't think A T & T would use LISP or ADA, did you? How can we tell? The clues are obvious to anybody who knows anything at all about floating point packages:

For starters, divide is nearly twice as fast as multiply. That can't happen in assembly language; in assembly language matters are reversed and multiply is always a lot faster than divide. What we have here is a case of either a poor algorithm being selected for multiply or, more likely, the HLL algorithm selected for multiply being a very poor match for how the compiler works!

It should not be surprising that single precision is slower than double precision; this is the sort of B.S. that big organizations foist on us dummies all the time (in the past it was to save bytes). What we obviously have here is conversion to double precision, the operation performed, and then conversion back to single precision. The ridiculously longer time required is a function of the fact that the operation is being done in the high-level language 'C'.

Remember, we are talking about the fundamental software support provided by A T & T for its 32-bit $16,000 "supermicro". And it is five times slower than a VIC-20, we kid you not! (The author of the review also benchmarked a slow 8MHz 68000-based computer, the Scorpion, and it ran 19 times faster while using an

Page 4, Column 1

IEEE format F.P. package.) So what does the author conclude at the end of the review? THE FOLLOWING IS A CONDENSATION OF THE LAST PARAGRAPH OF THE REVIEW. NO NEW WORDS HAVE BEEN ADDED; NO WORDS HAVE BEEN CHANGED:

"If IBM or Digital Equipment had produced it, then I probably would have given it a rave review. When you judge the 3B2/300 purely on its price/performance, it is an excellent machine. In fact, I want one, and I will suggest it to my clients."

RAVE REVIEW? PRICE/PERFORMANCE? 5 TIMES SLOWER THAN A VIC-20? The old geezer over there with the lamp, the one who is frantically trying to buy a Concorde ticket to the next continent, is Diogenes.

LESSONS LEARNED.

If you have been paying attention, you will know that we have been espousing the idea of writing important stuff like floating point packages and operating systems and high level languages in assembly for the past 3 1/2 years. (Longer than that, really, but what happened before we started putting our ideas in print doesn't count.)

On the other hand, nearly 900 of our 700+ subscribers have written to your stupid FNE patiently explaining to him what a wonderful idea 'transportable' high-level languages are. They have even tried to explain the wonderful 80%/20% (or was it 90%/10% ?) rule to him. But your FNE in his ignorance, has resisted all these wonderful ideas. Possibly because he does not like 32-bit $16,000 supermicros which run 5 times slower than a VIC-20? (You know, at the moment we don't feel the least bit ashamed of the obvious sarcasm in this paragraph. Oh yes: 900 out of 700+ courtesy of the photocopy machines.)

There is more: the same review, on p.71, knocks the theory of the overheadless multitasking operating system in the kazinga. Wall clock time runs about 60% ahead of CPU time on a matrix test which could be benchmarked with an hourglass - provided you had an hour-glass that lasted two hours! Oh, yes: where is the fabled 'C' compiler with only a 2-1 HLL overhead? Out for a beer with the Loch Ness monster and the Abominable Snowman?

This $16,000 superturkey requires 98 minutes to invert a 50 X 50 matrix. For big matrices, the inversion time is determined by the time required to perform N cubed multiplies and adds. The HALGOL 64-bit floating point package did a multiply and an add in about 150 microseconds (issue #17 p.20). That was before we sped up the multiply but we should also make allowances for pivoting. We're guessing 160 microseconds, including pivoting, per operation pair. For a 50 X 50 matrix

Page 4, Column 2

that's 125,000 times 160 microseconds or 20 seconds. that IS 294 TIMES FASTER THAN A T & T's $16,000 SUPERTURKEY!

LET US REPEAT THAT:

The HALGOL 64-bit floating point package can invert a 50-rank matrix about 300 times faster than the $16,000 A T & T 3B2/300 as measured by wall clock time. If we measure CPU time, which is only of interest to accountants and advertising copy writers, HALGOL is STILL 180 times faster. In making these comparisons you will remember that a Concorde supersonic jet transport cannot fly 100 times faster than a normally athletic 14 year-old girl can run.

Others are beginning to notice.

In David Fiedler's most recent issue of Unique, his UNIX newsletter, he asserts: "...talks we've had with other 3B2 owners and our own tests lead us to believe that A T & T has oversold the 3B2's power by several hundred percent. Your editor even was present at a special executive briefing by Ian Ross, the president of Bell Labs, during which Ross admitted that the 3B2 could serve no more than 5 or 6 users. We hope and expect that A T & T will be more reasonable with its future claims..."

A T & T had previously claimed that one 3B2 could support the combined populations of China, India, Japan and Outer Mongolia. In fact, if any one user tries to calculate a logarithm, for instance, everything is gonna come to a real quick stop with even 5 or 6 users!

Yes, we know it is slightly unfair to compare HALGOL's non-IEEE double-precision floating point execution times to the floating point times of the 3B2 superturkey, which ARE IEEE compatible. But that should only count for about 8 or 10 to 1 in speed. And besides, we could have compared against Chet's compiled BASIC or Ulrich's Inter68 PASCAL packages, both of which support the Nat Semi math chip and so are about 1,000 times faster than A T & T's $16,000 superturkey!

BURIAL RITES:

We are gathered here to bury that fictitious 80%/20% rule, which nobody in the real world does anything about. And we are going to make the grave do triple duty by interring the fabled 'C' compiler with only a 2-1 HLL overhead and the virtue of 'transportable' code alongside that 80%/20% rule. But we are having trouble locating that fabled 'C' compiler (must still be guzzling brew with Nessie and the Abominable Snowman) or any virtue in 'transportable' code that is about two orders of magnitude slower than untransportable code... Will a HLL supporter please give a eulogy?

Page 5, Column 1

MORE A T & T:

The vendors of that wonderful high-performance 3B2/300 are planning to introduce yet another small computer, this one designed by Convergent Technologies. Since it is designed to plug directly into the phone lines, A T & T is legally constrained to file with the FCC certain aspects of its design. It turns out that this new computer has half of (IBM's) AT's hard disk storage, 42% of the floppy disk storage, the same (512K) RAM, and 80% of the pricetag. It will also have an optional plug-in board to make it 'MS-DOS' compatible.

FCC regs do NOT require that the CPU be designated, but the fact that Jack Scanlon will not permit Convergent to lay hands on the WE32000 and that an optional board is needed for MS-DOS compatibility lends credence to the rumor that the new unit will be 68010-based.

As lots of folk have already pointed out, that means that A T & T is now supporting THREE incompatible CPUs in its personal/small computer product line. WHAT THE HECK, GUYS: Remember, the floating point package in the 3B2/300 is written in C and hence can be transported to the new 68010 machine. FANS OF HIGH-LEVEL TRANSPORTABLE CODE WILL DOUBTLESS BE PLEASED!

MORE Unique:

Earlier this year each of the only two newsletters we were getting both, at about the same time, failed to publish for a long while. One of these was Ron Jeffries' Jeffries Report and the other was David Fiedler's Unique. Because we thoroughly enjoyed both newsletters the publication hiatus perhaps seemed longer than it was.

While discussing another matter with David Fiedler, editor and principal author of Unique, he explained that the unfortunate publication hiatus was caused by some temporary internal organizational problems at InfoPro, which is the corporation under which Unique is published. The thick 'summer' edition was InfoPro's way to best recover from those problems and was not, as we assumed, part of a strategy to move Unique towards being a magazine. (David was mildly peeved that we would imply that his publication was about to start carrying advertisements - he is apparently at least as sensitive as we are about the editorial pressures that come with those ads.)

We have subsequently received two issues which appear to be in the old format except for slightly smaller type, meaning the same number of pages hold more information. Now, about our report that the August issue arrived on 20 Sep: it DID, but we have discovered that we are on the EDITOR'S mailing list! That list gets mailed two or three weeks after the

Page 5, Column 2

regular paying customers because some editors (not us) have taken material from David's newsletter and published it without attribution as their own scoop!

For the record, Unique is a valuable, well-written information resource regarding the UNIX-related community which is free of editorial bias caused by advertising. The reason we don't recommend that you all subscribe to it is that the subscription rate is $54 per year, too steep for a general-interest publication. We assume that everybody who is in the (UNIX-related) business is ALREADY subscribing (through his or her company, naturally). In case we are wrong, call (201) 989-0570, east coast time, for more subscription info.

CONFLICT OF INTEREST:

During our conversation David brought up the point that he, and InfoPro, do not have an interest in any hardware product. In another conversation the preceding day another manufacturer of an attached 68000 processor asked "You don't REALLY think we are competitors, do you?" (He was laughing at the time.) We replied no, but we can't say that in our rag because half of our readers wouldn't believe it!

We have even been (in our own judgement) circumspect about criticizing Mackintosh. Why be hesitant about criticizing Mack when we previously had no compunction criticizing the Apple III and LISA? Because we cannot let our readers believe that we automatically knock competitors, that's why.

LEAD THE CHEERING ?

In fact, not only have some of you readers been highly critical of OUR criticism of Mack but at least two readers have vented much spleen over OUR FAILURE TO LEAD THE CHEERLEADING FOR MACK! Geez! Here we have been writing for 3 1/2 years about how great it is to have 15 or 16 32-bit registers and we are supposed to lead the cheerleading for a product whose makers have gone to a great deal of trouble to keep the user from getting to those registers? If not for the pictures of the Mack motherboard that have been published, how would the typical Mack owner ever know what kind of CPU Mack used? The damn CPU is hidden!

Each of you readers will have to individually decide whether our failure to lead the cheering for Mack is due to an honest difference of philosophy or due to the fact that Digital Acoustics makes a competing product. (Keep in mind that your FNE has a great deal of influence with Digital Acoustics' president and its majority shareholder. Therefore, it is hard to tell where your FNE's philosophy leaves off and the DTACK products begin.)

Page 6, Column 1

ALTERNATE ARCHITECTURES:

The term "architecture" can mean a lot of things, including the shape of the cutout in the door of the outbuilding, but we all know we are discussing MICROCOMPUTER architecture here. Those of us who are interested in such stuff are extraordinarily fortunate; we happen to be living in the most interesting of times. The recent development of standard cell libraries, the techniques of Conway and Mead, even the silicon compilers which are coming on line; all of these things mean that computer architecture is no longer merely a suitable subject for dull academic papers to be published and forgotten. It is now possible to BUILD the computer architecture of one's dreams and to put it to practical, real-world tests! It's almost as though astronomy, which is an observational science, were suddenly to become a laboratory science!

A substantial amount of the British taxpayer's money is being expended on an effort to create a general-purpose dataflow machine whose smarts can be more or less evenly spread over a large number of discrete computing elements. That is the Transputer, of course, which has not yet seen working silicon. But we are pleased that an effort is being made to break the (general-purpose) von Neumann bottleneck. We are also pleased that it is not our money which is at risk in that effort.

Risk, er, RISC? The Nov issue of Byte has a very good overview of the RISC, or Reduced Instruction Set Computer. RISC's proponents assert that a RISC can provide better performance than existing CISCs, or Complex Instruction Set Computers. Since John Markov did a excellent job of presenting the case FOR the RISC in his Byte article, let us concentrate briefly on an opposing view.

Did you know that the 8080 can outperform the 4004? That the 8086 can outperform the 8080? That the 68020 can outperform the 8086? Oh? You knew all that? Of course you did! No, we are not trying to insult you; we are trying to make the point that the 4004 should be compared to the Autonetics PPS-4, the 8080 to the 6800, the 8086 to the Z8000 and the 68020 to the Z80000 or the 80386. In other words, the performance of microprocessors should be compared to other contemporary microprocessors.

Therefore, we are troubled when some academics, however well-meaning, compare a brand-new first or second-silicon prototype with 1979 technology (an early-silicon 8MHz 68000 with 2 wait states) and proclaim the superiority of that prototype. There is a lot of that going on in the RISC camp. Oh, yes: we forgot to mention that the opposite of the RISC, the CISC, is typified by the 68000 and the 68020. The RISC

Page 6, Column 2

proponents seem to be asserting that they are going to kick the stuffings out of the 220,000-transistor 68020 with a RISC having fewer than 50,000 transistors! (You don't suppose that Governor Moonbeam [Jerry Brown] was right and that simplicity really IS a virtue?)

We are not completely opposed to the arguments of the RISC crowd. In particular, WE GREATLY FAVOR LOTS OF ON-BOARD REGISTERS, especially when used in overlapping banks as the RISC machines do. If the RISC boys had had their act together (along with some commercial funding) back in the 1976-8 time frame when 50,000 transistors on a chip was the state of the art, they might well have been able to prove their point, at least for a while.

Today we think the RISC is doomed before it ever sees commercial realIty (as a one-chip microprocessor). What Motorola's designers have done with that huge number of transistor-equivalents on the 68020 is create an architecture with multiple execution units acting in parallel under the direction of that complex microprogram which the RISC folk decry. A RISC machine (as we understand it) inherently has only a single execution unit on-chip. Since coordinating multiple execution units is inherently a complex task, it is our opinion that time has passed the RISC concept by.

(We hope it is obvious that a chip with effectively-coordinated multiple execution units is always going to beat the heck out of a chip with only a single execution unit.)

Meanwhile, the folks at Stanford do not want to play sycophantic second-fiddle to the Berkeley RISC folk and so have decided to conquer the world with a compiler. A very, very sophisticated compiler. (Be sure to read Markov's Byte article all the way to the end.) How many of you have noticed that the success or failure of the Transputer will depend more on the success of OCCAM, which is a data-flow compiler, than on the transputer itself? True, they have to get the silicon to work first but that silicon won't be worth a tinker's dam if OCCAM cannot correctly coordinate multiple execution units in a general-purpose environment.

Best of all, ALL THIS STUFF HAS EITHER BEEN BUILT OR IS GETTING BUILT. For real! These are exciting times! If you are churlish enough to disagree, go watch a Gilligan's Island rerun and let the rest of us enjoy ourselves.

[The above was written on the morning of Nov 15. The following came in over the transom just after noon the same day:]

Page 7, Column 1

"...I don't have time for a paper, so I will summarize my arguments on the RISC/CISC controversy:

"1. The objective in a RISC design (university 'microprocessor') is minimum design effort. (Cynically: maximum personal career gain at minimum effort.) The main objective in a CISC design (commercial microprocessor) is maximum function per unit area. Right now I see the score as follows: RISCs leading in REPORTED performance, publications, and research funding and CISCs leading only in revenue. Exactly what you would expect, given the design objectives.

"2. Arguing with RISC proponents is like trying to put your thumb on a wet watermelon seed. As soon as you try to pin them down on the contribution of one idea (e.g. simplifying the instruction set), they squirt off in another direction (e.g. procedure call efficiency). Debates are a giant eristic shell game. I think arguments can be simplified by concentrating on the processor-memory interface. It is a bottleneck for all commercial microprocessors. If you simplify the instruction set, less information about what to do crosses the pins with each instruction, making the bottleneck at the processor-memory interface worse. (I'd have thought this would be most obvious to applications professionals.)

"3. Cut a 68000 in half across the middle just below the control store. Throw away the part with the instruction decoders, control store, state machine, clock phase generators, branch control, interrupt handler, and bus controller. What you will have left is a RISC 'microprocessor.' All the instructions execute in one cycle. The design is greatly simplified. The chip is smaller. And the APPARENT performance is vastly improved. Many of the papers written about RISCs would describe this machine as well. Now, Mr. Applications Wizard, try to build a system using this wonderful new chip. You have to rebuild on the card the parts you just cut off. Good luck trying to service the microcode interface at the 'microprocessor' clock rate.

"4. I can double the apparent performance (measured in MIPS) of the MC68000 by allowing the compiler to generate only the 32 most popular instructions.

"5. In the most recent RISC papers the authors have proposed such ideas as adding variable-length instruction encoding (outside the chip), floating-point instructions, load and store multiple, and string operations. Where are they going? Before long someone will cut their chip in half and start the cycle all over again."

[Anybody want to rebut the above arguments? - FNE]

Page 7, Column 2

DVORAK WATCH:

Just as we went to press with the last issue, John printed an anti-FORTH polemic in his InfoWorld column. It seems he thinks VALDOCS is godawful slow and he thinks that FORTH, a high-level language, is to blame. We agree. In fact, we agreed in advance, asserting the same sort of thing (along with several other observers) when VALDOCS first came out. But, John: FORTH is NOT to blame! Writing VALDOCS in ANY high-level language would have busted it just as well, or a lot better if that high-level language was (ugh!) PASCAL!

How long have we been telling folks that writing your operating system in a high-level language - ANY high-level language, including HALGOL - is a terrible mistake from which it is nearly impossible to recover?

We also reported, more recently, that some UNIX vendors were quietly rewriting the UNIX kernal - NOT the whole damn 5 megabytes, just the kernal - in assembly language. We were immediately jumped on by some minicomputer-type UNIX fans who asserted that we were wrong. Uh, uh guys - a significant number of vendors ARE rewriting (or HAVE rewritten) the UNIX kernal in assembly. For the same reason that a rewrite of VALDOCS is going on. That high-level is a killer, whether FORTH or PASCAL or C...

Perhaps John (Dvorak) has forgotten how 'wonderful' the PASCAL-based LISA-1 operating system was? No FORTH there!

For those persons who are pushing the '80%-20%' concept: LISA-1's operating system ran to 900,000 lines of PASCAL source code. To rewrite 20% for speed meant 180,000 lines of PASCAL source to convert to assembly - after, of course, WHICH 180,000 lines had been identified! Would you please have all that done for us by next Wednesday, please? No? Then will you please stop blithely claiming that rewriting 20% of the high-level code in assembly is some sort of magical panacea? Huh?

Remember that unfortunate integrated spreadsheet called MBA which, alas, was written in incredibly slothful PASCAL and which died a horrible death when confronted by lean, swift assembly-based 1-2-3 in the marketplace? Well, MBA has been completely rewritten now and it's a LOT faster. So what? 1-2-3 is still just as fast (FASTER if MBA was not COMPLETELY rewritten in assembly) AND THE Lotus FOLK GAINED AN 18-MONTH LEAD IN THE MARKETPLACE BY DOING IT RIGHT IN THE FIRST PLACE! And LISA 1 died in the marketplace because it did it WRONG in the first place!

The theory behind that damn 80%-20% does not allow for doing things in a timely fashion. That's why neither

Page 8, Column 1

MBA nor LISA 1 will EVER recover or be a factor in the marketplace. IN THE MASS MARKETPLACE, TNE 80%-20% "RULE" IS NOT IN ACCORDANCE WITH THE CLEARLY OBSERVABLE FACTS!

So where did the 80%-20% rule come from? From in-house programming staffs, which do not compete against MS-DOS or 1-2-3 in the mass marketplace. They have NO competition, period, and hence NO competitive situation to measure themselves against. In those non-competitive situations, 80%-20% looks FABULOUS - just what the data processing manager ordered!

Oh, yes: John Dvorak. In 5 Nov Infoworld John has the very bad luck of telling us how the 3.5 inch Sony ain't gonna be the future standard on account of IBM's connection with a different size media. Regrettably, while that issue of Infoworld was at the printers, IBM signed an order with Sony for a half- million 3.5 inch double-sided floppy disks (not drives, disks) PER MONTH! That means Sony has to increase its production by 50%, just based on that one order. Uh, nobody's perfect, John.

(Perhaps we shouldn't tell John about the one million 3.5 inch drives that IBM has ordered from Toshiba or the 800,000 3.5 inch drives IBM has ordered from ALPS, both orders placed at $60 per drive. What size did you say was going to be the future standard, John?)

MORE INFOWORLD:

While we are mentioning the 5 Nov issue, be sure to see pp 15,48,54,72. Page 15: will somebody please tell Mike McC. that 'earnings' is synonymous with 'profits'? The term he is after is 'sales' or (same thing) 'shipments'. It would startle a hell of a lot of people if Compaq really 'earned' $85 million in the most recent quarter.

On p.48 we learn that the NCR PC4 is designed and built by NCR, not outside vendors. That happens to be true. One of the parts which NCR uses in its very own design is the Faraday mother board, complete with Faraday ROM BIOS. On p.54 John Gantz gives himself a report card for the first year of his column. Why don't some of you readers give US a report card for our first three years?

Beginning on p.72 and extending over several pages and TWO hard disk reviews we learn why there is a distinct difference between how easy Mack is to USE and how easy it is to PROGRAM. Big, big distinction. Jeff Hull's Halgol Review #11 made this same point on its first page.

(Nov 12 Infoworld, p.19: apparently Mike McC. is not the only staffer who does not know the difference

Page 8, Column 2

between sales and net (profit). Kim B. asserts that Fortune Systems has netted $15 million in (fiscal) 1984. That is going to come as an ENORMOUS surprise to a whole bunch of financial analysts! And to Fortune's auditors, we add.)

WHO'S ON FIRST?

The Osborne Computer Co, which is still operating under Chapt 11, is about to introduce two new computers, Vixen and Encore. Osborne (the company) designed the Vixen itself but will have it built by an outside contractor. On the other hand, the Encore was designed by an outside contractor AND will be built by an outside contractor. In fact, the Encore is the same design as Morrow, Inc's Pivot portable. The new Encore computer is not related in any way to Encore Computer Corp, which is now working on Plan C. Everybody got that, now?

SYTE SINKS:

San Diego-based Syte Info Tech just died of a critical lack of cash, the venture capitalists having pulled the plug. Syte is one of the outfits which had bet heavily on Nat Semi's new 32000 serIes microprocessors - in this case, the 32016 (formerly 16032) - and UNIX. It is interesting to note that lack of a floating point math accelerator was cited as one of the reasons for pulling the plug. The writeup in EN (Oct 15 p.16) did not mention the lack of 10MHz 32016s, though.

FORTUNE SYSTEMS

has just cancelled nearly all of its few remaining retailers. They are now going with VARs (Value Added Resellers), which is how most minicomputers are sold. Naturally, the mass marketplace is one thing and the VAR market is another and the twain shall never ever mmet. Which proves what we have been saying all along, UNIX is totally unsuited to the mass marketplace. Fortune, you will recall, is the company which intended to prove that the UNIX - 68000 combInation was suitable for the mass market.

UNIX/WORLD magazine, Vol 1 #3 ran a very funny and informative article entitled "WHATEVER HAPPENED TO FORTUNE SYSTEMS" (p.40). The Fortune folk admit, for instance, that the Fortune multi-user system had "...performance problems beyond one or two (p.49)..." YE GODS! Performance problems beyond ONE or two? They also asserted: "It wasn't as easy to sell a sophisticated UNIX system as it was to get somebody to walk out carrying a PC under their arm (p.44)." Thus, the cancellation of the retailers and thus, the failure of UNIX in the mass market...

After a single quarter in which Fortune reported an

Page 9, Column 1

actual profit large enough to buy three boxes of paper clips, they have gone back to their old habit of spreading red ink by the 55 gallon barrel. They dropped nearly $4 million in the third calendar quarter. Oh, yes: Fortune would apparently prefer that you not know that they cleverly loaned $4 million to North Star during the aborted merger negotiations. (That loan is almost a secret.) How much longer do you think that $44 million they USED to have in the bank is going to last?

TOMORROW II:

A reader has pointed out that everything we said about Mackintosh (tomorrow and tomorrow and...) could also apply to HALGOL. He's right. Once one has made the decision to develop a computer language out in the open, then one is vulnerable to the 'tomorrow' charge right up until the exact moment the language is completed. The problem is, we had been developing the language out in the open for nearly two years before it dawned on us that we had already made a decision...

HALGOL: NEW?

Some folk have questioned whether HALGOL is really a new language or just another BASIC. We think the concept behind HALGOL is sufficiently original to warrant being called a language, but it all depends on your definitions and/or point of view (and we are somewhat prejudiced). To argue the point really involves arguing definitions, and we are disinclined to pursue a fruitless argument of that kind.

Is Modula II a new language or just a patched-up PASCAL? It all depends on your definitions, doesn't it?

WONDERFUL SEGMENTS:

Sam B. sent us a clipping from Computer Systems News (15 Oct p.30). The article was on IBM's new PC Professional FORTRAN, which naturally was written by Ryan-McFarland, not IBM. Sam circled these two paragraphs for us:

"In addition, PC Professional FORTRAN supports large arrays, another must for scientific applications but a problem with segmented-architecture chips such as Intel Corp's 80286, the microprocessor in the PC AT.

"'But Intel does describe an ability to manipulate segment addresses to create large arrays, and we decided we had to have it and make it transparent to the user. Ours is now the only FORTRAN to have that capability,' McFarland said, adding that it was implemented 'with great difficulty.'"

Page 9, Column 2

Gee, Sam, didn't you believe us when we told you that linear addressing was wonderful and that segmentation AIN'T? Like we have said a dozen times now, keep that 80286 locked inside 64K boundaries and it is a pretty fast micro - unless it has a SLOW SLOW 6MHz clock as in the PC AT, that is - FNE

(It is also nice to see that expert software professionals are now reaching the same opinion of the 80286 that we have been offering for a long time.)

A LITTLE PUFFERY:

Corporate superstars like to see their name in print and in that respect are just like the Hollywood variety. They also hire some of the same public relations firms and flacks, whose job it is to get spectacularly favorable 'news' stories (called 'puff pieces' in the trade) planted in newspapers as seemingly legitimate articles. An example can be found on page 2 of this morning's (30 Oct) L.A. Times' business section.

We have what appears to be a story about the success of Compaq, the IBM PC clonemaker. But the puff piece is illustrated by a very large photograph of one Ben Rosen and a very small photo of a Compaq computer. In fact, the only 'employee' of Compaq mentioned in the puff piece is Ben Rosen, who IS the board chairman but is NOT the chief executive officer and who in fact has no official operating authority at all. Yet this puff piece quotes Ben (who seems to have trimmed back his nose hairs) on and on as 'we' (meaning Compaq) do THIS and 'we' did THAT.

The text of the puff piece also neglects to mention Compaq's newest offering, the Deskpro (a tiny part of one sentence excepted). The Deskpro, you will recall, was designed to compete with the IBM PC/XT. It was not doing well in the intense competition for display space in the retail outlets even BEFORE IBM announced the AT. Naturally, nobody wants to talk about the Deskpro NOW, apres-AT. (Success has a thousand fathers but defeat is an orphan.) In short, this item in the L.A. Times was an absolutely perfect example of a puff piece if you don't notice which computer is in the very small accompanying photo...

SS-50 OR FIGHT!

Jeff H. has encouraged us to look into the SS-50 world, since it is beginning to be involved with the 68000. With the help of local subscriber David H., who very kindly loaned us the five most recent issues of the '68 Micro Journal', we have done some research. (68 Micro is published in Hixson, Tennessee; their phone # is (615) 842-4600.) Some of the results are surprising and others are, or should have been, expected.

Page 10, Column 1

You know how fanatical the S-100 folks are about their bus system and boat-anchor chassis? The S-100 folks are moderates next to SS-50 types! (We will pause to offer a short prayer of thanks that Jerry Pournelle's buddies are S-100 types instead of SS-50 types. We don't think a combination of Jerry and the SS-50 is puttable up with.)

A short recap: the SS-50 bus originated back in 1976 with Southwest Technical Products in San Antonio, Texas. Those folk built a 6800 (two zeros) system built on an S-100ish bus, but using some industrial grade Molex connectors for the bus connections. The industrial grade Molex connectors feature ten-penny nails spaced at tenth inch intervals in a single, not double, row. The male connector is on the mother board (which obviously should be termed the FATHER board in this case). The Molex connectors have the considerable virtue of being both rugged and cheap.

Cheap is why they were originally selected; the SWTP 6800 system was originally one of those super-cheap kit deals with blank boards for real, honest hobby-type hackers with more time than money. The SS-50 has evolved into some EXPENSIVE boat-anchor chassis which to a lay person such as us look almost exactly like the S-100 variety. SWTP, Smoke Signal and Gimix all make some VERY VERY EXPENSIVE SS-50 systems, all of which are 8-bit machines. Your basic SS-50 bus has an 8-bit data path, 20 address lines of which 4 are typically registered in hardware. After all, your SS-50 is based on the 6800 or, more recently, the 6809 - right?

Lately, maybe not right. Lately, maybe the 68000. At least that's what it says in black and white, and we naturally believe everything we read. In the Nov issue of 68 Micro Journal, on page 7, there is an ad for a '68000' upgrade from Smoke Signal. The first 6 and last two mentions of the CPU, including the two bold-faced headlines at the top all say, quote, "68000". Not until we examined the ad carefully did we find three mentions, in very small print, of the "68008". The photograph of the board clearly shows a tiny 48-pin 68008, not the gigantic 64-pin nearly inch-wide 68000 we all know and love.

It's like this: the SS-50 bus has 8 bits, and the 68000 has 16. The 68000 hence does not 'SS-50', which renders it invisible to chauvinistic SS-50 supporters. The 68008, especially in its 8MHz version, does have an 8-bit bus and at 8MHz has the same 500nsec memory cycle time as a 2MHz 6800. So the 68008, unlike the 68000, 'SS-50s'. When an SS-50 type says '68000' what he or she means is '68008'. This is not considered inaccurate or misleading or fraudulent because anything which does not 'SS-50' is unworthy of recognition if not officially declared not to exist.

Page 10, Column 2

68 Micro Journal has a new column by one Phillip Lucido, who means well. He has already mentioned in two different issues that the 68000 cannot index over a range larger than 64K (and give Phillip credit, he has spotted the sign extension problem). Apparently he is using some software, specifically a 'C' compiler, which grew up in the SS-50 environment courtesy of the 6809. Neither Phillip nor the compiler designers are (evidently) aware that the 68000 does in fact have full 32-bit indexing, and that any one of the data registers or address registers can be used as a 32-bit index register. Naturally, there is no such thing as a sign extension problem when using a full 32-bit index register.

There is a very good 8-bit operating system which grew up on those terribly expensive SS-50 boxes, or at least the ones powered by a 6809. It is called OS-9, and it is offered by a company called Microware Systems Corporation in Des Moines, Iowa. This operating system is now being advertised as being available for the 68000, which is surprising since it was originally written for the 8-bit, 64K address space 6809. In fact, Phillip Lucido writes about "68000 OS-9" in his "68000" column! Remember this is the SS-50 world and that the 68000 does not 'SS-50' but the 68008 DOES. Naturally, the "68000 OS-9" written about is really 8-bit '68008 'OS-9'. Phillip even mentions with some puzzlement that the "68000" (68008) did not run significantly faster than a 6809 unless "register variables" are used.

Translation: the 6809 has an instruction set that is a very limited subset of the 68000's instruction set. A nearly-literal translation of 6809 code to 6800X code is relatively simple unless you try to optimize for all the useful stuff the 6800X has that is missing in the 6809. Does anybody recall how the 8088 in IBM's new PC seemed to run exactly as fast as an 8080 the first couple years of the PC's existence? It turned out that what certain cynics believed, that all that code was just translated 8080 stuff, was TRUE!

Now we have OS-9, originally written for the 8080, er, 6809 and it is now running on the 8088, er, SS-50ish 68008. And it doesn't seem to run much faster than a 6809. Gosh, we wonder why! (For the record, we are not aware of any real, honest 68000 system which runs OS-9.) The same reasoning probably applies to the '68000' C compiler which Phillip uses and which originated with the 6809 (we believe).

You will please keep in mind, if you read the 68 Micro Journal, that if it is mentioned in that mag then it has 8 bits and 'SS-50's. You will see repeated headlines which would appear highly misleading or even fraudulent to a neutral observer but those headlines are fair game in the highly restricted SS-50 world.

Page 11, Column 1

You will never see a true 68000 system in the SS-50 world, much less a true 68020 system. That raises the interesting question: how much longer can those SS-50 types '8-bit' in a 16 or 32-bit world? We dunno. We do know that they think the S-100 bus has faded away into oblivion, which offers a nice contrast to the S-100 types, none of which have ever known of the existence of the SS-50 bus!

You may want to make your own investigation of the SS-50 world. We have one suggestion: when somebody tells you the 6809 runs as fast as the 68000, run like hell!

OCTOBER 17, 1984

was a remarkably interesting day. First we had to get up early to make the Motorola 68020 seminar in the city of Orange. We seldom travel by freeway anymore because, after 8 years of Governor Moonbeam's state transportation director Adrianna Gianturco there aren't enough freeways to handle the traffic. (Ms. Gianturco punished Orange County for not providing lots of cheap housing by withholding highway construction funds even though the Orange County population nearly doubled during her regime.) Natural result: Orange County's freeways are overloaded virtually all day, not just during the morning or evening 'rush hour'.

So we made an unusual pilgrimage to the Riverside Freeway just briefly before turning onto the Garden Grove freeway at the beginning of that freeway. We were in the left of two lanes and had the pleasure of opening up all four barrels of the carburetor for our 8-cylinder Detroit iron. Then we heard "whish, whish, whish!" as one German and two Japanese compacts blew past us on the right. We checked our speedometer: 72 MPH! Whatever happened to the national 55 MPH speed limit?

Arriving at the seminar nearly a half-hour after its scheduled 8:30 AM starting time, we naturally had time to pick up our prepaid registration materials just before the seminar started. Then the Motorola type spent about 40 minutes reviewing the 68000 (ZZzzzz) before stopping for a premature rest break at 9:35. After that break, he eventually actually got around to spending about an hour on what we had come to hear about - the 68020. (More on that later.)

After a buffet luncheon, we decided to split (but our project engineer stayed) when we learned there would be just the one afternoon session and that it would concentrate on a couple of 68020 instructions designed to support multi-tasking and then lots of emphasis on hardware (minicomputer-type stuff; what's new?) Motorola would like everybody to buy. But by the time

Page 11, Column 2

we left we had had the opportunity to talk to several folk in the low-end minicomputer game about industry economic conditions (more on THAT later).

We got back to the office just as newsletter #36 arrived from the printers. Stuffing and mailing those newsletters is a group activity at Digital Acoustics and the group includes us, so we proceeded to stuff newsletters in envelopes (imagine! there is a 50-50 chance that YOUR newsletter was stuffed by none other than your FNE!). While we were doing this, a regular subscriber walked into the office bearing two circuit boards:

COMPETITION REPORT II:

You may recall our Aug '82 report (#12, p.12) about some local folk who were planning to produce copies of our DTACK board, meaning the static-RAM Apple-compatible variety. For reasons which only one of our readers will understand or appreciate, we have never revealed, and will not reveal, all that we learned about that, shall we say, conspiracy? Well, guess what?

The two circuit boards our regular subscriber walked in with were both COUNTERFEIT static-RAM Apple-compatible DTACK boards! With just a little horse-trading, we found ourselves in possession of a gen-U-wine counterfeit DTACK board! The documentation which came with the board was hand-printed (don't those thieves know about word processors?) but just included a parts list, no schematic. The thieves had very cleverly just copied the main board and merely provided a drawing, no board or even schematic, of the 6-IC interface board which plugs into the Apple. The documentation noted that it was an "M and M" production - doubtless Mickey and Minnie. We agree.

The nicest thing is that those thieves must have lost money on the operation in addition to their time. We had, in the preceding months, received only ONE telephone call from someone who asserted that 1) they had bought, secondhand, a DTACK board and 2) a miscreant had ripped off their Apple II including the little DTACK interface board but had left behind the main DTACK board - so could they buy a replacement interface card, please? He didn't get it because we had already heard rumors of counterfeit DTACK boards circulating in Southern California (it's not a rumor now!) and asked him to show up personally with his serialized DTACK board.

When we can stop laughing, we feel very flattered that someone would rip off a circuit board design of ours. (It was NOT reverse-engineered, just a careful copy except that the Digital Acoustics part number and copyright notice were left off.)

Page 12, Column 1

MORAL CONSISTENCY:

Some of our readers (and customers) have expressed surprise and dismay in the past because we do not approve of, or support, Apple rip-offs such as the Franklin. Well, if we are morally consistent then we would ALSO have to approve of, and support, DTACK counterfeiters - hmmm? And we are, or try to be, morally consistent!

About the use of the word 'thief': it has come to our attention that theft is becoming so common in today's society that it is nearly respectable. If you feel that 'thief' is a harsh word, go back to the preceding few paragraphs and substitute the term 'socially unintegrated miscreant'.

Our experience is that some folk think the person who rips off their neighbor's TV console is a socially unintegrated miscreant while the person who rips off THEIR TV console is a thief!

MAKING IT:

In the vernacular, Digital Acoustics appears to be 'making it', if not making it BIG (yet). In addition to being popular enough to attract a counterfeiter, MICRO magazine is going to be appearing right about the same time as this newsletter with, get this, A CONSTRUCTIONAL ARTICLE FOR A DTACK-COMPATIBLE STATIC RAM 68000 ATTACHED PROCESSOR!

This will apparently be a wire-wrap project - we do not know of a circuit board being offered. While the design is intended to be DTACK compatible, it is NOT a rip-off. It is instead an original design which accomplishes some of the things we did, such as fix the 68000 zero-page problem, in an original yet compatible manner. Software which runs on our board should in principle run on the MICRO design, which is by a long-time West German subscriber to this rag.

Bob Tripp very kindly let us review the design, which is why we know it is original yet compatible, in case you were wondering. There are several items which prevent FULL compatibility:

The trivial one first: the design is not capable of reading status line B1. True, most existing software only uses status line B0 (the bootstrap ROM uses B0 to distinguish between commands and data). However, both the static and dynamic RAM DTACK boards can read line B1, so that feature might be used in some future software. (Ulrich, there is a clue there to a question you just asked us!) The design in MICRO has an unused gate which can read B1 so it will be a simple matter to include this function - the circuit will be wire-wrapped, remember?

Page 12, Column 2

THE MEMORY MAP:

The DTACK boards use $000-$3FF for the 1K bootstrap RAM, $1000 and up for RAM, $FF0-$FFF for the host interface I/O, and then maps the space from $400 to $FEF to the expansion connector. The space above the on-board RAM is also mapped to the expansion connector: $18000 and up in the case of the static RAM board, and $100000 (count those zeros carefully!) and up in the case of the Brando. This means that the expansion connector can be used to connect either memory expansion boards or peripherals such as our math boards or graphics boards. The math boards and graphics boards are mapped into the zero-page space $400-$FEF. By using this small portion of the zero page for I/O, more efficient (i.e. shorter and faster code) addressing of the various peripherals is enabled. Both the static and dynamic RAM DTACK boards are identical in this regard, which is why our peripheral boards work with either of the DTACK boards.

The MICRO design is incompatible with the DTACK boards in that the memory space $400-$FEF is not mapped to the expansion connector for I/O but is used to extend the size of the bootstrap ROM from $000-$FEF. Thus, the MICRO design has a bootstrap ROM which is nearly four times the size of the 1K DTACK bootstrap RUM. This also means that any code loaded into the extra 3K would be incompatible with DTACK boards unless a peripheral board is made which maps a ROM into that 3K space, rendering it useless for I/O - obviously a foolish proposition. (It was our project engineer, not us, who spotted this memory map conflict.)

In fact, the expansion port on that MICRO design is a little vague. The static RAM is limited to 60K, not 92K as on our original 1981 design. We think the MICRO design has regular interrupts similar to our Grande board and unlike the original GROUNDED static RAM board, which has no interrupts at all.

Building a wire-wrapped DTACK-compatible 68000 attached processor with all of 60K of static RAM is a great project for those persons who have lots of time on their hands but who don't care for crossword puzzles.

THE ANSWER MAN:

"Dear Mr. Eloi: What is the best way to upgrade my 92K static RAM board so it has lots more memory?" Mugwump

Mugwump, the best way to upgrade your 92K static board is to sell it to a frustrated MICRO reader who for some reason (such as laziness or lack of time) can't get that wire-wrap board to work. Take the proceeds, add enough fresh green to make $995 (more if you live in CA) and trade that sum to us for a half-megabyte GRANDE. That is by far the best and cheapest way to

Page 13, Column 1

get from 92K to 512K. By the way, we're informal around here; just call us 'Felgercarb'.

(If no frustrated MICRO reader is available, then the upgrade price to 512K is EXACTLY the same for DTACK customers as for Apple Computer Co. customers, except the DTACK customers get to keep the old board and Apple Computer Co. customers DON'T!)

[The above was written AFTER what follows:]

STATIC RAM STUFF.

For those of you with static RAM boards we have good news and bad news. The good news is that we will support the 92K static RAM board with HALGOL to the extent that such support is possible with only 92K. And our math boards (1 or 3-holer) and POTBOILER are compatible with our static RAM boards as well as our Grandes.

We have more bad news than good, though.

Our hacker-type sales (which are beginning to pick up again after our recent price cuts) are for either 512K or full-gallon (megabyte) boards. So HALGOL will be developed primarily for a 512K environment, with any additional memory being used as print buffers, larger RAM disks etc. There will be no version of HALGOL targeted for a memory size between 92K and 512K.

The static RAM boards do not have interrupts and so make superior devices for real-time tasks. The Grande boards necessarily have interrupts because of the DRAM refresh requirement, and this forces us to some contortions in certain kinds of programming (read future DTACKs for the exciting details!). This ALSO provides certain opportunities unmatched by the static board. Examples: checking once a second (every 500 interrupts) to see if a floppy disk has been removed, or having a built-in real-time clock or timer which depends on those regular interrupts.

While dynamic RAM prices have dropped dramatically in the past two months as the clone-makers drop out of the market, static RAM prices are actually 30% higher today than they were two years ago! We refer to Toshiba 100nsec 2K X 8s, of course. This means that static RAM now costs a tad more than 5 times DRAM, byte for byte.

All of these factors mean that attempts to expand 92K static RAM DTACK boards with more static RAM are doomed. (As our project engineer recently noted, the Morlocks have triumphed utterly.) We have received four or five requests for blank static RAM expansion boards, all of which we are going to refuse. There are several very practical reasons for that refusal, which have been enumerated in past issues of DTACK, but it

Page 13, Column 2

really comes down to this: You can spend a heck of a lot of money converting a too-small 92K static RAM DTACK system to a too-small 220K static RAM DTACK system. Net benefit of monies expended: ZERO!

The static RAM DTACK boards were designed, and initial production shipments made, in 1981. At that time 64K was a lot of memory and our boards could hold nearly 50% MORE than 'a lot of memory'. Our static boards were (and are) successful in their intended task, which was to provide a LOT of computing power at a low price to owners of personal computers (mostly but not exclusively Apples). Their time has passed, just as the time of our year-older Commodore 8032, with an exciting 32K bytes of DRAM, has passed.

Yes, our full-gallon Grandes are going to be considered similarly memory-short eventually, perhaps within 5 years. The same is true of anything else you can buy today in the personal computer market. We think this is called progress.

In the meantime, every task that the original 92K static DTACK boards could perform can STILL be performed by those boards! And we WILL provide a version of HALGOL for those boards, even though they are no longer regularly offered for sale.

BIG FLOPPY DISKS.

No, not big as in 30 inch diameter. Big as in megabyte-plus storage capacity per diskette. We have a couple of them which our project engineer is busy writing (at the moment) formatting routines for.

The biggest production diskettes are the ones made by Amlyn and Drivetec, each of which provides about 2.5 megabytes formatted per diskette. Kaypro adopted the Amlyn drive for its mostly-unsuccessful 'Robie' desktop unportable personal computer. We predict the 'Robie' will be even less successful in the future because Amlyn's sugar daddy was Dysan and Dysan cut Amlyn's purse strings a while back. (If you have been watching closely, Dysan has had some recent problems, mostly related to a lack of profits, and is in the process of being acquired by Xitek, a competitor.)

Drivetec is second-sourced by a little company called Eastman Kodak, and has been selected by Wang among others for future production. Drivetec would seem to have a bright future if not much present, if you will excuse the phrase.

Medium-high density 5 1/4 inch disk drives have been commonly available in Japan for nearly two years now. These drives having been thoroughly field-proven. IBM adopted them for use with its new AT which gives those drives instant credibility in the U.S. market. IBM

Page 14, Column 1

formats these diskettes for 15 512-byte sectors per track, 80 tracks per side, 2 sides. That's exactly 1200 Kbytes.

We are going to use these same Japanese drives formatted for 8 1024-byte sectors per track, 80 tracks per side, 2 sides. That's exactly 1280 Kbytes. That format will be compatible with our Blue Sky I, which will have 4 1024-byte sectors per track, 35 tracks per side, 1 side. That's exactly 140 Kbytes (so what did you expect on an Apple Disk II drive?).

(There will be a short pause while the folk who have been venting much frustration and spleen over our refusal to embrace their favorite Apple DOS are introduced to the folk who will very soon now be venting much frustration and spleen over our refusal to adopt all things PC-DOS. Each of these two groups argue for compatibility; if you will read the previous paragraph carefully you will see that we are doing it OUR way for - gasp! - compatibility!)

(Horrible second thought: are some of those folks who have demanded that a HALGOL DOS be compatible with their own favorite 6502 DOS now going to demand that HALGOL DOS be fully compatible with BOTH their favorite 6502 DOS AND PC-DOS? Don't bet against it; we have received some bizarre recommendations in the past, many of them from folks who should know better.)

Developing HALGOL on 140K DISK IIs is becoming increasingly difficult and irksome. And we are getting tired tired tired of that slow slow slow 6502-controlled disk access. So we are going to use a pair of 1.28 megabyte (formatted) diskettes for internal program development, starting as soon as we get working prototypes, which we have now, plus working DOS primitives, which we don't have now but which are being worked on. True, 1.28 megabyte floppies aren't as big and fast as a Winchester but the backup problem ISN'T!

If these diskettes prove successful, we will probably offer them for sale in some form. But it is much too early to discuss configuration, price or delivery. So we won't, for now.

MORE ECONOMICS:

A few years back, Digital Acoustics just happened to be one of the first stops an editor of a national electronics publication made after visiting the Tandy Corp in Texas. With eyes opened to record width, he rhetorically asked "do you know just how much money Tandy carries just in its CHECKING account?" And then he mentioned a figure which was in what a banker would describe as being in the "low to medium eight figures" - between $20 and $30 million. The editor was disappointed when we failed to get excited.

Page 14, Column 2

Look, any company has to have at least two weeks' cash flow in its checking account to comfortably handle payroll and miscellaneous purchases such as paper clips, toilet tissue and light bulbs. Since Tandy had sales of just over $600 million per annum at that time, their checking account was just right for that dollar volume. (A large company will logically keep monies in excess of that two weeks' cash flow in some form of interest-bearing account.)

Small companies look less like a statistical universe and so really should have a month's cash flow in the bank to be comfortable. Digital Acoustics, as we have pointed out before, is a small company. Small companies also tend to have much wider (and more sudden) variations in sales than large companies, which is another aspect of that less-like-a-statistical-universe. Just in the calendar year 1984 Digital Acoustics has experienced month-to-month sales variations of as much as 2-1, both up and down. In September, the 2-1 variation was DOWN!

We suddenly found ourselves with more overhead - clerical help and programming staff - than we could justify at the new, lower sales rate. To make a complicated story (running a business is NOT simple - try it!) short, we laid off one secretary and one full-time programmer to reduce our overhead to match the new, lower sales volume. We did NOT lay off anybody directly associated with hardware design or production and hence did not reduce our shipping capacity.

Contributing to our decision and action (around the first of October) was what we read in Electronics News, Electronic Engineering Times and the WSJ - MANY companies having massive layoffs, common second and third rounds of layoffs and even a significant number of companies entering Chapter 11. We decided that it was time for the company to run lean - and discovered at that Motorola 68020 seminar that everybody else (other companies, that is) had done what we just had, only three months earlier. Our former full-time HALGOL programmer, Reginald B., is now working for a large company which makes OEM products, some of them 68000-based, and which runs one or two-page color ads in Mini-Micro Systems.

We continued to have slow sales in October, and then sales dramatically increased this month (November), which by coincidence is right after our new price list came out. Right now it looks as though sales will hold up through the end of the year, but our crystal ball isn't calibrated beyond that.

Since we have been honest with you in good times we really should be honest with you when the going gets rougher. We are running lean and we plan to be around for awhile yet!

Page 15, Column 1

WE GET MAIL:

The following is a product release from Ulrich Schmidt:

Modula-2 for DTACK boards.

"Inter68, the newest version of my P-code interpreter for the 68000, is now able to run Volition System's implementation of Modula-2! The Modula-2 version supported is 0.3n - older versions such as 0.3g will not work. The Modula-2 package must be purchased separately from Volition Systems, of course. In all other respects, Inter68 v1.3 is fully upwards compatible to previous versions, i.e. it can run Apple Pascal as well as Modula-2. Features:

"- The following MODULES are provided in source form: TurtleGraphics, AppleStuff, MathLib0, MathLib1 and Doubles. MathLib0 allows Modula-2 programs to access the built-in transcendental routines, while MathLib1 and Doubles implement double precision arithmetic. All floating-point routines may optionally use the 16081 math chip.

"- Interrupts and the associated IOTRANSFERS are "sort of" supported. The can be no true interrupt support because there is no way for the 6502 to interrupt the 68000 short of a complete reset. (FNE, did you ever consider to bring out the interrupt lines?) Therefore, the service of 6502 hardware interrupts is postponed till the next I/O operation, which in turn means that programs that use IOTRANSFER must do some polling in order to give interrupts a chance to be recognized.

"- Inter68 can optionally use the Grande refresh interrupt as a (highly accurate) real-time clock. The resolution provided is 1/20 second. Pascal and Modula-2 programs can access the clock by means of the intrinsic TIME procedure.

"- Inter68 now has its own startup programs: SYSTEM.ATTACH and SYSTEM.STARTUP have been renamed 68000.ATTACH and 68000.STARTUP, respectively. This means that you can have different initialization programs for Apple PASCAL and Inter68, all on the same disk.

"- A configuration utility has been supplied that allows easy customization of memory size and volume number parameters; no re-compiling and re-assembling required.

"Modula-2 and the DTACK boards: a perfect marriage? After all, it's a combination of the state-of-the-art in software and hardware engineering! The price of the package is $95 for newcomers and $50 for buyers of previous versions (includes disk, manual, shipping and handling)."

Page 15, Column 2

Ulrich Schmidt
An der Junkersmuhle 33/35
5100 Aachen

We want it placed into the record that we were NOT responsible for the wording of that last paragraph! About that interrupt: while the older static RAM DTACK boards indeed do not have interrupts, the Grande does, as you have obviously figured out. Why not use your modified interrupt routine to peek at bit 1 of the status line - a bit which can be set or cleared by the 6502 and which is not used by any other software? Peek maybe every 1/20 second, although it is possible to peek ever 1/500 second! True, this constitutes polling, but at least it is INVISIBLE polling, Ulrich - FNE

"After reading your views on Winchester disks and backup in several of your last newsletters, I thought it would be appropriate to share with you and your readers some of our experiences with the Corvus system. We currently use a Corvus Omninet network with three disk drives installed as well as four other systems with single user drives. Three of these systems currently have DTACK GROUNDED boards connected and we have just received another six GRANDE boards to add to the various processors around the laboratory.

"We have been concerned about potential failures in the Omninet systems since the drives operate 24 hours a day, and some hardware failures have occurred. We have not experienced any routine problems in cycling power on the disks or other normal operations. That is not to say that we have not temporarily lost data. There have been instances of data loss caused either by programming errors, incorrect selections of deletions, or, in a couple of instances, errant operations of the disk due to lightning strikes within the immediate vicinity. Fortunately, the disks are backed up routinely using the video tape backup system available from Corvus (the Mirror system). This relatively inexpensive system uses standard video tape decks as a digital recording system. The most sophisticated version uses an Omnivision NV8200 tape deck which can be controlled remotely by the Mirror interface.

"In our network system, a backup is made every night at 2:00 AM. This backup is done automatically and involves not only writing the data to the tape but also rewinding the tape, verifying the backup is correct, and logging the results out to a spooler. For individual systems operations, the backups are normally done manually, and require twenty minutes for a 10 megabyte drive. The backup itself is unusual in that each block is written four times on the tape. With such quadruple redundancy we have never failed to be

Page 16, Column 1

able to restore data to a disk drive. In fact, the system has proven to be so reliable that we use the video tape systems as archival storage for our data files. As a backup system to a Winchester disk, we find the video system to be more reliable than any of the other backup systems we use for the various computers in our laboratory. Thus, we are not hesitant to use the Corvus disks with any of our systems, and in particular our DTACK boosted Apples.

"I might also add that we are users of the Inter68 PASCAL software and are using it with great success. We have seen speed-ups in many of our applications programs, which are generally compute-bound, by factors of 16. I might also mention that we have started to repackage our systems, hiding the Apple and 68000 inside a floor-mounted aluminum box and replacing the Apple keyboard with the Omega II board from Zicor. The result is a very pleasant PASCAL development system which is being used throughout the laboratory."

Tom K. Lewellen, Ph.D.
Associate Professor of Radiology
Division of Nuclear Medicine, RC-70
University Hospital
University of Washington Seattle WA 98195

Tom, your report is consistent with the information we had gathered. There is indeed good, reliable backup available at a low cost per system where a number of systems are involved. The point we were making is that there seems to be nothing which is both inexpensive and reliable available for the true personal computer user who has only the one computer, and there is nothing in your report which would contradict our point. We're glad to see that you're making good use of your DTACK boards - let us know if Ulrich Schmidt's new Modula II is of interest in your application? - FNE

"...the new, improved keyboard is here, sitting in its box next to the box with the PCjr. In order to expand my minimal unit to the 128K disk version, local suppliers want $435 plus the price of DOS - and that is without a printer port. My total hardware cost would then be $1100 for a unit that would not even match the latest Sanyo (MBC555-2), now on sale with six software packages for $995. The cost of upgrading my PCjr is equal to the cost of a non-mythical case and power supply from DA plus part of an interface system, so I pass on upgrades for the PCjr.

"The Cascade advertisement is a nice one, but WHERE'S THE DISK? Voice command facilities are fine for very busy design engineers who must minimize their expenditures of physical energy. Would it not be wise for Cascade to supply a harness that permitted engineers to suspend themselves from ceilings and hang

Page 16, Column 2

by their heels, the better to promote a much needed flow of blood to the brain?" FMFC Nils D. Jr, Wethersfield CT

To you newchums, Nils is a long-time correspondent (Formerly Mostly Faithful Correspondent) whose New England, um, THRIFTINESS is legendary. Nils hates 'fruity machines' and will not purchase a DTACK board until the price drops below $17. Meantime, Nils collects other computing devices, such as his PCjr and his EMS 68000 board, which sit unused in boxes.

Nils, you should know that CADD systems costing over $30,000 will come complete with desk and hidden disk to prevent damage from spilled coffee, cigar ashes etc. As an engineer, we pass on the ceiling harness. How about a reclining lounge and dancing maidens providing peeled grapes and other delectables? - FNE

"I ran across a copy of DTACK GROUNDED from a friend and was thrilled to see that someone puts together a nice concise newsletter about simple 68000 systems." Roy H., N. Hollywood CA

Roy, this rag has been called lots of things but we do believe this is the first time anybody called it concise - FNE

"I was recently subjected to a sustained barrage of your publication by someone with free access to a Xerox machine (an IBM copier would gag)..." Alan C., Sunnyvale CA

See what we mean, Roy? - FNE

In recent issues we have had readers send a check for software without specifying what software they wanted, demand (twice!) that we change their address without providing that address, and now possibly the ultimate: we have a check for $25 drawn on the American correspondent bank of an Australian bank. Since we opened the letter personally on a Saturday, we got to see the envelope and there was no return address. There was nothing accompanying the check or on the check indicating who wanted a 10-issue subscription. Somewhere there is an Aussie wondering where his paid-up DTACK subscription is. (Does standing upside-down all the time affect Aussie brains?) We haven't cashed the check.

About envelopes: except for letters which we personally open on Saturday, we are not permitted to see the envelopes as our secretary destroys them immediately. In fact, we are not permitted to read the mail until our secretary has confirmed that the

Page 17, Column 1

envelopes are on their final journey to a landfill. There seems to be some sort of union rule about this. So anything you want us to read needs to be included in the letter you send us - if, considering that Aussie example, you include a letter...

"What in the hell is a Dobsonian mount?" Eric L., Faulconbridge Australia

A Dobsonian mount is an alt-azimuth mount for a LARGE Newtonian-type reflecting telescope intended for deep-sky viewing. Deep-sky viewing implies low magnification factors, so tracking what you are looking at isn't a problem. Dobsonians use teflon bearings so you can turn the telescope horizontally (that's the azimuth) and a second bearing so you can tilt the telescope up and down. Sounds crude, but it isn't - it works great for eyeball-type astronomy. It is, however, absolutely useless for photography or for high-magnification viewing. Our Dobsonian is an Oddysey One, with a 13.1 inch diameter reflector. The 110 lb mount is light for that lens but folk who get beat over the head with it tend to STAY beaten - FNE

"...I've finally gotten around to subscribing to your rag, as well as picking up all the back issues. It is really fascinating to see many of my long suffering views expressed in print, especially on the subject of HLLs, 8086 vs 68000, and UNIX. A couple of years ago you could get lynched just by mentioning that you had heard of assembly language, much less programmed in it. Today the situation is improving, but there is a long way to go. On the other hand, as long as everyone else keeps refusing to catch on, us assembler hacks will have an unbeatable advantage.

[A page and a half of excellent arguments in favor of assembly have been deleted for brevity.]

"Many HLLs, like PASCAL, are like welfare states. They provide the programmer with a safety net. The cost is you have to tell the compiler EXACTLY what you plan to do with every variable. Well, as far as I'm concerned, that's none of the compiler's #$#%# business. Safety nets are for losers, people who can't hack it. I need the freedom to do whatever I want, whenever I want, and I'll take the responsibility for the results.

"One subject I do not really agree with you is Mac(k). But perhaps I am biased since I am the very first person outside Apple to write a commercial program for the Mack ENTIRELY IN ASSEMBLY LANGUAGE. This is a real program, distributed thru major distributors like Softsel and Micro D. And guess what - the first thing the folks at Apple said when we demoed it to them was 'wow - that's fast!' The product is selling quite

Page 17, Column 2

well, but it grieves me to think how much better it could sell if I had only written it correctly, in PASCAL. Oh, well, live and learn!

"Anyway, back to the Mack. When I first saw the documentation (1300 pages) I said, 'Oh my #@$#$, what have they done!' Surely they couldn't expect a mere mortal to learn all of that in just one lifetime? Perhaps re-incarnation is in order? The Mackintosh toolbox ROM is definitely a very complicated and ambitious piece of software, and is not to be mastered in a few spare evenings.

"As it turned out, though, it only (only?) took a couple of months of spare evenings to get a pretty good idea of what was going on. And as I began to actually USE the system, I became more and more impressed. Why's that, you ask? Well, no system designer can think of everything. On every other OS I have used, I have always run up against a feature that my program absolutely required, but was not in the OS. To get around this problem, I would have to devise an awkward kludge to somehow bypass the OS and get the problem solved. But so far, I have not found ONE feature missing from the Mackintosh toolkit. Unlike the user interface, the Mack programmer interface is VERY flexible. They give you 5 ways to accomplish everything. They even give you ways to do things that they tell you are NO NOs as far as user interface.

"Most OSs are simply collections of subroutines which don't relate to each other very much. The Mack toolbox, however, is very coordinated - obviously designed primarily by one person. A committee (the social equivalent of a HLL) could never have designed a system which hangs together as well.

"There are a few rough edges, especially in the print code, which seems to be a black box even to the people at Apple. (Rumor has it that a mysterious person named Owen is the only one with the key to the 'prince of darkness' print code.) All in all, though, this is a very powerful system for the programmer which can save a lot of time, especially in setting up mouse and window type applications, once you learn it. Just don't expect to learn it tomorrow.

"...the Mack is not my first exposure to 68000 assembly language, since I've been programming on Alpha Micros for about 5 years. (Alpha Micro converted to the 68000 about three years ago.) You briefly mentioned the Alpha Micro earlier this year, but apparently you don't know much about it. The mention noted that most 68000 multi user computers, like Fortune and TRS-16, were not doing well, but that Alpha Micro did seem to be doing well for some reason. I guess you didn't know that EVERY line of code in Alpha's OS, utilities, and BASIC is WRITTEN IN ASSEMBLY LANGUAGE! Another victory!

Page 18, Column 1

"The Alpha is such a good development system that I write my Mack software using it. The code is assembled and linked on the Alpha, and then sent to the Mack thru an RS-232 port. That way, I don't have to use the (aargh) LISA to develop software for the Mack. You'll notice that we have released one of the first 25 programs for the Mack, the first in assembler, and WE DID NOT START UNTIL MAY. Incidentally, last spring the folks at Apple assured me that there was NO NAY software for the Mack could be developed on ANY machine but the LISA. Sort of reminds me of your experience over the years." Jim R., Huntington Beach CA

(Jim is with ProVUE Development.) Jim, with all of the dozens if not hundreds of man-years Apple has lavished on developing Mack, how come you can't develop Mack programs on Mack? Another thing: just what is a 'spare evening'? - FNE"...I have crossed paths with the mysterious Trump Card (not Board, it makes a better pun that way). We had a need to be able to run Z8000 software, and there seemed to be three ways of doing that: the Trump Card, buying an Olivetti PC, and buying a development station from Zilog. For a number of reasons, of which the first was cost, we ended up going with the Trump Card. (Have you priced a development station from Zilog lately? It makes the EXORturkey price look quite competitive.)

"The Trump Card, however much or little Ciarcia had to do with it, does exist, and the articles in Byte were substantially accurate. It really does come with quite a bit of software (compiled BASIC, C, funny assembler called Y, and can act as a RAMdisk if you want to run programs on the PC), which in very large part work. We have found a couple of problems with them, but there is nothing which we haven't been able to get around, and the bug frequency is no higher than other new software. Performance is as good as claimed; not too surprising. The card comes with 512K and the developers are working on being able to expand that to 1 meg Real Soon Now. (We will probably get that expansion when it becomes available.) As for whether it is the second best attached processor, it is really a question of what you are looking for. First, since yours is attached to 6502 based systems and theirs to 8088 based systems, not too many people have a real choice. Likewise, if you are going to be doing all of your development in assembly, the 68000 is a far better choice; just ask the guy (working) on our Trump Card, who is doing just that." Bruce N., San Pedro CA

Bruce, that bit about who had the best or second best attached processor was obligatory kidding on our part. Considering the considerably lower memory chip prices which now prevail, it will be interesting to see if Ciarcia & (presumptive) company keep their current

Page 18, Column 2

$200/128K pricing - and if so how it will affect their sales. (The latest price list we have, courtesy of Ivan S., shows a zero-K Trump card at $995 and an equivalent card with 256K at $1395.) Thanks for the report - FNE

"...Anybody who likes assembly language, the 68000 and John D. can't be all bad. I read that Mr. D has a final manuscript in his files titled 'A Black Border for McGee'. Publication day is going to feel like a death in the family - I started riding on the Busted Flush in 1964.

"We are a two man company that has been in the micro-based communications processor business since 1976. Designing, manufacturing (thru subs), selling, installing and servicing. No promo intended here - just wanted you to know I sympathize with the trials of running a small tech business. How the hell do you find time to write a newsletter between filling out government forms, chasing unobtainable TTL and listening to every customer with a great idea for improving the product? Clones?

"...Our new design will have six 10MHz 68000 processors conversing thru Mostek 4501 FIFOs (DMA horror stories give me insomnia)... Although you thrive on criticism (valid and otherwise) - I can only find one small item. If your 68000 can do a 32-bit add in six cycles (DG #14, p.6), I'd like to trade it for one of my losers that takes eight.

"We users of the only true high performance micro are grateful to Eloi and the omnipotent Mr. Jobs for helping to keep the lights burning in the Texas glass factories. Keep up the good work. Sorry to ramble on for so long. The good news is that I seldom write." Kurt F., Colorado Springs CO

Kurt, as a lifelong bachelor we have no wife or kids to neglect. Since we don't watch TV much (football excepted) that give us lots of time in the evenings and on weekends to do things - like work - that normal folk don't. Fortunately we have chosen a line of work which often seems, to us, like play. Even so, your implication that we can't listen to all the helpful suggestions we get is correct - we ignore most of them (ALL of the suggested improvements to HALGOL these days)! As you would suspect, this adds to our considerable reputation for not being a nice person.

Actually, we DO listen to selected persons. These are the persons who have contributed to Digital Acoustics' coffers in the past through purchases. The larger the contribution the closer we listen (and the more carefully reasoned the advice we offer). Can you tell us a better way to sort the wheat from the chaff?

Page 19, Column 1

About that six-cycle 32-bit add: according to Motorola's second, third, and fourth editions of its 68000 manual, six cycles is correct. (e.g. 4th edition, p.189, Table D-4, line 2.) Can we help it if we (sigh) never noticed the little footnote that says the time is eight clocks if the address mode is register direct (and any other address mode ALSO adds cycles!)? Remember that Ian Fleming once killed off James Bond but then resurrected him when his publisher dangled enough money! Perhaps John D. McDonald will show greater strength of character. An aging beach bum is not a credible attracter of stuffed bikinis, after all - FNE

"I've been reading your newsletter regularly for a year or so, and would like to volunteer some information that you may find helpful. On page 24 of the Aug issue you gave me the distinct impression that you believe the 'D' in 16081D-6 and -10 stands for a D level mask. That D actually refers to the ceramic DIP packaging. The mask revision level, if visible at all, is stamped in ink on the underside of the chip. At least, this is the case with my rev G 16032 CPU.

"That having been said, I'd like to put in my two cents worth on the HLL/UNIX issue. I agree with you that operating systems and general purpose applications packages are best written in assembly language, so long as one is targeting a specific, stable machine/market. However, HLLs are quite useful for production applications when the target market for the software is diffuse. It's more cost-effective to write one C or (shudder) PASCAL program and recompile it for several machines than to write three or four assembly language programs, even if you assume that the assembly language programs can be written and debugged as quickly as the HLL code. I wrote nothing but assembly code for better than four years, and I'm still pretty good at it, but I find that I can get a good C program written and running in less than half of the DEVELOPMENT time of assembly code. Of course, it may be twice as big and/or twice as slow (depending on language, machine, and compiler), but often that's an acceptable tradeoff. Any decent HLL development system allows you to write time-critical and space-critical code in assembly language, which I routinely do.

"UNIX is useful in much the same way. UNIX provides people such as myself (and people at Pyramid, and Ridge, and A T & T, and National), who are working at realizing new processor architectures, with a generic operating system, complete with basic utilities, developmental tools, and a growing body of portable applications, that can be used to make a useful, if suboptimal, system around virtually any byte-addressable machine in a very short time at a relatively low cost. This encourages innovation in

Page 19, Column 2

processor design, which I think is very positive. Those machines that prove worthwhile will sooner or later attract people to write assembly-coded applications if the performance gain makes for a competitive product." Kevin K., Palo Alto CA

Kevin, we appreciate your missive for more reasons than you might suspect. For instance, we will be able to point to the second sentence in your third paragraph if anyone questions certain aspects of our own prose style...

On more technical matters, we agree with most of your assertions except the last sentence. Surely the mass personal computer marketplace features specific, stable machines (C-64, Apple II, IBM PC) and thus quite properly get assembly-based application programs from all of the software houses who want to be profitable. And the 'performance' of the UNIX crowd is already so abysmal (they SHARE CPU CYCLES! Mama mia!) that one more inefficiency probably won't be noticed, and it's corporate funds being wasted anyhow, right? About that last sentence: if a machine starts out with slow, inefficient software how will it ever be popular enough to provide the customer base needed to attract the assembly language programs which, as you have accurately pointed out, are more costly to develop?

Finally, would you please notify the boys at Murray Hill about the miraculous C compiler that produces code which is only twice as slow as assembly language? A T & T NEEDS that compiler DESPERATELY - FNE

"The reason small 68000 systems have not gotten off the ground is that there is no standard, nonproprietary, small machine operating system. If I build a small Z80 or 8086 system in my garage I just put in CP/M or MS-DOS and I am away. I cannot do this on the 68000... Will CP/68K ever be available for the DTACK boards? Is PICK implementible on a small single-user system?" James D., Dundas Australia

MS-DOS runs $60, quantity 1. CP/68K runs $350 and at that price will NEVER be made available by us for DTACK boards. At $60 and without a five or six figure up-front fee CP/68K could be attractive. Pick is implementible on a small system in principle but will not be any time soon (except the IBM PC/XT, for which PICK is available at around $1000). It now looks as though we are going to have maybe the first SIMPLE 68000 operating system right here at Digital Acoustics - see BLUE SKY REPORT elsewhere in this issue.

James, Pick happens to be located nearby and we do know some stuff about it that is not general knowledge, including the fact that Pick's problems in recent years mostly revolved around having TOO MANY customers! - FNE

Page 20, Column 1

Lee M. of Arlington, TX has written a number of reasons not to do BLUE SKY, all of which have to do with 6502-related compatibility. Sorry, Lee! It has been many moons since we have had any interest in being compatible with anything whatever on the 6502. Why, we'd as soon spend time worrying about being compatible with an Intel 4040-based tape machine! Read about BLUE SKY in this issue and see how the compatibility we are concerned with is making the Apple Disk II hardware compatible with some more advanced 68000-based hardware! (Psst! Hey, Lee! It's 16-bit time! Honest! - FNE)

BLUE SKY REPORT.

Today is 21 Nov, and this morning James S., our project engineer, was able to correctly write and read a 1024 byte sector on our prototype high-density floppy disks, the ones which use IBM PC/AT technology, meaning two-year-old Japanese technology. Here is some data:

The disk has two sides, 80 tracks per side. We are formatting it for eight each 1024-byte sectors per track per side. That's 1280 sectors at 1 Kbyte even per sector, or 1.28 megabytes. That is equal to MORE THAN NINE Disk IIs at 140K per Disk II! Yum!

The rotational speed is 360 RPM or 6 RPS. Since the disk cannot read or write to both sides at once, the minimum time required to cover the disk (assuming infinitely fast track-to-track access etc.) is 160 tracks times 1/6 second per track, or 26.7 seconds. Naturally, infinitely fast steppers we don't got. Still, the asymptotic limit of data transfer, reading or writing, is 1280 Kbytes per 26.7 seconds, or 47.9 Kbytes/second sustained. (Now, who was it who wanted us to use DOS 3.3 at about 1 Kbyte/second?)

Before we can estimate the actual sustained data throughput, we have to know something about how the DOS works. We are going to assume that the DOS works the same way as the first (limited purpose) DOS we wrote: a given file is ALWAYS recorded in ascending track/sector order. (NEVER in descending order, even for one sector.) It turns out this provides the fastest possible data throughput for the high-density floppy. It also is a technique which is totally incompatible with DOS 3.3 (sigh); maybe you are familiar with the way UCSD PASCAL DOS worked on the old TERAK LSI-11 computer?

This technique dispenses with a BAM (Block Availability Map) and instead just keeps track of the next available sector. When a file expands, the end of the file is recorded on the next available sector without regard to any unused sectors which might be located on nearby tracks. It also means that the disk tends to

Page 20, Column 2

accumulate 'dead' or unused sectors, reducing the effective capacity of the disk. Since we actually used such a DOS for years, it turns out the 'dead' sectors accumulate at a rate of less than 5% of the disk capacity per month even when the disk is being heavily used for program development. A 'Collect' function performed disk-to-disk can transfer the entire disk in about 60 seconds while reclaiming unused sectors and placing all files in the correct track/sector sequence. (We called the program we wrote to perform this function "RUN FAST' before we learned that other folk used "COLLECT": we wrote that old DOS back in late 1976!)

Now that we know how a file is allocated across the disk tracks and sectors, we can calculate the disk overhead. We will assume that the 68000 is more than fast enough to read or write sectors in sequence in conjunction with the Western Digital 2797-02 controller, although this has not yet been proved.

With a rotational period of 166.7 milliseconds and 8 sectors per track, each sector occupies a 'time slot' of 20.83 milliseconds. The track seek time is 3 milliseconds per track plus a 15 millisecond settling time at the destination track. When we are stepping track-to-track, that's 18 milliseconds, or 2.83 milliseconds FASTER than one 'sector time'.

Suppose that each track has the 8 sectors numbered 0 thru 7, with sector 0 being recorded immediately following the index hole on the soft-sectored disk (the Disk II is made as cheaply as possible and hence does not have an index-hole detector). The remaining sectors on each track are recorded in numeric sequence. Let us see what the consequences would be:

If we wanted to read the disk as quickly as possible beginning with track 0 sector 0, we would go to track 0 and wait for the index hole. Then we would read the 8 sectors 0 thru 7 in sequence. As we finish reading sector 7, we are fast coming up on the index hole and sector 0 again. Now we have to step to track 1 and begin reading sector 0 - but it takes us 18 milliseconds to switch tracks! That means the next readable sector on track 1 is NOT sector 0, the one we want, but sector 1. So we have to wait as seven of the eight sectors go by before sector 0 comes around again!

That technique, which is the simplest, provides a sustained throughput of exactly 1/2 of the maximum, or 24 Kbytes/second. Now, that is not shabby, especially compared to DOS 3.3. BUT THERE IS A BETTER WAY:

We format the disk differently: track 0 has sector 0 recorded just past the index hole as usual but the next track up has sector 7 recorded just past the index hole, with sector 0 following sector 7. Track 2 has

Page 21, Column 1

sector 6 recorded just past the index hole, followed by sector 7 and then sector 0. In this way, sectors 0 thru 7 are recorded in sequence on each track but successive tracks in ascending order have sector 0 delayed one sector position with respect to the preceding track.

Now, to read the disk we begin at track 0, sector 0 as usual. After reading sector 7, the last sector, we step over to track 1. After waiting 18 milliseconds to reach the track and settle, we only have to wait another 2.83 milliseconds before the next sector arrives. And HOW ABOUT THAT, the next sector just happens to be sector 0, the one we want next!

That means we read (or write) 8 sectors, take one sector time to step to the next track, read 8 more sectors, take one sector time to step to the next track, etc. We are reading (or writing) 8 sectors out of every 9 sector times. That means we can read (or write) the full disk in 26.7 seconds times 9/8, or 30 seconds. (We are ignoring the 1/4 second disk startup time and the time needed to locate the beginning track and sector.) That means the sustained data transfer rate is 1280Kbytes/30 seconds or 42.7 Kbytes per second. Now, which reader was it who wanted us to stay with the 6502 and DOS 3.3?

Remember, we actually wrote a DOS structured like this in late 1976 and it is still working in 1984. THERE IS MUCH TO BE SAID FOR THINGS WHICH WORK!

Hmmm. 42.7 Kbytes/sec, sustained. Has a nice ring to it. Especially after a few weeks in which we have regularly used DOS 3.3 to load and save text files...

Persons who insist on 'DOS 3.3 compatibility, only with speed' will be treated more kindly than they deserve. DOS 3.3 is slow precisely because of the way it (almost doesn't) work, NOT because of the 6502 or cheapskate Woz's refusal to use a floppy disk controller chip. No? Then how come Apple's UCSD PASCAL can load an entire Disk II in under 10 seconds? The only way to speed up DOS 3.3 is to ELIMINATE DOS 3.3, which is what we are doing!

PORTABLE MADNESS:

The opening line of the L.A. Times' story on Comdex tells it all: "Portable computers are proliferating almost as fast as some of their manufacturers are going bankrupt." The opening line of the third paragraph is not too shabby either: "'There's probably never been so much expectation in the computer industry, and so little return...'".

Page 21, Column 2

Naturally, InfoWorld's Kathy Chin wrote a rave article about a new HP transportable at the same time. (You remember Kathy; she awarded InfoWorld's 'Product of the Year' to LISA software at the exact instant before LISA I passed gently into that dark night.) Now, pay close attention here folks: the new HP transportable hosts UNIX and supports, get this, MULTIUSERS!

Next year we can look forward to a UNIX briefcase computer which will support 32 users and the year after that a UNIX vest-pocket computer which will support 256 users. Isn't progress wonderful?

Kathy also tells us that 1985 will be the year that the flood of UNIX applications software will hit. Makes sense; it's about time somebody did something with those 600,000 UNIX machines that were sold in 1983. Remember, you did NOT read that here first; you read it in InfoWorld first!

Has anybody noticed that when you buy a $69.97 VIC-20 you get BASIC free, and that when you buy a $2000 Mack you pay about $200 for BASIC? Now, just how many of you have priced BASIC on a $25,000 68010-based UNIX machine? (Now that Mack nibble copiers are here, the average price paid for Mack BASIC will likely drop.)

THE BUSTED TRICYCLE:

Remember the summer of '83? The country was in the depths of the deepest recession in recent decades. Digital Acoustics was shipping a whole bunch of 12.5MHz no-wait-state 92K static RAM boards to hackers and universities and a much larger bunch of 220K static RAM systems to an OEM. (Those 220K systems went for over $2,000 each; today a megabyte goes for $1595. Ah, progress!) And a company called AMD was running ads for the 80286 microprocessor, ads which proclaimed the vast superiority of the 286 over the 68000 and contemptuously referred to Motorola's second sources being "spread out from here to Tokyo."

We are now running up hard on the heels of 1985. How many of you have seen an AMD 286? Not an Intel 286, an AMD 286? How many of you have seen any 286 that can outrun a 12.5MHz 68000? A 10MHz 286 WILL outrun a 12.5 68K in some applications, you know. Who's shipping product based on 10MHz 286s? Remember, WE shipped our first 12.5MHz 68000-based product on 1 June 1982, 2 1/2 years ago. Where's the 286? In the IBM PC/AT and running at 6MHz, that's where! (With, according to PC Week, several hitches in its getalong.)

Oh, yes: Intel just signed up Fujitsu as a second source for the 286. We think that when AMD resumes advertisements for the 286, they will leave out the contemptuous reference to Motorola's second sources being "spread out from here to Tokyo!"

Page 22, Column 1

POURNELLE WATCH:

As most of you know, Jerry Pournelle has gathered a bunch of his columns from BYTE and has published then as "The User's Guide to Small Computers." This is a 331 page semi-large format 'Baen Book' at $9.95. We reluctantly bought a copy on a recent visit to our nearest bookstore and then set it aside because we did not expect to like it. Lots of folks like Asimov and Buchwald gather their columns into bunches and publish them as books but if you read the original, forget it!

Well, we've now read the last chapter and the first two chapters. To our surprise the book is VERY interesting - and yes, we read all of Jerry's columns as they appeared in BYTE. Jerry has added a lot of commentary, for one thing. For another, it is downright SHOCKING to re-read Jerry's first columns, written in early 1980, and realize how unbelievably crude the state of the personal computer art was less than five years ago!

And then Jerry starts in on languages - and operating systems - again (with current commentary added). It is amazing how Jerry can one moment seem so intelligent (when we agree with him) and the next moment so downright stupidly wrong-headed (when we disagree with him). We recommend this book.

WORDS AND WORDS AND...

Jerry discusses word counts and page production and stuff - remember, he bought his first computer for use as a dedicated word processor to produce fiction. See for instance pages ix and 331 of the above book. It seems his typical BYTE column runs 7,500 words and the book in question over 100,000 words. He also mentions a typical production of 10 pages in a working day (pre-computer).

To an author like Jerry, a page is 30 lines (that means double spacing) of 60 columns - a format that leaves an editor lots of room for his blue pencil. A page of this newsletter, on the other hand, is TWO columns of 60 lines, 55 characters each. A word is six column positions on average (5 non-space characters followed by a space). Because the words don't evenly fill the columns (in general) the actual number of words is about 5% less than a simplistic calculation would indicate (3 char positions lost in an average line). Let's toss out that 5% for the time being.

28 pages in the format of this newsletter would be 30,800 words. The logo on the front and REDLANDS eat some of that, so say that an average recent DTACK newsletter contains 25,000 words. That's about 3.5 times the size of one of Jerry's columns. Four newsletters are about equal in word count to Jerry's book. (So far, we have personally written all of the

Page 22, Column 2

source code that has been published in REDLANDS and yes, it takes time to write that stuff too.)

That's a lot of words, folks.

The reason we were able to publish on a regularly monthly basis for the first half of 1964 was that we had a full-time HALGOL programmer on board, leaving us free to work on this newsletter on weekends. Now WE are the HALGOL programmer and HALGOL is what gets worked on for most of the weekend. So it now takes us about a month and a half to turn out a 28-page newsletter. We COULD, we suppose, cut back to 18 pages and publish monthly but somehow 18 pages seems kinda skimpy - it is amazing how our perception has changed since the first few issues of this rag. With 28 pages, we figure we have more leeway to put in some stuff that most certainly will not interest every reader, without short-changing any one reader.

Question: How can we get paid Jerry's word rate?

POURNELLE vs. DVORAK:

We may have been unfair to Jerry by asserting that a mention in Dvorak's InfoWorld column pulled in more new subscribers to this rag than a mention in Jerry's BYTE mail column. At the time we wrote that it was true, but apparently folks don't get around to that mail column for about a month after the magazine arrives. Weekly InfoWorld gets acted on quickly or not at all.

Right now, we are getting lots of new subscribers (informally called newchums in these pages, which is a nod to Heinlein's The Moon is a Marsh Mistress and is not meant to be derogatory) and we don't even know where they are all coming from. We received one $15 check with a copy of one page of a magazine which reprinted some of our rantings and ravings but the name of the magazine was not on the page. A 1/3 page ad by Springer-Verlag WAS, and our project engineer called Springer and asked what magazine ran that ad. Turns out it was The Journal of Nuclear Medicine! Another subscriber read something in MD magazine. MD? Medical Doctor? Mechanical Design?

Excerpts of this rag have been published by The Programmer's Journal, which is an IBM PC-related publication, by InfoWorld, by the late Peelings II, by Club Mack, and by several club newsletters. It should be obvious that we are getting a lot of $15 checks from folks who do not really know what we are about, and that means that some of those folks logically should not be interested in this rag. The odd thing is, we haven't received any complaints, except for one cancel-my-subscription note from a female person who objected to a specific short item in one newsletter. Statistically speaking, that does not make sense.

Page 23, Column 1

OUR 'PRECIOUS TIME' ?

We just received a letter from a W. German who apparently disapproves of our haughty refusal to answer all correspondence: "I hope I did not take up too much of your precious time..." Now, is that snide? Naturally, we have nothing to do with our time but write lots of letters. (We read that letter at the office on a Sunday. At 8:20 A.M.! Honest!) There are other letters we don't write:

WE SELZ WHAT WE SELZ,

and what we do not sell, we do not sell. If you are one of the persons who have offered (demanded?) to buy something that is not on our price list, you will have noticed that we have not replied. That is not an accident. We receive too many requests for stuff we do not sell (usually a custom-stripped version of something we DO sell) and no, we will not explain why.

If you have expected a letter from us and have not received one, the reason is simple: we are lazy, and writing letters interferes with our mornings on the beach, our lengthy expense-account lunches, watching afternoon soap operas, our Wednesday golf match and sailing to Catalina on the weekend! Tsk.

68020 WATCH:

We have been guilty of overenthusiasm in estimating the performance of the 68020. Motorola has now published a fairly detailed performance analysis. When they speak of a 4-1 speed improvement, they are talking about a 16.67MHz 68020 vs an 8MHz 68000, each with no wait state, and code optimized for the 68020. A no-wait-state 16.67MHz 68020 needs, according to Motorola's literature, 90 nsec SYSTEM access time on the RAMs - and that includes the delays of address multiplexers, decoders, buffers, and data buffers. Translation: 68020 systems will have wait states unless you have unlimited DOD-type dollars. What you and we are presumably interested in is the speed improvement using 150nsec DRAM and comparing the 16.67MHz 68020 with the 12.5MHz 68000 - and that looks to be about 2-1 even. The initial sample 68020s run at 12.5MHz so we are looking at less than 2-1. (These figures assume the use of a 32-bit data bus for the 68020.)

When the 68020 comes out we will return to our 68000 strategy of over three years back: we will sell boards with empty sockets until such time as the price drops to something reasonable and we can begin to buy in quantity and hence buy for less than YOU can. Or don't you understand that if we buy a part for $610 (the current price, if and when Motorola delivers) then we have to sell that part for $1200 to $1500 if we want to stay in business?

Page 23, Column 2

Those persons who think that on July XX, 1985 Digital Acoustics will replace its $995 half-gallon 68000 board with a $995 half-gallon 68020 board are VERY BADLY mistaken! Also: the 68020 has MANY additional addressing modes and a few added instructions as well. Anybody see a 68020 resident or cross-assembler out there? Do not mistake us - in the future, the 68020 will phase out the 68000 at Digital Acoustics. But that future might be a LOT further off than you think.

MATH CHIP STUFF:

The 68881 has finally seen first silicon; now we will see if Motorola can break the existing record time of 2.5 years between first silicon and a working (production) complex F.P. math chip. We would like to be optimistic, but anybody who 'bets the company' on early arrival of production 68881s would be a fool, considering the historical record. (We DO think Motorola can beat that 2.5 years; but by how much?)

Nat Semi is having better luck with the 32081 (10MHz) than with its 32016 (8MHz max). We have NOT forgotten Wonderful Weitek, it's just that we can't make up our mind whether the forthcoming Weitek double precision chips will eventually be useful when coupled to a high-performance micro. Those chips are, at first glance, WAAAY too high-powered to work with even the swiftest of general-purpose microprocessors. And at $2200 for a two-chip set, forget it!

But prices do come down - especially since Analog Devices has announced equivalent models (and has seen FIRST silicon if not WORKING silicon). There is nothing like the good old learning curve and good old competition to bring those prices down. At $220 a two-chip set why wait 6 to 10 microseconds for a 32081 multiply when less than 1 microsecond is available? Except, of course, that a general-purpose micro cannot feed data and commands to that chip set in 1 microsecond... but then, the result is still SIGNIFICANTLY faster than the 32081... If you get the idea that we are ambivalent, you have it right!

And now AMD, which is really a well-run high-tech company, has announced a one-chip bipolar single-precision FP math chip which executes all instructions (add, subtract, multiply but NOT divide) in, get this, ONE (125 nsec) clock cycle! That chip, which apparently exists (although we are not certain), is the first of AMD's new line of 32-bit bit-slice chips.

ERRATA DEPT:

In issue #6, turn to page 24 and see the third paragraph, the one just above the headline 'ZERO-BASED INDICES". In that paragraph, cross out the words "and high bits of the first word of the array descriptor".

Page 24, Column 1

There is another matter which was correct as of the last issue but has since been changed: ALL arrays, even the ones with only one dimension, have a "type flag word" preceding the array descriptor offset, not just the arrays with more than 3 dimensions. And that means that the array offset ALWAYS points to the # of dimensions in the array descriptor table. The HALGOL run-time code is accordingly changed; the first example at the top of page 25, col 2 would have a type flag word between <MVA> and [ N ], for instance. Since all of the indices in that example are constants, the "type flag word" would be $0000. If the indices were all integer varns, the "type flag word" would be $E000. If only the last index were to be changed to an integer varn, the "type flag word" would be $2000.

A major result of this change is the reduction of 60 action addresses to just 4 (see the end of page 24). This change was made because we did string arrays this way, and they worked out ever so nicely!

HALGOL REPORT:

Since the last issue we have the string assignment function fully operational, string arrays fully operational, numeric (FP and integer) fully operational in an improved manner, arrays incorporated into the PRINT statement, and we are halfway finished with DATALOAD and DATASAVE statements with filenames and an argument list which accepts any combination of the three simple variable types (FP, int, str) or the three array types. These two DATA statements work with the binary image of the argument, NOT Mickey-Mouse stuff like PRINTing to a disk and then INPUTing from disk!

Let us emphasize that it is the string ASSIGNMENT function which is fully operational; there are lots of string manipulation functions which have not been done.

The HALGOL cup is now 75% full. IT IS ALSO 25% EMPTY! Depending on your personal temperament, you may focus on one or the other of those facts. If you are one of the knobby-kneed gentlemen featured on the front page of issue #31, HALGOL still does not use your favored syntax, and it never will. (All languages use their own syntax. If we can agree that everyone is out of step except Johnnie, WHO IS JOHNNIE?)

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

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

Page 24, Column 2

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

THIS ISSUE'S REDLANDS lists a small portion of the source code for the string assignment expression. Page 25 is the first page of the string assignment compilation code, and includes ALL of the code required to compile the right hand side of the equation - assuming the availability of the well-behaved subroutine "CHKMID" and the well-behaved and ubiquitous subroutines "SVARYCHK" (compile a string array) and "SVARCHK" (compile a simple string varn). It also lists the possible syntax of the string assignment expression; see the bottom of page 28 for an example.

Pages 26 thru 28 list the source code of just ONE of the well-behaved routines needed for simple and predictable implementation of arrays. This one, "LOADSTRA", is used at run time whenever an element of a string array is encountered.

First this subroutine adds the base address of the array descriptor table (line 265) to the descriptor offset in the HALGOL code. The resulting address points to the number of dimensions in the array descriptor table, which is fetched to register D3 (line 266). In the case of string arrays, the last "dimension" is really the length of each array element, so we decrement D3 to get the true # of dimensions exclusive of the element length (line 267). (F.P. and integer arrays have fixed element lengths of eight and two bytes, respectively.)

At line 268, we fetch the size of the first dimension. If this size is zero, we know the array has not been dimensioned. If it HAS been dimensioned, we branch to line 344 on page 27. Otherwise we check the number of dimensions. If that number is three or less, we default-dimension the array to 10 for each dimension and to 16 for the element length, the same as the default length for a simple string. If the number of dimensions is over three, we issue an error on the assumption that the programmer goofed!

If we have to default-dimension, we eventually arrive at line 344 with the situation in the same shape as though the array had already been dimensioned. Now we calculate the address of the array element, ending on line 397 when we add the array base address (from the array descriptor table) to D4. Finally, we move that address to A0 and the element length to D0.

Page 25

                         3 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 
                         4 ; 
                         5 ; STRING MANIPULATION CODE.  THE LEFT HAND SIDE OF 
                         6 ; THE ASSIGNMENT EQUATION CAN BE ONE OF THESE FOUR: 
                         7 ; 
                         8 ; (S AND N INDICATE AN INTEGER VARN OR CONSTANT) 
                         9 ; 
                        10 ;     A$ = 
                        11 ;     B$()= 
                        12 ;     STR(A$,S,N) = 
                        13 ;     STR(A$(),S,N) = 
                        14 ; 
                        15 ; THE RIGHT SIDE OF THE EQUATION CAN BE ONE OR 
                        16 ; MORE STRING ELEMENTS.  IF THERE IS MORE THAN ONE 
                        17 ; ELEMENT, SUCCESSIVE ELEMENTS ARE SEPARATED BY 
                        18 ; "+", WHICH IN THIS CASE INDICATES CONCATENATION 
                        19 ; RATHER THAN ADDITION.  POSSIBLE STRING ELEMENTS: 
                        20 ; 
                        21 ;    I.D. 0 = "LITERAL STRING" 
                        22 ;    I.D. 1 = A$ 
                        23 ;    I.D. 2 = B$() 
                        24 ;    I.D. 3 = STR(A$,S,N) 
                        25 ;    I.D. 4 = STR(B$(),S,N) 
                        26 ;    I.D. 5 = HEX() 
                        27 ; 
                        28 ; COMPILE A GENERAL HALGOL STR(B$() ASSGMNT 
                        29 ; 
 008C80: 554B           30 MIDSTRA  SUBQ.W  #2,A3          ;CORRECT WRK PTR 
 008C82: 36FC8E70       31          MOVE.W  #MSTRA,(A3)+   ;MSTRA ACTION ADR 
 008C86: 6006           32          BRA     MIDSTR1        ;CONTINUE 
                        33 ; 
                        34 ; COMPILE A GENERAL HALGOL STR(A$ ASSIGNMENT 
                        35 ; 
 008C88: 554B           36 MIDSTR   SUBQ.W  #2,A3          ;CORRECT WRK PTR 
 008C8A: 36FC8E68       37          MOVE.W  #MSTR,(A3)+    ;MSTR ACTION ADR 
 008C8E: 4EB88DFE       38 MIDSTR1  JSR     CHKMID         ;STR( ? 
 008C92: 677A           39          BEQ     SYNERR1        ;IF NOT 
 008C94: 6016           40          BRA     STR1           ;CONTINUE 
                        41 ; 
                        42 ; COMPILE A GENERAL HALGOL STRING ARRAY ASSGMNT 
                        43 ; 
 008C96: 554B           44 LETSTRA  SUBQ.W  #2,A3          ;CORRECT WRK PTR 
 008C98: 36FC8EC4       45          MOVE.W  #SSTRA,(A3)+   ;STRA ACTION ADR 
 008C9C: 4EB84C74       46          JSR     SVARYCHK       ;SVC STR ARRAY 
 008CA0: 600A           47          BRA     STR1           ;CONTINUE 
                        48 
                        49 ; COMPILE A GENERAL HALGOL STRING ASSIGNMENT 
                        50 ; 
 008CA2: 554B           51 LETSTR   SUBQ.W  #2,A3          ;CORRECT WRK PTR 
 008CA4: 36FC8EBC       52          MOVE.W  #SSTR,(A3)+    ;STR ACTION ADR 
 008CA8: 4EB84C70       53          JSR     SVARCHK        ;SVC STR VARN 
                        54 ; 
                        55 ; CHECK FOR AN "=" SEPARATING THE LEFT AND RIGHT 
                        56 ; HAND SIDES OF THE ASSIGNMENT EQUATION. 
                        57 ; 
 008CAC: 0C1800BD       58 STR1     CMPI.B  #"=",(A0)+     ;EQUAL SIGN ? 
 008CB0: 665C           59          BNE     SYNERR1        ;IF NOT 
                        60 ;

Page 26

                       257 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 
                       258 ; 
                       259 ; LOAD A STRING ARRAY ELEMENT'S LENGTH & POINTER. 
                       260 ; LEAVE STR ELEMENT LENGTH IN D0, POINTER IN A0. 
                       261 ; (LEAVE REGISTERS D6 AND A5 UNDISTURBED.) 
                       262 ; 
 008FAA: 3E1E          263 LOADSTRA MOVE.W  (A6)+,D7       ;TYPE FLGS TO D7 
 008FAC: 305E          264          MOVE.W  (A6)+,A0       ;FETCH ARY OFFSET 
 008FAE: D1F815C8      265          ADDA.L  SOADT,A0       ;ADD BASE ADR 
 008FB2: 3618          266          MOVE.W  (A0)+,D3       ;# OF DIMENSIONS 
 008FB4: 5343          267          SUBQ.W  #1,D3          ;DECR # OF DIMS 
 008FB6: 3218          268          MOVE.W  (A0)+,D1       ;1ST DIM 
 008FB8: 6662          269          BNE     LDSTRA4        ;IF NOT ZERO 
                       270 ; 
                       271 ; THE STRING ARRAY IS NOT YET DIMENSIONED.  FIRST 
                       272 ; CHECK WHETHER THE ARRAY HAS > 3 DIMS (EXCLUSIVE 
                       273 ; OF THE LAST DIM'SN, WHICH IS THE ELEMENT SIZE). 
                       274 ; 
 008FBA: 0C430003      275          CMPI.W  #3,D3          ;OVER 3 DIMS ? 
 008FBE: 6224          276          BHI     ERR58          ;IF NOT 
                       277 ; 
                       278 ; DEFAULT DIMENSION THE STRING ARRAY TO DIMENSIONS 
                       279 ; OF 10 EACH, WITH AN ELEMENT LENGTH OF 16 CHARS. 
                       280 ; 
 008FC0: 7800          281          MOVEQ   #0,D4          ;CLR 32 BITS 
 008FC2: 383C0640      282          MOVE.W  #1600,D4       ;DIM 2 ? 
 008FC6: 0C430002      283          CMPI.W  #2,D3          ;CHK DIM 
 008FCA: 670C          284          BEQ     LDSTRA3        ;IF 2 
 008FCC: 6206          285          BHI     LDSTRA2        ;IF 3 
                       286 ; 
 008FCE: 383C00A0      287          MOVE.W  #160,D4        ;DIM 1 
 008FD2: 6004          288          BRA     LDSTRA3        ;CONTINUE 
                       289 ; 
 008FD4: 383C3E80      290 LDSTRA2  MOVE.W  #16000,D4      ;DIM 3 
                       291 ; 
                       292 ; D4 = THE DEFAULT STRING ARRAY SIZE IN BYTES 
                       293 ; CHECK THE REMAINING MEMORY SPACE FOR ROOM 
                       294 ; 
 008FD8: 203815FC      295 LDSTRA3  MOVE.L  EOA,D0         ;END OF ARRAYS 
 008FDC: 9084          296          SUB.L   D4,D0          ;NEW ARRAY END 
 008FDE: B0B815E4      297          CMP.L   EOV,D0         ;MEMORY OVFL ? 
 008FE2: 640A          298          BCC     MEMOK          ;IF NOT 
                       299 ; 
 008FE4: 7E3A          300 ERR58    MOVEQ   #58,D7         ;UNDIMD > 3 
 008FE6: 6002          301          BRA     ERR46A 
                       302 ; 
 008FE8: 7E2E          303 ERR46    MOVEQ   #46,D7         ;MEMORY OVERFLOW 
 008FEA: 4EF86408      304 ERR46A   JMP     ERROR 
                       305 ; 
                       306 ; ALLOCATE MEMORY FOR THE ARRAY AND THEN INIT IT 
                       307 ; 
 008FEE: 21C015FC      308 MEMOK    MOVE.L  D0,EOA         ;STORE NEW END 
 008FF2: E68C          309          LSR.L   #3,D4          ;DIV BY 8 
 008FF4: 2F08          310          MOVE.L  A0,-(A7)       ;SAVE A0 
 008FF6: 2040          311          MOVE.L  D0,A0          ;PTR 
 008FF8: 2A3CA0A0A0A0  312          MOVE.L  #$A0A0A0A0,D5  ;4 SPACES 
 008FFE: 20C5          313 INITMEM  MOVE.L  D5,(A0)+       ;4 BYTES 
 009000: 20C5          314          MOVE.L  D5,(A0)+       ;4 MORE BYTES 
 009002: 5384          315          SUBQ.L  #1,D4          ;DECR COUNTER 
 009004: 66F8          316          BNE     INITMEM        ;LOOP 'TIL DONE 
                       317 ;

Page 27

                       319 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 
                       320 ; 
 009006: 2057          321          MOVE.L  (A7),A0        ;RESTORE A0 
 009008: 5588          322          SUBQ.L  #2,A0          ;CORRECT THE PTR 
 00900A: 3803          323          MOVE.W  D3,D4          ;SET D4 = # DIMS 
 00900C: 720A          324          MOVEQ   #10,D1         ; # TEN 
                       325 ; 
                       326 ; STORE THE DEFAULT DIMENSION(S)  (10) 
                       327 ; 
 00900E: 30C1          328 STORDIMS MOVE.W  D1,(A0)+       ;DEFAULT DIM 
 009010: 5344          329          SUBQ.W  #1,D4          ;DECR #DIMS 
 009012: 66FA          330          BNE     STORDIMS       ;LOOP 'TIL ZERO 
                       331 ; 
                       332 ; STORE THE DEFAULT ELEMENT LENGTH (16 CHARS), 
                       333 ; THEN STORE THE ADDRESS OF THE ARRAY. 
                       334 ; 
 009014: 30FC0010      335          MOVE.W  #16,(A0)+      ;ELEMENT LENGTH 
 009018: 2080          336          MOVE.L  D0,(A0)        ;ADR OF ARRAY 
 00901A: 205F          337          MOVE.L  (A7)+,A0       ;RESTORE A0 AGAIN 
                       338 ; 
                       339 ; D1 = SIZE OF THE FIRST DIMENSION 
                       340 ; D3 = THE NUMBER OF DIM'S (NOT INCL ELEMNT LEN) 
                       341 ; D7 = INDEX TYPE FLAGS 
                       342 ; A0 = PTR TO NEXT DIM (OR ELEMENT LENGTH) 
                       343 ; 
 00901C: 7800          344 LDSTRA4  MOVEQ   #0,D4          ;CLR D4 
 00901E: 2F0D          345          MOVE.L  A5,-(A7)       ;SAVE A5 
                       346 ; 
                       347 ; REPEAT THIS LOOP FOR 2ND, 3RD DIM'SN, ETC BUT 
                       348 ; EXIT LOOP BEFORE SERVICING THE ELEMENT LENGTH. 
                       349 ; 
 009020: DE47          350 LDSTRA5  ADD.W   D7,D7          ;TYPE FLG TO CY 
 009022: 640A          351          BCC     LDSTRA6        ;IF CONSTANT 
                       352 ; 
 009024: 3A5E          353          MOVE.W  (A6)+,A5       ;INT VARN OFFSET 
 009026: DBF815D8      354          ADDA.L  SOI,A5         ;ADD BASE ADR 
 00902A: 3415          355          MOVE.W  (A5),D2        ;INDEX TO D2 
 00902C: 6002          356          BRA     LDSTRA7        ;CONTINUE 
                       357 ; 
 00902E: 341E          358 LDSTRA6  MOVE.W  (A6)+,D2       ;INDEX TO D2 
                       359 ; 
 009030: B242          360 LDSTRA7  CMP.W   D2,D1          ;LIMIT O.K. ? 
 009032: 6328          361          BLS     ERR45          ;IF NOT O.K. 
                       362 ; 
 009034: D842          363          ADD.W   D2,D4          ;ADD INDEX TO D4 
 009036: 5343          364          SUBQ.W  #1,D3          ;DECR # DIMS 
 009038: 6706          365          BEQ     LDSTRA8        ;IF ZERO 
                       366 ; 
                       367 ; FETCH THE NEXT DIMENSION TO D1 AND THEN 
                       368 ; MULTIPLY THE NEW DIM * D4, SUM OF ELEMENTS, 
                       369 ; AND THEN LOOP TO FETCH THE NEXT INDEX ETC. 
                       370 ; 
 00903A: 3218          371          MOVE.W  (A0)+,D1       ;NEXT DIM TO D1 
 00903C: C8C1          372          MULU    D1,D4          ;DIM * # ELEMENTS 
 00903E: 60E0          373          BRA     LDSTRA5        ;NEXT INDEX 
                       374 ;

Page 28

                       376 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 
                       377 ; 
                       378 ; THE NUMBER OF ARRAY ELEMENTS IS IN D4. 
                       379 ; NOW MULTIPLY BY THE ELEMENT LENGTH 
                       380 ; 
 009040: 3218          381 LDSTRA8  MOVE.W  (A0)+,D1       ;ELEMENT LEN TO D1 
 009042: 2A04          382          MOVE.L  D4,D5          ;SAVE UPPER WORD 
 009044: C8C1          383          MULU    D1,D4          ;LEN * # ELEMENTS 
 009046: 4845          384          SWAP    D5             ;UPPER TO LOWER 
 009048: 4A45          385          TST.W   D5             ;ZERO ? 
 00904A: 6706          386          BEQ     LDSTRA9        ;IF ZERO 
                       387 ; 
                       388 ; THE NUMBER OF ELEMENTS IS > 64K SO INCLUDE THE 
                       389 ; UPPER WORD IN THE PRODUCT.  (THE NEEDED TEST FOR 
                       390 ; MEMORY OVERFLOW WAS PERFORMED WHEN THE ARRAY 
                       391 ; WAS DIMENSIONED.) 
                       392 ; 
 00904C: CAC1          393          MULU    D1,D5          ;UPPER PRODUCT 
 00904E: 4845          394          SWAP    D5 
 009050: D885          395          ADD.L   D5,D4          ;ADD ADR EXTENSION 
                       396 ; 
 009052: D890          397 LDSTRA9  ADD.L   (A0),D4        ;ADD ARY BASE ADR 
 009054: 2044          398          MOVE.L  D4,A0          ;ARRAY ELEMENT ADR 
 009056: 3001          399          MOVE.W  D1,D0          ;ELEMENT LENGTH 
 009058: 2A5F          400          MOVE.L  (A7)+,A5       ;RESTORE A5 
 00905A: 4E75          401          RTS                    ;LOADSTRA DONE 
                       402 ; 
 00905C: 7E2D          403 ERR45    MOVEQ   #45,D7         ;ARRAY BOUNDS ERR 
 00905E: 4EF86408      404          JMP     ERROR 
                       405 ; 

 

 
 RUNLOADER 
 10 A$(2,9)="ABCDEFGHIJKLMNOP" 
 20 B%=2:C%=9 
 30 PRINT A$(B%,C%) 
 40 STR(A$(B%,9),3,3)="123" 
 50 PRINT A$(2,C%) 
 60 
 LIST 

 10 LET A$(2,9)="ABCDEFGHIJKLMNOP" 
 20 LET B%=2:LET C%=9 
 30 PRINT A$(B%,C%) 
 40 LET STR(A$(B%,9),3,3)="123" 
 50 PRINT A$(2,C%) 

 RUN 

 ABCDEFGHIJKLMNOP 
 AB123FGHIJKLMNOP 

 END PROG