Issue # 14 DTACK GROUNDED Newsletter - October 1982
LATE NEWS FLASH:
DISASTER STRIKES! MOTOROLA SUSPENDS SHIPMENTS OF L12'S UNTIL LATE DECEMBER!
(More news at 11, er, on page 8.)
ON LAST ISSUE'S FRONT COVER PHOTO you may have missed the 68008. Look above and just to the left of the 68000. About the VERY LARGE Apple breadboard the 68008 is mounted on: that is a modified (via bandsaw) 3M Multibus breadboard, and yes it will plug inside the Apple II into one of the user slots. Yes, it will then be possible to close the cover, but only if you have a VERY (!) flexible cover.
As of the day we mailed newsletter #12, we had almost exactly 200 paid-up subscribers to this rag and almost exactly 100 68000 board sales, adding Pet and Apple compatible boards together (but not counting expansion boards, of which we had sold 11). That fact suggests the following greeting: Hello, customer!
However, if we consider that the newsletter is frequently photocopied and that our board has not yet been photocopied as far as we can determine, that might be an overstatement. Now, to business.
Let's discuss icehouses and the speed of light. What's that? You don't see the connection? Well, stick around:
SPEED OF LIGHT: When considering the RAM access time we must consider the time it takes the address signal to reach the furthest RAM from the 68000, plus the time it then requires the data to proceed from the RAM back to the 68000. Since our board is 1 1/4 feet wide, and the signal lines do not pass diagonally across the board, you may be surprised to learn that the total signal path out and back is about three feet. In free space, it requires three nanoseconds for electromagnetic waves (and light) to go that far. On a circuit board we do not have free space conditions and the signals proceed more slowly. So, we must allow 4.5 nanoseconds delay due to the fact that our board is fairly large.
Page 1, Column 2
Why are we discussing the speed of light and signal delays on our board? Because since we announced that 12.5MHz systems were available, and especially since the 12.5MHz premium dropped way down, absolutely NOBODY repeat NOBODY has expressed any interest in purchasing 8MHz or even 11MHz systems. And several board owners have actually expressed an interest in trading in their 150 nsec RAM for nice speedy 100nsec RAM. NO WAY! It's bad enough that we got caught with three 12.5 68Ks that we had paid $272 for, we ALSO got caught with about $2,500 worth of 150nsec RAM that absolutely NOBODY is expressing any interest in buying.
But MOST of the systems we have sold, about 75% of them, are 8MHz boards. Now a few of those boards had -1 RAM, the 100nsec part. Upgrading those will be a snap, using the application note to be found inside this issue. Peek inside at page three. Figure 1 is the old 8MHz Xtal oscillator circuit. Figure 2 is the new 12.5MHz circuit. Figure 3 is the new circuit board layout from the top, Figure 4 is from the bottom. Details on page 2. For now, check out Fig. 5 at the bottom of the page, because THAT is what we will discuss (continue discussing, really) here.
While there are a LARGE number of timing requirements to be met for a 68000 system, it turns out that the most critical one, speed-wise, is the read access time from when the address is available FROM the 68000 to when the data is presented TO the 68000. The basic timing of this operation covers three clock cycles, which at 12.5MHz is exactly 240nsec. For 12.5MHz 68000s (and also the 10MHz variety) the address becomes available within 55nsec from the TOP of the first clock and the data must be presented to the 68000 within 15nsec of the BOTTOM of the third clock. Thus the rise time of the clock becomes one of the delays to be taken into account.
If we add 55 to 15 and subtract the result from 240, we find that we have exactly 170 nsec from the time the address is available to present the data. We will call the read access time of the RAM chip 'Tad', or time from address to data. Here are the delays (outside the 68000 itself) to be taken into account:
1) Tad
2) Address buffer delay (74LS245) 18nsec
3) Data buffer delay 12nsec
4) Clock rise time 1.5nsec
5) Speed-of-light delay 4.5nsec
--------
GRAND TOTAL Tad + 36 nsecPage 2, Column 1
Solving for the required Tad, we have:
Tad + 36nsec = 170nsec
or Tad = 134nsec(The address buffer delay is given as 18nsec, not 12, because the address buffers must drive considerably more than the nominal 50pf from which the nominal propagation delay is derived.) Which conclusively proves that 150nsec RAM will NOT run it 12.5MHz, right? Maybe yes, maybe no. Before we consider that issue further, one can see that we nominally come up 16nsec short over a time span of three clock periods. If we increase the clock period from 80 to 85.33nsec, our system will run as analyzed above. That's 11.7MHz. Provided you modify your clock circuit and plug in a 68000L12.
BUT IF YOU ARE UNWILLING TO COMPROMISE, there are a couple of gimmicks possible. For starters, a part has just now become available called the 74ALS245, made by T.I. That part will reduce the propagation delay of both the address buffer and the data buffer by 6nsec each, so now we only need 146nsec RAM, close to the 150nsec you (may) have on your board. Surely there must be some way to pick up those last 4 nsec?
Gather around, and we will tell you a secret: your 150nsec RAM is not really 150nsec exactly. It is just too slow to be called a 100nsec part. When a part checks out at 101nsec, it becomes magically a 150nsec part on the spec sheet. In real life, it still checks out at 101 nsec. So in real life, we need to consider the statistical distribution of the speeds of the Toshiba parts. For parts manufactured since about last February, the distribution (for 150 nsec parts) is pretty close to the 100 to 125nsec range because that was when Toshiba 'shrank' their mask. After the change in task size, the price of 100nsec RAM dropped to nearly the same as the 150nsec part, a gentle hint as to the true production distribution.
If you purchased your board BEFORE last February (appx) the distribution may go way out to 140nsec with the rare part slower than that. Bad news! Heavy hangs the head!
HERE COMES THE ICEHOUSE BIT; But the speed of the Toshiba part is guaranteed up to 70 degrees C! And NMOS parts like the 2016 run FASTER when they are cooler. At room temperature, 23 degrees C, the part is at least 8% faster. So even a true 150nsec part will run at about 138nsec AT NOMINAL ROOM TEMPERATURE. If you live in Nome, Alaska or in an icehouse, the temperature will certainly not rise above that level and you can safely run your 150nsec (nominal) RAMS at 12.5MHz provided you ALSO perform the modifications to follow:
Page 2, Column 2
- Modify your clock generator to the 12.5 MHz configuration shown in figure 2 on the next page. Note that U58 becomes a Fairchild 74F04. Don't forget to change the crystal!
- Replace U70 and U71, which are now 74LS138s with T.I. 74ALS138s.
- It may prove productive to replace U55, U57, U68 and U69 with 74ALS245s. These parts are now 74LS245s. This will theoretically drop the address to data delay by 12 nsec. The reader is cautioned that we have not actually tested this last step.
- Oh, yes: do be sure to replace your 68000L8 with a 68000L12!
A 24MHz DTACK BOARD?
SOME OF YOU MAY BE WONDERING just how fast our board is capable of running. You may be interested to know that Harris Semi has introduced the HM-65161B-5, a 2K X 8 RAM pin compatible with the Toshiba 2016P-1s we use, with an access time of 55nsec, The new Toshiba MOS Memory Products Data Book carries an advance spec sheet on their 2016HD with an access time of 35nsec.
TRANSLATION: we are all set for those 1 micron 24MHz 68000s any time somebody decides to make one!
THAT DYNAMIC RAM VERSION OF THE DTACK BOARD: since Hitachi sells 2 to 4 million 64K DRAMs a month and ALSO manufactures the 68000, we asked them nicely for in application note showing how to use those parts together in a system. They had no such ap note. We said OK, how about an ap note showing how to build a memory board with those 64Ks? You are not going to believe this, but they did not have ONE LOUSY PIECE OF PAPER showing how to use their 64K chips!
Naturally we turned to Motorola. They also make both 64K DRAMs and 68000s. Would you believe that they ALSO have not a single piece of paper showing how to use their 64K DRAMs, with or without the 68000? Their sales types are mistakenly under the impression that ap notes #816 and #835 deal with 64K DRAMs. THEY DO NOT!
So it looks like we are going to have to design our Dtack DRAM version the same way we had to design our simple 68000 system: carefully interpreting the spec sheets. We prefer not to do this; re-inventing the wheel is dumb. Especially since the spec sheets are often misleading; one 64K DRAM spec sheet unambiguously states that *CAS enables the data output buffer. Bull puckey! (Actually we are quite lazy.)
Page 3
Page 4, Column 1
MISCELLANEAE:
S-100 REPORT: We reported in issue #9 that the S-100 'standard' was in a heap of trouble. Our sources were an article in Electronic Engineering Times plus a rebuttal article in Infoworld. The rebuttal article essentially stated, "They can't reject the standard because we haven't submitted it yet!" We think EET's article was more carefully reasoned and documented.
Well, Mark Garetz (the new S-100 committee chairman) and Sol Libes have each assured us recently that the S-100 draft standard is alive and well and that substantial progress is being made toward approval. So we picked up the issue of EET published near the end of Aug. and find that EET asserts that the S-100 draft was essentially tabled this year and is now moribund! (British readers: 'tabled' has opposite meanings in our countries. Over here, when you table something, you forget it.)
The thing is, EET is a generally reliable publication; definitely not the 'National Denouncer' of the electronics industry. Clearly, either EET or Mark and Sol are off base (nobody's perfect!).
TECHNICAL S-100 STUFF: The IEEE 696 draft standard, which is what we are discussing, is an OPEN-COLLECTOR (!!) bus draft standard. So the bus is limited to 10 MHz. Us folks here are shipping 12.5 MHz 68000s routinely. You may draw your own conclusions.
16032 REPORT:
Back in May National dumped a huge press release on every electronic and small computer publication there is, asserting "The 16032 is available now and we will begin shipping in July!" We suggest you reread that last quotation. As of 8 Sept '82 not ONE single 16032 has passed across the counter at Hamilton Electro Sales, a local authorized National distributor (and the source of our 12.5 MHz 68000s). Well, we remember another manufacturer of complex microprocessors with a similar credibility problem two years ago.
However, it appears that actual (limited) production of the 16032 will be underway soon. We have a little more info on this part we thought we would pass along to you.
THE GOOD NEWS: the 16032 is in absolutely PERFECT part to design a COBOL compiler around. The instruction set either has perfectly regular (orthogonal) addressing modes, or (IF it is not PERFECTLY regular) it is at the very least such more regular than whichever microprocessor that is in second place.
Page 4, Column 2
The 16032 is claimed by National to be much superior to the 68000 for multitasking operations, and therefore more suitable to run systems such as UNIX, which is inherently a multitasking operating system. Since we have absolutely no interest here in multitasking (this is the journal of SIMPLE 68000 systems, remember?) we are disinclined to argue the point or even investigate it. Likewise, they assert that the 16032 is better adapted to a virtual memory environment (they are dead right on that one but check Motorola's virtual machine, the 68010, which is being sampled.)
The 16032 has a 32 bit multiply, which the 68000 does not. And the 16032 multiply structure is architecturally superior (more levels of pipelining). Which means it runs faster for equivalent clock speeds.
NOW FOR THE BAD NEWS: To make the architecture and instruction set absolutely perfect for a COBOL compiler, National left out all the good stuff that us assembly language programmers like to use to produce fast, compact code. Like, for instance, address register indirect addressing with post-increment (and pre-decrement). Since automatic post-increment and pre-decrement has been left out, there is a particularly serious requirement for the short, quick forms of incrementing and decrementing a register such as the 68000's ADDQ and SUBQ instructions. Sorry, the 16032 does not support those instructions either! What's that? You don't program in assembly code? Just BASIC? Well, BASIC interpreters just happen to be written in assembly code!
The 16032's 32 bit multiply is a signed (two's complement) multiply ONLY! That means to perform the unsigned multiply for a floating point package using a 48 bit mantissa, the 16032 must use nine each 32 bit multiplies and sum just the lower half as partial products. That is extremely inefficient use of that big fancy 32 bit multiply! By way of contrast, the 68000 supports both signed and unsigned 16 bit multiplication. So we can multiply the two mantissas by using nine each 16 bit unsigned multiplies (MULU) and summing the partial products. Who would write such code? Your faithful newsletter editor did yesterday, as part of a 62 bit floating point package which will initially be used to support our HALGOL matrix inversion routine.
One consequence of not having an unsigned multiply (or divide) is that the 16081 math chip becomes a necessity rather than an optional enhancement. National is now projecting Jan '83 for samples. And we know how well National keeps its schedules, don't we?
National's 6MHz part will naturally be faster manana.
IF YOU FAVOR THE 16032, do not repeat not do any programming on the 68000 and thus become accustomed to having 16 each 32 bit registers. The 16032 has only half as many. The difference is like giving up your disk and going back to cassette program storage.
Page 5, Column 1
The day after writing the material on the last page, we happened to be speaking to the publisher of Microcomputer Printout Magazine. It seems their gossip columnist had printed an item about the 68000 having more registers than the 16032, and had received loud screams of protest both from National and from the manufacturers of the Acorn, a 6502 machine which will shortly (?) have a 16032 processor attachment. So let us examine this issue in greater detail.
First, we were speaking of GENERALLY USEFUL registers. We were once discussing the 6502 and mentioned that it had no 16 bit registers. A participant jumped up and said, "Yes, it does! The program counter is a 16 bit register!" Since the program counter is not particularly useful to manipulate data or even as an address pointer, we had implicitly excluded it from the discussion.
The 16032 has eight general purpose 32 bit registers plus six dedicated registers which are not GENERALLY useful. One of these dedicated registers is, of course, the program counter. The 16032 uses separate stack pointers for interrupts and subroutine calls; we have now accounted for three of the special registers.
While the 256 byte vector table in the 68000 is fixed in lowest memory ($000000 - $0000FF) the vector table in the 16032 is relocatable (for some reason). A 32 bit register is dedicated (!) to point to the start of the vector table (that's real useful, folks). This register is called 'interrupt base'.
Because the 16032 is designed for use with compiled languages, two additional registers are dedicated to the sort of things that compilers need done. The 'static base' register points to the global variables of a software module. The 'frame pointer' is used by a procedure to access parameters and local variables on the stack. This register is automatically modified by the ENTER and EXIT instruction. If you have never seen ENTER and EXIT instructions before you must not be a compiler writer. With microprocessors, those two instructions generally need to be simulated in software.
So, the 'static base' and 'frame pointer' registers are highly useful to compiler writers but not terribly useful otherwise. And we have now accounted for ALL of the six dedicated registers in the 16032; all we have left is the eight general purpose registers.
NOW FOR THE 68000; The 68000 has three dedicated 32 bit registers and 15 general purpose registers. The three dedicated registers are the program counter, the supervisor stack pointer and the user stack pointer. We have ignored the user stack pointer in the past since we believe in a philosophy of one man, AT LEAST ONE microprocessor. So all of us are supervisors!
Page 5, Column 2
The fifteen general purpose registers are data registers 0 thru 7 and address registers 0 thru 6. What's that? You say that since some of the registers are dedicated to data and sore are dedicated to address registers they cannot be considered true GENERAL PURPOSE registers? We admit that this is the first impression that one receives when learning about the 68000.
However, consider the point that in any program, one is most likely to need a mixture of data and address registers. True, the desired mixture is not always 8 data to 7 address. But the fact is that there is more overlap between the functions of those register types than is initially apparent. Consider that ADDQ and SUBQ work equally well on both data and address registers so that one can use either for a loop counter: DO SOMETHING, SUBQ #1 A3, BNE DO SOMETHING.
MOVEing, ADDing or SUBtracting address registers to data registers is equally as code efficient and as fast as data register to data register. And finally, the address modes 'address register indirect with index' and 'program counter relative with index' can use EITHER a data or address register as the index register. It is our experience in the past fifteen months of assembly language programming using the 68000 that we have never found an instance where we wished for more address registers and fewer data registers or vice versa (sometimes we would like to have 87 of each!).
The 68000 has 15 GENERALLY USEFUL registers and the 16032 has 8. That is close enough to 'double', no?
Now, just what in the heck is that British 6502-based machine going to do with a chip that is designed to support a COBOL compiler? You see, that machine (the Acorn) has been adopted by the BBC (British Broadcasting Co, familiarly known as the 'Beeb') as a vehicle to teach computers and programming to the great unwashed (that segment of society who watch Gilligan's Island reruns in this country). Is the Beeb going to run a series of programs on "Programming COBOL Compilers for Fun and Profit"?
(Our British readers will kindly note that we have avoided the political implications of the whole mess such as the fact that the Beeb, which is ALMOST an agency of the British government, is forbidden under law to associate itself with a commercial enterprise. We have also ignored the fact that Clive Sinclair is having kittens because the Beeb did not ally itself with HIS commercial enterprise and has introduced a new computer with an extraordinarily high performance/cost ratio, the Rainbow, in an attempt to bury the Acorn.)
Page 6, Column 1
(And finally, we will not enquire just how the production contract for the Acorn happened to be let to ICL. ICL combines the incompetent management and GOVERNMENT SUPPORT of Chrysler with the spectacular unprofitability of Zilog, back before EXXON restructured Zilog so that it does not have to report those losses as specifically attributable to Zilog. The difference is that ICL is a British company. And, oh yes: ICL does not sees to be able to manufacture the Acorn in the quantities desired.)
TRUTH (?) IN ADVERTISING:
ONE OF OUR READERS was kind enough to send us a copy of the promotional material being distributed by Intel comparing the performance of the iAPI 286 and the 68000. You will recall our suggestion in a recent newsletter that such comparisons are always completely objective, unbiased and factual. The dummy who wrote this one even put his name on it: Jayaram Bhat.
The headline of this completely factual comparison sheet states: "iAPX 286 LEAVES THE 68000 IN THE SLOW LANE!" That is followed by a series of benchmarks and then the sheet concludes thusly: "Performance of the iAPX 286 blows the 68000 out of the water". and, "LET US GO KILL THE 68000!"
Goodness gracious! we declared. Perhaps we underestimated the performance of the 286 a few issues back when we said it was a pretty good CPU, but slower than the 12.5 MHz 68000? So, we looked at the very first benchmark, a 32 bit Add/Sub. Well, we happen to know about that one. A 68000 requires six clocks, or 0.48 microseconds at 12.5 MHz. Then we looked at the right hand side of the line and discovered that the 286 is 1.6 times FASTER on that benchmark! WOW! According to our arithmetic, the 286 does a 32 bit Add/Sub in 0.3 microseconds, right?
WWRROONNGG!! It seems that the comparison sheet (prepared by Intel to show the 286 at its best) lists the 32 bit Add/Sub time for the 286 as 1.125 microseconds. Heavens to Elizabeth! It appears that the comparison sheet does not completely accord with the facts! Any reader of this newsletter who is surprised should go stand in the corner.
So how did Jay come up with that 1.6 ratio? Simple. He gave the timings for a FOUR (4) MHz 68000 as handicapped by a MC68451 memory management unit. That means 7 clocks are required, which is 1.75 microseconds at 4 MHz.
Page 6, Column 2
Jay, we'll let you kill all the 4MHz 68000s you want but if you are even going to THINK about killing our 12.5 MHz units you will need heavier artillery. Hell, based on that one benchmark you can't even come close to an 8MHz 68000! By the way: you say be interested to know that Motorola doesn't even TEST for parts slower than 8MHz these days. They do have a few contracts calling for scheduled delivery of 6MHz 68000s. So they ship 8MHz parts nicely stamped 'L6' to fulfill the contract.
SOFTWARE UPDATE #3:
Well, it's only update #2 for our Pet/CBM customers. We have just finished the remaining transcendentals in our Microsoft compatible floating point package. That means we also TESTED them, something IBM needs to learn (boot up compiled PASCAL on an IBM PC. Print SIN(-6.4). That's radians, remember. Result: -6.4. AMAZING!). We promise that SIN(-6.4) using our 68000 floating point package is -.116549204. Our WANG 520 desk calculator says -.1165492048, so we are pretty close.
For our Pet/CBM customers, we have to provide new EPROMS (3 or 4 depending on the model). Our Apple customers just get a disk (but they get one more often). Here is what is on the Apple disk:
- DOS is NOT on the disk! We removed it to make room for more files. DO NOT TRY TO BOOT THE DISK (and do not criticize it when it does not boot!).
- There is a new SETUP program showing how to link the new, completed floating point package into Applesoft using binary file UTIL4. UTIL4 is also included on the disk, of course.
- In newsletter #12 we discussed a "sieve of Erastothenes" benchmark. We have included the plain Applesoft version, 'SIEVE'. The HALGOL version (very slightly faster, ahem!) is included; 'SIEVE.H' plus binary file 'SV.O'.(The following 68000 source code is compatible with the DOS Toolkit text editor and the Phase Zero assembler. The 6502 source code just needs DOS Toolkit.)
- The source code for the 68000 floating point package ('FP') in format compatible with the DOS Toolkit editor and the Phase Zero assembler.
- The 68000 source code for the interactive 3-D program 'D6B'. An assembly listing may reveal some interesting tricks as to how a 68000 attached processor plots into the (highly scrambled) Apple II HIRES memory.
- The 68000 source code for HALGOL (in development, but the code provided has been tested). This includes the floating point to ASCII conversion printed in the last newsletter.
Page 7, Column 1
- The 68000 source code for the PROM monitor on the 68000 board. This is the version as transcribed from a WANG 2200 listing. It has not yet been tested (but you aren't going to modify those PROMs anyhow, right?).
- The 6502 source code for the host side of file UTIL4, called 'U4.S'. This includes the routines to hook into BASIC, the 6502 side of the monitor routines and some debug utilities such as the 68000 register and status dump.
- The (partial) 6502 source code for the SIEVE.H demo program, 'UH1'. This is the extra code that must be linked onto the front of 'U4.S' to produce the runtime object code in 'SY.O'. We did not include the complete file for space reasons (the complete code occupies 2 files, over 120 sectors).
- An updated memory test program. In the event of a memory failure, this program will now tell you the number of the memory chip AND WHAT BOARD IT IS ON. For instance, if you pull chip U17 on the expansion board, you will eventually encounter a 'BAD U17 ON THE MEMORY EXPANSION BOARD' message. This would be a much more useful program if those darn Toshiba static RAMs would fail more often. We've gone through more than 3000 and we haven't found a bad one yet. We still permit the program to report an error when the stack is overwritten around $001FF0 so you will know the program actually works.
- We somehow slipped up and did not provide the fastest version of our 'hat' program as part of update #2. So we have included 'D3.FASTER' and its associated binary file D3UTIL5. If you have a 12.5MHz board this program will run in 10.3 seconds.
IF YOU PRINT AN ASSEMBLY LISTING OF ONE OF THOSE 68000 SOURCE FILES, you must of course do so on dark red paper. Your faithful newsletter editor has unselfishly taken great pains to locate a source of Z-fold 9.5 by 11 inch tractor feed dark red paper, perfed at 8.5 inches. It comes in boxes of 2046 sheets each at the bargain price of $16,383.99 per box plus shipping charges (Calif. residents add 6% sales tax). Address prepaid orders (cashier's checks, certified checks and money orders are acceptable) to:
FNE ENTERPRISES
P.O. BOX 68000
SANTA ANA CA 92705
To make use of any of those programs, you will probably want to transfer them onto a disk with DOS and, in the case of the 68000 source files, the Phase Zero cross-assembler. FID will probably work but we are now using Sensible Software's SUPER DISK COPY III for that purpose (and also to zap DOS).
Page 7, Column 2
TRUTH (!) IN ADVERTISING:
There is a shocking outbreak of truth on page 576 of Sep '82 BYTE magazine. On the upper right of the page there is an ad for a 64K S100 RAM card. The promotional description states in part: "FULLY SUPPORTS THE NEW IEEE 696 S100 STANDARD (AS PROPOSED)." Please note those two last words. This is absolutely the FIRST time we have ever seen an S-100 advertisement that admitted that IEEE 'standard' ISN'T. We understand that some of the larger S-100 manufacturers have raised a war chest and have let a contract on the copy writer for Digital Research Computers (telling the truth in this here world can get you into a BUNCH of trouble!).
As long as you have that issue of BYTE at hand, don't miss the amusing advert on pages 32 and 33. Also, those of you who have an interest in PASCAL, which is NOT the same as having an interest in PROGRAMMING the language, should read the material starting on the last three lines of page 324 and continuing to the first paragraph on page 330 (that's really not such to read, there are MANY ads!). Yes, we know you read BYTE, but at 600+ pages it is easy to overlook the occasional item of interest.
One of the very most interesting things is what ISN'T in Sep BYTE: a full page ad from Metamorphic Systems for their 8088 board. In fact, it has been quite a few issues since that lovely ad has appeared. And we don't see anyone offering that board for sale.
SPEAKING OF MAGAZINES: (We were, weren't me?) We have mentioned in the past that there is this obscure outfit called Tandy which manufactures small computers under the Radio Shack label. Since these computers have until now only been sold in the thousands of Radio Shack retail stores, and since those stores carry no OTHER brands of small computers, us folks who work with those other brands tend to lose sight of the Tandy world.
We happened to pick up an "80micro" magazine the other day, the Sep '82 issue. Interesting stuff. For starters, the magazine has 402 pages, which is getting in BYTE's range. Looks like the circulation is ALSO getting in BYTE's range. Which means there are an awful lot of computers and an awful lot of computer users out there that we don't know about. Which we said already.
A quote from p.16: "Why is a Model 16 like a bowling ball?" "Because you can get the same amount of software from each!" So goes the joke making the rounds at 1 Tandy Center in Ft. Worth these days...
Page 300: "As of the middle of June, Radio Shack had shipped no more than 2,000 Model 16s and the majority of these units are still in dealers' hands..."
Page 8, Column 1
On P.40, a review of some Model 16 accounting software: "Our benchmark tests ran seven percent faster (than the Z-80 based Model II) on the Model 16. It will be interesting to try the benchmark test again when BASIC is available for the 68000 processor." SEVEN PERCENT FASTER? GADZOOKS!
IT DOES SEEM THAT THE 16 is having difficulty gaining airspeed for takeoff... Wonder how the info above jibes with the statement by Jon Shirley a couple of months back that "Radio Shack has sold about 50,000 Model 16s." Jon Shirley is Tandy's small computer marketing honcho.
For the benefit of those readers who have been asleep the past half dozen newsletters, the Model 16 sports a 68000 cpu, along with a Z80 so the computer will have some software to run.
And you will note that we have been very careful just now to refer to "small", not "personal" computers. You see, Tandy wants you to share that 68000 with two other users...
THE CATASTROPHE WHAT AM:
Like we said on the first page, Motorola has just stopped shipping the 12.5MHz version of the 68000. We first learned of the problem on 17 Sep. That's when Hamilton Electro Sales advised us that they could only ship 8 L12's of the 20 we had released that week, and that the balance would be 12-18 weeks. We received this information fairly late that Friday afternoon. The following Monday we called all over the country and rounded up (we hope; the parts are still arriving, slowly) an additional 46 parts. Our largest customer got wind of the problem and immediately ordered 40 boards, and would have ordered all 46 except that we wanted to keep a few to fill orders already in the mail.
On Thursday the 23rd we were advised the nature of the production hold, including the fact that shipments should resume around the end of December. We were also told the REASON for the hold, and then told not to publish that reason. We think that is a mistake in judgement on our source's part because the reason is highly technical and innocuous. We do not believe in shipping anything but quality parts here at Digital Acoustics and we would not hesitate to continue shipping L12s if only Motorola would sell us some. And yes, we ARE talking about the L12s that are now sitting on the shelf at Motorola and that they refuse to ship.
Those of you who have already received 12.5MHz boards from us: don't sweat it, there is absolutely NOTHING wrong with your board.
Page 8, Column 2
NOW WHAT, GUYS?
We have already returned one check for a 12.5 board. While we do not claim that we will refund money CHEERFULLY under these circumstances, we will, and do, return it (ink smeared with teardrops). That is for those persons who absolutely INSIST on 12.5 parts NOW, no substitutes permitted.
For those of you who are willing to put up with 8MHz boards temporarily until the 12.5 part is available, we will ship you a board which is 12.5MHz in every respect except for the crystal and the 68000 itself. In other words, all of the RAM will be the 100nsec -1 variety. We will sell you this board for $120 less than the published price for that memory size, and provide a certificate guaranteeing that we will upgrade the board (at our Santa Ana facility) to 12.5MHz as soon as those parts are available for $120.
That way, you eventually get the 12.5MHz board you want while having possession of a 68000 board in the meantime so you can start learning about the part.
And really: until quite recently, an 8MHz 68000 with no wait states was considered a very, very fast computing device!
WHILE WE ARE TELLING YOU ABOUT OUR PROBLEMS, we might as well do a complete job. We sold a BUNCH more Dtack boards in Sep. than we had anticipated. As a result, we ran out of Apple compatible boards on 28 Sep. and are not scheduled to receive the next increment of 50 boards from our supplier until about the middle of Oct. So for about two weeks, we can't even ship 8MHz boards!
Actually that isn't much of a problem. In fact, we're bragging just a little.
BUT WE REALLY SHOULD HAVE KEPT OUR MOUTH SHUT about the quality of our boards. No sooner had we published, a couple of newsletters back, that we had not had any failures out of the first 100 boards or so then we suddenly were hit with TWO failures. The first was apparently a microcode failure down inside a 68000L12 (naturally) which caused a fairly spectacular display when running our 3-D demonstration programs. You see, although the programs would run all the lines drawn mould be either perfectly vertical or perfectly horizontal! This actually produced a pleasing artistic effect but not the effect intended. So we replaced the chip for our (fortunately local) customer.
Now, nobody is going to call us sloppy workmen for a microcode failure but the next one was a lulu. We shipped a 92K 12.5MHz board to a customer in Germany.
Page 9, Column 1
Not only did we not leave anything out of that shipment, we included, at no extra cost, a clipping from a 1/4 watt resistor which became wedged under the front end of three (!) of the LSTTL ICs. Naturally, when the customer turned on his board it didn't work. After much head-scratching (the customer is an M.D., not an electronic engineer) he spotted the stray clipping.
Now, picture YOURSELF as an American who his ordered a $1000+ part from a small company in Germany under these circumstances. Our German customer took a close-up photo with an SX-70 camera clearly showing the clipping wedged under the sockets and sent us that along with a covering letter which was admirably restrained given the circumstances.
After analyzing the problem, we decided that only one integrated circuit could have been damaged. Guess which one. So we mailed a replacement L12 that same day and waited until the following day to call (the time differential is about 10 hours, had we called that afternoon we would have woken the household from a sound sleep!). And advised that the replacement part was already on its way.
In the future we will be more circumspect about discussing our quality control.
PHASE ZERO BUG REPORT:
A couple of new bugs have appeared in the Phase Zero cross-assembler. The most serious is that the MOVEM instruction assembles improperly for both the '-(An)' and '(An)+' addressing modes. The problem is that the bit mask correspondence in the 68000 is opposite for the predecrement mode as opposed to all the other modes. Phase Zero's programmer (well, one of them) mistakenly applied this correction to the postincrement mode. As a result, BOTH the preincrement and postdecrement modes assemble the register list bit mask incorrectly!
Also, the LIST command does not work. Phase Zero provided the NOLIST and LIST commands so that people like us with slow MX-80 printers could restrict the assembly listing to the local areas of interest. The idea is, when appending code around line 1000 of a file, one could place a NOLIST command in the first line of a file and then a LIST command it the start of the new code. Then only the new code would be printed out upon assembly. Unfortunately, LIST has the same effect as NOLIST.
THE FOLLOWING IS NOT A BUG: the Phase Zero assembler has BRANCH S and BRANCH L pseudo-ops. This selects the size of the forward branches on the first pass of the assembler. Since most of us will select BRANCH S, an occasional forward branch may exceed the maximum range of 126 bytes in the short form. In this case, the Phase Zero assembler will print an overflow error message just before the branch command during the SECOND pass.
Page 9, Column 2
To fix this problem in your code (and it is YOUR problem, not the assembler's), place a BRANCH L command in the line just before and a BRANCH S command in the line just after the branch in question.
YOU DON'T HAVE TO WORRY ABOUT THIS on a reverse branch because the assembler will automatically switch to the long-branch mode when needed. If you do not understand why the reverse branches can be automatically adjusted for a reverse branch but not for a forward branch then you have never written a two-pass assembler!
MORE SHORT AND LONG BRANCH STUFF:
There is a nasty problem to avoid when using the 68000 branch instructions. NEVER, NEVER branch to the very next instruction (when using the usual short branch mode)! Suppose we have code like this:
JSR doit ;do it twice
doit (code) ;do it once
RTS ;returnNow, the code above will work just fine using the JSR instruction. But the JSR instruction requires four bytes and can be (usually) replaced with the BSR or 'branch to subroutine' instruction in the range -128 to +126 bytes. The exception is when the location being branched to is the very next line of code. Which means the offset is zero bytes.
When the 68000 encounters a branch command, whether unconditional (BRA), to subroutine (BSR) or conditional (e.g. BCC) it checks the second byte of the instruction word. If that byte is zero, it ignores it and uses the NEXT word as a signed offset (range -32,768 to +32,766).
So if you replace the JSR in the code example above with BSR it will assemble a zero offset because 'doit' is the next location. When the code executes, the first word of the code for subroutine 'doit' will be used as an offset and our processor will in general go AWOL. Under most circumstances this is considered undesirable.
We DO hope that our readers appreciate these little suggestions which are arrived at by careful examination of the theoretical parameters. You don't think we would do something stupid like that OURSELVES do you?
THE READER MAY BE INTERESTED TO KNOW that Phase Zero has just entrusted us with the source code for their assembler for the purpose of converting it to a Pet/CBM compatible version.
Page 10, Column 1
US AND MICRO MAGAZINE:
We received the Sept. issue of MICRO magazine at noon on Aug. 23, which happens to be the day we delivered our newsletter #13 to the printers. This is being written the next day; issue #13 will not be mailed for two days yet and here we are working on issue #14. Sigh.
It is just barely possible that some of you say have taken our assertion that all those 100 announced 68000 systems are really minicomputers with a small grain of salt (it never ceases to amaze us that our readers do not always fully agree with our declarations/wild guesses). Well, MICRO magazine is not the sort of publication that you are going to find in the lobby of a DEC sales office. But it IS fairly commonly found in retail stores for 6502 based personal computers. It has been known for about four months that, beginning with the Sept. issue, MICRO would become the FIRST national/international magazine to provide significant coverage of the 68000 microprocessor, and, by implication, 68000 based products.
So, guess how many advertisements are to be found in that issue from vendors of 68000 based products? TWO. One was a quarter-page ad by an outfit in San Diego that makes nicely packaged KIM-like products at higher-than-KIM prices to set on engineering executives' desks. The other was a full-page ad from us. Honest. With a real phone number.
Friends, MICRO magazine is read by personal computer enthusiasts and minicomputer manufacturers care NOT A WHIT about personal computer enthusiasts. You will find NO advertisements in Sept. MICRO from Fortune, Corvus, Sage, Charles River, etc, etc. So: those of you who have been sceptical of our assertions in this particular area should perhaps reconsider.
Each of us has from time to time seen, especially in personal computing magazines, examples of reviews of products which are alongside advertisements for those same products. You may have wondered just how such the review was influenced by the placement of the advertisements. On pages 26 and 27 we have a similar occurrence which your faithful newsletter editor has, by a coincidence, some inside information on.
We wrote that ad (actually we bled over it!) two months earlier. We had absolutely no (specific) idea what sort of editorial material would be in the issue. Similarly, Lawrence Kepple must have written his article (and editorial) in about the same time frame. He surely had not seen our ad copy; it took time to typeset it and mail it to MICRO. To the advertising, not editorial, department.
Page 10, Column 2
There is some similarity between the ad and the article because we were both addressing similar problems: how do we say that the 68000 is a very high performance part while admitting that 10,000 canned applications programs do not exist? There are those, including us, who think that pages 26 and 27 look such like a two-page advertisement for Digital Acoustics.
But there was absolutely no collusion. On the contrary, the juxtaposition of the ad and the article is the result of the deliberate policy of MICRO magazine (which is shared by several other personal computer magazines) to group advertisements with related editorial material where possible.
LOTS ABOUT UNIX:
Lawrence Kepple treated Dtack kindly in the article which begins on page 27. Still, we must disagree with some of the things that he, and others, are beginning to assert about UNIX. Specifically, one reads and hears more and more that UNIX is a very good operating system for program development (true) and that therefore UNIX will become the standard operating system for 68000 based personal computers (false for several reasons).
In assessing UNIX, we are operating under the handicap of not being personally familiar with the system. When we recently began hearing things which were not in accordance with the facts as we understood them, we decided to get a little expert commentary on the subject. So we naturally phoned a Dtack subscriber who is expert on both UNIX and the 68000. We will call this person John because that is not his name.
John, we said, we think it is not a good idea to try to bring up UNIX on our Dtack board, but we would like your thoughts on this subject. "My initial reaction is that trying to bring up UNIX on an Apple is absurd" John replied. We pretty such share that viewpoint, but, just what really would be involved? we asked.
"For starters, you would need a source licence from Bell Labs and that is $50,000 right off the bat. From what you have told me about your endeavor in the past, I'd say you don't have the resources to do that." True, we replied, but we are growing and it might not be out of the question in the future. What else?
"The next thing is you will have to find a software house with some experience installing UNIX on the 68000. There is only one company that is really good at this and that is (name deleted). They have installed UNIX on about twelve or thirteen 68000 based systems within the last year. This outfit will want about $15,000. About $5000 of that will be an advance against future royalties" John pointed out. "But perhaps you do not realize the hardware constraints imposed by UNIX."
Page 11, Column 1
We understand that a big disk is needed, we replied. "A user will feel constrained if he only has a 10 megabyte disk. 20 is needed to be really useful." We interjected, we understand that Fujitsu is going to introduce a 40 megabyte fixed/removable Winchester around the end of the year and that Western Digital will have a 4 inch by 6 inch board which will interface that Winchester, among others. Incidentally, a big fixed/removable configuration is what we have been waiting for. Sure solves the backup problem!
"Isn't that, well, a little overambitious for an Apple II" John enquired? WE want a big disk for program development ourselves, we replied. We get the 'disk full' message MUCH too frequently with just the small amount of source code we have now. And you might be surprised at some of the customers we have and what some of their applications are. But, back to UNIX. What else do we need?
"You will definitely need some form of memory management and protection. UNIX is inherently a multi-user, multi-tasking environment. I know you do not favor multi-user installations but even with one user UNIX remains fundamentally a multi-tasking operating system. Hence, you need memory protection in hardware."
But that will slow us down, won't it? "Not necessarily. I know of one 68000 system in particular which runs at 8MHz without wait states and has memory protection. Of course, they use some fairly expensive high speed logic to accomplish that." John, that really doesn't sound like anything that could be called a simple system, we stated.
"Well, no" he replied. "And another thing: you are going to need a half megabyte of RAM as the absolute minimum. If you don't, the operating system has to swap the various tasks back to the disk too often and the system really bogs down. UNIX is really happiest with two megabytes of RAM."
John, we replied, we are trying to compare what you are describing against an Apple II with a Dtack board and a big hard disk. It doesn't seem to fit. "As I said at the beginning of this conversation, I think trying to run UNIX on a small computer like the Apple II is ridiculous. No, I have used an Apple and it is a very useful single-user single-tasking device. But that is NOT what UNIX needs" said John. "And there is one other little thing which may interest you:" Yes? we replied.
"UNIX is absolutely worthless without C, which is a compiled language. All of the 68000 C compilers come from (or are cloned from) a compiler developed at a certain northeastern university. And that compiler happens to be severely bug-ridden. Just thought you'd like to know!"
Page 11, Column 2
A SUMMARY: To run UNIX, we need at least 10 megabytes of fast hard disk, preferably 20. We need 1/2 to 2 megabytes of RAM. We need memory management and memory protection to keep those multiple tasks separated. Now, all of these things can be accomplished and have been accomplished. Grab $20,000 and go see Charles River Data Systems, for example. But that certainly does not describe anything in our product line.
JUST WHAT IS OUR PRODUCT LINE? Those of you who read between the lines of newsletter #12 will be aware that we have been wondering about that ourselves. We even called ourself a minicomputer manufacturer, and we do not like minicomputer manufacturers. But conversations such as the one reported above have helped us more clearly identify ourselves.
The fact is, our $8345 6502-based environmental noise monitor is a complex device. The autoranging and auto-zero circuitry is a Wilkes microprogrammed logic sequencer constructed entirely in CMOS, since power consumption is critical. This logic sequencer operates completely independently of the 6502. There are TWO chopper stabilized amplifiers; this won't mean much to you digital types but it might impress those of you with analog circuit design experience. Especially if you knew about the low power consumption (5 mw ea).
And we have just submitted a sole-source bid to the Army (the Army?!) for five of these monitors with some custom attachments to be used in a space-shuttle re-entry noise study in the vicinity of Vandenburg AFB. A part of the reason for our selection for this program was our successful performance with the Air Force NOISECHECK program a few years earlier.
So if we know how to make complex systems, how come the Dtack board is so simple-minded, you ask? There are several reasons, we reply. First, the Dtack board started as a fallout from a simple breadboard constructed to evaluate the use of the 68000 in small instruments. Secondly, we perceived our primary marketplace as hardware hackers who would want to get their hands on an inexpensive board to learn about the 68000. To keep the price down, we used static RAM not only for simplicity but also so that we could sell a board with as little as 4K RAM. The smallest RAM configuration using 64K dynamic RAMS is 128K.
And dynamic RAM is not particularly simple. One asks oneself at times whether one is in the 68000 business or the dynamic RAM business.
Page 12, Column 1
The next happenstance was that the personal computer we owned was the CBM 8032, NOT the Apple. As a result, the physical size of the DTACK board is determined by what can fit INSIDE the case of the Pet/CBM. It turned out we could fit a board 15 inches long inside the case, mounted from front to back. This allowed us to put 92K on the basic board. GREAT! We could sell the dedicated hacker 4K and he could add more RAM as he needed it, up to 92K. Summer a year ago when this board was designed, 92K was a lot of RAM for a Pet or Apple.
If our personal computer had been an Apple II we would of course have known that a fundamental law of the natural universe is that add-on boards have to be three inches high and ten inches long with a nose job. Instead, we have this ludicrous board, 6 1/2 by 15 inches which sits in BACK of the Apple. Outside. Without even a case, although we are working on that.
We announced a 128K expansion board and didn't bother building it until a Dtack customer came to us and waved some money at us. Now we have all the expansion boards you might want. The present version has built-in decode for only (!) seven slots so our system, as presently configured, is limited to just under a megabyte.
The fact that our board runs fast is not an accident. Those of you have been reading this newsletter are surely aware that we prefer fast computing devices to slower ones. A related fact is that simple systems run more swiftly than complex ones because there are fewer things to slow the system down.
But the kind of speed we offered, and the kinds of applications of that speed, we envisioned as being appropriate to the sort of individual hacker who likes to benchmark his own equipment against the other guy's. A 'hot rod' with registers and pipelining instead of four-barrel carburetors.
Others have discovered a surprising number of useful business applications ranging from the kind of scientific number crunching that we had in mind to graphics and business arithmetic (using 32 bit integers) that we did NOT have in mind.
With the benefit of 20-20 hindsight this is not surprising; when you have a processor this powerful at a price affordable by in individual (or small business) you are not going to repeat the old applications of a 1MHz 6502 as long as that 6502 is still available. No, the applications for the 68000 will be new ones, many of which nobody has thought of yet. After all, when the 6502 first came out nobody was then thinking of data base management system or electronic spreadsheets, right?
Page 12, Column 2
We refer you back to a letter we received in the first week of last Nov. and printed as pages 6 and 7 of our newsletter #5: that letter, which was postmarked San Jose, predicted that our company would fail and gave four reasons for that prediction. One was that at least four 68000 boards, some by major companies and selling for a lot less than ours, would be available within a year. Could be, there are 35 days to go in that year as we write this.
Another reason he gave was an accurate, as it turned out, prediction of a 68000 based small computer from Tandy. Just exactly how many sales do you think we have lost to the Model 16, guys?
Contrary to the predictions of that writer, Dtack has become an important contributor to the profitability of Digital Acoustics and, since last April, has shown steady sales growth. This is being written on Sep. 30, and this past month's Dtack sales have been by far the best ever. If we break the sales down between our business/industrial type customers and the individual hacker sales, both sectors are showing steady growth. This is a good thing for us but also a good thing for our past and future customers. We all know that the amount of software generated for a particular computing device is proportional to its user base.
But we did want to admit that our success has been partly due to good planning and hard work and ALSO partly due to plain dumb luck. The aspect of our board which was initially criticized the most by Apple owners, the fact that the board is WAY too big to go inside the case, turned out to be an excellent piece of planning (?) rather than a mistake!
So we are very pleased with the way our little endeavor is turning out, for a variety of reasons. We readily admit that we like the profits. Since we are responsible for the management of Digital Acoustics, there is some personal satisfaction in seeing the business prosper and grow. As a major stockholder in the corporation we like all of the above. And we are gratified that our thesis that the 68000 is ALSO usable in a SIMPLE system is being validated by customers placing cash on the barrelhead.
NOW THAT WE HAVE STRAINED OUR ARM patting ourselves on the back, here are the things we do NOT like about the way things are going. First, your faithful newsletter editor thinks of himself as a hardware type person. We LIKE designing new products, especially high performance ones. In recent weeks we have not had time to lay out a dynamic RAM version of the Dtack board OR a 68008 board. Or a math processor board. Or even a case for the existing board.
Why? Well, there is this newsletter. There is the 14 page information packet that had to be re-written last month. And there are the two full-page ads which we have written (only one of which has appeared in print so far). And there is the software we have been turning out. Hardware? What's hardware?
Page 13, Column 1
Something else we don't like is that we are now busy enough that we have to retract our previous promise to answer all of our mail. We DO promise to continue to answer your letters if you will adhere to these two simple rules: 1) Ask questions that have specific answers, not essay type answers. 2) Enclose an SASE. That way we can answer mail in the evening or on weekends when our secretary isn't available.
MISTAKE #8,377:
We promised last issue that we would tell you what Motorola is doing about the lack of reasonably priced 68000 software. And what Intel is doing about the lack of real, honest 8088 code. When we made that promise we thought we had a handle on Motorola's approach. But when we checked with our Motorola contacts they disagreed strongly with what we had believed.
What we DID detect in these conversations was an unease, a sense that all was not well on the software front, a sense that maybe there was a place for software for devices which were NOT incredibly complex and expensive. Yes, they know that the 68008 is NOT an appropriate engine for incredibly expensive and complex systems. Yes, they know that any software that will run on the 68000 will run on the 68008 and vice versa. Yes, they know that (largely due to their own approach to marketing the 68000) no inexpensive software exists for either the 68000 or the 68008. Yes, they sense that something is wrong...
The only positive step Motorola is taking is assembling a catalog of the various people marketing all that incredibly expensive 68000-based software.
And as far as Intel is concerned, there IS no problem!
MORE MISCELLANEAE:
There was a fine article by Robert Grappel of Hemenway Associates in the Sep. 29 '82 issue of EDN on the 16032, including comparisons to the 68000. It is possible, on the first paragraph of page 132, to get the impression that the 66000 is incapable of indexing beyond a range of +/- 32K. Actually, the 68000 can index over the full 16.7 megabyte address space, but the index value must be in a data register or in address register.
Page 13, Column 2
While the absence of MOVEQ, ADDQ and SUBQ instructions was not noted, the absence of '-(An)' and '(An)+' addressing WAS: "... there's no clean way to implement multiple stacks, which prove useful in implementing languages such as FORTH or in coding expression evaluators or macro processors." Apparently the author has not heard of HALGOL, which ALSO requires multiple stacks (we're just kidding, folks!).
BYTE WATCH II: BYTE magazine has just caught on to the fact that the 8088 is really an 8 bit machine and that it doesn't run very fast. See p.468 of the Oct '82 issue (BYTE's Bits). In that very same issue, they mention the 68000! At the bottom of page 8, we learn that "(it) has appeared in several new designs and will continue to grow in popularity based on its architecture and instruction set, both of which have been praised by programers." Perhaps some day BYTE will learn that the 68000 also runs swiftly?
DO NOT MISS THE CONTINUING DISCUSSION OF PASCAL starting near the top of page 276. For example: in the BASIC 'ON X GOTO' statement, the language defaults to the next line (or statement in some versions) if there is no line number corresponding to the value of X. For instance if X is minus three. At the top of page 277 we learn that "Pascal dumps your program. And believe it or not, the language's designers seem to think that's not a bug, but a feature."
And: "(Pascal) makes you declare all variables... (but) it does NOT require you to initialize variables, NOR DOES IT DO IT FOR YOU" (emphasis added). "...Pascal isn't very convenient; in the modern parlance, it's not really USER-FRIENDLY."
NOW LONG IS A FOOTBALL FIELD? 100 yards? WRONG! The playing surface is 120 yards long; you forgot the end zones! So what? Well, a 12.5MHz 68000 can perform a 16 bit register to register add in less time than it takes a beam of light to move the length of a football field (and you thought light traveled swiftly!). By comparison, a beam of light will travel several MILES in the time the Pet or Apples' 6502 requires to perform a 16 bit add.
And we already explained earlier in this issue that a timing analysis of our DTACK board required allowance for the finite speed of light. Fascinating subject, no? Most of you will remember hearing of a fellow named Michelson who is famous for two reasons, The first is that he is half of the team of Michelson and Morley. Those two fellows performed a famed experiment which culminated years later in E = M C squared and KABOOM! But Michelson is perhaps best known for his life-long quest to measure the speed of light with ever-increasing accuracy.
Page 14, Column 1
His last experiment involved the construction of a mile-long tube, about six feet in diameter. He then pumped the air out of the tube so that he could measure the speed of light in a (near) vacuum. This experiment was performed in the mid-1930s in a bean field on the south side of Santa Ana, California. Where is Digital Acoustics located? In a recently developed industrial area on the south side of Santa Ana which used to be a big bean field...
WE ADMIRE PERSONS WITH KEEN, LOGICAL MINDS. If you are one of those persons you should skip this item. Personally, we have trouble with conditional branches following comparisons when writing 68000 assembly code. Not with equality or inequality, those are the same as the 6502 and very easy to remember is BEQ and BNE respectively. It's those OTHER four possibilities that always cross us up. Well, always until we made this little 'crib sheet':
Branch if A > B: CMP A,B
BCS dst
Branch if A >= B: CMP A,B
BLS dst
Branch if A <= B: CMP A,B
BCC dst
Branch if A < B: CMP A,B
BHI dstThe two most common forms of comparisons are: CMP <ea>,Dn and CMPI (data),<ea>.
SOFTWARE STATUS REPORT:
We now have a very good memory test program which runs in the 68000 itself. We cribbed this one from a test written for the Wang 2200C a few years back by, we believe, Tyler Olsen of Wang Laboratories. The test will do a good job of finding 'bit pattern' problems, sometimes a problem in dynamic RAMs and also stuck address lines, sometimes a problem if you have been soldering on the Dtack board. Oh? Your solder never splashes?
This program works with a Basic program in the host. For each memory test the host calculates a random number from 1 to some limit such as 16. We call this 'N'. Then the host calculates N successive random values, each value ranging from 0 to #255. Thus, we have a string of random length composed of random values. We send the limit of memory (determined by the operator once when starting the program), N, and the random string to the 68000.
Page 14, Column 2
The 68000 copies the string repeatedly end-to-end in the remaining available memory until the limit of memory is reached. Then comes a second pass during which those copies are compared back against the original string. In general, there will be no errors, so the 68000 reports the number zero in which case both the host and the 68000 begin a new test using a different random length and a different random string. The test repeats indefinitely or until an error is detected.
If in error is detected, the address in the 68000 is stored in an error array along with the 'byte is' and 'should be' values. We limit the maximum number of errors to 20, first because of the limited number of lines on the hosts' CRT and also because if you have more than 20 errors you have BIG problems!
Because the 68000 is doing most of the work, the test runs very quickly. Which means MANY random bit patterns are tested in a reasonable time.
WE HAVE COMPLETED AND TESTED OUR DOUBLE PRECISION floating point package, 62 bits; one bit for sign, 13 for exponent, 48 bit mantissa. That provides 14.3 decimal digits precision. Here is the hexadecimal format for some common numbers:
+ ONE = $1001 8000 0000 0000
- ONE = $9001 8000 0000 0000
+ TEN = $1004 A000 0000 0000
+1/10 = $0FFD CCCC CCCC CCCDThis package will initially be used with a HALGOL matrix inversion program, The matrix inversion code has been written and will probably have been tested by the time you get this newsletter.
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II and soft: Apple Computer Co. Pet: Commodore Business Machines. DTACK GROUNDED and HALGOL: Digital Acoustics, Inc.
SUBSCRIPTIONS: You can subscribe by sending $15/6 issues U.S. and CANADA or $25/6 issues elsewhere. Tell us which issue number to begin with. Make the check out to DTACK GROUNDED. The address is:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
AS WE MENTIONED IN ISSUE #12, this newsletter will now be published at intervals (generally) greater than 1 month but hopefully not longer than two months. There's some more software and some more hardware that we want to get done...
