llvm-mos - kísérleti projekt az LLVM MOS 6502 processzorokra való portolására

Programozás

GitHub repository itt.

( asch v | 2021. 05. 28., p – 18:06 )

Bleeding edge technológia! Rá kellett keresnem, 1975-ben kiadott processzor, erre épül a Commodore64 is. Mostantó lehet LLVM-mel fordítani erre a gépre! \o/

 

Aki foglalkozik ezekkel, az leírhatná, hogy mi a jelentősége ennek!

Ezt nem mondod komolyan, hogy ennek utána kellett keressél. Az egyik legsikeresebb, legismertebb retró proci, a Z80, m68k mellett ebből adtak el a legtöbbet. Nem csak a C64-ben volt, hanem az összes nem-m68/x86 Commodore gépben, meg egy csomó játékkonzolban (Atari 2600, stb.).

Amit én a hírben nem értek, hogy miért csak C? Az LLVM-nek pont az a lényege, hogy a fordító első lépcsőben köztes virtuális architektúrára fordít, így a célhardverre már csak egy llvm-to-célarchitektúra fordító kell, és nem kell minden nyelven, minden külön fordítót újraimplementálni, elég csak az LLVM-et támogatni. Pont ezért lett az LLVM kitalálva, nem azért, mert unatkoztak és legyen valami ilyesmi is.

Egyébként meg nem olyan haszontalan, mint gondolnád, elég sokan foglalkoznak még C64-gyel, komplett demoscene van még hozzá mindig, meg retrós, meg rekreációs/hobbista programozók még portolgatnának rá kódokat. Nyilván a BASIC elavult, meg lassú, interpretált, limitált, így eddig csak ilyen régi architektúrán gépi kódban, ASM-ben lehetett nyomni, ami meg sok modern fejlesztőnek emészthetetlen. Így nem árt, ha a főbb, magas szintű nyelvekhez van rendes compiler.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> Ezt nem mondod komolyan, hogy ennek utána kellett keressél.

De, nekem Enterprise-om volt, és valamiért abban a hitben voltam, hogy a Commodore is Z80 alapú. Haveroknál játszottunk rajta, annál közelebb sosem kerültem a Commodore gépekhez.

> Egyébként meg nem olyan haszontalan, mint gondolnád

Nem állt szándékomban ezt sugallni, de utólag nézve kicsit így hangzik amit írtam. Egyszerűen csak nem ismerem ezt a világot, azért kérdeztem. Sejtem, hogy ez főként hobbi kategória, de a hobbit is komolyan és jól érdemes csinálni. A szívemhez egyébként közel állnak a 8 bites processzorok, de főleg csak AVR-eket programoztam még.

Akkor ismerkedj meg vele közelebbről ;-) Érdemes! Azt nem mondom, hogy igazi vason próbáld ki, mert az kicsit fájdalmas tud lenni. De egy cross compiler és egy emulátorral is meg lehet csinálni.

Mondom úgy, hogy 5 db C=64-em van jelenleg :-) De azon a billentyűzeten, és fejlesztő eszközökkel nem annyira felhasználó barát mai szemmel nézve.

Nem is ezt mondtam, hanem azt, hogy az a fő CPU. Amikor bekapcsolod, az "éled" először és megpróbál bebootolni floppy-ról (CP/M-et, vagy bármit amit fel tud), aztán, ha nem sikerül, akkor átadja a vezérlést a 8502-esnek, ami a megfelelő feltételek (C= gomb nyomása, C64-es cartridge, stb.) teljesülése esetén bebootol C64-es módba, különben C128 módba.

Oldschool Computer - http://oscomp.hu

Az igaz, hogy a C128-ban default a Z80-as proci bootol be, de akinek C128-a van, volt, az tudja, hogy ebben a módban szinte sose használta senki. Mindenki C64 módban használta, amikor a 6502-es proci aktív benne. Mivel a Commodore-os szoftverek nagy része erre íródott, főleg a játékok, mint húzóalkalmazások. A Z80 csak azért lett beletéve, beleerőltetve per default, hogy cégeknek vonzóvá tegyék CP/M futtatására. Az ötlet nem is lett volna rossz, csak az időzítés lett elkésett, 1985-ben lett kihozva, de akkor már a céges szféra nem 8080/Z80-as alapokon használt CP/M-et, hanem szinte mindenki tovább lépett x86-os alapokra és DOS-ra (Wordperfect, Lotus1-2-3, dBase, stb. workflow-n alapulva).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem csak nálunk megy a nosztalgiázás.
"Csirketelep" megvan?   https://www.youtube.com/watch?v=GqrfHrlVf7A
Nagyon komoly restaurációt végeznek ezek az elhivatott idősek. Nekik még igazán szívükhöz nőtt a Csepel, Ikarus, Rába.
Tisztelettel búcsúznak el egy újabb remekművüktől.

Ma a "használni és eldobni" korszakot éljük. Annyira fogyasztói társadalom lett a szemlélet, hogy a régebbi dolgoknak nincs további értéke.

