Issue # 28 DTACK GROUNDED Newsletter - February 1984

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

THE TRASH-68 ARRIVES:

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.

OOPS! DEPT:

"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

Page 1, Column 2

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.

p-CODE FORTRAN:

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.)

TRAMEIL RESIGNS:

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?)

BORING STUFF:

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).

Page 2, Column 1

UNIX STUFF:

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.)

IBM PC WATCH:

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.

Page 2, Column 2

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."

Page 3, Column 1

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.

DATING INFOWORLD:

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 ROSEN WATCH:

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

Page 3, Column 2

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?

WANNA GET RICH?

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.

Page 4, Column 1

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?"

IBM FINANCIAL WATCH:

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

Page 4, Column 2

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

Page 5, Column 1

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.

MILLIONS OF PROGRAMS:

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?)

Page 5, Column 2

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.

Page 6, Column 1

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.

SHORT STUFF:

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 & A TIME:

Q: Does the Grande have the "zero page" fix like the static board has?

Page 6, Column 2

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

Page 7, Column 1

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.

MORE PRICING STUFF:

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

Page 7, Column 2

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!

THEM LONG LEAD TIMES:

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.)

Page 8, Column 1

IW QUESTIONS UNIX:

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.

Page 8, Column 2

WELCOME ABOARD DEPT:

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.

YOU WILL PAY ATTENTION:

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.

HALGOL REPORT:

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

Page 9, Column 1

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.

Page 9, Column 2

SELECTING THE OUTPUT:

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.

THE ACTIVE DEVICE:

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

Page 10, Column 1

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.

MINI-MICRO WATCH:

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

Page 10, Column 2

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?)

COMMODORE WATCH:

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.

Page 11, Column 1

HEALTH ALERT:

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.

APPLE III STUFF:

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?

STRINGS AND THINGS:

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.

Page 11, Column 2

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:

1. A particular string may be umpteen-dozen bytes long on rare occasion. But I don't want to take up memory by DIMing the string umpteen-dozen bytes ALL the time! REPLY: If that string ever gets that long you will need that memory allocation THEN. If your computer has that much memory then, why not NOW?
2. A particular string array may have a thousand entries only four bytes long and one entry umpteen dozen bytes long. REPLY: You have designed a particularly stupid data system. There are techniques to program around such exceptions, even in BASIC. But is that a REAL problem or just a knee-jerk reaction? You LIKE fatal bugs that bomb your program and eat your data?
3. My mail-list program is DIMed for 40-byte strings and I have a 55-byte entry to make. REPLY: We have news for you. Your mailing labels are only 40 characters wide. We are much too tactful to tell you what to do with those other 15 bytes.

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!)

BYTE WATCH:

Page 12, Column 1

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

Page 12, Column 2

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?

THAT BUSTED TRICYCLE:

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?

TRUE FACTS DEPT:

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.

FALSEHOODS DEPT:

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

Page 13, Column 1

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.

NOSTRADAMUS DEPT:

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

Page 13, Column 2

'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?

COMPOUNDING THE FELONY:

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!

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

Page 14, Column 1

capacity to boot? And not be able to run MS-DOS, unlike the 2000?

THE TRASH-68s:

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.)

DO IT OUR WAY:

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

Page 14, Column 2

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!

TRASH <> TRASH:

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.

THE 68000 CONSPIRACY:

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

Page 15, Column 1

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?)

IT'S A 16-BIT CONSPIRACY!

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

Page 15, Column 2

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!

COMPLEX SOFTWARE DEPT:

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

Page 16, Column 1

else who uses the 68000. you gotta keep up with the Joneses, you know.

EXAMPLES:

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.)

HANDLING LABELS:

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

Page 16, Column 2

sufficiently friendly strategy. See if you agree.

LABELS DONE CORRECTLY:

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.

Page 17, Column 1

YE DE-SEX (ugh!) REPORT:

"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

Page 17, Column 2

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

ADDING A HALGOL FUNCTION:

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.

Page 18, Column 1

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:

1. Insert a function into a program.
2. Delete a function from a program.
3. Replace one function with another.

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.

WHAT'S IN A NAME?

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:

Page 18, Column 2

       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").

HALGOL COMPILATION:

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

Page 19, Column 1

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

Page 19, Column 2

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!

GLITCH CITY:

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.

Page 20, Column 1

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:

The 68000/16081 Interface

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

Page 20, Column 2

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.

(YES, WE GET MAIL!)

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

Page 21, Column 1

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.

Page 21, Column 2

"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.

Page 22, Column 1

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

HALFTIME :

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

Page 22, Column 2

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.

AUUGGHH!

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

Page 23, Column 1

Commodore's most recent quarter? (Scully's gonna turn green when he sees that profit figure!)

LOOKING BACKWARDS:

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.

MORE MACKINTOSH:

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?

YOU WILL SEND US MONEY II:

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 TO COPY:

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

Page 23, Column 2

ABOUT REDLANDS:

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.

Page 24

                           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 ;

Page 25

                          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 ;

Page 26

                         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

Page 27

                         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 ;

Page 28

                         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 ;