[mod.computers.macintosh] INFO-MAC Digest V4 #12

INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator William J. Berner) (02/20/86)

INFO-MAC Digest         Thursday, 20 Feb 1986      Volume 4 : Issue 12

Today's Topics:
                            DVI -> Postscript
                            12-mHz 68000 chip
                        address of GW instruments
                  re: unmoderate  !!! please don't !!!
                  Review of TML Pascal (more extensive)
                             High Baud Rates
                Using Single-Sided Disks as Double-Sided
                      Value of Inside LaserWriter?
                         Mac Plus compatibility
                          alternate 800K drives


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

Date: Tue, 18 Feb 86 11:45:37 PST
From: <DAVEG%SLACVM.BITNET@Lindy>
Reply-to: DAVEG%SLACVM.BITNET@SU-Forsythe.ARPA
Subject: DVI -> Postscript

Date: 18 February 86 11:43-PST
From: DAVEG@SLACVM
To: INFO-MAC@SUMEX-AIM
Subject: DVI -> Postscript

Date: 18 February 1986, 11:41:30 PST
From: David M. Gelphman         415-854-3300 x2538   DAVEG    at SLACVM
To:   INFO-MAC at SUMEX-AIM.STANFORD
Subject: DVI -> Postscript

Several places I have seem mention of a public domain program which will
convert DVI files (produced by TeX) to Postscript format.  Could
someone please point me to this or post it to INFO-MAC?  Thanks,
David Gelphman  DAVEG@SLACVM.BITNET

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

Date: Tue, 18 Feb 86 11:23 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Subject: 12-mHz 68000 chip

I suspect that this is due in part to the way that the Mac's video
circuitry works... it cycle-shared the video memory with the CPU.
Switching to a faster CPU would require either a dual-clock approach
(original-speed clock for the video, and faster clock for the CPU)
with the attendant increase in complexity, or a change in the video
refresh rate, with a substantial increase in video-path bandwidth
required.  Either of these approaches would have increased the cost
of one of the boards, and probably required major redesign of the
board.

Also, the Mac's RAM is not all that fast... I understand that it
typically forces the CPU to execute a single wait state per memory
access.  In this case, speeding up the 68000 wouldn't buy you much,
since it would be increasingly memory-bandwidth-limited.

