C=Foorumi

purkki pörrää tasaisesti ja ilman suurempia ongelmia

tosin meikäläisellä ei meinaa enään aika riittää muuhuinkuin ylläpitoon
lomapäivistä haaveillaan joskos niiden aikana saisi jotain aikaiseksi

huomasin myös ettei guide muotoinen file hakemisto paketti toimi enään
ja siksi se on jäänyt jälkeen nykyisestä file tilanteesta asia korjataan kunhan tässä ehtii asiaan paneutua

jotenkin alkaa pinna loppumaan tuon Youtuben kanssa pikku hiljaa...
ennen se toimi kuin junanveski mutta nykyään se alkaa oleen melko raskas pyörittää plus mainokset päälle
toisekseen tuo herkkä hipisyys noiden musien suhteen tms.

tässä hieman kuvaa pajastani viimeisin kuva oli vain pöydästä jonka ääreen en siis enään pääse koska...

ehkä mun pitäisi viimen tehdä tuo remontti loppuun ja vasta sitten tehdä jotain muita projekteja 

Coodi käännetty nyt täysin XA65 kääntäjälle
mutta koodista on iso osa hukassa ja siksi muuttujia ja ohjelma rutiineita puuttuu iso määrä
nyt selvitellää mitä 4 levyn lopusta puuttuu ja mitä rutiineita se sisälsi

mikään ei ole muuttunut tässä päässä ainakaan

Vuoden Vaitumisen uutisia 

näyttää siltä että A4000 hoitaa hommansa mallikkaasti ja ilman ongelmia joten se saa jatkaa 
A2000 remontti ja uppaaminen on laitettu hetkeksi jäihin koska Joululahjani vaatii kaiken liukenevan aikani

mitä tulee itse purkkiin sinne on avattu nyt Jukka Tapanimäki Time capsule
jonne tulee siirtymään melko runsaasti hänen jälkeensä jättämää Digitaalista janlanjälkeään
ensimmäisenä sinne siirtyi muutama C= lehteen kirjoitettu artikkeli ja myös hänen kirjoittamansa
kirja alotteleville 6510 ohjelmoijille myöhemmin jakoon menee sourcea
mm. Aikaetsivä,Octapolis,Netherworld dev disketit...
samoilla levyillä on myös työkalu softia joita pelien tekemiseen on käytetty
harkitsen myös laittavani jakoon linkki softan jolla hän kytki PC <> C64 yhteen
koodaus kävi tämän kaapelin kautta todella nopeasti ja näppärästi
mutta ensin minunkin on tutustuttava siihen perin pohjin...
onneksi systeemi on vanhalta DOS ajalta joten DOS poxsilla sitä voi ajaa jopa Linukan alla

niille joitka ihmettelevät miksi käyttäjien määrä on tipahtanut melko rajusti vuoden vaihteessa
voin kertoa että jokin scripti tms. päätti poistaa liian kauvan poissa olleet käviät purkin muistista
vielä en ole ehtinyt selvittämään mitä oikein tapahtui mutta suunitelmissa on palauttaa nämäkin käyttäjät takaisin
purkin koska he ovat osa sen historiaa muuten olo on ollut melko huoleton systeemi toimii ja kukkuu
toki se edelleen on joskus kumossa mutta ei sentään joka aamu kuten edellinen 
hyvää vuoden vaihdetta siis kaikille ja kohtahan se aurinkokin alkaa taas paistaa...

onko käynyt taas niin että armejjan kovakoulutus on vienyt meiltä foorumin kovimman peliarvostelijan ja videotuottajan =?
we miss you man !!

ensimmäinen packup osa kohta käännetty toimimaan XA65 kääntäjällä vielä 6 to go 
sitten pääsee kokeilemaan käynnistyykö ja onko ohjelman palaset oikeilla paikoillaan

http://jlgconsult.pagesperso-orange.fr/Atari/memory/memory_en.htm

luultavasti ST ei vain ymmärrä noiden isompien muistien päälle koska hardis rajoittaa muistin 4megaan
eli 4x1megaa joten sovittaminen on turhaa. tai verenkaivamista nenästään...

multa löytyy pussillinen noita 8bit kampoja mutta ei ole laitetta millä testa niiden kokoja
samoin simmejä ja dimmejä...

http://www.atari.org/hosted/quickfaq/stfaq_1.htm

whoo 700 sadas viesti lähtee tästä vielä 300 to go...

kävin sitten lopultakin masentamassa itseni ja lueskelemassa Gurujen hörinöitä wectorien piirrosta xD
kuten arvasin olen tähtivuosien päässä niistä rutiineista joita on kehitetty aikojen alusta asti
ja edelleen niitä viilataan...

