Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-108.txt

Text File | 1994-12-08 | 43.8 KB | 1,066 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 09 Jun 92       Volume 1 : Issue 108

Today's Topics:

    How do I detect the enter key?
    TO APPLE: We need high-speed serial communications
    OK, Apple, what gives with the gestalt values?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

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

From: [e-mail] (Richard Kennaway)
Subject: How do I detect the enter key?
Date: 2 May 92 14:38:51 GMT

On a IIfx with the extended keyboard, the enter key generates the keycode
0x4C.  On a Portable, it generates 0x34.  A look at IM vol1 (!) reveals
that in those days (i.e. the original Mac and MacPlus), 0x4C = enter key
on keypad, 0x34 = enter key on US keyboard, and also that the enter key on
the UK keyboard is something else again.  I had thought that since virtual
key codes came in, this situation didnt happen anymore, but apparently
not.

So I am still in the dark about how to tell in a machine-independent way
whether the enter key was hit.  Any suggestions?  Calling Gestalt or
SysEnvirons to find out what sort of Mac or keyboard is being used and
then looking up a table of the different enter key codes would be gross.

The character code (3) doesn't identify the enter key, since it is also
generated by control-C.

- --
Richard Kennaway     SYS, University of East Anglia, Norwich NR4 7TJ, U.K.
Internet:  [e-mail]               uucp:  ...mcsun!ukc!uea-sys!jrk

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 5 May 1992 19:30:44 GMT

[e-mail] (Richard Kennaway) writes:
>The character code (3) doesn't identify the enter key, since it is also
>generated by control-C.

Is there a reason you need to distinguish between the enter key and
control-C?
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Richard Kennaway)
Date: 6 May 92 09:10:58 GMT

In <[e-mail]> [e-mail]
(Steve Dorner) writes:

>[e-mail] (Richard Kennaway) writes:
>>The character code (3) doesn't identify the enter key, since it is also
>>generated by control-C.

>Is there a reason you need to distinguish between the enter key and
>control-C?

Yes: because the user can distinguish them.  The enter key has a well-
defined role in the user interface guidelines.  Control-C is an
entirely different keystroke.  Why should control-C act as the enter key?

- --
Richard Kennaway     SYS, University of East Anglia, Norwich NR4 7TJ, U.K.
Internet:  [e-mail]               uucp:  ...mcsun!ukc!uea-sys!jrk

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 6 May 92 17:54:29 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Richard Kennaway) writes:
>In <[e-mail]> [e-mail]
>(Steve Dorner) writes:
>>Is there a reason you need to distinguish between the enter key and
>>control-C?
>
>Yes: because the user can distinguish them.  The enter key has a well-
>defined role in the user interface guidelines.  Control-C is an
>entirely different keystroke.  Why should control-C act as the enter key?

Why not?  I really think you're making life difficult for yourself.
After all, the user can distinguish between the "1" key on the main
keyboard, and the "1" key on the keypad, can he not?  Do you also treat
those differently?  What's wrong with ^C as a synonym for Enter?  You are
not allowed to have any semantics for ^C anyway (control is reserved for
user-defined macros or terminal emulators), so what's the harm?

However, if you must, the thing to do is take the keycode, get the current
script, get the current KCHR for that script, run the keycode (minus modifers)
through KeyTrans with the KCHR you just fetched.  If the user had pressed
^C, you'll get a 'c' back from KeyTrans.  If enter was pressed, you'll still
have an ASCII 3.  I guess it's up to you whether it's worth going to such
lengths just to disallow the use of ^C as enter.


- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 6 May 92 18:47:29 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.cso.uiuc.edu> [e-mail] (Steve Dorner) writes:

   >The character code (3) doesn't identify the enter key, since it is also
   >generated by control-C.

   Is there a reason you need to distinguish between the enter key and
   control-C?

Ah, but on my KCHR, I have the character 10 for the enter key.

I think checking for the num-pad enter, and "mac-plus" (and powerbook)
enter is enough. I DON'T think the reference to the UK keyboard hacing
another enter key code being correct. I could be wrong.

- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

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

