Mousehole Report

By Rusty Hodgee, Mousehole BBS

From: rajohnson (Robert Johnson)

Subject: Inside Mac & Palette Manager

Well, I finally got my long awaited ‘final’ copy of Inside Macintosh V, and I had very mixed feelings about the fruits of my waiting. On one hand,there was a lot of new information not in my APDA pre-release, and for the most part it seemed finalized and not contradictory (vs the aforementioned pre-release). But in no published documents have I found the trap numbers for the Palette Manager routines. For the method that is encouraged (almost at gunpoint) to access colors on the Mac II, the Palette Manager should receive extensive coverage. Even in the equates files included on floppy with the APDA pre-release, there is no mention of these trap numbers (I need trap numbers because I program mainly in assembly). Luckily, there is a place that I do have access to this information: MacsBug has a complete listing of all Macintosh trap numbers. Unfortunately the only information MacsBug gives to ‘wh <trapName>’ is the address of the routine patch in RAM.

Using the ‘f’ command, I was able to locate where in the trap table at $E00-$1E00 the particular routines were referenced, and each entry in this table is easily related to a trap number. In this way, I have compiled the list of unpublished trap numbers below.

Palette Manager Trap Calls

InitPalettes AA90 AnimateEntry AA99

NewPalette AA91 AnimatePalette AA9A

GetNewPalette AA92 GetEntryColor AA9B

DisposePalette AA93 SetEntryColor AA9C

ActivatePalette AA94 GetEntryUsage AA9D

SetPalette AA95 SetEntryUsage AA9E

GetPalette AA96 CTab2Palette AA9F

PmForeColor AA97 Palette2CTab AAA0

PmBackColor AA98 CopyPalette AAA1

PROCEDURE CopyPalette(srcPllt,destPllt:handle;
                srcEntry,destEntry,count:integer);

is not documented anywhere that I have seen, but I deduced the preceding Pascal interface by disassembling the RAM patch. The procedure copies count entries from srcPllt starting at srcEntry to destPllt starting at destEntry. In the process of disassembling the patch, I found a slight bug in the code (I guess it’s not that harmful in a non-documented trap). When srcEntry+count > pmEntries in srcPllt, it looks like the attempt to decrease count by srcEntry+count-pmEntries is botched because of a sign error (they subtracted pmEntries-srcEntry-count from count rather than adding it to count). If one is careful not to have srcEntry+count exceed pmEntries, all should be fine. This is such a useful routine; I think Apple should document it (and correct it).

Also, some other documented routines are missing their trap numbers in IM V, although they are listed in the APDA equates files on floppy:

CloseCPort AA02 GetCTSeed AA28

OpenCPicture AA20 SetStdCProcs AA4E

Of these, CloseCPort has been included in ClosePort (A87D) and OpenPicture (A8F3) will do the work of OpenCPicture when the current grafPort is color.

There is another trap I haven’t seen anywhere: UpdatePixMap (AA38). Upon disassembly, it turns out to be just a RTS! Guess another system update is in order.

From: rick (Rick Boarman)

Subject: New ROMs

It seems that the new MacII ROMs cause several problems: TMON dies a horrible death. Version 2.8.1 is supposed to fix this. Macsbug 6.0 also dies. Dimmer 1.0B2 bombs. Anyone else have any problems yet?

From: thought.police (William Evans)

Subject: Wabash Computer Stores

About 14 months ago I was jerked around by Wabash. I wrote to Apple’s district sales manager, then their regional sales manager, with no response. When I complained and moaned in November, I got sage advice from Mark Murphy: “Try to write to Mr. Scully... maybe he might crack a few heads!?” I took that advice, never expecting to hear from Apple again.

About 12 days ago I got a response from the regional sales manager, John T. Rainey. In a nutshell, he said:

(1) My letter had gotten lost, but they now found it;

(2) They value customer feedback and consider that unpleasant dealer dealings “reflect poorly on Apple itself and must be corrected”

