Nincs a prociporton elég "láb" a mgnónak és a drive-nak IS.
A sorosport (IEC) DATA lábára is átkötheted, ha nem akarsz drive-ot hazsnálni, csak magnózni, van erre egy átforrasztós jumper a plus4 lapokon.
Talán C16-hoz így tervezték, abban nincs port, de ahhoz nem is lesz drive, csak magnó...később ezt meggondolhatták.
Ezt a kernalban szerintem full ejtették (most nem olvasok a kódban utánna, sry).
Aztán, hogy mégis 100% kompatibilis legyen, a "mégócsóbb kistesó" C16-ban már nem is akartak semmiféle vagy-vagy viccmegoldást, egy LS125-el bekapuzza a címet úgyis dekódoló PLA a buszra közvetlen ezt a bitet. Evvel ezt az egyetlen bites "csak input" funkcióját "kiváltja" a plusz4-ben lévő port ic-nek.
Ami valóban eléggé bajossá teszi egy "nem kell hozzá a gépet szétszedni" userport catridge építését.
Mondjuk annakidején ez aligha lett volna rentábilis, külső címdekóder, minden firlefranc.
A +4 userportján ráadásul ott a fullos UART is, ami a C16ban amblokk nincs, talán ahhoz van a kernalban egyedül valami, maga a sima IO port, az lehet bárhol, mert független ettől a problémától.
Nyilván okozna kompatibilitási problémát egy másik utólagos userport cím (nem mintha az utólagos SID-eknei is nem 4féle címe lenne kb), ha a C64-hez hasonlóan ide is több tucatnyi userportos bővítő lenne, eprom égetőtől a teletextig, azok nem működnének más címen.
De azért nem érzem úgy, hogy így 2019 körül ennek lenne a plusz4-es világban bármi jelentősége, tucatnyi bővítés lenne, amivel majd nem működne ez,....
... és ha van is ilyen gyári userportos cucc(???), nem lehetne emulátorban tesztelve olyan 10perc alatt "megpatchelni"...:)
Egyébként ha 6529b-t használnának kivülről (nem követtem az eredeti beszélgetést, fogalmam nincs) 99% az "húzná a rövidebbet", vagy fizikailag is megsínylené, vagy legalábbis mindig a sense szintje "nyerne", képtelen lenne az izmos 125-el szembehajtani.
Lévén az egy kanyi állat dedikált buszmeghhajtó, nem holmi kis kóbor port vagy memória.
Azt lehet csinálni, hogy arra a bitre, bemenetre a SENSE-t is bekötni.
Nem szép, Ykábel a magnóportba, meg izé, meg hogynézki, de ha nem akarunk a gépbe nyúlni és eredeti címre akarjuk, annak ára van.
A kernal majd próbálná a kiírt szint alapján kapcsolgatni a motort, ha fut a felelős megszakítás (asszem abban van) ám tegye.
Olvasásra ugyanaz jön vissza mint a port IC-n keresztül, írásra meg a port IC tökéletesen ellátja a feladatot kivülről.
Akkor van "bunyó", ha valaki nem dugná be valaki ezt a kiegészítő "kábelt", de annak is elejét lehet venni egy a 6529b-t gyengítő trükkel, egy párszáz ohm körüli ellenállásal az adatbusz felé, így tuti a statikus magnó bemenet nyer, tehát Y kábel nélkül ez a bit nem működik, és ennyi.
És vajon ezt miért nem a processzor portjára kötötték, ha már minden más úgyis ott van (jól tudom)? És ez egyben azt is jelenti, hogy ha párhuzamosított 1541-gyel töltesz, akkor töltés közben a magnót nyomgatva el lehet cseszni a betöltött adatokat?
A foundnál még nem olyan lényeges megállítani, mert pont akkora üres sípolás van utána alapból felvételnél, hogy nem gond, ha nem áll meg, de a töltés végén azért jó, ha megáll. :)
A casette sense a magnóból bejövő jel, ami jelzi a gépnek, hogy a magnón valamelyik gombot lenyomtad (play/valamelyik tekerés), ami erre válaszul bekapcsolja a motort (erre ugye azért van szükség, hogy szoftverből meg lehessen állítani a kazettát, amikor kiírja, hogy FOUND xxxx).
És valóban a plus/4-nél ez bele van kötve a $fd1x-re címzett 6529B-be, C16-on meg valami TTL chipbe megy, aminek ugyanez a chip select-je. Arra nem emlékszem, hogy a többi bittel mit csinál (szerintem lebegve hagyja), szóval szerintem ettől még simán lehetne rátenni egy másik IC-t, ami "szembe hajt" az adatbuszon. Végülis a külső RAM bővítők is ezt csinálják és még eddig semminek nem lett baja tőle (legalábbis én nem tudok róla)...
Most fut egy beszélgetés a P4W-ön C16-hoz User Port fabrikálásról. Ott írta az egyik versenyző, hogy nem lehet kompatibilisen replikálni a Plus/4 User Portját külső bővítővel, mert a CASSETTE SENSE már bent valahogyan be van kötve az $FD1x címtartományba, ahová a külső 8 bites párhuzamos portot kellene belapozni. Mi ez a CASETTE SENSE, mire kell a gépnek, és miért kellett ilyen hülyén megoldani? Valakinek van erről valami információja?
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.
