Letters

Pagemaker 2.0 Incompatible with 1.2

David E. Smith

Aldus Corp. released version 2.0 of Pagemaker today and MacTutor has found that version 2.0 is incompatible with version 1.2 for placing formatted MacWrite files. Under version 1.2, the left margin setting of MacWrite has always been ignored unless the command key is held down, when reflowing formatted MacWrite files into Pagemaker columns. This has become a feature, since it is very difficult to work with a MacWrite window with the left margin set at 0. Under version 2.0, this left margin setting is now automatically picked up by Pagemaker and the entire column of text is indented by this amount. Since there is no way to stop this indentation, in order to get MacWrite documents to correctly reflow into Pagemaker columns, you must go back and re-format all of your MacWrite ruler settings to a left margin of 0. Even for a single large document, this can be a job! And for the thousands of documents formatted over the last two years, impossible! Since Aldus has indicated they do not intend to change this, unless forced by the marketplace, MacTutor is encouraging a letter writing campaign to force the addition of a dialog option to turn off automatic indentation of MacWrite formatted files in version 2.0. Please write to Paul Brainerd at Aldus, 411 First Ave. South, Suite 200, Seattle, WA 98104. MacTutor will be very grateful.

TML Pascal and SANE

Alan Engard

I’m having a hair-pulling experience with TML Pascal (and/or SANE) and hope someone out there can help. The “Tan” and “XpwrY” calls to SANE fail consistently. It creates an Address Error or Illegal Instruction Error depending on the individual program. The failure occurs regardless of whether the parameters are constants or variables, and occur in both plain-vanilla Pascal and all-Mac Pascal code.

Following is an example:

 program test (input,output);
 uses macint f, sane int f;
 var
      result :real;
 begin
      writeln(‘Tangent:’);
      result:=Tan(3.1415926536); {TML crashes}
      writeln(result);
 end.

And I do know that at least some calls to SANE do work (although they are all non-calculation oriented): Num2Str and ClassExtended.

MacUser (as early as the February issue) listed the current version of TML Pascal as 2.01, while I have 2.0--is this right? If so, does this bug(?) still exist and what else has been fixed/added/changed? (On that note I would like to suggest that you mention development tool updates and briefly list their changes.) Thanks for all of your invaluable information--keep up the good work!

[We tried the example in Lightspeed Pascal and it ran a tangent function from SANE with no problems. I suggest you contact TML about updating to version 2.01 and ask them about this bug. The update problem requires a full time person to keep up with it. We haven’t found the time or money to hire such a person yet, but I agree the job is needed. -Ed]

 uses sane;
 
 PROCEDURE doUser; {LS Pascal example}
 VAR
 result : extended;
 str1   : str255;
 str2   : DecStr;
 f : DecForm;
 BEGIN
 result := Tan(3.1415926536);
 f.style := FixedDecimal;
 f.digits := 12;
 Num2Str(f, result, str2);
 str1 := ‘Tangent of Pi = ‘;
 doMessage(str1, str2, ‘’, ‘’);
 END;

McFace News

Dan Kampeier

First, I would like to thank Chuck Bouldin for taking the time to review McFace. Chuck is an avid user of McFace, and has contributed to the enhancement of McFace via his many comments and suggestions. I would also like, however, to provide a further explanation or clarification of the two major criticisms which Chuck made of McFace: (1) its relatively large size, and (2) its use of numbers as arguments in calls to McFace.

(1) One problem with the Absoft (Microsoft) Fortran compiler for the Mac is that the object code which it generates is at least twice as large as that generated by the Pascal or C compilers for the equivalent source code. This may be a trade-off for the execution speed, but I’ve also heard that the compiler is simply not very efficient with respect to the object code it generates. Now if you are stuck using such a compiler, the obvious thing to avoid is duplicating source code from program to program, and this is exactly what McFace does for you: it provides a single subroutine which can be used by many different Fortran programs on the same disk. The second reason why McFace is so large is simply that it does so much for you.

It contains code for file handling, text editing, picture handling, etc., as well as functions such as “Copy Table” (replace spaces with tab), search & replace, auto-indent, etc. If you use Fortran to create a program with most of the functionality of McFace, I guarantee that it will be at least as large as McFace. Finally, memory is going to continue to get cheaper, the Mac toolbox is going to continue to get more powerful, and McFace is going to inevitably get bigger as user expectations rise ever higher. (Look what has happened to the size of MS Word!)

(2) I experimented with many different methods of passing information between the calling program and McFace, and settled on a scheme with three levels: (a) direct “macro” commands are passed as arguments in the subroutine call, (b) often used variables are shared in a common block with the calling program, and (c) seldom used variables are stored in an array which the programmer can access as needed. Passing macro commands as numbers (versus integer variable names as recommended by Chuck) is preferred by most of the active users of McFace to whom I have talked. The source is cleaner, and their are simply not that many different macro commands to remember. Moreover, nearly all of the commands simply correspond to a McFace menu and item number, so that anyone familiar with the McFace Apple, File, Edit, and Window menus will also automatically know many of the macro command combinations. Furthermore, use of integer variable names for numbers is not as easy as it sounds since many of the McFace menu items are context sensitive (depend on which window is at front), and some menus are of variable length (depend on number of windows in use). Finally, nothing prevents a McFace user from simply creating integer variable names to use in place of numbers in calls to McFace.

McFace continues to evolve. Version 3.0 will ship sometime early this summer and should be compatible with the Mac II (Absoft was having trouble with some toolbox calls on the Mac II with its current release). My continuing goal is to put as much generic stuff into McFace as possible to facilitate the rapid development of fully Mac-like programs in a minimum amount of time using Fortran.

Reprint

W.J. Meyers

Thank you for allowing us to reprint Loy Spurlock’s comments on the Mac’s power supply problems from a past issue of MacTutor. I was told by Loy that you have given your approval to concurrently publish his article providing we acknowledged your permission to reprint at the beginning of the article. A copy of our newsletter is enclosed to prove that we complied with your wishes.

By the way, if you are still keeping tabs on the problems user’s are having with their SCSI drives, please put my name on the list. I am having one hell of a time with my ProApp 20 drive(s), but let me follow through to a conclusion before I tell you the whole story.

32k Segment Limit-Revisited

S.C. Kim Hunter

In MacTutor, March 87, I made a comment regarding a “fundamental” limit of the 32k that is imposed in many of the compilers for the Mac, mainly Pascal, and pointed out that MacFortran doesn’t have any of these limits, simply because Absoft chose to ignore the Mac ROM segment loader when they wrote their compiler (actually just ported it from something else).

