16Ks játékokról beszélünk, ennyi fért bele. Hasonló kóddal, 64K-ban sokkal részletesebb és több grafika belefért volna, de nagyon kevés 64K játék fejlesztődött
A Spectrumban nem erősebb a proci. Amit a Spectrum meg tud csinálni, azt a Plus/4os direkt konverziói mind meg tudták csinálni, csak gyorsabban.
A Sabrewulf konverziót konkrétan le kellett lassítani, mert az első verzió játszhatatlanul gyors volt plus/4-en.
Mindent, amit tud a ZX Spectrum 48K, azt a Plus/4 is tudja, csak sokkal jobban,
Legyen az CPU sebesség, grafika, hang, memória, csatlakoztathatóság.
A Spectrum 128 csak 1985/86-ban jelent meg, ami több szempontból már jobb mint a Plus/4 (hang, memória, bővíthetőség, CP/M), de a grafika továbbra is gyengusz maradt, pedig csinálhattak volna egy új módot, valami hasonlót, mint amikor a plus/4 kibővítette a 16os színteret a világosság jellel.
A Tir Na Nog-nál a Spectrum scroll egy kissé tényleg akadozik. A C64 dettó, amit láttam a tube-on.
A Plus/4 verzió teljesen folyamatos.
HW sprite: kincs ami nincs, tehát a kicsinek is örülünk :-)
A Zylonra tett megjegyzéseddel nem értek egyet. Ha gondolod, próbálj meg leprogramozni pl SuperCPUra HW segítség nélkül ekkora soft-sprite-ot, attributum kezelést, kitakarásokat, collision detectiont, állítólag penge vagy benne. Meglátod az mennyire lesz folyamatos.
Pontosan emiatt nem játékgép a plus/4, mert hw sprite hiányában a játékok egy részét (nem mindet) nehezebb leprogramozni, mint az árkád vagy c64 gépeken.
(PC VGA-n a roppant egyszerű chunky 320x200x256szín módban baromi egyszerű software spite-ot programozni, mert nincs szín-ütközés meg attributum)
-Driller: 3D majdnem ugyanolyan, grafikusan karakterenként eggyel kevesebb szabad szín
-Elite: wireframe grafika ugyanolyan, csak a plus/4 gyorsabb
-Grafikus/karakteres kalandjátékok: ugyanolyan, sőt a plus/4 alapból támogatja a grafikus/karakteres osztott képernyőt.
-Logikai tologatós játékok: Fekete háttér előtt mozgó blokkok: nincs sprite, de meg mehet oldani
-Egyszerű platformerek: egyszínű háttér előtt mozgó blokkok: nincs sprite, de meg mehet oldani
-Akciójátékok bonyolult háttér előtt mozgó karakterekkel: nem lehet vagy csak erős limitációkkal lehet megoldani plus/4en. A Turrican például pont ilyen, de számos játékot erős színütközéssel, vagy a karakter blokk körüli fekete kerettel oldották meg.
Voltak szép és gyors szoftver sprite szimulációk roppant jó collision detectionnel, de kevés volt az ilyen jó programozó. Például a Magician's Curse vagy a Zylon, ezeken nem látszik, hogy nem hardver sprite-al oldották meg.
A legutolsó hasonló játékok már a Plus/4en is elég profin néznek ki, az Adventures in Time, Pet rescue mind nagyon okésan oldotta ezt (is) meg.
Megy a finomscroll a Plus/4-nek, van rá HW regiszter, és szépen meg is lehet oldani. Ezzel még az Atari ST-t is megelőzi :-) (Igaz az Atari STE és a Mega ST már tudta ezt is, és a 8bites Atarik is)
Plus/4-en ebben az esetben az a gond, hogy nincs HW sprite. Így a regiszter állításakor nemcsak a háttér (mint a C64en), hanem az ellenség és a játékos űrhajója is scrollozódik.
Tehát ilyenkor egy másik képet kell kirakni az űrhajókból
Mivel karakteres grafikának nézem, a teljes finomscrollhoz az űrhajók esetén 4 fázist kell eltárolni (mivel multicolor, ezért 2 pixeles egy pont, tehát 4 scroll fázis van). A függőleges eltolással eltárolt űrhajóról nem is beszéltem.
Persze ezeket a tologatásokat meg lehet is csinálni a Plus/4-el szoftveresen, csak az is raszteridő.
Elég sok dolog mozog ezen a képernyőn egyszerre, hogy megérje a raszteridőn vagy a memórián spórolni (emellett az elérhető raszteridőt terhelik a hangeffektek, zenelejátszó, lövések mozgatása, collision control meg hasonló nyalánkságok amihez szintén nem értek). Tehát ebben az esetben a 4 pixeles scrollal sok mindent meg lehet spórolni.
A leírása szerint 25Hz a frissítés, azaz két frame-enként rajzol új képet. A többi sima matek: mondjuk ha egy másodperc alatt 100 pixelt akarsz scrollozni, akkor 100Hz frissítéssel ez 1pixel/frame, 50Hz-nél 2pixel/frame, 25Hz-nél meg 4pixel/frame. Nyilván itt nem scrolloz 100pixelt/másodperc, de a matek hasonló.
Mert mondjuk megy a finomscroll a Plusinak? Egy kicsit feltennéd a gondolkodó sapkát? Ha nincs hardver sprite és multicolor felbontásban csinálod a grafikát milyen lesz a látvány ha a képpontnál kisebb eltolást alkalmazol? Csak nem jobbra-balra (előre-hátra) fog fűrészelni a mozgó objektum? Jól nézne az ki?
De persze ismerhetsz olyan grafikai és programozási technikákat, amivel ezt sikerrel el lehet kendőzni a látvány és a teljesítmény romlása nélkül. Szerintem minden 16-os és pluszi tulaj és rajongó nagyon örülne, ha megosztanád velünk ezt a titkot.
Mondjuk a finomscroll még mindig nem megy a Plusinak, de miért nem? Nagyon darabos, igaz, nem karakteres balra scroll van, talán 4 pixeles, de passz, az biztos, h nem pixelnyi a lépésköz, hanem nagyobb.
Pi1541 display upgrade. Egy Amiga Gotek projectből visszamaradt kiskijelzőt rákötöttem a Pi1541-re, tök jól működik. Ami elég furcsa benne, hogy nem találtam olyan demót C64-re ami ne menne vele, szóval úgy tűnik, hogy 100%-os a 1541-es drive emuláció, de mégsem, mert Plus/4-en a 'Pets Rescue' az 1. pálya betöltése közben kifagy.
Megj. hogy topiktéma maradjon: a Plus/4-en is lehet játszadozni vele, pl. ha kikapcsolod a képet, és/vagy átkapcsolod fix slow clock-ra stb., szintén jelzi neked pontosan a CPU átlagsebességének a változásait (ld. 0.89 vs 1.70 MHz és társai). Sajnos pont a legérdekesebbik mérésre azonban NEM alkalmas: a PAL/NTSC átkapcsolós TED-bit "turbó" trükk esetében nem értelmezhető (azért nem, mert pont a képfrissítést használja fel fix pontnak a méréshez, ami ekkor ugye megváltozik valahogy, és nem tud tovább támaszkodni rá). Még VIC-20-on is működik a módszer egyébként.
Ha tényleg készítene egyszer valaki egy turbókártyát Plus/4-re (mint amit itt emlegetett valaki), azt is lehetne majd mérni vele valószínűleg... (Feltéve, hogy a TED chip működése közben nem változik meg.)
Még annyi, hogy ha az IEEE-488 interface-be ölöd az idődet (vagy atz IEC22IEE-re), arra akár a Commodore IEEE HDD is ráköthető.
Plus/4 OFF Sőt láttam egy nagyon exkluzív CP/M terminált PET-re, ami az IEEE interface-en és egy programon keresztül "rabszolga sorba" (terminálüzemmódba) száműzte a PET gépet, és egy teljes CP/Met futtatott egy kvázi külső gépen, a PET csak a billentyűzet és megjelenítő szerepet töltötte be. Mivel másodpercenként kb 1.4KB-ot tud áttölteni az IEEE trükkök nélkül, ez pont elegendő volt a (fekete fehér) karakteres képernyőtartalom frissítésére. http://mikenaberezny.com/hardware/pet-cbm/sse-softbox-z80-computer/ http://mikenaberezny.com/wp-content/uploads/2011/05/softbox-schematic.png Very complex :-D
Ez kissé butaságnak tűnhet, csakhogy akkoriban a CP/M olyan fejlettségűnek tűnt, mint később az MS-DOS, tehát ez az eszköz kvázi PC emulációt csinált a PET-en (Pascal, C compilerek, Wordstar profi szövegszerkesztő, stb lettek vele elérhetőek, futtathatóak, egy CP/M masina árának töredékkéért). Ráadásul erre még HDD-t is lehetett kötni, amiről a CP/M boot-olhatott.
Aki még ismerte a PC XT szintű vonalat, az nagyjából képben van, milyen (még nem garfikus felületű) jellegű programokról beszélek. (A C64-re volt egy hasonló CP/M cartridge, csak az az esetek 80%-ban nem működött, A C128 már igen).
Plus/4 ON
A CP/M csak 80 karakteren működött, tehát a folyamatosan futó terminál program mellett még egy soft 80 column üzemmód vitelezése is szükséges lenne, hogy CP/M-et lehessen futtatni Plus/4-en. Hogy ez mire lenne jó? Profi karakteres szövegszerkesztő a 3+1 helyett :-)
(komment: épp el akartam magyarázni, hogy wzerintem az 1551 és a IEEE interface-ek alapvetően máshogy működnek, és ránéztem a CMD IEEE Interface-ére (CIE a neve) és pont ugyanazt a "haszontalan" MOS 6525 IC-t alkalmazza, mint az 1551, vagy a Commodore sajár C64 IEEE inteface-e ooooopss). Egyébként ugyanez az IC volt használva a CDTV-ben, meg az A570 Amiga CD lejátszóban. Szánalmas, hogy milyen elavult alkatrészek voltak az 1551-ben :-D
Úgyhogy ha az 1551 C64-re kötését tervezed, akkor érdemes erre ránézned, valami hasonlót végzett a CMD a lenki áramkörrel, csak IEEE-488 eszközökkel (hasonló 8 bites adatátvitel és sebesség, persze más a protokol) https://imgur.com/a/bIDjqEb
Egyébként a CMD IEEE eszköze az, ami az egyik legegyszerűbb és legelegánsabb (szerintem), összevetve pl. a Commodore saját C64 IEEE488 vagy VIC1122 Cartridge-al (VIC-20-hoz).
Emellett vannak a IEC-re IEEE eszközöket csatoló cartridge-ek, ezek gyakorlatilag online fordítják a jeleket. A legbonyolultabb az Interpod nevű eszköz, ami az IEC-re mappel RS232 és IEEE488 interface-eket. elég bonyolult.
Ebből a legolcsóbb és legelegánsabb megoldás az NLQ.DE(Jochen Adler) által kifejlesztett ATMEL alapú kapcsolás, amit Codekiller fejlesztett tovább az engedélyével, jóval kisebb helyen megvalósítva ugyanazt a funkciót, egy centronics csatlakozó házban elfér. http://www.nlq.de
A program lehetőség szerint csak az aktuális állapotot méri fel (ez benne van a leírásában), de lehetőleg minél átfogóbban, részint pont azért, hogy össze lehessen hasonlítani az eredményeket. Pl. ha kikapcsolod előtte a képernyőt, vagy sprite-okat helyezel el a képen stb., akkor nyilván minden egyes ilyen esetben egy kicsit más-más lesz a vége. Éppen ettől érdekes, mert látni vele, egy-egy adott változtatás mivel jár. Nekem nincsen SCPU-m (mint ahogyan nincs MEGA65-öm sem), csak feljegyzem a mások által visszajelzett adatokat. Nem tudom, ők hogy állították be a hardvert előtte. Ha neked van, és lenne kedved megvizsgálni többféle beállítás mellett, akkor nagy örömmel látnám, mit hoz ki. (Amúgy mivel open-source, a forráskódban megnézheted pontosan, hogy mit csinál.)
Tehát van rá - elvi - lehetőség, h a C-64 kezelje a 1551-et.
Úgy gondolom - 99%, h eltévesztettem a házszámot! -, az SFD1001 megoldásából kéne kiindulni, ugye? Mert közvetlenül NEM lehet kezelni a 1001-et, kell egy kezelő program, amit ez az IEEE488 kártya tartalmaz. (Nem tudom, mi a kártya neve, ex-has elneveztem.)
Valamilyen elven belapozgatja a 1001-ről jövő adatokat valamelyik lábon keresztül - felteszem, EXROM-nak mondja a 1001-et és az IO1 - $DE00(?) -, vagy IO2-es - $DF00(?) - lábon keresztül belapozza a valamelyikük területére a byte-okat?
Az 5-ös lábon keresztül lehet eldönteni, írás / olvasás legyen. Gondolom...
Az EXROM-on keresztül az alapgép bekapcsolásakor betölti a 1001-et kezelő rutinokat, de lehet, tévedek.
Mintha Gaia Mester írta volna valamikor, h mely memóriaterületre - talán a $FEC0 / F0-ra? - lapozódik be a 1551-es. Ezt - elvileg - be lehet adni a C-64 oldalról is neki, h ide van belapozva, eze(ke)n a címe(ke)n keresztül látszódik.
Ha ez így igaz - kizárt, csak elmélkedem! -, akkor már "csak" meg kell tudni szólítani a drive-ot, valahogy. Talán a YAPE-ban lévő kezelőrutinok átírása segít? Sokat kellene módosítani? Mondjuk ezt az emulátor írója tudná megmondani...
Röviden összefoglalva:
- hasonlóan a 1001-et vezérlő crtg-hoz, valami ilyesmi programmal kéne elhitetni a 1551-gyel, h Plus/4-en van?
- mennyit kell(ene) módosítani a YAPE-s emulátorban lévő 1551-et kezelő rutinon, h C-64-en fusson? Talán a C-64-nek megfelelő memória-címekre módosítva működhet?
- vagy van kifejezetten 1551 specifikus cím, címek, ami miatt cím-konverzió kell? Pl mondjuk $8000 "fölé" töltendő program esetében ugye a ROM alá kell tölteni, ami Plus/4-nél nincs, ott kb 57 kByte-nyi közvetlenül elérhető RAM van.
- hw-esen "közvetlen" össze lehet kötni a C-64-gyel? A feszültségek (+/-) ugyan azok?
Most tekintsünk el attól, h nem lehet kapni Plus/4-es expansion portot, azzal később is ráérünk foglalkozni - egyet fel tudok ajánlani!
Az SCPU kint a gyors statikus ramban "tükrözi" a gép ramját (ha ezt egy-egy lapra bekapcsolod), plusz van egy egyértékes regiszter, egy "mikro-fifo" ami majd megvalósítja az írásokat, ha a lassú busz "ráér". Tehát olvasásra a gyorsan beírt másolatból azonnal kapunk értéket, írásra meg sem kell megvárni ameddig a lassú buszon teljesül.
Ha jól emlékszem, a nagyobb PLD-s V2 CPU-ban ez már igazi fifo, tehát megszabhatod hány értéket akarsz "várakoztatni", a gyors végrehajtás mindaddig nem vár arra (vagy te várhatsz tervezetten!) amíg tele nem lesz a fifo..
Kivéve az IO terület, mert ott a tényleges beolvasott értékre vagyunk (feltehetően) kíváncsiak, nem egy statikus másolatra, és írásra sem mindig tanácsos saját időzításünk helyett egy random "na most lehet" első szabad pillanatban rádobni az értéket.
Ezektől bonyolult az SCPU, hogy mindez regiszterekkel konfigurálhatóan meg van valósítva benne.
Ha fogunk egy gyors "emulátort",(nevezzünk most így mindent, ami nem az eredeti VAS), ami pl. vga képet rajzol, és az eredeti gép időzítéséhez semmi köze, teljesen mindegy, hogy szoftvres emulátor vagy módosított gyorshardveres másolat, ezek a problémák nem merülnek így fel, nyilván gyorsabb rendszert lehet csinálni, határ a csillagos ég.
Pont ez volt a nagy ötlet az SCPU-ban, nem az egész gépet replikálja (ez akkoriban lehetetlen lett volna) még az IO-t is meghagyja a helyén, nem kell beledugni a floppy-t, nem kell külső billentyű, nem kell semmi, sőt a belső 64k lassú ramot is használhatod egyfajta lassú"tárolónak", mégis van egy külső gyorsabb procid, neki való gyors külső rammal)
Tehát ha nem tudsz és akarsz SCPU-t programozni, csak elindítassz egy ilyen progit, más értékeket kapsz,...
.... -akár magával a progival- is más lenne, ha előzetesen konfigurálnád, hogy mindezek a műveletek fussanak kint és csak kint a gyors ramban, rögtön nem várnánk a lassú buszra és ha nem is 20 de 14-17 mhz körüli értéket adna (ha jó a program, és helyesen számol, ekkora sebességnél is)
Igazából azért az a SuperCPU sem olyan nagy adu ász, mint amilyennek látszik elsőre, mert van pár hátulütője, legalábbis 8-bit turbó tekintetében. (A 16-bites használata lenne inkább érdekesebb, de arra meg nincs szoftver.) A külső és a belső memóriák összehangolása egész sokat visszafékezhet, ha úgy jön ki a lépés. Ha pusztán a CPU pörög magában, úgy igen, az 20 MHz, de minél több a memóriaművelet a kódban, végül átlagosan annál lassúbb lesz.
Tavaly írtam ezt a kis MemTest64 nevű proggit (mely Plus/4-en is fut amúgy! szóval ez itt ontopik ;) ), ami nemcsak a memóriabővítőket teszteli, de többek közt megméri a CPU sebességét is, vagyis olyan formában, hogy tapasztalati úton mennyinek érzékelhető a szoftver számára. Lásd alább:
Ezzel tesztelve az SCPU-t például, csak kb. 8-9 MHz körüli sebességek jönnek ki (még egyszer a kulcsszó: sok-sok memóriaművelet az első 64K-ban).
Ugyanez a Turbo Chameleon esetében több, mint 14 MHz. A MEGA65-ön kb. 36 MHz jött ki (de ez még csak tavaly volt, majd meglátjuk, a végső verzióban mennyit nyom).
Kíváncsi leszek majd az U64-re, ha egyszer eljut odáig, mert Gideon szerint akár 31 MHz körüli turbóteljesítmény lenne saccolható rá.
Hanem hogy valaki megírja az 1551 normális kezelését C64-re.
Darab drótokkal egyébként itt (sem) lehet, kell némi áramkör is.
De ha drótokkal sikerül, oké, és? A csupadrót kártyára úgyis kellene eprom is,...
...legalábbis gondolom nem először 1541-ről akarod betölteni az 1551 loadert, majd utána tudsz csak 1551-et használni.
... kivéve amíg valamivel felül nem töltöd, vagy az első reset, runstoprestore vissza nem "löki" a vektorokat..ugyebár.
Az áramkört, meg kell tervezni, részben le kell szimulálni(tanácsos), majd összedrótozott prototipusokat építeni, kisérletezni, mérni, mint anno pl. a boticelli hardverkulcsnál csináltuk itt, olvasd csak vissza.
Kell szoftveres guru, "code supporter" is, abban a projectben volt egy topic beli kollega, aki szoftveres patchet irt a feladatra, annyira visszafejtette, itt ilyen mélységbe kellene a C+4 kernalba belemenni, majd adoptálni C64-re.
És sokkal jobb team együttműködés lenne szükséges,...csak épp kinek van ennyi deje.....néha te sem irsz hetekig...(sőt)
Ott belefért, hogy 2-3 naponta ír valamelyikünk választ vagy kérdést, vagy akármit, itt ha valami félremegy, meg sem mukkan a drive, és mivel az egész gépet mindenestül nem lehet áramkörszimulátorban megvalósítani, senkinek halvány fingja nem lesz, mi a bánat történik, mi nem jó.
Ez nem a kis-isis kössük össze az egyforma akármiket feladat, akármennyire is szeretnéd ezt hinni, ha az analóg tv bemenetét bekötöd hdmi-re sosem lesz semmiféle kép.
Igen, ettől még a dolog lehetséges, elvben.
Hasonló a két gép, a két busz, nem látszik előzetesen olyasmi, ami teljesen lehetetlenné tenné, még akár egész kevés alkatrésszel is, de nem arról van szó, hogy kössünk össze 10huzalt meg írjunk le pártucat utasítást és kész, hurrá.
Egyetlen egy miatt írtam le ezt, azthiszem újra, mert egyszer már röviden vázoltuk itt a lehetőségeket.
Nagyon-nagyon régen, valaha, nekem is volt ilyesmi perverzióm, még a hőskorban, a 80as években álmodoztunk, micsoda szupergép lenne, ami egyben lenne C64 és Plusz4 IS.
Akkor a haverok fele azt mondta ez teljesen lehetetlen, másik része, hogyha lehet is, totál hülyeség, csak mi tartottunk ki a baromságunk mellett, hogy de akkor mi lennél, plusz vagy C64es, hát, kisöcsi, mindkettő, de egyben(!) és elővenném a SzuperGépet.
Azóta sok víz lefolyt a dunán, és nem is voltunk teljesen egyedül akkoriban a hülyeséggel, Csory nevű hardware guru, tőlünk teljesen függetlenül álmodozott (tudtunk nélkül, tőlünk függetlenül) kb jó 5 ével később komplett VIC beépítéséről a plusiba, meg készült SID hang, meg stb.
Mostanra ez viszont valami olyan, mint veterán mercit és veterán fiatot keverni, agymenés, és feltehetően keveseknek tetszik.
Mondjuk a pluszi "képességeit" sokban "bővítené", ha korlátosan, egyes régen létező C64 bővítések elkezdenének "kicsit plusz4 bővítések" lenni, talán...bár ez sokakat nem igen érdekelne megintcsak, akik annak szeretik a gépet ami, és nem akarnak kicsit sem "valami mást" csinálni belőle.
Tehát az irány kérdéses, viszont errefelé lenne valamiféle lépés lenne az 1551---C64, azonban teljesen jelképes lépés.
100% kompatibilis lemezmeghajtó most is van, tehát nem visz ez sehova, így valószinűleg sosem lesz belőle semmi.
Valami nem kóser, mert pl 8:20-tól rángatózik az alsó borderen lévő raszternyesedék. Miért? Gondolom valami időzítési gond lehet, talán nem lehet pontosabban kiidőzíteni, de fogalmam sincs.
Egyébként meg a 9:14-nél lévő nyilas rasztertrükk pofás!
Készítettem egy hevenyészett rajzot - nyilván nem jó, de azért is készítettem, hátha valakinek van ötlete, vajon működne-e a kapcsolás?
Fogalmam sincs, h a 1551 felőli E - 00, D - RAS, 12 - MUX lábakat hová lehetne kötni a C-64 expansion portja felől? Mi kell még, h lehessen kezelni a 1551-et? Egyelőre HW szinten, a SW ráér. Úgy gondolom, kb úgy kéne működnie, mint a 1001-nek, de nem vennék rá mérget.
Egyáltalán meg lehet oldani a 1551 kezelését?
Most tekintsünk el olyan "apróságoktól", pl nem egyforma a paddle és az exp. port lábosztása. A feszültségek - pozitív itt / negatív ott - megfelelnek? Direktben összeköthető lenne?
Készítettem egy hevenyészett rajzot - nyilván nem jó, de azért is készítettem, hátha valakinek van ötlete, vajon működne-e a kapcsolás?
