Issue # 20 DTACK GROUNDED Newsletter - June 1983

eZine lover (@eZine)

Published in 

DTACK GROUNDED Newsletter

 · 1 year ago

BACK IN BUSINESS II:

We did admit that our newsletter was going to look like a new product brochure for a while, no? The board(s) below, modestly entitled the DTACK Grande on account of DTACK ain't grounded, feature a cool, even megabyte of memory. Not, mind you, a megabyte less 4K. That's 1,048,576 for you decimal buffs. You are not supposed to notice that only 1,044,480 of those bytes are linearly contiguous. Well, you needed a 4K stack area off to one side anyway, now didn't you?

The board below is a non-working prototype. In fact, it has not yet had power applied to it. Reasons: we haven't blown the two PAL memory decode and 'propriety-protect' chips. In fact, we have as yet never blown a PAL and we have to learn how to program the equations. Although we have received the crystals we have not yet received the special delay-line package which provides the proper timing for CAS and for (sob) DTACK. This board will run (honest) at 12.5MHz with one wait state.

Page 1, Column 2

The effective throughput will be about equal to a 10MHz 'Grounded board with no wait states, after allowing another 4% for software refresh overhead. The board is as closely identical to the static RAM DTACK board as it is possible to make it and still use conventional DRAM. The memory map at the start matches the DTACK Grounded board, meaning ROM occupies $0000 to $03FF, and RAM starts at $1000. That first 4K, being reserved as it is for the bootstrap ROM and the various 68000 'exception' vectors plus I/O, is the reason the full megabyte is not in linear sequence.

The board(s) will be available in memory sizes from 128K to a full gallon in 128K increments. The amount of refresh overhead is the same for all sizes of RAM since we do some proprietary tricks in those PALs to refresh all eight rows of DRAMs at once.

Here are the differences: because the DRAM board may be interrupted at any time to perform a refresh, every byte being transferred by the host must be transferred with full handshake (the Stuffer board uses full handshake in hardware). This means some of our demo software must be re-written slightly, and it will run slightly slower than the DTACK Grounded boards do at 12.5MHz. On the other hand, the 'Grande is inherently capable of multi-tasking and the 'Grounded isn't. The reason for the multi-tasking capability is that the DRAMs nominally require refresh every two milliseconds.

Delivery: largish quantities of wave-soldered boards around the first of August. A few (20?) hand-soldered boards a few weeks earlier. We are following the same procedure on the Stuffer board, so the three brave pioneers who have ordered one will get it soon!

The DTACK Grande - A Full Gallon

Page 2, Column 1

A DTACK REVIEW:

A long-time DTACK GROUNDED fellow traveller mentioned the other day that it would be fun to sit down and review forward from newsletter #1, seeing the changes over time of our little endeavor. Our instant reply was that we had not changed much aside from the fact that we are turning into a real business and thus have to act as though we are a real business, not a hobby shop.

After giving that more thought, we believe that the industry and our audience have changed more than we have!

Let us take, for instance, Nils D. Unlike most of you, Nils does not now have a computer. He consistently refers to the Apple II as 'that fruity thing' and urges us to lower the price and performance of the DTACK board to below $500 and attach it to a VIC-20. He accompanies that suggestion with an assertion that we have turned our back on the hobbyists.

It's like this: we have not turned our back on the hobbyists, the hobbyists have abandoned us! In Jan '82, the first month after we had both the Pet and Apple compatible boards in production and had shipped all of the back orders, we sold an entire $4,000 worth of DTACK boards. The prices were higher then because the 68000 was still a new, expensive part. And 150 nsec RAMs cost us about $8 each (although 100 nsec parts were technically available, they were horribly expensive).

The product mix for that $4,000 was maybe 4 each 4K boards and maybe one 92K. In other words, we were selling mostly to the hobbyists. In Feb we sold another $4,000; in Mar another $4,000. Perhaps we should say that we were selling to a very few hobbyists.

In April our DTACK sales shot up to $6,000. In May we sold about $8,600 and in June about $13,400. When our sales reached $60,000 total in Sept, of which over $50,000 was in DTACK boards, we decided that DTACK GROUNDED qualified as a business.

However, sales have remained constant at about $50K for the DTACK boards since that time. That's a lot of hobbyists at $595 per 4K board, you say? We have news for you: we are now selling fewer than two 4K boards per month! Almost all of our board sales are 92K or 220K these days. And that is why we say that we have not abandoned the hobbyists, the hobbyists have abandoned us!

Nils, at $595 we are already pretty close to your target price of under $500 for a VIC-20 add-on. Our

Page 2, Column 2

experience with Apple owners (of which many are hobbyists) suggests that the total market for a low-performance VIC-compatible DTACK board would be very small. And Digital Acoustics, which after all is supposed to be a profit-making business, cannot afford to pursue very small and hence unprofitable markets. Besides, if you want to make VIC owners aware of your product you have to advertise in COMPUTE!, and they want $4,000 per page (shooting rocks is very popular).

Our guess is that the hobbyist wants big memories these days. We are putting money where our guess is, as witness the front page of this issue (it costs money to develop a one megabyte 68000 board). Far from abandoning the hobbyist, we continue to pursue him or her (we now have two female type subscribers).

Another thing is that the industry has changed on us. Back in July of 1981, when we published the first issue of this newsletter, the 68000 was a new, very expensive part. And the board that we began to lay out had a large memory, about one and a half times the (then) largest personal computer memories, which were 48K to 64K. (If you don't believe us, dig out your July '01 BYTE magazine and review the ads.)

Back in issue #11 we wrote about trends in memory sizes. In the 4th paragraph on page 7 we asserted, "...we have a clear trend that says the amount of memory per constant dollar doubles every 18 months." If that seemed like an overstatement at the time you read it, consider that 256K is, today, a nice amount of RAM for a personal computer to have. In the last issue we mentioned two IBM PC 'super-spreadsheets'. Well, MBA requires 256K and 1-2-3 requires 128K. Both require two disk drives. The Epson HQ-10 comes with 256K as standard equipment. So does T.I.'s 'The Answer' (now).

(Come to think of it, the VALDOCS version of the HQ-10 comes with 3/8 megabyte as standard equipment including the bit-mapped video RAM!)

