EASy68K Home

August 1982

DTACK GROUNDED, The Journal of Simple 68000 Systems
Issue # 12 August 1982 Copyright Digital Acoustics, Inc

Last month we introduced you to a threaded 'programmable calculator-like' language. This language exists and it runs. Two of our older demonstrator programs use it. You may not believe this, but the heart of that language was written one Sunday afternoon in 20 minutes. We have a witness. It ran perfectly the very first time, with no bugs (it is VERY simple). Those of you who took the time to examine the source code on page 15 will recognize that there is VERY little 'interpretive' overhead. You will also recognize, then, that user definable extensions to that language can be easily added by assembly language programmers (providing the source is available on disk). As you can see by the program listing on page 16 of last issue, the program can be easily read and does NOT require one to do everything backwards.

Now, let us look at that again: we have a language (as yet quite primitive) which has vanishingly small overhead, is simple and bug-free, is user-extensible and supports documentation. One does not need a backwards 'set of mind'.

You know what? We think we have got hold of a good thing.


For starters, it is fairly obvious that the code must be entered using an assembler at this time. This cannot be considered a fully high level language for that reason. In fact, we really prefer INTERACTIVE languages such as BASIC. So we need to see whether this thing can be turned into an interactive language system WITHOUT losing the 'vanishingly small overhead' attribute. The proof of the pudding is in the tasting, and we have not tasted pudding yet. But we think we have figured a way to accomplish that, using a technique in which tables of variable names and labels are maintained which are used ONLY during the interactive or editing made. These tables are ignored while executing the program.

Page 1, Column 2

We assume you noticed that what in BASIC would be a keyword, such as ADD, is instead the 'action address' of the routine which performs the ADD function. So we replace the BASIC one byte keyword with a two byte action address. And we maintain tables which are NOT used at run time so that we appear to the user to have an interactive language. This means that our programs will certainly be larger than conventional BASIC programs. However, variable storage space requirements will NOT be changed versus equivalent BASIC programs.

Well, RAM is getting ever bigger and cheaper. That seems to be a good tradeoff to us; a little extra RAM for a lot more efficient run-time package. If you disagree, go get Dr. Dobbs, Vol. 1, and start writing a 68000 Tiny Basic. Maybe you can get the interpreter to fit in 2K, you clever devil. But don't bother telling us about it, we aren't interested in running slowly.

And talking about 'this thing' is awkward. We need a NAME for our proposed high-level language. Now, this is not as simple as one might think. Initials, for instance, can get one in trouble. IBM once announced a New Programming Language as "NPL". They immediately received a communication from Great Britain's National Physics Laboratory, familiarly known is "NPL". They threatened to write a programing language of their own, known as "IBM" or Incomprehensible Botched-up Mess. The elders of Armonk hastily renamed their new creation "PL/1".

We now have PL/65, XPL0 and whole batch of OTHER 'PL' based names. This mine has been exhausted, we think. What we need is a name which clearly indicates that we have here a programming language, and we also need that name to indicate that we have at hand a HIGH PERFORMANCE language. And we need to avoid provincialism and select a name with built-in world-wide recognition. Lets see, ALGOL is well known world-wide as a computing language. And Hal, the computer in the movie 2001, is well known worldwide as a high performance computer.


OK, we've got a recognizable name. Where is the language specification document? THAT, chum, is what we have to work out. Let us for the time being set aside 'specification' and instead consider 'attribute'. We have already decided that the language will include the desirable attributes of exceptionally low run-time overhead and that we will achieve that using threaded code. We will retain the benefits of an interactive environment, and pay the extra memory overhead for that benefit. It will be an extraordinarily simple task to 'compile' the programs written in HALGOL since all we need to do is discard the variable name tables, the label (GOTO, GOSUB) name tables and the edit and list modules of the run-time package. If this latter 'compilation' process requires more than one second, your faithful newsletter editor will personally eat the HALGOL source code without seasoning!

Page 2, Column 1

We need to decide upon 1) how to store the program and data in a memory space which is normally greater than 64K and 2) decide how to implement the interactive aspects of the programming environment. It might appear to the casual reader that decisions relating to the commands functions and syntax of the language are most important. Not so. This language will have user-extensible (and also user-deletable) commands and functions. You will be able to strip the stuff you will never need and add the stuff you do need. 'Shuffle a deck of 52 cards' becomes a single command, 'SHUFFLE'. This DOES assume that you are an assembly language programmer, but 68000 assembly language programming is a whole bunch easier than the 6502 or Z80 (or 8088) equivalent.

All right, the problem has been defined: let us attack the first part of the problem, how to store the program and the data. This has constraints of time and space (and what, we ask, does not?). By space, we mean that if we assign three bytes to every address, we effectively assign 4 bytes since the 68000 likes even byte boundaries. However, if the address of some items can be usefully defined by a two byte address (and hence limited to 64K) then we not only save two bytes of program storage but we also reduce the interpretive overhead. You will recall that the 68000 is data bus bandwidth limited; it takes longer to fetch four bytes than two.

When the 68020 arrives we will have 256K dynamic RAMs and 64K static RAMs as common, garden variety, inexpensively available devices. At that time, using a four byte address descriptor will become common and ordinary.

Right now, we are all close enough to the BAD OLD 64K era that we are uncomfortable with the idea of 'wasting' those two extra bytes. We propose a compromise:

A) All of the entrance points to the HALGOL commands and functions will reside in the 64K zero page. The two byte action address will therefore ALWAYS point at executable 68000 code.

B) Since some extensions will eventually require more than 64K RAM, the executable code in zero page (for these extensions only) will be limited to a JMP (long address) to the retaining executable code which can be anywhere in the 68000 address space. Each command or function will therefore require a minimum of 6 bytes of the available zero page. In the limit, we can have more than 10,000 commands or functions without running out of zero page space. This preposterously large number (most BASICS have fewer than 128 commands and functions) proves that we are not limiting ourselves by this two-byte address convention for the execution address of the command or function.

Page 2, Column 2

C) We will begin with the simple numeric variables stored in the zero page directly. At 8 bytes per numeric variable, we could have 2000 possible simple numeric variables assuming the HALGOL interpreter occupied 75% or less of zero page. However, if this becomes a problem in the future, we will go to plan (D) as outlined in the next paragraph:

D) Simple numeric variables can instead be identified with a two byte OFFSET from a BASE ADDRESS. The base address will be a three byte value which will (sensibly, the way the 68000 works) be stored as a four byte or long word value, ONCE, in zero page. The two byte offset therefore can address 64K of simple numeric variables. Now we are 'limited' to 8,192 simple numeric variables!

As a practical matter, we believe that it will be a couple of years before we will need more than 2000 simple numeric variables, and by THAT time memory will be so inexpensive that we will bypass (D) and go directly to four byte address pointers.

E) Simple string variables will be addressed in the same manner as in (D), but with a different base address pointer.

F) It is immediately obvious that arrays, both numeric and string type, will occupy memory space in an amount greater than 64K. We have a choice of simply and directly using a four byte address to point directly to the array or to use the more complex technique of using a two byte pointer to a four byte pointer. The four byte pointer points directly at the array (and the array parameter information). The former method is VERY slightly faster at run-time. The latter method has an advantage in saving program space and seems worthwhile. Each array has its own four byte pointer and each pointer occupies 4 bytes of our 64K zero page. However, it is the rare program which contains more than 100 arrays, so the zero page usage is negligible. We will adopt this latter method.

G) Like arrays, we need to plan immediately for programs which will occupy more than 64K bytes. This means the address pointer following 'GOSUB' or 'GOTO' will be a four byte parameter. Since these are statistically infrequent, this will not have such impact on program size.

As the language HALGOL becomes 'fleshed out' it is possible that some of those memory usage techniques will be modified. We consider ourselves pragmatic rather than dogmatic (as several readers have cleverly noted, we are even planning to manufacture some 68XXX boards on which Dtack will NOT be grounded!). Later in this issue we will illustrate the very real run-time advantages of HALGOL.

