Issue # 26 DTACK GROUNDED Newsletter - December 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

If you think that the title looks different this issue, you're right. As we told you way back 27 months ago, in issue #2, the 68000 provides absolutely MARVELOUS performance except for floating point operations, where it really needs help from a dedicated math processor. At that time, the math processor we had in mind was the Intel 8087. We had not completely thought through the situation and discovered the software problem. But now (finally) we have math processor support for the 68000 AND IT CAN BE PROGRAMMED IN 68000 ASSEMBLY LANGUAGE, as REDLANDS (this issue) conclusively proves.

Gentlepersons, we propose a toast to the new publication "The Journal of Simple 68000/16081 Systems". Ready? ALL OF THE PERSONS OF AN OPPOSING GENDER IN THE WORLD... AND THE TIME TO ENJOY THEM!

WHAT? NO BORING BOARD?

We DO have some new 16081 math processor boards, twelve of them. The two we've tested so far seem to work fine. They can be used "as is" (almost) with the Grande but we have to kludge the no-wait state static RAm board a tiny bit (we have to add a gate function to the expansion part decode circuitry). It seess that when we designed our simple board 2 1/2 years ago, we only had in mind static RAM and/or LSTTL to hang on the expansion port. It turns out that both our VDHR 7220 graphics board(s) AND the 16081 board use NMOS LSI, and both need that extra gate to work properly. The extra gate is built into the Grande as standard equipment.

So why the "almost" after the no-kludge statement for the Grande? Well, we didn't bring the clock out to the expansion bus, so we have to replace a 74F74 with one which has wires soldered onto it to go up to a separate 2-pin connector on the 16081 board. But replacement is all that is necessary; no soldering or modifications to the Grande are needed.

We are going to make a very small printed circuit board to hold the kludge circuitry for the static RAM board.

Page 1, Column 2

If you want to participate early in an on-going development which we are not yet satisfied is complete, we will sell you one of those twelve experimental 16081 boards. If you have a static RAM board, you will have to return it to us for the installation of the kludge (some soldering and cutting of traces is necessary) unless you are such an accomplished hardware type that you are willing to assume the warranty responsibility for your own work. We expect to have the small kludge board available by 1 Dec.

The kludge board is warranteed but the 16081 board is (for now) experimental and carries no warranty. Do not buy one unless you recognize that the board is (at this time) EXPERIMENTAL. We call it the UBQ-1. Note the absence of the 'W' suffix which would indicate that we are confident that it works. As we write this, we only have two logarithm functions programmed for this board, Hart index 2665 for comparison with the same index in 68000 software in issue #16 and Hart index 1704 for slightly better speed (254 vs. 269 microseconds).

MISSED OPPORTUNITIES:

We delayed for seven months before deciding to jump on the 68000 bandwagon and we did not develop a 7220 graphics board as quickly as we could have. We have no intention of dallying THIS time; we are jumping on the 16081 so fast that WE are out in front of all the other 68000 folks and also in front of the National coprocessor folks like Otherwise Intelligent because a 12.5MHz 68000 works better, overall, with a 6.25MHz 16081 than the 16032 works with the 16081 as a coprocessor (the same clock speed, you know).

A 68000/16081 AP NOTE

is what the last - and the current - and future - issues of this newsletter are. It seems that National is not going to publish a 68000/16081 ap note, for perfectly valid company marketing objectives. Motorola isn't going to publish one for the same reasons. We don't think INTEL's gonna publicize that combination!

So what do we have here? We have a helluvan opportunity for DTACK GROUNDED, that's what we have! The 680X0, 7220 and 16081 are the most important chips around for us performance freaks because each is the BEST in its particular area. And DTACK has now thrown a saddle over all three! We're gonna ride those nags for all they're worth, believe it!

LUCKY DTACK GROUNDED ?

Some folks would rather be lucky than good. Others think luck is what happens when preparation meets opportunity. Whatever, we'll take it!

Page 2, Column 1

NATIVE CODE FORTH:

"The native code FORTH compiler for the Apple/DTACK combination is now ready. It's called Ira, since it works with Gershwin, and assumes that Gershwin (my FORTH interpreter) is an the system. Ira is distributed as a source file, along with a file of compilable FORTH utilities. Also supplied is a ten page user's guide, giving capabilities, limitations, error messages, and examples.

"Ira's forte is good code. It produces code which uses the registers extensively, and which does good local optimization. Due to the optimization and the power of the 68000 instruction set, the code is the same size, sometimes even smaller than the original Forth. This would not be possible, for example, on a machine like the 6502. For example A @ B @ + C ! compiles into three instructions, only 12 bytes, while the original FORTH takes 14 bytes.

"Ira is not a full compiler for FORTH. It will compile arithmetic, bitwise boolean operations, comparisons, and control structures such as IF-ELSE-THEN and DO-LOOP. It will not compile calls to other words.

"As for performance, Ira will match anything, except handcoded assembly. For example, on the Byte benchmark (sieve of Erastosthenes), code compiled by Ira runs in 1.65 seconds. That compares with 10.7 seconds running the code on interpreted FORTH, and 1.55 seconds running the FORTRAN version on a VAX 11/780 using DEC FORTRAN. Other words have similar performance; an improvement of 5 to 6 over interpreted FORTH.

"The compiler does not need to be maintained in memory after the compiled words have been created, so large vocabularies can be handled.

"Ira is now available at a cost of $30 from:"

BRUCE WALKER
900 W. 14th ST. #10
SAN PEDRO, CA 90731

The above is a press release from Bruce. If you do not already have Gershwin, include another $30, total $60. If you want the source for Gershwin as well, include $15 on top of that, total $75.

Bruce, you actually let a VAX 11/780 outrun your 12.5MHz DTACK board? Shame!

CALLING ALL PROGRAMMERS:

Peelings II magazine is going to review the DTACK, Saybrooke, Qwerty, and PDQ 68000 boards. If you want YOUR software package to be reviewed, send a review

Page 2, Column 2

copy AND CLEAR INSTRUCTIONS to Peelings II. If your software is a language, demo programs on disk AND CLEAR WRITTEN INSTRUCTIONS will be very useful. When reviewing lots of stuff as PEELINGS II is going to do in this case, the reviewer(s) will not have time to screw around for several days discovering how your wonderful software works. Peelings has a 92K 12.5MHz static RAM DTACK board. Send your review copy AND THE CLEAR WRITTEN INSTRUCTIONS to:

John Martellaro
Peelings II magazine
2260 Oleander
Las Cruces NM 88004

For those of you who are not familiar with Peelings II, it is an Apple-related publication which in the past has specialized in software reviews. As you can see, they are broadening their coverage to include hardware as well. If you are an Apple person, you really should subscribe to this magazine. The rate is $21/year (9 issues). Send your check, if you are interested, to the above address but leave John's name off - his secretary won't let him touch the checks, just like here at Digital Acoustics.

DTACK (tiny?) C COMPILER:

[The following information was received yesterday as this is written. We understand that this is NOT a FULL C in the UNIX sense but that it is CONSIDERABLY extended beyond a tiny-C. More complete information will be published in future newsletters.]

"The SEK-C (TM) compiler... accepts a text file as an input, which should contain C language statements (and assembly language if bracketed by #ASM and #ENDASM). It generates an assembly language text file as an output. Presently the compiler is configured to be compatible with the MINOS operating system and Phase Zero's cross-assembler.

"The compiled code is optimized in a multi-pass process (all the generated code is still in memory, so this happens VERY quickly). In contrast to interpreters, this compiler generates native code, and thus will ultimately (in version 2.0 and beyond) produce very fast execution.

"For comparison with the quality of other C compilers, the SIEVE OF ERASTOSTHENES benchmark (BYTE, Jan '82) is executed in 4.2 seconds for 10 iterations. This is faster than ANY of the other C compilers they discuss (although we do have the advantage of 12.5MHz).

"Version 1.0 of the compiler is $95. The first 20 customers will receive a free upgrade to version 2.0 when it is available (6 months?). This version will

Page 3, Column 1

feature floating point data types, including a set of floating point subroutines stolen from Digital Acoustics' REDLANDS. (I intend to ultimately include support for the Nat Semi floating point math processor as soon as Digital Acoustics makes this available.) [We got production boards, Charles. The ball is firmly in YOUR court.]

"If anyone is interested in a high level language which will turn their attached processor into a device which rivals a VAX, send $95 (U.S. funds) to:'

Charles Lougheed Bennett
5Y Hibben Apts, Faculty Rd.
Princeton NJ 08540

(MANY) OOPS! DEPT:

It turns out Terry didn't misread a decimal place after all. We decided that 2500.00088 on the Apple just HAD to be the same as 2500.00009 on the Pet. Nope! Terry offered to provide the benchmark as a computer printout. As if we would doubt his word! (Is a notary public handy in El Cerrito, Terry?)

NUMBER OF REGISTERS:

24 bits gets you TWO MILLION floating point registers. 131,072 registers (p20) is what you get with a 20 bit address space (8086, 68008). Everybody knows that!

BUSTED CRIB SHEET:

Ye official DTACK crib sheet (issue #24, back page) has a fouled-up "THE HOST RESETS THE 68000". Check the 6502 source code we sent you until we regain enough confidence to publish a new routine.

THAT 16081 ACCUMULATOR:

We discovered on the day BEFORE we took #25 to the printers that the Nat Semi 16081 does not have an accumulator in the usual sense. Oh, yes; the 16081 does have eight registers, but only for SINGLE precision arithmetic. For double precision, it only has four registers.

And that IN5089 diode on p26 should have been a IN5059. How the abbreviation for "Unbelievably Quick and Dirty" got switched to "UBQ" - twice - on the cover page we dunno. On the back page, the PAL chip U1 should have (bar) AS as an input plus A9 thru A23 inclusive. How the abbreviation for "Unbelievably Quick and Dirty got switched to "UBQ" - twice - on the front page we dunno.

When the "OOPS" page gets longer than the preceding newsletter, we quit. Hey! Stop applauding!

Page 3, Column 2

THEM TRASH 68s:

It is possible that the recently-announced DIMENSION 68000-based computer may be the second "low-priced" 68000 computer. If you are most familiar with the $30,000 EXORMACS, the DIMENSION might look low-priced, and it does (will?) come with CP/M-68K. The article in EET 10 Oct '83 asserts that there will be lots of software introduced "next year." (Where have we heard that one before?) Actually, the DIMENSION may be an interesting machine when it appears. The brochures we have seen use an artist's rendition, NOT a photograph.

It is said that the folks behind the DIMENSION were involved with the original TRASH-80 Model 1. We emphasize "said": success has a thousand fathers but failure is an orphan, as we were reminded this morning reading the WSJ interview in which Adam Osborne asserted that he was not responsible for the bankruptcy of Osborne Computer.

Oddysey's TRASH-68 apparently isn't going to make the XMAS '83 selling season or we would have seen something about it by now. We'll have to wait until next year to shoot rocks using 32-bit registers.

GHOSTLY PEANUT:

It is now evident that Peanut is going to be introduced next Tuesday, Nov 1. Yesterday (today is still the 29th) the Wall Street Journal ran a long front-page story about this computer, and asserted that it "is a rifle aimed at Apple's cash cow, the Apple IIe". We thought we would tell you OUR opinion: The larger of the two Peanut, er, PCir, models is a rifle aimed at Apple's cash cow, the Apple IIe.

We do not always disagree with the media.

[later] O.K. so Peanut & PCjr have been released, but you can't buy one until the first quarter of next year. But IBM will ship a limited number of demo models to retailers. You don't suppose the limited number of demo models will have 8088 CPUs while the production stuff to be sold in the first quarter will have the more cost-effective 80188 CPU? (See "THE FACTS" REVISITED elsewhere in this issue.)

COMMODORE STUMBLES:

Or so the stories say. Commodore has two problems right now. The first is that they STILL can't make enough 64's to keep up with the demand. But they are trying hard, and quality control IS suffering.

The other problem is the severe shortage of disk drives. The recent writeup in Infoworld, quoting Ron Jeffries, is not quite right. (ln fairness to Ron, we

Page 4, Column 1

got the straight scoop from Electronic News, AFTER Ron had published his version.) What happened is, Commodore sent out an erroneous schematic to its suppliers and said, "Build this!" The suppliers did, and the result didn't work.

ALPS is (was?) merely the largest supplier of Commodore disks. Jack Trameil decided he could bully ALPS into paying for the shipping costs and revision costs involved in correcting the problem. ALPS replied, "No way!" Jack said, "Then we won't pay you!" ALPS proceeded to stop manufacturing Commodore disks! Since Commodore needs ALPS more than ALPS needs Commodore (for now) and since ALPS can undoubtably prevail in a court of law over the payment, we expect Jack to kiss and make up soon.

What is involved is, get this: 300,000 completed but unshippable disk drives! According to EN, the raw cost is $100 per disk, so Commodore is sitting on ten cents worth of 1541 disk drives for every man, woman and child in the U.S.

But as soon as the revisions are made - which involves replacing some LSI - the disk shortage will be somewhat relieved, especially if Jack and ALPS make up.

Persons who are hoping for Commodore to FAIL, however, should focus their attention on the fact that Commodore's problems continue to be an inability to produce enough product to meet demand. This is NOT the problem that Osborne, T.I., Intellivision, Victor, Fortune, Vector Graphics, etc. have had!

You think 300,000 is a lot of disks? It is less than 3 month's supply! And that's just for the Model 64! (300,000 disk drives would last Fortune Systems into the next century.)

[The following report was written by our young project engineer, who attended a briefing hosted by the U.S. Department of Commerce on export limitations.]

WHY WE CAN'T EXPORT

Any product which leaves the United States needs to have a export license (unless the destination is Canada). There are two different types of export licenses, general and validated. The products which we manufacture fall under the validated license category which would means that for every customer we sell to we must apply for another license.

Now suppose someone in another country wants to buy a 128K Grande from Digital Acoustics and suppose Digital Acoustics is willing to try and export the product. The potential customer, following the strictly adhered to policy of Digital Acoustics, sends a check for the

Page 4, Column 2

board. Now both Digital Acoustics and the potential customer must fill out in duplicate the Statement By Ultimate Consignee and Purchaser. This form is one sheet of paper with information to be filled in on both sides. A photocopy of each side on a separate piece of paper is unacceptable to the Dept. of Commerce. One of the many questions asked on this form is the specific ultimate use of the product. This question has to be answered in detail; the decision of whether or not to grant the license is largely dependent upon this response. At this point, we now need to fill out the application for export license. Also for some countries, an International Import Certificate issued by the government of the country of destination must be sent with application for export license and the Statement By Ultimate Consignee and Purchaser.

Attached to these documents we would staple a self addressed, stamped postcard. When the Department of Commerce receives these documents they will assign a case number to it, write it on the postcard, and mail it back to us. Now we wait. If after 30 days we have not heard anything from them, we may then telephone them, give them the case number on the postcard they mailed back to us, and they will tell us the status of the case. The wait is usually 6 to 8 weeks.

If the form is filled out correctly, the application will either be rejected or granted. If the form is not filled out correctly, it will have to be done again. If the application was rejected, Digital Acoustics would then return the would-be custamer's check, which we have had for up to 2 months or longer. If the license was granted, the process becomes a record keeping job.

Digital Acoustics must now fill out the Shippers Export Declaration form. On this form and everything else that will go with the Grande out of the country the following statement must be stamped: "THESE COMMODITIES LICENSED BY THE UNITED STATES FOR ULTIMATE DESTINATION _________ AND FOR DISTRIBUTION OR RESALE IN _________ DIVERSION CONTRARY TO U.S. LAW PROHIBITED.

On the back of the export license are many blanks. These blanks are for Digital koustics to keep a record of how the Grande was shipped throughout its entire journey including flight numbers, trains, trucks, etc. This is information that is required and that Digital Acoustics would have to spend time acquiring. Once this travel log is filled out we must send the license, keeping a copy for our records, to the Department of Commerce.

The entire procedure would take the profit out of our products (especially the Grande). We are not set up to handle the paper work involved (especially the tracking down of the method of shipment).

Page 5, Column 1

BENCHMARKS REVISITED:

First let us add some additional data points to the benchmarks published in the last issue. All of the following data was taken using Terry Peterson's benchmark as published at the bottom of page 12 in the last issue. We have included 5 results from the last issue and added some new results which may be of interest:

 Language             Version      Rel RMS Err    Time    Bits  Mant  Grd 
 CBASIC2/Eagle II                  4.56E-6     2740.0s    25.9   24    NO 
 Applesoft               II+       2.38E-7      488.1s    33.1   32    NO 
 IBM PC/BASICA (S.P.)   1.10       6.83E-5      205.0s    25.0   24    NO 
 Applesoft w/DTACK                 1.29E-9       34.6s    40.7   32   YES 
 Tasc w/DTACK                      1.29E-9       24.5s    40.7   32   YES 
 IBM PC/BASICA (D.P.)   2.00       1.41E-14     962.7s    57.2   48   YES 
 LISA 68000 BASIC                  9.30E-14     500.0s    54.4   53    NO 
 DEVELOPMENTAL 68000 PASCAL        4.60E-17     250.0s    65.4   53   YES 
 IBM PC, COMPILED (SEE TEXT)       2.21E-14     173.0s    56.5   48   YES 
 DTACK 68000 #2,  HALGOL/48        4.10E-12      23.0s    49.0   48    NO 
 IBM PC w/MICROWARE 8087           9.31E-14      21.0s    54.4   53    NO 
 DTACK 68000 #1, HALGOL/48         4.10E-12      19.2s    49.0   48    NO 
 DTACK 68K/16081 (predicted)       1.30E-13       4.0s    54.0   53    NO 
 IBM 3031 FORTRAN          SAS       (SAME)      2.76s    52.7   48   YES 
 IBM 4341 gp2 FORTRAN      SAS     3.09E-13      1.86s    52.7   48   YES 
 IBM VS FORTRAN (S.P.)     V.3     1.13E-3       1.41s    20.9   24    NO

The first five items above are reprinted from the last issue. Then we have IBM's PC running BASICA in double precision, measured by Terry P. The ninth line was measured by Bob P and is supposedly the same program except compiled. We suspect the compiler Bob used has a different floating point package than the interpreter or the time differential would not be as great. Since Bob's much faster program had a larger relative error, this seems reasonable. Bob then measured the same compiled BASICA program, only using Microware's 8087 support package. The result is a LOT faster but still slower than the DTACK GROUNDED 68000 static RAM board without math chip support!

DTACK #1 is the static RAM board with no wait states and DTACK #2 is the dynamic RAM board with 1 wait state. This data teas taken using HALGOL/48 with the floating point and transcendental packages published in issues #15 and #16. HALGOL/48 refers to the fact that the floating point package in issue #15 is the one used, and that package has a 48 bit mantissa. This is primitive, non-interactive HALGOL. If you have forgotten what primitive HALGOL looks like, check the back page of issue #11.

We are really sticking our necks out on the next item, which is PREDICTED performance, not measured. The

Page 5, Column 2

reason we are sticking our necks out is that we are going to have to do that FOR REAL. Today is Oct 21 and we will be ordering production, repeat PRODUCTION UQD-1W's within two working days. (The board layout is complete and is being double-checked. All nine I.C.'s of it.) When we predict the time at 4 sec, give us +/- 1 second. The reason for the accuracy prediction is that with 5 extra bits in the mantissa, the accuracy should be 32 times better than the package we have already written.

