Issue # 19 DTACK GROUNDED Newsletter - May 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

BACK IN BUSINESS:

Well, back in the hardware business. Down below you can see a prototype Stuffer board which works, although the connector for the 40 wire cable to the DTACK board is on the wrong side. (We did not provide adequate info to the outside consultant who laid the board out for us.) The production prototype, with connector on the correct side (but no solder mask or silk screen) can also be seen. It also works.

What, you ask, is a Stuffer board? Well, it's like this: if one is using the DTACK board to generate complete HIRES graphics pages on the DTACK board, it requires about 115 milliseconds to transfer the 8K graphics image to the Apple. Some people think that's too long. So one of the little projects we had in the back of our head was an interface board which would enable the 8K graphics image to be transferred at DMA rates. This is the sort of low-priority thing one thinks about but never really does. Right?

Page 1, Column 2

On page 8, par. 3 of issue #11 we mentioned that the son of a long-time cohort was close to graduation as an electrical engineer. It turns out that Cal State Disneyland disallowed some transfer credits so the degree will be postponed until late '83 or early '84. In the meantime, it became obvious last fall that we had more work than your FNE could personally handle. So we hired this student, for now on a part-time basis, and gave him the title 'Project Engineer'.

Since Project Engineers need a project to work on, we decided that the graphics DMA interface would make a dandy beginning project. We then discovered that our student-employee had an onerous, time-consuming design project coming up, called the 'Senior Design Project'. After making the horrifying discovery that our intrepid new employee intended to build a dingwhilly totally unrelated to the business of his new employer we had a nice chat. The chat was an the desirability of getting paid for developing his Senior Design Project. We even pointed out that he was now a professional and as such should expect and demand that he be paid for his design work!

About this small world we live in: as of right now we have only sold one DTACK board to a full-time professor in the Southern California area. And that professor bought his board over a year ago, nearly a year before our new Project Engineer joined us. Guess who our new P.E.'s faculty advisor for his Senior Design Project is? Riiight!

(Continued on page 18)

Page 2, Column 1

EXPORT PROBLEMS:

If you really want to know how fouled up the U.S. export embargos on technology are, see page 42 of Electronic News, 14 MAR '83. For those of you who do not have access to EN, we will summarize the story:

