6502-koneesta toiseen porttaus

[protek]

Tunnustetaan nyt heti ensi alkuun, etten ole eläessäni kirjoittanut riviäkään assembly-koodia, joten kysymykseni ovat enemmänkin hypoteettisia.

Mitä tulee ottaa huomioon, kun lähdetään porttaamaan konekielistä ohjelmaa yhdeltä 6502-pohjaiselta koneelta toiselle? Otetaan esimerkkinä Apple II:n Prince of Persia, kun sen sorsat ovat saatavilla ja kohdekoneena Plus/4 tai laajennettu C16. Tämä lähinnä siksi, kun Kuusnepaporttaus on jo tehty ja Plus/4 on ehkä raudaltaan lähempänä Apple II: a kuin Kuusnepa.

Itsellä tulee mieleen muistialueet. Plus/4:ssä on kohtuu paljon RAMmia vapaana, joten olisiko mahdollista, että PoP:n käyttämät muistialueet osuisivat yksiin? Jordan Mechner on dokumentoinut PoP:n ymmärtääkseni kohtuu perusteellisesti ja julkaissut sorsien lisäksi myös ne, joten vastaus löytynee sieltä sekä Apple II:n ja Plus/4:n muistikartoista.

Toinen asia lienee erot raudoissa. Olenko ymmärtänyt oikein, että pitäytymällä virallisissa opcodeissa assemblyllä koodattaessa, koodin pitäisi muistiosoitukset huomioon ottaen ilman muutoksia portattavissa alustasta toiseen? Ovatko siis illegal opcodet suoraan rautaa puukottavia ja nämä puolestaan vaihtelevat alustasta riippuen? Äkkiseltään voisi kuvitella, etteivät ainakaan grafiikkarutiinit ihan heittämällä mene.

Ajatus PoP:n porttauksesta Plus/4:lle heräsi, kun näin Exploding Fististä tehdyn epävirallisen Plus/4-porttauksen, joka ei grafiikoiltaan yhtään hävennyt Kuusnepalle toisin kuin virallinen C-16-porttaus.

[virgo]

kaikissa 8bit ja osassa 16bit koneissa puukotetaan suoraan rautaa koska

a) koneiden tehot ovat matalat
b) rom rutiinit ovat pelikäyttöön auttamattoman hitaita
c) jos rommilla olevia rutiineita käytetään ne ovat eri osoitteissa ja luultavasti tekevät asiat erilailla koneesta riippuen

pitää muistaa että Rommilla olevat ohjelmat on tehty tukemaan koneen Basicia nopeus ei ollut tärkein kriteeri
ehkä tilan tarve oli tärkeämpi

porttausta toki helpottaa että Cpu alusta on sama mutta enemmänkin ongelmia tuottaa koneiden erilainen hardis
koska ne vaativat erilaiset jipot toimiakseen oikein. käytetyt grafiikat pitää muuttaa alustalle sopiviksi...

samon jippojen viemä prosessori aika voi olla myös huomattavan paljon pidempi / lyhyempi riippuen täysin raudasta
8bit koneissa suurin ongelma ideoiden ja toteutuksen välissä on rajallinen prosessorin teho

illegal opcodet ovat yleensä samassa prosessori perheessä samat
eli konekieli käskyt joiden ei pitäisi toimia tai niitä ei ole suuniteltu toimivan tai ovat suoranaisia bugeja
prosessorin "parseri" kuitenkin ymmärtää osan käskyiksi ja parhaansa mukaan koittaa toteuttaa sen

illegal opcodet ovat harvinaisia joskus niitä käytetään kopiosuojaus tarkoituksessa
aikanaan deasseblerit eivät ymmärtäneet niitä käskyiksi joten se teki prosessista
hieman vaikeamman tulkita miten ohjelma toimii
joskus niistä on nopeus tai helppos hyötyä esim. X rekisteriä voi yhdellä illegal opcodet käskyllä vähentää haluamansa määrän
mikä ei normaali käskykannalla onnistu tai määrittelemällä A ja X rekisteri samalla käskyllä