To confirm my suppositions, I ran a test program in both Lightspeed Pascal and MacFortran. Listings are enclosed. In Lightspeed Pascal, one can define an array of integers up to 1..15497 in the global variable part, and in a procedure, up to 1..16375. Integers in Lightspeed Pascal are each two bytes, so these limits are close to 32k (which should be 32768 bytes, or 1..16384 integers). If the dimensions are increased by 1 more than these limits, the compiler politely puts up an error message advising one of three messages: 1) “Project has more than 32k of globals”, 2) “Available memory for variables declared at this level has been exhausted”, or 3) “Variables of this type would be too large”. At which point these messages appear is shown in the Lightspeed Pascal listing.

The same program done in MacFortran, and constricting integers to 2 bytes (integer*2-the default is 4 bytes), compiles and runs perfectly at the dimensions well over those of Lightspeed Pascal version. I ran the integer array dimension up to about 150,000 before running in to problems (on a 512k Mac XL). Unlike the polite messages of Lightspeed Pascal, MacFortran just overwrites and bombs (freeze, crash to Macsbug, the gamit, out of control). The compiler has no messages, friendly or otherwise, compiling and dimension with no grips. Only when the program runs do you know if you exceeded the memory limit. If you add more RAM, the problem goes away till you pump up to the new limit.

Lightspeed Pascal does edit, compile, run cycle in about 21 sec, good or bomb (politely). MacFortran, if you insert an “execute(‘QUED 1.5’)” to auto re-enter the editor takes about 1:20 min:sec for a good cycle, 2:40 min:sec for a crash/reboot on a Mac XL. So you take your choice: small, quick, polite bytes with Lightspeed Pascal, or Russian Roulette chomps with MacFortran.

I have passed these questions to Apple Macintosh Technical Support. They are beyond my limited scope as a “high level programmer”. Only someone who has actually read and understood Inside Macintosh and actual been inside a Macintosh could answer the questions. I am too big and fat to fit that spec. Andy Hertzfeld is small but fat (and cute! but that doesn’t count except when his software crashes-then he’s not so cute!).

We soon will have Macs with 4 megabytes (some have them now). Are we only allowed to swallow them in 32k chunks? Lets see, 4,096,000 divided by 32,768 is... How many chunks?

Don’t expect the answer to come from Think Technologies. At $89 per package, they can hardly pay for Steve Stein to answer the phone (which he now doesn’t seem to be doing). Only Apple with $500 mill in the bank can afford to pickup the phone. Hello?... Hello?... MacTech?... Is anyone there?

[The problem is that many compiler makers copied the segment loader technique for addressing code segments, which is to use a base address with an offset to the desired segment. I’ll take a guess and say the addressing mode they are using is PC with displacement. On the 68000, that particular form of addressing limits the displacement offset value to a 16 bit sign-extended integer, which is the source of the 32K limit. The 68020 allows this displacement to be a full 32 bits, so this restriction is not present. But the more important point is, they should not have used this particular addressing mode. The 68000 obviously offers a variety of addressing modes for directly reaching anything in the 16 meg memory space. -Ed]

03/25/87 22:56      LSP test32kprog
program test32k; {32k limit should be 32768 bytes}
{Lightspeed Pascal data structure limits.}
{Exceeding the limits incurs polite compiler error messages}
{Edit, Compile, Run time: 21 sec,}
{regardless if data size OK or too big}
{S.C. Kim Huner for MacTutor}
var
  i:array[1..15497] of integer; { max global=30994 bytes}
{1..15498 generates:  “ more than 32k bytes of globals.”}
{Also just adjust another variable, “c :char;”-same message}

procedure xx;
  var
   i:array[1..16375] of integer; { max proc=32750 bytes}

{ 1..16376 to 1..16383 generates:}
{ “Available memory for variables declared at this level has been exhausted}
{ 1..16384 generates: “Variables of this type would be too large.”}

  begin
  end;
begin
end.

test32k.for             Wed, Mar 25, 1987
       
       program test32k
C  MacFortran, Version 2.2
C  MacFortran data structures limited only by RAM.
C  if limit exceeded, MacFortran just crashes.
C  Mac XL Edit, Compile, Run time: 1:30 min:sec if OK
C  Edit, Compile, Run, Crash, Reboot time:
C          2:40+ min:sec if too big
C  S.C. Kim Hunter for MacTutor

           integer*2 i
           dimension i(150000)  ! 150000 OK

C  At 160000-170000, things deteriorate and freeze or crash
C on Mac XL with 512k.  Add more RAM, problem goes away.

     call xx
     write(*,*)”Im Ok, so far.  (But maybe not!)’
     pause
     execute(‘QUED 1.5’)
     end

     subroutine xx
     integer*2 ii
     dimension ii(16376)

C  16376=1 more than Lightspeed Pascal can do,
C                didnt try more.

      end

Park Your Head

Serge Froment

There is much confusion about the hard disk head parking. Every hard disk manufacturer seems to have his own opinion and way of doing it. Here is some questions I would like to be clarified.

When I bought the DataFrame hard disk, about a year ago, the manual told me that I must issue the “shutdown” command since the command does park the head of the DataFrame.

Recently, I received a new version of the DataFrame software, and the “read me” file says that I must use the new “SuperParker” program to park the head before moving the hard disk. One question arises: did the “shutdown” command really park the head?

What is “head parking”? The first documentation of the DataFrame said that it “moves the head to an unused portion of the disk”. The new documentation says that “it may take longer for the hard disk to boot after head parking since the drive have to recalibrate the head to former position”, which sounds more complicated than just moving the head to an unused portion of the disk.

I also saw recent public domain head parker programs. The documentation says that those programs issue a SCSI “stop” command. Does that command have a standard effect on every SCSI hard disk? It seems not: when I use those programs on my DataFrame, the disk boots faster than when I use the Supermac’s SuperParker.

I recently bought a Macintosh SE with internal hard disk. The manual says nothing about head parking in the section talking about the internal drive. There is now a real “shutdown” command along with the new “restart” command. Does the new “shutdown” command do anything more than avoiding you to rush beating the rebooting action? In the section about “caring for your Macintosh SE”, the documentation only says that when moving the Macintosh, you “should use the materials that the computer came packed in. If the system includes the internal hard disk, the canvas cases manufactured for older Macintosh units are probably not sufficient protection.” Does it mean that the Macintosh is now so business oriented that it should not leave the office? What about the passenger seat of my car, with the safety belt buckled up? Should I affix a “computer on board” sign in the rear of my car?

