Scene.hu

Milyen gép is az az Amstrad CPC voltaképp? Valami Spectrum-klón? Tényleg olyan egyszerű overscan képernyőt létrehozni rajta? Igaz, hogy sztereó a hangkimenete? Komolyan ugyanaz a videochip dolgozik benne mint a Hercules kártyákban? És tényleg nincsenek badline-ok?

TLC / Coroners monstre cikkének második részéből választ kaphatsz mindezekre az égető kérdésekre, a tovább után.

Az első részt pedig itt találod.

Képernyő-kezelés

A gép ezen része némileg ellentmondásos, abban az értelemben, hogy “nyers” képességei a kor szintjén kiemelkedők; a képernyő kezelése, memóriaszervezése (…és -igénye) ellenben nem annyira “szép” és egyszerű, mint más típusoknál.

A video-logika egy Motorola 6845 CRTC- ill. vele kompatibilis integrált áramkör köré épül. A CRTC a Z80-hoz hasonlóan gyakran és elterjedten használt áramköri elem a korabeli gépekben (…és még sokkal később is). CRTC az alapja a PC-s MDA-, Hercules- és CGA-kártyáknak, ezt találjuk a Commodore PET-ekben, a CBM II-es sorozatban; a kevésbé ismert típusok közül a BBC Micro-ban, az EACA Colour Genie-ben, illetve – régi ismerős – a Videoton TVC-ben. A Motorola-n kívül gyártott még CRTC-t a Hitachi, a UMC, a MOS Technology- és a Rockwell is (ezen chipek valamennyien az eredeti Motorola-licensz változatai). Kevésbé ismert, de CRTC-leszármazott a Commodore 128 VDC-chipje is. A PC-s VGA-kártyák a mai napig implementálnak CRTC-eredetű logikát – ui. az összes karakteres- és néhány régi grafikus mód a CRTC-s időkből származik.

Felvetődhet a kérdés, hogy hogyan lehetséges, hogy számos, egymástól nagyon különböző video-hardver “mélyén” ugyanaz a chip található. A válasz a CRTC esetében a korabeli, más chipektől eltérő felépítésében van.

A CRTC a képgenerálás feladatából kizárólag a képernyő szinkronizálásáért, és a képernyő-memória megcímzéséért felel. Sommásan megfogalmazva: az ember megmondja, hogy hány soros- és oszlopos legyen a képernyő, milyen címen kezdődik a képernyő-memória, hány rasztersor magas egy karaktersor, milyen szélesek- és magasak a keretek, a sorokon- és oszlopokon hol kezdődik a grafikus mező, milyen szélesek- és magasak a szinkronjelek, … és mellé az alaplapon mindezt megtámogatja egy órajellel, ami a CRTC számlálóinak ütemezését adja. Ebből a CRTC minden egyes órajelciklusra három dolgot generál: a vízszintes- és függőleges szinkronjelet, a képernyő-érvényesség jelét (inaktív, ha kereten tartunk), valamint az aktuális képernyő-pozícióhoz tartozó címet. …Minden más – a video-ram tényleges olvasása, a kiolvasott byte pixelekké alakítása, valamint az egyéb, járulékos feladatok – a CRTC-hez hozzákapcsolandó “körítés”, azaz külső áramkör feladata… ez a körítés az, ami a különféle, CRTC-alapú video-hardverek esetében egymástól nagyban különbözik. A külső áramkör a CPC-ben a gate array- és néhány, ezen chip köré szervezett egyszerű elem. Minden, ami a képernyőmód-váltással, palettával, …általában színekkel áll összefüggésben, a gate array-ben megvalósított logika feladata.

A CPC-ben nincs dedikált karakter-rom, és a video-hardver nem tud karakteres-, kizárólag csak grafikus módot. …Abból viszont tud három különbözőt is (…és létezik még egy negyedik, gyárilag nem definiált mód, amely a standard CPC-ken jól-, +-sorozaton már nem működik).

• Mode0: 160*200, 4 bit per pixel
• Mode1: 320*200, 2 bit per pixel
• Mode2: 640*200, 1 bit per pixel
• (Mode3: 160*200, 2 bit per pixel)

A módváltás (és minden, ami video-móddal kapcsolatos) a gate array feladata; az egyes módok cím-térképe teljesen megegyezik, kivéve az egyes, beolvasott bitmap byte-ok pixelekké lefordításának módját. …A CRTC nem is “tud” a képgenerálás ezen utolsó fázisáról, csak a gate array.

