Letters

By David E. Smith, Editor & Publisher, MacTutor

Colorizer Restores CMD-Shift-3

Kenelm W. Philip

I think you owe an apology to Joel West (Palomar Software). In the November issue of MacTutor, you comment on page 12: “There is still no way to capture the screen image of a color display.” On page 6 of the same issue is an ad for Colorizer, which mentions that this program will “Record full-color screen images to disk or printer”. Apparently the left hand knoweth not what the right hand is doing

As a satisfied user of Colorizer, I can vouch for the fact that the package contains an FKey which will dump a color screen to disk as a PICT file. To my mind, this FKey alone is worth the price of the package. [We agree! -Ed]

Finally, a tip that may be worth passing on to those Mac II owners who happen to have more than one monitor hooked up: If you hold down the Command key when you drag the grow box on a window, you can overcome the built-in limits on window size that many programs have (for example: Reflex+), but fails for a few (for example: MacWrite 4.6, whose window will snap back to the built-in limit as soon as you release the grow box). [If Reflex Plus has any limitation on it’s window size, we can’t see it on an Apple color monitor! -Ed]

IBM Versus Mac

Romanas J. Buskus

Just read one of those evaluation articles in Information Week that compared the IBM PS/2 Model 25 with the Mac SE. Before I go any further, I should tell you that Information Week is slanted toward IBM and thinks they are the greatest thing since sliced bread. I would even go as far as to say that the entire editorial staff wears blue underwear. So, is it any wonder that the Model 25 got 101 lines of evaluation text while the SE got only 59. (The author stated that the SE’s “biggest drawback may still be the fact that it’s not built by IBM). Even still, this is progress. A year ago, the SE would have been called a toy. The IBM’ers are beginning to realize that the MAC is a powerful business machine and are starting to make ridiculous compromises. For example, the article presented the author’s idea of the “Dream Machine”. It is as follows:

The Configuration:

• 101-key IBM keyboard (Apple’s keyboard doesn’t “feel” like an IBM)

• Apple mouse and controller software (thought they didn’t like mice?)

• 13-inch VGA color monitor (small screen?)

• Apple 3.5-inch disk drives (doesn’t IBM make these?)

• 20-Mbyte hard disk (I thought this was a dream machine!)

• Apple tutorial and documentation (Apple’s is more FUN!)

• Mac OS with DOS compatibility (for old time’s sake)

• IBM SAA and Appletalk compatibility (can’t figure this one)

List Price:

• Under $2000.00 (now you’re talking!!!)

Who is this guy?

68020 versus 80386

William Clodius

I have a few comments on the recent discussions that have appeared in your magazine on the relative performance of the 80386+80387 compared with 68020+68881. I believe your readers are incorrect in implying that a flawed design necessarily implies lower performance. The problems with the 80x86 design include the use of segmented memory, a smaller number of registers, and incompatible memory modes for different sizes of memory space (the 80286 protected mode problem). These problems complicate the design of programs, particularly of large ones, and make it impossible to write a program for earlier chips that take advantage of the larger memory space of subsequent chips. The need to implement several memory modes on the 80386 also increased the complexity of the design, and hence may be a contributing factor to Intel’s well publicized difficulty in manufacturing the 80386.

However, while the above problems complicate a programmer’s task and increase the cost of a working 80386+80387 system, they do not directly affect the performance of the system. For systems of comparable complexity, ie. two CISC designs, the performance should be roughly proportional to the MIPS rating. Because the 80386 includes the MMU on chip and uses a higher transistor density to implement faster algorithms for some instructions, it takes one to two less clock cycles than the MC68020 with MMU to perform an instruction so that it is effectively 15-33% faster than the MC68020 at the same clock speed. This increased performance is not unreasonable given that the 80386 appeared well over a year after the MC68020, and its designers could both study the MC68020 for ideas and take advantage of improvements in manufacturing technology. However, it is significantly less than that suggested by the recent notorious Byte articles.

