DTACK GROUNDED, The Journal of Simple 68000/16081 Systems
Issue #33 - July 1984 - Copyright Digital Acoustics, Inc
Yep. Illustrated below is one of the first 25 cases (of an order for 100). Genuine stainless steel. But what do we call it? "The case" seems, well, inadequate. Suggestions?
We should have the other 75 cases by the time you read this, and line filters a week after that. Because we don't have the line filters (except a couple of samples) yet, we cannot truthfully say that we have complete cases-cum-power supplies yet. You want the empty case? We got one - right now!
You want an empty case, send us $60 and we will send you the disassembled case with the plastic coating still (mostly) in place. We will add the hardware needed to mount a DTACK board and to bolt the case together and pay for shipping via UPS anywhere in the U.S. If you are the original purchaser of an Apple DTACK board s/n 10-49, static RAM variety, do not send us money. You will soon receive an offer of a free (in
the U.S.) case, or a future set of HALGOL source code (release 3) if you have already solved the case problem.
If you want a case with power supply, line filter and line cord, we will pull the plastic coating off and bolt and wire things together. You will still have to mount the DTACK board yourself and then bolt the front half of the case back on. The power supply is a heavy-duty 10 A switcher made by Lambda. We rate it at 7 A while running DTACK boards and such although there is no question that it will push 10 A into a resistive load. That power supply sets us back a hefty piece of change, so we have to charge $225 for this version. Pay the full amount in advance and we pay shipping costs via UPS anywhere in the U.S. If you are the original purchaser of an Apple DTACK board s/n 1 to 9, static RAM variety, do not send us money. You will soon receive an offer of a free (in the U.S.) case-cum-power supply. Our offer(s) will be extended to original purchasers ONLY; repurchasers need not apply.
If you do not live in the U.S., you will have to pay customs and air freight charges collect.
We are going to assemble and box for shipment the two versions, empty and fully loaded, by the dozens (literally). Do not ask for a third version, because we are not going to stop and put together a custom package just for you. Better you should go to McDonalds and ask for a Big Mac on a nonstandard bun etc. Why McDonalds? They will tell you to er, get lost POLITELY. We aren't polite about it.
INSIDE: The first of a two-part writeup of the WEITEK floating point math chips (p.19).
REAL, GENUINE (HONEST!) PRODUCTION DTACK CASE
We would love to be able to give you a report containing nothing but definite facts. We can't do that. So what we ARE going to do is lay out the facts as we understand them and add a little outrageous tea-leaf reading. Outrageous because the opinions we are going to present are not in accordance with the assertions of two major American semiconductor manufacturing firms. The reader is urged to consider the facts and form his/her own opinion.
The fundamental speed limitation of NMOS is the ability of the individual transistors to charge and discharge the capacitance, mostly the parasitic capacitance, of the device. If more current is available, the device runs faster - and hotter. As it happens, it is very easy to control the average current drawn by the individual transistors. One simply chooses bulk silicon with a lower resistivity (as measured in ohm-centimeters). No other significant changes in the process are needed.
Less easy is the problem of getting rid of the extra heat drawn by that extra current. The ability to operate such a special, high-power device under laboratory conditions where (for instance) a fan can be (literally) used just to cool that particular device is fine for research purposes but not so fine for production purposes. How many of you remember that early production 5MHz 8087 math chips ran VERY hot?
We believe that Nat Semi 16081s which run at 10MHz under lab conditions almost certainly exist (in very small numbers). However, we can see no evidence that 10MHz 16081s which are suitable for production exist.
Increasing the power is the only QUICK speed fix. All other methods take an appreciable time to implement.
Another obvious way to speed a device up is to shrink the mask. This takes time, requires highly skilled persons who are in short supply, and does no good unless the vendor has appropriate production equipment available. (By 'available' we mean that the company has to both HAVE the equipment AND have a time slot open for the use of the equipment.) The equipment problem can be cured with $$$ and the time problem can be solved by expending the requisite number of months.
The really intransigent part of the equation is the very serious shortage of skilled persons to produce the mask(s). This shortage is universal, not just a problem in one company.
YOU get to design the cooling system, naturally.
The reason Motorola does not have first silicon on its 68881 math chip today is that the skilled persons who would have done the mask for that chip have consistently been assigned elsewhere. Recently those persons have been working on the 68020 - and they still are. This also explains why Motorola has not shrunk the 3.5 micron design-rule mask it uses for the 68000. (3.5 microns was near the state of the art when the 68000 saw first silicon but is considered standard, even low-tech, today.)
Why does a shrunk mask make a part run faster? Simple. The smaller something is, the less capacity is associated with it. So, for a given power dissipation (which is largely package-limited), a smaller chip will run faster. If Motorola shrunk the 3.5 micron 68000 mask to 2 microns then 20MHz 68000s would become commonly available. Everybody in the chip business understands this, including Motorola.
YOU go tell Motorola management that it should shut down development of the 68020 for a few months to free up the skilled workers needed to produce the reduced 68000 mask! (See what the problem is?)
Can you make a part go faster without increasing the power dissipation or shrinking the mask? Yes, but the two easiest and simplest methods just got tossed out - you will remember that, hmmm? The design team - that's the mask boys again - can fine-tune the critical path elements. That is just a different form of mask change (if one that is simpler). Finally - and this is all that is left - the production team can concentrate on what we call "calibrating the cookie cutter". Perfectly produced parts will run faster than parts whose successive production stages are not perfectly aligned or are otherwise inconsistent.
We implicitly toss out draconian steps such as using gallium arsenide or sapphire substrates since those steps essentially entail a totally new design. Unless you know something we don't, we have now exhausted the possible methods of making a faster NMOS chip.
We refer not to the several laboratory samples which Nat Semi undoubtedly has but the production-compatible varieties which Nat Semi talks about a lot but doesn't ship. (It should not surprise you to learn that we have a lot of contacts at a lot of companies which manufacture 68000-based computers. It should not surprise you that Nat Semi has promised a lot of those folks 10MHz 16081s. And it should not surprise you that none, repeat none, of those folks have received such a part.) According to our calculations, 10MHz is nearly double the speed of the 6MHz parts which Nat Semi is actually making and which you can actually purchase in moderate quantities.
Since Nat Semi has to make the NMOS 16081 run faster, and since we have just discussed all the possible ways to speed up an NMOS chip, let us discuss which of the avenues available will be selected by Nat Semi:
A) INCREASE THE POWER: Wrong. Since this is the simplest and easiest way to speed up a chip, Nat Semi long ago increased the power as much as possible for a production chip. (Put your fingers on one while it is running - briefly! - to prove it.)
B) SHRINK THE MASK: This is the obvious method. Remember, all we need is time, money, and skilled folks who do not have anything else to do.
C) IMPROVE THE PRODUCTION PROCESS: Or fine-tune the mask, which uses skilled folk in smaller numbers. This is the most agonizing and least certain method available.
The method Nat Semi has chosen is (tadaa!), er, method C? REALLY? if the folks at Nat Semi can be believed (more on this later) they are dedicated to improving the production process to get from 6MHz (where they are) to 10MHz (where they want to be). Now, look: Nat Semi is in the business and we are not. But if we wanted to nearly double the speed of a complex microprocessor we would want to use a more certain method than just fine-tuning the production process.
All right, Nat Semi IS in the business and we are NOT in the business. So let's follow the lead of the folks who supposedly know what they are doing. Suppose fine-tuning the process begins to show results, meaning the parts start running faster than 6MHz. What is the first thing you notice? Why, you start seeing significant quantities of 8MHz parts! And before you start seeing any appreciable numbers of 10MHz product, you will see 8MHz parts in production quantities!
8MHz is a standard number in this industry. The nominal clock rate of the 68000 and the 80186 and the 80286 and the 68008 and... well, we are saying that 8MHz is a VERY common operating frequency. So what do we notice about the dog in the night? Why, we notice that it does not bark! (Right, JSK?)
Nat Semi, having announced that it is going to get from 6MHz to 10MHz by fine-tuning the production process, has sealed its lips completely with regard to any 8MHz parts! Gentlepersons, this state of affairs is illogical!
We are reminded of learning 2 1/2 years ago that the Intel 432, which Intel had proclaimed would solve the coming 'programmer crisis', would in fact require an INITIAL PROGRAMMING EFFORT OF 20 PERSON-YEARS! (See issue #6 p.5) Those two assertions by Intel were so starkly contradictory that we were motivated to investigate the 432 more closely and discovered (and printed in advance of any other publication) that the 432 was a disaster. What we are seeing here from Nat Semi is a contradiction of exactly that magnitude!
If we assume that Nat Semi is not going to require every board with a 16081 to have a freon cooling system, then we are faced with three possibilities:
Well, we TOLD you we were going to read tea leaves, yes? We have tried to explain the available choices and the problems associated with each choice. First, can you see any avenue open to Nat Semi which we have not discussed? If not, then which of the three options outlined above is Nat Semi taking? They would have you believe they are taking option 2 - and we flatly do not believe that!
We believe that Nat Semi is either taking option 1 or 3 - and we lean toward option 3. Well, you already knew that we are somewhat cynical about this industry.
(Some of the same folk who have been promised 10MHz 16081s have ALSO been promised sample 68881s by the end of this year! Honest! What is our opinion of that promise? The inhabitants of Hades are more likely to be afflicted by frostbite, that's what we think!)
We wrote the two preceding pages on the (early) morning of May 23. We went to lunch that day with Mario P., who is a member of the IEEE 854 radix-free arithmetic working committee. He also works for one of the two leading U.S. mainframe companies (he rides a motorcycle - guess WHICH of the two leading companies?). His job involves making performance evaluations and passing recommendations to higher management.
While we having lunch, the subject of the availability of announced products, especially math chips, was discussed. He pointed out that Intel had assured him that 8MHz 8087s existed but that he had not seen one. Later that afternoon Mario called us and reported that an actual 8MHz 8087 had just walked in the door but that the Intel sales type was already insisting that he give it back! (Give it back the next morning?)
What does that tell us about the actual availability of the 8MHz 8087? Considering Mario's employer and the nature of his job and even his membership on the 854 working committee you would have to assume that he would be near the very top of the list to get a working 8MHz 8087. But the Intel guy wanted the sample back almost immediately...
Yes, folks, the 8MHz 8087 'exists'. No, YOU cannot get one. Neither can we. What we are really trying to explain is that the fact that a part EXISTS is not always very helpful. We consider that a part 'exists' when you can buy one (even a sample) across a distributer's counter. By our practical working definition, 5MHz 8087s and 6 MHz 16081s exist but 8MHz 8087s amd 10MHz 16081s do NOT exist.
(Oh, yes: the Intel salesman brought with him the schematic showing the additional circuitry which is needed to make the 8087 work with the 80186.)
As we reported earlier, Nat Semi has finally agreed that we were correct 8 or 9 months ago when we asserted that the 16081 is in fact a synchronous part, not asynchronous. (Try reporting that last fact over the phone: 'the 16081 is in fact a [long pause] synchronous part, not asynchronous!") However, they have not finished re-characterizing it, so the 68000/16081 application note they are now advertising does not yet exist in a finished form.
However, they DEFINITELY DO NOT LIKE certain of the timing parameters they have measured on the existing version of the chip, and plan to make changes in the next mask to correct (change) the timing. The change should not be major and it should be possible to design a circuit which will accommodate both current and future versions of the 16081. However, that cannot be guaranteed because we do not know exactly what changes will be made (we suspect Nat Semi doesn't know either as we type this on May 25).
We understand that a senior member of Nat Semi's technical marketing staff has been telling folks that we don't know a heck of a lot about the 68000/16081 combo (among other things). OF COURSE WE DON'T! We have not yet had an opportunity to read the completed version of Nat Semi's application note yet. HOW CAN WE LEARN IF WE CAN'T READ THE APP NOTE? The senior marketing staffer's initials are R.M. If you run into him, tell him Eloi said to say hello.
The application note that Nat Semi is preparing shows the 16081 coupled to the 68000 using the same clock speed - 10MHz. Until 10MHz 16081s are available for purchase (which might be a heck of a lot longer than any Nat Semi type will admit) it will be necessary to run a 6MHz 68000 coupled to a 6MHz 16081. We believe that OUR technique of running the 68000 at double the frequency of the 16081 is superior. Superior by a 2 - 1 ratio, we smugly assert.
Who knows? On that far distant day when 10MHz 16081s finally become available for purchase across the counter it might also be possible to purchase a (2 micron design rule) 20MHz 68000 at the same time and to CONTINUE using that superior 2 - 1 clock ratio!
Nat Semi will not wish to whisper even a tiny word about the arrangement we favor because their own system is limited to running the micro and the math chip at the same frequency. So our technique will provide superior performance to the Nat Semi system whenever the math chip is NOT being used, by that same 2 - 1 ratio. (The 16032 and 68000 have essentially the same performance if their clock frequencies are the same.)
The HALGOL Review board of directors have authorized Jeff H. to trademark HALGOL II, HALGOL World (good for $5M from Pat McGovern), CALL HALGOL, St. HALGOL... The only exception is HALGOL itself, which we got to first. They're working on that. @%*&#!... (See issue #27 p.1, the middle of column 2.)
When we wrote about INMOS investing in a foreign country to gain access to engineers who were not failed greengrocers, both of our British readers jumped on us, assuring us that INMOS' overseas investment was minimal.
AHEM! May 21 EN, p73. Headlines: U.K. Unit Hits Inmos for Investment in U.S. The "Unit" in question is a Parliamentary committee. It seems that of the total investment of $155.82 million, $105.36 million has been invested in Inmos' Colorado Springs facility and only $50.46 million at the companies' two U.K. facilities (Newport, South Wales and Bristol, England).
Gee. According to our calculations, Inmos has invested more than twice as much in its one U.S. facility than it has in both U.K. facilities combined. Thus, it appears that our original assertions were correct and the protestations of both of our U.K. readers were unfounded. Tsk. (It also appears that the foreign country where Inmos sought competent engineers was the U.S., something that we knew at the time but which we very tactfully concealed from both of our British readers.)
When we carefully explained to you, last month, how happy we were that Motorola had a second source for the 68000L12 in Japan we neglected to mention how UNHAPPY Convergent Technologies was and is because Intel does NOT have a second source for the 80186 in Tokyo. Or in Surinam or Madagascar or Guyana or...
The reason we bring this up is that when that busted tricycle ad (by AMD, not Intel) originally ran we did not understand that contemptuous remark about "Motorola having its second sources spread out from here to Tokyo". We STILL don't understand it. And, to underline the point, we are almost certain that Convergent Technologies does not understand it either.
Peter Norton (official Establishment spokesperson) writes (15 May p.20) about why 1-2-3 is so popular:
"You can argue with me until we're both hoarse and out of beer, but I have always thought that an incredibly large proportion of 1-2-3's success could be attributed to its speed.
"If you ask any 1-2-3 buff to summarize the program's most endearing feature, I'll bet the first word out of that person's mouth will be 'Fast.'
"Apparently Ashton-Tate agrees with me, because it's made Framework every bit as speedy as 1-2-3, if not more so."
That opinion sounds an awful lot like the one we have been expounding for the past 15 months, or ever since 1-2-3 was introduced. It's nice to know that the Establishment has endorsed our viewpoint. In the same issue we learn the latest news about that famed Universal Operating System - the one that is like 'kicking a dead whale along the beach'. Softech's new president Ben Goodwin asserts, on p6 of 15 May PC WEEK:
"If there's been an operating system war going on, then the p-system lost it." [italics added]
Softech has just run up the white flag and introduced an MS-DOS version of its p-System. You can now run a p-System application program without ever once kicking a dead whale! (Assuming the vendor has adapted that application program to the new MS-DOS environment.) Softech remains a bit petulant over its capitulation:
"Softech hopes it will be able to move programs written under the p-System onto the PCs of MS-DOS jingoists who don't want anything to do with 'foreign' operating systems (p.50)." MS-DOS jingoists?
Why, you may ask, does Softech have a new president? Why, because sales tailed off at the end of last year and the company lost a ton of money, that's why! Oh, yes: new 'p-System' prexy Goodwin admits that he does not personally use microcomputers. He was assigned to San Diego by the Massachusetts-based parent firm, which is mainframe-oriented.
We only see four successful operating systems in today's mass market: CP/M, DOS 3.3, MS-DOS and whatever the OS is called on the Commodore 64. (With an installed base of 100,000 Mackintosh does not rate with those other 4 systems, each of which has an installed base of over 1.5 million machines.)
CP/M became popular because it was there when no alternative was. DOS 3.3 and the C-64 OS rode to success on the coat-tails of two machines which offered outstanding value, not because they 'beat out' competing operating systems.
MS-DOS is the ONLY successful mass-market operating system which became a success by beating off two AVAILABLE contending systems - DRI's 16-bit CP/M and Softech's p-System. (To give you an idea of the utter finality of MS-DOS's victory, DRI's Concurrent CP/M has just been made MS-DOS compatible and renamed Concurrent PC-DOS!)
Isn't it odd that every time we examine a recent highly successful mass-market application program or operating system we learn that the winner is written in assembly language? And that the losers are written in a high-level language? Uh - you DID know that MS-DOS is written in assembly, didn't you?
John Dvorak thinks all those pundits who are predicting success for A T & T in the computer market are wrong. Huh? We wonder which publications John reads? We have yet to hear of ANYONE not employed by A T & T who thinks they can profitably sell computers in the short or medium term. Which is why we have not been saying much ourselves; why waste time here on stuff you can read anywhere? (Now you know why this rag sometimes appears immoderate.)
Everybody looks at the size of A T & T's war chest and says yes, eventually they can learn to make and sell computers. That's true. Eventually they could ALSO learn to make and sell women's bras, wheat combines, sewer pipe, encyclopedias, ...
The same issue contained the conclusion of that hilarious two-part reprint on the demise of the 99/4A. BUT: talk about not being able to see the forest for all the trees! The author was so close to T.I. and the personalities involved that he COMPLETELY OVERLOOKED the single most important cause of the 99/4A's demise! What cause? Don't tell us that everyone has forgotten Jack Trameil already!
Look, T.I. 'did in' Commodore in the digital watch business because T.I. was the source of the chips used in those watches and they sold the chips to Jack for $9 and to themselves for $1. Jack never forgot that, and Jack holds a grudge REAL GOOD! When T.I. decided to go to the mat with the VIC-20 Jack was the low-cost producer and he took a $700 million chuck of meat out of T.I.'s fanny! (Shylock was a piker!) T.I. is STILL hurting! So how in the world can somebody write a story about the demise of the 99/4A without once mentioning Jack Trameil or the fact that he had the 99/4A centered in the cross-hairs of his sniper scope all the way?
(This is excerpted from a short article in TPUG (Toronto Pet User's Group) by David Williams. The title above is David's.)
"In the past two or three years, I have taught several courses in microcomputer programming. ...My approach
to teaching these courses was initially to accept conventional wisdom and to try to train the students, from the outset, to write elegantly structured, neatly flowcharted, heavily commented, beautifully typed programs. After all, so the theory goes, habits which are acquired early will become second nature to the students, standing them in good stead when they find themselves having to write or maintain complex programs in a business environment.
"Experience has made of me a sceptic. Nowadays, I find myself thinking more of analogies such as learning to walk before one can run. Teaching concepts such as program structuring to complete novices is a bit like talking about continental drift to someone who has no awareness of the world beyond the limits of his own home town! The students may be willing, even eager, to learn but, without some experience in handling simple computer operations, there is no way for them to grasp the broader concepts of program organization.
"To impose the rigours of structured programming, especially in a language such as BASIC which permits a looser style, is a wonderfully effective way of "turning off" beginning students. The way in which most of us "old timers" learned to program was to experiment and to learn from our mistakes. Usually, within a few hours of starting, we had succeeded in writing programs which worked, and we experienced the excitement and sense of achievement which this engenders. We were fortunate. No teacher ripped our efforts to shreds because we used multiple statements on each line, jumped all over the place with GOTOs, and didn't put in any REMs, I have heard many a student ask in bewilderment why his program, which worked, was given a lower mark than another which, though prettily set out, failed to do what it was supposed to do. My sympathies are with those students. In the rarefied atmosphere of academe, it is easy to loose sight of the fact that the primary purpose of any computer program is to work. Everything else is secondary.
"Of course I am not claiming that carefully-planned program organization is worthless. All of us who have written programs of substantial complexity know that it is extremely valuable. But its value is not apparent to a novice programmer whose simple routines can easily be written without much forethought. When he has become ambitious, when he has managed to get himself into a horrible mess because the logic of some complex program has become utterly incomprehensible, then will be the time for him to appreciate the advantages of flowcharts, structuring and documentation. Then he will realize the need for them, and will not feel them to be ludicrous impositions by a hide-bound teacher. Then will be the time for him to learn about them, not before.
"...Maybe, by moving away from structured programming and elegant typing, I am encouraging my students to write messy programs. But at least they ARE writing programs, programs which work and which provide them with the positive feedback which comes of achievement. This, to me, it the most important thing which can come out of a programming course."
[We fully endorse the foregoing except that some beginning programmers are "her"! Maybe women's lib hasn't arrived in Canada?]
"While enjoying your latest diatribe (issue #31) I came across a paragraph which appears to be a vicious and personal insult directed towards my person. As I cannot see what I could have done to incur your wrath (after all, my only contact with you has been to send you money)...
"...You will notice that the original press release by Dobkin (et al) refers to the BD-1 as a TO-3 package with the leads cut off, not a screwdriver as you reported. My reply was (I thought) quite clearly a tongue-in-cheek reply to this item in which I pointed out that a screwdriver would suffice for the application. I might point out that the press release was authored by several people at National including my friends Jim Williams (now at Linear Technology) and Lenny Sherman and it is often my custom to write a reply to their April 1st efforts... I have also enclosed a picture of my BD-1 which Dobkin and Williams sent to me in response to my letter!
"I must admit I was rather pleased that the editors of EDN did print my reply to the BD-1 along with my 'full name, employer and city.' I like to think I have a well developed sense of humor (after all, I do subscribe to your rag) and I am sorry my letter to EDN was a bit too subtle for you. However, I would hope that now that you have had a chance to re-read the offending material you might just admit you could have been (gasp) wrong!" David Abrams, Somerville MA
David, We had just opened your letter, realized the subject matter, and had turned to your letter to EDN (which begins "I can only react with disgust to Robert Dobkin's announcement...") when we received a phone call from Sam B., who until recently was the outside software editor for Computer Design magazine. We were laughing so hard we were having a hard time chatting with Sam!
To concur with your letter, we goofed and goofed big! Obviously, we remembered that 4-year-old stuff from EDN (5 Jun '80) but not correctly. Look at the good side: you may have saved us from switching career fields to
theology, at a fairly high administrative level. (We don't like administrative work anyhow.) Please accept our very sincere apologies! And don't tell anybody else how badly we goofed, please? - FNE
Oh, yes: Sam has decided to hang out his shingle as a free-lance technical writer. If any of you have seen his work in Computer Design and want to get in touch, we can pass along any note you want to send.
It is nice to report that somebody else made a mistake for a change. Terry P. has sent in a retraction of his earlier timing of the DeSmet C benchmark. His new timing is 1162 seconds, which "by golly, IS 19 minutes". The RMS error was 1.132091E-6, which indicates single imprecision.
About a year ago we made the mistake, of subscribing to the abovementioned publication. BIG mistake! Let us pass along just two sentences from the editorial in the Jul '84 issue:
"In surveying the responses we've received over the past few months, it's apparent that most readers are extremely happy with the GAZETTE." Extremely happy?
"Essentially, any product we review is, in our opinion, of merit." Translation: We are not about to upset one of our advertisers!
We mailed 549 copies of newsletter #32 on May 23rd. We thought you might like to know what folks, aside from the dumb Yankees, read this rag. Herewith are the foreign countries with more than one subscriber:
22 Canada 11 W. Germany 6 Australia 3 Saudi Arabia 2 England 2 New Zealand
All three of the Saudi Arabia subscribers have Anglic names and are ARAMCO employees. It is VERY interesting how few English readers we have (and yes, we DO know the difference between Britain and England; both of our British readers are English). When we have as many readers in one smallish town in Australia as in all of Britain, it lends a certain credence to our claim that the British would not recognize a high-performance microprocessor if one snuck up and bit them on the ankle.
You will recall that Analytical Engines, the outfit which makes the Saybrook II under-the-hood 68000 board, has been promising to make UNIX available for use with its product. They originally promised spring 1983 and then spring 1984 and damme if it is not SUMMER 1984 and time for A.E. to announce UNIX for the spring of 1985! And it appears that HALGOL, which was going to be a present for XMAS 1983 just might wind up in 1984's stocking... Who was it who once said software is sometimes late?
We suggested a couple of issues back that you might like to watch the financial progress of Wicat now that it had UNIX available for its 68000 machines. In case you don't read the Wall Street Journal, Wicat has forecast a loss of $13.4 million on sales of $23 million for its latest fiscal year. UNIX was not generally available from Wicat in its previous fiscal year so they only lost $4.1 million on sales of $25.3 million.
You are supposed to draw your own conclusions.
This one was overheard in a classy watering hole near the Sage manufacturing plant in Nevada: "You know, I really don't like UNIX but we make 68000 boxes and dammit, a lot of our customers are yelling that they want UNIX. We just might have to make UNIX available on the Sage yet!" Our informant asserts that the speaker closely resembled one Rod Coleman, Sage prexy.
Perhaps Rod could learn from from Wicat? What's that? Why, we mean learn how to implement UNIX on a 68000-based computer! Just what did you think we meant, dear reader?
Your FNE has been in the electronics business since before TTL was invented so it follows that we have lived (suffered?) through every TTL shortage. This time around, the shortage is not following the script. There is not yet (as we write this on May 29) any evidence whatever of a lessening of the shortage.
On the other hand, the widely predicted shakeout in the PC clone market has not yet taken place. IBM is still buying parts like crazy, including TTL, for the PCjr. Even though the balance sheet of a lot of those clone-makers looks terrible, they are being kept afloat for the time being by the venture capitalists (what we have here is an inefficient market).
We don't expect the TTL shortage to lessen until the venture capitalists cut their losses and IBM recognizes that the PCjr is history. It has been weeks since we have even seen a story about how jr isn't selling!
If you have any compassion in your heart, pray for those clones. Most of them are not long for this world. Because the real PC shortage is over and because the 'compatibility' problem has been so well publicized and because there is just so much counter space available in computer retail outlets. Mostly the latter.
Not long ago it made sense for a store to carry both the genuine IBM PC and the Compaq. After all, the Compaq is transportable and the PC isn't. But now IBM makes its own transportable (which, amusingly, has been called a 'Compaq clone'!) which it naturally wishes its dealers to sell. In fact, all of the market leaders have been busy broadening their product line. Right now the average computer dealer is hard pressed to carry four product lines; a fifth is out of the question. And PC magazine recently reviewed 40 clones! So what happens to the other 37 clones, hmmm? You know what happens. So light a candle and pause for one minute in remembrance.
And keep your gaze elevated so you will not notice all that corporate life's blood (red ink) spilled all over the place...
Before we decided to support the color monitor used by the Tandy 2000, we looked at a LOT of color monitors (including the Princeton line, Sam). One must read the spec sheet on one of these babies with great care. Almost all of them are just color TV type stuff with the TV receiver missing. That means 262 vertical lines non-interlaced or 525 vertical lines interlaced. (Some of those lines will not be displayed to improve the linearity.)
So when the spec sheet says non-interlaced, that is true... with appx 200 vertical lines. When the spec sheet says 400 vertical lines are available, this is true too... with an interlaced (30 Hz) display. Princeton has announced a new model with a faster horizontal scan rate for 400 lines non-interlaced but it costs the same as the Tandy monitor for which you can get service in your own home town if necessary.
Here is the bottom line: for 400V X 640H non-interlaced 60Hz display you need a 31.5 KHz horizontal scan rate and a 20-25 MHz [NOT 45 MHz as our hacker told you in the last issue] vertical amplifier bandwidth. The Tandy 2000 monitor, which is made by Mitsubishi in Japan, meets those specs.
"What a newsletter (#31). From the pornographic pictures on page 1 to the black humor of page 12 your rag gets more incredible with each issue. If you are really interested in a fast computer, stop playing with Eagles, Tandys, and the other toys. Put on a suit, wipe the Special Dark stains off, and proceed to the headquarters of Compupro. An introduction should get you ushered into Dr. Godbout's presence. After the ritual obeisance, an act that is due anyone who can run a 10MHz 68000 with no waits on a S-100 bus, ask Dr. Godbout to review his new bus-resident video board - the one that emulates the color and monochrome display of the PC. Examine the 256K static RAM boards (no touching now), the 20-slot motherboard, the boat-anchor power supply, etc. Now use your fingers and toes to count the number of memory slots available after the minimum cpu/controller configuration is installed. I guess better than 3 megabytes of 10MHz memory. Do not drool on the system, please. My mouth is watering already, and I don't have the cash to buy such a package. If you whisper the secret words (Jerry Pournelle sent me), Dr. Godbout might discuss adding 16081 math chip support to his 68000 cpu with you. Heh, heh, heh.
"...Enough whining for now. Taking you away from HALGOL could delay your purchase of a nice red Ferrari, tanker loads of Special Dark (too sweet for me), and thoughts of new hardware designs." MFC Nils D., Wethersfield CT
(The above note arrived just after we mailed #32, so Nils had not seen our own comments on Dr. Godbout etc.) Nils, John Dvorak asserts in the Infoworld which arrived in the same mail as your note that the S-100 bus is dead. So your first paragraph above is obsolete already. Please do not tell Dr. Godbout, O.K.?
One more thing: if we manage to make a (hard-earned and well-deserved, naturally) small piece of change out of DTACK, remember that it will not be the FIRST small piece of change we have made. Last time around we didn't buy a Ferrari or a boat or even a tanker loaded with Special Dark. What we bought was a largish speaker system to play our 300 or so classical lps on.
We have a semi-custom mural of the back yard of Isabelle d'Este's villa in Ferrari, Italy on one wall of our dining room. Isabelle was a contemporary of Cesare and Lucretia Borgia; they exchanged dinner invitations! Three years after we installed the mural we discovered that villa d'Este was occupied by Enzio Ferrari, maker of nice red Ferrari sports cars.
Pornographic pictures? The PLAYGIRL editor we are making a deal with doesn't seem to think so. - FNE
"I think you come down too hard on C. Any compiled language will be slower than machine language. Do you think that programs written in HALGOL will run as fast as HALGOL itself?
"...About the Tandy 2000 BASIC: The editor is not written in C. The 2000 uses BANK SWITCHING OF ITS GRAPHICS RAM and there is 96K of it to switch around. They probably bank switch because 96K doesn't fit in one segment. This makes it very slow to do text output in graphics mode. The PC is also slow during graphics mode output, but the PC isn't as bad because it only has 16K of graphics RAM to deal with and doesn't bank switch." John M., Canoga Park CA
John, HALGOL is designed for use as a problem-solving language. It is also designed to provide, for a problem-solving language, the benefits of both interactivity and compilation. HALGOL is definitely not intended for writing operating systems or other high level languages. C, on the other hand, is not interactive and is not (as far as we know) intended for use as a problem-solving language. We seem to be comparing squid with tungsten-filament light bulbs (HALGOL and C appear to be completely unrelated).
Thanks for the scoop on the Tandy 2000 and bank-switching. Did we ever tell you we do not like bank-switching? - FNE
"...Why don't you use the Motorola RMS two-chip graphics set instead of the 7220 for your medium resolution graphics board?" [name misplaced, darn it!]
At resolution comparable to the Tandy 2000's color monitor, the Motorola RMS chip set is down to only two colors, INTERLACED (horrors!). 'Nuff said? - FNE
"You may or may not have wondered about my success or failure in mating the DTACK to the Corvus Concept and using the floating point board. The interface from the Concept to the DTACK is very simple; I have enclosed for your amusement some subroutines that handle the Concept side of things. I intend to modify them so the DTACK board will appear as a peripheral to the operating system. The main task I have before me is to design a monitor that will allow me to allocate code
and data storage on the DTACK board in a rational manner, i.e., set up tables of entry point addresses the Concept can jump to when some particularly nasty number crunching is needed.
"I had some initial panic with the floating point board: all my results were garbage! My troubles were over when a 15 watt bulb glowed in my head: the 16081 is not byte backward but word backward! ...I am somewhat concerned about the operating temperature of the  chip; it is often too hot to touch.
"My real fear in all this is that IBM PCs and their clones will take over like Mongol hordes and set technology back at least five years. Maybe they already have. The only sunny spot is the wretched market response to the PCjr and the portable PC. ...GAWD, how I hate IBM!" John W., Austin TX
John, we hardly ever hear anything about the Corvus Concept. You say it is under $5000: does that include disk storage? Can you send us a timing of Terry Peterson's revised Dr. Dobb's benchmark run under Corvus BASIC? With and without the DTACK/16081? You should gain some insight as to why your math chip runs hot in the first few pages of this issue. Good luck with your project - FNE
"...I am distressed at how you write about me in your newsletter.
"You imply that I have somehow violated a non-disclosure agreement, or at least have been slippery. In fact, advance copies were sent to Mr. Coleman to be certain I was NOT in violation of the agreement." Jerry P., Studio City CA
(Jerry is referring to issue #32, p.15, the paragraph under the headline "ROD COLEMAN".) Jerry, immediately after writing that column we called Rod Coleman at Sage and discussed it. Thus, we knew that the 16081 stuff was hardly top secret since anyone who attended the Sage (show? festival?) could have seen prototype gear. And we confirmed that it was indeed Rod who called us earlier in the year and revealed that Sage was
'independently' working on a 68000/16081 interface. So we could not have intended to pick on you for revealing 'top secrets'.
You did indeed manage two separate allusions to the 68000 and hardware math support and you did it in such a way that only someone with special knowledge could have spotted the connection to Sage. Congratulations! Honest! We also thought it was humorous that we were one of the few with special knowledge who could connect those hints to Sage, and that was reflected in the way we wrote the paragraph in question.
But since you brought the subject up, we HAVE considered criticizing you for continuing to write incessantly about buggy whips, er, S-100 systems - FNE
"I heard rumors that Phase Zero was no longer shipping. Have you heard anything?" Mike E., Renton WA
Mike, they have sometimes been slow, especially in filling back orders. A couple of subscribers have written to us that their paid-for MINOS source code was 6 months overdue. When we forwarded their note, each received the MINOS source promptly. We have also heard from a couple of folks who were upset at not receiving their cross assembler. When we looked into it, it turned out they hadn't ordered it ("but I was SURE I had my secretary send a check!") - FNE
"I'm interested in getting FORTRAN 77 to use with the board when I get it. I have an Apple II+, and can use only Apple FORTRAN on it now. Any sources you could furnish for FORTRAN 77 would be greatly appreciated." Jeff D., Du Quoin IL
Jeff, Peter Seibert has adapted Apple FORTRAN, which runs under Apple PASCAL, to run on Ulrich Schmidt's Inter68. That's the only FORTRAN which now runs on our board(s), but it IS compatible with the FORTRAN you now have - FNE
"...I checked the voltage while a program was running. The crisp, authoritative LEDs indicated 5.00 at the power supply and 4.93 at the board. Unfortunately, over the years my NLS LM-3 digital voltmeter had become a bit senile and less than trustworthy. In fact, the voltage at the board was 4.43 VDC!" Alan K., Berkeley CA
Alan, we have had a whole rash of folks with power supply problems. Some of them think that if the voltage is within hailing distance of 5 volts everything is O.K. and some of them have added stuff (such as a math board) which wound up overloading their
power supply. All of them think (at first) that the problems are our fault.
What all of you want to do is get 5.0 VDC to the board. That usually means the voltage will be pretty close to 5.1VDC at the power supply. Check the voltage while the board is running a program, such as a memory test. It will save you having to ship a perfectly good set of boards back to us for repair, as Alan (and some others) have - FNE
"...143K will NOT be the norm in the near future. I've had a Rana III for some time, and it is going to be okay for ProDos. It stinks under DOS 3.3, as cataloging takes a week.
"RE: HALGOL: Please don't feel like Mother Martyr because all the suggestions that your FREE (to us) labor is not exactly what WE want. Most of us are almost as opinionated as FNE. Why else would we write? Could it be any different?
"Enclosed is a picture of daughters holding the original DTACK board w/power. A local hardware wizard put them together for me at a reasonable price. P.S.: I'm sure glad Bill Agee likes UNIX." S & M Software, Stanton MI
Sorry, we could not read your signature (candidate for understatement of year) and the company name was all we had on file. We're glad to see that you got your (11 year-old?) daughter a DTACK GROUNDED T-shirt. If you will refrain from accusing us of sexism, we can note that when your daughter is older we will be able to read the "G" and last "D" and also ask yes, but does Mary Cunningham? RE: HALGOL: for a while there we felt our craft ebbing (a fitting reply to an outfit named S & M, no?) - FNE
"Since like yourself, I wanted disk drives larger than 143K, I changed to RANA ELITE 3 drives and controller card. The RANA drives are fully supported by RANA who supplies enhancement patches for DOS 3.3 and (soon) ProDos. Faster seek time, faster track-to-track time, 653K per drive, 4 drives per controller plus the speed of a 68000 performing the data decoding [?]... Hope you'll try one so that you will stop bitching about those dinky old Apple drives." Robert L., York PA
What do you mean, 'speed of a 68000 performing the data decoding'? We haven't tried a RANA yet. Interestingly, we understand that Don Burtis, who designed the Apple-DTACK interface as our consultant, is now the president of RANA. Don is a hardware person who came up as an analog type chasing microvolts just like somebody else we know - FNE
"For some reason, people tend to look at the instruction set of the 16032 and say, 'HLLs should execute efficiently'. I look at it and say, 'Should be easier to write a compiler'. Definitely not the same." Nigel R., Torrance CA
Congratulations, Nigel! Most folks don't make that distinction - FNE
"...I have no interest in floating-point anything and didn't help IBM with their chip. IBM had to pay Intel to do the chip over because IBM floating point is not the same as IEEE floating point. I did, as a Motorola employee, go train the IBM people in Endicott to remicrocode the 68000 to do an IBM S/370 subset. (They wrote the microcode.)
"I already take Electronics, Electronic Design, and a few others - which I view as fancy titles for the National Enquirer. Your newsletter is the first I have seen that lines up well with my prejudices. I don't care about your product, floating-point, or applications. I do care about (perceived) microprocessor performance. Your remarks are the first I have seen that seem sensible. (Maybe it's just because you like the 68000.)
"Your 68000 chronology doesn't match my notes. (I kept a weekly diary of my activities on the project.) I show the preliminary specification dated 30 September 1977. It had the PC in the register file and the register file in memory. (On-chip, but with memory addresses - like the PDP/11?) The eight data registers were 16 bits and the eight address registers were 32 bits. Tom Gunter (project manager) made the suggestion to use all 32 bit registers on Saturday, 12 November 1977. On 10 April 1978 the PC was moved out of the register file. And during the week of 25 to 29 June 1979, the decrement branch on zero instruction was changed to include a condition code check. (It was DCNT and became DBcc.)" Nick T., San Jose CA
Nick, a lot of our readers seem to think that THIS is the National Denouncer. Stick around and you'll learn a lot - we're going to explain the 68000's two-level microcode any issue now - FNE
"The accompanying fiver proves that your fund-raising efforts have not been unsuccessful. I must insist, however, that my argument is still valid: although lines (C) and (D) (#32, p.23) represent erroneous results line (C) is 'slightly less erroneous' than (D).
"Please, do not keep your opinions on the RISC architectures a secret! I for one would like to know them. You appear to favor 'simple' over 'incredibly
complex', so I suppose that you are a RISC supporter. Just think of those several hundred registers! On the other hand, the 680X0 is definitely NOT a RISC." Ulrich S., Aachen W. Germany
Ulrich, we DO think of those 'several humdred (?) registers, but we otherwise favor CISCs. The fact that the 68020 has seen first silicon and no commercial RISC has is (ahem!) of some consequence.
We would like to get a contributed article on the RISC vs CISC question. The author should be familiar with the 68000 and have developed some knowledge of the RISC, perhaps by spending some time at Berkeley. Hmmm... where could we find such a person?
Thank you for the fiver; we will overlook your unseemly assertion that 32767/65536 of a least bit is "slightly" less than 32769/65536 of a least bit. After all, we were a bit reluctant to part with a fiver ourselves, as we recall - FNE
Whether it is a negotiating ploy (with Philips) or a real try, Atari has decided that it has to be IBM PC compatible. Commodore has tossed its hat into the PC-clone ring. A T & T is about to announce the first A T & T computers you can really buy. UNIX boxes? Nope, four badge-engineered Olivetti PC-clones. And two of the four clones are actually badge-engineered Corona Data Systems PC clones.
That leaves Apple as the only major player in the game that is a PC-clone holdout. And that makes us just a bit friendlier towards Apple Computer than we might otherwise be because they have had some pretty strange management practices and decisions over the years. (In the last issue we explained that Apple, which last year was ranting and railing against Apple discounters is now discounting Macks itself and in fact REWARDED those discounters by giving them the most Macks, initially when Macks were scarce.)
While Apple seems to be holding the line against the PC hordes, there is not a great deal of unanimity within Apple management as to the wisdom of its course. In fact there may be one man and one man only standing between you and us, dear reader, and those low-tech PC hordes. And you might not even like the guy.
Apple management: At the top is chairman Steve Jobs, who brags about making 300 people a millionaire. In the president's spot we have John Scully, who is the LAST person Jobs made a millionaire (John got a couple mil just to sign on board). In the next ten lower positions we have ten folk who have NOT been made millionaires by Jobs because they were hired by Scully.
That means that Jobs, while he has high visibility, is politically isolated by Scully and the numerous Scully yes-men just under Scully. This would not matter if Jobs and Scully had compatible goals and objectives, but they do NOT have compatible goals and objectives. In fact, John Scully wants Apple Computer to join the ranks of the PC-clones so badly that he can taste it. And what John wants, the Scully yes-men want.
Steve Jobs not only represents new money but BIG new money. And he made it and made it BIG while he was in his twenties. It should not be surprising that a lot of folks don't like Steve. Although most of us will not admit it, we resent persons who have been spectacularly more successful than ourselves. And yes, new money can sometimes be unbearable and BIG new money can sometimes be UTTERLY unbearable. And it should not surprise anyone that Steve has become just a tad arrogant. Very few of us like folks who are arrogant.
But absent Steve Jobs, Apple becomes the umpteenth PC-clone vendor. Scully has already tried to drag PC-compatibility in via the back door. One day when Steve's back was turned, Scully placed the official Apple seal of approval on Rana Corp's MS-DOS disk drive package for the Apple II. Scully almost succeeded in promoting an 8088-based PC compatible attached processor board to plug into one of LISA's four expansion slots. That project seems to have been derailed by Mack's flying start.
Oh, yes, Mack: Did Scully allow Jobs to win the fight to take over Mack because of a perception that Mack would crash and burn as LISA I did? And with Jobs discredited did Scully figure he would have no problems taking over and running Apple Computer HIS way? Remember, Scully made his mark peddling Pepsi, a soft drink which is virtually indistinguishable from its competitor, industry leader Coca-Cola.
Should Jobs succumb to accident or illness or should he be elected to the U.S. Senate, we will all be able to look around at the personal computer landscape and see nothing but IBM PCs and PC clones in any direction. If, like us, you find that thought unappealing, you might want to thank Steve Jobs. And even try to like the arrogant so-and-so just a little bit. You will also remember, if Steve runs for the U.S. Senate, to be sure that you and your friends vote AGAINST Steve. We need Steve right there in Cupertino, yes?
Isn't it a helluva note to discover that only one man stands between us and the PC-clone hordes? There may be thousands of anti-IBM employees in Apple's lower echelons, but they don't count. Top management counts.
That's why we have noticed publicly as Scully displaced the old-line Apple managers with Scully men.
Back in issue #25 we reported (with some outside help) about the conflict between the PC-DOS BIOS and the vectors which Intel had reserved. Now, it is true that we originally asserted that the problem was in MS-DOS, but at that time we naively believed that PC-DOS was just MS-DOS bought from IBM. The problem DOES exist and is beginning to bite a few folks on the ankles.
After John Dvorak reprinted our item in his column (thanks, John, that was great publicity!) reporters from three publications called us as part of attempts to do a more thorough story. Two of these reporters called back later reporting that they were getting totally conflicting stories, even 'nonsense', from other sources. One of them sadly told us that he had spent eight days trying to pin down 'the facts' and that he knew less about the matter than when he had started! None of the publications printed a follow-up.
Meanwhile, a journalist in England severely picked on us, assuring us that an unimpeachable source within Microsoft assured him that MS-DOS did NOT have the problem and that Microsoft (of course!) could NOT be held responsible for PC-DOS. We replied (in our newsletter) Cmon! Who do you think WROTE PC-DOS - the tooth fairy? The English journalist stuck to his version of the story and this has been a (small) bone of contention between us to this day.
AHEM! Integrated Circuits magazine, May/June 1984 p.48: "...Refer to table entitled 'Interrupt Vector Conflicts.' Microsoft did the PC-DOS (IBM) operating system for IBM, but claims that it was IBM's decision to allow the conflict with the 188/186 machines."
Microsoft wrote PC-DOS? GADZOOKS! What a surprise!
Please note the use of the word "allow" in the quotation above. Roll that word around your tongue for a moment and think about it. Contrast that word with others which were not used - "force" for instance.
Scenario: IBM's Prestridge is holding a loaded revolver to Bill Gate's head. "Bill, if you don't use those reserved vectors for PC-DOS, I'm going to pull this here trigger!" Hmmm... somehow that scenario does not play well. We wonder what our English colleague will have to say?
belong to the folks making 80186-based personal computers. You see, the microprocessors they use have hardware vectors which conflict with a number of BIOS calls for IBM's PC-DOS. If they expect to run programs written for PC-DOS, they do have a bit of a problem!
Last month we asserted that Adam's estimate of Lotus' 1-2-3 shipments was absurdly low and then we proved it. We also asserted that his estimate of PC shipments was too high, but not by nearly the same ratio... and then we left the proof as 'an exercise for the student'.
We weren't really copping out, we just wanted to give you a chance to try your luck. The ground rules are that IBM does not deliberately lie so we will give credence to their public announcements. That means we believe their assertion that they are going to triple PC shipments in 1984. We note that IBM does not address absolute numbers of shipments so next we look at the IBM watchers who have asserted that that 'tripling' translates into 2 to 3 million units in 1984, with a strong consensus grouped at 2.4 million. We will use that 2.4 million.
A large company does not shut down on the last day of 1983 and then begin the first work day of 1984 with triple the production. Large companies increase production gradually; although the process is not exactly an exponential curve it is something LIKE an exponential curve. Unless we know considerable detail about IBM's manufacturing operations the exponential curve is the only mathematical model available to us.
If we are going to triple production in a 12-month period, that can be accomplished by producing 1.095871 times as much in the next month as in each prior month. If we start with 115,044 units in Jan then we will produce 2.4 million units by the end of the year. The first quarter shipments work out to 379,280 units, or an average of 126,420 per month. Since there are 21.5 working days in an average month, that comes to 5,880 PCs per day as opposed to Adam's estimate of 10,000 per day. Adam's estimate was 70% too high, nearly double our calculation.
The figure above gives the first-order estimate of PC shipments. Consider that the 1-2-3 to PC ratio, which is the subject under discussion, should logically include the PC clones and the numbers go up a third. Consider that IBM's predicted tripling included 33% PCjrs - which are not selling up to plan - and you can back down a third, so we are back where we started.
Because it is going to be important to lots of folks, that's why! Adam perceives a (non-existent) shortfall in the sales of 1-2-3 and is busily investing his - and others' - money in a company he is starting to SOLVE that non-existent problem!
Remember that Adam started the Osborne Computer Company to get rich selling portable computers. Remember that the reason for the early success of Adam's company had nothing to do with the handle and everything to do with bundled software! Remember that when Osborne hired Jaunich away from Consolidated Foods in Chicago that Osborne (the company) was under the impression that it was profitable and doing well. When Jaunich arrived he was shocked to discover that the company was UNPROFITABLE and in terrible financial condition! (It should not surprise you that Adam cannot get his figures right - he has a track record, after all.)
Also remember that Adam championed tee-niny displays right up to the end, thus allowing the KayPro, with a MUCH larger screen, to steal Osborne's business.
NOW: Do you want to invest in a software house which is being started on a false premise (to solve a problem which does not exist)? Which will be run by a CEO who has a track record of getting his figures wrong?
This is fair play. Adam proved that he was good at this on the sending end; now we will find out how good he is on the receiving end. Er, one of you 550+ readers ARE going to send him a copy of this, yes?
Since most of you are Apple types who cannot run 1-2-3, let us update you on how that software package is doing in the IBM marketplace. So we turn to the back of Jun '84 Softalk and discover that 1-2-3 is (yawn) in first place and leading the second-place product by a margin of (yawn) 2.5 - 1. Softalk reports:
"Folks, it's time once again to marvel at the absolute domination of 1-2-3 in the IBM software market... 1-2-3 is so hot it makes a microwave oven seem like a boy scout campfire. 1-2-3 is so strong it could make a monkey out of King Kong. 1-2-3 generates enough cash to make Croesus weep with envy."
Gee. How can a program which is not correctly written in PASCAL or does not run under UNIX be so popular?
We hope to purchase 1-2-3 soon to run on our Tandy 2000 so that we can personally investigate this phenomenon.
Let's see now: if we will only study UNIX some more, we will understand how it is going to conquer the world, no lie, starting tomorrow (NOT yesterday). All right, so we turn to 31 May '84 Electronic Design p.140. We learn about hundreds of bugs. We learn that UNIX was written for a slow CPU with a fast disk. We learn that multi-tasking UNIX's inter-task communications "leave
much to be desired" and that 16 to 32 signal bits are associated with each task (!).
We learn that UNIX's file system ALSO leaves a great deal to be desired. "If a failure occurs after data is written to cache memory but before the i-node information is transferred to the disk, the newly written blocks become inaccessible." Hmmm.
We also learn that the economics of UNIX virtually force users to UNIX look-alikes rather than the real thing. Gosh. We somehow don't think this is what that other newsletter editor meant when he told us to study UNIX some more.
COMPUTERWORLD is a weekly which you do not ever want to read unless you work exclusively in a mainframe environment. 28 May '84 COMPUTERWORLD includes several articles on UNIX. A number of company spokespersons are quoted in those articles; all of them begin by ritually sacrificing a chicken or small goat before A T & T's Death Star logo and then pronouncing how wonderful UNIX is for software development and full-time computer professionals. Some examples:
Bruce Hunter, Interstate Electronics: "There really is no comparison between UNIX and conventional operating systems. Those systems can't begin to approach the versatility of UNIX. They don't have the literally hundreds of built-in programming tools that UNIX provides. It is an ideal system for people who are [oriented toward] programming or system management."
Charles Barnaby, Berkeley Solar Group: "As an environment for program development and text manipulation, UNIX is very powerful... UNIX is miraculous. It gives me access to programs designed specifically for developing code."
Lee Steinbrenner, ITT Courier: "The UNIX environment is state-of-the-art. If you have a lot of people doing [software] development tasks, UNIX is a wonderful tool to work together on."
When a fellow editor suggested that we would appreciate UNIX if we would only study it more, the above quotations are the sort of stuff he would have us study. But let us continue with more from those same stories, beginning with this ominous bridge sentence:
"UNIX is seen by some as the ideal environment for software development, but users are divided over its usefulness as a proper support for end-user applications." See how things went downhill after 'but'? Here is more:
Charles Barnaby (again): "UNIX is basically written for computer professionals and, to a large degree, it
is overhyped for the man on the street. Most heavily loaded UNIX systems are quite slow, and that makes them inappropriate for transaction-oriented applications."
Abraham Shenker, Intermetrics, Inc: "UNIX has been a fairly unstable system; it's changed a great deal in recent years. It hasn't been the stable environment that is really needed for application development... Efficiency is part of the reason [for UNIX's limited popularity]. UNIX will never be as good as a system that has contiguous files and better batch processing capabilities."
The above quotations are all from page 6. On page 9 COMPUTERWORLD condescends to look at the micro picture:
Ann Winblad, Open Systems Inc: "There hasn't been a significant UNIX system in the retail market." [Boy, are Tandy, Altos, IBM and Fortune going to take exception to that!]
Mark Ursino, Technology Services Corp.: "In the past four years, there have been 70,000 microcomputers with UNIX or a UNIX derivative sold. Apple shipped 70,000 Mackintoshes in four months." [And Commodore ships 70,000 C-64s in FOUR WORKING DAYS! Honest!]
Ann Winblad (again): "[UNIX could become] the most widely publicized yet seldom used operating system in history."
The above stuff is what that other editor ignores himself and obviously wishes US to ignore! It seems that our study of UNIX must be severely circumscribed if we are to learn how wonderful UNIX is...
The second issue of UNIX World is just out. The front editorial concludes that UNIX in today's form is not suitable for the mass marketplace. The back-page editorial openly wonders just how many of those look-alike UNIX box vendors are going to be around two years from now. In other words, a lot of other publications are beginning to support the views we have been expressing here for the past 17 months.)
Well, yes. But we have a legitimate reason to do this. Following is a reprint of the last paragraph on p.3 of our newsletter #24:
"The one arena in which an operating system can be written in a high-level language is the one where EVERY vendor agrees not to inconvenience his competitors by using high performance assembly. There is a real-world example: all those outfits making $35,000 UNIX systems, most of them based on the 680X0! The reason you have to spend $35,000 to get a really good-
performing single-user UNIX system is that UNIX is, in every case, written in C! Does anyone who reads this letter really believe that a truly high-performance personal computer could not be assembled today for about $6000 - $7000? Assuming available software written in assembly, that is."
The above paragraph is no longer true. Many companies have begun to re-write the UNIX kernel in assembly instead of C! There are two 680X0-based UNIX box makers in San Diego alone who are doing (or have done) that - BYTE and ALCYON. We believe that the substantial re-write of the FORTUNE operating system, the one which prompted them to drop the UNIX name, involved dumping C in favor of assembly.
is based on the speed of the hard disk, the efficiency of the memory management and (last of all) the efficiency of the CPU/operating system combination. Hardware memory management is an absolute necessity for reasonable performance; the absence of this feature is why the IBM PC and the SAGE fared so poorly in David Fiedler's benchmarks.
But given equal disk speed and equivalent hardware memory management, it will be the CPU/operating system which determine the competitive edge. As it happens, there are an awful lot of 10MHz 68010-based UNIX boxes out there with equivalent disks and memory management. (Many of them license the CPU board and memory management design from Sun Microsystems; it is no coincidence they are so alike!) All right, Tweedledum, how are you going to get a performance advantage to take to the marketplace? Oh? You are rewriting UNIX in assembly?
At this point we are certain that the die-hard HLL freaks amongst our readership are giggling that it is only the little guys who are re-writing UNIX in assembly. The big boys who know what they are doing would never commit such a heresy, right? To those persons we say:
Now that you are seated, we have big news for you: One of the little outfits which is currently re-writing UNIX in assembly is named AT & T! We are not kidding you even a little bit! It seems the Bellmac, er, WE32000 has proven uncompetitive with respect to 10MHz 68010s and so A T & T, the inventor of UNIX and the inventor of C, is re-writing UNIX (the kernel, not the 5Mb of utilities) in WE32000 assembly. The job is not yet completed and that is why you cannot buy their low-end 3B2 just yet. (PC magazine, 29 May '84 p.81)
WE JUST KNOW THAT many of our readers are going to mis-interpret us again. Folks, write all your non-mass-market applications programs in a high level language. Please! But if you want your company to prevail in the mass marketplace then your operating systems and languages are going to have to be written in assembly or your company is going to take the gas-pipe.
As far as mass-market application programs such as word processors and spreadsheets, you might check up on what language is used for the most successful programs... as Robert Carr just did. Carr was one of the developers of PASCAL-based MBA. After comparing his royalties with Mitch Kapor's, he decided to write Framework, the new Ashton-Tate integrated software package, in assembly. (29 May PC, p.39 and p.62)
But if you are going to write an application program for a non-mass-market, you should logically use a high level language. For instance, a payroll program for Sears, Roebuck should logically be written in (ugh!) COBOL. A structural analysis program should logically be written in FORTRAN (or some other language with built-in linear algebra and matrix support... ).
When H.P. adapted UNIX to its 9000 series minicomputer it found 281 previously undocumented UNIX bugs! (May 31 '84 Electronic Design, p.156)
If you would like to personally study UNIX, pick up the 29 May '84 issue of PC magazine. In addition to the editorial on p.81, there are five articles on UNIX on pages 145-177. There is a history of UNIX, an explanation of how UNIX works, and descriptions of three UNIX clones.
Intel supporters will tell you with a straight face that the Intel product line addresses big memories just as well, if not better than, the 68000. Well, PC WEEK (29 May p.38) lists eight Fortran compilers and five COBOL compilers. All are limited to 64K program and 64K data except Softech Microsystem's p-code FORTRAN, which is limited to 32K program (!) and Ryan-McFarland's COBOL, which is limited to 32K data.
There is just one exception to the above: MicroWare Inc's FORTRAN compiler, which lists at a cool $1,350.
If the Intel processors ain't somewhat limited how come 12 of 13 compilers are limited to 64K blocks or less? Is this "believe what I say, not what folks do?"
Most of you know that Trameil is starting a new personal computer company to be named 'Trameil Technology Ltd'. A paragraph from 5 Jun '84 WSJ p.4:
"Mr. Trameil owned two million shares of Commodore prior to his departure, but said in a Securities and Exchange Commission filing shortly after his resignation that he had arranged to sell one third of his holdings, which would have reduced his holdings to about 1.4 million shares, or a 4.5% stake in the company. Under SEC rules, further sales below the 5% level needn't be reported. Mr. Trameil declined to discuss his current level of holdings, but a Commodore executive said Mr. Trameil has sold most or all of his shares."
Translation: Kindly Uncle Jack is sitting on a liquid war chest of about $60 million (Commodore stock has declined slightly recently, possibly due in part to Jack's selling so many shares). According to the WSJ (and EN) he plans to put up $40 million of his personal money and raise another $110 million through brokers such as Merril Lynch. That would give the startup company $150 million, about equal to the total invested to date in Fortune Systems. It would also leave Kindly Uncle Jack with about $20 million in liquid assets which is NOT invested in the company! That should keep K.U.J. in pork-and-beans for awhile.
Don't forget that very well capitalized companies can go down as well as up, as Fortune Systems has amply proved. Somehow we do not think that will happen to an outfit headed by a healthy K.U.J. However, K.U.J. is not getting any younger. How much money would you want to bet on a company run by Jack's successor?
Ah, yes: Jack's successor. As we reported, the occasion of Jack's departure was related to Trameil's and Gould's disagreement over Gould's selection of a new prexy for Commodore International. What we did not know at the time was why that disagreement. Now we know. Trameil wanted to bring his two sons, Leonard and Sam, into upper level Commodore management but Gould was opposed. And Gould held a lot more Commodore stock than Jack...
Gould and Trameil traveled a long road together. With all of Trameil's Commodore stock cashed in, it is splitsville - permanently!
C. Gordon Bell has an article in Jun '84 IEEE COMPUTER magazine. The title, "Standards Can Help Us", is plain terrible. The article is excellent and is highly recommended. It is worth seeking out.
Bell discusses UNIX from a point of view that is at right angles to our view and that of our critics, for instance. He discusses the evolution of microcomputer architecture. He wants bus and LAN birth control - an excellent idea. He discusses the coming standardization of silicon foundries and silicon compilers and such. The more you bring to the article, the more you will get out of it - to some folks his single sentence on the Intel 432 might seem cryptic: "It is ironic that information on addressing didn't travel from California to Oregon, where Intel's 432 was developed."
As is inevitable in such a wide-ranging article covering moving targets, Bell made some small mistakes. He seems to think that Silicon Graphic's IRIS workstation is a couple of hundred times faster than the "other 150 graphics workstations". This will come as a big surprise to Chromatics and to other vendors developing products based on Weitek's chips and Weitek's board-level tiling engine (more on this in a future issue).
Also, Bell is yet another person who has been bamboozled by Intel's promotional material on the 286. For instance: Steve Scott can run the mile in under four minutes? Yes. Steve Scott (a husky fellow) can carry a refrigerator strapped to his back? Yes. Steve Scott can run a four-minute mile with a refrigerator strapped on his back? No.
Similarly, the Intel 286 really does run fast. And it really does have built-in memory management. But it DEFINITELY does not run fast with the memory management switched on...
John Gantz just got real unlucky. In 2 Jul '84 Infoworld, p.18, he serves up the facts and figures why IBM should logically come up with a price cut. Then he asserts that no such cut will in fact be forthcoming. While that column was at the printers, IBM cut their prices. Sigh...
Incidentally, the trade papers will tell you that IBM cut their prices on the order of 23%. The figure we used, elsewhere in this issue, was 15%. You see, IBM backed off a bit on the outrageous price premium of the next 192K after the first 64K of RAM. Because of that outrageous premium, almost nobody was buying that 192K from IBM. Even the dealers selling 256K PCs were plugging in those extra RAM themselves. So we call that portion of the price cut an adjustment to reflect market conditions. We stand by our assertion that 15% is just about the real IBM price cut. (Similarly, the price cut on the XT reflects market conditions with respect to Winchester upgrades.)
Using a 'hardware' 16 bit divide into 32 bits to perform a 48 bit by 48 bit integer divide is not simple. First, you have to know how the integer divide works (issue #2 p.14). Next, you have to know that the considerable (programming) work entailed is worthwhile, as in a 2.5 times speedup as compared to a simple shift-and-maybe-subtract algorithm. We told you that in issue #3, p.14, and then proceeded to list the code for using the hardware divide to speed the Microsoft compatible 68000 floating point package.
And then, over the next year, we forgot about it because we don't like much of issue #3 of our own newsletter, and so when we did our 62-bit floating point package we used shift-and-maybe-subtract on the assumption it would be FASTER! (Issue #15, pp27-28) Maybe we should read our own newsletter?
So, both Chet S. and Ulrich S. were correct in asserting that the use of the hardware divide was faster. Both wound up sending us examples of routines which they had written independently (we are flattered that the signs and exponents were handled in the exact manner of issue #3, p.14 in both examples). So we finally got around to writing our own routine, which you will find in REDLANDS (honest!).
In our software floating point package we use a 48 bit mantissa whose most significant bit is always set unless the entire floating point number is zero. (Testing the MSB of the mantissa is the correct test for zero in our package; it is true that our own divide routine in issue #15 tested for a zero exponent instead. Sigh.) Concentrating for the moment on non-zero numbers, here are the largest and smallest permissible mantissas:
FFFF FFFF FFFF 8000 0000 0000
Suppose that the larger number is the numerator and the smaller the divisor. If that is so, our initial hardware divide will not work because the most significant 16 bits of the 32-bit numerator are larger than (or equal to) the 16-bit divisor. So we begin by testing whether the 48-bit numerator is less than the 48-bit denominator. If not, we subtract the denominator from the numerator once and set a flag which tells us to correct the result at the completion of the subsequent division operation.
We will now assume that the 48-bit numerator is less than the 48-bit denominator. Even so, we cannot assume that the hardware divide will be correctly performed.
For instance, take the following numerator and denominator:
8000 0000 0000 -------------- 8000 FFFF FFFF
Even though the numerator is clearly less than the denominator, the attempt to divide $8000 0000 by $8000 will not execute correctly and the overflow flag will be set. Not to worry; since we know for sure that the entire 48-bit numerator is less than the 48-bit denominator then we know the largest possible result of the divide is $FFFF (with a remainder, to be sure!). So we test for the overflow flag immediately after the initial divide and assign the result equal to $FFFF if the overflow flag is set.
As you might expect, dividing by $8000 is not the same thing as dividing by $8000 FFFF FFFF. The 16-bit result of the hardware divide will either be correct or it will be one or two bits too high. (The result will NEVER be too low.) And that means that the remainder of the hardware divide is garbage which must be ignored. We need a way to determine the CORRECT 16-bit result and to obtain the CORRECT remainder!
What we do is use the result of the hardware divide as a TRIAL result. We multiply the 16-bit trial result times the 48-bit denominator to obtain a 64-bit number. Then we extend the 48-bit numerator to a 64-bit number and subtract the first 64-bit number from the extended numerator. Now, please follow this closely:
If the trial result was correct, then the most significant bit of the 64-bit result of the subtraction will be zero. (In fact, the most significant WORD will be a zero, but we will use the N flag as the test.) If the trial result was one or two bits too high then the result of the subtraction will underflow and the most significant bit of the 64-bit result of the subtraction will be set.
If we have an underflow then we know that the 16-bit result of the hardware divide is too high. We subtract one from this result and compensate by adding the 48-bit denominator to the most significant 48 bits of the result of the 64-bit subtraction. If the trial result was only one bit off, this will result in a number whose most significant bit (and word) is zero. Otherwise, we loop once more to correct the two-bit error. This time the most significant bit will definitely be zero and we can proceed.
We now have the correct value of the first 16 bits of the result of the division. The original 48-bit numerator is now reduced to a 32-bit number with a 16-bit remainder (the most significant 16 bits of the numerator are now all zero and so that 16-bit word can be ignored).
We now continue by dividing the 32 most significant remaining numerator bits by the most significant 16 bits of the denominator. This will give us a trial value for the second 16 bits of the division. Once again, this second trial result can be either correct or one or two bits too high. Our strategy for obtaining the correct 16-bit number is ESSENTIALLY the same as for the first 16-bit trial result, but we have a decision to make:
Just exactly how important is it too us that a half-bit error be rounded in the "correct" direction if the result is greater or less than a half-bit by an additional .015% of a least bit? If that is important to us, then the numerator must be extended to a remainder of 32 bits on the second phase of the divide and once again to a 48-bit remainder on the third and final phase of the 48-bit integer divide. Our result would be a 48 bit number with a 48 bit remainder which would then be examined for rounding to a 48 bit result. This requires that all three phases use a 16-bit times 48-bit multiply with a 64-bit result to correct the three trial results. And it assures that results which are have a remainder of almost exactly a half-least-bit will be rounded in the "correct" direction.
If you, like us, feel that a number which is off by almost precisely half a bit can be rounded in either direction without causing undue anguish, then we can use, in the three phases, 64, 48 and 32-bit results of multiplies to correct the three trial results. This will give us a 48-bit result with a 16-bit remainder. The least bit of that 16-bit remainder might not be correct! Like the new multiply algorithm we printed two issues back, we are accepting "teetering half-bits" to speed up the calculation.
(Let us emphasize that this "problem" occurs ONLY when the result has a remainder which is almost precisely a half-bit. And remember, that half-bit IS going to be rounded in one direction or the other, no matter what strategy we adopt. We say it is not worth the extra time to round in the "correct" direction if the result has a remainder of almost exactly half a bit.)
In the following discussion of Weitek's floating point chip set, remember that the Weitek set cannot perform division directly. Instead, the reciprocal must the calculated through an iterative process.
THE SUBJECTIVE IMPRESSION WE GOT at the seminar we attended was that Weitek was started by some gung-ho chip designers turned math hardware freaks. We got the impression that the Weitek folk were highly dedicated to their task and having fun at it. Although Weitek makes mostly IEEE floating point type chip sets you must understand that these sets are NOT like the 8087 or 16081. By Weitek's standards, those two chips are SLOOOOW!!
The Weitek chip sets are as fast as is possible at the current state of the art (for chip sets, that is). This has some ramifications, some of which are good and some of which (from our point of view) are bad. We can think of about seventeen things, each of which is so important that it must be mentioned first! Sigh...
There are three main applications to the Weitek chip sets: digital signal processing, 3-D (color) graphics, and math accelerators for general purpose computers (this includes array processors).
It is possible to match the speed of the Weitek chip sets, even to run just a bit faster, but this requires a board-level design using lots of MSI logic. The result would inevitably be less reliable and consume much more space and power. This means that some previously impractical applications are made possible by the Weitek chip sets. An obvious example is a 3-D digital signal processor which runs in real time and is coupled to the radar of an F-15 to give the pilot an overwhelming advantage over a hostile aircraft which lacks such gear.
We do not have to climb into the cockpit of an F-15 to find ready applications for something more reliable, smaller, lighter, and lots less power-hungry. Consider an existing hospital with an existing air conditioning system. There is a lot of useful digital gadgets which can't be used because of too much heat generation but which can be re-designed using the Weitek sets to get the power down to a reasonable - and useable - level. And the increased reliability is important to a hospital, which does not generally have lots of electronic engineers and techs floating around.
In 3-D graphics applications, the small size is as important as the lower heat generation. That makes it possible to build the needed high-speed math support right into the graphics workstation rather than resorting to a high-speed data link going to a VAX-cum-array-processor in a special air-conditioned room.
The non-business oriented reader is cautioned that profitability does not always indicate a positive cash flow. This is especially true of startups. A simplistic example: a startup earns $1M but invests $10M in capital equipment, which shows on the books as a $10M asset, not an expense. Nevertheless, the startup has had a negative cash flow of $9M. This is why investors are needed.
The Weitek 32-bit floating point chip set, which is in production, is ideally suited to both digital signal processing and to 3-D graphics. Both application areas are growing rapidly. Weitek's product line (with the addition of a special purpose chip to be introduced in the 3rd quarter 1984, more later) is ALREADY broad enough to base a pretty doggone successful company on. Our justification for calling the Weitek folk gung-ho is that they are already forging ahead into new territory which is not necessary for the short or medium term success of the company. (Just as HALGOL is not necessary to OUR short or medium term success.)
Weitek is proceeding to develop a double-precision IEEE floating point version of its chip set! And - this part we think is INCREDIBLE - finds itself eyeball-to-eyeball with Analog Devices, of all people! (It seems to be time to railroad.) We believe that Weitek is closer to real product than Analog Devices, so we will restrict ourselves to the Weitek line from here on out.
A MOMENT, PLEASE: We have a varied readership but we have more software types than hardware types. Some of our hardware type readers are incredibly more knowledgeable about pipelining than we are but we have other readers who think pipelines are found exclusively in oil fields. Please bear with us.
Digital 'pipelining' does indeed take its name from the pipelines found in an oil field. Take, for example, a pipeline 100 miles long. If you push a barrel of oil in at one end, how long does it take to get a gallon out at the other end? Why, it happens essentially instantaneously! (If the pipeline is filled.) How long does it take to get a PARTICULAR barrel of oil from one end to the other? Nobody cares! (But if we are talking about DIGITAL pipelines, that time is called the LATENCY.)
Take, for instance, the Weitek 32-bit floating point multiplier chip. With a 10MHz clock, it performs five floating point multiplies per microsecond. But it takes a full microsecond to perform a PARTICULAR floating point multiply. The obvious (and correct) inference is that the Weitek multiplier uses a five-level (ten clock) pipeline.
An oil pipeline is continuous, sort of an analog pipeline. Digital pipelines are discrete and are separated by registers. All of the registers are clocked simultaneously so that the data 'flows' through the pipeline in a continuous stream.
Although the Weitek chip set can be used in an unpipelined or 'flow-through' mode, it does seem a shame to give up a 5-1 edge in performance. This means that dedicated control logic is needed to sequence the chip set to perform a particular type of computation - a fast-Fourier transform, for instance. Different control logic is needed to perform a 3-D rotation, scaling and clipping for a graphics application. Therefore, if we are to get the maximum performance of which the Weitek chip set is capable we are necessarily restricted to specialized applications rather than general purpose use.
By now it should be occurring to you that the Weitek chip set is philosophically akin to the Wallace multiplier. The Weitek chips definitely require separate data and control buses, so they are non-von Neumann devices. To obtain maximum performance, the Weitek chips are often used in a data-flow configuration. This will take some explanation:
Take, for instance, a perfectly ordinary complex radix-2 FFT. The fundamental operation is the butterfly, which requires four multiplies and six signed additions (subtraction is essentially indistinguishable from signed addition and will be ignored). A regular computer programmer, accustomed to the von Neumann architecture, would program those ten operations in an appropriate sequence and eventually the job would get done.
A DSP (Digital Signal Processing) person would grab 4 Weitek multiplier chips, 6 Weitek addition chips, and connect them in a three-level pipeline which is a dataflow representation of the complex butterfly algorithm. Such a configuration is called a "screamer" in the trade, and will perform a complex radix-2 butterfly every 0.2 microseconds! This "screamer" is performing 50 - count 'em, five-oh, floating point operations every microsecond. That's 50 megaflops, which will give you some idea why the device is called a "screamer".
This naturally led us to speculate that the Weitek double-precision chip set, which we learned about for the first time at that seminar, might be an integral part of the FPS-164, which has been advertised but not delivered. Both parties are being cagy, but a recent FPS-164 ad spoke of LSI parts being scheduled for delivery at the end of this year. We have come to the reasonable conclusion that the Weitek double-precision chips are indeed going to be the number-crunching heart of the FPS-164.
Interestingly, Ed Sun and Norm Winningstad have not met. Too bad - aside from the generation difference, Dr. Sun and Winningstad are much alike and would doubtless hit it off very well. We wonder if any of the $4M invested in Weitek is FPS money?
For a 1024-point butterfly, 10 'passes' are required. If yet another level of pipelining is imposed, ten separate "screamers" can be used to speed up computations by an order of magnitude. We are now at 500 megaflops and we have one hundred Weitek chips. (You can see their sales manager and comptroller rubbing their hands in glee!) As you can imagine, such a device can perform FFTs very swiftly indeed, and is called a "super screamer" by the DSP folk.
If that is not fast enough, it is in principle possible to use up to 512 separate "screamers" at each of the ten levels. This would require 51,200 Weitek chips! Nobody has done that yet, but Dr. Sun asserts that one real DSP application requires over 1,000 chips and executes several gigaflops (giga = 1,000 times 1,000,000) per second. Such devices are so new that the DSP folk have not come up with a name. Somehow "super duper screamer" seems inadequate.
It will have occurred to you that the DSP devices described above are highly specialized as opposed to general purpose. This is the penalty one incurs when abandoning the von Neumann general-purpose computer architecture. The advantage is being able to achieve performance levels which no von Neumann device can attain (at a given level of technology). A certain NEC VLSI CMOS graphic processor also provides very high graphics performance thru the use of many chips and a data flow architecture.
This brings us back to the INMOS Transputer. INMOS claims that the Transputer will be capable of very high performance in a data flow architecture configuration - an assertion which seems eminently reasonable. But they add that that high performance data flow architecture will be GENERAL PURPOSE - and that does not seem reasonable to us.
We believe that the Transputer, if it ever becomes commercially available, may very well prove a success in certain dedicated applications but that it cannot possibly be successful as a general purpose computer. A lot of very high powered technical folk, mostly on the INMOS payroll, would strongly dispute our assertion. You pays your money ($1.50 for this rag) and you reaches your own conclusions, don't you now ducky? (Well, the Transputer IS British...)
[We have cleverly evaded the point, which is: WHAT CAN THE WEITEK CHIPS DO, IF ANYTHING, FOR ME AND MY MICROCOMPUTER? We sort of promise to return to this matter in a future issue. See how cagy we're getting?]
The current (Aug '84!) issue of ANALOG (with a satellite on the front cover) carries a novelette entitled "The Crystal Ball". This story, set in the year 2003, postulates an intelligent program with a personality. It also incorporates data flow machines and parallel processing as a part of the environment for the intelligent program. A short excerpt:
"'...what else would happen to her? She's a single job, so she's got a superfast chip dedicated to her.'
"'Don't you understand about data flow machines? They break programs into pieces based on concurrency diagrams.' She reached past him, typing clumsily for a distance.
"'But she's a simple program.'
"'But think how she'd look on a concurrency chart. She's so modular in her search procedures.' The display responded to her new query, and Celeste shrieked. 'And she's already distributed across 10,000 processors!'"
(Not to worry, folks. Our intelligent program is trapped in a data-flow machine with 50,000 parallel processors, so she is using only 20% of the machine capacity. And she [Valentina, the program] is going to take over the other 80% pretty quick.)
If you like or can even tolerate science fiction, it might be interesting to pick up this issue just for the one story. What's that? Why are we really
recommending this story? Well, it is about a maximally efficient computer in the year 2003. And it seems that the author (who is NOT us) thinks that in addition to a dataflow machine with massive parallelism, a fast machine will have to have an efficient operating system - something which EVERYBODY (almost) in 2003 knows is no longer needed!
The title reminds us of an old off-color joke: "Why do gypsies steal children?" "Crystal balls."
Well, maybe. The 14 Jun '84 issue of ELECTRONICS focuses on the worldwide semiconductor market. The cover message: "RACKING UP A RECORD YEAR?" You betcham, Red Ryder! P.126: "'So with business for the semiconductor makers the best it has been in years, equipment makers are not getting all the supplies they need to make their products. Since supply is not meeting demand, "the semiconductor industry is constraining the growth of the electronics industry,' says..."
Besides the guy they were quoting, so says us, too. The marketplace is a real mess. We are developing a new, medium-resolution graphics board and there is some question whether we will be able to get the parts we need to manufacture it in a timely manner. Let us pass along to you a horror story:
The distributor who is our largest source of TTL product recently held a very serious meeting including its inside and outside salespersons. This distributor, like most, had (and has) a lot of scheduled orders for TTL product. Some of those scheduled orders - out to December - are ours. The distributor had booked orders based on promises of product from Hitachi (Japan), from SGS (Italy), and especially from long-time supplier T.I.
Well, Hitachi did not deliver, SGS did not deliver, and T.I. came through with only 80% of its previously promised deliveries. It did not take a genius to see that this distributor could not possibly fill all the scheduled orders it had booked. The purpose of the serious meeting was to determine which companies would be dumped completely (the baby tossed to the wolves from the back of the speeding Russian troika), which would be wounded, and which would remain unscathed.
Come the review of Digital Acoustics: How long have they been a customer? Twelve years. How do they pay their bills? They have taken the 10 day/2% discount for the past two years (this is unheard-of, honest). How much drag-through business do we (the distributor) get? Well, $31,000 in Hitachi 12.5MHz 68000s for starters, plus a whole bunch of other stuff. Digital
Acoustics came out of the meeting unscathed, which means we will in fact receive most of our scheduled shipments. (In today's conditions NOBODY gets ALL their shipments - IBM excepted.)
But next week we have to try to schedule parts, beginning in September, for the production version of our 640 X 400 graphics board. This we are worrying about. A lot. Oh, yes: "drag-through business": it works like this: if you want to buy some of the super-scarce TTL, it would be very nice if you would buy some of the stuff - like expensive 12.5 MHz Hitachi 68000s - which is not scarce.
We just got the latest issue of UNIX Review (Jun '84). Page 28: will somebody please tell the editors of UNIX Review that doubling one's sales in a year corresponds to a 100% increase, NOT 200%? Then you can turn to the article beginning on p.18 which tells you, repeatedly, how fast PC/IX is. Really. REALLY?
This must be a different PC/IX than the one which took four of the ten available last-place finishes in benchmarks against 27 other competitors. It is most certainly a different PC/IX than the one Peter Norton wrote up, explaining that it was so slow because the PC has no hardware memory management, so PC/IX handles memory management in sloooow software. It also must be a different PC/IX than the one in the article beginning on p.44 of the same magazine, which is addressed to working around PC/IX's limitations (especially the ones caused by segmented addressing).
To the surprise of no one, IBM cut the prices on the PC and PCjr on 7 June. The PCjr was dropped to $999 (what else?). Within a month IBM will announce a new keyboard for the jr and that will not surprise anyone either. It WILL surprise a few folk when the repriced jr with a new keyboard continues not to sell...
If anything, the big surprise is the small price drop of the PC. Instead of the 25 to 30% everyone expected, the drop is closer to 15%. That means the clones will only be hurting badly instead of being devastated. IBM is being almost cruel in prolonging their agony.
Computer Associates just bought Sorcim (vendors of SuperCalc) for $17.6 million cash. The moment the transaction was finalized, they laid off Sorcim's top 35 officials, including prexy James Pelkey. No reasons were given for the cuts. (EN, 11 Jun) Er, you DID want to be an important executive of a software firm?
The software shakeout that we called to your attention earlier (#28, p.5) is proceeding apace. As we explained, with a true mass market for computers we would need FEWER, not more, computer programs. This is being proved true right now! The small software houses are dropping like flies! We do not need 200 spreadsheets, we need ONE (and in the IBM sector, ONE is what we damn well have). We need at most four word processors: one descendent of Michael Schrayer's Electric Pencil (WordStar), one Wang emulator (Multi-Mate), one compromise (SpellBinder) and one very simple word processor for occasional memo-writing (?).
That would imply that we need maybe five programs: A word processor, a spreadsheet, a data-base manager, a graphics package and a communications package. Wrong. We need ONE package, an integrated package which combines all five modules. We are almost there with Lotus' Symphony and Ashton-Tate's Framework.
And that implies that we need one program. We don't even need that many! The HP 110 contains 380K bytes of ROM, including Lotus' 1-2-3. Trameil left Commodore with a low-end computer which is sort of a $300 HP 110 but the new Commodore management does not recognize what it has and is instead agonizing over C-64 incompatibility. (The new machine was SUPPOSED to be incompatible with the C-64!)
[Late scoop: Commodore may have finally figured it out. The new CBM machine will be introduced with all four application ROM sockets filled, just the way Kindly Uncle Jack would have done it. This makes the second smart move Commodore's new management has made post-Trameil - the first was to NOT introduce that low-end UNIX (well, Coherent) Z-8000 machine.]
At mass production levels, say 100,000 to 1,000,000 computers per month, a megabyte of ROM costs $200 (at most) TODAY and a lot less than that next year. With a megabyte of ROM you can have 1-2-3, MultiMate, dBASE II, Crosstalk, a graphics package, BASIC, FORTRAN and MODULA-2 and have room left over for a few rock-shooting games. Piracy? What software piracy? Trameil and HP have blazed the trail and the Japanese are developing big, cheap ROMs because of the problems imposed by their language.
Imagine! Some folks thought that lots more computers equalled lots more programs! How quaint...
There will still be a need for certain limited-use applications programs (petrochemical, architectural, structural, environmental, etc. etc.). But most folks will program for their own use, such as (in our case) solving engineering programs.
The mom-and-pop cottage software house is disappearing. The shakeout that we told you about back in #28 is in progress right now, and it is happening in advance of the hardware shakeout. If we are not witnessing the death of software, we are witnessing the death of the software marketplace as we have known it for the past eight years!
(How, you ask, did we suddenly get from 4 word processors to one? Simple. In a truly mass market, the Chrysler push-button transmission fails by the wayside and everybody learns to shift gears ONE WAY. The commands for manipulating a spreadsheet are ALREADY as standardized as the meaning of a double yellow line down the center of a road - or hadn't you noticed? Learning to use the standardized, software-less mass-market computer will just be another skill to master, such as learning to drive a mass-market automobile on a massive roadway network.)
said Greta Garbo. In issue #9 (p.21) of The Computer Journal, author Bill Kibler tells us of "TURBODOS, a high speed version of CP/M, [which is] a good example of some programmer's positions. The authors are not available, and hide out somewhere unknown to all but their agents..."
Does Bill Kibler really believe that, having written TURBODOS, the authors are obligated to devote hours a day, henceforth and forever, to answering enquiries from miscellaneous dolts and twits? Or even the time-consuming thoughtful calls? Apparently Bill really DOES believe that.
As we have said before, writing a programming language is one of those things which should never be done for the first time. The second time around, one has learned some of the obvious mistakes to be avoided. Let us tell you FOR CERTAIN that the next time we decide to write a programming language we will be unavailable and that our whereabouts will be known only to our agents!
It seems that ours is not the only environment where apparently intelligent, rational persons can (and do) make unreasonable and irrational demands. The "obligation" which Bill Kibler is unilaterally attempting to retroactively impose on the authors of TURBODOS does not exist.
In the good old days, when somebody did not pay their debts, you lopped off their head, sold their wife and children into slavery, and levelled their domicile/business. If you were really mad, you might
even poison the earth with salt, as the Romans are said to have done to Carthage.
These days there is Chapter 11, which provides for voluntary bankruptcy. In Chapter 11, the debtor is granted legal asylum for a time from his creditors while a plan is developed under court guidance for rescheduling the repayment of the debt. If the debtor can convince the court that repayment is possible, the business is allowed to continue under the supervision of a receiver appointed by the court.
Some folk do not care for the social benefits to the community of trying to keep a business alive, and have instead a strong desire to close down the offending debtor immediately. (Some folk long for the old days.) (You Commodore folk see MIDNITE, issue #17, near the bottom of page 11.)
Do you realize that it has been a year since we went (GULP) and stuck our neck out on a prediction that the Intel 80186 and automated production were going to take over the personal computer marketplace, three-piece-suit division? Who in the world would have believed that Intel's inability to deliver would (for the time being) torpedo that prediction? Just one company alone (Convergent Technology) could use every 80186 Intel is going to make in '84 and still cry for more!
Did you notice where Infoworld, in its Tandy 2000 review, benched it against the IBM PC using Multiplan and that a recalculation time dropped from 6 seconds to 0.7 seconds? We know you do not read 80 Micro, so you will not have seen where Mitch Kapor said that the 2000 is 5 to 6 times faster than the IBM PC. These are not really typical speedups, being computationally intensive where the very efficient 80186 hardware multiply/divides become noticeable. The average speedup is about 2.5 - 1 unless we are waiting for a printer, in which case either machine runs at the speed of the printer. And the Tandy 2000 is absolutely typical of the new 80186 machines.
We know that you probably do not read PC WEEK but we do - and every week there are another one to three 80186-based better-than-IBM three-piece-suit personal computers announced. The numbers of computers that we predicted are already here. The problem is, nobody can ship significant quantities for lack of parts. The lack of parts is due to a lack of production capacity. The lack of production capacity is relative, not absolute - in other words, Intel allocates production time slots to various products.
To those folks who are just a little paranoid, the fact that the 80186 (used by MANY would-be IBM competitors)
does not seem to be getting much production priority might seem significant, especially since every 80186-based machine sale is likely to come out of IBM's hide. Did you know that IBM owns 20% of Intel?
Question: does our year-old prediction count as a hit or a miss? Perhaps (muttered darkly) we should cut out the Nostradamus bit and concentrate on hawking boards?
Speaking of hawking hardware, we wonder how sales of Ciarcia's Trump Card are going to go? Have any of you noticed the philosophical similarity of T-BASIC to HALGOL? We also wonder how Qwerty and Saybrook and PDQ are doing?
For that matter, has anyone heard from Dimension or Pinnacle, the two 68000-based stand-alone computers from Texas? There are two more 68008 boards on the Apple UTH market; one the Stellation 2 board with absolutely no resident memory and the other a static RAM cum EPROM board which is absolutely identical to the one we proposed building a long time ago and which none of you readers was interested in (see the ads in CALL-APPLE). Has anybody seen one of these boards?
Sales of the IBM PC are soft, as witness the recent price cut. Our friendly local Apple dealer has two or three Macks in stock, no waiting. Eagle has one foot in the grave and the other on a banana peel. Morrow's Z-80 cum software integrated package is on sale this weekend in L.A. for less than $1000. Some folks have actually taken delivery of their second floppy drive for Mack - a sure sign that a former shortage isn't. The Apple IIc is not exactly conquering the world although it is selling modestly well.
Eagle is the latest to learn that in the harsh, cruel personal computer marketplace one only gets to fail ONCE, and that failure will be permanent. Apple learned that lesson on the Apple III a while back. IBM has not yet learned that the PCjr is, permanently and for all time, DEAD! So it is desperately trying to pump life into the decaying corpse.
The only hard tickets around seem to be the C-64 and the QL (in Britain only, for now). There is a strong hint that the number of rodent persons who wish to travel north may be limited - else why the Macks sitting (if not for long) in dealers' storerooms? (Come to think of it, the shortage of Imagewriters may be at fault there.)
Sit down and write down the names of all the personal computer vendors who are selling in significant quantities. Can you come up with ten names? Twenty? Could you have named twenty companies two years ago?
In issue #28 we explained to you how you could get rich (p.3). We pointed out that the smash, run-away best-seller 1-2-3 was vulnerable to a competing spreadsheet which incorporated math chip support. We also explained, to Ben Rosen's nose's discomfiture, how to get financial backing for your project.
AHEM! Ashton-Tate is introducing Framework, which competes head-to-head with Lotus' Symphony, successor to 1-2-3. Some folks have reported that Framework is two or more times faster than either of Lotus' packages. Gosh! Since Lotus' packages are already written in assembly, how is it possible for Framework to be two or more times faster? Gee!
Framework is faster than Symphony because it:
A [ ] is written in PASCAL
B [ ] incorporates 8087 support
Rodin's 'Iris, Messenger of the gods' was:
A [ ] a lady
B [ ] a woman, but evidently no lady
The cover of the Jun '84 80 Micro features a young lady and the caption "Going Up With the 80186". OOPS! We seem to have run out of space this issue...
PERMISSION IS HEREBY granted to anyone whomever to make unlimited copies of any part or whole of this newsletter provided a copy of THIS page, with its accompanying subscription information, is included.
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; II, II+, IIe, soft: ProDOS, LISA, Mackintosh?: Apple Computer Co. Anybody else need a 182nd million ack, have your legal beagles send us the usual threat.
SUBSCRIPTIONS: Beginning with issue #19, subscriptions are $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. The address is:
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
REDLANDS THIS MONTH lists a new, faster 62-bit floating point divide routine for HALGOL (honest!).
125 LIST 126 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 127 ; 128 ; FETCH AN 8 BYTE F.P. NUMBER TO STK, D4, S5 129 ; 002448: 31D8190A 130 FPDIV MOVE.W (A0)+,S2 ;S2, X2 00244C: 2818 131 MOVE.L (A0)+,D4 ;M2A, M2B 00244E: 3A18 132 MOVE.W (A0)+,D5 ;M2C 133 ; 134 ; PERFORM A 62 BIT FLOATING POINT DIVIDE 135 ; DIVIDE FPACC1 INTO FPACC2 136 ; FIRST PERFORM A 48 BIT INTO 48 BIT INTEGER DIVIDE 137 ; (D4.L,D5.W)/(D6.L,D7.W) 138 ; 002450: 2C381904 139 FPDIV2 MOVE.L S1+2,D6 ;M1A, M1B 002454: 3E381908 140 MOVE.W S1+6,D7 ;M1C 002458: 4A86 141 FPDIV3 TST.L D6 ;DIVISOR ZERO ? 00245A: 6A00FF24 142 BPL DIV0 ;ERROR IF SO 143 ; 00245E: 4A84 144 TST.L D4 ;DIVIDEND ZERO ? 002460: 6A00FF28 145 BPL RZER ;ZERO IF SO 146 ; 147 ; TEST WHETHER M1 >= M2 148 ; 002464: 4243 149 CLR.W D3 ;CLR SUBTR FLG 002466: BC84 150 CMP.L D4,D6 ;COMP M1AB, M2AB 002468: 6606 151 BNE DIV1 ;IF UNEQUAL 152 ; 00246A: BE45 153 CMP.W D5,D7 ;COMPARE M1C, M2C 00246C: 67000130 154 BEQ.L MANTEQ ;IF MANTS EQUAL 002470: 6206 155 DIV1 BHI MANTOK ;IF M2 > M1 156 ; 157 ; M1 IS TOO LARGE, SUBTRACT M2 FROM M1 & SET FLG 158 ; 002472: 7601 159 MOVEQ #1,D3 ;SET SUBTR FLG 002474: 9A47 160 SUB.W D7,D5 ;M1 = M1 - M2 002476: 9986 161 SUBX.L D6,D4 162 ; 002478: 3F03 163 MANTOK MOVE.W D3,-(A7) ;SUBTR FLG TO STK 00247A: 2004 164 MOVE.L D4,D0 ;D0 = M1A, M1B 00247C: 4846 165 SWAP D6 ;M2A TO B15-=B0 00247E: 80C6 166 DIVU D6,D0 ;DIV 32 BY 16 BITS 002480: 6802 167 BVC DIV2 ;IF DIV O.K. 168 ; 002482: 70FF 169 MOVEQ #$FF,D0 ;RESULT $FFFF 002484: 4846 170 DIV2 SWAP D6 ;RESTORE D6 002486: 3200 171 MOVE.W D0,D1 ;PREPARE FOR 16 002488: 3400 172 MOVE.W D0,D2 ;BIT TIMES 48 BIT 00248A: 3600 173 MOVE.W D0,D3 ;MULTIPLY 174 ; 175 ; MULTIPLY DENOM TIMES 16 BIT DIVIDE RESULT AND 176 ; THEN SHIFT THE DENIMINATOR 16 BITS RIGHT. 177 ; 00248C: C6C7 178 MULU D7,D3 ;LO PARTIAL PROD 00248E: C4C6 179 MULU D6,D2 ;MID PARTIAL PROD 002490: 4847 180 SWAP D7 002492: 3E06 181 MOVE.W D6,D7 002494: 4847 182 SWAP D7 002496: 4246 183 CLR.W D6 002498: 4846 184 SWAP D6 00249A: C2C6 185 MULU D6,D1 ;HI PARTIAL PROD 186 ;
188 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 189 ; 190 ; SUM THE THREE PARTIALS TO FORM A 64 BIT PRODUCT 191 ; 00249C: 4843 192 SWAP D3 00249E: D443 193 ADD.W D3,D2 0024A0: 6402 194 BCC DIV3 ;IF NO CY 195 ; 0024A2: 5281 196 ADDQ.L #1,D1 ;IF NO CY 0024A4: 4843 197 DIV3 SWAP D3 0024A6: 4842 198 SWAP D2 0024A8: D242 199 ADD.W D2,D1 0024AA: 6406 200 BCC DIV4 ;IF NO CY 201 ; 0024AC: 068100010000 202 ADD.L #$10000,D1 ;ADJ FOR CY 0024B2: 3403 203 DIV4 MOVE.W D3,D2 204 ; 205 ; THE 64 BIT PRODUCT IS IN D1.L, D2.L 206 ; SUBTRACT PRODUCT FROM EXTENDED NUMERATOR 207 ; 0024B4: 4845 208 SWAP D5 ;-- EXTEND THE 0024B6: 4245 209 CLR.W D5 ; NUMERATOR -- 0024B8: 9A82 210 SUB.L D2,D5 ;SUBTRACT PRODUCT 0024BA: 9981 211 SUBX.L D1,D4 ;FROM NUMERATOR 0024BC: 6A08 212 BPL DIV6 ;IF NO UNDFLW 213 ; 0024BE: 5340 214 DIV5 SUBQ.W #1,D0 ;DECR RESULT 0024C0: DA87 215 ADD.L D7,D5 ;ADD SHIFTED DENOM 0024C2: D986 216 ADDX.L D6,D4 ;TO NUMERATOR 0024C4: 6BF8 217 BMI DIV5 ;IF STILL UNDFL 218 ; 0024C6: 4840 219 DIV6 SWAP D0 ;SAVE 16 BITS 0024C8: 2205 220 MOVE.L D5,D1 0024CA: 3204 221 MOVE.W D4,D1 0024CC: 4841 222 SWAP D1 0024CE: 82C6 223 DIVU D6,D1 0024D0: 6802 224 BVC DIV7 ;IF DIV O.K. 225 ; 0024D2: 72FF 226 MOVEQ #$FF,D1 ;RESULT $FFFF 0024D4: 3001 227 DIV7 MOVE.W D1,D0 ;SAVE RESULT 0024D6: 3401 228 MOVE.W D1,D2 0024D8: 3601 229 MOVE.W D1,D3 0024DA: C6C7 230 MULU D7,D3 ;LO PARTIAL PROD 0024DC: 3E06 231 MOVE.W D6,D7 0024DE: 4847 232 SWAP D7 0024E0: C4C7 233 MULU D7,D2 ;MID PARTIAL PROD 0024E2: C2C6 234 MULU D6,D1 ;HI PARTIAL PROD 0024E4: 4246 235 CLR.W D6 236 ; 237 ; THE DENOMINATOR IS NOW 32 BITS IN D7.L 238 ; SUM THE THREE PARTIALS TO FOR A 48 BIT PRODUCT 239 ; 0024E6: 4843 240 SWAP D3 0024E8: D443 241 ADD.W D3,D2 0024EA: 6402 242 BCC DIV8 ;IF NO CY 243 ; 0024EC: 5281 244 ADDQ.L #1,D1 ;ADJ FOR CY 0024EE: 4842 245 DIV8 SWAP D2 0024F0: D441 246 ADD.W D1,D2 0024F2: 6406 247 BCC DIV9 ;IF NO CY 248 ;
250 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 251 ; 0024F4: 068100010000 252 ADD.L #$10000,D1 ;ADJ FOR CY 0024FA: 4842 253 DIV9 SWAP D2 0024FC: 4841 254 SWAP D1 255 ; 256 ; THE 48 BIT PRODUCT IS IN D1.W,D2.L 257 ; SUBTRACT THE PRODUCT FROM THE EXTENDED REMAINDER 258 ; 0024FE: 9A82 259 SUB.L D2,D5 002500: 9941 260 SUBX.W D1,D4 002502: 6A08 261 BPL DIV11 ;IF NO UNDFL 262 ; 002504: 5380 263 DIV10 SUBQ.L #1,D0 ;DECR RESULT 002506: DA87 264 ADD.L D7,D5 002508: D946 265 ADDX.W D6,D4 00250A: 6BF8 266 BMI DIV10 ;IF STILL UNDFL 267 ; 00250C: 2205 268 DIV11 MOVE.L D5,D1 ;32-BIT NUM 00250E: 3C07 269 MOVE.W D7,D6 ;LESSER WORD 002510: 4247 270 CLR.W D7 002512: 4847 271 SWAP D7 ;D7 = DENOM MSW 002514: 82C7 272 DIVU D7,D1 002516: 6802 273 BVC DIV12 ;IF DIV O.K. 274 ; 002518: 72FF 275 MOVEQ #$FF,D1 ;RESULT $FFFF 00251A: 3401 276 DIV12 MOVE.W D1,D2 00251C: 3601 277 MOVE.W D1,D3 00251E: C6C6 278 MULU D6,D3 ;LO PARTIAL PROD 002520: C4C7 279 MULU D7,D2 ;HI PARTIAL PROD 002522: 4243 280 CLR.W D3 ;CLR LOWER WORD 002524: 4843 281 SWAP D3 ;ALIGN PARTIALS 002526: D483 282 ADD.L D3,D2 ;D2.L = PRODUCT 283 ; 284 ; THE 32 BIT PRODUCT IS IN D2.L 285 ; SUBTRACT THE PRODUCT FROM THE EXTENDED REMAINDER 286 ; 002528: 9A82 287 SUB.L D2,D5 00252A: 6A0A 288 BPL DIV15 ;IF NO UNDFL 289 ; 00252C: 5341 290 DIV13 SUBQ.W #1,D1 ;DECR D1 00252E: 6402 291 BCC DIV14 ;IF NO CY 292 ; 002530: 5380 293 SUBQ.L #1,D0 ;DECR D0 002532: DA87 294 DIV14 ADD.L D7,D5 002534: 6BF6 295 BMI DIV13 ;IF STILL UNDFL 296 ; 002536: 4845 297 DIV15 SWAP D5 ;32-BIT REMAINDER 002538: 8AC7 298 DIVU D7,D5 ;D5.W = GUARD WORD 00253A: 6802 299 BVC DIV15A ;IF DIV O.K. 300 ; 00253C: 7AFF 301 MOVEQ #$FF,D5 ;RESULT $FFFF 00253E: 4841 302 DIV15A SWAP D1 ;-- D0.L, D1.L ARE 002540: 3205 303 MOVE.W D5,D1 ; 64 BIT RESULT -- 304 ; 305 ; THE INTEGER DIVIDE IS COMPLETED; NOW 306 ; CALCULATE THE SIGN AND EXPONENT. 307 ;
309 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC 310 ; 002542: 361F 311 MOVE.W (A7)+,D3 ;RECALL SUBTR FLG 002544: 3C38190A 312 DIV16 MOVE.W S2,D6 ;FETCH S2, X2 002548: 38381902 313 MOVE.W S1,D4 ;FETCH S1, X1 00254C: 3A04 314 MOVE.W D4,D5 00254E: BD45 315 EOR.W D6,D5 ;D5, BIT 15 = SIGN 002550: 3E3C1FFF 316 MOVE.W #$1FFF,D7 ;MASK TO D7 002554: C847 317 AND.W D7,D4 ;MASK S1 002556: CC47 318 AND.W D7,D6 ;MASK S2 002558: 06461000 319 ADDI.W #$1000,D6 ;ADD OFFSET 00255C: 9C44 320 SUB.W D4,D6 ;X2 - X1 321 ; 322 ; TEST THE SUBTRACT FLAG 323 ; 00255E: E24B 324 LSR.W #1,D3 ;FLG TO CY 002560: 6406 325 BCC DIV17 ;IF FLG CLR 326 ; 327 ; SHIFT THE CY LEFT INTO THE RESULT'S MSB 328 ; AND SHIFT THE RESULT 1 BIT RIGHT. 329 ; 002562: E290 330 ROXR.L #1,D0 ;-- SHIFT MANT ONE 002564: E291 331 ROXR.L #1,D1 ; BIT RIGHT -- 002566: 5246 332 ADDQ.W #1,D6 ;INCR EXPONENT 333 ; 334 ; NOW ROUND THE MANTISSA UP IF NECESSARY 335 ; 002568: 4A41 336 DIV17 TST.W D1 ;BIT -1 SET? 00256A: 6A10 337 BPL DIV18 ;IF NOT 338 ; 00256C: 068100010000 339 ADD.L #$10000,D1 ;ROUND LSB UP 002572: 6408 340 BCC DIV18 341 ; 002574: 5280 342 ADDQ.L #1,D0 ;INCR HI LONG WORD 002576: 6404 343 BCC DIV18 344 ; 002578: E290 345 ROXR.L #1,D0 ;MANT $800... 000 00257A: 5346 346 SUBQ.W #1,D6 ;DECR EXP 347 ; 00257C: 4A46 348 DIV18 TST.W D6 ;TEST EXPONENT 00257E: 6B00FE0A 349 BMI RZER ;IF UNDERFLOW 350 ; 002582: BC47 351 CMP.W D7,D6 ;OVERFLOW ? 002584: 6200FDFE 352 BHI OVFL ;IF OVERFLOW 353 ; 002588: 02458000 354 ANDI.W #$8000,D5 ;MASK ALL BUT SIGN 00258C: 8C45 355 OR.W D5,D6 ;ADD SIGN TO EXP 00258E: 4841 356 SWAP D1 002590: 31C61902 357 MOVE.W D6,S1 ;S1, X1 002594: 21C01904 358 MOVE.L D0,S1+2 ;MANT B47-B16 002598: 31C11908 359 MOVE.W D1,S1+6 ;MANT B15-B0 00259C: 4E75 360 RTS ;DIVIDE DONE 361 ; 362 ; THE MANTISSAS WERE EQUAL 363 ; 00259E: 7200 364 MANTEQ MOVEQ #0,D1 ;(CLR.L D1) 0025A0: 7000 365 MOVEQ #0,D0 ;(CLR.L D0) 0025A2: 7601 366 MOVEQ #1,D3 ;SET SUBTR FLG 0025A4: 609E 367 BRA DIV16 ;EXIT VIA DIV15 368 ;