We plan to sell our dynamic RAM version of DTACK with various sized memories, 128K to a full gallon (megabyte). Want to bet we don't sell more full gallons than 128K versions? The hobbyist looking for a bargain just doesn't sees to be around. Maybe he is standing in line for his very own $84.88 (today's price) VIC-20? We don't have the answers to these questions, folks. Do you?

Like we said, the industry and our audience have changed more than we have.

Page 3, Column 1

MORE HALGOL STUFF:

Two issues back we were discussing 'compilation by template'. You will recall that this compilation was to take place at the time the line is entered from the keyboard. That way, at run time precompiled standard HALGOL code is executed. But when the program is listed or edited, the original equation is seen so that the operator can be blissfully unaware of the compilation process.

Regrettably, we are writing the HALGOL code and we have to not only be aware of the process, we have to invent it!

We have to accept HALGOL code in these forms:

 LINE            CODE 

 140 LET A = B 
 141 LET A = B + C 
 142 LET A = B - C / D + E * F - G + H

The sample lines above are deliberately made simple for illustrative purposes. We are not limited to simple variable names (antidisestablishmentarianism is a perfectly valid variable name). Constants are also permitted, but if you will recall our discussion of HALGOL constants, which we call 'constant variables', you will be aware that constants are handled in exactly the same manner as named variables.

Remember, we are for now talking about non-parenthetical expressions. Therefore, there are only four possible math operators. If we generalize about the equations above, we find that we have N variables to the right of the "=" sign and N-1 math operators. N must be at least one, but cannot be greater than the size determined by our template table. At this point, we have not yet determined what that maximum size is. As we can see by line 140 above, we do not necessarily have any math operators.

Our problem is to first evaluate the expression on the right hand side of the "=" sign and then store the result in the variable list on the left side of the "=" sign. Ordinarily there will only be one variable to the left, but multiple variable assignments are permitted. For instance:

 143 LET X,Y,Z = 10

will be compiled into the following HALGOL primitives:

 LOAD #10 
 STORE X 
 STORE Y 
 STORE Z

Page 3, Column 2

#10 is, of course, a constant variable whose name is the ASCII characters "#", "1", "0" and whose value is the eight byte floating point representation of the number ten.

(Elsewhere in this issue you will find a guest editorial which asserts that extending a high-level language can only be done by using RPN techniques. We respectfully disagree, since what we are doing here is extending HALGOL primitives into a higher order abstraction.)

EXPRESSION EVALUATION:

We will concentrate for a while on the evaluation of the non-parenthetical expressions, ignoring the ensuing store operation(s).

Here is how we can perform a right-to-left evaluation of line 142 in the first column on this page. Let us invent the rule that we always start by loading the right-most variable into the HALGOL (floating point) accumulator (FPACC1). So a start by loading H.

Is the number of remaining math operators greater than zero (if not, the evaluation is completed). Yes. Is the next math operator a multiply or divide? If so, we can pull the next variable into the second FP acc (FPACC2) and execute the multiply or divide. In this case, it is not, so we have to check whether there is more than one remaining math operator. If there is just the one remaining math operator, we can go ahead with the operation which would complete the evaluation of the expression.

(The complication we are encountering is due to the observance of mathematical precedence, in which multiply and divide have a higher priority than addition or subtraction.)

We now have variable H in FPACC1, we know that the next math operator is an add or subtract, and we know that there are two or more remaining math operators. So we have to check the next math operator to see if it has the same precedence as the first. If the precedence is higher, we will have to temporarily store the contents of FPACC1 and also the present math operator and begin anew with the next variable.

In this case (line 142, remember), the precedence of the next math operator is the same, so we load G into FPACC2 and add FPACC1 to FPACC2. We now have the value of (G + H) in FPACC1. But following the reasoning above, we cannot now subtract this value from F because the second math operator has higher precedence. So we save FPACC1 in a temporary FP register and also store the next math operator, which is subtract.

Page 4, Column 1

 142 LET A = B - C / D + E * F - G + H 
 (repeated for reference)

Now we 'begin anew'. We load F into FPACC1 and, since the next math operator, multiply, has the higher precedence, we proceed to load E into FPACC2 and perform the multiply. We now have (E * F) in FPACC1 and a stored temporary value and associated stored math operator.

Since we have a stored temporary value, we check the next math operator. If the next operator is an add or subtract, we can recall the stored value and operator and (add or subtract) to the current value of FPACC1. Since the next operator is an add, we recall (G + H) to FPACC2 and subtract (the stored operator) FPACC1 from FPACC2. BUT WAIT! THAT'S WRONG!

What we just did was subtract (E * F) from (G + H) when what we really wanted to do was subtract (G + H) from (E * F). Our result has the correct magnitude but the wrong sign! So when we recall a stored value and math operator, we execute the operator and then check whether it was a subtract. If so, we change the sign of the result, which then is equal to (E * F - G + H), and we now do not have a temporary stored value.

Now we check the next math operator; it is an add. So we have to check the precedence of the second math operator; we find it is a divide and so has higher precedence. So we store the accumulator into our temporary location and once again we 'begin anew'. We load D into FPACC1 and, since the next operator has the higher precedence we immediately load the next variable, C, into FPACC2 and execute the divide. The value (C / D) is left in the accumulator.

Since we now have a temporary stored value, we check the precedence of the next math operator. It is a minus, so we recall our stored value (E * F - G + H) to FPACC2 and execute the stored math operator, which is an add. The result is (C / D + E * F - G + H). Since there is only one remaining math operator, we can immediately proceed to load B into FPACC2 and execute the last math operator.

This completes the evaluation of the expression.

While the procedure outlined above is not the only way to evaluate the expression, it is one way, and it works. As we have said before, there is much to be said for things which work. Before formalizing the procedure, let us examine what is needed to make that implicit procedure work:

1. A byte value of N whose range is 1 to MAX, where MAX is to be determined.

Page 4, Column 2

2. A list of two-byte offset addresses of the N variables, along with a pointer to the end of the list. The pointer can be a two-byte value if the list is in the 64K zero page of the 68000.
3. A list of N - 1 math operators, along with a pointer to the end of the list.
4. An eight-byte temporary storage area for an FP value and a one-byte storage area for a math operator.
5. A flag to indicate whether a temporary value is in storage or not.

In the walk-thru of the evaluation of the expression in line 142, we directly executed the math operators. To compile HALGOL, we instead store the HALGOL operator ADD, SUB, MULT or DIV followed by the variable which would be in FPACC2. When we 'begin anew' we simply LOAD the next variable into FPACC1. We also have to STORE the accumulator into the temporary storage area. Let us call the temporary area <TEMP>.

Here is the right-hand expression of line 142 compiled into HALGOL primitives:

 LOAD H 
 ADD G 
 STORE <TEMP> 
 LOAD F 
 MULT E 
 SUB <TEMP> 
 CHS 
 STORE <TEMP> 
 LOAD D 
 DIV C 
 ADD <TEMP> 
 SUB B

This completes the evaluation of the expression. STORE A would complete the execution of line 142.

ENCODING THE MATH OPS:

There are only two levels of precedence. Multiply and divide have higher precedence, add and subtract have lower. We must be alert to the fact that divide and subtract are not commutative; that is, C / D does not equal D / C. Likewise, G - H does not equal H - G. But, because of the right-to-left evaluation method, a multiply is performed in the same manner as a divide and a subtract is performed in the same manner as an add.

This means that, aside from correctly identifying an

Page 5, Column 1

 142 LET A = B - C / D + E * F - G + H 
 (repeated for reference)

add from a subtract and a multiply from a divide, we can devise a unique evaluation procedure for every non-parenthetical expression by simply taking into account the mathematical precedence of each math operator. Since there are only two levels of precedence, we can assign multiply and divide to precedence level one and add and subtract to precedence level zero. Thus, only a single bit is required to encode the precedence level of a math operator.

This means that the right-hand expression of line 142, which has seven variables, can be encoded into a unique HALGOL primitive sequence using only six bits. Since the math operators are:

 - / + * + -

The corresponding bit sequence is:

 0 1 0 1 0 0

ENCODING THE TEMPLATE

Since we can encode 8 math operators in a given byte, it follows that one byte can uniquely determine the sequence of an expression with up to nine variables. This gives us a trial value for MAX, the maximum number of variables allowed in an expression.

With nine variables, there are 256 possible sequences of HALGOL primitives. Only six primitives are permitted: LOAD, STORE and the four math operators. The six primitives can be encoded into three bits.

There is a tenth variable, <TEMP>. The ten variables can be encoded into four bits. Therefore, each of the eleven primitives (listed on the preceding page) can be encoded into seven bits each. Since we are not using all of a byte to encode each operation, we can get another trial value for a reasonable MAX by observing that a byte has 5 bits left to determine the variable after allocating 3 to encode the operation. Since we must allow for <TEMP>, we can encode 31 additional variables (this seems a bit extreme).

Using the compiled HALGOL for line 142 as an example, it seems that we can encode an N variable expression into roughly 1.5 N bytes. Since the length of each compiled sequence will differ depending upon precedence, we will need an additional byte at the start to determine the number of primitives in the sequence. That's a total of 1.5N + 1 bytes (appx) for each unique sequence of N variables.

Page 5, Column 2

If we let MAX = 9, we will have about 15 bytes of encoded HALGOL primitives for each unique sequence, and there are 256 such sequences. Remember, an expression has N - 1 math operators. This means our lookup table will be about 4K bytes for MAX = 9. This seems reasonable.

Remember that this lookup table need be generated only once, and henceforth can be part of the code for the HALGOL package. This means that we need not care about the speed of the code generating the table. In fact, we would probably write such code in WANG 2200 BASIC, store the resulting code on disk as unformatted string array data, and then blow a 2532 EPROM (4K bytes). Then we would carry the EPROM to the Apple and read in the EPROM. This is how we handled our semi-hand-assembled 68000 code early in the history of DTACK.

ADDITIONAL CONSIDERATIONS:

Remember that we are keeping track of the actual number of variables in a particular expression, N, separately. In general, this will be less than MAX. If N is small, how do we 'map into' a table set up for nine variables?

Simple, we reply. We clear a byte before parsing the expression. As we encounter each math operator moving left to right, we shift a zero or one into the least bit position of that byte. This encodes a line such as:

 A = B * C + D

as

 0 0 0 0 0 0 1 0

If we keep track of the number of variables, and quit when we encounter an encoded call for variable #4 when, as in the example above, we only have three variables then we can use a primitive sequence intended for a longer expression for a shorter one.

Now we know the size of our table, the methods of encoding, and the rules for generating a HALGOL primitive sequence. We will let you in on a secret: 'compilation by template' is a Snark. Those of you familiar with Lewis Carrol's "The Hunting of the Snark" will know what we mean. In our next installment we will finish the hunt. That will be issue #21 or #22 as the spirit leads us.

Following is a guest editorial by Steve Heller of Hudson Falls, NY:

Page 6, Column 1

Language Prejudice revisited

I have spent about four years, from 1978 to 1982, writing programs for a relatively large data-base system on a Radio Shack Model III, out of fourteen that I have been a professional programmer. These programs were written in a combination of Basic and Z80 assembly language. I have also used about ten other assemblers, and five or six higher level languages. Both Basic and assembly languages have good features, but they also have some extremely serious defects, some of which I will list below. I have been driven to the conclusion that neither of them is suitable for writing MAINTAINABLE, UNDERSTANDABLE programs that have reasonable performance.

Here are the lists of Basic's strengths and weaknesses. I am assuming that Halgol is like Basic in those areas that have not been covered explicitly. First, the strengths:

B1+. Basic is relatively easy to learn, compared to assembly language. This is mainly because it has a limited set of operations, and few arbitrary restrictions on combining them. For instance, you can add an integer and a floating-point number together, without having to worry about the conversion. Likewise, any arithmetic expression can be used as a subscript of an array.

B2+. A related point is that you can get started easily. There is no need to learn complicated editor or compiler commands initially. You don't even have to type in line numbers, just use it as a calculator at first. This reduces learning anxiety noticeably.

B3+. It does not take a long time to make changes and test them out. This is because it is interpreted, rather than compiled. This aids in debugging, as you can try a number of things quickly.

B4+. The object programs are relatively compact. When you type in a statement in Basic, it is "tokenized" by replacing all of the keywords by one-byte abbreviations which are expanded again when you list or edit the program.

B5+. It is hard to make the system crash by typing in an illegal instruction. In almost all Basics, you will get a relatively meaningful error message, such as "Array subscript out of bounds in 30322", or at least a numeric code that you can look up in a table. You will rarely or never get a screen full of garbage or a monitor prompt which leaves you baffled. Note: this does not apply to Applesoft Basic, which can

Page 6, Column 2

easily be crashed unintentionally. Applesoft is one of the most primitive of Basics available today, for this and many other reasons.

B6+. You can stop execution of the program at any convenient point and examine and change variables, and restart at the same or a different point. Note, however, that you usually cannot alter the program and expect to continue, although there is no very good reason why not. Some Basics do allow this.

B7+. Variable-length strings are supported. This is a great advance over Pascal or Forth (at least in the FIG model), since they are very useful for commercial use, such as for names and addresses. Also, the set of functions that apply to these strings is quite good.

Now for the bad news. I am omitting from the list of Basic's weaknesses any that have been addressed in Halgol, to my knowledge:

B1-. There are no local variables in Basic. This makes it nearly impossible to develop a library of commonly useful subroutines, since there is no way of keeping variable use in them from interfering with that in the main programs to which they would be appended.

B2-. Subroutines have other problems, too. They cannot take explicit arguments, and cannot return explicit results. The subroutine and the main program must agree on the names of the variables to be used to pass arguments and results.

B3-. File handling is very awkward in Basic. Usually you are limited to 255 or 256 byte records, and all of the allocation and storage is up to the programmer. Even if different record sizes are available, all of the records in a given file must be the same length. I am limiting the discussion here to random-access files, since sequential files are virtually useless for most commercial work, large computer practice to the contrary notwithstanding. The baroque ways that have been devised to map variables onto the file buffers have nothing to recommend them, other than the ease of implementing them.

B4-. The set of pre-defined operations cannot be extended without a large amount of effort in assembly language. You are stuck with whatever the implementors produced.

B5-. Arithmetic operations, other than integer ones, such as counting, etc. are done in floating-point. This guarantees that there will be great difficulty in getting the accounts-receivable to add up to the

Page 7, Column 1

penny, even if the rounding routines are sophisticated enough to fool the casual user into believing that his numbers are stored exactly, which they are not. I realize that this objection is not considered important by engineers, but most programmers are not writing engineering programs.

B6-. One of the most unfortunate drawbacks of Basic is that it is NOT a language at all, but rather hundreds of different languages, one or more for each type of computer that has been produced. This means that you do not simply have to deal with the quirks and oddities of ONE language, but rather with those of all of these variants. Of course, this also means that some of the other objections that I raise may be answered by one or more of the myriad dialects of Basic, but those versions probably have other problems of their own. Only the lack of higher-level extensibility is an inherent characteristic of the language. In any event, the lack of standardization means that it is impossible to write a program in "Basic" and have it run on any other machine than the one on which it was written, even if the other machine uses a Basic that was written by the same company!

How about assembly language, then? First, the strengths:

A1+. You can do anything that the machine is capable of doing. For example, there are no arbitrary restrictions on memory usage, and you can use whatever data structures you can construct.

A2+. It is fast, again, because you are working with the machine itself, and not with a superimposed structure.

A3+. The programs are reasonably short, compared to object programs that are produced by a native-code compiler.

Now, the weaknesses:

A1-. You most create whatever data structures you want to use. For example, since most microprocessors do not have string variables or instructions for handling such variables, you must write them yourself, or get them from someone else. In the latter case, you are dependent on the skill of that other programmer, and you have to bend your code to conform to his conception of what is desirable in this area.

A2-. The programs are MUCH harder to debug than those written in a reasonably friendly higher-level language, since they are executed directly on the hardware. There is no "immediate" mode to help, nor

Page 7, Column 2

anything like a trace. To be sure, these facilities are usually not very good in Basic, but that doesn't mean that they can't be quite well done, if the language designer is interested in them. Even the simple ability to interrupt a program and examine and change variables, and then continue, is a great help in debugging. Also, if the program fails, it is likely to do so in a spectacular manner, and certainly will not tell you what happened or where, in contrast to most Basics, for example.

A3-. The object programs are considerably larger than Forth, or even interpreted Basic, programs. Those are, of course, compiled into "pseudo-code", which takes 8 or 16 bits per "instruction", each of which represents many machine-language instructions.

A4-. The programs are MUCH harder to understand than higher-level language programs, in general. The enormous range of possible combinations of instructions, each of which does an incredibly tiny piece of the final task, is an excellent means for confusing everyone, including the programmer who wrote it in the first place. The fact that it takes hundreds (or thousands) of machine-language instructions to do the task of a few lines of Basic or Pascal should indicate the great possibilities for error.

A5-. Every processor has a different assembly language. This means that there is no relatively easy way to transport your programs from one machine to another, and still get reasonable performance on the new machine. You could, of course, use emulation, but the increase in overhead is unacceptable for most applications. For example, there is a microcomputer data-base program that is run in emulated 370 code. It runs only a little slower than interpreted Basic!

What is my solution to these problems? Well, it seems to me that what you want to do is to combine the strengths of assembly language (flexibility, speed), with those of a high-level language (maintainability, ease of writing programs). In order to do these it seems that you must write in a mixture of assembler and higher-level. A nice way to do that would be to have a set of assembly language subroutines that would do all of the primitive operations that are needed in the application that you are interested in, and a higher-level language that lets you define new operations in terms of those already existing.

That sounds a lot like Forth, doesn't it? Not really, because Forth, as has been discussed in the letters column of this newsletter, is a kit, not a real language. If you could get an extensible language that had all of the built-in functions needed to write real programs in a given field (such as

Page 8, Column 1

commercial programming, which accounts for only 85% or so of the programming that is being done on microcomputers, if you discount rock-shooting), then you would have something. I do not claim that this language must use RPN, only that it be extensible, fast, and come with the necessary primitives, so that the poor applications programmer doesn't have to spend three months generating extensions to the language before he can start writing programs. The Forth attitude of "Do it yourself", in addition to being frustrating to the applications programmer for the above reason, is counterproductive because it means that every programmer will have a different set of operators to do the same tasks, which prevents any exchange between them.