Érdemes egy pillantást vetni a bitmap-sorokat reprezentáló adatfolyam méretére. A C64-bitmap egy képernyősora 40 byte. Egy CPC bitmap-sor, akárhogy számoljuk (160/2, 320/4, 640/8), 80 byte. Tanulság?… Nyers erőben a CPC- és a C64 bitmap-sorok információtartalma között van egy kemény, kétszeres szorzó… Persze, a C64-bitmaphez “jön” még a 8-soronkénti, 60 byte-nyi szín-attribútum info; valamint, a nyers erő nem minden, de azért azt is érdemes látni, hogy nem is kevés. Azonos felbontásban, egy pixelre, egy CPC kétszer annyi bitnyi szín-kombinációt tesz lehetővé, mint a Commodore hardvere. Egy Plus/4-coder pl. valószínűleg fél karját adná, ha 160×200-ban olyan video-móddal dolgozhatna, ahol 16, független szín áll rendelkezésére, azaz kezelhet pl. sprite-okat color clash nélkül… Aztán… 320×200-ban négyféle színű pixel, color clash nélkül… ciklusra pontos “háttérmunkával” (a paletta-regiszterek képernyőhöz szinkronizált írásával… emlékezzünk rá, badline nincs, a módosítás a képernyő tetszőleges helyén érvényre jut, és a CPU 6502-nél gyorsabb, azaz sűrűbb váltások lehetségesek…), vajon mit lehet kihozni belőle?… A vízszintesen 640 pixeles (…karakterben: 80 oszlopos), színes grafikus képernyő korabeli házi/mikrogépeken eleve szokatlan ügy…

Szó kell, hogy essék a gép szín-ábrázolásáról is. A CPC RGB-színkódolással dolgozik. 27 palettaszín, azaz 3 RGB-komponens / 3-féle érték. A CPC szín-ábrázolása tehát tulajdonképp egy lineáris, “másfél-bites” RGB-kódolás. (A “másfél-bit”, ti. az éppen három-, nem kettőhatvány-féle állapotok eredete egy frappáns hw-trükkre vezethető vissza: sok-bites D/A-konverzió helyett, a gate array kimeneteinek “háromállapotúságát” (= alacsony, magas, nagyimpedanciás) használják fel 3-féle analóg feszültségérték előállítására). Hol foglal ezzel a CPC helyet a közismert, lineáris RGB-t megvalósító hardverek között?… Összehasonlításképp: Spectrum (…valamint CGA, illetve VDC-módban C128; egységesen DRGBI): 1 bit + intenzitás (8-féle szín két intenzitásban). EGA: 2 bit (64). Atari ST: 3 bit (512). Amiga: 4 bit (4096). Standard VGA: 6 bit (262144). ….Láthatjuk, hogy a színfelbontás más rendszerekkel összevetve, nem túl nagy, de a valóságban (8-bites szinten) elfogadható. Habár a DRGBI-hez hasonlóan a CPC-n is könnyű túlságosan telített színeket (hupizöld-, hupilila- és társai) előállítani, az eredmény a gyakorlatban nagyságrendileg jobb, mint amazoké. A 27-féle RGB-kombinációból áll össze az adott grafikus módban használt 16-, 4-, vagy 2-elemű paletta (amelynek regisztereit szintén a gate array-ben alakították ki).

Az összeállításból már csak két részlet hiányzik: egyik a video-ram címzése, másik a gate array-n implementált megszakítás-logika.

A video-ram címzése a CPC egyik “gyenge pontja”, ami közvetlen következménye a CRTC chip felhasználásának. A CRTC-t ui. alapvetően karakteres megjelenítőkhöz tervezték, így külön számolja a video-mátrix karaktersorait, és a karaktersoron belüli rasztersorokat. A CRTC karakterszámlálója a bal felső saroktól kezdve, balról jobbra, fentről lefelé nő minden egyes karakter-pozícióval. A karaktersoron belüli raszterszámláló a karaktersor legfelső rasztersorán 0, minden rasztersorral egyesével nő, addig, ahány rasztersor magas karaktereket a CRTC-nek definiáltunk. Egy karaktersor kiírásának befejeztéig a karakterszámláló minden egyes rasztersorra a kezdő karakterpozícióról indul újra. …A CPC-ben nincs karakteres mód, a bitmap címzését a CRTC-vel “kerülő úton” oldották meg. “Virtuálisan”, a CPC “karaktersorai” 8 rasztersor magasak, és 80 byte (…egy hw-hack miatt valójában 40 pozíció, de ennek itt nincs jelentősége) szélesek. A “karakter-pozíció” adja meg a memóriacím A0..A10 és A14-A15-, a karakteren belüli rasztersor száma pedig a cím A11-A13 bitjeit. Ez azt jelenti, hogy a karaktersorok azonos számú rasztersorai (0..7) a memóriában címfolytonosak, egy adott karaktersor egymás alatti rasztersorainak kezdőcímei pedig egymáshoz képest +$0800 byte-tal (…A11-A13 helyiértékei, amelyeket a karaktersoron belüli raszterszámláló határoz meg…) térnek el. …A címszámítás a programok szempontjából így meglehetősen “érdekes”, leggyakrabban táblázatokkal oldják meg. Jól látszik az is, hogy “lehetséges” 16k-nál nagyobb képernyőt létrehozni – a karakterszámláló 16k-nál nagyobb helyiértékű bitjei is be vannak kötve –, de a különféle wrap-around esetek bekövetkezte miatt a beállítást érdemes jó előre átgondolni.