From: [e-mail] (Peter Creath)
Subject: TO APPLE: We need high-speed serial communications
Date: Fri, 24 Apr 92 06:10:44 CST
Organization: Cube Technologies

OK, Apple, for years programmers have been hacking together routines
to force the serial port to go faster than 57.6k (the max supported
by the .AIn/.AOut drivers).

With the advent of the Quadra, any program that directly addressed
the Zilog chip will have serious problems.  With the advent of the
Telebit WorldBlazer, there is now a modem which can handle a DTE rate
of 115.2k.

We need Apple to come out with a standard driver to handle these high
speeds, possibly even higher than 115.2k.  Perhaps an update to the
Comm Toolbox?  A new SERD?  Or maybe just a new Technote describing
the proper procedure for utilitizing the serial ports' full capacity
reliably.



- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (G. S. Marzot(Joe))
Organization: The MITRE Corporation
Date: Tue, 28 Apr 1992 14:16:07 GMT

In article <[e-mail]>
[e-mail] (Peter Creath) writes:
> OK, Apple, for years programmers have been hacking together routines
> to force the serial port to go faster than 57.6k (the max supported
> by the .AIn/.AOut drivers).
>
> With the advent of the Quadra, any program that directly addressed
> the Zilog chip will have serious problems.  With the advent of the
> Telebit WorldBlazer, there is now a modem which can handle a DTE rate
> of 115.2k.
>
> We need Apple to come out with a standard driver to handle these high
> speeds, possibly even higher than 115.2k.  Perhaps an update to the
> Comm Toolbox?  A new SERD?  Or maybe just a new Technote describing
> the proper procedure for utilitizing the serial ports' full capacity
> reliably.

Isn't there a NuBus board that provides this funtionality?????? Maybe
National Instruments or somebody???

routine disclaimer

+++++++++++++++++++++++++++

From: [e-mail] (Peter Creath)
Date: 29 Apr 92 21:57:15 GMT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (G. S. Marzot(Joe)) writes:
> Isn't there a NuBus board that provides this funtionality?????? Maybe
> National Instruments or somebody???

1) The Macintosh serial ports already have the hardware capability
   of running 232k baud.  It's just not built into the Toolbox.

2) Many people still have 'toaster' Mac's and can't use a NuBus board
   (or don't want to waste their only slot).

3) It would help the Macintosh community in general if Apple just
   released a new Serial tool or technote or something to utilitize
   speeds above 57.6k.  After all, IBM's can go 115.2k.  Granted,
   that's direct-to-chip interrupt-driven machine language, but most
   IBM's have the necessary UART.  Why not just prove the Mac's
   hardware superiority, since it costs more in the first place...

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Bill Coleman)
Date: 1 May 92 13:35:52 GMT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <[e-mail]>, [e-mail] (Peter Creath) writes:
> Lines: 22
>
> 1) The Macintosh serial ports already have the hardware capability
>    of running 232k baud.  It's just not built into the Toolbox.
>
> 3) It would help the Macintosh community in general if Apple just
>    released a new Serial tool or technote or something to utilitize
>    speeds above 57.6k.  After all, IBM's can go 115.2k.

Let's get this straight, guys. The reason IBMs go to 115.2Kbps is because
the 8250 (or equivalent) UART has an internal clock generator that generates
the appropriate clock.

On the Mac, the Zilog 8530 SCC generates internal clocking for asynchronous
rates up to 57.6Kbps. Period. You can't go faster asynchronously unless you
a) supply external clocking or b) modify the hardware of the Mac. Period.

The reason LocalTalk goes 230.4 Kbps is because it uses SYNCHRONOUS FM0
encoding. This requires a 4x clock instead of the 16x clock needed for
asynchronous communication. Hence, it is 4 times faster.

Before you go off berating Apple for not doing something, you at least ought
to be armed with the facts of what is and is not possible.

- --
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: [e-mail]
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

+++++++++++++++++++++++++++

From: [e-mail] (HP48SX Archive Maintainer)
Date: 2 May 92 00:24:08 GMT
Organization: Washington University in Saint Louis, Missouri USA

