Btw, en ezeket nezegetem, CPC wiki alatt, I/O-rol osszefoglalas:

http://www.cpcwiki.eu/index.php/I/O_Port_Summary

Floppy vezerlesrol:

http://www.cpcwiki.eu/index.php/765_FDC

Amugy jo ez a CPC wiki, segit azert sokszor, pl memorialapozasos dolgoknal is ezt nezegettem!

Mindenesetre újra elkezdtem elmélkedni a DMA-s EXDOS kártyán

A DI-EI mindenképpen kell az átvitelhez.

Van is a kodban par helyen DI...EI, ahogy nezem Meg a keyboard scannel is, az pl EP-nel szerintem nem kell. CPC-n valszeg azert, mert ott mindenfele elbonyolitott modon van raakasztva a kbd matrix, es elobb fel kell programozni a megfelelo eszkozoket az adott adatiranyra miegymas (gondolom), EP-n felteve ha mas process nem akar kbd-t scannelni (szerintem SymbOS-en egy process vegzi es azzal kommikal minden mas), akkor ez nem gond, tehat itt egy "megakaszto tenyezo" azonnal letudva

Ha lehet némi "darabosság", azaz mondjuk 2-3 időszeletet is rászánunk a szektorműveletre, úgy már meg lehet csinálni, és az említett ID olvasás trükkel lehet finomítani.
Mondjuk összességében egész biztos, hogy jóval lassabban fogja kezelni a lemezeket mint az EXDOS, mivel nem tud szektorblokkokat olvasni, és a sima szektornál is várni kell mire a driver meg a lemez pont alkalmas pillanatban találkozik.

Hat, mindennek ara van, a multitasking mindenkeppen lassit, hiszen overhead-et jelent az, hogy idonkent megszakitva van vmi. Meg akkor is, ha semmi nincs benne ami idozites specifikus mint pl disk sector olvasas, es mas process eppen nem akar futni, akkor is a scheduler jon 1/50 masodpercenkent es megvizsgalja mi a szitu, es ha vmi varazslat folytan mas nem is akar futni, akkor is ido kell mar ehhez is eleve.

Igen, ezen en is gondolkodtam ("lassu lesz"), hogy ha SymbOS single sectort-t olvas (a kod alapjan ugy tunik ...) akkor a kov sectorhoz varni kell amig a lemez korbefordul. Nem tudom. Lehet, eleve interlaved modon volt CPC-n a szektor kiosztas, igy a kov sector a disken nem fizikailag utana jon pont? Illetve, bovitesi lehetoseg: ha van eleg RAM, lehetne bufferelni a kov sectort is ha epp ugyis "keznel" van, es foleg, ha tudjuk (hmm, ezt azert nem egyszeru megmondani), hogy kell a kovetkezo is, akkor le lehetne tarolni, es ha read jon ra, mar ki lehet szolgalni. Ezzel eljutottunk a modern OS-ek disk cache fogalmahoz, amikor a nem hasznalt RAM-ot automatice disk cache-kent utilizalja (anno meg 2000 elott mindig panaszkodtak ismerosok hogy sz** a Linux, alig van/nincs szabad RAM! Azt nem ertettek, hogy a RAM eroforras; az a jo, ha tokig ki van hasznalva, kulonben minek van a gepben, ha csak uresen all? Nyilvan a kernel atadja app-nak es nem kezeli tobbe cache-kent, ha valakinek meg RAM kell ... szoval egy modern OS-t irni azert nem egyszeru, van benne trukk ezerrel egy csomo, es meg az x86 es hasonlo hw-k adta lehetoseg pl lapvedelem, CoW - Copy On Write - stb dolgok hasznalatarol meg nem is szoltunk, ez utobbi viszont mar nem Z80 tema erosen, a disk cache elvileg lehetne meg).

Az is baj, hogy jokat talalgatunk, de valojaban a SymbOS szerzoje nyilvan pontosabb valaszokat tudna adni Azert az erezheto, hogy ahogy egy doksiban is van: azert alap gep hiaba kiraly a SymbOS igen szukos neki, 128K RAM pl szinte semmire nem eleg normalisan dolgozni vele, illetve vmi SymbiFace vagy mi nevu hw is van amin RTC, IDE stb CPC-re (CPC wiki-n ott van valahol, az I/O port summary-ban is emlekeim szerint). Tehat az oke, hogy alap CPC-n es nyilvan alap EP-n is elfut(-na), de az eleg minimal neki mar, es talan kenyelmesebb hasznalatahoz azert tobb kell. Vegulis, tegyuk szivunkre a kezunket, meg multitask nelkul EXDOS-szal is mindenki SD kartyara vagyik mar, es esetleg kevesbe preferalja a floppyzgatast, az ido szava meg a regi gepeket sem hagyja erintetlenul ... Arrol nem is beszelve, hogy anno CPC/EP stb fenykoraban valoszinuleg nem is igazan jutott volna meg eszebe senkinek mikrokernelt meg ilyen modernebb OS fogalmakat alkalmazni sehol, meg nagyobb gepeken sem igazan, vagy csak elvetve legalabbis ...