It seems that Du Pont was not permitted to export its model 8800 liquid chromatograph (a clinical instrument) because it contained an 8080 microprocessor. Well, it just so happens that the Russians have been making a reverse-engineered 8080 for some time now (not a copy; there's a difference!). Photographs of the mask of that Russian '8080' were widely published in 1980, which suggests the part may have been available earlier. Since the Russian '8080' is available over the counter, Du Pont purchased some of these Russian microprocessors and tested them in their model 8800. They worked perfectly.

So Du Pont re-applied for an export license for their model 8800 with a Russian imbedded microprocessor. They were turned down. They applied for an export license for the model 8800 without a microprocessor. They were turned down.

If anyone can make sense of this mess, would you please explain it to us?

Let us explain the current status of our export limitations. First, there are no limitations on sales in the U.S. or Canada. Elsewhere, there is a $500 limit per customer, the limit applying to the total of all sales to that customer. This total limitation is enforced by entering all of the export declarations into a computer and doing the obvious cross-checking.

There is no limitation an shipping anything whose value is $499 down anywhere or to anyone. We would not like to test this point by shipping something to a Mr. Andropov, address the Kremlin, however.

Do we feel that we were compromising U.S. security by shipping our DTACK boards overseas (inadvertently against regulations)? No. The only technology on our boards is Japanese RAMs and a microprocessor which is also made in Japan. True, Motorola has a short lead in making the L12, but L12s are openly sold across the counter and about 250 L12s could fit into one diplomatic courier pouch. (Is there any naif amongst us who does not know that those pouches are not inspected as they enter and leave the country?)

Can we sell, in the U.S., to foreigners? Of course. There is no requirement for us to check citizenship papers for any sales in the U.S. (or Canada).

Page 2, Column 2

How much can we sell to West Germans before we break the export regulations? That depends on how many independent households there are in West Germany. Let us be conservative and say there are 10 million. We can sell up to $499 worth of computer gear to each household, or nearly five billion dollars total. Without breaking a single export regulation.

Isn't that a bit um, unusual? Yes it is, but the regulations were not written with our sales policies in mind. We are among the very few companies, at least in the computer field, which sell overseas direct to the end user. Almost everyone else (and certainly anyone doing a volume business) sells through distributers. The export regulations were written with that sort of exporting in mind. There are advantages and disadvantages, from our point of view, to the way the regulations work.

If we sold through a distributor (and our foreign sales were greater) then we could, after the expenditure of time and money, get an export license. We know; others making similar products have export licenses. In fact, we have been urged to do just that - without raising prices to the end user, of course! For the umpteenth time, we really do have one price for everyone. That includes distributers, which is why we don't have distributers!

On the other hand, by not selling through distributors we theoretically can sell nearly five billion dollars' worth of computer boards to West Germany legally and without an export license! Provided no one customer purchases more than $499.

Let us suppose that you are a West German who has already received a DTACK board (shipped to you against regulations, of course). Suppose we come out with a $100 or so accessory which will work with that board. Can you buy it? No. Your name is already in the computer. Can your neighbor buy it, explaining that he is purchasing it for you? No. The export form has a blank for the consignee and for the end user. Can your neighbor buy it, period? Of course! As long as we have no information that he is not the end user, your neighbor is as legal a customer as anyone. And, from six thousand miles away, how in the heck are we supposed to know who is a neighbor of whom?

And besides, we have already sold to perfectly legitimate neighbor-customers in this country who liked their neighbor's DTACK board and purchased one for themselves. We have nothing against neighbors in this country or elsewhere and we love checks!

We are home free, for individual customers and for products which cost less than $500. That fits certain accessories and also a 68008 board, if we ever get

Page 3, Column 1

around to building one (that is not certain at this point). For our standard DTACK boards, that poses a problem because they cost over $500.

If we create a special export model, to be sold less the 68000 and less the RAM, there is the problem that the end user will have to be able to obtain those parts, and also to install and test them themselves. Since West Germany and (secondarily) Britain have shown the most interest in our boards, what is the availability of L12s and 100nsec Toshiba 2016P-1s over there. What comments do you, you rotten Godless commie foreigner, have in regard to this problem?

(The one thing we can't do is sell multiple packages which combine into a fully loaded DTACK board. The folks supervising export activities are ignorant but they are not stupid! Every now and then they pick someone to make an example of, and we do not want that someone to be us!)

Back to Du Pont: that story case out during Robert Lovell's (Du Pont's government affairs manager for their Clinical & Instrument Systems division) testimony before the House Foreign Affairs trade subcommittee. His concluding remarks: "We don't want to be antagonistic, but we do need some relief in order to compete in world markets." Us too, Robert.

OOPS! (VARIOUS):

In the last newsletter we had a few (!) goofs. First, on page 20, par. 3, we said "we also had to multiply each constant by LOG (e)!" That should have been LOG base 2 of (e). So if you will turn to that page and write in a subscript 2 after LOG, things will be better.

The next thing we did wrong was go to press without having our biological spelling checker program, Ms. Kathy Meziere, proof about half the pages. The difference can be, um, ascertained. Just one of the problems is that there are certain words which we misspell every time when typing. System, for instance, is always mistyped as 'systme' on the first pass. We are well aware of this, and reach for the backspace key almost as soon as the word comes to mind. Another example is the word 'lose', which we always mistype as 'loose'.

Now, we need a biological spelling checker to catch that one since 'loose' is properly spelled... but the wrong word. So you should not be surprised to see this mistake at the end of page 27, even in boldface. Still, the appearance of that goof twice in one paragraph on page 30, col. 1 is perhaps excessive. And we do not want to hear about the innovative spelling "have'nt" elsewhere.

Page 3, Column 2

We completely fouled up the origins of the word 'mortgage' in the last issue, and we do mean completely. The reader may by now be getting the (correct) idea that we are stronger in microprocessor technology than in our knowledge of Romance languages. Sigh. Please forget about the origins of the word and concentrate on the fact that there was a time before mortagages were invented, O.K.?

(Lest the reader get the idea that this publication is totally fictional, the corporation having trouble with its accountant was AM International, the deposed corporate head was former U.S. budget director Roy L. Ash, the fired accounting firm was Price Waterhouse and the amount of money in dispute (it was the timing which was in dispute, really) was $203 million. The account we have on file was printed in the business section of the L.A. Times, bylined Martin Baron, Times Staff Writer.)

And what follows is something that just plain inadvertently got left out of the last issue:

HANDY HINTS FOR NEWSLETTER EDITORS: Before poking fun at a correspondent, even anonymously, first be sure whether the correspondent is pulling your leg. It's like this: we got this irate letter, two pages worth, which we took seriously. How else? The writer was a German, after all. Germans don't have a sense of humor! The book "500 Years of German Humor" is even thinner than the one entitled "Italian War Heroes." Sigh. So would all of you take out newsletter #16, turn to page 22 and cross out the paragraph beginning "HANDY HINTS FOR LETTER WRITERS."

While you are at that, would the two dozen people who have asked us recently about the status of the 68010 please read the paragraph opposite the one you are crossing off? The one in the first column? Hm, page 22, huh? Didn't we say something about stuff past page 20 in the last issue?

Nils, LISA does too come with a hard disk. It doesn't show up in the promotional photographs for the same reason DEC doesn't show their floppy disks in their promotional shots of their Rainbow. Haven't you ever wondered how the DEC machines could do anything without mass storage? Or cables to the mass storage? And have you ever seen the big black box in a promotional photo of the VIC-20? Or all the cables?

What we wonder about is how DEC can get away with calling a computer styled in beige on beige on beige a "Rainbow?"

Page 4, Column 1

COMMODORE WATCH:

Things are SNAFUd at Commodore U.S., as usual. Commodore continues to sell every VIC-20 and 64 it can make, and it can make a lot of them! There are now more than one million VICs in the field and the way things are going it will not be long before the two million mark is passed. The 64 sales level is a bit lower. We think that is because the 64 is designed for automated production, and it takes time (and money) to set up (or expand) an automated factory,

In other words, Commodore low end sales are now limited by their production capacity, which we have known for some time. But because we were not paying real close attention to Commodore, we got scooped by Ron Jeffries in his Jeffries Report recently.

You see, the story in Electronic News on the Commodore-Zilog pact specifically asserted that the price which Commodore would pay Zilog for mask rights to the Z8000 was the purchase of a certain number of Commodore chips, to be made by Zilog. We didn't know what that meant, and in fact it didn't make sense (to us).

We knew that one of the production bottlenecks in making more low-end Commodore units was that the production capacity of MOS Technology, Commodore's captive I.C. manufacturer, was saturated. In the meantime, there sat Zilog. Zilog not only needed a design win and something that looked vaguely like a second source, they also needed something to produce! According to Ron Jeffries, about 90% of Zilog's I.C. fabrication machinery was sitting idle. So Zilog is (or will soon be) cranking out lots of sound generator chips and graphics controller chips and...

Wait just a minute! That doesn't sound like things are SNAFU at Commodore! you say? Well, you are partly right. The VIC and the 64 are doing well and will be doing even better if the Zilog deal works out. And, face it, those two little jewels ire paying the bills at Commodore just like the Apple II pays the bills at Apple.

But, like Apple, the folks at Commodore have some pride in their 'up market' products also. It is in this area that things are SNAFU, cubed! The new goodies previewed at Comdex seventeen months ago still aren't even close to being ready for release! Commodore now claims that the new newer machines using the Zilog 8000 will arrive hard on the heels of the old newer machines, given realistic completion dates for those old newer machines.

In the meantime Commodore's dealers for the 'up market' machines are up in arms because they can buy 64s at their local K-Mart cheaper than they can buy them from

Page 4, Column 2

Commodore. And Commodore has nothing to replace the 64 with at this time (the 8032 is now a dead issue).

Back at corporate headquarters, Commodore held its traditional reorganization-of-the-month. When the smoke cleared, the persons responsible for the enormously successful VIC and 64 campaigns seemed to be downgraded and a newcomer named Robert Lane seems to have emerged on top. Mr. Lane's forte appears to be the ability to 'run a tight ship'. Translation: "You can't buy another package of paper clips now, you just bought one last year!"

This is obviously the most important management ability to bring to the fast-moving personal computer industry.

At least one other Commodore watcher thinks the smart thing to do would be to chuck the old new high-end machines and concentrate on bringing the Z8000 babies to market. You will recall that we told you, back in newsletter #4, that the Z8000 is a very good microprocessor, much better than the 8086 and second (it that time) only to the 68000. What we did not tell you, because it did not seem important at the time, is that the Z8000 chip is much smaller than the 68000. That means the Z8000 can be produced in 100,000 quantity for about five bucks! (In the 1983-4 timeframe.)

If Commodore got its act together, they could make big trouble in the small computer industry! Our bet is they will continue to do well at the low end of their line and that confusion will continue to reign supreme at the 'up market' end.

Exhibiting admirable restraint, we will not extend that observation elsewhere.

VICs, 64s, IBMs und DTACK:

Now that we have the 68000 running on the Apple II, with some demo and some third party software support, we are being increasingly badgered to offer the DTACK board on other computers. For the record, this is exceptionally easy to do from a hardware standpoint (see page 1 of newsletter #6, for instance). It is becoming increasingly evident that this is a very difficult task when it comes to software support.

Therefore, we are going to concentrate an bringing up HALGOL on the Apple rather than dilute our efforts trying to host other computers for now. Once HALGOL is workable, we will have more to offer owners of other computers. Perhaps more third party software will assist in this regard. A BASIC from Phase Zero certainly would!

Page 5, Column 1

In the meantime, it is interesting to note what kinds of requests we get. While there are very few computers for which we do not receive the occasional request, the VIC-20, the CBM 64 and the IBM computers are mentioned most often. We receive very, very serious requests to adapt the DTACK board to the VIC-20 (which surprises us) and equally serious requests for the 64, (which does not surprise us). The requests come from owners of the respective computers, which should be no surprise.

What is a surprise is the sort of requests we receive to 'host' the IBM pc. Hardly any of them come from pc owners! These requests usually come from someone with a commercial ax to grind, or from someone who is thinking of buying a pc, or even occasionally from well-wishers who think DTACK would prosper mightily by supporting the pc.

Here is our viewpoint: The VIC-20 is simply too limited to be of practical use as a DTACK host. The 64, once better peripherals are available, is nearly as capable as the Apple II and even exceeds the Apple II in some areas, such as sprite graphics and that really excellent sound generator chip.

Unfortunately, the 64 is turning into a 64K byte rock-shooting vehicle for drooling children (remember when a computer featuring 64K RAM commanded respect?). If one wants to read about the 64 these days the magazine of choice is COMPUTE!. Have any of you seen a recent issue of COMPUTE!? You could read the whole issue and never once find a reference to anything with 16 bits! What's worse, have any of you seen COMPUTE!'s advertising rates lately? Would you believe nearly four thousand dollars for a full page ad?

(It is a damn shame to see a computer as good as the 64 headed for a kiddie-toy rock-shooting ghetto. It deserves better.)

Now, about IBM: almost all IBM purchasers are first-time computer buyers. When people buy their first computer, they are generally overwhelmed by its capability. This stage lasts from one to three years (or forever). The persons who begin pushing the limits of their computer will eventually find those limits, and start becoming interested in something better. Which is where DTACK might logically come in.

We do not foresee any significant number of IBM owners becoming interested in greater performance before next year. So that is our timetable for now. (This timetable could be modified if someone needed our boards to work with the IBM and was capable of their own software support.)

Page 5, Column 2

OPERATING SYSTEMS:

We spent quite a bit of time a few issues back writing about operating systems. At the time we felt it was necessary because a lot of hogwash about them was being printed in the personal computer media. This placed us in the unenviable position of telling you things which were frequently diametrically opposed to what you were reading elsewhere, BYTE magazine for instance. Unfortunately, at the time we had little direct evidence to support our assertions, which placed us in the uncomfortable position of saying, "trust us!"

We are enormously pleased that Electronic Design magazine has just published, in its Mar 17 '83 issue, a special section on microcomputer operating systems. Forthwith, a few quotations which should not appear totally unfamiliar:

(page 122) '...even the most advanced micros rarely handle Unix as well as the PDP-11 computer an which Unix evolved. Two microcomputer characteristics are responsible for the apparent discrepancy: bus-oriented architectures and the relatively slow speed of Winchester disks... though Winchester disks, which were developed for micros, may seem like sports cars when compared with a floppy disk, even the fastest Winchester crawls at a snail's pace when compared with a PDP-11 disk. Since Unix found its roots in the PDP-11 and later the VAX series, both of which have extremely fast disks, the operating system relies heavily on code swapping - a definite liability when a Winchester supplies the mass storage."

Like we have said, several times yet, Unix absolutely requires a big, hard, fast disk. Winchesters are just hard and sometimes big. Fast they ain't. We have not tried picking on Winchester speeds because most of our readers are most familiar with Pet or Apple floppy disks. Now, Pet and Apple floppy disks are about five times slower than other floppy disks because each company chose not to use a separate floppy disk controller. (Jack Tramiel and Steve Wozniak are both cheapskates when it comes to floppy disks.)

Still, we are glad it was Electronic Design and not us which wrote, "...even the fastest Winchester crawls at a snail's pace when compared to a PDP-11 disk."

Have some of you begun to catch on why we assert that Unix is not going to conquer the small computer world?

WE GET MAIL:

We are going to condense and paraphrase some recent mail, along with our comments:

Page 6, Column 1

"Loved newsletter #18. Agree it is too long." Make up your mind, O.K.?

"#18 was too long. Took an hour to read!" Rebecca of Sunnybrook Farm maybe takes an hour to read. Newsletter #18 had six pages on transcendentals and three different sections on HALGOL. You actually read all 32 pages in an hour?

"My 24 pound cat has resumed his claw-sharpening practice an simulated DTACK boards (made with DTL, may you be old enough to remember it)." Good luck trying to get that DTL logic to run at 12.5 KHz, much less MHz. And our attack teddy bears are dusting off a French recipe for something called 'alley-lapin stew'.

"Issue #18 confirmed my suspicion: FNE is an Englishman!" Our biological spelling checker, who is an Englishperson, is still laughing! By the way, she happens to be from Cornwall. We once asked a Londoner how far it was from Cornwall to London and were told, "It is two hundred years from Cornwall to London!"

"Please print a catalog of available equipment in each newsletter." Right now it would be a short list. We make a Pet or Apple compatible board, 4K to 92K static RAM, and a 128K memory expansion board. In a couple of months, the list will be longer. Why not write for what we call an info pack, suitable for persons thinking of actually buying something?

"We worship God, not Martin Luther." We knew that, honest! But Martin has a 500th anniversary coming up which lots of people will be celebrating, including the communist East German regime (presumably washed for the occasion so that they will not be dirty communists). For some reason, the Catholic church will not be participating in that celebration ...

"Read with interest your comments on running a program for the first time. Now, about your memory test programs... " You will please pay attention to what we say, not what we do.

"Dear M.C.P.: ...although DTACK GROUNDED remains male dominated, its quality is above average" (a female subscriber). This constant adulation from our many female subscribers is liable to go to our head!

"Your newsletter is interesting even though I do not always agree with you." WHAT!? You disagree with us? Guards!!

"Please send current literature and prices for your current version of the DA607P noise monitoring system." We must have a word with our filing clerk.

"I realize you are prejudiced against Pascal... " How

Page 6, Column 2

can you say such a thing? Are we prejudiced against UCSD Pascal for the Apple (from Apple), which only has single precision floating point, or UCSD Pascal for the Apple (from Softech) which also has double precision floating point and is therefore useful? Are we prejudiced against Pascal as it was invented, which does not permit random access files, or against Pascal properly extended so that it is useful in a real world environment? Maybe we just prefer an interactive programming environment such as that provided by BASIC?

"If I were in business, I would be expanding the newsletter and staffing it to create much more than a podium for the DTACK viewpoint. There appears to be need of a forum for those who have too long tolerated the spreading of fertilizer... " If you were in business, you would go broke. When we mailed newsletter #18, we had just over 300 paid subscribers. The then price per issue of $2.50 paid printing and mailing costs and left a slight 'profit'. Just exactly how would you pay those staffers? As for creating a wider forum, let us point out that we have already turned down one sincere suggestion that we help save the world (#12, p13, par 1 & 2).

RELIABILITY, ANYONE?

In a recent bull session an Apple type stated that prior to purchasing a certain piece of equipment, his Apple would 'go down' sometimes when his refrigerator switched on or off. If he was running BASIC, he would lose his program 5% of the time. If he was running Pascal, he would lose it 95% of the time(!). But now that he has purchased that certain piece of equipment, the problem has gone away!

When we first began to make extensive use of our Apple, we began to lose disks left and right due to data errors. On one memorable occasion we lost 6 hours work at one fell swoop (what the heck is a fell swoop?). We bought a certain piece of equipment, and the problem went away. Yes, it was the same 'certain piece of equipment.'

The piece of equipment is a SOLA mini-ups, 250VA rating, part #63 - 13 - 125. This will set you back about $250, plus local sales tax. Contact Sola Electric, 1717 Busse Road, Elk Grove Village, IL 60007. Phone (312) 439-2800 for the location of your local dealer.

Most of you have seen the ads for power outlets which, one is assured, have goodies which grab big power transients, spikes of thousands of volts, R.F. interference and such. In our opinion, forget it! The first time we installed one of those, turning on a lamp (isolated by wonderful gadget) caused the 'protected' Apple II to go out to lunch!

Page 7, Column 1

As an incidental side benefit, the Sola is also a voltage regulator and thus will provide protection against 'brownouts'. (Actually, that is just backwards: the Sola was designed to regulate the line voltage and to (largely) eliminate harmonic distortion on the line. The excellent noise rejection properties are an incidental consequence of the design!) If you have an Apple II and you do not like to lose disks (or programs), this should be considered a necessary piece of equipment.

Here is the proper use of this device: It should be plugged into a power outlet. A multi-tap power strip, perhaps with a master power switch, should be plugged into the output of the Sola. Now, this is important: all repeat all of the line-powered parts of the computer system should be plugged into that multi-tap strip. That includes the computer, the printer, the CRT/monitor, the separate power supply for the DTACK board and so forth. This will provide proper line isolation. Do it!

KITS, QUALITY, ARROGANCE:

When we were much younger, we built quite a few electronic kits, almost all Heathkits. In our private moments, we are philosophically attuned to the concept of kit-building and we definitely are aware of the potential dollar savings, and the importance of such economies to the latest younger generation. Despite this, we have no plans to offer kit versions of our DTACK boards. Because several readers have enquired about the availability of kits, we feel an explanation is in order.

Back in the Heathkit days, point-to-point wiring was the order of the day. If a particularly serious soldering error was made, the fix involved ripping out the incorrect wiring and replacing it. Cost: a few feet of hookup wire. If a particularly serious error is made on a DTACK board, it generally results in the loss of the circuit board itself and all of the parts already soldered onto it. This sort of thing is not repairable!

As a natural consequence of the above, few kits are built today. This in turn impacts 'economy of scale'. Since there are few kit builders, it is proportionately more expensive on a per-customer basis to produce a kit. Since we are a small company even for the largest part of our product line, the number of requests for kits his been small - possibly as few as ten during the time we have been selling 68000 boards. Assuming everyone wanted the same kit, you figure the cost per kit if we had to spend, say, 150 hours of engineering and drafting time producing the necessary documentation. Unless you know something about burdened engineering and drafting that we don't, it is

Page 7, Column 2

much cheaper to provide the completed assembly!

The next thing to consider is that not everyone wants the same type kit. The one person would want just the circuit board and the monitor ROMs. So does the next guy... at first. Later he discovers the connectors, cables, the 64 pin 68000 socket and a few other items are hard to find. So he phones us up and tries to negotiate a personalized kit. And that, folks, is a killer for a real business. We are fast becoming a real business, which means that we would need to come up with a polite way to tell that person to (censored)!

But it's worse than that! Not even everybody wants a kit for the same basic product! For instance, we have had exactly two requests for a memory expansion kit (the 128K dingus). No way!

Contributing to the problem is our (hopefully honest) desire to produce a quality product, and our corresponding desire that all of the DTACK products in the field be well built and reliable. Finally, we would have to agree with a thinly veiled accusation (recieved from one reader) that there is a certain degree of (individual or corporate) arrogance in our attitude and policies. Nobody's perfect.

Arrogance, in our case, is a natural byproduct of having so much business that it is highly uneconomical to create, on the spot, prices and policies to suit the desires of a particular individual. Instead, we have to insist that the individual accommodate himself to our usual and ongoing prices and policies. Try driving up to the window at McDonalds and ordering a Big Mac with custom sauce, custom toppings and a custom price...

Perhaps this is a non-sequiter, but we have kept our policy, outlined in issue #2 of this newsletter, of offering the same price and terms to the individual customer that we do to big corporations and to quantity buyers. (And believe us, we got a lot of static over that fact!)

FLASH MATH CHIP NEWS:

The latest mask revision of National's 16081 is providing some parts with only a very few (we are told) problems. They run at 6MHz, of course. The good news is that we, dinky little Digital Acoustics, may be able to buy a sample in 4 or 5 weeks for just $200. When we told the National tech rep that we would buy two at that price, he said they weren't quite that plentiful yet.

Page 8, Column 1

TRUTH IN ADVERTISING:

There are two advertisements running these days which will be of particular interest to many of you. One is a very dignified multi-page ad from National on their 16XXX microprocessor series. You can always tell an ad which is intended to be serious; it will have lots of 'white space'. 'White space' is blank paper containing no information. Yes, we know that National's 'white space' is colored blue.

Anyhow, in this multi-page ad National tells us about the current status of its high performance microprocessor line. We particularly enjoyed reading about the 10Mhz version of their 32-bit processor. Ten megahertz? Thirty two bits?? Would both of you readers who believe that National ad please contact your FNE? We have a swell deal on Florida swamp land.

Intel is one (rare) example of a company which is very careful that its ads are accurate. Now, they don't mind if their ads are sometimes a tad misleading (in Intel's favor, of course), but they are careful about the literal facts. Which brings us to an ad Intel is currently running which features the 8MHz 8087, and asserts that the device performs a double precision floating point multiply in 1.7 microseconds. Here are the facts:

If Intel advertises 8MHz 8087s, then 8MHz 8087s exist. You may even be able to buy one. Now, about that 1.7 microsecond DPFP multiply: that is a typographical error. The actual execution time for an 8MHz 8087 is a tad over 17 microseconds. We think this is an honest (unintentional) error on Intel's part.

Speaking of 8087s, the 8087 is featured on the cover of the current (?) issue of Personal Computer Age. That's issue 2.3. There are a couple of good introductory articles, including one which explains what coprocessors are, etc. If you like the idea of the sort of high performance which is available from math processors but are a little vague on just exactly how they work, it might be worth your while to track down a copy of issue 2.3.

However, we suggest that you ignore the repeated assertions of Personal Computer Age's editorial staff that plugging an 8067 into the IBM pc turns the pc into a mainframe. That staff isn't stupid, just ignorant. It is totally irrelevant that the ad on the back cover features shooting rocks (very slightly disguised as alien beings) using, presumably, laser beams. Why does the last paragraph on page 6 of issue #11 of this newsletter come to mind when we see the term 'mainframe' misused?

Page 8, Column 2

TIMING DIAGRAM BLUES:

A timing diagram of our DTACK board is something which has been in demand, by our customers and by non-customers, since we first announced that we were going into the 68000 business. We have very bad news for them 'demanders'. There ain't none. What? You don't believe it?

Believe it! No timing diagrams for the DTACK board exist, at least at Digital Acoustics. One reason is that our board really is simple, and in a simple system you identify the most speed-critical path, make sure there aren't other critical paths and then you quit! Besides, if we published tieing diagrams, it would be obvious that our board cannot work. If you get hold of a Toshiba spec sheet on the 2016P-1 RAM, you will discover that the access time from chip select to data valid is too slow for our board to work. That is, the spec sheet is too slow. The RAM works fine.

We just love to make boards which work properly. We also love to sell our boards which work properly. But if you want timing diagrams, you will have to draw your own.

SECRET SCHEMATICS:

We have a schematic, nicely drawn an C size vellum, of the interface between the Apple and our DTACK board, and another of the Pet/DTACK interface. These schematics are not secret. You can have one for $5 if you live in the U.S. or Canada, or for $6.50 elsewhere. Be sure to specify Pet or Apple.

We also have a rough schematic, drawn sloppily an the back of a C size Diazo sheet. The pencilled lines are covered with yellow ink. The yellow ink is from tracing the hand-drawn sketch when we checked the printed circuit layout. That is the only schematic of the DTACK board(s) that we have, and no, you cannot have a copy of it even if you own one of our boards. We wish to keep the schematic a trade secret.

The reason we want to keep the schematic a trade secret is that it is the only, repeat only, part of our commercial operation that is a secret. And us girls have to have one secret, right? What's that? You don't believe in secrets? Everything should be open? It's a free country, chum! Why don't you start your own business and reveal all? We ain't gonna.

While you are writing letters to us complaining about how you think our attitude stinks, please send a copy to Hewlett-Packard and Wang Laboratories as well. Like lots of outfits, they don't provide schematics of their computer stuff either. One could do worse than emulate those two highly successful organizations, hmm?

Page 9, Column 1

LANGUAGE PREJUDICE:

We had hoped that a few of the things we say about programming languages would be obvious. Since it has not worked out that way, let us discuss a few of these matters here.

Our viewpoint is that of an individual programmer writing utility programs for his own and also other's use, or writing his own application programs for his own use. These personal application programs would lean heavily toward problem-solving type stuff. We feel that BASIC is the language of choice for individual problem-solving and that assembly language is best for writing utilities.

But please, dear reader, do not think we would carry these prejudices into inappropriate areas. A magazine editor once asked us what programming language we would use for a military systems application requiring 150 programmers for a period of 30 months. Our immediate comment was that we would certainly not use BASIC! The editor did not let us off the hook that easily, but continued to press us regarding our choice of languages for that application. We were forced to admit that we could not make a clear decision. Pascal is too limited for such a real-world application. Modula-2 is Pascal 'fixed' so it can work in large systems applications such as the one at hand (according to Wirth), but it is not yet generally available. Even Ada eight be worthwhile in such a large programming environment.

However, we do not think very many of our subscribers are involved in such large-scale programs. We believe that the sort of programming we do is closer to the sort of programming that the average reader (who programs) does. While we receive the occasional letter reminding us that programming is done elsewhere on a different (such larger) scale, we get very few letters asserting that the writer is personally engaged in such efforts. We believe this justifies our emphasis on simpler languages of which BASIC is arch-typical.

Our definition of 'utilities' is broad enough to encompass what others might call 'systems programming'. The favored languages in this area appear to be assembly, Pascal and C. Those of you who favor C are encouraged to sit down with a text an C on one side and an assembly language manual for the PDP-11 minicomputer on the other side. You will discover that C is the lowest-level high-level language there is; it is largely stylized PDP-11 assembly code.

Since C is such a low-level language we agree that it is a good language for utilities and systems programming. Since it is so closely tailored to the PDP-11 it will be highly inefficient when used with a processor which is not a PDP-11 or not very similar to

Page 9, Column 2

a PDP-11. The 68000 looks very such like a 32-bit PDP-11 (this is no accident) and therefore is nearly as effective a 'C-machine' as the PDP-11 itself.

This brings us to Pascal. Because Pascal, unlike C, is a true high-level language all the excess baggage carried around by high-level languages gets in the way at run-time even when the language is compiled into native code rather than P-code. If you read the same trade journals we do, you will know that the several megabytes of systems software provided with LISA were written in Pascal and compiled into native code. LISA has been criticized as slow in some circles and some of the speed-critical parts of LISA's systems software are now being rewritten in assembly language.

Absent hardware assists or user-writable microcode, assembly language is unquestionably the language of choice if you want to get something done before lunch (right, Nils?). The reason is that absolutely no unnecessary constraints are imposed on the programmer. Data typing? What's that?

It is also true that assembly language programming is harder to learn than a high-level language. But behold the gloriously efficient code one gets after that learning investment is made! Let us make an analogy in the world of music: a grand piano is more difficult to play than the kazoo, but what glorious music one can coax from a grand piano!

And, as we have repeatedly asserted in these pages, it is much easier to program the 68000 in assembly language than other microprocessors you may have encountered. Perhaps you are too lazy or too frightened to even try? In that event, the loss is yours!

Let us refer you to "PROGRAMMING LANGUAGES: History and Fundamentals" by Jean A. Sammet, Prentis-Hall 1969. In the preface, we discover that "...120 languages (are) described in this back. Of this total, approximately 20 are completely dead or on obsolete computers, about 35 are receiving very little usage, about 50 are for specialized application areas, and about 15 are widely used and/or implemented." At 785 pages, this is not a small book. It is an invaluable reference for anyone interested in almost any aspect of programming languages.

If you continue to feel that we are off base, we herewith present you with an invitation to write a guest editorial on the subject. We are not the sole authority and we do not even insist that we are right and that others holding opposing viewpoints are wrong. What we do assert is that so far we have been the only person willing to write up his or her viewpoint for publication here...

Page 10, Column 1

WE GET MORE MAIL:

"...you will already have heard from others about a minor erratum in your discussion of the calculation of TAN(X) an p. 17 in #18. There is a need for error checking since TAN is undefined for odd integral multiples of #PI/2 (the COS being zero there)." Larry W, NY NY

Nope, you are the first to call that to our attention, Larry. We were trapped by the distinction we had made between "infinity" and "undefined". In the first full paragraph of p.19 we pointed out that, although the logarithm of zero was defined (as minus infinity), it was not representable (as a floating point number).

Thanks to your assistance, it is clear that more careful attention need be given to the handling of error messages when calling the TAN(X) function, or when computing the COTAN(X) function by first calculating the TAN, then its reciprocal.

You, and some of our other readers, may be interested to know that we have at least four and perhaps as many as eight math professors and/or PHds, active or retired, amongst our readers. The reason for the uncertainty is that we have a few sneaky-Pete subscribers. Let us explain this: we make a point of reviewing our subscriber list periodically (usually by personally running the newsletter envelopes thru the stamping machine while reading the labels). So we will become accustomed to seeing an envelope for "Pete Katsufrakis, 123 Melody Lane, Ennui NE". When we subsequently run across an announcement of a heavily math-oriented seminar co-chaired by one Peter Katsufrakis, PHd, of Rastafaran University in Ennui, NE we exclaim: "Why, that sneaky Pete!"

We have a sneaky-Pete at a California State College north of Bakersfield and another at a major private University in Tennessee. Move over, Sherlock Holmes and James Bond...

"I am sure you would agree that renewals are the sincerest form of flattery Have had 18 D-Gs in the last two weeks... While not the most objective and 'professional' of publications... Was wondering about the HALGOL 'NEXT JMP' bit..." Chris H, Outremont, Quebec.

The sincerest form of flattery is an order for a board. Eighteen in two weeks?? This newsletter is like 151 proof rum: a little at a time is O.K. but don't take any large doses! Who ever told you that a newletter was supposed to be objective and unopinionated? Did you notice that, just after John Dvorak mentioned this newsletter favorably (see "LIES" ref.), his next newsletter review, immediately following, criticized

Page 10, Column 2

another newsletter for failing to publish critical judgements (read, 'opinions'). John obviously feels, and so do we, that a newsletter is supposed to be opinionated. You are right about the 'unprofessional' bit, though. We haven't been able to find a journalism major who knows very much about the 68000 and related topics. We are one of those illiterate engineering majors (and have transcripts of grades in English classes to prove it). Later for 'NEXT JMP', O.K.?

"I am not convinced that HALGOL is faster than FORTH given equal circumstances. You can write whatever you want in assembly language in FORTH. Also, your 'GOSUB' is just as slow as a FORTH nesting (the code is the same)... It seems your main objection to FORTH is that it is difficult to read. Well, FORTH does have variables; they can be used to improve readability... I do not find RPN particularly difficult to use... My main reason for writing, however, is to take issue with your dismissal of virtual memory as being too slow." Steve H. (again)

A FORTH written (almost entirely) in assembly language, like a good compiled BASIC, would be as fast as HALGOL at run time. The thing is, there is no such thing as a compile-time delay for HALGOL; all of the compilation is accomplished during program entry and editing. The chemical computer on the other end is too slow to notice that delay. As far as the chemical computer is concerned, what it doesn't notice doesn't exist (it is stupid, really).

HALGOL combines interactive convenience with compiled speed, without the inconvenience of a separate compilation procedure (this is our way of using the power of the 68000 to enhance ease of use without any speed penalty).

Besides which, FORTH practice is just the opposite. FORTH tends to be written mostly in FORTH, even to the extent that a floating point package was recently published in FORTH Dimensions, to critical acclaim. It was written in high-level FORTH constructs (!!). Which means that all pretenses at run-time efficiency had been tossed out of the window. Why? Transportability, of course!

As we have asserted previously, given a choice between efficiency and transportability, we will choose efficiency every time. We absolutely refuse to cripple HALGOL so that it can be transported to inferior microprocessors. The FORTH community has obviously chosen the alternate course.

Now, for your "just as slow" GOSUB and the last reader's "NEXT JMP". HALGOL, like BASIC, is a procedural language (non-procedural languages are discussed on page 726 of Sammet's book, in the chapter

Page 11, Column 1

entitled "SIGNIFICANT UNIMPLEMENTED CONCEPTS"). A HALGOL or BASIC program is a list of procedures to be executed. Surely the lowest form of BASIC, where "GOSUB" is maintained in the program as five Ascii characters, no longer exists (if it ever did). The next lowest form is our old friend Applesoft or BASIC 4.0 where "GOSUB" is a token to be interpreted. The next step up, compiled BASIC, is a list of subroutine calls. At the top of the heap (for 68000 machines and most other modern 16-bitters) is the threaded code used by HALGOL and FORTH (we will dispense with arguments about 16-bit or 32-bit program pointers). "Just as slow"?? Ye gods, it is the fastest method available (for the 68000 & like units)!! The same of course, applies to "NEXT JMP", as that is the required termination for a threaded procedure sequencer.