samoin ohjelmien sijainti eri osoitteissa aiheuttaa ongelmiä niiden siirtely ei ole ihan ongelmatonta
mm. JMP käskyt pitää muuttaa osoittamaan oikeaan osoiteeseen taulukoiden grafiikoiden sijainti vaatii muutoksia ohjelmaan
osan Jump käskyjen muutoksista käytetty assebler osaa itse hoitaa mutta
taulukoiden päälle ne eivät monestikkaan ymmärrä mitään

aluksi kannattaa tutustua hyvin kohde koneiden toimintaan ja hardikseen ymmärtääkseen niiden toiminta kohtuu hyvin
nykypäivän koodaaminen on ihan toiselta planeetalta jos vertaa 6502 koodaukseen

monesti ammattikoodereiden kuulee kysyvän "miksi et käytä korjastoja ?"
mikä kuvastaa suoraan tietämättömyyden ja erilaisuuden mitä tulee 8bit koneiden koodaamiseen
kirjastoja ei ole ! ellet niitä itse tee ja porttaus koneiden välillä käyttäen vain kirjastoja ei siis tule kyseeseen
ideana toki hyvä mutta ottaen huomioon koneiden rajalliset teho reservit joskus pelkkä
aliohjelma kutsu "JSR $xxxx" vie jo liikaa aikaa

kirjastot olisivat mukava mutta aina niitä pitää jotenkin puukottaa sopimaan tarkoitukseensa ainakin peli ohjelmoinnissa
mitä meillä on "kirjastoina" on malli rutiineita joita voidaan käyttää ja liittää itse coodiin
jos niistä tekee helppo käyttöisiä se yleensä tarkoittaa että ne myös vievät sitten hieman kellojaksoja

C64 Romilla lähin mitä tulee kirjasto kutsuihin on Jmp table joka sijaitsee ylemmässä Rom muistissa
mikä on yksinkertsisuudessaan hyppy taulukko joka kertoo missä kyseinen ohjelman pätkä sijaitse
nämä tukevat koneiden yhteensopivuutta keskenään C64,C128,SX 64
tämä ei tietenkään päde toisen valmistajan koneeseen koska sen rommeja on ohjelmoinut joku muu ja puukottanut hieman erilailla johtuen Raudasta

tässä esim.

Koodi [Valitse] Laajenna


; C64 kernal vectors

FF81   4C 5B FF   JMP $FF5B   ; initalise screen and keyboard
FF84   4C A3 FD   JMP $FDA3   ; initalise I/O devices
FF87   4C 50 FD   JMP $FD50   ; initalise memory pointers
FF8A   4C 15 FD   JMP $FD15   ; restore I/O vectors
FF8D   4C 1A FD   JMP $FD1A   ; set I/O vectors from XY
FF90   4C 18 FE   JMP $FE18   ; control kernal messages
FF93   4C B9 ED   JMP $EDB9   ; read secondary address after listen
FF96   4C C7 ED   JMP $EDC7   ; read secondary address after talk
FF99   4C 25 FE   JMP $FE25   ; read/set top of memory
FF9C   4C 34 FE   JMP $FE34   ; read/set bottom of memory
FF9F   4C 87 EA   JMP $EA87   ; scan keyboard
FFA2   4C 21 FE   JMP $FE21   ; set timout for serial bus
FFA5   4C 13 EE   JMP $EE13   ; input on serial bus
FFA8   4C DD ED   JMP $EDDD   ; output byte on serial bus
FFAB   4C EF ED   JMP $EDEF   ; send untalk on serial bus
FFAE   4C FE ED   JMP $EDFE   ; send unlisten on serial bus
FFB1   4C 0C ED   JMP $ED0C   ; send listen on serial bus
FFB4   4C 09 ED   JMP $ED09   ; send talk on serial bus