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

Skematisk eksekveringsforløb

Den følgende tabel viser programforløbet når et WHDLoad- installeret program vil blive eksekveret. Jeg håber, at det hjælper til at forstå, hvordan WHDLoad virker og hvordan WHDLoad, Slaven og det installerede program samarbejder.

BRUGEREN
  • starter demoen eller spillet ved at klikke på et ikon eller ved at starte WHDLoad via commandpromptet
Operativsystemet
  • loader WHDLoad's eksekverbare fil og starter den
WHDLoad
  • checker Software- og Hardwaremiljøet
  • loadser og checker Slaven
  • allokerer den påkrævede hukommelse til det installerede program
  • hvis Preload/S er aktiveret, loader den disk images og filer ind i RAM'en (så vidt som fri hukommelse er tilgængelig)
  • slår OS'et fra (deaktiverer multitasking og interrupts, degraderer grafikhardware til OCS, initialiserer al hardware med definerede værdier)
  • hopper ind i Slaven
Slave
  • loader den primære eksekverbare fil fra det installerede program ved at kalde en WHDLoad-funktion (f.eks. resload_DiskLoad eller resload_LoadFile)
  • patcher den primære eksekverbare fil (således at programmet vil loade sine data via Slaven, for at udbedre kompatibilitetsproblemer, og for at aktivere en udgang fra programmet)
  • kalder den primære eksekverbare fil
Installeret program
  • vil foretage sine sager
  • ved indlæsning af data fra disk vil den kalde Slaven (fordi Slaven har patchet den på den måde forinden), Slaven vil kalde WHDLoad, og WHDLoad vil delvist aktivere enable OS'et for at loade dataenea (kun hvis dataene ikke er Preload'et), derefter returnere, returnere og det installerede program fortsætter
BRUGEREN
  • forlader programmet ved at taste QuitKey
Slaven
WHDLoad
  • genaktiverer OS'et (gendanner hardware-registre, display og hukommelse)
  • frigør alle allokerede resourcer
  • returnerer til OS'et

Hvordan man installere en simpel enkeltdisk trackloader

Dette er en meget lille og kort trin for trin-guide om, hvordan man opretter en install for en NDOS demo/et NDOS spil vha. WHDLoad. Guiden reflekterer et ideelt, simpelt tilfælde. I den virkelige verden ville et sådant tilfælde formentlig aldrig finde sted. Vedr. specielle tilfælde og problemer, læs da de kapitler der følger efter dette.
  1. Forberedelse
  2. Slaven
    For at skrive Slaven har vi brug for følgende information:
    1. Hvor på disken er den primære eksekverbare fil placeret?
    2. Hvor inden i den primære eksekverbare fil er diskloaderen placeret?
    For at få denne information analyserer vi først bootblokken. I de fleste tilfælde vil den primære eksekverbare fil blive indlæst her fra exec.DoIO(). Sommetider er der en speciel trackloader i bootblokken. Vi skriver nu en Slave, der vil simulere bootblokken og indlæse den primære eksekverbare fil fra diskimaget. Nu trækker vi den primære eksekverbare fil ud af imaget eller et hukommelsesdump. Efter dette er vi nødt til at finde loaderen i den primære exe. En hurtig måde er at søge efter mønsteret $AAAAAAAA (brugt af MFM-dekodningen) med en hex-editor. Skær derefter området med (+/- $1000 bytes) fundet, disassemble det, og søg efter starten på rutinen. Forstå parameterlisten. Nu kan vi oprette kode til Slaven, hvilket vil patche denne loaderrutine på en måde der gør, at alle kald til loaderen vil blive omdirigeret til Slaven. Slaven vil derefter justere parametrene og kalde WHDLoad-funktionen resload_DiskLoad.
  3. I det ideelle tilfælde er install'en nu fuldført.
    én ting, der mangler at blive gjort, er at oprette et nydeligt ikon. Træk to billeder ud vha. snoop-funktionen fra WHDLoad og SP eller benyt en freezer eller én eller anden form for UAE til at udtrække billeder og bygge ikonet op. Den 16-farvede RomIcon palette anbefales.

Mulige problemer og specielle tilfælde

Ikke-standard trackloader

Nogle programmer bruger deres eget unikke diskformat. Dette betyder, at DIC ikke er i stand til at oprette de pågældende disk-images. For at oprette filer eller images fra sådanne diske, anbefales brugen af RawDIC. Se dokumentationen til RawDIC for mere information.

Flere diske

Hvis programmet bruger mere end én disk, må Slaven omdirigere disktilgangene til den korrekte imagefil. Sommetider er dette ikke nemt. Nogle programmer understøtter mere end é drev, så du kan bruge disknummeret til a vælge disken. De fleste programmer benytter en ID på hver disk for at skelne imellem dem. Brug i dette tilfælde en variabel, der indeholder disknummeret, og ved hver tilgang til disk-ID'et (fastslå en sådan tilgang ved at analysere parametrene for diskloaderen), inkrementér variablen (hvis den sidste disk er nået, så dekrementér den). Så vil loaderen forhåbentlig læse ID'et igen og igen op til det punkt, hvor den korrekte disk er sat i. Måske er der en forespørgsel fra programmet om, at brugeren skal indsætte den korrekte disk; deaktivér dette.

Gemning af Highscore