Egy oldalról egyetértek veled, hogy van, amit el kellene engedni, más oldalról kis időt rászánva az átgondolására nekem az is felmerül, hogy lenne ennek értelme a mai világban is.

A mondat első felére azzal érvelnék, hogy egy ilyen rendszer elkészítéséhez nagyon sok idő kell és nagyon nagy tudású ember(ek). Ha ezt az időt és tudást/elszántságot nem ilyen "hasznontalan" dologra fordítanák, hol tarthatna egy-egy olyan rendszer fejlettségben, ami tömegeknek hasznos.

A második fele meg azzal védhető, hogy ha a mai programozó gyerekeknek ilyenen kellene kezdeniük programozni, nem egy 1024 magos, 2 TB memóriás klaszterre írni valamit, ami csupa NVMe 4.0 meghajtóval van kirakva, akkor nem történne meg az, hogy egy random, elterjedt nyelven megírt konzolos "Hello World!" lefordítva 70 MB, és igényel egy 1 GB feletti runtime-ot az induláshoz... komolyabb programokról ne is beszéljünk.

Az IT-ben volt valahol egy váltás, amikortól a kód optimalizálása helyett az lett a mondás, hogy vegyél erősebb gépet. És ott elcsúszott a programfejlesztés is, mert akkor is rá lehetett mondani, hogy vegyél erősebb gépet, ha egyébként az adott program jól megírva nem igényelt volna ilyesmit. De ugye az erősebb gép lehetősége egyre inkább engedett gyengébb programozókat...

Áhh nem a gyenge programozókon múlik ez, hanem az agresszív product managementen. Ha 3-4 sprint teamnek fél év alatt kell 0-ról összecsapnia egy tizenegynéhány komponensből álló enterprise szoftvert, frontenddel, workflow managementtel, monitoringgal, alertinggel, HA-val, security-mindennek is megfeleléssel (persze ez utóbbit szigorúan csak papíron), akkor persze hogy szó nem lehet optimalizálásról vagy olyan programnyelv választásáról, amin egyáltalán esély van hatékony kódot írni.

És hiába tudja a product managered is, hogy ebből az erőltetett tempóból baj lesz, de akkor meg a konkurenciától maradsz le mint a borravaló.

Régóta vágyok én, az androidok mezonkincsére már!

A francokat nincs. :) A nyílt forrású cuccok nagy része sem hobbiprojekt. A legrosszabb, amikor egy manager (tipikusan egy frissen kívülről beújított valaki, akin rajta a bizonyítási kényszer, hogy valami új trendy stratégiával megreformálja a céget) úgy dönt, hogy "használjuk a community erejét", a korábban házon belül gányolt cuccok bugfixálásra.

Régóta vágyok én, az androidok mezonkincsére már!

Pont ezen gondolkodtam ma reggel. Nálunk is akkor indult el a színvonal a béka segge alá, amikor egy vezető úgy döntött, hogy ,,jövedelmezőbbé" teszi a munkánkat és engedni kellett a szakmai elveinkből, egyre többet.

Az a gond, hogy ezzel csak térben és időben lokalizáltan lesz jövedelmezőbb valami.

Ez megint csak a költségek externalizálása. Mert össz-társadalmi szinten megfizetjük a szar szoftverek ,,árát". Persze a lényeg, hogy mások fizetik meg (sarcasm).

Ma gyakorlatilag a pénzügyi szférában low-level programozóként lehet rendes munkát végezni. Mert ott van elég pénz és nincs igazi versenyhelyzet.

Aki szerint összemérhető, az tényleg idióta, de akinek hobbija a 6502, az belemélyed abba, hogy működik, esetleg assemblyben programozza, és tanul valamit, még ha valaki szerint tök feleslegesen is. Azzal, hogy a Ryzent használod, te magad semmit nem tanulsz belőle, egyáltalán tudod, hogy melyik lába ennek a CPU-nak mire való? Vagy hogy egyáltalán milyen lábai vannak? Hobbi szinten esélytelen már az új dolgokkal ilyen szinten foglalkozni.

Oh, felesleges érvelned. A mai rendszerismeret és szoftvertákolás úgyis kb. ebből áll az esetek többségében: https://www.youtube.com/watch?v=X5SkW7K0e3Y
Persze ha valamelyik "3rd party" komponenssel gond lenne, akkor általában csak bambán nézünk ki a fejünkből, az ügyfélnek pedig marad hibásan a szoftver.

Egyébként az embedded programozóknak még bőven hasznos lehet egy 6502 ismeret, abban a világban ma is előfordul a 64K RAM (vagy annyi se). Egy ATtiny 45-ben van 256 byte RAM (egy Atari 2600-nak volt 128 byte).

Az npm-el fél világot letöltő JS fejlesztő már elveszett, kellene nekik is egy bootcamp egy ilyen CPU-n, hogy észhez térjenek.

Áh, az a szekér is elment. Minden vacakba valami Linuxos cuccot akarnak rakni. Oda is, ahova egyáltalán nem indokolt. De legalább van MySQL + Javascript.
A többivel pedig nem akar a legtöbb foglalkozni.

