info-mac@uw-beaver (05/29/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Monday, 27 May 1985 Volume 3 : Issue 1
Today's Topics:
Re: Imagewriter compatibility
Re: Laserwriter fonts
Re: Application signatures
Yet more on ROM upgrade problems
System/Finder upgrade program problems
MacWrite 4.5 bug
Appletalk vs Thunderscan
Symbol font/LaserWriter question
Programs Plus
TopExpress reply to MacBCPL review
----------------------------------------------------------------------
From: John Mark Agosta <info-mac-request>
Subject: New volume number
Note that I have incremented the volume number, since we ran the dump
tapes this weekend.
------------------------------
Date: Sun, 26 May 85 13:33 EDT
From: Hess@MIT-MULTICS.ARPA
Subject: Imagewriter compatibility
The closest printer to the Imagewriter is the C.Itoh 8510A (or B)
(same as the Leading Edge Prowriter). And even IT isn't the same.
NEC8023 is second closest, but not near enough to do microspacing and
microfeeding at all. (The Prowriter obeys the same commands, but has
different resolution and font widths in PS mode.)
Brian
Subject: Laserwriter fonts
The Laserwriter has a not sign and a proportional sign built into its
internal symbol font. Adobe manual says not is at 'X'+128, and prop.
is at '5'+128. On the Macintosh, only the prop. is in the Symbol
font, and it is on Option-lowercase-m. The not-sign is in the Courier
font, on Option-lowercase-l. You should get the fancy keycaps desk
accessory which lets you view the keys in any font; it's a big help.
Brian
Subject: Truth in advertising
I bought stuff from LogicSoft and got what they said, $10 less than
the other ad's price. I can definitely understand why they weren't
interested in selling you twenty-dollar items with ten dollars off
each; it was intended to make cheap software prices on big-ticket
items where the mark-up will cover them. However, I agree that the
salesperson's response was rotten. And they probably won't keep up
their policy because Mac Connection has the hardest push for low
prices I've seen. LogicSoft won't beat them.
Brian
Subject: Application signatures (if nobody else responds)
You (or somebody else on this list) can find something written up on
it in one of the issues of "Outside Macintosh" which Apple publishes.
(It's not in the February or March ones, but I'm sure I saw an
article...)
Brian
------------------------------
From: crash!bwebster@SDCSVAX.ARPA
Date: Mon, 27 May 85 14:10:20 PDT
Subject: Yet more on ROM upgrade problems
I know this is getting a tad old, but I needed to pass along two more
confirmations that I've had concerning Apple's policy on the upcoming
ROM upgrade.
The first confirmation comes from someone [who shall remain nameless]
at one of the consortium universities. "Professor X" was in a meeting
with Martin Haeberli, Apple's rep (tho' I don't know if he's the only
one) to the consortium. Haeberli was specifically asked about the
rumored hard- nosed policy towards Mac owners who had 3rd party/DIY
upgrades. Haeberli confirmed that not only were dealers being
instructed not to perform the ROM upgrade, but that the ROM would
*not*e made available to these Mac owners (contrary to what had been
said here on INFO-MAC). Also, the ROM upgrade also includes swapping
in a double-sided drive (for the internal one), giving you 800K, and
that the whole thing would cost less than the price of an external
drive. Btw, Hyperdrive owners need not worry...ap- parently the ROM
restriction will *not* apply to you.
The second confirmation comes from another unnamed source at an
unnamed company that develops Mac products. This source ["Y"] sent me
private net mail, chiding me for promoting "unfounded rumors". I sent
back a message stating just why I felt my "rumors" weren't unfounded.
"Y" must have checked with some Apple reps in the meantime, because I
got a reply back stating that I was, indeed, correct about Apple's
planned policy.
Where does this leave us? Well, I will probably wait until *after*
the ROM/disk upgrade comes out, get it, then get Levco's 2MB upgrade
(providing it works with the new ROM, etc.).On the other hand, I may
just forget the ROM/disk upgrade altogether.
One last note: I have seen the Amiga in action and have gone through
the technical manuals. I'm under non-disclosure, but I will say this:
the Amiga is far more of a hacker's machine than the Mac ever was. As
soon as I finish my current "BYTE Programming Project" on the Mac (a
go-playing program in C), I'm going to switch over to the Amiga, at
least for a while. Should be lots of fun.
..bruce..
Bruce Webster/BYTE Magazine
crash!bwebster@ucsd
{ihnp4, noscvax, sdcsvax}!crash!bwebster
[The above opinions are, of course, my own.]
[Hold your messages: yes, I know just how hard it is to get a program
to play a decent (or even indecent) game of go. Believe me, I know,
because I had to write one for a graduate AI class I took. The
program I'm writing will provide everything *but* the brains--the goal
is for you to take it and add those yourself. Then you can play your
programs against each other. The article should be out in October,
and I don't really plan on posting the finished program much before
then. bfw]
------------------------------
Date: Mon 27 May 85 21:34:09-PDT
From: Team 3 <TA235.TEAM3@SU-SIERRA.ARPA>
Subject: System/Finder upgrade program problems
I was in the process of upgrading all my system/finder files with the
system upgrade program distributed on the Apple software upgrade
disks, when I discovered 4 disks the program not only failed to
upgrade, but actually destroyed. System update seemed to work fine on
all my copy protected software except: Musicworks, Smoothtalker,
TK!Solver, and Overvue. Overvue was recoverable by replacing the
finder (with version 4.1), and Musicworks and TK!Solver would work if
another system was used for startup, but Smoothtalker was obliterated.
Has anyone else had this problem (i.e., is it just me and my disks)?
Also, is there anyway to know in advance if system update will work?
(Note: I was updating my backup copies [made with CopyMacII].)
I'd appreciate any available information. Elliot@SU-STAR.ARPA
------------------------------
Date: Sun, 26 May 85 13:10:26 EDT
From: mazur@harvard.ARPA (Eric Mazur)
Subject: MacWrite 4.5 bug
The first time I used MW4.5 a little while ago I noticed a horrible
bug, that I thought would be noticed and reported immediately. A few
weeks have gone by and I haven't seen any report yet, so here I go:
Open MacWrite, type a few letters (just a few, say one or two) and now
try to backspace: doesn't work! If you hit return first and then start
typing, the backspace key works. The same thing happens after a ruler
insertion. Are we not allowed to make any typing errors in the first
paragraph after a ruler? Or am I doing something wrong?
Eric Mazur Harvard University
ARPA-NET: mazur@harvard.arpa BITNET: MAZUR@HARVUNXH.BITNET UUCP:
{seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!mazur
------------------------------
Date: 28 May 1985 08:12-EST
From: mss%dartvax%dartmouth.csnet@csnet-relay.arpa
Subject: Appletalk vs Thunderscan
We just got a Thunderscan. According to a brief note in the package,
Thunderscan has difficulties on a Macintosh which has been used on
Appletalk. Apparently Appletalk leaves some information in nonvolatile
memory (I guess the parameter ram/clock chip) which Thunderscan relies
on in some way. The suggested "work around" is to turn off the
Macintosh, remove the battery for the clock, wait thirty seconds for
the charges to trickle away and then put everything back together.
Although Thunderscan claims to be coming out (in a couple of months)
with a version of their software which will interact properly with
Appletalk, I thought an easy patch in the mean time would be to write
a program that flips those magic bits to something benign -- it
appeals to me more than taking the battery out of machine. A quick
call to Thunderscan (supposedly a technical support person) revealed
no information: all he knew was that there was a problem with the
interactions between Appletalk and Thunderscan but he had no idea what
a parameter ram was nor what could be stored there. My suspicion is
that some of the "reserved for future use" bits have been used, but
rather than performing experiments, I'm asking if someone else has
already solved the problem (or at least knows the technical info that
I need to write the program).
-Mark (mss%dartmouth@CSNet-Relay)
------------------------------
Date: Tue 28 May 85 16:00:35-PDT
From: Barry Eynon <EYNON@SU-SCORE.ARPA>
Subject: Symbol font/LaserWriter question
I've got a large technical paper I've been preparing on the Mac, using
WORD. Being a statistician, I've got the usual x-bars, etc. running
around in it. I've been using the Princeton math font to do my
symbols, which works fine on the Imagewriter. However, I'd like to do
my final version on the LW, if at all possible. I got my first chance
to print off a version today, and I used t "automatic conversion"
feature to convert the 10-point Geneva the paper is written in to
Helvetica, and since I had installed the Princeton fonts in the Laser
System, I figured they might not look quite as nice, but should be
fine for just the technical stuff.
Hoever, I was shocked to find that the Princeton characters come out
to be only about 2/3 the size of the Helvetica characters (both at 10
point) on the LW (it looks so good, otherwise...). So I've been
thinking of going through and changing all the technical symbols to
the LW Symbol Font, which I'm not enthusiastic about, to begin with.
But what's got me in a quandry at the moment is I can't figure out how
to put bars and hats over characters in Symbol. Has anyone else
figured out how to do this, or have any suggestions on solutions to
doing real math text on the Mac with the LW right now (eventually
someone's got to convert TeX - it's a natural matchup). Any help would
be appreciated.
-Barry Eynon EYNON@SCORE
------------------------------
Date: Sun, 26 May 85 17:08:50 EST
From: Stephen C. Hill <STEVEH@MIT-MC>
Subject: Programs Plus
I wish to report on my dealings with Programs Plus, 429 Honeyspot
(sic) Rd., Stratford, Conn. 06497, (800) 832-3201. I have ordered
several hundred dollars of assorted Hardware and software from them
and have been mostly pleased with their responsiveness. The only
thing that I can fault them on, is the order that contained
MacPublisher and Thunderscan amongst other items. I was paying via
credit card, and while they DID say that those two items were out of
stock and I would get them as they received them, when I received the
first part of my shipment, I noticed that I had been billed for the
entire amount. I received the back-ordered items within two weeks, so
I didn't get too upset, however when they called to say that another
item that I was interested in had arrived (and did I want to buy it?),
I expressed my feelings about the billing for unshipped product issue.
The lady said that that was not their policy, but things sometimes
slip.
All in all, I am very pleased with both the prices and delivery from
Programs Plus, and I only mention the above as a caution to be alert
for.
------------------------------
Date: 22 May 85 20:51:41 EDT
From: Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>
Subject: TopExpress reply to MacBCPL review
I have finally received the reply from Topexpress Limited
regarding my review of MacBCPL. The text of their reply in its
entirety follows --- please store it AFTER the review itself. One
item of importance mentioned in the letter is that "bona-fide software
developers and educational institutions" who read my review may buy
MacBCPL directly from Topexpress for only $100.00 (US) dollars rather
than $175.00.
[I have no ties whatsoever with Topexpress and have nothing to benefit
if people do or do not buy MacBCPL.]
Jeff
uucp: ...{harvard, seismo, ut-sally, sri-iu,
ihnp4!packard}!topaz!shulman arpa: SHULMAN@RUTGERS
[ This reply is stored in News-BcplReply.txt -jma ]
TOPEXPRESS LIMITED
Scientific and Computer Consultants
13/14 Round Church Street
Cambridge CB5 8AD
England
Telephone Cambridge (0223) 355427
14-May-85
To: Jeffrey S. Shulman
Dear Mr Shulman,
Thank you for your comprehensive review of MacBCPL. You made some
very good points, some of which I will deal with in more detail later.
Our main aim was to produce a system which could be used for serious
software development on a 128K MAC, with no hard disc attached - we
did not want to force people to use a Lisa or even a 512K Mac. For
this reason, we had to restrain ourselves slightly in the facilities
that we included in the compiler and library, for fear of using too
much store or disc space. We also thought it important that the
system be available quickly - there are too many products advertised
which will be available 'real soon now'!
Perhaps I can deal with some of your specific points:
The problem with floating point is that the documentation available at
the time seemed very poor. Since then we have studied it carefully
and have produced a set of trap declarations which give full access to
the 'SANE' routines in the two Mac packages. We will publish these
traps in our first BCPL user's newsletter.
Segmenting a BCPL program into separately loadable pieces is possible
if suitable 'glue' code is used to bind them together (this is
necessary because special action is required when BCPL code is loaded
- initialising global vector entries for example). I have now written
a simple 'gluepot' program which you can use to produce this special
code. We will include a listing of the program in the newsletter.
You can't use VEC declarations in BCPL to allocate variable amounts of
store (as in Pascal, the size must be a constant). Therefore it is
always necessary to use 'getvec'/'freevec' calls for serious store
allocation.
Ideally, we should have produced header declarations for every Mac
data structure; unfortunately, this would not have solved all
problems, since some knowledge as to formats are still required by the
user. For example, you can't use field selectors to access structures
allocated by the Mac itself, because they may not be aligned on a
four-byte boundary (necessary for BCPL!). We felt that it is rarely
necessary to extract fields from the more complicated structures (one
can use routines like 'GetWRefCon', for example), and so one can
declare structure offsets as necessary. I agree that we should have
included at least a printed list of all the useful byte offsets in Mac
structures; this will appear in the newsletter.
Altering the compiler so that the Toolbox registers need not be
specified is certainly something that we could do (you may have
noticed that there is a spare bit in the trap table format which could
be used to indicate a 'register' call). This was one of the changes
that we rejected eventually to keep the compiler down in size, as we
felt that register based calls are relatively rare. We may however
change our minds about this and include the facility in the next
release of the compiler.
We thought a lot about how the compiler is started off; the trouble
with using a double-click in the file name is that one cannot then
select some of the other file options (object file, etc) - I didn't
want to risk calling the standard file package from within itself.
Location of lines by number is a real problem on the Mac; we were most
reluctant to write a whole new editor (the Apple one is really quite
good), but also couldn't think of any better way of showing you where
the error occurred.
The linker and RMaker documentation we had from Apple was very sparse.
We felt that users might prefer to get more up-to-date versions from
Apple, rather than relying on the little information that we could
supply. When we publish our segmentation/overlaying mechanism for
BCPL, we will include more linker information.
Apple (UK) distribute the assembler development system free to
registered software developers, so we felt that users could easily
acquire the latest versions of the assembler and RMaker from them.
One can in fact include small amounts of inline code by writing hex
procedure calls [eg. LX4E71() would compile to a NOP instruction] but
this facility is obviously for experts only, and we thought it wiser
not to mention it in the manual. It is also rarely necessary to use
assembler routines with BCPL, since the language gives you such
low-level access to the machine.
Apple supply good low-level debuggers in the assembler development
system and on the MACSTUFF discs, so we did not feel it necessary to
develop a new one ourselves. Perhaps we should have given some hints
as to their use with BCPL - this is something worth including in our
newsletter.
We will look at our US pricing policy in the light of your comments,
but meanwhile for bona-fide software developers and educational
institutions we will charge only $100 as a special offer to readers of
this review who purchase direct from us. Perhaps you could help us
publicize this.
When we produce the next release of the system, existing users will be
given the opportunity of upgrading for a nominal fee.
I hope that this has clarified some of your points,
Yours sincerely,
Dr Richard Evans
------------------------------
End of INFO-MAC Digest
**********************