Issue # 17 DTACK GROUNDED Newsletter - February-March 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

DOCUMENTING HALGOL:

If we are going to really develop HALGOL into a working language we need to confront the issue of how to document the language. Coincidentally, C.A.R. Hoare of Oxford University has written a short article which espouses SIMPLE programming languages and suggests how to document one. The article appears in Electronic Design, Jan 6 '83 on pp 162-3. We will permit Mr. Hoare to speak for himself:

"Thus, I am confident in setting targets of simplicity for programming languages of the future. A formal language definition, expressed by mathematical equations, should occupy one or two pages. An informal language description, in the style of the 'Report on the Algorithmic Language Algol-60', should occupy 10 to 20 pages.

"A textbook should describe how to specify, design, document, and implement programs in the language. It should fill one or two hundred pages and should be suitable for use in schools. Finally, a library of useful algorithms should also be published in both human-readable and machine-readable form."

His one or two page formal language definition is apparently to be written in Backus-Naur form. If we are to follow his suggestions, we will need to find a tutorial on Backus-Naur and locate a copy of the Algol-60 report. Can some reader assist us in this regard?

With the exception of the formal definition, his plan largely coincides with the more loosely defined approach we had already adopted.

(continued on page 8)

Page 1, Column 2

MATH CHIPS REVISITED:

Back around newsletter #2 we told you about a wonderful math chip called the 8087 that was being developed by Intel. Here is an update:

The 8087 now exists. It is unquestionably the best math processor chip which can be purchased today and for several tomorrows. We are NOT, as we indicated 'way back when, going to attach it to our 68000 board.

The first problem is that we can't think of any way whatever that we could produce that chip with its associated 40 pin clock generator without supporting 8086 assembly language. We refuse to do this. Make that ABSOLUTELY refuse.

The second problem is that a lot of extra support chips are required in addition to the 40 pin clock generator. This makes it impractical to provide MULTIPLE math processor chips to support our 68000, which we are now interested in. If it requires the math processor five times as long to perform its calculations as it requires the 68000 to service (load and unload) the chip, then the 68000 can obviously keep five math chips busy in a vector processing application such as matrix computations. Both the upcoming 16082 (National) and the 68881 (Motorola) are usable as peripherals, which means more than one can be used at a time.

A third reason is that the 8087 is NOT EITHER ten times faster than the 68000 at double precision floating point computations. The speed differential is closer to three if we stipulate an 80 bit format (the 8087's "temporary real" format). Here is why the speed differential is less than we had thought:

1. Intel's early promotional literature stated that the 8087 supported double precision floating point (correct) and that the time to perform a floating point multiply was 19 microseconds (also correct). If some dummy such as your FNE wants to interpret that incorrectly as a 19 microsecond double precision multiply, that's not Intel's fault, is it? In fact, 27 microseconds is the time for a double precision FP multiply.
2. Intel's early promotional literature did not emphasize that it requires 9 microseconds to load and 20 microseconds to store a double precision floating point number (single precision is almost as slow, by the way).
3. We were comparing an 8MHz 68000 with a 5MHz 8087. The 68000 now runs 56% faster.

When those three factors are taken into account, the 8087 does not enjoy the overwhelming advantage that we had earlier thought. So, we are going to wait for the 16081 or the 68881. (As is Charles River, by the way.)

Page 2, Column 1

MISUNDERSTANDINGS:

There have been some misunderstandings between what we write and what some of our readers THINK we write lately. Obviously the fault is ours for not making ourselves clear.

ABOUT THAT TRASH 68: we did NOT say that that was what YOU AND WE needed; we said it was what the marketplace needed. The ENTIRE marketplace, 68000 division, needs the TRASH 68 because that is the only way lots of good, cheap 68000 software will ever be developed. But the people who would buy the machine are first time buyers, or perhaps fugitives from Sinclair or VIC land.

REMEMBER, most of that ENORMOUS store of VERY GOOD Z80 software was originally written for the TRASH 80 I, a truly crummy and rotten machine.

(Unfortunately, the market window for a TRASH 68 may close soon. Too bad.)

ABOUT UNIX: when we say that UNIX will NOT be the de facto standard operating system for the mass marketplace, PLEASE remember that we are talking about the MASS marketplace, not YOU, dear reader. (We sincerely hope that our readership has a distinctly different makeup than the mass marketplace.) Perhaps we need to define our perception of the mass marketplace:

For the purposes of discussing UNIX, the mass marketplace is the individual or small company with a CBM 8032/96 or Apple II or (ugh!) III or even an IBM PC and who is using that computer for a work related purpose. We assert that college professors, full time software developers and the like are a very small, vanishingly small, proportion of our mass marketplace. We are talking about reporters with word processors, dairymen, foundry operators, lumber yard operators and others whose primary activation is to use the computer, occasionally, to assist his principal business, which is NOT computers!

The UNIX supporters are to be found among people who work with computers FULL TIME and who are intelligent, activated and committed. As the old joke goes, a chicken is INVOLVED in producing a ham and egg breakfast but the pig is COMMITTED. The mass marketplace is (slightly) involved with their computers, NOT committed. The next time you hear someone tell you how wonderful UNIX is, find out whether he/she is a full time computer user (and therefore committed).

Again, dear reader, you and we are likely more committed to our computers than is the mass marketplace and UNIX may very well be a superb operating system for OUR purposes. In fact, when the price of 20 megabytes of fast disk and a 60000 UNIX come down to our range we will seriously consider using UNIX ourselves. Hasn't anyone noticed that we have almost always first asserted that UNIX is a very good operating system before stating that it is not for the mass marketplace?

Page 2, Column 2

UNIX does seem to be becoming the most common operating system on the HIGH END computers using the 68000. Like Charles River, Wicat and the other $10K to $20K systems. Those are not mass market machines. (Regrettably, there are doggone few LOW END 68000 machines.)

MULTI-USER/MULTI-TASKING: In some cases, multi-user systems are absolutely necessary. How else can we have airline or hotel reservation systems? However, your FNE does not want to work as a reservations clerk and we don't think you do either. Share our CPU with another user? We'd sooner share our toothbrush!

However, that leaves the issue of a single-user system which is nonetheless multi-tasking. The fact is, multi-tasking systems can be very useful to the individual user in SOME cases. Therefore, all things being equal, multi-tasking systems are to be preferred to systems which do not have that capability.

All things are NOT equal. Surprise??

Multi-tasking operating systems require either MUCH more memory or a fast hard disk for task swapping. And the operating system is necessarily more complex. Memory management in hardware is highly desirable. What does the individual owner/operator get for this? A GREAT BIG INVOICE for starters. Oh, yes: he or she can then print out an assembly listing while running an electronic spreadsheet or such. This is worth, to an individual, a great big invoice??? We don't know about you, chum, but we start our long assembly listings just before we stop for lunch. Who needs multi-tasking in a single-user system?

THERE IS A VERY GOOD ANSWER to that question. A business which employs a high-priced, talented professional computer type needs a multi-tasking computer so that it can keep that talented professional busy at ALL TIMES! NO LUNCH BREAKS!

We are indeed fortunate that we are not a talented professional because we do NOT want to be tied to a computer eight hours a day. And since we are not tied to the computer full time, we don't need a multi-tasking system.

And what is MUCH more important, since we don't need a multi-tasking system we don't have to PAY for one! Remember, our main objection to a multi-tasking system is the great big invoice that comes with it.

Page 3, Column 1

UNIX, MULTI-TASKING and the like are all applicable to the full time computer user (in an environment where $10K and up is not big bucks). We are talking about high-end systems for businesses, research centers or universities where intelligent, highly motivated and FULLY COMMITTED computer operators are available.

However, this newsletter does not direct its attention to high end systems. For that we can turn to Mini-Micro Systems. So let us do just that for a bit.

MINI-MICRO WATCH:

The reader may recall that we do not believe it is a deadly sin to misspell a word or commit the occasional grammatical error. Information content is such more important than absolute compositional correctness. Now, sometimes we wonder a bit when we see in an editorial reply to a letter to the editor the following sentence: "The 6800 is a 16 bit data bus(sic, sic and sic)." (Not from Mini-Micro.)

However, on page 193 of Dec '82 Mini-Micro Systems we find a paragraph and accompanying graph which reaches unprecedented heights of inaccuracy. We felt that we should share this with you, so following is the full text of the paragraph in question which is printed under the heading "PLUMMETING COSTS PER BIT":

"In 1977, user costs per bit of storage were forecast to be in the 0.01 cent range by 1982. In experience, however, user costs are now in the 0.008 cent range (Fig. 2). This is an order of magnitude change in only five years. Declines of this magnitude have a stimulating influence on memory use, but also say a great deal about the requirements for success in the industry."

Fig. 2 (from Mini-Micro Systems)

Here are a few of the errors we have found in Mini-Micro's report:

1. That 5 year old forecast was within 20% of current prices! That rates a bullseye, a direct hit! Or doesn't Mini-Micro know that 0.01 is NOT an order of magnitude different from 0.008?

   Page 3, Column 2

2. The forecast and the current prices are prices at the CHIP level. USER prices, for Mini-Micro readers, are prices at the BOARD level.
3. The accompanying graph, Fig. 2, shows a TWO order of magnitude difference between the forecast cost and the actual cost, which does not agree with either the actual figures or the accompanying text.

HOW, YOU MAY ASK, is it POSSIBLE to get your numbers so fouled up? It's like this:

1. 0.01 has only one zero to the right of the decimal but 0.008 has TWO zeros to the right. Obviously there must be an order of magnitude difference!
2. The price of a memory board is the same as the price of all the chips on the board, right?
3. To produce Fig. 2, we first duplicate the graph from the article containing the prediction, which was published in 1977. We extend the graph downwards until we find 0.001 on the vertical axis. That has two zeros to the right of the decimal just like 0.008, so this is where we will start. But 0.008 is nearly ALL THE WAY to the NEXT decade (correct). Um, let's see: WHICH next? Well, this is an article about declining memory prices, so we obviously have to go DOWN from 0.001 nearly all the may to the next decide, right?

ACTUALLY, THAT PARAGRAPH AND GRAPH were part of an article entitled "Semiconductor Memory" with the byline Ronald J. Whittier, Intel Corp. At the end of the article Ron is identified as the vice president and general manager of the Memory Products Division of Intel Corp., Aloha OR. His Ph.D is from Stanford University.

Wasn't it a Stanford University TUBA PLAYER who delivered the key block that won the Big Game for Cal this season?

ERRATA:

We discovered a small bug in the floating point package published in newsletter #15 while testing the transcendental functions. At line 909 we have an entry point which concludes with writing over the mantissa in memory. Unfortunately, at lines 891-2 and also at 863-4 we had ALREADY stored the information. Please note that the bug is in the very LAST lines of the code; we were in a BIG hurry to test the matrix package!

The easiest 'fix' is to change the code at the two earlier locations. Referring to the code as published in newsletter #15, delete line 892 & change line 891 to:

Page 4, Column 1

 4245    SHL1     CLR.W   D5             ;CLR B15-B0

Change lines 863 and 864 to:

 4844    SHW1     SWAP    D4             ;CLR B31-B16 
 4825             CLR.L   D5             ;CLR B15-B0

If you pad 3 NOPs after the first change above and two NOPs after the second change, all of the code entry points will remain unchanged (the patches above actually REDUCE the code size). If you do NOT pad with NOPs, change line 53 on page 16 of newsletter #16 to:

         SUBX     EQU     $2566

Extended testing of a transcendental package is about the best way of debugging the floating point package used by the transcendental package. If any bugs remain in the FP package, they are VERY obscure!

A SILLY SCENARIO:

The time is a century from now; commercial mining of the asteroids has been going on for the past twelve years. An exceptional discovery is made: a perfectly smooth asteroid, egg-shaped with a flat spot on one side. Since it is definitely not a stone or simple nickle-iron structure, it is returned to Earth for study.

At the press conference for its official unveiling, someone notices a small button on the more pointed end of the 'egg' and does the obvious thing. To everyone's surprise, the top of the 'egg' splits open, revealing an apparently human occupant. By 'apparently human' we mean that it appears to be a normal adult male except that there is no hair to be seen ('he' is nude) and 'his' skin color is a marbled purple.

While everyone is gawking, 'he' sits up, steps out of the 'egg', strides quickly out of the room and starts purposefully down the hallway. A reporter with a mini-holocam comes alert and catches up with 'him'.

"Where are you going?" asks the reporter.

"Why, I'm going to write a disk operating system" 'he' replies,

ISN'T THAT RIDICULOUS? One does not write a disk operating system without having accrued a minimum of experience. Where does one gather experience? Why, from ones' past, no?

Page 4, Column 2

When we found out how numeric variables were saved to disk using Apple DOS this past summer, we were incredulous at first. However, it just happens that HP DOS for its small computers, as of 1975, used that same technique. HP DOS also used one-character-at-a-time into and out of the buffer (and was ALSO slow).

Why does Apple DOS use this same inefficient procedure? Where did Wozniak work in 1975?

If you would like to know where the famous industry standard BASIC originated, and why the strings do not work properly, we suggest that you take a look at the BASIC (actually DEC SUPERBASIC, naturally) that ran on the DEC PDP-10 in 1974. Let's see now: what computer did Bill Gates & partner work on before becoming involved with MITS and the Altair?

It may even occur to you that the facts (well, opinions) expressed in this rag just might be influenced by OUR past. So, it is only fair that you know that we worked as a circuit and instrument design engineer, in small company environments, from 1961 to 1972. The equipment we designed was used to test ICBM class inertial gyroscopes. Therefore, since we are talking about Department of Defense funding of a vital part of our military effort, performance was everything and price was relatively unimportant. During the last three years of this period, we begin to become familiar with computing via the WANG 500, 520, 600 and the 2200.

It will not surprise you that the initial form of HALGOL is related to the way the WANG 500, 520 and 600 programmable desk calculators work. You should also not be surprised that our distaste for Microsoft string functions (Applesoft division) is based on the fact that we have been accustomed to a BASIC in which the strings operate correctly (WANG 2200 BASIC).

In 1973 we started Digital Acoustics to meet the perceived need to automatically monitor environmental noise. Although our DA607P is the de facto industry standard, it turned out that there was a lot more talk involved on environmental issues than funding. As a result Digital Acoustics never grew from its beginnings; it just slid sideways and paid its bills. However, we DID spend a lot of time learning about microprocessors and assembly language.

We even owned a minicomputer for a very (thank heavens) BRIEF time in 1973. It was a 32K DCC 116, which was a Data General Nova look-alike.

It can reasonably be said that DTACK GROUNDED is based on a combination of our bias toward high performance from our inertial guidance test equipment background and the experience we have gathered with microprocessors here at Digital Acoustics.

Page 5, Column 1

HOW TO MAKE ENEMIES:

SCENARIO: hard-working hacker pounds away on his Apple using Pascal or Basic or assembly language. After weeks of hard effort, contacts your FNE and proudly proclaims that he (no she so far) has, no lie, just got a real genuine 68000 cross-assembler up and working. Happily suggests that FNE must be trembling with anxiety in his haste to receive copy of same to evaluate. But... SHOCKSVILLE!! FNE yawns and expresses no interest whatever. Doesn't even want to SEE the triumphal result of magnificent and glorious effort!!

Why?

This is the way it is: The first complete and useful 68000 cross assembler available to us came from Phase Zero. It mostly worked right from the start, and Phase Zero has supported its customers. At this time we are not aware of any bugs in that package.

We have over TEN THOUSAND lines of source code on various DOS 3.3 diskettes. We are generating additional code-on a nearly daily basis. A substantial portion of that source code is distributed to our customers. In the future we will distribute even MORE source code, ALL in the Phase Zero format. By the time you read this, we mill have a programmer on our staff who will do nothing but assist in the development of HALGOL, which will ALSO, you should not be surprised to discover, be distributed in Phase Zero format.

If you wish to be able to personally use/modify/improve this source code, you must either: 1) Have the Phase Zero assembler, 2) Be prepared to retype many thousands of lines (without error, of course), or 3) Have a different assembler which HAS A CONVERSION PROGRAM TO CHANGE FORMATS (hopefully bi-directional).

