Posts filed under 'koodi'
Perjantai-illan hätäinen pikku Processing-projekti rupesi paisumaan ja alkaa olla jo hiljalleen ihan käyttökelpoinen. Tarkoituksena oli tehdä Zoo 2013:n PETSCII-kilpailua varten minimalistinen editori, jolla saisi lätkittyä ruudulle merkkejä väreineen ja sitten näytettyä niitä oikealla kuusnelosella. Mitään kunnollista ei tuntunut löytyvän valmiina Linuxille tai Mäkille, joten tehdään sitten itse. “Feature creep” iski pahasti päälle ja tein yhtä sun toista lisäystä. Tällä hetkellä ohjelma osaa jo seuraavaa:
- Piirto, kumitus ja väritys
- Reunuksen ja taustavärin vaihto
- Merkin poiminta
- Kuvien lataus ja tallennus
- Kuvien eksporttaus C-, assembler- ja BASIC-muotoon
- Simppeli pikselipiirtomoodi 1/4-merkeillä
- Alueen valinta ja kopiointi/tyhjennys
- PETSCII:n uudelleenjärjestely helpompaan muotoon
- Esikatselu venähtäneillä merkeillä ilman gridiä
Katsotaan, kuinka pitkälle into vielä riittää. Kaikenlaista muutakin mahdollista voisi lisäillä loputtomasti, mutta ainakin undo olisi varsin tarpeellinen toiminto. Animaatiota on pyydetty myös, mutta katsotaan nyt. Siinä vaiheessa, kun into loppuu, niin kintaat putoavat välittömästi 🙂
edit: Niin, jäi linkit laittamatta:
edit2: Tukee nyt myös VIC-20:tä.
edit3: Dokumentaatiota nyt täällä: http://www.kameli.net/marq/?page_id=2717
September 29th, 2013
Here are some preliminary results from a compiler/interpreter test, where we pitted different MSX compilers and cross-compilers against each other. The test was a simple integer addition loop. Here’s the Pascal version for a reference:
Program Bensmark;
Var
i,j,s:Integer;
Begin
s:=0;
For i:=1 To 10000 Do
For j:=1 To 100 Do
s:=s+1;
Writeln(s);
End.
The snippet tests mostly loops, so the results can’t be generalized for all sorts of purposes. Anyway, here comes the list with execution times in seconds, arranged from fastest to slowest:
- Mildly unrolled assembly: 4
- Trivial assembly implementation: 8
- SDCC C cross-compiler 2.9.0: 13
- MSX-C 1.20: 44 – painfully slow compilation
- X-BASIC: 47
- Turbo Pascal: 62 – quick compilation
- z88dk C cross-compiler: 86
- Hisoft C 1.35: 154
- Hisoft Pascal: 880 – extrapolated from a shorter loop
- MSX-BASIC: 2500 – extrapolated from a shorter loop
Some big surpises there, actually. I expected a lot better performance from z88dk and Hisoft C, but they lost even to the ancient Turbo Pascal. TP got a big plus for its swift compilation time, too. X-BASIC went on to show that BASIC doesn’t need to be slow at all. In spite of its problems and somewhat modest code generation, SDCC easily took the crown of compiled high-level languages here.
September 15th, 2013
Kevään kirjoitusrytistys alkaa lopultakin tuottaa näkyvää tulosta. Ensimmäisenä uunista ulos ehti Neljän kilotavun taide, joka ilmestyi tänään akateemisen verkkolehti WiderScreenin numerossa 2–3/2013. Demotutkimus tuppaa muutenkin olemaan marginaaliaihe, ja pikkuintrot kuten 4k, 1k ja 256B ovat vielä senkin marginaalissa, joten aiheessa on ainakin uutuusarvoa. Näin jälkiviisautena hiukan harmittaa, että tuli kirjoitettua tuo suomeksi, koska se rajaa kansainvälistä lukijakuntaa kohtuuttomasti – toisaalta on tärkeää, että pieniä kieliä käytetään aktiivisesti tutkimuksessa ja koulutuksessa. Jossain vaiheessa yrittänen laajentaa artikkelin johonkin sopivaan kansainväliseen tieteelliseen lehteen, kunhan saan kiireellisemmät kirjoitushommat alta pois.
June 3rd, 2013
Tein 10 PRINT -kirjasta saman tien hieman laajennetun arvion Turun yliopiston Agricola-verkkojulkaisuun. Ensinnä vähän epäilytti, sopiiko englanninkielinen ja melko tekninen teos ollenkaan Agricolan kirja-arvosteluihin, joissa yleensä käsitellään suomenkielistä kulttuurintutkimusta, mutta kun toimittajilta tuli vihreää valoa, niin mikäpä siinä. Linkki arvosteluun.
April 24th, 2013
Ohjelmistotutkimus (software studies) on verrattain uusi tulokas kulttuurintutkimuksen kentällä. MIT Pressin kirjasarjassa on aiheesta julkaistu jo muutama teos, joista viimeisin on 10 PRINT, tai koko komeudessaan:
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Koodinpätkän voi kukin kirjoitella Commodore 64:äänsä tai VIC-20:een, ja lopputuloksena pitäisi tulla labyrinttiä muistuttava mutkikas kuvio (ks. lopussa oleva kuva). Lyhykäisesti selitettynä ohjelma tulostaa satunnaisesti joko merkin 205 (kenoviiva) tai 206 (kauttaviiva), joiden interaktiosta syntyy loputtomasti enemmän ja vähemmän aitoja sokkeloita.
Kirja käsitteleekin aihetta sitten kaikkea muuta kuin lyhykäisesti – kansien väliin on saatu 309 sivua erilaisia variantteja ja sivupolkuja. Kirjoittajia on peräti kymmenen ja joukossa joitakin tuttujakin nimiä, kuten monessa tekniikan historian liemessä marinoidut Nick Montfort ja Ian Bogost, sekä Processingin toinen isä Casey Reas. Teosta on työstetty yhteisvoimin Wikissä, joten yksittäisen kirjoittajan panosta on mahdoton arvioida erikseen. Moderniin tyyliin koko kirja on myös ladattavissa pdf-muodossa verkosta sen kotisivuilta.
Lyhyeltä vaikuttavasta ohjelmanpätkästä singotaan moneen suuntaan, kuten labyrintteihin, ruudukon käyttöön kuvataiteessa, satunnaislukuihin, Commodoreen ja BASIC-ohjelmoinnin historiaan, mikä osoittaa ainakin sen, kuinka monimutkaisia kulttuuriset kytkökset ovat. Paljon sivuja on uhrattu onelinerin erilaisille varianteille ja muille alustoille tehdyille porttauksille. Milloin muunnellaan merkkien satunnaisuutta, milloin käytetään eri merkkejä tai toteutetaan samanlainen ohjelma jollakin aivan toisella alustalla, kuten Atari 2600:lla. Jokaisen sivupolun kautta päästään kertomaan jotain uutta laitteista, ohjelmointikielistä ja algoritmeista. Loppupuolella on hieman puuduttavan puolelle venähtänyt luku, jossa pitkien BASIC-esimerkkien kautta ratkotaan sokkelon ohjelmallista läpikäyntiä.
Välillä tuntui siltä, että onpas tässä keksitty nokkela punainen lanka, joka sitoo yhteen monia erilaisia teemoja – välillä taas siltä, että on ollut pakko tehdä tikusta asiaa, kun yhden rivin BASIC-pätkä ei ole kuitenkaan kantanut ihan kolmensadan sivun verran. Ehkä parasta antia itselleni olivat viittaukset taidehistoriaan ja satunnaislukujen merkityksen käsittely. Teknistä ymmärrystä tarvitaan melko paljon, jos kirjan teemoja aikoo oikeasti ymmärtää, vaikka toisaalta tuntuikin siltä, että joissakin yksityiskohdissa on popularisoinnin hengessä oikaistu hieman liikaakin. Summa summarum: mielenkiintoinen avaus, jonka kautta voi hahmottaa ainakin 1980-lukulaista ajattelua; aikaa, jolloin ohjelmointi tuli koteihin ja oli vielä luonteva käyttökohde tietokoneelle.
April 15th, 2013
Thanks to Nyyrikki, MSX1 developers can now save time when debugging their code with openMSX. He modified the original ROM so that it will skip the boot logo and the memory test. To make it work with openMSX I put together a hardware description file for a machine called msxfast. The files:
Less waiting, more programming – starting a .com program from autoexec.bat is now full five seconds faster! Originally, it took 12 seconds to get there, now only 7.
April 4th, 2013
Pääsiäisen viihteestä vastasi Revision 2013 Saksan Saarbrückenissä. Revision on käytännössä viimeinen iso kansainvälinen demoparty The Partyn lerpahdettua ja Assemblyn sekä The Gatheringin muututtua pikemminkin pelitapahtumiksi. Aiemmin party tunnettiin nimellä Breakpoint. Noin kauas ei viitsinyt lähteä ilman mitään omaa tuotosta, joten edellisenä iltana, lentokoneessa, bussissa, hotellilla sekä partypaikan aulassa koodattiin ankarasti deadlineen saakka ja hiukan sen ylikin. Lopputuloksena syntyi pitkästä aikaa MSX:lle demo, VJ-henkinen Amurisus. Youtube, Pouet ja msx.orgin hieman apologeettinen uutinen aiheesta.
Tein ensimmäiset MSX-produni vuonna 1997, jolloin työkalut olivat vielä primitiivisiä. Koskaan en ole koodannut itse MSX:llä, vaan heti alusta asti oli käytössä TASM-niminen assembler MS-DOS:n alla. Aivan alussa rämppäsin korppua PC:stä MSX:lle testausta varten, mutta aika nopeasti koko kehitys siirtyi PC-pohjaiseksi, kun fMSX-emulaattori alkoi olla varteenotettava vaihtoehto oikealle koneelle. Edelleenkään ei olla siinä tilanteessa, etteikö lopulta olisi pakko testata myös aidolla koneella, koska etenkin MSX1:n videopiiri on jonkin verran arvaamaton, kun liikutaan sen suorituskyvyn rajoilla. Vuoteen 2008 asti käytössä oli Yzin assemblerilla kirjoittama musiikkirutiini, jossa säveltäminen tapahtui nuotteja käsin datalauseisiin kirjoittamalla.
Tätä nykyä puhtaalla asmilla kirjoittelu olisi jo hieman tuskallisen puolella, vaikka Z80 onkin ykkösnimi perinteisten kasibittisten prosujen joukossa. Onneksi työkalut ovat kehittyneet oleellisesti, joten pääosa koodauksesta tuli tällä erää tehtyä ihan C-kielellä SDCC:n avustamana. Sekaan saa aikakriittisiä osia varten helposti inline-assembleria, joten paljon parempaa yhdistelmää ei voisi juuri toivoa. Ammoisten bat-viritysten sijasta käytössä on kunnollinen Makefile, joka kääntää tarvittavat osat, rakentaa emulaattorille levytiedoston ja käynnistää demon joko OpenMSX:ssä tai Nowindin yli oikealla koneella. Amurisusia tehdessä käytimme ensimmäistä kertaa versionhallintaa: lähdekoodi oli Tampereella sijaitsevassa Subversion-palvelimessa (itse istuimme Saksassa pöydän eri puolilla), mikä säästi reilusti aikaa ja vaivaa jopa näin pienessä projektissa, kun kahden koodarin rinnakkaiset muokkaukset sai yhdistettyä ilman eri sählinkiä. Sivutuotteena syntyi vielä varmuuskopio lähdekoodista. Musiikin sävellykseen on nykyään tekstieditoria helpompia tapoja, etunenässä alun perin Amstrad CPC:tä varten tehty Arkos Tracker. Kasibittikoodauksessa tarpeelliset kuvakonvertterit ja esilaskennat tein Processingilla, mikä säästää sekin vaivaa aiempaan C-kielellä näpyttelyyn verrattuna.
Lopputuloksesta tuli sunnuntain pikku viilailujen jälkeen varsin tyydyttävä. Mitään teknisesti mullistavaa tuossa ajassa ei olisi ehtinyt tehdäkään, mutta onneksi konsepti kantoi ja musasynkka toi ryhtiä muuten sekalaiseen sisältöön. Sijoitus jäi kilpailussa vaatimattomaksi, sillä taso oli varsin kova ja muut produt ilmeisen työllä ja tuskalla väännettyjä. Nykyään demoja tulee tehtyä joka tapauksessa omaksi huviksi, eikä palkinnoilla tai sijoituksella ole enää sanottavaa merkitystä – saatiinpahan kikkare harrastuneen yleisön nähtäväksi. MSX-yhteisöön tällainen happoinen kokeilu ei luultavasti vetoa, sillä demoja tuntevienkin tyyppien viitekehys on yleensä tukevasti 1990-luvun alkupuolen nostalgisissa MSX2-tekeleissä.
April 1st, 2013
Otetaan tästä nyt lopultakin selvä, eli millainen on Spectrumin näyttömuistin rakenne? Tätä sivua tavaamalla ja emulaattorilla kokeilemalla asia alkoi valjeta – eikä kovin lupaavalta näytä pelejä tai demoja ajatellen. Ei sinänsä mikään yllätys Herra Sinklairrin tekeleiden kohdalla 🙂
Spekussa on tunnetusti vain yksi yksi tarkkuus, 256×192 pikseliä, joka koostuu kuuden kilotavun (6144 tavua) bittikartasta osoitteessa 4000h (16384) ja sen perässä sijaitsevista attribuuteista osoitteessa 5800h (22528). Attribuutit ovat se selkeämpi osuus: jokaista 8×8 pikselin laatikkoa kohti on lineaarisesti tavu, joka määrää merkkipaikan etu- ja taustavärin. Vaikkei Spekussa aitoa merkkimoodia olekaan, niin attribuuttimuistin 768 tavua muodostavat merkkitarkkuudella 32×24-ruudukon. Käytössä on kasibittikoneille tyypillinen kolmebittinen RGB, mistä saadaan kahdeksan väriä. Lisäksi on käytössä välkytys- ja kirkkausbitit, joten yksi attribuuttimuistin tavu vkttteee sisältää seuraavat tiedot:
- v – etu- ja taustavärin keskenään vaihtelu so. välkytys
- k – kirkkaus eli merkin värit valitaan kirkkaamasta paletista (pl. musta, joka säilyy ennallaan, joten sävyjä on kaikkiaan 15)
- ttt – taustaväri (nolla bittikartassa)
- eee – etualan väri (ykkönen bittikartassa)
Bittikartta onkin sitten mutkikkaampi tapaus. Yhdessä tavussa on kahdeksan pikseliä, ylin bitti vasemmalla ja alin oikealla. Täysi osoite bittikarttaan vaatii viisi bittiä x-koordinaatille ja kahdeksan y-koordinaatille, sekä tietysti bittikartan perusosoitteen. Looginen ratkaisu olisi ollut muodostaa osoite tyyliin yyyyy yyyxxxxx, mutta ilmeisesti merkkien piirtämisen nopeuttamiseksi järjestys on toisenlainen. Kokonainen osoite on muotoa 010kkyyy mmmxxxxx seuraavasti:
- 010 – bittikartan osoite eli 4000h
- kk – kaistale, ruutu jakautuu kolmeen 2048 tavun kaistaleeseen
- yyy – y-koordinaatti merkin sisällä
- mmm – pystysuuntainen merkkipaikka kaistaleen sisällä
- xxxxx – tavun x-koordinaatti
Lineaarisen y-koordinaatin voi siis ajatella koostuvan biteistä kkmmmyyy, mikä valitettavasti tarkoittaa sitä, että muistiosoitetta muodostaessa bittejä pitää shiftata suuntaan ja toiseen verrattain mutkikkaasti. Nopeutusta voisi saada laskemalla siirrokset valmiiksi taulukkoon, mutta ei taulukon lukeminenkaan mitään nopeaa ole. Spritejen kanssa ongelma on verrattain pieni, kun vaakasuuntaan voi piirtää lineaarisesti, mutta esim. viivanpiirrosta tulee väistämättä hankalaa, jollei koko ruutua piirrä lineaariseen puskuriin, jonka hurauttaa sitten rivi kerrallaan näyttömuistiin.
Nettiä penkoessa on tullut vastaan muutama muukin oleellinen seikka. Muistialue 4000h–7fffh on hidasta muistia, eli sitä käsittelevät yhtaikaa sekä Z80 että ULA, ja konfliktin sattuessa prosessori jää odottelemaan. Bordereissa ei muistia käsitellä, joten siellä Z80 toimii täydellä nopeudella. Useimmissa kasibittikoneissa on vastaava ongelma, jota on ratkottu enemmän ja vähemmän onnistuneesti – esimerkiksi MSX:ssä pitää ruudunpiirron aikana näyttömuistia käsittelevää koodia keinotekoisesti hidastaa, ettei videopiiri roskaa kuvaa. Reunuksen värin voi Spectrumissa säätää suoraan portista feh alimmilla kolmella bitillä. Samassa portissa ovat myös kaiutinta ja kasettiulostuloa kontrolloivat bitit.
Uudemmissa Spekuissa ja klooneissa on vielä omia hienouksiaan. 128k:sta alkaen käyttöön ilmestyi toinen ruutupuskuri, joka sijaitsee pankissa 7. Tuplapuskurointi onnistuu vaihtamalla ULA:n näyttämään jompaa kumpaa ruuduista. Tarkemmin biteistä täällä. Näin äkkiseltään näyttää kyllä aika inhottavalta, että toisen puskurin käyttö varastaa 32 kiloa muistiavaruudesta, sillä ensimmäinen puskuri on kiinteässä paikassa ja ainoastaan muistin lopussa olevan viimeisen pankin voi vaihtaa. Neukkukoneissa on vielä omia laajennuksiaan, kuten väri per pikseli -grafiikkamoodi sekä “kirkas musta” väri, jolla saa käyttöön täydet 16 sävyä. Esim. Pentagonissa ei ole hidasta muistia, joten kone on hieman nopeampi, mikä näkyy toisinaan hidasteluna, kun russiademoja ajaa länsikoneilla.
Oman lisänsä soppaan tuovat vielä eri Spectrumien ruudunpiirron ajastukset. Ajoittamalla koodi tarkkaan yksiin ruudunpiirron kanssa on tehty kaikenlaisia nokkelia efektejä kuten vaikkapa värien lisäämistä välkyttämällä tai väritarkkuuden kohentamista merkkiä tarkemmaksi. Noin nyrkkisääntönä näyttää olevan niin, että kaikki vanhan koulun laitteet ja +2 ovat ajastuksiltaan samanlaisia, kun taas +2A/+3 ja neukkukloonit erilaisia. Kloonitkaan eivät ole keskenään samanlaisia (esim. Scorpion vs. Pentagon), joten lienee haastavaa tehdä ajastuksiin perustuvia demoja tai pelejä, jotka toimisivat kunnolla joka koneessa.
edit: Olikin pikku bugi attribuuttimuistin kohdalla, oikeat bitit ovat vkttteee.
November 18th, 2012
Kohta parisenkymmentä vuotta erilaisia emulaattoreita seuranneena pitänee sanoa tästäkin aiheesta jotain. Erinomaisten projektien, kuten vaikkapa OpenMSX, Mednafen, VICE tai DOSBox, vastapainona on olemassa lukematon määrä puolivalmiita, hylättyjä, vanhentuneita ja tasan yhdellä alustalla toimivia kämäisiä tekeleitä, joiden kanssa saa haaskattua sekä hermojaan että aikaansa. Ymmärrän kyllä, että ei harrastajaprojekteilta voi juuri mitään vaatia, mutta jotkin asiat voisi saman tien tehdä oikeinkin, kun kerran tekemään ryhtyy. Eli Huono emulaattori -HOWTO:
- Älä missään tapauksessa julkaise sorsia. Eihän niitä kehtaa näyttää, tai niissä on suuria liikesalaisuuksia, tai ehkäpä tällä emulaattorilla tahkotaan vielä joskus rahaa. Kukapa niitä jaksaisi edes lueskella.
- Heittäydy ahneeksi. Kyllä Sinclair QL -emulaattorista pitäisi 50 dollaria maksaa, kun sitä on kerran vaivalla tehty. Ja lisäkohtana:
- Jos kukaan ei kikkarettasi osta, niin älä julkaise sitä ilmaiseksi, eikä etenkään niitä sorsia.
- Sekoita käyttöliittymä- ja emulaatiokoodi keskenään. Näin voit varmistaa, että kerralla hyvin tehtyä käyttöliittymää tai suosikkikirjastoasi ei vaihdeta huonompaan.
- Optimoi tavujärjestykseen perustuvilla kikoilla. Kun sinun koneessasi kerran on MSB tai LSB, niin eiköhän se ole muillakin.
- Keksi oma formaatti. Muiden keksimissä levytiedosto-, kasetti-, rom- ym. formaateissa on aina jokin puute, tai sitten niiden käyttö on vaan muuten ikävää.
- Tee ajastukset silmukoilla. Nopeammalla koneella pyörii sitäkin paremmin!
- Keskity tasan yhteen alustaan. Järjestelmäkohtaiset rajapinnat ovat tehokkaita ja kun kerran kaikilla on se Win…jokin tietty käyttöjärjestelmä, niin turhaa vaivaa miettiä muita. Katso myös kohta sekoita käyttöliittymä- ja emulaatiokoodi keskenään.
- Älä tee emulaattorillesi www-sivuja. Ja tätä täydentävänä kohtana:
- Jos kuitenkin teet www-sivut, niin laita ne parin vuoden päästä katoavaan ilmaispalveluun tai koulusi koneelle, johon sinulla ei ole enää pian käyttölupaa.
Näillä pääsee jo pitkälle, takaan sen. Lisäkohtia voi ehdotella kommenteissa.
January 20th, 2012
One of these projects that might not be useful for anybody, but it was educational for me at least 🙂 For some time I had been looking for a bit nicer and easier way to code for Sinclair QL than just pure asm. There used to be a GCC hack, which can’t even be compiled these days. The other 68k-friendly alternative is vbcc, which has support for various related architectures such as Atari ST and Amiga, but no QDOS. Hacking GCC is nothing I’d love to do in my spare time, so I checked out vbcc instead.
The aim was simple enough: get compiled C code to run on QL at an absolute address (0x30000 in this case, right after the video ram). Dealing with nasty stuff such as executable headers wasn’t necessary, since vlink supports rawbin1 output, which is just good clean binary code and data. In addition to that there was a need for a trivial startup routine, which doesn’t do much more than call _main. The correct way would be to call libvc’s __main, which initializes the stack, the heap and the C library, but since the implementation here is so incomplete anyway, I decided to omit that at this point. The biggest challenge was to create the needed linker script to join different object files and sections to a coherent executable. The example scripts can bring tears to your eyes with their complexity, but to join the three required aout sections (.text, .data and .bss) wasn’t that bad after some orientation.
So, with about five hours of work I got to the point where I could compile and run C code on the QL using my own little Arduino-based transfer cable and software. Plain C without any standard stuff such as includes, stdlib and math isn’t very useful yet, so next it was time to look into that. To my surprise I found out that libvc is not part of the distribution at all. Fortunately, the TOS includes seemed to be almost generic, and since the libs are in aout format as well, I gave them a go as-is. Everything I tried seems to work just fine — of course excluding i/o — so there is no immediate need for a real libvc implementation. A kludge on top of another kludge doesn’t decrease the overall quality significantly 😛
The necessary files are here: vbcc-qdos-poc.zip. In order to compile anything, you need to install vbccm68k, copy the archive contents to /usr/local/vbcc, and then add +qdos to the compiler command line. There’s a lot of broken stuff, questionable hacks and so on, which is why I call it a proof of concept. Anyone willing to take the work further is most welcome to do so. This is enough for my humble purposes, probably coupled with a few additions to deal with the keyboard, screen mode etc.
January 14th, 2012
Next Posts
Previous Posts
