Posts filed under 'koodi'

Intel MEI + Linux + fan control

Everything related to meifand was moved to its separate project page: http://www.kameli.net/marq/?page_id=4263

Add comment December 12th, 2015

Nyt hakkeroimaan!

Nähtyäni tämän iski lievä tuskastuminen hakkeroinnin nykyiseen olemukseen. Kun tämä hakkerointi on kerran niin hienoa ja coolia ja uskottavaa ja innovaatiota ja täynnä bisnespotentiaalia, niin eiköhän pistetä oikein työryhmän voimin hakkerointitapahtuma pystyyn. Sponsoreita, bisnesenkeleitä, alustuksia ja tervetuliaissanat Tekesin edustajalta. Ja lehdistö tietysti paikalle! Ihanaa, että meillä Suomessakin on lopulta tällaista hakkeripöhinää.

Ehkäpä näkemykseni ovat romantisoituja ja aikansa eläneitä, mutta todennäköisemmin uskon niiden aitojen hackien syntyvän, kun asialle omistautunut jamppa koodaa ja kolvaa kolmatta päivää putkeen kalsareissaan yksiönsä tai opiskelijasolunsa hämärässä. Hakkeroinnin kotouttaminen ja laitostuminen palvelevat vesittyneisyydessään tuskin edes liike-elämän tarpeita, mutta onhan julkisuudellakin oma arvonsa – tosin tuskin niille itse hakkereille.

edit: selvennyksenä vielä, että minun puolestani on ihan ok, jos joku haluaa järjestää IT-messut. Hakkeroinnin valjastaminen kravattipantterien keppihevoseksi ilmentää kuitenkin sekä tietämättömyyttä että epäkunnioitusta hakkerikulttuuria kohtaan.

Add comment November 6th, 2015

Skrolli 1/2015

Skrollin tämän vuoden ensimmäinen numero ilmestyi juuri, ja mukana on taas omaakin tekstiäni: Maisemia Perlin-kohinalla. Kuten nimikin vihjaa, artikkelissa tehdään Processingilla pieni reaaliaikainen 3D-maasto käyttäen Perlin-kohinaa muodon laskentaan. Teron piirtämä takakannen PETSCII-kuva on sekin tutulla edikalla tehty.

grabbi spock

Add comment March 18th, 2015

PETSCII-artsua

Mattis Folkestad ilmoitti juuri, että hänen tekemänsä retrohenkinen PETSCII-muotokuva Lookin’ on esillä Emptymixupframe II -näyttelyssä Oslossa. Tässähän tulee koettua suorastaan isällistä ylpeyttä, sillä työ on tehty koodaamallani PETSCII-edikalla. Alla näpsy paikan päältä:

emptymixupframe

edit: Lisää vaan, tämäkin on tehty edikalla.

Add comment October 29th, 2014

Erään ryhmän retrospektiivi

Vanhat Fit-demot alkoivat muuttua hiljalleen vaikeasti ajettaviksi – Mäkillä lähes mahdottomiksi. Kymmenen vuotta sitten tietotekninen kenttä näytti kovin erilaiselta: esimerkiksi Mäkkäreissä oli vielä PPC-prosessorit. Rosettan kadottua Mac OS 10.7:n myötä ei vanhoja produja saanut enää helposti näytille, kun en jaksanut ruveta kääntämään ja paketoimaan kaikkia yksitellen jälleen kerran. Raspberry Pi:n myötä iski taas pieni porttausinto pari vuotta sitten, mutta kaavailtu demokokoelma jäi silloinkin tekemättä. Nyt sain lopulta aikaan, kun Manukin teki menuun grafiikat:

FitForAutopsy

Raspi-versio on vielä tekemättä, mutta Linuxilla ja etenkin OS X:llä saa nyt nuo kymmenen tekelettä ajettua. Vanhaan malliin sorsat ovat taas jaossa, tällä erää SVN:ssä: svn://www.kameli.net/marq/autopsy. Jos intoa ja aikaa sattuu riittämään, niin olisihan tuohon lisättävää. Etenkin 4k-introt olisi kiva saada kaikki. Anataus 5–7:n sorsat ovat hukassa, joten ne jäävät aika väistämättä sarjasta puuttumaan. Niin ja sitten vielä se linkki.

edit: Oli jäänyt libbejä pois OS X -versiosta. Nyt pitäisi olla toimivampi.

Add comment October 19th, 2014

Panana 1.0

Panana 1.0, the first version of the Arduino-based PC -> Panasonic JR-200 transfer cable is now finished and published. You’ll find all the necessary bits like software and some instructions on the Panasonic page, as usual. Here’s the schematic and the final cased contraption:

panana-fixed lodju

