DTACK GROUNDED #21
July 1983

DTACK GROUNDED, The Journal of Simple 68000 Systems
Issue # 21 July 1983 Copyright Digital Acoustics, Inc

OOPS!

We were supposed to have a photo of a very high resolution graphics board on this front cover but it was either publish on time without the photo or wait, and we decided publish on time. The photo will appear next issue, honest! Contributing to the decision was the fact that we have significant contributions this issue from three of our readers, so we really don't have room to describe the board(s) anyhow. But you will find pricing for the Grande towards the back of this issue. A preview: the full gallon costs $1995. Since we don't have any hi-tech stuff for the front page of this issue, how about

THIS MONTH'S FARM REPORT:

Outside a town in Italy lives a farmer who uses a donkey-drawn cart to bring his produce to the town for sale. As it happens, there is a Maserati automobile dealership which he passes weekly as he comes to town. The farmer is prosperous, the donkey cart is his only vehicle, and Maseratis are very good looking automobiles, especially when compared to a donkey cart. Knowing of the farmer's prosperity, there is a persistent salesan who keeps after that prospect...

"Luigi, why don't you get rid of that donkey cart and join the modern world?" asks the salesman, having become friendly with the farmer.

"Get rid of my faithful donkey and cart? Why, they have given faithful service for five years now" replied the farmer. "That bright red Maserati convertible sure looks good, though. When you can show me how I can use both, I might buy it."

Page 1, Column 2

"A sensible person who owns a Maserati would immediately retire his donkey and cart, except on those occasions when he needed to haul a load of," - here the salesman glanced at the cart - "leeks and garlic?"

"Look, my donkey cart can travel at ten kilometers per hour, especially when it is near feeding time and we are headed in the direction of the barn. The donkey cart is obviously a valuable resource which I must continue to make use of" the farmer pointed out.

"This Maserati can easily travel twenty times faster" the salesman replied, with an indignant sniff. "Luigi, just buy the thing and park that cart."

"No, I must use both. Perhaps if I drove them side by side, and stood with one foot in each vehicle?" the farmer speculated.

"Ridiculous!" the salesman ejaculated.

"I know! I will drive the Maserati a short distance, and then run back and drive the donkey cart an equal distance. Then I will drive the Maserati another short distance, and progress in this fashion. If I drive each a sufficiently small distance before switching, it will seem almost exactly as if I am using both vehicles simultaneously. Using both vehicles simultaneously is highly desirable, of course" the farmer pointed out reasonably.

"Luigi, you are incorrigable!" the salesman sighed as the farmer drove off with his load of leeks and garlic.

What's that you say, dear reader? Is your FNE stating that you are like that farmer with the donkey cart, just because you think that using your Apple and the 68000 at the same time is a marvelous idea? No, we would never assert that you were like the farmer.

Following is a story which was written by 'Adam Smith' - we think. We will make a deal with you: If you like the story 'Adam' gets the credit and if you don't like it we will take the blame.

(continued on page 7, col 2)

oops

OUR LATEST PRODUCT RELEASE

Page 2, Column 1

BOASTING DEPT:

We have not been hesitant in the past to admit the (usually obvious) mistakes we have made. Here we are going to reverse this procedure and point out some of our (brilliant, naturally) successes.

Nearly two years ago, in newsletter #4, we carefully explained that the brand new high-performance 16 bit micro being introduced by T.I., the 99000, was not a microprocessor at all. It was a process controller instead. T.I. did bring that thing out and it fell flat on its face. Electronic News (EN) has just printed two full pages explaining the history of this device and patiently explaining why it failed. We beat them to it in these pages by 20 months.

We immediately followed the 99000 story back in issue #4 (beginning on the bottom of page 13) with a prediction that the National 16032, which at that time was supposedly to be imminently available, would be late in delivery. Well, nearly two years later the 10MHz 16032 with no bug list still has not arrived.

Let's move all the way up to newsletter #6, dated Jan '82. Beginning on page 4, we warned our readers that all was not as it should be with the Intel 432. We were about four months in advance of any other publication, including EN, that there were any problems with the iAPX432. We were also the first to conclude that the problems were so severe that the product would inevitably be a complete failure in the commercial marketplace. We 'buried' the 432 on the last page of issue #10, June '82. See the first classified ad on the back page.

Have you read anything good about the 432 lately?

Also in that June '82 issue, on page 2, we told you (warned you?) about Unix. Since that time, the general micro industry trade publications have begun to trumpet the impending domination of the high end of the personal computer marketplace by Unix. What they obviously do not realize is exactly how high up that 'high end' is. We have tried very hard to counter that nonsense in these pages so that you, dear reader, will not be hoodwinked.

Only recently have we sensed a small beginning of an awareness that all is not well with Unix in the low-end market. Low end means under $20,000. First, a single sentence in BYTE (which we reported). Then two articles in successive weeks in EN about performance and sales problems at Fortune Systems. We predict that by this fall the leading micro publications will start to print articles about why Unix is not a good idea in a cheap microcomputer. These articles will be remarkably similar to what we have been publishing here

Page 2, Column 2

for over a year now.

However, those articles will (most likely) focus on only one of the two reasons why Unix is not a good idea in the mass marketplace. The other reason is that Unix is simply too complex for the average person. Anything which is going to be a success in the mass marketplace must be suitable for the average person. Read, for instance, page 3 in issue #10.

There is a reason why we have pointed out those past successes (aside from the fact that we like to boast). It has just become apparent that next year, 1984, will be the most eventful year ever for personal computing. Some of the things we are going to discuss now are already apparent, such as the obvious start of a shakeout in low-end personal computing (the rock- shooting division). But we will include one, highly specific, prediction that nobody has gotten around to yet.

GAUL IS THRICE DIVIDED:

1984 will complete the division of the personal computer industry into three totally separate and distinct elements. There will be the rock-shooting division, the three-piece-suit business division, and the performance freaks.

THE ROCK-SHOOTING DIVISION:

The shake-out in this division has already begun, so this doesn't count as a prediction. So we will instead predict that Commodore and Sinclair (Timex in the U.S.) are going to win, and explain why.

Prices for rock-shooting computers are under $100 and it is tough to pay workers in the U.S. a living wage to build computers which sell at that price. That's why Atari is abandoning efforts to build computers in this country and is moving its production to the far east. And that is why Atari is not going to be one of the winners; moving production to the far east was the correct strategy 3 or 4 years ago. The correct strategy today is a fully automated production line, and Timex and Commodore are the only rock-shooting computer builders who are going that route.

The rock-shooting division also requires up-to-date sound generators and video graphics control chips. Commodore and T.I. are best situated in this area. The reason we aren't including T.I. among the eventual winners is that they will be too late to perceive the virtues of automation. You do remember that it was Timex, not T.I., that won the digital watch battle, don't you? Timex won with fully automated production lines, not cheap far east labor.

Page 3, Column 1

THE 3-PIECE-SUIT DIVISION:

This division includes all those folks running VisiCalc on an Apple II as well as the IBM PC folks and all their camp followers. Even here, the shakeout has already begun. If you have been watching Vector Graphics, you will know what we mean. Next year is the year that this division will be utterly and completely transformed. The landscape will be littered with corporate corpses, and there will be precious few survivors.

What's that? You say people have been predicting that for years now? That 100 different computer companies cannot be sustained, just as the auto industry in this country couldn't sustain the 100 companies it once had? Look, we know all that. What we are going to do is give you the name, rank and serial number of the personage which will precipitate the holocaust. That counts as a prediction.

It's the Intel 80186. Not the 80286, the 80186.

The '186' is going to turn the three-piece-suit division on its head not for a single reason but for a variety of reasons. The first reason is that the 186 can run 8080 code, just like the 8086/8. But, unlike the 8086/8, the 186 can run 8080 code faster than an 8080. Noticeably faster, so that manufacturers offering personal computers using the 186 will be able to (correctly) claim a performance advantage over the IBM PC and its clones.

Since there are many companies or entrepreneurs who will perceive an opening here, lots of companies will shortly be making 186-based computers to compete with the IBM PC.

The second reason is that the 186 is highly integrated. Intel's Bob Noyce has publicly expressed uncertainty about what the heck a chip-maker can do with lots of transistors on one chip besides make big memories. Up to now nobody else at Intel has been able to figure that out either, judging by the iAPX 432 disaster and the '286', which is a superb weapon pointed 90 degrees from any desirable target. (But sometimes you get lucky. The 8087 is a product which is an incidental fallout of the 432 debacle. If the 8087 will not eventually win out over the 16081 and the 68881, it is it least first and it does work.)

But with the 186, which is not a state-of-the-art chip as far as the number of transistors on the chip is concerned, Intel (accidentally?) has produced a product which is a superb match for a very large market.

Look: the 186 includes, on the same small, low-cost chip a lot of features that used to require a lot of

Page 3, Column 2

extra chips at a lot of extra cost, like DMA for instance. This means that lots of bells and whistles which are either missing on low-cost computers or included on high-cost computers will now be found on low-cost 186-based computers. That is the second reason for building a 186-based computer: high-priced features at a low cost.

The third reason why lots of 186-based computers are going to be built is that Intel his already done all the hard work of designing a (moderately) complex computer system and have incorporated that design into a single (inexpensive, remember) chip. This means that anybody who wants to build a 186-based system can. The design work is already done.

So, we have three reasons for building lots of 186- based systems: a perceived performance edge over the IBM PC, cheap features that used to be expensive, and the ease of producing a product. These three reasons will reinforce each other to the extent there will be at least 50 companies, maybe a hundred and, perhaps, 200 (internationally) offering 186-based computers.

Let us switch our focus from the supplier' end to the user end. There will be millions of 186-based computers purchased because they will be cheap and have higher performance than the Z80 and 8088 based computers which now dominate the three-piece-suit computer division. And, they will be able to run all the 8080 software and all the software being developed for the IBM PC. There may be tens of millions of 186- based computers sold world-wide. So all those suppliers are going to get rich, right?

Wrong, of course.

Let us select two 186-based computers from two different suppliers selected at random from amongst all those suppliers. Set them side by side. What do we see? We see two computers that can both run the same software base. They both run faster than a Z80 or 8088. They both have the same high-performance features at low cost. In fact, the one is exactly like the other except for the small nameplate or logo an the front panel!

