Jul 85 Mousehole
|Column Tag:||Mousehole Report
Printing and the Tecmar
Nothing will get my Tecmar to let my Imagewriter print. Then on top of that, I tried Finder 4.1 on it and I can't copy a file onto it!
Tecmar and Finder 4.1
I have heard from some people that the "new" imagewriter driver and Finder 4.1 cause the Tecmar's print spooling to go out to lunch. It may be that reformatting is the only solution. Finders 3.3x and above need to be patched to have the "verify" routine no-opped.
Finder Patch for Tecmar
The patch for the Tecmar Finder is the following: change A002 57CA FFE2 to 4E71 4E71 4E71 using FEDIT. The second A002 fround using the Hex Search is it. Eliminates the "Verify" routine used in 4.1, but not used on earlier Finder's before 3.3x.
Rom Bug for I/O Traps
(name withheld to protect the guilty)
The effect of this bug is that if you perform an I/O trap call within an SCC interrupt routine or within a VBL task, your Macintosh may bomb. Assume A0 contains the pointer to the I/O parameter block:
403924: LEA $360,A1 ; pointer to file system queue header
403928: JSR *-$2E08 ; Enqueue pb (A0) on file system
40392C: MOVE SR, -(SP) ; save status
40392E ORI #$300,SR ; disable SCC and VBL interrupts
403932: BSET #0,$360 ;set file system busy bit
Suppose an SCC or VBL interrupt occurs during execution of the instruction at 40392C. At this time, the parameter block had been enqued on the file system queue, but the busy bit has not been set. If the interrupt handler performs an I/O trap, then that I/O as well as the one in the queue will be completed before the interrupt handler returns. When it does return, the file system queue is empty, and the instruction at 403932 sets the busy bit. Code following 403932 then attempts to dequeue a parameter block and execute it's command code, causing a bomb.
A similar sequence of code for device drivers begins at 40118E. This code exhibits the same problem except that the timing hole is two instructions wdie. Thus, if the file system or a device driver queue is not empty and the busy bit is not set, you MUST NOT perform the I/O trap.
What is the solution? Simple. If the queue is not empty and the busy bit is not set, set the busy bit yourself, perform your async I/O trap, and reset the busy bit. Hence, your I/O is simply enqueued, and when you return, the interrupted ROM code precesses the queued I/O calls correctly. This bug is known at Apple and will be fixed in the next ROM.
Finder 4.1 Bug
While trying to do a disk copy using the Finder, the destination disk's ICON disappeared and the startup disk commenced to copy itself onto ITSELF! I restarted everything by hitting reset but the Finder was missing from the system folder. Something is kind of fishy here. Anyone else see any weird things like this?
[Yes, I have had icons disappear or move erratically under Finder 4.1. I assume it is a warning the Finder or desktop has been trashed and it's best to shut down at once. Version 4.1 definitely has a bug related to tracking icons on the desktop. -Ed.]
More Finder 4.1 Icon Bugs
Finder 4.1 seemed to be working great until I got a "Disk needs minor repairs..." alert. When I checked the desktop, I noticed half the files had lost their icon pictures. Here's an interesting way to make your write 4.5 bomb: go to the search and replace window and hit "Command-Enter"...
Paste into the Calculator
Did you know that you can paste what's in the clipboard to the calculator and it will work just like you had typed it in? (Well, it does.)
New Software Releases
Just got the new "Official" update stuff from Apple; Write 4.5, Paint 1.5, Finder 4.1 and a new combo Font/Desk accessory Mover. The new paint allows "smoothing" with the Laser to increase resolution.
Thunderscan / Appletalk bug
Thunderscan uses the battery-backed up RAM and in fact looks at a location used by Appletalk. Removing the battery for 30 seconds after turning off the computer will clear memory and allow the thunderscan to work (until you use Appletalk again).
Product description on the 20 meg disk using the external drive connector is expected shortly. [What about recent announcements that Apple was shutting down the disk project in favor of buying the technology on the outside? -Ed.]
To build a driver, start your assembly with a RESOURCE directive:
RESOURCE 'DRVR' id '.XXX' atr
where "id" is the resource ID, "atr" are the resource attributes (usually at least system heap). The above example will give a driver names ".XXX". Following the RESOURCE directive, code the driver flags words, then the driver dispatch table. Note that the dispatch table does not need to be coded using offset. Just do this:
The link'll do the rest. (Note the linker will not resolve references across mutiple .REL files in the /RESOURCES section. Your driver must end up as a single .REL file.) The key to understanding how the MDS assembler and linker handle code resources is that the linker will resolve all relocatable references against a base "address" of zero. Therefore the use of the driver routine lables as shown above will automatically translate to offsets to the repective entry points. Neat, eh? Just keep the rest of the driver "position independent".
Next link the driver with a control file like this:
/TYPE 'ZSYS' 'MACS'
The /type directive makes the driver image file have the "little Mac" icon like the finder and sytem. It's optional.
Someone asked how to gray out text. Text is grayed out by painting it's enclosing rectangle with "GRAY" pattern and the pen in BIC mode. Apparently you can't just write gray text. Here is the code from the defProc for buttons, with my comments:
MOVE.L A4, -(SP) ; (SP) -> button rect
MOVE.L #$00010003, -(SP) ; shrink amt.
_InsetRect ;shrink rect.
MOVE.L A4, -(SP) ; (sp)=shrunken rect
MOVE.L (A5), A0 ;A0=>QD globals
PEA Gray(A0) ; (sp)=gray pat
_PenPat ;make pen gray
MOVE #patBIC, -(SP) ;bit-clear BIC mode
_PenMOde ; make bit-bashing pen
_PaintRect ; BIC-out text rectangle
MOVE.L A4, -(SP) ; (sp)-> shrunk rect
MOVE.L #$FFFFFFFD, -(SP) ; expand
_InsetRect ; expand button rect.