>1) The Macintosh serial ports already have the hardware capability
>   of running 232k baud.  It's just not built into the Toolbox.

Not quite exact. The Macintosh serial ports can go up to 1Mbit/sec. if
you add an external clock. I think that communication to both the
StyleWriter and LaserWriter LS is going on at speeds above 700kbit/secs.
but I am not sure about it.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Integalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Mon, 04 May 92 14:12:15 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (HP48SX Archive Maintainer) writes:
>>1) The Macintosh serial ports already have the hardware capability
>>   of running 232k baud.  It's just not built into the Toolbox.
>
>Not quite exact. The Macintosh serial ports can go up to 1Mbit/sec. if
>you add an external clock. I think that communication to both the
>StyleWriter and LaserWriter LS is going on at speeds above 700kbit/secs.
>but I am not sure about it.

As far as I can tell, the Stylewriter is running at 57,600bps.
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 16:29:17 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (G. S.
Marzot(Joe)) writes:
>
> In article <[e-mail]>
> > We need Apple to come out with a standard driver to handle these high
> > speeds, possibly even higher than 115.2k.  Perhaps an update to the
> > Comm Toolbox?  A new SERD?  Or maybe just a new Technote describing
> > the proper procedure for utilitizing the serial ports' full capacity
> > reliably.
>
> Isn't there a NuBus board that provides this funtionality?????? Maybe
> National Instruments or somebody???

Any MCP-based NuBus card should handle it, like our Ethernet cards
with 10Mbps, sorry 2.5 real Mbps speeds.

Cheers,
Kent/DTS
- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are not private, and not owned by any company, organization
or group.Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 21:02:22 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> In article <[e-mail]>, [e-mail] (G. S.
> Marzot(Joe)) writes:
> >
> > In article <[e-mail]>
> > > We need Apple to come out with a standard driver to handle these high
> > > speeds, possibly even higher than 115.2k.  Perhaps an update to the
> > > Comm Toolbox?  A new SERD?  Or maybe just a new Technote describing
> > > the proper procedure for utilitizing the serial ports' full capacity
> > > reliably.
> >
> > Isn't there a NuBus board that provides this funtionality?????? Maybe
> > National Instruments or somebody???
>
> Any MCP-based NuBus card should handle it, like our Ethernet cards
> with 10Mbps, sorry 2.5 real Mbps speeds.

Tim and I (hi Tim) had an argument about this statement. I must confess
I was thinking about MCP cards with *no* Zylog SCC chips for serial
async I/O handling. The SCC chip has a 3 byte buffer, so there are limitations
with fetching data quickly from such small buffers.

Dennis Hescox, another cubicle neighbour, provided more words of wisdom.
In general the Mac can't handle billions of interrupts without getting
into trouble reading SCC 3-byte buffers (Powerbooks with the PowerChip
causing a lot of interrupts, VM is going to VM-land with interrupts
turned off, and so on).

An external card - style MCP or any other intelligent NuBus card (I'm
assuming we have an independent CPU) would be more suitable for high
speed serial transfers. Fortunately for the time being there are few
async serial protocols (for modems for instance) with over 56kps speed
requirements - but yes, this will change.

Another nice idea would be to build a cheap NuBus card with a special
embedded CPU (style Moto one-chip CPUs with a serial port) which constantly
just drags bytes from a buffer and maps it into NuBus data space.

Anyway, I hope this clarified the case (Tim) :-).

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Stephan - Somogyi)
Date: Fri,  8 May 92 16:27:26 PDT
Organization: The Portal System (TM)

[e-mail] (Kent Sandvik) writes:

>Another nice idea would be to build a cheap NuBus card with a special
>embedded CPU (style Moto one-chip CPUs with a serial port) which
>constantly just drags bytes from a buffer and maps it into NuBus data
>space.

Applied Engineering has a 4-port serial card called the QuadraLink DMA
which they tout as being able to support all ports running at high speed.
They don't mention the top speed in the press-release that I have here,
though; they do however claim that all 4 ports are also usable for
LocalTalk with a software router.

