--->>>EZT<<<--- csak úgy felteszem ide, nehogy elsüllyedjen a topik! :-D Ui:. Remélem a Jiffydos miatt nem ütöm meg a bokám! De nemes cél érdekében írtam egyet! :-/
Jó anyag, de nem tartalmazott számomra túl sok újdonságot. Leszámítva a tényleg hasznos időzítési diagramokat, és az FLI üzemmódok pontos működését, lényegében csak az üzemmódok pontos bekapcsolása és a memóriatérképek vannak. Ezek benne vannak a Programmer's Reference Guide-ban is.
Ha a sprite és pár VIC-II specifikus dolgot kihagyom, akkor egy erős becsléssel kb. 50-60%-át különösebb utánajárásán és egyeztetés nélkül meg tudnám írni, az SVS Ultimate Map, és a Plus/4 fórumok olvasgatásával és a Plus/4 enciklopédiával (http://plus4world.powweb.com/plus4encyclopedia/500027) kb 70%. Eléggé csapnivaló programozónak tartom magamat, a tudásom inkább elméleti jellegű, ha Valaki ebben benne is van mint programozó, 85-90%-ban ugyanezt meg tudná csinálni.
Persze baromi sok szöveget kell beírni, de nekem 2-3 oldal beírása csak ujjgyakorlat. Lehet, hogy ha lement ez az őrület a munkahelyemen, akkor belevágok a C64 doksi alapján egy TED klónba, az év végéig össze tudnék hozni valami hasonlót 60-70%-ban. (sajnos egy lyme kóros kullancscsípés óta néha felcserélem a karaktereket, emiatt a szöveg visszaellenőrzése akár még több időt is vehet igénybe, mint maga a megírás; aránylag olcsón megúsztam a dolgot)
OK, értem már. Ebben az emulátorokat fejlesztő urak a legjobbak, Gaia, IstvánV (Enterprise emut is fejlesztett); ott pontosan kell a ciklusokat emulálni, hogy az összes demo, stb kép és hangeffektjei működjenek. Ehhez persze nagyon sok reszelés és finomhangolás kell, nagy eséllyel nem valamilyen dokumnetáció alapján oldották meg az időzítési problémákat.
Szerintem SuperCPU nem pont erre gondolt. Legalább is nekem nem úgy tűnik. Amit ő akar, nagyjából a híres VIC article TED-es megfelelője. Olyan meg "véletlenül" nincs senkinek.
A belső működés tekintetében a VIC-től valószínűleg annyi az eltérés, hogy soronként kevesebb a ciklus, nincs sprite adat fetch és kettő badline van. Esetleg még az állapotváltások pontjai esnek más ciklusra, de azt a TED dokuból kinézve és a VIC article-be behelyettesítve szerintem kiderül amit SuperCPU szeretne. Ha már azzal foglalkozik a kolléga, akkor összefésülhetné a vonatkozó részeket egy új leírásba. Meg egyszer láttam lft-nek egy táblázatát, ami szintén a működést modellezte.
Egyrészt érdemes letölteni az SVS Ultimate map-et a plus4world.com-ról
A TED fülön szinte minden rajta van, gyakran összevetve a C64-el is.
(egy hibát találtam benne nem oly régen: a karakteres kép és annak a színmemóriáját a leírásnál felcseréli.
A Plus/4-nél a színmemória van alul, a karakteres kép utána következik, viszont a leírásban fordítva írja (color RAM is above...)
A címzéseknél már jól van jelölve (SVS-nek küldtem róla jelzést)
A C64-en pl a színmemória csak egy adott fix helyen lehet, míg a Plus/4-nél más helyen is lehet. Ami azért könnyebbség, mert ha le van tárolva, nem kell másolgatni..
Ezek nagyon töredékesek, lehet hogy minden infó szerepel vagy fejben összerakható belőle,.
....bár akkor kb. az FPGA-TED forráskód teljes visszafelé megértése (nem fehérembernek való feladat) lehet """egyszerűbb""", mint ezekből a "van 40byte valami buffer" infómorzsákból legózni.
Én úgy okoskodtam, ha lelapozom az összes romot, nem tud IRQ végrehajtódni.
Mondjuk a végül ide betett példám valóban pont rossz, mert a beépített ROM-ban van IRQ...de próbáltam már SEI+JMP$ végtelen ciklussal is, FDxx-írástól függetlenül mindig a BASIC eleje van a képernyőn.
A yape annyival jobb(?), legalább a karaktergenerátor "eltűnik" egy fddf írás után, mert mind2 lapon külső ROM van, amiben nincs karakter adat. De a színmemória olyankor is mutatja, hogy magát a képet még mindig ugyanonnan rajzolja, ugyanazok a szines kockák vannak, mint ami a FDxx írás nélkül.
A BRK kezelője szerintem visszaállítja a KERNAL ROM-t. Van a PLA-nak egy KERNAL nevű kimenete, ami akkor lesz aktív, ha $fc00-$ffff címeket szólítasz meg és ez minden ROM olvasásnál ebben a címtartományban a KERNAL kiválasztását kényszeríti. Az IRQ kezelő meg így indul:
. FCB3 48 PHA
. FCB4 8A TXA
. FCB5 48 PHA
. FCB6 98 TYA
. FCB7 48 PHA
. FCB8 8D D0 FD STA $FDD0
. FCBB 4C 00 CE JMP $CE00
$ce00-nál megnézi, hogy BRK volt-e:
. CE00 BA TSX
. CE01 BD 04 01 LDA $0104,X
. CE04 29 10 AND #$10
. CE06 D0 03 BNE $CE0B
. CE08 6C 14 03 JMP ($0314)
. CE0B 6C 16 03 JMP ($0316)
Most azt hirtelen nem találom, hogy mit csinál a BRK kezelő a ROM bankkal, de az IRQ vége biztosan az, hogy
. FCC9 A6 FB LDX $FB
. FCCB 9D D0 FD STA $FDD0,X
Tehát ha nem tiltod le a megszakításokat és JMP * -al fejezed be a programodat, akkor valaki később garantáltan visszaállítja a $0-s ROM bankot (BASIC+KERNAL). Ha $FB-re $05-öt írsz, akkor a megszakítás végén az visszaállítja neked a saját bankodat. Kivéve, ha a BRK rutin valahol $0-t ír a $FB-re.
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.