Végül, a már említett megszakítás-logika… Commodore-os beidegződésekkel, a CPC ezen alrendszere jelentheti a legnagyobb bosszúságot, avagy “most mi van?!”-életérzést (…spectrumosok viszont azt mondanák, hogy hmmm, mi is a gond?…). A CPC-ben ugyanis nincsenek timerek, a CRTC-ben pedig nincs rasztermegszakítás-logika. Hoppá! (…Valószínű, hogy ez a rész lóg ki leginkább a konstrukció optimumából, “egész-ségéből”, azaz érvényesül leginkább korlátozásként… Ti. amit a Commodore-coder egyszerű adottságnak vesz (hogy megszakítás-technikát használhat, és az így futó, különféle feladatokat rugalmasan időzítheti), az itt “nincs”, legfeljebb csak vagy nagyon korlátozottan, vagy nagyon nagy program-ráfordítás árán. A CPC ezen a ponton bukja el pl. a digilejátszás- ill. az Atari ST-n megszokott YM/AY hackek “üzemszerű” használhatóságának lehetőségét). Ezen a téren a CPC egyetlen, erősen korlátozott lehetőséget biztosít. A gate array-ben található egy 6-bites számláló, amelyet a CRTC függőleges sorszinkron-jele nulláz, vízszintes sorszinkron-jele pedig egyesével növel. Amikor a számláló eléri az 52-t, a gate array megszakítást generál, a számlálót pedig nullázza. Végeredményben a gate array 52-soronként (frame-enként hatszor, azaz 50Hz-es frame-et feltételezve 300Hz-cel), a függőleges visszafutáshoz szinkronizálva (azaz minden frame-ben fix képernyő-pozíciókon), ha ez engedélyezett, megszakítást generál. …Van még némi kiegészítő-logika, ami bizonyos eseményekre a számlálót- ill. annak legfelső bitjét nullázza, ennek ezen a ponton túl nagy jelentősége nincs. A következtetést úgy vonhatnánk le, hogy a CPC-n “időzíteni”, pláne független folyamatokat, meglehetősen problémás vállalkozás (…CPU-val, ciklusokat számolgatva, busy loop-ban, ha egyáltalán… mint Spectrumon), ill. a képernyő adott pontjához időzíteni sem kényelmes, kivéve, ha a kívánt pozíciók a gate array által kitüntetett pozíciók közelébe esnek. Elképzelhető a logika esetleges hackelhetősége, bár példa (bizonyíték) erre eddig nem született.

…Most, hogy az összes részletét ismerjük, végsősoron, a gyári paramétereken kívül, mire is képes ez az összeállítás?… Valószínű, hogy máig rengeteg “exploit” maradt benne, de néhány lehetőséget azért fel lehet sorolni. Ezek legnagyobb része a CRTC rugalmasságához kapcsolódik. A programozónak gyakorlatilag teljes szabadsága van a képernyő méretével-, időzítésével- és egyebekkel kapcsolatban. Overscan képernyőt létrehozni (amihez C64-en soronkénti bűvészkedés kell) teljesen magától értetődő lehetőség. A kezdőcím-, sorméret- és egyéb regisztereket berhelve, hardver-scrollt- ill. freeline-jellegű effecteket lehet létrehozni. …Megjegyzendő, hogy a CRTC képes interlace-szinkron generálására, azaz nincs akadálya 625 sor/ 25Hz-es valós váltottsoros kép megjelenítésének. A palettaszínek (gate array-regiszterek) realtime módosításával itt is raszterozni lehet, és gyakori, hogy ciklusra pontosan, soron belül módosítanak paramétereket (akár szín-, akár más paraméterről legyen szó). Az RGB-színgenerátor kézenfekvő lehetőségként adja az Amigán- és Atari ST-n gyakori shadebob-effectek-, a palettázott módok pedig a paletta forgatásával kapcsolatos effectek lehetőségét. Képernyőn belül képernyőmódot váltani – bár nem annyira egyszerűen, mint gondolnánk, de – szintén lehet, és gyakran teszik. A CPC kommersz elemekből való felépítettségéhez még egy speciális kérdéskör kapcsolódik: az Amstrad a gépekbe olyan CRTC-ket szerelt, amilyeneket az adott pillanatban a világpiacon kapott- illetve olcsón megvehetett (avagy, amilyet már jóval később ő maga az ASIC-jeinek részeként gyártatott). Ezek a chipek egymással nem teljesen kompatibilisek. Ötféle kategóriáról van szó, amelyek a CPC scene-en önálló sorszámot kaptak:

• CRTC0: HD6845S ill. UM6845 (Hitachi ill. UMC)
• CRTC1: UM6845R (UMC)
• CRTC2: MC6845 (Motorola)
• CRTC3: 464+ / 6128+ / GX 4000 ASIC (Amstrad)
• CRTC4: “Cost Reduced” 464 / 6128 ASIC (Amstrad)

(A legkevésbé kedvelt típus az eredeti, Motorola-féle verzió (bizonyos exploit-ok nem működnek vele), legjobb az UM6845R (számos demó CRTC1-specifikus); használható a HD6845S ill. UM6845, valamint az ASIC-verziók.)

Összefoglalásul?… A gép ezen alrendszerének vannak “szépségei”, különösen a korabeli 8-bites gépekkel összehasonlításban. A gép színfelbontása- és színmélysége nem, de a nyers képernyőfelbontása az egy évvel később piacra kerülő 16-bitesek paramétereit idézi (…mekkora is az A1000, ill. az Atari 520ST vízszintes felbontása?…), és ezt a felbontást az igényes analóg-áramköri kialakítás- valamint a jó konstrukciós döntés folytán (…nincs kompozit színjel, a meghajtás analóg RGB-s) a monitoron képes is realizálni. (…Commodore-hoz szokott szemnek igen kellemes, ahogy a CPC képernyője zaj, artifact-ek, blur nélkül, tisztán a megjelenítő felbontásában jelenik meg… érdemes egyszer közelről megnézni pl. egy modern, de még képcsöves SCART-tévén). A paletta elfogadható, a vezérlő exploit-olható, a címzés kissé nyűgös, badline-ok nincsenek, karakteres mód nincs, sprite nincs, a képernyőhöz- vagy úgy általában az időzítés lehetősége meglehetősen gyenge… a video-áramkört kb. ennyiben lehetne összefoglalni.

Ez a cikk nem szól a késői, +-sorozat képességeiről, de annyit feltétlenül érdemes megjegyezni, hogy különösen a grafikus alrendszere tér el a klasszikus CPC-kben megismertektől. Az új (…már Amstradéknél is custom-technikára épülő) chipset 4-bites RGB-színkódolást “tud” (=Amiga, 4096-féle szín) max. 32-színű grafikus móddal, rasztersoronként max. 16 db, 16-pixel széles sprite-tal.

Hang

A CPC hangja (a korabeli szinten) átlagosnak mondható; alapja a General Instruments AY-3-8912 hanggenerátora (PSG, “Programmable Sound Generator”), amely gyakorlatilag azonos a Yamaha által gyártott YM2149 (SSG, “Software-controlled Sound Generator”) chippel. …Szintén gyakori építőelemnek számít, számunkra leggyakrabban a ZX Spectrum 128/+2/+3-ból, illetve az Atari ST-ből lehet ismerős. A CPC-be épített AY-3-8912-t egy sorozat “középső” eleme (…a sorozat valamennyi típusa azonos lapkát tartalmaz, csak a tokozás, azaz a ténylegesen kivezetett I/O port-kivezetések száma különbözik).