______________________________________________________________________
Stephan Somogyi    "It seemed like a good idea at the time"    MacUser

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

From: [e-mail] (Jamie R. McCarthy)
Subject: OK, Apple, what gives with the gestalt values?
Date: 27 Apr 92 15:33:01 GMT
Organization: Kalamazoo College

Apple is apparently planning on releasing 4,294,967,000 machines pretty
soon, because there's obviously a shortage of values for
gestaltMachineType to return.

The "Macintosh LC II Dev Note", on the "Hex, Drives, and Videotape" CD,
contains the following annoying words:  "The Macintosh LC II returns the
same gestaltMachineType response value as the Macintosh LC: 19 ($13). If
your software needs to differentiate between the Macintosh LC and LC II,
you can use the gestaltProcessorType selector to determine whether the
CPU is a 68020 or 68030."

Yes, I _can_, but I shouldn't _have_to_, now, should I?  Isn't that why
the bloody gestaltMachineType selector exists in the first place!?
Don't you think LC II owners will get suspicious when MacEnvy tells them
they have just a plain ol' LC?  "Maybe Apple put an LC into an LC II
case...hmmm..."

Argh.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 My coat contained a furnace where there used to be a guy...

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 27 Apr 92 18:02:02 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>Apple is apparently planning on releasing 4,294,967,000 machines pretty
>soon, because there's obviously a shortage of values for
>gestaltMachineType to return.
>
>The "Macintosh LC II Dev Note", on the "Hex, Drives, and Videotape" CD,
>contains the following annoying words:  "The Macintosh LC II returns the
>same gestaltMachineType response value as the Macintosh LC: 19 ($13). If
>your software needs to differentiate between the Macintosh LC and LC II,
>you can use the gestaltProcessorType selector to determine whether the
>CPU is a 68020 or 68030."
>
>Yes, I _can_, but I shouldn't _have_to_, now, should I?  Isn't that why
>the bloody gestaltMachineType selector exists in the first place!?

No, it isn't. Read the Gestalt docs in I-M 6 more closely.
The gestaltMachineType selector is
what is known as an "informational selector" and not an "environmental
selector." I think those are the correct terms.

