DTACK GROUNDED #13
September 1982
DTACK GROUNDED, The Journal of Simple 68000 Systems
Issue # 13 September 1982 Copyright Digital Acoustics, Inc
Below is a photo of our 12.5MHz minicomputer with zero wait states AND a picture of our new 68008 board (not quite in its final form!). That second big board under the 92K Dtack board is a real, working 128K expansion board. Yes, more than one expansion board can be used; but we honestly think more than 4 expansion boards makes no sense at all. In fact, consider carefully the fact that TWO 92K Dtack boards cost only a little more than one 92K Dtack board with one 128K expansion board. And you get almost as much memory and TWO of those fast, mean 12.5 MHz 68000s!
For those of you with slightly smaller aspirations, we are going to build a (slightly more polished than shown below) 68008 board that plugs inside the Apple II, just like all those other processor boards. Our initial offering will have 48K dynamic RAM if you have a 48K Apple II or II+. It will have 64K dynamic RAM if you have a 16K language card. And if you have a 16K language card plus the Cramapple, it will have 208K dynamic RAM. You see, all of the Apple's RAM will be directly addressable by the 68008.
Page 1, Column 2
In fact, the 64K address space of the Apple II will be mapped into the 32K - 96K address space of the 68008. The 68008 will have five - well, 4 1/2 - additional memory sockets. 0K to 8K will be dedicated to a 2764 EPROM. Three more sockets will each be 8K, ranging from 8K to 32K. These three sockets can hold either the 8K X 8 2764 EPROM or the 8K X 8 compatible low power static RAM which Hitachi is sampling now. And there will be one more 28 pin socket. This last one will be configured for the Toshiba masked ROM, 32K X 8 (!).
That latter ROM is strictly for high production (5000 minimum?), of course. But the part has 150nsec access and only 10 ma current drain when deselected. Since there are no 32K X 8 EPROMS around, and probably won't be for a couple of years, code in such a ROM should be reasonably secure.
Since the first 32K of the Apple memory space will be mapped into the 68008's 64K zero page, the 6502 zero page and both HIRES graphics pages can be accessed in the 68008's 64K zero page. We hasten to explain that this will not be true of 68008 boards IN GENERAL, but WE learned the trick of fixing the bug that Motorola built into their chip (which splits the zero page into two halves without hardware help) a year ago. So our board will not have that bug.
A SUMMARY: The 68008 board will have all the memory of the Apple available to it, plus whatever is on the board. The minimum on-board memory will be simply the 2764 EPROM sitting in the first 8K of the 68008 address space.
Page 2, Column 1
ABOUT THAT 1/2 SOCKET: We were generously offered the opportunity to purchase 25 of the new Hitachi 8K X 8 RAMS, for delivery late Sept, for a mere $200 each. We were offered another 25 pieces in late Oct for a mere $100 each. Instead, we are placing a redundant socket on the board mapped into the same space is one of those 3 8K sockets from 8K to 32K. This socket will accept a Toshiba 2K X 8 static RAM. When you plug an $18 8K X 8 next year, you will have to unplug the Toshiba part. This gives you the potential of having a little bit of RAM, now, separate from the Apple memory space.
SINCE YOUR APPLE DOUBTLESS has beaucoup RAM, why do we need a little RAM separate from the Apple? Because the access time of the Apple RAM is twice as slow as memory located on the 68008 board. And yes, 2764s are available in 200 and 250 nsec versions, both of which can run at 8MHz with no wait states on the VERY simple board we envision, which has no data or address buffers except between the 68008 and the Apple bus.
THE RESPONSE WE RECEIVED about our treatise on dynamic RAM was a virtually unanimous "Hey, dummy! Dynamic RAM does not either have any errors! Forget it!" Sigh.
Most of those replies arrived via phone or mail, but ONE was delivered directly by a person we will call Jack Jones because that is not his name. As it happens, we had dropped in on Jack, who is fairly well known in Apple II circles as a programmer, to demonstrate our Dtack 3-D graphics demo programs.
Jack was busy programming an application (he does this for a living) when we dropped in, so he chatted with us as he temporarily wrapped up his project. "You really blew it this time!" he stated. "I have been using my Apple for over four years now and I have NEVER had an error in ay dynamic RAM." You are indeed fortunate, we replied.
"No, I am NOT fortunate" Jack insisted, "If I had a memory problem I would certainly know about it! Now, look at this program here..." Jack gave the command 'LIST 4200-4300' and his Apple promptly barfed on the screen. We mean, the listing was a mess. "It seems we have a problem here" said Jack. He then removed his diskette and replaced it with a scratch disk. On trying to save the program, the DOS permanently went south. Sighing, Jack powered down, re-inserted the original diskette and powered up, rebooting his system.
What happened, Jack? we asked. "There is a bug in DOS 3.3 that sometimes does that. Since I back up my programs every 20 or 30 minutes, I don't really lose much code." replied Jack. How often does this happen? we asked, "It's unpredictable." Jack answered. "On rare occasion twice a day and sometimes it will not happen for a couple of months."
Page 2, Column 2
But you think it is a bug in the DOS? we asked. "That is almost certainly the cause." Jack answered. But, we pursued, software bugs react consistently to consistent inputs. The nature of the presumed bug would surely have been pinned down now considering the large number of persons using the Apple, yes?
"Look" said Jack impatiently, "a bug in the DOS is about the ONLY possible explanation for those erratic er, errors." But we have experienced the identical problem on OUR Apple(s), we replied. "See! It's a DOS bug!" Jack exclaimed.
Well, we replied, we ALSO have a Commodore 8050 dual disk drive. 2052 sectors per disk, just over a half megabyte per disk. And that is a single-sided disk. Now, the DOS resides in nice static ROM on the 8050. What little RAM is used is nice static 2114s. And we NEVER, repeat NEVER have disk errors using our 8050. In contrast, your DOS sits in dynamic RAM. Don't you suppose that might have something to do with your errors? Especially since they are highly random rather than systematic?
"Absolutely not!" replied Jack indignantly. "I just explained to you that I have NEVER had an error in my dynamic RAM. Perhaps you were not listening? Look," he continued, "I have been reading your newsletter since the beginning and although you have a few good points" (thanks a bunch, we muttered) "it is clear to me that you are totally off base when it comes to dynamic RAM."
Well heck, everyone is entitled to an occasional error. Even your faithful newsletter editor. Speaking of errors: we really did overreact two issues ago over the essential uselessness of most of those big RAM systems being grafted onto the Apple memory bus via various methods of 'bank selection'. Incompatible methods of 'bank selection', we add. We should NEVER have spit on your RAM disk emulator! We apologize to each of you and promise not to do it again (until next time).
Also, in the last issue we said the ALF/FTL advert was on page 373 of July '82 BYTE magazine. Try June.
EQUAL TIME DEPT: Following is a rebuttal to our writeup on dynamic RAM by Hal Chamberlain of MTU. As you can all see, we are totally unwilling to permit the publication of views contrary to our own in these pages. But we are willing to take this one exception because Hal has a nice first name and because he used a reasonably fresh printer ribbon. About 18 of our regular correspondents, please note.
Page 3, Column 1
THE 64K WEAKLING
Pity the poor little dynamic RAM. He's teased, ridiculed, doubted, shunned, misunderstood, and in general picked on most unfairly. He's kind of like the "egghead" you once knew in school. In other respects he's like a bottle of Listerene; he's hated but he's used. A few years ago I considered writing a long, detailed article on this topic for BYTE magazine but never went through with it. Now, since this publication has been so TERRIBLY brutal in demeaning dynamic RAMs, I am to come to their defense.
So whats the problem? Dynamic RAMs were publicly shunned long before the alpha mechanism of soft errors (which I will comment on at length shortly) was discovered. For us older engineers (those who were around in 1972-1973), it all started with the 1103 1Kx1 dynamic RAM. They were truly hard to use: +16 and +20 volt supplies, two clock inputs with critical timing, 16 volt logic swings on all inputs, and a puny output that needed an external sense amplifier! It took a good knowledge of analog circuits to design the needed drivers and receivers. The flood of engineers coming out of school at that time just couldn't cope with them. They were being taught asynchronous logic concepts and even back then, analog circuit design was becoming a lost art. On the other hand, engineers with core memory design experience had little trouble; they were much easier to drive than core planes were! Like core memories, dynamic RAMs are inherently synchronous devices. Back when I did my first 1103 memory board design, the rep for Intel just couldn't believe that the board came up in a week without any problems. In any case, the 1103 and dynamic RAMs gained a very bad reputation.
About 3 years later, in 1975, the 4K dynamic RAM (22 pin type) became readily available. These were much easier to use: only +12 and -5 supplies, just one clock, and TTL compatible I/O except for the clock. Of course they were still synchronous and the 12 volt clock driver was still a minor challenge. But this period was the beginning of the personal microcomputer age and many (most?) of today's engineers first got their feet wet then. The designer of the Altair computer (you remember the Altair, don't you?) wisely chose these 4K RAMs for the machine's large memory boards because of their very low cost and meager power consumption. But he almost delivered a knockout blow to usage of dynamic RAMs in personal computers as well because his board design didn't work! His smaller (1K) static board worked fine and 4K static boards from nearly a dozen garage operations that sprang up to meet the demand also worked. Conclusion: dynamic RAMs don't work (sample size=1) and static RAMs do work. Never mind that 2 or 3 of these static boards used up the power supply capacity whereas 16 of the dynamic boards would have left power to spare. In all fairness to the Altair's designers, they chose a bus structure that was very difficult to support properly with dynamic RAMs because it was basically asynchronous (no definite cycle time). Although the Altair's memory board problems were timing related, the mainstream engineering press also made much hay about noise problems when using scores of these RAMs on large boards. It seems that engineers were forgetting their transmission line theory as well!
Page 3, Column 2
In 1979-1986 it became practical to use 16K dynamic RAMs in microcomputers. These were easier yet to use since the clocks (back up to 2) used TTL logic levels and the inputs were designed to avoid drawing current and to withstand negative undershoots. Now you could get a "full gallon" of memory (64K) on one board and make huge add-in memory boards for minicomputers. Then came another stunning blow: some physicist somewhere discovered an inherent source of possible random errors in dynamic RAMs and it was confirmed in the lab! One could no longer assume that memory was theoretically perfect once noise, line reflections, power supply ripple, bad chips, etc. had been weeded out. Faith in the theoretical inerrancy of digital systems had been shattered! Dynamic RAMs are still reeling from this latest setback.
While these and other bad experiences may have jaded engineers who have been through the wars (and who are most likely to air their views in the media), look around you. Virtually every personal computer you see uses dynamic RAM exclusively. The only exceptions I can think of are very small machines like the AIM-65 and some S-100 users who are still in the dark ages or have lots of money to spend on memory boards and power bills. But before getting into the alpha radiation discussion, lets look at some of the other "problems" often cited when dynamic RAMs are ridiculed.
"OO-OO! But they need to be refreshed and that requires tons of extra overhead circuitry!" This is actually true when trying to design a "transparent" memory board that will be used in an undisciplined asynchronous environment such as the S-100 bus. On the other hand, most of today's personal computer designs need absolutely -ZERO- circuitry for refresh! How is that possible? Simple: any design that calls for the display generator to refresh the screen out of memory will also refresh the memory. Dynamic RAM refresh after all simply means that some location on each of the 128 rows is read every 2 milliseconds and screen refresh can certainly be arranged to do that. Also, the logic needed to resolve contention between the processor and the display generator is charged to the display cost budget, not memory cost.
Page 4, Column 1
"Yuck! Refresh is going to kill the Performance of my system!" The truth is that in nearly all cases, refresh cycles (even if they service the display) can be squeezed in between active processor cycles and thus not impact performance at all. Processors such as the 6502 and 6800/6809 make this incredibly easy with their uniform cycle timing but it can also be done with 8080/8085/Z80 class processors as well. Even when transparent refresh is not possible (such as with the 68000) the performance sacrifice need only be 1-2%. If that makes a significant differences pray you don't find a bug that slows your program down 5% to correct!
"*%&$@! You've got to do all that stupid multiplexing just to get the addresses in." OK, consider the alternative. A 16K dynamic RAM with separate addresses would need a 22 pin package and a 64K version would need a 24 pin package. 256K would go to 28 pins. With multiplexing, they all fit into 16 pin packages. Any complaints about board space used up by address multiplexors should be kept private because the larger packages would use up more space! Also when designing big memory boards you will grow to appreciate the advantage of only 8 big, noisy, power consuming address line drivers instead of 16 of the beasts.
"Dynamic RAMs are slow as molasses!" If you're doing a pipelined digital signal processor, then yes, the cycle time of dynamic RAMs is fairly slow (about 300NS at best). But when connected to a microprocessor, it is the access time that is important and that is readily available dam to 120NS. That really is fast enough to support a 12MHz 68000 and I've seen 100NS specs for one (Japanese) outfit's 64K part. It appears that as dynamic RAMs increase in size, their speed stays about the same but then much faster on large boards and multi-layer PC (=$$$) starts becoming necessary to control transmission line effects.
"Dynamic memories are terribly volatile. Just the word 'dynamic' makes me jittery." What the term "dynamic" actually means is that the circuit must be clocked constantly above some minimum rate in order to avoid information loss. This is because during some part of the clock cycle, information is stored in capacitors rather than cross-coupled flip-flops. What you may not realize is that nearly all MOS microprocessor chips, I/O chips, communications chips, and others use dynamic circuitry inside! That includes the venerated 6502 and 68000 processors. Dynamic circuitry is used in such devices because it gives tremendous design leverage in many cases. For example, a temporary holding latch can require as little as a single MOS transistor per bit if it is dynamic but will require at least 6 transistors per bit if it is static. When they are that cheap, they can be used extensively as pipeline registers to improve performance such as in the 6502 and 68000.
Page 4, Column 2
"What about alpha particles?" These errors are caused when an alpha particle (2 protons and 2 neutrons) emitted by the radioactive decay of uranium and thorium impurities in the RAM's packaging and metalization passes through a sensitive portion of the circuitry such as a memory cell. The passage of the particle knocks electrons loose and can discharge storage cells or cause peripheral circuitry noise. This is more of a problem now than in the past with 1K and 4K devices because only a few thousand electrons need to be knocked loose to cause an error due to the truly tiny storage capacitors (.05pF! ). The alpha particles do not damage the cell; they just discharge it like light would if the package was transparent. These errors are very infrequent!
How infrequent is that? The worst figure I have seen is .1% per 1000 hours which is being guaranteed by a well known manufacturer in their 64K RAM ads. Typical measured figures being brandied about in industry seminars go as low as .005%/1000 hours. Taking a typical personal computer system with 32 dynamic RAMs as an example (such as a 48K Apple with RAM card or my company's 256K Datamover 68000 board) what would the mean time between memory errors be? Using the .1%/1000 hours worst case, it comes to roughly 15,000 hours! That is 2 years at 24 hours per day or over 8 years of standard business hours! Now tell me, how many times is your system going crash because of power glitches, disk errors, static discharge, dirty connector pins, latent software bugs, operator error, or hard failure of some component during that time? Probably dozens if not hundreds of times and we are talking about only a 50/50 chance that one of those will be due to an alpha-induced error. Big deal!
Now, I'd like to tell a true story about the company where I used to work. This company was designing a very large centralized text editing system for a large newspaper. Dual PDP-10s formed the central computer which talked to numerous PDP-11/34 "terminal controllers". Inside each PDP-11 was a bus card cage which was to hold 12 terminal boards each of which had a TI9900 micro, 32K of memory, and a display generator. The workstations themselves were just keyboard/monitors connected with a single coax cable. The design of the terminal boards was well underway when the first article on alpha errors was published. The error rate calculated to one per 30,000 hours on the terminal board but somebody in management read that article and calculated in error frequency of one per week for the projected 200 terminals. That was unacceptable. So the addition of error correction was mandated. Lo and behold, the terminal micro now required two boards and therefore another card cage and power supply to be added to the PDP-11. Nobody can tell me that improved the reliability of the terminals! The system is now installed and like any large central computer, it crashes about once a day which affects all 200 terminals.
Page 5, Column 1
So, is it ever worthwhile to include error correction logic in a memory system? Probably so, particularly for a system with lots of memory that runs 24 hours a day and performs a critical function like process control. The main benefit of the error correction would be immunity against the effects of static discharge, power surges, noise, and bad chips which cause memory errors far more frequently than alpha particles. Thus I would stick to that recommendation even if the memory was static. Incidentally, I wonder if modern static RAMs with their giga-ohm load resistors in the flip-flop cells built with transistors every bit as small as dynamic RAM transistors could also be affected by alpha particles.
And what about parity? IBM computers have always used parity since day one so it is no surprise their personal computer does too. When IBM designs a computer, they first design the parity generator/detector and then they design the computer around it. I'd bet a bedfull of 68000 chips that they would have used parity even with static RAMs!
In conclusion, I think the flap about alpha particles is way overblown, particularly with respect to personal computers. Until the other causes for system malfunction can be reduced a couple of orders of magnitude, I wouldn't worry. On the other hand, the alpha phenomenon is just the beginning of a whole host of quantum mechanical effects that will become increasingly important as device size shrinks and switching energies decline. This will not only affect memory functions but will also affect logic. I suspect that when computers begin to approach the power of the human brain that their error rate may approach it as well.
WE ARE ENCOURAGED BY THE INITIAL REACTION to our introduction of the programming language HALGOL. FORTH programmers assert that it looks a great deal like FORTH, BASIC programmers say it looks like compiled BASIC (the best kind!) and we, of course, think it looks a lot like the 'language' used by the Wang model 600 programmable desk calculator. Which is to say, almost everyone has seen some good elements in the structure of the language. One or two of our readers have expressed some scepticism over how the name was selected, however. SOME people have no faith at all!
SIDEBAR: You didn't think that Wang 2200 we bought ten years ago was our FIRST computing device, did you? In the four years before then, we used, successively, a Wang 500, 520 and 600. In case you have not heard of Laboratories, their sales in the most recent fiscal year are over a billion dollars.
Page 5, Column 2
Before the Wang 500, we used a bamboo slide rule manufactured by Hemmi in Japan and marketed in this country by Post. You DO know what a 'slide rule' is, don't you?
WE HAVE JUST LEARNED that the 68008 will be sold, this year, at exactly the same price as the 68000. Which for now is $61, quantity 100. It is NEXT year that they hope to sell the part for 60 to 70% of the 68000 price. Like the second half of next year. Swell. For the same price, you get to run nearly twice as slow.
Now, we had thought the part was going to be introduced at $40 (so did a Motorola marketing exec we talked to as recently as last week). The estimated price on our projected 68008 board was based on that price. The price differential of $21 increases OUR board price about $47 and it increases the price of somebody else's board hanging in a pretty plastic package on the wall of your local computer store by $80.
This fact, plus including some on-board ROM and RAM changes our target price to $295 with absolutely no documentation or $345 WITH documentation. Since our disks are not locked, you can always copy your neighbor's disks after HE springs for $345.
But we frankly do not regard a $345 price tag (for a mail order board) as being especially attractive.
WE GET MAIL:
"...Softech Microsystems informs me that the official 4.1 system release will include the option for a 68000 adaptable P system. We will order that system as soon as it is available, step our two DTACK cards up to the 92K maximum, and proceed to install P4 on the Apple-68K combination. If that proves to be successful, I will be happy to provide both your newsletter and probably MICRO with materials describing what we are up to."
Thomas K, Lewellen, Ph.D.,
Associate Professor of Radiology
Division of Nuclear Medicine
UNIVERSITY HOSPITAL
UNIVERSITY OF WASHINGTON (Seattle WA 98195)
THE EXCELLENT BOOK "COMPUTER APPROXIMATIONS", mentioned here before, is part of "The SIAM series in applied mathematics." We saw a reference in a recent article which leads us to believe that there is a related (SIAM) periodical publication. Could some reader provide more information, including subscription info?
Page 6, Column 1
OFF THE EDGE OF THE CLIFF: The list price of the 68000L12 has just dropped from $332 quantity one to $111 quantity 100! (It seems only yesterday that the L12 made its debut on the published price list at $489, quantity one ONLY.) And Toshiba has dropped their prices further since issue #9. So, forthwith, this new price list. Be advised that we are retaining the 8MHZ prices ONLY as a service for those idiots who have told us that price is EVERYTHING (who needs to run fast?). If YOU have any sense, chum, you will go for the 12.5MHz column PROVIDED 100NSEC RAM IS AVAILABLE. We are worried that when those bigger companies who cannot shift gears as quickly as we can catch on, there MAY be occasional shortages of the faster RAM.
DTACK GROUNDED PRICING: CLK 8MHz 11MHz 12.5MHz RAM 150NS 150NS 100NS 4K $595 $679 $683 12K $627 $711 $723 28K $691 $775 $803 60K $819 $903 $963 92K $947 $1031 $1123
In the list above, 'CLK' means the clock speed of the board. The 8MHz board uses the 8MHz 68000 and the 11 and 12.5 MHz boards both use the 12.5 MHz 68000, whose part number is MC68000L12. (The 'L12' instead of 'L12.5' bothers the heck out of our contact at Hamilton Electro Sales, by the way. Don't worry about it; the L12 is a legitimate 12 1/2 MHz part.) Eleven MHz is as fast as our main board and expansion board will run with 150nsec RAM. When using the more expensive 100nsec RAM our board is in principle capable of running faster than 12.5MHz WHEN FASTER 68000s ARE AVAILABLE.
You will have noticed that we no longer list the option of selling the board less the 68000. We will extend until Sept. 30 '82 the right to buy such a board on an individually negotiated price; after that we will not sell boards less the 68000, period.
Our 128K expansion board is selling in very small quantities right now; we have only sold eleven as this is written, all to the same customer. So we have not achieved much in the way of 'economy of scale' yet. For now, we are selling the board ONLY in its fully loaded form; $995 with 100nsec RAM and $867 with 150nsec RAM. The latter board will run reliably up to 11MHZ.
REMEMBER THE GOOD OLD DAYS, when an 8MHz 68000 with zero wait states was hot stuff? No, we will NOT accept your 8MHz board as a trade-in on the faster job. But we WILL upgrade your board to 11 or 12.5MHz (depending on what RAM is in your board) for $200 plus shipping. You get to KEEP the 68000L8; we have absolutely no use for same.
Page 6, Column 2
THIS IS THE WAY IT IS: We have somehow found ourselves in the minicomputer business. Most of the people who are buying our boards are buying them for pure speed. So we are going to concentrate on building the fastest doggone 68000 boards you ever saw, at an attractive price. We are still maintaining the 'single price' concept, though. So YOU can buy at the same price as an OEM. And at the same terms.
So it is only fair to tell you that we will knock $63 off our DTACK (not expansion!) price if you can take delivery of the board with ABSOLUTELY NO DOCUMENTATION. No manual, no disk(s), no follow-up documentation. Most true OEMs don't want or need such. We thought you ought to know; we are an equal opportunity seller.
You may be interested to know that the OEM who bought the eleven expansion boards paid 10% down, the balance C.O.D. We really, honestly, have a single price list and a single sales policy. This fact shocks a lot of people, by the way. It is interesting to note that we have had a lot fewer outraged reactions lately from would-be board purchasers. Apparently the companies who want to buy boards have an employee somewhere who has read our newsletter, and most of our readers are beginning to catch on that we are absolutely serious about our (purposely unusual) sales policy.
DO NOT ORDER AN 11MHz BOARD OR UPGRADE YET! Eleven MHz is an odd crystal frequency and we have been given a 4 to 6 week delivery schedule. Be sure to check with us before ordering,
NOW THAT WE HAVE A SHORT DELAY in re the dynamic RAM version of our board, we have a few possibilities to discuss. 'Discuss' implies a bidirectional conversation; your input is invited.
A) Should the board use the 68008 rather than the 68000? That would permit a minimum configuration of 64K, dropping the price for the minimum configuration by $100 to perhaps $675 - $695. The maximum configuration would be 256K. (Once 256K chips arrive on the scene, like next year, that could be a 1 megabyte board!
B) Maybe we put a nice parallel Centronics printer interface on the board so we can have a 1 megabyte printer buffer next year? (That suggestion is intended seriously!)
C) Perhaps price is NOT everything? Perhaps we need to use a smallish 100nsec static RAM section with NO wait states (a sort of 'cache') and then up to 256K dynamic RAM with wait states? This is, of course, definitely NOT a minimum price configuration, But it DOES combine speed now with a 1 megabyte memory next year. If you vote for this option, WHAT SIZE should that 'cache' be? (We understand that that famous non-introduced 68000 model has a 4K (words or bytes?) 'cache'. We think maybe 16K bytes, but what do YOU think?
Page 7, Column 1
D) Maybe we need a 64K (max) dynamic RAM version that plugs inside the Apple? Even though our initial 68008 board will be able to access ALL of the memory in the Apple, including those 256K boards and the Cramapple? We really need no such board, of course, but the computer hobbyists, rock shooting division, have gone ga-ga over those 64K RAM chips. They are ordering printer buffers with 64K RAM, ice cream cones with 64K RAM and if we are going to build a 68008 board, we get an absolutely perfect knee-jerk reaction: "It has to have 64K RAM!"
By the way, our 64K printer buffer from QUADRAM has arrived!
Although there have been several books available on the 68000, you will have noted that we have not recommended any of them to you. Up to now they have ranged from so-so to TERRIBLE. But we have just spent several hours with the new book by Leo Scanlon: "THE 68000: PRINCIPLES AND PROGRAMMING", Howard W. Sams & Co., 1981. This is a good book.
Most books on microprocessors are understandably written when they are new and therefore the author is naturally not intimately familiar with the instruction set. As a result, the examples of assembly language code are often non-optimum. (In one 68000 book, the examples appear to be poor translations of 8008 code. The result is hilarious if you are an experienced 68000 programmer and bewildering if you are a novice trying to learn.)
Perhaps the orderly, logical and efficient nature of the examples given in the Scanlon book is a result of its late entry into the marketplace. If you have a real as opposed to passing interest in the 68000, you should buy this book.
We suspect that you should also start subscribing to MICRO Magazine (not the IEEE publication). Beginning with the September issue, they will be covering the 68000 regularly. The Sept. issue will feature an introduction to the architecture (registers and such), the first of a series of articles on the instruction set AND (get this) How To Use The 68000 To Enhance Your 6502. We are eagerly looking forward to reading that last article! Maybe we will learn something?
(We hope that last paragraph did not sound too snide. Many researchers examining a specified technical subject will always come up with a lot more useful information than just one.)
Page 7, Column 2
THE INCREDIBLE SOFTWARE GAP:
It is increasingly obvious that there is an ENORMOUS gap between the actual state of 16 bit software versus the expectations of the AVERAGE computer user. This is true whether one talks about the 8086/8 or the 68000/8. It turns out that only a little bit of the code in the IBM PC has been rewritten from 8080 code. It's the floating point code that has been changed, mainly, And the changes have LOTS of bugs. The '.1/10 = .001' bug is only one of MANY bugs in the math package of the IBM PC. For more details, see "The Bug That Ate Boca Raton" in the premier issue of the IBM edition of Softalk magazine.
8086/8 summary: there is very little true 16 bit code available and what IS available has bugs.
If you want to know the state of 68000 software, walk into any Radio Shack store and ask to see a demonstration of the Model 16. The will promptly load some Z80 code for you. Say that you want to see 68000 code and guess what? They don't have any. None. Zip. Heck, Dtack has more 68000 code than that!
Now, let us compare this state of affairs to the expectations of the AVERAGE computer user. The average computer user probably cannot write a program. If he miraculously has somehow learned to program in BASIC he doesn't want to. And he has come to expect literally tens of thousands of application programs to be available for his computer. Now that is simply an unrealistic attitude early in the life of a new processor. However, the problem is really MUCH WORSE than that!
You see, both Intel and Motorola have consciously and deliberately adopted policies which prevent development of 16 bit software for personal computers. They did not do this accidentally; they did it after calm, careful planning. Although both companies have been enormously successful at preventing development of software for personal computers using their products, they achieved their objective by different means. (We have explained this to you before, of course, but recent developments in both companies have intensified the problem.)
Intel cleverly assured that no real 16 bit software would be developed for the 8086/8 by retaining the architecture of the 8080 and also the instruction set of the 8080 in the 8086/8. They did this to assure that each and every instruction in the 8080 had a direct counterpart in the new devices and so code could be directly translated from the 8080 to the 8086. It is our guess that Intel intended this as a temporary solution until real 16 bit software could be written.
Page 8, Column 1
The temporary solution has turned out to be PERMANENT. As a result, there is some VERY nasty fighting going on inside Intel right now. We will tell you about the infighting later. Here is why the temporary solution is permanent:
Let us suppose that a manufacturer of an 8088 based personal computer (read IBM) steps inside his friendly local software supermarket (read Microsoft). "I'd like to have a nice FORTRAN compiler for my 8088 machine" states the manufacturer. "Fine. The price will be X dollars and you can pick it up tomorrow afternoon after 2PM" replies the software vendor.
"That fast? Say, that wouldn't be translated 8080 code, would it?" asks the manufacturer. "I see that you have taken your smart pills today!" congratulates the software vendor.
"But I want real 8088 code. Surely real 8088 code will outperform translated 8080 code?" "Yep. By a factor of three to four."
"In that case, I certainly DO want real 8088 code. What is your price and delivery for a real 8088 FORTRAN compiler?" "That will be 10X dollars, 12 to 15 months. But remember, the initial releases will assuredly have a few bugs. A major software package of that size on a new CPU always does."
"10X DOLLARS? 12 to 15 MONTHS?" shrieks the manufacturer. "You have GOT to be kidding! We absolutely HAVE to have that code within 6 months!" "It costs more for a crash development program; say, 20X bucks. And there will be a few more bugs under a crash program; there always are" admits the software vendor.
"I can't believe this! How did you ever develop that original package, the one that doesn't have any bugs?" asks the manufacturer. "Well, at the time of our initial release back in 1976 there weren't any alternatives. And back in 1976 the package HAD bugs. Now, there IS an alternative. You can have the slow cheap one now with no bugs, or the fast expensive one next year WITH bugs."
"That's no alternative!" snorts the manufacturer. "I'll be in at 3PM tomorrow to pick up my 8080, er, 8088 FORTRAN compiler."
THE VERY NEXT MORNING, who should walk into the software supermarket but Chuck Peddle, former Commodore guru (VERY BRIEFLY Apple guru) and current SIRIUS and Victor guru and holder of sizeable stock options. Chuck addresses the software vendor thusly: "My good man, I should like to obtain a FORTRAN compiler for my 8088 based computer." The software vendor explains the options, and Chuck ponders for a while.
Page 8, Column 2
"Well, I think we have to have the high performance package. We are aiming the SIRIUS at the serious business user; I feel the long term advantages outweigh the obvious short term disadvantages" decides Chuck.
"Very good!" exclaims the software vendor. "It is a pleasure to do business with a man who is willing to consider the long range perspective rather than grab the easy short range benefits. By the way," he adds, "IBM is picking up their FORTRAN compiler at 3PM this afternoon."
"WHAT? WE ARE COMPETING HEAD TO HEAD WITH THOSE (expletive deleted)! I can't let them get a FULL YEAR lead on us!" exclaims Chuck. "I'll have TWO packages ready at 3PM" replies the vendor soothingly.
AND THAT SCENARIO, dear friends, is intended to explain that price, delivery and competitive pressures are preventing the development of real 8086/8 software. The well-publicized bugs in the IBM PC (which are really due to Microsoft's BASIC interpreter; the Victor machine has them too, we understand) are not going to help the matter any.
SO THERE IT IS. There is very little extant 8086/8 software and there is very little being developed. The real world being the way it is, not such will EVER be developed unless all the warehouses holding the debugged (and depreciated!) 8080 code burn down.
While the general marketplace has not analyzed this situation thoroughly, there is an unease developing among the more knowledgeable persons in the personal computer field as to the performance of those 8088 machines. "I know it has a 16 bit internal structure. And I know it has hardware multiply/divide. It MUST be a lot faster. But every time I put a stopwatch on an application program I'd swear there was an 8080 in there!" One is beginning to hear musings of that nature more frequently.
"But this problem will soon be fixed, right? We mean, Intel is sampling the 80186 now and they are planning to have 80286 samples soon. The 80286 in particular is going to be a truly high performance part." Yes and no. Both those chips maintain the 8080 downward compatibility at considerable sacrifice of potential performance (assuming Intel built a real computer, not an 8080 emulator). The choices that will be available will be the same choices that are available for the 8088 and those warehouses haven't burned down yet.
Page 9, Column 1
Imagine the sort of word-of-mouth that the initial buyers of 80286-based personal computers are going to provide when they learn their machine is less than twice as fast as a garden-variety Z80! A recent article in Electronic News was headlined "The 68000 Gathers Momentum." One industry observer was quoted in the article thusly: "I don't see so such of an increase in 68000 momentum. What I see is a diminution of interest in the 8086." Guess why.
RIP! BASH! SNARL! TEAR!
These are the sounds emanating from Intel's council chambers these days. An explanation:
If you have just returned from a year's stay on the planet Zorn, you will be surprised to learn that the iAPX 432, which had been intended to carry Intel's high performance banner, is now seriously dead. With customers angrily demanding an upward migration path within the Intel family to compete with the forthcoming Motorola 32 bit machine (and even the forthcoming National 32 bit machine), Intel hurriedly announced THEIR 32 bit microprocessor. Several weeks AFTER that hurried announcement, they decided the part number would be the iAPX 386. So far, the part number is ALL that is definite about that device,
You see, there is one hellaceaus fight going on between the performance faction in Intel, who want to build a real computer (NOT an 8080 emulator) for a change and the compatibility faction, who have their gaze fixed on those warehouses (not one of which has burned down yet).
You have heard the Motorola story before, too. But new developments on the Motorola side of the fence justify this repetition:
Motorola developed the 68000 to go out and slay PDP11/70s. They also developed the 6809 for price sensitive applications such as personal computers. And NEVER, they asserted, shall the twain meet.
We have reported previously about the briefing we received in early Aug. '81, over a year ago, at the Motorola sales offices in Orange County. You will recall that we had had our prototype SIMPLE 68000 board up and running with our CBM 8032 for nearly two months at the time, and had our 'hooks' to the floating point routines working for a month.
The talk covered both the 68000 and the 6809 and the software similarities between them. It also emphasized the ENORMOUS price and performance differential. We were told in no uncertain terms: "While the price of the 68000 will undoubtedly drop some, it will NEVER be a cheap part. The price will probably NEVER drop below $50." It naturally followed that no one was to use the part for any other purpose than building complex, high performance systems.
Page 9, Column 2
Now, the fellow who said that knows a heck of a lot about registers, addressing modes and exception processing but he gets the dunce cap for his economic prognostications. We have been in electronics since 1954, and we have been watching semiconductor prices drop since about 1957. They haven't stopped dropping yet. We had already, a month earlier, decided to market our simple board for use with the Pet and the Apple. If the Motorola types had known of our plans, your faithful newsletter editor would probably have been tossed out of their offices without benefit of the elevator (their offices are on the fifth floor).
As we recall, we did not even snicker when that price prediction was made. Well, exactly a year after that meeting the official Motorola PUBLISHED price list has the 68000L8 at $61. The negotiated price for larger quantities is now WAY less than $50!
HOW DID MOTOROLA MISS THE MARK so badly? You will not have read this here before; since they were building a 'minicomputer on a chip' they naturally went out and hired some minicomputer types rather than take the time to train their existing personnel about minicomputers. For some reason we do not understand (we say with tongue in cheek) those minicomputer types somehow overlooked the potential of using that enormously expensive, enormously complex 64 pin chip in a personal computer!
With the word being spread that the 68000 was a wonderful minicomputer, only those software types who traditionally write packages for minicomputers bothered learning about the 68000 or writing software for it. The fact that Motorola was charging $30,000 for a software development station as a condition of even having their chip saleperson TALK to you did not help.
Yes, software DOES exist for the 68000. For $1500. For $2500. For $3500... In other words, for the traditional minicomputer single-CPU license fees. Which means there is virtually NOTHING available for us personal computer types or for other cost sensitive applications. THAT IS A GREAT BIG MISTAKE BY MOTOROLA!
BUT WE NOW HAVE IN OUR POSSESSION a real, working 68008 (actually, we received it three days before we mailed newsletter #12). Friends: the 68008 is NOT repeat NOT a device to slay the PDP11/70 with. It is NOT intended exclusively for enormously complex systems. The 68008 is an ideal candidate to build a Trash 68 around. Using a punk keyboard and a lousy CRT with poorer 'graphics'. Incredibly simplistic BASIC language (level 1/3). Audio cassette program storage; price under $800.
Page 10, Column 1
The 68008 is in fact a POLITICAL microprocessor. Let us explain that. First, the part has exactly the same instruction set (and hence microcode) as the 68000. It has exactly the same number of registers and the registers have the same length, 32 bits. Aside from some multiplexing circuitry added, plus the fact that only 20 address lines are brought out to the outside world, the 68008 is essentially identical to the 68000 IN TERMS OF PRODUCTION COST (true, the 48 pin package is very slightly cheaper than that big 64 pin package). So, naturally, the price is essentially the same?
NOPE. The 68008, we are told, will be priced at 60 to 70% of equivalent 68000 models. Which means that Motorola will either be taking a loss on the 68008 or a larger-than-accustomed profit on the 68000. Intel has been doing exactly the same thing with the 8088 for some time, so don't be surprised.
WHAT, WE ASK YOU, is the essential software difference between the 68000 and the 68008? We answer: there ain't no difference. So we have a nice, inexpensive, simple processor which can naturally be built into nice inexpensive computing devices and take advantage of all that nice inexpensive software that has been developed in the past two years, right? WRONG! There IS no inexpensive software; the 68000 is exclusively a minicomputer, remember?
Motorola therefore has a gigantic marketing problem. How does one explain that, say, BASIC interpreters for the 68000 should be priced at $2500/CPU but the same software for the 68008 should be priced at $29.95? When the software is IDENTICAL?
HERE ARE THE FACTS AS WE SEE THEN: Motorola did a great many things RIGHT in their overall 68000 game plan. Using a non-multiplexed data/address bus was a major correct decision. In fact, we have just realized that if we list all the right decisions that Motorola made, we will not be able to afford to print this newsletter. Let us instead concentrate upon the two OTHER mistakes Motorola made.
MOTOROLA MISTAKE #2: There is a very minor goof in the design of the hardware aspect of the 68000. This involves the 'sign extend' problem which splits the 64K zero page into two 32K portions, making the upper 32K portion potentially unusable. Fortunately this mistake can be corrected by about three 40 cent LSTTL chips. Oddly enough, it appears that Dtack Grounded is the only company to identify this problem and correct it in hardware. Even the first production prototypes of the Dtack board had this fix.
Page 10, Column 2
MOTOROLA MISTAKE #3: Motorola neglected to send a simple directive to their chip salesmen. As a result there are a whole lot of people who would have liked to use the 68000 who are NOT using the 68000 today. Here is how, and why, this happened:
Motorola has two classes of salesmen involved with the 68000. One class, in theory, only sells those big 64 pin ceramic packages called the 68000. Nowadays the 68008 is added, of course. We will call this class the 'chip salesmen' and will name a hypothetical member of this class "Chip". The other class only sells the $28,900 turkey called the 'EXORMACS'. These are the systems boys; we will name a hypothetical member of this class "Cy".
We will now quote from issue #2, page 8 of this newsletter: "If you want to see the rapidly receding back of a Motorola 68000 product specialist, refuse to buy his $28000 minicomputer!" How can this be? After all, the chip salesman has no responsibility to sell that minicomputer, right? WRONG! This is the way the real world works:
Chip and Cy are both employed by Motorola. Both have offices on that fifth floor, almost opposite each other. The men's lounge (you ex-Navy types: the head) is just a couple of doors down from both offices.
Chip encounters a potential customer (such as your faithful newsletter editor). The potential customer expresses enormous enthusiasm over the performance of the 68000 (we did!). Chip then states that it will be impossible to develop a 68000 system unless one invests in a $28,900 EXORMACS. The potential customer (that's us!) asserts that this is not in accordance with the facts and declines to purchase that $28,900 turkey. Does Chip continue to help the potential customer, suggesting alternate methods of developing 68000 systems which do not involve spending $28,900? NO! Chip rapidly strides away from the potential 68000 customer (that's us!), providing an excellent view of his back.
Why did this happen (it did!)? Why did Chip fail to help the enthusiastic potential 68000 customer find alternate methods of developing 68000 systems which did not involve the purchase of the EXORMACS? Particularly since the historical evidence shows that it is possible to build 68000 systems WITHOUT buying the EXORMACS.
THE ANSWER, DEAR FRIENDS, IS SIMPLE. If Chip had any means of suggesting that it was possible to develop 68000 systems WITHOUT purchasing an EXORMACS he would surely have kept the matter to himself. Suppose the contrary: suppose after the potential customer refused to buy the EXORMACS that the chip salesman (Chip, remember?) had suggested alternate development methods. (Today these alternate methods include buying a Dtack board and a Phase Zero cross-assembler.)
Page 11, Column 1
Here is what would have happened: on the next occasion that Chip walked into the men's lounge he would have been quickly followed by Cy. A white-knuckle, bared-teeth confrontation would have ensued. Cy: "We both work for the same company. Your paycheck, and mine, both say Motorola. We are, or should be, on the same team. YOU GOT THAT, CHIP? WE SHOULD BE ON THE SAME TEAM! Chip, I get a bonus for every EXORMACS I sell. The more bonuses I get the more pork chops and the less spaghetti my family eat. My son is eleven years old; I'd like to be able to put him through college when that time comes. YOU ARE TAKING FOOD OUT OF MY FAMILY'S MOUTH!"
Chip is not stupid; he can figure out this scenario for himself. That's why the scenario NEVER HAPPENED. What we saw was what we reported: the rapidly receding back of a Motorola salesman.
NEXT ISSUE:
Next issue we will discuss what Intel, Motorola and the systems manufacturers who use their microprocessors are doing about the lack of real 16 bit software.
We hope our readers will continue to keep in mind that you will not find pronouncements from Olympus (or even the Fountainhead) in these pages. We present here opinions which are hopefully of interest and are hopefully presented in an entertaining manner.
Some of the material in our last issue, and a lot MORE in THIS issue, is at a very low intellectual level. This his been done deliberately. It is currently popular to consider the two sides of the brain as having differing functions. Logical thinking has been assigned to one side; emotional thinking the other. Much of the rather simplistic material has been fashioned by us to (hopefully) address the emotional side of YOUR brain!
Almost all of our readers own or have used personal computers such as the Apple, Pet, Atari, etc, and are fully aware how useful these products can be. It is simply not, in any way, logical to consider these devices useless, laughable and beneath contempt. And yet the vast majority of persons with minicomputer backgrounds hold those opinions exactly. Logic? No. Emotion? YES!
Page 11, Column 2
The last four pages (appx) could have been covered, very logically, in one or two paragraphs. Which would have been a mistake because the problems are not logical, they are emotional. When Motorola introduced the 68000 the minicomputer boys they hired asserted that the device could be used to manufacture complex systems which could successfully compete with high performance minicomputers such as the PDP11/70 (true). They then asserted that since the 68000 had that capability it should be used EXCLUSIVELY in complex, high performance applications. Those of you who needed simpler devices (such as the computing heart of a personal computer having, get this: 64K RAM, a keyboard, CRT, dual disk drives and a printer) would please buy a low performance 6809 and go away and leave us minicomputer types alone. This is logical?
BY THE WAY:
We happened to pass by the 6809 marketing window last week and it was boarded up. The grass needed mowing and there were weeds in the flower bed. That's odd, we didn't even hear the window slam shut.
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II and soft: Apple Computer Co. Pet: Commodore Business Machines. PDP11/70: Digital Equipment Co. 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
IN THIS MONTH'S REDLANDS we have the complete listing of a floating point print routine. The routine assumes that the 6502 in the host has been programmed to accept $FF as a command to print a string until $00 is received, indicating the end of the string. We assert that this is a complex task; if you think this task is simple you are either much too smart or such too stupid to be reading this newsletter.
Included are subroutines which compare the floating point accumulator with a number in memory, print a string from memory, insert a character into a string, multiply the floating point accumulator by 10 very quickly, convert a 32 bit binary number into an ASCII string (Apple division with D7 = 1) ending with a null, find the end of a string terminated by a null and even an integer print routine, which is separate from the more general floating point print routine.
Now, what is the difference between such a routine written for HALGOL and the same routine written for BASIC? The HALGOL routine ends with JMP (A4) while the BASIC routine ends with RTS (those of you who require assistance making this conversion please apply elsewhere). So you can see that supporting HALGOL does not mean that we have turned our back on a 68000 BASIC.
Code Listing
1 OPT P=68000,BRS,FRS
002116 2 ORG $002116
3 ;
4 ; QUICK MULTIPLY OF FPACC1 BY 10
5 ;
002116 5638 1903 6 FPX10 ADDQ.B #3,X1 ;X1 = X1 +3
00211A 2238 1904 7 MOVE.L M1,D1 ;MANT1 TO D1
00211E 3438 1908 8 MOVE.W G1,D2 ;GUARD TO D2
002122 2601 9 MOVE.L D1,D3 ;MANT1 TO D3
002124 3802 10 MOVE.W D2,D4 ;GUARD TO D4
11 ;
002126 E289 12 LSR.L #1,D1
002128 E252 13 ROXR.W #1,D2
00212A E289 14 LSR.L #1,D1
00212C E252 15 ROXR.W #1,D2
16 ;
00212E D444 17 ADD.W D4,D2
002130 D383 18 ADDX.L D3,D1
002132 64 08 19 BCC FPX10X ;EXIT IF NO OVFL
20 ;
002134 E291 21 ROXR.L #1,D1
002136 E252 22 ROXR.W #1,D2
002138 5238 1903 23 ADDQ.B #1,X1
24 ;
00213C 21C1 1904 25 FPX10X MOVE.L D1,M1 ;RESTORE MANT1
002140 31C2 1908 26 MOVE.W D2,G1 ;RESTORE GUARD
002144 4E75 27 RTS ;DONE
28 ;
002146 307C 3000 29 INIT MOVE.W #$3000,A0
00214A 3248 30 MOVE.W A0,A1
00214C 303C 0100 31 MOVE.W #$0100,D0
002150 4298 32 INIT1 CLR.L (A0)+
002152 5340 33 SUBQ.W #1,D0
002154 66 FA 34 BNE INIT1
002156 4ED4 35 JMP (A4)
36 ;
37 ; TAKE THE INTEGER OF THE ACCUMULATOR
38 ;
002158 70 81 39 INT MOVEQ #$81,D0
00215A 1438 1903 40 MOVE.B X1,D2 ;EXP1 TO D2
00215E B002 41 CMP.B D2,D0 ;COMPARE
002160 65 06 42 BCS INT1 ;OKAY IF >= $81
43 ;
002162 42B8 1904 44 CLR.L M1 ;ZERO THE MANTISSA
002166 4ED4 45 JMP (A4) ;RETURN TO HALGOL
46 ;
002168 70 A0 47 INT1 MOVEQ #$A0,D0
00216A 9002 48 SUB.B D2,D0 ;D0 = $A0-EXP1
00216C 2238 1904 49 MOVE.L M1,D1 ;FETCH MANT1
002170 E0A9 50 LSR.L D0,D1 ;SHIFT IT RIGHT
002172 21C1 1904 51 MOVE.L D1,M1 ;STORE RESULT
002176 4ED4 52 JMP (A4) ;RETURN TO HALGOL
53 ;
002178 4EB8 1570 54 FRAC JSR ROUND ;ROUND FPACC1
00217C 31C0 1902 55 MOVE.W D0,S1 ;RESTORE S1, X1
002180 21C1 1904 56 MOVE.L D1,M1 ;RESTORE MANT1
002184 4278 1908 57 CLR.W G1 ;CLEAR THE GUARD
002188 4EB8 16EA 58 JSR FRACTN ;CALC FRACTION
00218C 4ED4 59 JMP (A4) ;RETURN TO HALGOL
60 ;
61 ; COMPARE FPACC WITH FP# IN MEMORY
62 ;
63 ; IF FPACC IS GREATER, N=0 (BPL FPACC>MEM)
64 ; IF FPACC IS LESS, N=1 (BMI FPACC<MEM)
65 ; IF FPACC IS SAME (INC GUARD), Z=1
66 ;
67 ; COMPARISON IS MADE WITH ASSUMED GUARD
68 ; OF $7F FOR FP# IN MEMORY.
69 ;
00218E 70 80 70 CPFP1M MOVEQ #$80,D0
002190 72 80 71 MOVEQ #$80,D1
002192 C018 72 AND.B (A0)+,D0 ;MEMSIGN TO D0
002194 C238 1902 73 AND.B S1,D1 ;FPACC SIGN TO D1
002198 B001 74 CMP.B D1,D0 ;COMPARE SIGNS
00219A 66 1A 75 BNE NOTEQL ;DONE IF NOT SAME
76 ;
00219C 1001 77 MOVE.B D1,D0 ;BOTH SIGNS NE?
00219E 6B 18 78 BMI NEGCMP ;BRANCH IF NEG
79 ;
0021A0 1038 1903 80 MOVE.B X1,D0
0021A4 B018 81 CMP.B (A0)+,D0 ;COMPARE EXP'S
0021A6 66 0E 82 BNE NOTEQL ;DONE IF NOT SAME
83 ;
0021A8 2038 1904 84 MOVE.L M1,D0
0021AC B090 85 CMP.L (A0),D0 ;COMPARE MANTS
0021AE 66 06 86 BNE NOTEQL ;DONE IF NOT SAME
87 ;
88 ; ASSUME GUARD #2 IS $7F & COMPARE GUARDS
89 ;
0021B0 0C38 007F 1908 90 CMPI.B #$7F,G1 ;COMPARE GUARDS
0021B6 4E75 91 NOTEQL RTS ;DONE
92 ;
0021B8 1018 93 NEGCMP MOVE.B (A0)+,D0
0021BA B038 1903 94 CMP.B X1,D0 ;COMPARE EXPONENTS
0021BE 66 F6 95 BNE NOTEQL ;DONE IF NOT EQUAL
96 ;
0021C0 2010 97 MOVE.L (A0),D0
0021C2 B0B8 1904 98 CMP.L M1,D0 ;COMPARE MANTS
0021C6 66 EE 99 BNE NOTEQL ;DONE IF NOT EQUAL
100 ;
0021C8 70 7F 101 MOVEQ #$7F,D0 ;ASSUME G2 IS $7F
0021CA B038 1908 102 CMP.B G1,D0 ;COMPARE GUARDS
0021CE 4E75 103 RTS ;DONE
104 ;
105 ; THIS ROUTINE IS USED FOR TIMING PURPOSES ONLY
106 ;
0021D0 70 31 107 TIMING MOVEQ #49,D0 ;SET FOR 100 WORDS
0021D2 3A7C 7000 108 MOVE.W #$7000,A5 ;ADDR = 28K
0021D6 2A80 109 TLOOP MOVE.L D0,(A5) ;STORE 2 WORDS
0021D8 51C8 FFFC 110 DBF D0,TLOOP ;LOOP 50 TIMES
0021DC 4ED4 111 JMP (A4) ;RETURN TO HALGOL
112 ;
113 ; PRINT A ZERO !
114 ;
0021DE 1AC7 115 PRTZER MOVE.B D7,(A5)+ ;LAST CHAR
0021E0 4215 116 CLR.B (A5) ;$00 IS END OF STR
117 ;
118 ; PRINT THE STRING AND RETURN TO HALGOL
119 ;
0021E2 4EB8 234E 120 PRNTIT JSR PRSTRM ;PRINT STR FROM MEM
0021E6 4ED4 121 JMP (A4) ;RETURN FROM HALGOL
122 ;
123 ; THIS ROUTINE PRINTS A FLOATING POINT NUMBER
124 ; AS AN ASCII STRING
125 ;
0021E8 3A7C 1932 126 PRINT MOVE.W #STR,A5 ;SET PTR A5 TO STR
0021EC 7E A0 127 MOVEQ #$A0,D7 ;D7 = SPACE
0021EE 1C38 1902 128 MOVE.B S1,D6 ;TEST SIGN
0021F2 6A 02 129 BPL PR1 ;SKIP IF POS
130 ;
0021F4 7E AD 131 MOVEQ #$AD,D7 ;"-" TO D7
0021F6 1AC7 132 PR1 MOVE.B D7,(A5)+ ;ASCII TO STR
0021F8 4238 1902 133 CLR.B S1 ;SET SIGN POS
0021FC 7E B0 134 MOVEQ #$B0,D7 ;"0" TO D7
0021FE 1C38 1903 135 MOVE.B X1,D6 ;TEST EXPONENT
002202 67 DA 136 BEQ PRTZER ;SKIP IF ZERO
137 ;
002204 4205 138 CLR.B D5 ;SET BCD EXP = 0
002206 0C06 0080 139 CMPI.B #$80,D6 ;CMP X1, $80
00220A 67 02 140 BEQ EXPIS0 ;SKIP IF X1 = 0
141 ;
00220C 64 0A 142 BCC EXPGT0 ;SKIP IF X1>0
143 ;
00220E 307C 2348 144 EXPIS0 MOVE.W #ONEE9,A0 ;PTR TO 1*10E9
002212 4EB8 1332 145 JSR FPMUL ;MULT & ADJ BCDX
002216 7A F7 146 MOVEQ #$F7,D5
147 ;
002218 11C5 1922 148 EXPGT0 MOVE.B D5,BCDX ;STORE BCDX
149 ;
00221C 307C 2342 150 NRMFP MOVE.W #HISTN,A0 ;LARGEST #
002220 4EB8 218E 151 JSR CPFP1M ;COMP TO FPACC1
002224 67 2E 152 BEQ FIXFP ;DONE IF EQUAL
002226 6A 16 153 BPL DIV10 ;X/10 IF GREATER
154 ;
002228 307C 233C 155 NRMFP1 MOVE.W #LOWSTN,A0 ;SMALLEST N
00222C 4EB8 218E 156 JSR CPFP1M ;COMP TO FPACC1
002230 67 02 157 BEQ MUL10 ;MULT BY 10 IF EQ
002232 6A 18 158 BPL RNDFP ;DONE IF GREATER
159 ;
002234 4EB8 2116 160 MUL10 JSR FPX10 ;MULT FPACC1 BY 10
002238 5338 1922 161 SUBQ.B #1,BCDX ;DECR BCDX
00223C 60 EA 162 BRA NRMFP1 ;CONTINUE
163 ;
00223E 307C 2336 164 DIV10 MOVE.W #TENTH,A0 ;PTR TO 1/10
002242 4EB8 1332 165 JSR FPMUL ;DIVIDE BY 10
002246 5238 1922 166 ADDQ.B #1,BCDX ;INCR BCDX
00224A 66 D0 167 BNE NRMFP ;DO NOT LOOP IF 0
168 ;
169 ;
00224C 307C 2330 170 RNDFP MOVE.W #HALF,A0 ;PTR TO 1/2
002250 4EB8 1218 171 JSR FPADD ;ROUND UP
172 ;
002254 2238 1904 173 FIXFP MOVE.L M1,D1 ;MANT1 TO D1
002258 74 A0 174 MOVEQ #$A0,D2
00225A 9438 1903 175 SUB.B X1,D2 ;SUBTR X1 FROM $A0
00225E E4A9 176 LSR.L D2,D1 ;SH D1 R BY D2
002260 4EB8 22F0 177 JSR BINASC ;CONVERT D1 TO ASC
002264 60 36 178 BRA FORMAT ;FORMAT AND PRINT
179 ;
180 ; FIND THE END OF THE STRING
181 ;
002266 3A7C 1932 182 FNDEND MOVE.W #STR,A5 ;POINT A5 AT START
00226A 141D 183 FNDE1 MOVE.B (A5)+,D2 ;FETCH CURR CHAR
00226C 66 FC 184 BNE FNDE1 ;LOOP UNTIL NULL
185 ;
00226E 534D 186 ISTRX SUBQ #1,A5 ;CORRECT POINTER A5
002270 4E75 187 RTS
188 ;
189 ; INSERT A DECIMAL INTO THE STRING
190 ;
002272 7E AE 191 DISTR MOVEQ #$AE,D7 ;"." TO D7
002274 61 12 192 BSR ISTR ;INSERT THE DECIMAL
002276 7A B0 193 MOVEQ #$B0,D5 ;"0" TO D5
194 ;
002278 1C25 195 KTR1 MOVE.B -(A5),D6 ;FETCH LAST CHAR
00227A BC05 196 CMP.B D5,D6 ;ZERO?
00227C 66 04 197 BNE KTR2 ;SKIP IF NOT
198 ;
00227E 4215 199 CLR.B (A5) ;REPLACE ZER W/NULL
002280 60 F6 200 BRA KTR1 ;REPEAT TILL DONE
201 ;
002282 64 02 202 KTR2 BCC KTRX ;SKIP IF NOT DEC
002284 4215 203 CLR.B (A5) ;CLEAR DECIMAL
002286 4E75 204 KTRX RTS ;DEC INSERTED, RTN
205 ;
206 ;
207 ; INSERT A CHARACTER INTO THE STRING
208 ;
002288 3A7C 1933 209 ISTR MOVE.W #STR+1,A5 ;STR+1 ADDR TO A5
00228C 4242 210 CLR.W D2 ;CLEAR UPPER BYTE
00228E 1400 211 MOVE.B D0,D2 ;UPPER BYTE CLEARED
002290 DAC2 212 ADD.W D2,A5 ;ADD TO STR PTR
213 ;
002292 1C15 214 ISTR1 MOVE.B (A5),D6 ;FETCH OLD CHAR
002294 1AC7 215 MOVE.B D7,(A5)+ ;STORE NEW CHAR
002296 67 D6 216 BEQ ISTRX ;DONE IF $00 (NULL)
217 ;
002298 1E06 218 MOVE.B D6,D7 ;OLD CHAR TO NEW
00229A 60 F6 219 BRA ISTR1 ;RPT TO END (NULL)
220 ;
221 ; FORMAT AND PRINT THE STRING AND EXPONENT
222 ;
00229C 1038 1922 223 FORMAT MOVE.B BCDX,D0 ;RECALL BCD EXP
0022A0 0600 0009 224 ADDI.B #9,D0 ;CORRECT THE EXP
0022A4 6B 1A 225 BMI NEGX ;NEGATIVE EXP
0022A6 66 06 226 BNE POSX ;POSITIVE EXP
227 ;
0022A8 61 C8 228 ZERX BSR DISTR ;INSERT DEC IN STR
0022AA 4EF8 21E2 229 ZERX1 JMP PRNTIT ;PRINT STR; EXIT
230 ;
0022AE 0C00 0009 231 POSX CMPI.B #9,D0 ;COMPARE BCDX TO 9
0022B2 67 F6 232 BEQ ZERX1 ;PRINT STR IF 9
0022B4 65 F2 233 BCS ZERX ;INSERT DEC IF LESS
234 ;
235 ; EXPONENT IS OVER NINE, USE EXPONENT FORM
236 ;
0022B6 61 20 237 BSR SUBEXP ;PUT E IN STR
0022B8 5303 238 SUBQ.B #1,D3 ;CORRECT THE EXP
0022BA 1203 239 MOVE.B D3,D1 ;SET TO PRNT EXP
0022BC 61 38 240 ENDEXP BSR CONV ;CONVERT BIN TO ASC
0022BE 60 EA 241 BRA ZERX1 ;PRINT IT
242 ;
243 ; THE EXPONENT IS NEGATIVE
244 ;
0022C0 5200 245 NEGX ADDQ.B #1,D0 ;ZERO IF EXP = -2
0022C2 67 0C 246 BEQ MINTWO ;PRT .0XXXX
247 ;
248 ; EXPONENT IS < -2, USE EXPONENT FORM
249 ;
0022C4 61 12 250 BSR SUBEXP ;PLACE E IN STR
0022C6 7E AD 251 MOVEQ #$AD,D7 ;"-" TO D7
0022C8 61 C8 252 BSR ISTR1 ;ADD MINUS TO END
0022CA 72 02 253 MOVEQ #2,D1 ;#2 TO D1
0022CC 9203 254 SUB.B D3,D1 ;EXP = ABS(EXP)+1
0022CE 60 EC 255 BRA ENDEXP ;EXIT VIA ENDEXP
256 ;
0022D0 7E B0 257 MINTWO MOVEQ #$B0,D7 ;"0" TO D7
0022D2 61 B4 258 BSR ISTR ;INSERT 0 IN FRONT
259 ;
0022D4 4240 260 MINONE CLR D0 ;SET D0 = 0
0022D6 60 D0 261 BRA ZERX ;INSERT DEC & PRNT
262 ;
263 ; SUBROUTINE; SET UP FOR PRINTING EXP FORM
264 ;
0022D8 1600 265 SUBEXP MOVE.B D0,D3 ;SAVE EXP IN D3
0022DA 70 01 266 MOVEQ #1,D0 ;SET FOR 1 INTEGER
0022DC 61 94 267 BSR DISTR ;INSERT DEC IN STR
0022DE 4EB8 2266 268 JSR FNDEND ;FIND END OF STR
0022E2 7E C5 269 MOVEQ #$C5,D7 ;"E" TO D7
0022E4 61 AC 270 BSR ISTR1 ;ADD E TO END
0022E6 4281 271 CLR.L D1 ;CLEAR D1, 32 BITS
0022E8 70 01 272 MOVEQ #1,D0 ;SET FOR 2 LOOPS
0022EA 307C 2328 273 MOVE.W #BATBL+28,A0 ;PTR TO LAST 2 K'S
0022EE 4E75 274 RTS ;SUBROUTINE DONE
275 ;
276 ; CONVERT A 32 BIT BINARY WORD TO A NUMERIC
277 ; ASCII STRING, 999,999,999 MAXIMUM.
278 ;
0022F0 70 08 279 BINASC MOVEQ #8,D0 ;SET FOR 9 LOOPS
0022F2 307C 230C 280 MOVE.W #BATBL,A0 ;PTR TO TABLE
281 ;
282 ; MAIN LOOP; PERFORM THIS LOOP 9 TIMES
283 ;
0022F6 2A18 284 CONV MOVE.L (A0)+,D5 ;GET K(N)
0022F8 7E AF 285 MOVEQ #$AF,D7 ;"0"-1 TO D7
286 ;
287 ; SUBTRACT THE CONSTANT UNTIL UNDERFLOW OCCURS
288 ;
0022FA 5207 289 BALOOP ADDQ.B #1,D7 ;INCR ASCII
0022FC 9285 290 SUB.L D5,D1 ;D5=K, D1=MANT
0022FE 64 FA 291 BCC BALOOP ;LOOP UNTIL OVFL
292 ;
293 ; ADD THE CONSTANT BACK TO CORRECT THE UNDERFLOW
294 ;
002300 D285 295 ADD.L D5,D1
002302 1AC7 296 MOVE.B D7,(A5)+ ;STORE ASCII
002304 51C8 FFF0 297 DBF D0,CONV ;LOOP 9 TIMES
298 ;
002308 4215 299 CLR.B (A5) ;LAST CHAR IS NULL
00230A 4E75 300 RTS ;BIN TO ASC IS DONE
301 ;
302 ; CONSTANTS FOR CONVERTING BINARY TO ASCII
303 ;
00230C 05F5E100 304 BATBL DC.L 100000000
002310 00989680 305 DC.L 10000000
002314 000F4240 306 DC.L 1000000
002318 000186A0 307 DC.L 100000
00231C 00002710 308 DC.L 10000
002320 000003E8 309 DC.L 1000
002324 00000064 310 DC.L 100
002328 0000000A 311 DC.L 10
00232C 00000001 312 DC.L 1
313 ;
002330 0080 314 HALF DC.W $0080 ;FP 1/2
002332 80000000 315 DC.L $80000000
316 ;
002336 007D 317 TENTH DC.W $007D
002338 CCCCCCCD 318 DC.L $CCCCCCCD
319 ;
00233C 009B 320 LOWSTN DC.W $009B ;99,999,999.9
00233E BEBC1FFD 321 DC.L $BEBC1FFD
322 ;
002342 009E 323 HISTN DC.W $009E ;999,999,999
002344 EE6B27FD 324 DC.L $EE6B27FD
325 ;
002348 009E 326 ONEE9 DC.W $009E ;1 * 10E9
00234A EE6B2800 327 DC.L $EE6B2800
328 ;
329 ; PRINT A STRING FROM MEMORY
330 ;
00234E 3A7C 1932 331 PRSTRM MOVE.W #STR,A5 ;POINT A5 AT STR
332 ;
002352 7E FF 333 MOVEQ #255,D7
002354 61 08 334 BSR OUTCHR ;XMIT PRINT COMMAND
335 ;
336 ; HERE IS THE MAIN LOOP TO OUTPUT THE STRING
337 ;
002356 1E1D 338 OUTSTR MOVE.B (A5)+,D7 ;GET CHAR
002358 67 0A 339 BEQ OUTCH ;END IF NULL
340 ;
00235A 61 08 341 BSR OUTCH ;OUTPUT THE CHAR
00235C 60 F8 342 BRA OUTSTR ;CONTINUE
343 ;
344 ; SUBROUTINE; OUTPUT A CHAR TO HOST
345 ;
00235E 7C 06 346 OUTCHR MOVEQ #6,D6 ;SET UP D6 AND A0
002360 307C 0FFA 347 MOVE.W #STATUS,A0 ;FOR OUTPUT
348 ;
002364 0D10 349 OUTCH BTST D6,(A0) ;HOST READY?
002366 66 FC 350 BNE OUTCH ;WAIT TIL HOST RDY
351 ;
002368 1087 352 MOVE.B D7,(A0) ;XMIT A BYTE
00236A 4E75 353 RTS ;RETURN
354 ;
355 ; INTEGER PRINT A 32 BIT BINARY WORD TO THE HOST
356 ;
00236C 7E A0 357 IPRINT MOVEQ #$A0,D7 ;" " TO D7
00236E 61 EE 358 BSR OUTCHR ;OUTPUT A SPACE
002370 2238 1904 359 MOVE.L M1,D1 ;MANT1 TO D1
002374 66 06 360 BNE IPR1 ;SKIP IF NOT ZERO
361 ;
002376 7E B0 362 MOVEQ #$B0,D7 ;"0" TO D7
002378 61 EA 363 BSR OUTCH ;OUTPUT A ZERO
00237A 4ED4 364 JMP (A4) ;RETURN TO HALGOL
365 ;
00237C 70 09 366 IPR1 MOVEQ #9,D0 ;SET FOR 9 LOOPS
00237E 3A7C 230C 367 MOVE.W #BATBL,A5 ;PTR TO TABLE
368 ;
002382 5300 369 IPR2 SUBQ.B #1,D0 ;DECR LOOP COUNT
002384 2A1D 370 MOVE.L (A5)+,D5 ;FETCH CONSTANT K
002386 B245 371 CMP.W D5,D1 ;COMPARE K, MANT1
002388 65 F8 372 BCS IPR2 ;LOOP TIL NOT ZER
00238A 60 02 373 BRA IPR4 ;UNCOND JUMP
374 ;
00238C 2A1D 375 IPR3 MOVE.L (A5)+,D5 ;GET NEXT K
00238E 7E AF 376 IPR4 MOVEQ #$AF,D7 ;"0"-1 TO D7
377 ;
002390 5207 378 IPR5 ADDQ.B #1,D7 ;INCR ASCII
002392 9285 379 SUB.L D5,D1 ;D5=K, D1=MANT1
002394 64 FA 380 BCC IPR5 ;LOOP UNTIL OVLF
381 ;
002396 D285 382 ADD.L D5,D1 ;CORR UNDFLW
002398 61 CA 383 BSR OUTCH ;XMIT ASCII
00239A 51C8 FFF0 384 DBF D0,IPR3 ;LOOP UP TO 9 TIMES
385 ;
00239E 4ED4 386 JMP (A4) ;RETURN TO HALGOL
387 ;
388 ;
# 00001218 389 FPADD EQU $001218
# 00001332 390 FPMUL EQU $001332
# 00001570 391 ROUND EQU $001570
# 000016EA 392 FRACTN EQU $0016EA
393 ;
# 00001902 394 S1 EQU $001902
# 00001903 395 X1 EQU $001903
# 00001904 396 M1 EQU $001904
# 00001908 397 G1 EQU $001908
# 00001922 398 BCDX EQU $001922
# 00001932 399 STR EQU $001932
400 ;
# 00000FFA 401 STATUS EQU $000FFA