There would be sooo much to add, like two-way transfer, support for BASIC files, a card reader and extra RAM, but let’s see if I ever get to that. At the moment the kludge already supports what I most want to do with it: test my own software. The transfer speed increased due to some final touches all the way from 5 kcps to 8 kcps, mostly because of using phi2s instead of phi2 for sync. Surely there’s room for improvement – next I’ll probably try halting the CPU when updating the latch – but as the speed is already more than 30x compared to the cassette port, there shouldn’t be too much to complain about. Thanks to Tero for his help and comments, too!

edit: Fixed the pinout of the expansion port.

Add comment September 25th, 2014

One more tool

For the ever-improving Panasonic JR-200 toolkit: one more little piece of code. It’s called cjrinfo and shows pretty much all the useful information concerning a CJR file, such as the baudrate, filename, block addresses, lengths and so on. Grab and compile: cjrinfo.c.

Add comment September 14th, 2014

Kohti siirtopiuhaa

Eräs pahimpia Panasonic JR-200 -koodailun esteitä on kunnollisen emulaattorin tai nopean siirtoratkaisun puute. Virtual Panasonic JR ei yksinkertaisesti riitä laitteistonläheiseen ohjelmointiin ja on muutenkin ajan hampaan pahasti kalvama Windows only -tekele. Kasettiportin kautta voi pöristellä softaa helposti sisään aidolle koneelle äänikortista, mutta 2400 bps käy tuskaisen hitaaksi vähänkin isommilla tiedostoilla, minkä lisäksi joka välissä pitää olla näppäilemässä latauskomentoja. Eli hakusessa olisi jotain “resetoi kone ja se lataa koodin” -tyylistä ratkaisua. Mitään sellaistahan ei tietenkään valmiina ole noin marginaaliselle koneelle, joten lähdimme Teron kanssa kyhäämään omaa siirtopiuhaa.

Elektroniikan vähäinen tuntemus asetti tiukat puitteet sille, kuinka valmiista komponenteista kikkale pitäisi tehdä ja kuinka mutkikkaaseen ratkaisuun rahkeet riittäisivät. Arduino oli tuttuna laitteena luonteva lähtökohta rajoituksistaan huolimatta, ja loput palaset koottiin normaaleista logiikkapiireistä: halpa EPROM, salpapiiri (latch) dataväylälle ja perinteinen GAL osoiteväylää dekoodaamaan. Sekaan vielä fiilispohjalta heitetty konkka kohinaa vaimentamaan 🙂 Olemattoman dokumentaation takia Panan laajennusväylän pinnitkin piti ensin selvittää omatoimisesti yleismittarilla – onneksi kaikki tarpeelliset sentään löytyivät. Sivussa piti opetella käyttämään eprommeria ja tutustua GAL-ohjelmointiin, mutta niistäkin selvittiin. Eprommerin käyttämiä jed-tiedostoja sai tehtyä eqn2jed-ohjelmalla. Tältä näyttää kahden väyläosoitteen dekooderi ($d800 ja $8000 viisi ylintä bittiä):

  CHIP GALLI 16V8
  i0=1 phi2=2 rw=3 vma=4 a11=5 a12=6 a13=7 a14=8 a15=9 gnd=10
  i1=11 o7=12 o6=13 o5=14 o4=15 o3=16 o2=17 lat=18 rom=19 vcc=20

  EQUATIONS
  /lat = !vma * !rw * a15 * !a14 * !a13 * !a12 * !a11 * !phi2
  /rom = !vma * !rw * a15 * a14 * !a13 * a12 * a11 * !phi2

Ohjelmistopuolellakin riitti haasteita, kun kolme tietokonetta piti saada toimimaan keskenään synkronoidusti. PC-päässä istuu lähetyskikkare, joka lähinnä lukee tiedoston levyltä ja lähettää sen Arduinolle sopivan verkkaiseen tahtiin. Arduinon sarjapuskuri vuotaa helposti yli (128 tavua kaikkiaan, kaksisuuntaisella lähetyksellä ilmeisesti 64/64), joten välillä pitää jäädä odottelemaan kuittausta. Suurin ongelma oli Artturin ja peeseen saaminen aluksi synkkaan, jottei tavuja menisi hukkaan puolin eikä toisin. 115200 bps sarjasiirto toimi lopulta varsin luotettavasti eikä ole edes nopeudeltaan pullonkaula. Sekä Linuxin että Arduinon pitäisi toimia suuremmillakin nopeuksilla: pikku kokeilulla myös 230400 meni läpi, mutta kun en ollut varma Mäkin tuesta, niin jätin nopeuskokeilut sikseen.

