DTACK GROUNDED, The Journal of Simple 68000 Systems
Issue # 24 October 1983 Copyright Digital Acoustics, Inc
Below is a photo of a real, working Nat Semi 16081 math chip peripheral to both the static and dynamic RAM DTACK boards. All of our preliminary tests indicate it gives accurate results and is about three times faster than a 5MHz 8086/8087 combo at performing the double precision floating point operation A = B * C where A, B and C are located in memory. The 68000/16081 combo requires 23 microseconds to perform this operation (measured using an oscilloscope on real working hard/software) while the 8086/8087 requires 65 microseconds + EA, where EA = <Effective Address> calculation of the source/destination of the operands. That's 9 microseconds to load an operand, another 9 for the other, 27 microseconds to perform the double precision multiply, 20 microseconds (!) to store the result and a tad for EA.
The relatively long times required to load and especially to store the operands using the 8087 are, we believe, due to the fact that the internal computations
are not performed directly on the IEEE format but on a longer "temporary real" format. By the way, the 8086/8087 combo will be FOUR times slower than the 68000/16081 combination due to the more restricted bus bandwidth.
We are very pleased with the results we have obtained and would be even more pleased if production 16081s were available now. The math chip IS being generously sampled, though, so production might begin early next year as Nat Semi representatives now predict. With National, you never really know until after it has happened (remember their press release in May 1982 which asserted that the 16032 would be available the very next month?).
We will have ample time to produce the QD-1W before production math chips are available... darn it!
Now that we have an "IEEE format" math chip working with our DTACK board(s) we thought we would bring you up to date on the happenings in the wonderful world of standards. First, the status of the IEEE draft standard for floating point operations:
The latest information most of you will have is draft version 8 of the IEEE standard, which was published in the March '81 issue of (IEEE) COMPUTER magazine. This went through two more iterations before draft 10 was submitted to the IEEE for approval and the 754 committee was disbanded. Although draft 10 was submitted nearly a year ago, the IEEE oversight committee an standards has not yet acted on it (and on
The Motorola 68000 and the National 16032 - Together at Last!
some other proposed standards) because of internal reorganizations within the IEEE and, it is rumored, just a little politicking. There is no way to know now when, or whether, draft 10 will become the official IEEE 754 standard.
Meanwhile, the IEC (International Electrotechnical Commission), which is the European equivalent to the IEEE for electrical/electronic standards purposes, has apparently grabbed draft version 8, the one published in COMPUTER magazine, and for some reason has rushed it through to approval. Let us repeat this: There is a finalized, approved IEC standard which is essentially if not literally identical to IEEE draft 8.
Now about the math chips: the 8087 is the only FAST math chip which more or less conforms to the draft 8 or 10 standard for double precision floating point which is available over the counter. (We exclude the very early and very slow AMD 9512.) We understand that this chip does not completely comply with all details of either draft 8 or 10, largely due to the fact that the chip design had to be frozen before draft 8 existed. However, we understand that the differences are minor.
The National 16081 math chip is not available over the counter but it is being widely sampled and, as stated elsewhere in this issue, we have one running successfully in conjunction with our DTACK boards. This chip also does not comply with either draft 8 or draft 10, apparently because of a desire on National's part to have an economically manufacturable part.
There are a number of sections of both draft 8 and 10 which outline OPTIONAL features. For instance, the 80- bit "temporary real" which is the ONLY format the 8087 uses for double precision computations is an optional feature not included on the Nat Semi 16081. Therefore the 8087 maintains higher precision intermediate results for chained operations but requires significantly longer to load and store operands.
There is no math chip available or soon to be available which fully complies with any math standard, approved or pending. The IEEE standards group operates under the imprimature and guidance of ANSI (the American National Standards Institute) and their standards have the effect of law. Compliance with an IEEE or ANSI (or IEC) standard is a legal matter, not a matter of opinion. (The work Digital Acoustics has done in the past to comply with ANSI S1.4 (1971) has made us painfully aware of these matters.)
This does not mean that the considerable efforts which went into developing the Intel 8087 and the National 16081 should go unappreciated. We bow with respect to both organizations for their considerable and worthwhile accomplishments.
You are considering buying a personal computer. You are choosing between two identical computers, physically speaking. They have the same CPU, CRT, disk drives, expendability, and they even look the same. Oh, yes: they also have the same price. The only difference is, brand A is eight times slower than brand B. Naturally, you purchase brand:
A: brand A
B: brand B
You are considering purchasing a very, very good personal computer for your serious and extended use. You want a single-user device (no sharing CPU cycles or files) with at least a 10 megabyte hard disk, a 16-bit CPU and such. You have narrowed the choice to two models which each meet your performance requirements. Brand A costs $35,000 and brand B costs $6,500. Naturally, you choose brand:
A: brand A
B: brand B
You are considering purchasing a spreadsheet to run on your three-piece- business-suit type personal computer. You have narrowed your selection to two competing software packages which have surprisingly similar features. Brand A will give you a graphical answer to "what if" in two and a half minutes, while Brand B will give you the same answer in a few seconds. Naturally, you purchase brand:
A: brand A
B: brand B
You are purchasing a programming language (we will not reveal that it is BASIC; it comes in a plain brown wrapper). Brand A has two levels of interpretation and is eight times slower than brand B. Naturally, you purchase brand:
A: brand A
B: brand B
The envelope, please: the correct answer in each case is A!
You disagree? Then you are in disagreement with virtually every current authority on programming. Today ALL the experts will tell you that operating systems and even programming languages should be written in a high level language (usually C). On the first two pages of issue #16 we poked fun at Carl Helmers. Hell, Carl was a prophet; everybody else in the computer world has joined in. Make that almost everybody.
On page 188 of Aug '83 BYTE magazine it is conclusively proven for the umpteenth time that a high level language should supplant assembly language now and forever. AND, let us emphasize, they are talking about for use in programming operating systems and other languages, as well as frequently used applications programs such as spreadsheets and word processors! The critical paragraph in BYTE's argument appears to be the last one in the second column. That critical paragraph proving people should forthwith and forever hence NEVER use assembly language contains the following phrase:
"Compared to other languages, assembly language allows the fastest execution of instructions and takes up the least memory space..."
We believe that we have spotted the flaw in the logic that essentially everyone except your FNE believes. Before discussing that flaw let us make a few observations. With what only appears to be a change of subject, let us talk about some hardware:
Those models above share three common attributes: 1) All have proven highly successful in the marketplace. 2) All have an operating system written in assembly language. 3) All have the principal mass-market high level language (BASIC) written in assembly language.
Now, some other hardware:
These models all have an operating system written in a high level language (PASCAL, C and FORTH, variously and in combination). The first three feature an interpretive BASIC which is written in a high level language and hence offers two levels of interpretation. None is being particularly successful in the marketplace, although it say be too early to judge in Epson's case. All have been widely panned as having poor performance.
The flaw in the arguments now being presented by just about every authority in sight is now obvious: there is a free marketplace in which purchasers can freely
choose among various alternatives. Operating systems are not written for an abstract, pristinely pure purpose. They are most commonly written to run on a specific machine which is offered for purchase by a specific manufacturer.
The available evidence proves conclusively (in our opinion) that the consumer (that's you and us) will purchase a computer whose operating system is written in a high level language if and only if no competitor has an equivalent unit whose operating system and mass- market language are written in assembly. Recent evidence seems to also conclusively prove that the same is true of second-generation spreadsheets. To the best of our knowledge, the good word processors have always, and always will be, written in assembly.
If all those "experts" were right, then Context/MBA would be wiping 1-2-3 out of the marketplace instead of vice-versa, and LISA or Fortune's 32:16 or even the Sage IV would be wiping out IBM's XT. Who cares if the software is three times harder to write in assembly if sales are therefore 30 (or more) times greater?
[This might be a good time to remind you that we have consistently reported here that the 68000 is about four times as easy to program in assembly as the 6502 or the Intel series.]
Why, then, do the "experts" continue to proclaim the death of assembly? Simple. This industry appears to be especially susceptible to the "Chicken Little," or bandwagon, effect. One guru (Carl Helmers?) asserts that assembly is dead and it's O.K. to program your operating system in a high-level language and damme if twenty other guys don't pick up the chant and then four hundred more and everybody agrees because everybody else is saying the same thing. Perhaps this is a (another, more accurately) character defect in your FNE but your FNE does NOT like bandwagons.
That's why we point a (slightly dirty) fingernail at the real-world marketplace and assert that assembly has whipped high-level at every confrontation! (You will please note that our argument is limited to operating systems, high level languages and application programs offered to the mass marketplace which are used frequently. Real-time programming is not being considered here although that is another obvious area where assembly MUST be used.
The one arena in which an operating system can be written in a high-level language is the one where EVERY vendor agrees to not inconvenience his competitors by
using higher performance assembly. There is a real- world example: all those outfits making $35,000 UNIX systems, most of them based on the 680X0! The reason you have to spend $35,000 to get a really good- performing single-user UNIX system is that UNIX is, in every case, written in C! Does anyone who reads this letter really believe that a truly high-performance personal computer could not be assembled today for about $6000 - $7000? Assuming available software written in assembly, that is.
The "experts" who are loudly proclaiming the death of assembly are the same guys who were trumpeting the arrival of UNIX as THE mass-market operating system for 16-bit minicomputers a year ago. You know, it's a funny thing; we look around today and we don't see UNIX as a mass-market operating system. Maybe we need glasses?
Can't those "experts" see that assembly has won every confrontation in the past and is winning every confrontation RIGHT NOW? Do those "experts" operate in a vacuum (without their space helmets, your FNE asserts darkly) where there is no such thing as a free marketplace where one can CHOOSE? (Academia provides one arena where the free market and competitive pressures do not exist, of course. That's one reason such screwball ideas come from that direction at times.)
One of the problems with disagreeing with a lot of (mostly very intelligent) experts is that the experts might be right, which would leave lots of egg on one's face. We ask each reader to think of examples where assembly has lost to transportable code in the free marketplace and to please bring them to our attention. We are not unwilling to recant when proven wrong! Don't point to PASCAL's popularity in academia; that is not a free marketplace.
Take another look at that idiotic multiple-guess quiz. Can any rational person select A on any question? Does not the "experts'" assertions REQUIRE that A be selected in each case?
Transportable code can be used (make that WILL be used) in universities, where there are no competitive pressures.
Transportable code can be used in a business
environment where there is so much money available that a sufficiently powerful computer can be purchased to overcome the inefficiency of transportable code. Such as $35,000 for a really good personal computer.
In fact, transportable code can be used under ANY circumstances where competition from assembly and a free marketplace do not exist. This applies to kazoo instruction programs for left-handed Lithuanians; you are not likely to encounter competition for such a program. You can write a program for yourself in transportable code if it is not going to be used very often in a "time is money" environment. You can write a transportable tic-tac-toe program for your niece.
MOST IMPORTANT OF ALL, you can write operating systems, high level languages and application programs in transportable code if you do not mind somebody coming along and wiping out your product the way the XT is wiping out Fortune's 32:16 or the way 1-2-3 is wiping out MBA. The nice thing about being willing to lose money and/or go broke is that you can do anything you want!
Those of you who follow the hardware side of the microcomputer industry are probably aware that all of the major microprocessor manufacturers - Intel, Motorola, Nat Semi, Zilog - are adapting Unix System V for their 16-bit products under the guidance of Western Electric. This is wonderful, of course, because that will provide standardization and (with famous semiconductor industry efficiency) a very low licensing price, right? Uh, WRONG!
If you want to get the real low-down, detailed bad news about this project take the effort to look up the 8 Sep '83 issue of Electronics Magazine. Beginning on page 108 is more information about Unix System V than you will ever want to have. There is a separate writeup for each of those four micro manufacturer's game plans, plus over-all info. Let us venture the opinion that anybody who reads this material is going to have a lot less interest in System V than he/she had prior to reading it.
Let us offer just two little gems; the licensing for any of those UNIX systems will be done by Western Electric directly, NOT by the semiconductor houses. Thus no learning curve and no mass market economies. System V will continue to be very, very expensive even if the semi houses get the hardware cost down to $1.17. Secondly (you are going to love this one!): System V, which is the culmination of years of refinement of a truly wonderful (?) multi-user operating system HAS NO PROTECTION AGAINST TWO USERS MODIFYING THE SAME FILE SIMULTANEOUSLY! Isn't that just marvelous?
Hey! That guy keeps claiming that Microsoft's 68000 BASIC has two levels of interpretation but he ain't never PROVED it! (Do we hear that little voice?) Let us introduce you to a little magazine called PC, the Sept '83 issue to be exact, all 668 pages of it. On page 99 Peter Norton (of IBM PC fame) asserts: "The subject of languages is touchy because most programmers - including me - have opinions that are distinctly individual and often passionately held. That the choice of a programming language can easily be an emotional issue is interesting and revealing in itself."
Peter also asserts: "For what is called 'systems programming'... C is probably the best language available. Certainly C is widely accepted as such, and that acceptance ensures that its reputation will be fulfilled." (p.101)
How do we square this with the aside a paragraph earlier that "...reports have it that IBM/Microsoft's FORTRAN is pathetically slow while Supersoft's FORTRAN is said to be very fast." As it happens, Microsoft's FORTRAN is written in C!
(We cannot fail to pass along a couple of quickies: "Fans of Pascal have elevated it to near religion, while vendors of compilers [Ken please note] have extended the language in many ways Wirth never specified in order to make it usable in business." (p.121) and "FORTH users are usually quietly satisfied with their discovery of the perfect language, while Pascal's minions are fervently evangelistical, even violent in defense of their chosen language." (p.126))
"...Witness the unsinkable BASIC interpreter. Forget operating systems. Forget snazzy spreadsheets. Hang up your modeM, and, for that matter, junk your PC. The real hero of the personal computer revolution is BASIC." (p.141)
You have maybe wondered why 1-2-3 and MBA are so similar in features? "Says Kapor... 'we saw MBA, and my feeling was that a data base was a more natural expansion of a spreadsheet.'" (p.164)
The foregoing is by way of leading up to a report on the interview with Tandy Trower, Microsoft's Product Marketing Manager for both business and consumer products. Tandy's last name gets misspelled a lot, for reasons suggested above.
"Trower: All the BASICS created up to the present are written in assembly code. But one of the things that
we are doing right now with all of our languages is moving them into C. It makes them much more portable. Moving from the 8080 to the 8086 is reasonably easy, but moving from 8086 or 8088 code over to the 68000 is a little more difficult." (p.294) This is a factual report if one allows some leeway for 'up to the present' and 'doing right now'. You see, Microsoft's 60000 BASIC was written in C prior to June 1982. But the 8088 BASIC in the IBM PC is written in assembly, not C. Why?
(p.293) "... Actually, Microsoft back at that stage [when first approached by IBM - FNE] probably consisted of fewer than 15 employees. We have almost 400 now."
By our figures, that gives Microsoft 385 reasons to keep the big blue giant happy by busting their 68000 BASIC so that it is slower than their 8088 BASIC - as they have in fact done! By writing the 68000 version in C, which is the second level of interpretation that we strongly hinted at on the front page of issue #16. What's that? You didn't realize we were talking about IBM and Microsoft on the front page of #16? We suppose that you have not identified the large oaf either?
You may, if YOU wish, believe that Microsoft has written its 68000/16032/Z8000 BASIC in C for transportability. We do not believe it is an accident that that action protects its substantial income from 8-bit machines, including the PC. This is a very smart move in the short term but in the long term it can hurt Microsoft badly. We have presented arguments in this matter elsewhere in this newsletter.
A software house which is selling a very fast second- generation spreadsheet has been contracted by a Silicon Valley personal computer manufacturer to adapt that spreadsheet to its yet-unreleased 68000-based machine. We wonder if that manufacturer realizes that the port will be done in C, not the original assembly language? And that the second-generation spreadsheet will therefore run very slowly on their unreleased 68000 machine? (Isn't transportable code wonderful?)
Is it true that the original spreadsheet program by this company was written by six guys, first in C then translated to assembly for performance? Is it true that they have used the VERY substantial income to hire lots more troops, mostly from the mainframe world? Is it true that one of the more highly-placed new-hires recently asserted that this second-generation spreadsheet needed a wordprocessing module and a communications module? Did he also very clearly assert that they need not be GOOD modules since the public would buy ANYTHING with his company's name on it? Is this what is called V*S*C*RPing?
You will recall that we have consistently asserted that the 12.5MHz 68000 is the best single-user single- tasking one-chip CPU you can buy today. You may have forgotten that, when we compared the 68000 to the (hypothetical and unavailable) 8-10MHz Intel 286, we unequivocally asserted that the 286 was the superior multi-user multi-tasking device. (We compared the 286 to a stake-bed truck, which is assuredly better suited to transporting 32 sheep than a Porsche Turbo. We also asked: are you going to drive the truck or ride in the back?)
But we did not pursue the reasons for our opinion. One is that the 286, once it is real at 8MHz next year, has a really excellent memory management scheme built into the chip. (Memory management is what you need to keep 32 sheep from trampling each other.) We recall asserting that the 286 was really a good memory management chip which, as an afterthought, included a microprocessor. But there is yet another reason which we have not emphasized up until now:
Back in issue #4 we pointed out that the T.I. 9900 was really good at "switching contexts" for the simple reason that it maintained no registers on the chip itself. For that SAME REASON, the chip is a real DOG when it comes to performance.
The latest issue (#2) of UNIX REVIEW asserts that the ability to switch contexts quickly is important in a (typically multi-user) UNIX system, and that it is going to evaluate the various 16-bit chips in the future based on their suitability as a "UNIX ENGINE". Boy, is that T.I. 9900 going to look good when they evaluate context-switching!
So how do the 68000 and (hypothetical) 286 compare in re: context switching? No contest! The 286 is FAR superior!
Uh, just a minute now... UNIX is a popular (well, highly visible) high-end microprocessor-based operating system and you are saying that the 286 is FAR superior in performing an important UNIX-related function, you say ask? Yup, we answer. How can this be, you ask?
Let us for a moment set aside Unix and competing processors and compare the performance of the 68000 (16 ea 32-bit registers) with a HYPOTHETICAL 68000 II with 32 ea 64-bit registers. With four times greater internal resources, the 68000 II should outperform the 68000 in the sort of single-user single-tasking applications which we prefer. At least, we hope it is obvious that the greater the internal resources, the better the, microprocessor. (Let us please, for now, ignore considerations such as where do we find room in
the instruction field to SPECIFY those extra and longer registers. We will discuss this later, we promise.)
Now; can the 68000 or the 68000 II switch contexts more quickly? Since switching contexts essentially involves saving the status register, program counter and the address and data registers to memory (usually the stack) and replacing them with equivalent register contents for a different context, obviously it will require the (hypothetical) 68000 II nearly four times longer to switch contexts!
Well, be advised that the 286 has nearly four times less internal resources than the 68000! Naturally the 68000 is the superior microprocessor for single-tasking purposes, as we have told you. Naturally the 286, with very limited internal resources compared to the 68000, switches contexts much more quickly. Naturally, the T.I. 9900 (lately, 99000), with virtually NO internal resources, switches contexts even more quickly than the 286!
If you want to ride in the back of that stake-bed truck with the other 31 sheep, you will LOVE the 286! And if THAT does not seem such a hot idea to you, then you should run like hell when offered a microprocessor which switches contexts more quickly than the 68000...
So why is the Grande suitable for print spooling, etc? Because only a few registers, maybe three, have to be switched for that purpose, and also because there are only two or three tasks, not appx. 32, to handle concurrently.
Here at Digital Acoustics we have a couple of youngsters, one an electrical engineer and the other a programming engineer, who have the luxury of being able to concentrate on a single context (generally speaking) throughout a given working day. On the other hand, your FNE has rather diverse duties. When we get deeply involved in a given project and are (note editorial plural) approached by one of those youngsters asking a question regarding their ONE single-tasking context, we often do not even understand the question as it is first asked. This is a source of considerable amusement to the youngsters, who snicker and laugh behind your FNE's back.
As we have just demonstrated, the simple fact is that your FNE's chemical CPU has such vast internal resources that it requires a significant amount of time to change contexts!
(There will be a short pause while your FNE ducks tomatoes, fish-heads and worn-out shoes.)
VERY-DAMN-HI-RES stuff: if you want to see what we are doing with those boards on the last cover, see page 41 of Mar '83 Computer Graphics World or page 272 of Feb '83 Mini-Micro Systems. The Genisco ad shows a 792 X 1024 monochrome monitor. It appears to NOT have alternate memory pages or multiple bit planes, which our boards DO. However, the Genisco unit does have a case and a keyboard and a $9950 price tag.
We will not pick on the guy who called us today and asked if a "wide-bandwidth" 20MHz (!) NEC monitor could be used with our graphics boards. Folks, we use a 67.888 MHz pixel clock so you need a 150MHz monitor bandwidth. Like we said, those graphics boards are not a toy.
(Let's see now: half-gallon Grande $1245, VDHR-2 $1500, monitor $1100-$2000, custom case $1000, keyboard $300. Hmmm... and that Genisco monitor doesn't even have a 68000, much less half a megabyte. Or two bit planes and alternate pages, although we are not sure about that.)
Up until now Motorola has been achieving very good yield of 12.5MHz 68000s even though they have not shrunk their (now 3-year old) 3.5 micron design-rule mask. Motorola DOES have plans, it is rumored, to shrink the 68010 mask once they have the cookie-cutter properly calibrated. In the meantime, Hitachi has never been able to produce, commercially, 12.5MHz parts using that same 3.5 micron mask.
Now they won't have to try. Hitachi has just announced a successful reduction of the 68000 mask to 2.6 micron design rules, and that they will have commercial quantities of 12.5MHz 68000s next month at $73/1000. If Hitachi could calibrate its cookie-cutters as well as Motorola, that would mean 16, maybe even 18, MHz 68000s.
We may yet see 16MHz 68000s or 68010s available across the counter before 8MHz Intel 286s...
We are getting a LOT of inquiries and some purchases lately from folks who want to tie their DTACK boards to non-fruity machines, 64s, OSIs, Z-80 cards, IBM PCs, you name it. Some of these are for proprietary purposes. Those of you doing non-proprietary work might want to make yourselves known to others of similar ilk. Like the Aussie, Belgium and Minneapolis folks working with OSI. Just write to us, indicate your interest, and give us permission to give your
address and/or phone number to others.
That means you, too, Earl. (Earl wants to hook up to a Z-80 system.)
Chuck Peddle has 'turned over day-to-day operating responsibility' of Victor Technology to a new executive vice president and chief operating officer, Richard G. Couch. Chuck's decision coincidentally followed closely on the heels of the first Victor board of director's meeting that followed the release of Victor's latest quarterly financial report. Victor Technology is the outfit that makes the best-selling Victor 9000 personal computer.
What that means is, if anyone at Victor wants to buy a box of paper clips, they ask Richard for permission, not Chuck. Maybe Victor is not becoming the fourth largest computer firm swiftly enough to satisfy its board of directors? Will future Victor advertisements continue to feature Chuck's picture and repeat his name 4 1/2 times?
The Wall Street Journal has quoted Apple's new prexy Scully that a board is being developed which will allow LISA to run (IBM) PC software. We just KNOW how popular that decision will be with the folks (most of them XEROX PARC alumni) who developed LISA...
Apple's two previous co-general managers have been shunted aside (they have not been reassigned to a new post as this is written). Apple has a NEW acting general manager: new prexy Scully. Seems Scully wants to PERSONALLY control the destiny of the Apple IIe, whose sales are reported to be flattening. Source: EN 5 Sep '83. Oh, yes: the same issue of EN carries a long article about LISA sales being uh, slow.
Maybe the folks at Apple figured they were hiring a figurehead, but it seems they got a tiger instead. It will be interesting watching future developments.
Texas Instruments has just named a new president of its consumer products group (99/4A). He is Peter A. Field, formerly of Proctor & Gamble. Actually, he was head of P & G's coffee division, but if we called his Mr. Coffee, you might think we were referring to a former baseball player.
Formerly the president of Consolidated Foods, he has
been running Osborne Computer for some time now. Doubtless that is the reason for their recent success.
In fact, he has been successful in getting rid of just about ALL of Osborne's production workers. That's odd: we hadn't heard rumors that Osborne was setting up a fully automated production line. We wonder if this has anything to do with reports that three Japanese industrial spies drowned in San Leandro, CA when they were caught in a flash flood of crocodile tears near the Morrow factory?
This one has not arrived on the small computer scene yet, but he will.
Somebody has just come out with the simple, small, EPROM-cum-static RAM 68008 under-the-hood board we have discussed several times in these pages. The somebody is QWERTY INC. in San Diego; their phone number is (619) 569-5283. Oh, yes: for $695 you got 16K EPROM expandable to 32K, 2K RAM expandable to 8K, and a 7MHz clock. (Electronics, Aug 25 '83 p.174) The field for under-the-hood 68000 boards now seems filled; there is little point in our bucking heads with the 4-6 companies in that market.
It is interesting to note that their price is only $100 less than for a 12.5MHz 128K Grande, which has a 16-bit data bus and is expandable...
By all means look up the latest, maybe next-to-latest by now, issue of PC World and turn to the publisher's column. The first thing we want you to observe is the photograph of David Bunnell. We could express an opinion about that photograph but we think it would be better to permit each of you to form your own opinion.
But we think that his column, in which he talks about how much trouble Commodore is in, proves conclusively that he cannot read a company financial report. IBM (the whole corporate structure) should be experiencing Commodore's growth rate and profit margins...
There is a shortage of integrated circuits, especially the several flavors of TTL, as the country pulls out of the recession. However, this shortage is due to a sudden expansion of business in the home and personal computer marketplace and from manufacturers of small office business type products. The big boys - IBM, Burroughs, CDC, etc. haven't upped their purchasing.
Let's see now: wasn't it Erwin A. Frand who wrote that the low-end computer market was becoming THE computer market? See issue #21, p.11 column 2.
The more PCs IBM sells the more people are unplugging their terminals so the response time of the existing mainframe improves so we don't need that bigger mainframe we thought we would need this year, hmm? Has anybody noticed that Hewlett-Packard, which is primarily in the higher-end computer business, is showing 6% annual growth lately? Has David Bunnell noticed what IBM's total corporate annual growth rate is lately?
The people buying IBM PCs are precisely those who last year had a terminal plugged into the resident mainframe. The people who buy Apples and Trash-80s are less likely to be the mainframe terminal type. What a wonderful idea IBM had to compete with Apple and the Trash-80s!
But shorter. On Friday, Aug. 26, two sample production Grande boards plus piggyback expanders arrived, at 10AM. At 3:30PM a 512K Grande was fired up, and it worked! So the piggyback board was added, and the megabyte worked! True, these first 'production' boards did not have solder mask or silk screen. But there ain't no jumpers, so the modifications we made to the prototype layout were all O.K. and we can give our board supplier the production go-ahead tomorrow, Aug 29.
Now for the true story: we naturally left the new board running a memory test overnight. When we arrived in the morning, we noticed the screen was frozen. No error messages were on the CRT so we assumed an electrical power transient had locked up the handshake. Sigh. So we poured a cup of coffee and turned to the second issue of UNIX REVIEW, which had arrived the previous day.
When we got up to pour a second cup, it seemed to as that the frozen CRT looked different, but we decided our (chemical) memory was playing tricks on us. Coming back from the coffee pot, it looked different yet again! So we stopped to watch, and, sure enough, the Grande was still running the memory test at one pass every eight seconds.
Look, we have been working with 68000s now for over two years, and it is our experience that when something doesn't happen for an entire EIGHT SECONDS, then something is busted (maybe the software). Having been caught ourselves, we will not pick on the several
persons who did not realize we were kidding in the last issue when we talked about how slowly the dynamic RAM board ran a memory test. Naturally it takes a lot longer to check out a megabyte. Everybody knows that, right?
Charles River Data Systems is now advertising that it delivered the first commercial product using the 12.5MHz Motorola 68000. In the first issue of UNIX REVIEW, that newsletter asserts that the first Charles River systems were shipped in Feb '83. We called Charles River, got hold of their advertising copy writer, and pointed out that WE shipped OUR first 12.5MHz 68000 product on 1 June '82. And since we got PAID for that product, that made it commercial, no? We also pointed out that by Feb '83 we had shipped about 100 12.5MHz 68000-based commercial products.
At least the guy listened and apparently wrote down the name of our first customer for the 12.5 version. It will be interesting to see whether they continue to use that 'we wuz first' assertion. Why not? The folks at Sage are still trying to gull you into believing their 8MHz 68000 runs at 2 MIPS, an assertion which will amuse the Charles River folks as much as it does us. We wonder what the Charles River folks would think about Acorn's 8 MIPS 68000 product...
[Later.] Surprise! The guy called us back and stated that the Charles River ads will be changed to indicate they shipped the first general purpose computer system using the 12.5MHz 68000, NOT the first commercial product. Because of publishing lead times, you will not see the revised ads until very late this year.
In the April '83 issue there was an article which concluded that the 12MHz Z800X with a 64K address range, was superior in addressing ability to the 12MHz 68000 with a 16.7 megabyte address range. One reader wrote a letter to the editor asserting that there were a few problems with that article, one of which being the fact that 12MHz Z800X's did not exist. That letter and a rebuttal were published in the Aug issue.
The author's rebuttal asserted that the only fair way to compare two microprocessors was to assume identical clock frequencies. We think the author also asserted that the difference in addressing range was irrelevant to addressing ability but we are not sure... maybe you ought to read the letters and judge for yourself. While you have that issue out, do not miss the article on "Big-Enders vs. Little-Enders."
"I appreciate your defense of Phase Zero in your recent newsletters. The fact that we needed defense (and we did) is more than a little embarrassing. We are about as small as a company can get (one 68000 programmer, a total of three employees, two with 'real' full-time jobs), and a lot of things simply never get done. I hope that our service to our customers has been (at least) adequate. Being called thieves does hurt; it's not what we're here for.
"...it is usually a great mistake to attempt to retain too much of the old structure when upgrading and redesigning. This (have you ever noticed?) is the mistake I have chosen to make in working on operating systems for the DTACK boards. The mistake I have chosen NOT to make is to spend an extra six months to a year on development when I could be writing a language. And tell me, does it really make that much sense to do things like flashing the cursor in the 68000?
"About LISA: I have only had about three hours to play with one, at Pima Community College here in Tucson. Unfortunately, the machine was working badly and had to be sent back. I was able to make LisaWrite (the word processor) malfunction fatally several times, but will have to try again when it is repaired to see if the malfunctions were real. It is (as we've all heard by now) painfully slow. LisaWrite often runs four or five characters behind on input, which came very close to taking me right over the edge. And about that one- button mouse: somebody wasn't quite satisfied with having only one button, so some functions are activated by the "shift-click": press "shift" on the keyboard, then click the button. So such for design integrity. The dot-matrix printer is not just painfully slow; it is completely beyond belief.
"Best Regards (to Oliver, too!)" David R. PHASE ZERO
Folks, we received this letter only a couple of days after we mailed newsletter #23, so David did not know that A) we had also 'come clean' with an admission that WE were a small company (we have never claimed otherwise), and B) had not learned that Oliver, the irate Teuton, had a personal credibility problem with respect to his complaints about PHASE ZERO's unresponsiveness.
Based on correspondence and phone conversations with our own customers we can confirm that PHASE ZERO does support its customers (customer = person who sends check in payment for product). We have had a couple of complaints that PHASE ZERO sometimes does not provide 24 hour turnaround to a customer in, say, New Jersey but that reflects more on the unrealistic expectations of some customers than on PHASE ZERO's service.
We can ALSO confirm that if you write PHASE ZERO for information about their software you are going to get the same response that you will get from us if you write us asking for information about the Stuffer board: NONE! It is not economically feasible to respond to information requests about products which cost $100 or less (or even $110).
Do we own stock in PHASE ZERO? No. Are we disinterested, then? HELL, no! They are supporting our boards with a cross-assembler and they are writing a BASIC (and have written an operating system) for the Apple-DTACK environment. Obviously, we wish then well and support their efforts.
We have received a HUGE volume of mail unanimously suggesting that we make extensive use of the enormous resources of the Apple's 6502 in developing HALGOL. We get three times as such mail on this subject as we did about virtual memory, and we got lots of mail on that subject. This means that you readers will LOVE MINOS 1.0 because that operating system uses the 6502 just the way all of you have suggested!
We believe that the 6502 is the problem and therefore cannot be a part of the solution. The HALGOL operating system under development COMPLETELY REMOVES the cerebrum from the 6502 and leaves only the cerebellum to control the motor (I/O) functions. This is a good deal for you customers among our readers: you will have the opportunity to see in practice which approach works best, and you will be able to make a choice.
Speaking of a choice, those of you who love virtual memory will of course applaud LISA and its wonderful performance.
We have received a number of letters like the above about LISA, but have chosen up to now only to nod in the direction of LISA's performance shortcomings. Only a churl would pick on a new computer for having 'bugs', so we haven't mentioned these up to now. But enough time has passed that LISA should be deloused but we still get letters reporting severe bugs. So maybe we ought to start reporting them, LISA being a 68000 machine.
OUR ATTITUDE TOWARD LISA (we have told you this before): LISA is a 68000-based small computer with high marketplace visibility. The best thing that could happen to Digital Acoustics would be for LISA to be a smashing success. That would show the world that the 68000 is as good as we think it is, thus HELPING our sales! At $10,000 we will never lose a single sale to LISA. If anything, we are ticked off because Apple has not done a better job. Maybe they listened too carefully to THEIR customers praising virtual memory? (The customer is NOT always right!)
"...do I detect a slight indication that one FNE doesn't like COBOL?" Eric L Faulconbridge Australia
Eric, it's like this: COBOL is needed, just as maggots are needed. Each performs a useful task. We don't have to like either, and we don't - FNE.
"While I generally agree with Steve McIntosh (issue #23), there is one thing I must take exception to. Forth (not FORTH, it is not an acronym) is for small fast cheap systems, but Forth does not require a "fairly large start-up effort." I got Forth running in about three months, part time, having nothing but an assembler. I think it unlikely that anyone could get UNIX going on a DTACK/Apple combination with nothing but the Phase Zero assembler in that time. Another piece of evidence is that there are three, complete, independently done versions of Forth for the DTACK/Apple alone, not counting other 68000 implementations." Bruce W. San Pedro CA
Bruce, we think Steve was talking about a complete system with lots of utilities and a 600 page manual. That means (in our judgement) that Steve is correct from his point of view, while you are correct from YOUR point of view. Everybody wins. (If your Forth has 5 megabytes of utilities and a 600 page manual, Steve loses. We don't think Steve is worried.)
Now we must put on our editor's hat. You have probably noticed that we kid around a good deal about misspelling and grammatical issues in general. But since you specifically assert that FORTH should be spelled Forth, let us call your attention to the FORTH DIMENSIONS newsletter, in which FORTH is consistently spelled using all capital letters throughout, not just in the magazine's title. Then you use UNIX in all caps although, to the best of our knowledge, it is not an acronym!
DTACK you have correctly spelled in all caps. We adopted that spelling because that's the way the Motorola technical manuals have it. Have you noticed that our static board is 'GROUNDED' but the dynamic board is 'Grande' and our block-DMA board is 'Stuffer', always with italics? You assuredly have NOT noticed that the PHASE ZERO folks always refer to themselves using all capitals. At least you did not use "FORTH", "Forth" and "FIG-forth" in the first two paragraphs of your letter, as one correspondent did not long ago.
English is a pretty flexible language which can survive considerable violence done to it while still conveying an understandable message. We make an effort here to at least make consistent mistakes. (Having an engineer do the editing here is like having a fox guard the chickens!)
"...of course your 68008 card should have its own dedicated RAM. You could easily fit a 68008, buffers, eight 64K DRAM chips and support circuitry on the board... You state that the 68008 using the Apple II DRAM is only 3.9 times faster than the 6502. This increases to 7.8 when using its own high speed DRAM. What do you mean ONLY? The Z80 or 6809 should be so lucky. Yet look how popular they were/are." Charles M, APO NY
Charles, there ain't a lot of software for a 68008 board yet, you know - FNE.
"I have done two little benchmark tests:
B#1: MOVE.L #10000000,$6000 LOOP1 SUBQ.L #1,$6000 BNE LOOP1 B#2 MOVE.L #10000000,D1 LOOP2 SUBQ.L #1,D1 BNE LOOP2 RESULTS: Test 1 Test 2 IBS AP20 (7MHz) 96 sec 42 sec HOMEBREW 8MHz DRAM 56 sec 23 sec DTACK, 8MHz 36 sec 20 sec DTACK, 12.5MHz 23 sec 13 sec
"This shows quite nicely the influence of the speed of the memory used...
"...Modula-2 is, in my opinion, a VERY good language for programming large programs. Volition have done just a poor implementation with strange restrictions. They compile it to p-code (of course), but their compiler is not a precompiler to Pascal; even worse: their p-code is only partially compatible with the UCSD/Apple p-code, although their compiler runs under this operating system (sigh)." Oliver B. Hamburg W. Germany
Oliver, should Test 2 for the homebrew be 33 sec? 56 to 23 seems to be a larger improvement, proportionally, than for the other systems. Thanks for the information about Modula. We are terribly sorry to hear about all the stamps being sold out in the Hamburg area so that you could not answer inquiries - FNE.
"BDM has a contract to develop a fully automated combat simulation called Quickscreen for the Defense Nuclear Agency (DNA) and the U.S. Army Training and Doctrine Command (TRADOC). The Army wanted something that would run quickly on an Apple... we proposed an Apple with one of your boards attached, since a vanilla Apple just
doesn't have enough capability.
"We had recently started using the Corvus Concept on other projects, and it did have FORTRAN, so that is what we are using for development (actually, three of them). The Apple and Corvus machines share a common disk through a local network that Corvus sells.
"The simulation is fairly large. We put an early demonstration version of it an a 220K DTACK GROUNDED configuration and it barely fit. We expect to use 348K in the deliverable version. Future improvements could result in it being larger still. One of the main requirements for thi simulation is a large allocatable data array. Space in this array is constantly being re-allocated. Until the 68000 came along, a simulation of this kind hasn't run on anything smaller than a VAX.
"One question we are frequently asked is why we didn't just use a Corvus Concept. Aside from the fact that DNA's Request For Proposal (RFP) specifically preferred the Apple, the performance difference is significant. I figured that there is a factor of 2.5 difference based on clock speeds and wait states. The Corvus Concept, having a segment based operating system, uses a significant amount of time swapping from disk. It also doesn't allow segments larger than 32K of code. Virtually any program is multiple segment, since just the library routines pretty much fill one segment. A simple benchmark showed a thrash factor of 1.5 in a two segment program, on a machine with 512K.
"As we got some of our code working on the Corvus, I became very concerned about performance. A routine that needed to execute in a few tenths of a second at most was taking 3 or 4 seconds. Even the hardware performance margin and thrash factor from the benchmark couldn't cover that. When we finally loaded the whole thing onto the DTACK board, we found that the actual performance ratio was over two orders of magnitude! Of course, the major reason for the large difference is that the whole thing fit on the 220K DTACK board, but had to be swapped to and from the disk an the 512K Corvus.
"In defense of the Corvus Concept, it was designed to be a workstation, not a high performance number cruncher. It has many good features... The combination of the Corvus for development and the DTACK for the target machine gives us both ease of use and high performance.
"We hope in the future to go to an even quicker simulation using parallel processing, so I am most interested in your planned developments in this area... I suspect that the performance we could get using the DTACK board was a decisive factor in winning this contract." John G. McLean VA
Whew! Actually, we have compressed this letter considerably. It is most interesting that a 220K DTACK board runs OVER TWO ORDERS OF MAGNITUDE faster than a 512K Corvus because the 512K Corvus (apparently using virtual memory) needs to do constant disk swapping. That just happens to be consistent with what we have previously written about virtual memory systems, hmm? John has since reported in a telephone conversation that the troops at BDM diddled the Corvus operating system enough to get rid of ONE of those orders of magnitude, which is ALSO consistent with what we have previously written ("maintain a staff of programmers to hopefully correct the excessive swapping when it occurs"). See issue #9, page 11. Naturally, almost all of our readers expressed displeasure with our viewpoint at that time.
The operating system used by the Corvus Concept is precisely the kind of ridiculously over-complex operating system favored by most purveyors of 68000 systems. What's that? You say we are exaggerating? YOU don't think it is ridiculous that a 512K 68000 system runs OVER TWO ORDERS OF MAGNITUDE SLOWER than a 220K 68000 system which is not "enhanced" with a "wonderfully" complex operating system? Then rush right out and buy a $10,000 LISA, which has ALSO been "enhanced" with another "wonderfully" complex operating system. That's why it runs several keystrokes behind when running LisaWrite.
Do you suppose anyone is ever going to pay attention to our assertions that the way to use the 68000 in a personal computer is to have a very simple (hopefully INVISIBLE, in fact) operating system and programming languages which run as closely to assembly as possible (most certainly NOT a BASIC written in C!)?
The problem with being one of 32 sheep in the back of a stake-bed truck is that the truck eventually arrives at its destination. Having disgorged its passengers, the truck carries mutton and lamb chops, suitably iced, back to the railroad yard.
This writer, and most of our readers, personally get our hands dirty an a keyboard. When we make a purchasing decision, that decision is almost always based on what WE, each of us, personally wants for our own use.
Mainframes, for example, are not sold that way at all. When was the last time you heard of an IBM salesperson approaching a keypunch operator and offer a 3033 for sale? Similarly, a VAX 11/whatever is almost never purchased by an individual for exclusive use by that individual.
From 12 months ago and up until 6 months ago one read/heard a veritable frenzy of pronouncements that the mass personal computer marketplace was moving up to 16-bit processors (just now starting to come true) and that UNIX was the absolutely ideal 16-bit operating system and that, hence, UNIX was about to become THE mass-market operating system. This hysteria has died down a bit in recent months because it is evident that no such event is transpiring. But the people who are a bit slow getting "with it" are still trumpeting UNIX.
It is like this folks: the MASS marketplace caters to persons such as you and us who spend our money based on what WE want and what WE want to use. Your FNE has gone to considerable effort to study - not just read - the first two issues of UNIX REVIEW, which is a cross between a magazine and a newsletter for UNIX people. Although there is lots of stuff in both issues about marketing UNIX systems, we can report that there is NOTHING, repeat NOTHING in either issue that has anything to do with the person who sits down at the keyboard. If you pick up issue #2 and read the article beginning on page 28, see if YOU don't start feeling just a bit like proto-mutton. We did.
It is evident that UNIX remains, like the 3033 and the VAX, a system that is sold to honchos to tie a bunch of sheep to. We are sure that many slaughter-house workers are wonderful, sensitive human beings. A couple of the writers for UNIX REVIEW come off the same way. But the more we read UNIX REVIEW, the more depressed we get.
Nobody selling or even promoting UNIX gives a damn about the user. Since the user is also the PURCHASER in the mass marketplace, this is a counter-productive attitude.
As Steve McIntosh ably reported in the last issue, UNIX requires a level of involvement and expertise that most of us, who use computers maybe an hour or two a days are unable and/or unwilling to commit. UNIX is too damn overly complicated.
(Of the mass personal computer marketplace.) As reported elsewhere in this issue, UNIX systems inherently provide uncompetitive performance in a single-user system. Translation: UNIX has a spectacularly poor performance/cost ratio in a single- user system - and that is the only kind of system the mass-marketplace will consider.
We have, several times, expressed our surprise and dismay over Motorola's approach to selling its 68000 microprocessor. We even devised a fairly elaborate scenario which called for the chip salesmen to support the systems group and that EXORMACS-turkey via peer pressure. We have told you, several times, of our early experience seeing the rapidly receding back of the Motorola chip salesman when we declined to purchase an EXORMACS. We now have news for all but two of our 400 subscribers: it wasn't peer pressure.
During 1980, while the chip was real but had a bug list until the last quarter, there was a big fight going on between the Systems Group in Phoenix and the chip folks in Austin. The Systems Group wanted to get rich selling the $29,000 base-price EXORMACS whereas the chip folks wanted to sell chips. (Motorola sells more chips than any other company in the world, including T.I., which is about to slip behind NEC into the 3rd place slot.)
Well, Motorola's corporate honchos are headquartered in Phoenix, which meant the the Systems Group presented their arguments over cocktails at lunch while the chip folks sent memos from Austin. If you have any idea how big companies work, it will come as no surprise that the Systems Group won. It became official, though publicly unannounced, Motorola policy to do everything possible to support sales of the EXORMACS - and that included refusal to support any company which wanted to design 68000-based products without buying an EXORMACS. Like Digital Acoustics for instance.
The chip salesman who gave us such a good, though brief, view of his back was a company man executing official company policy.
The Systems Group folks decided that sales prospects for the EXORMACS would be enhanced if they could attract same of the software houses writing expensive packages for the VAX, Eclipse, Prime and S.E.L. to adapt their packages for the EXORMACS. To do this Motorola had to be able to assure those software houses that they could charge their accustomed $5000 - $15000 fee for their software products. Those software houses definitely did not want to compete with the folks selling $200 - $700 software for the Apple II or the folks selling $50 - $300 software for the Trash 80.
Therefore, Motorola did everything in their power to keep the price of 68000 software high. First, they made certain that all of their application notes on the 68000 were slanted at designing incredibly complex, expensive systems. Their technical gurus told people
at the seminars they conducted that the 68000 would always be an expensive part (an assertion that flew in the face of common sense at the time, and has since been proven false).
And, get this: THEY DELIBERATELY WITHHELD ANY TECHNICAL ASSISTANCE FROM ANY PERSON OR COMPANY THAT INDICATED AN INTEREST IN DEVELOPING A LOW-END 68000-BASED PRODUCT! We can now understand why the only two people at Motorola that we knew to talk to pleaded with us to put a $1000 - $1500 price tag on the Applesoft-compatible (originally CBM-compatible but the same code) floating point package instead of selling it for $10. And why ONE of those two stopped talking to us after we did it anyway. (Considering the now- revealed facts, we wonder why the other guy still spoke to us on occasion. We will not reveal his name, but he then worked in Phoenix.)
Please understand that what we are telling you is factual: it was Motorola's deliberate, official policy to keep the 68000 out of the personal computer marketplace. If cheap 68000-based products ever became available, the $30,000 EXORMACS would appear less attractive, and those guys writing software packages for the VAX certainly wouldn't want to write 68000 code for $10,000 if a similar software product was available for a cheap personal computer for $250.
What all this means is that the DTACK GROUNDED project (and product) was exactly and precisely what Motorola did NOT want.
The chip folks were well aware that a well-tuned production process can turn out enough microprocessors in one hour to fill the requirements of the EXORMACS folks into the next century. So where did they get to sell chips, not being permitted to promote the 68000 in low-end products? The phrase is "imbedded systems." In other words, 68000s were to be designed into disk controllers, communications multiplexers, military fire-control systems and such. However, there were others trying to sell into that same market.
Intel was pushing the 8086, Zilog its Z800X family, National the 16032 which was, no lie, going to be available any day now and even Fairchild with its 9445. (And let us not forget the forgettable T.I. 99000, which can switch contexts VERY swiftly, having no internal resources to speak of.) This meant that Motorola had to go after what the marketing folks call "design wins." In other words, they had to convince the design team leader to pick the 68000 and not a competing product as the "engine" for a microprocessor- based whingdilly.
This task was made more complicated by the fact that no inexpensive software development system existed, and that no application notes were available describing systems which were not incredibly complex. Many "imbedded microprocessor" whingdillys are quite simple. Only the fact that, as any competent design engineer can readily see, the 68000 really was the best microprocessor available has kept the 68000 from vanishing without a trace.
We hope everyone understands that a small company called Digital Acoustics was very, very unpopular among the Motorola folks. What we were doing was exactly and precisely what Motorola did NOT want to get done! We were (please excuse the expression) farting in Motorola's church!
Now, you might agree with us that this state of affairs was the stupidest way to sell a microprocessor conceivable. But remember, MOTOROLA WAS NOT TRYING TO SELL A MICROPROCESSOR, THEY WERE TRYING TO SELL A (poorly designed) $30,000 (BASE PRICE) MINICOMPUTER! If cheap 68000-based computers and software development stations were readily available, the guys designing, building and marketing the EXORMACS would be out of a job, along with the substantial number of software types employed in-house to support the EXORMACS.
If you look at this as a bunch of guys (the Systems Group folks) trying to hold onto a job, the situation takes a little more sense. Remember, the Systems Group held the home-field advantage, it being such easier to persuade a corporate executive over cocktails than with a written memo.
This state of affairs existed for two years, from 1980 until the summer of 1982. Midway through 1982 somebody (or somebodies) at Motorola noticed they were getting KILLED in the marketplace by the Intel/IBM team (this was before IBM purchased a sizable chunk of Intel outright). Additionally, sales of the EXORMACS were not up to projections because others such as Tektronix were selling much cheaper 68000 software-development stations.
Two years' marketing leadtime having been completely wasted, the chip folks were finally given the go-ahead to sell chips.
A number of things happened more or less simultaneously. A catalog of 68000 software vendors was hurriedly thrown together. Motorola actually phoned us asking whether we had software to offer! We said no, but that a company called PHASE ZERO did.
Next, Motorola threw together a package (part of which only existed an paper) of chips very similar to the chip set upon which Radio Shack's Color Computer is based. (You don't think Tandy designed the CoCo, do you?) This package included a 68008, 8ea 64K DRAMs, a graphics controller chip supporting sprites and presumably the ROMs and a DRAM controller chip. The package was offered for $150 each in (high) production quantities for delivery in late 1983.
Those of you who are pretty such locked into the Apple world may not know what a 'sprite' is. A 'sprite' is a block of pixels, say 16 X 20, which can be user-defined and then moved as an object with a single command. There are usually several sprites with differing priority levels. When a lower-priority sprite passes behind one with higher priority, it disappears. Every sprite, naturally, has priority over the background.
It is possible to simulate this in software but that is very slow. 'Sprites' in the Apple world tend to be few, simple and slow. The $200 Commodore 64 has a graphics controller chip which supports several prioritized sprites in HARDWARE! It also has a very good - make that superb - sound generator chip. The Apple IIe does not have either of these features. Now you know why so many folks want us to support the 64 with our DTACK boards!
So we just now found out about that chip set? No, what we have just now found out was that Motorola's (former) counterproductive sales policy was deliberate. We found out about the chip set about five minutes after Motorola offered the chip set to the Oddysey division of Magnavox, in Knoxville, Tennessee. You see, one of the engineers that Oddysey assigned to develop their version of the Trash-68 was not firmly convinced that Motorola could deliver the chip set at that price. Remember, Motorola had been telling people for two years that the 68000 would always be an expensive part and that it was exclusively suitable for big, complex, expensive systems.
So the engineer decided to ask somebody who knew about 68000s but was not employed by Motorola. You will never guess (we coyly assert) who he got hold of! (For the record, we told him that Motorola could deliver that chip set at that price in the first or second quarter of 1984 if not in 1983.)
Now, there is no such thing as being a little bit pregnant. Oddysey was not the only place approached by Motorola. Mattel's Intellivision division also went for the package and were actively developing their own TRASH-68 right up until after their last quarterly financial report ($156 million loss), after which the
project was terminated and all the people working on it were fired! (A friend of ours was shocked when an experienced 68000 assembly-language programmer applied for a job, explaining she had just been laid off!)
The best information we have is that there are two TRASH-68s, absolutely perfect for rock-shooting, coming down the chute. At least one of them will use CP/68K as the operating system (we will wait for the moans to die down from those of you who are familiar with CP/M). One of these will be from Oddysey, one will definitely not be from Intellivision, and Mackintosh is probably not the other, having been started more than a year before the chip set was offered.
The real question is whether the two TRASH-68 vendors will be able to produce in time for this Xmas' marketing window. The problem, you should not be surprised to know, is there ain't no software except for the VERY expensive packages developed by the minicomputer folks to support the EXORMACS. (Would you like to buy a $15,000 spreadsheet to run on a TRASH- 68?) We do know that the Oddysey folks will make a very nice job offer to anyone who can program the 68000. Do you want to move to Knoxville?
It is interesting to try to figure out who the second TRASH-68 vendor will be. Not Apple; they already have their Mackintosh project (which is also running late due to no software, by the way). Not Atari; their prematurely announced future product line does not seem to have an available niche for the 68008. Definitely not IBM; they own a major chunk of Intel, remember? Mattel/Intellivision is out on account of no dinero. Not Commodore; Uncle Jack likes to make his OWN chips. Can Tandy go IBM-compatible, as they are in the process of doing, and bring up a TRASH-68 at the same time?
This thing is going to have essentially the same graphics resolution as the CBM 64, or about 192 X 256 pixels (this is a limitation of current inexpensive chip technology and also a limitation of color TV sets. Nobody's going to buy a $2000 - $7000 RGB color monitor for a TRASH-68.) It will have an audio cassette interface like the 64; it will have an optional and very small capacity floppy disk accessory, just like the 64, and most folks will wind up with the accessory disk drive, just like the 64. Management will not plan for the large proportion of disk drives that will be purchased so there will be a shortage of drives, just like the 64.
(Are we boring anybody out there?)
The clock rate still be 4 to 6 MHz and the DRAMs will probably be time-shared between the 68008 and the graphics controller chip in Apple II and LISA fashion, meaning the performance will be equivalent to a 2 to 3 MHz 68008, which in turn is equivalent to a 1.2 to 1.8MHz 68000 with a real 16-bit data bus. (The 68008, which must make at least two memory fetches to get each instruction, is almost totally bus-bandwidth limited.)
Translation: the TRASH-68 is going to be a lot like the Commodore 64, only 2 to 3 times faster. It will be absolutely perfect for shooting rocks if anybody ever gets any software written for it. The bad news is that it will be CONSIDERABLY more expensive than the 64 (but under $1000 less the disk and color TV). Also, we do not believe Motorola included a sound chip in the set. So the T.I. chip, which is not nearly as good as the one in the 64, will probably be designed in instead. (Shooting rocks without appropriate sound effects is unthinkable.)
We don't know whether the TRASH-68s will appear this year or be delayed until next year (maybe even the third quarter of next year). We do know that software is needed but largely unavailable. (BOY, DO WE KNOW THAT software IS UNAVAILABLE!) Among the limited circle of folks who know about the TRASH-68s (and YOU are now inside that circle) there appear to be some questions over whether the market window has passed for the 68000. Anyone who has read pages 2 thru 6 of issue #21 of this newsletter will know that there are certainly reservations in our mind! That the 680XX can succeed in the MASS marketplace, that is.
But if those TRASH-68s are even modestly successful, it will prove an ENORMOUS benefit to us at Digital Acoustics! How so, you may ask?
That's 68000 Industry Standard Basic, the one written by Microsoft. That's the one with two levels of interpretation and which was out-benchmarked a year ago by Applesoft (we refer to Interface Age's review of the Fortune 32/16, which has a 5.5MHz clock and a 16-bit bus). We believe that Microsoft deliberately busted their 68000 BASIC (they have another explanation: more later) to protect their income, which is almost all from low-performance 8-bit devices. That includes the 8088, which is a low-performance 8-bit device.
Please note that the TRASH-68s will be offered for sale to the masses, not to lordly PASCAL and UNIX types. This means that it is absolutely essential that BASIC be made available. Since the ISB is badly busted on a true 16-bit 68000, it will prove ludicrously, make that
impossibly, slow on the TRASH-68. Think about a rock- shooting toy five times more expensive than the Commodore 64 but three or four times slower and you will get the picture.
Since the TRASH-68s will be no great shakes at performance under ideal circumstances, it will be essential that an efficient BASIC be used to justify the higher price tag versus the 64 (and other competing 8-bit designs). We believe that the absence of such a BASIC is a major factor impeding the timely introduction of the TRASH-68s.
It is with CONSIDERABLE pleasure that we present the bad news: any BASIC that will run in an acceptable fashion on a/the TRASH-68 will run MUCH, MUCH faster on a real 68000 with a real fast clock because the 68008 and the 68000 are ABSOLUTELY IDENTICAL software-wise. The only difference is the bus-bandwidth! The bus- bandwidth of our DTACK boards is about six to ten times greater than those TRASH-68s, so anything that will run on them acceptably (faster than the 64, which is equal to the Apple II) will run like a bat out of hell on OUR board(s)!
If the TRASH-68(s) is/are even moderately successful then Microsoft's slow slow 68000 ISB is DEAD DEAD DEAD! It couldn't happen to a nicer bunch of guys! (You might like to review issue #12, page 4, the three paragraphs under "THE RUMOR MILL" at this point.)
"I spend as such as 20 hours a day (sometimes as little as 0 though) on computer keyboards - an Apple II+, a TV1950, a DECWRITER 34, an ADM3A, AN ADM3A+, an ADM5, a FREEDOM 100, and a few lesser knowns (albeit more ancient). All of these have many differences, the worst of which is the placement of the hated control key. The DEC34 and TV1950 have thoughtfully placed it to the left of the shift lock key, giving one either extra exercise or a bit of the unexpected. The ADRs place theirs somewhere on the left, but sometimes the bottom row, and sometimes the next to the bottom as the Apple has it. Shifting one's reflexes (I became a touch typist in high school against my will but in favor of attending a class with a M/F ratio of 25:1) to get the control key when it is desired is nigh onto driving both 3, 4, and 5 speed manual transmissions.
"I say this lest the reader think that I an unfairly biased against the IBM PC keyboard. It, in comparison to the others I work on, is one tough sucker to type on (probably equivalent, carrying the analogy(?), to driving a 1939 Ford truck with a 3 speed non-
synchronized transmission - you have to double-clutch up or down shifting, in or out of gear). I as clearly not alone in this feeling since there are at least three commercial firms (profiteers one thinks) selling rich people a new and better keyboard.
"Why is this keyboard so horrible? Glad you asked. 1. The toggle keys (num lock which toggles cursor control vs. numerics, & shift lock which toggles upper/lower case) do not have LED's to show what is toggled. You get a row of numbers expecting a cursor movement to the left. Shift lock is really shift toggle - i.e., pressing the shift key on other keyboards always ALWAYS gives upper case - not so here, it gives you opposite case of whatever case is defined as normal which depends on half many times (even or odd) the shift lock (toggle) has been pushed. Note that this is not solved by hardware alone since it is done in software - the shift key actually is registered as a keypress and software figures out what to do with such a keypress. This shift toggle then makes for such fun (and many Anglo-Saxonisms) when what you press is not what you get.
"Ah well, there is more fun. The sound of the keyboard makes one believe he has a Mattel typewriter in hand - some like the feel and same do not. I have grown used to it just as I learned to double clutch the 39 Ford.
"The worst of the worst is the placement of the keys. Some are problems of software interacting with key- placement - e.g., ESC and 1 are very close together, and in BASICA ESC clears the line. Yep - about 10 times an hour. Other is purely hardware, and firms like Keytronics have cured those. They are placing a key between your left little finger and the shift key (it has a back slash an it). This means that you are very likely to not get a shift (e.g. to get the double quote for strings in BASICA) but rather something else - an international standard is what IBM calls it. That is not what I call it. Same thing with the RETURN key - Usually, placed 2nd to bottom row, one key over from right little finger resting place for all us touchers. Well one more key over and you got IBM. Means that one happens more like 100 times an hour.
"Now there are many other interactions (CNTL-NUM LOCK rather than CNTL-S to halt a listing, CNTL-SCROLL LOCK/BREAK rather than CNTL-C to stop a listing - neither of which is easy to find in the manuals about BASIC) of the keyboard, but the [F[N[E will probably have cut some of this already so th-tha-that-that's all folks." Bob Parks, St. Louis MO
Bob, that M/F ratio of 25:1 worries us ... you did tell us you are originally from Denver, not Frisco? It took an F/M (NOT M/F) ratio of 35:1 PLUS a threatened second study hall to get US to take typing - FNE.
If you have engaged them in combat but have failed to emerge victorious, ask them for a membership application - ancient saying.
Several readers and DTACK customers have pointed out to us that not everybody around is an electrical engineer or microcomputer expert, and that some folks would like some information on a somewhat more basic level. Let us give this thing a try here.
Perhaps the most common request we get is how the host and the DTACK board communicate with each other. Apparently everyone has forgotten issue 12, pages 6 and 7, which tell what is happening in a hardware/software context. But it is not really necessary to know what is happening in hardware to write successful software. Forthwith, an explanation of the software communications fundamentals. Before proceeding, walk over to a photocopy machine and copy the back page of this issue.
Six fundamental operations are required for communications from host to DTACK board and vice-versa. The host is always initially in charge, so it is necessary for the host to be able to reset the 68000. This leaves the 68000 in the bootstrap monitor. The bootstrap ROM uses a combination of command bytes and data bytes in a predetermined protocol to exchange data. Command byte $02, when followed by a three byte address, will cause the 68000 to transfer execution off of the bootstrap ROM so that command bytes may (depending on the software you write) no longer be necessary. This means we need to be able to send a command byte.
Finally, the host must be able to send a byte to the 68000 or receive a byte from the 68000 and the 68000 must be able to send a byte to the host or receive a byte from the host. All of these operations are outlined on the back page, which is a crib sheet.
We hope you are not offended by the crib sheet; we use these things all the time ourselves. We have had two 6502 crib sheets tacked to the wall over our drafting table for seven years now, and we still refer to them when writing 6502 code. The comparisons on the DTACK crib sheet are copied from the back page of issue #14, with two additional branches added that we had not formerly included. One of the reasons we did this crib sheet is that we kept pulling issue #14 out of our file when writing 68000 code to try to make our conditional branches go in the right direction.
RESETTING THE 68000: Just write a zero to the status port (NRSTAT), wait 100 microseconds or longer, and then write an 8 to the port. Voila! The 68000 will be reset. The reset code on the crib sheet uses the X register of the 6502 and will not disturb the content of the 6502 accumulator or Y register. Also, the 68000 is not held in reset long enough to destroy any contents of the dynamic RAM if you are using a Grande. All of the communication routines here will work without modification on both the GROUNDED static RAN board and the Grande dynamic RAM board.
SENDING A COMMAND BYTE: First we wait until the 68000 is ready to receive a byte. The first two instructions, BIT and BVS will be executed until the 68000 is ready (if you need to know more hardware details about what is going on, read issue #2, pp6-7 and review the BIT instruction in the MOS Technology programming manual). Once we determine that the 68000 is ready, we send a 9 to the WRSTAT port to indicate to the 68000 that any byte received will be a command byte. We use the X register in the 6502 to do this so as not to disturb the accumulator, which contains the command byte. Next we send the accumulator to the data output port (WRDATA). Finally, we store an 8 in the status port so that the next byte sent will not be improperly flagged as a command byte.
SENDING A DATA BYTE TO THE 68000: We once again wait until the 68000 is ready using a BIT - BVS instruction pair. Once we determine that the 68000 is ready, we store the byte in the 6502's accumulator in the data output port WRDATA. That's all it takes.
RECEIVING A DATA BYTE FROM THE 68000: We first wait until we know that the 68000 has sent us a byte. This is accomplished by the LDA - BPL 6502 instruction pair. Once we know a data byte has been received, we simply read the data input port (RDDATA) and return with the byte in the accumulator of the 6502.
Now we reverse roles; we look at communications from the 68000's point of view. The 68000 has fewer options; it cannot reset the host nor can it set a flag to indicate a command byte. In fact, the 68000 has no equivalent of the WRSTAT output port that the 6502 has. Otherwise communications occur in exactly the same manner, except using 68000 assembly code.
SENDING A BYTE TO THE HOST: We first wait until the host is ready to receive a data byte. This is accomplished by the BTST - BNE instruction pair. Then we move the byte from D7 to the data output port DATOUT. That's all it takes.
RECEIVING A BYTE FROM THE HOST: We first wait until we know that the host has send us a byte. This is accomplished by the MOVE - BPL 68000 instruction pair. Once we know that a data byte has been received, we simply read the data input port (DATIN) and return with the byte in data register 7 of the 68000.
Rather than looking for marginal things to fill the crib sheet with, we have left a sizable corner so that each of you can make notes to yourselves. We hope that this writeup - and the crib sheet - have been helpful, and that they accept our application...
Check the front pages of the sample source code we sent with your board to find out where WRDATA, DATOUT, etc. are located.
"Please make some announcements in the next newsletter:
Jeff has (evidently) been suffering from indigestion or something. Following is a product announcement???
Product Announcement: the Garage Computer Corporation is proud to announce its first product: The Trash-68 Unkit Computer!
Bill of Materials ----------------------------------------------------------------- 1 Apple II+ compatible motherboard A&T (Component $249 Systems, Inc., 723 Ninth Ave, Kirkland, WA 98033) 1 Apple replacement power supply (numerous suppliers) 79 1 KeyTronics KB200 (or EPS) detachable Apple keyboard 198 1 (Conroy-LaPointe 800-547-1289) 1 Vista Quartet (pair of double-sided drives with con- 650 troller, 320+320=640K capacity or std Apple 143K) (Conroy-LaPointe) 1 16K Ram card (several sources current Byte) 39 1 Videx Ultraterm (80 to 160 col display) 279 1 DTACK Grande 128K board (you know where) 795 1 Klugematic metal case (various suppliers) 35 1 Complete set free software, DSE 0 1 MINOS (?) 40 ----------------------------------------------------------------- Total $2364
The unkit plugs together; some manual dexterity required for the assembly of the case.
Result: a 192K 68000 computer with these advanced features: 12.5 Mhz processor, with RAM expandable to 1 Megabyte TODAY. Uses industry standard Apple bus for plug-compatibility with all Apple peripherals, just like the big bucks Corvus Concept. Advanced dual (optional triple and quadruple) processor design that runs all Apple software, CP/M (optional $139), MS-DOS (ugh-optional extra) and tho ever-growing base of 68000 software. COMES STANDARD WITH: compiled 68000 BASIC, 68000-linked Applesoft; optional Assembler ($40) and FORTH ($30). Halgol (the language of the future) SOON! UNIX available later this century.
DTACK SOFTWARE EXCHANGE
4326 CONGRESSIONAL DRIVE
CORPUS CHRISTI, TX 78413
--- INSTRUCTIONS FOR SENSENIG BASIC ---
Turn on your printer. So far, Silentype, Microline, and Epson printers are known to work. If yours won't, let us know.
Turn on your DTACK board. As the lights dim and the ominous low hum of dilithium crystals locking into power resonance fills the room...
Boot disk #1. A flashing cursor will appear.
Replace disk #1 with disk #2.
Type LD <return>
You will be prompted for a filename. Type INSTRUCTIONS <return>
When disk stops spinning, type TR <return> and you'll get them.
Policies of the Software Exchange:
And have we made a big one. We now have 700 to 800 megabyte-hours of 64K DRAM testing and we have not yet found a single memory error. It therefore appears that your FNE was wrong (and many of you, notably Hal Chamberlin, were right). Well, at least we were right about static RAM being faster and not needing a periodic "time out" for refresh.
A retrospective on how we fell into this hole: When the 64K DRAMS first appeared, there were in fact some problems. Lots of problems. Major problems. All of this was covered in the trade media in some detail, which we followed. Everybody went back into the lab for a redesign to fix the rather obvious problems. When the second generation 64K DRAMs began to be shipped, the frequent articles about problems in DRAMs began to fade away, slowly because of publishing lead times.
Here is where we goofed: we failed to note that the dog was no longer barking (there were no more articles about problems in 64K DRAMs).
Here are some of the things that happened during the re-design phase: bit-sense lines were folded so as to cancel the effect of alpha particles in many cases. The stored charge in each bit cell was made larger than the charge change due to an alpha particle. A 'bootstrapped' technique of writing data was used to place a larger charge in the storage cell. Improved techniques of applying the polyside protective coating were developed. (Polyside is a long-chain polymer which for some reason stops alpha particles.) In other words, a number of techniques were used to a attack the problem rather than depending on just one 'fix'. Based on the data we have, those fixes worked.
You should not get the idea that the original problems were not real. Intel, for instance, is only now getting back into production with THEIR second- generation 64K DRAM - and Intel INVENTED DRAMs!
The 256K DRAMs are just beginning to be sampled, and the horror stories are just beginning ta reappear. We hereby resolve: 1) to stand well clear of the 256K parts until they are thoroughly de-loused, and 2) to notice when all the stories about problems in the 256K parts disappear (that will be about two years from now).
It now appears that usable 256K DRAMs will appear in just about the same time frame as commercial, across- the-counter 68020s. So the minimum memory configuration, using 32 each 256K DRAMs, will be, uh, ONE MEGABYTE!
The L.A. Times (17 Sep) asserts that Apple is about to drop LISA's price: "Dealers have said Apple miscalculated the market for LISA and missed potential sales to small businesses by pricing it too high." Gosh! WHAT A SURPRISE! Gee!
Pursuant to simultaneous suggestions from Eric in Australia and Bill in the U.K. we are reinstating our old offer to sell a 4K static RAM DTACK GROUNDED board, LESS the 68000L12, for $495, FOB Santa Ana, CA. This means, unless they change the law on us again, that we can accept a $495 (U.S. funds) check from all those un- American furriners and ship a board air freight and customs collect. We CANNOT ship by any other means than air freight; insurance and traceability, you know.
But we cannot sell even a $10 diskette to such a customer later - the TOTAL LIMIT is $500. On the other hand, we can sell your neighbors a board also - another GROUNDED or a Stuffer - or even a diskette, if they have not bought a board...
These boards will have a 12.5MHz crystal and two 2016-1 or, more likely these days, the improved/equivalent 2016AP-10. And they will have been tested. BUT - they will not have the required 68000L12! So we are (very slightly) back in the export business, until they change the law on us again. Which those turkeys probably will.
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, II+, II, soft, LISA, LisaWrite: Apple Computer Co. Anybody else need a 164th million ack, have your legal beagles send us the usual threatening note.
SUBSCRIPTIONS: Beginning with issue #19, subscriptions are $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. The address is:
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
REDLANDS IS BACK! This issue we are publishing a subroutine used to evaluate an ASCII free form representation of a floating point number. Examples: 1, 1.00, +1E0, +1.000E-0 (all equal one). We are also publishing a flowchart for the subroutine! We have tacked some labels at intervals on the flowchart which correspond to the same labels in the source listing, which should help those of you who wish to follow the code as a way to start learning 68000 programming.
Grande update p.27
NUMEVAL : CLR FLAGS & 3 F.P. REGISTERS : GET 1ST CHAR : MINUS ? no :yes : GET SIGN FLAG : numev2 : PLUS ? no :yes : numev3 : GET NEXT CHAR : numev4 : yes ZERO ? :no : yes DECIMAL ? :no : 1 - 9 ? no :yes : FLOAT THE DIGIT STORE IN "INTEGER" & RETAIN IN FPACC1 : numev5 : GET NEXT CHAR : 0 - 9 ? no :yes : FPACC1 = 10 X FPACC1 STORE IN "INTEGER" FLOAT THE DIGIT ADD TO "INTEGER" STORE IN "INTEGER" & RETAIN IN FPACC1 : : E ? yes :no : DECIMAL ? no :yes decsvc : SET DECIMAL FLAG SET "TENTHS" = 1 :
SYNTAX ERROR decsv1 : GET NEXT CHAR : E ? yes :no : 0 - 9 ? no :yes : DIVIDE "TENTHS" BY 10 FLOAT THE DIGIT MULT TIMES "TENTHS" ADD TO "INTEGER" : esvc : "INTEGER" = 0 ? yes :no : GET NEXT CHAR : MINUS ? no :yes : SET EXP SIGN FLAG : esvc1 : PLUS ? no :yes : esvc2 : GET NEXT CHAR : esvc3 : yes ZERO ? :no : 0 - 9 ? no :yes : DIGIT TO "IEXP" (INTEGER EXPONENT) SET EXPONENT FLAG : esvc4 : GET NEXT CHAR : 0 - 9 ? no :yes : MULT IEXP BY TEN ADD DIGIT TO IEXP :
GETINP (SUBROUTINE) : GET THE NEXT CHAR : SPACE ? yes :no : GET CHAR FLAGS : LEGAL CHAR ? no :yes : RETURN notlegl : DISCARD RETURN ADDR : isynerr : REPORT SYNTAX ERR RETURN
The end of the string being evaluated is marked by a space. When a space is detected while fetching a char from the string, execution skips to "GETINPX". The subroutine return add- ress is discarded and then the sign flag, exponent flag, and exponent sign flag are examined to determine Whether the number in "INTEGER" is the final result or not. Error conditions are flagged by placing a non-zero byte in D7.
If there is no error, there will be a zero byte in D7 and FPACC1 will contain a floating point number which represents the ASCII input string.
getinpx : DISCARD RETURN ADDR : "INTEGER" = 0 ? yes :no : SIGN FLAG SET ? no :yes : NEGATE "INTEGER" : inpx1 : EXP FLAG SET ? no :yes : SET "EXPONENT" = 1 : inpx2 : "IEXP" < #160 ? yes :no MULTIPLY "EXPONENT" BY 1E160 & SUBTRACT #160 FROM "IEXP" : inpx3 : "IEXP" < #40 ? yes :no MULTIPLY "EXPONENT" BY 1E40 & SUBTRACT #40 FROM "IEXP" : inpx4 : "IEXP" < #10 ? yes :no MULTIPLY "EXPONENT" BY 1E10 & SUBTRACT #10 FROM "IEXP" : inpx5 : (ASSUME "IEXP" = N) MULTIPLY "EXPONENT" BY 1EN : EXP SIGN FLG SET ? no :yes : CALC 1/"EXPONENT" : inpx6 : MULTIPLY "EXPONENT" TIMES "INTEGER" : inpx7 : RESULT "INTEGER" NUMEVAL DONE!
3 ; 4 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 5 ; 6 ; ACCEPT A NUMERIC INPUT IN ASCII FREE FORMAT 7 ; 8 ; THIS SUBROUTINE EXPECTS A STRING OF NON-ZERO 9 ; LENGTH WHICH IS TERMINATED BY A SPACE CHARACTER. 10 ; THE STRING IS LOCATED IN LOCATION "STR". 11 ; 12 ; THIS ROUTINE RETURNS AN ERROR BYTE IN D7. IF 13 ; THERE IS NO ERROR, THE ERROR BYTE WILL BE ZERO. 14 ; THIS PERMITS USING THIS ROUTINE ON EACH CHAR 15 ; ENTERED DURING AN INPUT FUNCTION TO DETECT AN 16 ; ERROR CONDITION WITHOUT BOMBING THE PROGRAM. 17 ; 18 ; THIS ROUTINE DESTROYS NO REGISTERS EXCEPT D7. 19 ; 003588 48E7 FEFC 20 NUMEVAL MOVEM.L D0-D6/A0-A5,-(A7) ;SAVE REG'S 00358C 7E 0D 21 MOVEQ #13,D7 ;SET FOR 14 WORDS 00358E 307C 37C0 22 MOVE.W #FLAGS,A0 ;SET PTR TO CLEAR 003592 4258 23 NUMEV1 CLR.W (A0)+ ;FLAGS, IEXP AND 003594 51CF FFFC 24 DBF D7,NUMEV1 ; 3 FP REGISTERS 25 ; 003598 367C 3F80 26 MOVE.W #CHRMSK,A3 ;PTR TO CHR FLAGS 00359C 387C 1A80 27 MOVE.W #STR,A4 ;A4 PTS TO STR 0035A0 4EB8 36AA 28 JSR GETINP ;GET A CHAR OF STR 0035A4 0C07 00AD 29 CMPI.B #"-",D7 ;MINUS ? 0035A8 66 08 30 BNE NUMEV2 ;SKIP IF NOT 31 ; 0035AA 08F8 0000 37C0 32 BSET #0,FLAGS ;SET SIGN FLAG 0035B0 60 06 33 BRA NUMEV3 ;NEXT CHAR 34 ; 0035B2 0C07 00AB 35 NUMEV2 CMPI.B #"+",D7 ;PLUS ? 0035B6 66 04 36 BNE NUMEV4 ;SKIP IF NOT 37 ; 0035B8 4EB8 36AA 38 NUMEV3 JSR GETINP ;GET NEXT CHAR 0035BC 0C07 00B0 39 NUMEV4 CMPI.B #"0",D7 ;ZERO ? 0035C0 67 F6 40 BEQ NUMEV3 ;DISCARD LEADING 0 41 ; 0035C2 0C07 00AE 42 CMPI.B #".",D7 ;DECIMAL ? 0035C6 67 3E 43 BEQ DECSVC ;SERVICE DECIMAL 44 ; 0035C8 0407 00B0 45 SUBI.B #$B0,D7 ;SUBTRACT $B0 0035CC 0C07 0009 46 CMPI.B #9,D7 ;GREATER THAN 9 ? 47 0035D0 6200 00F0 48 BHI.W ISYNERR ;REPORT SYNTAX ERR 49 50 ; 0035D4 4EB8 378A 51 JSR DFLOAT ;FLOAT THE DIGIT 0035D8 4EB8 37B2 52 JSR STORINT ;STORE IN 'INT' 53 ; 54 ; *** NOTE THE DIGIT IS IN BOTH FPACC1 & 'INT' *** 55 ;
57 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 58 ; 59 ; THE FIRST INTEGER DIGIT HAS BEEN ACCEPTED; 60 ; SERVICE ADDITIONAL INTEGER DIGITS (IF ANY). 61 ; 0035DC 4EB8 36AA 62 NUMEV5 JSR GETINP ;GET NEXT CHAR 0035E0 0805 0004 63 BTST #4,D5 ;0-9 ? 0035E4 67 12 64 BEQ ETEST ;SKIP IF NOT 65 ; 0035E6 4EB8 332A 66 JSR FPX10 ;TEN TIMES FPACC1 0035EA 4EB8 37B2 67 JSR STORINT ;RESULT IN INT 0035EE 4EB8 3786 68 JSR CHFLOAT ;FLOAT THE DIGIT 0035F2 4EB8 37AA 69 JSR ADDINT ;ADD CHAR TO 'INT' 0035F6 60 E4 70 BRA NUMEV5 ;NEXT CHAR IN STR 71 ; 0035F8 0C07 00C5 72 ETEST CMPI.B #"E",D7 ;EXPONENT ? 0035FC 67 56 73 BEQ ESVC ;SKIP IF SO 74 ; 0035FE 0C07 00AE 75 CMPI.B #".",D7 ;DECIMAL ? 76 003602 6600 00BE 77 BNE.W ISYNERR ;SYNTAX ERR IF NOT 78 79 ; 80 ; DECIMAL RECEIVED; SERVICE DECIMAL DATA 81 ; 003606 08F8 0001 37C0 82 DECSVC BSET #1,FLAGS ;SET DECIMAL FLAG 00360C 21FC 10018000 83 MOVE.L #$10018000,TENTHS ;'TENTHS' = ONE 37D2 84 ; 003614 4EB8 36AA 85 DECSV1 JSR GETINP ;GET NEXT CHAR 003618 0C07 00C5 86 CMPI.B #"E",D7 ;"E" ? 00361C 67 36 87 BEQ ESVC ;SKIP IF EXPONENT 88 ; 00361E 0805 0004 89 BTST #4,D5 ;0-9 ? 90 003622 6700 009E 91 BEQ.W ISYNERR ;SYNTAX ERR IF NOT 92 93 ; 003626 3A47 94 MOVE.W D7,A5 ;SAVE DIGIT IN A5 003628 307C 3376 95 MOVE.W #TENTH,A0 ;CONSTANT 1/10 00362C 21D8 1902 96 MOVE.L (A0)+,S1 ;FETCH CONSTANT 003630 21D0 1906 97 MOVE.L (A0),S1+4 003634 307C 37D2 98 MOVE.W #TENTHS,A0 ;VAR 'TENTHS' 003638 4EB8 2220 99 JSR FPMUL ;'TENTHS'/10 00363C 5148 100 SUBQ.W #8,A0 ;PRT TO 'TENTHS' 00363E 4EB8 37B6 101 JSR STOR ;STORE IN 'TENTHS' 003642 3E0D 102 MOVE.W A5,D7 ;RESTORE DIGIT 003644 4EB8 3786 103 JSR CHFLOAT ;FLOAT THE DIGIT 003648 5148 104 SUBQ.W #8,A0 ;PTR TO 'TENTHS' 00364A 4EB8 2220 105 JSR FPMUL ;MULT TIMES DIGIT 00364E 4EB8 37AA 106 JSR ADDINT ;ADD TO 'INT' 003652 60 C0 107 BRA DECSV1 ;NEXT DIGIT 108 ; 109 ; 'E' RECEIVED; SERVICE EXPONENT DATA 110 ; 003654 0838 0007 37C4 111 ESVC BTST #7,INTEGER+2 ;INTEGER = 0 ? 00365A 67 66 112 BEQ ISYNERR ;ERROR IF SO 113 ;
115 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 116 ; 117 ; CONTINUE SERVICING EXPONENT DATA 118 ; 00365C 61 4C 119 BSR GETINP ;GET NEXT CHAR 00365E 0C07 00AD 120 CMPI.B #"-",D7 ;MINUS ? 003662 66 08 121 BNE ESVC1 ;SKIP IF NOT 122 ; 003664 08F8 0002 37C0 123 BSET #2,FLAGS ;SET EXP SIGN FLAG 00366A 60 06 124 BRA ESVC2 ;GET NEXT CHAR 125 ; 00366C 0C07 00AB 126 ESVC1 CMPI.B #"+",D7 ;PLUS ? 003670 66 02 127 BNE ESVC3 ;SKIP IF NOT 128 ; 003672 61 36 129 ESVC2 BSR GETINP ;GET NEXT CHAR 003674 0C07 00B0 130 ESVC3 CMPI.B #"0",D7 ;ZERO ? 003678 67 F8 131 BEQ ESVC2 ;DISCARD LEADING 0 132 ; 00367A 0805 0004 133 BTST #4,D5 ;0-9 ? 00367E 67 42 134 BEQ ISYNERR ;SYNTAX ERR IF NOT 135 ; 003680 0407 00B0 136 SUBI.B #$B0,D7 ;D7 = 1 TO 9 003684 31C7 37DA 137 MOVE.W D7,IEXP ;INT EXP 003688 08F8 0003 37C0 138 BSET #3,FLAGS ;SET EXPONENT FLAG 139 ; 00368E 61 1A 140 ESVC4 BSR GETINP ;GET NEXT CHAR 003690 0805 0004 141 BTST #4,D5 ;0-9 ? 003694 67 2C 142 BEQ ISYNERR ;SYNTAX ERR IF NOT 143 ; 003696 3838 37DA 144 MOVE.W IEXP,D4 ;FETCH INT EXP 00369A 76 0A 145 MOVEQ #10,D3 00369C C8C3 146 MULU D3,D4 ;10 X IEXP 00369E 0407 00B0 147 SUBI.B #$B0,D7 ;D7 = 0 TO 9 0036A2 D847 148 ADD.W D7,D4 ;ADD DIGIT TO IEXP 0036A4 31C4 37DA 149 MOVE.W D4,IEXP ;STORE INT EXP 0036A8 60 E4 150 BRA ESVC4 ;NEXT DIGIT 151 ; 152 ; GET THE NEXT CHAR FROM STRING. EXIT IF 153 ; THE CHARACTER IS A SPACE AND SEND AN 154 ; ERROR MESSAGE IF THE CHAR IS NOT A LEGAL 155 ; NUMERIC INPUT CHAR (0-9, +, -, ., E) 156 ; 0036AA 4287 157 GETINP CLR.L D7 ;CLEAR UPPER PART 0036AC 1E1C 158 MOVE.B (A4)+,D7 ;GET THE NEXT CHAR 0036AE 0C07 00A0 159 CMPI.B #" ",D7 ;SPACE ? 0036B2 67 16 160 BEQ GETINPX ;EXIT IF SPACE 161 ; 0036B4 1A33 7000 162 MOVE.B (A3,D7.W),D5 ;GET CHAR FLAGS 0036B8 0805 0003 163 BTST #3,D5 ;LEGAL CHAR ? 0036BC 67 02 164 BEQ NOTLEGL ;SKIP IF NOT 165 ; 0036BE 4E75 166 RTS ;RETURN WITH CHAR 167 ; 168 ; AN ILLEGAL CHAR HAS BEEN DETECTED 169 ; 0036C0 2C1F 170 NOTLEGL MOVE.L (A7)+,D6 ;DISCARD RETURN ADR 0036C2 7E 01 171 ISYNERR MOVEQ #1,D7 ;SYNTAX ERROR ID 0036C4 4CDF 3F7F 172 MOVEM.L (A7)+,D0-D6/A0-A5 ;RECOVER REGS 0036C8 4E75 173 RTS ;RET W/ERR MESSAGE
175 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 176 ; 177 ; A SPACE HAS BEEN DETECTED 178 ; EVALUATE PARTIAL RESULTS AND RETURN 179 ; WITH A ZERO ERROR I.D. (NO ERROR). 180 ; 0036CA 2C1F 181 GETINPX MOVE.L (A7)+,D6 ;DISCARD RETURN ADR 0036CC 0838 0007 37C4 182 BTST #7,INTEGER+2 ;INTEGER ZERO ? 183 0036D2 6700 008A 184 BEQ.W INPX7 ;DONE IF SO 185 186 ; 0036D6 0838 0000 37C0 187 BTST #0,FLAGS ;SIGN FLAG SET ? 0036DC 67 06 188 BEQ INPX1 ;SKIP IF NOT 189 ; 0036DE 08F8 0007 37C2 190 BSET #7,INTEGER ;SET SIGN NEG 191 ; 0036E4 0838 0003 37C0 192 INPX1 BTST #3,FLAGS ;EXP FLAG SET ? 0036EA 67 72 193 BEQ INPX7 ;RESULT IN 'INT' 194 ; 0036EC 21F8 37DC 37CA 195 MOVE.L E0,EXPONENT ;SET 'EXP' = ONE 0036F2 0C78 00A0 37DA 196 INPX2 CMPI.W #160,IEXP ;LESS THAN 160 ? 0036F8 65 0E 197 BCS INPX3 ;SKIP IF LESS 198 ; 0036FA 307C 383C 199 MOVE.W #E160,A0 ;PTR TO 1E160 0036FE 61 72 200 BSR MULEXP ;MULT TIMES 'EXP' 003700 0478 00A0 37DA 201 SUBI.W #160,IEXP ;SUBTR 160 FROM IEXP 003706 60 EA 202 BRA INPX2 ;TRY AGAIN 203 ; 003708 0C78 0028 37DA 204 INPX3 CMPI.W #40,IEXP ;LESS THAN 40 ? 00370E 65 0E 205 BCS INPX4 ;SKIP IF LESS 206 ; 003710 307C 3834 207 MOVE.W #E40,A0 ;PTR TO 1E40 003714 61 5C 208 BSR MULEXP ;MULT TIMES 'EXP' 003716 0478 0028 37DA 209 SUBI.W #40,IEXP ;SUBTR 40 FROM IEXP 00371C 60 EA 210 BRA INPX3 ;TRY AGAIN 211 ; 00371E 0C78 000A 37DA 212 INPX4 CMPI.W #10,IEXP ;LESS THAN 10 ? 003724 65 0E 213 BCS INPX5 ;SKIP IF LESS 214 ; 003726 307C 382C 215 MOVE.W #E10,A0 ;PTR TO 1E10 00372A 61 46 216 BSR MULEXP ;MULT TIMES 'EXP' 00372C 0478 000A 37DA 217 SUBI.W #10,IEXP ;SUBTR 10 FROM IEXP 003732 60 EA 218 BRA INPX4 ;TRY AGAIN 219 ; 003734 3E38 37DA 220 INPX5 MOVE.W IEXP,D7 ;FETCH INT EXP 003738 E74F 221 LSL.W #3,D7 ;MULT BY 8 00373A 0647 37DC 222 ADDI.W #NTBL,D7 ;ADD TABLE BASE 00373E 3047 223 MOVE.W D7,A0 ;A0 PTS AT 1EN 003740 4EB8 3772 224 JSR MULEXP ;MULT TIMES 'EXP' 225 ; 003744 0838 0002 37C0 226 BTST #2,FLAGS ;EXP SIGN FLG SET ? 00374A 67 08 227 BEQ INPX6 ;SKIP IF NOT 228 ;
230 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC. 231 ; 232 ; NOTE: 'EXPONENT' IS ALSO IN FPACC1 233 ; 00374C 307C 37DC 234 MOVE.W #E0,A0 ;PTR TO #1 003750 4EB8 22FA 235 JSR FPDIV ;CALC INVERSE 003754 307C 37C2 236 INPX6 MOVE.W #INTEGER,A0 ;PTR TO 'INT' 003758 4EB8 2220 237 JSR FPMUL ;MULT 'EXP' X 'INT' 00375C 60 0C 238 BRA INPX8 ;VALUE IN FPACC1 239 ; 00375E 21F8 37C2 1902 240 INPX7 MOVE.L INTEGER,S1 ;'INT' TO FPACC1 003764 21F8 37C6 1906 241 MOVE.L INTEGER+4,S1+4 ;(8 BYTES) 00376A 4247 242 INPX8 CLR.W D7 ;NO ERROR MESSAGE 00376C 4CDF 3F7F 243 MOVEM.L (A7)+,D0-D6/A0-A5 ;RESTORE REGS 003770 4E75 244 RTS ;NUMEVAL SUBR DONE 245 ; 003772 21D8 1902 246 MULEXP MOVE.L (A0)+,S1 ;FETCH @ A0 003776 21D0 1906 247 MOVE.L (A0),S1+4 ;(LOAD FPACC1) 00377A 307C 37CA 248 MOVE.W #EXPONENT,A0 ;PTR TO 'EXP' 00377E 4EB8 2220 249 JSR FPMUL ;FPACC1 X 'EXP' 003782 5148 250 SUBQ.W #8,A0 ;PTR TO 'EXP' 003784 60 30 251 BRA STOR ;EXIT VIA STOR 252 ; 253 ; SUBROUTINE; FLOAT CHARS $B0 - $B9 254 ; 003786 0407 00B0 255 CHFLOAT SUBI.B #$B0,D7 ;SUBT EXCESS $B0 256 ; 257 ; SUBROUTINE; FLOAT 0 - 9 IN FPACC1 258 ; 00378A 42B8 1902 259 DFLOAT CLR.L S1 ;CLEAR FPACC1 00378E 42B8 1906 260 CLR.L S1+4 003792 1C07 261 MOVE.B D7,D6 ;TEST FOR ZERO 003794 67 12 262 BEQ DFLTX ;DONE IF ZERO 263 ; 003796 31FC 1008 1902 264 MOVE.W #$1008,S1 ;SET EXPONENT 00379C 5378 1902 265 DFLT1 SUBQ.W #1,S1 ;DECR EXPONENT 0037A0 E30F 266 LSL.B #1,D7 ;SHIFT D7 LEFT 0037A2 6A F8 267 BPL DFLT1 ;REPEAT TIL NORMLD 268 ; 0037A4 11C7 1904 269 MOVE.B D7,M1 ;STORE MANTISSA 0037A8 4E75 270 DFLTX RTS ;DONE 271 ; 272 ; SUBROUTINE; ADD FPACC1 TO 'INT', RESULT TO 'INT' 273 ; 0037AA 307C 37C2 274 ADDINT MOVE.W #INTEGER,A0 ;PTR TO 'INT' 0037AE 4EB8 23A8 275 JSR FPADD ;ADD FPACC TO INT 276 ; 0037B2 307C 37C2 277 STORINT MOVE.W #INTEGER,A0 ;STORE IN 'INT' 0037B6 327C 1902 278 STOR MOVE.W #S1,A1 ;STORE FPACC1 (A0) 0037BA 20D9 279 MOVE.L (A1)+,(A0)+ ; STORE FPACC1, 0037BC 20D9 280 MOVE.L (A1)+,(A0)+ ; (8 BYTES) 0037BE 4E75 281 RTS ;DONE 282 ; 0037C0 <2> 283 FLAGS DS.W 1 ;FLAGS WORD 0037C2 <8> 284 INTEGER DS.W 4 ;FP REG 0037CA <8> 285 EXPONENT DS.W 4 ;FP REG 0037D2 <8> 286 TENTHS DS.W 4 ;FP REG 0037DA <2> 287 IEXP DS.W 1 ;INT EXP 288 ;
0037DC 10018000 290 NTBL DC.L $10018000 ;1E0 0037E0 00000000 291 DC.L $00000000 0037E4 1004A000 292 DC.L $1004A000 ;1E1 0037E8 00000000 293 DC.L $00000000 0037EC 1007C800 294 DC.L $1007C800 ;1E2 0037F0 00000000 295 DC.L $00000000 0037F4 100AFA00 296 DC.L $100AFA00 ;1E3 0037F8 00000000 297 DC.L $00000000 0037FC 100E9C40 298 DC.L $100E9C40 ;1E4 003800 00000000 299 DC.L $00000000 003804 1011C350 300 DC.L $1011C350 ;1E5 003808 00000000 301 DC.L $00000000 00380C 1014F424 302 DC.L $1014F424 ;1E6 003810 00000000 303 DC.L $00000000 003814 10189896 304 DC.L $10189896 ;1E7 003818 80000000 305 DC.L $80000000 00381C 101BBEBC 306 DC.L $101BBEBC ;1E8 003820 20000000 307 DC.L $20000000 003824 101EEE6B 308 DC.L $101EEE6B ;1E9 003828 28000000 309 DC.L $28000000 00382C 10229502 310 E10 DC.L $10229502 ;1E10 003830 F9000000 311 DC.L $F9000000 003834 1085EB19 312 E40 DC.L $1085EB19 ;1E40 003838 4F8E1AE5 313 DC.L $4F8E1AE5 00383C 1214B616 314 E160 DC.L $1214B616 ;1E160 003840 A12B7FE7 315 DC.L $A12B7FE7 316 ; @ 000037DC 317 E0 EQU NTBL ;PTR TO FP#1 318 ;
We received the initial production run of Grande boards, including the piggyback memory expander, late on the afternoon of 15 Sept. On the next day, Friday, we turned the main Grande board over to our wave soldering outfit, which seems less busy than our circuit board fabricator. At least, they promise us boards soon: Three trial boards the middle of the following week and the remainder a few days after that. So we should ship a couple of boards by 23 Sep and the remainder the following week.
Since we have only three full gallons on order (most are 128K with a couple of 512K), we chose to hand- solder the initial piggyback boards to expedite production. The production piggyback boards will also be wave soldered very soon, like maybe in two weeks.
Everybody does understand that the 700-800 megabyte- hours of memory testing we have given the Grande is equivalent to 12,000 hours testing 64K IIes? And that that is 7 weeks of 24 hr/day operation? It appears that power outages will, statistically speaking, cause more problems than alpha particles.BUT: REMEMBER WE ARE TESTING USING A SOLA LINE CONDITIONER! (See RELIABILITY, ANYONE? on page 6 of issue #19.)
Adam Osborne resigned from Osborne Computer about five seconds before they filed for Chapter 11 (bankruptcy). Let's see: before he went into the computer manufacturing business he wrote a column called "From the Fountainhead" for Interface Age magazine. In that column he used, as we recall, to express opinions which were not in accordance with the general industry perception. Does that mean that your FNE is going to be faced with competition from an unexpected quarter?
Would Adam spend all his ink convincing folks that a 5 or 7 inch CRT is just as readable as a 9 inch CRT?
According to today's (18 Sep) L.A. Times, Osborne was just the first domino. The Times predicts that the 200 companies making personal computers are going to shake down to 12 to 15 companies, plus additional companies producing peripherals. The Times further suggests that there are some specially areas where smaller companies who do not directly confront the big boys can survive.
Like we told you way back in issue #21, we plan to stay in business making Ferraris (or was that Cosworth-Ford engines?). If you do not think we are serious, maybe you should look at the front page of this issue again.
YE OFFICIAL DTACK CRIB SHEET: ----------------------------- COMPARISONS: Branch if A > B: CMP A,B BCS dst Branch if A >= B: CMP A,B BLS dst Branch if A =< B: CMP A,B BCC dst Branch if A < B: CMP A,B BHI dst Branch if A = B: CMP A,B BEQ dst Branch if A <> B: CMP A,B BNE dst COMPARISON FORMS (2): --------------------- CMP <ea>,Dn CMPI <data>,<ea> THE HOST RESETS THE 68000: -------------------------- RESET LDX #0 ;set D3 low STX WRSTAT LDX #25 ;set delay DELAY DEX ;delay 100+ s BNE DELAY LDX #8 ;set D3 high LDX RDDATA ;clr inp port RTS ;done SEND COMMAND BYTE TO THE 68000: ------------------------------- CMD BIT RDSTAT ;68000 ready ? BVS CMD ;wait til rdy LDX #9 ;set D1, D3 hi STX WRBTAT STA WRDATA ;send cmd byte LDX #8 ;set D1 low STX WRSTAT RTS ;command sent
HOST TO DTACK COMMUNICATIONS ---------------------------- Send a byte to DTACK: SENDBY BIT RDSTAT ;68000 ready? BVS SENDBY ;wait STA WRDATA ;send byte RTS ;done Get a byte from DTACK: GETBYT LDA RDSTAT ;byte avail? BPL GETBYT ;wait LDA RDDATA ;read it RTS ;done DTACK TO HOST COMMUNICATIONS ---------------------------- Send a byte to the host SENDBY BTST #6,STATUS BNE SENDBY MOVE.B D7,DATOUT RTS Get a byte from the host GETBYT MOVE.B STATUS,D7 BPL GETBYT MOVE.B DATIN,D7 RTS