Floppy-archeologie: Rex I

Alles over C64/C128 software
-
Everything about C64/C128 software
dmantione
Junior
Berichten: 60
Lid geworden op: za okt 04, 2014 10:01
Locatie: Purmerend

Floppy-archeologie: Rex I

Berichtdoor dmantione » za apr 08, 2017 12:55

Goedemorgen,

In een poging weer activiteit op het forum te krijgen... ik blader wel eens door de floppycollectie heen uit mijn jeugdjaren. Ik backup de floppy's naar moderne media met de 1541U2, die nog altijd in goede staat lijken. Ik ben wat dat betreft benieuwd wat het langer gaat volhouden: De floppy's of de SD-kaart. Daarbij speel ik ook nog wel eens wat en kom ook nog wel eens iets tegen wat ik al jaren weer vergeten was.

Eén zo'n spel wat tegenkwam is Rex I. Dat is een Duitstalig spel, maar zat destijds genoeg in elkaar om het taalongemak voor lief te nemen (in mijn tienerjaren sprak ik geen woord Duits) en ik heb het destijds nog redelijk wat gespeeld. Het is een strategisch spel dat veel weg heeft van het veel bekendere Kaiser, maar is veel uitgebreider.

Van het één komt het ander: Ik had moeite het spel te draaien en ik ging op zoek naar de oorzaak. Onderzoek leverde twee oorzaken op: Incompatibiliteit met de Final Cartridge III en het spel tolereert niet dat er op de seriële bus ook nog andere apparaten actief zijn dan device 8. Omdat we tegenwoordig met een 1541U2 werken is dat zeer irritant, evenals de onhebbelijke eigenschap van programmatuur om device 8 te hardcoden.

Het spel is geschreven in een combinatie van Basic en machinetaal en dat maakt de code enigzins inzichtelijk: De Basic-delen zijn goed te lezen, terwijl de stukjes machinetaal relatief kort en bondig zijn. Het spel aanpassen om de hardgecodeerde device 8 eruit te halen was dan ook een kleine moeite.

De intolerantie voor meerdere seriële devices wordt veroorzaakt door een fastloader die het spel installeert. De tweede aanpassing was dan ook het herschrijven van de machinetaalroutine die die fastloader installeert: Die controleert nu eerst of de LOAD-vector naar het ROM wijst. Zo nee, dan is er waarschijnlijk al een fastloader actief (cartridge!) en kan het spel beter niet zijn eigen fastloader installeren. Misschien kan de fastloader maar beter helemaal uit het spel verwijderd worden. In de gouden C64-jaren hectten programmeurs erg veel belang aan een goede ervaring op een kale C64, tegenwoordig is de situatie dat iedereen wel iets van fastload-mogelijkheden heeft en hebben we liever dat spellen netjes de kernel gebruiken voor compatibiliteit met zoveel mogelijk apparaten.

Resultaat was dat het spel device 4,9 en 10 van de 1541U2 tolereerde, maar bij gebruik van de Final3 nog altijd niet functioneerde. Het oplossen daarvan was een flinke klus. Na onderzoek bleek dat de bestanden CH.* door het spel altijd op adres $dffc worden geladen, min of meer in het RAM achter de kernal, op 4 bytes na. Die 4 bytes zitten dus in IO2, iets waar je absoluut niet mag komen, je kunt er zonder cartridge ook helemaal geen gegevens neerzetten, maar het spel doet het toch en manipuleert dan het heiligdom van de FC3 (en andere cartridges).

Omdat je helemaal niets in die 4 bytes kunt opslaan was het me wel duidelijk dat die 4 bytes niet terzake deden. Het is vermoedelijk een header van het programma waarmee de bestanden gegegenereerd zijn, de programmeur wilde de echte data op $f000 hebben, dus deed het maar zo? Alleen, hoe los je uit op? Je hebt op een C64-geen SEEK om 4 bytes te kunnen overslaan als je een bestand leest. Ik heb uiteindelijk gekozen de 4 bytes van de CH.*-bestanden af te halen, elk bestand dus gemodificeerd. Het spel dan weer werkend krijgen was een hele toer, want je moet op veel plaatsen BASIC en op sommige plaatsen de machinetaalroutines aanpassen, maar is gelukt. De bestanden laden nu op $f000 en het spel is nu compatibel met de FC3 en waarschijnlijk een hoop andere cartridges.

