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.
Valóban a C16-nál van pár 470 picoF-s kondenzátor, ami a Plus/4-nél nincs. De ezeknek funkcionálisan nem lehet sok szerepük, talán azért kell, mert a C16-ban nem annyira stabil a belső táp.
Amennyire tudom a 6510-nél a kazettás jelenség olyasmi, hogy a gép nem tudja pl megállítani a motort a töltés végén, meg a megtalált header után nem tudod gyorsítani (visszaigazolni?) a töltési folyamatot gomb lenyomásával. Ha jól tudom a $01-es címhez van köze.
Ebben nem lehetne különbség a C16 és Plus/4 között.
Ebben az esetben lehet hogy az SVS Ultimate Map segíthet:
a Plus/4-en a6-os (7-es? rajz szerint a 6-os) láb is rá van kötve a Datasette WRT vonalra, míg a C16-on nincs.
A doksi szerint a J8 és J9 babrálásával (megcserélésével?) lehet rábírni a Plus/4-et a C16 szerinti működésre.
Ahonnan linkelted a kapcsolási rajzot, ott meg van a tizenhatosé is. Azon mintha látszana egy-két alkatrész a kérdéses vidéken, ami a plusziban nincs meg. Már amennyire látom. Az lehet oka a stabilabb működésnek?
A magnó és IEC busz egymást-zavarása közsimert pluszis anomália, a probléma elepvető oka, hogy bizonyos IEC és kazetta vonalak közösek. Mivel a procin nincs annyi port, amennyi kellene.
Gondolom valamelyik volanlat nem tökéltesen fogadja, "illeszti" az a magnó, további nagyon részletes vizsgálatot igényelne, miért működik C16-al mégis.
pontosan ezt csinálja (PRG-ből TAP vagy WAV file), meg visszafelé is.
Ha kész a WAV file, akkor a PC-ről egyszerűen átjátszod egy kazettás deck-re.Ezt én egyszer próbáltam, gond nélkül felvette. Igaz már nincsenek dataset-jeim, kiszórtam őket pár éve (bocs)
Ehhez persze kell egy régebbi kazettás deck vagy AUX bemenetes mikrohifi torony kazettás egységgel.
Az utóbbi manapság már elég ritka darab (főleg au audio bemenet), de én is tudtam egyet venni pár éve. ÚJAT (leértékelve volt 11k)!
Sony MicroHifi CMT-EH25. Egész korrektül szól, vagy MP3 CD és USBről MP3 lejátszás.
Benne van minden, ami kell. Ennél sokkal jobbat nem nagyon lehet kapni.
Az a gond evvel az analóg zenehallgatásra szánt cuccal magnózással, hogy a C= kazikon tulajdonképpen nem hang van.
Nyilván a kazetta miatt nem nagyon lehetett átlépni a hangfrekvenciás tartomány határait, tehát van olyan magnó, olyan file ami működik, de alapvetően ezek a digitális jelek messze túllépik lefelé (és felfelé is!) a tipikus magnók sávszélességét.
Ebből az lesz, hogy ahol a mágnesességnek 1-0 "aránylag hirtelen kellene átugrani" ott egy ilyen elnyújtott(abb) átmenet keletkezik.
Ha véletlenül az, amikor erre olvasáskor a komparátor már 1-et ad, belefér az időzítés tűrésébe épp, akkor helyes lesz a töltés, ha kicsúszik, akkor ott keletkezik egy hibás bit és load error.
Nyilván a komparátor érzékelési szintjének, vagy a bemenő jel szintjének változtatásával adott határok közt ez a dolog befolyásolható, de mivel nem a problémát kezeljük, csak megkerüljük, végtelenségig lehet szívni evvel.
A tapuino és a digitális megoldások viszont tökéletesen működnek, mivel semmi analóg mágneses dolog nincs a képben, azonnal tökéletes időzítéssel kapja a gép az 1-0-0-1 átmeneteket.
Én mondjuk tapuino helyett inkább drive emulátorban gondolkodnék... pl..:
A 6502-8501 fejlesztést teszteltem, amikoris észrevettem, hogy plus/4-en, ha a magnó és a floppy be van dugva a gépbe, akkor a DIRECTORY-t nyomva vagy lefut a beolvasás-kiírás vagy megfagy és a floppy drive csak pörög tovább. Kipróbáltam eredeti processzorral(8501), azzal is ugyanaz a történet. Mással is kipróbáltattam, hasonló sikertelenséggel.
A magnóm egy commodore feliratú fehér jószág aminek a csatlakozóját(C64) lecseréltem minidinre(C16). Van egy szürke eredeti commodore 1531 magnóm amit szintén rádugtam a fehér magnó helyett, azzal meg tökéletesen megy együtt a floppy drive. Szétszedtem mindkét magnót és hiába a commodore felirat a kasztnin, a nyáklapok különböznek. A szürke magnó nyáklapján ott virít egy 1531 felirat is.
Ráadás! A C16-ban bármelyik magnót bedugva a floppy drive-al tökéletesen hozza a DIRECTORY parancsot. :D
A 264-es széria (plus/4, C16, C116, stb.) KERNAL-jában 0-ról újraírták a magnó-kezelő részt, valószínűleg ezért fordulhatott meg a logika. A PET/VIC20/C64/C128 magnóhoz képest csak a csatlakozó más. (meg a színe)
A csatlakozón kívül egyébént a szalag-kezelő rutionokat is még az eredeti PET-ből vitték tovább, egészen a C128-ig. (kivéve ugye a 264-es sorozatot)