(You do understand that any company trying to outperform the IBM PC will inevitably produce a computer which is indistinguishable in appearance from the PC, don't you?)

Who is going to buy those millions or tens of millions of 186-based computers? You will! 1984 will be the year which marks the start of the two-computer family (not counting rock-shooting stuff). You will buy one to gain access to lots of useful software that won't

Page 4, Column 1

run on the other computer you own. You will keep that other computer because you have lots of useful software for it which won't run on an Intel-based system and also (maybe) for another reason to be discussed later.

O.K., it's 1984. Let's you and us drive to your nearest personal computer outlet and buy a 186-based computer. Surprise! There are many brands! Which one do we select? They are all identical, no? Why, we either buy the cheapest or the one with the IBM logo!

All those computers are going to be about as dissimilar as the Ford, Chevy and Plymouth before the oil crisis became generally apparent. But there are only three car companies mentioned in that last sentence. There will be a myriad making 186-based computers.

So what's going to happen? C'mon, you know that as well as we do. What is going to happen is going to be a blood-bath of price-cutting which is going to leave only a few survivors, who will be the Ford, Chevy and Plymouth of the personal computer industry. That's where all those bodies lying around the landscape that we mentioned earlier are going to come from.

Unnoticed in all the excitement will be the demise of all the companies whose fortunes depend upon the Z80 or the 8088, because people will have the option of a cheaper, higher performance computer which is software- compatible. Did you notice the word 'cheaper' in that last sentence? Yes, we mean cheaper than the extant business-type Z80 or 8088-based computers. Again, this should be obvious.

When the blood-letting starts the three survivors will be the ones with fully automated factories. The ones using American labor will go under first, then the ones using far east labor. The situation is identical to the rock-shooting division. The reason this became evident first in the rock-shooting division is that it was the first to achieve sales of one million computers per year by a single manufacturer. The Big Three who emerge from the 186 war will each make much more than a million computers a year. In fully automated factories. That lady in Arab, Alabama may have to go back to plucking chicken asses coming down the line at 100 miles an hour.

Automated production of millions of units per year means that every manufacturer who now builds Z80 or 8088 products using hand labor is going to vanish. The smart ones will get out now.

We trust it is evident to the reader that lower prices will mean higher sales which will lead to even further price reductions due to economics of scale which will lead to... You disagree? Then how come you can buy a Z80-based Timex for $45 right now, today? Hmmm?

Page 4, Column 2

The folks making marketing forecasts for sales of business computers two or three years down the road are vastly underestimating the number which will actually be sold because they have not taken into account the economic effect of automation. Those same forecasters blew the prediction of sales for rock-shooting computers last year for the same reason.

So you are going to have your choice of rock-shooting computers or a 186 based Ford, Chevy or Plymouth? No, remember that Gaul was divided into three parts.

THE HIGH PERFORMANCE CROWD:

Remember that Ferrari and Mercedes are still in business and that both of them manufacture their cars using hand labor. Digital Acoustics is going to remain in business selling exactly what it sells now: Ferraris. (Maybe Cosworth-Ford engines would be a better analogy?)

You see, the 186 is a high performance part only when you compare it to the Z80 or 8088. There will continue to be lots of folks building computers using the 68000 family and even the Intel 80286. The '286' can run circles around the 186, or at least it will once Intel produces it. As we pointed out in issue #15, beginning on page 10, the 286 will have performance which is directly comparable to the 68000 once Intel gets it up and running at full clock speed. Comparable in speed but organized in a very different fashion, as we pointed out. (If you don't remember how different, go back and review the 2 1/4 pages on the subject.)

How does this affect you? Well, it means that you should buy, not build, a 186-based systems. Unless you plan to build a fully-automated factory.

Most of our readers own computer equipment made by Apple or Commodore. Now will this affect those companies? Well, Commodore will become the Commodore of the rock-shooting division. They already are. What will become of Apple? Now that, gentlepersons, is a downright interesting question. One we don't have the answer for. We can predict that LISA will crash and burn if Apple doesn't re-write all that Pascal software in assembly language. Or haven't you heard that LISA doesn't show much swift in its present form?

Yes, we know that LISA uses Pascal compiled into native code, not P-code. But Pascal native code is a lot slower than assembly code. What is going to happen to the 68000-based computer manufacturers who continue to rely on interpreted P-code is too awful to contemplate! And now you know why we are keeping HALGOL as close to assembly code as possible.

Sweet dreams!

Page 5, Column 1

PLAGIARISM DEPARTMENT:

On Friday, May 20 we sent newsletter #20 to the printers. The next morning we got up at 3AM and wrote the preceding three pages. After having breakfast and reading the morning paper, we drove to work. Just two of us hardware types work on Saturdays at Digital Acoustics, in case you were wondering. When the mail arrived at noon, Electrical Engineering Times arrived with it. We always jump on that industry newspaper and its counterpart Electronic News as soon as they arrive because they print what is happening now while BYTE, for instance, prints what happened six months ago.

So we immediately noticed the headline "PC Shakeout Looming" on page 52. That headline was over a short article, only four column inches long. It seems that the Arthur D. Little company is predicting that only one of five or six current manufacturers of personal computers will be in business by 1987.

Since the other hardware type at work had read the draft copy of those last three pages, we naturally called the EET article to his attention. His immediate comment was, "You'll have to change (the last 3 pages) now, won't you?" We explained that it was very common to read elsewhere things very similar to what we write. On this very same page is a longer article, 12 column inches, headlined "Experts Differ On Japan's Robotics Lead."

This is being written the following day. On the front page of the L.A. Times' business section we find an article on Japanese business which includes the following: "Yamazaki Machinery Works... has been operating one of the most advanced manufacturing facilities in the world since 1981, using a round-the- clock 17-man automated factory to outproduce more conventional operations dependent on nearly 300 workers."

Getting back to page 52 of EET (dated May 16/23) there was also in earnings report on 13 companies, including T.I. and Commodore. The latest quarterly sales for T.I. was $1.174 billion, with virtually no profit. T.I.'s sales for the same quarter the previous year was $1.078 billion. Commodore's latest quarter sales were $189 million, with sales the same quarter last year of $82 million. Conclusion: Commodore is growing much faster than T.I! (Candidate for understatement of the year.)

Those figures show Commodore growing at 130% per year. IBM is growing about 13% per year these days (the entire corporation, not their PC division). H.P. is growing at 19% per year, based an their most recent quarter. Guess which company has a fully automated factory among the three companies in this paragraph?

Page 5, Column 2

Oh, yes: Commodore showed a profit margin of 13.2% on those sales.

You are not going to believe this, but on that same page there is a fourth item (maybe you aughta read EET?), this one bar graphs prepared by Enlon Associates, showing the market shares in 1982 by unit and also by dollar volume, followed by similar graphs predicting unit and dollar market shares in 1985. Enlon is a consulting firm in Los Gatos, CA. Enlon thinks Commodore's market share will double, dollar- wise, in that time. Since they also predict the entire market will increase from $3.7 billion to $9.7 billion in that same period, they are predicting that Comoodore's sales will increase 5 1/4 times in that three year period.

We think Commodore will grow faster than that. If they sustain a growth factor of 2.3 per year, over a three year period that is a growth factor of twelve, not 5.25. With more automated factories coming on line, Commodore may do even better than a factor of 12!

You may by now be getting a small glimmering of why we think fully automated factories will be important to mass-market manufacturers in this industry. Full automation has not yet arrived in the manufacturing of the three-piece-suit variety of personal computer but it inevitably will!

THE MASS SOFTWARE MARKET:

The existence of millions or tens of millions of software-compatible computers is going to utterly transform the software industry. All of us are already aware that software will then be sold pretty much the way books are now. That will pretty such kill the piracy problem, at least for programs with mass appeal (when was the last time you photocopied a book?). But there are a couple of other matters to consider:

There are hundreds of millions of people who can speak English. Many of them can and do read. Therefore, the potential market for a well-written, entertaining novel is enormous (e,g, Jonathon Livingston Seagull). The competition is intense. John D. McDonald, Herman Wouk, Tom Wolfe are examples of some pretty darn competent writers. Similarly, only the very best writers will be able to succeed in the future mass software marketplace. Which means that the vast majority of the Computer Science types graduating from college these days will inevitably wind up as GS-9s coding ADA for the Army.

The reason for this is that the mass marketplace will not tolerate inefficient programs and inefficient

Page 6, Column 1

progress are the only kind favored by the Computer Science folks. We refer to Ada and transportable interpreted P-code, of course. Persons asserting that a program written for an installed base of ten million software-compatible computers has to be portable will be laughed at.

For the third straight issue we call your attention to the battle between Context/MBA and Lotus/1-2-3, where MBA has the enormous advantage of portability and poor little 1-2-3 (sniff) isn't portable at all. Softalk (PC edition) keeps informing us how this contest is going and friends, lions vs. Christians was a more even fight! The fast assembly language is eating that transportable P-code alive!

Isn't it evident to everyone that assembly language is the software equivalent of fully automated hardware factories? In each case we have the maximum available efficiency. Who needs extra overhead, whether time or personnel?

Let's be reasonable, folks: do you think that ten- million-installed-base marketplace is going to tolerate inefficient programs?

Inefficient languages such as BASIC, Pascal, and ADA will be used only for personal programming or the Army, in Ada's case. Pascal may be retired to the area it was written for in the first place: teaching programming,

We are fully aware that the fifteen Pascal programmers who read this newsletter will regard our assertions with great disfavor. But the devastating success of 1- 2-3 in crushing MBA has put the handwriting on the wall; you will ignore it at your ovn risk! We suggest that you go back and read the end of the first page of issue #16 again.

Unfortunately for Carl Helmers, the fact is that the (68000) chip is not "so fast you don't notice." 1-2-3, running on an 8088, is about 12 times faster than (transportable) MBA running on a good 68000 machine, the HP 200 model 16. Have all of you figured out which company Jerry and Carl were talking about? No? Why not ask the recently fired former engineering V.P. of Fortune Systems?

This is being written on Monday the 23rd of May. Today's Electronic News carried a long article about the lead times for IBM PCs going out to 6 months or more. Since many people won't wait that long, the PC clone made by Compaq is selling as fast as Compaq can make them. This part you will not believe: there is even a severe shortage of DOS 2.0 software. Desperate

Page 6, Column 2

dealers are (highly illegally) copying the disks so their customers will be able to turn on their computers!

It is our understanding that IBM is currently producing 25,000 computers a month. Clearly, that isn't nearly enough! This shortage, which is causing the Compaq to be fabulously successful as they 'ramp up' production, is going to act like blood in the water to sharks. The venture capitalists and the entrepreneurs are going to be drawn irresistibly to this market. When they look over the situation it will be obvious to them that the time is ripe for a 80186-based machine.

And that, friends, is why we are predicting that so many companies are going to enter this market.

The funny thing is, IBM is doing it to themselves by not producing enough computers to fulfill the needs of the marketplace, which causes the clones to be temporarily successful. The reason IBM can't produce enough computers is that their management is not accustomed to responding rapidly to changes in the marketplace. Also, IBM does not own those production lines in Arab, Alabama where the PCs are being produced. They contract with independent suppliers to produce, under contract, X units per month. The vendor in turn schedules parts, builds production lines, and hires chicken pluckers in the exact numbers necessary to fulfill the contract.

If IBM cannot learn to respond quickly in a marketplace where quick response is absolutely essential, then IBM may not be one of the survivors in the personal computer marketplace. Customers will put up with almost anything in this personal computer racket, but they absolutely will not put up with a vendor who can't build enough product. You do understand that the shakeout predicted by Arthur D. Little can't happen if the biggies can't produce enough product, don't you?

And while the biggies can't produce, the sharks continue to gather.

HOW DOES THIS APPLY TO YOU?

Well, if you do not program, and you can wait two or three years, you are going to be able to buy a very good, very cheap three-piece-suit type computer. It might run under $1000 with 128K and two single-sided floppies, about 300 to 400K capacity each. The economies of mass production is going to pull other computer prices down as well; Lisa or something equivalent to Lisa in memory size, etc, might go for $3000 three years from now.

But if you do program, the scenario changes dramatically. If you are going to do assembly language

Page 7, Column 1

programming on the 8086/8 or the 186 or 286, you are going to have to learn that wonderful Intel assembly language. Friends, the 6502 looks marvelous compared to the Intel lineup, and the 6502 is at least four times less easy to program than the 68000!

Let us make an analogy: programming the Intel line in assembly language is like cleaning out a cesspool (you prefer 'septic tank'?). You can do it if you set your mind to it, but is this really what you want?

MALIBU BEACH BIKINIS:

Back in the 1950s and 60s there were a series of movies made, all with the name "Malibu Beach Blanket Picnic". The young men who saw those movies back then are now old, fat and rich. The thing is, there were cute young girls in bikinis an Malibu Beach back then (the reader is advised that we have some expertise in this matter) and there are even cuter young girls in even briefer bikinis on Malibu Beach today.

This presents a marvelous opportunity to those who would like to build resort-type hotels on Malibu Beach or maybe even 200 yards back on the other side of Pacific Coast Highway. There is this one problem: every hotel room has a john in it and every john gets used regularly. So there must be a sewer for the Hotel to hook into. There are no sewers in Malibu Beach.

There are no sewers in Malibu Beach because the folks there like their lifestyle as it is, thank you. So every year a bond issue for a sewer system gets put on the ballot by the real estate developers who want to build those resort hotels and every year the bond issue gets voted down by a huge margin. We can't tell you about the judges involved in this and the, er, peculiar rulings which have attempted to force the residents to accept a sewer system because we might get tossed into the pokey.

Fortunately for the residents of Malibu, state law is unquestionably clear that a bond issue must be approved by a vote of the people. And a sewer system is much too expensive to be installed by private interests. Which means the developers are asking the voters to pay, themselves, for ruining their own lifestyle.

In the meantime, there is this one consequence: there is one cesspool (all right, septic tank) per residence. Because the lots on the beach are so small, one does not simply seal the old septic tank and build a new one, the way farmers used to do it. No, one hires a honey dipper. This is not a popular job, and so honey dippers are very well paid indeed.

It is possible to sake a great deal of money honey dipping in the Malibu Beach colony and, as has been

Page 7, Column 2

conclusively proven recently, it is possible to make a great deal of money doing assembly language programming on the Intel microprocessors. We would not want either job. Get an assembly language manual on the 8086, for instance. You will see what we mean.

(The above was written prior to the phone conversation with 'otherwise intelligent', reported elsewhere in this issue.)

(continued from the front page)

Back in 1958 a little old lady walked into the office of her stockbroker and directed his to purchase a sizeable block of shares in a company named Brunswick, which held the patents on automated pin-setters. When the startled stockbroker asked why, she replied "Because I have to stand in line for two hours if I want to go bowling, that's why!"

Brunswick stock climbed all the way to 74. Late in 1961, a year in which Brunswick reported record high earnings per share, the little old lady walked back into her stockbroker's ofice and directed him to sell all of her Brunswick stock. When the again-startled stockbroker asked why, she said "Because I don't have to stand in line to bowl anymore, that's why!'

When we tried to find this story we struck out, but we did find, on page 111 of "The Money Game" (by 'Adam Smith') the earnings per share of Brunswick for the years 1934 thru 1965 inclusive. They went from .11 in 1954 to 2.56 in 1961 to "d4.21" in 1965. We will quote a portion of the following paragraph:

"...that little "d" is for deficit. Brunswick did have a pretty good lock on the pinsetter business, but the bowling boom contained within it the seeds of its own destruction, like all booms. Bowling alleys proliferated like gerbils, and a location that can support one bowling alley supports none when a second one moves in and they divide the business... Brunswick managed to make it from 74 to 8 in one of the steepest dives of recorded history."

A location that can support one bowling alley supports none when a second one moves in? Gosh, we didn't know that. Suppose me try a little 'Adam Smith' imitation:

'68000/Unix systems are proliferating like gerbils.'

No? Try this one: 'Winchester-technology disk manufacturers proliferated like gerbils.'

Well, then, how about this: '80186-based IBM clones are going to proliferate like gerbils.'

Page 8, Column 1

Shortly after mailing issue #4 of this newsletter (you do remember pages 9 and 10, don't you?), a reader wrote and asked, 'are you by any chance a registered investment counselor?'

No, we are not. We did once (in 1969) have a large motivation to study how the stock market works, so we studied (not just read) a book entitled "The Over-the- Counter Securities Markets (a review guide)", Second Edition. This book was then the official textbook for candidates wishing to become a 'registered representative'. Registered by NASD, that is. That stands for the National Association of Securities Dealers. (These days it's 'NASDAQ'). How large was the motivation? Try middle six figures. We have also been personally involved in forming the Articles of Incorporation of two companies.

So what? So that makes us the most qualified, in the corporate-financial area, of all the newsletter writers who write about the Motorola 60000 microprocessor,

UNIX IS A GOOD SYSTEM:

We trust that you understand that there are companies which are profitably building 68000/Unix systems, good ones. We also trust that you understand that they are expensive, and that they are being sold like Rolls Royces, not popcorn. Wasn't it a vice-president of Codata Systems Corp. who wrote a letter to BYTE magazine (Jan '83 p.14) bragging about selling 500 systems in one year? That's less than 50 a month!

If you have about $35,000 you can buy a superb 68000- based Unix system from any one of several vendors. That price is for a fully-equipped single-user multi- tasking system (we don't write about multi-user systems here). Nobody pays that such money for a single-user computer unless they plan to use it at least 8 hours a day, five days a week. Most of us do not use our personal computers that much.

Several companies selling 50 very good Unix systems a month does not add up to 125,000 Unix systems in 1983. In fact, 1983 is half over. Have 62,500 Unix systems been sold since January? Tandy now offers XENIX on its Model 16, if you buy their big, slow disk. Has anyone heard any good words about that system?

THE 286 IS A GOOD MICRO:

As we have told you before, Intel's 80286 processor is a good part with high performance, or at least it will be when the 8MHz version with no bugs enters production sometime next year. It is, however, very different from the 68000. This makes an objective performance comparison difficult at best.

Page 8, Column 2

But to assert, as AMD's tricycle ads do, that the 286 is three times faster than the 68000 is absurd. What we don't understand is why Motorola is letting AMD and Intel get away with those ads. Or haven't you noticed that there has been no response from Motorola? Is it possible that the minicomputer boys have taken over completely? The minicomputer types would probably agree that the 68000 should have a memory management chip attached for multi-user multi-tasking purposes. (Your Porsche should have a bus bolted onto its back.)

Well, we don't agree that the 286 is three times faster than the 68000 or that a memory management chip is needed. We prefer simple, fast systems. On the opposing page is an ad which has been placed by us in the July (appx) issues of Peelings II, Call Apple and Nibble. You will not notice the typo ("286" is missing after "8MHz" at one point). And if you have been reading the recent issues of this newsletter, you will understand why that ad will not appear in Micro.

MISCELLANEAE:

Aaargh! KILL! Somebody has ripped off our copyrighted patented trade secret of tilting the RAMs so that the signal traces run straight across the board! The 'somebody' is named ZEN/TEK. See page 291 of PC WORLD, issue #3.

Leroy L first comes along and points out that our HALGOL expression syntax did not allow exponentiation:

 100 A = B ^ C 

Then Jim F pointed out that we did not allow negation:

 101 D = - D
 102 A = - A 

Then Stewart H. of Stamford, CT (Leroy and Jim are local) pointed out that we were evaluating - and + in the wrong order, pointing out that

 103 A = B - C + D 

Should not be evaluated by adding C and D, and then subtracting the sum from B. But that is what the example we gave did! Stewart has made it clear to us that evaluation must be from left to right for math operators having the same precedence (why didn't more of you catch that?). (Maybe we should just be thankful for the help we do get.)

Well, we really are trying, folks. While we mull these problems, we will provide further discussion of HALGOL syntax elsewhere in this issue.

Page 9, Advertisement

The 68000 DREAM MACHINE

THE DTACK GRANDE:

Above is a photograph of the prototype for the DRAM version of our Apple compatible 68000 board. We have modestly named it the DTACK Grande because it has a Grand(e) amount of memory: a megabyte! That's called a full gallon here in California. (You can buy one with only 128K if you like.) This one has a 25MHz Xtal oscillator which we divide by two to generate the 12.5MHz clock for the 68000. DTACK is not grounded; there is one wait state. Refresh is performed in software, with a hardware assist so that the overhead is exactly the same for a megabyte as for 128K (4%). Thus the effective speed of this board is equivalent to 10MHz with no wait states.

Which makes our one megabyte 68000 exactly twice as fast as another one megabyte 68000 system that you Apple types may have heard of. The other one doesn't work with Apple II's, of course. Ours does.

Because the refresh is interrupt-driven, this board is inherently capable of multi-tasking so all you print spooler and type-ahead buffer fans should love this board. We think it will make a dandy RAMDISK. Oh, yes: it has a big, fast 68000 microprocessor (we almost forgot while we were admiring all that memory!).

TRUTH IN ADVERTISING:

Many of you have seen that ad with the tricycle falling apart which asserts that the iAPX 286 is faster than the 68000. Here are the facts:

1. The board pictured above, with one wait state, can perform a 32 bit add in less than half a microsecond and an 8MHz can't.
2. Intel is currently running ads offering 6MHz 286 boards, projecting delivery of 7.7MHz boards early next year. What 8MHz 286?
3. The 68000 has exactly seventeen more 32-bit registers than the 286. That's because the 286 doesn't have any.
4. Back to that tricycle ad: have you noticed the fine print that says the speed of the 68000 has been "adjusted"?
5. AMD and Intel like to compare against a slow 8MHz 68000, burdened down with a memory management chip for multi-user systems. We are offering 12.5MHz 68000s for single-user applications. BIG difference!
6. The 68000 can linearly and directly address up to 16 megabytes of RAM. The 286 can't. That's important when you have a megabyte of RAM!

However, since we believe in 'truth in advertising' ourselves, that prototype pictured above doesn't work yet. We have not yet programmed the PAL memory decode chips or the bootstrap PROMs. This ad is being written on 23 May '83, so things may have changed by the time you read this.

THE 'STUFFER' BOARD:

In our last ad we told you about a 'block DMA' interface we were developing. The production boards just walked in the door and we will be shipping that interface this month. It works with both the static and the dynamic RAM 68000 boards we make. (However, it was designed before the Apple lIe was available, so it is not compatible with the Ile.)

SOFTWARE:

All the stuff we mentioned in our previous ads is still available. We are well along the road developing HALGOL, a high speed BASIC-like language that runs at close to 68000 assembly language speeds - and that is very fast! Right now we are finishing up the BIOS. That stands for Basic I/O System. It turns the 6502 in the Apple into an I/O handler exclusively, and lets the 68000 take over and run things.

SHOULD YOU BUY OUR BOARD?

Our board is still not suitable for persons who just want to turn on their computer and run canned software. You must have some interest in doing some programming yourself, or you will not want to buy one of our boards.

We still provide lots of 68000 source code on unlocked, easily copyable disks. Three disks with demo programs and source code are shipped with each board.

Aside from that, we can only think of a million reasons why you might like to buy one of the boards pictured above.

DIGITAL ACOUSTICS
1415 E. McFadden, Ste. F
Santa Ana, CA 92705
(714) 835-4884

Apple, Applesoft and Apple II are trademarks of Apple Computer Company.

Page 10, Column 1

Sometimes we goof. About 30 of you have written to us regarding our opinion of virtual memory in an inexpensive personal computer setting. It would appear that the vote is 29 - 2 in favor of virtual memory. Since this is a democracy (right?) we hereby reverse our opinion and declare that a good virtual memory system will appear in an inexpensive personal computer tomorrow. Well, would you believe the day after tomorrow? Maybe next month, then?

You might also be interested to know that the early returns indicate unanimous disagreement with our plan to use as little of the Apple's (purported) intelligence as possible in writing the HALGOL BIOS. This is a dictatorship, all of you are wrong! (Maybe you guessed this from the front page?)

Turn to pg 30 in May 26 '83's Electronic Design. Headline: "Real-time kernal raises Unix performance by orders of magnitude." Story: "...can boost the throughput of 68000-based systems running under Unix by more than 300%."

Orders? Not order, mind you, but orders, plural, of magnitude? Three hundred percent? Well, we were wondering where that Mini-Micro ex-staffer was going to get his next job.

The same issue of ED has a feature on supermicros starting on pg. 97. The author, Carl Warren, condescendingly stoops to include " ... some systems confined to single users and even single tasks (emphasis added).' Thanks a bunch, Carl.

DTACK Grounded somehow got mixed up in Peelings II's April fool issue, which was published in May as usual. See the article on pages 48 and 49. We like the quotation on page 49: "These timings prove that: #1) Nothing beats a 68000..."

We forgot to mention, in our last issue, the marvelous writeup on IBM's "support" for the PC in April Softalk (PC edition). See the story beginning on pg. 119.

We thoroughly enjoyed the issue of EET mentioned earlier in this newsletter. It included a reprise of the two-page tricycle ad by AMD, featuring the performance of the Intel 286, which AMD doesn't make yet. Intel doesn't make it yet either judging by the Intel ad in the same issue which offers to sell you a board with a 6MHz 286 now and projects availability of a 7.7MHz version early next year. Oh, yes: the Intel ad shows the performance of the 8MHz 286 vs. the Motorola Exormacs, running Pascal. Sigh.

Page 10, Column 2

Now, Motorola makes real nice micros but that Exormacs is an 8MHz, 4-wait-state turkey. It is also a fact that Motorola's version of Pascal is lousy, speed-wise. Oregon Software advertises a 68000 Pascal which they (very accurately) assert is twice as fast as Motorola's. If you will factor in, say, a 12.5MHz 68000 with one wait state running Oregon Software's Pascal and take another look at those figures, you will find the 286 looking rather sickly.

If AMD juggles the measured numbers (they admit to doing this in the small print in their ads), why can't we? If we assume a single-user system and either single-tasking or trivial multi-tasking such as print spooling and a keyboard type-ahead buffer, then we can throw out the memory management which is what slows down the 68000 in those comparisons. We freely admit that the 286 is a better multi-user vehicle than the 68000. In fact, we admitted that extensively a few issues back. ('The 286 is a superior vehicle for transporting 32 sheep simultaneously. Are you going to drive the truck or ride in the back?')

Regrettably, Oregon Software wants about $7,000 for a single-CPU license for their Pascal these days. Oh, well, we don't like Pascal anyhow.

Neither does Brian Kernighan. Two of our readers have been nice enough to send us a copy of Brian's paper entitled "Why Pascal is Not My Favorite Programming Language." This is a 16 page document, which begins with the sentence, "Pascal is the thalidomide victim of programming languages." This paper should be read by anyone interested in Pascal. We are going to reprint his summary here and hope we don't get sued:

"To close, let me summarize the main points in the case against Pascal.

"1) Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.

"2) The lack of internal static variables and initialization combine to destroy the "locality" of a program - variables require much more scope than they ought to.

"3) The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.

"4) The one-pass nature of the language forces procedures and functions to be presented in an

Page 11, Column 1

unnatural order; the enforced separation of various declarations separates program components that logically belong together.

"5) The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.

"6) The case statement is emasculated because there is no default clause.

"7) The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.

"8) The language lacks most of the tools needed for assembling large programs, most notably file inclusion.

"9) There is no escape. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to write libraries of I/O routines in Pascal itself. The language is closed.

"People who use Pascal for serious programming fall into a fatal trap. Because the language is so impotent, it is extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, Fortran-like common, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group, but destroy its portability to others.

"I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming."

It is surely evident from these past few issues that opinions different from those held by your FNE are acceptable for publication in these pages, subject only to reasonable limitations on length and suitability for publication (we cannot totally set aside our editor's hat). Perhaps someone could explain, succintly, why Pascal is so great? We think four pages could be devoted to such a writeup, properly done. Four pages in here is eight columns of 55 characters each, so that is more space than one might think. Is anyone listening? Tom in rainyland? Earl in L.A.? Oliver across the big creek?

In fact, Pascal is hardly the only subject that could

Page 11, Column 2

stand exposure from outside. Any pet peeves out there? Favorite hobbyhorses? Aren't you tired of putting up with our opionions?

A reader sent us a copy of pg.23 of May '83 "INDUSTRIAL R & D." Somebody named Ervin A. Frand wrote a one-page editorial or commentary entitled "There must be a Ford at IBM." These two sentences were in bold-face:

"The low-priced, mass-produced automobile begat the assembly line. The assembly line did not beget the automobile."

Frand goes on to observe that Detroit ignored the low- cost transportation market because it was small, but now low-cost transportation is the market, and Detroit is hurting. Xerox ignored the low-cost copier market, and now low-cost copiers are the aarket. The point Frand seems to be making is that low-cost personal computers will soon be the computer market (we fully agree, for what that is worth).

But Mr. Frand seems to think that IBM is responding correctly to the small computer marketplace and we are only in partial agreement with that. You cannot compete effectively in the small computer marketplace if your lead times are six weeks and growing. You cannot set a 12-month game plan and stick to that plan when market conditions change. Because your competitors will leave large cleat-marks right up your back, that's why!

Almost all the 68000 folks (notably including Motorola) seem to be ignoring the low-end 68000 marketplace. So what is happening? The Intel folks are taking over the low-end coaputer market, and, gentlemen, that is becoming the market! The 68000 is going nowhere in the low-end market because, apparently, Motorola does not want the 68000 in the low-end market! And for the life of us, we cannot figure out why.

Mr. Frand closes with this paragraph: "I believe it was Winston Churchill who made the statement to the effect that if you do not choose to fight your enemy at a time and a place of your choosing when you know you will win, then you will inevitably fight him at a time and place of his choosing when you can never win."

Motorola deliberately chose not to fight for the small computer marketplace two years ago when it could have won with the 68000. Now Intel has chosen its time and its weapon, the 80186. Who is going to buy the 20 millionth 80186-based IBM PC clone?

(This is getting slightly embarrassing. We have just

Page 12, Column 1

received the June 6 issue of EET and, starting on page 10, is a story about how Motorola and BTE are moving far-east production lines using cheap labor back into the U.S. and into fully automated factories. Because it's cheaper, that's why. The stuff about this earlier in this newsletter was written, as noted, earlier. Honest.)

WE GET MAIL:

"...I myself have the Motorola MEX68KECB Educational Computer Board, and is finding it no end of fun to play with." Gordon B, Fort Sask, AB

Would you please write a review of that board for us, Gordon? As far as we know, you are the only subscriber who has one. Is AB really the standard abbreviation for Alberta (CANADA)?

"I've spent most of the last week writing 6502 programs for my son to use in his business. I'm glad to help him out, but what drudgery compared to the 68000! ...the routine to send text to the screen has delaying loops in it. Otherwise, the display changes almost instantly, and I have to search the screen for several moments to locate the first of the new lines on the screen. By slowing the screen down, my eye goes automatically to the first of the new lines. ...I hope that when you make a fast floating point board, it will be possible to use it with the one megabyte board you are now developing." Chester S, Iron Mountain, NY

Chet, we are taking every precaution to keep the static and dynamic RAM versions compatible with forthcoming peripheral boards. And, while we had already decided to allow some inefficiencies in HALGOL during I/O operations, we had not previously thought that it might be required!

"I look forward to reading your wonderful, erudite publication each month. I applaud your espousal of static RAM over the erratic dynamic stuff. Keep up the good work." Felgercarb Naysayer Elai, Santa Ana, CA.

Thanks for the kind words, Felgercarb. But you do know that the dynamic-RAM-loving Morlocks are going to win, don't you?

"Comments about Simon's Basic:

"This (large) set of extensions to Commodore Basic on the 64 is both a success and a failure. It is an outstanding achievement for someone who is sixteen years old. (It ought to put the fear of God in any number of 40-year-old programmers...)

Page 12, Column 2

"According to the manual, the package adds 114 commands to Commodore Basic. I have two comments about that number: first, while the 64 Basic lacks high level support for its fancy graphics and sound hardware, it probably does not need 114 more commands. Second, when a language is extended, it is important to make the fewest, not the most, additions. There is already a lot of clutter in Basic, and the last thing the world needs is to add 114 more commands to a language that is already poorly standardized, incompatible, and generally poorly suited for use by the millions of ordinary folk who are rushing down to the local drug store to buy a 64.

"Yes, the Commodore 64 needs a better Basic. But why not sit down and spend some time designing a coherent set of extensions that will be easy to use, and easy to remember? I think that Simon's Basic shows again that Commodore seldom chooses to do things right, Instead, it takes the quick and dirty, get it out the door, we'll make it better someday approach to product development. They make lots of money doing business the way they do, so I guess they'll keep on releasing soft/hardware that isn't ready to be used by consumers.

"David Simons has a bright future, as he is obviously a very talented programmer. I wish that he had been able to work with some experienced language designers while creating his package.'

R. Jeffries, Goleta CA

We are publishing this mini-review because it bears on language design, something we are currently working on. We also thought reading about a 16 year old doing such good work in assembly language would shame certain of our um, less ambitious readers to take a closer look at assembly language programming for things like utilities and language extensions. HALGOL is being deliberately designed for user extensibility at the assembly language level. (The way to do this, of course, is to provide the language in source form with full documentation.)

DEPT OF TRUE FACTS:

To go along with Sage's 2 MIPS performance which has since been eclipsed by Acorn's 8 MIPS, we had a letter a while back from Tom L of Seattle: "A 68000 expert has told me that grounding DTACK causes an extra five wait states on each memory cycle." We replied that his 'expert' wasn't.

Richard H of Dallas has just sent us a copy of Bob S- C's newsletter, the May '83 issue of APPLE ASSEMBLY LINE. Richard writes: "...appears unfairly negative and misleading. (I assume this may have something to do with issue #17, p.5)"

Page 13, Column 1

AAL states; "Analytical Engines, Inc. has one-upped the DTACK Grounded board. ...DTACK is NOT grounded on this board so you have access to the full 16-megabyte address space." Gosh, we learn something new about the 68000 every week, it seems. Grounding DTACK prevents access to all the memory space? Really? Bob, why don't you buy an Acorn and run at 8 MIPS? (Richard is correct about #17, p.5, col 1.)

By the way, Bob reports that Analytical Engines will soon have Unix available for their board. That should work real well with your 140Kbyte DOS 3.3 disks.

Speaking of Analytical Engines Inc, we have an update for you. On page 17, col 1 of issue #17 we reported that 'otherwise intelligent' (the Nat Semi 16032 freak, remember?) had put a $100 down payment an a Saybrook card. Well, we have just had a chat with 'O.I.' and it seems the folks at AEI saw that item and got upset. So they gave his one of their demo boards to hold. The demo board clears the Apple's HIRES screen in about 16 msec, according to O.I. So we stand corrected, the Saybrook now works in a demo form and has, for several weeks now. What does not work yet is all the wonderful software, otherwise they would deliver it to O.I., right? (This is being written an 29 May.)

Incidentally, 'otherwise intelligent' is not unhappy with us or vice-versa. When his wife recently renewed their subscription to this newsletter, she wrote "(Otherwise Intelligent)" alongside his name. He says he gets a surprising amount of mail at his business asking if he is 'O.I.' We are going to serve as a free proofreader for him on an article he is writing comparing the 68000 with the 16032 (plus other chips maybe).

You might be interested to know that 'O.I.' seems to think the 6809 is actually easier to program than the 60000! He says its instruction set is much more regular, which is true. It is also much more limited! But we really wish we had a recorder when he gave us a 15 minute diatribe about how difficult the 8086 was to program. Not because we disagree - this is the one subject in which we are in full agreement - but because he has actually programmed the 8086 in assembly language and was therefore able to describe the numerous deficiencies in colorful detail.

One of our readers wrote earlier that he was interested in serving is a clearing house for user-generated software for the DTACK boards. We wrote back urging that he reconsider, considering the difficultiet he would be letting himself in for. Well, he did reconsider:

Page 13, Column 2

"I was quite serious about serving as a clearing-house for DTACK software. I am unsure how much interest there will be in such an enterprise, but I think it's worth a try... The ground rules would be simple: send a disketter and a stamped mailer home, and I'll fill it up with whatever is available and return it immediately. [Jeff, what do you want to bet over half conveniently overlook the return postage? - FNE.] For now I only have DOS 3.3 to offer. Any type of software is welcomed, since the idea is to cross-pollinate thinking... Submissions should be documented on the disk in a standard text file for everybody's convenience. [You're going to get less documentation than return postage - FNE] When one disk won't hold it all, I'll start a volume system with a master catalog textfile on each disk. The first ten people sending submissions will receive a bonus blank Verbatim disk as a reward to get things going.

"My real concern is that this might be slow getting started, and people would be disappointed that there wasn't more available, so somebody's going to have to contribute or I will look like a dope. The usual disclaimers would certainly apply: no warranty is implied about the quality of the programs, which are placed in the public domain for the education of all DTACK users; if I have the slightest doubts that any material might be protected by copyright it will be returned and not distributed."

DTACK Software Exchange
c/o Jeffrey W. Hull, M.D.
4326 Congressional Drive
Corpus Christi, TX 78413

In the last issue we promoted Jeff from the semi-washed to the washed, and it looks like he turned right around and got himself another promotion, this time to civilian. If you will look at those initials right behind his last name, you will understand why Jeff didn't list his phone number. Doctors like to sleep at night, you know.

Jeff, you are going to look slightly dopey for about three months, and then things will take off as we get a somewhat usable HALGOL up and running in the interactive mode, so folks can write some fast applications software.

In the meantime our subversive West German friends (and sometimes customers) have also started a user group. If you are interested, contact:

Thomas Wieland
Saebenerstr, 126
8000 Munich 90
West Germany

Page 14, Column 1

Incidentally, we specifically (herewith) authorize Jeff and Thomas to charge a reasonable fee for costs involved in distributing any DTACK materials which may (technically) be copyrighted by us. We have no interest in protecting our copyrights except against companies. Thomas also sent us a comment about 8086/8 programming:

"...I had the chance to do some work with the IBM PC at my job and especially work with the 'wonderful' macro (etc.) 8086/8088 assembler. I think even with the little knowledge I have of the 68000, I'm forever spoiled for the kind of segmenting done with the 8086. It's just too painful."

Thomas, you are not going to get an argument either from us or from 'Otherwise Intelligent'! Oh, yes: If you want us to pass along that monitor, you should write up the instructions formally, print them using a fresh ribbon on paper 11 inches (not 12 inches) high, and ship them to us with a cardboard backing (unfolded). Most people who have DTACK boards use paper 11 inches high. Right, Oliver?

"I spent two hours.. trying out the Epson QX-10 with VALDOCS. VALDOCS is a great idea. However, it is poorly implemented; the machine is slow, slow, slow. Unfortunately the VALDOCS program is written in a FORTH dialect instead of assembly language... as it is now, I found it to be a disappointment." John K, Lewiston, ID

John, when are you going to let us off the hook over that Poe/Stevenson gaffe?

"VALDOCS... was written in FORTH, according to the BYTE reviews. It seems from the s-l-o-w keyboard response that the programmers left the time-critical routines in compiled FORTH rather than recoding into machine language..." Jeff H (again)

"The Epson QX-10 has one small weak spot in its design - the time taken to convert ASCII to dot-mapped form for display. I wonder how LISA does in this respect. ...when I can get a really cheap airline ticket to CA, I might pay a memorial visit to Santa Ana. No entry, just to nail some theses on the door to suite F." Nils D, F.C. (Faithful Correspondent)

Nils, LISA has a 68000 to spread the dots instead of a Z-80. And since when does Digital Acoustics rate as the establishment? Just because we don't want to put our 1-megabyte DTACK Grande on the VIC-20?

THE LAST WORD ON 1-2-3:

We know that some of you have been getting a little bit

Page 14, Column 2

tired of our emphasis on 1-2-3 and its speed, which is of course entirely due to the fact that it is programmed in assembly language. If you have felt that we exaggerated the importance of 1-2-3 as an event, stick around!

We urge that you seek out the June issue of Softalk magazine, the IBM edition. You can recognize it by what looks like a pink ice cream cone on the cover. The last two pages, as is traditional with Softalk, discusses which software programs are selling best. Both pages are entirely devoted to 1-2-3 or to how all the other prograes are doing poorly by comparison! To give you a flavor, we will quote froa the start and the finish of those two pages:

"To other software publishers Mitch Kapor's 1-2-3 must be taking on a resemblance to Ghidrah, the three-headed monster of Japanese filmlore who leaves chaos and destruction in his wake until chased off by Godzilla. That's essentially what 1-2-3 is doing to the market..." And now, folks, the closing paragraph:

"Lotus is doing everything right. There's not a Godzilla in sight. The IBM software market is theirs far more surely than the IBM hardware market belongs to IBM."

Folks, can we persuade you to read the last sentence of that final paragraph again? We cannot tell you the margin by which 1-2-3 is outselling Context's MBA (with its wonderful transportable p-code) because MBA is no longer one of the top 30 sellers (gosh! we wonder why?). But we can tell you that 1-2-3 is outselling Frogger by 21-1 and Frogger is outselling MBA.

The next thing we want to tell you is that the sales figures for 1-2-3, as reported in Softalk, are no longer accurate. You see, Softalk reports sales of software in retail stores only! And 1-2-3 is not just selling in retail stores these days.

Turn to page 34 of Eletronic News, 30 May '83. There you will find a 26-column-inch story entitled "Retailers Feel Pinched By Software Direct Sales." It seems that Lotus is building a National Accounts organization, staffing offices in several cities. When an IBM salesman calls on the larger accounts these days, the Lotus representative is right at his shoulder. And are the retailers ticked off! (You will recall that they gross $200 - $250 on each sale of 1-2- 3 and there have been many such sales!)

What the EN staffer who wrote the story (Robert Ristelhueber) did not apparently realize is just why Lotus was chosen as the sotware house to be introduced by the IBM salesman. But you and we know, dear reader.

Page 15, Column 1

The reason we have taken care to report this ongoing story to you is that many of you are Apple types who do not watch doings in the IBM PC World, and hence might overlook this event (and 1-2-3 is an event) until it is too late. What this means is that interpreted p-code will now only be used to write tic-tack-toe programs to amuse one's nephew. The last successful commercial program in p-code has already been written.

Fortune Systems, which offers a 68000-based computer whose operating system is rumored to be written in p- code, has now announced that it will report a loss in this quarter. EN reports that the president of Fortune does not return its repeated phone calls.

In June '83 BYTE magazine, beginning after page 384, is a large ad whose pages are not numbered. If you will turn about 7 pieces of paper you will find that HP ad we mentioned in the last issue. The HP Series 200 Model 16 runs an MBA function (using portable p-code) in just 30 seconds! That is doubtless highly impressive to the owner of 1-2-3 who can run the same function on his/her IBM PC in two or three seconds.

A FORTHRIGHT REVIEW:

Following is a $500 review of Bruce Walker's $30 FORTH:

"The author offers a set of two disks, implementing a 68000 version of the Forth Interest Group Forth (fig- Forth). FIG is an organization devoted to promoting the Forth language; its offerings are all in the public domain and it encourages people to use it's work as a basis for implementing commercial products. FIG's hope is that by providing a common kernal, future implementations will all be reasonably compatible so that code can be shared among various users, independent of the implementation. The author's use of the FIG material is therefore commendable.

"FIG will provide two manuals- the installation manual, and actual 68000 code, for $20. You then need to invent the interface code for your machine and copy the entire code manual in order to obtain a running system.

"The author has taken the material originally provided for the 6502, adapted the code to the 68000, and provided additional routines to do the interfacing between the DTACK board and the 6502, as well as the Apple's disk and the 68000. For all this work, two disks, one containing the Forth object code and interface routines, the other containing a set of text files containing the Forth source code, he is charging

Page 15, Column 2

only $45 ($30 if you don't want the assembly code listing). I consider this a real bargain.

"My comments about the actual workings of the programs must be addressed to three different audiences: people who know very little about Forth and have never used it; people who have some experience with Forth but are daunted by the prospect of developing a total system from scratch; and people who are interested in the details of the development of a 68000 Forth. Most of my comments will be directed to the second group, the non-expert Forth user, of which I am a member.

"Two documents accompany the disks. One is the fig- Forth glossary. The other consists of 5 pages containing the following material:

"1) Booting the system. (The disk I have uses DTACK's HELLO program and the program aborts when the disk access fails. This is a trivial oversight, just delete the offending line and resave the HELLO program.)

"2) Instructions for opening a DOS file that gives access to 50 screens. (Forth organizes the disk into a set of 1K 'files' called SCREENS. Data is stored on those screens - which have no names, but instead are numbered consecutively from 1 up. Most program development occurs by writing onto the screens using the Forth editor, and then compiling.)

"3) Instructions for saving a new version of Forth, containing any additional word added to the directory. The final word to be executed by Forth during a save is EXIT, and it does just that, leaving you in the BASIC supervisor program. There appears to be no way to return to Forth without reloading a new Forth image and doing a cold-reboot.

"All this material is covered in a page and a half. I found it clear, and had little trouble using it. The user should be warned however that: i) It is absolutely vital to issue the command EMPTY-BUFFERS before beginning. ii) Although the word FN appears to support backspacing, it really doesn't and will try to access a file whose name includes embedded backspaces. This causes the system to crash. Retype FN after a carriage return if you make an error. This warning is given, but several pages later. iii) The word OPEN should be followed by the word DROP. For some reason OPEN and CLOSE leave an integer on the stack. iv) Many errors will drop you into the 6502 BASIC supervisor program, which then aborts. The only recourse seems to be a COLD boot. Therefore you would be well advised to save your work frequently.

"4) Next is a list of about two dozen new words not contained in the fig glossary. Some of these words are

Page 16, Column 1

actually defined on screens 14 and 16; I encourage the new user to read these screens. There is also a brief discussion of an application program (a text editor) that is provided as (Forth) source code on the screens.

"5) The final item is a brief discussion of how to initialize a new set of screens.

"Documentation is the bane of all software (and hardware?) developers. The documentation here is clear enough that I had only minimal problems getting started. I believe that if you are an old Forth hand you will have little trouble getting up and running, but if you are not familiar with Forth this material will not be sufficient.

"The problems for a novice are, I believe, severe. The author recommends 'STARTING FORTH' by Leo Brodie. That book was written for PolyForth and uses a slightly different model. Where that model differs from the Forth-79 standard, Brodie gives both versions. This will not be sufficient for the fig-Forth user. The words CREAT BUILDS> and

"(By the way, it is a tribute to Forth's portability that a complete explanation of the differences between the 79-standard and FIG takes about a dozen pages. The book might really be used by a novice with this information, although I have never seen one try. Imagine trying to do the same with Applesaft and Radio Shack Basic!) I tried an experiment, opening Brodie's book (at random) to the section which explains what happens inside a colon definition. Extensive use there is made of the word EXIT. Did you know that ;S is the fig-Forth word for EXIT? Guess what would happen if you did use EXIT as Brodie suggests?

"Now, about the interface implementation provided: Besides loading Forth onto the 68000 and forcing a jump to Forth's cold start routine, Forth requires a method for reading and writing a 1K screen from the disk. This involves code for both the 68000 and the 6502. The 68000 code is quite simple, but the 6502 code is a combination of machine code, BASIC, and calls to the DTACK 'UTIL' sonitor routines at $8600. This leads to

Page 16, Column 2

a very fragile interface. I actually managed to disorder the DOS file containing the definition of some extra Forth utilities - and I have no idea how I did it! A more explicit problem concerns the use of BASIC. Control-C is traditionally used by Forth is a 'break' signal. Depending an what is being executed, this character may be passed through to the BASIC program, resulting in its aborting. There is no easy way to recover. A RESET causes the same problem, as may a disk error (e.g. trying to read a screen whose number is 'too large').

"Fortunately this is not a major problem. Most of the interface is entirely outside the actual Forth implementation, and can be recoded at leisure. It is too bad that a standard I/O interface has not yet been devised. This is a tedious job, and I can't really fault the author, who was eager to get Forth up and running, for not working harder on this part of the project. We all badly need a standard way to pass keyboard input back and forth between the 6502 and the 68000, as well as a standard way to open, read, write and close DOS files. Halgol will need to do this, and I understand that DTACK is actively working on just such a project. (Bravo!)

"I feel obligated to warn the expert user who envisions redoing the interface that the documentation provided by the author does not have any information about this aspect of the implementation. The exact method by which data is exchanged between the 6502 and the 68000 is not specified, nor is the protocol for disk access. Of course all the code is provided, so a diligent person could eventually unravel the protocols.

"Here is a sample of some questions that I have, that will have to be answered before I can alter the interface: i) How can I change the 6502 readkey routine to support the Apple's escape key editing functions? Somewhere the interface could be made to call the routine at $FD35 in the Apple's monitor, or is that contrary to the interface design the author developed? ii) Why can only one set of screen files be open at a time, and why does the program allow access to SCREEN # 0 (illegal in fig-Forth)?

"My final comments are directed solely to the experts, who well say be interested in the details of the 68000 code the author wrote to implement the kernal. Much of it is a direct translation of the 6502 code upon which it is modeled. Often second guessers will find a slightly better version. For example, subtraction follows the 8-bit 6502 model of negating one argument and then adding. Since there is a 16-bit 68000 subtract, a slightly faster version can be coded. The major problem with Forth on a very powerful computer is the overhead involved in the NEXT code contained in

Page 17, Column 1

every word in the kernal. This overhead must be divided by the amount of code needed to do the computation desired to see what effect changes in the code will have on performance. When the computation corresponds to only one or two machine instructions, Forth is very inefficient as compared to assembly language. Moreover, improving the coding of any word will have much less impact than improving the code for DOCOLON and NEXT. For this reason I believe that the author's Forth is already running near top speed. I can't imagine anyone getting a 50% improvement over the current benchmark times no matter what improvements in the code he comes up with.

"Another area that has received such attention is the use of stacks in Forth. The author (for reasons I cannot fathom) has limited both the return stack and the data stack to 256 bytes! That should be trivial to fix (if you have a Phase-Zero assembler). I suggest putting the data stack between the disk buffers and the dictionary, and perhaps eliminating the test for stack overflow in DOCOL at the same time. A larger return stack seems reasonable as well. Another suggestion would be to define the top of the data stack to be the D0 register. The resulting code can be such prettier and faster (but see the comment above!).

"Lest these criticisms sees harsh, or unfair, let me stress that the code is a reasonable basis for getting started, and allows you to easily debug improvements.

"To summarize: If you were thinking of implementing Forth yourself - there's more than enough material here to justify buying both disks. Revision is always easier than creation, and where could you find someone willing to type all that material for only $45? If you are waiting for the perfect implementation of Forth - buy this implementation. It only costs $30, and will give you a chance to start writing code right now. That future 'perfect' version will probably cost you $300, and there's no guarantee it will work any better! Finally, if you are curious about Forth, and wondering if it is worth learning - I assure you that it is. But I think you should start with some other version (unfortunately on some other less powerful computer).'

Norman P. Herzberg
c/o IDA - CRD
1 Thanet Road
Princeton, NJ 08540

Bruce's reply: "...actually, I'm quite glad that he took the time to do (the review), as he clearly put a lot of time into it. There are some misunderstandings, though, which I would like to correct, and one improvement.

Page 17, Column 2

"1) After running EXIT, when you type RUN (into the Apple basic monitar), the program still restart, and ask if you want to reload Forth. If not, it will start again with the image that's already in the 68000 memory. If you have made any changes since you first loaded Forth, however, you will have lost them unless you did a PERM command. As for the choice of the word EXIT, I have to admit it was a bad one. At least the code for the Apple interface is supplied as source, so that if you don't like it, any user can change it.

"2) I agree that FN should support backspace, and believe me, I've got the files with imbedded backspace characters to prove it. The following revised FN does support backspace:

 : FN 0 7686 C!
      32 1 DO
             KEY DUP EMIT
             DUP 13 = IF DROP 7686 C@ 1 - 7686 C! ELSE
             7686 C@ 1+ DUP 7686 C! 7686 + C! THEN THEN
         LOOP ; 

"3) OPEN and CLOSE leave a word on the stack because, in the mode where I/O errors don't halt the system, they return an indication of success or failure. That word is redundant, of course, if the system is in a mode where an I/O error halts the system. If you are always going to use it in that mode, I suggest changing the definition of OPEN and CLOSE, as Herzberg suggests.

"4) I agree that more documentation could be provided; it just takes a lot of time and energy.

"5) I agree that the interface, with BASIC doing a lot of the work is fragile, and I suspect rather slower than it might be. But, getting it up in BASIC was faster than any other way I could think of.

"6) Access to screen 0 is possible in Fig-FORTH, a direct call of R/W will do it every time. A more serious problem is accessing more than one set of screens at a time. There are serious design problems here: if more than one file is open, since a word like BLOCK takes only a single integer argument, which file is meant? There are ways of doing this, but they require redesigning the fig-FORTH model of disk blocks from scratch along with all the words which use them. I wasn't up to that, and besides, I have programs which use the current BLOCK heavily--so I took the coward's way out." Bruce Walker, San Pedro CA

Between us and MICRO magazine, two of the available 68000 educational boards are being reviewed. See MICRO, June '83, p.42. The reviewer seems to be highly impressed by that 4MHz jewel.

Page 18, Column 1

Faithful Correspondent (FC) Nils Dahl, Jr. has bought an EMS board to go with his VIC-20 and has submitted the following:

THE EMS 68000 BOARD:
A MODEST REVIEW

"The EMS 68000 board is definitely a learning tool. The first thing that you will learn after receiving the bare board ($99.95) is that a fully socketed board is available for $159.95. Best for anyone interested to write for literature prior to any purchase from EMS.

"An overview: the designer of the EMS board has aimed at a specific market for his product. The board offers several different I/O ports as delivered but only the RS-232 ports are supported by the software provided. EMS has announced plans for add-ons such as memory expansion, disk controllers and video boards. The mother board is obviously designed as the basis for an expanded system. EMS is offering the complete kit (including the 68000) for $544.90. This package, under certain conditions, could offer some people a good deal more hardware for the money than does DTACK.

"The EMS board is a superb commercial grade product with solder mask, silk screen and gold-plated edged connectors. The board was designed for wave-soldering and will require a miniature soldering iron and a delicate touch to hand-solder the sockets. The following parts are provided:

"Two RS-232 ports, one for data terminals and one for data set functions [such as a modem? - FNE].

"One parallel port; 16 data lines, write enable, strobe in and strobe out [sounds like a PIA chip - FNE].

"One program cartridge port; will accept up to four 16K blocks of ROM.

"One peripheral port which supports 8-bit transfers and offers 10 address lines plus the service lines for system communication.

"One memory expansion interface for up to 512K of memory. The adventurous hobbyist could try cutting two of the four ground connections and jumpering in two additional address lines.

"One blank port - this edge connector could be hard- wired but has, as delivered, only two cryptic connections.

"Revision B of the EMS board offers clock speeds of 10, 5 and 2.5 MHz. Rather than designing for blinding speed in synchronous mode, the EMS board aims at using

Page 18, Column 2

the versatility of asynchronous made to permit easy implementation of various memory types and devices, somehow using the variable bus speed to accomodate slow EPROMS along with fast static RAM chips [why are we reminded of our newsletter #1, page 1? - FNE]. Address and data lines are buffered using TTL chips. Timing for the RS-232 parts and system clock for time keeping are generated in a most unusual chip, the AMD 9513. Anyone who was puzzled by the 6522 spec sheet has a real treat in store with the 9513. The monitor is in one 2764 [one? surely you jest! - FNE] although a second 2764 is provided for user expansion of the monitor. Some logic is used to force a jump into the monitor instead of the normal starting vector fetch at $000000.

"The ports are buffered using additional TTL chips. Only the RS-232 ports have latching features, all others are buffered only. These other ports are going to need software servicing and will be slightly more difficult to use than register/buffer ports that hold the data indefinitely [such as DTACK uses - FNE].

"Except for the 9513 timer chip, there are no real surprises in hardware on this board. Unfortunately, there is one designer-acknowledged defect. The attempt to design in a Bus Error subsystem failed, as there is a warning not to use the two 74LS373 chips that were to constitute the bus error register [you must re-read issue #1, page 1, par. 2! - FNE].

"The specs call for power of 5 volts at 2 amps for logic plus the usual +/- 12 volts for RS-232.

"This board would be an excellent starting point for hobbyists if the following provisos are well understood. The board is not well documented (more on this later) and it is not sold in tested form. The user will first have to assemble and test it. If you don't have a 20MHz dual trace scope and a multimeter, or access to same through a friend, forget this board. You must own a commercial terminal or a computer having terminal (RS-232) facilities. The monitor software responds only to RS-232 ports [and to think we get criticized because our standard product 'only' transfers 71,000 bytes - not bits - per second! - FNE]. The user will have to write and load software to support other ports. Storage of user-written software will have to be on devices already available and working. Using a terminal alone will mean re-entering your 68000 programs via keyboard every time something goes wrong.

"Now, the documentation: This board was aimed at advanced hobbyists who already have or can easily figure out how the existing support logic chips work. The manual tells you next to nothing; this is the one weak point of the EMS board.

Page 19, Column 1

"Let me indulge in some harsh criticism for a change. The manual for the EMS board is a joke. EMS provides five very sparse pages of descriptive information, one memory map PROM logic chart, one ten page appendix containing a nice chip list (3 pages), part signal/pinout descriptions (five pages), one jumper option list page, and one very poor chip location sketch (barely readable). Following is the heart of the manual, three single sheets of logic diagrams that define all chip connections [a schematic? - FNE].

"We also are provided a copy of the spec sheet and an application note on the 9513, 39 pages. Another page briefly describes the differences between the EMS monitor and the Motorola MACSBUS monitor (oh ho). Eighteen pages are copied from the MACSBUS monitor manual and detailing the features offered for use of MACSBUG on the EXORCISOR (oh ho). Four pages on S- Record formats [? - FNE], source of copy unknown. One warranty page, essentially telling you that you will lose 20% of the price if you return a non-defective board.

"Now we have clues as to the source of the EMS board. It appears to be a slight redesign of the Motorola educational board that will require advanced knowledge of various topics to apply intelligently. If you are a novice, forget the EMS board immediately. If you are a dedicated and experienced hardware type, you may be able to implement the board as delivered and eventually get it working satisfactorily. Should you want a full system, please wait until EMS is delivering the other pieces [see June BYTE page 399 - FNE] and plan to spend many hours putting it together and testing it. The cost of such a system may be well beyond that of a working Sage II with terminal and printer. If you are interested in the EMS board as an educational tool, you may find that it is below the bare minimum required to permit learning (as opposed to sheer frustration)."

Nils Dahl, Jr.
40 Belcher Road
Wethersfield CT 06109

Nils included in editorial which is not, in our opinion, properly part of the review: "We must realize that a 68000 board or system, developed by a small company, inevitably will cost much more than when a major cranks them out by the millions. That millions stage will not be reached for several years, and then only if 68000 software becomes plentiful and cheap."

Nils adds an epilogue: "The EMS board will provide me with the knowledge required to prototype my own 68000 system, one that will use the VIC-20 as a support system." Good luck, Nils!

Page 19, Column 2

The DTACK Grande:

As most of you are aware, we are not terribly fond of dynamic RAM. See, for instance, page 10 and part of 11 in issue #10, which was mailed exactly a year ago. But it is also true that there are some applications where the use of dynamic RAN is perfectly reasonable, as we pointed out on page 5, col 2 of issue #9. Why did it take so long from that time for us to bring a dynamic RAM version of the DTACK board out? Because that was the point where our sales suddenly climbed dramatically.

Look, if you own a hardware store which has three clerks and your sales triple over a five month period you are not going to get much advance planning done during that time. That is exactly what happened to us. As long as we are telling you about how our business is going, let us admit that our sales have essentially stabilized since last Sept. And, we added another engineer last Nov. as witness the Stuffer board, of which more anon.

Because our sales have stabilized, it appears that we have saturated the market for high-perfortance 68000 boards using highly reliable static RAM. To be perfectly honest, we never expected that product to have mass market appeal. The Grande won't have true mass appeal either because we don't have the canned software that market requires.

But where else can you purchase a megabyte of 150nsec DRAM plus a 12.5MHz 68000 (with one wait state) for $1995? Following is the complete price list:

  128K        $795
  256K        $945
  384K       $1095
  512K       $1245

  640K       $1545
  768K       $1695
  896K       $1845
 1024K       $1995 

"1024K" is, of course, a megabyte. The reason for the incremental step in price at 640K is that we have to add another circuit board at that point.

EXPANSION BOARD PRICING:

Expansion board prices, for boards purchased separately, are as follows:

  128K        $345
  256K        $495
  384K        $645
  512K        $795 

Page 20, Column 1

MEMORY UPGRADE POLICY:

We will upgrade one memory size to the next for the difference in the then current published prices for the two memory sizes, plus a $50 handling charge, plus shipping and sales tax (where applicable). If you return a board to us, be sure to wrap it in aluminum foil so that it will not be damaged by the surface static electrical charge that is found in the ubiquitous styrofoam packing materials. (That's what those black conductive plastic bags that you threw away were for.) Also, remove any RAMs or other ICs which you have added yourself; we don't want them in our shop.

This policy is applicable to static and dynamic RAM boards equally.

DELIVERY SCHEDULES:

We urge you to wait a few weeks after first reading this before sending us an order for a Grande. If you must place an order immediately, you must clearly authorize us, in writing, to hold your deposit or payment for longer thin 30 days. Otherwise, we will return it. Be sure to specify a cutoff point at which we must return your check if we do not ship. We do not know what the demand is going to be for this board nor are we certain as we write this how many boards we can ship when.

(To be perfectly honest, we really don't expect an avalanche of orders because the great unwashed need more canned software than we have to offer.)

A DTACK REPORT CARD:

Since we began shipping Apple compatible boards in Dec '81, we have been able to ship boards very quickly on receipt of order. Our average turn-around time has been just under three working days (!) over the past 19 months. It is not unusual for an order for an Apple compatible board which arrives in the 12:30 mail to go out the same day on the 3:30 UPS pickup. That's the Apple compatible boards.

Now, about the Pet compatible boards: First, there are four varieties of Pet/CBMs that we can hook our static RAM 68000 board onto, and each of them is different, requiring different EPROMS and in one case special hardware. Also, we have sold an average of 1.1 Pet/CBM compatible boards in the 20 months we have been shipping them. That means that a given variety of Pet/CBM is purchased once every 3.6 months.

Even given the problems cited above, we have to admit that our delivery performance for Pet folks has been completely unacceptable for a company which requires a

Page 20, Column 2

10% down payment to seal an order. We also admit that the situation isn't going to get any better, so if you order a Pet/CBM board be prepared to wait a while. (We do ship, eventually.)

But that problem will not exist for the DRAM board because we do not plan to offer a Pet/CBM version. It turns out that the added complexity of DRAM circuitry means that we can't add all that extra Pet interface circuitry that is on our static RAM board. See the front page of issue #3, and note the nine ICs, including one 2K X 8 RAM, just above the two 50 wire cables. Now look at the board on the front page of issue #20. See what we mean?

THE RELIABILITY ISSUE:

Our DRAM boards do not have either error detection or correction, nor do we have parity, which detects errors but does not correct them. The reason we do not have error detection and correction is that such circuitry is very expensive, prohibitively expensive for memory sizes less than half a megabyte.

There are two reasons why we do not have parity on the Grande. The first is that we do not believe in it. If a parity error occurs on an instruction fetch and you have parity, you will know that your computer went out into left field due to a parity error. If you have one of our boards and the same thing happens, you will only suspect a parity error. What's the diff?

We urge that you understand this clearly: parity does not correct errors, it merely detects them. The detection is not useful at all on an instruction fetch, and real programs run between 85% and 98% instruction fetches.

Parity also slows things down when you are trying to run as close to 12.5MHz as possible. When your memory cycle time is 800nsec or more, as in the IBM PC with its 4.77MHz 8086, parity is simpler (and you can use cheaper memory).

WHAT IS THE ERROR RATE?

As we have repeatedly stated, we don't know. We don't think anyone else can be certain what the error rates are. We will provide a test program with the Grande (as we do with the Grounded) to detect errors. But we cannot, in a simple home or office environment, determine whether it was an electrical interference problem (see issue #19, p.6, col 2) or an alpha particle, or a plain 'failure' error.

What we do know is that the error rate for a megabyte of program will be 16 times greater than for a 64K program, and the error rate for a 1K program will be 64 times less than for a 64K program. That applies to alpha partical problems and plain failures. Where electrical interference is concerned, the error rate is independent of the program size.

ANSWER NOT MY QUESTION:

We are consistently asked to put a number on the 'mean time to error', as measured in hours. Nobody wants us to answer that question. What they want us to do is to guarantee that no error will occur for X hours after the equipment is turned on. We can't do that, and neither can anybody else: alpha errors and 'failure' errors are completely random in nature.

We candidly urge that you beware of Murphy.

WHAT 1K PROGRAM?

Why, a RAM disk program. See, for instance, page 101 of Jun '83 BYTE magazine (and check those prices!). The Grande can be used as a large and highly reliable RAM disk. (We hope nobody has copyrighted that name. For a while, the Zilog lawyers were claiming that it had copyrighted about 4% of the alphabet and that nobody else could use that 4%.) And yes, we do mean highly reliable. Here is the way it works:

Suppose we are working with 256 byte sectors. For each sector, we store an associated checksum, two bytes, plus a software-generated parity table, one bit for each byte. That's an additional 32 bytes. So we use 290 bytes to store each sector. The parity is generated by a simple lookup-table, so not much time is lost generating that table. With a 1 megabyte Grande, we can store 3,601 such sectors, or 900.25 Kbytes of simulated disk. That's 6.4 DOS 3.3 disks. These figures are based on setting aside the odd 4K which is not contiguous to the 1020K as the location of the RAM disk program. 4K is more than we need.

Because the error rate in only 1K of that DRAM is almost certainly going to be many times smaller than the error rate due to power outages or electrical interference, we can have a highly reliable simulation of a disk if we can prevent errors from accumulating in those 3,601 sectors. We can.

Suppose we assume an absurdly high random error rate in our megabyte of one bit error per hour. That means each sector will catch an error once every 3,601 hours on average. We need to not only detect those errors, we need to correct them! Here is how:

The 68000 is interrupted every 2 milliseconds to refresh the DRAM. That's 500 times per second. After each refresh cycle, we calculate the checksum of one of those 3,601 sectors and compare this to the stored

Page 21, Column 2

original. That means that each sector is checked every 7.2 seconds!

3,601 hours divided by 7.2 seconds means that each sector is checked nearly two million times for every random error which occurs.

When the stored checksum is incorrect, we can determine (assuming a single bit error) which bit is in error by the difference in the checksums. If the difference is $40, then D6 on one of the 256 bytes is bad or the error is in the low order byte of the checksum itself, Now (and this will happen only once every two million trials) we test the parity on each of the 256 stored bytes. The one with the parity error is the byte with the error, which we can correct because we know what bit is in error. If no byte has a parity error, then it is the checksum itself which is wrong, so we replace it and continue.

This is a foolproof method which will detect and correct single bit errors and detect most multiple-bit errors. We will, of course, keep a log of the locations where errors were detected in the remaining 3K of our 4K RAM, or perhaps in the last sector, leaving 3,600 usable sectors. In this manner, we can detect a 'squirrelly' DRAM or an incipient failure.

Now, about the possibility of multi-bit failures: our statistical knowledge was never that great, but we figure that if we are testing for failures two million times more often than they occur and if a single bit error occurs in a given sector every 3,600 hours, then we can consider a multi-bit failure due to random processes about equal to the probability of having a satellite fall an your head. Multi-bit failures will be associated with power outages or electrical interference.

The checking process should require about half a millisecond on each 2nsec interrupt, so that becomes the maxisum 'latency' for a disk request from the Apple. Disk folks generally talk averages, so we have a 1/16 millisecond latencey for our RAM disk. That ain't too bad!

Because we are being candid with you (at least, we try), here is what we think is going to happen: given the present status of software support, we think we would eventually reach an 'equilibrium' with the Grande of about 20 megabyte boards a month and about 20 boards averaging 256K. The 128K orders will average with the 512K orders to maintain the 256K average. The two modes will be a megabyte and 256K.

We do have the new-product problem, where the nervous

Page 22, Column 1

nellies wait and see how the brave sams do with the new boards. This credibility problem will be smaller than when we first started out because most people have heard of us by now and they know we have been shipping 68000 boards that work. Still, that means that we are going to start out slower than those figures above.

We also intend, seriously, to turn HALGOL into a workable language which will be available in source form. We think Phase Zero is equally committed to developing that 68000 BASIC which will work with our board. These two events are going to change the arithmetic, but we do not know how drastically.

In other words, we don't really know what is going to happen. Is your crystal ball calibrated better than ours? We do know that we can continue to be profitable and to grow, even under the worst case scenario we can think of. The fact that we have other products coming down the line to support the existing boards is going to help, and so is the fact that we have kept the dynamic RAM board compatible with the static. The Stuffer board works with both, and so will the math chip add-on, and so will the (very high res) graphics boards we are working on.

We hate to bore you with this business stuff, but we can't have fun playing around with the 68000 if we can't pay the bills. And we love to play around with the 68000! We hope you do, too.

OBSCURE STUFF:

We thought we ought to let you know that H. G. Wells wrote a story called 'The Time Machine' in the 1890s. In this story we find, in a distant future, two races of men. The Eloi were childlike, somewhat degenerate descendents of an earlier race of men with (comparative) god-like powers. We imagine that the Eloi would be very like static RAM advocates. The other race was the squat and ugly Morlocks, who we imagine would prefer dynamic RAM. Oh, yes: the Morlocks occasionally dined on roast Eloi! (We never said static RAM would win.)

ABOUT THE 'STUFFER' BOARD:

If you do not have a requirement to transfer an 8K graphics page from the 68000 memory space to the Apple HIRES page(s) very quickly, then you don't need a Stuffer board. It would be stretching the truth to say otherwise. Well, we've told you ever since the beginning that you didn't need DMA, no?

But if your graphics application requires that you frequently and continuously update the 8K HIRES page(s), then the Stuffer board is both inexpensive and essential.

Page 22, Column 2

HALGOL STUFF:

The HALGOL BIOS, at least the portion affecting the interaction between the keyboard of the Apple and the CRT, is progressing rapidly. Since most of you are Apple types, most of you will not be interested in the fact that we are implementing the HALGOL environment as a full screen editor. But you few Pet types know what we mean, don't you?

Let's just say that if you don't know what a screen editor is, you are going to be very pleasantly surprised. It's not quite as important as the opposite sex, but it is close! A full screen editor works much better when it has 80 columns to work with, so it looks like we are going to have to follow the suggestion a reader just sent us to do a survey of the equipment you Apple type DTACK customers have, such as 80 column boards. It doesn't make any sense to support 80 columns if less than half of you have one, and it doesn't make sense not to if over 90% of you do have 80 column boards.

We have been re-educating one of our Apple type friends who was formerly into minicomputers. When you think of minicomputers, you think of operating modes. So, he asked how one entered the HALGOL 'screen editor mode'? It works this way, folks: HALGOL is not a 'mode', it is an environment. Interactive BASIC is also not a 'mode', it is an environment. When you switch on a CBM 8032, the screen editor is there! What screen editor mode?

The CBM screen editor has this one small problem: the line being edited cannot be longer than the width of the CRT monitor. Our 64 column Wang 2200 column CRT, does not have a screen editor, but it does have a line editor which has to be specifically called up with a dedicated 'edit' key. The 2200 can edit a line which is longer than the width of the CRT monitor. Naturally, we want the HALGOL screen editor to be able to edit a multi-line statement without the necessity of entering a special mode.

THE HALGOL SCREEN EDITOR:

It should be understood that the 68000 is in sole and complete charge of the keyboard and the CRT display at all times (and against the wishes of all of you readers, who wish to continue using the alleged intelligence of the 6502). A replica of the screen display is maintained in the 68000. Since we have more memory to work with, we can maintain several screens at once. We are only limited by the amount of RAM we wish to set aside. Doesn't it seem reasonable to set aside an 8K area in the 68000 which could be used as the graphics buffer in the graphics made and as a multiple- screen text storage area in the text made? This will

Page 23, Column 1

provide 8 screen storage for a 40-column display or 4 80 column screens.

This will be especially advantageous when editing a program as it will be possible to 'reverse scroll' through an additional 6 or 7 K-bytes of text.

Now, about how we will overcome the single-line screen editor limitation of the CBM: Each line will have an associated flag. This flag can be a bit or a byte; memory is cheap these days. The purpose of the flag is to indicate whether a line is complete in itself (yes) or is continued on the next line (no).

Consider the following hypothetical lines of BASIC:

 100 LET SCARE=SUM*DIFF
 110 PRINT"THIS TEXT IS TOO
 LONG TO FIT ON ONE LONE" 

We seem to have a typo in each program line. In line 100, we want the variable name to be 'SCORE'. So we run the cursor up and place it over the 'A', type 'O' and then 'RETURN'. This would erase the remainder of the line if you were running Applesaft, but with a Pet/CBM (even a $78 VIC-20!) the complete line will be re-entered into the computer and will replace the old line since the line number is unchanged.

But the Pet screen editors are unable to handle the typo in the last word of line #110 because the line is too long to fit on one line of the CRT. With the HALGOL full screen editor we mill be able to place the cursor over the 'O' in the last word of that program line and key 'I' and then RETURN. The complete program line will then be accepted and will replace the line with the same number in memory.

How? When the screen editor detects a carriage return, it accepts the complete line on the CRT, including characters beyond the cursor (Applesoft doesn't). But we also check the flag for the previous line on the CRT to determine whether the previous line is self- sufficient and complete. It is not, so that line on the CRT is appended onto the front of the line where the carriage return was detected. Now we check the next previous line, which is line #100. It is self- sufficient, so the two CRT lines which make up line #110 are both accepted and the complete program line is then correctly edited.

Here is how we determine 'self-sufficiency': We begin with an empty screen; all the lines are flagged as self-sufficient. The only time we clear the flag is when the character-print (or echo) routine detects a wrap-around to the next line. If the wrap-around is followed immediately by a carriage return, indicating the previous line has been completed, then we go back

Page 23, Column 2

and re-flag that line as sell-sufficent. Simple, no?

Why the CBM screen editor doesn't work this way we don't know. We also don't know why the Apple doesn't have a screen editor. HALGOL has a full screen editor which works; believe it! And remember, there is no 'screen editor mode', you just boot HALGOL and the screen editor is there, it is part of the HALGOL environment.

Look, you want to 'do' Pascal? First you load the text editor and enter some Pascal source code. Then you save it and call up the compiler. Then you call the linking editor. Since you entered the code perfectly, with no errors, you now get a binary object file that you can run, you lucky devil you. Before your program does anything for you, you must deliberately call up four different operating modes!

Interactive BASIC is different. You turn the computer on, and if you have BASIC in ROM, you can enter a program, save a program, load a program, run a program; and if any errors are encountered at run time, you can list the offending line, determine what the problem is, and edit it. There is ao 'mode'! Interactive BASIC is an environment, and that is what sakes interactive BASIC so friendly. We want HALGOL to be equally friendly.

By now you should be getting the idea that HALGOL; the language, the operating system, the environment, will be a composite of the best features we can find in other computers plus an idea or two of our own. The three computers with which we are most familiar are, as you know by now, the Wang 2200, the CBM 8032, and the Apple II+. We spend a lot of time these days at the keyboard of our Eagle II, but so far we haven't run anything but the word processor and the disk backup module.

BEGINNING AT THE BEGINNING:

As most of you are doubtless aware, HALGOL will not make an initial appearance as a fully complete and finalized system. We must, once the language is complete enough to save useful programs to disk, allow for passing HALGOL programs to the next version of HALGOL. This is vitally important. Since the program is largely a list of the 16-bit addresses of the run- time object code for each function, some of these addresses will inevitably move around. Now is the time to plan for this eventuality.

We can see two solutions, both of which involve saving the program to disk in other than its optimum pre- compiled form. The compilation we refer to is the one that takes place as each line is entered from the keyboard under the direction of that slow chemical

Page 24, Column 1

computer; there is no separate 'compilation' as in UCSD Pascal or the usual compiled BASIC.

One obvious form is the text image of a printed listing of the HALGOL program. When the text is re-loaded, it can be re-compiled just as though each line is being entered from the keyboard. Programs saved in this fashion will tend to occupy much more disk space than a conventional HALGOL disk image. This does seem to be the easiest and most idiot-proof method.

There is another method worth considering: the use of a tightly coded byte-oriented format, similar in some respects to the way your 6502 BASIC works. This will result in a disk image that is actually smaller than a conventional HALGOL disk image. Aside from the desirability of saving disk space, we must consider the tantalizing possibility that, if the disk is sufficiently slow, the 68000 may be able to re- constitute the program from its compressed form so fast that the time savings resulting from the smaller number of bytes to be loaded from the disk actually results in a faster effective load-and-run time than recording the program in the conventional HALGOL image. (Yes, we know that's a long sentence. We couldn't think of a way to break it up and still make sense. Sorry.)

We will use one, or both, of those methods to transport programs from HALGOL v.X to v.X+1.

HALGOL VARIABLE NAMES:

You should recall that HALGOL will permit variable names of whatever length (maybe we oughta put a limit of 255 bytes an a name?). And that constant variables, such as '1', will be permitted. Those of you who were paying attention last issue will also be aware that HALGOL will permit expressions such as:

 LET A = B + C * D / E + F 

Now, we certainly hope that all of us can agree what that last line (stripped of its line number) means. Consider this next line:

 LET A = B+C*D/E+F 

Does this mean to set variable 'A' equal to the variable whose name is "B+C*D/E+F"? Or do we implicitly accept "+", "-", "*", "/" as delimiters between variable names? This is an important question, since it determines whether "SCORE*MARGIN" is a legal variable name. One does not worry about such matters ordinarily, one just uses the syntax permitted by the language one is running. Since we are designing the language, we are not permitted to duck this issue.

Our decision is that the four math operators (and the

Page 24, Column 2

"=" sign) are delimiters. This means the two lines above are equivalent and that "SCORE*MARGIN" means to add the MARGIN to the SCORE. BASIC uses the math operators as delimiters and we do not want to depart too far from BASIC.

COMPILATION BY TEMPLATE:

IEEE Computer magazine has a department called "The Open Channel." The guidelines for this department state in part: "We'll accept anything (short of libel or obscenity) so long as it's submitted by a member of the Computer Society. If it's really bizarre we may require you to get another member to cosponsor your item."

As you might imagine, the quality of the submittals to that department is somewhat variable. The average quality is amazingly high. In the May '81 issue is a much longer than average paper entitled "On Systematic Generation of Scientific Papers" which in our opinion is utterly outstanding. You will note that the publication date happens to be two months before we wrote the first issue of this newsletter. The nature of this newsletter has been profoundly influenced by that paper.

The first paragraph reads (in part): "...Even if you are an accomplished scientific writer, your work probably suffers from consistency gaps as you lapse into a less technical style. Our simple method helps you achieve the consistent style acceptable to the publishers of most reputable scientific journals. This method will help you systematically set down your ideas clearly and simply - and then convert them into text that challenges even the most competent readers."

The authors show how a simple, clear paper can be successively improved. From space limitations we will trace the final sentence only. In simple language, we have "Better computers can do more work for us." In passive voice this becomes "Better computers can be made to do more work." With improved vocabulary we have "Enhanced computational equipment enables additional facilitation of work accomplishment.' Finally, the piece de resistance: "Prevention of the impinging of enhancements to computational equipment would (if actually allowed) prevent the additional positive facilitation of work and task accosplisheent by these greatly and affirmatively improved facilities."

Up to this point, we have an outstanding paper on the writing of acceptable scientific papers. The authors do not stop here, they go on to provide a step-by-step procedure for accomplishing the above. And now, they add a brilliant touch worthy of consideration for the Nobel Prize in Literature: they point out that the

Page 25, Column 1

step-by-step procedure can be cotputerized: "Writing will always be difficult, even for those who have mastered our effective and proven method. Someone should look into computer-aided writing. Someone is. We are."

"..and give rules for passive-voice sentence construction. This is advanced scientific text processing.

"Second, we have a such more ambitious project. We are trying to create several template scientific papers ... with passive-voice construction, repetition of ideas, and other features of scientific papers. They will lack only the nouns associated with the topic. The scientific author will eventually be able to supply topic nouns to the computer and see the scientific paper produced automatically."

They then offer an experimental template:

"Over the past __________________, a number of studies have appeared which use ___________________ methodologies to evaluate __________________. Examples include ___________________, ____________________, and ________________. Studies of this kind involve theory, observation, and manipulation of ___________________ in contrast to studies on ___________________ or on material, social, ..." The template continued at some length.

The authors are Nick Trendennick and Brion Shimamoto of IBM's Thomas J. Watson Research Center. This proves that there are some good things to say about IBM and its people.

HUNTING THE HALGOL SNARK:

You see, when they found the Snark, it was a Boojum. In the last newsletter we set out all the rules to construct the template which would then be used to compile non-parenthetical (math) expressions. How many of you realized that if you can program an algorithm to construct the template, then you don't need the template? The Applesoft program an page 24 of the last issue is the algorithm to construct the template, except for negation and exponentiation which were overlooked, as noted earlier.

And a 68000 can, in assembly language, execute that algorithm at blinding speed. This raises the quettion: why did we mislead you as to our intentions?

We misled you so that many of you would follow the logic of how we planned to construct and use the template. We believe that many of you did. Do you realize that we were, in fact, describing how to write

Page 25, Column 2

(a portion of) a compiler? If we had told you what we were up to, 340 of the 354 readers we mailed newsletter #20 to would have immediately skipped over that portion of the newsletter.

Heck, everybody knows compilers are difficult to write. It happens not to be so these days. Programming the 68000 in assembly language is in many ways easier than that Applesoft program. How long did it take us to write the program in Applesoft? We didn't write it in Applesoft!

We wrote the program an our CBM 8032. Because the 8032 has a screen editor, that's why. The Wang 2200 with its line editor would have been an acceptable alternative, but we don't have many customers with Wang 2200s. After we had the program working on the 8032, we translated it onto the Apple.

We have since modified the program - on the 8032 - to permit both forms of negation. We are currently looking at the possibility of adding exponentiation.

A SMALL CONFESSION:

Rule #1 in developing HALGOL is that we have to develop a useful problem-solving language which runs as swiftly as is possible. Rule #2 is that we never deviate from rule #1 except during I/O operations, including program editing. Rule #3 says we want to make HALGOL as friendly as is possible given the constraints of rules 1 and 2. This implicitly means to make the language as much like BASIC as possible, because there is general agreement that BASIC is the friendliest programming language (and environment).

As we spend more time thinking how to make HALGOL Look more like BASIC, it becomes evident that we can find ways to make it more similar than we had earlier thought was possible. What we are doing is introducing additional layers of abstraction to accomplish this purpose. The penalty is that the program size does grow some, since we have to carry around the "source" with us as well as the HALGOL run-time primitives.

A really complex BASIC program of, say, 20K bytes might double in size or even triple. Somehow this doesn't worry us as such as it once might have. Remember, we plan to offer a module which will 'strip' the "source" code, leaving only the run-time primitives. This should be done only after the program is completely debugged, of course.

The prediction an pages 2 thru 4 was written three weeks ago today. In the past three days we have seen Mattel's most recent quarterly results, showing

Page 26, Column 1

horrendous losses. Atari has been bleeding heavily for some time. In this morning's L.A. Times business section, Texas Instruments reports that it expects to report a loss of as much as $100 million (!) in its second quarter, due to a "sudden and unanticipated" downturn in its home-computer business. Oh, yes: we pass a Radio Shack store in Tustin every morning on the way to work. There is a large hand-written butcher- paper banner in its window today announcing "50% off on all Intellivision!"

We did explain to you recently that there was no way that Commodore could affect a corporate giant like Texas Instruments, didn't we? T.I. will doubtless stage a comeback using that exciting new 99-2 that we just read about in BYTE magazine.

Has everyone noticed that neither Mattel, nor Atari, nor T.I. have fully automated factories? And that all three are losing money heavily? Have you noticed that Commodore continues to be highly profitable, and has a fully automated factory? We have not seen financial results for Timex or Sinclair, but the ZX-81 (Timex 1000) are built in fully automated plants and the British press reports that it costs about $13 to turn out one of those little jewels.

Can you imagine how loudly mild, unassuming Jack Trameil is laughing as he reads the financial reports of his U.S. competitors?

By the way: we have been informed by a Commodore observer that the pact between Commodore and Zilog is heavily weighted in Commodore's favor and that Jack would have to be a fool to buy Zilog. We don't think Jack is a fool.

AN OVERVIEW OF RIGID DISK INTERFACES

by LeRoy E. Lundberg
Staff Engineer Knudsen Systems Inc.

"The singularly most important product for me at NCS in Anaheim was Maxtor's 380 megabyte 5 1/4 inch Winchester disk drive. The importance of this product was not even diminished by colleagues who questioned whether the heads in the show drive were functional 3380 Whitney technology sliders. A real disk drive now exists in a 5 1/4 inch floppy-disk compatible package which can perform as well as a large 14 inch Winchester technology disk drive. The weight and power consumption are reduced by a factor of 15 as compared to a 14 inch drive.

"The Maxtor drive could easily find a place on my desk

Page 26, Column 2

in place of the old Apple floppy drive [you'll need three thousand DOS 3.3 floppies to back it up, LeRoy - FNE]. Unfortunately, it is not possible right now to plug such a device directly into the Apple II computer.

"This discussion will first cover the current popular interface standards and then outline methods of interfacing rigid disk Winchester drives to the Apple II computer.

THE SMD INTERFACE:

"The Storage Module Drive interface was originated by Control Data Corp. (CDC) for their large disk drives and was based upon a definition of two flat interface cables ("A" and "B") which ran from the disk drive to a minicomputer controller and then to a computer. This interface has been in popular use since 1975, and allows data to be transferred at 9.6 Megabits/sec. The SMD interface is currently supported by most 14 inch removable and non-removable disk drives.

THE ISI INTERFACE:

"The Intelligent Standard Interface was recently introduced by CDC, and is capable of transferring data at 10 to 50 Megabits/sec. This interface also appears to be geared to the large minicomputer user. If it is successful it should supercede the CDC SMD interface.

THE SASI or SCSI INTERFACE:

"The Small Computer System Interface is the upgraded Shugart Associates System Interface, accepted and renamed by the American National Standards Institute. Although now an ANSI standard, this interface is not widely used. A review of 25 leading 5 1/4 inch Winchester disk drive manufacturers found that only two of them used this interface.

THE ST506 INTERFACE:

"The ST506 interface is a spinoff of the Shugart Associates SA1000 floppy disk-compatible 8 inch Winchester disk drive, first introduced in 1979. While important differences in timing and data rates exist, the remaining signals have enough similarity to run either an 8 inch floppy disk drive of the 5 1/4 inch Seagate Technology 6.4 Megabyte Winchester drive.

"The review of 25 leading 5 1/4 inch Winchester manufacturers found that 13 of then use the ST506 interface, clearly today's most popular interface for 5 1/4 inch Winchester drives. The basic specifications include: 5 Megabits/sec data rate, open collector outputs, differential signal inputs, modified frequency modulation (MFM) recording, and a data format which defines both specific address-mark bytes and ID fields.

Page 27, Column 1

THE ESDI INTERFACE:

"The Enhanced Small Disk Interface is used by companies such as Maxtor to achieve a 10 Megabit/sec transfer rate. The ESDI specification defines a low cost interface which maintains compatibility with the ST506 de facto standard. The primary advantages of the enhanced standard over the original ST506 are: the ability to select 16 heads rather than 8, the use of NRZI recording rather than MFM, and placement of the data separator in the disk drive rather than in the controller [this is compatible? - FNE].

THE APPLE II INTERFACE:

"The Apple II interface is built around modified Shugart S400 floppy disk drive electronics and uses a data compression algorithm to write data to the disk. This originally unique interface has been generalized by several disk drive manufacturers who are now producing Apple II 'look-alike floppy disk' drives. Still, interfacing an Apple II computer to a rigid disk Winchester drive requires more than just understanding and choosing one of the previously listed interface options. Utilizing the existing Apple II DOS in order to stay compatible with existing software presents another major difficulty. Modified DMA into the Apple's memory and default commands within the DOS are among the methods used to maintain compatibility.'

(Knudsen Systems Inc. is a supplier of plated media for rigid disk drives - FRE,)

OPERATING SYSTEMS STUFF:

As has been reported in several publications, including EET and Infoworld, the CP/M folks have (according to one account) announced that they have won the war with CP/M-86 against MS-DOS (aka PC-DOS). (They have?) So, they are naturally supporting MS-DOS so people will still buy their languages. It should be noted that Microsoft has not found it necessary to support their languages on CP/M-86! Not to worry, folks, the CP/M folks have announced that they are really going to win with Concurrent CP/M. Using Concurrent CP/M one can run as many as four application programs simultaneously (well, concurrently). In other words, Concurrent CP/M is a multi-tasking operating system. You know our opinion of multi-tasking systems.

Well, we have just changed our mind. With Concurrent CP/M we can load four copies of a word processor and get this newsletter done four times faster! What a wonderful idea! How have we managed to overlook the obvious benefits of multi-tasking up to now?

Page 27, Column 2

Actually, Concurrent CP/M may go over very well. We can think of some very sexy demos that could be put together to dazzle the unwary buyer (analogous to the multiple-window demos that are dazzling folks right now). And the folks who sell memory expansion boards are going to love Concurrent CP/M! But the casual computerist who uses his/her Computer one or two hours a day needs Concurrent CP/M like a hole in the head.

We call your attention to Infoworld, 27 Jun '83, page 14. There we find the following: "A big surprise on the computer is the transparency of the operating system. The operating system is there, but you are almost never aware of it..." People, that is how we would like to hear the HALGOL operating system described someday. The best operating system for the non-full-time computer user is the simplest, most invisible operating system that will do the job.

What computer was Infowarld writing about? The IBM PC with Concurrent CP/M? No. The Tandy Model 16 with XENIX? That's close. Infovorld was writing about the new lap-size portable that Tandy is selling, the trash- 80 Model 100! Moral: if you want to find a good, simple operating system, find a single-user single- tasking computer.

OUCH!

Shortly after you receive this newsletter we will be having an outside contractor stuff and wave solder a run of 100 'Stuffer' boards. This is a planned preliminary to similar activity involving the DTACK Grande. (Shades of Arab, Alabama!) Ouch? Well, it seems that nobody who uses wave soldering bothers trimming the leads on the I.C. sockets. If you grab hold of a wave soldered board too hard you will exclaim, "Ouch!"

It now appears that the first 20 hand-soldered Stuffer boards will be sold out well before that first wave solder run will be available so there may be delays of up to 30 days temporarily on delivery of the Stuffer. Come to think of it, this will mostly affect those who have sent in orders before reading this! Oh, well, please make allowances anyway, O.K.?

THE PHASE ZERO INFO PACK:

Apparently they don't have one. Motorola did Phase Zero a 'favor'. They are listed in the Motorola 'blue booklet' as a source of 68000 software. All over the world, executives are having their secretaries make up a form letter and request information from everyone on that list. Phase Zero round-files all such requests.

Page 28, Column 1

Come to think of it, what can you say about a cross- assembler that would be useful and informative to the typical person making an inquiry, who has not yet learned anything about the 68000?

We are now making a product, the Stuffer board, which is priced at about the same level as the Phase Zero cross-assembler. If we receive any requests for information on that board, we will round-file the request. For reasons which are precisely analogous to Phase Zero's.

We have received several letters complaining about Phase Zero's lack of response to a request for information. We generally reply that they will respond favorably to a check for $95. (If you want something for nothing, apply at your local welfare officer or to the Red Cross.)

It disturbs us at times that we are manufacturing a product about which many (most?) potential customers have very little knowledge. On the other hand, those same customers need a great deal of knowledge, and almost all of them are well aware of the fact. One of the purposes of this newsletter is to fill in some of the gaps not covered by the Motorola spec sheet and programming manual or by sitting down in front of a cross-assembler and turning out some code or by the other traditional learning methods.

LATE NEWS ON T.I.

It seems that we were not the only one to notice T.I.'s announcement of an impending $100 million loss. Monday the 13th of June proved to be unlucky for T.I., since its stock dropped 25% in value just in that one day! That corresponded to a perceived drop in the value of the company of $940 million. This info was reported in the L.A. Times the next day by Kathryn Harris, Times staff writer. On the front page, no less. There was a chart in the business section under a photograph of Coleco prexy Arnold Greenberg, shown seated at the keyboard of the new Coleco "Adam" computer. No other info given.

On page 54 of Electronics magazine, dated 16 Jun '83, is a News Brief item about the "Adam", asserting that it has 80K RAM, a word processor and CP/M in ROM, a 500K tape memory all for $600. Now, here comes that part which we do not believe, even if Electronics magazine printed it: "and - most surprising for a package priced so low - a daisy-wheel printer."

Oh, yes: the Times chart showed that Commodore stock has climbed from under $15 per share to over $58 per share in the past 18 months. Commodore has just

Page 28, Column 2

dropped the wholesale price on its Model 64 from $360 to $199. Since we believe it costs Commodore only $63 to make the 64, that still leaves them a nice profit margin. Remember, we told you that sweet, cuddly Jack Trameil couldn't possibly affect a corporate giant such as T.I. (This is the only publication ever to describe Jack Trameil as sweet and cuddly!)

FLASH! DISK ERRORS?

ON DISK READ ERROR, LOOSEN THE WRITE PROTECT TAB!

STUFFER INCOMPATIBILITY:

About a week after mailing the last newsletter, our test technician walked up to us and observed, "I see in the newsletter that the Stuffer board isn't compatible with the Apple IIe." That's right, we replied, the board was designed before the IIe came out. And we've only had the interface specs for a few days. So, the IIe is incompatible. "I'm sorry to hear that, especially since I have just checked out three Stuffer boards on the IIe in test. You do remember giving me the IIe because you didn't like the keyboard, don't you?" replied our tech. Um, maybe it's incompatible?

A 68008 BOARD?

Persons who might be interested in a 68008 under-the- hood Apple compatible board are urged to write us. Please explain your preference for a $350-$400 static RAM and Eprom board versus the usualy high-priced loaded-to-the-gills DRAM board just like all the other available coprocessors. (Are people really interested in an inexpensive software-compatible learning tool or are they just looking for another excuse to hang lots of DRAM under the hood?)

OUR USUAL GOOF: We used the term 'RAMDISK' in our ad copy before we remembered that it was copyright of Axlon. Our apologies to John Vurch, Axlon's prexy. We won't do it again, honest! But it is too late to stop the ads that will appear around July in Nibble, Call-Apple and Peeling II (but definitely not Micro).

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, II+, III, soft, LISA: Apple Computer Co. Anybody else need a 158th 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