Issue #1 DTACK GROUNDED Newsletter - July 1981
Copyright 1981 Digital Acoustics, Inc.

=============================     ABOUT OUR LOGO: (you should 
***   *****   *    ***  *   *     immediately skip to the 4th 
*  *    *    * *  *   * *  *      paragraph if you are not a hardware 
*   *   *   *   * *     * *       hacker).  If you do not recognize 
*   *   *   *   * *     **        the meaning of our logo, you 
*   *   *   ***** *     * *       obviously have not reviewed 
*  *    *   *   * *   * *  *      Motorola's application notes for 
***     *   *   *  ***  *   *     their 68000.  The 68000 features an 
=============================     asynchronous data bus, like many of 
      ================= 10        the more complex minicomputers.  
      =================           Assuming that you are approaching 
=============================     the 68000 by way of an 8 bit 
     ===================          microprocessor such as a 6502, 6800, 
          =========               or 8080 this will be strange to you 
                                  because these all have synchronous 
data buses.  The 68000, when writing data, places the data on the bus 
and waits for an acknowledgement that the data has been received.  
This is accomplished by placing a low logic level on pin 10, DTACK 
(DaTa ACKnowledged).  A read is performed by requesting data from a 
device and waiting until a low logic level is placed on pin 10 which 
acknowledges that the data is now available on the bus.

Because the acknowledgements from all of the various devices connected 
to the bus must converge on pin 10, a very large percentage of the 
available application information on the 68000 published by Motorola 
covers the circuitry to generate DTACK.  Motorola has thoughtfully 
provided another pin labelled BERR (Bus ERRor).  When DTACK is not 
succesfully generated, you are supposed to provide a watchdog timer 
which will assert BERR logic low.  The 68000 will then trap to the 
location in memory pointed to by the BERR vector.  At this location, 
you have to write software to decide what to do about the failure to 
generate DTACK.

Motorola is not worried about the complexity of this process because 
they are, for reasons known only to Motorola management, promoting the 
68000 exclusively as the "engine" for very complex systems.  
Accordingly, there are a lot of companies who are planning to drive 
the PDP 11/70 out of the marketplace with $10,000 (base price) 68000 
systems.  It is rumored that Apple is one of these companies, and HP 
has already announced their system, which naturally comes with a 50 
(fifty) column CRT.

If you are interested in paying $10,000 for an admittedly high 
performance, complex system based on the 68000, this would be a very 
good time to stop reading this newsletter.  There will be absolutely 
nothing here to interest you.  If you already own, or are thinking of 
buying, an Apple II or a Pet/CBM system, and you would like to 
inexpensively increase its computational throughput by a factor of 10 
to 20, read on.

Again, about the logo: it is possible to build very simple systems 
using the 68000 if you ground DTACK.  Naturally, you can then tie BERR 
to +5, since the data is always acknowledged.  Now you have a 
SYNCHRONOUS data bus, and you can throw out about 93% of Motorola's 
application information on the 68000.  Take another look at our logo: 
get it?

Page 2

Our prototype 68000 board has a minimum configuration of 17 ICs, many 
of which are actually used to interface the CBM 8032 which is the host 
processor for the board.  However, most of the readers of this 
newsletter will be more interested in the use, rather than design of, 
a 68000 system.  Those readers should be advised that they can attach 
a 68000 board to their Apple II or Pet/CBM system for about $600, or 
even a low less if they can solder and test their own board.


Now is the time to reveal who "we" is, folks.  DTACK GROUNDED is the 
ficticous name chosen by Digital Acoustics, Inc.  as a trade name for 
our line of 68000-related software and hardware.  Digital Acoustics 
has been in business since 1973 and shipped its first microprocessor 
based product early in 1974.  We have in the past built instruments 
which used the Intel 4004 and 4040.  We currently build unattended 
environmental noise monitors using the 6502 processor.  DTACK GROUNDED 
grew out of a research project to determine the feasibility of using a 
68000 based processor in the next version, or v.04 as we call it, of 
our DA607P environmental noise monitor.

Before you fall down laughing about the use of a 68000 in a glorified 
sound level meter, you should be advised that our DA607P v.03 carries 
a price tag of $7995 and that it has a built in thermal printer with 
HIRES graphics.  It was released in July, 1980 and uses a 6502 
processor with a real time clock that WORKS.  By way of contrast, the 
Apple III was released sometime around Dec, 1980 with a real time 
clock that did NOT work (the Apple III is manufactured by the Apple 
Computer Company, which you may have heard of).

The latest model environmental noise monitor made by our major 
competitor (name on request) uses an Intel 4040 processor!  For some 
reason, our sales have been much higher lately than those of our major 
competitor.


