Commodore File Browser.

01A könyvtárlista rajzolva van, nem átfordítva

Ami a legfontosabb volt számomra, az a képernyőkép jobb oldalán látszik. A lemezképen belül minden sort a valódi character.rom-ból rajzol ki a program, pontosan úgy, ahogy egy 1541 kiírja a könyvtárat: blokkszám, idézőjeles név, fájltípus, < a zárolt fájlnál, * annál, amit sosem zártak le rendesen. Az inverz fejlécsor a lemez nevét, az ID-t és a DOS típust hozza.

Ez azért számít, mert a sceneről származó lemezek nem úgy használják a könyvtárukat, mint a normálisak. Rajzolnak vele. Egy rakás nulla hosszúságú DEL bejegyzésből logó lesz, vonal, keret — és ha a neveket megjelenítéshez ASCII-ra konvertáljuk, ahogy a legtöbb eszköz teszi, akkor az egész kép írásjelekké esik szét. Itt a névbájtok soha nem lesznek konvertálva, így pont úgy jön ki, ahogy annak idején kitalálták.

02És vissza is írható, bájtonként

Egy díszített könyvtárlistát rendesen kirajzolni csak a feladat fele. A másik fele az, hogy készíteni is lehessen egyet — és itt fogy ki egy sima szövegmező. A rendszerbetűtípus le tudja írni egy fájl nevét; azokat az inverz blokkokat és grafikus karaktereket viszont nem, amikkel egy scene könyvtárlista íródott, mert a Mac billentyűzetén egyetlen billentyű sem adja ki őket.

Ezért a lemezfejléc, az átnevezés és a DEL bejegyzés hozzáadása ablak mindegyikében ott van egy Haladó lenyíló, ami magukra a bájtokra nyílik. A mező ilyenkor a karakter ROM-ból rajzolt cellák sorává válik, gépelés közben lépkedő kurzorral, alatta pedig ott a rács minden olyan karakterrel, amit egyetlen billentyű sem ér el — a grafikusakkal, az inverz formákkal, a shiftelt szóközzel —, a ROM bármelyik feléből, vagy mind a 256 bájttal, ha úgy kéred.

Az átnevezés a teljes tizenhat bájtos névmezőre nyílik, a shiftelt szóköz utáni részre is, és éppen ettől lehetségesek a díszített sorok: a meghajtó az első shiftelt szóköznél zárja be az idézőjelet, a mező maradékát pedig utána már közönséges karakterekként írja ki — pontosan ott laknak a grafikák. A név mellett ott a blokkszám, amit a sor kiír, úgy véve, ahogy megadod, és semmihez sem hasonlítva — így egy könyvtárlista képekben is tud számolni. A fejlécben pedig a szabad blokkok száma azt az értéket állítja be, amivel a lista véget ér: a sávonkénti számlálókat mozgatja, a foglaltsági térképet érintetlenül hagyva — így állítja magáról egy demólemez, hogy üres, miközben minden fájl rajta van.

03Mit tud megnyitni

D64-es eszköznek indult, aztán szépen elkezdett oldalirányban növekedni. Jelenleg ezeket olvassa és írja:

Az írás volt az, ami igazán elvitte az időt. Commodore oldalon ez azt jelenti, hogy a blokkokat a könyvtársávtól kifelé kell foglalni a megfelelő interleave-vel, a könyvtárat egy szektorral bővíteni, amikor az aktuális megtelik, és a BAM szabadblokk-számlálóit is szinkronban tartani. Amiga oldalon a könyvtárak nem listák, hanem hash táblák, így a program végigjárja a láncokat, és azt mutatja, amit egy igazi AmigaDOS is mutatna — beleértve azokat a bejegyzéseket is, amelyeket egy naiv olvasó elveszít, ha két név ugyanabba a rekeszbe esik. Íráskor a bittérkép, a hash láncok és — ha a kötetnek van ilyen — a könyvtárgyorsítótár is konzisztens marad.

