Prisman halpalaarista tärppäsi kympillä viiden kotimaisen sotilasfarssin kokoelma Asento!, joten kokeillaan nyt sitten tätäkin. Sotilasfarssin kultakausi oli 50-luvulla, kenties testamenttina sodalle ja eräänlaisena kansallisena terapiana. Ainakin sotilasfarssit koskettivat teemaltaan niitä miehiä, jotka olivat hiljattain rintamalta palanneet. Kokoelmia oli Prismassa pari lisääkin – mm. Lasse Pöystin tähdittämiä Monni-leffoja – mutta tähän satsiin osuivat seuraavat merkkiteokset:
- Rykmentin murheenkryyni (1938). Lunki torppari Hemminki Aaltonen ja nössö maisteri Auermaa yrittävät sopeutua tornifirmaan tässä poikkeuksellisen aikaisessa tekeleessä. Alkupuolella on jopa hiukan potentiaalia, kun jäpikkäät ystävystyvät yli luokkarajojen, mutta loppua kohti leffa rapautuu tyypilliseksi hölmöilyksi romanttisin ripauksin. Lopputulema on armeijaa suorastaan ihannoiva, joten tätä voi ajatella ajankohtansa puolesta eräänlaisena rekrymainoksena.
- Murheenkryynin poika (1958). Nyt on Hemminki Aaltosen pojan Heikin aika mennä armeijan harmaisiin. Jäyhä poitsu sopisikin palvelukseen oikein hyvin, mutta hankaluuksia seuraa, kun samanniminen (nössö) kukkakauppias ei meinaa sopeutua kuriin ollenkaan. Lopuksi taas kohelletaan ja saadaan asiat järjestykseen. Kokoelman huonoin.
- Sotapojan heilat (1958). Naisjuttuja on varmasti jokaisessa sotilasfarssissa, mutta tässä romanttiset seikkailut ovat oikein poikkeuksellisen paljon esillä. Alokas Puustinen (Pöysti) pyörittää suurta deittirinkiä, mikä tietysti päättyy katastrofiin, kun huijatut naikkoset saapuvat joukolla paikalle. Varmaankin ainoa oivallus nähdään lopussa, kun alikessuiksi ylenneet entiset simputetut ryhtyvät toistamaan edeltäjiensä maneereja.
- Tyttö lähtee kasarmiin (1956). Ristiinpukeutuminen on komedian peruskiviä, eikä juuri toisin näissäkään leffoissa. Tällä kertaa – hyvänen aika sentään – palvelukseen astuu ehta nainen mieheksi pukeutuneena. Kun huijaus alkaa selvitä, seuraa siitä luonnollisesti monenmoista kiusaannuttavaa tilannetta ja väärinkäsitystä. Statistina vilahtaa mm. itse Spete.
- Vääpelin kauhu (1957). Vanha sodankin nähnyt jermu kutsutaan takaisin ruotuväkeen johtuen taas vaihteeksi nimien sekaantumisesta. Noh, vanhahan taitaa jo temput eikä ota turhaa stressiä äkseeraamisesta. Sivumennen hoidetaan lemmenasioita ja otetaan suojatiksi taas vaihteeksi nössö maisteri, joka ei oikein pärjää miesten koulussa. Ei tätäkään mestariteokseksi voi luonnehtia, mutta varmaankin tämän kasan paras, pitkälti Heikki “Tuntemattoman Hietanen” Savolaisen karisman ansiosta.
Samoista aineista on saatu aikaan hyvin samanlaisia keitoksia. Koomista äkseeraamista, simputusta, lemmenseikkailuja, aamu-unisuutta, pinnaamista, kommelluksia, musiikkinumeroita ja stereotyyppejä löytyy kaikista. Erityisen toistuva kuvio on alokkaan tm. pukeutuminen upseerin vermeisiin, minkä jälkeen komentoketju on hetken hupsusti päälaellaan. Arkkityyppejä ovat mm. räyhäävä alikessu, ankara mutta reilu isoherra, vieraantunut maisteri, pinnaava velikulta, naistenmies, hölmöläinen, vanha kanta-aliupseeri sekä hemaiseva lemmenintressi. Näyttelijätkin ovat usein samoja: jo mainitun Lasse Pöystin lisäksi nähdään ainakin Leo Jokelaa, Tommi Rinnettä ja Siiri Angerkoskea.
Jollen nyt vallan erehdy, niin kaikki kasarmille sijoittuvat ulkoilmakohtaukset on kuvattu Santahaminassa; ainakin saman sillan yli mennään toistuvasti. Paikka sijaitsee kätevästi Helsingissä, mikä lienee ollut eräs merkittävimpiä syitä. Katsotaan nyt, jaksanko näitä enempää kahlata, sillä tästä köykäisestä lajityypistä lienee saanut jo viiden teoksen perusteella varsin kattavan kuvan.
Tyttö lähtee kasarmiin
October 13th, 2016
Pitkällisen lueskelun jälkeen sain loppuun Grant D. Taylorin kirjan When The Machine Made Art: The Troubled History of Computer Art, joka on tietämäni mukaan ainutlaatuisen laaja katsaus tietokonetaiteen historiaan. Käsittely on kronologista ja ulottuu ensimmäisistä tietokoneella tehdyistä kuvista suunnilleen vuosituhannen vaihteeseen saakka. Jo itse termi “tietokonetaide” viittaa historiaan – nykyäänhän puhutaan pikemminkin vaikka digitaalisesta tai (uus)mediataiteesta.
Läpitunkeva teema, joka näkyy jo kirjan nimessäkin, on tietokonetaiteen kohtaama vastustus. Jäin itse miettimään, että onko julkinen keskustelu todella ollut noin vihamielistä, mutta näkemystä on ainakin perusteltu monin esimerkein. Kritiikkiä on satanut sekä aiheellisesti että aiheetta monesta suunnasta: tietokonetaidetta on eri aikoina syytetty niin kaupallisuudesta, temaattisesta köyhyydestä kuin tekniikkakeskeisyydestäkin. Taylor tarjoaa syyksi yhtäältä sitä, että taidemaailma ei pitänyt tontilleen tunkevista tiedemiehistä, ja toisaalta tietotekniikkaa kohtaan tunnettuja yleisempiä epäluuloja.
Kenties suurin käänne tietokonetaiteen historiassa vaikuttaa olleen se, kun (suhteellisen) helppokäyttöiset valmisohjelmat tulivat taiteilijoiden saataville 80- ja 90-luvun kuluessa: musiikin ja grafiikan luominen ei enää vaatinut välttämättä syvällistä teknistä osaamista. Tämäkään suuntaus ei kaikkia miellyttänyt, vaan vanhan polven tekijät kritisoivat moista kyvyttömyyttä. Sittemmin kenttä monimuotoistui ja yhdistyi muihin taidemuotoihin niin pitkälti, ettei ole enää mielekästä puhua pelkästään tietokonetaiteesta, kun tietokone toimii keskeisenä työkaluna niin valokuva- kuin videotaiteilijoillekin.
Kirjasta löytyi joitakin eväitä myös demoskenen analysointiin. Olen jo pitkään pohtinut, onko demoskene pikemminkin moderni (tekijyys on keskeistä, töitä arvioidaan tiukoin kriteerein) vai postmoderni (kollaasit ja tyylillinen lainailu). Muun digitaalisen taiteen tapaan voitaneen sanoa, etteivät demot ole puhtaasti kumpaakaan, vaan niissä on piirteitä molemmista suuntauksista. Esimerkiksi 90-luvulla yleistynyt kerroksittainen “fotarimainen” valokuvien ja efektien yhdistely kytkeytyy laajempiin mediataiteen ilmiöihin sekä työkaluihin, ja kertoo osaltaan siitä, kuinka demoskene on kiinni ajassaan.
October 6th, 2016
Croutonin kanssa oli tullut askarreltua jo aiemmin, mutta sen rajat alkoivat tulla ikävästi vastaan: etenkin videotoisto tökki selittämättömästi, minkä lisäksi chroot-vankilat tuntuivat hiljalleen lahoavan käsiin sieltä täältä. Niin Croutonin kuin Chrome OS:nkin tulevaisuus on suuri kysymysmerkki, joten oli aika kokeilla vaihtoehtoja, jotta Acer C710:ni palvelisi vielä tulevaisuudessakin.
Eräs vaihtoehto olisi ollut Chrubuntu, mutta kun senkään jatkosta ei ole varmuutta, päädyin lopulta dramaattisempaan ratkaisuun, SeaBIOSiin, joka korvaa normaalin firmiksen pelkistetyllä BIOS-versiolla, jonka kautta voi buutata normaaleja käyttöjärjestelmiä. Seuraavaksi ulkoiseen USB-asemaan 64-bittisen Mint/MATE 18:n DVD ja normaali asennus käyntiin. Hiiripädi ei toiminut asennuksen aikana, mutta ulkoisella hiirellä sekin este voitettiin.
Toimii suorilta
- WLAN, Ethernet
- 3D- ja videokiihdytys, ulkoinen näyttö (ainakin VGA-liittimellä)
- Webbikamera
- Kortinlukija
- Äänet ml. kuulokeliitäntä
- Bluetooth
- Akun varaus- ja prosessorin lämpötila-anturit
Toimii säätämällä
- Hiiripädi: jostain syystä Mint estää oletuksena tarvittavan moduulin (i2c_i801) lataamisen. Rivi pois paikasta /etc/modprobe.d/blacklist.conf ja johan toimii. Asetukset ovat vakiona hieman huonot, mutta ohjeita kohentamiseen löytyy. Päivitän postausta, jos jaksan ruuvata synclientin asetuksia enemmän.
- Äänensäätönapit: Fn ei ilmeisesti toimi millään viilaamisella, mutta äänensäädön voi vaihtaa normaaleihin F-näppäimiin paikasta Preferences – Keyboard shortcuts.
- Sama juttu kirkkaussäädön kanssa. Ensimmäinen ratkaisu on asentaa alapalkkiin kirkkausappletti. Asentamalla xbacklightin voi yo. paikasta lisätä F6/F7:lle komennot “xbacklight -dec 10” ja “xbacklight -inc 10”.
Ei toimi
- Lepotila: voisi ehkä olla mahdollista saada toimimaan isolla viilaamisella, mutta tein nyt mieluummin laiskasti niin, että kannen sulkiessa kone menee kiinni (Preferences – Power management).
- Fn-nappi: tähän ei löytynyt oikein googlaamallakaan mitään, joten F-napeille ei saane tuplatoimintoja käyttöön. Eniten harmittaa F10:n menetys äänenvoimakkuuden säätöön, koska sitä tarvitaan emulaattoreissa.
- ACPI: jos olen asian oikein ymmärtänyt, SeaBIOS ei tätä tue, joten nämä hienoudet jäävät kokematta. Kokeilin joitakin buuttiparametreja, mutta acpi_available ei näytä mitään.
Meni suunnilleen kuten odotinkin, eli suurin osa laitteistosta toimii suorilta, kun taas osa vaatii virittelyä. Sleepin puuttuminen on kenties ikävin juttu, kun on kyse mukaan napattavasta pikkukoneesta – toisaalta vanhahko 24-gigainen SSD:kin buuttaa virtanapista puolessa minuutissa, joten mitään massiivista odottelua ei tarvitse sietää. Hiiripädin asetuksia pitäisi jaksaa vielä viilata sujuvuuden parantamiseksi, vaikka ihan riittävän hyvin se toimii jo nytkin.
Pienten kompurointien vastapainoksi saa paljon hyvääkin: videotoisto (jopa fullhd-h264) tai äänet eivät töki, VirtualBox toimii, muistia ja suoritinaikaa ei huku Chrome OS:lle, käytössä on täysi paletti kerneliajureita, levy on selkeästi osioitu, USB-levyillä olevien tiedostojen kellonajat eivät sekoile, päivitykset tulevat kootusti, ja asiat ovat ylipäänsä varsin vapaasti konfiguroitavissa, siinä missä Chrome OS piilotti juttuja alleen. Uskon ja toivon myös, että käyttis ei lahoa samalla tavoilla yllättäen kuin Croutonin chrooteilla on tapana.
Filosofisesti ajatellen kone on nyt pitkälti menettänyt ominaispiirteensä ja on kuin mikä hyvänsä pikkuläppäri, johon on asennettu Linux. Sikäli paljon tässä oli tekemistä ja lopputulos vielä puolinainen, että sujuvinta käyttökokemusta halajavan ei kannata Chrome OS:stä luopua. Jättänen koneen itse kuitenkin toistaiseksi puhtaasti Linuxille, kun se näinkin hyvin toimii, eikä Chromen puolella toisaalta ole yhtään ohjelmaa, jota jäisin kaipaamaan.
Siinä se nyt on ihan todistettavasti.
edit: käyttämällä Chrome OS:n pädiajuria tämän mukaisesti saa satunnaiset hyppimiset ja harhaklikkailut kuriin. Asetuksia olisi hurjasti, mutta taidan jättää suhteellisen ok toimiville oletuksille, kun kone ei missään varsinaisessa tehokäytössä ole.
September 17th, 2016
I suppose this problem will affect many people, so here’s one answer for Google to find. The latest Mint (18) has some graphics problems on at least the integrated GPU of Broadwell chips — others have reported similar issues on Skylake chips as well. It is reasonable to assume that other Ubuntu derivatives are susceptible too. It seems that kernel 4.4 introduced some bug that causes the screen to occasionally turn black for a fraction of a second. Changing the window manager or compositor do not alleviate the problem.
Mint 17.x does not suffer from blinking as it uses 3.x kernels. Updating to 4.6.3 seems to solve the issue as well, so it’s probably not a question of the X server either. The only quirk is that Mint doesn’t let you use other kernels than the 4.4 series easily. Here’s one package with instructions that did the trick, use at your own risk.
August 15th, 2016
I’ve been using various guesstimates throughout the years for the PAL MSX screen and pixel aspect ratios, but now there’s finally something credible instead (in contrast, NTSC machines have ~square pixels). According to this discussion thread, the pixels are as wide as 7:5 or, in other words, they are 1.4 times as wide as they are high. That’s pretty flat! I got almost same figures on my own Philips 1084S using a ruler, so they’re very likely correct. Other calculations:
- The pixel area of a 256×192 image is 5.6:3 — almost the same as a modern 16:9 screen
- That is a multiplier of 1.8666… for the image height to calculate the width
- In terms of square pixels 358×192 is very close, or with double pixels 717×384 even better
Viewing a borderless SCREEN 2 image fullscreen on a 16:9 screen gives a pretty good quick estimate of how it will look like. Two things to note are of course that people’s CRT displays are not perfectly calibrated, and that emulators do not use a correct ratio by default. In general horizontal stretching looks worse than vertical, which might be one reason emulators are a bit conservative with their aspect ratios; for example openMSX definitely produces a narrow image – even setting horizontal_stretch to its minimum value of 256 doesn’t make the image flat enough. Furthermore, Japanese Konami warez would appear unnaturally squeezed, even though that’s exactly how they were seen in Europe back in the day.
Square pixels vs. a corrected image:
edit: just as notes here some other numbers. Out of a 313 line full progressive PAL frame about 61.3% is spent on actual pixel lines, while the remaining 121 lines (38.7%) are for the border (113 lines) and vertical sync (8 lines). Dividing 3.58 MHz by 50 yields 71600 clocks per frame, but as a progressive frame is longer (49.92 Hz), the actual clocks are closer to 71700 per frame or 229 per scanline.
As shown by the IO demo, the exact cycles are not stable across machines, which makes it tricky to do splitting effects on an MSX1. IO uses a timing of 228 cycles/line or 71364 per frame, so those are probably the correct numbers on at least some machines.
edit2: Haven’t confirmed yet whether the MSX outputs 312 or 313 lines per frame, so the figures above are just estimates (there are some other possible error sources too). What is known is that the vertical blanking interrupt (VBI) takes place immediately after the last pixel line, not outside the screen. In addition, ideal Z80 cycles are not correct on real machines, as there are additional T-states introduced by memory access.
August 1st, 2016
Homma on edennyt niin hitaasti ja kankeasti, etten ole kovin paljon kenellekään viitsinyt mainostaa tekeväni taas yhtä opinnäytettä. Nyt, kun kirjoitusurakka alkaa kääntyä loppusuoralle (ensimmäinen raakaversio tuli valmiiksi juuri tänään) niin uskaltanen jo kertoa, että väitöskirja on tarkoitus taputella kuntoon vielä tämän vuoden puolella, sikäli kun ohjaajat, esitarkastajat ja laitoksen moninaiset prosessit sen sallivat. Aiheena jälleen sama kuin lisurissakin eli demoskene, mutta tällä kertaa paremmassa ohjauksessa sekä jo hieman kouliintuneemman humanistin ottein. Turun yliopiston digitaalisen kulttuurin oppiainehan on humanistisen tiedekunnan alla — tätä tilannetta tuskin olisin 1996 kuvitellut näkeväni.
Näin jälkiviisautena tohtorintutkintoon olisi voinut ja kannattanut tähdätä hieman suorempaa polkua. Toisen maisterintutkinnon tekemisestä on ollut käytännössä aika marginaalisesti hyötyä, eivätkä lisensiaatin paperitkaan oikein avanneet uusia ovia nykyisen akateemisen maailman tohtori/ei tohtori -binäärin vuoksi. Noh, kaipa noista opinnoista on edes jotain syvämmen sivistystä tarttunut. Jos voisin nyt neuvoa 2009 itseäni, niin: häivy sen lisurisi kanssa vehreämmille laitumille ja laajenna se siellä monografiaväikkäriksi kunnon ohjauksessa. Moisella oikopolulla olisi säästynyt muutama vuosi.
Olen välillä ollut pikkiriikkisen kateellinen jatko-opiskelijakollegoilleni, sillä he ovat enemmän ja vähemmän kaikki jostain humanistiselta alalta peräisin. Itse taas olen aika kotikutoinen tapaus, sillä en ole maisterivaiheessa koskaan tutustunut humanistisiin tutkimusmenetelmiin, diskursseihin jne., jollei sitten paria taidehistorian peruskurssia lasketa. Asiat voi toki opetella omin nokkineenkin, mutta hieman turhauttavaa ja epävarmaa se on toisinaan ollut toisenlaisesta taustasta tulevalle. En edelleenkään pärjää Foucault/Deleuze/Latour-vyörytyksessä, mutta tutkimusta voi onneksi tehdä maanläheisemminkin.
June 24th, 2016
Somessa tuli taas vastaan joku terveyttä ja hyvinvointia kohentava höpötuote, joita tuntuu markkinoille ilmaantuvan tasaiseen tahtiin. Tuoreessa muistissa lienevät vielä vaikkapa Skudo-säteilysuoja, Power Balance -hologrammiranneke sekä Valkee-korvavalot, eikä homeopatiakaan ole koskaan kartalta kadonnut, vaan tunkee pikemminkin jo apteekkeihinkin. Tästä intoutuneena innovoin puppugeneraattorin, joka soveltuu alan tuotekehitykseen – reloadilla lisää tuotteita: http://www.kameli.net/~marq/energia/
Toteutukseen meni kaikkiaan parisen tuntia PHP:llä. Suurin osa ajasta kului avainsanojen kaiveluun netistä. Tuotemerkki sekä -nimi muodostetaan molemmat satunnaisesti alku- ja loppuosasta (“Bene-“, “Rosa-“, “Vita-” ja sitten “-dol”, “-san” tm. perään), minkä jälkeen arvotaan virkkeeseen loppuosan mainesanat niin ikään taulukoista. Tuotekuvauksen jälkimmäinen puolisko käyttää samoja datoja kuin alkukin, mutta yksinkertainen logiikka varmistaa, ettei mikään aiempi sana toistu. Joitakin hieman kummallisia yhdistelmiä tulee edelleen, mutta se oikeastaan sopii tähän käyttöön.
“Rosasan-pellavalaastari piristää voimakkaasti solujen luonnollista aineenvaihduntaa sekä tukee hermoratojen kokonaisvaltaista ionisaatiota.”
May 27th, 2016
During the last few days I’ve spent hours and hours trying to understand how Oric (Oric-1 and Atmos) hires graphics work. Compared to most 8-bit home computers of the 1980s the mode is notably different with its “serial attribute” based layout. If you know how teletext works, you’ll easily notice certain similarities. You can find multiple elaborate explanations of Oric graphics online, but I’ll try and distill their essence into a few minimalistic rules:
- There are 240 by 200 pixels described by 8000 bytes located at A000h (followed by three hard-wired lines of text which we will omit). One row is 40 bytes.
- There are eight colors to choose from: black, red, green, yellow, blue, magenta, cyan and white ie. a typical 3-bit BGR colorspace from 0 to 7.
- For each byte – describing six not eight pixels – you can do one of the following:
- Change the ink color. Six pixels of paper color will be displayed in this 6×1 block. Byte contents: 0..7.
- Change the paper color. Six pixels of the new paper color will be displayed. Byte contents: 16..23.
- Display pixels using the current ink (1) and paper color (0). Byte contents: 40h + bitmap in the lower-order bits.
- If bit 7 is on, the block will be displayed in inverted colors. Note that the inversion does not affect the result of ink/paper change operations, only the outlook of the 6×1 block. The inversion logic is a bitwise not:
- black – white, 000 – 111
- red – cyan, 001 – 110
- green – magenta, 010 – 101
- yellow – blue, 011 – 100
- Every new row starts with white ink and black paper.
In addition there’s stuff like 50/60 Hz, blinking and text mode setting, but we’ll skip them too. At first the ruleset seems quite simple, but once you actually start thinking of how to do graphics with it, things don’t look that easy anymore. Let’s warm up with a little close-up of a real Oric piccy (“Yessagician” by Dbug):
This is the left edge of the screen and the gray lines denote 6 pixel block borders. How would you choose the operations for displaying the pixels – in particular the area I’ve outlined with a red rectangle?
Solutions: the completely black lines we could show as pixels as the line starts with white ink and black paper, but there’s many other possible solutions too. Every black 6×1 block might actually contain an ink change or perhaps setting the paper to black again. Or setting the paper to white and turning the inverse bit on. The 6×1 blue blocks we could create by simply changing the paper to blue, after which the next identical block could contain an optional ink change.
As to the marked area, however, we need to do something else. Changing the paper to blue on the left leaves us with white/blue which will not do for the next block as there are pixels to be displayed. The only possible solution is to turn paper yellow and invert the colors for both of the blocks. An inverted white/yellow pair provides the needed black/blue for the bitmap.
The first two questions I tried to solve were “Is this picture a legal Oric hires image?” and “How to display a legal image using the possible operations?” There’s more to converting a random image to the Oric, but these two problems have to be understood in order to get anywhere. A first bruteforce solution which didn’t even check all the possible combinations took several minutes to solve just one row of a simple image on a recent i5 computer, so clearly something else had to be done.
For each 6×1 block containing one or two colors there can be multiple solutions. Two-color blocks are the easy case: there’s the bitmap and the colors inherited from the left, possibly inverted. One-color blocks are a different ballgame altogether, since they can contain paper changes, invisible ink changes or they might even be a bitmap. All of this with or without inversion, of course. Another difference is that a two-color block needs to get proper colors from the left, whereas a single-color one can be displayed anytime with a paper change.
The following image tries to convey a conceptual model of how it works:
Each column in the graph represents a 6×1 block and its multiple possible solutions. Some could call this a directed acyclic graph. The first block can be displayed in four different ways, the next only in two and so on – in reality the numbers are a lot higher with singe-color blocks. The arrows denote possible movement from left to right: each way of displaying a given block here limits the options for the next block. For example a block which leaves ink/paper as white/black does not provide for its neighbor in need of red color.
Instead of a recursive approach starting from the left and trying out all the possible solutions it is enough to simply loop through the columns, create the links, optionally dropping the dead-ends (solutions leading nowhere on the right or with no supply from the left) and duplicates (same in/out combinations). If there is a path that runs all the way from the left edge to the right, we can conclude that this particular row is legal. More than one path is possible, but that doesn’t really matter. Walking back from right to left we can collect one legit representation for the row, thus solving the two “research questions”.
When it comes to dealing with images that do not comply or converting a random jpeg, I don’t have much to say yet. Different approaches will lead to better or worse approximations – as of now I simply turn offending two-color blocks to single-color ones, but much more could be done. Further reading and examples here:
edit: some first thoughs on dealing with non-conforming images. The first thing I’d try is make a graph with approximate solutions, make the errors the weights of the vertices and use a shortest path algorithm such as Dijkstra’s to find the nearest possible approximation.
edit2: here’s a bit more visual representation of the bits as a bonus.
May 26th, 2016
A project I’ve been working on for the last few weeks is now out: Pixel Polizei is a helper tool for the retro artist. The purpose is to let the “graphician” draw using whatever software they happen to like, check/force color clashes and finally save the outcome in native formats that can be viewed using emulators or the real deal. So far there is support for these machines and screen modes:
- Amstrad CPC modes 0 and 1 with or without overscan
- C-64 hires and multicolor
- MSX screen 2
- Oric hires
- Plus/4 hires and multicolor
- ZX Spectrum
More formats and platforms will appear when I find the time and motivation again. As usual, the tool should work on Lin/Mac/Win as long as Java 7 or newer is installed. Open source, too.
May 17th, 2016
Next Posts
Previous Posts