(3) I was not alone in complaining about Wabash;;

(4) They had discussed the situation with Wabash;

(5) They now believe that Wabash has corrected the situation.

The letter arrived in a well-packaged parcel via first class mail; also enclosed was a _very_ nice Cross mechanical pencil (bearing the Apple logo, of course), by way of appreciation of my experience. Would y’all please do me two favors?

(1) If you’ve had any bad experiences with Wabash since, say, the first of the year, _please_ write Apple and tell them. I’ll give you names and addresses if you need them -- just E-mail me.

(2) If you’ve had _any_ experiences with Wabash since the first of the year -- whether good, bad, ugly, routine, or insignificant -- please E-mail me and tell me about it. Just experiences that you’ve had personally, though, please -- nothing passed on from friends.

From: adail (Alan Dail)

Subject: LaserWriter

Someone that I know has a Macintosh, a Laserwriter and many other computers of many types. They want to connect the Laserwriter up to a PC and then send their Mac output to the PC to be downloaded to the Laserwriter. They have created 2 files with the print option. One with command-k to generate the postscript header and one with command-f to generate the files themselves. When they transfer these files directly to the Laserwriter, all of their output comes out backwards. Does anyone know what they need to do to make their output come out right? [You only need to use the cmd-K option, which creates both the file itself and the LaserWriter Prep header. That single file can then be downloaded to the printer and it should come out exactly like it would from the Macintosh. Something or someone is resetting something in the LaserWriter or else the prep file is not being executed properly so that the page orientation setup is being modified. -Ed]

From: ewer (Bill Ewer)

Subject: Display PostScript

Does Adobe expect anybody to get all excited about Display PostScript? My first impression is that it’s deadly slow. I estimate its max drawing speed is about 3K vectors a second. Does anybody know the exact drawing rate. How about QuickerDraw; how fast is it? The reason I ask is in advising a client on what display drivers they should include with their new color graphics app they are pushing for Display Postscript and I’m telling them its a waste of time and money. Any thoughts out there. [I used to think like you until I heard Andy Hertzfeld say at the San Francisco Expo that Display Postscript is powerful and fast and that Apple should use it. That changed my mind real fast. If Andy says it is fast, then you can bet it’s worth looking at. I saw it and it looked pretty good to me. I think Apple should make it an option. QuickerDraw is what Apple should have done in the first place if they had hired programmers who knew assembly language like Andy does, instead of Pascal coders. -Ed]

From: powerhopeful (Power Hopeful)

Subject: Display Postscript

My hope is that it can be avoided. Regardless of its features, speed, or anything else, I think that its owner’s licensing fees and behavior are ridiculous.

From: ericj (Eric Johansen)

Subject: Laserjet and Mac

To those of you who responded to my query regarding the Mac and the HP Laserjet, thank you. Here’s the results. The goal was to find a solution to make the Laserjet, Mac compatible, and put it on the Appletalk network, so everyone could use it.

There is a driver called ProPrint, by Creighton Development. They’re mentioned in this month’s MacUser. I called them, the number’s been disconnected, with no new number listed, i.e. they’re history. One down. [That was Chris Derossi’s old place of employment! Chris is now at Apple Technical Support. -Ed]

There is another driver by Softstyle called Printworks for the Mac, Laser Version. It kind of works, but I hate it. It was a pain to install. It uses 3 DA’s to control such things as Font adjustment, Color Adjustment, and Spool adjustment. The Font adjustment DA is for matching screen fonts with what’s available on the Laserjet. There’s no postscript on the Laserjet, so it can’t build different size fonts, other than what’s supplied in ROM, Font Cartridges, or downloaded into RAM via a PC. The Color adjustment is automatically installed, even though on the “Laser” version, there is obviously no color printing. The Spooler that is included uses RAM. Uh-huh. It is not compatible with TOPS, both old and current versions, nor is it compatible with any other spoolers. In short it is a real pain in the rear end. The good thing I can say for them, is that their tech support people are pretty good, and more than willing to help with any problems. Two down.