The Macintosh SE is a great machine... but I hate the keyboard. It reminds me of the worst IBM PC clones. The feeling is awful, and it makes me do many typing errors: the keys I strike are often not entered, and I occasionally strike the “\” key instead of the space bar. The absence´ of the right sided “option” key is painful when typing left sided special symbols. The original Macintosh keyboard layout was great. So great that even IBM copied its basic layout on the new PC models. Why change the position of keys on every new Macintosh model? Since there is a new “restart” key over the numerals, it would have been possible to place the cursor and the “escape” keys there also and keep everything else into place...

A final word about international resources. The original INTL resources contains the format of dates and the string for writing every day of the week and month by name. It also contains a single abbreviation size for short date format. There is a flaw in this design: in French, the days of the week abbreviation uses 3 characters. So far, it’s ok. The problem comes when applying a 3-char abbreviation to month names: in French, June and July spell “juin” and “juillet”; so the abbreviation is “jui” for both. Using a 4-char abbreviation for everything looks ugly, especially for the days of the week. The French localization uses a 3-char abbreviation despite the ambiguity; the French Canadian uses a 4-char one despite the ugliness. The true solution would be to have an abbreviation size for every day and month name. I have not received yet the localized version of system 4.0. I know ti allows writing with all scripts of the world, including Arabic, Japanese and Chinese. I strongly hope it will also solve that old Roman script problem.

Yes Virginia, You Can Find Yourself

David M. Lane, President

Just a note about HFS compatibility and the MS-BASIC compiler. It turns out it is possible to create stand alone applications using libraries from BASIC that work even if the user changes the application’s name. Unfortunately, the method is very poorly documented, alluded to only in one of the READ ME files distributed with the compiler. First you move the necessary library statements into the application. Then with PEEK statements you determine the name of the current application. You then use this name in the library statement. For example,

Appname A$
LIBRARY A$
REM rest of the program follows:

END
SUB AppName (theName$) STATIC
  theName$=””
  CurAppName=&H910
  i%=PEEK(CurAppName)
  FOR j%=1 TO i%
