[mod.mac] INFO-MAC Digest V4 #99

INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (08/14/86)

INFO-MAC Digest         Wednesday, 13 Aug 1986     Volume 4 : Issue 99

Today's Topics:
                  110 baud tolerances (INFO-MAC V4 #93)
                           MPW and C Compilers
                             Hard Disk Tests
                       PtInRgn vs. PtInRect speed
                         modemDTR desk accessory
                        Delphi Mac Digest V2 #36
                 Princeton Math Font for the LaserWriter
                              MacSUN comms.
                             MacApollo query
                          info on imagen 8/300


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

Date: Tue, 12 Aug 86 10:12:42 PDT
From: jww@sdcsvax.ucsd.edu (Joel West)
Subject: 110 baud tolerances (INFO-MAC V4 #93)

this really takes me back to my high school days.  we modified
the command interpreter of an HP timesharing system to allow
users to change the speed on their terminal (they would log
in at 110 baud, then change their speed up to 300)

we made the algorithm
	it B=110, then char size = 11 (1+8+2)
	otherwise, char size = 10 (1+8+1)
so if you said
	RATE-110
you got 10 cps, 2 stop bits
	RATE-111
you got 11.1 cps, 1 stop bit, etc.

In experimentation with an actual ASR-33, we could use 1 stop bit, but
not much faster than 11 cps.  A 3rd-party terminal based on an ASR-33
could go 11.4 as I recall (the mapping to multiplexor parameters
was a step function, and the next step didn't work).

For someone used to hearing an ASR-33 chatter at regular speeds, there
was something slightly disconcerting to hearing it at the higher
speed.  But in answer to the question, 10.16 cps with two stop bits
would definitely work with any ASR-33 I ever saw.


	Joel West	(c/o UC San Diego)
	Western Software Technology, POB 2733, Vista, CA  92083
	{ucbvax,decvax,ihnp4}!sdcsvax!jww
	jww@SDCSVAX.ARPA

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

Date: Mon, 11 Aug 86 04:22:35 edt
From: Roy Leban <roy%farg.umich.csnet@CSNET-RELAY.ARPA>
Subject: MPW and C Compilers

MPW is great.  Need I say more?  I have about 10 pages of bugs and problems
and I still like it.  It's a lot more of a development system than anything
else on the Mac.  In contrast, Lightspeed C is one hell of an integrated
compiler and editor.  It's not a full-blown development system, however,
because it's missing all the tools that MPW has, including an integral
Pascal compiler and assembler, extensible tools, etc.  I've seen Lightspeed
Pascal and it's probably fairly equivalent to LSC, except for the insane
way it enforces their silly indentation and formatting style just like
MacPascal did.  Either are good non-professional development tools.  For
large applications, MPW is probably a better way to go.  Integrating assembly
is a pain in LSC and LSP.  It's trivial in MPW.  Resources can be created
in MPW with Rez, a very nice resource compiler (that's right, it's a compiler).
Some people on the net have commented that they might like to develop in
LSC and convert to MPW for their final version.  This isn't a good idea,
for several reasons, the most obvious of which is that ints are 16 bits in
Lightspeed and 32 bits in MPW C.  MPW did it wrong.  Compatability with UNIX
C is worthless if you don't have compatability with the toolbox, which
as Apple well knows, is built into every Mac.  Another reason for not
wanting to convert at the last moment is incompatability of include files;
the possibility of introducing errors due to compiler deficiencies on one
side or the other; I suspect I'll stick with Pascal almost exclusively in MPW.

In short, if you're working by yourself or on small projects, either LSC
or LSP will serve you well, as well as Aztec C, TML 2.0, etc.  If you're
working on a very large project, you'll probably want to look into MPW.
  -Roy Leban		(roy%farg@umich.csnet)

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

Date: Mon, 11 Aug 86 04:42:57 edt
From: Roy Leban <roy%farg.umich.CSNET@CSNET-RELAY.ARPA>
Subject: Hard Disk Tests

I thought people might be interested in hearing the results of a very
informal disk test of 4 different drives.  The test involved creating
a very large file and duplicating it in the finder.  The file was
created by diassembling the 128K ROMs into a text file, producing a
1.4Meg file.  The results are as follows:

	DataFrame 20		38 Seconds
	AST 2000		38 Seconds
	Apple HD20		140 Seconds
	HyperDrive 10		180 Seconds

The DataFrame and AST tests were performed on a MacPlus with 1Meg of
memory.  Enabling the RAM cache at 512K had no effect on the time.
The HD20 test was performed on a 512e (the same one the HyperDrive
was connected to) and a MacPlus.  Timing was identical.  The HyperDrive
10 is an original HyperDrive 10 with new GCC ROMs, connected to a 512
upgraded with the new Apple ROMs and 800K drive.  It had one 10Meg
HFS drawer on it which was almost completely empty.  Changing the
amount of free space on the various drives had almost no effect.
The test appears to be a simple transfer timing test.

Of course, the most interesting aspect of this test is the fact that
the HyperDrive showed up as the slowest of the bunch.  Earlier informal
tests had showed an MFS HyperDrive to be roughly twice as fast as an
HD20 connected to a 512K Mac.  It appears that GCC did something bad
when they made the HyperDrive HFS compatable.  This brings up a major
complaint that I have with GCC right now.  I have my HyperDrive
configured as one 10Meg HFS drawer.  I find that this is the most
convenient way to use it.  Twice, I have had problems with it and GCC
says that it is because I am not using it properly.  They say that I
should configure my StartUp drawer as an MFS drawer and then use other HFS
drawers for other stuff.  Considering that HFS drawers can not shrink,
you're pretty limited in the way that you configure your HyperDrive,
unless you do what I did.  GCC has basically said that they're not
concerned with the problems that I've had because I haven't done things
their way.  Because of this and the fact that MPW requires more memory
(it needs at least 1Meg to compile) and more disk space, my Mac +
HyperDrive is now sitting in its carrying case waiting to be sold (anyone
want it?).  I should mention that I used to have a high opinion of
GCC and even served as a Beta tester for some versions of their
software.  For someone who is less demanding than I am, the HyperDrive
may well be a good alternative.  I liked it a year ago when I paid the
bargain price of $1700 for it.
  -Roy Leban	(roy%farg@umich.csnet)

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

Date: Wed, 13 Aug 86 17:37 CDT
From: <BOYD%TAMLSR.BITNET@WISCVM.ARPA> (Scott T. Boyd)
Subject: PtInRgn vs. PtInRect speed

Recently, just for fun, a friend wrote a small program which put 400
randomly shaped regions on the screen and waited for a mousedown.  He
wanted to see just how long it would take to find any given region.
His code to find the region looked something like:
        for i:=1 to 400 do
                if PtInRgn(TheEvent.where,region[i])
                then InvertRgn(region[i]);

We thought we would need to be much more creative in searching for the
region, but this was just an experiment.  Oh, there was an else clause
that did a SysBeep(1) if it didn't find the region.

How did it turn out?  It found the region so fast that it seemed we hadn't
travelled all the way down with the mouse button.  If we clicked where
there was no region, it beeped instantly.  In fact, pressing the button
as fast as our video-game fingers could go, we could not get ahead of the
mac.

MORAL:  When you think you need to get cute and creative to get the speed
out of the mac, try the easiest way first.  You might be surprised.

scott boyd
the MacHax(tm) group

ps:  We tried this on a classic Mac, the Plus, and a Lisa under MacWorks.
     It seemed to be just as fast on all three machines.  And, as we all
     know, appearances of speed are as good a measure of anything as long
     as the user is happy.

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

Date: Wed, 13 Aug 86 16:31:20 cdt
From: brian@SALLY.UTEXAS.EDU (Brian H. Powell)
Subject: modemDTR desk accessory

     In a recent INFO-MAC, I mentioned that I had a desk accessory that kept
the new Mac+ serial driver from negating DTR the next time it was closed.  I've
had some requests for it, so here it is.
     This is useful when, for instance, you just want to quit a terminal
program for a short period of time without the modem hanging up.
     To use it, just select it inside your favorite terminal program.  It only
works for the next time the driver is closed, so you'll have to select it each
time you want to quit the program and not hang up during a modem session.
     This version is assembled to use the modem port.  To use it with the
printer port you can re-assemble it (making the obvious change to the source).
A skilled ResEdit or FEdit user can find the -7 in the code and change it to
a -9, without needing to re-assemble it.
     I've tested it on a Mac+ and a 128K (that's RAM, not ROM) Mac.  (It
faithfully beeped on the 128K Mac.)
     It consists of a PackIt2 file which includes the DA, the MDS assembly
source, a link file and an rmaker file.  Perhaps it will be archived as
sumex:<info-mac>da-modemDTR.hqx.

Brian H. Powell
		UUCP:	{ihnp4,seismo,ctvax}!ut-sally!brian
		ARPA:	brian@sally.UTEXAS.EDU

[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DA-MODEMDTR.HQX

DAVEG
]

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

Date: 12 Aug 86 20:37:07 EDT
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Delphi Mac Digest V2 #36

Delphi Mac Digest          Tuesday, 12 August 1986      Volume 2 : Issue 36

Today's Topics:
     RE: List Manager LDEF (Re: Msg 525)
     RE: Very Weird Problem (Re: Msg 542)
     RE: Very Weird Problem (Re: Msg 553)
     RE: Very Weird Problem (Re: Msg 552)
     RE: Very Weird Problem (Re: Msg 553)
     RE: Very Weird Problem (Re: Msg 542)
     RE: Very Weird Problem (Re: Msg 563)
     RE: Very Weird Problem (Re: Msg 563)
     Laserwriter FONDs
     Driver Needed
     lightspeed c
     RE: lightspeed c (Re: Msg 11541)
     RE: LW cartrige recharging
     Medical Uses of a MAC
     RE: Medical Uses of a MAC (Re: Msg 11554)
     RE: Medical Uses of a MAC (Re: Msg 11554)
     Medical Uses of a Mac
     RE: lightspeed c (Re: Mw'?11541)
     Paranoia Vindicated
     RE: Paranoia Vindicated (Re: Msg 573)
     RE: Paranoia Vindicated (Re: Msg 575)
     char speed
     lightspeed C (more grumbles)
     RE: lightspeed C (more grumbles) (Re: Msg 11617)
     RE: lightspeed C (more grumbles) (Re: Msg 11622)
     RE: lightspeed C (more grumbles) (Re: Msg 11623)
[ archived as

[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV2-36.ARC

DAVEG
]

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

Date: 11 Aug 1986 20:52-PDT
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Princeton Math Font for the LaserWriter

Princeton Font 3.0L for the Macintosh and Laserwriter is now available.
To obtain a copy, send SASE (padded) and a blank disk (400K or 800K) to
S.H.Lam, MAE Dept., Princeton University, Princeton, NJ 08540. Contribution
(to Princeton University) is welcome; $30 suggested for individual and $100
suggested for the 'office laserwriter'.

[I hope someone who writes away for this will post a copy for the
INFO-MAC archives, along with an appropriate shareware notice.  -- Steve]

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

Date: Tue, 12 Aug 86 16:11:17 WET
From: I Freedman <freedman@Cs.Ucl.AC.UK>
Subject: MacSUN comms.

Dear MacUser,
	Some of you asked for refs. on the MacApollo and MacShell
projects.
MacApollo:	Phillips. R.L. et al. (1986),IEEE CG&A May 1986,pp.53-57
		"A Bridge from Full-function to Reduced-function
		Workstations"
		Univ. of Michigan

MacShell: 	Contact: Steve Coy,Computer Science,University of
		Western Australia
		Sophisticated terminal to UNIX

		I. Freedman
		ALVEY MMI-137 (Real-time 2.5D Vision Systems)

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

Date: Wed, 13 Aug 86 13:42:44 edt
From: <wicinski@nrl-css.arpa>
Subject: MacApollo query


I've seen people talk about it, I've read little blurbs about it,
but I can't find any hard information on the MacApollo software.

Anyone have any good info, someone who is running it, a contact person??
Our local Apollo salesman is confused and does not know.

thanks
tim

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

Date: Tue 12 Aug 86 11:16:37-PDT
From: Antony Sword <SWORD@SRI-STRIPE.ARPA>
Subject: info on imagen 8/300

Does anyone know how to interface an Imagen 8/300 to
the output of a Macintosh running McDraw??

Thanks in advance

Sword@sri-ai

[ note from moderator:  There is a public domain version of software which
allows printing of macdraw documents on an imagen. I do not see it posted
in the archives but it was on usenet some time ago. I believe it was written
in C for a unix machine but I'm sure could be ported. If someone is familiar
with this code or has a copy, please submit it and it will be posted. DAVEG ]

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

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