Egyébként ha már C64 ... sok-sok szépség még amikor nem volt se HUP, se internet ... https://www.youtube.com/watch?v=ypyt3mLv7vg   Szoftver: Digicom64, rádióillesztő hardver TCM3105 IC-re épült.
A rádiófrekvencián akkor is ment a móka és kacagás ... 1200 bps (RH-n 300 bps), de piszok lassú adás-vétel átkapcsolási idővel. Az 1980-as évek második felében mindez internet híján igen hasznos volt.
A teljes hálózati kapcsolatfelépítés és minden szintén alaposan dokumentálva volt (legutolsó verziója itt olvasható).
Alacsony szinten volt benne UI keret (UDP-hez hasonló feladatra, de L2 szinten) és I keret (TCP-hez hasonló feladatra, L2 szinten. Rendesen Connect és Disconnect folyamat + 8 keretes nyugtaablak). Mindez az internet előtti korszaktól és rádión.
Aztán 1991-ben az internet ahogy kezdett a világon kiépülni, lett RFC arról, hogy hogyan kapcsolhatóak össze interneten a rádióamatőr adatátviteli hálózatok. IP protocol 93. Ez ma is ott figyel a /etc/protocols állományban.
Aztán az ezredforduló után pár évvel ez is ment a történelem süllyesztőjébe. Szép játék volt, szemléletes és egyúttal hasznos adatátviteli megoldás volt a szöveges korszakban.

Nem tudom, az elefántcsonttoronyból miért fáj, ha valaki az alapoktól és a (h)őskortól ismerkedik a hardverrel. Persze sokan megmaradnak hobby szinten, de azért hw fejlesztésnél csak jól jöhet még az ilyen tapasztalat is.  HW nélkül meg megsütheted a SAN tudásod.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Mai napig használok a játékfejlesztői munkámban egy rakás olyan trükköt, amit a 8 bites hardverek programozása közben tanultam és nagyon jól jönnek, ha optimalizációról van szó.

Android: https://play.google.com/store/apps/developer?id=Artex+Games
iOS: https://apps.apple.com/developer/artex-studios-inc/id399983944

Hát nem tudom. Nekem még alap, hogy mely gépekben dobogott 6502, Z80, i8085, i8086 és nagyjából hogyan épült fel egy ilyen számítógép. De lehet ez csak azért van, mert öregszem sok társammal együtt.

Szerintem a 8 bit jóval több, mint retró. Volt ezekben valami nagyszerű, valami csodálatos. Ami mára kihalt és érthető, hogy egy rétegnek hiányzik.
Számomra ezt jelentette a programozás, nem azt a referenciabújásos vagy inkább már stackexchange túrásos java-zsonglőrködést, amit ma sokan csinálnak.

Szerintem a 8 bit jóval több, mint retró. Volt ezekben valami nagyszerű, valami csodálatos.

Hobbibarkácsolásra, rendszer megismerésére, tanulására is alkalmas volt. Sokkal egyszerűbb a maiaknál, átlátható, és alaposan dokumentált.
Lásd: alapos kézikönyv, könyvben teljes forráskód kommentezve, könyvben teljes kapcsolási rajz.
Ezeket a vasakat még "bare metal programming" módon gyúrhattad. Azaz érezted a vasat és volt valami szépsége a trükkök kiaknázásának.

... meg FPGA-kba bele nagyon jok a 8-bites procik. Noplane ha van hozza C fordito :) Az a tapasztalat hogy nagyon sok problemara meg mindig joval egyszerubb egy SoC-ot felepiteni egy FPGA-ban - azaz egy egyszeru processzor + spec, egyedi periferiak - mint akar tisztan klasszik FPGA-val szopni, mint akar tisztan MCU-kkal kieroszakolni a mukodest.

Ez mai napig egy absz naprakesz elo valami, es a retros dolgok ezt hatarozottan segit(het)ik megerteni es/vagy elsajatitani.

"Jovore" (5-10 ev mulva) MÉG Rustban fogjak irni.

De felek, hogy eljon majd a nap, amikor rajovunk, hogy lassan nyugdijaztuk az utolso C es Rust fejlesztot is, mikozben karbantartasra mindket nyelv eseten maradt volna igeny.

A hasonlosag: ASM programozok is mar nagyon kevesen vannak, tobbnyire C forditot fejlesztenek.

A kulonbseg: a C forditok rengeteget dolgoznak evtizedek alatt kialakult modszerekkel optimalis forditasi fakon, futasidokon, es ezt a "senki nem erdekel, hogy 1 vagy 3 masodpercig tolt" hozzaallas felek, hogy megszunteti. Attol tartok, hogy egy nap alacsonyabb szinteken is elterjed a "nem kell optimalis futasido, mert van eroforras boven, de az alacsonyszintu programozo-ora meregdraga" hozzaallas, teljesen megszuntetve a gyorsan futo alacsony szintu kod igenyet is, mert "ahhoz nyugdijbol kene visszahivni embereket".