04A lemezkép szerkesztése tranzakció

Amikor belépsz egy lemezképbe, az betöltődik a memóriába, és minden másolás, törlés, átnevezés, átrendezés és fejlécszerkesztés ezen a munkapéldányon történik. A lemezen lévő fájlhoz addig nem nyúl a program, amíg a panel ki nem lép belőle. A normál kilépés menti; az Esc mentés nélkül lép ki, és rákérdez, ha van függőben lévő módosítás; a ⌘S pedig kilépés nélkül ment. Amíg vannak mentetlen módosítások, a panel fejlécében a MODIFIED felirat áll, tehát látod az állapotot, mielőtt az Esc-ért nyúlnál.

Azért csináltam így, mert egy félig megírt lemezkép semmit sem ér, és mert így a kísérletezés ingyen van: átrendezed a könyvtárat, beszúrsz pár DEL bejegyzést, hogy rajzolj velük, aztán meggondolod magad, és mentés nélkül kilépsz.

05Megnézni, mi van a lemezen

Az F3 egy háromféle módú nézegetőt nyit. A hex a kézenfekvő, egy kapcsolóval arra, hogy az első két bájt betöltési cím-e vagy csak adat. A Basic visszafejti a Commodore BASIC programot, és a Commodore betűkészlettel listázza. A Bitmap pedig bitenként egy pixelt rajzol a fájlból.

A bitmap nézegetőt használom a legtöbbet, és alig van benne kód. A bájtokat adott szélességű és magasságú blokkokba csempézi; a blokkon belül a bájtok raszter sorrendben futnak, egyenként nyolc vízszintes pixel, a blokkok pedig balról jobbra csempéződnek, majd tördelnek lefelé. Ez az egyetlen leképezés az egész funkció, és emiatt az érdekes elrendezések csak számok: 8×8-as blokk 320 szélességgel egy c64 bitmap képernyő, a 24×21 sprite, a 8×8 128 szélességgel pedig egy karakterkészlet.

Ez a mód olyan fájlokhoz való, amik sosem voltak képek. Amik viszont azok voltak, azok kapnak egy saját módot.

06Képek, a saját színeikben

A nézegetőnek van egy negyedik módja, és ez az egyetlen dolog a programban, ami nem két, a témából színezett szín. Egy kép a saját harminckettőjét hozta magával, és megmutatni éppen azért érdemes, hogy azokat lehessen látni.

Az Amiga oldalán ez IFF ILBM-et jelent. Egy kép mélységbitenként egy bitsíkon volt, minden sík egy teljes oldal, és egy képpont színindexe az egyes síkok ugyanazon helyéről vett egy-egy bit — amit aztán az OCS két trükkje értelmez át. Az EHB a felső 32 indexet az alsó 32 felezett sugarú változatává teszi; a HAM-nál a legtöbb képpont nem is szín, hanem a tőle balra lévő képpont egyik csatornájának a megváltoztatása. Mindkettő azért van, hogy több szín jöjjön ki a palettából, mint amennyi belefér.

A lista Commodore fele az érdekesebb, mert ezeknek a fájloknak nincs fejlécük, sem varázsszámuk, sem bármi másuk, ami megmondaná, mik. A kor rajzolóprogramja kidobta a VIC-II memóriáját lemezre, a betöltője pedig visszatette oda, ahonnan jött. Így egy formátumot a pontos hossza és a betöltési címe együtt azonosít, ami elég szűk ahhoz, hogy egy közönséges program szinte soha ne essen bele — és ha egyik sem stimmel, a program visszautasítja a fájlt, nem pedig találgat. Szinte mindegyik ugyanaz a négy darab más sorrendben — 8000 bájt bitmap, 1000 bájt videómátrix, 1000 bájt színRAM és egy háttérszín —, így egy táblázat lett belőlük, nem pedig egy-egy külön dekóder.