And then we come to dear LISA with her wonderful, modern BASIC which is written in a mixture of PASCAL and assembler. Please note that it is indeed slower than conventional Applesoft when running floating point (but faster for integer arithmetic). "DEVELOPMENTAL 68000 PASCAL" is a contributed benchmark taken on a 68000 machine which is still in development (in other words, it has not been released), running under PASCAL. We forget the (code) name of the machine, as we have also forgotten who sent us this benchmark. It is considerably more accurate than any other result, since it uses a "temporary real" format for chained floating point calculations which includes a 64 bit mantissa. It is also more than ten times slower than HALGOL/48.

For reference only, we have tossed in some mainframe data. SAS is the "Statistical Analysis System." Both benchmarks have the same error because they use the same software package. Both benchmarks were timed in batch mode, NOT timesharing mode. The last result is run on IMN's VS (Virtual System) FORTRAN V.3 in single precision and the relative error of 1.13E-3 is NOT a misprint. That huge error SHOULD shock anybody, but it turns out that it does not surprise persons who are familiar with IBM's single precision package. We are told that that package is sometimes called "half precision" and sometimes called "joke!" Many persons feel that IBM's single precision package should never be used for any serious purpose.

TIMING CONCLUSIONS:

Heavy number-crunching produces timings which are a function of the CPU used and the precision of the package. It is therefore shocking how SLOW LISA is, even though we have been telling you about Microsoft's wonderful 68000 BASIC since Aug '82 (see issue #12, page 4, col 1 and issue #16, page 1).

Next, we note that HALGOL/48 is about one order of magnitude faster than the IBM PC (a 5MHz 8088).

Page 6, Column 1

The DTACK 68000 running HALGOL/48 is nearly as fast as an 8088/8087 combination, if slightly less accurate. Both are only one order of magnitude slower than legitimate mainframes (the IBM 3031 and 4341 gp2). We honestly did not think that mainframe performance could be so closely approached by the 68000 or by the 8088 with 8087 support. We are going to have to stop ridiculing the IBM PC-related copy writers who keep asserting that the IBM PC with 8087 support provides mainframe performance. It most certainly does not, but the difference is only one order of magnitude. Put it this way: the PC with an 8087 can see a mainframe on the horizon.

The predicted performance of the 68000/16081 performance is less than half an order of magnitude slower than a couple of legitimate mainframes - and more than half an order of magnitude better than the IBM PC with 8087 support. If the PC with an 8087 can see a mainframe on the horizon, the 68000/16081 lives in the same neighborhood with the mainframe. Please understand that the mainframes cited are not supercomputers but they aren't obsolete dogs either. The 4341, at least, is still in production.

(Pick a mainframe sufficiently distant in time and your hand calculator has mainframe performance,)

We have not retained the benchmarks of the various PET systems from the last issue because they are so similar to the Apple benchmarks. Just take the Apple timings and multiply them by 1.15 (because of the 60 interrupts/sec on the PET which give that nice software timing capability).

The DTACK/UQD-1W combination will not have mainframe floating point performance BUT IT WILL BE CLOSE! It will be DAMNED close!

ERROR CONCLUSIONS:

We did not fully understand what we were measuring when toe wrote the last issue. The fact is, a severe error bias is inherent in both the original Dr. Dobb's benchmark and also in Terry P's revised benchmark. However: it turns out that this bias provides ADDITIONAL information about a floating point package that would otherwise be difficult to ascertain. Once this bias, and the additional information it makes available, is understood we think you will prefer it over unbiased benchmarks.

The problem - and the benefit - is the argument passed to the TAN (tangent) routine. We start with a number which is an integer from one to 2500. After squaring and taking the square root, any worthwhile mathematical package will return the original integer with no error. We performed this test on our 62-bit

Page 6, Column 2

floating point package using HALGOL/48 and the error was in fact zero, as expected. The error will NOT be zero using Microsoft's 6502 BASIC because the square root is calculated by taking the log, dividing by two, and performing EXP. This saved a few dozen bytes of code but does introduce errors and also takes a long time (50 milliseconds) to calculate.

So, we go into the log/exp pair (hopefully) using our original integer. We exit the log/exp pair with a small error, as a reasonable person might expect. The number presented to the ATN function is not the original integer, in general, but the original integer perturbed slightly.

When an ATN (arc tangent) calculation is performed, we are telling the calculating device, "Here is a number which is a tangent of an arc. What is the arc whose tangent is this number?" The ATN is supposed to return the PRINCIPAL arc, which lies between minus #PI/2 and plus #PI/2, or minus 90 degrees to plus ninety degrees. In BASIC, arcs are measured in radians, not degrees so we will return an arc between -#PI/2 and +#PI/2, or roughly -1.57 to +1.57.

As it happens, most of the numbers passed to the ATN function are numbers corresponding to an arc which is very near plus 90 degrees, or +#PI/2. Since we are mapping a very large number (96% of the numbers are over 100 and 80% are over 500) into a very small number - about 1.57 - the (small) errors which we picked up during the log/exp process nearly vanish and we are left with another, different, small error, which is the (hopefully small) inherent imprecision in calculating the arc. Let us call this error, which will be on the order of half a least bit in the mantissa (RMS value), epsilon.

Now we arrive at the final step, which is APPARENTLY to calculate the TAN (tangent) of an arc whose tangent is the original large integer. But what we are really doing is calculating the tangent of an arc which is different from the original arc by epsilon, and so the tangent calculation, if done correctly, will NOT return the original integer. The problem is, the tangent function maps a very small number (appx 1.57) into a very large number (96% over 100, 80% over 500). This magnifies the error.

Here is an example, taken using a T.I. 57 hand calculator. We start with 1250, which is an average argument in the benchmark we are using. The arc tangent returns 89.954163 degrees. Let us deliberately place a .01% error in that number by multiplying by 1.0001, resulting in an angle of 89.963159. Taking the tangent of that angle yields a tangent of 1555.2092(!). The original error of .01% has been magnified to 24.4%, or roughly 2440 times larger relative error. If a

Page 7, Column 1

smaller deliberate error is used - say .00001%, or 1E-6, the error will be magnified in the tangent by about 1962 times, which happens to be #PI/2 times 1250, and the angle just happens to be (almost) equal to #PI/2. THIS IS NOT AN ACCIDENT!

Try this yourself: take any large N. Calculate the arc tangent and then multiply by .999999 (six nines, introducing a relative error of 1E-6). Now calculate the tangent. Divide the result by the original N and you will find that the relative error is 1.57E-6 times N, or #PI/2 times N times the original deliberately introduced error.

It turns out that the relative RMS error which is calculated by Terry P's algorithm is in fact 2267 times the RMS epsilon error in the ATN (arc tangent) routine, plus the RMS epsilon errors of the other functions untagnified. The magnification of the ATN error is so great that the other epsilons are completely masked. This does, however, give us a very precise measure of the errors inherent in the ATN function, and we can deduce the number of accurate bits in the mantissa of the floating point package from that information. (If the person who programs the floating point functions knows what he/she is doing, the accuracy of all the transcendental functions will be similar.)

(Why 2267? Take 2500, the largest N in the Dr. Dobb's algorithm and also in Terry's. Multiply by #PI/2 and divide by the square root of 3. If you have some knowledge of differential and integral calculus, you can figure this out for yourself.)

The RMS error of HALGOL/48 was 4.1E-12, which is equal to 4100E-15. Dividing by 2267, we find that the RMS error of the ATN function is in fact 1.81E-15. The reciprocal of that number is 5.53E+14, and the log to the base 2 of THAT number is 48.974, which we round off to 49.0. This means that the RMS error in the HALGOL/48 ATN function is about half a least bit.

We have converted the relative errors in the table a few pages back to the number of bits of precision, rounded to the nearest tenth bit. We have also taken the liberty of making, from that information, some assumptions about the number of bits carried in the mantissa of the floating point package and also whether a guard byte or word is used.

ADDITIONAL COMMENTS:

The transcendental package we published in issue #16 isn't quite as good as some of the professionally-done packages. We only managed an RMS error of one bit better than the mantissa, while others have managed 1.4 bits better than the mantissa.

Page 7, Column 2

It is evident that Microware uses 8087 support only for the four basic math functions rather than using the "temporary real" internal number representation which can be used for chained operations. When used in that fashion, the 8087 effectively provides a "guard word" on the IEEE format. And that, if used, would provide better accuracy than the Microware package provides. The 68000 system which is under development does in software what the Microware package SHOULD do in hardware.

Check LISA's error performance against the IBM PC's with Microware's 8087 support. It is obviously performing IEEE double precision format calculations in software, which is very time-consuming. Our forthcoming 68000/16081 will do the same thing but in hardware, which is a whole lot faster. Since we can't write transcendentals as well as some others (evidently), we are only predicting 54.0 bits of precision vs. the 54.4 that Microware and LISA achieve.

About the sickly IBM single precision package: now you can see why users call that package "half precision." Our interpretation is that the single precision package is in hardware and uses a radix (exponent) base 16 rather than base 2. That's guaranteed to introduce far larger round-off errors.

We just LOVE the accuracy of M, er, of the 68000 system that is under development. We are not sure we would want to wait around for 250 seconds to get that accuracy. Although this system uses extended precision for all calculations, it seems probable that variables are stored as conventional 8-byte values, perhaps in the IEEE format. This makes this system's floating point package an "8087 done in software", which accounts for its relative slowness.

The reason our Microsoft compatible transcendentals are 206 times better than Microsoft's 6502 package is that we use a guard word or byte and Microsoft did not. They did include a guard byte on the add, subtract and multiply but they really botched the divide algorithm, which does not even round properly half the time (we have discovered divide errors of almost an entire least bit using that 6502 package).

SIGNIFICANT INFORMATION:

We are told that what we have been calling a mantissa in this newsletter for 2 1/2 years should in fact be termed a "significand". It is true that we have seen this word in use recently, but our 1980 Webster's NEW WORLD DICTIONARY (SECOND COLLEGE EDITION) does not contain the word "significand". It seems likely that the accession of "significand" over "mantissa" has occurred recently. Since your FNE is old-fashioned, we will continue to use "mantissa".

Page 8, Column 1

In the book COMPUTER STRUCTURES: READINGS AND EXAMPLES, McGraw-Hill 1971, we find in Chapter 4, page 97: "Several of the digital computers being built or planned in this country and England are to contain a so-called 'floating decimal point'. This is a mechanism for expressing each word as a characteristic and a mantissa..." One of the three authors of Chapter 4 is a fellow named John van Neumann.

A TALE OF TWO SYSTEMS:

Back in issue #4, we told you about how T.I. wound up making a programmable controller which they called a minicomputer and sold, mostly to themselves. They also wound up making a one-chip version called the 9900. We did not give you the FULL story at that time; here is WHY:

The chip folks were perfectly aware of the shortcomings of that programmable controller, and wanted to make a real general-purpose computer. The "systems" boys got the ear of upper management (read J. Fred Bucy), and upper management sided with the systems guys. Voila, the wonderful 16-bit 9900, which is SLIGHTLY superior to the Intel 4004 as a general-purpose computer.

The wonderful T.I. home computer entered the marketplace before we started this newsletter, so you will have to take our word for this next unless you are willing to travel to Santa Ana and interview our three witnesses: at a time when the small computer media was predicting that T.I. was going to take over the entire personal computer business and drive everybody else out, we were telling our personal acquaintances that the T.I. home computer mould crash and burn.

We had just one reason for that prediction: the HORRID "performance" of the 9900 as a general purpose computer. At a time when everyone else was concentrating on the size of T.I., a true corporate giant compared to anyone else then in the game, and on the size of the 9900 (a 16-bit machine) WE were concentrating on the lack of internal resources on the inefficient two-address or three-address instruction set, and on the fact that T.I. management could be depended upon to go vertical (use the chip they made themselves) in their home computer.

Well, the T.I. 99/4 came out and promptly fell flat on its face. It turns out that T.I. did lots of OTHER things wrong besides use the 9900. The busted keyboard, for instance. (For a VERY brief time after it became obvious that the 99/4 was a flop as a home computer, T.I. tried to market it as a BUSINESS computer! With that busted keyboard!) Instead of recognizing the failure, T.I. did a very odd thing: they decided to sell the computer at a loss.

Page 8, Column 2

T.I. sold a LOT of the slightly revamped 99/4A, all at a loss. Apparently they were going to make it up on volume or on software or SOMETHING, because the 99/4A has been a money-loser from day one. (Along the way, the T.I. chip makers wanted to make their NEXT-generation chip either a real microcomputer or,second-source the 68000. The systems boys went howling to management and management made the chip folks bring out an updated 9900 called the 99000. We reported this in newsletter #4.)

We are typing this between 6 and 7 AM on Saturday, 29 Oct. This morning's paper carried the announcement that 1) T.I. has just dropped another $338 million in the last quarter on personal computers, and 2) that T.I. was dropping out of the home computer business. The story included this quotation by a spokesman (Skip Bushee) for a marketing firm: "Why would they make an announcement right before the Christmas selling season? Who's going to buy one now? Why (pull out) at all?"

It's very simple, Skip: if there had been more than a 30 second lapse between the announcement that "we lost $338 million" and "we are quitting the business" then J. Fred Bucy would have been out of a job. Has everybody forgotten that T.I. lost about $200 million in the PREVIOUS quarter on home computers? And that that sum included write-downs which were supposed to assure the future profitability of the home computer business? And that J. Fred took PERSONAL charge of the home computer division at that time?

Remind us to never do business with Skip's marketing firm.

Meanwhile, the T.I. systems guys are selling a Professional Computer which uses an Intel 8088. After costing the company more than half a billion dollars (plus potential profits from a REAL microcomputer) the systems guys have finally caught on. A little applause, folks?

THE SECOND SYSTEMS GROUP:

We told you about the way the 68000 was crippled for two years by the Motorola systems group two issues back, so we will not repeat the story here. But note that the systems group is a TINY outfit compared to the chip manufacturing division that it managed to smother. What is it with upper management that they will listen to the idiot systems boys instead of sensible folks? (The T.I. systems boys developed a PASCAL with a GOTO statement. We aren't kidding.)

Only the fact that us folks here at Digital Acoustics could be accused of being (idiot?) systems types ourselves prevents us from suggesting that all systems persons be taken out in the street and summarily shot.

Page 9, Column 1

MY MANAGER:

You will recall that Apple prexy Scully shoved aside the co-general managers of Apple's Personal Computer Division (you mean there's another division?) and took over this job himself. Well, there is a Scully man who is the new general manager of the PCD. (Scully man = hired by Scully hence loyal to Scully, not Apple Computer.) This is the sort of thing that happens by half-dozens, so we expect to see a Scully man as controller, a Scully man as head of marketing, a Scully man as... and we expect this to happen sooner rather than later. In corporate circles this is euphemistically called "grasping the reins firmly." If all of the princelings are loyal to the king, then there can't be a palace revolution, hmm?

The first Scully man is John Cavalier, formerly of Atari. We'll keep you up to date as more Scully men join Apple. (We don't expect to see a "Scully woman".)

GETTING A MATH CHIP:

Those darn guys at Nat Semi are spoilsports. We had a very funny and somewhat sexist scenario drawn up to show you how to get a free sample 16081 - which until recently was the ONLY way you could get a 16081.

They are now SELLING their samples. For $200. They run at 5 volts, are tested at 6MHz, and do not have an accompanying "bug list". We just bought one at Avnet (a local authorized Nat Semi distributer) and we will probably buy one or two more. Although Nat Semi describes these early chips as "engineering samples" the letters "ES" do NOT appear on the top of the chip, although they are printed on the bottom where you would not normally look. This may be a precautionary hedge.

THEM WINCHESTER DISKS:

Waaahh! We can't find the reference! Well, we're going to pass this on anyway. You may have noticed that there are several outfits making Winchesters plus controllers available for $999. Surprise! They mostly work. One outfit is about to discontinue direct mail sales and go to retail, but at $1395 (or $1495, we don't have that reference). It seems they have shipped a lot of product and the product mostly works except that sometimes the disk won't start rotating when turned on (a trivial matter, no?). There the customer is with a thousand buck investment and worse, 5 megabytes of data which he hasn't backed up because everybody knows how reliable Winchesters are. And the disk won't spin.

And we have heard from a certain graphics house which we know very well. They are shipping Winchesters into the field and they are turning up DOA too often.

Page 9, Column 2

The reference we can't find states that those errors never occur at the manufacturer (sort of true and sort of false) and that the problem can be fixed by "poking a finger at the flywheel" (a very temporary fix). Here are the facts:

Winchesters use a DC motor to spin the disk. Cheap DC motors have slip rings and brushes and - this is the problem - a very small "dead band" at two (at least) locations. If the motor stops in this "dead band" the brushes don't make contact with the slip ring and the motor won't start. Statistically, the possibility of stopping in the dead band is small, say one in several hundred. With thousands of users turning their disks on an average of once a day, you are going to get a LOT of disks that don't spin. The person who is unlucky enough to have his disk lock up, and who doesn't know what is going on, can be VERY unhappy.

The very simple and obvious cure is to use a DC motor with no dead band. They exist and are readily available, but cost about thirty bucks more than the cheapies. Guess which the manufacturers are going to use? We remind you that no one ever went broke underestimating the intelligence of the American public. The folks who are buying Winchesters are buying price, price, price! The result is Winchesters that lock up and have other problems.

Did you know that even the Winchester used in IBM's XT has to warm up the better part of an hour before it will write data reliably? And that some folks leave their XT on forever on that account? (Reference: UNIX REVIEW, Aug/Sep '83, page 58.)

There is an outfit called PAPST (an Austrian or Czech outfit) which made very high quality motors for tape recorders twenty years ago and which makes very good DC motors for Minchesters now. Almost nobody uses them because they aren't cheap. (We have a friend who insists that the spelling is PABST, like the beer. He may be right. He also says the way to "unlock" the disks is to raise the front a couple or three inches and then to drop it. Understandably, he doesn't want his name associated with that suggestion publicly.)

So run right out and get a cheap, shoddy Winchester to store all your precious data on. We think we'll wait awhile yet. We will want TWO, not one, Winchesters and we will want removable and interchangeable media. You know, what Syquest promised to have in mass production a year ago. And we will want at least SOME track record of reliability. We don't mind being the first to buy a new chip but anybody who buys the first models of a complex, sensitive mechanical device like a Winchester for lowest price deserve what they get.

In mechanical matters, conservatism pays off.

Page 10, Column 1

(Two days after writing the above, 20 Oct '83 ELECTRONICS magazine arrived with a story on page 110 about "hard-disk-drive makers fear price war."

Subtitle: "Seagate's Connor avers a Japanese firm is following a dumping strategy in selling a hard-disk drive for about $100 below the usual U.S. price." Hmm.

A couple of years ago wasn't it Tandon that was supposedly "buying" business in the floppy field? "Those guys (at Tandon) can't deliver quantity product at that price!" Jugi's competitors asserted. Surprise! Those guys COULD. Maybe Densei really CAN deliver product, profitably, the way Tandon did? Seagate currently has almost 45% of the U.S. 5 1/4 inch Winchester market. Connor's first name is Finis. An omen?

TAKE THAT, PC SCUM!

Oct '83 DATAMATION has an editorial (p.27) which decries the way personal computers are sneaking into large businesses without so much as a by-your-leave to the lordly DP Manager. Methods are suggested to correct the situation. We offer a partial quote from the tail end of the editorial: "...you can catch more flies with honey than vinegar. Control of the personal computer..."

Yes, folks, we really are talking about CONTROL of the personal computers - all of them - by the DP Manager. What? You aren't convinced? Oh, you think we are abstracting just one person's viewpoint and making a DP mountain out of a molehill?

All right, turn to page 189 of the same issue of DATAMATION and you will find a story entitled Move it to a Micro. A few quotations: "...growing inventory of old applications and the rapid spread of microcomputers. Both are major concerns for data processing executives.

This story then suggests re-writing old COBOL applications in BASIC and moving them onto one of those personal computers (we are not making this up, folks). "(It) means that the dp manager achieves two important results: a needed application gets modernized, and a micro performs a real, justifiable job."

Naturally, the tasks which the micro had been used for previously, which were not under the supervision of the dp manager were NOT "real, justifiable job(s)."

Let us not take our eye off the real purpose of this exercise: "...the approach offers an opportunity for his [sexist! - FNE] to assert greater control over the ways micros are used in his organization." The operative word, folks, is CONTROL.

Page 10, Column 2

Be advised that if you work for a company which has a dp manager, that dp manager desperately wants CONTROL over your personal computer. Every computer operator who presses a keyboard without a by-your-leave from the dp manager, or who chooses PROGRAMS without the dp manager's approval (gasp!) diminishes the CONTROL of the dp manager, which lessens HIS (?) authority and importance.

CONTROL = POWER! This is plain, old-fashioned I am the glorious boss and you peons are less than dirt thinking. This is the thinking found in the publication UNIX REVIEW, where UNIX is (naturally) asserted to be a wonderful operating system but where the operator of the wonderful operating system is never mentioned.

It just so happens that we had occasion to chat over the phone with one of the founders of UNIX REVIEW (the publication is looking for columnists) and he confirmed that UNIX REVIEW does not discuss anything related to the UNIX operator, the guy who gets his or her hands dirty on the keyboard. UNIX systems are purchased by dp managers, not UNIX operators. If you use UNIX, the dp manager is firmly in CONTROL!

(An aside to our feminist readers: the author of that DATAMATION article which uses 'his' and 'his' when referencing the dp manager is Irene Shain Nesbit.)

MORE SEXISM:

We have concluded that the English language is fundamentally sexist. In writing this newsletter we have constantly run across phrases which we are unable to express in a sexually neutral manner without twisting the phrase out of shape. Consider a verbal, not written, problem: a female mailman. If one (verbally) uses the term "mailperson" that sounds exactly like "maleperson," which some females would consider offensive.

English is a very efficient language for the simple reason that England was conquered so often by a succession of invaders. (The reason there are so many attractive Scottish redheads is that the USO dances held when the Norsemen raided the northern shores of Great Britain were inadequately chaperoned.) Each wave of new conquerors simplified the existing language and made additions to it where improvements were possible. English is a language which has NANY one-syllable words. English is biased in favor of the use of one-syllable words.

Examples: male, man, boy, girl. Examples of multi-syllable words which English disfavors: woman, female. If the feminists could come up with a useful and acceptable one-syllable replacement for those last two

Page 11, Column 1

words, the feminist battle would be half won (apparently GIRL, although a single-syllable word, is unacceptable to feminists). Ah, girls: words mean what you WANT them to mean, no?

"THE FACTS" REVISITED:

We mailed #25 on 13 Oct. About 8 or 9 days earlier, we had sent copies of the rumor and "the facts" to several persons and places which we thought might be interested, such as IBM competitors, Intel competitors, and a few journalists. The day before we mailed #25 we received a phone call from one of the journalists from on the other side of the big creek. "The information you have sent me is wrong." he asserted, "I have checked this out with IBM and with Microsoft in Bellevue and both tell me that there is no problem between MS-DOS and the 8018X."

Oh dear! And we called that "the facts!" Well, on 17 Oct we received the 17 Oct '83 issue of Electronic News (now there's real efficiency for you!). Let us provide some quotations from a story on page 24:

"Microcomputer group general manager David House last week acknowledged the company has just begun instituting a mask change on the 80186 that resolves a microcode bug that had rendered the processor unsuitable for certain IBM PC-compatible applications...

"Intel has solved the microcode bug and is shifting production of the 80186 to a new mask set that eliminates the problem. 'It is a problem within 60 days of being gone,' the Intel manager said."

British journalism is evidently suffering following the untimely demise of the late, great Inside Trader. In the May '81 MCP he wrote "protestations that all is well... so readily swallowed by the sycophantic gulls of the computer press, should be judged in the light of the following..." Like the fact that the 80188 mask is being revised because of a conflict with MS-DOS? In the July/Aug '80 issue of PRINTOUT Inside wrote, "Crow-eating time for industry know-alls who scoffed at our predictions..."

One can speculate on the meaning of "It is a problem within 60 days of being gone." Here are some sample interpretations:

1) Within 60 days we will have corrected the problem, produced as many replacement parts as are needed, and placed these replacement parts in customers' hands.