The above disagrees with analyses by some of your readers that assume that the 80386+80387 differs in performance from the 80286+80287 only by a factor proportional to their clock speed. However, by the same reasoning a 16MHz MC68020 should be only twice as fast as an 8MHz MC68000, instead of about four times as fast. In such comparisons it should be noted that a 32-bit bus in and of itself will give an additional factor of two improvement for 32-bit operations over a 16-bit bus (ie. floating point operations), and can give additional performance increases for 8- and 16-bit operations by using the registers as caches and by sometimes performing operations in parallel. Further performance increases occur for newer designs because the increased transistor density allows the implementation of faster algorithms and special techniques, such as putting the MMU on chip, to reduce the number of clock cycles per instruction. Such techniques allow the MC68030 to be about 50% faster than the MC68020. The increased transistor density also allows the use of new instructions, such as the transcendentals implemented on both the 80387 and MC68881. As a result, your readers should not predict the performance of an 80386 system using an 80286 compiler, although some of them have attempted to do so.

Finally, a few assorted points. Neither the 80387 nor the MC68881 is the fastest available floating point unit. The Weitek processors, for example, are much faster than either chip at floating point operations. Although I believe the 80386+80387 is faster than the MC68020+MC68881, the performance difference between the two groups of chips is not significant compared with reasonable differences in compilers, operating systems, and bus characteristics. However, if Motorola’s performance goals for the MC68030+68882 are achieved, then their performance should be much faster than the Intel chips for reasonable variations in other aspects of the system design, ie. a Mac “III” should decisively outperform any 80386+80387 system.

Watch Your System File

Neil Ticktin

Thank you very much for publishing my letter in the November issue. The only problem is that you slightly misquoted me on page 12, second column. In the last paragraph of my letter, you quoted me as “...begging to sell kits...” when I actually wrote “...beginning to sell kits...”. Not a big mistake, but it gave the wrong impression to your readers and to ComputerWare. Could you please print a correction and get me out of trouble?

Recently, I have had to help a lot of my clients with problems ranging from hard disks to programs not running correctly. What I have found time and time again is that their System file has been mutilated. This has especially contributed to hard disk problems. My suggestion to anyone and everyone is to have a copy of their System backed up on floppy. If you suspect a problem, replace the System file on your hard disk or boot floppy and restart your machine. Apple might think about ways of making their System more bullet proof and protected.

To re-initialize the parameter RAM, that is used by the control panel, press CMD-OPTION-SHIFT as you select the control panel from the apple menu. I found this useful when a Macintosh II would not boot from an internal F140. A squirmy public domain desk accessory had zapped the parameter RAM.

Does Font/DA Move 3.6 have any bugs?

Peter Trinder

I have a technical question to ask in respect of MultiFinder. I have received from Apple Developers group (the UK version of APDA), the UK localized version of MultiFinder and I have encountered some weird problems using the 3.6 Font/DA Mover. The main trouble seems to be that when I remove more than one Font, the Font/DA Mover fails with an error (-108) and the font file becomes damaged (or if I am removing from the system, the System is damaged). I only seem to get this problem using a MacPlus with more than 1Mb of memory, in my case it is a TurboMax. A friend has had this problem on a standard MacPlus with 4 Mb! I checked with Apple UK and they told me on 16th of November that the release of MultiFinder [in the UK?] had been delayed. Does anyone know if this is the reason? I called Steve Brecher about a week before I heard of the delay and he was puzzled but could not offer a solution.

[Multifinder is shipping here and we have not seen this problem with the Font/DA Mover. However, you cannot ‘edit’ your system file while running Multifinder. You must return to the normal Finder before you move fonts and DA’s in and out of the system. The only problem we have verified is that which we reported last month: some fonts may need to have their flag word checked in their FOND resource to make sure it is $6000 to work correctly under Pagemaker 2.0a. We also noticed that Edit has problems with more than 24 fonts under the new system. -Ed]

MultiFinder Patch for PageMaker

He did however give me a patch for PageMaker 2.0 & 2.0a which will allow it to switch correctly in MultiFinder; the problem is that PM only recognizes 31 entries in the Apple Menu. Switching in MultiFinder looks for the entry in the Apple Menu; if it is more than 31, nothing happens. To fix this, search for 0102 011F and change it to 0102 01FF. This will allow PageMaker to honor 255 entries. Thanks Steve, you are great!!