A Paint Magic a kilógó forma ebben a táblázatban, mert a képet abba a programba mentve tárolja, amelyik megmutatja: elöl 114 bájtnyi megjelenítő kód, ami pontosan annyi, hogy a bitmap a VIC által megkövetelt $2000-es határra, a videómátrix pedig $6000-re kerüljön. A formátumról nincs közzétett leírás, így az itteni eltolások azok, amiket maga a kód használ — a meglepetés pedig az $5F43-on van: egyetlen bájt, amiből az egész színRAM-ot feltölti. Ezért nincs a fájlban egyáltalán színRAM-oldal, és ezért téved az, aki ilyet keres benne, nem talál, és ebből arra jut, hogy a formátum hires: multicolour, cellánként három saját színnel és eggyel, amin az egész képernyő osztozik.

07A zene lejátszása

Ezeken a lemezeken a tartalom fele zene, úgyhogy egy dallamon az Enter lejátssza azt. A SID fájloknál a címek a PSID vagy RSID fejlécből jönnek, ha van ilyen; a fájlnévből, ha az követi a régi scene konvenciót (a Z10 I1000 P1003 azt jelenti, hogy az init az $1000-en, a play a $1003-on van); ha pedig egyik sincs, akkor magából a lejátszó kódjából.

Ez az utolsó eset egy egészen kellemes nyomozás lett. Van egy csomó Music Assembler lemezem, ahol minden dallam s.mac.14 típusú néven fut, és semmi nem árulja el a fájlban, hol vannak a rutinjai. Az editor viszont a lejátszót fix elrendezésben menti a zene elé, tehát maga a lejátszó kódja az aláírás: az init a betöltési cím után $48-cal ül, a zenét hajtó megszakításkezelő pedig $18-cal. Ebben a kódban két helyet megnézve tizenöt lemezen 256 dallamot ismer fel úgy, hogy egyetlen fájlnevet sem olvas el. Nagyjából az ötödükre rárajzolt egy rip-felirat az első bájtokra, ami a megszakításkezelőt is elvitte — ezeknél azt a rutint hívja, amit a kezelő hívott volna, $21-gyel odébb, és ugyanúgy szólnak.

Van hozzá oszcilloszkóp, kevert vagy hangonkénti nyomvonallal, és mp4-be is exportálható, a dallammal mint hangsávval. Ez nem valós időben fut, hanem offline: minden videókockához pontosan egy kockányi hangot renderel, majd rajzol, így a kép és a hang együtt marad, akármeddig tart is az exportálás.

08És a tracker modulok

Az Enter az Amiga modulokat is lejátssza, és itt válik igazán idegesítővé a névadás kérdése. Az Amigás fájlokat nem úgy nevezik el, mint a Mac-eseket. Ott a konvenció egy előtag — mod.crockets, nem pedig crockets.mod —, és rengeteg fájlon egyáltalán nincs semmi. A saját ADF és DMS lemezképeimben lévő modulok közül ötöt úgy hívnak, hogy KONMOD, LSMmiuzik vagy oliNBP. A névből ezeket sosem lehetett volna megtalálni.

Így hát a bájtokat olvassa. Minden számításba jövő formátum bejelenti magát valahol: a klasszikus, 31 mintás Amiga modulnál négy karakter az 1080-as offseten, a trackereknél és a chiptune editoroknál egy jelölés a fájl elején. Csak a jelölés viszont nem elég, és erre van egy kedvenc ellenpéldám. A ProTracker lejátszórutin forrásában van egy sor, amely így szól: EQU 1080 ;"M.K." :) — egy komment, amely megnevezi a jelölés offsetjét — és abban a fájlban ez a komment pont az 1080-as offsetre esik. Egy ideig a böngésző felajánlotta, hogy lejátszik egy 68000 assembly forrást.