2) Within 60 days we should begin quantity production using the new mask.

Page 11, Column 2

3) Within 60 days me will begin testing the new mask set, which is expected to be completed at that time.

4) Within 60 days we will have figured out how to redesign the mask set.

MORE RUMORS MONGERED HERE:

In the last issue we did not reveal two other rumors we had heard, both of which asserted that the main circuit board for Peanut had undergone numerous revisions (one source said 17, the other 24). This makes lots of sense if IBM had to (or TRIED to) redesign the circuit board to accommodate an 8088 rather than an 80188. That would require the addition of a LOT more circuitry.

As this is being written, speculation over Peanut is reaching fever pitch. On Oct 14 the WSJ had a large article on the back cover speculating about Peanut to the extent of giving specific configurations and prices. Infoworld, however, asserts that IBM has no pre-Xmas advertising plans for Peanut.

Realizing that events may overtake this writeup, here is our analysis: if Peanut is to appear before February, it will have to be using an 8088 CPU. If Peanut DOES appear with an 8088 CPU, it will be a temporary model to be replaced by the ORIGINAL 80188 design as soon possible. If Peanut is delayed until February or later it will appear with an 80188 CPU.

The Peanut uses CBM 64 technology at Apple IIe prices, except that it will have a REAL disk drive (in the larger of two configurations). A real disk drive is something that the 64 does not have. Come to think of it, using DOS 3.3 the IIe cannot be said to have a real disk drive either. DOS 3.3 is bad enough loading binary files; loading text files is virtually impossible.

