oscomp.hu

Csak... en nagyon makacs embernek szulettem. Ami az evek alatt alabbhagyott, mert sokszor jobban fajt a fal, amin at akartam torni, mint amit elkepzeltem elore...
Szoval gondolkodjunk pusztan elvi szinten es maradjunk kicsik. A fajlrendszert en nem banom egyaltalan, ha a memoriaban letezik csak elsosorban. A sed awk es tarsai nem ugy kene ezek alapjan elkepzelni, ahogy vannak, vagy ahogy megszulettek, hanem alkotoelemeikre bontva megprobalni kifoguralni hogy mikent lehet pl alap regex et par kilobajtban megcsinalni. A C kodja ha jol emlekszem nem tobb par oldalnal. Ha tevedek, akkor.kicsit tovabbi egyszerusitesek kellenek illetve ujrairasok, mert hat ki mondja, hogt a regex forras ami rendelkezeare all a legjobb? Addig van legjobb, amig jobbst nem irunk helyette. Vagy en, vagy Te, vagy mas.
Szoval nekem az tok eleg hogy nehany funkcio elmuzsikal alacsony szinten a memoriaval. Ebbe mar kicsi, de pelda erteku peldak belefernek es oktatasra pl tok jo lehet.
Mellette a memoria lapozas nem egy nagy ugy, bar nem tetszik de a kenyszer ravihet. Vagy ket harom spectrum osszekapcsolasa se a pokolbol valo otlet, ami megint megnyithat bizonyos tavlatokat.
De a legfontosabb szerintem, mint mindig, a technika. Alap file rendszer es navigacio, es nehany utility amit be kell huzni kazirol vagy mashonnan, hogy mukodjon. Illetve fuknciokat is ossze lehetnw allitani es betolteni, linkelni specifikusan a feladatra mert mindek is kene nekem awk szubrutin mikor csak par ciklust akarok futtatni egy par text fileon vagy egyszeru kepanyagon?
Illetve az egesz tar alapbol tomoritve lehetne legalabbis ahol ez kifozetodo ami tobbnyire az adat. Es az adat ae ugy legyen tarolva mint egy brutal buta fat vagy ntsc vagy ext3 ban, hanem meretre optimalizalva mint stacker, jam voltak anno, de lehet abbol is ujat irni es a par szaz k adatbol maris lehet 20k.

Kezdjük azzal, hogy a "natúr" 48k-s Speccy-n nincs értelme a fájlrendszernek, mert az egyetlen "háttértár", amit rá lehet dugni, az a tape. A tape pedig szekvenciális hozzáférésű és nem random. És teljesen mindegy, hogy MP3 lejátszót dugsz rá, vagy eredeti szalagos magnót, mert a szekvenciális hozzáférés marad. Bővíteni persze lehet mindenféle kütyüvel, de ha már bővítjük, akkor már ennyi erővel rá lehet dugni egy Z80000-es "turbókártyát", aztán annyi. De abban mi a Speccy? Nem. A minimum hardware egy bármilyen fájlrendszer alá az olyan, aminek van véletlen elérésű tára. Ennek megfelelően az egyetlen stock modell, ami szóbajöhet, az a ZX Spectrum +3. Valószínűleg ez az egyik oka, hogy a SymbOS nincs original Speccyre. Aztán, valami egyszerű shell-t, meg primitív fájlrendszert persze lehetne írni egy floppy-val bíró gépre, de ahhoz azért nem ártana, ha lenne elég RAM is. Csak emlékeztetőül: C64-en sincs "fájlrendszer", mert ott a DOS a lemezegységben van és van benne külön RAM, meg CPU. Ennek megfelelően egy 48k-s gépen, ahol még a képernyőmemória is lejön a tárból, nem nagyon van esélye normális rendszert felépíteni. Valószínűleg ez a másik oka, hogy a SymbOS nincs original Speccyre.

A dolog második részét viszont, hogy az awk-ot, sed-et, vagy bármi hasonló eszközt te egy ZX Spectrum 48-asra portolj, az megint a sok sikert hozzá kategória. Az utóbbi "csak" ~100k Linuxon, viszont az előbbi az olyan laza 640k; még az MS-DOS-nak is megfeküdné a gyomrát. És megint, ezek az eszközök egy csomó dologban függenek a libc-től, a kerneltől, meg egyéb dolgoktól. Ez még 128k-ban is sok lenne. És ezen nem segítene semmiféle screen-split trükk.