To digress for a moment, I would like to say something about the relative merits of RPN and algebraic notation. I certainly would be the first to admit that, everything else being equal, I prefer algebraic to RPN. Unfortunately, there are a number of things that are not equal. First, there is the fact that it is MUCH easier to write a compiler to compile RPN than it is to write one to convert algebraic to RPN, and then compile that, which is the easiest way to compile an algebraic language. If that were the only objection to algebraic, then I would probably go with it anyway. However, it has a much more serious drawback, which is that it is too limiting. RPN allows you to create functions that have any number of arguments and any number of results. This is impossible in an infix language, as far as I know. If I am wrong, then I would appreciate being enlightened.

A number of people have an antipathy to RPN, although clearly not everyone, since there are quite a few Forth programmers, not to mention the hundreds of thousands of HP calculators that use RPN. At this point, it would be appropriate to answer the question of how to rewrite the following expression in RPN; since Forth is just one example of an RPN language, it would probably be better to avoid mixing up its problems with the ones inherent in RPN.

 LET Y = A * X * X * X + B * X * X + C * X + D

The RPN language that I am using has genuine variables, which do not require "@" and "!" in order to use them. This approach was suggested in the article "The TO solution" from Forth Dimensions magazine, volume 1, number 4, July 1979. Here goes:

 X X X * * A *   X X * B *   X C *   D    + + +  ->  Y

I do not consider this to be particularly difficult to understand, but then maybe I'm weird.

Page 8, Column 2

To get back to the question of a better language, it would also be very good if this language was portable to many other microcomputers. In answer to the statement that Halgol is not portable, because that would cripple its abilities, which are based on the 68000 architecture, I would point out that a language is supposed to be designed for the benefit of the programmers who will use it, not for ease of implementation. Also, the fact that any stored-program digital computer is capable of running any program that any other such machine is capable of running (with the exceptions of time constraints and memory size), should indicate that it would be possible to port Halgol onto ANY other machine that had reasonable performance, even 8-bit machines (!). If Halgol is as good as is claimed by its writer, it should be just the thing on the Z80 and 6502, as well, although obviously it would not be as fast.

In conclusion, I do not believe that the last word has been spoken on the great language debate, nor will it be for the foreseeable future. However, the trend toward larger programs and faster processors clearly is on the side of the high-level languages, and I expect to see some new entries in that area that will eliminate some of the serious problems with the currently available choices.

ZILOG WATCH:

Since most of you do not watch the 'sand baking' industry closely you will not have noticed that Zilog has just experienced a major management shuffle. The new management arrangement draws sharp distinctions between the anointed members of the inner circle, which is involved exclusively with products which exist, and the unwashed, who are involved with future products which will, of course, exist some day eventually manana. Such as the 32-bit Z80000 and even the super-8-bit Z800. We do not know whether the desks of the unwashed are now located over trap doors. You see, before this management reorganization there were persons whose responsibilities included both extant products and the stuff which really is, of course, coming down the line.

If you read paragraph #2 of page 10 of newsletter 11, you will be aware that Zilog originated over a (losing) argument over whether assembly language mnemonics should include both LOAD and STORE (LD, ST) or just MOVE. That argument has resulted in EXXON losing an enormous amount of money over the past few years. Now, everyone expects a high-tech startup to lose money at first but everyone also expects the startup to eventually show a profit. Zilog is getting long in the

Page 9, Column 1

tooth and has never shown anything remotely approximating a profit. We cannot tell you what their recent losses are. EXXON became embarrassed over the high and continuing losses of Zilog and folded them into a larger subsidiary so that they (EXXON) were not legally required to continue reporting ZILOG's substantial losses.

With the recent management reorganization ZILOG can be easily trimmed into a leaner, potentially profitable organization by merely yanking the lever connected to the trap-door which we suspect is located under the desks of the unwashed. It is an absolute requirement that EXXON pull that lever themselves before they will be able to sell ZILOG to another organization. (You do understand that a buyer would want to purchase an outfit that had already been trimmed down, don't you? It's like this: any organization that lays off a lot of long-time employees is going to be unpopular. Therefore EXXON should lay off those employees since EXXON's unpopularity will be irrelevant once a new owner takes over. There are other financial reasons which we will not bore you with.)

If EXXON sells ZILOG the company may need a new name. How does Commodore West strike you?

ABOUT SIMON BASIC:

We asserted earlier that sales of the '64' are now production limited. What evidence do we have of this? Well, how about Simon BASIC for starters? You don't know about Simon BASIC? That is a software package sold in Britain for the '64' which provides 154, count 'em, 154 additional commands (keywords). The price is 50 pounds which is about $65. If you have a '64' and you wish to write some programs yourself this package is, or should be, indispensible.

Who, you may ask, offers this package for sale in Britain and why can't you purchase it in this country? An obscure outfit called Commodore sells Simon BASIC in Britain! The reason you cannot purchase it in this

country (in our opinion) is that it would make the '64' much more attractive to buy, to the possible detriment of sales of other Commodore models. The '64's told in Britain are not made in the same factories as those sold in the U.S., which explains the difference in sales policies.

We know more about Simon BASIC than we otherwise might because a friend in England was nice enough to send us a copy, which we received yesterday (Apr 23). What you get is a floppy disk and a rather thick manual which seems, on short notice, to be well organized and thorough.

Page 9, Column 2

OUT OF BUSINESS!

Well, we knew somebody would eventually come along with a better mousetrap and put us out of business. Someone forwarded to us a photocopy of Acorn's brochure and gadzooks! Not only does that 68000 based product have a 16MHz clock, it operates at 8 MIPS! That assertion is repeated three times, so it isn't a misprint. We wonder if Sage has heard about this?

Well, it was fun while it lasted, folks. Incidentally, the 8MIPS Acorn is compatible with UNIX and C. It is also "Compatible with Compilers and 6502 Assemblies (sic)." Says so right there in the brochure.

THIEVING WEST GERMANS:

No, not all W. Germans are thieves but we know of one bunch in Berlin because they stole from us. We are referring to Computersystems Und Software GmbH, which is located at Nassauische Str. 58, 1000 Berlin 31. They sent us a check for $25, which we received on Nov. 17 '82. In exchange we sent them newsletters #12 thru #17. Almost immediately after we mailed #17, they had their bank send our bank a notice that we had not "sent the goods", and withdrew the $25 from our bank through the international banking system. This banking transaction took place on Mar 2 '83 at our end.

So your moderate, easygoing FNE sent them a letter which opened "Congratulations! Your company has just stolen $25.00 from our company." and concluded, "...I am going to put the name and address of your company in (the) newsletter and I am going to brand you a thief. Yours very sincerely indeed,"

We received back a memo on C + S letterhead pointing out that they had paid for the newsletter, and enclosed a copy of the cancelled check as proof. The signature was F W Binns, or maybe Bonns. We sent a letter back pointing out that we knew he had paid us initially, but that we were P.O.'d (does not stand for Post Office) that they stole the $25 back after we sent the newsletters. Incidentally, the reply implicitly proves that they did receive the newsletters.

We then offered the thieving S.O.B.s an opportunity to rectify the situation, repeating our threat. By rectify, we of course meant to repay the $25 through the international banking system so as to clear our good name with our bank. As you can see, those S.O.B.s have not done that.

We are enclosing copies of the relevant correspondence and the bank order with this newsletter to our dozen or so W. German subscribers so they can see the truth of this story. Did we ever tell you that your FNE is not a nice person?

Page 10, Column 1

WE GET MAIL:

"I ran across a very interesting and well written book a few months ago. From your HALGOL theory, I could swear you have read it. The similarities are astonishing. The book is 'Writing Interactive Compilers and Interpreters,' by P. J. Brown of the computing laboratory, University of Kent at Canturbury. The publisher is John Wiley & Sons." Mark P., Bloomington MN

We had been unaware of that book until now, Mark. We would agree that it is a good book (we assert modestly) if it bears strong similarities to HALGOL. Did you notice that the author is British? The British are such more inclined to favor things which work well rather than things which have a 'correct' theoretical base. An example of this is Oliver Heaviside's operational calculus, known as the La Place transform in this country.

Oliver was an engineer who wanted simple methods of solving complex problems. In devising his operational calculus, he took certain shortcuts which horrified mathematicians, who abhored the lack of rigor in his methods. The frenchman La Place eliminated the shortcuts (which worked, worked correctly and worked well, by the way) and put his own name on the mathematical process. In the U.S. La Place transforms are taught, using the 's' operator.

In Great Britain the (useful and correct) shortcuts have been retained and the original operational calculus is taught, using the 'p' operator. Although we picked up some British texts somehow early in our career, we quickly learned not to use operational calculus in a college or university environment for the same reason that students in certain American universities today dare not use the GOTO statement.

We applaud the willingness of the British to espouse things which work well and deplore the unwillingness of American academicians to acknowledge things which work well, whither or not a conventionally 'correct' theoretical basis can be identified.

Now, regarding the book: we believe we will forego purchasing and studying that book right now, since we believe we have a good idea how to pursue HALGOL already. If you see us drifting off into some quagmire better handled by methods in Brown's book, we would appreciate it if you would get in touch with us.

Mark adds, "Why aren't there any other 68K systems out running as fast as yours?" Those other folks are hung up on transportability rather than efficiency, Mark. They would rather have a transportable super-spreadsheet which requires over a minute to perform a

Page 10, Column 2

common function than an untransportable version which performs the same function in two seconds.

We also care about transportability, but only within the 68XXX family of microprocessors. We believe this is the family which will provide superior performance for single-user single-tasking computers for at least the next five years (our crystal ball has not been calibrated beyond 1988). And, the family will remain software upward compatible because Motorola took the necessary step to bury 8-bit architecture with the introduction of the 68000.

We acknowledge that Intel has done a superb job of providing a microprocessor, the 80286, which will service a large number of terminals (each operator restricted to 64K) better than the Motorola family. We also acknowledge that National will eventually (once they get their parts up to the advertised 10MHz speed) have a part which is superior to the 68000 (but not the 68010) in multitasking and also superior at running conventionally programmed COBOL compilers.

(If you like COBOL, you should be elsewhere.)

Take another look at the front page of this newsletter, guys and gals: that is a megabyte! A full gallon! And we are offering this to persons, hopefully including yourself, who would like to keep that all for your own exclusive use. Given your own private megabyte, what could be better than a 68000L12 to work with that memory? O.K., so a 16MHz 68020 would be better! You can't buy one yet. But you can transport your 60000 software when the time comes...

Regular correspondent Nils D. writes: "Ever hear of Educational Microcomputer Systems in Irvine? They sell bare boards with documentation... starting at $99.95" While we see their small ad regularly in BYTE and elsewhere, we have never heard from anyone who actually has one. We would be greatly pleased to hear from an owner of that system. We would be even more pleased to recieve an independent (from the manufacturer) review for publication here. We would even like to be informed of a review published elsewhere.

Our board exists, it works, and some useful software is surfacing for it. Our board has been reviewed in Peelings II, Micro and even in Creative Computing. Not one of the other 68000 boards which people keep asking us about has ever been reviewed in those or similar magazines, to our knowledge. We wonder why?

And as to your hint that some of our earlier policies have changed, Nils, you are correct! Why? Well, you might try reading newsletter #12, page 12, column two

Page 11, Column 1

for instance. But you seem to be primarily referring to our suggestion in newsletter #10 that we build a cheaper board, said cheapness being accomplished by leaving off expansion capability among other things. You might be interested to know that that trial balloon caused us to get lots of mail, unanimously (at the time) rejecting the idea of a board with no expansion capability.

Prudent companies do respond to market pressures, Nils. (We may get that EMS review yet, Nils has since written that he is buying one to interface to a VIC-20. He's not kidding ... we think.)

"...enclosing a new version of the monitor I wrote. The original was sent to about 30 interested souls including four in W. Germany and only two in California (?) ...this monitor repairs all the known faults. It is designed to be resident in the RAMcard and has several new features ...I want to offer it at $10 (U.S. funds) anywhere except to those who bought the first version; $5 to them so I don't take advantage of 'test pilots'. This monitor is still in the public domain."

P W Soule
969 Via Del Monte
Palos Verdes Estates
CA, 90274

Pete, we are not surprised about the W. Germany/CA interest ratio although we have many more customers in CA. The (highly subversive) West Germans take their 68000 stuff seriously but many of our CA customers are (evidently) too busy watching Gilligan's Island re-runs. Obviously, you and Bruce Walker do not fall into that category.

Those of you who are not familiar with Pete and his monitor should review newsletter #17, pages 13 thru 16. We don't have room to print the revised instructions because they are now up to 9 pages.

Pete also wrote: "I saw a cartoon of a Hell's Angel-type biker with a leather jacket bearing the motto:

"BORN TO LOOSE"

"Could have used your word processor."

Pete, you will remember that criticism of your FNE is verboten in these pages. Otherwise we might reveal that you spelled 'W. Germany' as "W.Geramy".

Page 11, Column 2

"...are you suggesting that all programs, even applications programs, be written in assembly language?" Steve H, Hudson Falls NY

Not at all, Steve. The programs which should be written in assembly languages are:

1. High level languages (obviously, we hope).
2. Any time-critical code, especially stuff that reacts interactively with the real world (generally called real-time).
3. Any frequently-used utility where the difference in operating speed between assembly language and high-level stuff can be easily perceived. Operating systems, for instance. Word processors (8-bit division). Games (especially!). Graphics primitives, graphics not-so-primitive.
4. Any program where the use of assembly language can gain one a competitive advantage in the marketplace. For instance, the super-speadsheet 1-2-3.

Let's talk about 1-2-3 for a bit. We saw a large ad in the L.A. Times this past week pointing out that Context/MBA runs five times faster on the HP Series 200 Model 16 than it does on the IBM PC. That program can run on both an 8088 and a 68000-based machine because it is written in Pascal and is therefore portable. The H.P. ad, nearly a full page, pointed out that a particular function which required 2 1/2 minutes on the IBM PC ran in only 30 seconds on the Model 16. Of course, 1-2-3, which is written in assembly language, would perform the same function in two or three seconds on the slow IBM machine!

1-2-3 is drawing rave reviews from the PC-related magazines! It has been featured on the cover of at least four of these magazines despite the newness of the program and magazine leadtimes! In the vernacular, it has completely blown the MBA program out of the water with respect to sales to PC owners.

But it is not transportable to Model 16 owners, you say? Friends, we ask you: is the total number of business managers who have bought H.P. Model 16s instead of IBM PCs greater or less than twenty?

1-2-3 is an enormous financial success. It goes for $500 and is the largest selling IBM PC software program, period. So what advantages does it have over MBA aside from speed? None. Do what we did: buy some PC-related mags and read the reviews! Even Microcomputing (formerly Kilobaud), which is not a PC-related publication, has 1-2-3 featured on the cover of its May issue.

Page 12, Column 1

On page 63, we learn that "Regarding speed, there is no contest. 1-2-3 is awesome... compared to 1-2-3, almost anything is slow." The closing lines of that review: "I started out ambivalent-even somewhat skeptical-of 1-2-3. After all, I've worked with MBA for a year, and I like it. But I think I'm coming to love 1-2-3."

Is it clear to everyone that the popularity of 1-2-3 is due to one factor, and one factor only? The blinding speed of assembly language programming? How many of you reading this are aware of just how many sales are required to be the absolute sales leader for all categories of IBM PC software programs? Take that many sales over a one month period, multiply by $250 to $300 and you will know what the income of the authors is for one month's sales! Multiply that by twelve to get the yearly income.

(This may be the first IBM PC assembly language program to be really, honestly written in 8086 code, not translated from 8080 code. And an equivalent program written for a 12.5MHz DTACK board would run about five times faster, meaning the response time would be in the half-second range.)

We have a complaint. Our complaint is with the computer science folks. Our complaint is that they do not sees to care whether a particular program ever runs to completion. That is why they like p-code Pascal.

Is there any reader out there, computer science type or no, who does not have a tee-niny greedy bone in his or her makeup? Surely the above alerted you to the possible financial advantages of assembly language? What's that? You aren't greedy? And you love transportable Pascal? Do you realize that it is people like you who can absolutely ruin a newsletter editor's day?

OBSCENITY WATCH:

It is an undeniable fact that your FNE would never qualify as a deacon and would most certainly never seek a position as a censor. Nevertheless, we do self-censor this newsletter. Our guiding rule is that there is absolutely no, repeat no, Anglo-Saxon (or more recent) word that we will not use in this newsletter. We do, however, require that the circumstances require the use of the A-S term in question. You will, for instance, find the word 'hell' in this issue. In our opinion, its use (in context) is appropriate.

We are aware that there are a few 'little old ladies' (of whatever age or gender) who object to this.

Page 12, Column 2

This brings us to am private correspondence with someone who: A) Lived thru the Truman administration. Truman, while in office, called a music critic an S.O.B. without bothering to use the initials. The President of the United States actually inferred that the immediate maternal ancestor of the critic was a real dog (not just an unattractive blind date), and B) is a fan of Robert A. Heinlein, and is therefore well aware that frontier societies pay no attention to a certain 'official' document. In this regard, we cite Heinlein's books "Tunnel in the Sky", "The Moon is a Harsh Mistress" and "Time Enough for Love".

