shulman@topaz.RUTGERS.EDU (Jeff Shulman) (02/16/86)
Delphi Digest Sunday, 16 Feb 1986 Volume 2 : Issue 6
Today's Topics:
RE: Mac screen size
RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
Mac Plus System/Finder with old ROMs
RE: Mac Plus System/Finder with old ROMs (Re: Msg 5726)
Address arithmetic
RE: Address arithmetic (Re: Msg 5727)
RE: Address arithmetic (Re: Msg 5730)
RE: Address arithmetic (Re: Msg 5751)
Clipboard and Selections
68010, 68020
RE: 68010, 68020 (Re: Msg 5764)
RE: 68010, 68020 (Re: Msg 5765)
RE: 68010, 68020 (Re: Msg 5764)
RE: 68010, 68020 (Re: Msg 5775)
Doubling your Sony Floppies
RE: Doubling your Sony Floppies (Re: Msg 5772)
RE: Doubling your Sony Floppies (Re: Msg 5781)
MacWorld Expo Schedule
Mini 8 Connectors
Mac Plus 8-pin adaptor cables
Getting application info from a DA
RE: Getting application info from a DA (Re: Msg 5869)
LASERWRITER DRIVERS
RE: LASERWRITER DRIVERS (Re: Msg 5904)
CopyBits Help
RE: CopyBits Help (Re: Msg 5909)
RE: CopyBits Help (Re: Msg 5909)
RE: INFO-MAC Digest Vol 4 #8 Header (Re: Msg 5908)
Finder5.1 Speedup
----------------------------------------------------------------------
From: RICFORD (5725)
Subject: RE: Mac screen size
Date: 9-FEB-17:14: Mousing Around
In reply to the question about Mac screen size, I believe that Alan
Kay has stated something to the effect that perceived screen quality
is better when pixel actual size is smaller than some threshold. The
size of the Mac screen is then limited by that pixel size and the
number of pixels. (If I remember rightly, the magic size is less than
1/72" or so).
Ric Ford
"MacInTouch" newsletter
------------------------------
From: MACLAIRD (5724)
Subject: RE: ACCESSING "USED INTERNALLY" (Re: Msg 5613)
Date: 9-FEB-17:07: Programming
Scott,
I've been fiddling a little with TextEdit myself lately. Right now I'm more
than a little aggravated at what it took to figure out the AutoScroll settings.
Documentation (Inside Mac is documentation, right?) should describe when things
are not only counter-intuitive but downright mysterious.
(By AutoScroll I mean scrolling to the selection point after Cut, Paste, etc.)
I notice in Inside Mac, however, (p. I-391) a reference to a TEDoText routine,
which may be a better alternative to setting CaretState off (rabbits do love
dem Carets!) If you patch the TEDoText location with a routine of your own,
carefully saving the old address within your routine, you might be able to
set a switch whenever the selection range has been highlighted that would stop
the caret from being drawn. Or perhaps you could just test the SelRect area
to see if it was longer than a caret. Maybe you could just trap the function
that positions the pen to draw the caret to put it where you want it - like
off the screen?
Just goes to show, there's more than one way to slice a caret!
-Laird
------------------------------
From: RICFORD (5726)
Subject: Mac Plus System/Finder with old ROMs
Date: 9-FEB-17:20: Macintosh In Fact
We have been running the new System/Finder on an old 512K Mac with no problems
and a performance increase -- HOWEVER, we got work to do, and don't dare try it
on the production Mac's/hard disks. Anyone know _exactly_ what compatibility
problems (if any) exist between the new stuff and the old ROMs?
Ric Ford
"MacInTouch" newsletter
------------------------------
From: JIMH (5729)
Subject: RE: Mac Plus System/Finder with old ROMs (Re: Msg 5726)
Date: 9-FEB-17:41: Macintosh In Fact
Ric, quite a few of the members of Apple Dayton who bought harddrives in our
group purchase are using 5.1 and system 3.0 with no problems. jim
------------------------------
From: MACLAIRD (5727)
Subject: Address arithmetic
Date: 9-FEB-17:21: Bugs & Features
Hey all you MacsBuggers out there! here's a little piece of MC68000 that may
prove educational. I was trying to add the bottom half of A0 to A1, and was
getting kinda thrown by the results: it seems the top half of A1 was in on
the picture as well.
Much of the Motorola blue book is a little terse: they don't tell you that
address arithmetic always works on the full 32 bits of the destination.
Anyway, to see for myself, I got into MacsBug, and typed in the following:
SM BE00 8 92C8 60FA
BR BE00
PC BE00
A0 FFFF
A1 0
G
Which translates to:
ADDA A0,A1
SUBA A0,A1 ; put back the original A1?
BRA.S *-6 ; loop to breakpoint
and I invite all of you to fiddle with the values in A0 and A1 until you too
are confident that address arithmetic always operates on the full destination
register.
Oh, by the way, if you don't remember the values on entry to MacsBug, I'd exit
by the RB (reboot) command. Don't you just love grinding them floppies?
-Laird
------------------------------
From: JIMH (5730)
Subject: RE: Address arithmetic (Re: Msg 5727)
Date: 9-FEB-17:43: Bugs & Features
Laird, you mean you are still using MacsBug? TMON is much!!! better. jim
------------------------------
From: DWB (5751)
Subject: RE: Address arithmetic (Re: Msg 5730)
Date: 10-FEB 02:07 Bugs & Features
Laird, just pointing out that my little blue book says:
"011 - word operation. The source operand is sign-extended to a long
operand and the operation is performed on the address register using
all 32 bits" M68000 16/32-bit Microprocessor (4th Edition), pg 59
(ADDA description)
Maybe this is a recent addition?
David
------------------------------
From: MACLAIRD (5754)
Subject: RE: Address arithmetic (Re: Msg 5751)
Date: 10-FEB 04:29 Bugs & Features
Right you are!
It just goes to show that no matter how carefully you read the information the
"exceptions" to the general ideas will often wind up throwing you. In this
particular case, it wasn't causing a bug, but I just happened to notice the
numbers while debugging.
Life is full of these little surprises . . .
-Laird
------------------------------
From: RICFORD (5736)
Subject: Clipboard and Selections
Date: 9-FEB-18:51: Developer's Corner
OK, all you Clipboard hackers, how 'bout an explanation for this one:
The MacLightning spelling checker can check the spelling on a _selection_, in
Word, for instance, or even in MockWrite! This doesn't require a previous Cut
or Copy. How do they do it? Do they somehow know what is selected and do the
cut/copy themselves??
I'm looking at doing a DA with similar capabilities (don't laugh!), so I'm
interested in any discussion of Clipboard/Scrap behavior.
Ric Ford
"MacInTouch"
------------------------------
From: NRK (5764)
Subject: 68010, 68020
Date: 10-FEB 18:56 Hardware & Peripherals
Does anyone know what is involved in replacing the Mac's 68000 with a 68010 or
68020? I know that the latter will not work at full potential because of the
slow clock speed, but they should still speed things up because of their more
rapid execution of certain opcodes. --Nick Karp (NRK)
------------------------------
From: PEABO (5765)
Subject: RE: 68010, 68020 (Re: Msg 5764)
Date: 10-FEB 19:36 Hardware & Peripherals
The original (64K) ROM from Apple will not work with the 68010 or the
68020 because the information placed on the stack differs for some
exceptions. There may be other limitations. I don't know if the new
(128K) ROM supports the newer chips or not.
peter
------------------------------
From: MACLAIRD (5767)
Subject: RE: 68010, 68020 (Re: Msg 5765)
Date: 10-FEB 20:24 Hardware & Peripherals
As well as the need Peter pointed out to patch the exception vectors (not a
real hard item) it would be necessary to speed the clock rate of the Macintosh
to take advantage of the faster processor. This is why GCC simply chose to
use a faster 68000 chip; there is no real advantage to introducing incompatible
hardware when there's a simpler alternative.
On the other hand, the 68010 is pin-compatible with the 68000, while the 68020
is anything but! Personally, I can't see any reason for the Mac+ not to have
the 68010 MPU; except the software might not have been done to take advantage
of it. I've said it before.. and I'll probably be saying it again.
The real advantage the 68020 offers is the 32-bit "bus" path for data transfers
at the clock rate. This involves using faster DRAM or even Static RAM to feed
the processor; possibly even caching the memory as well. Some of this hardware
is not exactly cheap either! The present Mac supports its 8 MHz clock with its
memory interleaved: that is, the memory is capable of making two cycles while
the processor performs one. This is also interleaved during video display with
the screen hardware, which produces an effective 4 MHz rate except during the
Vertical and Horizontal Retrace time slices.
Thus, there is no real advantage to replacing the processor without
really going whole hog and getting into some serious effort. That's
why the manufacturers which have done so are asking such high prices
too.
Now, can someone tell me how to spell "compatible"??
-Laird
------------------------------
From: RICFORD (5773)
Subject: RE: 68010, 68020 (Re: Msg 5764)
Date: 10-FEB 22:52 Hardware & Peripherals
Nick,
Levco, who's putting a 68020 in a Mac, seems willing to talk about the issues
involved. Duane Maxwell is the "mouth" of Levco.
The new ROM's do indeed support the 68020.
You could probably get copies of some of the info. Levco was
distributing at the San Francisco Expo if you called: 619-457-2011
Ric Ford
"MacInTouch" newsletter
------------------------------
From: DWB (5787)
Subject: RE: 68010, 68020 (Re: Msg 5775)
Date: 11-FEB 01:50 Hardware & Peripherals
Actually, since the 68010 uses a slightly different exception stack format,
there are quite a few cases in the 64K roms that will be broken because of:
move sr,-(sp) ; save sr for rte instruction
move #2200,sr ; lock out serial interrupts
... do some processing
rte
The rte instruction will get the sr and then the pc off the stack fine in the
68000 but the 68010 will look for another word after that and find garbage,
depending the actual garbage it finds it will then get a "format exception"
(vector 14), continue as normal (minus one word on the stack), or do something
really bizarre and try to continue some (probably non-existent) instruction
(thus taking an additional 25 words off the stack and probably generating some
other exception.)
David
------------------------------
From: PEABO (5766)
Subject: Doubling your Sony Floppies
Date: 10-FEB 19:52 Hardware & Peripherals
I just initialized a dozen single-sided Sony floppy diskettes as 800K
double sided disks. All but one initialized fine, and when I tried a
second time, the recalcitrant one init'd just fine as well. I'll be
very interested to see if these stay good after being used for a bit!
peter
------------------------------
From: PEABO (5781)
Subject: RE: Doubling your Sony Floppies (Re: Msg 5772)
Date: 11-FEB 00:20 Hardware & Peripherals
Still going good with the Sony diskettes ... All 11 copied successfully to the
second backup diskettes. However, one odd thing happened: I got the message
"File "Foo Bar Bletch" could not be written and was skipped." on one of the
disks, so I reformatted the target disk (OK) and tried again (got the same
message). Then I formatted anothe diskette, and the exact same thing happened!
At this point I figured it wasn't the disk, so I copied the one file by itself,
and it worked OK. However, there were many files on the disk, and I also got
the message that the directory was full on the output disk. Very puzzling,
since the output disk seems to have the same amount of space allocated as the
input did!
peter
------------------------------
From: JIMH (5784)
Subject: RE: Doubling your Sony Floppies (Re: Msg 5781)
Date: 11-FEB 01:07 Hardware & Peripherals
Peter, i have had those problems with single sided drives also.
Several of the people at work had the bad taste to buy Amigas and are
using maxell single sided disks dual sided with no problems. jim
------------------------------
From: PEABO (5786)
Subject: MacWorld Expo Schedule
Date: 11-FEB 01:32 Mousing Around
There will be two more MacWorld Expos in 1986:
Boston, August 14-16 at the Bayside Exposition Center. Note, August 16 is a
Saturday.
Dallas, October 16-18, at the Dallas Market Hall.
Attendance figures release by Mitch Hall Associates show that the
first MacWorld Expo drew about 18,000 attendees (San Fran, Feb 1985),
the second drew 15,000 (Boston, Aug 85, no Saturday show day), and the
one that just took place in San Fran drew 25,000 attendees.
peter
------------------------------
From: HALL (5856)
Subject: Mini 8 Connectors
Date: 13-FEB 20:38 Hardware & Peripherals
[ This is in regard to the notice about Mac+ connectors from Jameco in the
previous Delphi Digest - Jeff ]
No, unfortunately, my sources (a dealer and others) weren't quite
right. The DIN 8 is not what is used on the Mac+. They are called
"Mini 8s", and although they look similar to the DIN 8s, aren't the
same. Apparently, the Mini 8s are smaller, and the pin arrangement is
slightly different. The place to get the Mini 8s is H & B Associates
in California. Their phone number (outside of California) is
1-800-423-3014. I don't know what their California number is, but you
can call Harmonix at (415) 322-5454, and ask for Mike Ferrera. He can
give you their other number(s). The connectors are $3.90 each in
quantities under 25.
Sorry about the confusion.
Brian Hall
------------------------------
From: RICFORD (5881)
Subject: Mac Plus 8-pin adaptor cables
Date: 14-FEB 15:53 Hardware & Peripherals
Thanks to ADVISE and some leg-work, I think I've stumbled on a good supplier of
Apple cables, specifically 8-pin -> 9-pin adaptor cables. They've got them in
stock and claim to be supplying them to Cupertino...
C Enterprises 310-110 Via Vera Cruz San Marcos, CA, 92069 619-744-8182
Ric Ford
"MacInTouch" newsletter
P.S. They're hand-soldered, guaranteed for life, and cost $10-13 depending on
quantity.
------------------------------
From: MARSHG (5869)
Subject: Getting application info from a DA
Date: 13-FEB 23:37 Programming
How can I get the finder info for the current application from a DA.
I can get the application's name and resource file renumber using
getappparms, but where do I go from there? Is there any way of
turning the resource ref # into a ioVRefNum so I can do a getfinfo
call or is there some other way of getting what I want (short of
rummaging through the finder bundle in the resource file.
Marsh Gosnell
------------------------------
From: BRECHER (5876)
Subject: RE: Getting application info from a DA (Re: Msg 5869)
Date: 14-FEB 01:03 Programming
If you assume that the application has changed the default volume (which I
suppose you must), then...
If HFS is not installed:
The quick and dirty way to get the vol is to use the resource refNum
as an offset into the FCB list. The file's FCB contains the address
of the VCB, which contains the vRefNum.
The slow and clean way is to do a series of indexed GetVolInfos, doing a
GetFileInfo on each volume until you find it.
If HFS is installed:
Use GetFCBInfo.
------------------------------
From: KWILLEY (5904)
Subject: LASERWRITER DRIVERS
Date: 15-FEB 12:53 Business Mac
I HAVE A PROBLEM THAT I HOPE SOMEONE HAS SOME INFORMATION CONCERNING.
I CURRENTLY HAVE A 512K MAC, HD20, AND LASERWRITER AT WORK FOR
GRAPHICS PREPARATION. MOSTLY VIEWGRAPHS FOR PRESENTATIONS. I USE
MACPAINT TO CREATE CUSTOM GRAPHICS WHICH ARE PASTED INTO MACDRAW
DOCUMENTS. IF I CREATE A PORTRAIT OR "VERTICAL" MACDRAW DOC. I CAN
PRINT THE FIRST COPY IN 30-60 SECONDS. HOWEVER, I PREFER TO PRINT
VIEWGRAPHS IN HORIZONTAL (LANDSCAPE) MODE. WHEN CUSTOM MACPAINT
GRAPHICS ARE PASTED INTO A HORIZONTAL DOCUMENT, IT CAN TAKE 30-40
MINUTES!!! TO PRINT. THIS IS UNACCEPTABLE. I COULD CREATE VERTICAL
DOCUMENTS AND PASTE IN ROTATED GRAPHICS BUT THIS IS UNPRACTICAL SINCE
EDITING BECOMES A CHORE. I THINK THE PROBLEM PROBABLY LIES IN THE
LASERWRITER DRIVER. I'M HOPING SOMEONE KNOWS OF A DRIVER WHICH IS
OPTIMIZED FOR HORIZONTAL OUTPUT OR KNOWS OF A SOLUTION LEAVE ME A
MESSAGE IF SOMETHING SHOWS UP. PS I HAVE ORDERED THE LASERWRITER PLUS
UPGRADE BUT HAVE BEEN INFORMED THAT IT WILL NOT IMPROVE THIS ASPECT OF
PRINTING PERFORMANCE.
------------------------------
From: PEABO (5915)
Subject: RE: LASERWRITER DRIVERS (Re: Msg 5904)
Date: 15-FEB 15:23 Business Mac
I don't see why it should take longer one way or another ... there may
be something about the format of the Quickdraw image produced by
MacDraw that makes it much harder to translate into PostScript,
though. It is possible that one of the other packages (like MacDraft)
might avoid the problem, and if you can test this at your dealer
before buying the package, it might be worth following up on.
peter
------------------------------
From: LOFTUSBECKER (5909)
Subject: CopyBits Help
Date: 15-FEB 14:41 Programming
I am trying to save (and later restore) the portion of the screen
image covered by the SFGetFile box, using _CopyBits. My code for saving
is as follows:
PEA ScreenBits(A5) ; Screen Bitmap (from)
PEA MyBitmap ; MyBitmap (to)
PEA CopyTop ; a rectangle, copy from
PEA myTop ; a rectangle, copy to
Clr.W -(SP) ; SrcCopy mode
Clr.L -(SP) ; no clipping
_CopyBits
MyBitmap is a structure containing (longword) a pointer to space
allocated with _NewPtr that will hold the image; (word) the value of
RowBytes; and (4 words) the bitmap's rectangle, 0000 0000 0088 015C:
top, left, bottom, right (the size of MFS SetFile box). CopyTop is
a rectangle (4 words), 0028 005C 00B0 01B8 which is the top, left,
bottom, and right coordinates of the SFGetFile box as displayed on the
screen. myTop is a rectangle, coordinates 0000 0000 0088 015C (i.e.,
the entire bitmap).
This portion of the code certainly does copy _something_ into
the space pointed to by the pointer in MyBitMap (determined by zeroing
the space and then looking with TMON after the _CopyBits operation).
After this call, I then call SFGetFile, which blanks out its area of
the screen. My code for restoring the screen then is as follows:
PEA MyBitmap ; my bitmap (from)
PEA ScreenBits(A5) ; screen bitmap (to)
PEA myTop ; a rectangle, now copy from
PEA CopyTop ; a rectangle, now copy to
CLR.W -(SP) ; SrcCopy mode
CLR.L -(SP) ; no clipping
_CopyBits
MyBitmap, myTop, and CopyTop are exactly as they were before the first
call. However, as far as I can see the screen remains exactly the same
as it was before the call.
Can anyone tell me -- or even give me some hints -- where I may be
going wrong?
Many thanks.
- Lofty
------------------------------
From: JIMH (5923)
Subject: RE: CopyBits Help (Re: Msg 5909)
Date: 15-FEB 19:07 Programming
Lofty, i havent researched this extensively but i seem to remember reading that
copybits scales ect to the dest rect. and some other things that are probably
unnessecary have you thought of using Blockmove? jim
------------------------------
From: JIMH (5933)
Subject: RE: CopyBits Help (Re: Msg 5909)
Date: 15-FEB 20:23 Programming
Lofty, i got the following code by disassembling an init resoure which
replace the cursor traps to ensure the watch cursor gets put up when
the system is busy. hope it helps, and if you want the entire program
i will email it to you (its not long) jim
QUAL proc2 ;-refs - INIT4 NewInitCursor NewSetCursor SaveOldCursor
* * the purpose of this routine appears to be to save off the cursor
* image pointed to by A0 into temporary storage. *
MOVEM.L D0/A1,-(A7) ;save registers
LEA OldCursorStorage,A1 ;A1 points to temp storage for cursor
MOVE #16,D0 ;16 bytes to cursor loc_1
MOVE.L (A0)+,(A1)+ ;move from old location to temp
DB_F D0,loc_1
MOVEM.L (A7)+,D0/A1 ;restore registers
RTS
;-refs - SaveOldCursor OldCursorStorage
DZS.W 34
------------------------------
From: RICFORD (5925)
Subject: RE: INFO-MAC Digest Vol 4 #8 Header (Re: Msg 5908)
Date: 15-FEB 19:18 Mousing Around
In response to the request for GW Instruments' address:
3 Ames St. Cambridge, MA, 02139 617-577-1524
By the way, some message headers had no message - was this intentional
editing??
Ric
------------------------------
From: NANOCHIP (5952)
Subject: Finder5.1 Speedup
Date: 16-FEB 00:31 Programming
This is essentially a copy-cat routine of the Finder4.1 speedup as reported
in the FEB issue of MacTutor (pp8) Mousehole report. Thanks to ANT KILLER for
the original idea and Finder4.1 search strings, which are slightly different
from those given below. (I've used this for a week on my MacDrive w/ System3.0
and it hasn't given me any problems (Finder5.0/Sys2.1 for bootup)).
To speed up Finder5.1 operation, use Fedit to make the following changes.
This will stop the Zooming effect (FrameRect) when a window is opened or
closed, by substituting NOPs (4E71).
It also speeds up application launching (!), since the expanding windows
(rects) don't have to be drawn when you open an appl from the desktop...try it!
Sector: 82 Position: 52
Search for: 486E FFE0 A8A1
Change to: 4E71 4E71 4E71
Sector: 82 Position: 80
Search for: 486E FFF8 A8A1 486E FFE0 A8A1
Change to: 4E71 4E71 4E71 4E71 4E71 4E71
Sector 82: Position: 118
Search for: 486E FFE0 A8A1 486E FFE8 A8A1 486E FFF0 A8A1
Change to: 4E71 4E71 4E71 4E71 4E71 4E71 4E71 4E71 4E71
<Chip
------------------------------
End of Delphi Digest
********************