én nem vagyok hardveres, nem értem konkrétan mi az a dma, de a nick képgenerálása az miért nem dma?

CPC +-on van már DMA, de az ugye 90-es évek környékén jött ki, ha jól emlékszem, akkor 1989.

De ott meg digi hang nincs ha jól tudom.

na de erről beszélek... "akkor még nem volt divat" - a fő kérdésem tehát hogy csak ennyi, hogy "nem jutott eszükbe", vagy komoly hw fejlesztés is kellett volna pl ahhoz hogy a nick ha már szépen felolvassa a memóriát és képet csinál belőle, akkor mellékesen 1 byte az lpt-ben mehetett volna egy DA-ra is

amúgy a régi tévéken hangja volt a képnek is, ha felhangosítottuk a tévét, a képernyő tartalmától függően cicergett

DMA-ról (legjobb tudomásom szerint) akkor beszélünk, ha az operatív tár a forrás vagy cél memória, és a művelet célja adatátvitel. A videójel generálásnak nem célja az adatátvitel, mivel nem kerül át más helyre az olvasott adat másolata, illetve dedikált videómemóriában történik.

Ez igy nem teljesen pontos. A DMA alapvetoen olyan adatatvitel amit nem a CPU vegez. Es vegulis memoriabol olvasas, majd abbol videojel kepzes valami absztrakt modon rafoghato, hogy az. A forras itt is memoria, raadasul a Nick eseten a VRAM ugye nem feltetlen teljesen dedikalt, hiszen a CPU is el tudja erni (nem igy pl az MSX-en, ahol csak I/O portokon at mondod meg, hogy mit szeretnel csinalTATni te, mint CPU a videomemoriaban, kozvetlenul nem tudod elerni "nativan"). Amugy a hatarvonal valoban nem mindenesetben kristalytiszta.

Viszont az LPT-s "DMA" hangkeltés megszerintem szinte teljesen hasznavehetetlen lenne, ugyanis a programozási modellje egy katasztrófa. Szerinted jó ötlet, hogy a memóriába szanaszét szórva hevernek a hangminta adatai, ráadásul az LPT előnye, hogy egy LPB-vel több videósort is le lehet írni pont ellentétes a hanglejátszáshoz szükséges egyenletes adatáramlással?

Ezert irtam azt, hogy nem magaban az LPT-ben lenne a sample. Hanem hasonloan ahogy a videomodok hasznaljak az LD1/LD2 erteket hogy az altal olvassak a memoriat, lehetne egy LD3 ami a digi sample-re mutat, es onnan olvassa akkor amikor van ra eppen ideje (pl a targyalt utolso 3 nick slot alatt, felteve ha nem lenne ott a vram dram refresh ugye, amit akkor valoban csinal a nick). Ez kb ugyanaz, mint ahogy a pixel adatok sem az LPB-kben vannak valojaban, az LPB-k max leirjak mi az LD1/LD2 erteke, ahonnan a Nick majd olvassa.

nekem nem kellett volna hogy tökéletes legyen a megoldás, ha lpt-ben van a sample, nekem az is jó lett volna, és hogy ehhez soronkénti lpt kellett volna
játékokban, demókban oké lett volna így is

Ezt tovabbra sem ertem Marmint az otletedet. Az irtozatosan nagy LPT lenne, gondolj bele. Es a keptartalomhoz is osszekompanlni ... siman nem erne meg. Foleg hogy a Nick amugy is az LPB-kben levo pointerekkel operal, nem tudom miert szeretnel ilyen nyakatekert megoldast, meg csak nem is tul logikus ...

de azt nem értem miért kéne nagyon nagy lpt neki? hány sor lehet max az lpt, 300?

De az csak 1/50 másodperc hang lenne. Csak a hang miatt pedig pazarlás lenne az LPT méretét tovább növelni. Ezért célszerűbb a külön (pl. I/O porton keresztül állítható) olvasási cím használata amikor a soron belül van rá idő, például statikus video RAM esetén az utolsó 3 karakter felszabadulna 6 byte olvasására.

Ezért célszerűbb a külön (pl. I/O porton keresztül állítható) olvasási cím használata amikor a soron belül van rá idő, például statikus video RAM esetén az utolsó 3 karakter felszabadulna 6 byte olvasására.

Ha már "álmodozunk"... Ezt talán úgy lett volna értelme megcsinálni, hogy a DAVE maradjon csak a hangnál. A NICK olvashatná neki az adatot. Ehhez azért néhány ponton módosulna a jelenlegi felépítés... Azt lehetett volna csinálni, hogy a DAVE is be kellett volna hogy kerüljön a "belső", NICK-hez tartozó memóriabuszra. Hátrány lett volna, hogy a DAVE regisztereinek a piszkálásakor is lett volna órajel-nyújtogatásos késleltetés, de ez talán még elmegy...

A DAVE-ben kellett volna egy plusz időzítő, amivel a playback frekvencia állítható. Meg kellett volna egy kimeneti láb, ami azt jelzi a NICK felé, hogy kellene a következő adat a D/A felé. Meg egy bemeneti láb, ami jelzés, hogy "itt az adat".

A NICK-ben kellett volna egy plusz pointer az LD1/LD2-n felül, de ezt az I/O tartományon belül kell elérni, semmi köze nem kell hogy legyen az LPT-hez. Ezen felül egy BYTE-számláló kell, meg a sallangjai egy pufferes olvasáshoz. Kell egy bemeneti láb, ami a DAVE felől jövő "következő D/A adat kell" jelet fogadja. Ha ez aktív, akkor a NICK egy "éppen nem használt Z80 ciklus" alatt végrehajthatja a memória olvasást. Illetve kell még egy kimenet a DAVE fele, amivel jelzi, hogy az éppen zajló memória ciklus végeredménye neki szól.

Ebben a felállásban összesen két plusz láb kellene a NICK/DAVE részéről is, ez még akár bele is férhetett volna. Így már nem tűnik annyira komoly feladatnak a dolog, de az azért simán lehet, hogy nem lett volna rá hely a csipeken belül.