Én nem hiszem, hogy annyival kevesebb lenne aki ért hozzá, egyszerűen csak többen foglalkoznak programozással, és közöttük elveszik az a kevés, aki ért is hozzá. Illetve aki ért hozzá, az is hajlamos üzleti szempontok miatt nem foglalkozni optimalizálással - legalábbis csak a legnagyobb blockereket oldja meg, a kicsire nem ad. De ha volna rá kereslet, akkor volna rá képesség is. Beállt egy egyensúly és kész.

Szerintem egyáltalán nem törikönyv szintje. Nem haszontalan ezeket a régi rendszereket ismerni. Ugyanis ezek a régi technológiák egyszerűbbek és jobban megérthető rajtuk azok a fejlődési trendek, szoftverfejlesztési, és architekturális koncepciók, amik mentén végbementek fejlődések, fejlődési trendek. Elhiszem, hogy téged speciel nem érdekel. Én se vagyok egyébként benne annyira a retróban, néha emulátorozok, de sok órát nem teszek bele. Pedig most nagyon nagy divatja van, mindenki retrózik, meg veszik nyakra-főre a retró hardvert. Én ennyire elvakult nem vagyok, de ismerni nem árt ezeket, lehet belőlük tanulni. Egyáltalán nem kidobott idő. Főleg olyan retró rendszerek esetén nem, amiknek továbbra is van jövőre, Unix és annak származékai, C-szerű nyelvek, shellek, vim/Emacs, stb.. Attól, hogy valami régi technológia, nem jelenti azt, hogy primitív, és ma már használhatatlan.

A C64 meg kiváltképp kiemelkedik most, elég sok embert elég nagy nosztalgia köt hozzá, mai napig jelennek meg új demók, új játékok, új magazinok hozzá, de pl. még új, multitaskig OS-t is fejleszt rá valaki (TEOS). Egy csomó modern periféria érhető el rá mindig, sőt, már majdnem ott tartanak, hogy 1-2 proprietary chip meg egy billentyűzet híján vadi új C64-et is lehet építeni, amiben minden új, ház, PCB, szinte az összes chip, RAM, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, mindegyik ugyanaz az 6502-es architektúra, mindegyik egyformán futtatja a 6502-es generic kódokat. Inkább csak 1-2 extra pin, 1-2 extra utasítás, más gyártástechnológia az, amiben a felszínen különböznek, ami azt eredményezi, hogy egymással nem pin-kompatibilisek, de házilag átdrótozhatók úgy, hogy működjön. Nyilván ettől még a 6502-es kódok nem gépfüggetlenek, mivel használhatnak extra utasítást, meg más-más memóriakiosztás, I/O műveleteket, ami gépenként eltért. Kb. olyan különbséget kell elképzelni, mint a 8086 és 80186 volt hogy utóbbiba voltak extrák implementálva, és hiába volt kód szinten kompatibilis, olyan gépekbe került, amik nem teljesen voltak PC kompatibilisek, mert más volt a BIOS, más volt egy-két segédchip. Emiatt hiába is volt rájuk spéci DOS, jó pár DOS-os program, ami IBM PC BIOS kódokat használt volna, az nem futott rajta.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Pár éve olvastam, hogy SD kártyák beágyazott vezérlőjének visszafejtésekor találtak némelyik firmware-ben 6502-es utasításkészletet. Persze nem 1 MHz-en ment, és mindenféle non-standard hozzátoldások voltak benne. De ezekszerint beágyazott rendszerekben mikrokontroller szintű feladatokra még sok helyen használhatják, mert kicsi, olcsó, licenszdíjat senki nem kér érte.

Régóta vágyok én, az androidok mezonkincsére már!

1 MHz original, 2 MHz C128-ban ... 14 MHz Motorola W65C02s-14.
https://westerndesigncenter.com/wdc/documentation/w65c02s.pdf - 25. oldal "AC Characteristics"

Csináltak ennél gyorsabbat?
Megjegyzem, az egyetlen Accumulator regiszter azért komoly hatékonysági hátrány egy pl. 8 regiszteres másikhoz képest.

Hogyne csináltak volna, C64-hez/C128-hoz volt is kiegészítőként: https://www.c64-wiki.com/wiki/SuperCPU, WDC 65C816S CPU, 20 MHz, 16 MB RAM. (Mondjuk ez már 16-bitre bővített 6502-es.)
Van rá demo is. :)

Oldschool Computer - http://oscomp.hu

60-valahány MHz rémlik, de most így hirtelen nem találtam meg a cikket, amiben szerepelt.

De egy SD kártyába nem egy standard-közeli 6502-t, inkább egy full dokumentálatlan, teljesen ad-hoc módon bővített utasításkészletű valamit kell elképzelni. Simán lehet, hogy annak csináltak több acc regisztert.

Régóta vágyok én, az androidok mezonkincsére már!

De ezekszerint beágyazott rendszerekben mikrokontroller szintű feladatokra még sok helyen használhatják,

Eredetileg annak is készültek ezek a procik, beágyazott rendszerekbe, afféle mikrovezérlőkként, csak a RAM/ROM, netán periféria, nem volt még beléjük integrálva. 