Riccardo Ettore came to the MacUser show in London (10-12 Nov.) and gave me a disk with his new Sound Mover Package. This has a converter for taking SoundCap files and producing .snd resources for both HyperCard and the Mac II. He has also included a Sound Mover which is designed like the Font/DA Mover and this will install sound resources into the system. Of interest to MacPlus and SE owners is his IBeep2 CDEV which is placed in the system folder and appears in the Control Panel (System 4.1 or higher) and allows the Mac II beep sound facility on these machines. He has included an assortment of sounds, I have the Beatles HELP! Makes a nice change. It should be on CompuServe by now. [Note to authors: We would dearly like to publish some type of sound mover CDEV that explains how to add sounds to the Mac II ‘library’ of exception beeps. -Ed]

What about 512KE Machines?

Ian McLellan

Is it safe to use the new System 4.1 and Finder 5.5 on a 512KE? Every time I ask the dealers around here, I get memory upgrade offers instead of answers. Do I really need the extra memory? Is disk space a problem (I don’t have a hard disk)? Is there something else I should know? [System 4.1 is not new, but yes, 4.1 and Finder 5.5 work fine on a 512KE, at least on mine! The really new System 4.2 and Finder 6.0 also appear to work on the 512KE so far However, you should upgrade to at least a plus. I don’t think 512KE machines will be usable for very much longer, given the growth in application size we are seeing. -Ed]

Draw over the Menu Bar in Basic

Anthony J. Oresteen

One of my biggest frustrations with ZBasic for the Mac was I couldn’t control the ENTIRE screen. I wanted to draw over the menubar but just couldn’t. Well, thanks to a hint from Ann Arbor SoftWorks (FullPaint) I figured it out.

The solution is simple (as most are once you know them!). You can draw visable windows only on the defined region of the desktop. When the Window Manager is initialized, it draws the desktop and empty menu bar. It stores the desktop as a region and the global variable GrayRgn (&9EE) holds a pointer to it. By expanding the desktop region to the full screen size, you can draw windows over the full screen.

Below is a program that draws a full screen, inverts it to BLACK, and then restores the desktop. NOTE that it will work with any size screen as it checks the global screen.bits for the screen size.

Two bugs remain. First, the lower corners of the desktop do not return to “round rect” types. They are square but should be rounded. Secondly, when scrolling text in the black window, you get funny white bars. Any help on solving these minor bugs would be appreciated. Thanks.

(1)

REM THIS DRAWS WINDOW OVER MENU BAR
REM A. J. ORESTEEN AUG 1987
REM PUBLIC DOMAIN USE FREELY
REM THANKS TO ANN ARBOR SOFTWORKS (“FULLPAINT”) FOR HINT!!
REM USE ZBASIC 4.0 [or later? -Ed] !!!
:
BREAK ON  :  CLS  :  COORDINATE WINDOW  :  WINDOW OFF
:
VSIZE%= PEEK WORD(PEEK LONG(&904)-116): REM VERT SIZE OF SCREEN
HSIZE%= PEEK WORD(PEEK LONG (&904)-114): REM HOR SIZE OF SCREEN
GRAY&=PEEK LONG (&9EE)  : REM GETS GRAY REGION OF DESKTOP
CALL OPENRGN: REM SAVES REGION DATA
OLDDESKTOP&=FN NEWRGN: REM GETS NEW HANDLE FOR REGION
CALL COPYRGN (GRAY&,OLDDESKTOP&) : REM GETS A COPY OF STANDARD
DESKTOP 
CALL SETRECTRGN (GRAY&,0,0,HSIZE%,VSIZE%): REM SETS DESKTOP TO 
 FULL SCREEN