So when we wrote this person a private note asking, "When are you going to (take desirable action), you XXXXXXX" it never occurred to us that he would take offense. (By calling him an XXXXXXX, we implied the absence of a certain official document, no more.) Is not the pursuit of knowledge about the 68000 a frontier of sorts?

Despite the fact that we reserve the right to make the full use of the English language, we trust that most of you will agree that we use, and will continue to use, this right judiciously...

"In newsletter #19 you implied that virtual memory always exceeded real main memory. This is normally, but not always, the case. The amount of virtual memory is determined by the address space of the computer; the amount of real main memory by your pocketbook. Normally, when computer architects start designing, they lay out an address space 'larger than anybody can buy.' They may, then, add virtual memory software and hardware to make it appear that the whole address space is in main memory.

"In the case of the IBM 360, more memory than 'anyone could possibly buy' was set at 24 bits, or 16 megabytes (number seems familiar-FNE). Remember that these decisions mere made in the early 1960's, when the biggest computer around was an IBM 7094 with (the equivalent of) 147K bytes. However, in the intervening 20 years memory prices have dropped so much that IBM (and plug compatible manufacturers, such as Amdahl and Fujitsu) now routinely ship large mainframes with more than 16 megabytes. The operating system makes use of the extra memory in the same way that Apples with more than 64K use the extra memory, by bank switching.

"Users have raised their expectations too, so that 16 megabytes is now constraining them. (The current project that I am on is overlaying the program because it won't fit in 16 megabytes!) Consequently, IBM has this year announced a new operating system, MVS/XAA and the microcode changes to go with it, to support 31 bit

Page 13, Column 1

addressing. There are 26 new or changed instructions, according to an Amdahl spokesperson. I don't have the details on what those are. The change to 31 bit addressing is very recent though; I believe that MVS/XA is still in beta testing."

Bruce Walker
San Pedro, CA

We think that a virtual memory system which is smaller than the real memory is, well, words fail us, Bruce.

The most amazing things happen when people think one is willing to tell the truth (small t division) in one's publication. For instance, we recently received the following via carrier pidgeon:

"The Intel 8088 Handbook:

"A MOV to segment register instruction and a POP segment register instruction are treated similarly: no interrupt is recognized until after the following instruction.

"This mechanism protects a program that is changing to a new stack by updating SS and SP. If an interrupt were recognized after SS has been changed, but before SP had been altered, the processor would push the flags, CS and IP into the wrong area of memory.

"The Facts:

"Well, surprise surprise! 8088 parts which bear a 76 copyright in fact PERMIT an interrupt during a MOV SS... MOV SP sequence. Newer parts, bearing a 78,81 copyright date have this bug fixed.

"Since the newer part was first available in mid 1982, essentially all the IBM PCs in the field have a bad 8088.

"Discovering such a problem (which occurs intermittently, and only on certain machines) is painful enough. But the interesting predicament is the question of how to deal with these hundreds of thousands of "bad parts" installed in all kinds of hardware. Obviously any sane programmer must now protect any stack changes by disabling interrupts, else the program will malfunction. But this is exactly CONTRARY to the proud claims in the Intel Handbook. And you don't think that this problem might be described somewhere, so you might be forewarned, do you?

"Intel and its vendors are not prepared to recall all chips from the field; therefore it is DANGEROUS to

Page 13, Column 2

leave such a misleading statement in the 8086 Handbook. It is possible to imagine that someday a real-time system, programmed according to the Book will suddenly malfunction, due to a coincidence in interrupt timing and instruction sequencing. Who will be liable?

"P.S. Intel already dealt with precisely the same bug in the early 8086 parts, so it wasn't an unknown issue!'

We checked this out unofficially with an Intel person and learned that the mask correction was done late in 1981. That pretty such agrees with a mid-1992 change at the retail level. Does anybody remember the third classified ad on the back page of our June, '82 newsletter (#10)?

Look, the question of whether IBM has any integrity has already been answered. They don't. That's why they can ship tens of thousands (if not hundreds of thousands) of business computers which have math errors by a factor of ten and recommend that its customers use those computers in banking applications. We see no indication that IBM ever intends to fix those problems.

"...you seem to read your mail, so the views of us members of the great semi-washed must be of some marginal interest to you... there is next to nothing in the way of transportable software published in FORTH... try out the Epson QX-10 in the word processing mode. A Z80 running the VALDOCS system in FORTH cannot keep up with us slow typists getting text to the screen. The last time I saw that was with a text editor I wrote in BASIC." Jeffrey H, Camp Lejeune, NC

Jeffrey, it is important for someone who is in the Navy to understand rank. The 'anointed' are those who have purchased a DTACK board. The 'washed' subscribe to this newsletter so you have an instant promotion. The 'semi-washed' are those who receive this newsletter by photocopy or who otherwise can be considered in the 68000 personal computer camp, even if they don't know about us. The 'unwashed' are firmly in the camps of competing microprocessors, such as Intels', Nationals', T.I.s' etc. The 'unspeakable' are trying to chain you and 31 of your associates to a multi-user system. We have failed to come up with an appropriate descriptor for those who are using the iAPX432 to write tic-tac-toe algorithms.

FORTH is much more transportable than PASCAL. UCSD PASCAL (Apple) is incompatible with UCSD PASCAL (Softech)! The Epson scoop is news to us. Who has FORTH running on the Epson? Why is it that slow?

Page 14, Column 1

"...I have never read an editorial in any computer mag. so egotistical, opinionated and downright truthful... although I don't always agree with you, I found it to be enlightening and quite stimulating, to the point that I take more notice of the articles I read now, not accepting them as the truth just because they are in print." Martin C, Dhahran, Saudi Arabia

Egotistical? Opinionated?

"I am still very interested in the dynamic RAM version of your board but I haven't seen much about it recently. Now about your comments about a great graphics capability using the NEC 7220 chip? Since the main reason for getting an Apple in the first place was its superior graphics (I bought it in 1979), the use of a 7220 seems like a super idea.

"What happened to your idea for 8 68000's on a peripheral board? Is this project still active? The best use I could see for it would be in the 3-D graphics area, where you could stack all objects to be processed and then assign a 68000 to process one. This would allow objects to respond by (appx) 8X faster." Lon B, APO 'Frisco

Lon, we hate to get letters like yours. You can see more about our dynamic RAM version on the front cover. You will have to wait until newsletter #21 to find out about the great graphics. The multi-68000 design has not yet actually begun. Why didn't you ask about the Stuffer board? At least that one is actually in production.

