Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-142.txt

Text File | 1994-12-08 | 34.0 KB | 910 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 14 Jul 92       Volume 1 : Issue 142

Today's Topics:

    Standard File Woes w/Super Boomerang
    How do I tell if I'm in COLOR or MONOCHROME??
    Multiple non-modal movable dialogs
    68040 extremely slow when rounding real numbers !!!!
    scsi driver for Kennedy 9track tape
    AppleEvents for Education



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

These digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Roby Sherman)
Subject: Standard File Woes w/Super Boomerang
Date: 11 Jun 1992 22:36:43 -0400
Organization: The Tao of Programming

Hi all. I posted a message earlier telling of how when I use a file
filter with the StandardGetFile call, I get a divide by zero message...
Well, after a little bit of investigating, it seems to me  that Super
Boomerang 3.0.2 is causing the problem. If I turn SB off, my code no
longer crashes... Any have any reason why the two wouldn't exist
peacefully together? Enclosed is the SF portion of my code, just in case
it *IS* me...

                thanks,

                   Roby

My Call is : StandardGetFile(@MyFileFilter,-1,emptyTypes,MyReply);

The filter function is :

{~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~}
 function MyFileFilter (pb: CinfoPBPtr): boolean;
 begin
  if pb <> nil then
   begin
    if allowanything then
     begin
      MyFileFilter := false;
      exit(MyFileFilter);
     end;

    if Pb^.IOFLFndrInfo.FDCreator = ctype then
      MyFileFilter := false
     else
      MyFileFilter := true;
   end;
 end;

- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Michael Hecht)
Date: Fri, 12 Jun 1992 19:31:22 GMT
Organization: SAS Institute Inc.

I've had this bite me also. The problem is that SB is calling your filterProc
as though it were a CustomGetFile-style filterProc. SB 3.0.2 is *supposed* to
fix the problem. DFaultD 2.22 has the same bug, and I don't know of a
later version that fixes it.

Once I determined what was going on, I hacked up this code to get around
the problem (my filter filters out files w/o a resource fork):


pascal Boolean ResourceFileFilter( ParmBlkPtr pb )
{
    /*
     *    Deal with stupid bug in SuperBoomerang & DFaultD.
     *    They're calling our filter proc as though it was a FileFilterYDProc!!!
     *    When this happens, pb will be null. So, just eat a longword on the stack
     *    to get around the problem.
     */
    if( !pb ) {
        asm {
            move.l        4(a7),8(a7)
            move.l        (a7)+,(a7)
            addq.l        #4,a6
        }
    }

    /* Don't filter out directories */
    if( pb->fileParam.ioFlAttrib & ioDirMask )
        return FALSE;

    return ( pb->fileParam.ioFlRPyLen == 0 ) ? TRUE : FALSE;
}

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

---------------------------

From: [e-mail] (Roby Sherman)
Subject: How do I tell if I'm in COLOR or MONOCHROME??
Date: 6 Jun 92 14:22:28 GMT
Organization: The Tao of Programming

Hi.


    Does the Cgrafport have some sort of flag that indicates when it's
displaying gray-scale or color? If not, how can I determine this?


        thanks...

                Roby

- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Vince Vann)
Organization: University of Miami Medical School
Date: Sun, 7 Jun 1992 18:11:09 GMT

[e-mail] (Roby Sherman) writes:
:
:     Does the Cgrafport have some sort of flag that indicates when it's
: displaying gray-scale or color? If not, how can I determine this?
:
: [e-mail]                    Roby Sherman

No.

You must look at the graphics device field 'gdFlags' to determine
this.  The gdDevType flag (bit 0) tells you whether you are in
monochrome mode (=0) or color mode (=1).

Of course, you should use the function TestDeviceAttribute( aDevice, 0) to
get this flag rather than test it yourself, since Apple could easily change
the gDevice structure or its flag locations.

To get the maximum depth device that intersects a global rect in screen
coordinates use GetMaxDevice( &globalRect).

[See IM-V, Chap. 5 on Graphics Devices].

