Ismételgesd csak a hülyeségedet. Már mondtam, de ezek szerint nem fogod fel, Plus/4-es topikban nem szidjuk a Plus/4-et. Nyiss egy új topikot ezen a néven: 'Plus/4 szidó topik', na itt folyamatosan szidhatod.
Hát én arra gondoltam, hogy valamilyen külső ROM-os megoldást lehetne csinálni. A 'Retro számítógép és videojáték klub' facebook csoportban az egyik itteni fórumtárs hírdet egy ilyet: C16 Plus/4 cartridge 128kb-tól 1MB-ig. Van egy-két donor Plus4-em meg C16-om, hogy az egyikből kivenni egy expansion portot és erre a nyáklapra pluszba rárakni, amin rajta lenne a külső ROM, lehetne rárakni a SID kártyát. nem tudom érthető voltam e :-)
Max. úgy, ha a ROM-ot a 3-plus-1 helyére teszed. Expansion port bővítő plus/4-hez nincs. Annak idején jó ötletnek tűnhetett az 1,98mm-es pitch távolság az expansion portra, de már nagyon régóta beszerezhetetlen. Anélkül meg külső ROM-ot és SID-kártyát is együtt használni necces. Esetleg egy prosztó programot tenni az SD kártya elejére, ami KEY parancsokat futtat induláskor és minden reset után rányomsz a shift+stop-ra :D.
A következőt szeretném Plus4-en, ezt mind egyszerre egy gépen: - SID kártya - JiffyDOS - SD2IEC / RPi1541 (természetesen külső) - F valamilyen billentyűkre ezek a szövegek íródjanak ki: - Fx billentyű: OPEN1,8,15,"CD/KONYVTARNEV/":CLOSE1 (belépés egy könyvtárba/D64 image-be) - Fx billenytű: OPEN1,8,15,"CD:←":CLOSE1 (kilépés egy könyvtárból/D64 imageből) - Fx billenytű: LOAD"//:DEFAULT.PRG",8 (olyan programot töltsön be egy gombnyomással aminek DEFAULT.PRG a neve a gyökérben)
Ezeket mind össze lehetne hozni valamilyen ROM-al?
"1 menetes lemezmásolás RAM bővítő nélkül csak a 64 KB-os VDC RAM felhasználásával, lásd a Servantot."
Ezt teszteltem, tényleg működik. A 128 KB-os rendszer RAM-ot és a 64 KB-os VDC RAM-ot együtt használja. Csak így lehetséges ez, mert egy 35 sávos teljes 1541 lemezoldal 171 KB-os.
Lenne egy fájl kicsomagolós problémám! Van a Multi Botticelli rajzprogram és ennek is a crack-elt kicsomagolós(tömörített) verziója. Eddig ez az egyetlen program, amit nem sikerült cartridge-ről elindítanom. Szépen felmásolódik a ramba, és el is indul, de a crack bemutató utáni kicsomagolás az teljes fagyásba viszi a gépet. Yape-ban is teszteltem és ott sem akarja. Ha Yape-ba betöltöm, akkor megyen rendesen, ha cartrige-ről másolom ramba és utána csinálok egy PRG betöltést is, ami elviekben beállítja a szükséges vektorokat, mert beállítja, akkor is meghal a program indítása. Ez mitől lehetséges? Minden megoldás érdekel! :-)
"Disk copier*. Copy whole disk or only the tracks which are used (marked as used in the BAM). Single or dual drive copy. Automatically detects if the disk is single or double sided. With 64K VDC memory (but without a REU), it will copy a whole single sided disk in one pass."
De, ilyenekkel nyugodtan OFF-old szét a topikot, szvsz sok mindenkit érdekel!
Egyébként van-e lehetőség arra, a 64kByte-os VDC-t használva, egymenetes teljes lemezoldal másolót csinálni C-128-ra?
Gondolom valahogy lehet detektálni, h a VDC fel van-e bővítve, vagy sem.
És milyen jól jön a Bank 2 - vagy 1 -, és a VDC, mert az +128kByte RAM, plusz ugye 45-50kByte marad az "alap" memóriában is, így van-e bármilyen akadálya egy egymenetes teljes lemezes másolónak?
Látni a neten többféle RGBI-analóg átalakítót kompozitra, svideora, de csilliókért vannak, 50+ €. Analóg RGB-re könnyű átalakítani, csak 1 halom ellenállás és dióda kell hozzá. Van fekete-fehér kompozit kimenete is, olyan, mint az Amiga 500 MONO kimenete, de ez nem sokat ér. 1084-gyel nem gond az RGBI.
Nem értek egyet, a C64-nek is jó a billzete, és ehhez is lehet új tápot venni, vagy csinálni.
Vettem pár éve 2 sima műanyagházas C128D-t, mindkettőnek a tápja volt rossz. 1987-es elavult fosok. A DCR-nek jobb a tápja, 1988-as, de ezek is romlanak el. Felesleges a 2,5-szer nagyobb áramfelvételű C128D-t használni C64 módhoz. Csak a C128 alaplap 2A-t vesz fel 5V-on, a C64 0,7A-t.
Csak látnám már végre azt a demót, ami 512 KB-os 1750 REU-val DMA-zik a 64 KB-os VDC RAM-ba.
Az 1750 DMA-jával készült pár C64 demó pár éve egy versenyre, több REU demó nem nagyon van.
A VDC-re csak a Risen from oblivion VDC részét láttam, mást nem találtam, ami jó lenne.
Simán lehetne a 128 apró extráit is kihasználni 64-es módban (opcionálisan egy 64-es programhoz). Az egyik legismertebb ilyen dolog, ha a 2 MHz-es módot ki-be kapcsolgatod a képernyő tetején és alján, akkor kb. 30%-nyi CPU-nyereséget lehet vele elérni. Pl. az Elite használja (hogy gyorsítsa a rajzolást).
Ami alapjában véve könnyű, miután a legtöbb program eleve egy rasztermegszakítást alkalmaz, csak azt kellene néhány extra utasítással még kibővíteni. Van egy konkrét helyzet, amihez ez direkt jól jönne: a PAL->NTSC konverzió esete. Ott ugye az NTSC esetében kevesebb a frame-enkénti szabad prociidő (ráadásul drasztikusan kevesebb a kereteken kívül töltött rész), ami ezzel kiválóan kompenzálható. Egyszerűen lehetne egy program "NTSC-fixed" (legalábbis 128-tulajoknak, 64-es módban futtatva). Hm, és mégsem használják...
Nemrég jött ki a Sam's Journey, egy remek példa, mivel ő is trükköt használ, csak egy másikat: az NTSC-konverzióhoz a REU jelenlétét igényli a program (CPU-gyorsítóként használja a DMA-t). Ez se rossz ötlet, de akad vele probléma, mivel aki cartridge-en venné meg a játékot, az nem tudja a cartridge-et a REU-val a gépbe dugni egyszerre (vagyis kell mellé egy port replikátor is, vagy marad a lemezes verzió).
Sokkal egyszerűbb és elegánsabb lett volna a fast mód segítségét használni (ráadásul nagyobb célközönséget is fedett volna le, hisz 128-tulaj több van, mint amennyi REU-tulaj valószínűleg).
És mégsem gondoltak rá... Ezt nem értem ilyenkor.
(Jól van most már, nem offolom ezt a Plus/4-topikot tovább... ;-))
A VDC-ről sokáig azt gondolta mindenki, hogy használhatatlan, mert azon a kis két bájtos adat/port regiszterpáron kell átküldeni neki egyesével minden adatot a memóriába. De azóta kitaláltak már egy csomó trükköt, amivel drasztikusan felgyorsítható, pl. a megfelelő időzítés mellett 7-8 bájtot átcsúsztatni egyszerre, vagy a REU DMA-val akár több száz bájtot (ami tényleg villámgyors).
De a legszebb, ha a 64K VRAM-ba már minden belefér, és utána a belső block copy-val kell csak mozgatni.
Igen, az RGBI monitorkimenet az némi probléma, de szerencsére egyre többféle megoldást találnak ki modern tévékhez és monitorokhoz (a legvégső esetre egy monokróm összegző jele is még van az egyik tűn, az sima kompozit, csak egyszínű).
"Még azt nem értem, hogy miért veszik még mindig a C128-akat, C128D-ket? Mire használják az alapgépeket? C64 módban minek? Akkor vegyenek C64-et. C128-ra nincsenek új programok."
Szerintem még 64-es módban is egy jobb gép, mert jobb minőségű a tápegysége és a billentyűzete (én pl. szívesebben használom).
"A REU csak 1 MHz módban működik, 2 MHz módban nem."
Programozástechnikailag ez nem olyan nagy akadály, csak ki kell kapcsolni a fast módot, amikor épp DMA-zol, majd vissza.
Bármikor csinálhatok itthon bármit, amit csak akarok a C64-emmel, vagy az A1200-ammal. Itt a TC64, meg a turbókártya A1200-ra CF-fel. Ha akarom, minden nap partizok itthon. Miért mennék bárhová? Hány Árok partira járónak van TC64-e? 1-2-nek? Hány oda járó használja minden nap a C64-ét, vagy az Amigáját? Senki. A Vicious SID 2-ben jobb zenék vannak, Greets, Blood money, stb.. Itt az 1084-em a C64-hez, az 1084S-em az Amigához. Mindkettő fixen 1-1 külön asztalon, csak be kell kapcsolni, rákötve a hang erősítőre.
Voltam annó egy Árok partin. Láttam mi megy ott. Mindenki vedel, a fele ember dohányzik, alig érdekelt valakit hogy milyen demók, stb. mennek, ittak, beszélgettek, stb.. Okádtak össze mindent. Aztán pár évvel később olvasom az amigahu oldalán, hogy az akkori Árok partin valaki az egyik helyiségben a sarokba szart. Ezek a dolgok nekem nem hiányoznak. Itthon elvagyok egyedül, senki nem dohányzik az orrom alá, nem zajonganak, azt csinálok, amit akarok. Pár hete az amigahu és az aproamiga oldalakon Bitcoin bányászás folyik, jelezte a tűzfalam, ki se nyitom az oldalt. Vicc az egész.
Pedig bármennyire is hihetetlen, a fejlődés nem áll meg, csak nagyon lelassul.
Ott van például a Vicious SID első része, a Halleluja-s "effekt" - CRT TV-sek előnyben.
Sőt, ebben van a 8(?) bites digi lejátszás is, ami, tekintve, h 16 fokozatban lehet állítani a hangerőt, igen csak érdekes ötlet volt.
Aztán ott van a Plus/-es demo, Lavina Of Gotu említette a gyors töltős megoldást. Na ugye, h vannak még ötletek és vannak olyan "őrültek", akik leprogramozzák! Éljen!
Nélkülük nem lenne 8 bites demoscene, talán Árok Party sem, ahol évente egyszer lehet találkozni a hasonló érdeklődésű emberekkel és nagyon is jól tudja magát érezni az, aki nem játssza az eszét.
(Mekkora móka volt tavaly, amikor az A1200-n, amiben CF-en - vagy vinyón? - pl a DOC CD32-es verzióját végig vittem és vagy 8-10-n, egy emberként szurkoltak a lányszöktetésnél, a kardozásnál. Áh, kár bármit is mondanom, az érzés leírhatatlan, minden másra ott a magány.)
Egyetértek. Még azt nem értem, hogy miért veszik még mindig a C128-akat, C128D-ket? Mire használják az alapgépeket? C64 módban minek? Akkor vegyenek C64-et. C128-ra nincsenek új programok.
C128 módra nehéz turbót fejleszteni, mert a C128 bővítőport időzítései nem teljesen olyanok, mint a C64-nél, messzebb van a chipektől. Ezért nem működik sokszor az IDE64 C128-cal, pedig C64 módos a kártya. A RAMLinknél megoldották ezt.
A legtöbb embernek nincs 80 oszlopos monitorja, és a sima C128-ban meg a műanyag D-ben csak 16 KB-os a VDC RAM. Külön kell kártya bővíteni 64 KB-ra, többféle is volt, hol kapni, hol nem. Persze simán kicserélhető a 2 4416 RAM chip 2 4464-re, de a legtöbben nem fognak forrasztgatni. Az 1750 512 KB-os REU nem drága még ma sem, 50-70 €, ebből is sokat gyártottak, szinte mindig van ebayen, vagy 1764. A REU csak 1 MHz módban működik, 2 MHz módban nem.
Én azt nem értettem meg soha, hogy a C128-at miért hanyagolják el még mindig annyira. Ma is nagyon sok van belőlük pedig (hiszen "csak" a C64 utáni második legnagyobb tömegben gyártott mikrogép), sokkal több, mint például a Plus/4-ből, és nem nehéz a géphez hozzájutni sem.
Még a turbókártyákkal kapcsolatos ellenérzés megérthető valamennyire, mivel sokak szemében az nem "genuine hardware" (mint ahogy az SD-kártya sem az stb.).
A C128 viszont abszolúte az, és a REU is, ami nemcsak pluszmemória, de DMA-kontroller is egyben (és részben pont a C128-hoz tervezte a Commodore még anno, ld. Basic-ben is vannak gyári parancsok a kezelésére).
A VDC chip 64K RAM-mal remek felbontásra képes, és némi trükközéssel lehetséges villámgyorsan adatokat bele-DMA-zni a REU-val, sőt, még némi saját, kissé korlátozott blitter-szerű belső block copy funkciót is tartalmaz (mely a CPU-val párhuzamos módon működik). Közben ott a 2 MHz fast mode is a háttérben. Senki sem mondhatja, hogy elfogytak a lehetőségek... ;-)
Nem sok újat tudnak mostanában felmutatni a C64, Plus4 demókban, a régebbi dolgokat variálják sokféleképpen. Világszerte csak kb. pár 1000 olyan retrós van, aki tényleg minden héten foglalkozik a C64-ével. Ők a keménymag, a programozók, grafikusok, zeneírók, stb., ők csinálják a játékokat, demókat. Ennyi ember egy része (min. pár 100) vehetett volna már évekkel ezelőtt TC64-et, és már évek óta lehetne versenyezni, hogy melyikük mit tud kihozni a kb. 15 MHz-ből, a 16 MB-ból, és a beépített 1541-ből. Már régen erről kéne szólnia a demóknak, stb.. haladni kell a korral, nem úgy csinálni, mintha még mindig 1988 lenne, ahol csak alap C64+1541 van.
Mégis sokkal több stock C64 demó születik még 2018-ban is, mint turbózott C64 -es demó ;-)
Ez a szépsége, ez van, ezen nőttek fel, akik még ma is művelik. C+4-re is volt expanded ram demo anno is, de sok értelme nem volt, mert nagyon kevés embernek volt ilyen hw.
Aki tovább akart lépni, az a 90-es évek elején/közepén megtette, amigára, majd PC-re. Aztán egyre többen visszatértek 8bitre, mert PC-n a gigahertzek és terrabyteok világában nem nagyon értelmezhető már a klasszikus demoscene, csak ott is limitációkkal (256byte, 4k, 64k)... Akkor meg már inkább 8bit. :)
Mostanra már kihasználtak mindent, amit ki lehet facsarni a 6510/8500-ból, a VIC-ből, a SID-ből, CIA-ból, és a 64 KB RAM-ból. Láttam sok demót, az összes keret eltüntetését, oldalt is, nem csak lent-fent, sok effektet, digizenéket, demós gyorstöltőket, több 10 KB-os programokat, stb.. 20+ éve sok ilyen demót megvizsgáltam, és írtam át, kísérleteztem, hogy hogyan működik, mert semmiről sem volt semmi infóm, nem volt internet.
Illene már továbblépni pl. a TC64 (Turbo chameleon) felé. Pár éve lehetett kapni, és még fogják gyártani.
Amúgy is miért erőltetnénk tovább az 1 MHz-et, meg a 64 KB-ot, ha van 14-16 MHz, és 16 MB 1764-féle REU?
Ha az alapgépből ennyi mindent ki lehetett hozni, akkor a TC64-gyel mennyivel többet ki lehetne? A VIC, stb. ugyanaz maradt. Attól még C64 lesz, hogy TC64 van beledugva.
Vagy nekem kell megírnom a TC64-es dolgokat? Van TC64-em.
Ha ennyire gyors kód kell, akkor lehetett venni 4 és 8 MHz-es CPU kártyákat, Flash8, stb.. Nem muszáj az eredeti hardvert erőltetni. Ott van régóta a Turbo chameleon 64, mégse látok 1 demót, stb.-t se írva, ami kihasználná a kb. 14-16 MHz-et. Pedig több 100-at eladtak ebből.
Pont ezzel tapintottál a lényegre. A limitációt kell kihasználni.
Miért lenne lassú egy rövidebb, de ciklusokkal dolgozó kód, mint egy hosszabb, de ciklusok nélküli? Pl. a demóeffektednél.
Azért, mert a ciklusszámláló (és általában ilyenkor egyben indexáló) növelése/csökkentése, pl. INX +1 byte és 2 ciklusidő, annak figyelése pl. CPX #$NN +2 byte és +2 ciklusidő, + az ezekhez tartozó branch utasítás + 2 byte és +2 ciklusidő = +5 byte és +6 ciklusidő MINDEN CIKLUSBAN, tehát szorozva #$NN -el a plusz teher. Ez a kis effektemnél maradva alsó hangon is még + 1920 byte és + 2304 cpu ciklus, ha csak a render beviteli oldalát számolom, az outputot nem, mert így számoltam ki az előbbiekben a nondocumented opcode-ok hatását is.
Ezzel visszakanyarodtunk az eredeti kérdéshez: MIÉRT?
A demo is a non-interactive multimedia presentation that is rendered in real time .
Demos are usually created to showcase some or all of the following: computer hardware and/or software capabilities ... and/or the abilities of the programmer.
Láttam már C64 demót, ami ezzel az idézettel kezdődött, pont azért, hogy ha valaki véletlenül egy PC fókuszú partyn meglát egy oldschool demót 8bitre, akkor értse, hogy miről is szól a retroprogramozás, limitációk mentén.
Amiket itt leírsz, speciális demóeffektek, és itt is csak néhány utasítást használsz a nem normálisakból. Ezzel max. másodpreceket spórolsz 10+ KB-nál is a demóeffektnél. Azzal indult ez a beszélgetés, hogy átlagos használatnál miért és hol kellenek a nem normál kódok. Lásd a 8664-es üzit. Gyorstöltők, GEOS, játékok, tömörítő és kicsomagolóprogramok, stb.. Még mindig nem látom hogy annyira sokat számítana pár CPU ütem egy gyorstöltőnél, vagy máshol.
10-20 éve elég sok intrót, játékot, demót elemezgettem disassemblerrel, sosem találkoztam illegális utasításokkal. Csak olyan volt, hogy a kicsomagolórutinnál trükköztek EOR-ral dekódolással, meg csak 1-szer indíthatóra írták meg a játékokat, indítás után átrendezték a RAM-ot, hogy ne lehessen másodszorra indítani se azzal, se más címmel.
Miért lenne lassú egy rövidebb, de ciklusokkal dolgozó kód, mint egy hosszabb, de ciklusok nélküli? Pl. a demóeffektednél.
Ha ennyire gyors kód kell, akkor lehetett venni 4 és 8 MHz-es CPU kártyákat, Flash8, stb.. Nem muszáj az eredeti hardvert erőltetni. Ott van régóta a Turbo chameleon 64, mégse látok 1 demót, stb.-t se írva, ami kihasználná a kb. 14-16 MHz-et. Pedig több 100-at eladtak ebből.
A kis demóeffektednél csak a programkód 31 KB? Ez hogyan lehetséges?
Úgy lehetséges, hogy - mint említettem - double bufferes, tehát 16kb egy frame előállítása, de ez csak a render engine, e mögött azért még dolgozik ez-az kódban.
Azért ilyen hosszú, hogy ne legyen benne ciklus, mert ha van hely, akkor inkább gyorsabb legyen, mint kisebb, mert ha csak nem limitált compóra programozunk, akkor nincs értelme a kis kódnak, ha lassú.
A világért sem szeretnélek meggyőzni/kizökkenteni, csak a tényeket közöltem/közlöm. :)
A LAX minek? Mikor kell ugyanannak a címnek az értékét egyszerre az A-ba és az X-be tölteni?
Ha ugyanazzal az értékkel egymás után (speedcode!) többször kell elvégezni műveleteket, akkor kevesebbet eszik, ha letárolom nem csak akksiba, hanem X-be is (ingyen), és amikor megint kell az érték, nyomok egy TXA-t, ami csak 1 byte. Csak ezzel a manőverrel 384 byte (TAX vagy PHA) és 768 ciklus lett megtakarítva!
A SAX értelmetlen, mert hogyan lehetne egyszerre az A és X értékét beírni 1 címre?
Ezt másik effektnél használtam. SAX {adr} = store A&X into {adr} Tehát, nem egyszerre, hanem Akksit AND-olja X-el és az eredményt rakja el tetszőleges helyre. Hatalmas nyereség! Mégegyszer mondom, hosszú speedcode-ok. Miért speedcode? Hogy ne fecséreljünk ciklusszervezésre cpu időt.
LSA nincs:
Én ebből dolgozok, a csapatunk adta ki huszonpár éve:
opcodeja 4B. /más leírásban ALR-nek hívják/ Végrehajt egy AND #$NN-t az akkura, majd ezt LSR-ezi is (osztja kettővel). Ez is sokszor jön jól. Ha a kis effektemet megnézed, megértheted, miért.
Nem a műveletek itt a lényeg ebben az esetben, hanem az, h órajelciklust lehet spórolni, bár nem mindegyikkel.
Mondjuk a nulláslap használatával 4 helyett 3 órajelciklus alatt megvan, tehát nem használ LDA és TAX párost, hanem helyette $ A7-et ad meg és gondolom valamilyen értéket és már is spórolt egy ciklust, ami nem megvetendő, ha rengetegszer hajtódik végre ez a két utasítás.
Valamit időzít, raszter-trükköt csinál, vagy éppen a gyors töltő "dolgozik".
(Passz, annyira nem vagyok benne, legfeljebb, ha szépen kéred, beteszi ide a megfelelő kódrészletet és akkor láthatod.)
Ja, lehet jönni leugatni a szokásos stílusodban, h ehhez sem értesz, meg ahhoz sem. Valóban, semmihez sem...!
