Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!info-mac From: INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator William J. Berner) Newsgroups: mod.computers.macintosh Subject: INFO-MAC Digest V4 #27 Message-ID: <8603081514.AA17809@ucbvax.berkeley.edu> Date: Sat, 8-Mar-86 10:06:00 EST Article-I.D.: ucbvax.8603081514.AA17809 Posted: Sat Mar 8 10:06:00 1986 Date-Received: Sun, 9-Mar-86 05:07:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: INFO-MAC@SUMEX-AIM.ARPA Organization: The ARPA Internet Lines: 209 Approved: info-mac@sumex-aim.arpa INFO-MAC Digest Saturday, 8 Mar 1986 Volume 4 : Issue 27 Today's Topics: Transfer procedure... Vol 4 #23 - Red Ryder Problem 800k drives not working... Color Mac ---------------------------------------------------------------------- Date: Thu 6 Mar 86 21:57:08-EST From: Rich Subject: Transfer procedure... To all interested parties: This program fragment implements the strategy for calling the assembly-language-only trap "_Launch" from Pascal, as described in Macintosh Technical Note #52. This procedure was written in TML Pascal; it puts a Standard File box on the screen with a list of applications to which you can transfer. It's useful for putting in a program as a menu option, and with TML Pascal there's a way to implement this as a desk accessory. note -- this coed is slightly different from the LisaPascal given, and I've added in the SFGetFile call; however, it should work in LisaPascal too. I will continue to send useful program fragments as I find/write them. Please send me comments or questions about anything I post; I'd appreciate it. --richard. procedure Transfer; {Richard Siegel March 6, 1986 } TYPE pLaunchStruct = ^LaunchStruct; LaunchStruct = record pfName: ^Str255; {Pointer to application to be launched} param: integer; {State of sound/screen buffers} End; {LaunchStruct} var Reply : SFReply; ValidTypes : SFTypeList; volRef : Integer; Location : Point; prompt : Str255; pMyLaunch: pLaunchStruct; myLaunch: LaunchStruct; fName: Str255; err : OSErr; Procedure Launch; INLINE $A9F2; PROCEDURE LaunchIt(pLnch: pLaunchStruct); INLINE $205F; begin with Location do begin h := 60; v := 60; end; validTypes[0] := 'APPL'; SFGetFile(Location, prompt, NIL, 1, validTypes, NIL, Reply); if Reply.good then begin err := SetVol(NIL, Reply.vRefNum); pMyLaunch:= @myLaunch; With pMyLaunch^ do Begin pfName:= @Reply.fName; {pointer to our fileName} param:= 0; {we don't want alternate screen or sound buffers} End; {With} LaunchIt(pMyLaunch); Launch; end; end; ------------------------------ Date: Fri, 7 Mar 86 16:29:56 PST From: Lionel_Tolan%SFU.Mailnet%UBC.MAILNET@MIT-MULTICS.ARPA Subject: Vol 4 #23 - Red Ryder Problem I'm a micro user not a tech but I dispute the claim that any Red Ryder version is 99.9% VT100 compatible. We run MTS using DEC front ends on 9600 BAUD local lines. The software for the front ends uses XY addressing to postion the cursor for menus and such to save time. When Ryder gets a direct cursor address it resets to the beginning of the line rather than going to the correct location. The result is that all of the items on a horizontal menu are printed in the first few columns. This also does a wonderful job of encrypting incoming messages on our full screen message system. I quit using RR because of this and its slow speed. I didn't know an easy way to get to Scott Watson so I haven't reported the problem. VersaTerm also had the same problem but I understand that this has been fixed. Macterminal and MacKermit work fine. MacKermit is my terminal emulator of choice because it appears to keep up at 9600 BAUD. Now if MacKermit could only position the cursor with the mouse..................... ------------------------------ Date: Fri, 07 Mar 86 12:58 PST From: Dave Platt Subject: 800k drives not working... It matters a great deal whether your 800k drives are the new Apple drives, or third-party 800k drives such as the Haba and (I think) Mirror Technologies. It also matters whether you're running under the old MFS, or under HFS (and, if so, whether you're running the HD20 RAM-based version, or have the new ROMs or a Mac Plus). In short: the original Mac's .SONY driver assumes that all floppy disk drives have the same speed-control requirements as the Apple 400k drive. The Haba and other third-party 800k drives were built to be compatible with the Apple drives, and thus they work just fine on the Mac when plugged into the IWM (external-floppy) port. The updated version of the .SONY driver released (in the Hard Disk 20 fi le) with the Apple HD 20 is different. It assumes that any floppy drive containing more than 400k is one of the new Apple 800k drives, which has its own speed controller and does not require that the Mac fiddle with the speed-control lines. [The new Apple drives supply a "data transfer ready" signal that the older drives did not... another incompatibility]. So, if you plug a Haba 800k drive into the IWM port, the new driver will assume that it's a new Apple drive, and won't supply some of the signals that the drive needs. Result: it won't work. I've seen a patch that someone had constructed for the RAM-based version of HFS, that would cause the new .SONY driver to behave the way that the old one did (always supply speed-control signals). This patch must be applied to the Hard Disk 20 file using FEdit; it permits the Haba drives to work, but will probably render Apple 800k drives [and possibly the HD20] inoperative. I don't know if the patch can be used if you have the new ROMs... I rather doubt it. Ditto if you use a Mac Plus. My current belief is that third-party 800k drives probably will not work if you plug them into the IWM port on a Mac Plus or a 128k-ROM Mac. It appears as if the controller in the HD20 is providing the IWM speed- control signals to a floppy-disk drive plugged into its expansion port, regardless of the size of the drive. So, you should be able to continue to use your third-party drives by plugging them into the HD20. NOTE HOWEVER... all of the above is meaningless if you actually have Apple 800k drives for the Mac. These should (better!) work just fine when plugged into the IWM port on a Mac that [a] is a Mac Plus; [b] is a Mac with the 128k ROMs, or [c] is a Mac with the 64k ROMs, and is running the System and "Hard Disk 20" files released on diskette with the Hard Disk 20. Hope this helps... ------------------------------ Date: Fri, 07 Mar 86 13:25 PST From: Dave Platt Subject: Color Mac According to an article in Electronic Engineering Times last year, there are two new Macintosh-line products (or product families) in the works. Jonathan will be Apple's entry into the engineering-workstation marketplace. It will have a larger (14-inch?) monochrome screen with more screen "real estate" (more pixels in each direction), 11 meg of memory (upgradable to 16 meg), a 68020 processor chip (probably with a 68881 math coprocessor chip, or at least a socket for same) , and will be offered with a 20-meg internal hard disk as an option (and I can't imagine many folks buying an 11-meg machine with a single floppy drive & nothing else!). It will have expansion slots (possibly VMEbus standard?). Its physical footprint will be somewhat larger than the Mac, but not much. Rumored announcement date: late Spring to mid-summer 1986). Jason (aka "Versa Mac", "Modular Mac", and "Color Mac") will be announced sometime around 4Q86 or 1Q87. It will provide a color screen of about the same size as the Mac's. Rumored to be a compact machine of about the same size as the Mac, it will provide an architecture fairly similar to that of the Mac Plus (SCSI port) with a limited expansion capability (it may not provide a standard bus, from what I can puzzle out). Reportedly, the biggest factor in its release date is the availability of color monitors that can handle the necessary bandwidth [I suspect that Apple doesn't want to risk the sort of flak that Commodore has been taking re the Amiga's high-resolution color mode... since the Amiga uses a standard NTSC framing signal, high-resolution color tends to suffer from interlace flicker, which makes it very difficult to use for word processing]. Disclaimers: this is all rumor; I can't swear to the truth of any part of it. ------------------------------ End of INFO-MAC Digest **********************