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

info-mac@uw-beaver (03/16/85)

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


INFO-MAC Digest         Saturday, 16 Mar 1985      Volume 2 : Issue 15

Today's Topics:
                           info-mac directory
                    Re: Reading Lisa disks on the Mac
                       PICT and Macpaint/Scrapbook
                             MacFortran bug
                                   GEM
                          AppleTalk Developers
                          512K upgrade by Centa
                       Q: upgrade with 1-Meg-chips
          Address and phone-number of Microprocessors Unlimited
                 Details of Binhex 4.0 HQX Format Wanted


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

Date: Fri 15 Mar 85 15:03:09-PST
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: info-mac directory

This weekend I hope to complete a project to reorganize the info-mac 
directory into parts, grouping files with similar purposes together.  
This will work something like subdirectories, but instead I will 
preface file names so that grouped files are all next to each other.  
In this way some of the purposes of the files will be more obvious.  
You will still be able to find everything in info-mac@sumex.  These
are the prefaces I am contemplating:

DA- a desk accessory
DEMO- a demonstration program 
ED- courseware 
NEWS- text files of new releases, conferences, interviews.  
PICT- a macpaint format picture 
UTILITY- a utility (which is not a DA) for the mac 
VMS- system functions for VAX/VMS o.s.es 
UNIX- unix programs

TOPS-20 stuff apparently all begins with MAC.. and so it will remain 
unchanged. So will well known programs such as SUMACC, SEAGATE and
XLISP.  These changes and others will be docmented in a conversion
directory that I'll mail out upon completion.

Also I am looking into making the whole directory available on tape
for folks who might want to order copies by mail, just as SUMACC alone
can be ordered.

Direct your comments to INFO-MAC-REQUEST. -jma

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

Date: Fri 15 Mar 85 14:22:45-EST
From: Randy Forgaard <RANDY@MIT-XX.ARPA>
Subject: Re: Reading Lisa disks on the Mac

Michael --

     > Does anyone know of a program to read Lisa disks on the
     > Mac?  It would be nice to have access to some of the
     > software supplement assembler include files, etc.

At the last Boston Computer Society (BCS) Mac Users Group meeting,
someone asked the very same question for the same purpose.  The reply
was that the BCS has recently added such a program to one of its
public domain Mac diskettes.  The disks are $7 apiece.  (Price for
non-members might be higher.)  Contact:
     Eric Levine
     The Boston Computer Society
     One Center Plaza
     Boston, MA 02108 and describe the program you are looking for.
Also, it's likely that this program also exists on, say, CompuServe,
since most of the BCS disks contain public domain stuff obtained from 
elsewhere.

In addition, it was mentioned that in the next (i.e., last) Mac 
Software Supplement from Apple, all interesting stuff like include
files will be included both on the Mac disks and the Lisa disks in the
supplement.

- - Randy Forgaard

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

Date: Wed, 13 Mar 85 11:41:04 EST
From: olson@harvard.ARPA (Eric Olson)
Subject: PICT and Macpaint/Scrapbook


Larry's Problem is as follows (If I understand it correctly):
        1) His non-bitmap PICTs don't scale right
        2) His bitmap PICTs don't appear on the scrapbook or in
MacPaint.

I don't know the answer to (1), although the answer to (2) might help.

As for (2), I spent about 5 days trial-and-error trying to find the 
(as far as I can tell) COMPLETELY UNDOCUMENTED way to get MacPaint to 
recognize your PICTs.  It turns out that, within the Picture, the 
ClipRect should be set to the picture rect.  God only knows why.  
Also, the picture rectangle ought to be origined at (0,0), in case 
something pays attention to that.  This works:

/* Copy a piece of a bitmap onto the clipboard so MacPaint/Scrapbook
will */ /* understand how to deal with them.  Note:  The source of the
picture is */ /* a BitMap (made up of a buffer, a RowBytes, and a
boundsrect) */ /* */

copy(whichbitmap,rectptr)
        BitMap * whichbitmap /* The bitmap to take PICT from */
        Rect * rectptr /* The rectangle to copy */ {
        Rect temprect /* Rectangle to use for PICT */
        PicHandle picture /* The picture */

        SetRect(&temprect,0,0,rectptr->right-rectptr->left,
                rectptr->bottom-rectptr->top);
        picture=OpenPicture(&temprect);
        ClipRect(&temprect); /* THIS IS VERY IMPORTANT */
        StdBits (whichbitmap,rectptr,&temprect,srcCopy,(RgnHandle)
NULL);
        ClosePicture();
        HLock(picture);
        PutScrap(GetHandleSize(picture),'PICT',*picture);
        HUnlock(picture);
        }

