Schematische uitvoer stroom

Het volgende tabel laat de programma stroom zien wanneer een WHDLoad geïnstalleerd programma wordt uitgevoerd. Ik hoop dat dit helpt te begrijpen hoe WHDLoad werkt en hoe WHDLoad, de Slave en de geïnstalleerde programma's doet samenwerken.

De GEBRUIKER
  • start demo of het spel door het klikken van de Icoon of door het starten van WHDLoad via de commandolijn
Het Besturingssysteem
  • laad en start het WHDLoad uitvoerbare bestand
WHDLoad
  • controleert de Software en Hardware omgeving
  • laad en controleert de Slave
  • toewijzen van benodigde geheugen voor het geïnstalleerde programma
  • als Preload/S is geactiveerd laad het disk images en bestanden in het RAM (zolang vrij geheugen beschikbaar is)
  • schakelt OS uit (schakelt mutitasking en onderbrekingen uit, verlaagd grafische hardware naar OCS, initieert alle hardware met gedefineerde waarden)
  • springt in Slave
Slave
  • laad het hoofd uitvoerbare bestand van het geïnstalleerde programma door het aanroepen van een WHDLoad functie (bijv. resload_DiskLoad of resload_LoadFile)
  • patcht het hoofd uitvoerbare bestand (dat het programma zijn data laad via de Slave om compatibiliteits problemen te repareren, om een uitgang te creëren van het programma)
  • roept het hoofd uitvoerbare bestand aan
Geïnstalleerd programma
  • Doet zijn ding
  • tijdens het laden van data vanaf disk zal het de Slave aanroepen (omdat de Slave dit gepatcht heeft op deze manier de vorige keer), en de Slave zal de WHDLoad aanroepen, en WHDLoad zal gedeeltelijk de OS activeren om data te laden (alleen als de data niet Voorgeladen is), keer dan terug, keer terug en het geïnstalleerde programma word hervat
De GEBRUIKER
  • verlaat het programma door het drukken van de QuitKey
Slave
WHDLoad
  • schakelt het OS opnieuw in (hersteld hardware registers, beeldscherm en geheugen)
  • maakt alle toegewezen bronnen vrij
  • keert terug naar het OS

Hoe installeert men een simpele één disk tracklader

Dit is een kleine en korte stap voor stap handleiding hoe een install word gemaakt met WHDLoad. De handleiding reflecteert een simpel voorbeeld. In de echte wereld zal dit voorbeeld waarschijnlijk nooit voorkomen. Voor speciale voorbeelden en problemen, lees de volgende hoofdstukken die volgen.
  1. Voorbereiding
  2. De Slave
    Om de slave te schrijven hebben we de volgende informatie:
    1. Waar op de disk bevind zich het hoofd uitvoerbare bestand?
    2. Waar bevind in het hoofd uitvoerbare bestand de disk lader?
    Om deze informatie te verkrijgen moeten we eerst de bootblock analyzeren. Meestal word het hoofd uitvoerbare bestand geladen vanaf hier via exec.DoIO(). Soms is er een speciale tracklader in de bootblok. Nu schrijven we een Slave welke de bootblok zal simuleren en het hoofd uitvoerbare bestand zal laden van de disk image. Nu rippen we het hoofd uitvoerbare bestand van de image of een geheugen dump. Hierna moeten we de lader in de hoofd exe zoeken. Een snelle manier is om te zoeken naar het patroon $AAAAAAAA (gebruikt bij het MFM decoderen) met een hex-editor. Snijd dan het gevonden gebied, demonteer het, en zoek naar het begin van de routine. Begrijp de parameterlijst. Nu creëren we een code voor de Slave welke de lader routine patcht op een manier zoals alle aanroepen naar de lader doorgestuurd worden naar de Slave. De Slave zal dan de parameters instellen en de WHDLoad functie resload_DiskLoad aanroepen.
  3. In de ideale situatie is de install nu compleet.
    Het enige ding wat nog gedaan moet worden is het maken van een mooie Icoon. Rip twee plaatjes met de snoop eigenschap van WHDLoad en SP of een freezer of U.A.E. en maak het icoon. De 16 kleuren RomIcon palet is aanbevolen.

Mogelijke problemen en speciale gevallen

Niet standaard tracklader

Sommige programma's gebruiken hun eigen disk formaat. Dit betekend dat DIC geen disk images kan maken. Om bestanden of images te maken van zulke disks is het gebruik van RawDIC aan te bevelen. Zie de documentatie van RawDIC voor meer informatie.

Meerdere disks