A PSG háromcsatornás, csatornánként egy-egy 50%-os kitöltési tényezőjű négyszögjelet előállítani képes hanggenerátor. A csatornák oszcillátorai 12-bitesek, és “timer-típusúak” (ellentétben a SID fázis-akkumuláló oszcillátoraival), azaz frekvencia helyett periódusidőt várnak. CPC-ben a PSG órajele 1MHz, a hangkimenet előállításához ennek a frekvenciának 16-odát osztjuk a periódusidő-regiszterekbe írt 12-bites értékkel. A chip implementál egy egyszerű, shiftregiszter-alapú zajgenerátort, amelynek kimenetét mindhárom csatorna kimenetéhez hozzá lehet “keverni” (…a “keverés” valójában egy VAGY-kapcsolat a négyszögjel-generátor és a zajgenerátor kimenete között). Minden csatornához önálló, 4-bites hangerő-érték tartozik. Ezen a ponton a PSG meglehetősen érdekes, ui. a hangerő-értékek nem lineárisak, hanem exponenciálisak – így a kevésnek tűnő, 16-féle hangerő-érték is meglehetősen nagy dinamikát képes átfogni. Van még a chipen egy egyszerű burkológörbe-generátor, amelyet a csatornák hangerejéhez (egyhez- vagy többhöz) lehet rendelni. (Ez utóbbit a gyári dokumentáció sem hívja ADSR-generátornak, mivel annál “kissé” egyszerűbb… itt kell megjegyezni, hogy a PSG- és SSG-chipek képességei összesen ezen az egy ponton különböznek; az SSG envelope-generátora kétszer akkora felbontást (5-bitest) tud, és, hogy az időzítés ne változzon, kétszeres sebességgel fut). Sok- vagy kevés?… Egy SID-hez képest meglehetősen karcsú (…az Atari ST esetében pedig, a vele konkurrens Amiga Paula chipjéhez képest konkrétan sehol sincs), a klasszikus Spectrum 1-bites hangjánál, a VIC-20 VIC-I-énél, a Plus/4 TED-jénél fejlettebb, az Atari 800 Pokey-chipjénél, …hát, ízlés kérdése. A chipen ezen kívül még van egy 8-bites I/O port (AY-3-8910 és YM2149: két 8-bites I/O port), amely az alap-funkcióhoz szorosan nem kötődik, a CPC-ben ezen keresztül történik a billentyűzet- és a joystick(ok) lekérdezése.

A CPC hangkimenete sztereó (!), a három PSG-csatorna közül egy jobbra, egy balra, egy pedig középre van keverve. Az analóg interface korrekt, nem torzít, nem zajos, szabványos jelszintet biztosít (ellentétben az Atari némileg torz- és a Spectrum 128 némileg alacsony jelszintű/zajos hangkimenetével).

Hogy negatívumot is említsünk: a PSG rendszerbuszra illesztése bizonyos mértékig “vicces”. A General Instruments a chipjein olyan rendszerbuszt implementált, amelyet Z80-alapú rendszerben nehéz reprodukálni. A tervezők Nagy Sándor példáját alapul véve, a kérdést “megoldották” – logikailag nagyjából azon a szinten, mintha az ember egy parallel porton keresztül kívánna megcímezni és megszólítani egy közepes integráltságú IC-t. A CPC-ben rendelkezésre áll egy Intel 8255 PPI (parallel port interface) chip, amely itt a billentyűzet-kezelésért, és egyéb, bitenkénti I/O-funkciókért (pl. a magnó ki- és bemenetért) felel. A PSG ezen PPI portjainak vonalaira csatlakozik. A PPI-portok írásával lehet számára busz-műveleteket (…azaz végsősoron regiszter-műveleteket) küldeni. Következmény?… A funkcionalitás nem csorbul, de a PSG regiszterei némileg lassan kezelhetők. Egy regiszter módosítása 6 darab OUT-műveletet igényel (…a Spectrumon ugyanez 2 művelet). …Hirtelen ki kellene számolni, hogy hány órajelciklust igényel egy player egy futása alatt csak a frekvencia- és hangerő-regiszterek frissítése… az STA $D400,X frappánsságát mindenesetre el lehet felejteni…

Mint láttuk, a hanggenerátor nem túlságosan összetett, de néhány trükkre azért itt is lehetőség van. A csatornánként szabályozható hangerő más, négyszögjel-alapú hanggenerátorokkal szemben (VIC-I, TED) előnyös. A gyakorlatban szintén jó lehetőség a zaj- és hang-hullámforma keverhetősége egy csatornán (egyszerű ritmushangszerek, a zenei hang megszakításának követelménye nélkül). A fejlettebb trükkök közül az első (és leggyakoribb) az envelope-generátor “félrehasználata” hangszerként- ill. amplitúdó-modulátorként. Erre az alkalmazásra az a két jellegzetesség ad módot, hogy 1.) az envelope-generátornak van “loop”-módja, amikor a generátor felfutás-lecsengés periódusa trigger nélkül, sorozatban ismétlődik, 2.) az envelope-generátor frekvenciaalapja “elég nagy” lehet, akkora, ami a hallható tartományba esik. Bár a frekvencia beállítása ebben a tartományban nem túl pontos, a gyakorlatban jól használható. Mivel az envelope-generátor a megadott periódusidő ütemében egyesével számol fel- és/vagy lefelé, azaz lineáris fel- és lefutást valósít meg, ezt a sorozatot valamely csatorna hangerejérekapcsolva (…amelyről említettük, hogy exponenciális jelleggörbéjű) csúcsos, exponenciális, görbe mentén emelkedő és csökkenő hullámformát kapunk. Ezt a hullámformát még maszkolja az adott hangcsatornán aktív négyszögjel (ha van), annak saját periódusidejével… azaz végeredményben a kettő amplitúdó-modulációja valósul meg. Erre a hackre épülnek a “buzzer”- és hasonló effectek – avagy gyakorlatilag az összes mai PSG-zene basszusszólama…

