Issue # 36 DTACK GROUNDED Newsletter - October 1984

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

WATCH THIS, SNOOPY!

"It was a dark and stormy night, with miles to go before I sleep. So I leaped upon my gallant steed and galloped off in all directions!"

It seems that newsletter editors (and other technical writers) are adopting lurid writing styles such as the above these days. That sort of stuff originated with headline writers for the National Denouncer and then leaked into the editorial pages of CAR and PAYMENT magazine. If you are running into that "miles to go before I sleep" line too often, it does not mean that technical writers are either cultured or even that they have taken up reading poetry. In the old Charles Bronson movie Telefon, which frequently appears on late-night TV, "miles to go before I sleep" is part of the poem which repeatedly triggers violent reaction in Russian moles. Very few critics have ever described Charles Bronson movies as significant contributors to culture.

About galloping off in all directions: a 19th century novelist actually used that phrase, proving that there is more than one way to create immortal prose. Now, if we can help Snoopy get past that first line of his Gothic...

We favor another approach. Say, for instance, we have this poor-but-honest crippled teen-age newsletter editor. When invoking the magical acronym "TANSTAAFL!" a stroke of lightning turns him into a 60 foot tall white ape with a 4 gigabyte linear address space. The white ape embarks on an heroic quest of mythic dimensions. On this journey he fights the dark powers of the Computer Science Theocracy; supports the cause of 'one person, at least one CPU'; defeats foul, degrading segmented memories; makes even the most modern and highest performance microprocessors available for use in single-tasking personal computers; reveals the despicable practice of busting high level languages by writing them in yet another high level language; defends the forces of virtue... well, that

Page 1, Column 2

Terry Peterson's Commodore - DTACK connection revealed, p.19. Ulrich Schmidt's Inter68 v1.2 now supports the Nat Semi math chip - p.17. Peter Siebert's 68000 native code generator for Inter68 v1.2 - p.12. Open letter to MICRO's Bob Tripp - p.3. HALGOL arrays - p.22. UNIX stumbles - p.9. Mail call - p.17. Lotsa toro poo-poo all over - watch your step at all times!

last might be going too far. The opening line of this epic will, of course, be "Call me Felgercarb."

However, our natural modesty forbids us to write in the manner suggested above, or even in the more lurid style which has become popular elsewhere. We will continue in our restrained, formal prose style. The fact that the Fay Wrays of this world do not seem to favor 60 foot tall apes has not influenced our decision.

PROGRESS! WONDERFUL?

By now you have probably noticed that the photograph on the front cover of the last issue was almost totally unrecognizable. Since we are personally responsible for the photographs around here, both that last one and the ones in preceding issues, let us tell you what happened. Progress is what happened.

We take those photographs using an Olympus OM-1 camera, 100mm lens, Vivitar manual electronic flash and Celestron tripod. The tripod is new and the other stuff has been around for over 10 years. The manual flash puts out a constant amount of illumination, so we take each 'pose' of the boards we 'shoot' using four to six different f-stops. We know from experience that a circuit board against a white-sheet background photographs best using about 1 to 1 1/2 f-stops lighter (more open) than "normal", as defined by the output of the flash and our distance from the board.

These are black-and-white negatives for prints, of course. Very few folk use black-and-white these days, so you have to find someplace that even handles the stuff. For us that was Main Photo, about a mile from us in Santa Ana. We would get back, in one or two days, up to 36 ea 3 X 5 glossy prints, six to eight "poses" with each "pose" taken with those several different f-stops. We'd select the best "pose", then the optimum darkness for that "pose" for publication.

Oh, yes: progress. Knowing in their infinite wisdom that camera buffs do not know what they are doing, Main Photo has just installed a new automated black-and-white photo print machine. The automated print machine adjusts the light balance FOR EACH PRINT the way IT thinks things should be. So no matter what f-stop we

Page 2, Column 1

use, the prints all come out the same: too dark! So we had no alternative for the last issue. Now we will have to learn how to circumvent progress.

CASCADE GRAPHICS:

We sent a color print of a Cascade Graphics ad with the last newsletter. Guess who makes the half-megabyte 12.5MHz 68000 board (one wait state) and the graphics boards (a 3-bit-plane VDHR system) for the Cascade Graphics system illustrated? If you guessed Analytical Engines or Stellation II, go stand in the corner.

The 19 inch RGB color monitor has 1024 X 796 resolution with 60Hz non-interlaced refresh. Since alternate screens are used, 3/4 megabyte of DRAM is used just for the graphics boards for a total of 1 1/4 megabytes per system. Naturally, it is the fully-developed and extremely sophisticated software which makes that system go. Like nearly 400,000 lines of (ugh!) PASCAL. Well, they DO draw the screen using 68000 assembly code in conjunction with a 7220 graphics controller chip...

BRIGHTNESS II:

Since we have already discussed the brightness problems we have had with our photography, let us discuss an aspect of color graphics which might not have occurred to you. Imagine a hypothetical monitor with a "resolution" of one pixel horizontally and one vertically. In other words, the whole screen is one giant pixel which is either on or off. That pixel, when on, will be VERY bright! On the other hand, that Cascade Graphics color monitor has a resolution of about 1000 X 1000. So if one pixel is on, it represents one one-millionth of the potential output of that screen. That is NOT very bright.

For simplification, we will assert that the Apple HIRES screen has a resolution of 250 X 250, that our new POTBOILER has a resolution of 500 X 500 and that the Cascade Graphics 10C has a resolution of 1000 X 1000. If we call one-millionth "one ppm" (parts per million), then each individual Apple HIRES pixel has a brightness of 16 ppm, each POTBOILER pixel a brightness of 4 ppm and the Cascade 10C a brightness of 1ppm. As a natural consequence, beginners look at a simple line drawn on the 10C and say, "Gee! It's not very bright, is it?"

As we proceed from low to medium to high resolution, progressively finer detail can be shown but individual lines become less and less bright. To equal the brightness of an Apple HIRES line, four 10C lines must be drawn side-by-side. To equal the brightness of a POTBOILER line, two 10C lines must be drawn side-by-side. So?

So a beginner in this area will look at the POTBOILER's

Page 2, Column 2

640 X 400 graphics and then stand up and cheer! It turns out that resolution in the 640 X 400 range is psychologically optimum in that good detail can be seen but individual lines are still fairly bright (intense). Naturally, the higher resolution monitors are in fact better, as you would appreciate if you have a complex drawing to display. Two lines can be 'drawn' side-by-side when brightness is really needed. But you will pay an awful lot of money for that improved resolution, which means that 640 X 400 resolution is not only psychologically optimum, it is also VERY cost-effective.

HACKERS vs. OEMs:

We started DTACK to make 68000 boards for hackers. Two of the first ten Apple-DTACK boards that we sold back in Dec '81 went to a company named Cascade Graphics, which happens to be located two blocks from us. They had developed a CADD PASCAL software package over a period of 3 years which ran on a $300,000 Cal Comp computer. Then they adapted the package to the Apple II (and the Corvus hard disk) using Apple's version of UCSD PASCAL. The package worked fine except that it was excruciatingly slow. Guess what they bought those two DTACK boards for? Right!