theName$=theName$+CHR$(PEEK(CurAppName+j%)
  NEXT j%
END SUB

will work regardless of the folder the program is in or what the name of the program is.

We have been distributing a statistical program (CLR ANOVA) in compiled MS-BASIC since December. It is a stand alone application and is fully HFS compatible.

Number Crunching on the Mac

Louis M. Pecora

Enclosed is a $30 check for a year’s subscription to MacTutor. Do you have a list or index of past articles so I can decide which back issues to order? [We’re working on it ]

Enclosed with this letter and payment is an “open letter” about number crunching. It was inspired by a recent very good article by P. Zarchan in MacTutor and partly by my own experiences.

Most working engineers and scientists would like to have a work station on their desktops. At this time, most cannot afford a Sun, Apollo, or VAX. However, for many applications the Mac plus or its descendents can prove to be effective tools. The exception to this is for number crunching. Two main problems which appear to surface on this topic are the SANE routines and available scientific programming languages. The particular questions I raise here cover these, along with some other questions. The range is from Mac-specific to general computer software questions. I include them all because, in the long run, they will all affect the Mac and its descendents. My preference is for C, but those who prefer other structured languages can often substitute their name in place of “C” in what follows.

Two recent articles1,2 show that use of SANE floating point routines can slow number crunching on the Mac to a crawl. Microsoft FORTRAN uses its own IEEE routines which, although less accurate than SANE, can blaze through number crunching. However, Microsoft FORTRAN is not the answer, as I state below. The real question is are there other floating point routines available for the Mac which can be accessed by other languages, especially the structured ones: c, Pascal, Modula-2, etc? I’ve heard that Motorola has its own routines and that these are available to some Forth packages3. Can they be made available to other language packages? Are there floating point routines available which specifically use the 68881 coprocessor? This is an item sure to become a standard on future Macs.[Jörg Langowski published a complete 32 bit floating point package in a past issue of MacTutor that addresses these concerns. It could be modified to call the 68881 directly. SANE on the Mac II is patched to use the 68881 independent of your application and that speeds it up four fold at least. -Ed]

Another aspect of number crunching is the use of large data arrays. Often these cannot fit in RAM and use of virtual memory (disk space) must be made. Only Microsoft FORTRAN, to my knowledge, can do this. Are there other language packages which can do this? [The 32K segment limit in most compilers (including MPW) means you have to construct your own data structures using a handle to point to a block of memory. That block could be made virtual by designing your program to do so. -Ed]

From what I’ve said above, one might think that Microsoft FORTRAN is the answer to number crunching questions. But anyone, especially a Mac user, who has used Microsoft FORTRAN knows that it is buggy and clunky. It does not easily deliver what it promises. Experiences at our lab is generally that programs written in Microsoft FORTRAN often take 2 to 5 times longer to debug than programs in C or Pascal or even FORTRAN on a VAX. Access to the Mac toolbox is cumbersome. Some experiences have been so frustrating that people have just given up.

Some of the problems are with Microsoft FORTRAN itself and some stem from just plain FORTRAN. Most programmers recognize that FORTRAN is an awkward beast which is used only because of inertia and the fact that nothing has appeared to take its place4.

Recently, an enhanced version of C (C++) has been released by AT&T labs. It appears to have many features which are more effective and efficient than any C counterpart. These include items of interest to number crunchers: vectors, matrices, easy I/O, type checking, etc. Is there a version of C++ for the Mac? If not, C with better floating point routines and the programs “lint” would be a good start for number crunching on a Mac. Is there a version of “lint” for the Mac?

Finally, in a more general vein, is there a better scientific language available now or in the works which takes the best structured languages like C and the best of FORTRAN (type checking, floating point over- and under flow, virtual arrays, complex numbers, etc.) and combines them??

Many of the above questions are crucial for the Mac to gain a true foothold on most engineer’s and scientist’s desktops. The hardware is there. Except for the 68881 floating point coprocessor, the above are software questions. I’m sure a great many scientists and engineers, besides myself, are interested in the answers.

“Footnotes”:

1. MacTutor, March 1987, pp. 15-22

2. MacWorld, one of the 1986 issues reviewing Microsoft FORTRAN

3. I haven’t looked into this yet, but I am advised that CIS (the MacForth people in Rockville, MD) are using the Motorola routines.

4. I am ignoring ALGOL here. IBM has made sure that, in the U.S.A., FORTRAN is the “preferred” language for scientific programming. I understand it’s different in Europe where ALGOL is more readily available.

More 68020 Benchmarks

Chuck Bouldin

A few comments about the “MacCad” article in the March issue. I think this is a very good article, since it shows the potential of the upgraded Macs as true number-crunchers. If anything, I think the article understates the speed of a 68020-68881 for several reasons.

First, neither the Basic nor the Fortran benchmarks contain any transcendental operations (sin, cos, etc. ). Surprisingly enough, such functions are handled on a VAX as subroutine calls, while the 020/881 Fortran has inline calls to the 881. with clock rates of 12-16 mHz on 020/881 systems, benchmarks that are heavily loaded with transcendental functions actually run FASTER than a VAX 11/780. Also, the 881 will deliver 80 bit precision, where the VAX ( in standard REAL*8) gives 64 bit precision.

Second, neither of the benchmarks uses large data arrays. When arrays get larger than 64K, the performance of the 020/881 systems goes up a lot relative to the segmented architecture of 80386 or 80286 systems. In fact, when large arrays are manipulated, as in matrix inversions or the Sieve benchmark for finding, say, the primes up to 80,000, then a stock Macintosh will outrun a PC “AT”. To be fair to the VAX, it should be pointed out that the VAX will improve over the 020 on benchmarks with large data structures, as the VAX does a better job of addressing the data structures.

It is also interesting to compare the performance of the Mac on the Whetstone benchmark, which mostly tests the speed of the floating point operations. The result are: (here, bigger numbers are better, i.e., faster computer)

VAX 11/780 (1) 1100

Mac+/Absoft Mac Fortran (2) 41

Mac+/Novy 020/881 upgrade (3) 214

Mac+/Prodigy 4 upgrade (4) 500

Compaq 386/ Lahey Fortran (5) 232

Compaq deskpro 286/Lahey (6) 98

Comments on the hardware/software:

(1)Unloaded Vax 11-780 with VMS 4.x and latest release of the Fortran compiler.

(2)Standard Macintosh with Absoft/Microsoft Compiler

(3)Mac+ upgraded with Novy 68020/881 board, running Absoft MacFortran 020 compiler. Clock rate is still 8 MHz and data path is still 16 bits.

(4)Mac+ upgraded with Prodigy 4 running Absoft MacFortran 020 compiler. Clock rate is 16 MHz and data path is 32 bits. The factor of 2 over the Novy board is from clock rate increase and bus bandwidth. Except for the Mac’s infamous “video refresh through the CPU” this benchmark would be closer to 750K whetstones. The Prodigy Prime and the Rye 020/881 upgrades should provide essentially the same performance.

(5)Compaq 386. Uses 16 MHz 80386 with hardware floating point supplied by a 12 MHz 80287, since there is, as yet, no available 80387. Lah´y Fortran compiler.

(6)Compaq Deskpro 286, 80286/80287 running at 8 MHz. Lahey Fortran compiler.

I think it is very interesting that, with a $750 upgrade, a Mac+ will deliver virtually the same number-crunching capability as the very best ($7000) MS-DOS computer that is available. With more elaborate upgrades, that widen data path to 32 bits, and increase the CPU clock rate, the Mac gets even faster. The results are in good agreement with the conclusion in the article that the Mac II or upgraded Mac+ can be expected to perform at ~1/2 of VAX level.

Finally, a few minor quibbles with the article. What is meant by an “improved” PC? Why does the use of an 80287 with an AT only change the speed of the Butterworth benchmark from 39 to 35 seconds, while it changes the results on an improved PC from 75 to 40 seconds? Could we also get the speed of the Compaq 386 on the Butterworth benchmark?

The most serious flaw in using the Macintosh for CAD work is that many languages have 32K segmentation limit! As you pointed out, Apple effectively trashed Motorola’s clean linear address space and made it into a segmented Intel-style address space. I think that MacTutor should address this question in detail. Are there any C or Pascal compilers that will allow arrays or code segments larger than 32K? [If there is, MacTutor will offer a free ad space for the first good Pascal compiler that eliminates this restriction. -Ed]

Hanover Fair Report

Christoph Sold

First, I apologize for my poor English. Yesterday I was at the Hanover fair CeBit at Apple and have seen the two new Mac’s and some new software. I was surprised by the new capabilities of these machines. I think only a few people from America were there, so I write what I have seen to you.

First the hardware: There were --as said above-- two new Macintoshes: The “little” Macintosh SE and the “big” Macintosh II. First I describe my impression on the Macintosh SE. It was ready built and --as Apple announces-- now available. Its main difference to the Macintosh Plus is a slot, and the possibility to fit a second disk drive or a hard disk in. But the important difference is the change of priority between RAM access from the CPU and the video chip: This speeds the Mac SE up by 30% against a Macintosh Plus.

Now the (seen) facts about the Macintosh II: It comes up with an 68020, hard disk built in and has no built-in monitor. Apple shows us two kinds of monitors: Two black and white ones, one of these shown with a resolution of 640x480 and a size of 12"; and one RGB analog color monitor with the same resolution, but a size of 13" (Sounds like SrcnHres and ScrnVres become interesting, ha?). I have seen this machine working with an 8086 coprocessor card: Turn on, WordStar in, it works. I’ve been told Microsoft flight simulator works too. (But, in fact, which IBM program is really good enough to us Macintosh folks?) The main interesting point on this machine was the presentation of RagTime on it: Its authors Mr. Brüning and Mr. Everth where running a color version of RagTime. It shows an excellent color and b&w shading, much better as all known IBM EGA displays. The letters where sharp and excellently legible, also in 9-point sizes. In fact, the only equivalent monitor was one I have seen in a computer graphics studio. This was about 43,000 -- DM($12,000). Apple has done a very good Job with these video displays.

Now the software: There was --as noted above-- a new version of RagTime, which includes (in Germany) word wrapping, color display and new layout possibilities. But the main interesting software was 4th Dimension: A fully relational, programmable database which allows to create Macintosh-like programs [Silver Surfer]. In fact, it was a mixture between FileVision, Omnis 3 and Microsoft File, but it’s power is much more than only a combined version of these three programs. The example shown at the fair looks like a program explicitly written in a programming language, with it’s own buttons, user-defined windows, specialized controls and so on. The programming language is very near Pascal with a lot of predefined routines. It can create and read several files formats, including SYLK and ASCII text. The author searches 170 records from about 10,000 and exports them to Excel. This action (searching, quitting and then starting Excel) takes about 30 seconds! It is possible to disable items according to the data. In the example shown, a complete list of French wine yards, (yes, it was graphically shown where the wine yards are), the author disabled the button “My Cellar” if the selected Wine wasn’t in his cellar, so the personal notes about this wine (which were in their own windows) cannot be changed.

I think this is the biggest deal for the Macintosh since MacWrite. 4th Dimension overrides any other known database, including mainframe databases, because of its speed and programmability. If you buy it, it comes with a complete software developers environment and the licenses for runtime units, so from the end users view everything comes from one hand, and he has not to buy a database program.

Another thing new on CeBit was APD: Apple Programmierer Deuschland. This new user group is much like APDA: if, from Europe, you want something from APDA, their is no other way to get it than flying to America and buy it there. (I tried to get MPW here in Germany: It was impossible.) Many tools aren’t available here, and one intention of APD is to distribute these things. A developers conference is planned for April 23rd 87 in Frankfurt/Main, and that should help local developer groups. This sounds very good, huh?

OK, this was what I’ve seen in Hannover at Apple. It was very interesting to look at Macintoshes growing and the plans of Apple. A last word at IBM: they had the biggest presentation, but at Apple were the most people. Pagemaker on the IBM works very slow (on AT03), and it needs a special monitor, Intel Above Memory, a hard disk and an Apple LaserWriter to work. For less money you can (in Germany) buy a Macintosh II with 40 megabytes, a LaserWriter, Ragtime, some Postscript tools which work approximately four times as fast. The shown databases where slow and ugly to use, most incompatible with other applications and lack the graphic data storing. Programmers environments are very expensive on the PC’s. And last, but not least, the documentation for MS-DOS Computers is bad against IM; after reading IBM technical handbooks I think IM is a Roman.

So I’ve found I decided the best computer one year ago: The Macintosh. It shows the power of a continuous hardware and software concept without critical changes in the system.

PCMacBasic Underestimated

Dr. Peter Markiewicz

I am writing in response to the recent Basic article comparing the relative strengths and weaknesses of the compilers currently on the market. I think in giving the PCMacBasic compiler a low rating, you are missing the main advantage it has over the others, as well as the major purpose many people buy a Mac Basic compiler for, which is to modify existing programs to run on a new machine.

I am not a professional programmer, and as such much of the work I do involves modifying public-domain scientific programs to run on the Macintosh. I simply don’t have the time to ‘start from scratch’ without changing my career. Nearly all the Basic programs I have worked with originally started life on an IBM PC in BasicA, and my purpose is to 1) make these programs run on a Mac, and 2) improve their operation by adding features of the Mac environment such as windows, menus, and so on. Frequently, they consist of a large number of small programs integration, with each becoming a single menu item in a larger Mac program. There are usually several parameters that must be set for their operation, for which complex Dialog boxes are the natural choice. Furthermore, many of the programs share the same dialogs in the larger package.