Egy másik lehetőség a PSG-n digihangok lejátszása. Ez gyárilag is dokumentált, a hangerő-regiszterek felhasználásával minden további nélkül lehetséges. Gond: a CPC-ben nincs timer, azaz a digi időzítése kb. annyira nyűgös, mint Spectrumon (…időzítés: busy loop-ok, adott ciklusszám alatt lefutó kódrészletek- és társaik, erőből, megszakítás-technika nélkül). Megvalósítható, de innentől kezdve a képernyőn vagy nem mozog semmi, …vagy a megvalósítás nagyon munkaigényes. (A badline-ok hiánya viszont az ügy szempontjából üdítő…)

A PSG/SSG chipek mesterei valójában nem az Amstrad- és nem is a Spectrum-, hanem az Atari ST-scene zenészei és programozói; ez az a platform, ahol az SSG határait már a 80-as évek vége óta nagy szenvedéllyel tologatják kifelé… persze, némileg segítségükre van az erősebb platform, és (legfőképp) a timerek- és megszakítás-lehetőségek rendelkezésre állása. Itt nagyon gyakori a variálható négyszögjel-impulzusszélesség használata (“SID” effect), a digik (…a hőskorban jellemzően mod-playerek, ma inkább natív, SSG-szólamokat kiegészítő digi-technikák formájában), különféle, SSG-csatornákra ráültetett “soft synth”-ek, a sync-buzzer effectre épülő synth,… …azok az effectek, amelyek üzemszerű alkalmazása Sinclair Spectrumon v. Amstrad CPC-n nem annyira a kisebb processzor-teljesítmény, mint inkább az “olcsó” időzítés- és megszakítás-lehetőség hiánya miatt előnytelenek (vagy konkrétan határosak a lehetetlennel).

Az AY/YM zenék platformok közötti konverziójának itt is kialakult az a hagyománya, ami a SID –> TED konvertálgatást jellemezte; a lehetőségek itt persze sokkal jobbak. “Tökéletes” konverziót némileg nehéz készíteni az eltérő környezet (…ST-specifikus realtime SSG-effectek) és az eltérő PSG/SSG órajelek miatt (ami miatt az envelope-generátor adatait csak némi hallható elhanyagolással lehetséges átszámítani). De a gyakorlatban azért egészen jó konverziók készültek.

Személyes, kissé filozofikus komment: bár a történelemben építettek már jobb hanggenerátort, a CPC-vel összefüggésben a PSG-t nem volna érdemes “leírni”. …Alapvetésként, a különféle erősségek- és korlátozások együtt adják egy platform, végsősoron a platformra megjelenő produkciók sajátos, összetéveszthetetlen “ízét”. A CPC “identitásához” (ami alapján semmi mással nem téveszthető össze) éppúgy hozzátartozik a PSG jellegzetes hangzása, ahogy a C64-éhez a SID-é. …8-bites kultúrkörben jellemzően egyébként sem a hardvert szeretjük különféle produkciókhoz optimalizálni (bemenni a sarki boltba, és venni egy háromezermilliárd gigatexellel jobb grafikus kártyát), hanem fordítva… adott hardver határait szeretjük feszegetni. (Előfordul az ellenkezője, de azt a ligát pl. wild demonak hívjuk, és azért szeretjük ;-) ). A PSG sosem lesz SID, de ettől a világ még nem fog kifordulni a sarkaiból. Számos, kitűnő zenész dolgozik ezen a platformon (különösen az Atari ST scene-en). A kérdést jól lehetne szemléltetni a templomi orgona és a zongora különbségével; van köztük kategória-különbség, nem egyformán szólnak, de egyrészt az ember jó esetben nem csak templomi orgonán szeret zeneműveket hallgatni (…különösen, ha adott esetben nem is tart otthon egyet a sufniban… vagy, ha éppenséggel szereti a zongorahangot :-) ), másrészt a zenei élményt a hangszeren kívül jelentékenyen befolyásolja még egy aprócska, nem hangszerfüggő tényező: a kompozíció… Ez utóbbi szempontból, különösen az Atari ST scene zenészei nagyon “erősek”… Felvetődik a kérdés, ha Atarin rengeteg, jó kompozíciót lehet hallani… akkor miért volna ez lehetetlen CPC-n?…

