SystemPatch 3.0

[ziosante]

I've assembled a new version of SystemPatch, added some new patches from last public release.
This version must be considered beta.
Read included doc to know what's new in this version.
Maybe someone can find this software useful yet.

[Shoonay]

Cool, ziosante! Thanks!
Not to mention hello&welcome to EAB!

I'll try it soon, when merging KG's WHD pack with mine that's already on the HD.
One of very few patches I use, that actually do something good, and don't hang me Amy.

[killergorilla]

Sorry to be thick, but what is it?

[Shoonay]

It's a System Patch, silly KG

Home Page

---=== EDITED ===---

From the FAQ (inside the archive)

It's merely a try to implement a patch that could group part of known patches
for 68k Amigas, with some implemented by me.
A sort of "all in one" patch.

A *GREAT* "try" if I say so meself!

[Charlie]

Wooo-Hooo!!!

[ppill]

Thanks! One of my favorite patches.

[alexh]

Could you post it to the Aminet?

I'll only forget where to find it otherwise.

Thanks

[ziosante]

I'll post SystemPatch to the Aminet soon.

[DamienD]

Hello ziosante,

Thanks for your patch

Maybe you can offer some advise / information in this thread: SystemPatch3 - WHDLoad preload incompatible?

[alexh]

Originally Posted by wepl

It seems that TLSF returns 2,018,011,950 for AvailMem(MEMF_LARGEST).
Which causes that nothing is preloaded because WHDLoad uses this to calculate the puddle size for the memory pools used for the PreLoad memory.

Which version of TLSF did you use? 1.4?

There was a bug in AvailMem(MEMF_LARGEST) according to the changelog.

Originally Posted by planton42

History
~~~~~~~
V1.4 (22-Oct-07):
  - Fixed enforcer hit (memory write to 8) reported by Bernd Rösch.
  - Fixed TLSF memory being counted multiple times, if the original mem
    header was present for AvailMem(MEMF_TOTAL).
  - Fixed a slight inaccuracy for AvailMem(MEMF_LARGEST) if there were
    multiple blocks of the same category or multiple TLSF memory headers.
  - When eating a memory header, random MEMF flags were used. Fixed.
  - When converting memory headers and the TLSF Mem header is at the end
    of the original memory header, it will shrink the original one to
    remove the overlap.
  - AllocatorBenchmark was broken and would always use MEMF_CLEAR.
  - SaferPatches, PatchControl and (probably) SetMan would crash TLSFMem
    if started before, because they would try to allocate memory while
    TLSFMem calls SetFunction to modify the allocation routine, even before
    it could store the old function pointers itself. Hence, SaferPatches
    would call the patched TLSF pointer for memory, and TLSF would call
    a NULL pointer for legacy memory routines.
    To fix this catch22, TLSFMem now also implements the very last legacy
    routines Allocate() and Deallocate() itself.
  - TLSFMem would crash when run in ROM space, because it tried to save the
    old SetFunction() pointers in its code. Now that it doesn't call legacy
    routines anymore, this is fixed. However, TLSFMemPool still needs to
    store the old function pointers -- When run as resident TLSFMemPool
    will not patch memory pool functions.
  - Fixed some glitches in CreatePool() when running out of memory.
  - MEMF_CLEAR memory clearing now happens outside of Forbid state.
  - Fixed some evil glitches in AllocAbs() which could cause aligned memory
    allocations operations to fail when memory got fragmented. This could
    also explain why PowerUP programs refused to run.
  - Enabled minimum sanity check on FreeMem() for correct size parameter.
    Will recoverably GURU with $715F0041 when mismatch is detected.

[ziosante]

TLSF has some evident bug with the AvailMem(MEMF_LARGEST) function.
I'll do some debug and try to see if I can fix the problem.

[PeterK]

Originally Posted by ziosante

TLSF has some evident bug with the AvailMem(MEMF_LARGEST) function.
I'll do some debug and try to see if I can fix the problem.

Hi Sante !

The problem with AvailMem is, that TLSFMem doesn't like memblocks with a
size larger than 2 GBytes, because unfortunately it works with signed longs
and uses the wrong condition-codes for its branches. Thus every memblock
with 2 GByte or more is treated as a negative number and causes crashes!

One remark according IconBeFast v1.16 in systempatch 3.0:
There is some part of the documentation which belongs to the icon.library patch v2.0x in your systempatch.guide. It's not true that v1.16 has a colormap cache like v2.0x and that also means it's just about 4 times faster with icon loading and not 6 times.
Further, could you make a short note that the users of your patch collection won't need TagLiFE anymore in their startup-sequence, just to avoid patching the same functions twice.

But anyway, thanks a lot for your systempatch, I still use it