WINDOW #1,,(0,0)-(HSIZE%,VSIZE%),3 : REM DRAWS MAX SIZE WINDOW
PRINT “BIG WINDOW!”
:
DELAY 1000
:
WPTR&=WINDOW (14): REM HANDLE TO WINDOW
VISRGN&=PEEK LONG (WPTR&+24): REM VIS RGN OF WINDOW
CALL INVERTRGN(VISRGN&) : REM INVERTS SCREEN TO BLACK
CALL BACKCOLOR (33): REM BLACK BACKGROUND COLOR
CALL FORECOLOR (30): REM WHITE FOREGROUND COLOR
CLS: BEEP : TEXT 0,18,0,0
PRINT : PRINT “BIG BLACK WINDOW!”
:
DELAY 1000
:
WINDOW CLOSE #1  : REM CLOSE FULL SCREEN WINDOW
CALL BACKCOLOR (30): REM WHITE BACKGROUND COLOR
CALL FORECOLOR (33): REM BLACK FOREGROUND COLOR
CALL COPYRGN(OLDDESKTOP&,GRAY&)  : REM RESTORES NORMAL DESKTOP 
 REGION
CALL PAINTRGN (GRAY&): REMDRAWS REGION
CALL DISPOSERGN (OLDDESKTOP&) : REM DON’T LEAVE A MESS IN      
 MEMORY
CALL DRAWMENUBAR : REM RESTORES MENU BAR
:
WINDOW #2,”FULL SCREEN”,(20,40)-(HSIZE%-20,VSIZE%-20),257
TEXT 4,12,0,0
PRINT:PRINT “MENUBAR IS NOW SHOWN AGAIN!!”
BEEP
PLOT 40,80, TO 200,200 : CIRCLE 300,200,40
:
“PAUSE”
GOTO “PAUSE”

Loved the Printer Driver

Peter Adamson

I was totally ecstatic when I saw your artical on how to write a printer driver. I’ve been trying to get info in how to do this for months with no success. Then I discovered that the source code was in, uh, C Are there any bilingual programmers out there that have translated it to Pascal? I’m not that kind of bilingual.

I have a utility program that spends a lot of time going through the main event loop each time. I’d like it to run in the background, but I really don’t feel like rewriting it to go through the event loop more often. Can this be avoided using a Pascal equivalent to PAUSE (Forth Forum, November)?

[Try it as a Multfinder background task? -Ed]

How to get started?

Tatsuhito Koya

I am a graduate student at Civil Engineering Department of Northwestern University, and intending to write engineering software for the Macintosh. I have been using for a long time an Apple IIe and am familiar with its programming, but I quickly found out that the Mac is a totally different machine. Many technical terms used in MacTutor like handle, filter, and graport are a real mystery to me. Could you suggest good sources of information explaining these? Also, I would like to start learning C and Assembly language. Could you recommend some good compilers, assemblers and texts dedicated to programming a Mac? [Think Technologies makes a nice friendly C compiler called Lightspeed C, version 2.13 and Consulair Corp. makes a nice little 68000 development system, version 2.0. As far as books go, find a good bookstore and buy everything that says Mac on it. You’ll need it all eventually, especially anything published by Addison-Wesley. -Ed]

Hypercard Questions

Scott Vore

A few questions please:

1) In Hypercard is there any way to call the SF GetFile dialog when importing text or do I have to specify the Filename each time? (I guess I could use CN XCMD)

2) In Hypercard is there any way to use application defined events like event #13-15 in the Event Manager?

3) The October issue of MacTutor (pg. 7) spoke of a button to import text in the button ideas stack. I sure can’t find it. Any ideas?

4) Any idea why a company that calls itself (or product) “Lightspeed” won’t whip an update for Lightspeed Pascal for the Mac II without a check (not plastic) and then takes over two weeks to do it? Beats me.

[The latest LS Pascal update, 1.11, is available on AppleLink (I think), Compu-Serve, and direct from MacTutor at no charge to our customers. A new version should be announced at the Expo this month. More next time, if they release it. We have had a number of people contact us about writing regular Hypercard articles, but nothing yet. We would like to have an on-going hypercard column, if someone has the ‘stick-to-it’ fortitude of a Dave Kelly or Jörg Langowski to pull it off. -Ed]

A/UX Articles?

Coppieters Johan

I’m thinking about writing something for you to explain how to use the Macintosh toolbox from within A/UX, the Apple Unix version. [Great! -Ed]

A lot of developers, now having programs running under other Unix systems are ready to port their work to A/UX. This is easy since A/UX is a very good System V Unix implementation, so recompilation on a Mac II running A/UX does the job. In a second phase these developers want to convert their programs to conform to the Macintosh User Interface guidelines. This is where they get into problems and some of them are already reading MacTutor along with Inside Macintosh to get used to the Macintosh philosophy.