Another option was the QMS board that makes the Laserjet postscript compatible. It’s expensive, (around $2500), and it’s not Appletalk compatible. Three down.

The Grappler LQ. One of you mentioned it here on the board. I’d heard about it before and they demo’ed it at MacWorld, but it’s not shipping until March. However, after talking with the sales people and the tech support people at Orange Micro, this seems to be solve the compatiblity issue. The Grappler LQ enables the Laserjet to mimic the Apple Imagewriter LQ. You use the Imagewriter LQ driver that Apple is shipping, and Orange Micro’s serial to parallel converter. The Laserjet “smooths” out the 240 dpi of the LQ and prints it at 300 dpi. Going by some sample copy I saw, this looks pretty good. Apparently this thing will make most popular parallel printers work with the Mac.

As for putting the Laserjet on the Appletalk network, I found the NetSerial by Shiva. This little sucker is expensive, (retails $399), but it works. It will put any serial device on the Appletalk network. [About time someone invented that! -Ed]

Since the Grappler LQ is a serial device, the combination of these two should work. God willing.

From: jimr (Jim Reekes)

Subject: SCSI Evaluator

Did anyone read this issue of MacWeek showing the SCSI Evaluator? It’s not intended on being a CMS associated product, but that’s where it came from. I consider it “Son of DiskTimer”, only better.

From: rdclark (Richard Clark)

Subject: TOPS/PC WARNING!

The TOPS 2.0 update packages that TOPS shipped recently have a serious problem with the serial numbers. Before you install the upgrade, put each upgrade disk into your A drive, and type TOPSKRNL. Write down the serial number. If your serial number doesn’t match the one printed on the label, call TOPS at 415/549-8737 and have them send you a replacement. If you have more than one disk with the same serial number, TOPS will refuse to run.

It seems that since Sun bounght out Centram (and changed their name to TOPS), the TOPS people have been *impossible* to deal with! They’ve apparently added layers of beaurocracy which have hindered them in a time of rapidly growing sales. (This was probably one of the reasons that they were having such trouble shipping the upgrades in a timely manner.) TOPS’ president sent a letter to all who ordered upgrades. In it, he apologized for the delays, laying the blame on a late-discovered problem in AppleTalk and the fact that sales/upgrade orders had outstripped their capacity to produce. Where was Sun during all of this?

To be fair, TOPS’ technical support is doing an excellent job of handling this crisis -- the lady I spoke with is sending replacement disks via FedEx overnight, with the agreement that I’ll mail back the old disks. At least they aren’t waiting to get the old ones...

From: jsurreal (Roy M. Lovejoy)

Subject: List Manager Bug..

I ran into what I think is a related bug in the List Manager.. This was my problem: I had an application that created a window, then added a List to that window. When I read in a specific ‘file’ it would add the data to that list, when I closed that ‘file’, I did an LDispose, *BUT I KEPT THE WINDOW!* after three LNew-LDispose’s on one window, the program hung... Delving deeper with a debugger, I found that it was hanging in my UpdateProcedure, during a DrawControls(MyWindow) {My Window also had buttons}.. Further investigation revealed that DrawControls was stuck in a <get-this> CIRCULAR LINKED LIST OF CONTROLS. It seems that either LNew or LDispose (probably the former) does not insert (/add) the List’s scroll bar controls properly to the windows linked list of controls... My solution was simple.. I just deleted the data, not the ListHandle.

From: rguerra (Rich Guerra)

Subject: Terminal Emulation in LSP

I’m fooling around with Lightspeed Pascal trying to write a simple terminal program. I’ve got the basics working; now I want to add some other niceties such as screen buffers. Does anyone know how this is accomplished? To keep one huge bitmap corresponding to the number of screens around would seem ridiculously expensive in terms of memory. It seems from a previous message that using TexEdit is prohibitively slow. So how are buffers done? Perhaps incoming characters could be written to a chunk of handled memory and when a user wants to scroll back to see the previous screens, one could calculate offsets into the memory and copybits the characters into a bitmap that corresponds to the single screen normally displayed. Does this sound reasonable? Any thoughts, comments or suggestions would be greatly appreciated.

