Issue # 22 DTACK GROUNDED Newsletter - August 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

BACK IN BUSINESS III:

Them things down there are, collectively, our new very-damn-high-res video graphics boards. The bit-plane boards are separate from the video controller circuitry so that one, two or three bit-plane boards can be used. Two bit planes allow for on, off, and two gray levels (commonly and erroneously called 4 gray levels) while three bit planes allow more gray levels or RGB color.

The resolution is 1024 horizontal by 796 vertical, thus providing a unity aspect ratio. You draw a rectangle 750 pixels on a side and the result will be a square.

The BIG surprise is that the display is NOT, repeat NOT interlaced! The update rate is 60 Hz and the pixel clock is 67.888 MHz! Yes, we do use the 7220 NEC video graphics controller chip, the 5MHz version. Yes, we remember telling you the NEC was unusable in a non-interlaced display with this such resolution. Well, we don't use the NEC. An explanation follows:

Page 1, Column 2

You see, the bit planes have alternate HIRES pages, just like the Apple II (which you may have heard of). The difference is that, using our board, the 7220 can write to one of the pages while the other is being displayed. And the memory pages can be swapped back and forth, just like the Apple II. The difference is that there is no way, none, to write directly to the page which is currently being displayed.

As you might imagine, you are not going to walk into your nearest home computer vendor's shop and pick up a suitable monitor for $69.95. In fact, this graphics system (with more than one board it rates as a system) is designed primarily to work with a specific manufacturer's specific black-and-white monitor. The company is Video Monitors Inc in Eau Claire, WI. The bad news for the hacker reading this is that the monitor does not come in a case! Which is O.K. for the pros, they have to make a case anyhow to also hold the boards since 67.888MHz is channel 4...

Clearly, this board is not intended for the single-unit buyer. But, we have several industrial-type customers and their money is just as good as the single-unit buyer's money, no?

But, just as we now make both static and dynamic RAM versions of our DTACK 68000 boards (and this board is compatible with both), this is just the first of our NEC 7220-based hires graphics boards. The next one will be pointed toward something a bit more reasonable for an individual (but still fairly high-end). We are developing a family of compatible boards...

Page 2, Column 1

FAST NUMBER CRUNCHERS:

If the Intel 8087 or the National 16081 math chips are too slow for you, it is possible to build what used to be called a 'stunt box' to speed up the floating point calculations. Possible but definitely not easy! Besides all, the design work, there is the problem of laying out the 5, 6 or 7-layer circuit board and of course the production problem.

Well, the circuit design portion of the problem has been solved; there is an application note featuring a complete design using (mostly) parts which exist.

We refer to Application Note AN-111 (remind us to tell you about Casablanca's 111 club sometime), published by Monolithic Memories (MMI). The title is "Big, Fast and Simple - Algorithms, Architecture, and Components for High-End Superminis" and the authors are Ehud Gordon and Chuck Hastings. This is a 14 page tutorial, 20 pages if we include the appendix. If you are a hardware freak and interested in floating point processors you must obtain a copy of this ap note.

We read it one morning at home. Afterwards, the name Chuck Hastings and the (clear and easily understandable) writing style seemed familiar. When we drove in to work, we immediately checked the CONFERENCE PROCEEDINGS of the second West Coast Computer Faire, and sure enough, Chuck is also the author of the article beginning on page 370. That article, entitled "A RECIPE FOR HOMEBREN ECL", is one we have remembered well and still, after five years, makes good reading.

Come to think of it, that ap note should be of interest to anyone who needs to write about technical stuff, especially hardware, as a model of how to do the job right. The typesetters didn't bollix it too badly, but the equation at the top of the second column on page 13 should be:

Q(n+1) = 2Qn(1 - BQn) for the reciprocal

Also., Figure 7 on page 8 has the MUX addresses in the reverse order. Reverse the signals to A and C on the three MUXes at the bottom of the figure but not to the encoder in the middle of the page; those signals are drawn correctly.

It is interesting to note that Chuck, in the paper reprinted in the Computer Faire proceedings, credits Norm Winningstad as being one of the three people to give him some help on the road to ECL, because it happens that we know Norm also. We first met Norm in 1961 while we were both employees of Tektronix, the oscilloscope manufacturer. In fact, Norm had occasion, in the early 1970s, to visit our home once for a toddy and to see and hear the largish speaker system we have.

Page 2, Column 2

Of course, Norm is the founder and President of Floating Point Systems, Inc. That company has been enormously successful over the past dozen years and is traded on the big board (the New York Stock Exchange) so we imagine Norm, who happens to be a nice guy, might have less time these days to be helpful about ECL.

And, boy! would we ever like to own our own VAX with an FPS-164 array processor attached. We can't afford it and even if we could it would overload our home's air conditioning systems. Turn, for instance, to the two-page ad in Mar '83 DATAMATION beginning on p.92. The FPS-164 runs at up to 12 double-precision megaflops and the price starts at $300,000 (a megaflop is a million FLoating-point OPerations per second). So, we are going to make a homebrew 'equivalent' which won't be homebrew at all since we will offer it for sale.

'Equivalent' means about one megaflop for about $10,000. That's twice as cost-effective as Norm's little (?) baby, which works out to $21,000 per megaflop. Of course, we will not have Cornell University standing behind us the way Floating Point Systems does, so we will have (as usual) less software support. Incidentally, the Cornell-FPS connection is worthy of an extended story all by itself. Nothing sinister; the Cornell folks just thought that an available high-perforiance attached processor at a reasonable price was a good idea for the scientific community in general and thus 'got behind' FPS and helped it along. The only available alternatives were called Crays and Cybers and cost lots of bucks.

We are going to make our (roughly) megaflop machine by paralleling a bunch of Nat Semi 16081 math chips with either 68000L12 or 16032 support. This will be done by making a 'mother board' exactly 6.5 by 15 inches, the same size is both the static and dynamic RAM versions of our board. And compatible with each, of course. Then we will make a small, simple processor board with at least one 16081 associated math processor. Since the 'mother board' can hold 10 to 12 of these boards, each with either one or two 16081 math processor chips, a megaflop (double precision, remember) is well within practicality at a price of $10,000.

(We will know about the '68000 or 16032' and the 'one or two' questions soon; we have a schematic drawn up and will be building a trial prototype soon.)

Another nice feature is that a half-megaflop will be available for about $6000. Yet another nice feature is that the megaflop will not overload your home (or schoolroom or small laboratory) air conditioning system. Maybe the folks at Cornell University ought to be advised about our little project? (The small computer market is the market... didn't we read that somewhere recently?)

Page 3, Column 1

ATTN PEANUT GALLERY:

We are now going to give you what may be the offer of a lifetime (or maybe maximus ridiculi absurdum): a chance to kibitz in advance an a floating point array processor which is going to be built. Here are the ground rules: you can make any suggestion you like, no matter how wierd, and we promise not to expose your ignorance here by name (we may do so anonymously if the suggestion is sufficiently entertaining). On the other hand, we promise that us and our new project engineer will, both of us, read your proposal and consider it as we design the array processor.

The thing is, it is ridiculously easy for any hardware type to come up with ten different array configurations in five minutes. The problem the manufacturer has is that he can generally build only one configuration. Think about it.

Now, why are we going to build such an array? We provide several answers;

1) This is a fun project, and we are doing this 68000 stuff for fun as well as a way of paying the bills.

2) What personal computer magazine can resist publishing, and perhaps commenting on, an array processor which has that kind of performance? We expect to have the free publicity pay for the development cost even if we never sell any!

3) There is a huge potential market for such a device, if only the right people know about it. There just ain't no way to get that kind of performance at that kind of price elsewhere. And remember, the math chip sockets can be left vacant for the guy who needs about 15 honest MIPS of 32-bit integer performance. For those interested in conversion factors from honest MIPS to Sages or Acorns, one honest MIP = 2.5 Sages = 10 Acorns. So our 15 MIPS array processor would be rated at 37.5 Sages or 150 Acorns.

(For those who just returned from an extended vacation on the planet Zorn, the 'Sage' and the 'Acorn' are both fictitious units of 68000 performance as measured in millions of instructions per second.)

4) Additional 68000 processors, with or without supporting math chips, are not the only sorts of things that could be plugged into those 10-12 expander slots. How about disk interfaces, printer interfaces, modems, prom/eprom-burners, plotter interfaces, game paddle interfaces for rock-shooters, that kind of stuff. Grande owners with a full gallon will probably not need a language board, or whatever those things are called.

(This brilliant idea is wholly original with us.)

Page 3, Column 2

Supercomputers
= Colossal Computations
+ Enormous Expectations
+ Renowned Risk

That's the title of an excellent article by Neil R. Lincoln of Control Data Corporation, published in (IEEE) Computer magazine, May '83. Neil, who obviously has a great deal of hands-on experience with high-end array-type supercomputers, has succeeded in writing an article which is both very informative and very entertaining. If there is any possibility that you can get your hands on this article, we strongly urge you to do so. Following are a few exerpts:

"The legendary knight-errant riding into the dark forest to confront a fire-breathing dragon is not unlike the supercomputer developer who sets out to slay a new set of mammoth computations. Both are sent off with great cheers of encouragement - by spectators. Both are blissfully ignorant of the nature of the beast, despite an incredibly detailed analysis of its size and fury - also by spectators...

"A major choice confronting the computer architect is the degree to which a new supercomputer should be considered general purpose or special purpose. In today's computer vernacular, the term general purpose includes both the processing of business data with Cobol and Sort/Merge and computationally intensive scientific applications...

"Since we have decided not to develop the traditional line of software (Cobol, etc. - FNE) for the supercomputer, a supporting computer system must be coupled to the supercomputer to provide expected user interfaces. The supercomputer is then a computational engine harnessed and controlled by a standard, general-purpose computer system...

(Sounds like an attached processor to us - FNE)

After discussing a few nasty business considerations, such as the need to show a (gasp!) profit, the author continues: "The last task for the architect is to listen to the comments and criticisms of a variety of interested parties. Users of computers are rarely content these days to state their requirements in terms of computation and memory volumes; they are more apt to describe their needs in terms of 'a machine of their own design.' This tendency is even stronger today...

"The computer organizer must sort out the meaning of the incredible variety of suggestions that surface ...

The author concludes: "With technology limitations making the achievement of clock cycles under 10

Page 4, Column 1

nanoseconds quite difficult, the performance of scalar processing is reaching an asymptote. This limitation, together with the need to keep execution in balance with vector execution, seems to be driving us to introduce multiple scalar units into future supercomputers."

You will please excuse our use of an authority on supercomputers-cum-array-processors to make a few points for us. Array processors are never 'generally' useful; on the other hand, there is no practical way to (with sufficient economy) solve certain scientific problems without the use of array processors. The reason array processors are not 'generally' useful is the data path problem, discussed briefly in issue #6, page 3 of this newsletter.

If you are an alert reader, you should be wondering how we can expect to provide more double precision megaflops/buck than the FPS-164. After all, when someone offers you a disk with a very high megabytes/buck ratio, you know he is offering you a big, big disk! The way computers usually work is that when you double the investment in the CPU, you more than double the performance. It's like this:

Them Automated Factories

Surely it is evident that the 6502 is essentially a PDP-8 fabricated on a fully-automated production line? And that the 68000 is a fully-automated PDP-11/45? In its 8MHz version, that is. The evidence indicates that the 12.5MHz version can beat a low-end VAX running integer-type calculations. Well, the Intel 8087 and the Nat Semi 16081 are fabricated an fully-automated production lines while the FPS-164 is essentially hand-built.

So, what we are going to do is take advantage of fully-automated production lines! Who says we do not follow our own (implied) advice?

Oh, yes: the DRAM board will be wave-soldered, not hand-soldered as the DTACK board is. Why don't we wave-solder the DTACK board? The board was not laid out with that in mind. Wave-soldered boards have to have small pads and skinny line spacing to avoid solder bridges. The DTACK board has large pads and thick lines to survive hand-assembly work.

The consequence is that the DRAM board will always be fully socketed while the DTACK board always has exactly as many sockets as required for the amount of memory ordered.

Page 4, Column 1

PUBLIC DOMAIN:

You want a complete set of Shakespeare's plays? Well, O.K. but it is going to cut into your time watching re-runs on TV. Oh, you just want an ornamental edition to look good in your bookcase? In that case let's go into this bookstore here on Rodeo Drive in Beverly Hills. Ah! Over there! A really fine-looking edition with a hand-tooled leather cover. Inside we have good acid-free paper and look! it is hand-stitched. Sure glad you are paying for it, not us.

What's that? You say Shakespeare is in the public domain and that you don't have to pay for it? Chum, if you try to walk out of this store without making a stop at the cashier's desk that cop over there chatting with the attractive cashier is going to act just as though you have tried to knock over a filling station with a Saturday-night special.

We (slightly) apologize for our simplistic introduction to the subject of copyright, public domain and ownership rights. However, it has become evident to us that a number of our readers misunderstand some aspects of these subjects and, much more important to us, misunderstand our attitude to our own property rights.

First: the fact that something is in the public domain does not mean that a physical embodyment is free, as we trust we made clear in the opening paragraphs above. In fact, you may be surprised to discover that the artwork and perhaps even the custom typeface (!) used to print that Shakespeare collection may be legally copyrighted so that you cannot (legally) photocopy it!

As Norman Herzberg reported in the last issue, the FIG-Forth manuals are in the public domain, but you must pay if you want thee to send you a copy. FORTH was originally developed with government funds at Kitt's Peak and hence is in the public domain, right? Well, the version that was developed at Kitt's Peak 14 years ago is certainly in the public domain, but the version now being offered for sale by FORTH, Inc is distantly removed from that primitive version and is definitely not in the public domain!