Als het programma meer dan 1 disk gebruikt moet de slave de disk toegangen doorsturen naar de juiste image bestand. Soms is dit niet gemakkelijk. Sommige programma's ondersteunen meer dan 1 drive, zodat u de drive nummer kan gebruiken om de disk te selecteren. De meeste programma's gebruiken een ID op elke disk om ze te onderscheiden. In dit geval, gebruik een variabele welke de disk nummer bevat, en op elke toegang naar de disk ID (bepaal zo'n toegang door het analyzeren van de parameters voor de disk lader) verhoog de variabele (verlaag het wanneer de laatste disk is bereikt). Zodat hopelijk de lader de ID weer leest telkens weer tot de juiste disk is geplaatst. Misschien is er een verzoek van het programma dat de gebruiker de juiste disk moet invoeren, schakel dat uit.

Bewaren van Highscore

Er valt weinig over te zeggen. Gebruik resload_SaveFile om het geschikte geheugen gebied te schrijven naar de disk. Als u wilt, encodeer het dan zodat idioten het niet gemakkelijk kunnen patchen. Het is niet aanbevolen om direct in disk images te schrijven (gebruikmakend van resload_SaveFileOffset), omdat als er iets fout gaat (bijv. een crash) is het mogelijk dat de images beschadigd zullen raken.

Savegames

Het handelen van een Savegame is hetzelfde als met highscores.

Toegang tot het besturingssysteem

Op het moment dat de slave en het geïnstalleerde programma is uitgevoerd, bestaat er absoluut geen OS noch is het toegankelijk noch heeft het nut om toegang te zoeken! Daarom moeten alle toegangen geprobeerd door het geïnstalleerde programma uitgeschakeld zijn. Als er niet veel van zijn en ze geen nut hebben in een WHDLoad omgeving (zoals exec.Disable() of exec.SuperState()) simpelweg NOP ($4e71) ze dan. Als de toegangen een belangrijke functie hebben (zoals exec.DoIO()), stuur ze dan door naar de Slave en emuleer ze. Als er veel van zijn, creëer dan een simpele exec.library in een ongebruikt geheugen gebied. (initialiseer de lange woord op adres $4). U kunt de bron controleren voor de Oscar.slave, welke exec.AllocMem() emuleert. Om toegangen te detecteren naar de OS, is de initiële execbase ingesteld op $f0000001 met de intentie dat alle routines welke de execbase willen gebruiken, een "Adres Fout" uitzondering aanmaakt.
Als er een hevig gebruik van de OS functies is, gebruik dan 1 van de kickemu pakketten welke gevonden kunnen worden in het whdload-dev pakket. Er is 1 pakket voor Kick 1.3 ('src/sources/whdload/kick13.s') en 1 voor Kick 3.1 ('src/sources/whdload/kick31.s'). Deze pakketten hebben een originele kickstart image nodig en creëert een complete OS omgeving in de WHDLoad ruimte. Raadpleeg de juiste leesme meegeleverd voor verdere informatie

Algemene compatibiliteits problemen

Gelimiteerde adres ruimte op 68000/68010/68ec020

Op deze processors is de adres ruimte gelimiteerd tot 16 MB ($000000...$ffffff) omdat deze CPU's maar 24 adres regels bevatten. Daarom als gevolg zullen alle toegangen tot hogere adressen worden uitgevoerd naar de lagere 16 MB door het negeren van de meest significante 8 bits. Sommige programma's gebruiken deze bits om data te bewaren, of simpelweg vergeten ze te legen. Op een processor met een volle 4 gb adres ruimte zoals 68020/680ec30/68030/68040/68060 zal dit niet werken, omdat de volle 32-bit adres de toegang wordt verschaft.
Om dit probleem te verhelpen zult u deze toegangen moeten patchen en doorsturen naar de geschikte adressen.
Soms is de reden voor de toegang naar vreemde adressen een niet geinitieerde verwijzer. In dit geval kan het helpen door het verwijderen van $400 - ws_BaseMemSize.

Verschillende stackframes op elke processor

De stackframes gecreëerd door de processor bij onderbrekingen en uitzonderingen zijn verschillend voor de leden van de 68k familie. Op de 68000 is een stackframe 6 bytes, behalve bij Bus en Adres Foutmeldingen. De stackframe bevat de weggeschreven SR bij (a7) en de weggeschreven PC bij (2,a7). Op alle processors (68010+) is de minimale stackframe 8 bytes en tevens bevat het de vector bummer als een woord bij (6,a7) Deze 4-woord stackframe formaat $0 is gecreëerd voor "Trap #xx" en onderbrekingen op 68010-68060. De stackframes bij andere uitzonderingen zijn verschillend op elke processor. De RTE instructie werkt verschillend op de 68000 tegen de 68010+. Op een 68000 hersteld het simpelweg de SR en de PC en hervat de programma uitvoer bij het onderbroken adres. Op de 68010+ zal het tevens de stackframe vrij maken liggend aan het stackframe formaat.
Sommige programma's duwen een adres (PC) en een SR en dan een RTE instructie uitvoeren. Dit werkt alleen op een 68000, op een 68010+ leid dit tot ondefinieerbare resultaten.
Als een programma dit doet, dient u dit te repareren. Soms is het genoeg door de RTE om te ruilen met een RTR.

MOVEM.x RL,-(An) op 68000/010 en 68020/030/040

Er is een verschil als het register gebruikt is in predecrement mode (RL) ook bevat is in de register lijst. voor de 68020, 68030 en 68040 is de geschreven waarde naar het geheugen het initiële register waarde verlaagt door de grootte van de operatie. De 68000 en 68010 schrijven hun initiële register waarde (niet verlaagd).
Omdat zo'n dergelijke constructie niet erg handig is, geen huidige software is bekend problemen te hebben door dit.

Algemene richtlijnen voor het schrijven van installs

Tips & Truuks

Wat is beter, diskimages of bestanden?

Soms heeft u de keuze om disk images te gebruiken of echte bestanden. Beide hebben hun voordelen. Het gebruik van disk images is meestal makkelijker en sneller om een Slave te creëren. Maar echte bestanden zijn makkelijker te cachen (als er heel weinig geheugen is of als het geheugen gefragmenteerd is). De benodigde ruimte op een harde schijf is ook smaller met echte bestanden dan met disk images. U zou eigenlijk alleen disk images moeten gebruiken als er veel bestanden (meer dan 30) zijn.