Ami még kérdés: CPC-n mi történik a DI alatt érkezett megszakítással? Mert nálunk ugye eltárolódik a Daveben, és EI-nél aktivizálódik. Így ha kicsit kicsúszunk az 1/50 időből, még nagy baj nem lesz.
Mondjuk CPC-n meg ott 300Hz, így ott is tud hamarosan pótlódni.

Jo kerdes, passzolom A mostani felig EP-s SymbOS ganyolasom (ugye JSep alapbol EP emulator, Nick-hez LPT-hez - azokat inicializalom magam a snapshot alapjan amit szinten en gyartottam -, memorialapozashoz nem nyultam, ami most ganyolva van benne az atiras miatt az az I/O port-ok CPC szerinti ertelmezese, meg par ilyen kisebb dolog) peldaja okan azt csinalom, hogy atirtam ahova az rst 0x38 mutat. Eloszor is kiirtottam ezt a 300Hz/6 varakozast, mivel eleve 50Hz-unk van, VINT-bol. Aztan  nyomok azonnal egy dave latch reset-et mar az elejen. Igy mukodni latszik, jelenleg a berhalt JSep-vel elindul a SymbOS, a kicsit atirt kbd scan koddal pedig tudom mozgatni az egerkurzort, csak ugye ha valamit megprobalok elinditani, akkor ablakot kirakva (ezt mar kuldtem egy regebbi hozzaszolasomban) kozli velem, hogy disk error, ami nem is csoda, mert meg nincs kesz Lehet, EP-n a kritikus szekciot amugy nem eleg vedni DI-EI-vel hanem Dave VINT (azaz INT1) enable/disable kene inkabb helyette?

Amugy visszaterve EP-hez: en azt gondolnam, hogy igazi "EP-only" OS eseten vagy meg kell tartani az EXOS/EXDOS-t es raultetni vmit (ez szerintem az EGI iranyvonala), esetleg nemi multitasking bevetesevel (ahol EXOS funkcio futasa eseten nyilvan nincs process valtas), vagy irni nullarol (na ez nem lenne kis melo) egy uj EXOS-t ami eleve tud ilyesmiket is. Azt persze, hogy ez kompatibilis legyen, nehez v szinte lehetetlen megcsinalni. Gondolok itt pl arra, hogy nem igazan van lehetoseg (a kompatibilitas megtartasaval!) hogy pl ne egy szem rendszerszegmenst turkaljon mindenki egyszerre, vagy ne is nyuljanak hozza, es legyen az az EXOS maganugye belsoleg. Stb. Az is lehet, hogy ilyen jellegu OS eseten kvazi nem igazan realisztikus megtartani az eredeti EP software-ek futtatasat ilyen kornyezetben, ha ilyeneket (pl exos-5 fejlec) futtat vki, akkor az monotaskingra atall, de be lehet vezetni uj fejleccel megaldoitt sw-ket, amire szigoru eloirasok vannak, hogy mit hogyan szabad neki es mit nem, es azokat pl lehetne vhogy parhuzamosan is futtatni akkor, es akkor nincs kompatibilitasi gond, mert ez egy uj "program tipus" lenne. Viszont erosen vitathato, hogy lenne-e ertelme, azert olyan nagy erdeklodes nem lenne ra ... A SymbOS olyan szempontbol jo, hogy mar tobb gepen is megy, es az app-ok hordozhatoak is kb, es EP-nel (sajnos ...) nepszerubb gepeken is fut. Viszont egy EP only uj OS haaat ... nem tudom

Ti biztos értitek mit jelent mindez, de két szóban elárulnád hogy miért volna jó egy DMA -s EXDOS ?

(Eccerűen ... "felhasználói" szempontból ...)

DMA a Direct Memory Access (asszem) roviditese, es arra utal, hogy nem a CPU vegez memoriamuveletet. Azaz, pl megmondod a floppy controllernek, hogy akarod ezt a szektort, DMA vezerlovel egyezteted, hogy majd lesz szives elkerni a controllertol es ide es oda lerakni a memoriaba aztan. A Z80 meg kozben total mast csinal, "varazslatosan" megjelenik majd a memoriaban a szektor, anelkul, hogy Z80-nak varnia kene ra, es/vagy neki kene az adatokat beolvasnia. Ez egy EXDOS eseten nem feltetlen ertelmes, mert amugy is monotasking (ill max annyi, hogy lehet a DMA gyorsabb mintha a CPU csinalna!), viszont egy SymbOS eseten (vagy barmi hasonlo multitask OS) nagyon hasznos, ugyanis kozben szabadon futhat mas program addig amig a DMA dolgozik, ami maskepp nem lenne lehetseges. Az eredmeny egy SymbOS v hasonlo OS eseten: disk I/O alatt sem "darabosodik" a disk ativeteli sebesseg javul, stb. Amugy hasonlo meg a win95 kornyeken (?) volt, ahol floppy format az hazavagta a dolgokat erosen, mert (nem ertek a windows-hoz, tippelek, es ezt a gondot is onnan tudom h haverok mergelodtek mindig) kozben a OS talan BIOS funkciokat hivott 16 bites modba valtva addig, es felfuggesztve a multitaskingot. Ha ez az elmeletem a win95 kapcsan igaz, akkor az a vicces szitu, hogy ez teljesen hasonlo lenne, mint amikor a SymbOS-t megprobalnank EXOS/EXDOS funkciokra raultetni a sajat hw szintu driverei helyett (ahogy ott BIOS-t hivott hw kozeli sajat lekezeles helyett).