Gary Kildall developed the first version of CP/M using government funds, so that first version is in the public domain. It has been considerably improved (some would say slightly improved) since, and the current version is not in the public domain.

A very complete disk operating system plus some high level languages and a whole bunch of applications programs were developed using government funds to run on Honeywell minicomputers. So all of that stuff was, and is, legally in the public domain. The folks who

Page 5, Column 1

wrote that software, or headed the teams which wrote the software, were the founders of Prime Computer, a minicomputer manufacturer which opened its doors with a complete sofware base for its Honeywell-compatible minicomputer line...

How do you get ahold of public domain software? Now, that is a problem. If you go to Kitt's Peak or to FORTH Inc and demand a copy of that early public-domain FORTH, you will be ignored. If you go to Gary Kildall or Digital Research and demand a copy of the early public-domain CPIM you will be angrily told to '(expletive deleted) off.' If you go to the Prime Computer folks and demand a complete set of that public-domain stuff developed for the Honeywell minicomputers you will be told to shove it up your nose.

The simple fact is, the law does not require anyone to go to any effort to provide you with copies (physical embodyments) of anything which is in the public domain. Charles Moore, Gary Kildall and the Prime Computer founders wrote that early public-domain stuff and thus had access to it. The law does not require them to pass a single scrap along to you, friend.

You might, if you know where the material is, and if you have lots of money to pay attorney's fees, get copies of government-funded public domain stuff under the 'Freedom of Information Act.' But 'Act' fast, the Reagan administration is trying hard to dismantle that Act (too much politically embarrassing stuff gets revealed).

But not all public-domain stuff is a result of government funding. Not even the 'FoIA' is going to do you any good here. Your best bet is to find someone who, for public spirit or for (hopefully small) profit is willing to help you get your hands on public domain software, for instance. But if what you really want is an impressive hand-tooled edition of Shakespeare's plays you will have to pay and pay and...

Now, about copyrighted material: for the benefit of those readers who do not follow Jerry Pournelle's column in BYTE magazine, let us reiterate the point (obviously not understood in the software industry) that the Copyright Act requires that you support lending libraries and requires that you support free distribution among persons who are handicapped in certain ways.

If E. E. Milne, who we believe is the author of the Winnie-the-Poo stories, were in the software industry he would set up machine-gun pillboxes across the street from childrens' libraries and shoot the kiddies down as they came out of the library with one of his books.

Page 5, Column 2

To summarize, your rights of access to stuff in the public domain are perhaps smaller than you thought, and the ownership rights of copyrighted software are less than most software copyright holders believe.

This brings us to this newsletter, which has a copyright notice on the front, and to our software, which has copyright notices on the source code.

We are continually amazed by the otherwise sensible persons who think we do not want our newsletter to be copied. The simple fact is, it costs us more to print and mail (in the U.S. and Canada) a copy of the newsletter than the $1.50 per copy that you pay (honest!). When it comes to the subscribers from elsewhere, who pay $2.50 per copy, be advised that the postage is $2.00 (!) per copy, and the printing cost is just under a buck. So we lose money for every copy mailed, and we cannot sell boards to those overseas folks to make up the difference!

It is more cost-effective (for us) for you to photocopy our newsletter and hand it over to your friends/colleagues than it is to ask them to send us $15 for their omn subscription! We applaud Ned W who claims that he makes about ten photocopies of each issue as it arrives, and we deplore Terry P who asserts that he makes several cohorts read his original copy so as not to violate our copyright.

Besides, if you give your friends photocopies they may make second-generation copies in turn and we may, eventually, be read in Kabul on Sunday afternoon ...

Now, about the copyrights on our software. They are there to protect our interests against Fortune 2000 companies. We really do believe that HALGOL, and maybe some other stuff, will be useful and we do not believe that Gigantically Amalgamated Motors should profit unfairly from our work.

On the other hand, the disks we pass out are not 'locked' in any way. And the source code, which is the primary documentation, is included on most disks. Suppose that a small company tries to 'rip us off.' There are two possibilities: either they give us credit, by mentioning the source of the code (small pun) or they try to keep it a secret. If they try to keep it a secret, we will either not find out about it or we will. Suppose we do find out:

NOW THE FUN STARTS! We get to write nasty letters to editors of magazines such as BYTE pointing out the heinous transgression of the company stealing our software. This will: A) Provide free advertising for us, B) Provide free advertising for the company

Page 6, Column 1

swiping our software, C) Let others know the existence of useful 68000 software which is readily and easily swipeable and hence help the spread of such software, and D) Let readers know that our company also has software for our boards.

We see this as a win-win scenario which will help us and help anyone swiping our software PROVIDED (!) they are not a Fortune 2000 company. We would be inclined to sue a Fortune 2000 company that tried to 'rip us off.' Why? For two reasons: one, it would offend our sense of 'rightness' and two, sueing large companies can be very profitable if your legal rights are clear (the Copyright Act is very clear and unambiguous).

But if you have a dinky little outfit with as few as 500 persons on your payroll, we have no interest at all in enforcing our copyright rights. You will have to either give us a an acknowledgement or risk getting called bad names in 'letters to the editor' columns,

We ask the reader, if he or she is friendly-inclined towards our little endeavor, to give lots of photocopies to your friends. If you subscribed to this rag and subsequently decided you made a mistake, please give lots of photocopys to your enemies.

WE GET MAIL:

"You can too use the DTACK board with the SuperPET! Here is how it is done... Finally, give DRAM a break! Surely, you can't blame DRAM for the (apparently) inadequate power supply in the Apple II? My refrigerator has yet to kill WordPro (running in DRAM in the PET)!" Terry P, El Cerrito CA

Terry, we are truly impressed by your achievement with the SuperPET. To the rest of our readers, we will modify our statement that the two are incompatible. But it takes a willingness to work hard, some knowledge of both hardware and software and considerable perseverance to accomplish that task. For most of you, we suggest that you not consider trying to mate the DTACK with the SuperPET.

Now, about that DRAM: we now come to the moment of truth (small t division) with regard to your FNE's assertions. In the past we manufactured static RAM-based products exclusively, and promoted static RAM as being superior to DRAM. Well, now we make both kinds, so what does your FNE assert?

Static RAMs are simpler, faster and more reliable than dynamic RAMS. To us, that translates as better. We have never claimed that DRAM, especially in larger configurations, are not a lot cheaper than static RAM. Although DRAM is a little slower and a little less reliable, it is suitable for many applications, as we

Page 6, Column 2

pointed out a long time back.

But we would not wish to do a structural analysis of a skyscraper design using DRAM that did not have error detection and correction circuitry.

Some people trim their philosophies to suit the product they are currently selling. The most favorable expression designating such persons is 'weathervane', the rest are considerably less favorable! We are not a weathervane! Not incidentally, the reason we tell you that the 68000 is the very best CPU available for the single-user single-tasking market is that we honestly believe that is true.

When a better CPU comes along, we will jump ship immediately! As we expect to do in about two years when the 68020 reaches what we have called 'stage 4.' Of course, when we jump ship we will carry HALGOL along with us because the 68020 will be software compatible with the 68000. Unlike Intel, Motorola has already made the necessary transition into the world of real computers.

Sorry, folks, we got a little carried away there. This is supposed to be the mail column.

"Let me risk initiation into the O.I. club. What is wrong with a simple FORTRAN-based system for the APPLE-DTACK? How about airing your language prejudice concerning FORTRAN?" Richard R, Dallas, TX

Richard, the O.I. club is very exclusive, having a membership of one. There is absolutely nothing wrong with a simple FORTRAN-based system for the Apple DTACK except that no such system exists. We have no prejudices against FORTRAN (although it is slightly outdated), and there are many useful programs which could be run if a FORTRAN were available at a comfortable price. We suspect that a real 68000 FORTRAN which compiles to native code and has an acceptably small number of bugs would probably have a licence fee of $10,000 per CPU. Then there would be the hassle of hooking that into the Apple and the wonderful Apple-compatible disk drives.

If anyone knows of a cheap, suitable FORTRAN please let us know about it'

"A message to the software stone ages: I have read your recent newsletter and felt somewhat annoyed by the methods described for parsing. This is definitely not the sort of thing I want to read in a newsletter I have paid for..." Bernhard M, Kandel, W. Germany

Page 7, Column 1