Good Luck!

Eric.

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

Date: Tue, 12 Mar 85 08:45:51 est
From: mtu!russell@Glacier (Russell Reid)
Subject: MacFortran bug

   After reading the sunny reviews on info-mac, I went out and spent
hard cash for MacFortran.  It's got lots of nifty features, but it
won't run any of the programs I've tried it on.  Why not?  The block
IF statement doesn't work, for one thing.  It will never execute an
ELSE IF, no matter what.  That's pretty basic for a compiler; didn't
you guys who reviewed it ever try it on any programs??  It seems to
have other quirks I haven't traced down yet; I've got other things to
do.
  Some other comments on MacFortran:  it comes with a FORTRAN 77
manual, plus "replacements for Chapters 2 and 3", as noted without
explanation in an inclusions sheet.  Why didn't ABSOFT replace them
itself; it's only a loose-leaf manual?  The chapters are quite
different than the ones they replace, so the index and table of
contents are no longer valid.  (C'mon, guys, this is the age of text
processors! ) The replacements concern the changes in the debugger and
the Mac specifics of compiling and stuff.  The debugger is very nicely
implemented; it's easily the equal of MacPascal's stops, observe
windows, and step-by-step executing.  All references to a built-in
calculator simply vanished from the new Chapter 3; did it just get
removed?  I could find absolutely no reference to an abort procedure 
or interrupt, but command (cloverleaf)-C seems to interrupt almost
anything.  That's great, but where is the documentation?
  The menu option to transfer to the editor is great, but it is only
half a cake if you can't transfer back from "Edit" to "MacFortran".
  I like the copy protection scheme a great deal.  You can put it on a
hard disk, and only insert the "signature" disk once per bootup.
That's not much headache.  There's a flaw there, too:  if you
anticipate the coming request for the signature disk and insert it
BEFORE it's requested, you get into some kind of a loop, so that you
must eject and start over.  Oh, well, beats the socks off MacPascal
anyway.
   On the whole, MacFortran has lots of nice features and should be
wonderful once the problems are ironed out.  Since I was planning to
use it for something of importance this weekend, I am rather
disappointed in the IF statement, but eventually it should be great.
It gives complete access to the Toolbox, including some documentation.
It compiles pretty fast, (I'd say very fast for FORTRAN), executes
very fast, and has a wonderful debugger.  It allows me to set the
default print and read unit (i.e. "*") to be the screen instead of the
printer, but it makes me remember to reset that option each time the
compiler is called.  I'd rather MacFortran did the remembering.
   There are a bunch of extended features, plus some features I'll
call FORTRAN 88, i.e. structured and strong type features that can
turn off implicit typing, and can essentially REPEAT-UNTIL and
WHILE-DO, without statement numbers.  Nice.
   Documentation should INCLUDE specifications for a language; even if
the language is FORTRAN it should never be ONLY that.  Who ever reads
the specs for a language if he can help it??

Russell Reid, Michigan Technological University

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

Date: Wed 13 Mar 85 18:31:02-PST
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Subject: GEM

Last night at the Software Entrepeneurs Forum meeting, I saw GEM
running for the first time. It was running on an IBM PC and will run
on all of its clones. It also will run on the Atari Jackintosh and on
a Lisa 2/10 running CP/M 68K as a development system for the Atari
machine.

Gem is based on an extension of DRI's GSX VDI (Virtual device
interface) product which provides hardware-independent graphics
capability. The version implemented is actually an extension of the
original GSX as it contains rasterop operations required for a window
oriented system. This can be thought of as the counterpart to
QuickDraw on the Mac.

Ontop of the VDI is the AES, which defines things such ast the
drop-down menus, windows, dialogs, etc. This is the part which most
closely corresponds to the Mac's User Interface Toolbox.

The underlying operating system is MS-DOS so that no additional
capability is provided here such as memory management.

Applications make calls to the VDI, AES and DOS. One application si
provided to users, which is the desktop - a replacement for
COMMAND.COM, which is most like the Macintosh Finder.

