DTACK GROUNDED, The Journal of Simple 68000/16081 Systems
Issue # 28 - February 1984 - Copyright Digital Acoustics, Inc
DTACK GROUNDED, The Journal of Simple 68000/16081 Systems
Issue # 28 - February 1984 - Copyright Digital Acoustics, Inc
YES! A real, honest Trash-68 as specified at the end of page 16 in our newsletter #10, printed 20 months ago. Who woulda believed it?
It comes from Britain via the labs of Uncle Clive himself. Sinclair plans to introduce the model this spring via mail order ONLY (wait until he gets our bill for preparing his business plan - mutter, mumble), in Britain only. By summer he hopes to have ramped production up to 20,000 a month, at which time the little gem may be introduced in the U.S.
It has 128K, a 68008, two (tape) waferettes, and four applications packages (ominously, no BASIC was mentioned). The "retail" price (mail-order, remember) is expected to be in the $500 - $600 area, less CRT. Hot diggety! You know, we have always admired Uncle Clive. Let's hope he can get production levels up to the point where you and us can each buy one. We think it would make a perfect mass-market vehicle for a "polished" HALGOL.
"The price for Inter68 is $50, not $40 as stated on p.22 of issue #27... the Jul/Aug issue of the "Journal of Pascal and Ada" reports Sage II compilation rates of 1200 lines per minute when using floppies and 1300 lines per minute using RAM disk (no list files were produced). Inter68 compiles 2000 lines per minute using floppies and well over 5000 lines per minute using RAM disk... May I suggest that you seriously consider advertising in JPA?" Thomas W., Munich W. Germany
DTACK GROUNDED advertise in a PASCAL/ADA rag? We are struck dumb. Make that speechless, we've been dumb for a long time now.
We passed your performance figures along to a local Sage dealer who has been bugging us about how wonderful
the Sage and the p-system operating system of SofTech's is, and he immediately decided that Inter68 was not real PASCAL. In fact, he decided he didn't know anything about it despite the 8 pages or so that we have devoted to it.
The real kicker is that he then demanded to know whether you were unfairly running at 12.5MHz. Apparently he is unaware that if one claims to be the fastest (and he did claim that the Sage was), one cannot count cycles. "Fastest" is an absolute, not a relative.
Thomas W., whose address is on the front page of issue #27, has announced the availability of FORTRAN to run under Inter68. The package costs $40 and requires an Apple II, the Apple PASCAL and FORTRAN package in addition to a DTACK board (size unspecified, but probably the same required by Inter68) and Inter68 itself. We hope that Thomas will send us more information or perhaps a review by one of his fellow Germans - the potential user community in this case is so small that it may be difficult to get a truly independent review. (How many DTACK/PASCAL folks are also interested in p-code FORTRAN? Put another way, how many FORTRAN fans are gonna want to learn PASCAL and be willing to put up with p-code?)
(We might have the wrong guy - we lost the original announcement - but the European Area DSEx Herr Direktor will get your check to the right W. German without fail.)
It's true! Kindly Uncle Jack has resigned, "for personal reasons." His successor is already lined up. It is an interesting coincidence that Apple's Markulla and Commodore's Trameil departed immediately after their respective companies reached $1 billion in sales (yes, Commodore sold over $1 billion in calendar 1983!). We hereby declare that our prediction of future sales of Commodore's new product, written before Trameil departed, is hereby null and void. (Have you noticed how Apple's profits have held up now that Markulla is gone?)
Get rich, page 2. 32-bit micros, page 12. 16081 math chip, page 19B. Mackintosh, page 12B. Transportable assembly language, page 5B. HALGOL pages 8B, 16B, 17B. Mail page 20B. IBM ennui, page 2. Pricing policy (other) page 7. DSEx report, page 17. REDLANDS page 24 (honest).
Since we are not permitted to criticize UNIX, not being a regular UNIX user, please turn to pages 14-17 of Dec '83 Dr Dobbs and see a regular UNIX user criticizing UNIX more severely than we have.
You want the bad news? O.K., here is the bad news. You may have read about all the micro manufacturers standardizing on UNIX System 5, right? That's the one which, among other things, permits two users to modify a file simultaneously. Oh, yes, the bad news: Western Electric has just signed a contract with Digital Research to develop System 6, which happens to be file-compatible with - we do not make these things up, folks - CPM/86.
You see, AT&T is about to emerge from federal restraints which prevented it from competing in the computer business, including the personal or home computer business. What do homes have? Why, telephones. Who has the address list of all those home phone owners? You know darn well who. Who wants to lease a computer, for a low monthly sum, to all those folks who now use phones? You know that one too.
What you might not know is that AT&T has (in part) reached the same conclusions that your FNE has regarding the future of the mass-market UNIX system, and is covering its bet with CPM/86 compatible UNIX System 6. Why else the pact with Digital Research for System 6, we ask?
(A story predicting AT&T's home/personal computer strategy was printed in Sept '83 DATAMATION on page 70. The author assumed that housewives were going to use UNIX to re-calculate recipes. Sure.)
We sense that 99% of the PCs are being purchased for purely three-piece suit purposes. Others, including several of you readers, have told us "Not so!", suggesting vistas of PCs in laboratories, PCs in schools, etc. Well, the editorial staff at Softalk magazine, the IBM edition, agree with us. The last three months one turns to the back of the magazine to read "Softalk presents the bestsellers" and sees 1-2-3 with its usual 36+% of the market, then two word processors, a data base management program and a communications package in the next four places. One sees Microsoft Flight Simulator, which is not really a game, as the highest-rated non-business software package in tenth place (and dropping) with 3.6% of the market. There is only one game (Zork I) in the Dec. list and it is in a three-way tie for last place with 1% of the market.
If you read the editorial material accompanying the bestseller list, you will immediately notice a sense of frustration on the part of the editorial writers. Last month they wrote about a spreadsheet, two word processors, a data base system and a communications package. This month the same. Two months ago the same. Next month, the same. WHOOPEE, HOW EXCITING! Two quotations from the Dec. bestsellers column:
"The overwhelming business orientation of the pc can be deduced from the weakening sales of Home Accountant Plus, which earlier was one of the leading software sellers. Inasmuch as no home finance package has come forth with a serious challenge to H.A.P., its relative weakness must be attributed more to the business orientation of the computer than to diminishing popularity or strengthened competition."
And: "1-2-3 is so strong, its market share is larger than that of all American car manufacturers combined. 1-2-3 is so dominant, it has a larger share than Standard Oil before it was broken up. 1-2-3 has a bigger market share of spreadsheets than IBM has of mainframes."
PCs in laboratories? Education? We will agree, but only after adding the phrase "all seven of them". Just turn and look inside the back cover of Softalk AND LOOK AT WHAT IS SELLING! The number of PCs being used by persons not wearing a tie and a vest is statistically insignificant.
For our obligatory harangue about the virtues of assembly language mass-market application programs, we turn to a December '83 issue of INFOWORLD. Volume 5, issue 51 to be exact. In the table of contents, under SOFTWARE, we find "Infoscope: A blindingly fast data-base manager". BLINDINGLY FAST? We like it already. So we turn to page 55, and right off we read, "'No higher-level languages spoken here,' laughs Jeff Garbers, a software designer for Microstuff." More:
"To illustrate Infoscope's speed, Garbers cites an advertisement taken out recently by another data-base-manager publisher. The ad claims that the competitor's product can alphabetically sort 1000 records in 59 seconds and boasts that this is five times the speed of dBASE II.
"'We can sort the same records in three seconds," Garbers states bluntly."
So why do we need a fast data base management program? "According to Garbers, the simple user interface and quick response time allows you to work with Infoscope data in an improvisational manner... 'you can explore,' he says."
Look, the three-piece-suit environment is a time-is-money environment. No manager in his right mind wants to wait unnecessarily for an answer. The key word in that last sentence is "UNNECESSARILY". If ALL the UNIX folks agree that they will bust their operating system, then the managers have no choice but to use some other operating system like MS-DOS. The managers have done that. If the managers want a fast integrated spreadsheet they have no current choice but to buy 1-2-3. SOME of them (ahem!) appear to be doing so.
And now we have a data-base program written by a guy who doesn't like HLL, and which sorts in three seconds what dBase II sorts in five minutes. O.K., P-code fans, go compete against that program with PASCAL. Write your PASCAL in C to keep Ma Bell happy. Write the C in COBOL to please the data processing managers. Write the COBOL in Ada to meet mil specs. Oh, yes: good luck! You're gonna need it.
You might have noticed that we did not give you the date of INFOWORLD Volume 5, Issue 51. That's because each edition of INFOWORLD has TWO dates. Also, two issues of INFOWORLD can have the same date and yet not be the same issue. Confusing? It sure as hell is!
(INFOWORLD places a later date on the store copies to give them a longer "shelf life". This stratagem will fool only, well, fools.)
Ben used to write a newsletter covering the small computer industry. Lately he has teamed up with some other venture capital guys and formed the "Sevin-Rosen" investment group. They are the money folks behind Compaq, Lotus and now an outfit in Santa Monica called "Deckhand" or something similar. Compaq is the quintessential PC clone, Lotus publishes an obscure spreadsheet called 1-2-3, and "Deckhand"? Well, it's like this:
Apple stole multiple windows - and a lot of employees - from Xerox's PARC. After filing the serial numbers off, Apple presented the concept as its own invention in LISA. Although sales of LISA and all those multiple windows have been, um, disappointing, lots of folks are excited about multiple windows. So Microsoft and Digital Research are battling with multi-window software packages. There is just one little problem: as of now the total number of applications programs which run with either the Microsoft package and the Digital Research package is - TADAA! - zero.
Being an ex-newsletter writer Rosen is quick to pick up on trends, so Sevin-Rosen raided the programming staff
of a computer outfit in Santa Monica and set them up as "Deckhand". "Deckhand" has its own multi-window software package (DesQ) AND there are four applications for it.
Some of the other venture capitalists are getting tired of Rosen getting most of the ink and a larger share of the profits than those others would like. A bright person might want to take advantage of that fact. How?
You CAN, you know. Provided you are a good programmer, willing to go honey-dipping, and know how to approach a venture capitalist. All you have to do is write the next best-selling PC program. No, not next-to-best, the next, best. Since the fourth largest selling PC program will be a communications package, the third largest a data-base manager, and the second largest a word processor (soon word-processor cum spelling checker cum dictionary cum thesaurus) that means that you have to write an integrated spreadsheet and knock off 1-2-3.
How can you do that? Simple. 1-2-3 does not make use of hardware math superchargers, so it is a whole lot slower (when recalculating all the cells) than a spreadsheet that DOES. Using that 8087 socket doesn't sound so original? No, but nobody is taking advantage of that socket yet in a spreadsheet. Besides, our suggestion doesn't stop there.
You should not only make use of an 8087 for calculating most of the transcendentals, you should ALSO use a Nat Semi 16081 for performing the simple dyadic functions, such as A = B * C because it is 2 1/2 times faster than the 8087 (when working with the 8088, which is what we are talking about now). We remind you that the three-piece-suit marketplace is a time-is-money marketplace, and that 2 1/2 times speed advantage is IMPORTANT! Also, you will want that 2 1/2 - 1 edge over the unimaginative dummies who will just use the 8087.
If you will write an integrated spreadsheet in assembly and using BOTH the 8087 and the 16081, you are ALMOST a wealthy person. The final step is to know how to approach a venture capitalist. We happen to know how to do that, but we know that you won't believe us. So let us establish our credentials:
In 1968 the company in which we owned 45% of the stock was acquired by a conglomerate. The wedding was blessed by a Beverly Hills-based brokerage house, which naturally got 5% of the action. The final papers were signed in the north-of-Wilshire private residence of an assistant in that brokerage house, who oddly enough happened to collect works by the very same sculptor favored by the big cheese at the brokerage house.
In 1973, that same (former) assistant was living in the Soho district of London. Yes, the one in England. He was living there because he owed at least $600,000 that he couldn't pay. We know because $300,000 was owed to us. It seems that one heckuva recession hit in 1972, and the conglomerate suddenly became spectacularly unprofitable. No sweat, they had a long-term credit arrangement with a bank consortium. Then the president of the conglomerate pulled a truly momentous boner: he violated the credit agreement by buying another company for cash. That placed the conglomerate in technical violation of the credit agreement and the banks immediately pulled the plug. The stock dropped from $42 to $1, and that assistant happened to be holding our "put".
In 1973 the Soho district of London was where the high-priced call girls lived. We suppose an expatriate relative of the late, former Shah of Iran is living in that north-of-Wilshire former residence of that former assistant these days.
During the signing ceremony at that north-of-Wilshire residence in 1968 we were handed an original piece of sculpture to examine. It was bronze, about ten pounds as we recall. It was the lower torso of a woman, from the navel to halfway down the thighs. One of the thighs was lifted radically upward and a little way out, prominently displaying the genitalia. This is actually a famous piece of (modern) sculpture. We have seen photos of it in art books. That's books, plural. (It seems that modern sculptors cast about 50 numbered "originals" before destroying the mold.)
The above story is true. Now let us tell you the correct way to approach a venture capitalist with your entirely original idea. You say to him:
"How would you like to yank some hair out of Ben Rosen's nose?"
In early Dec, IBM's chief financial officer (Allen J. Krowe) stood up in front of some New York financial analysts (probably the same bunch Scully lied to a month earlier). He proceeded to make some uncharacteristically (for IBM) specific predictions for the coming year, 1984. Among other things, he predicted that IBM's shipments of personal computers would triple in 1994. Oh, yes: IBM has NEVER been known to deliberately lie to financial analysts. (Usually they just don't say much.)
Apparently all the financial analysts interpreted the IBM spokesman's words as meaning that sales of the PC
would triple in 1984. They believe more than 800,000 were shipped in 1983 and that lBM is predicting shipments of 2.5 million PCs in 1984. Now, those analysts are a lot smarter than we are but we interpret IBM's chief financial officer's prediction differently. We believe he was speaking of combined sales of PC, PCjr and Peanut.
If OUR interpretation is correct, pressure on the makers of PC clones will NOT be due to ready availability of the PC. (We trust that ALL of our readers understand that the continuing shortage of PCs is opening the door for those clones.) Pressure on the makers of the clones will come from the makers of other clones! There are too many of them. A store which already carries the Chameleon, Compaq and Eagle mostly won't be interested in carrying yet another brand - and there are MANY other brands, with more appearing daily.
Apparently IBM intends to refer to both of its new low-end models as the PCjr. We insist that they are sufficiently different to warrant differing names, so we will continue to refer to the littlest one, the one without a disk, as the Peanut. We don't think that IBM is going to sell many Peanuts, judged by mass-market standards. PCjrs MAY sell well, if they prove to be useful at home for persons who have PCs on their desks at work.
It might be well to keep in mind that the only personal computer that IBM has yet introduced which has done well in its ORIGINALLY TARGETED marketplace is the PC/XT. And the PC/XT is a minor variant of a computer which was originally targeted at the Apple II as a 16K cassette-based home computer. The success of Peanut and the PCjr is yet to be proven. We don't think the success of Peanut will EVER be proven.
The old doggerel goes, as you proceed through life, my friend, whatever be your goal, keep your eye upon the doughnut, and not upon the hole.
It would be a good idea to keep in mind that the continuing and increasing success of the PC is based on the fact that the computer is USEFUL in a business environment. The business environment is a TIME-IS-MONEY environment, and it always WILL be. Given a choice of several prettily-packaged but functionally equivalent application software, the one which runs fastest will be the one that sells into this market.
The businessmen who are buying 1-2-3 do not know about the wonderful theory behind HLLs such as maintainability and transportability nor do they give a damn how hard it is to find good assembly language programmers. They just want to get the job done, NOW. There really IS an opening for a faster integrated
spreadsheet, and it really IS a good idea to include a 16081 math chip with that package in addition to the 8087.
How did managers get along without these tools in the past? They had lots of high-priced flunkeys called middle managers to do the work. 1984 is the year when middle managers will begin to line up at the unemployment office. The lines will get longer in 1985. In 1990 there won't be any middle managers.
Back in 1972 DATAMATION asserted that the number of payroll programs written actually exceeded the number of computers that had been sold. That was BPC (before personal computing). Lots of folks out of those old-fashioned data processing environments still think in that implied fashion. Reader John B is especially vociferous in asserting that it is simply not possible to program, in assembly, the massive number of applications programs that will be needed for the massive number of personal computers being sold.
WHAT massive numbers of programs? The IBM PC market needs ONE integrated spreadsheet, ONE data-base manager, ONE communications package, and TWO word-processing packages (WordStar and a WangWriter emulation - MANY secretaries and typists have been trained on a WangWriter wordprocessor). John B has it EXACTLY BACKWARDS: as more and more software-compatible computers are sold, there will be FEWER programs needed. The realities of the mass marketplace, will expel inefficient programs.
While everybody has their eyes on the hardware marketplace waiting for the shakeout to eliminate everybody but Ford, Chevy and Chrysler exactly such a shakeout is actively in progress behind their backs in the software marketplace. And it is driving the staff at (IBM) Softalk magazine nuts.
John B asserts that the office of the future is turning into silicon (true), that integrated office software will be needed (true), that such software is highly complex (true) and that, therefore, the silicon office MUST be programmed in HLL because the vast number of assembly language programmers that would otherwise be needed are not available (totally false). He even asserted that it was impractical to program such a complex program in assembly.
Sigh. First, the silicon office CAN be programmed in assembly. It HAS been. The CBM 8096 (that's the Commodore 8032 like we have but with an extra 64K of bank-select memory) was the largest-selling small business computer in England a while back because of an integrated office software package called (surprise?)
Silicon Office. That's about a 56K object code assembly language program. That's a non-trivial program, done COMPLETELY in assembly.
Secondly, we only need enough assembly language programmers to write ONE American-version "Silicon Office", NOT "thousands of programmers" because only ONE program will succeed in the evolving mass marketplace, and that is the one which works best, meaning fastest in that TIME-IS-MONEY environment.
(TWO wordprocessing programs are currently dominating the PC software marketplace because there are lots of folks familiar with Electric Pencil and its descendents (e.g. WordStar) and also lots of folks trained to use the Wang office products of which WangWriter is typical. Not surprisingly, sales of WangWriter (a dedicated word processing machine) have dropped way off lately because of competition from personal computers. Everyone at Digital Acoustics refers to the office Eagle II as "the word processor" as in, "can I use the word processor now?" One can purchase six Eagle IIs for the price of one WangWriter.)
We were not kidding earlier about you having an opportunity to become rich. 1-2-3 is not an optimal integrated spreadsheet since it does not make use of the 8087. That is going to prove Lotus' undoing one day when somebody else gets smart and yes, that WILL cause Ben Rosen some discomfiture. dBase II is a grotesque antique sitting there just waiting for somebody to knock it off (somebody may just HAVE). The two word processors are less vulnerable because they are ALREADY written in assembly, as good wordprocessors always have been. We don't know anything about the communications package.
Maybe you P-code enthusiasts can program a doughnut-formula program for your local doughnut shop?
The last outfit to try and make it big with Pascal was Apple Computer with a product called LISA. You all know how well LISA is selling.
[The following conversation with P-code Charlie is fictitious.]
PcC: Is that CBM 8096 STILL selling well in England?
FNE: Better than you might think. The British mags still carry large ads for the machine.
PcC: So what IS selling well in England?
FNE: The Victor 9000 in its Sirius guise and an obscure personal computer made by an outfit called IBM seem to lead the pack these days in the business market for small computers.
PcC: AHA! Both those machines use 8088s, and therefore are not compatible with the 6502 code that SILICON OFFICE is written in. So Bristol Software locked themselves out of the emerging 8088 marketplace by writing their integrated software package in 6502 code! What (if anything) is Bristol Software selling these days?
FNE: Actually, they're selling SILICON OFFICE for the Sirius and the IBM PC. And it's still written in assembly, so it still runs fast.
PcC: But assembly isn't transportable!
FNE: Apparently Bristol Software doesn't know that.
Tandy has a new personal computer called the Model 2000. Monroe, until recently a part of Litton Industries, has a new System 2000. The Tandy machine uses the Intel 80186 and so does the Monroe. The Tandy machine has 400 X 640 graphics and so does the Monroe. SAY! You don't suppose...
There is a lot of this going around. The new Leading Edge PC clone is the same machine as the Sperry PC clone. Neither company makes the clone; Mitsuwhatchamajigger in Japan makes it.
When two companies sell the same machine the price is the same, right? Well, no. It seems the Monroe name is worth about $700 (or 23% more) than the Tandy name. We don't know how much more the minicomputer folks at Sperry think the Sperry name is worth, and frankly we don't care.
(Actually, the Monroe machine includes a Z-80 card and the Tandy machine doesn't.)
TODAY IS DEC 26, and wow, look at the bargains being advertised in the L.A. Times. One of the bargains is a big ad offering LISA for sale for $5495. The ad is from an authorized Apple dealer, namely Computique, formerly Olympic Sales. To the several persons we know of who paid $9995, congratulations! To the rest of you: look for LISA at WAY under $5000 (discounted) before a year has passed. In fact, you may see LISA at a LIST price under $5000 before a year has passed.
It appears that those persons who suggested, upon LISA's introduction, that the computer was overpriced and could be sold for $6000 were correct.
Q: Does the Grande have the "zero page" fix like the static board has?
A: Yes.
Q: Is the Grande fully socketed?
A: Yes, but the only sockets we guarantee (warrantee) are the ones we sell with DRAMS in them. On the other hand, we don't do anything silly like drill holes in the unpopulated sockets. Commodore really did that for a while over two years back. Honest.
Q: Is the Grande set up to use 256K DRAMS?
A: No. The second-generation 256Ks are not yet available, and WON'T BE at practical prices for two years. We don't know what the timing of those parts will be or how much bypassing will be required.
Q: Can the Grande be expanded beyond one megabyte?
A: Yes and no. Only one piggyback expansion board can be installed, so the basic board is indeed limited to a megabyte. But the expansion port permits up to another 15 megabytes to be installed IF DRAM expansion boards were available - and they aren't, yet. There's nothing hard about making memory expansion boards, each with its own piggyback board so that each is good for another megabyte.
But we do not make such expansion boards now nor do we have immediate plans to do so. When it comes to memory expansion boards, we let the marketplace guide us. Remember, we did not offer 128K expansion boards for the static RAM systems until some folks waved genuine coin-of-the-realm under our nose.
We pay (no pun intended) CLOSE attention to coin-of-the-realm. We also ignore idle inquiries.
Q: Has PHASE ZERO fixed their Apple-68000 cross-assembler to work with the Grande?
A: The PHASE ZERO cross-assembler actually runs entirely on the Apple. You don't need a 68000 board at all, so which one you have is irrelevant. The Applesoft file UPLOAD probably will not work with the Grande, but we have never - not once - used UPLOAD. If you remember that the PHASE ZERO assembler tacks eight extra bytes onto the front end of the object code, you will be all right.
Suppose that you have a PHASE ZERO object file on disk 2 assembled to run at $2000 on a DTACK board. These two lines will get the code into the 68000, using either UTIL4 (static board only) or UTIL7 (both static and dynamic RAM boards):
200 PRINT CHR$(4);"BLOADCODE.OBJ,A$5FF8,D2"
210 CALLQ:REM07 002000 6000 1800
Note that we load the code 8 bytes lower in memory than we send the code. This strips off the extra 8 bytes. The person writing the lines above is supposed to know that the code was assembled to run at $2000 in the 68000 and that there are 6K bytes ($1800) to send. If you don't know where the code is assembled to run and how big the file is, just execute line 200 and drop into the monitor. 5FF8.5FFF will print the address (4 bytes) and the code size (4 bytes).
Actually, we ordinarily execute line 200 (for instance) followed by:
210 PRINT CHR$(4);"BSAVECODE.O,A$6000,L$1B00,D1"
This gets the object file on the destination disk in D1 without those extra bytes. All of the demo software we provide was prepared in this manner.
Last issue we told you about our sales policy. This month we are going to tell you about somebody else's. The product to be discussed is real, the pricing ratios are real and the product plugs into an Apple II computer. But we have slightly changed the numbers (without changing the ratios) to disguise the product.
This product is nationally advertised, is sold in (some) retail stores and has a list price of $1500. Retailers pay $1000 for this product. We will suppose that you are a retailer who has purchased several of these devices for resale. One day someone comes into your store and thumbtacks a notice on your bulletin board. It seems the company which makes this gadget is giving a talk to the local Apple computer user's club and is offering a 30% discount on their product at this meeting - and 30% off $1500 is, um, $450 for a net price of $1050.
You (the retailer, remember) suddenly find competition only $50 more than YOU paid for that gadget! And they are advertising on YOUR bulletin board! Now, we KNOW how YOU feel about this. What we don't know is how our other readers feel. So, let's ask them:
THE TRUE PRICE OF THIS PRODUCT IS:
[ ] $1500
[ ] $1050
[ ] $1000
[ ] THIS IS CRAZY!
Those who checked the latter box are wrong. The fact is, the above (completely true) scenario is how the real world works. We at Digital Acoustics, who place one price and one price only on our products, are the ones who are crazy
In the last issue we told you we had an OEM customer who had spent $300,000 with us in the preceding year. What is an OEM customer if we have one price? One who pays $50 less per system (Grande) because he doesn't need manuals and demo disks and such. Yes, we DO offer the same terms to our other customers, so we continue to have just one price. Crazy, man!
Because we try hard to bring stuff to you as quickly as possible, our little rag has about as short a lead time as ANY (roughly) monthly publication. That means we personally do all the editing and don't take an extra two weeks for somebody else to carefully proof and format this newsletter. The result is a higher number of goofs than would otherwise be the case, but the shortest lead times around. Despite this, there are times when we are running nearly two issues ahead of you - even if you are a paid subscriber in the U.S.
While the Nth newsletter is at the printers, you will have finished reading issue N-1 and we will already be writing issue N+1. Imagine the lead times at a professionally produced, slick national magazine with advertisements. The editors will COMMONLY be working at least 4 months ahead of the reader. At least.
The reason we bring this up is a misunderstanding we had recently with a member of the editing staff of UNIX REVIEW. We have written in this newsletter that UNIX REVIEW did not carry anything of interest to the person who gets dirty hands on a UNIX keyboard. Well, that happened to be true of the first couple of issues, which were the ones we read most carefully.
There are now more issues out, and the last couple DEFINITELY DID have some stuff about the user. Evidently the magazine has changed its focus. Or expanded its focus as it added more staff, maybe. And remember that the editorial staff is working about four issues ahead of the readers, including your FNE. So that editorial staff member has probably seen SIX issues in progress with user-related material and doubtless thought your FNE was a dunderhead, which is true. But what we wrote was correct at the time we originally wrote it.
Nevertheless, it continues to be true that UNIX buyers are honchos shopping for a piece of gear to chain 32 peons to, and that UNIX users are mostly involuntary types who have been chained, during working hours, to a UNIX machine whether he/she likes it or not. No person not already familiar with UNIX could possibly read the tutorial on a UNIX text editor in the most recent issue of UNIX REVIEW and conclude that UNIX was desirable. (Some folks who ARE familiar with UNIX are gonna take strong exception to that last sentence. Sigh.)
About 18 months after we told you that UNIX is unsuitable for the mass personal computer marketplace, INFOWORLD has come out with a cover story on the subject. While IW has not whole-heartedly adopted our viewpoint, they are a lot closer than the "UNIX IS COMING!" stuff that prevailed a year to a year and a half ago. IW asserts that 1984 is the year when UNIX will be placed before the mass-market public. We think it arrived in 1983 and has already been rejected.
Read the IW cover story yourself. It's the issue of a little kid framed in a huge floppy disk labeled UNIX. (Good luck running UNIX on a floppy disk, kid!) We will only mention one little item from the story, and that is the assertion that MS-DOS is migrating towards XENIX, which is UNIX less the 5 megabytes of useful utilities. The story by John Markoff asserts that IBM is moving away from MS-DOS (= PC-DOS) for that reason. You see, XENIX almost equals UNIX whose rights are owned by AT&T, and IBM and AT&T are headed for a shootout.
We mention this because others have pointed out Microsoft's public announcement that their MS-DOS (written in assembly and VERY popular) is headed towards UNIX (written in C for the chosen few), via XENIX. That public announcement was made at a time when Mini-Micro Systems magazine seriously predicted that Microsoft was going to sell THREE BILLION DOLLARS' worth of XENIX licenses in 1983 - and all the gurus (we ain't a guru) were shouting agreement.
Under such circumstances, if Bill Gates believed those predictions or even PART of them - and he evidently did - NATURALLY MS-DOS would be publicly announced to be moving towards UNIX, er, XENIX. Also checkbook balancing programs and recipe computing programs (the ones which tell you to use 2.333333333333 smidges of a seasoning for 7 people).
As soon as Bill Gates realizes that MS-DOS moving towards UNIX (er, XENIX) means bye, bye IBM, MS-DOS will execute an IMMEDIATE right turn. The trouble is, Bill doesn't catch on as quickly as he used to. Either he is getting senile or he is surrounded by too many yes-men. The last guy who said no to Bill happened to be the (then) president of Microsoft, Townes by name. Shortly after saying "no" to Bill, Townes was no longer employed by Microsoft. Bill Shirley, formerly personal computer sales manager for Radio Shack, now fills Townes' former position.
It is rumored that Shirley's mantra is "Yes, Bill. Yes, Bill. Yes, Bill..." No, the rumor does not assert that he is chanting to himself.
Another writer who has privately been highly critical of OUR opinion that UNIX is unsuited for the mass computer marketplace has finally noticed, in print yet, that those UNIX systems which are available (Fortune, Wicat, Tandy 16 etc etc) are not successful. But he thinks it's the price tag that is holding back buyers. Wrong. It is the 1200 page manual that inhibits the mass-market purchaser.
Most of the readers of this newsletter are not typical members of the mass personal-computer marketplace. You will please give us credit for knowing this? UNIX is in fact a suitable operating system for full-time computer professionals, especially full-time programmers. Since many of you readers are in that latter category, UNIX may be the perfect operating system for YOU! Too bad you can't personally afford to buy a good UNIX-based machine - yet.
But even when hardware prices drop to $1.87 for a good UNIX-based machine, that 1200 page manual is going to keep UNIX a system suited exclusively for full time computer professionals.
As of today, UNIX has the additional handicap that the purchaser and the user are not the same persons.
Having passed 12K of object code, HALGOL was becoming somewhat unwieldy to work with. Also, it was IMPOSSIBLE for TWO persons to work with the code. So, we broke the code up into four groups and arranged matters so that each of the four groups could be assembled independently of the others. And, by 'freezing' all but the last file of the disk, it is now possible for two persons to work on debugging and extensions to the code simultaneously.
Each disk contains a number of text files of source code, each of which "chains' to the next source file in the sequence. The first file on each disk, in general, contains some global "equates", a jump table to the important routines on the disk, and some other equates adapted from the jump tables on the other three disks. It is these jump tables which permit separate assembly of each of the four disks.
The first disk contains the floating point and transcendentals as printed in REDLANDS in issues #15 and #16. (They have been re-assembled and slightly modified.) Also, the first disk contains the floating-point print routine printed in issue #13, modified for use with the 62-bit FP format, and the numeric input
routine printed in issue #24. Along with a few miscellaneous tables, that comes to a little over 4K object code. The first disk contains mostly mature code which will change infrequently. As other portions of the HALGOL code achieve mature status, they will migrate to the first disk.
Incidentally, a 143K Apple II diskette can hold source code equivalent to about 7 or 8K of object code.
The second disk contains HALGOL run-time code. Pages 23 thru 28 of issue #17 contain some typical run-time code which is almost identical to the code we are still using. The second disk also includes the code used to LIST the run-time code along with some utility (or library) functions common to the LIST code.
The third disk contains the screen editor - something a lot of you Apple types have never used or seen - plus a bunch of library (or utility) routines that are used during program entry and editing.
The fourth disk contains the cold and warm start entry points plus the parsing code for the HALGOL commands and functions.
This reorganization took three weeks to accomplish, including improving the documentation (mostly the comments in the source listing but also a document listing the above information in much greater detail). It is now possible for a person with a 28K DTACK board to enter, list and run a HALGOL program. (If you have less than 28K, forget it!)
As Bruce C. wrote a few issues back, writing a real, honest programming language is not a simple task. In fact, he predicted that we would not be able to bring it off (a reasonable prediction assuming your FNE is the only person working on the language). Sorry, Bruce, we cheated. That is, we have a full-time computer science graduate whose sole duty is to implement HALGOL. AND, now that we have some hardware stuff out of the way for the time being, WE (your very own FNE) are getting OUR hands dirty on the code too. (Make that VERY dirty; we have actually skipped some NFL playoff games! That's clear proof that HALGOL has a high priority at Digital Acoustics!)
Incidentally, the combination of a relatively inexperienced programmer who is a computer science graduate (him) plus a very experienced, especially in assembly language, programmer with no knowledge of computer science seems to be working well. Both of us are happy with the way the project is going and we think YOU will be too, as soon as we can LOAD and GAVE a program and we have the LET (formula) function working. That's when we will send you your last free diskette.
HALGOL includes much more sophisticated methods of redirecting the output to various devices, methods which are nevertheless simple to use. (The PR#1 and PR#0 that the Apple uses are unbearably crude.) It's like this: HALGOL provides three kinds of output, LIST, PRINT and SYS, or console output. Upon a cold start, all three are directed to the CRT. If you want to list your program on the printer, SELECT LIST 1 will direct program listings to device 1, the printer, instead of device 0, the CRT. Printed data and system output will continue to go to the CRT. If you want to re-direct listings to the CRT, key SELECT LIST 0. Unlike the Apple, hard copy is not duplicated on the CRT.
You can also SELECT PRINT #, either as a command or as a function (within a program). The device selected for printed data has no effect on where the system output (console) or where listing will go. Similarly, the SYSOUT can be selected: SELECT SYSOUT #.
So far only devices #0 and #1 (CRT and hard copy printer, respectively) have been implemented. We suppose it should be possible to print to a serial port or to a disk as well.
If you do not understand what we mean by system output, prompts and error messages are sent to the system output.
We will later implement SELECT INPUT. At the moment the keyboard is the only INPUT device, and will continue to be the cold-start default input device in the future. Other input devices? Why, a serial port comes to mind, no? If INPUT and PRINT can be selected as serial ports, a communications package could be written in HALGOL rather than assembly. (And to think that we have been unjustly maligned as being opposed to high level languages!)
How do we direct different kinds of output to different devices? Well, we have three 32-bit registers in memory called LISTER, PRINTER and SYSOUT. Each contains the address of the device driver code for the particular kind of output. To print a character we first make sure that the address contained in the register named PRINTER has been moved to scratch address register A5. Then we place the character to be printed in D7 and JSR (A5). Nothing to it.
If you have been paying attention, you will probably have wondered whether we have three separate sets of utility routines (such as HEXPR), one for each kind of output. Nope. We have an additional 32-bit register
in memory called ACTIVE. When the LIST command is executed, the first thing that happens is that we MOVE.L LISTER,ACTIVE. The PRINT command and each PRINT function begin with MOVE.L PRINTER,ACTIVE. The system prompting and error reporting routines begin with MOVE.L SYSOUT,ACTIVE.
All of the output drivers simply move ACTIVE into scratch address register A5. Like we said, nothing to it. Right, Bruce?
Since all commands and functions ASSERT the appropriate ACTIVE device, there is never a necessity to concern oneself with RELINQUISHING ACTIVE, and we don't.
We simply LOVE the enormous quantity of factual information which can be found in Mini-Micro. In the Dec '83 issue on page 66 we discover that the number of single-user microcomputers DECLINED in 1983. The number of dedicated word-processing microcomputers (including our two Eagle IIs in our judgement) DECLINED in 1983. On the other hand, professional workstations showed modest growth in 1983 and multi-user systems showed stronger growth in 1983.
In the future, the former two categories are predicted to show continued decline, with the number of single-user systems declining almost to zero by 1988. In contrast, multi-user systems are predicted to show astonishing gains in the 1985-1988 time frame. The operating system for these multi-user systems, the ones showing astonishing gains? Why CP/M, of course. Yes, CP/M and NOT CP/86 or CP/68K or MS-DOS or even UNIX.
Let's see now: Mini-Micro is directed to an audience of folks who market multi-user systems but who HATE microcomputers like the IBM PC because they can't make any money off them. You don't suppose that this influenced those predictions a tad, do you?
(We just KNOW that about half of our readers will believe that we are making this up. Nope. Check page 66, Dec '83 Mini-Micro Systems magazine.)
Some of you may be wondering by now why Mini-Micro is so screwed up so often. Simple. Mini-Micro is a SALESMEN'S magazine (saleswomen too few in this area to be statistically significant). You strip the bullshit away from a salesman and all you have left is a tiny piece of lint. Salesmen lie as a matter of course; it's part of their job. We once spent a memorable hour at a table next to five real-estate salesmen early one Friday evening. In that time, they went through five rounds of drinks - on empty stomachs. With each round, the deals got larger and their voices grew louder. By the time we were ready to leave, the deals were up to
the $350,000 range (in 1976 dollars) and there were LOTS of those deals. When we called for our check, the waitress leaned over and whispered, "The big shots behind you are keeping separate checks!"
You will find no one at Mini-Micro magazine who is the least bit contrite over that ridiculous prediction that Microsoft was going to sell $3 BILLION in XENIX licenses in 1983 because that was salesmen's bullshit. Salesmen never worry about getting caught in last year's lie because they are busy pushing NEXT year's lie - such as sales of single-user micros dropping to near-zero by 1988.
Some of the stuff in Mini-Micro is actually correct. The trouble is, there is no way (strictly within the context of the magazine) to separate the bulishit from the stuff that is correct - and that, friends, means the salesmen are doing their job properly.
(Do you realize how many folks believe anything and everything they see in print?)
This is being written on Dec 29. By the time you are reading this, the Jan Las Vegas Consumer Electronics show will be over, and Commodore will have introduced two major new products. One will be the $695 Z8000 UNIX (well, COHERENT) machine. The other will be a machine midway between the C-64 and the new $69S UNIX machine, with lots and lots of built-in software via ROM. Don't be surprised if the $695 UNIX machine is introduced at $995. Remember, the C-65 was introduced at $595. Kindly Uncle Jack DOES like to skim a little cream before going to the REAL price.
Aside from "lots of ROM" we don't know much about the midrange machine except to agree with somebody's prediction (Uncle Jack's?) that it will outsell the C-64, which means that Commodore's sales and profits will continue (for a while) to double yearly. That means that 1994 is the year Commodore's sales surpass the Fortune 500 level. (Scuttlebutt says Apple is planning several hundred layoffs. Will Apple be the company on the Fortune 500 list that Commodore displaces whenever the Fortune editors get around to acknowledging Commodore's success?)
The cheap Z8000 UNIX machine will sell several tens of thousands of copies in the next year or so. Not the next month, the next year. By Uncle Jack's standards, that is a failure. It will attract a small band of fanatical followers, as the SuperPET has. (The SuperPET is another Commodore failure.) This small band will be the gullible chumps who think running UNIX (COHERENT) on floppy disks is a great idea, especially for less than $1000.
The nation's suicide rate will increase dramatically toward the end of 1984 as all of the micro industry pundits who have been claiming that high prices were the only reason UNIX was not becoming popular auto-defenestrate.
Several persons have asked us, including one of Digital Acoustic's employees, what is to happen with the Apple III now? We thought we explained that to you in the last issue.
The Apple III has been set up as an independent business unit so that its profitability, whether positive or negative, can be easily monitored. If the business unit continues (?) to be profitable, then the Apple III will continue to be sold. If it is unprofitable, the plug will be pulled. It is that simple.
The presence or absence of other products of the Apple Computer Co. is irrelevant. Profits are relevant. Setting up a product as an independent operating unit is a very obvious (to business persons) signal that the time has come for a product to make it on its own - or else. The person who will make the decision has absolutely no emotional attachment to the computer, having arrived at the Apple Co long after the development and introduction of the III was history.
Surely you do not think that the Apple III will last (be manufactured) forever? Surely you do not think that ANY product will be manufactured forever, especially a COMPUTER?
In reply to our request for discussions of strings, we get a 13-page hand-written tutorial on the subject. (Fortunately, the author's handwriting is legible!) The author is Faithful Freeloader Tim L of Richland, WA. There is only one problem: Tim mentions fixed length strings only to dismiss them. The remainder of his tutorial is a discussion of the many ways of fighting the garbage collection problem.
(We just went back into those 15 pages to find a quotation to back up the above point. It seems Tim did not dismiss fixed strings, he just sort of slid by them.) Well, IEEE Spectrum magazine doesn't think it is possible to have string functions without garbage collection either. If we did not have TWELVE YEARS personal hands-on experience with a BASIC with no garbage collection we might agree.
Tim is no dummy though - he DOES point out, accurately, that a BASIC program is, in part, a collection of strings. And as the program is edited, "garbage" is indeed collected. The same is true of HALGOL, and a strategy is indeed required to collect the garbage in the program itself. (Make that semi-required. The major portion of the garbage is eliminated in real time as the program is edited.)
Tim does not mention owning a specific personal computer and so he may not know that Applesoft has a fatal, as in crash your program and burn your data, bug in its garbage collection routine. He may also not know that one of the more advanced techniques he mentioned to speed the process of garbage collection is standard equipment in our CBM 8032. And he obviously either does not know or does not appreciate that the problem can be avoided altogether when running a program.
Here are the principal arguments against fixed strings:
And if those arguments do not convince you then check Wang's growth and earnings for the past 12 years and consider that they did it on fixed strings. One of the cute little things Wang did along the way was to rip the office word-processing market away from IBM. Not only did they do it but they did it PERMANENTLY, making it stick. That's why one of the two leading word-processing programs for the IBM PC is an emulation of WangWriter, NOT an emulation of an IBM system. (And to think that some folks think you can't compete with IBM!)
Jan '84 BYTE magazine has a very good survey article on 32-bit microprocessors, beginning on p. 134. Considering the author draws his paycheck from Nat Semi, we were braced for a somewhat biased report, but that proved not to be the case. On the other hand, he chose to avoid performance comparisons entirely - and that happens to be our PRIMARY interest in 32-bit microprocessors (is there any other reason to go to 32 bits?) We find ourselves in full agreement with about 98% of what the author wrote, so let's discuss that other 2% briefly.
On p. 144 the author points out that the Nat Semi 32032 is fabricated using 3.5 micron design rules and contains about 70,000 transistors. (That happens to be almost identical to the Motorola 68000, which came along nearly four years earlier. Didn't we say something in the back of issue #4 about Nat Semi being a dollar short and a day late?) He then asserts that the device runs at 10 MHz and that faster devices are planned for 1984. The 32032 is, in fact, a 6MHz device. 10MHz versions are only available at Nat Semi's Fantasy Island franchise - ask for Mr. O'Rourke. FASTER than 10MHZ in 1984? Ho ho ho!
This is related to the next item: the author's flat assertion that all of the 32-bit microprocessors will outspeed all of the 16-bit generation. As a matter of fact, both the 12.5MHz 68000 and the 10MHz 68010, both of which are in quantity production, will comfortably outrun the 6MHz 32032, a part which is not yet in production.
(The alert reader will have noticed that Nat Semi does not offer 8MHz versions of the 16032 nor discuss 8MHz versions of the 32032 - a clear signal that 6MHz is in fact the top of the speed curve at this time. Remember, Motorola has sold 4,6,8, 10 and 12.5MHz versions of the 68000. It appears that 10MHz Nat Semi devices will have to await a major shrinkage of the mask, to 2.0 - 2.5 micron design rules. That is by no means a simple change.)
Also, remember the T.I. 9900 - a 16-bit microprocessor that is a BUNCH slower than the popular 8-bit micros. General Instruments and an obscure company named National Semiconductor ALSO made 16-bit micros that were notably slower than the 6502 and Z80. We suggest that there is no historic evidence to support the author's assertion that all 32-bit micros are faster than all 16-bit micros - and point out that we have offered a specific example where this is not the case.
We'd like to know more about Inmos' Transputer. It is apparently a non-von machine dedicated to multiprocessing using data-flow concepts to utilize parallelism (where possible) in (mostly) sequential programs. The problem is, every microprocessor that
has deviated from von Neumann design principles has proven to be a flop in performance - and yet, in each case, the deviation was for the express goal of INCREASED performance! You don't suppose there really IS such a thing as a free lunch, do you?
3 Jan '83
"Attention: The Publisher
"Dear Sir,
"A copy of your Dec '83, issue #26 has been referred to my attention because of your article "The Busted Tricycle." We are very sorry that you did not promptly receive the information you requested. I am enclosing that data and, even though late, hope it will restore your faith in AMD, no matter what your position may be on the 286 vs. 68000 issue.
"My compliments on DTACK GROUNDED and best regards."
ADVANCED MICRO DEVICES
Daniel F. Barnhart
Manager, Marketing Services
Dan, did you know this year is 1984?
Courtesy of Dec '83 80 MICRO (page 262) we learn that one Steve Wozniak asserts that Mackintosh will arrive in November, cost $1200, and boggle everybody. In case you don't remember Steve, he is the failed rock concert promoter who tried to kid you that the US Festival featured a 50-50 mixture of rock and technology. In the next column we learn that IBM is prepared to upstage everyone by selling 100,000 Peanuts before XMAS. We will have to rely more heavily on 80 MICRO in the future for factual information. A $1200 Mackintosh! WOW!
The Wall Street Journal is suggesting that Mack will come in at $2,000 to $2,500 - the last figure more than double Steve's, as reported by 80 MICRO. Some folks think the WSJ is more reliable than 80 MICRO in matters which have a dollar sign in front.
Since the views to be presented here are contrary to the true facts listed above, this MUST be the falsehoods dept. First, let us define our version of a vanilla Mackintosh: 68000 CPU, 128K DRAM, two 3.5 inch Sony microfloppy disks, one parallel printer port, a
serial port and a mousehole WITH a monochrome monitor and four or five applications programs, something a mass-market personal computer needs these days.
Please take particular note that we are including TWO, not one (or zero) floppy disks and we are including the CRT in our basic configuration. One can get lower prices by leaving out the floppies and the monitor but the resulting system would not be very useful.
Before estimating Mack's price tag, is there something already on the marketplace similar to that configuration? There are some similarities to the Trash 80 Model 2000 that Tandy just introduced. Both are true 16-bit machines. Both have good graphics, although the Tandy has a larger CRT, 11 inches vs. 9 inches. The Tandy costs $2995 and did NOT require a substantial development cost for software. Apple DID have a VERY SUBSTANTIAL software development cost. The Tandy disks hold more data but are conventional 5 1/4 minifloppies, which are further down the learning curve where cost is concerned. If we were just comparing the 2000 and Mack, we would have to say that Mack would be priced higher, perhaps by $500 given management with similar pricing practices. That puts Mack at $3495.
There is a new machine from England which is an even closer match to Mack. The Apricot is a true 16-bit transportable machine with an 8086, 256K DRAM, a high resolution monochrome monitor and two Sony 3 1/2 inch microfloppies. It includes the printer port, a mousehole AND a built-in modem, not just a serial port. Again, Apricot's makers did not need a large investment in software. Price: $3190. That would put Mack at $3540 in our judgement, given management with similar pricing practices.
However, the only management with pricing practices similar to Apple's is Apple. So let's compare Mack to LISA. LISA costs $6995 when stripped of software. Remove the hard disk and you have $5395. LISA comes with a full gallon (one megabyte), the same as a loaded Grande. Strip a gallon Grande down to a pint (128K) and you save $1200. Apple uses a larger markup but WE use premium 150 nsec DRAM and we buy in smaller quantities. Let's knock $1500 off LISA in a 128K DRAM version, so we are now down to $3895 without software. Apple wants an extra $1200 for LISA with a full set of software, so that $3895 might be low for Mack WITH software, given Apple's usual pricing practices.
A wise prognosticator either makes vague predictions, or, if he MUST make specific predictions he makes certain the effective date is a LONG way in the future. We are obviously not wise because we are going to make a specific prediction whose effective date is 24 Jan
'84 - about a week after you are going to receive this issue. We are talking about Mackintosh, complete with two microfloppies, monochrome monitor, parallel and serial ports and mousehole. We fearlessly predict that a 128K Mack will list at $3695 and at $3995 with 256K. Those prices will include four or five application software packages and a BASIC written in PASCAL.
Our prediction dramatically differs from ANY rumor or leak which is now circulating. Well, you have about a week to find out how loudly you can laugh at your FNE, right? (If Mack comes in at $1200 like Wozniak says, your FNE will re-assume his original name and vigorously deny ever having written a newsletter.)
Oh, yes: about delivery. The WSJ asserts that Mack is already in mass production in that fully automated production facility in Fremont, CA. So, the WSJ continues, it will be readily available immediately after introduction. The WSJ continues that Apple has learned from the LISA fiasco, where availability lagged introduction by seven months.
We say you aren't going to be able to buy a Mackintosh for about six months after introduction. Why? Well, for starters the order for the 3.5 inch Sony microfloppies was not signed until November '83. You think Sony carries a few hundred thousand of those things on its shelf for immediate delivery?
Having shot off our - keyboard? - about Mackintosh's pricing, we might as well make some more predictions about Mack. Mack is going to be a true son of LISA. People who like the way LISA does things LOVE LISA. Folks who like to do things their own way - like us - do not like LISA at all. One of the problems LISA has is that not many of the folks who like it can afford it. This problem will be less severe with Mack, but you will probably have to fork over more than $4,000 for a Mack (sales tax, you know). Not many folks spend $4,000 without giving the matter significant thought.
We call your attention to the fact that the competition in this industry is a moving target. Mack's competition will not be ONLY the PC - take a good look at Tandy's 2000 with those big, big disks, and MS-DOS compatibility to boot. And the 2000 comes with a BASIC written in assembly!
So we have a $4,000 machine that you MAY love - and you may hate. How many of you are going to like being forced to do things Mack's way, we wonder? How many of those who DO like being forced to do things one way and one way only will be able and willing to fork over $4,000? For a machine that will almost certainly run more slowly than the Tandy 2000, and have smaller disk
capacity to boot? And not be able to run MS-DOS, unlike the 2000?
Having missed this Christmas' selling season, the Odyssey folks are continuing to develop their rock-shooting 68008-based toy computer for the NEXT season, but on a low-key basis. A couple of folks got discouraged and have left Knoxville, but the project is definitely on and has been re-targeted for fall '84.
It turns out the other "cheap" 68000-based computer ain't. Cheap, that is. If you have not yet spotted the ads for the Dimension computer in BYTE and elsewhere, shame on you. The most important thing about that computer is that it will cost you over $5000 to turn on the power switch. Yes, we know the advertised price tag is $3995.
For $3995 you get the computer but that does not include the operating system, which is sold separately for $350 (CP/M-68K). AND that price does not include a CRT AND DIMENSION DOES NOT HAVE A CRT TO SELL YOU! Which means that lovely artist's rendition they use in their brochures and in the BYTE ads is a bunch of hokum, showing a matched monitor. Incidentally, with fairly high resolution graphics you ain't gonna buy a monitor at your local computer retail outlet for $79.95.
(The price list asserts at the top that CP/M-68K is included in the base price but CP/M-68K is ALSO listed further on in that price list as a $350 peripheral. The specification sheet does not include CP/M-68K in the software supplied, which is just a boot ROM with a BIOS and monitor tracer.)
So we will have to wait nearly a year for a Trash-68.
(We chatted with our colleague Ron Jeffries recently about the absence of a Trash-68 and relayed the status of the Oddysey project. He asked, "Did you know that Philips is having talks with Warner Communications over Atari?" Yes, we read about that, we replied. Why do you ask? "Well," Ron replied, "Philips just happens to own Magnavox, which owns Oddysey." We didn't know that, and it DOES make the low-key talks between Philips and Warner of more interest if Ron is correct about the ownership of Magnavox.)
Once upon a time a couple of guys started a computer company in a garage. The second version of their computer had a very simple operating system and a very simple (integer only) BASIC. Because the computer was very simple, it was possible for clever folks with
gumption (no squatters and howlers here) to make that computer do very original and clever things. This simple computer became such a huge success that the bankers started making the decisions, including that the company hire some folks who knew something about computers. The company did.
So when the company designed its third computer the experts made certain that anyone who used it would do things in the correct manner. The correct manner is, of course, the way the experts did things. (You read this in John Dvorak's InfoWorld column recently, as part of the interview with Wozniak.) For this and other reasons, that third computer never became very popular.
The company's fourth computer was given a female name rather than a number. It came with an operating system best described as a sable-lined strait jacket. If the jacket happened to fit you correctly, it is VERY comfortable. If the jacket does not fit, then it is a DAMNABLE strait-jacket!
And here comes number five, which is named after a particular variety of Apple for the time being. Number five will have a 68000 CPU, but will NOT be what this industry needs, which is a Trash-68. A Trash-68 is an Apple II with a 68000 CPU and a 16-bit data bus. A Trash-68 has a very simple operating system, a simple (integer?) BASIC and most important of all, a Trash-68 lets you do things YOUR way!
Some readers have mistakenly assumed that the term "Trash-68" is a put-down. To the contrary, we use it as a term of respect. The original Trash-80 was incredibly important and beneficial to the personal computer industry. And the personal computer industry in turn has been good to lots and lots of folks, both individuals (you and us, perhaps?) and companies.
Because the Trash-80 was simple and did things the way YOU wanted to, a LOT of Trash-80s were sold. Because a LOT of Trash-80s were sold, a LOT of software was written and some of that software was and is pretty darn good. Lots of the stuff running on the IBM PC today was originally written for the Trash-68.
There appears to be a continuing conspiracy to keep the 68000 out of the mass personal computer market. We cannot think of any other reason why a Trash-68 has not been on the market for at least the last 18 months. (Remember, we have been SHIPPING our DTACK boards for 26 months now!) An 8MHz Trash-68 would be 13 times faster than an Apple II or, if the video refresh RAM is
time-shared like the Apple II and LISA, 7 times faster than an Apple II. The manufacturing cost would be no more than $30 higher than a 128K IIe, and so it could be sold for no more than $100 more than that 128K IIe. If one were available, we'd buy it - and so would a couple of million others.
But there is a conspiracy. We spoke recently with a honcho at a software house which vends languages and operating systems for the 68000 as well as lesser CPUs such as the 6800. That software house makes a single-user single-tasking software system for the 6800 but NOT for the 68000. No sir! Their 68000 BASIC is a MULTI-TASKING language. When we expressed our strong desire for a simple, single-tasking BASIC, that honcho expressed shock, dismay and incredulity. If it's a 68000 you HAVE to have multi-tasking, he patiently explained. How will the guys in the instrument labs be able to use the computer otherwise, he asked?
Frankly, my dear, we don't give a damn about the guys in the instrument labs. Let them go buy a PDP-11 running RTX (or something) like they always have. We are just interested in what we and a couple of million others want. But his point - if it's a 68000 it HAS to be complex - continues to be the conventional wisdom. And that's why there are no Trash-68s yet.
(Do you realize that the industry is still stuck in the position we described on page 1 of issue #1 of our newsletter, 30 months ago?)
That attitude is not limited to the 68000. It also appears to prevail amongst the Z8000 crowd and the (few) Nat Semi folks as well. Kindly Uncle Jack, who has made a large fortune for himself and for long-time holders of Commodore stock by selling simple systems, has just decided that his cheap Z8000 computer will run UNIX (well, a derivative). Using floppy disks, of course. Jack has thereby uncharacteristically done an enormous favor for his competitors, especially the Apple Computer Co. Absent a Trash-68, the next best inexpensive personal computer would be a Trash-8K. As we have told you, the Z8000 is a pretty good microprocessor, one that can run a simple software system (like the Apple II has) much, much faster than the 68000 can run a complex software system (like the Fortune, Sage, Lisa, Tandy 16 have).
This worries us just a tad. If even Kindly Uncle Jack is swallowing the "16 bits gotta be complex!" bullshit, perhaps our viewpoint is incorrect? We will know soon, because HALGOL is turning into reality. Halgol is a 68000 programming language designed to combine the user-friendly interactive environment common to BASIC (with a screen editor, yet!) with the run-time
efficiency of a compiled language designed to take advantage of the vast internal resources of the 68000, AND TO HELL WITH TRANSPORTABILITY!
What puzzles us is that we appear to be the only ones interested in doing that. We may be wrong but, as a British publication recently reported, "(FNE) is putting his company's money where his loud mouth is." We'll drink to that!
The UNIX derivative that the Commodore Z8000 machine will use is Coherent, written by the Mark Williams company in Chicago. They offer Coherent for the IBM PC at $500 a copy. If you think Uncle Jack is going to pay more than $10 a copy for Coherent, get in touch. We'd love to take your money.
The Apple Computer Co has recently announced that LISA's operating system is being re-written (actually, the P-code is being compiled to native code) for greater speed. A 2-1 increase is expected. The thought of an OPERATING SYSTEM spending most of its time doing "powerful type checking" is, to us, disgusting. We all know that PASCAL types can't write programs correctly - why else all that interminable type checking? - but an OPERATING SYSTEM is supposedly debugged enough that type checking should not be necessary, hmmm?
Have you noticed that just about all of the 68000 machines that were crippled at introduction by high-level operating systems and BASICS have had their operating systems re-written in a desperate search for more speed - and the higher sales that would accompany that speed? Fortune re-wrote their operating system and removed the name UNIX from the result. LISA is dropping P-code in favor of native code. According to a Sage dealer, the Sage operating system is now native code instead of P-code. And we swear that the Tandy 16 software, all five bytes of it, got an upgrade a few months back.
Well, gee, if it's a 68000 the software just GOTTA be complex. Didn't we read that somewhere?
So what we will do is write HALGOL in PASCAL P-code to pacify the religious zealots, write the P-code in COBOL to make the big data-processing organizations happy and write the COBOL in ADA to meet mil specs. This will bring things to a halt very nicely. The language will come in two varieties; one excessively verbose for PASCAL fans and the other terse for C fans. Let's see now... things coming to a halt... we will call the first version COAGULATE and the second CLOT. Then we can try to re-write the HALGOL operating system in a desperate search for more speed just like everybody
else who uses the 68000. you gotta keep up with the Joneses, you know.
A program module written in COAGULATE:
"Take that integer value which is intermediate between the numbers one and three and place it upon the position of most significance. Then take a like value and place it upon the position of most significance, thereby relegating the previous number to the penultimate position of most significance. Then perform a mathematical summation of the two values, removing each from the position of most significance. Finally, place the result of the mathematical summation in the position of most significance."
A complete program written in CLOT:
: 2y >;
(We don't know what the example above does, but we are told that it replaces a 5,000 line APL program.)
The best way to handle branches (nasty GOTOs) as well as (more socially acceptable) GOSUBS is to a named label. For instance, 'GOSUB "CALC SINH"' is a bit more understandable than GOSUB 35410, especially if you know what SINH is. You maybe prefer 'GOSUB "PRINT PAGE"'?
In writing a computer program, we must proceed one line at a time. Suppose one enters:
210 GOSUB "PRINT LINE"
at a time when there is not yet a label named "PRINT LINE"? Do we issue an error message and toss out the line? Suppose the label DOES exist - but the line defining the label is later deleted from the program? What now, Charley Brown?
The incremental compiler concept as implemented in HALGOL acts a line at a time to provide apparent instantaneous response to the slow chemical computer in charge of the keyboard. Not even a 68000 is fast enough to re-compile an entire program, which might have 10,000 lines of code, in apparent instantaneous time. It is therefore unacceptable to require that the entire program be re-compiled, looking for GOTOs and GOSUBs, upon the deletion of a line containing a label. A different strategy is required, hopefully a more friendly one than tossing out line 210 above just because the label is not yet entered.
We believe that we have devised a workable and
sufficiently friendly strategy. See if you agree.
When compiling line 210 above, we search the label name table for a match to "PRINT LINE". When a match is not found, the label "PRINT LINE" is added to the end of the label name table and a dummy address is inserted in the corresponding element of the label address table. The dummy address points to an error message, "LABEL IS MISSING". The index of the new label is returned and stored in the HALGOL program along with the action address for GOSUB.
Later, when a line containing the label "PRINT LINE' is entered, the label name table is searched once more. If a match is found, we first check the corresponding entry in the label address table. If that address is the address of the error message, we just replace that address with the real address of the label in the program, and everything is copacetic. If we find a match for the variable name and the corresponding address is NOT the address of the error message, then we have a duplicate label situation and we report a fatal error (fatal for the particular line being entered, that is).
Given the above strategy, the otherwise horrendous problem of what to do if a line containing a label is DELETED from the program becomes trivial - we leave the label in the label name table but change the formerly valid corresponding address to point to the error message. VOILA!
After deleting the line containing the label, are there any references out there to the deleted label? We dunno. What we DO know is that if the program is run and a GOTO or GOSUB references that label, program execution will terminate and the "LABEL IS MISSING" error message will be issued.
Does this mean that extra "garbage" can accumulate in the label table? Yes. But no garbage accumulates in the HALGOL program nor does anything accumulate which can slow the execution of the HALGOL program.
We will later write a 'COLLECT" command which will remove the garbage from the various tables, but that command will not execute instantaneously even with a 12.5MHz 68000, and is best issued just before getting up and taking a stretch. Keep in mind that the total garbage ordinarily will amount to less than 3% of the total size of the program and tables and you will see that it is not a matter of great concern.
If you can figure a better label-handling strategy to fit an incremental-compiler environment, get in touch.
"I used my word processor (Magic Window II, also sold as Acewriter) to do an index for the Sensenig BASIC manual. MWII saves formatted files as binary files (versus unformatted-saved as a text file). It is a simple matter to load the binary file and delete some garbage (formatting data) at the first of the file), then (SB) split the block at the end of useful text. The file can now be (SS) saved as a Sensenig format block (up to 32K long) for safekeeping and further fiddling. While Chet's editor is reasonable for a line editor, I wanted a screen editor to do the index with lower case characters for readability, tabs, etc. and to speed up editing longer BASIC programs translated from other sources. Other word processors that use binary files probably work as well. I want to hear from others who do this experiment to get an idea which ones work. Applewriter may not be worth it - even if the textfile output is converted to binary, the result may have to be converted to ASCII before it will work.
"On the updated BASIC disk I have included a few new programs. The BENCHMARK from Creative Computing, January, p. 12 runs in 9.0 sec, same as Burroughs 820; compare to Saybrook 13 sec; Olivetti M20 13 sec; IBM PC 24 sec running single imprecision - almost 9 orders of magnitude less accuracy - 1.1E-2 (interestingly, all the 8088 clones are faster than the PC). Accuracy is 0.9E-10 (DEC VAX 11/780 double precision = 1.6E-10). D3.ORIG runs in 54 sec. COSINE draws a complex 3-D function from the cover of Myers "Microcomputer Graphics" in 40 sec (40+ minutes for Applesoft).
"Sensenig BASIC is really worth getting into, even though HALGOL is just about here. The (ID) (insert from disk) command allows the use of function or macro libraries. Since the product is a relocatable 68000 machine language program with no run-time code module (as with Applesoft compilers), I don't see why so me folks don't use it right now to simplify some of the drudgery of writing larger applications (write and compile subroutines, etc) !
"Plans are afoot to start compiling programming tips, bugs, "features", programs and such into a "leisurely quarterly" applications newsletter of DSEx which will tentatively be entitled 'The HALGOL Review'. [We just KNEW we wuz gonna get voted O-U-T OUT! - FNE] This will be distributed free for the foreseeable future to all DSEx members (if you have a disk, you're a member) and any board owner who is merely interested. Those who are merely interested in the boards or who might have some other 68000 product will be put on the mailing list as well until it starts to cripple my finances. HALGOL, Sensenig BASIC, Inter68, FORTH, C and whatever else we get going will be fair game. Anyone who wants to get on the mailing list may write
or telephone. Any programming tips of even the smallest magnitude (e.g. how to use your word processor to create source files) are welcome. Problems, questions and complaints can be aired, and all are free to help or comment.
"Let me know when you are close to distribution for the first version of HALGOL and I'll send some cash for disks. [HALGOL is NOT in the public domain - FNE] What are your latest thoughts on the documentation business ? If the documentation is printed and sent with the disk, I need new mailers, and a little extra on the disk charge for printing it. If it is on disk, there's the problem of guaranteeing that everyone can print it out (essentially need a program to do it included-Sensenig operating system does this). The initial documentation as well as the updates could be in REDLANDS, but I need to be able to distribute the updated documentation with updates of HALGOL. Have you considered sending me and Pete Soule, for example, preview copies for some "beta testing" before the thing enters its first release? We might catch some boo-boos or 'features' before the stone tablets are carved." Jeff H., Transcendent Director, DSEx
Boo-boos? In HALGOL? Jeff, surely you jest! - FNE
We have spent the last couple of weeks adding new functions to HALGOL. Some of them are pretty simple, like REM, which is the same as the BASIC REM function. Nevertheless, there are certain steps necessary for a function to be integrated into the HALGOL language. There is one additional step - a very simple one - that is necessary because of the limitations imposed by the small data storage capacity of the DISK II used by most of us Apple owners.
O.K., let's add REM to HALGOL.
First we need a unique name for our function. Is the name "REM" taken? No. So we add DC.B 3, ASC "REM' to the end of our table of HALGOL keywords, which is a linked ASCII string, Apple version. Well, almost to the end: don't forget the DC.B $00 (null) which terminates the table.
Then we add DC.W REM to the end of another table. This table is the table which contains the action address of all the HALGOL functions. Each entry in the HALGOL keyword name list has a corresponding entry in the action address table, and the Nth entry in one must match the Nth entry in the other. The best way to keep things in sequence is to add each new function to the end of the list. (Yes, we know this sounds dumb but we managed to get it wrong once yesterday!) Both of these tables are located on (Source) Disk #2.
The temporary (?) extra step is that an additional entry must be made in an additional matching table on Disk #4. This table is the address of the routine which compiles that particular function, checking for errors such as syntax errors. So we add DC.W EREM to the end of that table. The "E" stands for Edit, which is a shorter word than Compile.
Now that we have made matching entries in three tables, we must, as you might suspect, write some code. What code? Why, to (A) COMPILE (Edit) the function, (B) RUN the function, (C) LIST the function, and (D) another very simple and very tricky function - the ability to find the next HALGOL function, or "line" of code!
We assume that you understand the purpose of A, B, and C in the previous paragraph. Let us explain D more clearly. Given the address of the (start of the) 34th compiled HALGOL function in a HALGOL program, how do we find the (starting) address of the 35th function? One of the reasons for doing this is to subtract one address from the other, thus determining the memory size taken up by the function. We need this size to:
When replacing one function with another, we need to compare the sizes of the two functions. If the sizes are not the same, we will need to either expand or contract the HALGOL code.
And we will need to find the Nth function as a portion of the LIST command.
We have successfully evaded giving the code which finds the next function a name. Instead, we have named the POINTER to that code the "LINE LINK". The line link is a 16-bit pointer which is located immediately before the first word of the run-time code. In other words, at the action address for the function, minus 2. While we are at it, the LIST LINK is a 16-bit pointer which is located immediately before the LINE LINK, or at the action address minus 4. And we had originally intended for the EDIT LINK to be located immediately behind the LIST LINK, or at the action address minus 6. At this time the EDIT LINK is sort of a "vermiform appendix", having no function because a separate table has temporarily taken over its function on account of small, slow disks.
Here is the run-time code for REM, with links:
DC.W ENULL ;DUMMY LINK
DC.W LKEYSTR ;LIST LINK
DC.W ADDN ;LINE LINK
REM MOVE.W (A6)+,A5 ;FETCH REM LINK
ADDA.L A5,A6 ;NEXT ACTION ADR
JMP (A4) ;RETURN TO HALGOL
(Yes, we know this isn't the most exciting code in the world.) The link being fetched as the first line of the action code is the link in the compiled HALGOL code for REM that points at the next line. Since there are surely fewer than 32K characters in the REM comment field, a .W (word) move into A5 sign-extends B15, which is zero, into the high-order 16 bits of A5. So we have a dependable long-word value that we can add to the HALGOL program pointer A6. And that's all we have to do for the REM statement at run-time.
In this particular case, the action code does pretty much the same thing as the line link code. We are not going to show you the code for ADDN because it already existed, and what we are writing about here is HOW TO ADD A FUNCTION TO HALGOL, not how to write a complete language from scratch. We aren't going to show the code for the LIST LINK "LKEYSTR" either, because that code had ALSO been previously written (for PRINT "literal string").
But EREM needed some new code. Before we get to that code, let us discuss the HALGOL compilation process in general. Our REM line looks like this:
100 REM PROG START
(This is what the screen editor places in a buffer after a <CR>, or carriage return, is detected.) By examining the first character and discovering that it (the "1") is a numeric character, we know that the operator is inputting a HALGOL program line. The line number is evaluated as a 16-bit binary word, in this case $0064. This tells us the highest HALGOL line number is 65535.
This line number is stored as the first word in a temporary work buffer called "WRKBUF". The compilation for each line is done in this buffer.
Next we check whether the line number $0064 is already in the Line Number Table. It is not, so we A) store the line number at the end of the table (since the table is empty, it is stored in the first position at relative address $0000). B) We store the address in the HALGOL program where the line begins in the first position in the Line Number Address Table. C) We place a zero word ($0000) in the second word of the work buffer to indicate a new line. (This word is the
condition flag and is 'zero' for a new line or 'one' for an old line.) Next we place the index of the line number in the third word of the work buffer. The index of the first line number in the line number table is zero, the index of the second line number in the table is one, etc. D) We place the address in the line number table where the line is to be inserted (if a new line number) in the fourth word of the work buffer.
The above probably seems complex and in fact the explanation is much more complicated than the code. Here is the code which accomplishes the tasks in the preceding paragraph:
; STORE THE LINE NUMBER
MOVE.W D1,(A3)+ ;STORE LINE #
; LOOK FOR LINE NUMBER IN "LINE NUMBER TABLE"
MOVEA.L LNTBLS,A4 ;START OF TABLE
JSR SRCH1 ;LOOKUP LINE #
MOVE.W D7,(A3)+ ;SAVE COND FLG
MOVE.W D3,(A3)+ ;SAVE INDEX
MOVE.W A4,(A3)+ ;SAVE INSERT ADR
Now that we have four words stored in the work buffer, we next look for a valid function name (such as LET) after the line number. If there is no valid function name, we check for a leading quote (") indicating a label. But in the case of LET we do in fact have a function name. The question is, what is the index of the function name (0, 1, 2, etc)? We have to search through the ASCII linked list that is the keyword name table to find the index.
Having found the index we double it and use it to look up the action address from the action address table on Disk 2. This action address is always stored as the fifth word in the work buffer. Next we use that same doubled index to look up the "edit" (compile) address in the edit link table on Disk 4 - this is the table that is sort of temporary. And then we do an indirect jump to that address and start executing compilation code!
Here is that code:
EREM ADDQ.W #2,A3 ;PTR PAST REM LINK
JSR INPTXT ;GET THE STRING
MOVE.W A3,D7 ;END POINTER
SUBI.W #WRKBUF+10,D7 ;SIZE OF TEXT
MOVE.W D7,WRKBUF+10 ;STORE REM LINK
BRA REWIND ;STORE HALGOL CODE
In the code above, A3 is a pointer to the temporary HALGOL work buffer, WRKBUF. This buffer already contains the line number, condition code, line index
and address of the line in the line number table plus the action address for REM, 5 words total, before we reach label EREM. That means we enter EREM with the work buffer pointer, A3, pointing at WRKBUF+10. This is where the link goes that is used at run time to skip over the text string. So we first just add 2 to point at WRKBUF+12 and call a subroutine that already existed to store the string in the buffer. This subroutine is smart enough, for example, to store an extra null ($00) at the end, if necessary, so that we come out of the subroutine with A3 pointing at an even address,
Next we move the pointer A3 to D7 and subtract the address of WRKBUF+10 from it, giving us the size of the string. We store this number in WRKBUF+10 as the link the run-time code uses to skip over the string.
We have covered all of the code needed except the LINE LINK and the LIST LINK. Here they are:
ADDN CLR.L D0
MOVE.W (A6)+,D0 ;SIZE OF PARM FIELD
ADD.L D0,A6 ;PTR TO NX LINE
JMP (A4) ;FIND NEXT LINE
In the above code, A6 is the pointer to the HALGOL compiled program but JMP (A4) does not, in this case, jump to the HALGOL code. Instead, it jumps back to a subroutine which is locating the Nth HALGOL line.
LREM JSR LISTKEY ;LIST THE KEYWORD
ADDQ.L #2,A3 ;SKIP THE REM LINK
JSR LISTSTR ;LIST THE STRING
JMP LINFEED ;<CR> & DONE
And that, folks, is all the code that is needed to implement the REM function. Yes, we know it seems complex for such a simple function, but all of the elements must be in place for even the simplest function to work. It really wasn't a bit harder to install the LOCAL function (local variables) discussed in the last newsletter. Yes, HALGOL now has local variables that work!
There is an unexpected glitch in the Nat Semi 16081 math chip which may affect some operations. When sending multi-word data to the 16081, if a long delay is encountered between data words, the initial data may be lost. It is almost as though dynamic registers are being used inside the 16081.
This was called to our attention by (DELETED). We were asked to check and confirm this bug, as we can easily insert controlled delays between adjacent words while the 16032/16081 coprocessing system cannot.
We discovered that data was lost after a 60 millisecond delay in a cool room with lots of open-air ventilation. When we placed a sheet of paper over the 16081 to simulate the heat one might encounter in a crowded chassis, the data was lost after 20 milliseconds. Incidentally, this came as an unexpected surprise to the folks at (DELETED).
This has obvious implications for the sort of excessively-complex, multi-tasking environments favored by miniconputer-oriented systems organizations if Nat Semi does not correct the design. It is irrelevant to simple, single-tasking environments such as favored by - ahem - Digital Acoustics.
The following report was prepared by our young Project Engineer:
In issue #25 we published a schematic to interface the 16081 to the 68000. Since then we have learned more about the 16081; such as the duration of the SPC pulse can not exceed the value X+Y, where X is the period of the clock going to the 16081 and Y is (as far as we can tell) 30 nano-seconds. Because we use the 68000's Address Strobe to generate the SPC for the 16081, the length of the SPC pulse is affected by the number of wait states on the 68000. On our static ram board (Dtack Grounded) there are no wait states so the Address Strobe is low for approximately 185 nano-seconds. This is right at the edge of not working. On our dynamic ram board (Dtack Grande) there is one wait state on every memory cycle, which means that the Address Strobe and the SPC will be lengthened by 80 nano-seconds. This will not work.
There are two ways of fixing this problem. One is to increase the period of the clock going to the 16081. The second is to shorten the SPC pulse. Because it is not desirable to slow down the clock of the 16081, we chose the second method. What we did was to use a mono-stable triggered by the Address Strobe to generate the SPC pulse.
Once we could control the length of the SPC pulse, the question of how short can the pulse be. According to our 16081-6 spec sheet, the minimum SPC pulse width from the CPU is 100 nano-seconds. So we chose a value which meets the requirements of the 16081 and all of the set-up and hold time requirements of the system.
"...didn't realize newsletter was so unabashedly biased in favor of your company's stuff! What the heck are you TALKING about? Better send some sales literature.., and more on the 16081 board. (Just think, I worked on an OS for Trident subs!)" Brian C., Warminster PA
We gotta admit that issue #27 is a tough one to break a new subscriber in on, Brian. Perhaps we did not make it sufficiently clear that that remarkably high performance could be attained by ANY 12MHz 68000 - 6MHz 16081 combination. (Have you peeked at the title at the top of page 1?) We've shipped six to eight such combinations to real customers already. Who else is shipping? Hmmm? Incidentally, be advised that we have NEVER claimed to be unenthusiastic - FNE
P.S.: Do we get credit for letting other folks know how to use the 68000/16081 combo?
P.P.S. If you don't want to take newsletters in sequence just like everybody else, you will have to pay $2.50 for specified individual copies - just like everybody else. Look in the info sheet we sent you at the newsletter prices. The EMS review was in #21, incidentally.
Too much in the past month, actually. We don't know whether it is the holiday season or what, but we have recently been getting more mail than we can handle. Not junk mail or mail from ignorant folks but thoughtful letters which clearly deserve thoughtful answers. Unfortunately, we simply have not had the time to answer all of them. There are just so many hours in the day - and night - and weekends. The general rule is, if you write asking yes-no type questions and enclose an SASE, you will get an answer. The two page essay type replies are no longer being written.
Since we are now writing HALGOL code, HALGOL documentation, HALGOL demo programs and this newsletter, this situation is not likely to change soon. If you are one of the deserving folks who are not getting an answer to their carefully written letters you have our sincere regrets if not apology - we only apologize when we goof, and this is not a goof.
If you desperately need information and cannot find it in this newsletter or elsewhere, you may be out of luck. (Perhaps we have simply accumulated so many fellow-travellers that we cannot provide one-on-one information to ANYBODY?)
"If you send gift cards - this is a Christmas gift from his daughters (Katie, Evie, & Betsy)." Sally Carbrey Raleigh NC
Hope you enjoy our rantings, Bruce.
"Fuel for the '8086 is hard to program' fire: an associate of mine is an experienced assembly language programmer. He has programmed virtually all the
micros: 1802, 8048, 8008, 8080, 8085, Z80, Z8000, etc. He owns an IBM PC and has written software for it. He feels that programming on the 8086 family takes 15-20% more effort than programming a Z80! This opinion is shared by everyone I have talked to. Segmentation is a real pain to program around." Max S., Thousand Oaks CA
Your associate owes it to himself (herself?) to get some experience programming the 68000, Max. It is (honest) VERY friendly. Sorry about bowdlerizing that last sentence - FNE
"I think you are wasting your time & effort developing HALGOL - suggest redirect to developing DTACK GROUNDED 68000/IBM PC simple operating system.
"I use APL on my IBM PC and believe that the addition of a 68000/16081 would be a natural. There are several APL packages around." A. L. J., Manhattan Beach CA
A.L., we just know without looking that we can't afford any of those 68000-APL packages. In addition, those packages are all designed to work on a specific operating system (definitely not OUR simple system!). HALGOL, and its operating system (which you are not supposed to notice is there!), will run equally well on the IBM or CBM-64 or Apple. Sorry, we're going to continue to waste our time & effort - FNE.
"...I have found in a big German electrical engineering magazine (that) DTACK GROUNDED made the headlines here.
"I would like to see published in the newsletter the sort of article that Mr. Soule wrote describing his monitor about, for example, MINDS 1.0 or the C compiler." Thomas W., Munich W. Germany
We'd like to see either descriptions or reviews of MINDS and C ourselves, Thomas. Unfortunately, somebody has to write them, and so far, nobody has. Did you notice that the German magazine spelled 'Eloi' correctly? - FNE
"My last newsletter said that Redlands started on p.29 and my newsletter cuts off with page 28. General error or was I slighted?" [Name and city withheld]
Sir, you have fallen for one of the oldest publishing gags around. The earliest recorded example is an edition of the Mt. Olympus Post-Dispatch, which carried the following:
"While Europa desperately tried to cover her ripped bodice, the bull pushed her backward onto a pile of hay. She watched in helpless terror as (continued on tablet 9)" There were, of course, only six tablets in that edition.
"Much of the current thought in Computer Academia reminds me of the Bauhaus schools, with Niklaus Wirth playing Walter Gropius. There is an increasing tendency toward parochial forms and a general contempt for the 'user'. Efficiency is a minor consideration next to the 'art' of programming and this 'art' is supposed to be revealed in the expression or style of the writing rather than the speed or size of the program itself.
"Such thinking may be possible in mainframe or academic environments but fails when a single user is waiting on a single computer. The current poor showing of various 16-bit machines in the marketplace is richly deserved. Perhaps those in the industry who take the public for granted will realize that the public is not as gullible as they think.
"...What ever happened to the mythical Case/Power Supply?" John W., Austin TX
The mythical Case had its structural strength problem solved in this past month. We are now getting quotations on the wooden end pieces and doodling uninspired renditions of stuff to be silk-screened onto the case to let others know what's inside. We hope you enjoy your half-gallon Grande and the math board - FNE.
"'Mal Hackson' gave a seminar at Northrup a couple of weeks ago. It was a bit early in the morning for me, but my associate Paul made it. ...Mal asked what kind of development system we were using for our 68K machine. Since I do most of the development on my DTACK board, Paul replied as such. Mal then looked at the field service rep for Northrup's Exorciser systems and asked, "should we support these people?
"You published a 'kit' for a high-performance 68K computer...
"Perhaps the reason you get more pro-HLL letters is that you are stating a fact that is so self-evident to those who agree with you that it not only does not warrant a response, but is downright boring to read about all the time ('the sky is blue', 'inflation is rising'). I disagree with the attitude 'since this processor runs ten times faster, we can use this HLL that runs 12 times slower and hardly sacrifice anything'. Boring subject. END." Nigel R., Torrance CA
Nigel, Mal was kidding - we think. Lots and lots of folks have written to us about that 'kit'. Apparently nobody noticed that it was proposed (written up) by Jeff H., the DSEx Director. Incidentally, Nigel, when you referred in your letter to 'OS-9 Level 2 being a multi-abuser' system, that should have been 'multi-user'. Watch your spelling.
We would like to get you into the same room as, for instance, John M. John makes his living programming on the very highest performance minicomputer made by a prominent minicomputer manufacturer. He writes "shoot the invaders" programs (REAL invaders, John works indirectly for the Pentagon writing war games). For the kinds of programs John writes, that top-of-the-line mini sometimes gets bogged down, so he is fully aware of the need for performance. And yet John thinks it doesn't matter that LISA is slow! John thinks LISA sells poorly because it costs too much. When we point out that the similarly priced IBM PC/XT sells very well indeed with an assembly-based operating system and an assembly-based BASIC, he says the sales are because of that three-letter logo.
Check the year's first issue of InfoWorld. Kathy Chin gives LISA's software an award for excellence, even though she acknowledges that LISA's sales are slow. Despite this, she asserts that LISA's software is successful! (Remind us to look up 'successful' in a good dictionary. Kathy is obviously using a different definition than the one we are thinking of.) Then turn to John Dvorak's column in the back of the same issue and see where he awards the 'Dubious Achievement Grand Prize' to LISA-compatible software packagers!
What we are saying, Nigel, is that there appears to be a bifurcation of beliefs - most folks are on one extreme or the other with few in the middle. Since sales of HLL-based machines are dismal to say the least, it appears that most folks are on OUR side, and that the other side appears large because they make a lot of noise. This has been our perception of the PASCAL freaks as well - there are very few but they make one hell of a lot of noise! - FNE
"Please entend my subscription to the 'Intel Terrorist's Newsletter', On the lighter side: HALGOL for LISA & MACK? How about a 'Mucho Grande' with a 68020, NEC 7220 graphics and a 16081 or 68881 math chip?" Chuck D., N. Hollywood CA
We prefer Macho Grande, Chuck. Lay some 68020s on us, and watch us go to work! HALGOL for LISA? Who can afford it? For MACK, the question is, has Apple written the operating system to permanently lock the user out of the supervisory mode? If they have, then no HALGOL for MACK - FNE
At halftime during the Redskins-49ers football game, there was a commercial for the HP touch-screen personal computer. As the operator touched the screen, some file folders slid by. When she took her hand away, a file folder labeled "Kapoor" was in the center of the screen. Ha ha. Last we heard, Mitch Kapoor, er, Kapor
was not poor. The other thing we noticed is that there were only THREE folder labels visible on the entire screen! (The last was Kapok and we did not catch the first - we must be losing a step.) Here we have an 80-column 24-line CRT and we can only get THREE names on the screen? Why do we feel it is sizzle, not steak, that is being sold?
Sit down in front of your personal computer. Reach out and put your finger on the CRT. Now hold it there for awhile. Hold it there. Hold it there for a while longer, now. How are you going to like to work a 40-hour week with one of these little jewels?
Saw a well-done ad (commercial) for the Tandy 2000. Saw 3 or 4 ads over the two football games for the IBM PC - all of them the ad that shows the tall stack of software. Didn't see a single ad for the Apple Computer Co.
After carefully telling you about the two major Commodore computers to be announced in early Jan, and after explaining to you that the one which is being touted the loudest wasn't gonna sell, catastrophy struck! According to Electronic News, 2 Jan '84, somebody ELSE has correctly identified that the UNIX (well, COHERENT) keyboard machine ain't gonna sell. That somebody else is (sigh) Commodore.
Commodore has made a last-minute decision to not introduce the UNIX machine. It seems they went out and showed the prototype to a few of the folks "on the street" and the "folks on the street" went BLEAAHH! No software, no BASIC, and worst of all, no zero page for Jim Butterfield to document (inside joke exclusively for Pet types). Commodore may introduce this machine in another six months and then again they may not. We think, now that they have correctly identified that the machine won't sell, that they won't. Another UNIX machine has just bitten the dust. (It'll be test-marketed in West Germany, a small market where Commodore can't lose too much money.)
And we're mighty unhappy because we are going to have to continue to put up with the folks who think UNIX is not selling well because the boxes are too expensive. Obviously, Commodore is smarter than those folks,
How smart is Commodore? Smart enough to sell $425 million in the fourth calendar quarter! It's much to early for audited results, but it looks like they will make about $50 million after taxes in the fourth quarter. Will somebody please ask David Bunnell just exactly what kind of trouble Commodore is in? Would anybody like to compare the VERY BEST quarter the Apple Computer Co. has ever had in its history against
Commodore's most recent quarter? (Scully's gonna turn green when he sees that profit figure!)
Do you remember the frenzy of interest in Peanut before it was released? Have you noticed how little interest there is in the PCjr now that everybody knows about it - and its limitations? Well, if YOU haven't noticed, Electronic News has. They sent a team of reporters out to interview retailers about the on-going interest in jr. There isn't any.
And some folks think IBM can do no wrong!
[later] IBM has just announced their new operating system PC/IX, for Interactive Executive. It's a UNIX work-alike developed by a 125-employee software house in Santa Monica. Available in April for (choke) $900.
When we predicted the price of Mack a month ago, we did not know that Apple had cleverly designed Mack so that only one microfloppy drive could be mounted internally. Everybody out there who likes to work with a single floppy drive, raise your hand. What? No hands? Is everybody asleep? Or (gasp!) is it possible that Apple has goofed - again?
Most of your subscriptions expire with this issue. How can you possibly do without this sober, sedate, scruffy rag? (lf you do not know when your subscription expires, look for a number on the mailing label. If it is 28, then this is the last issue you will receive.)
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, SOS, ProDOS, LISA, Mackintosh?: Apple Computer Co. Anybody else need a 172nd million ack, have your legal beagles send us the usual threat.
SUBSCRIPTIONS: Beginning with issue #19, 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. The address is:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
The code in REDLANDS this month is the real, working code to SAVE and LOAD HALGOL programs from the HALGOL environment. SAVE works by dumping the HALGOL program and all necessary pointers and tables into the host beginning at $6000 - that's easy. It then actually peeks into the 6502 code space and determines the location of the end of the existing BASIC program, which just happens to the the short Applesoft LOADER program (see the end of page 27). You probably know the end is marked by a $0000 "line link" and that the variables are stored immediately after that link.
SAVE then lifts the 64 bytes beginning with the $0000 link into the 68000 and places them in a temporary buffer. After calculating two MORE line links (the Applesoft variety) it takes the data found at the end of page 28 and stores it beginning at the position of the former $0000 link. This definitely over-writes some variable values, in case you were wondering. If you examine the data at the end of page 28, you will discover that it is two Applesoft-type program lines which save the binary HALGOL data found at $6000 and then performs a GOTO 63997. Line 63997 is the line immediately preceding the two new lines we are adding, and it just happens to be the line which jumps into the 6502 side of the very simple BIOS.
So, once the HALGOL code and the two new program lines are in the host, SAVE issues a CMD01 (return to BASIC). The 6502 now executes, in BASIC, the first of the two new lines, saving the named HALGOL program file as a binary file. Then the next line returns the 6502 to the simple monitor, and the SAVE command now restores those 64 bytes, erasing the two new program lines and restoring the variable values.
We haven't mentioned taking care-of the length of the binary file or the name of the file, but we do that, honest.
The LOAD program works pretty much the same way but not in the same order, of course. Commands 7 and 8 are deliberately written to mimic the CALLQ:REM07 and 08 that many of you are familiar with on the Applesoft side of the host:DTACK interface. In each case one places a 68000 address in A5, a host address in D6 and a byte count in D4. CMD8 sends bytes from the 68000 to the host, and CMD7 fetches bytes from the host to the 68000.
We are printing this code to serve as a guide for the gung-ho types among you who have DTACK boards, and to prove that we are making substantial progress with HALGOL for less gung-ho folks and for those who have not yet purchased a DTACK board, but are leaning.
2 LIST
3 ;-------------------
4 ;-- COMMAND: LOAD --
5 ;-------------------
6 ;
0054AA: 48E7FFFE 7 LOAD MOVEM.L D0-D7/A0-A6,-(A7) ;SAVE REGS
0054AE: 3C7C55B4 8 MOVE.W #LNAME,A6 ;PTR TO NAME FLD
0054B2: 4EB85542 9 JSR NAME ;SET UP PROG NAME
0054B6: 4EB8556E 10 JSR GETLINK ;GET HOST LINE LINK
11 ;
12 ; CALCULATE AND STORE THE LINE LINKS FOR THE
13 ; TWO LINES TO BE APPENDED TO THE BASIC PROG.
14 ;
0054BA: 3A7C55CB 15 MOVE.W #LLINK+1,A5 ;2ND LINE LINK
0054BE: 7231 16 MOVEQ #$31,D1 ;LINK OFFSET
0054C0: 4EB85614 17 JSR CSLINK ;CALC & STORE
0054C4: 3A7C55A5 18 MOVE.W #BLOAD+1,A5 ;1ST LINE LINK
0054C8: 7226 19 MOVEQ #$26,D1 ;LINK OFFSET
0054CA: 4EB85614 20 JSR CSLINK ;CALC & STORE
21 ;
22 ; LOAD THE PROGRAM FROM DISK TO THE HOST
23 ;
0054CE: 4EB85592 24 JSR LSPROG ;LOAD THE PROGRAM
25 ;
26 ; LOAD THE PROGRAM FROM THE HOST TO THE 68000
27 ;
0054D2: 367C3584 28 MOVE.W #CMD7,A3 ;PTR TO CMD7
0054D6: 4EB8550E 29 JSR SGTBLS ;PROG HOST TO 68K
30 ;
31 ; THE PROGRAM IS LOADED, NOW:
32 ;
33 ; 1) MARK THE END OF THE PROGRAM
34 ; 2) MARK THE END OF THE NAME TABLES
35 ; 3) MARK THE END OF THE LINE NUMBER TABLE
36 ; 4) CALC & STORE THE LINE COUNT
37 ;
0054DA: 20781584 38 MOVE.L SOH+4,A0 ;PROG END
0054DE: 30B8354E 39 MOVE.W END+2,(A0) ;APPEND END
0054E2: 2078159C 40 MOVE.L SOLBN+4,A0 ;LBL NAME TBL END
0054E6: 4210 41 CLR.B (A0)
0054E8: 207815AC 42 MOVE.L SOCN+4,A0 ;CONS NAME TBL END
0054EC: 4210 43 CLR.B (A0)
0054EE: 207815BC 44 MOVE.L SOVN+4,A0 ;FP NAME TBL END
0054F2: 4210 45 CLR.B (A0)
0054F4: 2078158C 46 MOVE.L SOLN+4,A0 ;LINE # TBL END
0054F8: 30BCFFFF 47 MOVE.W #$FFFF,(A0) ;HIGHEST LINE #
0054FC: 91F81588 48 SUB.L SOLN,A0 ;SUBTR TBL START
005500: 3008 49 MOVE.W A0,D0 ;2 * # LINES
005502: E248 50 LSR.W #1,D0 ;LINE COUNT
005504: 31C0154C 51 MOVE.W D0,NLINES
52 ;
005508: 4CDF7FFF 53 MOVEM.L (A7)+,D0-D7/A0-A6 ;RESTORE REGS
00550C: 4E75 54 RTS
55 ;
57 ; TRANSFER A PROGRAM BETWEEN THE HOST AND
58 ; THE 68000; THE DIRECTION DEPENDS ON A3.
59 ;
00550E: 7009 60 SGTBLS MOVEQ #9,D0 ;9 TABLES
005510: 3C7C1580 61 MOVE.W #SOH,A6 ;PTR TO POINTERS!
005514: 363C6000 62 MOVE.W #$6000,D3 ;HOST ADR TO D3
005518: 3C03 63 MOVE.W D3,D6 ;HOST ADR
00551A: 3A4E 64 MOVE.W A6,A5 ;ADR IN 68000
00551C: 3800 65 MOVE.W D0,D4
00551E: E74C 66 LSL.W #3,D4 ;8 BYTES PER TABLE
005520: 31C4151A 67 MOVE.W D4,COUNT ;INIT COUNT
005524: D644 68 ADD.W D4,D3 ;NEXT HOST ADR
005526: 4E93 69 JSR (A3) ;XFR 72 BYTES
005528: 5300 70 SUBQ.B #1,D0 ;XFR 8 TABLES
71 ;
00552A: 2A5E 72 SGTBL1 MOVE.L (A6)+,A5 ;TABLE ADR
00552C: 281E 73 MOVE.L (A6)+,D4 ;TABLE END
00552E: 3C03 74 MOVE.W D3,D6 ;HOST ADR
005530: 988D 75 SUB.L A5,D4 ;NUMBER OF BYTES
005532: 6708 76 BEQ SGTBL2 ;SKIP IF ZERO
77 ;
005534: D978151A 78 ADD.W D4,COUNT ;BYTE COUNT
005538: D644 79 ADD.W D4,D3 ;NEXT HOST ADR
00553A: 4E93 80 JSR (A3) ;XFR ONE TABLE
00553C: 5300 81 SGTBL2 SUB.B #1,D0 ;DECR TABLE COUNT
00553E: 66EA 82 BNE SGTBL1 ;XFR 8 TBLS
83 ;
005540: 4E75 84 RTS ;ALL BYTES XFR'D
85 ;
86 ; CLEAR THE NAME FIELD IN THE PROGRAM LINE
87 ;
005542: 3F0E 88 NAME MOVE.W A6,-(A7) ;PTR TO NAME FLD
005544: 7E20 89 MOVEQ #$20,D7 ;SPACE
005546: 7009 90 MOVEQ #9,D0 ;9 CHARS
005548: 1CC7 91 NAME1 MOVE.B D7,(A6)+ ;ONE SPACE
00554A: 5300 92 SUBQ.B #1,D0 ;DECR COUNT
00554C: 66FA 93 BNE NAME1 ;LOOP 9 TIMES
94 ;
95 ; CHECK FOR A NAME FIELD; LENGTH 1 - 8 CHARS
96 ;
00554E: 4EB858DA 97 JSR CHKFLDC ;GET PARM FIELD
005552: 0C050009 98 CMPI.B #9,D5 ;NAME > 8 CHARS ?
005556: 6506 99 BCS NAME2 ;OK IF > 9
100 ;
005558: 7E20 101 MOVEQ #32,D7 ;NAME TOO LONG
00555A: 4EF85A16 102 JMP ERROR ;REPORT ERROR
103 ;
104 ; STORE THE NAME IN THE "BSAVE" NAME FIELD
105 ;
00555E: 305F 106 NAME2 MOVE.W (A7)+,A0 ;PTR TO NAME FLD
005560: 1E1E 107 NAME3 MOVE.B (A6)+,D7 ;FETCH A CHAR
005562: 0207007F 108 ANDI.B #$7F,D7 ;MASK UPPER BIT
005566: 10C7 109 MOVE.B D7,(A0)+ ;STORE A CHAR
005568: 5305 110 SUBQ.B #1,D5 ;MORE CHARS?
00556A: 66F4 111 BNE NAME3 ;LOOP TIL DONE
112 ;
00556C: 4E75 113 RTS ;NAME SET UP
114 ;
175 ;-------------------
176 ;-- COMMAND: SAVE --
177 ;-------------------
178 ;
0055D8: 48E7FFFE 179 SAVE MOVEM.L D0-D7/A0-A6,-(A7) ;SAVE REGS
0055DC: 3C7C5654 180 MOVE.W #SNAME,A6 ;PTR TO NAME FLD
0055E0: 4EB85542 181 JSR NAME ;SET UP PROG NAME
182 ;
183 ; SAVE THE PROGRAM FROM THE 68000 TO THE HOST
184 ;
0055E4: 367C3588 185 MOVE.W #CMD8,A3 ;PTR TO CMD8
0055E8: 4EB8550E 186 JSR SGTBLS ;PROG TO HOST
187 ;
0055EC: 4EB8556E 188 JSR GETLINK ;GET HOST LINE LINK
189 ;
190 ; STORE THE BYTE COUNT IN THE BASIC PROG LINE
191 ;
0055F0: 3C38151A 192 MOVE.W COUNT,D6 ;BYTE COUNT
0055F4: 307C566C 193 MOVE.W #SLEN+4,A0 ;DEST
0055F8: 6126 194 BSR DOHEX4 ;CONV & STORE
195 ;
196 ; CALCULATE AND STORE THE LINE LINKS FOR THE
197 ; TWO LINES TO BE APPENDED TO THE BASIC PROG.
198 ;
0055FA: 3A7C5673 199 MOVE.W #SLINK+1,A5 ;2ND LINE LINK
0055FE: 7239 200 MOVEQ #$39,D1 ;LINK OFFSET
005600: 6112 201 BSR CSLINK ;CALC & STORE
005602: 3A7C5645 202 MOVE.W #BSAVE+1,A5 ;1ST LINE LINK
005606: 722E 203 MOVEQ #$2E,D1 ;LINK OFFSET
005608: 610A 204 BSR CSLINK ;CALC & STORE
205 ;
206 ; SAVE THE PROGRAM FROM THE HOST TO THE DISK
207 ;
00560A: 4EB85592 208 JSR LSPROG ;SAVE THE PROGRAM
209 ;
00560E: 4CDF7FFF 210 MOVEM.L (A7)+,D0-D7/A0-A6 ;RESTORE REGS
005612: 4E75 211 RTS ;SAVE DONE
212 ;
100 HOME : TEXT :P = 38383:Q = 0 - 102
110 PRINT CHR$ (4);"BLOADAPPLE.O,A$8600,D1"
120 PRINT CHR$ (4);"BLOADHALGOL.O,A$2000"
130 CALL 38359
140 CALL Q: REM 07 002000 2000 4000
500 CALL Q: REM 02 005210
63997 CALL 34304
116 ; FIND THE END OF THE HOST PROGRAM BY TRACING
117 ; THE BASIC LINE LINKS 'TIL $0000 IS FOUND.
118 ;
00556E: 31FC0801110 119 GETLINK MOVE.W #$0801,LINK ;1ST LINK ADR
120 ;
005574: 30381100 121 GETLINK1 MOVE.W LINK,D0 ;D0 = LAST LINK
005578: 3A7C1101 122 MOVE.W #LINK+1,A5 ;68000 ADR
00557C: 7802 123 MOVEQ #2,D4 ;TWO BYTES
00557E: 610C 124 BSR CMD7B ;GET NEXT LINK
005580: 11E51100 125 MOVE.B -(A5),LINK ;HIGH ORDER ADR
005584: 66EE 126 BNE GETLINK1 ;LOOP TIL ZERO
127 ;
128 ; END OF HOST PROG FOUND; SAVE THE NEXT 64
129 ; BYTES TEMPORARILY IN THE 68000'S "DBUFF".
130 ;
005586: 3A7C1104 131 MOVE.W #DBUFF,A5 ;68000 ADR
132 ;
133 ; GET 64 BYTES FROM THE HOST; HOST ADR IN D0
134 ;
00558A: 7840 135 CMD7A MOVEQ #64,D4 ;64 BYTES
00558C: 3C00 136 CMD7B MOVE.W D0,D6 ;D6 = HOST ADR
00558E: 4EF83584 137 JMP CMD7 ;EXIT VIA CMD7
138 ;
139 ; APPEND TWO NEW PROGRAM LINES TO THE END OF
140 ; THE HOST BASIC PROGRAM (BLOAD/SAVE, CALL).
141 ;
005592: 6108 142 LSPROG BSR CMD8A ;STORE 2 LINES
143 ;
144 ; EXIT TO BASIC SO THAT HOST CAN LOAD/SAVE PROG
145 ;
005594: 4EB8356C 146 JSR CMD1 ;EXIT TO BASIC
147 ;
148 ; RESTORE THE HOST CODE WHEN SAVE IS DONE
149 ;
005598: 3A7C1104 150 MOVE.W #DBUFF,A5 ;68000 ADR
151 ; RESTORE THE HOST CODE & LOAD/SAVE DONE
152 ;
153 ; SEND 64 BYTES TO THE HOST; HOST ADR IN D0
154 ;
00559C: 3C00 155 CMD8A MOVE.W D0,D6 ;D6 = HOST ADR
00559E: 7840 156 MOVEQ #64,D4 ;64 BYTES
0055A0: 4EF83588 157 JMP CMD8 ;EXIT VIA CMD8
158 ;
0055A4: 0000FEF9 159 BLOAD DC.L $0000FEF9 ;LINK, LINE#
0055A8: BAE72834 160 DC.L $BAE72834 ;?CHR$(4
0055AC: 293B2242 161 DC.L $293B2242 ;);"B
0055B0: 4C4F4144 162 DC.L $4C4F4144 ;LOAD
0055B4: 20202020 163 LNAME DC.L $20202020 ;9 CHAR NAME
0055B8: 20202020 164 DC.L $20202020
0055BC: 202C4124 165 DC.L $202C4124 ; ,A$
0055C0: 36303030 166 DC.L $36303030 ;HEX ADDRESS
0055C4: 2C204431 167 DC.L $2C204431 ;, D1"
0055C8: 2200 168 DC.W $2200 ;QUOTE, END
0055CA: 0000FFF9 169 LLINK DC.L $0000FFF9 ;LINK, LINE #
0055CE: AB363339 170 DC.L $AB363339 ;GOTO 639
0055D2: 3937 171 DC.W $3937 ;97
0055D4: 00000000 172 DC.L $00000000 ;END PROG MARK
173 ;
214 ; SUBROUTINE; CALC & STORE 1 BASIC PROG LINK
215 ;
005614: D240 216 CSLINK ADD.W D0,D1 ;ADD LAST LINK
005616: 3E01 217 MOVE.W D1,D7
005618: E04F 218 LSR.W #8,D7 ;HIGH ORDER
00561A: 1A87 219 MOVE.B D7,(A5) ;STORE HI ORD
00561C: 1B01 220 MOVE.B D1,-(A5) ;STORE LO ORD
00561E: 4E75 221 RTS ;DONE
222 ;
223 ; CONVERT AND STORE A WORD (4 HEX CHARS)
224 ;
005620: 6106 225 DOHEX4 BSR DOHEX
005622: 6104 226 BSR DOHEX
005624: 6102 227 BSR DOHEX
005626: 4E71 228 NOP ;4 CHARS DONE
229 ;
230 ; CONVERT AND STORE A HEX DIGIT
231 ;
005628: 3E06 232 DOHEX MOVE.W D6,D7 ;NIBBLE TO D7
00562A: 6106 233 BSR HEXIT ;CONVERT TO HEX
00562C: 1107 234 MOVE.B D7,-(A0) ;STORE IT
00562E: E84E 235 LSR.W #4,D6 ;NEXT NIBBLE RDY
005630: 4E75 236 RTS ;DONE
237 ;
238 ; CONVERT A NIBBLE IN D7 TO HEXADECIMAL
239 ;
005632: 0207000F 240 HEXIT ANDI.B #$0F,D7 ;MASK D4-D7
005636: 06070030 241 ADDI.B #$30,D7
00563A: 0C07003A 242 CMPI.B #$3A,D7 ;NUMERIC?
00563E: 6502 243 BCS HEXITX ;SKIP IF SO
244 ;
005640: 5E07 245 ADDQ.B #7,D7 ;A - F
005642: 4E75 246 HEXITX RTS ;CONVERSION DONE
247 ;
005644: 0000FEF9 248 BSAVE DC.L $0000FEF9 ;LINK, LINE#
005648: BAE72834 249 DC.L $BAE72834 ;?CHR$(4
00564C: 293B2242 250 DC.L $293B2242 ;);"B
005650: 53415645 251 DC.L $53415645 ;SAVE
005654: 20202020 252 SNAME DC.L $20202020 ;9 CHAR NAME
005658: 20202020 253 DC.L $20202020
00565C: 202C4124 254 DC.L $202C4124 ; ,A$
005660: 36303030 255 DC.L $36303030 ;HEX ADDRESS
005664: 2C204C24 256 DC.L $2C204C24 ;, L$
005668: 30303030 257 SLEN DC.L $30303030 ;HEX LENGTH
00566C: 2C204431 258 DC.L $2C204431 ;, D1"
005670: 2200 259 DC.W $2200 ;QUOTE, END
005672: 0000FFF9 260 SLINK DC.L $0000FFF9 ;LINK, LINE #
005676: AB363339 261 DC.L $AB363339 ;GOTO 639
00567A: 3937 262 DC.W $3937 ;97
00567C: 00000000 263 DC.L $00000000 ;END PROG MARK
264 ;
00001100 265 LINK EQU $1100
00001104 266 DBUFF EQU $1104
267 ;