Peldaul. Annak idejen szorakoztam az Euphoria nevu nyelvvel. Iszonyu egyszeru, es emellett teljes grafikus sdk ja van a windowshoz. Szoval gyorsan lehetett vele valami latvanyosat osszehozni. A problemam az volt, hogy oktatoprogit talaljak ami mutatja es begyakoroltatja.bizonyos parancsok mukodeset egy eleg nagy klaszteres linux kornyezetben. Az egesz kornyezet tul draga lett volna beallitani, de egy.ugyes.kis szimulatorral akarmi bemutathato. Szoval ez.volt a cel es egesz.jo lett, bar befejezni igazan nem tudyam, mas prioritasok miatt.

Most a spectrumon hasonloban gondolkodnek, csinalni egy nagyon kicsi (ertsd leegyszerusitett es kis lenyomatu) csonkot, ami pl egyszeru file kezelest mutat be. Listazhatod a filejaidat, valthatsz direktorit, belenezhetsz egy.ket fileba. Mindezt egy, vagy akarhany terminal ablakban. Max fileok 100,.max direktori melyseg 3,.max file hossz mondjuk 100 byte. Ez ha megvan, akkor tovabb lepni sort, regex, awk sed stb eszkozokre.
Mas prpjekt lenne a megoldas Nagyitasa, optimalizalasa. Pl 48kban nagyok q korlatok, de 80 vagy 128kban mar kisebbwk. Ha bedugsz egy microdriveot vagy floppit, neadj isten kazettas.magnot, akkor megno a hatterter. Kaz magno lehet bluetoothos mp3 olvaso is, mert mar van ilyen. Ez.mar kicsor tul megy az eredeti speccyn de akkor emulatorban, a nagyitas reszekent jelenhetne meg.
De kicsinek maradni is oriasi, sztem miutan a spectrum screen 3 reszre oszlik, a felso kettot elvesszuk, oda toltunk progit, alson meg 2 vsgy 3 terminal ablakot, es ott marad 42k memoria adatnak, es.overlay funkcipknak. Talan nem lenne lehetetlen?

Ja,.hat engem maga a feladat is erdekel, talan jobban is, mint a vegtermek. Szoval pl ott egy jo pelda, amit irtal. Ls es filerendszer. Hogy lehetne ilyesmit speccyn megvalositani? Szerintem tobbfelekeppen, es mindenkeppen ujszeru,.ordogien egyedi megoldasokkal. Pl . Mondjuk eloszor is meghatarozzuk,.hogy mi az a minimum ami kene, mire lenne ez.jo, es kb mi a realitasa, kovetwlmenyei. Ha ez.megvan, akkor ennek alap reszeit ki lehetne dolgozni szerintem, majd iterativan optimalizalni.

windows 95: minimum 386sx (32-bites CPU) és 4 MB RAM, windows nt3.1: minimum 386dx (32-bites CPU) és 12 MB RAM, MS-DOS 5.0: minimum 286 (16-bites CPU) és 384 kB RAM. Hogy jött ez ide? Még mindig Linuxos szarok Z80-ra való portolásáról beszélünk és nem arról, hogy mit lehet egy régi 32-bites CPU-ra átírni. És azonfelül az egyes parancsprogramok kódjának portolása önmagában kevés, mert az ugyan lehet, hogy pl. az ls maga a parancs még Z80-on is futhatna, de mi lesz azokkal a dolgokkal, amikre szüksége van, pl. a fájlrendszer, meg a kernel? Scriptingről, meg terminálemulációról nem is beszélve.

Miert ne? Ott vannak a unix utils dosra meg windowsra, egesz 90tol. Semmi multitask, csak a utilityk.

Z80-ra semmiféle Linuxos dolgot nem tudsz portolni, még a legapróbbat sem.

Vilagos. Erdekes lehetne, hogy csak nehany dolgot megoldani. Pl terminalok fussanak egyszerre es linuxos parancsok, scripting. Szoval nem mindent, de valamit.

Nekem is tetszik. De ettől még egy modern oprendszert nem lehet Z80-asra portolni. És ez nem tunyaság kérdése.

Oke! Lenyeg, hogy tetszik. Nekem nagyon :)
Az a komment az interjubol van, csak ramutat, miert is jo ez az egesz retro dolog. Emlekeztet, hogy mashogy is lehet alkotni.

Nem mondtam, hogy nem jó. Azt mondtam, hogy nettó ökörség a Linuxhoz hasonlítani. Leírták, mit értenek preemptíven:

For the task management a combination of pre-emptive and cooperative multitasking has been choosed, which makes different task priorities possible. Pre-emptive means that tasks are interrupted after a certain amount of time by the operating system, in order to share the CPU time with other tasks. Cooperatively means, that a task stops using CPU time by itself. It does it, if it finished its current job or is waiting for a certain event. Because of this combination it is possible to assign priorities. Tasks with a low priority receive CPU time only if all tasks with higher priorities are not currently working.

