[mod.computers.macintosh] INFO-MAC Digest V4 #27

INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator William J. Berner) (03/08/86)

INFO-MAC Digest          Saturday, 8 Mar 1986      Volume 4 : Issue 27

Today's Topics:
                          Transfer procedure...
                      Vol 4 #23 - Red Ryder Problem
                       800k drives not working...
                                Color Mac


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

Date: Thu 6 Mar 86 21:57:08-EST
From: Rich <RS4U@CARNEGIE.Mailnet>
Subject: Transfer procedure...


To all interested parties:

This program fragment implements the strategy for calling
the assembly-language-only trap "_Launch" from Pascal, as
described in Macintosh Technical Note #52.

This procedure was written in TML Pascal; it puts a Standard File
box on the screen with a list of applications to which you can transfer.
It's useful for putting in a program as a menu option, and with TML Pascal
there's a way to implement this as a desk accessory.

note -- this coed is slightly different from the LisaPascal given, and
I've added in the SFGetFile call; however, it should work in LisaPascal
too.

I will continue to send useful program fragments as I find/write them.
Please send me comments or questions about anything I post; I'd appreciate
it.

                    --richard.


procedure Transfer;
{Richard Siegel
 March 6, 1986
}
TYPE
          pLaunchStruct = ^LaunchStruct;
          LaunchStruct = record
                    pfName: ^Str255; {Pointer to application to be launched}
                    param: integer;  {State of sound/screen buffers}
          End;  {LaunchStruct}

var
          Reply : SFReply;
          ValidTypes : SFTypeList;
          volRef : Integer;
          Location : Point;
          prompt : Str255;
          pMyLaunch: pLaunchStruct;
          myLaunch:  LaunchStruct;
          fName: Str255;
          err : OSErr;

Procedure Launch; INLINE $A9F2;
PROCEDURE LaunchIt(pLnch: pLaunchStruct); INLINE $205F;

