Using resload_Protect#?

### Brug af resload_Protect#?

#### Teori

Der er forskellige situationer i hvilke det kan være meget nyttigt at få at vide hvornår det installerede program tilgår specifikke hukommelses områder. med resload_Protect#? funktionen er det muligt at beskytte visse hukommelses områder fra processoren at læse og/eller skrive. At beskytte betyder at ethvert forsøg på at tilgå et beskyttet område vil generere en Access Fault exception som vil resultere i en passende requester af WHDLoad. Hvis du deklærer et hukommelses område som beskyttet v.h.a. resload_Protect#? funktionen vil WHDLoad modificere de berørte page descriptors i MMU'ens oversættelses træ. Nu vil CPU'en generere en Access Fault exception hver gang et beskyttet område tilgås. Exception handleren indeni WHDLoad vil verificere grunden til exceptionen. Hvis grunden var et forsøg på at tilgå en beskyttet page men tilgangen ikke matcher det beskyttede område vil tilgangen blive emuleret og den normale program eksekvering vil fortsætte. Ellers vil WHDLoad afslutte med en passende requester. Hvis adgangen var en adgng til instruktions strømmen (f.eks. CPU'en forsøger at loade kode) vil den altid blive emuleret, eller med andre ord resload_Protect#? funktionen berører kun læsning og skrivning af data. Det faktum at enhver adgang til en beskyttet side (sidestørrelsen er i øjeblikket $1000) vil generere en access fault, selv hvis det beskyttede område kun har en længde på 1 byte, resulterer i et drastisk fald i programmets eksekverings hastighed. Specielt hvis dele af koden ligger på amme side. Hvis programmet afhænger af eksekveringshastighed er der mulighed for afvigelser i eksekveringen. Så det er muligt at nogle programmer ikke vil virke med beskyttelses featuren.

#### Eksempel: checksums over kode

Hvis du installerer et program ved brug af WHDLoad er du nødt til at patche de originale loader rutiner på en måde så de bruger WHDLoad til at loade spil data. Nogle spil overvåger nogle kode områder med checksum for at kontrollere at koden ikke er modificeret. Disse overvågnings rutiner kan være svære at finde men ved hjælp af resload_Protect#? functioner i WHDLoad er der ikke noget der er nemmere end dette. Alt hvad du skal gøre er at beskytte de bytes du har ændret i koden fra at blive læst. Nu vil hver rutine der prøver at lave en checksum kontrol og læse din patchede kode generere en adgangs fejl. Og du vil vide hvor rutinerne ligger.

#### Begrænsninger

Du må ikke beskytte den hukommelses side hvor SSP'en peger hen. Hvis du gør dette vil det resultere i en Double Bus Fault fordi CPU'en ikke vil være istand til at skrive exception stackframen. Efter en Double Bus Fault er det kun muligt at lave en reset for at fortsætte eksekveringen. WHDLoad vil kontrollere om der er en konflikt af det beskyttede område og SSP'en og afslutte hvis der er. Men dette vil ikke hjælpe hvis SSP'en ændrer sig senere hen.

- 68020 + 68851
  - Denne hardware understøttes ikke i øjeblikket
- 68030
  - 3-Byte transfers er ikke understøttet og vil generere en real Access Fault, sådanne transfers vil opstå hvis et longword på en ulige addresse på en sides udkant bliver tilgået (f.eks. "`tst.l ($fff)`" hvor siden på $1000 er beskyttet), fordi dette ikke er validt på en 68000 vil du højst sandsynligt ikke se noget som dette.
  - Låste transfers forudsaget af `tas`, `cas` eller `cas2` er ikke supporteret og vil generere en real Access Fault. Dette er ikke et problem fordi låste transfers ikke er supporteret på Amiga hardware
- 68040
  - denne hardware er ikke supporteret i øjeblikket
- 68060
  - ulige data stream adgang er ikke supporteret og vil generere en real Access Fault, en ulige adgange er en adgang der spænder over 2 sider (og mindst én af dem er beskyttet). F.eks. "`tst.l ($ffe)`" berører siden $0..$fff og siden $1000..$1fff, denne begrænsning er et stort problem og kan nogle gange gøre resload_Protect featuren ubrugelig. Måske vil jeg prøve at supportere dette senere hen men det er meget vanskeligt.
  - ulige instruction stream adgange er ikke supporteret og vil generere en real Access Fault hvis begge sider er beskyttet. En sådan konstallation skulle være til at undgå
  - låste transfers der forudsages af `tas` eller `cas` er ikke supporteret og vil generere en real Access Fault. Dette er ikke et problem fordi låste transfers alligevel ikke er understøttet af amiga hardware
  - instruktioner der ligger på en beskyttet side (og derfor vil blive emuleret) og som tilgår overvågnings delen af status registret vil blive eksekveret ukorrekt. Disse instruktioner vil altid se trace bit'en som 1 og interrupt priority mask som 7. Enhver modifikation af overvågnings delen vil være uden effekt (overvågnings delen vil bevares uændret)
  - `movem` instruktion kan få adgang til et beskyttet område uden at genererere en Access Fault exception. Dette er muligt fordi kun den første adgang (word eller longword) vil blive verificeret om det matcher det beskyttede område
  - `move16` og dobbel præcisions operationer (FPU) er ikke understøttet og vil generere en real Access Fault
  - en "`move (mem),(mem)`" med overlappende kilde og base addresse som genererer en Access Fault fordi det ikke vil blive eksekveret ordentligt. For eksempel "`move.l ($ffc),($ffe)`" hvor side $1000..$1fff er beskyttet og hukommelse før eksekvering indeholder ($ffc)=$11112222, ($1000)=$33334444, efter eksekvering indeholder $1000, $11114444 og ikke $22224444