For programming of this type, the PCMacBasic compiler wins hands down over every other compiler in the market! I can say this because in a recent project to port and integrate a set of 20 DNA sequence analysis programs, I tried every compiler except Softworks, and was unable to do the job until I started using PCMacBasic! I’ll list the features it supplied which were essential to my project, which are supported nowhere else:

1) Immediate operation of BasicA programs after transfer onto a Mac. All the programs I ported to the Mac ran with virtually no modification when compiled with PCMacBasic. By contrast, it required several days work to modify a single program of the set to compile with MS Basic, and I couldn’t get it to work with ZBasic without totally rewriting the program, due to differences in random access file commands. As I said, I don’t have time to do rewrites.

2) Rapid conversion of programs using function keys to pull-down menus. Once again, it was possible to rapidly convert a function-key driven program to one using pull-down menus. With the other compilers, the only alternative is to completely scrap the code and write menu-handling routines, which was impractical without rewriting the programs.

3) PCMacBasic is the only compiler that provided acceptable support for building complex dialog boxes. I was able to quickly define the Dialogs in the resource file, create, modify, and collect user input without having to rewrite the programs or use ROM calls. Radio buttons were managed by the Runtime, without any Basic coding. Several of the subprograms in the package were able to share the dialog without writing additional code. The simplicity of polling and modifying the dialogs within BASIC was unmatched by any of the other programs, where dialogs cannot be created as resources and modified in memory without a lot of ROM calls.

4) Package support. The most serious problem with MS Basic and ZBasic to my mind is the difficulty in defining local variables (including strings), and integrating a set of CHAINING programs into a single application. It is very difficult to fuse several small programs into a large one with ZBasic and MS Basic because of this, one cannot arbitrarily define all the variables in a section of the program as local. The CHAIN command in the other systems involves unacceptable time, and the programs are all still separate files, just waiting for the user to accidentally remove a few and bomb the rest. With PCMacBasic, the PROGRAM, CHAIN, and COMMON directive allowed painless integration of a large set of programs into one package, without worrying about variable conflicts. Adding a new program to the package was almost like adding on a function in C. The individual programs became segments, which made for excellent memory management. As a result, it was possible to fuse all 20 programs into a single 200K application, and still have it run on a 128K Mac! The SEGMENT directive in ZBasic doesn’t compare. Once again, to do this with the other compilers would have involved a complete rewrite of the code.

5) File management and NAMEing. PCMacBasic supports HFS, and the FILES$ command supports opening or printing files from the Finder in a single line of code. One can quickly specify types and Creators with the NAME command. I tried this in ZBasic (3.02), but got occasional bombs. The PCMac form worked well enough, however that I could allow the user to specify the type of output file they wanted in a scrolling dialog!

To summarize:

If you don’t have the time to rewrite an application from scratch, and want or have to use an existing BasicA program, PCMacBasic is by far the best choice. I agree that it is not the best environment to develop a new program. It has serious limitations in areas like printer support and slow execution of compiled programs. However, I think that many of the Basic programmers out their, (including those reading MacTutor), are not professionals with the time to write from scratch, want to take programs off the IBM to run on the Mac, and quickly add a Mac-style without rewrites.

I suggest that the next time you compare compilers, you include a “Ease of porting existing programs” section. I think you will agree that PCMacBasic is by far the best in this area for the reasons mentioned above.[PCMacBasic has come back from the dead, with the authors working on a new release. We’ll ask Dave Kelly to investigate. Ed]

Apple’s Solder Machines Don’t

Chuck Rusch