Arduinon ja Panasonicin välinen siirto vaati enemmän jumppaamista. Vaikka siirto meni varsin lujaa läpi suurimman osan ajasta triviaalillakin latchin rämpytyksellä, niin välillä tavuja kuitenkin putoili. Toimiva ratkaisu perustui lopulta siihen, että kun pana lukee siirrossa käytettävää muistiosoitetta, niin se liipaisee lopettaessaan Artturilta keskeytyksen, jossa liipaistaan salpapiiriin uusi arvo. Näin varmistui se, ettei liipaisu tapahdu kesken osoitteen lukemisen. Nopeus putosi samalla puoleen, mutta tärkeämpää oli saada tavut perille. Optimoinnin jälkeen todellinen siirtonopeus asettui n. viiteen kilotavuun sekunnissa. Silläkin täyttyy jo koko muisti seitsemässä sekunnissa pakkaamattomalla datalla.

Aiemmissa siirtopiuhoissani olin käyttänyt yksinkertaista alternating bit -toteutusta, jossa vaikkapa kahdesta pinnistä toinen on kello ja toinen itse data. Nyt oli kuitenkin käytössä juhlavat kahdeksan bittiä kerralla, ja mieli teki siirtää täysiä tavuja kerralla ilman bittien shiftaamista. Kotipolttoisena ratkaisuna tein niin, että peräkkäiset tavut muuttuvat joka kerta, jolloin Pana tunnistaa seuraavan tavun pelkästä arvon muutoksesta ilman erillistä synkronointia. Pitkien nollasarjojen ym. tehokkaan siirron vuoksi tavuihin sotketaan mukaan “kantoaalto”, joka miinustetaan vastaanottopäässä. Jokunen harva tilanne, jossa peräkkäiset tavut ovat sittenkin samat, hoidetaan erillisellä escape-merkillä.

viritys pannaani1 vers_5_9_2014

Nyt on jo kotelokin ja kaikki. Oikealla Teron PETSCII:nä piirtämä piirikaavio, josta näkyvät piirit ja niiden väliset kytkennät tarkemmin. Kehityskohteita olisi tietysti lukuisia:

  • Pienemmällä rommilla säästyisi tilaa levyltä: nyt on käytössä kokonaiset 256 tavua 128 kilon piiriltä. Mutta kun niitä sattui olemaan…
  • Arduino Nanon voisi korvata ATMegalla, kunhan vaan saisi USB-liikenteen ja virransyötön jotenkin hoidettua. Toinen vaihtoehto olisi halvempi Arduino Micro.
  • Sekaan roiskaistu yksinäinen konkka ei välttämättä tee mitään hyödyllistä: pitäisi tutustua joskus tarkemmin, mihin ja millaisia niitä oikeasti tarvitaan
  • Siirtosofta voisi palata BASIC-tulkkiin ja ylipäänsä tehdä vähän enemmänkin asioita
  • Koko härpättimelle päälle/pois-kytkin
  • Resettinappi, jos mahdollista laajennusportin kautta
  • Oikean kunnon piirilevyn teettämällä saisi tilaa säästettyä huomattavasti samoin kuin hyppylankasotkua

Puutteineenkin Panana ratkaisee pääongelman eli nopean koodin siirtämisen peeseeltä Panasonicille. Jatkokehityksen toppasi toistaiseksi se, että eBayltä haalimani Kiina-Nanot osoittautuivat viallisiksi (kloonatut FTDI-piirit eivät osaa kaksisuuntaista liikennettä). Kunhan saan toimivampia, niin julkaisen koko projektin sitten virallisestikin Panasonic-sivulla.

Add comment September 6th, 2014

Toshiba FlashAir, command line, retro machines and all

A couple of weeks ago I didn’t even know that there are WLAN-enabled SD cards, but such beasts exist indeed. Usually they are meant for cameras and automatic uploading of recent photos, but a creative mind can quite obviously think of a lot of other uses for them. The most interesting product seems to be Toshiba FlashAir, since it allows file upload unlike most other devices. It’s not too expensive either, so I got myself the 8G model.

Instructions on setting up the card can be found on other sites. As a matter of fact, the documentation is surprisingly extensive. At its heart the card contains a web server that can be used for different transactions (plus those automatic uploads that I’m not interested in). It didn’t take much effort to edit the needed config file to get the gadget set up. After that you just need to find out its IP and start browsing. There are various hidden CGI files, such as upload.cgi, that let you do a number of things ranging from file browsing to configuration. They and their parameters are all described on the FlashAir Developers’ site.

I expected there to be some ready-made handy tool for file handling and maybe there is, but all I could find were various code snippets in Python or PHP. Browser-based file handling isn’t that great, so I ended up hacking together a little shell script called FA that lets you do the most needed basic stuff from the command line. Should work in any *nix, as long as you’re using bash and have cURL installed. Maybe even Cygwin or similar, who knows. Use as you wish, but don’t come complaining to me if your files were lost 🙂

