Mivel konkrétan ez nem egy "hogyan segítsünk Pákásnak" nevű fórum, ezért tényleg sok minden egyébről is lehet itt cseverészni, például más jellegű Plus/4 dolgokról :-)
A Dirmaster jó kis program, de szerintem elég bugos. Többször összerogyott nekem könyvtárszerkesztés közben, kezdhettem elölről az egészet.
Szerintem pontosan jól csinálod, de mivel a az alap könyvtárszerkezet nem tudja rögzíteni a 35 track fölötti adatot, ezért lehet "normál módon" nem megy., nem tudja értelmezni a 664 blokk feletti rögzítést. Próbaképp letöltöttem a Rocket Science 185KB-os lemezét, megnyitottam a DirMasterben, majd töröltem az állományokat, de csak 664 block free lett.
Én úgy látom, hogy BAM editorban egyenként engedélyezni lehet a "foglalt" 35track feletti szektorokat jobb egérgombbal, de ettől nem nő meg a kijelzett 664 blokk, és csak simán bemásolni sem enged 664 blokk fölé. De én magam nem is értek nagyon a lemezek szerkesztéséhez. Lehet, hogy csak direkt BAM szerkesztéssel tudod megoldani a dolgot.
C64-en több ilyen tool van, mint pl a Disc Doctor for 40 track, persze ezek is inkább hardveres floppy driveokra, nem SD-re vannak kitalálva.
SD/1541-II-t próbáltad? :-) Az elvileg HW szinten emulál, tehát meg kell ennie a 40 track-es D64-et is. Talán a hétvégén lesz időm kipróbálni Rocket Science-t vele.
Ha nem fontos amit írok, hogy megoldódjanak a problémáim, akkor miért írsz ide? Nem csak a csevegés a lényeg itt. Lehet sokmindenről beszélni, de ha nem jutok előrébb, akkor kár ide írnotok, meg nekem is.
Ezeket eddig is tudtam, a 9200-as problémákra kérem a megoldást, hogyan lehet a Dirmasterrel 40 sávos lemezt csinálni, látszik hogy kezeli a mások által csinált 40 sávost, de a freeben nem látszik, csak a BAM-ban, én nem tudok 35 sávnál többet használni. Töltsd le a Dirmastert és nézd meg amiket írtam. Most nézem hogy amikor az üres d64-be átmásoltam a Rocket lemez A oldaláról az indítófile-t és a 00-08-as file-t, 40 free lett, de a BAM-ot megnézve a 36-40 már tele van, a 35 és 2-es sávokon van még hely, 8, 11 blokk, az 1-es sáv üres, 21 blokk, össz. 40 szabad. Közben a blokkszámokat összeadva 625 jön ki, nem jó az egész. Ha új d64-et nyitok és beállítom az extended tracksot, már most foglalatnak jelzi a teljes 36-40 sávokat. Ezért nem tudok 664 blokknál többet belerakni.
Pont a Rocket science-nél látszanak a file-ok, nincsenek elrejtve, 11 file van az indítófile-on kívül, ezért tudtam összeadni, össz. 709 blokkos. A B lemezén a boot file után 20 file van, össz. 753 blokk. Ez lehetséges, mert a 40 sávosnál 749 free, a 18-asba is lehet rakni adatokat. A BAM már nem ezt mutatja egyik oldalnál se, mind2 lemeznél a 36-os sávon van csak üres hely, a többi tele van 40-ig, de ez nem érdekes.
Az alap CBM (és a Jiffy) DOS nem tudja kezelni a 1541-ben a 35-nél több sávot. A lemezt magát meg lehet ilyenre formázni vele, külön programmal, de a BAM-ban (ami a szabad blokkokat számolja) nem fog szerepelni, ehhez 40-sávos DOS kell (nekem ilyenből a SpeedDOS+40 van, de nyilván másik is volt).
A Rocket Science (meg egy csomó más demó is) meg trackloader-es, ami azt jelenti, hogy normál DOS-szal csak a boot program van tárolva (ami tartalmazza a loadert is) és onnantól a loader tudja, hogy mi hol van a lemezen, ezért ezek a directory-ban meg se jelennek. Így aztán simán lehet 40 sávos a lemez, mert azt csak neki kell tudnia.
Ez az, a tokra-s linkről töltöttem le, az üzikben van. https://csdb.dk/release/?id=44110 Sima d71, semmi trükk, 376 blocks free (952 blokk adat), szerintem működni fog 2 db d64-re szedve.
Érdekes hogy azt írja ott az issuesnél, hogy "Extending a d64 from 35 to 40 tracks...", de hiába jelölöm be a Disk/extensions menüben az extended tracksot, akkor is 664 free van az üres d64-nél, pedig 749-nek kéne lennie, csak az adott d64 fejlécében a filenév mellé tesz egy kis csillagot. Nem is lehet 664 blokknál többet belemásolni. Nem jó akkor se, ha a 192 KB-os Rocket science Plus/4 demó d64-ét (A oldal) nyitom meg, látok minden file-t, össz. 708 blokk, de 0 free. 708-664=44 Ha törlök egy min. 44 blokkos file-t, akkor kezdi el mutatni a free-t, tehát most is 35 sávosan kezeli. Nem enged semmit belemásolni az eredeti d64-be, pedig 192 KB-os (ez 40 sávos adatmennyiség), a 35 sávos csak 171 KB. Miért van ez?
Akkor hogyan lehet 40 sávos, max. 749 blokkos d64-et csinálni? Nem látom. Egyáltalán mivel készítenek 40 sávos d64-eket simán, meg valódi lemezről 40 sávos d64-et? Minden lemezfilenál külön be lehet állítani az extended trackot, ami d64. D71-nél halvány, mert itt nem lehet 40 sáv. Pedig milyen jó lenne a 80 sávos d71 formátum. A TC64 csak 35 sávos d64-eket kezel, simán nem lehetne a 35-40 sávokon lévő programokat betölteni, ehhez a TC64-ben DOS csere kéne pl. 40 sávos Speeddosra, a Jiffy is csak 35 sávos. Az S-Jiffy DOS 32 KB-os, kezel 40 sávot, de nem lehet 16 KB-nál nagyobb a TC64 1541 DOS file.
9199-re: Az RGBI régi CGA felbontás, elvileg régi CGA monitorokra közvetlenül rá lehet kötni, azoknál is dsub 9-es csati van. De kinek van 198x-ben gyártott működő CGA monitora?
Van RGBI-ről analóg RGB-re, meg erről más jelekre (talán kompozitra, svideora) konvertáló eszköz, de minden átalakítás minőségromlással jár, és pont a jó képminőség a szuper a VDC-ben 1084-gyel, sokkal jobb, mint a 40 sávos luma/chroma jel. Ezért sosem vettem, csináltam RGBI-ről valamire átalakítót. Így a jó natívan 1084-gyel.
Van VDC VGA mania, itt RGBI-VGA adapterrel jó csak a kép, amúgy 1084-gyel csak fut a nem 50 Hz miatt, kipróbáltam. https://csdb.dk/release/?id=121912
A VDC-nek igazából mindegy, hány MHz a rendszerbusz, mert saját, külön órajele van, a saját, külön frissítésű DRAM-jával teljesen elszeparált az alaplapon lévő többi eszköztől. Ezért is lehet átprogramozni PAL és NTSC (vagy bármi egyéb) közt szabadon.
Végül is a fő akadály, ami miatt nem népszerű, inkább az, hogy mai kijelzőkre nehéz csatlakozni vele, mert vagy speciális eszköz kell a színes RGB-I kimenetéhez, vagy lehet a kompozit jelét venni, de akkor csak monokróm. A VIC-kel és a TED-del persze nincsen ilyen gond.
Érdekesség: már a MEGA65-ben is van valamilyen szintű VDC chip emuláció (a GEOS-128 portolásához kellett nekik, ezért megcsinálták...), így elvileg ha valaki a 64-es módból kiindulva programozza, akkor talán ott is lehet futtatni az eredményt (kérdés persze, mennyi funkcióját, milyen szinten kezeli):
Ki tudja, még lehet, hogy a jövőben egy korlátozott (nyilván nem 100% kompatibilis, de legalább elérhető) C128 natív módot is valahogy belehekkelnek a C65 mellé? Nem lenne rossz szerintem.
> Meg van egy d71-es VDC képes demó, ez se megy TC64-gyel, mert csak d64-et kezel. Majd szétszedem 2 db d64-be, meglátom mi lesz, jókor kell váltani a 2 között hogy végigmenjen a load.
Ez szerintem nem fog menni, mert a D71-nél egyáltalán nem garantált, hogy egy fájl ugyanarra az oldalra kerül, simán lehet (sőt valószínű), hogy sávváltás-optimalizálás miatt felváltva vannak a két oldalon az adatok. Legalábbis így tud a leggyorsabb lenni.
Úgy tudom hogy a CP/M cartridge sima C64-ben is bizonytalanul működik valami időzítési gond miatt. Sosem volt ilyen cartridge-em, mindig C128-cal teszteltem. Arra emlékszem az eredeti C128 Z80 3-4 MHz-en ment volna, de vissza kellett lassítani valamiért, szerintem a VIC miatt, mert 1 MHz-es 8502-vel tud csak működni, gondolom a Z80-nal is ez van. Már a 2 MHz-es fast módnál sincs képe a VIC-nek, csak szemét van a képen. Érdekes hogy a VDC működik 2 MHz-en is, sőt a chip egyben PAL és NTSC is, míg a VIC-nél külön chip kell ehhez.
Tényleg sokkal többet ki lehetett volna hozni a VDC-ből. Tegnap meglett a 64 KB VDC RAM, kapott C64+128 mód Jiffyt, kipróbáltam TC64 C64-be dugva (Jiffys 1541) + serial kábellel egy halom VDC demót, működnek. Ez is. https://csdb.dk/release/?id=161195 Ez még a V1-esről készült videó:
Annyi hátránya van hogy a TC64-et nem lehet a C128-ba dugni, hogy a REU-s programok nem működnek így, pl. a Wheels 128, hiába van max. 16 MB 1764 a TC64-ben. Meg van egy d71-es VDC képes demó, ez se megy TC64-gyel, mert csak d64-et kezel. Majd szétszedem 2 db d64-be, meglátom mi lesz, jókor kell váltani a 2 között hogy végigmenjen a load.
Kár hogy még mindig nincs új gyártású modern, olcsó 16 MB-os SuperCPU C64 és 128 módhoz is, ezzel száguldott a gép, volt SCPU 128-am, eladtam, mert túl drága volt 2000+ €-ért, hogy nálam romoljon el, és aztán csak 200 €-t érjen. A DCR is régen elkelt, elég nekem most a sima C128, nem akarok újra 1571-et és 1581-et venni, drágák.
Az 1570 is érdekes történet, volt ilyenem is, 1571 DOS van benne, sosem készült külön 1570 DOS, ezért gyárilag alaplapi áramkör átvágásokkal és drótozással butították hozzá az egyoldalas 1541 mechanikát, hogy ne 2 oldalasan akarja kezelni. Vajon mi történne, ha kiadná valaki az U0-M1 parancsot, ami 2 oldalas módra váltást jelent? A DOS érti ezt. Az M0 az 1 oldalas mód.
A Z80 eleve a CP/M miatt került bele és csak azért, mert a marketing beígérte, hogy CP/M kompatibilis lesz a gép, de nem tudták megoldani, hogy a C64-es CP/M cartridge működjön. Ezért is van visszabutítva a Z80 a 8502 órajelére. (8502? most elbizonytalanodtam, de asszem az van benne)
Valahol részletesebben is leírták hogy milyen szuper lett volna az eredeti C128 rendszer, és hogyan, miért butították le annyira, mert először a C64 kompatibilitás se volt benne, de tanultak a Plus/4 bukásból, ezért belerakták a C64 módot rendesen.
Z80-nal miért csak a CP/M létezett? Egy halom más rendszert lehetett volna csinálni Z80-nal.
Annyira nem lehet lassú a VDC, ha a Risen from oblivion demót megcsinálták, pár órája néztem meg újra valódi géppel.
A VDC-t a C900 (csak prototípus állapotig jutott) UNIX workstationhöz tervezték eredetileg, ahol egy 10 MHz-es Zilog Z8001 (16-bites) proci mellett teljesített volna szolgálatot 1024x800 pixel monokróm grafikus felbontásban 128K videorammal és egy extra blitter kártyával is kiegészítve. Mivel ezt a projektet lelőtték (mert jött az Amiga, és arra koncentráltak inkább), a chipet végül is a C128-hoz használták fel lebutítva (kevesebb RAM-mal, blitter nélkül), miután épp készen lett addigra. Ide írtam róla egyszer, ha van kedved és érdekel a téma, olvasd el: http://rosetta.blog.hu/2016/04/11/commodore_900_vagy_z-machine
A regiszterkiosztás a Z80-szerű architektúra miatt lett olyan, amilyen (IN és OUT portok használatához lett tervezve).
A valóságban nem annyira lassú adatokat bevinni, mint ahogy az urban legend tartja. Általános másolóciklusokkal összemérve kicsit több, mint kétszer annyi idő, mint a normál memóriába, pl. lásd itt: normal vs. VDC/load = 17345 vs. 37367 gépi ciklus (1 kilobájt átvitele, átlagban): http://csdb.dk/release/?id=158763
De még ezen jelentősen lehet gyorsítani, mert pl. nem is muszáj minden bájtnál ellenőrizni a ready bitet, hanem elég csupán néhány bájtonként (ki lehet kísérletezni, hogy mennyi fér bele, sőt, ha van mellette REU, azzal akár nagyságrendi ugrást lehet elérni).
Aztán 2 MHz-en járatva a CPU-t, az átvitel is mindjárt duplájára gyorsul ugyebár.
SuperCPU-val 20 MHz-en kb. 6-7-szeresére gyorsul fel.
C128 VS Plus/4: a C128 nem volt bukás. 2 millió darabot eladtak belőle,kétszer annyit mint a jóval olcsóbb Plus/4-ből, és megjelenésekor jóval drágább volt, mint a C64. Sok C64-es választotta a C128-at, mint fejlesztés, de mikor kiderült, hogy annyira azért nem komoly gép, maradtak a jól bevált régi játékok futtatásánál. Magyarul amíg aktív volt a gép eladása, nem nagyon volt igény komolyabb játékokra. A 8502-re írt 128K-s felhasználói programok nem voltak rosszak, és a GEOS is elég jól futott a nagyobb memóriával és a nagyobb felbontáson. viszont a REU már akkor is drága volt, és a gép további belső bővítése nem volt olcsón megoldható.
A többség megmaradt a játékoknál.
Személyesen láttam a szegedi Vízműveknél az informatikusokat, akik épp a friss C128-akaon telepítették a bérszámfejtő és személyzeti nyilvántartó programokat. A C64 már kevés volt, volt numerikus billentyűzete, a processzor gyorsabb volt, a 80 karakteres kijelző igen hasznos volt. (bár BASIC-ben ÁLLÍTÓLAG a folyamatos RAM/ROM lapozás miatt a C128 lassabb volt mint a C64, és konkrétan lassabbak a rajzoló rutinok mint Plus/4-en (mivel VIC-II módban a CPU stabilan 1MHz-en megy, míg a Plus/4 a kereten 1.7MHz-el)
A C128 a teljes kompatibilitásával pontosan úgy járt a C64-el, mint a Plus/4 a C16-al: hogy több programot adhassanak el, ezért a limitáltabb, de több ember számára eladható termékeket gyártották le és adták ki. A C64-ből minimum 10x annyi volt, mint a C128-ból, a C16-ból minimum 2x annyi, mint Plus/4. Mindkettőnek az lett az eredménye, hogy a legtöbb ember által elérhető memóriamennyiségre fejleszettek, ez 64K volt a C64 esetén (mert a C128 úgyis elfuttatja) és 16K a C16 memóriája miatt (a Plus/4 úgyis elfuttatja)
C128-al kapcsolatban: rengeteg potenciál van a gépben, imádom a kinézetét a desktop masinának, az 1571 is csúcs (van is belőle egy), de vannak dolgok, amit igencsak elböktek benne. többek között emiatt nem lett sikeresebb gép, bár a profibb konkurrencia is igen erős volt már akkoriban (mindenki az Amigát várta...)
-A CP/M professzionális használata a Z80 processzor orbitális lassúsága miatt dőlt dugába. Ha jól tudom, a VIC-II és a szűk memória sávszélesség miatt kb 1MHz-en üzemelt (legjobb esetben 2). No ehhez tegyétek hozzá a szövegszerkesztőt és adabáziskezelőt, ezt az adatmennyiség kezelést egy kvázi 1MHz-en működő Z80-nak kellett kiszolgálnia, amit már a ZX Spectrum 48K is kiröhögne a 3.5MHz-ével, a CP/M-et futtató Amstrad CPC-k 128KB val és 4MHz-es CPU-val pláne. Konkrétan leírják, hogy bár a CP/M csak karakteres módban működött eleinte, olyan lassú volt a szövegszerkesztő (talán wordstar?) hogy oldalváltás esetén szó szerint látni lehetett ahogy egyesével kirakja a képernyőre a karaktereket a gép. (a CP/M vagy a multitasking SymbOS mint olyan engem is érdekelt volna Plus/4-en, 1571-el, és erre az eZ80-at szemeltem ki, ami egy gyors modern IC, a leggyorsabb megfelel egy 200MHz-es Z80-nak, van 100% teljesen Z80 kompatibilis módja, kissé hasonlít a SuperCPU agyához. Mivel nincs NMI vonal a 8501-en, ez a bővítés halott ötlet, ráadásul a scene sem támogatta, hogy a Plus/4 kvázi rabszolgasorban egy megjelenítő eszközzé degradálódjon).
VDC: a VDC-t olyannyira nem tervezték arra, hogy grafikát kezeljen, hogy eleinte nem is volt dokumentált ez a módja a CBM részéről, csak mint 80 karakteres kijelzőt reklámozták. (ekkor még csak 16K-s verzió volt belőle, ami 16 független szín mellett (4 bitplane) csak igen limitált 640x200 felbontást tett lehetővé. Hiába mondjátok,hogy a VDC ezt izomból megoldotta. Volt benne blitter, viszont baromi lassú volt a programozása. A 37 belső regisztert egy kontrollregiszteren keresztül lehetett felprogramozni, aminek a programozása tele volt várakozási ciklusokkal. Lassú... A VDC memóriáját ugyanazen keresztül lehetett feltölteni adatokkal, hasonló kommunikációs módon. Hát nem gyors... SZVSZ ez szerintem látszik is. Ha megnézek egy C64 GEOS vagy egy C128 GEOS futtatást, az ikonok lapozása során szerintem a C128 többet gondolkodik, dacára a több memóriának és kétszer gyorsabb processzornak. Ez szerintem csak amiatt lehet, mert az új ikonok képeinek az adatait lassú áttölteni a képernyőre. Vagy nézzétek meg a VDC Mania képernyőtöltését. Nem a kép olyan nagy méretű (hisz max 64KB lehet) hanem amíg ezt az adatmennyiséget átpumpálják a szűk keresztmetszeten.
Nem a VDC-t akarom ekézni, de ahogy a SID-nek volt annyi direkt elérésű programozható regisztere, a VDC-t is sokkal gyorsabbá tehették volna, ha a 37 regiszter direkt elérésű lett volna. De ilyen adatmennyiség áttöltését eredetileg nem tervezték bele, csak a 2KB-os karakteres képernyőnyit.
Az FLI valóban szinte teljesen megfogja a processzort, ebben játékot tutira nem ír senki (?), de azért amit ebből a Plus/4ből ki lehet sajtolni trükkökkel, az nem semmi. Nagyon kevés 8 bites gép volt erre képes akkoriban.
Amit szerintem kihagytak mint ziccert: ZX Spectrum emulátor. A Z80 adott volt, volt kellő memória is, a SID le tudta volna emulálni az AY-t (már ha hozzáfért a SID regiszterekhez a Z80)
Máskor is nézegettem már ilyesmi hosszú guide-eket. 700+ oldalt nem tudok átnézni. Csak az 501-től néztem most bele. Az 537. oldalon a VIC teszt bit az 53296 1-es bit, de az 1-es cím bitjeiről, a színtárról nem ír az 502. oldalon az 1-es címnél. Az 540. oldalon a szokásos 1-es cím bit kiosztás van, mert ez a C64-es kiosztás, semmi nincs a 2 színRAM kapcsolásról.
Nem értem hogy a C64-es profi trükk, demó, játék programozók legalább egy része miért nem tér át egy kicsit a C128-ra, és ír demót C128 módra, a VIC és VDC részre is, mint a Risen from oblivion készítői tették 2001-ben, csináltak VIC-re 60,1 Hz-es képet, stb., meg VDC demót is. Én is programozgattam már sokat, 20 MHz-es SuperCPU-t is, de messze vagyok ezektől, nem tudok csak ezért belemerülni a témába évekre, hogy pár trükköt írjak. A SuperCPU-ból se hoztak ki mindent azzal a nem sok demóval, amit találni. Az nem akadály hogy kevés embernek van valódi SCPU-ja, évek óta elérhető a VICE SCPU emus verziója. Pl. jól néz ki a felső kereten 4×40, az alsó kereten 6×40 karakter szöveg sima betűkkel, össz 35×40 karakter sprite-ok nélkül, csak a 16383-as címet programozva. Ezt felturbóztam sprite-okkal is, meg még az oldalkereteket is megnyitottam, így 4×50 és 6×50 karakter lett csak a kereteken. Néhány hét alatt csináltam tavaly egy 24 részes SCPU demót, ezek is benne voltak, a videót láthattátok tavaly.
Csak sokáig tart végigolvasni, és megtalálni benne mindent (meg a részleteket fejben összerakni persze). Én is ezt nézem meg, ha kell.
Lemon64-et szoktam követni, ott is évről évre mindig előhozza valaki a 128 témát, akkor mindenki pufog egy sort, ötletelnek, aztán megint nem történik semmi. :) Akik 64-en rutinosan fejlesztenek, nem akarnak kimozdulni már a komfortzónából.
Hol van a leírás a C128 1-es címről (színtár kapcsolás) és a többiről, ami más, mint C64-en? Az obsessionon nem találtam. Nem gondoltam hogy az osztott képernyős Graphics parancsnál különböző színtárat használ a nagy és kisfelbontáshoz.
Plus/4-nél is van Graphics parancsos osztott képernyős mód (a BASIC 3.5-től van ilyen), ahol a képernyő alsó 5-6 sorát raszterrel levágja a karakteres módhoz, felette nagyfelbontású mód van. Itt nincs 2 színtár?
Ott van a belső U36 (internal function ROM) és a külső megfelelője, szintén max. 32 KB méretben (external function ROM), csak C128 módban, mégse látok egy C128 módos cartridge-et se. Néhány éve módosítottam egy C64 cartridge-et külső 32 KB-os funkciós ROM-osra (a ROML-t és a ROMH-t egy 74LS08-val AND-oztam össze a 32 KB-hoz, itt 2×16 KB-ot kapcsol), a 8 féle belső U36-ból (Servant is, stb.) 3-4 működött így is.
A többinél gondolom az inic rutint, a ROM kiosztást kellett volna átírnom hogy működjön. Sőt olyat is lehet csinálni, hogy a Servantban a CALL EXROM menüt aktiválni, ilyenkor a külső cartridge funkciós ROM-ot hívja meg, akár az 1750 REU-ban lévő 28 lábú foglalatba rakott ROM is működik így, kipróbáltam annó. De lehetne simán külső cartridge-ben is kapcsolgatni a 32 KB-os ROM-okat.
Ha ennyi mindent tud a C128, amit a C64 nem (meg amiket én írtam az előzőben), meg ott a sok VDC trükk is a Risen from oblivion demóval, meg az obsession oldalon a sok trükk leírása 2007 óta, akkor miért nem használta ki senki 1985 óta? A C128DCR-ben eleve 64 KB VDC RAM és 8580 SID van, 1987-ben jött ki ez a gép. Miért bukott meg a C128, mint a Plus/4-es, ha ennyi mindent tud?
Úgy látszik télen a C128 40 és 80 oszlopos trükkökkel és a Plus/4 színekkel fogok kísérletezni. Gyorsan 64 KB-ra bővítem a VDC RAM-ot, 4416 chipek ki, 4464-ek be, kész. Van 1084-em RGBI bemenettel, kábellel.
Fel kéne hívni a demóírók figyelmét, hogy a C128 dolgokkal is foglalkozzanak. Még ma is sok embernek van ilyen gépe. Ebayen ki lehet fogni működőt táppal 100 € alatt.
Még mindig nem találtam olyan Plus/4 demót, ahol 20-30 színnél többet használtak volna EGYSZERRE a képernyőn. Valaki tud 50-121 színes demót? Van 231 színes trükk is, már írtam itt erről.
A színtárak az 1-es címen kapcsolgathatók (ahol a 64-es üzemmódban a Kernal és a Basic ROM). A két legalsó bit választ ki a CPU és VIC számára egymástól függetlenül egyet-egyet, azaz akár megoldható, hogy a képernyőn az egyik látszik, miközben te írod-olvasod a másikat, majd megcseréled őket (double buffering). Az oprendszere amúgy arra használja fel őket alapesetben, hogy az egyiket a szöveges, a másikat a grafikus képernyőhöz rendeli (pl. osztott képernyőnél praktikus a GRAPHIC paranccsal).
A test bit trükkös: ha beállítod, akkor "elszáll a kép", mert felpörgeti a raszterszámlálót (elkezd nagyon gyorsan nőni, végül megáll nullánál). Ha csak kis időre kapcsolod be, átveri a képernyőfrissítést, és ha jókor/rosszkor kerülsz vissza belőle, a 16 szín árnyalata megváltozik például, mert kiesik a szinkronból (csak CRT-n). Interlace-re itt egy leírás:
És még annyi mindent tud a C128-ban az MMU is (pl. a nulláslap és a verem is átcímezhető, akár másik bankba stb.), rengeteg lehetőség hever parlagon, a programfejlesztők meg lusták voltak kiaknázni évtizedekig.
van (a VIC is mind a kettőt látja, azaz tehetsz grafikát a másodikba is). A CPU-ból ki lehet még nyomni
Hogyan lehet a 8566-os VIC test bitet interlace-re használni?
A C128-ban hogyan használsz 2 színtárat? A gépben egy 2 KB×8 bites SRAM (mint az 1541, 1571-ben) van a C64-es 1 KB×4 bites helyett, ez mindig 55296-on van C64 és 128 módban is, nem lehet áthelyezni. Hogyan használod ki a másik 1 KB-ot színRAM-nak?
Komolyan keresek a C128 felső 64 KB-ját használó programokat, mert ott áll kihasználatlanul, jó lenne valami értelmesre használni. Ha ennyire jól használható lenne a felső 64 KB C128 módban, grafikára is, akkor miért nem írt még senki semmi értelmes demót, vagy csinált akár 4-8 képből és több színtárból álló interlace szuper képet, ami ezt kihasználja? Még sima bármilyen programot se találtam, ami bármire használná a felső 64 KB-ot. A sima C128 BASIC 7.0 is csak változóknak, tömböknek, stb. tudja használni a felső 64 KB-ot, BASIC program nem lehet ott.
Meg ott van a 16, vagy 64 KB-os VDC RAM, ebbe is lehet adatot rakni 40 oszlopos módban, és gyorsan átmásolni a sima RAM-ba. A Servant U36 bővítésben van 1 menetes 1541 lemezmásoló, a 171 KB adatot a 128 KB rendszer RAM-ba és a 64 KB-os VDC RAM-ba rakja. Nem tudok mást, ami használná ezt így. 64 KB VDC RAM-mal már 3×64=192 KB RAM van, nem mindegy. Vagy 64 KB VDC RAM-mal (80 oszlopos mód + fast 2 MHz mód) rendesen kihasználni a 128 KB rendszer RAM-ot, a felső 64 KB-ot is, ilyen programot se találtam.
Akár olyan 40 oszlopos demót is lehet írni, ami saját gyorstöltővel betölt egy egész 1541 lemezoldalt a 192 KB-ba, és onnan használja. Amigánál is vannak olyan sok grafikás demók, amik akár 50 MB fastRAM-ot is igényelnek, előre betöltenek, kicsomagolnak, kiszámolnak sokmindent a fastRAM-ba, ha kész, csak akkor indul a demó, és közben nincs load, már csak a fastRAM-ból kell másolgatni a chipRAM-ba. Mondjuk ezekhez 68060 66+ MHz kell, de ez most nem érdekes.
Továbbá a C128-ban lévő VIC-IIe is több potenciált tartalmaz a C64-eséhez képest eleve, hisz két colour RAM közt válthatsz (ugye 64-esen egy komoly korlát, hogy ez fix) és két 64K-s memóriabankod van (a VIC is mind a kettőt látja, azaz tehetsz grafikát a másodikba is). A CPU-ból ki lehet még nyomni +30%-ot sebességben, valamint a VIC-IIe "test bit" révén elérhető némi interlace vagy színmódosításos trükk.
Annyival még árnyaljuk a képet, hogy míg C64-en és Plus/4-en az ilyen technikák agyonterhelik a CPU-t és/vagy felélik a memória nagy részét a gépben, addig a C128/VDC esetén a VDC chip hardverből nyomja az interlace-t és a dedikált videomemória elérése is a CPU-tól független (akár belső adatmozgatásra képes), így mind a proci, mind a rendes memória tökéletesen tehermentesítve van (sőt, kikapcsolt VIC mellett még badline sincs, a proci full 2 MHz-re átkapcsolható).
Ha egy-egy állóképen való meditálás helyett valamilyen konkrét célra használná az ember, rengeteget számít ez a különbség. (Pl. a GEOS-128 még a 640x200-as felbontásban futtatva is sokkal gyorsabb, gördülékenyebb, mint a 64-es verzióval való kínlódás.)
A VDC Challenge csak 320x200 felbontású HFLI (nem váltott-soros) képeket használ, tehát egy kép, viszont az FLI trükk miatt minden második sorban új színpaletta van a karakteren belül.
Én a 320x200-as (H) felbontást preferálom a normál FLI helyett, mivel sokkal részletgazdagabb a kép 320x200-on, mint 160x200-on (viszont kevesebb színt használhatok egy karakterhelyen belül)
A I-s Interlace-es képeknél új színek alakulnak ki, mivel a két kép nem egyforma, és a szem tehetetlensége miatt kiátlagolja az egymás mögött levő gyors ütemben váltott pixeleket.
Larry elsősorban a kontrasztra és a színek egymáshoz képest észlelhető fényességére helyezi a hangsúlyt (mivel kétszer több érzékelő van ebből a szemünkben), míg én inkább a színekkel operálok. (az én elméletem az,hogy a több színnel finomabb átmeneteket és természethűbb képeket lehet csinálni, ehhez viszont a jobbik felbontás dukál - ez a VDC-nél jön ki leginkább, aminek hiába van remek felbntása, a 16 szín hazavágja. Érdemes megnézni az EGA képeket is, hasonló teljesítményre képes a C128 VDC is, csak itt még a teljes paletta is 16 szín, nem 64 mint az EGA-nál)
Mindemellett megjegyzendő, hogy az összes Plus/4 FLI módot ki kell "hivatalosan" egészíteni egy D betűvel, mivel szemben a C64-el, itt csak minden második sorban lehet palettát váltani.
Ennek az ok az, hogy a szín+fényerő külön állítása és memóriába másolgatása nem fér bele egy raszteridőbe.
Theát a C64 FLI, a Plus/4 DFLI
A C64 ebből a szempontból jobb, ilyet viszont nem nagyon lehet összehozni rajta:
Az igazsághoz hozzátartozik, hogy a szürkeárnyalatos képeknél a C64 és a Plus/4 között nincs akkora különbség.
A C64 5 szürke árnyalattal rendelkezik (fekete és fehérrel együtt, a Plus/4 9-el, viszont a fehér nem olyan szép fehér mint a C64-é, inkább csak nagyon világosszürke.
A konvertált kép hány darab kép? Egy, vagy a "villogásból" összeadott képek összege!? Nem ismerem az eljárást és nem is értem minek képet váltani. Ha egy kép is közel olyan "megjelenésű", mint az eredeti verzió. Köszi
Az Amiga VS Plus/4 HFLI összevetést nem érzem annyira merésznek.
Az IHFLI váltott kép segítségével újabb színek jönnek létre virtuálisan, a szem tehetetlenségénél fogva. (Larry slideshow-i erre épülnek, meg a luminance over chrominance elvre) A C64 esetén ez pár tucat új színt eredményez, Plus/4 esetén több ezer képződik.
Egy kicsit túltoltam a ditheringet, de azért nem rossz egy "referencia" Amiga HAM6 kép Plus/4 konverziójáról
A C64 és C128 (még VDC magas felbontásaival együtt is) csak limitáltan képes fotókhoz hasonló képeket generálni. Egyszerűen nincs kellő mennyiségű szín az átmenetek leképzéséhez, furcsa "szürreális" palettákat kell használniuk még a legnagyszerűbb képekhez is (a C64 grafikusok képességeivel kapcsolatban nincsenek kérdőjeleim, néha eszméletelen minőségű képeket tesznek le az asztalra, akár HIRES vagy MC formátumban - vajon mire lennének képesek Plus/4-en?)
Tegnapról lemaradt (pontosanbbban eltűnt a hozzászólásom, mikor egy képet akartam becsatolni):
egyébként ha meg demoról van szó, a színkezelésben a Promised Land nagyon király. Bár korábban is gyártottak nagyon szép plazmákat plusz/4-re, de ennek a palettái fantasztikusak.
Szerintem 11:00-tól és 16:30-tól kezdődő részeknél kezdenek igazán bámulatosak lenni az effektek, de az előtte levő gömb, toroid és háromszögek is baromi jók. Remekül passzol az igen egyedi zenéhez, amit akár meg is hallgathatsz itt: https://www.youtube.com/watch?v=NmDLh3MmooY
Az SJIFFY ugyanarról az NLQ.de oldalról érhető el, aki az általam nagyon sztárolt IEC2IEEE Atmel interface-t tervezte. (Jochen Adler)
Elvileg a IEC2IEEE cucc Jiffy kompatibilis, és akkor Jiffy sebességgel tudná az IEC-re akasztott SFD-1001-et kezelni (C= 1MB/lemez, egy komplett C64 Pool of Radiance játék elfér egyetlen lemezen. Lenyűgöző!), de sajnos az én adapterem nem akarja a sebességet, mindig lefagyott. (egy hasonló PET-es cuccnál írták, hogy a Jiffy-hez 16MHz-es verzió kell, ez meg csak 8MHz körül mozog, és így elveszíti a szinkront az egyik gyorsan adagolt vezérlőjellel)
Ráadásul az Arokra szállítás közben gallyra ment az SFD-1001-em is. :-(
Úgyhogy maradt 1db amerikai MSD SD-1 floppy-m 1541 kapacitással, de IEEE csatival (és 1541 sebességgel).
Ha a fenti IEC2IEEE adapter tudná a Jiffy sebességet, akkor ezek a brutál IEEE eszközök sima IEC parancsokkal üzemeltethetőek, és szinte "végtelen" a kapacitásuk és még gyors is lenne. elvileg az IEEE egységek még annál is gyorsabban tudnak dolgozni, mint amit az IEEE-488 engedélyezett a számukra.
Nekem örök kedvencem a"porsche dizájnos" C= 8250LP dual floppy drive, gyönyörű. (bár tudom nem sok köze volt a Porsche-hez) De 100ezer forintot sajnálnék rá, pláne ha még lassú is. Valami ilyesmi kellett volna a Plus/4-hez az 1551 helyett az IEC kompatibilis 1541 mellé, ha már mellécsapták azt a bazi nagy adaptert, lehetett volna IEEE-488 (jah, meg a Sound Expander :-) )
Huh, annyi külön post lett hirtelen... Inkább témánkét írok, mert már így is túl sok a szám az életemben :-)
TED zene VS SID: a TED gyengébb. pont. A HVSC csak a C64 SID-ekkel foglalkozik a HVTC meg csak TED-en futóakkal. A Plus/4 SID zenék általában valahonnan "lettek", általában van szerzőjük is, csak nincs jelölve ("music is ripped from C64"). A Promised Land abból a szempontból különleges, hogy Plus/4 platformhoz írták a SID zenéit, a CSDB viszont "C64-náci" (ahogy ezt egy lengyel kontaktom írta), tehát semmit nem raknak fel, ami nem fut direktben C64/C128-on, nem írható be ilyen demo/projekt. Tehát a Promised Land-ben használ Celtic Design zenéi a szürke zóna, legjobb esetben bekerülhet a HVSC-ba, CSDB-n nem túl esélyes.
A hardverekről annyit, hogy a fekete házas (!!!) Sound Expandert is a Plus/4-hez kellett volna kihoznia a Commodore-na (Yamaha IC-vel), nem a C64re, mert abban már volt SID. Nem is értette senki a lényegét, hogy ez most minek??? Ugyanígy a fekete házas (!!!) IEEE-488 cartridge, amiből egy sem készült Plus/4-re, és van egy halom C64-re. Rá lehetett volna kötni a brutál PET háttértárakat. 1985-ben hozták ki! https://www.c64-wiki.com/wiki/Commodore_Sound_Expander
Memóriabővítők:
Mivel van egy C64 RAMLINK-m 16MB gyors háttértárral, D64, D71 és D81 emulációval, saját Jiffy-vel, tehát nagyjából tudom miről maradt le annó Plus/4 társadalom. (bár RAM bővítőm nincs) Egyébként ehhez bármilyen külső erősebb 9V táp megfelel, tehát nem kell egy erősebbet 2-3A-es C64 specifikus tápot hajszolni, mint pl REU esetén, mert lehal a gép és a táp. Ennél nem. Ráadásul ráakasztható egy külső akkumulátor, amivel megtartja a beállításait és a 16MB-ba töltött programokat. Nagyon kafa. Nem használom, mert rengeteg helyet foglal mire összerakom az egész cuccot.
Addig őrizgetem, míg nem ér majd legalább negyed misit :-)
Én a Lotharek-től mostanában kapom meg a 256K Hannes belső RAM bővítővel ellátott 6502 modulomat (sajna nem volt lelkierőm kivárni a többi ígéretes fejlesztést). Ennél nagyobb memóriát semmi nem kezel Plus/4-en (játék csak kettő, pár utility), a GEOS meg a többi még ennyit sem, mert nincs rá felkészítve. De szerintem felesleges is ennél nagyobb egy ilyen képességű géphez. Remélem a 2A-es tápom elbírja, de ennek érdekében épp most szerzek be modern EPROM és PLA készletet, ami kb 0,2 -0,3 A-el csökkenti a gép áramfelvételét (és a képződő hőt)
Plus/4 gyűjtemény:
Most jutott eszembe, hogy kettőt is kaptam. Az egyik a SD/1541-II-höz járt , és alig volt benne valami C16-os.
A másikat az 1541/II-mbe integrált microIC-hez kaptam, az jó bő volt eredetileg is, elkezdtem létrehozni a Toplista alapján a saját gyűjteményemet (külön könyvtár a konvertált, Top40, stb), de de csak félkész, mert elég kevés a munka+család kombó mellett időm.
Most 1150 állomány van benne (PRG és D64 vegyesen), 28MB. Szívesen megosztom, ha ez segít.
Csak hová lehet az ilyet feltölteni? Az IMGUR-t használom általában, de az képekre jó.
Mi használja ki a színeket?
erről eszembe jut a 8 Shades of Black demogyűjtemény, amiben van egy rész, amit Mermaid jegyez. a lenti videóban 1:16 "Lone Fly"
Egy madár repül, alatta házak, parallax scroll, sok szín, raszter háttér és ég, baromi jól néz ki. Kár hogy csak demo maradt, 2007-es.
Szerintem ez az egyik legszebb nem konvertált "majdnem játék" a gépen. Egy Agony jellegű lövöldözős játékot simán ki lehetett volna belőle hozni, persze hogy miképp mozogna a madár valódi háttér előtt (color clash?) szoftver sprite emuláció és színkezelés kérdése. Jah, és a zenéje is eléggé rendben van, mert igen sok effekt le van kezelve benne, sajna nem tudom kinek a műve. https://www.youtube.com/watch?v=WMUVaY6SigU
Kár hogy a 9170-nel és a 9174-gyel nem akartok foglalkozni.
Hogyan lehet megtalálni a Plus4-es SID zenéket? A Promisedét se találom, nincs meg a zene neve és a linkje, csak hogy Celtic design. Itt nincs semmi. http://plus4world.powweb.com/members/celticdesign
Itt meg nincs meg a Promised land, mert a CSDB-n nincsenek Plus/4-es programok.
Sokkal jobban megéri egy Meanwell RS-15-5-öt használni, ami 5VDC 3A-es. Vagy RS-25-5-öt, ami 5A-es (jobb a Ft/Amper arány), ezzel lehet C64+1541-II tápot is csinálni egyben. 2800, 3e, 3700-ért vannak a nagy boltban.
Csak annyi megjegyzésem lenne, hogy a Promised Land lemezoldal váltásnál nincs space figyelés, a Bitfire (ez itt a reklám helye) érzékeli, hogy illesztésre került a B oldal, és automatikusan elkezd tölteni. Ha minden jól le van emulálva, akkor megy miden kombón. :) Annyit még, hogy mikor az insert disk grafika teljesen kirakódik, egy picit még utántölt, mert volt egy kis hely az A oldalon, így a kövi part kis szelete még bejön. :) Így közel 0 hely maradt az A oldalon. :D Szóval elképzelhető, hogy ha túl hamar kapja ki a lemezt a polgár, akkor megáll a demó. Lámpát kell figyelni, vagy el kell számolni kettőig.
A zenéről annyit, hogy le a kalappal azelőtt a néhány megmaradt TED zenész előtt, aki értelmezhető ZENÉT tud kicsikarni a TED-ből, pl. Csabó, Luca, Degauss, de nálam tudatos választás volt a SID zene, és tudatos választás volt a zenész (celticdesign), kb. 3 hetes intenzív kutatómunka és válogatás után.