Bij testen loopt het spel nu echter snel vast vanwege geheugengebrek. Het BASIC-programma is iets in de orde van 50 byte langer dan voorheen, maar kennelijk is dat teveel. Ik moet het geheugengebruik van het spel dus iets terugdringen en dat is niet triviaal, het ouderwetse schoenlepelwerk op de C64. Het spel kan tijdens het draaien de hoeveelheid vrij geheugen tonen, nu 423 byte na opstarten, dat dat krap is moge duidelijk zijn. Idealiter zoek ik dus een methode om BASIC-programma wat kleiner te maken, maar het is al redelijk compact geprogrammeerd. Ik heb wel wat ideetjes, maar het wordt er niet eleganter op. Wellicht is het iets om in de groep te gooien om te kijken of er een elegante methode is.

Een ingreep die ik al gedaan heb is 3 aanroepen van SYS aan de start omzetten in een machinetaalroutine, zodat nog maar 1 SYS nodig is, dat spaart ongeveer 20 byte uit.

Als het allemaal werkt is het wellicht een leuk idee om het spel te vertalen, is er ook weer eens wat Nederlandstaligs beschikbaar.

Diskimage van de stand tot nog toe: http://www.freepascal.org/~daniel/rex%20i.d64

Daniël

dmantione
Junior
Berichten: 60
Lid geworden op: za okt 04, 2014 10:01
Locatie: Purmerend

Re: Floppy-archeologie: Rex I

Berichtdoor dmantione » vr apr 28, 2017 16:24

Na het bestuderen van de mogelijkheden, heb ik besloten de invoerlus in machinetaal om te zetten. Die invoerlus komt meerdere malen in de code voor, dus een centrale machinetaalroutine die het werk doet, bespaart redelijk wat geheugen. De muisondersteuning in de invoerlus was een beetje knullig, dus kon beter. Na een zoektocht door de berging vond im mijn oude 1531-muis terug en daar wat experimenten voor gedaan. Ik ben min of meer wetenschappelijk te werk gegaan en heb op de PC een klein algoritmetje ontworpen, wat de potx/poty-coördinaten omzet in een menupositie in het spel.

6502-machinetaal ben ik nooit echt verleerd, toch was het best wel even puzzelen om het goed te doen, en ook om een plekje te vinden. Vanaf $c92b tot $c9ff was nog wat geheugen vrij, dus het moest in die ruimte gelepeld worden, wat na een beetje passen en meten gelukt is. De machinetaal was niet de enige uitdaging: Ik was geheel vergeten hoe complex het is om de 1531 te programmeren, met name omdat Commodore in zijn wijsheid het toetsenbord en de controports op dezelfde draadjes heeft aangesloten, waardoor tijdens het uitlezen van het toetsenbord de nodige malen geschakeld wordt tussen de analoge lijnen op poort 1 en 2, maar nadat die interrupt voltooid is, de muis enige tijd niet uitgelezen mag worden. Zowat de enige manier om de muis betrouwbaar uit te lezen is de interrupts om te leiden en de muis dan net uit te lezen voordat je naar de originele interruptroutine springt die het toetsenbord uitleest. Het staat allemaal keurig in de Nederlandse handleiding van de 1531 en is een mooie illustratie hoeveel de wereld veranderd is: Het is tegenwoordig volstrekt uit den boze dat een computerfabrikant aan eindgebruikers uitlegt hoe je interruptroutines moet schrijven.

In het geval van het spel betekent interrupt een rasterinterrupt die een splitscreen implementeert en om de muis netjes uit te kunnen lezen, moest ik me dan ook nog eens verdiepen in een rasterinterruptroutine, zodat ik het er aan kon toevoegen. Die rasterinterruptroutine zit op $05a4 en op die plek was wel plek te vinden voor een paar byte extra die de muis uitleest. Het was nodig gegevens van de muisroutine terug te communiceren naar het BASIC-programma. Dat kun je natuurlijk ergens in het geheugen stoppen en er met peek uitlezen. Ik vond dat niet elegant genoeg en het kost allemaal extra plek in het BASIC-geheugen, dus heb ik ook nog maar even uitgezocht hoe je in machinetaal BASIC-variabelen van waarde kunt veranderen.

