Issue # 27 DTACK GROUNDED Newsletter - January 1984

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

Our faithful Wang 2200 has died, just one week short of its twelvth birthday. It came suddenly - we came in to work one morning and it was lying on its back, feet stuck straight up into the air and stone cold. Just the preceding day it had been healthy and vigorous. We suppose that we should not be so sad, (almost) 12 years is a very old age for a computer. The Apple II, for instance, is not yet eight. In fact, the only operational computers older than our Wang that we can think of are the IBM 360s being used around the U.S. for air traffic control. Yes, they ARE failing more frequently lately. Have a nice flight on your next trip.

We have ordered a used Wang 2200, this one a model 2200T (about contemporary with an early Apple II) so that we can continue to use our Wang software.

DTACK REPORT:

Having brought all active hardware designs to an apparently successful conclusion - the VDHR graphics board is now in pilot production, as is the 16081 math board - we are now concentrating on software. HALGOL having become operational, if barely, we are documenting it and reorganizing it into two modules - the edit and run-time varieties - so that we can do run-time extensions while our resident computer science type can work on parsing the input, etc. You will find some stuff inside about local variables, parameter passing, proper string functions, and a DOS 3.3-compatible HALGOL DOS proposal.

DSEx Report:

"The latest and possibly penultimate Sensenig BASIC (Chet is about through tuning it) is now in distribution. It has a revised 50 page manual and runs on either the static or dynamic RAM boards. The system is somewhat more convenient to use and more crash-resistant and recoverable. I recommend it highly to all current BASIC users, and hope they all send their disks back for updating.

Page 1, Column 2

"Thomas Wieland has been named European Theatre Coordinator of the Exchange. We now cast our shadow over the entire Free World. His address is:

Thomas Wieland
Saebenerstr. 126
8000 Munich 90
West Germany

"I now have (but haven't really tried out) Walker's FORTH compiler and Inter68. Inter68 might be a real tiger; the pseudodisk feature makes a big Grande board and Inter68 a nice alternative to a Sage or other P-system board. Fortran is now supported for Inter68 (I'm sure you know this). DSEx intends to fully distribute programs running under PASCAL, FORTH, HALGOL and Sensenig BASIC, as well as assembler source." Jeff H, Corpus Christi TX

Jeff, we feel a little bit like the stand-up comedian in the late 60s who, on advice of his accountant, incorporated himself. Immediately after doing so the board of directors (his wife and parents) held an emergency meeting and voted him O-U-T out. Your letter is footnoted "THE PREMIER 68000 SOFTWARE EXCHANGE", you have European and Pacific Theatre Coordinators and, if we recall our last phone conversation correctly, you hold the title of "Grand Panjandrum".

We, like Mary Shelley's good Dr. Frankenstein, are beginning to suspect that the monster we have created is going to destroy us. We currently hold the (roughly equivalent) titles "newsletter editor" and "hey, dummy!". If we sit up and bark like a good dog, would you throw us a small bone (title)?

Woof?

CHARITY BEGINS AT HOME:

We would like to thank the large number (four in a two-week period, we kid you not) of foreigners who have requested circuit board artwork, schematics, timing diagrams and manufacturing rights for the Grande, because that confirms OUR belief that the Grande is a pretty good board. But ain't none of you gonna get them because the benefit/exposure ratio does not make sense to Digital Acoustics. A much smaller number want to build the static RAM board, something we can reasonably consider (the design is over two years old).

BORING STUFF:

32-bit micros, page 7. A Chuck Peddle retrospective, page 9. Math chip economics, pages 2, 10-11 and 25-26. 68000 PASCAL review, page 21. HALGOL stuff, pages 17 and 20. Advanced 6502, page 26. REDLANDS, page 29.

Page 2, Column 1

PUT ME ON YOUR MAILING LIST

is a phrase we have been hearing frequently in the past couple of weeks. First John Dvorak gives us a lot of space in his column over a gossipy item, and then Stan Baker of Electronic Engineering Times gives us a lot more ink over the 68000/16081 combo and some newchums start pouring out of cracks. Hearing that we publish a newsletter, the immediate, knee-jerk response is, "put me on your mailing list." Imagine their surprise when we tell them they have to send money. Imagine how fast they climb back into their cracks.

There are now about 450 folks who are willing to PAY for this rag, and about 4,500 (would-be) freeloaders who would like to be on the mailing list. If some public-spirited soul out there would, as a charity, make up the $6,800 monthly expense differential we might listen to the moochers. Each of the would-be moochers think he/she is a special case, naturally.

Counting a magazine published across the big creek, we have gotten ink in three major publications in the past three weeks. Only ONE of these spelled our name correctly. Listen, dammit: It's E - L - O - I.

A PERSONAL CRAY 1?

The CDC 205 runs, as a scalar machine, about 8 MFLOPs (million floating point operations per second, 64-bit format). Our Dtack board(s), with the 16081, run about 1/12 to 1/15 double precision MFLOPs. The CDC 205 rents for $1000/hr, or about $125 per MFLOP-hr. That makes the DTACK machine(s) worth, performance-wise, about $8 to $10 per hour. If one already has an Apple II, a half-megabyte Grande and a math processor could pay for themselves in less than 200 hours, or three weekends!

LISA is about 125 times slower than our 68000/16081 system, so LISA is worth, performance-wise, 7.5 cents an hour. At $8,190 LISA will pay for itself in wily (!) 109,200 hours. That's nearly 13 years of 24 hour/day, 365 day/yr operation.

Think about it. 8+ days payback vs. 12+ years!

If you are buying a machine for performance, would you want one that would pay for itself - by CDC 205 standards - in 8 days or in 12 years? Is that a question or a sardonic commentary?

NO INTEREST?

(At prevailing interest rates, LISA would NEVER repay its investment on an amortized basis while the DTACK payback is so swift that interest rates don't matter - but who's paying attention?)

Page 2, Column 2

What's that? You work a 40 hour week and you think your computer should too? O.K., the DTACK payback time is five weeks, and the LISA payback time is fifty-two and a half years (in tomorrow's interest-free world). What we are really trying to say is, if you like to bang bits, you are a LOT better off with a DTACK board than with a LISA. All 68000 machines are definitely NOT created equal.

(Let us take this opportunity to salute HLL fans, who will stick by operating systems and even BASIC interpreters written in PASCAL, no matter what er, slight disadvantages might be entailed. The theory is so perfect that HLL just HAS to be right.., right?)

DECADENT DEC:

As all of you have doubtless noticed, DEC is suddenly in big trouble. The only puzzle to us is why suddenly. DEC took itself out of the 36-bit (yes, thirty-six) computer business, abandoning its profitable DEC-10 product area. It has failed spectacularly in its attempts to penetrate the personal computer business, for the utterly predictable reasons one might expect that a minicomputer manufacturer would fail. It is being sat on at the high end of the VAX line by IBM and its new 4361 scientific small mainframe. It is being attacked at the bottom end by, you guessed it, IBM again with the PC and the XT and the XT/370. Even Data General has a higher performance 32-bit minicomputer.

Think about this: DEC's highest performing VAX can outrun a DTACK 68000/16081 combination ONLY if that VAX has the optional floating point stunt box, which costs $20,000 all by itself. And then the performance edge is 4-1 or less. 4-1 over what? Why, over an attached processor on an Apple II personal computer'

Want to buy some DEC stock?

OUR ARRAY PROCESSOR:

Several of you have asked whether we have forgotten or abandoned the array processor. The answer is DEFINITELY NOT! The array processor is to be a showcase for DTACK GROUNDED and the 68000/16081 combination. Before we design the hardware, we need to know a little more about software, timing factors and such. That way the boards will more likely be properly designed and have software support.

The UQD-1 can, in a sense, be considered an early prototype of the array board.

All right, we know you're braced for an exposition of how cost effective the array processor will be and how it will compare to DEC's top-of-the-line VAX. WRONG. We will let YOU make those comparisons.

Page 3, Column 1

IEEE FP STD MEET:

The Mini-Micro conference was held in San Francisco concurrently with Wescon. On Thursday afternoon, Nov 10, a meeting was held to discuss developments related to the IEEE draft standard on floating point. The sketchy report we received indicated that there was a heckuva rainstorm in progress and that not many folks showed up. The meeting went sort of like this:

The National guy stood up and talked about the 16081. Then the Motorola guy stood up and talked about the 68881. Then somebody else stood up and announced that the 16081 could be used as a peripheral by the 68000. Nobody showed any interest. End of meeting.

LACK OF INTEREST:

That report did not surprise us. because we received only three or four phone calls that week as a result of Stan Baker's column headlined "DIGITAL ACOUSTICS' MATH PROCESSOR" (it will come as a surprise to Nat Semi that the 16081 is OURS). It appears to us that one is either greatly interested or not interested at all in floating point processors. Perhaps we should drop the subject lest we bore the majority of our readers.

(Expressing a viewpoint which lots of readers vigorously oppose is one thing. Boring readers is quite another, and undesirable.)

ZAPPING ZILOG:

Zilog's systems group has just developed a two-board floating point accelerator for their system 8000 minicomputer. They will be very pleased to charge you the price of a Japanese pickup truck for that board set, but only if you buy their Z8000-based minicomputer first (we wonder if it costs $29,000?). All of you are by now doubtless aware of our unbounded admiration for systems groups.

So we located the name of Zilog's representative on the IEEE floating point committee and called him through the company's main switchboard.

Hi, we said. Our name is Felgercarb Eloi. Did you know that National's 16081 can be used by the Z8000 as a peripheral? You didn't? Would you like to have a schematic and a four-page description of exactly how each pin of the 16081 functions? You would? Fine, we'll send them to you, along with a five-page source listing showing how to program it without a new assembler. Oh, you're welcome. And then we hung up the phone.

We are awaiting our XMAS card from Zilog's systems group.

Page 3, Column 2

Then we remembered Gene Price. Gene is a local Fairchild sales representative who has given us some technical help over the past few years. He was in charge of pushing the 'F' TTL series when it (they?) was first introduced. These days he is the local 9445 guru, and we figured we owed him a favor. So we called him up and explained that the 9445 could have floating point hardware support NOW, if it really needed it. Would he like to have some schematics and some other stuff? Does bread fall butter side down?

We do not have to pick up the phone and tell Intel that the 16081 can be used as a peripheral to an 8086/8087 system because two Intel types have exchanged negotiable tokens of their esteem for subscriptions to this rag. Why would anybody tie a 16081 to a system that already has an 8087? Because dyadic functions such as A = B * C, where A, B and C are located in memory will execute about 2.3 to 2.5 times faster than with the 8087. Matrix inversion will show similar improvements in execution time.

Why would an 8086 that has a 16081 also use an 8087? Because many transcendentals can be calculated more swiftly than with the 16081. Why is the speedup only 2.3 to 2.5 when we have reported a 3-1 improvement? Because we have a 12.5MHz 68000 and they have a 5MHz 8086. Do we expect to see an 8086/8087 system which also has a 16081 peripheral? Yes, shortly after hell freezes over.

THE PERFECT WELFARE STATE

has now been achieved. You don't understand? Is it not evident that ALL 16-bit microprocessors are now fully supported? (By floating point hardware, that is.) When EVERYONE is fully supported, is that not the perfect welfare state?

There are always a few conservatives who don't WANT to be supported, at least not by somebody else.

ABOUT MOTOROLA:

Motorola is the company which, over a two-year span when it had a VASTLY superior product compared to its main competitor Intel, did such a good job telling people that it was impossible to construct a simple computer using its product that almost NONE of the billions of dollars' worth of simple computers now being sold annually use that superior product.

Motorola has an imperious attitude; they like to tell their customers what the customer needs. If Motorola doesn't MAKE it, why then the customer must not NEED it! Motorola is the staunch conservative who would be MORTIFIED to be discovered being supported by somebody else's math processor!

Page 4, Column 1

OPPOSED POLICIES:

During DTACK GROUNDED's first year we were VERY unpopular in Motorola circles because Motorola did not want simple 68000 systems to exist! Then our attitudes aligned because of a reversal of policy at Motorola. This lasted for about 15 months. Now we are likely to become unpopular again because we are espousing the use of the 16081 with the 68000 - and Motorola ain't gonna.

(Not all Motorola employees have attitudes which coincide with official company policy. But employees of large companies MUST follow the policies of those companies. How can it be otherwise? Do not blame the line troops because idiot top management is so easily swayed by the Svengali systems boys after the third martini at lunch.)

In the summer of 1981 Digital Acoustics had no credibility, no contacts in the industry and little experience at guerilla warfare. Things have changed. We are still a very, very small company and Motorola is still a very, very large company - the LARGEST in semiconductor manufacturing - but we have learned a few tricks. The next six months should be lots of fun!

We wonder how many design losses Motorola is going to take because it does not have math chip support while Intel, National, Zilog and Fairchild DO before it does an about-face - again - and we can be friends with Motorola's front line troops again?

WALL CLOCK TIME:

We discovered that one of the members of the IEEE floating point group is a stone's-throw neighbor here in Santa Ana. We called him (Why always HIM? Girls are naturally good at multiplication, no?) and explained what we were up to, and invited him to drop by. He did and we had, at least on our end, a very enjoyable talk. Turns out this guy is one of the few mainframe type persons on the committee, working for Burroughs, the # 2 U.S. mainframe vendor.

When the conversation turned to benchmarks - as it did frequently - we were struck by his emphasis on "wall clock time". Bob F. contributed some benchmarks run on IBM mainframes in the last issue and John M. has contributed some VAX 11/780 benchmarks in THIS issue. Each reported times measured in "CPU time". Here is what we learned about "CPU time":

"CPU time" is the actual CPU time required to perform the benchmark, less time spent on OTHER (time-sharing) users, and LESS operating system overhead. If a user is one of eight (an average number) of users on a VAX 11/780 with an FPA 780 Floating Point Accelerator, one can get a particular job done in only 1/4 the CPU time

Page 4, Column 2

as an Apple owner with a DTACK/16081 combination BUT THE DTACK OWNER WILL FINISH MORE THAN TWICE AS SOON!

The Apple/DTACK/16081 system runs on "wall clock time" and the VAX time-sharing system does NOT. We will concede that your VAX is faster if you can kill off the other users.

Time-shared CPUs need an accounting method of allocating costs among users, which is what "CPU time" is all about. You and we draw our paychecks based on "wall clock time". You may well finish a given job sooner with our stuff than with your wonderful top-end VAX. (And maybe NOT, depending on the application.) But doesn't it give one pause to hear that a $5000 machine may, under some circumstances, be superior in computational ability to a machine whose price STARTS at $235,000?

