### Gebruik van resload_Protect#?

#### Theorie

Er zijn verschillende situaties waarin het handig kan zijn om geïnformeerd te worden wanneer een geïnstalleerd programma toegang maakt tot bepaalde specifieke geheugen locaties. Met de resload_Protect#? functies is het mogelijk om bepaalde geheugen locaties te beschermen tegen het lezen en/of schrijven door de processor. Bescherming betekent dat elke toegang aan zo'n beschermd gebied, wanneer uitgevoerd, het een Toegangs Fout uitzondering maakt wat een geschikte requester geeft door WHDLoad. Als u een geheugen gebied aangeeft als beschermd met de resload_Protect#? functie zal WHDLoad de betrokken page descriptors in de MMU vertaal boom aanpassen. Nu zal bij elke toegang naar de beschermde page de CPU een Toegangs Fout uitzondering maken. De uitzondering handler in WHDLoad zal de reden nakijken voor de uitzondering. Als de reden een toegang was naar een beschermde page maar de toegang niet hetzelfde is zal er een emulatie van de toegang plaatsvinden, en de normale programma uitvoer gaat verder door. Anders zal WHDLoad stoppen met een geschikte requester. Als de toegang er één was naar de instructie stroom (ofwel de cpu probeert code te laden) zal het altijd geëmuleerd worden, of met andere woorden de resload_Protect#? functies hebben alleen effect op het lezen en schrijven van data. Het feit is dat alle toegangen naar een beschermde page (pagegrootte is momenteel $1000) een Toegangs Fout maken, zelfs als het beschermde gebied een grootte heeft van 1 byte, met als gevolg een sterke vertraging van de uitvoerbare snelheid van een programma. Vooral als delen van de code gelegen zijn op dezelfde page. Als het programma afhankelijk is van de uitvoer snelheid, zijn verschillen in uitvoer mogelijk. Dus het is mogelijk dat sommige programma's niet werken met de bescherm eigenschap.

#### Voorbeeld: checksommen over code

Als u een spel installeert met WHDLoad moet u de originele lader routines patchen in het spel op een manier zodat WHDLoad de speldata laad. Sommige spellen voeren checksommen uit op bepaalde code gebieden om te zoeken of de originele code gewijzigd is. Deze detectie routines kunnen soms moeilijk te vinden zijn. Maar met de resload_Protect#? functies in WHDLoad is er niks makkelijker dan dit. U hoeft alleen de bytes te beschermen die u heeft veranderd in de spelcode tegen lezen. Nu elke routine welke probeert om een checksom te maken en de gepatchte code te lezen zal een Toegangs Fout geven. En u zal komen te weten waar de routine zich bevind.

#### Beperkingen

U moet niet de geheugen page beschermen waar de SSP naar toeverwijst. Wanneer u dat wel zou doen en een Uitzondering ontstaat, zal het gevolg een Dubbele Bus Fout geven omdat de CPU onmogelijk de stackframe uitzondering kan schrijven. Na een Dubbele Bus Fout kan alleen met een reset de uitvoer hervatten. WHDLoad controleert op een conflict in het beschermde gebied met de SSP en beëindigd zonodig, maar dit helpt niet als de SSP verandert later.

- 68020 + 68851
  - deze hardware word momenteel niet ondersteund
- 68030
  - 3-Byte overdrachten worden niet ondersteund en veroorzaken een reële Toegangs Fout, Zulke overdrachten ontstaan wanneer er toegang wordt gezocht naar een lange woord op een oneven adres op een page grens (bijv. "`tst.l ($fff)`" waar de page op $1000 is beschermd), omdat dit ongeldig is op een 68000 zal u dit waarschijnlijk nooit te zien krijgen
  - gesloten overdrachten veroorzaakt door `tas`, `cas` of `cas2` worden niet ondersteund en veroorzaakt een reële Toegang Fout, dit is geen probleem omdat gesloten overdrachten niet ondersteund worden door Amiga's hardware.
- 68040
  - deze hardware word momenteel niet ondersteund
- 68060
  - verkeerd gepositioneerde data stroom toegangen worden niet ondersteund en veroorzaken een reële Toegangs Fout. Een verkeerd gepositioneerde toegang is een toegang welke 2 page's bevat (en tenminste 1 ervan is beschermd), bijvoorbeeld "`tst.l ($ffe)`" beinvloed de page $0..$fff en de page $1000..$1fff, deze beperking is een groot probleem en maakt de resload_Protect eigenschap soms bijna onbruikbaar, misschien zorg ik later voor ondersteuning hiervoor maar het is moeilijk
  - verkeerd gepositioneerde instructie stroom toegangen worden niet ondersteund en veroorzaakt een reële Toegangs Fout wanneer beide page's beschermd zijn, het beste is om zo'n situatie te vermijden
  - gesloten overdrachten veroorzaakt door `tas` of `cas` worden niet ondersteund en veroorzaakt een reële Toegangs Fout, dit is geen probleem omdat gesloten overdrachten niet ondersteund worden door Amiga's hardware.
  - instructies welke liggen op een beschermde page (en daarom geëmuleerd worden) en toegang zoeken op de supervisor gedeelte van de status register worden incorrect uitgevoerd, deze instructies zullen altijd de trace bit als 1 zien en de interrupt prioriteiten mask als 7, een wijziging in de supervisor gedeelte zal geen effect hebben (ofwel de supervisor gedeelte blijft onveranderd)
  - de`movem` instructie kan toegang krijgen tot een beschermd gebied zonder een Toegangs Fout uitzondering te maken, dit is mogelijk omdat de eerste toegang (woord of lange woord) word gecontroleerd of het beschermde gebied overeenstemt
  - de`move16` en dubbele precisie operaties (FPU) worden niet ondersteund en veroorzaakt een reële Toegangs Fout
  - een "`move (mem),(mem)`" met overlappende bron en bestemmingsadres welke een Toegangs Fout genereerd omdat verkeerd gepositioneerd, incorrect word uitgevoerd. bijvoorbeeld "`move.l ($ffc),($ffe)`" waar page $1000..$1fff is beschermd en geheugen voor het uitvoer bevat ($ffc)=$11112222, ($1000)=$33334444, na uitvoer $1000 bevat $11114444 en niet $22224444