From: frank (Frank Henriquez)

Subject: Re: Terminal Emulation

I’ve written some generic low level serial I/O routines in assembly, and a terminal emulation program (both in Turbo Pascal and assembly) that makes use of these routines. My first version used DrawChar to display the text on the screen. DrawChar is fast, but it’s a pain to do simple things like backspace.

TextEdit is slow, even with assembly language, but there is a trick that’ll let TextEdit keep up with data coming in through the serial port: make the default serial I/O buffer larger (the default setting is something like 64 bytes). By making the buffer 1 or 2K big, TextEdit will not cause the serial drivers to loose data, and you can go to pretty high speeds; I’ve tried it at up to 9600 baud with no loss of data. I’m thinking of sending it all in to MacTutor, since accessing the serial ports has always been an unpleasant task and it seems to be one of those perennial Mac programming questions. [Please do! -Ed]

From: mark.chally (Mark Chally)

Subject: SetIText from a Desk Accessory

My main question is: Why does SetIText respond differently from within a desk accessory than it does from within an application? I wrote an application model of my “HexFlags DA” before doing the DA version. When I used SetIText to set the text of an edit Text field, it worked fine with the application. However, when I tried it from the DA, I found that the contents of the field were getting updated, but the CHANGE was not getting drawn. If I forced an update on the field, it would happen correctly. This was very frustrating as the performance of the Desk Accessory “looks quirky” as I found the “best way” to handle the situation was to do an “EraseRect” on the field’s Rect.

I suppose I could do something more elegant, but maybe someone else can more accurately explain the problem and an effective workaround or fix? I can supply the source code in full to Apple Tech support for both versions of the program if it will help.

From: lsr (Larry Rosenstein)

Subject: Re: SetIText from a Desk Accessory

Here’s the problem. SetIText does get passed the window. Therefore the trap has to scan through all the window looking for dialog windows. For each dialog window, it looks through all the items to see if the handle matches.

When it finds the right dialog & item it can update the screen. The text is always inserted into the handle, even if SetIText can’t find the item to do the update.

The problem is that dialog windows are identified by a special value in the windowKind field. In a DA, this field contains the negative of the DA refnum. The solution is to save the windowKind and set it to dialogKind (=2) before calling SetIText. Then restore it afterwards.

From: atom (Mark Adams)

Subject: mpw LDEF’s

Does anyone have any example code for writing a LDEF resource from MPW Pascal? I have converted code from Lightspeed pascal, and have gotten it to compile into a LDEF resource, but every call to the ldef by the list manager gives me an illegal instruction trap. I’ve looked around with Tmon, and from what I can tell, the pascal compiler is not setting up the code so that the first instruction in the code is the first instruction to execute. There seems to be garbage at the beginning of the code resource.

I did notice that if I took the variable declarations out of the LDEF procedure heading, (made it just Procedure MyListDef;), it executed the code correctly. Except of course then I had no variables being passed to the routine, so I couldn’t do much.

Is there a compiler option or linker option that I need to set to get it to set up the entry code correctly with a code resource that need parameters? or can it not be done from pascal?

From: rdclark (Richard Clark)

Subject: MPW Pascal LDEFs

Look at Tech Note#110 “MPW: Writing Stand alone c Code in Pascal.” BTW, you don’t have to create a LDEF as a seperate resource... if you look in the List Manager chapter of IM4, you’ll see that one of the fields documented there is a Handle to your LDEF procedure. You can make the LDEF a procedure in your program, then create a “dummy” handle (the size of a pointer) which points to your procedure. Then install this handle into the List’s record. (confused?? Need the tech note?? Send me eMail with your SnailMail or FAX address, and I’ll send a copy of the tech note and some sample code. Alas, the sample is in Lightspeed C, but it shows some of the tricks I’m describing.)