It's too bad the 6502 world never developed floppy disk controller chips. Naturally, it is totally impossible to adapt Intel or NEC controllers designed for the 8080 to the 6502 - right, Hal Chamberlin?

SOFTECH STUFF:

During the brief negotiations we held a year ago with SofTech we were told, in confidence, the terms on which SofTech had licensed Osborne Computer for the SCUD P-system. When Osborne went Chapter 11, it turned out that the true price and terms were revealed in the press because SofTech was holding a large chunk of Osborne's paper. Osborne had in fact been licensed by SofTech to distribute the P-system royalty-free for the sum of $1.9 million (slightly less than we were told in confidence). But only about $300,000 had actually been

Page 12, Column 1

paid at the time Osborne went belly-up (definitely not what we had been told in confidence).

Osborne's bankruptcy left SofTech holding the bag for $1.6 million. Since SofTech is in the 50% corporate income tax bracket, that meant that they had to re-state their earnings (take a writedown) to the extent of $800,000. It also means that SofTech wanted about 75% as much from us as an advance against royalties as they wound up getting from Osborne.

Considering the effect of the SCUD P-system on Osborne's sales and profits, we think we maybe made a wise decision not to license the SCUD system ourselves. Two other wise decisions we have made lately are not to buy the Hope diamond and not to initiate a corporate take-over of General Motors. (That SCUD system just HAS to be good judging by the price tag SofTech hangs on it.)

TRUTH IN ADVERTISING:

We have at hand the sports section and the business section for the L.A. Times, Oct. 22 '83. On the back page of the sports section is a very large ad by EPSON offering the RX-80 printer for $299. On the back page of the business section is a very large ad by EPSON which offers a free RX-80 printer worth $599 with the purchase of a QX-10 computer. Our reaction is identical to the headline on the EPSON ad on the back of the sports section: "You must be kidding!"

MERCANTILISM vs. HLLs:

By our count, we have received approximately 380 letters from subscribers pointing out that HLLs are transportable, maintainable, and can be written in a structured manner, and (the litany drones on...) "and so," the letters conclude, "since the theory is so perfect it is obvious that HLLs MUST be used!" 379 of the letter writers have chosen to completely ignore the marketplace. We have published the other letter elsewhere in this issue.

Look, folks, your FNE is a MERCHANT! We operate IN THE MARKETPLACE and we live or die BY OUR PERFORMANCE IN THAT MARKETPLACE! Can you understand why we have so little regard for theories which refuse to acknowledge the realities of the marketplace?

We have identified and pointed out to you certain segments of the marketplace which will not support inefficient code, for the sisple reason that EFFICIENT CODE - written in assembly, of course - is available in those market segments. No consumer in his right mind will select inefficiency over efficiency.

Page 12, Column 2

Even the one letter-writer who acknowledged the presence of the marketplace is stubbornly adhering to his theory that 1-2-3 is destroying Context's MBA in the marketplace because of superior marketing (advertising) by Lotus. That is dead wrong. Because we, as a newsletter editor and as a merchant who plans to market an IBM PC-compatible product, have been reading the PC-related publications, we KNOW why 1-2-3 has swept the marketplace.

Every one of those publications - EVERY ONE - featured 1-2-3 on the FRONT COVER and wrote effusively of its fantastic speed in the editorial material inside. If you want to credit that to marketing rather than the speed that you can only get with assembly language then O.K., 1-2-3 wins due to better marketing.

We feel we have presented the best arguments in this area that we can, and so will de-emphasize this subject except where new evidence appears - such as this:

BYE, BYE UNIX:

Let us refer you to an article in the very first shrunk Infoworld. On page 28 there are announcements of new hardware and software from Fortune Systems. Gasp! We find that:

"Now the question many industry watchers will be asking is, 'Will the Fortune 16:32 be obsolete?'

"Fortune Systems told infoworld that the computer will still be sold, but the initial UNIX operating system will be replaced by FOR:PRO, the company's enhanced operating system.

"The company claims that on a five-user system, FOR:PRO improves menu and terminal response time by 100%, file access speed by 40% and floating-point calculations by 300%.

"FOR:PRO will be a standard feature on Fortune Systems microcomputers, and current 16:32 owners will be able to upgrade free of charge."

Gosh! Fortune is abandoning wonderful UNIX? GEE! They are going to a different operating system which runs much more swiftly? Let's see now: UNIX is written in C. A faster, more efficient operating system would (naturally) be written in:

A [ ] COBOL

B [ ] P-code PASCAL

C [ ] other (specify) ______________________________

Send your test paper to Carl Helmers for grading.

Page 13, Column 1

We hate to keep repeating this, but we don't want you to get the wrong idea. UNIX is in fact a very good operating system for dedicated, full-time computer professionals, provided it runs on VERY good (and hence VERY expensive) hardware. It seems probable that there is a higher percentage of dedicated, full-time computer professionals in our audience than in the general marketplace.

If you favor UNIX on the 68000, do not despair because Fortune has turned its back on UNIX. The folks with the SAYBROOKE under-the-hood 68000 board will soon (?) have UNIX available to run on your 143K DISK IIs. You will be amazed at the performance. We mean that literally.

THE ZILOG Z8000:

We bet you had forgotten the Z8000, which was the very best microprocessor available for one year before the 60000 became real, and which was the SECOND best microprocessor available until fairly recently. Well, ZILOG apparently has some fresh blood in marketing.

Rumor (we know him well) has it that the Motorola sales folks have had to put out a few fires recently where ZILOG had convinced engineering staffs that the Z8000 was actually superior to the 68000! We think Motorola ought to find out who the sales or marketing genius is and hire his/her.

ZILOG, for instance, has produced a hilarious poster entitled CHIPWRECK. This is "A TRAGIC TALE FROM DEEPEST SILICON SPACE OF THOSE WHO BOUGHT THE 68000 - AND LIVED TO REGRET IT! STARRING CAPTAIN ZILOG, THAT 16-BIT WONDER OF DERRING-DO. With Mr. Motorooter, that odorous 2-bit villain of CPU chicanery. Co-starring the seductive Motorooter Rose. INTRODUCING THE FETCHING ZILL.

In addition to the main illustration, with Captain Zilog playing Luke Skywalker to the 68000 as tie-fighter, there are six smaller captioned scenes. Here are the six captions:

"What does it mean when the fetching Zill learns that C language on the lumbering 68000 takes 30% more code than on the superefficient Z8000?

"What travesty of good design principles lies ahead when Mr. Motorooter's mad scientists create a power-mad 64-pin, 68000 ceramic monster with a voracious appetite for PC board real estate?

"How does wily Motorooter Rose use her charms to convince innocent designers to buy the 68000 CPU - with no peripherals to back it up! [Zilog offers a 68000 peripheral kit of ZILOG parts! Since we have no

Page 13, Column 2

predjudice against Yoda ears, green skin or shaved heads, we are trying to arrange a date with Rose - FNE]

"How does Motorooter give new meaning to "kludge" when it crams 70,000 transistors onto one 68000, knowing all along that a Z8000 does more with just 17,000?

"Will it be too late to bring back the high-speed Z8000 when angry designers discover cumbersome wait states in the 68000?

"How does Captain Zilog use the awesome Z8000 to rescue programmers throughout Silicon Space from the awful fate of tedious 68000's?"

Did you notice the marvelous loaded words imbedded in five of the six captions? Lumbering? Travesty? Kludge? Cumbersome? Tedious? Hey, Motorooter, er, Motorola: find that guy/gal and hire him/her!

We LOVE this poster! It will be on display at Digital Acoustics for some time to come. We are encountering difficulties in lining up a date with Rose.

CALCULATING TRANSCENDENTALS

For those who are interested, we would like to share with you some thoughts we have had while planning a 68000/16081 transcendental package. This is our third time around for most of the transcendentals and the second time around for the TAN function, for example. Writing a transcendental package is something one should NEVER do for the first time.

Since this will be the 2.5th time we have done this, the problem is now not how to get the job done - we know that - but how to make the most effective use of the resources available. Said resources include a 12.5MHz 68000 and a 6.25MHz 16081, plus either $5/Kbyte no-wait-state static RAM or $1.5/Kbyte one-wait-state DRAM. The use of the 16081 limits - and hence simplifys - our choices.

Who is in favor of unlimited precision? You there, sir? You are interested in unlimited precision? Well, we have bad news for you. Last week we used our time machine to travel into the future and accept delivery on a CRAY 50. We took it back to the Juriassic period and set it up with an Everlast potter supply (had to travel all the way up to the 27th century to get that). Well, we checked it yesterday and it hasn't finished its first floating point multiply yet. It seems that unlimited precision is out.

O.K., let's discuss limited precision. In our opinion, the usual single precision format with only a 24 bit mantissa is useless for anything but graphics and a 16 bit mantissa is adequate for graphics. We wrote a

Page 14, Column 1

graphics floating point package more than a year and a half ago using a 16 bit mantissa. That package is one hell of a lot faster than any 8088/8087 combination that has ever lived, mainly because it can BOTH load and store a floating point number in under 4 microseconds while the 8088/8087 require over 34 microseconds (!) to perform the same functions. And 16 bit mantissa multiplies or divides are done directly in one 68000 instruction.

