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 ********************