Issue # 8 DTACK GROUNDED Newsletter - April 1982
NOW WE ARE FAMOUS!
Well, sort of. We made the March 31 issue of EDN magazine, on four different pages yet! On page 34 they wrote about us as an alternative to the Tandy 68000 upgrade; they put our name (and phone number) on page 36; and our board was written up on page 138 as part of a DIFFERENT article by a different author. That other article gave us a single line on yet another page, making four pages in all. For you software types, EDN (Electronic Design News) is one of the three major electronic design magazines published in this country. It is barely possible that our phone may be ringing a tad the next few weeks!
In lieu of a brochure, we have put together a 'sampler' of the Dtack Grounded newsletter. This 'sampler' is sized equivalent to one newsletter; that was 14 pages until this issue, which is going to 16 pages. At 16 pages, we are just barely under two ounces, and that only when the humidity is low!
The reason we are going to 16 pages is that we continually get caught short of space, and it is REDLANDS that usually suffers. As you can see, we have also decided to use the compressed type available courtesy of EPSON. We now have two Epsons, one for our Apple II and the other for our CBM 8032. This newsletter is being typed on the 8032 using Wordpro 4+. Wordpro 4+ is a fine text editor which unfortunately does not support many of the features available on the Epson. In fact, Wordpro 4+ really needs a daisy wheel printer of the NEC, Diablo, Qume variety. But then what do we do for compressed type?
Enough digression. The point is, this and future issues of the Dtack Grounded newsletter will contain at least 6O% more text than most prior issues. Note that we make a distinction between text and information. Part of the problem is that we now have a real product and we are developing real software to run on that product. Reporting on this software is space consuming. Last issue we reported some software surfacing from customers. In this issue that WELCOME trend continues and WILL continue in future issues. We know right now of two more software packages coming up whose authors do not want to announce until the package is done. Neither package will be very expensive.
Page 1, Column 2
We understand that we will be featured in the April issue of PEELINGS II, with a photograph of our board on the front cover yet! For those of you who do not own Apples, 'PEELINGS II' is a magazine dedicated to reviewing SERIOUS Apple software. They are quite candid in their reviews. Maybe we should not have told you about them until we have seen the review ourselves? We don't know what they say about our board, but we HAVE been told that the text file of the review occupies about 50 sectors on disk!
By the time you receive this, the first issue of '68000 MICRO NEWS' will be in print. The first issue will go about 40 pages and will list about 37 different 68000 computer vendors. One vendor is Dtack Grounded, which has been shipping product since last fall. Another is the Apple Computer Company, which emphatically is NOT shipping product! (They are listed as 'in development', we understand.) Because this magazine will be VERY important to the 68000 user community, we are repeating their address here:
211 N. 7th Street
Allentown PA 18102
$25/yr (12 issues)
We are happy to report that, judging by the prospectus, 68000 MICRO NEWS is NOT going to be exclusively a vehicle for printing ghost written articles with accompanying four color photographs. We have spoken to the publisher, and his background is in engineering, not marketing!
As soon as we can find the time to turn our hat around and prepare some advertising copy, we will be running ads again, this time half page and with photos of the hardware. Because of publishing lead times, you probably will not see any of these ads until midsummer.
In this issue we will update the current status of the 8087, discuss downgrades (yes, DOWNgrades!), tell you maybe more than you ever wanted to know about a 3-D graphics demonstration program and about how stupid we are. Oh? You already knew about that last one?
Somewhere in a future issue we will print a dissertation on virtual memory which has been sitting in a text file since December. We also have a text file full of answers to some of the commonly asked questions about our board. Yet another text file is holding the writeup on the fix for the 'GOTO' delay in long Pet or Apple programs. Like we have said in the past, our problem in editing this newsletter is NOT finding material, but rather to select what DOESN'T get published!
Page 2, Column 1
INTEL 8087 STATUS REPORT:
We are going to relate not just the status of the 8087 but also HOW we obtained that information. The purpose is to elicit sympathy from the reading audience for the plight of the poor circuit board designer.
From past issues of this newsletter, we recall that a new mask was due around the start of this year. So we called the local Intel sales office and asked for news on the 8087. We were assured that the new mask on the 8087 worked perfectly and worked at 5MHz. We decided to check this story with the 8087 product manager's office at the factory.
The factory representative assured us, "The 8087 is absolutely fully functional." When we asked about the speed we were told "the device is meeting all specifications, including the 5MHz clock rate." When might we be able to purchase some of these wonderful chips, we asked? "These parts will be available within 6 weeks. The price will be $450, quantity one. The part number is", and here he proceeded to give us a part number, which we wrote down on a piece of scratch paper.
(The conversation reported above actually went on for five or ten minutes, during which me were repeatedly told that the part was fully functional, and at 5MHz.)
Aha! Progress! we thought. When our purchasing agent tried to order the 8087, the answer came back, "do you want the 8087-3 or the 8087-5?" Oops! At that point, we personally got on the phone and asked, "by any chance does that -3 mean 3MHz and the -5 mean 5MHz?"
"You clever devil!" replied the person on the other end of the line, who happened to be the Intel product specialist and also of the female persuasion. "Anyone that clever MUST need some Tony Hamilton calendars for his office." What the heck is a whoosis Hamilton calendar and why should we want one, we asked? "A Tony Hamilton calendar is a large rectangle of cardboard which has a 1982 calendar printed on the right and has a manuscript featuring Tony Hamilton's life history stapled on the left. It tells how Tony as a boy scout was more patriotic, thrifty and reverent than all the other scouts in his troop, how he single-handedly won the war of 1812 - maybe it was same other war. The 'more thrifty' part I can personally attest to, my paycheck-"
"Wait a minute!" we burst in. "The subject was the purchase of an Intel 8087, you may recall." She replied "But we are holding a contest to see who can find good homes for the most Tony Hamilton calendars. They are really beautiful calendars, with the correct dates and everything. The photo of Tony on the front of the manuscript is lovely, even if it IS slightly retouched."
Page 2, Column 2
"At least," she went on, "I don't think the halo is completely natural". And what might the winning prize be in the contest, we asked? "As you know, sales are down because of the recession. The prize is, I get to keep my job!"
"Look, we're sorry, but we don't need any calendars. But we do need at least one 5MHz 8087. We guess that's the -5 part? "Right!" she replied, "I can sell you an 8087-3 for only $460 and get you pretty quick delivery from the factory. But we have NO price and NO delivery date on the -5 part." No thanks, we need the 5MHz part, we said. "Too bad. Well, we'll put Amalgamated Digital Acoustic Industries down for 83 Tony Hamilton calendars anyway. Ta ta!" she signed off.
So, we went back and checked our notes and sure enough, after being repeatedly assured that the 8087 worked at 5MHz we had been told to order a -3 part! Procreatae illegititis prevaricatum!
That, friends, is the sort of thing that us (instrument? computer?) design types run into more often than is desirable. And you would never guess that our local Intel distributor is Hamilton Electro Sales.
COPROCESSORS AND CLOCKS:
You will all have figured out by now that a 3MHz 8087 is nearly twice as slow as a 5MHz 8087. The problem, however, is WORSE than that! You see, the nature of coprocessors is that EACH of the two or more coprocessors INDIVIDUALLY monitors the instruction stream. Let us consider a simple case where there are only two coprocessors, an 8086 (or 8088) and an 8087. When an 8087 instruction is detected, the 8086 detects this fact and automatically relinquishes the bus. The 8087 automatically takes over - and this is important - WITHOUT any time-consuming handshake procedures (that's why coprocessors are faster than peripherals).
A necessary corollary is that the 8086 CANNOT run with a faster clock than the 8087 because they are both monitoring the instruction stream constantly! If the 8087 erroneously thinks it detects one of its instructions the result will be DISASTROUS because the 8086 will NOT relinquish the bus and the 8087 will try to take over ANYWAY. Remember, there is no time-consuming handshake to prevent this. The bottom line is that the maximum clock speed of a coprocessor system is limited by the maximum clock rate of the SLOWEST of the coprocessors.
And THAT means, dear friends, that the 3MHz 8087s which are now available are NOT REPEAT NOT going to plug in alongside a 5MHz 8086 or 8088. Hear THAT, IBM computer fans? It also seems that the many ads for S-100 based 8086/8087 systems are somewhat optimistic for now.
Page 3, Column 1
SO WHAT DOES THAT MEAN FOR A DTACK GROUNDED 8087 BOARD?
Actually, this affects US far less than it does those people who are trying to run the 8087 with their PRINCIPAL PROCESSOR (if we may use that term). You see, our principal processor is a 68000; the ONLY reason for us to use an 8086 is as a clock generator for the 8087. You may recall that we referred to the 8086 as a 40 pin clock generator back in newsletter #2. Therefore, we have the luxury of operating an 8087 at a clock rate which is TOTALLY INDEPENDENT of the 68000 clock rate.
However, that $460 price tag is pretty steep for a chip which runs slightly faster than HALF the anticipated speed. And two OTHER changes have occurred: the Motorola 68881 math coprocessor has been announced and we have developed our own fast graphics floating point package. Our FP multiply time is 32 microsec, for example. Our sine routine runs in 370 microsec, SQR in 160 microsec (times are averages).
High speed graphics computations were ONE of the applications we had in mind for the 8087. A 3MHz clock and the development of our fast FP package combine to shoot THAT application down!
Nothing stays the same; Intel will eventually bring out a 5MHz version of the 8087 and/or drop the price of the 3MHz version substantially. Most complex chips of this kind, including the 68000, appear in initial versions with slower than anticipated clocks. We WILL bring out a math processor board when price, performance and need become reasonably congruent.
THE MOTOROLA COPROCESSOR?
The Motorola 68020 32 bit processor with which the 68881 math processor acts as a coprocessor has been announced as a 16 MHz part. The 68881 math processor has been announced as an 8 MHz part. For the time being, let's assume these figures are correct. What does this mean?
Let us first (hypothetically) construct the highest performance microcomputer possible (once the 68020 is available). This means we run the 68020 at 16 Mhz. Naturally, we reserve an empty socket next to the 68020 for the 68881 math coprocessor. Some time passes. Now we decide to buy a 68881 and plug it in to that empty socket. We turn the microcomputer on. It jumps 3 feet (one meter for you metric fans) straight up into the air and crashes down on its left side, billowing clouds of purple smoke!
The mistake we made was to try to run an 8 MHz coprocessor at 16 MHz. That won't work, guys (Oops! Sorry, Linda). We can always cut back the clock rate on the 68020 to 8MHz. Now our microcomputer system will run correctly! Unfortunately, during those periods when the coprocessor is NOT being used, our microcomputer is only half as fast as it as BEFORE we mounted the math coprocessor! And we no longer have the highest performance microcomputer possible.
Page 3, Column 2
AN INSOLUBLE DILEMMA?
Heck, no! We explained the correct solution to this problem way back in newsletter #2. You probably thought we either didn't know what we were talking about or that we were taking a cheap shot at Intel. WRONG! The problem we are discussing is fundamental to ANY system where the math coprocessor runs more slowly than the microprocessor to which it is to be attached. At the time newsletter #2 was written, the Intel 8087 was the ONLY math coprocessor which was realistically forthcoming.
So, in newsletter #2, we pointed out that the best way to build a high performance microcomputer system was to use the best available microprocessor (running at the fastest available clock rate) as the principal processor and to use the BEST AVAILABLE math coprocessor to perform the floating point computations. The best available math processor uses a DIFFERENT microprocessor as a host? WHO CARES? Use that different microprocessor as a clock generator (!) for the math coprocessor.
This is the BEST, repeat BEST way to construct a high performance system. Now that Motorola has announced the 68881, what would be the BEST way to use that part? Simple. Use a full speed 68020 (16 MHz) as the principal processor and use a second 68020, at 8MHz, as a clock generator for the 68881. We made fun of the Intel 8086 as a 40 pin clock generator for the 8087. Well, the 68020 will have between 80 and 100 pins! How about an 80 to 100 pin clock generator?
THIS ALSO GIVES US SOME FREEDOM: One of the aspects of coprocessors which has not been discussed is that the way the darned things work implies that they have to be hooked to the SAME manufacturer's microprocessor. This is CORRECT! That also implies that the system must be based on that manufacturer's microprocessor. This is NOT correct! We received a great deal of flak both from Intel and from the brighter people we initially contacted about our concept. The flak was over the well-known fact (?) that it is absolutely IMPOSSIBLE to use the 8087 with the 68000! That well-known fact happens to be false.
The truth is, we have the option of using the 8087 with the 68000, the 68881 with the 8086 or 8088, and other combinations and permutations. What happens if the 68881 turns out to be less desirable (or less available) than the 8087? No problem; use the 8087!
Page 4, Column 1
WHAT IS THE PROBLEM? WHY NOT RUN THE MATH UNIT AT FULL SPEED? The current generation processors use 16 bit internal data buses; the next generation will use 32 bit data buses. The internal adder (ALU) is the same width as the internal data bus. ALL, repeat ALL high performance double precision floating point math processors will have a 64 bit internal data bus and therefore a 64 bit adder. The add time for 64 bits is necessarily longer than for 16 or 32. That is why the 16 bit 8086 is NOW available in 10 MHz versions but the 64 bit 8087 is only available in a 3 MHz version.
In other words, the problem is unrelated to a specific manufacturer. Also, the problem is NOT going to go away!
ENOUGH OF THIS TALK ABOUT HIGH PERFORMANCE MICROPROCESSORS! LET'S HEAR IT FOR SOME REALLY LOW PERFORMANCE STUFF! You are tired of hearing about upgrades? Maybe you would prefer to hear about downgrades? We define downgrade as an add-on processor to an existing computer which has LOWER performance than the original processor. Yes, such a device DOES exist!
No, we are NOT talking about 6809 processor boards for the Apple II. We have stated in clear and unambiguous terms that the 6809 outperforms the 6502 by a small margin. Therefore, a 6809 processor board for the Apple II qualifies (barely) as an UPgrade.
The specific DOWNgrade processor we are talking about is called 'Baby Blue' and is a Z80 add-on for the 8088 based personal computer manufactured by IBM, a company you may have heard of. 'Baby Blue' is manufactured by Xedex, a new company which you have probably not heard of. Their sales manager, after consulting his dartboard, has projected sales of 60,000 units at $600 retail THIS YEAR! According to our less than trustworthy TI 58, that's $36 million retail the first year for a brand new startup company. Our reaction is that that is a heck of a lot of downgrades
WHY WOULD ANYBODY WANT TO BUY A DOWNGRADE? For an existing software base, of course. There are MORE than ten thousand programs available on CP/M. Although they can, in principle, be converted from 8080 code to 8088 code, the conversion process is not COMPLETELY automated. And the size of the resulting object code DOES grow, by about 10% according to Intel. The net result is that several dozen of the most popular CP/M programs have been converted to run on the 8088. That leaves more than ten thousand which have NOT been converted. Thus: Baby Blue.
In our last newsletter we stated that the emerging de facto standard method of upgrading from 8 to 16 bits was to continue running 8 bit code as 16 bit systems and 16 bit application programs become more readily available. We further stated that, in the case of the 68000, that meant having a $2.50 8 bit processor physically available to run the 8 bit code. But in the case of the 8086/8088, translated 8080 code would suffice. The introduction of Baby Blue (if it is a success) means that the 8086/8088 ALSO needs a resident $2.50 8 bit processor.
Page 4, Column 2
AN OUTSTANDING ARTICLE ON 16 BIT PROCESSORS appeared in the Mar 8 issue of Electronic News. This is a 123 column inch (!) article on the current status of all of the various 16 bit entrants into the microprocessor market. Interviews with the top marketing people at TI, Motorola, National, Fairchild etc. were included. If you need to know MORE about the various devices than appears in our newsletter, look up this article!
For the rest of you, we are pleased to report that there is nothing whatever in the article which would contradict or even significantly modify anything which has appeared in these pages. The ONE surprise is the FIRST mention (that we have seen) outside of this newsletter which, in effect, says that the iAPX 432 is less than wonderful.
In fact, Intel executives are quoted in the article as stating FIRMLY that: 1) The iAPX 432 will NOT be abandoned, and 2) Intel had just decided (within the past week) to build a 32 bit version of the 8086.
It is a fact that all microprocessors are FULLY SUPPORTED by the company producing them right up until the INSTANT that they are removed from production. You can turn to the classified ad section of almost any issue of Electronic News and see a desperate request for Fairchild 9440 Microflame processor chips, which are no longer in production. One presumes that the part was designed into a project it a time when it WAS in production, and therefore FULLY SUPPORTED.
Microprocessor history is littered with abandoned 16 bit units (IMP-16, PACE, INS8900) formerly produced by National. In just the past week we chatted with an otherwise rational person who is seriously thinking of using the National 16032 rather than the 60000 or 8086 in a forthcoming personal computer. The 16032 is, of course, FULLY SUPPORTED by National. We hope the reader (that's you) is beginning to catch on why real, honest, PRODUCING second sources are so important!
Again, National Semi is a very good company with many excellent products whose past history in the 16 bit microprocessor field does not inspire confidence.
ON THE NEXT PAGE we will discuss a 3-D graphics demonstration program in detail. We even discuss exactly what goes on inside the 68000 when running this program. If that discussion seems complicated, well; 3-D graphics ARE complicated!
Page 5, Column 1
INTERACTIVE 3-DIMENSIONAL GRAPHICS DEMONSTRATION PROGRAM D6A
1) PURPOSE: This program is intended to demonstrate the extremely high performance of the 68000 processor as compared to the more modest capabilities of the venerable but obsolescent 6502. A secondary purpose is to provide a demonstration of Newton's equations of motion simulated in free space (the demo program is to be useful). We need to discuss the properties of the object to be manipulated by the operator (you!).
2) PROPERTIES: The object can have differing shapes in different versions of this program. Shape is NOT important! What IS important is that the object has a center of mass and six coordinates. Three coordinates are the usual X, Y and Z linear coordinates. The X coordinate is the horizontal or side to side position. The Y coordinate is the vertical or up and down position. If X and Y are both zero, the object is in the CENTER of the screen. The Z coordinate is the distance toward or away from the operator.
Since the CRT, which is the operator's 'window' into the simulated world is TWO-dimensional motion towards the operator is shown by having the object grow larger, and motion away is shown by having the object grow smaller. If the object is far away and slightly below the center of the screen, the object will apparently drop lower on the screen as it is brought directly towards the screen with no other motion.
The object is also described by three angles A, B and C. Angle A is the orientation in the plane of the CRT. Zero degrees is at 3 o'clock, and rotation is counterclockwise. Angle B is at right angles to the plane of the CRT. Finally, Angle C is the angle of spin about the major axis of the object.
3) OPERATOR CONTROL: The program permits the operator to control the object by accelerating the object along any of the three linear axes or about any of the three angular axes. Acceleration can be applied to only one axis at a time. The polarity of the acceleration is controlled by a 'sign' flag. Keying the 'left arrow' sets the sign negative, while the 'right arrow' key sets the sign positive. To accelerate towards the left, key the 'left arrow', then key 'X'. To continuously accelerate, rapidly key 'X' or hold both 'X' and the 'repeat' key down.
An important distinction must be made here between 'move' and 'accelerate'. If the object is in motion towards the left, then accelerating to the right will begin to slow the motion towards the left. Eventually, the motion towards the left will stop and the object will begin to move towards the right, slowly at first and then faster.
Page 5, Column 2
Suppose that the object is motionless on the left hand side of the screen and that we want to move the object to the right hand of the screen, also motionless. The procedure is to accelerate towards the right for HALF the distance and then to REVERSE the acceleration for the last half of the journey. This will not be immediately intuitive to anyone who has not studied Newton's equations or who is not a long time S-F fan. But that's how it works in free space!
4) OPERATOR LIMITATIONS: If the object exceeds the limits of the graphics screen, the program quits! It is therefore desirable to stay under control at all times! This aspect of the program can be used by the operator to invent his own 'games' based on the demonstration program, which is fundamentally NOT a game.
5) VELOCITY versus ACCELERATION: What we are doing by applying a constant acceleration on a given axis is to change the velocity on that axis at a constant rate. This is called 'ramping' the velocity, where the base of the 'ramp' is in general non-zero. The rate of change of the velocity is directly proportional to the acceleration. The velocity is therefore the integral of the acceleration and the acceleration is the differential of the velocity. The former relationship is most important since acceleration is the controlled variable.
6) POSITION versus VELOCITY: If the velocity is constant, the position changes linearly. Expressed another way, a constant velocity 'ramps' the position. Again, the base of the 'ramp' is in general non-zero. The position is therefore the integral of the velocity, which is the integral of the acceleration.
7) POSITION versus ACCELERATION: It follows from 5) and 6) that position is the double integral of acceleration. While this is a well defined mathematical relationship, it is NOT intuitive!
Although it is possible to train qualified persons to perform the mental gyrations necessary to use the property of acceleration to control position, it has not proven possible to do so in an OPTIMUM sense. Optimum here means with minimum energy expenditure. In the real world, computers are the preferred choice WHERE POSSIBLE. When the computer controlled descent path tried to land Apollo 11 on some boulders, Neil Armstrong had to assume manual command of the lunar lander. He got it down with 20 seconds' fuel left. He was, of course, using acceleration to control position. YOU can use this simulation program to do that, but more safely!
8) ADVANCED CONTROL: There are times when more, or less, than the usual acceleration is needed. The acceleration factors for the six axes are initialized to a nominal value, which we will arbitrarily call '1'.
Page 6, Column 1
Values of 1/16, 1/4, 4 and 16 are also available for any of the six axes separately and independently. We call the acceleration factors '1' thru '5' where 1 is the smallest acceleration and 5 the largest. Keying '5', followed by one of the six letters corresponding to one of the six axes will change the acceleration on that axis to the maximum value until such time as the operator decides to change it.
It is also possible to change the acceleration factor on all three linear axes (X, Y and Z) simultaneously by keying the factor (1 thru 5), then 'L' for Linear. All three angular accelerations can be changed simultaneously by keying the factor (1 thru 5) and then keying 'P'.
All six acceleration factors can be changed simultaneously by keying the factor (1 thru 5) and then keying 'M'.
The action can be frozen by keying 'F'. All keys except 'G' (go) are ignored while the action is frozen.
9) SUMMARY: This demonstration program requires a Dtack Grounded Apple compatible 68000 board with 4K RAM (that's the minimum configuration!). We hope that the program will hold your interest for a while and perhaps whet the interest of some of your younger friends in the field of mathematics and physics.
If some aspects of this demonstration program seem oversimplified (v.01 will be a 'wire frame' with no hidden lines) we ask you to remember that we are hardware types and that this is the FIRST graphics - 2D or 3D! - program WE have ever written! (We did slightly MODIFY another program before this - D3.FASTER.)
We suggest you stop reading at this point and get some 'hands on' experience with the program. When you have familiarized yourself with the features listed above, continue with the additional documentation below.
MORE INFORMATION ON "D6A"
MORE CONTROL: An additional control key (R) has been added. When 'R' is keyed all linear and angular velocities are zeroed, the X and Y coordinates of the center of mass are centered on the screen, and the Z coordinate is set to the minimum (closest) value consistent with being able to 'spin' the object without touching the edges of the CRT. All angles are set to zero. We call this control function 'RESET'.
Using 'RESET' for other than demonstration purposes is like cheating at solitaire since you can, of course, do the same thing using the regular controls. Right?
Page 6, Column 2
MORE BELLS AND WHISTLES: Since this is, after all, a demonstration program we have been unable to resist adding a few other touches, even if they are of a distinctly non-Newtonian nature! For instance, after keying 'R' you are presented with a static right side plan view. So we have implemented key '9', which works in conjunction with the three angular axis keys A, B and C. After keying '9', keying either A, B or C will cause the position of the object to shift on that axis by 90 degrees.
Try this exercise: key 'right arrow', 'R' and 'C'. Now you have a top plan view, pointed to the right. Key 'A'. The plan view is still of the top, but oriented upward. Now key 'B' and you have the front view. Or is it the back view? Are you going to let us get away with claiming a TOP view a few sentences back?
Use of this '9' key can be interspersed with use of the controls mentioned earlier. The '9' key does not affect the linear motion in any way. It will stay in effect for the angular axes until one of the keys '1 - 5' are pressed.
Key '8' works just like key '9', but the angular increments are 22.5 degrees, or one fourth of 90 degrees. Key '7' increments a sixteenth of 90 degrees. Key '6' increments by 15 degrees.
STATUS DISPLAY: Keying 'S' will cause seven symbols to be printed it the upper right of the screen. All are polarity signs, plus or minus (except when zero is appropriate on the bottom six). The top sign is isolated, and indicates the last setting of the left or right arrow keys. Then there is a space before a group of three signs. These three signs correspond to the signs of the angular velocities VA, VB and VC. Then another space followed by three more signs of the linear velocities VX, VY and VZ. You have to be clever enough to remember that the sequence from the top down is A, B, C for the top group of three and X, Y, Z for the bottom group of three.
Using the status display makes it such too easy to control the object, so you will naturally wish to key 'S' again. This turns the status display off.
SO YOU'RE COORDINATED TOO DEPT: It has come to our attention that some beginning operators have had difficulty controlling the object on the Z axis, the one directly toward and away from the operator. Especially without using the status display. This represents simple incompetence on the part of the beginning operator; the author of this demonstration program never had any trouble with the Z axis. You will believe this!
PSYCHOLOGICAL FACTORS: What you are seeing is, of course, a two-dimensional (ignoring the curvature of your CRT) representation of a three-dimensional object. Now close your left eye and look at your right hand.
Page 7, Column 1
Now close your left eye and look at your right hand. What you are seeing is a two-dimensional representation of a three dimensional object (honest!). The point is that the brain can readily interpret a two-dimensional view as a three dimensional object, particularly after it has seen a number of two-dimensional representations from different angles.
However, the 'wire frame' representation of the current program (no hidden lines) is ambiguous with respect to whether the object is pointed AT you or AWAY from you. Your brain will choose one or the other interpretation. If you glance away and then back, your brain may switch orientation on you. If, while slowly turning the object so that it points directly at (or away!) from you, your brain may decide to suddenly switch orientation on you just as the object passes through pointing 'straight at you'.
We point this out because we have already had two people complain about a bug in the program after seeing this effect! The bug is in a DIFFERENT program ...
This also points out the value of 'hidden lines' which generally remove this ambiguity.
HOW DOES THE PROGRAM WORK? Very swiftly. Oh, you're serious? Well, it works like this:
The 6502 and the 68000 are both busy when running this program. A basic cycle for the 6502 side is: A) send the keyboard data, one byte, to the 68000. B) Clear the HIRES screen which is not currently being displayed. C) Receive the graphics data from the 68000. D) Toggle the 'switch' to display this screen. This is the end of one basic cycle.
The basic cycle for the 68000 is: A) receive and interpret the keyboard character. B) Calculate the new position of the object by adding the velocity information to each of the three linear axes and the three angular axes. C) Calculate the distance of the object, SQR(X*X + Y*Y + Z*Z). D) Use this distance to scale the dimensions of the object. E) Calculate the sine and cosine of each of the three angles for later rotational transformation. F) Perform the three dimensional rotational transformation. G) Multiply the X coordinates by 1.29 so that objects positioned horizontally are the same apparent length as the same object positioned vertically. H) Add constants to the X and Y coordinates to map X=0, Y=0 into the center of the CRT. I) Fix the X and Y coordinates into integer format. J) Decide whether the slope of each line to be plotted is less or greater than one. If the slope is one or less, set up the plot data for that line in the form X1, X2, Y1, delta Y. If the slope is greater than one, set up the plot data in the form Y1, Y2, X1, delta X plus an identifier bit. Repeat this for all lines.
Page 7, Column 2
K) Wait until the 6502 is ready to receive pixel data, then send the data to the 6502. This completes one cycle for the 68000.
(Some detail has been left out of the above 68000 sequence. For instance, we check whether each angle exceeds plus or minus 2PI, and reduce the angle by 2PI if so.)
By using optimized 6502 machine code, we are able to clear the HIRES screen in between 55 and 56 milliseconds. However, the 68000 performs steps A) thru J) in only 15 milliseconds! This means that the 68000 spends 40 milliseconds twiddling its thumbs until the 6502 is ready to receive the pixel data! Finally, the pixel data is exchanged and plotted in an average of 25 milliseconds. The total cycle time averages 80 milliseconds, which means we get 12.5 new HIRES graphics representations per second!
It is also obvious that the extent of the calculations performed by the 68000 could be increased nearly 400% with no decrease in the update rate! This fact should be kept in mind as we continue this discussion.
NO MORE 4K SYSTEMS?
There are fewer than 200 bytes left in a 4K system when 'D6A' is run. Future enhancements to this program will NOT run on a minimum DTACK GROUNDED 68000 board. Well, those of you who have 4K systems didn't expect to stay at that level forever, did you?
POSSIBLE FUTURE EXTENSIONS AND ENHANCEMENTS:
The demonstration program as it now stands can obviously serve as the framework of more generally useful software packages (in more than 4K of RAM). Here we will discuss some of these possibilities:
A) 'Hidden lines' could be implemented on the current object.
B) A version of the program can be developed which uses the same techniques but controls velocity rather than acceleration. When you take your hands off the keyboard, the object remains motionless. This is what is needed to position an object at different viewing angles. (Actually, the implementation of the 'R' and the '6 - 9' keys provide same aspects of this method.)
C) User programmable objects could be added, with each 'object description' saved on disk as a named file. The user would specify the X, Y and Z coordinates of each point. Then, the point pairs between which lines are to be drawn would be specified. The limitations on complexity would be the 192 X 280 pixel resolution and the amount of memory on the 68000. It seems to us that a 12K system could hold more point and line data than could be usefully plotted on a 192 X 280 screen.
Page 8, Column 1
D) A set of utility subfiles could be developed so that an object (such as a chair) can be called up and automatically inserted in a larger object file (such as a room). This is an Applesoft, not 68000, type utility. However, consider this:
We define the room coordinates, save them up to the 68000 and use the 68000 to position the room in the desired orientation. Now we call up the 'chair' subfile and move it into a SECOND location in the 68000. Pay attention closely: We can now move the chair into the desired location and angle using the keyboard while leaving the room position fixed! Then we toggle a flag (key 'T'?) which permits moving the room AND chair into different viewing angles to be sure the chair is correctly positioned. If not, we toggle the flag back, locking the room into position, and continue to position the chair.
The '9' key, which can toggle back and forth from the side and bottom plan views with a keystroke will prove useful at tasks such as placement of a chair in a room.
When the final position of the chair is determined, we key 'Y' to 'save' the position of the chair. This adds the subfile to the data base of the larger object so that the entire object data can be saved to disk. The subfile will be 'tagged' to identify it AS a subfile. At a future time, any given subfile can be temporarily 'dropped' from the graphics representation. This can be done by keying 'D', followed by the number of the subfile, then RETURN. All temporarily 'dropped' subfiles would be restored to the CRT by keying 'D', 0, RETURN.
The way this would work in the 68000 is that each subfile 'tag' would have an active/inactive status bit. It would probably be useful to write an Applesoft routine to be able to permanently delete a specified subfile from the object data file stored on disk.
THOSE ARE POSSIBILITIES:
We are NOT in the software business. What we want to do is provide, at no charge, demonstration and utility software which works with our 68000 board. Our objective is to make our board more attractive for purchase (ARS GRATIA PECUNIA). Program D6A is obviously a demonstration type program. If we adapt this program to work with user definable object files (and we will), we think that version of the program could reasonably be described as a utility.
Page 8, Column 2
However, some of the more advanced bells and whistles described above are of marginal value to US, because we CANNOT program the world! And any one particular piece of programming that gets done means another that does NOT. A good utility such as a fast matrix inversion routine is, we believe, of more use generally than a lot of effort to provide a 'hidden line' version of D6A (which would require more than 4K to run).
SOFTWARE UPDATE POLICY:
Those of you who were among the initial purchasers of Apple compatible 68000 boards are already aware that we update our customers from time to time with demonstration and utility software, and at no charge yet! You know this, of course, because you recently received a nice CARE package containing a disk, a couple of dozen pages of source code and - who would have believed it? - NO invoice!
Will you receive future free updates? Yes. Will we ship out a new disk every time we come up with a new demonstration or utility program? No. Obviously, we cannot afford to ship free updates on a weekly (or even monthly) basis. Are we going to ship a disk tomorrow containing D6A? No. As we mentioned, we want to develop a user definable object version of the program. Also, there are a few OTHER projects we have in mind!
You don't like to wait? You don't have to. We have a new customer service software update policy to cover this situation. If any of our customers send us $10, we will make a copy of the most recent software that has been developed SINCE the last update and mail it. This offer is restricted to disk media; we aren't about to make special copies of source code. If several customers want to band together and order one disk and then provide their own duplicates, that's fine with us.
BOY ARE WE EVER STUPID!
Other manufacturers of upgrade processor boards for the Apple II SELL the software that works with their board! For instance, one vendor of a 6809 board which works with the Apple charges beau coup bucks for a floating point package which works with that board. On the other hand, the FIRST thing we GAVE AWAY with our board was a floating point package which is roughly ten REPEAT TEN times faster than the one they CHARGE for! And we include the source code!
In fact, we are publishing in this month's REDLANDS the complete SOURCE CODE for the very high speed graphics floating point package used in D3.FASTER and in D6A. This package is approximately 70 times faster than APPLESOFT's. This speed enhancement is made possible by: A) Using a processor which is about 13 times faster, on average, than the 1MHz 6502 used in the Apple, and B) restricting the mantissa of the floating point package to 16 bits. This gives a minimum resolution of one part in 32,768. That is more than 100 times better resolution than is needed for a 192 X 280 pixel HIRES screen!
Page 9, Column 1
Well, the code is complete for the four basic functions of add, subtract, multiply, divide. Space limitations preclude publishing the SQR, SINE, COS, FRAC, ROTATE routines in this issue. Maybe in a future issue?
ABOUT THIS F.P. PACKAGE:
This package only uses data registers 0, 1 and 2. That leaves 5 unused data registers for the program which is calling the floating point package. Like our Microsoft compatible 9 decimal digit package, there are two entrance points to each of the four basic routines. One assumes that both FPACC#1 and FPACC#2 have already been loaded. The other assumes that FPACC#1 is already loaded and that address register 0 points at the F.P. number which is to be loaded into FPACC#2. In this case, the address register indirect with postincrement addressing made is used. This means that A0 is pointing at the NEXT F.P. memory location after the subroutine is called.
The version printed here also uses address registers 1 thru 6 inclusive. Address register 1 points to the 4 byte FPACC#1 and also to the sign byte of FPACC#1. If you see a MOVE .L (A1) you know that the entire number is being moved. MOVE B (A1) means that the byte containing the sign bit (B7) is being moved. Address register 3 points at the two byte MANT1, the mantissa of FPACC#1. You will generally see MOVE .W (A3) except once in the divide routine where we deliberately want to move the two byte MANT1 into the high order bits of a 32 bit data register. For this purpose, we use MOVE .L (A3), Dn followed by CLR .W Dn to clear the garbage from the low order 16 bits. Finally, A5 points to X1, the exponent of FPACC#1. This is invariably used for one byte moves.
Address registers 2, 4 and 6 point to FPACC#2 in the same way that 1, 3 and 5 point to FPACC#1.
This same floating point package is used in program D3.FASTER. Although it may seen unusual to tie up all of the address registers for the floating point operations, it turns out that the resulting code IN THESE PARTICULAR GRAPHICS PACKAGES is both more compact and faster. These graphics packages alternate between intensive floating point calculations and intensive plotting. During plotting the address registers are used for a totally different purpose, mainly as pointers to the HIRES graphics Apple II memory mapping routines.
Page 9, Column 2
A single instruction, namely MOVEM (move multiple registers) is used once at the start of the computational part of the program and again at the start of the plotting part. Because the SQR routine requires the temporary use of two additional data registers and the SINE routine requires three additional data registers and an address register, the MOVEM instruction is used at the start and again at the end to save and then restore the registers in question. Therefore, the registers appear to be unused to the program which calls the SQR and SINE routines.
In applications which intermingle floating point and non-floating point operations, it will be undesirable to dedicate six address registers as pointers to the two floating point accumulators. Then a package such as that used in D3.FAST is needed where 'absolute short' addressing is used to work with FPACC#1 and FPACC#2. We mention this because all of our (Apple section) customers have a copy of the source to that package. We had not yet segregated the floating point data register use into D0, D1 and D2 at the time that package was written, however.
Translating the addressing from one method to the other is extremely simple. Review page 11 of newsletter #7 for examples.
THIS PACKAGE HAS SOME SWIFT!
This package performs the SINE routine in an average of 370 microseconds (!) as measured by a Tektronix model 475 oscilloscope which had been very recently calibrated by Tektronix. We put a dummy write into an unused RAM at the start and again at the end, that's how! By way of comparison, Applesoft requires about 17 milliseconds and a 4 MHz AMD9511 math processor chip requires MORE THAN 1 millisecond! (A 4 MHz 9511 is used by the fastest version of MICROSPEED, which is also to be reviewed in April PEELINGS II.)
We are enormously gratified to be able to report those speed comparisons in the above paragraph. You see, we have been defending ourselves for months against the pointy-headed idiots who INSIST on comparing the execution speed of that crummy six decimal digit precision 9511 math chip against a more generally useful 9 decimal digit precision package such as that used in the Pet and in Applesoft. That comparison is misleading, disgusting, out of order and also un-American. (Foreign readers are permitted to modify that last bit.) As we have repeatedly (and heatedly) explained, you can't do anything useful but graphics with a 9511. A small business cannot even balance its checkbook with it!
With our high speed graphics package with its 16 bit mantissa, which is ALSO useful for graphics work (at the limited precision inherent in pixel-mapped CRT displays) the shoe is very definitely on the other foot. Our sine calculation is nearly three times faster! Now the 9511 adherents can howl LONG AND HARD about unfair comparisons!
Page 10, Column 1
COMPARING ORANGES AND ORANGES: For the record, Motorola offers a 60000 floating point package which has IDENTICAL precision to the 9511. See newsletter #5, page 2. With an 8 MHz 68000, it outperforms the 4 MHz 9511 easily. And 12.5 MHz versions of the 68000 are now readily available for those who REALLY want to rub the 9511 adherents' nose in it!
Those readers who feel that your faithful newsletter editor thoroughly ENJOYED writing the above paragraphs are to be congratulated for their keen perception!
By the way, we KNOW that the 4 MHz 9511 is an Intel chip with a different part number so that you will think Intel invented it! Since AMD designed the part we think THEY should get the credit. But if you want 4 MHz you will have to go to Intel.
A SOFTWARE ANNOUNCEMENT FROM CASCADE GRAPHICS:
"A very powerful debugging tool called 'CGDBUG' is now available. CGDBUG is very similar to Motorola's MACSbug. Some of the features found in CGDBUG are:
- Set and display breakpoints
- Set and display memory
- Set and display all registers
- Trace instructions
- Define and display a graphics page
- Read and write data from/to disk
"CGDBUG is designed to run under the PASCAL Operating System. The price is $250.
"Also available are PASCAL to DTACK GROUNDED interface routines at $125." For more information contact:
MIKE ERVIN
CASCADE GRAPHICS DEVELOPMENT
1000 S. GRAND AVE.
SANTA ANA, CA 92705
(714) 558-3316
The above announcement would appear to be the initial surfacing of PASCAL support software for our board. It is unlikely to be the last (the 68000 is a magnificent P-code interpreter). Incidentally, we understand that UCSD PASCAL only offers single precision (six decimal digit) floating point. Our informant states that he avoids it whenever better precision is needed (which is often). This does not seem reasonable to us, but we are unable to contradict our informant. Can a reader enlighten us on this subject?
Page 10, Column 2
HARDWARE AND SOFTWARE STATUS REPORTS:
Early in the development of the DTACK GROUNDED Apple and Pet/CBM compatible 68000 boards we took the unusual step of telling our newsletter readers the truth about the status of our project. When the boards didn't exist except in prototype form, we said that. When we had the links to the Pet/CBM BASIC but not to Applesoft, we admitted that, too. The time has come to modify this policy somewhat.
First, carrying a software status report as a separate item is now ridiculous since such of this newsletter specifically discusses software which runs on our board(s). The bad old days when we might (or might not) have a single paragraph to report are gone. The software status report has served its purpose and is dropped as of now.
Second, the hardware status report tracked us from production prototype layout through production prototype; from having no production boards to having production Pet/CBM boards (but no Apple boards) to having a small initial production run of each of the boards. Well, both versions are in full production with 4K systems being shipped essentially 'off the shelf'.
The hardware status report, whose purpose was (initially) to candidly admit that the hardware did not (at first) exist and that we had nothing (at first) to deliver, has also served its purpose and is hereby dropped. Hardware announcements will continue to appear but NOT on a monthly basis.
ACKNOWLEDGEMENTS. Apple; singular, II and soft are trademarks of the Apple Computer Co. Pet and CBM are trademarks of Commodore business machines. Baby Blue is probably a trademark of Xedex (and Xedex was named by a palindrome fan). DTACK GROUNDED is OUR trademark. CP/M is a trademark of Digital Research of CA. MACSbug is a trademark of Motorola. Who did we miss?
SUBSCRIPTIONS: You can subscribe to this rag (lucky you!) by sending $15/6 issues U.S. and CANADA or $25/6 issues elsewhere. Tell us which # issue to start with. Make the check out to DTACK GROUNDED. The address is:
DTACK GROUNDED
1415 E. McFadden, St. F
SANTA ANA CA 92705
REDLANDS IS BACK IN FORCE! This month we have an absolute first, a scoop: an extremely high speed graphics floating point package, all four fundamental operations, for the 68000. Enjoy! We SINCERELY HOPE that the cheapskates among you were unable to obtain photocopies of the next six pages! Nyaa, nyaa!
Code Listing
1 OPT P=68000,BRS,FRS
0010F6 2 ORG $0010F6
3
0010F6 0851 0007 4 FPSUB1 BCHG.B #7,(A1)
0010FA 60 06 5 BRA FPADD1
6
7 * - START OF FLOATING POINT SUBTRACT ROUTINE -
8
0010FC 0851 0001 9 FPSUB BCHG.B #1,(A1)
10
11 * -- FETCH A 4 BYTE F.P. NUMBER TO FPACC#2 --
12
001100 2498 13 FPADD MOVE.L (A0)+,(A2)
14
15 * -- START OF FLOATING POINT ADD ROUTINE --
16
001102 1016 17 FPADD1 MOVE.B (A6),D0
001104 67 36 18 BEQ RETN1 DONE IF X2 = 0
001106 3213 19 MOVE.W (A3),D1
001108 B015 20 CMP.B (A5),D0
00110A 65 0C 21 BCS FP1GEFP2 OKAY IF X1 > X2
00110C 66 04 22 BNE SWAP SWAP IF X1 < X2
00110E B254 23 CMP.W (A4),D1
001110 64 06 24 BCC FP1GEFP2 OK IF MANT1>=MANT2
25
26 * -- SWAP FPACC#1, FPACC#2 --
27
001112 2212 28 SWAP MOVE.L (A2),D1
001114 2491 29 MOVE.L (A1),(A2)
001116 2281 30 MOVE.L D1,(A1)
31
32 * FPACC#1 IS >= FPACC#2; NOW ALIGN MANTISSAS
33
001118 1415 34 FP1GEFP2 MOVE.B (A5),D2
00111A 67 34 35 BEQ RZER DONE IF EXP1 IS 0
00111C 9416 36 SUB.B (A6),D2 D2 = X1-X2
00111E 67 06 37 BEQ SHIFT SKIP IF EXP'S EQ
001120 0C02 0010 38 CMPI.B #$10,D2
001124 64 14 39 BCC ADDX DONE IF DIFF>#15
40
41 * SHIFT 16 BIT MANT2 IN D0 RIGHT BY # IN D2
42
001126 3014 43 SHIFT MOVE.W (A4),D0
001128 E468 44 LSR.W D2,D0
45
46 * -- ADD OR SUBTRACT ? --
47
00112A 1411 48 MOVE.B (A1),D2
00112C B512 49 EOR.B D2,(A2)
00112E 6B 0E 50 BMI SUB SUBTRACT IF DIFF
51
52 * -- THE MANTISSAS ARE ALIGNED IN D1 AND D0;
53 * ADD THE TWO MANTISSAS --
54
001130 D340 55 ADDX.W D0,D1 D1= D0+D1
001132 64 06 56 BCC ADDX SKIP IF NO CY
57
58 * NORMALIZE THE MANT RIGHT AND INCREMENT EXP1
59
001134 E251 60 ROXR.W #1,D1
001136 5215 61 ADDQ.B #1,(A5)
001138 67 4E 62 BEQ OVFL REPORT OVERFLOW
00113A 3681 63 ADDX MOVE.W D1,(A3)
00113C 4E75 64 RETN1 RTS
65
66 * -- SUBTRACT THE MANTISSAS --
67
00113E 9340 68 SUB SUBX.W D0,D1 (M1= M1- M2)
001140 6B 0A 69 BMI SUBX (OK IF D15 = 1)
001142 67 0C 70 BEQ RZER ZERO IF GRD= 0
71
72 * - SHIFT ONE BIT AT A TIME UNTIL NORMALIZED -
73
001144 5315 74 NORM SUBQ.B #1,(A5)
001146 67 08 75 BEQ RZER
001148 E341 76 ASL.W #1,D1
00114A 6A F8 77 BPL NORM (LOOP UNTIL DONE)
78
79 * THE NORMALIZAT'N IS DONE; RESTORE MANT1
80
00114C 3681 81 SUBX MOVE.W D1,(A3)
00114E 4E75 82 RTS
83
84 * - THE RESULT IS ZERO; CLR S1, EXP1, MANT1 -
85
001150 4291 86 RZER CLR.L (A1) ZERO FPACC#1
001152 4E75 87 RTS
88
89 *************************************************
90 * FETCH A 4 BYTE F.P. # TO FPACC#2, MULTIPLY
91 * TIMES FPACC#2, LEAVE THE RESULT IN FPACC#1
92 *************************************************
93
001154 2498 94 FPMUL MOVE.L (A0)+,(A2)
95
96 *************************************************
97 * CALCULATE THE EXPONENT OF THE RESULT
98 *************************************************
99
001156 4240 100 FPMUL1 CLR.W D0
001158 4241 101 CLR.W D1
00115A 1015 102 MOVE.B (A5),D0
00115C 67 F2 103 BEQ RZER ZERO IF EXP1= 0
00115E 1216 104 MOVE.B (A6),D1
001160 67 EE 105 BEQ RZER ZERO IF EXP2= 0
001162 D240 106 ADD.W D0,D1 ADD EXPONENTS
107
108 *************************************************
109 * CALCULATE AND STORE THE SIGN OF THE RESULT
110 *************************************************
111
001164 1012 112 MOVE.B (A2),D0
001166 B111 113 EOR.B D0,(A1)
114
115 *************************************************
116 * NOW MULTIPLY THE MANTISSAS
117 *************************************************
118
001168 3013 119 MOVE.W (A3),D0
00116A C0D4 120 MULU (A4),D0
00116C 6B 04 121 BMI MULX SKIP IF D31 = 1
122
123 *************************************************
124 * NORMALIZE BY SHIFTING LEFT ONE BIT, X1= X1-1
125 *************************************************
126
00116E E388 127 LSL.L #1,D0
001170 5341 128 SUBQ.W #1,D1
001172 927C 0080 129 MULX SUB.W #$80,D1
001176 67 D8 130 BEQ RZER
001178 6B D6 131 BMI RZER
00117A 0C41 0100 132 CMPI.W #$0100,D1
00117E 64 08 133 BCC OVFL
001180 1A81 134 MOVE.B D1,(A5)
001182 4840 135 SWAP D0
001184 3680 136 MOVE.W D0,(A3)
001186 4E75 137 RTS
138
001188 74 01 139 OVFL MOVEQ #1,D2 1= OVERFLOW
00118A 66 02 140 BNE ERR2A
00118C 74 02 141 DIVBY0 MOVEQ #2,D2 2= DIV BY ZERO
00118E 4EF8 0122 142 ERR2A JMP IDLE ( RETURN TO BOOTSTRAP )
143
144 *************************************************
145 * FETCH A 4 BYTE F.P. NUMBER TO FPACC#2
146 * FPACC#1, THEN DIVIDE FPACC#1 INTO FPACC#2.
147 * THE RESULT IS STORED IN FPACC#1
148 *************************************************
149
001192 2498 150 FPDIV MOVE.L (A0)+,(A2)
151
152 *************************************************
153 * FETCH EXPONENTS TO DATA REGS D0 AND D1
154 *************************************************
155
001194 4240 156 FPDIV1 CLR.W D0
001196 4241 157 CLR.W D1
001198 1215 158 MOVE.B (A5),D1
00119A 67 F0 159 BEQ DIVBY0 CAN'T DIV BY 0
00119C 1016 160 MOVE.B (A6),D0
00119E 67 B0 161 BEQ RZER ZERO IF EXP2= 0
162
163 *************************************************
164 * CALCULATE THE EXPONENT OF THE RESULT
165 *************************************************
166
0011A0 9041 167 FPDIV2 SUB.W D1,D0 16 BIT SUBTR
0011A2 D07C 0080 168 ADD.W #$80,D0 (CORRECT EXP)
169 * (DO NOT TEST OF OV/UNFL NOW)
170
171 *************************************************
172 * CALCULATE AND STORE THE SIGN OF THE RESULT
173 *************************************************
174
0011A6 1212 175 MOVE.B (A2),D1
0011A8 B311 176 EOR.B D1,(A1)
177
178 *************************************************
179 * DIVIDE MANT2 BY MANT1
180 *************************************************
181
182 * -- MANT2 TO D1, B31 - B16 --
183
0011AA 2214 184 MOVE.L (A4),D1
185
186 * -- CLEAR B16-B0 --
187
0011AC 4241 188 CLR.W D1
189
190 * -- DIVIDE MANT2 BY MANT1 --
191
0011AE 82D3 192 DIVU (A3),D1
193
194 * -- SKIP IF DIVIDE IS O.K. --
195
0011B0 68 10 196 BVC DIVX
197
198 * -- DIVIDE NOT O.K., ADD #1 TO EXP --
199
0011B2 5240 200 ADDQ.W #1,D0
201
202 * -- SUBTRACT MANT1 FROM MANT2 --
203
0011B4 4841 204 SWAP D1
0011B6 9253 205 SUB.W (A3),D1
0011B8 4841 206 SWAP D1
207
208 * -- DIVIDE AGAIN; THIS TIME NO OVERFLOW --
209
0011BA 82D3 210 DIVU (A3),D1
211
212 * -- NORMALIZE RESULT; SET B15 = 1 --
213
0011BC 74 01 214 MOVEQ #1,D2
0011BE E24A 215 LSR.W #1,D2
0011C0 E251 216 ROXR.W #1,D1
217
218 * - TEST EXPONENT FOR UNDERFLOW OR OVERFLOW -
219
0011C2 3400 220 DIVX MOVE.W D0,D2
0011C4 6B 8A 221 BMI RZER ZERO OR UNDERFLOW
0011C6 0242 FF00 222 ANDI.W #$FF00,D2
0011CA 66 BC 223 BNE OVFL
224
225 * -- RETURN EXP1 AND MANT1 TO FPACC#1 --
226
0011CC 1A80 227 MOVE.B D0,(A5)
0011CE 3681 228 MOVE.W D1,(A3)
0011D0 4E75 229 RTS
230
# 00000122 231 IDLE EQU $000122