The problem, fellows, is that the the 6502 is about to go the way of 
the 4004/4040.  Very soon, like early next year, your neighbor's kid 
is going to come home with a Trash 80 IV based on an Intel 8086, and 
he is going to LAUGH at your 6502 based system the same way we at 
Digital Acoustics laugh at our competitor's 4040 based instrument.  
What really hurts is that he will be laughing with justification.  The 
8086 actually CAN run circles around a 6502 based system.

Now, a short eulogy: the 6502 has been very good to a lot of people, 
and for a lot of companies.  Most of you are aware that it was by far 
the best performing microprocessor of its generation.  Its generation 
has now passed (you know about this, of course, otherwise you would 
not be reading this newsletter).  REQUIESCAT IN PACE.

We know deep down inside that our 6502 systems are beginning to sprout 
turkey feathers.  The problem is not whether to stay with the 6502.  
The problem is to select the correct microprocessor to use next.  
Several companies and at least one 6502 based publication have decided 
that the 6809 is the logical successor to the 6502.  Obviously, we 
disagree.

Page 3

Let's talk about market windows.  The Intel 4004/4040 was the most 
advanced microprocessor of its day (it was the ONLY microprocessor of 
its day!).  The market window for the 4004 opened in 1972, and slammed 
shut when Mos Technology introduced the 6502 for $25, quantity one, in 
the summer of 1975.  The problem with the 6809 is that it very nearly 
missed its market window.  I have seen one announcement of the 6809 
dated Feb.  1977.  Had the 6809 reached the marketplace in 1978 it 
would have been enormously successful.  Today, the market window is 
closing for the 6809.  The window will slam shut on the day that the 
price of the 68000 drops below $XX.  (The exact value of XX depends on 
familiarity and acceptance of the 68000 in the marketplace.  We intend 
to assist in this regard.)

The market window of the 68000 is just opening.  Because the 
architecture and microcode are both extensible, the 68000 will 
probably be a viable performer for a long time (nothing lasts 
forever).  Imagine, if you will, microcoded string and floating point 
instructions, a 32 bit data bus, writeable microcode...  All of these 
things are in the future of the 68000.

Why is the market window closing on the 6809?  Because it is SLOW, 
that's why!  If you want to add two 32 bit numbers, you have to do the 
usual LDA, ADC, STA four times in 6502 style (the 16 bit add in the 
6809 is not an add with carry).  And, since the 6809 is not pipelined, 
this will take 1/3 LONGER than the 6502 to do the job.  Please 
understand that I am NOT claiming that the 6809 is not, overall, 
superior to the 6502.  What I AM saying is that it is terribly slow 
considering that it came along 5 years later.


