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