Page 3, Column 1


"The biggest problem with readability of Forth programs, in my opinion, is the resistance to using variables. Heavy use of the stack results in anonymous values, referenced to an ever-changing top of stack, and is very hard to follow... In any case, my point is that any language which uses a stack heavily will have the same characteristics." B.W.W., San Pedro CA.

Bruce, HALGOL will NOT use a stack heavily.

"Oregon Software is working on a (Pascal-2) package for the 68000. Do read their advertisement in a recent copy of Byte and send for their literature. Perhaps your Dtack board could fly with Pascal-80." Dr JSK, Lewiston ID.

John, we called Oregon Software. They have a successful package which they sell for $3,500 per CPU on PDP11/70s and VAXs. They understandably have no interest in selling this package at a price appropriate to the Apple market. And frankly, neither are any of the OTHER vendors of 68000 software packages. You see, the word is out that the 68000 is ONLY usable in minicomputers, so everyone writing 68000 software is pricing it at minicomputer levels.

A LETTER DATED THE SAME DAY that we mailed the last issue asserts that MICRO magazine is indeed very seriously searching for articles on the 68000 and suggests that Dtack board owners might be natural sources of such articles. You can call MICRO at (617) 256-5515 and ask for a free copy of their writer's guide.

"...if those 4 engineers and 4 software guys don't get busy, my warrantee will expire and I will blame them... Who is able to use Smalltalk on an Apple? ...you have obviously perceived by now that I am highly qualified to be the newsletter editor advertised for in issue #10." R.D., Minneapolis MN.

Ron, you said FOUR high level languages, TWO months. We expect results, not excuses (putting the blame is NOT an Olympic event, by the way). We know absolutely nothing about running Smalltalk on an Apple. We have not written anything about running Smalltalk on in Apple in this issue. THAT IS OFFICIAL. YOU WILL BELIEVE IT!

We do not think that you meet the high standards required of a newsletter editor for this publication. Nearly all of your words are spelled correctly. As Mark Twain observed, "That man has a poor imagination who can think of only one way to spell a word." Judging by the sample you sent us your son Reid DOES qualify for the job. Unfortunately the state of California has these pesky child labor laws...

Page 3, Column 2

Mark Twain is, of course, the pseudonym of Samuel Longhorne Clemens. In "Life on the Mississippi" Sam wrote, "War talk by men who have been in a war is always interesting; whereas moon talk by a poet who has not been in (sic) the moon is likely to be dull." Sam, we don't know which watering hole you favor these days, but we have interesting poets who talk of the moon now.

And in case any of our readers wonder why we explained who Mark Twain is, we have readers in Yugoslavia, Germany, England, Venezuela, Japan, Norway and Texas.

"...the Aristocard people. There would appear to be something very odd about the operation as the people at the other end of the telephone quoted (in the Apple Orchard product announcement) denied all knowledge of Simon or his works. Similarly, the zip code is an impossible one." J.A., Reading, England.

"...I think in newsletter #9 you wrote something about a British company offering 68000 boards for Apple. The company is Simon Computer, the board is called "Aristocard", it costs about $900 (= 475 pounds) and they don't answer any letters... P.S.: My girlfriend who loves your letters would be glad if you sent her a foto of yourself..." O.B., Hamburg, W. Germany.

Gentlemen, we remember writing something about the Aristocard but we are doggoned if we can find the reference IN OUR OWN NEWSLETTER! Oliver, your girlfriend is to be congratulated on her good taste. We have our secretary out looking for a Robert Redford photograph, which we will autograph and forward.

"For seven years, I worked for a manufacturer of some of the world's largest number crunchers. The systems were fantastic at crunching numbers. But, they were lousy at everything else... Control Data's NOS (Network Operating System) has a response time that is pitiful compared to a 68000 running UNIX. And there's a factor of between 500 and 1000 difference in the price.

"A certain company who shall be nameless, advertises a system called the (name deleted) which (they claim) can support 32 users. Nowhere in any of this advertising is there a definition of what 'support' really means... Look: if you have a one MIP machine, and you divide it between 32 people, you have about 30,000 instructions per user per second... The well established performance models tell you that you'd better utilize only about 50%, so now you're only giving the user 15,000 instructions per second... On UNIX, it probably takes that such time to process an interrupt from a terminal." H.M., Mt. View, CA.

Henry, are you trying to tell us that loading up one CPU with 32 users isn't a super neat idea? After all we have asserted in these pages supporting such sharing?

Page 4, Column 1

"...I hear that Mickey Mouse wears an Apple watch." (name deleted), England.

(Name deleted), since Apple does not seem to be spending much time selling product lately, they may have more time to file lawsuits. A word to the wise...

"We received your journal via the copying machines. Thank you, nevertheless... we should tell you that certain machines of the mentioned kind (Japanese brands) don't mind the red color at all." Dr. E.B., Wuppertal, W. Germany.

Ernestus, only a cad would photocopy the sacred red pages! As to the use of Japanese copiers, surely you remember that we fought a war against them 40 years ago?


We recently heard a VERY interesting rumor. It seems that this well known company has been working an a 68000 based computer for a long time now. As the rumor has it, they had invested over 100 man-years of programming effort in the project. Well, none of that software ever worked satisfactorily so they junked it and went hat in hand to Microsoft. "Would you folks write us some software so that we can run (code name of computer)? Please?", they were rumored to have asked.

As the rumor goes, Microsoft delivered a software package to this well known company in June and (code name of computer) now runs. Unfortunately (the rumor continues), the big brass at the well known company are displeased because (code name of computer) runs very slowly. Now, this rumor is not specific as to the REASON (code name of computer) runs slowly.

Unfortunately, this rumor will be of less interest to you since we have completely forgotten which well known company is involved and we have also forgotten the code name of the computer.


Counting our Dtack board, there are now no less than three 'attached processors' available for the Apple II. One of the others uses a Z80B and the other uses an 8088. It seems some other people have figured out that being forced into lockstep with that slow Apple memory bus seriously degrades performance. What follows is an open message to these other vendors:

Fellows, congratulations on a good piece of engineering. True, we have been pointing out the advantages of an attached processor in this newsletter for a year now, but you obviously arrived at your decision independently or you would be using the 68000, not the Z80B and 8088. Now for the bad news: there are a great many Apple owners who know more about hardware design and performance than YOU do. And these many owners are, judging by our experience, going to give you a great deal of flak over not using the 'obviously superior' DMA approach to exchanging data with the Apple.

Page 4, Column 2


Way back before there was an Apple or Pet and when Noah was still laying his keel there was this outfit called the Southern California Computer Society. It met once a month at TRW near Los Angeles International Airport. You would see 700 to 1000 people show up to hear 14 year olds lecture poorly about BASIC.

We attended two or three of those meetings before some members' money started disappearing and the mood of the club soured. However, the club held on for a year or two and in fact founded the magazine S.C.C.S. Interface which later became Interface Age. We want to tell you about a particular meeting when a MITS representative showed up with the 6800 (NOT 68000) version of the Altair. The 6800 version was a lot smaller (and cheaper), being a one board system. Without, we add, a whole lot of memory on board.

The MITS representative incautiously took the cover off this computer in the lobby while the 14 year old lectured in the main meeting hall. The MITS rep set the unit on the floor so that the twelve or so persons gathered around could all see and ask questions. Your faithful newsletter editor was one of the twelve.

When one of the onlookers asked about the limited memory, the MITS rep stated that his company was about to come out with a memory expansion board. Oh? Just where would this expansion memory plug in? we asked. "The expansion board goes here." explained the rep, swirling his hand in the space above the single board. But there is no CONNECTOR on the main board for the expansion memory to plug INTO! we exclaimed. This embarrassed the rep, since most of the other onlookers caught on to the problem. After a short exchange whose detail we have forgotten, the rep stated cuttingly, "You'll never buy a computer anyway!" Then he put the cover on his computer and left. We remember the conversation well because we were one of the few people at that S.C.C.S. meeting who DID have a computer at home!