Now, consider the 68000: suppose you want to add those same two 32 bit 
numbers.  Let the first 32 bit number be in D0 (data register 0) (you 
DID know the 68000 has 32 bit registers, didn't you?) and the second 
in D1.  Let the result be returned to D0.  Here is the code for this:

D0 81           ADD .L D1, D0

This is a one word (two byte) instruction which takes .75 microseconds 
(8MHz).  The 6809 requires 24 bytes and 48 microseconds to do the same 
job.  THAT'S 64 TIMES SLOWER!  You want to add two 64 bit numbers?

D0 82           ADD .L D2, D0
D3 83           ADDX .L D3, D1

Two words, 1.75 microseconds.  You still want to use the 6809?  We 
have one word for you: Goodbye!


We hereby officially declare the formation of the "Simple 68000 
Systems Chowder and Marching Society".  This society has no dues, 
rules or bylaws.  Its charter is obvious.  Only those who are 
interested may join.  We at DTACK GROUNDED (Digital Acoustics, Inc.) 
will do everything we can to reduce the admission fee.

Page 4

For 6502/68000 systems to become a reality, we need hardware, 
software, and an information channel.  None of these three 
prerequisites can exist independently.  Perhaps the most important is 
the knowledge that it is possible to build simple, inexpensive systems 
using the 68000, which we herewith present.  We now pause for a 
message from our sponsor (you KNEW there was a commercial coming, 
didn't you?).


DTACK GROUNDED is going to sell boards, assembled at various levels, 
which will attach the 68000 plus its own resident memory to the Apple 
II or Pet/CBM as a peripheral device.  We call this an "attached 
processor".  Because we are a small company, we can afford to sell 
these boards at a small profit.  Because we are greedy, we want to 
sell lots of boards.  To sell lots of boards, we have to GIVE AWAY 
lots of software, beginning with a monitor, cross assembler and a 
floating point package compatible with Apple II and Pet/CBM Basic.  We 
also have to publish a newsletter (you are reading this, no?), priced 
below cost if the time required to write it is counted.

As I write this, there are about 300,000 systems out there using the 
6502 and Microsoft Basic.  Nearly all are Apples or Pets.  Nearly all 
have 40 column CRTs.  Perhaps half have disk(s) and a printer 
attached.  Now, a LOT of these systems are used by dentists to mail 
monthly statements or by high school students to play games.  None of 
these people will be interested in a 68000 attached processor on the 
first or second round.


First or second round?  On the FIRST round, only the hard core 
hobbyist, probably a hardware hacking type, will be interested.  This 
person follows the electronics industry journals, and is well aware of 
the advantages of the 68000.  There are about 1000 of these guys, and 
993 of them own Apples (this writer is one of those 1,000 and owns a 
CBM 8032/8050 system: 80X25 CRT, over 1 Megabyte on line.).  These 
guys will buy to be the first on the block, and also because it is 
otherwise difficult to get a 68000 development system for about $600.  
The easiest way to distinguish a working engineer in industry from a 
hardware/software hacking hobbyist is by the clock.  If it's after 5 
PM, he's a hobbyist.

At the START of the first round, we have a monitor, floating point 
package, a logarithm routine with hooks to Basic that runs 14 times 
faster (at 8 MHz) and a VERY crude cross assembler, all available now 
and included FREE with our boards.  At the END of the first round, we 
will have all of the standard transcendental functions (SIN, ATN, 
etc.) with hooks to Basic, and published hooks for the 
compiler/Pascal/C software types so they can come on board when ready 
(they will not come on board on the first round, because 1000 users is 
not a viable user base).  A cross assembler which is merely crude will 
be available.  All of this software will come free with the board, or 
priced to cover printing and mailing costs to registered board owners.


(This marketing practice is called "bundling", and has been ruled to 
be illegal IF the company is in a dominant position in its industry.)

Page 5

By the end of the first round, we should begin to see some software 
surfacing from the user group.  Some of this will be commercial, but 
early on it will probably be "hey, look what I made my 68000 do, and 
look how fast is runs" stuff.  We would very much like to publish such 
software in the DTACK GROUNDED newsletter, with appropriate 
attribution.  This would, of course, turn the newsletter into a 
journal.  We understand that there is a very fine flight simulator 
program with 3 dimensional graphics that runs on the Apple.  What if 
it were possible to increase the frame update rate by a factor of 10 
to 20?

Incidentally, we love games.  Games are as American as apple pie.  
Games are very useful to demonstrate computers to the great unwashed.  
But please submit 68000 code for tic-tac-toe games elsewhere.  We 
think DTACK GROUNDED readers will be mostly interested in more serious 
stuff.


Now, the SECOND round: Some software hackers are going to come on 
board because they have seen one of the first round buyers' units run 
FAST.  Some non-hackers (species "user vulgaris") will come on board 
because of a friend's recommendation and because the price of 
admission is declining (the 68000 price will be dropping as more 
second sources come on line and as product yield improves).  Some 
small company industrial types are going to come on board because this 
is the cheapest way to get a 68000 development system, and because we 
intend to license our floating point packages at very reasonable one 
time fees.  The cross-assembler will continue to improve, but is 
unlikely to result in invidious comparisons to Carl Moser's 6502 
assembler.

A 61 (yes, sixty one!) bit floating point package, 14 decimal digits 
precision, will be made available complete with transcendentals and a 
calculator package which emulates the old Wang 600 calculator (this 
package exists NOW in 6502 code, but without most of the 
transcendentals).  It will NOT be IEEE compatible for reasons to be 
given in a future issue of this newsletter.

An 80 bit floating point package will be written, with 
transcendentals, so that an error analysis of the 61 bit and the 
Microsoft Basic compatible packages can be accomplished (the integer 
portion of the divide and multiply routines of the 80 bit package 
already exist and have been used to check the existing 9 digit 
Microsoft compatible package).


Since the 80 bit package will have 18 decimal digit precision it will 
make a very effective, reliable 16 decimal digit package, which is 
what the business people really need.  This package will be licensed 
at VERY reasonable rates for the business programming people.  The 
four basic functions (add, subtract, multiply, divide) will run about 
five or six times faster than the 6502 is now running with its 9 
decimal digit package, which is not really adequate for business use. 
 The transcendentals will run about three times faster than the 
existing 9 digit 6502 package, and should prove very useful to those 
scientific types, such as astronomers, who need high precision 
arithmetic.

Page 6

During the first part of the second round, we will provide software 
hooks to intercept the "find variable" subroutine which looks up the 
location of the floating point variables for transfer to one of the 
two floating point accumulators.  The numeric variables will then be 
located in the 68000 memory space, not the 6502 memory.  This will 
greatly speed up the basic interpreter by eliminating the constant 
data transfer between the two processors and by allowing the 68000 to 
locate the variables, which it can do somewhat faster (ahem!) than the 
6502.

Toward the end of the second round, we will provide hooks to transfer 
the "expression evaluation" subroutine from the 6502 to the 68000.  
The 6502 will now have little to do except perform string functions 
and monitor the keyboard (the 6502 is very good at monitoring 
keyboards).  In other words, the 6502 portion of your system will be 
approaching the status of an I/O processor.

During the second round, some commercial software will begin to 
appear.  I expect the first quality commercial software will take 
advantage of the 68000's extremely fast integer arithmetic to greatly 
speed up Apple II graphics.

Once the 80 bit floating point package is introduced, some general 
ledger business systems programmers will begin to use the 68000 board, 
either with the CBM 8032 or with an Apple with an 80 column CRT 
adapter board.  In either case, a reasonable sized disk will be 
required.  This means that the cost of the 68000 board will be (and IS 
NOW) a very small part of the total cost of the system.  General 
ledger programmers who do NOT use the 68000 board will find themselves 
at a competitive disadvantage.

This takes us up to the beginning of the third round, which starts 
when someone, probably a British software house specializing in the 
8032/8096 business computer, will introduce a compiled Basic which 
makes effective use of the power of the 68000.  The next issue of this 
newletter will explain why the marriage of compiled Basic and the 
68000 is one that is made in heaven and why you should be miserable 
because you do not have this combination available to you RIGHT NOW.

           **********************************************

Above is an optimistic scenario which can come true.  An essential 
part is the continuation of this newsletter and your contributions to 
it, which will turn it into a journal as noted.

Another part is that we at DTACK GROUNDED have to sell enough boards 
to make it profitable to give away software, or find other related 
ways to make a profit.  One way to do this is to offer the software 
separately at a low, but profitable in large quantity, price.

But, as we said previously, our main purpose is to make a little money 
on each board we sell.

Page 7

How can we compete with 17 copycats who do not have our overhead 
because they are not busy writing software to support this program?  
Very simply.  Our software will always be distributed with large, 
easily readable copyright notices.  It happens that the copyright law 
in this country is clear and unambiguous.  For this reason, copyright 
lawsuits tend to be open and closed affairs (the recently famous Data 
Cash lawsuit involved ROMs which were NOT marked with a copyright 
notice).

Does this mean that we will actually sue a computer club which copies 
and distributes our software to its members?  Not unless done so for 
purely commercial reasons.  The people we would be inclined to sue 
would be our competitors (people or companies which sell copycat 
boards, which is legal and aboveboard, but distribute our software 
with them, which is strictly illegal).

Actually, there is some stuff, particularly 68000 source code, which 
we don't even want the clubs to copy.  That's why the last part of 
this newsletter is printed in black ink on dark red paper.  Look, 
fellows, if we published our $10 floating point source code package in 
black ink on white paper there would be a 31st generation photocopy in 
Kabul, Afghanistan by Sunday afternoon!



HARDWARE STATUS REPORT:

The prototype 68000 board is operational, and has been since about 
June 1.  A qualified consultant has been retained to design an 
interface board for the Apple II (Burtronix did the Microsoft Softcard 
board design, for instance).  The design was turned over to us on July 
9, and the printed circuit artwork for this interface board was 
completed, except for the DTACK GROUNDED logo, on 14 July.  Today's 
date is 15 July, and this part of this newsletter will be revised in 
future days to keep you up to date.


The layout of the 68000 board, with sockets for 68k bytes 200 nsec 
static ram and a memory expansion connector will begin next week, July 
20.  After prototype testing (with assistance from our Apple 
consultant), an initial order of 250 circuit boards, with solder mask 
and component layout silk screen, will be placed.  The 68000 board 
artwork will then be modified to the CBM 8032 interface configuration, 
which includes a private 2K ram for the 8032 mapped into the second 
half of the CRT memory space.  A 64K memory expansion board will be 
available sometime in October.


The 8032 version mounts INSIDE the 8032 and is therefore shielded.  
The Apple II version obviously has the main board mounted OUTSIDE.  
However, we understand that the first 200,000 Apple IIs sold can't be 
used anywhere near a TV set anyway.  Nevertheless, how to shield the 
68000 board when used with the Apple will have to be looked into.

Page 8

SOFTWARE STATUS REPORT:


If you send us $10 plus 50 cents postage (U.S.  only) NOW, you will 
get twenty-plus pages of 68000 floating point (the Microsoft Basic 
compatible 9 decimal digit version) source code by return (1st class) 
mail (Calif.  residents add 6%).  At this price, the package is 
obviously offered with no support and no license for its reproduction 
in any form is offered or implied.  However, the package has been 
carefully tested and there are no known bugs.  Should a bug be located 
after the fact, a correction will be printed in a future issue of 
DTACK GROUNDED.

Not incidentally, purchasers of the floating point package will be 
interested to know that the innards of this package will be examined 
in detail in this and future issues in the second, secret (i.e., 
difficult to photocopy) section of DTACK GROUNDED as the tutorial on 
68000 software.  This benefits the software buyer by explaining how 
the 68000 code works, in case you are not familiar with 68000 code.  
The DTACK GROUNDED subscriber benefits even when not interested in the 
FP package, since the tutorials are thus guaranteed to cover tested, 
functional, useful code.  Or haven't you ever seen "code" published in 
magazines and textbooks which had obviously never been run, and 
obviously never could run?


If you would like to subscribe to this newsletter, send $15 for six 
issues to:


DTACK GROUNDED
1415 E. McFADDEN St. F
SANTA ANA   CA   92705


Apple, Apple II, Apple III are trademarks of the Apple Computer 
Company.  Pet and CBM are trademarks of Commodore Business Machines, 
Inc.  DTACK GROUNDED is a trademark of Digital Acoustics, Inc.  As far 
as we know, Trash 80 IV is not, either in part or in whole, anybody's 
trademark.


If you received this newsletter as a free sample, this is the end (if 
you received it in reply to our magazine S.A.S.E information offers, 
this is printed half size to reduce postage costs).  For subscribers, 
the next six RED pages are a tutorial on using the 16 bit unsigned 
multiply to generate a 40X32 bit multiply with 40 bit result, which is 
what is needed to be compatible with the Microsoft floating point 
multiply (but 31 times faster).

The next issue of DTACK GROUNDED will have complete pricing and 
ordering information on the hardware.

If you are still with us this far, and plan to stay with us, it is 
absolutely essential that you get a Motorola 68000 specification sheet 
and a User's Manual, Motorola part # MC68000UM(AD2).

Page 9

WELCOME TO REDLANDS, CASH CUSTOMERS!


in re FLOATING POINT:

Some definitions of terms and other clarifications are in order.  
First: if you do not already know the difference between floating 
point and integer representation of numeric values, then it is highly 
unlikely that you will catch on to most of what is happening in the 
68000 code.  What you should do is get a good book in the subject, and 
come back to this material when you DO understand the difference.

I can't think of a book which is clear, concise, inexpensive and 
readily available on this subject.  BYTE publishes a book which is a 
collection of articles previously printed in BYTE magazine on the 
representation of numbers in computers, titled "NUMBERS IN THEORY AND 
PRACTICE".  This book is presumably at least available.  If any reader 
can recommend a better book on this subject, please drop a line to the 
editor of DTACK GROUNDED.

A short review: the four fundamental floating point operations are 
add, subtract, multiply, divide.  These are dyadic operations, meaning 
we need TWO operands to obtain a result.  Add and multiply are 
commutative, meaning A+B = B+A and A*B = B*A.  However, subtract and 
divide are not commutative; we have to make a decision who does what 
to whom.  In a Microsoft compatible package, the decision is made for 
us.  Let FPACC#1 be the floating point accumulator, where the result 
of an F.P.  operation is left.  FPACC#1 has a guard byte, remember.  
We subtract FPACC#1 from FPACC#2 (by changing the sign of FPACC#1, 
then proceeding to perform a signed addition).  When dividing, 
Microsoft first rounds FPACC#1, eliminating the guard byte.  They then 
divide FPACC#1 into FPACC#2.

A floating point accumulator has a sign (positive or negative), an 
exponent and a mantissa.  FPACC#1 also has a guard byte (in Microsoft 
Basic).  We call the sign bit in FPACC#1 S1, the exponent X1, the 
mantissa M1 and the guard byte G1.  The corresponding descriptors for 
FPACC#2 are S2, X2, M2 and G2.  G2 is (initially) by definition zero, 
but is needed to perform addition or subtraction with G1.