Another class of developers want to make programs for the Mac, but they want their programs to be able to run under A/UX (for example: VIP, MacDraw, SuperPaint, Rez do run under A/UX). This is possible since well-written code under the Finder is object-compatible with A/UX. One has to know which manager and which routines to avoid.

A third class of developers just wants to program under A/UX, using the multitasking normally available under UNIX [and the true 32-bit mode? -Ed], and use the toolbox to create windows, dialogs, controls and menus. Our company, SoftCore, organizes the basic Unix traning for Apple and we import the Kinetics networking products so we have good expertise in both A/UX and networking. If your readers are having problems getting to non-Mac machines, let me know, as I’m willing to explain some of the solutions to MacTutor readers.

CopyBits Wierdness?

(Name left off letter)

Anybody notice that _CopyBits in the SE ROM (/Patch(?)) doesn’t work the same as before? I have a ‘Wizzo’ modified to handle a $9B x $9B bitMap. Works fine on 512K RAM, 64K ROM Mac, but truncates the top 3 rows of the image in the “Fade In’ routine on the SE - open left, open right, open out all work fine. Same application file on both machines. Tracing through the application’s code yields no clues-- call to _Copy Bits have identical parameters on both machines. TMON & The Debugger show the current grafPort to have the same portRect, VisRgn, and clipRgn at each call to _Copy Bits from the application code.

Note that 2 other bitMaps (different dimensions) work fine on both machines. I’ve been too overloaded with other *things*; (i.e. this routine hasn’t made its problems seen in money-dependant situations) to trace through the trap code or test problematic bitMap dimensions.

Woes of a Mac Programmer

Doug Beck

Reading MacTutor convinces folks that you are competent to program the confounded machine. I have been tapped to do the development work on halftone algorithms a la National Geographic in texture. [product description edited out. -Ed]

Anyhow, the chosen instrument for all this is a Mac II. Tricked out with a RasterOp 8 bit deep RBG controller with a TI 34010 graphics chip, 8 Megabytes main memory, 144 Meg disk (PC third party stuff), a 20 inch Mitsubishi display as well as a standard monochrome display, and probably a 200/400 Meg write once optical disk for archiving. The hard copy device will be fed data via a National Instrument DMA controller and 32bit parallel interface, fed from four National Semiconductor 16Meg memory boards. 72 MEGABYTES of memory. Lots of plugging and unplugging of cards just to reconfigure the Mac to do its stuff.

AHA! The serpent raises its head in paradise! The Mac OS only supports 24 bit addressing. How in the heck does one get a hold of those National Semi memory boards? Will the system recognize them and place them in the system heap where a NewPtr call will get them? I am sloggong through Vol V of IM, but no glimmer so far. It was hard enough to just find the hardware to do the job, and do a sales job on the project manager. To not be able to address these widgets will be *real tough*. Of course you could treat each board as a Ram Disk, and just feed starting and ending data points to the DMA device, but that lacks appeal. Oh, Sigh.

Last items. I was in ComputerWare in Palo Alto a couple of weeks ago to pick up Suitcase. Also there was Jean Louis Gasse, of Apple VP of R&E fame. He had a large stack of Mac software he was purchasing off the shelf. On top of the stack was a copy of MacTutor. I guess he does this regularly, just to check the quality of product in the market place for his children. Apple does listen.

Couldn’t take Apple up on any of their job openings in your recent mailing to contributors. My son (MSCS U of O) is already working there (Smalltalk guru) and as a family, we are better taken in small doses. Keep up the good works and pray for a 32-bit Mac OS. (A/UX, just say NO!) [By now, the Mac II ROM replacement for the Slot Manager bug operating in 24-bit mode, rather than 32-bit mode, is well known. If you fuss enough, you get a ROM upgrade. But what about the memory manager and the segment loader? Will they go to 32-bit? -Ed]

Advanced Program Debugging with “The Debugger”

Steve Jasik