(This letter was received a couple of days after #20 was mailed, so Bernhard had not yet seen the admission that we were guilty of a small hoax.) Bernhard, watch what we are doing, software-wise, for a few more newsletters and then write us about our progress, O.K.? And thanks for the kind words about our hardware plans. Sure wish we could sell you some".

"Dear FNE: I wish to purchase a 12.5 MHz DTACK board with 60K memory for the Apple II+ with all documentation. I have a minor problem in consummating the purchase. Actually I have several problems. I am not absolutely (or even relatively) sure of the present price for the board. I as not certain exactly where to order the board. I am not certain to whom I should make out the check. I assume a personal check will be usable if it does cause delay.

"You may detect a note of criticism in the paragraph above. If you did not, re-read it..." Eric E, Norman OK

Eric, we certainly do not wish to upset anyone, especially someone like yourself who sends us a (perfectly acceptable, by the way) personal check. We have this thing called an 'info packet' for persons who are thinking of buying boards, and which will answer the questions you had and, perhaps, ease some of your uncertainties. All you had to do was phone us, using the phone number we publish in our full page ads, or write us it the address published in every newsletter requesting such info.

Several readers have suggested that we include prices, etc in every newsletter. We think this would give the newsletter a more commercial flavor than it already has, so we don't do that.

Anyhow, we appreciate your check, which we received on June 8. We hope you like your board, which we shipped on June 10.

"I have seen numerous comments about market windows in the newsletters. Well, my humble opinion is that the 68000 market window is jammed shut and will take dynamite plus crowbar to open. Perhaps HALGOL is that 'window opener'... Wish I had bought Coleco 6 weeks ago at $24 a share... Let us know how Uncle Jack is doing in his crusade to help everyone else market computers." Nils D, Wethersfield CT

Nils, if you had purchased $1000 worth of Commodore stock in 1972 it would now be worth $700,000. Uncle Jack is doing fine, thanks. And since when were you ever humble?

Page 7, Column 2

If you had that $700,000 you would be aware that the 68000 market window is frozen shut only at the bottom end. Have you placed your order for LISA yet? Would you like a truly superb single-user UNIX/68000 system for $35,000? Your implication that some inexpensive software is what it will take to unstick the 68000 market window at the lower end is exactly correct.

We're trying, but nobody else is as far as we can tell.

"I now work for Boeing Computer Services, Richland and have been using every computer in the book. My original task was to convert six FORTRAN programs to a CRAY from a Univac 1144... (the CRAY) will compile a 10,000 line FORTRAN program in under 11 seconds, with optimization.

"The FORTUNE is being fought over because of its word processor... Unfortunately any other function runs too slowly because of disk access and slow disks. But one great word processor! [Nooo! Don't tell us that FORTUNE's UNIX is slow on those floppies! - FNE]

"Working in data processing for a living gives a different perspective an computing... Languages are a hot topic. A lot of people do not like PASCAL and the ones that do only like certain implementations. Most would like ADA to dissapear and Modula 2 to show up on a system they could use it on. [And isn't pre-processed into PASCAL? - FNE]

"Hardware discussion abound, and everyone wants a 68000 based micro... everyone has been unhappy with how few systems look promising, or are affordable. Software is a big problem." Bill J, Richland, WA

Bill, why is software a problem, we ask innocently? - FNE

"With regard to the rather presumptuous categorizing of computer buyers into three groups, you are incorrect. The new breed is the average homowner who wants a useful word processor/letter composer/learning tool. Game sales are not exactly booming around here... most of the Apple owners I know are not technically oriented; their reaction to the words 'attached processor' is incredulous. You are more likely to see some specialty firm [like a graphics house, we ask innocently?] use your board as the central processor for a custom system than you are to make a fortune on 'attached processors.'

"...how many companies presently manufacture a working 68000 main board for less than $1000? Good, now how many of these companies are avoiding the marketing of lower cost development boards (based an a low cost

Page 8, Column 1

variation of their one and only main board) like the plague? And what is the minimum entry price for anyone wanting a working 68000-based computer (let's start with a Sage II, two floppies, terminal, printer, 256K RAM, assembler software, etc.) otherwise? Now, just who is 'The Establishment' when it comes to low-cost 68000 products? ...will all the DTACK newsletter subscribers who own Vic-20s please stand up?" Nils D, Wethersfield CT

Nils, we did not understand that you really were serious calling us 'The Establishment.' What we are trying to do right now is figure out whether that is a compliment. Addressing our other readers for a moment: Nils has well-earned the title 'Faithful Correspondent.' There are some persistent themes to his letters that we will cover without quotation.

Nils consistently wants a cheap-as-possible large-memory 68000 board. If we toss in expendability, that is exactly what the 128K Grande is. But $745 is way, way over the price he wants. Nils obviously needs expendability because he constantly writes of the benefits of multiple processors, which implies expendability. It just so happens that we agree with him on that subject in two ways: the use of multiple high-performance processors as a (relatively) cheap array processor, and the use of single low-performance CPUs as I/O processors (the fruity machine, as Nils calls it). How the heck we can provide what Nils wants at what Nils would call a low price, we dunno.

The only way to make a really cheap 6800X board is by using a slow 68008 with a 2764 and just one static RAM with a few empty sockets for a few more RAM, and leave off the expansion parts and the buffers for the expansion ports and the extra memory decade for the expansion ports - and Nils makes it clear that that is not what he wants. Nobody else has written us asking for a non-expandable system, either.

Next, Nils (and a select few others) want us to offer blank boards. We agree that the thought of blank boards is a good idea, but when it gets down to real situations, we have Nils' EMS blank-board review in the last issue. You sell people blank boards, they call and want special (or hard-to-get) parts. They call and want design info. They plug in no-good chips bought at surplus and then they want to send you the board, along with those no-good surplus chips, of course, for trouble shooting. This may be your idea of a good way to run a business but it is not ours!

Finally, Nils wants us to un-bundle our hardware from the software (so that the price will drop a couple of hundred dollars, presumably). Huh? Now, it is true that developing software is an expense, and our customers do pay for that expense, the Tooth Fairy

Page 8, Column 2

being unavailable. Nevertheless, software development is a one-time expense. Only in Looking-Glass-Land can an accounting system be devised which will drop the price of a board more than the media cost for the software, if the software is deleted. And we already offer that: $63 off the DTACK board and $15 off the Stuffer, if bought less all documentation, including software media.

But Nils' closing mutterings about a nationwide chain of Eloiburger stands worries us...

[Exerpts from this next letter are being quoted in reverse order because it makes more sense that way.]

"We have about 50 PCs on campus [Washington U, St Louis] and I can find no one that has had a parity error. We have one PC that was run 8-16 hours a day, 5 days a week, is a terminal to (a) mainframe, and no parity errors (it has 128K). Hmmmmm I bet you guessed correctly on not putting nasty old parity on that unreliable dynamic RAM.

"How come so much for the memory - $150 for 128K - that's by my count 16 chips, and in lots of 100 (if my memory is correct, it takes 132 chips to make a gallon) [close!] I can buy 150 nsec for $6 a chip... you are overcharging on chip cost by 50% - almost as good as IBM. First time that you seem to be charging excessive for chips alone.

"Let's see, you can either switch modes (your wording) and save some memory, or you can have it all there at once. Maybe you will be the Carl Helmers of memory land (gosh Batman, a megabyte is so such, no one will notice if we borrow some of it).

"The mailman has been stealing my magazines, and he even got so cute as to lift the REDLANDS from the current [#21] newsletter (but left the rest).

"The stuffer board works except I got to write ay own stuff or modify yours." Bob P, St. Louis MD

'write my own stuff or modify yours?' Bob, you seem to have forgotten the obvious third alternative, which is, uh, just a second now...

Here we go to a great deal of trouble piling up the felgercarb, then squaring, cubing and tesseracting it beginning an page 2 of #21 and you notice REDLANDS is missing?

About memory usage: you should have been to the FORTH Interest Group meeting we attended last week in Fountain Valley. Those guys are still pounding their chests over how compact FORTH code is. One of the

Page 9, Column 1

officers (we think) proudly demonstrated some real complicated algorithms (hex to decimal?) as written in PASCAL and FORTH. Sure enough, FORTH was more compact. Whoopee. Shortly after, we stood up and displayed the prototype full-gallon Grande and asserted that we were less impressed with that compactness than we might have been ten years ago. That officer (?) jumped to his feet and refuted us thusly: "But this is source code!"

(Actually, we were at the meeting to hold up the megabyte 60000 board and ask when somebody was going to write a 32-bit FORTH. An attendee already had! Sigh.)

About our memory prices: we are descended from a long line of highway robbers. You have maybe heard of Procrustes? Just how, we ask, could we have otherwise devised our modest and moderate business practices?

Finally: since you have ordered Grande serial number one (a full gallon, how about some applause there folks!) we are pleased that you like DRAM. But Bob: after getting our secretary thoroughly accustomed to receiving missives asserting that negotiable funds are enclosed which enclose no such funds, you sent a letter asserting that funds were enclosed which did have funds and now this letter which asserts that no funds are enclosed and, in fact, no funds are enclosed and our poor secretary is terribly confused! Shame!

"I read about your difficulties selling your 68000 board to a godless westgerman like me. It has taken me a year to collect the $1000 for a 60K 12.5MHz board. Could you be so merciless as to say you are not able to sell me the board?

"Perhaps you can sell me the board for the super special price of about $490, and sell a disk with HALGOL and so on for another $490 to my friend. No one need know what is on the disk.

"I think there must be a way to manage it and I as silent as the grave. In any case write me as soon as possible what you think I must do to get your board." Understandably Anonymous, W. Germany

U.A., that idea would not fool even the stupidest U.S. official, and some U.S. officials are very stupid indeed (including some in high positions of authority, your FNE mutters darkly). We were not kidding even a little bit when we said we do not want to go to jail! This is the third or fourth such letter suggesting simplistic circumvention of export regulations. Uh, uh!

By the way, we recieved a (different) letter from another W. German, on another subject, who pleaded with

Page 9, Column 2

us not to publish his letter because the English grammar was not perfectly correct. Well, his English was one heck of a lot better than our (non-existent) German! We definitely do not criticize, or make fun of, someone whose second/third/fourth language is not absolutely perfect.

Instead, our practice is to edit any letter that is too awkward to be read swiftly (as we did the letter above) while leaving in occasional foreign colloquialisms which tend to provide a pleasurable 'flavor'. Nor do we mention this under ordinary circumstances. Please do not be afraid, if you are a foreigner, to write to us due to imperfect English.

Since the 68000, even the L12, and 100nsec Toshiba RAMs are readily available in W. Germany, maybe somebody ought to be manufacturing the board over there? We will have to give this some serious consideration...

"...I enjoy your editorial opinions and find (to my horror!) that I usually agree with them. Especially your remarks about Pascal. I have programmed extensively in Pascal over the past five years (mostly because, until recently, it was the best language available for micros). I assume that you've heard about Modula-2 by now - I have Volition System's implementation for the Apple and, although I haven't used it much yet, I think Wirth has corrected most of Pascal's major deficiencies.

"I'm interested in learning more about artificial intelligence in general and LISP in particular. I'd be particularly interested in a DTACK implementation of LISP - a language that runs painfully slowly on 8-bit micros. As a matter of fact, it'd probably be fun to write the interpreter myself - somebody must have written a book on how to do it..." William W, Silver Spring MD

William, or Bill, you forgot to sign your letter. Anyone who usually agrees with our somewhat extreme views must have his head cross-threaded. Nevertheless, you seem to be our best candidate to write a review of Volition's Modula-2. How about it? Is the size of an array part of the data type in Modula? Are we correct in guessing that Volition's Modula-2 is really a language pre-processor for Pascal?

In exchange, we will pass on any information we recieve as a result of your letter about LISP. For instance, a chap named Bruce who lives in San Pedro knows a bit about LISP. You want to write the interpreter yourself? Do you suppose it is possible to pass hi-tech microbes via newsletters?

Page 10, Column 1

IN THE BEGINNING

was Shockley, who got the most publicity, and Bardeen and Brittain, who did the most work. On 23 Dec '47 they succeeded in making an unspeakably crude germanium point-contact transistor work. The three shared the Nobel Prize in physics in 1956, but by then Shockley had already left Bell Labs (Bardeen stuck around and picked up another Nobel in physics, the only person who has received two Nobels in the same field. Curie got hers in physics and chemistry, in case you were wondering.)

In 1954 Shockley Semiconductor Laboratory was set up in Santa Clara County as a subsidiary of Beckman Instruments. Shockley's (scientific) reputation attracted some very talented staff members. However, Shockley proved no great shakes at running a company so, two years later, eight of those staffers left as a group.

This group, which included Gordon E. Moore and Robert N. Noyce, persuaded Fairchild Camera and Instrument to set up Fairchild Semiconductor in Palo Alto. In what was to become a tradition, Shockley publicly denounced the members of that group as the "traitorous eight!"

By 1958 the Fairchild group had developed the 'mesa' transistor and in 1959 they developed the 'planar' process, although it was not announced until 1960. In June, 196B Bob Noyce left yet another employer as he resigned at Fairchild. Gordon Moore followed shortly after and the next thing you know, there they were at Intel with founder Andrew S. Grove.

This left Fairchild hurting for talent - its stock also dropped when Noyce left - so they hired the head of Motorola's semiconductor group, Clarence Lester Hogan. Hogan then turned around and raided Motorola for seven more staffers, known as "Hogan's Heroes." Fairchild's stock promptly went back up where it had been. Motorola placed Hogan's former assistant Steve Levy in charge and promptly brought suit against Hogan and his Heroes (and their wives under Arizona community property laws) for damaging Matorola's business. Levy did such a good job that Motorola was unable to show any damage in court, so Motorola lost the suit, finally, in 1973!

(The preceding information came from the 50th anniversary issue of Electronics magazine and the 25th anniversary issue of Electronics News.)

This brings us up to the present. A group of Intel staffers have spun out of Intel and established another company. A high official at Intel, named Robert N. Noyce, is busy denouncing them, publicly calling them

Page 10, Column 2

disloyal and threatening lawsuits. We assume that Bob Noyce has a very short memory, having done that twice himself! (Who's the wise guy who asked, "Whose ox is being gored?)

A PERSONAL ENCOUNTER:

In the fall of 1977 we were approached by a staff member of the Canoga Park, CA office of Bolt, Beranek and Newman. BB&N is the world's largest acoustic consulting organization. The Canoga Park office had a contract with the Air Force, at Wright-Patterson AFB, to recommend an appropriate acoustic noise monitor for the Air Force NOISECHECK program. Upon the Air Force's acceptance of their recommendation, the Canoga Park office was to purchase four instruments, field test them and write operational manuals for the instruments for Air Force use.

The instruments had to meet certain specifications but were also to be evaluated on a 'human factors' basis. The prime candidates for the award were Metrosonics in upstate NY, Digital Acoustics Inc in Santa Ana, CA... and the BB&N Instrument Company in Cambridge, MA (!). The BB&N Instrument Company was a subsidiary of Bolt, Beranek and Newman and the office of its general manager was just down the hallway from the President of BB&N, who happened to be a fellow named Steve Levy. Isn't this the save Steve Levy who once ran Motorola Semi so efficiently that Motorola lost a lawsuit to Fairchild?

Well, we had a hunch at the time which of the three candidates was going to be selected by BB&N's Canoga Park staffers but we decided to put forth a good-faith best effort anyhow. Surprise! BB&N recommended to Wright-Patterson that the Digital Acoustic proposal best met the objectives of performance and ease of use. The Air Force accepted the recommendation and BB&N proceded to place an order for four DA607P Environmental Noise Monitors with us. The order was placed out of their Cambridge office, whether because the amount exceeded Canoga Park's spending authority or to escape California sales taxes we dunno.

We delivered pretty much on schedule and the equipment was quickly accepted. So all was sweetness and light? Ha ha (said politely). We will skip over some of the occurences because there is no point in harming the innocent. But we came out with a one-page promotional brochure on the DA607P which, in one paragraph, stated that BB&N had recommended our DA607P for use in NOISECHECK and that the DA607P had indeed been selected for that program. We also mentioned that BB&N had purchased four units for later delivery to the Air Force. All of these things were true, accurate and factual.

Page 11, Column 1

Next we received a telegram on 2 Jun '78 which read: "WE HAVE BEEN INFORMED BY OUR CANOGA PARK OFFICE THAT YOU DO NOT INTEND TO HONOR OUR REQUEST OF JUNE 1 TO DELETE ALL REFERENCES TO ANY USE OF OUR NAME BY DIGITAL ACOUSTICS, INCLUDING BUT NOT LIMITED TO ADVERTISEMENTS OR INFORMING THIRD PARTIES THAT B B N HAS MADE ANY PURCHASES OF YOUR PRODUCTS. YOU SHOULD UNDERSTAND THAT WE ARE CONSULTING OUR COUNSEL TO DETERMINE OUR LEGAL REMEDIES IF YOU PERSIST IN YOUR INTENTIONS TO MIS-USE OUR CORPORATE NAME.

BOLT BERANEK AND NEWMAN INC RICHARD M LUCASH STAFF ATTORNEY"

We thought the matter over for about three minutes, deciding on an appropriate reply to the implicit threat in the telegram. We finally picked up the telephone and called the head of the Canoga Park office, read him the telegram, and then stated that if we had to use a single word to express our attitude toward the telegram that the word would be "contempt." We went on to remind the Canoga office head of the John Peter Zenger case (we hope you studied your high school American History, because we aren't going to explain that one!)

Several days later we received a personal phone call from the President of BB&N, one Steve Levy. In the course of a conversation that lasted about 45 minutes we were told of the extraordinarily high ethical standards by which business should be conducted. We were told that although it might, tehcnically, be legal for us to reveal our connection with BB&N over NOISECHECK, it would not be the highest ethical behavior. We tried to explain that his staff alligator down the hall at the BB&N Instrument Co. was chewing on our ankle to the extent that it was impossible to keep our head in the clouds. Steve did not seem especially happy with the results of his call when he finally hung up (did we ever tell you that your FNE is stubborn?).

A couple of years later BB&N, still under the leadership of Steve Levy, was accused in Federal court of swiping big bucks from the U.S. government. Two BB&N vice presidents were convicted in Federal court on felony charges in connection with the matter...

The reader might be interested to know that the BB&N Instrument Co. was recently sold by BB&N to a Swiss outfit. We hope that staff alligator doesn't have any trouble learning to yodel.

All the stuff on the previous 1 1/2 pages is either on the public record, or, in the case of the Steve Levy phone call, we were personally involved and can attest

Page 11, Column 2

to the truthfulness of the story. The next little gem is apocryphal:

BEST WAY TO BUILD A COMPUTER

In 1952 Wilkes presented his landmark paper entitled "The Best Way to Build a Computer" before a philosophical society. In that paper, he outlined the principle that is now known as microprograming. He gave the paper before a philosophical society because there mere no computer societies then.

Let us skip about 25 years to the middle-to-late 1970s. A computer company (somewhat like Burroughs) had three different plants where their business computers, all mainframes, were built. One plant designed and built their large mainframes, another the midscale machines and the third the small mainframes. Each plant had a totally independent staff. Every three or four years all of the plants would be directed to develop a new computer line. (Quite reasonable considering the continuous advance of computer technology.)

The staff designers (you prefer 'engineers'?) at the large and midscale plants were very IBMish with their white shirts, ties, business suits and Detroit iron. They would arrive promptly at 8:30 AM and leave promptly at 5:00 PM. The folks at the small-scale plant were wierd. They wore T-shirts with holes in them, beards and long hair, and they drove Volkswagons or Datsuns. If you were at the plant any hour of the day or night you would see somebody arriving at work just as someone else was leaving.

The latter group found themselves designing a new small-scale computer the very year that fast TTL ROM became cheap enough for commercial use. So they microcoded the operating system, using Wilke's methods. When the big cheeses from corporate headquarters got around to the small-mainframe operation, they were horrified! The new small mainframe outperformed their new midscale mainframe!

The solution was obvious: the bearded freaks were ordered to remove the microcode and to do the operating system in software like everybody else. End of apocryphal story.

COMPETE WITH YOURSELF?

Horrors! Compete with ones' self? Why would anybody want to do that? (To be profitable, even to assure one's continuation in business maybe.)

Protecting ones' own products from competition from ones' other own products is a necessity in some

Page 12, Column 1

circles, no? Like the apocryphal story about the Burroughs-like computer company above. Like the deliberately busted keyboard an IBM's PC to protect their Displaywriter. Like not at first releasing CP/M (or any programming language or operating system) with Displaywriter, which is in fact an absolutely vanilla Intel 8-bit machine, to protect the low-end mini 'positioned' just above it. (IBM has just recently relented and released CP/M for Displaywriter.)

There are some areas of the personal computer marketplace which we (deliberately) do not follow, such as Atari, Mattel, and all the kiddie stuff covered by Compute! magazine these days. That is, we follow the VIC-20 and CBM 64 only from a market-impact standpoint.

So we thoroughly enjoyed Ron Jeffries' recent newsletter covering the peculiar and hilarious antics at Atari, including the 'turf' wars between the game division and the personal computer division and the way a bunch of Atari products were made deliberately inferior to protect the marketability of other Atari products! That is, the antics are hilarious if you are an Atari competitor. If you are an Atari stockholder, they are tragic!

We call your attention to our own DTACK Grande. We did absolutely nothing to cripple that board so as to protect sales of the Grounded static-RAM board. The Grande is the best and most cost-effective machine we could build, given that the idea is to run as fast as possible while using reasonably priced (translation: 150 nsec) DRAM. Lots of DRAM, as much as could economically be put on one board. Which means you don't use one board, you use two - one of them a piggy-back board.

In fact, it was our best guess that just publishing a photo of the DRAM board would severely cripple sales of the static RAM board. To our surprise, the sales of that board really took off the first two weeks in June! (Sales have subsequently slowed, however.) Why? We dunno. Maybe school vacation and wanting something to learn the 68000 with during the summer? Graduation presents?

The next board we make will be deliberately designed to be as attractive for purchase as possible, thus taking business, potentially, from the GROUNDED and Grande boards. This surprises you? Then you obviously did not read issue #10, page 14.

(In point of fact our near-term 'next' products will be peripheral devices which can be used with either the static or dynamic RAM boards. The Stuffer is merely the first such example; see the front cover of this issue [we hope!] for another.)

Page 12, Column 2

Coming down the line before long will be the QD-1, which will be assigned the model number QD-1W before it is offered for sale. 'QD' stands for 'quick and Dirty', while 'W' - eventually - will stand for 'it Works'. We may have mentioned previously that there is much to be said for things which work. 'Quick and Dirty' means just what it says, a product designed to be first rather than best.

The QD-1 will have a socket for a Nat Semi 16081 math chip, a Centronics parallel printer part, and several software RS-232 'like' input and output lines, driveable by software (!). Because our TTY-40 printer, all 390 lines per minute in its 80-column guise, is currently being driven thusly by our 1976-vintage 6502-based attached processor, that's why.

The Centronics parallel port is for an Epson printer or a Houston Instruments TP-41 plotter. If you can't afford an HP $15,000 plotter, read the specs on the TP-41 and TP-42. The TP-41 runs $3,000!

And the reason the 16081 math chip socket will be unpopulated is that the 16081 is not yet a purchaseable part. But it is in sampling, and we do, as reported earlier, have one. More important, we have a schematic for the QD-1, ready for prototyping using our 3M prototyping system. (This time we will put the bypass caps and the Vcc/Vss connections on first, Ron.)

We currently have three 'game plans' to get the National math chip running. Here is the situation as we understand it: preliminary spec sheets, which is all we had up to 3 weeks ago, showed a 28-pin device with some pins assigned functions specifically and solely to make it easy to hook the 16081 up as a peripheral chip to any micro, not just Nat Seei's micros. These dedicated pins have been dropped on the final product, which is a 24-pin package whose spec sheet sakes no mention whatever of the possibility of its use as a peripheral,

On the other hand, it is not nearly as intimately hooked into the Nat Semi micros as the Intel 8087 is hooked into the Intel 808X. That's background. Now, the three game plans, in order of decreasing optimism.

1) We have a young project engineer who believes spec sheets. The latest spec sheet says that the necessary clock (6 MHz for now) is asynchronous from everything else, including instruction stores and data fetches and stores. The thing about young project engineers is, you have to let them try their ideas out. Either they work (good) or they don't and the young engineer gains valuable experience. The first prototype will assume that the exact wording of the latest spec sheet is correct. If this works, the prototype gets cast in a printed circuit layout and becomes QD-1W.

Page 13, Column 1

2) Our long-in-the-tooth project engineer does not believe the (latest) preliminary spec sheet is accurate, and that the various stores and fetches must be synchronized with the (6 MHz) clock. Since we do not want to slow the 68000 down, this will require a one-rank bidirectional latch setup to implement. If approach #1 does not work, we try this next.

