DTACK GROUNDED, The Journal of Simple 68000 Systems
Issue # 17 February-March 1983 Copyright Digital Acoustics, Inc.
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)
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:
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.)
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?
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.
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.
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:
HOW, YOU MAY ASK, is it POSSIBLE to get your numbers so fouled up? It's like this:
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?
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:
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!
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?
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.
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!!
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.
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?
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.
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.
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.)
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?
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.
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'.
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.
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.
(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 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.
#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?
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?
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.
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.
#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?
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?
#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!
(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.)
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.
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 four pages you will find the operating instructions for a (public domain) 68000 monitor with single stepping and a disassembler(!).
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.
**---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.
**---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.
**---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.
969 Via Del Monte
Palos Verdes Estates
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!)
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.
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?
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.
"...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!
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).
(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.
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.
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.
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...
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.
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.
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.
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
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:
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.
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 ;