info-mac@uw-beaver (04/14/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Sunday, 14 Apr 1985 Volume 2 : Issue 29
Today's Topics:
info-mac filename changes
Bug in SUMACC runtime startoff for device drivers
recovering from tecmar hard disk crashes
C Compiler Benchmark Update
ProModem 1200 and ProCom-M (review)
MacDraw-to-Impress (Imagen) translator
Serial driver baud rates
Serial Tales
Anyone have Red Ryder 5?
----------------------------------------------------------------------
Date: Sat 13 Apr 85 09:54:11-PST
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: info-mac filename changes
You'll find a few info-mac files in new places in the directory.
MACKERMIT.SH has been moved to MC1KERMIT.SH, so that we keep the same
convention as Columbia, where the original is archived.
UNIX-MW2TROFF.DOC was originally mis-named. It belongs with the
MWXLATE series. These are now grouped togther as:
UNIX-MWPROF.SCRIPT UNIX-MWXLATE.C
.DOC
Please have a look at the file <info-mac>00DIR, where there is a new,
complete directory listing, and let me know if you see any other
confusions in <info-mac>
-jma
------------------------------
Return-Path: <WEINSTEIN@BBNG.ARPA> Date: 31 Mar 1985 20:10-EST
Subject: Bug in SUMACC runtime startoff for device drivers From:
WEINSTEIN@BBNG.ARPA To: info-mac@SUMEX-AIM.ARPA
The following obscure bug hits when using the SUMACC system to write
device drivers or desk accessories which are to be loaded onto the
system heap (instead of the application heap, as usual). Because the
SUMACC system re-uses register a5 for its own purposes, it must stash
the original a5 in a special place (_savea5) and restore it before
each system or toolbox call. This is done, however, only the first
time the desk accessory is loaded. In the meantime, the proper value
of a5 can change if a new application has started up, causing all hell
to break loose!
Temporary solution -- modify the crtdriver.s header file so that
_savea5 is reset every time the driver is opened, and not just when it
is loaded.
long range solution -- modify SUMACC so instead of using its own
'_savea5', it uses the one provided by APPLE in system low-memory
which is guaranteed to be correct.
------------------------------
From: John Clark <clark@rand-unix>
Date: 05 Apr 85 15:14:16 PST (Fri)
Subject: RECOVERING FROM TECMAR HARD DISK CRASHES
If you experience a "soft crash" on a Tecmar hard disk with version
2.0 partitioning software (and perhaps on other external hard disks as
well), don't be too hasty about reformatting or sending the beast out
for repairs. Recovery may be possible simply and with no loss of
files.
A soft crash is here defined as corruption of the System and/or Finder
files on the default Tecmar boot volume ("DTBV"), "The System ". At
initial powerup, software on the boot floppy attempts to make the DTBV
the startup volume (and, if successful, ejects the floppy). If the
System and Finder files are not present on the DTBV, the floppy stays
put and becomes the startup volume, while the DTBV is mounted as a
non-startup.
No problem--so far. However, if the Finder and the System files are
present on the DTBV, but in a corrupted state, the Mac can crash at
powerup so that it is impossible either to boot the floppy or to mount
the DTBV.
I experienced this problem when the Mac noisily crashed in the midst
of copying a new System file onto the DTBV. After doing a reset, I
couldn't bring up the Tecmar, nor could I even get far enough to be
given the opportunity to re-initialize the thing. The MacDrive was
completely inert.
Assuming that the crash corrupted only the System file on the DTBV,
and not the DTBV itself, the recovery strategy is obvious--just what
you'd try with a floppy that has a trashed System: force the DTBV to
be mounted as a non- startup. The Tecmar software, unfortunately,
doesn't provide for this.
Disassembly of the Tecmar INIT resource ID=31 suggested a patch that
accomplishes this. On a copy of the Tecmar boot floppy, examine the
System file using Fedit. Search for the (unique) hex string, 6708
337C FFFF 0088. Using Hex Modify, change this string to 4E71 4E71
4E71 4E71. Write the change and exit. The four NOPs (4E71), in
effect, force a branch around the portion of code that tries
(conditioned on the presence of System and Finder files) to make the
DTBV the startup volume.
To my mild astonishment, this patch--the only one I tried--worked the
first time. The Tecmar floppy booted as the startup volume, and
mounted the DTBV as a non-startup. I was then able to copy a clean
System file onto the DTBV. Recovery complete.
Although different in detail, I suspect the same sort of recovery
technique would be effective for soft crashes on similar hard disks
that attempt to automatically mount a volume and convert it to the
startup.
John Clark clark@rand-unix
------------------------------
Date: Wed, 10 Apr 85 01:27:20 pst
From: hamachi%ucbkim@Berkeley (Gordon Hamachi)
Subject: C Compiler Benchmark Update
I previously submitted a table comparing a number of C compilers for
the Macintosh. At that time I had not yet seen the Manx Aztec C
compiler.
Since then, Manx sent me an evaluation copy for a week. Bill Duvall
sent me some additional results. Finally, a friend of mine let me use
his Megamax compiler version 1.2.
The main benchmark was the sieve program as published in Byte
magazine, August 1983. The benchmark did not use register variables.
Since the hardware configuration varied from compiler to compiler, it
isn't easy to make comparisons. The "Small" gives the size of a
secondary benchmark, a trivial c program with a single printf
statement.
===========================================================================
Vendor Memory Disk Compile Link Load+Run Run Size Small
===========================================================================
Manx 128K Floppy 28.5 41.6 16.9 6.6 5124 4904
Consulair(a) 512K HyperDrive 19.2 14.5 15.2 8.0 10496 10240
Consulair(b) 512K HyperDrive ---- ---- ---- 6.3 ----- -----
Megamax v2(c)512K Floppy 7.9 71 13.0 6.6 5484 5276
Megamax v2(c)512K Corvus Omni 2.7 23 9.2 6.6 5484 5276
Megamax v1.2 128K Floppy 5.1 73.7 13.2(d) 6.6 5768 ----
Megamax v1.2 128K Floppy 5.1 73.7 17.2(e) 6.6 5768 ----
Softworks 128K Floppy 77.4 111.9 15.8 8.8 34560 26368
Hippo 2 512K Ram Disk 11.6 8.8 14.1 --- 13864 ---
Sumacc VAX780 2MB Hard Disk 2.3 (compile+link) (f) 7239
===========================================================================
Notes: (a) version using 32 bit integers
(b) version using 16 bit integers (same as other compilers)
(c) probably a prerelease of version 2.0
(d) from the Megamax "transfer" mini-finder.
(e) from finder 1.1g
(f) 16 seconds real time to compile. Bomb 26 when run.
From the table it looks like the Megamax v2 on a 512K machine is
slower than the Megamax v1.2 on a 128K machine. The source file is
less than 2K, so I doubt that fragmentation had anything to do with
it. This anomaly illustrates that these numbers are for comparison
only, and your mileage may vary. Use the numbers to pick the
interesting ones, and the clear losers.
I timed the compilers using the stopwatch on my Casio F-85 wristwatch.
The time to load the compiler or linker was not included in the
measured time; however, the time to compile included the time to load
the assembler for all compilers except for the Megamax compiler, which
has no separate assembly step.
The numbers shown here measure only a small part of what's important
in a good compiler. A good suite of test programs would include a
file I/O benchmark, a subroutine call benchmark, etc. (I'm working on
it, but these things take time).
The more I run benchmarks the less convinced I am that these numbers
really matter. You should consider how bug-free a compiler is: I have
enough trouble with my own code without having to debug somebody's
compiler. Consider ease of use: would you prefer a heavily Unix-like
environment (Manx) or a more Mac-like environment? What kind of
debugging tools are there?
While the overall compile-link-run time is interesting, serious
developers will typically compile a module, link several ".o" files
together, and then test. In this environment a fast linker may be
more valuable than a fast compiler or the ability to produce small
a.out files.
Most programmers spend a significant portion of their time testing and
debugging. What kind of debugging tools does each compiler have?
Nobody has a symbolic debugger--if enough people ask for one, the
compiler vendors will get the message. If one were available, it
would be a persuasive selling point with me.
Then there's price. These compilers range in price from $299 to $499.
Some are available at a substantial discount through mail order. If
two compilers are about the same, choose the cheaper one.
People seem to like what they buy. That makes sense, as they buy what
they like. Nevertheless, ask your friends what they think, and get
them to let you use their systems. Try out lots of different
compilers and then decide what kind of interface you like the best.
That's what I'm doing as I make these measurements.
--Gordon Hamachi
------------------------------
Date: Fri Apr 5 16:14:11 1985
From: mcb@lll-tis-gw (Michael C. Berch)
Subject: ProModem 1200 and ProCom-M (review)
I attended the Computer Faire in San Francisco last weekend with an
open mind and the firm intention to come home with a modem for my new
Mac. The hot-selling item was the Prometheus ProModem 1200, a "Hayes
compatible" 300/1200 bps serial modem, and I ended up getting it from
Priority 1 Electronics at their "show special" price of $299,
including the "MacPac" which is a Mac cable and a disk containing a
communications package called ProCom-M (version 0.9X).
The modem itself is a tremendous buy. The technical manual is
well-written and covers the Hayes-compatible command language and the
real-time clock-calendar. (You can pay extra and get an "options
processor", an alpha display, and, I believe, some RAM for
communications buffer.) The unit seems solidly built and
well-designed, though a bit bulky and heavy (not a problem in my
application). I'm sure there are things I haven't come across yet, but
my first reactions are enthusiastic.
ProCom-M, on the other hand, is a big disappointment. It came in a
sealed box with the Mac cable and NOT A SHRED OF PRINTED
DOCUMENTATION. There was a manual contained in document files that you
could access with ProCom and read on the screen. I tried to print
them from the file menu, but they drove the Imagewriter crazy because
they contained control characters (evidently from the previous
Wordstar version of the manual, which was apparently copied verbatim).
Strike one.
The manual was apparently written by a person not fluent in the
English language. [I don't mean this disparagingly -- he writes
English a lot better than I can write any non-English language].
SOFTWARE DEVELOPERS, PLEASE NOTE: if a software product is worth
releasing, it is worth documenting in a readable form by a
professional writer. It doesn't cost a fortune, but reflects well on
your firm and products. (flame off). Strike two.
Advertising material for the "MacPac" and ProCom-M states that it does
"simple terminal emulation". Well, that apparently means that it
emulates a "simple terminal" -- a TTY. Alas, no VT100 or even VT52 (or
even, for gosh sakes, an adm3a :-) ). VT100 is promised for Real Soon
Now. Strike three.
There are several serious bugs in ProCom-M version 0.9X. One is that
you can't use it from the external disk drive -- if you do, the phone
directory is blank and it won't load any phone number files from disk.
It also bombs every now and then for no apparent reason. (No, I didn't
note the ID but I will for their Tech Support.) Another bug is that
the cursor won't move left (either destructively or non-destructively)
when BACKSPACE is received (or echoed locally). It uses CTRL-BACKSPACE
for DEL and CTRL-[ for ESC (or so I was told by the developer). BREAK
is sent by selecting it from the Commands menu. Strike four.
I haven't yet tried downloading/uploading using XMODEM protocol or
capture mode. Presumably, it works.
One interesting feature is that Prometheus maintains a BBS (in
Fremont, Calif.) where you can download the "latest" version of
ProCom-M if you are a registered customer. You can also ask questions
of their support people, which do get answered, publicly, but -alas-
are not usually good news. The version I have (0.9X) is dated December
1984; the version offered for download is apparently the same with
minor bug fixes.
Well, the bottom line is that I will have to buy some REAL
communications software for the ProModem. If anyone has any strong
feelings pro or con about the full-featured packages, please be kind
enough to drop me a line to the address below.
Michael C. Berch Control Data Corp. / Lawrence Livermore Natl.
Laboratory mcb@lll-tis.ARPA
{akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
...!idi!lll-tis!mcb
------------------------------
Date: Thu, 11 Apr 85 18:46:22 pst
From: Richard Ottolini <rick@mazama>
Subject: MacDraw-to-Impress (Imagen) translator
I was thinking of writing one. Please stop me if one exists. The
resolution of MacPaint was too low to bother transfereing to a laser
printer (besides this software exists). I requested the MacDraw
vector file format last week, but did not receive correct information.
I have a prelimary decoding from MacDraw .9992 file dumps. It more
resembles the menu options in MacDraw rather than the ToolBox picture
command format (I quess it might be pre-Mac QuickDraw). I will post
the format after I have tested it in the conversion program.
------------------------------
Date: Mon, 1 Apr 85 11:24:18 pst
From: (Mike O'Dell[x-csam]) mo@lbl-csam
Subject: Serial driver baud rates
DOes anyone off-hand know the formula for calculating the 9-bit baud
rate constant for the baud-rate/format ioctl? IM gives nice numbers,
but they aren't quite geometric as I expected. I looked up the
formula for the raw SCC divisor:
((clock rate)/(2*baud rate)) - 2
I suspect the -2 is the culprit. However, I strongly suspect the baud
rates I want to generate either (1) cannot be expressed accurately
enough in the 9-bit ioctl representation or (2) cannot be expressed at
all because they are quite slow. Does anyone know the consequences of
manhandling the SCC registers myself? Is the 16-bit version of the
timing constant kept somewhere and will have to be hunted down and
adjusted? Does anyone know why they chose such a representation when
they could have simiply represented the entire 16-bit constant?
Further along these lines, is the information necessary to write a RAM
serial driver available? I want to run a port in syncronous mode
complete with framing, etc. The Appletalk driver does this, but is
there any information available short of reverse-engineering that
beastie? Matters such as interactions with the disk driver are the
kind of things which give me the willies. I must run syncronously,
will settle for 9600 baud, and must be able to do disk I/O without
locking out the serial channel. Can anyone help?
Thanks,
-Mike O'Dell
PS - I just realized I may have misread IM and the timing constant my
indeed by 10 bits in the ioctl argument. If so, there are probably
enough bits to go slow enough - dunno about accuracy until I see the
formula and run some numbers.
------------------------------
Date: Thu, 11 Apr 85 08:49:34 pst
From: (Mike O'Dell[x-csam]) mo@lbl-csam
Subject: Serial Tales
I have some questions for any Serial Driver wizards out there.
(1) I need to generate baud rates not in the official list. I have
tried to reverse engineer the formula for the IOCTL baud rate field
and am convinced that some of the rates I need would require a number
too big for the 10 bits of the IOCTL word. So, is is possible to use
the IOCTL to set as much as I can and then just manhandle the SCC
registers? Should I bypass the IOCTL altogether? Is there something
somewhere which has to be diddled if I load the SCC baud rate
registers myself? Wondering out loud department: why did they pick a
different representation for the baud rate? Why didn't they just use
a longword for the state information??????
(2) I need to write a serial driver which runs in synchronous mode
doing HDLC. I need to be able to do disk reads and writes at the same
time so I need to interact with the disk driver the way the async
serial driver does. I will send and receive complete frames so I only
have to stuff the TX or read the RX registers into the buffer fast,
and need to go up to 9600 baud. Does anyone know where the
disk-driver/serial-driver interface is documented and what I have to
do to interact with whatever else is involved with arbitrating
assignment of serial ports to drivers?
Thanks muchly,
-Mike O'Dell
------------------------------
Subject: Anyone have Red Ryder 5?
Date: 10 Apr 85 13:34:29 EST (Wed)
From: Dave Farber <farber@UDel-Huey.ARPA>
------------------------------
End of INFO-MAC Digest
**********************