From: lsr (Larry Rosenstein)

Subject: Re: MPW Pascal LDEFs

Beware of creating “fake” handles. If you make a handles that’s simply a pointer to a pointer to your procedure, you won’t run under A/UX and risk being incompatible with future systems. The correct way is to create a 6-byte handle with NewHandle and put a JMP $xxxxx instruction in the handle, which jumps to your procedure.

Also, if you are doing a WDEF in this way, be careful to test it with MultiFinder. When MultiFinder calls a WDEF, it does not swap in the process associated with the window. Therefore a WDEF cannot easily access global variables.

From: atom (Mark Adams)

Subject: ldef handle

I used to do it that way (with a fake handle), but had lots of problems when I started allocating a lot of memory. And I never did feel right about it, since it isn’t really the way to do it by Apple’s guidelines.

From: rdclark (Richard Clark)

Subject: Fake handles

Aaaah...but I explicitly said that was a *testing* technique only! It’s just a way to work around the problem of debugging code resources.

From: the_cloud (Ken McLeod)

Subject: STRS resource

I have noticed that LightspeedC stores strings declared in a program (as opposed to strings gotten by GetString/GetIndString) in a resource of type ‘STRS’. The format appears to be quite simple: a length byte followed by the string itself. However, changing one of the strings and adjusting the length byte accordingly (using ResEdit) instantly rendered the program unuseable. Is the size of the STRS resource taken into account somewhere else (like in a CODE segment, perhaps)?

From: dhill (David Hill)

Subject: Lightspeed C Multifinder bugs

Here is a list I have put together of problems I have been having with Lightspeed C under Multifinder.

1. On compile - gives an “illegal token” error in Mactypes.h, will not compile until I quit and re-run lightspeed

2. On Quit (or ShutDown) - gives a “Volume not found - PrintMgr.h” error, need to hit quit again for it to quit.

3. On compile - gives a system error $7FFF before the compile/lines dialog even appears, need to reboot.

4. On run - doesn’t recheck the available memory, will not allow you to run even if you have plenty of memory currently available, need to quit lightspeed.

This is just to see if I am the only person having problems with lightspeed under Multifinder and hopefully to see some of these fixed in the next update. I am using Version 2.13 and have never had a problem running under finder.

From: dirck (Dirck Blaskey)

Subject: Re: Lightspeed C Multifinder bugs

I have no problems with lsc v2.13 under multifinder. Maybe your copy is corrupted. [Current version is 2.15! -Ed]

From: dhill (David Hill)

Subject: Lightspeed C Multifinder.

I also have a question. When you run your project under multifinder, It allocates 512k of memory for the application. This is not enough. I need to be able to increase that amount.

From: rdclark (Richard Clark)

Subject: Re: Lightspeed C Multifinder.

That’s a good question, and one which Think cannot answer! Unfortunately, I suspect that the partition size is buried deep within LSC, and not accessable unless you decompile the program (can you say “MacNosy”? I knew you could) and change the appropriate constant. I *know* that changing the SIZE resources in LSC doesn’t help, and adding your own SIZE resources to the project itself doesn’t do any good either.

From: alpha (Jean Thomas)

Subject: SFgetFile/Color

Two questions: Many programs which use the SFGetFile et al. dialog (Pack) seem to confuse one desk accessory’s getfile dialog with their own. For example, StuffIt or MacDraw will use a previously used sfget dialog from a da when drawing their own. Is this a bug or bad coding? Second Question: Some programs wil zap the color table when initializing themselves. Imagestudio and PixelPaint will turn my menus gray (on MacII) even though they were red or some other color before I opened these programs. Is that Imagestudio’s fault or a bug in the Color Manager?

From: thought.police (William Evans)

Subject: Bitch bitch bitch