If you are not familiar with assembly language, you will have a lot of 
trouble (at first) with the material to follow, but do NOT rush out 
and buy a book, at least for now.  Assembly language programming, like 
riding a bycicle or participating in a certain popular indoor sport, 
is best learned by doing.  After you are a competent assembly language 
programmer, a book on the subject may provide interesting historical 
information on the subject as well as the correct names and 
descriptors for what you have already been doing.

SOME CONVENTIONS:

When discussing the 6502, the data lines are named D7 thru D0 and the 
address lines are named A15 thru A0.  Motorola has chosen to name the 
data registers in the 68000 D7 thru D0, and the address registers A7 
thru A0.  Therefore, we will use b15 thru b0 to describe the data 
lines, and b31 thru b0 to describe the individual bits in a register.  
When is becomes necessary to discuss address lines, we will for the 
time being use the name "address line(s)" to describe the address 
line(s).  This is not very original and certainly not very compact, so 
we are open to suggestions on this matter.

Page 10

We assume that you have previous experience with assembly language on 
an eight bit microprocessor, probably the 6502.  Be advised that the 
single most important assembly mnemonic for the 68000 is MOVE.  This 
single mnemonic replaces LDn, STn and Tnn.  In other words, MOVE is 
used for loads, stores and transfers.

Whether one or three descriptors are used for these three operations 
is arbitrary, but don't get the idea that the subject is not 
considered important.  There was an intense battle at the very top 
echelon of Intel over MOVE vs LD, ST, TFR a few years ago.  The loser 
founded ZILOG.  Have you ever compared 8080 and Z80 source code?

