Macintosh-SW/mac-rom
1
0
Fork 0
mirror of https://github.com/elliotnunn/mac-rom.git synced 2024-12-22 23:29:27 +00:00
Code Issues Projects Releases Wiki Activity
0e4a082eb4
mac-rom/LinkedPatches/LinkedPatches Release Notes

150 lines
5.3 KiB
Plaintext
Raw Normal View History

Bring in CubeE sources Resource forks are included only for .rsrc files. These are DeRezzed into their data fork. 'ckid' resources, from the Projector VCS, are not included. The Tools directory, containing mostly junk, is also excluded.
2017-09-17 09:09:04 +00:00
LinkedPatches Release Notes
First created on: 3/26/92 5:57:47 PM
----------------------------------------------------------<2D>----------------------------------------------------------
3/26/92 5:57:54 PM
File: LinkedPatchLoader.a,54
Owner: Dean Yu
Project: MainProj<6F>LinkedPatches<65>
File: Build,255
Owner: Dean Yu
Project: MainProj<6F>Make<6B>
File: SysObj.Make,447
Owner: Dean Yu
Project: MainProj<6F>Make<6B>
File: BootCode.a,22
Owner: Dean Yu
Project: MainProj<6F>OS<4F>StartMgr<67>
File: BeforePatches.a,27
Owner: Dean Yu
Project: MainProj<6F>Patches<65>
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 <20>PTCH<43> 0, which is run before linked patches, so we don<6F>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.
----------------------------------------------------------<2D>----------------------------------------------------------
4/4/92 9:44:14 AM
File: LinkedPatchLoader.a,55
Owner: Fred Monroe
Project: MainProj<6F>LinkedPatches<65>
Radar bug: #1024666
> Release notes for this change:
Made Linked patches more memory friendly so that we can boot in low memory conditions. The <20>lpch<63> resources are moved above the boot globals (MemTop/2 + 1k) during the linkpatch loading. After this time MemTop is reset and the copied resources disappear.
> What was tested:
Booted a 2 meg machine with and without VM turned on. Walked through the process in macsbug.
----------------------------------------------------------<2D>----------------------------------------------------------
4/6/92 5:04:53 PM
File: LinkedPatchLoader.a,56
Owner: Dean Yu
Project: MainProj<6F>LinkedPatches<65>
Radar bug: #1024666
> Release notes for this change:
Linked Patch INITs were broken with the last change because D4 was not being initialized. Fix this
up and added judicious comments that Fred was too whipped to add because his ride was here.
> What was tested:
Kenny<EFBFBD>s TSM INIT was crashing because of this bug. With this fix, his INIT boots successfully. Also
stepped through the system boot to make sure all the linked patches got copied to the right place,
and MemTop was being restored afterwards.
----------------------------------------------------------<2D>----------------------------------------------------------
4/8/92 6:13:49 PM
File: LinkedPatchLoader.a,58
Owner: Dean Yu
Project: MainProj<6F>LinkedPatches<65>
Radar bug: #1026928
> Release notes for this change:
Changed linked patch loader so that it will be able to get linked patch resources out of ROM. Before
loading each <20>lpch<63> resource, see if CurMap is 1. If it is, set ROMMapInsert to true to get the
resource from ROM. ROM Gibblies will know to set CurMap to 1 before calling the linked patch
loader.
> What was tested:
Changed CurMap to 1, and watched linked patch loader set ROMMapInsert to true before getting an
<EFBFBD>lpch<EFBFBD> resource. Of course, since there are no linked patches in ROM on a IIci, the machine bombed
very shortly afterwards. But that wasn<73>t the point of this change.
----------------------------------------------------------<2D>----------------------------------------------------------
4/30/92 2:50:28 PM
File: LinkedPatchLoader.a,59
Owner: Dean Yu
Project: MainProj<6F>LinkedPatches<65>
Radar bug: #1023455
> Release notes for this change:
The check in the hasTerror runtime conditional to check for Horror ROMs was looking at
the wrong offset into the ROM header. It was looking at decimal offset 14 instead of hex
offset 14. Change the code to use the correct offset.
> What was tested:
The implication of this bug was that non of the Terror only linked patches were being
loaded on Horror ROM based machines, like Vail. With the change, these patches are now
loaded.
----------------------------------------------------------<2D>----------------------------------------------------------
6/3/92 10:34:40 AM
File: LinkedPatchLoader.a,60
Owner: Dean Yu
Project: MainProj<6F>LinkedPatches<65>
Radar bug: #1026928
> Release notes for this change:
Change <58> sets ROMMapInsert to true if CurMap is 1 so that linked patches in ROM would
be possible. However, the if the Resource Manager sees 1 in CurMap, and that
ROMMapInsert was true, it will reset CurMap to be SysMap when leaving the Resource
Manager call. This makes subsequent checks of CurMap invalid. Instead of doing this,
save CurMap in a register before getting any <20>lpch<63> resources, and compare that against 1
to determine if ROMMapInsert needs to be set before getting a linked patch resource.
> What was tested:
Slammed 1 into CurMap, and watched the code that loads all linked patch resources try to
get them from ROM instead of from the system file. Of course, it didn<64>t find any, and
crashed, but it was looking in ROM all the time which was the whole point of this
exercise.
----------------------------------------------------------<2D>----------------------------------------------------------
Reference in New Issue Copy Permalink