Keresés

Te egy állat vagy! :)

--->>>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! :-/

Letöltöttem, átlapoztam.

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..

Nincs véletlenül valahol egy teljes leírás a TED képfelépítéséről?

http://mclauchlan.site.net.au/scott/C=Hacking/C-Hacking12/gfx.html

http://plus4world.powweb.com/plus4encyclopedia/500027

https://www.pagetable.com/docs/ted/TED%207360R0%20Preliminary%20Data%20Sheet.pdf

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.

Még sincs gond a 'Pets Rescue'-val. Újra letöltöttem és nem fagyott ki, úgy tűnik hogy a D64 volt hibás.

Nagyjából nálam is így néztek ki, de egyéb okból is főleg a plus4emu szokott beválni, és az szép bitzajt rajzolt.

Hát, nem tévedtem, sem a VICE sem a YAPE emulált TED-je nem olvas video adatot, csak az első ROM lapról.

Hibának ezt nem nevezném, mert jelenleg ez sokra nem jó, pláne egy emulátorban...de a valódi gép (nyilván) nem így működik.

Najó, a kernal végét tényleg nem lehet lelapozni, csak meg kell nézni a rajzot, ...ez még az emultároban is jó.

De a többit nem értem miért nem akar menni, közben megpróbáltam grafikus módban is, ugyanúgy mindegy melyik ROM-ot lapozom be.

Mostmár idegesít, holnap megpróbálok valamin kompozit videójelet megjeleníteni, és kipróbálom igazi gépen.

É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.

Ahhoz, hogy tudjuk mit cseszel el, tudnunk kéne azt is, hogy mit vársz mi történjen.

Egyébként VICE felejtős. Linuxon és Macen plus4emu, Windowson YAPE vagy plus4emu.

Szerintetek ilyenkor minek kellene a képernyőn lennie? Mit cseszek el?

.C:2000  A9 80       LDA #$80
.C:2002  8D 14 FF    STA $FF14
.C:2005  8D D5 FD    STA $FDD5
.C:2008  00          BRK
.C:2009  00          BRK
.C:200a  00          BRK
.C:200b  00          BRK
.C:200c  00          BRK

Mintha sem a vice, sem a yape nem működne helyesen, de ezt nem tudom elhinni..., tuti valamit én nézek el :(

Oh, tényleg bocs. A !=-t benéztem =-nek :)

Én is azt mondtam hogy nem ő az :-)

Szerintem nem. Visszaolvastam a hozzászólásait: ahhoz túl értelmesen ír programozási dolgokról és plus/4-es témákról is.

Szerintem SuperCPU != SuperCPU128 / TiedLehet / C128 / AmigaFan / RetroFan

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.

Magicians-ban a tényleges bejárható háttered általában sötét, egyszerű grafikákkal.

Hogy a show nagyobb legyen, a 256szín miatt szépen hunyorognak a csillagok. Ilyet pl ennyire klasszul C64en nem igen lehet.

Scroll viszont nincs, ez képernyőváltós játék.  Sok sprite sincs, egyedül nyomod, vagy jön 1-2 denevér, esetleg esik rád az alma.

A Zylon egy tolószékesen lassú játék, C64-en a rosszabb basic sprite demók néznek ki így.

Timeslip-ben pl egészen klassz a finomscroll, bár csak a képernyő egy harmadát scrollozza, ami ad raszteridőt minden másra.

Rengeteg kisgépen nincsen hardvare sprite, pl scectrumon sem. Viszont erősebb bennük a proci.

Erre szép példa a TirNaNog, ami máig ámulat, hogy a francba írták meg ekkora hires sprite-val, eredetileg egy spectrum game, ...

...nem teljesen reccenésmentes a scrollja, és más grafikus hiba is van, de mindenképpen ámulatba ejtő, pláne a maga korában.

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.

Finomscroll:

Bár én sem vagyok nagy programozó :-)

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.

Ööööö..., itt valami félreértés lészen!

Nem tudok programozni, még az amatőrebbnél is amatőrebb vagyok.

Szóval feltűnt ez a scrollozós dolog - emlékeztem a Turrican-ra, az szépen scrollozott: https://www.youtube.com/watch?v=nNAkBxNt0Dc

Vagy a Rambo: https://www.youtube.com/watch?v=n4l3ZVSon_4

Ne harapd le a fejem! :-)

Elkelt.

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ó.

Eladók az alábbi IC-k:

-MOS 8501 R1 C16/+4 CPU 2db
-MOS 8360 R2 C16/+4 TED 2db
-MOS 251641 251641-02 PLA C16 / C116 / +4 2db

-PAL kernal Revision 5 C16/+4 318004-05 1db
-318030-01 C16/plus4 Kernal PAL Magyar Rev1 1db
-318006-01 C16/+4 basic rom 1db

-MOS 6502 VIC-20/1541 CPU 1db
-1541 lower ROM 325302-01 1db
-1541 upper ROM 901229-5 1db
-MOS 6522 Via I/O VIC-20/1541 2db

-BLUE CHIP BCD/5.25 DISK DRIVE(1541 klón) MEL9501-40 8520 motorvezérlő 40PIN 1db

Ár: megegyezés szerint

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.

Armalyte / IO klónnak tűnik. Mindenesetre gyönyörű munka, gratulálok!

Végre kihasználják a Plus/4-et, mert eddig nagyon sok, gyatra grafikával és animációval megáldott játékot írtak rá.