INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (03/11/87)
INFO-MAC Digest Tuesday, 10 Mar 1987 Volume 5 : Issue 63
Today's Topics:
DrawPicture to an Offscreen Bitmap
ModalDialog filters
Re: Mouse freezes?
VBL tasks and ADDQ instructions
addq.w to adjust stack
Re: addq.w for popping arguments?
Re: addq.w for popping arguments?
VBL information?
LaserWriter and Adobe Version numbers
Mac Plus and Hard disk powerdown.
Correction to Postings on Script Manager
PROTECTING STATIC MEMORY
laser spoolers
MacNifty Audio Digitizer
Are there 3rd party color monitors for Mac II?
Rerouting default files in Word 3.0?
Color printing from MacWrite
----------------------------------------------------------------------
Date: 10 Mar 1987 16:52-EST
From: Chuck.Weinstock@sei.cmu.edu
Subject: DrawPicture to an Offscreen Bitmap
I am trying to draw a picture to a *large* offscreen bitmap using
Lightspeed C. I believe that the bitmap is set up correctly, using
NewPtr to get the space and setting a boundary rectangle. rowBytes is
even and appears to be the right value. After a SetPortBits the
portBits field looks correct.
The picture draws correctly to the screen. When I send it to the
offscreen bitmap DrawPicture loops forever with a trap AXC6, and the
heap is corrupted.
Does anyone out there have any idea what is going on? All I really
want to do is turn a PICT file into a multi-screen bitmap that I can
then manipulate in my real application (like the Thunderscan software
does, only somewhat bigger). Does anyone have any C code fragments
that will accomplish this for me?
Any help would be appreciated.
Chuck Weinstock
------------------------------
Date: Tue, 10 Mar 87 8:40:06 EST
From: Mike Kraley <kraley@ccw.bbn.com>
Subject: ModalDialog filters
FRUIN@HLERUL5.BITNET is having a lot of problem getting a custom
filter function to work in ModalDialog. This completely threw me
for a loop too - the words in IM are vague and I leaped to
exactly the same wrong conclusion as Mr. Fruin.
The bad assumption is that, when the filter function is called,
that the myItem parameter holds the item number where the click
happened. WRONG! This function is called for EVERY event that
happens in the dialog window: clicks, keys, etc., and no (or
little) processing is done before the callback. Only the first
two parameters are set at the call: myDialog and myEvent. myItem
is probably just garbage. Your function must parse the raw event
itself and figure out if it's a kind you are interested in. then
you use the myItem parameter (notice it's a VAR) to pass
information BACK to ModalDialog, i.e. what item number you would
like it to return to its caller.
When you are processing the event, if it is a click, you have to
explicitly figure out which item the click is in, e.g. by doing
PtInRect. Remember to think about global vs local coords; the
event is global.
Good luck.
...Mike
------------------------------
Date: Sun, 8 Mar 87 21:39:34 mst
From: dlc@LANL.ARPA (Dale Carstensen)
Subject: Re: Mouse freezes?
sbm@Purdue.EDU asked why mouse interrupts aren't being processed when
interrupts are enabled. Although the processor has interrupts enabled, the
SCC, which handles tracking the mouse, does not have interrupts enabled.
The reason the SCC doesn't have interrupts enabled is because the SCC
received a reset. The reason it is so likely for the SCC to receive a
reset is that the Macintosh address mapping PALs allow a number of addresses
to access the SCC, somewhere on the order of 4 to 8 million (out of 16
million available addresses). It's likely you are de-referencing a bad
pointer.
------------------------------
Date: Sun, 8 Mar 87 22:48 CDT
From: <MAX%TAMLSR.BITNET@wiscvm.wisc.edu>
Subject: VBL tasks and ADDQ instructions
To the person who asked about VBL tasks going away when an application
quits...
A VBL task can expire in two ways. It can be removed explicitly by
a call to VRemove, or its counter can be allowed to decrement to
zero and not be reset. Thus, VBL tasks are impervious to application
comings and goings. Of course, this assumes that the task wasn't
placed in the application heap... If you place a task in the application
heap and don't remove it before quitting, the Vertical Retrace Manager
will try to call the task anyway and crash.
To the person complaining about ADDQ.W instructions to pop the stack:
An ADDQ instruction operating on an address register (like the
stack pointer) operates on the whole long word regardless of the
operation size.
Hope this helps,
Greg Marriott
The MacHax(tm) Group
%-b
------------------------------
Date: Mon 9 Mar 87 13:20:51-EST
From: Ian Lance Taylor <TAYLOR@XX.LCS.MIT.EDU>
Subject: addq.w to adjust stack
This is in reply to the message complaining about the use of addq.w
to remove arguments from the stack. This will actually work fine,
since on the 68000 all address register arithmetic is performed as
longwords; i.e. the immediate operand of the addq will be sign extended
before the addition. Since the stack pointer is just an address register,
addq.w works fine. Of course, the addq.l instruction takes the same number
of bytes, so I have no idea why they didn't use it.
Ian Lance Taylor
taylor@xx
------------------------------
Date: 9 Mar 1987 18:30-EST
From: Walter.Smith@dba.mach.cs.cmu.edu
Subject: Re: addq.w for popping arguments?
Re: Popping arguments with addq.w:
Don't panic. M68000 Programmer's Reference Manual, 4th Edition, p.61:
"The entire destination address register is used regardless of the
operation size."
Re: Debuggers running with interrupts enabled:
Debugging VBL tasks is a very special case, like debugging INITs.
Neither is easy. Assuming all current VBL tasks work, which is usually
the case, leaving interrupts on allows the mouse to move and the disk
drive to shut off, which is nice. To debug a VBL task, use Macsbug.
It turns interrupts off, and you can usually survive it long enough to
get the task working and switch to a real debugger. In some cases, you
could just zero the VBL queue before getting into the section of the
program that is failing.
Walt
wrs@k.cs.cmu.edu ..!seismo!cmu-cs-k!wrs
------------------------------
Date: 10 Mar 1987 08:25-EST
From: Tom.Lane@zog.cs.cmu.edu
Subject: Re: addq.w for popping arguments?
>I noticed that Aztec C uses addq.w on the stack pointer to pop
>arguments after function calls. If I understand addq.w correctly, this has
>obvious drawbacks. If the stack pointer is on a 64K boundary, addq.w will
>not carry into the high word of SP, and the stack pointer will end up
>pointing into no man's land.
Fortunately, you don't understand addq.w. According to the relevant
page of the 68000 manual, "The entire destination address register is
used regardless of the operation size." This is an instance of a
general principle that applies throughout the 68K instruction set:
when an address register is the destination, the operation is ALWAYS
a longword (32-bit) operation. The ".w" or ".l" modifier of the
instruction indicates how wide the SOURCE datum is, but a word source
is sign-extended and used in a long operation with the address
register value. Thus bugs of the kind you envision can't happen.
In other words, addq.w and addq.l are the same if the destination is
an address register (though definitely not if it's a data register).
Personally, I always write "addq.l" in this case when I'm writing
assembly code, just to make things clear.
When more than 8 bytes are to be popped, you have to use "adda #n,SP".
In this case the difference between .w and .l is real and useful: .w
implies a 16-bit literal value, .l a 32-bit literal. When popping
arguments, 16 bits is sufficient, and writing "adda.w #20,SP" saves a
word and a memory cycle. No bug ensues since the CPU sign-extends the
literal to a long value and does a long addition to SP. I'd be pretty
upset with a compiler that insisted on using "adda.l", thus wasting
2 bytes in every procedure exit sequence.
In summary, using "adda.w" is the right thing to do; when the value
is small enough to allow "addq", ".l" is preferable on stylistic
grounds, but "addq.w" is not wrong.
tom lane
ARPA: lane@ZOG.CS.CMU.EDU
UUCP: ...!seismo!zog.cs.cmu.edu!lane
BITNET: lane%zog.cs.cmu.edu@cmuccvma
------------------------------
Date: Tue, 10 Mar 87 11:23:25 PST
From: PUGH%CCC.MFENET@nmfecc.arpa
Subject: VBL information?
There has been a flurry of requests for VBL information on the net, but no
one has posted any answers. If there is information passing going on in
the background via private email, may I please request that some of that
info be forwarded to the net as there are more people interested in it than
just the requestor.
Thanks,
Jon
------------------------------
Date: Sun, 8 Mar 87 20:36:27 cst
From: rackow@anl-mcs.ARPA (Gene Rackow)
Subject: LaserWriter and Adobe Version numbers
Question: What versions of firmware is in your laserwriter? I have a
Laserwriter with version 38 and another with version 39. I hear that
Adobe has version 46 out. Possibly higher.
Question2: What are the MAJOR improvements taking place from version
to version? I have been told that version 41/42 fixed a bug that
caused the LaserWriter to loose virtual memory on errors. Try sending
5 print jobs to the printer, of which the first 4 have errors. The
fifth, and further, jobs will abort due to a framedevice error. Power
cycling the printer is the only cure.
Question3: How do we go about getting upgrade roms?
Gene Rackow
------------------------------
Date: Mon, 9 Mar 87 16:56 CST
From: Dan Stewart <STEWART_SYS%uta.edu@RELAY.CS.NET>
Subject: Mac Plus and Hard disk powerdown.
Someone once asked about whether or not a Mac Plus and hard disk
configuration should be powered off after use or just left on. I don't
think an answer was ever given. In my case I have a Mac Plus and MacBottom
SCSI-21 and I use it roughly every day. Is it better to just leave
everything run and turn the Mac's screen down, or powerdown the Mac, but
leave the disk running, OR power everything off?? I guess it depends on
how devastating the on/off action is to the circuitry, but I don't really
have a feel for that. Any suggestions?
Dan Stewart
STEWART_SYS@UTA.EDU
------------------------------
Date: Mon, 9 Mar 87 11:48:57 pst
From: apple!jordan@ucbvax.Berkeley.EDU (Jordan Mattson)
Subject: Correction to Postings on Script Manager
A corection to my posting on the Script Manager....
I made a big mistake in my posting about the Script Manager. I stated
that the Script Manager was maintained in ROM on the Macintosh SE and
Macintosh II. This is wrong.
The Script Manager is a package that is maintained in RAM (having been
loaded from the System File), and therefore will be available on the
Macintosh 512K, Macintosh 512KE, Macintosh Plus, Macintosh SE, and
Macintosh II when the Universial System Disk ships with the Macintosh II
this Spring.
I am sorry for any confusion that my mis-information has caused any of
you folks.
Jordan Mattson UUCP: ucbvax!mtxinu!apple!jordan
Apple Computer, Inc. CSNET: jordan@apple.CSNET
Tools & Languages Product Management
20525 Mariani Avenue, MS 27S
Cupertino, CA 95014
408-973-4601
------------------------------
Date: Mon, 09 Mar 1987 16:36 PST
From: GDCWOOD%CALSTATE.BITNET@wiscvm.wisc.edu
Subject: PROTECTING STATIC MEMORY
We have several Macintoshes located in public computer labs on the
Humboldt State campus. A problem that is occuring more and more
frequently is the changing of the control panel settings, which will leave
the Macs seemingly inoperable to other users. For example, a user sets
the control panel setting APPLE TALK to CONNECT and then leaves. Another user
uses the machine and needs to print to an Image Writer connected to the
printer port, no go, Apple Talk is now using that port. Most users aren't
aware of the effects this have; hence, it is assumed the machine is damaged.
I agree that the fix is an easy one; however, the machines are down until
the techs are made aware of it and schedule time to fix the problem.
After the long winded intro. here is my question. Is it possible to protect
the portion of RAM, kept active by the battery, so that control panels changes
cannot effect original settings. The idea being that the settings could be
set to allow general operation, and be protected from accidental or other
changes.
Any information would be greeeeeeatly appreciated.
Thanks in advance!
Dan Calderwood
GDCWOOD@CALSTATE.BITNET
Humboldt State University
------------------------------
Date: Mon, 9 Mar 87 22:05:12 EST
From: jonathan@mitre-gateway.arpa (Jonathan Leblang)
Subject: laser spoolers
Does anyone have any experience with any of the software laser spoolers
curreny available? I am considering purchasing one, and any comments would
be greatly appreciated.
FINDER 5.4 TIP
Holding OPTION down while selecting Eject from the file menu ejects the disk
and removes it from the desktop (the same as dragging to the trash).
This only works when selecting from the menu, option-command-E won't do it.
jonathan
|\ /| | | | \ | ARPA: jonathan@bert.mitre.org
| \/ | | | |__/ |__ BITNET: leblangj@vtvax3.bitnet
| | | | | \ | MABELL: (703) 883-5761
| | | | | \ |___ USNAIL: 7525 Colshire Drive
McLean, VA 22102
Jonathan A. Leblang
The MITRE Corporation
------------------------------
Date: Mon, 9 Mar 87 16:12:57 AST
From: PAUL%ACADIA.BITNET@wiscvm.wisc.edu
Subject: MacNifty Audio Digitizer
I am trying to set up the MacNifty sound digitizer on a Mac Plus and
have been attempting to get the proper cable setup. I can't see
what's wrong with my setup, but its not working. This is what I
have at the moment:
DB9 DIN8
pin 1: Frame ground to pin 1
pin 2: +5V (from 7805)
pin 3: Signal ground to pin 4
pin 4: TxD positive to pin 6
pin 5: TxD negative to pin 3
pin 6: +12V (from AC adapter)
pin 7: HSC in to pin 2
pin 8: RxD positive to pin 8
pin 9: RxD positive to pin 5
Does this look right? If not, can someone out there tell me what
is right. Please reply directly. Thanx.
UUCP: {seismo:watmath:utai:garfield}!dalcs!aucs!Paul
BITNET: {Paul:phs}@Acadia
Internet: {Paul:phs}%Acadia.BITNET@WISCVM.WISC.EDU
------------------------------
Date: Mon, 9 Mar 87 20:42 EDT
From: <KURAS%BCVAX3.BITNET@wiscvm.wisc.edu>
Subject: Are there 3rd party color monitors for Mac II?
We have a Mac II and an SE here at Boston College but Apple has not sent
us a color monitor. The one we have looks as though it was cannibalized
from an old Lisa. Does anyone know whether there are any third party RGB
monitors that can be used as-is with the Mac II and the Apple video card?
By the way, I understand many of you are upset that there is no upgrade
path from the Plus to the SE, but If you've seen what the inside of the SE
looks like you'd realize why this is impossible. The guts are laid out
completely differently and are packed much more tightly (hence the fan).
The case is also significantly different inside and out. Only the basic
shape remains the same. It's kinda like the difference brtween the II+ and
the IIe. I hope no one was naive enough to expect an upgrade path to the
II. (Smile...)
Another thing -- the slot in the SE is being described as a Macitosh SE
expansion slot, so I assume it's different from anything currently
available.
The II and the SE both look really good. The SE is what the Plus should
have been. (But like all Macintosh products, it's evolutionary. It could
not have been created without its predecessors.) The built-in hard disk is
great. General Computer will have a hard time competing with that. The II
is another story completely. Though I haven't seen color or gray scales
(our video board is beta and has a few bugs) nor have I heard sound (our
unit doesn't have a functioning sound chip) the speed is tremendous. And I
haven't encountered any applications which don't run properly (except an
old version of ResEdit). All in all, it looks like a winner. I'd say Apple
has done themselves proud with this thing. (And now will come the
inevitable nitpicky complaints of those who refuse to see what a great
product this is and instead look only at the omnipresent defects, always
wanting more and never thankful for what they have.) Sorry. That was just
my Apple-loving inner self speaking. Any questions? Mail me a note. I'd
also like to hear what others are thinking of this thing.
Pat Kuras
Boston College
<KURAS@BCVAX3.BITNET>
------------------------------
Date: Mon, 9 Mar 87 11:45 EDT
From: <BELSLEY%BCVAX3.BITNET@wiscvm.wisc.edu>
Subject: Rerouting default files in Word 3.0?
Is there anyway to reference a specific drive through a file name? The
question arises as follows: MS Word 3.0 places its default settings file,
"Word Settings" in the blessed folder and not on the disk that contains
the application "Microsoft Word". If, then, one uses the system in a RamDisk
and MS. Word on another 800K disk, the changes to the default settings file
go to the RamDisk and are not automatically saved on a floppy.
There is a way around this, but it is not completely satisfactory. The
file name in the code that is relevant to the reading and writing of
"Word Settings" occurs on Sectors 31 and 208. If one wants this file to
reside on the program disk, say, "WordDisk", then one can use Fedit to
replace these two strings with, say, "WordDisk:defs". This works fine so
long as the overall length of the new name does not exceed that of the
original ("Word Settings") and so long as it is terminated in the C-string
zero.
Using the above solution, the default settings file "defs" will not reside
on the application disk "WordDisk", and the changes that are made will be
saved on this floppy disk rather than in the RamDisk containing the System.
The trouble with this solution is that it requires the Word application be
particularized to a particular disk name, and it will no longer work
correctly if the WordDisk name is changed without similarly altering the
Word code.
So my question is: is there some means for indicating, say, the internal
drive in the file name that will cause this file always to be read and
written to the disk in the internal drive? I would have thought using the
drive number 1, as in "1:DefSettings" would do the trick, but it doesn't.
More generally, is there any way to name a file so that it is directed to
the default volume (which is where Word resides) rather than the volume
that contains the blessed folder? This would be ideal since the default
settings file would then always exist with the word application regardless
of disk name or drive.
My appreciataion in advance for any thoughts and suggestions.
david a. belsley
boston college belsley@bcvax3.bitnet
------------------------------
Date: Tue, 10 Mar 87 14:24:08 PST
From: PUGH%CCC.MFENET@nmfecc.arpa
Subject: Color printing from MacWrite
Well, I just had some fun. I have been playing with my Imagewriter II, which
is a darn nice color printer. I have used Silicon Press, ColorPrint, and
SuperPaint to do color printing with it and have decided that SuperPaint wins
hands down. I think I'll just toss out the others.
Using SuperPaint's draw layer you can do MacDraw in color and then copy them
into MacWrite documents where they will still print in color!!!!!!
That's right, color from MacWrite. I love it. Be sure to copy it from the
draw layer though so that it is saved as PICT resources.
Jon
N L pugh@nmfecc.arpa
M A L National Magnetic Fusion Energy Computer Center
F T N Lawrence Livermore National Laboratory
E L PO Box 5509 L-561
C Livermore, California 94550
C (415) 423-4239
------------------------------
End of INFO-MAC Digest
**********************