Hát igen, a RAM + PROM-ot (egyszer programozható) integráltan tartalmazó mikrovezérlők az 1990-es évek elejétől terjedtek el. Fejlesztéshez UV fénnyel törölhető "kvarcüveg ablakos" verziók voltak.
Az EEPROM-os verziók csak valamikor 1995 utántól terjedtek itthon el.

Addig 8051 + RAM + ROM illesztés ... digitális technika órai tananyag volt. A 27xxx EPROM család "közismertségnek" örvendett.
https://i.ebayimg.com/images/g/SGcAAOSwoTVdZTyR/s-l640.jpg
Ablak ezen sem díszítés, ezt is UV fénnyel tudtad törölni. Aztán az ablakot leragasztottad, védted a fénytől.

A 6510 nem is lett volna sikeres, ha nem raktak volna ügyesen mellé
   - VIC
   - SID
jól eltalált IC-ket + kettő botkormányt. Ezekkel együtt alkotott rendszerként lett egyben akkor egy nagyon ütős a cucc.

( kl3on v | 2021. 05. 28., p – 18:43 )

Szerkesztve: 2021. 05. 28., p – 18:44

A cc65 compilert használtam C64hez, viszont emlékeim szerint a legkisebb méret amit elő tudtam állítani a binárisra, az 8Kvolt, a kötelező static linking miatt. Ami így a téma iránt csak érdeklődőként szerintem elismerésre méltó, de még mindig luxus, amikor pl 38K memóriádból kell gazdálkodni alapból. Kiváncsi vagyok ez mit és hogyan fordít, linkel.

Megnéztem a cc65 fordítót. Ha az stdlib-ből nem használsz függvényeket, hanem te programozol le mindent, akkor a produktumod 272 byte mérettől indul.
Ja és a közvetlen videó memória kezelés sem kötelező, hiszen ettől még beugorhatsz a ROM megfelelő részére is. Például character out esetén A regiszterbe töltött karakterrel beugrasz a ROM 0xffd2 címére. Bár a közvetlen memóriaírás nyilván gyorsabb és C-ben sem vészes lekezelni.

Megnéztem, a CC65 a grafikus memória kezeléséhez szükséges 320-szal való konstans szorzást nem kezeli optimálisan, azt ha gyorsítani akarunk, muszáj saját mul320.s állományban magunknak assembly-ben korrigálni.
(Aki nem ismeri, ezekben a processzorokban még nem volt hardverszorzó, a szorzást így shift és add műveletek felhasználásával lehet elvégezni, de a konstanssal való szorzásnál további egyszerűsítési trükkök vannak.)

Fel lehet azt írni C-ben is szorzás nélkül:

y = (x << 8) + (x << 6);

Vagy, mert lehet, hogy nem optimalizálja ki és 8 shift helyett 14-et csinál:

y = x << 6;
y += y << 2;

Ehhez nem kell assembly.

(BTW, a 320-as szorzás hova kell a grafikus képernyő kezelésénél? 1 pixel 1 bit HiRes-ben és 2 bit MultiColorban, de úgy csak 160 pixel van egy sorban, szóval egy sor mindig 40 byte...)

Oldschool Computer - http://oscomp.hu

Igaz, low level C-ben is összerakható és cc65 esetén érdemes összerakni. Próbaként ellenpélda: avr-gcc, amely ATtiny-nél átlátja a trükköt, automatikusan gyors 320-as szorzást fordít.

A C64 grafikus pixelszervezése érdekes volt. Az is karakterhely orientált volt. Tehát a bitek egymás melletti pixelekként jelentek meg, ebből 8 byte egymás alatt (függőleges irány), majd következő a mellette.levő karakterhelyen folytatódott.

A szineket így ha jól emlékszem karakterhelyenként újra tudtad definiálni. Na itt már homályosodik az emlékem, pedig sokat programoztam azt is assemblyben..

DOH, igazad van, megfeledkeztem róla, hogy karakterenként épül fel a bitmap képernyő is, látszik rég foglalkoztam már vele...

Igen, a relokálható ScreenRAM-ban határozhattad meg az egyes byte-okon az egyes 8x8-as mezők 0. és 1. színét HiRes módban, MultiColor módban pedig az egyes 4x8-as mezők 1. és 2. színét, a 3.-at a $D800-ra drótozott 1024 nibble-nyi ColorRAM-ban, a globális 0. színt pedig a $D021-on.

Oldschool Computer - http://oscomp.hu

Felcsigáztál, nosztalgiáztam picit és elővettem a témát cc65 fordítóval és C64 emulátorral.
Egyik tanulsága, hogy ha nem szolgai módon az algoritmus akarom leprogramozni assembly-ben (ahogy néhány évtizede), akkor tényleg elég a 40-es szorzás és néhány felesleges jobbra shift majd felesleges balra shift elmaradhat.

// x: 0..319, y: 0..199
void setpixel(uint16_t x, uint8_t y) {
    // ha itt nem (y >> 3) van, hanem (y & 0xf8), akkor nem kell később 3-szor felshift
    uint8_t rowX8 = y & 0xf8;
    // 40 = (2*2 +1x)*2*2*2
    uint16_t idx = ((( (rowX8 << 2) + rowX8) << 3) + (x & 0xfff8)) | (y & 7);
    pixelmem[idx] |= (0x80 >> (x & 7));
}