3) If Nat Semi has in fact succeeded in 'locking out' foreign processors, then we use a 16032 as a math chip driver. This will explain the uncertainty published elsewhere in this issue regarding the exact nature of the forthcoming 'array processor'.

In fact, the QD-1W will be an essential first step towards that array processor. And, we will offer the QD-1W for sale (fairly cheaply, with that empty math chip socket) for others who want to jump on the math chip as soon as possible. Or who maybe want to play with one megabyte print spoolers or TP-1 plotters driven directly by a 680000.

It is understood that the QD-1 will be capable of working with both the static and dynamic RAM boards.

OMINOUS HAPPENINGS:

Those of you who favor the 68000 for the magnificence of its internal resources (16 each 32-bit registers - imagine!) and for its linearly addressable 16 megabyte memory space and for the fact that 12.5 MHz parts have been readily available across the counter for over a year now have cause to worry.

AMD and Intel have been running a concerted series of what can politely be referred to as 'misleading' ads comparing the Intel 286 to the 68000. Via a series of (understandably partisan) tactics they have managed to make the 286 seem considerably superior to the 68000. In contemporary American advertising practice their actions are proper; comparison advertising is the way advertising is done these days,

This is true of grocery stores, soft drink firms, automobile manufacturers and (oh, yes:) personal computer manufacturers. If one does not reply to those advertising assertions, where every vendor understandably places his own best foot forward next to his competitor's highly visible worst foot, the public will believe those assertions. As the public is beginning to believe those 286 vs. 68000 comparisons.

True, most engineers can see the fallacy in those comparisons but the buying decisions in the personal computer marketplace are not being made by engineers. And, in case you have not yet noticed, the personal computer marketplace is, or is becoming, the computer marketplace. The numbers, and the dollars, are in the

Page 13, Column 2

$2000-$5000 price range right now, although that range is moving down. Even MINI-MICRO magazine acknowledges that, although MINI-MICRO itself targets the multi-user $25,000 and up range.

But Motorola, for reasons known only to itself, is ignoring the mass personal computer marketplace and is, as far as We can determine, continuing to court vendors of $35,000 and up UNIX systems who will sell about 50 units a month. In the meantime, IBM is shipping 50 THOUSAND personal computers a month using Intel CPUs and they are unable to meet the demand!

Perhaps Motorola thinks nobody believes those ads. We have news: almost everybody does believe them! In PC WORLD, Vol 1 #5, on page 42 we find: "The (286) is two to three times faster than the Motorola 68000 even though both chips can address the same amount of memory." This is presented as a simple, uncontested fact. It gets worse. On page 45: "But the 186 and the 286 are substantially faster than the 68000." Again, offered as simple fact. We trust that it will come as a considerable surprise to readers of this newsletter that the 186 is substantially faster than the 68000.

The point is, the author (who happens to be James Fawcette) obviously believes he is reporting the facts. And the buddreds of thousands of readers will believe those 'facts'! Certainly Motorola has taken no action to make James believe differently! Doesn't Motorola understand that it is not the engineers that make the buying decisions these days? And that the people who make the buying decisions will believe uncontroverted claims of relative performance? Why should they not?

