SHULMAN@RED.RUTGERS.EDU (Jeffrey Shulman) (09/05/86)
Delphi Mac Digest Thursday, 4 September 1986 Volume 2 : Issue 42
Today's Topics:
Floating Point with Aztec C (5 messages)
trap dispatch
RE: Extensible Desk Accessories (Re: Msg 357)
RE: a debugging aid (Re: Msg 671) (2 messages)
RE: Hard Disk Drive Reliability (Re: Msg 12260) (4 messages)
Keyboard Fun (3 messages)
RE: Using Acta Runner for other (useful) purposes
RE: FLIPPING PIG MODE ON
A gem by any other name...
RE: Which 20 Meg?? (Re: Msg 12311) (4 messages)
HyperDrive failures
Advanced Logic Systems - Word Handler
MacAuthor
Using Mac to communicate with deaf
DataFrame Print Spooler (Beta 1.2) Probl (3 messages)
DeskTop Publishing Expo
TScan blues
-----------------------------------------------------------------------
From: SOLARPULSE (670)
Subject: Floating Point with Aztec C
Date: 28-AUG 20:02 Developers' Corner
Has anyone done any detailed work with the floating point package? I
have just hit a wall with Aztec C. It seems that some (the few
routines I've looked at) of Aztec's floating routines like sin(), etc.
do a translation from some internal format for a double to the Mac's
(SANE) extended precision. The use an undocumented move.d command to
do this. The first problem is that what ever that move.d is doing it
is taking a lot of time to do it. In some worst case situations > 10
milliseconds! The end result is that the Mac evaluates a sin function
about as fast as the Apple II +, about 60 or so a second. This is
very poor. MS Fortran (Absoft) is about 10 to 20 times faster.
Second gripe is that not all the floating point functions done by
Aztec call the Mac SANE routines. Yes, so the SANE routines are slow,
not as slow as Aztec's implementation, and at least they are correct.
I have found, in my limited testing so far, that at least the pow
function is wrong. I wonder how many more functions are screwed.
Unfortunately, this type of thing undermines the confidence one must
have in his/her compiler.
As I work mainly with floating point numbers I need a good C
compiler th at does things correctly. After finding that Megamax can
not even write out floating point numbers correctly I turned to the
only other product availa at the time. Will many new C compilers are
available. Can anyone recommend a solid C compiler that does not fall
down doing Floating Point calculations?
Ah, I feel better have gotten that off my chest. Thanks for listening.
David.
------------------------------
From: PEABO (674)
Subject: RE: Floating Point with Aztec C (Re: Msg 670)
Date: 29-AUG 14:10 Developers' Corner
At present the best C compiler for floating point is Mac C from
Consulair. It supports the 80-bit format directly (I don't know for
sure whether that is the default for double or if there is a "long
double", but others who read Forum would know). Mac C also has an
option in its most recent version to emit code directly for the 68881
chip, which will be important to you if you want to write calculation
intensive code for the Prodigy 4.
LightspeedC also supports 80-bit floating point, and uses "short
double" for 64- bit format. There are other advantages to LightspeedC
that may sway your decision.
peter
------------------------------
From: DWB (686)
Subject: RE: Floating Point with Aztec C (Re: Msg 674)
Date: 31-AUG 06:52 Developers' Corner
Mac C has two added classes. 'extended' which is an 80 bit floating point
number (all float operations are performed using extended numbers instead of
doubles) and 'comp' which is a "floating integer... maximum integer is now
9,223,372,036,854,775,807." What they mean by a "floating integer" I can't
imagine.
David
------------------------------
From: MACLAIRD (673)
Subject: RE: Paranoia Vindicated (Re: Msg 573)
Date: 29-AUG 06:13 Programming Techniques
As I think about this problem right now, it does seem odd because the 68000 has
only 24 bits on its data bus. However,
Check the generated code to see if it's d(PC) or d(A*) and what the related
register's address is.
On the other hand, the PC might get nailed by an address register. The 68000
does have 32-bit internal data paths, and address arithmetic does have uses
above and beyond address calculation. For instance, I seem to remember Bill
Atkinson's bragging about using the Address Registers to save remainders in
SANE.
All in all, it's not easy to see how putting the master pointer's flag
byte into an address register should cause memory wrapping _outside_
the 68000, because the understanding I had was there just weren't pins
to carry those values to the address decoder/memory.
_Laird
------------------------------
From: PEABO (679)
Subject: RE: Need help with LightSpeed C (Part I) (Re: Msg 675)
Date: 30-AUG 18:38 Programming Techniques
If you like using "int" instead of "short" or "long" you'll want to pay
attention to the compiler's integer preference. Aztec is short, Mac C is long,
MPW C is long, LightspeedC is short.
Me, I avoid "int" whenever possible.
peter
P.S.: Jeff tells me that Megamax thinks "short" is "signed character". That's
not just dumb, it's close to being boneheaded and wrong.
------------------------------
From: SOLARPULSE (676)
Subject: trap dispatch
Date: 30-AUG 11:05 Developers' Corner
I am trying to call some SANE routines directly by interfacing
assembly langauge to C (Aztec). DOes anyone have a simple example
demonstrating use of a trap dispatch to FP68K, i.e. replacing the
JSRFP in INSIDE MAC. David.
------------------------------
From: DDUNHAM (681)
Subject: RE: Extensible Desk Accessories (Re: Msg 357)
Date: 30-AUG 18:45 Current Discussions
I stayed up until about 06:30 writing the first DIec, and fixing the bug where
Delete gets confused when there are multiple long names. I determined that the
calling sequence needs to be changed to
pascal word ExtensionProc(volume,name,d_rsrc, e_rsrc)
int volume; char name[64]; int d_rsrc, e_rsrc;
where the value returned is TRUE if the file list needs to be changed (i.e. a
delete or rename) and FALSE if not (i.e. Get Info a la Finder).
Let me know what the demand is. DiskInfo still needs some cleaning up, but I
can upload the source code to the GetInfo DIec as soon as someone needs it.
I'm thinking the easiest way to handle DiskInfo expandability is for
DiskInfo to open a "DiskInfo File" in the system folder. This could
contain the resources needed for the extension (i.e. DIec, DIem, and
STR#, and whatever else you need). There would still be a problem
with extensions from several people, but I think it would be simpler
than trying to get everything in a suitcase file. Certainly simpler
for the end user.
------------------------------
From: DDUNHAM (682)
Subject: RE: a debugging aid (Re: Msg 671)
Date: 30-AUG 18:45 Programming Techniques
Hmm, Delphi trashed my original posting.
I've found that it helps my debugging to label routines so TMON's disassembly
can identify them. I do this by including
#asm
dc.b "CLOSE_WI" ; spend 8 bytes to help ID
#endasm
after the final } of a routine. However, Aztec C puts the RTS after the first
return statement, not at the end of the function, so you can't always do this.
Nevertheless, it's certainly a pleasure to look at a TMON disassembly and be
able to see real stuff.
Oh, I only do this when I have a good idea what routine(s) I'm debugging. Also,
this might not be necessary when you're debugging an APPL; I never have figured
out how to get TMON to use a .map file for a desk accessory (with (A4) global
offsets instead of (A5)).
------------------------------
From: JIMH (683)
Subject: RE: a debugging aid (Re: Msg 682)
Date: 30-AUG 22:10 Programming Techniques
Speaking of TMON, anybody besides me ever get tired of reaching around
back for the interupt switch? I used resedit to open an fkey in my
system file and typed int he debugger trap. close and save, and you
have instant fkey to call tmon, or any oth er debugger. I got the
idea from a BMug article to shutdown. anyway its crude as it doesnt
check to see if there is a debugger, anyone know how to do that? but
it works well if you want to bop into tmon to setup a trap intercept
or to look at a me mory location ect. you still need the interupt
switch if you arnet in an event loop. jim
------------------------------
From: BRECHER (12338)
Subject: RE: Hard Disk Drive Reliability (Re: Msg 12260)
Date: 3-SEP-00:01: Mousing Around
Some of the software supplied with the various hard disks is
hardware-specific, such as driver installers/formatters/volume
managers. Other items are hardware- independent (or *could* be), such
as backup programs, print spoolers, and file encryption programs --
actually, multi-volume or partitioning schemes can fall in this
category too, e.g., MacServe and a new utility from FWB (the makers of
Hard Disk Util).
The HyperDrive Manager would be hardware-specific. The GCC Backup
program can be used to restore from floppy to other hard disks -- I
used it to transfer data from my HyperDrive to my MicahDrive when I
switched over earlier this year.
------------------------------
From: BRECHER (12339)
Subject: RE: Hard Disk Drive Reliability (Re: Msg 12264)
Date: 3-SEP-00:02: Mousing Around
Not sure what you mean -- the apparent speed of one drive relative to
another is a result solely of how fast it can get to the blocks and
transfer them.
------------------------------
From: FRACTAL (12378)
Subject: RE: Hard Disk Drive Reliability (Re: Msg 12222)
Date: 3-SEP-22:31: Mousing Around
My experience with a large variety of disks is that unless the
transfer rate performance is quite bad (the controller only transfers
1 or 2 sectors per rev during multi-block transfers => DiskBench over
2000 on read or write), the seek speed of the drive generally
determines the subjective performance of the drive to the mac user. I
know that a Seagate ST 225 (in my Dataframe 20) running at 2 to 1
interleave is subjectively slower than my Atasi 3046 when it was
running at 3 to 1 interleave, even though the data transfer speed was
50% slower for large blocks. The average seek time on the Atasi is
30ms, the ST 225 is 85ms; that is the statistic that really matters.
Unfortunately you have to pay relatively big bucks to get faster
seeking drives, and the cheapest ones are 'full height' 5 1/4 inch
drives that no Mac drive makers are using because they are bigger.
(Though one would probably fit in the huge box that Hyperdrive puts
their ST 225N into).
Tom
------------------------------
From: DWB (12391)
Subject: RE: Hard Disk Drive Reliability (Re: Msg 12378)
Date: 4-SEP-02:08: Mousing Around
It's a combination of how fast and how timely it can get them there. Getting a
block of data to the machine a half second before the machine is ready for it
doesn't help anything. Obviously, this is most important with machines that
support DMA I/O or with software which uses ASYNC transfers, if there is any of
it out there.
A quiet drive can also seem faster than a noisy drive, strictly
because you don't hear all the work it has to do to get the data. It
may not be any faster, it just seems like it is.
Also, as pointed out by Tom, the seek time has an awful lot to do with hwo fast
a drive is, probably more so than the transfer rate.
David
------------------------------
From: MOUSEKETEER (12340)
Subject: Keyboard Fun
Date: 3-SEP-00:05: Hardware & Peripherals
Semi-interesting Hardware Story...
This evening I decided to rearrange the shelves in the Mousehole. A loose
bracket, though, sent a 15 pound CD player crashing to my desk. Luckily, my
Mac keyboard broke itUs fall. (Right!) Inspection revealed three keys of the
keypad in bits and pieces. The right side of the keypad didnUt work, along
with [, ] , p and z. Opening the case, I found a crack on the far right side
of the keyboard breaking 7 traces. I figured I could jumper the traces, but
three of the keys under mechanisms were in shatters. Oh well....
However, in cleaning, I had run across my old Mac Keypad, the one that
doesn't work with the new ROMs. Luckily enough, the key mechanisms were
identical. 45 minutes with a soldering iron and my Mac Plus keyboard is
working just fine, even if the blue wire under the board looks kinda funny.
MORAL: Even obsolete Mac Keypads can be useful!
Alf
------------------------------
From: LAMG (12342)
Subject: RE: Keyboard Fun (Re: Msg 12340)
Date: 3-SEP-01:58: Hardware & Peripherals
Alf: Yes, but how's the CD player doing? -Franklin
------------------------------
From: MOUSEKETEER (12343)
Subject: RE: Keyboard Fun (Re: Msg 12342)
Date: 3-SEP-02:11: Hardware & Peripherals
Oh, the CD player? Just fine. It's an old pro at being dropped, and it has
never seemed to mind. Which is good, since I don't have any old obsolete CD
players to scavenge parts for it from.
;-)
Alf
------------------------------
From: DDUNHAM (12345)
Subject: RE: Using Acta Runner for other (useful) purposes
Date: 3-SEP-03:34: Network Digests
> From: <INFOEARN%HLERUL5.BITNET@WISCVM.WISC.EDU>
> Subject: Using Acta Runner for other (useful) purposes
Thomas, you've discovered the bad and (apparently in your case, good) points of
installing DAs in applications. Namely, resource conflicts. What the Runner
does is look for the configuration resource (type ACTA) and then does an
OpenDeskAcc() on the DRVR that owns the ACTA resource. In the normal scheme of
things, the application is searched before the System, so it ends up opening
DRVR 12 from the application (MacDialer) instead of DRVR 12 from the System (
Acta).
On the down side, I suspect that if you run Acta from within MacDialer Runner,
you may get to see some spectacular crashes, since it'll pick up MacDialer
resources instead of its own.
If the "suitcase file" for MacDialer has no resources except the DRVR,
or happens to have none with the same type and ID as Acta, you're
safe. This is very unlikely. I've received other comments from
people who installed DAs into applications and then found that Acta
won't work in that application. I could prevent resource conflicts,
but it'd make Acta bigger (and slower), so I'll just say that I can't
support users who do what you do.
I think what you want is something like the FKEY-DA Sampler (which is
ChocolateWare).
------------------------------
From: DDUNHAM (12344)
Subject: RE: FLIPPING PIG MODE ON
Date: 3-SEP-03:34: Network Digests
> From: jonathan@mitre.ARPA (Jonathan Leblang)
> when I hold down shift-option-command and do ABOUT RESEDIT... I get a box
> that says 'FLIPPING PIG MODE ON' and if done again, the mode will turn off.
Pig Mode is for debugging; it's apparently like TMON's heap scramble.
------------------------------
From: DDUNHAM (12346)
Subject: A gem by any other name...
Date: 3-SEP-03:35: Mousing Around
Notice that, according to the 1 Sep InfoWorld, Xerox's Ventura
Publisher Edition "runs in the Graphics Environment Manager?"
Apparently they don't want any possible confusion with GEM, which runs
on the Atari ST :-)
------------------------------
From: JCROSS (12350)
Subject: RE: Which 20 Meg?? (Re: Msg 12311)
Date: 3-SEP-13:23: Hardware & Peripherals
I'm using a Hyper20, Apple HD20 and DataFrame. DataFrame is best by
far. Has never crashed. Very sound, reliable product. Good value to
at 8-900 dollars. The Hyper has been relaced 5 times (in 9 months).
The Apple is OK, but slow and kludgy compaired to the DataFrame. Hope
this helps.
------------------------------
From: MACINTOUCH (12355)
Subject: RE: Which 20 Meg?? (Re: Msg 12350)
Date: 3-SEP-19:19: Hardware & Peripherals
Rob,
BMUG has found the Apple HD20 to be extrodinarily reliable. I like the fact
that it works with both a Mac Plus and a Mac 512K, and doesn't take up either
of the serial ports. I personally don't think performance is a real factor.
I've lost much more time to hardware failures than I ever gained by having
the highest speed disk (HyperDrive). The DataFrame does seem to be quite
reliable, too, and SuperMac has demonstrated unusually good support, with
a 1-year guarantee.
I highly recommend getting HFS Backup from PCPC, no matter what hard disk
you're using. It has saved us countless times, and so far I haven't seen
a better utility. (1-800-MAC-BUTT)
Ric Ford
------------------------------
From: MADMACS (12358)
Subject: RE: Which 20 Meg?? (Re: Msg 12311)
Date: 3-SEP-20:09: Hardware & Peripherals
Get a DataFrame! It compares well on speed and it is very reliable. - Doug
------------------------------
From: MOUSEKETEER (12368)
Subject: RE: Which 20 Meg?? (Re: Msg 12358)
Date: 3-SEP-21:10: Hardware & Peripherals
I've been using an HD 20 for 10 months and a Dataframe for 30 days. I know
there is supposed to be a real speed advantage to the Dataframe, but I've never
really noticed it. For my money, the big question is reliability. While I've
managed to do some pretty flashy crashes with beta software, the HD20 has never
been a hassle, beyond a save with HFS Backup, reint and restore. To date I'm
fairly (and naively) convinced that what I put on it will be there later.
I had the same outlook toward my dataframe until Monday, when it did some silly
noises and refused to open a file three times. On the fourth time, it just
sat flashing it's little red LED for 10 minutes. I then turned the whole
system off and rebooted, upon which all worked normally. If I had a really
important file and could only put it on one of the drives, it'd be on the
HD20.
Then again, I wouldn't buy an HD20 now...surely Apple has a SCSI up their
sleeves, no?
Alf
------------------------------
From: MACINTOUCH (12356)
Subject: HyperDrive failures
Date: 3-SEP-19:23: Hardware & Peripherals
There's nothing quite like being all set up on a hard disk and having it break.
Getting converted to floppies can be a real chore, even with 2 800K drives and
HFS Backup.
I've had my second HyperDrive failure in less than a year. This time, it
failed without warning, and was unrecoverable. It was the hard disk itself,
made by MiniScribe. My technician tells me he's seeing a rash of problems
with the MiniScribe. Although it's not GCC's fault (they just buy the thing,
they don't make it), I'm rather uncomfortable about HyperDrive reliability.
The FX20, the new external drive from GCC, would probably be more reliable.
It uses a Seagate drive (says my friendly technician) and I suspect robustness
was higher on the priority list this time around.
Ric Ford
------------------------------
From: MOUSEKETEER (12376)
Subject: Advanced Logic Systems - Word Handler
Date: 3-SEP-22:17: Network Digests
Advanced Logic Systems - Word Handler
Curious and ever likely to stick my mousy nose into odd places, I called
ALS today and asked "why are you ripping off all these Mac users?" I was
routed to Maggie, "who knows why we charge so much for shipping/handling".
Maggie had to admit she didn't really know, but that they weren't trying to
make any money off returning MacWrite disks. In fact, they were only
charging for shipping, and throwing the handling in free. (I know this must
sound like one of my tall tales, but it's TRUE!). She said only VP Nathan
Scholnof knew why it was $25, but his wife was having a baby, so he wasn't
there this week. OH, "and you should know, sir, that $25 only covers us
sending back a disk with MacWrite on it...not a Master Disk of MacWrite...
if you want a Master Disk back it's $50." (I swear I'm NOT making this up!)
Next call, Macworld magazine. "Why are you helping ALS rip people off?" I
was routed to Patricia Navone, Northwest Advertising Manager. Pat has heard
a lot about ALS lately...she even knew Nathan's wife was having a baby! She
said that starting in the November issue, the ALS ad would be stating up
front that it would cost you $25 to get your MacWrite disk back, but agreed
that a "large red label reading 'WARNING: LARK'S VOMIT!'" would be more in
order (you have to be a Python freak to understand..). Further, since
ALS had been a bit "unclear" in its ad, she said they had agreed to return
MacWrite disks to users for only $15. I mentioned I had just talked to ALS,
who said it was $25, or $50 for a master disk back. Pat said I should talk
to Susan Connally at ALS, who they had made the arrangement with. She
also said Alfonso Qwerty was an odd name.
Back to ALS. "Hi, it's Alf again. I'm supposed to ask Susan Connally why
you are ripping off Mac users this time." Huddled noises in background...
I've obviously got them where I want them...grin. "Uh, Sue is away from her
desk. Let me get your number and she'll call back in 15 minutes." 15
minutes pass....RING! "Hi, is Ralph there? Oh. OK, here's the deal. If
the purchaser will send back a note requesting their MacWrite master disk,
a copy of their invoice showing it was purchased before this coming Oct. 15,
we'll only charge them $10 to get it back."
I still think it's something in the CA air, myself.
Alf
------------------------------
From: MOUSEKETEER (12377)
Subject: MacAuthor
Date: 3-SEP-22:20: Network Digests
To: CLAK100%BGUNOS.BITNET@WISCVM.WISC.EDU
Subject: MacAuthor
Reviews of MacAuthor are pretty scarce at present, but the MacTimes UK,
where the program has been used a bit recently printed a letter from a
user who complained "it runs at the speed of a one-legged tortoise" among
other not so nice comments. The writer was especially dismayed by the
lack of support for footnotes and the copy-protection used.
The editor noted that this letter was typical of comments they received
about the program. "When I last spoke to the people at Icon I was told
they had sold 4500 copies so there are either a lot of very disappointed
people out there or a lot of very satisfied ones who don't know any better."
Alf Qwerty
Delphi Anti-Sysop
JEFF: Do we get to put neat little quotes at the bottom of our messages?
"Tell me where a man gets his cornpone and I'll tell you what his
'pinions are." -- Puddinhead Wilson
------------------------------
From: TECHNISOLVE (12375)
Subject: Using Mac to communicate with deaf
Date: 3-SEP-22:02: Creative Pursuits
USING MAC TO COMMUNICATE WITH DEAF....
Does anyone know of a hardware interface which allows the Mac or any RS232
device imitate a TTY device. I have a friend who is deaf and uses a simple
TTY-like device to communicate. It generates several tones as each key is hit
and does not use a carrier as a modem would.
Your help is greatly appreciated.
Dave Gracon
------------------------------
From: MADMACS (12385)
Subject: DataFrame Print Spooler (Beta 1.2) Probl
Date: 4-SEP-00:40: Hardware & Peripherals
I am having trouble getting MacPaint and FullPaint files to spool to
the Beta 1.2 spooler from DataFrame. Their doc. claims that this
should work. The file spools ok but at soon as it becomes the file
being printed, my ImageWriter carriage moves, but is followed
imeadiately an ID=2 Bomb. MacWrite, MacDraw, and other files spool
just fine. The only thing wierd about my set-up is that I have added
extra DAs using RESEDIT by numbering their DRVR's 26 through 31 (to
get more in the system). In fact, the spooler wouldn't install until I
removed one of them. I observe using RESEDIT that Print Que's DRVR
resource is not a Desk Accessory, as such, but a "true" Driver. Is
this related to the problem??
Has anyone got the DF spooler working with MacPaint files?
- Doug (MADMACS)
------------------------------
From: MOUSEKETEER (12389)
Subject: RE: DataFrame Print Spooler (Beta 1.2) P (Re: Msg 12385)
Date: 4-SEP-01:07: Hardware & Peripherals
I don't really know how useful this information would be, but looking over
DotP's DA Installer+ docs, slots 27-31 are reserved for Device Drivers, and
having installed DA's there may be a problem. The only slots listed by DotP
as being usually safe to use are 39-47 (Undefined).
Alf
------------------------------
From: MACINTOUCH (12399)
Subject: RE: DataFrame Print Spooler (Beta 1.2) P (Re: Msg 12389)
Date: 4-SEP-16:00: Hardware & Peripherals
Doug,
I believe that FullPaint and MacPaint both use non-standard ways of printing,
bypassing the Printer Manager. I suspect this is the root of the problem.
SOLUTIONSINC has been dealing with this in their Glue package, so you may
want to drop a message to them.
Ric Ford
------------------------------
From: BMUG (12392)
Subject: DeskTop Publishing Expo
Date: 4-SEP-02:13: Hardware & Peripherals
I just got back from setting up the BMUG booth at the DESKTOP
PUBLISHING EXPO at the Embarcadero Hyatt Regency in San Francisco, and
I've got to report... the stuff there is HOT!
The expo opens tomorrow, and runs Thur-Fri 10-6, and Sat 10-4.
Admission is $25 (ouch!). The Desktop Publishing CONFERENCE, costing
$600, started today and runs through Saturday... that is where all the
BIGwigs are... but the EXPO is for the PEOPLE.
Apple is there in force... they'll be putting out a newsletter at the
show... actually creating it (PageMaker, etc.), typesetting it
(LinoType), making a plate and PRINTING it (Gestetner) right in their
booth! Over half the exhibiting companies connect with Macintosh in
some way. Some companies, Apple included, are scrounging for
equipment... even Apple Tradeshows can't get any macs for itself, as
all the stuff is off at the APPLE NATIONAL SALES CONFERENCE, going on
this week in BOCA RATON, FL (interesting coincidence, eh?). Mike
Macintosh (really! I saw his ID!) is event manager for Apple's
DeskTop Publishing division, and he greeted all us Apple developers
over a pizza & beer dinner... he works under John Scull (not to be
confused with someone else). (Actually, Mike claimed that he was a
prototype for Apple's next machine, and by shaking hands with him you
were applying your fingerprints to a non-disclosure' agreement
automatically.) Both Mike & John greeted us & then took off for the
sales meeting... but I'm getting off the subject.
Radius was there... I talked with MICHAEL BOICH, Pres. of Radius, and tried out
the new machine hands-on. They've fixed the font problem some people were
noticing at MW Expo, and it seems to be working PROPERLY with LOTS of software
now... dialogs are centered in the big screen, you can drag windows from one
screen to another... the image is crisp, clear, and readable. MacInTax was
particularly impressive, with the entire 1040 form visible at once. This will
certainly be one of the hits of the show.
Aldus has a big booth, probably to show off PageMaker for the PC. Noone from
Aldus was around for me to ask about PM 2.0 for the Mac.
We expect several PC page layout programs to be announced at the show, by Aldus
and others. However, our resident expert, Brian Hamlin of LaserWrite in Palo
Alto, expect that they will perform (speedwise) like dogs compared to Mac
software. Almost everybody has adopted a "wait-and-see" attitude (you know,
hand above eyes to shade them from the light, knees bent, peering into the
distance). We've got invitations to the press releases / parties of several
companies, so we'll report on these during the show.
Letraset is one company that will be holding a press conference at the
show... to announce that they have BOUGHT Boston Software Publishers
... and to announce "a major new desktop publishing program for the
Macintosh". Our analysts expect that the product will NOT be an
on-line Kroy letterign system.
Silicon Beach Software is previewing SuperPaint, expected to Ship on
October 16. It is a NICE program, combining the best of MacPaint,
FullPaint, and MacDraw. I especially liked:
> "LaserBits", 300 dpi bitmaps that you can edit onscreen and treat as
objects in your document. > "Layering" of object-oriented and bitmaps
on-screen > easy reverse text & shaded text, ON THE LASERWRITER > A nice
pallette & user interface.
They reportedly have 100 beta testers working on the program now.
They're alsow working on putting the finishing touches on "Dark
Castle" and some other adventure game.
FTL Systems is there with MacTEX ("Mac-Tech"), a Mac implementation of Donald
Knuth's TEX document layout system... I haven't seen it, but their flyer seemed
to promise the world.
BMUG is there, of course! We're the only user group there... we'll be showing
off the BMUG NL's (created in MacWrite & MacDraw), as well as signing up
members.
Adobe has a large booth, emphasizing the many printers that now support
PostScript(r). I've heard that they are selling something like 4300
LaserWriters a MONTH, but I'm not sure of my numbers. Incidentally, Adobe just
went public.
Ann Arbor Softworks is there... making excuses for why FullPaint was originally
copy-protected, a moot point now that they've removed their copy- protection.
They were yakking about the perception that MacPaint was freely distributable,
and dealers pressuring them to protect it, and so on. The guys at the Silicon
Beach Software booth were REFUSING to test-run an Abaton 300 dpi scanner loaned
to them for the show, because the software was protected, and the silicon beach
guy didn't want to put ANYTHING protected ANYWHERE near his machine. Oh yeah,
Silicon Press is now up to version 1.1... there were a couple of bug fixes.
In any case, I'll try to keep you updated whenever I get back to the show... I
saw a bunch of dealer order forms at tthe Radius booth, and some nice product
literature... but I'm not sure when/whether they're shipping. As some have
reported, it plugs in through the SECURITY CABLE connector on the Mac... WEIRD!
-- Raines Cohen
Ace Reporter, TEAM BMUG
------------------------------
From: DDUNHAM (12395)
Subject: TScan blues
Date: 4-SEP-05:09: Bugs & Features
Help! We borrowed a ThunderScan and now have a 328K map (it was
scanned at 400% resolution, and this file contains no grey map). Now
what do we do with it? It's too big to Copy, and PageMaker doesn't
read ThunderScan documents. Would Glue be able to capture a TScan
print, and create a clipboard that PageMaker could use?
------------------------------
End of Delphi Mac Digest
************************
-------