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

info-mac@uw-beaver (05/07/85)

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


INFO-MAC Digest           Monday, 6 May 1985       Volume 2 : Issue 42-bis

Today's Topics:
                   Macintosh-VMEbus Interface Manuals
                   list of info-applebus coordinators
             Re: Printing Mac Postscript File?? (LaserPrep)
                       MacDraw 1.7 and Imagewriter
                     Improvements to UCSD Pascal....
              A script for converting net.sources.mac using xbin
                          more on Mac upgrades
                             2MB Mac upgrade
                          Inside Mac not $4.00
                      1 Megabyte Macs and Beyond ?
                        Has anybody used "Neon" ?


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

From: John M. Agosta <info-mac-request@sumex-aim.arpa>
Subject: Munged formatting

The automatic mailer got ahold of the digest copy before I finished
reformatting it ( to remove what the digester did to it). Here is 
the complete, correct copy that was supposed to go out yesterday.
My apologies to everyone. The next announcement is added, from
yesterday:

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

Date: 06 may 85 10:09-GVA
From: Bruce Taylor <BGT$WB@GEN.BITNET>
Subject: Macintosh-VMEbus Interface Manuals


I can now supply a limited number of User Manuals for the MacVEE
Macintosh-VMEbus interface described in Issue 34 of INFO-MAC.

The 37-page manual describes the interface at a level low enough for
VMEbus applications to be programmed in any of the Mac's resident
languages.  It is available to professional researchers active in
VMEbus applications and interested in using Macintosh as a system
controller.

To request a copy of the manual, send your (steam) mailing address to
<BGT$WB@GEN.BITNET> or write to B.G. Taylor, EP Division, CERN, 1211
Geneva 23, Switzerland.

             Bruce Taylor


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

Date: Sun 5 May 85 00:51:45-EDT
From: Ralph W. Hyre Jr. <RALPHW@MIT-XX.ARPA>
Subject: list of info-applebus coordinators

Here is a summary of redistribution list coordinators for
info-applebus.  These are the people to contact if you are at one of
the sites mentioned and you'd like to receive info-applebus.

Redistribtion List			Coordinator address	Area
info-applebus-bbn@bbn			tappan@bbng		bbn
info-applebus%ucbcory@ucb-vax		jsc%ucbcory@ucb-vax	Berkeley
appletalk@ucla-cs			request@ucla-cs		ucla
applebus@plus5.uucp			hokey%plus5.uucp@seismo	?
munnari!applebus@seismo			munnari!kre@seismo	Australia
info-applebus-incoming@harvard		sob%talcott@harvard     harvard, gcc
info-applebus@utah-20			oper.crum@utah-20	Univ. of Utah
info-applebus-scrc@scrc-stony-brook	hornig@scrc-stony-brook	Symbolics
info-applebus%daemon@tektronix.csnet	dsc%daemon@tektronix	Tektronix
ucl-info-mac@ucl-cs			hugh%hcig.nott%ucl-cs	United Kingdom
info-mac@mitre				cperry@mitre		Mitre Corp.
info-applebus@cmu-cc-te			ec0n@cmu-cc-te		Carnegie-Mellon
info-applebus@tartan			wohl@tartan		Tartan Labs
info-applebus@cit-20			mikes@cit-20		Caltech
incoming-info-applebus@columbia		chris@columbia		Columbia Univ.
info-applebus-local@upenn.csnet		ira@upenn.csnet		Univ. of Penn.
infomac@patch.arpa			byard@patch.arpa	West Germany
info-applebus@drea-xx			Gergely@drea-xx.arpa	Canada 
post-info-applebus@washington		macnair@washington	U of Washintgon
bboard.info-applebus@dec-marlboro	Deufel@dec-marlboro	DEC
applebus@emory.csnet			km%emory.csnet		Emory Univ.
info-applebus@wsmr			jmitchen@wsmr07		White Sands
info-applebus@s1-c			vdb@s1-c	Lawrence Livermore Lab
local-info-applebus@usc-ecl		schwartzkopf@usc-eclb	Univ. So. Cal.
applebus@toroto.csnet			drg@toronto.csnet	Toronto
nyu-info-applebus@nyt			russell@nyu-cmcl2	New York Univ.

Here are some other people at sites which don't currently have
distribution lists.  If you are at one of the sites listed below,
please contact the appropriate person to have a local distribution
list created for.  Thank you.