The GEM desktop is almost a complete one-for-one RIPOFF of the
Machitosh finder. I saw no new inovations at this level (although the
underlying AES had a few new features.) The dead giveaway was in the
menu structure.  All of the same functions were there as in the Mac
finder, with perhaps slightly different names (Show info vs Get info)
but they were (not so) roughly in the same orientation as on the Mac.
Everything from desk accessories (a calculator and a clock) through
the file, and view menus. Unfortunately, I did not get a chance to
view these up close but everything seemed to be practically the same -
even the initial location of disk and trash can icons.

While the lower levels of GEM support more than one mouse button, all
of the current application software relies on only a one button mouse.
A mouseless keyboard driver is also available.

The AES provides a little more in the way of innovation. GEM's scroll
bars give a hint as to the document's size as well as its position
relative to the window. The top of the thumb is the top of the screen.
The bottom of the thumb is the bottom of the screen. Xerox, and most
other scroll bar implemen- tations have done this all along. Near the
top right corner of the window is an upwar pointing arrow which blows
up the window to the full size of the screen These were practically
the only improvements I saw over Apple's impementation.  Everything
else seemed to act, if not look the same.

Apple has a pattent on pull-down windows. DRI snuck around this by
creating drop-down windows which drop down as soon as the cursor nears
the menu's title on the menu bar. Clicking on an item below then
executes a particular function.  Clicking on an area outside the menu
cancels the function. Menus can thus stay down indefinitely, thus
creating a "mode" which may cause a mouse click to be misinterpreted.

Gem applications even have resource files similar to those used by the
Macintosh, except that they are organized into a tree structure as
opposed to apples fixed two level name/ID structure.

An interactive resource construction set is avilable which is what the
Mac resource editor is trying to be. (This is one thing DRI got right,
although this was only a programmers' tool and not a stand-alone
application.)

GEM is quite definitely a Macintosh ripoff. It provides little in the
way of innovation in the area of user interfaces. Its only redeeming
factor is availability on non-Apple Hardware. It still has yet to be
proven that it can succeed in an IBM-PC marketplace where others such
as VisiOn and DeskQ have failed. The Atari machine is still a dark
horse and the effect of that machine on the market is still unknown.

These are my own personal views. I am neither affiliated with Apple
Computer nor Digital Research.

                                                        Gus Fernandez
                                                        FERNANDEZ@SU-SCORE

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

Date: 15 Mar 85 14:46:47 EST
From: Kevin.Dowling@CMU-RI-ROVER
Subject: AppleTalk Developers


The March 11 issue of InfoWorld had an article on Appletalk 3rd Party
Vendors. It listed the following 21 licensed third-party developers of
product for the Mac Office.

Aldus:
        Pagemaker, software for designing and producing
typeset-quality
        copy using the LaserWriter.

ALP Systems:
        Educational software - a networked writing lab for colleges
        and universities.

Banyan Systems:
        A network server that lets Mac users communicate with IBM PC's
        using Appletalk.

Centram Systems West Inc:
        Interface cards and software that let Macintoshes and PCs
        communicate over Appletalk.

Fortune Systems:
        Fortalk, an Appletalk interface for Macintoshes and Fortune
        computers.

Hayes Microcomputer Products:
        Communications products for Appletalk.

Healthcare Communications:
        Dental Mac, multiuser office software that supports Appletalk.

Infosphere Inc:
        Expansion devices for Appletalk

Iomega:
        20 Meg hard disk storage system with a 10-megabyte removable
        hard disk pack. [Bernoulli Box]

Lutzky-Baird Associates:
        Ultra Talk, an Appletalk/Unix file server and electronic mail
        system.

Megahaus:
        Megaform, a software report and report generator with
spreadsheet,
        graphics, and database.

Micro Design:
        The Keeper, a hard disk/file server for Appletalk.

Novell Inc:
        Netware and Macfile Server, networking products for the
Macintosh.

Paramis Corp:
        An interface card and software that allow an Apple IIe or II+
        to act as file or printer servers for Macintoshes and Apple
IIs.

Sunol Sytems:
        Sun Mac, a hard disk drive for Appletalk.

3Com:
        An Ethernet interface for Appletalk.

Tridata:
        Netway 1500, connects Appletalk to mainframes.

Videx:
        Mail Center, an information transfer program for use on
Appletalk.

WOS Data Systems Inc:
        Wosbase, a multiuser database.

Zilog:
        System 8000, allows the Zilog 8000 family of Unix supermicros
to
        act as hosts to the Appletalk network.


                        nivek

Arpanet:  nivek@cmu-ri-rover Bell:  (412) 578-8830 USmail:  Robotics
Institute CMU
          Schenley Park
          Pgh, PA 15213

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

