Issue # 39 DTACK GROUNDED Newsletter - February/March 1985
BOY! DO WE GET MAIL!
After the very tactful reminder which led off the last issue, we received lots of checks. We also received quite a few notes and letters with many of those checks, so we have a greatly expanded mail section this time. After filling 8 pages, we decided to postpone until the next issue a missive from New Zealand. Some of our horse-whip wounds may have healed by then.
DRAM PRICES PLUMMET:
64K DRAM prices have dropped like a runaway freight elevator, and we have adjusted our prices to match (p.22). We are now selling 150nsec DRAM at the incremental price of $64/128K. Lots of other companies are still selling their memory upgrades for about $300/128K, which is (ahem!) VERY profitable if they can find suckers to stand still for it. Wang Labs still wants $1,200 for a 32K memory upgrade for its 2200 LVP line, which is why we don't own a 2200 LVP. (We really would like a modern 2200 as a test bed for BASIC 2, the best BASIC now in existence.)
LETTING GEORGE DO IT:
One of the reasons we are making HALGOL source code available is so the more ambitious and competent HALGOL programmers can extend the language for their own purposes. However, this has up to now seemed a formidable undertaking to most of you. After all, in addition to programming the run-time code for the function itself you ALSO have to program the parsing and compilation of the code and the listing of the code. That is THREE programming tasks, not one.
All right, suppose that YOU need a special function that involves, say, two integers and a 4-byte string variable (32-bit arithmetic, anyone?). We will call the special function GEORGE. The syntax is:
GEORGE X%,Y%,Z$Page 1, Column 2
Math chip & hi perf micro update pp2-3. IBM watch p.3. Unix p.4. Aussie 68000 hackers p.6. DTACK disk report p.7. QD DOS pp8-11. Mail call pp12-19. 68796 hacker newsletter, p.18. Updated DTACK FORTRAN p.19. HALGOL REVIEW p.19. Apple watch pp20-21. New DTACK prices p.22. HALGOL v.03 release, p.23. REDLANDS pp24-28.
It so happens that writing the parsing and compilation code and the listing code for that function is a piece of cake for FNE because we have written very similar code enough times that we have had lots of practice. Suppose we DO write such code, and also provide the framework for the run-time code. For instance, the absolute (32-bit) address of X% could be in D0.L, the value of X% in D1.W, Y% likewise in D2 and D3, Z$ likewise in D4 and D5 plus maybe an error trap in case the programmer has failed to dimension Z$ as a 4-byte string. And then we plug in a TRAP13, so that an attempt to run the unmodified code will result in a screen dump of the register contents. That way the programmer could assure himself that GEORGE was really doing things (setting up addresses and values) correctly. The TRAP13 can be followed by two NOPs to provide room to replace the TRAP with a JSR to a long_ word address.
Now, THAT is your basic easy-to-extend high level function! For the price of a six-pack of Heineken Special Dark, we would even be willing to reveal how to modify the name (GEORGE) to something more pleasing (ROTATE, MERVYN, QUASH, FOO).
And if we maybe add a few more pre-programmed functions to help GEORGE out - we could call these HARRY, BOB, ELWYN, SMITTY and maybe some other stuff (we are keeping this clean, naturally) - it might be REAL easy to extend HALGOL! In fact, by examining the parse, compile, list, and run-time framework for these functions in the HALGOL source you just might learn enough to program your very own GEORGE functions!
The different GEORGE permutations will have different argument lists and syntax, for instance:
HARRY W%,X%,Y$,Z$
BOB X,Y,Z$,A()
ELWYN X,Y%,Z$,A%()
SMITTY Y%,Z$,A$()You get the idea.
A 68000 TINY BASIC!
Be sure to see the Feb issue of Dr. Dobbs, which features a tiny BASIC which runs in a mere 3K RAM.
Page 2, Column 1
MATH CHIP REPORT:
The Jan issue of COMPUTER DESIGN carries an update on two competing LSI double-precision floating point math chip sets - the ones by Analog Devices and by Weitek. Despite the subtitle on page 165, the Analog Devices chip set is NOT available now, not even for sampling. But the forces of competition are working for us (potential) end customers: The Weitek chip set is down from $2200/100ea to $600/100ea. And it does divide. And single precision as well as double precision. Of course, the Weitek set isn't available yet either.
Another chip which is not available is the Motorola 68881, but apparently they have somewhat working samples and are selectively sampling them (translation: General Dynamics and Honeywell can get ONE but Digital Acoustics cannot). Motorola is now promising working parts in low production quantities for this summer but you will want to remember that the 68881 was promised originally for 1982 and honcho Jack Brown made a DEFINITE promise of Nov '84 delivery in Aug '84. Our guess is initial across-the-counter distributer (retail) parts won't be available this year, although samples will be (samples Digital Acoustics can buy, that is) by this summer or fall.
The good news is that the 68881 is reported to be very fast, especially on transcendentals. The bad news is that it appears to be best suited for use with the 68020, not the 68000. Accordingly, we have commissioned a version of the HALGOL F.P. math routines to be written for the 68000/32081 combination. Not, we insist, that we could not write such routines ourself if we had enough time - see, for instance, pp23-28 of issue #26 of this rag - but we really ARE as busy as we have told/complained about!
68020 REPORT:
Over a year ago we estimated that we had a 50% chance of getting a sample 68020 by 1 Jan '85. At the time Motorola was swearing up and down that samples would be available no later than summer '84. Well, we received our first two 68020 samples, at $610 each (we kid you not), during the second week of 1985. These samples run at 12.5MHz, and have a wart list as is usual for initial samples of such complex parts. We still think that our year-old prediction of initial production 68020 parts in summer '85 is a good one.
We haven't made a final decision as to just what to do with these samples yet - it becomes increasingly evident that a 5 or 6-layer circuit board will be needed to make these babies work. If that seems obscure now, wait until you see the part... Does anybody know a source of cheap, repairable, and reliable 5 or 6-layer printed circuit boards?
Page 2, Column 2
16MHz 68000 REPORT:
You will remember the ads run by Thompson CSF, a French company, last summer. They claimed that they had 12.5MHz units THEN, and would have 16MHz 68000s before the end of '84. WRONG! They now assert that you can order 12.5s if you are willing to wait 8 to 10 weeks for delivery. 16MHz 68000s they ain't quoting.
Meanwhile, Hitachi has abandoned its attempts to reach 16MHz with its shrunk-mask NMOS 68000.
10MHz 80186 REPORT:
AMD (Advanced Micro Devices) is producing some 10MHz 80186s in addition to the 6 and 8MHz variety. A 10MHz 80186 is a VERY respectable machine, essentially equivalent to a 10MHz 68000 for small databases. (It's limited to 64K program and 64K data). Unfortunately, Intel chose not to produce an 80187 math coprocessor. While it is apparently possible, using a lot of extra, expensive circuitry to adapt an 8087 to the 80186, apparently nobody is doing this. We hope IBM's forthcoming PC II doesn't make a liar out of us.
INTEL iAPX 386 or 80386:
There has been absolutely no publicity of late about the 386, which means that it is coming along slowly. Intel was claiming a year ago that it would be sampling in the third quarter of '85. Our guess is nobody is going to get their hands on a 386 until '86. However, the prospect of a 32-bit computer which can linearly address no more than 64K is fascinating...
Z800 and Z80000 REPORT:
Valentine's Day 1985 will be Zilog's tenth anniversary. Somebody got the bright idea of introducing real, honest chips - first silicon anyhow - for the Z800 and Z80000 on that date. Then they commissioned a very nice short video tape to promote the chips and that date. By the time we got that video tape last fall the Z80000 was already late and now the Z800 won't make that date either.
The Motorola 6809 would have been a great product in 1978, but it got introduced in 1981. The Z800 would have been a great product in 1982, but it looks as if it will be introduced in 1985 - maybe. Our guess is that nobody is going to hold a Z80000 in his hand this year. Besides, the Z80000 is limited to 64K linear addressing, like Intel's 80286. Like the 286, it has an elaborate memory management scheme built onto the chip.
We wonder if it will take as long to debug the Z80000 as it is taking to debug the still-buggy 286?
Page 3, Column 1
RISC MACHINES:
We have been assured by two readers (Bruce W. and Nick T.), using independent reasoning paths, that Dr. Tabak & colleague were almost certainly NOT deliberately 'sending up' the RISC concept (issue #38, p.2). So we apologize to Dr. Tabak and his colleague for (apparently) misrepresenting their views. However, we insist that our view of their papers as a REDUCTO AD ABSURDUM of the RISC concept is supportable, and we are NOT backing down from that view.
Meanwhile, you might check out the 10 Jan ED survey of RISCs (p.174) or the contemporary article in EET.
TRANSPUTER WATCH:
Although INMOS reported 'first silicon' on the Transputer two or three months ago, that was apparently just a test mask, known to be incomplete. INMOS now talks about 'completing the metallization (interconnection) layer', and that if you are hot for the Transputer you will get hold of their OCCAM cross-compiler, the one that runs on a VAX, and not bother them until the end of 1985...
If INMOS did not have a skilled, sensible programmer (C.A.R. 'Tony' Hoare) on their staff we might respond to that last suggestion in a VERY rude manner.
TO OUR YOUNGER READERS:
Judge Crater walked away over 50 years ago and never came back. To OUR generation, he is the most famous missing person of all time. We would explain that Ambrose Bierce studied and publicized his disappearance, but you probably haven't heard of Bierce either. Maybe we should have used Jimmy Hoffa instead of Judge Crater?
The St. Catherine Hotel on Catalina Island, in its day the island's largest, was torn down about 25 years ago. The great auk, a large sea bird of the North Atlantic, has been extinct for nearly 150 years. With these hints, perhaps you can interpret an item on p.4 of the last issue.
MORE IBM STUFF:
No sooner had we printed out (using double strike to get a good, dark image) the master and backup prints of the last newsletter, in which we reported that IBM was not well thought of amongst hard disk vendors, when the 31 Dec issue of EN arrived. Therein we learned that 1) CMI, which makes the hard disk for IBM's AT, came VERY close to telling IBM to TAKE A HIKE, which IBM headed off by 2) renegotiating the price of CMI's drive upward from $500 to $550 and by 3) making a non-
Page 3, Column 2
equity loan of $6 million to CMI and by 4) providing a letter of intent to CMI for the purchase of 240,000 hard disk drives in 1985. A letter of intent from a company like IBM is generally good for a line of credit with a bank.
IBM was driven to such lengths of generosity because it is run by such nice people - and also because it had no choice. We say again: CMI, for real, VERY nearly told IBM to take a hike!
We are beginning to suspect that IBM has made yet another enormous miscalculation - this time, that the PC/AT would be purchased (in its hard disk model) almost exclusively for use as a multi-user system, and that single-users would buy the floppy disk version. Instead, massive numbers of ATs with hard disks are being purchased by corporate single users and the floppy disk version is being massively IGNORED. Worse (for IBM), nobody seems to want the XT any more, and IBM evidently planned to continue selling the XT as the top-of-the-line model for single users... and has lots of completed inventory to back that plan up!
At least one retailer (ComputerWorks of Westport, CT) is now "qualifying" its customers! Translation: "No, no! As a single user, all you need is an XT. You really shouldn't be buying an AT - that's way too much computer for a single user like yourself!" For some reason, we suspect this sales ploy will not be a wild success.
Later: in Feb BYTE Pournelle suggests that an acute shortage of 6MHz 286s is behind the shortage of ATs. Like we said last issue, there are MANY rumors about the cause of the AT shortfall. Our favorite is also PC WEEK's: too many unsold XTs on the shelf! We say yet again, IBM expected the AT be purchased for multi-user installations and never DREAMED the AT would cut into XT sales.
(Hmmm... could it be that Pournelle is HALF right - that there is indeed a severe shortage of 286s for IBM personal computers, but that it is a shortage for the new PC II, NOT for the AT? Of course, that would require that WE be proved wrong about the PC II being based on the 186, but we've been wrong before.)
BRITISH WATCH:
While the its larger North American colony has gone bananas over the IBM PCs (various models) and, in distinctly lesser quantities, Apple's Mackintosh, it is interesting to note that the mother country has managed to restrain its enthusiasm for either of the above. In fact, the British marketplace looks like the U.S. market four years ago - lots of competing brands and models, most of them 8-bit 64K machines.
Page 4, Column 1
The MSX machines which us Yanks can only read about in BYTE arrived in Britain in force last year, apparently with some success. It will be interesting to see if the Japanese try to duplicate that success in the U.S. in 1985. They CAN'T - mostly because they will be a year late, but also because the market for cheap 8-bit 64K machines has nearly vanished in this country but NOT in Britain. The average working Joe in Britain has a lot less discretionary income than his U.S. equivalent and that places constraints on the price tag of 'popular' computers over there.
(This is twice we have asserted that the British have less discretionary income. If you doubt us, check paragraphs 2 and 3 of Briton Dick Pountain's report in 'Jan BYTE, p. 401. That's Jan, not Feb.)
INFOWORLD WATCH:
James Fawcette's editorial in the 28 Jan issue (p.5) has much to recommend but nevertheless contains 2.5 significant errors. Fawcette writes: "...Apple still outsells IBM in retail markets". WRONG! According to Future Computing, Nov RETAIL sales show IBM suddenly jumping above Apple by 40%! True, that was the first month (and the most recent reported month) IBM led Apple in RETAIL sales, but 40%? Wow! (A breakdown of IBM PC sales by product shows that an enormous surge of PCjr sales accounted for ALL of that 40% - honest! See PC WEEK, 22 Jan p.110.)
Fawcette writes: "The PCjr is only IBM's first attempt in (the home) market." WRONG! Remember that the PC was originally a BASIC-in-ROM machine with 16K RAM and an audio cassette interface for program storage - and small computers with audio cassette interfaces for program storage are HOME machines.
That's two mistakes; now for the .5 mistake:
Fawcette writes: "Apple badly needs to get Mack technology into a home product." HALF RIGHT! Apple also badly needs to get 'Mack technology' OUT OF MACKINTOSH so folks can use it in simple ways like, for instance, the Apple II. The simplified Mackintosh would lack icons and drag-down menus and San Francisco type fonts but it would GREATLY simplify porting ordinary and usual computer programs to the Mack.
But even with 2.5 mistakes Fawcette's editorial is otherwise close to the mark.
UNIX/WORLD WATCH:
The best UNIX-related slick magazine (of two contenders) is now also the largest, even though it was second out of the starting blocks. UNIX/WORLD now publishes over 120,000 copies per issue.
Page 4, Column 2
Publisher Knapp has given up trying to take your PC away at gunpoint and has noticed (Feb '85 p.7) that there isn't room in the UNIX market for 200 UNIX-based 68000 systems. Gosh, what a surprise!
Editor Gill asserts (p.9) that "...the UNIX system is likely to never be all things to all people." Furthermore, he never once tells us about UNIX gaining momentum because somebody announced some more UNIX vaporware. Now, that IS a surprise!
You will remember Jean Yates' 1982 prediction of 600,000 UNIX system sales in 1983, which proved to be slightly optimistic. Well, Jean was then an alumnus of market research firm Gnostic Concepts. When she left, her position was filled by Brian Boyle. In 1983 Gnostic Concepts prepared, presumably with Boyle's help, a more conservative estimate of 1984 UNIX system sales. That estimate was for 124,000 systems, nearly five times fewer than Yates' prediction (and a year later in a supposedly expanding market!). Well, 1984 is over and guess what? Right! UNIX system sales fell short of that prediction.
As Boyle reports (p.50): "...things have fallen somewhat short. A number of mild surprises, but nothing in the way of a positive surprise." With tongue firmly in cheek, he points out that "Cray projected they'd sell two, and so far they've sold zero." SHAME, Brian!
Remember that UNIX/WORLD pays its bills with advertising income. That's why the reviewer who correctly reported, in excruciating detail, how horribly slow the A T & T 3B2/300 $16,000 'SuperMicro' is at floating point calculations (five times slower than a $69.97 VIC-20) was careful to report that that same SuperTurkey was an outstanding value and that he was going to recommend it to his clients...
MORE UNIX STUFF:
A T & T decided to hog the profits on System V, so independent OS vendors are avoiding it like the plague. Pay attention now: "(A T & T) changed their licensing agreement so that you couldn't pyramid them. They got restrictive. They said the company that remits the royalties to A T & T must own all the sources its sublicensees distribute. This has discouraged systems houses from going to a company like Microsoft, because they would have to hand over their source codes." That was Robert Swarz, president of Mark Williams (the COHERENT folk), quoted in Jan 21 EN (p.34).
So what does this mean? Well, you will recall that Intel (they make microprocessors, remember?) had adopted Microsoft's XENIX as their (Intel's) internal standard operating system. When Intel decided to
Page 5, Column 1
follow A T & T's lead and implement UNIX system V on the 80286, they naturally approached Microsoft to do the job for them. Heck, everybody knows that XENIX is really UNIX, right? Uh, wrong. A T & T had set the rules such that Microsoft could not 'leverage' off XENIX - in other words, having written 'UNIX' once, Microsoft would have to write UNIX all over again from scratch. Microsoft looked at its existing work load and politely declined the job.
Intel was placed in the humiliating position of finding another software house to implement a SECOND UNIX (remember, XENIX is really UNIX, right?), this one incompatible with its internal house standard, for its 80286. Wunnerful, wunnerful! Digital Research, the CP/M folk, reluctantly accepted the job. They have finally delivered. Late.
Pay attention again, now: John Rowley, DRI prexy, publicly asserted that "UNIX has not been an overwhelming success in the commercial marketplace." DRI then tossed out all of its ongoing work on UNIX System V. (EN politely asserted that DRI "spun out" two groups. Don't you believe it: the word is 'toss'!)
The first group to be (ahem!) 'spun out' was the UNIX Library development group. That group has already folded for lack of funding.
The second group consists of the folks who did that 80286 System V port, who have set up shop under the name Microport Systems. A third group, which had been working on System V applications, is being quietly disbanded, as in 'here is your pink slip'. The total amount of money DRI has invested in any of these groups is apparently zero. Continuing to quote EN:
"With the move, DRI said it is abandoning any future System V porting projects and operating system-level developmental work.
"Of concern to DRI was the prospect of competing directly against A T & T while abiding by A T & T's licensing terms. 'It just turned out not to be a viable thing for us to do,' Mr. Rowley noted. 'A T & T is actively marketing UNIX themselves.'
"At Microsoft, Adrian King, XENIX product director, had a similar observation, noting 'A T & T has become a fairly aggressive competitor in the marketplace.'"
So there you have it: A T & T, with its recent changes in its licensing policies, has assured that it will corner the lion's share of any monies generated by System V while simultaneously assuring that there will be precious little monies garnered because folks will look elsewhere. They already have.
Page 5, Column 2
For instance, just exactly who is going to port System V to Intel's forthcoming 80386. That's '386', not '286'. Hmmm? Embarrassing, isn't it?
AT & T has shot itself in the foot again. You know, with foul-ups like this, we should not be surprised that their $16,000 'SuperMicro' is five times slower than a $69.97 VIC-20. AT & T has been trying to lay off folks lately, or maybe get them to retire early. How many folks? Try middle five figures. Yep, FIVE!
AMLYN AND DRIVETEC
were the two companies pioneering the high-capacity 5 1/4 inch floppy disk drive market. Amlyn was bankrolled by Dysan and was cut off along will all the other startups bankrolled by Dysan just before Dysan was acquired by (Xitec? Xintec?). We had thought that Drivetec had landed a contract with Wang Labs but apparently not - their big customer was KayPro, and the only product in the KayPro line which used the Drivetec stuff was the 'Robie', which is doing poorly in the marketplace. Drivetec is now down to fewer than 10 employees...
It seems that the "IBM technology" in the high-density AT drives is (for now) the limit of dependable 5 1/4 inch storage for conventional floppy disk drives. You and we know that that is not "IBM technology" at all, just ordinary two-year-old Japanese technology.
More and more U.S. floppy disk manufacturers are vanishing. The latest is Shugart, which some folks used to think was immortal. Jugi Tandon didn't get much respect a few years back, but he gets lots these days - Tandon is the only really healthy U.S. floppy disk drive manufacturer. Even if most of the actual manufacturing is done across the Pacific.
(Tandon will be even more healthy if it wins its two actions against far-east competitors - one against Gold Star of Korea for industrial espionage, and one against a number of Japanese suppliers, notably including Sony, for infringing Tandon's patents for two-sided disk technology. The double-sided Sony drives being used by H.P., (and presumably the double-sided drives ordered by IBM from ALPS and Toshiba) are among the models which Tandon asserts are infringing.)
[Later: to prove how volatile the small computer disk peripheral market is, a couple of days after we wrote the above IBM cancelled Tandon's contract to supply 5 1/4 inch floppy drives - a contract which accounted for 58% of Tandon's $400 million '84 shipments! True, IBM gave Tandon a new contract as a second source for its AT hard disks, but initial shipments of that contract do not begin until September. Not only has Tandon lost 58% of its customer base, but there is some speculation
Page 6, Column 1
that IBM may refuse to pay Tandon for product in its production pipeline. Didn't we write a while back that IBM is viewed as a bad customer in the small disk marketplace?]
With IBM's supply of 5 1/4 inch floppies cancelled, exactly how long do you think it will be before the PC is phased out and the PC II, based on 3.5 inch floppies, is introduced?
MORE 68000 HACKERS:
Yet another 68000 hacker organization has surfaced, this one in Australia. We received a 12-page newsletter from them outlining their project. If you want to receive their newsletter send them $2.50 (we suggest an international money order or maybe $3 cash) at the following address. Since their newsletter is much too long to reproduce here we are reprinting portions of our reply, to give you an idea what is going on:
Mad Hackers
6 Hillcrest Ave.
Faulconbridge 2776
Australia
1) 'Eloi' is misspelled on page 1.
2) The reproduction quality of your newsletter does not meet minimum standards. Even Jeff H., who is sometimes a bit sloppy about reproduction at the margins of his rag, would reject your page 5 out of hand. Suggestion: review the masters before mass printing and redo them when necessary.
3) I love to see lots of folks cooperate in an endeavor which is (perhaps) intended to result in a commercial product. In the rare event that this endeavor is successful, I will also admire the view as ONE of you folks grabs ownership of the successful endeavor and leaves the others out in the cold. Or haven't you heard the story about how all the PC magazine staffers left en masse to form PC World?
Hint: possession is nine points of the law, even down under. In whose garage is all this material being gathered? If you know the answer to that question, you know who will have ownership.
4) Obviously the Mad Hacker has not yet learned of the extreme performance degradation associated with bit-mapped alphanumerics, nor has he learned that the problem is N times worse once N bit-planes are added for color. Also, the performance degradation is worse for higher pixel resolutions. Have any of you had the misfortune to see the Corvus Concept crawl, slowly? It has 720 X 560 pixels, monochrome. When our project
Page 6, Column 2
engineer first saw the Tandy 2000 print alpha on the color monitor he actually laughed out loud! And I have removed the color adapter from my Tandy 2000 because the 2000 is INCREDIBLY slow as long as that board is plugged in!
The answer, for performance-oriented budget systems, is to have an entirely separate text circuit - using a 6845 or 9007 - and a separate monitor. My personal solution is to consider this text output the primary/default system output device and to have graphics optional, using a separate graphics monitor. That way several graphics options can be supported at differing price and performance levels.
(One STILL has to make the choice of very cheap but poor-quality text based on standard 525-line monitors or using the higher quality available by designing for the nonstandard and higher-priced IBM PC monitors or the Tandy 2000 monochrome monitor. The Tandy text is better than the IBM PC's, believe it or not! It is also incompatible with anything but itself.)
Unfortunately few hackers are yet aware of the performance trap inherent in mapping text into a bit-map and so will demand bit-maps, like a little kid demanding that fourth chocolate ice-cream cone. Both ways you've got a disaster on your hands.
Question: are the Mad Hackers up to providing what folks need instead of what (some) folks WANT?
(Yes, text and graphics CAN be intermixed. Cheaply and slowly or swiftly and expensively. There is no way - yet - to intermix text and graphics cheaply and swiftly.)
5) I admire the free-spirited person who would build an audio tape interface and a hard disk interface into the same computer.
6) I note in paragraph 2, page 1 that you are planning to copyright your code to prevent other folks from taking commercial advantage. The Mad Hacker machine is evidently intended to be commercially successful. Has anyone noticed that Digital Acoustic's code is copyrighted to prevent others from taking commercial advantage????
7) If you expect a significant percentage of your newsletters to go to us idiots in the States I strongly suggest that you publish on 11 inch paper. It is a hell of a lot easier to file paper that is a bit too short than paper that is a bit too long, yes?
8) It is increasingly evident that spelling checkers are not commonly available for the Mackintosh. 'Propriatory' (sic)? I should hope it is undisclosed!
Page 7, Column 1
9) Using an 8MHz 68000 is a poor choice for a computer which is going to weigh in at $4K - $6K total price. 10MHz 68000s will work with 150nsec DRAM with no wait states, especially if you toss out LS257s in favor of F257s. Don't forget series resistors to damp the F257 undershoot.
10) Have you looked at the Keytronic and Qubie 5151 IBM PC replacement keyboards? Both have the same layout but the Keytronic has audible feedback like the PC and Qubie has tactile feedback - it's nice to have a choice!
11) Who gets to lay out the circuit boards for all the stuff you guys are gonna build? Has anybody figured out the hours involved? The expense involved?
You 'Mad Hackers' have a long haul in front of you, but persons who misspell 'Eloi' deserve whatever they get! Good luck? (signed) FNE
P.S. I have printed the back pages of my newsletter on RED paper (hard to copy) and on YELLOW paper (frankly symbolic of yellow journalism) but NEVER on PINK paper. Is the Mad Hacker machine going to come with lace trim? Is somebody confusing the computer language LISP with a limp-wristed lisp? In Australia? Wait until the Newport Yacht Club hears about this!
DTACK DISK REPORT
(The following report was mostly prepared by James S. and mostly edited by FNE.)
The Mitsubishi M4854 5.25 inch 1.6 Mbyte (unformatted) floppy disk drive has an interface identical to 2-sided 8 inch disk drives. It rotates at 360 RPM and supports a 500 Kbits/second data transfer rate (double density). These drives are in production and are readily available. Mitsubishi specifies that the M4854 does not require write precompensation. The track-to-track stepping time is 3 milliseconds, the settling time is 15 milliseconds and the head load time is 50 milliseconds. The specification states that the drive has 77 cylinders, but application note MFD-081 states that the unit can use 80 cylinders like the IBM PC/AT.
The Mitsubishi drives dissipate 4 watts with the motor off, 8.5 watts when continuously seeking (stepping) and 5 watts with the motor on but no stepping (standby). Unlike earlier 5.25 inch disk drives, the M4854 is very densely packaged and there is essentially no air path through the drive itself for convection cooling. We have already proved that if two of the drives are used in the horizontal position and stacked one on top of the other that excessive overheating will occur and data errors DEFINITELY will be encountered. In fact,
Page 7, Column 2
we discovered that the diskette media was actually quite warm to the touch under this condition. One member of the DA engineering staff believes that this mounting configuration will prove unreliable even if a fan is used (if the air basically has nowhere to go, a fan does not help).
One solution is to mount the drives vertically with some separation between drives so that air can flow past both the top and bottom of the drives. If horizontal mounting is used we believe that special provision has to be made for an adequate flow of cooling air. In particular, the two drives must not be mounted 'top to bottom' whether vertical or horizontal, whether a fan is used or not. You may translate 'special provision' to 'extraordinary provision' if you wish, since this apparently has not been a problem with earlier floppy disk drives. (Pull the drive mechanism out of a DISK II case and you will see why: there are LARGE air cavities throughout the drive mechanism, providing ready air flow in whatever direction.)
We have already discovered that horizontal mounting is preferable to vertical, since it is easier to 'crumple' the center of the diskette when the drive is mounted in the vertical position. We have purchased three brands of the special high-coercivity diskettes needed by these new-generation drives, and NONE of them are equipped with center reinforcement rings.
There are lots of different manufacturers making different floppy disk controllers and lots of manufacturers claiming they are making the newest 'do everything' controller. What we need is a chip that is for real NOW but which also has the most functionality (do everything). The Western Digital WD279X-02 FDC and the Standard Microsystems Corporation FDC 765A stand out from the rest.
The Western Digital WD279X-02 is very similar to the WD179X series. The biggest difference is that the WD279X-02 has the write precompensation and data separator on the chip. This is great IF it works reliably. If it doesn't work Digital Acoustics can't fix it or even 'tweak' it. We've been using the chip and it seems to work. We have not tried the FDC 765A.
The WD chip requires an external latch for the drive select lines but appears to be unlimited in the number of drives it can support. However, the interface itself only has four drive select lines. The current track and sector number can be read/written from/to the chip so that the CPU will be able to correctly set up the chip when switching to another drive, Since the M4854 is two-sided, we use the WD2797-02.
The Standard Microsystems FDC 76SA appears to more versatile but we haven't tried it yet. The stepping
Page 8, Column 1
pulse duration is programmable from 1 to 16 milliseconds in 1 millisecond increments. The head load timing is also more versatile. The chip supports up to four drives without the burden of the CPU keeping track of which track any of the four drives is on. However, it has to have an external phase lock loop data separator and write precompensation circuit.
Recently Standard Microsystems Corporation has announced its new SMC 9266. This is a FDC 765A with a write precompensation circuit, digital phase lock loop data separator, head load timer, and crystal oscillator on the chip. However, since it is new there can be availability problems and bugs. (Some folks are not fond of digital phase lock loop data separators, though.)
The relative ease of bringing up a system with the WD2797-02 rather than the FDC 765A tilts the scales in favor of the Western Digital chip. We are testing compatibility between disk drives now. We are also comparing media from different manufacturers (Dysan, Maxell, Memorex).
We will pass along more info as it becomes available.
INTRODUCING QD DOS
where 'QD' stands for 'Quick and Dirty': we need a DOS which can work with the hardware our existing Apple II customers already own, which is as close to free as possible, and which is file compatible with our forthcoming non-name 'realDOS'. 'RealDOS' will, of course, work with 1.28 megabyte (formatted) floppy disks at 40.4K bytes/second average throughput.
The idea is, if our customers develop useful programs and datafiles using 'QD DOS' and later need a larger and/or faster disk, the files will be completely compatible and transferable with trivial ease. The phrase 'as close to free as possible' means we will charge our costs, as a taxed business with paid employees, to make and ship the documentation and disk(s) for 'QD DOS'. And what our existing Apple II customers 'already own' is, of course, a pair of DISK IIs and DOS 3.3.
Since 'QD DOS' will use DISK IIs and DOS 3.3, it will be slow like DOS 3.3. In fact EVEN SLOWER, because 'QD DOS' will be piggybacked on top of DOS 3.3. But clever folks will figure out how to adapt 'QD DOS' to Diversi-DOS or David-DOS and that will help a lot because all 'QD DOS' files, whatever their type, are saved on the DISK IIs as binary files - and those disk enhancement packages work well with binary files.
QD DOS's storage capacity can be easily extended with any higher-capacity disk which supports DOS 3.3.
Page 8, Column 2
A SWELL TIME-KILLER!
Designing ones' own DOS is lots of fun - it beats the hell out of working crossword puzzles for killing time! For us, the best place to start is to define a disk's storage in terms of absolute sector numbers and then to write subroutines which permit reading and writing a given (absolute) sector on a specified disk.
Then we do a little stepwise refinement: we begin by assuming that we have a disk catalog, and that we are going to save a data file onto disk. O.K., persons, HERE WE GO!
SAVING A FILE TO DISK:
When saving a file to disk, we are faced with several scenarios - that is, ways of deciding, and identifying, WHERE to save the file on the disk. We may have a new file which is not on the catalog and therefore does not currently occupy sectors on the disk. If the file is already on the disk, it may be larger, smaller, or the same size as the datafile to be saved. We need an algorithm to serve all of these eventualities.
We need to first define the information which is available - and required - in the disk catalog! We can then write a pseudocode algorithm to perform the FILE SAVE function. For convenience, we will assume that we are saving a DATA file.
The disk directory itself is a specialized and dedicated datafile. We will assume that utility subroutines are available to load and save this file. Here is a description of the minimum information needed for a workable disk catalog:
CATALOG DESCRIPTOR:
The next available sector #
The maximum legal sector number (size of disk)
The number of files currently in the catalog
The maximum legal file number (size of catalog)
The size of each file descriptor [IMPLICIT]
The address (in the catalog) of the first file
descriptor [IMPLICIT]Each file descriptor needs the following minimum information:
FILE DESCRIPTOR:
A file type identifier byte
A file attributes byte
A filename
The first disk sector # of the file
The number of sectors in the filePage 9, Column 1
(It can be argued that the file type identifier byte and the attributes byte are not strictly necessary but we would have a very poor disk catalog without them.) To this, we will add a one-byte filename checksum for the hell of it - we hate to do EVERYTHING just like everybody else! Some definitions:
Let NXSA = the next available sector # on disk
Let TSA = the maximum legal sector number
Let FSF = the first disk sector of the file
Let NSF = the number of sectors in the file
Let OLD = the number of sectors which were already
assigned to the file.
Let NEW = the number of additional disk sectors
required to save the file.
Let CNT = the total sector count (OLD + NEW).
Let #N = the selected disk drive
Let FNB = a file name scratch buffer
Let TSEC = a temporary sector number register.
Let SECNUM = the sector number where the disk buffer
is to be saved.
Notes: NXSA, TSA, FSF, NSF are all parameters in
the disk catalog. FSF and NSF are found in
a particular file descriptor.
OLD can be zero if we have a new file; NEW
can be zero if we have an old file. CNT
must be greater than zero.
'Fill the buffer' means fill with 1020
bytes of data and data identifiers, or fill
with remaining data if fewer than 1020.
The first 4 bytes of a 1024 byte sector are
the pointer to the next sector of the file.HERE IS A PSEUDO-CODE ALGORITHM TO PERFORM DATASAVE:
Store the filename in temporary buffer FNB
Identify and store #N, the disk drive #
Save the pointer to the argument list (A6)
(This is the HALGOL program pointer)
Calculate the number of bytes in the data file
Then calculate the number of 1020 byte sectors
(CNT) needed to hold that number of bytes
Restore argument list pointer A6
Read disk #N catalog into the catalog buffer
Search the disk catalog for the given file type,
filename checksum, and filename.
GOTO OLDF if data file found
Check whether the disk catalog file descriptor
table is full (error if so)Page 9, Column 2
Increment the number of files in the catalog
Store the file type and attribute bytes
Store the filename checksum and the filename
Set OLD = 0, NSF = 0, FSF = NXSA, NEW = CNT
Increment NXSA (the next available sector #)
GOTO NEWF
OLDF Set OLD = NSF and set NSF = zero
Calculate NEW = CNT - OLD
IF NEW is negative, set NEW = 0
NEWF Error if TSA < (NXSA + NEW)
Set SECNUM = FSFNOW PERFORM THIS LOOP UNTIL THE FILE IS SAVED:
LOOP Clear the first 4 bytes of the buffer
(the next-sector ptr)
Fill the buffer
Decrement CNT
If CNT = zero, GOTO SAVEX
If OLD = zero, GOTO NEWSEC
OLDSEC Decrement OLD
Read disk sector SECNUM (4 bytes ONLY) to TSEC
(do not modify 1020 byte buffer data)
If TSEC <> zero, GOTO NEWSC1
NEWSEC Move NXSA (next avail sector #) to TSEC
Increment NXSA
NEWSC1 Move TSEC to 4-byte next-sector buffer ptr
Save the buffer to disk #N on sector SECNUM
Increment NSF (# of sectors in the file).
Move TSEC to SECNUM
GOTO LOOP
SAVEX Save the buffer to disk #N on sector SECNUM
Increment NSF (# of sectors in the file).
Save the disk catalog back to disk #N.
DATASAVE IS COMPLETED!(Note that although some parameters of the disk catalog are changed before all of the error conditions have been tested, none of these parameter changes count UNLESS THE DISK CATALOG IS SAVED BACK TO DISK! And in case of an error, the disk catalog will NOT be saved back to disk.)
The above is the outline of a suggested method of saving a file whether or not that file already exists. Note that an outline which is sufficiently complete to be useful (implementable) pretty much defines the disk catalog. It should not be a surprise that disk catalog descriptor tables and file descriptor tables are all pretty much alike, with differences in such trivial stuff as the number of characters in a filename, filename extensions ala CP/M, time & date stamps etc.
Page 10, Column 1
ARE YOU TRULY AMBITIOUS ?
If you are truly ambitious, try writing your own DOS. Remember, it beats the hell out of working crossword puzzles for killing time!
Now, about compatibility between this 'QD DOS', whose development is well under way, and out forthcoming 'realDOS': we are primarily seeking FILE compatibility, not catalog compatibility. Therefore, we keep the four-byte pointer to the next sector, even though 2 bytes is enough because those four bytes are fundamental to the file structure as saved to disk. But we design our disk catalog to work with DOS 3.3:
'QD DOS' CATALOG FORMAT:
A catalog will be recorded on each disk, in increments (sectors) of 1K byte. The catalog will be initialized as a dedicated DOS 3.3 binary file and will NOT be recorded in 1024-byte sectors with the first four bytes reserved for the pointer to the next sector. This means that 'QD DOS' catalogs are essentially limited to a size that can be conveniently loaded into an Apple II in one piece, or about 12K bytes maximum. 'QD DOS' catalogs for standard DISK II diskettes will be 2K byte binary files, named "ZZCATAAA" in DOS 3.3.
CATALOG DESCRIPTOR TABLE:
Address datum bytes
$0000 Maximum legal sector number: 2
$0002 Next available sector: 2
$0004 Maximum legal file number: 2
$0006 Number of files in catalog: 2
$0008 Undefined bytes: 56
$0040 File descriptor table startThe addresses listed above are the addresses relative to the disk catalog buffer location.
FILE DESCRIPTOR:
$0000 File type: 1
$0001 File attributes: 1
$0002 Filename checksum: 1
$0003 Filename: 14
$0011 (undefined bytes) 3
$0014 First sector # of file: 2
$0016 Number of sectors in file: 2
$0018 (undefined bytes) 8
--
32
File type: 0 = compiled HALGOL program
1 = HALGOL program text image (TSAVE)
2 = DatafilePage 10, Column 2
File attribute byte:
D0 = Hidden catalog entry ? (1 = yes)
D1 = Read only (locked) ? (1 = yes)
D2 = Scratched ? (1 = yes)
D3 - D7 undefinedThe address listed above is the address relative to the beginning of the particular file descriptor. We aren't going to try to justify that filename checksum; it's just there (to be different?).
If we have a DISK II-based QD DOS diskette, it will have a 2048-byte catalog and 120 1K-byte data sectors (assuming the disk is full). The 120 1K-byte sectors will be recorded on 15 each 8-K binary DOS 3.3 files. The names of these 158K binary files will be:
#1 "ZZZAAAAA"
#2 "ZZZAAAAB"
: :
#15 "ZZZAAAA0"QD DOS will have to map absolute sector numbers 0 - 119 into one of those named files, and into a particular 1K section of the 8K file.
Assuming a DISK II-based QD DOS diskette, the maximum number of sectors -1 (the highest legal sector number) is 119 decimal. The highest legal file number is 61 decimal. So the first 8 bytes of the catalog of an otherwise blank QD DOS diskette would be:
$00 77 00 00 00 3D 00 00meaning 119 is the highest legal sector number, zero is the next available sector number, 61 is the highest legal file number, and there are zero files in the catalog. (The first sector and/or file number is zero.) The file descriptor table is irrelevant, since no files are opened.
(An 'otherwise blank' DISK II-based QD DOS diskette is one which has the 2K catalog binary file and the 15 each 8K data binary files already recorded on the disk in DOS 3.3 format but which contains no QD DOS files.)
OTHER DISK DRIVES:
Modifying the above format to work with other DOS 3.3-based disk drives is simplicity itself. Suppose you have one of those 450K+ RANA drives, and you want to assign 400 1K data sectors while keeping 62 (#0 to #61) maximum files in the catalog. No sweat! The catalog remains 2K bytes and retains the name "ZZCATAAA", the first 8 bytes of the catalog become:
$01 8F 00 00 00 3D 00 00Page 11, Column 1
And we have to save 50 each 8K data files named:
#1 "ZZZAAAAA"
#26 "ZZZAAAAZ"
#27 "ZZZAAABA"
#50 "ZZZAAABX"(You should be able to fill in the other file names.)
From the above, you should be able to figure out for yourself how to set aside a given portion of, say, a SIDER hard disk to work with QD DOS. All you have to change is the number of 8K binary data files and the first two bytes of an initialized catalog file unless you want to change the catalog size, in which case you will have to recalculate the fifth and sixth bytes of the catalog file (the maximum legal file number) to agree with the new size of the catalog and also make a minor modification to HALGOL IN ASSEMBLY LANGUAGE to load and save the re-sized catalog file.
A less technical and less detailed explanation follows:
MORE QD DOS INFO:
We are talking about a DOS which will be file-compatible with the HALGOL DOS we are writing for the high-density Mitsubishi floppies. If all of our DTACK customers were limited to DISK IIs, it would make sense to implement BLUE SKY ONE. However, several correspondents - present and potential DTACK customers - have made the point that BLUE SKY ONE would exclude the use of higher density disks such as the RANA floppies and some Apple II-compatible hard disks such as the SIDER. By trading off the maximum (hardware-limited) speed for greater DOS 3.3 compatibility, we can indeed accommodate a variety of disks.
What we do is create, under DOS 3.3 control, a number of 8K binary files. These files are given a 'fake name' beginning with "ZZZAAAAA". The next name is "ZZZAAAAB", the 27th name is "ZZZAAABA", etc. This permits 26 to the 5th power 8K files, or 95,051 megabytes per disk maximum. It is unlikely that these fake names will conflict with any real file names that you may be using. By beginning the names with "ZZZ" these files, which are 68000 HALGOL files rather than real 6502 DOS 3.3 files, will appear at the end of any alphabetized Apple II disk catalog listing.
The disk catalog is named "ZZCATAAA" and can usefully be as small as 1K, and as large as 12K. The nominal size is 2K. Since a 12K catalog file can handle 382 separate files, this should be more than adequate for any QD DOS application. Remember, QD DOS is intended as a temporary, inexpensive expedient until a real 68000 DOS, with real 68000-based disk drives, is available.
Page 11, Column 2
Our perception is that ProDOS is becoming the Apple version of Digital Research's CP/M v3.0 - almost everybody acknowledges the superiority of v3.0 but almost nobody uses it (including us) because all of our CP/M programs run under v2.X, and v3.0 is NOT compatible with v2.X. Similarly, we observe that almost everybody acknowledges the superiority of ProDOS but almost nobody uses it (including us) because all of our Apple II+ programs run under DOS 3.3, and ProDOS is NOT compatible with DOS 3.3. In addition, ProDOS absolutely REQUIRES the presence of a 'language card' in an Apple II+ as well as the $60 fee for ProDOS itself. That's a quick $120-$180 right there.
In contrast, QD DOS will work with a standard 48K Apple II+ and DOS 3.3 - total extra cost, $0.00. If you want to run at ProDOS speeds, Diversi-DOS will do the job for just $29.95. (All HALGOL files, regardless of their type, will appear as binary files to DOS 3.3, when running 'QD DOS'.)
By now it should be obvious that each of those 8K binary DOS 3.3 files with fake names are going to 'stand in' for a particular track of 8 each 1K sectors in the 'real' HALGOL DOS using the high-density floppies under direct 68000 control. Instead of reading an 8K track at a time, we will read an 8K DOS 3.3 file at a time. The 8K buffer is the Apple II itself, easing the memory demands on 92K static DTACK boards.
Although the DOS 3.3 (pseudo) files are 8K each, the 'granularity' of the 'QD DOS' will be based on 1K pseudo-sectors to match the 1K sector granularity of the real HALGOL DOS.
The 'fake names' will be transparent to the HALGOL programmer/operator, who will only see the names in the HALGOL catalog file.
In fact, (much!) slower execution will be the only really obvious difference between 'real DOS' and 'QD DOS' besides differences in storage capacity. Transferring files between QD DOS and realDOS will be trivially simple because the file images on disk will be identical, sector for sector and byte for byte. We think that justifies calling QD DOS 'compatible' with realDOS!
HOW MANY DOSs ?
And since we are actually well under way writing these two DOSs, that means we bid a fond adieu - permanently - to BLUE SKY ONE and also that we forget ProDOS. A guy can write just so many disk operating systems... YOU have more ambition? PROVE it!
Page 12, Column 1
WE GET MAIL:
"I just received issue #38. I retrieved the envelope from the round file and found a '38' inscribed by my name. Woe, sorrow and bye bye $15. The absence of a mailing label caused semantic pain for a few moments. Could I interest you in a '78 vintage SWTP 40 column printer that will save someone in your organization writer's cramp?
"Re: BRITISH WATCH: I noticed the ad for a "SIDER" in an issue of Call Apple that arrived around the first of December. Another ad on the facing page featured the 'Mega-vault' which was clearly identified as the Xebec 9710. It was priced at $1095 or $400 more than the 'SIDER'. While I was mulling over these items the mailperson delivered a Xebec brochure in response to a bingo card from Computer Design. And there they were: the Xebec 9710 and right next to it, the 9710H. The specs on the 9710H fit the 'SIDER' and the art work looked the same except for a name-plate.
"I ordered by phone using plastic. I received confirmation of the order by mail within three days and the unit was delivered by UPS 5 days later. The confirmation was mailed from Bethlehem, PA but the unit was shipped from Carson City, NE. I dug out the Xebec brochure and noted that the Xebec Customer Support Center lists 3579 Highway 50 E., Carson City NE for a return address. First Class Peripherals (vendor of the 'SIDER') use the same street address. End of mystery. Some of the installation programs still bear the Xebec copyright notice.
"Best regards to you and Luigi." Robert C., Houston TX
We printed 757 labels using an MX-100 - 499 from one Applepost mail list disk, 258 from another - and exactly 40 labels by hand. Death March Dunkerson's hand, to be specific. You got one of the 40.
We sell 128K Grandes by mail for $695. Lots of retail outlets would like to sell them but they need about a third off for their discount. We can't make 128K Grandes for a third off $695 - if we could that's what we would sell them for right now. So how does Digital Acoustics sell 128K Grandes by retail as well as by mail? Simple!
We establish another outlet, perhaps in Pennsylvania, called 'Muy Bueno Peripherals, Inc'. MBPI sells a 128K 68000 attached processor called 'TOPPER' for $1095 - $400 more than a 128K Grande. Most of MBPI's sales are to retail outlets - for $695 each, giving the retail outlet the discount it needs. 'TOPPER's are shipped from McFadden St in Santa Ana, CA. This works great until some smartass (no names, now!) figures out QUE PASA? and writes a letter to BYTE and/or Call-Apple
Page 12, Column 2
blowing the whistle on the deal. Does that clarify the 'SIDER' deal a bit? By the way, Pete S. has been waiting for his SIDER for two months now. They cashed his check immediately.
Robert, if you know a foolproof way of selling at good mailorder prices and yet providing retailers the high markup they need to stay in business, let us know. We will pass your regards to Luigi, who is still spending a lot of time looking at the south end of a northbound, er, donkey - FNE
"...Although HALGOL is NEARLY as fast as assembly, does it make any provision for a machine language interface? Paul S., Aurora CO
Paul, we know we asserted a long, long while back that HALGOL had about a 15% HLL overhead, but at that time HALGOL was almost exclusively a floating-point number-crunching language. HALGOL has CONSIDERABLY more overhead when performing integer or (especially!) string functions. Actually, HALGOL's HLL overhead is about the same as a 68000-based compiled BASIC with an EFFICIENT floating point and transcendental pack - FNE
"...I agree with your opinions about 80-90% of the time. However, I'm in sharp disagreement with you on one point: THE MACKINTOSH!
"Now, before you say, 'aw, not one of those drones again!' hear (read?) me out. I've been building and working with microcomputers since 1976 (I even built a COSMAC ELF - still have it, too!). I've designed and built several microcomputers, including two 6809-based machines: one based on the dinosaur bus (SS-50) and another was a single-board design that fit on a 5 1/4" disk drive.
My favorite machine is the Mack. Yes, I hate the fact that it doesn't offer any bus expansion, but that's my only complaint. I have an EXCELLENT, fast macro-assembler/editor called MackASM (written in assembly, of course) that I bought for $80. It comes with a full debugger also. You mentioned in the last newsletter that the Mack forces you to use the cutesy OS. Not true! When you run a GOOD Mack program, the finder is discarded and the program uses the TOOLBOX routines to do all of its I/O. You could write your HALGOL OS on a Mack if you wanted to. Really! I haven't been hampered by the Mack at all; in fact, I find that I have more programming freedom than on any other machine I've used. The main drawback? Well... you DO have to pay Apple $150 to get the 1000 page 'Inside the Mackintosh' book that describes the inner workings of all the routines. So, lay off the Mack, eh?" Frank H., Los Angeles CA
Page 13, Column 1
Frank, it has become evident that SOME progress has been made toward solving what is in my opinion, and in the opinion of MANY others, Mackintosh's biggest problem: its (former) lack of an assembler and its too-damn-complex operating system. If we are in disagreement, it is over just exactly how much progress has in fact been made.
$150 doesn't worry us, not with six decimal places in the bank and all of our bills paid up (we have been taking the 2% net 10 discount, when available, for over two years now). What worries us is that damn 1000-page manual, which we suspect we would be expected to STUDY, several times through. You are correct, with enough time we COULD bring up HALGOL on the Mack. Who pays our bills while we take the time to do this? Who compensates us for that irreplaceable time lost in planning our next generation of hardware products? Do not forget for an instant that it is hardware that pays Digital Acoustic's bills - and FNE's salary.
We trust you have read p.88 of Dec Dr Dobbs, on which page it is asserted that "Apple has outsmarted itself by making program development on the Mackintosh hideously difficult" and, "MackBASIC can't even run the BYTE Sieve of Erastothenes benchmark [with 128K] because the Mack runs out of memory". Have you noticed that Apple management will happily sell unlimited numbers of Macks to students for 60% off the advertised list price? And that NOBODY thinks Apple loses money on the deal? Have you read pp124-5 of Jan Dr Dobbs? Especially with regard to the hazards and overhead of 'heap management'? HALGOL has no heap management, Frank - FNE
"May I suggest that you update your "Brochure/Information Packet" to reflect the fact that you are now in your FOURTH period of paid subscriptions?
"I have attempted to correspond with PHASE ZERO, Ltd without success. The back issues of your newsletter explain why. There is no telephone listing for PHASE ZERO. I wish I knew how to buy an unadvertised product from a company which will not answer any written requests for information, and which has no telephone.
"Hayden no longer sells their Double Precision Applesoft software package.
"I have just gone through issues 1 through 28 of your newsletter, and am still reeling from the experience." Robert F., Woodinville WA
Information Packets are among the things we don't have time for these days - we just ran out and won't reprint them, probably for several months. Most people find
Page 13, Column 2
out about us through this newsletter these days, which makes the info package slightly redundant. We have no desire to fill the catalog files of the bozos who want 'all the information you have available - preferably on six-color hard-stock brochures'.
Since you have ordered another 10 issues, you will read more about PHASE ZERO including nasty things we wrote about Dan Davidson (currently 'Mr. PHASE ZERO'). The next issue included a reply from Dan which included his phone number. However, Robert, the transgression we picked on Dan about was - and is - his failure to reasonably support early customers of his assembler with more recent updates. We have never heard of anybody who sent $95 to PHASE ZERO who did not receive a 68000 cross-assembler in return, usually very promptly. And if you will read the preceding paragraph, you will notice WE are not especially fond of information requests ourselves.
Damme if we can figure out what to do about a copyrighted program whose ownership (Hayden's) appears to be clear but which is no longer offered for sale. Anybody out there have any useful ideas? Oh, yes: please direct questions about Number Nine hardware to Number Nine!
We cannot understand how reading this quite moderate and modest rag would cause you any discomforture - FNE
"I recently got one of your boards (512K) and have been wondering if I got defective software. Specifically, the fragment SETUP hangs the computer if I run it. The next time you feel inspired to write about comic book characters, please restrain yourself and write about your demo software instead.
"I have been using Ulrich Schmidt's PASCAL interpreter for the last few weeks and can not begin to say what a pleasure it is to work without the constant grinding of the disk drives. Not to mention the astonishing speedup. I am going to write away today for the Modula 2 update." Patrick K., New York NY
Patrick, do you by any chance have an old Apple II? Not an Apple II+, an old Apple II? That model is famous for 'hanging' on SETUP. The problem has something to do with what language is loaded into RAM - we, uh, think. Most folks with old IIs have that problem for about 24 hours and then go "OH, YES!" and we never hear from them again. Since we don't own an old II we never did quite get it straight what the problem was - FNE
(Ah, Patrick, you DO have a 'language card' installed, don't you? SETUP won't work, even on a II+, without a 'language card'.)
Page 14, Column 1
"At first I was P.O.'d, MIGHTILY! But then my laid back, good-natured self rose to the occasion, as usual. I even forgot about the Sozheznitsyn quote I like so much about someone being like [this passage heavily censored].
"'apparently surrendered unconditionally' my right eye! If you had simply thought to mention that my 'surrender' was accompanied by a 30 page fanatical defense of Modula-2 [true] as well as a six page well reasoned explanation (including charts and statistics) of why the programming language used in the vast majority of software products is a small beer in a large brewery the reader hisself [sexist] could have made up his own mind as to my 'surrender'." John B., Burlingame CA
When a letter jumped off the front desk and started chewing on our ankle we said to ourselves, 'Hark! A missive from Kindly Burlingame John!' Naturally, we phoned John for clarification. The following is our synopsis of that phone call:
We and John are agreed that most commercial programming is done by data processing departments with system analysts, coders... lots of warm bodies. Since a certain percentage of these warm bodies can be counted on to come and go in a year's time, a programming language is needed to minimize the effect of such personnel turnover. PASCAL used to be such a language, Modula-2 (and ADA) are such languages today. And COBOL is always with us, too.
We and John are agreed that the 80%-20% theory is great, and that the theory SHOULD be put to use. We are also agreed that the theory, for whatever reason, in practice is NOT put into use. (We are not in total agreement WHY.)
We are even agreed that BASIC, or an improved BASIC-like language, is best suited for programming medium-length programs by persons who are not professional computer types! (John's immediate reaction was that anyone with any ambition or self-respect would learn to program correctly in Modula-2.) We pointed out that a person who wanted to build the world's greatest widget did indeed have lots of ambition but that the ambition was directed toward the construction of wonderful widgets, NOT learning wonderful but complex programming languages and concepts. We personally add, thank heavens for dedicated, ambitious widget-makers! We surely need 'em!
Finally, as Bob P. once mentioned, P.O. could stand for Post Office but in this case it does not. John did not use the initials in his missive. John, we are going to bill you for the out-patient treatment we needed for our wounded ankle - FNE
Page 14, Column 2
"I can take a hint, especially when delivered with such subtle understatement - (here's your $15).
"About your 'legendary 2-1 C compiler': I don't know much about 2-1, but the compiler that comes with the Digital Research CP/M-68K package seems to be about 1.25-1. I've seen a great many modules come out of that compiler and the efficiency level of code generation and optimization is excellent. Still, the executable programs you get are humongous. The reason is that the library routines are linked into the final load module, and they include everything under the sun, since, unlike a sensible operating system, all the I/O relocation, buffer allocation, etc. is there. I have had a 300 byte object code module expand into 30K.
"I am a computer professional, as well as a computer hobbyist. I work in a rather large data center as a software specialist in the MVS/XA environment. I couldn't agree with you more with your statement about virtual memory on a personal micro; I have some reservations about virtual memory on a mainframe. But I think that the greater degree of concurrency possible, the better." Daniel L., Carmichael CA
Daniel, the comments we have made about concurrency and other complexities in personal computers were directed to the Daniel L. who is a computer hobbyist and who buys his own computer for his own use at home, NOT to the Daniel L. who is a full-time computer professional and who works in a large data center using complex, expensive computers purchased by his employer.
Uh, we hope you don't mind if we decline to comment on the 1.25-1 overhead C compiler of DRI's? - FNE
"...I've had pretty good results using your partial release [pre-v0.3] of HALGOL as a tool for developing real-time simulation subroutines for translation into either Gould Systems Fortran-77+ or Systems Assembly Language for the 32/7780. At present the DTACK with HALGOL is capable of running about four times the execution time per pass through the subroutine as the 32/7780 running FORTRAN-77+. This is pretty good when this version of FORTRAN is looked upon as a real-time package with a relatively low overhead and our 32-7780 is capable of hardware floating point on both processors and both have had the Systems High Speed Floating Point Accelerator Package (hardware) added to them. At the time I ran the Time and Accuracy test, our Internal Processing Unit was on line and the only other task running was the operating system itself. This means the number crunching (for all 2500 loops ran) was performed without exiting for operating system overhead. In my book when I can spend less than $1000 and raise the apparent speed of my personal computer to one fourth that of a system costing over $100,000, I am highly pleased." William McP., Headland AL
Page 15, Column 1
We are pleased that you are pleased, William. Now we have to convince our other readers that we didn't write your letter. If we HAD written your letter, we would've pointed out that HALGOL is interactive while FORTRAN 77+ is compiled, with all the source/compile/edit/recompile/link/load fun-and-games that are inherent in compiled languages.
You are on the right track - HALGOL is about being fast, NOT about having the most sophisticated features and the most structured contructs ever sighted in microcomputer history. There are a few of these latter around, but they seem to run slowly for some reason...
Hope you like v.03, which you should have received by now. Wait until you hear about George, which will be a prominent and, we hope, popular feature of HALGOL release v.04. We'll tell you more about George in the next issue of this rag - FNE
"...P.S.: Unlike Paul G., I am NOT interested in seeing some portion of my letter taken out of context and myself ridiculed and abused in your publication." Leif J., Pontiac MI
O.K., Leif - FNE
"My, the first paragraph of issue #38 certainly put the fear of God into my life. Why I'd rather sell my mother to the white slave traders than miss a single fun filled issue of your rag. (Of course she and I have had our differences recently).
"In addition, I could hardly refuse to re-subscribe in light of the simply nifty 'humble personal apology' you printed with MY NAME AMD EVERYTHING in issue #33. You even kinda mentioned it again in issue #35. So you will find enclosed a small token of my appreciation (in negotiable form; Mom said the envelope was too small for her suitcase and pillow)." David A., Somerville MA
David, we have begun to suspect that the first paragraph of the last issue could have been expressed more tactfully - FNE
"I really can't figure out those guys at Digital Research. I don't believe that they're selling enough copies of CP/M-80 ver 2.2 to keep the whole organization afloat. They just officially gave up on CP/M-Plus (CP/M-80 ver 3.0). They were so late with CP/M-86 that it is trampled by MS-DOS. I don't think that MP/M-II or MP/M-86 are 'setting the world on fire', and they show every intent to bury CP/M-68K by avoiding such marketing tools as (1) reasonable price, (2) advertising, (3) providing the level of user
Page 15, Column 2
support that they promise, much less the level of user support that the average user wants. I hope that DRI doesn't go belly up, because I think that would probably make Microsoft even more difficult to deal with than they are now." John T., Apple Valley MN
Officially? DRI is getting lots of bucks for its Intel UNIX V port and, one assumes, more for supporting the Atari Jackintosh with GEM (good luck collecting from KUJ, DRI!). One of the things that bothers us about CP/M-68K is its reported size - nearly 100K of code, exclusive of a (high level) language is not what appeals to us in a personal computer operating system. Why, you would almost think they had written it in inefficient, bloated 'C' instead of efficient, compact 68000 assembly code - FNE
"I am enclosing some sales lit for the latest product I'm working on. It is the 'APL MACHINE', a 9 mflop array processor connected to a dedicated I/O processor. The array processor is a 68000 controlling the bit slice pipeline and 4 megabytes of fast memory. It is running an APL interpreter/environment (written in C, assembler, and microcode) that is super-duper fast and getting faster. I should say the single user system is super fast, the multi-user system is (I shouldn't say this) 'not so fast'.
"The dedicated I/O processor is a 68000 with 80Meg to 2Gig of hard disk, streaming tape, etc... It is written largely in C with some assembler (we try to be sane). For software development on the I/O processor we use CP/M-68K, and boy - it is slooooow.
"(Analogic), with $150M in sales, is very smitten with the 68000. We do use 8080 based processors when it fits the product, but the majority of the computer products are 68000 based." Reed S., Wakefield MA
O.K., Reed, you got your plug in. Before our other readers run out and buy their very own single-user 68000-based interpretive array processor-based APL machine, please note that these babies run $80,000 to $100,000 for a typical system. See Oct '84 Electronic Products for a 4 1/2 page description of this system. Question: is that a single or double-precision array processor?
CP/M-68K slow? Zounds! We knew it was written in bloated 'C', but reader Daniel L. assures us that DRI's 68000 'C' compiler has only a 1.25-1 overhead. Since Dan would never lie to us, you must be wrong - CP/M-68K MUST be fast. Mustn't it? - FNE
"It's really dumb to use linked lists (using the first 4 bytes of each sector), what about random access?
Page 16, Column 1
Your system is fine for tape, but the big advantage of disks is that you have random access." John B., Staten Island NY
John, the issue you have raised is a legitimate one, and was also discussed by John T. of Apple Valley in a recent letter. Let us discuss this matter in simplified fashion for those readers who are not disk storage experts:
Random access means that any sector on the disk can be addressed directly. However, a particular disk file (program or data) generally is much larger than a single sector and hence is spread over multiple sectors. To read the file, the correct sectors must be read, and they must be read in the correct sequence. Question: with MANY sectors on a disk, how do we know which sectors to read and in which sequence?
That question has many correct answers, not just a single correct answer. Each correct answer has its advantages and disadvantages. We will concentrate on the DOS 3.3 answer and our linked list method:
DOS 3.3 assigns a 'side sector' to hold the sector list for a given file. Each file acquires at least one extra sector dedicated to this purpose. (Sector = DOS 3.3 T/S) This has the advantage of greater simplicity and also simplifies nearly 100% utilization of the disk - 'dead' (or 'garbage') sectors are easily reclaimed for use. It also has the great disadvantage that if you lose the one sector containing the sector list, your file is G - O - N - E, GONE! And the same process that enables picking up 'garbage' sectors also fragments the file all over the disk - something that is especially prevalent in DOS 3.3 and in standard UNIX. Furthermore, it takes a lot longer to read a file whose component sectors are randomly scattered over the disk. Score: 2 pluses, 3 minuses.
We have chosen to use a forward-linked-list method. The disk catalog needs only the first sector of the file and there is no 'side sector'. Each sector, as you have noted, contains a 4-byte link to the next sector on the disk (if the link is zero, there IS no next sector). Recovery in the event of a single disk error, as John T. noted, is greatly simplified. But the biggest advantage of this method is that it nearly forces the sectors to be allocated contiguously in ascending order.
When a sufficiently swift CPU is available, so that consecutive sectors can be read, the one sector that can be read most quickly after sector N is sector N+1 - and the linked list allocation method we use is designed to assure that sector N+1 is almost certainly the next sector which NEEDS to be read. So our method
Page 16, Column 2
permits easier 'disaster recovery' and is generally faster, with the mild disadvantage that some 'garbage sectors' do accumulate over time. (We recommend that a 'collect' utility be run once a month on developmental disks to minimize this problem. It only takes a minute.)
In conclusion, John, our 'linked list' sector allocation method is actually faster than alternate methods - which is why we chose it. By now, you should have caught on that we like things which run fast - FNE
"Please send me circuit diagrams of the 68000 system with dynamic RAM interface. I would like to build my own system similar to yours but not chained to a 6502 Apple. Thank you for your consideration." Peter Z., Ottowa Canada
Peter, we hate to tell you this since your note was so polite, but we figure we spent lots of money developing our product and we do not give that valuable product away. The schematic is, of course, the symbolic embodyment of that development work and would enable another technical person to duplicate our valuable product. Provided they could figure out what's in the two PALs, that is.
Lots of other companies, such as Hewlett-Packard and Wang Labs, share our attitude. Have you noticed that while the Apple II itself is an open system that almost all of the peripherals for the Apple II are closed? Like the Novation modem or the Gibson light pen, both of which are actually sealed, or potted? And that our product is a peripheral for (mostly) the Apple II?
Maybe HSC Inc, which also makes a DRAM-based 68000 attached processor (for Z80 systems), will give you the HSC schematic. See a recent Dr. Dobbs for HSC's address in New York. Oh, yes: good luck! - FNE
"I am the owner of (blush) a PCjr. Not only that, but I bought it in order to be able to use a word processor written in (gasp) PASCAL. Worse still, if I had to do it over again I would do the same thing!
"After suffering for many years with the total lack of an adequate word processor for my Apple II and the limited storage capacity of Apple disks, I broke down and switched reluctantly to IBM. I made the shift in order to be able to use the word processor PC-Write from Quicksoft. Besides the price being right ($10), this is an extremely fast and versatile piece of software. Bob Wallace shows that if you know what you are doing you can write a hell of a good editor in PASCAL supplemented by some assembly language coding.
Page 17, Column 1
"Unfortunately Groton MA, unlike Groton CT, is nowhere near the ocean, so I can't blame my lack of good sense on walking into nuclear submarines, which are even rarer here than they are in Santa Ana." Bruce G., Groton MA
Writing things like word processors and assemblers with the editors in HLLs and the rest in assembly makes a lot of sense, Bruce. We have done both in the past, using BASIC instead of PASCAL, and the results were quite good even though our Wang 2200 (ca 1971!) is about 5 times slower than a 5MHz 8088. Let's pretend we never wrote anything about you banging your head on a nuclear submarine in Groton MA, O.K.? - FNE
"Well, I'm hooked. A friend (?) lent me a stack of your rags, and I spent the better part of a week becoming addicted to your unbiased, unemotional reporting of the state of the microcomputer art." Steven G., New Haven CT
Unbiased? Unemotional? YOU must be the guy who banged his head too often on nuclear submarines, Steven - FNE
"Loved the A T & T review; when do they send the bully boys over to suggest you refrain from comment? I get the distinct impression that C might actually be reasonably effective (even efficient) on a system that has a machine code set up similar to that on which C was devised. That is, if you run C on a PDP 8 or 11, it may well be nice. I get the distinct impression that on a 6502 it is an utter disaster, and only marginally better on a Z80. 68000? I don't know enough about PDP-11 assembler to venture an opinion about the similarities and differences, but you certainly don't seem impressed.
"Mack crackers: the star type screwdrivers can be obtained in a decent general hardware store (cut some material from the front of the handle so they will reach the screws). Take a door hinge, mill the edges where the hinge opens to make something that will fit between the two halves of the Mack. Weld on a couple of metal bars for handles. Very nice, doesn't mar the finish nor leave screwdriver marks on the Mack, and it is a lot cheaper than the tools Apple sells to Mack dealers for opening the cases.
"One problem with your DTACK designs is that they are too conservative. Why don't you throw a few more 68000s onto your boards, so we can have enough power to run a keyboard without lockout while doing disk access, and another 68000 just to handle the disks, and maybe a few more to handle the color memory?" Eric L., Faulconbridge Australia
Page 17, Column 2
C is a high level language with the normal overhead of high level languages. Yesterday a guy came in to pick up a bunch of issue of this rag on account of he had a DIMENSION 80. He asserts that CP/M-68K, which is written in C, runs more slowly than CP/M-80 on a 4MHz Z80. DRI has a bunch of HLLs which are written in transportable C and they are real turkeys which can be benchmarked with a calendar. Folks keep claiming that we don't like C. WRONG! We just don't like ANY operating system or ANY HLL that is written in ANY HLL! (Writing an operating system in HALGOL would be equally disastrous.) We would be willing to change our mind if and when an HLL comes along which has only a 1.25-1 overhead.
Eric, this is the journal of SIMPLE 68000 systems. If we toss in all those extra 68000s, folks will start installing serial ports on our systems and start looking for sheep to chain-gang. Also, all those extra 68000s would cost money, believe it or not - FNE
"I asked for issues up to #39, I only got up to #38. Please send issue #39 and start my subscription with #40.
"Maybe you should check out <ACTION> for the Atari. It is perhaps the fastest, highest low-level language any computer has ever seen. The things it can do are incredible." Scott W., La Jolla CA
Sigh. Scott, $15 gets you #29-#38 (10 issues), NOT #29-#39 (11 issues). You would be amazed how many of your fellow subscribers have made the same mistake. So we are starting your renewal with #39, NOT #40. Also, we are not in the business of providing free technical pointers for folk who want to design their own hardware. Did we ever tell you that we are not an especially nice person? - FNE
"I am considering a subscription to DTACK, but right now I am looking for a divide routine in 68000 assembly (32 bit / 32 bit, signed). This is to be used in a four function calculator simulator to run on a Mack. You appear to be a excellent source on 68000 work - please let me know if I may acquire this through you, or a good 68000 source other than DTACKers where it may be acquired." Daniel D., Goleta CA
Gosh, Dan, we really ARE 'a excellent source on 68000 work' but this week we are not supporting Apple Computer's 68000-based products. Perhaps you should enquire elsewhere? The Mackintosh-related magazine MACKWORLD, for instance, is simply loaded with 68000-related code! We don't mind promoting another publication since we sense somehow that you ain't gonna subscribe to this one.
Page 18, Column 1
(To our other readers: we also have a heart-rending two-page letter from Portugal politely requesting assistance in designing a homebrew 68000 system to interface with an existing 6502 homebrew design. The writer obviously expects that we ARE going to provide such assistance! Peter R., where are you now? - FNE)
"What's the latest concerning the final revision and completion of the Production grade versions of your 'UBQ-1W 16081 math chip Peripheral circuit board'???? I may be interested, BUT only if all the revisions and modifications are complete and all changes are part of the circuit board ARTWORK (not jumper wires! - if you have jumper wires I'll wait awhile and design my own). If it is complete I may purchase one." Scott S., Manchester NH
Scott, we think you don't understand about the QD-1W, to give the device its correct name (Quick and Dirty #1 what Works). IF the QD-1W has jumpers what makes you think we would ever go back and modify the artwork? Good luck with YOUR design, and let us know when you get all the jumpers designed out and the final revisions and modifications in production. We may purchase one - FNE
"Not all hard disk controllers use Z80s. WD used an 8X300 CPU (I think Signetics makes it) on their WD1000 and 1001 boards, but all of the hard disk interface stuff was done with custom chips, not by the CPU itself. The CPU only handled host communications and managed the sector buffer. The more recent WD1002 board uses the WD1010 single chip hard disk controller. No separate CPU at all.
"XEBEC may use Z80s, but I still don't think the CPU being used is as important as you make it seem. These controller boards do all the dirty work with special hard disk controller chips. They don't work like the Apple, where the CPU does all the work. The CPUs on these boards are there to provide a high level command interface to the host and to manage the sector buffers.
"Take a look at the specs on the WD1002. It will deliver hard disk data to the host almost as fast as it comes off the drive, yet the host doesn't get tied up with dealing with the low level problems. You issue a read command, wait for the signal that it is done, and then block move the data out of the WD1002 buffer. The XEBEC controller can probably do the same thing, maybe easier with the SASI bus instead of the WD100X bus.
"On page 5 you write: 'We don't understand what Rod means by asserting that UNIX has great capacity, perhaps that is a reference to the big fast hard disk that UNIX just HAS to have to work (acceptably)?'
Page 18, Column 2
"There are times when I think you are not being totally objective about UNIX. We can all agree that it is not suited for single user/single task use, but I thought you realized it was good at what it was designed to do. If you want multiusers or multitasking, and you are either a computer professional or just a a good hacker, then UNIX can be a great system... It provides an ideal environment for professional programmers and hackers with large bank accounts.
"You may or may not be aware of a new newsletter called '68796 Hackers' Newsletter'. It is published by Victor Frank: 12450 Skyline Blvd: Woodside CA 94062. Subscriptions are $20/year. This newsletter is oriented towards users of Multibus-based 68000 systems, but it plans to cover all 68000 systems a hacker might be interested in. If the 32016 ever shows up in cheap systems like NS says it will, they will cover it too. Some of your readers might be interested in knowing about it." John McN., Canoga Park CA
John, WE subscribed to that other rag, since we are somewhat interested in 68000s. It seems to be focussed around the reclamation of SURPLUS 68000 boards designed for use with the Intel Multibus (IEEE 796 bus), specifically surplus WICAT boards. The first two issues abound with photographs and parts lists for WICAT boards. After what is obviously hundreds of hours of work, Victor asserts that he has a 4K 68000 system up and running. Victor also told us he plans to expand his coverage to other systems.
We would have sworn that we have been writing EXACTLY what you just wrote about the UNIX system. However, in the context of Rod Coleman's remarks about operating systems, including the p-SYSTEM and MS-DOS, it is still not clear to us what he meant by 'great capacity'. Perhaps your interpretation is correct.
Boy, do we remember the 8X300! That chip dates 'way back to 1975, making it a contemporary (or even predecessor) of the Z80. The 8X300 and its slightly modernized successor the 8X305 are a cross between an 8-bit micro like the 6502 and the 2900-series bit-slice machines. The part is microprogrammed instead of programmed - the lucky designer gets to choose his own microprogram word width and such, just like the 2900 series. We would say it is incredible that that 10-year-old part is still in use except that the 10-year-old Z80 (and 6502) is still in use. Incidentally, if the Napoleon who is running the Western Design Center ever actually turns out production quantities of his new 'super-6502' with an 8MHz clock rate, that chip will be an 81300 replacement, NOT competition for the 68000 as he claims (hence the 'Napoleon' bit).
You may well be entirely correct in your other remarks about hard disk controllers, and we thank you for the
Page 19, Column 1
additional information. We may have been mislead by the fact that most personal computing systems with hard disks and a theoretical data transfer rate 10 times higher than our high-density floppies run slower than our high-density floppies. We assumed the problem was the Z80. We will look into this further, and pass on whatever we find out - FNE
"In your last issue (#38) you implied that you were the only purveyor of low-cost 68000 systems. This is not in accordance with the facts...
"I just can't resist tweaking the ears of attack teddy-bears." Sam B., San Anselmo CA
Huh? Sam, this is the newsletter which has at various times prominently mentioned our 'competitors', including that $229 68008 board from Stellation II. Perhaps we did slip - can you give us a page #? By the way, DTACK and GROUNDED are KODIAK attack teddy-bears! We recommend restraint with the ear-tweaking bit - FNE
"I recently updated my FORTRAN package for the DTACK board. Version 1.1 of Fort68 now supports the transcendentals in the P-code interpreter. This significantly speeds up all transcendental functions. The bug with the short character string has been fixed and the new version also supports the SYSTEM.LIBRARY of Inter68 version 1.2/1.3.
"To use Fort68 [1.1] you need the Apple Pascal [1.1] FORTRAN compiler and Inter68 version 1.2 or later. The price of $65 (please send checks only) includes the diskette and a 10 page user manual.
"Owners of version [1.0] may upgrade for $25."
Peter Siebert
Einsteinstrasse 186
4040 Neuss 1
West Germany
"The DTACK Software Exchange (DSEx) exists to accomplish two things: first, to disseminate useful public domain software to all DTACK board users; second, to present a vehicle for free and open idea exchange in the form of The HALGOL Review, the newsletter of the Exchange. All DTACK board owners are invited to join the Exchange and receive the newsletter for free by simply writing to me at the address below (I request that persons who do not have a board and are merely interested tell me so when they join so that I not keep them on the rolls too long). Any disk order automatically enrolls the purchaser as a full member of the exchange." Jeff H., Corpus Christi TX
Page 19, Column 2
DSEx Current Catalog
All disks are $4 each postpaid (overseas airmail $5 each postpaid). MAKE CHECKS PAYABLE TO "DTACK Software Exchange" if you know what's good for you. All disks are Grande compatible unless otherwise noted. Mailing address: DTACK Software Exchange. 4326 Congressional Drive. Corpus Christi, TX 18413; telephone 512-852-5208.
Disk 1 - DAS DTACK linked Applesoft by Pete Soule
(static boards only).
Disks 2/3 - Sensonig BASIC sample programs, manual
and Index. Must be ordered together. Runs under
DOS or ProDOS, hard disk compatible.
Disk 4 - Pascal Stuff assorted miscellany.
Disk 5 - Assorted assembly stuff and miscellany,
programs mentioned in back HR issues.
Disk 6 - Sensenig BASIC for the 32061 math chip
sample programs and manual addition. Runs under
DOS or ProDOS, hard disk compatible.
Disk 7 - FigFORTH for DTACK boards by Ken Matei,
contributed by Willis Matthews.
Disks 8/9 - MON68K by Thomas Wieland. Must be
ordered together. Programs plus (53 page)
manual/index. Assumes you have lowercase
display.
Disk 10 - ProDOS RAMDISK by Keith Sproul/Pete
Soule. Versions for original and Stuffer
interfaces.
Disk 11 - MINOS 3.01 by Roger Ronald for
static/dynamic boards. ProDOS version of
MINOS. You will need MINOS 1.0 from Phase
Zero for documentation. Sourcecode available
from Roger Ronald (see HR #9, p.3).
Disks 12/13 - Resident Cress Assembler/Editor
for Static boards only by Henning Spruth. Order
as a set only. Includes instructions for building
your own DTACK Grounded compatible board with
complete software and source code. Schematic
diagram set available free to exchange members
(domestic and overseas) on request.The HALGOL Review is the independent newsletter of DTACK board applications and programming, published every once in a while (pseudomonthly) by Jeffrey W. Hull. Subscriptions both domestic and overseas are free to any exchange member or board owner. Letters and calls are welcomed. Continued existence is always problematical and entirely dependent upon your correspondence.
Page 20, Column 1
SON OF BUSTED TRICYCLE:
The AMD tricycle ads are back! You will remember those ads from about 20 months ago, which compared the performance of the 80286 and the 68000 in a somewhat (ahem!) less than factual manner. You can dig into DTACK back issues if you want to find out about those old AMD ads; what we will mostly discuss is the first of the new ads (e.g 28 Feb EET, pp8-9).
As we predicted, there is no contemptuous remark about "Motorola having its second sources spread out from here to Tokyo!" That's because Intel now has its OWN second sources spread out from here to Tokyo.
The old ads were about the wonderful 80286, aka iAPX 286, that AMD was gonna sell REAL SOON NOW. Oddly enough, the NEW ads are about the 80286 that AMD is gonna sell REAL SOON NOW. (Apologies to J.P.) Not much progress in the last 20 months, AMD!
The new ads are a 'comparison' of the 80286 vs. the Motorola 68020, which is represented by a ten-foot-high tricycle. A tricycle which is NOT busted, we add. AMD claim #1: the off-chip MMU will slow down the 68020 in a multi-tasking environment, and a cache memory cannot fully compensate for the degradation of performance. On the other hand, AMD claims that the 80286 has the MMU on-chip "so you don't lose any performance." FACT: ALL microprocessors suffer performance degradation in a memory-managed, multi-tasking environment, notably including the 80286. In fact, the 80286 probably degrades more than the 68020 because it has to map 64K into 16Meg, whereas the 68020 has no 64K limitation. NOR IS IT EVEN LIMITED TO 16MEG!
AMD claim #2: "We'll give you two responsible sources for the iAPX family: Intel and Advance Micro Devices. We have a ten-year agreement to exchange parts, masks and R & D..." FACT: the agreement in question does NOT, repeat NOT cover the entire iAPX family. Only the 286 (besides the 8086/8) was covered by the agreement until recently when the 80186 was belatedly added. There is no agreement for AMD to source the 80386 or even the famed iAPX 432. The AMD ad is highly misleading on this point.
AMD claim #3: The UNIX kernal must, in part, be rewritten to accommodate the new MMUs Motorola is developing for the 68020. FACT: That's true! It's ALSO true that the UNIX kernal must be rewritten for ANY microprocessor manufactured by ANYONE. What the hell does AMD think DRI has been doing these past many moons while porting System V to the 286?
AMD claim #4: That they (AMD and Intel) have more peripherals on the shelf than "any other family'. FACT: That is sort of true. "Sort of" because we have
Page 20, Column 2
never had any problems interfacing the 68000 to Intel-type peripheral chips (NEC 7220, WD 2797) or even non-Intel chips (Nat Semi 32081). AMD may win this one in the big marketplace because we suspect that Motorola might not want you to know that Intel peripheral chips interface so easily to the 68000 family.
AMD conveniently refrains to compare the performance of the 80286 and the 68020 this time around. Gosh! We wonder why? Could it be because the 68020 is about three times faster in the first place (8MHz 286, 16MHz 68020, no wait states)?
Welcome back, AMD. Don't let any of your copy writers get caught under that unbusted 10-foot-high tricycle now, y'heah?
DEPT. OF TRUE FACTS:
H.P. prexy John Young asserts that H.P.'s computer sales have shown a compounded-annual-growth of 20%. He then explains that that "results in an increased sales factor of six over a five-year period." (28 Jan EET, p.16) Sorry, John - that's an increase of about 2.5, not 6, over a five-year period. Better have the ROMs in your H.P. 35 checked.
APPLE WATCH I:
On the morning of Jan 24, we excitedly grabbed the WSJ and the business section of the L.A. Times to learn of the fantastic new product introductions at Apple's annual stockholders' meeting. We were less than enthralled by what we read.
NEITHER newspaper mentioned the quiet passing of LISA II. LISA, whatever the version, is now officially deceased. Surviving is the Mackintosh XL, which looks amazingly like the old LISA II/10. However, ALL of the old LISA software has now gone with the wind - only Mack software is being supported. Let's see, now - ALL Mack software features bit-graphics, and the 'aspect ratio' of the Mackintosh XL CRT dramatically differs from the regular Mack. Hmmm.
According to the WSJ and LAT stories, the star of the stockholders' meeting was a network to connect with IBM PCs, said network to be available for purchase not in 1985, not in 1986... no sir! That network will be available in 1987! LET'S HEAR IT FOR APPLE COMPUTER, FOLKS! 1987! We are already holding our breath!
Even long-time Applephile Jeff H. had his milk curdled by Apple's latest moves. If Apple has lost Jeff H., how many friends can it have left?
(Jeff ain't the only friend Apple has just lost. Read on!)
Page 21, Column 1
APPLE WATCH II:
Jobs and Scully have publicly wept over Apple's poor performance in the last quarter of calendar 1984. Woe, woe. Folks are avoiding the purchase of Mackintoshes in droves and neither Jobs nor Scully can understand why.
Gosh! For a couple of weeks we were convinced that there must be TWO Apple Computer Companies, because one of them had the most spectacularly successful quarter, both from the standpoint of sales and of profits, in corporate history in the fourth quarter of 1984. In fact, with Commodore's sales actually DROPPING - and dropping SIGNIFICANTLY - versus the same quarter in 1983, Apple's performance in more than doubling its sales and profits looks even more spectacular. So why are Jobs and Scully wearing sackcloth and ashes and wailing loudly?
Why, because most of those sales dollars were Apple II-related. Nobody in upper management at Apple gives a fig about II-related sales or profits. In fact, they all wish the II would go away! The weeping and wailing was, and is, over Mack's poor showing in that last quarter. It seems that Mack only accounted for about $200 million in sales while II-related sales were about $490 million (of the total of $698 million).
WOZ WATCH AND FAREWELL:
Any time a crummy little newsletter editor starts telling you about the personal attitudes of upper management of a billion-dollar-plus company it behooves him to provide some supporting evidence. So if all of you will turn to page 177 of Jan BYTE, we will provide a few quotes from Wozniak's interview:
"...we spent three solid years keeping the Apple II down."
"Unfortunately, we made it very difficult for anyone to get access to the insides of (the Apple III)... We closed that machine up to where somebody could have a very difficult time finding out how to add their own I/O drivers. We did not make it easy for the outside world. We thought we wanted all of the market for ourselves."
"The thinking on the III was very much like a religion in that it could only be done one way - our way... Nothing on the II should be allowed to run as fast or faster than the Apple III. That was the thinking that stuck with the company for three solid years."
Substitute 'Mack' for 'Apple III' and you pretty much have Apple's attitude today. By the way, we did not make up the bit about Jobs and Scully weeping and
Page 21, Column 2
YEAR APPLE COMPUTER COMMODORE
'82 $663.8M $71.2M $??? $??
'83 $1084.7M $59.0M $1042.3M $126.1M
'84 $1897.9M $104.3M $1209.4M $100.3MShown above are the sales and profits for Apple and Commodore for the last three calendar (not fiscal) years. We do not have complete figures for Commodore in 1982. However, in 1981 Apple was outselling Commodore about 2 to 1 as measured in dollars. Note what a magnificent job Tramiel did in pulling Commodore even with Apple in total sales and WAY ahead in profits (1983) before Gould showed him the gate!
YEAR APPLE COMPUTER COMMODORE
'82 $214.3M $23.5M $176.3M $26.6M
'83 $316.2M $5.8M $431.4M $50.1M
'84 $698.3M $46.1M $338.7M $3.2MShown above are the sales and profits for Apple and Commodore for the 4th calendar quarter of the last three years. Note how well Commodore did in '83 vs. Apple: as you might have guessed, that was Commodore's last quarter with Tramiel in charge. Then see the most recent quarter ('84) to see how each company is doing. Apple is obviously doing spectacularly well with Tramiel gone; too bad nobody at Apple respects sales and profits made by its Apple II line!
wailing over sales following its most successful quarter in history. Nearby you will find the recent sales and profit performance for both Apple and Commodore. Yearly figures are for calendar, not fiscal, years. By '4th quarter' we mean the three months Oct, Nov, Dec - in other words, the Xmas selling season. YOU decide whether weeping and wailing is/was appropriate.
After reading the Woz interview in Jan BYTE you should not be surprised that Woz and corporate Apple have parted company. The next time Woz criticizes corporate Apple he will do so as a private citizen.
DRAM PRICING:
It is now a little over 12 years since we purchased our first personal computer. (David Bunnell likes to claim he was in on the very first personal computers, but the truth is he had barely completed toilet training when we received our BASIC-in-ROM home computer with a 64 column, 16 line CRT.) That computer, a Wang 2200, came with 4K RAM and was expandable to a maximum of 32K RAM. To reach 32K, four circuit boards with 8K bytes each were needed. Each circuit board was populated with two
Page 22, Column 1
rows of 16 dynamic RAMs, each of which had a munificent 2K bits. The RAMs were AMS 6003s, originally made especially for Honeywell. At that time these RAMs represented the very highest production technology - sort of like 256Ks this time last year.
Each 8K board cost $2500, so it would set you back a cool $10,000 for a complete 32K board set. As it happens, the 256K DRAMs which are now becoming common EACH contains 32K bytes, the same as a full-house Wang 2200 12 years back (!), and you can buy one for around $10. That's at the chip level. Put it on a board and sell it at retail and the price is about $44 (e.g. $700/16). That is roughly a ratio of 256-1 over twelve years, which is an exact fit for the 'doubling every 1.5 years' rule for RAM that we published in these pages a long while back.
(True, the 1985 dollar is worth about half the Nov '81 dollar, but it is also true that Wang has historically charged more than Apple for memory. It balances out. Besides, if prices change by, say, 128-1 or 512-1 over a 12 year period the doubling time is changed but little. It's a simple log problem, YOU work it out!)
What doubles every 1.5 years is the amount of memory you get for a constant dollar. That has held true over ever since the first integrated flip-flop, which was a one-bit memory chip! But the curve is NOT smooth in the short term, spectacularly including the period one year back, at which time DRAM prices were MUCH higher than would have been expected based on a smooth historical curve. The reason for that anomoly, as we all know now, was the irrational expectations of about 60 companies, each of which was planning to take 10% to 30% of the IBM PC-compatible market.
The price WE have paid for 64K DRAMs has dropped by a factor of three just in the past year and most of that drop has taken place in the past five months. Yes, we have a new price list. Yes, the incremental price for DRAM is about a third - actually a bit LESS than a third - of what we charged a year ago. The prices we charge really ARE related to our costs, as we have said in the past. We are continuing to charge about $2.47 for each $1 of raw parts that we buy, so we can make a profit and stay in business, as we explained quite recently. So will those of you who got huffy at us for RAISING our prices a year ago please calm down? Our COSTS went up a year ago, and our prices really ARE related to our costs!
VARIETIES OF DRAM COSTS:
There is the CHIP cost, the INCREMENTAL cost, and the SYSTEM cost. The chip cost is smallest, right around $1.60 per 64K DRAM if we are telling you the truth about our markup (we are). The INCREMENTAL cost is the
Page 22, Column 2
OUR NEW PRICES:
The following prices are taken from our new price list, and are effective as of 11 Feb '85:
GRANDE (Apple compatible):
128K $672 640K $1143
256K $736 768K $1207
384K $800 896K $1271
512K $864 1024K $1335GRANDE memory expansion: (bought separately)
128K $279 384K $407
256K $343 512K $471
QD-2W (3-holer): $135
(the QD-1W 1-holer math board has been discontinued)
Stuffer board: $130Add 6% sales tax for delivery in California.
difference between, say, a 128K GRANDE and a 256K GRANDE. Since that is now $64 and since 16 added chips are needed, that works out to $4 per chip. However, the price for the 128K GRANDE already included the sockets, bypass caps, soldering, handling, PC board space etc. for those extra 16 DRAMs. The SYSTEM price - which includes those costs - is higher than $4/chip. How much higher?
Well, our half-megabyte expansion board for the GRANDE is just about pure RAM or RAM support. We now charge $471 for a fully loaded board (64 chips). That's $7.36 per chip at the SYSTEM level. So now you know the difference between chip, incremental, and system DRAM prices. (If you are wondering how to get good 150nsec DRAM for $1.60 a chip, just order 5,000 of them and have a certified check waiting two days later when UPS arrives. No, we won't sell you chips for $1.60. In fact, we won't sell you chips period.)
We try to make this newsletter both interesting and (occasionally) informative. The reason we publish details of costs, overhead, markups, - and the need for profitability - is that nobody else that we know of does so. So we would guess that the above info is of interest to our readers who do not have a business background. We do this knowing full well that a significant portion of the microcomputer buying public simply does not understand why companies cannot buy a part for $1 and then sell it for $1. If they charge more, they must be dirty rotten greedy capitalist pigs, yes?
Page 23, Column 1
Our graphics boards are now only sold assembled and tested as a system. Individual boards are not available for purchase. This condition will continue until we develop software support for the graphic boards, at which time this policy will be reviewed.
The above prices are for sales in the United States to areas covered by United Parcel delivery. Prices to areas not covered by United Parcel delivery may be higher. Add 6% if delivery is to made in California. As of 15 Feb '85 Digital Acoustics no longer accepts orders outside the United States, regardless of the price of the product in question. (Continue reading for explanation.)
ECONOMIC REPORT:
After a very slow month of sales (Sept '84), amid widespread poor sales and massive layoffs elsewhere in the industry, we laid off two employees. One was a full-time programmer, the other a full-time secretary. Neither was involved in design or production of the boards we sell, and design and production of boards is what pays the bills at Digital Acoustics.
Our fear at the time was that the sales downturn would continue indefinitely. Well, it DID continue, and worsened, for another month (Oct. '84). Since both our overhead and DRAM prices had dropped, we printed a new price list effective 15 Oct '84. Sales rose substantially the next month, and have been good since. (In fact, two days ago we approached our part-time board stuffer, who is a third-year business administration major at Cal State Fullerton, to see if he wanted to work more hours. We are running close to capacity at the moment, given the present number of employees.)
We think the marketplace has sent us a message to operate leaner and more efficiently and to keep our costs down. That means no full-time programmer and no full-time secretary to work just two hours a day. AND SINCE WE HAVE NO FULL-TIME SECRETARY SITTING AROUND WITH NOTHING TO DO, WE NO LONGER HAVE TIME TO SCREW AROUND FILLING OUT EXPORT/CUSTOMS FORMS, NOT EVEN TO CANADA! Death March Dunkerson is filling in at the front desk to see that the bills are paid and that the payroll checks are made out, but Death March is NOT a touch-typist!
In fact, our project engineer James S. and your FNE are the only touch-typists now on the Digital Acoustics payroll. That's yet ANOTHER reason why letters requesting information are not getting answered. Aren't we rotten?
So our staffing level has changed, and that has necessitated some policy changes. But Digital
Page 23, Column 2
Acoustics has returned to robust health as measured by sales and profits. We thank the several readers who wished us the best after we (truthfully) reported a downturn which now appears to have been temporary. QUESTION: would the downturn have been temporary had we not cut back unessential overhead and then dropped our prices to reflect that new, lower overhead (in addition to lower DRAM prices)?
HALGOL v.03 REPORT:
Believe it or not, v.03 has (finally!) been shipped. Boy, were we ever optimistic asserting that we would ship v.03 the second week of January! It took us two weeks (of part-time work) just to put together the MAILING LABELS! You see, we use the ApplePost mailing list program and it doesn't allow printing out DTACK board purchasers.
Anyhow, v.03 has been mailed, at OUR initiative and at OUR cost. Anybody has any complaints, return what we sent and you will get your purchase price back ($0.00).
Another reason for the delay was we wanted the DATASAVE and DATALOAD statements to work so you could save and load arrays. After 23 pages of code, we got that done and working! Honest! Enjoy!
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, Mackintosh?: Apple Computer Co. Anybody else need a 194th million ack, have your legal beagles send us the usual threat.
SUBSCRIPTIONS: Subscriptions are $15 for 10 issues in the U.S. and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. All back issues are kept in print; write for details. The address is:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
THIS ISSUE'S REDLANDS is five pages of the actual 68000 code to execute the pseudo-code algorithm for DATASAVE printed earlier in this newsletter. That algorithm ignored the host buffering and pseudo-files that are actually used to make this code compatible with DOS 3.3. Can you spot the extra code needed for DOS 3.3 compatibility? Now you can allocate, say, 4 megabytes of your SIDER disk for HALGOL files! And, if you have a megabyte, save or load an 800K array - NOW!
Page 24
2 LIST
3 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC
4 ;
5 ;-----------------------
6 ;-- ROUTINE: DATASAVE --
7 ;-----------------------
8 ;
9 ; DATASAVE "FILENAME"(DN),ARGUMENT LIST
10 ;
11 ; (SEE THE PSEUDO-CODE AND DISCUSSION OF DATASAVE
12 ; IN DTACK GROUNDED ISSUE #39)
13 ;
14 ; STORE THE FILENAME IN TEMPORARY BUFFER FNB
15 ; IDENTIFY AND STORE #N, THE DISK DRIVE #
16 ;
009F00: 48E70078 17 DS MOVEM.L A1-A4,-(A7) ;SAVE REGS
009F04: 4EB89DAA 18 JSR FNAME ;NAME, CKSUM, DR #
009F08: 3F03 19 MOVE.W D3,-(A7) ;SAVE CHKSUM
20 ;
21 ; CALCULATE THE NUMBER OF SECTORS REQUIRED TO SAVE
22 ; THE FILE
23 ;
009F0A: 4EB8A072 24 JSR FILESIZE ;D1 = #SECTS
009F0E: 31C1A102 25 MOVE.W D1,CNT ;STORE # SECTS
26 ;
27 ; READ DISK #N CATALOG INTO THE CATALOG BUFFER
28 ;
009F12: 4EB89CC2 29 JSR READPCAT ;READ THE CATALOG
30 ;
31 ; SEARCH THE DISK CATALOG FOR THE GIVEN FILE TYPE
32 ; FILENAME CHECKSUM, AND FILENAME.
33 ; GOTO OLDF IF DATA FILE FOUND
34 ;
009F16: 3617 35 MOVE.W (A7),D3 ;RESTORE CHKSUM
009F18: 4EB89DFE 36 JSR SRCHFN ;1ST SECTOR # TO DO
009F1C: 673C 37 BEQ OLDF ;IF FILE FOUND
38 ;
39 ; CHECK WHETHER THE DISK CATALOG DESCRIPTOR
40 ; TABLE IS FULL (ERROR IF SO)
41 ;
009F1E: 4BF90001F804 42 LEA DCAT+4,A5 ;PTR TO MAXFILES
009F24: 3E1D 43 MOVE.W (A5)+,D7 ;MAXFILES TO D7
009F26: BE55 44 CMP.W (A5),D7 ;ROOM FOR ANOTHER?
009F28: 6396 45 BLS ERR76 ;NO, CATALOG FULL
46 ;
47 ; INCREMENT THE NUMBER OF FILES IN THE CATALOG
48 ; STORE THE FILE TYPE AND ATTRIBUTE BYTES (2 BYTES)
49 ; STORE THE FILENAME CHECKSUM AND THE FILENAME
50 ;
009F2A: 5255 51 ADDQ.W #1,(A5) ;INCR FILE CNT
009F2C: 2041 52 MOVE.L D1,A0 ;FILE DESCRIPTR PTR
009F2E: 30FC0200 53 MOVE.W #$0200,(A0)+ ;DATAFILE I.D.
009F32: 361F 54 MOVE.W (A7)+,D3 ;RESTORE CHKSUM
009F34: 10C3 55 MOVE.B D3,(A0)+ ;FILENAME CHKSUM
009F36: 4BF89EE4 56 LEA FILENAME,A5 ;SET NAME PTR
009F3A: 7C10 57 MOVEQ #16,D6 ;SET FOR 17 CHARS
009F3C: 10DD 58 DS1 MOVE.B (A5)+,(A0)+ ;MOVE A BYTE
009F3E: 51CEFFFC 59 DBF D6,DS1 ;MOVE 17 CHARS
60 ;Page 25
62 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC
63 ;
64 ; A0 POINTS TO FSF (FIRST SECTOR # OF FILE)
65 ;
66 ; SET OLD = 0; NSF = 0; FSF = NXSA; NEW = CNT
67 ; INCREMENT NXSA (THE NEXT AVAILABLE SECTOR #)
68 ; GOTO NEWF
69 ;
009F42: 4BF90001F802 70 LEA DCAT+2,A5 ;PTR TO NXSA
009F48: 30D5 71 MOVE.W (A5),(A0)+ ;SET FSF = NXSA
009F4A: 4250 72 CLR.W (A0) ;SET NSF = ZERO
009F4C: 4278A104 73 CLR.W OLD ;SET OLD = ZERO
009F50: 31F8A102A106 74 MOVE.W CNT,NEW ;SET NEW = CNT
009F56: 5255 75 ADDQ.W #1,(A5) ;INCREMENT NXSA
009F58: 601C 76 BRA NEWF ;GOTO NEWF
77 ;
78 ; D1.L = PTR TO EXISTING FILE DESCRIPTOR
79 ; NSF = NUMBER OF SECTORS IN FILE
80 ;
81 ; SET OLD = NSF AND SET NSF = ZERO
82 ; CALCULATE NEW = CNT - OLD
83 ; IF NEW IS NEGATIVE, SET NEW = 0
84 ;
009F5A: 548F 85 OLDF ADDQ.L #2,A7 ;CORRECT STK PTR
009F5C: 7416 86 MOVEQ #22,D2 ;NSF OFFSET
009F5E: D282 87 ADD.L D2,D1 ;D1 = NSF ADDR
009F60: 2041 88 MOVE.L D1,A0 ;A0 = PTR TO NSF
009F62: 31D0A104 89 MOVE.W (A0),OLD ;SET OLD = NSF
009F66: 3438A102 90 MOVE.W CNT,D2 ;FETCH CNT
009F6A: 9450 91 SUB.W (A0),D2 ;D2 = CNT - OLD
009F6C: 6A02 92 BPL OLDF1 ;IF NO UNDERFLOW
93 ;
009F6E: 7400 94 MOVEQ #0,D2 ;CLR D2
009F70: 31C2A106 95 OLDF1 MOVE.W D2,NEW ;NEW = CNT - OLD
009F74: 4250 96 CLR.W (A0) ;SET NSF = ZERO
97 ;
98 ; A5 = PTR TO NXSA; A5-2 = PTR TO TSA
99 ; A0 = PTR TO NSF; A0-2 = PTR TO FSF
100 ;
101 ; ERROR IF TSA < (NXSA + NEW)
102 ; SET SEC# = FSF (SEC# = SECNUM)
103 ;
009F76: 4BF90001F802 104 NEWF LEA DCAT+2,A5 ;PTR TO NXSA
009F7C: 3415 105 MOVE.W (A5),D2 ;NXSA TO D2
009F7E: D478A106 106 ADD.W NEW,D2 ;D2 = NXSA + NEW
009F82: B46DFFFE 107 CMP.W -2(A5),D2 ;TSA < NXSA+NEW ?
009F86: 6200FF40 108 BHI ERR78 ;NOT ENOUGH ROOM
109 ;
009F8A: 31E8FFFEA108 110 MOVE.W -2(A0),SECNUM ;SET SEC# = FSF
009F90: 42789EFE 111 CLR.W TSTKCNT ;CLR TSTACK CNT
009F94: 42B89EFA 112 CLR.L RCNT ;CLR REMNG COUNT
113 ;
114 ; READ THE PSEUDO-FILE CONTAINING THE FIRST SECTOR
115 ; OF THE FILE (FSF) INTO THE HOST MEMORY.
116 ;
009F98: 48E700FE 117 MOVEM.L A0-A6,-(A7) ;SAVE REGS
009F9C: 4EB8A050 118 JSR RDSECNPF ;LOAD FILE TO HOST
009FA0: 4CDF7F00 119 MOVEM.L (A7)+,A0-A6 ;RESTORE REGS
120 ;Page 26
122 ; NOW PERFORM THIS LOOP UNTIL THE FILE IS SAVED
123 ;
124 ; CLEAR THE FIRST FOUR BYTES OF THE BUFFER
125 ; FILL THE BUFFER
126 ; DECREMENT CNT
127 ; IF CNT = ZERO, GOTO SAVEX
128 ; IF OLD = ZERO, GOTO NEWSEC
129 ;
009FA4: 43F8A300 130 LOOP LEA BUFF1,A1 ;BUFFER POINTER
009FA8: 4299 131 CLR.L (A1)+ ;CLR NX-SECT PTR
009FAA: 4EB8A110 132 JSR FILLBUFF ;FILL THE BUFR
009FAE: 5378A102 133 SUBQ.W #1,CNT ;DECREMENT CNT
009FB2: 674A 134 BEQ SAVEX ;LAST SECT IF ZERO
135 ;
009FB4: 4A78A104 136 TST.W OLD ;OLD = ZERO ?
009FB8: 672A 137 BEQ NEWSEC ;GOTO NEWSEC
138 ;
139 ; SERVICE A PREVIOUSLY SAVED (OLD) SECTOR
140 ;
141 ; DECREMENT OLD
142 ; READ DISK SECTOR SEC# (4 BYTES ONLY) TO TSEC
143 ; (DO NOT MODIFY 1020 BYTE BUFFER DATA)
144 ; IF TSEC = ZERO, GOTO NEWSC1 ELSE GOTO NEWSC2
145 ;
009FBA: 5378A104 146 OLDSEC SUBQ.W #1,OLD ;DECREMENT OLD
009FBE: 4EB8A036 147 JSR SECNFILE ;SECNUM IN HOST MEM
009FC2: 7C07 148 MOVEQ #7,D6 ;SECTOR MASK
009FC4: DC78A108 149 ADD.W SECNUM,D6 ;SECTOR #0-7 TO D6
009FC8: 780A 150 MOVEQ #10,D4 ;SET 10-BIT SHIFT
009FCA: E96E 151 LSL.W D4,D6 ;MULTIPLY BY #1024
009FCC: 06464000 152 ADD.W #$4000,D6 ;HOST BASE ADR
009FD0: 2F0D 153 MOVE.L A5,-(A7) ;SAVE A5
009FD2: 4BF8A10A 154 LEA TSEC4,A5 ;68K ADR = TSEC
009FD6: 7804 155 MOVEQ #4,D4 ;4 BYTE TRANSFER
009FD8: 4EB83C34 156 JSR CMD7 ;READ 4 BYTES
009FDC: 2A5F 157 MOVE.L (A7)+,A5 ;RESTORE A5
009FDE: 4A78A10C 158 TST.W TSEC ;TSEC <> ZERO ?
009FE2: 6606 159 BNE NEWSC1 ;YES, GOTO NEXSC1
160 ;
161 ; SERVICE AN UNPREVIOUSLY SAVED (NEW) SECTOR
162 ;
163 ; MOVE NXSA (NEXT AVAIL SECTOR #) TO TSEC
164 ; INCREMENT NXSA
165 ;
009FE4: 31D5A10C 166 NEWSEC MOVE.W (A5),TSEC ;NXSA TO TSEC
009FE8: 5255 167 ADDQ.W #1,(A5) ;INCREMENT NXSA
168 ;
169 ; SVC A DISK SECTOR (NOT THE LAST SECTOR OF FILE)
170 ;
171 ; MOVE TSEC TO 4-BYTE NEXT-SECTOR BUFFER PTR
172 ; SAVE THE BUFFER TO DISK #N ON SECTOR SECNUM
173 ; INCREMENT NSF (# OF SECTORS IN THE FILE)
174 ; GOTO LOOP
175 ;
009FEA: 21F8A10AA300 176 NEWSC1 MOVE.L TSEC4,BUFF1 ;4-BYTE TSEC TO PTR
009FF0: 4EB8A012 177 JSR SAVEBUFF ;SAVE BUFF AT SEC#
009FF4: 5250 178 ADDQ.W #1,(A0) ;INCREMENT NSF
009FF6: 31F8A10CA108 179 MOVE.W TSEC,SECNUM ;MOVE TSEC TO SEC#
009FFC: 60A6 180 BRA LOOP ;GOTO LOOP
181 ;Page 27
183 ; COPYRIGHT 1985 DIGITAL ACOUSTICS INC
184 ;
185 ; SERVICE THE LAST DISK SECTOR OF THE FILE
186 ;
187 ; SAVE THE BUFFER TO DISK #N ON SECTOR # SECNUM
188 ; INCREMENT NSF (# OF SECTORS IN THE FILE)
189 ;
190 ; (THE PHRASE 'SAVE THE BUFFER TO DISK' SHOULD NOT
191 ; BE TAKEN LITERALLY; WHAT ACTUALLY HAPPENS IS
192 ; THAT THE 1K BUFFER IN THE 68000 IS MOVED TO ONE
193 ; OF THE EIGHT 1K 'SECTORS' IN THE HOST MEMORY
194 ; WHICH COMPRISE AN 8K PSEUDOFILE.)
195 ;
196 ; AFTER 'SAVING THE LAST BUFFER', WE SAVE THE
197 ; RESIDENT PSEUDOFILE BACK TO THE DOS 3.3 DISK,
198 ; COMPLETING THE DATASAVE OPERATION.
199 ;
200 ; THEN WE SAVE THE P-DISK CATALOG BACK TO DISK #N
201 ; AND RETURN TO HALGOL (DATASAVE IS COMPLETED)
202 ;
009FFE: 4EB8A012 203 SAVEX JSR SAVEBUFF ;SAVE BUFF AT SEC#
00A002: 5250 204 ADDQ.W #1,(A0) ;INCREMENT NSF
00A004: 4EB8A064 205 JSR WRCURPF ;SAVE PFILE TO DISK
00A008: 4EB89CEE 206 JSR SAVEPCAT ;SAVE PDISK CATALOG
00A00C: 4CDF1E00 207 MOVEM.L (A7)+,A1-A4 ;RESTORE REGS
00A010: 4ED4 208 JMP (A4) ;RETURN TO HALGOL
209 ;
210 ;
211 ;
212 ;
213 ;--------------------------
214 ;-- SUBROUTINE: SAVEBUFF --
215 ;--------------------------
216 ;
217 ; FIRST MAKE CERTAIN THAT THE CORRECT PFILE IS
218 ; LOADED INTO THE HOST, AND THEN SAVE THE 1K
219 ; BUFFER TO THE HOST.
220 ;
00A012: 4EB8A036 221 SAVEBUFF JSR SECNFILE ;RIGHT P-FILE LD'D
00A016: 7C07 222 MOVEQ #7,D6 ;SECTOR MASK
00A018: CC78A108 223 AND.W SECNUM,D6 ;SECTOR #0-7 TO D6
00A01C: 780A 224 MOVEQ #10,D4 ;SET 10-BIT SHIFT
00A01E: E96E 225 LSL.W D4,D6 ;MULTIPLY BY #1024
00A020: 06464000 226 ADD.W #$4000,D6 ;HOST BASE ADR
00A024: 2F0D 227 MOVE.L A5,-(A7) ;SAVE A5
00A026: 4BF8A300 228 LEA BUFF1,A5 ;PTR TO 1K BUFFER
00A02A: 383C0400 229 MOVE.W #1024,D4 ;COUNT = 1K BYTES
00A02E: 4EB83C38 230 JSR CMD8 ;SET 1K TO HOST
00A032: 2A5F 231 MOVE.L (A7)+,A5 ;RESTORE A5
00A034: 4E75 232 RTS ;SAVEBUFF DONE
233 ;Page 28
235 ;--------------------------
236 ;-- SUBROUTINE: SECNFILE --
237 ;--------------------------
238 ;
239 ; MAKE CERTAIN THAT THE PSEUDO-FILE SPECIFIED
240 ; BY SECNUM IS LOADED INTO THE HOST'S MEMORY.
241 ;
00A036: 48E70084 242 SECNFILE MOVEM.L A0/A5,-(A7) ;SAVE REGS
00A03A: 3038A108 243 MOVE.W SECNUM,D0 ;SET SECTOR PTR
00A03E: E648 244 LSR.W #3,D0 ;PFILE # IN D0
245 ;
246 ; IF THE PFILE # IN D0 IS NOT THE SAME AS THE
247 ; CURRENT PFILE # (CURRPF), SAVE THE CURRENT PFILE
248 ; TO MEMORY AND LOAD THE NEXT PSEUDO-FILE.
249 ;
00A040: B0789EE2 250 XCHGFILE CMP.W CURRPF,D0 ;SAME ?
00A044: 6704 251 BEQ XCHGX ;IF THE SAME
252 ;
00A046: 611C 253 BSR WRCURPF ;SAVE CURR PFILE
00A048: 6106 254 BSR RDSECNPF ;READ THE NEW PFILE
255 ;
00A04A: 4CDF2100 256 XCHGX MOVEM.L (A7)+,A0/A5 ;RESTORE REGS
00A04E: 4E75 257 RTS ;DONE
258 ;
259 ;--------------------------
260 ;-- SUBROUTINE: RDSECNPF --
261 ;--------------------------
262 ;
263 ; LOAD THE PSEUDO-FILE SPECIFIED BY SECNUM TO HOST
264 ;
00A050: 7000 265 RDSECNPF MOVEQ #0,D0 ;CLR UPPER BITS
00A052: 3038A108 266 MOVE.W SECNUM,D0 ;SET SECTOR PTR
00A056: 4EB89D36 267 JSR LEGLSECT ;PFILE # IN D0
00A05A: 4EB89D48 268 JSR RDPPARMS ;SET LOAD PARMS
00A05E: 4EB8986E 269 JSR LOADIT ;LOAD THE PFILE
00A062: 4E75 270 RTS ;DONE
271 ;
272 ;-------------------------
273 ;-- SUBROUTINE: WRCURPF --
274 ;-------------------------
275 ;
276 ; SAVE THE CURRENT PSEUDO-FILE FROM HOST TO DISK
277 ; (THE 8K PSEUDO-FILE IS NOW RESIDENT IN HOST RAM)
278 ;
00A064: 30389EE2 279 WRCURPF MOVE.W CURRPF,D0 ;CURRENT PFILE #
00A068: 4EB89D50 280 JSR WRPPARMS ;SET SAVE PARMS
00A06C: 4EB8995E 281 JSR SAVEIT ;SAVE THE 8K PFILE
00A070: 4E75 282 RTS ;DONE
283 ;