A teljes példakódot itt megtalálod, fordítási és vice-ben való futtatási instrukciókkal együtt. Egyébként ez lefordítva 913 byte.
(vice telepítése után a sourceforge repóban levő forráskódból kell még a basic chargen kernal a /usr/share/vice/C64/ mappába, hogy fusson.)

További hasznos:
   https://www.commodore.ca/manuals/c64_programmers_reference/c64-programm…    pdf 27. 28. oldala (könyvben 125, 126) leírja a memória kiszámítást.
   https://www.commodore.ca/commodore-manuals/commodore-64-users-guide/
   https://www.commodore.ca/commodore-manuals/commodore-64-programmers-ref…

Lecsekkoltam, kirakja az X-et (a VICE már sok éve fent van). (Mondjuk egyeneshúzáskor jobb inkább a címet és a maszkot léptetni, mint újraszámoltatni minden pixelnél.) Én is nekiálltam kíváncsiságból a címszámításnak; én ezt hoztam össze saját kútfőből, lépésről-lépésre implementálással, majd kiegyszerűsítéssel:

uint16_t idx = (y & 0xf8) << 3;
idx += (idx << 2) + (x & 0xfff8) + (y & 7);

Ahogy nézem, ez majdnem ugyanazt csinálja, mint a tied, csak mivel én először szoroztam 8-cal és csak utána 6-tal, így nem kell neki átmeneti változó, spóroltunk egy byte-ot a stack-en. :P (Ezek szerint mégis célszerűbb lenne 320-szal szorozni?)

Oldschool Computer - http://oscomp.hu

Ennek ellenére ez 2%-kal lassabb. Csináltam erre is egy tesztet.
Közben belefutottam, hogy a cc65 printf() függvénye bugos, ne használd.

Viszont C-ben teljesen más érzés C64-et programozni, mint annó assembly-ben. Ha annó kezembe került volna egy C fordító és egy C könyv ...

Látom. Mondjuk ennek a fele azért van, mert összeadást használtam a végén, nem vagy-ot, így feleslegesen 16-biten elvégezve az összefésülést. Ha nem + (y & 7) van a végén, hanem | (y & 7), akkor nem 1001 ticks vs 1021, csak 1001 vs 1013. Valószínűleg ugyanez okozza a másik felét is, a (rowX8 << 2) + rowX8 az 16 bit + 8 bit, míg a idx += (idx << 2) az 16 + 16 bit. Vagyis a y = (4 * x + x) * 8; jobb lebontás, mint a y = (8 * x); y += (y * 4);, ha x 8-bites, még akkor is, ha ugyanúgy 5 shiftelés és egy összeadás van benne.
Mi baja a printf()-nek?

Volt a CoV-ban C rovat, szidták is, mint a bokrot. :P

Oldschool Computer - http://oscomp.hu

printf() hibák:
    \n --> nem lépteti a sort.  pos =  (x / 40 + 1) * 40
    %d --> nem működik

Esetleg ettől eltérő formázó karakterei vannak? De akkor meg nem egyezik az ANSI C-vel, ami meg azért gáz.

Ha belegondolok, hogy milyen lassú a C64, 1 MHz alatti órajel és 2..7 órajeles 8 bites utasításokkal, hardverszorzó nélkül ... mennyi de mennyi trükk be lett vetve hogy értelmes tempót adjon a játék.
A VIC overlay technikáit is ki kellett használni. A hardveres sprite és a sprite-ütközés detektálás nagyon eltalált hardvertámogatás volt. Ha ezeket mind használtad, akkor jött az, hogy a VIC, amely a CLK alacsony állapotában használta a RAM-ot az Address Enable Control (AEC) lábon keresztül rendszeresen blokkolta a 6510-es CPU-t és a CLK H állapotában is használta a RAM-ot. Rengeteg hardvertrükk, amit a kényszer szült, de trükkösen megoldották.

(Volt 8 órajeles utasítás is, igaz, az mind illegal. :P) A VIC-ben az is jó volt, hogy a ScreenRAM relokálható volt, így ha tartottál egy szekunder példányt belőle és a VBlank alatt egy szimpla váltással cserélgetted őket, akkor 136 színből választhattad ki a 0. és 1. színt 16 helyett, vagy MC-ben az 1.-őt és 2.-at, bár ott kicsit csiklandósabb volt a dolog, mert a ColorRAM-ot nem lehetett mappelni, így a 3. színt vagy továbbra is 16 színből választottad ki, vagy VBlank alatt becopyztad azt az 1000 byte-ot, ha belefért...
Igazából két dolgot nem értek: a ColorRAM-ot miért nem csinálták 4 helyett 8-bitesre, hogy onnan lehessen húzni MC módban a 0. színt, hogy ne globális legyen és miért nem tették a ColorRAM-ot szintén mappelhetővé, hiszen a VIC 16k-s tartományába bőven belefért volna (csak 8k volt a bitmap és 1k a ScreenRAM). Bár gondolom a fő szerepet az olcsósítás játszotta itt is...