Vince
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Rick Zaccone)
Date: 8 Jun 92 11:34:34 GMT
Organization: Bucknell University, Lewisburg, Pa.

In article <[e-mail]> [e-mail] (Vince Vann) writes:

   You must look at the graphics device field 'gdFlags' to determine
   this.  The gdDevType flag (bit 0) tells you whether you are in
   monochrome mode (=0) or color mode (=1).

Doesn't this just tell you if it's a color capable monitor?  This may
not reflect the current mode.  I thought that you had to check gdMode
to get the current mode.  If gdMode > 128, then we are not in
monochrome mode.  If this is not the correct interpretation, then
what's the difference between gdDevType and gdMode?

Rick Zaccone
- --
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 8 Jun 92 16:22:41 GMT
Organization: MacDTS Misfits

In article <[e-mail]>, [e-mail] (Rick Zaccone) writes:
>
> In article <[e-mail]> [e-mail] (Vince Vann) writes:
>
>    You must look at the graphics device field 'gdFlags' to determine
>    this.  The gdDevType flag (bit 0) tells you whether you are in
>    monochrome mode (=0) or color mode (=1).
>
> Doesn't this just tell you if it's a color capable monitor?  This may
> not reflect the current mode.  I thought that you had to check gdMode
> to get the current mode.  If gdMode > 128, then we are not in
> monochrome mode.  If this is not the correct interpretation, then
> what's the difference between gdDevType and gdMode?

No, the gdDevType tells you what mode the monitor is in at the moment.
In fact, there isn't any way to determine if a monitor is monochrome
or color; all the translation is done in software and there isn't
any way for a monitor to indicate to the system that it doesn't
support color.

Tim Dierks
MacDTS, but I speak for my knees

+++++++++++++++++++++++++++

From: [e-mail]
Date: 8 Jun 92 22:18:28 GMT
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Rick Zaccone) writes:
> In-reply-to: [e-mail]'s message of 7 Jun 92 18:11:09 GMT
> In article <[e-mail]> [e-mail] (Vince Vann) writes:
>
>    You must look at the graphics device field 'gdFlags' to determine
>    this.  The gdDevType flag (bit 0) tells you whether you are in
>    monochrome mode (=0) or color mode (=1).
>
> Doesn't this just tell you if it's a color capable monitor?  This may
> not reflect the current mode.  I thought that you had to check gdMode
> to get the current mode.  If gdMode > 128, then we are not in
> monochrome mode.  If this is not the correct interpretation, then
> what's the difference between gdDevType and gdMode?

I think the gdDevType bit of gdFlags is set if the device has been set
to display color; it's clear in grayscale. The gdMode field is a
number that may only make sense to a particular video card. In Apple's
old card it corresponds to various bit depth settings.  I avoid using
the word "mode" in connection with the gdFlags to prevent confusion
with the gdMode field of the GDevice record.

Use the following code to determine current settings of a particular
GDevice:

procedure GetVidMode(theDevice: GDHandle;var mode: Integer; var color:
Boolean);
begin
  mode:= theDevice^^.gdMode;
  color:= TestDeviceAttribute(theDevice,gdDevType)
end;

Note that someone may change the settings (from the control panel or
using one of the routines below) after you make this call.

In System 7, use the HasDepth function to determine if a particular
device can handle a particular depth/color combination. HasDepth has
the effect of translating a depth (say 8 bits) into a gdMode ($83 or
so on mine). Use the whichFlags and flags parameters to about color
vs. grayscale. SetDepth is similar; it sets the depth and color/gray.

GetVidMode (above) determines the current setting; HasMode determines
the availability of a potential setting.