begin
          with Location do begin
                    h := 60;
                    v := 60;
          end;

          validTypes[0] := 'APPL';

          SFGetFile(Location, prompt, NIL, 1, validTypes, NIL, Reply);
          if Reply.good then begin
                    err := SetVol(NIL, Reply.vRefNum);
                    pMyLaunch:= @myLaunch;
                    With pMyLaunch^ do Begin
               pfName:= @Reply.fName;    {pointer to our fileName}
               param:= 0;          {we don't want alternate screen or sound buffers}
                    End;       {With}
                    LaunchIt(pMyLaunch);
                    Launch;
          end;
end;

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

Date: Fri, 7 Mar 86 16:29:56 PST
From: Lionel_Tolan%SFU.Mailnet%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: Vol 4 #23 - Red Ryder Problem

I'm a micro user not a tech but I dispute the claim that any Red
Ryder version is 99.9% VT100 compatible. We run MTS using DEC
front ends on 9600 BAUD local lines. The software for the front
ends uses XY addressing to postion the cursor for menus and such
to save time.

When Ryder gets a direct cursor address it resets to the
beginning of the line rather than going to the correct location.
The result is that all of the items on a horizontal menu are
printed in the first few columns. This also does a wonderful job
of encrypting incoming messages on our full screen message
system. I quit using RR because of this and its slow speed. I
didn't know an easy way to get to Scott Watson so I haven't reported
the problem.

VersaTerm also had the same problem but I understand that this
has been fixed. Macterminal and MacKermit work fine. MacKermit is
my terminal emulator of choice because it appears to keep up at
9600 BAUD. Now if MacKermit could only position the cursor with
the mouse.....................

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

Date: Fri, 07 Mar 86 12:58 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Subject: 800k drives not working...

It matters a great deal whether your 800k drives are the new Apple
drives, or third-party 800k drives such as the Haba and (I think)
Mirror Technologies.  It also matters whether you're running under
the old MFS, or under HFS (and, if so, whether you're running the
HD20 RAM-based version, or have the new ROMs or a Mac Plus).

In short:  the original Mac's .SONY driver assumes that all floppy
disk drives have the same speed-control requirements as the Apple
400k drive.  The Haba and other third-party 800k drives were built to
be compatible with the Apple drives, and thus they work just fine on
the Mac when plugged into the IWM (external-floppy) port.

The updated version of the .SONY driver released (in the Hard Disk 20 fi
le) with the Apple HD 20 is different.  It assumes that any floppy drive
containing more than 400k is one of the new Apple 800k drives, which has
its own speed controller and does not require that the Mac fiddle with
the speed-control lines.  [The new Apple drives supply a "data transfer
ready" signal that the older drives did not... another incompatibility].
So, if you plug a Haba 800k drive into the IWM port, the new driver will
assume that it's a new Apple drive, and won't supply some of the signals
that the drive needs.  Result:  it won't work.

I've seen a patch that someone had constructed for the RAM-based version
of HFS, that would cause the new .SONY driver to behave the way that the
old one did (always supply speed-control signals).  This patch must be
applied to the Hard Disk 20 file using FEdit;  it permits the Haba
drives to work, but will probably render Apple 800k drives [and possibly
the HD20] inoperative.

I don't know if the patch can be used if you have the new ROMs... I rather
doubt it.  Ditto if you use a Mac Plus.  My current belief is that
third-party 800k drives probably will not work if you plug them into the
IWM port on a Mac Plus or a 128k-ROM Mac.

It appears as if the controller in the HD20 is providing the IWM speed-
control signals to a floppy-disk drive plugged into its expansion port,
regardless of the size of the drive.  So, you should be able to continue
to use your third-party drives by plugging them into the HD20.

NOTE HOWEVER... all of the above is meaningless if you actually have
Apple 800k drives for the Mac.  These should (better!) work just fine
when plugged into the IWM port on a Mac that [a] is a Mac Plus; [b]
is a Mac with the 128k ROMs, or [c] is a Mac with the 64k ROMs, and
is running the System and "Hard Disk 20" files released on diskette
with the Hard Disk 20.

Hope this helps...

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

Date: Fri, 07 Mar 86 13:25 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Subject: Color Mac

According to an article in Electronic Engineering Times last year,
there are two new Macintosh-line products (or product families)
in the works.

Jonathan will be Apple's entry into the engineering-workstation
marketplace.  It will have a larger (14-inch?) monochrome screen with
more screen "real estate" (more pixels in each direction), 11 meg of
memory (upgradable to 16 meg), a 68020 processor chip (probably with a
68881 math coprocessor chip, or at least a socket for same) , and will
be offered with a 20-meg internal hard disk as an option (and I can't
imagine many folks buying an 11-meg machine with a single floppy drive &
nothing else!).  It will have expansion slots (possibly VMEbus
standard?).  Its physical footprint will be somewhat larger than the
Mac, but not much.  Rumored announcement date: late Spring to mid-summer
1986).

Jason (aka "Versa Mac", "Modular Mac", and "Color Mac") will be
announced sometime around 4Q86 or 1Q87.  It will provide a color screen
of about the same size as the Mac's.  Rumored to be a compact machine of
about the same size as the Mac, it will provide an architecture fairly
similar to that of the Mac Plus (SCSI port) with a limited expansion
capability (it may not provide a standard bus, from what I can puzzle
out).  Reportedly, the biggest factor in its release date is the
availability of color monitors that can handle the necessary bandwidth
[I suspect that Apple doesn't want to risk the sort of flak that
Commodore has been taking re the Amiga's high-resolution color mode...
since the Amiga uses a standard NTSC framing signal, high-resolution
color tends to suffer from interlace flicker, which makes it very
difficult to use for word processing].

Disclaimers:  this is all rumor;  I can't swear to the truth of any part
of it.

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

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