In an April 87 in MacTutor, I described the features of “The Debugger”, and alluded to work in progress on some advanced features. During the last 8 months, I have extended “The Debugger” in a variety of ways. The extensions were selected to enable debugging “in the large”, and to bring it closer to a source level debugger.

Debugging “in the large”

Given the ability to observe and print the values of expressions at specific points in a program, one can examine its behavior over large sequences of instructions. Such a facility is useful when one wants to analyze the cyclic behavior of a program, or catch bugs that do not show up until after a program has executed for a long period of time.

I have added the ability to attach “action clauses” to breakpoints. An “action clause” is a sequence of debugger statements that are executed every time the attached breakpoint is encountered. An action clause consists of one or more debugger statements. Debugger statements may be assignments to debugger variables, write statements which direct ASCII output to the “-Notes-” window, and IF statements which control the execution of the “action clause”. Underlying the statements is a powerful expression calculator based upon the syntax of Pascal. An example should make things a bit clearer. Consider the following “action clause” :

(2)
   Writeln(?Bkpt:integer,’ delta = ‘,ticks-?oldticks:integer);
   ?oldticks := ticks;
   if ?Bkpt < #20 THEN resume;

The Writeln statement will place a line with the value of ?Bkpt (the number of times the Breakpoint has been encountered) as an integer, followed by the string ‘ delta = ‘, followed by the value of the expression ‘,ticks-?oldticks (as an integer) in the “-Notes-” window. The second line will save the value of the System global variable ticks in the debugger variable ?oldticks. The third line tests the value of ?Bkpt, and if it is less than 20 decimal, then execution of the program resumes, else it breaks into “The Debugger”.

If we were to attach this condition to a breakpoint that followed the “GetNextEvent” call in the main event loop of a program, then it would display the number of ticks between successive calls (plus the overhead save and restore the user’s environment and execute the action clause)

The operands in an expression may be the values of the user’s registers (RA0 .. RA7, RD0 .. RD7 ), system global variables, user global variables, debugger variables, or numeric constants. In addition to the standard operators ( +, -, *, DIV, OR, AND ), expressions may contain references to functions for shifting bit fields, saving and comparing blocks or memory, saving the registers, and a general purpose function, Userp, that can call any defined user function. This last facility lets one extend the expression parser in an arbitrary way.

Towards Source Level Debugging

A number of features have been added to make it easier for the user to display information in formats that are natural to the program being debugged. The ability to extend the built in set of record type definitions allows the user to inspect his structures. The “add/ZAP User Defs” command allows the user to add type declarations such as the following to “The Debugger’s” set of types:

(3)
xmyDptr = ^xMyData; { forward reference of a Ptr Equiv}
xMyData = RECORD  
   Terecord:TeHandle;  { an Inside Mac type }
   File_Vol,windstuff:integer; {list of field names seperated by 
 commas}
   ftrunc,changed,third:Boolean; {list of Booleans}
   more:Longint;  { this should be aligned on a Word boundry }
   s1:String[6];  { defines a Pascal String, max 6 chars long, 
 occupies 8 bytes }
   more2:Word;  { an integer that will print in Hex format }
  END;

Both Nosy and “The Debugger” know the calling sequences of the Macintosh trap calls. Now one can specify the Parameter lists of user defined trap calls so that the values of their parameters can also be displayed in their natural format when they are called, such as in the example below.

The Debugger on AutoPilot

After adding features such as the ability to define User Type and arglist definitions, a natural extension would be to read those and other commands from a file when it started up. If a file with a “.dsi” (Debugger Startup Info) exists, then it is read in and processed. It may contain commands to define user types, user arglist defs, set action clauses, breakpoints, trap intercepts, open files, etc. This feature will speed up the repeated debugging of programs.

The Future

As I add features to “The Debugger” and get feedback from users, there is a never ending set of things that I can add to it. Items currently on the wish list include, decompilation to an algebraic language so we can minimize the need to understand assembly language, trap discipline and support of the MMU chip, etc. (Contact Steve at Jasik Designs, (415) 322-1386).

MacTutor welcomes letters. I personally try to answer all of them. Be sure to include your name and address in the letter as the envelope is long gone when I get it. Short technical notes get top priority. Send to PO Box 400, Placentia, CA 92670.