MOTOROLA 68000 ARCHITECTURE:

Now for a VERY short introduction to the 68000 architecture: it has 
eight general purpose data registers, each of which has 32 bits.  It 
has eight 32 bit address registers, one of which (A7) is dedicated as 
the stack pointer.  That's 64 bytes of on board registers.  This 
compares to 4 bytes for the 6502: the accumulator, X, Y and stack 
pointer.  We have recently been writing code using this wealth of 
on-board storage, and let us tell you it's FUN!

NOW LET'S GET ON WITH IT

Take a peek at pages 13 and 14.  That's the actual code used to 
perform the integer multiply in our Microsoft compatible nine digit 
floating point package.  M1 is a four byte memory location containing 
the mantissa of FPACC#1.  G1 is the next byte in memory, and is the 
guard byte used my Microsoft in their floating point package to 
improve the accuracy.  We reserve the next byte as a "garbage" byte 
since the 68000 can't perform byte multiplies.  M2 is the location of 
the four byte mantissa of FPACC#2.  M2 has no guard byte.

Following is a description of what is happening in the Motorola 68000 
source code on pages 13 and 14: first we MOVE the guard byte and the 
garbage byte as a word to the lower 16 bits of data register 0, or D0.  
The ".W" following MOVE specifies a word (16 bit) operation.  Then we 
clear the lower byte of D0 by using the CLR (clear) instruction, with 
the ".B" specifying an 8 bit operation.  The guard byte is left in b15 
thru b8 of D0.