You will remember "wall clock time".

SHAME ON YOU!

Well, on some of you. Persons who clearly oughta know better have written some pretty wild letters to us defending high-level languages. At least two of them defended writing programs for an oil refinery in HLL! That's like defending motherhood and apple pie.

We thought we had made it clear that we were talking about operating systems, programming languages themselves, and mass-market application programs (word processors, spreadsheets). No one in their right mind would write an oil-refinery application program in assembly, not even your FNE. We certainly would not be spending a lot of time, money and effort developing HALGOL if we did not believe that there are LOTS of times when one should NOT use assembly.

The plain fact is, computers which have operating systems written in HLL cannot hack it in the real world competitive marketplace. Apple Computer can't figure our why buyers will not salute their deathly slow LISA, and is barely covering expenses by selling lots of IIes, which have an operating system and a BASIC written in assembly. Fortune Systems is in the same boat but does not have an alternate computer programmed in assembly, so Fortune is NOT covering expenses - to put it mildly.

Look, if it is such a hot idea to program BASIC in PASCAL, then it must be an equally good idea to program that PASCAL in C, no? And then we can program that C in Ada to meet mil specs. A BASIC written in PASCAL written in C written in Ada is guaranteed to bring a CRAY 1 to its knees. As a BASIC written in PASCAL already has brought LISA and FORTUNE's 32:16 to their knees (both are slower than Applesoft on a 1MHz 6502).

Page 5, Column 1

A HARDWARE ANALOG:

As usual, there is a direct analog in the hardware world. In Nov. '83 IEEE spectrum magazine, on page 101, we find:

"There are a number of difficulties with current automated layout tools. Chips designed by them tend to be larger and slower than handcrafted designs. Slow circuits may be particularly unacceptable in next- generation computer designs, where high-performance parallel systems are a stated goal. Furthermore, inefficient use of silicon reduces the advantages of VLSI either by leading to chips too large to manufacture economically or by requiring more chips to perform a given function. Automated layout tools produce lower-quality designs than humans because they typically have only a single strategy for placing transistors or larger blocks and for interconnecting cells, whereas humans can call on a variety of strategies, depending on the characteristics of a particular problem."

Look, the very THOUGHT of writing an HLL in an HLL is ridiculous. We even used the concept as a "poke fun" item way back in issue #4, when we did not believe anybody was stupid enough to actually DO it! See page 7, where we wrote: "...our FORTH is written in BASIC, a truly innovative approach made possible by our brilliant programming staff."

That would NOT be innovative today because other "brilliant programming staffs" are actually DOING what we used as a 'reducto ad absurdum' aver two years ago.

A BOLD (?) PREDICTION:

Apple Computer is 'betting the farm' on Mackintosh, which is due to be unveiled at their Jan 24 annual stockholder's meeting. We predict that Mack will be wildly successful if it has an operating system and a BASIC written in assembly. If it has an operating system and a BASIC written in HLL we predict that it will be a mass-market failure.

It is understood that a computer which is a mass-market failure can sell in the thousands, as Fortune's 32:16, LISA and the Sage II have. But mass-market successes sell in the HUNDREDS of thousands (if not millions).

LOW-GRADE vs. HIGH-GRADE:

Sure, we know there are more programmers who can program HLLs than who are GOOD assembly programmers. There are also more chicken pluckers than good polymer chemists. Does DuPont employ chicken pluckers on its research staff? There are more low-grade than high-grade types in ANY walk of life.

Page 5, Column 2

You let the HLL types write the one-shot oil refinery programs and hire GOOD assembly language types to write the operating system for your intended mass-market personal computer.

What's that? You say there aren't enough assembly language programmers to go around? My dear sir: all you need is enough to program the operating system and BASIC for YOUR computer, and there are more than enough for that. What's that? You have positions open and you are not getting enough applicants? Then you are not offering enough pay! Try offering, say, $250,000 per year and see what happens. If you plan to sell a SUCCESSFUL $2,500 mass-market machine then you are certainly aiming for no less than one million sales. That's $2.5 billion. Since software is rumored to be important to the success of a computer, let's budget 5% towards assuring good software. That's $125 million.

FAREWELL, MASS-MKT UNIX:

In Nov '83 Mini-Micro Systems there is a COMDEX conference preview (p.229). Two of the speakers during the session on operating systems will be Jean Yates, who is a UNIX person, and Rodney Zaks, president of Sybex Computer Books. Mini-Micro reports:

"Yates does not see UNIX becoming the de facto standard for 16-bit systems. 'Obviously, IBM's MS-DOS/PC-DOS products are the de facto 16-bit standard,' she asserts. 'MS-DOS/PC-DOS is very much the OS of the single-user workstation.'

Zaks will present a paper on "Defacto Standards in the Micro Jungle." According to Mini-Micro, "The Tuesday session will delve into the 'demise of CP/M, the rise of IBM-enforced standards for operating systems, the significant demise of PASCAL and the unlikely emergence of UNIX,' according to Zaks. 'It is very likely that we will see CP/M taper off and possibly slow drastically,' Zaks asserts. 'It is unlikely that any significant new computer, will be introduced that will have CP/M compatibility.'

"Zaks sees PC-DOS or 'possibly a proprietary OS that IBM might be introducing later on' as taking over CP/M's role. 'PASCAL at this point remains a developmental tool for engineers and an educational tool for universities. The growth phase of Pascal is also now terminated.'

"Zaks is also not optimistic about the prospects for UNIX. 'UNIX so far has not made it,' he contends. 'And the hardware that would truly support the OS's capabilities is not truly available at this point. The large-scale use of UNIX as an operating system is very unlikely in the short term. UNIX remains very much wishful thinking in its admirers' eyes.'"

Page 6, Column 1

PREDICTING THE PAST:

If you will review those quotes from Yates and Zaks you will not find a single prediction. Each is reporting what happened in 1983. 1983 is the year that UNIX was placed before the public and was SPURNED by the public. Have you bought a Fortune 32:16 yet? Have you bought a Tandy 16/XENIX system? Do you know anyone who HAS? Are there any magazines supporting such systems? Can you name even ONE successful mass-market computer which does not have one or more magazines supporting it?

CP/M has failed so utterly in the 8088 market that Digital Research has had to make its line of languages available on MS-DOS. That's about as obvious a white flag as you will ever see.

Zaks continues to make the mistake that caused the UNIX bandwagon to start rolling in mid-1982: he thinks hardware is the secret to the success of UNIX. That's bullshit! Hardware is in fact IRRELEVANT to the success or failure of UNIX. The reason UNIX will NOT EVER succeed in the mass marketplace is that 1,000 page manual. The mass marketplace features casual computer users, not dedicated full-time professionals. Those casual users are spending their own money for a computer that they are going to use themselves. If they cannot sit down in front of a computer in a retail showroom and start using that computer within five or ten minutes, they aren't going to buy.

And THAT is why UNIX REVIEW ignores the dummy who gets his hands dirty on the keyboard. UNIX systems will continue to be purchased by data processing managers for involuntary use by peons. That's a mass marketplace?

A POP QUIZ:

The IBM PC, Apple II, CBM64/VIC20 and Trash-80 I/III/IV are examples of machines whose operating system and BASIC are written in assembly. What is the total number of national magazines supporting those four systems?

# of ASM-related mags: ____

The Fortune 32:16, SAGE II, LISA and the Tandy 16/XENIX are examples of machines whose operating system and BASIC are written in HLLs. What is the total number of national magazines supporting those four systems?

# of HLL-related mags: ____

If the arguments which WE have presented have not persuaded you, perhaps you should examine closely the figures which YOU have just written down? They are YOUR figures. What do they mean?

Page 6, Column 2

80186/8 PARTS SHORTAGE?