siinä missä wectorin piirossa moonfall peli käyttää Rev 2 tekemääni piste rutiinia kulma piirtoon
se tarkoittaa noin 36 kellojaksoa per piste ilman seuraavan pisteen kohde laskentaa
missä gurujen rutiini piirtää jo wectoria ja kuluttaa siihen 13 kellojaksoa per piste
ja maximissaan 34 per piste

hauskinta asiassa oli huomata ettei jukkakaan ollut juuri paneutunut pisteen piirto koodin syvälliseen toimintaa
vaan oli kopioinut sen suoraan mallista ja koska se oli nopeampi kuin aikaisempi se riitti hänelle
itse havaitsin heti uusia koodeja katsoessani että omassanikin on yksi ilmi selväparannus kohde

muut parannukset joita ajattelin lisätä on jo keksitty
joten ongelmaksi jää vain kerätä koodit talteen ja soveltaa ne toimimaan yhteen pelin mootorin kanssa tai muokata
rutiinit toimimaan pelin kanssa yhteen

mikä parasta piiloviiva ongelmakin ratkeaa melkein kuin itsestään tässä samalla
eikä vie tehoa yhtään enempää vaan edelleen lisää sitä

mitäs nyt sitten ?!?
seuraavaksi hieman opettelen lisää ja teen sourcen muokkaukset loppuun ja yritetään saada
MoonFall Rev1 starttaamaan ja toimimaan niin näen onko se nykyisen kanssa edes yhtenevä

huomasin myös kääntäjän koodia tutkiessani ettei käyttämäni AX kääntäjä
ota huomioon nollasivu osoituksia oikein vaan käyttää 16bit osoituksia ?!?
tästäkin saadaan koodiin tehoa lisää kunhan keksin miten nuo nollasivu osoitteet pitää
erikseen kääntäjälle ilmoittaa

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


pitihän se testata mihin tuo Rev 2 versio pystyisi samanlaisessa testissä

kyseinen rutiini pystyy piirtämään samaisia viivoja 9kpl ruudun päivityksessä

ja kun oikein rääkkäsin niin sain max lukemat mihin se pystyy oikeasti kun puristetaan ihan viimeisille
675 pixeliä ruudun päivityksessä eli kauvas jää ;-)

edit:
testasin sitten myös uuden rutiinin huiput tällä hetkellä
79x28=2212 pixeliä

hieman uutisia 

kehitin päässäni uuden viivanpiirto rutiinin jolla paiskii vanhaa koodia mennentulle seinille xD
jos ennen yhden 256 pitkän viivan piirtämiseen meni ruuduudun päivityksen verran kello jaksoja
pystyy nykyisellä tekemään vähintään 50-60kpl samoja viivoja 7o7
vielä en ole tarkasti mitannut paljonko se on tehokkaampi mutta vähintään tuohon määrään se pystyy
256 viivan piirtämiseen menee hieman alle 8 rasteri linjaa

testaus on vielä kesknen eikä koodikaan ole vielä täysin optimoitu mutta lähellä olllaan
vielä muutama kielletty käsky ja säästämme vielä 4-8 kellojaksoa per 8 pixeliä
tämä näyttää hyvältä...

:edit 21.30 1.1.2015:

köh köh...
tulipas reviteltyä leukoja hieman enemmän kuin olisi ollut tarve xd
nyt rutiinia on hiottu ja oikeasti testattukin niin alkoi selviämään lopulliset tehotkin
en ole etsinyt lopullista tehoa vaan mittasin vain montako kyseistä viivaa pystyn sillä piirtämään
ilman että päivitys aika loppuu kesken mahdollista olisi ehkä vielä noin 30-80 pixelin piirtämiseen

ulkomuistista kun aloin noita speksejä paukuttamaan niin pieleenhän se meni 
eli otetaampas uudelleen. kyllä tehoa saadaan mutta ei toiki niin paljon kuin alussa ilmoitin
koodin teho on noin 100 vaakapikseliä ja 20 riviä yhdessä ruudunpäivityksessä se tekee noin 2000 pixeliä
jos tuon muuttaa hires tilaan tehot näyttävät seuraavaa 200*20=4000 pixeliä
( MoonFall pelin ruutu on noin  color 128 x 120 pixeliä mono 256x120 pixeliä)

nyt kysytte että miten koodi pystyy kaksinkertaiseen tehoo tarkemmalla ruudulla
siitä voimme kiitellä C= insinöörejä ja kyllä rutiini pystyy tuohon ehkä muutaman rasteri linjan vie lisää mutta pystyy silti

rutiini piirtelee siis vaaka viivoja
jukan koodissa on noin 4 erilaista spesifiä viivan piirto rutiinia
vaaka / pysty viivojen piirto (esim. kartta)
kulma piirrot on jaettu kahteen osaa riippuen siitä piirretäänkö viivaa enemmän vaaka suuntaan vai pystyyn
näin voidaan välttää kahden suunnan tarkistukset ja mitataan vain viivan "pituutta" ja kun se on saavutettu on viiva valmis
tässä hieman esimerkkiä miten vaaka viiva piiretään nykyisellään pelin rutiineissa