Sure FORTH can be made more readable. But most FORTH programmers seem to delight in producing 'tight' unreadable code. Still, we will give you an opportunity to prove your case. Re-write the following HALGOL or BASIC statement (they can be the same) in FORTH and we will print it and let our other readers judge whether you have made your case:

 LET Y = A * X * X * X + B * X * X + C * X + D

About the fact that you have no difficulty using RPN: Our occasional comment about FORTH types being somewhat backward is intended to be taken humorously, not seriously.

(Pant, pant! A moment while we catch our breath...)

You are not the only reader who has taken us to task over our assertion that virtual memory is inappropriate for a personal computer. Virtual memory is a complex subject; books have doubtless been written about it. It seems inconceivable that any one book could be definitive. It therefore follows that we cannot provide a complete justification for our opinion in these pages.

We can, however, point out that a small company called IBM had fits trying to get adequate, or even acceptable, performance out of their virtual memory operating systems when they were introduced on the 370 series ten years ago. This was in spite of the fact that Burroughs had beaten them to the marketplace by more than five years, so that IBM had a model to copy, er, study. We know about this because we remember reading the horror stories in Computerworld ten years ago.

Otherwise we will (almost) terminate the discussion of virtual memory in this journal with the following simplistic explanation: Virtual memory is a wonderful idea because the amount of RAM appears to be about