Electronics magazine (17 Nov '83 p.41) reports that Intel will only be able to meet 20 to 30% of the demand for the 8018X processor in the first half of 1984. (These parts were originally scheduled to be in quantity production in Dec '82 (yes, '82!)). Since we have been accused of being cynical by some readers lately, we decided to get others' interpretations of that announcement.

Does that mean that IBM, which owns 14% of Intel, will only get 20 to 30% as many of those parts as it needs for the production version of Peanut and PCjr or does it mean that Intel won't be able to meet the needs of others after IBM gets all it wants? So we bounced that off the editor of a national magazine and off some well-placed folks at a couple of Intel's competitors. You know what? We ain't the only cynic.

FNE = CHICKEN (squawk!)

Back in July, in issue #21, we stuck our neck out on a prediction which we still stand by, but which we thought most of you readers would consider outrageous. We had originally written that there would be 500 companies in the U.S. and 1000 internationally producing 8018X-based personal computers. When preparing that issue for the printers, we decided those numbers were too large to be printed and still retain any credibility with our readers. (That's YOU, plural.) So we cut way back, on page 3, col 2, par 3.

Now we wish we had left those numbers alone. We have had NOT ONE reader write to tell us that we are all wet over those predictions, which proves that either you are not paying attention or that we are in some agreement. Another reason we wish we had left those numbers alone can be found on page 195 of DATAMATION, Nov '83:

"Currently there are between 600 and 700 companies buying the two 16-bit cpus, the 8086 and the 8088. 'We are shipping several hundred thousand 8088s per month.' claims Andy Verhalen, product manager at Intel. Half of the designs, but most of the production volume, is for personal computers, he says.

"The next generation of 16-bit microchips, the 25% faster 186 and 188, are being designed into new products at the rate of more than one a day, according to Tony Barre, Intel marketing manager. 'We already have 400 product designs locked up and we expect to have 1,000 by the end of the year.' he says."

We have not even received any flak over our prediction that the automated factories will win. Not even a contact inside Apple Computer disagreed, which we

Page 7, Column 1

thought was surprising considering most of their pc assemblies were being produced using cheap far east labor. NOW we understand! Mackintosh will be built in Fremont, CA on a fully automated assembly line

It would appear that the personal computer marketplace is shaping up exactly as we predicted in issue #21 - if we had only left those numbers alone. So why did we chicken out? Well, we thought we were going to get lots of ridicule from our readers, and not even newsletter editors really like to subject themselves to ridicule. Please excuse us now while we scratch up some breakfast. Squawk!

TODAY'S ENGLISH LESSON:

Flak is shrapnel from exploding cannon-shells, usually of the anti-aircraft variety. Gregory Peck ran into a lot of flak in the movie Twelve O'Clock High. A 'flack' is a press agent, one whose job is to get publicity for his/her client.

The reason we are explaining this is that the editorial staff of a certain national weekly personal computer industry publication (evidently) does not know the difference between flak and flack. We won't tell you which publication because it has treated us kindly.

THE LATE BELLMAC 32

is now known as the WE32000, on account of Western Electric is losing the Bell trademark as part of the AT&T breakup. The Bell labs boys are doubtless laughing themselves silly over Nat Semi's lovely purple advertisements, which simply state that the 32032 32-bit processor, which is now in limited sampling, is the FIRST 32-bit microprocessor. Even H.P. might be amused, if it bothered to notice. And have you heard about DEC's microVAX chip set? Or NCR's chip set? (Both of those last are 32-bit but do not qualify as microprocessors on account of more than one chip.)

We would really like to know more about that WE32K chip, but they are not selling it separately at this time. We understand it is primarily optimized for communications, secondarily for UNIX, and that effectiveness as a GENERAL PURPOSE computer was given third priority. We have certainly not heard even the slightest murmur about any attributes of swiftness.

THE NAT SEMI 32032

is surprisingly unswift itself. First, there is little difference between the 32032 and the 16032 aside from the bare fact of a 32-bit external data bus. Internally, the 16032 and the 32032 are the same. But because the 16032 is NOT, repeat NOT, data bus-bandwidth limited, the performance gain of the 32032

Page 7, Column 2

over the 16032 is only 35% - and those are Nat Semi's figures. The 32032 may be here today, but it is NOT the 32-bit processor of tomorrow.

(The BIG problem Nat Semi has is that the National parts - all of them - are being promoted as 10MHz parts but are REALLY 6MHz devices.)

The Intel 386 - that's THREE eight six - is off in the far distant future and will not be a high performance part because none of the warehouses holding all that 8080 code have burned down yet - and Intel has decided to retain compatibility with the 8080. (The Intel folks will vigorously deny this. They ALSO deny that the 8086/8 was specifically designed to be compatible with the 8080. So how come the IBM PC runs so much translated 8080 code?)

We must confess that we don't know much about the Zilog Z80000 (note the five zeros) aside from the fact that it is now a paper tiger. We believe that the mask layout, if actually begun, must have begun quite recently. One of the reasons we don't pay much attention to what Zilog does is that it seems pointless to invest a lot of effort learning about a forthcoming (?) Zilog product when one might read in the next morning paper's business section about EXXON "pulling the plug" on Zilog. Zilog has ALWAYS been an enormous cash drain on EXXON. Sure EXXON can afford it, but WHY? Zilog's future might rest on something as simple as the health of EXXON's current CEO.

Since HP ain't about to sell their 32-bit micro, you know who is left. Yep, Motorola and their 68020. It looks like that little baby will be about 3.5 times as fast as a 68000 for the same clock rate. How do we know? Remember that turgid, reader-unfriendly booklet Motorola put together comparing the 68000 and the 286? Well, it also has performance data sprinkled through it for the 68020. And it looks like that not-so-little baby is going to be a REAL 60-foot-tall gorilla.

Too bad nobody is going to be able to buy one across the counter for a long time yet.

FORTUNE SYSTEMS WATCH:

Fortune has just dropped $9.1 million in the third quarter on sales of $9 million. Now read that last sentence again, and think about it. What that means is that Fortune spent $18.1 million to sell $9 million. It will not surprise you that the same stories announcing this loss also tell about the three vice-presidents who have just, um, "left".

Assume the gross profit on Fortune's small computers runs 40%. So their expenses in selling that $9 million, exclusive of overhead, were about $5.4

Page 8, Column 1

million. That means that Fortune's overhead is $18.1 million less $5.4 million, or $12.7 million. So they would have to sell $31.75 million to break even, and sell $63.5 million to make a 20% pretax and 10% posttax profit. (These numbers are based on an assumption of 40% gross profit. Gross profit is what you have if your company has no overhead!

If that 40% is right, Fortune has to increase its sales by a factor of 3.5 to break even and by a factor of 7 to make a 10% posttax profit. Is it possible that not as many people as some might desire are saluting the cheap 68000/UNIX flag?

Do you realize, dear reader, how much flak your FNE has taken over the past 12+ months for asserting that cheap 68000/UNIX systems are NOT a good idea and would not be popular and hence not profitable? Well, if you still like such systems, SOME of Fortune's models still support UNIX and two of those three vice-presidency positions are still open.

VICTOR TECHNOLOGY WATCH:

Victor just reported $37 million in losses in the third quarter on sales of $46.1 million. That isn't the way to become the third largest computer company in the world, is it?

COMMODORE vs. Apple:

Commodore's third quarter profits are up 83% over the last year while Apple's pretax profits are DOWN 84% in the third quarter vs. the previous year. Commodore's sales more than doubled. With post-tax profits of $24.3 million on sales of $209.3 million, their profit margin is nearly 12% after taxes - and Commodore had a disk drive shortage to drive sales and profits down, remember?

To the best of our knowledge, IBM's revenues are NOT doubling yearly. We wonder why PC World's David Bunnel thinks Commodore is in trouble? We'd sure like to have troubles like Commodore's here at Digital Acoustics! Here are some third (calendar) quarter results. Profits are AFTER taxes, and you DO know what parentheses around the profit figure mean, right?

             Commodore  Apple  Victor  Fortune 

  '83 profit  $24.3M    $5.1M  ($37M)  ($9.1M) 
  '82 profit  $13.3M   $18.7M   ($1M)    -- 
  change       +83%     -73%   -3,600%

Note that Commodore is setting record sales and profits at a time when nearly everybody else is falling flat on their, er, face. Commodore's profits are better than Apple's LAST year when Apple was highly profitable.

Page 8, Column 2

With sales doubling yearly and with sales in the current quarter of over $200 million, we trust it is obvious to all of our readers that Commodore is poised to become a Fortune 500 company. While Scully is spending his time worrying about IBM, kindly Uncle Jack just might undercut Mack with a (relatively) cheap 256K keyboard computer using a Zilog 28000. Remember, the Z8000 is a pretty good microprocessor.

A Z8000 programmed in assembly is one hell of a lot faster than a 68000 programmed in PASCAL or C. And Uncle Jack has a habit of hanging attractive price tags on his keyboard computers. It is our observation that the public doesn't like to pay high prices to run slowly, as sales (?) of LISA and Fortune confirm. Mack, if programmed in PASCAL and C, might face the same problem.

REAL NEWS DEPT:

We missed this one the first time around, but DATAMATION, in its Aug '83 issue, asserts that Apple Computer has sold out its 1983 production run of LISA computers (p.13). Boy, is THAT going to be news in certain circles, including the office of one J. Scully. We wonder how DATAMATION comes up with these scoops?

APPLE PERSONNEL DEPT:

Ten months ago, in issue #17, we reported that "(Floyd Kvamme) has just joined Apple Computer as V.P. Sales, reporting directly to Apple Prexy (then) Mike Markulla (this no doubt makes John Couch deliriously happy)."

Well, gee, we guess John Couch must have been less than deliriously happy because he does not work for Apple Computer any more. According to the EN story which announced his departure, "Mr. Couch had been the guiding force behind development and introduction of Apple's Lisa office systems product."

In issue #24 we told you about Scully shunting aside the former co-general managers of Apple's Personal Computer Division. One of them, Paul Dali, did relocate temporarily as Director of Market Development but that did not last and he is now O - U - T! Well, one cannot move Scully men IN unless others move OUT, no?

NEW EXCUSES NEEDED:

Many of you will recall that Apple blamed premature introduction for the relative failure of the Apple III. They are now blaming premature introduction for the lack of LISA sales. Obviously Apple needs some new excuses. So, if you have any spare excuses laying around, please send them to the Apple Computer Co., attn: J Scully.

Page 9, Column 1

Apple's ads for LISA trumpet the hundreds of man-years that went into LISA's development. When Scully asserts that LISA was introduced PREMATURELY, isn't he saying that NOT ENOUGH development was done? This reminds us of Intel's wonderful iAPX 432, which was going to solve the programmer crisis but required 20 man-years as a minimum start-up programming effort.

AMBULANCE CHASING DEPT:

Digital Research (marketers of VisiON) and VisiCorp have each filed lawsuits against the American Opthalmologist Association. ComputerLand has some process servers scouring the land to find one Moses, who is said to be establishing a PromisedLand.

C. I. Peddle Retrospective:

It must be terribly embarassing to hold the title of President and Chief Executive Officer of a company while not having the authority to purchase a box of paper clips. Chuck Peddle, famed designer of the 6502 and the original PET was in that awkward position for a while, but no more. The Victor folks have mercifully removed those two titles and have named him vice chairman (of the board), a title which carries no authority and little responsibility.

The Wall Street Journal story about this change headlined Chuck's name as "C. I. Peddle". Boy, what a bringdown for a guy whose photograph and name (4 1/2 times, yet) appeared in a full page ad in BYTE for Victor Technologies. Not only that, but the WSJ story erroneously reported that Chuck designed the "68000" microprocessor while at Motorola. Well, it's easy to get the number of zeros wrong; we did so ourselves in THIS journal recently.

All of you probably know that Chuck designed the 6800 (NOT 68000) at Motorola, and the 6502 at MOS Technology. We have news for you: that is not in accordance with the facts. HERE ARE THE FACTS:

Chuck Peddle headed the CPU design team which designed the 6800 at Motorola. Motorola had DIFFERENT design teams working on the various peripheral chips such as the 6820, 6850 etc. After the 6800 design was completed and checked out, Motorola did NOT reassign Chuck and his team to one of the peripheral chips.

Now is the time to recall a couple of aphorisms: "the Devil makes work for idle hands," and our own "there are some things which should never be done for the first time," such as design a microprocessor. The 6800 was Chuck's - and his design group's - FIRST microprocessor. And Motorola did NOT reassign Chuck and his design group to other duties, as we just said. Chuck did the obvious: he and his design team came up

Page 9, Column 2

with a SECOND microprocessor design which was similar to the 6800 but corrected its most glaring deficiency: only one index register. Chuck and his design group also designed the microprocessor to be more producible. At this time the 8080 and 6800 both cost in the neighborhood of $360. Yes, three hundred sixty dollars. And Intel would not sell you an 8080 unless you purchased your DRAM from them as well.

So Chuck took his new CPU design to Motorola management and they had no interest whatever. "Chuck," they said, "we already have one microprocessor. We do not need two."

Consider how Chuck and the design group he led must have felt at this point. Motorola had failed to assign them useful work. They had designed a SECOND 8-bit microprocessor which, predictably, was in fact superior to their FIRST design. We suspect that Chuck and his design group felt rejected and unwanted. Certainly their new design seemed to be unwanted by Motorola. AND - (we emphasize this) - Motorola continued to fail to find meaningful work for Chuck's design group.

The predictable happened. Chuck (he was the leader of the group, no?) shopped around the semiconductor industry for a home for his group and for their new, superior, microprocessor design. He found willing takers at MOS Technology, a firm which at that time was specializing in calculator chips - sort of low-grade microprocessors, mostly (all?) 4 bits.

ETHICS. The semiconductor industry then (and now) featured easy nobility between employers. This has considerably benefited the industry and the industry's customers. But there is some ambivalence: it is O.K. for Bob Noyce to jump ship from Shockley to Fairchild and later from Fairchild to Intel, but if an employee of Bob's does the same thing then the employee is disloyal, traitorous and a possible lawsuit target.

But it is generally agreed that one should not take engineering drawings from ones' previous employer to the NEW employer. That is not just unethical but also illegal. Did Chuck carry engineering prints (what the aircraft industry calls "blueprints") of his new design to MOS Technology? We dunno.

What we DO know is that A) MOS Technology brought out the 6502 in a remarkably short time after Chuck and his team joined them, and B) Motorola brought suit against MOS Technology on the grounds that engineering drawings had been taken from Motorola, and won a court judgement of $300,000 from MOS Tech. (It appears that SOMEBODY carried those prints.)

We must recall that MOS Technology was a very small operation with limited financial resources (it is

Page 10, Column 1

difficult to recall how much this industry has grown since those days). That $300,000 hurt them, badly. They had to look around for what is called these days a "White Knight", or friendly corporate takeover. They found one: Commodore and kindly Uncle Jack.

The rest of the story is well known. Chuck talked Trameil into coming out with the original PET 2001. Lots has happened since then including the weekend when Chuck and Bill Geiler designed the VIC-20; the brief time when Chuck left Commodore to be a consultant for Apple and then promptly left Apple and rejoined Commodore, presumably ladened down with Apple's secrets. Apple's anger shortly turned to laughter as Chuck broke off from Commodore and established Sirius Systems (later Victor Technology) and set out to become the head of the third largest computer company in the world.

But you should not believe that the 6502 was designed at MOS Tech. It was in fact designed at Motorola. Honest.

An afternote:

The floppy disk drive for the Victor 9000 was one of Chuck's proudest engineering achievements. The speed of rotation varies depending on whether the head is on a inner track or an outer track or in between. The idea is to keep a constant linear velocity of the magnetic media past the head. The idea was so successful that Apple copied it a year later and claimed they had invented it. Apple made its own drive mechanisms though, which proved to be highly unreliable. (Apple solved that problem the same way they 'solved' the Apple III fiasco: they had an "afternoon of the long knives", with, as Apple usual, no survivors.) Tandon made Victor's drives and they are HIGHLY reliable to the best of our knowledge.

Naturally, the Victor drives will not read ANY other manufacturer's disks - including IBM's. Victor, as this is written, is not paying some past-due bills on account of no dinero (like $12 million owed Tandon, for instance). Kidde, who owns a portion of Victor, has promised a cash infusion IF Victor produces a board in X days which will permit the 9000 to read IBM PC-format floppies. It seems nobody wants highly reliable; what people want is IBM compatibility.

One of Chuck's proudest engineering achievements MAY prove to be the death of Victor. (Those whom the gods would destroy they first make proud.)

MINI-MICRO SYSTEMS WATCH:

The Oct '83 issue of Mini-Micro arrived between 4 and 10 Nov '83. The editors must be especially proud of

Page 10, Column 2

pages 81 thru 96 because our copy of the magazine has three sets of those pages. They may publish late but their news is up-to-date: at the end of page 100 we learn that "Despite Texas Instrument's second-quarter home computer operation pretax loss of $183 million, TI chairman Mark Shepherd states that TI will stay in the home computer business." Hmmm.

On page 311 they have a story about Zilog's floating point accelerator boards for their System 8000 microcomputer, which is based on the Zilog 8001 microprocessor. This article includes a table (p.312) listing the execution times of the new board set and also the times of some other devices, including the Nat Semi 16081. We are reproducing that table here, with the following changes: only double-precision (64-bit) execution times are listed, the subtract column has been dropped since it is (obviously) identical to addition, and the clock speed of the 16081 and the 80287 have been changed to conform to today's real world: 6MHz and 5MHz respectively.

                  Multiply   Divide    Add 

  DEC VAX 11/780    3.4       8.8      1.4 
  Zilog board set   3.22     16.36     3.64 
  Nat Semi 16081   10.33     19.67    12.33 
  DEC 11/34        25.36     35.36     8.91 
  Intel 80287      27.0      39.0     17.0 
  DEC 11/23       193.      239       43

The times listed are in microseconds. The three DEC units all had floating point accelerators: the FPA 780, FP11-A and KEF11 respectively. Mini-Micro listed the iAPX 286/20 (Intel code for the 80286/80287 combo.)

It must be emphasized that the times given do not include, as Mini-Micro says, "instructions such as load, store and jump." Mini-Micro continues with this paragraph, which concludes the article:

"A more appropriate benchmark can be designed by performing a real-life task such as the dot product of two 1,000 element vectors. To eliminate the effect of high-level program generators, the dot-product program should be written in assembly language. Using such a benchmark, a Zilog System 8000 model 31 with (their FP board set) selling for $37,400 can be compared with a DEC VAX 11/780 with floating point accelerator selling for $230,000. The Z8000 operates at 125 KFLOPS vs. the VAX's 250 KFLOPS. This means that the Z8000 operates at 1/2 the speed of the VAX for 1/6 the price."

Our guess is that the DTACK/16081 will run about 65-70 KFLOPS on that same benchmark, nearly independent of whether the Grande or the GROUNDED board is used since the 16081 is the time-critical link in the chain. That's one-fourth of a VAX 11/780 WITH the FPA-780!

Page 11, Column 1

Along with our comparison of the DTACK/16081 to the CDC 205 elsewhere in this issue, it is obvious that we have at hand a very cost-effective heavy-duty number-cruncher. This is going to be very important, soon (the 68000/16081 combo, that is).

PULLING THE PLUG:

Beginning about a year after the Trash-80, Apple and Pet became available, a whole bunch of people started unplugging from timesharing and joyfully embraced personal computing. This included folks who wanted to do simple stuff, including word processing (letter writing), simple engineering computations, and later (when VisiCalc arrived) spreadsheets. Nobody wants to pay connect charges and storage charges and line charges and CPU time charges if they can make a ONE-TIME payment and then run their computers "forever", almost for free. Nobody wants to be limited in the hours they can do computations.

Ever check out connect charges/minute at 10AM, Mon-Fri on time-sharing? Ever try to get a line?

All of you know who has unplugged from that time-sharing line: practically ALL of you! Many of you have forgotten the ones who are still tied to time-sharing - the heavy-duty number-crunching folks.

The number-crunching that can be done in one CPU-hr on a scalar CDC 205 CAN be done on an Apple II but it will take a year and a half of 24hr operation. That's not a realistic alternative to that hour on the Cyber.

The DTACK GROUNDED 68000 board, in software, can get that hour's worth of computation done in three weeks, 24 hours a day. Pray you don't get a power outage. Develop patience as a virtue.

The DTACK/16081 combination can perform that computation in four days! If you have a SIMPLE problem - one the CDC can solve in five minutes of CPU time - the DTACK/16081 can ALSO solve the problem, and in just over 5 hours. A 6502-based Apple II would require a month, which is not reasonable or workable.

What's unique about the DTACK/16081? Nothing, we're just here FIRST. Machines like this are going to provide for the number crunching folks the freedom from connect time and CPU charges that most other personal computer folks have had now for five or six years.

