[fa.info-mac] INFO-MAC Digest V2 #33

info-mac@uw-beaver (04/18/85)

From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>


INFO-MAC Digest         Thursday, 18 Apr 1985      Volume 2 : Issue 33

Today's Topics:
                        New files from Compuserve
                      New Macintosh Kermit on the Way
                          Function Keys for Mac
                              UPGRADE ALERT
                            Re: Serial Tales
                            Finder wish-list
                     Finder update, serial port buffer
                        Mac Std Graphics Protocol
                          MacWrite 4.2 problem
                     MacTerminal disk writing query
            Macintosh XL [sic] Parallel Port documentation ?
                            Inside AppleTalk


----------------------------------------------------------------------


Date: Sat 13 Apr 85 21:08:48-PST 
From: Gus Fernandez <FERNANDEZ@SUMEX-AIM.ARPA> 
Subject: New files from Compuserve 

The following files are now in <info-mac> New version of Extras D.A.
(DA-EXTRAS.HQX, .DOC, DA-EXTRAS-FKEY.HQX) Line/Word/Character count DA
(DA-WC.HQX) Phoenix block (Serial port DA communication) documentation
   (PHBLOCK.DOC, HQX) Screensaver DA (DA-SCREENSAVER.HQX, .DQC)

Also, in the file SWITCHER.SHAR is the pre-release of the switcher
(version 2.0) Use 'sh switcher.shar' from a unix system or edit the
pieces apart on another operating system.

This is still a beta test version, but Andy asks all users to submit
bug reports.  [ I am collecting comments for Andy. Any info-mac mail
about the switcher will be forwarded to him -jma ]

In the shell archive (shar) file are five files swtest.text - Beta
report description in text format. ***READ IT*** swtest.hqx - beta
report (MacWrite file) swdoc.hqx - User documentation (Illustrated
MacWrite file) swhints.hqx - Developer documentation - How to make you
application
   "Switcher friendly" (MacWrite file) switcher.hqx - The switcher
itself.


Have fun and go track down those bugs! (Not that the program has lots 
of them, but that it has to deal with so many existing applications!)

                                                Gus Fernandez

------------------------------

Date: Tue 16 Apr 85 12:17:35-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: New Macintosh Kermit on the Way

Just to forestall any parallel development, this is to announce that 
Columbia University is about to release a new Macintosh Kermit.  The 
program is written in C using the SUMACC Unix-based cross development 
tools, and is based on the new C-Kermit protocol modules.  It includes
VT102 terminal emulation with line and character insertion and
deletion.  The terminal emulator and file transfer functions are done;
the rest of the user interface (dialog, display, and control windows)
is being done now.  We expect to announce an initial release within
several weeks.

Columbia's Macintosh Kermit will be distributed on Columbia's Kermit 
distribution tapes and via computer network, like other Kermit
programs.  We recognize that Macintosh Kermit will be difficult to
bootstrap, especially at sites that do not have the SUMACC tools, so
we would like to place a few diskettes at sites where they will be
most widely reproduced and circulated, such as the member schools of
the Apple University Consortium.  Any other suggestions?
Unfortunately, Columbia simply does not have the resources to get into
the diskette production business, so we are looking for sites that are
willing to act as distribution centers.

------------------------------

Date: Tue, 16 Apr 85 10:44:58 EST
From: winkler@harvard.ARPA (Dan Winkler)
Subject: Function Keys for Mac


