mirror of
https://github.com/elliotnunn/sys7.1-doc-wip.git
synced 2024-12-12 20:29:12 +00:00
411 lines
15 KiB
Plaintext
411 lines
15 KiB
Plaintext
Patches Release Notes
|
||
First created on: 3/26/92 5:58:22 PM
|
||
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
|
||
3/26/92 5:58:32 PM
|
||
|
||
File: LinkedPatchLoader.a,54
|
||
Owner: Dean Yu
|
||
Project: MainProj∫LinkedPatches∫
|
||
|
||
File: Build,255
|
||
Owner: Dean Yu
|
||
Project: MainProj∫Make∫
|
||
|
||
File: SysObj.Make,447
|
||
Owner: Dean Yu
|
||
Project: MainProj∫Make∫
|
||
|
||
File: BootCode.a,22
|
||
Owner: Dean Yu
|
||
Project: MainProj∫OS∫StartMgr∫
|
||
|
||
File: BeforePatches.a,27
|
||
Owner: Dean Yu
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1024282
|
||
|
||
> Release notes for this change:
|
||
|
||
A Process Manager segment was being loaded high in the system heap, causing fragmentation. It
|
||
was loaded high because the linked patch blocks were in the way at boot time. We tried to alleviate
|
||
this by moving these blocks high in the heap, but that stopped working. Now we load these segments
|
||
in ‘PTCH’ 0, which is run before linked patches, so we don’t have to worry about the strange
|
||
memory setup at linked patch time.
|
||
|
||
> What was tested:
|
||
|
||
The Process Manager segments in question are loaded low, always. All the locked blocks are all
|
||
in the lower third of the system heap, which is very good for fragmentation.
|
||
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
4/9/92 6:08:35 PM
|
||
|
||
File: GestaltEqu.a,52
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫AIncludes∫
|
||
|
||
File: GestaltEqu.h,53
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫CIncludes∫
|
||
|
||
File: GestaltEqu.p,47
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫PInterfaces∫
|
||
|
||
File: Sys.r,304
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Make∫
|
||
|
||
File: GestaltFunction.a,42
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫OS∫Gestalt∫
|
||
|
||
File: GestaltPatches.a,31
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫OS∫Gestalt∫
|
||
|
||
File: PatchIIciROM.a,150
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Patches∫
|
||
|
||
File: ShutDownMgr.a,50
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Toolbox∫ShutDownMgr∫
|
||
|
||
File: SoundMgrPatch.a,25
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Toolbox∫SoundMgr∫
|
||
|
||
Radar bug: #1026795
|
||
|
||
> Release notes for this change:
|
||
|
||
As we do for the PowerBook 100, we need to change boxFlag on Macintosh LC II machines
|
||
from its original value of boxMacLC to boxMacLCII in PatchIIciROM.a. We also need
|
||
to add a new value that can be returned for gestaltMachineType, gestaltMacLCII. This has
|
||
implications
|
||
in several areas of the System. We need to add a new entry in the machine icon table
|
||
for Gestalt (the same icon as the LC) and a new string in the machine name STR# in the
|
||
System (”Macintosh LC II”), both of which show up in the Finder. We need to make sure
|
||
that Gestalt returns the same value for gestaltHasSoftPowerOff and gestaltSerialAttr
|
||
as the Mac LC. In the ShutDown Manager, we need to set the CLUT to 50% gray on a restart
|
||
as we do for an LC. In the Sound Manager, we need to expand the sound primitive vector
|
||
table
|
||
to include the LC II.
|
||
|
||
|
||
> What was tested:
|
||
|
||
On an LC II, verified that boxFlag was set correctly, verified that the right icon and
|
||
machine string appear in About This Macintosh…, verified that the CLUT was set to 50%
|
||
gray on restart, verified that sound input worked. Didn’t check the returned values for
|
||
gestaltHasSoftPowerOff and gestaltSerialAttr, though.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
4/22/92 10:46:31 AM
|
||
|
||
File: LowMemoryPrintingPatches.a,3
|
||
Owner: Dean Yu
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1012961
|
||
|
||
> Release notes for this change:
|
||
|
||
If PrintMonitor is not in the Extensions folder when you try to do background printing,
|
||
7-Up’s alert which asks the user whether he wants to print now or later because not
|
||
enough memory is available appears. Without 7-Up, Finder would report an error saying
|
||
that you need to put PrintMonitor back in the extensions folder before you can print
|
||
anything. This was a change that 7-Up introduced. They decided that if PrintMonitor
|
||
wasn’t there, they would print right away. Except that the message in the alert was
|
||
wrong. Since this code was rolled into Cube-E, we have the same problem. Change the
|
||
code so that if it couldn’t find PrintMonitor, it wouldn’t try to print immediately, and
|
||
let the Finder report the old error.
|
||
|
||
> What was tested:
|
||
|
||
Took PrintMonitor out of the extensions folder, then tried to background print from
|
||
MacWrite II to an LS. Without the change, the “Print now or later when there’s more
|
||
memory” dialog appears. With the change, the print job is spooled to the PrintMonitor
|
||
Documents folder, and the Finder brings up the notification that PrintMonitor must be put
|
||
back before any printing could be done.
|
||
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
5/13/92 4:41:34 PM
|
||
|
||
File: PatchIIciROM.a,152
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1026795
|
||
|
||
> Release notes for this change:
|
||
|
||
Mac LC II computers shipped with both version 1.9f1 and 1.9f2 ROMs. When determining
|
||
whether to set boxFlag to boxMacLCII at boot time, we should just check for the major
|
||
version ($19) instead of the whole version (previously, we were checking for $19F2).
|
||
|
||
> What was tested:
|
||
|
||
Verified that About This Macintosh still showed Mac LC II on our only LC II test machine,
|
||
which has an f2 ROM. This still needs testing on an f1 ROM as well.
|
||
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
5/14/92 2:00:29 AM
|
||
|
||
File: VideoPatch.a,10
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1029735
|
||
|
||
> Release notes for this change:
|
||
|
||
The shipping version of the Macintosh Quadra 950’s ROM (1.7F2) has a bug in the built-in
|
||
video driver which prevents the DirectSetEntries call from working correctly when the
|
||
attached display is put into 32 bit-per-pixel mode. To fix this problem, we just patch
|
||
the bad table in place since it resides in the System heap. This is a five-entry table
|
||
that needs to have six entries. We just add the sixth entry to the end. This writes over
|
||
part of the table used for the SetGrayScreen call, but that’s okay since the gray screen
|
||
call is generally only used at boot, before this patch gets installed.
|
||
|
||
|
||
|
||
> What was tested:
|
||
|
||
I wasn’t able to test this too well. I booted it on my Zydeco, but the patch didn’t fire
|
||
because the Slot Manager says there’s no driver for the on-board slot. I did prove that
|
||
the patch is harmless if it doesn’t get activated. I watched the code with Macsbug and
|
||
the patch exits cleanly.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
5/28/92 9:53:29 AM
|
||
|
||
File: MiscPatches.a,59
|
||
Owner: hae-sung Kim
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1030902
|
||
|
||
> Release notes for this change:
|
||
|
||
Included DictionaryEqu.a file for DictionaryDispatch.
|
||
|
||
> What was tested:
|
||
|
||
Compiled and tested with input method.
|
||
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
6/2/92 9:21:59 PM
|
||
|
||
File: GestaltEqu.a,55
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫AIncludes∫
|
||
|
||
File: GestaltEqu.h,56
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫CIncludes∫
|
||
|
||
File: GestaltEqu.p,50
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Interfaces∫PInterfaces∫
|
||
|
||
File: InternalOnlyEqu.a,22
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Internal∫Asm∫
|
||
|
||
File: Sys.r,317
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Make∫
|
||
|
||
File: GestaltPatches.a,33
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫OS∫Gestalt∫
|
||
|
||
File: PatchIIciROM.a,153
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Patches∫
|
||
|
||
File: ShutDownMgr.a,51
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Toolbox∫ShutDownMgr∫
|
||
|
||
File: SoundMgrLowLevel.a,32
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Toolbox∫SoundMgr∫
|
||
|
||
File: SoundMgrPatch.a,27
|
||
Owner: Jeff Miller
|
||
Project: MainProj∫Toolbox∫SoundMgr∫
|
||
|
||
Radar bug: #1031451
|
||
|
||
> Release notes for this change:
|
||
|
||
As we do for the PowerBook 140, we need to change boxFlag on PowerBook 145 machines from
|
||
its original value of boxPowerBook170 to boxPowerBook145 in PatchIIciROM.a. We also need
|
||
to add a new value that can be returned for gestaltMachineType, gestaltPowerBook145.
|
||
This has implications in several areas of the System. We need to add a new entry in the
|
||
machine icon table for Gestalt (the same icon as the PowerBook 140) and a new string in
|
||
the machine name STR# in the System (”PowerBook 140.” for now, until we announce the
|
||
machine (the period at the end will let you tell the difference in the meantime)), both
|
||
of which show up in the Finder. In the ShutDown Manager, we need to close the video
|
||
driver at shutdown or restart as we do for the 140 and 170. In the Sound Manager, we need
|
||
to expand the sound primitive vector table to include the 145, and fool the Gestalt
|
||
attribute table into thinking a 145 is really a 140.
|
||
|
||
> What was tested:
|
||
|
||
On a PowerBook 145, verified that boxFlag was set correctly, verified that the right icon
|
||
and machine string appear in About This Macintosh…, verified that playing a sound and
|
||
sound input worked.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
6/11/92 9:37:39 PM
|
||
|
||
File: BeforePatches.a,30
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1032330
|
||
|
||
> Release notes for this change:
|
||
|
||
When parameter RAM gets reset (Cmd-Option-P-R during boot), the value for SPConfig gets
|
||
set to zero. The value from PRAM gets copied into the low-memory global SPConfig when the
|
||
machine starts up.
|
||
|
||
A value of 1 means use AppleTalk. 2 means use asynchronous serial. The value of zero is
|
||
undefined. In System 7 and before, the Chooser would assume AppleTalk was on if the value
|
||
was zero. The System 7 Tune-Up assumed zero meant AppleTalk was off and this caused a
|
||
number of problems. The factories and the hardware teams would like zero to mean
|
||
AppleTalk is on.
|
||
|
||
To reproduce this bug:
|
||
Choose Restart
|
||
Before the Happy Mac appears, press and hold Command-Option-P-R until the Mac plays the
|
||
boot beep a second time
|
||
Let go of the keys.
|
||
When the Finder is up, select the Chooser from the Apple Menu.
|
||
|
||
Result:
|
||
AppleTalk is off and the Mac needs to be restarted to make AppleTalk active.
|
||
|
||
Part of the solution is in AppleTalk 57.0.4GM. If SPConfig is zero, they set it to 1,
|
||
turning AppleTalk on, mostly. However, the System will have already recorded the fact
|
||
that SPConfig was zero and marked a flag in ExpandMem to indicate the AppleTalk is off.
|
||
Many parts of the System, including the Chooser, use this flag to decide that AppleTalk
|
||
is off.
|
||
|
||
There are two changes to the System to fix this. First, the code which sets the flag in
|
||
ExpandMem should treat zero as AppleTalk active. Second, the code that prevents the
|
||
AppleTalk driver from getting opened should be removed. This code is obsolete anyway
|
||
since AppleTalk 57.0.4 does the right thing.
|
||
|
||
> What was tested:
|
||
|
||
I zapped PRAM during boot and verified that AppleTalk was on by opening the Chooser and
|
||
mounting a server. I also checked Sharing Setup.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
6/17/92 2:54:13 PM
|
||
|
||
File: PatchIIciROM.a,155
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1032863
|
||
|
||
> Release notes for this change:
|
||
|
||
The boxFlag for the PowerBook 145 needs to be set by software when the machine boots
|
||
since the hardware sets it to the boxFlag for a 170 (since the 140, 145, and 170 all
|
||
share the same basic hardware and ROM). The original attempt to distinguish between a 140
|
||
and a 145 used the current processor speed: if the processor was running at 25MHz, then
|
||
it was a 145, otherwise it was a 140.
|
||
|
||
This doesn’t work because the 145 has a power-saving mode where it will run at 16MHz.
|
||
This caused the code to think it was a 140.
|
||
|
||
The solution was to check the maximum processor speed instead of the current processor
|
||
speed. Now the code successfully identifies a 145 whether it’s running at 16MHz or 25MHz.
|
||
|
||
> What was tested:
|
||
|
||
I booted the 145 and checked boxFlag with Macsbug and About This Macintosh… to make sure
|
||
it said 145. Then I changed to power-saver (16MHz) mode and rebooted. During boot I
|
||
verified that the processor was running at 16MHz. The software still correctly identified
|
||
the machine as a 145.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
6/22/92 7:05:54 PM
|
||
|
||
File: PatchIIciROM.a,156
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1033336
|
||
|
||
> Release notes for this change:
|
||
|
||
Because of a hardware bug in the 140 ROM, the Power Manager thinks the maximum processor
|
||
speed of the 140 is 25MHz. So the code to distingish between the 140 and the 145 thinks
|
||
that both are 145s.
|
||
|
||
The fix is to check the hardware register directly. We’re still using maximum processor
|
||
speed as the determinant
|
||
|
||
> What was tested:
|
||
|
||
The 140 now thinks it’s a 140. I didn’t test the 145 yet because there’s only one in the
|
||
building and the wonderful folks in SQE have it.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
7/5/92 2:03:56 AM
|
||
|
||
File: UniversalEqu.a,26
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Internal∫Asm∫
|
||
|
||
File: PatchIIciROM.a,157
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1033139
|
||
|
||
> Release notes for this change:
|
||
|
||
The Cuda version of the firmware for the Egret chip doesn’t need the patches from
|
||
PatchIIciROM.a. So I added a check to see if we have Cuda or later firmware and skipped
|
||
the patches if so. The change came from the hardware folks since they’re working with the
|
||
new Egret chips on some of the upcoming CPUs.
|
||
|
||
I also added the constants for the masks and values for the Egret firmware.
|
||
|
||
> What was tested:
|
||
|
||
I couldn’t do much since I don’t have a machine with Cuda firmware. However, I did
|
||
examine the code with Macsbug to make sure that everything was as expected.
|
||
----------------------------------------------------------•----------------------------------------------------------
|
||
7/7/92 12:41:38 AM
|
||
|
||
File: PatchIIROM.a,93
|
||
Owner: Chris Derossi
|
||
Project: MainProj∫Patches∫
|
||
|
||
Radar bug: #1012754
|
||
|
||
> Release notes for this change:
|
||
|
||
There’s an old bug in the patches for Mac II class machines that causes VM and 32-bit
|
||
mode to not work. During patch time, we nuke the slot VBL queue and move it to a new
|
||
location using updated routines. However, we weren’t clearing the low-memory global for
|
||
the VBL queue.
|
||
|
||
I added the code to set the low-memory global SlotVBLQ to -1 right after the old queue
|
||
header gets disposed. This tell the rest of the software to use the new VBL stuff.
|
||
|
||
> What was tested:
|
||
|
||
I wasn’t able to do any testing on this because I’m just adding the code at the request
|
||
of MHD. I’m not sure what the specific effect of this change will be, so I’m relying on
|
||
Dallas to do the appropriate tests.
|
||
----------------------------------------------------------•----------------------------------------------------------
|