Subject: 512K upgrade by Centa
Date: 08 Mar 85 17:24:20 EST (Fri)
From: Steven B. Munson <sbm@Purdue.ARPA>

     I just read in the MACazine (what a tacky name) that some company
called Centa Systems, Inc. is doing 512K upgrades for $350.  The ad 
doesn't say much that is useful (like most ads), but it says that a 
RamDisk is included (looks like the one by Assimilation, Inc. that 
allows you to configure a disk size from 35K to 316K and will 
automatically create the RamDisk and copy whatever files you want to
it at boot time), the work is covered by a 90-day warranty, and it
seems to imply that they actually replace the chips on the board you
give them, rather than just swapping boards.  Does anyone know
anything more about this process or Centa Systems?  I have never heard
of the company before, so any clues to their reliability would be
helpful.

     Along the same lines, I can't remember the price of the upgrade 
offered by MassTech or their address, but I do remember that the only 
reports I heard about it were good ones.  Could someone send me this 
information (via mail) please?  Of course, these days, the 512K
upgrade seems to be passe.  MACazine says that "a major developer of
peripheral hardware" is rumored to be developing a 2 Megabyte Mac, to
be released possibly as soon as this summer.  Apparently, 1 Mbit chips
are soon to go into commercial production, which would make 2Mbyte
upgrades even easier (no piggy-backed boards).  Of course, we know
that a 1MB upgrade is available now from MicroGraphic Images for
$1595, but that is outrageous, when the price of a 512K upgrade is
$350.

     For those who didn't know about one or more of these companies, 
the addresses follow.  I have no association with any of them.

                                        Steve Munson
                                        sbm@purdue.ARPA

Centa Systems, Inc.  5308 Derry Ave., Suite C Agoura Hills CA 91301 
(818) 889-6246

Assimilation, Inc.  20833 Stevens Creek Blvd.  Cupertino CA 95014 
(408) 446-0797 {The list price of Mac Memory Disk (TM) is $29}

MicroGraphic Images Corporation 19612 Kingsbury St.  Chatsworth CA
91311 (818) 368-3482

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

Date: Thu 14 Mar 85 13:45:36-CST
From: Werner Uhrig  <CMP.WERNER@UTEXAS-20.ARPA>
Subject: Q: upgrade with 1-Meg-chips

I'm ready to discuss this topic. However, you can only do that (so I
am told) if you have the "newer modell" board.  Factory 512's have it,
and recent 128s also.  I don't know what the cut-off date or
modell-number was, since which the 128s have the 512-boards also, does
someone else?  You can tell by looking at the inscription on the
board, it says "128k 512k" somewhere.  Also, if you look at the
upgrade instruction in DDJ of Jan85, there is a picture in the
addendum on page 4 which shows the "critical" section of the board, 
the location for the multiplexor on the board.  The old 128's didn't
have that but you needed to piggyback the multiplexor.  Which is
exactly what you have to do again to go to 2Megabytes.  Also, I
believe that the 1Meg-chips have more than 16 pins, so the upgrade
should get a bit trickier than the 256-one, maybe someone more
knowlegable could speculate on this some more?

The 1Meg-chips are hard to come by still, and expensive due to low
yield and demand by the "guys with the money" (if you know whom I
mean).  $100 per, I believe it to be.

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

Date: Fri 15 Mar 85 02:41:03-CST
From: Werner Uhrig  <CMP.WERNER@UTEXAS-20.ARPA>
Subject: Address and phone-number of Microprocessors Unlimited

[ When I forwarded the message back, Werner, I did not keep myself a
copy.
  As I recall, you commented about Micro's low price and one day turn
around
  on orders. -jma ]

I had posted it twice already during the last month, I believe, so I
tried to keep it short.  But here it is again. (They always advertise
in BYTE)

        Microprocessors Unlimited
        24000 South Peoria Av.
        Beggs, OK, 74421
        (918)267-4961

also, not to forget, I don't like to post complete advertisement, lest
I get into troubles ....

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

From: Bruce_Jolliffe%UBC.MAILNET%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Date: Fri, 8 Mar 85 12:52:40 EST
Subject: Details of Binhex 4.0 HQX Format Wanted

Could someone give me the algorithm used to encode MAC files with 
Binhex 4.0. I'd like to be able to decode the files on a computer 
other than the Mac.

               -- Bruce

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

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