macintosh@nwc-143b, farber@udel-ee, rej@cornell, pugh%e@lll-mfe,
cmsmaint%brownvm.bitnet@wiscvm.arpa, cperry@mitre, cralle@lll-crg,
warner@clemson.csnet, swg.lpress@usc-isib, schoff@rpi.csnet,
verber@ohio-state.csnet, canas@ukans.csnet, liberte@uiuc.arpa,
fae.wu@ames-vmsb, billn@sri-unix, mcgrew@ru-blue

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

Date: 5 May 1985 1411-PDT (Sunday)
From: Brian Reid <reid@su-glacier.arpa>
Subject: Re: Printing Mac Postscript File?? (LaserPrep)

There are two different ways that a Mac application program can talk
to the LaserWriter. The obvious way is for it to generate PostScript 
directly; those files do not normally require a header. If an 
application program does not do anything special, it outputs to the 
LaserWriter by generating a file that has the syntax of PostScript but
the semantics of Apple QuickDraw. In other words, it is a PostScript 
file that consists of a series of calls on user-defined operators, and
each of those operators corresponds to some QuickDraw function. While 
this scheme can work with no cooperation on the part of the 
application, it does not produce the most satisfactory results because
the semantics of QuickDraw are reasonably device-dependent, and the 
computation that the LaserWriter needs to perform to emulate them at a
pixel resolution that is not an integer multiple of the screen 
resolution can be substantial.

There is a header file (that gets downloaded into the LaserWriter as 
part of its initialization sequence) that defines all of the operators
that are needed for QuickDraw emulation. It is not 
application-dependent, and it is site-dependent only in that it 
contains the server loop exit password for the LaserWriter, so if you 
have changed the password on your LaserWriter from the default
password of 0000000, you will have to edit the header file to reflect
that new password (the server loop password is the first 7 characters
of the file).

It would be a fairly simple matter to modify that header file so that 
it could be used as a genuine prefix to each file that is printed, 
rather than being downloaded into the printer outside of the server 
loop (where it will stay until the printer is rebooted).

I am enquiring as to whether or not the contents of this header file 
are proprietary to either Apple or Adobe. I can't imagine that they
are proprietary, but I want to check anyhow. If the file is not
proprietary I will happily send a copy of it out to the net (it is 40K
characters, of which 19K are the actual definitions and the rest are
comments and documentation that should be stripped from it before you
actually use it.)

        Brian Reid decwrl!glacier!reid
        Stanford reid@SU-Glacier.ARPA

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

Date: Sat, 4 May 85 19:10:53 EDT
From: Joel Malman <malman@BBNH.ARPA>
Subject: MacDraw 1.7 and Imagewriter

Warning (or is this a bug report?):

Don't remove the Imagewriter printer driver from your MacDraw (version
1.7) disk.  If you do, if will NOT able to 'start MacDraw cold' to 
create a new document i.e. if you double click MacDraw you get a 
window you can not edit in. The window is all gray and none of the 
tools work.  Removing the Imagewriter software does NOT seem to effect
editing OLD MacDraw documents.

joel

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

Date: 3 May 1985 18:11:29-EDT
From: jcr@Mitre-Bedford
Subject: Improvements to UCSD Pascal....

> From: werner@ut-ngp.ARPA (Werner Uhrig)
> From: jww@bonnie.UUCP (Joel West)
>
> "SofTech upgrades p-System software:
>     Performance speed on Apple II computers increased"
>         San Diego Tribune, April 22 financial pages
>
>     ...[the p-System software]got a reputation from program developers
> as
>     being particularly slow in execution, especially on the Apple,
> which,
>     some said, "ran slow as molasses."  [Goodwin] agrees: "We lost
> contact
>     with the customer and input of what they wanted in a product."
>        But that's all changing, he said: "We're speeding up
> performance
>     on the Apple II family by a magnitude of 20 to 30 times."


After reading the above, I called Softech to check it out.  Having
used Apple Pascal on the IIe for about a year now, I was pretty
excited at the capabilities described in this article.

The performance increase described in the article comes through the
use of a native code generator (NCG).  For those not familiar with the
p-system, an NCG is a program that takes the p-code produced by a
p-system compiler and translates in into native code for the processor
it is to run on.  The translation is not complete; some portions of
p-code are left intact and still must be interpreted.  However, the
increase in execution speed is still quite significant.