(Yes, it is a big pain. I still have code which relies on informational
selectors to determine some functionality: I know it is wrong, but I just
haven't fixed it yet).

Info selectors are selectors which are FYI, but you shouldn't use them
to make judgements about how your software will run. In particular, you
shouldn't use the item returned by an informational selector like
machine type to decide what kind of processor you have. What if you are
running an SE with an -020 or -030 accelerator? Your code will break.

There are other examples of how not to use Gestalt - for example, assuming
you have an FPU because you have a certain processor... assuming you have
color QuickDraw because you have System 7, etc. You always must test for
the lowest "atom" of functionality that you actually need - using the
Environmental selectors. The Informational ones are fine for the Gestalt DA
or an about-box but can't be guaranteed for much else.

All that said, actually I agree with you - I think Apple should have used
another machine type for the LC II. Unless they have so many new machines
planned that they can't spare the bits in the machine type field... : )
- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 27 Apr 92 21:05:34 GMT
Organization: Kalamazoo College

[e-mail] (Paul Potts) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>
>>"The Macintosh LC II returns the
>>same gestaltMachineType response value as the Macintosh LC: 19 ($13). If
>>your software needs to differentiate between the Macintosh LC and LC II,
>>you can use the gestaltProcessorType selector to determine whether the
>>CPU is a 68020 or 68030."
>>
>>Yes, I _can_, but I shouldn't _have_to_, now, should I?  Isn't that why
>>the bloody gestaltMachineType selector exists in the first place!?
>
>Info selectors are selectors which are FYI, but you shouldn't use them
>to make judgements about how your software will run.
>The Informational ones are fine for the Gestalt DA
>or an about-box but can't be guaranteed for much else.

My point exactly!  Identical return values serves no purpose except to
put false information into programs' about boxes.  Environmental
selectors can and should be identical for different machines;  if you want
to know processor type, all machines with the same processor should
return the same value.  But you wouldn't expect gestaltSystemVersion to
tell you "7.0.0" if you were running 7.0.1, even though it's an
informational selector.  What would be the point?

User and machine lying to each other should remain exclusively in the
MS-DOS world.  ("No, that's not a 9-pin dot-matrix printer--it's an
HP DeskJet!  Yeah!  Trust me!")  Macs should be honest.

>All that said, actually I agree with you - I think Apple should have used
>another machine type for the LC II.

You know, everyone calls the LC the "II LC" even though it isn't a II.
Maybe now I'll get calls from people:

"Your program crashes on my II LC and on my friend's LC too."
"Oh, your friend has the new LC II?"
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Also thanks to:  Inside Macintosh (except vol. V, ch. 27)"
   - the Tesserae "About..." box

+++++++++++++++++++++++++++

From: [e-mail] (Jon Rowlands)
Organization: Texas Instruments, SPDC, DSP Technology Branch, Dallas
Date: Tue, 28 Apr 1992 00:00:44 GMT

In article <[e-mail]>, [e-mail]
(Jamie R. McCarthy) writes:
...
|> You know, everyone calls the LC the "II LC" even though it isn't a II.
|> Maybe now I'll get calls from people:
|>
|> "Your program crashes on my II LC and on my friend's LC too."
|> "Oh, your friend has the new LC II?"

Pardon this irrelevancy, but this reminded me of a snippet of conversation
between my (French) boss and an attendant at the sandwich counter of our
excellent cafeteria:

    Sandwich person: Would you like white or wheat?
    Boss: White.
    S: White?
    B: Oui.
    S: Wheat?
    B: No, white.
    S: What?
Ahem.

Jon
- --
Jon Rowlands            email: [e-mail]
Texas Instruments        phone: [phone]
SPDC, DSP Technology Branch      fax: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Date: 28 Apr 92 02:05:24 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
>
> The "Macintosh LC II Dev Note", on the "Hex, Drives, and Videotape" CD,
> contains the following annoying words:  "The Macintosh LC II returns the
> same gestaltMachineType response value as the Macintosh LC: 19 ($13). If
> your software needs to differentiate between the Macintosh LC and LC II,
> you can use the gestaltProcessorType selector to determine whether the
> CPU is a 68020 or 68030."
>
> Yes, I _can_, but I shouldn't _have_to_, now, should I?  Isn't that why
> the bloody gestaltMachineType selector exists in the first place!?
> Don't you think LC II owners will get suspicious when MacEnvy tells them
> they have just a plain ol' LC?  "Maybe Apple put an LC into an LC II
> case...hmmm..."

Apple's reasoning is very easy to understand although personally I think
it's a crock.  The Gestalt values have to come from somewhere,
either the ROM or the System file.  I assume that the LC II
has the same 'universal' ROM as the LC.  In that case the value would
have to come from the system.  But Apple didn't release a new system
with the LC II (perhaps because of all the complaints about the 6.0.x
where x got quite large) and so there is no where to get the new selector
from.

> Argh.

I agree.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- The quest for understanding continues...

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 29 Apr 92 02:56:19 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Quinn "The Eskimo!") writes:
> Apple's reasoning is very easy to understand although personally I think
> it's a crock.  The Gestalt values have to come from somewhere,
> either the ROM or the System file.  I assume that the LC II
> has the same 'universal' ROM as the LC.  In that case the value would
> have to come from the system.  But Apple didn't release a new system
> with the LC II (perhaps because of all the complaints about the 6.0.x
> where x got quite large) and so there is no where to get the new selector
> from.

Hmm, I don't recall that many complaints about the different versions
of 6.0.x. There were some people who had difficulty appreciating the
importance of 6.0 when that first came out (and, frankly, you couldn't
blame them). But then when 6.0.2 appeared, and the later versions, Apple's
position always seemed to be "if you're not having any problems, you don't
need to upgrade".

I guess this whole thing really proves that the LC II has the exact same
ROM as the LC, as well as running the exact same system--absolutely *nothing*
needed to change to work with the 68030 CPU! After all, if they had to
change anything for the LC II, they could have put in a new Gestalt machine
type code while they were at it. As it was, it obviously wasn't worth the
trouble.

Lawrence
not sorry he bought his LC (now 16 months old) when he did...

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 28 Apr 92 13:35:06 GMT
Organization: Kalamazoo College

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>[e-mail] (Quinn "The Eskimo!") writes:
>> I assume that the LC II
>> has the same 'universal' ROM as the LC.  In that case the value would
>> have to come from the system.  But Apple didn't release a new system
>> with the LC II (perhaps because of all the complaints about the 6.0.x
>> where x got quite large) and so there is no where to get the new selector
>> from.
>
>I guess this whole thing really proves that the LC II has the exact same
>ROM as the LC, as well as running the exact same system--absolutely *nothing*
>needed to change to work with the 68030 CPU! After all, if they had to
>change anything for the LC II, they could have put in a new Gestalt machine
>type code while they were at it. As it was, it obviously wasn't worth the
>trouble.

Well...no.  Changes to the LC ROM include support for the 030's MMU,
displaying the desktop immediately on startup, improved SANE, and
support for SwapMMUMode().  It was also modified to "allow operation
under virtual memory," and--this one's really got me wondering--"to
correct a sound allocation problem."  This is all from that same Note.

So there really isn't any excuse for keeping the same selector.  Maybe
someone forgot about it until after the ROMs were burned...?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 My coat contained a furnace where there used to be a guy...

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Wed, 29 Apr 1992 02:14:48 GMT

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
>
> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> >[e-mail] (Quinn "The Eskimo!") writes:
> >> I assume that the LC II has the same 'universal' ROM as the LC.
       ^^^^^^
This post explains where this assumption comes from.

> >I guess this whole thing really proves that the LC II has the exact same
> >ROM as the LC, as well as running the exact same system--absolutely *nothing*
> >needed to change to work with the 68030 CPU! After all, if they had to
> >change anything for the LC II, they could have put in a new Gestalt machine
> >type code while they were at it. As it was, it obviously wasn't worth the
> >trouble.
   ^^^^^^^
Do I detect a note of sacrasm here (-:

> Well...no.  Changes to the LC ROM include support for the 030's MMU,
> displaying the desktop immediately on startup, improved SANE, and
> support for SwapMMUMode().  It was also modified to "allow operation
> under virtual memory," and--this one's really got me wondering--"to
> correct a sound allocation problem."  This is all from that same Note.

I'm not sure what this proves but they both have the same ROM version
ie $067C(as reported by gestaltROMVersion).  This means one of the
following...

a) the ROMs are different a different version and gestaltROMVersion
   is lying
b) the ROMs are the same version but have been subtly bashed and
   and gestaltROMVersion has not been updated to reflect this