The reason a hate to get letters like yours is that many of our readers are going to think that it is a fake. Anybody who would like to see Lon's letter can, during regular business hours. Look for a handwritten page out of a spiral binder in DTACK correspondence file #21. We mounted it backwards and have marked it with a big red "X".

And yes, that is correspondence file #21. We get lots of mail.

A few pages back, we told you how well an assembly-language program called 1-2-3 was doing in the marketplace. We have just received the May issue of Softalk (for the IBM PC) magazine. 1-2-3 is now outselling the absolute second-place program (WordStar) by 2.3 to 1! And it is outselling Context's MBA by over 16 to 1! Does everyone realize that these sales figures are for the month of March, which was before 1-2-3 made the front page of all those magazines?

Page 14, Column 2

Wait until you see what the sales figures are for this assembly-language program now, which will be reported in the July issue of Softalk (IBM section). Us folks here at DTACK (well, Digital Acoustics, Inc.) are hoping that this will mark the beginning of an industry awareness of the very real advantages of assembly language programming. Make that a general industry awareness.

"You no doubt saw the article in May '83 BYTE entitled "Sorting Algorithms for Microcomputers" by Terry Barron. When I read it and tried out the Applesoft examples and seeing how it compared to other computers with compiled languages, I decided that it would be interesting to see what the 68000 could do.

"Pascal provides a somewhat better comparison because it uses 16 bit integers (the size I used for the 68000 example). I have included the source listing for both the Pascal and 68000 programs (using a very faint ink ribbon - FNE). I make no claims as to the randomness of the very simple "Random Number Generator" I devised, but the numbers are definitely unordered before sorting and in correct order after, so I hope this comparison is accurate.

"My results for the three languages are as follows: Pascal was 8 times faster than Applesoft, while the 68000 assembly language programs was 4,271 times faster than Applesoft." Andy S, Laurel MD

It's as simple as 1-2-3, Andy. Now, about that ribbon...

"I am writing you of my progress on the project you code named BLUE SKY ONE. I have been able to implement the basic concept in a dual Forth environment. The fast disk routines will read and write RWTS type Forth screens in my 68000 Forth system (independently written and not the same as Bruce Walker's - FNE). I have a 48K Apple II+ and a 12.5MHz 92K Dtack board. Although the routines are in a Forth system, they are written in 95% pure machine code for both processors with about 3% Forth glue to hold things together. This fact should make it easier to adapt the work to other applications, such as HALGOL DOS. The code at this point is still a bit experimental with the read routine working quite well, but the write routine needs more work to bring it up to the required performance level.

"Here are read routine benchmarks:

"1. The Forth word ": READ.DISK 140 0 DO I BLOCK DROP LOOP ;" will read all the sectors on a 5 1/4 DOS 3.3

Page 15, Column 1

disk, loading 1024 bytes into one of the Forth buffers. The routine is useless by itself but serves to illustrate the speed at which data is being read, denibbilized, and stored in memory.

 System                               time 
 6502 Forth on Apple                  1:42 
 68K Forth with normal DOS            1:34 
 68K Forth with fast DOS               :10

"As shown above this is not processor intensive, so it is a good example of how I/O bound the 68000 is with normal DOS operation.

"2. Loading and compiling a large Forth program ("Forth Programming Aids" by Curry Associates. This program is over 100 screens in length:

 System                               time 
 6502 Forth on Apple                  4:59 
 68K Forth with normal DOS            1:27 
 68K Forth with fast DOS               :29

"This example shows why every Forth addict should buy a Dtack board (Jack, we write the ads around here, O.K.? - FNE). The 6502 has to work very hard while the 68000 just sits by and compiles everything with a speed comparable to the disk access time. However, when we speed up DOS things really cook.

"3. Loading and compiling 'A Forth Cross-compiler' by Nautilus Systems. This program is 53 screens in length but requires the processor to work harder since it contains a number of <builds does> constructs in the cross-assembler.

 System                               time 
 6502 Forth on Apple                  6:00 
 68K Forth with normal DOS            1:05 
 68K Forth with fast DOS               :45

"The disk actually stops rotating during the loading of parts of this program, showing that speed-up is program dependent.

"The fundamental routines used were written on either information obtained from 'Beneath Apple DOS' or from disassembling RWTS. The basic operation of the read routine is:

1. The 68000 passes track # to the 6502 which then uses the RWTS seek routine to position the head.
2. The 6502 then executes the 'read address' routine to find out which sector is under the head. The physical sector # is then skewed to the logical sector # and and passed to the 68000.

Page 15, Column 2

3. The 68000 takes the logical sector # and applies it to an address lookup table to determine the location of the 342 byte buffer allocated to that sector.
4. The 6502 then reads the data from the data field via a modified 'read data' routine that passes data to the 68000 instead of the 6502 nibble buffer.
5. After the data is in the 68000, a 68000 postnibbilizing routine denibbilizes the data and moves it to the Forth buffer asking for it.

"I would be interested in hearing from anyone else working on or interested in this project. Address your inquiries to:"

Jack Haller
230 Mechanic St.
Boonton, NJ 07005

(201) 843-5800 X6641
(201) 334-0338 (home)

Jack, your 'squatting and howling' society membership is herewith permanently cancelled!

MISCELLANEAE:

In Apr 19 EN on page 6 we find a report that "The chief design engineer of the IBM PC, who was heading the development of a low-end personal computer, left the company last week to join Franklin Computer... as vice president of engineering." In the same issue there is another report on Franklin on page 12: "...sources said its new products may move the firm out of the Apple-compatible-only market and into IBM PC-compatibility as well." Gadzooks! Now amazingly perspicacious that source is!

Will Franklin ever make a Franklin-compatible computer?

In EET, under the headline "Reagan Proposes Tougher Rules On Exports Of High-Tech Products," we find the following:

"...the administration would tighten the existing act by stating that the mere capability of a foreign country to produce items in sufficient quantity and of a comparable quality to those controlled by the U.S. does not constitute foreign availability,"

"Prosecution of violators would be made easier..."

We interpret the above as meaning that Reagan wants to toss your FNE in the pokey if we ship 68000 boards to

Page 16, Column 1

West Germany even though the West Germans are shipping 68000 systems to the U.S. (they really are, you know). Since we really do not want to go to jail, we are going to tread lightly over this export issue. We have already turned down the sly suggestion of one West German that we sell him a 92K board as three 'field service kits'.

They don't even serve Heineken's Special Dark in our Federal prisons, much less Mumm's Extra Dry.

In the same issue of EET, editor Girish Nhatre asserts: "It is unlikely that the world needs another 68000-Unix combination business computer in addition to the 40-odd such beasts in existence, all spawned over the past two years."

Girish, you obviously don't know what you are talking about. We have it on good authority that all 90, not just 40, of the 68K/Unix outfits in Silicon Valley alone are going to be enormously successful. And say: aren't you the guy who doesn't care for Apple Computer's policies? Obviously, you and we do not see eye to eye.

The headline story in the preceeding issue of EET (Apr 11) was entitled "Software Houses Ready Alternatives To Unix For Microprocessors." An opening sentence was "But not all software engineers consider Unix, developed at Bell Labs in the minicomputer environment, as an optimum solution in the microprocessor environment." Hmmm. That appears to remarkably similar to opinions we have been expressing in these pages for the past year (see, for instance, pg 2 of issue #10).

(If you read that story you will discover that 37 vendors are heading in 37 directions, all of which come with a high price tag.)

Unix, which is a superb operating system for full-time computer professionals using adequate hardware, is superb because of 1) the 5 megabytes or so of on-line utilities, and 2) the use of 'pipes' to sequence data from one program to the other. The utilities require a big disk and the 'pipes' require a fast disk. Absent a big disk you don't have the utilities and absent a fast disk you don't have effective 'pipes'. In fact, what you have is an empty paper bag.

You do not have to take our word for this. You can go down to your local Radio Shack dealer and ask to see their 68000-based Model 16, which now comes with Microsoft's XENIX. Ron Jeffries reports that it is 'real' Version 7 UNIX, minus several hundred programs

Page 16, Column 2

(the utilities, of course). Ron also feels that 128K is not enough memory for XENIX.

A few of you may have seen the April '83 issue of IEEE MICRO magazine. It contained a performance comparison of the 8086, Z8000 and the 68000. The performance comparison was limited to the subject of addressing, using block-oriented compiled high-level languages. There were a few errors which you might not have noticed:

1. The author asserted that the 68000 requires 5 clock cycles for a write operation. The correct number is 4, the same as a read operation.
2. The author demoted the performance of the 12.5MHz 68000L12 to 12MHz, stretching the cycle time from 80nsec to 83.3nsec.
3. The author credited the 8086 with 12MHz performance.
4. The author also credited the Z8000 with 12MHz performance.
5. The author restricted the addressing to 16 bits, meaning the entire program and all the variables were restricted to 64K. This will doubtless be of interest to ADA fans and to persons casting covetous glances at the one megabyte DTACK GRANDE on the cover of this newsletter.
6. The author cleverly performed all comparisons on paper, including the above mistakes (of course). A comparison using real hardware would have exposed four of the first five mistakes.

The author concluded that the Z8000 was the best processor to work with high level languages. The fact that the Z8000 has been available for over three years and the 68000 over two years, with nearly unanimous industry consensus that the Z8000 is a nice CPU but not in the same league as the 60000, should have alerted the author that there was a problem or two in his paper calculations.

Have you been wondering what happened to the DEC Rainbow? A reader of ours recently got one of these little jewels in his place of employment, and passed along the following information: if you wish to purchase a Rainbow 100, the CPU, which contains both a Z80 and an 8086, is a component with an associated price. If you would like to have a keyboard, that is another component with another price. You want a CRT?

Page 17, Column 1

That's another component. A dual 5.25 inch floppy drive is another component. An operating system (CP/M) is another component and another $250. You want BASIC? You can have that too. Just fork over the bucks.

However, you cannot have the ability to format disks for your dual floppy drive format. DEC wants you to purchase pre-formatted disks from them at $65 per box of 10. Isn't that wonderful?

Since our reader's employer is taking care of all the considerations which have price tags attached, we asked how the device worked. He (Lyle P. of Los Angeles) stated that he was using it as a DEC terminal emulator, the VT-102 as we recall, into his employer's PDP11/34 and that it worked fine.

MICRO DELIVERY TIMES:

Many of you are doubtless aware that National Semi is forecasting delivery of its 32-bit micro late this year and that Motorola has forecast delivery of their 68020 at about the same time. In the last newsletter we tactfully suggested that you would not wish to hold your breath until the delivery of either device. Here is the way it is:

National still has not yet delivered the 16-bit micro they are advertising, which is a 10MHz unit with no bug list. Motorola was more than two years late delivering both the 6809 and the 68000. (You might want to review newsletter #4, the middle of page 11 and the middle of page 14. That's a year and a half ago, remember!) It has become necessary to lie about when product is going to be delivered in the micro industry. Why? For the simple reason that any company which tells the truth while its competitors lie will be severely disadvantaged.

We have an item from EDN's News Breaks section stapled on the wall beside our desk. The item mentions an exciting now device from Zilog called the Z800. The Z800 would be completely code compatible with the Z80 but run 3 to 5 times faster with equivalent clock speeds due to advanced internal architectural features such as pipelining, instruction prefetch etc. The device would also include multiply and divide instructions. We do not have a date for that News Breaks item but it was asserted that the Z800 would be available in the spring of 1982!

We have beside us another News Breaks item. This one is dated 28 Apr '83 and is on page 15. You guessed it, the Z800 is coming! Parts (i.e. samples) are scheduled to be available late this year. Since 'late this year' can easily become 'early next year', we find ourselves

Page 17, Column 2

in the spring of 1984, two years after the initial delivery date.

Folks, everybody lies in this industry! They have to!

(Incidentally, the Z800 may prove to be permanently delayed if our interpretation of a recent management reorganization at Zilog is correct. This is covered elsewhere in this newsletter.)

How can one determine fact from fiction with regard to when new generation micros will really be delivered? Well, there really isn't a foolproof way of predicting the future, although horse-racing fans try to disprove that assertion every day. We can offer some guidelines, however:

1. Until you can see a magnified photograph of an actual chip (known in the industry as 'first silicon') you cannot be certain that anyone is actually working on the product aside from the advertising department. It is interesting to note that Intel produced posters of the first silicon for the iAPX 286 (the 80286) several months ago but no one has seen photographs of the Z800 or of the Zilog, National or Motorola 32-bit processors.
2. All the 'first silicon' photo does is prove that some engineers are seriously working on the part. It is not necessarily expected to work, and generally it does not work. The next stage occurs when the company publishes a preliminary spec sheet which provides pinouts (i.e. pin 10 is DTACK) and preliminary estimates of power consumption and of bus timing. This indicates that parts exist which sort of work.
3. The next stage is when you read, in journals which are believed to place some emphasis on accuracy, that a few samples are being provided. This means Convair gets one, General Motors gets two, but Digital Acoustics can't got one yet. About three months after this, Digital Acoustics can get a sample - one - with a bug list. (We are at this exact point right now with the National math chip.)
(Sometimes companies will sell their engineering samples. We understand that the Intel 286 can now be purchased in a 6MHz ES version with a bug list, if Intel thinks you 'qualify'.

4. The first stage at which most of you should start paying attention to a part is when you can walk into your local distributer, plunk (lotsa) money down on the counter and walk out with a real chip which does not have a bug list. The Motorola 68000 reached this point in Nov 1980. The time from 'first silicon' to here can

Page 18, Column 1

be two years. For the Intel math chip it was more than two years, but then the 8087 was an enormously complex part for its time.

It was almost a year ago that a grinning teenager walked into the front door of our shop and demanded to see our prototype 68020 board! Honest! And more lately we have been recieving lots of inquiries about the 68020. Friends, Motorola hasn't seen first silicon on the 68020 yet.

Please do not misunderstand us. We are enormously pleased that Motorola is going to make the 68020 (they will!). We wish it were available today, but it ain't. We are not trying to make the Motorola folks look foolish by pointing out that you are not going to be able to purchase a 68020 late this year or early next year. Perhaps Motorola plans to see 'first silicon'?

Digital Acoustics will offer a 68020 board for sale approximately two seconds ater it reaches stage 4. That is 49 weeks faster than we reached the marketplace with the 68000.

If you expect the 68020 to reach stage 4 earlier than late '84 or early '85 then you know something we don't.

Micro magazine has just done it to us again, and they did not even offer us a cigarette afterwards. On page 126 of their May issue they ran that old ad for the seventh consecutive time! The problem appears to be associated with the magazine's new publisher, or rather with the new publisher's personnel. You should not expect to see ads for DTACK products in future issues of Micro magazine.

If you wish to see our new ad, which was written on Feb 10 '83 (publishing lead times, you know) either check out Peelings II, Nibble, Call Apple or else write us for a copy.

In that ad, we asserted that 68000 programmers may be more employable in the future than programmers of 8-bit machines. Cal Comp has a sign (almost) overhanging I-5 (the Santa Ana freeway) near Disneyland West asking for 68000 programmers right now!

May's Micro magazine does have a brief mention of the DTACK board, on page 26. We politely suggest that they have not invested a great deal of time familiarizing themselves with the DTACK board. To add insult to injury, they misspelled our name. A writeup on the Apple III immediately followed... cut out that laughing, you guys!

Page 18, Column 2

For the record, we did inform Micro magazine of its goof in the April issue, when they erroneously printed that old ad for the sixth time. The new folks don't listen too well, it seems.

You might be interested to know that this issue, which has a fair amount of 16-bit related stuff, has an editorial stating that future issues will contain "advanced information on the VIC-20." That's what we like, a tightly focussed editorial policy!

The P-500 (which is being sold in the L.A. area) has been renamed the 'Commodore 128'. In Ron Jeffrie's newsletter, he states: "...Commodore dealers have started getting early production models of the new Commodore 128. There's just one problem: the invoices are stamped 'Not For Resale'. Why? Maybe it's because the user documentation is incomplete, the cassette ports don't always work, or the power cords are missing."

Ron, Commodore's user documentation is always incomplete. The reason for the 'Not For Resale' stamp is that the unit doesn't meet the FCC EMI requirements yet, and this is Commodore's way of covering their fanny with the FCC.

What happened was, Jack Trameil came back from Europe enthused over the reception of the 128 and had his west coast factory run off 500 of them without checking with his engineers. That was somewhat premature because the CRT controller can trash memory that the CPU is working on, among other reasons like the EMI problem. It was also surprising because Jack almost always checks with his engineers before taking action. (Where is that small bull symbol stamp?)

Lest you think we are picking on Ron, you should know that in the previous issue, over a month back, Ron correctly analyzed the prospects of those companies who are taking a piggyback ride on the IBM PC. This week's issue of EN has just gotten around to publishing something on that, and they did not do as good a job as Ron did. We are referring to EN's May 9 issue, p.20. Their story is headlined, "Desktop Rivals Follow IMB's Move." IMB? Come on, EN!

If you are interested in Ron's newsletter (The Jeffries Report), call (805) 967-7167. Remember, that's west coast time. Ron's newsletter has the further advantage that it takes less time to read than ours.

InfoWorld (May 30) carries an interview with George Morrow. Many of you Apple or Pet types may not know of George because he hails from 8080/S-100 land. Unlike

Page 19, Column 1

your unassuming FNE, George is opinionated and outspoken. He was one of the first to predict the ignoble failure of Osborne's portable computer startup.

George was right in a sense; the Osborne is a failure as a portable computer. A survey has shown that 95% of the many buyers of the Osborne do not give a rat's hindquarters about the portability of that computer. What they bought was the integrated hardware/software package.

Our opinion is that Adam still doesn't understand the reasons for the success of the product his company sells because his latest product is another portable with another too-small screen. With a price seven hundred bucks higher than the Kaypro and a screen five-eighths as big as the Kaypro the continued future success of the Kaypro is assured. Osborne is a crummy prognosticator himself because he his asserted in public that his new machine will 'wipe out' the Kaypro.

Morrow understands why Adam has been successful because his company now sells an integrated hardware/software package that doesn't have a handle. It also does not have a small screen. (It does have a big one.) Here are a couple of exerpts from the Infoworld interview

"The Lisa is a complete and total disaster, a disaster both in price and timing. It's two years late, and it's three times the price it should be selling for.

"I'll bet that product is causing internal arguments at Apple. I'll bet people are threatening bodily harm to each other over Lisa."

Regarding being on the leading edge of technology: "When the company gets bigger, things get more complicated. You can't afford to be adventurous. If you get into high volume, you have to stick with established technology. You've got to take what you know works." (Now you readers know why recent ads in BYTE look like vanilla, squared.)

On work: "I haven't done any work in ten years. I've done things, but work is something that you arrive to in the morning and you'd like to leave in the evening. You're not supposed to enjoy your work. If you enjoy what you do, it is no longer work." Hmmm.

George appears to be somewhat critical of the Apple folks a few paragraphs back. You will recall that we have decided not to criticize Apple anymore. This has proven to be a wise decision, because Apple had $225 million or so in sales in its most recent quarter, and that's hard to criticize!

One of these days we may even decide that the Apple III is a great success! Who says sinners can't reform?

Page 19, Column 2

BYTE WATCH:

Yes, we know you read BYTE magazine, but there are a few items we don't want you to overlook.

On page 82 there is a review of Fortune's 68000-based computer. Be sure to read the second sentence of the article! If you buy much of the software listed in the box on page 84, that second sentence will not be in accordance with the facts. On page 86, just above the "Fortune Word Processing" headline, we find this sentence: "I am pessimistic about the performance of a floppy-disk-based Unix system." So are we, Steve. (You can read more about Unix starting on page 94).

Victor has a two-page ad beginning on page 218. That ad asserts, in headlines and five times yet, that the Victor 9000 is a 16-bit machine. It is, of course, an 8-bit machine. Check out the right-most 9000 illustrated. That one has the keyboard which goes with the version of the 9000 which is selling very well indeed in Britain. The other keyboard is the one you will find on the version of the 9000 which is selling very poorly in the U.S. The difference is, of course, the 'heel rest' on the rightmost keyboard and the lack of same on the other.

The lack of a 'heel rest' is why Digital Acoustic's only Apple IIe is now being used in test. Our test personage is a one-finger hunt-and-peck typist who does not need a heel rest. Although we personally like the crisp 'feel' of the IIe keyboard very much, the heel of our right hand kept hitting a key on the (new) lowered front row of keys, one which produced no printed character on the CRT but did 'garbage' the input and cause constant assembler errors. We will not use a IIe which doesn't have a 'heel rest' extension.

Our Lobo MAX-60 has an outstanding heel rest. The Eagle II we are typing on now has a heel rest, but we would not mind if it was about three-quarters of an inch longer (deeper?). Incidentally, now that we have bought two Eagle IIs at the discount price of $2500, the list price has been dropped to $1999. Too bad the Eagle II does not have HIRES graphics; we might otherwise recommend that you buy one. The two disk drives each hold 390K and the disks are about 8 times faster (!) than Apple's Disk IIs because Eagle wasn't too cheap to use a real floppy disk controller chip.

Speaking of bad keyboards, there is what appears to be a world-class bad keyboard pictured on page 65. That thing must be six inches high!

We are becoming less enchanted with Jerry Pournelle. In his "User's Column" he conclusively proved that JRT Pascal 2.0 has bugs. JRT knew that; that's why they brought out version 2.5 long ago. Even 2.5 had a few

Page 20, Column 1

bugs; that's why they brought out version 3.0 more recently, but long enough ago to meet BYTE's lead time.

The home software business is expected to do $700 million this year. That does not include business software! And JRT is selling (selling very well, we might add) a pretty good Pascal (3.0, not 2.0) these days for a price that is, well, considerably lower than conventional industry practice. Naturally, JRT will be congratulated for this by the industry media? Hell, no! Dr. Dobb's magazine publicly mugged JRT and now BYTE tells us that version 2.0 (!) has bugs.

Jerry also authored the review of the new Osborne (beginning on page 39) in which he leaves lipstick all over Osborne. There is not one critical word in that review. On page 44, in the next to last paragraph, Adam Osborne is quoted: "When we announce the Executive we'll have several thousand in distributer's warehouses. Customers will be able to buy our machines as soon as they've heard about them." Jerry seemed to overlook the fact that the Executive II has also been announced but is not available. And the price to upgrade the one to the other has not been announced! Perhaps Jerry was busy finding bugs in JRT Pascal 2.0?

Why do we get the impression that, if we were to run across Jerry Pournelle these days, he would be wearing a three-piece suit?

On page 95, you will see an ad for Saturn System's Accelerator II. This is a 6502 board with a 3.58MHz clock. At a suggested retail price of $599 it is cheaper than Number Nine's board, so it will be a big seller, right? Wrong! The high speed 6502 board that will sell well is Synertek's 3.5MHz board with 16K RAM that plugs into slot 0. It comes with a patch for Pascal (which one we dunno) and for BASIC. Price: $299.95, quantity one. We placed an order for ten of them at $249.95 each on May 3rd. The new Synertek board works with the Apple II+ but not the lie. There are many II+s, no?

That Synertek board is going to become a powerful reason why you should have an Apple II+ instead of a IIe. What's that? You can't locate a II+ in your area? Have you investigated the Franklin, hmm?

Maybe we should take our crummy one megabyte board(s) off the market. According to Sol Libes you can buy a robot with three 8088 microprocessors and THREE MEGABYTES OF MEMORY for only $2500. We suggest that you keep the three 8088s and the memory and throw away the robot. See the first paragraph on page 496.

You can get a copy of the proposed ANSI standard for the BASIC language for twenty bucks. See the bottom of page 498. We have ordered our copy.

Page 20, Column 2

HIGH TECH, LOW PAY

The L.A. Times newspaper recently ran a feature article on manufacturing operations in the high technology area and was astounded to discover that high tech meant low pay. Especially featured was the manufacturing plant in northern Alabama where IBM subcontracts the construction of the PC. The town's name is Arab, honest!

Before the arrival of hi-tech, the principal industry in the area was providing plucked chicken to the remainder of the country. Because there are lots of people there willing to work for $3.65 an hour, that's why. The reason other industries have not moved into the area to take advantage of the low prevailing wage scales is that the general educational level is not, um, especially high.

So, the nice middle-aged ladies who take the automatically assembled and wave-soldered PC mother boards, brush them and then visually inspect them for defects are paid the local prevailing wage: $3.65 an hour. An IBM representative visiting the plant was shocked to discover how little the employees were being paid. Finally, he insisted on personally interviewing one of those workers to confirm that they were satisfied.

So he questioned this one lady, who was becoming increasingly irritated. Finally she broke into his questioning and said, "Mister, before I came to work here I had a job plucking chicken asses coming down the line at 100 miles an hour. Believe me, I'm satisfied!"

The technicians who test the boards? The testing is completely automated; the 'technician' just mounts and dismounts the board to and from the test fixture. This job is apparently considered "man's" work in Arab. The 'technicians' are given all of one hour's (!) training before being put to work on their own.

A limited number of skilled personnel are needed to program and set up the automated production machinery, program the automated board testing, etc. The owners of those production facilities seem to have considerable difficulty persuading engineers to move to Arab from Boston or Silicon Valley or even Santa Ana. We wonder why?

Why, just the other day our production foreperson ('Death March' Dunkerson) came to us with a suggestion that we get rid of most of our production employees and replace them with robots. Death March, we asked, why would you want to get rid of our beloved employees?

"Robots don't come in hung over on Monday. They don't not come in hung over on Monday. They don't take

Page 21, Column 1

vacations, get paid overtime, go on strike, complain about working conditions, or come lazing out of the restroom with eye pupils as big as dimes."

Death March, you must be more tolerant of the natural human conditions and the accompanying frailties. The employees you want to get rid of are our friends and neighbors. We have a social responsibility...

"That reminds me!" Death March cut in, "You don't have to pay social security taxes on robots!"

When are we going to install our new robots? we asked.

SCURRILOUS GOSSIP:

In the last newsletter, we reported the death of Britain's beloved gossip columnist Inside Trader at the hands of an unknown assailant. Did anyone notice that we had reported death threats against Mr. Trader in newsletter #17 (p.15 col. 2)?

Alas, Microcomputer Printout's legendary publishing lead times fooled us: we have received May's MCP and lo! there was yet another column from the pen of the late Mr. Trader.

In May '82 BYTE magazine, Check Peddle (of Victor 9000 fame) is quoted as follows (p. 271): "The minicomputer company that I fear the most is DEC. The big computer company I fear the most is IBM. The third company I fear the most is whichever Japan decides to let be the winner." Since Chuck does not appear to fear any other companies, one assumes that he intends to steer his company into the number 4 slot in sales behind those leaders.

We wish to commend Mr. Peddle on the great patience and care with which Victor is attaining the number 4 sales position.

The recent, review of the Fortune 16:32 is the second which has appeared in the industry media; Interface Age magazine carried a review in the Nov, '82 issue, written by Tom Fox. In the opening paragraph of that review, Tom asserts: "...the most revered position on the corporate staff is filled by an astute individual with the title of Vice President, Planning."

Revered? Astute? Gosh, wow!

In the May 9 '83 issue of Electronic News, on page 16, we find: "Fortune Systems Corp. acknowledged last week it plans to replace engineering vice-president Steven H. Puthuff whose departure comes amid reports of

Page 21, Column 2

performance shortfalls in the firm's 32:16 microcomputer system."

It appears that Fortune's engineering V.P. must be less astute and less revered than its planning V.P.

Tom Fox's review continues on page 72: "...we were surprised that the Fortune's micro was actually slower than an Apple II Plus... the 32:16 is less than 1/8 the speed of the best of the 68000-based computers we have tested." Hmmm, is that a 'performance shortfall'?

The recent EN article continues on p.23: "...industry reports that users of the Fortune system have found its performance significantly reduced in configurations calling for more than two users. Fortune has said that up to 16 users can tie into the machine... The Fortune system uses the 68000 microprocessor and the Unix operating system."

But not, evidently, a big fast disk.

And in the very next issue of EN, we learn that Fortune's sales have dropped. They now are predicting that sales in the second quarter will be lower than sales in the first quarter. Isn't this the hot startup which John Dvorak reported (in his Infoworld column) that recently had the tenth largest stock placement in U.S. business history, for crying out loud?

TRUTH IN ADVERTISING:

Many of you have seen the ad series knocking the 68000 in comparison to the 80286. Did you notice those ads are being run by AMD, not Intel? AMD is the company which at the present time is not manufacturing any high performance processors whatever. AMD also appears to be bigoted against the Japanese: "...their second sources are strung out from here to Tokyo." So, we ask wonderingly, what?

Something else you will note if you have real good eyesight so you can read the fine print: the little asterisk and the tee-niny print where it says the performance figures have been, ahem! er, adjusted. You bet your sweet ASCII they've been adjusted! Now, dear reader, you are supposed to guess which way they've been adjusted. Riiight! You win the cigar!

What they have done is, at a minimum, inserted two wait states on that 8MHz 68000 they are comparing against. Maybe four; we're going to write and find out. What is their justification for inserting those wait states?

We will suppose that you are going to race your Porsche against their vehicle, which happens to be a bus. Pretty confident in your Porsche, aren't you? But here

Page 22, Column 1

comes AMD (and Intel, in this case) with another bus, which they proceed to bolt onto the back of your Porsche. "Wait a minute! What the heck is going on? That's not fair!" you complain.

"But sir," they assert, "our bus can carry 16 people and your Porsche can't. We must attach this bus to your Porsche before we can fairly compare the performance of our respective vehicles. Surely, you cannot object to fairness?"

"That's stupid!" you reply. "I never bought my Porsche to drag 16 people around!" But, you discover, your reply is in vain. The opposing side has already declared their bus faster than your Porsche and have posted the results of the contest on the bulletin board!

A couple more points: the comparison is between 8MHz parts on both sides. Some of you readers may have discovered by now that the 68000 is available with faster clock speeds, all the way up to 12.5MHz. Only three 80286s which run at 8MHz exist at this time. One of them is at Intel's headquarters in Santa Clara, one is at IBM's labs in Armonk and the last one is in Mr. O'Rourke's store on Fantasy Island.

HALGOL BIOS COMMANDS:

The ability to read the keyboard, scroll the CRT or clear the screen are implicit given the ability to read or write one byte to a specified memory location. The speed advantage of (some) dedicated commands for the keyboard and CRT functions seems (very slightly) worthwhile given that we want HALGOL to run swiftly.

In a 9600 baud terminal it requires one full second - that is 60 CRT refresh times - to transfer 1024 bytes. We can do that using the "store a byte at a specified address" method for each of the 1024 bytes in about 60 milliseconds. That is only 4 CRT refresh times. Although we may refine our CRT handling code in the future, we are already 15 times faster than 9600 baud!

How does the 6502 handle control codes? It doesn't. It merely sends whatever is in the keyboard buffer, including the HEX(00) which indicates no key has been pressed. The 68000 handles the control codes.

APPLE LOVERS: DESPAIR!

We know from our past experience with persons who know a lot about the Apple but much less about the 68000 that our method of handling the I/O, which dispenses with any intelligence in the Apple, will met with fierce resistance. We reply in advance: wait until you see the enormous speed improvement!

Page 22, Column 2

THE HARD PART:

The toughest part of our little project will be reading and writing a specified disk sector directly without going through the host's DOS.

Once we can read or write (in assembly language) any of 256 possible values into each of the 256 bytes stored in a given sector, it will be easy for us to implement our own HALGOL DOS because we already did that once on the Wang 2200. Are there any public-spirited individuals out there who are willing to help us with the hard part for the Pet? (If your consultant is too busy, ask somebody to do it for free, right?)

STUFFER BOARD ALERT: Apple sent us the IIe bus timing specs (honest!). The Stuffer is absolutely guaranteed not to work with the IIe. So don't buy it if you have a IIe. Nobody else's DMA-like board designed for the II and II+ will work either, so we don't feel bad.

OUR NATIONAL SEMI 16081 MATH CHIP arrived on Friday the 13th. We hope that's not a bad omen. We didn't get two, but then we didn't have to pay for it either. The bug list for this engineering sample is amazingly short.

YOU ARE NOT SUPPOSED TO NOTICE the Applesoft code listing back there in REDLANDS. The fact is, we were having trouble filling this issue so we just tossed it in, hoping you wouldn't notice. Don't bother keying it in, it probably doesn't work.

OUR USUAL GOOF: Many of you received a subscription renewal notice which offered six more issues for $15. Make that ten issues; we forgot to change an old form letter. The last issue you have paid for now appears on the upper right of your mailing label.

THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple, II, II+, III, soft, LISA: Apple Computer Co. Anybody else need a 156th million ack, have your legal beagles send us the usual threatening note.

SUBSCRIPTIONS: Beginning with issue #19, subscriptions are $15 for 10 issues in the U,S, and Canada (U.S. funds), or $25 for 10 issues elsewhere. Make the check payable to DTACK GROUNDED. The address is:

DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705

See? We said REDLANDS would return! What we have this month is a plotting routine which maps pixels into the equivalent of the Apple's tortuously convoluted HIRES graphics page. This uses three lookup tables which are generated by a software routine (issue #7 p.14).

Page 23

HALGOL Apple command codes:

The following is the minimum command set which the Apple has to receive from the 68000 to make HALGOL viable for use with keyboard, CRT, disk and printer. No other devices will be implemented initially.

What we are doing is turning the Apple into an I/O handler, not a terminal! This is vital from the standpoint of speed and also of transporting HALGOL to other host computers. Please note that very little software modification will be required for the Pet. It is only the direct disk sector read and write which will present problems.

Exit to BASIC

Read the keyboard
Bell (considered part of keyboard)

store a byte at ADRHI, ADRLO
retrieve a byte at ADRHI, ADRLO

store N bytes beginning at ADRHI, ADRLO
retrieve N bytes beginning at ADRHI, ADRLO

print a byte to a hard copy device

set flash mode at ADRHI, ADRLO
clear flash mode at ADRHI, ADRLO
Scroll

read a D, T, S disk sector
write a D, T, S disk sector

The following commands will be needed if a non-standard HALGOL disk format is used (for the purpose of improving the disk speed):

INIT
read a HALGOL sector
write a HALGOL sector

(Additional Commands will be required to support HIRES graphics)

You may have noticed the absence of cursor commands above. We have a surprise for you: the Apple II does not have a cursor in hardware! What appears to be a cursor is merely the 'flash mode' of a character being set; more than one character can be in flash mode at once.

The position of the cursor, and the corresponding flash mode, will be handled by the 68000.

Page 24

10 HOME : TEXT : GOSUB 5000 
30 PRINT "INPUT AN EXPRESSION": PRINT : INPUT L$ 
50 PRINT : L = LEN(L$): IF L = 0 GOTO 1050 
60 REM STRIP SPACES 
70 FOR I = 1 TO L: X$ = MID$(L$, I, 1): IF X$ = " " GOTO 100 
90 J = J + 1: J$ = J$ + X$ 
100 NEXT I: L$ = J$: L = LEN(L$): P = L: IF L = 0 GOTO 1050 
110 T = L / 2 - INT(L / 2): IF T < > .5 GOTO 1060 
120 REM CHECK SYNTAX 
130 FOR I = 1 TO L STEP 2: V$ = MID$(L$, I, 1) 
140 V = ASC(V$): IF V < 65 OR V > 90 GOTO 1020 
150 NEXT I: IF L < 2 GOTO 185 
155 FOR I = 2 TO L = 1 STEP 2: M$ = MID$(L$, I, 1) 
160 IF M$ = "+" OR M$ = "-" OR M$ = "*" OR M$ = "/" GOTO 180 
170 GOTO 1040 
180 NEXT I 
190 REM SYNTAX OK; BEGIN COMPILATION 
200 REM HARD COPY OPTION HERE 
210 REM HARD COPY OPTION HERE 
220 V$ = MID$(L$, P, 1): PRINT "LOAD "; V$: P = P - 1 
230 IF P > 1 GOTO 260: REM CONTINUE IF NOT COMPLETED 
240 IF F = 0 GOTO 1030: REM DONE IF NO TEMP STORAGE 
250 GOTO 300 
260 GOSUB 900: IF K = 0 GOTO 280: REM SKIP IF LOWER PRECEDENCE 
270 V$ = MID$(L$, P, 1): P = P - 1: PRINT H$(M); " "; V$: GOTO 230 
280 IF F = 0 GOTO 340 
290 REM RECALL TEMP VAR & OPERATOR 
300 F = 0: M = M1: V$ = V1$: P = P + 1 
310 PRINT H$(M); " <TEMP>": IF M = 0 GOTO 230 
330 PRINT "CHS": GOTO 230: REM SUBTRACTION WAS REVERSED 
340 IF P > 1 GOTO 370 
350 REM LAST MATH OPERATOR 
360 V$ = MID$(L$, P, 1): PRINT H$(M); " "; V$: GOTO 230 
370 REM TEST PRECEDENCE OF NEXT MATH OPERATOR 
380 P0 = P: M0 = M: K0 = K: P = P - 1: GOSUB 900: IF K = 1 GOTO 400 
390 P = P0: M = M0: K = K0: V$ = MID$(L$, P, 1) 
395 P = P - 1: PRINT H$(M); " "; V$: GOTO 230 
400 P = P0: K = K0: M = M0: V$ = MID$(L$, P, 1): V1$ = V$: M1 = M 
410 PRINT "STORE <TEMP>": F = 1: GOTO 220 
900 REM FETCH MATH OPERATOR 
910 M$ = MID$(L$, P, 1): K = 0: M = 0: IF M$ = "+" GOTO 960 
920 M = 1: IF M$ = "-" GOTO 960 
930 K = 1: M = 2: IF M$ = "*" GOTO 960 
940 M = 3 
960 P = P - 1: RETURN: REM K IS PRECEDENCE, M IS MATH OPERATOR 
1020 PRINT : PRINT "IMPROPER VARIABLE NAME DETECTED IN POSITION "; I: STOP 
1030 PRINT : PRINT "COMPILATION IS COMPLETED": STOP 
1040 PRINT : PRINT "ERROR, EXPECTED A MATH OPERATOR IN" 
1045 PRINT "POSITION "; I: STOP 
1050 PRINT : PRINT "ERROR, THERE IS NO EXPRESSION": STOP 
1060 PRINT : PRINT "ERROR; THERE SHOULD BE AN ODD NUMBER" 
1070 PRINT "OF VARIABLES AND MATH OPERATORS.": STOP 
5000 FOR I = 0 TO 3: READ H$(I): NEXT I 
5010 DATA "ADD","SUB","MULT","DIV" 
5020 PRINT "HALGOL EXPRESSION COMPILATION INTO" 
5030 PRINT "PRIMITIVES DEMO.  USE SIMPLE VARIABLES" 
5040 PRINT "ONLY.  A THRU Z ARE ALLOWED.  THE MATH" 
5050 PRINT "OPERATORS ARE:   +  -  *  /": PRINT : PRINT : RETURN

Page 25

                         48 ; REPEAT THIS LOOP FOR EACH PAIR OF COORDINATES 
                         49 ; 
                         50 ; PULL 12 BYTES OF LINE PLOT DATA FROM 
                         51 ; THE DATA STACK (A0) AND PLOT IT. 
                         52 ; 
00184A  2818             53 PLOTXY   MOVE.L  (A0)+,D4 
00184C  2E18             54          MOVE.L  (A0)+,D7 
00184E  3018             55          MOVE.W  (A0)+,D0 
001850  3A18             56          MOVE.W  (A0)+,D5 
001852  6A 24            57          BPL     XLINE          ;PLOT X IF B15 = 0 
001854  3200             58          MOVE.W  D0,D1 
001856  E349             59          LSL.W   #1,D1 
001858  E34D             60          LSL.W   #1,D5 
                         61 ; 
                         62 ; PLOT A LINE FROM 2*Y1 (D1) TO 2*Y2 (D5) 
                         63 ; D4=X1, 25 BITS;  D7=DELTA X, 32 BITS 
                         64 ; 
00185A  2004             65 YLINE    MOVE.L  D4,D0 
00185C  4840             66          SWAP    D0             ;D0.W=X 
00185E  3432 1000        67          MOVE.W  (A2,D1.W),D2   ;START OF YTH LINE 
001862  D431 0000        68          ADD.B   (A1,D0.W),D2   ;ADD BYTE OFFSET 
001866  3842             69          MOVE.W  D2,A4          ;A4 = PIXEL PTR 
001868  1435 0000        70          MOVE.B  (A5,D0.W),D2   ;FETCH THE PIXEL 
00186C  8514             71          OR.B    D2,(A4)        ;OR INTO HIRES PAGE 
                         72 ; 
                         73 ; -- CHECK WHETHER MORE POINTS NEEDED IN LINE -- 
                         74 ; 
00186E  B245             75          CMP.W   D5,D1 
001870  64 26            76          BCC     PLOTEX         ;EXIT IF NO MORE 
001872  D887             77          ADD.L   D7,D4          ;X=X+DX 
001874  5441             78          ADDQ.W  #2,D1          ;INCR Y 
001876  60 E2            79          BRA     YLINE          ;CONTINUE PLOT 
                         80 ; 
                         81 ; PLOT A LINE FROM X1 (D0) TO X2 (D5) 
                         82 ; D4 = Y1,24 BITS;  D7 = DELTA Y, 32 BITS 
                         83 ; 
001878  2204             84 XLINE    MOVE.L  D4,D1 
00187A  4841             85          SWAP    D1 
00187C  E349             86          LSL.W   #1,D1          ;D1.W = 2 * Y 
00187E  3432 1000        87          MOVE.W  (A2,D1.W),D2   ;START OF YTH LINE 
001882  D431 0000        88          ADD.B   (A1,D0.W),D2   ;ADD BYTE OFFSET 
001886  3842             89          MOVE.W  D2,A4          ;SET PIXEL PTR 
001888  1435 0000        90          MOVE.B  (A5,D0.W),D2   ;FETCH THE PIXEL 
00188C  8514             91          OR.B    D2,(A4)        ;OR INTO HIRES PAGE 
                         92 ; 
                         93 ; CHECK WHETHER MORE POINTS ARE NEEDED IN LINE 
                         94 ; 
00188E  B045             95          CMP.W   D5,D0 
001890  64 06            96          BCC     PLOTEX         ;EXIT IF NO MORE 
001892  D887             97          ADD.L   D7,D4          ;2Y = 2Y + 2DY 
001894  5240             98          ADDQ.W  #1,D0          ;INCR X 
001896  60 E0            99          BRA     XLINE          ;CONTINUE PLOT 
                        100 ; 
                        101 ; ARE ALL OF THE LINES PLOTTED ? 
                        102 ; 
001898  5338 25AD       103 PLOTEX   SUBQ.B  #1,SERCNT      ;DECR LINE CTR 
00189C  66 AC           104          BNE     PLOTXY         ;LOOP TIL DONE 
                        105 ; 
                        106 ; -- RETURN VIA SUBROUTINE 'OUT8K' -- 
                        107 ;

Page 26

                        109 ; THE FOLLOWING SUBROUTINES USES 'THE STUFFER' TO 
                        110 ; RAPIDLY (!) TRANSFER THE 68000 RESIDENT HIRES 
                        111 ; PAGE TO THE APPLE II HOST. 
                        112 ; 
                        113 ; THE EXECUTION TIME IS 11.4 MILLISECONDS 
                        114 ; 
00189E  7E 06           115 OUT8K    MOVEQ   #6,D7          ;STUFF 8K 
0018A0  4EB8 1962       116          JSR     OUTCHR 
0018A4  1038 0FFA       117 OUT8K1   MOVE.B  STATUS,D0      ;CHECK CMD BITS 
0018A8  0240 0003       118          ANDI    #3,D0          ;MASK B2-B7 
0018AC  5700            119          SUBQ.B  #3,D0 
0018AE  66 F4           120          BNE     OUT8K1         ;WAIT TIL HOST RDY 
                        121 ; 
0018B0  307C 3000       122          MOVE.W  #HIRES,A0      ;PTR TO ARRAY 
0018B4  303C 03FF       123          MOVE.W  #1023,D0       ;8K/8 TO D0 
                        124 ; 
0018B8  11D8 0FFA       125 HILOOP   MOVE.B  (A0)+,DATOUT   ;OUTPUT A BYTE 
0018BC  11D8 0FFA       126          MOVE.B  (A0)+,DATOUT 
0018C0  11D8 0FFA       127          MOVE.B  (A0)+,DATOUT 
0018C4  11D8 0FFA       128          MOVE.B  (A0)+,DATOUT 
0018C8  11D8 0FFA       129          MOVE.B  (A0)+,DATOUT 
0018CC  11D8 0FFA       130          MOVE.B  (A0)+,DATOUT 
0018D0  11D8 0FFA       131          MOVE.B  (A0)+,DATOUT 
0018D4  11D8 0FFA       132          MOVE.B  (A0)+,DATOUT   ;8 BYTES/LOOP 
0018D8  51C8 FFDE       133          DBF     D0,HILOOP      ;REPEAT 1024 TIMES 
                        134 ; 

 

                          5 ; CLEAR THE 8K HIRES GRAPHICS 
                          6 ; THE EXECUTION TIME IS 1.45 MILLISECONDS 
                          7 ; 
0017E8  48E7 FFFE         8 CLRHRS   MOVEM.L D0-D7/A0-A6,-(A7)  ;SAVE 15 REGS 
0017EC  21CF 25AA         9          MOVE.L  A7,M2          ;SAVE 16TH REG 
0017F0  4281             10          CLR.L   D1 
0017F2  4282             11          CLR.L   D2 
0017F4  4283             12          CLR.L   D3 
0017F6  4284             13          CLR.L   D4 
0017F8  4285             14          CLR.L   D5 
0017FA  4286             15          CLR.L   D6 
0017FC  4287             16          CLR.L   D7 
0017FE  48A7 7F00        17          MOVEM.W D1-D7,-(A7) 
001802  4C9F 7F00        18          MOVEM.W (A7)+,A0-A6    ;CLRS (.L) ADR REGS 
001806  3E7C 5000        19          MOVE.W  #HIRESU,A7     ;HIRES PG + $2K 
00180A  70 1C            20          MOVEQ   #28,D0         ;SET FOR 29 LOOPS 
                         21 ; 
00180C  48E7 7FFE        22 CLR8K    MOVEM.L D1-D7/A0-A6,-(A7)  ;CLR 56 BYTES 
001810  48E7 7FFE        23          MOVEM.L D1-D7/A0-A6,-(A7) 
001814  48E7 7FFE        24          MOVEM.L D1-D7/A0-A6,-(A7) 
001818  48E7 7FFE        25          MOVEM.L D1-D7/A0-A6,-(A7) 
00181C  48E7 7FFE        26          MOVEM.L D1-D7/A0-A6,-(A7)  ;280 BYTES/LOOP 
001820  51C8 FFEA        27          DBF     D0,CLR8K       ;LOOP 29 TIMES 
                         28 ; 
001824  48E7 7FC0        29          MOVEM.L D1-D7/A0-A1,-(A7)  ;CLR 36 MORE 
001828  48E7 7FC0        30          MOVEM.L D1-D7/A0-A1,-(A7)  ;8192 BYTES CLRD 
00182C  2E78 25AA        31          MOVE.L  M2,A7          ;RESTORE A7 
001830  4CDF 7FFF        32          MOVEM.L (A7)+,D0-D7/A0-A6  ;RES OTHER 15 
001834  4E75             33          RTS                    ;8K HIRES CLEARED