I just finished Loy Spurlock’s letter about the Mac’s power board problems in the March ’87 MacTutor, and I couldn’t agree more. I own an upgrade and peripherals business which is out of necessity getting more and more into the service and repair end of things. I don’t have Loy’s electronic expertise (when we can’t fix a board we send it to his company, Computer Quick), but I have done about 600 memory upgrades over the last two years (mostly Levco), know the inside of the Mac pretty well now, and would like to expand on a few of Loy’s points.

On page 5, he says that 9 out of 10 power board failures are in the video circuitry part of the board, and 8 of those 9 are flyback transformer failures, probably due to heat. I know he’s talking about heat in the box, and hot spots on the power board, but up here in the cool Northwest, while we are fixing a lot of power boards, I only replace a flyback occasionally. The big problem here is cold solder joints which he outlines in the next paragraph. In fact, the cold solder joint problem is so bad that I have taken to making a routine visual inspection of the power board with a 6 power scope whenever I open up a Mac --regardless of whether there is any reported trouble with the Mac’s sweep power supply (Apple’s term for the board). Over the last month and a half on about 15 machines I have serviced which have power boards over two years old (most are newer), I have yet to find even one which was free of cold solder joints with visible cracks. That’s right, 100% of the older boards are either failing or look like they are about to fail. I have serviced probably 40 or so old power boards over the last six months and usually there are about six bad joints with visible cracks and another half dozen which look suspect.

These bad joints occur in one of four areas on the board, and right where Loy says they are --where there is a large metal lead or pin on the other side of the board. The biggest offenders are the joints which hold the cable connectors. There are three cables connecting the power board to the rest of the computer. Near the top of the board is a four-pin connector which carries the sweep signals to the yoke of the CRT. The top pin carries a lot of current and controls the horizontal sweep signal. When that joint fails, or gets interrupted, all you get on the screen is a thin vertical line. On old boards, that joint almost always has a thin circular crack around the pin sticking through from the other side. When this crack gets wide enough, the current is interrupted, at first intermittently. Getting a lot of current through an intermittent joint apparently causes an enormous heat buildup. I have seen boards where part of the nylon housing for the connector to that pin was completely burned out, as in, gone. There is often scorching of the board around the pin. When it gets really bad, the heat and possible voltage surges begin to take out components in related parts of the circuitry. A sort of domino effect fans out from the joint, and can easily wipe out a half-dozen components or more. The bottom joint in that row of four is the next most likely to go bad and when it does, it takes out the vertical sweep on the upper or lower half of the picture, leaving only the other half.

The next two joints most likely to be cold and cracked are the end pins in the ten-wire connector for the power cable which goes to the digital /logic/ mother board. This row is horizontal, near the center of the board, and the joint toward the front is the first to crack. Because interruptions here are interruptions to the logic board, symptoms include system bombs and spurious resetting. The third connector is the seven-wire cable carrying power to the CRT gun at the back of the tube. Cracks in these joints are less frequent, but not uncommon. I am less sure which are most likely to fail here, I check them all under magnification. As for symptoms, I remember a few machines with wavy lines on the screen, but cannot be certain they originated from this row of connections.

The fourth are most likely to have cold cracked joints is that of the flyback transformer itself. These heavy metal pins form a circle of nine joints. There are actually two circles, one for the earlier smaller transformer which Loy describes as failing frequently, and a larger wider tangential circle of holes for the more recent robust transformer which Loy (and Apple) now use as replacement for the smaller one. Interesting that the holes for both sizes of transformers were designed into the original board from the beginning.

In my experience, the above 31 joints account for most of the cold solder joint failures. I have found others which have been cracked, but not many in Loy’s other likely category --those connected to large foil planes in the board.

Let me now give my version of what I think is happening to the power boards, why so many are failing, and what we, as end-users, can do about it. First let me say that what we are discussing here is only true for old boards, particularly those in the original 128k machines. If you have a Mac which is at least two years old and has never had the power board replaced, this is your Mac. A quick way to check is to take the battery door off and see if it has a silver or black case-mounting screw. If it has a black screw and the power board has never been replaced, it is an older board and we’re probably talking about your Mac. I have found very few problems with the joints on the newer boards with silver mounting screws. The color of the screw obviously has nothing to do with the problem; it is just a quick indicator of age. Apple has either found a way of correcting the problem, or it hasn’t shown up yet in the newer boards.

Now, as for the older boards, while it is true that some of the components are cheaper than they could have been and are failing outright as a result, it seems to me a lot of the trouble is just bad soldering. Why would a company as careful as Apple is about quality control let bad solder joints slip by? The answer is that there was no way they could tell they were bad. We have heard about the burn-in time on the bench, the torture tests, etc., that all Macs undergo at the factory. The early power boards also have a mark made with red marker, on every solder joint. That means that each one was visually inspected by a human being, and it looked good at the time. So every joint looked good and passed the tests before leaving the factory, but some of them, two years later, are cracking up and failing. Let me propose a possible scenario of how that could have happened.

The boards are soldered by passing them over a wave-soldering machine. The temperature of the solder can be set at any temperature needed, but if it is too hot, the small components on the board can be damaged, and if it is too cool, the large components will draw heat out of the joint before it sets correctly and a cold solder joint will result. So setting the temperature or boards with a wide variety of component sizes is a bit tricky. A cold solder joint is one which is crystalline in nature rather than a solid “fluid” amalgam. Normally a cold joint looks dull and a bit textured rather than bright and shiny, but sometimes it is hard to tell the difference. So some joints, particularly those with long metal pins or leads on the other side of the board, set up as cold crystalline joints and slip by the visual inspection. They also get by the burn-in test because there is plenty of surface contact at the joint initially to carry the current. I’ve been told that use of heat-resistant components will resolve this problem, but I have no way of knowing whether Apple used such components on the early Macs.

But once a Mac is sold, the situation begins to change. Now the machine is in the user’s hands and it gets turned off and on constantly. Everytime it is turned on, the joints heat up and expand; everytime it is turned off, they cool down and contract. A proper joint can take that expansion and contraction, but in a crystalline one, the crystals begin to break apart. Where? Right at the joint between the metal pin and the solder, hence the circular cracks. After two years of so, the cracks become wide enough so that the current is interrupted, if only momentarily. Result? A system bomb, a reset, the picture collapsing to a thin vertical line and then restoring itself, the upper or lower half of the picture going out, wavy lines across the screen, etc. If not corrected, the problems get worse; interruptions are more frequent, severe overheating and voltage surges begin to take down other components, the user winds up with a “smoking Mac”, and the whole board has to be replaced. Perhaps this is why some of the flybacks are overheating as well.