Magyarán van lehetőség preemptive módon futtatni programot, de cooperative módon is. Viszont akkor lehet rajta olyan cooperative módon futó programot írni, ami sose adja vissza a vezérlést a rendszernek.

A win95 meg egy gigászi szarrakás volt, preemptive my ass, CLI HLT FTW.

Az tény, hogy sok lusta balfasz van a szakmában, aki pazarolja az erőforrásokat, csak nem tudom hogy jön ide, a Linux@Z80 témához.

Ez a megjegyzese telitalalat a mai programozok tunyasagarol

Todays computers are so fast, that you usually don’t recognize, if your code is completely unoptimized. If it’s running on your local machine only, that maybe ok, so there is no pressure to learn it anyway.

Itt meg a megalkotoja irja, hogy az alap spectrumra lehetetlen, de a 128k ra megoldhato lenne.

https://distritoentebras.wordpress.com/2017/12/23/interviewing-jorn-mika-aka-prodatron-symbos-creator-and-retro-enthusiast/

Itt kolteszkednek rola, hogy preemptiv is, csak nem annyira stabil: https://www.cpcwiki.eu/index.php/SymbOS

"While the MOS Technology 6502 can not move the stack, the Z80 can freely replace it to any position in the memory, which is more or less a condition for pre-emptive multitasking."

Ha win95 nel stabilabb akkor mar tok jo. Nekem jol mukodott a win95 is, megfelelo patchek es hozzaallas tudataban.

Az attol meg tok jo is lehet. Csak az faj, hogy nincs Spectrumra vagy zx81re.
De a preemptivitason akkor mit erthetnek?
"it is based on a microkernel, which provides preemptive and priority-oriented multitasking "

Ja. Cooperaitve multitaskingot. Merthogy ez is az. A grafikus felülete meg kb. a GEM-mel egyszintű, vagy lehet, hogy valamivel jobb. És az egyes verziói direkt az egyes gépekre vannak optimalizálva. Pontosan azt tudja, amiket én itt az előző posztokban felsoroltam, hogy mit tudhat egy 8-bites gépre írt multitask oprendszer és köze nincs a Linux funkcionalitásához, amiről te beszéltél, hogy portoljunk egy lecsupaszított Linuxot Z80-ra.

Ugy tunik mas is almodott mar multitasking ot z80-on: https://en.m.wikipedia.org/wiki/SymbOS

Uff.

Ha 5 percenként van task-switch, akkor az minden, csak nem multitasking...azonfelül az éppen futó programon felül ott vannak még a háttérfolyamatok is, meg maga a "kernel" is; ezeket 5 perces TSI-vel kiszolgálni, az nettó vicc.

Először is nem feltétlenül foglalnak kevesebb helyet az utasítások; pl. pont a sux86 az, ami - backward-compatibility okokból - egy 8-bites utasításkészlet - pont a Z80 "alapjául" szolgáló 8080 - nyavalyáit hurcolja magával a mai napig, viszont ennek megfelelően az utasítások egy jelentős része is a mai napig 1 byte rajta. (Pl.: push, pop, ret*)
De, még ha feltételezzük is - a gondolatkísérlet kedvéért - hogy a Z80 utasításai kevesebb helyet foglalnak, akkor viszont azt is hozzá kell tenni, hogy Z80-on több lépésből is fog állni egy elemi utasítás végrehajtása, mint egy mai sux86-on. Pl. sux86-on egy - a fairplay kedvéért 16-biten címezhető - 32-bites memóriarekesz értékéhez hozzáadni egy másikat kb. ennyi:

movl ($16384), %eax
add %eax, ($16388)

Ez egészen pontosan 11 byte (a1 00 40 00 00 01 05 04 40 00 00) és akkor még jófejek voltunk a Z80-al szemben, mert nem foglalkoztunk vele, hogy 32-biten címezte ki nekünk a két értéket - ezzel elbaszván 4 byte-ot - hanem a legprimitívebb, legegyszerűbb, leggyorsabb módon oldottuk meg.
Ugyanez Z80-on? 32-bites regiszter ugye nincs, csak 16, tehát két lépésből kell összeadnunk, kezelve a carry-t:

LD BC, (16384)
LD HL, (16388)
ADD HL,BC
LD (16388),HL
LD BC, (16386)
LD HL, (16390)
ADC HL,BC
LD (16390),HL

Ez egészen pontosan 26 byte. Ez több, mint kétszer akkora, mint sux86-on. Akkor szerinted a Linux Z80-ra fordítva mennyivel lenne nagyobb, mint sux86-on?