Page 11, Column 2

equal to the total RAM plus disk capacity; since disks are generally much larger than RAMs, the net result to the programmer is a much, much larger RAM to work with.

The programmer does not have to worry where in the (virtual) RAM his subroutines are located and he/she does not have to worry where the variables are located. We suggest that if the proceeding sentence is true, then virtual memory works; and that if it is not true, then virtual memory does not work.

Suppose we have a program sequence which frequently calls a particular subroutine (or seven). The subroutines will almost always be off the current program segment residing in physical RAM (if this is not true, who needs virtual memory?). The resulting constant, repeated swapping of program segments will not actually stop program execution but the program might not run to completion this year. The identical argument applies to frequent references to variables which reside in different segments.

IBM's fix for this problem was to assign a minicomputer to work as a full time 'performance monitor'. The minicomputer's job was to alert a team of specialists in white coats when excessive 'disk swapping' occurred. The team would see that the 370 was switched to some other task while they sought means of eliminating the excessive swapping. They did this, of course, by grouping frequently used program sections and also frequently used variables.

(This ultimately reduces to efficient scheduling of disk overlays. What virtual memory??)

This is what a personal computer user needs??

As we said, this almost terminates the discussion of personal-computer virtual memory in these pages. Here is the crack in the door. Go to a technical library and research the problems IBM had ten years ago. (In fact, you might look at Electronic News, Apr 4 '83. There is a front page story about how IBM just had to add an extra 16 megabytes to the 3081 because the MVS [Multiple Virtual Memory] operating system didn't work right with only (!) 32 real megabytes of RAM!!!) Get a copy of a few of the articles to prove you have done this research.