[Ijust love using GDevices 'cause I get to type "gd" so much:-]

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

+++++++++++++++++++++++++++

From: [e-mail] (S4161006)
Date: 12 Jun 92 21:00:56 GMT
Organization: University of Massachusetts at Amherst

In <[e-mail]> [e-mail] writes:

> In article <[e-mail]> [e-mail] (Vince Vann) writes:
>
>    You must look at the graphics device field 'gdFlags' to determine
>    this.  The gdDevType flag (bit 0) tells you whether you are in
>    monochrome mode (=0) or color mode (=1).
>
> Doesn't this just tell you if it's a color capable monitor?  This may
> not reflect the current mode.  I thought that you had to check gdMode
> to get the current mode.  If gdMode > 128, then we are not in
> monochrome mode.  If this is not the correct interpretation, then
> what's the difference between gdDevType and gdMode?
>
> Rick Zaccone
> --
> [e-mail]
>

All this talk is making me nervous!!  I need to find out the pixel
depth the user has set to determine what kind of drawing I do. To do this
I do the following:

TheGDevice := GetGDevice;
Depth := TheGDevice^^.gdPMap^^.pixelSize;


So, is this OK?  If not what should I do.  Thanks in advance

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 05:07:05 GMT

In article <[e-mail]> [e-mail] (S4161006) writes:
>All this talk is making me nervous!!  I need to find out the pixel
>depth the user has set to determine what kind of drawing I do. To do this
>I do the following:

>TheGDevice := GetGDevice;
>Depth := TheGDevice^^.gdPMap^^.pixelSize;

Of course, this can't possibly be the right thing to do if the user has
two monitors on his mac, and the window spans them both, and tthey have
different screen depths: Some parts will have one pixelsize, and some
another.  Tehre is an article in the current issue of Develop magazine
that talks about a new system call in System 7 and how to emulate it
on older systems so that a single update event will get broken up into
one piece for each montior that the update region intersects. Of course,
if you do any drawing not at update time (say as a result of the user
using a scroll nar...).

+++++++++++++++++++++++++++

From: [e-mail] (Rick Zaccone)
Date: 13 Jun 92 19:44:55 GMT
Organization: Bucknell University, Lewisburg, Pa.

In article <[e-mail]> [e-mail] (S4161006) writes:

   All this talk is making me nervous!!  I need to find out the pixel
   depth the user has set to determine what kind of drawing I do. To do this
   I do the following:

   TheGDevice := GetGDevice;
   Depth := TheGDevice^^.gdPMap^^.pixelSize;


   So, is this OK?  If not what should I do.  Thanks in advance
- ----------------------------------------------------------------------
I've done some investigation and here's what I found out.  The
following is taken from Apple's Q&A Stack 4.0.6:

In my Macintosh system, I have two screens. The main screen in a 19"
monochrome. The second screen, to the left of the main one, is color.
How can my program know whether or not a color display is available,
its depth, and its coordinates?

The following bit of code will show you basically how to walk the
GDevice list and find the information you want from it. Most of this
information can be found on pages 119 and 124 of Inside Macintosh
Volume V.


count = 0;
GDevHand = GetDeviceList();
ScreenRect[count] = (*(*gDevHand)->gdPMap)->bounds;
ScreenDepth[count] = (*(*gDevHand)->gdPMap)->pixelSize;
ScreenColor[count] = TestDeviceAttribute (GDevHand, gdDevType);

while ((GDevHand = GetNextDevice(GDevHand)) != nil) {
     ++count;
     ScreenRect[count] = (*(*gDevHand)->gdPMap)->bounds;
     ScreenDepth[count] = (*(*gDevHand)->gdPMap)->pixelSize;
     ScreenColor[count] = TestDeviceAttribute (GDevHand, gdDevType);
}

- ----------------------------------------------------------------------
Here are some comments that I would like to add:

1. The result of the call to TestDeviceAttribute reflects the status
of the Grays:/Colors: radio buttons in the Monitors control panel. Be
careful interpreting the results of this call because it is possible
that the Colors: radio button is selected and the monitor is
displaying B&W. In this case, TestDeviceAttribute will return 1
(color). You also need to consider the depth of the color being
displayed. (Because 1 bit color == B&W). So, to determine if color is
currently being displayed, you need to consider more than the result
of TestDeviceAttribute. You also need to consider the value of
pixelSize.

2. The value of pixelSize reflects the currently selected item in the
scrollable list of screen depths in the Monitors control panel.
Considering pixelSize alone is not enough because it doesn't tell you
whether you are displaying grayscale or color.

3. To determine the current display device, use GetGDevice(). Be
careful though. This routine is not available on all Macs. In
particular, it is not available on Classics, Plus' and SE's. If you
try to call this routine on a Classic and you are running System 7 the
machine will bomb with an unimplemented A-trap error. Use
TrapAvailable as defined in IM Vol. 6 to determine if this routine is
available. If the trap is not available, you can be sure that the
machine is displaying B&W. I'm not sure if GetDeviceList() and
GetNextDevice() are available on all machines. The same problem may
exist with them.

Rick Zaccone
- --
[e-mail]


---------------------------

From: [e-mail] (HP48SX Archive Maintainer)
Subject: Multiple non-modal movable dialogs
Organization: Washington University in Saint Louis, Missouri USA
Date: Mon, 8 Jun 1992 11:27:10 GMT

Hi,
I am about to write a database front end in MPW C/C++.
I need to have a few dialogs open at the same time, and the user should
be able to select any of them. The dialogs might even have a vertical
scroll bar, a zoom box, and a close box. They will also contain stuff
with different fonts, fancy buttons I design myself etc.

Is there any way smarter to do this than to use dialogs, and use
IsDialogEvent, UpdateDialog, and lots of user items ? Is there any
sample code available for this anywhere ? I couldn't find anything on
ftp.apple.com, so here is a little work for DTS.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Integalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (Brain in Neutral)
Date: 9 Jun 92 17:36:15 GMT

>Subject: Re: Multiple non-modal movable dialogs

You mean...modeless dialogs?

> I need to have a few dialogs open at the same time, and the user should
> be able to select any of them. The dialogs might even have a vertical
> scroll bar, a zoom box, and a close box. They will also contain stuff
> with different fonts, fancy buttons I design myself etc.
>
> Is there any way smarter to do this than to use dialogs, and use
> IsDialogEvent, UpdateDialog, and lots of user items ? Is there any
> sample code available for this anywhere ? I couldn't find anything on
> ftp.apple.com, so here is a little work for DTS.

It sounds like you'd be better off to use regular windows.  By the time
you get done messing with all that junk so that you can properly support
modeless dialogs, you'll be sorry.

Have a look at Tech Note 203: Don't Abuse the Managers.  It has a section
on using the dialog manager.  The section seems to focus on modal dialogs
(whereas you're interested in modeless ones), but my own experience is
that getting the event loop right for modeless dialogs is, um, difficult.
At least, in TransSkel I know there were several revisions made to the
event routing code to get it to work properly for modeless dialogs, and
I'm still not sure it's correct yet.

Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Tue, 9 Jun 1992 19:45:42 GMT

In article <[e-mail]>, [e-mail] (Brain in Neutral) writes:

> ...my own experience is that getting the event loop right for modeless
> dialogs is, um, difficult.  At least, in TransSkel I know there were
> several revisions made to the event routing code to get it to work
> properly for modeless dialogs, and I'm still not sure it's correct yet.
> Paul DuBois

Hello Paul, glad you are well and still pushing bits!  I've done a number
of small applications based on modeless dialogs, the most complicated has
four independant window types (including the about box, which was just
another modeless dialog!).  I've never tried to do a skeleton like TransSkel
and I know that is a quantum leap beyond any fixed application, but after
a few revisions I think I've got a structure that works.

The key for me was to call IsDialogEvent once at the beginning and store
the result into a local Boolean.  For some events you care if it is a
dialog event and for some you do not.  The first two cuts were a big ifelse
on IsDialogEvent and two separate switch statements, the second cut was
one big switch in which about half the cases had if IsDialogEvent and the
other half didn't.  The third and final version uses the Boolean local:


/* Main routine and event loop
 */
main()
{
    EventRecord    myevent;
    Boolean    devent;
    WindowPtr    windp;
    short    wtype;
    short    itemhit;
    Point    where;

    initialize();
    do {
    windp = FrontWindow();
    if (drawmenubar) {
        DrawMenuBar();
        drawmenubar = 0;
    }
    WaitNextEvent(everyEvent,&myevent,30,nil);
/*
 * Don't call IsDialogEvent on null or update events in background.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 9 Jun 92 21:04:21 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (HP48SX Archive Maintainer) writes:
>
> Hi,
> I am about to write a database front end in MPW C/C++.
> I need to have a few dialogs open at the same time, and the user should
> be able to select any of them. The dialogs might even have a vertical
> scroll bar, a zoom box, and a close box. They will also contain stuff
> with different fonts, fancy buttons I design myself etc.
>
> Is there any way smarter to do this than to use dialogs, and use
> IsDialogEvent, UpdateDialog, and lots of user items ? Is there any
> sample code available for this anywhere ? I couldn't find anything on
> ftp.apple.com, so here is a little work for DTS.
> --
> Povl H. Pedersen             [e-mail]
> HP48sx archive maintainer

This is easier done WITHOUT using the Dialog Manager.

You'll end up spending way too much time making this work.  You'll always
be adding more and more hacks to make it work.  Everything you'll need
will end up being a userItem, of which the Dialog Manager doesn't handle.

For example, IsDialogEvent prior to System 7 did not check the result
of FrontWindow before deferencing the WindowPtr.  If there were no windows
visible, then the Dialog Manager would check two bytes in low memory to
be dialogKind.  But it could also bus error depending on what you have
at location zero.  To avoid this you have to call FrontWindow before
calling IsDialogEvent.  At this is only the beginning.


The Dialog Manager is not a user interface.
The Dialog Manager is not a user interface.
The Dialog Manager is not a user interface.
The Dialog Manager is not a user interface.
The Dialog Manager is not a user interface.


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 10 Jun 92 07:53:36 GMT
Organization: Reed College, Portland, Oregon


  [e-mail] (HP48SX Archive Maintainer) writes:
. I am about to write a database front end in MPW C/C++.  I need to have a
. few dialogs open at the same time, and the user should be able to select
. any of them....

  [e-mail] (Jim Reekes) writes:
. This is easier done WITHOUT using the Dialog Manager.
. The Dialog Manager is not a user interface.

  Agreed! I had not wanted to comment on this, because I wouldn't want to
rain on anyone's parade. The Dialog Manager was never intended to be the
end all be all of user interface management systems. The only reason you
would ever need to use it would be in the standard open, save, page setup,
and print dialogs.

  In my humble opinion, what you are describing are not modal dialogs per
se. Rather, I suspect that they are simply windows at the beck and call of
the user and the current document. The only reason modality would enter
into it would be if the function of one of the window was atomic, and would
have to be completed before doing anything else. From what you've
described, this is not the case. Disinfectant does a good job of being
utterly modeless, if I am not mistaken.

  My application framework handles dialogs with a stack of modality states.
When you open a modal dialog, you push a new modality state of true. This
prevents the user from switching to another window, and takes care of
updating the menus and so forth. When it goes away, you pop it. These are
usually done in the constructor and destructor methods for the dialog
object. Internally, the Dialog Manager is never used. The gadgets you
describe are implemented as a rooted graph of objects, with the root being
the dialog object itself.

  Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 03:56:53 GMT

Altough the Dialog manager isn't _intended_ to be the be all and end all in
window design tools, the DITL editor editor in ResEdit is very, very good.
It is a shame to throw that away just because some one at apple warns you
about the dialog manager.  What I do is re-implement the dialog manager so
I have my  own interpreter for DITLs. This lets me leverage off of existing
tools like the DITL editor in ResEdit.  With the new pop-up menu CDEF, it
is even easier to do some spectacular user interface design work just in
the dialog manager (provide you are willing to implement your own CDEFs
and MDEFs.)

---------------------------

From: [e-mail] (Tim Dierks, software saboteur)
Subject: 68040 extremely slow when rounding real numbers !!!!
Date: 11 Jun 92 00:05:52 GMT
Organization: MacDTS Misfits

In article <[e-mail]>, [e-mail] (Juha Pirttil{) writes:
> We would very much appreciate if someone from Motorola or Apple or
> anyone else who understands the inside of 68040 explained what is
> going inside 68040 during FINTRZ/FINT operations. Why is it so
> sloooow when rounding ??? Otherwise we have no complaints concerning
> its speed.

The 68040 doesn't contain a complete floating point processor; a number
of the FPU instructions are emulated by a software package included with
System 7.0.1.  Among these are FINTRZ, which the C compiler is forced to
use because of the C language specification.  Needless to say, emulating
these instructions is somewhat slower than they would execute were they
in hardware, as they are in the 68881/2.

There is a tech note on this situation, #317: "FPU Operations on
Macintosh Quadras".  In this note, the following workaround is
suggested:

Rather than using the sequence:

    FINTRZ        FPn,FPm                  ; truncate to integral value
    FMOVE.L       FPm,<ea>                 ; convert to integral format

you use the following:

    FMOVE.L       #$00000010,FPCR          ; set round-to-zero mode
    FMOVE.L       FPn,<ea>                 ; truncate to integral format
    FMOVE.L       #$00000000,FPCR          ; restore default modes

This should operate much faster on the 68040 with minimal performance
impact on the 68020/30 and 68881/2 combination.

As always, make sure you check for an FPU using Gestalt before
executing any of these sequences.

Tim Dierks
MacDTS, but I speak for my knees.

+++++++++++++++++++++++++++

From: [e-mail] (Juha Pirttil{)
Date: 10 Jun 92 07:00:34 GMT
Organization: Department of Physics, University of Oulu

For all programmers who use ploating point arithmetic on
a Motorola 68040 and want it to be as fast as possible:

Motorola 68040 rounds extended numbers *really* slowly.

An incoherant scatter radar analysis program called GUISDAP
has been developed in Finland. It has been written using
MATLAB and therefore it runs on all computers that can run MATLAB.
However GUISDAP is being developed on the Macintosh.

Because MATLAB is slow, it was decided to use C-language for
the most time-consuming parts. They are typically heavy
floating point calculations. One routine was a complex Lagrange
interpolation routine that has 24 floating point operations(FLOP).
When the routine was tested it used 9 us for these 24 FLOPs.
(Around 2.7 MFLOPS). The final routine had some rounding before the
actual calculation. When the final routine was tested the speed
dropped down to 0.333 MFLOPS!. After a few days of hard work we
found that the slowdown occurred because FINTRZ/FINT or FMOVE.L
operations are extremely slow on the 68040. FINTRZ/FINT uses 14 us
and FMOVE.L 12 us. In addition MPW C compiles simple operation

             i = (int)x,

where i is long and x is extended, to assembly in this way:


             FINTRZ    FP7,FP0           (14 us)
             FMOVE.L   FP0,-$0008(A6)    (12 us)
             MOVE.L    -$0008(A6),FP0    (<1 us)

Alltogether this rounding takes 26 us. Because there were two
roundings the total calculation time is 61 us (26 + 26 + 9)
which is desperately slow for our purposes.
On the Macintosh IIci exactly the same calculations took about
the same time than on the Quadra, which is because 68030/68882
rounds relatively faster than 68040 !!! (68030/68882: Calculation
90 us Rounding: 15 us, 68040: Calculation: 9 us Rounding: 26 us)

Fortunately we were able to solve the problem. We wrote a function
called ffloor (fast floor), which takes an extended number as an input
parameter and returns the integer part of it in a long integer. The
ffloor operation took only 2.6 us instead of 26 us. Following is the
listing of ffloor and some and some sample code.

We would very much appreciate if someone from Motorola or Apple or
anyone else who understands the inside of 68040 explained what is
going inside 68040 during FINTRZ/FINT operations. Why is it so
sloooow when rounding ??? Otherwise we have no complaints concerning
its speed.


#include <stdio.h>
#include <math.h>
#include <StdLib.h>

extern void timer(int *n);


int ffloor(extended x)
    {
    int *ii;
    char *ic;
    ic=&x;
    ii=ic+6;
    x = x + 140739635838976; /* 2^47+2^31 */
    return( *ii - 2147483648 ); /* 2^31 */
    }

main(int argc, char *argv[])
{
    extended x;
    int nn,i,j;
    x=2.3456;

    timer(&nn);
    for (i=0; i < 1000000; i++) {
            j=(int)x;
    }
    timer(&nn);
    printf("time = %d ?s\n",nn);

    timer(&nn);
    for (i=0; i < 1000000; i++) {
            j=ffloor(x);
    }
    timer(&nn);
    printf("time = %d ?s\n",nn);
    return(0);
}
/* Some runs:

demo
time = 25721024 ?s
time = 2634484 ?s
demo
time = 25507483 ?s
time = 2634566 ?s
demo
time = 25496106 ?s
time = 2633708 ?s
*/


Juha Pirttil{                         Markku Lehtinen
Physics Department                      Sodankyl{?Geophysical Observatory
University of Oulu
90570 Oulu                            99600 Sodankyl{
FINLAND                               FINLAND

 ********************************************************************
 *                     J u h a   P i r t t i l {                    *
 *                                                                  *
 *      [e-mail]            addr. Yliopistokatu 38/521   *
 *      tel: [phone]                   90570 Oulu             *
 *                                           Finland                *
 *      Macintosh Programmer                                        *
 ********************************************************************

---------------------------

From: [e-mail] (Don Bedford)
Subject: scsi driver for Kennedy 9track tape
Date: 12 Jun 92 21:36:52 GMT
Organization: SAIC, San Diego


I dont want to - but have to - write a device driver in Think Pascal to
drive a Kennedy 9 track tape unit which has a Kennedy 8124 scsi controller
board installed.  I am able to select and rewind the tape, but haven't
been successful in getting any further.  If anyone has endured similar
folly please respond with useful hints (I am developing on a Mac IIfx)

thanks in advance...

don bedford for doug rowitch for gary shaffer

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 05:13:36 GMT

Remember to protect both the parameter block and the destination buffer
in a SCSIRead and a SCSIWrite so it fdoesn't get flushed by the virtual memory
sub system. Under System 7, Apple does _not_ do this for you. (However, if
you are writing a true device driver (a DRVR resource with a name starting
with ".", then Apple will protect the buffer, and the io parameter block
for you. You are on your own about the SCSI control block though. See
Inside Mac VI for more info (og, also, if it isn't a true driver, you
also need to protect the code itself.)  Apple, please fix SCSIRead and
SCSIWrite!  (and while your at it, how about Asynch i/o like the floppy
driver has had since '84?)

Also, if your device is like mine, it will only abort an operation if
you send it a NAK at the end of a buffer read. If you need to abort the
read because you couldn't allocate the buffer to put the data, you'll need
a specail version of your call to SCSIRead that "drops the data on the floor"
so you can get it out of the SCSI device buffers and send that NAK.

---------------------------

From: [e-mail] ( Philippe Cinquin)
Subject: AppleEvents for Education
Date: 12 Jun 92 18:03:36 GMT
Organization: IMAG Institute, University of Grenoble, France

I've known for a long time there were special AppleEvents for education
programs, and I did not care about them, but, this afternoon, I realized
I desperately need to integrate them to my program!

Could anyone please tell me where to find info about them?

Thanks. If you email, please do so at "[e-mail]"

+++++++++++++++++++++++++++

From: [e-mail] (Levent Mollamustafaoglu)
Organization: Aiken Computation Lab, Harvard University
Date: Sat, 13 Jun 1992 05:52:00 GMT

In article <[e-mail]> [e-mail] ( Philippe Cinquin) writes:
>I've known for a long time there were special AppleEvents for education
>programs, and I did not care about them, but, this afternoon, I realized
>I desperately need to integrate them to my program!
>
>Could anyone please tell me where to find info about them?
>
>Thanks. If you email, please do so at "[e-mail]"

The latest APDA manual shows a document named (As far as I remember)
"The Education Suite" which should be similar to the Apple Events Registry
for the General Suite. I don't recall the price.

You can reach APDA by [e-mail], or get some useful
information via ftp from ftp.apple.com, probably in directory
dts/apda.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

---------------------------

End of C.S.M.P. Digest
**********************