How much Phase Zero stock do we own? None. What kickback do we get on each assembler sold? None.

We are sticking with the Phase Zero assembler for the simple reason that we MUST have a STANDARD if we - that is, you and us - are going to be able to work together and exchange source code which is mutually useful. Since the Phase Zero assembler was first, and works, and is supported, it makes sense to standardize on that cross assembler. Let us note that it is NOT necessary to have a DTACK board to use that (cross) assembler!

We have been contacted by at least 15 different persons who have developed cross-assemblers independently. The total number of lines of code we have keyed in using all those other cross-assemblers is zero AND WILL REMAIN ZERO. For good and logical reasons.

Hence, we lose one friend for each non-standard cross-assembler that gets developed. Sigh.

Page 5, Column 2

Here is how we can be friends again: Write bi-directional conversion routines from Phase Zero format to YOUR format, and back again. That way we can exchange source code in Phase Zero format. If your cross-assembler is offered commercially, we will mention it in this newsletter if you can convince us that such bi-directional conversion routines exist, are provided, and that they work. There will be no charge for the first six or so announcements, so start writing those conversion routines NOW, OK?

IBM PC WATCH:

We picked up an issue of PC, 'The Independent Guide to IBM Personal Computers'. This one is Vol 1 #7. Lots of interesting stuff. It seems that the cynical viewpoint that IBM deliberately screwed up the keyboard to protect sales of the more expensive DISPLAYWRITER is becoming near-universal (see p.175). What puzzles us is that the numerous carbon-copies of the PC which are appearing are all using an almost EXACTLY identical board (presumably the one offered by KEY TRONIC). We would think there would be a good market for a non-busted PC keyboard. (See also p.242, Dec '82 BYTE, "That Wrecked Keyboard".)

New bugs in the PC continue to surface at an astonishing rate. For instance, '.1' does not equal '.10'. They do not PRINT as the same number either (page 302). The same page cites chapter and verse to conclusively prove that PC BASIC is translated 8080 code.

On page 29 PC reports that there are bugs in IBM's FORTRAN compiler. If one attempts to utilize more than 256K RAM one tends to get ERROR 1268, dynamic file allocation limit exceeded. The staff at PC do not seem to have made the connection with the fact that, although one can install MUCH sore than 256K RAM, the maximum RAM configuration available from IBM is, you guessed it, 256K. We would write the PC staffers and point this out but almost all of them walked out together recently to start a new publication called 'PC World'.