If you can think of an implementation which would have eliminated IBM's then problems and the corresponding now problems of a personal computer, mail your suggested implementation and your proof-of-research to us.

Absent those steps, this subject is now closed.

Page 12, Column 1

A FORTHRIGHT REBUTTAL(?):

"I feel compelled to take typewriter to hand to reply (not really rebut) the comments in the last newsletter about Forth.

"1. Threaded languages are not, of course, the property of Forth. To the best of my knowledge, the first use of the idea was in a DEC FORTRAN compiler, though the idea is fairly simple and probably was invented many times. It might surprise even some Forth enthusiasts to know that threadedness isn't a property of the language, but particular implementations. There is a standard for Forth and it carefully avoids calling for a threaded implementation. In fact, I have a Forth which is not threaded, which I got long ago for the Apple. (It was trash in other respects, but it did show that you could write a non-threaded Forth.)

"2. Forth can be made readable, though I concede that it is somewhat more difficult to write such code than in a more mainstream language, such as BASIC. In my experience, Forth programmers at least give lip-service to readability; now if you consider APL freaks...

"3. Finally, to reply to Steve H: he is quite right; Forth is more a language kit than a language. Forth was intended to be lean, easy to implement, and fast. That means you must leave out everything which will not be used in every application. Strings are not "given the brush-off." I have seen at least two sets of Forth words to implement them. There is no requirement to have only two stacks; I, and many others, add more for specialized purposes. That's what a kit language is for. As Tony Hoare said, 'If you want a language without subsets, you must make it small.' He is currently working on his own small language; I'm not betting that it will look anything like Forth, however."

Bruce Walker, San Pedro CA

"P.S. You can summarize by saying, as has been said before, 'Forth is an adult language. You aren't taken by the hand; there is plenty of rope to hang yourself; but it doesn't get in your way and the tools are there to do anything.'"

Bruce, it is about cotton picking time we heard from you in defense of Forth - FNE.

"...not to raise trouble, but DTACK GROUNDED is still subtitled "The Journal of Simple 68000 Systems" so why no coverage, except disparaging, of Saybrook, Acorn and Sage?" Ron G, Davis CA

Page 12, Column 2

About Saybrook: how do we cover a device which doesn't work yet? The only thing disparaging we have said about the Saybrook is that it doesn't work (still true, we understand) and that its price continually rises (also still true; about $1550 at the West Coast Computer Faire or about $2100 for 12.5MHz).

About Acorn: we think it is fair to disparage a company which advertises a 'clock frequency' which is double the true value. In fact, we think such advertising is plain dishonest. At that, Acorn exaggerates less than Sage:

About Sage: they continue to claim their 8MHz 68000 runs at two MIPS, which continues to be 'not in accordance with the facts.' According to Motorola, an 8MHz 68000 runs at about 0.8 MIPS, which agrees closely with our own estimate. Sage is claiming performance two and a half times greater than their unit is capable of, something which does not engender confidence and trust from us. Otherwise, the hardware runs well and swiftly, as we have reported.

Intellimac: We wrote this one up a while back. We have never received any follow-up information to go with our personal board, which is either serial #1 or #2, depending on whether you believe the shipper or the Avery label on the board itself. Apparently they have upgraded the clock from 4 to 6MHz these days. This is the board that is used in the Acorn.

EMS: there is an outfit in Irvine, CA which make a kit which is available at various levels of completeness. Almost every BYTE magazine carries an ad for this board. We don't know anything else about it.

Motorola: As we reported a long time ago, Motorola was going to introduce a small module for just $495. They actually did finally introduce it. We don't know anyone who has actually used it.

All of the above: nobody has ever sent us a review of any of those units. That has a great deal to do with why we have had no coverage of them except what we have provided ourselves.

BLUE SKY ONE:

'Blue Sky' means we are going to discuss possibilities, not probabilities. Please do not write us a few months hence enquiring why we haven't done something discussed here!

Those of you who have Apple II computers with 35 track Apple or Apple compatible floppies may have noticed that those disks are a tad slow. Let us hypothetically

Page 13, Column 1

discuss a possible method of speeding up the data thruput, especially in the read mode.

A 5 1/4 inch floppy spins at 300 RPM. This means that all of the information on a 16 sector track passes the head in two tenths of a second. That is, it is in principle possible to discuss reading those 16 sectors in just two tenths of 1 second. That's 4K bytes. If we ignore the track-to-track settling time, we can (nominally) read the entire 35 track disk in seven seconds. This gives us a target to shoot at, a target which is somewhat faster than DOS 3.3(!).

Back to the problem of reading one track: because of the way DOS 3.3 nibble-izes the data, it is necessary to have an 8K byte disc buffer to read 4K bytes of data. After reading the track, the 6502 would have to de-nibbleize the data back into 4K bytes and then decide what to do with the 16 separate sectors of 256 bytes each.

Suppose what we need is a HALGOL DOS, one which reads the HALGOL operating system from disk into the 68000? That operating system is going to get big fast! Dinky little 256 byte blocks (sectors) just aren't going to make sense in a HALGOL environment. If you consider that the BASIC operating system for the H.P. Model 16 occupies (we are told) 236K bytes you can see what the problem is.

If we are going to run HALGOL, it is not unreasonable to assign an 8K disk buffer in the Apple. Perhaps HIRES page 2?? But after filling that buffer, we tell the stepper motor to seek the next track. While that track seek is being performed, the Apple can send that 8K block to the 68000 and let the 68000 de-nibbleize the data and perform certain other necessary alterations (more later).

Transferring the 8K block will require a little more than 110 milliseconds with a standard interface (71,000 bytes/sec) or about 11.5 milliseconds with the new 'Stuffer' board (discussed elsewhere).

While the Apple reads the text track, the 68000 is de-nibbleizing the previous track data. This provides overlapping operation, resulting in very high efficiency. (Now, this is what we mean by letting the Apple handle the minimum I/O and letting the 66000 handle the smarts!)

Which of the 16 sectors is the first, second, third? Why should the Apple care? Let the 68000 handle that bookwork! This means that the Apple only has to detect the start of any one of those 16 sectors before starting to read the track! This minimizes the rotational latency, of course.

Page 13, Column 2

The fundamental DOS 3.3 operations, such as RWTS, are well documented by Apple and in the book "Beneath Apple DOS." So it would not be an impossible task to tackle something like this.

More considerations: DOS 3.3 uses dynamic sector allocation. Which means that consecutive 256 byte blocks can be distributed in a random fashion all over the disk rather than in some sequential fashion.