Amit viszont eldönt a kérdést, az a számtan. Egy modul megmondja, milyen hosszú a 31 mintája, és mely mintázatokat játssza, és a fejléc plusz a mintázatok plusz a minták pontosan kiadják a fájlt — ha a mintázat méretét abból a csatornaszámból számoljuk, amit a jelölése kimond. A gyűjteményem mind a 98 modulja bájtra kijön. Az assembly forrás 1,2 MB mintát állít egy 25 KB-os fájlban, úgyhogy kiesik.

09A motorok

A hangmotorokat nem én írtam, és megérdemlik, hogy rendesen meg legyenek nevezve. Mindhárom bele van fordítva az alkalmazásba, nem külön linkelve, tehát nincs mit telepíteni mellé.

A c-flodot alaposan meg kellett dolgozni, mielőtt az Enter billentyű közelébe engedtem volna. Ezeknek a chiptune formátumoknak semmilyen aláírásuk nincs, tehát az egyetlen módja a felismerésnek az, hogy sorban minden lejátszónak odaadjuk a fájlt, és megnézzük, melyik fogadja el — ezért a tévedést túl kell tudni élni. Alapból viszont debuggerbe csapódik, ha egy fájl nem fér bele valamelyik fix méretű pufferébe, ami egy alkalmazásban azt jelenti, hogy a folyamat egyszerűen meghal. Ezeket az ellenőrzéseket nem lehet csak úgy kitörölni, mert éppen az adott pufferekbe való írást védik; így most van egy visszaugrási pont, ahová eljutnak, és a betöltés hibázik el az alkalmazás helyett. Ezen kívül egy x86-os debug utasítást feltételezett, és 286 KB mintamemóriát engedett egy modulnak ott, ahol az eredeti gépekben két megabájt volt.

10Két mappa, tartalom szerint összevetve

A ⇧⌘S összeveti, amit a két panel mutat, egészen a fa aljáig, és jelenti, miben térnek el. Minden fájl hasht kap, így az összevetés tartalom szerint történik, nem név és dátum szerint: egy átnevezett fájl átnevezésként olvasódik, nem pedig egy hozzáadott meg egy törölt fájlként, egy megérintett, de meg nem változtatott fájl pedig egyáltalán nem különbség.

Amin gondolkodni kellett, az az, hogy két mappát, amelyik mindkettő változott, nem lehet becsületesen összevetni pusztán a kettejük nézésével. Egy fájl, ami a bal oldalon megvan és a jobb oldalon nincs, egyszerre két történet — hozzáadták balra, vagy törölték jobbra —, és a kettő ellentétes teendőt kíván. A két mappában semmi nem tudja megkülönböztetni őket. Ezért egy sikeres szinkron feljegyzi, amiben a két oldal akkor egyetértett, a következő futás pedig háromfelé hasonlít: amelyik oldal már nem egyezik a feljegyzéssel, az az oldal mozdult.

Így minden ítélet meg tudja nevezni az oldalt — „jobb oldalon változott”, „bal oldalon törölve”, „balra változott, jobbra törölve” —, és éppen ez az a kérdés, amiért a jelentés van. Nem az, hogy a két mappa eltér, ami magától is látszik, hanem az, hogy melyik mozdult, és ezért merre kell utaznia a különbségnek. Ahol nincs bizonyíték, ott ezt mondja, ahelyett hogy kitalálna valamit: korábbi szinkron feljegyzése nélkül az azonos tartalom két néven talán átnevezve lesz, mindkét névvel és mindenféle javaslat nélkül, egy első futás pedig soha nem javasol törlést.

A törlések ki vannak kapcsolva, amíg nem kéred őket, és ha mégis megtörténnek, a Kukába mennek, akármit mond az F8 beállítása — az az egyenként kiválasztott fájlokra vonatkozik, ezekről a szinkron döntött. A konfliktusokat sosem oldja fel magától: a jelentés tetejére kerülnek, a riasztás színében, a javasolt teendőjük pedig az, hogy ne történjen semmi. A Sync megnyomása pedig nem zárja be a lapot: a futás a szemed előtt zajlik, bájtokkal súlyozott csíkkal és annak a fájlnak a nevével, amelyiknél éppen tart — mert egy SD kártyán néhány száz fájl elég sokáig tart ahhoz, hogy egy befagyott ablak és egy a végén eltűnő párbeszédablak megkülönböztethetetlen legyen egy lefagyástól.