(Most heavy-duty number crunching involves linear algebra and/or matrix manipulations, which run half an order of magnitude faster on a DTACK/16081 system than on an IBM 8088/8087 system. That half an order of magnitude is IMPORTANT to the number-crunching folks, else 4 days becomes 12 days.

Page 11, Column 2

DESCENDANT OF PROCRUSTES:

We have at hand the umpteenth letter of anguish from a university prof regarding the incompatibility of our sales policy and his university's rules and regulations (including state law in the case of state universities). The problem, of course, is our refusal to accept purchase orders or to grant credit. Since many of you have not read one of our 'information packets' lately or reviewed issue #2, where we stated our (then) reason for our sales policy, let us explain here:

(If you have no interest in business matters, skip to the next headline.) When we began the 68000-board side of the Digital Acoustics business in the second half of 1981, it was strictly a sideline to the company's main business, which was unattended environmental acoustical noise analyzers. Up to that time, we had been the BUYER, not seller, of products of that general nature. The mickey-mouse multiple price structures, usually under the name 'OEM schedules' had irked us considerably.

Because of this, and because we THOUGHT that all the customers for those 68000 boards would be individuals with personal computers, we decided to take the admittedly unusual step of offering John Doe in Fargo ND as good a deal as ANYBODY could get. Since we would not offer John credit (i.e. accept a purchase order) then we could not accept a purchase order from anyone - if we kept our contract with John. We realized even then how unusual such a policy is/was, as you can see by reviewing issue #2. We worried, even then, over how long we could KEEP such a policy.

The 68000 board continued to be a minor sideline up until the summer of 1982, when two things happened roughly simultaneously: DTACK sales skyrocketed and the Reagan administration put the U.S. out of the environmental noise business. As of Oct 1 1982 the annual budget for the Office of Noise Control of the Environmental Protection Agency became zero dollars.

Suddenly, Digital Acoustics was in the attached processor business, not in the noise monitoring business. Our sales policy for attached processors became of more than casual interest. But we have maintained the old policy unchanged. Why? Because our existing policy WORKS, that's why!

You may not believe this, since businessmen are not noted for complete candor in these matters, but we have priced our products as low as we can while making a small profit (our targeted profit is 10% post-tax). We HAVE to make a profit, because we are growing. [More details on cash-flow later.]

Page 12, Column 1

It is common for someone, upon first hearing of us, to express skepticism as to whether we - and our products - are for real. After all, the prices are much too low! When we convince the person that we ARE for real, they often want to cut a deal which involves some volume over the next year with a 30 - 40% discount. And offer us a purchase order for such. Again, you may not believe this - but we cannot take pricing set for a 10% profit on a cash-on-delivery basis and then offer a 30 to 40% discount on a credit basis.

So we offer no discount and no credit to ANYONE. (We wish you could have heard that EXXON purchasing agent yell like a stuck pig when he discovered his company had no credit with us!) True, this policy does cause problems for some purchasers, notably state universities and U.S. government agencies such as the Department of Energy. But we have sold MANY boards to state universities, universities in general and one to the DOE We even have a major OEM customer who accounted for 40% of our 68000-related sales last year.

And so, the REAL reason we have stuck to our policy: IT WORKS And we can continue to look John in Fargo straight in the eye (figuratively speaking) and assure him that he gets as good a deal as anyone.

ABOUT CASH FLOW AND GROWTH: For you non-business types, we are going to give you the five minute course on cash flow and corporate growth. Let us suppose that parts are purchased and assembled, on average, 30 days before shipment. Let us assume that universities and big companies pay invoices an average of 60 days after shipment. We will assume that everyone DOES pay - so don't sell to Osborne or Washington State's WHOOPS power consortium. Businessmen would say that such a company 'rolls over its cash flow' every 90 days or 4 times a year.

Since our hypothetical company is profitable, it costs less than 90 day's sales to fill that pipeline - say the equivalent of 80 day's shipments or 2.6 months. If the company is shipping $100,000 a month, it has $260,000 sitting between some stage of inventory and the reception of the payment. It had also better have some operating money sitting in the bank. Having less than one month's revenues sitting in the bank account is SCARY for a small company. So we need, for this example, a total of $360,000 of what we will loosely call current assets.

Now, suppose that the size of the company doubles in the next year, to shipments of $200,000 a month. None of the other numbers have changed, so it needs to have double $360,000 or $720,000 of current assets to operate. Where did that extra $360,000 come from? Well, this company is profitable, no? At 10% post-tax profits it generates $120,000 a year at the old sales

Page 12, Column 2

rate and $240,000 a year at the NEW sales rate. Assume gradual growth over the past year and split the difference at $180,000.

But that $180,000 falls $180,000 short (!) of covering the additional $360,000 in current assets needed. Since the 30 day average inventory time has not changed and the 60 day payment time hasn't changed either, it is obvious that the difference must come out of the bank balance. Instead of the $200,000, or one month's shipments sitting in the bank we have only $20,000. That is just two working days' shipments. Employees' checks bounce. The bank is unhappy. Suppliers are worried.

FACT: a company which rolls its cash flow over every 90 days and which has an after-tax profit of 10% of sales cannot double its sales in one year without finding additional outside financing.

FACT: Digital Acoustics DOUBLED in size in our last complete fiscal year over the preceding fiscal year - and showed strong growth in its bank balance! How? We have an average inventory time of 20 days because RAM is such a large portion of our costs - and we buy RAM at (nearly) the last minute. And our average payment time is about 3 or 4 days! (Most folks pay the full amount in advance and the others pay C.O.D., which averages 15 days turn-around.)

As a result, we have about one month's shipments tied up between inventory and payment. If we are currently shipping $50,000 a month, to take a round number, we have $45,000 tied up between inventory and payment (don't forget that 10% profit margin). And we need another $50,000 for a comfortable bank balance. That's $95,000 in our loosely defined 'current assets'.

If we double our sales in the next year - and we expect to do exactly that - we will need to double those 'current assets'. We need to find another $95,000. Profits at the current level are $60,000/yr, and $120,000/yr at next year's shipping levels. Once again, we split the difference and find we have covered all but $5,000 of the extra needed 'current assets'. But we figured this on a 30 day cash turnover, and our cash turnover is closer to 23-24 days.

Result: Digital Acoustics CAN double its size on internally generated (10%) profits in one year - but only using the payment terms which were in fact devised for another purpose entirely Hypothetical question: how could Digital Acoustics triple its size in a single year without additional financing? Answer: with a 15%-20% post-tax profit margin. YOU work the numbers.

(If you had a spreadsheet, it would work the numbers for you. What did you think VisiClones were FOR?)

Page 13, Column 1

AN EXERCISE FOR THE STUDENT: The Osborne Computer Co. went from zero to $70 million in annual sales in less than two years. You work out their cash flow, assuming an initial investment of roughly $10 million. (This is YOUR exercise. You can make any assumption you want.) Question: Given the world's greatest management, how does Osborne stay solvent without additional outside financing, such as the public stock issue which never came through?

PROCRUSTES: We mentioned a few issues back in the letters column that we were descended from Procrustes, which is where we got our business policies. Procrustes was a (hopefully) mythical highwayman who at times forced travelers to EXACTLY fit his bed. If the traveler was too tall, feet and legs were trimmed to fit. If too short, the traveler was stretched on a rack, again until a fit was achieved. Thus our business policies are procrustean, which the handiest dictionary defines as "...arbitrary, often ruthless disregard of individual differences or special circumstances."

That's about as good a description of our sales policy as you're gonna find.

MORE MINI-MICRO STUFF:

In Nov '83, p.137: "At the ancient age of 10, UNIX is seen by some as too slow and awkward for efficient microcomputer processing." REALLY? Gee, we wonder who "some" is/are?

O.K., so that is a nice general statement with no specifics to back it up. If you want specifics, turn to the article on page 255 which tells you in detail why UNIX's disk operating system is busted, and how one company is PARTIALLY fixing the problem:

"The minicomputer systems of the early 1970s had relatively little disk storage. This led to the development of UNIX's complex and awkward file system, which was designed to use every available block of disk space by scattering file blocks throughout the disk with little regard to ease and speed of access. Reading a file sequentially as UNIX does requires many disk head movements because blocks of the same file can be located on different tracks or cylinders."