Alas, when I mentioned that I'd heard that an NCG (or some other 
improvement) might soon be available for the Apple II family, the man
at Softech knew immediately what my source was.  He said that the
reporter owned a IIe and got a little overzealous in his reporting.  
The fact is that they currently have no plans for an improvement to 
pascal for the Apple II family, though he said they WERE keeping an 
ear open, and if demand was high enough, such a product MIGHT possibly
be released in the future.

However, NCGs are available (or soon will be) for several other
processors.  It would be interesting to compare the performance of Mac
UCSD pascal using an NCG to Mac Object Pascal when both become
available.  Also, does anyone perhaps have statistics on UCSD pascal
with an NCG on the IBM PC as compared to Turbo Pascal?


                                  Regards,
                                             --- Jeff Rogers
                                                 jcr@Mitre-Bedford.ARPA

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

Date: Sat, 4 May 85 23:55:49 pdt
From: ix924%sdcc6@SDCSVAX.ARPA (Chris Borton)
Subject: A script for converting net.sources.mac using xbin

             This shell script is useful for taking all or some
     of the files in net.sources.mac and putting just the results
     of xbin on all of them into one directory.  Macsend (revised
     version of 4/27 by Barry Eynon (barry!playfair@Score) can
     then be used to download them all.  I'm sure there is a more
     efficient way to do the process than this, but it does work.
     I would appreciate any improvements.  With this shellscript
     as a base one could set up a Red Ryder RSP to log on, down-
     load everything, and log off pretty easily.  Red Ryder 6.0
     will hopefully have time batch files--even better!  Well, I
     hope this helps!

                Chris Borton (sdcsvax!sdcc6!ix924)

[ Arpa net subscribers can find a copy of this stored in
  UNIX-SRCS2XBIN.SHAR -jma ]

-----------------------< CUT HERE >--------------------------------
#! /bin/sh
# Shellscript for xbin'ing groups of files to one directory for macput.
# Invokes /bin/sh upon entry.
# 
# This shellscript will ignore directories and files that are unreadable,
# 	as well as any files without the line "(This file must be converted...)"
#
# Wildcards may be used.  Thus, to xbin all files in the range 240 to 249
#	use "macxbin 24*"
# Upon termination of the operation, the Macintosh bell will ring
#	two times.  This is your clue to wake up and see what is waiting.
# 	This might be deleted if you plan to do this in the background and 
#	don't want to be bothered.
#
# Done on May 5, 1985 by 
# Chris Borton (sdcsvax!sdcc6!ix924)
# University of California at San Diego. (Undergraduate CS)
#
mesg n
for f in $*
do
	if [ -f $f ]  && [ -r $f ]
	then
		fgrep "(This file must be converted" $f > /tmp/BinHextest

		if [ -s /tmp/BinHextest ]
		then
			rm /tmp/BinHextest

#  Replace "/hp1h/ixmaster/ix924/hcx" with the full path to the directory you 
#  	wish to put the files to download.

			cp $f /hp1h/ixmaster/ix924/hcx
			cd /hp1h/ixmaster/ix924/hcx
			xbin $f
			rm $f

#  Replace "/usr/spool/news/net/sources/mac" with the path to your 
#  	net.sources.mac if it is different.

			cd /usr/spool/news/net/sources/mac
		else
			rm /tmp/BinHextest
		fi
	fi
done
echo -n " "
echo "Downloads ready!"
echo -n 
echo -n 
mesg y

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

From: <bang!crash!bwebster@Nosc>
Date: Thu, 2 May 85 09:16:19 PDT
Subject: more on Mac upgrades

I posted a message here some weeks ago about Apple advising its
dealers *not* to perform the [hypothetical] 128K ROM upgrade on any
Mac that had been messed with by a third party.  At that time, I had
heard this report from only one source (albeit a reliable one).  Since
then (but before my message was posted here), I have received two or
three confirming reports from other (and distinct) channels.  I would
advise great caution in pursuing 3rd party upgrades (including DIY)
until Apple is willing to confirm or deny the reports.  I'd also
appreciate hearing directly from any of you who have any information
on this (I'll keep all names, etc., strictly confidential), and I'll
post a summary to the digest.  Thanks.
                                                        ..bruce..
                                                Bruce Webster/BYTE
Magazine
                                                bang!crash!bwebster@nosc
 {ihnp4 | sdcsvax!bang}!crash!bwebster

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

From: <bang!crash!bwebster@Nosc>
Date: Thu, 2 May 85 09:23:21 PDT
Subject: 2MB Mac upgrade

Having warned you all about 3rd party upgrades, I thought I'd pass on
some information to you.  I recently received a 3-page letter from
Duane Maxwell at Levco Industries about their Mac RAM expansion board.
To keep things brief, here's their price list and address:

        "Bare" board (everything but the RAM) $499.95
        1 megabyte upgrade kit 624.95
        1.5 megabyte upgrade749.95
        2 megabyte upgrade kit 874.95
        Levco/dealer installation charge 100.00

        2.0 megabytes installed:  $974.95

        Levco Enterprises
        11568 Sorrento Valley Road, #14
        San Diego, CA 92121
        (619) 755-7827

A friend of mine (Will Thompkins) stopped by Levco and played with a
2MB Mac.  He booted up the Assimilation RAMdisk software and created a
1.4MB RAM disk (which still left him a full 512K of work space).  He
loaded it up with various applications and was quite excited about how
well every- thing worked.

Maxwell, in his letter, says that Levco plans to release a package
"that will allow the user to partition the memory in any way he or she
wants:  into RAMDisks, cache buffers, and application heap space."  He
goes on to point out the advantages of using a write-through cache
buffer for your disk drives instead of a RAMdisk, namely that nothing
is lost in case of a power glitch or system crash (at least, nothing
that wouldn't normally be lost).

The upgrade also includes a piezo fan, which (Maxwell claims) makes
the 2MB Mac run cooler than a regular 512K Mac.  Levco is planning to
offer it as a separate product.

I thought those of you planning to do RAM expansion might want to
consider Levco's stuff.  The usual disclaimers apply--I have no
interests, connections, or in any way will profit or benefit if you do
(or don't do) business with Levco.
                                                ..bruce..
                                        Bruce Webster/BYTE Magazine
                                        bang!crash!bwebster@nosc 
{ihnp4 | sdcsvax!bang}!crash!bwebster

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

Date: Sun, 5 May 85 16:13:24 pdt
From: huxham%ucbcory@Berkeley (Frederick A. Huxham)
Subject: Inside Mac not $4.00


The reason some consortium schools think that they will be selling
I.M. for only $4.00 is due to a misprint in the latest price list from
Apple.

It listed the price as 5/$10.00 (or $2 each).

This is wrong.

At the computer store at U.C. Berkeley (I work there) you can buy them
for $15.00.  I would imagine other Universities having similar prices.

Fred Huxham huxham@berkeley

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

Date: Wed, 1 May 85 13:00:28 EDT
From: greenes@harvard.ARPA (Robert Greenes)
Subject: 1 Megabyte Macs and Beyond ?

I have seen various discussions about rumors and plans for expanding
the Mac's memory capacity beyond 512K, which all seem to imply, when I
read them, that the extra memory is to be used for ram disk purposes,
not as extension of operational memory space.

Is there some characteristic of the way the Mac uses its address space
that precludes program and data structures to extend beyond 512K, say
because the video buffer's address, or some other io address space was
set up to be in this range?  It would be unfortunate if the 68000
series machines and their potential address range were limited by this
kind of design constraint.  If this is the case, does anyone know
whethe either the new ROM for the Mac or some later change will
correct it?  Or can the Mac in fact take full advantage of additional
memory now?

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

Date: Fri, 3 May 85 17:05:56 pdt
From: ssc-vax!alcmist@uw-beaver.arpa (Frederick Wamsley)
Subject: Has anybody used "Neon" ?

I just read a blurb from Kriyas Systems announcing a programming
environment for the Mac called Neon.  Their literature describes it as
an extensible object-oriented language with full toolbox access.

Has anyone actually used it or seen it run?  How fast is it?  How
bug-free?  How well documented?

I will post a summary if I find anything out.  Please mail replies to
me directly.

Fred Wamsley UUCP:
{cornell,decvax,ihnp4,tektronix}!uw-beaver!ssc-vax!alcmist ARPA:
ssc-vax!alcmist@uw-beaver

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

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