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...!
Milyen műveletekhez kell sok LDA+TAX? Akkor se látom hasznát a nem normális kódoknak. Túl kevés helyen kell azokat az utasításpárokat egymás után használni, ahol lenne értelme.
A LAX minek? Mikor kell ugyanannak a címnek az értékét egyszerre az A-ba és az X-be tölteni?
A SAX értelmetlen, mert hogyan lehetne egyszerre az A és X értékét beírni 1 címre?
LSA? Nincs ilyen utasítás.
A kis demóeffektednél csak a programkód 31 KB? Ez hogyan lehetséges?
A nem dokumentált opcode-ok igen hasznosak. Nekem speedcode generálásakor, mikor repetitíve sokszor merülne fel sok LDA TAX páros, például, igenis sokat számít az a megnyert ciklusszám. Összességében kb. 3-4 ilyet használok, persze csak a stabilakat (LAX, SAX, LSA, sta.). STABIL: értsd: mindig így fut le, ahogy elvárjuk. Természetesen csak azokat használjuk programokban, főleg demóírásra, amik ilyenformán stabilak, nem lenne másképp sok értelme.
Mivel a rendert speedcode végzi, a hosszában és a CPU igényében is sokat számít, hogy sokmindent nem dokumentált opcode-al oldok meg. Ráadásul double bufferes, így duplán számít; mindkét buffer előállítására egy-egy speedcode van kompletten, mert nem fut le egy kép alatt az fx. Szóval így jobban elférek memóriában, és gyorsabb az effekt.
A fenti effekt render engineje $8000-$FB88 között van, szóval az említett opcode-ok nélkül el sem fértem volna ilyen kényelmesen. És mivel ilyen hosszú kódról beszélünk, inkább generálódik ez, mintsem bepötyögjük, bár mint előttem írták, a különböző assemblerek tudják ezeket. Én speciel Excel + VBA -t használok speedcode generálásra, van aki KickAssembler-t ,stb.
Még a Plus4 témánál vagyok, mert a 7501 is egy 6502 módosítás.
Itt van ez:
65802 (65C802)
A 65816 egy változata, pin-kompatibilis a 6502-vel, így a címtartománya csak 64 KiB
Úgy tervezték, hogy közvetlenül felválthassa a 6502-t a meglévő áramkörökben
Órajele: 16 MHz-ig
Simán lehetett volna ebből csinálni 6510-et, 7501-et, 8502-t, stb. a Commodore cuccokba. 1982-1994-ig végig a bugos 6502-t, és az ebből fejlesztett CPU-kat használták, ami röhej. A 6522 is bugos volt, mégse tettek semmit.
Nem kell nekem 50 perces videó. Miért nem használtak a 80-as években másmilyen CPU-t, amiben eleve több utasítás van? Voltak 1980 körül más CPU-k is a 6502-nél több utasítással. Ezt is lehetett volna módosítani a C64-hez, mint a 6510-zel meg is történt, ez a 6502 módosítása. Itt van az 1981-es WDC 65C02.
Én nem is kifejezetten neki írom, hanem csak azért, ha más is olvassa az agyalásait a topikban, ne a hülyeséget vegye készpénznek, hogy a tiltott kód majd lefagy meg hú meg ha.
Mondjuk valószínű mindenki ért angolul -rajta kívül-, és kb tudja is ezeket, vagy ha nem, utánnanéz, szóval tényleg kár minden hülyeségét részletesen kitárgyalni, mea culpa.
Akit nagyon részletesen és mélyen érdekel, mi az, hogy "tiltott kód", mitől van, miért és mi történik olyankor, megnézi ezt, és megért _mindent_:
(alapszintű logikai áramköröket, alapvető makroarchitektúrát, a 6502 assembly alapjait azért érdemes megismerni a megnézése előtt........ mivel ez kifejezetten a 6502-ről, és nem általában a processzorok felépítéséről működéséről és programozásáról szól)
Nézem ezeket a SLO, stb utasításokat. Elég kevés olyan helyzetet tudok elképzelni, ahol szükség van pont ilyen dupla műveletekre egymás után. ASL+ORA, ROL+AND, LSR+EOR, ROR+ADC, LDA+LDX egyszerre, stb. Ezek csak a SLO, RLA, SRE, RRA, LAX utasítások voltak.
Nem értem hogy ezek hogyan segítenek abban, ha pl. 1 rasztersorban több színt akarok csinálni, mint alapból lehet a sima LDA, STA-val. Alapból csak 6-7 karakterhelyenként lehet színt változtatni, és ez a rejtett utasításokkal se lesz jobb. Az LDA színkód, STA 53280, vagy 53281 módnál nincs gyorsabb mód a színek beírására, ezeket ismételve egymás után. Persze lehet olyan, hogy LDA 1. szín, LDX 2. szín, LDY 3. szín, és STA 53280, STX 53280, STY 53280, de ezzel csak 3 szín lehet egymás után. Ez nem sokat ér, mert a 3 LDA alatt megint több karakternyi helyet megy odébb a raszter. Ha meg 1 rasztersorban csak 1-szer van a 3 LDA, utána csak a 3 STA-t variálom, akkor csak 3 szín lehet az egész sorban kb. 4 karakterhely/színnel. Itt 2 karakterhely van a 3 színes csak ST-kkel, de C128 mód 2 MHz kapcsolgatással.
8B-ről nem tudok nyilatkozni, de a többit biztosan használják. A Spindle is azért nagy cucc, mert soros 1541-es trackloader, úgy, hogy realtime GCR dekódolást csinál a lemez forgása közben, így nem kell neki nagyobb RAM a floppyba. Ez pl. használja ezeket a nem dokumentált (ne hívjuk illegálisnak, mert nem azok) műveleteket.
Egyébként (bár nyilván ezt itt nagyjából mindenki tudja), ezek pont azért jöttek létre, mert a 6502 (és az arra a magra épülő összes többi proci is) annyira végtelenül leegyszerűsített, hogy az utasításkód néhány bitjéhez van kötve, hogy pl. A, X vagy Y regiszterre értelmezett a művelet. Ha két bitet is beállítasz, akkor kettőre fog menni.
Akkor is érdekes hogy ennyire elterjedt volt a sok tiltott kód használata. Miért akarod azt belemagyarázni a dologba, mintha a CPU gyártók szándékosan eltitkolták volna az utasítások egy részét, amik amúgy jól működnének, csak hogy ne használják az emberek? Akkor az összes nem normális utasításkód rendesen működne, egyiknél se fagyhatna le a CPU, vagy csinálna valamit (mindig ugyanazt), vagy mindig NOP lenne. Nyilván hogy kísérletezgetéssel jöttek rá a C64 demóírók, stb., hogy melyik utasítás mit csinál, vagy mit nem. Ebből lettek a LAX, stb. jelölések is. Ha a 6502, 6510, stb. tényleg nem előre megírt mikrokódos módon működik, akkor simán csak a működés melléktermékei a nem dokumentált utasítások. Még mindig nem világos hogy miért építettek a programírók ezekre. Akkor ezek szerint a mai modern PC, stb. CPU-kban vannak titkolt utasítások?
Ebben van valami... de lehet, h csak a 128-am nem jó. Néha, átváltva 64-es módba, vékonyak, egy pixel szélesek lesznek a betűk. Nem tudom, talán a 128-as mód valamelyik charset-je aktiválódik? Ezt mondjuk kétlem, de hátha valaki tudja. ----------------------------------------------------------------------------
8B-nek csak kimenete részlegesen kétséges, de pl. 6510-8510 vonalon meglehetősen biztos, hogy mi fog történni. (ld a táblázatban a "stable = yes" minkettőnél, + ha megnézed a koreai és philippines 1541-be gyárilag szerelt 6502 procinál is stabilnak mérte)
Egyébként, ha egy utasítás részlegesen instabil, az nem azt jeleti, hogy megfelelő körültekintéssel ne lenne használható.
Időszakosan vannak igazi coderek is a topikban, majd ők hozzászólnak hány pluszis demóban mennyi 8b van, vagy nincs.. :)
(tiltott kód tuti rengeteg, mivel a duplakimenetű, bemenetű vagy több műveletes utasítások egy célzottan megírt gyors rutinban komplett ciklusokkal gyorsabbak, simán ez választhatja el azt ,hogy valami lehetetlen vagy lehet, egy rasztersor alatt, egy olvasott GCR byte ideje alatt, stb )
"Mindenütt van, ahol nincs kihasználva mind a 256 utasítás gyárilag"
Csak éppen egy mikroprogramozott processzoron minden utasítást külön mikroprogram valósít meg.
Amit valaki megírt és beletervezett a processzorba.
Tehát a nem használt opkódok, -ha csinálnak valamit-, az bizony egy szándékosan nem dokumentált, szándékosan létrehozott utasítás, amit legfeljebb nem dokumentáltak.
(általában ha nem akarnak minden opkódot kihasználni a többi NOP, semmit nem csinál rá a CPU)
Valószinűleg azért nem érted, mert a processzorok működéséről is csak homályos fogalmaid vannak, ilyen szakirodalom pedig szinte nincs magyarul.
Talán itt a polcon nálam akad egy kivétel...bár roppant alapszintig jut el...
"FodorTamás-NagyImre" Digitális számítógépek I-II-III, 1991, ISBN 963-10-7489-7, "A munkaügyi minisztérium megbízásából kiadja a műszaki könyvkiadó, A KÖNYV KERESKEDELMI FORGALOMBA NEM HOZHATÓ!!"
