Issue # 31 DTACK GROUNDED Newsletter - May 1984
SANTA ANA SQUARES?
We find ourselves here on this lightly lit stage in a large auditorium, facing an array of cubicles five wide by five high. The cubicles are closed on the sides, top, bottom and rear. In each cubicle is a critic. Each critic can see only himself and us, but we can see all 25 critics.
The critics are being critical about the direction we are taking HALGOL. Each is pointing in the direction HE wants HALGOL to go. No two critics are pointing in the same direction; indeed nearly every alt-azimuth is represented. If we could remove the cubicle boundaries, all of the critics could see the lack of agreement among themselves, have a good laugh, and then go home. But we can't remove those boundaries and so each critic can only see us and can see that we are not moving in the direction desired by the critic.
This failure on our part to move HALGOL in the direction desired by the particular critic produces
Page 1, Column 2
(depending on the critic) resignation, despair, frustration and even anger.
We discovered a while back that nobody who has a thin skin should be a newsletter editor. But we are having to dodge a larger number of missiles than usual lately, almost all over the subject of the direction of HALGOL, and it is getting to us. We can tell because today, only ten days after putting the last newsletter to bed, we discovered we had written on this subject TWICE (this makes three times). We are leaving both expositions in the newsletter so that you folks will have the benefit (?) of OUR point of view.
While we set up this here camera and tripod, let us explain to you that all it takes to produce a programming language is hard work and lots of money (most of you would be shocked if we told you how much money we have already invested in HALGOL). All 25 of you out there in those boxes are freely offering (a couple of you are DEMANDING) to help us expend OUR money and OUR hard work, hmmm? THERE! The camera is all ready.
Would each of you now point in the exact direction you want HALGOL to go? Thank you. Will the two of you who have been most demanding clench your other fist? Good. Hold one moment now. Special effects: strip off all their clothing! CHEESE, EVERYBODY! Thank you. You will find your clothing in your cubicle behind you.
Now, if you guys (not one gal in the bunch) don't lighten up a bit and stop trying to put your greedy paws on OUR investment and OUR hard work, we are going to print this photo in a future issue.
Page 2, Column 1
SURPRISING MEMORIES.
Let's face it, some folks are a lot smarter than some other folks. A strong contender for the title of 'World's Smartest Publisher' would be David Bunnell. You will recall that David asserted last year that Commodore was in trouble. Since that assertion came before, during, and after an unbroken succession of record quarterly sales and profits by Commodore and during a time when Commodore was growing at the rate of 2.3 times a year, compounded, David obviously knows something that the rest of us dummies don't. Proving that he possesses nearly limitless shrewdness, his editorial in May '84 PC World expresses SURPRISE that many PCs now have 256K of memory!
Let's see now: the runaway smash-hit winner this past year in the PC software arena has been Lotus' 1-2-3, no? And 1-2-3 really needs 256K to be really useful, yes? Naturally, it should come as a surprise to a publisher of a PC-related magazine that lots of PCs now have 256K of memory!
As the memory size in personal computers rises, a dilemma is becoming increasingly apparent. That dilemma is based on the fact that the Intel line of microprocessors are spectacularly ill-suited to work in memory spaces larger than 64K.
You will recall our repeated assertions that Microsoft's Bill Gates is no dummy when it comes to software. It has finally surfaced that Microsoft's continued refusal to expand it's industry-standard BASIC into the new, greater-than-64K world is deliberate. Microsoft will not produce an over-64K BASIC for the PC because it would be ungodly SLOW using those crippled Intel micros! (May '84 80-micro, p.92)
Nearly two years ago (issue #11 p.7) we pointed out that memory has historically doubled every 18 months. If today's correct mass-market memory size is 256K then three years from now the correct size will be one megabyte. Just as today's cheap vanilla Intel micro is the 5MHz 8088, three years from now the cheap vanilla Intel micro will be the 8MHz 80186.
The 80186, a part which maintains architectural and instruction set compatibility with yesteryear's 8080, has very good performance inside 64K boundaries but is a miserable failure when attempting to work with larger memory spaces. (Incredibly, Intel's 32-bit iAPX 386, now under development, will continue the Intel tradition of 8080 compatibility.)
On the other hand, Motorola's cheap, vanilla micro three years from now will either be the 12.5MHz 68000 (available across the counter for two full years now) or something even HIGHER in performance.
Page 2, Column 2
Whether Motorola's cheap, vanilla micro three years from now is the 12.5MHz 68000 or something better, we can be assured that 1) that product will be software-compatible with the 68000, which has now been around for 3 1/2 years and is gathering software support and will THEN have been around for 6 1/2 years and will THEN have MASSIVE software support, and 2) that product will not be busted by being forced to be architecturally compatible with a (then) 13 year old 8-bit micro, and 3) that HALGOL will be able to work easily and naturally with memories in the megabyte range (we suspect this will be true of most other 68000 software as well, naturally).
Intel is today's clear and obvious leader precisely because it has maintained historical continuity with the 8080 architecture and instruction set and hence has a lot of software (developed for 64K memories) to back it up. Motorola is lagging today because it made a decision to break loose from compatibility with 8-bit micros and had to begin from point zero with respect to software support. (Motorola's original and incredibly naive plan to withhold the 68000 from the mass-computer marketplace exacerbated this situation for a while.)
In another three years the 68000 will have a solid, in-place software base and NONE of that software is going to be limited in any way by arbitrary memory restrictions or 8-bit compatibility. The folks with those megabyte Intel machines are going to be spending a lot of time worrying about "What SEGMENT am I innnn..." and worrying about the very substantial performance degradation associated with 64K segment limitations (will Microsoft EVER write a larger-than-64K BASIC for the Intel line of micros?).
It has been nearly a year now since we predicted an explosion of sales of 80186-based personal computers (#21, p.3). Well, Intel now has orders on hand for TEN MILLION 80186's! Since all those orders were (ahem!) totally unexpected, Intel is only going to be able to produce ONE million 80186's this year, a shortfall equal to 90% of the demand.
Because Intel failed to foresee this huge demand for 80186s and hence failed to prepare adequate production facilities, the market window for those 80186-based products has narrowed substantially. The market window for the 80186 (and other microprocessors with 64K limitations) is going to slam shut when it becomes general knowledge in this industry that segmented micros are useless in one-megabyte single-user personal computers. And that is going to happen three years from now because in three years everybody is going to HAVE one megabyte in their personal computer.
As the old saying goes, the handwriting is on the wall for those who can read it.
Page 3, Column 1
CASH COW EATS RIFLE!
You will recall that Peanut, aka PCjr, was described by the Wall Street Journal as "a rifle pointed at Apple Computer's cash cow, the Apple IIe." You will also remember that we concurred with that assessment. Well, the cash cow just ate the rifle. Let us relate a phone conversation we received yesterday from an IBM supporter:
"I realize that we are talking about a statistical distribution of just one unit, but (censored), I have had THREE keyboards so far and not one of them works properly. The second keyboard came with a warped case that did not even fit together properly! I have had to return two defective parallel adaptors. I have had to replace the disk drive once.
"IBM is simply going to HAVE to do something about that keyboard! It is simply NOT ACCEPTABLE! I know that Teledyne makes the PCjr - someplace in Tennessee, right? - but it has the IBM logo and IBM cannot permit its reputation to be ruined by something like this!"
INFOWORLD WATCH:
InfoWorld reports that PCjr sales are real slow and that a shortage of Apple IIes is developing. It seems that lots of folks are walking into Computerland with a handful of cash to buy the PCjr and are walking out with IIes. Like we said, the cash cow has eaten the rifle. Why? Because IBM deliberately busted the PCjr with that lousy keyboard, the unexpandable memory, and only one disk drive! Apparently the keyboard is busted better than they planned. Why bust the PCjr? So it won't impact sales of the PC.
Oh, yes: about how the PCjr got busted. In the italicized sentence in the above paragraph, does the description of how the PCjr got deliberately busted remind you (except maybe for the keyboard) of any other current offering from any other personal computer manufacturer?
CHINESE CHESSBOARD II:
We have consistently been reporting that the personal computer industry is more than doubling every year. Since lots of respectable forecasters use a much smaller figure, like maybe 60% per year, you may have worried about the accuracy of our assertions. Well, InfoWorld's interview with Wayne Green included this item:
"...look at what has happened. Looking at the sales for 1975 and projecting it through the nine years since then, we've had a growth of 260% per year, averaged over the nine years. I don't see any end to that."
Page 3, Column 2
ANOTHER 68000 U.T.H. BD.
Stellation II, the makers of 'the Mill' 6809 board, have joined the 32-bit register camp with a very cheap 68008 board. It costs only $229 and has absolutely no ROM or RAM on board (what do you expect for $229?). Incidentally, if you will rush down to your local Hamilton/Avnet dealer, they will sell you up to 5 ea 68008s for $12 apiece... looks like we are going to have to check the new list price for the 68000s.
In the fall of 1981, Jeff Mazur printed a review of the Mill in Softalk magazine, revealing that in several benchmarks the "performance improvement" obtained by using the Mill was NEGATIVE! As we were telling Jim Hines of Stellation II the other day, it required the utmost restraint on our part not to refer to the 'Mill' as the 'Millstone'! But we never did, did we?
But now Jim is in our camp and gets to answer questions like, "Since your $229 board uses a 68000, surely I get UNIX, LISP, FORTRAN, and C with the board? I DON'T? What the hell is your 68000 board good for if I don't get UNIX, LISP, fortran, and C?" Welcome to the wonderful 68000 world of infinite expectations, Jim!
PRAISE A THIEF?
To take something which legally belongs to another is commonly regarded as theft in this country, even though it might technically be called copyright infringement - as when someone light-fingers the ROM code in the IBM PC. In a recent PC World which reviews 40 - count 'em, 40 - IBM PC clones, PC World is careful to point out that it is not legal to actually copy the ROM in the PC. They then review those 40 clones, reserving the loudest praise for those clones which have most closely approximated an actual PC! We can imagine the following scenario:
David Bunnell is giving a talk to a roomful of folks who build or are planning to build PC clones. He points to a full-size artistic rendition of a manufacturer: "Gentlemen, this mock-up represents a thief, one who has actually copied the IBM PC right down to the code in the ROM. Naturally, none of you would like to be regarded as a thief. But you should know that the closer your actions are to what the thief did, the more praise and promotion your endeavor will receive from PC World. Now, let's all of you get out there and see how closely you can approximate a thief!"
Naturally, the above scenario is fictitious. To the best of our knowledge, David Bunnell has never suggested that anyone approximate a thief. What he HAS done is encourage clone-makers to 'closely adhere to the industry standard for the PC'. You can see the difference. You CAN? Would you explain it to us?
Page 4, Column 1
MORE IBM COMPATIBILITY:
The Corona (Data Systems) and the Eagle are among models which have been, up to now, rated as VERY compatible with the IBM PC. Well, they should be: it seems both companies have agreed, in court, to stop copying IBM's ROM! In the Mar 24 L.A. Times business section is a report that IBM filed a suit on Feb 21 against Eagle over ROM-copying and that Eagle signed a consent decree the same day. Following is a quote from the story, bylined Paul Richter, Times Staff Writer:
"(Eagle) initially said it expected no decline in orders while it interrupted shipments to rewrite the program. But while shipments were delayed between Mar 6 and Mar 23, many major Eagle customers delayed orders as they waited to see whether the redesigned computers would be able to run a high percentage of IBM software, the company said."
In other words, much of Eagle's past sales success has been due to the fact that it VERY, VERY CLOSELY (ahem!) approached acting like a thief... Having made a profit of $457K in the 4th calendar quarter of '83, Eagle is now forecasting a $7-$9 million loss in the 1st quarter '84. Tsk!
One might almost think that it's not a good idea to infringe IBM's copyrights. It is also not a good idea to be making an even slightly incompatible PC clone when IBM's production capacity catches up to demand, which has now apparently transpired for the PCjr, the PC and the PC/XT. Eagle isn't worried, though. That same Times story reports:
"An Eagle spokesman, however, denied that IBM's increased production has crimped Eagle sales, insisting that Eagle computers are not sold primarily because they mimic operations of the IBM Personal Computer." Ho ho ho.
IBM PC PRICING:
Heck, we agree with Eagle that IBM PC availability won't affect Eagle sales. For instance, on p.8 of the same day's Sports Section, there is a 256K PC advertised for sale with two 320K disks, a color card and monitor for $2595. [Micro Business Computer Center in Lawndale, (213) 370-1577.] Now, wouldn't you rather buy an Eagle which is evidently gonna get a lot less compatible with all that software out there real soon?
Compaq, until now the most successful of the PC clone-makers, just took a look at IBM's new portable PC and immediately dropped their price $500. Shakeout? Naaah. Those clone-makers will continue to do as well as when you had to wait 3-6 months for your PC or XT. Sure they will.
Page 4, Column 2
QUANTUM LEAP:
"No modesty has been exercised by Sinclair Research in the naming of their latest computer which they have called the QL for Quantum Leap." is the opening sentence the QL product bulletin in Mar '84 Wireless World, the British electronics mag. WW, by the way, has decided that the 68008 microprocessor is an 8/16/32-bit device. Nothing like playing it safe, one supposes. Here is more:
"Sinclair have designed their own operating system, called QDOS, although no discs are involved. QDOS is a single-user, multi-tasking system which has the ability to run several programmes concurrently and to display the results simultaneously in different windows on the screen. The operating system uses a new version of Sinclair BASIC, called SuperBasic, which is claimed to be so superior to 'normal' BASIC as to constitute a different language. It has the ability to define procedures written in individual blocks. A 'constant execution speed' is claimed, that does not get slower if a program is longer."
If WW and Sinclair were American, the first four words of the paragraph above would be "Sinclair has designed its". Judging by the latter half of the paragraph above, we are not the only folks to see that lots of internal resources in the 6800X permit a substantially superior BASIC to be written. The fact that HALGOL does not operate concurrently is purely a matter of individual preference on the part of the dummy, er, erudite scholar who is defining the language.
The same issue of Wireless World carries the first installment of a construction article using the 68008, so we will have to take back what we said about WW exclusively featuring the Z80. On the other hand, the author is a Motorola employee...
The more we read about the Sinclair QL, the more we are convinced that the machine is ideally suited to the American marketplace. But we said that already, didn't we?
A T & T woos INMOS:
Although this is not a new story it is an ongoing one and bears directly on the future, if any, of the Transputer. It seems that Maggie Thatcher has decided that enough British taxpayer's money has been poured into INMOS and that it will have to get by on private financing in the future. A T & T has now made several offers to purchase INMOS outright, all of which have been turned down.
A T & T wants the in-place and operating wafer fab facilities to produce DRAM for in-house consumption and
Page 5, Column 1
has no interest in continuing to finance INMOS development of proprietary products (read: the Transputer). INMOS continues to insist that continuing development of the Transputer be assured, and has repeatedly turned down the several tenders by A T & T for lack of such assurance.
But the courtship continues because INMOS desperately needs additional capital and A T & T DEFINITELY (if not desperately) wants those in-place and operating wafer fab facilities. Not too many folks (or companies) have the kind of cash that A T & T has and that INMOS needs. As in any courtship, the question is which side is gonna give in...
Odyssey's Trash-68:
You will remember the Trash-68 that Odyssey, a division of Magnavox/Philips, was developing in an attempt to meet the '83 holiday season? Well, software wasn't the only reason it was not ready. It seems Motorola will not have the two-chip graphics controller which was a part of that package in mass production until late '84. Look at the good side: the complete chip set should (then) cost closer to $70 than the originally forecast $150 assuming they are going to use the 68008 instead of the 68000.
In the meantime the Odyssey division has been closed down, apparently permanently, except for 40 staffers who were transferred into a brand-new division - Philip's Home Information Systems Division. While Philips has declined to reveal how that new division fits into the North American Philips corporate chart, you and we know that 40 persons is about the right size for a new home-computer development team, and that the Philips Trash-68 design effort has been under way for almost two years.
Please note that it is "PhiLips", not "PhiLLips".
THE TANDY 2000:
We received our Model 2000 on the same day that newsletter #30 arrived from the printers. First the good news: the hardware and graphics are superb. With color you worry about fuzziness and how sharp and readable the text will be. No problem at all.
In graphics, things are relative. The 2000's graphics have 4 1/2 times the number of pixels as the Apple II's HIRES screen, but over three times fewer than a VDHR board set! When we say the graphics are superb, we are saying that the 640 X 400 pixel 8-color non-interlaced monitor and graphics system used by the 2000 are at least as good as a person could reasonably expect at the price and maybe even better.
Page 5, Column 2
The disk transfer rate is about the same as our Eagle II, which is a single-sided version of the drives used by the Model 2000. If you are accustomed to Apple IIs, that transfer rate is very fast. For you CP/M folks, the transfer rate is vanilla single-density 8 inch or double-density 5 1/4 inch. (The Eagle III is essentially the exact equivalent of the 2000 where floppies are concerned. Why don't we have Eagle IIIs instead of our IIs? Eagle Computer has the quaint idea that adding a second side to the two floppies adds $1000 to the value of the computer!)
The bad news is that the editor used by GW BASIC is written in C and is slow on slow on slow. The BASIC uses this same editor to print to the CRT, so any printed output running under BASIC is painfully slow to watch. In fact, we first thought we had one of those infamous busted-BASICS. Not so; everything but the editor and the output runs swiftly. Terry Peterson's benchmark runs in 68 seconds using single imprecision (double precision transcendentals are not available). While that is slow compared to HALGOL at 18.6 seconds running genuine double precision, it is pretty fast compared to lots of other personal computers.
That crummy editor and the lack of double precision transcendentals is about all we can say about the 2000 that is bad. (We understand the IBM PC has that same crummy editor and that the standard BASIC also lacks double precision transcendentals.) This looks to us like the first desktop personal computer that Tandy has ever made that could be competitive outside Radio Shack. We think the 2000 could sell in Computerland.
WHERE'S THE BEEF?
Proving that we are as willing to jump on a cliche as the next guy, the UNIX bun (product announcements) is swelling to massive proportions. We have here THE BUN THAT ATE KANSAS, MONTANA AND ARIZONA! (Geography was never our strong point.) In the meantime there ain't no beef (customers) to go with that bun. Ron Jeffries, in his latest newsletter, has fallen into the trap of gushing praise over some more (sigh) UNIX product announcements! Maybe he ought to read his own newsletter a couple of issues back where he noted that UNIX customers were mostly absent?
According to the morning paper, A T & T is scheduled to announce three new UNIX systems today, all in the 3-B series. It says the 3-B20 is the biggest and sells for $230,000. The smallest is the 3-B5 which sells for $57,000. Our heart is suddenly pounding! Our blood is rushing hotly and we are concentrating with feverish intent! Have we caught the UNIX product announcement fever? Is the attractive young lady across the street going to stop bending over like that? (We are typing this in our study at the front of our house.)
Page 6, Column 1
No, do not assume that nobody would be dumb enough to pay $230,000 for a UNIX system. In fact, A T & T has sold 500 of them already! All to an uncompetitive, guaranteed-profit monopoly called, um, A T & T...
A REQUIEM FOR O.T.:
With great sadness we lay the title 'Otherwise Intelligent' to rest. The guy who favored the Nat Semi 16032 over the 68000 but was Otherwise Intelligent no longer seems to favor the 16032, so we cannot in good faith continue to apply that cognomen to him. Well, 20 months is time enough to come to one's senses.
MASTERWORKS DEPT:
ACT of Great Britain has just negotiated a buy-out of most of Victor Technology's inventory. We have opened negotiations through a director of ACT (this is the truth) to purchase the famed organizational chart of the former 500-employee Scotts Valley manufacturing facility. The famed organizational chart is said to feature a block at the top labelled "Chuck Peddle" from which 499 lines emanate directly to each of the other employees of the plant.
TRUTH DEPT:
Yes, Truth with a capital T. It is possible that you have had the good fortune never to encounter the IBM (PC) Tech Journal. In its Feb '84 issue, on p.36, it lists the annual (1983) sales of various personal computer manufacturers. Commodore is listed at only $800 million, which is going to surprise the heck out of both Kindly Uncle Jack and also Commodore's independent auditors, both of whom are under the impression that Commodore sold $1 billion in 1983.
On the same page, it is predicted that in 1984 IBM will take 1st place in under-$1000 personal computer sales with Coleco moving into 2nd place ahead of Commodore. Your FNE is looking hard for the guy who made that prediction. We have some swamp acreage in Florida, we have a couple of spare bridges and we are setting up a table-stakes poker game using OUR cards!
SICKLY PEANUT?
What's that, Bunky? Your PCjr gives you weird, random disk errors? It thinks you're pressing the keyboard even if you happen to be across the room? Your problem, Bunky, is that you are not paying attention.
Check out any IBM advertisement, promotional photograph, or even TV ad for the PCjr. Where is the console, which contains the disk drive? Good. Now, where is the monitor? At least a foot away, right? Now, Bunky, where is YOUR console? On your desk, you
Page 6, Column 2
say? Now, where is your monitor? On top of your console? SHAME, Bunky! The monitor isn't shielded and neither is the console. In fact, the PCjr manual TELLS you that in the fine print at the bottom of page 'leventy-seven.
Just remove your monitor from the top of the console, Bunky, and move it a foot away. What's that? You say that doubles the space the unit occupies on your desktop? Well, Bunky, that's just the way the Peanut-butter cookie crumbles...
FNE MAKES MISTAKE:
Yes! Your FNE has (gasp!) made an error. We received this here anonymous phone call which opened up, "You made a serious error in your last newsletter. Microsoft's Multiplan for Mack is not either busted in C." But we checked that story three ways, we protested. We are SURE it is busted in C!
"No", the caller insisted, "it is not either busted in C. Multiplan for Mack is in fact busted SQUARED in INTERPRETED C! So is the Multiplan which runs on the Apple II, for that matter. You see," the caller explained, "if you really want to have a worthwhile program instead of just a toy, 128K just isn't enough memory to work with. The only way to sufficiently compress the code is to use an interpreter. For instance, Lotus was doing 1-2-3 for Mack in C, but Lotus COMPILES their C to native code. That's why Lotus has stopped working on 1-2-3 for Mack until Mack grows into 512K."
We guess we will have to take back what we have been telling our readers all along about our infallibility. Sigh. If you can't believe your FNE, who CAN you believe in?
ONCE UPON A MATH CHIP:
A newsletter editor once decided to have his two hardware type engineers develop a math processor peripheral using the Nat Semi 16081 for his 68000 attached processors. As you can read on pages 12 and 13 of his newsletter #22, a 'game plan' was devised toward this end. The (then) young project engineer (who has matured considerably since) read the 16081 spec sheet and noted that it was an asynchronous part. "I will interface the 16081 asynchronously!" exclaimed the (then) young project engineer.
The other project engineer, a fading dour pessimist, growled, "Spec sheet or no spec sheet I'll bet that part has to be interfaced synchronously. Let junior over there take his shot and then I'll show him how it's done!" Meanwhile, the newsletter editor planned to use the 16032 to drive the math chip, just in case.
Page 7, Column 1
So a prototype was constructed, which is pictured on the front page of newsletter #24. It used an asynchronous clock, and worked correctly about 9,999 floating point operations out of 10,000. The (then) young project engineer improved the grounds, the +5 bypassing, he buffered the clock, he tried slower clocks. The prototype continued to work, 9,999 times out of 10,000. The fading dour pessimist suggested using the same clock as the 68000, only divided in half. The system then worked 10,000 times out of 10,000 tries.
A second, somewhat improved prototype was constructed, and is pictured on the front of newsletter #25. The two project engineers continued to learn more about the exact way the interface worked and which parameters were critical, but every attempt to use an asynchronous clock for the 16081 worked - 9,999 times out of 10,000. The newsletter editor reported the need for a synchronous clock on page 25 of issue 25. That issue also carried a schematic of a 16081/68000 interface.
You may find this hard to believe, but a photocopy of portions of newsletter #25 somehow found its way to Nat Semi headquarters in Silicon Valley. Here is an excerpt from a phone conversation which took place between the newsletter editor and someone at the Nat Semi plant in Nov '83:
"You have an interesting writeup, but of course YOU. ARE. WRONG. about the synchronous clock." The newsletter editor tried to explain the many ways his project engineers had tried, unsuccessfully, to make the 16081 work asynchronously. But the guy at the other end talked a lot better than he listened. He explained, "WE. HAVE. THE. MOST. SOPHISTICATED. AND. EXPENSIVE. TEST. GEAR. THERE. IS! And, OUR. TEST. GEAR. PROVES. CONCLUSIVELY. THAT. THE. PART. IS. ASYNCHRONOUS." End of 'conversation'.
An excerpt from another phone call in Jan '84: "You know, a couple of us here at Nat Semi now believe that the 16081 is really a synchronous part, not asynchronous. But we are having a heck of a time getting the chip boys to listen to us!"
An excerpt from a call to the Nat Semi headquarters in Mar '84: "WE. ARE. TOO. BUSY. TO. SPEAK. TO. YOU. NOW. Our MOST. SOPHISTICATED. AND. EXPENSIVE. TEST. GEAR. IS. BUSY. RE-CHARACTERIZING. THE. 16081. AS. A. SYNCHRONOUS. DEVICE." Noooo! the newsletter editor answered...
Traditor!
A little over a hundred years ago, as a large construction project in Africa drew to a close, preparations were made for a celebration. Joe Green,
Page 7, Column 2
one of the foremost composers of the time, finally agreed to produce an opera for the occasion. (His decision was influenced by several sacks of gold.) Since this was to be a 'grand' occasion, a 'grand' opera was needed.
In those days the size of an opera house was limited to that which could be covered by the leather-lunged singers or bellowers (depending on your view of opera). 'Grand' opera implies a large cast, with things happening on a grand scale. But if you have lots of singers, you have a chorale, not an opera. What to do?
Joe Green produced a 4-act grand opera of such scale that today that opera defines the term 'grand opera'. He accomplished this with utmost economy: in Act 1, Scene 1 he (well, the King) sends our hero off to war with the admonition to 'return a conquerer (ritorna vincitor)"! (What else? Go out there and lose?)
Unhampered by television reporters, our hero does his thing so we have (what else?) a victory march. Here Joe Green pulled out the stops. Trumpeters, elephants, a veritable army carrying spears, a horde of prisoners march across the stage ('Triumphal March'). 'Grand' opera indeed! (The term 'spear carrier' derives from this opera.) However, this is only Act 2 - with two more acts to go our hero is, as you might have guessed, in for big trouble!
Act 4, Scene 1: our hero, having fallen into disfavor, is tried by the priests (any time priests get to be judges, the defendant is in big trouble - whether in today's Iran, the Spanish Inquisition or this opera). Our hero is repeatedly urged to 'justify yourself!' (discolpati!). Failing to do so, the priests repeatedly cry out, 'Traitor!' (Traditor!). In this scene, our hero is called a 'traitor' 13 times - a number which proves unlucky for him.
We received a letter yesterday from a Sage dealer which opened by repeating, we kid you not, "Traitor." exactly 64 times! He has been urging us to get a 68000-based Sage, a personal computer with no graphics. And we have the nerve to buy a Tandy 2000, with very good color graphics! Traitor indeed! The Sage dealer even closed with a curse: "Your punishment is to program in 8086 assembly language for as long as you may continue to live!" Now, that's downright nasty!
But his letter immediately brought to mind that opera and the trial of our hero by the priests. As most of you have figured out, the opera is Aida, Joe Green's name in Italian is Giuseppi Verdi and the large construction project was the Suez canal. Naturally, the premiere performance was not held until Christmas Eve 1871, long after the canal was opened for traffic. Well, compositions are a lot like software, no?
Page 8, Column 1
WE GET MAIL:
"Thanks for the latest issue [#29], now forwarded to legal and goon squad department of Rex Malik Ltd. for appreciation (do you know what Malik is Sicilian for?)." Julian A., Goring England
Gulp! We were just kidding! - FNE
"Thank you for the HALGOL (source) disks and documents - I haven't had the time to test it a lot, but it really seems to be a speedy implementation. Unfortunately, I have some bugs to report which I have found in your HALGOL floating point routines." Ulrich S., Aachen W. Germany
Er - oh, hi there, Ulrich! you happened to have caught us in the middle of a hardware design. How do like this T-shirt with the "HARDWARE DESIGNER" logo? Or the sign over our desk which reads "HARDWARE DESIGNED HERE"? Or the sign on the door to our office which reads "FNE: FAMED DESIGNER OF HARDWARE"? No, don't touch the sign, the paint is still wet.
Since we are a hardware designer, we obviously cannot be held responsible for any dinky little software bugs in our floating point package. In fact, we fixed one recently after Eric E. pointed out the problem, which was in the square root routine. You see, the argument is reduced to the range
1 > argument >= 1/4which should logically result in a square root whose range is:
1 > root >= 1/2.Unfortunately, for the largest number whose value is less than one, which has the hex representation
$1000 FFFF FFFF FFFFthe square root (correctly) rounds up to one, a result which we had not anticipated. Thus the exponent was $1001 at a time when we anticipated an exponent of $1000. This required the addition of two assembly instructions at the very end of the square root routine, as you can see by comparing the HALGOL source printout with the code in #16 REDLANDS. Still, the old code was correct about
99.9999999999999%of the time and incorrect about
0.0000000000001%Page 8, Column 2
of the time. The floating point multiply and divide routines are obviously heavily used in the various transcendental calculations, which we spent about 200 man-hours testing against known good result tables, 2,048 results/table. One suspects that really gross errors would have surfaced by now.
Most of the "bugs" you point out involve the calculation of the floating point exponent, and thus would result in an error by a factor of two or more. Now, we do not doubt that there might be a bug or two in our floating point code - we are a hardware type, remember? - but we have not encountered gross errors (except for the square root bug noted above). Could we persuade you to give us examples of particular arguments which do not provide the correct result?
The strange repeated code at the start of CLET flags particular errors which might occur during compilation. If you suddenly get a register dump unexpectedly on the CRT just after entering a LET statement, the code in the lower word of D5 will tell you exactly where in the compilation process the error was encountered. We think you should not get such an error (we think the compilation process is debugged), but this is the reason one distributes evaluation disks, no?
[Incidentally, Ulrich, Chet S. is also picking on our choice of divide algorithm. Perhaps we should take a closer look at the use of the hardware divide - we DID use it in the early Microsoft compatible package, if only (we thought at the time) to prove a point.]
COMPUTER APPROXIMATIONS
by Hart et al is now being published by the Robert E. Krieger Publishing Company, Inc. whose address is 645 New York Avenue, Huntington, NY 11743.
HALGOL COMMENTS:
We are now receiving a number of comments about HALGOL, largely because we put a couple dozen evaluation copies on the street for just that purpose. A lot of the comments are totally unrelated to what HALGOL is all about. For instance:
"...take a look at Microsoft's BASIC for the Mac. It isn't fast, but it sure is slick and refined and convenient." Comments of this nature are often followed by an assertion that it is ABSOLUTELY ESSENTIAL for HALGOL to be 'slick, refined and convenient'. Other comments suggest that HALGOL should be (ahem!) EXTREMELY FAMILIAR, which is a refined way of saying "Waah! It's just gotta be exactly like Applesoft!" Yet other comments, from very experienced programmers, propose a laundry list of extremely sophisticated features (naturally!).
Page 9, Column 1
We recognize that all of these suggestions are meant well. Now let us tell YOU what WE think! First, will all of you please note that your suggestions are largely mutually contradictory? For instance, to be 'EXACTLY' like Applesoft tosses out both 'slick and refined and convenient' and 'extremely sophisticated features'? Clearly, there is no way that we can satisfy as much as a small minority of the folks attempting to give us direction.
We can see where folks might want to mold a language to their own desires, especially if they don't have to do any of the work or pay any of the bills. Unfortunately, we do not have that luxury - we both have to do the work and also pay the bills! Therefore, we look at suggestions from the standpoint of cost and time (mostly the same thing) as well as purely theoretical desirability.
Who can argue against 'slick and refined and convenient'? We would rather argue against motherhood and apple pie! Are we going to actively pursue this highly desirable objective? No! We do not have enough money or time or manpower.
What we are going to do is concentrate on making HALGOL A) Fast. B) Interactive. C) Programmable by anyone who can program. D) Refer back to A).
Those are THE objectives of HALGOL and the ONLY objectives of HALGOL. One or two of our less reasonable readers have suggested that to compete with, say, Microsoft's MAC BASIC that we will HAVE to be just as 'slick and refined and convenient'.
THAT'S TOTAL BULLSHIT!
If we thought there was one iota of truth in such an assertion we would close down Digital Acoustics no later than yesterday and put our money in a McDonald's franchise! The entire raison d' etre for DTACK GROUNDED is that speed is worthwhile by and of itself. Look, HALGOL is 34 times faster than Microsoft's MACK BASIC! We firmly believe that a language which is interactive, 34 times faster and programmable by anyone who can program is, without further virtues, competitive on the marketplace. And - unlike the folks who make the most demanding 'suggestions', we are putting our money where our 'mouth' is!
We hasten to explain that MOST of the suggestions we receive are NOT demanding - but some are.
We DO want suggestions which will help us improve HALGOL. This means we want 'bug' reports and we want suggestions to make small improvements and refinements. We DON'T want suggestions to design a completely different language! And we DON'T want DEMANDS!
Page 9, Column 2
(Yes, darn it, we know most newsletters don't carry angry stuff like the above, but about one of every fifteen letter-writers couch their 'suggestions' in the form of demands. And yes, that does make us angry. Remember, we admit to not being a nice person. Question: do the folks making those demands realize what they are doing?)
(Oh, yes: the letter we (partly) quoted was not from a 'demander', but it was from a person who has not always shown a sensitivity to the effort and expense of programming with no offsetting income.)
The following is from a letter dated 21 Dec '83 which we are just now getting around to semi-answering:
"I have decided to check out all the stored constants in your old Microsoft compatible floating point package, since I intend to include it in the next release of Inter68 - bugfree if possible. I have found one definite error and several inconsistencies. Let's start with the LOGK table. Lines 740-741 contain a constant labelled "2/LN(2)". The least hex digit is a 0; it should be an A.
"Lines 734-739 contain 'magic numbers'. Could you perhaps explain how you derived them - otherwise it will be impossible to check them. The constants do not correspond exactly to their respective comments." Ulrich S., Aachen W. Germany
Ulrich, the LOG function was the first one we implemented after getting the basic four math functions working back in Jun '81. Since we wanted to be Microsoft compatible, we chose to translate their algorithm exactly, including the stored constants. The constants in our package are taken right out of the CBM 8032 ROM (see for instance starting at $CB07 the "2/LN(2)" constant. The identical constants are used in Applesoft.
The COMMENTS alongside the constants are our own; we wrote "2/LN(2)" not because the constant was exactly that value but because it was certainly close (incidentally, wouldn't the last hex digit of 2/LN(2) be a '9' when correctly rounded?).
What Microsoft did (we later discovered) was use Hart index 2662 for the calculation of LOG base 2 of X. Unfortunately, Hart index 2662 is for the calculation of the LOG base e of X. That meant Microsoft had to multiply the constants given in 2662 by the LOG base 2 of e, about 1.44. For instance, P02 is given by Hart as .39965794919. After scaling we (and Microsoft) wind up with the constant just above "2/LN(2)", or appx. .9618 as our comment notes.
Page 10, Column 1
Likewise, the ATANK tables are taken from Hart (index 4995); if there is a disagreement between the comment and the constant it is because we had no reason to carefully check the comment itself. (Come to think of it, that code was originally hand-assembled using the Wang 2200 and later re-entered using the PHASE ZERO assembler by a temporary summer employee, a 16 year-old high school student. For instance, in line 1068 we would never have entered "EVALUATER", hmmm?)
Beginning at the bottom and working up, surely you recognize the well-known sequence 1, 1/3, 1/5, 1/7 etc? But the exact values have been diddled to converge to a reasonable approximation with a finite number of terms. When working with Chebyshev approximations, one constantly runs into numbers which are ALMOST exactly like something recognizable!
If you are going to write your own transcendentals, you will need Hart and also the Hayden double precision floating point routines. If you will send us your proof of of purchase (of the Hayden routines) we will send you our modifications which automatically translate and round from the Hayden format to the HALGOL/48 format and the IEEE double-precision format. (This is because Ulrich has done lots of work. Anybody else, it's proof of purchase plus $10 US and Canada or $13 elsewhere.)
This is twice (actually, the FIRST time because of our delay in answering) you have found 'bugs' in our floating point packages, Ulrich. The 'bugs' mentioned in this letter aren't bugs at all! And you have as yet failed to document a single instance of the alleged bugs you have found in the HALGOL double precision package. Would we be out of line to suggest that if you cannot cite a particular example of an erroneous result that perhaps you should send us a short note plus the price of, say, a six-pack of Heineken Special Dark (about $5 in Santa Ana)?
(We are not really picking on Ulrich, who is obviously a highly skilled programmer - much more so than us hardware types. But floating point stuff, and especially the Chebyshev approximation technique used for many transcendental calculations, is very specialized. There aren't many "floating point persons" around. It is amazing that, with Chet Sensenig, there are two such in the tiny DTACK GROUNDED "community".)
"You write, 'No amount of mouthpower can compensate for a lack of sales. There is no place for PASCAL in today's marketplace.'
"WRONG, as usual. I can not understand your penchant for lording your ignorance over your readers. So often
Page 10, Column 2
you regale in blatant stupidities and strut your ignorance like a woman with a new skimpy swimsuit. I have no doubt you will ignore the enclosed piece of evidence since it contradicts most vividly your prejudices." John B., Burlingame CA
(The enclosed evidence is a clipping which asserts that Turbo PASCAL has sold 20,000 copies at $50 each in 5 months. John points out that this is $1 million and then asks, How much have you made in the last five months?)
John, Borlund has SOLD - not MADE - $1 million in five months. That is about three times our current sales rate, or perhaps a tad less. If you think we are going to knock Borlund, you have another think coming. We have heard nothing but good about that company and about Turbo PASCAL. Even Jerry Pournelle had nice words for Turbo! The reviews say it compiles fast and runs fast, just the sort of qualities which we admire. O.K., so you gotta do the source code - compile - rewrite stuff, but what the hey...
At $50 (well, $49.95) we think Borlund has turned out a product which is aimed at PASCAL's original purpose - a teaching language. As soon as they have an Eagle II and/or a Tandy 2000 version we will buy it - as a learning tool. There are about 2.5 million, as a conservative estimate, computers now running CP/M or MS-DOS or PC-DOS, and Turbo PASCAL is available for some configurations of each of those operating systems. On the other hand, we understand that Turbo PASCAL is non-standard and hence unportable.
Why do we suspect that a big percentage of those 20,000 copies were sold for the same reason we will buy one or two eventually - as a learning tool? Come to think of it, the second sentence which you quoted from our last newsletter is clearly wrong, now that we look at it again. There IS a place for PASCAL in today's personal computer marketplace - as a learning tool! Which is, of course, what the language was designed for.
Glad to hear you're picking up a Mack. We may be offering HALGOL for the Mack next spring for about $49.95. Will you make a small contribution to our corporate coffers at that time? Oh, yes: in the future, do not be so reticent when writing us - go right ahead and 'speak out'! - FNE
P.S.: how many of those 2.5 million CP/M or MS-DOS or PC-DOS computers run BASIC? How many personal computers which do not have BASIC are doing well in the marketplace? How many which do not have PASCAL?
[Your FNE wishes it placed into the record that he has no objection whatever to women strutting, sashaying or just sauntering in skimpy bathing suits.]
Page 11, Column 1
APRIL FOOL:
This is being written on the morning of April 2, and we nearly O.D.'d on the April 1 stuff in yesterday's L.A. TIMES. We happen to like a well-done spoof no matter what the time of year, such as the ones which have regularly poured out of National Semiconductor. How many of you remember the WOM, a write-only memory suitable for archival records and highly classified information? Or the Darkness Emitting Arsenide Diode (DEAD)?
A few years back, Nat Semi had a new product release printed in one of the trade hardware magazines (EDN, we think). The new product, a battery discharger, was described in fine detail including its melting temperature, etc. Upon reading the spec sheet closely, it became evident that the release described an XCELITE # so-and-so flat-bladed screwdriver. But the product release was really very well done.
Naturally, EDN received an irate letter denouncing the high-tech product release, angrily pointing out that a flat-bladed screwdriver would be just as effective and a lot simpler and cheaper. One imagines that the editors huddled to discuss how to handle the letter. They wound up printing it without comment, appending the writer's full name, employer and city! Now, that was cruel!
In the last issue (#30, p.18) we poked a little fun at David Bunnel, who publishes both PC World and Mac World. The headline was "JANUSSARY?". Well, we have just received a letter which points out (correctly) that a "Janissary", with an i, is a loyal follower while "Janus" was a two-faced Roman god. Then the letter asks whether our misspelling was deliberate! No, we are not going to tell you the writer's name or the city he lives in; we have a little more compassion than those EDN editors!
Just to complicate matters, "Janissaries" is the title of a recent novel by Jerry Pournelle, as is "Son of Janissaries". (Oops! Make that second title "Janissaries: Clan and Crown".)
"Having just read newsletter #30 I felt the urge to put fingers to keyboard and express some opinions... Would you PLEASE stop talking like a system type and lay off with the kneejerk put-down of the Commodore 64 as 'not a REAL computer'? (I think the term was something like an electronic doorstop for shooting rocks'.
"...UNIX (again): Since the time I wrote "Why UNIX Is Not My Favorite Operating System [issue #23, pp9-11] I have become a UNIX user. After all, I am a full time professional programmer. I have to say, now, that even with all its problems and pitfalls it is the best thing
Page 11, Column 2
around for what I do for a living. I'm even beginning to like it! After all, I leave it at work. At home I work almost exclusively in FORTH.
"I can't stand modeless editors. I almost never use the full screen editor on my C64 (of course, I almost never use BASIC on my C64 either) because of the many times I have screwed myself up by hitting one too many RETURNs, or the wrong cursor/control key. I guess it's like rodents and electronic disks - you either love them or hate them (as I do). My favorite editor is the one that comes with the UCSD p-system. My least favorite editor is Wordstar (which is almost modeless - there is a different control key for every function).
"The SAT (folks) are idiots, as everybody except themselves realize. It seems that the SAT is really a screening device to see which applicants are sincere enough about college to go out and get an SAT cram book so they can pass the test." Steve McI. Long Beach CA
Whooo! Let's see, now - where do we start? O.K., we will take this one in order: We cut out 2 1/2 pages of Steve's defense of the C-64 because the C-64 does not need defending in these pages. The electronic door-stops we were referring to include the Sinclair ZX-80 and also the ZX-81 (aka Timex 1000) plus the VIC-20, the T.I. 99/4A and a few others of that ilk. The C-64 is a fine design which can do a few useful things and a whole bunch of fun things. If you think you have seen us knock the C-64 in these pages, you are most likely mistaken. We also do not knock the profitability of the C-64. David Bunnel of PC World is the one who knocks the C-64 and the $51 million in 4th quarter 1983 profits it brought Commodore.
Let us extend our congratulations to yet another full-time computer professional who likes UNIX. UNIX days and FORTH evenings? Gadzooks!
Who ever told you the Commodore editor is modeless? We purely HATE the insert mode that our CBM 8032 uses. Like you, we are ALWAYS hitting the wrong key sequence to get out of that #&*%@! mode, which is an important reason why we are making the HALGOL editor modeless! Another reason is the inconvenience of entering and exiting the Apple monitor - something we used to spend a lot of time doing until we built monitor functions right into the modeless HALGOL operating system. You are a UNIX professional who uses FORTH at home and like the UCSD operating system? DOUBLE gadzooks!
The Apollo astronauts were screened by having them soak their foot in (literally) icy water for two hours at a time. It had nothing whatever to do with their proficiency as an astronaut, but it probably DID indicate that anybody who would put up with that silly crap was pretty serious about becoming an astronaut!
Page 12, Column 1
For more details along these lines, read about the "steel eel" in Tom Wolfe's The Right Stuff. Better yet, read Michael Collins' Carrying the Fire, which is in most ways a better book than Wolfe's. (Collins is the guy who rode the Apollo 11 command module in moon orbit while Armstrong made a giant step for mankind.) AND, get this, Collins really wrote his book himself; no ghost-writer was involved. Honest!
"I must have been living under a rock for the past several years because I only discovered your informative and clearly objective newsletter with issue #29." Bruce G., Groton MA
CLEARLY OBJECTIVE? Bruce, have you bumped your head on too many nuclear submarines lately? - FNE
"I can tell by your attitude in the newsletter that the micro world is frustrating you probably more than before. It is amazing how much misinformation advertisers and ignorant columnists can disseminate. With all the lies, halftruths and opinions expressed as facts filling the literature and stores, I am surprised anything is real. Most people I know are getting less and less sure of any opinions they have and are talking more and more vaguely. You are still making sense of most of it and trying to get us poor ignoramuses to see your viewpoint, but it is not easy.
"What I see is a market which just attempted to become static and lost. I think a lot of people were hoping IBM PC compatibility would stabilize it all and we could all feel satisfied and go back to being boring human beings. Unfortunately, most people are not happy being boring and do not want to be stuck with [in?] the IBM womb. Actually, I look at this as fortunate, but the ones who wanted stability don't. If you don't think the IBM PC compatibility issue is dying look to the PC magazines desperately talking about it. This means they hope to keep the ship afloat, since it helps their own sales.
"A backlash is in progress, but since so may people in three-piece suits and business outfits (the women) are involved it is not a civil war. Many dealers have been unhappy with IBM and happy with Apple from a dealer viewpoint, so they are willing to give Apple a chance (Commodore is not sold by computer shops). Also, the Visicalc lawsuits are really making a lot of people think, "wow, Visicalc was the big thing for a long time and now it is not, 1-2-3 will probably be beat and then the machine the competition uses will sell too." This is not to say the Mac is so great, only that it is easy to use and people trust it to have a lot of good software soon.
Page 12, Column 2
"Most people I know do not want IBM to own the market and the compatibles are selling not just for compatibility, but to not buy IBM (which is amazing illogic). Also, too many in the industry know the IBM PC can be beat; Radio Shack is showing how (a lot of people are serious about this one) and Apple is doing everything possible to say the Mac is thirty-two bit and therefore much better. (This is fair play, use the same tactics as the competition did, they called theirs 16 bit.)" Bill J., Richland WA
Bill, we too sense a problem out there and like you, we are having trouble putting our finger on it. We view the personal computer marketplace through our own special prejudices, and here is what our prejudices tell us:
The personal computer marketplace has only four significant participants at this time: Apple II/II+/IIe, Commodore 64, IBM PC and clones thereof and (collectively) the Z-80 CP/M machines. (Mackintosh is not yet shipping in significant quantities.) What jumps right out at you is that not one of these four is even remotely state-of-the-art! Indeed, their performance is very 1977-ish (except for the very few PC programs which support the 8087). We believe that people sense this and are hoping for a White Knight, a modern machine which will lead them out of that antediluvian 1977 swamp.
In 1984 a state-of-the-art personal computer will be based on the 68000 microprocessor (with a peripheral socket for the 16081, maybe). That was also true in 1983, of course, and what we got in 1983 was Fortune and LISA I. State of the art? Like hell! Both were slower than am Apple II! We have here a terrible disagreement between theory (68000 = state of the art) and practice (the Fortune and LISA I were dogs).
One of the things a newsletter writer does is listen (believe it or not). We ask other folks their opinions and then we listen. Even if we talked to someone else on the same subject an hour or a month ago, we listen. On the following subject we have found an amazing consensus. Here is that consensus:
The operating systems and BASIC interpreters, etc, for the 6502s and Z-80s were done in assembly. The programmers cut corners, used special tricks and in general did everything they could to improve the performance of their 8-bit software because that was NECESSARY. Adequate performance could not otherwise be obtained. These programmers knew (or learned later, after their companies had prospered) that they were not programming in a proper manner.
But these same programmers naturally want to write their software properly -IF THAT IS POSSIBLE! Once one
Page 13, Column 1
has a 68000, with lots of registers (16 ea 32-bit registers just like a VAX or IBM 370, in fact) and, get this, FAR MORE THAN ADEQUATE PERFORMANCE, it then becomes possible to program CORRECTLY. Correctly means using a transportable high-level language such as C or PASCAL. And so the folks programming the Fortune and LISA I (and Microsoft's Mackintosh line of software) wrote their programs correctly. Result? The correctly-programmed 68000 machines are all slower (!) than the 1977 machines, which did not have the benefit (?) of being programmed correctly.
Do the folks programming the 68000-based products realize what they are doing, performance-wise? Yes. But, they will earnestly explain, it is much more important for programs to be written properly than that they be fast. Then they excuse themselves, explaining that it is time to disembowel yet another computer on the altar of the golden calf Transportability.
And so, the restive mal-ease of the personal computer marketplace: buyers have a choice of obsolescent 1977-performance computers OR they can choose a MODERN 68000-based machine that is EVEN SLOWER! And those are the only choices available! A pretty box indeed.
This explains the surge of interest that Bill J. has noted in the Tandy 2000. The 2000 is based on the 80186 which is in turn source-compatible (via a translation program) with the 8080A and source-compatible, period, with the 8088. So folks are turning to the Tandy 2000 in a desperate search for more modern performance even though the improvement is much less than 2-1 (vs an 8MHz 8036) or about 2.4-1 (vs a 4.77MHz 8088).
If only someone would put a gun to the head of those 68000 programmers and force them to write BAD, FAST code instead of GOOD, SLOW code then LISA would have been a success and Mack would, once production gets rolling, be enormously successful. As it is, it appears that Mack is attracting mouse fans and others who wish to travel north. Perhaps we are wrong, but we believe that the mass computer marketplace wishes to travel in other directions as well.
And perhaps we are wrong, but we think fast untransportable code is vastly superior to slow transportable code IN THE MASS MARKETPLACE! We are busily writing fast untransportable 68000 code (HALGOL) in an attempt to bring DTACK GROUNDED a step or three closer to the mass marketplace. Let us explain to Bill and to you other readers the full dimensions of our commitment:
In the electronics industry, it is well known that a small or medium-sized company has an overhead equal to its payroll (or double if the payroll is considered
Page 13, Column 2
part of the overhead, as it usually is). In addition to the dollar figure that appears on the paycheck (before deductions) there are lots of hidden payroll taxes most employees are not aware of. Social security, unemployment, disability... Then there is the rent, the electricity and gas bills, the phone bill; liability, fire, theft and flood insurance. Employee health insurance. Property and inventory taxes. Business licenses. Supplies of all kinds. Computers and test equipment and software and technical publications. Furniture. Maintenance and waste disposal. All of these things, as is typical in this industry, almost exactly equal our payroll.
So if you hire a new computer science graduate, one who is not yet mentally locked into the 'correct' may of doing things, it costs the company twice his salary. The same thing applies to other employees who might work on HALGOL such as your FNE. With this in mind, we assure you that we are being completely accurate and truthful when we tell you that during May '84 the investment Digital Acoustics has made in HALGOL (over a 2 year period) will pass $100,000.
Cheap HALGOL is NOT - for us.
"I find it disappointing that you need to stoop to calling the Tandy machines 'Trash-80s'. I expect this kind of thing from 13 year old rock shooters, but I would have expected better from mature adults." John M., Canoga Park CA
John, we - and a lot of others - use that term in an inverted sense. The fact is, as you have noted, the TRS-80 Model 1 was very, very good to a lot of people. We now use Trash-XX now to denote any computer which would do for the present generation of first time users what the Model 1 did seven years ago for the last generation. Please note that we have consistently asserted that this industry desperately needs a Trash-68. We define 'Trash-XX' as being the ideal first computer for somebody who wants to learn about computers (well, maybe a second computer for folks whose first computer was an electronic doorstop).
By the same token, a 'Trash-XX' needs to be very affordable and hence necessarily lacks stuff that more advanced folks like you and we take for granted - disk drives, for instance. A 'Trash-XX' is something you graduate from and then move on to a real computer.
Remember, a 'hacker' originally described German furnituremakers so inept and clumsy that they were said to 'hack' furniture out of logs with an ax! The meaning of 'hacker' has become inverted with time and is now commonly used as a term of respect for an knowledgeable computer type - FNE
Page 14, Column 1
"I enjoyed 'LOTS OF NEAT STUFF', you nearly got me with the copy-protected versions of HALGOL. I guess you will write your UNIX kernal in 6502 assembly to take advantage of the powerful Apple terminal?" Thomas W., Munich W. Germany
No, we think HALGOL-UNIX should be transportable, so we will write the UNIX kernal in either PASCAL or ADA. Naturally, we will then compile to native 6502 code on our powerful Apple terminal.
(Don't feel bad, lots of folks were going "huh?" and re-reading the first few paragraphs before they got to the line at the bottom - FNE)
"Issue 30, pp2-3 seems very uncharacteristic of the FNE. You claim to believe whatever the Motorola guy tells you about UNIX vs. VERSADOS but never believe what the INTEL guy tells you about the 8086 or 80186 vs. the 680XX. My my my. The Motorola guy would always tell the truth - right? I hear but am unable to document the 'fact' that UNIX was among if not the first to 'share segments', i.e. compilers, etc. Too bad mine is only hearsay but maybe one of your UNIX friends could shed some light on the issue of sharing.
"About all that memory to disk to memory I/O that leaves your heart cold (at least discussing UNIX). You should learn a bit/byte/word more about mainframes. The PAGER on a VM [Virtual Memory] system for IBM can cost up to twice as much as the CPU itself...
"IBM demonstrated the XT370 running SAS [Statistical Analysis System] at the SAS User Group Conference last week. SAS did run, but rather slowly by anyone's standards - and was paging like crazy. They may have to fine tune the paging algorithm to get reasonable response.
"Page 14 - you will stop picking on the folk who bother to communicate with you for their grammar - on p. 15 you are 'filing a fourth four-drawer cabinet' On that same page, under Points of View, you have a non-sentence begining with a capitial letter (F in Folks) after a . and two spaces and ending with a . which does not have a verb but only a clause (who...)." Bob P., St. Louis MO
'begining with a capitial'? Shame, Bob! And you did not even terminate the preceding sentence with a '.'! In accordance with your directive, we will not point out that leaving off the terminal 's' in 'assess', as you did elsewhere in your missive, produces an obscenity. And your innovative use of 'beleive' elsewhere is naturally unworthy of notice. If you were an engineer like us you would have an excuse!
Page 14, Column 2
About virtual memory: we seem to remember mentioning that VM is indeed used on some mainframes and that such use requires very expensive hardware and even that VM is a better idea when the computer has 99 other users it can service while swapping segments for YOUR task.
The point we have tried to make is that VM is absolute poison at the personal computer level since that level is much too price-sensitive to permit a proper implementation of VM and even then, there aren't 99 other users to service during the dead time (we hope!). Your comments about the performance of the XT/370 seem to support our argument.
Since you also took the time to point out the advantages of multi-user systems on mainframes, perhaps you have not noticed that this newsletter is directed at persons who purchase and operate their own computers? We have nothing against multiuser systems in an appropriate environment. Any time we phone to make an airline or hotel reservation, for instance, we sure hope the person on the other end is plugged into a multi-user computer system.
Now, about that VERSADOS/UNIX foulup: you are not the only person to point out our transgression. Yes, we should have known better. For many years it was our practice to treat personages (one at a time) of an opposing gender to a meal and a drink to put them in a receptive state of mind. It will not surprise you that the Motorola type had just treated us to a meal and a drink immediately before laying that hogwash on us! Sigh...
A CHANGE OF SUBJECT?
For some reason, this seems to be an opportune time to report the following: Since mailing the last newsletter, we have chatted with two other newsletter writers whose views on UNIX are opposed to ours, to say the least. Here is their composite view as we understand it:
When viewing the UNIX scene, one appropriately focuses on new product releases and new companies entering the UNIX marketplace. One ignores profitability or the vendor/customer ratio as unimportant. Even if particular companies fail, UNIX is the eternal constant. It is very important for UNIX newsletter writers to produce um, somewhat optimistic projections of future UNIX sales (such as Jean Yates' 1982 projection of 600,000 UNIX boxes to be sold in 1983) because otherwise one will not be welcomed and taken to lunch/dinner by the heads of the companies one visits.
(By golly, Jean Yates IS regarded as a more popular dining companion than your FNE by the heads of Fortune, Sun Microsystems, Charles River...)
Page 15, column 1
(As someone who runs a company, we just happen to think that profitability and a concomitant absence of business failure is downright IMPORTANT! Naturally, anyone who thinks profitability is important is going to carefully assess [two 's's on the end, Bob] the reasonableness of sales projections, even going so far as to produce report cards for past years' projections. A proper UNIX person will naturally remain aloof from such crass, mundane considerations.)
"I am probably one of the many who have pointed this out but where do you get that parameter "Address valid to (bar) AS Low" to be 40 nsec? The only spec near that value is the FC to AS Low. There seems to be some confusion between spec 11 and 11A, or do you know something about the 68000 AS timing that you're not telling?" Chris A., Pittsfield MA
Well, Chris, we do indeed know something which we have not - up until now - told. On the other hand, you are actually the first to question that 40 nsec address to (bar) AS assertion of ours, which (as you correctly point out) cannot be confirmed in any Motorola literature. Clearly, an explanation is called for.
First, a review: until quite recently, static RAMs were (all of them) incorrectly specified as a convenience to the specification writer. When one speaks of (for instance) a 150 nsec static RAM, one is speaking of a device which has a Taa (access time from address) of 150 nsec. Up until the past two years, that same part will feature (?) a Tcs (access time from chip select) equal to Taa, in this case 150nsec. THAT IS NOT IN ACCORDANCE WITH THE FACTS! In fact, Tcs is ALWAYS much shorter than Taa. The reason is quite simple: There are many gate delays in the row and column address decoding, but very few gate delays in the chip select path. For example, Tcs of a Toshiba 150 nsec RAM is in fact 60 nsec +/- 5 nsec.
So why, up until two years ago, did spec sheets for static RAMs (any manufacturer) feature equal Taa and Tcs? Because the spec sheet writers are lazy, that's why! (We are almost sure that we have addressed this question previously, but when we review pages 1-3 of issue #14 we find no mention of this.)
This brings us to the Motorola 68000L12, whose spec sheet is a (literally) fantastic invention. We call your attention to item 15 of the timing specifications. Item 15 tells you that the (bar) AS signal may in fact be positive no more than 65 nsec between memory accesses. Gentlepersons, there are two way of looking at that assertion: A) it is not in accordance with the facts, or B) it is total bullshit. As it happens, the question of the accuracy of that 65 nsec spec is very, very important when designing DRAM systems.
Page 15, Column 2
You see, a quick design review of any 68000 system featuring DRAMs (e.g., our Grande) will reveal that the (buffered and decoded) (bar) AS signal is a marvelous candidate to be directly used for (bar) RAS. (RAS means Row Address Strobe, as (bar) CAS means Column Address Strobe. How do you think the DRAM folks got a 64K DRAM, which needs 16 address lines, two power lines and data input and output all in a 16 pin package? Right! The address lines are strobed in 8 bits at a time by RAS and CAS!)
Back to that 65 nsec minimum RAS positive time: if you will grab a good, properly calibrated oscilloscope and look at pin 6 of a 68000L12, you will find that the time the AS signal is positive is in fact 125 nsec +/- 1 nsec! This not just meets but comfortably EXCEEDS the 100 nsec positive requirement of 150 nsec DRAMs! We go directly from an insufficiency to an embarrassment of riches (timing margins). Wha hoppen?
'Wha hoppen' is that we have been done in by lazy spec sheet writers, or have been if we believe that 'fantastic invention' which comes disguised as a spec sheet. We should warn the average reader, who is not a hardware type, that certain hardware engineers and certain engineering organizations hold spec sheets in general in the same regard they would the Holy Grail. To those persons, what we are telling you is sacrilegious! This heretic will continue...
Let us explain where that 65 nsec figure on line 15 of the 68000L12 spec sheet came from: All of the output signals, including the address lines, R/W, (bar) AS and LDS and UDS and even the data when the 68000L12 is writing, are initiated by one edge or the other of the 12.5MHz clock signal. Naturally, there is a delay from the initiating clock edge until the signal appears at the output. As is common with electronic circuits, the delay associated with a positive-going signal (tplh) is not, in general, the same as the delay associated with negative-going signals (tphl).
(tplh = propagation time from low to high; tphl = propagation time from high to low.) Here are some typical figures (in nanoseconds) for a common TTL inverter:
tplh tphl
74L04 35 31
74LS04 9 10
74ALS04 4 3
74F04 3.7 3.2The 74F04 has a much faster tplh than the 74L04, but then the tphl is ALSO a lot faster. What are the chances of encountering an inverter with the tplh of the F part and the tphl of the L part? A ridiculous thought? Not if you are a spec writer, it seems.
Page 16
|<-- 40 -->|<-------- 80 ------->|
_ S7 __________ S1 __________
CLOCK \__________/ S0 \__________/ S2 \__
->| 15 |<- ->| 20 |<-
__ ________________________________
REAL AS ______/<------------- 125 ------------>\________
->| 20 |<-- 40 -->|
___________________
/
REAL ADR --------< ADR VALID
\___________________
|<--- 55 --->| ->|<- ZERO!
__ _______________ =====
B.S. AS ______________/<----- 65 ---->\_____________
\
- BULLSHIT
FIGURE 1 --------Page 16, Column 1
Now let us return to that (bar) AS signal and the specification on line 15 of the 68000L12 spec sheet. As shown in Figure 1, the clock which initiates the positive-going edge of (bar) AS occurs 1 1/2 clocks before the clock which initiates the negative-going edge. A 12.5MHz clock has a period of 80 nsec, so 1 1/2 clocks is exactly 120 nsec. If the internal circuits of the 68000 had equal tplh and tphl, then the positive width of the (bar) AS signal would be exactly 120 nsec. True, those figures are NOT equal, but how do we get from 120 nsec to 65 nsec on line 15?
Simple. The spec writer assumes that tplh can range from zero to 55 nsec, and that tphl can also range from zero to 55 nsec. Now, considering the variation in speeds shown by the '04 TTL inverters in the table above, those times seem reasonable.
HERE IS WHAT IS NOT REASONABLE: the spec writer assumes that if tplh is 55 nsec, then tphl can STILL be zero! And THAT, dear reader, is where that 65 nsec figure in line 15 comes from: 120 nsec minus 55 nsec equals 65 nsec! (See BULLSHIT! in Figure 1 above.) The fallacy is that a part which has a zero nsec tphl will surely also have a very quick tphl, hmmm? Does that not make common sense? Won't devices which have short delays going one way also have a strong tendency to also be fast in the other direction? Won't devices which are slow in one direction tend to be slow in the other direction?
This brings us back to the question raised by Chris A.: "but where do you get that parameter 'Address valid to (bar) AS low' to be 40 nsec?" Well, Chris, the clock edge which initiates the address outputs occurs half a clock, or 40 nsec, before the clock edge which initiates the high-to-low transition of the (bar) AS signal. Since the address buffers on the 68000 chip are identical to the (bar) AS buffer, the propagation delays should be nearly identical (and in practice they ARE nearly identical).
Back to that ridiculous 65 nsec specification on line 15: we have taken measurements on many sample 68000L12s with many differing date codes and we have yet to find the duration of the positive portion of the
Page 16, Column 2
(bar) AS signal to vary more than one nanosecond from its nominal value of 125 nsec! Translation: the typical tplh for a 68000 buffer is 15 nsec and the typical tphl is 20 nsec. Since the signal goes positive 5 nsec quicker than it goes negative, the positive duration of (bar) AS is 5 nsec longer than the nominal time between the initiating clock edges.
What happens, you ask, if somebody does something to make, say, tphl faster? Such as shrink the mask, as Hitachi has in fact done? Well, tplh will ALSO get faster and that 125 nsec just might drop down to 124 nsec. Tsk. So where did that 65 nsec figure on the spec sheet come from? As we told you much earlier, that is literally a fantastic invention. The 65 nsec figure comes to you courtesy of Mr. O'Rourke and Tattoo and lazy spec writers everywhere.
Keep in mind that every timing figure for output signals on the 68000L12 spec sheet is based on that zero to 55 nsec figure and you will be able to make more sense of what is going on, Chris. Oh, yes: are you by any chance related to Christopher Arena, who is the president of ETC, which manufactures the PDQ II 68000 add-on card for the Apple II? If you are, would you ask him whether he has a job available for a dour, fading project engineer with 68000 and 16081 experience? (We have had it about up to here with the carping of the HALGOL critics.)
A doctor, a construction engineer and a spec writer were having a drink one evening and got into a discussion of the world's oldest profession. "Well, on the seventh day God took a rib from Adam and created Eve. I guess that makes mine the oldest profession." asserted the doctor. "Nope!" replied the construction engineer. "On the first day God created the Heavens and the Earth out of Chaos. That makes mine the oldest profession!"
"Don't you guys know where all that Chaos came from?" the spec writer asked.
Page 17, column 1
AAAARRGGH!
It may have come to the attention of some of you readers that your FNE is somewhat impatient with things which work slowly. One of the slowest things which is related to the Apple I/O system, and hence to HALGOL, is the unbearably slow Disk II and the even slower DOS 3.3 file handler.
It is apparent that ProDOS contains no breakthroughs in DISK II speed. It is also becoming apparent that Apple Computer (probably in the interest of compatibility) is NEVER going to upgrade the Apple II floppy disk system to something more modern and reasonable. To give you an idea of our desperation over those (censored) Disk IIs we were actually toying with the idea of making the standard HALGOL mass storage system a higher capacity drive tied directly to the 68000! (While that would indeed work well, it would raise the 'price of admission' beyond most folks' limits.)
We are driven to the inescapable conclusion that we need to reexamine, on a realistic nuts-and-bolts basis, an idea which we had formerly just tossed up for comments:
BLUE SKY ONE II:
A regular Disk II has 35 tracks. The floppy rotates at 300 RPM or 0.2 seconds per revolution. If the floppy drive had a zero start-up time and zero track-to-track step time and if there was no latency (if the data can be immediately read once we step to a track) then it would be possible to read the entire disk in exactly 7 seconds. (35 tracks times 0.2 seconds per track = 7 seconds.) A West German reader sent us a PASCAL disk which loaded a full disk in just nine seconds! We still have trouble believing it!
Well, let's figure out how that worked: most (but not all) Disk IIs will start and come to speed in 0.5 seconds, so we will assume that is the time allocated by the PASCAL system. Add that to the seven seconds and subtract the total from 9 seconds and it is evident that only 1.5 seconds remains for track-to-track stepping and latency (the time to the next sector). Thus, roughly a fifth of a rotation is allocated for a track step and for latency.
When we take into account the fact that Apple PASCAL uses 512-byte sectors and hence 8 sectors per track, it is evident that the time to step to the next track and begin reading must be N*1/8 rotation time, where N is some integer. Since the actual time is roughly a fifth of a rotation, it is evident that N is, for the demo disk cited, 2. That means that 1/4 of a rotational period, or .2 sec/4 = 50 milliseconds is the time to step and settle on the next track in this case.
Page 17, Column 2
Using these figures, it evident that the time required to read one track is 0.2 sec + 50 millisec or 0.25 seconds total. The fastest we can expect to read a Disk II is, then, 0.5 seconds startup plus 35 times 0.25 sec - a grand total of 9.25 seconds. Yes, we know that the PASCAL disk loaded in a measured 9.0 (appx) seconds, but it was filled with HIRES images, 8K per image. That requires TWO tracks per image. If we assume that only 34 tracks were used, the agreement between theory and empirical data becomes exact.
COMPATIBLE DOS 3.3 ?
Various readers have suggested, begged, ordered and pleaded that we keep HALGOL compatible with DOS 3.3. We have decided that this just can't be done if we are to have something useful, meaning reasonably fast. One does not harness a team of oxen to an Indy race-car.
What we really have here is a replay of the battle that we fought and won eighteen months back about whether to make use of the super-intelligent 6502 simultaneously with the 68000. We have taken the time to think the matter through and it turns out that if we are to have a reasonably fast DOS using Disk IIs it will have to be a 68000 DOS using buffers that are considerably larger than the 256-byte Apple buffer(s).
When we say we have taken the time to think the matter through we mean that we have also taken the time to study (not read, study) the book Beneath Apple DOS, by Worth and Lechner. We ignored the actual convolutions of the high-level portions of DOS because we plan to write our own using the 68000, and concentrated instead on the low-level information about timing and the format of the data on the disk itself.
A comment about the book and who should read it: if you do not know quite a bit about both software AND hardware, your chances of understanding the low-level stuff are slim and none, and (as noted elsewhere in this issue) slim just ducked out the door. Our guess is that a pure-software type could get through the high-level stuff that we ignored with no trouble. Finally, we would guess that only one of the two authors knows much about hardware, and that they are both primarily software types.
The illustration introducing Chapter 6 brought a few chuckles. You see, in the late 1960s your FNE was a gung-ho analog designer chasing microvolts and closed-loop servos and nanovolts/sqr(Hz). The saying at the company where he was the engineering V.P. was, "Remove the cover from the subterranean chamber. Lower rare roast beef, Edam cheese and chilled Mumm's Extra Dry. Raise the tray, which will now be covered with schematics. Replace the cover on the subterranean chamber!" Plus ca change, plus c'est la mems chose.
Page 18, Column 1
Here is the short course on DOS 3.3 and HALGOL disk formatting:
DOS 3.3 DISK FORMAT:
Bits are recorded on the disk with a time separation of 4 Apple II clocks, which Beneath Apple DOS calls 4msec, which is in fact the abbreviation for milliseconds. (We have that problem at times ourselves.) In fact, the Apple clock period is about .980 microseconds. So, each byte requires 31.36 microseconds. Since the disk rotates at a nominal speed of one rotation per 200 milliseconds, that means we can record 6377.5 bytes per track. Since DOS 3.3 uses 16 sectors, that gives us 398.6 bytes/sector. (And you thought there were only 256 bytes per sector! Tsk!)
Each sector has a 14-byte address field. The 256 data bytes are spread out, via 'prenibblizing', into 342 bytes. An extra 7 bytes are tacked on, 3 at the front and 4 at the back, for a total of 349 bytes in the data field. Add 14 to 349 and we have 363 bytes of the available 398.6 used up. The remaining 35.6 bytes are used for the two "gaps" associated with each of the two fields in the sector (address and data). The gaps are made up of repeated "sync bytes". Each gap MUST have, as a minimum, 5 "sync bytes" for the disk to be read correctly.
The "sync bytes" are needed because the rotational speed of the disk is not perfectly constant and because a disk initialized on one drive may be written on by another disk drive with a slightly different rotational speed. This implies that we need some slack. The slack is in the gaps, which are made up of sync bytes. Each sync byte is ten bits long, or 1.25 normal bytes. So the 35.6 remaining bytes provide approximately 28.5 sync bytes to be allocated to the two gaps. Beneath Apple DOS suggests that 5 to 10 sync bytes are to be found in the gap following the address field, and 14 to 24 in the gap following the data field. That means that our calculations almost exactly correspond with the book - a very good thing, because the book has been around a while and nobody has shot holes in it yet.
HALGOL DISK FORMAT:
A HALGOL Disk II will use 1024-byte sectors, four sectors per track. No interleaving will be used; sectors will be read in sequence and (when appropriate) written in sequence. There will be only 140 sectors, so only a single byte will be needed to define a particular sector on disk. Note that the use of four sectors per track is in agreement with our observation earlier that a 25% rotational delay upon stepping to the next track provided a maximum-speed disk read.
We are stuck with the Disk II hardware, so we will use
Page 18, Column 2
the same prenibblization. Our 1024 bytes becomes 1366 bytes after being nibblized. Add 14 bytes for the address field and seven bytes to the data field and we have a total of 1387 bytes. Since 6377.5 divided by 4 is about 1594.4 bytes per (large) sector - should we say quadrant? - we have space for 207.4 normal bytes or 166 sync bytes left over.
With minor adjustments, that is what HALGOL DOS will look like on the disk. Before you bitch too loudly, consider that HALGOL will be able to load a 30K text file in under three seconds! The 68000 will, of course, do all the pre- and post-nibblization and stuff like that. Why not? It is a whole BUNCH faster than the 6502!
For the folks with half a megabyte or so, HALGOL will of course use RAM disks for even greater speed, once the disk(s) have been initially loaded into RAM (at less than 10 seconds per disk!)
Of course, none of this is compatible with DOS 3.3 or even ProDOS... which means that nobody is going to come after us asserting that our 68000 code infringes their copyright! (Now let's see... how do we modify this scheme so we can write-protect HALGOL disks?)
LIMITS: A VIRTUE ?
As many of you may remember, we offered a long while ago to manufacture a 68008-based under-the-hood board at a low price. We received a surprising amount of correspondence on this subject, nearly all of which said, "Great idea! Your cheap board HAS to have 128K DRAM and expansion capability!" As an acquaintence noted, that is exactly orthogonal to the concept of "cheap". The fact is, "expandability" and "cheap" are antonyms! Consider:
"Expandability" requires that any case be larger than needed to allow for that expansion. It requires that the power supply be larger than needed for the same reason. It requires additional "glue" logic and buffering and connectors. "Expandability" is a newly-wedded couple buying a five-bedroom house. One thing "expandability" is not: it is not cheap.
Having said that, we note that the products we now sell are expandable, that the power supply which has been designed into the mythical case is oversized to accommodate yet-unknown add-ons, and that we are having a hard time locating expensive LS640 buffers, five of which are used to buffer the expansion port on every DTACK 68000 board, static or dynamic.
Question: Should we design and offer for sale an UNexpandable 68000 attached processor, one with a cheap case because it only has to be exactly as big as the
Page 19, Column 1
board and power supply which it contains and a cheap power supply because it only has to be exactly big enough to power that board and a board which is smaller and cheaper because the extra glue loqic and buffers and connector have been tossed out? Our guess is, for the audience we have cultivated (that's YOU!), no. We invite correspondence on this subject, provided you do not suggest that the product be expandable!
SON OF VDHR GRAPHICS:
As you should know by now, our plan to offer a medium-resolution graphics expansion (there's that word again) board was derailed by extensive bugs in the existing production 7220. We have the choice of A) dropping the idea, B) waiting for the debugged 7220A, now 6 months or more away, or C) designing a dumb graphics board, one where the 68000 does all of the work.
If we do (C), we would build a two-ported board which is compatible with the Radio Shack color monitor for the Tandy 2000. This monitor has 640 X 400 non-interlaced RGB color graphics and an aspect ratio that is 11% off unity. At $800, it is the most cost-effective color monitor in its performance range. To give you an idea, it has exactly twice the horizontal resolution and exactly twice the vertical resolution of IBM's PC color monitor. That means there are four times as many pixels as IBM PC color graphics!
Naturally, there is no free lunch. A dumb graphics accessory and the color monitor together would come to $1450, give or take $100. That's not exactly pocket change for most of us. On the other hand, our mythical case has room for such a board and the power supply for the mythical case has enough extra juice to power it. (That's the flip side of the 'expandability' coin.)
Should we hold off until a better/cheaper color monitor appears? Should we wait for the 7220A? Stick with cheaper monochrome? Or just take a long walk off a short pier? If you drop us a line, give us your thoughts on this subject as well, please.
Dig Sex ?
As most of you are aware, we are not especially fond of the acronym selected by DTACK Software Exchange director Jeff H. We mean, DSEx comes out as 'de-sex' and there is just no way we can get friendly with that. We have been lobbying Jeff to change the name to the DTACK GROUNDED Software Exchange, whose acronym DGSEx will naturally be pronounced 'dig-sex', which is corny but something we can approve of.
Perhaps Jeff does not understand that a DSEx would naturally have to support the Eunuchs operation, er, operating system?
Page 19, Column 2
BYTE WATCH:
The April issue is out, complete with a marvelous April 1 gag (disguised as a statement of ethics) by Phil Lemmons. Phil would have us believe that Consulting Editor Jerry Pournelle PAID for the 50+ computers which reside in chaos manor! What a laugh...
This issue also discusses five different dialects of BASIC. Boy, BYTE is in big big trouble! Wait until the readers of THIS publication find out that not one of those BASICs are exactly like Applesoft or meet any of the demands we have been getting in re: HALGOL!
Uh, those of you who have felt free to attack HALGOL ARE going to attack those five BASICs as well, aren't you? What have we got here, a double standard? you think your FNE is an easier mark than Lemmons? [Some of you may be wondering whether the preceding is meant to be sarcastic. Let us leave no doubt: YES]
Now that we have vented a little spleen, you really should take a look at the middle column on page 299. Here is an excerpt: "A new class of compiler, the incremental compiler, has found favor among BASIC's recent innovators. This compiler permits the simulation of interactivity, provides another level of error checking, and would, by itself, be a significant improvement to BASIC." The article outlines further improvements featured by "the new BASICs" and darned if most of them don't look a lot like HALGOL (or what we have planned for HALGOL). As we have said before, it is reassuring to note that our decisions with regard to HALGOL are not too far from the mainstream.
This issue also has an article on an 80186-based machine with 'super' graphics capability. Sigh. If you will look on page 290, you will see that the 640 X 400 pixel mode has only two colors and is interlaced, meaning each pixel is updated only 30 times per second (instead of 60 times per second for non-interlaced displays). The only way to beat the annoying 'flicker' caused by an interlaced display is to use long-persistence phosphors. But, as any owner of an Apple Monitor III knows, long-persistence phosphors are TERRIBLE for fast-moving graphics - and that BYTE article is about a machine which supposedly FEATURES fast-moving graphics. Translation: that 'super' graphics machine will in practice be used in its 320 X 200 mode, which is the same pixel density as the 1977 Apple II monochrome HIRES graphics.
The Tandy 2000, on the other hand, has eight colors at 640 X 400 pixel density and is NOT repeat NOT interlaced. Will the real 'super' graphics machine please stand up? What's that? We are interfering with the constitutional right of promoters to tell outrageous lies?
Page 20, Column 1
ST. MAC WATCH:
Issues #1 and #2 of St. Mac had 60 pages, but issue #3 has dropped to 52 pages. You would think that someone would have figured out in advance that a closed computer is not going to attract many advertisements for add-on hardware. Amongst those 52 pages is an editorial on page 4 which essentially states: "ACHTUHG! You vill buy a Mack und you vill travel north und you vill LIKE traveling north! On page 49 we are told who is buying Mack, which means we are also told who is NOT buying Mack. A couple of quotes:
"Noticeably missing from the ranks of the buyers were hackers and people who already own another Apple computer. Retailers say these prospects look with interest, but don't buy." And: "Techies may not be buying, but many others are thinking of unique ways to use the computer." If you will check page 4 of issue #29, we said that already.
The feature article was an Alan Kay interview. Alan is about the only alumnus of the Xerox STAR who eluded Apple's clutches, going instead with Atari. Well, Alan survived the last Atari layoff (some VERY well regarded programmers did NOT) and he MIGHT even survive the next one. That circumstance may have something to do with his churlish attitude throughout the interview.
We are tempted to quote part of the interview - on page 12 Alan seems to think a 12MHz 68000 compiled to machine code is pretty good pookie, but then on the next page he states, "I personally think that school is a kind of mass murder." And then he goes on for a page to justify that remark. Nope, you can have Alan; we will look for support for our endeavor elsewhere.
But St. Mac does have some useful information, such as the fact that Microsoft's Mack BASIC only leaves a 13,405 byte user workspace and does not include the COM(munications) or SOUND statement. Well, the rodent is sort of cute. Maybe you vill travel north only und LIKE it?
MORE APRIL FOOL:
EDN had a truly marvelous spoof of floating point math chips, a subject in which we have a keen interest. They described a math processor which supported Roman numerals! It seems the chip has a very long rise and fall time (see Gibbon for more details). Also, the chip never ever produces a divide-by-zero error (ahem!). To use the IC as a slave processor, you can specify automatic chaining operations! A tribute-free phone number with a DCCC area-code is provided by EDN for more information. The chip is made by Ancient Micro Devices, CMI Thompson Pl (wait until Jerry Sanders hears about this). See p139 of EDN, 5 Apr '84.
Page 20, Column 2
Walden Pond this ain't:
It was near sunset when the well-dressed businessman approached us by the pond. Shifting the bundle he was carrying under his right arm, he asked "Have you by any chance seen Peanut?" Actually, we admitted, we had. We saw Peanut right out there, nearly in the middle of the pond, as he was going down for the third time!
"How long ago was this?" the businessman questioned us sharply. Well now, we replied, fair is fair. It's your turn to answer a question. What's that you are carrying under your arm? "A new data entry device!" he snarled. "How long?"
How about that, we leisurely answered. It looks just like a keyboard! Oh, yes: about twenty minutes ago, we reckon. With that, we turned to leave. "Didn't you even try to help?" the businessman demanded. We turned back momentarily and mildly replied, we've never cared much for Peanuts.
We quickly reached the perimeter road. When we looked back at the pond, the businessman had rolled his well-creased pants nearly up to his knees and was standing dubiously at the edge of the water. We shouted at him, one more thing: when he turned around and looked in our direction, we yelled we don't like Popcorn either!
He threw the data entry device into the water.
REAL TRAGEDY DEPT:
There is this outfit (which shall go unnamed) which has used this pretty good and moderately expensive 68000 box complete with a 10 megabyte Winchester. They have had this machine for quite a while now and it has done a bang-up job for them in developing lots of 68000 assembly-type stuff. Naturally, they have made backups from time to time of all the files which change on the Winchester.
Well, that system finally failed. When they got it fixed (after a 3-4 week delay) they discovered - ulp! - that they could not read any of the backups they had been making for the past six months! You see, if you only have ONE Winchester and if it is pretty much full, then one has a fairly strong disincentive to test one's backups...
You may now understand why Digital Acoustics, a company which can afford a Winchester disk or three, owns NONE. The guy who runs the place does not believe in using Winchesters without good, effective backup capability. It does appear that IOMEGA makes a good backup, so good that it looks to us SUPERIOR to the general run of Winchesters which are available for the Apple in terms of data transfer rate. That company in Georgia [VAFAX,
Page 21, Column 1
call (800) 241-1119] which has adapted the IOMEGA drive for use as a PRIMARY storage device apparently thinks along the same lines we do. IOMEGA has just delivered its 10,000th drive, nearly all of them intended for use as backup (secondary storage). Hmmm...
There are some removable-cartridge Winchesters around, if you believe the ads. DMA, Syquest... one asks oneself why nobody is using these drives in production quantities. One reads in the technical media vague assertions that there are problems with the removable-media Winchesters, said problems not specified.
What we are really saying is that, in our opinion, any device which is (in our view) a good backup device is also a good primary storage device. We can't imagine a better storage system than two removable-media Winchesters sitting side-by-side. Apparently others share our viewpoint; several folks pre-announced such a disk storage system using Syquest drives about 18 months back, which was then three months before Syquest was going to start delivering production quantities! (Uh, production schedules have slipped slightly.)
This is being written after Blue Sky One II, elsewhere in this issue. As you can see, we have been doing a lot of thinking about mass storage lately and we have DEFINITELY had it up to here with that 140K DOS 3.3 system!
If you are currently using a Winchester, you might check to see if your backups are genuine, hmmm? The company mentioned above (that is a true story) wishes IT had!
SEK-C VERSION 1.5:
"Version 1.5 of the SEK-C DTACK-compatible 68000 compiler is now available. It requires a 92K Static RAM DTACK board, a 48K Apple II+, and a text editor capable of handling the special characters that C is fond of, such as curly braces and reverse backslash. Since FNE informs me that DOS Toolkit will not handle these characters, I recommend an editor/assembler such as MERLIN, which allows these special characters to be displayed either via the HIRES graphics screen or via an 80 column card such as the VIDEX.
"SEK-C v1.5 is an extended version of the Small-C compiler written by Ron Cain, later refined and extended by J. Hendrix, and described in Dr. Dobb's Journal. The compiler comes complete with the MINOS operating system, but without the MINOS source code of course. It also comes with a native 68000 assembler.
"The execution speed of SEK-C is very fast. The sieve of Erastothenes benchmark from BYTE magazine, for example, runs faster than ANY of the timings listed for
Page 21, Column 2
68000 C Compilers. SEK-C generally chooses in-line code over subroutine calls, and is optimized in a multiple pass process, and hence gains its speed. The total compilation PLUS ASSEMBLY rate for large source files is 200 lines per minute (using Pronto-DOS to speed up the disk access times) and is faster for short files. The majority of the time taken is the writing of the assembly language object files generated by the C compiler and the subsequent reading of these files by the assembler.
"Should you wish to hand-optimize certain portions of your code, the assembly language file put out by the compiler is in standard Motorola/ASSEM68K compatible syntax, and you may easily modify those sections you wish. If you want to imbed your own carefully hand-tuned 68000 assembly language functions into the C source files, it is no problem. Simply surround it by #ASM and #ENDASM. As aids in debugging or speeding up your assembly coding, both TRACE and PROFILE functions are included in the standard library. These are C callable functions which respectively give you a step by step view of selected 68000 register contents, or generate a map of the frequency with which each instruction in your code is executed.
"SEK-C version 1.5 does not yet include LONG or FLOAT data types, but version 2.0 will! (Version 2.0 will also run on the DTACK Grande dynamic RAM 68000 board.) As promised before, the early C customers are receiving a free copy of version 1.5 and will receive a free copy of 2.0 WITHOUT having to send their old disks back in order to get it! (I always disliked having to do stuff like that myself.) The policy that the first twenty customers get free upgrades through version 2.0 is still in effect, so get your copy now and you still qualify.
"SEK-C v1.5 for the static DTACK board is still $95. The book "The C Programing Language" by Kernighan and Ritchie costs $25. Send funds to:"
Charles L Bennett
SEK Enterprises
7585 Amador Valley Blvd #14
Dublin CA 94568
(See issue #26 p.2 for the earlier release 1.0. Please note that Charles has a new mailing address since the earlier release - FNE)
Electronic News Watch:
The following two paragraphs are taken from E. N. 2 Apr '84, pages 21 and 16 respectively:
"One of Fortune Systems' most important large end-user customers, Crocker Bank of San Francisco, has stopped
Page 22, Column 1
buying new Fortune computers and is said to be leaning toward Digital Equipment [DEC] desk-top systems as the standard microcomputers throughout the company. Fortune systems already bought by Crocker are being consolidated in its Business Banking Center. Fortune officials, who acknowledge that Crocker has put new Fortune orders on hold, say the customer is taking a 'wait-and-see' posture on Fortune."
"IBM has been quietly soliciting bids in recent weeks from leading keyboard makers here and in Japan for a new data entry system but, following its standard procedure, won't tell the would-be vendors on what project the keyboard will be used. Speculation is rife, however, that IBM wants the keyboard as a replacement for the controversial rubberized "Chiclets-style" keyboard on the PCjr home computer. Dissatisfaction with that keyboard, which many critics argue is difficult to use for word processing, is believed to have contributed to the PCjr's slow start in the marketplace."
MORE KEYBOARD:
Yesterday (Apr 3) IBM announced software which, in effect, turns its PC into a Displaywriter. Earlier IBM had announced that lead times on the Displaywriter were now out to 9 months due to a shortage of certain parts which are also used in the PC.
Translation: IBM is retiring the Displaywriter without officially seeming to do so. If you have a choice of waiting 9 months for a higher priced unit or taking immediate delivery of a functionally equivalent unit, which path will you choose? Please note that the 'parts shortage', in this case, is completely fictitious. IBM is building many, many, MANY more PCs than Displaywriters. Re-routing enough parts to support orders for Displaywriters would not even cause a noticeable hiccup on PC production lines.
The plain fact is that a multi-billion dollar company like IBM just does not want to fool with a product like Displaywriter and its insignificant sales. What makes this especially ironic is that the keyboard of the PC was originally deliberately busted to protect sales of the Displaywriter, just as the 'chiclet' keyboard of the PCjr was deliberately busted to protect sales of the PC. (Persons who are not touch-typists will not think the PC keyboard is busted. Remember, Displaywriter is/was intended for use exclusively by touch typists. Also remember that IBM originally did not think it would sell very many PCs.)
HOPE FOR THE REST OF US:
The fact that IBM has as its principle office wordprocessing machine one which was originally
Page 22, Column 2
deliberately designed to make wordprocessing highly inconvenient provides hope for the rest of us. In this case, the 'rest of us' ranges from tiny Digital Acoustics to giants Apple and Tandy. If IBM ever decided to make a genuine PC, one which uses the latest and best technology of puppet Intel (IBM now owns 20% of Intel) and which is not busted or warped in any way to protect any other product of IBM, it would be a signal for the rest of us to take up selling aluminum siding.
Meanwhile, it really breaks our heart to see the PCjr and its chiclet keyboard do an 'el floppo' in the marketplace. Gosh.
COMMODORE WATCH:
Well, Commodore did in fact introduce an exact copy of the Hyperion, a Canadian portable PC clone at the Hanover fair. The British call this "badge engineering." We suspect that the "Commodore" PC clone shown at Hanover was in fact a Hyperion with the "badge" literally swapped.
Although Commodore also showed its Z8000 UNIX-clone, speculation is that that machine will not even be test-marketed in West Germany. If true, that would be the only smart thing that Commodore has done, post-Trameil. Remember the Z-8000 based Olivetti M-20? Our local personal computer retailer is trying to unload one, $995 as-is, all sales final.
It has been more than a year since Commodore shut down its far-east VIC-20 production lines and retooled for a 16K version. Well, that 16K version was ALSO introduced (finally) at Hanover, with a $200 (list) price tag. Two questions: just how much inventory of VIC-20s did Commodore HAVE a year ago? Who in the world would buy a C-16 at $200 instead of a C-64 for not much more?
[The above was from a story in the L.A. Times. The corresponding WSJ story gave a price for the C-16, in this country, of $100. That makes more sense.]
WEST GERMANS PLEASE NOTE:
There have been at least one, perhaps two, copies of the HALGOL release 1.02 source code in West Germany since mid-March. Since any DTACK board owner is permitted to pass a copy of same to any other DTACK board owner, we presume that you will now have a copy if you are interested and if you are a DTACK board owner.
We know that Ulrich S. has a copy because we sent him one; we assume that DSEx European Herr Koordinator Thomas W. was sent a copy by Jeff H. If you guys don't
Page 23, Column 1
want to cooperate amongst yourselves then you are going to miss out. We will, for instance, send a copy of release 1.03 to Peter S. when it is ready; if Ulrich S. does not want to cooperate then Peter will have his chance at revenge, hmmm? Looking further down the road, perhaps release 1.04 should go to irate Teuton Oliver B? He IS still alive, isn't he? (We have not heard from him for ages.)
And yes, we know very well that it costs money to make copies and mail them. So charge enough to recover your costs, O.K.?
VDHR IN COLOR:
Video Monitors Inc. of Eu Clair, WI have introduced a color version of their 20 inch monochrome monitor. We have already made and sold a three-bit plane version of our VDHR system (no sweat - the system was designed from the start for up to four bit planes) for one of those new monitors and it is now in use at a certain CADD house. If you think 1024 X 796 monochrome graphics with 4 grey levels is spectacular, wait until you have seen 1024 X 796 RGB (color) graphics! To get some idea, just go see a demo of the Tandy 2000 and realize we are talking about a 20 inch monitor with over three times as many pixels! Yum!
Talk about a little kid in a cookie factory! (Actually, we thought of a better analogy but we are trying to keep this rag reasonably clean.)
You may also be interested in a report by Sam Bassett on page 73 of Apr '84 Computer Graphics World. (Remind us to twit Sam about those '64K BYTE chips expected next year'. Sam, 256K bits is ONLY 32K bytes...)
SHOVELING RIGHT ALONG:
Most of you undoubtedly believe that we shovel a little fertilizer (a natural by-product of dairy operations) from time to time (we did, after all, adopt the nom-de-plume Felgercarb, did we not?). From time to time, a whole bunch of you start shoveling in the opposite direction, and the past couple of months has been one of those times. About twenty of you are asserting that the high level language C is not really high level and hence has a vanishingly small time overhead as compared to assembly. Gentlepersons, that assertion is genuine Grade A cow-flop! A few facts:
Let us first observe FORTH, a language whose enthusiasts regularly claim has only a 2-1 overhead. So Bruce Walker first introduces a standard FORTH for the Apple/DTACK system and then follows up with an Apple/DTACK FORTH which compiles nearly to native code with a concomitant 5-1 speedup! Where did old 2-1 go? Out for a beer?
Page 23, Column 2
Now we come to the Mar '84 edition of Computer Architecture News, the ACM SIGARCH quarterly. In past issues, the performance of the 68000 and Z8000 were compared to the RISC I (a paper study where the RISC I is concerned, naturally). Assembled C code was originally used for the 68000 and the Z8000 and doggone if the RISC did not prove nearly 4 times faster than the 68000!
In the Mar '84 issue the benchmark tests are repeated, this time using assembly. The 68000 sped up by a factor of MORE than six, and is now 1.5 times faster than the RISC I in four out of five tests! In other words, C has a 6-1 overhead when used with the 68000 (the ratio was about 5-1 for the Z8000)! (Incidentally, the latest test was done with a 10MHz 68010. A 12.5MHz 68000 would skin the RISC I alive! A 4-1 faster RISC I with the 68000 running C, indeed!)
Gentlepersons, a 'more than 6-1 speed degradation' can in no way be considered negligible. Will you please put down those shovels and accept the fact that C has the usual, expected and ordinary overhead associated with just about any high-level language? (PDP-11s excepted; C is largely stylized PDP-11 assembly code.)
SUPPRESSED TOPIC A:
In this journal Topic A is speed. A lot of other publications will go to almost any length to suppress that subject. (As Henry McG recently wrote, "There is a lot of hostility in the computer community to measures of performance".
Take InfoWorld, the issue headlined "EASY TO USE". In the third column of the cover story on p36 we learn that "Valdocs is now considered somewhat of a failure (an upgrade to better the effort is due out soon)." And that, folks, is both the beginning and the end of the discussion of the QX-10's 'Valdocs' operating system.
Why is Valdocs a failure? Because it does not use a mouse? Because the cover of the operating manual is chartreuse instead of fuschia? Could Valdocs be (gasp!) SLOW? We have no way of knowing!
Only after reporting that LISA was rejected by the marketplace and again reporting that LISA is not doing well do we finally get down to it: FINALLY they report that "The Lisa's interface is extremely slow." Gadzooks! An unexpected outbreak of candor! The article continues:
"Time is an important factor in keeping the user involved. The ideal response time after a key is pressed is one-tenth of a second. After one second, the user looks away from the screen and starts to look
Page 24, Column 1
out the window or thinks about having a snack. At thirty seconds, the user gets out of his chair. 'You have to be aware of these thresholds and stay below them,' McGregor says."
And there you have it folks; the simple and obvious justification of the need for speed. Given one computer which is 34 time faster than another, then tasks which have a difficulty or complexity 34 times greater can be run on the faster computer which cannot be run on the slower computer, given acceptable response times. Since the faster computer can also perform ALL of the tasks of the slower computer, then the faster computer is more desirable (more widely applicable) than the slower computer. That, in a nutshell, is what we have been preaching in these pages for almost three years now.
34-1 is the difference between starting a program at the start of a coffee break and being finished at the end or running 4 hours 40 minutes. We assert that such speed is desirable in and of itself. Yes, we know we said that already this issue.
But we sure wish we knew why Valdocs is not doing well. Perhaps the manual is printed in Basque?
OUT, DAMN FURRINER!
There are foreigners and foreigners. For most of our readers, Radio Shack land is populated by furriners. Since we have this here Tandy 2000 (with color graphics to make an Apple type weep) we examined the May '84 issue of 80 Micro magazine carefully - it has some more scoop on the Trash 2000. It is interesting to delve into another culture. On the supposition that you agree with us, a few quotes from this issue:
"Why did we pick Pascal as the topic for a column? Our reader surveys show that it ranks only behind BASIC and Assembly language in interest. As Bruce points out, it is widely used in schools." (p.8)
"The new year brought Apple's 32-bit Macintosh - the first computer built entirely of bells and whistles." (p.21)
"This 'Unixization' policy, according to A T & T Technologies Computer Systems Vice President Jack Scanlon, has paid off handsomely. All in all, 'about 70,000 computers of approximately 70 different types run UNIX systems' Scanlon told attendees at Washington, D.C.'s Uniforum, a UNIX users' trade show." (p.24)
"There are two attractions to UNIX, which make up for its being bigger, slower, and harder to learn than the single-user DOSes micro programmers are used to." (p.24)
Page 24, Column 2
As a single-user micro programmer, we are damned glad there are attractions which make up for UNIX being bigger, slower, and harder to learn. Otherwise we might decide against using it. And if there are a total of 70,000 UNIX systems in operation, including systems which became operational before 1983, what happened to Jean Yates' prediction of 600,000 UNIX system sales in 1983?
Pascal is widely used in schools? Gosh, we didn't know that. Being less popular than 'Assembly' we did know about...
On page 96 is an article on benchmarks, in which the Trash 2000 beats everything in sight by a factor of at least 2.3-1. The computer which comes closest to the Trash 2000 in performance? Why, Mackintosh of course! We will ignore that the language used by the Trash 2000 is written in Assembly (mit a capitial [sorry, Bob] 'A' yet) while the Mack is running a language written in C. What the heck, a lot of you readers have explained to us that C runs just as fast as assembly, right?
MORE RADIO SHACK:
One can always tell when Tandy is going to close out a computer model; it goes on sale for 20% off. The latest Tandy model to be on sale is the Model 16, which is available for about $2000 off the former price. Tandy insiders tell us that the Model 16 is limited by its use of a Z-80 to perform all I/O operations. They expect to see the Model 16 replaced by an improved model wherein the 68000 handles its own I/O.
WE GET MORE MAIL
"Being a native of California I can't be a Belgium. Even worse if I were a citizen of Belgium I would not be a Belgium because Belgium is the name of the country and the people are Belgian. Now about some of the French that you have put into your newsletter..." David L., Embourg Belgium
There is no one in the editorial offices now, FNE being out to lunch. This is a recording.
"First the good news: in the light of your explanations I must admit that I haven't found any bugs in your Microsoft compatible package after all. I was misled by the disagreements between constants and comments. Also, you are right that the last hex digit of 2/LN(2) is '9' and not 'A'.
"Now the bad news: let us play with the HALGOL floating point multiply. Let us multiply a number that is almost 1.0 by a number that is just above 0.5 - the result would be around 0.5, right?
Page 25, Column 1
10 LET A = (1 - 2 (-47)) * (.5 + 2 (-48))
20 PRINT A"What's that? The result is zero? That's a rather gross error, isn't it? No, I don't drink Heineken Special Dark, but I wouldn't mind some Andechser Doppelbock." Ulrich S., Aachen W. Germany
Ulp! Ulrich, if you will take out your copy of newsletter #15 (Nov-Dec '82) and turn to page 26, you should find an "ROXR.L #1,D0" instruction between lines 475 and 476. What's that? You say that instruction is missing on your copy? Gee. It's missing on ours too! Perhaps the enclosed $5 will pay for the necessary fluid to correct the typo? (We had sent Ulrich an early copy of our previous reply.)
Only one week previously we had replaced that very multiply with a new version which is about 14% faster - and which did not have that instruction missing. So the bug you found was not present in the current version of developmental HALGOL! O.K., O.K., we know that is a weak excuse, so drink your correcting fluid, will you? We are printing the new multiply routine in REDLANDS. The reader (Ulrich and Chet are disqualified) is challenged to compare the new code with the code in issue #15 and identify the one major and one minor reason the new code is 14% faster.
The new multiply code is intended to go with the faster divide routine which Ulrich and Chet S. have been prodding us to write - next issue, maybe?
"There is a restaurant in Albuquerque called 'Eloi's Place', and if it hadn't looked like such a dive, I would have eaten there yesterday... John B., Santa Fe NM
No relation, John - FNE
HALGOL REPORT:
Halgol has now has multiple statements per line capability up and running. Also, to edit line number XXX just key ".XXX" followed by RETURN and the system lists line XXX and places the cursor on the first character of the line following the line number. Makes for super-easy editing! Dynamic allocation of table space (which includes the HALGOL run-time code itself) is now being worked on. All of the above is due to our resident full-time HALGOL programmer.
Our other HALGOL programmer has been spending so much #%&@*! time chasing *<@%$ parts that arrays are not progressing nearly as fast as we would like. We have a 2-1/2 page writeup on how HALGOL arrays work and more than five pages of source to back up the description,
Page 25, Column 2
but none of that has been tested. We think we will wait until the code is at least minimally functional before sticking our neck out and publishing either the description or (portions of) the source.
One thing we did do is write a faster F.P. multiply routine and we have begun work on a very messy but faster F.P. divide routine. Why that instead of arrays? We need something soothing after a frustrating morning chasing parts.
Why are we spending so much time chasing parts? Because we are shipping DTACK boards at continually increasing rates. (All right, it IS true that a large proportion are going out the door with a VDHR board set attached.) But temporarily, until we get production settled at its new plateau, the last thing in the world we need is a sudden onset of board orders from hackers. If you are wondering why we have not been advertising, that's why!
FLASH !
Alan Kay has resigned from Atari. His departure "comes amid continuing layoffs and reorganizations associated with... efforts to restore profits."
Co-founder Carlton Ahmdahl and computer development director James Dykstra have resigned from Trilogy. Carlton is the son of Gene Ahmdahl
(Both reports are from 16 Apr '84 Electronic News.)
PERMISSION TO COPY:
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 178th 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:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
REDLANDS THIS MONTH lists a new, faster 62-bit floating point multiply routine for HALGOL - complete with ROXR.L #1,Dn instruction.
Page 26
2 LIST
3 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC
4 ;
5 ; STORE A ZERO IN FPACC1
6 ;
002384: 42B81902 7 RZER CLR.L S1
002388: 42B81906 8 CLR.L S1+4
00238C: 4E75 9 RTS
10 ;
11 ; FETCH AN 8 BYTE F.P. NUMBER TO D5, D6, D7
12 ;
00238E: 2A18 13 FPMUL MOVE.L (A0)+,D5 ;X2, M2A
002390: 3C18 14 MOVE.W (A0)+,D6 ;M2B
002392: 3E18 15 MOVE.W (A0)+,D7 ;M2C
16 ;
17 ; PERFORM A 62 BIT FLOATING POINT MULTIPLY
18 ;
002394: 4A45 19 FPMUL2 TST.W D5 ;ZERO ?
002396: 6AEC 20 BPL RZER ;IF SO
21 ;
002398: 4CB8000E1904 22 MOVEM.W S1+2,D1-D3 ;M1A, 1B, 1C
00239E: 4A41 23 TST D1 ;ZERO ?
0023A0: 6AE2 24 BPL RZER ;IF SO
25 ;
26 ; MULTIPLY THE MANTISSAS FIRST
27 ;
0023A2: 3007 28 MOVE.W D7,D0
0023A4: C0C2 29 MULU D2,D0 ;M1B * M2C
0023A6: 3806 30 MOVE.W D6,D4
0023A8: C8C3 31 MULU D3,D4 ;M1C * M2B
0023AA: D084 32 ADD.L D4,D0 ;ADD PARTIALS
0023AC: 4240 33 CLR.W D0 ;DISCARD LOWER WORD
0023AE: E350 34 ROXL.W #1,D0 ;CY INTO BIT 0
0023B0: 4840 35 SWAP D0
36 ;
0023B2: CEC1 37 MULU D1,D7 ;M1A * M2C
0023B4: D087 38 ADD.L D7,D0 ;NO CY POSSIBLE
0023B6: 4244 39 CLR D4 ;FOR CY'S
0023B8: 3E06 40 MOVE.W D6,D7
0023BA: CEC2 41 MULU D2,D7 ;M1B * M2B
0023BC: D087 42 ADD.L D7,D0
0023BE: E354 43 ROXL.W #1,D4 ;CY INTO BIT 0
0023C0: 3E05 44 MOVE.W D5,D7
0023C2: CEC3 45 MULU D3,D7 ;M1C * M2A
0023C4: D087 46 ADD.L D7,D0
0023C6: 6402 47 BCC MUL1
48 ;
0023C8: 5244 49 ADDQ.W #1,D4 ;ADD THE CY
0023CA: 3E00 50 MUL1 MOVE.W D0,D7 ;GUARD WORD
0023CC: 3004 51 MOVE.W D4,D0 ;CARRYS
0023CE: 4840 52 SWAP D0 ;NEW PARTIAL SUM
0023D0: 4244 53 CLR.W D4 ;CLR CARRYS
0023D2: CCC1 54 MULU D1,D6 ;M1A * M2B
0023D4: D086 55 ADD.L D6,D0
0023D6: E354 56 ROXL.W #1,D4 ;CY INTO D4
0023D8: C4C5 57 MULU D5,D2 ;M2A * M1B
0023DA: D082 58 ADD.L D2,D0
0023DC: 6402 59 BCC MUL2
60 ;Page 27
62 ; COPYRIGHT 1984 DIGITAL ACOUSTICS INC
63 ;
0023DE: 5244 64 ADDQ.W #1,D4 ;ADD CY
0023E0: 4243 65 MUL2 CLR.W D3 ;CLR EXP ADJ FLG
0023E2: 3C00 66 MOVE.W D0,D6 ;LEAST WORD
0023E4: 3004 67 MOVE.W D4,D0 ;MOVE CARRYS
0023E6: 4840 68 SWAP D0 ;PARTIAL SUM
0023E8: 3405 69 MOVE.W D5,D2
0023EA: C4C1 70 MULU D1,D2 ;M1A * M2A
0023EC: D082 71 ADD.L D2,D0 ;NO CY POSSIBLE
0023EE: 6B08 72 BMI MUL3 ;IF NORMALIZED
73 ;
0023F0: DE47 74 ADD.W D7,D7 ;LEFT SHIFT
0023F2: DD46 75 ADDX.W D6,D6 ;LEFT SHIFT
0023F4: D180 76 ADDX.L D0,D0 ;LEFT SHIFT
0023F6: 7601 77 MOVEQ #1,D3 ;INCR EXP ADJ FLG
78 ;
0023F8: 4A47 79 MUL3 TST.W D7 ;ROUND UP ?
0023FA: 6A10 80 BPL MUL4 ;IF NOT
81 ;
0023FC: 5246 82 ADDQ.W #1,D6
0023FE: 640C 83 BCC MUL4
84 ;
002400: 5280 85 ADDQ.L #1,D0
002402: 6408 86 BCC MUL4
87 ;
002404: 4246 88 CLR.W D6 ;MANT = $8...000
002406: 4280 89 CLR.L D0
002408: E290 90 ROXR.L #1,D0 ;CY INTO BIT 31
00240A: 5343 91 SUBQ.W #1,D3 ;DECR EXP ADJ FLG
92 ;
00240C: 32381902 93 MUL4 MOVE.W S1,D1 ;S1,X1
002410: 4845 94 SWAP D5 ;S2,X2
002412: 3805 95 MOVE.W D5,D4
002414: B344 96 EOR D1,D4 ;BIT 15 = SIGN
002416: 02448000 97 ANDI.W #$8000,D4 ;SIGN ONLY
00241A: D245 98 ADD.W D5,D1 ;ADD EXP'S
00241C: 02413FFF 99 ANDI.W #$3FFF,D1 ;MASK HIGH BITS
002420: 06431000 100 ADDI.W #$1000,D3 ;INCLUDE ADJ FLG
002424: 9243 101 SUB.W D3,D1 ;SUBTRACT OFFSET
002426: 6B00FF5C 102 BMI RZER ;IF UNDERFLOW
103 ;
00242A: 0801000D 104 BTST #13,D1 ;OVERFLOW ?
00242E: 6600FF4E 105 BNE OVFL ;REPORT OVERFLOW
106 ;
002432: 8244 107 OR.W D4,D1 ;ADD THE SIGN BIT
002434: 31C11902 108 MOVE.W D1,S1 ;STORE S1, X1
002438: 21C01904 109 MOVE.L D0,S1+2 ;STORE M1A, M1B
00243C: 31C61908 110 MOVE.W D6,S1+6 ;STORE M1C
002440: 4E75 111 RTS ;FP MULT DONE
112 ;Page 28
YE OFFICIAL DTACK CRIB SHEET II:
--------------------------------
THE HOST RESETS THE 68000: SEND COMMAND BYTE TO THE 68000:
-------------------------- -------------------------------
RESET SEI ;mask int'pt CMD SEI ;mask int'pt
LDX #0 ;set D3 low BIT RDSTAT ;68000 ready ?
STX WRSTAT BVS CMD ;wait til rdy
LDX #25 ;set delay LDX #9 ;set D1, D3 hi
WAIT DEX ;dly 100+ s STX WRBTAT
BNE WAIT STA WRDATA ;send cmd byte
STX WRDATA ;snd garb byt LDA RDDATA ;clr 68K flag
LDX #8 ;set D3 high CMG BIT RDSTAT ;cmd accpt'd ?
STX WRSTAT ;remove reset BVS CMG ;wait til got
WAIT1 BIT RDSTAT ;garb taken ? LDX #8 ;set D1 low
BVS WAIT1 ;til taken STX WRSTAT ;clrs cmd line
LDX RDDATA ;clr inp port CLI ;en'bl int'pt
CLI ;en'bl int'pt RTS ;command sent
RTS ;done
HOST TO DTACK COMMUNICATIONS
----------------------------
UNSIGNED COMPARISONS:
--------------------- Send a byte to DTACK:
Branch if A > B: CMP A,B SENDBY BIT RDSTAT ;68000 ready?
BCS dst BVS SENDBY ;wait
STA WRDATA ;send byte
Branch if A >= B: CMP A,B RTS ;done
BLS dst
Get a byte from DTACK:
Branch if A =< B: CMP A,B
BCC dst GETBYT LDA RDSTAT ;byte avail?
BPL GETBYT ;wait
Branch if A < B: CMP A,B LDA RDDATA ;read it
BHI dst RTS ;done
Branch if A = B: CMP A,B
BEQ dst DTACK TO HOST COMMUNICATIONS
----------------------------
Branch if A <> B: CMP A,B
BNE dst Send a byte to the host
SENDBY BTST #6,STATUS
COMPARISON FORMS (4): BNE SENDBY
--------------------- MOVE.B D7,DATOUT
RTS
CMP <ea>,Dn
Get a byte from the host
CMPA <EA>,An
GETBYT MOVE.B STATUS,D7
CMPI <data>,<ea> BPL GETBYT
MOVE.B DATIN,D7
CMPM (Ay)+,(Ax)+ RTS