11Húzás, javítás, nyomtatás és a szóköz

A húzd és ejtsd ugyanabban a négy irányban működik, mint a funkcióbillentyűk, a Finder pedig az ötödik: a kihúzott kijelölés oda kerül, ahová ejted, a másik alkalmazásból behúzott fájlok pedig abba a panelbe, amelyikre ejtetted őket. Hogy egy ejtés mozgatást vagy másolást jelent-e, ugyanúgy dől el, ahogy a Finderben — azonos köteten belül mozgat, két kötet között másol, a ⌥ pedig a másikat kéri —, azzal, hogy egy lemezkép belseje önálló kötetnek számít. Nem is lehet másképp, hiszen a bájtok útközben átíródnak a másik formátumba.

A Repair Disk az 1541 VALIDATE parancsa, előtte egy jelentéssel. Végigjárja minden fájl blokkláncát, a talált állapotból újraépíti a foglaltsági térképet, kijavítja azokat a blokkszámokat, amelyek nem egyeznek a saját fájljukkal, és visszaadja azokat a szektorokat, amelyek foglaltnak voltak jelölve, de semmi nem használta őket — mindezt viszont megmutatja, mielőtt egyetlen bájtot is írna, és mint minden más szerkesztés, ez is a memóriában landol, így az Esc továbbra is eldobja. Amit nem hajlandó megtenni, az a találgatás: két lezárt fájl, amelyik ugyanarra a szektorra tart igényt, olyan sérülés, amit a foglaltsági térkép nem tud leírni, tehát a jelentés megnevezi a fájlokat, és nem íródik semmi. A 48 lemezből, amin ez készült, 41 jön ki tisztán; 19-en van egy le nem zárt fájl, ami rendszerint az egész probléma.

A ⌘P azt nyomtatja ki, amit az aktív panel mutat, mégpedig úgy, ahogy a panel rajzolja: egy Commodore könyvtárlista a karakter ROM-ból kerül papírra, a ROM-nak abból a feléből, amelyikben a panel éppen áll. A képernyőn ezek a karakterek bitmapként vannak, egy képpont egy c64-es képpontra, mert a képernyőnek van pixelrácsa, amihez igazodni lehet. Egy nyomtatónak nincs — egy nyolc képpontos karakter 600 dpi-n egy pont törtrészeire esne —, így papíron ugyanezek a karakterek téglalapokként mennek le, és bármekkora méretben négyzetesek maradnak. A nyomtatási párbeszédablak Listing panelján állítható egy karaktercella mérete, és hogy a lista egyszer vagy kétszer fusson-e le az oldalon: egy teli, 144 bejegyzéses 1541-es könyvtár két hasábban, 8 pontos mérettel elfér egy lapon.

A Quick Look ugyanezeket az olvasókat teszi a Finder szóköze mögé. A képekből saját bélyegkép lesz, abban az alakban, amilyennek szánták őket, nem négyzetesre nyomva, így egy ILBM-ekkel vagy Koalákkal teli mappa képekként olvasódik, nem üres lapok faláként; egy zenén, modulon vagy hangmintán a szóköz megmondja, mi a fájl, és el is indítja, majd leáll, amikor a nyílbillentyűk továbblépnek. A korlát nem az olvasókban van, hanem az útválasztásban: a Quick Look a fájl típusát a nevén lévő kiterjesztésből veszi, így egy mod.valami nevű amigás fájl semmit sem ér el — és éppen ez az, amire maga a böngésző való, ahol az Enter a bájtokat olvassa el helyette.

12Még néhány kép