Issue # 24 DTACK GROUNDED Newsletter - October 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

MORE HARDWARE STUFF:

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

Page 1, Column 2

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!

IEEE & IEC MATH STANDARDS:

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!

Page 2, Column 1

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.

Page 2, Column 2

A MULTIPLE-GUESS QUIZ:

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.

Page 3, Column 1

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..."

THE EMPEROR'S NEW ATTIRE:

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:

• The Pet/CBMs (various models)
• The Apple II/II+/IIe
• The TRASH-80 models I, III, IV
• The CP/M Z-80 machines, various
• The IBM PC

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:

• Sage (various models)
• Fortune 32:16
• LISA
• Epson HX-10

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.

WHY, HE'S BUCK NAKED!

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

Page 3, Column 2

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.]

THE SKY IS FALLING! SQUAWK

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 OBVIOUS EXCEPTION:

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

Page 4, Column 1

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.

MASS-MARKET UNIX? WHERE?

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.)

HAS YOUR FNE GONE CUCKOO?

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?

WHITHER TRANSPORTABLE CODE?

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

Page 4, Column 2

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!

UNIX SYSTEM V:

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?

Page 5, Column 1

PROVING A POINT:

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)

TANDY TOWERS, er, TROWER:

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

Page 5, Column 2

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.

RUMORS MONGERED HERE:

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?

Page 6, Column 1

MULTI-TASKING I:

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

Page 6, Column 2

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.

MULTI-TASKING II:

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.)

Page 7, Column 1

SHORT STUFF:

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.)

FASTER 68000s COMING?

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...

FOREIGN HOSTS:

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

Page 7, Column 2

address and/or phone number to others.

That means you, too, Earl. (Earl wants to hook up to a Z-80 system.)

THE PEDDLER MAN:

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 PEPSI MAN:

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.

THE SOAP MAN:

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.

THE CAN OF BEANS MAN:

Formerly the president of Consolidated Foods, he has

Page 8, Column 1

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?

THE TOOTHPASTE MAN:

This one has not arrived on the small computer scene yet, but he will.

MORE COMPETITION:

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...

PC WORLD WATCH:

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...

THE PARTS SHORTAGE:

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.

Page 8, Column 2

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!

ANOTHER TRUE STORY:

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.

SLOW, SLOW DYNAMIC RAM:

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

Page 9, Column 1

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?

TRUTH IN ADVERTISING:

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...

TRUTH (!) IN ADVERTISING:

[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.

IEEE MICRO WATCH:

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."

Page 9, Column 2

WE GET MAIL:

"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.

Page 10, Column 1

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!)

Page 10, Column 2

"...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!)

Page 11, Column 1

"...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

Page 11, Column 2

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

Page 12, Column 1

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!)?

MUTTON & LAMB CHOPS:

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.

Page 12, Column 2

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.

STRIKE ONE:

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.

STRIKE TWO:

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.

STRIKE THREE, UNIX IS OUT!

(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.

Page 13, Column 1

A HORROR STORY:

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.

EVEN MORE HORROR:

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

Page 13, Column 2

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.

WHITHER GOETH THE 68000?

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.

Page 14, Column 1

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!

RIDICULI; ABSURDUM MAXIMUS:

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.

THE RESUSCITATION PROJECT:

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.

Page 14, Column 2

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!

THE TRASH-68 COMETH!

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

Page 15, Column 1

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?

GUESSING GAMES, ANYONE?

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?

THE TRASH-68:

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?)

Page 15, Column 2

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.)

SOME QUESTIONS:

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?

THE DEATH OF THE 68000 ISB:

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

Page 16, Column 1

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.

GLEEFULLY: THE BAD NEWS:

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.)

WHY THE IBM PC DOES NOT HAVE
MY FAVORITE KEYBOARD:

"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-

Page 16, Column 2

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.

Page 17, Column 1

If you have engaged them in combat but have failed to emerge victorious, ask them for a membership application - ancient saying.

THE BEGINNER'S COLUMN:

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.

COMMUNICATIONS FUNDAMENTALS:

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.

YE DTACK 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.

Page 17, Column 2

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.

THE 68000 SIDE OF THINGS:

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.

Page 18, Column 1

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.

THE BLANK CORNER:

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...

THEM EQUATES:

Check the front pages of the sample source code we sent with your board to find out where WRDATA, DATOUT, etc. are located.

Page 18, Column 2

"Please make some announcements in the next newsletter:

1. Chet has made minor changes to the BASIC, OS and manual. Anyone who got the BASIC before Sept. 1 needs to return the disk [and postage] for the new manual and operating system.
2. My ZIP is 78413, NOT 76413. Make checks payable to the DTACK Software Exchange (we are now registered & legal).
3. Pete Soule's DAS hooked Applesoft requires the autostart ROM. Sensenig BASIC requires an Apple II+ (Applesoft in ROM?).
4. All disks should be copied with a nibble copier for best results (??-FNE)." Jeff Hull, DTACK Software Exchange

Jeff has (evidently) been suffering from indigestion or something. Following is a product announcement???

Page 18, Column 3

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.

Page 19

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:

1. Make checks payable to DTACK Software Exchange.
2. If you send a disk, DON'T send the SASE mailer home... just sufficient stamps. "We" have our own mailers now.
3. If you send us a check for disks, postage is included in the price.
4. If you have a problem with a disk, e.g. will not boot, please let us know immediately... if our drives get out of whack, it could produce a monstrous headache. Each disk is tried out briefly before mailing, that is, it worked for me-why not for you? If you write about a problem, describe your equipment in the usual excruciating detail.
5. Please don't call at odd hours. between 6-10 p.m. CST would be appreciated. I'm a pediatrician... don't be hurt if I'm not home in the evening. I'd prefer to get mail. I promise not to sell your name to Publisher's Clearing House. Honest.
6. Don't be shy about sending in programs or there will be no software to exchange.
7. If you have special interests or talents, please let us know so that we can connect you to the power grid.

Page 20

EVERYBODY MAKES MISTAKES:

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!

Page 20, Column 2

LISA WATCH:

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!

EXPORT STUFF:

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:

DTACK GROUNDED
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

Page 21, Column 1

        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 
           :

Page 21, Column 2

     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 
           :

Page 21, Column 3

        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

FLOWCHART NOTES

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.

Page 21, Column 4

 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!

Page 22

                           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 ;

Page 23

                          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 ;

Page 24

                         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

Page 25

                         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 ;

Page 26

                         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 ;

Page 27, Column 1

 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 ;

Page 27, Column 2

PRODUCTION Grandes!

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.)

Page 27, Column 3

COMPETITION REPORT?

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?

AN ECOLOGICAL NICHE:

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.

Page 28, Column 1

 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

Page 28, Column 2

 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