Floppy drive és -interface

Ismét egy standard áramköri elem – olyannyira, hogy ez ugyanaz a chip, amelyre a PC-s floppy-vezérlők is épülnek. Ez egy NEC μPD765 FDC. A konkrét áramkör a PC-s lehetőségekhez képest némileg leegyszerűsített, de főbb jellegzetességei azzal teljes mértékben megegyeznek. Fix MFM-kódolással dolgozik, fix 250kbps bitsebességgel, DMA-lehetőség nélkül (azaz programozott I/O-val), …mindez nagyjából a PC-s DD-s meghajtók paramétereinek felel meg (ahogy a lemezkezelés megszokott sebessége is).

A CPC gyári meghajtói a már említett egyfejes, 40 trackes, 3″-os egységek. Az AMSDOS 40 track/side, 9 sector/track, 512byte/sector-paraméterlistával dolgozik, azaz egy lemezoldal kapacitása gyári formátumban 180k – éppen akkora, mint egy PC-s 5.25″-os DD-s lemez egy oldaláé. …A szektorok azonosítói (formázáskor) nem azonosak a PC-éivel, azaz a PC direktben nem-, csak speciális programokkal hajlandó CPC-s lemezeket kezelni (…és persze azt is csak onnantól, ha már rendelkezésére áll egy 3″-os meghajtó… vagy a CPC rendelkezésére áll egy 3.5″/5.25″-os).

A lemezek kapacitása pusztán az FDC megfelelő programozásával növelhető. Az FDC (rövidebb gap-ekkel) képes egy sávra 10 szektort elhelyezni, és a legtöbb meghajtó képes 42 tracket (némelyik 43-at) kezelni, így az oldalankénti kapacitást a 200-220k-körüli határig fel lehet tornázni (…megjegyzés: az AMSDOS ezeket a formátumokat nem kezeli, adott program track-loadere ellenben minden további nélkül). Ezek egyébként pontosan megegyeznek a korabeli PC-s világban elkövetett lemezes kapacitás-növelő trükkökkel. Az FDC kényelmes “rendelkezésre állása” miatt számos gyári másolásvédelem trükközik a lemezformátum különféle paramétereivel, pl. ír fel rövidebb-hosszabbra formázott szektorokba adatokat, használ spec. szektorszámozást, stb.; ezekre a trükkökre a már említett PC-s (…és CPC-s…) lemezmásoló-rutinok általában fel vannak készítve (…ahogy a CPC-lemezek image-inek tárolására kitalált PC-s DSK-fájlformátum is).

A hardver összesen két, független meghajtót képes kezelni. A buszra csatlakoztatott drive bizonyos határok között akármilyen típus lehet, ui. az interface a klasszikus Shugart-buszt valósítja meg; némi munkával PC-s drive-okat is meghajthat (…ahol a munka nagyobb részét leginkább a PC-s drive Shugart-szabványúra visszaalakítása jelenti, az Amiga drive-jainak cseréjénél is megszokott módon). Hw-módosítás nélkül, a CPC 250kbps-es bitsebességet támogat, azaz lehetőségeinek felső határa a DD-s lemezszabvány határaival egyezik; két fej, 80(…1-3) track, 10 sector/track, azaz valahol 820-830k per disk környékén. Az Amiga-stílusú, 11 sector/track séma (amely ott a 880k-s kapacitást eredményezi) az FDC-vel sajnos nem működik. Megjegyzés: az AMSDOS ezeket a formátumokat nem támogatja, néhány DOS-kiegészítés (pl. Parados), ill. néhány konkrét program viszont igen.

Commodore-os összevetésben elmondható, hogy a séma alapvetően különbözik az ott megszokottaktól. Míg ott az alapvető problémát nem a lemez I/O, hanem a lassú soros busz kezelése jelenti, itt a CPU-nak közvetlenül rendelkezésére áll a teljes, lemezkezelést megvalósító infrastruktúra; cserébe viszont, nem áll rendelkezésére a drive-ban, tőle függetlenül dolgozó másik processzor… Azaz, a lemezkezelés összes részfeladatát, a szektor-adatok szinkron kiolvasását neki, magának kell megvalósítania – programozott I/O-val, DMA- ill. FDC-megszakítás használata nélkül.