One customer told me that his power board went up in smoke just as he loaded a desk accessory called “Toaster”; at least he seemed to enjoy the irony, if not the expense. If caught in time, all that is needed is to have those bad joints resoldered at a high enough temperature to make a solid connection. I am now inspecting and resoldering up to five old boards a week, and as I said above, I have yet to find an old one without bad joints on it.

Finally, let me add a footnote about the three double-stick pads which hold the plastic cover onto the power board. This cover is important. The power board has some pretty high voltages on it and can be dangerous if touched at the wrong time, but the cover has to be removed to inspect the joints on the board. Further, one of those 1"x1" pads is stuck over the four vertical sweep joints which I mentioned above as being among those likely to be bad. I usually pull the cover off, tearing each pad in half, although you can get by with just pulling the top one in half, bending back the cover to get at the board, and holding ti back with the side of your arm while you work on the board. I then cut and scrape off the part of the pad stuck to those sweep joints needing inspection, being careful not to damage the board. A good fingernail works well here. When I am done resoldering the joints, a little rubber cement to both surfaces will re-glue the pads back together. I’ve wondered a bit whether the pad could be part of the reason the sweep joints are the first to go. In theory, the pad could insulate the joints, causing them to get hotter and expand even more than they would have otherwise, breaking those crystals down faster. Maybe, maybe not, but I trim that particular pad back so that it is not covering those joints, just in case.

The point of being so detailed about all this is that if the little scenario I’ve outlined above is true, and the 100% figure holds up, we are in for a real flood of bad power boards. Your option is to pay a dealer about $165 to replace it, or find someone who knows where to look (and how to solder) to go over it for you before it goes bad. [“You pay me now, or you pay me later”] I charge $35 to open the Mac, inspect the board, resolder the bad joints, check and reset the voltage and put it all back together. I charge $20, if I’m already inside the Mac for some other reason, like adding a fan or doing a memory upgrade. Others might want a little more; I think up to $50 would still be worth it. I figure I’m adding to the life of the board through this service. I don’t recommend it unless your machine is at least two year’s old, but I have found bad joints on newer boards; there just aren’t as many of them and their cracks are not as big.

Some of the above may be electronically inaccurate, I don’t pretend to know the power board like Loy Spurlock knows it, but maybe there is enough truth here to help save a few more Macs. At least I’m not bad-mouthing the power supply itself; I’m fingering the cold solder joints, and who could love a cold solder joint? If your power board has just recently gone up in smoke, send it to Loy, his crew is really good at component repair, and at a fraction of the normal cost of replacing it.

TextEdit and MS Basic 3.0

Blake Miller

I have been keeping up with your articles for some time now. I have every issue of the magazine. I am letting you know, so you do not think I just came out of the backwoods of Alabama....

After reading your recent article on BASIC in the March 1987 issue of MacTutor, I have noticed that these strange and arcane words were also highlighted with my version of MS BASIC 3.0 BINARY as well. “Spurred on by the curiosity of one so entranced with things not oft told the common man for fear he were to cause some inadvertent harm”, I rushed for my copy of Macintosh Revealed, turned to the section on TE Edit and immediately began to type in the rest of the TE commands which are in the ROM. Perhaps you did the same?

The enclosed page of paper displays my results. Other commands are highlighted too. I have indicated what I would believe to be the correct syntax for using these with MS BASIC. This is based upon what MS used for their example on the disk. That is,

• A Handle is returned by WINDOW(6)

• The address of the text is returned by SADD(Text$)

• The Length is returned by LEN(Text$)

• A rect is given by VARPTR(Rect(0))

I have tried TEScroll with varied results. This command does indeed scroll the text. It will move it anywhere you want within the Edit Field. However, it, as well as TECalText, TESetText, and TEUpdate, do not wrap the darn text!

According to Macintosh Revealed V2, on page 244, it says that “TECalText wraps a edit record’s text to its destination rectangle, calculating its line starts and nlines.” Fine and dandy. I should expect so much from MS BASIC with a command that is not “official”. However, they use TESetText in their example on the disk. This is the program which reads the text files. In Macintosh Revealed V2 on page 242 and 243, it also states that “TESetText sets the text to be edited by an edit record.” And that “TESetTex automatically wraps the new text to the destination rectangle, calculating its line starts and nlines.” With “The new text is not automatically displayed on the screen; call TEUpdate to display it.”

When you examine what TEUpdate is supposed to do, you will find that Macintosh Revealed again says that “TEUpdate draws an edit record’s text in its graphics port. .....updRect is a rectangle in the local coordinates of the record’s port (usually a window). The text to be drawn will be clipped to the intersection of the rectangle with the record’s view rectangle.” And again “The record’s text is automatically rewrapped to its destination rectangle before drawing; there’s no need to call TECalText first.”

Well, I tried another text file with the example program that MS sent on the disk. Unless you have saved your original word processing file to have a carriage return after every line, your text will go off into the weeds off the right edge of your window or edit field. THERE IS NO WRAPPING OF TEXT! I have written small sample programs trying all manner of these calls and parameters with the Edit Field statement and all. I can not get any text to wrap.

I made the edit field contents scroll with TEScroll, and if I went far enough around, I could see all my text way out there at the end of the line, but there was not wrapping into the “destination rectangle”. It seems that somehow, the wires have been crossed between the ROM and what MS BASIC does in an Edit Field with an edit record.

I will try to write a line editor using the TEScroll and some of the things I have talked about here. If I can, I will send you guys a copy. In the meantime, if you learn anything about how the TE functions can be used to wrap text, please let us all out here know soon (via MacTutor, of course). This will be greatly appreciated.

[Text is drawn with TEUdate, which uses the line starts array (TECalText) to wrap the text to the destination rectangle. If your destination rectangle is larger than your view rectangle, typically your screen, then the text appears not to wrap. In order to get it to wrap where you can see it, the destination rectangle must be the same size or smaller than the view rectangle. Your problem is that MS Basic is changing the destination rectangle so it can accommodate long program lines. TextEdit is wrapping the lines, but not to the rectangle you think. -Ed]

TESETTEXT SADD(Notes$),LEN(Notes$),WINDOW(6)
TECALTEXT WINDOW(6)
TEUPDATE VARPTR(RECT(0)),WINDOW(6)
TESCROLL HorizPixInt, VertPixInt, WINDOW(6)
TESETSELECT CharPosStart, CharPosEnd, WINDOW(6)
TEACTIVATE WINDOW(6)
TEDEACTIVATE WINDOW(6)
TEKEY SADD(Char$)+1,WINDOW(6)
TEDELETE WINDOW(6)
TEINSERT SADD(InserText$),LEN(InsertText$),WINDOW(6)