A friend has written a routine that installs itself on the system heap
and catches all events before the event manager gets them.  (This is 
how we came across the bug in Manx's GetTrapAddress().)  His routine 
can be set up to recognize any event, remove it from the queue, and 
replace it with any other sequence of events.  The idea is to
implement very general function keys.

His original gaol was to convert troff documents to word format using 
word by hitting a function key that would cause his routine to install
all the events necessary to search for and delete the next .i and put 
all the text up to the next .r into italics.

So now that the technical problems of how to get and alter events are 
solved, he has to decide on other details.  Should this routine be 
installed by a desk accessory?  Should it read function key
definitions from a file?  How should it work with the switcher?

If you have suggestions, please let me know.

Dan.

------------------------------

From: <bang!crash!bwebster@Nosc>
Date: Tue, 16 Apr 85 07:59:11 PST
Subject: UPGRADE ALERT


 TO:  Everyone who is considering a RAM/Hyperdrive upgrade

I've just heard some disturbing information from a usually reliable
source.  As many of you may know, Apple is coming out with a ROM
upgrade (128K) this year (probably in September) to fix bugs,
accomodate the double-sided disk drives, etc.  Well, according to my
source, Apple is instructing its dealers *not* to perform the upgrade
on any Macintosh that has been modified in any way.  In other words,
if you have done anything to your Mac (RAM upgrade, Hyperdrive, etc.)
other than buy the official (and incredibly overpriced) Apple 512K
upgrade, your dealer may not upgrade your ROM for you.  I have not yet
been able to get a confirm/deny/no comment out of Apple; I'll keep you
posted on what I find.


Additional information and commentary is, as always, welcome.

                              ..bruce..

[These are, of course, my own opinions, and do not necessarily reflect
anyone else's . . . though I suspect they just might.]

------------------------------

Subject: Re: Serial Tales
Date: 13 Apr 85 23:17:45 PST (Sat)
From: Van Jacobson <van@lbl-csam>

If you fit a least squares line to the Serial driver document's table 
of baudrate vs. 10-bit-magic-number (which I'll call "count"), you
get:

   TrueBaudrate = 114695 / (count + 2)

The Mac crystal is 3.670702MHz and the integer divisor that gives a
number closest to 114695 is 32.  Since the baud rate generator has a
divide-by-2, the SCC WR4 is set for x16 clock mode.  3.6707MHz / 2 /
16 = 114709.  This gives you:

   MacBaudrate = 114709 / (count + 2)

if you just stuff "count" directly into SCC WR13 & 14 (which is what
the serial driver is doing, I think).  The error in MacBaudrate is a
constant 0.4% from 110 to 19.2KBaud.

If you're going to transmit synchronous instead of asynchronous, the 
SCC automatically gives you x1 clock mode.  If you want 9600 baud, you
could select the speed with a count of 189 (which gives an error of 
0.1%, if I did the arithmetic right) then poke WR4 yourself to select 
sync. mode.  I've tried something like this & it more-or-less worked
(I was turning my Mac into a poor-man's serial line analyzer).  But,
if you're trying to make a product, why not license the source of the
RAM serial driver from Apple & hack it into the shape you need?

 - Van Jacobson, LBL

------------------------------

Date: Mon 8 Apr 85 17:08:29-MST
From: Tony Jacobs <T-JACOBS@UTAH-20.ARPA>
Subject: Finder wish-list

    It would really be nice to have two simple features added to the
new finder if it isn't too late.  All the new features are great, at
least the ones I've seen or heard about.

    It would be real nice if you could just put a disk icon in the
trash in order to eject it and remove its contents from the desktop.
This can be done now but since speed is the trademark of the new
finder, I think this is a good simple shortcut.

     The other feature is one that would allow the file names to take
up more than one line below the Icon.  It's a real pain to have to
move icons around in order to see the full name.  The file name could
just auto wrap on any character like a space, dash, or period. That
would clean up the appearance of the desktop a lot.

Steve Capps, Bruce Horn, hope you're listening.  The new minifinder is
looking better all the time.  Many people still like the Skipfinder
better as so far it has more utility. Being able to open on a document
is quite valuable.

T-Jacobs@UTAH-20

------------------------------


Reply-To: DAVEG%SLACVM.BITNET@Forsythe 
To: INFO-MAC@SUMEX-AIM 
Subject: finder update, serial port buffer

An idea and a question,

The idea:  seeing Microsoft word and the technique of double clicking 
on the title bar of a document and having it fill the screen (and go 
back to the original size and location after this) makes me realize 
that this technique should probably be a more global feature.  Perhaps
when the ROM is updated such a thing will be supported.  Regardless,
one of the most important places to implement such a thing would be
the finder.  Much of one's time is spent resizing windows on disks to
find what you are looking for.  I think it is very important to
consider this for the current update to the finder in the works (if
possible) or for future updates.  Any feedback about this idea AND is
there any chance that such a thing will/can be incorporated.

The question:  While working with the switcher using a terminal
emulator and another application I found that information received to
the serial port while the second application was running, appeared on
the screen when I switched back to the terminal application.  Does
anyone know how big the buffer is and whether it exists only on the
modem port or both ports?

 David Gelphman DAVEG@SLACVM.BITNET

------------------------------

Date: Mon, 15 Apr 85 09:55 MST
From: "Kevin W. Laurent" <KLaurent@DENVER.ARPA>
Subject: Mac Std Graphics Protocol

Attached is a proposed Standard for handling Quickdraw graphics via a 
telecommunications interface as put forth by Scott (Red Ryder) Watson.
As usual, there appears to be more than one standard because
Mainstay's Telescape offering was developed before this Standard came
out.  Does anybody know what kind of a protocol Mainstay is using?
 <KLaurent@DENVER> Kevin Laurent

[ There is a copy kept in <info-mac>graphics-protocol.txt -jma ]

------------------------------

Date: Tue, 16 Apr 85  8:54:03 EST
From: Alex McKenzie <mckenzie@BBNH.ARPA>
Subject: MacWrite 4.2 problem

I've been trying to use MacWrite 4.2 to edit a document which started
life on a local mainframe.  I used MacTerminal to record a "printout"
of the document, retaining line breaks.  I then opened this document
with MacWrite 4.2.  If I chose "CR means line break" during the
conversion process, MacWrite captured the entire text but all the
previous formatting was gone, which was unacceptable.  Alternatively,
if I chose "CR means paragraph" during the conversion process, 
MacWrite caputed the formatting but truncated off more than half the
text (with NO warnings/diagnostics).  Can anyone guess what's going
wrong, how I can work around the problem, or whether the next version
of MacWrite (4.5?) is likely to fix the problem?

Alex McKenzie mckenzie@bbn.arpa

------------------------------

Date: Wed, 17 Apr 85  9:01:43 EST
From: Andrew Malis <malis@BBNCCS.ARPA>
Subject: MacTerminal disk writing query

Does anyone know a patch to MacTerminal 1.1 that disables the 
save-state disk write after 8 seconds of inactivity?  This can get
really annoying at times, especially if you want to be able to load
MacTerminal into the Switcher, and then change disks to use another
application, but still occassionally switch back to Macterminal to
read any new mail.  If this were disabled, and you also turned off
recording off the top, then MacTerminal wouldn't need to do any disk
accesses at all.

Also, a hint for those of you using the switcher with MacTerminal 1.1:
give MacTerminal a preferred memory size of 140K if you want to be
able to use diskinfo and some of the other larger desk accessories.

Another hint: I've found that MacTerminal automatically turns off 
Xon/Xoff flow control when doing xmodem transfers, and then (if you
have it selected) automatically turns it back on again.  So, to run at
9600, you can just keep it on all the time.

Andy

------------------------------

Date: 10 Apr 1985 06:42-EST
From: mss%dartvax%dartmouth.csnet@csnet-relay.arpa
Subject: Macintosh XL [sic] Parallel Port documentation ?

We are trying to connect a device to the parallel port of a Lisa 2/10 
(or Lisa 2/5 without Profile) running Macworks, however, the Lisa 
manuals and IM provide scarce documentation. Before we take apart a 
Lisa to get the information we need, is there someone who has already 
attached a new device to the parallel port and written a driver for
it?  We'd like to trade notes.

------------------------------

Date: Thu, 11 Apr 85 21:23:30 EST
From: cadtroy!schoff@cadmus
Subject: Inside AppleTalk


Having spent some time implementing the AppleTalk protocols
(LAP,DDP,ATP,NBP) for a UNIX SystemV machine (the CadMac from CADMUS) 
based on a 1984 specification which had no description of the
"AppleTalk Manager" (First Draft 1/31/85).  I find myself in a
dilemna, I'm incompatible!!!  My design strategy has been to give the
user a "socket" handle.  In other words something that looks like a
Berkeley socket, without the necessity of using IP.

Now, looking at the "AppleTalk Manager" I think it is real nice for a 
single-user operating system, but leaves me kind of cold in the UNIX 
realm.  I'm wondering what John Q. Public thinks (those who have some
UNIX knowledge and have at least seen the "AppleTalk Manager").

Would anyone care to venture a postion on the necessity of providing 
an exact copy of the "AppleTalk Manager".  Note that it would be more
than possible to build this interface on the mechanism that I have
provided (ie "sockets").

I assume that if enought "neat" netware software comes out, it will be
demanded of me to provide for this.

marty schoff@cadmus.ARPA {wanginst,seismo}!ucadmus!schoff 
schoff%cadmus.csnet

PS:  for those who care my implementation is a kernel implementation
        with LAP being done
        in a front-end.

------------------------------

End of INFO-MAC Digest
**********************