Now we MOVE D0 to D3.  Note that the size of the move is unspecified.  
The assembler defaults to ".W" in the absence of a size specifier.  
Now, we wanted a 16 bit MOVE operation to have a copy of the guard 
byte in D3.  However, this is very poor style, especially for a 
beginner (which we are!).

The next two instructions MOVE the lower order (but higher in memory) 
16 bits of M1 into D1, with a copy in D4.  The next two instructions 
MOVE the high order 16 bits of M1 into D2, with copy in D5.

We now have two copies of the 40 bit M1+G1 of FPACC#1 inside the 
68000, the first copy in D2, D1, D0 and the second copy in D5, D4, D3.  
We have no idea what is in the upper 16 bits of these six data 
registers, but that's O.K.  because the 16 bit multiply instruction 
ignores the upper half of the registers.

Page 11

Now we move the lower order half of M2 into D7 (get ready, everybody, 
on the next instruction we are, finally, going to perform an actual 
HARDWARE MULTIPLY!).  Now we execute "MULU D7, D0", which requires 
8.75 microseconds at 8 MHz.  This instruction replaces the contents of 
D0 with the 32 bit result of the 16 by 16 bit multiplication.  Aren't 
32 bit registers handy?  D7 is unchanged, so we continue, multiplying 
times D1 and then D2.

Now that we have all the partial products involving the lower order 
portion of m2, we MOVE the high order half of M2 to D7 and multiply it 
times D3, D4 and D5.  We now have all of the partial products (six of 
them) inside the 68000.  At the bottom of page three is a diagram of 
the contents of D0 thru D5, followed by a symbolic representation of 
the desired result.

After adding the partial products, that portion of the result below GG 
will be discarded, since we want only the most significant 40 bits of 
the result.  However, we must first determine whether the addition of 
D0 thru D4 will generate carries into the portion of the result we 
want to keep.  Therefore, we can only throw away the lower order bits 
when it is impossible for them to be added to another low order 
result, possibly generating a carry.

Looking at D0, we see that we can immediately discard the lower half 
of the register.  We also have the problem that we want to add the 
UPPER half of D0 to the LOWER half of D1.  Continuing with the code on 
page 4, we CLR (clear) the lower 16 bits of D0 by specifying ".W" for 
a 16 bit operation.  Then we SWAP the upper and lower 16 bits of D0.  
The upper 16 bits of D0 are now all zero, and the former high order 
bits of D0 are now in the low order position...  which is exactly 
where we need them for an add into D1.

