A link már nekem sem működik. A bal oldalon megjelenő hármas egységekből a felsőt lehet betenni a táblára (a maradék kettő következő az előregondolkodást segíti). El lehet forgatni, így 8-féleképpen lehet letenni egy hármast. Csak üres mezőkre lehet tenni. Ha legalább három egyforma kép kerül egymás mellé, akkor eltűnnek (nyilván erről kapta a nevét a játék). Bár nem igazán tudom, hogy mit ábrázolnak a képek, de az egyik kékes a joker.
Szép. Ahhoz képest a szerző kifejezetten kérte, hogy ne legyen még publikálva, mert még apró simításokat akar rajta elvégezni és utána forráskóddal együtt közzéteszi.
Ügyes módon csak SD2IEC-ről fut. Elvileg YAPE 1551 IEC módban is kellene mennie, csak nem tudom, hogy mivel indul el (az első indítóját át kell ugrani, mert az betölt egy SJLOAD-ot, amitől viszont a 1551 IEC mód azonnal megfagyasztja a gépet). Erre emlékszem abból, ahogyan ott nálam próbálgatták. Csak közben én átmentem máshova és Króna vitte tovább a történetet.
A Game Compo előtt pont élőben nyomta az együttes az LN2-t és ha jól emlékszem talán volt egy LN1 zene is.
Voltak akik teljesen extázisba estek tőle (tényleg jól szólt), ez jól megalapozta az Ati féle LN helyezését is :-) Teszletgettem egy fél órát az LN-t, és nagyon jó a kód. (főleg a takarások és a color clash téma érdekelt.)
Baromi gyors a pálya kirajzolása.
Összvissz egy pillanatra futottam bele egy bugba a templom előtti shinto kapunál (egy pillanatra eltűnt egy szegmens), de magától megjavult és nem is tudtam újra előidézni. Sajna a C64-en használt réteges sprite itt nem működik, ezért nem lehet rózsaszín arca/keze a ninjánknak, és emiatt nem lehetnek az ellenfelek sem színesebbek. (vagy jönne a color clash).
Bár elviekben van még két másik fix szín is multicolorban, tehát akár zöld vagy szürke ninja is lehetne az ellenfél (mint a 80as évekbeli alámondásos VHS videókon).
Úgy tippelem, ezek lehetnek még a fix színek a feketén kívül. A szürke különösen kihívást jelentene a szürke úton, ui. láthatatlan lenne :-)
Nem nagyon. Ezek valszeg annyira Csory sajátjai, hogy még a németek sem tudtak róla. Csory ugyan odaadta nekem annó lemezen a 256k-s programjait (pl. megcsinálta a Bard's Tale játékokat is 256k-sra, RAM drive-ként használva a memóriát, hogy ne kelljen lemezeket cserélni - olyannyira, hogy nálam 64k-s gépen el sem indult, amíg meg nem módosítottam), meg egy cetlin a kapcsolási rajzot. Ebből van az a Macro Assembler, amit TLC emleget és az tényleg sehol nincs dokumentálva, hogy ez vajon mi a búbánatot csinálhat. Még annyira sem, mint a németek bővítményei.
Rájöttem, hogy igazából nem teljesen helytelen 240 kb-osnak nevezni, mivel az $FCFF fölötti memóriát el lehet hanyagolni. Úgy meg már nincs messze attól az értéktől. De nem is erről akartam írni. Megtaláltam TLC hozzászólását a P4W fórumon, amiben a Csory féle bővítés ROM vonatkozású aspektusait boncolgatja, és ez az amire emlékeztem. Valami olyasmi, hogy a TED ROM olvasásait mindig a nullás bankra irányítja (KERNAL+BASIC?), illetve a bővítés permanensen belapoz $FE00-tól egy nem részletezett nagyságú tartományba valamiféle ROM tartalmat. Erről van valami részletesebb információ?
240 az a 244, de igen. (legalábbis annyinak szokták emlegetni, de most utánaszámolva: 1x64 + 3x60 az tényleg 244). ROM bővítést is a németek csináltak (Hannes és Solder, illetve lehet, hogy mások is benne voltak. Ahhoz is ott van a plus4_io_map.inc-ben a regiszter kiosztás, bár az idők folyamán az is átalakult. Eredetileg igazi ROM bővítés volt, aztán SRAM lett belőle, elemmel, ami az SRAM-ot életben tartotta meg írásvédelem kapcsolóval. Azt 384k ROM/SRAM expansion-nek szokták hívni.
Akkor gyakorlatilag a Hannes/Solder bővítő 256 helyett csak 244 kb-os volt? A Csory-félével meg lehetett emulálni 16 vagy 32 kb-os RAM-ot is?
Most ködlött fel bennem, hogy valamelyik memóriabővítés kapcsán mintha lett volna emlegetve valami trükközés a ROM-mal is. Az mi lehetett? Vagy csak rosszul emlékszem? Mondjuk ez egyáltalán nem kizárt.
Mondjuk, hogy nincs. A regiszterleírást megtalálod az IOLibV3 forrásokban (szerintem valami plus4_io_map.inc vagy hasonló lesz a neve, oda belekommenteztem + még a ram_size_detect.inc vagy hasonlóban ott a programozása is). Solder weboldalán voltak fent a kapcsolási rajzok hozzá, az viszont néhány éve nem elérhető (mármint a link, ami a saját, otthoni szerverére mutatott).
Nagyjából két alapvető típusa van a memóriabővítésnek (mindkettő vezérlőregisztere a $fd11-$fd1f címek közé lapozódik):
- a Csory féle, ami max. 256k és annyit tud, hogy a 64k címtartományból az egyik 16k-s rész helyére a 256k-ból bármelyik 16k-t belapozhatod.
- a másik, amit Hannes-félének hívnak, ott meg azt tudod változtatni, hogy $1000 vagy $4000 legyen a vágási pont (alatta mindig az alapértelmezett RAM-bankot használja), fölötte meg választható, hogy melyik 64k-s szeleletet akarod látni, ez volt eredetileg szintén 256k, de szabad bitek vannak, 4 megáig fel lehet vinni. Ha max. 1 megás a bővítés, akkor két bittel lehet kapcsolni, hogy a Csory bővítés aktív-e (mert igazából 256k-t szoktak építeni, ami mind a Csory, mind a Hannes félét tudja).
Ezek az alaptípusok, ezek vannak még kiegészítve olyan apróságokkal, hogy a TED melyik RAM bankot lássa (kiválasztott vagy mindig az alap) és hasonlók, amire fejből nem emlékszem, de valami ilyesmi.
Ja, emulátorokban a RAM-bővítés kezelése nagyon bugos: a Yape csak Hannes-t tud, 256k-ig (az talán jól működik, nem emlékszem), a VICE meg vagy Csory vagy Hannes, de ott valami gixer volt, az nem volt teljesen százas.
Nemrég (mert még emlékszem rá :)) olvastam a P4W-ön a siziolibv3-ról. Meglepődve láttam, hogy 4Mb-os bővítés is létezett legalább elvi szinten a pluszihoz. Van valahol valamilyen dokumentációja az egyes memóriabővítések programozásának és működésének?
Legvalószínűbb az, hogy elromlott. :) A viccet félretéve itt megtalálod a hivatalos szervizkönyvet. A pdf 22. oldalától kezdődik a hibakeresési segédlet. De a fórumtársak valószínűleg majd dobnak pontosabb tippeket.
Nálam volt olyan plus/4 javításra, ahol ez a jumper át volt kötve. Az volt a hibajelenség, hogy nem ment a magnó. Egy villámgyors assembly programmal kiderült, hogy a magnó maga megy, a SENSE vonal nem jut el a $fd10-es portra, emiatt a KERNAL nem kapcsolja be a motort. Rémlett, hogy van erre jumper, ahol ezt lehet állítani, hogy merre menjen, user port felé vagy CPU felé. Akkor megnéztem a KERNAL-t és nem találtam olyan kódot (lehet, hogy felületesen néztem), ami a CPU portról veszi a SENSE jelet. Megkerestem a kapcsolási rajzot, A J8/J9 jumper pont ezt állítja. Át- (vissza-) forrasztottam a jumpert az eredeti állásba és megjavult.
Utána megnéztem a C16 kapcs. rajzát, mert ott ugye nincs 6529 a user portra: ott egy 74LS125-tel van helyettesítve, de ugyanúgy $fd10-en nézi a KERNAL.
Nekem C16-on volt (van). Néhányszor tapasztaltam olyat, hogy FOUND-nál nem állt meg a magnó. Sosem értettem, hogy miért. Egyébként az, hogy nem állt meg, inkább gyorsította a betöltést, mert (legalábbis a Tape Messias reformja előtt) a header után is van egy feleslegesen hosszú sípolás, amin így átteker a bekapcsolt kép mellett.
Végülis a probléma annyira nem lényeges, mert amelyik gép az "épített" procival ellátva a fenti magnós hibát produkálja, az eredeti procival is ugyanazt csinálja! Nem veséztem ki jobban, hogy mi lehet az oka.