Brug resload_SaveFile for at skrive det pågældende hukommelsesområde til disken. Hvis du synes, kan du kryptere det en smule så fedtører ikke så let kan patche det. Det er ikke anbefalet at skrive direkte ind i de pågældende disk-images (vha. resload_SaveFileOffset), fordi hvis noget går galt (f.eks. crash), er det muligt, at disse images vil blive beskadiget.

Savegames

Håndtering af Savegame er det samme som med highscores.

Tilgange til operativsystemet

På det tidspunkt, hvor Slaven og det installerede program eksekveres, eksisterer der absolut intet OS eller er tilgængeligt eller giver nogen mening at tilgå! Derfor må alle forsøg på sådanne tilgange fra det installerede program deaktiveres. Hvis der ikke er mange af dem og de ikke giver mening i WHDLoad-miljøet (såsom exec.Disable() eller exec.SuperState()), så NOP ($4e71) dem ganske enkelt. Hvis tilgangene har en vigtig funktion (såsom exec.DoIO()), så omdirigér dem til Slaven og emulatér dem. Hvis der er tons af dem, så opret en simpel exec.library i et ubrugt hukommelsesområde (initialisér lang-ordet ved adresse $4). Du kan checke kilden til Oscar.Slave, der emulaterer exec.AllocMem(). For at detektere tilgange til OS'et, er den indledningsvise execbase sat til $f0000001 med den hensigt at alle rutiner, der gerne vil bruge execbasen, vil oprette en "AdresseFejl"-undtagelse.
Hvis der er kraftigt brug af OS-funktioner, så brug én af kickemu-pakkerne, der kan fidnes i WHDLoad-dev pakken. Der er én pakke for Kick 1.3 ('src/sources/whdload/kick13.s') og é for Kick 3.1 ('src/sources/whdload/kick31.s'). Disse pakker kræver et originalt kickstart-image og vil oprette et komplet OS-miljø inde i WHDLoad-rummet. Konsultér også den pågældende readme der er vedlagt, for yderligere information.

Fælles kompatibilitetsproblemer

Begrænset adresserum på 68000/68010/68ec020

På disse processorer er adresserummet begrænset til 16 MiB ($000000...$ffffff), fordi disse CPU'er kun har 24 adresselinjer. Som følge deraf er alle tilgange til højere adresser udført til de lavere 16 MiB ved at ignorere de mest betydningsfulde 8 bits. Nogle programmer bruger disse bits til at gemme data, eller glemmer ganske enkelt at cleare dem. På en processor med fuld 4 GiB adresserum, såsom 68020/680ec30/68030/68040/68060 virker dette ikke, fordi de fulde 32-bit adresseser vil blive tilgået.
For at løse dette problem er du nødt til at patche disse tilgange og omdirigere dem til de korrekte adresser.
Sommetider kan årsagen til tilgange til mærkelige adresser være en uinitialiseret pointer. I disse tilfælde kan det hjælpe at cleare hukommelsen $400 - ws_BaseMemSize hvilket også kan opnås ved at bruge flaget WHDL_ClearMem.

Forskellige stackrammer på hver processor

Stackrammerne, der oprettes af processoren ved interrupts og undtagelser er forskellige for medlemmerne af 68k-familien. På 68000'eren er en stackramme 6 bytes lang, bortset fra Bus- og Adressefejl. Stackrammen indeholder den gemte SR ved (a7) og den gemte PC ved (2,a7). På alle andre processorer (68010+) er den minimale stackramme 8 bytes og indeholder yderligere vectornummeret som et ord ved (6,a7). Dette Fire-Ords stackramme-format $0 er oprettet for "Trap #xx" og Interrupts på 68010-68060. Stackrammerne på andre undtagelser er forskellige på hver processor. RTE-instruktionen fungerer forskelligt på 68000'eren sammenlignet med 68010+. På en 68000 gendanner den ganske enkelt SR'en og PC'en og fortsætter programeksekvering ved den afbrudte adresse. På 68010+'eren vil den ydermere frigøre stackrammen afhænging af stackramme-formatet.
Nogle programmer skubber en adresse (PC) og en SR og eksekverer så en RTE-instruktion. Dette virker kun på en 68000, på 68010+ vil dette have uventede resultater.
Hvis et program gør det, vil du blive nødt til at fixe dette. Sommeetider kan det være nok at erstatte RTE'en med en RTR.

MOVEM.x RL,-(An) på 68000/010 og 68020-68060

Der er en forskel, hvis registrene, der bliver anvendt i predecrement-modus (RL) også er indeholdt i register-listen. For 68020-68060 er værdien, der skrives til hukommelsen, den indledningsvise registerværdi, dekrementeret med størrelsen på operationen. 68000'eren og 68010'eren skriver den indledningsvise registerværdi (ikke dekrementeret).
Pt. er der ingen kendt software, der har problemer pga. dette.

Generelle retningslinjer for skrivning af installs

Tips & tricks

Hvad er det bedste, brug af diskimages eller filer?

Sommetider har du valget mellem at bruge diskimages eller rigtige filer. Begge har sine fordele. Brugen af diskimages er som regel den nemmere og hurtigere måde at oprette Slaven på. Men rigtige filer er nemmere at cache (hvis der er meget lidt hukommelse eller hukommelsen er fragmenteret). Den krævede plads på harddisk vil også være mindre med rigtige filer end med diskimages. Du bør kun bruge diskimages, hvis der er mange filer (mere end 30).
[Main] [Docs] [Installs] [Search] [Team] [Guestbook] [Links]