(For related reading on FORTRAN bugs, see the two letters on page 22 of Dec '82 BYTE.)

WHY ARE WE READING ABOUT THE PC? Because in 18 months or so we are going to offer an attached processor for that machine. 68000? Nope. The 68020 should be coming out about then. And it will take that long for most of the PC owners to realize they have a slow machine which needs fixing (most IBM PC buyers are first-timers).

Also, we have neither the time nor the personnel to tackle that market right now.

Page 6, Column 1

MISCELLANEAE:

WE HAVE BEEN INFORMED that the word above is NOT the correct Latin spelling of the plural of miscellaneous. Who said it was Latin? We just think it sounds sort of pluralish, which is what we wanted. We DID take 3 or 4 semesters of Latin in high school. Perhaps we should say we took the courses. The Latin obviously didn't take.

AFTER WRITING (YET AGAIN) about UNIX we had the pleasure of chatting with a full-time professional programmer. The computer on his desk has an 8MHz 68000 with no wait states, one megabyte RAM with memory management and a 60 megabyte hard disk. This is a single-user multi-tasking system, and he is quite pleased with its performance (he actually sounded smug). His operating system? Why, UNIX of course! We neglected to ask whether his employer permitted him to take lunch breaks. Oh, yes: you can buy a system exactly like the one he has for $30K give or take $5K.

WE ASSUME THAT ALL OF YOU spotted the photo of Apple's LISA on page 26 of TIME magazine, the first issue of 1983. It is heart-warming to know that Steve Jobs is working people 90 hours a week, 7 days a week. That takes for a wonderful family life for married persons and a full social life for single persons. When do these people shop for groceries, do their laundry, mop their floors? Is Mackintosh really worth that level of dedication sustained over two years or more? And to think that many people were appalled at the hours Data General employees put in as reported by Tracy Kidder in his Pulitzer prize-winning book!

For the benefit of those youngsters who have not yet studied the French monarchy, it is NOT a compliment to say that someone would make a good king of France. For instance, one French king roasted himself to death. The fireplace was too hot, but instead of standing up and walking away from the hearth, he waited for his bearers to do the Job (oops! job!). He waited too long.

WE HAVE THIS PERSONAL FRIEND who sometimes takes our newsletter a tad more seriously than we intend. He was particularly concerned when we postulated in Newsletter #4 that the reason for a re-introduction of the Apple III was to avoid getting hit with an adverse auditor's opinion on their (legally required) annual financial report over the worth of slow-moving stock sitting in their warehouses.

As part of the writeup, we had to explain that the purpose of the legally required independent audit of a publicly traded company was to prevent the officers of the publicly traded company from over-stating the true worth of the company by, among other things, insisting that 'dead' inventory was in fact valuable.

Page 6, Column 2

Well, the publicly traded company HE works for terminated a production program and moved some completed gadgets and a lot of parts into a warehouse. They continued to carry that inventory at full value on their books although they had stopped trying to sell the parts. Guess what? They just got hit with an adverse auditor's opinion after the bottom line of their annual financial reports

THE THOUGHT OCCURS that you may be getting tired of reading about SIMPLE 68000 systems. If so, by all means get hold of an Oct '82 issue of Mini-Micro Systems and check out the article on the Charles River 68000 system beginning on page 193. This is DEFINITELY not a simple system!

This article, written by an employee of Charles River, asserts that their 68000 runs at 12.5 MHz with no wait states 70 to 95 percent of the time. Just exactly how many wait states are involved the other 30 to 5 percent of the time was not stated. But Fig. 1 shows their 'slow' memory as having a 760 (?!) nsec access time. Sounds like a great big bunch of wait states to us. Did we ever tell you that there is such virtue in simplicity?

SOMEONE KEEPS STEALING our two $120 paperweights and carrying thee back to the R & D department (would you believe R & D closet?). You don't think someone thinks the NEC 7220 graphics controller chip is intended for higher service than being a paperweight? Just because it can draw lines and circles (well, arcs of circles) at 1.25 million pixels per second?

GLEANINGS FROM JAN. Microcomputer Printout magazine: "...(on seeing TRON) the third time round we spotted a joke at Apple's expense..."

Why would anyone poke fun at Apple?

Also: "...what's the significance of '64' in Commodore 64? ... it means that there is 39K of RAM available for BASIC programming." Hmm...

(In the preceding issue, Julian Allason's 'Hotline' column had, ahem, a few typos. We are pleased to see that Julian acknowledged same in this issue and in fact accepted with good grace a tiny jibe in the letters column: "Pass on our 'get well soon' wishes to your pruff reader.")

(This is to be contrasted with gossip columnist Inside Trader's churlish reply to your FNE some months back when we pointed out that our name had been misspelled in his column. You would think ANYONE could spell F - N - E properly, wouldn't you? Oh well, the English never were very good at the American language.)

Page 7, Column 1

ANOTHER TYPO:

Julian isn't the only one plagued with typos lately; we had a totally inexplicable one ourselves on page 15 of the last issue. Before we tell you about the typo, a little background.

In ISO World, Jan 10 '83 there is a headline story, text on page 3, about Commodore signing with Zilog as an ongoing second source for the Zilog line of 16 bit microprocessors. WHAT A SUPRISE! That means that the next to last paragraph on page 13 of our last issue was NOT correct; the paragraph WAS related to the next to last paragraph in the FIRST column which asserted that Commodore was about to sign an agreement with a manufacturer of 16 bit microprocessors. In fact, by a remarkable coincidence the two paragraphs in question just happen to sit side by side.

Now, about the typo: we simply cannot understand how, in the sentence '...but we promised not to tell.' the word 'promised' was misspelled as 'promized'.

THE SAME ISSUE OF ISO WORLD asserts that an informal survey in the Silicon Valley area revealed at least 90 ongoing projects which involve the 68000 together with UNIX. Has anyone figured out how many of those can possibly survive such a crowded marketplace?

Does that count as 90 each 68000 design wins, or 88 each 68000-related future bankruptcies, or both of the above?

SPEAKING OF 68000 PRODUCTS:

As everyone knows, since we manufacture a particular brand of 68000 product, it is a fundamental law of nature that we will denigrate all competing products. Keeping this in mind, there is an Apple compatible 68000 board available from West Germany via an outfit called 'IBS'. This board is a conventional Apple peripheral board which plugs inside the Apple. It has 128K DRAM and most likely has DMA capability.

Our correspondent reports that it "...is cheaper than the DTACK board and the software offered is quite interesting... the IBS card at average is as swift as a 5MHz DTACK board..." Three pages of specs were also forwarded but we do not read German so we have no idea what they say or what the 'interesting software' is.

However, it is about cotton-picking time that someone ELSE made a decent 68000 peripheral board for the Apple II. And developed some good (or at least interesting) software. We'll let IBS have the 'under the hood' 68000 market and continue to develop our 636K Melkin for people who want a BIG memory and an expansion interface.

Page 7, Column 2

BYTE WATCH:

Our Jan '83 BYTE magazine came in yesterday's mail so we happily tore the plain brown wrapper off and turned to the table of contents. YE GODS! The first item to catch our eye is: "...the advantages of a single-processor multiuser system..." ADVANTAGES?? SINGLE-PROCESSOR?? MULTIUSER?? On the assumption that we have another typo here, we turn to the article.

On page 152 we find: "Hardware that performs well in a single-user environment may perform miserably in a multiuser environment." Now, that is in eminently sensible statement. Somehow, we feel that we will not encounter the obvious corollary, 'hardware that performs well in a multiuser environment will perform far better in a single-user environment' so we turn the pages forward to find something interesting.

The very next article, on page 166, is a MARKET SURVEY! What do we have here, a copy of Mini-Micro Systems? Well, the front page says BYTE. So we turn to the article about the 68000 machine on page 100 and doggone if THAT doesn't look like a refugee from Mini-Micro.

It looks suspiciously as if BYTE wants to compete with Mini-Micro. And that, dear reader, is a VERY LARGE change of editorial direction because Mini-Micro is not about personal computers. Mini-Micro is about marketing (translation: money) and about selling multi-user systems to management to chain 32 sheep to. One of those chains is reserved for YOU.

We can remember when BYTE was a magazine for personal computer users.

Well, if we can't read about personal computers we can at least get a few laughs. For instance, on page 440 Sage is at it again. Who amongst our readers is prepared to believe that an 8MHz 68000 has 2 MIPS performance? The truth is that an 8MHz 68000 does not even run quite at 1 MIPS! Oh, well, what's a little white lie between friends?

But an even BIGGER laugh can be found on page 437. Chuck Peddle is now the undisputed world record holder at self-promotion. The advertisement on page 437 has his picture (once) and his name repeated 4.5 times. The 0.5 is where just 'Peddle' instead of 'Chuck Peddle' was used. This breaks the FORMER world record of four name repetitions on a one page advertisement (with no picture).

How many of you can identify the former world record holder? Hint: he has pseudonymously appeared in these pages as 'otherwise intelligent'.

Page 8, Column 1

AND NO SOONER DO WE WRITE (elsewhere in this newsletter) that someone ought to offer a proper IBM PC keyboard than somebody does just that. See page 263.

A LARGE SERVING OF EGO:

During the past year and a half, we have received several comments that your FNE has a (huge, gigantic, enormous; choose one) ego. Hey, guys, your FNE writes a newsletter. Accusing a newsletter writer of having a swollen ego is like accusing rain of being wet or a duck of waddling or the Sun of rising in the east!

ANYONE who writes for publication MUST be egotistical enough to think that people will want to read what they write, no? And newsletter writers automatically must have the largest egos of all because what we write is (largely) OPINION. Personal opinion.

However, different people expose their egos in different ways. For instance: your FNE's full name has never appeared in this newsletter after seventeen issues and over 300 pages. But you had better believe that the reason is NOT that we are shy and retiring! So what IS the reason, you ask?

This newsletter is fairly long, touches on many different subjects, and expresses opinions that are often, well, different from the norm. The reader might eventually perceive a personal confrontation with the writer IF the identity of the writer were thrust upon the reader. As it is, the opinions of the writer, not the writer himself, occupy center stage. The reader is left to confront ideas and opinions, not a person.

And you know what? Some of those different ideas and opinions make a surprising amount of sense (there's that ego again).

STILL, WE DO NOT THINK OF OURSELVES as carrying stone tablets down from the mountain. We even, on rare occasion, express an erroneous idea or opinion. This is where YOU, dear reader, come in.

We are in serious need of feedback from YOU. Although we have about 15 regular correspondents among our (currently) 250 subscribers, most of the rest of you are imitating (from our viewpoint) a pet rock. Unfortunately, we don't know what material interests pet rocks. If this newsletter is less interesting than you would desire, have you written to us about it? Is there a particular subject on which you have some expertise AND an opposing viewpoint to ours? Why not write it up?

What we would like from you is information and criticism. Fan mail we don't need. If the silent 94% of our readership would be LESS silent, this would be a better newsletter for all of you.

Page 8, Column 2

(continued from page 1)

Mr. Hoare also notes that some programming languages, including PL/1 and Ada "...provide excellent examples of a cancerous growth in complexity." We can obviously agree with that. But two other points he makes appear to be contradictory. For instance he decries "The pursuit of efficiency on poorly suited computer hardware..." while opposing "Commercial interest, which leads a manufacturer to add features to his language implementation - features that will make it impossible for the customer to transfer his programs to other machines."

Perhaps we are misinterpreting that last bit, but we definitely do not think that a language written primarily to run on the 68000 family should be restricted to features which can easily be duplicated on inferior microprocessors, a point which we will emphasize further on.

Likewise, we are not in complete agreement with the proposition that the book documenting the language needs to be 'suitable for use in schools.' In this country at least, universities usually pick one language, and one language only, as the one which WILL be taught and which WILL be used by the students. A simple language, which is what both Mr. Hoare and we espouse, will never be accepted by a university in this country. (If the language is simple, the computer science profs won't be able to exhibit their obvious superiority.)

We obviously agree that it is a good idea to steer clear of "poorly suited computer hardware..."

It appears that Jerry Pournelle, who writes the User Column for BYTE, espouses HALGOL also, even though he has never heard of the language. On page 18, Jan '83, he writes: "the problem is, why would a practical programmer use a compiler (rather than an interpreter)? Surely there must be ways to let the computer do the bean counting."

Jerry, HALGOL is an attempt to get the speed advantages of a compiler while letting the computer do enough 'bean counting' to make the programmer believe he (or she) is working with an interpreted language. We do have this one question; just how did you know that Digital Acoustics is located in a former bean field?

WE GET (FICTIONAL) CALLS:

We have some material to cover which we feel can best be handled as a fictional series of phone calls. Some of the material is close to phone conversations we have actually had (several times!) and other material has not yet been discussed with anyone. We will simply assign numbers to the callers. FNE is, of course, your faithful newsletter editor.

Page 9, Column 1

#1: I'm glad to hear that you're going to implement HALGOL as an interpretive language. You ARE going to make it compatible with the industry standard BASIC (henceforth 'ISB'), aren't you?

FNE: No. The ISB has some problems, particularly in the way its string functions work. Make that DON'T work.

#1: But what people need is something they can load and run without modification, and there are LOTS of programs written in ISB!

FNE: We ain't gonna. If you're so hot to run 68000 ISB, go buy a $5000 (name deleted) and run slower than a VIC 20.

#1: But if HALGOL were fully compatible with the ISB it would be VERY commercial!

FNE: Prostitution is ALSO very commercial. Most women prefer other careers. Look, we gotta go now. Bye.

#2: ...but you HAVE to make it compatible with the ISB! It's the ONLY way to go!

FNE: We do not have enough time, money or people to write a fully ISB compatible version of HALGOL. Therefore we CAN'T do it, even if we wanted to. Do you have something else to discuss?

#2: (angrily) But most people who have Apples don't WANT to write new programs; they want to run the ones they ALREADY HAVE very (click).

(Yes, we do hang up on people.)

#3: Why don't you want to make HALGOL fully compatible with the ISB?

FNE: Aside from the busted string functions, it is FAR more difficult to force-fit a program to match a program written elsewhere. Especially when what we have is a program which is translated from 8080 code to the 6502, crudely. Even more especially that both the 8080 and the 6502 are 8 bit machines and do things most efficiently 8 bits at a time. A properly written 68000-based language will mostly do things 16 or 32 bits at a time. You have NO IDEA how much grief those 8 'guard bits' in the ISB floating point package caused us, for instance.

#3: Do you realize how big the market is for a completely compatible 68000 version of the ISB?

Page 9, Column 2

FNE: Yes, we do. But we don't have the resources to do the job. Maybe that's a good thing; it would kill us if we got buried under 20,000 or so board orders all at once. As it is, we are profitable and we are growing fairly rapidly.

#3: Would you write a compatible version if you HAD the resources?

FNE: No. We would instead put those resources to work developing an extended HALGOL. We think that is what people with 68000 machines NEED. We realize that what they WANT is something compatible with that ISB.

What we have here is an education problem. It took US a good six months of daily use of our own DTACK board to fully realize, at the gut rather than academic level, that the 68000 should NOT be used to assist the 6502 or vice versa. But every week we hear from potential customers who want to run BOTH the 6502 and the 68000 as EQUAL partners. We tell them they have the wrong idea.

#3: You're chasing away customers!

FNE: So? We think it would be dishonest to deal with those persons otherwise. It's not uncommon for us to tell someone not to buy our board if we think he or she can't handle it. And with HALGOL coming along we will have to chase away fewer people.

#3: You're going to do all this by yourself?

FNE: Heck no. We have a computer science student from UC Irvine joining us after the first of the year. He won't graduate until June so he will be working about 20 hours a week helping firm up HALGOL. And you would be surprised how such of the work has already been done.

#3: Well, good luck!

#4: Come on now! ZERO interpretive overhead??

FNE: People usually think of languages as having integer levels of overhead. The 60000 ISB has two, the 808X and 6502 ISB has one, and compiled languages are generally thought of as having NO interpretive overhead. In fact, compiled programs usually execute as a series of subroutine calls. So the overhead for each function is a JSR and an RTS. Those two functions require 18 and 16 clocks, respectively, for a total overhead of 34 clocks. HALGOL's equivalent overhead is a MOVE.W (A6)+,A5; JMP (A5); JMP (A4). Each of those requires 8 clocks for a total overhead of 24 clocks, 10 fewer than the subroutine call.

#4: But do you REALLY mean ZERO interpretive overhead?

Page 10, Column 1

FNE: (laughing) Of course not! We just mean that the amount of interpretation is pretty close to zero, FAR closer to zero than to one. If we were a religious zealot like some FORTH types, we might insist on absolutely zero interpretation. But we aren't

#4: Can you give me an example of something which could be interpreted without violating your idea of running as fast as possible?

FNE: Almost any I/O function you would care to name. PRINTUSING is possibly the best example that comes to mind. The easiest way to handle that function is to interpret the format field at run time.

If you are going to print something it is either going to the CRT to be interpreted by a very slow chemical-based computer or it is going to a hard copy printer. In either case, the 68000 can interpret the PRINTUSING format statement fast enough so that the system will not be slowed down. Unless maybe you have a 50,000 line per minute laser printer?

#4: Is that ALL that will be interpreted?

FNE: Absolutely not! The ENTIRE interactive (or editing) phase will be COMPLETELY interpretive! But since we are interfacing with that slow chemical-based computer again, the slowness won't be noticed. The interactive or editing phase is really an I/O function.

#5: So HALGOL will use threaded code? Doesn't that make it really a dialect of FORTH?

FNE: Absolutely not. Threaded code is probably the ONLY similarity to FORTH.

#5: But you said HALGOL would be user-extensible! Sure sounds like FORTH to me!

FNE: HALGOL will be user-extensible because we will provide the source code on machine-readable, user-modifiable floppy disks, plus enough documentation of how the language works so that the user can add any functions he wants.

Look: FORTH is written in FORTH. HALGOL is written in assembly language. FORTH has about 100% run-time overhead, HALGOL close to none. Maybe 5%?

#5: How else is HALGOL different from FORTH?

FNE: FORTH was born when 16K of random access memory was VERY expensive. As a result its design emphasizes compactness of code at the expense of some run-time overhead. HALGOL is designed for the new world where everybody has more than 64K. A LOT more than 64K. We are going to use that cheap RAM to reduce the run-time overhead in addition to allowing larger programs.

Page 10, Column 2

Bigger programs need better documentation. FORTH programs and documentation are like pigs and perfumed baths; they are rarely seen together. On the other hand, HALGOL will specifically be designed to enhance documentation and readability.

#5: If HALGOL isn't like FORTH, what IS it like?

FNE: Why, HALGOL is obviously BASIC with a run-time package that is optimized to work very well indeed, meaning very swiftly indeed, with the 68000 family of microprocessors!

#5: So why not CALL it BASIC?

FNE: First, we like to have a little fun around here. Second, if we call it BASIC we get an absolutely perfect knee-jerk reaction: "It's just GOTTA be ten million % compatible with the ISB!" And we've become concerned recently that the terms "68000 BASIC" and "slow" will become synonymous. If you've read the front page of our last newsletter, you'll know what we mean.

#6: ...but if HALGOL is optimized specifically to work with the 68000, it won't be transportable, will it?

FNE: Certainly. HALGOL will be transportable to the 68008, the 68010 and the 68020.

#6: How do I transport HALGOL to an Intel-based computer?

FNE: You don't. Look, if we deliberately design a language to make the most effective use of the extended register set and other good features of the 60000, it follows that inferior processors will NOT be a good fit for that language.

Turn the idea around. Look at Softech's 68000 PASCAL release 4.1 for instance. The program is limited to 64K and so is the data. THAT you can transport to an 808X! Is that the kind of 'transportability' that you want?

#6: But if a really good program is developed using the speed of HALGOL and the 68000, how can someone with an IBM PC use that program?

FNE: If he does not have some sort of 68000 add-on for his PC, he will have to purchase an Apple II/DTACK combination or buy some other 68000-based computer which has HALGOL installed (assuming such a computer exists). In other words, we achieve portability by porting the customer to the 68000 hardware, not the program to the customer.

Page 11, Column 1

#6: (scornfully): That sounds dumb to me!

FNE: The alternative is to restrict 68000-based languages to forms which will run effectively on inferior microcomputers. Which means the 68000 will run more slowly than is necessary. Why cripple 68000 software to maintain compatibility with inferior processors? Now, that WOULD be dumb!

#7: ...but if you're a small company, how are you going to manage to produce HALGOL in a reasonable period of time?

FNE: In pieces. First we will implement the numeric (floating point) functions. If you have been following this newsletter you will know that we have done that already. Next we need input and print functions for the double precision format and we will have a language which can solve many types of numeric problems.

Once that is out, we will implement numeric arrays, saving data to DOS 3.3 disks in a reasonable format (the way Apple does it is NOT reasonable) and the printing of literal strings.

After that we would work on strings, done correctly, and string arrays. Integers, integer arrays and matrix functions could be postponed until much later.

#7: (impatiently) But I want some useful 60000 software RIGHT NOW!

FNE: (reasonably) Then go buy a Tandy 16. Bye now.

#8: BASIC is a truly crummy language for writing large programs. After a certain size GOSUB 1370 or GOTO 340 becomes meaningless. Look at a listing of your own "Hand Assembler's Helper" program and you'll see what I mean.

FNE: We agree that 'GOSUB 1370' becomes meaningless in a large BASIC program. That's why HALGOL will not HAVE any line numbers at run time. So you could not use HALGOL to 'GOSUB 1370' if you wanted to. Well, maybe if you insist on designating "1370" as a label. But GOSUB "CALC STD DEV" is a mite clearer.

#8: What about long variable names?

Page 11, Column 2

FNE: Use the variable name "antidisestablishmentarianism" if you want. But PLEASE don't use "supercalifadulisticexpialidosis"! That is a lexicographical Piltdown man! Even if there WAS a song about that word in the movie "Mary Poppins." Look, one day Mr. Funk and Mr. Wagnall agreed that it was a shame that the longest word in the language was in Webster's dictionary. So they invented "super etc." and defined it as meaning "if"!! And people went for it! Heck, it's right there in print, isn't it? Wagnall and Funk must still be laughing some place. Doubtless they are having no problems meeting the winter heating bill.

#8: What does that have to do with HALGOL?

FNE: Nothing.

#8: OK, we get it. You can use long variable names. But doesn't that waste memory space? If that long name is used 30 or 40 times in the program?

FNE: First, the long variable name appears only ONCE in memory, in the table of variable names. Elsewhere we just have the address of the variable, two bytes only, for each repetition of the variable name.

#8: Wait a minute! There are TWO things wrong with what you just said! First, if what we have in memory is the address of the variable and NOT the name, how can we list the program? Second, if only two bytes are used for the variable address, how are we going to work with a large program, or even an extended HALGOL, where the variables cannot be located in the 64K zero page?

FNE: Let's take those in reverse order. We will have a pointer to the start of variables, just like the ISB. Except that pointer will be a 32 bit address. To find the absolute address of a particular numeric variable, we MOVE.W (A6)+,A0 to get the offset from that base. If we have fewer than 4000 simple numeric variables (which will certainly be the case, no?) then the most significant bit of the offset will be a zero. When we move a word into an address register, the 68000 automatically extends the most significant bit into the upper half of the address register. Now we ADD.L SOV,A0 and we have the absolute address of the variable in address register A0. SOV is that 32 bit base address, of course.

Now, as to how we list the variable name during the interactive phase: Suppose the offset address is $00C0. There are eight bytes in each variable, so we shift the offset address 3 bits right, giving us $0018. Hex(18) equals decimal 24. Since the number of the first variable is zero, that means we have here the 25th variable in the variable table. So we go to the table of variable names and list the 25th name. Simple, no?

#8: It sounds almost TOO simple.

FNE: There ain't no such thing as too simple!

Page 12, Column 1

(We realize this is pretty dull stuff, so we are going to stop for now. But we will carry more of this material in the future for those of you who are interested in the structure of HALGOL.)

(What amazes us in retrospect is that no one has implemented such a language already. The benefit of maximum speed while maintaining the user friendliness of an interactive language has not previously been attained in a simple language, as far as we know. And yes, the term 'user friendly' is being overworked these days.)

SOFTWARE REVIEWS:

It is traditional here that we do NOT pick on individuals unless they are 'public figures'. Let us explain in advance that Jim Strasma has his own keyboard and publication, with circulation greater than ours, and is well able to defend himself. M000SE has lost its amateur status on account of offering software for sale, presumably for (intended) profit.

Several months ago, we were searching for a mail list program. A colleague gave us a disk, asserting that it contained a mail list program written by Jim Strasma.

Before trying the program, we had occasion to chat with Jim on the phone, and asked in passing what the price of his program was. Jim replied that he had written TWO mail list programs. One was in the public domain and he charged (as we recall) $35 for the other.

Shortly thereafter, we loaded his program on our CBM 8032 and ran it. It came up with a short menu of about five items and asked, "COMMAND?". We selected the entry command by entering the number of that command as listed on the menu. Sure enough, we were then able to enter our own home address successfully. Having completed the entry, the system came back with "COMMAND?".

There we were with an 80 column 25 line CRT and all we can see is ONE LOUSY WORD, a question mark and a blinking cursor. WHAT command? WHERE command?? Jim is a sometimes member of the clergy for a Protestant denomination. It is a very good thing that he was not present to hear our X-rated remarks!

That mailing list program of Jim's was obviously never meant to be run for the first time. If that is the program that Jim charges for, he is overcharging his customers by $35! Needless to say, that is NOT the program we are using for our computerized sailing list. We are using Apple Post, $50 from the Apple Computer Co. Our secretary reports that the program runs satisfactory except that she gets tired of waiting for the sloowww Apple disk.

Page 12, Column 2

A computer program which one writes for others MUST be written so that others can run it the FIRST TIME. That means menus on the screen and/or adequate hard copy instructions. Which brings us to the M000SE program:

M000SE, 97% of your intended customers have envelopes and file cabinets and file trays and general stacks of paper which are ALL exactly 8.5 by 11 inches. That happens to be the size of this newsletter. If you are going to service 97% of your customers properly, you MUST provide documentation on that size paper.

Before we continue, we need to explain that we played chess several times a week when in high school and played at least weekly up til 12 or 13 years ago, which (come to think of it) is when we became enamored of computers. On the other hand we have NEVER played any computer chess game.

So, when we sat down to play our first game with the M000SE, we were naturally HIGHLY DISPLEASED to discover that, like Jim Strassa's mail list program, the M000SE was never intended to be played the first time.

We have corresponded with M000SE regarding this, and received the reply that the M000SE is exclusively intended for the use of TOURNAMENT computer chess players. Such expert players will, naturally, know how to run the program. M000SE has, however, agreed to provide additional information including a comparison of standard (to us old fogeys) chess notation such as P-K4 and B-QB4. When M000SE actually completes this additional information and includes it with its 17 page manual, it may be possible for a mere chess player to run the M000SE!

Apparently it had not occurred to the authors of the M000SE that there are very few tournament chess players who own DTACK boards and vice versa.

M000SE, assuming that you are looking for CUSTOMERS, let us offer this suggestion: put the COMPLETE command syntax in the manual along with the comparison of the command syntax with conventional chess book notation. Finally, go find someone like your FNE who is a chess player (and can sort of operate the Apple II) but who has NEVER played a computer chess game AND TEST YOUR INSTRUCTION MANUAL ON HIM!

We suspect that we have a wonderful program here for persons running a computer chess program for the FIFTIETH tine.

ON THE NEXT 4 PAGES:

On the next four pages you will find the operating instructions for a (public domain) 68000 monitor with single stepping and a disassembler(!).

Page 13

SSMON ; a Monitor for the DTACK Grounded MC68000 board with an Apple II host.

This monitor has been in use for a few months and seems to have had all the principal software faults rooted out of it. It is set up for a 12K board and should be modified for other memory sizes for the most useful configuration. The monitor provides the standard features of examining and modifying memory and so-on, similar to the monitor provided by DTACK Grounded. It provides the capability to disassemble code and single-step through programs as well as load and save programs in the Phase 0 Assembler format. Since the code is "ROM-able" it could be relocated to the language card and write-protected for maximum RAM space.

In writing this monitor I wanted to preserve as much of the Apple II monitor features as possible to make learning command syntax easier and help provide an easily transported design model. In addition I wanted to use a lot of the monitor furnished by DTACK Grounded and written by Phase Zero's Rifkind - both to save time and to keep output in a familiar format. You will be able to see many of the parallels if you use the program.

The trace/trap routine was written by my son, Larry using the excellent Motorola 68000 facilities provided for this. The program looked too short to believe at first. Some of the features imbedded in it are to comply with a few 68000 requirements that are, apparently, not in the Motorola manual. The manual is generally excellent and, I think, a great aid to any one interested in assembly language programming of the MC68000 family of microprocessors and associated devices. Development of the monitor started with this routine, but development of the routine was not complete until a Phase Zero ASSEM68K had been obtained and much of the monitor was available to check out the program.

The prompt character is " ! " except in the register modify mode, as explained later. The monitor is loaded at $8000 and the prompt will appear upon an 8000G command from the monitor or a BRUN SSMON. Most of the commands are similar to those used in the Apple Monitor, the primary difference being that the input and output are word and long word oriented rather than byte-oriented.

Each of SSMON's operations which requires special MC68000 code has that code loaded to the DTACK board from the data stored in the Apple when SSMON is BLOADed. This feature allows the user to use and overwrite portions of MC68000 memory used by SSMON in between calls to SSMON. It will not, of course, allow you to overwrite the stack and get away with it.

In the description below, AAAA signifies an address of from one to six hex digits, HHHH stands for a word input of from one to four hex digits and HHHHHHHH stands for a long word input of from one to eight hex digits. All other letters such as commands and example entries are shown below as they should appear on the screen.

All commands are terminated by a carriage return when the "!" prompt character is on the screen. When a sub-mode is selected, such as register modify or single step the prompt character does not appear and the required command syntax is explained below.

Page 14

COMMANDS

• Examine memory:
  AAAA.AAAA
  Entering 2300.2344 will display memory words between those addresses. Odd address are truncated to even ones.
• Change memory:
  AAAA:HHHH HHHH HHHH .........
  Entering 2344: BA23 5 FF will set $2344 to $BA23, $2346 to $0005, and $2348 to $00FF
• Move memory:
  AAAA<AAAA.AAAAM
  Moving the DTACK PROM monitor out to $3000 is accomplished by; 3000<0.400M
• Jump to a given address and begin execution:
  AAAAG
  To run a program beginning at $2400 enter; 2400G
  If the program locks up in a loop you will have to get the 68000's attention by use of the next command.
• Reset the 68000:
  I
  This executes the DTACK PROM monitor reset program and sets the supervisor stack pointer to $3FF8. This is the "cold start" entry also used when entering SSMON for the first time.
• Quit SSMON:
  Q
  This returns control to the Apple monitor. The "*" prompt will appear and the Apple monitor will be entered at $FF65.
• Switch to the user stack pointer:
  U
  This sets the USP to $3F40 and activates it.

**---Comment: All files are assumed to be stored in the Phase Zero ASSEM68K format and stored to disk via Apple DOS 3.3. This format has an eight byte header ; for details consult their manual. In this implementation of SSMON file sizes are limited to $7600 bytes (with a little safety margin). I will probably rewrite this section when I can buy more memory.

• Load a binary file :
  T(file name)
  To load a file named DEMO saved to disk in the Phase 0 Assembler ( ASSEM68 ) format enter; TDEMO .
  To load DEMO to a location other than the default value enter; AAAATDEMO.
• Save a binary file:
  AAAA.HHHHW(file name)
  To create a file named XPOX and save it to disk from code located at $3120 to $315F (inclusive) enter ; 3120.40WXPOX. This will save the code to disk and add the eight byte header in the Phase 0 format.
  Entering TXPOX will load the file XPOX from disk to the DTACK board at the location it was saved from, ie $3120.

  Page 15

• List instructions:
  AAAAL to start and L to continue.
  Entering 1234L will disassemble the six instructions beginning at $1234. Continuing to enter L will list successive groups of six instructions. Six was chosen because it fits the Apple screen, however the next command allows some flexibility in the number of instructions disassembled.
• Change number of instructions disassembled:
  HHN
  For listing to a printer, for example, you may want more than a screenful of instructions disassembled at a time. 40N will cause hex $40 instructions to be listed for each "L" entered. The default value of 6 is reset for every cold start, either an "I" command from SSMON or 8000G from Apple monitor.

**---Comment: Several programs have been disassembled in this manner and reassembled with the Phase 0 Assembler. So far, in order to get ASSEM68K to assemble the files created this way corrections have had to be made on MOVEM instructions in which only the register mask is given in this disassembler and on some "Q" instructions in which the data are disassembled as immediate with SSMON. Generally minor and easily repaired differences.

• Single-step:
  AAAAS to initialize and S to continue.
  This instruction operates in a manner similar to that of the Apple, but the first display is of the initial condition of the registers and instruction which will be executed with the next S entered. Pressing S repeatedly will then step through instructing showing the instruction just executed on the top of the screen, the register configuration, and the next instruction. Entering any other letter than S will return to normal SSMON mode and the ! prompt. The register display is a ripoff of the one DTACK-Grounded provides.
  The stack pointer for the program being traced is set to $3F40 on entry.
• Alter register contents
  R
  To change the "going-in" register configuration prior to tracing a program via the single-step facility use the R command. It will set up a register display and allow all registers and condition codes to be modified, except the stack pointer. These condition codes, data and address registers are in effect only during the trace operation. The actual register contents from the calling program are saved and restored. If tracing is interrupted by some memory examination, moves and so-on it is likely that the registers will be saved and tracing can be continued. the stack, however, is not saved so that if tracing is interrupted while in a subroutine and then resumed the program will not return properly.

  Page 16

  In this mode the normal SSMON prompt will not appear. Entering Q will return to normal SSMON monitor operation and the ! prompt.
  To reset a data register enter; Dn HHHHHHHH ( where n stands for the register number, 0-7 ).
  D4 4F2 will set D4 = $000004F2
  To reset an address register enter; An HHHHHHHH
  To reset the condition codes enter; C(bit pattern)
  C 10010 resets condition codes per the bit pattern entered. Check the CC register display to make certain you have changed what you wanted to.

**---Comment: When a mistake has been made in programming, for example attempting to MOVE a word to an odd address, the single-step command will not step through the instruction the first time the S is pressed, a good sign you should look for trouble.

Although there are more features that would be useful, SSMON as it stands is good for a beginner (like me) who is attempting to learn how the 68000 operates on data. I hope it is helpful to someone else, and I have placed it in the Public Domain. If you find a fault I'd appreciate it if you'd tell me.

PW Soule
969 Via Del Monte
Palos Verdes Estates
CA 90274

(213) 373-2465

We have discussed this matter with Mr Soule and have pointed out to him that he is likely to receive twenty to fifty enquiries almost immediately. Since it will require a disk for SSMON to be useful to someone else and since purchasing, copying and mailing the disks does have a certain expense, both in terms of dollars and time, I suggested that he might want to charge a fee for those persons who would like a copy of the disk.

After some discussion Mr Soule has agreed that it might be best to charge $5.00 for the disk and mailing and handling fee in the U.S. and Canada, or $7.00 as an international money order elsewhere.

(Because Digital Acoustics is a business which pays rent, taxes and other overhead we charge double that amount if you want a disk from us. The people who copy and mail the disk like to get paid for instance!)

Page 17, Column 1

MORE MISCELLANEAE:

12.5MHz 68000s are being shipped again! We received 10 pieces on Jan 18 and another 12 today, which is Jan 26. Supposedly, another 86 are hard on the heels of these 12. So we will be sending notices of availability of upgrade shortly (we hope!). HALLELUJAH!

WE NOW HAVE an Apple IIe. As expected, our DTACK board and software work on it without change.

WE HAVE REPORTS that LISA is a very good piece of equipment. This pleases us as the availability of a good, highly visible 68000 at $9,995 will enhance OUR sales in the $1,000 and under range.

On page 9 of our newsletter #3, back in the fall of 1981 we find this: "A lot of people, including some software houses, perceive that our program will be successful... ESPECIALLY after the Apple Computer Co. introduces its $10,000 68000 machine."

Nobody's going to call us a liar over a lousy five bucks, are they?

IN ADDITION TO IBS, there is another 'under the hood' 60000 board being developed in Texas under the name 'SAYBROOK' by Analytical Engines, Inc. At the San Francisco Applefest last Nov. they were accepting $100 down on a special show price of $795, regular price being $995. The brochure they were passing out at the San Francisco CP/M show this past weekend listed a 'special introductory' show price of $1250. At this rate they will surpass LISA's price tag before long, but hopefully not before they get it working...

And we will know when they get it working because 'otherwise intelligent' put his $100 down on a SAYBROOK board last Nov. and will doubtless come by and show it to us when he gets it. He hasn't come by yet.

IF YOU READ THE SAME REPORTS WE DID of Apple's annual meeting on Jan 19 you will note that Steve Jobs backed off from acknowledging Mackintosh, instead suggesting that we might 'look for an enhanced Apple III later this year'. Besides that, the rumored price tag for Mack has gone from $1500 to $2000 to $4000 in the trade journals, just in the last 4 months. You don't suppose Mack is being developed under contract by Analytical Engines?

Can anyone out there explain to us how Apple can sell both the III, enhanced or not, AND Mackintosh?

NATIONAL SEMICONDUCTOR is in the 'limited sampling' mode on its 16081 math processor now. We are due shortly to receive specifications and hopefully to qualify for a sample. There is a 'bug list'; but that's normal for a part at this stage of development.

Page 17, Column 2

We may wind up selling more 16081s than 68000 chips! Let us hypothetically suppose that it requires 1 unit of time for the 68000 to load and unload a 16081 peripheral chip. Let us also !suppose that it requires the 16081 6 units of time to perform a calculation. It then becomes obvious that the 68000 can keep six of those math chips busy simultaneously. So if we make an accessory board with the appropriate number of peripheral sockets on it, we will have a relatively inexpensive vector processor. Call it the 'poor man's vector processor'. We know a poor man who wants such a machine very badly.

YOU MAY REMEMBER that we have implied that there are a bunch of minicomputer types running the show at Apple Computer these days. And it is true that the vast majority of minicomputer types have nothing but contempt for dinky personal computers such as the Apple II and IIe. To us, this explains why all the income from sales of the II seems to be applied to advertising the III and paying for the development of LISA. LISA is a sufficiently advanced product that even a minicomputer type need not feel compelled to turn up his nose at it.

BACK TO NATIONAL. Nat Semi has an Advanced Products Division which sells mainframes which beat the IBM 3033. The Nat Semi mainframes are, of course, manufactured in Japan by Hitachi. We are talking about machines that use a VAX for a toothpick! One could be forgiven for surmising that people in that line of business just might have contempt for dinky little MINICOMPUTERS!

What does this have to do with Apple Computer? Well, until recently Nat Semi's Advanced Products Division was headed by one Floyd Kvamme. But Floyd quit and has just joined Apple Computer as V.P. Sales, reporting directly to Apple Prexy Mike Markulla (this no doubt makes John Couch deliriously happy).

We wonder: A) Has Mackintosh been dropped in favor of an Apple mainframe? B) What is Floyd Kvamme's attitude toward dinky little minicomputers and personal computers like LISA and the IIe?

Has anyone noticed that Floyd obviously has outstanding contacts at Hitachi, a company which coincidentally happens to be a source of 68000 chips? Did you notice that Hitachi signed a contract list year with Digital Research of Calif (the CP/M people) develop CP/M-68? Can CP/M-68 run on LISA?

THE NUMBER OF COINCIDENCES TO BE FOUND in this industry is simply amazing. Now many of you noticed 'otherwise intelligent''s business plan for his 16032 Apple compatible board in Electronic Engineering Times last fall? How many of you noticed how astonishingly similar that plan was to that of another Apple compatible board vendor (68000 division)? Does everyone remember what the sincerest form of flattery is?

Page 18, Column 1

WIRELESS WORLD:

Wireless World is a British magazine whose editorial policy is very difficult if not impossible to describe. You say find an article on FET-output audio amplifiers or how to interface the Z-80 or an attack on Einstein's Special Theory of Relativity. In the Dec '82 issue there is an article entitled "The New Bureaucracy" by Ivor Catt. We are going to present here excerpts from that article and our commentary:

"In the early days, a factory was owned by the man who managed it, controlled it and understood all the details of its operation. But later, in the industrial revolution, business and industry became larger and more complex, and the owners began to lose detailed knowledge of their operation. The introduction of the joint stock limited liability company (corporation in this country - FNE) allowed ownership to be fully divorced from the understanding. A professional managerial class developed which knew all the details and was therefore able to make the crucial decisions.

"...Henry Ford behaved like an industrial Canute when he tried to keep power out of the hands of his professional management, virtually bankrupting his company in the process.

"...The latest shift is in high technology industry, where most complex problems and decisions are technological, so that power should now move from management to the technocracy. We can see bitter battles during the transfer of power... (after a transfer of power) the old group can only act obstructively.

"...Onto the scene of this rearguard battle comes software, a simplistic new pseudo-technology with no technical content, administered by programmers who are as ignorant as management when it comes to engineering. There are virtually no so-called 'computer science' degree courses in this country (Britain) containing any physics or engineering. The arrival of software is a heaven-sent aid to management in its battle to limit the work of technocracy, particularly because software, the modern clerk's job, is in fact low level management work.

"It is in the interest of both management and of programmers to play down and limit technology, and they do this by developing the myth that software IS technical, possibly THE new technology, although software has no engineering content, and employs almost exclusively programmers with no knowledge of engineering or even of (high) school physics.

Page 18, Column 2

"...Up to the present time another quite distinct battle has been fought between the pure scientist and the technocrat. You will all be familiar with this battle, between sacred scientific search after truth (said sacred search generally funded by the Generals - FNE) on the one hand and profane technological search after profit (tsk - FNE) on the other. In the range from sacred to profane, pure mathematics stands at the most sacred end of the spectrum, then comes applied math, then physics, then engineering. Now the mathematicians, being divorced from the profit active, found it difficult to make a living. However, a decade or two ago, some of these technology-free individuals stooped to programming in order to earn a crust. They discovered that a lack of knowledge of physics and engineering was no handicap, that programing had no technical content, so, reassured, they called themselves computer scientists (although programming is not a science) and talked about such things as 'cybernetics', the 'information revolution', and so forth.

"...The fact that many out-of-work mathematicians took up programing meant that software ended up on the side of pure science in its century-old battle against profane applied science... (programmers) set up departments in what they called computer science, which must be a false name because in such departments no science or computer hardware is taught, only programming.

"...There is no possibility that the present industry, containing as it does personnel 98% of whom have no knowledge of technology, will be able to exploit the gigantic potential of digital electronics in the future."

We have felt for a long time that the sort of 'computer science' taught by the programmers was a bunch of B.S. Our perception is that what is taught in the universities as 'computer science' has little or no connection with the real world.

For instance, take PASCAL. PASCAL was developed as a pedagogical tool in the 1967-1969 timeframe, when most schools could afford only a minicomputer with tape storage. (Pedagogical tools do not have to be useful in the real world.) Floppy disks had not been invented and hard disks were excessively expensive. But here in 1983 we have an ISO standard for PASCAL which only allows SERIAL (tape-based) files! Look, guys, in 1983 nobody but kiddies shooting rocks with their VIC-20s use tape. Everybody in the personal computer field uses disk storage, mostly floppy. But floppy or hard, all disk storage is basically random access. It is LUDICROUS to have a standard today which does not support random access files!

Page 19, Column 1

What's that you say? The ISO Pascal dates back close to 1969? B.S.! It was about a year ago, maybe less, when we read about the ISO committee on PASCAL breaking up in disarray because of the intransigence of the academic representatives over modifying the language so that it could do useful things (as the industrial committee members wanted).

WE GET MAIL:

(And sometimes we read it.) We were reviewing our recent correspondence and came across the following from John R. of St. Paul, Mn: "...(your newsletter) is overpriced but I do enjoy it. You ought to charge your major advertiser more money for the publicity and decrease the cost of the subscription..."

John, after reading your note (evidently belatedly), we went back and reviewed printing and mailing costs on our early newsletters (Migawd! How SMALL newsletter #1 is!) and decided that we could, as a package deal, sell the first 12 newsletters for $15 U.S. instead of $30. As a package deal, there is much less handling and even a significant savings on postage. We aren't going to change the price on the current issues because, you may have noticed, they are now considerably larger.

So here is the new subscription deal:

 THERE IS NO YEARLY SUBSCRIPTION! 

 PUBLICATION INTERVAL IS 4-8 WEEKS 

 SPECIAL PACKAGE DEAL (issues 1-12 only) 
 NO SUBSTITUTIONS!  ALL OR NOTHING! 

 U.S.           $15 per package 
 CANADA         $15 (U.S. funds) 
 FOREIGN        $25 (international money order) 

 
 SUBSCRIPTIONS: 

 U.S.           $15 per six issues 
 CANADA         $15 (U.S. funds) 
 FOREIGN        $25 (International money order)

See? We do read our mail!

Those of you who may be wondering why foreign stuff is so expensive may not be aware that, except for Canada, postage rates are 80 cents per ounce, four times greater than domestic rates,

Oh, yes: we are making the deal automatically retroactive to any order for 10 (or more) issues received by us after 1 Jan '83. We will do this by extending those subscriptions for another 6 issues.

Page 19, Column 2

YOU ARE NOT GOING TO BELIEVE THIS, but we wrote about the IBS 68000 board over a week ago and about the SAYBROOK just this morning (27 Jan). At about 1 PM we received a note in the mail from Bud R. of Long Beach, CA (practically a neighbor). He enclosed a flyer from the CP/M conference in Frisco on the SAYBROOK. His note read in part:

"I am somewhat reluctant to send this to you because you will probably have lots of negative things to say about it and/or why I even sent the article to you..."

Bud, we think you have the wrong idea about us. The IBS card from W. Germany works, it works well according to our correspondent, and we said as much nice stuff earlier in this newsletter as we could, considering we could not read the spec sheet because it was printed in German (how un-American!).

We poked a little fun at the SAYBROOK a couple of pages back largely because we think a company with a rapidly changing price tag on a board which doesn't work deserves a little kidding. Please note that we did NOT say that the board wouldn't be any good once they get it working.

Look, we have been telling people for over a year and a half that it is a very good idea to hook a 68000 attached processor to a host personal computer. Obviously, there are other companies, MANY other companies, who are competent and can take good products. We regard other 68000 boards arriving on the scene as a validation of our assertions.

The potential marketplace is HUGE! Just in the Apple community alone, we are rapidly (now that the IIe has arrived) headed toward one million people who desperately need a 68000 processor of some type to help their obsolescent 6502 I/O processor along. There is absolutely no way that we can reserve all, or even a major portion, of that market to ourselves.

What we are trying to do is capture a small piece of that market, at the high end. Therefore our base product runs at the fastest speed possible and fits outside the Apple. Now, that proves that we do not know what we are doing because, as we said before, it is a fundamental law of the natural universe (Apple section) that Apple add-ons are three inches high and ten inches long with a nose job. Both the IBS and the SAYBROOK boards fit that description which proves that they both know what they are doing!

However, we would like to point out that we had a working board and some functional software (a 68000 floating point package hooked into Pet BASIC) before we announced our board to the world. Admittedly that is highly unusual in this personal computer industry, so maybe we shouldn't pick on Analytical Engines very much about that. In fact, if you will review three pages back we took it easy on them, reserving most comment for their rapidly moving price tag.

Page 20, Column 1

It is not our policy to knock competitors just because they are competitors. And we certainly aren't going to knock you, Bud, for sending us the SAYBROOK flyer! In fact, we appreciate the thoughtfulness of you and persons like you who keep us informed on these matters. As it happens, one other subscriber who lives nearby had delivered a copy by hand. But if that subscriber had NOT attended that show, your copy would be our only one.

We cannot read every magazine and book and we cannot attend every (or even hardly any) computer show. If you see something that you think might be of interest to the other readers of this rag, PLEASE call it to our attention, preferably by sending us a copy. (Didn't we already say that earlier in this issue?)

"CAN YOU TOP THIS?" is the header for a letter on page 26 of Feb '83 MICROCOMPUTING (formerly KILOBAUD). It seems that a FORTH programmer in Cicero IL plugged an 8087 into his IBM PC and wrote a matrix inversion program in Polyforth 2 from FORTH, Inc. He managed to invert a 10 X 10 matrix in 0.692 seconds. He then challenged: "...(are there any) users with 68000-based computers who can beat these benchmarks?"

Well, the inversion program we published in newsletter #15 will do the job a LOT faster, Steve. Like about 0.17 seconds, or about 4 times faster. Of course, that algorithm used a 48 bit mantissa, slightly less than the 52 bit mantissa which the 8087 uses. Also our algorithm did not do any pivoting, because the dummy who programmed the routine wasn't sure he knew how.

The time required to invert a large matrix is essentially equal to the time required to multiply two numbers and add a third, plus the time to calculate the addresses and load and store the operands, TIMES the cube of the order of the matrix. If the matrix is not large, there is a small additional overhead.

Steve used a 10th order matrix so that cubed is exactly equal to 1000. Since our 68000 board can do the basic operation in about 150 microseconds, we get about 150 milliseconds or 0.15 seconds as our calculated execution time. But 10 is not a very large matrix so the actual time is about 0.17 seconds, as we have already said.

Page 20, Column 2

Are we claiming that our 60000 is faster than the 8088/8087? No, but we are ALMOST as fast. If the IBM PC used an 8086 with a 16 bit wide bus, the 8087 could perform the basic iteration in 90 microseconds exclusive of address calculation (which might be done concurrently in any event). The 8 bit bus used by the 8088 slows things down; the probable basic iteration time is just over 100 microseconds. That means the 8088/8087 can invert a 10th order matrix in about 0.12 seconds if properly programmed. It would appear that Polyforth 2 has about a 500% overhead in this case.

Which is why we are trying to develop our HALGOL with about 5% run-time overhead.

Also, as we have pointed out previously, the 8088/8087 combo is TWO chips, costing more than TWO 12.5MHz 68000s. A fair comparison of the 8088/8087 against TWO of our 68000s in a matrix inversion benchmark would find the two 68000s winning handily.

WHILE YOU HAVE THAT MAGAZINE, be sure to check out the sub-title on page 58: "Which multi-user operating system will you be using in the future?" NONE, it is to be fervently hoped. We assume that YOU, dear reader, also are not looking forward to be cipher #23 chained to a multi-user system with 31 other sheep.

Perhaps the institution of the 'press-gang' will return. In ports such as Liverpool and Boston, when the ship's company was short a seaman or two come sailing time, the Boatswain and a few of his mates would go out late at night with a billy club and a big gunny sack. Presto! The ship would have a full complement of son come the next morning, with the vessel 20 miles at sea. Naturally, the Captain would offer to let any press-gangee who protested too hard to return. "Just dive over the side and start swimming, lad!"

It would take something as drastic as press-ganging AND twenty miles of water to persuade your FNE to use a multi-user operating system in the future.

WHILE WE ARE AT IT we might as well pick on the sidebar on page 64, same article. There we find "The few drawbacks of CP/M and Unix are compensated for by the reputations they've built over the years." Huh? Look, a drawback is REAL. A reputation is blue smoke! (apologies to Jimmy Breslin) One cannot compensate for something tangible with blue smokes, no?

As the old joke (VERY cleaned up) goes, Pierre the Frenchman is explaining, "George builds great bridges, but do people call him 'George the bridge-builder'? No! Arnold produces fabulous croissants at his bakery, but do people call him 'Arnold the baker'? No!! But commit just ONE social indiscretion..." Gentlepersons, THAT is an example of 'reputation'.

We will NOT discuss the reputation of Cicero, IL...

Page 21, Column 1

IBM PC WATCH II:

Since much of what is being written lately in the trade papers about IBM and its PC is not in accordance with the facts, we thought we would bring you up to date is to what is REALLY happening.

One cannot pick up a magazine about the PC these days without being inundated by gushing praises of IBM management and its foresight and perspicacity in making the PC an 'open' design. The large number of foreign add-ons, the trade journals assert, are helping sell PCs. And since IBM management LOVES to sell lots of PCs, they are pleased with the way things have gone??

(For the record, we believe there may be some merit in some of those trade assertions.)

Let us tell you the true facts; IBM management is absolutely FURIOUS that they have lost so many sales dollars to foreign add-ons and they are VERY actively working at this moment to correct the situation permanently! They are now developing a PC II (shades of Apple II!) whose sole and only purpose in life is to cut off the sales of foreign add-ons. IBM management wants 100 cents out of every dollar spent on the PC line. Here is how they are planning to assure this in the future:

The PC II will be totally incompatible, hardware-wise, with the PC. The CPU will be the iAPX 186, which has a real 16 bit data bus. There will be provision on board for a minimum of 128K DRAM, max 256K before adding plug-ins. The built-in floppy disk drives will have a form factor TOTALLY INCOMPATIBLE with any other floppy disk drive in existence. You will HAVE to buy your disk drives from IBM; nothing else will fit! And since IBM will have no competition, they can price the drives however they like. Naturally, NONE of the extant foreign add-ons will work with the PC II.

NOT INCIDENTALLY, here are some OTHER recent industry doings: IBM has bought a LARGE stake in Intel with cash. Intel has set back shipment of production volumes of the 186 CPU to non-IBM customers by six months. Intel has publicly asserted that the 'problem' is a shortage of the 'chip carrier' mount needed by the 186. Spokesmen for the various manufacturers of 'chip carriers' have VIGOROUSLY denied any such shortage. Since Intel has ALSO denied that there is a problem manufacturing enough 186 chips, that leaves as the only credible explanation that all available 186s (less maybe a few samples) are being shipped to IBM. Of course, Intel has denied this also!! What do YOU think?

WE THINK that almost all Intel 186 CPU production is going to IBM for the early introduction of a successor to the PC, which we have called the PC II.

Page 21, Column 2

MORE COMPETITION! HOORAY!

On page 84 of Feb '83 MICRO magazine there is an advertisement for another Apple compatible 68000 board. Except for the fact that the unit is in a box with a power supply and that the ad asserts a 12MHz (not 12.5) clock rate, the description is identical to the Intellimac board which we wrote up a couple of issues back. Even the $10 for the 100 page manual is identical to the price and size of the manual provided by Intellimac.

The availability of more 68000-based products for the Apple (and for other potential host computers) is very good for YOU. It's good because you have a choice; it's good because competition will force all of the vendors, including us, to be on their toes and provide good service (using the term 'service' in its most general sense).

It is also good for us because, absent competition, it is extremely difficult for us to meaningfully assert that we offer 'good value'. The reply would naturally be "good value compared to WHAT?"

Before you purchase an Acorn, we suggest you determine the frequency of the signal being applied to pin 15 of the 68000. If the Acorn is indeed a packaged Intellimac, as we suspect, that 12MHz clock will refer to the frequency of the Xtal oscillator. Intellimac divides that frequency by two before applying the result to pin 15 of the 68000.

Not incidentally, it is considered um, somewhat less than accurate to specify a 'clock' frequency for a 68000 product which is different from the frequency that is being applied to pin 15. We're not saying anybody is lying, mind you; we are not absolutely CERTAIN that the Acorn is an Intellimac. If we were a betting person we would lay odds, though.

LISA WATCH:

Well, everybody else is writing about LISA. Aside from the gushing reprints of Apple's promotional material, the critiques fall into two groups. The most common comment is that LISA is a very nice overpriced machine (exactly what we have been predicting for more than a year). The minority consent is that LISA is a nice overpriced machine that doesn't have enough software. Now that last bit IS a surprise, Apple has been leaking stuff about the huge amount of software that will come with the machine. Some observers feel that they have not met that promise.

Page 22, Column 1

We suggest that you might want to review pages 6 and 7 of our newsletter #5. That was where we reprinted (in disguised form) a letter received from San Jose in early Dec '81. If you will notice, the writer is describing LISA quite accurately (Apple actually hired some of the people who developed the Xerox STAR). We can now reveal that item #4, which we censored, revealed that Apple was working on a $1500 68000 machine. The first public mention of Mackintosh with that price tied to it was in Sol Libes' column in Dec '82 BYTE (page 541).

(The leaked price of Mack has climbed tremendously more recently.)

It is now obvious that the writer of that letter was a member of Apple's 68000 development group and that we did the writer an enormous favor when we disguised the handwriting and censored item 4. We mean, the guy MIGHT have gotten canned. Remember, Apples' legal staff was reading illegal photocopies of our newsletter back then.

And we wouldn't want that to happen even though he predicted that our company was going to fail! (Tsk, indeed!)

We have this problem: there are more interesting, worthwhile projects to work on than we have hands available to work on them. We have therefore decided that much of our circuit board layout work is going to be farmed out to consultants. This will allow us to introduce new products at a more rapid rate.

Our G-2 suggests that Motorola has the same problem. As a result, work on a faster (shrunk) 68000 has been set aside and all hands are concentrating their efforts on the 68010. We understand that the 68010 will be the chip targeted for speed improvement. The good news is that the 68010 is pin compatible with the 68000, so it should run on the DTACK board. The bad news is they have to first get the 68010 in production before they can begin to speed it up. We do not anticipate product from Motorola faster than 12.5MHz until late this year.

We wonder what Hitachi is doing these days...

Testing of the transcendental package has been completed; all of the routines worked satisfactory except the sine function, which had two minor goof. Because we are running late this issue, we will give you the fixes here and save the description of the remaining transcendental functions (how the algorithms work, that is) until the next issue.

On page 30 of last issue, we will append one line of code:

 002D5C   FPTWO    DC.L $10028000

Page 22, Column 2

Then turn to page 20 and change the label in line 252 from FPONE to FPTWO. This will change the op code from 21F826CA190A to 21F82D5C190A.

Finally, change the destination label in line 261 from S1 to SINSGN. Yes, we are moving the byte right back where it came from. What we are doing is testing the most significant bit. That changes the last byte of the op code from 02 to 22. VOILA! Debugged transcendental package!

Incidentally, the bug fixed by that last change does not affect 99% of random operands. That is why it's necessary to THOROUGHLY test a transcendental package! For the record, about 8 hours testing time was spent for every hour writing the code. Of course, we must keep in mind that several years' experience went into writing that code...

ANYONE WHO READ THE FIRST ISSUE of INFOWORLD (Vol 5, #1 & 2. Don't argue with us, #1 & 2 is ONE issue. The holidays, you know.) will have realized that your FNE is not the only personage who dislikes the management practices of a certain computer company. But get ahold of the Jan 31, '83 issue of Electronic Engineering Times and read the editorial on page 71. We were actually shocked by the last line of that editorial!

HANDY HINTS FOR LETTER WRITERS: If you are going to write us letters vigorously denying affiliation with a particular commercial enterprise, it is a very good idea not to have previously written us a letter, especially within the previous ten days, in which you use the term 'we' three times in one paragraph to describe your relationship with that commercial enterprise. Oh, yes: it is also helpful if your mailing address is not identical to the mailing address of the commercial enterprise with which you are not affiliated

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, III, soft, LISA: Apple Computer Co. Anybody else need a 150 millionth ack, have your legal beagles drop us a line.

SUBSCRIPTIONS: See page 19. Make the check payable to DTACK GROUNDED. The address is:

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

IN THIS MONTH'S (formerly) REDLANDS we have some code which we cheerfully admit is, for now, quite useless. Still, this is the framework upon which we are going to build HALGOL. Remember, your FNE is not the only programmer we have on the premises these days. Which means we might actually get something accomplished.

Code Listing

                         76          OPT     P=68000,BRS,FRS 
003000                   77          ORG     $003000 
                         78 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC. 
                         79 ; 
                         80 ;         *****  HALGOL  ***** 
                         81 ; 
                         82 ; HALGOL IS A THREADED PROGRAMMING LANGUAGE WITH 
                         83 ; VERY LITTLE RUN-TIME OVERHEAD.  THE FLOATING 
                         84 ; POINT PACKAGE FOR THIS VERSION IS THE FOURTEEN 
                         85 ; DECIMAL DIGIT DOUBLE PRECISION 62 BIT PACKAGE. 
                         86 ; 
                         87 ; HERE IS THE ADDRESS REGISTER USAGE: 
                         88 ; 
                         89 ; A7 IS THE MACHINE STACK POINTER 
                         90 ; A6 IS THE PROGRAM POINTER 
                         91 ; A5 IS A SCRATCH REGISTER 
                         92 ; A4 IS DEDICATED TO POINT TO HALGOL 
                         93 ; A3 IS THE PROGRAM SUBROUTINE STACK POINTER 
                         94 ; A2 IS THE DATA STACK POINTER 
                         95 ; A1 IS UNDEFINED AS YET 
                         96 ; A0 IS A SCRATCH REGISTER PRIMARILY USED 
                         97 ;    TO POINT AT FLOATING POINT VARIABLES. 
                         98 ; 
                         99 ; ALL OF THE DATA REGISTERS ARE SCRATCH REGISTERS. 
                        100 ; 
003000  2C78 1A06       101 BEGIN    MOVE.L  SOH,A6         ;PROG ADDR TO A6 
003004  31FC 3272 1A02  102          MOVE.W  #DERR,ERRPTR   ;DEFAULT ERR COND 
00300A  387C 3014       103          MOVE.W  #HALGOL,A4     ;(TRACE OFF) 
00300E  60 04           104          BRA     HALGOL         ;START PROG 
                        105 ; 
003010  4EB8 3270       106 TRACE    JSR     TRACFN         ;EXECUTE TRACE FN 
                        107 ; 
003014  3A5E            108 HALGOL   MOVE.W  (A6)+,A5       ;FETCH ACTION ADDR 
003016  4ED5            109          JMP     (A5)           ;JUMP TO ACTION ADR 
                        110 ; 
                        111 ; MOVE AN FP VARIABLE FROM <VAR ADR> TO FPACC 
                        112 ; 
003018  326C            113          DC.W    EVAR1          ;EDIT LINK 
00301A  322A            114          DC.W    LLOAD          ;LIST LINK 
00301C  3226            115          DC.W    ADD2           ;LINE LINK 
00301E  3A5E            116 LOAD     MOVE.W  (A6)+,A5       ;FETCH VAR OFFSET 
003020  DBF8 1A0A       117          ADDA.L  SOV,A5         ;ADD BASE ADR 
003024  21DD 1902       118          MOVE.L  (A5)+,S1       ;-- MOVE VAR TO 
003028  21DD 1906       119          MOVE.L  (A5)+,S1+4     ;   THE FPACC -- 
00302C  4ED4            120 NOP      JMP     (A4)           ;RETURN TO HALGOL 
                        121 ; 
                        122 ; LOAD AN IMMEDIATE 8 BYTE FLOATING POINT # 
                        123 ; ( THE ACTUAL FUNCTION NAME IS LOAD$ ) 
                        124 ; 
00302E  326E            125          DC.W    ENULL          ;EDIT LINK 
003030  322C            126          DC.W    LLOADS         ;LIST LINK 
003032  3220            127          DC.W    ADD8           ;LINE LINK 
003034  21DE 1902       128 LOADS    MOVE.L  (A6)+,S1       ;-- NEXT 8 BYTES 
003038  21DE 1906       129          MOVE.L  (A6)+,S1+4     ;   IS FP # -- 
00303C  4ED4            130          JMP     (A4)           ;RETURN TO HALGOL 
                        131 ; 
                        132 
                        133 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        134 ; 
                        135 ; STORE FPACC IN A VARIABLE LOCATION 
                        136 ; 
00303E  326C            137          DC.W    EVAR1          ;EDIT LIST 
003040  322E            138          DC.W    LSTORE         ;LIST LINK 
003042  3226            139          DC.W    ADD2           ;LINE LINK 
003044  3A5E            140 STORE    MOVE.W  (A6)+,A5       ;FETCH VAR OFFSET 
003046  DBF8 1A0A       141          ADDA.L  SOV,A5         ;ADD BASE ADR 
00304A  2AF8 1902       142          MOVE.L  S1,(A5)+       ;STORE THE FPACC 
00304E  2AF8 1906       143          MOVE.L  S1+4,(A5)+     ;AT THE VAR LOC'TN 
003052  4ED4            144          JMP     (A4)           ;RETURN TO HALGOL 
                        145 ; 
                        146 ; LOAD VAR TO FPACC AND ZERO THE VAR LOCATION 
                        147 ; 
003054  326C            148          DC.W    EVAR1          ;EDIT LINK 
003056  3230            149          DC.W    LTOTAL         ;LIST LINK 
003058  3226            150          DC.W    ADD2           ;LINE LINK 
00305A  3A5E            151 TOTAL    MOVE.W  (A6)+,A5       ;FETCH VAR OFFSET 
00305C  DBF8 1A0A       152          ADDA.L  SOV,A5         ;ADD BASE ADR 
003060  21D5 1902       153          MOVE.L  (A5),S1        ;-- MOVE THE VAR TO 
003064  429D            154          CLR.L   (A5)+          ;   FPACC1 & STORE 
003066  21D5 1906       155          MOVE.L  (A5),S1+4      ;   VARIABLE -- 
00306A  4295            156          CLR.L   (A5) 
00306C  4ED4            157          JMP     (A4)           ;RETURN TO HALGOL 
                        158 ; 
                        159 ; MOVE VAR1 TO VAR2 
                        160 ; 
00306E  326A            161          DC.W    EVAR2          ;EDIT LINK 
003070  3232            162          DC.W    LMOVE          ;LIST LINK 
003072  3224            163          DC.W    ADD4           ;LINE LINK 
003074  3A5E            164 MOVE     MOVE.W  (A6)+,A5       ;FETCH SRC OFFSET 
003076  DBF8 1A0A       165          ADDA.L  SOV,A5         ;ADD VASE ADR 
00307A  305E            166          MOVE.W  (A6)+,A0       ;FETCH DST OFFSET 
00307C  D1F8 1A0A       167          ADDA.L  SOV,A0         ;ADD BASE ADR 
003080  20DD            168          MOVE.L  (A5)+,(A0)+    ;MOVE S,X 
003082  2095            169          MOVE.L  (A5),(A0)      ;MOVE MANT 
003084  4ED4            170          JMP     (A4)           ;RETURN TO HALGOL 
                        171 ; 
                        172 ; SWAP THE F.P. ACCUMULATOR WITH A VARIABLE 
                        173 ; 
003086  326C            174          DC.W    EVAR1          ;EDIT LINK 
003088  3234            175          DC.W    LSWAP          ;LIST LINK 
00308A  3226            176          DC.W    ADD2           ;LINE LINK 
00308C  3A5E            177 SWAP     MOVE.W  (A6)+,A5       ;FETCH VAR OFFSET 
00308E  DBF8 1A0A       178          ADDA.L  SOV,A5         ;ADD BASE ADR 
003092  2F15            179          MOVE.L  (A5),-(A7)     ;1/2 VAR TO STK 
003094  2AF8 1902       180          MOVE.L  S1,(A5)+       ;1/2 ACC TO VAR 
003098  21DF 1902       181          MOVE.L  (A7)+,S1       ;1/2 VAR TO ACC 
00309C  2F15            182          MOVE.L  (A5),-(A7)     ;2ND 1/2 TO STACK 
00309E  2AB8 1906       183          MOVE.L  S1+4,(A5)      ;1/2 ACC TO VAR 
0030A2  21DF 1906       184          MOVE.L  (A7)+,S1+4     ;1/2 VAR TO ACC 
0030A6  4ED4            185          JMP     (A4)           ;RETURN TO HALGOL 
                        186 ; 
                        187 
                        188 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        189 ; 
                        190 ; STORE A ZERO IN AN F.P. VARIABLE 
                        191 ; 
0030A8  326C            192          DC.W    EVAR1          ;EDIT LINK 
0030AA  3236            193          DC.W    LZERO          ;LIST LINK 
0030AC  3226            194          DC.W    ADD2           ;LINE LINK 
0030AE  3A5E            195 ZERO     MOVE.W  (A6)+,A5       ;FETCH VAR OFFSET 
0030B0  DBF8 1A0A       196          ADDA.L  SOV,A5         ;ADD BASE ADR 
0030B4  429D            197          CLR.L   (A5)+          ;ZERO THE VAR 
0030B6  4295            198          CLR.L   (A5) 
0030B8  4ED4            199          JMP     (A4)           ;RETURN TO HALGOL 
                        200 ; 
                        201 ; GO TO THE ADDRESS OF A LABELLED HALGOL LINE 
                        202 ; 
0030BA  3268            203          DC.W    EGOTO          ;EDIT LINK 
0030BC  3238            204          DC.W    LGOTO          ;LIST LINK 
0030BE  3224            205          DC.W    ADD4           ;LINE LINK 
0030C0  2C56            206 GOTO     MOVE.L  (A6),A6        ;DEST ADDR TO A6 
0030C2  4ED4            207          JMP     (A4)           ;RETURN TO HALGOL 
                        208 ; 
                        209 ; GOSUB TO THE ADDRESS OF A LABELLED HALGOL LINE 
                        210 ; 
0030C4  3268            211          DC.W    EGOTO          ;EDIT LINK 
0030C6  323A            212          DC.W    LGOSUB         ;LIST LINK 
0030C8  3224            213          DC.W    ADD4           ;LINE LINK 
0030CA  270E            214 GOSUB    MOVE.L  A6,-(A3)       ;PUSH OLD PROG PTR 
0030CC  2C56            215          MOVE.L  (A6),A6        ;NEW PROG PTR 
0030CE  4ED4            216          JMP     (A4)           ;RETURN TO HALGOL 
                        217 ; 
                        218 ; RETURN FROM A HALGOL SUBROUTINE 
                        219 ; 
0030D0  326E            220          DC.W    ENULL          ;EDIT LINK 
0030D2  323C            221          DC.W    LRETURN        ;LIST LINK 
0030D4  3228            222          DC.W    ADD0           ;LINE LINK 
0030D6  2C5B            223 RETURN   MOVE.L  (A3)+,A6       ;RESTORE PROG PTR 
0030D8  5C8E            224          ADDQ.L  #6,A6          ;CORRECT THE PTR 
0030DA  4ED4            225          JMP     (A4)           ;RETURN TO HALGOL 
                        226 ; 
                        227 ; CHANGE THE HALGOL ERROR ROUTINE ENTRY POINT 
                        228 ; 
0030DC  3268            229          DC.W    EGOTO          ;EDIT LINK 
0030DE  323E            230          DC.W    LOEGOT         ;LIST LINK 
0030E0  3224            231          DC.W    ADD4           ;LINE LINK 
0030E2  21DE 1A02       232 OEGOTO   MOVE.L  (A6)+,ERRPTR   ;SET ERROR PTR 
0030E6  4ED4            233          JMP     (A4)           ;RETURN TO HALGOL 
                        234 ; 
                        235 ; SEND $00 TO INDICATE END OF HALGOL PROGRAM 
                        236 ; 
0030E8  7E 00           237 END      MOVEQ   #0,D7          ;NULL MARKS END 
0030EA  4EB8 346A       238          JSR     OUTCHR         ;SEND NULL 
0030EE  4EF8 0122       239          JMP     IDLE           ;RET'N TO BOOTSTRAP 
                        240 ; 
                        241 
                        242 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        243 ; 
                        244 ; ADD THE VARIABLE TO THE FPACC AND RETURN 
                        245 ; THE RESULT TO FPACC, LEAVING VARIABLE UNCHANGED. 
                        246 ; 
0030F2  326C            247          DC.W    EVAR1          ;EDIT LINK 
0030F4  3240            248          DC.W    LADD           ;LIST LINK 
0030F6  3226            249          DC.W    ADD2           ;LINE LINK 
0030F8  305E            250 ADD      MOVE.W  (A6)+,A0       ;FETCH VAR OFFSET 
0030FA  D1F8 1A0A       251          ADDA.L  SOV,A0         ;ADD BASE ADR 
0030FE  4EB8 23A8       252          JSR     FPADD          ;ADD IT TO ACC 
003102  4ED4            253          JMP     (A4)           ;RETURN TO HALGOL 
                        254 ; 
                        255 ; SUBTRACT THE FPACC FROM THE VARIABLE AND RETURN 
                        256 ; THE RESULT TO FPACC, LEAVING VARIABLE UNCHANGED. 
                        257 ; 
003104  326C            258          DC.W    EVAR1          ;EDIT LINK 
003106  3242            259          DC.W    LSUB           ;LIST LINK 
003108  3226            260          DC.W    ADD2           ;LINE LINK 
00310A  305E            261 SUB      MOVE.W  (A6)+,A0       ;FETCH VAR OFFSET 
00310C  D1F8 1A0A       262          ADDA.L  SOV,A0         ;ADD BASE ADR 
003110  4EB8 23B0       263          JSR     FPSUB 
003114  4ED4            264          JMP     (A4) 
                        265 ; 
                        266 ; MULTIPLY THE VARIABLE TIMES FPACC AND RETURN 
                        267 ; THE RESULT TO FPACC, LEAVING VARIABLE UNCHANGED. 
                        268 ; 
003116  326C            269          DC.W    EVAR1          ;EDIT LINK 
003118  3244            270          DC.W    LMULT          ;LIST LINK 
00311A  3226            271          DC.W    ADD2           ;LINE LINK 
00311C  305E            272 MULT     MOVE.W  (A6)+,A0       ;FETCH VAR OFFSET 
00311E  D1F8 1A0A       273          ADDA.L  SOV,A0         ;ADD BASE ADR 
003122  4EB8 2220       274          JSR     FPMUL 
003126  4ED4            275          JMP     (A4) 
                        276 ; 
                        277 ; DIVIDE THE FPACC INTO THE VARIABLE AND RETURN 
                        278 ; THE RESULT TO FPACC, LEAVING VARIABLE UNCHANGED. 
                        279 ; 
003128  326C            280          DC.W    EVAR1          ;EDIT LINK 
00312A  3246            281          DC.W    LDIV           ;LIST LINK 
00312C  3226            282          DC.W    ADD2           ;LINE LINK 
00312E  305E            283 DIV      MOVE.W  (A6)+,A0       ;FETCH VAR OFFSET 
003130  D1F8 1A0A       284          ADDA.L  SOV,A0         ;ADD BASE ADR 
003134  4EB8 22FA       285          JSR     FPDIV 
003138  4ED4            286          JMP     (A4) 
                        287 ; 
00313A  326E            288          DC.W    ENULL          ;EDIT LINK 
00313C  3264            289          DC.W    LINT           ;LIST LINK 
00313E  3228            290          DC.W    ADD0           ;LINE LINK 
003140  4EB8 32A6       291 INT      JSR     SUBINT         ;TAKE THE INTEGER 
003144  4ED4            292          JMP     (A4)           ;RETURN TO HALGOL 
                        293 ; 
003146  326E            294          DC.W    ENULL          ;EDIT LINK 
003148  3266            295          DC.W    LFRAC          ;LIST LINK 
00314A  3228            296          DC.W    ADD0           ;LINE LINK 
00314C  4EB8 27F4       297 FRAC     JSR     FRACTN         ;TAKE THE FRACTION 
003150  4ED4            298          JMP     (A4)           ;RETURN TO HALGOL 
                        299 ; 
                        300 
                        301 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        302 ; 
003152  326E            303          DC.W    ENULL          ;EDIT LINK 
003154  3248            304          DC.W    LLOG2          ;LIST LINK 
003156  3228            305          DC.W    ADD0           ;LINE LINK 
003158  4EB8 2618       306 LOG2     JSR     SLOG2          ;LOG BASE 2 
00315C  4ED4            307          JMP     (A4) 
                        308 ; 
00315E  326E            309          DC.W    ENULL          ;EDIT LINK 
003160  324A            310          DC.W    LLOG           ;LIST LINK 
003162  3228            311          DC.W    ADD0           ;LINE LINK 
003164  4EB8 2612       312 LN       JSR     SLN            ;LOG BASE 3 
003168  4ED4            313          JMP     (A4) 
                        314 ; 
   @ 00003164           315 LOG      EQU     LN             ;DEFAULT BASE E 
                        316 ; 
00316A  326E            317          DC.W    ENULL          ;EDIT LINK 
00316C  324C            318          DC.W    LLOG10         ;LIST LINK 
00316E  3228            319          DC.W    ADD0           ;LINE LINK 
003170  4EB8 260A       320 LOG10    JSR     SLOG10         ;LOG BASE 10 
003174  4ED4            321          JMP     (A4) 
                        322 ; 
003176  326E            323          DC.W    ENULL          ;EDIT LINK 
003178  324E            324          DC.W    LEXP2          ;LIST LINK 
00317A  3228            325          DC.W    ADD0           ;LINE LINK 
00317C  4EB8 2A32       326 EXP2     JSR     XP2            ;EXP BASE 2 
003180  4ED4            327          JMP     (A4) 
                        328 ; 
003182  326E            329          DC.W    ENULL          ;EDIT LINK 
003184  3250            330          DC.W    LEXPE          ;LIST LINK 
003186  3228            331          DC.W    ADD0           ;LINE LINK 
003188  4EB8 2A2A       332 EXPE     JSR     XPE            ;EXP BASE E 
00318C  4ED4            333          JMP     (A4) 
                        334 ; 
   @ 00003188           335 EXP      EQU     EXPE           ;DEFAULT BASE E 
                        336 ; 
00318E  326E            337          DC.W    ENULL          ;EDIT LINK 
003190  3252            338          DC.W    LEXP10         ;LIST LINK 
003192  3228            339          DC.W    ADD0           ;LINE LINK 
003194  4EB8 2A20       340 EXP10    JSR     XP10           ;EXP BASE 10 
003198  4ED4            341          JMP     (A4) 
                        342 ; 
                        343 
                        344 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        345 ; 
00319A  326E            346          DC.W    ENULL          ;EDIT LINK 
00319C  3254            347          DC.W    LSQR           ;LIST LINK 
00319E  3228            348          DC.W    ADD0           ;LINE LINK 
0031A0  4EB8 286C       349 SQR      JSR     SSQR           ;SQUARE ROOT 
0031A4  4ED4            350          JMP     (A4) 
                        351 ; 
0031A6  326E            352          DC.W    ENULL          ;EDIT LINK 
0031A8  3256            353          DC.W    LSINE          ;LIST LINK 
0031AA  3228            354          DC.W    ADD0           ;LINE LINK 
0031AC  4EB8 278C       355 SINE     JSR     SSIN           ;SINE 
0031B0  4ED4            356          JMP     (A4) 
                        357 ; 
0031B2  326E            358          DC.W    ENULL          ;EDIT LINK 
0031B4  3258            359          DC.W    LCOSIN         ;LIST LINK 
0031B6  3228            360          DC.W    ADD0           ;LINE LINK 
0031B8  4EB8 277E       361 COSINE   JSR     SCOS           ;COSINE 
0031BC  4ED4            362          JMP     (A4) 
                        363 ; 
0031BE  326E            364          DC.W    ENULL          ;EDIT LINK 
0031C0  325A            365          DC.W    LTAN           ;LIST LINK 
0031C2  3228            366          DC.W    ADD0           ;LINE LINK 
0031C4  4EB8 28FC       367 TAN      JSR     STAN           ;TANGENT 
0031C8  4ED4            368          JMP     (A4) 
                        369 ; 
0031CA  326E            370          DC.W    ENULL          ;EDIT LINK 
0031CC  325C            371          DC.W    LARCSI         ;LIST LINK 
0031CE  3228            372          DC.W    ADD0           ;LINE LINK 
0031D0  4EB8 1000       373 ARCSIN   JSR     ASIN           ;ARC SINE 
0031D4  4ED4            374          JMP     (A4) 
                        375 ; 
0031D6  326E            376          DC.W    ENULL          ;EDIT LINK 
0031D8  325E            377          DC.W    LARCCO         ;LIST LINK 
0031DA  3228            378          DC.W    ADD0           ;LINE LINK 
0031DC  4EB8 1000       379 ARCCOS   JSR     ACOS           ;ARC COSINE 
0031E0  4ED4            380          JMP     (A4) 
                        381 ; 
0031E2  326E            382          DC.W    ENULL          ;EDIT LINK 
0031E4  3260            383          DC.W    LARCTA         ;LIST LINK 
0031E6  3228            384          DC.W    ADD0           ;LINE LINK 
0031E8  4EB8 2B7E       385 ARCTAN   JSR     ATAN           ;ARC TANGENT 
0031EC  4ED4            386          JMP     (A4) 
                        387 
                        388 ; COPYRIGHT 1982 DIGITAL ACOUSTICS, INC. 
                        389 ; 
                        390 ; SUBROUTINE; FIND THE ADDRESS OF A LINE NUMBER 
                        391 ; 
                        392 ; ENTRANCE 0:  MOVE HALGOL START ADR TO A6 
                        393 ;              LINE # DESIRED IS IN D6 
                        394 ;              SET D7 = LINE 0 
                        395 ; 
                        396 ; ENTRANCE 1:  CURR LINE ADDR IN A6 
                        397 ;              CURR LINE # IN D7 
                        398 ; 
                        399 ; EXIT WITH ADDR OF LINE # (D6) IN A6 
                        400 ; ( 0 = END BEFORE LINE # FOUND ) 
                        401 ; 
0031EE  2C7C 00003274   402 FLIN0    MOVE.L  #START,A6      ;A6 = HALGOL START 
0031F4  4247            403          CLR.W   D7             ;SET LINE #0 
                        404 ; 
0031F6  3F0C            405 FLIN1    MOVE.W  A4,-(A7)       ;SAVE A4 CONTENTS 
0031F8  387C 31FC       406          MOVE.W  #HLINE,A4      ;POINT A4 TO HLINE 
                        407 ; 
0031FC  5247            408 HLINE    ADDQ.W  #1,D7          ;INCR CURR LINE # 
0031FE  BE46            409          CMP.W   D6,D7          ;SAME LINE #S ? 
003200  67 12           410          BEQ     LMATCH         ;DONE IF SAME 
                        411 ; 
003202  3A5E            412          MOVE.W  (A6)+,A5       ;NX HALGOL PROC'DR 
003204  BAFC 30E8       413          CMPA.W  #END,A5        ;END OF PROG? 
003208  67 06           414          BEQ     HEND           ;SKIP IF END 
                        415 ; 
00320A  554D            416          SUBQ.W  #2,A5          ;PTR TO LINE LINK 
00320C  3A55            417          MOVE.W  (A5),A5        ;LINE LINK FN ADR 
00320E  4ED5            418          JMP     (A5)           ;FIND NEXT LINE 
                        419 ; 
003210  3C7C 0000       420 HEND     MOVE.W  #0,A6          ;LINE NOT FOUND 
003214  385F            421 LMATCH   MOVE.W  (A7)+,A4       ;RESTORE A4 
003216  4E75            422          RTS 
                        423 ; 
                        424 ; FIND NEXT LINE FOR A VARIABLE FIELD SIZE FUNCTION 
                        425 ; 
003218  4280            426 ADDN     CLR.L   D0 
00321A  301E            427          MOVE.W  (A6)+,D0       ;SIZE OF PARM FIELD 
00321C  DDC0            428          ADD.L   D0,A6          ;PT TO NX LINE 
00321E  4ED4            429          JMP     (A4)           ;FIND NEXT LINE 
                        430 ; 
                        431 ; FIND NEXT LINE FOR A FIXED FIELD SIZE FUNCTION 
                        432 ; 
003220  548E            433 ADD8     ADDQ.L  #2,A6 
003222  548E            434 ADD6     ADDQ.L  #2,A6 
003224  548E            435 ADD4     ADDQ.L  #2,A6 
003226  548E            436 ADD2     ADDQ.L  #2,A6 
003228  4ED4            437 ADD0     JMP     (A4)           ;FIND NEXT LINE 
                        438 ; 
                        439 ; 
   # 00000122           440 IDLE     EQU     $000122 
                        441 ; 
   # 00001902           442 S1       EQU     $001902 
   # 00001A02           443 ERRPTR   EQU     $001A02 
   # 00001A06           444 SOH      EQU     $001A06 
   # 00001A0A           445 SOV      EQU     $001A0A 
                        446 ; 
   # 00001000           447 ASIN     EQU     $001000 
   # 00001000           448 ACOS     EQU     $001000 
   # 00002220           449 FPMUL    EQU     $002220 
   # 000022FA           450 FPDIV    EQU     $0022FA 
   # 000023A8           451 FPADD    EQU     $0023A8 
   # 000023B0           452 FPSUB    EQU     $0023B0 
   # 0000260A           453 SLOG10   EQU     $00260A 
   # 00002612           454 SLN      EQU     $002612 
   # 00002618           455 SLOG2    EQU     $002618 
   # 0000277E           456 SCOS     EQU     $00277E 
   # 0000278C           457 SSIN     EQU     $00278C 
   # 000027F4           458 FRACTN   EQU     $0027F4 
   # 0000286C           459 SSQR     EQU     $00286C 
   # 000028FC           460 STAN     EQU     $0028FC 
   # 00002A20           461 XP10     EQU     $002A20 
   # 00002A2A           462 XPE      EQU     $002A2A 
   # 00002A32           463 XP2      EQU     $002A32 
   # 00002B7E           464 ATAN     EQU     $002B7E 
                        465 ; 
   # 0000322A           466 LLOAD    EQU     $00322A 
   # 0000322C           467 LLOADS   EQU     $00322C 
   # 0000322E           468 LSTORE   EQU     $00322E 
   # 00003230           469 LTOTAL   EQU     $003230 
   # 00003232           470 LMOVE    EQU     $003232 
   # 00003234           471 LSWAP    EQU     $003234 
   # 00003236           472 LZERO    EQU     $003236 
   # 00003238           473 LGOTO    EQU     $003238 
   # 0000323A           474 LGOSUB   EQU     $00323A 
   # 0000323C           475 LRETURN  EQU     $00323C 
   # 0000323E           476 LOEGOT   EQU     $00323E 
   # 00003240           477 LADD     EQU     $003240 
   # 00003242           478 LSUB     EQU     $003242 
   # 00003244           479 LMULT    EQU     $003244 
   # 00003246           480 LDIV     EQU     $003246 
   # 00003248           481 LLOG2    EQU     $003248 
   # 0000324A           482 LLOG     EQU     $00324A 
   # 0000324C           483 LLOG10   EQU     $00324C 
   # 0000324E           484 LEXP2    EQU     $00324E 
   # 00003250           485 LEXPE    EQU     $003250 
   # 00003252           486 LEXP10   EQU     $003252 
   # 00003254           487 LSQR     EQU     $003254 
   # 00003256           488 LSINE    EQU     $003256 
   # 00003258           489 LCOSIN   EQU     $003258 
   # 0000325A           490 LTAN     EQU     $00325A 
   # 0000325C           491 LARCSI   EQU     $00325C 
   # 0000325E           492 LARCCO   EQU     $00325E 
   # 00003260           493 LARCTA   EQU     $003260 
   # 00003264           494 LINT     EQU     $003264 
   # 00003266           495 LFRAC    EQU     $003266 
   # 00003268           496 EGOTO    EQU     $003268 
   # 0000326A           497 EVAR2    EQU     $00326A 
   # 0000326C           498 EVAR1    EQU     $00326C 
   # 0000326E           499 ENULL    EQU     $00326E 
   # 00003270           500 TRACFN   EQU     $003270 
   # 00003272           501 DERR     EQU     $003272 
   # 00003274           502 START    EQU     $003274 
   # 000032A6           503 SUBINT   EQU     $0032A6 
                        504 ; 
   # 0000346A           505 OUTCHR   EQU     $00346A 
                        506 ;