[Main] [Docs] [Installs] [Search] [Team] [Guestbook] [Links]

Schematisch uitvoeren doorloop

Het volgende tabel laat het programma doorloop 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 het 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
  • laadt en controleert de Slave
  • toewijzen van benodigde geheugen voor het geÔnstalleerde programma
  • als Preload/S is geactiveerd laad het diskimages en bestanden in het RAM (zolang vrij geheugen beschikbaar is)
  • schakelt het besturingsysteem uit (schakelt multitasking en interrupts uit, verlaagt 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 de vorige keer dit gepatcht heeft), en de Slave zal de WHDLoad aanroepen, en WHDLoad zal gedeeltelijk het besturingssyteem activeren om data te laden (alleen als de data niet Voorgeladen is), keert dan terug en het geÔnstalleerde programma wordt hervat
De GEBRUIKER
  • verlaat het programma door het drukken van de QuitKey
Slave
WHDLoad
  • schakelt het besturingssysteem opnieuw in (hersteld hardwareregisters, beeldscherm en geheugen)
  • maakt alle toegewezen bronnen vrij
  • keert terug naar het besturingssysteem

Hoe installeert men een simpele ťťn disk tracklader

Dit is een kleine en korte stap voor stap handleiding hoe een install wordt gemaakt voor een niet-DOS demo/game 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 disklader?
    Om deze informatie te verkrijgen moeten we eerst de bootblock analyseren. Meestal word vanaf hier via exec.DoIO() het hoofd uitvoerbare bestand geladen. Soms is er een speciale trackloader in de bootblock. Nu schrijven we een Slave welke de bootblok zal simuleren en het hoofd uitvoerbare bestand zal laden van de diskimage. Nu rippen we het hoofd uitvoerbare bestand van de image of een geheugen dump. Hierna moeten we de lader in de hoofd exe bestand 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.
    Een ding wat nog gedaan moet worden is het maken van een mooie Icoon. Rip twee plaatjes met de snoop functie van WHDLoad en SP of gebruik een freezer of ťťn of andere van U.A.E. om plaatjes uit te pakken 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 diskimages 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 ťťn disk gebruikt moet de slave de disk toegangen doorsturen naar het juiste image bestand. Soms is dit niet gemakkelijk. Sommige programma's ondersteunen meer dan ťťn 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 analyseren van de parameters voor de disklader) 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 diskimages 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 opgestart, bestaat er absoluut geen besturingssysteem noch is het toegankelijk noch heeft het nut om toegang te zoeken! Daarom moeten alle geprobeerde toegangen 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 longword op adres $4). U kunt de bron controleren voor de Oscar.slave, welke exec.AllocMem() emuleert. Om toegangen te detecteren naar het besturingssysteem, 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 besturingssysteem-functies is, gebruik dan ťťn van de kickemu pakketten welke gevonden kunnen worden in het whdload-dev pakket. Er is ťťn pakket voor Kick 1.3 ('src/sources/whdload/kick13.s') en ťťn voor Kick 3.1 ('src/sources/whdload/kick31.s'). Deze pakketten hebben een originele kickstartimage nodig en creŽert een complete besturingssysteem omgeving in de WHDLoad ruimte. Raadpleeg de juiste readme 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 processors 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 4gb adres ruimte zoals 68020/680ec30/68030/68040/68060 zal dit niet werken, omdat de volle 32-bit adressen van de toegangen worden 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 geÔnitieerde pointer. 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 voor 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 word bij (6,a7) Deze 4-word 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 vergeleken met 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 onverwachte 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-68060

Er is een verschil als het register gebruikt is in predecrement mode (RL) en ook bevat is in de registerlijst. voor de 68020-68060 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 hierdoor.

Algemene richtlijnen voor het schrijven van installs

Tips & Trucs

Wat is beter, diskimages of bestanden?

Soms heeft u de keuze om diskimages te gebruiken of echte bestanden. Beide hebben hun voordelen. Het gebruik van diskimages 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 diskimages. U zou eigenlijk alleen diskimages moeten gebruiken als er veel bestanden (meer dan 30) zijn.
[Main] [Docs] [Installs] [Search] [Team] [Guestbook] [Links]