$10,000 PhotoTypesetter

W. McBride

I wish to answer a question from your MacWorld Expo Resort which was published in the March MacTutor:

question: $10,000 Phototypesetter?

answer: Yes

That bit was easy but now lets get down to business. Let me give you a few figures first to wet our appetites. The 70,000 Macs here in France include all types. Apple France now has reduced its authorized Mac dealers to 300, not counting the VAR’s. The MacPlus now costs 19,900 francs ($3,350). Here’s the one you’ve been waiting for. About ten months ago, the Allied Linotype L-100 was reduced in France from 440,000 francs ($74,576) to 330,000 francs ($55,932). If follows that you don’t find such a beast down at your local friendly copy shop, but I didn’t just want to talk to you about Linotype politics. I note with much interest that the postscript RIP is available from Adobe and I would not be at all surprised if you have already found a marking engine at the required resolution. In case it wasn’t already clear, I wish to be involved in your project to design, construct and market a phototypesetter which is within the grasp of at least a part of the Macintosh community. Your $10,000 figure is very significant. When the Apple LaserWriter was introduced, it cost just that amount, whereas today it is down to $8,400. if your project includes from the outset a realistic approach to the European market-place, I’m sure it would really go places. The management of its development and marketing is critical and the time is right. [Unfortunately, the project is stalled for lack of a suitable phototypesetting engine mechanism. It seems all the phototypesetters are custom engineered by the same companies trying to rip us off. No one has an OEM engine. Compu-Graphic has a new offering in the postscript desktop market: $100,000 for the whole system. Vari-Typer has a new 600 dot per inch LaserWriter: $18,000. Meanwhile, Allied remains the only postscript phototypesetter: $50,000. -Ed]

Loves MacTutor

Glenn McPherson

I have been purchasing MacTutor off the newsstand since 1984. Now that I have the time to seriously develop software for the Mac, I am subscribing to your fine magazine. Each month I get Dr. Dobb’s, Computer Language, PC Tech Journal, and BYTE as well as many other non-technical magazines. MacTutor is one of the best (the BEST for the Mac) journals that I read. Keep up the good work!

Basic Compiler vs Interpreter

Steven C. Leach

I would like to put in my two cents worth about the new Microsoft Compiler (V1). Yes it does create big code, and it is certainly not the fastest compiler around but the combination of interpreter compiler environment is one I find very hard to beat. I bought Lightspeed C as soon as it was available, I even paid list price out of my own pocket, and I am not a developer. Whenever I can get away with it, I use the MS Basic with all of the CLR libraries I need.

The main reason for my writing this letter is to let others know some of the quirks of the MS compiler (V1) versus the Interpreter (V3). Most of these quirks show up when your source starts getting above 64K (that’s only an estimate; I have not looked into the compiler with MacNosy nor do I want to).

1) The interpreter gladly allows the programmer to DIM an array by simply declaring the array and using it in a piece of program, providing the index never goes above ten there is no problem.

The compiled program will do likewise until a certain program size is reached then it starts giving the user a run time error number 38, which is of course, not documented. So if you get run time error 38 start looking for an undimensioned array.

2) The interpreter doesn’t care if you use multiple statements on a line, providing you don’t exceed a line length of 255 characters.

The complied program will actually cause a system error ID=02 when the subroutine levels get more than 3 and the program size exceeds the 64K level. In the documentation it says that multiple statements on a line are no longer necessary, but of course does not mention this problem.

3) The interpreter will happily perform a CLOSE #1 even if file #1 has been closed before this statement is executed.

The compiled program of course chokes on this occurrence and causes an ID=02 system error. Admittedly this situation is rare, as a matter of fact, I found this quirk only by mistake (my mistake).

4) Last, but not least by a long shot, is that the compiled programs seem to be unable to read the serial port with any accuracy or consistency what so ever. I haven’t figured this problem out so if any one can help I would be very grateful. [It’s a bug and there is a patch fix to the compiler. -Ed]

These situations occurred on several different programs, the source text file for the interpreter ran between 70-120K and of course the compiled programs ran well over the 100K mark. Oh well it’s a great way to debug programs that have to be done inside a month or two.

Thank you for providing this forum. Have you thought about Genie or CompuServe as an online service so we can make local calls and upload, download all your great stuff? One last request, could someone please write an article on how to give an application from one of the basic compiler an icon, and of course how to give an icon to the files produced from that application?

MS Basic Suggestions

G.M. Greytak

Double Daves: Keep up the good work. It is to your credit that Microsoft relies on your judgement.

You asked for suggestions for improvements to BASIC. I have a few which may not occur to most users. I use BASIC in an interpretative mode to write ad-hoc simulations relative to Civil Engineering and business problems I am studying. Looping through a range of parameters helps me determine the sensitivity of a design to them. Graphing the results gives me reassurance that the algorithm is the proper one. The questions I consider do not lend themselves to applications. CivilSoft, Excel, etc. impose constraints which limit what I wish to explore.

• It would be nice to use the Greek alphabet for variable names as single characters, not SIGMA.

• Working in radians is unnatural. Wouldn’t it be nice to declare degrees instead of writing and calling a function.

• So would being able to re-define the origin of the screen say x=256, y=171 or 0,342 instead of the present 0,0 at upper left.

• MacDraw can plot Multi-pages, wouldn’t it be nice to plot to several windows (virtual screens) (Do you recall the stripchart mode in Appleplot?)

• How about multi-line function declarations?

• Or MAT(matrix) commands/operations?

• I believe that there are SANE functions which are not usually implemented, i.e. Present value(parameter list including i,n). Using something of this nature is more user friendly than digging up the math handbook for the formula.

• I don’t believe CLR libraries contains some of the interesting possibilities, eg: the area under the normal curve to a given z value.

• In any case the incorporation of some of the libraries makes the wish for all of them to be available in the language itself.

In other words, I want BASIC to be a smart computation pad. [I agree! It is a great frustration of mine that no one yet knows how to write a suitable Basic for the Mac. Maybe we could license HP’s 9836 Basic? -Ed]

New Word for the Mac

Sarah Chart

A new release of Microsoft Word 3.01 is scheduled to be released in June that will work with the Mac II and fix all known problems in version 3.0 (see mousehole column). This update will be sent at no charge to all registered users of version 3.0. A special thank you goes out to all individuals who took the time to contact Microsoft with problems found in version 3.0.