Letters

Seymour Cray on Macintosh

S.C. Kim Hunter

In case you missed this gem from the Wall Street Journal, Dec. 30, 1986, I thought I’d pass this along to you. It seems John Scully mentioned at the December Boston conference on high technology how Apple had recently bought a Cray supercomputer for a cool $14.5 million to design the next generation Apple. This prompted the following remarks from John Rollwagen, Cray’s chief executive, as quoted in the Wall Street Journal article: “since they were good enough to buy one of our machines, some of us have bought a few of theirs.” Later Mr. Rollwagen told Seymour Cray, the company founder, about how Apple was using the machine, and he related Mr. Cray’s reaction saying “There was a pause on the other end of the line, and Seymour said, ‘That’s interesting, because I’m designing the next Cray with an Apple!’ “

Prolog Wanted

Greg Pisanich

Hi! Being one of your loyal subscribers, I’ve noticed a real dearth of Prolog articles in your magazine. I mean, with two seperate advertisers spending all that money and no articles to help hype their product, you guys should be ashamed! [We are, especially since we have one article waiting to run! -Ed] Wait! No! No! Don’t tear the letter up yet! I’m not writing to criticize! I’m writing to ask for one of your author’s kit. I’ve been working with prolog on the Mac for awhile now and I’d like to take a stab at writing a series of articles your your excellent publication. I work at Hughes Radar, in El Segundo. Our department does software tools, although my work currently involves an expert system to be used in threat recognition (shoot ‘em down first!). Some of my school work at UCLA has been done in Prolog as that’s really the only chance I get to work with it.

C Toolbox Tricks

Jean-Michel Decombe

I have been reading you since the first issue. Since the first issue, I came to the conclusion that MacTutor is the best magazine for the Macintosh. It would be great if you could start a Trick Corner, where you would give the right code for the right need. For example, how to write a zoomrect() function, how to widen the prjobdialog in order to add buttons, and so forth. Here are some of my tricks in C and now I ask you: What is the best way to write in the data fork of the running program. I write this and it works, but I’m not sure it’s the right way to do it. [Is there a right way on the Mac? (Note, this code has been hand typed.) -Ed]

Writing to the Data Fork of a File in C:

char  thename[64];
handle  thehandle;
int   thevolref, theappref;
long  thelong;
ptr   theptr;

 getvol(&thename,&thevolref);
 getappparms(&thename,&theappref,&thehandle);
 thelong=BEFORE;
 fsopen(thename,thevolref,&theappref);
 fsread(theappref,&thelong,theptr);
 fsclose(theappref);
  
 thelong=AFTER;
 fsopen(thename,thevolref,&theappref);
 fswrite(theappref,&thelong,theptr);
 fsclose(theappref);

ZoomRect() Function in C:

zoomrect(srect,drect,expand) rect *srect,*drect;   boolean expand;
{
grafptr saveport,deskport;
rect    r[17];
long    unit;
int     count;

 getport(&saveport);
 getwmgrport(&deskport);
 initport(deskport);
 penmode(notpatxor);
 penpat(&gray);
 for(count=0;count<=22;count++) {
 if(count<=16) {
 r[count]=*srect;
 unit=(expand?count+1:33-count)*count/2;

r[count].a.top+=(unit*(drect->a.top-srect->a.top))/136;
r[count].a.left+=(unit*(drect->a.left-srect->a.left))/136;
r[count].a.bottom+=(unit*(drect->a.bottom-srect->a.bottom))/136;
r[count].a.right+=(unit*(drect->a.right-srect->a.right))/136;

 framerect(&r[count]);}
 if(count>=6)
 framerect(&r[count-6];}
penmode(patcopy);
penpat(&black);
setport(saveport);
}

The values employed here are the results of several tests. Before, there were formulas instead, but I tried, choosed the better values and put them instead of the formulas, for a greater speed. You must use the function with three parameters: the source and destination rectangles, in global coordinates, and the expand boolean (fast to slow or slow to fast zoom effect). Like this:

zoomwindow(thewindow,openit)
windowptr thewindow;
boolean openit; 
{
int     theint;
rect    startrect,windowrect;
 setport(thewindow);
 setrect(&startrect,0,0,256,171);
 windowrect=thewindow->portrect;
 localtoglobal(&windowrect.b.topleft);
 localtoglobal(&windowrect.b.botright);
 if(openit) {
 zoomrect(&startrect,&windowrect,TRUE);
 showwindow(thewindow); }
 else {
 hidewindow(thewindow);
 zoomrect(&windowrect,&startrect,FALSE); } 
}

Likes MPW

Mark Lankton

While I’m sitting here I’ll pass on a few thoughts about MPW I’ve been working with the shell/assembler and the C compiler for about a month, and I’ve got to say I’m impressed. The shell is extremely powerful, and while it seems un-Mac-like, the convenience of using it to develop programs won me over in a hurry. I routinely rebuild a program (after a crash-debug-edit interval) with a single tap of the enter key that’s tought to beat. The C compiler makes tight, fast code, better than any other I’ve seen on the mac. There are already a nice bunch of tools around, and you can bet taht there will be many more in short order. It’s good stuff, and if it isn’t as flashy as Lightspeed at first glance, well look again. One thing for sure, it has the look of a system intended for use on some “serious” hardware- so bring on the new machines!

StringOf Bug in LSP

Evan Torrie

I was trying to convert one of my MacPascal programs the other day into Lightspeed Pascal, when I came across the following bug. My Lightspeed version 1.0 will do the first bit okay using NumToString, but when I get to the second bit using StringOf, the variable j goes haywire and goes into an endless loop after the program has been run three times successively. [StringOf is buggy in the current version. -Editor] By the way, I think Lightspeed is the best software development system I’ve seen for the Mac. What would have taken me hours of frustration to bedug in TML, takes me only 10 minutes in Lightspeed. The only things I wish for are a compile to assembly langauge option and 68020 support. [We want those too! And an assembler! -Ed] Here’s the bug:

program LSBug;
var
 i,j:integer;
 theString:Str255;
begin
 showText;
 {NumToString works OK}
 for i:=1 to 2 do
 for j:=1 to 2 do
 begin
 NumToString(i,theString);
 Writeln(i,j);
 end;
 { But StringOf makes the program go haywire! }
 for i:=1 to 2 do
 for j:=1 to 2 do
 begin
 theString:=StringOf(i);
 Writeln(i,j);
 end;
end.

Comments on IC! Bug in NEON

Paul Snively

I just read the August issue with a great deal of interest and some amusement. As usual, I devoured Jörg Langowski’s always excellent Threaded Programming column because he and I have a common interest in threaded languages. To my surprise, he resurrected the old NEON bug in IC! along with a comment from BIX. There still seems to be some question as to why the IC! code insists on rebooting upon being executed.

The ADDQ #3,SP instruction is indeed the culprit, although not for the reasons suggested in the BIX post. The problem does revolve around the fact that the 68000 is a word addressed processor. The author of IC!, obviously assuming that a byte-length instruction on a 68000 actually moves one byte, added three to the SP and moved the resulting byte. This code shows a flawed understanding of byte accesses using the 68000: a byte access always involves two bytes, not one, so the code was wrong from the beginning. To move a byte from the stack might be done with ADDQ #2,SP followed by MOVE.B (SP)+,D0. Another problem is that the author of the IC! routine assumed that the SP could be manipulated like any other address register, which is not the case. Obviously, the stack register is crucial to the proper operation of the entire system.

In elementary school we learn that adding an odd number to an even one results in an odd number 100% of the time. Since that is the case, adding three to the contents of the SP results in an odd SP. One thing that the stack pointer absolutely MUST NOT be made to do is contain an odd address! Since the 68000 is word addressed, all address registers - the SP included - must contain even addresses in order to avoid trouble. An odd address in an address register other than A7 may or may not cause problems - it depends upon the code. In the case of the SP, however, the situation is more critical because of the SP’s importance to the system.

The 68000 notices the bizarre state of affairs, says “That’s odd!” and throws up its hands in despair. It knows of no way to react to an odd SP address but to react as if it had encountered what in 68000 parlance is known as a double bus-fault. That’s about the worst thing that can happen to a 68000. Its reaction is to completely reset itself. Hence the spontaneous rebooting of the Mac upon encountering an ADDQ #3,SP instruction: it acts as a subtle version of RESET or JMP 40000A.

This interesting observation leads me to conclude something disturbing about NEON. The IC! code of NEON is based upon a faulty understanding of byte addressing on the 68000 microprocessor, and is coded badly, to boot. To make matters worse, the problem has been discussed in print over a period of several months and no patch has been forthcoming from Kriya to fix it - and this over a period of time that has seen at least one revision to NEON itself. Suffice it to say that I am somewhat unimpressed with the level of expertise shown by Kriya in their implementation of NEON. It seems to have been written by programmers who were experienced FORTH programmers but who had very little Macintosh (or any other 68000-based machine, for that matter) experience. (No offense to Charles Duff, Norm Iverson, et. al. - and Mr. Duff has since left Kriya and has most recently written a new object-oriented language for the IBM PC family running under Microsoft Windows called “Actor.” Perhaps he found the Windows environment a more friendly one in which to implement his vision of object-oriented programming, although this is pure conjecture on my part).

By the way, it’s interesting to note that some clever programmers (such as those at ICOM Simulations, Inc.) have used the odd SP trick to force a system reboot if their copy protection schemes fail to verify that the disk is an original. This is clever, because any instruction that forces the SP to an odd number will work, making the code difficult to find - what do you search for??? MOVEA.L #1,SP will work, as will SUBQ #7,SP or ADDQ #107,SP - it really doesn’t matter, as long as it’s odd.

Amygdala Newsletter

Rollo Silver

The Mandelbrot Set, M, is a subset of the complex plane (see figure 1). It has been called “the most complicated mathematical object ever discovered”; its boundary is certainly very convoluted, and is in fact a fractal. It is named after Benoit B. Mandelbrot, the pioneer of fractals and the discoverer of M. It can be generated by a mind-boggingly simple process of successive squaring and adding of complex numbers.

The basic question is: given a complex number z, is z in M or not? (note that a complex number z is defined as z = a+bi where a and b are reals, and i is the square root of -1.) We answer the question by generating a series of complex numbers from z as follows.

z0 = z,
z1 = z02 + z,
z2 = z12 + z, 
z3 = z22 + z, etc. 

z is in . For instance, starting with z = i, we get:

z0 = i, 
z1 = -1+i, 
z2 = -i, 
z3 = -1+i, 

and we’re in a loop; all . On the other hand, starting with z=1, we get:

z0 = 1, 
z1 = 2, 
z2 = 5, 
z3 = 26,   

.

Figure 1 The Mandelbrot Set

So what? Well, it turns out that there’s a way of coloring the exterior of M, reflecting its mathematical structure, and the color “views” that you get by magnifying regions near the boundary are mind-blowing, and of inexhaustibly beautiful, literally infinite, variety. The book The Beauty of Fractals, by Peitgen and Richter, published last year, has many wondrous views of M and other fractals, and much related math. The Computer Recreations column in Scientific American (August 1985) was devoted to M, and probably launched the Mandelbrot craze. The coloring is related to the test mentioned above: for each there is a smallest n for which |zn|>2, so each point in the complex plane outside M has an integer associated with it, which I call its dwell number. Using any “coloring by numbers”, e.g. 0 = dark blue, 1 = green, 2 = turquoise, etc., you color each point outside M with the color associated with its dwell number.

A lot of people, myself included, are fascinated with M and other fractals, and so I decided to put out a newsletter, Amygdala, for us. It’s available at the address above for $15 a year (10 issues) or $25 for Canada. You can get a sample issue free for a SASE.

Mac a Mystery

David Price

I earn my living by designing and writing software packages, currently on an Alpha Micro 1092, which is a 68000 machine. I just got a Macintosh Plus for home. It seems to be an incredible machine, yet it has the un-nerving ability to make me feel like I don’t know the first thing about programming! The amount of “front end” material to learn before one can make the machine do the most simple things is at times staggering. I came across your periodical in a computer book store, bought a copy and started a subscription the same day. It seems to be a magazine full of intelligent and useful information, although at times, I feel like I came in on the middle of a conversation.

You are doing a very good job, and I expect to learn a lot from your experienced contributors. Please send a copy of The Best of MacTutor, Vol. 1 so I can catch up on my education.

A Heated defense of MPW

Roger Voss

The editor’s aside comment in a letter appearing in the November 86 issue of MacTutor nearly sent me realing onto the floor! I quote “ we agree with this sentiment and are not even sure MPW is really necessary “, end quote. I couldn’t believe the absolute naivety that this comment represented, coming as an editorial comment from a programming journal for the Macintosh. [I stand by the statement, but your defense of MPW points out many of it’s worthwhile attributes, especially for large multi-person projects. -Ed]

Everyone universally touts the latest programming environments from Think Technologies as being the highest state of programming on the Mac. I agree that Lightspeed C and Pascal represent very worthwhile additions to the Macintosh program language repertoire. I strongly disagree that such environments are also “really” all that the Mac community needs in the way of software development tools and that Apple should “really” stay out of programming tools altogether. This attitude is highly unwarranted. [I never said that! -Ed]

Compiler products from companies such as TML and Think Technologies are very good products and answer the need and requirements for a lot of folks that want to attempt programming the Mac. These types of products, however, ignore the requirements, sophistications, preferences, efficiency-of-working-environment, etc. of important numbers of Macintosh programmers. I am speaking mainly of the non-amateur programmer; working professional software developers that earn their every tidbit of bread and crumb from writing applications and various system software for the Macintosh.

Somehow or another, people have formed the notion that the epitome of a great development environment is very fast compilation and all functionality of the environment accessible via pull-down menus and other Mac metaphors. [It is certainly my preference. -Ed] When one is working on a large complex programming project that ranks into 25 or more seperate compilation units, composed of tens of thousands of lines of source code, and written in a combination of Object Pascal, procedural Pascal, C and 68000 assembly language, one needs a lot more than only a fast compiler and a moderately adept make facility in order to facilitate the day-to-day grind of developing such a program. I can’t begin to estimate the amount of development time and effort I have gained back on my side because of the MPW script language tools that I have written to deal with some sticky aspect of my code development process. Over the many months that I have worked rigorously with MPW I have customized the ease-of-use (and speed-of-use) of the shell/editor environment to very impressive simplicity. The versatility of the shell script language and MPW unix like tools allows one to create fantastic labor saving devices. I save time all the time that I work in the MPW environment because of the fact that it leverages me to work much more efficiently and effectively with a very complex project.

I am very glad that Apple has so seriously pursued the development of a sophisticated and comprehensive software development environment for the Macintosh. The efforts of third party developers have not yet matched Apple’s own as far as bringing forth truly powerful and professional development environments for commercial software production.

Well, I haven’t dropped into the issues of combining multi-lingual compilation units; the options available for various levels of debugging information and debugging code generation; having various levels of code optimization; multi-levels of conditional compilation switches; environment variables that can inform compilers to use different source file interfaces and bodies under different modes of compile objective (and likewise with the linker for object files and libraries, and the make utility for make files). You know, the 68000/68020 assembler in MPW just by itself is more impressive than many third party compiler products. The code generation of the MPW compilers I would take any day over the Think Tech. compilers. The Greenhill C in MPW does a lot of subtle and not so subtle optimizations when you start looking at it under a debugger. I for one greatly applaud Apple for bringing MPW to the Mac world. [Look for an article on the MPW script language next month in MacTutor. -Ed]

Human Touch Disappears

Jeff Hopkins

Great Journal! The best yet for any computer system. I have a big question; what happend to Human Touch Computer Products? I’m one of the lucky (unlucky?) few who received one of their Macintosh upgrade boards. It works falwlessly. The 12 Mhz 68000 doubles the Mac’s computing speed. This is one of the best engineered Mac products I’ve seen. Unfortunately, Human Touch no longer seems to exist. Has someone bought the line, or is it for sale? It’s a shame to see such a good product off the market.

Mouse Freezing Effects

John Baxter

In response to the item headed Folders and Mouse Freezing in the Mousehole column in December ’86, I found that if I put Apple’s Hard Disk Backup program into a folder on the HD-20SC, that folder became a “deadly folder” as described in the column. I solved the problem by creating a floppy from which to run Hard Disk Backup (which makes sense, anyhow, since such a floppy would be needed for many restoration operations). The folder in question was in the root level directly. System 3.2, finder 5.3, stock Mac Plus. (How about more MacForth coverage? It’s my primary development system on the Mac.)

Fortran Coverage?

Paul Waterstroat

Great magazine - keep up the good work! You are providing a unique and poweful tool to the Macintosh community. I’ve noticed that your Fortran coverage has been somewhat spotty of late. It is my opinion that the programming environment provided to Mac programmers of Fortran is the weakest of any major language on the Mac. I feel the Fortran programmers have the most to gain from a tool like MacTutor. I hope that a regular Fortran column returns soon. [Fortran took a back seat waiting for Microsoft to finish fixing the package for HFS. Now that they have released version 2.2 (and sent us a copy!) we expect to cover Fortran again as the CAD/CAM tool of choice for the new family of Mac workstations. -Ed]

Fortran & QUED 1.5 Bug

S.C. Kim Hunter

Microsoft Fortran version 2.2 does not do integer to real conversions correctly. Try this example:

PROGRAM DOSQRT
REAL X
X = SQRT(2)
WRITE(*,*) X
PAUSE
END

result: X = 5.3196E+08

Now change to add decimal point to get the correct result:

X = SQRT(2.)

result: X = 1.414214, as expected. Moral: Don’t rely on implicit integer to real conversion in the Fortran functions.

Here is a real bad one. QUED 1.5 just destroyed a MacServe volume on my XL hard disk! How? By printing more than one file to a Laserwriter from the finder when the QUED clipboard is active. Here are the steps that caused the problem (Believe me, don’t try it yourself!):

1. Install QUED and 2 or more text files in a MacServe volume. 2. Set up QUED with ‘clipboard’ checked on the QUED edit menu. 3. Save QUED defaults (which makes clipboard active when QUED loads). 4. Quit to finder. 5. From a user Mac, access the MacServe volume with QUED and files. 6. Select 2 or more QUED text fifels in the finder desktop. (Text files and QUED are on the MacXL MacServe volume, being selected from another user Mac Plus or Mac 512) 7. Choose Print from the file menu. 8. Sit back and watch the fireworks.

Qued does the following. It loads in with no menu bar (logo instead). The first file is printed OK, but not that the laserwriter dialog says ‘document: clipboard’! After that it’s mush time. The post status of the MacServe volume is such that the MacServe DA ‘shared’, ‘private’ and ‘release’ buttons are dimmed on all Macs. Can’t get at the volume! Any attempt to remove volume says volume is busy. The volume has to be deleted with Mactools.

If the clipboard is deactivated in QUED, finder printing can work OK, but after the second file prints, the menu bar becomes active. Any attempt to do much of anything bombs with ID=10. QUED has a printer spooling feature, and is also able to print the clipboard. I suspect these options are confusing each other when using a laserwriter.

Wants a good assembler

Paul Meyerholtz

I have been reading MacTutor for a couple of months and have found it a fantastic magazine. (I know you get a lot of these letters, but you always print them so you must not be tired of hearing it.) [I’m not! -Ed]

I don’t have a Mac of my own, but use one from work. I’m waiting for the 87 product announcements to get one for myself. I am at the moment interested mostly in assembly and have MDS version 1.0. It is getting me started, but its deficiencies are obvious. When I get Mac, I’ll also want to buy a new assembler. Do you have any comments on which is best? In the future I will also be programming in Pascal and hopefully C. I just sent off my membership to APDA. [I use the Consulair C as my assembler because it works better than MDS on a Mac Plus. But the best assembler by far appears to be the new MPW assembler. I’d take a good look at that one. -Ed]

Likes VIP

Jim Bishara

I have purchased VIP and am very excited about it. Mainstay indicated that MacTutor will have some future articles on it. I have made some comments about VIP and sent them to Mainstay. Here are a few of them:

- Printing from VIP wastes paper. Best to save as a text file and edit out unnecessary line feeds.

- It feels “wrong” not to have a RETURN statement at the end of a subroutine.

- The cmd-D feature to interrput a program during execution is very nice.

- VIP has a severe shortcoming in not being able to observe more than one variable at a time. This should be a high priority enhancement.

- More explanation on resources should be added to the manual.

- I don’t understand how one could create a MacWrite type FONT menu in VIP since it doesn’t support the following toolbox calls: GetFNum, GetFName and RealFont. These should be added.

- A translator from VIP to Pascal or C will only be of value if it produces a complete program, not just the text equivalent of the VIP source code.