And now our reason for dredging up that old story: We have just received from a correspondent in England a nicely done six page brochure printed by Simon Computer. About four of those pages feature the Aristocard, a 68000 card which plugs into the Apple bus and uses Apple memory to run. This means that each 16 bit fetch or store is done as two consecutive 8 bit memory cycles. Since the 68000 is almost totally bus bandwidth limited (more on this subject elsewhere in this issue) that means the effective speed of the card is about equal to a 2.4MHz 68000. The official clock rate is 4MHz whenever the bus is not being utilized.

Page 5, Column 1

Now, so far this card is configured almost exactly the way OUR 68008 card will be toward the end of the year (or whenever the 68008 becomes real). And the performance is just about exactly what we anticipate for our card. But since they have to add some logic to fool the 68000 into doing two memory cycles on the Apple for one on the 68000, the card is a tad expensive at 475 pounds. That's over $800 U.S.

But the kicker is that there will shortly be a 128K expansion board for the Aristocard which will permit the clock rate to go to 8MHz just like the basic speed of OUR 8MHz board (that's what the brochure clearly states!). This means that someplace an that card there must be a connector carrying, as a minimum, 16 data lines, A16 thru A1 (16 more lines) plus AS, LDS, UDS and R/W. That is 36 signal lines minimum not including +5 or ground. And at 8MHz you usually need lots of ground lines. And you usually need a bunch of buffers for all those lines.

If you will take out our newsletter #3, you will see on the far right side of the board two 50-pin connectors and five 20-pin LSTTL signal buffers for OUR expansion board. Actually, we use half of the 20 pin chip just above the 68000 as a buffer as well, but we bring out ALL the address lines. Since there is a very large and very clear photograph of the Aristocard on the brochure, we looked for the corresponding connectors) and buffers (the board is small; there isn't such room to hide).

There ain't none.

Which means you will be able to expand the Aristocard by 128K and switch to an 8MHz clock shortly AFTER you plug the memory expansion board into your 6800 Altair.

The person who mostly doesn't write the FWAUG newsletter visited us in person recently and became the FIRST (but not last) person to suggest that we put a memory expansion connector on our yet undesigned 68008 Apple compatible board. He pointed out that it would require only a few traces on the P.C. board and should not increase the cost at all! He apparently had not counted the required signal lines and apparently was thinking of operating without buffers. There is an ABSOLUTE MINIMUM of 36 signal lines, not including ground lines. And we think we would need buffers!

(According to MICRO, the FWAUG newsletter is published 9 times a year. Seven of those issues must be printed using invisible ink!)

Page 5, Column 2

IT IS A CURIOUS FACT that although we frequently receive suggestions that we add hardware features (such as the ever-popular 300 baud RS232 port) to our 68000 boards, most of the suggestions either ignore the associated costs or else specifically assert that the hardware can be added with no increase in price. We have been in the electronics hardware manufacturing business for 20 years now and we have NEVER been able to add hardware features without an associated increase in cost. A company which increases its costs without a corresponding increase in price is not long for this world, guys.

Our planned 68008 board is intended to have the lowest possible price. We said $200 to $250 and we mean it. While we cannot absolutely promise to pull that off, we DO absolutely promise to TRY. The way to achieve the lowest possible price is to eliminate any unnecessary cost. So, dear reader, we ask you to please refrain from writing or calling with suggestions of features which can be added to our proposed 60008 board, features which naturally will not require a price increase!

(One thing which might affect the price is the question of whether to put on-board memory for the 68008 separate from the Apple memory space. Using an 8MHz 68008, that would double the effective "bus bandwidth", permitting TWO bytes to be fetched each microsecond instead of just one using the Apple memory. But the extra memory increases the price. Maybe we need a choice of both kinds of boards?)

POSTSCRIPT: Since the above was written we have received TWO suggestions that we add 64K RAM to our proposed 68008 board. Neither suggestion was accompanied by a proposed compensatory price increase. Sigh.

HOT 68008 FLASH!

To Motorola's enormous surprise, the very first 68008 mask set worked, with no known bugs. Maybe we will have a sample by the time we mail this newsletter?

We will not see whether this is as important to the 68000 user community as we think, because WE are going to be the first to ship real 68008 boards that fit completely inside the Apple II, just like all those OTHER alternate CPU boards. Which means the dynamic RAM board is going to be set aside temporarily, and the 68008 project given top priority.

One of the nice things about a low-priced board fitting entirely within the Apple II case is that less software is needed to justify a less costly purchase. And since we now have a young programmer working for us doing nothing but generating software which we will give away, we may sell a board or two or three.

Page 6, Column 1


At the very last minute before taking the last issue to the printer, we received in the mail a copy of the article briefly mentioned an page 12 (of issue 11). We only had time to present a VERY brief summary of that article. There is MUCH MORE in that article that will be of interest to most of our readers.

First, the article was written by a group of graduate students of the Computer Science Division of the University of CA, Berkeley. The abstract reads: "We describe an experiment to test the 432 as a high-level language uniprocessor by comparing it with the 8086, 68000, and VAX-11/780 for four integer and character programs written in Ada, C, and Pascal."

Our own interest in the 432 is now zilch. However, we can toss out the 432 and we still have a nice comparison of the 8086, 68000 and VAX 11/780.

Finding unbiased comparisons is not difficult if you know how, by the way. Here is our method: Articles and ads are constantly published using bar graphs to compare various processors. MANY such comparisons have been published by the various manufacturers. It should not be surprising that each ad proves conclusively the superiority of the advertiser's product, no?

The thoughtful reader say wonder about the collective factual content of those articles and ads. Here is how we winnow the wheat from the chaff: when Zilog compares its product against the 8086 and 68000 we simply throw out the Zilog data and assume that we have a relatively unbiased comparison of the 8086 and 68000. When T.I. publishes a bar graph comparing the 99000 to the 8086, Z8000 and 68000 we throw out the 99000 data.

If we do this enough times and take a weighted average we will have a pretty good idea of the performance of the various contenders. One additional precaution is necessary: we have to be careful to note what clock speeds are cited in the comparisons. It will be necessary to factor the advertised clock speeds versus those generally available (for ALL of the contenders) to arrive at a final realistic comparison.

An example: Suppose National were to advertise that the 16032 is faster than the 68000. Since their promotional literature asserts that the 16032 is a 10MHz device, they would doubtless compare that 10MHz part (?) to an 8MHz 68000. They would naturally select those things which the 16032 does particularly well, which is business as usual in this game. For instance, the 16032 apparently does outperform the 68000 at 32 bit multiplication. But ALL of the speed comparisons, including the multiply, would be seriously biased in Nationals' favor (surely you are not surprised, chum?).

Page 6, Column 2

The bias would involve the comparison of a 10MHz 16032, which does not exist, against a mere 8MHz 68000. The VERY limited number of working 16032 samples available right now run at 6MHz. Even a crummy little outfit like us is shipping commercial 68000 product which runs at 12.5MHz. The ratio by which the National advertisements would overstate the relative performance of their product can be calculated thusly:

RATIO = (10/6) times (12.5/8), or OVER 2.6!

If National were to assert that it actually had a few working 8MHz parts, we would reply, So what? Motorola has had a few working 16MHz 68000s for many months now (the article was dated May 17 '82. The tests using the 16MHz 68000 were surely performed MUCH earlier).

National intends to have 10MHz parts someday? Wonderful! Our money says that a shrunk mask version of the 68000 runs at 20MHz before they reach 10MHz. Any takers?

So, we have an unbiased comparison of the 8086, 68000 and VAX 11/780. EVEN BETTER, we have performance data on a 60000 with NO wait states (Dtack effectively grounded) and another 68000 with FOUR wait states. Where did they find a 68000 with four wait states? Would you believe that $28,900 turkey called the EXORMACS has FOUR wait states on every memory fetch (if this article is correct)?

Please note from the figure on the next page that a 68000 with four wait states runs at about 55% the speed of a zero wait state machine with the same clock speed. Now, these are integer and character benchmarks. With an AVERAGE mix of multiplies and divides, the degradation in throughput will not be quite as bad. We will assign the equivalent throughput for the example given at 60%, and support that conclusion as follows:

The 68008 requires TWO memory cycles to fetch one word of an instruction. Each memory cycle requires four clock cycles, so a 68008 (with no wait states) is equivalent to a 68000 with four wait states. And Motorola spokesman have been quoted as stating that the 68008 will have 60% of the performance of the 68000 given equivalent clock rates. Q.E.D.

DID YOU NOTICE THAT WE HAVE NOT spent a lot of time pointing out how the 68000 ran away from the VAX? Not even how our own 12.5 MHz boards compare? As a PRACTICAL matter we really do not think anyone is going to study that chart, puzzling over whether to buy a VAX or a Dtack board! OTHER considerations, such as software support on the one hand and a FAR lower price on the other will force that decision!

Page 7

              432          8086          68000        VAX-11/780

      |                                           **
      |                                           **
 1.5 -+-                                          **
      |                                           **-12.5MHz
      |                                           **     ##
      |                                           **     ##
      |                                           **     ##
 1.0 -+-                                          **     **
      |                                     ##    **     **
      |                                     ##    **     **
      |                                     ##    **     **
      |                         ##          ##    **     **
 0.5 -+-                        ##     **   ##    **     **
      |                    **   ##     **   ##    **     **
      |              ##    **   ##     **   ##    **     **
      |              ##    **   ##     **   ##    **     **
 0.1 -+-             ##    **   ##     **   ##    **     **
      |   **   **    ##    **   ##     **   ##    **     **

         4MHz 4MHz 10MHz  5MHz 8MHz   8MHz 8MHz 16MHz
          R2   R2*   R3   0WS  0WS    4WS  0WS   0WS
         12WS 12WS  4WS

                    ************     #############
         Figure 2:  * measured * and # predicted # performance
                    ************     #############

The figure above is taken from the article " A Performance Evaluation of the Intel iAPX 432" which appeared in Computer Architecture News Volume 10, No. 4, June 1982 on page 26. We have added to the figure the performance level of a 12.5 MHz 68000 with no wait states. Note that this performance far exceeds the existing VAX 11/780 and is approximately equal to hypothetical improved VAX systems which may be developed in the future.

Page 8, Column 1


For nine years now, Digital Acoustics has made its living making environmental noise monitors. In July '81, we decided to make high performance attached processors as a 'fun' hobby. Well, as of July '82 we are a company which makes high performance attached processors for a living and also makes environmental noise monitors as a profitable annoyance. The growth in Dtack sales in the past four months has been phenomenal.

Our sales policy, 10% down and COD or full payment in advance, will become a necessity instead of an arbitrary decision very soon if our sales continue to grow. Dtack is an obvious economic success. It is also a 'quality control' success since no failures have yet been reported (all Dtack boards are still in warranty). And when we read the accounting report we get this nice warm feeling deep down inside.

However, we have NOT achieved our original objective. Which was to bring an extraordinarily high performance processor to the individual dedicated personal computer hacker. The cash register jingles merrily but we have bad art. Since a major objective of our Dtack endeavor was to have fun, we worry over this lack of artistic success. Digital Acoustics is NOT run by an accountant!

WHERE THE SALES HAVE GONE: Most of our recent board sales have been either fully loaded 92K varieties, frequently with a 128K expansion board. The 12.5MHz option is becoming increasingly popular (yes, the expansion board runs nicely at 12.5MHz). But we are selling these boards to businesses, not hackers. And we DO mean boards, plural because many of these businesses are buying more than one board. On several occasions the initial TRIAL (!) purchase has been two boards, and on one occasion THREE!

Why are these people buying our boards? Usually it is for a single, highly specific purpose. They have such-and-such a job to do, they (usually) already own Apple computers, sometimes lots of them. So they buy our board to solve this single specific problem. Do you realize what we are describing? The Dtack boards are being purchased as MINICOMPUTERS!

Look, a minicomputer is a device which is invariably purchased as the solution to a particular problem. Absent the problem, no sale. Yes, we know, we said this before. But we are becoming financially successful selling a product which we did not intend to manufacture! The fact is, we simply have not been thinking of our product in terms of its application as a minicomputer.

Obviously, others have.

Page 8, Column 2

YOUR TYPICAL MINICOMPUTER MANUFACTURER has these characteristics: 1) Pricing is unrelated to manufacturing costs. 2) EVERYTHING is a secret! 3) The company is run by the accountants, who have no heart and no art. If it is necessary to step on a few people to achieve a good 'bottom line', so what? 4) There is this thing called a list price...