CPC scene

Általában elmondható, hogy ahogy ismertebb platformokon, úgy CPC-n is elkezdődött a demók készítése, a hardver határainak “feszegetése” még a késő nyolcvanas- korai kilencvenes években (ebből az időszakból a neten számos megademó lelhető fel ma is; jól illusztrálja a tényt, hogy a CRTC-típusok beszámozása ebből a korszakból származik, azaz a típusok közötti különbségekkel már az akkori scenerek részletesen tisztában voltak). A CPC scene magját húsz éve kb. ugyanaz a néhányszor tíz, elszánt CPC scener jelenti (kis fluktuációval), akik időnként valószínűleg akkor is elővennék a gépet némi szórakozás- és/vagy elme-gyakorlat céljából (kellemest a hasznossal…), ha semmiféle CPC scene nem volna. Tipikusan brit-, német-, francia-, spanyol-, ill. görög nemzetiségűek. Kisebb-nagyobb produkcióik időről időre megjelennek, és meglehetősen jó honlapokat tartanak fenn, lásd alább. Az egyetlen sajnálatos dolog, az átütőbb CPC-demók megjelenésének viszonylagos ritkasága… Az élet sokkal “csendesebb” ezen a tájékon, mint C64-en (sajnos…); Rhino már említett, győztes projectje (a platform kelet-európai egzotikusságán mint tényen túl) többek közt ezért is jelenthetett üdítő színfoltot, éppúgy a 8-bites platformok rajongói- mint szűk értelemben a CPC scene számára is.

Figyelemre méltó stuffok, címek, nevek… (szabad asszociációban, kommentekkel)

• The CPC Wiki Az eddigi legteljesebb, jól szerkesztett CPC információs bázis. Fenntartója Gryzor.
• The Unofficial Amstrad WWW Resource. Szerkesztője Kevin Thacker, alias Arnoldemu. A site talán a legjobb kiindulópont, ha valaki CPC-programozásra adná a fejét, Kev Thacker pedig mintha több, más vonatkozásban is ismerős volna… mintha éppenséggel ő írta volna a Batman Foreverben használt trackloadert, illetve az Arnold CPC emulátort is…
• CPC-POWER. Masszív, katalogizált CPC-szoftvergyűjtemény (demók és játékok), információkkal, kereshetően.
• Project AY. YM/AY zenegyűjtemény, többségében Spectrum 128-ról és CPC-ről.
• SNDH. Elsődleges YM/AY zenegyűjtemény (aktív), Atari ST-s.
• sc68. YM/AY zenegyűjtemény (Atari ST). Sajnos, jó ideje nem frissítik (ezzel együtt tanulságos).
• Joris “Scavenger” de Man, Jochen “Mad Max” Hippel, Frank “Tao” Seemann, Emmanuel “Lap” Larry, Nic “Count Zero” Alderton, Gunnar “Big Alec” Gaubatz, Excellence In Art, Mathieu “DMA-SC” Stempell, MSG, J.S. “Jess” Gerard, Stefan “Lotek Style” Benz… …Ebben a sorrendben… :-) Minden, YM/AY-zenét kedvelő ember félistenei :-).
• Arkos, Targhan, Demo Iz Art. Landscape part; 2 négyszög + 2 realtime mixelt digi csatornás zene (Targhan), berhelt mode2 (640×200) képpel (video).
• From Scratch (Vanity), videó. …Meg kell említeni, hogy az emulátorok még hagyján, de a videók, az eredeti produkcióknak, legfeljebb csak halvány árnyékai…
• Egy részlet a Synergy Megademo-ból, Scavenger híres zenéjével, illetve egy Patisoners demó videója (Spectrum 128-ról) ugyanezzel a zenével, annak szemléltetésére, hogy ugyanazon dolgok milyen következményekkel járnak egyik- és másik platformon. (Türelmesek olvashatnak a Patisoners demó technikai részleteiről… igen tanulságos…).
• Hasonló stílusú kunszt CPC-ről, eredeti zene szintén Scavenger, Parasites, videó
• CPCMANIA, a CPCDiskXP honlapja, ha valaki igazi vas felélesztésén, és produkciók 3″-os lemezre kiírásán törné a fejét…

Források

A cikk tartalmának pontosításához a Wikipedia, a már említett CPC Wiki ill. Unofficial Amstrad WWW Resource vonatkozó cikkeit vettük alapul, a képek az előbbi két forrásból származnak; köszönet értük!