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