The two hopped-up Mac systems I've seen (GCC's Hyper 2000, and Levco's
Super Mac) both use the same basic approach to the speedup... they
have their own high-speed RAM boards (100 to 150 nanoseconds, "no wait
states" alleged) and their own CPU clocking, running at the higher rate;
the original Mac RAM board is left in place at its old clock speed, and
is accessed only when writing to video memory.  Thus, the CPU can run
at full speed except when accessing the video memory (usually from
within QuickDraw).

I imagine that the next-generation machine (Jonathan?) will use a
68020 at a substantially faster clock speed.

[Also, I heard rumor that Apple had not been confident that they
could acquire a sufficient quantity of 12-mHz-rated 68000 chips.]

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

Date: Tue, 18 Feb 86 11:46:23 PST
From: <DAVEG%SLACVM.BITNET@Lindy>
Reply-to: DAVEG%SLACVM.BITNET@SU-Forsythe.ARPA
Subject: address of GW instruments

Date: 18 February 86 11:41-PST
From: DAVEG@SLACVM
To: INFO-MAC@SUMEX-AIM
Subject: address of GW instruments

Date: 18 February 1986, 11:39:39 PST
From: David M. Gelphman         415-854-3300 x2538   DAVEG    at SLACVM
To:   INFO-MAC at SUMEX-AIM.STANFORD
Subject: address of GW instruments

The address for GW Instruments who makes the MacAdios system is

   GW Instruments
   3 Ames St.
   Cambridge Ma.  02139

   (617)-577-1524


This information comes from the literature I have for MacAdios.
David Gelphman   DAVEG@SLACVM.BITNET

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

Date: 18 Feb 86 16:18 CST
From: MACA.AFCC@AFCC-4.ARPA
Subject: re: unmoderate  !!! please don't !!!

If unmoderating means not having info-mac in digest form, then.. read on...

Realizing of course the great amount of effort needed to put the digests to
gether etc.., I would like everyone to know how much I appreciate the filtering
and editing done by our moderator(s).  Info-mac was unmoderated when I joined
the club.  I remember those days very well, I spent endless time putting the
misc messages into some resemblence of order so that I could paste them into
our office automation bulletin boards for everyone else.  The work done by our
moderator(s) is saving many of us the equivalent amount of work at each
receiving site.  thanks and keep up the good work, even if it means waiting
somtimes!

... jay personius ...

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

Date: Tue 18 Feb 86 15:28:33-PST
From: Jim DeLaHunt <JDLH@SU-SUSHI.ARPA>
Subject: Review of TML Pascal (more extensive)

I am the TA for a mid-level Computer Science survey class.  My students have
been programming in TML Pascal for a couple of months now, and here are their
reactions:

BUGS
  * Running the compiler via the "Transfer" menu is unreliable.
  * Mismatched BEGIN/ENDs give confusing error messages.
  * Sets are limited in size (to 32 elements?)
  * Sets of integer subranges seem to work; sets of characters don't seem to.
  * All integer subranges start from 0; the subrange 10..11 has 11 elements.
  * Don't use sets to see if a character is a letter, use 'a' <= ch <= 'z'.
  * HALT doesn't work -- use the supplied ExitToShell routine instead.
  * Types flaky -- if List = ^Element, you cannot assign something of type List
    to something of type ^Element; they must both be List types.
  * Manual is weak -- no index.
  * Maximum of 8 consecutive IF...THEN...ELSE IF...THEN...., then the compiler
    gags.
  * Compiler has been know to hang for no apparent reason.
  * Assorted holes in the string support.  Cannot assign null string with
    Str := ''.
  * Never say Str[i] := ch.  Use CONCAT instead of assigning subscripts.
  * Always initialise strings to a non-null literal, such as Str := ' '.

MISFEATURES
  * No debugger supplied.
  * Debugging is limited to global symbols using MDS.
  * Parameters may not be of type STRING.  One must declare TYPE MyString =
    STRING and then declare the parameter MyString.
  * Procedures may not be declared FORWARD and EXTERNAL simultaneously.
  * Seperate compilation is unsupported (but possible).

GOOD POINTS
  * TYPE, VAR, and CONST declarations may be mixed together.
  * CASE statement has OTHERWISE clause.

DISCLAIMERS
  * This list is biased, since I assembled it by asking my students
    what trouble they were having.
  * Most of the problems seem to come from the fact that TML is selling
    a polished Beta test version, rather than a fully-tested release.
  * "The Next Release" should be much better.
  * TML has a better price/performance ratio than MacPascal or UCSD Pascal.
    It can be used for programs of an interesting size, it makes good use
    of the Mac, and it pretty much works.
  * And if it's any indication, none of my students has bailed out of
    TML yet and gone back to the DEC-20.

Seperate compilation IS possible, but you need the Macintosh
Development System and a little bit of knowledge.  The basic technique
is to compile a module with a dummy main program and generate an
assembly listing, edit the object file to remove references to the
main program, and then assemble the object file.  The linker can work with
these "doctored" files just fine.

Contact me directly if you have questions.  I do not read INFO-MAC.

	--Jim DeLaHunt, Stanford University	JDLH @ SU-Sushi.ARPA

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

Date: Tue, 18 Feb 86 16:21:27 est
From: Roy Leban <roy%farg.umich.csnet@CSNET-RELAY.ARPA>
Subject: High Baud Rates

The reason most programs can't handle high baud rates has little or nothing
to do with the serial driver.  Drawing characters and scrolling the screen
takes time.  The serial driver can run up to 1KBit, but there's now way an
8Mhz 68000 could ever keep up (much less at the 5Mhz that the Mac really
runs at).  The solution is to buy a better program.  (i.e., forget MacTerminal
and Red Ryder (which is twice as slow as MacTerminal)).  However, no current
commercial program keeps up above 7200.

  -Roy.
         (roy%farg@umich[.csnet])

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

Date: Wed 19 Feb 1986 11:29:47 EST
From: <OBRIEN@LL.ARPA>
Subject: Using Single-Sided Disks as Double-Sided

   Besides the experiences mentioned in the Delphi digest (Info-Mac v4#11),
has anyone else had good/bad luck using single sided floppies as double-sided
in the new double-sided drives?  Do some brands work better than others?
   If this works, it would help us to avoid buying too many DS disks while
the prices are initially steep.

                                       -- Tom O'Brien
                                   arpa:  obrien@LL

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

Subject: Value of Inside LaserWriter?
Date: 19 Feb 86 18:14:38 EST (Wed)
From: "Christopher A. Kent" <cak@Purdue.EDU>

We've had an order for Inside LaserWriter outstanding to Apple (through
Computerland, sigh, don't ask) for several months, and always get the
answer that it's out of stock. I've started wondering -- what
additional information is in Inside LW that isn't in the LW Appendix in
the paperback PostScript book? Can anyone tell me? Or should we just
cancel the order and buy the PostScript book (we're using the
pre-release 3-ring binder version now.)

Could someone tell me the ISBN of the PostScript book (it's not in the
local stores)?

Thanks,
chris

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

Date: Wed 19 Feb 86 16:37:35-PST
From: Jerold Wallis <WALLIS@SUMEX-AIM.ARPA>
Subject: Mac Plus compatibility

An apple rep that was at the university of michigan users group meeting
stated that most of the problems of software incompatability on the mac
plus that dealt with HFS could be worked around by placing the appication
in the same folder with any files that it was working with.

Other sources of incompatibility that were mentioned were the fact that
the drive mechanism and drive control was different, and that this might
interfere with certain copy protection schemes.  A poll of the members
turned up ABSOFT fortran as the only software that would not run due to
copy protection problems (although the updated version being sold as
Microsoft fortran runs reportedly without problem).  Experience was limited,
however, and posting of other incompatibility problems would be useful

J. Wallis

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

Subject: alternate 800K drives
Date: 20 Feb 86 10:57:03 EST (Thu)
From: "Christopher A. Kent" <cak@Purdue.EDU>

A representative of Haba Systems called me the other night to tell me
about their 800K drives. The prices are quite cheap ... $150 for an
internal (do it yourself installation), $200 for an external with
tradein of your Apple drive. I didn't think to ask how usable the
internal drive is without a ROM upgrade, or if Apple is willing to do
the upgrade without the drive and what the price break is, but I
thought I'd pass the info along.

Of course, I'm not associated with Haba Systems in any way, shape, or
form; I can't even afford to take them up on their offer.

Cheers,
chris

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

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