The original reason for getting the card was to use it with various oldschool computers and their card readers. So far I’ve only tried Sinclair QL and it kind of works. The only remaining problem is that the card doesn’t deal well with reset: after that you need to reinsert it, which sort of beats the purpose of wireless data transfer. After reinserting the card it also takes about 10 seconds to be back online, which is a bit annoying if you need to wait for it frequently. I’ll update this post when I’ve experimented with other machines.

flashair

I’m sure there’s more to discover when dealing with other machine/card reader combinations. For example, I don’t know if the filesystem needs to be FAT32. If so, some readers will not work.

edit: Similar behavior with the 1541 Ultimate. Initially the card works like an angel, but after the C64 has accessed the virtual drive the web server disappears until the next cold boot or card reinsertion. Mere reset doesn’t help.

edit2: Another interesting discovery is the user IO mode, where you can control individual SD pins as you see fit. Could make an interesting wireless controller or something.

edit3: According to Tero’s tests, the card works better with a ZX Evolution. It seems that the Evo doesn’t kill the WLAN after a reset.

Add comment August 11th, 2014

Sohaisu Spectrumin suuntaan

Vääjäämättä koitti se päivä, kun Spectrumillekin piti jotain yritellä. Vammala Party’14:ään kyhättiin siis pieni intro, jossa on biisi, kuva ja kahdeksan “aitoa” 16×16 spriteä. Yzi teki biisin ja Terppa suurimman osan koodista sekä grafiikat; itse touhusin mukana lähinnä spriterutiinia ideoimassa, Arkos-soittorutiinia Spectrumille sovittamassa sekä kehitysympäristöä kasaamassa. Lopputulos toimii klassisella 48k-kumpparillakin, joskin ääniä varten tarvitaan AY- eli PSG-moduuli kuten Wonder AY.

Spritejen piirtely ei ole mitenkään erityisen hauskaa Spectrumilla, sillä rauta ei niitä mitenkään tue, grafiikkamuistin järjestys on mutkikas, värirajoitukset iskevät nilkkaan, eikä 48k:ssa ole edes grafiikkasivuja. Piirto- ja pyyhintäjärjestyksen on oltava niin ollen tarkkaan harkittu ja ajastettu, etteivät pallot repeile ja välky. Tero on käsitellyt aiheeseen liittyvää problematiikkaa syvällisemmin blogissaan. Aitoihin spriteihin tarvitaan tietysti reikiä varten läpinäkyvyys, mikä tarkoittaa, että uuden tulokkaan alla olevalle grafiikalle tehdään ensin maskin kanssa AND ja sitten varsinaiset pikselit lisätään päälle OR-operaatiolla. Jos jotain hyvää hakee, niin Speku on aika nopea grafiikkamuistinsa käsittelyssä, ja muisti sijaitsee ainakin normaalissa osoiteavaruudessa, toisin kuin vaikka MSX:llä.

Musiikkipuoli hoitui helposti jo tutuin konstein eli Arkos Trackerilla ja sen omiin tarkoituksiin muokatulla toistorutiinilla. Virittelyä vaati oikeastaan vain porttiosoite ja porttikomentojen muuttaminen kaksiosaisiksi. MSX:ltä tuttu

 out (0xa0),a

piti muuttaa muotoon

 ld bc,#65533
 out (c),a

Speku on sikäli harvinainen laite, että se käyttää Z80:n täyttä 16-bittistä porttiavaruutta päinvastoin kuin muut tunnetut laitteet. Käsky on siis salaa itse asiassa out (bc),a.

Z80-konekieli oli vanhastaan tuttu, ja kun SDCC:n kanssa oli tullut säädettyä jo aiemmin sekä MSX:llä että Sharpilla, ei työkalujen kasaan saamisessa mennyt kohtuuttoman kauan. Valmiita MSXlibin rutiinejakin sai käytettyä jossain määrin sinältään. Fuse on kelpo multiplattis-emulaattori, joka osaa ajaa tap-tiedostoja suoraan komentoriviltä – eli käytännössä Makefilestä. Eniten kompurointia aiheutti lopulta käännetyn binäärin muuntaminen tap-muotoon, sillä pikaisella hakemisella löytyi vain toimimattomia tai vääränlaisia vaihtoehtoja. Lopulta löytyi onneksi bin2tap, minkä myötä viimeinenkin puuttuva palanen loksahti kohdalleen.

Hauska sivupolku tämä ainakin oli ja saattaa olla, että Spekun äärelle tulee palattua joskus tulevaisuudessakin. 48k on demokoneena tarpeettoman rajoittunut, joten 128k olisi sikäli houkuttelevampi kohde, mutta vaatisi samalla jonkin verran lisää opettelua muistin pankituksen osalta.

the_unhanged

Add comment July 18th, 2014

Next Posts Previous Posts


Kommenttien virta

Aiheet