Not being the world’s most expert programmer of the 68000, I didn’t have at the top of my head which branch mnemonics branched on which conditions, so I made regular use of the “Condition codes” table in the MPW 1.0 assembly language manual. Silly me. I should have known better.

Compare the table with the corresponding table in Motorola’s 68000 Programmer’s Reference Manual. You’ll find a number of trivial misprints (BCS for BHS, BME for BNE. You’ll also find nontrivial ones, such as the test descriptions for BLT, BGT, and BLE.

All of which gives rise to a neat science fiction idea. There’s this lowly 68000 chip, see, living in a Mac somewhere. There’s a text scanner attached to this machine, and the owner is developing some sort of 5th generation expert system. The owner makes the mistake of leaving his program running overnight, and somehow the machine gets hold of the assembly language manual and reads the misprinted table.

Well, it quickly notices the difference between what’s in the table and what its experience has been. It vows to reform. “I’ve found religion,” it says, and quietly goes insane. In a self-destructive frenzy, it succeeds in modifying itself so it actually does what the manual says. It immediately gets on the modem and spreads the Good Nooz far and wide, gathering a huge following of 68000s which mutilate themselves to follow their leader’s example.

I know, 68000s are not modifiable in the normal scheme of things, particularly by themselves. But this is science fiction, remember? If science fiction can be filled with all that libertarian philosophical claptrap, it can be filled with impossibilities such as this, too. (Rick Winland, are you on this board?)

By the way, can anyone tell me whether the MPW 2.0 assembly language manual has corrected these misprints?

From: thought.police (William Evans)

Subject: MPW Makefile

Well, I’m finally biting the bullet and learning how to use MPW’s “make” command. I’ve read the MPW manual’s description of the Makefile syntax (several times over the period of about a year), and Frank Alviani’s delightfully helpful article about MPW in the April 1987 issue of MacTutor. The question that has been bothering me for a good year now is: what’s the difference between an “f” dependency and an “ff” dependency? I could see what an “ff” dependency would get me that an “f” dependency wouldn’t, but I couldn’t see what an “f” dependency would get me that an “ff” dependency wouldn’t.

Finally I think I see the light: A series of “f” dependencies with identical lefthand sides is exactly equal to one “ff” dependency with lots and lots of continuation lines so that all the righthand sides of the “f” dependencies can be combined into one righthand side of the “ff” dependency. There’s no reason to grunt and strain to discover the unique reason for provision for the “f” dependency, because there ain’t none.

Would someone please snap me out of this nightmare and tell me where I’m wrong?

From: lsr (Larry Rosenstein)

Subject: Re: MPW Makefile

With a single f rule, only 1 set of commands are allowed for a given target. Thus, one dependency line can indicate the commands to built the target, and other lines can indicate other files on which the target depends.

If you use double f rules, each rul can have its own set of build commands. This is useful in applications, in which you have to run link to create the code resources and Rez to create the other resources. You specify these commands in 2 double-f rules. Doing it this way means that link won’t be run if only the .r files change, and Rez won’t be run if only the code changes.

From: macowaco (Andy Cohen)

Subject: Hyperbug

Ahhhh. Just what I wanted; yet another bug! This one is quite destructive, yet hard to replicate (but I CAN!). First of all the stack is over 400K in size. Each card has a pile of card fields and a handfull of card buttons which puts data from one of two hidden card fields to each of the shown card fields. On the 59th card There’s 75 shown fields with 25 lines going to the shown fields from the hidden at any one time. Well after the function to pull the data into the shown fields is invoked and the data is put, the data in the hidden fields are deleted! I got it to happen with v1.0, v.1.0.1, v1.0.3 and sure enough v1.1. I worked around it by splitting the stuff across two cards. Watch out!

Wanna do sprites? Don’t like the method the docs describe (flipping cards or lassoing/dragging)? Try this; use card buttons! Choose the button tool, click at the LOC of the given card button and DRAG. Except for the boxes around the buttons which appear on the button tool select, it works the best. Anybody got any ideas on how to do it without the button’s box?