b) the ROMs are the same and gestaltROMVersion is correct

Now unfortunately I don't have time to spare to compare the ROMs byte by byte.
Any takers?

Regardless the whole situation is unacceptable.  The whole point of
informational selectors is to display information to the user.  If your
program asserts that a user's machine in an LC when it's really an LC II
(s)he is going to think it was programmed by a gumby.  And no sane
person is going to say "Oh it's an LC it must have Colour QuickDraw";
not nowadays anyway.

While we're (I'm) bashing the LC II I hope you're all aware that
the Apple LC EtherNet card wont work in the LC II.  I guess asking our
local reseller to be aware of this fact is a little too much to ask, right?

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who never said anything about Microsloth being sane!


+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 29 Apr 92 13:05:14 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:
>In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
>>
>> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>> >[e-mail] (Quinn "The Eskimo!") writes:
>> >> I assume that the LC II has the same 'universal' ROM as the LC.
>       ^^^^^^
>This post explains where this assumption comes from.
>
... details deleted...

I think the fact that the ROM version numbers are the same might be
because the "Universal ROM" seems to have two parts (or so I've read;
it could be wrong). The hardware-dependent ROM routines have been
separated from the higher-level calls, I think: one chip holds the
high-level routines, and these are identical in a number of the new
machines, and one chip holds anything hardware-dependent like 030 PMMU
support, etc.

This might explain why the version number of the "Universal ROM" is the
same.

- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 30 Apr 92 01:04:32 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Quinn "The Eskimo!") writes:

> I'm not sure what this proves but [the LC and LC II] both have the same ROM
> version ie $067C(as reported by gestaltROMVersion).  This means one of the
> following...
>
> a) the ROMs are different a different version and gestaltROMVersion
>    is lying
> b) the ROMs are the same version but have been subtly bashed and
>    and gestaltROMVersion has not been updated to reflect this
> b) the ROMs are the same and gestaltROMVersion is correct

The correct answer, it appears, is b) (the first b), not the second one :-)).
Every colour-capable machine since the IIci has had the same "ROM version"--
1660 decimal, or 067C hex. This is reflected in the presence of a single
PTCH resource with ID 1660, which first appeared in System 6.0.4.

And yet the system is capable of distinguishing between different versions
of this "universal" ROM--as I found out when I tried to boot System 6.0.5
on an LC.

Why did Apple give up on the ROM version ID as a means of distinguishing
between different ROMs? Who knows...

> While we're (I'm) bashing the LC II I hope you're all aware that
> the Apple LC EtherNet card wont work in the LC II.  I guess asking our
> local reseller to be aware of this fact is a little too much to ask, right?

I see. So the hack to get 68020 PDS cards to work with the 68030 isn't quite
as effective as it should have been, perchance?

Lawrence
more and more happy he bought his LC when he did.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 30 Apr 92 01:22:41 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Paul Potts) writes:
> I think the fact that the ROM version numbers are the same might be
> because the "Universal ROM" seems to have two parts (or so I've read;
> it could be wrong). The hardware-dependent ROM routines have been
> separated from the higher-level calls, I think: one chip holds the
> high-level routines, and these are identical in a number of the new
> machines, and one chip holds anything hardware-dependent like 030 PMMU
> support, etc.

Yup. There's a diagram in the "Macintosh Classic II, PowerBook Family
and Quadra Family Developer Notes", which is repeated in both the Quadra 700
and Quadra 900 chapters. This compares the ROM layout in the IIci with that
in the Quadras.

According to this diagram, the 512K ROM in the IIci is divided into
four areas: "ROM code" (if the diagram is to scale, this is about 256K
in size), "Overpatch area" (with some unused free space here), "ROM resources"
and "Declaration ROM" (for the Slot Manager?). In the Quadras, the extra
512K contains a large chunk of "New ROM code" and some "New ROM resources".
The "Declaration ROM" section is also moved so it stays at the highest
addresses.

I assume that the 512K ROMs in the IIfx, LC, IIsi and Classic II (and LC II?)
look very similar to that in the IIci. There's no diagram of the layout of
the 1MB ROM in the PowerBook 140 and 170, but that is probably similar to the
Quadras.

And the PowerBook 100, I understand, has exactly the same version 890
decimal (037A hex) ROM as ye olde Macintoshe Portable.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Date: 30 Apr 92 02:05:46 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
> In article <[e-mail]>, [e-mail] (Quinn "The Eskimo!") writes:
>
> > I'm not sure what this proves but [the LC and LC II] both have the same ROM
> > version ie $067C(as reported by gestaltROMVersion).  This means one of the
> > following...
> >
> > a) the ROMs are different a different version and gestaltROMVersion
> >    is lying
> > b) the ROMs are the same version but have been subtly bashed and
> >    and gestaltROMVersion has not been updated to reflect this
> > b) the ROMs are the same and gestaltROMVersion is correct
>
> The correct answer, it appears, is b) (the first b), not the second one :-)).

Whoops!  Lawrence wins the prize for spotting the deliberate error.

> And the PowerBook 100, I understand, has exactly the same version 890
> decimal (037A hex) ROM as ye olde Macintoshe Portable.

If you're reading the same developer notes I am then the system distinguishes
between a Portable and a PB100 by looking at some IO space in high memory
which is always clear on the Portable and set on the PB100 (or vice versa).
Kiddies, can anyone say "hack"?  How about "gross hack"?

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Even happier about his PB100 (RubberDucky) than Lawrence is about his LC.

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 1 May 92 02:27:01 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) wrote:
>
> And the PowerBook 100, I understand, has exactly the same version 890
> decimal (037A hex) ROM as ye olde Macintoshe Portable.