En o ja, ik heb het hier vooral over muis, maar het spel is ook gewoon met pretpook te bedienen, dus de machinetaalroutine regelt zowel de muis- als joystickinvoer.

Resultaat een simpele machinetaalroutine die je kunt aanroepen met bijv. sys51546,7,p%,m%. De 7 is het aantal ingangen in het menu, p% is in/uit, het is de huidige positie in het menu. Na terugkeer is die veranderd bij muis- of joystickbewegingen. m% is alleen uit en geeft de huidige muispositie aan, of 0 als er op een joystick- of muisknop is gedrukt. Daarmee konden de invoerlussen in het BASIC-gedeelte zeer sterk vereenvoudigd worden, met als gevolg dat er ongeveer een kilobyte geheugen bespaard wordt.

Na omschrijven en testen is het spel is nu weer helemaal speelbaar en nu ook een stuk beter met de muis te bedienen.

dmantione
Junior
Berichten: 60
Lid geworden op: za okt 04, 2014 10:01
Locatie: Purmerend

Re: Floppy-archeologie: Rex I

Berichtdoor dmantione » ma mei 01, 2017 7:33

Ik heb de vertaler er overheen gehaald. De nu Nederlandse versie is hier te downloaden:

http://www.freepascal.org/~daniel/rex%20i%20nl.d64

Siem
Senior
Berichten: 189
Lid geworden op: do feb 04, 2010 16:26
Locatie: Heerhugowaard
Contacteer:

Re: Floppy-archeologie: Rex I

Berichtdoor Siem » ma mei 01, 2017 22:30

Het spijt me te moeten melden dat beide D64's het niet doen in VICE.
Heb van alles geprobeerd, true drive emulation enz.. Zonder resultaat.

Gr. Siem
Verzamelaar van Commodore computers en randapparatuur.

dmantione
Junior
Berichten: 60
Lid geworden op: za okt 04, 2014 10:01
Locatie: Purmerend

Re: Floppy-archeologie: Rex I

Berichtdoor dmantione » di mei 02, 2017 0:05

Hé, dat is raar, want ik heb ze zelf ook in Vice gedraaid en dat ging goed. Zou het kunnen dat de fastloader ook hier roet in het eten gooit? Zoals ik hierboven schreef tolereert de fastloader in het speel geen andere ingeschakelde apparaten dan een device 8. Een tweede floppy of printer die alleen maar aan staat is al fout.

Ik heb dus een check toegevoegd die de fastloader niet installeert als de load-vector niet naar de kernel wijst (aanwijzing dat er een cartridgefastloader aanwezig is), maar als je in Vice geen cartridge zou nemen en een device 9 zou activeren, dan loopt de boel ook in Vice gegarandeerd in de vangrail.

Dit is iets waar nog nader naar gekeken moet worden en zoals gezegd speel ik met het idee om die fastloader maar helemaal te saboteren.

nhoijtink
Expert
Berichten: 363
Lid geworden op: vr jun 06, 2008 9:00

Re: Floppy-archeologie: Rex I

Berichtdoor nhoijtink » di mei 02, 2017 13:32

Loopt hier ook goed in WinVICE

Afbeelding
Afbeelding

True Drive emulation, Drive sounds, en 40TR Extend on Access staan bij mij standaard aan. De WinVICE versie is 3.0 33018, maar zal in latere versies ook dienen te werken denk ik.

Hier kun je vele versies van WinVICE vinden, waaronder de 3.0 33018: http://vice.pokefinder.org/#downloads


Ik heb wel gemerkt dat het laden wel erg lang duurt, dus houd daar rekening mee. Rechts onderin kun je iig de diskdrive headstep zien.

Terug naar “Software”

Wie is er online

Gebruikers op dit forum: Geen geregistreerde gebruikers en 1 gast