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.
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.
; 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