INFO-MAC Digest V3 #33
info-mac@uw-beaver
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 <ALDE...@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: j...@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
j...@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 <j...@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 <stan...@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%LA...@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.B...@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%IRISHMV...@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: fo...@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 DA...@SLACVM.BITNET
------------------------------
Date: Sun, 18 Aug 85 07:53:35 edt
From: terrapin!ma...@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 <ho...@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
**********************