(Didn't we TELL you that UNIX needs a FAST hard disk?)

After more detail about how screwed up the UNIX file system is, the article continues on the next page: "Nothing less than a complete rewrite of the UNIX file system can solve the disk-access problem. However, its effects can be minimized." Translation: we are going to paper over the problem, not solve it.

Page 13, Column 2

The reader will keep in mind that your FNE has been told that he is not permitted to criticize UNIX since he is not an experienced UNIX operator. The more we read articles like the one we are quoting here, which not only assert that UNIX's file system is busted but explain in detail exactly HOW it is busted, the less likely it is that we will EVER be an experienced UNIX operator! Here's more from that article:

"During the early 1970's, when UNIX was originally implemented, the ASR-33 Teletype was the only reasonably priced interface to a minicomputer system. It was inexpensive, easily maintained and widely available. But it was also slow - 10 char/sec - and required 10 pounds of pressure to depress one of its keys. Because the ASR-33 ran at a slow 110 baud, little attempt was made to streamline UNIX's terminal interface. The aggregate throughput for terminals on a typical UNIX system today is barely 1200 baud, fast enough for 10 ASR-33 terminals but only one-eighth the rate of a modern 9600 baud CRT terminal."

The AGGREGATE throughput is only 1200 baud? YE GODS! You know, if we were permitted to criticize UNIX, we might say a couple of words about that! There's more:

"UNIX was the first practical portable operating system, but it often suffers in performance when ported to a different machine. For example, several benchmarks show that UNIX Version 7 is faster on the PDP-11/70 than on any of the VAX-11 systems. The PDP-11/70 is certainly not faster than the VAX-11/780 but UNIX is better tuned to the PDP-11/70, making it difficult to run UNIX efficiently on a different set of hardware without much effort."

Look, folks, UNIX is written in C. C is largely stylized PDP-11 assembly code, as we have told you before. Naturally UNIX is a better fit to the PDP-11 series than to a different computer with a different instruction set - such as either the VAX or the 68000 or the 8086 or...

You might be interested to know that the article above, which is highly critical of standard UNIX, is written by an outfit which would like to sell you a 68000-based UNIX system - an expensive one, of course - with some software patches and some expensive hardware patches (a FAST disk, smart serial I/O boards) to prop up that inefficient operating system.

You might also keep in mind that UNIX System V, which is what all the microcomputer manufacturers are implementing in cooperation with Western Electric, has ALL of the problems listed above, as well as others. (You will disregard the above material because we are not qualified to criticize UNIX, not being an experienced UNIX operator.)

Page 14, Column 1

LAUGH/CRY DEPT:

Electronic News (21 Nov '83) carries the first official release of information about Commodore's Z8000 keyboard machine. 128K RAM, built-in floppy, $700. The article concludes (p.59): "The new machine is expected to put pressure on Apple to reconsider its long-stated position that it does not compete with Commodore. Apple contends the two companies target different markets on the basis of the amount of service, support, and third-party software that is available.

"While Apple has said that although the Commodore 64 and Apple IIe use the same microprocessor and have the same on-board RAM capabilities, the disparities in support, service, software, and quality make the IIe a superior machine, and justify a $1,000 difference in retail prices.

"The Z8000 machine, analysts said, will pose a real threat to the Apple lIe, if some price and performance adjustments are not made in Cupertino."

But that article earlier asserts that the machine will use a UNIX operating system! With that floppy disk...

The same issue, page 1: T.I. is introducing two new personal computer products. One is a portable version of its PC clone. The other is a knee-top portable - for $2,000 to $3,000!

First Scully writes a letter to EN stating that the price of the IIe will not be dropped. Then he stands up in front of a bunch of financial analysts in New York and assures them that the price of the IIe will not be changed. Before all the ashtrays from that meeting have been cleaned, Apple drops the price of the IIe starter system by $150. EN reports all this, including the fact that Scully has no interest in returning EN's phone calls. We have news for Scully: financial analysts are not stupid, they have excellent memories, and they certainly do not like to be lied to. What kind of reception does Scully think he is going to get on his NEXT outing before that group?

The reader is left to decide which of the above items to laugh at, and which to cry over.

MACK IN A VEST?

At that same financial analyst meet in New York, Truthful John "...made it clear that Apple's next product, which he referred to as the Apple 32, and which generally is believed to be the MacIntosh (sic) computer, will not be for the home market." (EN Nov 14 '83 p.76) We think that means Mack will be too expensive for the home/hobby market. All that's left is for Mack to buck heads with the PC, hmmm?

Page 14, Column 2

WE GET MAIL:

"How will the introduction by Apple of ProDOS and their 6502C upgrade kit for the IIe (1/24/84) along with Mackintosh according to my usually reliable sources inside Apple - consider me anonymous if you use this - affect the DTACK-Appie IIe working combination? Will these present any hardware or software incompatibility problems?" Considered Anonymous, Davis CA

We are happily awaiting ProDOS on account of we are tired of slow, slow DOS 3.3, C.A. ProDOS has some SUPER-MODERN and EXCITING new features, such as the ability to CHAIN a program or even CHAIN to a line number. Of course, our Wang 2200 had those same super-modern features in (yawn) 1972. For more about ProDOS, see Nov. CALL-APPLE.

You have forgotten that when Creative Computing reviewed the DTACK board a year ago, the best performance was obtained when it ran WITH the Number Nine 6502C board. Our board will be VERY compatible with Apple's 6502C, if there is such a thing.

NATURALLY this stuff is going to be released 1/24/84. That's the date of Apple's annual stockholder meeting! You will recall that LISA was released at the LAST stockholder's meeting, but became available over the counter about six months later.

We didn't know Apple was working on a 6502C supercharger, but it makes sense. If you are right, Apple's fastest machine will then be the IIe, Mackintosh next, then the III, and LISA will bring up the rear. Imagine! A 6502 machine faster than TWO 68000 machines! Will you pardon us for a moment, C.A.? We feel ill...

[L.A. Times, 22 Nov '83, p.2: "A Davis (CA) Junior Chamber of Commerce fund-raiser featuring live sex acts and the auctioning off of a prostitute ended with the arrests of 22 men and women... (who) paid $12.50 per ticket to witness the 'Davis Jaycees Sports Night'." Wow! And we thought all they did was grow grapes in Davis! How much are tickets to Apple's annual stockholder's meeting, C.A.?]

"...I'm NEVER shorted-out enough to suggest support from DTACK for the VICTOR 9000. Know, sir, that the decal on my SuperPET reads 'SP9000' . That is the model number, FNE, just as '8032' is a model number. You misread the '9000' in my letter to mean the VICTOR 9000. Apologize to Sonny Tufts please, before you hear from his lawyer.

"I note John B. asserts that ASM programs are unreadable, unmaintainable, and unreliable. If so (and

Page 15, Column 1

I don't agree), let him blame HIS assembler. Mine allows structured programming (yes, it can be done), and the code is readable, maintainable, and reliable. If HLLs can get better, then so can ASM, dammit!" Dick B, Hatteras NC

Dick, we need not apologize to Sonny for associating him with the (really) high-quality Victor 9000. Sonny is as popular an actor as the VICTOR is popular as a computer (in this country, at least). Arguing ASM vs. HLL, especially if the HLL is PASCAL, is like trying to convert the Pope to Buddhism. Really.

"Ulrich Schmidt's Inter68 arrived DOA. A friend who separately bought Inter68 has the same problem... I think your customers and your company would be well-served if you discuss in your newsletter only products you have tried out.

"Please don't implement HALGOL outside of DOS 3.3! DOS 3.3 is slow, only clumsily supports high capacity disk drives, has a rotten language interface, etc... but it is the one I am using now. ProDOS is a tougher question for you, perhaps. I would vastly prefer DOS 3.3, but if you feel you must use something better, please stay with the standard Apple product." John C, Silver Springs MD

We have reluctantly come around to agreeing with you on the subject of which DOS to use, John, except that we believe (not having seen it) that we will greatly prefer ProDOS over DOS 3.3. Of course, we would prefer the bubonic plague over DOS 3.3.

As it happens, we received a glowing review of Inter68 by phone the day before your letter arrived. We are enclosing the name and address of the person who is getting excellent results with that package in the hope that you can discover what glitch is keeping you off the air. (We are trying to persuade Tom L. to reduce his glowing review to print.)

John, we're going to tell you a short story: it seems this enterprising aluminum salesman was looking for new uses for his employer's metals. So he called on Steinway, a long-time manufacturer of pianos, and suggested they replace certain parts which are traditionally made of ivory with aluminum. The Steinway rep agreed to give the aluminum a fair trial. "When should I come back?" asked the salesman. "Oh, in about a hundred years. Steinway builds pianos to last, so we will need to do some thorough testing!"

In publishing this newsletter, we can either try to get news to you soonest, or we can do the publishing equivalent of 'thorough testing'. We have decided that a purpose of this journal is to move information

Page 15, Column 2

SOONEST. That means (among other things) that we publish claims for third-party software as given, clearly identifying the source of those claims. We publish reviews later, when we can get them.

Clearly, the problem you are having with Inter68 is not general. Let us know what the problem was when you clear it up, if you don't mind. (John has a static RAM board, so it is not the UTIL4 vs UTIL7 problem that is currently giving Grande owners fits, if temporarily, with respect to third-party software. See details elsewhere in this issue.)

Faithless Correspondent Nils D. has finished licking his wounds (issue #23, pp15-16) and has returned in fine fettle. Better yet, he now has a word processor and Gemini-10 printer for his VIC-20, so we don't have to employ an Egyptologist to decipher his hand-scrawled missives:

"Where are the Japanese, you ask? Alive and well and looking for honest U.S. software houses... Epson is probably busy sharpening their Samurai swords for a brief excursion into California. I hear that the VALDOCS package is less than outstanding in several respects, this being entirely the fault of the firm that was hired to design that package. If ADAM's word processor is, indeed, written in C, then it is a testament to the fairness of software firms that they screw their own countrymen as well - no international discrimination.

"After Jerry Pournelle jumped on the slow, converted 8080 code of Compupro's BIOS and hinted at the poor performance of CPM/86, some native code work was evidently started. [Native code work? Are the natives restless tonight?] It is rumored that Bill Godbout, a man who insists on quality first, is not pleased to learn that he was hornswoggled with crude software... Small computer manufacturers [the ones shorter than 5'3"?] cannot afford to be stuck with poor code that makes their machines noncompetitive in speed or reliability [sounds vaguely familiar, Nils].

"The HLL debate rages on - as debates do when fools get going [ouch! - FNE]. There is nothing wrong with the concepts behind UNIX or C Language. The features of both could be provided for micros and prove to be valuable tools - for certain tasks where time is not a critical factor. HLLs do make it easier for novices to get started on computers and can lead to or encourage development of machine language skills by those who have the desire and ability to do so.

"You are an acknowledged speed freak, intent in specializing in number crunching and graphics displays. I see a system developing that will cost less and run

Page 16, Column 1

much faster than LISA. You don't need it, but good luck. Now when did you say that larger static memory DTACKs would be available?" Nils D, Wethersfield CT

Nils, one company already has a 608K static RAM DTACK system. That's a 92K 68000 board and four 128K expansion boards. Just exactly how large a static RAM system are you looking for? (Their application cannot stand the 18% speed degradation of the Grande, in case you were wondering.) Almost ANY personal computer is faster than LISA, except the 99/4A. And we will take all the luck we can get, thank you.

Now, about your phrase, "Epson is busy sharpening their Samurai swords". A long while back, with the coming of the industrial revolution, it became necessary to provide practical means of capital formation. In the U.S. the "corporation" was invented. A corporation is, legally, a "person" (corpus?) who can sign contracts, incur debts, go bankrupt, etc. Your phrase, written from an American point of view, should be "Epson is busy sharpening its Samurai sword".

In England the problem of capital formation was solved by permitting associations of investors with limited obligations. An English "limited" company is therefore plural, and in England your phrase would read "Epson ARE busy sharpening their Samurai swords" (emphasis added). Since your phrase combines "is" and "their" we conclude that your letter was written while you were in the middle of the big creek.

[An aside to our other readers: Nils picks on US, so it is only fair that we get our at-bats, too. And, if you pick up an English magazine related to personal computers, it will be less jarring to read "Commodore are doing such-and-such."]

Reader John B. has sent us a thoughtful letter which includes a two-page list of important events in the software world, beginning in 1940. Here are the last two items on his list:

1981-1983 Enter Apple's LISA in UCSD Pascal. "integrated software", "leveraged learning", "common user environment", "cut and paste", "visual computers", "desktop", "icons", "invisible operating system", "advanced error messages", "minimum effort", "Apple Interface principles", "top-down analysis and design", recursive implementation", "we were developing everything in parallel: the hardware, the operating system, the applications, the manuals, the details of the user interface"

1983-1984 Enter Apple Mackintosh in HLL?

Here is OUR version of those two items:

Page 16, Column 2

1981-1983 Enter Apple's LISA in UCSD Pascal. "five characters behind a touch typist", "benchmarks slower than an Apple II", "one of two factories closed outright, the other cut back to 45%", "a belated 18% price cut in a desperate attempt to stimulate sales", "200 man-years of development", "it was introduced prematurely", "mass-market failure proved by lack of even ONE LISA-related national magazine"

1983-1984 Enter Apple Mackintosh in HLL?

John writes, "If you still need a dragon to slay I suggest you print these three sentences:

"What I would like to argue is the following proposition. By January, 1985 you will feel the same about your current opinion of HLLs as you now feel about DRAM error rates. The convincing event that will forever change your mind will be the stunning success of Apple's Mackintosh." John B, Burlingame CA

John, we have written elsewhere in this issue that we believe that Mackintosh will in fact be a stunning success IF it has an operating system and BASIC written in assembly, like the popular Apple II. Consider the following two facts: 1) EVERY personal computer that has had a mass-market success has had an operating system and a BASIC written in assembly. 2) NO personal computer with an operating system and BASIC written in HLL has yet been a mass-market success. It is true that those two facts do not PROVE our opinion that a personal computer CANNOT be a success with an operating system and a BASIC written in HLL.

In fact, our opinion CANNOT be proved, by its very nature. Over the next 200 years 3,782 personal computers may be introduced in HLL, and 3,782 personal computers may fall on their face at an aggregate loss of trillions of dollars but one never knows, number 3,783 just might make it

Mackintosh has everything going for it. If any HLL personal computer is going to make it in this decade, Mack will be that computer. There are several national magazines already planned to support the computer. The problem is, we remember a year ago how wildly successful LISA was gonna be. Then folks found out about "five characters behind" and "benchmarks slower than the Apple II".

If we have not proven OUR opinion, John, you certainly have not proven YOURS. It seems we have a horse race, a difference of opinion being what it takes to make a horse race. Now for the bad news: although Mack will be introduced Jan 24, it will not be on retailers' shelves until a LONG, LONG time afterward. So we will not be able to declare which of us is right until about this time next year.

Page 17, Column 1

LOCAL HALGOL VARIABLES:

HALGOL now (soon?) features local variables in Halgol subroutines, thanks to some help from Terry P. By the way, Terry points out that he SIGNED the letter which we edited to "Understandably Anonymous" in issue #26. Apparently Terry is unafraid to make fun of you lowly Apple users who do not have a screen editor.

Here's how it works: give HALGOL the operator LOCAL, which should immediately follow the label of a subroutine. Here is what a HALGOL subroutine might look like to the operator:

  5000 "DO IT" 
  5010 LOCAL X,Y,SCORE,TOTAL 
  5020 ... 
    : 
    : 
  5140 RETURN

This subroutine declares four named variables as local to the subroutine. The run-time HALGOL code might look like this to the 68000:

  <LOCAL> 
   $0004 
   $0008 
   $0020 
   $0100 
   $0000 
     : 
     : 
  <RETURN>

<LOCAL> represents the action address of the function LOCAL, followed by the number of local variables, and then the base offset addresses of the four (in this example) variables (numbers 1, 4, 32, and 0). Then we have the body of the subroutine, and then the action address of RETURN. The RETURN action address is the same for a subroutine with or without local variables (the SAME "RETURN" might serve for both purposes if a subroutine has two entrance points.

Note that there is no run-time code for the name of the subroutine at the start of the subroutine; the label is kept in a table that is associated with the (entry and edit-time) code, not the run-time code.

We also want to look for "RETURN WITHOUT GOSUB" errors, else our threaded code might go off into never-come-back-from land. How to do all this simply and quickly?

At run time we initialize the machine stack pointer to $1FF8, and store all zeros in the next two higher long-words. Then we use the following assembly code at the action address for RETURN:

Page 17, Column 2

  RETURN  MOVE.L (A7)+,D7 ; FETCH RETURN ADDRESS 
          BEQ    ZERO     ; SKIP IF ZERO 
          ADDQ.L #2,07    ; CORRECT FOR GOSUB ADDR 
          MOVE.L D7,A6    ; NEXT HALGOL ADDRESS 
          JMP    (A4)     ; NEXT HALGOL INSTRUCTION 

  ZERO    MOVE.W (A7)+,D7 ; ANOTHER ZERO ? 
          BEQ    REWOGS   ; ERROR, NO GOSUB 

  ; D7 CONTAINS THE NUMBER OF STORED VARIABLES 
  ; NOW RESTORE THEM. 
          MOVE.L VBASE,D5 ; VARIABLE BASE ADDR 
  LOOP    MOVE.W (A7)+,A5 ; VAR BASE OFFSET TO A5 
          ADD.L  D6,A5    ; ADD BASE ADDR 
          MOVE.L (A7)+,(A5)+ ; RESTORE A VARIABLE 
          MOVE.L (A7)+,(A5)+ 
          SUBQ.W #1,D7    ; DECR VAR COUNT 
          BNE    LOOP     ; RESTORE ALL VARIABLES 
          BRA    RETURN   ; NOW RETURN ! 

  ; IF TWO CONSECUTIVE RETURN ADDRESSES ARE ZEROS, 
  ; THEN WE HAVE A 'RETURN WITHOUT GOSUB' ERROR. 
  ; (The error code "REWOGS" is not listed here.)

Now, here is the run-time code for LOCAL:

  LOCAL   MOVE.W (A6)+,D7 ; FETCH # OF LOCAL VARNS 
          MOVE.W D7,D0    ; TO D7 AND TO D0 
          MOVE.L VBASE,D5 ; VARIABLE BASE ADDR 
  LLOOP   MOVE.W (A6)+,D6 ; FETCH BASE OFFSET TO D6 
          MOVE.W D6,A5    ; AND FETCH TO A5 
          ADD.L  D5,A5    ; ADD BASE ADDR 
          ADDQ.L #8,A5    ; CORRECT FOR ADR MODE 
          MOVE.L -(A5),-(A7) ; STORE VARIABLE ON STK 
          CLR.L  (A5)     ; INITIALIZE LOCAL VAR 
          MOVE.L -(A5),-(A7) 
          CLR.L  (A5) 
          MOVE.W D6,-(A7) ; STORE BASE OFFSET ADDR 
          SUBQ.W #1,D7    ; DECR VAR COUNT 
          BNE    LLOOP    ; STORE ALL VARIABLES 
          MOVE.W D0,-(A7) ; STORE VAR COUNT ON STK 
          CLR.L  -(A7)    ; 0 = LOCAL VAR IDENTIFIER 
          JMP    (A4)     ; NEXT HALGOL INSTRUCTION

The code above stores the variables which are being used as local variables on the stack, initializes the local variable to zero, and stores the base offset address of that variable on the stack. After all variables are stored and initialized, the local variable count is placed on the stack. Finally, a dummy return address of zero is placed on the stack to identify the presence of local variables when executing RETURN.

(Note that we have to add #8 to A5 at one point to compensate for the predecrement address mode.)

Page 18, Column 1

This is really very simple, especially after Terry explained to us how to do it. But, it is fairly easy in general to add functions to HALGOL, largely because assembly language programming on the 68000 is so simple and straight-forward. If you were paying attention when scanning the assembly code just listed, you will have noticed that HALGOL GOSUB and RETURN addresses are 32-bit values. HALGOL is not in any way limited to 64K segments, unlike IBM PC BASIC and SofTech PASCAL.

EXAMINING THE STACK:

To make sure we all understand this, let us examine the stack after we have entered the example subroutine with four local variables. The stack grows toward lower memory, and in program listings lower memory locations are printed FIRST. Therefore, the TOP of the listing below is the BOTTOM of the stack. The number on the left is the number of bytes in each item:

   4    FALSE ZERO RETURN ADR 
   2    NUMBER OF LOCAL VARIABLES 

   2    BASE OFFSET OF LAST LOCAL VAR 
   8    STORED VALUE OF VAR 

   2    BASE OFFSET OF 3RD LOCAL VAR 
   8    STORED VALUE OF VAR 

   2    BASE OFFSET OF 2ND LOCAL VAR 
   8    STORED VALUE OF VAR 

   2    BASE OFFSET OF FIRST LOCAL VAR 
   8    STORED VALUE OF VAR 

   4    HALGOL SUBROUTINE RETURN ADR

We can see that the number of bytes on the stack due to the use of local variables is 6 + 10N where N is the number of local variables. The last four bytes above, the HALGOL return address, will be needed whether local variables are used or not, and so cannot be charged to the local variables.

NESTED LOCAL VARIABLES:

So what happens if we call another subroutine from a subroutine which has local variables? No problem, the return address is stored on the stack, masking the false zero return address identifying the presence of local variables. That subroutine will be executed, and a return to the original subroutine performed with no problems. If one of the local variable names is encountered in the nested subroutine, it is the local value of that variable name which will be used/modified.

If we call another subroutine from a subroutine which

Page 18, Column 2

has local variables and the new subroutine ALSO has local variables, again there is no problem. If a new local variable has the same name as one of the old local variables, then the old local variable will be stored on the stack, to be restored when RETURN is executed.

PASSING PARAMETERS:

We do not yet have the ability to pass parameters to those local variables, using code like this:

  100 GOSUB "RECT-POLAR",WIDTH,HEIGHT 

  960 "RECT-POLAR" 
  970 LOCAL X,Y,SCORE,TOTAL

It seems to us that the value of variable WIDTH should be passed to local variable X, the value of HEIGHT passed to local variable Y, and local variables SCORE and TOTAL should be initialized to zero. (Maybe Terry will take pity on us and explain how parameters should be passed, too. We are not either too proud to accept help in programming HALGOL. Remember, writing a programming language is one of those things which should never be done for the first time.)

'CONSTANT VARIABLES'

Two of our more alert readers discovered the obvious problem involved in keeping constant variables and named variables in the same table. We discovered it too, which is why we are using a separate table now for constant variables and another table for the constant variable's NAME, which is of course the ASCII representation of the constant.

We are still storing the constants in their floating point representation. At no time (while running a program) does HALGOL ever have to stop and translate an ASCII constant into its floating point equivalent.

STRINGS AND THINGS:

Now that HALGOL is functional in an increasing number of respects, including the ability to print literal strings (the string equivalent of a numeric constant) and to have prompts as part of the input statement, the time has come to begin planning for string variables. As we have told you before, a person's actions are generally based on his past history. We know only two ways of implementing strings, the right way (Wang BASIC) and the wrong way (Microsoft BASIC).

Microsoft strings have the well-known "garbage collection" problem and the lesser known handicap that binary data cannot be handled and manipulated as a string array. The particular version of Microsoft

Page 19, Column 1

BASIC with which most of us are familiar (Pet or Apple variety) has the further handicap that MID$ cannot be used on the left side of an equation. We have in the past asserted that a BASIC which does not permit MID$ to be used on the left does not have strings - a perhaps exaggerated viewpoint.

YOU are also a product of YOUR past history, hmmm? If you have only encountered Microsoft strings in the past, you may believe that they work in accordance with the natural laws of the universe. Uh uh. But they do have one advantage that Wang-like strings lack: One never has to worry about how long a string is. Which also means that if you are saving strings into a file, you don't know how big the file can be, yes? The following idiot program will quickly bomb a computer using Microsoft BASIC:

  100 A$ = "A" 
  110 A$ = A$ + A$ 
  120 GOTO 110

Wang strings have a fixed length. That means one either accepts a default length (generally 16 characters) or has to DIM the string length. You might be surprised how often the default length is well suited to the task at hand, and how the ability to DIM a string length simplifies setting up file structures. (If the string containing a line of a mail list is dimensioned as 32 characters long, one NEVER has an overflow on the mailing label or an oversized record in a sequential file.

Microsoft BASIC, with its apparent freedom, presents the opposite problem: the need to limit the length of strings. This is generally done slowly, in BASIC. In Wang BASIC the process is automatic.

STRING ARRAYS DONE RIGHT:

If you have never had the opportunity, it is hard to understand how important it is to treat binary object files as string arrays. Among other things, this allows string manipulations on binary machine code. Consider the following hypothetical program line:

  100 MAT SEARCH A$()=HEX(A900A2FF) TO ADR$(),N

You may recognize the hex string as "LDA #0, LDX #255". That program line will search array A$() for all occurences of the four-byte substring, and return the addresses [with respect to the first byte of A$()] of every match to array ADR$(), plus the total number of matches to N. If the number of matches is larger than the number of elements in ADR$(), this will be identified in N. A question: if you program in BASIC, how have you managed to get along without such capability up to now?

Page 19, Column 2

(The preceding example is not quite identical to Wang BASIC. The difference is that the first byte of an array in Wang BASIC is #1, not #0 as it will be in HALGOL. As a result, Wang issues a "no match" or "end of matches" in the destination array ADR$() with a zero address, and hence does not need the additional parameter N. But if the number of matches exceeds the number of elements in ADR$(), there is no way to identify that number.)

Thoughtful correspondence on string functions is invited. As we have indicated, our past experience covers only two ways to implement strings. We have an open mind to anything but "Waaah! It's just GOTTA be exactly like Applesoft!"

[Later: The Dec '83 issue of IEEE Spectrum magazine has just arrived. On page 24, under the headline "Collecting Garbage" we find the curious and amusing assertion that a fundamental law of the natural universe is that interactive languages (read "BASIC") have a garbage collection problem. This will doubtless amuse long-time readers of this newsletter and will cause paroxysms of laughter to ring down the hallways at Wang Laboratories.]

"THE FACTS" YET AGAIN:

It seems that the rumor and "THE FACTS" which we published two issues back kicked up quite a ruckus, thanks to the publicity John Dvorak gave it in INFOWORLD. We continue to hear, from the other side of the big creek for instance, that we were wrong. We think a certain British journalist has checked with IBM and has checked with Microsoft, which means he has checked the same place twice. When Gates speaks, Prestridge's lips move. You will recall that Microsoft employed 15 persons before IBM, and 400 NOW. If that does not make Microsoft a chattel of IBM then you must know something we don't.

We suggest you check John Markoff's followup story on page 23 of Vol 5, #49 INFOWORLD. That's the one with the chained floppy disks on the cover. (We have two copies of this issue, one dated 5 Dec and the other 12 DEC.) In the third column, note the quotation from David House, who is the guy who runs microprocessor development and production at Intel. House confirms reports in EN three weeks earlier:

"House also acknowledged the accuracy of the incompatibility reports. 'It's true that Intel reserved a series of interrupt vector locations, and Microsoft used them, he said."

You will recall that in the EN story (17 Oct p.24), House additionally confirmed that the 8018X mask was being re-done because of a conflict with MS-DOS. Thus,

Page 20, Column 1

in those two stories, THE GUY WHO RUNS MICROPROCESSOR DEVELOPMENT AND PRODUCTION FOR INTEL HAS ABSOLUTELY CONFIRMED THE ESSENTIAL ELEMENTS THE STORY WE RAN TWO MONTHS AGO. If you wish to accuse us of being equally as ignorant about Intel microprocessors as the one person in the world (David House) who should know the MOST, then we will willingly plead guilty. We do not regard such as occasion for calling a rump meeting of the Societe Anonomie d'Stetsonphage. Nor is it at all surprising that some vested interests (IBM. Microsoft) are trying to deny that story. (See John Dvorak's column the same issue.)

"THE FACTS" originally ran in issue #25, which featured detailed information about the use of the 16081 floating point math processor with the 68000 microprocessor. We still find it hard to believe that "THE FACTS", which was printed as a divertissement, has attracted three orders of magnitude more attention than the 68000/16081 combo. Maybe John Dvorak was correct when he asserted that this newsletter is really a gossip rag?

A HALGOL DOS?

As the old cliche goes, let us run this one up the flagpole and see how many of you salute it: The problem of a HALGOL DOS is primarily one of compatibility. Blue Sky One is a great idea for folks who have a half-gallon (or more) Grande and who do not need compatibility with DOS 3.3 or ProDOS or hard disks. It is not such a hot idea for the folks who have a 92K (or 60K, or 28K) static RAM board. And many of you have expressed a desire to stay with one of the standard Apple DOSes.

There are a bunch of DOS speed-ups available lately. Only one speeds up both loading and saving text files (Diversi-DOS 2-C). A review of this utility can be found on page 24 of Vol 4 #3 Peelings II magazine. Since this disk loads and saves binary files five times faster than DOS 3.3, it might be nice if we could use it, too?

So how do we make our HALGOL DOS compatible with DOS 3.3, ProDOS, Diversi-DOS and with hard disks? Applesoft is the common denominator, yes?

WHAT IS A FILE ?

Why, a file is a collection of ones and zeros. Different types of files interpret those ones and zeros in different ways. The SAME pattern of ones and zeros might mean "3.141590" or "bomb Pearl Harbor at dawn" or "735 GOSUB 1310". All we need to know is the type of data, and the ability to load and store that data.

Page 20, Column 2

We can store any kind of data whatever - Applesoft BASIC programs, Integer BASIC programs, text files, even binary data (!) in binary files, provided we ALSO store - maybe in the first byte of the file? - the type of data in the file. Now all we need is the ability to load and store just one kind of file - binary data. Remember, we will be loading and storing to and from a 68000-based DTACK board, with a short stay in the host RAM in transit.

THE HALGOL CATALOG:

All of the files on our HALGOL disk, with one exception, will be binary files. The one exception will be the HELLO program, which will be a short Applesoft program, to serve as the HALGOL loader. The binary file HALGOL will contain the 68000 HALGOL run-time code as well as the 6502 utility code and HALGOL I/O handling code. Finally, the binary file HCAT will contain the HALGOL catalog. So an "empty" HALGOL diskette will have (for DOS 3.3) the DOS recorded on the first 3 tracks, a HELLO Applesoft program, and HALGOL and HCAT binary files.

When listing the HALGOL catalog while running HALGOL, none of those will appear in the catalog listing. Only HALGOL programs or data files will appear in the catalog listing while running HALGOL. The HALGOL catalog and the DOS 3.3 catalog are essentially unrelated except that the HALGOL catalog "HCAT" is contained in the DOS 3.3 catalog.

Indeed, ALL of the files in the HALGOL catalog will be contained in the DOS 3.3 catalog, although not under the same name. That way (for instance) we can have a HALGOL HELLO program.

How do we get from the 68000 to the disk? Via the host RAM as a way-station, that's how. How big is the host buffer? Well, if we set aside $2000-$8000 as a DOS buffer, each binary file is limited to 24K bytes. If we have a file to store that is larger, the file must be broken down into subfiles of 24K. So the SECOND byte of each binary file contains the number of sub-files remaining in the file. This means HALGOL files are limited to 256 times 24K, or about 6 megabytes per file, which seems to be adequate (if not, we just make that a 16 bit parm and presto! 1.5 gigabyte files!

FRAGILE APPLESOFT:

The ONLY thing that Applesoft is used for under this scheme, aside from initially loading and starting HALGOL, is saving or loading binary files. UNFORTUNATELY: a disk error will leave you hung up in the DOS 3.3 operating system. Pray for no disk errors? This will require some thought.

Page 21, Column 1

HOW ??

You mean, how can we use Applesoft to load and save the binary files and yet claim that we have a 68000 language here? Simple. The 68000 writes, modifies and restores the Applesoft program on the fly. The loader program looks like this, in schematic form:

  HOME:TEXT 
  LOAD HALGOL BINARY FILE 
  RESET THE 68000 
  TRANSFER HALGOL CODE 
  COMMAND 68K TO EXECUTE 
  CALL 6502 I/O UTILITY

That leaves the 68000 in charge of things, with the 6502 accepting and executing a sequence of commands from the 68000. One of the commands which can be executed is to send the 6502 back to BASIC (Applesoft). If we execute that command, program execution will terminate because there are no more programs lines to be executed.

YET.

Because the 68000 can (easily) read and write data from and to the host, it can easily find the end of the existing program by simply reading the SOV (Start Of Variables) pointer in the Apple at locations $9A, $99. It can then read up and save the first 64 (for instance) bytes AFTER the end of the program, and then write two new Applesoft program lines over that variable area. (This is O.K. provided the two lines do not use variables, and they don't.)

Let us say that the operator keys in the HALGOL command:

  SAVE PROGNAME

First the 68000 will determine that we HAVE a program, however long or short, to save. (No program, no action.) Then it figures out how many bytes, the important issue being more or less than 24K? Let's say the total number is 4K NOT including the file type identifier and the zero indicating no more 24K records after the first record. Oh, yes: we do need two more bytes indicating the number of bytes in the file, don't we?

Well, we place these four header bytes and the other 4K bytes in the host RAM beginning at $2000. Then we write a short program which is the Applesoft version of

  65534 PRINT CHR$(4);"BSAVEBA,A$2000,L$1004,D1"

followed by 65535 CALL 38380, assuming 38380 is the entrance to the 6502 I/O handler.

Page 21, Column 2

Now we send the 6502 the command to return to BASIC. It does, and promptly executes line 65534, saving our binary file under the dummy name BA, then jumping right back into the host HALGOL I/O handler. The 68000 is waiting for the 6502 to respond to the next I/O command, which is to restore the start of the variable table (remember we stored 64 bytes in the 68000?).

We will not forget to update the HALGOL catalog, will we?

NEVER FOR THE FIRST TIME:

As we have mentioned before, there are certain things which should never be done for the first time. Writing a DOS is one of them. As it happens, we wrote a 6502 DOS on our Wang 2200 back in '77 and it worked. It was sorta crude because it only had one job to do, but it did that job well. Now we have to write a 68000 DOS on an Apple - a similar task.

Another thing we have done is play with writing Microsoft 6502 BASIC program lines from assembly. We did this three years ago, just before we built our prototype 68000 board. Turns out this is so simple it really shouldn't be listed as one of the things which should never be done the first time. (If you want to see what the desired code looks like, just enter the BASIC line from the keyboard, drop into the monitor and look at the line in hex. Nothing to it.)

Following is a short review of Ulrich Schmidt's Inter68:

The Ultimate Speed-up Kit?

"In my laboratory at the University of Washington, we are amongst those folks who find that using Pascal is an excellent way to produce the kind of programs we require, without having hideous problems with software maintenance. As has been well discussed in the pages of this newsletter, there are certain difficulties with execution speed with the UCSD Pascal system and Its derivatives. For many of our applications, the speed has not been considered a major problem. However, during the last two years, we have tried to push our Apples to new and, at times ridiculous, heights. We bought our first DTACK cards over a year ago with the specific intention of installing the UCSD P 4.1 system on them. Due to certain other problems, such as fulfilling contractual arrangements with the various funding agencies of the federal government so that we could eat, we have not had a great deal of time available for pursuing our goal. Instead, we have had great fun learning to use 68000 assembler and designing projects to use DTACK cards.

Page 22, Column 1

"While it is still our full intention to pursue those goals, we noticed with great interest the writeup in the recent newsletter concerning the development of an interpreter for the 68000 which would execute Apple Pascal. At the extraordinarily reasonable cost of $40, Ulrich Schmidt provided us with a manual and two diskettes worth of software. What we have received is an extraordinarily well done piece of software that worked when we first tried it.

"What is provided is an interpreter that loads onto the 68000 and, with a few exceptions, emulates the Apple Pascal v1.1 P machine. Exceptions have to do with 'byte sex' of the 68000 as compared to the 6502, and the resulting difficulties with data files. Mr. Schmidt has carefully discussed in his manual the reasons he chose not to compromise 68000 speed to make the system fully compatible with Apple Pascal data files. If one wants to transport data files created under the normal Apple Pascal system, and if those data files utilize integers and characters, it will be necessary to change the ordering of the bytes within the data file. If you know the structure of the data file, this is rather easily accomplished with appropriate use of block reads and block writes. If, however, you are dealing with a piece of commercial software, problems can arise.

"I have been using the software only for about two weeks, and in fact, have only used the first version of the interpreter and have not yet tried the high resolution graphics version. But the results were so encouraging and impressive, I thought that a brief review of the standard interpreter would be of interest.

"The software comes configured for the DTACK card to be installed in slot 2 of the Apple. I have always found this to be a great inconvenience, since typically the remote communications card is in slot 2. In my case, it is a bit more complicated, since about half of our Apples have Corvus hard disk interfaces in slot 2 with the interpreters modified to redirect the remote output to slot 4. However, Mr. Schmidt has been kind enough to provide a great deal of source code on the disk that is sent, and it includes the sources for all the critical I/O utilities which are slot specific. Therefore it was a simple matter of changing some global constants and reassembling the utilities in question.

"To bring the system up, it is first necessary to run a program which makes a new version of System.Pascal, called 68000.Pascal, which includes a few new op codes to handle certain critical problems with byte sex and running the operating system. Once this has been accomplished, it is only necessary to move three code files to your primary disk. These include the 68000

Page 22, Column 2

interpreter, and two utilities called UPLOAD and CALL68.UPLOAD very rapidly installs the 68000 interpreter onto a DTACK card, and CALL68 causes the 68000 to execute a warm bootstrap. This essentially looks like a standard system initialization, and proceeds very rapidly. From that point on you are running on the 68000, with a verified average increase of a factor of 10 in execution speed.

"The first thing we did was to execute a series of benchmarks to compare the standard Apple Pascal to the 68000 interpreted version. To help us along, Mr. Schmidt has included on the distribution disk a benchmark program. We ran these benchmarks and verified all of the time differences mentioned in the previous newsletter. We then proceeded to compile and execute many of our programs and found the same average speed increase.

"An immediate application presented itself in that we had begun using in our laboratory a very powerful document formatting program (fancy word processing for developing manuscript and technical manuals) called the Incredible Text Printer by Datamed Research. The only problem is that the program, when running on an Apple II under Apple Pascal, is not a speed winner. In a relatively simple document with primarily block text, the output speed to the printer was on the order of 30 characters per second. After our first week and a half of playing with the 68000 interpreted Apple Pascal, we decided to try to run the ITP system on the DTACK GROUNDED card.

"The immediate problem was that the program utilizes a series of user settable parameters to initiate printout. These parameters can be saved in a series of files and include most of the normal format options one would select. These were stored within a separate data file, and it proved to be a relatively simple task to compare the setup display and determine the location of the parameters within the data file. Then after a simple five minutes of work with the patch utility, a data file was created which the formatting program could read. Once a single such file had been made, the program itself was able to create additional format files.

"With a total of 30 minutes of work, the ITP system was running totally and without any problems whatsoever on Mr. Schmidt's interpreter. Instead of printing 30 characters per second, we are now printing 200 characters per second, with the speed limitation being disk access. Once the ITP was set up on the system, it became an obvious move to set up the advanced systems editor on the interpreter also. This turned out to be extraordinarily simple, since the normal configuration program supplied with the ASE editor ran without difficulty on the 68000.

Page 23, Column 1

"Thus, after a total time spent of one hour, we had a first class word processing system up on the DTACK GROUNDED card, with truly impressive performance. We installed the software system in our physics research laboratory and immediately won smiles and sounds of appreciation from our primary secretary. Upon describing the performance of the system to a second secretary working in our main clinical area I was faced with what could best be described as the potential of work stoppage until I promised to obtain yet another DTACK GROUNDED card and provide the same high speed facilities on her Apple.

"The bottom line is that Mr. Schmidt has produced an interpreter which allows one to execute Apple Pascal programs and attain a significant increase in speed, commonly a factor of 10. He includes an adequate manual and plenty of source code to allow users to adapt specific drivers for any device they may have attached to their Apple. We are just now beginning to use the high res graphics version, and we will send a "review" of that version after we've used it a bit longer."

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

WE GET MORE MAIL:

"I talked to some of the local National Semiconductor distributors, and they are indeed offering the 16081, but there is a 6-7 week delivery time. Since you seem to be able to get them 'over the counter' out there in sunny California, why don't you sell your boards with the chip included? I don't feel like voiding the warranty on a kilobuck board.

"On the lighter side of things: Are you aware of Steve Passe's 68000 public bulletin board? It was listed in the latest Dr Dobb's (303-781-4937). I logged into this system, and found that there is a fair amount of gossip about the notorious FNE and his journal. Of course I set the record straight - you don't really eat 8080s for breakfast." Charles B, Princeton NJ

Not without strawberries and cream, Charles. Speaking of "lighter", about your printer ribbon: shame!

We don't sell our math board with the chip included because no company can buy something for $200, sell it for $200, and stay in business. By selling the board with an empty socket, we're giving our customers the best deal possible. That chip is (for now) an engineering sample, not fully guaranteed. That's another reason we can't sell it.

Page 23, Column 2

We do not warrantee the $125 math board because it is designed to work with the ENGINEERING SAMPLE 16081, and Nat Semi may change the design in some manner (like going to 28 pins) that will obsolete our board. That would not be our fault.

The fact is, we are VERY VERY early getting "on board" that math chip, which is about at the point the 68000 was in the summer of 1980. Anybody who wants "on board" the 16081 right now should understand that the device is yet experimental and that the user must assume whatever financial risk is involved. Just how much responsibility can we assume in exchange for $125?

But we do not understand your comment about voiding the warranty on a $1000 board. Use of the math board does not void the warranty on our 68000 boards, unless you are unwilling to let US - at no additional charge - make the modifications to your static RAM board to accommodate the math chip. (The Grande requires no modifications.)

(We have donated $1 to Charles' new ribbon fund.)

"Just a note to let you know that I now have Inter68 up and running. As you can see by the enclosure, there WAS a small bug. I suspect most people will want to use the version that allows graphics commands, and has no bugs. I, too, am now an Inter68 enthusiast and recommend it highly." John S, Silver Spring MD

John, we are sure glad YOU are happy because there is somebody else out there who ain't. John T of Seattle, WA is unhappy with just about everything we DON'T do. One of the things we have failed to do is, for now, make our interactive 3-D program D6A available with the Grande. Shame on us! Further, we neglected to alert our third-party software vendors to the (minor) differences between the Grande and the GROUNDED boards at a sufficiently (for John) early date. Not only that, but we failed to do whatever it was we were supposed to do when he returned ONE of the three nearly full diskettes we mail with each Grande.

Now, the fact is, much of the third-party software, such as Inter68, MINOS-1, Bruce Walker FORTHs, etc. does not work (as of two weeks ago) with the Grande. The reason is those third-party software vendors - with the exception of Chet Sensenig - do not own Grandes. As a result, they have doubtless modeled their communications routines between the host and DTACK boards on UTIL4, a utility which does not always use full handshake between host and 68000. The Grande, which may be interrupted at any time to do a refresh, requires full handshake at ALL times. We have therefore written UTIL7, which is identical to UTIL4 except for full handshake. UTIL7 is fully compatible with both the Grande and GROUNDED boards.

Page 24, Column 1

We waited until just after the Grande folks would have discovered that MINOS-1, Inter68 etc. did not work to send out the revised software. This is the psychologically correct moment, John. If we had sent UTIL7 out earlier, one of two things would have happened: the revised software would have been filed and forgotten or lost or both, or the third party vendors would have said to themselves, "HMMM! Our software won't work with the Grande, but then we do not own a Grande and there are few Grandes out there, so we will return this order and explain that our software does not work with the Grande."

By delaying until after most third-party vendors had already accepted a small sum of pecunia, and therefore incurred a moral obligation to some Grande owners, we have (this is the truth, John!) actually ACCELERATED the delivery of working Grande software to Grande owners! Your gratitude for our astuteness is curiously lacking, John!

(We insist that the foregoing analysis is correct. We do not claim it was planned in advance - FNE.)

"Are you sure you don't write all those letters yourself, a la Penthouse magazine?" Roy M, Santa Cruz CA

Just yours, Roy - FNE

"I enjoy your newsletter, especially reading about all this new hardware coming up. Too bad we can't get any of it over here. I guess we Germans are really subversive as hell and the CIA keeps a close watch on every (electronic) hardware store in North America to catch every foreigner daring to buy a 68000 there.

"Even though I am condemned to be a passive onlooker, I am still looking forward to new exciting products, especially a multiple 68000 board. (I really would like to see how you tackle writing the software for it.)" Thomas W, Munich W. Germany

Passive onlooker? The great European Theatre Coordinator for DSEx? And you know very well that 68000s, including the 12.5MHz variety are readily available across the counter in your country as well as Japan. The folks making the export regulations in this country are really stupid. They actually seem to think that microprocessors are exclusively American!

About software for the multiple-68000 board: we would provide some demos to serve as examples and let it go at that. To incorporate multiple micros into a high-level language one is limited to linear algebra and matrix applications unless one wishes to learn a very great deal indeed about data path analysis - and we don't so wish.

Page 24, Column 2

"You produced some head-scratching around here when you referred to THREE correspondents from Faulconbridge. Eric L. and I know each other well, but we couldn't think of everyone else. Then the penny dropped - Kathy Meziere originally got my name fairly spectacularly wrong. Actually, having two correspondents from a town with a population of 2000 is doing pretty good.

(After explaining about the F8 ROM) "Actually I'm not that clear about how much knowledge of Apples as such you do have. I know you didn't come from there. Also you give the impression at times of knowing less than a reasonable amount about numerical methods 'wasn't sure he could handle pivoting' (or similar) appeared in one of the newsletters. I'm willing and able to help in these areas if you need it, but I have a feeling you enjoy making yourself out to be less knowledgeable than you are." Ken O, Faulconbridge Australia

In defense of Kathy, your handwriting is fairly spectacularly illegible, Ken. It's a good thing you PRINT your name at the top of your correspondence now, or we would probably think we had seven Faulconbridge correspondents.

We really ARE as unknowledgeable (read: ignorant) as we appear. We do know a little bit about hardware and a little about software AND we manage to knock out a newsletter regularly (with some help from you folks) that some people find interesting, and we're satisfied with that. We don't need to claim more smarts than we have - folks who do always get tripped up, no?

"Whadda yew think of the HP150 as an upgrade for my PET 4032? As in, the next time you're opinionating over new hardware." Don P, Winnipeg Canada

Buy a Trash 80 Model 2000 instead and save $1000. You get a better CPU (once the mask is fixed), better floppies, better graphics and more standard equipment. HP means High Price. Don't forget to replace the 80186 CPU once (IF) Intel gets the mask stabilized.

Or (here comes the commercial) wait a few more months and buy a Grande for your PET - when we have pure 68000 software (HALGOL), we will port it to the PET. Still no graphics but you save another $2000. And, if you program in assembly, you don't have to go honey dipping.

"The notion of a newsletter anent the MC68000 family and other arcana sounds wonderful and timely. Please send me subscription info." Michael 5, Hayward CA

TIMELY? Michael, we have been publishing this rag for 2 1/2 years now!

Page 25, Column 1

BUSINESS STUFF:

Suppose you are the manager of a business which has several product lines. Suppose one of them sold in quantities which are far smaller than the principal product(s). A manager - especially one new to the scene - might want to know whether that item with small sales was profitable or not. But he might find that Tom spent 10% of his time on it, Jerry 55% and Helen 50%. In fact, it might even be more difficult than that, especially in a large company. What to do?

Simple. One sets up that smaller operation as an independent business unit (with separate accounting). Tom is not in this business unit and so spends 0% of his time on it; Jerry and Helen ARE in the unit and so spend 100% of their time on it. In just a few months, the profitability of such an independent unit - or absence of profits - becomes apparent.

If the independent unit is NOT profitable it is now very simple to "prune the tree". You keep Tom and tie the can to Jerry and Helen. We DO hope that you non-business types appreciate us pointing out these little business tips, even if they are not related to your interests.

APPLE III REPORT:

John Scully has just caused the Apple Computer Co. to form an independent business unit for the Apple III computer. This is the first such unit Apple Computer has ever had. David Fradin, formerly the product manager for the III, will head the unit, which has a staff of 16 (yes, sixteen) to handle marketing, sales and engineering.

Apple has revealed that 75,000 Apple Ills have been sold since the introduction in 1980, a period of almost four years. That number is equal to five weeks' production of Apple IIes or eight working days' combined production of CBM 64s and VIC-20s.

The Apple III has also been redesigned to be more compatible with the Apple lIe. It now has a IIe keyboard and a new version of SOS to be compatible with ProDOS. The suggested resale price, with 256K RAM and ONE 143K disk drive and (by today's standards) dinky graphics is $253 HIGHER than the Trash 80 model 2000 with TWO floppies, EACH holding 720K, 128K RAM and 640 X 400 (yes, 400) NON-INTERLACED (no flicker) graphics. And the model 2000 has a 16-bit microcomputer and some degree of compatibility with IBM PC programs, running MS-DOS and using an Intel microcomputer.

Pray for Mr. Fradin and his staunch crew of 15 persons?

(Source: Electronic News, Dec 5 '83 page 28.)

Page 25, Column 2

THE BIG CRUNCH:

Floating Point Systems is the outfit that makes some extraordinarily cost-effective math stunt boxes, most of which wind up bolted onto a VAX. They have a new single-precision unit which costs only $2000 per megaflop as a response to some attempted competition. But we mostly like double precision, and the FPS-164 has been their leader in that area for some time.

"(The FPS-164) offers up to 12 million floating-point computations per second, 15 decimal digits of precision, and up to 7.25 megawords (58 megabytes) of memory for prices starting at $300,000." asserts the latest ad for the FPS-164. That's $25,000 per megaflop with minimum memory configuration.

The Grande is good for 1/12 to 1/15 megaflop when equipped with a 16081 math processor. With a minimum memory configuration (128K) and a math chip, we are up to about $1200. At 1/15 megaflop, the low end of the estimated performance range, that comes to $18,000 per megaflop - more cost-effective than the FPS-164.

If we equip the Grande with TWO math processors, it is possible that the performance may be in the 1/8 megaflop range, for about $1500. That would drop the cost per megaflop to $12,000 - just half the cost of the FPS-164. It is true that such a system would only be useful for vector type operations, but that is also true of the FPS-164, which is a vector machine. It is also true that the theoretical maximum performance might not be achieved in a practical program, but that is true of ALL vector machines including the FPS-164. The latest ad gives a real-world example of only five times the performance of a VAX with an FPA-780 floating point accelerator - and that is only four times faster than a DTACK/16081 combination!

Please understand, we aren't trying to run FPS out of business. What we are saying is that the 68000/16081 is a very cost-effective combination for linear algebra and matrix type operations. It is more cost-effective than a 16032/16081 coprocessor combo because the coprocessing configuration allows only one math chip per microprocessor. It is more cost effective than a 16032 with two math chips connected as peripherals because the 16032 is a 6MHz part and the 68000 runs at 12 or 12.5MHz. It is more cost effective than an Intel coprocessing system because the Intel system is very awkward working across 64K memory boundaries and because the Intel combo is simply SLOW when performing linear algebra or matrix-type operations - about 1/40 to 1/60 megaflop at 5MHz, and that's with an 8086 (the IBM PC is slower yet with its 8-bit data bus).

Let's speculate a bit: say, the 16081 goes into volume production and drops to $120/100 (it could drop as low

Page 26, Column 1

as $40-$60/100, being a fairly small and simple part). Take a megabyte Grande and attach eight half-megabyte 68000s, each with FOUR 16081s. Each of those eight boards would run about $2500 for a total of $20,000 plus more for the megabyte Grande and the host processor. Say, $26K to $28K total. What we have is a total of five megabytes of DRAM, not counting whatever memory the host has, plus 32 (thirty-two) math chips. That's two megaflops, or EIGHT TIMES THE PERFORMANCE OF A VAX-780 WITH THE FPA-780 SUPERCHARGER! And that VAX starts at $235,000.

A four-board system would cost $10,000 less and still have four times the performance of the VAX. This is the kind of arithmetic that can give the president of the second largest U.S. computer company (DEC) ulcers. Or haven't you noticed DEC scrambling hard to get into personal computers, followed by NCR, Sperry, etc?

The 16081 is built on HIGHLY automated production lines. The FPA-780 and FPS-164, by comparison, are practically hand-built. The automated production lines are going to win. (To those readers who are yawning while reading this: read up on what Gene Ahmdahl is up to these days at Trilogy!)

OOPS! DEPT:

When calculating the log base 10, we need as one of the stored constants the value of the log to the base 10 of 2. To the nearest 21 decimal places, that is:

  .301029995663981195214

See those three nines in a row? When we keyed that value into a modified HAYDEN double precision program a year ago, we accidentally keyed in FOUR nines in a row. The stored constants published in issues #16 and #26 are therefore wrong. In issue #16, page 18, line 171 should be:

   DC.L $9A84FBD0

and in issue #26, page 28, line 276 should be:

   DC.L $79FF509F

A CASE! IT'S COMING!

We have a case design now which is aesthetically pleasing if not small. It needs a bit of fine tuning to get better structural strength in two of the three axes, but nobody's perfect. Since we are not getting around to finishing that up for some reason, we have turned the job over to our young project engineer. Which means we really will have a case before lots more time elapses, and (perhaps) a power supply, too.

Page 26, Column 2

JUDGE CRATER FOUND!

Well, not judge Crater but a modern 6502 with 16-bit attributes. Whoopie. Four years ago, three even, that would have been exciting. Well, at least we can explain some rumors, and clarify an item in Dec '83 BYTE's MICROBYTES (p.7):

The Western Digital Design Center, which designs chips but (sorry, BYTE) has no production facilities whatever, has extended the 6502 design considerably. Their new chip, which they call the W65SC816 - isn't that a cute model number? - features 24 bit addressing, 16 bit (high and low half) X, Y and accumulator registers and an ADDITIONAL 16 bit "Direct register". You don't suppose somebody peeked at the 6809, do you?

The Western Digital Design Center, which designs chips but (sorry, BYTE) has no production facilities whatever, has extended the 6502 design considerably. Their new chip, which they call the W65SC816 - isn't that a cute model number? - features 24 bit addressing, 16 bit (high and low half) X, Y and accumulator registers and an ADDITIONAL 16 bit "Direct register". You don't suppose somebody peeked at the 6809, do you?

The new chip is pin-compatible with the 6502, which means the extra 8 address bits are obviously multiplexed, probably on the data lines during the first half of the clock cycle. The bad news is that the extra addresses are "bank selected", even if the "bank register" is internal. Not only that, but there is no overlap from one bank to the next like the 8086/8. So what we have is 256 independent 64K address spaces. There are, however, separate bank registers for the program and for data (the data bank register extends the effective addressing of both the X and Y registers to 24 bits).

The chip has an emulation mode which turns the device into an exact match for the 6502 - same op codes, same number of instruction cycles, etc. Initial production will be by GTE. Price is expected to be $20/100 pieces. (Electronic Design, 24 Nov '93 pp39-40.)

This explains the rumors coming from Apple and Commodore. Except for the emulation mode and pin-compatibility with the 6502, the device is CONSIDERABLY inferior to the 68008, which retains linear addressing over a one megabyte range and has the same register set and instruction set as the 68000. The 68008 price is now $31/100 and dropping.

Western Digital is planning to make an obviously non-compatible (with the 6502) version with a real 16-bit data bus. WHY, we can't figure out. Haven't they heard of the 68000 ($43/100)? Or the Z8000? Or...

DEPT. OF TRUE FACTS:

In Dec '83 PC WORLD, on page 256 we learn how to install an 8087 in a PC. You will naturally "Avoid wearing polyester clothing, but make sure to wear rubber-soled shoes. ...Make sure you are well grounded by wrapping some wire around your wrist and securing the end of the wire to a pipe or to a doorknob." To a DOORKNOB?

Page 27, Column 1

Thus, we have a new addition to the pantheon of Truth: right after "The check is in the mail" and "I'm only resting my hand on your knee, my dear" we have "Doorknobs make good grounds".

(We almost didn't believe that one when Bob P. read it to us over the phone.)

But when the same author later asserts that the installation instructions direct one to first install the chip in the socket and then to remove it to discover whether installation caused any pins to be bent over, he is telling the truth. It seems there are some REAL SMART folks out there in PC land.

TRUTH IN ADVERTISING:

THE STAR OF THE '81 COMDEX SHOW was the Fortune 32:16 (Feb '82 BYTE, p.6). The stars of the '82 COMDEX show were the Compaq PC clone, the Epson QX-10 VALDOCS system, and the Heath robot (Jan '83 BYTE, p.6). We will not have to wait to discover the star of the '83 COMDEX show because INTERTEC has thoughtfully informed us that THEIR new product was the star, in an ad prepared at least six months in advance of the show (we read that ad in Dec '83 BYTE, on p.13, about 1 1/2 hours before COMDEX opened on Monday, 28 Nov). It's awfully nice of Intertec not to make us wait for the Jan or Feb BYTE to find out who the star was, and we trust their new computer will do as well as Fortune's 32:16. After all, it uses a... um, the ad doesn't say what CPU is used. In fact, it doesn't give ANY information about the computer at all. But it's a pretty picture, isn't it? (We haven't the heart to tell them the socks are supposed to be black.)

QUICKIES:

DOES EVERYBODY REMEMBER THAT IBM originally introduced the PC as a 16K machine with (bug-ridden) BASIC in ROM and a cassette interface, to compete with the Apple II? That the initial surge of sales for the PC were for ignorant (not stupid, ignorant) businessmen so they could brag about owning their own IBM computer? That the second surge of sales, which began before the first stopped, was caused by less-ignorant businessmen discovering, "Hey! This here little toy is USEFUL"

So will everyone remember that the PCjr is IBM's second, not first, attempt to shoot down the Apple II?

NO COMPUTER LIVES FOREVER, not even the Apple II. We were until very recently under the impression that Mackintosh was the intended successor to the venerable Apple II. But now that Scully has announced that Mack is NOT intended to be a home computer, it appears we were wrong. Question: were we wrong from the very beginning, or has Mack's corporate "mission" changed?

Page 27, Column 2

WE HAVE BEEN TOLD THAT if IBM offered a warm, steaming platter of, um, used food for sale that a number of people would buy it. The consensus appears to be that Peanut is just such an offering, closely followed by the PCjr. Kindly Uncle Jack actually applauded when he heard the details about Peanut! IBM is serving up another warm, steaming platter called Popcorn. Popcorn uses an 80186 and is solely and specifically designed to support several users. That means that PERSONS will not buy Popcorns, DP MANAGERS will buy Popcorns.

IBM apparently has not noticed the ratio of computers bought by individuals versus the number bought by DP managers lately. Not to worry, if you want to buy a higher-performance PC you can get one from Tandy. Tandy (NOT Radio Shack) has just introduced the Trash 80 Model 2000 (What? Not 2001?) using an Intel 80186. Not an 80188, an 80186 with a genuine 16-bit data bus.

Tandy claims this model is over twice as fast as the PC, for 25% less money. All of us are going to need a three-piece-suit computer eventually to run all that good three-piece-suit software that is becoming available. The 2000 looks good at first glimpse. It would be nice if Tandy were to toss a little sand in IBM's gears, at a time when the only machine IBM could fight back with is a multi-user machine that no rational person would touch with a 3.048-meter pole.

We will probably buy a 2000 to play with if Intel can ever get the 80186 mask done right - redesign has followed redesign, interminably and with no end in sight at this time. After all, that higher-performance MS-DOS machine will need math chip support, right? At 8MHz, we will have a blue moon before they get a workable 80187. You don't suppose that a Nat Semi 16081 could be hooked up, do you? (We DO know that honey dippers can be hired, for a price.)

IN THE SAME ISSUE OF INFOWORLD John Dvorak apologizes to Bill Gates for lending credence to our story that Microsoft is responsible for using those reserved vectors, John Markoff quotes Intel's David House as saying Microsoft used those vectors. Bill Gates, meet David House. David, this is Bill.

It is amazing how ready some folks are to swallow the official Microsoft line. This is the way it is, fellows: The official Microsoft line asserts that the vector conflict is in the IBM bios, NOT MS-DOS itself. So how can David House, who is in a position to know the facts, assert that Microsoft used those vectors? Well, uh, just who do you think WROTE that bios? Paul Lutus? Tinkerbelle? The Sugar Plum Fairy?

Oh, yes: another part of the official Microsoft line is that the mask re-design which is now in progress is due to a bug in the divide code. The story in

Page 28, Column 1

Electronic News, Oct 17, page 24 asserts that the mask is being re-done due to a problem with MS-DOS. Electronic News is the most reliable source in the electronics industry. A divide bug is a GENERAL bug, not specific to MS-DOS. (We know what the official Microsoft line is because Chris Larsen called us, too.)

WE REOPENED THE HLL DEBATE for the simple reason that about 60% of our correspondence - and we get a lot of correspondence - is on the subject of HLL. Opinions seem about evenly divided on the two sides, which is surprising. This journal is NOT a general-interest publication, but has from the start been aimed at individuals who are interested in what was, in 1981, the highest performance microprocessor around: the 8MHz 68000. Because our readership SHOULD be heavily biased in the performance direction, it amazes us how many of our readers will voluntarily sacrifice the performance of their computer on the altar of the great god HLL and its consort compatibility.

Have some subversives snuck into our high-performance tent? What's going on?

MANY OF YOU KNOW THAT Victor owes Tandon $12 million for floppy drives, and has owed that sum for a lot of months now. Tandon has officially and legally written off that $12 million as a bad debt, reducing its corporate fourth-quarter earnings from $10+ million to a loss of $1+ million. While they have not yet filed suit against Victor, an event which would surely precipitate Chapter 11 filing (voluntary bankruptcy), we do not see how they can fail to do so eventually. For one thing, the IRS is unlikely to allow Tandon to write that sum off without an attempt to collect. This may mean that it will require more time for Victor to become the third or fourth largest computer firm in the world.

WE HAVE BEEN TOLD that the reason there are no national magazines supporting LISA or FORTUNE or the Tandy16/XENIX or the 2MIPS Sage is that there is not a sufficient installed base to support a magazine. (Translation: they ain't sold many computers.) Further, we are told it is the relatively high price of those machines which inhibits their sales, NOT their low performance due to HLL op sys & BASIC. It is therefore with great interest that we read the very FIRST sentence of Sol Libes' column in the PC Tech Journal, Vol 1 #3, p.14: "This year IBM is expected to make and sell upwards of 800,000 PC/XT machines." Hmmm.

INFOWORLD'S JOHN DVORAK recently wrote, "There is some fear that UNIX is turning into a negative feature to everyone except those in the programming community." The next issue of INFOWORLD, Doug Clapp wrote, "BYTE magazine seems to think that secretaries will learn

Page 28, Column 2

UNIX, a mirthful notion." Dec BYTE features a couple of letters highly critical of UNIX. Do we hear the thumps and clatter of lots of folks jumping off the mass-market UNIX bandwagon?

DECADENT DEC has figured out, accurately, that unless the company can establish a foot-hold in the personal computer marketplace, its future is bleak. Accordingly, it has established four task forces internally to find out what the problems are in that area. HINT: if one buys a VIC-20 for $87, one turns on the power switch and has BASIC and even a screen editor sitting there on line. If one buys a DEC personal computer, BASIC is a $250 component to be purchased separately. DEC even expected that the series 300 - we are not kidding you, now - would be the LARGEST selling model of the three it offers. The series 300 is the one WHICH DOES NOT HAVE A DOS AVAILABLE

DEC's biggest problem is related to the fact that it needs four internal task forces to find out why their personal computers are not selling well. We, and almost all of our readers, could give them EXACT reasons given a price list of all the "optional" accessories.

YOU WILL SEND US MONEY:

Most of your subscriptions expire with issue #28, and this is #27 already. How can you possibly do without this scholarly, sedate, scurrilous rag? (If you do not know when your subscription expires, look for a number on the mailing label. If it is 28, then #28 is the last issue you will receive.)

PERMISSION TO COPY:

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

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, II+, IIe, soft, SOS, ProDOS, LISA: Apple Computer Co. Anybody else need a 170th million ack, have your legal beagles send us the usual threatening note.

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 MONTH'S REDLANDS comes disguised as several missing pages. Maybe next issue we can do better?