Its like this, guys: A LIST PRICE is published. If you knock three times, ask for Harry and promise to buy a few dozen minicomputers as soon as your prototype system is debugged, you magically become an OEM. Like generals, there are various grade OEMS. One grade only gets a 20% discount (didn't knock hard enough). The next grade gets a 30% discount (should have asked for Don). But the very highest grade OEMs get a 40% discount off that list price. But YOU are not an OEM, so YOU have to pay FULL LIST'

AS YOU CAN SEE, we do not hold your typical minicomputer manufacturer in high regard. And we are now, de facto, a minicomputer manufacturer. The bottom line states that we are a SUCCESSFUL minicomputer manufacturer. So we will now change our style, right? First off, we have to have a little secrecy around here! Which means that we either stop publishing this newsletter or we turn it into a conveyor of promotional puffery, devoid of truth (small t variety) or useful information. BULLSHIT!

(In the past we have used the phrase 'not in accordance with the facts' as a substitute for that last word. The substitute seems inappropriate here.)

We LIKE our present policies. We are comfortable with them. We like to be able to truthfully state what our future plans are in this publication. And, when an event such as the earlier-than-expected arrival of the 68008 comes along, we modify our plans accordingly and report that fact here. We like to be able to publish source code in REDLANDS (where nobody can copy it). We get no ulcers worrying about security leaks. And best of all, we are making a nice profit so that we can not only continue these policies but also justify them to our stockholders (Digital Acoustics is a corporation).

What we do NOT like is the fact that we have not been able to sell very many Dtack boards to individual hackers. We honestly believe that our boards are one heck of a good deal for anyone who can write assembly language. There are also significant advantages for persons who write programs in BASIC, significant meaning a five time (and up) increase in speed when used with a compiler. According to the report by Alan Wood published in our last newsletter, there are even some advantages for PASCAL programmers. Why have we been mostly unsuccessful in this area?

Page 9, Column 1


As we all know, the personal computer industry was founded by Jack Tramiel, who was tired of repairing typewriters; Jobs and Wozniak, who were tired of being ciphers in huge organizations; and Tandy, which was tired of selling doorbells which played "The Yellow Rose of Texas."

Severally and separately there grew three companies which manufactured small computers at a price low enough to be personally affordable. However, each of these companies made the same terrible mistake. In their innocence, they did not realize the importance of security.

There they went, openly telling everyone exactly what they were doing, publishing software which rightfully should be sold. The mistaken antics of these new companies (OK, new division in Tandy's case) caused snickers at DEC and guffaws at Data General. It was obvious to those professionals that the upstarts were destined to fail.

Knowledgeable observers mark the publication of "Sweet Sixteen" in Nov '77 BYTE magazine as the start of the inexorable decline of these new companies, particularly that of the Apple Computer Co. You see, Wozniak actually PUBLISHED the (super-secret) heart of the Apple INTEGER BASIC interpreter!

Since there were no suitable (read $25 or less) 16 bit microprocessors available, Wozniak had simply written a SOFTWARE EMULATION (called "Sweet Sixteen") of a 16 bit processor, and proceeded to write his system software using that emulation! Any rational person could see that such important software tools must be kept secret lest they aid and comfort the competition!

As a result of this ludicrously inadequate security, Jack Trameil is back repairing typewriters, Jobs and Wozniak are ciphers again and Tandy sure hopes you are in the market for a doorbell which plays "The Yellow Rose of Texas."

The personal computer market is of course now dominated by Data General, followed closely by DEC, General Automation and other long-time small computer manufacturers. Unconfirmed rumors report that Data Generals' personal computer shipments have now reached the unheard-of level of 700 units per month!

If one were to judge by the actions of many companies NOW making personal computers, one would be led to believe that the short history outlined above is REAL.

Page 9, Column 2

While those 100 companies which have announced 68000 based minicomputers are focussing on preventing each other from knowing what is going on, they have failed to perceive that they are collectively in competition with the 8088 culture headed by IBM. Surely any company which has the resources to produce a stand-alone 68000 system has more persons knowledgeable about the 68000 than us. If each of those companies would contribute, say, one page of technical information to the general (68000) cause each month we would have in embarrassment of data. An embarrassment means, of course, that it would be impossible to read all of it.

Instead, those 100 companies are permitting the general public to retain the idea that the 8088 is a real, honest new generation 16 bit processor, JUST LIKE THE 68000! How do they expect the public to pay premium prices for their minicomputers if they do not explain the premium performance afforded by the 68000? The fact that Micro Magazine is scrambling hard to get articles about the 68000 is proof that the attitude of those 100 companies is deliberate, not accidental. The situation should rightfully be reversed; Micro should be buried in manuscripts submitted by those companies.

Let's toss out the Tandy 16; Tandy operates strictly in a world of its own. We have been waiting for one of the other 99 68000 based computers to become generally available. It is easy to announce a new product, not so easy to place production models on a retailer's shelf. We found it quite interesting to read an advertisement in the sports section of a recent Los Angeles Times. A Computerland advertisement contained a nice picture of a Fortune mini, er, personal computer. There was also a suggestion that the reader might like to drop in and purchase same. This is absolutely the FIRST advertisement by a retailer for a 68000 based product that we have seen.

But where in the personal computer press does one read promotional literature extolling the virtues of the Fortune product? Nowhere!

In newsletter #10, we asked our readers generally for comments on random number generators and received more than a dozen replies before we went to press with issue #11. In issue #11 we asked our readers generally to report publication of information on the 68000 in other periodicals and we have received not one peep. Which means that for a period of over a year, the crummy rag you are now reading has been the ONLY periodical with any information an the 68000. Gentlepersons, that situation is RIDICULOUS.

Your faithful newsletter editor is NOT, by any reasonable standards, an expert on the 68000. We know for a fact that several readers know more about the 68000 than we do. And yet, for most of you, the only information you can get regarding the performance of the 60000 and its relative merit with respect to other processors is what you read here.

Page 10, Column 1

How did we, all of us, get in this mess?

We got in this mess because virtually all of the companies making small computers are dominated at the management (decision making) level by persons with minicomputer backgrounds. And ALL minicomputer types have absolutely nothing but contempt for personal computers. You don't believe it? Call on your local DEC or Data General (or Nixdorf or Facom) sales office. Ask one of those minicomputer types, face to face, his opinion of the Apple or Pet. The chances are he will fall down laughing!

(We specifically except Commodore, Sinclair and Osborne from that charge in the last paragraph. We believe it is no accident that the sales volume of these three companies continues to increase phenomenally. On the other hand, Apple Computer has had sales of 133, 132 and 142 million in its last three quarters. That is hardly a phenomenal increase.)

The fact that Motorola perceived the 68000 as being useful only in incredibly complex, expensive systems also contributed to the mess we are in. To this day Motorola has not one single application note on the 68000 describing a small, simple system.


We see two conflicting events coming up fast. First is the adoption of the 68000 by Micro Magazine, for which we all should think Bob Tripp. This will certainly help the general awareness of the potential of the 68000, especially if Bob can bring himself to permit the publication of the enormous performance differential of the 68000 vs. the 6809.

Running counter to this trend is the rapidly approaching public sale of 68008 boards, mostly for the Apple II. The 68008 is NOT a high-performance part and, when tied to the one-byte-per-microsecond Apple bus, will be even lower in performance. Our promotional material on our 68008 board will candidly admit that the board is NOT a high-performance product. But we are almost certain that other vendors of essentially the same product are going to hype their product as being representative, performance-wise, of the 68000 family (sales are more important than the facts, right?).

If the public is permitted to perceive that the performance of the 68008 when locked to the slow Apple bus is typical 68XXX performance, those 100 companies making 68000 minicomputers are in GREAT BIG TROUBLE. Which they DESERVE for their own lack of promotion!

Page 10, Column 2

On the front page of newsletter #2 we declined to discuss the relative performance of the 68000, concluding "People might think we were prejudiced, or something!" By now, everyone KNOWS we are prejudiced, so here goes:

We will assign an arbitrary performance rating of one to a 1 MHz 6502, since most of our readers are familiar with a computer using such. We are going to compare the 6809, 8086/8 and 68000/8 to that 6502 for GENERAL PURPOSE computing. This is a difficult task at best, and at worst an obvious opportunity for outrageous exaggeration. All we can do is assure the reader that we have spent considerable time (the past several years) arriving at these figures. First the figures:


 6502      1     0     1      1      1.0 (ref)
 6502      3.6   0     1      1      3.6
 6809      1     0     1      1      1.3
 6809      2     0     1      1      2.6
 8086     10     0     4      2     10
 8086      8     0     4      2      8
 8086      5     0     4      2      5
 8088      5     0     4      1      3.5
 60000    12.5   0     4      2     20
 68000     8     0     4      2     13
 68000     8     4     8      2      7.8
 60008     8     0     4      1      7.8
 68008     8     4     8      1      3.9

CLK is the clock speed in MHz. WS is the number of wait states. MEM CY is the number of clock cycles required by a memory read operation. BY/CY is the number of bytes transferred on each (program) read operation. PERF is the performance relative to the 1MHz 6502.

Comparing the performance of different processors is done by the method reported earlier. By "general computations" we mean the particular mix of instructions used when running, for instance, an interpretive BASIC program. If more specialized benchmarks are used, it is easy to "cook" the results. For instance, the 6809 obviously multiplies much more swiftly than the 6502. But branches take one or two clocks longer, zero page references one clock longer. A 32 bit add is done in 34 clocks by the "16 bit" 6809 and in 38 clocks using the 8 bit 6502. Incidentally, the three page article on 32 bit addition in April MICRO magazine was badly botched. The writers were obviously completely unfamiliar with the 6502 and its addressing modes.

Page 11, Column 1

Let us examine the 3.5 rating we gave the 5MHz 8088. The slick ad which has been running in BYTE forever asserts a performance rating of 4, but adds the qualifier "running most applications." We believe that is about equivalent to our unqualified 3.5 rating. However, if one is to judge by the well-known fact that the IBM PC is only a little faster than Applesoft (even with the advantage of a six digit F.P. format), one would assume the 8088 should be rated far lower. We believe the discrepancy is due to the fact that most 8088 (and 8086) systems are actually running translated 8080 programs. Our rating assumes code written specifically for the processor in question.

Motorola has published an article which asserts that the 68000 at 8MHz is five times faster than the 2MHz 6809. We agree. Intel has reported that the 8088 has 70% the throughput of the 8086. We agree. Motorola has been predicting a throughput for the 68008 of 60% that of the 68000 for equivalent clock speeds. The benchmark results published in the C.A.M. article discussed earlier in this issue support that conclusion; a 68000 with 4 wait states is functionally equivalent to a 68008 with no wait states. 60% it is.

The 68008 with 4 wait states is what we are going to see when the 68008 is forced into lockstep with the one-byte-per-microsecond Apple II bus. The predicted performance is only slightly better than that of the 8088 when used in this manner. IF THE PERFORMANCE OF THE 68008 ON THE APPLE BUS IS ACCEPTED BY THE PUBLIC AS TYPICAL OF THE 68XXX FAMILY, US 68000 VENDORS ARE IN GREAT BIG TROUBLE!!

As CPU speeds approach infinity, the performance of a particular processor becomes directly proportional to the bus bandwidth. The 8 bit version of an infinitely fast CPU would have exactly 50% the performance of its 16 bit equivalent. The 68008 with a 60% throughput is therefore closer to this ideal than the 8088 with 70% the throughput of its 16 bit equivalent.

Although the 8MHz 68000 and the 8MHz 8086 have exactly the same bus bandwidth (four megabytes per second) with no wait states, the 68000 is considerably faster because of the greater speed of the CPU and also because of its vastly greater internal resources. Having sixteen each 32 bit registers pays off, as we said on page one of issue #2.

The 6809 was designed as a CHEAP processor which is EASIER TO PROGRAM than earlier 8 bit processors. These two design objectives were met admirably; the designers are to be congratulated. The 6809 was never intended to be a fast part so pipelining (which the 6502, 8088 and 68000 have) was left out and instruction prefetching (which the 8088 and 68008 have) was left out. As a result, the 6809 is not very much faster than the 6502 despite its superior instruction set and greater internal resources.

Page 11, Column 2


"...how come your operational, in hand, working board is only about 20% faster than the ALF 8088 'advertised' Applesoft speedup board? ...We have another 'benchmark' of our own- a problem programmed in Fortran, using integer addition and comparisons and little else. A 4341 MOD II did it in about 6.3 seconds run time while your 12.5MHz programmed in 68000 assembler (no we do not run Fortran on it yet) ran the problem in 4.5 seconds. This benchmark is meaningful to us since the development time was about the same (neglecting the 6502 interface etc.). Why don't you toot about that? (A 4341 II is about 25% faster than a 370/158 although a mite slower than the 3033.) ...Our phone call (ref #10 DG) was not frantic...' B.P., St. Louis, MO.

It sure sounded frantic at this end, Bob. You realize, of course, that absolutely no one is going to believe our 12.5 job blew away one of eye beyem's mainframes, don't you? Or a VAX 11/780? (Incidentally, Bob, the GGF contribution went AWOL somewhere between St. Louis and Santa Ana. And would you please give that typewriter ribbon a decent burial?) Now, about that ALF (or FTL) benchmark:

We direct the interested reader to one of those full page ads by ALF Products, such as the one on page 373 of July '82 BYTE. The 8088 card considerably sped up an Applesoft benchmark. We are reporting their results here along with ours. The times are in seconds.

 Applesoft                51.7
 TASC                     41.5
 Applesoft  w/ALF         23.6
 TASC w/ALF               13.3
 Applesoft w/8MHz DG      20.1
 Applesoft w/12.5 DG      19.7
 TASC w/8MHz DG            9.4
 TASC w/12.5 DG            8.9
 HALGOL w/8MHz DG          1.62
 HALGOL w/12.5 DG          1.04

(HALGOL timings by oscilloscope.) A simple examination of the two Applesoft/DG timings shows the 6502 is taking 19 seconds to soft the Apple while the 8MHz DG board requires 1.1 seconds and the 12.5 job 0.7 seconds to support the 6502. It therefore follows that the ALF board, which hooks into Applesoft the same way ours does, requires 4.6 seconds to get the job done. That's 6 1/2 times slower than our 12.5MHz board.

What is obvious is that nothing is going to get done in a hurry as long as that feeble-minded 6502 is in the way. HALGOL almost completely eliminates the 6502; we DO let it place the ASCII numeric characters on the CRT. (Actually, Applesoft does not use strict ASCII; bit D7 is a one instead of a zero.)

Page 12, Column 1

The alert reader will note that a better than 5 times improvement was achieved using the combination of TASC and our DG board, even though that particular benchmark features very simple math. With heavy duty number crunching the speedup would be 8 to 12 times. But HALGOL gives us a 32 to 50 times improvement! Those readers who have wondered why we have not emphasized the use of our board with a compiler lately please note.

Our board DOES work well with a compiler. But it works one heck of a lot better if we bypass that idiot 6502. Now do you see why your faithful newsletter editor sometimes gets a bit er, ANNOYED when asked why we did not design our system for concurrent operation with the 6502?

REDLANDS WILL FEATURE THIS MONTH the HALGOL listing of the benchmark published by ALF, plus a few of the interpretive routines used by HALGOL. You will not notice that the first page of REDLANDS is printed on white paper.

We are reprinting (with permission) the following information taken from the Aug. '82 issue of MICROCOMPUTER PRINTOUT Magazine, an English publication which once specialized in the Pet but has recently broadened their coverage. This issue has a superb section on CP/M, by the way.

 MAKE           U/W        I.B.    SALES/MONTH

 Commodore     6,700      95,000     2,600,000
 Sinclair     20,000     300,000     1,600,000
 Sirius          500       1,500     1,220,000
 Acorn         3,500      18,000     1,150,000
 Apple         1,100      30,000     1,000,000
 Tandy           950      24,000       760,000
 Osborne         450       1,000       420,000
 Sharp         1,400      13,500       304,000
 Atari           475       5,000       130,000
 T.I.            200       3,000        35,000

Sirius is Chuck Peddle's 8088 machine, marketed in the U.S. under the Victor label (see Aug. '82 BYTE, p.281). Sinclair and Acorn are English makes; Sharp is the only Japanese machine listed. The Japanese are taking over the personal computer market VERY SLOWLY! (We even remember when it was TI that was going to take over.)

U/M is units shipped in England per month, I.B. is the installed base. SALES/MONTH is in pounds. The pound is worth less than two dollars these days; we will not list the exact ratio to avoid upsetting our English friends.

Well, you DID want to know what's happening on the other side of the big creek, didn't you?

Page 12, Column 2


Most of you have heard of CURSOR, which was a cassette magazine for the Pet computer. CURSOR was produced by The Code Works under the leadership of Ron Jeffries. Well, Ron has started a newsletter (The Jeffries Report) about general doings on the personal computer scene. The price is $15 US & Canada, $20 elsewhere for six monthly issues. If you are interested, make your check out to The Code Works, Box 550, Goleta CA 93116. Here is an excerpt from issue #2, quoted with permission:

"I have information from several sources that a group in Orange County, California has copied the Apple-II motherboard and may have copied the DTACK GROUNDED 68000 attached processor board for the Apple. The same group is reported to also distribute stolen software.

"...Those (DTACK's) prices sees fair to me. I don't understand why the Orange County group would want to steal the design.

"The disturbing thing about this specific case is that it may be an indicator of a much deeper problem. I haven't heard of similar hardware design thefts, but it seems like a large fraction of personal computer users either steal software or look the other way when stolen software is distributed.

"The most important point is not how many dollars VisiCorp, Microsoft, or Micropro have lost because of software theft. What worries me is that theft is being condoned on such a grand scale. Our social fabric depends on trust and integrity, and anything that erodes those values is dangerous. I welcome your comments on this topic."

Ron, you are clearly not attuned to our wonderful modern American society. It just happens that in the past two months we have had occasion to report two instances of what seemed to be theft. In each case we were asked, "Why are you sticking your nose into this matter? It is no skin off YOUR nose; you are not the one being ripped off. Why not leave it alone?"

We believe that our society is (or should be) one large community. When the resident of a proper community sees his neighbor's house being burglarized he calls the police THEN rather than waiting for his or her OWN house to be hit. If we do not help others, who will help us? As Ron has by bringing this matter to our attention.

We ask those readers who share our attitude to keep a sharp lookout for counterfeit DTACK boards, especially in the Orange County area.

Well, we SAID this was a competition report, didn't we?

Page 13, Column 1

THIS YOU WILL NOT BELIEVE: We recently received an 11 page handwritten letter inviting us to help save the world from tyranny and for democracy. After two readings, we think the writer was (is) serious. For one thing, an 11 page handwritten letter is too much work for a gag. However, we must respectfully decline.

It happens that WE are opposed to tyranny and friendly inclined toward democracy ourselves. But there is just so such one person can do! OUR little crusade is a full time job and then some. Besides, we do not think the technical objective proposed by the writer is within the current state of the art. We do wish him well.

EDITOR'S REPORT II: These past six issues have been, more or less, our SECOND attempt at publishing a newsletter. After all, we had reserved the option of 'turning it off' after the first six issues. Well, we have decided to continue for yet ANOTHER six issues. We have a couple of optimists among our readers who are paid up through issue #24. If we decide to discontinue this newsletter after #18, they will be reimbursed in cash.

The next six issues will hopefully include contributed material since we are beginning to develop a respectable customer base. Also, we need to avoid duplicating the sort of material that is going to be published in Micro. We have no desire to compete with regular magazines. We will continue to report on developments of high-performance products usable in personal computers. And we will continue to report on the development of HALGOL, which some of you may have noticed has some resemblance to a compiled BASIC.

It now requires forty hours of personal effort to produce one issue of this newsletter. Since we are also beginning to write copy for full page ads, it seems likely that we will publish less frequently. Say, six weeks per issue.

The reader say be interested to know that each page of this newsletter occupies 30 to 32 sectors on disk. For an issue such as #10, which had no REDLANDS, that is 480 sectors!

FIRST MISTAKE DEPT: Becoming a newsletter editor.

SECOND MISTAKE DEPT: The article "Rethinking the 256-kb RAM" referenced on page 10 of our last newsletter appeared in the IEEE Spectrum (not Computer) magazine.

THIRD MISTAKE DEPT: Our statement that the 16MHz 68000 could be purchased is apparently incorrect. We have tried to buy one, with no success. Although the device does exist, its status is 'limited sampling'. Meaning Control Data can get one and General Dynamics can get one but Dtack Grounded can't.

Page 13, Column 2

FOURTH MISTAKE DEPT: REDLANDS is supposed to be printed on red paper except for issue #4 which was supposed to be printed on yellow paper. We DID use yellow for the first printing. But the second printing accidentally was done on white paper. The third printing, recently done, came out on red paper. Now, one of these days we are going to get it right again!

68000 vs. VAX: The reader is reminded that the benchmarks cited earlier are not general purpose benchmarks; they are tests of the ability of the computers to handle characters (text) and to execute procedure calls. No claim is made that the 68000 can bang floating point numbers at VAX rates. In fact, those readers with long memories will recall that we flatly stated in newsletter #2 that the 68000 really needs a companion math processor to offload (double precision) floating point computations to make the most effective use of its considerable capabilities.

SIDEBAR: An Apple User Group newsletter, which shall go unnamed, recently published a rationale for a company charging more for a product than the basic parts cost. It seems that the writer would permit the company to add the cost of labor and rent plus a percentage to be set aside for expansion of the (manufacturing) plant. There was no mention of any profit to reward the investors who put up their money to start the manufacturing operation.

Has our society departed so far from the precepts of free enterprise that 'profit' has become a dirty word, not to be used in polite company?

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; singular, II, III and soft: Apple Computer Co. Pet and CBM: Commodore Business Machines. VAX: Digital Equipment Co. TASC: Microsoft. DTACK GROUNDED and HALGOL: Digital Acoustics, Inc.

SUBSCRIPTIONS: You can subscribe by sending $15/6 issues U.S. and CANADA or $25/6 issues elsewhere. Tell us which issue number to begin with. Make the check out to DTACK GROUNDED. The address is:

1415 E. McFadden, Ste. F

FAREWELL, MAYBE, AGAIN: For most of you, this is the last issue of your current subscription. You may regard this notice as a very broad hint that you should consider sending us another check.

IN THIS MONTH'S (uncopyable) REDLANDS we have the complete listing of the FTL benchmark as written in HALGOL. Included is assembly language listings of some of the HALGOL functions.

Code Listing 1

                          1          OPT     P=68000,BRS,FRS
0022D0                    2          ORG     $0022D0
                          4 * THIS IS THE START OF THE THREADED CODE
0022D0  226E              6 START    DC.W    INIT           CLEAR 1K
0022D2  22C2              7          DC.W    TIMING         START TIMING
0022D4  203C              9          DC.W    MOVE           MOVE #5 TO B
0022D6  2338             10          DC.W    FIVE
0022D8  2344             11          DC.W    B
0022DA  203C             13 LOOP1    DC.W    MOVE           MOVE #3 TO C
0022DC  2332             14          DC.W    THREE
0022DE  234A             15          DC.W    C
0022E0  200C             16          DC.W    LOAD           CALC SQR (B)
0022E2  2344             17          DC.W    B
0022E4  2376             18          DC.W    SQR
0022E6  201C             19          DC.W    STORE          STORE FOR LATER
0022E8  2350             20          DC.W    SQRB
0022EA  200C             22 LOOP2    DC.W    LOAD           CALC B/C
0022EC  234A             23          DC.W    C
0022EE  20A0             24          DC.W    DIV
0022F0  2344             25          DC.W    B
0022F2  2380             26          DC.W    FRAC
0022F4  20FA             27          DC.W    JIFZER         BRANCH IF ZERO
0022F6  2314             28          DC.W    NXB
0022F8  200C             30          DC.W    LOAD           CALC=C+2
0022FA  234A             31          DC.W    C
0022FC  2088             32          DC.W    ADD
0022FE  232C             33          DC.W    TWO
002300  201C             34          DC.W    STORE
002302  234A             35          DC.W    C
002304  2090             36          DC.W    SUB            CALC SQR(B)-C
002306  2350             37          DC.W    SQRB
002308  20DE             38          DC.W    JIFPOS         BRANCH IF >= 0
00230A  22EA             39          DC.W    LOOP2
                         41 * INTEGER PRINT B
00230C  200C             43          DC.W    LOAD           FETCH B
00230E  2344             44          DC.W    B
002310  2356             45          DC.W    INT            TAKE INTEGER
002312  21FE             46          DC.W    IPRINT         PRINT IT
002314  200C             48 NXB      DC.W    LOAD           CALC B=B+2
002316  2344             49          DC.W    B
002318  2088             50          DC.W    ADD
00231A  232C             51          DC.W    TWO
00231C  201C             52          DC.W    STORE
00231E  2344             53          DC.W    B
002320  2090             54          DC.W    SUB            CALC 1000-B
002322  233E             55          DC.W    THOU
002324  20DE             56          DC.W    JIFPOS         BRANCH IF >= 0
002326  22DA             57          DC.W    LOOP1
002328  22C2             59          DC.W    TIMING         END TIMING SIGNAL
00232A  2236             60          DC.W    END
   # 0000200C            63 LOAD     EQU     $00200C
   # 0000201C            64 STORE    EQU     $00201C
   # 0000203C            65 MOVE     EQU     $00203C
   # 00002088            66 ADD      EQU     $002088
   # 00002090            67 SUB      EQU     $002090
   # 000020A0            68 DIV      EQU     $0020A0
   # 000020DE            69 JIFPOS   EQU     $0020DE
   # 000020FA            70 JIFZER   EQU     $0020FA
   # 000021FE            71 IPRINT   EQU     $0021FE
   # 00002236            72 END      EQU     $002236
   # 0000226E            73 INIT     EQU     $00226E
   # 000022C2            74 TIMING   EQU     $0022C2
   # 0000232C            75 TWO      EQU     $00232C
   # 00002332            76 THREE    EQU     $002332
   # 00002338            77 FIVE     EQU     $002338
   # 0000233E            78 THOU     EQU     $00233E
   # 00002344            79 B        EQU     $002344
   # 0000234A            80 C        EQU     $00234A
   # 00002350            81 SQRB     EQU     $002350
   # 00002356            82 INT      EQU     $002356
   # 00002376            83 SQR      EQU     $002376
   # 00002380            84 FRAC     EQU     $002380

Code Listing 2

                          1          OPT     P=68000,BRS,FRS
                          3 * COPYRIGHT 1982 DIGITAL ACOUSTICS, INC.
002000                    5          ORG     $002000
                          9 * PACKAGE FOR THIS VERSION IS THE NINE DECIMAL
                         10 * DIGIT APPLESOFT COMPATIBLE PACKAGE.
                         12 * HERE IS THE ADDRESS REGISTER USAGE:
                         14 * A7 IS THE MACHINE STACK POINTER
                         15 * A6 IS THE PROGRAM POINTER
                         16 * A5 IS A SCRATCH REGISTER
                         17 * A4 IS DEDICATED TO POINT TO F__TH
                         18 * A3 IS THE PROGRAM SUBROUTINE STACK POINTER
                         19 * A2 IS THE DATA STACK POINTER
                         20 * A1 IS UNDEFINED AS YET
                         21 * A0 IS A SCRATCH REGISTER PRIMARILY USED
                         22 *    TO POINT AT FLOATING POINT VARIABLES.
002000  3C7C 22D0        26 BEGIN    MOVE.W  #START,A6      START ADDR
002004  387C 2008        27          MOVE.W  #HALGOL,A4
002008  3A5E             29 HALGOL   MOVE.W  (A6)+,A5       FETCH ACTION ADDR
00200A  4ED5             30          JMP     (A5)           JUMP TO ACTION ADR
00200C  3A5E             32 LOAD     MOVE.W  (A6)+,A5
00200E  31DD 1902        33          MOVE.W  (A5)+,S1
002012  21D5 1904        34          MOVE.L  (A5),M1
002016  4278 1908        35          CLR.W   G1             CLEAR GUARD BYTE
00201A  4ED4             36          JMP     (A4)           RETURN TO HALGOL
00201C  3A5E             38 STORE    MOVE.W  (A6)+,A5       ADDR TO PTR A5
00201E  4EB8 1536        39          JSR     ROUND          ROUND GUARD
002022  3AC0             40          MOVE.W  D0,(A5)+
002024  2A81             41          MOVE.L  D1,(A5)
002026  4ED4             42          JMP     (A4)           RETURN TO HALGOL
002028  3A5E             44 TOTAL    MOVE.W  (A6)+,A5
00202A  31D5 1902        45          MOVE.W  (A5),S1
00202E  425D             46          CLR.W   (A5)+
002030  21D5 1904        47          MOVE.L  (A5),M1
002034  4295             48          CLR.L   (A5)
002036  4278 1908        49          CLR.W   G1             CLEAR GUARD
00203A  4ED4             50          JMP     (A4)           RETURN TO HALGOL
00203C  3A5E             52 MOVE     MOVE.W  (A6)+,A5       SET SRC ADDR
00203E  305E             53          MOVE.W  (A6)+,A0       SET DEST ADDR
002040  30DD             54          MOVE.W  (A5)+,(A0)+    MOVE S,X
002042  2095             55          MOVE.L  (A5),(A0)      MOVE MANT
002044  4ED4             56          JMP     (A4)           RETURN TO HALGOL
   # 00001536            59 ROUND    EQU     $001536
   # 00001902            60 S1       EQU     $001902
   # 00001904            61 M1       EQU     $001904
   # 00001908            62 G1       EQU     $001908
   # 000022D0            63 START    EQU     $0022D0

Code Listing 3

                          1          OPT     P=68000,BRS,FRS
0020DE                    2          ORG     $0020DE
                          4 * JUMP TO LABEL IF FPACC1 > OR = ZERO
0020DE  3A5E              6 JIFPOS   MOVE.W  (A6)+,A5       LABEL ADR TO A5
0020E0  1038 1903         7          MOVE.B  X1,D0          TEST ZERO
0020E4  67 10             8          BEQ     JPOS2          JUMP IF ZERO
0020E6  66 08             9          BNE     JPOS1          TEST SIGN
                         11 * JUMP TO LABEL IF FPACC1 IS GREATER THAN ZERO
0020E8  3A5E             13 JIFGTZ   MOVE.W  (A6)+,A5       LABEL ADR TO A5
0020EA  1038 1903        14          MOVE.B  X1,D0          TEST ZERO
0020EE  67 08            15          BEQ     JGTZX          EXIT IF ZERO
0020F0  1038 1902        16 JPOS1    MOVE.B  S1,D0          TEST SIGN
0020F4  6B 02            17          BMI     JGTZX          EXIT IF NEGATIVE
0020F6  3C4D             18 JPOS2    MOVE.W  A5,A6          STORE JUMP ADDR
0020F8  4ED4             19 JGTZX    JMP     (A4)           RETURN TO HALGOL
                         21 * JUMP TO LABEL IF FPACC1 IS ZERO
0020FA  3A5E             23 JIFZER   MOVE.W  (A6)+,A5       LABEL ADR TO A5
0020FC  1038 1903        24          MOVE.B  X1,D0          TEST ZERO
002100  66 02            25          BNE     JZERX          EXIT IF NOT ZERO
002102  3C4D             26          MOVE.W  A5,A6          STORE JUMP ADDR
002104  4ED4             27 JZERX    JMP     (A4)           RETURN TO HALGOL
   # 00001902            30 S1       EQU     $001902
   # 00001903            31 X1       EQU     $001903

Code Listing 4

                          1          OPT     P=68000,BRS,FRS
0021FE                    2          ORG     $0021FE
                          4 * INTEGER PRINT A 32 BIT BINARY WORD TO THE HOST
0021FE  7E A0             6 IPRINT   MOVEQ   #$A0,D7
002200  61 EE             7          BSR     OUTCHR         OUTPUT A SPACE
002202  2238 1904         8          MOVE.L  M1,D1          MANT1 TO D1
002206  66 0A             9          BNE     IPR1           SKIP IF NOT ZERO
002208  7E B0            11          MOVEQ   #$B0,D7
00220A  61 EA            12          BSR     OUTCH          OUTPUT A ZERO
00220C  7E A0            13 IPRX     MOVEQ   #$A0,D7
00220E  61 E6            14          BSR     OUTCH          OUTPUT A SPACE
002210  4ED4             15          JMP     (A4)           RETURN TO HALGOL
002212  70 09            17 IPR1     MOVEQ   #9,D0          SET FOR 9 LOOPS
002214  307C 219E        18          MOVE.W  #BATBL,A0      PTR TO TABLE
002218  5300             20 IPR2     SUBQ.B  #1,D0          DECR LOOP COUNT
00221A  2A18             21          MOVE.L  (A0)+,D5       FETCH CONSTANT K
00221C  B245             22          CMP.W   D5,D1          COMPARE K, MANT1
00221E  65 F8            23          BCS     IPR2           LOOP TIL NOT ZER
002220  60 02            24          BRA     IPR4           UNCOND JUMP
002222  2A18             26 IPR3     MOVE.L  (A0)+,D5       GET NEXT K
002224  7E AF            27 IPR4     MOVEQ   #$AF,D7        ASCII 0 -1 TO D7
002226  5207             29 IPR5     ADDQ.B  #1,D7          INCR ASCII
002228  9285             30          SUB.L   D5,D1          D5=K, D1=MANT1
00222A  64 FA            31          BCC     IPR5           LOOP UNTIL OVFL
00222C  D285             33          ADD.L   D5,D1          CORR UNDFLW
00222E  61 C6            34          BSR     OUTCH          XMIT ASCII
002230  51C8 FFF0        35          DBF     D0,IPR3        LOOP UP TO 9 TIMES
002234  60 D6            37          BRA     IPRX           XMIT SPACE & EXIT
   # 00001904            40 M1       EQU     $001904
   # 000021F0            41 OUTCHR   EQU     $0021F0
   # 000021F6            42 OUTCH    EQU     $0021F6
   # 0000219E            43 BATBL    EQU     $00219E