info-mac@uw-beaver (08/21/85)
From: Moderator Richard M. Alderson <INFO-MAC-REQUEST@SUMEX-AIM.arpa> INFO-MAC Digest Thursday, 22 Aug 1985 Volume 3 : Issue 33 Today's Topics: New Moderator RFC: Command key standards BinHex Version 5 Correction to my posting about FreeTerm Macintosh VMEbus and CAMAC interfaces Converting SimpleTools to Consulair Small Talk on Lisa (ER, Mac XL, ER MacLisa, Er, MacLump) printing with versaterm MacDraw "bug" MacTerminal wiring for NEC modem, a question MacTerminal question/comment Graphics protocol for Red Ryder, request for information Multiplayer Games, request for information ---------------------------------------------------------------------- Date: Tue 20 Aug 85 22:23:01-PDT From: Rich Alderson <ALDERSON@SUMEX-AIM.ARPA> Subject: New Moderator I am the new moderator for the Info-Mac mailing list. John will continue to be involved in operation of the archives here at SUMEX, and will help me to deal with the trickier requests for inclusion in our mailings and such. He is going back to being a doctoral student most of the time. I would like to thank him for his very good job as moderator, and for giving me the opportunity to succeed him. I hope I do as well. Postings should continue to go to Info-Mac@SUMEX; administrivia should go to Info-Mac-Request@SUMEX. Rich Alderson ------------------------------ Date: Sat, 17 Aug 85 16:54:40 pdt From: jww@SDCSVAX.ARPA (Joel West @ CACI) (ttyd3) Subject: RFC: Command key standards (A copy of this was posted to the Usenet net.micro.mac....) REQUEST FOR COMMENTS: Macintosh Command Key Bindings It is interesting to note that the first chapter of the 1400 pages of Inside Macintosh is "Macintosh User Interface Guidelines"; begun in March 1982, it is also one of the oldest. A consistent user interface is what distinguishes the Mac's use of a mouse, menus, windows, etc. from any attempt to retrofit such gimmicks onto other computers, e.g., an IBM PC. However, thus far there has been no attempt to standardize the command key bindings for user applications. I'm referring, of course, to the keyboard shortcuts to menu selections that are intended for the most commonly used options. The existing differences are already getting annoying, and are likely to get worse. I've drafted a standard to guide my own personal work. At the same time, I'd like my software to be consistent with everyone else's. I've surveyed a number of programs that I feel are representative and were in my disk case. Emphasis was given to Apple-brand software (straight from the Oracle's mouth?) even though many were developed elsewhere. I omitted terminal programs because command is used as a control key, but looked at a few other programs (major and minor) not listed here. I'd like to summarize the results listed in detail below: 1. Text editor functions are common to most applications 2. Case (shift key) should NOT be significant 3. Preference is given to frequent (Plain) vs. infrequent (Print) uses 4. Most applications are reasonably consistent WHAT THIS IS * Suggested where corresponding functions are included * Intended for new programs * Consistent with "Macintosh User Interface Guidelines" * Representing the author's personal views only WHAT THIS IS NOT * An ANSII standard * Prohibiting alternatives where different functions are used * All-inclusive or comprehensive * Cast in stone I would like to hear comments from others who have developed software, or those who have programs not mentioned (particularly Jazz, Multiplan, and database programs.) I will summarize all responses in a later article. Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA [This message is archived as [SUMEX]<INFO-MAC>COMMAND-KEY.RFC. I am sending it out in its entirety because I think it will be of immediate interest to many who have difficulties with obtaining our archives. --rma] Macintosh User Interface Proposed Command Key Standard Joel West <jww@sdcsvax.ARPA> August 17, 1985 SURVEY OF EXISTING SOFTWARE and PROPOSED STANDARD Write Paint Draw Edit Word* Basic Finder Std. File New n n n n Open o o o Close w Save s s Print p Quit q q - q Edit Undo z z z - z - z z Cut x x x x x x x x Copy c c c c c c c c Paste v v v v v v v v Clear - b - Select All- - a - - - a a Duplicate - - d - - - d d Search Find - - f f f - f Find next f - - - - n - Change - - s h - Go To g - - g - - g Write Paint Draw Edit Word* Basic Finder Std. (Align)**** Left n l - L - - l Center m m - C - - m Right r r - R - - r Justify j - - - J - - j Style Plain p p p - ** - - p Bold b b b - B - - b Italic i i i - I - - i Underline u u u - U - - u Outline o o - D - - o Shadow s s - S - - s Super h - - - + - - Subscript l - - - *** - - Unless otherwise noted, key equivalents are not case sensitive, and order of menus is standard order. - Not available * Case must match ** Shift-spacebar *** Shift-minus **** Menu title containing align operations varies: Format MacWrite Style MacPaint, MacDraw Paragraph MS-Word AREAS OF OVERLAP/DISPUTE n Next or New o Outline or Open s Shadow or Save p Plain or Print VERSIONS SURVEYED MacWrite 4.5 MacPaint 1.5 MacDraw 1.0 MDS Edit "10/84" MS-Word 1.0 MS-Basic 2.0 Finder 4.1 ------------------------------ Date: Mon, 19 Aug 85 16:44:00 EDT From: Gary P Standorf <standorf@CECOM-2.ARPA> Subject: BinHex Version 5 This is BinHex version 5 which I downloaded from Compuserve. It is shareware and the author requests a payment of $10 if a person keeps this program. It supports the MacBinary file format which converts a file to binhex format in a significantly compressed form. The MacBinary file format is becoming increasingly popular on Compuserve since the data compression significantly reduces file transmission time. It will also convert files in all of the earlier BinHex formats (Hex, Hcx, & Hqx). Dehexify this file using BinHex.Hex, which is available on Info-Mac. Enjoy, Gary Standorf <info-mac@cecom-2> [You will find this program archived as [SUMEX]<INFO-MAC>BINHEX5.HCX. Please note that MacBinary is an *8-BIT* protocol, unsuited to use in a network/mail environment such as Info-Mac, and continue to use BinHex 4.0 or earlier for submissions. --rma] ------------------------------ Date: Mon, 19 Aug 85 13:44 PST From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA> Subject: Correction to my posting about FreeTerm Upon further experimentation, I find that FreeTerm 1.7 understands both the original (checksum) and more recent (CRC) error-detection protocols of XMODEM. If you drag down "XMODEM receive...", FreeTerm tries three times to initiate a CRC-type dialog (it sends a "C", then waits for the first block). If these bids all time out, FreeTerm sends a "NAK" to get a checksum-type conversation going, and waits for the first block. It's possible that some checksum-only XMODEM software might be confused by FreeTerm's bid for a CRC conversation... I haven't run into any yet, but caveat user. Be aware that when you receive XMODEM data from a checksum-only system, there will be a pause of about 1 minute before any useful data begins flowing... FreeTerm waits about 15 seconds before timing out each of the "C" bids. ------------------------------ Date: 20 aug 85 16:02-GVA From: BGT.WB%GEN.BITNET@WISCVM.ARPA Subject: Macintosh VMEbus and CAMAC interfaces Dear John, Here is a short contribution to INFO-MAC. Best Regards, Bruce. Version 2.0 of the MacVEE User Manual, describing the CERN-developed Macintosh-VMEbus and Macintosh-CAMAC interfaces, is now available to professional researchers. MacVEE was announced in INFO-MAC Volume 2, Issue 34 (21 April 1985). Numerous MacVEE systems are now in service, and a licence has also been granted to Hewlett-Packard for the development of an adaptation for their Series 200 personal computers. To request a copy of the latest MacVEE Manual, write to - B.G. Taylor, EP Division, CERN, 1211 Geneva 23, Switzerland Bitnet: BGT$WB@GEN Arpanet: BGT$WB%GEN.BITNET@WISCVM ------------------------------ Date: 09 Aug 85 08:30 EST From: CML5A9%IRISHMVS.BITNET@WISCVM.ARPA Subject: Converting SimpleTools to Consulair We were impressed enough in our users' group with simpletools to decide to attempt conversion to Consulair C for those in the group who didnt have megamax. Notice that i said attempt. We havent finished the conversion yet, but the following are some musings that i think would be helpful for someone more knowlagable about consulair that ourselves. 1) Consulair likes it's toolbox calls in mixed case. Use the megamax CONVERT program on SimpleTools first, and fix some of the cases that are a little different. It's faster to do it this way than converting each one by hand. 2) Consulair's choice of calling convention for FlushEvents is different than that used by megamax (there are two legal convensions from inside mac, one passing two integers and one passing a longword, consulair chose the latter) 3) Consulairs point and rectangle structures are different from that used by megamax. Fixes are needed to all code that makes use of these (sigh). 4) Consulair does not have a MaxApplZone call...at least none that we could find. 5) The external reference to stopstars (an integer) seems to be needed to be commented out. We couldnt get around "symbol unresolved" any other way... this may, however, be the cause of our other problems. 6) While we are on the subject of the word stop. Dont use it as a variable name or as the name of a procedure while using consulair. Because consulair compiles into assembler source and then assembles, and uses the names as actual labels, the assembler blows up when stop is used (for obvious reasons, it's matching with the STOP instruction) The simplest fix is to change this to something like "stopper" however, this makes any programs written using simpletools non-universal across compilers. There is probably another way around this problem. 7) And now, the big one. Consulair seems not to handle string conversion the same way as megamax. It seems has if we will have to be inserting explicit string conversion routines in for all calls involving strings (lots of them, as simpletools is BASED on strings) unless anyone out there who knows more about consulair than we do can offer some hints... We hope to get around these problems and when we do, to post the sources here, so that users of consulair can benifit from simpletools. If someone has beat us to the punch, super, how about posting it? Of course, Erik Kilk still holds all rights etc to simpletools, we are just adapting his code for use with another compiler. - Tom Dowdy "If it jams, force it, if it breaks, it needed fixing anyway." ------------------------------ From: fouts@AMES-NAS.ARPA (Marty) Date: 19 Aug 1985 1414-PDT (Monday) Subject: Small Talk on Lisa (ER, Mac XL, ER MacLisa, Er, MacLump) I just called Apple and talked to somebody who told me that somebody at Apple had in fact done a SmallTalk-80 Implementation on the MacLump (Lisa,) but that it wasn't going to be released. He then indicated that I might be able to get copies of such from "one of the user's groups, such as Apple 32" Can anybody put me in touch with someone who has a copy of the MacLisa Smalltalk code? Please reply directly, I'm not on the list right now. Thanks, Marty fouts@ames-nas ..!ames!amelia!fouts ------------------------------ Date: Sun, 18 Aug 85 21:21:27 PDT From: DAVEG%SLACVM.BITNET@Forsythe (David M. Gelphman 415-854-3300 From: x3186) Subject: printing with versaterm Regarding a previous question about printing on the Imagewriter with Versaterm: Versaterm requires that SWITCH 2-3 should be CLOSED on the imagewriter. Evidently this controls XON-XOFF. I had no problems using PRINT STREAM or PRINT GRAPHICS after this was set. I've never had any problem printing with any other programs once this was set CLOSED. David Gelphman DAVEG@SLACVM.BITNET ------------------------------ Date: Sun, 18 Aug 85 07:53:35 edt From: terrapin!mark@mit-eddie.MIT.EDU (Mark Eckenwiler) Subject: MacDraw "bug" In response to the 8/11 posting noting a bug in MacDraw: Draft mode printing probably was never meant to print graphic objects, on the Imagewriter or anywhere else. In AppleSpeak, "draft" means print using the printer's character ROMs--as in MacWrite's draft mode, which also omits any graphics present in the document. ------------------------------ Date: Mon, 19 Aug 85 14:19:47 PDT From: Mike Hogan <hogan@AEROSPACE.ARPA> Subject: MacTerminal wiring for NEC modem, a question I am trying to use MAC terminal with a NEC Modem. I am wiring up my own terminal cable and tried two possible connections. The first was suggested by a friend with a Hayes smart modem: MAC DB25 Connector 1+cable ground 1 2 unused 3+8 7 4 unused 5 transmit 2 6 5 7 8 8 hooked to 3 7 9 receive data 3 After reading <Info-MAC>rs232, I rewired as follows: 1+ cable ground 1 2 3+8 7 4 5 2 6 unused 7 5 8+3 7 9 3 I tried both with MAC terminal. My modem doesn't dial so I use my phone with a push button to start data transmission after receiving the carrier. I have not been about to get either set up to work. I don't know how to get MAC terinal to wait for me to dial the number, all it says is "no carrier". I am still not sure of the wiring?? Has anyone else been successful at using MAC terminal with a NEC 212A type modensuccessfully??? mike hogan@aerospace ------------------------------ Date: 20 Aug 1985 09:34 PST From: Steve Johnson <SAJ@ACC> Subject: MacTerminal question/comment Reply-to: SAJ@ACC Macterminal question: using option-click to position the cursor in vi does not work so well, mostly because Macterm sends a stream of arrow-key equivalents, rather than direct position-the-cursor commands (Versaterm does the job right). Does anybody know whether version 2.0 will do a better job, or if there is a way to fix the problem in version 1.1? I'm getting fast enough to want to use the mouse these days (and am doing it almost automatically). Also, I saw reference to a "SuperMacTerminal" available on the Compuserve BBS. Anyone know more about that? (the reference was in the July issue of MACazine, p.26). Thanks. steve johnson saj@acc ------------------------------ From: pur-ee!kangaro!milo@Berkeley Subject: Graphics protocol for Red Ryder, request for information Date: Fri Aug 16 18:24:02 1985 The documentation to the new Red Ryder program mentions that a graphics driver is built into the program that lets you do Mac graphics, dialogs...etc. over the phone lines. Would anyone happen to know where I could get some information on this protocol? Is it the same as the graphics protocol mentioned in Info-Mac a while back? I would like to get my hands on any information available on either protocol as I am in the process of writing some special driver software for the Macintosh section of the BBS I operate and I want to avoid "reinventing the wheel" if possible. If anyone can send me any info I would appreciate it. If possible, please try to mail the information directly to me as I don't get info-mac at my site. Thanks Greg Corson UUCP: {ihnp4 | ucbvax}!pur-ee!kangaro!milo My BBS "The Connection": (219) 277-5825 ------------------------------ From: pur-ee!kangaro!milo@Berkeley Subject: Multiplayer Games, request for information Date: Fri Aug 16 20:09:32 1985 Would anyone out there be aware of any good Mac/AppleTalk based multiplayer games OTHER THAN mazewars? I am looking for some games of this type, particularly ones where source code is available. I am also interested in multiplayer games that would run using a Unix system (possibly via dial-up) as an intermediary between several computers. Actually, I could use any form of multiplayer game...even ones that are not Mac based...so long as the source was available so I could add to or convert them. Basically, if it's Multiplayer and runs on a Mac or Unix computer I am interested. If you have any information on Mac or Unix multiplayer games please mail it directly to me, I don't get Info-Mac regularly so a reply here probably wouldn't get to me for months. If you have any suggestions of other people/newsgroups that I could contact for information on multiplayer Mac or Unix games please let me know (send network mailing addresses). Thanks Greg Corson UUCP: {ihnp4 | ucbvax}!pur-ee!kangaro!milo Or leave a message to the sysop on "The Connection" BBS: (219) 277-5825 ------------------------------ End of INFO-MAC Digest **********************