Oldschool Computer - http://oscomp.hu

Nem voltam elégedett a cc65 által fordított kóddal, továbbá kíváncsi voltam a paraméterátadásra.
Ezért időközben kíváncsiságból a setpixel() részt megírtam assembly-ben. 454 ticks lett, 2,2-szeres gyorsulás.
A bench.c mellett találod asmfunc.s néven.

Na ez is kivesézve, egyúttal a hétvégi nosztalgiázás megtörtént.

Én se bírtam magammal, újraírtam nulláról az assembly rutint, elérhető itt: http://oscomp.hu/depot/asmfunc.s
396 ticks lett a végeredmény, az ~2.53x-os gyorsulás.

Note: 3 helyen nem dokumentált utasítást használtam, de csak egyre írja a manual, hogy "instabil" (XAA); VICE-ban működik.

Oldschool Computer - http://oscomp.hu

Keresőtábla ügyes, a végén a 0x80 >> bitshift loop kidobva. Ezzel 402-re leugrott az általam írt is. Kicseréltem arra.
A te megoldásod viszont így is 1,5%-kal gyorsabb.

Amint látszik, a cc65 fordító "nem teljesen értette" a feladatot, nem tudta absztrakt síkon optimalizálni, így a legbelsőbb rész assemblyben való megírása 2,5-szeresen odavert. Az időkritikus és legbelsőbb részeket érdemes itt assemblyben kézzel megírni.
GCC esetén ARM és x86 architektúrákon szerencsére jobban maszírozható C-ben a fordító, ott mindössze 1,05 körüli nyereséget tudok általában az assembly belsővel elérni, így ott általában nem érdemes assemblyben újraírni belső részeket.

bench.c -t is keresőtáblásra írtam át. Ez 26 időegységnyi nyereséget hozott ott is (1001 -> 975).

A 46. sorban a CLC utasítást kihagyhatod; elméletileg kellene, de gyakorlatilag mivel egy 8-bites értéket forgatsz kétszer felfele, a közvetlenül előtte lévő ROL ki fogja törölni mindenképpen. Úgy már csak 399 ticks. Kicserélheted mindhárom TXA / AND #$XX párost is (37, 66, 86) XAA #$XX utasításokra, viszont az XAA-ra azt írják, hogy egyes gépeken kiszámíthatatlan; VICE-ban működik és ez így már csak 389 ticks. Ha az XAA használatát eldobjuk mindkettőnk kódjából, akkor mindkettő 399 ticks.

8-bites CPU-n mindig is ASM-ben kellett megírni a sebességkritikus részeket, ez ma sincs máshogy. A mai CPU-kon, ha nem is kell konkrétan ASM-ben, de érdemes megnézni milyen ASM kimenetet ad a C fordító és újragondolni időnként a snippeteket; geza42 tud erről sok tippet adni.

Ebből is látszik, hogy 8-bites CPU-n, ha C-ben is programozol, érdemes ASM-ben gondolkodni; egy modern CPU-n nincs kardinális különbség egy shift és az indexelés között (sőt a shift lesz gyorsabb), de 6502-őn, ahol nem az összes shift történik meg egy ciklus alatt, ott számít.

Oldschool Computer - http://oscomp.hu

Hát, az enyémben így volt már a múltkor is, csak felcserélve az eleje, meg a vége, szóval nem indokolt a többes szám. :)

	tax			; X = y;
	ldy	#$00
	sty	ptr1+1
	and	#$f8
	sta	ptr1		; <- rowX8 = y & 0xf8;

vs.

	tax		; utolsó (y) paraméter acc-ban jön, kell még alább
	and     #$F8
	sta	ptr1    ; LO 1x

	ldy	#$00
	sty	ptr1+1  ; HI=0  --> ptr1+1:$ptr1 abszolut indirekt

Én az Y és a ptr+1 kinullázását a maszkolás előtt csináltam, te utána.

Sz*rk: Egyébként a 67. sorban az

	lda	(sp),y
	tax

helyett nyugodtan lehet

	lax	(sp),y