(An Intel type challenged us when we asserted that we have a software package that will draw that 'HAT', less one wrinkle, 20 times faster than the 8088/8087 combo. We sent his four listings, showing the generations (progression) from the original 53 minute Applesoft program to the pure 68000 assembly language program that runs 300 times faster. That was a month ago. We haven't heard from his since.)

WONDERFUL WEITEK:

A company called Weitek has a chip set - two chips - that will perform single precision floating point calculations at four megaflops. That's right, four million single precision floating point operations per second. It uses a four-level pipeline, so it requires an entire microsecond to perform a PARTICULAR floating point operation (AWWW...). Before you get too excited, consider that it requires a bus-bandwidth of 32 megabytes/sec to feed it operands for dyadic functions, and 16 megabytes/sec to store the results. Somewhere along in there we have to have some instructions, so you are looking at about a 64 megabyte/sec data bus bandwidth to make optimum use of that chip set.

Still, this is one of the chip sets of the future for digital filtering and graphics applications and such. But single precision is not what we are after, so, moving right along ...

MICROSOFT'S 6502 PACKAGE

uses a 32-bit mantissa and ALMOST uses a guard byte, only they screwed up the divide function. The net result is the same as if no guard byte were used at all. Since a guard IS used for signed addition and for multiplication, the Microsoft 6502 package does not have an optimum speed/precision ratio,

(We are toying with the idea of programming a proper 6502 divide and placing it in the public domain.)

GUARD BYTES OR WORDS

do extend the precision of results but at great cost in the time domain. A 48-bit mantissa floating point package with a guard word will execute almost as slowly as a different package using a 64-bit mantissa.

Page 14, Column 2

The 8087 effectively has an 11-bit guard band built in since ALL calculations are performed in 'temporary real' using a 64-bit eantissa. This provides additional accuracy when performing certain chained operations; it provides NO ADDITIONAL ACCURACY WHATEVER when performing non-chained operations such as the dyadic operations used during matrix calculations. As a result of this 'temporary real' format used for ALL calculations the 8087 is severely handicapped when performing dyadic computations (such as matrix operations) because of the VERY SUBSTANTIAL TINE PENALTY involved in loads and stores.

THE PRECISION ONE NEEDS

is a matter of personal opinion. We are personally uncomfortable with the 9 decimal digits provided by Applesoft GENERALLY. In specific circumstances, that is good enough 90% to 99.8% of the time. There are MORE times when we would like better precision,

The precision we are comfortable with is provided by a 48-bit mantissa with no guard word or byte. We need better precision only on rare occasions involving extraordinary circumstances. So far, the only occasion we have had in our lifetime for better accuracy is to test the precision of a 48-bit (mantissa) transcendental package which we have written. Now we have that need again as we are about to write a transcendental package using a 53-bit mantissa.

A transcendental package using a 53-bit mantissa will have MORE precision than we personally feel a need for, but that is what you get with the 16081 - no more, no less. As we said (typed?) earlier, using the 16081 limits - and simplifys - our choices.

THE CHOICES LEFT

involve decisions as to tradeoffs between memory consumed in the storage of constants versus execution time for certain transcendental functions. The EXP and ARCTAN functions fall into this category and so do the ARCSIN and ARCCOS functions since they are calculated from the ARCTAN.

Basically, the question is how much money one is willing to spend to get an X% speed increase in, say, the EXP function. Is it worth 64 additional bytes of stored constants to save one multiply and one add? Is it worth 192 additional bytes of stored constants to save two multiplies and two adds? Is it worth 448 more bytes of stored constants to save three multiplies and three adds?

There are lots of things that one can do with a computer - such as running a word processor as we are doing now - which never involve the EXP function at

Page 15, Column 1

all. But if one is purchasing a 16081 to go with a 68000 to go with a host computer then one presumably has an interest in the EXP function. On the other hand there are lots of things to compute besides the EXP. But buying memory is a one-time event, and thereafter the EXP function forever runs more swiftly. How much money are we talking about?

    Mults, Adds saved   mem      SRAM       DRAM 

        1, 1        64 bytes   31 cents   9 cents 
        2, 2       192 bytes   94 cents  29 cents 
        3, 3       448 bytes  219 cents  66 cents

The prices listed above are todays' RAM prices. Eighteen months from now, those prices will have been halved. Our opinion is that today we should use an extra 192 bytes for the SRAM boards and an extra 449 bytes for the DRAM boards. (Speed may be more important to us than to you - but it IS a $5000 (total price) computer system we are speeding up, no?)

A significantly faster EXP isn't worth the better part of a buck? How come you're thinking of buying a $125 board (appx) to hold a $250 chip? To run slowly?

You see, we DO have some choices left.

STANDARD TRANSCENDENTALS:

There are those who would take those choices away, for the noblest of motives. There appears to be substantial support among the ex-members of the disbanded IEEE floating point standard committee for standardization of methods of calculating transcendentals. As recently as last week we were supportive of such a standard. We now have second thoughts:

The EXP function and the ARCTAN function are examples of transcendental functions whose calculation time is heavily dependent upon the number of precalculate stored constants which are used. As we have just tried to demonstrate, the optimum number of stored constants is a function o4 memory prices. If a correctly optimum number of stored constants is selected today, in three years that number will be four times too small and in nine years it will be 64 times too small (memory prices are halved every 18 months, historically).

But standards are not the sort of thing that one should be changing constantly. Neither should standards lock in obsolescent technology. It seems we have a dilemma.

There is the additional fact that stored constants have one price tag when stored in cheap DRAM and another, much larger price tag if stored in ROM on an already large and expensive math chip such as the 8087.

Page 15, Column 2

NO CHOICE AT ALL

is what Cody and Waite provide. Their single-choice EXP algorithm does not take advantage of stored constants to reduce the calculation time at all. This is hard to believe for a book published,in 1980.

We much prefer Hart, et al's COMPUTER APPROXIMATIONS, which provides numerous choices and in fact provides TWO tables (Indices 1220 and 1221) for the calculation of EXP using an additional 256 precalculate values - that's 2K bytes - although the book was originally published in 1968 when memory was very, very expensive. (Fifteen years from now, memory in 1983 will seem very, very expensive.)

CHOOSING A MATH CHIP:

We can begin by observing that the 8087 MUST be used with the Intel 808X microprocessor and thus the user is stuck, permanently, with the woes of segmentation and limited memory. On the other hand, the 16081 can be used with both available microprocessors which have a nonsegmented 16 megabyte address range.

Rarely will the choice of the floating point processor chip determine which microprocessor is used. Instead, a microprocessor is chosen AND THAT CHOICE IMPLICITLY DETERMINES THE MATH PROCESSOR CHIP. Our task here, then, is not to provide information to make a selection of a floating point chip, but to explain what relative performance is available from the two available floating point math processors.

EVERY 16-BIT MICROPROCESSOR NOW HAS FLOATING POINT SUPPORT. The 16081 can be interfaced to the 18000 and Fairchild 9445 in the same way as the 68000. In fact, the 16081 can be interfaced to the 16032 (1) as a peripheral as well as as a coprocessar. Pages 24-28 of the last issue provide the needed information to interface other processors.

Why would anyone want to inter4ace a 16081 to a 16032 as a peripheral? Suppose one has a 10MHz 16032 and a 6MHz 16081 available. Would you rather have a 6MHz 16032/16081 coprocessing system or a 10MHz 16032 with a 5MHz 16081 peripheral?

The 12.5MHz (or 12MHz) 68000 is well matched to the 6MHz (or 6.25MHz) 16081. Using prefetch techniques and with the benefit of twice the clock speed the 68000/16081 can run as fast as the 16032/16081 coprocessors while performing floating point calculations. On non-floating point computations the fast clock on the 68000 makes it no contest.

Thus, it is clear that an optimum 68000/16081 combination is superior to an optimum 16032/16081

Page 16, Column 1

coprocessing system as long as the 16081 is limited to 6MHz, as it is likely to be for some time. 8MHz or 10MHz 16081s are likely to arrive around the same time as 16MHz 680X0s (NOT soon) and will continue to be a good match.

8087 - 16081 COMPARISON:

The 8087 calculates many of the transcendentals internally and is clearly faster than the 16081 peripheral working with a microprocessor in software. For instance, A = LOGe(B) where A and B are double precision values located in memory executes in 254 microseconds (Hart 1704) versus 213 microseconds using a 5MHz 8086/8087. (The algorithm published in REDLANDS is Hart 2665, slightly slower at 269 microseconds.)

EXP, TAN, ATN, and SQR will all execute faster with an 8087 than the 16081. The 8087 EXP advantage may be slight to non-existent, while the 8087 SQR speed advantage is substantial (we will have exact figures after we program those functions).

What about the speed advantage of the 8087 while performing SINE and COSINE calculations? The answer is neither simple nor obvious. Intel would suggest that the SINE function be calculated from the TANGENT, using

SINE(X) = SQR(A/(1+A))

where A = the TAN(X) squared. This can present problems in the close vicinity of 90 degrees; the TAN(90) is infinity but the SIN(90) is one. One wonders how many persons programming in 8087 SINE function will take this into account and what their strategy will be and what the average and maximum time penalty for that strategy will be. Like we said, the answer is neither simple nor obvious.

FOR MATRIX OPERATIONS, as for all operations involving the fundamental math operations of +, -, *, /, along with lots of stores into and loads out of the math chip, the 16081 is vastly superior to the 8087. A speed ratio of 4 to 1 would be expected while inverting a large matrix, for instance. That's over half an order of magnitude difference in performance.

(We apologize for the brevity of these comparisons. We are running short of space this month.)

DUBIOUS DISTINCTION DEPT:

We now have the dubious distinction of having our name misspelled in a column whose name begins with "Inside" an BOTH sides of the big creek. You would think that ANYBODY could spell "Eloi", right?

DTACK SOFTWARE EXCHANGE:

Page 16, Column 2

The following report has been received from the DTACK SOFTWARE EXCHANGE:

"A new disk of Pascal stuff has been added by Ron Goldthwaite. It includes Alan Wood's Pascal hooks (I think) with utilities to run DTACK in a slot other than 2. A description is included in his letter on the disk. Those interested should request disk #4, Pascal Stuff.

Ken Ozanne has been named Pacific Theatre Coordinator of DSEx [de-sex? - FNE]. He says his policies are about the same as mine. Anyone west of Hawaii should write to him. He will get all disks free as soon as they are added to the catalog.

Ken Ozanne
42 Meek's Crescent
Faulconbridge, NSW 2776
Australia

DSEx GRUMBLINGS:

"Someone, somewhere must have used their DTACK board for some purpose before Sensenig BASIC. That lonely someone must have programmed in assembly. Now, surely all of that precious source code can't be proprietary and darkly secret. Isn't there someone out there who has some PHASE ZERO compatible source code of any calibre, function or description which they could part with? I, for instance, am working on an ASCII file compression subroutine - not very impressive, but I AM TRYING TO LEARN 68000 ASSEMBLY!!! So are a lot of others, I wager. Share your stuff!!! Don't be embarrassed about rough edges in your comments. Any old garage sale subroutine or bargain basement hacker code is WELCOME. We need a library of such so that 1) the new guys can learn by tearing apart 68K code (there ain't much around outside DTACK grounded), and 2) we can eventually assemble collections of programs for distribution so that we don't all try to reinvent the wheel. Those who have gotten disks already should feel just a tiny bit obligated to repay the tremendous favor done thee by those who have placed their work in the public domain." Jeff Hull, Director, DSEX

Most folks are lazy, Jeff - FNE.

"I'm a lowly physisist (who) is very interested in the DTACK board with a math chip." Pete C, Cambridge MA

Pete, physisists are not lowly amongst our readers. We have mountebanks, charlatans and lechers and even an economist amongst our subscribers. (According to noted economist Paul Samuelson, "Times are so parlous that the Poles are telling economist jokes.") But no aluminum siding salespersons, so far.

Page 17, Column 1

"I recently received all your back issues and have been reading them in reverse order. I assure you that they make just as much sense this way. But this vast accumulation of opinionata is mentally damaging. The result (hideous revelation) is that I have literally been dreaming MIPS, Full Gallon, "FNE"... (cure by sending check for 128K Grande?)... Who is this (censored) Newsletter Editor? He/she/it does not give his/her/its name (for obvious reasons).

"In issue #23, on page 7, 2nd col, 5th par, you opened a parenthetical comment which extended over four and a half pages until it was closed by the unbalanced right parenthesis of the unfortunate Bob P. Obviously he was trying to do you a favor (your gratitude was somewhat lacking).

"In issue #10, p.6; 'Yeah' is a synonym for 'yes.' The correct synonym for 'hooray' is 'yea' or 'yay.' And is it copyrighters or copy writers or just hack admen that PHASE ZERO rents?

"Gratuitously cruel comment: 'HALGOL' is a terrible name. Your language will bear no resemblance to Algol, the ancestor of Pascal. Let me see, it's a language... talk... DTALK GRUNTED? ...Your damn newsletter (DNL) needs a global index!" Ralph D, Mt. Laurel NJ

You are not reading backwards fast enough, Ralph. The origin of the name HALGOL is given on page 1 of issue 12. WE get to make the editorial corrections around here, understand? Even when we don't. Sending us a check for a Grande is a MARVELOUS idea. If it doesn't make YOU feel better, it will most certainly make US feel better - FNE

Oliver B, the irate Teuton from MOOOSE SYSTEMS in Hamburg, has written to protest that we misrepresented his last letter. The reason the stamps are all sold out in the Hamburg area is that Oliver purchased so many to answer your inquiries. He assures us that he and MOOOSE SYSTEMS always answer all inquiries, even the ones without return postage.

Oliver, we mis-read your letter. Will you accept our apology? AND, you happen to be the first of several persons who have suddenly jumped on us about a BASIC written in C NOT having "TWO" levels of interpretation. Okay, it DOESN'T have two levels. But it IS one heckuva lot slower than a BASIC interpreter written in assembly. If you will not permit us "TWO levels of interpretation", what alternate terminology would you suggest to correctly represent the facts?

Also, we have just discovered that Microsoft's LISA BASIC is an EARLY version of deliberately busted BASIC and is in fact largely written in PASCAL, as we broadly hinted on the front page of issue #16. - FNE

Page 17, Column 2

"I have a question about the reset routine on the CRIB SHEET. The Apple II utility routines place a garbage byte in the LS374 between the wait and the setting of D3 high but the crib sheet doesn't. The utility routine works but the crib sheet routine appears not to. What difference does that garbage byte make to the hardware?" Michael H, St. Paul MN

Michael, your FNE mever nakes mistakes. Use the one in your 6502 source code for now, O.K.? Sigh.

"On page 266 of Noy '83 PC World, there is a letter which has to be the "dumb shit" submission of the month. Apparently some folks can't recognize a screen editor if it kisses them! (Probably has something to do with brain damage incurred by prolonged use of an Apple II.) Maybe HALGOL, which does have a screen editor, oughta watch out?" Understandably Anonymous

That was a cruel remark, U.A. Just because your Commodore model has a screen editor nearly as good as HALGOL's doesn't mean you can make fun of Apple owners or the writer of that unfortunate letter. - FNE

"Thanks to the marvels of photocopying, I now have issue #20 which I've read and will now photocopy for others. Re page 13: what sort of bird is a carrier piDgeon?

"I like the Grande. Love the idea of a megabyte to myself. I still can't afford it, of course, but hobbyists are like that. I still can't bring myself to like the idea of a software refresh. However... that megabyte of memory solves a hell of a lot of other problems." Eric L, Faulconbridge Australia

Carrier pidgedns are the principal source of nourishment for faulcons, Eric. It's just as well that you can't afford a full gallon on account of we can't sell you one. Better get used to refresh delays. The 68000 is almost totally bus-bandwidth limited, so there is no way for invisible refresh. If you like predictable timing, you either have to do as LISA and the Apple II do: use the memory half the time for video refresh, which provides automatic DRAM refresh but slows the CPU down something fierce, OR:

Mask the interrupt (temporarily!). The Grande DOES permit masking the refresh interrupt. It turns out that this is sometimes NECESSARY, so it's a good thing that it is possible.

Are DTACK photocopies the Sears Catalog of Faulconbridge? Is Faulconbridge three dingas and a billabong or is it a thriving center of commerce? Doesn't standing upside down make you dizzy?

Page 18, Column 1

"Yesterday I received ALL the issues of DTACK GROUNDED and stayed up way too late chuckling over those witty figures of speech and reminiscing over early days of programming an a Wang 22OOVP. (It's not everyone who knows the simple pleasure of typing MAT SORT instead of 15 lines of code.) We still don't have our Grande, but..." Willie S, Dalton GA

You do NOW, Willie. And, doggone it, you've let the cat out of the bag about MAT SORT (and MAT SEARCH and...). We were going to introduce that feature in HALGOL next spring and claim we invented it ourselves. (YOU non-Wang types: MAT SORT and MAT SEARCH operate on alpha arrays.) EARLY days? Wang VP??

"I consider your views on many topics to be dead-on accurate, perceptive and always well expressed and fun to read but I as still baffled at how badly you have missed the boat on HLLs.

"Your attempt to make the 'real world marketplace' the last word in the ongoing and evolving argument between assembler (ASM) and HLL is something of a scoundrel's last refuge. The reason I and many others prefer to wage this battle in the ethereal realm of logic and reason rather than over the sales counter is that the micro marketplace is still in its infancy and is only now being shaped by what you and others are publishing. Not nearly enough hard data exists yet to draw the kinds of conclusions you are trying to draw. After all, the marketplace is merely the product of a bewildering set of individual consumer's prejudices; logical, illogical and often ignorant.

"...it is clear that the advertising campaign for 1-2-3 is a thousandfold more effective than the advertising campaign for Context's MBA. To simply cite sales figures for two products out of 20,000 and then state your conclusions is no proof of your assertions at all.

"Oftentimes the marketplace IS wrong and sometimes dangerous. Consider cigarettes, DDT, and PCB. Once the marketplace smiled on these products but a little experience has shown, beyond a shadow of a doubt, that the marketplace was wrong.

"...If the proponents of ASM prevail in the marketplace then the Information Revolution is doomed because every programmer on Earth will spend 90 hours a week strictly maintaining and modifying unreliable and unmaintainable ASM programs. Progress will cease. Consider this market reality and understand why the market must be fought, shaped and tamed rather than surrendered to. For a software purist, like me, it is worth fighting the ignorant and shortsighted marketplace to find a place of prominence for Modula-2 and selected other HLLs no matter what the marketplace currently says.

Page 18, Column 2

"CP/M is #1, MS-DOS is #2, UCSD P-system is #3. The UCSD P-system is 90% INTERPRETED Pascal and its success can not be dismissed or ignored. I would say that the marketplace is sending out MIXED signals, wouldn't you?" John B, Burlingame CA

John, if you and we agreed an everything then one of us would be unnecessary. Since this is OUR keyboard, YOU would then be in big trouble. We can't recall having ever asserted that we were always right, and we make that assertion even less frequently now that we have been proven spectacularly wrong over the error rates of 64K DRAMs. But we ARE a newsletter editor and we do as newsletter editors must: we offer our opinion.

You are absolutely the FIRST strong HLL supporter to address the issue of the marketplace. You have done so by asserting that the marketplace is wrong. Let us both thank and congratulate you for this. You and we seem to be agreed that HLLs and the marketplace oppose each other. (Other supporters of HLLs who have written to us have refused to even consider the marketplace.)

We congratulate you on your willingness to fight for your convictions. Please excuse us if we do not purchase stock in the company you work for or in the computer manufacturer for which you have written an operating system or programming language in HLL. YOU say know that the marketplace is wrong but Wall Street ain't got the message yet. Oh, yes: Lotus has just gone public and, if we are reading the trade journals correctly, Mitch Kapor is now worth $5 million. He did it in 18 months from a standing start with assembly. But so what? It's only money, right?

The SCUD P-system is #3? In what position is DOS 3.3, running on one million- plus Apples, or whatever operating system is used on the 1.5 million-plus Commodore 64s?

One final message for you and other HLL proponents: if the temperature under the collar gets too hot, think instead for a while about the things on which we are in agreement - FNE.

"Terry P sent me a copy of your Nov '93 newsletter. Couldn't put it down. Cheered 16 bits < 8 bits; cackled over the IBM/Commodore follow-on, and collapsed into hysterics when you zapped UNIX and C (very painful, since I spent the last two evenings vomiting sadly all over BYTE's latest praisemongerings of same). What a delight to find common sense, competent analysis, hard information, and a splendid disregard for what passes as the current fashion (fashion = modish b*llsh*t).

Page 19, Column 1

"Most of us who have (the SuperPet) like it well, but see it inevitably overwhelmed. Commodore can't make enough '64s, and has more or less abandoned us to put its resources where the sales are. If we can get your 68000 add-on, and IF we can convince Waterloo to adapt the micro languages to the 68000, we have a super-smart terminal for your black box, and Waterloo has a tremendous market - C64, 8032, 9000 [Victor 9000? Sonny Tufts? - FNE], PC. I've drafted a letter to John W. at Waterloo regarding writing versions of the Waterloo interpreters/op system/library for the 68000. Either Waterloo does it or time overwhelms and obsoletes the present versions (or they jump to another processor).

"...I note that hardware makes tremendous advances, and languages languish. Having found, in the Waterloo languages, something BESIDES Pascal which is well-structured (without Pascal's verbal flatulence), easy to write, easy to REWRITE whenever it needs revision, modular, and transferable, I'm loath to leave the package for anything else I now know about. (I) see lots of real fast new computers with immense memories and the same old crummy last-generation languages." Dick B., Hatteras, NC

John B, meet Dick B, Dick, this is John. The rest of you: we did NOT write either Dick or John's letter, both are - as far as we can tell from this end - legitimate.

If Waterloo brings up a 68000 version of their package which is device-independent, it only requires a new bios plus some tinkering with DOS for a new machine such as the Apple. In addition to the support us folks at DTACK intend to provide (NOT 9000), Waterloo should not overlook the Trash 68 being developed in Knoxville or the Mackintosh being developed in Cupertino.

Obviously we would be overjoyed to have Waterloo and their extensive package available for our DTACK customers - we could get real friendly with APL, and would even be willing to play with (ugh!) Pascal if it were interactive, as Waterloo's is. By the way: why didn't you like our newsletter?

(The Waterloo SuperPet package, written for the 6809, includes BASIC, FORTRAN, PASCAL, APL, and COBOL. All are interactive and interpreted; no separate compilation is required. Dick B. is the editor of the SuperPet Gazette - (919) 986-2443.)

DSEX note: Bob P. has been, er, persuaded to document and submit his SLOTCHANGER program to the DTACK SOFTWARE EXCHANSE. Now we can all (?) run our DTACK boards in slots other than #2. We would like to thank Bob for his public-spirited gesture. We also hope his arm, which was severely wrenched, gets well soon.

Page 19, Column 2

MC68000 vs. iAPX 286:

In the last issue we provided HALF of a comparison of the "code efficiency" of the 68000 vs. the 286. You will recall that we stated unequivocally that the 286 was more code efficient. That happens to be true IF AND ONLY IF we make the assumption that code and data are restricted to 64K. The moment you pass 64K the 286 - in fact the entire Intel 16-bit line - becomes unbelievably klutzy. As we have pointed out, the 68000 can move a megabyte (or so) using only six instructions:

      MOVE.L  #src,A0 
      MOVE.L  #dst,A1 
      MOVE.L  #count,D0 
  AA  MOVE.B  (A0)+,(A1)+ 
      SUBQ.L  #1,D0 
      BNE     AA

Performing the above task using an Intel microprocessor becomes an incredibly complex and difficult task. Consider that the data will not, in general, be evenly aligned on 64K boundaries and that the alignment of the source and destination will not match. Even the simple "SUBQ.L #1" becomes a multiple-instruction operation using multiple conditional branches since the Intel line can only do 16-bit arithmetic (can you imagine?).

[The only way to truly understand the difficulties imposed by segmentation is for YOU to personally try to duplicate the above code on an Intel microprocessor.]

Tasks which the 68000 can handle in a trivially simple manner become XXX's using Intel microprocessors once 64K is passed. (In former days, we would have used the expression "chinese fire drill" for XXX. However, one cannot use ethnic expressions these days, so we used "XXX" instead of "chinese fire drill." We hope all of you appreciate the care we have taken not to offend.)

THE BUSTED TRICYCLE:

By now all of you must have seen the AMD ad for the 286 which likens the 68000 to a busted tricycle. You will recall the fine - make that tiny - print which states that the performance of the 68000 has been "adjusted" and that details will be provided on request. THAT IS A BUNCH OF BULLSHIT!

We personally wrote, formally and on Digital Acoustics letterhead, to AMD at the address given on the ad. The letter respectfully requested details of the "adjustment(s)" and was mailed three months ago. We included a copy of the ad in question so that there would be no doubt about what we were writing about. WE HAVE RECEIVED NO REPLY WHATEVER. You don't suppose that AMD won't admit how they fudged the data, do you?

Page 20, Column 1

THE murmured ANSWER:

Motorola has finally come up with an answer to those AMD and Intel ads, but they are very nearly keeping the answer(s) secret. It seems that Motorola's legal beagles (the rumor goes) don't think it's proper to mention one's competitor or to do direct competitive comparisons in ads where the name of the competitor is given. (Where have those legal beagles BEEN the past fifteen years?)

So, although Motorola has assembled some devastating rejoinders to that busted tricycle, you will have to personally contact them for that information. The most comprehensive reply is a 64 page document entitled "M68000 VS. iAPX 286 - A CONTRAST" dated Aug '83. Unfortunately this very informative document is turgid; it can be read only with the help of great concentration and in several sittings. (We have had the document for a month and we are about two-thirds the way through.) Read this document if you MUST, else stay clear.

A much more accessible ("reader-friendly") document is: "BENCHMARK REPORT #1: A SUMMARY OF EDN BENCHMARKS." Still, you will still have to approach Motorola personally to get one. If there is any doubt in your mind as to the relative merits of the 68000 vs. the 286, it would be worth your while to do so.

ADVANTAGE MOTOROLA:

AMD and Intel have reported to you that the 286 is a great deal faster than the 68000. In BENCHMARK REPORT #1, Motorola informs you that the 68000 is a great deal faster than the 286. We reported to you, back in issue #15 (pp10,11), that the 286 was superior to the 68000 in some applications and that the 68000 was superior in other applications. In our particular area of interest, which is a (mostly) single-tasking personal computer with lots of memory, the 68000 is a much better device. Further, the 68000 has been in production at 12.5MHz for 10 months and the 8MHz 286 does not yet exist as a production device.

What Motorola has done is to REVERSE the AND/Intel tactic of specially selecting ways to make the 286 look good and the 68000 look bad. Turn about is fair play, no? Let us give you, with Motorola's assistance, some of the stunts that AMD and Intel have pulled to make the 68000 look bad. And, since we try to be even-handed here, believe it or not, let us tell you how Motorola has rigged ITS comparisons.

Some of the stuff Intel did, such as using a slow 8MHz 68000 and adding two wait states for memory management, you already know about. What you - and up to now, we -

Page 20, Column 2

did not know was how they had "adjusted" EDN's actual timings. One cute trick Intel pulled was to add (on paper) task switch times to the 68000 benchmarks but did NOT add equivalent times for the 286! Additionally, Intel nicely overlooked the fact that 68000 I/O interrupts do not REQUIRE a task switch. [This stuff is related to multi-tasking.]

Intel uses 68000 benchmarks written for 16.7 megabytes of memory space and compares them to 2B6 benchmarks WHICH ARE CONSTRAINED TO OPERATE MITHIN 64K.

A couple of direct quotes from Motorola:

"(EDN's) Bit Matrix benchmark (K) from Intel does not even work. In order to speed it up, only a small percentage of input arguments will correctly run. The data must reside in the first byte of its segment and cannot extend any further than 1/8 of the maximum segment size. This is due to the lack of any 32-bit registers and the severe segment restrictions an Intel microprocessors. The MC68000 version works for all matrices anywhere in its large linear address space!'

"In none of Intel's benchmarks do they handle the case of a data ites straddling a segment boundary. Intel's own application notes show that just to access a simple scalar array of over 64K in size takes from over five to over eight times longer than the 68000!'

INTEL vs. INTEL:

Intel even rigged its benchmarks of the 286 vs the 8086, as we reported to you one and a half years ago (issue #10, p10, col2, par 2). In addition to the info we gave you way back then, Intel took the additional advantage of not using its MMU mode of operation in comparing the 286 to the 8086. As Motorola reports: "...THUS THE PROTECTED iAPX 286 RUNS THE EDN BENCHMARKS ONLY 37% FASTER THAN THE 8086! WHAT HAPPENED TO INTEL'S CLAIM OF 3 TO 6 TIMES FASTER?"

LARGE DATA STRUCTURESs

More Motorola quotes: "The iAPX 286 MMU makes it almost prohibitive to access large data structures. Operations on 32-bit data types or large data structures are so difficult to code on the iAPX 286 [sound like a chinese fire drill to you? - FNE] that Intel never even bothers trying. Their own application notes show an unbelievable 5 to 8 times slower execution time accessing a simple array element as compared to the 68000... Since almost all performance oriented microprocessor systems must run in a memory space of more than 64K bytes it is possible to obtain an accurate picture of just how the iAPX 286 fares in the real world by looking at its execution times... when handling data structures over 64K in size.'

Page 21, Column 1

THE MOTOROLA "adjustments":

AMD and Intel "adjusted" the 68000 performance data. What is sauce for the goose is also sauce for the gander, no? Motorola has added "...simple insertions of the necessary segment overrides in Intel's '86 architecture to allow accessing the entire address space or required by the iAPX 286 MMU." (Motorola also turned on the 286's wonderful - but slow - MMU.) Motorola also points out, as we frequently have, that full speed 68000's are available and full speed 286s aren't. Here are the "adjusted" EDN benchmarks, Motorola edition, all without wait states:

EDN BENCHMARKS:

                   12.5 68000     8 8086      8 80296 

 A  I/O Interrupts       25.6         43.2        96.8 
 B  I/O Processing      259.2        396.0       357.3 
 E  String Search       127.0        201.0       128.4 
 F  Bit Manipulation     55.4        127.1        97.9 
 H  Linked List         116.8        269.0       199.8 
 I  Quicksort            13.9         38.3        36.1 
 K  Bit Matrix          289.1        938.5       508.8

All times given above are microseconds except the guicksort benchmark, which is in milliseconds. Note that the 12.5MHz 68000 beats the 286 in all seven benchmarks. In fact, the string search benchmark is the only one where the 286 was even CLOSE. Well, we TOLD you the 286 wasn't worth a damn once 64K was passed, didn't we?

WHAT DOES THIS ALL PROVE? Why, it proves that whoever gets to "adjust" the other guy's performance is going to win. What did you expect?

We think the conclusions we reached and published in issue #15, p 11, col 1 may be the fairest and most unbiased comparisons of the 286 and the 68000 which have yet reached print. And issue #15 is a year old.

The point is, for the applications) that WE favor, the 68000 is in fact vastly superior to the 286. You want to lock 32 sheep each into its very own 64K? The 286 may be just the machine for you, and goodbye sir, do not let the door strike you in the buttocks upon the hopefully proximate occasion of your egress.

THE IBM PC XT/370:

There have been a lot of stories about this machine, not all of thee accurate. Let us fill you in. About a year ago, we read in Electronics magazine about IBM's attempt to turn three 68000s, interconnected, into a chip set that would directly execute the instruction set of the IBM 370. Although the register set of the

Page 21, Column 2

68000 is almost exactly like the register set of the 370 (16 ea 32-bit registers) the 60000 microcode ROM is not large enough to permit one 68000 to be reprogrammed with the instruction set. The reason for the multiple 68000s, interconnected, is to gain access to a larger microprogram control store.

The 68000 was being modified in Armonk with the cooperation of Motorola. Although we thought we had reported this in this newsletter, we could not find it (in 527 pages: maybe we need an index?).

The final result appears to be a startlingly good piece of work. IBM wound up with two custom 68000s and an Intel 8087 (whether custom or not we dunno) interconnected to execute the 370 instruction set directly (NOT a software emulation), along with a conventional 68000 for 'housekeeping'. This set of boards is in turn connected to a PC/XT as - naturally - an attached processor.

The newspaper articles which assert that the PC XT/370 uses multiple 68000s are therefore not quite right and the Electronics magazine article (3 Nov '83, p 47) which refers to "two custom IBM microprocessors" is not quite right either. In addition, the Electronics article has an IBM spokesman downplaying the performance of this machine. The PC XT/370 will in fact provide EXCELLENT performance, as we clearly stated that a 68000/8087 combination would way back in newsletter #2.

What's that? You say "thank you for the information and goodbye, I am on my way to buy a PC XT/370?" We're not worried. You'll be back about two microseconds after you price some 370 software.

IBM has released the PC XT/370 for one reason and one reason ONLY: if users are going to offload mainframes onto VERY intelligent terminals, then IBM wants thee to be IBM's VERY intelligent terminals. We think they have accomplished that and we think they have permanently locked up the desktop computer business in large companies which use the IBM computers AND we think they have given large companies which are NOT 370-compatible a reason to switch.

The IBM PC has been widely criticized as being low-tech and selling only because of the IBM logo, which is probably true. If you hear anybody grouse about the XT/370 being low-tech, then the person doing the grousing is uninformed, to put it mildly.

If you are wondering how IBM made the (quasi) 68000s work with the 8087, remember that IBM modified the microcode. And they MAY - considering their excellent (cough) working relationship with Intel - have been able to modify the 8087 as well.

Page 22, Column 1

THE LAST GASP SALOON:

That's where Microsoft's chances of selling 125,000 XENIX licenses this year is hanging out, and he is, well, heavily inebriated. Has anybody noticed how sales of the Tandy 16 really took off after XENIX became available with that machine? That's funny, neither did we. In fact, we have at hand a detailed report on the sales performance of different areas of Tandy's computer business in the past year and the business machines - that's the models 12 and 16, the last with wonderful **** XENIX **** performed the WORST of all Tandy's computer lines,

In fact, the sales of business computers as a percentage of Tandy's total computer sales DECLINED from the preceding year. Gee! And XENIX became available on the Model 16 last year. Shouldn't that have given sales of the Tandy 16 a TRENENDOUS impetus? Our very good friend Gary Friedman, who is the President of Fortune Systems, was telling us just a few months back how WONDERFUL cheap 60000-based UNIX (or UNIX-like?) systems were. Say: have any of you seen Gary lately?

Not to worry. We've heard LISA is going to be available with UNIX or a look-alike. LISA is the expensive (by Apple II standards) 60000-based computer which is benchmarked elsewhere in this issue running more slowly than Applesoft.

HALGOL PROGRESS REPORT:

While we have been sidetracked by the Nat Semi 16081, hardware, software, benchmarks etc. our full time HALGOL programmer has been grinding away. We can now, interactively from the Apple keyboard, enter a HALGOL program, edit a HALGOL program, RENUMBER a HALGOL program, LIST a HALGOL program to either the CRT or a printer, write loops, RUN a HALGOL program, and PRINT results. That's pretty good news.

This is still primitive HALGOL with no LET (formula) statement, and that is your FNE's fault because we quit when we had that about 65% completed to work on the 16081. We still can't load or save HALGOL programs to and from disk.

The limited things that we CAN run do so VERY swiftly. There is ABSOLUTELY NO POSSIBILITY that you will wonder whether you are running Applesoft or HALGOL. If you own a DTACK board, look for a disk as an XMAS present from us - the LAST free disk, regrettably. After this, we will have to charge for disks. (And the HALGOL XMAS present might be late.)

Yes, there will be a version of HALGOL which supports the 16081. No, it will not be available this XMAS.

Page 22, Column 2

ANYBODY SEE A DRAGON?

We are running out of dragons. Nobody wants to read about how slow the iAPX 432 is anymore. The outcome of our fight with the DRAM dragon is ALSO not discussed around here anymore (but for entirely different reasons). Fortune Systems, which was one of the first entrants to jump on the cheap 68000/UNIX bandwagon, has just become the first to jump off. (The slow learners are still trying to climb on board.) The HLL/assembly battle is over; the task at hand is to clear away the dead and wounded. We are pleased to report that some of our readers have come over to our point of view as a result of what we have written (and some had reached that viewpoint before us). Those who continue to cling to HLLs are impervious to the facts, and no rational argument is going to sway them.

Like we said, we need a new dragon. The 286-68000 advertising battle is a good candidate for the general public but we think our audience already favors a large linearly addressable memory space.

Quixote's dragon is Sancho's windmill. Maybe we ought to concentrate for a while on mundane stuff like math processors and a case and maybe even a power supply or (gasp!) a HALGOL that works well enough to be useful?

REVERSE PROGRESS:

Now that Fortune has dumped UNIX in favor of a faster operating system, will UNIX REVIEW continue to point with pride to the 16:32 as an example of a successful UNIX system?

PERMISSION IS HEREBY granted to anyone whomever to make unlimited copies of any part or whole of this newsletter provided a copy of THIS page, with its accompanying subscription information, is included.

THE FOLLOWIN6 TRADEMARKS ARE ACKNOWLED6ED: Apple, II, II+, IIe, soft, LISA: Apple Computer Co. Anybody else need a 168th 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

THIS MONTH'S REDLANDS features a logarithm routine EXACTLY like the one in REDLANDS, issue #16 (both use HART index 2665), except that the Nat Semi 16081 is used to, er, somewhat speed up computations.

Page 23, Column 1

A LOGARITHM CALCULATION
IN 269 MICROSECONDS:

Beginning on the next page is a 68000/16081 logarithm algorithm based on Hart index 2665, the same that we used for the HALGOL/48 transcendental package published in newsletter #16. The program flow does not at first appearance seem identical because there were a lot of subroutines called which have been replaced here with (almost) straight-line code. Also, the constants used will appear different, but they are in fact the same. Here are some floating point representations;

    #          HALGOL/48              IEEE 754 (draft) 
    1    $1001  8000 0000  0000    $0000 0000 0000 3FF0 
    5    $1003  A000 0000  0000    $0000 0000 0000 4014 
   -5    $9003  A000 0000  0000    $0000 0000 0000 C014 
 SQR(2)  $1001  B504 F333  F9DE    $3BCD 667F A09E 3FF6

Nat Semi has chosen to store their numbers in reverse order from the Microsoft and HALGOL/48 sequence. The word in lowest memory is the least significant word of the mantissa, while the highest word in memory contains the sign, exponent, and five bits of the mantissa (counting the "hidden" bit).

Note that the MSB is the sign bit in both formats. In HALGOL/48 the next two bits are "don't cares", for a 62-bit format. Then we have thirteen exponent bits, expressed as "excess $10000". Then we have a 48-bit mantissa whose most significant bit is always a one unless the number is a zero. The mantissa ranges from 1/2 to ALMOST one. The number one is expressed by 2 to the first power times 1/2.

The IEEE 754 (draft) standard is radically different, the only similarity being the sign bit in the most significant position. The next 11 bits are the exponent, expressed as "excess $3FF". The most significant bit of the mantissa is "hidden", or implicit, This "hidden" bit is followed by 52 additional mantissa bits, for a total of 53.

The IEEE format places the decimal point in the mantissa between the "hidden" bit and the remainder of the mantissa. The mantissa thus lies between one and almost two. The floating point representation for the number one is therefore one in the mantissa times an exponent of zero. The only non-zero mantissa bit is the "hidden" one.

Because the IEEE format uses 5 more mantissa bits than HALGOL/48, it has 32 times greater resolution, or 1 1/2 more decimal digits of precision. HALGOL/48 does not use the IEEE format because it is a spectacularly poor "fit" for the 68000's registers and ALU. If you don't believe us, read the benchmark times on page 5.

Page 23, Column 2

The 68000 must simulate in software what the 16032/81 does in hardware. This is especially true when reading one of the double precision registers of the 16081. See lines 243-249 on the back page. We send the I.D. byte to wake up the 16081, then the command word to read out the register. Now we have to wait 10 clocks of the 68000 (five clocks on the 16081) before reading the 16081 status word. Then and only then can we read out the four-word (8 byte) register value. Why read the status word? You don't have a choice; that's how the 16081 works.

If you test that instruction with only an 8-clock delay you have a 50-50 chance of having the instruction work. The reason is that the 68000 instructions can have one of two phase relationships with the 16081 since the 16081 clock is the 68000 clock, divided by two.

The 68000 instruction set is very peculiar in that there are ALMOST NO instructions which require an odd number of clock cycles to execute. (Can you find the exception?) YOU MUST BE SURE TO TEST YOUR 68000/16081 SOFTWARE USING BOTH POSSIBLE PHASE RELATIONSHIPS. We did; that's why we are using a ten-clock delay instead of eight before reading out the status register when reading a register of the 16081.

Nobody wants to re-write an assembler to aaccomodate both the 16081 and 68000 so we assigned names to all of the operations we were interested in, and set up "EQU" assignments for each of those names. Since you will undoubtably want to move a floating point operand from outside the 16081 somewhere into a 16081 double precision floating point number, you will want to assign EQUs for the four possibilities:

  MEMTOF0 EQU $04A0 
  MEMTDF2 EQU $84A0 
  MEMTOF4 EQU $04A1 
  MEMTOF6 EQU $84A1

A thoughtful glance at those codes will show that bit #15 and bit #0 determine which register is involved. The reason for this "split" parameter field will be discussed in next issue.

On p.26, the P(6) times register F0 multiply begins on line 148. But P(6), two long-words, were pre-fetched into the 68000 data registers on lines 109, 110 and the instruction was prefetched on line 143 as a part of the delay waiting for the 16081 to complete moving register F0 to F4. Such prefetching can overlap the operations of the 68000 and 16081 for maximum speed.

Also note that the four addresses peculiar to the 16081 were prefetched at line 34 on page 24, along with the most common I.D. byte (to D6). This provides a considerable saving of bus bandwidth.

Page 24

                        2          LIST 
                        3 ;COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 
                        4 ; 
                        5 ; CALC LOG2 THEN MULT BY LOG10(2) RESULT LOG(10) 
                        6 ; 
00260A: 7E02            7 LOG10    MOVEQ   #2,D7          ;2 = BASE 10 I.D. 
00260C: 6012            8          BRA     LOGB           ;CALC LOG10 
                        9 ; 
                       10 ; CALCULATE THE LOGARITHM TO THE BASE 2 
                       11 ; 
00260E: 7E01           12 LOG2     MOVEQ   #1,D7          ;1 = BASE 2 I.D. 
002610: 600E           13          BRA     LOGB           ;CALC LOGE 
                       14 ; 
                       15 ; THE FOLLOWING LIST IS USED TO SPEED FLOATING 
                       16 ; POINT OPERATIONS USING THE NAT SEMI 16081 
                       17 ; 
                       18 ; D6 = FPU ID WORD       A3 = PTR TO FSTAT 
                       19 ; A1 = PTR TO FPU ID     A4 = PTR TO FDONE 
                       20 ; A2 = PTR TO FPU OP     A5 = PTR TO FACC1 
                       21 ; 
002612: 00BE           22 LIST     DC.W    $00BE          ;FPU ID WORD 
002614: 0E80           23          DC.W    FID            ;FPU ID WORD PTR 
002616: 0EE0           24          DC.W    FOP            ;FPU OP WORD PTR 
002618: 0EA0           25          DC.W    FSTAT          ;FPU STATUS PTR 
00261A: 0E00           26          DC.W    FDONE          ;FPU DONE FLAG PTR 
00261C: 1902           27          DC.W    FPACC1         ;FP ACC IN MEM PTR 
                       28 ; 
                       29 ; CALC LOG2(X) THEN MULT BY LOGE(2) RESULT LOGE(X) 
                       30 ; 
00261E: 4247           31 LOGE     CLR     D7             ;0 = BASE E I.D. 
002620: 11C71912       32 LOGB     MOVE.B  D7,FLAG 
002624: 48E7007C       33          MOVEM.L A1-A5,-(A7)    ;SAVE A1 - A5 
002628: 4CB83E402612   34          MOVEM.W LIST,D6/A1-A5  ;FETCH PTRS 
00262E: 241D           35          MOVE.L  (A5)+,D2       ;FETCH FPACC1 
002630: 2615           36          MOVE.L  (A5),D3 
002632: 3803           37          MOVE.W  D3,D4          ;TEST MSB 
002634: 6BCA           38          BMI     ERR3           ;NO LOG IF NEG 
002636: 6602           39          BNE     LOGOK          ;OK IF NOT ZERO 
002638: 67CA           40          BEQ     ERR4           ;NO LOG IF ZERO 
                       41 ; 
                       42 ; 
                       43 ; FOR NOW IGNORE MICKEY-MOUSE IEEE SOFT UNDERFLOW 
                       44 ; 
                       45 ; 
                       46 ; THE OPERAND IS LEGAL;  PROCEED WITH LOG2 CALC 
                       47 ; 
00263A: 0243000F       48 LOGOK    ANDI.W  #$000F,D3      ;MASK EXPONENT 
00263E: 3A3C3FE0       49          MOVE.W  #$3FE0,D5      ;EXP = -1 TO D5 
002642: 8645           50          OR.W    D5,D3          ;EXP = -1 IN D3 
                       51 ;

Page 25

                       53 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 
                       54 ; 
                       55 ; SET THE OPERAND RANGE TO SQR(.5) =< X < SQR(2) 
                       56 ; 
002644: 307C2776       57          MOVE.W  #SQRH+8,A0     ;PTR TO SQR(.5) 
002648: B6A0           58          CMP.L   -(A0),D3       ;COMPARE 1ST HALF 
00264A: 6604           59          BNE     LOG2A          ;DONE IF NOT SAME 
                       60 ; 
00264C: B4A0           61          CMP.L   -(A0),D2       ;COMPARE 2ND HALF 
00264E: 670A           62          BEQ     LOG2B          ;O.K. IF SAME 
                       63 ; 
002650: 6A08           64 LOG2A    BPL     LOG2B          ;O.K. IF FPACC1 > 
                       65 ; 
002652: 06430010       66          ADDI.W  #$10,D3        ;EXP = $3FF 
002656: 04440010       67          SUBI.W  #$10,D4        ;DECR ORIG EXP 
                       68 ; 
                       69 ; SEND X TO FPU REGISTER F0 
                       70 ; 
00265A: 3286           71 LOG2B    MOVE.W  D6,(A1)        ;SEND ID TO FPU 
00265C: 34BC04A0       72          MOVE.W  #MEMTOF0,(A2)  ;MEM TO REG F0 
002660: 2482           73          MOVE.L  D2,(A2)        ;SEND OPERAND X 
002662: 2483           74          MOVE.L  D3,(A2) 
                       75 ; 
                       76 ; SEND F.P. #ONE TO FPU REGISTER F4 
                       77 ; 
002664: 307C2776       78          MOVE.W  #FPONE,A0 
002668: 3286           79          MOVE.W  D6,(A1)        ;SEND I.D. 
00266A: 34BC04A1       80          MOVE.W  #MEMTOF4,(A2)  ;MEM TO F4 
00266E: 2498           81          MOVE.L  (A0)+,(A2)     ;LOW 2 WORDS 
002670: 2498           82          MOVE.L  (A0)+,(A2)     ;HIGH 2 WORDS 
002672: DE87           83          ADD.L   D7,D7          ;6 CLOCK DELAY 
                       84 ; 
                       85 ; MOVE F0 TO F2 (DUPLICATE X IN F2) 
                       86 ; 
002674: 3286           87          MOVE.W  D6,(A1)        ;SEND I.D. 
002676: 34BC8400       88          MOVE.W  #F0TOF2,(A2)   ;MOVE F0 TO F2 
00267A: 363C1020       89          MOVE.W  #F4SUBF0,D3    ;PREFETCH NEXT CMD 
00267E: 4E71           90          NOP                    ;4 CLOCK DELAY 
                       91 ; 
                       92 ; CALC X - 1 IN F0 (F0 - F4) 
                       93 ; 
002680: 3286           94          MOVE.W  D6,(A1)        ;SEND I.D. 
002682: 3483           95          MOVE.W  D3,(A2)        ;F0 = F0 - F4 
002684: 9845           96          SUB.W   D5,D4          ;SUBTR EXCESS $3FF0 
002686: E844           97          ASR.W   #4,D4          ;NORMALIZE EXP 
002688: 363C8020       98          MOVE.W  #F4ADDF2,D3    ;PREFETCH NEXT CMD 
00268C: 3E14           99 LOG2E    MOVE.W  (A4),D7        ;FPU DONE ? 
00268E: 6AFC          100          BPL     LOG2E          ;WAIT UNTIL DONE 
                      101 ;

Page 26

                      103 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 
                      104 ; 
                      105 ; CALC X + 1 IN F2 (F4 + F2) 
                      106 ; 
002690: 3286          107          MOVE.W  D6,(A1)        ;SEND I.D. 
002692: 3483          108          MOVE.W  D3,(A2)        ;F2 = F4 + F2 
002694: 2018          109          MOVE.L  (A0)+,D0       ;PREFETCH P(6) 
002696: 2218          110          MOVE.L  (A0)+,D1 
002698: 363C2010      111          MOVE.W  #F2DIVF0,D3    ;PREFETCH NEXT CMD 
00269C: 3E14          112 LOG2F    MOVE.W  (A4),D7        ;FPU DONE ? 
00269E: 6AFC          113          BPL     LOG2F          ;WAIT UNTIL DONE 
                      114 ; 
                      115 ; CALC (X-1)/(X+1) IN F0 
                      116 ; 
0026A0: 3286          117          MOVE.W  D6,(A1)        ;SEND I.D. 
0026A2: 3483          118          MOVE.W  D3,(A2)        ;F0 = F0/F2 
0026A4: 363C8401      119          MOVE.W  #F0TOF6,D3     ;PREFETCH NEXT CMD 
0026A8: 594D          120          SUBQ.W  #4,A5          ;CORRECT PTR 
0026AA: 3E14          121 LOG2G    MOVE.W  (A4),D7        ;FPU DONE ? 
0026AC: 6AFC          122          BPL     LOG2G          ;WAIT UNTIL DONE 
                      123 ; 
                      124 ; MOVE Z = (X-1)/(X+1) TO F6 
                      125 ; 
0026AE: 3286          126          MOVE.W  D6,(A1)        ;SEND I.D. 
0026B0: 3483          127          MOVE.W  D3,(A2)        ;MOVE F0 TO F6 
0026B2: 363C3030      128          MOVE.W  #F6MULF0,D3    ;PREFETCH NEXT CMD 
0026B6: 4E71          129          NOP                    ;DELAY 4 CLOCKS 
                      130 ; 
                      131 ; CALCULATE Y = Z * Z IN F0 
                      132 ; 
0026B8: 3286          133          MOVE.W  D6,(A1)        ;SEND I.D. 
0026BA: 3483          134          MOVE.W  D3,(A2)        ;F0 = F6 * F0 
0026BC: 363C0401      135          MOVE.W  #F0TOF4,D3     ;PREFETCH NEXT CMD 
0026C0: 3E14          136 LOG2I    MOVE.W  (A4),D7        ;FPU DONE ? 
0026C2: 6AFC          137          BPL     LOG2I          ;WAIT UNTIL DONE 
                      138 ; 
                      139 ; STORE Y IN F4; RETAIN IN F0 ALSO 
                      140 ; 
0026C4: 3286          141          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
0026C6: 3483          142          MOVE.W  D3,(A2)        ;MOVE F0 TO F4 
0026C8: 363C30A0      143          MOVE.W  #MMULF0,D3     ;PREFETCH NEXT CMD 
0026CC: 4E71          144          NOP                    ;DELAY 4 CLOCKS 
                      145 ; 
                      146 ; MULTIPLY P(6) TIMES Y IN F0 
                      147 ; 
0026CE: 3286          148          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
0026D0: 3483          149          MOVE.W  D3,(A2)        ;MEM * F0 
0026D2: 2480          150          MOVE.L  D0,(A2)        ;SEND P(6) 
0026D4: 2481          151          MOVE.L  D1,(A2) 
0026D6: 7405          152          MOVEQ   #5,D2          ;SET LOOP COUNT 
0026D8: 600C          153          BRA     LOG2L          ;ENTER LOOP 
                      154 ; 
                      155 ; NEXT PERFORM SERIES EVALUATION;  HART 2665 
                      156 ; MULTIPLY Y (F4) TIMES F0, THEN ADD P(N) TO F0 
                      157 ;

Page 27

                      159 ; COPYRIGHT DIGITAL ACOUSTICS INC 
                      160 ; 
0026DA: 363C3020      161 LOG2K    MOVE.W  #F4MULF0,D3    ;PREFETCH NEXT CMD 
0026DE: 3E14          162          MOVE.W  (A4),D7        ;ADD DONE ? 
0026E0: 6AF8          163          BPL     LOG2K          ;WAIT UNTIL DONE 
                      164 ; 
0026E2: 3286          165          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
0026E4: 3483          166          MOVE.W  D3,(A2)        ;F0 = F4 * F0 
                      167 ; 
0026E6: 363C00A0      168 LOG2L    MOVE.W  #MADDF0,D3     ;PREFETCH NEXT CMD 
0026EA: 2018          169          MOVE.L  (A0)+,D0       ;PREFETCH P(N) 
0026EC: 2218          170          MOVE.L  (A0)+,D1 
0026EE: 3E14          171 LOG2M    MOVE.W  (A4),D7        ;MULTIPLY DONE ? 
0026F0: 6AFC          172          BPL     LOG2M          ;WAIT UNTIL DONE 
                      173 ; 
0026F2: 3286          174          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
0026F4: 3483          175          MOVE.W  D3,(A2)        ;ADD MEM TO F0 
0026F6: 2480          176          MOVE.L  D0,(A2)        ;SEND P(N) 
0026F8: 2481          177          MOVE.L  D1,(A2) 
0026FA: 363C3020      178          MOVE.W  #F4MULF0,D3    ;PREFETCH NEXT CMD 
0026FE: 51CAFFDA      179          DBF     D2,LOG2K       ;LOOP 6 TIMES 
                      180 ; 
                      181 ; NOW MULTIPLY P(Y) BY Z 
                      182 ; 
002702: 363C3030      183          MOVE.W  #F6MULF0,D3    ;PREFETCH NEXT CMD 
002706: 3E14          184 LOG2N    MOVE.W  (A4),D7        ;ADD DONE ? 
002708: 6AFC          185          BPL     LOG2N          ;WAIT UNTIL DONE 
                      186 ; 
00270A: 3286          187          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
00270C: 3483          188          MOVE.W  D3,(A2)        ;F0 = F6 * F0 
00270E: 363C81A0      189          MOVE.W  #INTTOF2,D3    ;PREFETCH NEXT CMD 
002712: 2018          190          MOVE.L  (A0)+,D0       ;PREFETCH LOGE(2) 
002714: 2218          191          MOVE.L  (A0)+,D1 
002716: 3A3C30A0      192          MOVE.W  #MMULF0,D5     ;PREFETCH 2ND CMD 
00271A: 3E04          193          MOVE.W  D4,D7          ;TEST FOR ZERO 
00271C: 6718          194          BEQ     LOG2Q          ;SKIP IF ZERO 
00271E: 3E14          195 LOG2O    MOVE.W  (A4),D7        ;MULTIPLY DONE ? 
002720: 6AFC          196          BPL     LOG2O          ;WAIT UNTIL DONE 
                      197 ; 
                      198 ; EVALUATION OF LOG(2) IS COMPLETED FOR THE RANGE 
                      199 ; SQR(.5) TO SQR(2).  NOW CONVERT THE EXPONENT FROM 
                      200 ; 2'S COMPLEMENT INTEGER TO F.P. AND ADD IT TO 
                      201 ; COMPLETE THE LOG FUNCTION BASE 2. 
                      202 ; 
002722: 32BC003E      203          MOVE.W  #$003E,(A1)    ;CONVERSION I.D. 
002726: 3483          204          MOVE.W  D3,(A2)        ;16 BIT INT TO F2 
002728: 3484          205          MOVE.W  D4,(A2)        ;SEND OPERAND 
00272A: 363C0010      206          MOVE.W  #F2ADDF0,D3    ;PREFETCH NEXT CMD 
00272E: 3E14          207 LOG2P    MOVE.W  (A4),D7        ;CONVERSION DONE ? 
002730: 6AFC          208          BPL     LOG2P          ;WAIT UNTIL DONE 
                      209 ; 
                      210 ; ADD CHARACTERISTIC TO MANTISSA 
                      211 ; 
002732: 3286          212          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
002734: 3483          213          MOVE.W  D3,(A2)        ;F0 = F2 + F0 
002736: 1E381912      214 LOG2Q    MOVE.B  FLAG,D7        ;RECALL BASE FLAG 
00273A: 670A          215          BEQ     LOGEX          ;SKIP IF BASE E 
                      216 ; 
00273C: 5307          217          SUBQ.B  #1,D7          ;BASE 2 OR 10 ? 
00273E: 6712          218          BEQ     LOG2X          ;SKIP IF BASE 2

Page 28

                      220 ; COPYRIGHT 1983 DIGITAL ACOUSTICS, INC 
                      221 ; 
                      222 ; COMPLETE THE EVALUATION OF THE LOG BASE 10 BY 
                      223 ; MULTIPLYING BY THE LOG BASE 10 OF 2. 
                      224 ; 
002740: 5048          225          ADDQ.W  #8,A0          ;POINT AT LOG10(2) 
002742: 2018          226          MOVE.L  (A0)+,D0       ;PREFETCH CONSTANT 
002744: 2210          227          MOVE.L  (A0),D1 
                      228 ; 
                      229 ; LOGE EXIT;  INSTRUCTION AND CONSTANT PREFETCHED 
                      230 ; 
002746: 3E14          231 LOGEX    MOVE.W  (A4),D7        ;ADDITION DONE ? 
002748: 6AFC          232          BPL     LOGEX          ;WAIT UNTIL DONE 
                      233 ; 
00274A: 3286          234          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
00274C: 3485          235          MOVE.W  D5,(A2)        ;F0 = MEM * F0 
00274E: 2480          236          MOVE.L  D0,(A2)        ;SEND CONSTANT 
002750: 2481          237          MOVE.L  D1,(A2) 
                      238 ; 
002752: 363C0405      239 LOG2X    MOVE.W  #F0TOMEM,D3    ;PREFETCH NEXT CMD 
002756: 3E14          240 LOG2R    MOVE.W  (A4),D7        ;FPU OP'TN DONE ? 
002758: 6AFC          241          BPL     LOG2R          ;WAIT UNTIL DONE 
                      242 ; 
00275A: 3286          243          MOVE.W  D6,(A1)        ;SEND I.D. BYTE 
00275C: 3483          244          MOVE.W  D3,(A2)        ;MOVE F0 TO MEM 
00275E: 4E71          245          NOP                    ;4 CLOCK DELAY 
002760: DE87          246          ADD.L   D7,D7          ;6 CLOCK DELAY 
002762: 3E12          247          MOVE.W  (A2),D7        ;DISCARD STATUS 
002764: 2AD2          248          MOVE.L  (A2),(A5)+     ;RESULT TO FPACC1 
002766: 2A92          249          MOVE.L  (A2),(A5) 
                      250 ; 
002768: 4CDF3E00      251          MOVEM.L (A7)+,A1-A5    ;RESTORE REGS 
00276C: 4E75          252          RTS                    ;LOG CALC DONE 
                      253 ; 
                      254 ; CONSTANTS USED BY THE LOG ROUTINES 
                      255 ; 
00276E: 3BCD667F      256 SQRH     DC.L    $3BCD667F      ;SQR(.5) 
002772: A09E3FE6      257          DC.L    $A09E3FE6 
002776: 00000000      258 FPONE    DC.L    $00000000      ;ONE 
00277A: 00003FF0      259          DC.L    $00003FF0 
00277E: 74971B88      260          DC.L    $74971B88      ;P(6) 
002782: 4C233FCF      261          DC.L    $4C233FCF 
002786: B4F8F412      262          DC.L    $B4F8F412      ;P(5) 
00278A: B9003FD0      263          DC.L    $B9003FD0 
00278E: 07502000      264          DC.L    $07502000      ;P(4) 
002792: 85123FD4      265          DC.L    $85123FD4 
002796: 2B18FDC4      266          DC.L    $2B18FDC4      ;P(3) 
00279A: 61743FDA      267          DC.L    $61743FDA 
00279E: BF3E51DE      268          DC.L    $BF3E51DE      ;P(2) 
0027A2: 776C3FE2      269          DC.L    $776C3FE2 
0027A6: 5C74DC39      270          DC.L    $5C74DC39      ;P(1) 
0027AA: C7093FEE      271          DC.L    $C7093FEE 
0027AE: 8307652B      272          DC.L    $8307652B      ;P(0) 
0027B2: 15474007      273          DC.L    $15474007 
0027B6: 39EFFEFA      274          DC.L    $39EFFEFA      ;LOGE(2) 
0027BA: 2E423FE6      275          DC.L    $2E423FE6 
0027BE: 2A2D54D0      276          DC.L    $2A2D54D0      ;LOG10(2) 
0027C2: 44133FD3      277          DC.L    $44133FD3