Programmeren van WHDLoad

[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	terugkeer naar WHDLoad door het aanroepen van resload_Abort
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.

Voorbereiding
- Maak een lade welke alle bestanden bevat.
- Creëer een diskimage met DIC in deze lade.
- Creëer een #?.info bestand met "WHDLoad" als <Standaard Programma> en een Tooltype "SLAVE=#?" die de naam van de slave bevat. (of kopieer simpelweg het icoon van een voorbeeld Install en schakel alle tooltypes uit behalve "SLAVE=").
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.
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

Wijzig niet CPU registers aanwezig in hogere processors zoals VBR of CACR. De VBR is altijd 0 vanuit het zicht van de Slave programmeur, ook wanneer het verschoven is omdat Auto Vectors (en Traps wanneer de Flag WHDL_EmulTrap is ingeschakeld) zijn geëmuleerd. De bits in de CACR zijn verschillend voor elke processor. Er is maar één geldige manier om de caches te wijzigen, gebruik resload_SetCACR/SetCPU en de bitdef's van 'exec/execbase.i' en 'whdload.i'. Ook alle dingen aanwezig in het te installeren programma die botsen met deze registers moeten uitgeschakeld of overgeslagen worden, Anders kan WHDLoad niet correct werken!
Wijzig nooit diskimages. Dat heeft het voordeel dat als iemand wenst een programma te starten van een floppy, dan hoeft diegene alleen maar de images terugschrijven naar een disk (aangenomen dat het programma draait zonder verschillende fixes, wat niet vaak gebeurd).
Gebruik nooit originele dingen van het programma direct in de slave (kopieerrechten probleem).
Schakel de Caches alleen in als u zeker bent dat het draait op alle processors.
Gebruik zo weinig mogelijk geheugen als mogelijk voor ws_BaseMemSize. Sommige mensen hebben ingesloten tags op het eind van het chipgeheugen, dus helpt het om alleen $1f0000 in plaats van $200000 te gebruiken en WHDLoad absolute toegewezen geheugen te gebruiken.

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]