:main flat line loop:
rev 1

!LINELOOP   LDA (T2),Y
!BIT      ORA BIT1,X
         STA (T2),Y

!INXNOP   INX
         INX
         CPX XM2
         BCS !END
         LDA BIT4,X
         BNE !LINELOOP
         TYA
         ADC #8
         TAY
         BNE !LINELOOP

!END      RTS
en ole katsonut mutta olettaisin että rev 2 näyttää seuraavalta
tai ainakin minä olisin sen kirjoittanut näin
pysty kordinaatteja ei tarvitse antaa kuin kerran vaaka pixeleitä voi piirellä pelkällä X rekisterin veivaamisella
muttei edes tästä ole kisaajaksi uudelle rev 3 rutiinille ;-)


!LINE_LOOP

    LDY BIT4,X
    LDA (T2),Y
    ORA BIT1,X
    STA (T2),Y

    INX
   CPX XM2
   BCS !LINE_LOOP
   RTS

mutta koska koodin tehostaminen ei aina kutista koodia vaan ennemminkin kasvattaa sitä
saatan ehkä joutua karsimaan Boost versiosta mono modin pois että saan muistiin tilaa tehokkaamille koodauksille 

sain sitten etukäteis joululahjankin jota tässä on käpistelty jo muutama viikko

eli alkuperäisen MoonFall pelin aito source
tosin näyttää olevan vanhempaa versiota kuin kaupallinen versio
samoin backup korppu 4 oli korruptoitunut joten hieman joutuu paikkailemaan
ja kaikki grafiikka fileet ovat kadoksissa joten nekin joutuu tekemään itse
samoin PC linkkerillä tehty koodaus ei ole suoraan yhteensopiva minkään käyttämäni Assyn kanssa
joten käsin korjaamista tiedossa paljon ennen kuin käännös käynnistyy oikeana toimivana pelinä

vaikka jukka aikanaa hieman kirosikin ettei saanut upotettua minun piste rutiinia ohjelmaan
näin jälkeen päin tutkittuna hän on sen kuitenkin tehnyt
mikä lämmittää mieltä vaikkakin vuosien päästä
ilmeisesti viivästynyt julkaisu avitti vielä viimehetken korjailuja
saamani source on ilmeisesti ensimmäisen julkaisu yrityksen ajalta
jossa jukan oma rutiini ja eroa on enemmänkin kuin muutama kello jakso
viivan piirto rutiini taas on ällistyttävän optimoitu en ole nähnyt optimoidumpaa rutiinia
asiaa kuvastaa jukan kommentti " ; note: this can't possibly be much faster! "
tosin tutkimuksen alla on kuinka paljon viivanpiirtoa ennen pystytään coodia optimoimaan
yritän samalla lisätä koodiin piiloviivojen poiston (Elite)
kyseinen toiminto oli MF mutta jukka poisti sen koska piiloviivojen laskenta vei kuulemma liikaa kellojaksoja
nyt tutkitaan onko siihen joku keksinyt paremman matamatiikan xD

kuten tuossa yllä kerroin tarkoitukseni on tehdä MF hyvin optimoitu versio
lähinnä viivanpiirtoon&laskentaan liittyviä buustauksia
tiedoilla mitä asiasta on nyt tällä välillä kertynyt
vaikka alustana olisikin pelkkä C64 tulemme näkemään nopeuden nostoa ruudun päivityksessä
tuen myös kaikkia Chameleoin tarjoamia apuja turboa ja REUta
blitterin käyttö on harkinnassa mutta kokeillaan nyt ensin nämä normaalit jipot koska blitteri on vain Chameleonin 7 päivityksessä joka seuraavassa poistettiin "turhana"

tässä vielä malliksi Jukan ja minun piste rutiini muistaakseni sama pätkä oli C= artikkelissa ?!?
*pitääpä tarkistaa*
vakaa aikomus on tiputtaa tuosta vielä muutama kellojakso :p

Jukka rev1:
LINELOOP1 LDA ROWPNTLO,Y
STA T2
LDA ROWPNTHI,Y
SCROFF1 ADC #0 ;add offset (because of douple buffering) lisää ylätävuun toisen buf arvon
STA T3 ; näin voidaan käyttää samaa taulukkoa
TXA ;x reg. = x coord
AND #$F8
ORA BIT4,Y
TAY
LDA (T2),Y
DOTBIT1 ORA BIT1,X ;get bits from a table
STA (T2),Y

Rev2:
LINELOOP1 LDA ROWPNTLO,Y
STA T2
LDA ROWPNTHI,Y
SCROFF1 ADC #0 ;add offset (because of douple buffering)
STA T3        
LDY BIT4,X
LDA (T2),Y
                ORA BIT1,X ;get bits from a table
STA (T2),Y