Jälleen on nysvätty metroasemakilpibittiä, tällä kertaa ei itseni vaan työkaverin Tuomas "Dezgeg" Tynkkysen toimesta. Dokumentoinpa tähän muun infon joukkoon kuitenkin. (Osa tekstistä copypastea Tuomakselta.) Nyt on pitkälle selvitetty bittiformaatti, jota softa oksentaa näytöille, eli missä järjestyksessä pikseligrafiikka on bittivirrassa. Kaikki fonttidata on itse CPU:lla, ja näytöt tosiaan hoitavat vain pikseleitä, ja pikselit eivät ole neliöitä vaan erityiseen järjestykseen laitettuja kolmioita.
Itse ohjaussofta ei kai tee databittien jakoa eri LCD-paneeleille, vaan sen (osoitteistuksen) hoitaa joku muu. Softa vain vetkuttaa yksittäistä bittiä, jossa on kaikki data. (Jokin muu bitti voi tietty osoittaa jotakin, mutta datajohtojakin on useampia kai.) Paneelien varsinaisen väylän protokolla on edelleen hieman hämärässä, eli mitä dataa kulkee missäkin johdossa ei ole satavarmaa. Niissähän on käyttöjännitelinjoja, dataa ja osoitteistusta. Datanastoja ja osoitenastoja oli siis useampia.
Löytyi emulaattori (Win85), jolla saa veivattua tuota softaa jopa siten, että I/O-liikenteen näkee. Kyseinen softa tukee mielivaltaisia laitteita, joita se modulaarisesti käyttää DLL-kirjastoista. Tuomas reversasi (binääristähän helposti nähdään) APIn jolla laitekirjastoille jutellaan, ja tuuppasi dataeventit muutamalta näyttöpäivityssekvenssiltä tiedostoihin. Biteistä sitten valistuneita arvauksia ja kuvaahan siitä tulee.
- 1-device-init.txt dumppi i/o-laitteiden alustuksesta
- 2-clear-screen.txt näytön tyhjennys, kaikki kuusi puolta pötkössä
- 3-ulam-hog.txt ULAM-H0G-tekstin tulostus
- print-spa0.txt Test: SPA-0
- print-spa1.txt Test: SPA-1
- print-spa2.txt Test: SPA-2
- print-full-segments.txt näyttö täyteen pikseleitä, jälleen kaikki kuusi
- printline_decoder.py Python-koodi, jolla dekoodataan bitit graafiseksi - myös bittijärjestyksen näkee parhaiten vasta koodista joka sitä parsii.
Numeroiduissa tiedostoissa on io-tapahtumat resetistä ULAM-H0G-tekstin tulostamisen loppuun asti, jaoteltuna kolmeen tiedostoon. UARTtien ym. alustus, näytön tyhjennys, ja itse tekstin printtaus. Lisäksi kaapattu "Test: SPA n" arvoilla n = 0,1,2, sekä WD-testin kaikki segmentit täyttävä tulostus.
Ohjausta varten on jokainen sarake jaettu keskeltä kahtia, joten bittivirta on seuraavanlainen:
- oikealta vasemmalle jokaisen sarakkeen (5 * 24) 12 ylintä pikseliä
- vasemmalta oikealle jokaisen sarakkeen (5 * 24) 11 alinta pikseliä
Yllä olevassa ruutupaperikuvassa on numeroitu mikä bitti vastaa mitäkin pikseliä sarakkeessa.
Emulaattorin tulosteesta sai reverse-engineerattua väyläformaatin. Sanomalla terminaaliin esim. sort -u 3-ulam-hog.txt | grep out saa kaikki ohjelmassa käytetyt PC-portti-arvo-kolmikot, joissa on tapahtunut IO-kirjoitus. Tuosta voi sitten päätellä esim. että ohjelman kohdassa PC = 4036 on kirjoitettu porttiin vaan ykkösbittiä. Tuolla tavoin saa filtteröityä pois kaikki ei-databittikirjoitukset.
Databitit saa siis eristettyä sanomalla "cat 3-ulam-hog.txt | egrep '408a|409b|40b4|40c5'" (taikaluvut osoittavat tietyt kohdat koodissa). Yhteen normi-riviin (eli vaikkapa bootin ULAM-H0G) menee 2208 = 4 * 24 * 23 bittiä. Yhdessä paneelissahan on siis 24 saraketta, sarakkeessa 23 erimuotoista kolmiopikseliä, ja normirivillähän on se neljä paneelia.
Kirjoitusten lukumäärät eri koodikohdissa:
$ sort 3-ulam-hog.txt| uniq -c | egrep '408a|409b|40b4|40c5'
553 408a out 0x42 0x00
215 408a out 0x42 0x01
273 409b out 0x42 0x00
111 409b out 0x42 0x01
610 40b4 out 0x42 0x00
158 40b4 out 0x42 0x01
212 40c5 out 0x42 0x00
76 40c5 out 0x42 0x01
Osoitteet 0x42 ja 0x43 menevät näyttöväylälle, 0x10 ja 0x11 yhdelle uartille, 0x20 ja 0x21 toiselle, 0x40 näyttöjä hoitavan piirin mode-porttiin ja 0x33 toisen piirin modelle.
Emulaattorilla ei tietenkään vielä emuloitu itse oheislaitteita eli noita i/o-piirejä - cpu lukee niiltä jotakin, mutta lukemiset laitettiin palauttamaan emussa vain nollaa. Hyvin sitä grafiikkaa silti tuli, mutta jokin synkronointi, osoitteistus tms. saattoi jäädä huomiotta.
Sitten vielä pitäisi ehtiä oikean raudan ääreen tarkastelemaan, mihin nuo bitit menevät ja mistä osoitteistus tulee. Aiemmin eräässä hacklab-sessiossahan tutkittiin, miten itse väylän nastat menevät. Osaa osoitteistuksesta voi tietysti tutkia myös emulaattorilla assemblykoodi toisessa kädessä, kun näkee miten cpu miettii bittejä.
Pitäisi myös tarkastella, onko itse periferaalipiireissä (jotka tuolla muistiavaruudessa elävät mihin bitit viskotaan) jotain siirtorekisterikaltaista tai laskurinomaista älyä, vai hoitaako sen ihan jokin ulkoinen muu piiri. Osoitenastat vaikuttavat ainakin siltä, että ne voisi kaivaa helposti bittien määrästä laskuripiirillä. Ohjainkortilta lähtee iso leveä väylä per puoli, mutta itse lcd-paneeleille menee (käyttisten lisäksi) jonkinlainen enable-nasta sekä kolme datalinjaa. Helposti piippaillaan yleismittarin jatkuvuusmodessa väyläliittimeltä, että mitkä nastat menevät millekin piirille. Lopuksi vielä sitten logiikka-analysaattori nuuhkimaan ja siitä sitten vertaamaan näihin lukuihin.
0 kommenttia
Oma kommenttisi
Mielipide tämän sivun asiasta? Kirjoita toki. Älä raapusta kuitenkaan ihan asiattomia juttuja.
Jos on yksityisempää asiaa, tarkkaa kysyttävää tai aihetta pidemmälle keskustelulle, käytä yhteydenottolomaketta kommentoinnin sijaan.
Hölmöt kommentit saatetaan moderoida pois jälkikäteen.