INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator William J. Berner) (02/25/86)
INFO-MAC Digest Monday, 24 Feb 1986 Volume 4 : Issue 16
Today's Topics:
RamStart for MacPlus?
Command set for MAC+ SCSI
Mac+ Serial Cables
Switcher 4.6
comment about QUED
missing page in Inside Macintosh
Scrolling suggestion
what's Next?
----------------------------------------------------------------------
Date: Fri, 21 Feb 86 14:14:46 est
From: cordy%qucis.bitnet@WISCVM.WISC.EDU
Subject: RamStart for MacPlus?
I have just started using my new MacPlus, and was trying to set it up
with a large RamDisk using RamStart. The result was a system error of
some kind every time RamStart tries to start up the Finder on the RamDisk.
I have experimented with this and determined that the incompatibility is not
with the MacPlus or System 3.0, since a RamDisk system using System 3.0 and
Finder 4.1 works fine. The incompatibility is with Finder 5.1, presumably
with the hierarchical file system.
Does anyone know of a version of RamStart or equivalent that will work with
Finder 5.1 and the heirarchical file system? Does the author or RamStart
(the best free program EVER) know about this problem? Can it be fixed?
Jim Cordy
Dept. Computing & Info. Science
Queen's University at Kingston
Canada
------------------------------
Date: Sun, 23 Feb 86 15:23:11 est
From: Ken Mandelberg <km%emory.csnet-relay.csnet@CSNET-RELAY.ARPA>
Subject: Command set for MAC+ SCSI
From what I read, the main issue preventing easy mix and
match of SCSI disks is making sure that the driver uses
the same command set as the controller. To this end the
ANSI X3T9.2 Committee is considering a proposed standard
called CCS (common command set).
I have not gotten my December software supplement, so I
as yet don't have any idea what is going on inside the
Mac+.
Does Apple supply a SCSI device driver, and if so what
command set does it use? Is it CCS, homegrown, or perhaps
the set command set used by a popular controller?
If Apple is not supplying a device driver, do they at least
publish some command guidelines that the third party
SCSI suppliers are using?
------------------------------
Date: Sun, 23 Feb 1986 17:29 EST
From: Dave Elbon <SYSDAVE%UKCC.BITNET@WISCVM.WISC.EDU>
Subject: Mac+ Serial Cables
I've located the Mac Technical Note (#65) with the Mac+ pinouts. The
serial ports look like this:
Macintosh Plus Serial Connectors
Mini DIN-8
(Female Connector)
* * *
8 7 6
* * *
5 4 3
* *
2 1
Pin Name Description/Notes
--- ---- -----------------
1 HSKo Output Handshake (from Zilog 8503 DTR)
2 HSKi/Ext. Clk Input Handshake (CTS) or TRxC (depends on 8530 mode)
3 TxD- Transmit Data
4 Ground
5 RxD- Receive Data
6 TxD+ Transmit Data
7 Not Connected
8 RxD+ Receive Data (ground this line to emulate RS-232)
I've not had a chance to use this yet. What I need is some Mac+ to
regular 25-pin RS-232 cables. My dealer didn't have anything like
that and I don't know where to get the mini-8 connectors in town, so
I bought a mini-8-to-mini-8 cable (called a Mac+ peripheral cable, I
think), and cut it in half. Now I just need to add the 25-pin
connectors and I should be ready to go. The cable is not a straight-
through, I believe several lines are crossed so the color coding
probably won't be the same on the two ends. Remember, I haven't
actually done this yet, but it sounds good.
Acknowledge-To: Dave Elbon <SYSDAVE@UKCC>
------------------------------
Date: Sun, 23 Feb 86 14:08:38 cst
From: Kurt Hansen <hansen%uiowa.csnet@CSNET-RELAY.ARPA>
Re: Speed
1. I read the ongoing discussion about transmission speed to/from the
Mac with interest. I am about to hook up the Mac to a supermicro Unix
workstation (1-8 users) with a null-modem type cable, and I was hoping
to run at 9600 baud. I blithely assumed that it could handle this speed.
To test whether it could or not, I took a large (94K) file into Apple's
Edit program (straight text, Monaco 9 pt. font, so about 24x80 full screen).
I scrolled through the file first to get it all into memory (I'm on a 512),
then timed how long it takes to scroll through it. It took 2 minutes and
13 seconds, which converts to about 700 characters per second. This means
that any terminal program which is about as efficient as Edit is at getting
characters to the screen is limited to about 7000 baud, which agrees with
the performance people have been reporting for commercial programs.
2. The above speed I will call the scrolled-display speed. To be honest, I
expected this speed to be higher. After all, the Mac is supposed to be
fast, right? Well, I have worked on lots of systems, and actually this is
pretty fast. This speed only needs to be as fast as the user can comfort-
ably skim the material scrolling by. On this supermicro, I run the termi-
nals at 9600 baud, and really this is too fast for comfort. As I see it,
this scrolled-display speed doesn't need to be any faster than it is on
the Mac.
3. Naturally, there are other speeds which should be higher. For example,
we want file transfer speed to be as high as possible. However, most
programs I have seen (on any system), don't show you the file as it is
being transferred. Thus, transfer speeds may be a lot higher than the
scrolled-display speed. Another speed which should be higher
is the speed for a full screen editor. In this case, you are simply
writing over characters that already exist, or clearing whole lines or
the whole screen. If you think about it, a lot of effort is required for
a scrolled-display: all the current lines must be moved up, then the new
line must be drawn. This means that it is a lot faster to do something
like a full-screen display than a scrolled-display. Hence the Mac and
any other bit-mapped display ought to be able to handle a full-screen,
non-scrolling type display at a higher speed, possibly much higher.
4. When I get the new ports for our supermicro, I will post the results
of connecting, transferring, and doing full-screen work with the Mac
to the net.
Kurt Hansen
------------------------------
Date: Mon 24 Feb 86 07:30:24-PST
From: William J. Berner <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: Switcher 4.6
Several people have had trouble with Switcher 4.6; therefore, I have
removed it from the <info-mac> directory. If I get my hands on another, or
if the kind soul who posted it the first time could mail me another copy, I
will replace the version that is there now.
Bill Berner
Moderator
------------------------------
Date: Mon, 24 Feb 86 11:44:52 PST
From: <DAVEG%SLACVM.BITNET@Lindy>
Reply-to: DAVEG%SLACVM.BITNET@SU-Forsythe.ARPA
Subject: comment about QUED
Date: 24 February 86 11:32-PST
From: DAVEG@SLACVM
To: INFO-MAC@SUMEX-AIM
Subject: comment about QUED
Date: 24 February 1986, 11:25:18 PST
From: David M. Gelphman 415-854-3300 x2538 DAVEG at SLACVM
To: INFO-MAC at SUMEX-AIM.STANFORD
Subject: comment about QUED
I too have the QUED editor and while I am impressed by some of the
things it has, unfortunately it presently has 2 serious shortcomings.
For me it is currently nearly unusable (version 1.3). It seems to
have a problem when SWITCHER and HFS are both operating. In this
configuration, it wants to make a backup of your file after every
save (whether you request it or not) and after the file is backed up
once, the backup file cannot be overwritten for the next backup. In other
words, you can't make frequent saves. If you close the file before you
switch it seems to solve the problem but overall this problem makes
life difficult. I have spoken with them about the problem but have
not received a solution yet (after 1.5 weeks).
The deficiency this editor has which all editors I've seen for the
Mac also have is the lack of ability to search using wildcard characters.
I asked them about this and they said I was the first person who had
requested this! I guess many of the people using their product have
never used an editor on a computer which is not as user friendly as the
Mac.
David Gelphman DAVEG@SLACVM.BITNET
------------------------------
Date: 24 FEB 86 17:46-CST
From: BOYD%TAMLSR.BITNET@WISCVM.WISC.EDU
Subject: missing page in Inside Macintosh
I just received a letter from Addison Wesley, publishers of Inside Macintosh.
Someone had asked earlier whether they would provide a correction for the
missing page II-91. Well, they actually did! In the interest of helping
disseminate the corrections, the page follows. If you are wondering how they
got my address, I won my copy of IM at the Macworld Expo in San Francisco.
-------------------------------------------------------------------------
The File Manager
Result codes noErr No error
bdNamErr Bad file name
dupFNErr Duplicate file name and version
dirFulErr File directory full
extFSErr External file system
ioErr I/O error
nsvErr No such volume
vLckdErr Software volume lock
wPrErr Hardware volume lock
FUNCTION FSOpen (fileName: Str255; vRefNum: INTEGER; VAR refNum:
INTEGER) : OSErr; [Not in ROM]
FSOpen creates an access path to the file having the name fileName on the
volume specified by vRefNum. A path reference number is returned in refNum.
The access path's read/write permission is set to whatever the file's open
permission allows.
Result codes noErr No error
bdNamErr Bad file name
extFSErr External file system
fnfErr File not found
ioErr I/O error
nsvErr No such volume
opWrErr File already open for writing
tmfoErr Too many files open
FUNCTION OpenRF (fileName: Str255; vRefNum: INTEGER; VAR refNum:
INTEGER) : OSErr; [Not in ROM]
OpenRF is similar to FSOpen; the only difference is that OpenRF opens the
resource fork of the specified file rather than the data fork. A path
reference number is returned in refNum. The access path's read/write
permission is set ot whatever the file's open permission allows.
NOTE: Normally you should access a file's resource fork through the
routines of the Resource Manager rather than the File Manager. OpenRF
doesn't read the resource map into memory; it's really only useful for
block-level operations such as copying files.
Result codes noErr No error
bdNamErr Bad file name
extFSErr External file system
fnfErr File not found
ioErr I/O error
nsvErr No such volume
opWrErr File already open for writing
tmfoErr Too many files open
High-level File Manager Routines II-91
[THIS MESSAGE HAS BEEN ARCHIVED AS [SUMEX]<INFO-MAC>INSIDEMACPAGEII-91.TXT
-BB]
------------------------------
Date: 24 Feb 1986 16:00-PST
From: Steve Deering <deering@su-pescadero.ARPA>
Subject: Scrolling suggestion
(I submitted this note to INFO-MAC in November, just after the mailing
list went on vacation. It didn't show up in the issues after the hiatus,
so here's another try.)
Clicking on an arrowhead in a scroll bar is supposed to cause its associated
object to scroll by one line (or other applicable small unit), whereas
continuous pressing should cause continuous scrolling by lines. However,
in many places where scroll bars are used, it is necessary to click very
quickly to avoid scrolling two or more lines. A good example is the
font list displayed by the Font/DA Mover -- I find that it often takes
me several tries to get the window scrolled to exactly the place I want
because I keep overshooting. The same problem almost always arises
when scroll bars are used to set the value of a numeric parameter, such
as the size of a RAM disk.
It looks as if applications are responding to the downstroke of the
mouse button by performing a single scroll step, and then continuing to
scroll if the button is still down. If the single scroll step takes
very little time, then the button will probably still be down even if it was
just a "click". (I am not a Mac programmer, so this is pure speculation.)
I suggest that scrolling should work just like keyboard auto-repeating.
That is, the downstroke should cause an immediate single scroll step
and then, ONLY if the button remains down longer than some threshold,
continuous scrolling should occur. Perhaps the Control Panel settings
for keyboard repeat threshold and repeat rate should also determine the
scrolling threshold and maximum scrolling rate, or maybe there should
be separate scrolling parameters.
I wonder if it is too late to get this into the new ROMs? :-)
(This joke made sense in November.)
Steve Deering
deering@SU-Pescadero.ARPA
------------------------------
Date: 24 FEB 86 18:27-CST
From: BOYD%TAMLSR.BITNET@WISCVM.WISC.EDU
Subject: what's Next?
Hey, what's Steven up to now? Good 'ol Mr Jobs just bought a controlling
interest in Pixar and will become chairman of the board, according to this
week's Infoworld. For those of you unfamiliar with Pixar, it's a spinoff of
Lucasfilm that builds absolutely incredible graphics machines. So far,
it's one of the hottest things on wheels.
Their next project is, according to an insider at Pixar, targeting a
machine that can handle dealing with 800 million polygons in a scene.
That's not high-resolution, that's Near-Reality resolution. And they've
been working on it for some time...
What do you think he has up his sleeve? It's gotta be good.
------------------------------
End of INFO-MAC Digest
**********************