Issue # 38 DTACK GROUNDED Newsletter - January 1985
IT'S CHECKBOOK TIME !
This issue is the LAST issue which about 500 of our 700+ subscribers are going to receive. So YOU are probably included in that group. Look for a number 38 on your mailing label - there it is, right? What that means is, we will not mail the next issue, #39, to you unless you send us a negotiable token of your esteem.
(Let's see: if all 500 of you re-up, 500 times $15 plus a few $25 checks is, ummm... lots and lots of Heineken Special Dark!)
THE LATEST FARM REPORT:
(You may remember Luigi and his donkey wagon loaded with leeks and garlic (front page of issue #21, Jul '83). Well, Lulgi is once again interested in a nice new Maserati...)
"I have finally determined that I must retire my ass!" Luigi informs the salesman. "Donkey, Luigi, call him a donkey! Otherwise folk might get the wrong idea!" rejoins the Maserati salesman, adding "Long time no see! I trust your produce business is prospering?" (A good salesman always qualifies his customer!)
"Yes, but my er, donkey is getting old. He can't haul a full load of leeks and garlic to town like he used to. And I think I am ready to move up to a more modern conveyance such as one of your shiny new cars. Besides, Anna" - here Luigi, who is of somewhat short stature if the truth be known, squinted up at the salesman - "has said that she would prefer to ride in a Maserati than a donkey cart!"
"Ho ho! Would that by any chance be the Anna who is secretary to the vice president of the bank you patronize?" asked the salesman, grinning. "The very one. You can see how I could use a nice Maserati?" Luigi modestly replied. "I have these few simple requirements..." UH OH, thought the salesman.
Page 1, Column 2
More RISC stuff, p.2. Disk Efficiency, p.2. Personal UNIX, p.4. Operating systems, pp5-7. More than you ever wanted to know about DOSs, in excruciating detail, pp7-14. Mail call, p.15. IBM watch, p.19. Synertek stuff, p.20. MICRO folds, p.21. 3-holer boards, p.21. DRAM glut, p.22. Atari, p.24. Apple hardware, p.26.
"My prospective new car must fit into the stall where I now keep my er, donkey. That is one meter wide by four long. My new car must use the same fuel as the donkey, for I have much stockpiled. That means oats, carrots, and other vegetables - many of which I grow myself" Luigi pointed out. "What I am really after is the obvious benefits of modern transportation while maintaining compatibility with the old model."
"But, Luigi!" protested the salesman. "That makes no sense at all! Everybody knows that a modern automobile cannot use the same 'fuel' as, as a DONKEY!" he spluttered.
Luigi was firm. "I have much time, money and experience invested in my er, donkey and the cart. While I am certainly interested in more modern transportation I must obtain it in a way that makes sense to me and is familiar to me. And I must not lose the use of the substantial stores of fuel I have saved up for my old mode of transportation. Nor do I wish to devise new and different means of storage. And that means that I MUST OBTAIN A COMPATIBLE AUTOMOBILE! Who," Luigi asked rhetorically, "could deny the obvious benefits of compatibility?"
The Maserati salesman covered his eyes and moaned, "But any modern transportation that was compatible with your donkey cart would most assuredly have many of the limitations of that donkey cart. What you need is a firm break, a new beginning, using the most modern of transportation methods! And that is necessarily incompatible!"
"No!" replied Luigi, standing his ground. "I will not purchase an automobile which is not compatible!"
"Luigi, will you get your ass out of here?" the salesman demanded.
As we did in issue #21, your FNE wishes to remind you that we are not stating that you are like that farmer with the donkey cart, just because you think that a new high-performance DOS must be compatible with DOS 3.3 or other DOSs based on (and limited by) 8-bit micros. No, we would never assert that you were like the farmer...
Page 2, Column 1
RISKY RISCS:
The June '84 issue of Computer Architecture News, the ACM SIGARCH publication, contained two short papers on RISCs. We passed over them quickly when we first received that issue. After what we published in the last issue, we thought we would go back and review those papers more carefully.
Ho, ho, ho!
One of the papers was by Daniel Tabak of Boston University. He considers the limits to which a computer instruction set can be reduced. If we have zero instructions, he points out, then we have no computer. Therefore, the smallest possible instruction set for practical purposes is ONE! One of the worthwhile attributes of a single-instruction computer is that no assembler is needed. He and a colleague at Ben Gurion University in Israel actually constructed such an 'ULTIMATE RISC'. The one instruction chosen is CMOVE, which is a conditional move. Tabak calls this 'ultimate RISC' a SIC (Single Instruction Computer).
Tabak continues, "It can be argued that a SIC is a boundary case of RISC after the instruction set reducing process has reached the limit of a single instruction... We have, on the one hand, a 32-instruction RISC and on the other hand, a SIC with a single instruction. Both could be regarded as being, loosely speaking, on the two edges of a 'Reduced Instruction Set Computer Space' (RISCS). A natural question can now arise: what about the computer space in between? What are the properties of RISC-type computers whose instruction sizes have been further reduced, below 32, but have not yet reached the ultimate limit of a single instruction?"
Tabak's colleague at Ben Gurion University has a companion paper outlining the MODHEL microcomputer model for the purpose of investigating the effectiveness of RISCs whose instruction set complexity is intermediate between the 32-bit RISC and the single-instruction SIC. He points out: "The modularity of this computer consists in the fact that its instruction set it subdivided into subsets of instructions, or instruction modules." If you have not caught on by now that Tabak & Co. are doing a number on the RISC you should read that last sentence again and note that the 68000 meets the definition of a RISC "[with an] instruction set subdivided into sets of instructions, or instruction modules."
The material in Computer Architecture News was reprinted from the EUROMICRO Journal. We have not been able to determine whether the originals were originally published on April 1.
JIM STRASMA WATCH:
Jim is the editor of Midnite, the PET/CBM-related publication. He has also more recently been writing a column for RUN, the PET games publication with 200,000 readers. (It is simply amazing how many folks like to shoot rocks.) Considering what we wrote on P.23 of the last issue, a couple of items from the latest Midnite may be of interest:
"...when I was a youth, I dreamed of being popular, like my friends who had people calling them all the time. Now I have two phones, and it's common for both to ring at once. Be careful what you ask for -- you may get it!" (p.1)
And: "A persistent gripe we hear from people who write some companies for help is that their letters are ignored... I'm developing more and more sympathy for such companies. ...(questions) that require extensive reference on topics not dear to me may never get properly answered. Kitchen sink letters (those which ask about everything but the kitchen sink) are especially vulnerable..." (p.5)
What's this? Jim Strasma doesn't answer all his mail? Wait until Peter R. hears about this! (Jim, I hope you understand that we are on YOUR side this time - FNE)
DISK EFFICIENCY:
The very next issue of InfoWorld (17 Dec) that arrived after we mailed our last issue ran a letter on p.56 from Hall Chamberlin, who may be related to MTU's Hal Chamberlin. Hall asserts that folks who write DOSs should try for fast throughput, not just make things work, however slowly (shades of DOS 3.3 text files!). Specifically, he points out that the RANA Systems Super Mini-Floppy Disk Drive comes with a backup program which requires 15 times longer than necessary. We are in agreement with Hall. In fact, Blue Sky Report in our last issue was really an examination of how fast it might be possible to make a DOS run when transferring large files. And we are now (3 Dec) writing a 'trial DOS' based on DOS 3.3 in which the Apple host stands in for a fast disk to examine the practical software-related problems of running a fast DOS. Too bad this is a tiny, obscure newsletter in an 'out', quiet backwater or Hall might learn what WE are doing.
In a somewhat related matter, the Dec issue of IEEE SPECTRUM carries a 'Design case History: Apple's Mackintosh'. This article includes the following quotation, which is attributed to Burrell Smith: 'In other computers, the disk controller is a brick wall between the disk and the CPU, and you end up with a poor-performance, expensive disk that you can lose control of... Instead of a wimpy little 8-bit
Page 3, Column 1
microprocessor out there, [Mackintosh has] this incredible 68000 - it's the world's best disk controller.' (p.38)
We are not convinced that Burrell was quoted accurately, or, if the quote WAS accurate, that he was correct. We are now using the 68000 in conjunction with a Western Digital floppy disk controller and it works great, no problems at all and we are getting a large-file data throughput which is right at the limits imposed by the hardware. Here is what we think Burrell meant:
If you buy a disk controller subassembly (board) from XEBEC, Western Digital etc. that board will ALWAYS have an 8-bit Z-80 on it! ALWAYS! And the throughput is very definitely limited - SEVERELY limited - by that darn 8-bit Z-80. Why not use an 8MHz plastic 68000 from Hitachi (15 bucks each/100) instead? Our guess is folks either don't know how to program the 68000 or how to interface it to a Z-80. Or else we get back to 'Hall' Chamberlin's complaint: folks just don't seem to care whether their hardware runs efficiently!
(Those disk controller boards we were referring to are primarily Winchester controllers but they also control any floppies - and sometimes tape drives - that are connected to the system. And that ubiquitous Z-80 is a real DOG by 68000 standards.)
Yes, we do know that the Mackintosh uses the 'Woz chip' a la the Apple II - but the 'Woz chip' is just another floppy disk controller. As we have seen, that chip runs as fast as ANY 1MHz 6502 is going to run - but it does put more of a software strain on the back of the CPU than one of those Western Digital floppy controller chips. The same thing applies to the Mack's DOS - it is fast using the 68000, just not very flexible - like the Apple II before it.
DESIGN PURITY ?
That same SPECTRUM article mentions "...an intense and almost religious argument about the purity of the system's design versus the user's freedom to configure the system as he liked." Obviously, 'purity of design' won out, which is a real shame. Doesn't Apple realize it could have had it both ways? It would have been trivially simple to include a switch (hardware or software) that would turn off that damn over-complex user interface and let ordinary programmers transport ordinary programs to the Mack.
Some publications are now talking up as A VERY GOOD THING the inability of typical hackers (vs. well-financed corporations) to write commercial programs for Mack. By keeping out the riff-raff, the reasoning goes, the available software will be of better quality
Page 3, Column 2
on average (and $250 on average for EACH program). We wonder if Apple remembers that Dan Bricklen, VisiCalc's originator, was once counted among the riff-raff? And that Apple made an ENORMOUS amount of money off the folks who bought Apples so they could run VisiCalc?
MORE SPECTRUM:
That same (Dec) issue carried an article titled "How Andrew Kay manages". We looked for a while for the tag "to lose many millions of dollars' worth of inventory" but they left that off. However, on p.71 we find that Kaypro acknowledged "a substantial possibility that the loss may reach or exceed [the several million dollars reported in the press]".
Kaypro, which is now a publicly-traded company, is overdue on its audited annual report which will, of course, reveal the extent of those inventory losses. At the moment (3 Dec) we do not even know whether the inventory shortfall is due to inventory which once actually existed but was light-fingered by socially unintegrated miscreants or whether some person or persons simply posted inventory on the books which never physically existed.
[The next day the L.A. Times reported that Kaypro expected to report writedowns for missing inventory 'and other adjustments' that could total as much as $10 million. Kaypro also asked the SEC to postpone its deadline for annual independently-audited financial filings for two weeks, to 15 Dec.]
MORE MONEY WOES:
Columbia Data Products, once one of the foremost IBM PC clone-makers, just reported a loss of $28.6 million on sales of $0.39 million in its most recent fiscal quarter. Yes, you read that correctly - Columbia's losses equaled 7,333% of sales!
Somehow, we just can't work up much sympathy for an outfit which tried to make a career of selling somebody else's computer design.
NOSTRADAMUS DEPT:
Remember that open letter to Bob Tripp a couple of issues back? When we wrote it we had forgotten our own little item on p.3 of issue #31, which clearly and accurately predicts MICRO'S ridiculous attack on the Stellation 68008 board. See par 3, col 2. By the way, it's Jim 'Hinds', not 'Hines'. Sorry, Jim.
A while back, we predicted the demise of the middle manager. The 29 Nov WSJ had THREE feature stories on the front page of its second section about the ongoing demise of the middle manager and white-collar worker!
Page 4, Column 1
DEPT OF TRUE FACTS:
T.I. is boasting that its briefcase-size portable is the first with an 8087. This will prove of great interest to GRID, whose briefcase-size COMPASS portable has featured an 8087 as standard equipment for over two years now.
Nearly a year ago, Amiga demo'd its 'Lorraine' computer at the Chicago Comdex. What they REALLY showed was a mockup with a minicomputer sitting out of sight doing the actual work. At the Nov Las Vegas Comdex, they showed [no kidding, now] some SLIDES which purportedly were generated on a 'Lorraine' (InfoWorld 10 Dec p.21). SLIDES?
Some other companies are beginning to offer optional 16081 math processors with their 68000 machines. We are looking at p.13 of one of their catalogs right now, and see that this option will perform '7500 to 48,000 multiples per second - 17,000 is typical'. It is good to know that 17,000 multiples per second are typical, but we do have this one question: what is a 'multiple'?
ADVANCE TO THE REAR:
Micropro has been paying its bills for years with WordStar, the ancient assembly-based word processor. They now have a program which they hope will succeed WordStar (succeed in two senses) called 'WordStar 2000'. Naturally, this successor is written in (what else?) 'C'! (Maybe they located that legendary 'C' compiler with only a 2 to 1 HLL overhead?)
POPULARITY POLL:
A number of articles in various magazines have noted that a certain male track star of the L.A. Olympic Games has been unable to cash in on his success. It seems that no American firms want him to help boost their image. None of the articles have been able to suggest a reason for this.
Well, just the other weekend we were having lunch at the St. Catherine Hotel on Catalina Island with Judge Crater and this male track star's girl friend. (The menu featured roast breast of great auk.) His girl friend couldn't suggest any reason for his inability to cash in, either. Big, big mystery...
PERSONAL UNIX:
The Dec issue of UNIX REVIEW features a series of articles on the general subject of 'LOW COST PERSONAL UNIX'. One of the featured articles is a lengthy interview with Bob Marsh of Onyx. It is quite a coincidence that this came out shortly after
Page 4, Column 2
InfoWorld's cover issue on the same subject, especially since Bob Marsh was also extensively quoted in the InfoWorld issue.
Well, Bob asserts that UNIX is not going to replace MS-DOS in the PC market. He points out that the user communicates with the CPU via an RS-232 'pipe' and that means no graphics or 'windows'. Later he says, 'Whoa! UNIX is, after all, a $1 billion market!' That happens to be true - combine all companies, combine the hardware and software, and what you have is, for real, a billion dollar per year market.
By way of comparison, Commodore International sells more than one billion dollars each year just in hardware. That's one company, hardware only.
The Apple Computer Company now sells more than one billion dollars a year just in hardware. That's another company, hardware only.
IBM does not release detailed sales breakdowns of individual product areas, but many observers think they are selling $3 billion worth of PCs (various models) per year now. That means the total UNIX market, all companies, hardware and software, is a THIRD the size of just ONE company's PC hardware sales. Whoopee?
(Some of the other articles in Dec UNIX REVIEW claim UNIX IS going to make it big in personal computers, doubtless starting tomorrow. And Bob Marsh asserts, on p. 39, that a megabyte of memory chips can be bought for about $150. WHERE, Bob? The side deal you had going with Tattoo at the Fantasy Island distributor is null and void on account of Tattoo demanded too big a raise and so he doesn't work there any more.)
If there is any doubt in your mind, one way or the other, about whether you and UNIX are destined to make beautiful music together as soon as hardware prices drop just a bit more, you should make an effort to locate and read the Dec issue of UNIX REVIEW. While most of the authors in that issue are under the impression that they are outlining the changes which have to occur in the UNIX world to accommodate the mass market, they are in fact presenting detailed proof that UNIX ain't gonna make it in that market.
Second to the interview with Bob Marsh, who openly asserts that UNIX is NEVER gonna make it in the PC world (and Bob's company makes UNIX boxes!), we enjoyed Rob Warnock's article beginning on p.26. In reverse order Rob points out why unexpandable boxes are always a lot cheaper than expandable ones (this is a point which we have not been able to get over to most of you readers), extolls the benefits of megabyte ROMs (where have we heard THAT one before?), and explains the fundamental, root problem of UNIX.
Page 5, Column 1
The root problem is that as soon as you hang a second user on a given CPU then it is necessary to protect the CPU from both of those users. That is, we cannot have user B's terminal go dead because user A is loading a large disk file. Therefore, the CPU cannot load that large file! No, sir! We have to have specialized disk controllers and DMA so that the CPU goes on working while the big file is being loaded. The same thing applies to ALL I/O, naturally. Nobody seems to stop and notice that 8MHz 68000s are now available off the shelf for just $15/100 (Hitachi plastic). Just how much are we going to spend to protect that $15 chip? Why not give each user his or her own $15 chip?
Later in this issue we will expand on our idea begun in the last issue of loading large files quickly using the new high-density floppies from Japan. We will do that USING THE CPU, without DMA or a CPU-Independent controller (using a #%$&*@ Z-80 to slow things down!). How un-UNIXish! Of course, if you want to load a quarter-megabyte file, your 'terminal' will go dead for about six seconds.
[It is refreshing to see a note of reality finally reaching even UNIX REVIEW, which was the last cheerleading holdout of the UNIX-related publications. True, UNIX REVIEW continues to wear rose-tinted lenses while gazing at reality...]
JOHNNY ONE-NOTE:
In the past year, this rag has turned into Johnny One-Note. There appears to be only one party line, and that line is, of course, the line favored by your FNE. Believe it or not, we have tried to avoid that!
A typical scenario follows: we receive a letter from a computer professional who is obviously involved in the minicomputer world. The letter will always lecture us about 80%-20% (or 90%-10%), the virtues of virtual memory and concurrency and the economics of supporting several users with just one CPU. We write back pointing out that our newsletter is directed to persons who buy their own computer using their own funds for their own personal use. We then invite a submittal explaining how virtual memory and concurrency and such can benefit the persons to whom this newsletter is directed. AND THEN WE NEVER HEAR FROM THEM AGAIN! (This scenario has been repeated a half-dozen times in the past year.)
Why is this? Do these minicomputer types recoil in horror when they learn that we are really serious about using the highest performance micro available and assIgning 100% of the power of that micro to just one user and just one task? Do they think that someone who would do something so stupid is beneath notice? Or do they just belatedly recognize that we are not in the
Page 5, Column 2
OEM/discount/multluser/vertical market/VAR business, and direct their attention elsewhere (like towards Mini-Micro Systems)?
OPPOSITION WELCOMED!
If they think that we will not present an opposing viewpoint in these pages, they are wrong. We do not feel we have a personal conduit to some repository of universal truths! What we DO have are some opinions based on experience, observation or just reasoning. Do YOU have a better idea? A better idea for those persons purchasing their own computer for their own use using their own funds? Then TELL us about it - we'd like to hear, and so would our other readers.
TIGHTLY FOCUSSED VIEWS:
(We have received a few submittals lately which did not get published. The reason is simple: they covered too many subjects. The correct number of subjects to be covered in a guest editorial is ONE. If you want to write about nine different subjects, go start your own newsletter - as Jeff H., for instance, has.)
If YOU think this rag has a single party line, do YOU bear part of the responsibility for that?
OPERATING SYSTEMS.
COMPUTERWORLD EXTRA, the 14 Nov edition, has an article by Rod Coleman, Stride Micro (formerly Sage) prexy, on operating systems. Rod notes that there really isn't a good 16-bit micro operating system. He asserts:
"MS-DOS performs well but falls behind miserably in rapport; the P-system has good rapport and excellent portability, but suffers tragically in performance; and A T & T's UNIX possesses great capacity but little else.
"Clearly, a major breakthrough in operating systems has yet to emerge." (p.27) By using the term 'rapport', meanIng rapport between operating system and user, Rod appears to be sidestepping the phrase 'user friendly', which has become discredited. Let's examine those brief quotes:
Rod says MS-DOS performs well. Naturally; it is written in assembly. He says that the P-system suffers tragically in performance. Naturally; it is written in a high-level language. We don't understand what Rod means by asserting that UNIX has 'great capacity', perhaps that is a reference to the big fast hard disk UNIX just HAS to have to work in an acceptable manner?
But we have to take exception to his claim that the P-system has good rapport. When others refer to running
Page 6, Column 1
that operating system as like "kicking a dead whale along the beach" they are NOT referring to "good rapport". (Rod, if you and we agreed on everything one of us would be unnecessary - and we'd miss you!)
Incidentally, do not miss the Stride Micro ad on p.276 of Dec Byte. As you can see, Stride has pretty much abandoned the single-user personal computer crowd and is looking for lots of sheep to chain to its new multi-user systems, which can concurrently service the combined populations of Luxembourg and San Marino. Sharing CPU cycles is something else we disagree with Rod about - assuming that ad really reflects his personal opinions.
However, Rod's article in COMPUTERWORLD EXTRA implicitly assumes that it is possible to find the one perfect operating system for all micro-based computers. We have a lot of trouble with that assumption.
WHAT'S A GOOD SYSTEM ?
OPERATING system, that is. As we pointed out in issue #10, over 2 1/2 years ago, it is not possible to produce ONE universally suitable operating system. On page 2 we neatly divided the user universe into eight groups with decidedly differing requirements. IN REAL LIFE THINGS ARE NOT THAT SIMPLE!
In fact, UNIX is the perfect operating system for SOME persons. Those persons are full time computer professionals who have the time, intelligence and dedication required to learn and use UNIX AND - this is important - mostly work on character-based stuff which does not require complex scientific calculations and hence can tolerate sharing CPU cycles. Uh - just exactly how many persons in the U.S. fit that description? Do you see a mass market here?
So the obvious answer to "what operating system is going to take over the future micro universe?" is, NONE OF THE ABOVE! A universally applicable operating system is a pipe dream, a boojum.
Instead of a universal operating system, which is analogous to the pot of gold at the end of the rainbow, we need to discuss what sort of operating system will fill lots of peoples' needs best. "Lots of people" brings us back to the mass personal computer marketplace and the happy, smiling customer walking out of a computer store with his or her own personal computer, intended exclusively for his or her own personal use and paid for with his or her own personal funds. We can immediately toss out multiuser operating systems and we can also toss out what most folk call multitasking operating systems, the ones which need hardware memory management. (The hardware memory management is too costly physically and in time.)
Page 6, Column 2
We can toss out the operating systems which cost $17,500 (various minicomputer) or $3,500 (unemasculated UNIX) or $1,000 (Pick, PC/IX) or $600 (P-system) or $350 (CP/68K). Try $60. The mass marketplace will stand still for $60.
We can toss out the operating systems written in a high level language. The mass-marketplace will not stand for that inefficiency. You don't believe us? Look around! Compare assembly-based CP/M, MS-DOS and PC-DOS to the P-system and C-based CP/68K. (Pick is assembly-based but is inherently multi-user and is also somewhat expensive. If Digital Acoustics needed a multi-user system, we would look closely at some 68000-based systems which support PICK - such as the ones marketed by CIE.
As we have mentioned before, we are rapidly coming up on the personal-computer multimegabyte memory era, and micros with segmented memories are not going to make it as single-user CPUs. Nor are operating systems based on 64K segments such as MS-DOS. What this all means is that the most popular mass-market operating system for three or four years down the road does not yet exist. (You know, the personal-computer multimegabyte memory era is coming up faster than we had earlier expected. Four years might be too long a time frame.)
A DIGRESSION: December FORTUNE magazine, the one with the cover story on IBM's aggressive domination of its market, has another story on the new generation of 32-bit micros. Remember Jean Claude Cornet, whom Intel yanked back from France to fix the 80186 mask? He is now one of the folks working on the Intel 386 (p.116), which is a 32-bit micro which will maintain upward compatibility with all that 8080 software (like the 8086, the 186 and the 286 before it). How this will get pulled off is going to be interesting to see: software compatibility requires a 64K segmented architecture. The 286, you will recall, has a 24-bit address bus using internal 64K segments, so do not assume that Intel will not produce a 32-bit micro with 64K segments. To repeat, segmented architectures STINK when attempting to work with multimegabyte memories! G. Gordon Bell, DEC's former V.P. of Engineering, has repeatedly asserted that the biggest mistake a computer architect can make is using too small a linear address space. Intel has not yet ventured beyond 64K - and neither does the Zilog 80000 (five zeros) - honest!
So what system has the best chance to be the future standard? Sir, you OBVIOUSLY NAVE NOT BEEN PAYING ATTENTION! We are not looking for THE future standard, we are looking for the future STANDARDS! Big difference!
Page 7, Column 1
The best bet for a future standard is the leading standard today: MS-DOS, aka PC-DOS. This operating system has a lot going for it: it is single-user single-tasking, written in assembly, and sells retail, quantity one, for $60. The biggest problem MS-DOS has (aside from 64K segments) is that Bill Gates insists that Microsoft will continue to complexify it. Microsoft would be better advised to either simplify it or, at worst, leave it alone. The mass market doesn't want complexity, it wants simplicity.
The worst bet for a future mass-market standard is an operating system which emphasizes supporting lots of concurrent users. Any such operating system will inherently be limited to purchases by businesses, as UNIX is now. OS-9, originally written for the slow 8-bit 6809, claims in its ads to be headed in that direction.
(If you want to avoid what is unquestionably the most tasteless advertisement [for an operating system] of all time, do not read the ad for 'S1' on page 23 of 3 Dec Electronics Week. This ad shows two stone tablets sitting on top of a mountain with lightning playing about the tablets. The first tablet begins "THOU SHALT HAVE NO OTHER OPERATING SYSTEM BEFORE S1" Naturally, each of the tablets list five such commandments. The sun has blasted through the cloud cover and has somehow embossed "S1" on the side of the mountain. An artesian spring has burst free just below the "S1". On the plain beside the mountain, a horse rears. There is an apple (no bite). There is a split egg, with the yolk improbably stretched between the separated halves of the shell. In the sky appear the words, "SURELY IT WILL COME TO PASS..." Stuff like this might cause the Pope to consider conversion to Buddhism.)
(Oh, yes: "ONLY S1 VENDORS & USERS WILL SURVIVE THE NEXT REVELATION" Please excuse us while we go barf...)
The most conspicuously absent operating system is the one for mass-market users of more-than-megabyte systems with Motorola or Nat Semi CPUs (which have multi-megabyte linear addressing capability). It appears that no such operating system will appear from the professional programing community since those folks will continue to believe that multi-megabyte 68000 and 32000 systems MUST be multiuser minicomputers!
That means that this needed system will probably arise out of some Joe's attempt to make a simple operating system for a 68000 rock-shooting computer. (Rock-shooting computer makers cannot afford UNIX licenses or even CP/68K or OS-9 licenses.) The computer professionals will be horrified. Joe's company will make lots of money.
Page 7, Column 2
OUR FAVORED OS ?
We thought you would never ask. The envelope, please: TADAA! Our favored operating system is NO operating system! What we mean is, the operating system should be a natural part of the computer environment along with the editor, programming language, etc. We are, of course, referring to the HALGOL environment. Let us assume that we manage to get HALGOL reasonably completed in 1985. If, when asked what operating system HALGOL uses, the HALGOL programmer scratches his head and replies "Gee! I don't think HALGOL has an operating system!" then we will have accomplished our intended goal.
If you think that sounds something like Mackintosh, you're right. But we also are not going to put anything between the user and the fundamental system resources or restrict the user from doing things his or her way. Mackintosh, on the other hand, will not let the user anywhere near the system resources and absolutely demands that the user do things Mack's way or not at all. Now, if that is not a difference in philosophy then there IS no difference in philosophy!
Commodore is struggling with the problem of getting the Amiga into production. Sir Clive is trying to get the QL from production into MASS production. Kindly Uncle Jack has, as usual, announced several dozen future Atari computers, some of them using 68000s. As usual, he may even build one or two of them some day, especially if he can raise some money. The reason you did not see the Philips Trash-68 this XMAS season is that Motorola does not yet have both of the two chips needed for its graphics system in production.
Hitachi is now selling a plastic-packaged 8MHz 68000 for $15, quantity 100. You had better believe that some folk we haven't noticed yet are readying their own Trash-68s. There IS some product innovation left in this industry, once you get away from the folk slavishly copying IBM. All of these folk will need a single-user single-tasking CHEAP operating system, which means all of them will have to write their own. One of these is bound to turn out to be a pretty good system.
(As Sir Clive prepares to introduce the $499 QL into the U.S., the professionals continue to insist that the 68000 is exclusively a vehicle to run UNIX and support 16 users. The word 'dichotomy' was invented to describe just such a situation, but 'absurd' fits too.)
A DO-IT-YOURSELF DOS:
Write your own DOS! Heck, why not? No, it is not either too complicated - especially if you have some help. So let us give you a few pointers:
Page 8, Column 1
First, get somebody - such as James S., our project engineer - to write the formatting routines and the read or write track, sector, and side routines (assuming the use of those nice new 1.6 megabyte unformatted Mitsubishi drives). See? Already the job is getting easier!
Next, following the recommendations of Hall Chamberlin, do an advance performance evaluation of the hardware. We already did that last issue in Blue Sky Report, even before Hall Chamberlin's recommendation arrived via InfoWorld. We seem to be moving right along!
We need to set aside space on the disk for a directory - that's easy - and then figure out how to allocate the sectors. We did that last part in the last issue too, and we will follow that 'next available sector' technique, with a very minor improvement which is not important enough to explain right now.
So the stage seems to be set - just go DO IT, huh? Almost! First we want to prove to ourselves that we can indeed store and load large files at our target throughput of about 43K bytes per second. If we can do that, then we are ready for the real thing.
A SAVE/LOAD BENCHMARK:
Here is our target benchmark: dimension an F.P. array 4 X 25,000. That's 100,000 floating point values at 8 bytes each, or 800,000 bytes. That'll easily fit on a full-gallon Grande and on one of those 1.28 megabyte disks. Here is our benchmark:
10 HOME:TEXT
12 DIM A(4,25000)
14 FOR I=0 TO 3
16 FOR J=0 TO 24999
18 X=I*25000+J+.5
20 MVA X TO A(I,J)
22 NEXT J:NEXT I
24 LET F$="FILENAME"
26 PRINT "START TEST"
28 DATASAVE F$(D1),A()
30 PRINT "HALFWAY!"
32 INIT (00) A()
34 DATALOAD F$(D1),A()
36 PRINT "TEST DONE"
38 FOR I=1 TO 3
40 FOR J=0 TO 24999
42 Y=I*25000+J+.5
44 MAV A(I,J) TO X
46 IF X <> Y GOTO "ERROR"
46 NEXT J:NEXT I
50 PRINT "DATA OK"
52 END
54 "ERROR"
56 PRINT "BAD TEST"Page 8, Column 2
LARGE FILES vs. SMALL FILES
That is certainly a good benchmark to measure the large-file disk throughput (and to sell full-gallon Grandes). Now, you should understand that a data throughput of about 43K bytes/sec for large files does not mean that a 4.3K file can be loaded in a tenth of a second - there is some motor start time (1/4 second on these drives) and some track seek time to the catalog, and then maybe track seek time to the file. So there is probably a half-second (appx) minimum time for even a small file.
Another thing: the technique used to load (or save) a very large file will not be that same as that for loading 'kitchen sink' files, ones with many arguments and/or types of arguments. Let's discuss 'kitchen sink' files for a while:
KITCHEN SINK FILES:
There are six possible types of arguments: simple FP, integer, and string variables and FP, integer and string arrays. When an array is saved or loaded, the ENTIRE array is saved or loaded. Therefore, an array argument is specified by, for example, A() signifying the FP array whose name is A. Eventually, string arrays (and strings) can be saved an loaded as formatted or unformatted arrays and strings. Formatted means that a particular string array element (or string) is terminated by a carriage return, whereas unformatted string arrays (or strings) are simply saved or loaded as a binary image. Since we are just feeling our way into this thing, we are initially implementing unformatted string arrays and FORMATTED (!) simple strings, just to prove we know how it is done.
Here is an example of a DATALOAD statement using each of the six possible types of arguments:
DATALOAD F$(D1) X,K%,L$,A(),I%(),S$()However, the DATALOAD (or DATASAVE) statement is not limited to just one of each type of argument, nor must the argument types proceed in any predetermined order. In fact, some perfectly legitimate DATALOAD statements can get REAL messy looking! By the way, the syntax for DATASAVE is identical to that for DATALOAD. The filename can be specified by a literal ("FILENAME"), and the drive number specification is optional when keying in the statement, just as the LET is optional in an assignment expression.
Let us focus our attention on a poor, lonely simple floating point variable (for instance) in the middle of the argument list for a complex DATALOAD statement. Our syntax might look something like this:
Page 9, Column 1
DATALOAD F$(D1) ---,X,---where "---" indicates an indefinite bunch of arguments of unspecified types. Most of you have heard of disk buffers, so you know that we aren't going to load up that 1.28 megabyte floppy all at once. Most DOSs written for 8-bit floppies use disk buffers the same size as a sector. HALGOL will use a buffer (or buffers - we'll see) the size of a track on one side of the disk. That's 8K. The size of the HALGOL buffer is chosen to maximize throughput, not to conserve RAM. Still, the size of a file can in general be bigger than that buffer.
LOADING THE MIDDLE ARGUMENT
What information do we need to load the FP variable X from the disk file in the above example? Hmmm.
Well, we know that the FP variable has eight bytes - that's implicit in the variable type. It would be nice to know that the next argument in the data saved to disk has the same variable type that is called for in the DATALOAD statement, yes? So the disk image of the variable X is a 'type' byte followed by eight 'value' bytes.
We need to know where in the 68000 memory the value of X is going. That's obviously the floating point value table, and the location within that table is determined by adding the base address of the table to the offset address of the variable X. So the argument X is specified in the HALGOL run-time code for the DATALOAD statement by the type, which can occupy one word, and the offset, which is another word. From this we can generalize that the argument list to be LOADed is specified in the run-time code by a type word and an offset address, which is another word, for each argument in the list.
The following two essential items are provided by the run-time code:
- The argument type FP implies 8 bytes to be stored.
- The address where the data is to be stored.
Let's see, now. The system has to have a pointer to the next available byte in the buffer. Remember that we have been loading other arguments and we cannot be sure that the 8 byte value is completely contained in the buffer. We need a byte count specifying the number of bytes remaining in the buffer. So we add these to our list of essential items:
- A pointer to the next available byte in the buffer.
- The number of bytes contained in the buffer.
Page 9, Column 2
REFILLING THE BUFFER:
If the number of bytes left in the buffer is less than the number of bytes needed for the current argument (in this case the FP variable X) then we will need to call a routine to reload the buffer. When reloading the buffer we need to know whether there is more data in the file (if we try to reload the buffer and there is no more data, then we must issue an error message). We also need to know the next sector # to be loaded. (We will use sector numbers 0 to 1279, from which we can readily calculate the track, the sector on that track, and the side.)
After the buffer is reloaded, we must reset the buffer pointer to point to the start of the buffer and set the buffer byte count.
We need to add two more essential items to our list:
- The next sector number in the file.
- Whether there is more data in the file.
LINKED-LIST FILE STRUCTURE:
In case you were wondering, each successive sector (1024 bytes) contains a pointer to the next sector number. This is called a linked list. A few bytes of those 1024 in each sector must be 'set aside' for this pointer. Since there are only 1280 sectors on the Mitsubishi disks currently under consideration, only two bytes are needed for this link. However, two bytes can only specify 64K sectors at 1K each, or 64 megabytes. Winchesters are already past that limit. We definitely need three bytes to specify that link as soon as we hook up a hard disk to HALGOL. But the 68000 works best with 16 or 32 bit numbers, so it seems sensible to set aside four bytes to be ready for the lazer disks in the future. That allows for disk capacities of 4,000 gigabytes. Or, if you prefer, 4,000,000 megabytes.
That means each 1024 byte sector actually contains 1020 bytes. It also means that the maximum number of bytes on one track, one side is 8,160 rather than 8,192.
When a file is initially saved, it is saved in consecutive ascending sector order; e.g. 787, 788, 789 etc. The last sector in the file is marked by a zero link (since the sector sequence is always ascending, sector #0 can NEVER be the NEXT sector). Therefore, if the next sector number is not zero, there IS more data remaining in the file - so the sector number satisfies one of the essential items on our list! The only time the sector sequence is NOT consecutive is when a file is resaved with more data, and this situation is fixed by a 'COLLECT' program.
Page 10, Column 1
Having the sectors in ascending sequence provides the fastest possible data transfer for the hardware used. That is what HALGOL is all about - getting the maximum speed out of the hardware used. (We will let others write operating systems in P-code or floating point packages in unoptimized 'C' or having disk files with sectors scattered randomly about the disk.)
THE DISK CATALOG:
Naturally, the disk catalog contains the first sector number and the type of the file, in this case a data file, in conjunction with the file name. There may be other information associated with the file name, such as a bit marking the file as read only ("locked").
THE DEVICE DRIVER:
At this point we would logically discuss the operation of the device driver, which is the point where the software gets intimately linked to the hardware. We are not going to do that, because although the device drivers have in essence been written (we have been able to write and read the entire 1280K disk since the end of Nov) WE did not write the drivers! James S., our project engineer, did. And he seems to be much better at designing hardware and writing device drivers than he is at documenting same.
So we are just going to magically invoke two subroutines, "READSEC" and "WRITESEC". In each case the sector number is passed to the subroutine as a 32-bit value in D0 and a memory pointer is passed in A0. The subroutines will return the next sector number in D0 and the next byte location in memory in A0. The subroutines are not permitted to change any other registers in the 68000 (meaning that any registers used are saved and then later restored).
LOADING THE BUFFER:
We will for now simply assert that we have a subroutine called "LOADBUFF" which reloads the buffer and returns the buffer byte count and a pointer to the beginning of the buffer. (We assume that any assembly language programmers amongst you could write such a routine using "READSEC" as a building block.) "LOADBUFF" works on complete sectors only; no partial sectors. An attempt to call "LOADBUFF" when there is no more data in the file will result in an error message.
THAT MIDDLE ARGUMENT:
Now we can get back to loading that middle argument N. We will assume that the argument type, a simple FP varn in this case, has already been checked. As pointed out in the preceding discussion, we need the following essential information:
Page 10, Column 2
- The number of bytes to be stored (8).
- The address where the data is to be stored.
- A pointer to the next byte in the buffer.
- The number of bytes contained in the buffer.
- The next sector number in the file.
- Whether more data remains in the file.
The last item in the list - whether more data remains in the file - is implicit in the next sector number. If the next sector number is not zero, then there is more data in the file. And if we are simply going to magically invoke the subroutine "LOADBUFF", then we do not need the next sector number. That leaves us with the first four items, two of which are byte counts and two of which are address pointers.
On the next page is the software to service that middle argument. We first compare the number of bytes to be moved (8) against the buffer byte count. The odds of the first branch being taken are over 1,000 to 1 against (8,153 to 7, to be exact), so 99.9% of the time the first seven lines of code are all that will be executed. But if there are fewer than 8 bytes left in the buffer, we check whether the buffer is empty. If so, we call "LOADBUFF" and start over. Otherwise, we transfer the remaining bytes in the buffer, correct the number of bytes to be stored, call "LOADBUFF" and start over.
This routine, which we call "CMDX", is in fact used to transfer ALL kinds of arguments when loading a "kitchen sink" datafile. Just load the destination pointer into A0 and the byte count into D1 and GOSUB CMDX! Nothing to it.
We bet you thought writing a DOS was difficult.
DATA FILE FORMAT:
A HALGOL data file, by definition, is one which contains one or more of the six possible HALGOL argument types. It also contains certain format information, since we need to check for a match of data types when loading the data from disk. In the case of an array we need to check the size of the array to be certain that we do not overflow the array being loaded, and also to locate the type of the succeeding argument. In the case of strings we need to know the length of the string, and in the case of string arrays we need to know the length of the array elements.
Obviously, it is an error to load an FP array if the disk format indicates that a string array is the next argument in the file. Obviously, it is an error if the array in the 68000 memory is dimensioned smaller than the number of bytes in the array in the disk file. (We THINK that's obvious. Hmmm...) However, what if the array in the 68000 is dimensioned LARGER than the array
Page 11
129 * COPYRIGHT 1984 DIGITAL ACOUSTICS INC
130 *
131 * MOVE D1 BYTES FROM THE BUFFER TO THE VARN ADR
132 *
133 * D1 = THE # OF BYTES TO BE MOVED TO THE VARN
134 * D2 = THE NUMBER OF BYTES REMAINING IN THE BUFFER
135 * A0 = PTR TO DESTINATION ADR (VARN LOCATION)
136 * A5 = PTR TO NEXT BYTE IN THE BUFFER
137 *
138 009C2C B441 CMDX: CMP.W D1,D2 ;COMPARE BUFF CNT
139 009C2E 650C BCS CMDX2 ;IF D1 > D2
140 *
141 * THE SOURCE COUNT IS LESS THAN OR EQUAL TO THE
142 * NUMBER OF BYTES AVAILABLE IN THE BUFFER.
143 *
144 009C30 9441 SUB.W D1,D2 ;DECR BUFF COUNT
145 009C32 5341 SUBQ.W #1,D1 ;CORRECT THE COUNT
146 009C34 10DD CMDX1: MOVE.B (A5)+,(A0)+ ;MOVE A BYTE
147 009C36 51C9FFFC DBF D1,CMDX1 ;LOOP 'TIL ZERO
148 *
149 009C3A 4E75 RTS ;DONE
150 *
151 * THE BUFFER COUNT IS LESS THAN THE SOURCE COUNT.
152 * IS THERE ANY DATA IN THE BUFFER ?
153 *
154 009C3C 4A42 CMDX2: TST.W D2 ;BUFFER EMPTY ?
155 009C3E 660C BNE CMDX4 ;IF NOT
156 *
157 * EMPTY THE BUFFER, THEN REFILL IT AND START OVER.
158 *
159 009C40 9242 SUB.W D2,D1 ;DECR SRC COUNT
160 009C42 5342 SUBQ.W #1,D2 ;CORRECT THE COUNT
161 009C44 1AD8 CMDX3: MOVE.B (A0)+,(A5)+ ;MOVE A BYTE
162 009C46 5341 SUBQ.W #1,D1 ;DECR COUNT
163 009C48 51CAFFFA DBF D2,CMDX3 ;IF NOT ZERO
164 *
165 009C4C 4EB89CBC CMDX4: JSR LOADBUFF ;REFILL BUFFER
166 009C50 60DA BRA CMDX ;START OVER
167 *
10 DIM Z$35, STRING$(5,10)35
20 DIM FP(4,100),INT%(16,100)
30 DATALOAD "FILENAME"(D1),X,Y%,Z$,FP(),INT%(),STRING$()
40 F$="NEXTFILE"
50 DATALOAD F$(D1),X,Y%,Z$,FP(),INT%(),STRING$()
HPR $A800,$9
9708 8000 0000 0023 0000 0000 0002 0005
000A 0023 FFFF 9708 0003 0000 0010 0004
0065 0001 0000 001C 0010 0064 FFFF 47A4
00B1 08C6 C9CC C5CE C1CD C500 0001 0000
0003 0000 0005 0000 0002 0010 0004 001C
0006 0002 0000 8EBA 0004 0008 08CE C5D8
D4C6 C9CC C500 47A4 FFB1 0004 0001 0000
0003 0000 0005 0000 0002 0010 0004 001C
0006 0002 0000 3D6EPage 12, Column 1
in the disk file? We think that should be allowed. And what if the array saved into the disk file was dimensioned (4,25000) while the array being loaded from disk is dimensioned (4,5,5000)? We don't think that is a problem either, so the disk file format does not include specific dimension information - just type and total array size. We DO, however, check the element length of string arrays if FORMATTED data is specified. (We are going to pass on a more in-depth discussion of formatted vs. unformatted strings for now, and will assume unformatted string arrays.)
ARGUMENT TYPES:
The dummy argument type zero (0) is used to indicate the end of the file ('no more arguments'). Here are the possible argument types:
0: no more arguments
1: simple FP varn
2: FP array
3: simple integer varn
4: integer array
5: simple string varn
6: string arrayARGUMENT DISK FILE FORMATS:
A hex (01) type byte marks a simple floating point varn, and is followed by the eight bytes of the floating point value, most significant byte first.
A hex (02) type byte marks a floating point array, and is followed by a 24-bit array byte count, then by the indicated number of bytes. The 24-bit array byte count comes most significant byte first, least significant last.
A hex (03) type byte marks a simple integer varn, and is followed by the two bytes of the integer value, most significant byte first.
A hex (04) type byte marks an integer array, followed by a 24-bit array byte count as before, then by the indicated number of bytes.
A hex (05) type byte marks a simple string varn, and is followed by the string length byte (value ito 255), then by the string itself with as many bytes as the string length byte indicates.
A hex (06) type byte marks a string array, and is followed by the element length byte (value ito 255), then by a 24-bit array byte count as before, then by the indicated number of bytes.
A hex (00) type byte marks the end of the data file.
Page 12, Column 2
FILE FORMAT OVERHEAD:
In addition to the arguments themselves, there is some overhead associated with formatting the data file. Here is the overhead for each of the argument types:
simple FP varn: 1 byte
FP array: 4 bytes
simple int varn: 1 byte
integer array: 4 bytes
simple str varn: 2 bytes
string array: 5 bytesFrom this and the known size of the arguments themselves, it is possible to calculate the number of sectors needed to save a data file. Remember to add one byte for the EOF (End Of File) type byte and remember that there are 1020 data bytes per sector.
RUN-TIME DATALOAD CODE:
At the bottom of p.11 is a hex printout of a DATALOAD statement which includes all six argument types. The code is in this form:
<DATALOAD> ACTION ADR
[ 00B1 ] LITERAL NAME,
DRIVE #1
[ 08C6 ] 8 BYTES, "F"
[ C9CC ] "I", "L"
[ C5CE ] "E", "N"
[ C1CD ] "A", "M"
[ C500 ] "E", NULL PAD
[ 0001 ] TYPE FP
[ 0000 ] OFFSET ADR
[ 0003 ] TYPE INT
[ 0000 ] OFFSET ADR
[ 0005 ] TYPE STRING
[ 0000 ] OFFSET ADR
[ 0002 ] TYPE FP ARY
[ 0010 ] OFFSET ADR
[ 0004 ] TYPE INT ARY
[ 001C ] OFFSET ADR
[ 0006 ] TYPE STR ARY
[ 0002 ] OFFSET ADR
[ 0000 ] ARG LIST ENDOn the same page, line 50 is the same except that the filename is specified by a string variable. The run-time code begins:
<DATASAVE> ACTION ADR
[ FFB1 ] STR VARN NAME,
DRIVE #1
[ 0004 ] S' VARN OFFSETand continues with the same argument list format as line 30. DATASAVE code is just like DATALOAD except for the action address, and it uses exactly the same syntax as DATALOAD.
Page 13, Column 1
TRACK vs. CYLINDER:
A two-sided floppy disk, like hard disks, has more than one track number N. In multiple-surface drives the term 'track' is replaced with 'cylinder'. Any particular sector in the drive is specified by a cylinder number, a surface number, and a sector number. The HALGOL DOS will work with a simple sector numbering scheme of 0 to M-1, where M is the total number of sectors available on a given disk drive.
With the Mitsubishi drives we are using, M is 80 X 2 X 8 (cylinders times surfaces times sectors/track) or 1280. So HALGOL will pass a binary number whose decimal value is 0 to 1279 to the READSEC or WRITESEC routine along with a drive number, and the routines will have to translate that number into cylinder, surface, sector format to be passed along to the floppy disk controller (the drive # is selected by a latch external to the Western Digital controller chip).
LOGICAL vs. PHYSICAL:
If you read BLUE SKY REPORT in the last issue, you will know that (for instance) sector #0 on track 0 is not adjacent to sector #0 on track 1. Sector #0 is instead "delayed" one sector position to maximize throughput when reading or writing large files. On track 2 sector #0 will be "delayed" TWO sector positions with respect to track 0, etc. Unfortunately, the Western Digital controller chip likes to initialize disks with sector #0 always immediately following the index hole on the floppy disk media.
Therefore, the HALGOL DOS has to also "map" from logical sector numbers to physical sector numbers, which is quite simple using the 68000. We need to convert the logical sector number in data register D0 to a cylinder number in (for instance) D1, a surface number in D2, and a PHYSICAL (not logical) sector # in D3.
Here is code that will do the job, including a test for a legal logical sector #:
1 CMPI.L #1279,D0
2 BHI DISKERROR
3 MOVE.W D0,D1
4 LSR.W #4,D1
5 MOVE.W D0,D2
6 LSR.W #3,D2
7 MOVE.W D0,D3
8 ADD.W D2,D3
9 ANDI.W #7,D3
10 ANDI.W #1,D2That's it! That's all it takes. An explanation:
Page 13, Column 2
A digression: We have a choice between skewing the logical-vs-physical sectors between side 0 and side 1, while using an 8K disk buffer, or NOT skewing the sectors and using a 16K disk buffer. There is a potential 5.5% data throughput performance gain if no skewing and 16K buffers are used. We have chosen to go with 8K buffers because we are not convinced that we can consistently and reliably 'flush' a 16K buffer in one sector time (appx 20 mlllisec), but we DO think we can 'flush' an 8K buffer in that time.
The number #1279 decimal, which is the largest legal sector number, can be represented by 11 bits in binary. We are using a 32-bit number to define our sector so we will be ready for those BIG BIG lazer disks when they arrive! Line 1 tests for an illegally large sector number; line 2 will branch to an error routine if that number is too large.
THE CYLINDER:
We take the most significant 7 bits and let them represent the cylinder number, which ranges from 0 to 79 decimal. So line 3 moves the lowest 16 bits, of which the most significant 5 are now assured to be zeros, to D1. Line 4 pushes the lowest four bits off the right-hand edge of the data register and we are left with the cylinder number in D1.
THE SIDE:
Line 5 moves the logical sector number to D2. Line 6 shifts bit 4, the surface (side) bit, into the least significant bit position of D2. Line 10 masks all of the other bits in D2.W to zero except for the least significant bit, which has a value of 0 or 1 corresponding to side 0 or 1. Note that we do not mask off those other bits until the end of the code.
THE SECTOR:
We take the least significant three bits and let them represent the logical sector number on a given track. To get the physical sector number, we add the cylinder number times 2 and the side bit to the logical sector number and then truncate the result to the three least bits. Note that after line 6 and before line 10, data register D2 contains 2 times the cylinder number plus the side bit! So, in line 7 we move the logical sector # to D3, then in line 8 we add D2 to D3. In line 9 we mask off all but the least three bits of D3, leaving the physical sector number.
An example: suppose we want to read sector number 875 (decimal). That's Hex (036B) and the eleven significant bits have the pattern:
Page 14, Column 1
: cylinder 54
: : sector 3
------- ---
01101101011
-
: side 1We can use the number 54 (decimal) for the cylinder directly and the 1 for the side number directly but we need to calculate the physical sector number. So we shift the number 3 bits right in D2 and add to D3 and then truncate the result:
D2 01101101011
D3 01101101011---
----------- : discard
D3 XXXXXXXX000 3 bitsTherefore, on cylinder 54, side 1, logical sector 3 maps to physical sector 0.
WHY ALL THAT WORK ?
The reason we are skewing sectors is to avoid having to wait for an entire rotation of the disk after reading sectors 0 thru 7 on track T and then stepping to track T+1. Since stepping to the next track requires nearly one 'sector time', we cannot immediately read sector 0 because it went by while we were stepping. So we either have to wait while 7 more sectors go by and sector 0 comes around again or we can 'map' sector 0 into sector 1 and start reading immediately!
(Our project engineer just looked at that 10-line code sequence a page back and showed that he could save a few clock cycles by modifying the code. True, but it would unnecessarily complicate the explanation of what was happening!)
THAT'S ALL FOR NOW:
We know that most of you are not interested in as much detail as we have presented in the past six pages on writing a DOS. The point is, ANYBODY can stand up on a soapbox and claim that a high-performance floppy disk-based DOS can (or cannot!) be incorporated into a simple 68000 system. It is quite another thing to PROVE that it can be done.
We are writing this DOS because HALGOL needs a DOS that is not limited to those obsolete Apple DISK IIs. We will write a compatible DOS based on those obsolete Apple DISK IIs because it should be possible to load and run HALGOL on a DTACK board without having to buy a pair of floppy disks. We think we have figured out a way to use any higher capacity disk you may already have purchased for your Apple II, such as a hard disk or a RANA drive, with this compatible HALGOL DOS.
Page 14, Column 2
ERRATA SQUARED:
Last issue's errata got fouled up; issue #36 got mysteriously transcribed as #6. Let's try again:
In issue #36, turn to page 24 and see the third paragraph, the one just above the headline "ZERO-BASED INDICES". In that paragraph, cross out the words "and high bits of the first word of the array descriptor".
MD COMPUTING ?
"Hey, Felgercarb!" James called. "Remember that MD magazine a new subscriber mentioned?" Yes? we murmured contentedly. "Well, its name is MD COMPUTING and it's published by Springer-Verlag. Look here! That new subscriber sent us a photocopy of pages 11 to 13 of vol 1 #6 and they are reprinting stuff from your newsletter all over those pages! In fact, get this - they start off by stating that 'As usual, in this issue we are quoting extensively from FNE'!"
So? we replied, editorial material is hard to come by these days (peel us another grape, dear? we suggested to DA's new dancing maiden). Besides, it's all right to copy our newsletter - we print that right on the signoff page every issue, you know.
"Yes, but these guys did not publish the subscription information! Surely they are breaking the copyright law?" our project engineer insisted.
Sigh. (Dear, will you go over to the couch there and look pretty? Our project engineer seems intent on transacting some nasty old business stuff.) Look, James, there is no such thing as 'breaking the copyright law'. It does seem possible that MD is infringing our copyright, which is not the same thing. We might even have written them a letter giving them permission to publish, and then forgotten about it. If not, we may send a stiff note of protest in a year or nine. By the way - you WILL remind us to send a note to Nils D. thanking him for indirectly suggesting that we employ a dancing maiden?
"I thought it was supposed to be dancing maidens, plural?" inquired our project engineer. Now, now - the DA budget only allows for ONE - as an executive perk, you know. Anything more before you get back to work? we asked pointedly. "Well, MD also misspelled 'Eloi' - see, they printed 'E-L-O-I-E'" he replied.
WHAT? GUARDS! MAN THE BATTLEMENTS! FETCH THE ATTACK TEDDY BEARS! THIS, we shouted, MEANS WAR! We looked around and saw that both James and the dancing maiden had vanished. Damn uppity youngsters! we grumped. Peeling one's own grapes just isn't the same!
Page 15, Column 1
[Later: it turns out that had our new subscriber sent a copy of page #15, we would have seen that MD DID give us proper credit. But we had too much fun writing that item to change or delete it.]
WE GET MAIL:
"What little interest I had in HALGOL vanished when you made line numbers mandatory.
"Forth programmers have been described (perhaps by you) as 'smugly happy with what they believe is the best programming language' (or words to that effect)." Steve McI, Long Beach CA
Steve, we did NOT make line numbers mandatory, at least not in the sense that you seem to be indicating. HALGOL still has no facility for GOSUBing or GOTOing a line number (and, by the way, we have been criticized for that fact). What we meant was, when our then resident full-time programmer implemented multiple statements per line he had to use some sort of 'tag' to indicate which statements were the first of a line. That 'tag' is what was made mandatory. The obvious 'tag' is a line number, since we were already using line numbers for editing purposes.
SOME method of editing programs MUST be provided. FORTH solves this problem by breaking the program down into "screens" which DO fit all at once on the CRT. The P-system scrolls SOURCE TEXT up and down. HALGOL does not have 'source text'. Would you have us use HALGOL "screens"? We have instead adapted the BASIC convention of line numbers, without crippling the system with GOSUB or GOTO (line number). The line numbers are mandatory only to the extent that editing is mandatory, and also to the extent that we MUST have some sort of tag for multiple statements per line, so why not a line number?
It would be a trivially simple task to list a HALGOL program without the line numbers but then how would you edit it? We are not trying to impose HALGOL on someone who uses FORTH in private or UNIX and C for a living but let's be fair when critiquing HALGOL, O.K.?
We most certainly have NOT written anything like your example about FORTH or FORTH folks. What we HAVE written is that FORTH folk are very interesting if a little backward (that's a reverse Polish joke, Steve). We have also asserted that one can safely attend a FORTH Interest Group meeting without having someone try to sell you a life insurance policy (or try to recruit you for the Junior Chamber or the Rotarians).
Thanks for the mini-review of the Sinclair QL. Did you see David Ahl's writeup in Vol 10 #12 Creative Computing? - FNE
Page 15, Column 2
"Digital Acoustics is no longer the producer of the fastest attached processor for PCs. We had a demonstration this week of the Marinco board for the IBM PC, which is a real screamer. It has an AND 29116 ALU (125nsec cycle time) and 45nsec onboard memory. In addition, it has a 16 bit parallel multiplier. They claim a minimum of 8 MIPS and possibly 24 MIPS. All is not sweetness and light, however. The memory on the board is limited to only 2K X 48 bits of PROM and 2K X 48 bits of RAM, and the software is limited to an onboard executive/debugger and an assembler (sound familiar?). But the speed is there - 1024 pt complex FFT (16 bit integer) 18.2 msec, for instance.
"They ran several demos while they were here, and their board is much faster than a PC, even doing floating point much faster than the 8087. The board is about $3000 (there are several models), but the software is not cheap. Assembler and utilities are $4,000, and library software is $300-$400 for such operations as vector, matrix, scalar, signal processing, image processing (each), around $1000 if you want the source. That's Marinco Computer Products, Inc. in San Diego. Call 800-421-4807 outside CA, -4808 in CA." Bruce W., San Pedro CA
Actually, Analytical Engines is supposed to have been shipping Apple-compatible SAYBROOK boards with 14.4MHz 68000 CPUs (somehow selected from L12's) for some time now. Anybody heard from them lately? We wonder which will be the first company to make an attached processor, using AMD's upcoming 32-bit ALU, for a Timex 1000? - FNE
"...We are using a 68000-based VMEbus system for a teleconferencing system. We have some excellent assembly language programmers. One guy is super good at assembly and prefers to code everything that way. [For] every new system he encounters he develops a macro package included as an INCLUDE file which performs a lot of special functions like screen I/O, file I/O, etc. After he gets done tailoring a software architecture, is as almost like writing in an HLL. His code is tight and efficient as well as fairly easy to read.
"We also have someone who worked at Bell Labs in 'C' for about five years. Since our application is a real-time system, we quickly got into what was to be written in 'C' and what was not. Performance measurements on OPTIMIZED 'C' and assembly produced a 4 to 1 difference in favor of assembly speed. A poor 'C' program done earlier showed a 40 to 1 advantage in favor of assembly language." Steven S., Yorba Linda CA
Steven, that crummy performance by the 3B2/300 in floating point looks to us like about a 40 to 1 HLL
Page 16, Column 1
('C', of course) overhead versus assembly considering that the floating point package is IEEE compatible. To us, that absolutely proves that A) there is no such thing as a 'C' compiler with 2 to 1 HLL overhead, and B) that damn 80%/20% rule is in fact too often ignored. Thanks for passing along some more real-world 'C' performance figures - FNE
"Billy Batson a crippled newspaper boy, indeed! Sir, run a diagnostic on your hydrocarbon RAM. Billy Batson was a quite ordinary if slightly stocky lad whose only abnormality was that when he spoke the word SHAZAM he was thunderclapped into the form of Captain Marvel, aka the Big Red Cheese. Billy B. worked as a child newscaster for a radio station whose call letters were, I believe, WHIZ.
"The crippled newsboy was one Freddy Freeman who looked a bit more like a real human (the artists working from an entirely different set of model sheets) and could change into Captain Marvel JUNIOR (no relation to PC). Can your frayed synapses dredge up the magic word or words that HE had to speak? [Nope - FNE]
"Then Billy's sister or cousin or something popped up and became Mary Marvel. And then there was Grandpa Marvel. After that it would take a Latter-Day Saint to trace the genealogy of the entire Marvel family. Who was their arch-enemy? What was the name of the talking tiger?
"I myself was addicted to Wonder Woman, which gave me all kinds of curious notions about proper relations with the 'weaker' sex." Jim H., Pullman WA
It does appear that our hydrocarbon DRAM dropped a few bits. It hasn't been refreshed for nearly 40 years, so that's not surprising. GRANDPA Marvel? We are not going for that one, Jim! By the way, we received a letter from James M. of Newark DE in the same mail with about the same info, but we opened your letter first so we guess you have priority.
We remember Wonder Woman, the comic book version, well. Even at that youthful age we had noticed that women had bumps on their chest but Wonder Woman was drawn COMPLETELY flat-chested and we wondered about that. We knew, from our grandparents' bookcase, that Amazons were women who had cut off one of those bumps so as not to interfere with their archery. In retrospect, it is obvious that Wonder Woman was an Amazon who was a switch-archer. But the real reason we didn't like Wonder Woman was that her invisible airplane looked like a VASE (honest!), not a P-38! We have seen the TV version of Wonder Woman a couple of times and Linda Carter does not resemble the comic book original in two important respects - FNE
Page 16, Column 2
"...[ABSOFT Corp.] sells FORTRAN 77 compilers for a variety of micros including, most recently, Mackintosh. While I know and respect your feelings about HLLs and Mack, hopefully MackFORTRAN, which is written in 68000 assembly language, will be faster than Mackintosh Microsoft BASIC (619 sec) or MackPASCAL (328 sec) for Terry P.'s benchmark in issue #25. As a scientist, FORTRAN does come in handy.
"More interesting, however, was the discussion I had with an ABSOFT representative when I ordered MackFORTRAN. The representative asked if I would be interested in a hardware floating point accelerator for the Mack. It seems ABSOFT plans to sell a piggyback board for the Mack with a 68000 and 32081 for about $500." Reed C., Brookhaven National Laboratory Long Island NY
Reed, do you REALLY know our feelings about HLLs? Despite our repeated denials, many of our readers (apparently including you) seem to think that we are opposed to the use of HLLs. Wrong! We are opposed to the use of HLLs which are busted by being written in ANOTHER HLL. An example is Microsoft's 8088 FORTRAN, which is written in 'C' and does not run but instead oozes, slowly. Or SofTech's P-code FORTRAN, likewise. Have you by any chance noticed that we have ourselves invested over $100,000 in HALGOL, which is a high level language?
The ABSOFT FORTRAN, if correctly written in assembly instead of being busted in C or PASCAL, is exactly the sort of thing any 68000 computer needs - especially with optional math chip support. Would you please keep us advised of the progress of that ABSOFT FORTRAN, including benchmark performance with and without the 32081? In return we promise to shield you from the wrath of reader Ivan S. over your grammatically incorrect usage of "hopefully" (see issue #29, p.16 col 2) - FNE
"I suppose that the usual holiday activities are in progress at DA - toasting correspondents to a golden brown over an open fire, quaffing brew, giving the attack teddy bears a good brushing, decorating the tree with 8MHz 68000 chips and streamers made from EDN advertisements for CPU chips, etc. Well, happy holidays. May you dream of hardware-implemented string moves for the 68000 and other nice things." Nils D., Wethersfield CT
Thanks, Nils - we hope you have a happy holiday season as well. C-64 HALGOL support is coming up faster than you think, now that a third party is involved. About that "terminally impecunious": ANOTHER newsletter editor is responsible for that one! - FNE
Page 17, Column 1
"...On the subject of UNIX, I have noted with some chagrin a tendency for these $50K 68000 machines to come sans assembler. [Name deleted] does not even sell one, but refers the buyer to some aftermarket source. In talking with one of their sales jerks (he was a major jerk), I was given to feel that someone wishing to use an assembler must have suffered brain injury at an early age. This bothers me greatly since it suggests the OS is equally out of bounds. I am interested in getting some possible benchmarks on basic performance on these machines; it is possible that the humble [Corvus] Concept/DG combination is faster than these C/UNIX driven computers. I seriously doubt if a 10MHz 68010 can overcome the disadvantage of its fancy OS. Of course, my interest in these boxes relates to their real-time 'Star Wars' graphics stuff and I may have to compromise somewhere. However, I refuse to buy anything that has no factory assembler w/factory support. I have too much laborious code lovingly done in 68000 asm; I will not convert said code to C just to be fashionable.
"Your report on the WE32000 should make some people wonder where the HLL disease should stop. I can't believe someone would write floating point software in a HLL. My slow Concept (FP add: 210 microsec) is a Cray by A T & T standards. You would think the Fortune/Lisa fiasco would change some minds, but the hacks out there probably don't give a damn.
"...the 7220 is relatively slow; it appears the FIFO is a real bottleneck if small moves/draws are done. I don't understand why everybody uses the 7220 since it is a relatively obsolete part; Hitachi is supposed to be better and the XTAR GMP sounds far more powerful." John W., Austin TX
John, the reason everybody uses the 7220 is that IT IS THE ONLY ONE IN PRODUCTION! We received our sample Hitachi chip two days before your letter, for instance, and we paid beaucoup bucks for it! As far as we know, the XTAR is strictly a paper design for now. Our experience is that the 7220 can consistently outrun even a no-wait-state 68000L12; the real bottleneck is the manipulations which have to be done by the 68000 for the 7220 which the upcoming Hitachi chip does internally, thereby unloading the 68000 for more useful stuff.
As for your comments on assembly, you may be interested that long-time virulent HLL supporter John B. of Burlingame, CA has apparently surrendered unconditionally. We suspect that he does not see it that way, but in his recent missive (much too long for publication here) he asserts that algorithms should first be tested and perfected in a high level language and THEN translated into assembly if desired. We can find no disagreement with that viewpoint and our own.
Page 17, Column 2
In fact, some of you may recall that we did exactly that when writing the expression evaluation compilation and optimization code for HALGOL. We don't always write in HLL first because some algorithms, especially bit-twiddling stuff, can be expressed more simply and elegantly in 68000 assembler than in any HLL we know - FNE
(Hey, wait a minute! Didn't we introduce John B. to John W., and vice-versa, in these letter columns a long time back?)
"As reported in the Midnite Software Gazette, issue #21, there is a bug in the HESMON simple assembler routine. Branch instructions that would correctly generate offsets of $7E, $7F, $80, or $81 (i.e., the longest-possible 6502 branches) are incorrectly handled. The interesting thing about this is NOT that it took from 1979 (when the EXTRAMON code containing this error was written by Bill Seiler, I guess - at this point, who knows?) until 1984 to discover the error, but that SOMEONE, SOMEWHERE (presumably of sound mind and body) was using a one-line 'simple assembler' to write code requiring such branches! I doff my hat to that individual and suggest he is now qualified to undertake something of MODERATE difficulty - such as rowing up the Hudson to Lake Erie in a washtub using a teaspoon for an oar." (modestly) Sneaky Pete
It is possible that 'Sneaky Pete' may be related in some way to one Terry P., who adapted Bill Seiler's copyrighted program (with Bill's permission) to a commercial version for use with the VIC-20, known as HESMON. More recently, Terry has adapted PHASE ZERO's copyrighted 68000 cross-assembler (again with permission) to the PET/CBM world - FNE
"P.S.: ...I will be most interested in seeing some portion of this letter taken out of context and myself ridiculed and abused in your publication." Paul G., Cote St. Luc Quebec Canada
Paul, that's ridiculous! We NEVER abuse our correspondents. Are all Canadians as unperceptive as you, or just the frogs in Quebec? - FNE
"I for one entertain no fantasies of every citizen learning UNIX as a second language. For one thing, to use UNIX well you really have to know a dozen or so different languages and quoting conventions. Aside from being a very cleverly done and enormously useful system, Unix is, well, old. As you would say, Unix likes to have a fast disk. (Guess why! Ken Thompson designed the file system assuming the disk would be so fast relative to the CPU, and guess what's happened to
Page 18, Column 1
CPUs and not to disks.) However, you must allow me my pity when I watch someone struggle with a task that I could whip off in a few lines of UNIX. If only it wasn't so expensive to buy and hard to learn..." [name deleted]
We'll hoist a Special Dark to that, deleted - FNE
"SHAZAM:
"Solomon Wisdom
Hercules Strength
Atlas Stamina
Zeus Power
Achilles Courage
Mercury Speed"Nils D., Wethersfield CT
Nils reports that the initial WHIZ comics issue, dated Feb 1940, was reprinted by Lyle Stuart, Inc., Secaucus NJ in 1974.
"I have some reservations about your dislike of C." Ivan S. Berkeley CA
Hold it, Ivan! Who said we dislike C? We merely dislike the use of C - or any other high level language - to write ANOTHER high level language, or a floating point package, or even an operating system intended for use in a mass marketplace. That is NOT the same thing as 'disliking C'! We fear that much of your letter is a non sequitur because your opening sentence, reprinted above, is false and misleading. We merely prefer that C (or other HLLs such as COBOL, FORTRAN, MODULA-2 and HALGOL) be used in an APPROPRIATE manner. The A T & T use of C to write a floating point package for the 3B2 series was HIGHLY INAPPROPRIATE! - FNE
"...Maybe when success overwhelms DTACK, it will rate its own mailing envelopes. I've come dangerously close to tossing issues thinking they were unwanted promotional literature." David H., NY NY
We never thought of that, David - and we are pretty quick to toss apparent junk mail in the round file ourselves. We just printed up 3,000 Digital Acoustics envelopes (would you believe they cost over 10 cents each?), but we will try to give some consideration to your suggestion 3 or 4 months from now - FNE
"While many people foolishly ignore the 80%/20% rule, I don't really believe that it is fictitious." John T., Apple Valley MN
Page 18, Column 2
We agree completely; the 80%/20% rule is NOT fictitious - just foolishly ignored. By the way, do you like Apple Valley better than Burnsville (issue #36, p17 col 1)? - FNE
"I can't solve all your problems, but I can help you with the question you asked in issue #37, p.22: Here's how to get my word rate:
"Spend about 15 years in the aerospace business.
"Become a professor.
"Spend two years working in politics, manage four successful and one unsuccessful campaign, then become the speech writer for the mayor.
"Drop all that and become a full time writer. Better have saved some money. Income for the first four years was zero, and we were no longer used to starving like students.
"Write a best selling novel.
"Turn out about 12 other novels, plus four or five books of non-fiction.
"That's it.
"One of these days I'll mention you in the main body of the column. That'll fix Dvorak." Jerry P., Los Angeles CA
Thanks for the tips, Jerry. You have just convinced us how smart we were to take up electronic hardware design instead of free-lance writing for a living! (An aside to our other readers: Jerry's letter arrived on CITIZENS ADVISORY COUNCIL ON NATIONAL SPACE POLICY, J. E. Pournelle, Ph.D. CHAIRMAN letterhead.) - FNE
"I beg to differ with your analysis of my column that discussed the 3-inch disk as a standard (#37 p.8). I simply pointed out a possible switcheroo scenario that people should be aware of - I NEVER said that the 3-inch disk WOULD BE the standard disk you implied.
"In fact, I long ago said that it was all over and the 3.5-inch disk had won the war. I may have been premature with that proclamation, but that's the one I officially made and was thanked by H-P for doing it!
"I would appreciate a clarification in your next issue." John D., Albany CA
How's this, John? By the way, another columnist (Jerry P.) kindly mentioned you (see above) - FNE
Page 19, Column 1
THE (GAG!) IBM WATCH:
The following is for those of you who for one reason or another do not follow IBM doings closely.
You remember the PCjr, introduced about a year ago. You remember how it fell on its face, and the four or five magazines which were started exclusively for the jr ALL fell by the wayside. Well, PC WEEK reports that jr is now selling, slowly but steadily. How slowly? At about the same rate as the IBM portable, that's how slowly! But the amazing thing is not SLOWLY, the amazing thing is that it SELLS AT ALL!
So we checked out the IBM ad in 11 Dec PC magazine, beginning on p.49. In the second paragraph they talk of 512K jrs! In the THIRD paragraph they talk of 512K jrs! In the fourth paragraph they talk of running Lotus 1-2-3 and Andrew Tobias' Managing Your Money! And we are still in the first column of a four-page, 12-column advertisement!
In other words, IBM has been forced to abandon its original strategy, which was to cripple the jr so that it could not POSSIBLY be used as a business machine in competition with PC sr. You will remember that IBM was spectacularly successful at crippling the original jr. Which meant that IBM found itself with about 100,000 jrs on dealers' shelves that weren't moving, plus another 350,000 (our estimates) sitting in warehouses. We hate to run this into the ground, but the fact is that IBM has independent outside auditors who will not permit IBM to carry those 350,000 units as being worth something if they are not selling.
So IBM management has decided (gulp!) to sell the jr in competition with the PC, that being the only way to move some of those units out of the warehouses and avoid garnering a well-publicized black eye in the financial press. (As a publicly-traded company, IBM can NOT keep the disposition of about $300,000,000 - that's Three Hundred Million Dollars - secret. Otherwise the bulldozers would already have buried those jrs deep into the side of a Tennessee mountain.) We have a few questions which we invite YOU to answer for yourself:
- What month in 1984 was the LAST month in which a PC jr production line was running? (Production lines to modify/upgrade EXISTING jrs do not count!)
- Have jr dealers successfully unloaded their original allotments of jrs? If so, have they re-ordered more jrs?
- How many jrs do YOU think IBM has in warehouses? How many jrs do YOU think IBM is selling, via new orders, to dealers each month?
- When do YOU think production lines will be re-opened to manufacture more jrs from scratch, if ever?
Page 19, Column 2
[Later: Jeff H. in Texas tells us that a couple of his doctor colleagues have purchased jrs because of a cute little graphics program that is like MackDraw, ONLY IN COLOR! Apparently those colleagues have more dollars than sense, computerwise. Also, they apparently purchased their jrs as adult toys, which is how most Macks are sold. This does seem to explain why a few jrs are selling, 512K or no 512K.]
This brings us to the new IBM PC AT, which uses a 6MHz crystal for now and hence has a bit-crunching capacity slower but reasonably close to what the 68000 is capable of. That is IBM's multi-user machine, and was intended by IBM as a multi-user vehicle to cover A T & T's low-end UNIX machines. The AT has proven to be enormously popular - AS A SINGLE-USER MACHINE! It seems that most folks like to hog all that performance all for themselves personally. Tsk.
In other words, the AT, like the original PC, is proving popular for a reason not planned by IBM. Fortunately, IBM temporarily ran out of competing models which needed to be protected, so the AT is NOT deliberately busted! The keyboard is quite reasonable - the return key is in the correct position, and is big enough to plant corn on.
This brings up the widely-anticipated PC 2 (PC II?). We haven't the foggiest idea what this machine is going to be like. We DO know what it SHOULD be like:
With much trepidation we once more call your attention to our prediction in issue #21, 18 months back. (See p.2.) We insist that was a logically correct prediction! It did not come off - yet - because Intel was late with working 80186s, and those 80186s were in VERY short supply in late '83 - early '84. In fact, only in the past couple of months has Intel actually caught up. And that is due more to the severe current market downturn than to Intel's production effort.
Because of the shortage of the 186, IBM did not come out with a computer based on that chip. And so the few computers that WERE 186-based fell by the wayside because they were obviously IBM-incompatible in a marketplace which had become paranoid over IBM compatibility! And the explosion of 186-based computers which we predicted never happened. Not YET, that is!
Now, there is unanimous consensus in the industry that IBM will introduce, around Feb of '85, a successor to the original PC. The original PC is coming up on its fourth birthday and is well due for retirement. Observing that IBM has 1.8 million 3.5 inch disk drives
Page 20, Column 1
on order, and 500,000 3.5-inch disks/month, we make the unstartling prediction that the PC 2 will use these disks. Unlike Apple with its Mack, IBM is not going to blunder and only allow one drive in the case. There will be the usual two, as in the HP 150 and the ACT Apricot.
We are sticking with our old prediction that IBM will use the 186 CPU, even though not all industry observers agree with us. Up to this point, we think what IBM IS going to do matches up with what they SHOULD do.
But we predict that IBM is going to catch the IIC/Mack disease and make the PC 2 a closed system. That way those tick birds which have prospered off the original PC will be eliminated. And all the ads that the tick birds ran, effectively advertising the PC, will be eliminated. And all the magazines that ran all the tick-bird ads and were effectively gigantic ads for the PC will go out of business. Boy, was Apple smart to drive off THEIR tick-birds! Would you expect IBM to be less astute?
We predict that in addition to the accidental busting of the PC 2 by making it a closed system, IBM will also DELIBERATELY bust the PC 2 to protect the necessity to sell off all those jrs sitting in warehouses. It will also protect the AT (an 8MHz 186 is almost exactly as fast as the 6MHz 286 which the AT currently uses - and IBM thinks the AT is a multi-user system!). Having twice selected the keyboard as the easiest thing to bust, we predict that IBM will NOT deliberately bust the PC 2 keyboard. (Remember, IBM had to EAT the last busted keyboard they sent out!) Instead, they will do the equivalent.
What, you ask, is the equivalent? Well, the purpose of a busted keyboard is to slow down data entry in an office environment which features touch typists, not disadvantaged hunt-and-peckers. Having taken too much heat over the jr keyboard, IBM will instead choose to slow down the output end - the display. How do you slow down the display? Ask Apple - Apple now has TWO computers on the market with displays which cannot keep up with a touch typist! And yes, there is a rat in the PC 2 woodpile. Or some other kind of rodent.
The introduction of the PC 2 will necessarily await the reduction of PC inventory to a suitably low level. That level might not be too awfully low; IBM is not above holding a closeout sale on the PC at prices low enough to provide the final coupe de grace for those clone-makers. That means you might see the PC 2 as early as Feb '85, which is the date most IBM watchers are predicting.
Well, there are a few specific predictions with which you will be able to (gleefully?) pillory your FNE!
Page 20, Column 2
UNBEARABLE DISGUST:
Do you realize that except for that segmented 286 CPU with too-few internal registers that the PC AT is EXACTLY the kind of personal computer we have been trying to promote in these pages for 3 1/2 years? It has a math chip. There is no shortage of DRAM. It has a single-user, mostly single-tasking operating system written in assembly! It has not a few APPLICATION programs written in assembly! It has high-density floppies. It has optional medium-resolution color graphics. AND IT IS MADE AND SOLD BY IBM! We are unbearably disgusted...
All right, so the AT has a few warts right now. Those are all fixable warts, except for the segmented CPU. And surely you realize that IBM is the ONE company which can introduce a somewhat-PC-incompatible computer and get away with it?
SYNERTEK WATCH:
Most of you are Apple types who know what an Apple II accelerator card is. There have been high-speed 6502s available for many moons but the Apple II bus and ESPECIALLY the Apple DOSs (various) limit the Apple to 1MHz. Well, as high-speed memory has come down and down in price several companies have offered high-speed 6502 CPU boards for the Apple which are mapped to slow down to 1MHz when running in the DOS memory space and such. Almost all of these are tied to the 7MHz clock built into the Apple, divided by two to provide a 3.5MHz clock for a 6502C (4MHz 6502).
One of the companies which came out with such a design was Synertek, which had a systems group (systems = single board systems such as the SYM-1 or even single-board subsystems such as an Apple speedup board). This made particular sense since Synertek was itself a major supplier of 6502Cs. Anyhow, Synertek made a pilot run of 50 of these Apple accelerator boards and advertised them for sale.
We had a customer who used a combination of 68000 code and 6502 code, and the 6502 code was not running particularly swiftly. So we took advantage of the substantial discount offered by Synertek and placed an order for 10 units.
At about that same time, Synertek sent all 50 pilot production units back east to a microcomputer show along with some gung-ho hacker types who worked for the systems division where that card was designed. Alas, while that show was in progress, Synertek management made a decision to fold their systems group. It did not take a massive intellect for those gung-ho hackers to figure out that they had a job for as long as it took to return to the west coast Synertek plant.
Page 21, Column 1
An amazing thing happened that night. Some socially unadjusted miscreants broke into the storage room where those 50 pilot production boards were stored and made off with all but about ten of them. Nobody has ever figured out who the miscreants were. We were informed that Synertek could not fill our order for 10 boards but perhaps we would like to purchase ONE board, and if we liked it, maybe purchase design rights?
Well, we bought and tried the board - more to the point, our client tried it - and it turned out that disk access was the big slowdown and none of the accelerator boards run the disk faster than usual. So we are one of about ten companies who own a copy of that accelerator board legitimately, and we'll bet none of the other nine are using their board either.
But Synertek still made those fast chips, or at least they did until last week. We called to check on availability of a 3MHz 6545 CRT controller and were informed that Synertek had officially closed down, likely permanently since owner Honeywell had been unable to find a buyer.
MICRO WATCH:
It seems that MICRO will not publish Helmut Spruth's DTACK compatible 68000 board wire-wrap design after all, since the magazine has gone out of business. We would be more sympathetic if that magazine had not ripped us off to the tune of about $2000 by TWICE running the wrong, outdated, DTACK ad copy - the second time after receiving a protest over the first incident. We had cleverly paid in advance to get a 15% discount so there was nothing we could do about it except withdraw our advertising, which we did...
THERE'S A MESSAGE THERE:
The more perceptive reader should note that being in the 6502 camp is no longer a guarantee of success. Synertek and MICRO were certainly in the middle of the 6502 camp. Has the time come for our more astute readers to stop demanding that we (DTACK) support the 6502 this and the 6502 that? Especially slow, slow 6502-based DOSs?
MODERATE VIEWPOINTS:
Some of our readers have not yet caught on to the fact that the viewpoints expressed in this rag are truly moderate and conservative. Some of you, for example, thought that we went somewhat overboard in our description of hard disk backup problems.
You will naturally want to look up the 8 Jan issue of PC magazine and turn to page 33 where they have the horror stories about poor (or NO) hard disk backups.
Page 21, Column 2
PC asserts that if a CONVENIENT hard disk backup is not available, then folk will not back up those disks. [Zounds! That folk will NOT use 300K floppies to back up a 10Mb hard disk - not more than once or twice, that is. [Gadzooks! Why, PC magazine even has the effrontery to suggest that you might want to CHECK your backup to see if it is a good one! Now, why couldn't WE have thought of some of those things?
James S., our project engineer, asked us what the minicomputer folks, who have been living with hard disks for many years, use for backup. Streaming tape, of course. And that same streaming tape is the only good, effective, reliable backup for hard disks in micros. Good, reliable streaming tape is NOT cheap - it will cost you MORE than the purchase price of a PC/XT these days. Some cheaper tape backup units are appearing, but the available evidence (such as that earlier PC article we cited) suggest that they still have some problems. Reliability costs money, it seems. Surprised? (Streaming tape IS relatively inexpensive as minicomputer pricing goes.)
The new PC writeup also provides some specific horror stories, naturally. We are anxiously awaiting letters of apology from certain readers over this subject...
3-holer math boards:
A 3-holer math board is one which permits up to three Nat Semi 32081s to be used simultaneously, since sockets are provided for three of those chips and separate decoding as well. However, it is NOT necessary to fully populate the board; it can be used with one - or two - math chips as well.
The 3-holer is set up with a jumper option to divide the 68000 clock by 2 or else to not divide the clock. This means that the math chip will run at either the same, or half, the clock frequency as the 68000.
Can the 3-holer run at 10MHz? YES! However, it must be used with either a 10MHz 68000 or a 20MHz 68000 (and if you have a 20MHz 68000 please let us know IMMEDIATELY!). This means a crystal frequency change on the DTACK board. Unfortunately, the GRANDE has dedicated delay lines designed for 12.5MHz operation, so changing the crystal is chancy at best. NOT recommended! However, the static RAM DTACK board will work very nicely with a 10MHz crystal. You ought to let us make the modification here in Santa Ana unless you are a hardware type with a well-equipped lab (and a good high-frequency oscilloscope).
An aside to Ulrich: the available Nat Semi 8MHz math chips are NOT asynchronous; you have to run them with an 8MHz Nat Semi micro or an 8 or 16MHz 68000. Got any 16MHz 68000s over there? We ain't got none here!
Page 22, Column 1
OUR TERMS OF SALE.
Some of you might not know our terms of sale. You can either send us full payment in advance, in which case we will pay for the shipping, or you can (in the U.S. only) send us 10% down, and we will ship COD via UPS, and you pay the balance plus shipping and COD charges (generally under $10 for a typical $1000 order).
For the past two years, most folk have just been sending us the full amount with their order, which either indicates a high degree of trust or a lack of knowledge that we will accept a 10% down and ship the balance COD as outlined above.
OUR WARRANTY:
Our warranty is 1 year, parts and labor. Warranty work is performed in Santa Ana and we do not pay shipping, although in the U.S. we pay for the return via UPS.
(If NASA goes back to the moon in '85 with a DTACK board and the board fails on the moon, we will NOT pay for shipping to get the unit repaired. If your neighbor takes a DTACK board to Iran, getting the board back and forth if a failure occurs is your neighbor's responsibility, not ours. Got it?)
If these warranty terms are unacceptable to you then you should not buy our products. Actually, our boards don't fail very often - but you never know, YOUR board just might be the exception.
BRITISH WATCH:
It really is a good idea to keep a weather eye on our British compatriots. You never know what you might learn... For instance, most of you Apple types have seen that big, expensive ad for a mail-order hard disk called the 'SIDER'. They want you to send $695 and wait for 4 to 6 weeks. One suspects the delay could be longer than 4 to 6 weeks; one suspects that they want the full amount in advance, no 10% down stuff - and one suspects that company has not been in business for 12 years, like a certain company we know. But the biggest puzzle to us is, WHO MAKES THAT HARD DISK? That ad by First Class Peripherals has the smell of a trading, not manufacturing, company.
Well, we were scanning through the Dec issue of Personal Computer World and on page 71 there is an ad for an identical-appearing hard disk except that the logo says "XEBEC"! How about that! And XEBEC is a long-time manufacturer of hard disk subsystems. We wonder why First Class Peripherals wants to obscure the origin of that disk? Frankly, we'd be more likely to buy it knowing it came from XEBEC, an established and reputable company.
Page 22, Column 2
There's more. It seems that back in Dec '81 ICL and Sinclair jointly announced a project to develop an inexpensive office computer. The result is on the cover of Dec Personal Computer World and is described on pp 120-6 of the same issue. This machine, called 'One Per Desk', looks like the usual Sinclair low-cost engineering masterpiece but is full-size and has a telephone handset on the left-hand side of the keyboard. The machine is designed to be left powered up at all times, and so has a switch to turn off the CRT to extend the life of that part (who said nobody uses vacuum tubes any more?). The CPU portion strongly resembles the 68008-based QL and much of the software is the same.
In case you have not heard of ICL, that stands for International Computers Ltd., another British outfit which seems to exist exclusively for the purpose of dissipating enormous chunks of the British taxpayers' money. The reason you have not seen ICL is that nobody would buy their products unless forced to do so by the British government (the way British Overseas Airways, the lucky dogs, got to buy Concordes). ICL may finally, with Sir Clive's help, have a winner. In particular, the obvious software compatibility between the QL and the One Per Desk will help both machines. Now: can the machine be manufactured in quantity and in a timely fashion?
Finally, the 32-bit T424 version of the Transputer has seen first silicon. We'll pass along more information as it becomes available. In case we forgot, we should tell you that Inmos is NOT going to provide an assembler for the Transputer! Nope, you will only be permitted to program the part in the high-level language OCCAM. Hmmm. The last chip (set) that could only be programmed in high-level was Intel's famed iAPX 432. You DO remember the iAPX 432, don't you?
DRAM GLUT
This is the morning of 19 Dec, and on the op-ed page of the L.A. Times is an article about the upcoming OPEC meeting. Here is a partial quotation from that article: "As it is, however, all market forces are relentlessly beating on the OPEC system, creating downward pressure on prices. A huge oil surplus is seeking buyers, and oil has been losing customers to other fuels, such as coal in the United States and natural gas in Western Europe.
"There is a third reason for the current oil drama. More and more oil is sold on the open market at spot and spot-related prices - that is, at prices determined by thousands of buyers and sellers, not by oil ministers."
We know that most of you are uninterested in oil prices
Page 23, Column 1
or availability except when you stop to buy gas for your car, but most of you are presumably interested in DRAM prices. Well, more and more DRAM is sold on the open market at spot prices - that is the ONLY place we have been buying DRAM (and static RAM) for three years now - and a HUGE DRAM surplus is seeking buyers!
What happened is that dozens and dozens of PC clone-makers mote or less simultaneously came to the realization that it was useless to pile more completed inventory on top of the already excessive inventory in those warehouses, and more or less simultaneously cancelled their orders for 64K DRAMs. IBM and even lowly Commodore (with its $1 billion-plus sales) noticed their sales were not doubling or tripling as they had expected and cut back their DRAM orders.
Two other things happened simultaneously: Micron Technology, a Utah outfit which is said to have a MINOR position in the world DRAM market (5% of the world DRAM market is MINOR?) dropped its prices in the U.S. to parity with its prices in Japan. [Yes, you read that correctly and no, we are not going to explain here - it's too complicated. This very much deserves a story of its own, whenever we have space available in this rag.] So for the past several months, the big players in the 64K DRAM market - Apple, Commodore, even Sun Microsystems (the UNIX box-maker) have been paying less than $2 each for 150nsec 64K DRAMs. That's one thing.
The other thing is that mass production capacity for 256K DRAMs has just come on line and found no buyers waiting, meaning no production products to plug those 256Ks into! So guess what's happened? Spot-market prices of those 256Ks slid from over $30 each to $12.50 each, quantity 1000, virtually overnight! This means that 256K DRAMs have ALREADY reached the 5-1 price differential vs 64Ks which conventional wisdom says is needed to replace 64K DRAMs in cost-sensitive applications (like the personal computer market)! If you had asked us in July when that crossover would occur, we would have SWORN that it would not take place for 12 to 18 months from last July! (Proves how smart we are, hmmm?)
Logically, everybody in the industry should now be re-tooling for 256K DRAMS. We suspect that almost everybody IS, the economics almost FORCE re-tooling. HOWEVER: be advised that market forces work in BOTH directions, or don't you remember waiting in line to buy gas a few years back? Paying high prices for gas, and thankful for the opportunity to pay high prices? The name of the game is supply and demand - as our OPEC story in this morning's paper states, "...prices determined by thousands of buyers and sellers..."
Just what do you think is going to happen to 256K DRAM prices when everybody finishes re-tooling for 256Ks
Page 23, Column 2
more or less simultaneously? And starts buying in PRODUCTION, not sample, quantities? What do you think is going to happen to 64K DRAM prices when nobody wants them and everyone is instead clamoring for 256Ks?
One can make a case for an opposing scenario: DOZENS of clone-makers turn their toes skyward in '85. The liquidators emptying those warehouses undercut every product on the market, including the Sanyo PC clone. The market for all personal computers stays soft. Prudent company executives soft-pedal new product development. In this case, everybody DOES NOT re-tool for 256Km, and the price of 256K and 64K DRAMs keep an app: 5-1 price differential, and the price of DRAM in general will decline slowly as 1985 progresses.
Which scenario is going to come true? We dunno. Perhaps yet another scenario? We dunno that, either. We, along with some others, foresaw the PC clone glut and the obvious immediate consequences for the clone-makers but we failed to predict the sudden and devastating effect of that glut on spot DRAM prices. It's a good thing we make a living as an electronics hardware designer, NOT an investment counselor!
IBM ADDENDUM:
'IBM WATCH' a few pages back was written about Dec. 1. Today is Dec 26 and we have some updates:
Although all of the PC/AT problems are fixable, it is apparently going to take longer than originally expected to fix that hard disk. IBM has announced that new orders will be filled in nine months! (Heck, even a woman can deliver that fast!) As per usual when IBM has problems, numerous conflicting rumors have been floated about the exact nature of the problem. [Is the REAL AT problem an excessive inventory of unsold XTs?] One of the more interesting observations was made by the WSJ, which asserted that IBM has proven itself to be a 'bad customer'. Result: the other hard disk manufacturers are reluctant to jump into the breach and help IBM out with its AT problems.
You think that is exaggerated? Well, IBM formerly purchased IMI drives for $365 each for its PC/XT. Those IMI drives proved highly reliable. When the contract ran out, IBM indicated it wanted a price level around $270 for the next go-round. IMI looked at its costs and decided to discontinue operations upon the completion of the existing contract! The new contract went to a Japanese supplier for a price of $260 each (one source tells us the price is $240). IBM proved to be a 'bad customer' for IMI, and IBM proved that it is more interested in price than in reliability or long-term supplier relationships. We don't think the ex-IMI folks are shedding any tears over IBM's current problems with the PC/AT hard disk.
Page 24, Column 1
The PCjr proved to be a much larger XMAS season success than we had anticipated. You already know part of the reason - the multi-media saturation advertising campaign and the brutal price cuts which made a 128K jr WITH an RGB color monitor sell for less than an Apple IIC. What you may not know is that IBM was ALSO offering a 'very substantial bonus' to the retail clerks for each jr sold (WSJ). The net result is that IBM most certainly lost money on each jr sold but they made a SUBSTANTIAL reduction in those completed jrs sitting in warehouses. IBM is obviously not going to have any problems with its auditors over the remaining jrs next year; they can reasonably assert that the jr is a seasonal product. And that unsold inventory has been SUBSTANTIALLY reduced.
Predatory pricing - selling below cost - happens to be illegal in this country. (An obvious exception is a closeout ala Timex 2000 or T.I. 99/4A.) We wonder if Apple is going to file suit against IBM for predatory pricing this past XMAS season?
THEM FABULOUS DISKS:
According to our dictionary, 'fabulous' can mean very good, wonderful'. It can also mean 'imaginary, fictitious'. Those of you who follow the trade magazines closely have seen lots more fabulous disk drives ANNOUNCED than SHIPPED. Remember two years back, when the Syquest removable disk drive was going to be shipped in quantity? Remember late '83, when Sony announced that it would be shipping production quantities of a 10Mb version of its 3.5 inch floppy, using vertical recording?
One of this year's hot rumors is a tiny, mass-produced hard disk by JVC. Mass-produced as in a totally automated factory. The entire drive is said to be almost small enough to slip into your shirt pocket. The price is projected to be astonishingly low. The entire electronics - controller and all - are said to fit into just six IC packages in the prototype version, and the production version will (naturally) feature just a SINGLE custom chip! In our naivete, we are (naturally) going to hold our breath until this package arrives...
The personal computer hard-disk marketplace in 1985 is going to be (to say the least) unstable. In a market which can logically support about 10 vendors we find about 100. With the handwriting already on the wall, a lot of those vendors are going to be trying some far-out materials and techniques in an effort to forestall the corporate grim reaper. A very few - make that very, very few - of these far-out approaches may WORK. A tiny percentage of those may work RELIABLY.
The obvious pressures of 100 vendors trying to keep
Page 24, Column 2
alive in an industry which will support 10 will severely depress prices - and quality control - in '85.
And the biggest customer for personal computer hard disks has in effect posted a huge public notice that it wants price, not reliability. (Did we ever tell you that the management and technical types coming from the mainframe/minicomputer world have nothing but contempt for personal computers and for personal computer users?) 1985 is going to be a great year for buying CHEAP hard disks. It is NOT going to be a great year for buying RELIABLE hard disks.
Oh, yes: 1985 will also be a very good year for announcements of fabulous disk systems, all of which will be delivered REAL SOON NOW. (Apologies to J.P.)
The opening salvo of 1985's hard disk wars may have been fired by Tandy, which dropped the price of the 1200, its PC/XT clone, from $2995 to $1995 on Dec 25.
ATARI/TRAMIEL WATCH:
We do not know how much you know about naming corporations. There is 'Digital Acoustics, Inc.' with a comma after Acoustics and a period after 'Inc'. because that's how the company name is registered with the California Corporation Commission. We have sat in on the drawing up of the corporate articles for two corporations, and we well remember how particular the attorney was in each case to verify the EXACT spelling of the (prospective) corporate name. It may therefore interest you to know that the corporate shell set up by Kindly Uncle Jack (hereafter KUJ) to purchase Atari is named 'Tramel Technologies'. Yes, 'TRAMEL'! Somebody was not paying attention when that corporate name was registered, it seems.
Somebody was not paying attention to a lot of things, because the $300 million in receivables which Tramel Technologies received with Atari turned out to be mostly uncollectable. And Atari's debts were maybe larger than KUJ knew (or just larger than he had planned to pay off). As a result, Atari has a very bad case of the shorts.
You may have read that KUJ bought Atari for no cash. That is misleading. Here is what happened: KUJ and his associates were required, as part of the deal, to put up $75 million cash into a corporate shell that would acquire Atari. That's Tramel Technologies. While Warner Communications received none of that money, Atari was not bought for nothing. (It has been reported that only $40 million of that $75 million has actually shown up in Tramel Technologies' coffers, however. We dunno why.)
Page 25, Column 1
Warner Communications got rid of a highly unprofitable operation (Atari) which was dragging its parent toward the abyss. Warner also received notes from Tramel Technologies with a face value of $240 million and entered those notes on its books at a 'present value' of $160 million. (A promise to pay $1 several years in the future is NOT worth $1 today. The financial phrase 'present value' accounts for the difference between the face and the real value of a note such as the one Warner received from Tramel.) Warner also received warrants to buy up to 32% of Tramel (the 'new Atari') at some point in the future.
Warner gave up some $300 million in receivables and a smaller amount in Atari debts.
O.K., pay attention now: Warner communications, in addition to divesting an operation which was a massive money sink, made certain adjustments to its corporate books. It added to the corporate books the $160 million present value of the Tramel note. It subtracted from its debts the Atari debts which were assumed by Tramel, which is equivalent to adding that sum to its books. And it subtracted from its books the $300 million in Atari receivables acquired by Tramel.
Let us assume that the Atari debts were $80 million. The net effect to Warner was a subtraction of $60 million ($160M + $80M - $300M) from its books in exchange for getting rid of that huge money sink. Tramel Technologies got $220 million ($300M - $80M) plus it got to keep the $75 million it supposedly already had. (True, Tramel issued a note to Warner for $240 million to be paid at some future date.) In other words, KUJ picked up a billion-dollar company PLUS $220 million by just putting up $75 million in earnest money, which he got to keep. You would have to think that KUJ got the better of the deal.
However, it turns out that those $300 million in receivables were worth nowhere near $300 million. In fact, they were worth only about $50 - $60 million, which is what Tramel has been able to collect. Let's use the figure $60 million and recalculate what Warner got and what KUJ (Tramel Technologies) got:
Warner comes up with $180 million ($160M + $80M - $60M) plus it gets rid of a money sink. Tramel GIVES UP $20 million ($60M - $80M) plus KUJ & friends had to (supposedly) put up $75 million of their own money - and don't forget that $240 million note, which will have to be paid at a future date if all goes well. In return KUJ gets a billion-dollar corporation which is losing money heavily. Looked at this way, we think Warner came out a lot better than KUJ.
KUJ apparently agrees with our conclusion because he has been virtually blackmailing Warner Communications
Page 25, Column 2
to retroactively come up with more money. How, you may ask, can KUJ (virtually) blackmail Warner? You have maybe forgotten about that Tramel note which Warner placed in its books at $160 million? If Atari goes down the tubes, that note is worthless! Plus some of those debts which were transferred to Tramel Technologies may come home again via lawsuits...
What kind of 'virtual blackmail'? In a news conference in London in early Dec, KUJ threatened to 'pull out by 31 Dec ('84) if Atari is not successful'. So Warner is in fact bending a little, retroactively. According to the WSJ, $10.1 million has been transferred here and another $4.5 million there for various reasons. Sums like these are nowhere near what KUJ needs to keep Atari alive and viable as a large contender in the small computer marketplace. (And remember that whatever portion of that $75 million front money that KUJ put up via Tramel Technologies legally belongs to Tramel Technologies and to its creditors, which now includes Atari's creditors. KUJ cannot pull that money back out if he walks away. It's the law!)
Atari, in time-honored KUJ fashion, has announced numerous new products which, naturally, will (honest!) be in mass production real early in 1985. (If any of you readers believe this, we are offering a real good deal on a couple of bridges that you might want to look into.) The fact is, Tramel needs big, new, money to mass-produce those new computers whatever their date of introduction. KUJ has publicly acknowledged that he plans to raise $150 million in new money via a stock offering. You had better believe that KUJ would never dilute his equity in Tramel Technologies (and hence in the new Atari) if it were not absolutely essential. Remember, he left Commodore because somebody (Gould) owned more stock than he did.
You had better believe that raising $150 million in the small computer industry today is a whole bunch tougher that it was this time last year.
Things are actually more complicated than we outlined above, of course. For instance, one of the reasons Tramel has collected so little on those receivables is that KUJ slashed prices on the Atari 800 - twice - and a lot of Atari customers applied price-protection credits to their debts. What is abundantly clear is that Warner and KUJ were trying to take each other to the cleaners; what is surprising is that Warner is perceived by many observers as coming out on top in the early going. But Warner has already had to cut the book value of that $240 million note from $160M to $135M due to Atari's shakiness...
Some quarters have made much of KUJ's attempt to turn each of an inventory of 100,000 Atari 800s into a $100 bill this past XMAS season. Even if he were
Page 26, Column 1
successful, that's only $10 million. And KUJ doesn't need $10 million, he needs $150 million.
KUJ has left a few enemies behind. He was never quick to pay a bill, for instance. Jim Strasma writes in Midnite: "It couldn't happen to a nicer guy. ...chickens have quietly been coming home to roost." (You would almost think that Jim, who with his wife Ellen has written some disk manuals for Commodore, is one of the folks who were not paid in a timely manner!)
What we have tried to present here is some of the complexity of the ongoing Warner/Atari/Tramel/KUJ business transactions. We suggest that you ignore the continuing flurry of Atari new product announcements and concentrate on two things: A) Has KUJ taken a walk? B) Has Tramel Technologies successfully raised big, new money? Either A) or B) has to happen before we can judge whether those new product announcements mean anything.
APPLE II+ HARDWARE:
A few months back the folks at Quality Software very kindly sent us a sizeable book entitled Understanding the Apple II by Jim Sather. This book is a massively detailed explanation of how the Apple II works, written from the point of view of a genuine hardware type. Chapter nine, for instance, is a 45-page description of the Apple disk controller which complements but does not duplicate the software description of that controller in Beneath Apple DOS by Worth and Lechner. There is even a nice, short foreword by an obscure hardware type named Steve Wozniak.
We had planned to wait until that book appeared in at least some of our neighborhood computer bookstores before we recommended it to you. Well, it never did. We had occasion to chat with one of the Quality Software folk recently (about the progress of Beneath Apple ProDOS) and discovered that they were mostly unsuccessful in placing that book into distribution. You see, it is about a discontinued computer (the Apple II+), and the book distributors were convinced that nobody would be interested in a book about a discontinued computer! Besides, there are so MANY books on computers these days...
If you own an Apple II or II+ and you are interested in hardware, we recommend this book highly. But if you want it, at $22.95 (#5011), you will have to order it direct from Quality Software. They want another $2.50 for postage & handling plus 6.5% sales tax if you live in California. Phone (818) 709-1721 or write:
Quality Software
21601 Marilla St.
Chatsworth CA 91311
Page 26, Column 2
For those of you who own Apple IIes, we understand that Jim Sather is working on a version of the book for that computer. We'll let you know when that book appears.
For you ProDOS fans, the good news is that Beneath Apple ProDOS is now in print, written by the same authors as Beneath Apple DOS. This is also available from Quality Software (#5054, $19.95). The new book is the same size and format as the original, but a casual glance at the insides reveals a clearer, more straight-forward organization. Either the authors have learned or ProDOS is itself more organized than DOS 3.3 or (most likely) both!
A real 'sleeper' is the unexpected SUPPLEMENT TO Beneath Apple ProDOS, which appears to be a fully annotated disassembly listing of ProDOS. This will prove invaluable to 'those experienced programmers who want to design custom interfaces' to paraphrase the introduction. This is a 124-page book in standard 8.5 X 11 inch format. It costs $10 (no #) and is only available direct from Quality Software. All of these books are soft-cover, of course.
HALGOL RELEASE v1.03,
the last FREE release, will be shipped the second week of Jan '85. Most of our troops are on vacation until Jan 2 and it will take the 3 working days of the first week in Jan to get things squared away and this issue into the printers.
PERMISSION IS HEREBY granted to anyone whomever to make unlimited copies of any part or whole of this newsletter provided a copy of THIS page, with its accompanying subscription information, is included.
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; II, II+, IIe, soft: ProDOS, LISA, Mackintosh?: Apple Computer Co. Anybody else need a 192nd million ack, have your legal beagles send us the usual threat.
SUBSCRIPTIONS: Subscriptions are $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. All back issues are kept in print; write for details. The address is:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
THIS ISSUE'S REDLANDS is the source listing of the format routine for the high density 5 1/4 inch floppy disk drives using a Western Digital WD-2797 controller chip. For the first but not last time, this code was not written by your FNE!
Page 27
3 * COPYRIGHT 1985 DIGITAL ACOUSTICS INC
4 *
5 * AUTHOR: JAMES M. SHAKER DATE: 2 JAN. 85
6 *
7 *---------------------
8 *-- ROUTINE: FORMAT --
9 *---------------------
10 *
11 * FORMAT A HIGH-DENSITY (1.28MB) DISK.
12 *
13 * THE FORMAT USES 1024 BYTES/SECTOR, 8 SECTORS/
14 * TRACK, 2 TRACKS/CYLINDER, 80 CYLINDRES/DISK
15 * SEE PAGE 127 OF THE 1984 WESTERN DIGITAL
16 * STORAGE MANAGEMENT PRODUCTS HANDBOOK
17 *
18 * GENERATE THE IMAGE OF AN ENTIRE TRACK IN MEMORY.
19 * SET PTR FOR LOGGING THE SECTOR ID LOCATIONS.
20 *
21 002118 3C7C5000 FORMAT: MOVE.W #TMPARA,A6 ;SECTOR ID LOC PTR
22 00211C 307C6000 MOVE.W #DBUFF,A0 ;TRACK BUFFER PTR
23 002120 704F MOVEQ #79,D0 ;SET FOR 80 BYTES
24 002122 10FC004E F1: MOVE.B #$4E,(A0)+ ;WRITE $43
25 002126 51C8FFFA DBF D0,F1 ;80 BYTES
26 *
27 00212A 700B MOVEQ #11,D0 ;SET FOR 12 BYTES
28 00212C 10FC0000 F2: MOVE.B #$00,(A0)+ ;WRITE $00
29 002130 51C8FFFA DBF D0,F2 ;12 BYTES
30 *
31 * WRITING $F6 ACTUALLY WRITES $C2
32 *
33 002134 10FC00F6 MOVE.B #$F6,(A0)+ ;WRITE 3 F6'S
34 002138 10FC00F6 MOVE.B #$F6,(A0)+
35 00213C 10FC00F6 MOVE.B #$F6,(A0)+
36 002140 10FC00FC MOVE.B #$FC,(A0)+ ;WRITE INDEX MARK
37 002144 7031 MOVEQ #49,D0 ;SET FOR 50 BYTES
38 002146 10FC004E F3: MOVE.B #$4E,(A0)+ ;WRITE $4E
39 00214A 51C8FFFA DBF D0,F3 ;50 BYTES
40 *
41 00214E 7200 MOVEQ #0,D1 ;WRITE 8 SECTORS
42 002150 700B F4: MOVEQ #11,D0 ;SET FOR 12 BYTES
43 002152 10FC0000 F5: MOVE.B #$00,(A0)+ ;WRITE $00
44 002156 51C8FFFA DBF D0,F5 ;12 BYTES
45 *
46 * WRITING $F5 ACTUALLY WRITES $A1
47 *
48 00215A 10FC00F5 MOVE.B #$F5,(A0)+ ;WRITE 3 $F5
49 00215E 10FC00F5 MOVE.B #$F5,(A0)+
50 002162 10FC00F5 MOVE.B #$F5,(A0)+
51 002166 10FC00FE MOVE.B #$FE,(A0)+ ;WRT ID ADDR MARK
52 00216A 3CC8 MOVE.W A0,(A6)+ ;SAVE SECTOR ID ADR
53 00216C 10FC0000 MOVE.B #$00,(A0)+ ;TRK #
54 002170 10FC0000 MOVE.B #$00,(A0)+ ;SIDE #
55 002174 10C1 MOVE.B D1,(A0)+ ;SECTOR #
56 002176 10FC0003 MOVE.B #$03,(A0)+ ;SECT LEN(1024)
57 *
58 * WRITING $F7 CAUSES 2 CRC BYTES TO BE WRITTEN
59 *
60 00217A 10FC00F7 MOVE.B #$F7,(A0)+ ;WRITE 1 $F7
61 00217E 7015 MOVEQ #21,D0 ;SET FOR 22 BYTES
62 002180 10FC004E F6: MOVE.B #$4E,(A0)+ ;WRITE $4E
63 002184 51C8FFFA DBF D0,F6 ;22 BYTES
64 *Page 28
66 002188 700B MOVEQ #11,D0 ;SET FOR 12 BYTES
67 00218A 10FC0000 F7: MOVE.B #$00,(A0)+ ;WRITE $00
68 00218E 51C8FFFA DBF D0,F7 ;12 BYTES
69 *
70 * WRITING $F5 ACTUALLY WRITES $A1
71 *
72 002192 10FC00F5 MOVE.B #$F5,(A0)+ ;WRITE 3 $F5
73 002196 10FC00F5 MOVE.B #$F5,(A0)+
74 00219A 10FC00F5 MOVE.B #$F5,(A0)+
75 00219E 10FC00FB MOVE.B #$FB,(A0)+ ;WRT DATA ADR MARK
76 0021A2 303C03FF MOVE.W #1023,D0 ;SET FOR 1024 BYTES
77 0021A6 10FC0000 F8: MOVE.B #$00,(A0)+ ;WRITE $00 (DATA)
78 0021AA 51C8FFFA DBF D0,F8
79 *
80 * WRITING $F7 CAUSES 2 CRC BYTES TO BE WRITTEN
81 *
82 0021AE 10FC00F7 MOVE.B #$F7,(A0)+ ;WRITE 1 $F7
83 0021B2 7078 MOVEQ #120,D0 ;SET FOR 121 BYTES
84 0021B4 10FC004E F9: MOVE.B #$4E,(A0)+ ;WRITE $4E
85 0021B8 51C8FFFA DBF D0,F9 ;121 BYTES
86 *
87 0021BC 5201 ADDQ.B #1,D1 ;WRITE NEXT SECTOR
88 0021BE 0C010008 CMP.B #8,D1 ;8 SECTORS DONE?
89 0021C2 668C BNE F4 ;LOOP IF NOT
90 *
91 0021C4 303C031F MOVE.W #799,D0 ;SET FOR 800 BYTES
92 0021C8 10FC004E F10: MOVE.B #$4E,(A0)+ ;WRITE $4E
93 0021CC 51C8FFFA DBF D0,F10 ;800 BYTES
94 *
95 * WRITE THE TRACK IMAGE TO THE DISK 160 TIMES
96 * WRITE CYLINDER 0 TO 79
97 *
98 0021D0 4EB82004 JSR RESTORE ;RESTORE TO CYL 0
99 0021D4 4242 CLR.W D2 ;CYLINDER COUNTER
100 *
101 * WRITE SIDE 1, THEN SIDE 0
102 *
103 0021D6 7601 F11: MOVEQ #1,D3 ;SIDE 1 FIRST
104 *
105 * FILL IN THE SECTOR ID INFO FOR EACH SECTOR
106 *
107 0021D8 3C7C5000 F12: MOVE.W #TMPARA,A6 ;SECTOR ID LOC PTR
108 0021DC 307C6000 MOVE.W #DBUFF,A0 ;TRACK BUFFER PTR
109 0021E0 7807 MOVEQ #7,D4 ;SET FOR 8 SECTORS
110 *
111 0021E2 325E F13: MOVE.W (A6)+,A1 ;GET ADDR OF SECTOR
112 0021E4 12C2 MOVE.B D2,(A1)+ ;PUT IN CYLINDER #
113 0021E6 1283 MOVE.B D3,(A1) ;PUT IN SIDE #
114 0021E8 51CCFFF8 DBF D4,F13 ;8 SECTORS
115 *
116 0021EC 4EB82084 JSR WTRACK ;WRITE THE TRACK
117 0021F0 4EB82218 JSR DLY590 ;DELAY 590 USEC
118 0021F4 51CBFFE2 DBF D3,F12 ;WRITE EACH SIDE
119 *
120 0021F8 4EB8206C JSR STEPIN ;NEXT CYLINDER
121 0021FC 5242 ADDQ.W #1,D2 ;ADD 1 TO CYL #
122 0021FE 0C420050 CMP.W #80,D2 ;ARE WE DONE?
123 002202 66D2 BNE F11 ;LOOP IF NOT DONE
124 *
125 002204 4EB82004 JSR RESTORE ;RESTORE TO CYL 0
126 002208 4E75 RTS ;FORMAT COMPLETED
127 *