And I think the PowerBook 140 and 170 have the same gestalt value.

- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 7 May 92 17:52:51 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Paul Potts) writes:
>
> In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
> >Apple is apparently planning on releasing 4,294,967,000 machines pretty
> >soon, because there's obviously a shortage of values for
> >gestaltMachineType to return.
> >
>
> All that said, actually I agree with you - I think Apple should have used
> another machine type for the LC II. Unless they have so many new machines
> planned that they can't spare the bits in the machine type field... : )

  The only reason the LC II doesn't have a new machine type is so that
7.0.1 will run on it.

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.
     It wasn't MY idea...

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 7 May 1992 19:08:28 GMT

[e-mail] (Dean Yu) writes:
>
>  The only reason the LC II doesn't have a new machine type is so that
>7.0.1 will run on it.
>

Might I suggest a new series of Gestalt selectors?

gestaltFailsOnSystemVersion607 = 'S607';
gestaltFailsOnSystemVersion700 = 'S700';
gestaltFailsOnSystemVersion701 = 'S701';
etc...

They return 0 if the current machine works OK with the stated system, 1
otherwise.  Burn it into the ROM of future machines, and put the
appropriate override for old machines into future systems.

Old machines on old systems report that they always work.  That's a
trifle misleading if a program asks the hypothetical "If I reboot under
system x.x.x, will it work?" -- so programs like SystemSwitcher couldn't
completely trust it.  Not many programs ask that, though.

That way, all System 7.1 will have to do is ask itself if it runs (as
soon as the ROM overrides are installed--pretty early in the boot
sequence I imagine).
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented." - High C language reference manual, 1987

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 16:27:53 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Jamie R. McCarthy) writes:
> Well...no.  Changes to the LC ROM include support for the 030's MMU,
> displaying the desktop immediately on startup, improved SANE, and
> support for SwapMMUMode().  It was also modified to "allow operation
> under virtual memory," and--this one's really got me wondering--"to
> correct a sound allocation problem."  This is all from that same Note.
>
> So there really isn't any excuse for keeping the same selector.  Maybe
> someone forgot about it until after the ROMs were burned...?

No, as stated earlier, it was deliberately done, and we at DTS tried
to stop it, but it had to do with time-to-market and use of existing ROM
software.

Cheers,
Kent/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Mike Shoemaker)
Date: 9 May 92 02:02:24 GMT

In article <[e-mail]>, [e-mail] (Quinn "The Eskimo!") writes:
>
> While we're (I'm) bashing the LC II I hope you're all aware that
> the Apple LC EtherNet card wont work in the LC II
>
> Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
>

This is not completely true.

There is a new rev of the card that works on the LC II. OR,
if you install the software that comes in the box with the machine (Network
Software Installer 1.2), you will get a new driver in the system file that
overrides the one in ROM. The original rev card will work just fine.
(The unfortunate thing is you have to install the software BEFORE the
old card...)

A blanket statement "the LC EtherNet card does not work in the LC II" just
leads to confusion among customers.

Of course it would be nicer for everyone if the original card worked just
fine in the LC II without having to put a new driver in the LC II's system
file first with the installer, but it just didn't work out that way.

I'm just trying to clear the situation up: there is a new revision of the
card that works just fine in all LC's. If you have an older rev card and
want to move it from your LC to your LC II, you have to run a simple installer
first.

By the way, all you LC users with the original card that use MacTCP may want
to upgrade using the Network Software Installer 1.2 anyway since the new
driver also fixes a bug that shows up with some MacTCP-based programs.
(for the techo-weenies, the original LC ethernet driver allowed a small
maximum number of transmit fragments. The documentation says the transmit
fragment list can be arbitrarily long (not exceeding the max packet size),
and some MacTCP based applications make use of this feature.)

Mike Shoemaker
Apple Computer, Inc.

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

End of C.S.M.P. Digest
**********************