Ok, és minek nekünk HD -s lemez ? Vagy még a winyo/SD -knél is fáj nekünk a z80 memcopy ?

Úgy értem az LDIR -es SD már tényleg álom sebességű ... még nagyobbat akarsz álmodni ?

Jo, hat ha nem koveted a melylelektan OS ismeretek cimu eloadasomat, akkor nem erted SymbOS eseten erosebb a lassulas mint EXDOS eseten mert multitask OS, mast is csinalnia kell, lecsuszhat dolgokrol es tovabb kell varni stb, itt tobbet segitene a DMA. EXDOS eseten a gyorsulas talan kevesbe kritikus, mert o amugy is csak var amig nincs kesz, mas dolga nincs (multitask OS-nel lenne boven!). Marmint hozzaszolasom most csak az atviteli sebessegre vonatkozik mono es multitask OS versus DMA esetre. A HD-s floppys kerdest majd Zozo tudja, lehet a 4MHz-es Z80 lassu hozza hogy LDIR-el is bekerje? Az, hogy miert kell HD floppy az meg passz, en eleve nem is floppyzgatnek mar, de tudom, en ilyen problemas eset vagyok, hogy keverem a modernt a retroval

Amugy legfuturisztikusabb otlet DMA/eleg memoria eseten: readID-el lekerdezzuk hol vagyunk aztan (nem tudom FDC engedi-e WD ill a CPC-s NEC eseten) onnantol a teljes savot bezuzzuk memoriaba. Aztan ha ugyanarrol a track-rol kell adat, akkor memoriabol adhatjuk (figyelem, ha sector iras van, nem art a disk cache-t ervenyteleniteni vagy ott is atirni ... az mar az advanced hozzaallas netovabbja, hogy delayed write is legyen, azaz ne irja azonnal disk-re csak ha osszegyult tobb valtozas vagy sok ido eseten nem volt tobb irni valo - ez viszont azzal jar hogy a floppy-t nem illik barmikor kivenni hanem szabalyosan le kell valasztani, ez gondoiom pl pendrive eseten mindenkinek ismeros - Mac-eken regen - most nem tudom - nem is volt mechanikus kiado gomb, mert ne vedd ki a lemezt, ha tartalma meg inkonzisztens lehet! Amugy FAT eseten ez hasznos mert pl irasnal ossze-vissza ugralni kell az adatblokk felirasa majd FAT update-elese kozott, bar igaz a FAT minden csak nem koreszu filerendszer ...).

Mondjuk az lenne a szep DMA-s floppy stb eseten, ha barhova a fizikai RAM-ba tudna DMA-zni. Azaz nem csak oda, ami eppen Z80-nak be van lapozva. Azt viszont nem tudom, hogy a 22 bites EP cimbusz felso 8 bitje ami a dave 4 "lapozo" regisztererol jon (B0...B3) levalaszthato-e buszrol, azaz azt mondd a Dave-nek hogy tegye magas impedanciaju allapotba a kimeneteit, es hagyja beken a buszt szepen. Pedig ez lenne a szep, ugy Nick modra: ugye Nick is olvassa LPT-t, videoram-ot stb (voltakeppen DMA-zik, read-only modban allandoan!) akkor is, ha egy VRAM szegmens sincs belapozva Z80-ra. DMA-nal is jo lenne, ha szabadon DMA-zhatnank barhova, Z80 szegmens lapozasatol fuggetlenul a Dave altal.

Lehetne meg fokozni, de szerintem kisse elszaladt velem a lo

Ennek nem lenne ertelme: a disk-nek egy feje van (na jo, ket oldalas eseten ketto, de akkor sem tud egyszerre mindkettovel olvasni v irni), egyszerre akkor is csak egy dolgot tud olvasni, de meg egy SD kartya is egyszerre egy parancsot szolgal ki ...

2 SD kártya 4 winyó kombó ?

Ok, és minek nekünk HD -s lemez ?

Nekem azért mert szeretem a floppyt Az még olyan ember közeli periféria, lehet látni, hallani hogyan dolgozik. A flancos modern dolgokon, mint az SD kártya még egy LED sincs