Seven or eight months later they completed the software adaptation and started buying lots and lots of boards from us. These were two-board 68000 systems, 220K static RAM at 12.5MHz with no wait states. (We don't think Cascade would like for us to reveal their exact sales figures, so please understand if we are vague about exact numbers.) Our sales were proceeding well with our intended 'hacker' market as well, although lots of those 'hackers' had found commercial applications for a very fast microprocessor board.

After six months, Cascade came to us and began to discuss the possibility of us building a high resolution graphics controller board for them. Ordinarily we give an immediate "NO!" answer to requests for custom products but they had already bought several hundred thousand dollar's worth of our boards before these discussions opened. (Most folk who want custom products have never spent a dime with us.) It took another four months of discussion before the specifications of the VDHR board set were frozen in March '83. We had working prototype VDHRs in August, although there were MANY cuts and jumpers. In fact, the board artwork had to be redone TWICE before we had the current production boards. VDHR pilot production began in DEC '83 and regular production began a month later.

While all of this was going on, we were designing the Grande, our DRAM version of the DTACK board. We had prototypes in June '83 but did not turn them on and

Page 3, Column 1

test them at that time because we were concentrating on the VDHR system, which proved to be even more of an engineering challenge than we had anticipated. (Pushing pixels at 14.7 nsec per pixel using TTL technology on two-sided circuit boards is certainly an educational experience.) The Grande, like the original GROUNDED board, was intended for our 'hacker' customers. You will recall that we had some reservations about how reliable a DRAM board would prove. Well, it proved highly reliable and has essentially replaced the GROUNDED board. So who has bought the most Grandes? Cascade Graphics, naturally!

The VDHR system has WAAAY too much horsepower for your individual hacker, so we decided to make a hacker 7220-based graphics board. Color, naturally; hackers LOVE color. (The reason we know what hackers like is that some are employed by Digital Acoustics.) But detuned down to something a hacker - an affluent hacker - can work with. VOILA! Our POTBOILER, which proved very easy to design and manufacture after our experience with the VDHR system.

Is Cascade going to develop the POTBOILER into a cost-effective CADD system? You bet your sweet patootie! They haven't announced anything yet, but they DID buy three of the prototype boards (we built FIVE prototypes on the assumption, a good one as it turned out, that they would work).

So what is our OEM box score? We have built only one custom design for an OEM, the VDHR. However, the boards which were designed exclusively with hackers in mind have also proved to be interesting to OEMs. Incidentally, Cascade is just our biggest OEM. For instance, three universities have surprisingly large numbers of GROUNDEDs and Grandes and (in two cases) 16081 math boards.

FINAL ADD, POTBOILER:

Those of you who have investigated the 7220 graphics controller chip will have discovered that it is a bear and a half to program. By comparison, 68000 assembly language is a piece of cake. This means that the POTBOILER will be absolutely useless to most hackers without some high level language support.

So we are incorporating such support into HALGOL right now. By the time you are reading this, both FP and integer arrays will be working and such arrays make nice repositories of plot lists. (REPOSITORIES OF PLOT LISTS? Time to knock off and watch the Raiders play Kansas City.)

[LATER: The Raiders carved out a routine, ho-hum 22-21 victory over the Chiefs, winning on a field goal in the final seconds.]

Page 3, Column 2

AN OPEN LETTER TO MICRO PUBLISHER BOB TRIPP:

Bob, I have already applauded your belated decision to support the hacker's microprocessor of the 1980's, the 68000 family. Regrettably, several of MICRO magazine's staffers - and this may include you, Bob - have not personally come to terms with the 68000 and with the substantial performance margin it has with respect to the 6502 and the 6809.

I am sure that you remember, as I do, the excitement engendered by the introduction of the Mos Technology 6502 in the mid-1970s at the price of $25 (quantity either 1 or 100). That forced Intel and Motorola to get rid of their $300 price tags on their 8080 and 6800, respectively. As I recall, a couple of kids in Silicon Valley and a Mos Tech employee in Pennsylvania designed personal computers around that $25 marvel which became somewhat popular. Please remember that popular personal computers were eventually built around the 8080 and (to a lesser degree) the 6800, once THEIR prices dropped into the $25 range.

We skip forward to the early 1980s and find the 8-bit 6809 being introduced in the $25 range (100 ea) and the 68000 being introduced in the $300 range. I vividly recall attempting to persuade you to support the 68000 with MICRO magazine back in the summer of 1981, shortly after I conclusively proved that it was possible to build exceptionally simple 68000 systems - a fact which Motorola had successfully obscured from the general public. However, you chose to FOCUS on the 6809. Heck, it's a free country and besides, FOCUSING on the 6809 was probably a good idea in the short term.

Motorola had originally decided to deliberately keep the 68000 out of the personal computer marketplace. To implement this policy, they adopted a number of stratagems, such as refusing to provide any technical assistance to anyone who refused to purchase their $30,000 EXORturkey or who announced plans (as I did) to offer a 68000-based product for the personal computer market. All of their application notes were directed exclusively to the construction of enormously complex systems. But in retrospect, the most important thing Motorola did was to hire lots of minicomputer folk to market the 68000. You know as well as I do, Bob, how much contempt minicomputer folk have for crummy personal computers.

In the summer of 1982 Motorola management finally noticed that IBM/Intel was KILLING them in the personal computer market and that the personal computer market had expanded into a billion-dollar industry. So the Motorola honchos reversed their policy and made a belated attempt to push the 68000 into the personal computer marketplace via the 68008 and the RMS color

Page 4, Column 1

graphics chip set. But Motorola had (and HAS) a major problem: its marketing force was still (and IS still) a bunch of minicomputer types who still had (and still HAVE) contempt for crummy personal computers.

In addition to that, lots of folks (including you, Bob?) listened to and believed Motorola's earlier assertion that the 68000 was intended exclusively for minicomputers and FORTRAN, LISP, and UNIX. Learning this, most personal computer types mentally shelved the 68000 and STILL believe that hogwash.

Times have changed. The last Motorola price list I looked, at several months ago, had plastic-cased 8MHz 68000s priced at $32 (100 ea). If we take inflation into account, Bob, THAT IS ACTUALLY CHEAPER THAN THAT (mid-70s) $25 6502!

Not only is it cheaper, Bob, but is is a LOT easier to program than the 6502! Yes, we know the 6809 is also easier to program than the 6502. It SHOULD be, the 6809 instruction set is a VERY LIMITED SUBSET of the 68000 instruction set! Anyone who gets their hands dirty on a 68000-based keyboard will quickly learn that the 68000 is MUCH easier to program than ANY 8-bit chip, including the 6809. (I suppose it would not be tactful to mention again that three-page article that MICRO ran on 32-bit addition using the 6809 and the 6502? Or the fact that a 32-bit add is a single instruction in the 68000?)

And if $32 in 1984 dollars is too rich for your blood, the 68008 has the same instruction set and the same internal resources (like 16 ea 32-bit registers) that the 68000 features. And the price for an 8MHz plastic-cased 68008 was only $18 (100 ea) in that same list.

Even if 6809s were free, Bob, a 68008 will pay for itself in just two to four hour's programming effort because you can get a lot more programming done in that time than with the 6809. In fact, at these prices it is perfectly reasonable to use a 68008 to turn a water sprinkler on and off.

Having laid the groundwork, Bob, I now come to the point of this letter: MICRO magazine has done more harm than good to the 68000 cause in recent issues!

No sooner had you announced that MICRO was henceforth supporting the 68000 than you published an article on the 68000 in which the author concluded that the 68000 had such excellent performance that it must be reserved for industrial use and that individual hackers at home would have to limit themselves to the 6809! THAT IS TORO POO-POO! (Bob, do you have any FOCUS computers left that you need to sell?)

That was bad enough, Bob, but the latest issue of MICRO

Page 4, Column 2

is guilty of 50-megaton overkill. In the Sept issue, on p.11, you have a 'spotlight' on Stellation's $229 68008 under-the-hood Apple board. I am very pleased that item was not signed since I can express my opinion unhindered by any humanitarian impulse:

That item is the biggest bunch of stupid, misguided and uninformed bullshit that I have seen in any technical publication in memory! The author actually knocks a $229 product because it does not come with FORTRAN, LISP, and UNIX! Now, that $229 product plugs into (nominally) a 48K Apple II+ with one or two 140K floppy disks! FORTRAN and LISP? UNIX?

Bob, will you grab that author and patiently explain to him or her that YOU CANNOT RUN UNIX on a 48K Apple II+, even with TWO floppy disks? And that 68000-based FORTRAN generally goes for $3000 and LISP for $6000 so it is somewhat unrealistic to expect Stellation to provide those two languages with a $229 board? Incidentally, when was the last time you ran LISP using 48K of RAM and one or two 140K floppy disks?

On page 9 of the Sept issue you point out to your readers that it is advertising that supports magazines, including MICRO. I had been planning a series of four or five educational ads, at least a full page each, to run in MICRO. (Digital Acoustics can easily afford such, and it NEEDS a 68000-related personal computer publication to advertise in.) That plan is now shelved. I will never knowingly advertise in any publication which relegates the 68000 to an industrial ghetto or ridicules 68000-based Apple accessory board manufacturers for not providing FORTRAN, LISP, and UNIX with their product. (Does Apple's Mackintosh come with FORTRAN, LISP, and UNIX? Did you notice the MTU ad on page 3 of the Sept issue which offers a $5075 68000 computer but which ALSO doesn't come with FORTRAN, LISP, or UNIX? What do you think THEY, as MICRO advertisers, think of page 11?)

Perhaps MICRO INTENDS, intellectually, to support the 68000. But it appears that the MICRO editorial staff is emotionally locked into the early 1980s, when a 68000-based product just HAD to be a $30,000 vehicle for which you could license FORTRAN for $6,000 or LISP for $10,000 or UNIX for $15,000. Far from supporting the 68000, MICRO is in fact actively HARMING the 68000 cause!

Bob, can you recommend a personal-computer magazine which TRULY supports the 68000 as a 1980s' 6502? MICRO ain't it!

FNE

Felgercarb N. Eloi

Page 5, Column 1

JOHN GANTZ WATCH:

How does John do it? If WE write about anything related to "THE STORY OF 'O'" we would get clobbered - did you see that 'cancel my subscription' letter in the last issue? As it happens, we didn't read 'O' in our misspent youth but we did read a lot of books from the same shelf. Like Donleavy's The Ginger Man and both of Henry Miller's Tropics and even My Secret Life by Anonymous - and that last one gives a better picture of mid-1800's England than you might suspect, considering the subject matter. (If we ever find that book in print again, we are going to add it to our personal library.)

But our real reason for bringing up Gantz' 17 Sep column in InfoWorld is what he has to say about virtual memory: "'Virtual storage' kills. If you know what the term means and what trouble IBM had getting it to work on its mainframes, you will agree. If you don't know, it's too complicated to explain here. At any rate, it was (is?) critical to the Ovation product, and I would bet dollars to doughnuts that virtual storage was behind development lags." Gee, it's nice to see somebody else agree with our assessment of virtual storage on personal computers for a change. You DO remember that we said you would be better off to embrace a hooded cobra than personal virtual memory, don't you? A long while ago?

AD ASTRA?

Have any of you seen that wimpy advertisement which proclaims "In 2001, we reached the stars!" Gosh, when we saw the movie HAL was getting his memory banks pulled near the orbit of Jupiter. That's still the inner part of the solar system, folks! Maybe the yo-yos who pasted up that ad think Proxima Centauri is about a hundred feet past Jupiter?

We hope those ad-makers aren't the technical consultants on the upcoming film "2010".

1-2-3 vs SYMPHONY:

If you have been paying any attention to the three-piece-suit market, you know that SYMPHONY has not been especially well received. A lot of folk had put off making a decision between 1-2-3 and SYMPHONY until the latter was released. Well, SYMPHONY has been released now and guess what? There has been a MASSIVE surge in sales for 1-2-3. How do we know? Well, (IBM) Softalk reported 1-2-3 leading PC software sales as usual, but the index shot from 272 in July to - get this - 447 in August! Yes, four hundred and forty-seven!

Gee, WHAT A SURPRISE that SYMPHONY is not being as well received as well as 1-2-3! AHEM! Following is a

Page 5, Column 2

reprint of the last paragraph on page 5 of our issue #24, a whole year ago!

"Is it true that the original spreadsheet program by this company was written by six guys, first in C then translated to assembly for performance? Is it true that they have used the VERY substantial income to hire lots more troops, mostly from the mainframe world? Is it true that one of the more highly-placed new-hires recently asserted that this second-generation spreadsheet needed a wordprocessing module and a communications module? Did he also very clearly assert that they need not be GOOD modules since the public would buy ANYTHING with his company's name on it? Is this what is called V*S*C*RPing?"

(You don't suppose that the paragraph which preceded the above way back in issue #24 just might be related to Mackintosh, which hadn't been released at the time?)

CONFIRMING BACK-UPS:

Two issues back, we warned the reader that a prudent fixed-disk Winchester user not only backed up his data but also checked whether the back-up was a good one. We cited a particular (anonymous but genuine) example of how a company could get bit on the ankles by no-good backups. Naturally, a reader phoned and said, "Hey! You don't know what you are talking about!" (We have such tactful readers!)

He proceeded: "Streaming tapes have been around for a long time and they are HIGHLY reliable. Our company has used mechanisms made by Archive, Cipher and Wangtek. These tape drives use a read-after-write head, and use deliberately degraded analog performance (reduced gain) to check the recorded data. That way, even after the tape ages or the read head has some wear, the playback is guaranteed good. (Well, as good as anything is guaranteed.) And our formatters that we use with these drives also record block numbers, so a second verification can be done by block as well as by file. I have used these things myself for a couple of years and I can go and get any of my old back-up tapes and reload them anytime. No errors!"

We discussed pricing, and it develops that this reader was discussing a tape backup system with a bill of materials of about $1200-$1300 in fairly substantial quantity. Parts required: tape drive, power supply, formatter, formatter-to-host interface, its share of a case. That makes for an end-customer price of $4K to $6K. Such systems are nearly always sold as a non-detachable part of bigger, more expensive systems so you never see the itemized price tag.

We do agree that highly reliable tape backups of this kind have been available for some years now.

Page 6, Column 1

BUT - we were talking about the new cheapies coming on the market aimed at the PC/XT and that ilk. We are looking at end-user prices that go all the way down to under $1000. These are new systems which do not have proven performance! We implied, two issues back, that not all was well with some of these systems. Can we come up with any hard evidence to back up that innuendo? NATURELLEMENT!

For starters, we grab 18 Sep PC magazine, which was obviously published AFTER our initial writeup two issues back. That issue of PC just happens to focus on big disks and includes an article which reviews tape backups in general and five versions (four manufacturers) in specific. [IF YOU ARE PLANNING TO USE PERSONAL COMPUTERS WITH BIG DISKS, YOU REALLY SHOULD BUY THIS ISSUE OF PC.]

A few quotes: "...it took two tape cartridges and 10 minutes to complete the backup and another 15 minutes to verify the operation [that's FAST - FNE]. The verify stopped on the first cartridge with the error message 'Verify error on block 12129: bad tape.' I tried the backup again, this time swapping the two cartridges. Again I got the error message, but this time it took a total of only 12 minutes to tell me that block 69 was bad. The errors had occurred on the 450-foot, 10,000-bits per inch cartridges that Davong had supplied... In summary, the Davong software is crude and the hardware problems I had are unacceptable."

On to another brand, this time Tallgrass: "...it surprised me that the full backup took 40 minutes. During the backup operation, two undocumented errors appeared: 'TMS - free directory entry missing' and 'Buffer crossover of DMA page boundary.' In addition, the backup stopped dead at one point... [The Tallgrass drive] is slow, it's missing key features such as the ability to create subdirectories, it has many bugs, and it requires a lot of effort for full hard disk backups."

Pay attention, now, because the next step is a doozie:

"I did run into a problem when I used [with the SYSGEN Image] FSAVE. I found that large chunks of storage on the hard disk, as much as 7 megabytes at a time, would disappear. [What's 7 megabytes of data between friends? - FNE] The people at SYSGEN told me that some IBM PCs and XTs have bad DMA chips. This defect can cause problems when using the Image. [We are going to call 7 megabytes that ain't there anymore a PROBLEM? GADZOOKS! What candor! They were able to tell me how to identify a bad chip, and when I found out that I did indeed have a bad DMA chip, they sent me another version of the software that would work with it."

Page 6, Column 2

People, PLEASE PLEASE read that last paragraph CAREFULLY. SYSGEN KNOWS that some DMA chips are bad, they ALREADY HAVE alternate software which works correctly if the chip is bad - AND THEY WILL SEND THE ALTERNATE SOFTWARE TO YOU AFTER, REPEAT AFTER YOU HAVE LOST UP TO 7 MEGABYTES OF DATA! I yi yi!

The reviewer's conclusion? "The SYSGEN Image is an ideal choice for backing up the XT." Apparently the 7 megabytes of data lost belonged to someone else, hmmm?

The other brand tested, the Alloy PC-BACKUP, was the most expensive at $2,195. It worked correctly, but the reviewer noted: "The documentation for the Alloy tape drive is only fair. Instructions for CP/M and MS-DOS are intermixed, information is difficult to find, and there are numerous misspellings... I was disappointed with its speed."

Friends, these are not the things we want to read about tape backups we are considering buying.

NAT SEMI WATCH:

A couple of issues back we wrote about Nat Semi's inexplicably strange game plan for going from 6MHz directly to 10MHz without touching base at 8MHz. We speculated that there might be an unannounced mask change in the works. Had we known the true extent of the massive personnel turnover which had occurred last Feb, we might not have been so surprised at the incredibly strange goings-on. Here is an update:

8MHz! WHAT, 8MHz? YES!

Your friendly local authorized Nat Semi distributor can now sell you a 6MHz or 8MHz 16032, or 32016 as it is now called. Let us repeat that: an 8MHz 32016 is now available for sale. 8MHz. Not 10MHz, no 10MHz 32016s are available. So much for Nat Semi's previously announced purity in avoiding 8MHz parts.

As we pointed out last issue, 10MHz 16081s, now called 32081s but still stamped 16081 on the case, are now available. Your friendly local authorized Nat Semi distributor will happily sell you one for $300. An unannounced mask change WAS made early this year - that's why our old software that worked with last year's mask would not work with this year's. It is also why they are getting somewhat reasonable yield of 10MHz parts at reasonable operating temperatures now.

Our comments were not far from the facts which have subsequently unfolded, yes?

Page 7, Column 1

BYTE WATCH:

If you have the Sept BYTE, see the ad for the Sage IV disk backup on page 478. Unlike the streaming tape drives we wrote about a couple of pages back, this backup is FAST! How fast? Why, it backs up 10Mb in NO TIME! That is one helluva accomplishment! True, we have been trying to implement HALGOL so that language will run in no time at all, but we have considered that merely a desirable objective rather than something which can in fact be accomplished. Backs up 10Mb in NO TIME? My, my!

Terry Peterson is getting a lot of ink these days. In our rag, Aug Dr Dobbs, Sept BYTE... uh, Terry, didn't Jim Strasma give you some ink recently in Midnite as well?

Check out the ads for Eagle IIs on pages 507 and 519. As we told you before, Eagle Computer sold off all of its Z-80 line to a liquidator. These are the first ads we have seen since the liquidation. We paid $2500 each for our two Eagle IIs; that was back around Feb '83 and they have been worth every cent as dedicated word-processors. The word-processor which comes with the Eagle II, Spellbinder, is as easy to learn and use as any we can imagine. Of course, it helps that the keyboard has the Spellbinder commands engraved on the sides of the keys.

We used WordPro IV+ on our Commodore 8032/8050 system to produce this newsletter before we bought the Eagles, and that system (and word processor) is, by comparison, pathetic! Within two months after getting the Eagles, we had actually FORGOTTEN the convoluted command set used by WordPro IV+ (no marked keys, you know)! The last time we loaded up that word processor, we had even forgotten how to get a listing of the files on disk - kinda important considering it will only handle one of our compressed newsletter pages at a time!

We're going to buy another Eagle II or two - for use as spare parts if nothing else. The other nearby company which uses Eagles (after seeing ours, they bought 3 right away!) has already bought two more since Eagle closed out that line. Incidentally, that other company, like us, manufactures microcomputer stuff but they, like us, have NEVER looked 'under the hood' of an Eagle. The Eagle is in no way a 'hacker' machine - you just use it, and it works. If you like 64K Z-80 machines. For word processing, we LIKE!

A SHORT DIGRESSION: Spellbinder does not include a spelling checker. If you need a spelling checker and are using a Z-80 CP/M machine run, do not walk, to your nearest software outlet and buy Oasis' THE WORD+, or whatever they are calling the latest version. THE WORD is just like our Eagle/Spellbinder combo: it works!

Page 7, Column 2

And it works VERY well! We would recommend, we DO recommend, that program to any Z-80 CP/M user.

A recent issue of PC WEEK carried a survey of spelling programs. The author asserted that there were some programs which were superior to THE WORD but which were being overlooked because of "100,000 fanatical THE WORD users". You can count us amongst that 100,000. The reason we bring this up is that one of those competitors, V.SPELL, is advertised on p.421 of Sept BYTE.

Notice in the box comparing three spelling checkers that V.SPELL features "Dictionary hypenation"! Now, one of the things we do NOT want from a spelling checker is 'hypenation' of any kind. In fact, we don't even need HYPHENATION...

BUT NOBODY CAME!

They have just held the second annual National Computer Software Show in Anaheim. The organizers expected 15,000 to 20,000 visitors to be attending seminars and viewing products on opening day.

1,000 showed up.

The shakeout in the software industry continues, well in advance of the already noticeable magazine and personal computer-maker shakeouts. Remember, the total dollar volume of software sales is actually INCREASING. But all that money is being funneled into fewer and fewer products. Didn't somebody point that out before? (Numbers from L.A. Times Business Section 6 Sep.)

BUT WE WUZ SICK!

The week before the Olympics we caught a bug that knocked us on our back for a day or two. We combatted it with the usual chicken soup and ministrations of our flu doctor, the famed Dr. Calvert Fitzgerald. Then came the Olympics, which we watched in the evenings and on weekends. So there were three weeks during which very little got done towards writing newsletter #35, which explains why it was "late".

We got a few phone calls asking about the newsletter: "Where is it?" and even Jeff H., the editor of the other 68000-based newsletter, got a couple of inquiries. It's nice to be missed.

What is NOT nice is what that damn flu bug did. It kept coming back! Not bad enough to make us REALLY sick, but enough so we couldn't get any work done about half the time. This started right after the Olympics and we didn't really know what was going on - we figured the odd hours we kept during the Olympics might have just made us lazy. We have since discovered that

Page 8, Column 1

our sneaky flu bug was pretty common; lots of folk have had similar problems all over the country.

The point we want to make is that newsletter #35 was co-authored by your FNE and a flu bug. If portions seem less than inspired, we will credit those portions to the flu bug! O.K.?

DE FACTO STANDARD:

All of you will have learned, with the help of MICRO magazine and SAGE dealer Paul Lamar, that the SofTech p-System is becoming (has become?) the de facto 68000 operating system standard. Meanwhile, SofTech has announced that it will post an operating loss in the third calendar quarter despite profitability for its main business, which is providing contract software for Uncle Sam. Where, then, is the loss occurring? Why, in the subsidiary which produces the de facto standard p-System! And why is the p-System subsidiary going to lose money in the third calendar quarter? Why, because their sales are too low! Hmmm...

SofTech is applying the usual 'fix' in an attempt to forestall yet more losses in the fourth fiscal quarter: more layoffs. Remember, they had this problem last year, too.

Gee, if the p-System is a defacto standard in a growing industry, how come the only source of that defacto standard is posting continuing financial losses and having continuing layoffs? We dunno - but we suspect that that 'de facto standard' AIN'T! Hell, the white flags have been flying from SofTech's battlements - the ones still standing - for some time now. If you have written a software package which runs on the p-System, you lucky dog you, you can now (with some effort, true) re-host it to run under MS-DOS. Question: why not write it to run under MS-DOS in the first place?

We don't have much first-hand experience on the p-System. But we ARE a businessman, and we can make a pretty accurate prediction about what happens to a money-losing subsidiary which is steadily dragging down an otherwise profitable corporation. Just exactly how many software houses are beginning a mass-market software development to run under the p-System today? If the answer to that question is "zero", just what does "de facto standard" mean in this case? Huh?

Here are the numbers: in the quarter ended Aug 31, SofTech posted a loss of $347,000 on sales of $7.99M. In the same quarter last year, SofTech EARNED $515,000 on sales of $9.53M. Those figures are for the entire SofTech operation; the p-System subsidiary figures are not broken out separately except for SofTech's informal announcement that that subsidiary is dragging down an otherwise profitable operation.

Page 8, Column 2

STANDARD BUSES:

A couple of issues back (#34, p.4 col 1), we explained briefly why we do not design our products around a standard bus. We expected to get a lot of flak over that, so naturally none of you mentioned it. Well, it is nice to know that an authority - the former chairman (Andrew Allison) of the IEEE-896 Futurebus Committee agrees with us. See 20 Sep Electronic Design, p.82.

Allison makes several points: that high performance and processor independence are mutually exclusive; that standard buses are best suited to applications which have special I/O requirements or to applications where I/O configurations will be subject to frequent change; and that there are a lot of reasons why a single-board or sealed-box computer is more practical than a bus-structured system. He points out that "the most highly touted abilities of the new backplane interfaces and bus structures, for instance, are to make possible multi-processing and to build computers with multiple (bus) masters. Those goals, though, raise more questions than they answer..."

Our approach is to use a synchronous expansion bus optimized for the 68000 and single-user, (mostly) single-tasking. This gives the very best performance available for our type system, at a very low cost. Contrary to what some of you think, there is not ANYTHING proprietary about our expansion bus structure. That expansion connector is completely 'open'.

[It is interesting to note that the expansion bus used in the old SAGE computers, which were intended for single users, was pretty much like ours. SAGE's move to a standard bus (VME) in their new computers coincides with their move to multiuser (up to 22 users!) systems.]

THAT MEGABYTE ROM:

A couple of issues back we observed 'The Death of Software', observing that we only really need one spreadsheet, one word processor, one data base manager etc. We also asserted that a megabyte of ROM could be provided for just $200 in large production quantities.

General Instrument's Microelectronics group has just dropped the list price of its 250 nsec 256Kbit (32Kbyte) RO9256 mask ROM to $6.25, quantity 10,000 (24 Sep EN). Since it takes 32 of these ROMs to make a megabyte, the cost is 32 times $6.25 or, uh, carry the five... two hundred dollars! How's that for a good guess? Actually, at a production level of 40,000 units per month that would be 40,000 times 32 ROMs or 1,280,000 ROMs per month. We would think there would be a substantial discount relative to the 10,000 price.

Page 9, Column 1

The point is, it is now entirely possible and even practical to dump a megabyte of ROM into a desktop computer. Whether that would be a good idea (as in profitable), we dunno. But the H.P. portable and even the Commodore unit, which are both ROM-intensive, will be testing the water. With ROM prices continuing to drop, we suggest that you would not want to reject the 'BIG ROM' concept out of hand.

THE HALGOL HARANGUE:

The title above is one of the few that Jeff H. of the HALGOL Review hasn't copyrighted already, so we're stuck with it even though it lacks a certain panache. (My country right or wrong, my mother drunk or sober, my Harangue mellifluous or not...)

A REVIEW: HALGOL is intended to be a problem-solving language for individuals to use. It is not intended for systems programming and it is not intended for use by programming teams of 150 persons. You may recognize that BASIC is a well-known problem-solving language for individual use.

BASIC comes in two flavors and each of these flavors comes with a problem. Interpreted BASIC is exceptionally friendly but slow. Compiled BASIC has all of the problems that naturally come with compiled languages including unfriendliness but is often used anyhow to get more speed. HALGOL is an attempt on our part to create a language which has all the friendliness of an interactive environment but the speed of a compiler. Recognizing that there is no such thing as a free lunch, this previously-unknown but desirable combination of attributes has to be paid for somehow.

The most obvious coin of payment is a large run-time package. In other words, while a VERY decent BASIC interpreter (exclusive of graphics) can be packed into 8K bytes, HALGOL will be about four times larger. This explains why the concepts behind HALGOL have not been seen in programming languages up until now - that extra memory was a killer. But the incremental cost of that extra 24K bytes is now less than $24! With 128K Macks being considered inadequate and 512K considered standard, it is hard to get excited over 24K of extra code. (With graphics and an operating system, HALGOL will probably weigh in at 40 to 48K. With an equivalent of the FORTRAN LINPACK matrix algebra pack it can get bigger than that. Remember, H.P.'s 68000 BASIC has a 236K byte run-time package!)

However, extra memory is not the only cost of having a language which combines interactive and compiled features. Most of you who have worked with BASIC compilers know that a few restrictions pop up which are not applicable to the purely interactive form of the

Page 9, Column 2

language. True, the extent of these restrictions reflect the skill of the programmer(s) of the compiler and also the time and effort (expense) poured into the compiler. Put another way, at what point does the programmer say, "I quit! This is it!"?

Most of you will remember the flood of mutually contradictory directives we received for a while with respect to implementing HALGOL. Some of you readers were overzealous with your "suggestions" and we were guilty of taking you - and ourself - too seriously. Looking back, we now recognize that some of you readers were baffled at our unwillingness to accept your obviously meritorious suggestions, while we could not understand how you readers could possibly expect us to program in 25 differing directions simultaneously.

We now think we have figured out what happened. Neither we or you readers had any previous guidelines to follow. While there are MANY newsletter writers/editors, and while language designers (as opposed to the 3,453rd implementor of a 'standard' BASIC) are not really uncommon, we cannot think of a previous case of a person designing a computer language while concurrently publishing a newsletter! This combination is not likely to happen again soon, so the lessons we learned in the 'school of hard knocks' will likely be wasted.

Anyhow, there are other restrictions imposed by our desire to combine interactivity with compilation. Some restrictions are inherent and some are due to limited time/money (or laziness, if you prefer). And some things which might seem like restrictions to the casual observer are in fact deliberate, reasoned choices on the part of the designer - such as the absence of mixed-mode arithmetic.

We would have been in a much better mood a few months back had we kept in mind that those persons who demanded that we attain both our primary objectives and ALSO match the sophistication attained by professional software companies with hundreds of programmers and $100 million per annum in sales were in fact paying us a VERY sincere compliment. We ain't nowhere near that good - but please accept our belated thanks for the thought. ["We" = your FNE and our full-time HALGOL programmer, who is a UCI computer science graduate.]

And now let us tell you a little bit about HALGOL integers and arrays and yes, their limitations... if you will just turn to page 21.

UNIX! (AGAIN)

Way back in early 1982 there was a furious debate about which operating system was going to win out in the 16-bit personal computing arena. Soon the UNIX adherents

Page 10, Column 1

were shouting louder than most other folk. They started making some pronouncements which seemed to us at the time to be remarkably fatuous, so we placed a two-page writeup (pp2-3) in the June '82 issue of this rag. That writeup was intended to clarify a few items for our readers, and we figured that would end it.

Wrong!

It seems that the UNIX arena is public-relations-driven, which means that fantasy pretends to be reality and crass facts are ignored. A limited few UNIX gurus whipped themselves into a frenzy of absurdly overstated expectations during the summer of 1982, and the well-oiled UNIX public relations departments saw to it that those expectations got lots of ink. Dozens and dozens of minicomputer types started huddling with venture capitalists to grab a piece of the huge UNIX market which, obviously, was poised for explosive growth! These expectations climaxed in the fall of 1982 when UNIX guru Jean Yates, frothing with excitement, jumped up on the nearest table (metaphorically speaking) and shouted to the world that 600,000 UNIX systems would be sold in 1983!

An amazing number of otherwise rational persons swallowed that prediction hook, line, and sinker. Mini-Micro Systems magazine pointed out that Microsoft would gross $2 BILLION in 1983 in XENIX licenses. It was soon reported that there were ninety, count em, 90, 68000-based UNIX startups in Silicon Valley alone. Far from laying the question of UNIX to rest in the June '82 issue, we felt it necessary to counterbalance in these pages the effluvium of toro poo-poo from other publications. This meant that everyone was out of step except Johnny, uh, Felgercarb. And it meant that Felgercarb took an awful lot of flak from (some) DTACK readers over his view of UNIX.

As we have pointed out before, this (personal computer) industry is highly susceptible to the 'Chicken Little' effect. The henhouse emptied out and all the chickens ran off behind Jean Yates squawking, "UNIX is coming! UNIX is coming!" Your FNE received a number of letters pointing out that we would join the rush if only we knew more about UNIX (we STILL get such letters).

It slowly became evident in 1984 that UNIX had sold somewhat fewer than 600,000 systems in 1983, and the charge of the chickens ran out of steam. But nobody, especially those opinion-leaders whose pronouncements are amplified by the UNIX public relation offices, likes to admit they goofed. Jean Yates muttered that if 600,000 UNIX systems had not been sold then ALMOST 600,000 had been sold - and even invented a lot of non-extant UNIX vendors to bolster that claim. Others looked for new champions - IBM or A T & T (Fortune having fallen on its derriere).

Page 10, Column 2

We still giggle when we remember the publisher/editor who called us right after IBM announced PC/IX and triumphantly proclaimed that IBM had lined up behind UNIX and that, contrary to what we had been telling our readers, UNIX would now inevitably emerge victorious! We replied in print by questioning whether sales of PC/IX at $900/copy would pay for the paper clips in IBM's Seattle office. And then there was System V and then there was A T & T's entry into the hardware arena and... Different UNIX gurus desperately grasped onto one or the other of these announcements (UNIX is VERY big on announcements) as evidence of UNIX's inevitable triumph.

A funny thing became evident: the UNIX marketplace WAS expanding - but at about the same rate as the rest of the small computer marketplace. If but a tenth of the nonsense pumped out by the collective UNIX public relations departments were true, UNIX would today be the only operating system used on any computer within the ken of mankind! (Personkind?)

TRUTH REARS ITS UGLY HEAD:

As Lincoln pointed out, you cannot fool all of the people all of the time. It has finally become embarrassingly evident that most of the pap emanating from the UNIX public relations departments is pure natural fertilizer. We are seeing the beginnings of another Chicken Little charge, this time in the reverse direction.

UNIX persons (opinion-leaders) are finally noticing, in print, that there is no such thing as a UNIX standard! UNIX/WORLD Executive Editor Philip J. Gill points out (issue #3, p.7) that there are MANY UNIXs and that no two are compatible! Unique editor David Fiedler adds that, as a result, each UNIX installation needs a UNIX guru on hand before it can get an application package up and running. David also notices that the A T & T hardware has poor performance and notes with disgust that "genuine A T & T UNIX" is not even complete (but rather what we call emasculated). (Unique dated Aug but arrived 20 Sep.) Sep UNIX REVlEW's publisher's column (p.4) discusses the difficulties of administering small UNIX installations of 2 to 4 users and insists that UNIX has lousy documentation. 3000 page manuals, but lousy documentation. Sep MINI-MICRO SYSTEMS' publisher's column (p.11) flatly asserts that UNIX's time has passed. Aug Datamation magazine blasts UNIX. Even PC World's David Bunnell, bless him, has noticed the mismatch between AT&T/UNIX and the mass marketplace (Oct. p.13).

(Let us quote from the last paragraph of MINI-MICRO's editorial: "UNIX brought the importance of operating-system software into prominence. It has served its purpose. Let's now benefit from the experience and

Page 11, Column 1

move on to the newer, more capable and fully integrated operating-system solutions...")

No, UNIX is not likely to lie down and die, at least not in the foreseeable future. But neither is UNIX going to expand (proportionally) much beyond the niche it now has.

As we pointed out way back in June '82, there is no such thing as "the best operating system". The concept of "best" is relative, in this case relative not only to the computer and the application but also to the user. It was absurd to assert that UNIX was or ever would be the best operating system for the dentists and candle-makers who comprise the mass personal computer marketplace. Finally, Felgercarb is no longer out of step, the UNIX gurus having changed step to match (without noticing him, to be sure - this is a tiny, obscure newsletter in an 'out' backwater, remember?).

If we were nicer than we are, we would not point out that we told you so.

A T & T PERFORMANCE:

Some comparative benchmarks have been run on some of A T & T's new UNIX machines. The first pitted the 3B2/300 against six other machines in the $12K to $20K class, and featured computations and RAM read/writes. The A T & T machine came in next to last, beating out the 8086-based Altos. The 68010-based Convergent Technologies' Miniframe finished first. The A T & T machine came in in the middle in terminal support tests, and finished first in the disk performance test. (You don't suppose that A T & T has learned through all the years that UNIX really DOES need a FAST hard disk, NOT just a hard disk?) The 8086-based Altos finished last in all three benchmarks. (Oct 1 EN, p.21)

SYSTEM V & the 80286:

All of you probably know that SYSTEM V is the dialect of UNIX which is, no lie, gonna be the standard and conquer the world. That's because A T & T, the world's greatest and most experienced marketers, are behind it. (What do you mean, we have overspent our allotment of sarcasm?) Well, Motorola has had an A T & T-approved SYSTEM V release for some time now but the 80286-based release (called 'port' in the UNIX world) is seriously behind schedule - and may have some other problems unrelated to the schedule. We thought you might like to know how this state of affairs came about:

The first thing you should know is that the SYSTEM V ports for the various microprocessors are being performed FOR A T & T, who will own the ports (code) when they are done, as they now own the 68000 port. Therefore, A T & T is also setting/has set the rules

Page 11, Column 2

under which the ports are to be performed. Remember, A T & T wants ports which are COMPLETELY compatible with its own code.

The second thing you should know is that Intel, makers of the 80286, had already adopted Microsoft's XENIX, a UNIX clone, as its official internal operating system. So when Intel agreed to cooperate with A T & T in obtaining an 80286 SYSTEM V port, they naturally went to Microsoft. Microsoft read the contractual ground rules established by A T & T, which required that EACH LINE OF CODE changed had to be justified in writing and heavily documented. Like we said, A T & T wants ports which are COMPLETELY compatible with its own code.

Microsoft therefore learned quickly that it could not 'leverage' off the very substantial work it had done on XENIX, its UNIX clone. SO IT TURNED THE JOB DOWN!

Imagine the feeling Intel must have had to suddenly realize that their own internal standard operating system, XENIX, was going to be unrelated to the absolute, definite, for-sure future operating system standard, SYSTEM V! So, with heavy heart, Intel managed to persuade Digital Research (DRI) to take on the 80286-SYSTEM V port. (Some publications wrote at the time that DRI 'won' the port over Microsoft. That is not in accordance with the facts.)

Well, DRI is late delivering the 80286-SYSTEM V port and both A T & T and Intel are afraid that DRI is not going to promote its SYSTEM V port even after (if?) it delivers. You do not suppose that DRI has detected which way the UNIX wind is blowing, do you? (The above information was abstracted from David Fiedler's UNIX newsletter Unique and from Oct 1 EN p.21.)

A CONVERGENCE OF INTERESTS:

"...A T & T recently signed a major long-term OEM agreement with Convergent Technologies... to develop, design and manufacture products on an exclusive basis for A T & T Information Systems... Insiders say the arrangement could put more than $1.5 billion in Convergent's pocket over the next five years" (Apr '84 MINI-MICRO SYSTEMS, p.68).

At the blockbuster press conference announcing A T & T's entry into the UNIX computer mart, the very first speaker was A T & T's Vice Chairman James E. Olson. "He also noted that A T & T plans to make component level parts (i.e. WE32000 chips and 256K RAMS) available to the industry as soon as possible (Mar '84 Unique, p.2).

Rub those two paragraphs above together and you will understand why we, and just about every other industry observer, leaped to the conclusion that Convergent was

Page 12, Column 1

going to design and build desktop computers for A T & T using the WE32000 and the A T & T 256K DRAMs, both of which have been in production for some time.

SURPRISE!

ENTER STAGE LEFT: A crusty dragon with triple strength halitosis, breathing fire! 'We are not ABOUT to let anybody what we don't own a piece of (read: Olivetti) get ahold of them WE32000s or 256K DRAMS! You will be SURE' - here the dragon swung his head out over the first three rows of the audience, examining the darkened corners carefully - 'to get that straight!' With this, the dragon scrabbled around and left in the direction he arrived as the audience sat stunned. 'Who WAS that dragon?' folks whispered fearfully. Why, that was kindly Jack Scanlon, a mere vice president of A T & T's Computer Systems Division! (This was reported in almost every industry publication, the only known exception being the Northeastern Oklahoma Poultry-Raiser's Gazette. Jack Scanlon was getting a LOT of ink at that time.)

If you think comparing Jack Scanlon to a fire-breathing dragon is somewhat exaggerated, we suggest you hire into a $40 billion company and publicly contradict the vice-chairman of that company! Without even being polite about it!

You may wonder why James Olson does not grab a large, industrial strength fly-swatter and apply it in the obvious manner to one Jack Scanlon. We point out, because a federal court will not let him do that! You see, as a part of the court-ordered and court-managed breakup of Ma Bell, A T & T is legally required to keep its Information Systems division separate from its Computer Systems division. The former division is the one in charge of direct retail computer sales and is also the division which awarded Convergent the secret contract. The Computer Systems division is in charge of computer sales to OEMs, VARs (Value Added Retailers) and, oh yes: is in charge of WE32000 and 256K RAM production.

And the reason nobody in higher management can reach out and touch two someones in those two divisions and order them to (literally) get their act together is that would be a violation of the federal court order maintaining two independent divisions. Result: the one division runs around signing contracts which the other division won't honor. Madness!

What do Convergent and the Information Systems division do now with their huge, multi-year secret contract? Probably provide a good living for two-score lawyers for the next half decade, we would guess.

Page 12, Column 2

NATIVE CODE PASCAL:

I would like to announce the availability of NAT68, a 68000 Native Code Generator that transforms P-Code into 68000 machine code. During this transformation the Pcode is heavily optimized and redundant or dead code is removed. Also, optimization is performed on all stack operations, removing most of the push and pull instructions.

The resulting codefile is about twice as large and between 2 and 10 times faster than the original. The speed increase depends heavily on the type of operations involved in the program. Obviously, real and set operations cannot be speeded up very much nor can procedure calls, but almost any other operation becomes much faster. For example: BYTE's Sieve benchmark takes 43.8 sec when using P-Code and only 5.7 sec when using native code. That's a factor of 7.7! (The SIEVE takes 57 sec on the SAGE according to BYTE Sep '84 p. 352.)

To use the Native Code Generator, you must have the Inter68 v1.2 P-Code interpreter, which can be purchased separately from Ulrich Schmidt (older versions will not work!).

The Native Code Generator comes on one disk with a four page manual.

An optional P-Code and MC68000 Code Disassembler, called DIS68, is also available. It disassembles P-Code files (both negative and positive byte sex) as well as code files with 68000 assembler routines and INLINE code (generated by either the Native Code Generator or by my modified Pascal compiler).

This disassembler comes on one disk with a two page manual.

Prices (including postage):

    NAT68           $45 
    DIS68           $45 
    NAT68 & DIS68   $65

Persons who have purchased NAT68 alone can later purchase DIS68 for $30. Please send a check (in U.S. funds) to:

Peter Siebert
Einsteinstr. 186
4040 Neuss 1
West Germany

Page 13, Column 1

DVORAK WATCH:

You can't trust that damn DVORAK. After months and months of irrelevant frivolity, such as telling folks what kind of cheese to serve at parties, John comes up with some useful observations, such as the fact that the computer science theocracy is taking over the computer language side of the American National Standards Institute (ANSI). It seems that the theocrats aren't satisfied with PASCAL; they want FORTRAN to be PASCAL too - and damme if they do not seem to be trying to accomplish that!

John, that's the sort of thing which we would logically publish in THIS rag. Why don't you go back to your pure gossip and leave the serious stuff to us? (If we were not afraid of giving you a swollen head, we would point out that a mention in your column is worth twice times as many new subscribers to DTACK as a mention in Jerry Pournelle's BYTE mail column - 15 to 20 vs 7 to 10. Of course, you have not compared the DTACK GROUNDED newsletter to leprosy.)

No, we are not toadying up to John because of the newsletter contest he announced in the same InfoWorld column as the above scoop. John has already published our mailing address and subscription fee at least twice, and besides, we don't want to get too close to a columnist who lives in the Frisco area and who consults with a guy named "Swish"!

VEGETABLE OIL:

Once upon a time (about twenty years ago, actually) there was this person who had friends in high places. One of the high places was the oval office of the White House in Washington, D.C. Because the identity of those friends in high places was well known, he had no difficulty borrowing many millions of dollars from the banking establishment. Especially since those loans of many millions of dollars were fully collateralized by substantial amounts of vegetable oil, said vegetable oil being stored in underground tanks.

If you want to borrow money against your house, the bank will send somebody out to evaluate the worth of your house. This person is in fact an auditor, regardless of his or her actual title. Similarly, the banks sent an auditor around to check the contents of those underground storage tanks filled with vegetable oil. The way this is done is sort of like checking the oil in your car - drop a stick (in this case a LOOONNG stick) in the tank and see how much of the stick is messy with oil when the stick is pulled out.

The problem is, the sort of highly professional auditors who would be entrusted with checking up on many millions of dollars' worth of vegetable oil wear very nice suits, while underground oil storage tanks

Page 13, Column 2

are very, very messy. So the auditors would look at the scant above-ground evidence of those tanks and write in their report, "Yep! There's lots of oil there in those underground tanks, all right!"

And then one day the banks sent out a young auditor who did not really understand the correct way to perform an audit. When he was shown the scant above-ground evidence of those tanks, he ignored the messy surroundings and said, "Hand me that stick!"

Guess what?

MORE AUDITOR STUFF:

Corporations have financial records, familiarly called 'books', which detail the assets and debits of the company. Assets can include money in the bank and cash on hand, accounts receivable, capital equipment and inventory. In the past we have written about the value of completed goods inventory; specifically, how public companies should value large warehouses filled with completed goods if those goods are not in fact selling. The goods we wrote about 2 1/2 years ago were lots of Apple IIIs and more recently we wrote about lots of PCjrs sitting in warehouses somewhere (perhaps several somewheres).

However, no one - certainly not us - ever suggested that the number of completed Apple IIIs listed on the books did not correspond closely with the actual number of Apple IIIs sitting on shelves in warehouses. Fact is, in the better corporate circles the inventory carried on the books corresponds closely with the physical inventory sitting on the shelves. When the physical inventory fails to correspond with the book inventory by a significant amount, people tend to get upset.

Suppose, for instance, a company has $7 million more inventory sitting on the shelves than is recorded in the books. If the federal, state, and local tax authorities find out about the discrepancy they are likely to become unhappy. Mostly because the federal and state folks would figure that company was trying to do them out of about $3.5 million in taxes on unreported income, but even the local folk would like to collect property taxes on that inventory. The feds are so uptight about unreported inventory that they will provide free room and board at a federal facility while the reportee reflects upon his or her mistakes.

It is also a bad idea to report $7 million more on the books than is in fact sitting on the shelves. In this case the tax guys will not be unhappy; if you want to overpay your income taxes, that's all right with them. In fact, considering that one must pay $3.5 million in taxes that are not really owed in order to report $7

Page 14, Column 1

million in nonexisting inventory, you might think folks would not do that. YOU WOULD BE WRONG! Publicly traded companies are worth what Wall Street says their stock is worth. And Wall Street pays especially close attention to a company's profits. Paying out an extra $3.5 million in unowed taxes can result in an upward evaluation of the worth of the company more than ten times that amount. Much more.

This latter problem is so obvious that the Securities and Exchange Commission has stringent rules about it. This is just one of the reasons the SEC requires independent audits of publicly traded corporations on an annual basis.

[The alove was written a couple of weeks ago and the KAYPRO report below was written a week ago. Yesterday InfoWorld finally got around to KAYPRO, and in this morning's (Oct 3) L.A. Times business section there is a report of the consent decree which Tandem signed with the S.E.C. in which they promise not to book orders which do not exist to boost apparent profits: "In some cases, the SEC charged, Tandem would indicate that a sale was complete or nearly complete - so that the revenues could be recorded - when, in fact, the deal was pending. The SEC said the company commonly prepared misleading invoices that made it appear that equipment was being sent to customers when it was actually being sent to a warehouse for storage.")

THE KAYPRO SHORTFALL:

[The following story was carried in InfoWorld dated 15 Oct but arrived 2 Oct, in the WSJ on 13 Sep, in EN on 10 Sep but we believe that we read the story late the week before 10 Sep in the L.A. Times business section. This story has not yet concluded.]

The independent auditors examining KAYPRO's books recently discovered a discrepancy between the value of the inventory listed on the books and the physical inventory sitting on the shelves. Although the exact amount of the discrepancy has not yet been determined, estimates up to $7 million have been published in the financial press. The discrepancy is downward; that is, there appears to be less physical inventory sitting on the shelves than is listed on the books.

By a remarkable coincidence, KAYPRO just happens to have gone public at a time when the discrepancy apparently existed but had not yet been discovered and reported. Therefore, the actual company profits were - it seems to us - considerably lower than was indicated by the prospectus. Stock was issued at $10 and is now, after the discrepancy and corresponding overstated profits has been revealed, trading around $2. At least one stockholder lawsuit over this matter has already been filed.

Page 14, Column 2

As you might imagine, there is considerable speculation going on as to how this discrepancy occurred. It is well known that much of KAYPRO's inventory was housed until recently in a circus tent. Circus tents have notoriously poor security. One speculation is that, as the KAYPRO folk moved, say, $10 million in inventory via the front door (front flap?) of the tent, socially unadjusted miscreants were moving $7 million out the back of the tent. That is one possibility.

Another possibility is that certain KAYPRO folk moved $3 million in inventory into the front of the tent and wrote down in the books that they moved in $10 million. Like we just said, that is the other possibility.

Of one thing we can be certain: if $10 million in inventory gets entered in the books, then $10 million in inventory was PAID for. And so, if the $7 million (estimated) KAYPRO inventory discrepancy is not due to simple theft (an outside job, that is), we have the fascinating specter of $3 million in inventory being received and $10 million in bills being paid out! If - we are just supposing, mind you - IF this latter proves to be the case, then there are undoubtedly some fascinating relationships to be discovered between one or more KAYPRO persons (in, say, purchasing and/or accounts payable) and one or more KAYPRO suppliers.

We bet you thought auditing was dull.

While we await the revelation of the real facts behind KAYPRO's estimated $7 million inventory discrepancy, we'd like to borrow a little money. Say, $17 million. For security we'll put up this here vegetable oil we have stored in these here incredibly messy underground storage tanks...

[Do all of our readers understand enough about double entry bookkeeping to know why there HAVE to be checks which paid for that estimated $7 million in missing inventory, even if that inventory proves to have never physically existed?]

RULE BRITTANIA I:

It is proving an exhausting task to keep up with the numerous advances in microcomputer technology emanating from the British Isles. Earlier this year Wireless World headlined "Advanced Microcomputer!" on its front cover. When we looked inside we discovered the advanced microcomputer used a Z-80 CPU! We have the Sep issue of WW at hand, opened to the ad on page 55. It seems the British have come up with a new invention of unparalleled originality. They have taken a fairly ordinary home-type 6502 microcomputer and turned that microcomputer into a host for an advanced attached processor with a huge memory space! ZOUNDS!

Page 15, Column 1

The attached processor uses a 6502 and comes with 64K of non-expandable RAM.

Oh, yes: the host processor is Acorn, which may be better known as the 'BBC machine' since the British Broadcasting Company officially endorses it. This is the machine which was, no lie, going to have a Nat Semi 16032 attached processor Real Soon Now (apologies to J.P.). That was over two years back and no 16032 attached processor has ever been sighted.

RULE BRITTANIA II:

While BYTE magazine is lambasting Sir Clive for failing to produce the Sinclair QL machine in large numbers, Sir Clive's engineers are trying to one-up Gene Amdahl and his Trilogy Corp. They are trying to produce a single-wafer half-megabyte shift-register memory. Using a 1972 patent by Ivor Catt which outlined how to automatically search for and include good shift register loops while automatically switching out bad loops, it seems that this scheme has a genuine chance to succeed. The concept is very similar to magnetic bubble memory except that most of the complex electronic overhead is eliminated and cheap, plentiful silicon replaces the garnet required for bubble memories. Like magnetic bubble memory, the chip would have both major and minor loops so that access time is not limited to the recirculation time for the entire half-megabyte.

If successful, this single wafer will be used as the heart of an 'electronic disk' which will be plugged into the left-hand side of the QL. Before any of our readers knock a mere half-megabyte, remember that's about three and a half 140K DISK II floppies. Unfortunately, this program is more than a year away from commercial reality at best.

How many of you remember the sizable excerpt of a WW article by Ivor Catt which we printed in these pages a long while back?

RULE BRITTANIA III:

The Sinclair QL is struggling along in Britain, with most of the struggles based on getting the software to fit inside the unit without losing too much functionality. The first release of the QL had a 'dongle' (like a U.S. game cartridge) sticking out the back and a multitasking operating system. The second release still had a 'dongle' but no multitasking and the third release finally fitted inside the case by deleting some functions from the BASIC, but it still lacked multitasking. The developers of the original multitasking operating system are now SELLING that system independently of Sinclair!

Page 15, Column 2

Meanwhile, everybody has been cussing out the tiny Sinclair tape cartridges as being unsuitable for business records (this is really startling information of the same class as THE SUN RISES IN THE EAST!) but an alternative strongly resembling the old Exatron "Stringy Floppy" is surfacing.

The point is, the British INSIST that the QL be judged exclusively for its suitability as a business machine, which is exactly what torpedoed the original PCjr in this country. In fact, the QL is an absolutely marvelous device for shooting rocks using 16ea 32-bit registers and at only $500 is extraordinarily well suited to the U.S. home computer marketplace. We know we have said this before, but Sir Clive could make a TON of money - make that several tons - by selling the QL in its present form in the U.S. Those tiny tape cartridges, which really are NOT suitable for keeping business records, are MARVELOUS for storing rock- shooting high scores!

Meanwhile, Apple's Mackintosh has totally bombed in the British market. The British evaluate the Mack as a productivity tool and of course, productivity is not what Mack is about. Mack in the U.S. is sold as an adult toy, period.

The enormous difference between the British and the U.S. market lies in the far greater discretionary income the Americans have.

RULE BRITTANIA IV:

During that extraordinarily dragged-out negotiation between Victor and Britain's ACT it turns out that Victor management might not have been the only outfit dragging its feet. The following missive arrived from a highly placed DTACK mole:

"It ain't ACT that got the ulcer. They got a fat grin on their face, and why not?

"It suited the Pommies just fine to have Victor carry on making Sirii in the hopes of being bought whilst ACT established Apricots (which just happen to be Victor compatible...) so securely that Sirius will soon be unsaleable in the U.K. In any case ACT is Victor's largest customer and thus virtually unsackable, or as you would say, unfireable, like most shuttle launches.

"Having strung Victor along until Apricot production was ramped up (it's currently about 4,000 units a month and rising) ACT pulled out of the Victor purchase negotiations, citing Victor's inability to reach a decision - which, if [IF? Surely you jest! your thesis about its suiting Victor's management to continue in Chapter 11 is correct, could have continued indefinitely.

Page 16, Column 1

"It is only now that one or two suspicious minded British stock market analysts have begun to wonder whether ACT were ever serious. After all they may have a short term need for Sirius product, but with all the lovely British government grants to setting up factories in depressed areas, why would they have wanted to buy a plant in California?

"Accustomed as your readers are to pursuing red herrings, they might find it enjoyable to speculate why the aforementioned areas are so depressed. Personally I think its the warm beer that's to blame.

"Greetings to all your fellow Colonials from us here in the mother country."

Remember the W. German outfit that "successfully" bid for Victor and then could not come up with $30 million in long green? Well, that was Beta Systems A.G., which is a software house which is a subsidiary of Kerkerbachbahn A.G., a real-estate company. Guess what? The K.A.G. headquarters have been raided by the police, records alleged to relate to fraud have been confiscated, and two upper-management officials were arrested.

Gee, you don't suppose that police raid and the two arrests is in any way related to the fact that Beta Systems A.G. couldn't come up with $30 million in long green after 'winning' the competition to buy Victor? Gosh!

SEXISM DEPT:

Lia Belli, the wife of famed attorney Melvin Belli, is running for the California state Senate. Her campaign literature asserts that she had been a Fulbright scholar, had graduated with high honors from the University of Maryland and had been awarded a master's degree by Occidental college. In addition, statements were made that she had been named Woman of the Year by the City of Hope and had organized a Northern California chapter of UNICEF, the United Nations Childrens' Fund.

It turns out that she had not been a Fulbright scholar, had not graduated with high honors from the University of Maryland and had not been awarded a master's degree by Occidental college. She was not named Woman of the Year by the City of Hope and had not organized a Northern California chapter of UNICEF, the United Nations Childrens' Fund. When these facts surfaced, she quite naturally blamed the resulting controversy on her opponent, who happens to be a male. (28 Sep L.A. Times p.3)

Hey, look guys: we know we gave the little darlings the vote, but is it too late to change our minds?

Page 16, Column 2

FARADAY vs. TAVA:

As we have reported before, it can be enormously profitable to sell stuff that does not belong to you. If you don't get caught, that is. Faraday, makers of a board-level IBM PC clone, have filed suit against TAVA, makers of an IBM PC clone. It seems that early versions of the TAVA were based on the Faraday board. Then for some reason TAVA started obtaining boards similar to the Faraday from other board vendors, but somehow (surely by accident?) the new TAVA boards continued to use ROM copies of the Faraday BIOS ROM. Faraday has gone to court with enough proof to get an injunction. Meanwhile, Faraday has licensed its BIOS ROM to NCR, which is using that BIOS (and Faraday's boards) in its PC4 systems. NCR can now use that BIOS in other PC designs... of course, NCR is PAYING for that privilege, a nicety that TAVA overlooked.

TRUMP BD: HALLOO!

Except for the occasional sentence in Jerry Pournelle's User Column, Ciarcia & Co's TRUMP BOARD seems to have disappeared. That design (and its software) seemed to us like the second best attached processor we have run into (ours has more expandability and some practical stuff like math chips and graphics to use that expandability for). Yet you just don't read about it. Has any reader crossed paths with that board? Would you tell us about it, please?

256K DRAMS:

NEC appears to be the leader in 256K DRAM production, having hit 1 million chips per month in July '84. NEC expects to be producing 2 million/month by year's end. Hitachi is close behind NEC and Fujitsu is behind Hitachi but in the ball park. Toshiba and Matsushita are way back, currently shipping a miniscule 50,000 chips per month each. Motorola and Mostek are just sampling, and T.I. is said to be sampling although it has not officially announced its product. (Sep 24 EW p.22)

If we assume that worldwide production of 256Ks is now 4 million units per month and that Apple is buying enough 256Ks for 40,000 Plump Macks a month, or 640,000 per month, then 16% of the world's current 256K DRAM production is going into Plump Macks. We say 'Plump' because the genuine Fat Mack, which was (and still is?) scheduled for production early in 1985 was to have had a logic board redesign to quadruple the data rate of its serial port, for instance. Introduction of the 'Plump Mack' this early reeks of a desperation move to placate frustrated software designers.

Incidentally, going from 128K to 512K is a 384K upgrade regardless of what prevaricators may say.

Page 17, Column 1

WE GET MAIL:

"I am writing regarding my subscription. On July 29th, I renewed my subscription by sending you a check for $15. You have cashed the check but now I seem to have stopped receiving copies of your newsletter. I'm used to receiving my copy on or near the first of the month and here it is, the 5th and no newsletter. My old subscription was good until issue #38. Is this the penalty for sending in my dough too soon? Please send me issue #35 as soon as possible and do what you can to put my name back on the subscriber list." Pierre M., Madison WI

We have received letters from folk describing DTACK as their monthly 'fix', Pierre, but we didn't think they were serious. We received your letter on the 8th and your issue #35 went out on the 7th with everybody else's. Next time we get a flu bug maybe we better mail notices? - FNE

"P.14 (#35): Dr. Dobb's benchmark 18.6 sec. P.17: HALGOL now does it in 16.8 sec... wish my obligations would go down as fast as HALGOL speeds up.

"Could you update us old slow 8Mhz owners as to what we can do with our boards vs. math chips, video etc." Ron D., Minneapolis MN

Ron, 16.8 sec is the correct figure when running the one-wait-state 12.5MHz Grande, as we correctly reported on page 17. Page 14 was written by our issue #35 co- author, the flu bug. He managed to transpose the 8 and 6. The old 8MHz boards run just fine with the experimental math board and with both video graphics systems, the VDHR and POTBOILER. You see, we have kept the expansion interface compatible right from the start; the Grande has an identical expansion interface. If your 8MHz board is memory-shy you will not be able to run a lot of the software which has been developed by various folk, though - FNE

John T. of Burnsville, MN wrote us a nice note about his HSC 68000 attached processor while subscribing to this rag. His HSC board just plugs right into a Z-80 socket, which makes for good compatibility with the various CP/M machines. He has a 6MHz 68000 with 256K RAM expandable to 768K. He also asks for our software on a CP/M compatible diskette. Uh, sorry, John! We do not even claim to be nice guys in general - asking us to expend any effort at all to support your Z-80/HSC 68000 system vastly exceeds our limited store of good will. Aside from that, welcome! (The fact that we do not SUPPORT our competitors does not mean that we otherwise knock or hinder them.) - FNE

Page 17, Column 2

"...By the way, you're completely off base on your comments about Rod in the last issue. First off, Nicklas Writh is spelled correctly. You must have confused him with his more famous Swiss colleague, Nicklaus Wirth, the father of PASCAL and MODULA II. Writh, from nearby Lichtenstein, is less well known but has nonetheless made significant contributions to our craft by developing critical algorithms to aid in the application of ski wax. His current project is an 8088 emulator that runs on any early 'Babbage Engine'. Reportedly, this combination results in a product that is actually quite faster than the PC itself.

"Your crack about nepotism was also below the belt. Rod was considering filing a libel action over this one, but no one in his family is a lawyer!" Buddy F., Director of Public Relations, Sage Inc.

Buddy, the grandmother of PASCAL and MODULA II spelled her son's first name without a 'c': "Niklaus". Please try to get that right? It's a good thing that Rod and family decided not to cross swords with us. We would have dredged up dirt all the way back to Rod's family founder Cuthrun Coldmaigne, not to mention British patriot Benedict Coldmaine or western badperson Ringo Colemain - FNE

(About that 'western badperson': we were watching a TV capsule review of Bob Hayes' athletic career recently. The commentator pointed out that Bob was the 'anchorperson' on the U.S. men's 4 X 100 meter relay team in the Tokyo Olympics. 'Anchorperson' on the MEN'S relay team? That sort of thing can give sexism a good name!)

"Thank you for the copy of Cascade's upcoming ad. It looks very professional. I wish them success - for entirely altruistic reasons, of course.

"Could you please mention in your next newsletter that I have written the 16081 math chip routines to work with Inter68 v1.2? These routines are now incorporated in the Inter68 package but early buyers (of version 1.2 only) can get them too for $10. The routines work with 1983 and 1984 chips alike. The speed-up ranges from 1.5 for single precision to 4.0 for double precision transcendentals. Terry Peterson's benchmark (news- letter #25, p.12) clocks in at 15.1 sec without the math chip and 4.1 sec when using the 16081 (all times for static boards). The root mean square error in the latter case is 9.3E-14 without and 1.28E-13 with the 16081. The larger error in the latter case is due to the fact that the 16081 uses a 53 bit mantissa, while the software routines use a 64 bit mantissa for intermediate results.

"My Stuffer board still doesn't work with my Grande!

Page 18, Column 1

And you have a French DTACK owner who has a similar if not identical trouble... Have you really tested the Stuffer/Grande combination?" Ulrich S., Aachen W. Germany

Ulrich, you mean my, er, OUR prediction in issue #26, page 5, the fourth from last entry in the table, was OFF BY AN ENTIRE 2.5%? 4.1 sec vs. a predicted 4.0? OH, THE SHAME OF IT! Of course, we did not then have the benefit of Nat Semi's marvelous ap note...

We have two or three dozen Grande/Stuffer owners in the U.S. and none of them are experiencing the problems you two Europeans are having. Question: does the timing of European Apple IIs differ in some significant respect from the U.S. versions? Keep in mind that the U.S. version has the odd memory cycle which is longer than most for compatibility with U.S. TV standards. We would be willing to bet that the problems both of you are having could not be duplicated on any of our machines here in Santa Ana.

Another West German has written to us pointing out that the new CMOS 6502s are static and would likely permit a 100% duty cycle when used with the Stuffer board. He asks how much faster this would let the Stuffer run? Our 68000 boards, both of them, are capable of transferring more than 1 megabyte per second. It is necessary to use deliberately inefficient 68000 code to prevent overwhelming both the Stuffer board AND the usual MOS 6502, which is a dynamic device and needs the occasional bus cycle to keep alive. However, the sample software we provide runs within 10% to 20% of the theoretical maximum, so a CMOS 6502 would not provide much improvement unless 10% or 20% was critical to your application.

Yet another West German has written, twice, to denounce us for not updating "Use of the DTACK GROUNDED 68000 Monitor/Bootstrap v.04". Well, the 68000 Monitor/_ Bootstrap v.04 has not changed for over 2 1/2 years now. That has a lot to do with why we have not updated it. True, the monitor used in the Grande IS v.10 - but the similarities are so great that we felt the same documentation, along with a note published in the newsletter about Command 10 which the West German in question obviously overlooked, would suffice. This writer asked altogether too many questions, including some which had been answered within the preceding 8 months in this newsletter. So we turned his second note over to our project engineer so he could get some experience with demanding, inattentive customer/_ readers!

For every letter we get bitching about documentation, we get at least one like the note from Ulrich S. above telling about wonderful accomplishments using the DTACK boards. There is a lesson there someplace. - FNE

Page 18, Column 2

"...Since CDC 7600s, Cyber 176s and whatever Cyber 800 series is the fastest are all scalar machines at 8 megaflops, people have been paying to run scalar problems on them for years. The 205 is also an 8 megaflop scalar machine and normally costs around the same as a 176 to a user. This means scalar problems are run on the 205, though it really shines when a problem is vectorized (a painful process given the CDC software support). The Cray-1 is a 21 megaflop scalar machine and costs about the same per CPU second as the 176 or 205, therefore you get 260% processing for about the same cost for a scalar problem. The Cray is used heavily for scalar problems.

"Two other considerations come to mind. The first is that both the 205 and Cray-1 address much more memory than the older CDC designs (limited to 64K words or 128K words, without extended addressing) and therefore larger problems can be solved more directly. With a 176 you had 128K words of main memory (60-bit words) and with special calls you could access up to 1 megaword of extended memory in 128K chunks. On a Cray- 1, the norm is 1-2 megawords of linearly addressable main memory and I hear the 205 is similar. Having lots of memory can often be very useful, as you have often pointed out.

"The other important consideration is that many problems do not vectorize well. A great deal of work is with Monte Carlo methods and though some parts vectorize, the real time consuming parts do not. Therefore only slight speed advantages come of vectorization.

"Am I seeing a change of attitude? A couple of issues back you went on about how you had to stay with the tiny Apple drives. Since they were so slow (using DOS 3.3), you want to do Blue Sky One, a super fast disk handling system. Some other people suggested ProDOS, but you are resisting. Another consequence is that you would not be getting the Iomega system. The reason here was if you had faster and bigger drives HALGOL would be written with them and would not run on the DISK IIs.

"Now you are hedging on the Apple drives and I cheer you. If you write your disk I/O routines with the idea they will need to interface with multiple disk formats and operating systems, you will support most configurations. Those of us who decide to go the Iomega route (or whatever you go with), will have the speed and storage. This will be since you would have written the needed I/O routines to do the work in the first place. Those with only DISK IIs would be supported because you would have little trouble (if you did it right) writing drivers for them and you do not want to burden your purchasers with a $2400 purchase that does not go into your own pocket. [Tsk! - FNE]

Page 19, Column 1

"...Let's fill in my viewpoint on the Mack. When the Mack came out I was happy, I found it easy to use and figured the 68000 community would get a boost. I didn't realize the "Apple Syndrome" still existed. This is the idea that 'Apple knows what is good for you and you are just going to do it the one true way'. My impressions are this is pushed hard by Larry Tesler and Steve Jobs and I do not like it. I feel I should be given the ability to do it any way I can." Bill J., Richland WA

[See the letter from Zhahai S. on p.16 of the last issue, and our invitation to Bill to comment.] Regarding Blue Sky One: as far as we know, Bill, we have not changed our attitude. Blue Sky One will have the substantial advantage that it will be a 68000 DOS, not a 6502 DOS such as DOS 3.3 or ProDOS. We are no longer interested in 6502 operating systems or DOSs, even if the system in question is the greatest piece of 6502 code ever written in the entire history of personkind! Blue Sky One will have the even more substantial advantage of being essentially free (media costs, you know).

ProDOS, on the other hand, was written to make the Apple II compatible with Apple III disk files and for no other reason. That was back when Apple stood 100% behind the Apple III and was promising to continue supporting the Apple III forever. (Forever expired five seconds later.) If there is anything we have less interest in than 6502 DOSs, it is anything written primarily to support the Apple III.

We have reluctantly concluded that there aren't any good hard disk systems out there at a reasonable price - YET. Our idea of a good hard disk 'system' includes a fast, inexpensive and reliable backup. We know a lot of you will disagree with us because there are so many really lovely ads running for hard disks with removable disk media. Naturally, all the hard disks pictured in those ads are readily available and highly reliable! We seem to remember that ads for the readily available, highly reliable Syquest drives have been running for two years now.

But we do need something better than the DISK IIs and something better than 6502 code. We don't like to talk too much about how well Blue Sky One would work in conjunction with a RAM disk because lots of our customers bought 92K static Ram boards two years (or so) ago and they aren't big enough for RAM disks. Now that IBM has officially blessed the new Japanese 1.2 megabyte (formatted) half-height 5 1/4 inch floppies by including one in the AT, we are looking hard at maybe interfacing a pair of those directly to the DTACK's 68000 via an interface board and a Western Digital controller chip.

Page 19, Column 2

We continue to receive letters, plural, from folks who want to connect the DTACK board to an IBM PC. We will do this when HALGOL is finished, honest! And that is not so far off now, as you can see elsewhere in this newsletter. In fact, if you are interested in the DTACK/CBM 64 combination read on...

M68000 Cross Assembler for Commodore Computers

Now available from T. & S. P. Software Products: "Commodore-compatible" versions of the Phase Zero cross assembler ASSEM68K. These versions run on the CBM 8032, CBM 4032 (with 4040 or 8x50 disk), or Commodore 64 (with 1541 disk). They are available at the address below, same price as the Apple version: $95 (U.S. funds, check or money order) each + 6.5% sales tax for CA residents. This is the "complete" Phase Zero package: ASSEM68K with 15+ page manual and example (up)loader program.

For the uninitiated: the Phaze Zero cross assembler ASSEM68K runs on a 6502 machine (Apple/PET/C-64) to assemble MC68000 assembler source files into MC68000 machine language (saved in binary on disk). It comes complete with a 'loader' program that will read the binary disk file and transfer it to an attached DTACK Grounded/Grande board. Source files may be prepared using the Commodore Assembler Development System Editor, almost any word processor, or the WATCOM microEDITOR (which is now available for the C-64, as well as the SuperPET).

HALGOL on Commodore

HALGOL (release 2) is running - not bugless, but complete - on BOTH the CBM 8032/SuperPET and Commodore 64 'hosts'. T. & S. P. Software Products is willing to supply (under DTACK license) a copy of the 'current' version (source and object with loader) on 4040/1541 or 8x50 disk(s) to a 'limited' number of requesters at the exorbitant fee of $10/disk (U.S. and Canada) or $12/disk elsewhere - CA residents add 6.5% sales tax. There is one disk for the 8x50 and three disks for the 4040/1541. ('Limited' means that when we get tired of making disk copies we'll quit.)

T. & S. Peterson
Software Products
8628 Edgehill Ct.
El Cerrito CA 94530

"It's great to see that I've finally made it into the big time in Silicon Valley... I still think that if you want to sell a product in the $1000 to, now, $2500

Page 20, Column 1

range, you ought to provide thorough background and be ready for lots of questions by mail. You've chosen to operate differently, with, apparently, at least modest success - more power to you." Peter R., Bethesda MD

Like we said before, Peter, no matter how carefully we explain how impossible it is to answer questions (ESPECIALLY from beginners), folks will still demand that we answer those questions anyhow. Uh - your suggestion that we should 'be ready for' questions DOES have an implied corollary that we ought to ANSWER those questions, doesn't it? By the way, it's nice to hear from you again. - FNE

A correspondent has falsely accused us of condensing his letter. We did no such thing, we EXCERPTED it, as we do nearly all of the letters we publish here. (When we condense a letter, we delete the correspondent's name, realizing that condensation runs the risk of changing the information content.) Take these two examples from a book about fishing:

"Call me Ishmael."

"A one-legged sea-captain organized a fishing expedition to catch a white whale, but the whale caught the sea-captain instead."

One of the above is a condensation while the other is an excerpt. We wonder if that correspondent can recognize the difference? He DID, in his letter of Sep 19, demand twice that we update his address - without providing his address in that letter, of course.

8088s: ONE CENT ?

Well, it finally is happening.

The management of those 40 IBM PC clone-makers have finally, about six months after sensible folk had already reached the conclusion, decided that they are not each going to grab 10 to 20% of the IBM PC- compatible market. And they are having a 'fire sale' on parts, like LSTTL and 8088 chip sets. Contracts to accept delivery of 64K DRAMs have been cancelled and the spot market is awash with 64K DRAM right now, forcing prices down generally. (Yes, this IS why we have just dropped our memory prices.)

Those LSTTL and 8088 chip sets are being sold into the 'gray market' - a place where sensible folk do not deal. We'll tell you why, and how the 'gray market' works, in another issue some day.

What is important to vendors like Nat Semi (LSTTL) and Intel (8088 chip sets) is that companies which formerly were buying are now selling.

Page 20, Column 2

It also means that the managers of those clone-makers have finally decided to stop piling up finished goods in the warehouses because if you are selling your basic component parts then you aren't using them to turn out finished goods, hmmm? EN, in its 9 Oct headline story gave the name, rank and serial number of the companies which are dumping parts. You'd recognize all of them. And there are more to come: it's going to get worse!

We have told you before about the COMING blood-bath. Now is the time to start talking about the blood-bath IN PROGRESS. Lots of folk who were working in the personal computer industry this last spring are going to be working for Burger King next spring - if all.

PUBLICATION FREQUENCY: Some of you have noticed that we are taking about six weeks per issue lately. One reason is we are doing lots of HALGOL programming. You can expect to continue to receive your newsletter later and later into the month. When we get real close to the next month we will have a 'Jan-Feb' issue, just like old times (see issues #7 and #17, for instance).

PERMISSION IS HEREBY granted to anyone whomever to make unlimited copies of any part or whole of this newsletter provided a copy of THIS page, with its accompanying subscription information, is included.

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; II, II+, IIe, soft: ProDOS, LISA, Mackintosh?: Apple Computer Co. Anybody else need a 188th 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

THIS ISSUE'S REDLANDS contains a explanation of HALGOL integers and arrays, plus a few examples and - oh, yes - our new price list. If you are wondering why we have dropped our memory prices by a third, it's because 64K DRAM prices have dropped by nearly that much, and we expect them to drop a bit further. There are NO shortages of LSTTL right now - and as recently as 60 days ago there were severe shortages. And we expect to sell more Grandes to an OEM to go along with our POTBOILER board, to hackers for the same reason, and even maybe some Grandes on account of cheaper RAM prices and HALGOL becoming nearly complete as a language. And for all of those reasons, Grande pricing has dropped substantially. We can now sell you a half- megabyte Grande for a tad under a kilobuck! Uh, AHEM! Merry XMAS, everybody!

Page 21, Column 1

INTEGERS:

HALGOL features conventional 16-bit twos-complement integers, whose value can range from +32767 ($7FFF) to -32768 ($8000). Adding a "%" onto the end of an otherwise normal variable name indicates an integer varn (varn = shorthand for named variable). Following are legal integer variable names: A%, A123%, ANTIDISESTABLISHMENTARIANISM%. Integers are highly useful as loop counters and indices (indexes) for arrays A(I%,J%,K%) and for string commands (MID$(A$,D%,J%)=V1$). We also have integer constants whose limits are the same as integer varn value limits and which are also used for indices and for string commands: A(I%,3,7) and MID$(A$,5,2)=V1$. Integers are also extremely useful when performing graphics.

32-bit integers are highly useful for business arithmetic but are significantly slower than 16-bit integers. We will wait until America's banking system is clamoring for HALGOL before implementing slow 32-bit integers.

Integer varns are treated just like floating point varns as far as HALGOL action code is concerned. For instance, the HALGOL run-time code for PRINT A% would be <PRINT VARN%>, [ A% ] where < > indicates the action address and [ ] is the offset address of the value of A% in the integer value table. At run time, the following code would load A% into register D1 to prepare for printing:

     PRINTV% MOVE.W (A6)+,A5 
             ADDA.L SOI,A5 
             MOVE.W (A5),D1

We move the offset address into A5, add the base address of the integer values SOI (Start Of Integers), and use that address to fetch the 16-bit integer value into data register D1.

INTEGER CONSTANTS:

Floating point constants are treated just like floating point varns except that they are kept in another table. Since F.P. constants are 8-byte values, they are indicated by an offset address (one word) in the HALGOL run-time code. But integer constants are one-word values and it is somewhat absurd to consider using a one-word offset address plus a value table offset to find an integer constant. We sensibly carry the actual constant around in the HALGOL program where an offset would otherwise be expected. Here is how we would move an integer constant from the HALGOL program into data register D1 (for instance):

     MOVE.W (A6)+,D1

Page 21, Column 2

That is a one-word instruction versus three instructions to load an integer varn into the same register. HALGOL is extremely efficient in working with integer constants.

INTEGER EXPRESSIONS:

HALGOL fully supports integer expressions. For instance:

     100 A%,B%=100*(((D%-47)/E%)*H%+347+ABS(K%))

is a perfectly legal line of HALGOL.

MIXED-MODE ARITHMETIC

is verboten at all times. Since Microsoft 6502 BASIC DOES support mixed-mode arithmetic, you may wonder why we are so lazy. We answer, it is not because we are lazy at all. Microsoft 6502 BASIC converts all integers to floating point before performing any arithmetic. This both explains why 6502 BASIC provides mixed-mode arithmetic and it also explains why integer arithmetic is so damnedly slow on the Pet and the Apple (using Applesoft).

On the other hand, sometimes one wants to convert integers to floating point before arithmetic computations. Consider the following mixed-mode formula (illegal in HALGOL):

     10 LET A = B% * C% + D%

Depending on the values of B%, C% and D% the expression on the right hand side of the assignment statement MIGHT (or might NOT) overflow if integer arithmetic is used. Depending on what sort of things are being kept in the integer varns (screen coordinates?) the programmer will generally know whether there is a chance of overflow and write the appropriate HALGOL code:

     20 CONVERT B%,C%,D% TO X,Y,Z 

     30 LET A=X*Y+Z

Or, if no chance of overflow this faster form:

     100 LET X% = B%*C%+D% 
     110 CONVERT X% TO A

MORE VERBOTEN MIXED-MODE:

HALGOL also forbids the use of floating-point values as indices for array elements or for string indices. This is a deliberate choice on the designer's part for two reasons: first, it simplifies the HALGOL action code and hence makes that code run a bit faster while taking up a bit less memory. But since HALGOL is not, after

Page 22, Column 1

all, a FORTH to crow about how small a run-time package we have here, the most important reason to exclude the use of F.P. indices is to force the programmer to write efficient code. Those persons who have been accustomed to programming PETs (all varieties) and Applesoft have gotten into the habit of using F.P. indices because there is no speed penalty. But there IS - make that would be - a severe speed penalty in HALGOL. So you guys and gals get friendly with integer indices real quick, O.K.?

HALGOL ARRAYS:

HALGOL features three kinds of arrays: floating point, integer, and string. At the time this is being written (5 Oct) F.P. arrays have been working, via default dimensioning, for two weeks and integer arrays for one week. We are in the middle of writing the DIM function, which is forcing us to consider how string arrays work, right now.

Some ground rules: we assume you know what an array is. Portions of this writeup are about four months old, dating back before we became heavily involved in the circuit board layout of POTBOILER. However, what we did back then was document, for our own use, how HALGOL arrays work! And then we discovered when we wrote the code that certain aspects of the run-time code did not mesh properly with the compilation, or that we had overlooked something, etc. So a second ground rule is that we are only going to publish here explanations of things that work - which means a largely second-generation writeup. It also means that we will not discuss how the DIM function and string arrays work, since they don't yet (although the DIM function is CLOSE!).

HALGOL MEMORY MAP:

A HALGOL program consists of a number of tables. For each table, there are two pointers which define the start and the end of that table. All of these tables except one grows upward in memory beginning at $A000 (for now). The single exception is the array table (array element table? array value table?), which starts at the upper limit of memory and works downward. If you have a full-house 92K static RAM board, the upper limit of memory is $18000. If you have a full- gallon Grande, the upper limit of memory is $100000 (be careful counting those zeros!). All right, so you have an extra 4K of memory at $FDXXXX! Nobody uses that 4K - yet.

So the F.P. array A(D%,3,7) will be default dimensioned 10 X 10 X 10. That's 1000 F.P. registers at eight bytes each. If this is the first array encountered in a program and if you have a full-house static RAM board, then this array will be allocated the memory

Page 22, Column 2

from $160C0 to (the byte just before) $18000. Pointer SOA (Start Of Arrays) will take on the value $160C0 and pointer EOA (End Of Arrays) stays at $18000.

Although arrays grow downward in memory (that is, successive arrays are allocated successive blocks of memory in a downward direction) the individual elements of a particular array grow upward in memory. That is, A(0,0,0) will be found at $160C0 and A(9,9,9) will be found at $17FF8 using our previous example.

HALGOL INDICES:

(The plural of index can be either indexes or indices, and we prefer indices. The word 'indexes' is ugly when spoken aloud.) The first index in HALGOL always has the value 0 (zero). An array dimension which has been dimensioned 10 has the legal indices 0,1,... 9. All indices are specified by integer varns or integer constants so the question of fractional indices does not arise. Naturally, negative indices are not permitted. More specific detail on the maximum indices permitted will await completion of the DIM function.

We have included run-time checking for illegal array indices, knowing that FORTRAN does not and also knowing that there is some overhead (time) associated with such checking. HALGOL is, after all, a language for we and thee to write our own programs in and if THEE makes no mistakes WE do!

MAXIMUM # OF DIMS:

F.P. and integer arrays can have up to 16 dimensions. However, arrays with four or more dimensions are treated differently at run time. For example, the HALGOL run-time package will refuse to default- dimension an array with four or more dimensions on the theory that the programmer must not know what the heck he or she is doing. (Default-dimensioning a five- dimensional F.P. array involves allocating nearly a megabyte!) There are also differences in the way the HALGOL program is stored; more on this later.

There are also some restrictions on the maximum number of elements in an array, but that is enforced by the DIM function and we don't have that working yet.

If you feel constricted by that limitation of 16 dimensions, you really should be programming in PASCAL.

DEFAULT DIMENSIONS:

F.P. and integer arrays, for now, are default- dimensioned to 10, which means that 9 is the largest legal index. We are not locked into the number 10 and we can easily change that number to, say, 11. The default dimension process just grabs more memory.

Page 23, Column 1

ARRAY TABLES:

We have up to now restricted ourselves to the array value table, which starts at the top of memory and grows (is allocated) downward. There are two other tables associated with HALGOL arrays, the array name table and the array descriptor table. Incidentally, these tables are shared by all three kinds of arrays: F.P., integer and string.

THE ARRAY NAME TABLE

differs from the name tables for simple integers and simple strings in that the '%' or '$' which distinguishes that data type is retained. In fact, that is the ONLY distinguishing feature which identifies the type of array! (Our initial writeup included a clumsy, elaborate flag in the array descriptor table to identify the type of array. Turns out it isn't needed; the incrementally compiled HALGOL program already knows what kind of array is involved!) The array name table otherwise is a linked ASCII table and works the same way the other name tables work (this has been discussed in detail in a past issue.)

And now, before discussing the array descriptor table, a confession:

ARRAYS ON THE CHEAP:

We admitted a few months back - that's before the POTBOILER project - that we planned to implement arrays 'on the cheap', meaning that we will not initially allow arrays to be incorporated into expressions. Instead we will enable the transfer of a variable (value) into an array element and also the transfer of an array element value into a named variable. Because this is a temporary expedient, we can give temporary names to the functions:

     MVA = Move Variable to Array (element) 
     MAV = Move Array (element) to Variable

Syntax examples:

     200 MVA VARN TO ARRAY(3) 
     210 MAV ARRAY(J%) TO VARNX 
     220 MVA X% TO A%(3,J%,4) 
     230 MAV A%(I%,J%,4) TO Y%

Here is a BASIC line number followed by its (for now) HALGOL equivalent:

     300 A = 5*M(I%,J%+1)+52 

     300 J1%=J%+1: 
         MAV M(I%,J1%) TO X: 
         A = 5*X+52

Page 23, Column 2

(We KNOW that's awkward. That's why we said this is a temporary expedient. No, we are not going to do it "right" by the day after tomorrow. Our job is to first get the language working, THEN worry about getting it working "right". For now it is awkward - but it gets the job DONE and done FAST! If you prefer "nice" to "fast", stick to Applesoft. Otherwise, please have some patience. We can't program the world in a day!)

MULTIPLE STATEMENTS:

That HALGOL example above showed multiple statements per line separated by colons, listed on separate lines. The separate line-listing is only for clarity; in practice the listing will be just like a Microsoft BASIC listing. Sorry about the red herring. Now, let us return our attention to arrays and the array descriptor table, please:

ARRAY DESCRIPTOR TABLE:

Each descriptor in the Array Descriptor Table will contain the following information:

1. The index of the descriptor
2. The number of dimensions of the array
3. One word (integer value) for each dimension
4. The 32-bit starting address of the array

The first three items in the descriptor are one word each, while the last item is a two-word value. Each descriptor contains 4 + N words, where N is the number of dimensions of the array.

There is only one descriptor table, and that table contains the descriptor of all of the various kinds of arrays: floating point, integer, and string. THERE IS NO INFORMATION IN THE ARRAY DESCRIPTOR TABLE TO DIRECTLY DETERMINE THE TYPE OF THE ARRAY! The HALGOL run-time code needs no such information. However, the type of the array whose index is, say, 3 can be determined by examining the LAST character of the array name (in the array name table) whose index is 3. Therefore, we can say that there is an INDIRECT indicator of the type of array in the array descriptor table.

Item 1) is the index of the descriptor, a number whose value is 0, 1, 2, ... , N-1 where N is the number of arrays (of all kinds). The index of the array descriptor is implicitly the same as the index of the array name in the array name table.

Item 2) is the number of dimensions of the array. This is a non-zero positive integer whose range is 1 thru 16 inclusive. This size is known before the program begins execution and does not change while the program is running.

Page 24, Column 1

Item 3) is the size of the given dimension, a non-zero positive integer. This size is unknown when program execution begins and so is initialized to zero as a flag. If the first dimension is still zero upon the first reference by the program to that array (i.e., a DIM statement for that array has not been executed) then the array will have each of its dimensions initialized to the default value 10.

Item 4) is the absolute address in memory (NOT an offset address) of the start of the array. Array elements begin at this address and grow upward in memory. This address is not known when the program begins; it is established when the array is dimensioned (either by default or by a DIM statement).

Except for the name (which includes the "%") and high bits of the first word of the array descriptor, integer arrays work just like F.P. arrays.

ZERO-BASED INDICES:

If we have an array with a dimension of, say, 10 then the index values which reference that dimension are 0, 1, 2, ... , 9. The largest index value is always one less than the dimension.

Some BASICs do not follow this convention. If you have ever had to calculate the indices of the Nth element in a multi-dimensioned array you would know why they SHOULD follow this convention! In any event, arrays and indices which work in this manner work fastest and fast is what HALGOL is all about. If the Arabs could figure out, over a thousand years ago, that zero (NOT one!) is the logical first number of an integer sequence then surely we can do as well?

WHITHER STRING ARRAYS ?

You will remember that we are only writing here about things that work and string arrays don't work yet. We will discuss string arrays later - hopefully in the next issue although one never knows with this rag.

ARRAY DESCRIPTOR OFFSET:

Most of you know by now that a HALGOL variable is specified in the run-time code by a 16-bit offset value. Add the offset value to the 32-bit base address of the value table and you have found the location of the variable in memory.

Similarly, a 16-bit offset value is used to locate a particular array descriptor. However, an array descriptor contains several elements. Where shall the descriptor offset point? To the index which is the first item of the descriptor? No, because that would be inefficient - we do not need the index at run time.

Page 24, Column 2

It turns out that in some cases the first item needed from the array descriptor table (at run time) is the number of dimensions, which is the second word of the descriptor. In other cases, the run-time code already 'knows' the number of dimensions and the first item needed from the array descriptor table is the first dimension value (size), which is the third word of the descriptor. So that is how the HALGOL code is compiled - the array descriptor offset will be the offset of the index of that array in the descriptor table PLUS either 2 or 4, depending on whether we first need the number of dimensions or the value (size?) of the first of the dimensions.

An example is the MAV function (Move an Array element into a Varn). The run-time code for MAV is compiled one way for arrays with 1, 2 or 3 dimensions and another way for arrays with 4 to 16 dimensions. If the array has fewer than four dimensions, the descriptor offset points to the value (size?) of the first dimension and the compiled code will implicitly know which of the words specifying the indices are integer varn offsets and which are integer constants.

MULTIPLE ACTION ADDRESSES:

This means that there are TWO run-time action addresses for MAV involving one-dimensioned arrays of type F.P. The first action address knows that the index is specified by a constant and the second knows that the index is specified by an integer varn offset. Similarly, there are FOUR action addresses involving two-dimensional arrays and EIGHT action addresses involving three-dimensional arrays. That is fourteen action addresses. If you remember your HALGOL theory, each action address has a list link associated with it, so we can list the program back out correctly.

There is ONE action address for MAV of type F.P. involving arrays of 4 to 16 dimensions. That means that we use an extra 16-bit word in the run-time code whose individual bits determine whether the index for that dimension is specified by an integer varn offset or an integer constant. It also means that the action address does not implicitly 'know' the number of dimensions so that the array descriptor offset points not to the value (size?) of the first dimension but to the number of dimensions.

That's a total of 15 action addresses for the MAV function for arrays of type F.P. Add another 15 for the MVA (Move a Varn to an Array element) function for type F.P. - that's 30 action addresses for type F.P. Add another 30 action addresses for type integer - that's 60 action addresses! And remember, for each action address there is a unique list link (list routine address).

Page 25, Column 1

Gasp!

Did you really read that last page? Paying attention, we mean? If so, congratulations - we think. Now we're going to discuss array name conflicts and then provide some examples to (we hope) clarify the preceding pages, especially that last one. (We will pause momentarily while the cheering quiets down.) We will first provide a generalized example, then a specific example with actual values PRESENTED IN THE SAME FORMAT, and finally on the next page the same examples presented as screen dumps of actual (very short) HALGOL programs.

SAME NAME DEPT:

We will eventually have a file-handling system which will work with straight-forward statements such as:

     DATASAVE A(),A%(),A$(), ...

We don't think Applesoft works that way, but most minicomputer-type BASICs do. Certainly the highly successful WANG BASIC-2 operating system for the WANG 2200s (which are still in production) works that way. Since we are saving a binary image of the arrays, the process is one heckuva lot faster than converting all the numbers to an ASCII string and then using the INPUT function when reloading those arrays from disks.

However, note that since we save entire (not partial) arrays, there is no indication what number of dimensions - or what size dimensions - the arrays have. So, what if we have array A(2,3) and A(3,4,5) - in other words, two floating point arrays with the same name but a different number of dimensions? Answer - we do not permit two arrays with the same name and a different number of dimensions! If you try it, the program line with the second array dimension usage will be rejected and an "ARRAY SIZE MISMATCH" error issued.

On the other hand, using A() and A%() and A$() is all right because the NAMES of the three arrays are NOT the same! Remember, the "%" and "$" are a part of the array name as stored in the array name table. So there is no conflict there. It works like this: when DATASAVE is executed, it abstracts the first name, in this case an array whose name is "A". The array-name 'finder' will report the index of "A", NOT the index of "A%" or "A$". Since those array names have different indices, they in effect 'POINT' to different descriptors in the array descriptor table. Like we said, no conflict. Remember, there is a one-to-one correspondence between names in the array name table and descriptors in the array descriptor table.

Yes, we will permit simple variables to be DATASAVEd as well as arrays. It's just that the subject under discussion was arrays.

Page 25, Column 2

     MVA N TO A(3,4,5) 

       <MVA> 
       [ N ] 
       [ A ] 
       [ 3 ] 
       [ 4 ] 
       [ 5 ]

What we have above is the action address for MVA, followed by the offset address of N, then the offset pointer to the first dimension of array A, then the indices 3, 4, and 5. Here is the actual code from the next page in the same format:

     <44B8> 
     [0000] 
     [0004] 
     [0003] 
     [0004] 
     [0005]

The HALGOL program currently begins at $A000 and does not move around since it is the first of the HALGOL tables. The array descriptor table on the other hand does move upward in memory as the HALGOL program grows, so what we need is a pointer to that table - and we got! The array descriptor table pointer is located at $15D0. The command HPR@ $15D0 tells the HALGOL operating system to locate the address stored in that pointer, print it out, and then print the data found at that address. Another example:

     MAV A(7,14) TO X 

     <MAV>  <42B4> 
     [ A ]  [0012] 
     [ 7 ]  [0007] 
     [ 14]  [000E] 
     [ X ]  [0008]

The final screen printout on the next page is two examples of the same floating point array with (choke!) 16 dimensions! We will leave it as an exercise for the student to determine how much RAM would really be required to run that program! The point is, as an array with more than 3 dimensions, it has the additional type flag word AND the array descriptor pointer points to the number of dimensions, not the first dimension.

Note that the type flag word is $0000 for the first occurrence of the array since all of the indices are constants. The type flag word for the second occurrence of the array is $FFFF since all of the indices are (integer) variables.

Page 26

10 INPUT N 
20 MVA N TO A(3,4,5) 
30 MAV A(3,4,5) TO X 
40 PRINT X 

RUN 

? 7.7 
 7.7 

END PROG 
                    DESCRIPTOR PTR TO 1ST DIMENSION 
HPR $A000,$3          | 
3D8C 0000 44B8 0000 0004 0003 0004 0005 
4312 0004 0003 0004 0005 0008 3DC4 0008 
3D6E 0000 000A 0014 001E 0028 FFFF 0000   (END) 
====                                       === 

HPR@ $1D50 

$00A0AC    (ARRAY DESCRIPTOR TABLE) 
0000 0003 000A 000A 000A 0001 60C0 0000 
|__|                     |_______| 
  \INDEX                     \ ARRAY ADR 

(DIMENSIONS DEFAULTED TO 10) 

 

 
10 MVA N% TO I%(D%,E%,F%) 
20 MAV I%(17,13,11) TO X% 
30 MVA N TO A(D%,E%) 
40 MAV A(7,14) TO X 
                       DESCR'TR PTR TO 1ST DIMENSION 
HPR $A000,$3                        | 
XXXX 0000 0004 0002 0004 0006 463A 0004 
0011 000D 000B 0008 XXXX 0000 0012 0002 
0004 42B4 0012 0007 000E 0008 3D6E 0000 
           |                  ==== 
 DESCR'TR PTR TO 1ST DIMENSION 

    XXXX = <MVA> CODE BAD - SORRY! 

 
HPR@ $15D0 

$00A0DC 
0000 0003 0000 0000 0000 0000 0000 0001 

(NOTE DIM'S NOT ASSIGNED SINCE THE 
                 CODE HAS NOT BEEN RUN) 

 

10 MAV A(1,2,3,4,5,6,7,8,9,10,11,12,13,1 
4,15,16) TO X 
20 MAV A(A%,B%,C%,D%,E%,F%,G%,H%,I%,J%,K 
%,L%,M%,N%,O%,P%) TO Y 

 

HPR $A000,$6 

       TYPE FLAG WORD 
       /   DESCR'TR PTR TO # DIMS 
      /    / 
48D0 0000 0002 0001 0002 0003 0004 0005 
0006 0007 0008 0009 000A 000B 000C 000D 
000E 000F 0010 0000 48D0 FFFF 0002 0000 
                          /    / 
                         /  DESCR'TR PTR TO # DIMS 
                       TYPE FLAG WORD 

0002 0004 0006 0008 000A 000C 000E 0010 
0012 0014 0016 0018 001A 001C 001E 0008 
3D6E 0000 000A 0014 FFFF 0000 0000 A000 
====

Page 27

                                       15 Oct '84 

YE DTACK GROUNDED PRICE LIST 
---------------------------- 

DTACK Grande: 12.5MHz 68000: 
(for Apple II, 1 wait state) 

less aux. bd:  with aux. bd: 

128K   $695      640K  $1295 
256K   $795      768K  $1395 
384K   $895      896K  $1495 
512K   $995     1024K  $1595 
                  : 
                  : that's a megabyte, folks! 

Accessories included: 

   3 unlocked disks demo & utility software 
   hard copy of monitor routines source code 
   hard copy of floating point source code 
   interface cable & Apple II, IIe interface adapter bd 

Accessories required but not included:  case & power supply 

Dimensions:  15 inches by 6 1/2 inches 
Power required:  +5 volts regulated at 3 Amps (max) 
                       (1.8A/128K & 2.2A/1024K typ) 

 
Grande AUXILIARY MEMORY BOARD 
(When purchased separately: 
    128K  $345    384K  $545 
    256K  $445    512K  $645 

 
'POTBOILER' COLOR GRAPHICS BOARD 
(INCLUDES 7220 GRAPHICS CONTROLLER) 

    $550 

640 H X 400 V pixel resolution, 8 colors, 22.4MHz pixel rate 
60Hz refresh rate, absolutely NOT interlaced! 
Drives Tandy 2000 color monitor or its Mitsubishi equivalent 
Self-contained 128K byte refresh RAM                  | 
                                                    (AT-1341A) 
Accessories included: 

   interface cables to DTACK board 
   1 unlocked disk with test & demo programs 

Accessories required but not included: 

   DTACK 68000 board (static or dynamic) and power supply 
   Tandy 2000 (or Mitsubishi) color monitor and video cable 
   case & power supply 

Dimensions:  15.75 inches by 6 1/2 inches 
Power required:  +5 volts regulated at 3 Amps (max)

Page 28

EXPERIMENTAL 32081 MATH CHIP BD(s): 
 (SOLD LESS THE 32081 MATH CHIP(s)) 
  Compatible with both static and dynamic RAM DTACK boards 

   1-holer  $105    3-holer  $135 

Accessories included: 

   1 unlocked disk with logarithm routine source & object code 
   interface cables to DTACK 68000 bd 

Accessories required but not included: 

   Nat Semi 32081 floating point math chip(s) 
   DTACK 68000 board (static or dynamic) and power supply 

 
Stuffer BLOCK DMA INTERFACE 
(for Apple II, II+, IIe) 
      (WORKS WITH Grande or GROUNDED) 

       $130 

Accessories included: 

   complete schematic and 1 unlocked disk with demo prog & source 

 
GENUINE STAINLESS STEEL DTACK CASE 
  Designed to contain a DTACK 68000 bd and three accessory boards 

  bare case:  $60   complete:  $195 

The complete case includes a 5V 10A power supply,  line filter, and 
power cord;  wired and tested. 

Accessories required and/or included:  none 

SCHEMATICS: 

  Apple/static DTACK interface schematic          $5 
  Pet/CBM/static DTACK interface schematic        $5

(Like HP, DEC and Wang we consider our CPU circuitry proprietary)

All prices are in U.S. funds.

6% California sales tax must be included when applicable.

(Our VDHR (very-damn-high-res) graphics board(s) for use with the Grande or GROUNDED boards are now in production. The graphic controller uses a 5MHz NEC 7220 and sells for $600; each bit plane is $500. WARNING: these boards are NOT suitable for private party hacker use! See newsletter #29.)

(Our no-wait-state static RAM boards and static RAM expansion boards are now available by special arrangement only due to lack of demand. Prices - and delivery - will be individually negotiated at the time of sale.)