(This is how bad it is: Intel is now asserting, as reported by James on page 45, that the segmented memory used by the 808X is superior (!) to the 'flat' memory of the 68000! Why not? Motorola won't tell anybody otherwise!)

Perhaps Motorola is content for the 68000 product line to be a footnote in the history of the semiconductor industry, to be shipped by the dozens in $50,000 multi-user UNIX systems and by the dozens by eccentrics like Digital Acoustics and Analytical Engines.

Why should proud Motorola pitch its product to the vendors of those $2000 to $5000 machines, who are shipping about 150,000 units per month now (all vendors) and who will soon be shipping a million units a month as that price drops to the $1000 to $2500 range? After all, the 68000 is suitable for use in a truly large and complex system. Right?

Isn't this where we began over two years ago?

Page 14, Column 1

SHORT STUFF:

LeRoy L informs us that Syquest has solved the removable-media problem and is now shipping 20 evaluation units a week, and hopes to improve that to 80 a week shortly.

Have you seen those masses of 68000/UNIX systems that were going to take over the small computer world? We haven't. We see lots of IBM PCs and lots of PC clones, though.

The multi-line HALGOL screen editor is operational as of mid-June, and the hard stuff - parsing - is being written, slowly of course.

The Modula-2 offered by Volition Systems seems to be a language pre-processor written in Pascal which converts the Modula-2 code to Pascal. The version they offer for the Apple is written in Apple-Pascal and the version that runs on the Sage is Softech Pascal.

There are now more than 440 pages of this newsletter in print, and we have begun the third year of publication. The first newsletter was mailed an July 25, 1981 (and should have had an August, not July, date). Has it really been that long?

If you really need to find a bookstore in Beverly Hills, we recommend Hunter's. It's not on Rodeo, but it is close to the Wilshire-Santa Monica Blvd intersection and on the north side of Wilshire. It also happens to be a good bookstore of the old style.

Prudent persons looking for winners in the forthcoming 3-piece-suit personal computer marketplace bloodbath would not bet against either Commodore or Sinclair/Timex. You read it here first!

Has anyone noticed that after we said we were going to stop criticizing the Apple Computer Company that we stopped criticizing them?

We are enormously pleased by the nice, clean signals and the splendid timing margins on the prototype Grande (this is a paid advertisement).

The troops who answer the phone at Digital Acoustics tell us that they get a lot of inquiries about a 68008 under-the-hood board. But we have received only one letter in response to our specific inquiry in the last issue, and that writer really wants a half-gallon. Maybe the folks who want 68008s are semi-literate?

You are not going to believe this, but we will have a case for the DTACK boards, with or without power supply, within 90 days. A pretty case with wooden end-pieces to match stubborn FNE's cranial cavity.

Page 14, Column 2

DEATH GRIP:

If you purchased one of the first six Stuffer boards by serial number, you may be wandering why you received two demo disks, one in the shipping carton and one in the mail. What happened was, on the day we were going to ship those first six units, we personally converted a box of ten blank disks into Stuffer demo disks, turning them over to Death March Dunkerson to label them and apply the write protect tab, as usual.

The next day our intrepid young project engineer checked out one of the four remaining disks and discovered that it would not read properly. We assumed that this was due to the use of an Apple II other than the usual one to copy the disks, so we hurriedly put another six disks to those first customers in the mail, this time using the usual Apple to clone the copies.

A (very) few days later, we received a phone call from Jack N in New Jersey. He had received the mailed copy before the UPS shipment, and had not been able to read the disk! When he inspected the disk, it did not seem to rotate well in the cardboard jacket. On a hunch he removed the write protect tab and presto!, he had a perfectly good disk! Jack suggested, tactfully enough, that we were putting on the write protect tab too tightly.

When we asked Death March how she applied the write protect tab, she boasted about how tightly those tabs were applied, even about the little 'pinch' she applied in the cutaway area. We are considering changing Death March's nickname to Death Grip.

And if you have any of our disks that are hard to read, try removing the write protect tab. You might want to replace it, gently!

Incidentally, those first six Stuffer boards were ready to ship exactly a week before we got the documentation and the demo disk together. Isn't it ever thus?

IT AIN'T A BUG!

Honest. What we are talking about is what happens when you use a byte-oriented monitor to try and read - or, in the case of Peter Soule's monitor, disassemble - the code in the bootstrap ROM (actually PROM). It never occurred to us that anyone would use a monitor, which is clearly intended for use in RAM, to try to read the bootstrap. We were rudely alerted to the contrary very early in this game (by the purchaser of board #1 or #2, we forget which).

The problem is that the bootstrap is unmodifiable (by most users) word-oriented functional code and so, as a matter of hardware design, it is NOT decoded byte-wise,

Page 15, Column 1

just word-wise. You try to read it out using a byte-oriented monitor and every other byte will be garbage.

Like we said, our customers found out about this very early in the game and accused us of hiding something. So we added on another section to demo program 'CHECKSUM', which all of our customers have, usually on the very first disk they ever got from us, or on disk '1 of 3' for more recent customers, Apple division. After displaying the registers, the checksum and the version of the ROM, you are invited to press 'RETURN' again. This will carry you into another menu, in which you are invited to select which 128 bytes of the ROM code on the CRT in hexadecimal.

Since this code has existed since day two, it should be obvious that we are not trying to hide anything!

And shame on Peter for writing a byte-oriented disassembler! Is it not obvious that a 68000 disassembler should be word-oriented, hmm? As one of our humorless W. German readers asked, "Have you seen any odd instructions lately?"

Incidentally, the reports we get indicate that the latest version of Peter Soule's monitor/disassembler works pretty well. Unless you just like to shoot rocks, ten bucks for a disk and nine pages of documentation is quite reasonable. See newsletter #20, page 11.

TRAP FOURTEEN:

The first section of demo program CHECKSUM, like demo program MON (and a few others) show how to use the instruction TRAP #15 to interrupt a 68000 program and display the registers and status bits. TRAP #15 has to work in conjunction with a system call, which is SYS P+27 in the case of the PET and CALL P-27 in the case of the Apple. This implies that the host is running in BASIC so that such a call can be issued.

While developing the HALGOL BIOS, in which the host is running in machine language (as recommended by Norman Herzberg and others) this creates a problem. The TRAP #15 goes through a jump vector in RAM which is initialized on RESET to point to the MON routine at $00020E in the bootstrap ROM. What the MON does is immediately dump the status register word into RAM along with all 16 32-bit registers. (Boy, do we ever hope that none amongst you are trying to use that hokey 'user stack pointer.' We are all supervisors, right?) Well, right after that it starts shoving those 66 bytes at the host.

And the host code for the HALGOL BIOS is sitting there trying to interpret those 66 bytes as a series of commands and data. Don't work very good. Sigh.

Page 15, Column 2

So, we first put in a code patch which used BIOS Command #0, which instructs the host to execute an 'RTS', returning the host to BASIC so that CALL P-27 can then be issued. This works, BUT the process of sending Command #0 trashes the status bits and a few of the registers.

TADAA! COMETH THE CAVALRY!

To the rescue, that is. Back in June of 1991 when the DTACK bootstrap was written and hand-assembled (the Hand-Assembler's Helper, program ASM, was written later) we decided to make the TRAP vectors, all 16 of them, point to locations in RAM. Upon reset, the first fifteen of these vectors, TRAP #0 thru #14, are initialized to point to the bootstrap 'IDLE' routine at address $000122. As noted earlier, TRAP #15 is initialized to point to the MON routine.

So, we wrote a very short routine, listed below, to solve the status bit and data register 'trashing' problem. Then the initialization routine for HALGOL has one instruction added to point the TRAP #14 vector (which resides at $001050) to this short routine. We save the status register and the troubled data register, issue the necessary commands to return the host to BASIC, restore the data register and the status register and then execute our old friend TRAP #15 and voila!, real honest un-trashed registers and status bits on the CRT!

(In addition, the hex code for TRAP #14, $4E4E, is easier to remember than TRAP #15, which is $4E4F. Talk about lazy!)

 40E7      MOVE   SR,-(A7) 
 3F05      MOVE.W D5,-(A7) 
 4EB84514  JSR    CMD1 
 3A1F      MOVE.W (A7)+,D5 
 46DF      MOVE   (A7)+,SR 
 4E4F      TRAP   #15

DIVIDE AND CONQUER:

Not the world folks, just bugs in the code. When we have some 68000 code that goes off into never-come-back-from land, we first put a TRAP instruction in the middle someplace, see whether it still goes off, and continue accordingly. Once we begin to get reasonably close to the bug, we like to over-write branch instructions with the TRAP instruction, and examine the status bits to be sure the branch would have gone the way we think it should have.

This is a surprisingly simple and effective debugging method that takes a little practice to get used to but is definitely worthwhile.

Page 16, Column 2

The closest thing the 6502 has to the TRAP instruction is the BREAK instruction, $00. The BREAK instruction takes you to the IRQ vector, at which point it is possible to examine a status bit to determine whether one arrived via the IRQ interrupt or the BREAK instruction. Messy, inefficient, and there is only one BREAK.

The 68000 has sixteen separate TRAP vectors. Since we have provided a six-byte area in RAM for each, each TRAP can pass thru a 'long absolute' jump instruction to any place in the 16 megabyte addressing range of the 68000.

In case you are a little vague on how this 'TRAP' stuff works, when the 68000 recognizes the TRAP op code, $4E4X, and decodes X to determine which of the sixteen vectors is needed. The 68000 then jumps to the location defined by the bootstrap ROM and starts executing code, which means that it is desirable that there is code to be found at the destination of those vectors in the bootstrap ROM. And that is why we initialize all but the last trap vector in RAM to $4EF9 0000 0122, which is a 'long jump' to the IDLE point in the boot ROM.

If you want it to jump to a different location in, say, the 64K 'zero page', all you have to do is change the $0122 to wherever you want the TRAP instruction to wind up (remember to have some code there before modifying the vector!).

As we have told you many times, the 68000 is more complex than the 6502, but this makes the part much easier to program, once you get the hang of it.

MULTITASKING REVISITED:

All of you readers are doubtless well aware that we HATE multi-user systems (which share one CPU) and that we are not even overly fond of single-user multi-tasking systems, always noting the exception that a full-time computer professional can make effective use of such a system, if he has adequate software and hardware such as a $35,000 system running UNIX.

Many of you have suggested that a type-ahead buffer might be desirable, and an Intel type (of all people!) convinced us that print spooling in RAM is a good idea, if we have enough RAM to spare. (Print spooling is traditionally done on disk, but most of us have disks that are too small and too slow for that.) Now, let's see: where can we find a CPU with enough RAM to spare for a 'spooling' buffer?

While a type-ahead buffer, which our CBM 8032 has, is a form of multi-tasking, it is a very mild form and not the sort of thing we were referring to. What we meant

Page 16, Column 2

(honest!) was that we were not in favor of running a word processor, general ledger, a spreadsheet and a graphics application (rocks to be shot down?) all at once. So we are not actually changing our philosophy, we insist! Got that, Nils?

So here is how to do multi-tasking, er, print spooling on the GRANDE: we add one more six-byte area to the end of the sixteen TRAP vectors. We initialize the first two bytes to $4E73, which is called RTE (ReTurn from Exception) by Motorola. We would have preferred RTI, return from interrupt, but Motorola got there first and they insist that an interrupt is just a particular form of exception.

What normally happens 500 times a second, or every two milliseconds, is that the 68000 is interrupted by a hardware counter. This is a level-4 interrupt. The level-4 interrupt vector in the bootstrap ROM points to a location in the ROM which executes four MOVEM.L (all registers) to four successive pseudo-locations in RAM. Our supersecret PAL memory decode devices decode these pseudo-locations as addressing all RAM simultaneously as far as RAS (row address strobe) is concerned, but not CAS. So none of the RAM is actually changed, and none of the status bits or registers since we are (pseudo-) writing to RAM.

(True, the interrupt saves the status register on the stack anyhow, but it does not save the data and address registers.)

Executing each MOVEM.L instruction pseudo-writes to 32 word locations. Four such instructions write to 128 words of memory, which is exactly as many as is needed to refresh the commonly-available 64K DRAMs. O.K., we have refreshed our DRAM, now what?

Now we jump to that location in RAM just past the TRAP #15 vector and, if you have not modified that location, the RTE is executed and we continue where we left off when the interrupt arrived. Our calculations indicate that the overhead for the interrupt is about 3.6%, by the way. We claim 4% in our advertising.

BUT, if you modify that vector, you can execute some other code 500 times each second before returning to the main program. You might even want to modify that vector to jump to a print spooling routine. You WILL remember to save any registers affected by the print spooler and restore them before executing an RTE, Non't you? (Nils, why are you crying and rolling around on the floor?)

Of course, you can execute another routine to implement a type-ahead buffer before executing the RTE...

Page 17, Column 1

OLIVER HEAVISIDE:

In issue #20, on page 10, we wrote about Oliver Heaviside and how the Mathematical establishment stole his ideas without giving him credit. In the latest issue of IEEE Spectrut magazine, Jul '83, there is a feature on Oliver, who seems to be celebrating a centennial. The article is entitled: "Oliver Heaviside: genius and curmudgeon" and is written by Paul J. Nahin of the University of New Hampshire. Let us offer a few quotes from this article, which you can then compare with what we wrote two months ago:

"For none of these achievements does Heaviside receive present-day recognition. A search for his name in textbooks will show only a brief mention, if anything. Others recieved the credit. For instance, today electrical engineering students are taught the Laplace transform to solve linear problems involving discontinuities; most of them are never told of Heaviside's pioneering work.

"When attacked for the vague meaning of his operational calculus, his pragmatic reply was, 'Shall I refuse my dinner because I do not fully understand the process of digestion?' Some years after Heaviside's death, Professor H.T.H. Piaggio wrote in a review article on operational calculus, 'Yet Heaviside's results were always correct: Could a tree really be corrupt if it always brought forth good fruit?'

"...But the Royal Society mathematicians remained unmoved and had no sympathy merely because Heaviside got the right answers to problems no one else could solve. [Please read that again! - FNE] They considered his approach a mathematical blasphemy, a worship of the devil practice of ignoring the 'real' problems of mathematical rigor, and so they censured him..."

Now: did we give it to you straight or not?

TRACE MODE:

Earlier we suggested one method of troubleshooting 68000 assembly language code. There is another way (probably many other ways) which can even be used alone or in conjunction with the 'divide and conquer' approach. Basically, the idea is this: wouldn't it be nice to know at what address the last two dozen or two thousand instructions were executed, just before your CPU went bye-bye? And what the status bits were after each instruction?

Well, the Motorola 68000 has this built-in hardware debug feature called a TRACE Mode. Here is how it works: first you stick some code someplace outside the line of fire. This code need not be in zero page.

Page 17, Column 2

What we do at this location is optional; we 'do something' and then execute an RTE, or 'Return from Exception'. If we destroy the content of data and/or address registers in the process, we must save those registers first and restore them before the RTE.

But 'do something' can be formidable, if we take care.

The first thing we do is set aside 8K bvtes that will not be used by the program to be debugged or by the program's data (Holy Artichokes, Batman, we have lots of memory, right?). 6K of the memory will be reserved for a circular list of 1K items, each item having 3 words or 6 bytes. The item is the status register contents after the instruction being traced is executed (one word) followed by the contents of the program counter (the address of the next instruction, two words).

Although the trace function is (naturally) disabled during execution of the trace exception processing, it may not be clear that the trace is also disabled during interrupt processing, as in software refreshing on the Grande board. Nevertheless, we do not want to continue to add to the circular list once our program has gone, for our purposes, bye-bye. So, before invoking the trace function, we will want to define the lower and upper limits of instruction addresses. During execution of the trace function, we will check instruction addresses against these limits and avoid adding them and their associated status info to the circular list if the limits are exceeded.

We save the data and address registers which will be modified via a MOVEM.L at the start of the trace execution code and then restore them at the end of the code. Since we will be examining the content of the stack, the registers should be saved to a 64-byte location next to the 6K circular list, not on the stack.

We will need four stored constants, one variable and one flag. Two of the constants are the beginning and the end of the circular list. The other two constants are the beginning address and the ending address of the code to be traced. The variable is the pointer to the next entry in the circular list. All four constants and the variable should be long-word parameters.

The flag indicates whether the circular list has wrapped around or not, thus telling us whether we have 1K valid list entries or only 3 if the pointer is set to the fourth item from the beginning of the list. It seems simplest to make the flag a long-word parm, so that we can tell the number of instructions which have been discarded (over-written) on the circular list as well.

Page 18, Column 1

Before we can execute the trace code, we have to modify the Trace Mode secondary vector in RAM at $00102A. The secondary vector is initialized to $4EF9 0000 0122, which is a 'long absolute' jump to the 'IDLE' location in the bootstrap ROM. (These locations are the same in the static and dynamic RAM boards.)

So we leave the '$4EF9' alone and modify the long-word address following to point to the Trace Mode execution code. Finally, assuming the execution code is in place and the upper and lower limits of the code to be traced have been defined, we enable the Trace Mode by setting the most significant bit in the Status Register:

 ORI #$8000,SR

The first page of REDLANDS is the assembly listing for an implementation of the Trace Made function. Extensions such as multiple 'valid address windows', TRAP commands if certain invalid window limits are exceeded, etc. are left to the ambitious reader.

Oh, yes. To turn off the Trace Mode, just clear the most significant bit of the status register thusly:

 ANDI #$7FFFF,SR

HALGOL STUFF:

We are converging on the structure of HALGOL, and, as we indicated last issue, it is going to look a lot more like BASIC than we had earlier expected. The reason, of course, is that most of our readers - and customers - who can program, can program in BASIC. Another reason is that we believe that BASIC, properly implemented, is a pretty good language. For instance, Bill J, who works in a large (scientific) data processing organization, reports that his fellow workers hate BASIC but readily tolerate Hewlett-Packard BASIC. If you will take a look at the BASIC command and instruction set for the HP series 200 model 16 you will understand this.

The reason that HALGOL will look more like BASIC is that that is the language we think it should look like. As we learn more about the task we have set for ourselves, we are learning that what we are doing is designing a language pre-processor (!) in addition to the instantaneous (to the slow chemical computer) compilation involved, along with the reverse-compilation involved to allow instantaneous program editing and re-running, as allowed by most BASICS.

Dammit, that last paragraph is obscure. Let us try another tack: most of you have heard of the "Universal Turing Machine." This very simple machine has been proven to be capable, theoretically, of executing any

Page 18, Column 2

algorithm which can be written in any language for any computer. No one asserts that the Turing Machine can do so efficiently, of course.

The point we are about to make has been disputed in private conversation, so think this over: the instruction set for the Universal Turing Machine is VERY simple. We assert without proof that the Universal Turing Machine can be emulated by any practical computer language running on any practical computer, subject to the availability of adequate memory to execute the emulation. (Cobol is, barely, a practical computer language?)

Remember, the Turing machine is VERY simple. We would be very interested in any evidence that the machine cannot be emulated in FORTRAN or BASIC or ALGOL or LISP or even APL or FORTH. Absent such evidence, we will proceed an the assumption that our earlier assertion is correct. (As an engineer, we need not adhere to mathematical rigor.)

(An aside: anyone who is familiar with the extremely simple instruction set of the PDP-8 will recognize that it is very nearly a Turing machine with a 12-bit data width. And MANY computer languages have been implemented on the PDP-8, no?]

Since the Turing machine can execute any computational algorithm (read; computer program), and any language can emulate the Turing machine, then it follows that any computer program which can be written and executed in one programming language can be written and executed in any other computer language. (We are discussing what is possible, not what is efficient. We still don't want to write payroll programs in FORTRAN or structural analysis programs in COBOL.)

If we accept that the run-time package of HALGOL is, or will be, a computer language it follows that the algorithm being executed can be executed in any other language. Which means that it can be written in any other language. Which means that the 'front-end' of HALGOL can look like Modula-2 or even Pascal (choke) if we wish, rather than BASIC.

Which brings us back to the assertion that HALGOL will look like BASIC because that is the language we want it to look like, a point which we hope is less obscure now.

We have the additional advantage that we can fine-tune the form of the 'BASIC', the run-time package of HALGOL, and the intermediate translator to work together in an efficient manner. You all know how BASIC works and we have published examples of run-time HALGOL code for a year now. Perhaps we should spend some time discussing the translator?

Page 19, Column 1

THE HALGOL TRANSLATOR:

We will recall that HALGOL is being written to run very swiftly indeed on the 680XX series of microcomputers, and can be transported easily to any computer based on those microcomputers. The translator should be fast and efficient on the 680XX; compactness of code is not required (HP 68000 BASIC uses a 236K run-time package, we understand).

The best device we have been able to come up with is to use tables extensively. Now, we hate the jargon term 'table-driven', but the HALGOL translator will use lots of tables.

In issue #17, beginning on page 3 we discussed how to implement 'constant variables' and discovered that they could be handled exactly as named variables are handled, with an additional pointer to assure that the constants are NOT initialized to zero at the start of the program. The way the variables were referenced in the HALGOL code, by an offset from the start of the variable table, made the variables RELOCATABLE. If we need to move all the variables say, 138 bytes higher in memory, all we need to do is move all of them and then add 138 to the base pointer to the start of the variables.

We, in this case three of us, have discussed this matter further and have decided that the whole HALGOL run-time code can be made relocatable by the use of more tables, thus greatly simplifying the task of inserting and deleting lines in the HALGOL program, the one the chemical computer sees.

TYPES OF TABLES:

Tables have elements which are either fixed in size or not. Elements which are obviously not fixed in size are variable names, constant variable names, and label names where a 'label' is the location of a GOTO or GOSUB.

Tables whose elements are fixed in size are manipulated by the 68000 with great ease; this need not be discussed here. There are several methods - we can think of three - of manipulating tables with variable-length elements. Each of these methods involve tradeoffs between compactness and speed. We (singular, this time) have selected the intermediate method because it seems to us that the slow chemical computer will never notice the inefficiency during edit time and also because these tables are not used at run time!

Here is an example of how we will construct our variable-element tables: suppose we have a table containing (just for example) the elements "CC", "B", "ABCDE" and no other elements. Here is the hexadecimal

Page 19, column 2

representation of the table in memory:

 02 43 43 01 42 03 41 42 
 43 44 45 00

(The above representation assumes ASCII code. Naturally, neither the Apple nor the PET use ASCII.)

From that representation, we can infer the rules for these tables. Each element is preceded by a byte defining, in binary, the number of bytes in the element. This byte forms, in conjunction with the auto-increment addressing mode of the 68000, a link to the next element. A zero link defines the end of the table.

Although the name given to such a table is subject to some controversy within Digital Acoustics, it has been decided [ahem that such tables will be termed 'linked ASCII tables'.

As noted earlier, these tables are not used at run time. They are used during program entry and program listing. During program listing we have the number of the entry, what we want to do is list the name. Obviously, this is accomplished by jumping from link to link until the desired number of elements have been skipped, and voila!, there is the ASCII name of the Nth entry in the table.

During program entry, we want to know one of two things:

1) Is that name (ASCII string) already entered into the table? If so, what is its number? .

2) If the name is NOT in the table, then what is the number and location of the next entry?

Consider a variable name: if the name is already in the table, we just need to know the number to place in the HALGOL run-time code, shifted three places left to indicate 8 bytes per element in the table of variable values. If we are going to maintain a crunched form of BASIC for listing purposes (and we will), then we will also need that number for the crunched code,

If the variable name is NOT in the table, then it is a new variable. We add the number of characters (bytes) in its name, then the name itself, then a HEX(00) to indicate the NEW end of the table. We need to allocate another 8 bytes in the variable value table, and we need to shuffle blocks around if needed to avoid overwriting other parts of the program (this is a very important aspect of the translation process and will be covered separately in a future issue).

Page 20, Column 1

Labels can use common subroutines to search the table of label names, but if a match occurs we have a WHOOPS! DUPLICATE LABEL ERROR! almost instantly after the programmer hits 'return', entering a program line with a label name already used.

Associated with the variable name table is the table of variable values, which has a fixed length (8 bytes) for each element. There is a one-to-one correspondence between the Nth name and the Nth variable value.

Also associated with the label name table are TWO address tables. One address table is the address of the label in the crunched code and the other is the address of the label in the HALGOL run-time code. Each element of the two address tables are long-word (4-byte) values so that our programs will not be restricted to 64K bytes.

The crunched code will contain a keyword byte for a GOTO followed by the number of the label. For maximum compactness, there will be two GOTO keywords, the first indicating that the number following is a one-byte value while the other indicates the following number is a two-byte value. We know of no BASIC programs with over 64K labels!

The HALGOL run-time code will contain the action address for the GOTO function, followed by the number of the label, which has been shifted two bits left (multiplied by 4) so that the number can be used to directly index into the table containing the label. If the number is stored as a word value, this restricts us to 16,384 labels in a given program. This seems reasonable for now and is easily fixable later if this proves to be a limitation.

So here is how the HALGOL run-time code for the GOTO function would work:

 GOTO  MOVE.W (A6),D0 
       MOVE.L #LADRBAS2,A5 
       MOVE.L (A5,D0.W),A6 
       JMP (A4)

In the code above, A6 is the HALGOL program pointer, LADRBAS2 is the base pointer to the start of the (HALGOL run-time code) label address table, and A4 is dedicated to point to the code to execute the next halgol statement (NEXT). The usage of A6 and A4 corresponds exactly to the more primitive, non-interactive form of HALGOL printed in earlier issues.

Note that (A6) rather than (A6)+ is used as the addressing mode in the first line. There is no need to use the post-increment mode in this case since the HALGOL program pointer is going to be changed anyway.

Page 20, Column 2

The first line fetches the number of the label, already multiplied by 4, to data register D0. The second line fetches the base address of the label address table to scratch address register A5. The third instruction uses the indirect, indexed addressing mode to fetch the absolute address in memory of the label in the HALGOL run-time code. This works by adding the 16-bit value in data register D0 as a sign-extended 32-bit value to the 32-bit pointer in A5 and fetching the long-word value at that location to A6.

(This means that we will have to be somewhat tricky if we have more than 8K labels since the next label number will index backwards! Hmmm.)

But the beauty of this method of executing the GOTO function is that it is completely relocatable! We can move the HALGOL run-time code anywhere we want and execute it unchanged. Of course, we DO have to change the elements in the label address table if we move the code associated with those elements, but that's easy, as we will discuss in another issue.

What is the HALGOL run-time representation for a label? There isn't one! Labels don't do anything, they are just reference points. And the location of the reference points is maintained in the label address table.

DO IT OUR WAY!

As you know, we believe in using labels for GOTOs and for GOSUBs. However, for short or quick-and-dirty programs, line numbers suffice. And many of our readers, not being assembly programmers, are unaccustomed to using other than line numbers. So, do we permit the use of line numbers or do we say, do it our way? Well, we've never cared much for dogma so we will permit both varieties of GOSUBs and GOTOS.

Which means that there will be tables for the line numbers, the address of the line numbers in the crunched code and the address of the line numbers in the HALGOL code. Actually, that last table, the one for the HALGOL code, is the only one we are adding. We already needed the first two. It also means that the GOTO keyword in crunched code and also the HALGOL action address are really different because they find their addresses in different tables.

But as long as the programmer can't tell the difference, who cares?

We seem to have merely covered the introduction to the translation process, explaining how the tables work and what some of the tables are, but we are running out of space for this issue. We will resume the discussion of translation in the next issue (we think)

Page 21, Column 1

As is our occasional custom, we bring you a few tidbits which were rejected by the National Denouncer as not meeting their most elementary editorial standards of accuracy and fairness:

80186 BUG, SON OF 8088 BUG

Or, A FUNNY THING HAPPENED ON THE 186's JOURNEY TO CONQUER THE WORLD. According to Colin Johnson's Data Files column in EET (Jun 20), the Intel 80186 has a bug even worse than the interrupt bug in early 8088's, reported here a couple of issues back. This one bombs a particular instruction if a recent DMA operation has been performed, Colin reports.

If that report is true, then there are potential BIG, BIG problems in the future because some manufacturers, notably IBM, have been stockpiling 186's for over 6 months now. Colin reports that "Intel is said to be considering recalling existing 186s." Well, Intel didn't recall those defective 8088s and they didn't admit to the problem in the 8088 data manual! (They did just the contrary: they specifically stated in the manual that the problem did not exist!)

You don't suppose that we might be seeing a selective recall, where IBM gets new parts but the unwashed don't? That would mean that IBM's "Popcorn" portable would not 'feature' that bug but Xerox's competing "Unicorn" would. Both "Popcorn" and "Unicorn" both use the 80186...

You see, IBM owns 12.5% of Intel. You don't suppose IBM might want a little edge on one of its major competitors, do you? Or an edge on those 50-200 other outfits that will feature 186-based products?

AAUUGGHH! WE GOOFED!

We are forced to confess that we were wrong when we told you, in issue #18, pg 17, under the heading 'ELECTRONIC NEWS WATCH' that a dinky little outfit like Commodore "obviously can't do anything to a true corporate giant like T.I."

You see, it seems that the $100 million loss T.I. is projecting includes a $205 million loss in T.I.'s home computer division and a $105 million profit in the rest of the company. T.I.'s integrated circuit division is operating at capacity right now (have you tried to buy any LSTTL lately?) and is thus highly profitable.

Since kindly Jack Trameil, with a little help from Sir Clive, has taken a $205 million dollar chunk out of T.I.'s hind end, it appears that we were way off base and that maybe Commodore CAN influence a true corporate giant like T.I.! Who would have believed it?

Page 21, Column 2

HIGHER MATHEMATICS:

This month's problem is to calculate, if T.I. has a $205 million dollar loss and one million home computers in the field, how much T.I. has lost on each of those computers? The time limit for this test is five minutes.

YUKS AND CHORTLES DEPT:

T.I. spokesman Norman Neureiter is quoted in Infoworld (Jul 11, p.3) that "The major element in this sudden and unanticipated change in T.I.'s home-computer business was the sharp fall-off in its software sales to retailers beginning the latter part of May."

Fall-off in software sales? Two humored and five million dollars? Who is kidding whom?

In EDN's 23 Jun '83 issue the table of contents lists, on page 293, "Use less code for fast 8080 multiply." We wonder how the extra space got inserted between "Use" and "less"?

The Apple III is now going for $1695 and the 5MB Profile for $1395 (as advertised in L.A. Times sports section). That's with 256K but without the monitor. We might buy one. Why? About 10,000 former Apple II hackers are now proud (?) owners of 'the shiny Apple', that's why. If 500 of them buy full gallons to protect their investment (which might be over $9,000), that happens to be a one million dollar market for us, which is attractive. How $9,000? Well, the III started out at about $5000 with 256K and the Profile Winchester disk started at $4,000 to $5,000, no? After all, we don't have an investment in hardware to make except for the III itself; the DTACK board just plugs in and runs.

And to think that reader Bob P recently accused us of not being greedy! Friends, greed is an important, indeed pervasive part of your FNE's makeup. Why else, we ask, would we contemplate the purchase of a III?

Oh, yes: the IIIs are being sold off to make room for the IIIe. Just thought you'd like to know. From the point of view of someone wishing to support the IIIs that have already been sold, we would want the III, not the IIIe. Right?

We bet none of you have heard, up to now, about "raster keyboards" and "bit-mapped interfaces." DATAMATION (May '83 p.82) states unequivocally that the Apollo Domain has these features. Folks, we strive tirelessly to keep you abreast of the latest in technology...

Page 22, Column 1

In that same article, the Apollo spokesman brags that the operating system for the 68000-based Domain is written in Pascal and hence that they are not 'locked into' the 68000. What a marvelous idea! Now, why didn't Fortune Systems think of that so that they would have a transportable operating system? What's that? You say we should review our own newsletter #16, p 7, col 2, the paragraph beginning 'You don't' halfway down the column?

Hmm. We see what you mean. We would have preferred a reference to page 2 of that same issue, where we asserted: "The people writing operating systems in p-code are either idiots or they are deliberately trying to sabotage the sales of their own computers! (With notable success, we add.)"

[The situation must be really bad when a newsletter editor starts quoting himself!]

CORPORATE MUSICAL CHAIRS:

Commodore has dumped prexy-of-the-month Parks and has not replaced his yet. Microsoft's Bill Gates hired Towne away from TEKTRONIX a year ago to run the company, and then Bill proceeded to continue running the company and now Towne is out. Surprise? No, exactly the same thing happened with Lore Harp and Fred Snow at Vector Graphics a few months back, but you didn't read about that one in Infoworld. Why? Well, Lore is a girl and the head of CWC (owners of Infoworld) is a boy. Those are facts. You know what sometimes happens when you rub two facts together...

We mentioned before that a company making an IBM PC clone, Compaq, is being sued for theft of trade secrets and patent infringement. We also reported the strange fact that the outfit doing the sueing is T.I. Well, it gets curiouser and curiouser. T.I. is proceeding with the suit, which is now at the discovery stage. This means, in part, that T.I. has to tell Compaq just what, specifically, they are doing to infringe T.I.'s patent(s). This is not necessary when the suit is first filed!

So everybody #as surprised when it turned out that the "patent infringement" turned out to be for the software in an Intel 8748 in the Keytronics keyboard used by Cospaq, and IBM, and just about everybody else making PC clones! Since IBM uses the same part in the same keyboard, naturally T.I. will expand its suit to include IBM as a defendant? Uh, no. It seems that T.I. has licensed IBM for that part.

But the T.I. attorneys could not produce the license agreement in court, presumably because the ink wasn't dry yet...

Page 22, Column 2

John D. McDonald, who is probably the best active American story-writer, just blew one. In the 20th Travis McGee adventure, Travis' buddy Meyer loses his home, which happens to be a boat named the John Maynard Keynes. The loss of the boat is incidental to the loss of Meyer's last blood relative, as it happens. Still, boats have to be replaced and sure enough, at the end of the book Meyer has a new home/boat. Here is where John D. blew it: the name of the new boat is the 'Thorstein Veblen.'

Veblen is a famous economist and is the author of "The Theory of the Leisure Class", published in 1899. He was best known for his ability to write about economics in a witty and entertaining way. When he wrote, in the book just cited, about "invidious comparisons of employment", he surely had in mind comparisons of regal 68000 assembly language programmers versus vulgar Intel 808X assembly language programmers.

But it is a plain fact that Veblen was a socialist, although he never publicly labelled himself. When the Bolsheviks took over in 1917, Yeblen "praised the Soviet system for abolition of private property and substitution of production for use, not profit" (quoting Broadus Mitchell).

We trust that Travis, whose politics appear to lean to the right, will never learn about this. (Travis is not smart enough to figure it out for himself.) After all, Travis trusts Meyer, who selected the name of his new boat. If we are lucky, Meyer will soon have a third boat, which can be named after a far superior economist: Thomas Robert Malthus.

In the meantime, if Meyer needs a name for the smallest room on his new boat, there is this living economist who is currently based in California...

We can forgive John D. for misspelling the programming language Cobol as "Cobal". It would worry us if he did know enough about Cobol to spell the name correctly.

Hear the wild, haunted cry of the lowly 808X assembly language programmer:

"WHAT SEGMENT AM I INNnnnn?"

Did we ever tell you that Bill Gates is a wealthy young man today because so many people stole his software? We do not believe that Bill, who is an extraordinarily intelligent person is some respects, understands this. We believe that if you offered Bill a time machine and a foolproof software protection scheme, he would take them. And use them!

Page 23, Column 1

The T.I. 9900: A Requiem

On our next-to-last visit to a Forth Interest Group meeting, this one about eighteen months ago, we participated in the usual B.S. session before the meeting officially started. One attendee asked of the group, "Why is the 9900 so slow?" We replied, because it doesn't have any registers, that's why. Another member of the group gave us an amused smile, and tactfully corrected us: "The 9900 does have registers, but it keeps them in memory, not on the chip itself."

We did not say the memory had no registers, we did not say the desk had no registers, we did not say... well, what we did say was that the 9900 has no registers. Surely it is apparent that we were correct?

Let us consider a register-to-register add using the 68000, this one a 16-bit add so we can directly compare it to the 9900. In a no-wait-state 68000 that instruction will execute in just 4 memory cycles, or 0.32 microseconds at 12.5MHz. The reason that no additional time is required other than the time required to fetch the op code from memory is that the 68000 pipelines one level of instruction fetch with the execution. The register-to-register add takes place entirely within the 68000 chip while the next instruction is being fetched.

Let us examine how the 9900 has to perform a register-to-register add, given that the registers are maintained in memory: First we fetch the instruction op code. That's one memory cycle. Next we fetch one of the registers. Two cycles. Now the other register, Three cycles. Now we perform the add. Four cycles, likely. Now we store the result back into memory. Five cycles, or (more likely) six if we allow time for the op code to be decoded prior to the first register fetch.

As you can see, maintaining the registers in memory exacts a terrible penalty in performance.

Why would anyone design a chip that works this way? Because the T.I. systems group wanted a chip-level version of the 990 programmable controller, which they called a mini-computer. Even the systems group has now caught on to the fallacy inherent in the design, which is why the T.I. PC (Professional Computer) uses an 8088, just like the IBM PC. But the 9900 continues to be used in the home computer that T.I. makes, and rumors indicate that the home computer division is not doing well these days.

We do have a purpose for raking over this story again besides defending our assertion that the 9900 has no registers. But we have to discuss another matter before we can tie the two ends together.

Page 23, Column 2

VIRTUAL MEMORY (AGAIN):

For the third time in this issue, we commend to you an excellent article. This one is not even remotely entertaining but it is highly informative. We refer to "Chip architecture; a revolution brewing" by Fred Guteri in (IEEE) Spectrum magazine, July '83. This article is a survey of the architecture of present and future high performance microprocessors, ranging from the 8086 (now over 4 years old) forward and including the RISC, which is not a commercial part, and the TMS 320 digital signal processor, which is not a microprocessor.

This wide-ranging article makes the point, among many others, that the 8086 and the 68000 are poorly suited for use in virtual memory systems. We can find no fault with that assertion. It is then pointed out that the Intel 286 and the Motorola 68010 are suited for virtual memory sytess and again, we agree. (Incidentally, the 68010 is now available across the counter in 8 and 10 MHz versions and in small production quantities, which is not true of the 286. Thus, it appears that the 68010 is about six months ahead of the 286 as far as availability in production quantities is concerned.)

If you read this article, do not make the dumb mistake we made. We were halfway through a page discussing segmentation when we made the sudden discovery that they were not discussing what we thought. You see, when we see a survey article covering both the 68000 (and the Nat Semi 16032) and the Intel line, the word segmentation immediately conjures up the fact that the Intel products are limited to 64K segments. Different subject entirely!

On p.37 we read: "Two types of addressing for memory management are being used... segmented and paged memory. Both are virtual memory schemes...

"The tradeoffs between segmented and paged memory are not easily defined because the two are often combined. Paged memory involves dividing memory into sections of fixed length, determined by the architects of the processor, and then fitting programs into these pages. If page size and program size do not match well, then swapping will not be efficient.

"With segmented memory, on the other hand, the user can define the amount of memory needed for a particular program. Small jobs can save space with segmentation, because the processor does not have to swap in a larger block of memory than is needed. But segmented memory can also create problems for the unwary programmer who specifies a segment size that exceeds the physical memory space. Although that is not likely to happen often..." You wanna bet? Stick around, folks!

Page 24, Column 1

LISA WATCH:

Many of you have written to us expressing opinions of LISA and some of you have written to ask that we express our opinion. We have, up to now, not commented such about LISA because we had little information about the production version. It may surprise you to learn that a local customer of ours has a pilot-production LISA, and has had it since about February. That machine had some teething problems, not surprising in the pilot production of a complex machine.

So we have restricted our comments to the operating system, which is written in Pascal and compiled to 68000 native code, and to the clock speed, which Apple asserts is 5MHz. (We would say 4.8MHz, which amounts to total agreement. You see, LISA uses an 8MHZ 68000 with 4 wait states, just like the EXORMACS, but three times less expensive!)

But we bring up LISA again because we have more information thanks to Richard Page, reported to be the manager of the LISA project. Mr. Page is quoted frequently in that Spectrum article we just discussed. And it turns out that LISA is a virtual machine! Even though there is general agreement that the 68000 is poorly suited for use as a virtual machine...

In fact, Mr. Page reveals that LISA implements memory protection using discrete logic, not the Motorola VLSI protection chips because they only support 8 to 16 simultaneous segments! Ye gods! And LISA is a single-user machine!

Quoting from the last paragraph of the sidebar on page 33: "This causes the 68000 to be awkward in Apple's LISA system, for example, according to Richard Page, manager of the LISA project, information on the machine's state must always be kept in main memory and constantly updated [emphasis added - FNE] in case a swap is made, so that the machine can begin again where it left off."

What do we have here? A 9900 all over again that keeps its registers in memory? Have we finally identified the real reason that LISA seems to run slowly?

As you can see, we had a real reason to bring up the 9900 again, and to place such emphasis on our correct assertion that the 9900 has no registers. It would be fascinatipg to have more information about just how the 68000 programmers keep all the state information in memory...

And now, about segment sizes exceeding real memory: When our customer received his LISA early this year he fell in love with one of the program utilities called

Page 24, Column 2

LISA-DRAW (we think). It seems that program made, in his opinion, an absolutely perfect foundation for a schematic-drawing program.

So he busily defined MUXes and counter chips and NAND gates and such and added them to the data base for his program. So if he wanted to invoke a 74LS157 MUX, it came up on the screen with all the functions labelled and the correct pin numbers already assigned. Everything went swimmingly until he finally overflowed the assigned segment. LISA, being a hard-disk virtual machine, then went out to disk and allocated another segment (page?) to the data base for the program.

Regrettably, the ProFile 5MB hard disk used by LISA was already nearly filled and so the virtual operating system over-wrote a significant portion of the operating system! And there was no backup because the special floppies used were not then available ...

This software bug in the virtual operating system will by now, one fervently hopes, be fixed. Remember, we have written proof in our correspondence files that 29 of you guys (no gals so far) highly approve of virtual memory!

If one tends to speculate, one might speculate on whether the 68010 is being retrofitted to LISA so the state could be kept inside the chip where it belongs instead of in memory like the lowly 9900. Hmmm?

MORE SHORT STUFF:

We need a Constitutional amendment requiring the death penalty for anyone who manufactures a computer which does not have a selectric-like keyboard. You will keep in mind that we make an attached processor, not a computer.

Scenario: the end of this century approaches. Newsletter editor unwraps the cellophane from new GigaVAX computer. 256-bit data bus, 1,000 MIPS, 200 Megaflops, a terabyte of battery-backup CMOS RAM. Cost: almost $200. Plugs computer into industry-standard keyboard and invokes 500 wordprocessors concurrently to get newsletter writing over quickly. Discovers there's nothing to write about...

It was bad enough when the Europeans rammed through the term 'Hertz' to replace the term 'cycles per second' instead of honoring Charles Proteus Steinmetz. It was when they decided that the unit of atmospheric pressure would henceforth be designated the 'Pascal' that we decided to get out of the environmental noise monitoring business. We don't make these things up, folks!

Page 25, Column 1

We (plural) got the Grande prototype working, a full gallon's worth, on the last day of June. That's just 24 months after we got the pre-prototype static RAM board working. No, the prototype Grande did not work when we first turned it on; it seems the interrupt does not work in a sensible fashion on the 68000.

Mickey Mouse wears a 68000 interrupt watch!

A complaint has been received that 'Grande' sounds too Detroitish. We had to call it something, and at least Grande starts off like GROUNDED, phonically speaking. (How else would one speak than phonically, one asks?)

Persons ridiculing our predictions in #21 will not wish to read about the Sanyo PC clone in Infoworld, 18 Jul '83. For $995 list, you get the main computer with 128K RAM, keyboard and one floppy. Delivery August. CRT is extra. This year.

The demo program written in Applesoft and the related program written in primitive HALGOL are not either "sieve of Erastothenes" programs. We were providing a direct comparison to ALF's 8088 FTL board, and we copied what ALF said in their ad. And ALF called that algorithm a "sieve of Erastothenes." Both us and ALF have been reprimanded by John Martellaro, editor and publisher of Peelings II magazine.

Nobody paid any attention to our sly aside about page 399 in June BYTE during the EMS review last month. Doesn't anybody want to know about the forthcoming massive 68000 system support from EMS?

TRANSOM DETECTIVES:

The darndest stuff arrives over the transom here at Digital Acoustics. We have just received a part of what might be an internal memorandum someplace:

"(Name Deleted) has been told by Xerox that they have been informed about the 80186 problem and Intel will replace their parts. IBM has been stockpiling the 80186 for some months for the Popcorn computer, so it goes without saying that those parts will be recalled. But will the smaller customer share in the recall? [sounds familiar - FNE] Intel told Xerox that they should have the problem fixed by January, 1984!

"I talked to one of the engineers at Xerox about the problem. It seems that the string move instruction (MOVS) cannot be used if one uses either DMA or the external HALT pin. Both DMA channels cause the same problem.

"The 80186 has been giving us a bad time lately -- here's a chance to help ourselves and do the potential

Page 25, Column 2

customer a good turn at the same time. Direct the potential customer to the EET article. A problem as serious as that should not be ignored -- and the delivery of 'good' parts has to be a long ways off for the small customer!"

THE BASKERVILLE HOUNDS

are well known because they did NOT bark. It is very interesting that our multi-issue 'compilation by template' writeup drew lots and lots of correspondence, spirited correspondence, but after three weeks we have not received one letter commenting on our (lengthy) prediction in the last issue. We have received lots of correspondence on other subjects during that time.

We aren't trying to declare an "Ain't We All Great" society but it is a fact that quite a few of our readers are non-stupid. To the extent that this newsletter is useful, a major part of that usefulness is a result of being able to serve as a communication path between non-stupid persons, especially persons of differing backgrounds and career fields.

You will recall that Sherlock Holmes made a significant and useful deduction from the fact that the hounds didn't bark. We hope the fact that none of you have commented on last issue's prediction is useful information to you.

(We hope that our readers did not just perceive that prediction as being too silly to warrant comment...)

WE GET MORE MAIL:

"A chilly, rainy 4th of July weekend finds me poring over the 2 1/4 pounds (!) of Dtack Grounded back issues which arrived the other day. Your newsletter is delightful; I love gossip and I've always been fascinated by arrogant iconoclasts (at least at a distance)...

"I am an artist... the next step must include a fast, powerful processor and a fairly high resolution bit-plane graphics device, the whole works capable of updating its images in 'real time'...

"You ask what a 'fell swoop' might be. I used to wonder the same thing. (Ahem!) In Act IV: Scene III of "Macbeth," Macduff is informed by Ross that his wife, children, servants, all have been murdered by Macbeth. In grief, Macduff exclaims,

'...O hell-kite! All?
What, all my pretty chickens and their dam
at one fell swoop?'"

Jim H, Pullman WA

Page 26, Column 1

Jim, how could you so describe your calm, moderate FNE? We have never clasted a single icon, although that waste basket of LISA's is mighty tempting.

Our 68000 boards and the very high res graphics prototype boards on the front of this issue are (or will be) good products but they are not capable of updating images in real time. The bad news is that no hardware exists anywhere at any price which will meet your 'real time' criteria.

We direct you to the magazine Cooputer Graphics World in general and to the interview of Gary Demos beginning on page 63 of the Jan '83 issue specifically. Here is a quotation from that interview: "This algorithm will produce images of up to 250,000 polygons in 100 seconds when supported by the Cray." The Cray 1 is a helluva machine but 100 seconds is not real time. The images comprising the movie TRON were computer generated but not in real time.

We suggest you stay well clear of that Shakespeare stuff. We have it on good authority that it is just a collection of quotations.

"SEIG HEIL! YOU VILL SCNAPP TO ATTENTION! [not what was written, but idea is same - FNE] ...I think we can agree that the Halgol and FP sources (not Pascal - FP compatible) are worthless when working under the Apple Pascal 1.1 Operating System. This obviously cannot hurt you, as you are thinking that there are only 5 Pascal users. My crossassembler is intended for Pascal users, to utilize your board for this operating system. Thus I am not attacking your shares of Phase Zero.

"Too, I'm quite fed up with this childish 'My programming language is better than yours' warfare. I think that most programming languages have a right to exist... I dislike those kind of players who have nothing better to do than to tell others what they have to do. [We agree. Can we use a GOTO now? - FNE]

"Phase Zero... I hate this bunch of thieves, as they have stolen my included return postage from me.

"Kernighan... Has this guy nothing better to do than write 16 pages why he dislikes something? His main 9 points against Pascal are plainly wrong (all of them)... By the way, his book "Software Tools in Pascal" is a perfect example of software which is useless to really anybody... Best regards," Oliver B, Hamburg, W. Germany

"P.S. You may sit down now..."

Thanks, Oliver... we think. Permit us to explain to our other readers that we have abstracted only a little

Page 26, Column 2

from your two page letter, but that the exerpts are representative of the entire letter. The business about "your shares of Phase Zero" is in reference to our refusal to feature his cross-assembler for the SECOND time in this newsletter!

In issue #16 we gave Oliver's firm, MOOOSE SYTEMS, a free one-and-a-half page ad. The writeup on his cross-assembler, the MUXA68, is on page 6 as is the address of his firm. Every info packet we send out contains the same information, if in shorter form. Oliver, just how many times do we have to feature that same cross-assembler before we don't have to schnapp to attention?

The Phase Zero people are not thieves. Let us explain simple facts to irate Teuton: there is no way that Phase Zero can mail that postage back to you without spending their OWN money! If we were in their shoes, we would have done exactly as they did (nothing!). It's not as if they are going to be able to use that international postage certificate to buy a beer, after all. At least when we bitched about West German thieves the amount in question was $25, not (appx) 25 pennies! (And what we were really upset about is that our file at our bank contains a false statement that we accepted money and did not deliver.)

How much money are you personally prepared to pay out of your pocket to return some idiots' unsolicited return postage? Surely it is evident that your return postage cannot be both affixed to the front of an envelope and inside that envelope?

Since you have attacked us and Phase Zero so vigorously, it is with an enormous sense of relief that we note you are also attacking Mr. Kernighan intemperately. Yes, we were aware that he is one of the authors of the C language. Come to think of it, we would worry if you attacked Kernighan and then approved of us...

The next time you order us to schnapp to attention while formally addressing us by our first, middle and last names, please try to get more than one out of three right, O.K.? But you have managed to get your Pascal-based cross-assembler publicized again, you clever devil! Interested persons are going to have to dig back into issue #16 to get your address and find what the new price is... and yes, folks, Oliver's closing salutation really was "Best regards"!

Commodore's high-end product line is but totally screwed up, at least in this country (FCC problems). Good thing the VIC and 64 are doing so well. In fact, 'so well' is a drastic understatement. We are being regularly approached by some damn competent people, from both the hardware and software side, asking us to

Page 27, Column 1

support the 64. When we have some useful 68000 software available, such as Phase Zero's BASIC or our HALGOL, we (very likely) will.

THE DTACK GRANDE:

Today is July 13, and we are entering the sixth day of almost continuous memory testing on the GRANDE. 'Almost' means whenever we are not checking out other programs, such as the 'HAT' demo. We are using a modified version of the second memory test for the static RAM board. Modified to avoid overwriting the RTE instruction in RAM which terminates the software refresh, in case you were wondering.

This memory test gets a string of random length, 1 to N where N is user-prograssed (16 is a good nominal value). Not only does each string have a random length, each element in each string is a random byte whose value ranges from 0 to 255. These random strings are sent to the 68000, which then copies the string end-to-end until the memory is filled, then the 68000 goes back and checks each string copy against the original, logging any errors it finds. If no errors are found, the program simply repeats indefinitely, using a different random string for each iteration.

We have yet to find our first error. Now, we know the program works, because you can pull a chip and the program will immediately log that as an error. Or, you can tell the test program to check 1024K instead of 1020K and immediately find some errors because, although the GRANDE does have 1024K, only 1020 of it is contiguous. Maybe all the alpha particles are hiding in the other 4K, which has not been extensively tested?

One thing we have definitely determined is that DRAM is a lot slower than static RAM. It requires less than a second to do a complete test, one pass, of the random-string procedure on the 92K Grounded board but the 1 megabyte Grande takes 8 seconds, about ten times slower!

And the 'HAT' demo program, after modification so that we have full handshake an each byte from the Apple side, runs nearly two seconds slower than the 10.8 second time logged by the static RAM board. The reason for the full handshake on the Grande software is that you never know when an interrupt for the 68000 refresh is going to arrive. The reason for no full handshake on the static-RAM Grounded boards is that the 68000 can always send the next byte before the 6502 is ready to read it, or accept a byte before the 6502 can send the next one.

In the next few days the Grande circuit board artwork will be modified to correct the few cuts and jumpers that are on the prototype board and we will order a

Page 27, Column 2

production quantity of the final versizn. Since we are not being flooded with orders - we have exactly one Grande order so far - there does not seem to be any rush. We should be wave-soldering the first batch the about mid-August. No, we are not even holding that one customer up; he has several 220K static-RAM DTACK boards already.

And we continue to receive orders for the GROUNDED boards. Maybe dynamic RAM is not as popular as we had believed? Of course, the first magazine with an ad for the Grande is just out now but we have almost 400 subscribers to this rag now.

Oh, well, maybe we can get rich selling very-hi-res graphics boards. Or QD-1W's. Or array processors.

Grande Expansion?

When the DTACK board (92K) came out, we were immediately asked whether we were going to introduce a memory expansion. We said, 'sure!' and all the people went away. About 9 months later several people wanted DELIVERY, which is not the same thing as asking whether we had plans. So we tell you, sure, we'll have expansion boards some day for the Grande. Guess when.

MORE ARRAY PROCESSORS:

Earlier in this issue we described Floating Point Systems, Inc as a good company and then stated we could beat their main product on a cost-performance basis, two statements which are somewhat contradictory. Not to worry. In yesterday's mail came articles on two new array processors, one from FPS Inc. Our "poor man's array processor" will not outperform the new stuff on cost-performance by a significant margin. Sigh. We will report on the new stuff in the next issue.

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

SUBSCRIPTIONS: Beginning with issue #19, subscriptions are $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. The address is:

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

O.K., so REDLANDS isn't much these days. That's because we have been busy with hardware lately, and will be for another month. Starting issue #24 or #25, we will doubtless draw complaints that we are publishing too much 68000 code!

Page 28

                          1 ;      MOTOROLA 68000 TRACE ROUTINE DEMO 
                          2 ; 
                          3 ; -- COPYRIGHT 1983, DIGITAL ACOUSTICS, INC -- 
                          4 ; 
                          5          FWRD    L 
                          6          BRANCH  S 
                          7          SHORT   F 
                          8 ; 
00010000:                 9 LSTART   EQU     $010000        ;CIRCULAR LIST ADR 
00011800:                10 LISTLIM  EQU     $011800        ;1024 ITEMS 
00011800:                11 LPTR     EQU     LISTLIM        ;LIST PTR, 4 BYTES 
00011804:                12 FLAG     EQU     LPTR+4         ;LIST OVERFLOW FLAG 
00011808:                13 LOWLIM   EQU     FLAG+4         ;LOWER PROG LIMIT 
0001180C:                14 HILIM    EQU     LOWLIM+4       ;HIGHER PROG LIMIT 
00011810:                15 TRTEMP   EQU     HILIM+4        ;12 BYTE TEMP AREA 
                         16 ; 
--OBJECT: TRACE.0 
  011820                 17          ORG     $011820        ;START OF TRACE 
                         18 ; 
                         19 ; THIS IS AN EXAMPLE OF HOW THE 68K TRACE ROUTINE 
                         20 ; CAN BE USED TO ASSIST IN DEBUGGING SOFTWARE. 
                         21 ; 
  011820: 48F980030001   22 TRACE    MOVEM.L D0/D1/A7,TRTEMP  ;SAVE REGISTERS 
  011828: 301F           23          MOVE.W  (A7)+,D0       ;STATUS REG TO D0 
  01182A: 2217           24          MOVE.L  (A7),D1        ;PROGRAM ADR TO D1 
                         25 ; 
                         26 ; IS THE PROGRAM COUNTER WITHIN THE DESIRED LIMITS? 
                         27 ; 
  01182C: B2B900011808   28          CMP.L   LOWLIM,D1      ;BELOW LOWER LIMIT? 
  011832: 6536           29          BCS     TRACEX         ;EXIT IF TOO LOW 
  011834: B2B90001180C   30          CMP.L   HILIM,D1       ;ABOVE UPPER LIMIT? 
  01183A: 622E           31          BHI     TRACEX         ;EXIT IF TOO HIGH 
                         32 ; 
                         33 ; SAVE THE PROGRAM COUNTER ADDRESS AND THE STATUS 
                         34 ; REGISTER IN THE CIRCULAR LIST. 
                         35 ; 
  01183C: 2E7900011800   36          MOVE.L  LPTR,A7        ;NX ITEM ADR TO A7 
  011842: 3EC0           37          MOVE.W  D0,(A7)+       ;STORE STATUS 
  011844: 2EC1           38          MOVE.L  D1,(A7)+       ;STORE PROG CTR 
  011846: 200F           39          MOVE.L  A7,D0          ;NX ITEM ADR TO D0 
  011848: 0C8000011800   40          CMPI.L  #LISTLIM,D0    ;ABOVE LIST LIMIT? 
  01184E: 650C           41          BCS     TRACE1         ;SKIP IF NOT ABOVE 
                         42 ; 
                         43 ; RESTORE THE CIRCULAR LIST POINTER TO THE START 
                         44 ; 
  011850: 203C00010000   45          MOVE.L  #LSTART,D0     ;BOTTOM ADR TO D0 
  011856: 52B900011804   46          ADDQ.L  #1,FLAG        ;REPORT LIST OVFL 
                         47 ; 
  01185C: 23C000011800   48 TRACE1   MOVE.L  D0,LPTR        ;PTR TO NEXT ITEM 
  011862: 4CF980030001   49          MOVEM.L TRTEMP,D0/D1/A7  ;RESTORE REG'S 
  01186A: 4E73           50 TRACEX   RTE                    ;NEXT INSTRUCTION 
                         51 ; 
                         52 ; SAMPLE INITIALIZATION ROUTINE 
                         53 ; 
  01186C: 23FC00002000   54 INIT     MOVE.L  #$2000,LOWLIM  ;SET LOWER LIMIT 
  011876: 23FC00002A00   55          MOVE.L  #$2A00,HILIM   ;SET HIGH LIMIT 
  011880: 42B900011804   56          CLR.L   FLAG           ;CLR OVFL FLAG 
  011886: 23FC00010000   57          MOVE.L  #LSTART,LPTR   ;SET START OF LIST 
  011890: 21FC00011820   58          MOVE.L  #TRACE,$10C2   ;SET TRACE VECTOR 
  011898: 007C8000       59          ORI     #$8000,SR      ;SET TRACE BIT 
  01189C: 4E75           60          RTS