Ami meg a multitasking shell-t illeti, a shell nem "multitasking". A kernel az, ami multitaskingos lehet. A shell csak mondja a kernelnek, hogy mit csináljon, a shell maga is csak egy task, ami programokat tud elindíttatni a kernellel.
A sakkprogramról meg annyit, hogy annak kb. annyi interakciója van a júzerrel, hogy hova lépjen a júzer, az összes többi az vegytiszta matek, amit egy őrült lehet, hogy bele tud zsúfolni párszáz bájtba. Egy shell, az teljesen más. Annak elsöprő többsége pont az interakcióról és annak lekezeléséről szól. A CBM BASIC 8k-s volt, azt nem tudni, hogy mennyi volt belőle a "shell", de biztos nem 300 byte. És akkor arról még nem is beszéltünk, hogy hiperprimitív volt, BASIC-only, shellnek csak más híján lehet nevezni; az AmigaShell, ami már azért inkább nevezhető shellnek és egy multitask OS alatt futott, az kb. 13 kB volt maga a programkód és nem tudom, hogy még mennyi a memóriaigény, de összesítve tuti nem fért el 16k-ban. És még az is ezer sebből vérzett, nem lehet összemérni egy mai shellel. Ha felrakjuk a KingCON-t, akkor már igen (sőt), viszont akkor már 36k a handler maga és még X kB memória. És ugye itt memóriaigényt alatt per kopf, (értsd per shell instance) memóriaigényt kell érteni. Ergo "multitasking" shell-t 16k-ba...nos, sok sikert hozzá.

Pl a 16k romot ki lehetne hajitani es helyette egy multitasking command shellt belokni. 16k nem sok de ha 300 byteban sakkprogi, akkor...

Az NMI miert nem jo? Nem kell hogy minden szazadmasodpercben switcheljen, eleg 5 percenkent is. Tudom, kis igenyu vagyok :)

A 8 biten nincsenek ilyen boduletes memoria igenyek es az utasitasok is kisebb helyet foglalnak. A Hisoft C fordito is 10k korul volt ha jol emlekszem

Ja, azt kene.

A Linuxból már a legelső 0.01-es verzió is 32-bites CPU-t, MMU-t és messze több, mint 64kB memóriát igényelt. Esélytelen. Pont. Egy Z80-ason meg nem fogsz virtualizálni semmit, örül a szerencsétlen, ha egyetlen programot tud futtatni egyszerre. Nem tudom feltűnt-e, de az első preemptive rendszerek, (a QDOS és az AmigaOS) is 68000-esre íródtak és nem 8-bites CPU-kra. Egy kooperatív, task-switching oprendszert persze meg lehetne rá írni, de akkor azt 100%-ig az aktuális gépre optimalizálva (tehát külön Speccy/Amstrad/Enterprise/stb. verzió).

De az nem baj. En most nem a meglevo linux szirszarokra gondolok, hanem ujonnan irni valamit ami poen es mukodik.
Gondolj minimalis verziora es annak is csak a leg leg leg ... legmininalisabb alfa elotti allapotara. Illetve nem teljesitmeny a cel, hanem pl multi edit tobb ablakban es nemi lajtos progi futtatas itt ott. Gondolj a jail alapu virtualizaciora ahol egy szerencsetlen laptopon akar 1000 hostot is beallithatsz es elindithatsz, de sosem hal be a gep mert omos algoritmusokkal, vagy sajat magad, csak annyit futtatsz egyszerre, ami meg megy.

Az megvan, hogy a Linux kernelnek még a leg-leg-leg-leg-leg-leg-lecsupaszítottabb verziója is nagyobb tárat igényel, mint amit a szerencsétlen Z80-as ki tud címezni egybe? Még ha tudunk is lapozni, szerinted mi sebessége lenne, ha állandóan lapozni kéne? Az is megvan, hogy a Linux kernel elsöprő többségében 32-bites változókat és aritmetikát használ? Szerinted mi sebessége lenne, ha 32 (és 64!) bites műveleteket 8-biten kéne N lépésből végrehajtani? Arról nem is beszélve, hogy Linuxot MMU nélkül használni masszív önszopatás, lehetséges, de aki megpróbálja, szopik, mint a torkosborz. (Alapból ott kezdődik, hogy forgathatsz magadnak, mert a rég behalt μClinux-t leszámítva nem is tudok olyan csapatot, aki MMU-less Linux kerneleket terjesztett volna bináris formában...)
Még sima 68000-esre és 68010-esre sincsen Linux (még 68451-gyel sem); minimum 68020 ÉS 68851, vagy teljes értékű 68030 (tehát nem 68EC030!) kell hozzá. Ennek megfelelően a legelső Zilog, amin a Linuxot elméletileg futtatni lehetne, az a Z80000-es.