Now we perform a 32 bit ADD, adding D0 to D1 with the result left in 
D1 (isn't it nice to have 32 bit instructions?).  Unlike the 6502, it 
is not necessary to clear the carry first.  However, the carry bit 
will, if appropriate, be set as a result of this add.  The next 
instruction (BCC MUL1) tests the CY and skips of the carry is zero.  
If the carry is set, we do not skip and instead add one to D5 (a quick 
look at the diagram on the bottom of page 3 will show that a carry 
propogating out of D1 should proceed to D5 in bit position 0).  ADDQ 
means "add quick", which can be done using data from #1 to #8 in a one 
word instruction, which is why it is called "quick".

D1 and D3 are aligned already, so we add them, leaving the result in 
D3.  Once again, we test for a carry and add one to D5 if CY = 1.  Now 
the lower half of D3 is useless, and we have to align the UPPER half 
of D3 with the LOWER half of D2.  So: CLR .W D3, then SWAP D3.  We can 
now add D3 to D2, and so we do!  But look at the diagram again: any 
carry generated must be added into bit position 16 of D5.  Now we 
can't use ADDQ to correct D5, so we add the 32 bit immediate data 
$00010000 to D5 if a carry is generated adding D3 to D2, and again on 
adding D2 to D4.

Let us carefully consider the contents of D4 at the location labelled 
"MUL4": The upper half of D4 must be added to the lower half of D5.  
But before we clear the lower half of D4, remember that it now 
contains our guard byte in bit locations 15 thru 8.  So, first we 
store our guard byte in D0.  Now we do the familiar CLR .W, SWAP, ADD 
.L.  However, we do not have to test for a carry because no carry is 
possible on this add.

Page 12

We now have the most significant 32 bits of the result in D5 and the 
next lower 16 bits in the lower half of D0.  In a floating point 
multiply (Microsoft compatible version) the most significant bit of M1 
and of M2 are both ones.  The highest possible value of M1, G1 is 
$FFFFF and the lowest is $8000.  The highest and lowest values of M2 
are $FFFF and $8000.  The highest possible result is then $FFFEF0001 
and the lowest is $400000000 (because we actually perform a 48, not 
40, bit multiply times 32 bits we actually have another hex zero 
appended to those results).

The lowest possible result is not in normalized mantissa form with bit 
31 = 1, in which case the mantissa must be normalized.  However, this 
is not part of the integer multiply, which is completed as of the next 
to last instruction on page 14.

We hope this short introduction to Motorola 68000 programming has been 
informative, and has whetted your desire to get your hot, sweaty hands 
on that beautiful 64 pin ceramic device!  Although it took a while to 
describe how the integer multiply worked, you may be interested to 
know that the 68000 executes that code in about 76.5 microseconds (8 
MHz), which is about 31 times faster than the 6502!


MISCELLANEAE in re ADDRESSING:

About address line 0: the 68000 doesn't have one.  Since the data bus 
is 16 bits wide, running address line zero, which differentiates 
between bytes, to word locations doesn't make sense.  The 68000 
instead has two data strobes, one for b15 thru b8 called UDS and one 
for b7 thru b0 called LDS.  This stands for Upper Data Strobe and 
Lower Data Strobe, respectively.  If a data byte is being written from 
a data register to memory at an odd location, the lowest 8 bits of D0 
are placed on b7 thru b0 of the data bus and LDS is asserted.  When 
writing to an even memory location, the same lowest 8 bits of D0 are 
placed on b15 thru b8 and UDS is asserted.  When performing a word or 
long word operation, the address can definitely and positively NOT be 
odd.  More on this next issue.

Although the address registers are actually 32 bit registers, the 8 
highest order bits are not brought out on the 68000 package.  As a 
result, the 68000 is restricted to a mere 16 megabyte addressing 
range, all of which can be accessed without bank switching, 
segmentation or other fun techniques.  Following is the code needed to 
transfer one million bytes (decimal) from one location in 68000 memory 
to another:

               MOVE .L #1000000, D0
               MOVE .L #LOC1, A0
               MOVE .L #LOC2, A1
         XFR   MOVE .L (A0)+, (A1)+
               SUBQ .L #1, D0
               BNE XFR

Try THAT on your friendly 8086, Z8000 or bank switched 6809!


And now, as the sun sinks slowly in the west, we bid you a fond adieu 
until the next issue of DTACK GROUNDED.

Page 13

  55                                ********************************************
  56                                 THE FOLLOWING CODE MULTIPLIES 32 * 40 BITS
  57                                ********************************************
  58
  59 414A       *DATA*           30 38       59    MOVE .W G1, D0
  60 414C       *DATA*    G1     70 2E       60
  61
  62 414E       *DATA*           42 00       62    CLR .B D0
  63
  64 4150       *DATA*           36 00       64    MOVE D0, D3
  65
  66 4152       *DATA*           32 38       66    MOVE .W M1+2, D1
  67 4154       *DATA*    M1+2   70 2C       67
  68
  69 4156       *DATA*           38 01       69    MOVE .W D1, D4
  70
  71 4158       *DATA*           34 38       71    MOVE .W M1, D2
  72 415A       *DATA*    M1     70 2A       72
  73
  74 415C       *DATA*           3A 02       74    MOVE .W D2, D5
  75
  76 415E       *DATA*           3E 38       76    MOVE .W M2+2, D7
  77 4160       *DATA*    M2+2   70 34       77
  78
  79 4162       *DATA*           C0 C7       79    MULU D7, D0
  80
  81 4164       *DATA*           C2 C7       81    MULU D7, D1
  82
  83 4166       *DATA*           C4 C7       83    MULU D7, D2
  84
  85 4168       *DATA*           3E 38       85    MOVE .W M2, D7
  86 416A       *DATA*    M2     70 32       86
  87
  88 416C       *DATA*           C6 C7       88    MULU D7, D3
  89
  90 416E       *DATA*           C8 C7       90    MULU D7, D4
  91
  92 4170       *DATA*           CA C7       92    MULU D7, D5
  93
  94                                ********************************************
  95                                *        MULTIPLICATION IS COMPLETE        *
  96                                *  NOW ALIGN AND ADD THE PARTIAL PRODUCTS  *
  97                                ********************************************
  98
  99                                D0 =                               HHHH HHHH
 100                                D1 =                          HHHH HHHH
 101                                D2 =                     HHHH HHHH
 102                                D3 =                          HHHH HHHH
 103                                D4 =                     HHHH HHHH
 104                                D5 =                HHHH HHHH
 105                                PRODUCT =           MMMM MMMM GG
 106                                WHERE M= 32 BIT MANTISSA,  G= 8 BIT GUARD
 107

Page 14

 108 4172       *DATA*           42 40        1    CLR .W D0
 109
 110 4174       *DATA*           48 40        3    SWAP D0
 111
 112 4176       *DATA*           D2 80        5    ADD .L D0, D1
 113
 114 4178       *DATA*           64 02        7    BCC MUL1
 115
 116 417A       *DATA*           52 85        9    ADDQ .L #1, D5
 117
 118 417C MUL1  *DATA*           D6 81       11    ADD .L D1, D3
 119
 120 417E       *DATA*           64 02       13    BCC MUL2
 121
 122 4180       *DATA*           52 85       15    ADDQ .L #1, D5
 123
 124 4182 MUL2  *DATA*           42 43       17    CLR .W D3
 125
 126 4184       *DATA*           48 43       19    SWAP D3
 127
 128 4186       *DATA*           D4 83       21    ADD .L D3, D2
 129
 130 4188       *DATA*           64 06       23    BCC MUL3
 131
 132 418A       *DATA*           DA BC       25    ADD .L #$00010000, D5
 133 418C       *DATA*           00 01       26
 134 418E       *DATA*           00 00       27
 135
 136 4190 MUL3  *DATA*           D8 82       29    ADD .L D2, D4
 137
 138 4192       *DATA*           64 06       31    BCC MUL4
 139
 140 4194       *DATA*           DA BC       33    ADD .L #$00010000, D5
 141 4196       *DATA*           00 01       34
 142 4198       *DATA*           00 00       35
 143
 144                                ********************************************
 145                                STORE THE GUARD BYTE IN D0, BITS B15 THRU B8
 146                                ********************************************
 147
 148 419A MUL4  *DATA*           30 04       41    MOVE .W D4, D0
 149
 150 419C       *DATA*           42 44       43    CLR .W D4
 151
 152 419E       *DATA*           48 44       45    SWAP D4
 153
 154                                ********************************************
 155                                *   NO CARRY IS POSSIBLE ON AN ADD TO D5   *
 156                                ********************************************
 157
 158 41A0       *DATA*           DA 84       51    ADD .L D4, D5
 159
 160 41A2       *DATA*           6B 08       53    BMI MULX      SKIP IF D31 = 1
 161



---------------------------------------------------------------------
Transcriber's notes:

I have duplicated the original as closely as possible by keeping the 
original grammar, spelling, punctuation, and layout.

The logo at the beginning of this issue is an ASCII representation of 
the original graphic logo.

The original was done on a daisy wheel printer.  All pages are white 
except pages 9 through 14, which are black ink on dark red paper.  The 
red section is REDLANDS and is explained in the middle of page 7 and 
the bottom of page 8.

The following errors are in the original.

        bycicle
        ficticous
        succesfully
        that the the 6502
        newletter
        how fast is runs
        propogating
        writeable
        miscellaneae
        thru

        In REDLANDS, the author sometimes refers to page 13 as page 3 
        and page 14 as page 4.
