Welcome, Guest. Please login or register.


Author Topic: NICK (Read 103539 times)

Offline geco

  • EP addict
  • *
  • Posts: 5430
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: NICK
« Reply #390 on: 2015.December.20. 08:21:33 »
Én kizárt dolognak tartom, nagyon meglepődnék, ha lenne ilyen.
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.

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 47.0.2526.73 Chrome 47.0.2526.73
    • View Profile
    • Honlapom
Re: NICK
« Reply #391 on: 2015.December.20. 10:20:05 »
én nem vagyok hardveres, nem értem konkrétan mi az a dma, de a nick képgenerálása az miért nem dma?
Vigyázat! Szektás vagyok! :)

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 43.0 Firefox 43.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #392 on: 2015.December.20. 11:52:55 »
én nem vagyok hardveres, nem értem konkrétan mi az a dma, de a nick képgenerálása az miért nem dma?

Vegulis szigoruan veve az is lehet DMA, igazad van. Csak ugye az altalaban mindenhol kb adott (na jo ZX81-nel erdekes mert ott a CPU igencsak kell a kepalkotashoz is ...), szoval altalaban azt kipipaltnak vesszuk :) Viszont az regen nem volt olyan szokasos, hogy mas is a CPU segitsege nelkul menjen, pl digi hang, meg mas ...

Online Zozosoft

  • EP addict
  • *
  • Posts: 13533
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 43.0 Firefox 43.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #393 on: 2015.December.20. 12:08:08 »
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.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13533
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 43.0 Firefox 43.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #394 on: 2015.December.20. 12:10:02 »
Viszont az regen nem volt olyan szokasos, hogy mas is a CPU segitsege nelkul menjen, pl digi hang, meg mas ...
Ha jól tippelem ez elsőként az Amiga vivmánya? Később meg PC-n Sound Blaster.

Egyébként meg Z180-ban van DMA, majd azzal játszhattok ilyet :-)

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 47.0.2526.73 Chrome 47.0.2526.73
    • View Profile
    • Honlapom
Re: NICK
« Reply #395 on: 2015.December.20. 12:21:44 »
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 :)
Vigyázat! Szektás vagyok! :)

Offline ergoGnomik

  • EP lover
  • *
  • Posts: 841
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
Re: NICK
« Reply #396 on: 2015.December.20. 13:00:19 »
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 itt egy nagy ostobaság. Ne is olvassátok el!

Az automatizált funkciók mindig igényelnek hardver fejlesztést. Akkoriban még eléggé meg volt kötve az áramkör tervező mérnökök keze, hogy mennyi tranzisztort integrálhatnak egy lapkába anélkül, hogy súlyosan veszteséges legyen a gyártása.

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?
« Last Edit: 2015.December.20. 13:20:25 by ergoGnomik »

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 43.0 Firefox 43.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #397 on: 2015.December.20. 13:22:37 »
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.

Quote
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.

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 47.0.2526.73 Chrome 47.0.2526.73
    • View Profile
    • Honlapom
Re: NICK
« Reply #398 on: 2015.December.20. 13:37:28 »
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

Vigyázat! Szektás vagyok! :)

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 43.0 Firefox 43.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #399 on: 2015.December.20. 17:43:07 »
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 ...

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 47.0.2526.73 Chrome 47.0.2526.73
    • View Profile
    • Honlapom
Re: NICK
« Reply #400 on: 2015.December.20. 18:03:47 »
annyit nem ér ez hogy ennyit beszélgessünk róla :D
de azt nem értem miért kéne nagyon nagy lpt neki? hány sor lehet max az lpt, 300? sok játéknak és a legtöbb demonak soronkénti lpt-je van, az is elég nagy (mondjuk 200 sor)
Vigyázat! Szektás vagyok! :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #401 on: 2015.December.20. 18:24:41 »
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.

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 47.0.2526.73 Chrome 47.0.2526.73
    • View Profile
    • Honlapom
Re: NICK
« Reply #402 on: 2015.December.20. 18:31:08 »
De az csak 1/50 másodperc hang lenne. :)

nyilván frissíteni kell folyamatosan ezt a "buffert" ahogy amúgy minden más, mai modern rendszerekben is (csak ma már sokkal nagyobb lehet ez a buffer ügye). nem értem mi ezzel a gond.
Vigyázat! Szektás vagyok! :)

Offline balagesz

  • EP user
  • *
  • Posts: 265
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: NICK
« Reply #403 on: 2015.December.20. 19:00:46 »
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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #404 on: 2016.March.03. 09:36:35 »
Igy igen erdekes, hogy ket a szam-"csoport" pont meg van cserelve Xep128 es ep128emu kozott, azaz lehet hibasan hasznalom a level szintet a VINT-nel :-P Legalabb meg valami kiderult, hmmm. Alakul ...

Itt lehet hiba a nick.c-ben (570. sor):
Code: C
  1.                                 dave_int1(!vint);
Az INT1 bemenet nem invertált, azaz a megszakítás valójában a VINT-es LPB után történik.