What we are talking about here is our own DOS using our own method of sector allocation. If we forget about dynamic sector allocation and use a forward-pointing linked list scheme, we eliminate that particular problem at the cost of leaving 'garbage' sectors on the disk when a file is reduced in size and then re-saved to disk. Running a compaction program occasionally will eliminate the 'garbage' sectors and put all of the files in the optimum sequence.

This latter bit is not 'blue-sky' at all; we have such a custom forward-linked DOS running on our WANG 2200C. It is used exclusively to maintain source files for our 6502 assembler, stored in a binary compressed format to conserve disk space. (Well, we also use it for text files in our WANG's quasi-word processor.)

We invite comments from readers who know about RWTS and sectors and linked lists and stuff like that. You amateurs lay off for now, O.K.?

This idea was inspired by a suggestion made several years ago by a colleague, Leroy Lundberg. When the Shugart SA1002 Winchester came out, he suggested that we make a simple track-at-a-time interface for our high speed attached processor. The high speed attached processor was a 2MHz 6502 system. The host computer was, and is, a WANG 2200C. Yes, Leroy recently won (?) the D-TACK D-MERIT Award over another matter.

BLUE SKY TWO:

(Introductory and cautionary verbage same as above.)

Here we are trying to convince people that the 68000 is a high performance part and we still get mail from readers who are looking past the 68000 to the next higher level of performance. If us folks here at DTACK want to lead rather than follow, perhaps we should lay a few prognostications on you.

The 80186 is going to provide severe competition for

Page 14, Column 1

any microprocessor presuming to be 'almost as good as the best.' It has decent performance and will be an inexpensive part to design around at the system level. We predict that it will kill off the Z8000 series for anybody who can't produce the Z8000 for less than $10 retail. Olivetti, correctly interpreting the handwriting on the wall, has introduced in 8086 CPU module for their Z8000-based computer so that it can run CPM/86 and be (somewhat) software compatible with the IBM PC.

The real battle for performance supremacy will be waged between the 80286 and the 68010. Since neither device is available today in quantity or at full (predicted) clock speeds, this battle is on paper for now but it will heat up soon because both products are now real; it is now a matter of calibrating the cookie-cutters that will stamp out those chips in the tens of thousands.

Speaking of paper battles, Intel is running an ad now which asserts that the 286 outperforms the 68000 by a factor of three, generally. Up to now Intel has stuck (barely) to the practice of truthful ads (in our opinion). This latest ad places severe strains on truthfulness. If you have forgotten our opinion of the 286 and how it shapes up against the 68000, see newsletter #15, pages 10 and 11.

Nobody seems to have noticed yet that much of the excellent performance of the 286 when working with 16 bit data in 64K environments depends on its high bus bandwidth. That is, the 8MHz 286 allows only 250 nanoseconds per word transfer versus 320 nanoseconds for a 12.5MHz 68000. That 250 nanoseconds necessarily includes the time to set up valid addresses etc. plus some margin at the end to read in the data before starting the next bus cycle. What this means is that those companies which do not provide a substantial amount of high-speed 'cache' RAM are going to wait-state that poor 286 CPU to death!

Each fundamental memory cycle in a 68000 system requires four clock cycles, while each 286 fundamental cycle requires only two clock cycles. Each 12.5MHz 68000 clock is 80 nanoseconds while each 8MHz 286 clock is 250 nanoseconds. The fastest inexpensive dynamic RAM is the 150 nanosecond variety, which is not fast enough for either of those CPUs unless wait states are used. One wait state on the 12.5MHz 68000 equates to a 400 nanosecond memory cycle while one wait state an the 8MHz 286 equates to a 375 nanosecond memory cycle, and there went the 286's bus bandwidth advantage out the door!

If you want to use all of the available performance of the 12.5MHz 68000 you need 100nsec static RAN, as many of you have already discovered. To be able to use all

Page 14, Column 2

of the potential performance of the upcoming 286 the same thing applies. Wait states will hurt the 286 proportionally more than the 68000 because the minimum wait increment on the 12.5MHz 68000 is 80nsec versus a minimum wait increment of 250nsec for the 8MHz 286.

Yes, we know that Intel talks about a 10MHz 286. We expect to see such a device eventually, but not soon. It will probably be contemporary with 16MHz 68000s from Hitachi and 16MHz 68010s from Motorola. All of the above will require fast static RAM for maximum performance. Fast like 70nsec or so.

(Those of you who have noticed the omission of the National 16032 from this discussion are advised that the omission was not accidental,)

Some of you are aware that limited quantities of 100nsec DRAMs are available at premium prices. You may wonder whether these cannot be substituted for the 100nsec static RAMs we are now using to attain full 12.5MHz thruput with no wait states.

We have a surprise for you: the answer is no!

You see, the 68000 address lines become valid half a clock period, or 40 nsec at 12.5MHz, before the address strobe (bar AS) goes low. There is no way to know in advance of the high-to-low transition of AS that a memory cycle his begun, even though it does begin 40nsec earlier with stable, valid address lines. Therefore, RAS (Row Address Strobe) for the DRAMs occurs as soon after the high-to-low transition of AS is possible, and this starts the clock running on the DRAM's specified access time. But a static RAM would already have spent 40nsec decoding the address!

Therefore, it would require a 60nsec DRAM to equal the access speed of a 100nsec static RAM. This argument is of course limited to the 12.5MHz 68000. But the addresses have to be stable before RAS is applied to DRAMs. Always. So it seems likely that static RAM will always outperform seemingly equivalent DRAMs. And that is yet another reason why we like static RAMs.

ONWARD AND UPWARD:

It is clear from our correspondence file that some of you readers are looking past the little 286/68010 battle. Well, there are only two directions to travel for higher performance if we are to stay in the microprocessor world. We must get hold of a next-generation 32-bit microprocessor or else use multiple microprocessors.

Page 15, Column 1

About 32-bit microprocessors: you cannot buy one across the counter. Hewlett-Packard actually makes a real, honest 32-bit unit. The chip is huge! The yield is correspondingly terrible! But HP does not care; each good chip becomes the heart of a $30K to $120K minicomputer. The HP chip does not even have a name!!

Next we have the Bellmac-32, which does exist. It is a CMOS part with a reasonable chip size, so it is in principle manufacturable. Ma Bell recently embarrasedly admitted that the part was optimized as a communications controller, not as a general purpose processor. The people writing comparisons of 32-bit processors for Computer Architecture News had not caught on to that fact.

Next is the RISC, or Reduced Instruction Set Computer. This part has almost been manufactured experimentally. It has been written up in Computer Architecture News as though it were real. In C.A.N.'s simulated benchmarks, the RISC has shown up very well. There is now some controversy over whether this has to do with the instruction set or the extra registers the designers built into the chip design. In any event, this chip is not commercially available nor will it be commercially available in the foreseeable future.

So you can't buy the HP chip or the RISC and you would not want to buy the Bellmac-32.

That means we must look to the National 32032 or the Zilog Z80000 or the Intel 386 or the Motorola 68020. All of these are intended to be commercial parts. All four manufacturers will tell you that their part will be available real soon now! In our opinion, it will be a long long time before you can walk into your local distributer, place your money on the counter, and walk out with one of those four devices. Indeed, there is grave doubt whether the Z80000 will ever see the light of day (we fear that Zilog is not long for this world in its present form and with its present overhead).

If we are to believe National and Motorola their 32-bit microprocessors will appear late this year. You may guess what our personal opinion is.

If we cannot obtain a 32-bit microprocessor in the near term, how can we achieve higher performance than with a 68000? As nearly a dozen of you have pointed out to us, ten or so 68000s can run faster than just one 68000. And we are finally talking about a real product which can really be purchased across the counter at your local distributer. Unfortunately, no one has yet built a dedicated multi-68000 system.

We should emphasize that such a multiprocessor system

Page 15, Column 2

is not generally useful because of the data path problem (see issue #6, page 3, the last two paragraphs). But it turns out that many problems can be broken down into elements which can be solved in a multiprocessor system. What we are really talking about is an array processor, of course.

It is in principle possible to build a system with 8 or 10 slave 68000s (each with a fairly small memory) for less than $5000, There are real-world applications for such devices such as medical imaging. Several of you readers have been so unpolite as to suggest we manufacture such a device. Since we think it is a good idea, too (if largely for promotional purposes) we will put that at the end of our list, right after the cheap 68008 'under the hood' Apple compatible board.

MICRO WATCH:

We regret to report that our advertisements in Micro magazine are all screwed up. We are pleased to report that it is not our fault.

Our second full page ad, the one beginning "WE (SORT OF) LIED", was placed in four consecutive issues. Since the ad was by then pretty well worn out, we did not place it in the March issue. They ran it anyway. That's the fifth consecutive appearance.

Back on Feb, 18, we sent copy for a new ad with an accompanying check for placement in the April issue. The April issue is just out. They ran the old ad copy, for the sixth consecutive time. We have already sent them a check (over two weeks ago, in fact) for the May issue, which is supposed to repeat the new copy. Your guess as to what will happen is as good as ours.

BYTE WATCH:

By now almost all of you will have seen the April issue of BYTE. For the first time, BYTE has moved into the 1980's as far as their editorial material is concerned. (There is still some '70s stuff; see the article on page 360. 16K DRAMs? Three power supplies??) So will the ten or twelve DTACK subscribers who do not also subscribe to BYTE run out and get a copy of the April issue? Now, before they are sold out?

You will have noticed a nice, lengthy article on the National 16-bit chip family, beginning an page 53. If you will turn to the Conclusions on page 66, you will discover the following: "...these large systems (such as the IBM 3081) currently offer no more than 16 megabytes of virtual memory."

Page 16, Column 1

That is a lie. The IBM 3081K now features 32 megabytes of real DRAM, going on 48megabytes. The virtual storage is over two gigabytes (EN, 4 Apr 83, pg 1). And the 370 has had 32 megabytes of real RAM for what seems like forever. We don't know whether the guy writing that National article is lying an purpose or out of ignorance but we would read the remainder of the article with care...

BYTE has finally figured out that the world is larger than 64K; that the old-generation 8-bit processors are a poor fit for this new world, and that choices must be made as to how to best utilize our new-found resources. See the editorial on p.6 and the article beginning on p.242. Although the headline on each emphasizes software, the editorial emphasis is, 'how the heck do we best utilize all this super hardware?'

Sprinkled throughout the issue is support for some viewpoints we have been pushing here for nearly two years now (!). For instance, both Richard Frank of SORCIM and Microsoft's Bill Gates believe (p.251) "...that simultaneously running more than one application program on a single microprocessor is neither necessary nor desirable."

And as a part of the article on Modula-2 beginning on p.385 we find a high-powered follow traveller who has little or no use for unextended PASCAL, one Brian Kernighan of C language and Software Tools fame. We strongly recommend the Modula-2 article since it describes in loving detail all the stuff that is wrong with PASCAL. Well, much of the stuff that is wrong with PASCAL.

In fact, to the extent that Modula-2 fixes many of PASCAL's problems, we like Modula-2. But we do not like Volition system's implementation because it is based on Apple UCSD PASCAL, which only has single precision arithmetic and is therefore not generally useful.

WE JUST KNOW that we would like "Why Pascal is Not My Favorite Programming Language," by Brian Kernighan, Computing Science Technical Report No. 100, Bell Laboratories 18 Jul '81. If we had a copy, that is.

Brian Kernighan is (with P. J. Plauger) the co-author of the excellent book Software Tools (Addison-Wesley, 1976). You may be interested to know that P. J. Plauger has also published several stories in Analog Science Fiction under the same name.

PLEASE DO NOT MISS the correspondence on pg.18 regarding the delivery of JRT Pascal.

ALSO DO NOT MISS (please) the writeup on FORTRAN bugs beginning an pg.20.

Page 16, Column 2

MISCELLANEAE:

Commodore has just installed a new president-of-the-month whose background includes nothing related to computers. The Osborne computer company has a new president who is the former prexy of Chicago-based Consolidated Foods. The only 'high tech' Consolidated Foods has is the Electrolux Vacuum Cleaner line, which is peddled door to door. The Apple Computer Co. has a new president who is the former prexy of PepsiCo, we kid you not (take the Apple challenge today??). None of these guys know anything about computers. And that ought to tell you something about the attitudes and values of Commodore and Osborne and Apple.

John Dvorak in his column in Infoworld heaps praises on the management of Fortune Systems and their ability to raise lots of bucks thru a stock offering. He concludes his praises by noting that all of the management of Fortune seem to be clones of the prototypical salesman in a three piece suit named Bob.

Our interpretation of these events is that the computer business is now too important to permit anyone who knows anything about computers to have any say in the management of a computer company. Can you provide an alternate explanation which is in accordance with the observed facts?

"I have ported over 40,000 lines of assembly code from an IBM series/1 to the popular 16-bit micros (8086, Z8000, 68000) and from an assembly programmer's point of view the 68000 is the hands down winner. But I have two gripes when it comes to the 68000 (both admittedly trivial):

"1) Why doesn't the loop instruction (DBcc) stop at zero, as the 8086, Z8000, Series/1, PDP11,... do?

"2) Why not shift the displacement in PC-relative jumps, etc. to create a word offset and expand it to a byte offset at run time (as the series/1 & Z8000) and double the range. Seen any instructions at odd addresses (double meaning) lately?" Louis S, Largo MD

Louis, we don't care for the DBcc instruction either. As for shifting the displacement, the 68000 does not have a particularly efficient internal shift mechanism. We seem to be agreed on the point that the 68000 is far and away the easiest micro to program. We also sees to agree that the 68000 ain't perfect. Now, about those 40,000 lines of source code: was that a proprietary project or can you tell us more about it?

Page 17, Column 1

"...we refer to your letter of 18th March addressed to Inside Trader:

"I regret to inform you that Mr. Trader passed away after a murderous attack upon his by an unknown assailant last Thursday evening.

"Knowing of your close association, the Editor wondered if you would care to pen a few words of panegeric for our special memorial issue."

(signed) W. Cheetham, Obituraries Editor

We have indeed submitted a suitable farewell to Inside Trader, Microcomputer Printout magazine's beloved gossip columnist. We understand that the list of suspects has been pared to about 37,000 so an arrest can be expected momentarily. The enormous number of wooden stakes received at M.C.P.'s editorial offices augers well for warm offices next winter.

A little further on we have reprinted the last item in Inside Trader's last column, which may clarify the previous paragraph...

MICROCOMPUTER PRINTOUT WATCH:

In their April issue, M.C.P. takes turns throwing posies and brickbats at one Apple Computer Co. On page 909 Julian Allason points out a small inconsistency:

"...Apple (has) already indicated their intention of restricting LISA dealerships to the select few. The official explanation is that only the most experienced business systems houses would be able to do justice to the new baby. Quite how this squires with Apple's claim (probably justifiable) that LISA is so easy to use that it can be learned in twenty minutes, is anybody's guess."

(Julian, Apple critics are now in danger of receiving several cases of soda pop [guess which brand] delivered by helicopter and dropped from two thousand feet.)

And on page 102 we find the last item ever to be published by the late Inside Trader:

"To Chateau Commodore, where they are chortling over the following riddle: 'What is the difference between a hedgehog and a Range Rover?' Answer: 'A hedgehog has the pricks on the outside!' Commodore boss, Bob Gleadow, recently acquired a Range Rover."

Small World Dept: On page 19, Julian Allason professes to have received a missive from a Miss Roberta Gleadow, who enclosed a photograph of herself in a bathing suit. Well, more out than in, in Julian's judgement. One

Page 17, Column 2

wonders whether she might be a distant relative of Bob, the new owner of a Range Rover?

M.C.P. has the problem that a few of its readers are too dense to understand the difference between the occasional spoof and serious reporting. They have just adopted the practice of identifying, for their "less astute readers," spoof stories by a small 'bull symbol'.

Fortunately all of our readers can invariably and correctly detect the difference between one of our little 'leg pulls' and our more serious reporting, so that we have no need to label our jokes...

ELECTRONIC NEWS WATCH:

We have heard several persons who are closely connected with Commodore (U.S.) assert that dear, sweet Jack Trameil is 'out to get' several personages and several companies. Now, we can hardly believe that an easy-going type like Jack would bear anyone any ill will. But the rumors (mistakenly, we are sure) persist that Jack is out to get Chuck Peddle, T.I. and a few others.

Aside from the fact that Jack is too nice a guy, there is also the small fact that a dinky little outfit like Commodore obviously can't do anything to a true corporate giant like T.I. Obviously! So the story on p.54 of Apr 11, '83 E.N. is particularly interesting.

As everyone who watches this industry has long been aware, T.I. has been bringing along a $99 16-bit home computer called the 99/2. This quarter T.I. was due to sign up lots of mass marketers such as K-Mart, Sears, Monkey Ward and the like. The reason, of course, is that now is when those mass marketeers are putting together those large catalogs.

Through an unfortuitous coincidence (unfortuitous for T.I., that is) Commodore picked the exactly wrong moment to drop the package price on their VIC-20, tape unit and a software program by $40. Retailers responded by selling the extras at list price and dropping the VIC-20 by $40, placing it well under $100.

We will permit Mr. William Turner, T.I.'s Consumer Products Group prexy, to explain T.I.'s reaction to Commodore's move: "I have withdrawn it (the 99/2) from the planning cycle you usually have with retailers. We have advised all retailers who said they wanted the 99/2 that we will not pre-plan in any way... We have asked they not put the product in their catalog."

As we have pointed out to you, there is absolutely no way that dinky little Commodore can influence a corporate giant like T.I. In fact, there is also no way they can get at Chuck Peddle or Victor ...

Page 18, Column 1

We have been assured by several sources recently that the Apple III has become an enormously successful product. Heck, you readers know us, we believe anything we hear about the Apple Co. or its products. Especially if what we hear is favorable. So, another story on the same page, same issue of E.N. puzzles us:

Bruce Burdick, prexy of a 4-store Computerland franchise in Kansas City: "The Apple III seems to be dying a long and lingering death. It should have been phased out 2 or 3 years ago (wasn't it introduced 3 years ago? -FNE). I don't think we've sold one in two months."

And Sheldon Gawiser, veep of Computerworks in Westport, Conn: "The machine just isn't selling... Apple has a lot to do to make the III competitive. Sales have been slow." Ah, Sheldon: you're repeating yourself!

And we have forgotten where we recently read about the Plum Computer Co., but there is such an outfit, honest. We know that Apple has taken a dim view of an outfit called Orange, but we still have the Tangerine, Prune and Kumquat names open.

PC WORLD WATCH:

We have the premier issue of this magazine. It features a careful comparison (pp102-117) of two 'super-spreadsheets', NBA and 1-2-3. The first is written in PASCAL, the second in assembly language. Guess which runs 40 times faster than the other? The last paragraph on p.115 and the next paragraph on the following page are worth reprinting here:

"As has already been mentioned, 1-2-3 is significantly faster than NBA for virtually all program functions. Speed is a very important measure of performance in these two management programs. For the intended (business) users, time is money. When one program takes several minutes to do what another accomplishes in split seconds, those minutes can add up to hours, and hours of a manager's time can be expensive.

"Besides the directly attributable cost of wasted time, a hidden cost of a slow program may be even more significant - the degree to which speed affects convenience and creativity. If a task is easily and quickly executed, a manager will be more likely to perform more iterations of a 'what if' analysis and, therefore, will be more likely to find the optimum solution. The cost of such a missed opportunity, although hard to measure, can be great. In addition, waiting for the computer to respond can be detrimental to morale."

Hmm. Did we ever tell you that assembly language programs run much, much faster than interpreted

Page 18, Column 2

programs? Such as the interpreted 'P-code' of supposedly compiled UCSD PASCAL?

SOFTALK (IBM DEPT) WATCH:

Softalk regularly prints the top 30 selling (IBM PC) software packages at the rear of the magazine, along with an index so that, for a given month, the sales of different packages on the list can be compared. They also print a commentary an that list.

The April '83 issue finds 1-2-3 at the top of the list by a considerable margin only two months after its introduction. The commentary pretty such praises the package, which you will recall is written in assembly language. Its PASCAL-based competitor sold just over a tenth as many packages in the reported month, which is February (publishing lead times, you know).

Oh, yes: on p.31, we discover that 96% of the PCs use PC-DOS, another 3% use CP/M-86 and (ahem) 1% use the UCSD p-System (from all sources combined). You don't suppose that Softech's 'universal' operating system might be slightly less than universal?

(Continued from page 1)

Well, the faculty advisor asserted that TTL chips, after all, go together rather easily. He suggested that a more complex project would be appropriate for a Senior Design Project. (We believe that he was overlooking the fact that we had two asynchronous systems to tie together.)

So, the interface specification was expanded to allow bidirectional data transfer. And we provided for the transfer of 256, 512, 1024, 2048 and 4096 byte blocks as well as 8192 byte blocks. This revised specification was approved by the faculty advisor (we do not know whether the small bribe of a working prototype was made or not, and we have not asked!).

And, since the interface has been prototyped and proven to work, our new Project Engineer is the first in his class to complete his Senior Design Project. And maybe the only one to get paid for it??

Naturally, the Stuffer board duplicates the circuitry of the standard (no-name) interface board so that all of the existing software will run without modification.

Now for the utterly predictable sales pitch: we will sell you one of these boards for $110 including a small manual, a complete schematic and a disk containing a

(Continued on page 20)

Page 19, Column 1

THE SIX BIGGEST LIES:

1. The check is in the mail.
2. I'm only resting my hand on your knee, my dear.
3. You must purchase an EXORMACS to support 68000 development.
4. The 68000 is usable exclusively in very complex systems.
5. Ninety 68000/UNIX companies can profitably coexist in the Silicon Valley.
6. Anyone who does not endorse 3, 4 and especially 5 cannot be said to act favorably toward the 68000.

We have been informed in no uncertain manner that lie #6 above is considered fully operative by most of the staff at Motorola headquarters in Austin.

In the meantime, the folks at INFOWORLD (well, John Dvorak) are apparently under the impression that this newsletter reflects favorably on the 68000. See John's "Inside Track" column in the March 28 issue. Of course, John does not know nearly as such about the small computer industry as those Motorola technical types ensconsed behind their desks in Austin reading each other's marketing forecasts. Of course.

We have figured out what it takes to stay on the good side of Motorola: Buy an EXORMACS. Build incredibly complex 68000 systems. Launch the 91st 68000/UNIX startup in the Santa Clara area. Include us out!

The folowing is taken from Mar 31 '83 Electronic Design News, page 115:

"FIRM BECOMES SOLE NONSOURCE FOR SEMICUSTOM ICs

"Jeff Berman, president of Standard Pseudocircuits, Inc, has announced that the firm will remain the industry's sole nonsupplier of gate arrays and ULAs. In justifying his company's position, Berman explained that 'There are now 79,134 semicustom-IC suppliers. We expect to see 79,130 bankruptcies in the next 2 or 3 yrs, at which time we'll see what the remaining four are doing right - then we'll become number five."

That item is, of course, an April-fool spoof (maybe it should be identified with a small bull logo?). Those EDN staffers obviously know that just so many hot-dog stands can profitably occupy the same street corner. Most Motorola types haven't figured this out yet, and neither have about 85 Silicon Valley start-ups.

Page 19, Column 2

L.A. TIMES WATCH:

On Saturday, April 16 the following advertisements appeared in the Sports Section: A Timex 1000 for $44.95. A VIC-20 for $88. An Atari 1200XL for$529.88. An Apple II+ for $615. An Apple II+ with 12" monitor and a disk drive, $995. A Commodore P-500 with 128K, $795 (actually in stock). A frankly labelled close-out sale on NEC computers. An Apple III with 256K and a monitor, $2099 (obviously a close-out for that particular retailer).

There was also a full page ad for the Kaypro II and a half page ad for the Epson QX-10. The $2995 QX-10 has two disk drives, 380K each; 640 X 400 graphics windowed into a 1024 X 1024 virtual display; 256K RAM bank-switched for its Z80A microprocessor and another 128K for the display. The display uses the NEC 7220 graphics controller, by the way. There were lots of individual retailer ads featuring this computer, but nobody is discounting it yet. Do you realize this computer comes with a total of 3/8 megabyte RAM as standard equipment??

It is indeed fortunate for Apple, Tandy and IBM that Epson didn't spend an extra $50 ,and install an 8MHz 68000 in the QX-10. Only the limitation imposed by the Z80A prevents the QX-10 from being a world-beater.

(We wonder whether that 640X400 display is interlaced or not. It makes a big difference, folks!)

(We also tactfully suggest that you refrain from walking into an Apple III retail outlet and quietly offering $2100 cash [plus sales tax] for a 256K Apple III plus monitor. You will likely find yourself with 1/4 megabyte RAM more than you used to have and $2100 less cash,)

DERELICTION OF DUTY:

Yes, we know we were supposed to resume discussion of HALGOL this issue. The plain fact is, inspiration didn't come. Let us point out that our earlier discussion of transcendentals appeared in issues 16 and 18 with a big hole in issue 17. We also have the excuse that we have been doing a lot of work on hardware designs lately. Since our schedule calls for us to concentrate on hardware for another month, you may not see much discussion of HALGOL next month either (this may be good rather than bad news to some of you).

But we will resume (formerly) REDLANDS next month, with some 68000 graphics utility code.

Page 20, Column 1

demonstration program and the source code for the demonstration program. If you are content to look at your neighbor's schematic and copy his demonstration disk, we will sell you the board for $95 with just the short manual. In case you don't know it already, we do not sell documentation separately, even though we periodically hear from dingbat yo-yos who demand that we do so...

Oh, yes: we are going to have these boards wave soldered, which means a run of at least a hundred, which means it will be about six weeks before we will be able to ship you a board (today is Apr 16). Say, the end of May or the first week of June. If you order a board right away, be sure to include specific written authorization for us to hold onto your money for more than 30 days, or we will have to send it back (reference: Joe Sugarman).

Now for the unpredictable inverse sales pitch: while we fully guarantee this board to work properly with an Apple II or II+ or IIe, we cannot guarantee that it will work with all other DMA devices. In particular, we can absolutely guarantee that it will not work with one of those copy de-protection boards! Assuming you trigger the device while a Stuffer DMA transfer is in progress, that is.

We have discovered that, as a practical matter, all Apple DMA boards assume there is no other board competing for the bus. We have gone to considerable effort to avoid conflicts, including designing the board so that the 6502 must initiate the DMA process, and we provide in hardware a means for the 6502 to monitor in software whether the transfer is completed.

Nevertheless, there is absolutely no way that we can guarantee compatibility with those hundreds or thousands of foreign Apple plug-ins. In the event of a conflict, the problem is yours, not ours. We will not provide refunds in the event of such a conflict. You should give this matter careful consideration...

And, for obvious reasons, we will not sell the Stuffer board as a substitute for the standard board. (Genghis Khan strikes again?)

IN PRAISE OF SOFTWARE:

That is the title of a one-page article in April '83 Wireless World. Most of you will remember that we recently quoted extensively from an earlier (very one-sided) Wireless World article which essentially attacked programming and programmers. Not one of our readers has commented on that earlier piece even though we must have a lot of programmers who read this newsletter. Nobody even noticed that the same editor

Page 20, Column 2

who selected that attack on programmers for publication spends a fair amount of time programming himself! Sigh...

In any event, the title of the new article is misleading. The article really defends the use of high-level languages (such as PASCAL) instead of assembly language for programming. In the process, the author (H. D. Baecker of the dept of computer science, University of Calgary, Canada) presents absolutely the most compelling arguments for PASCAL programmers to learn assembly language that we have ever heard.

You see, the reason for a commercial, profit-oriented enterprise to program in PASCAL rather than assembly language despite the indisputable speed advantages of assembly language is that PASCAL programmers can be hired for much smaller salaries than assembly language programmers, who are scarce and in high demand.

In other words, the only reasons for a PASCAL programmer to learn assembly language is that his programs will run much faster and he will earn much more money! (Linda, there are no non-sexist alternatives to 'he' and 'his' which are both succinct and unobtrusive.)

This seems to point in precisely the opposite direction to the thrust of the argument presented in the article. But the article addresses itself to management and those making management decisions! Since when is it news for management and labor to find themselves on opposing sides?

The author's concluding sentence is: "We are a bare 32 years beyond the commissioning of the first general purpose electronic digital computers, and it may seem premature to throttle development by adopting standardized tools, such as existing high level languages or operating system."

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

SUBSCRIPTIONS: Beginning with this issue, subscriptions will be $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Send the check, payable to DTACK GROUNDED, to:

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

(O.K., so we lied last issue! But REDLANDS really will return next issue, honest!)