-t is használni, mert az speciel egy stabil illegal instruction és ugyanazt csinálja. (Nem tudom, hogy rá lehet venni, hogy a ca65 megegye, de mindenesetre, ha nem, akkor

.byte $b3, sp

Oldschool Computer - http://oscomp.hu

Viszont ami felett meg én siklottam át: most esik le, hogy te azért tároltad az akkumulátort a forgatások végén, mert a direkt cím helyett azt forgattad...hát ezt már ki kellett volna szúrnom, de jobb későn, mint sárgadinnye. :/
Átírtam én is arra a sajátomat, így már csak 372 ticks. http://oscomp.hu/depot/asmfunc.s

Sz*rk: Ha átemelem az általad leprogramozott incsp2-t, akkor csak 365 ticks.

BTW:

;	jmp     incsp2  ; ne ugorjunk, programozzuk le
	clc
	lda	#$02
	adc	sp
	sta	sp
	bcs	@end    ; ritka eset, hogy ugrik
        rts		; itt a vége általában
	inc	sp+1
@end:	rts

Itt az @end címke rossz helyen van, egyel feljebb kéne, hogy legyen. (Így már csak 364 ticks.)

Oldschool Computer - http://oscomp.hu

Nálam ment VICE-ban, de igazából egy cseppet sem lep meg, hogy nálad meg nem megy; a XAA hírhedten instabil (sajnos, mert amúgy nagyon hasznos utasítás lenne).

Mindenesetre, ha nem megy valami algoritmusból, majd megy táblából: http://oscomp.hu/depot/asmfunc.s
A következő műveletet ((y & 0xf8) * 40) | (y & 0x07) ugyanis fel lehet írni szépen két db. 256 elemű táblába (_lower256 és _higher256), minek eredményeképpen, csak az x & 0xfff8-cal való összeadás marad és 294 ticks-ig sikerült is lemennünk.

Alternatíva, hogy ha az 512 byte-nyi táblaadat túl sok lenne (C64-en ez nem lenne meglepő), akkor ki lehet táblásítani csak a (y & 0xf8) * 40 értékét is, ugyanis, mivel annak az alsó 3 bitje úgyis repül, valójában csak 32 eredményünk lehet. Ez így mindjárt csak 64. byte, viszont 321 ticks. Ha a 64 byte még mindig sok lenne; az alsó byte a táblában úgyis csak azt ismétli, hogy $00, $40, $80, $c0, azaz a magas érték beállítása után elég egy and #$03 és a tábla 4. byte-jától kezdve kidobható, 32 helyett csak 4 byte marad belőle, azaz a két tábla úgy 64 helyett csak 36 byte-ot foglal. Viszont így 325 ticks lesz a végeredmény. (Egyébként az alsó byte megbízhatóan mindig az y 4. és 3. bitje felforgatva 7. és 6. bitnek, szóval akár tábla sem kell hozzá, de egyrészt úgy 331 ticks lesz, másrészt meg a kapott kód többet foglal, mint a 4 byte-os tábla, meg a két byte-os and művelet...)

Oldschool Computer - http://oscomp.hu

( arpi_esp v | 2021. 05. 28., p – 21:12 )

a linux kernelt le tudja mar forditani ra? :)

( hnsz2002 v | 2021. 05. 29., szo – 07:34 )

Ha nem tudom mi az llvm, akkor a cikk nem nekem szól? :)

"Sose a gép a hülye."

( uid_21476 | 2021. 06. 01., k – 10:57 )

HELP ME, HELP ME please, please, pleeeeaaase!

Azt szeretném megtudni, hogy ezek a régebbi procik, mint a 6502 is, emulálhatók-e kereskedelmi célzattal?

Gondolok itt arra, hogy egy kontrollerben futna az emuláció és a külvilág felé ugyanúgy meglennének a kivezetések, tehát a teljes kontrollbusz, címbusz, stb.  Szóval, hogy gyakorlatilag be lehetne vezetékelni egy kézzel fogható 6502 helyére.
Azért kérdezem, mert pl. a hosszú ideje készülgető commander x16-ban, de még a Gigatron TTL cpu-ban is van 6502 emuláció. Szóval, ezek a projectek szerintetek, hogyan, miként oldják meg ezt a kérdést?  

Mert az rendben van, hogy valaki ír egy ilyesmit, hobbi célzattal, közzé is teszi és nem rugják rá az ajtót, mert hát, miért is tennék?

Na de aki értékesítési célzattal teszi ugyanezt, mint a fentebb említettek is, azokkal mi van? Egyáltalán, mi lehet?

 

"...Soon after the 6502's introduction, MOS Technology was purchased outright by Commodore International, who continued to sell the microprocessor and licenses to other manufacturers. In the early days of the 6502, it was second-sourced by Rockwell and Synertek, and later licensed to other companies.

In its CMOS form (the 65C02, which was developed by the Western Design Center), the 6502 family continues to be widely used in embedded systems, with estimated production volumes in the hundreds of millions.[4].."

https://en.m.wikipedia.org/wiki/MOS_Technology_6502

-szal végig kell túrni, hogy jelenleg kinél vannak a licencjogok és az mit ír elő. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( uid_21476 | 2021. 06. 01., k – 11:48 )

Szerkesztve: 2021. 06. 03., cs – 02:06

Köszönöm a segítséget.

Nos, én feltételeztem, hogy az USA-ban talán úgy néz ki ez, hogy a védettség csak bizonyos időtartamig szól, azt követően szabad prédává, közkinccsé válik, vagy legalábbis válhat a dolog. Ahogy pl. nálunk ma már József Attila műveit bárki bátran megjelentetheti, stb.

Nem-e valami ilyesmi teszi lehetővé, hogy a két említett projekt is fel merte vállalni az emulációt. 
Ráadásul, itt emulációról van szó, nem is gyártásról. Bár ez a jogtulajdonos számára irreleváns.
Olyan viszont mintha rémlene, hogy az intel erősen markolja az x86 utasításkészletét és nem engedi azt pl. ARM-on emulálni.

De most nézem csak az utolsó mondatodat, hogy talán a licensz kitér ilyesmire. Mégegyszer, köszönöm.