Szerintem nekem az utsó, amivel játszottam (és végigjátszottam) az a Twin Kingdom Valley volt. :) Ebbe is csak belenéztem, hogy működik-e nagyjából, aztán viszonylag hamar elakadtam és átküldtem Stefannak, hogy nézze meg, hogy jó-e. :)
Igazából egyet csíptem: amelyik mindig azt írta, hogy Buksi ugatását hallod. :) Na megvan. Bocs, de Monkey Island óta nem valószínű, hogy bírnék még ilyenekkel játszani (de becsületből eljutottam egy tucat that's not likely to work-ig anélkül, hogy bármi más történt volna:)). Azért köszönjük, és lelkesebb játékosokat!
Ha valaki szereti a szöveges kalandjátékokat: átportoltam a DAAD motort plus/4-re, két játék jött ki vele (eddig): plus4world.powweb.com/forum/38951 .
A lemezek plus/4-en sajna nem autostartosak (legalábbis a YAPE load"*",8,1 -et indít, így pont nem megy, shift+run/stop-al viszont igen). Tartalmazzák a C64 és a plus/4 verziót is, a loader detektálja, hogy melyiken vagy és azt indítja.
Ez tipikusan az a buta eset, amikor "a több túl sok".
A chipek pedig félig házon belül készültek (MOS), mégis a gépekben sokszor körbe kellett rakni mindenféle "kiváltó" és "kiegészítő", lebutító, "máshogy használó" funkcióval, kóddal, áramkörrel.
Ezek cmos, un. totempole portok, képtelenek open collectort korrektül megvalósítani, pedig korrekt, védett, biztonságos, relative "gyors", többirányú(!), több szereplős adatvezeték ebben a korban csak így képzelhető el. Kvázi un. "huzalozott vagy", bárki lehúzhatja, és bárki megnézheti, le van-e húzva, miközben nem ő húzta le.
Persze lehetne valami ellenállásos szembehajtás védelem, vagy valami diódás gány, de a C64-ben és előtte a VC20ben már bevállt egy séma, a drive-okban is ez volt, nem akartak módosítani már később sem. Itt ráadásul minden ciklus fáj, hiszen így is gyárilag beteg lassú a busz, ha folyton az adatirányt kell piszkálni, és nézegetni a szintet, még rosszabb lenne.
Eleve egy kapkodva kitalált szerencsétlenség az egész, hiszen az IEC eredetileg a VIA gyors léptetőregiszteres hardveres soros képességeire lett megálmodva, majd ebből lett több éven és gépgeneráción átívelő szoftveres bitbang-es, utólagos fastloados, stb,stb "szerencsétlenkedés".
Ma különben gyakran azt képzeljük, a mai világ ennél "fejlettebb", de én ma is szépen látom az IT szektorban szokásos "holnapra olcsón rakjátok össze abból, ami van,!mindegy mennyire gány belül, ha valamennyire működik, ki kell adni,! stb,stb " szellemiséget minden munkanapomon.
Miközben más hülyeségekbe meg néha hihetetlen "semmi se drága" számolatlan erőforrás megy, nem egyszer aztán a kidobásra, a semmire, a projekt törlésre.
Érdekesek ezek a dolgok. Azt lehet tudni, hogy miért kellett a Serial lábait egynél több port lábra is bekötözni? Anélkül még akár el is férhetett volna a kettő, ha mondjuk az adatvezetéket közösítjük.
> É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?
> Ezt a kernalban szerintem full ejtették (most nem olvasok a kódban utánna, sry).
Én a múltkor megnéztem, mert került hozzám egy plus/4 azzal, hogy nem megy a magnó és azon át volt forrasztva. :) Valóban nincs a KERNAL-ban figyelés a casette sense-re a proci porton.
Nem tud a kimenet "1-re" váltani, ha lenyomja valaki a gombot, pontosabban gyárilag is magát a portot kell 1-be tenni, majd ha lehúzta a magnó, azt érzékeli a gép.
Így magnó és a user port csúnyán zavarja egymást. Mindig, ha be van a magnó dugva, és piszkálod.
Mit is írtam előbb a pluszin a gyári userportos bővítők """hatalmas számáról"""? Na ennek talán ez (is) oka lehet.
Azért illene egy kultúráltabb lepárhuzamosításnál megállni CRC error-al, legalább töltésnél.
Oké, a soros fastloadok minden ciklust mohón zabálnak, ott nem marad erő sem gép sem drive oldalon holmi CRC-re(átalában), egy párhuzamos átvitel estén azért megoldható.
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 :-)
