Enterprise Forever

:HUN => Hardver => Kijelző => Topic started by: tigrian on 2005.December.23. 00:18:01

Title: NICK
Post by: tigrian on 2005.December.23. 00:18:01
Ide gondoltam a Nick mûködésével, ill. egyéb kép és HW kapcsolatáról szóló dolgok megbeszélését. Ha kéritek, akkor írok róla összefoglalót is.
Title: Re: NICK
Post by: MrPrise on 2005.December.23. 00:22:36
Quote from: "tigrian"
Ide gondoltam a Nick mûködésével, ill. egyéb kép és HW kapcsolatáról szóló dolgok megbeszélését. Ha kéritek, akkor írok róla összefoglalót is.

Szerintem mindenkinek hasznos volna egy ilyen összefoglaló, hogy tisztán lásson. Viszont gondolom mások sem szeretnék hogy ez a bõvítõkártya készülésének a rovására menjen ;-)
Title: Re: NICK
Post by: gafz on 2005.December.23. 00:26:13
Quote from: "MrPrise"
Szerintem mindenkinek hasznos volna egy ilyen összefoglaló, hogy tisztán lásson. Viszont gondolom mások sem szeretnék hogy ez a bõvítõkártya készülésének a rovására menjen ;-)


Hát igen, lassan lesz egy új EP alaplap 2000 MHz-es emulált Z80-nal, 1600*1200 felbontásra képes NICK II-vel valamint 192kHz-en 96 biten mintavételezni tudó DAVE II-vel... :) Nameg az elsõ 8bites Linux... :D Meg esetleg MS-Windows... :wink:
Title: Re: NICK
Post by: tigrian on 2005.December.23. 00:28:39
Quote from: "MrPrise"
Szerintem mindenkinek hasznos volna egy ilyen összefoglaló, hogy tisztán lásson.

Rendben. Azért mondjátok többen is :)  Direkt nem szavazást csináltam belõle, az olyan személytelen...
Quote from: "MrPrise"
Viszont gondolom mások sem szeretnék hogy ez a bõvítõkártya készülésének a rovására menjen ;-)

Az sajna nem ezen múlik most. A tasz-toldozás a "meleg" projekt, abba szólhat bele. De egyiket sem fogja jelentõsen hátráltatni. Attól tehát nem kell tartani, attól viszont igen, ha közben vagy utólag derül ki, hogy jobban tudjátok nálam, akkor morcos leszek  :smt093
Title: Re: NICK
Post by: gafz on 2005.December.23. 00:32:07
Quote from: "tigrian"
Ide gondoltam a Nick mûködésével, ill. egyéb kép és HW kapcsolatáról szóló dolgok megbeszélését. Ha kéritek, akkor írok róla összefoglalót is.


Persze hogy kérjük! (Nyugi, valószínûtlen, hogy jobban tudjam nálad...  :wink: )
Title: Re: NICK
Post by: tigrian on 2005.December.23. 00:37:46
Quote from: "gafz"
Hát igen, lassan lesz egy új EP alaplap 2000 MHz-es emulált Z80-nal, 1600*1200 felbontásra képes NICK II-vel valamint 192kHz-en 96 biten mintavételezni tudó DAVE II-vel... :) Nameg az elsõ 8bites Linux... :D Meg esetleg MS-Windows... :wink:

Ezt most nem értem, miért írtad. A legutolsó "ötleted" szinte már támadás ellenem.  :smt065
Az elõtte levõ értelmetlenség, az az elõttiekrõl pedig legfeljebb egyesek álmodozhattak.
O.K., túlzásokat írtál, tehát nyilvánvalóan poén, de tényleg nem értem, hogy jön ide.  :smt017
Title: Re: NICK
Post by: gafz on 2005.December.23. 00:43:34
Quote from: "tigrian"
Ezt most nem értem, miért írtad. A legutolsó "ötleted" szinte már támadás ellenem.  :smt065
Az elõtte levõ értelmetlenség, az az elõttiekrõl pedig legfeljebb egyesek álmodozhattak.
O.K., túlzásokat írtál, tehát nyilvánvalóan poén, de tényleg nem értem, hogy jön ide.  :smt017


Jaj, melyik ötletem? :oops:
Title: Re: NICK
Post by: tigrian on 2005.December.23. 00:48:00
Quote from: "gafz"
Jaj, melyik ötletem? :oops:

A Redmond-i cég emlegetése...
Title: Re: NICK
Post by: gafz on 2005.December.23. 00:53:23
Quote from: "tigrian"
A Redmond-i cég emlegetése...


 :) Már azt hittem, valamelyik értelmesnek szánt ötletemmel támadtalak.... Csak poén akart lenni...  :oops:  :smt083
Title: Re: NICK
Post by: tigrian on 2005.December.23. 01:04:04
Quote from: "gafz"
Quote from: "tigrian"
A Redmond-i cég emlegetése...


 :) Már azt hittem, valamelyik értelmesnek szánt ötletemmel támadtalak.... Csak poén akart lenni...  :oops:  :smt083

Annak is vettem  :P
<OFF>
gafz kedvéért:
http://www.hospitalityclub.org/~inquis/images/microsoft/TuXperience.jpg
http://owe.fw.hu/
</OFF>
Title: Re: NICK
Post by: tigrian on 2005.December.23. 03:26:12
Okay, csapjunk a lovak közé.
Visszafelé haladok, elõször arról, hogy mi a végcél, milyen jelet is kell elõállítani.
Csak olyan mélységben taglalom, ami a NICK mûködéséhez kapcsolódik, tehát elsõsorban, hogy miért kötöttek a frekvenciák.

Fekete-fehér (vagyis inkább világosságjel csak)
A videojel egy analóg soros jelfolyam. A világosság-információt a jel amplitúdója hordozza. A idõtengelyen pedig...hát ott sokminden van. A bonyolítás oka a megjelenítés miatt van. Két dimenzióra kell ugye leképezni az egydimenziós (pusztán idõ) adatot. Ehhez valamilyen fajta szinkronizálás szükséges. Ezt a soros jelfolyamba "integrálták", mintegy idõmultiplex módon. Egy része az idõnek a hasznos adat, egy másik (jóval kisebb) része pedig a szinkroninformáció.
A megjelenítõ eszköz (a monitor) egyetlen sugarat bocsát ki, azt, hogy az a képernyõ melyik részén okoz fényt, az eltérítése határozza meg.
Így néz ki a monitor eltérítése:
(http://enterpriseforever.com/userpix/3_di39fig03_1.gif)
(Függõleges irányban az eltérítés erõsen kinagyítva.)
Van tehát egy sugarunk, ennek az útját két mágnes ráncigálja folyamatosan, szekvenciálisan, meghatározott rend szerint.
A scanline a hasznos, amíg itt jár a sugár, addig a videojel szerint fényesebb-sötétebb pontokat hoz létre a képernyõn (igen, ferde, a valóságban is, csak jóval kisebb mértékben). A scanline ideje kb. 53 usec. Amikor a képernyõ szélére ér, akkor villámgyorsan visszamegy a képernyõ másik szélére (retrace: visszafutás, ennek az ideje kb. 11 usec), és kezdi elölrõl az egészet.
Közben a függõleges eltérítés pedig lefelé húzza a sugarat (ettõl lesz ferde), csak jóval lassabban, majdnem 20 msec alatt.
Hogy miért ezek a frekvenciák? Van egy minimális értéke, a szem mûködése határozza meg. Ha ennél lassabban menne a sugár, akkor már nem folyna egybe. A maximális értékét pedig a technika korlátozta (a TV szabvány már 80 éves!)
Ráncigálni kell tehát a sugarat, ehhez két eltérítõegység, annak pedig két vezérlõjele van. Ezek fûrészjelek, a vízszintes eltérítésé pl. 53 usec emelkedõ, 11 usec csökkenõ idõvel.
(http://enterpriseforever.com/userpix/3_95x47s00_1.gif)
Ez eddig rendben van, de biztosítani kell, hogy az adónál és a vevõnél a sugár ugyanabban a pillanatban ugyanazon a képterületen legyen (technikai értelemben: az eltérítõjelek szinkronban fussanak). Erre szolgálnak a szinkronjelek.
A videojel és a szinkronjelek együttesét hívjuk kompozit videojelnek. Ennek egy része (egy sor, vagyis 64 usec) így néz ki:
(http://enterpriseforever.com/userpix/3_di39fig05_1.jpg)
Az ábra NTSC jelet ábrázol, ezt találtam hirtelen. A mi szempontunkból csak a soridõ a különbség, PAL-ban 64 usec. A kép alján a szinkronjel kinagyítva.
Egy teljes félképet, vagyis 20 msec-et ábrázoló képet nem találtam most hirtelen a neten, de nagyjából ugyanígy néz ki. Képzeljetek el 600-at ebbõl egymás után, aztán 25-öt, de már csak szinkronjelekkel, a videotartalom ott "blanking level", tehát kioltási szint.

Nem beszéltem még a kioltásról (blanking). Amikor a sugár a képernyõn a sor végérõl az eléjére visszafut, ha ott is bekapcsolva lenne, akkor fényes csíkot húzna maga után. Erre az idõre tehát ki kell kapcsolni, vagyis a videojelben erre az idõre fekete, sõt annál is feketébb jelet (lgb figyelsz? Létezik a feketénél feketébb, legalábbis a videotechnikában :-)) kell elõállítani. A TV készülékek többsége egyébként erre a szintre húzza be a feketét, ezért van az, hogy a látható fekete kép valójában már világosabb a feketénél. Huh, érthetõ?

Egy kép egy adott sora így alakul (színjelek nélkül):
(http://enterpriseforever.com/userpix/3_di39fig01res_1.gif)

A színes képnél a videojel még rondább. Ennek a részleteibe most nem megyek bele, a NICK-hez ez nem kell. Annyit azért röviden, hogy a TV technikában nem RGB, hanem világosságjel és két színkülönbségi jel van. Oka pedig a kompatibilitás a FF TV-kkel. Az egyik kódolásból a másik matematikailag konvertálható.

Mi van még? Ja, az interlace (váltottsoros letapogatás).
Ez csak a sávszélességcsökkentés miatt van. A szem ugye kb. 15 kép/mp-nél gyorsabb képváltást már folyamatosnak érzékel. De ez csak az egyik szempont, az ilyen képváltásnál a villogást azért még érzékeli. Ha azt akarjuk, hogy a villogás is megszûnjön, akkor legalább 45-50 képet kell megjeleníteni másodpercenként.
(Ma már tudjuk, hogy ez is kevés, létezik egy harmadik érték is, ez alatt már nem érzékeljük a villogást, de a szemizmok azért még mozdulnak rá.)
50 egész képet kéne tehát átvinni mp-enként. Ez 20 msec. A PAL videószabvány 625 sort ír elõ. 20 msec alatt 625 sor, egyszerû matekkal egy sorra 32 usec jutna (31,25 kHz, ismerõs szám?). Ez alatt a 32 usec alatt kéne kb. 833 (625*4/3) pontot megkülönböztetni. Ehhez 13 MHz-es jel kéne. A TV kezdetekor (20-as évek) ezt még nagyon soknak gondolták, sok szempontból is. Ezért bevezettek egy "trükköt".
Csak 25 képet viszünk át, ez elég a folyamatos mozgáshoz. Viszont felváltva (fésûszerûen) a sorokat, így a képváltás ténylegesen 50 Hz lesz. Így a villogás kérdése is megoldva.  
(http://enterpriseforever.com/userpix/3_di39fig02res_1.gif)
Elõször egy kép páratlan sorait (piros vonal), aztán fél sorral elcsúsztatva a páros sorait (kék vonal).
Ezzel elérték azt, hogy egy soridõ a duplájára nõtt (64 usec), az összes ebbõl adódó frekvencia pedig a felére csökkent.
Ma már ez az interlace inkább csak nyûg, rengeteg problémát okoz. Jó példa ez szerintem, hogy a szabványalkotók mennyire szûklátókörûen, az adott kor technikai színvonalát célozva csak meg dolgoznak. Nem csoda, a gyártók érdekei mindenekelõtt...
A szgépek (és a monitorok) nem is használják ezt a módszert. Az EP sem, valójában tehát minden második félkép egyforma.

Röviden ennyi a NICK feladata tehát, elõállítani a szinkronjeleket, videojelet, és ezeket egyetlen soros bitfolyamban kiküldeni. A színek bekeverését (pontosabban az RGB-bõl a világosság és színjelek elõállítását) az EP-ben másik cél-IC végzi.

Akkor most jöhetnek a kérdések, folyt. köv., ha tetszett.
Title: Re: NICK
Post by: MrPrise on 2005.December.23. 03:32:15
Quote from: "tigrian"
Akkor most jöhetnek a kérdések, folyt. köv., ha tetszett.

Ez király! :smt023
Majd az ilyen hosszabb írásoknak csinálok külön oldalt.
Title: Re: NICK
Post by: geco on 2005.December.23. 05:20:21
Quote from: "tigrian"
A szgépek (és a monitorok) nem is használják ezt a módszert. Az EP sem, valójában tehát minden második félkép egyforma.


Jól értem?
Minden páros sor megegyezik a páratlan megfelelõjével a számítógépek képmegjelenítése esetén? Vagy teljesen eltévedtem a sörözés után?

Quote from: "tigrian"
A színek bekeverését (pontosabban az RGB-bõl a világosság és színjelek elõállítását) az EP-ben másik cél-IC végzi.

Akkor most jöhetnek a kérdések, folyt. köv., ha tetszett.


Gondolom ezt a TV modulátor végzi, EP esetében nem túl jo hatásfokkal.
Title: Re: NICK
Post by: tigrian on 2005.December.23. 06:04:26
Quote from: "geco"
Quote from: "tigrian"
A szgépek (és a monitorok) nem is használják ezt a módszert. Az EP sem, valójában tehát minden második félkép egyforma.

Jól értem?
Minden páros sor megegyezik a páratlan megfelelõjével a számítógépek képmegjelenítése esetén?

Nem, ez csak a kompozit (összetett) videojelet elõállítókra vonatkozik. Durván leegyszerûsítve, amiket TV-re terveztek. Ahol 30 kHz feletti sorfreki van, az már progresszív szkennelésû, vagyis a sorok egymás után vannak, egy képen belül, félképek meg nincsenek.
Quote from: "tigrian"
A színek bekeverését (pontosabban az RGB-bõl a világosság és színjelek elõállítását) az EP-ben másik cél-IC végzi.
Quote from: "geco"
Gondolom ezt a TV modulátor végzi, EP esetében nem túl jo hatásfokkal.

Nem, a modulátor az külön egység, a fémdobozba burkolt. Azon kívül is van még 2 IC az EP-ben. Az LM1886 az RGB-bõl csinál színkülönbségi jeleket, az LM1889 pedig be is keveri azt a videojelbe (a hangot is tehetné, de azt kispórolták). De még ennek a kimenete is alapsávi videojel, tehát DC-6Mhz közötti. Ezután jön a modulátor-doboz, ami UHF-re keveri.
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 09:54:31
Tetszik!
A 625 sorból mennyi a hasznos képsor? Valami ötszáz akármennyi?
És mivel a NICK a két félképnek ugyanazt adja, ezért marad kétszáz akárhány soros felbontása?

Egy pici kiegészítés: a PC monitorok is használták ezt az interlace technikát, amikor egyre nagyobb felbontást kezdtek kitalálni: 800x600,1024x768,1280x1024,stb ezek elöször mindig interlace-ben jelentek meg, késöbb lettek normálisan is elérhetõek. A 90-es évek közepe-vége táján volt vezetõ nagy betükkel hírdetett paraméter az, ha egy monitor pl 1024x768 Non Interlaced-et is tudott már. Úgy 5-6 éve tünhetett el végleg az Interlace a PC technikából.
Title: Re: NICK
Post by: lgb on 2005.December.23. 10:37:16
Amugy a Nick eddig "legszebb" tulajdonsaga hogy egy egyszeru digitalis halozat (ULA/PLA ilyesmi lehet talan?), tehat pl analog jel ha jol tudom nem is igazan jon ki rajta, hanem pl 8 "vezetek" jon ki, amibol ellenallasletra segitsegevel all elo valami analog jel mint egyszeru D/A konverter (mar amennyire tudom, szoljatok ha nem igy van). Ez azert is erdekes, mert volt olyan project otletem meg regebben hogy Ep-t kossunk VGA monitorra, elvezheto frissitesi frekvenciaval. Arra gondoltam, hogy digitalizalni kene a videojelet, elrakni egy szeeep nagy puffer RAM-ba, ahonnan viszont egy masik videojel megjelenito aramkor olvasni ki nagyobb sebeseggel, akar tobbszor is, amig egyszer feltolti a Nick-bol erkezett adatokkal. Ekkor persze 'tulfut' a Nick-en, pl 100Hz-es TV-k mukodnek hasonloan az ket puffert hasznal, igy egy frame kesessel lehet latni, az egyik puffer tartalmat latja az ember a kepernyon, a masik meg tellik a video jelbol erkezo adatokkal, aztan utana csere van. Ep eseten neheziti hogy nincs fix frekvencia a kepvaltasra, ugye a vertical retreace is az LPT resze, marmint azt nekunk kell adni, es elvileg lehet igy nyujtani vagy kicsinyiteni azt az idot ami egy frame felepitesre kell (az mas kerdes hogy mit szol hozza egy TV). Masik erdekesseg, hogyha Nick-bol jovo jeleket arra hasznalja az ember hogy indexeljen vele egy 256 elemu SRAM "tombot" benne RGB ertekekkel, akkor gyakorlatilag programozhatova valna a 256 EP szin is :)
Title: Re: NICK
Post by: lgb on 2005.December.23. 10:42:08
Quote from: "lgb"
Arra gondoltam, hogy digitalizalni kene a videojelet, elrakni egy szeeep nagy puffer RAM-ba, ahonnan viszont egy masik videojel megjelenito aramkor olvasni ki nagyobb sebeseggel, akar tobbszor is, amig egyszer feltolti a Nick-bol erkezett adatokkal. Ekkor persze 'tulfut' a Nick-en, pl 100Hz-es TV-k mukodnek hasonloan az ket puffert hasznal, igy egy frame kesessel lehet latni, az egyik puffer tartalmat latja az ember a kepernyon, a masik meg tellik a video jelbol erkezo adatokkal, aztan utana csere van.


Pont a lenyeg maradt le: EP eseten digitalizalni sem kell mert ugyis digitalis adat jon ki, pl Jerri amikor elkezdte a Commodore One projectet akkor csak egy hasonlo cuccnak indult C64-hez [marmint VGA monitorra C64-et], de ott ugye a VIC-II jelet digitalizalni kellett volna elobb :) Bar lehet kar kuzdeni ezzel, hiszen aze' a Nick annyira nem lehet bonyi, egyszerubb egy ujat szintetizalni pl egy FPGA belsejeben vagy whatever. Ha eleg gyors a RAM (mert ugye egy un Nick slotban a Nick max 2 byte -ot tud olvasni) akkor lehetne emelni a Nick byte fetch / slot maximumat, es akkor lehetne beallitani olyan modot ahol tobbszorese a vizszintes felbontas emiatt. Alapvetoen ha jol latom az egesz problema ott vagy hogy ez azert (is) limitalt, mert ugye a memoria sebessege adott, kozben neha a CPU is hozzanyul esetleg, tehat egyszeruen a meglevo EP hw-ban ezt nehez lenne emelni, sot neha a Nick igy is kenytelen megallitani a CPU-t egy kis "cikluslopasert" (ill ha jol tudom ezt a Dave csinalja, marmint a jelet o adja ki).
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 10:52:03
Quote from: "lgb"
Amugy a Nick eddig "legszebb" tulajdonsaga hogy egy egyszeru digitalis halozat (ULA/PLA ilyesmi lehet talan?), tehat pl analog jel ha jol tudom nem is igazan jon ki rajta, hanem pl 8 "vezetek" jon ki

Nagyjából pont így van :)
http://enterprise.8bit.hu/PCB/EP64-3.jpg
Quote
marmint azt nekunk kell adni, es elvileg lehet igy nyujtani vagy kicsinyiteni azt az idot ami egy frame felepitesre kell (az mas kerdes hogy mit szol hozza egy TV).

Nekünk az egyik Junoszty tévénk iszonyatosan érzékeny volt, kb 3 sor eltérésnél már elkezdett futni a kép. Innen tudjuk, hogy rengeteg EP-s proginak nem teljesen korrekt az LPT, ha betöltöttünk egy programot, állandóan tekergetni kellett a potit, hogy megálljon a kép. Egy átlag TV-n 10-20 sor eltéréssel is stabil marad még a kép.
Szóval arra nem szabad alapozni, hogy pont annyi sor jön ki az EP-bõl amennyi kéne... ehelyett a VSYNC,HSYNC jeleket is figyelni kéne.
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 10:57:46
Quote from: "lgb"
Ha eleg gyors a RAM (mert ugye egy un Nick slotban a Nick max 2 byte -ot tud olvasni) akkor lehetne emelni a Nick byte fetch / slot maximumat, es akkor lehetne beallitani olyan modot ahol tobbszorese a vizszintes felbontas emiatt.

Ilyesmin én is gondolkodom :) Szerencsére van egy nem használt videómód bitkombinációnk, így simán meglehetne csinálni kompatibilisre!
Quote
Alapvetoen ha jol latom az egesz problema ott vagy hogy ez azert (is) limitalt, mert ugye a memoria sebessege adott

Na igen ráadásul a korai EP-kben (mint pl az én 2944-esemben), még igen lassú 300 nanos RAM-ok vannak video memóriának! Újabbakban már lehet kétszer gyorsabb is. Ha meg új alaplapot csinálnák, lehetne berakni akár 15 nanos SRAM-ot is :)

Quote
neha a Nick igy is kenytelen megallitani a CPU-t egy kis "cikluslopasert" (ill ha jol tudom ezt a Dave csinalja, marmint a jelet o adja ki).

Egész pontosan azt csinálja a DAVE, hogy a CPU órajelébõl kihagy pár ciklust ilyenkor.
Title: Re: NICK
Post by: tigrian on 2005.December.23. 12:36:26
Quote from: "Zozosoft"
Tetszik!
A 625 sorból mennyi a hasznos képsor? Valami ötszáz akármennyi?

A szabvány csak annyit ír elõ, hogy kb. 25H (H:horizontal, egy sort jelöl) a függ. kioltás ideje. Elvileg tehát kb. 600 sor marad képre. De az elsõ kb. 12 sort sem lehet használni, ott van pl a Teletext infója. Marad tehát kb. 588 sor.
A gyakorlatban még ennél is kevesebb, mert a TV-k a kép széleit (függ. és vízszintes irányban is) "levágják", magyarán kisebb ablakot mutatnak csak belõle. Ez minden TV-nél más és más, beállítás kérdése, de úgy nagy átlagban olyan 560 körüli lehet.
Quote from: "Zozosoft"
És mivel a NICK a két félképnek ugyanazt adja, ezért marad kétszáz akárhány soros felbontása?
:smt045
Quote from: "Zozosoft"
... a PC monitorok is használták ezt az interlace technikát, amikor egyre nagyobb felbontást kezdtek kitalálni

Ez nem teljesen igaz, minden monitort mindig rá lehet vennei az interlace módra. Az interlace arra való, hogy ugyanazt a felbontást feleakkora sorfrekivel, és feleakkora sávszélességgel adhass. A korai monitorokban nem elsõsorban a felbontás volt korlátozott, hanem a sorfreki. Az persze igaz, hogy a gyártók --jó szokásukhoz híven-- mindig a nagyobb számokat mondják, még ha nem is igaz.
Az interlace egyébként a monitoroknál gyakorlatilag használhatatlan, függ. irányban "remeg" a kép.
Ezért nem is használják karakterkijezésnél (a TV is remeg egy picit, pláne az olcsóbbaknál, de a képnél nem annyira zavaró).
Quote from: "Zozosoft"
Úgy 5-6 éve tünhetett el végleg az Interlace a PC technikából.

A reklámokból igen. Attól még létezik ma is. Csak nincs értelme (bár én így vettem rá a monitoromat az 2000 körüli felbontásra, próbából :-) )
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 12:45:17
Quote from: "tigrian"
Ez minden TV-nél más és más, beállítás kérdése, de úgy nagy átlagban olyan 560 körüli lehet.

Junosztyon baromi könnyen be lehet állítani max méretre :)
De igaz, hogy egyes tévéknél még az EXOS-on keresztül elérhetõ 27x42 karakteres képernyõ (+status sor) is kilóg itt-ott, anno a színes tévénk megvétele után másnap hívtuk a szerelöt, beraktunk egy EPDOS-t, hogy ezt akarjuk látni :) és utána a filmekbõl is többet láttunk mint mások :) :)
Title: Re: NICK
Post by: tigrian on 2005.December.23. 12:49:33
lgb és Zozo, jaj, nagyon elõreszaladtatok a RAM olvasásával, ez a következõ rész témája lett (volna). Gondoltam, haladunk tematikusan, de ha már mindenki úgyis tudja...
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 12:51:40
Quote from: "tigrian"
lgb és Zozo, jaj, nagyon elõreszaladtatok a RAM olvasásával, ez a következõ rész témája lett (volna). Gondoltam, haladunk tematikusan, de ha már mindenki úgyis tudja...

:) Tanár úr kérem! Azért gondoljon a többi elsõs diákra is :)
Szóval jöhet a következõ rész!
Title: Re: NICK
Post by: gafz on 2005.December.23. 13:02:17
Quote from: "Zozosoft"
:) Tanár úr kérem! Azért gondoljon a többi elsõs diákra is :)
Szóval jöhet a következõ rész!


 :smt045
Title: Re: NICK
Post by: tigrian on 2005.December.23. 20:25:23
Az elõzõ részben arról volt szó, hogy mi is az a kompozit videojel, milyen kritériumai vannak. Ebbõl számunkra csak annyi a fontos, hogy egy sor (scanline) nemcsak a képtartalomból áll, vannak egyéb követelmények is.
No, azt már tudjuk, milyen jelet kell elõállítai, nézzük meg, ez hogyan is történik.

"pixel" (egy pont) elõállítása a képernyõn
Az alapelv ugye az, hogy a memória egy meghatározott részét elkezdjük olvasni, és az ott található adatok alapján elõállítjuk a videojelet reprezentáló jeleket (az, hogy ez 1 bit vagy 8V vagy 13 bakfitty, az most egyelõre nem érdekes).
Ez a léptetés egy meghatározott frekvenciával történik, ezt hívják RAMDAC-nak. Az értéke bizonyos határok között teszõleges, a tervezõ dönti el. Minél nagyobb a frekvencia, annál jobb lesz a felbontás, ez ugye nyilvánvaló. Van azonban egy felsõ limit, legalábbis a kompozit videojelnél. A színes jel esetében a világosságjel sávszélessége csak kb. 3,5 MHz. Ez korlátozza a RAMDAC praktikus maximumát kb. 7 MHz-re.

Hogyan is van ez? Mitõl lesz fele, meg kétszerese?
(http://enterpriseforever.com/userpix/3_ramdac_1.gif)
Az órajel felfutó éle olvassa be és teszi ki az adatot.
A videójel alacsony frekvencián szintén négyszögjel lesz, magasabb frekin egyre inkább már csak színusz.

Ez tehát azt jelenti, hogy a vízszintes felbontás nem lehet több kb. 720-nál (ismerõs szám?)
A színinformáció esetén a helyzet még rosszabb, a sávszélesség még kisebb. Emiatt két egymás melletti pixel színe mindig egyforma (ezt a tömörítõprogramok ki is használják). Tehát ha belegebedsz, akkor sem tudsz kb. 360 pontnál jobb színes felbontást produkálni. Ez nem jelenti azt, hogy minden második pixel egyforma, a fényességük lehet más. A színük nem. Egy sötétkéket pl. követhet világoskék. Piros viszont kizárt. Ez persze csak a kompozit jelre vonatkozik. RGB-ben (legyünk szabatosak: component jel esetén) bármit lehet.

No, tudjuk tehát, mik a lehetõségek. Az EP-ben ki is választották a maximumot, 7.125 MHz a RAMDAC (elvileg).

Quote
A RAMDAC választása ugyan tetszõleges, a sor hossza viszont szigorúan kötött, a színsegévivõ órajelével szinkronban kell lennie. Elrettentésül: (284-0,25) * 15625 Hz = 4433618,75 Hz, ez a színsegédvivõ.
Gyakorlati okokból a NICK órajele a RAMDAC kétszerese. Mivel a NICK ugyanazt a jelet használja a RAMDAC-nak is és a sorképzésre is, ezért további kötöttségek vannak. Az órajelnek a sorfreki (15625 Hz) többszörösének kell lennie. Feltéve, hogy még 16-tal is osztható az arányuk, így csak bizonyos értékek jöhetnek szóba. A doku szerint 57*16 = 64 usec. Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.


Quote
Szerintem el is túlozták kissé, alig akad monitor, ami az ennek megfelelõ felbontást produkálni tudja. TV meg aztán pláne nem. Feltételezem, produkálniuk "kellett" a minél nagyobb felbontást. No meg azért a 8 pixel széles, 80 karakteres képernyõ feltételezi a legalább 12.75 MHz-et. És akkor még nincsen BORDER sem. Szóval alacsonyabb frekivel, 6*8-as karakter olvashatóbb lenne, de az jókora bonyodalmakkal járna...


Lassan elérkezünk végre egy sor képzéséhez.
A sor (scanline) a legkisebb elemi (és atomi) egység a NICK-ben. A sor idõzítése fontos, úgyhogy csak minimálisan tudjuk szabályozni. A NICK 57 "egységre" (slot) bontja a sort (logikailag), ebbõl az elsõ 8 alatt olvassa be a memóriából a sor megjelenítéséhez szükséges mód-adatokat (közben pedig generálja a szinkronjelet). A következõ 46 alatt van a tényleges videótartalom generálása. Az utolsó 3 alatt frissíti a videomemóriát.

Quote
Vegyük elõ ismét a videojelet!
(http://enterpriseforever.com/userpix/3_di39fig05_1.jpg)
Egy slot 16 RAMDAC órajelet (így 16 pixelt, ill. 32 NICK órajelet) jelent, 1,1228 usec-et. Az elsõ 8 tehát kb. 9 usec.
Az ábra szerint viszont 4.7 + 0.6 + 2.5 + 1.6, összesen 9.4 usec ideig nem lehet képtartalom (a sor a szinkronjel elejétõl kezdõdik, ezért nem számoltam a rajzon szereplõ kezdõ 1.5 usec-et).
Miért érdekes ez?
A NICK a 8-ik slot után, vagyis a 9-ik usec-tõl már kiteszi a videojelbe a BORDER-nek megfelelõ színt. Egy kicsit tehát belelóg abba a tartományba, ahol még fekete szintet kéne produkálnia. Az eltérés nagyon kicsi, általában nem okozhat problémát. Lehetnek azonban TV-k, monitorok, amik meghülyülnek tõle, ha a BORDER nem fekete (ill. alacsony világosságjel-tartalmú).


A 9-ik slot idején tehát már BORDER lesz. Hogy meddig, az programozható. Aztán következik a tényleges képtartalom, adott ideig, aztán ismét BORDER.
Quote
A soridõ végén is vannak betartandó követelmények, adott ideig ott sem szabad mást, csak fekete szintet kiadni. De ez nekünk már nem fontos, a lényeg, hogy az utolsó 3 slotban már nem lehet aktív képtartalom.


Van tehát összesen 46 slot a képtartalomra (ez éppen 51.65 usec), ezalatt 736 pixelnyi adatot generál.
Nézzük akkor, mit is állíthatunk egy soron belül a képtartalmat illetõen (idõben)? Azt, hogy hol kezdõdjön (de ez minimum 9 ), és hogy meddig tartson (max. 55). Azt azért jó tudni, hogy a TV-k a kép széleit nem jelenítik meg, ezért gyakorlati okokból kb. 42 slot használható. Ez nagyjából be is határolja, hogy 10 és 52 a nyerõ szám.
Ezzel el is érkeztünk az analóg rész végéhez. Ígérem, legközelebb már ismerõsebb terep lesz. :-)
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 20:36:51
Quote from: "tigrian"
Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.

Ez igen jól egybevág azzal, hogyha a Nick órajelét kötjük be rendszerórajelnek, akkor 7.12 Mhz-es Z80-at kapunk! Valószínüleg ha több tizedesnyire mérnénk az órajelet, akkor meg lenne a 7.125...
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 20:52:18
Végig olvastam, jó kis leírás! Nekem eddig ezek az analóg dolgok igen homályos területnek számítottak :)
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 20:57:35
Quote from: "tigrian"
Tehát ha belegebedsz, akkor sem tudsz kb. 360 pontnál jobb színes felbontást produkálni. Ez nem jelenti azt, hogy minden második pixel egyforma, a fényességük lehet más. A színük nem. Egy sötétkéket pl. követhet világoskék. Piros viszont kizárt. Ez persze csak a kompozit jelre vonatkozik. RGB-ben (legyünk szabatosak: compound jel esetén) bármit lehet.

Gondolom ez az oka annak, hogy gyárilag csak monochrom kompozit jel van kivezetve.
Szövegszerkesztéshez, stb ez a jó, mivel ez az ami szép éles. Ha megcsináljuk a színes kompozitot, az igazából csak játékra jó, 80 karakteres módban már elég elmosodott. Mi ezért is csináltuk átkapcsolhatóra.
A tökéletes megoldás pedig az RGB használata, valami jó kis Scart-os tv-n, monitoron :)
Title: Re: NICK
Post by: tigrian on 2005.December.23. 21:04:57
Quote from: "Zozosoft"
Quote from: "tigrian"
Tehát ha belegebedsz, akkor sem tudsz kb. 360 pontnál jobb színes felbontást produkálni.

Gondolom ez az oka annak, hogy gyárilag csak monochrom kompozit jel van kivezetve.

Nyilván. Bár egyértelmûen ott a helye a csatin a színesnek is. Lenne még egy megoldás a problémára, kisebb felbontással, 64 karakter széles képernyõ remekül mûködik. A HP200-am is így csinálja, õk is tudnak valamit. Magyarán a 640 pixel is sok már, 6 MHz-es RAMDAC-kal 64 karakter tökéletes lehetne. De hát lehetnek egyéb szempontok is...
Title: Re: NICK
Post by: gafz on 2005.December.23. 21:15:12
És hogy is van az az Y-C? Akkor már lehet 2 szomszédos pixel más színû?
Színes meg monocrom composite jelet be lehet vezetni egy TV-be svhs csatlakozón át jó eredménnyel?
Title: Re: NICK
Post by: tigrian on 2005.December.23. 21:38:25
Quote from: "gafz"
És hogy is van az az Y-C? Akkor már lehet 2 szomszédos pixel más színû?
Színes meg monocrom composite jelet be lehet vezetni egy TV-be svhs csatlakozón át jó eredménnyel?

Igen, a kompozit vidojel legnagyobb nyûgje, hogy 50 év alatt eszetlen sok mindent zsúfoltak bele. A kezdetekkor a 6 MHz ûbermegaszuper minõségnek számított. Aztán az amcsik folytatták, és kapásból lecsíptek belõle 1 MHz-et. Aztán megtoldották a színek infóival is, újabb 2 MHz-et ellopva. Európában még tovább bonyolították, aztán a franciák még erre is rátettek egy lapáttal. Amit aztán az egész szoc. tábor megszenvedett.
Közben belezsúfolták még a sztereó hangot is, meg a Teletextet is, szóval... talán ez a legtöbbet toldozott-foldozott-buherált szabványa az embernek. Idõben leírni az egyenletét már szinte nem is lehet, mindenféle spektrum- meg vektorábrák kellenek hozzá. Ezektõl megkíméltem a csapatot :-)

Az SVHS-ben külön van a világosságjel (Y) meg a szín (C). Nem tudom, van-e rá gyakorlati limit, mit lehet a chroma-ra vezetni. A színinformáció még abban is kettõs kódolású (amplitúdó és fázis), úgyhogy ott is vannak azért megkötések. De mindenképpen sokkal jobb minõségû az összetett videojelnél.
Az EP esetében ez rajtunk nem segít, csak az RGB. Ott viszont az alacsony sorfreki a gond. Nemigen találsz hozzávaló monitort.  :cry:
Title: Re: NICK
Post by: gafz on 2005.December.23. 21:48:20
Quote from: "tigrian"
Az EP esetében ez rajtunk nem segít, csak az RGB. Ott viszont az alacsony sorfreki a gond. Nemigen találsz hozzávaló monitort.  :cry:


Az EP-n alacsony a sorfreki vagy a monitoron?  :oops:
Title: Re: NICK
Post by: tigrian on 2005.December.23. 21:58:11
Quote from: "gafz"
Az EP-n alacsony a sorfreki vagy a monitoron?  :oops:

Juj, akkor nem sokat értettél abból, amit eddig írtam. Vagy nem jól írtam meg.  :smt022
Az interlace (váltottsoros) technikának az a lényege, hogy feleakkora sorfreki kell hozzá. Az EP-t is TV-re tervezték, tehát ilyen sorfrekije (15625 Hz) van.
A szgép monitorok viszont már progresszív mûködésûek, ott egyik sor után a másik jön, végig, aztán kezdõdik elölrõl. Emiatt a sorfrekijük kétszer akkor minimum (31 kHz fölött). Aztán fel, ameddig csak bírják, a felbontás növelésével összhangban.
Nagyon nehéz, de mindenképpen drágább (fõleg régebben) olyan monitort készíteni, ami többféle frekin mûködik. Emiatt az "úgysem használt" frekire nem is tervezik ezeket.
Title: Re: NICK
Post by: Zozosoft on 2005.December.23. 21:58:22
Quote from: "tigrian"
Nemigen találsz hozzávaló monitort.

Nem véletlenül költöttem jó pár ezret a Philipsem felújítására, mikor kipusztult benne a sorkimenõ (vagy valami ilyesmi :) )
Title: Re: NICK
Post by: gafz on 2005.December.23. 22:01:15
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k? Valahogy nálam a progresszív megjelenítés a VGA monitorokkal került képbe... :smt090
Title: Re: NICK
Post by: tigrian on 2005.December.23. 22:20:33
Quote from: "gafz"
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k?

A váltottsor természetes velejárója a páratlan sorszám. A szgépeknek meg a páros a normális. De van más oka is. A 16 kHz alatti freki túl alacsony, a hallható sávban van. Van mûszaki oka is, pontosan nem tudom (a tekercs nálam sötét terület  :D ), de jelentõs áramok folynak az eltérítõtekercsben, jelentõs energiákat termelve. Ha jól tudom, alacsonyabb frekinél ugyanahhoz az energiához nagyobb áram, tehát jóval masszívabb (értsd: drágább) végfok kell.
Ez az egész katódsugárcsöves-nagyfeszültséges-eltérítéses technika egy --elég szûk-- tartományon belül lavíroz mindig, sohasem sikerült még stabil, megbízható, hosszútávon mûködõ készüléket építeni. A megoldást most már az LCD-k jelentik, nemsokára már teljesen leváltják végre ezeket. Azok között már most is találhatsz RGB bemenetût, amit TV-nek árulnak, annál van esély, hogy 15 kHz-en jár (bár nem biztos).
Title: Re: NICK
Post by: gafz on 2005.December.23. 22:25:42
Quote from: "tigrian"
A megoldást most már az LCD-k jelentik, nemsokára már teljesen leváltják végre ezeket. Azok között már most is találhatsz RGB bemenetût, amit TV-nek árulnak, annál van esély, hogy 15 kHz-en jár (bár nem biztos).


Szóval ha valaki véletlenül (vagy majd ha olcsóak lesznek) vesz egy LCD TV-t EP-jéhez, akkor még az is lehet, hogy pofára esik??? :smt074
Title: Re: NICK
Post by: tigrian on 2005.December.23. 22:29:06
Quote from: "gafz"
Szóval ha valaki véletlenül (vagy majd ha olcsóak lesznek) vesz egy LCD TV-t EP-jéhez, akkor még az is lehet, hogy pofára esik??? :smt074

Bizony, több oka is lehet rá. A képminõségtõl is történhet vele ilyen, a cipõfûzõje is kioldódhat, meg az is lehet, hogy vásárlás elõtt nem ellenõrizte a paramétereket. :roll:
Title: Re: NICK
Post by: gafz on 2005.December.23. 22:33:08
Quote from: "tigrian"
Bizony, több oka is lehet rá. A képminõségtõl is történhet vele ilyen, a cipõfûzõje is kioldódhat, meg az is lehet, hogy vásárlás elõtt nem ellenõrizte a paramétereket. :roll:


Az LCD bizniszre mostanában nem jellemzõ, hogy a vásárlás helyén kideríthetõ legyen, hogy képes-e a TV a 15kHz sorfrekvenciára... :(
Title: Re: NICK
Post by: tigrian on 2005.December.24. 00:40:51
Quote from: "gafz"
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k? Valahogy nálam a progresszív megjelenítés a VGA monitorokkal került képbe... :smt090

Uh-oh. Elnézést kérek.  :oops:
Az õsi CGA monitorok valóban majdnem használhatóak lennének. Azok NTSC frekivel jártak (naná, az amcsik amaguknak csinálták), tehát 15750 Hz vízszintes, 60 Hz függõleges frekivel. De a CGA vezérlõ is már progresszív megjelenítést használt, talán ezért ment ki a fejembõl.
A sorfreki tehát gyakorltilag ugyanaz, a képfrekinél viszont nagy esély van rá, hogy nem tud a monitor 50 Hz-re ráhúzni. Kicsit belenyúlva a belsejébe, azért bizonyára rávehetõ.
De van még egy lehetõség, kicsit késõbb (már a VGA korszak-ban) készültek ún. multisync monitorok is, ezek 15-31kHz és 50-60 Hz között tudtak mûködni.
Több gond is van még ezekután is. Egy ilyen több (10) éves masinánál valószínû, hogy a sorkimenõ része már vagy halott, vagy erõsen közel van hozzá (egyszer én vettem 3 egyforma ilyen monitort, fillérekért, arra számítva, hogy egyet csak összerakok belõlük. Mind a 3-nak a sorvégje volt kampec. :-( Mint ahogy az összes CRT-nek ez a legsebezhetõbb pontja.)
És ha még beindul, akkor is van esély rá, hogy interlace üzemmódban a kép remeg. Sok öröm nem lesz tehát benne.
Nem kell tehát feladni, de jóval egyszerûbb az LCD felé kacsintgatni.
Title: Re: NICK
Post by: MrPrise on 2005.December.24. 00:53:59
Quote from: "tigrian"
Nem kell tehát feladni, de jóval egyszerûbb az LCD felé kacsintgatni.

Szeretnék már kacsingatni az Enterprise-om képernyõjére az LCD monitoromon    :smt024
Title: Re: NICK
Post by: gafz on 2005.December.24. 10:00:17
Van valakinek LCD TV-je? Megnézte már rajta az EP képét? Ha igen, milyen?
Title: Re: NICK
Post by: tigrian on 2005.December.24. 12:08:28
Quote from: "gafz"
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k?

Még egy dolog, talán nem világos, pedig írtam már, hogy mindig, minden monitort rá lehet venni az interlace-re.
Szóval a monitor mit sem tud az üzemmódról. Van neki két eltérítõegysége. Azt, hogy azok hogyan mûködnek, a szinkronjelek határozzák meg (amit ugye kívülrõl kap). Amikor szinkronjelet kap, akkor van a visszafutás az eltérítésben. Tehát csak a szinkronjelek egymáshoz való viszonya határozza meg azt, hogy progresszív, vagy interlace lesz-e belõle.
Majd egyszer talán lerajzolom, hogy is van ez, abból rögtön érthetõ lesz...
Title: Re: NICK
Post by: Ep128 on 2005.December.24. 18:17:14
Quote from: "gafz"
Van valakinek LCD TV-je? Megnézte már rajta az EP képét? Ha igen, milyen?

1x már majdnem sikerült egyet megnézni... :-)
Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...
Title: Re: NICK
Post by: tigrian on 2005.December.24. 21:28:49
Quote from: "tigrian"
Az õsi CGA monitorok valóban majdnem használhatóak lennének.

Beszéltem egy cimborámmal, aki nálam sokkal jobban ért a monitorok belsejéhez, lévén, õ javította is azokat. Nem találtuk meg teljesen a közös nyelvet, de egy-két dologban azért felhomályosított, ill. egyet is értettünk.
No szóval az alacsonyabb freki elõállítása nem fizikai, ill. technológiai probléma, viszont az igaz, amit írtam, miszerint megdrágítja a berendezést, ha nagyobb tartományban is kell mûködnie. Ezért az "úgysem használt" frekikre nem is tervezik.
Ritka tehát a multisync monitor, legalábbis ebben a tartományban.
A másik dolog, hogy a CGA monitor TTL bemenetû, azaz csak 16-féle színre tervezték (van egy plusz intensity bitje is, ezért inkább RGBI-nek hívják). Vagyis egyáltalán nem biztos, hogy egy CGA monitor analóg RGB jelet is tud fogadni. Amelyik tud, azon kell lennie egy kapcsolónak is emiatt (vagy plusz bemenetnek, vagy egyéb állítási lehetõségnek). Az ilyeneken többnyire BNC bemenet is van, a kompozit videojelnek (is).
Title: Re: NICK
Post by: Zozosoft on 2005.December.24. 22:45:11
Analog bemenetü CGA az szerintem kb fehér hollo kategoria. Ami valoszinübb lehetne:EGA/VGA monitor.Az ilyen az EGA miatt tudja ugyanazt a lassu frekit mint a CGA.Viszont a VGA miatt tuti van analog RGB bemenete.
De az ilyen régiségeket szerintem már vagy 5-8 éve kidobálták lomtalanitáson...
EP-hez legegyszerübb nézni egy kis 14" tvt,RGB Scart csatival.
Nekem is van egy kis Samsung,teljesen jo, kb akkora a különbség a komposit meg a RGB között,mint az UHF és a composit között...
Persze a Philips RGB monitorom egy picivel jobb még ennél is,de az már nem annyira számottevö.
Title: Re: NICK
Post by: tigrian on 2005.December.24. 22:59:31
Quote from: "Zozosoft"
... Ami valoszinübb lehetne:EGA/VGA monitor.

(http://enterpriseforever.com/userpix/3_welcome_1.gif)
Köszi a kiegészítést, valóban kissé összekevertem a CGA meg RGB rövidítéseket. Szóval akkor RGB monitorról beszélünk, ami CGA frekit is (15.75 kHz) meg persze EGA frekit is (21.85 kHz) tud, és ezek valóban a VGA korszak elején léteztek leginkább.
És abban is igazad lehet, hogy jóval egyszerûbb SCART bemenetû TV-t találni.
Title: Re: NICK
Post by: Zozosoft on 2005.December.27. 22:43:50
Quote from: "tigrian"
Ezzel el is érkeztünk az analóg rész végéhez. Ígérem, legközelebb már ismerõsebb terep lesz. :-)

És mikor lesz az a legközelebb? :-)
Title: Re: NICK
Post by: tigrian on 2005.December.27. 22:53:46
Quote from: "Zozosoft"
És mikor lesz az a legközelebb? :-)

Türelem, türelem. Egyrészt Karácsony volt nálam is, másrészt a köv. részre jobban elõ kell készülnöm. Le kell ellenõriznem, nehogy marhaságot írjak. Igazából még szkóppal is meg akartam nézni, de az lehet, hogy kimarad...
Addig is itt egy kép neked, példának, hogy mennyire nem lehet a színeket megjeleníteni a videojelben. Piros után kék nem is létezik pl. De minden átmenet ronda.
Igazából csak a "pacák" mûködnek jól. Ahhoz képest elég élvezhetõ a végeredmény.  :lol:
(http://enterpriseforever.com/userpix/3_beallabra_1.jpg)
Title: Re: NICK
Post by: Zozosoft on 2005.December.27. 22:55:44
Quote from: "tigrian"
Addig is itt egy kép neked, példának, hogy mennyire nem lehet a színeket megjeleníteni a videojelben.

Ez valami tévéadásból van?
És mindez ugye a kompozít videójelre vonatkozik, ugye? :-)
Title: Re: NICK
Post by: tigrian on 2005.December.27. 23:01:39
Quote from: "Zozosoft"
Quote from: "tigrian"
Addig is itt egy kép neked, példának, hogy mennyire nem lehet a színeket megjeleníteni a videojelben.

Ez valami tévéadásból van?

Így van, ez egy beállítóábra, mûsor után sugározza az egyik adó.
Quote from: "Zozosoft"
És mindez ugye a kompozít videójelre vonatkozik, ugye? :-)

Igen, persze, arra példa, hogy az összetett videójel egy nagy kompromisszum. Valójában csak képekre való, vonalas ábrára semmiképp sem. De azt is akartam jelezni vele, hogy a felbontás nem minden. Kisebb felbontással is lehet élvezhetõ képeket gyártani (és ez már bevezetõ a következõ témához  :wink: )
Title: Re: NICK
Post by: Zozosoft on 2005.December.27. 23:18:22
Quote from: "Ep128"
Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...

Hát ez nem olyan biztos! De majd megkérdezzük Tigriant is, hogy jól gondolom-e :-)
Én a PC-s LCD/TFT monitorokból kiindulva nagy problémákat sejtek...
Ezek gyakorlatilag digitális képernyõk, azaz fixen meg vannak a képpontjaink, ellentétben a CRT folyamatosan változó fénysugarával. A fix képpontok meghatározzák a képernyõ ideális felbontását is. A monitor elektronikájának be kell digitalizálni az analóg jelet, és ezt elosztani a fix képpontokra. Akkor van gond, ha az általunk használt felbontás nem egyezik meg a monitor ideális felbontásával. Pl egy 1500x1500-as monitort (az egyszerûség kedvéért nézzünk normális számokat :) ) 1000x1000-es felbontásban akarjuk használni. Ekkor minden pixelünknek 1.5 pixel felel meg a monitoron... ami a gyakorlatban úgy fog kinézni, hogy egyes kép pixeleink 1, más pixelek 2 pixel méretûek lesznek a monitoron, ami a nyomdai világból jól ismert moaré effektusthoz vezet. Magyarán fos lesz a kép :( A PC világban használt idióta méretû felbontásoknál még kiszámíthatatlanabb módon fog elb...odni a kép, pl ha egy 1024x768-as LCD monitort 800x600-ban szeretnénk használni... Természetesen maradéktalan oszthatóság esetén (pl 1600x1200-as monitor 800x600-ban) tökéletes marad a kép.
Természetesen az, hogy mennyire feltünõ a hiba, függ a megjelenített tartalomtól is, pl szövegszerkesztésnél, ahol éles karakterekre lenne szükség, ott rendkívûl zavaró. Játéknál, filmnézésnél, ahol nagy mozgó pacák vannak, ott nem tünik fel :)
Visszatérve az elejére: vajon milyen felbontása van egy LCD TV panelnek? és ez mennyire egész számú többszöröse az EP felbontásának?
Title: Re: NICK
Post by: Zozosoft on 2005.December.27. 23:19:34
Quote from: "tigrian"
a felbontás nem minden. Kisebb felbontással is lehet élvezhetõ képeket gyártani

Ha van hozzá elég szín :-)
Title: Re: NICK
Post by: tigrian on 2005.December.27. 23:59:33
Quote from: "Zozosoft"
Quote from: "Ep128"
Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...

Hát ez nem olyan biztos! De majd megkérdezzük Tigriant is, hogy jól gondolom-e :-)
Én a PC-s LCD/TFT monitorokból kiindulva nagy problémákat sejtek...

Elvileg igen, a képpontoknak a megjelenítés helyére kéne esniük. De ez már az analóg monitoroknál sincs így, sõt, ott meg aztán végképp nem. Ehhez a részéhez nem értek, valamilyen fiziológiás dolog lehet mögötte. A nagyobb felbontásnak is (az adott monitor képességeihez képest) elvileg nincs értelme, mégis nagyobb felbontás érzetét lehet vele elérni. Vagyis mûködik a dolog.
Quote

Visszatérve az elejére: vajon milyen felbontása van egy LCD TV panelnek? és ez mennyire egész számú többszöröse az EP felbontásának?

A TV-kbe tudtommal a leggyengébb verziókat teszik. Vagyis úgy nagyjából 640*480 körüli (talán egy picit nagyobb) a felbontás, a nagy méretûeknél is. Tehát senki ne akarjon ilyet PC-re kötni, monitornak.
Title: Re: NICK
Post by: Zozosoft on 2005.December.28. 00:08:02
Quote from: "tigrian"
nagyjából 640*480 körüli (talán egy picit nagyobb) a felbontás, a nagy méretûeknél is. Tehát senki ne akarjon ilyet PC-re kötni, monitornak.

Ezt én is így sejtettem :-)
640 az EP-n a 40 karakter széles kép, border nélkül... az ideális olyan 680 lenne, erre kiférne a 42 karakteres sor is, picike borderrel.
Title: Re: NICK
Post by: tigrian on 2005.December.28. 00:21:11
Quote from: "Zozosoft"
... az ideális olyan 680 lenne, erre kiférne a 42 karakteres sor is, picike borderrel.

Mondom, mûködik a nagyobb felbontás a kisebb lehetõségeken. Úgy 20-30%-kal jobb felbontás ráengedhetõ egy monitorra, ha elvileg nem is képes rá. A pont megjelenítése az analóg jelnél (és ugye azt adunk neki) nem "digitális", tehát nem "van vagy nincs". Ha egy pixel két pont közé esne, akkor mind a két pont világítani fog, halványabban. A szem meg valahogy korrigálja magának az infót. De ez csak spekuláció a részemrõl, a lényeg, hogy nem a 640 kontra 672 a kérdés.
Egyébként meg sosem esik esik pontosan pixelre az infó, analóg jel (tehát pontatlan idõk) esetén. Meg egyébként sem, hiszen nics egyetlen pont, legalább 3-ból tevõdik össze.
Title: Re: NICK
Post by: Ep128 on 2005.December.28. 02:24:51
Quote from: "tigrian"
Quote from: "Zozosoft"
Quote from: "Ep128"
Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...

Hát ez nem olyan biztos! De majd megkérdezzük Tigriant is, hogy jól gondolom-e :-)
Én a PC-s LCD/TFT monitorokból kiindulva nagy problémákat sejtek...

Elvileg igen, a képpontoknak a megjelenítés helyére kéne esniük. De ez már az analóg monitoroknál sincs így, sõt, ott meg aztán végképp nem. Ehhez a részéhez nem értek, valamilyen fiziológiás dolog lehet mögötte. A nagyobb felbontásnak is (az adott monitor képességeihez képest) elvileg nincs értelme, mégis nagyobb felbontás érzetét lehet vele elérni. Vagyis mûködik a dolog.
Quote

Visszatérve az elejére: vajon milyen felbontása van egy LCD TV panelnek? és ez mennyire egész számú többszöröse az EP felbontásának?

A TV-kbe tudtommal a leggyengébb verziókat teszik. Vagyis úgy nagyjából 640*480 körüli (talán egy picit nagyobb) a felbontás, a nagy méretûeknél is. Tehát senki ne akarjon ilyet PC-re kötni, monitornak.

Ez izgi, mert az LCD Tv-k nagy részét úgy árulják, hogy "számítógéphez is ajánlott" -cetli van rányalva... :-)
Title: Re: NICK
Post by: MrPrise on 2005.December.28. 10:05:43
Quote from: "Ep128"
Ez izgi, mert az LCD Tv-k nagy részét úgy árulják, hogy "számítógéphez is ajánlott" -cetli van rányalva... :-)

Gondolom itt a számítógép = PC. Filmnézésre meg lehet, hogy jó.
Title: Re: NICK
Post by: tigrian on 2005.December.28. 12:16:39
Quote from: "MrPrise"
Quote from: "Ep128"
Ez izgi, mert az LCD Tv-k nagy részét úgy árulják, hogy "számítógéphez is ajánlott" -cetli van rányalva... :-)

Gondolom itt a számítógép = PC. Filmnézésre meg lehet, hogy jó.

Igen, filmnézésre. Itt is az az igaz, hogy sose higyj a gyártóknak! És mindig nézd meg a speckót is.
Title: Re: NICK
Post by: lgb on 2005.December.28. 23:03:58
Quote from: "Zozosoft"
Quote from: "lgb"
Ha eleg gyors a RAM (mert ugye egy un Nick slotban a Nick max 2 byte -ot tud olvasni) akkor lehetne emelni a Nick byte fetch / slot maximumat, es akkor lehetne beallitani olyan modot ahol tobbszorese a vizszintes felbontas emiatt.

Ilyesmin én is gondolkodom :) Szerencsére van egy nem használt videómód bitkombinációnk, így simán meglehetne csinálni kompatibilisre!


Nana, az teljesen mas! A videomod igazabol azt hatarozza meg, hogy a beolvasott adatokbol milyen modon legyen kepi informacio, azaz peldaul ilyen es olyan videomod, ennyi es annyi szinnel stb. Igazabol az hogy pl 2 byte helyett negyet olvasson be az nem videomod fuggvenye, meg keves is lenne az az egy darab nem hasznalt bitkombinacio, hiszen minden (na jo majdnem minden) videomodnal szukseg lehetne esetleg dupla vizszintes felbontasra, sot van ahol a negyszerezes is jo lenne (pl 256 szinu mod), stb. A nem hasznalt bitkombinaciot inkabb arra kene fenntartani, hogy pl 15 v 16 bites szinmelyesegu mod :)
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 09:08:53
Quote from: "lgb"
Nana, az teljesen mas! A videomod igazabol azt hatarozza meg, hogy a beolvasott adatokbol milyen modon legyen kepi informacio, azaz peldaul ilyen es olyan videomod, ennyi es annyi szinnel stb. Igazabol az hogy pl 2 byte helyett negyet olvasson be az nem videomod fuggvenye, meg keves is lenne az az egy darab nem hasznalt bitkombinacio, hiszen minden (na jo majdnem minden) videomodnal szukseg lehetne esetleg dupla vizszintes felbontasra, sot van ahol a negyszerezes is jo lenne (pl 256 szinu mod), stb. A nem hasznalt bitkombinaciot inkabb arra kene fenntartani, hogy pl 15 v 16 bites szinmelyesegu mod :)

Nem nyert :-)
Code: [Select]
MB - Mód byte.

    * VINT - Ha be van állítva, ennek a MODSOR-nak a kezdetén megszakítás generálódik (lásd késõbb).
    * SZÍN MÓD - Azt vezérli, hogyan fordítódnak a képernyõbyte-ok színbyte-okká.
          o 00 - Két színû mód
          o 01 - Négy színû mód
          o 10 - 16 színû mód
          o 11 - 256 színû mód
    * VRES - Beállítva teljes függõleges felbontást engedélyez, törölve csak korlátozott felbontás van a grafikus módokban.
    * VIDEO MÓD - Átfogó video mód. Azt vezérli, hogyan legyenek kiolvasva a képernyõbyte-ok a video RAM-ból.
          o 000 - VSYNC mód
          o 001 - PIXEL mód
          o 010 - ATTRIBUTE mód
          o 011 - CH256 mód
          o 100 - CH128 mód
          o 101 - CH64 mód
          o 110 - nincs használva
          o 111 - LPIXEL mód

A nem használt 110 videó móddal lehetne jelezni, hogy über brutál hiper szuper nagy felbontású grafika :-) és ehhez még ott van a 2 szín mód bitünk is!
Title: Re: NICK
Post by: lgb on 2005.December.29. 09:44:48
Quote from: "Zozosoft"
Quote from: "lgb"
Nana, az teljesen mas! A videomod igazabol azt hatarozza meg, hogy a beolvasott adatokbol milyen modon legyen kepi informacio, azaz peldaul ilyen es olyan videomod, ennyi es annyi szinnel stb. Igazabol az hogy pl 2 byte helyett negyet olvasson be az nem videomod fuggvenye, meg keves is lenne az az egy darab nem hasznalt bitkombinacio, hiszen minden (na jo majdnem minden) videomodnal szukseg lehetne esetleg dupla vizszintes felbontasra, sot van ahol a negyszerezes is jo lenne (pl 256 szinu mod), stb. A nem hasznalt bitkombinaciot inkabb arra kene fenntartani, hogy pl 15 v 16 bites szinmelyesegu mod :)

Nem nyert :-)
Code: [Select]
MB - Mód byte.

    * VINT - Ha be van állítva, ennek a MODSOR-nak a kezdetén megszakítás generálódik (lásd késõbb).
    * SZÍN MÓD - Azt vezérli, hogyan fordítódnak a képernyõbyte-ok színbyte-okká.
          o 00 - Két színû mód
          o 01 - Négy színû mód
          o 10 - 16 színû mód
          o 11 - 256 színû mód
    * VRES - Beállítva teljes függõleges felbontást engedélyez, törölve csak korlátozott felbontás van a grafikus módokban.
    * VIDEO MÓD - Átfogó video mód. Azt vezérli, hogyan legyenek kiolvasva a képernyõbyte-ok a video RAM-ból.
          o 000 - VSYNC mód
          o 001 - PIXEL mód
          o 010 - ATTRIBUTE mód
          o 011 - CH256 mód
          o 100 - CH128 mód
          o 101 - CH64 mód
          o 110 - nincs használva
          o 111 - LPIXEL mód

A nem használt 110 videó móddal lehetne jelezni, hogy über brutál hiper szuper nagy felbontású grafika :-) és ehhez még ott van a 2 szín mód bitünk is!


De pontosan hogy nyert! Nem erted mire gondolok. Arrol beszelek hogy en nem feltetlenul csak huper/szuper felbontasu grafikat akarok, mi van, ha en pl ATTRIBUTE modban szeretnem duplazi a vizszintes felbontast? Vagy a karakterek CH modokban? En errol beszeltem amikor azt mondtam, hogy szerintem szerencsesebb lenne ha nem azt az 110 kombinaciot hasznalnank erre, hanem barmelyik modnal lehetne lehetoseg arra, hogy ketszerezze az ember (vagy akar negyszerezze, netan nyolcszorozza ;-) a vizszintes felbontast olyan modon hogy egy slot alatt egyszeruen novelni kene a Nick (illetve a Nick2 ;-) altal beolvasott byte-ok szamat. En a nem hasznalt kombinaciot (110) inkabb masra hasznalnam, pl akar hi-color ;-) modra, ahol persze aztan TENYLEG kell a felbontas novelese, hiszen 2byte/pixel (15 v 16 bpp) eseten "normal" Nick tempoval a vizszintes felbontas kb 40 pixel lenne csupan (ha 40  slot van a ket margo kozott), ami negyszerezessel 160 pixel kornyekere mehetne fel, nyolcszorozassal meg mar "kellemes" 320 kornyekere jutunk. Napersze ez azert is erdekes, mert 320*200 az 8 bpp-vel (256 szin) es csaknem 64K, 320*200 16 bpp-vel az kvazi dupla ennyi, szal nem fer be a 64K videoramba :) Szoval ez is egy erdekes kerdes a Nick2 szempontjabol ;-P Najo, lehet hogy ez a 15/16 bpp kisse tulzas, tenyleg.
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 10:23:03
Quote from: "lgb"
mi van, ha en pl ATTRIBUTE modban szeretnem duplazi a vizszintes felbontast? Vagy a karakterek CH modokban?

Ezeknek én nem érzem az égetõ szükségességét :)
Quote
En errol beszeltem amikor azt mondtam, hogy szerintem szerencsesebb lenne ha nem azt az 110 kombinaciot hasznalnank erre

És hogyan oldanád meg az eredetivel való 100%-os kompatibilitást?
Quote
Najo, lehet hogy ez a 15/16 bpp kisse tulzas, tenyleg.

Szerintem is! Én a grafikus módokban eggyel nagyobb felbontással már bõven beérném. A kettõvel jobb már überkirály lenne, de ott már jönne a Video RAM méret gond is...
És arra is gondolni kell, hogy ha nem csak állóképeket akarunk nézegetni, hogy a Z80 meg tudjon bírkozni a kép adatok piszkálásával. Ha egy 7-8 Mhz-es Z80-hoz tennénk egy 2x felbontást tudó Nicket, az nyílván úgyanolyan könnyedén mûködne, mint a mostani felállás.
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 10:39:56
Leírom a mostanában megfogalmazodott ötletemet, Tigrian biztos örülni fog neki :-)

Úgy látom nem lenne szükség új alaplapra sem, megoldható lenne egy külsõ Nick2 kártyát csinálni.
A Nick portjai csak írhatóak, így semmi akadálya, hogy egy másik Nick is legyen a rendszerben, a Nick portokra írt dolgokat ugyanúgy megkapná ez is. Videó memóriából kéne még egy csak írható tükör példány az új Nick számára. A Nick2 pontosan ugyanazt csinálná mint a Nick, kivéve a nem használt videómódú sorokat, ezekben 2x sebességgel olvasva az eredeti felbontás dupláját hozná.
Természetesen a kártyának saját monitor kimenete lenne, ami esetleg lehetne VGA/DVI/akármi is :)
Az eddig használt videómódú sorokban mind két NICK képén úgyanaz lenne, tehát bármely régi programot futtatva, nem kéne az alaplapi kimenetet használni. Az eddig nem használt módú sorokban a régi nem jelenít meg semmit, az új meg a nagyobb felbontású grafikát.
Módosítva az EXOS VIDEO: perifériát, egybõl simán mûködne bármely EXOS grafikát használó programban a dolog, lévén az EXOS írói elõrelátóak voltak, és logikai kordináta rendszert használtak, ami független az éppen használt fizikai felbontástól.
Title: Re: NICK
Post by: MrPrise on 2005.December.29. 11:06:06
Quote from: "Zozosoft"
Leírom a mostanában megfogalmazodott ötletemet, Tigrian biztos örülni fog neki :-)

Úgy látom nem lenne szükség új alaplapra sem, megoldható lenne egy külsõ Nick2 kártyát csinálni.

Ez amilyen vad ötlet elsõre, olyan király is! :-D
Title: Re: NICK
Post by: tigrian on 2005.December.29. 12:58:02
Quote from: "Zozosoft"
Leírom a mostanában megfogalmazodott ötletemet, Tigrian biztos örülni fog neki :-)

Én igazából annak nem örülök, hogy már megint elõreszaladtatok  :(
Reggel 5-ig írtam az új részt, de nem bírtam tovább, így nem készültem el vele. Úgy látszik, ebbõl már hagyomány lesz, hogy az új rész elõtt lgb-vel bevezetitek azt  :lol:

Quote
... megoldható lenne egy külsõ Nick2 kártyát csinálni.

Valóban, és nem is olyan ördöngösség. Gond abból adódik, ahogy mész fel a RAMDAC frekivel, úgy gyûlnek egyre jobban a megoldandó analóg problémák (pontosabban: úgy lesz egyre inkább analóg probléma a digitálisból).
Ami a programozását illeti, alapvetõen lgb-vel értek egyet, én sem az ún. nem használt videómódot használnám. Inkább új IO portot neki, aztán onnan már bármi lehet. Vagyis nem tolgozgatnám az eredeti LPB-t.
De erre késõbb majd visszatérhetünk. Most inkább nem ezen járatom az agyam, hanem befejezem a köv. fejezetet.  :P
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 13:11:19
Quote from: "tigrian"

Ami a programozását illeti, alapvetõen lgb-vel értek egyet, én sem az ún. nem használt videómódot használnám. Inkább új IO portot neki, aztán onnan már bármi lehet. Vagyis nem tolgozgatnám az eredeti LPB-t.

Így viszont nehezen tudom elképzelni a kompatibilitást, azt meg pláne, hogy régi és új tetszõlegesen legyen keverve...
Meg szerintem pont késöbbi fejlesztésre maradt az a nem használt mód, így az eredeti alapkoncepcióba is beleillik a dolog. Az EXOS koordináta rendszeres is pont a kétszerese a jelenleg elérhetõ max felbontásnak (2 szín mód), ebbõl arra tippelek, hogy gondoltak ilyen kétszeres felbontású mód jövöbeni megvalósítására.

Quote
De erre késõbb majd visszatérhetünk.

Ok! :)
Quote
Most inkább nem ezen járatom az agyam, hanem befejezem a köv. fejezetet.  :P

Hajrá, már nagyon várjuk!
Title: Re: NICK
Post by: lgb on 2005.December.29. 14:14:54
Quote from: "Zozosoft"
Quote from: "lgb"
mi van, ha en pl ATTRIBUTE modban szeretnem duplazi a vizszintes felbontast? Vagy a karakterek CH modokban?

Ezeknek én nem érzem az égetõ szükségességét :)


Pedig hasznos, pl 80 karakteres felbontast maskepp nem csinalsz, legalabbis valodi
karakteres moddal (ami gyors lenne) nem, csak mondjuk pixel modban (ami viszont lassabb
hiszen pixelenkent kell rajzolni). Masreszt "egyszerubb" olyan szempontbol hogy nem a video mod jelenteset kell "ertelmezni" hanem egysegesen beallithato hogy a Nick2 egy slot alatt
pl dupla annyi pixelt rakjon ki, igy hozza sem kell nyulni ahhoz a logikahoz ami eddig volt, "csak" az idozitesen kell valtoztatni meg miegymas, es ezert cserebe ez minden videomodra mukodni fog.

Quote from: "Zozosoft"
Quote from: "lgb"
En errol beszeltem amikor azt mondtam, hogy szerintem szerencsesebb lenne ha nem azt az 110 kombinaciot hasznalnank erre

És hogyan oldanád meg az eredetivel való 100%-os kompatibilitást?


Hat attol fugg hogy milyen szinten kell implementalni :) En eloszor arra gondoltam hogy ez a teljes Nick mukodeset erinti es akkor semmi helye az LPT-ben, hanem pl port szinten lehet globalisan megmondani ezt (elvegre ez a teljes nick idoziteset befolyasolja), azaz ha jol tudom igazabol 80-8F az mind fenn van tartva a Nick-nek de ebbol csak a 80-83 van hasznalva. Na persze azonnal eszunkbe juthat, hogy miert ne lehetne ezt is belezsufolni az LPT egyes LPB-ibe, ezaltal nem kell globalisnak lennie ezen a dolognak. Ekkor TENYLEG problema lesz a kompatibilitas, ahogy mondod, en viszont az elso megoldasra gondoltam kezdetben, ezert ezen nem is filoztam ... Esetleg egy csunya otletem van, ami megprobalja a ket megoldas otvozni: allitsuk csak be szepen az amlitett 110 nem hasznalt kombinaciot a nem standard dolgokra, azonban ebben az esetben a videomodot es a byte fetch / nick parametert vegye a Nick2 pl az LPB utolso byte-jabol. Ezzel azt ertnenk el, hogy a 110 kombo beallitasa nelkul full compatible minden, beallitasaval viszont lehetoseg van minden fajta videomodban novelni a vizszintes felbontast! Az ara ennek az, hogy az LPB utolso byte-janak hasznalataval 16 szinu modban elba*szuk a palettat, jobban mondva annak utolso byte-jat. Esetleg van alternativ megoldasom erre is :) Ha mar egyszer pl ugyis 2 byte helyett negyet olvasna a Nick egy slot alatt, akkor azt is jelenthetne ez, hogy az LPB lehet hosszabb mint 16 byte! Ezzel maris lenne hely az infonak, es a 16 szinu modot sem rontanank el palette ugyileg. Mivel a mod nem az LPB elso byte-jabol derul ki,
ezert az LPB olvasasa sorban nem az elso slot-ban derul ki hogy normal vagy extended
LPB-vel van-e dolgunk, ezert ket lehetoseg van. Egyreszt azt mondhatjuk hogy a Nick2 az LPB-t az eddigi 8 slot helyett pl 4 alatt be tudja olvasni, es ha extended LPB van akkor meg van erre ido. Ez kisse elter az eredeti felepitestol, nem tudom okozna-e valami
sw kompatibilitasi problemat vmi nagyon timing-specifikus programnal. A masik lehetoseg az, hogy a Nick2 is szepen az eredeti utemben olvasgatja az LPB-t, de ha annak masodik byte-ban levo video modban az 110-t talalja, akkor az egyik (vagy tobb, attol fugg mit akarunk beletenni meg az extended LPB-be) LPB olvaso slot ciklusnal raduplaz, azaz tobb mint 2 byte-ot olvas, es oda kerulhetne az uj info. Na persze ezzel az extended LPB nem lesz kompatibilis a normallal, dehat mivel ez tok uj feature, ez nem is baj, viszont az eredeti LPB felepitese, olvasasi idozitese stb teljesen a regi lesz ha nincs beallitva az 110 ertek.

A kovetkezo megoldando problema ott lesz talan, hogy a Nick az LPL es LPH dolgai megvaltoznak talan, hiszen az also negy bitet a Nick generalja, pontosan azert, mert
4 bit az 16 fele kombinacio ami egy LPB hossza. Azaz LPB hossz valtozaskor az LPT cimzeseben is valtozas lesz ... Ezt tenyleg nem tudom hogyan lehetne lekezelni ezek
utan (kezd tul bonyolulta valni), en max arra mennek ra, hogy 84-8F portok kozott legyen par Nick2 specifikus regiszter, amivel megadhato egy "masodik" LPT cim, a 82 es 83 portok altal megadott cimet hasznalna a Nick a "standard" LPB olvasasakor, illetve az "extended LPB" elso 16 byte-janak olvasasakor, viszont az "extended LPT cimrol" olvasna "extended LPB modban" a 16 byte-on fuli byte-ok olvasasakor (az persze kitalalando hogy hany plusz byte legyen, ha eleg 1 darab is, akkor eleg egyszeru). Ha valakit zavar hogy uj I/O portot kell hasznalni, akkor alkalmazhato esetleg a VIC-III-ban ismert trukk is, hogy az uj I/O port rejtve van amig egy "magikus sorozatot" nem kuld az ember egy adott portra, amire azert nehez veletlenul rahibazni.

A fenti elmeleteim elonyenek azt erzem, hogy a full LPB kompatibilitas megmaradt, az 110 mod beallitasaval viszont extended LPB modba kerulunk ahol tovabbi X byte (mennyi kell?) all rendelkezesre egy scanline felepitesenek vezerlesehez, es akkor ide kerulne hogy mi is a videomod ami kell (hiszen az eredeti helyen 110 all annak jelzesre hogy extended LPB), illetve hogy Nick idozites milyen legyen, esetleg tok uj egyeb feature-ok. Ha valaki attol fel hogy ez az 110 felhasznalasra kerult par programban (pl mert beallitasa fekete szint eredemenyez videomemoria tartalmatol fuggetlenul - ez nem tudom igy van-e tippelek), akkor mondhatjuk azt is, hogy az a feature az 110-val csak akkor mukdik ha elotte specko I/O porton kertuk hogy "figyeljen" erre a Nick2.


Quote
Quote
Najo, lehet hogy ez a 15/16 bpp kisse tulzas, tenyleg.

Szerintem is! Én a grafikus módokban eggyel nagyobb felbontással már bõven beérném. A kettõvel jobb már überkirály lenne, de ott már jönne a Video RAM méret gond is...
És arra is gondolni kell, hogy ha nem csak állóképeket akarunk nézegetni, hogy a Z80 meg tudjon bírkozni a kép adatok piszkálásával. Ha egy 7-8 Mhz-es Z80-hoz tennénk egy 2x felbontást tudó Nicket, az nyílván úgyanolyan könnyedén mûködne, mint a mostani felállás.


Na igen, de pl a meglevo 256 szinu modban is dulpazassal egyutt is csak kb 160 pixel
a felbontas, azert negyszeres meg allati szep lenne, mert akkor 320 pixel az mar valami. Masreszt a CPU eroforrasrol meg annyit, hogy ez lehetne kb az, mint anno PC-knel az SVGA modok: senki sem hasznalta "animaciora", de allokepekhez pl jol jon ... Nem kotelezo mindenre hasznalni, nyilvan. Masreszt jo sok felhasznalasaban jol jon, hogy a kep megvaltoztatasa megoldhato csupan az LPT modositasaval (pl gorgetes effekt) anelkul hogy akar egyetlen bitet is at kene irni a videotartalomat kepviselo memoriacimeken!

Plusz egy regebbi orult otletemet is leirom meg :) A fuggoleges visszafutas generalasanal viszonylag temerdek ideig vsync modban kell lenni es egyebek is kellenek. Ezen ido alatt erdemi informaciot nem is olvas igazabol a Nick (marmint ami megjelenik), tehat ezen idot fel lehetne hasznalni arra is, hogy "valamit" (mit? ki kene talalni) olvashatna minden frame megjelenitese elott pl belso RAM-ba, amit aztan onnan tud hasznalni, ezzel nem boritva fel az idozitest meg a fenti byte fetch / slot nyujtas hasznalata nelkul sem.
Title: Re: NICK
Post by: tigrian on 2005.December.29. 16:14:42
Még mindig egyetlen scanline a vizsgálódásunk tárgya.
Azt tudjuk már, hogy egy sort így állítunk elõ: adott idõben kipakoljuk a megfelelõ adatokat. Nézzük, mik ezek az adatok, és honnan jönnek!
Az alapelv egyszerû; a B/W megoldás: elõvesszük a memóriából a neki megfelelõ szóhosszúságot (a mi esetünkben 8 bitet), és kiléptetjük a RAMDAC órajelével.

(http://enterpriseforever.com/userpix/3_pixshift_1.gif)

Igenám, de mi színes pixeleket szeretnénk, 8 bites színmélységgel, akkor tehát 8 db shift regisztert kéne használnunk. Számoljunk! A RAMDAC 7.125 MHz-es, tehát 140 ns-enként kéne 8 bitnyi adatot olvasni a memóriából. Ajjaj, ez nem fog menni... Lassabban kell olvasni azt a fránya memóriát. Sõt, még annál is lassabban, mint ahogy lehetne, mert a proci is akarja használni. Kompromisszumot kell tehát kötni.  A NICK 8-szor ennyi idõ alatt olvas be egy byte-ot.

Quote
Ha a proci akarja elérni a memóriát, miközben a NICK is, akkor a NICK egész egyszerûen "elveszi" a proci órajelét arra az idõre. Brutális, de hatékony megoldás :-)


Ennek persze ára van. Az elérhetõ felbontás és színmélység így egymás konkurrensévé vált (mint ahogy a szépség és az ész szorzata is állandó  :wink:  ) Egy 8 bites adat így tartalmazhat 8 db 2 színû pixelt, vagy 4 db 4 színût, vagy 2 db 16 színût, vagy 1 db 256 színût.
1 bittel persze csak 2 szín közül, 2 bittel csak 4 közül stb. lehet választani. Hogy melyik legyen az a színcsoport, erre szolgál a paletta.
A shift regiszterünk tehát így módosul 2-C (két színû) módban.

(http://enterpriseforever.com/userpix/3_mux2c_1.gif)

A MUX a multiplexer (adatválasztó) jelölése.

4-C módban (figyeld meg, a RAMDAC csak a fele)

(http://enterpriseforever.com/userpix/3_mux4c_1.gif)

16-C módban (a RAMDAC itt csak a negyede)

(http://enterpriseforever.com/userpix/3_mux16c_1.gif)

256-C módban RAMDAC/8 a shift regiszter órajele.
A pixel ezeken a rajzokon már 8 bites (kék vonalak), ahogyan a paletta is.

A szín üzemmód egy teljes scanline-ra vonatkozik, mivelhogy egy sorban csak egyszer lehet megadni.

Az már megvan, hogy hogyan jelenítsük meg a színeket, az van még hátra, hogy honnan vegyük az adatokat, és miként interpretáljuk.
Alapvetõen 4-féle display mód van, a pixel, az attribútum, a karakter, és a speciális. Ezek változataival együtt 7-féle. A NICK két pointert (LD1, LD2) használ az adatok helyének megadására. Egy slot alatt két byte-ot (BUF1, BUF2) olvas be a memóriából.
A pointerek használata és a shift regiszter feltöltése az egyes üzemmódokban:

PIXEL
BUF1 <- (LD1), BUF2 <- (LD1+1)
BUF1 és BUF2 együtt egy 16 bites shift regisztert alkot. LD1-et a memória-ciklusban kettõvel növeli. LD2 ebben az üzemmódban nem használt.

LPIXEL
Ez ugyanaz, mint a PIXEL, de csak egy byte-ot olvas be (így LD1-et csak 1-gyel növeli), és a RAMDAC csak a fele. Fele annyi display memória kell hozzá, egyébként nem tudom, mi értelme.

ATTR
Attribútum mód, ez egy újabb indirekció segítségével 16 színt engedélyez, de slot-onként csak kettõt.
BUF1 <- (LD1), ide kerül a színinformáció (a paletta indexe. Vagyis a palettája :-) )
BUF2 <- (LD2), ez pedig 2-C adat, ezt kell megjeleníteni, ez kerül a shift regiszterbe.

(http://enterpriseforever.com/userpix/3_muxattr_1.gif)

LD2-t növeli 1-gyel. LD1-et is növeli 1-gyel, de minden scanline kezdetén újratölti (bõvebben a modeline-nál). Ez a display mód szolgál a speccy grafika emulálására (ha a modeline 8 soros). Csak 2-C színmóddal van értelme.

CH256
Ez az üzemmód szolgál a karakterfontok megjelenítésére, ismét csak indirekcióval.
BUF1 <- (LD1)
BUF2 <- (LD2 bit7..0, BUF1 bit 7..0)

(http://enterpriseforever.com/userpix/3_ch256_1.gif)

(16-színû módban RAMDAC/4 stb. az órajel, de az mire jó?)
LD1-et növeli minden memória-ciklusban, de scanline elején újratölti. Ez mutat a karakter kódjára. LD2 pedig a fontleíró táblázatra mutat, annak egy adott sorára, ez kerül a shift regiszterbe. LD2 ezért minden scanline elején növekszik 1-gyel (az elõálló pointer tehát 256-tal). A fonttáblázat felépítése így: elõször minden karakter elsõ sora, összesen 256 byte, aztán a második sorok és így tovább.

CH128
Ugyanaz, mint a CH256, de 128 elemû fontkészletre szolgál (megint csak a memória csökkentése az értelme, ill. némi színezés is). LD2-bõl most 9 bitet használunk, BUF1-bõl pedig csak 7-et.
BUF1 <- (LD1)
BUF2 <- (LD2 bit8..0, BUF1 bit 6..0)

CH64
Dettó, mint az elõzõek, ismét csak a felhasznált bitek mások.
BUF1 <- (LD1)
BUF2 <- (LD2 bit9..0, BUF1 bit 5..0)

VSYNC
A NICK ránk bízza a függõleges kioltás és szinkronjel vezérlését (emlékeztek még az analóg részre?), erre szolgál ez az üzemmód. Ilyenkor csak fekete színt (sõt, egyáltalán semmilyen színt sem) szabad kiadni, ezért semmilyen paletta nem felel meg erre a célra. Nem használja ezért a BORDER színt sem ilyenkor. A szinkronjel kezdetét és végét a margókkal tudjuk szabályozni.

--------------------
Mire jó ez a sokféle üzemmód? Hát hogy a SW-esnek könnyebb legyen.  :wink:
No meg persze a procinak is jóval kevesebb dolga van így.

Ez tehát egy scanline elõállítása. Minden sor elején beolvas a NICK 16 byte-ot (LPB: Line Parameter Block), ezek az adatok tartalmazzák az adott sor képzéséhez az adatokat. Több scanline összefogható modeline-ra (ez egy logikai lépcsõ); az LPB egy modeline-ra vonatkozik. Így a megegyezõ módú sorokhoz nem kell új LPB-ket írni.
Nem célom kimásolni ide a dokut, inkább a miérteket és a hogyanokat szeretném bemutatni, de itt most hasznos lehet az LPB-t összefoglalni.

[table color=#232323]
[mrow] LPB+0 [col] SC [col] ScanLine. Azt mondja meg, hogy ez a modeline hány scanline-ból áll. Az értéke bekerül egy számlálóba, ami minden scanline elején növekszik 1-gyel. Amikor 0-vá válik, akkor van vége ennek a modeline-nak. (Ezért ide a komplemens kódot kell írni, tehát 256-scanline).
Pl: 9 soros karakteres üzemmód esetén ez kilenc (ill. 256-9) lesz, attribútum módnál (256-)8 stb.[/table]

[table color=#232323]
[mrow] LPB+1 [col]MB [col] ModeByte.
[row][col] b7 [col] VINT. Az ide írt érték egész egyszerûen kikerül a NICK egyik lábára, ami a DAVE-ben az egyik megszakítás-figyelõ lábra megy. Normál esetben ezt minden félképben (20 msec) egyszer kell 1-esbe tenni, a többi sorban 0-ba. Így áll elõ egy 50 Hz-es megszakítás.

Quote
Itt egy kicsit nem értem a tervezõket. Az élvezérelt megszakítás miatt csak 2 soronként lehet IT-t generálni. A NICK-ben létezik félsoros jel, amivel törölhetné ezt a bitet. Nem értem, miért nem ezt tették.

[row][col] b6..5 [col] Colour Mode. A lehetséges 4 színmód közül itt választhatunk  
[row][col] b4 [col] VRES. Ha itt 0 van, akkor az LD1-et és az LD2-t is újratölti, minden scanline kezdetén. Szép hosszú függõleges sávokat lehet így egyszerûen elõállítani :-)
[row][col] b3..1 [col] Video Mode.

Quote
A 8-ik, hiányzó módot TPIXEL-nek hívják (tiny resolution pixel talán?), de vagy csak nem dokumentált, vagy nem is létezik.


[row][col] b0 [col] Reload. Ide 1-et írva, a Line Pointer Base regisztert (IO port 82..83) újratölti. Errõl majd késõbb.
[/table]

[table color=#232323]
[mrow] LPB+2 [col] LM [col] Left Margin (és egyebek)
[row][col] b7,b6 [col] MSBALT, LSBALT. Ez két érdekes bit, 2-C PIXEL módban ezekkel 8 szín közül lehet 2-t használni. A HW-ünk tehát így módosul:
(http://enterpriseforever.com/userpix/3_muxalt2c_1.gif)

Értelme karakteres kijelzésnél van, ahol a felsõ és az alsó bit a fonttáblában jellemzõen 0. Így könnyedén átszínezhetõ egy-egy karakter képe. 80 karakteres üzemmódban az EXOS ki is használja.

[row][col] b5..0 [col] Left Margin. Az értéke határozza meg (slot egységben), hogy meddig tart a BORDER, ill. hol kezdõdjön az adott üzemmódnak megfelelõ kijelzés.
[/table]

[table color=#232323]
[mrow] LPB+3 [col] RM [col] Right Margin (és egyebek)
[row][col] b7,b6 [col] ALTIND1, ALTIND0. A szerepük hasonló, mint az xSBALT biteknek, de 2-C karakteres üzemmódban, és nem a karakter képe szerint színez, hanem a kódja szerint.

(http://enterpriseforever.com/userpix/3_muxind2c_1.gif)

[row][col] b5..0 [col] Right Margin. Ismét csak slot egységben, idáig tart az adott modeline üzemmódja. Innentõl kezdve BORDER lesz (az aktuális scsanline-ban).
[/table]

[table color=#232323]
[mrow] LPB+4 [col] LD1L, Line Data Pointer 1 low byte
[mrow] LPB+5 [col] LD1H, LD1 high byte.
[row] [col] LD1 mutat a PIXEL módokban a bitképre. Karakter módokban ez mutat a karakter kódjára. ATTR módban az attribútum byte-ra.
[/table]

[table color=#232323]
[mrow] LPB+6 [col] LD2L, LD2 low byte
[mrow] LPB+7 [col] LD2H, LD2 high byte
[row][col] LD2 mutat ATTR módban a pixel adatra, karakter módokban a fonttábla egy adott sorára. PIXEL módokban nem használt.
[/table]

Quote
- LD2 helyén találjuk minden módban a pixel adatot (ami a shift regiszterbe kerül), kivéve a PIXEL módokat. Nem értem, miért ez a distinkció...
- PIXEL módokban LD2 nem használt. A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban. Nem világos, mit érthetnek ezalatt. De talán összefügg az elõzõ megjegyzésemmel.


[table color=#232323]
[mrow] LPB+8..15 [col] A paletta elsõ 8 értéke.
[/table]

------------
Ezzel már össze is állt a kép. Szinte már meg is építettük a csipet  :smt001
Egy (ill. több hasonló) sort már tudunk képezni, innentõl már csak ugrás az egészet összefogni. Legközelebb....
Title: Re: NICK
Post by: lgb on 2005.December.29. 16:31:20
Quote from: "tigrian"
LPIXEL
Ez ugyanaz, mint a PIXEL, de csak egy byte-ot olvas be (így LD1-et csak 1-gyel növeli), és a RAMDAC csak a fele. Fele annyi display memória kell hozzá, egyébként nem tudom, mi értelme.


Pontosan ez :) Azt irtak rola hogy a Nick egyik elonye hogy olyan rendszerbe is hasznalhato legyen, ahol igencsak keves RAM van (ez mondjuk erdekes, ezek szerint a Nick-et nemcsak EP-be szantak?) es ott elony, hogy lehetoseg van fele olyan felbontasra ezzel kevesebb RAM kell. Pont ez jon elo a CH modoknal is, azert van tobb, hogy takarekos legyen ha eleg kisebb megjelenitendo jelkeszlet is. Amugy erdekes ez is, mert legtobb gepen a character generator adatok azok sorban jonnek, azaz ugy ertem, hogy elso karakter elso scan line-ja, elso karakter masodik scan line-ja, stb, aztan jon a masodik karakter. Viszont EP-en ezt ugy megoldottak hogy kvazi tetszoleges karaktermagassag megvalosithato mivel eloszor jon az osszes karakter elso sora, aztan a masodik, stb.
Title: Re: NICK
Post by: lgb on 2005.December.29. 16:54:04
Elmeletemhez meg annyit tennek hozza, hogy az egyeszerusites kedveert extended LPB modban eleg lenne egy "offset" megadasa (ez globalis, vmi uj Nick regiszteren at), ami megad egy fix erteket, ennyit kell hozzadni minden LPB kezdocimehez, hogy megkapjuk az extended LPB ide tartozo reszet. Igy "majdnem" 32 byte lesz egy LPB merete (azert majdnem, mert az hogy extended LPB-vel van-e dolgunk vagy nem az nem azonnal derul ki hanem csak az LPB olvasasa kozben, ezert legalabb 1 byte elveszik), de ez nem baj, mert igy is van minden dogivel. Az extended LPB-ben pl lehetoseg van ujabb 8 szin definialasara, igy 16 szinu modban lehetoseg lenne mind a 16 szint beallitani LPB-bol, fixbias nelkul. A maradek byte-ban lenne egy csomo controll bit, eloszor is pl a video mod, hiszen az 110 invalid kombinacio jelzo az extended LPB-t, es emiatt ez az info mar innen fog jonni, ill pl azt a tenyt, hogy 16 szinu modban regi modon (8 szin definialva) vagy uj modszerrel (a maradek 8 szin is megadhato az extended LPB-ben) kivanjuk-e elerni. Es meg mindig marad jovobeli bovitesekre hely, ezert szigoruan le kene fektetni, hogy a nem hasznalt byte-ok NULLA ertekuek kell hogy legyenek az extended LPB-ben.

Tehat akkor igy nezni ki a Nick elso 8 slot-ja (nullatol kezdve a szamozgatast):

0.slot:

  LPB nulladik byte-janak olvasasa
  LPB elso byte-janak olvasasa, itt derul ki, hogy extended LPB-e vagy nem

1.slot:

  LPB masodik byte-janak olvasasa
  LPB harmadik byte-janak olvasasa
  _HA_ extended LPB, akkor az extended LPB nulladik byte-janak olvasasa
  _HA_ extended LPB, akkor az extended LPB elso byte-janak olvasasa

[...]

7. slot:

  LPB 14. byte-janak olvasasa
  LPB 15. byte-janak olvasasa
  _HA_ extended LPB, akkor az extended LPB 12. byte-janak olvasasa
  _HA_ extended LPB, akkor az extended LPB 13. byte-janak olvasasa

Na persze, ha az extended LPB ertelmezesenek kerdese eleg gyors es mar #0 slot-ban eldol akkor ott is olvashato meg akar 2 byte azonnal ha extended LPB, es akkor az extended LPB resz is pontosan 16 byte lesz, en abbol indultam ki, hogy a #0 slotban a regi idozitessel megy a byte fetch teljesen, tehat ott mar nem lesz "idores" ahhoz hogy az beferjen (majd csak #1-tol), igy viszont az extended LPB csak 14 byte hosszu lesz. De meg boven ez is eleg, mert ha abbol 8 opcionalisan a 16 szinu mod palettajanak hianyzo resze, akkor is marad 6 byte-unk mindenfelere, pl az eredeti videomod abrazolasara, a Nick idozites allitgatasara stb stb. Raadasul ha csak egy offset-et kene kozolni a Nick2-vel hogy az extended LPB az adott LPB-re hol van az LPB baziscimehez kepest, akkor ez az offset felhasznalhato lenne pl annak kontroljara is, hogy engedve van-e a 110 video mod alapjan az extended LPB felismerese, ha pl ez az offset nulla, akkor nem, ha ettol kulonbozo akkor igen, es 256 byte-os egysegekben ertendo, Ez az offset meg lehetne pl a 84-es porton betaplalhato, es ezzel akkor megoldottuk az engedelyezes kerdeset, illetve a hol legyen az LPT LPB-inek extended byte-jai cimu kerdest.
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 17:41:27
Tigrian! Kezd izgatni, hogy miféle Nick leirásod van! Mert se az angol se a magyar EXOS könyvbeli leírás nem említi azt a TPIXEL-t... meg más izgalmasat is említesz, pl:
Quote
A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.
Title: Re: NICK
Post by: MrPrise on 2005.December.29. 17:45:09
Quote from: "Zozosoft"
Tigrian! Kezd izgatni, hogy miféle Nick leirásod van! Mert se az angol se a magyar EXOS könyvbeli leírás nem említi azt a TPIXEL-t... meg más izgalmasat is említesz, pl:
Quote
A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.

Ez nem Tigrian's Pixel mód?  :smt109
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 17:49:43
Quote from: "lgb"

Pontosan ez :) Azt irtak rola hogy a Nick egyik elonye hogy olyan rendszerbe is hasznalhato legyen, ahol igencsak keves RAM van

Vagy az EP-be nem szántak ennyi RAM-ot eleinte? Végülis mikor kezdhették a tervezést? 82-83-ban?
A korabeli gépekhez viszonyítva 16K video RAM teljesen korszerû lett volna, de aztán mire piacra került a gép, nagyon helyesen a 64K mellett döntöttek.
A 191-es porton lehet beállítani, hogy 16/64K az alaplapi RAM. (4116/4164-es IC-k)
Title: Re: NICK
Post by: tigrian on 2005.December.29. 17:52:25
Quote from: "Zozosoft"
Tigrian! Kezd izgatni, hogy miféle Nick leirásod van! Mert se az angol se a magyar EXOS könyvbeli leírás nem említi azt a TPIXEL-t... meg más izgalmasat is említesz, pl:
Quote
A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.

ET1/1 (tehát a legelsõ az összes doku közül :-) )
Az EXOS leírás nem ebbõl, hanem az ET1/3-ból (egy évvel késõbbi) készült, ha jól látom.
Szkenneltem, majd megbeszéljük, hova küldjem.  :wink:
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 17:52:27
Ez az extended LPB gondolat se rossz, én mondjuk az LD1-be tenném a kérdéses LPB-hez tartozó eLPB címét.
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 17:54:04
Quote from: "tigrian"
ET1/1 (tehát a legelsõ az összes doku közül :-) )
Az EXOS leírás nem ebbõl, hanem az ET1/3-ból (egy évvel késõbbi) készült, ha jól látom.
Szkenneltem, majd megbeszéljük, hova küldjem.  :wink:

Ez nagyon izgalmasan hangzik! Milyen kincseid vannak még? :-)
Title: Re: NICK
Post by: tigrian on 2005.December.29. 17:55:29
Quote from: "MrPrise"
...TPIXEL...
Ez nem Tigrian's Pixel mód?  :smt109

(http://enterpriseforever.com/userpix/3_28_spin_1.gif)
Én "tiny resolution pixel mode"-ra tippelek, annyira rászálltak erre a kis memória dologra.
Title: Re: NICK
Post by: tigrian on 2005.December.29. 18:04:02
Quote from: "Zozosoft"
Ez nagyon izgalmasan hangzik! Milyen kincseid vannak még? :-)

(http://enterpriseforever.com/userpix/3_et11_1.gif)
Nekem I.S. dokuk vannak fénymásolva. Az EXOS leírás is ezekbõl készült (ill. u.az).
Ha jól látom, csak két olyan példányom van, ami nem forog közkézen. Az egyik ez a NICK doku, a másik pedig a DAVE issue4 -es változata (az EXOS-ban issue5 van. Még nem néztem meg, mi a különbség.)
Title: Re: NICK
Post by: MrPrise on 2005.December.29. 18:06:09
Quote from: "tigrian"
Quote from: "Zozosoft"
Ez nagyon izgalmasan hangzik! Milyen kincseid vannak még? :-)

(http://enterpriseforever.com/userpix/3_et11_1.gif)
Nekem IS dokuk vannak fénymásolva. Az EXOS leírás is ezekbõl készült (ill. u.az).
Ha jól látom, csak két olyan példányom van, ami nem forog közkézen.

És még nincs bescannelve? ;-)
Title: Re: NICK
Post by: tigrian on 2005.December.29. 18:08:17
Quote from: "MrPrise"
És még nincs bescannelve? ;-)

Akkor most én mondom, hogy vissza kéne olvasni...  :wink:
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 18:12:43
Quote from: "tigrian"
Nekem I.S. dokuk vannak fénymásolva.

Nagyon izgalmas! Honnan szereztél te ilyeneket? :-)
Kár hogy az EXDOS-ból nem jutott :(
Title: Re: NICK
Post by: MrPrise on 2005.December.29. 18:13:21
Quote from: "tigrian"
Quote from: "MrPrise"
És még nincs bescannelve? ;-)

Akkor most én mondom, hogy vissza kéne olvasni...  :wink:

Ja. Az a pár kimaradt ;-)
Title: Re: NICK
Post by: tigrian on 2005.December.29. 18:17:26
Quote from: "Zozosoft"
Quote from: "tigrian"
Nekem I.S. dokuk vannak fénymásolva.

Nagyon izgalmas! Honnan szereztél te ilyeneket? :-)

Annak idején baráttól kaptam, a SZTAKI-ból.
Quote
Kár hogy az EXDOS-ból nem jutott :(

Dehogynem! Mondom, ez az EXOS doku. Megvan a többi is (kernel, video, sound, printer, serial/net stb.), de ezek HTML-ben olvashatók lgb mirrorján, ezért nem említettem.
Title: Re: NICK
Post by: tigrian on 2005.December.29. 18:22:54
Aki kéri, annak elküldöm.
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 18:31:31
Quote from: "tigrian"

Quote
Kár hogy az EXDOS-ból nem jutott :(

Dehogynem! Mondom, ez az EXOS doku.

Értem, de én az EXDOS-t hiányolom :-) amibõl csak a tartalom jegyzék van az angol oldal mirrorján :(
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 18:32:20
Quote from: "tigrian"
http://tigrian.fw.hu/nicksamp.zip

hiba 404 :(
Title: Re: NICK
Post by: tigrian on 2005.December.29. 18:36:59
Quote from: "Zozosoft"
Quote from: "tigrian"
http://tigrian.fw.hu/nicksamp.zip

hiba 404 :(

Hihi, a freeweb moderálta, gondolom, a mérete miatt. O.K., párosítd a file-nevet a másik domain-nel, úgy is megtalálod.  :wink:
Title: Re: NICK
Post by: Zozosoft on 2005.December.29. 18:39:01
Quote from: "tigrian"
párosítd a file-nevet a másik domain-nel, úgy is megtalálod.  :wink:

Megvan, jövöget lefelé :-)

Update: lent van mindkettõ :)
Title: Re: NICK
Post by: tigrian on 2005.December.29. 19:30:13
Quote from: "Zozosoft"
...az EXDOS-t hiányolom :-) amibõl csak a tartalom jegyzék van az angol oldal mirrorján :(

Oh, bocsánat, figyelmetlenül olvastam. Hát az valóban nincs.  :(
Title: Re: NICK
Post by: lgb on 2005.December.29. 19:38:22
Quote from: "Zozosoft"
Ez az extended LPB gondolat se rossz, én mondjuk az LD1-be tenném a kérdéses LPB-hez tartozó eLPB címét.


Hmmm, az sem rossz otlet ... Aztan magaban az eLPB-n lenne akkor a "hianyzo" LD1, amit felhasznaltunk mas celra az eLPB kapcsan. Egyetlen hatrany, hogy az LD1 hatrebb van ugye az LPB-ben ezert mire oda eljutunk addig mar lement az LPB olvasasara szant 8 slot-bol 3 slot (ha magat az LD1 olvasasat is nezzuk) azaz utana meg dupla annyi byte fetch-el slot-onkent se hozhato be eleg byte, illetve igen, csak akkor le kell mondanunk pl a 16 szinu uzemmod kiterjeszteserol (full 16 szinu paletta fixbias nelkul). Masreszt igyekeztem a legkevesebbet valtoztatni az LPB 16 byte-jaban meg eLPB modban is, hogy esetleges sw atirasoknal pl ha valaki csak vizszintes felbontast akar novelni akkor ne kelljen neki tul sokmindent atirni.

Amugy a masik ami meg Cool lehetne Nick2-ben az hogy az EP palette is legyen programozhato, azaz pl jojjon ki 24 bites adat per pixel a D/A atalakitas elott, Nick modban maradna a max 256 szin, de megmondhatnad hogy ez meg az az EP "szin" milyen valodi szint jelent. Ez 256 szinu modnal egy indexelt eleres tehat, de pl 16 szinunel mar duplan indexelt (az LPB-ben levo palette info EP szint az az meg index a valod RGB color space-ben pl). Amugy ez nem uj otlet, ez volt pl EGA/VGA valtasnal: az erdeti EGA paletta megvan VGA-n is de valojaban az is "kersztulmegy" aztan a 256 palette regiszter elso X erteken, csakhogy ezek default erteke pont azok ami EGA-n lenne. Vagy hasonlo, ertitek, most nem magyarazom 3C8/3C9 port szinen a VGA kartya programozasat mert nem ide tartozik :)
Title: Re: NICK
Post by: tigrian on 2006.January.02. 23:54:11
Átolvastam, amit itt a NICK bõvítésérõl fejtegettetek. Nem igazán értem, mit akartok bonyolítani.
Az odáig rendben, hogy jó lenne egy CH mód, nagyobb felbontással, hogy a 80 karakteres szöveg is gyorsabb legyen. Az is O.K., hogy grafikára is jó lenne egy nagyobb felbontású/színû üzemmód.
Azt viszont nem értem, hogy miért akarjátok ezt az LPB-be belezsúfolni. Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva, legalábbis a grafikát illetõen. A karakteres módot is meg lehet oldni, anélkül, hogy az LPB-t tolgozgatnánk.
Title: Re: NICK
Post by: Zozosoft on 2006.January.03. 10:12:00
Quote from: "tigrian"
Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva,

Na ez az ami nekem nem tetszik! Mert így ha régi programot, vagy akárcsak EXOS-t futatsz, az csak a régi Nicken látszódna, az új kártyán nem.
Ezért nekem az lenne az alapkövetelményem, hogy az új Nick pontosan ugyanazt csinálja mint a régi! Olvassa az LPT-t, stb, így minden jelenlegi program látszodna az új kártyán.
Esetleg lehetne úgy, hogy átkapcsolni egy nem LPT-s módra, de ez nekem nem tetszik, nem EP-s megoldás :)
LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.
Én alapvetõen másra nem is vágynék :) Ha karaktermódokat is akarjuk tuningolni, arra is van egy ötletem: a VRES bit-et jelenleg nullázni kell. Ennek 1-es értéke jelenthetné a HW80-as módot. Így akkor nem kéne mindenféle extended LPT-ket kitalálni.

De ez most ugyis csak egy ötlet roham, hogy elüssük az idõt addig, míg jön a Nick elõadás következõ része :) :) :)
Title: Re: NICK
Post by: lgb on 2006.January.03. 10:33:05
Quote from: "tigrian"
Átolvastam, amit itt a NICK bõvítésérõl fejtegettetek. Nem igazán értem, mit akartok bonyolítani.
Az odáig rendben, hogy jó lenne egy CH mód, nagyobb felbontással, hogy a 80 karakteres szöveg is gyorsabb legyen. Az is O.K., hogy grafikára is jó lenne egy nagyobb felbontású/színû üzemmód.
Azt viszont nem értem, hogy miért akarjátok ezt az LPB-be belezsúfolni. Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva, legalábbis a grafikát illetõen. A karakteres módot is meg lehet oldni, anélkül, hogy az LPB-t tolgozgatnánk.


Azert, hogy full compatible legyen visszamenoleg is! Ez persze alapkovetelmeny, ez vita targya nem lehet. Plusz igy az is megoldhato, hogy akar keverd a dolgokat, es a kepernyo felso fele az pl valami uj felbontas, az alja meg regi full nick compatible. Amugy szerintem a Nick-ben pont az a jo hogy legtobb akkori (es mai ... :) geptol elteroen nem egy globalis videomod van, hanem LPT-ben LPB-kent valtoztathatod, es ha EP bovites akkor nem artana megorizni legalabb az EP filozofia alapjait, kulonben az mar ugye nem EP hanem valami mas, akkor ilyen erovel egy mai PC-t is lehet hasznlani, hisz az ugyis sokkal gyorsabb es jobb a grafikaja is :) A boncolgatott megoldas elonye, hogy 100%-ban visszmenoleg kompatibilis, illetve az uj feature-ok keverhetoek egy screen-et a regiekkel anelkul hogy a "regi resznel" megszunne a kompatibilitas.

Ha az ember akar pl FPGA-ban szintetizalni egy Nicket, plusz feature-okkel, akkor amugy is (a kompatibilitas miatt) implementalni kell az eredeti Nick mudkodest IS, akkor meg teljesen logikus hogy azt a mechanizmust bovitsuk az "extended" uzemmodban (pl tobb byte fetch-elese stb), minthogy emelett letrehozz egy teljsen kulonbozo elven mukodo reszt is, nem?
Title: Re: NICK
Post by: Zozosoft on 2006.January.03. 10:42:25
Amúgy meg itt a topic fõszereplõje:
http://enterprise.8bit.hu/Alapgep/Picture/NICK.jpg

Érdekes, hogy ebben a korai (02944) gépben amiben fotóztam, még nincs hûtés rajta. Az újabb gépekben egy rézlemez van rátéve: http://enterprise.8bit.hu/Alapgep/Picture/elanenterprisepcb-h.jpg
Title: Re: NICK
Post by: lgb on 2006.January.03. 10:49:49
Quote from: "Zozosoft"
Quote from: "tigrian"
Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva,

Na ez az ami nekem nem tetszik! Mert így ha régi programot, vagy akárcsak EXOS-t futatsz, az csak a régi Nicken látszódna, az új kártyán nem.
Ezért nekem az lenne az alapkövetelményem, hogy az új Nick pontosan ugyanazt csinálja mint a régi! Olvassa az LPT-t, stb, így minden jelenlegi program látszodna az új kártyán.
Esetleg lehetne úgy, hogy átkapcsolni egy nem LPT-s módra, de ez nekem nem tetszik, nem EP-s megoldás :)


Tokeltesen egyet ertek! Azert ne egy PC-t epitsunk ... Az mar van jo par. Ha mar mindenkeppen kell bovitett EP (van aki ezzel sem ert egyet ugye ...) akkor meg kene probalni tenyleg EP-t epiteni, azaz legalabb az EP szellemet tovabbvinni.

Quote from: "Zozosoft"

LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.


pontosan!

Quote from: "Zozosoft"

Én alapvetõen másra nem is vágynék :) Ha karaktermódokat is akarjuk tuningolni, arra is van egy ötletem: a VRES bit-et jelenleg nullázni kell. Ennek 1-es értéke jelenthetné a HW80-as módot. Így akkor nem kéne mindenféle extended LPT-ket kitalálni.

De ez most ugyis csak egy ötlet roham, hogy elüssük az idõt addig, míg jön a Nick elõadás következõ része :) :) :)


Az meg csunya. A VRES nullazasnak igenye az a Nick filozofia eredmenye: a VRES az ugye
az ha jol emlexem, hogyha az adott LPB tobb scanline-ra vonatkozik (LPB legelso byte-ja) akkor minden az adott LPB-hez tartozo scanline-ra ujra visszaallitsa az LD1 es LD2 erteket, vagy ne. Ennek altalaban grafikus felbontasnal az az ertelme amit a VRES jelent ("vertical resolution"), azaz akkor az adott scanline-okra ugyanaz fog latszodni. Azonban karakteres modnal azert kell nullazni, mert ugye ilyenkor egy LPB valojaban egy KARAKTERSORT ir le, es a scanline-ok szama adja az adott sorban a fontok magassagat, ehhez viszont persze nem art ha az LD1 es LD2 erteke visszall minden scanline utan, hiszen ugyanazt a karaktert jelenitjuk meg csak mindig mas sorat, egymas utan. Ettol persze az meg lehetne amit akarsz, csak kicsit "csorbitja" a filozofiat, plusz imho az eredeti Nick mukodne talan (valakinel tapasztalat?) akkor is ha CH* modokban a VRES nem nulla, csakhat akkor eleg "fura" eredmenye lenne, de ki tudja hogy nem hasznalja-e ki ezt valaki valamire? Na ha a fenti logikamban hiba van akkor javitsatok ki please :)

Ez eLPB otlete nekem azert jon be, mert termeszetes modon adodik: nagyobb felbontasban ugyis novelni kell a slot-onkent olvashato byte-ok szamat, es mivel ugye az elso nyolc slot van fenntartva az LPB olvasasara, akkor pl tobb byte beolvasasaval azonnal hosszabb LPB-t is olvashatunk, es akkor a kerdes le van zarva, egyszeruen, a filozofiahoz illeszkedo modon bovitettunk, plusz kaptunk jo par byte-ot meg az LPB-be amibe esetleg
majd kesobb meg tobb dolog is beteheto. Plusz persze "normal" modban (nincs eLPB) komatatibilis. Persze az is lehetne, hogy lenne egy uj Nick I/O port (pl a 84h) ahol azt mondod a Nick-nek (globalis beallitas) hogy ezentul 32 byte egy LPB es nem 16, ami pl nemes egyszeruseggel annyi hogy 2 helyett 4 byte olvasasa lenne ezentul solt-onkent, es akkor ebbol adodik a 32 bytes-os LPB es a dupla vizszintes felbontas is egyarant. Ez viszont nekem azert nem feltetlenul tetszik, mert a Nick filozofiaban pont az tetszik
hogy igen keves "globalis" dolog van amit pl I/O porton kell beallitani, es minden mast "ugy szed fel" a Nick mukodese kozben, teljsen automatikusan, nulla CPU behatassal elerheto az ami mas gepen nem (pl C64-en raster interrupt kell aztan ott a program pl modositja a VIC-II megfelelo regisztereit). Masreszt tovabbi elony, hogy keverheto akar scanline-onkent az eLPB elkepzelessel az hogy pl egy LPB az normal a kovetkezo az "extended", ami globalissan nem menne. Ez azert is jo, mert hacsak nem akarunk egy total durva uj gepet epiteni, a videoram az 64K, es nem feltetlenul eleg ha mindent megduplazunk (vagy negyszerezunk?) egyes modokban, neha erdemes lenne ugy takarekoskodni a programoknak hogy pl a screen egy reszen van csak ez. Vagy akar lehetne nagyobb video RAM is pl ugy hogy a CPU az utolso negy szegmensen (FC-FF) esetleg belapozhatoan lathat
a videoram tobb resze, a Nick meg pl az eLPB-bol veheti hogy a videoramja melyik 64-s
szeletebol kell toltenie ha LD1 es/vagy LD2 alapjan kell fetch-elni (reszleteket persze ki kene dolgozni), az LPB byte fetch az pl fixen mehetne a nullas video ram "laprol" ami egyben a default Nick config is. Ez persze eleg messzire vezethet, itt csak azt kivanom jelezni hogy az LPB az egy jo dolog, es egy csomo mindent meg lehet vele rugalmasan csinalni (ilyeneket is amit irtam es amit most nem feltetlenul akarunk), tehat erdemes a Nick bovites soran ugyanugy LPB-ben tarolni mindent amit csak lehet, es nem valami "globalis" beallitasokban gondolkodni ...
Title: Re: NICK
Post by: Zozosoft on 2006.January.03. 10:56:08
Quote from: "lgb"
a Nick filozofiaban pont az tetszik, hogy igen keves "globalis" dolog van amit pl I/O porton kell beallitani, es minden mast "ugy szed fel" a Nick mukodese kozben, teljsen automatikusan, nulla CPU behatassal

Teljesen egyetértek!!!
Title: Re: NICK
Post by: tigrian on 2006.January.04. 01:43:02
Quote from: "Zozosoft"
Ezért nekem az lenne az alapkövetelményem, hogy az új Nick pontosan ugyanazt csinálja mint a régi! Olvassa az LPT-t, stb, így minden jelenlegi program látszodna az új kártyán.

Ebben teljesen egyetértünk.
Quote from: "Zozosoft"
LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.

Egyetértek, szerintem is a NICK a legjellemzõbb elem a vasban. Azzal már nem feltétlenül, hogy az jó dolog, ami abban van.
Quote from: "Zozosoft"
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.

Na ebben tér el a véleményünk. Minden adott a nagyobb felbontáshoz, minden üzemmódban, egyedül csak a RAMDAC-ot kell felgyorsítani. Ezt pedig szerintem globálisan érdemes, nem pedig soronként. Kár tehát az LPT-be piszkítani. Ugyanazt az LPT-t (ill. majdnem ugyanazt, a pointereket újra kell számolni) egy új vas nagyobb felbontással jeleníthet meg, a NICK pedig annak a felét, negyedét stb (vagyis egy ablakot belõle). Tehát semmiféle új módot nem kell kitalálni.
És ez szépen bele is illik az EXOS-ba.  :wink:
Quote from: "Zozosoft"

Én alapvetõen másra nem is vágynék :) Ha karaktermódokat is akarjuk tuningolni...

Hát nem ugyanazt mondjuk? :-) kicsit finomított grafika, plusz 80 karakteres CH üzemmód.
Quote from: "Zozosoft"

De ez most ugyis csak egy ötlet roham, hogy elüssük az idõt addig, míg jön a Nick elõadás következõ része :) :) :)

Hát nem tudom. Úgy tûnik, semmi újat nem mondtam, ezek után sem fogok nyilván. És baromira utálok fölöslegesen dolgozni. Majd meglátjuk.
(lbg talán el sem olvasta, hiszen úgy már akkor bele kellett volna kötnie a VRES-be.
Quote from: "lgb"
...Azonban karakteres modnal azert kell nullazni...

NEM, minden sor elején 1-gyel nõ az LD2 értéke. Ha azt is újratöltöd, csak a legfelsõ sort ismételgeted.)

De igaz, valóban csak elmélkedünk. Ennek az egésznek semmi értelme, amíg egy (vagy több) programnak nincs rá igénye.
Title: Re: NICK
Post by: lgb on 2006.January.04. 08:21:52
Quote from: "tigrian"
Quote from: "Zozosoft"
LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.

Egyetértek, szerintem is a NICK a legjellemzõbb elem a vasban. Azzal már nem feltétlenül, hogy az jó dolog, ami abban van.


Hat pedig ha azzal nem ertesz egyet, akkor mar nem EP-t akarsz epiteni ha teljesen mas logikaval akarsz tovabbmenni, akkor ennek semmi koze tobbe az EP-hez ...

Quote

Quote from: "Zozosoft"
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.

Na ebben tér el a véleményünk. Minden adott a nagyobb felbontáshoz, minden üzemmódban, egyedül csak a RAMDAC-ot kell felgyorsítani. Ezt pedig szerintem globálisan érdemes, nem pedig soronként. Kár tehát az LPT-be piszkítani. Ugyanazt az LPT-t (ill. majdnem ugyanazt, a pointereket újra kell számolni) egy új vas nagyobb felbontással jeleníthet meg, a NICK pedig annak a felét, negyedét stb (vagyis egy ablakot belõle). Tehát semmiféle új módot nem kell kitalálni.
És ez szépen bele is illik az EXOS-ba.  :wink:


Ez viszont nem olyan szep. Az eLPB SOKKAL jobb otlet, foleg ha nyesz tizeniksz plusz byte-ot minden LPB-hez (!) az azert szerintem _sokkal_ tobb hasznot tud hozni mint az a lehetoseg hogy par dolgot globalisan tudsz csak meghatarozni. Szerintem ez sokkal jobb, Nick szellemisegehez sokkal jobban illo, es kesobbiekben is tovabb bovitheto megoldas.

Quote
Quote from: "lgb"
...Azonban karakteres modnal azert kell nullazni...

NEM, minden sor elején 1-gyel nõ az LD2 értéke. Ha azt is újratöltöd, csak a legfelsõ sort ismételgeted.)


Ize, ja lehet, de az LD1-et nem :) Kozben megfeledkeztem arrol az "aprosagrol" hogy EP-n kisse maskeppen muxik a chargen mint legtobb mas gepen, itt eloszor minden char elso sora van leirva, aztan a masodik stb, mig mashol altalaban eloszor az elso char osszes sora, stb.
Title: Re: NICK
Post by: Ferro73 on 2007.February.18. 20:48:05
Kérdésem volna:
A CPU  I/O utasitásnál IN a,(0B5h)  A0-A7=0B5H  A8-A15= A regiszter
viszont a bövítö csatlakozon már az A14-A15 a NICK generálja
ilyenkor mi jelenik meg rajta a CPU A14-A15 vagy valami más?
Title: Re: NICK
Post by: Zozosoft on 2007.February.18. 21:38:17
Nem a Nick,hanem a Dave, de jó a kérdés.
A buszon mindig a Dave-böl jövö A14-15 van,ami az éppen belapozott szegmensektöl függ. Ezért EP-n nem használhato a 16 bites I/O cimzéses trükk, amit Pl Spectrumon is használnak.
Ezért is volt hibás az eredeti Spectrum Emulátorban a billentyüzet figyelés. A javított ROM programban úgy válogattam össze a belapozott szegmenseket,hogy mind a négy laphoz különbözö A14-15 kombinácio jöjjön ki a buszra.
Title: Re: NICK
Post by: Ferro73 on 2007.February.18. 23:20:23
Ha jól emlékszem van 1-2 üres érinkezö oda ki lehet vezetni a CPU a14-A15 lábait.

ha nem akkor csak gépen belül lehet megoldani ezt aproblémát.

más a kép vissza futás ugy jellzi a NIKC hogy a Vsync és a Hsync X mikrosec H-H tartja vagy valami ilyesmi nem?
Title: Re: NICK
Post by: Jubatian on 2010.December.12. 15:34:07
Üdv!

Bocs, hogy régi témát forgatok fel, ez szerintem ide passzol: Nick.

Szóval beszereztem eme régi gépet, az EP128-at, mint életem elsõ igazi retró masináját, persze így másodkézbõl annak megszokott problémáival terhelten. Ugye-ugye, az a kis pöcök ott a jobb alsó sarokban, hát az sajnos nem mûködött oly szépen, pedig kellett volna némi BASIC-eléshez is. Fóliát ragasztgatni nem lehet, viszont egy Atari joyhoz egy 9 tûs csatit csak ki lehet kanyarítani valahogy.

Hát le is borzadtam kissé, most, hogy elemeire szedtem a gépet: A 64K RAM bõvítõ panel alatt az a rézlap csak ott lityegett a levegõben, fogta még éppen az átkötés drótjához a "rágógumi", de attól még aligha sokat segített a Nick-en ebben az állapotában (Hála a jó égnek, eme elszabadult fémdarab azért semmihez hozzá nem ért korábbi bekapcsolások során!). A rézlap alján szépen kivehetõen olvasható a Nick felirat, meg a sorozatszám, az IC-n semmi... Megoldottam, kis tisztítás, enyhe ledörzsölés, hõvezetõpaszta és pillanatragasztó, a masina mûködik :)

Gyakori lehet az ilyesmi? Csak szólok akkor, lehet, nem árt benézni a háztetõ alá!

(A joystick-hadmûvelet is sikerült: A négy irányt és az ENTER billenytût kivittem egy Atari szabványra drótozott csatira. Joystickom nem volt, így mindenféle hulladékból meg pár mikrokapcsolóból azt is csináltam :D )
Title: Re: NICK
Post by: Zozosoft on 2010.December.12. 19:37:52
Gyakori az a leesett fémlemez, így 25 év után kezd elengedni a ragasztó. Ujabb sorozatú Nicknek nem is kell :-)
Title: Re: NICK
Post by: Jubatian on 2010.December.12. 20:40:47
Jaa! :) - pedig igencsak megijedtem, hogy "Szent anyám, megfõztem a Nick-emet!!" így eddig alig párszor kipróbálva a masinát. Na, de akkor most már biztos jól van neki, a Core2duókhoz szánt hõvezetõ paszta biztos elbír azzal a kis fûtéssel odabenn :D
Title: Re: NICK
Post by: Tuby128 on 2011.January.24. 19:01:19
Az ET1/1 szkenn kellene nekem
http://tigrian.fw.hu/nicksamp.zip oldal nem létezik!

Kérlek segítsetek,hogy honnan tudnám megszerezni, mert szeretnék lefekvés elõtt esti mesét olvasni! (még ma ha lehet)
Title: Re: NICK
Post by: IstvanV on 2011.January.24. 19:31:08
Az ET1/1 szkenn kellene nekem
http://tigrian.fw.hu/nicksamp.zip oldal nem létezik!

Ha ez a régi (2.0) EXOS dokumentáció akar lenni, akkor megtalálható itt (http://gafz.enterpriseforever.com/PDF/EXOS20_technical_information.pdf) (ebben "ET1/1" a NICK leírás).
Pontosan milyen információt keresel egyébként ?
Title: Re: NICK
Post by: IstvanV on 2011.January.25. 12:29:00
No, tudjuk tehát, mik a lehetõségek. Az EP-ben ki is választották a maximumot, 7.125 MHz a RAMDAC (elvileg).

Quote
A RAMDAC választása ugyan tetszõleges, a sor hossza viszont szigorúan kötött, a színsegévivõ órajelével szinkronban kell lennie. Elrettentésül: (284-0,25) * 15625 Hz = 4433618,75 Hz, ez a színsegédvivõ.
Gyakorlati okokból a NICK órajele a RAMDAC kétszerese. Mivel a NICK ugyanazt a jelet használja a RAMDAC-nak is és a sorképzésre is, ezért további kötöttségek vannak. Az órajelnek a sorfreki (15625 Hz) többszörösének kell lennie. Feltéve, hogy még 16-tal is osztható az arányuk, így csak bizonyos értékek jöhetnek szóba. A doku szerint 57*16 = 64 usec. Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.

Ezt már sikerült tesztekkel megállapítani, hogy a NICK órajele nem pontosan 14.25 MHz, hanem valamivel kevesebb (lásd
itt (http://enterpriseforever.com/emulatorok/idozitesi_problemak_az_emulatorokban-t380.0.html;msg14863#msg14863)). Mivel egy sor a NICK-nél pontosan 284 színsegédvivő ciklus (a szabványos 283.75 helyett), és egy sor 57 karakter, ezért a tényleges frekvenciák így számíthatók:
  - színsegédvivő frekvencia fPAL = 17734475 / 4 = 4433618.75 Hz
  - sorfrekvencia = fPAL / 284 = 15611.33 Hz (a szabványos 15625 Hz helyett - ez egyes "digitális" TV-knél és TV kártyáknál problémát is okoz)
  - karakter frekvencia = fPAL * 57 / 284 = 889846.02 Hz (ez ismerős lehet az ep128emu órajel konfigurációjából :))
  - NICK bemeneti órajel = fPAL * 57 * 16 / 284 = 14237536.27 Hz
  - képfrekvencia = fPAL / 284 / 312 = 50.0363 Hz
Title: Re: NICK
Post by: IstvanV on 2011.January.25. 13:15:59
ATTR
Attribútum mód, ez egy újabb indirekció segítségével 16 színt engedélyez, de slot-onként csak kettõt.
BUF1 <- (LD1), ide kerül a színinformáció (a paletta indexe. Vagyis a palettája :-) )
BUF2 <- (LD2), ez pedig 2-C adat, ezt kell megjeleníteni, ez kerül a shift regiszterbe.

Az attribútum mód működése nem dokumentált (de nem különösebben hasznos) nem 2 színű módokban:
  - 256 színnél nincs hatása, gyakorlatilag ugyanaz, mint a 256 színű LPIXEL mód, csak a pixeleket az LD2 címről olvassa
  - 4 és 16 színű módban a paletta szín 0. bitje alapján választ "papír" vagy "tinta" színt, a többi bitet figyelmen kívül hagyja; a 4 és 16 színű mód pixel byte kódolása miatt ez gyakorlatilag azt jelenti, hogy csak a pixel byte felső 4 bitje jelenik meg kétszeres nagyítással (4 színű módban), vagy a felső 2 bit négyszeresre nagyítva (16 színű módban) a normál 2 színű attribútum módhoz képest

Quote
[row][col] b7 [col] VINT. Az ide írt érték egész egyszerûen kikerül a NICK egyik lábára, ami a DAVE-ben az egyik megszakítás-figyelõ lábra megy. Normál esetben ezt minden félképben (20 msec) egyszer kell 1-esbe tenni, a többi sorban 0-ba. Így áll elõ egy 50 Hz-es megszakítás.

A video megszakítás talán nem egészen egyértelmű az EXOS dokumentáció alapján, tehát pontosan így működik:
  - a DAVE B4h portjának a 4. bitjén gyakorlatilag a VINT kimenet aktuális állapota található (tehát amikor VINT=1, akkor itt is 1 van)
  - a VINT lefutó éle váltja ki a megszakítást, tehát az a beállított VINT-es LPB után történik, és nem az elején
  - a B4h port 5. bitjén a video megszakítás kérésének aktuális állapota olvasható (a VINT lefutó élére vált 1-re); ha nincs engedélyezve a video megszakítás, akkor itt mindig 0 van

Quote
[row][col] b4 [col] VRES. Ha itt 0 van, akkor az LD1-et és az LD2-t is újratölti, minden scanline kezdetén. Szép hosszú függõleges sávokat lehet így egyszerûen elõállítani :-)

Ez így nem egészen igaz, az LD2-t nem tölti újra, csak az LD1-et. Ez a tulajdonsága hasznos a karakteres módokban (ahol az LD2 minden sor után a karakterkészlet méretével növekszik), és attribútum módben (így lehetséges karakter méretű attribútum cellák létrehozása VRES=0 használatával).

Quote
Quote
A 8-ik, hiányzó módot TPIXEL-nek hívják (tiny resolution pixel talán?), de vagy csak nem dokumentált, vagy nem is létezik.

Az "érvénytelen" mód valójában olyan karakteres módnak tekinthető, amely a pixel adatot mindig FFFFh video címről olvassa :) Tehát talán "CH0" módnak lehetne nevezni, de sok gyakorlati haszna nincs. Azért a karakteres módokhoz van legközelebb, mert egy byte-ot olvas az LD1 címről (ez az ALTIND0/ALTIND1 bitekkel ellenőrizhető), majd a következő byte-ot az FFFFh címről (ez lesz az LPIXEL felbontású pixel byte), és nem végez ATTR műveletet a színeken.

Quote
LPB+2  LM  Left Margin (és egyebek)
b7,b6 MSBALT, LSBALT. Ez két érdekes bit, 2-C PIXEL módban ezekkel 8 szín közül lehet 2-t használni. A HW-ünk tehát így módosul:

LPB+3  RM  Right Margin (és egyebek)
b7,b6  ALTIND1, ALTIND0. A szerepük hasonló, mint az xSBALT biteknek, de 2-C karakteres üzemmódban, és nem a karakter képe szerint színez, hanem a kódja szerint.

Ezek az EXOS dokumentációban (legalábbis a 2.1 verzióban biztosan) zavaró módon össze vannak keverve :roll: Helyesen:
  - LM bit 7 = MSBALT
  - LM bit 6 = LSBALT
  - RM bit 7 = ALTIND0
  - RM bit 6 = ALTIND1
Érdemes megjegyezni, hogy ezek minden video és szín módban működnek, akkor is, ha a műveletnek egyébként nincs értelme, ha a színeken nem is mindig van látható hatásuk (256 színű és/vagy attribútum módban nem tudják megváltoztatni a színeket, de az MSBALT/LSBALT ilyenkor is levágja a megfelelő pixel byte bitet).
A működésük:
  - MSBALT: ha a pixel byte (függetlenül attól, hogy az LD1 vagy LD2 címről van) 7. bitje 1, akkor a paletta színek választásakor OR műveletet végez 2-vel, és 0-ra állítja a pixel byte 7. bitjét
  - LSBALT: ha a pixel byte 0. bitje 1, akkor a paletta szín index 2. bitjét állítja be (OR 4), és a pixel byte 0. bitjét törli
  - ALTIND1: ha az LD1 byte (függetlenül attól, hogy mi a funkciója) 7. bitje 1, akkor OR 2 műveletet végez a paletta szín indexen, de nem törli az LD1 byte 7. bitjét
  - ALTIND0: ha az LD1 byte 6, bitje 1, akkor OR 4 műveletet végez a paletta színek választásakor, de nem törli az LD1 byte 6. bitjét
Title: Re: NICK
Post by: Zozosoft on 2011.January.25. 14:12:38
Az "érvénytelen" mód valójában olyan karakteres módnak tekinthetõ, amely a pixel adatot mindig FFFFh video címrõl olvassa :)
Az ilyen elvetemült dolgokat hogyan sikerült ki kísérletezni?

És akkor az emu mindezen nem dokumentált érdekességeket is tudja?
Title: Re: NICK
Post by: IstvanV on 2011.January.25. 14:27:06
Az ilyen elvetemült dolgokat hogyan sikerült ki kísérletezni?

Egyszerűen: ki kell próbálni igazi gépen :) És kísérletezni, hogy mi történik a paraméterek különböző kombinációival. Miután láttam, hogy ugyanaz az egy pixel byte ismétlődik az "érvénytelen" módban, sejteni lehetett, hogy azt az FFFFh vagy (esetleg 0000h) címről olvassa, csak ellenőrizni kellett, hogy valóban így van-e.
Általában így lehet megérteni a hardver működését: tesztelni a lehető legtöbb különböző módon, majd ha az eredmények alapján van valamilyen elmélet a működéséről, akkor azt újabb tesztekkel ellenőrizni.

Quote
És akkor az emu mindezen nem dokumentált érdekességeket is tudja?

Amiket az előbb leírtam, igen (ha nincs bug). A szín mód, video mód, és LSBALT/MSBALT/ALTIND0/ALTIND1 512 lehetséges kombinációja elvileg mind emulált.
Title: Re: NICK
Post by: Ferro73 on 2011.January.25. 18:42:48
Ha jól értelmeztem a karakteres modot miszerint 00. karakter 1 sora; 01. karakter 1.sora...... 255. karakter 1.sora; 00.karakter 2.sora .....
a karakter sor 9 pixel sorból áll.
egy 2x2 /16x18 pixel/ 4 karakter normál modban egy Sprite
deha a karakter sor 16 pixel sorbol állna akkor 4 szinnel 256   2x1 /8*16+8*16/ 2 karakter azaz 2x több grafika jelenithetö meg egy karakter táblával ez lenne  a játéktér az információ /idö, pontszám.../ normál 8-9 pixel soros karakteres sor más karakter készlettel és azok nak sem kellenekülön rutin.

Olyat lehet-e /miért is ne lehetne / mikor egy játék vált menüröl játéktérre,
ilyenkor elöre megszerkeztett LPT-menü C800h -> LPT-játéktér CB00h   out ...... vibráció nélkül ?
Title: Re: NICK
Post by: Ferro73 on 2011.January.26. 15:35:10
kérdés a VIRQ mindig megjelenik a NICK 32. lábán és ha igen akkor elméletileg az 50 vagy 25 Hz ?

egy másik kérdés Spektrum HW a flash része amikor szin csere van papit <> tinta akkor a pillanatnyi Flash álapot vagy az egész képernyöre vonatkozik / flash területek egyszerre Cserélik fel a papi <> tinta szineket/?
Title: Re: NICK
Post by: endi on 2011.January.26. 19:19:32
ha egy memóriacímrõl olvas minden pixelt, akkor marha gyorsan változtatva az ezen a címen lévõ értéket, írni lehet a képernyõre :)
mint a border effekt, illetve én egyik demómban a biast állítottam így soronként többször
Title: Re: NICK
Post by: Tuby128 on 2011.January.27. 06:54:48
Vajon aki megírta az emulátort, az a referenciából olvasta, hogy a NICK-nek hogyan kell mûködnie, vagy megszerezte a NICK terveit és onnan írta meg?
 Van egy sanda gyanúm, hogy a második.
 Viszont ha igazam van, akkor talán beszerezhetõvé válik (már ha odaad egy másolatot) és akkor teljesül a vágyam, láthatom "belülrõl" is.

Endi:
Ha a NICK legalább két byte-ot olvas be minden kiírás elõtt, és ebben az esetben mindkét byte ugyanonnan származik (FFFFh), akkor (még ha nagyon gyorsan is sikerül írnod a memóriát) minden alkalommal kétszer jelenik meg egymás mellett ugyanaz a minta. Namost mivel a paletta a sorban végig ugyanaz marad, legjobb esetben sem lesz jobb egy Graphics hires 2 grafikánál, ráadásul mint ahogy mondtam, a minta ismétlõdik. Tulajdonképpen semmire sem jó.
Talán arra jó lehet, ha 1 byte memóriával kell mintás hátteret szolgáltatni. (Sistergõ képernyõ -  fehér zaj)
Title: Re: NICK
Post by: IstvanV on 2011.January.27. 12:32:55
Vajon aki megírta az emulátort, az a referenciából olvasta, hogy a NICK-nek hogyan kell mûködnie, vagy megszerezte a NICK terveit és onnan írta meg?
 Van egy sanda gyanúm, hogy a második.

Nem szereztem meg semmilyen tervet, és nem is tudom, hogy elérhetők-e még valahol ilyenek. Az emulátor írásához részben a dokumentációt használtam, részben pedig az igazi gépen futtatott különböző tesztprogramok segítségével próbáltam megérteni a hardver működését, mert a dokumentáció (mint általában) nem túl részletes, és néha még félrevezető és/vagy hibás is.

Quote
Ha a NICK legalább két byte-ot olvas be minden kiírás elõtt, és ebben az esetben mindkét byte ugyanonnan származik (FFFFh)

Csak a második (pixel) byte származik mindig az FFFFh címről, az elsőt az LD1-ről olvassa, és az így az ALTIND0/ALTIND1 segítségével felhasználható a színek karakterenkénti változtatására. De ettől függetlenül a nem dokumentált módnak nincs különösebb gyakorlati haszna.
Title: Re: NICK
Post by: Tuby128 on 2011.February.22. 15:37:33
Láttam egy Youtube videót. Egy srác készített egy videovezérlõ IC-t (EP-nél ez ugye NICK volt) amivel felépít a szemünk elõtt egy keresztezõdést.
Az az érdekes, hogy téglalapokat rak ki a 3D-s térben, amikre textúrák (képek) vannak kifeszítve. Sokat egymás mellé téve kap mondjuk egy tömbházat.
 A térben lehet "röpködni" és minden szögbõl megszemlélni az eseményeket.
 Ez a video nagyon jó demonstráció arra, hogy legalább mit kell tudnia egy korszerû videovezérlõnek.
 Támogatom, hogy ez is kerüljön bele a Nick II-be.

A video itt (http://www.youtube.com/watch?v=jDzPfAbHLFI) található
Title: Re: NICK
Post by: vizor on 2011.February.22. 16:47:47
Akkor már támogathatná legalább az OpenGL 1.2-õt is. Szép álom, de jó lenne  :)
Title: Re: NICK
Post by: Zozosoft on 2011.February.22. 16:59:38
Akkor már támogathatná legalább az OpenGL 1.2-õt is. Szép álom, de jó lenne  :)
És mindebben mi lenne Enterprise?
Title: Re: NICK
Post by: vizor on 2011.February.22. 17:43:15
Semmi.

De abban a hozzászólásban amire válaszoltam, vajon mi az Enterprise? Mert a videón egy "játékkonzol"-szerûség van házilag... Ha már erre ment el a téma, hogy milyen legyen a Nick II (III, IV, V, ...), akkor ha lúd, legyen kövér  :)
Title: Re: NICK
Post by: lgb on 2011.February.23. 00:14:07
Semmi.

De abban a hozzászólásban amire válaszoltam, vajon mi az Enterprise? Mert a videón egy "játékkonzol"-szerûség van házilag... Ha már erre ment el a téma, hogy milyen legyen a Nick II (III, IV, V, ...), akkor ha lúd, legyen kövér  :)

Na igen, de ahogy a "Z80 II" :) thread-ben is felmerult: ha csinalsz egy modern, pipeline, superscalar, RISC stb Z80-at, az mar baromira nem Z80, ilyen eleven lehet pl egy ARM proci is, ami mar legalabb van, aztan max emulaciova futtatja az eredeti Z80 kodot, atlagos "modern" orajelen nem problema. Akkor az viszont mar csak emulacio ismet. Ez kisse olyan feature, mint amikor AmigaOS szerusegeket csinalnak, de mar kozel sem az erdeti hw-n futnak, ami nem motorla 68000 sorozat en azt mar nem neveznem Amiganak ... Bar ez hozzaallas kerdese. Nehez meghuzni a hatarvonalat, az igaz ....

Amit en nick kapcsan el tudok kepzelni pl: tudjon egy slot-ban a "nick II" 2 byte-nal tobbet olvasni. Igy novelheto a felbontas, ami pl 256 szinu modnal kulonosen jol jon. Meg azt is megkockaztatom, hogy nemi 'sprite szeruseg' is beleferne, ha pl vsync/blank alatt olvasna be a szukseges adatokat (bar ha jol remlik az eredeti nick-ben az extcol dolgok pont arra voltak fenntartva hogy kesobb valami sprite szeru feature-t lehessen csinalni kulsoleg, hmm?)
Title: Re: NICK
Post by: Tuby128 on 2011.March.09. 09:07:43
Te Zoli, van az az EP az angol E-Bay-en. Tudod a rossz RAM-os. Azt írta a hapek, hogy "TESTING FC ERROR".
Ugye az egy EP-64, tehát a NICK memóriája a rossz.
Kérdésem az, hogy ez nem-e lehet a NICK hibája miatt, hogy nem engedi hozzáférni a memóriához, vagy bezavar, és emiatt hiba lép fel?
Title: Re: NICK
Post by: Zozosoft on 2011.March.09. 09:30:20
Kérdésem az, hogy ez nem-e lehet a NICK hibája miatt, hogy nem engedi hozzáférni a memóriához, vagy bezavar, és emiatt hiba lép fel?
Nem, egyszerûen megpimpósodott a RAM IC, van ilyen.
Title: Re: NICK
Post by: Tuby128 on 2011.March.09. 09:45:14
Szerinted mennyiért fogják elvinni? Kelleni fog így valakinek? Elég gány a doboza is. Meg a hátulján is kopottak a feliratok.
Title: Re: NICK
Post by: Zozosoft on 2011.March.09. 10:43:28
Szerinted mennyiért fogják elvinni? Kelleni fog így valakinek? Elég gány a doboza is. Meg a hátulján is kopottak a feliratok.
100-150 fontot tippelek, vitrinbe jó a hibás gép is...
Title: Re: NICK
Post by: Tuby128 on 2011.March.14. 08:03:47
Hogyan módosítsam az lpt végét, hogy NE interlace módban jelenítse meg a képet?
Title: Re: NICK
Post by: Ferro73 on 2011.March.14. 08:32:03
létezhet olyan, hogy a lpt blok nem ~200*16Byte hanem  15-20 * 16Byte ezáltal valamivel kevesebbszer WAIT,HALT -olja a procit ?
Mivel ilyenkor nem kell kiolvasni az LPT blokokat.
Title: Re: NICK
Post by: IstvanV on 2011.March.14. 11:26:32
Hogyan módosítsam az lpt végét, hogy NE interlace módban jelenítse meg a képet?

Ha ez valamilyen LCD TV, akkor sehogyan, mert egyszerűen csak interlace módot támogat; hasonló probléma van a PC-s TV kártyákkal és azok szoftvereivel is, amelyeknél nehéz elérni, hogy a kép ne interlace módban jelenjen meg. Talán valahogyan be lehet állítani a TV-n nem interlace módot, de valószínűleg nem; talán nem meglepő, ha a gyártók azt tételezik fel, hogy a TV-n csak szabványos TV adást fognak nézni, és 8 bites gépet már szinte senki nem használ.

létezhet olyan, hogy a lpt blok nem ~200*16Byte hanem  15-20 * 16Byte ezáltal valamivel kevesebbszer WAIT,HALT -olja a procit ?
Mivel ilyenkor nem kell kiolvasni az LPT blokokat.

A NICK minden sorban újra beolvassa az aktuális LPB-t (ha ott változnak a paraméterek, például a paletta, akkor változik a kép is), nem lehet időt megtakarítani a több soros LPB-k használatával. Tulajdonképpen semmivel nem lehet gyorsítani a video RAM-ot, amely fix időzítésű: minden karakter (889846 Hz) ciklusban 2 NICK és 1 Z80 memória műveletre van lehetőség. Nincs hatása a BFh I/O porton állítható várakozásnak sem.
Title: Re: NICK
Post by: Ferro73 on 2011.March.14. 17:02:22
és ha a NICK memoriát kicserélnénk IDT707288S VRAM-ra /64K*16b/ akkor megoldodna a kérdés ?
Vagy a NICK akkor is felfügesztené a CPU-t ?
Title: Re: NICK
Post by: Mayer Gábor on 2011.March.15. 09:28:12
Hogyan módosítsam az lpt végét, hogy NE interlace módban jelenítse meg a képet?

Nem inkább azt szeretnéd, hogy interlace módban eltérő legyen a két félkép?
Title: Re: NICK
Post by: Tuby128 on 2011.March.16. 12:28:11
Azért szeretném megváltoztatni az LPT végét, ezzel megszüntetni az interlace módot, mert van egy sony wega 100hz-es katódsugárcsöves tévém, és jelen pillanatban az a helyzet, hogy ha rádaom a scart csatlakozón keresztül az RGB jelet, akkor vibrál a kép (a betûk szélei elmosódottak, és villognak). Szeretném kipróbálni milyen ha nincs az a fél sor az lpt-ben.
Title: Re: NICK
Post by: Mayer Gábor on 2011.March.16. 22:28:21
Hozz létre egy 68 soros karakteres üzemmódot (ami 68*9=612 pixelsor) és ezt egészítsd ki egy 13 pixelsoros vsync modsorral.

http://www.ep128.hu/Ep_Konyv/Enterpress_Cikkek.htm

Ha kész a kód szólj én is kipróbálom.

Title: Re: NICK
Post by: IstvanV on 2011.March.16. 23:37:47
Hozz létre egy 68 soros karakteres üzemmódot (ami 68*9=612 pixelsor) és ezt egészítsd ki egy 13 pixelsoros vsync modsorral.

http://www.ep128.hu/Ep_Konyv/Enterpress_Cikkek.htm

Ha kész a kód szólj én is kipróbálom.

Szerintem nem az a probléma, hogy nem működik az interlace mód, hanem hogy a normál, nem interlace módú kép is interlace-ként jelenik meg, legalábbis ha jól értettem, amit Tuby128 írt. Ez gyakori probléma az újabb, "digitális" TV-knél (ilyen lehet az említett 100 Hz-es TV is, amely valószínűleg digitalizálja a video jelet, és minden félképet kétszer jelenít meg); ezek egyszerűen nem támogatják a 8 bites gépek nem szabványos (azaz nem 625 soros interlace, 15625 Hz sor- és 50 Hz félkép frekvencia) video kimenetét. A gyártóknak úgy látszik, nem éri meg ezzel foglalkozni, ha a felhasználók 99%-a csak normál (interlace) TV adást néz a TV-n.

Az inerlace módhoz egyébként nem elég 625 sorra növelni az LPT hosszát (bár lehet, hogy van olyan TV/monitor, amin ez működik), hanem két VSYNC kell, amelyek között 312.5 sor a távolság. Ez úgy oldható meg, hogy az egyik VSYNC sor elején kezdődik és sor közepén ér véget (mint az EXOS 2.1 leírásban), a másik pedig sor közepén kezdődik és sor végén ér véget. Ilyen található például az epimgconv által generált interlace módú .com file-okban, és az IVIEW-ban is.
Code: [Select]
>3FB000  F7 08 0B 73 B8 FE E9 01  :w..s8~i.
>3FB008  00 36 00 49 FF 24 2D 36  :.6.I.$-6
>3FB010  E9 02 3F 00 00 00 00 00  :i.?.....
>3FB018  00 00 00 00 00 00 00 00  :........
>3FB020  50 32 0B 33 00 40 00 00  :P2.3.@..
>3FB028  00 FF 58 F8 00 00 00 00  :..Xx....
>3FB030  C5 82 3F 00 00 00 00 00  :E.?.....
>3FB038  00 00 00 00 00 00 00 00  :........
>3FB040  FD 00 3F 00 00 00 00 00  :}.?.....
>3FB048  00 00 00 00 00 00 00 00  :........
>3FB050  FE 00 20 3F 00 00 00 00  :~. ?....
>3FB058  00 00 00 00 00 00 00 00  :........
>3FB060  FF 00 3F 38 00 00 00 00  :..?8....
>3FB068  00 00 00 00 00 00 00 00  :........
>3FB070  FD 00 3F 00 00 00 00 00  :}.?.....
>3FB078  00 00 00 00 00 00 00 00  :........
>3FB080  F2 02 06 3F 00 00 00 00  :r..?....
>3FB088  00 00 00 00 00 00 00 00  :........
>3FB090  E9 02 3F 00 00 00 00 00  :i.?.....
>3FB098  00 00 00 00 00 00 00 00  :........
>3FB0A0  F7 08 0B 73 B8 FE E9 01  :w..s8~i.
>3FB0A8  00 36 00 49 FF 24 2D 36  :.6.I.$-6
>3FB0B0  E9 02 3F 00 00 00 00 00  :i.?.....
>3FB0B8  00 00 00 00 00 00 00 00  :........
>3FB0C0  50 32 0B 33 00 77 00 00  :P2.3.w..
>3FB0C8  00 FF 58 F8 00 00 00 00  :..Xx....
>3FB0D0  C5 82 3F 00 00 00 00 00  :E.?.....
>3FB0D8  00 00 00 00 00 00 00 00  :........
>3FB0E0  FD 00 3F 00 00 00 00 00  :}.?.....
>3FB0E8  00 00 00 00 00 00 00 00  :........
>3FB0F0  FE 00 06 3F 00 00 00 00  :~..?....
>3FB0F8  00 00 00 00 00 00 00 00  :........
>3FB100  FF 00 3F 20 00 00 00 00  :..? ....
>3FB108  00 00 00 00 00 00 00 00  :........
>3FB110  FD 00 3F 00 00 00 00 00  :}.?.....
>3FB118  00 00 00 00 00 00 00 00  :........
>3FB120  F3 02 06 3F 00 00 00 00  :s..?....
>3FB128  00 00 00 00 00 00 00 00  :........
>3FB130  E9 03 3F 00 00 00 00 00  :i.?.....
>3FB138  00 00 00 00 00 00 00 00  :........
Title: Re: NICK
Post by: Mayer Gábor on 2011.March.17. 07:17:04
Ő azt mondta meg akarja szüntetni az interlace módot, tehát 625 soros non interlace módot akar.
Title: Re: NICK
Post by: Zozosoft on 2011.March.17. 09:00:19
Ez gyakori probléma az újabb, "digitális" TV-knél (ilyen lehet az említett 100 Hz-es TV is, amely valószínûleg digitalizálja a video jelet, és minden félképet kétszer jelenít meg); ezek egyszerûen nem támogatják a 8 bites gépek nem szabványos (azaz nem 625 soros interlace, 15625 Hz sor- és 50 Hz félkép frekvencia) video kimenetét. A gyártóknak úgy látszik, nem éri meg ezzel foglalkozni, ha a felhasználók 99%-a csak normál (interlace) TV adást néz a TV-n.
Ugyanez lehet a Scart csatlakozós monitorok esetén is, az ott tapasztaltak alapján az LG használ olyan módszert ami számunkra a legjobb eredményt adja. Érdekes módon az interlace EP képbõl (pl IVIEW) is jó minõségû állóképet csinál.
Title: Re: NICK
Post by: Mayer Gábor on 2011.March.17. 09:15:48
Érdekes módon az interlace EP képbõl (pl IVIEW) is jó minõségû állóképet csinál.

De mi ebben az érdekes? Ez a PAL szabvány, nem?
Title: Re: NICK
Post by: Zozosoft on 2011.March.17. 09:54:00
De mi ebben az érdekes? Ez a PAL szabvány, nem?
A PAL interlace és az EP interlace az más dolog.
Title: Re: NICK
Post by: Tuby128 on 2011.March.17. 10:09:19
Kezdünk kicsit eltávolodni egymástól, noha próbálok tényleg jól fogalmazni.
Tehát a TV-mnek szerintem az a problémája, hogy nem jól dolgozza fel az interlace módot. Errõl szeretnék megbizonyosodni úgy hogy non-interlace módot állítok elõ az EP-n.
Azt olvastam, hogy a NICK mindkét félképben ugyanazokat az információkat küldi el.
Amiatt lesz interlace, hogy az utosó-néhány sor az LPT tábla végén a függõleges szinkronnal machinál valamit. Nos én pont ezt akarom úgy átalakítani, hogy minden kép egymáson legyen, és ne eltolva.
Lehet, hogy két sor között fekete csíkos lesz a kép, de az nem érdekel.
Title: Re: NICK
Post by: Mayer Gábor on 2011.March.17. 10:22:10
ugye elolvastad a korábbi hozzászólásomat amiben leírtam, hogyan próbáld meg a 625 soros non interlace módot előállítani?
Title: Re: NICK
Post by: IstvanV on 2011.March.17. 11:19:57
Kezdünk kicsit eltávolodni egymástól, noha próbálok tényleg jól fogalmazni.
Tehát a TV-mnek szerintem az a problémája, hogy nem jól dolgozza fel az interlace módot. Errõl szeretnék megbizonyosodni úgy hogy non-interlace módot állítok elõ az EP-n.

Az EP video kimenete már eredetileg is non-interlace, feltéve, hogy nem fut olyan program (pl. IVIEW), ami kifejezetten interlace módot állít elő. Mint már említettem, sok újabb TV csak interlace képet tud megjeleníteni az analóg video jelből, mert az a szabványos.

ugye elolvastad a korábbi hozzászólásomat amiben leírtam, hogyan próbáld meg a 625 soros non interlace módot előállítani?

Ez szabálytalan formátum (túl alacsony VSYNC frekvencia), tehát könnyen előfordulhat, hogy így fut vagy ugrál a kép. De jobb esetben is lehet, hogy így is csak interlace lesz az eredmény.
Title: Re: NICK
Post by: Tuby128 on 2011.March.23. 20:26:17
Beszereztem még egy EP 128-at. Ez angol. Amikor kivettem a csomagolásból kotyogott. Benézve láttam, hogy nincs a helyén a hangszóró. Szétszedtem, és helyre raktam, viszont valami kandikát ki a 64Mb-os kiterjesztett memória alól. Bizony a Nick hûtõlapja volt. Valahogy levált róla. Azon gondolkozom mivel tegyem vissza.
Title: Re: NICK
Post by: Zozosoft on 2011.March.23. 22:54:49
Bizony a Nick hûtõlapja volt. Valahogy levált róla.
Ezt írtam már többször is, így 25 év után szokása lepotyogni.
Quote
Azon gondolkozom mivel tegyem vissza.
Én maradtam a gyári megoldásnál, pillanatragasztó.

De érdemes megnézni a Nick típusát, ha 08-47-es (vagyis javított kiadás), akkor nem is kell a lemez.
Title: Re: NICK
Post by: Tuby128 on 2011.March.23. 23:00:05
Azt hiszem az az. Kicsit nehéz volt elsõre megmondani, mert ahogy leugrott a lemez vitte a fele feliratot is, de sikerült kisilabizálni, hogy ez bizony az. Akkor nem is rakom rá vissza. Remérelem emiatt nem fog tönkremenni.
Title: Re: NICK
Post by: Povi on 2011.March.24. 11:57:44
a 64Mb-os kiterjesztett memória alól

Hű, ez valami tuning EP lehet!!!  :mrgreen:
Title: Re: NICK
Post by: Jubatian on 2011.March.30. 21:41:34
Paletta.

Egy furcsa dolog csapott a fejembe ahogy elkezdtem itt szórakozni a Nick grafikus képességeivel. Mi is az EP 256 színû palettája? Lett egy sanda gyanúm, amelyet egy gyors BASIC programmal a TV-n úgy látom, be is igazoltam (Természetesen igazi géprõl :) ). Már ha jól látom, amit ott látok. Ez pedig az, hogy a kék szintjei nem egyeznek a piros és zöld szintekkel. Azaz ha PC-n akarom kihelyettesíteni, akkor:

Piros és zöld szintek: 0x00, 0x24, 0x49, 0x6D, 0x92, 0xB6, 0xDB, 0xFF
Kék szintek: 0x00, 0x55, 0xAA, 0xFF

Amit a TV-n most látok, az meg valahogy nagyon passzol ehhez a feltevéshez. Egyik érdekes következménye ennek, hogy a "tiszta" szürkeárnyalatok hiányoznak. Van fekete meg fehér, közötte "igazi" szürke nincs. Nekem amúgy jobban tetszik ez a paletta, mintha úgy lenne, hogy legyen, na, persze a TV-s megállapítás is elég szubjektív valami tud lenni (Valami 90-es évek eleji kis színes TV-rõl van szó). Így lenne ez, vagy valahogy máshogy? (Volt valaki elvetemült, aki jelszinteket méricskélt valahol már?).

Másik dolog, ami piszkál, hogy általában mekkora is az a képterület? Az én TV-m pofájára úgy látom, éppen hogy csak feltér a 42 oszlop, na, máshol is lehet legalább erre számítani? (Remélem, csak az én "látóköröm" ilyen szûk). A függõleges sorszámmal gondolom, a PAL szabvány miatt kevesebb a gond.
Title: Re: NICK
Post by: Zozosoft on 2011.March.30. 22:04:26
Ehhez nem kell méregetni, elég elolvasni egy NICK leírást :-)
Mivel 8 bitet elég nehéz egyenlõ arányban három felé osztani, így jött ki, hogy a piros és zöld 3 bites, a kék 2 bites.
Title: Re: NICK
Post by: Ferro73 on 2011.March.30. 22:14:53
a régi tévén húzd össze a képet <--> ez álltal látható lesz az ami lemarad a "foszfor" hiánya miatt
igaz ha szines a TV akkor a szinek nem biztos, hogy megmaradnak mindenhol.
Én Monokrom monitorra kötötte és mivel képcsövet cseréltem nem volt elég feszkó a "sorkimenö...eltérítõ"-nél igy teljes EP képet kaptam.
Title: Re: NICK
Post by: Jubatian on 2011.March.31. 17:50:57
Ehhez nem kell méregetni, elég elolvasni egy NICK leírást :-)
Mivel 8 bitet elég nehéz egyenlõ arányban három felé osztani, így jött ki, hogy a piros és zöld 3 bites, a kék 2 bites.

Huh, hát nem is ezen lamentáltam, hanem azon, hogy vajon úgy döntöttek-e, hogy tiszta fehér nem lesz, és akkor a magas helyiértékek azonos szinteket kódolnak, vagy ezek szerint akkor ennél :) Az elõbbi azért kerülgetett, mert sok régi gép palettája ilyen (Gondolok itt a régi PC digitális monitorra a 64 szín-lehetõséggel). Na, de ez jobban is tetszik nekem, szerintem érdekesebb a színválaszték így, meg úgy nézegetve van pár egész használható FIXBIAS csoport 16 színû módokhoz. Valamivel lágyabbnak, természetesebbnek tûnnek ezek a színek nekem, mint mondjuk az említett EGA paletta.

Ferro73: TV - szóval akkor --benne-- a TV-ben? Elõl nekem nincs ilyesmi rajta, valami ITT Ideal Color. Asszem a hátuján talán akad típus, de az szinte biztos, hogy adatlap nincs hozzá (Nem leltem a neten - döglött távirányítója miatt vadásztam sokat, mert "Csend" gomb sincs elõl rajta, így meg az EP-vel van némi alap háttérzaj a hangerõszabályzás ellenére is. Ebbõl fúrás lesz meg kapcsoló, na mindegy). Esetleg akad valami általánosabb ismertetõjegye az erre szolgáló potméternek (?).

Igazság, hogy nem annyira azért kellene, mert valami nálam kinn lenne a képbõl, hanem mert én szeretnék rá programozni :) - hogy mennyire szabad elszaladni a függõleges oszlopok számával, hogy úgy általában feltérjen egy TV képére.
Title: Re: NICK
Post by: Ferro73 on 2011.March.31. 18:58:03
TV gyártótól függ feltünteti vagy sem, használd a tükör trükköt.

A távirányitóra  ha pesti vagy probáld meg a pecsát / Petöfi Csarnok / van egy müszerész javít, készit.
Title: Re: NICK
Post by: IstvanV on 2011.March.31. 19:57:40
Igazság, hogy nem annyira azért kellene, mert valami nálam kinn lenne a képbõl, hanem mert én szeretnék rá programozni :) - hogy mennyire szabad elszaladni a függõleges oszlopok számával, hogy úgy általában feltérjen egy TV képére.

Ha fontos, hogy "TV kompatibilis" legyen a kép, akkor vízszintesen csak legfeljebb kb. 42 karakter lehet, de egyes TV-k talán még abból is levágnak; a 40 az biztosan kifér. Én úgy látom, bár ezt több TV-n is ellenőrizni kellene, hogy a normál 11/51, illetve 10/52 margókkal kissé balra van eltolódva a kép.
A függőleges látható terület is TV függő, mindenesetre az EXOS 252 ((27 + 1) * 9) sort jelenít meg, ami után 14 sor keret, majd 3 sor VBLANK után következik a VSYNC. Ezt talán érdemes kissé felfelé eltolni, azaz néhány sorral több alsó keretet használni, mert úgy emlékszem, régen CRT TV-n alul már nem volt az egész kép látható a legnagyobb, 42x27 karakteres video lapot megnyitva, a státusz sor felett pedig még volt egy kevés keret.

Piros és zöld szintek: 0x00, 0x24, 0x49, 0x6D, 0x92, 0xB6, 0xDB, 0xFF
Kék szintek: 0x00, 0x55, 0xAA, 0xFF

RF/kompozit/S-Video kimenetet használva valójában nem lineáris a kék szint, hanem a gép 3 bitesre konvertálja, és 0,2,5,7 lesz; ezért a 38h és C7h szín elvileg teljesen szürke, és nem "szines" árnyalatú, mint az emulátoron. Az RGB kimenet külön, (valószínűleg nem túl pontos) ellenállásokkal megvalósított D/A átalakítót használ.
Title: Re: NICK
Post by: Ferro73 on 2011.March.31. 20:16:52
Én anno az asmon-t használva teszteltem belapoztam B2-re az 0FFh szegmenst és memória módosítással B900h környékén teszteltem margó beállítás, sprite keresés. Érdemes azért a Bordert szinezni mert ugy jobban látható a margó /sor szélek/

Title: Re: NICK
Post by: Jubatian on 2011.March.31. 20:24:52
TV gyártótól függ feltünteti vagy sem, használd a tükör trükköt.
-- gondolsz arra, hogy belebújok hátulról, aztán tükörben nézem, mi történik elõl? :D (Háát, fiatal vagyok én ehhez, de gyerekként még láttam TV szerelõt)

Én úgy látom, bár ezt több TV-n is ellenõrizni kellene, hogy a normál 11/51, illetve 10/52 margókkal kissé balra van eltolódva a kép.
Az én TV-m szerint is! Nálam a két oszlopnyi hely a negyvenhez képest a jobb oldalt van, a normál EP kép éppen súrolja a bal kávát. Akkor gondolom ilyen 336x256 méret elférésére lehet számítani, de ekkor illik a felhasználónak lehetõséget adni a kép kalibrálására (Hová tegye a NICK?), meg a jó régi TV-k miatt a létfontosságú információkat nem a sarkokba rakni.

RF/kompozit/S-Video kimenetet használva valójában nem lineáris a kék szint, hanem a gép 3 bitesre konvertálja, és 0,2,5,7 lesz; ezért a 38h és C7h szín elvileg teljesen szürke, és nem "szines" árnyalatú, mint az emulátoron. Az RGB kimenet külön, (valószínûleg nem túl pontos) ellenállásokkal megvalósított D/A átalakítót használ.
Ühüm, szóval akkor a kékre általában a 0x00, 0x49, 0xB6, 0xFF sor illene inkább, ha PC-n akarok hozzá rajzolni. Hát na, az is igaz, hogy a TV-n ennyi eltérés vagy látszik, vagy nem (Ugye felrajzoltam némi palettát, aztán meredtem a TV-re, de nem tûnt fel)... Rajzolásnál persze azért számít.
Title: Re: NICK
Post by: Ferro73 on 2011.March.31. 20:37:33
A program indítása egy kalibrációval egy fehér kerettel  kurzorral majd enter-rel fixálni és utána indulna a program néhány 100 bájt az egész.
Title: Re: NICK
Post by: Jubatian on 2011.March.31. 21:52:00
A program indítása egy kalibrációval egy fehér kerettel  kurzorral majd enter-rel fixálni és utána indulna a program néhány 100 bájt az egész.
Jaja, és utána, ha szûkös a RAM, el is dobhatod azt a néhány 100 bájtot :D Bár az egy kicsit trükkösebb, ha valami hires módot akarsz pontosan elhelyezni, hiszen 2 byte-os csoportokban fogja csak arrább tenni azt a NICK, tehát ez a kép kiosztásában is igényel némi meggondolást (Amit tervezek, abba viszont ez még éppen hogy belefér).

Kicsit szórakoztam azzal a palettával, hát gondolom, közismert, valami ilyesmi akkor érzésem szerint (A kékre a 0 2 5 7 bontással). Onnan középtájról szerintem egész korrekt FIXBIAS-ok szedhetõek fel, se túl sötét, se túl világos, az alsó 8 helyre felvett színeket jól ki lehet velük egészíteni.
Title: Re: NICK
Post by: Zozosoft on 2011.April.01. 09:37:11
Mi anno, amikor megvettük a színes tévét, másnap kihívtuk a szerelõt, berakva az EPDOS képét (27x42), hogy na akkor ezt kérjük középre, hogy minden látsszon.
Bonuszként így a filmekbõl is többet láttunk  :ds_icon_cheesygrin:
(Ha van tvtuneres PC a közelben, érdemes összevetni annak a képét a tévével, jól látszik, hogy mennyit levágnak a tévék.)
Title: Re: NICK
Post by: IstvanV on 2011.April.01. 13:52:16
(Ha van tvtuneres PC a közelben, érdemes összevetni annak a képét a tévével, jól látszik, hogy mennyit levágnak a tévék.)

Ez (http://enterpriseforever.com/dlattach.html;topic=31.0;attach=6157) a program így néz ki TV tuner kártyával, S-Video kimenetet (http://wiki.enterpriseforever.com/index.php/S-Video_kimenet) használva: epsvid02.jpg (http://enterpriseforever.com/dlattach.html;topic=31.0;attach=6147;image). A kép eredetileg 768x576 méretű volt, azaz 48 karakter szélességű és 288 (nem interlace) sor a magasság, de ebből alul 2 sor már VBLANK. Itt is látható, hogy a kép kb. 1 karakterrel el van tolva balra (a színes területnek vízszintesen 160 és 672 között kellene lennie 768x576 méretnél, de valójában 144 és 660 között van, azaz a pixelek kis mértékben szélesebbek is, mint az emulátoron).
Title: Re: NICK
Post by: Tuby128 on 2011.November.28. 11:48:59
Olyan érdekes, hogy minden évben amikor áttanulmányozom az EP kapcsolási rajzát (legeltetem a szemeimet) szóval mindig van olyan hogy újat találok, és meglepõdöm rajta.
Most pl. arra lettem figyelmes, hogy a Nick kétfázisú órajelet kap. Így gondolom picivel gyorsabban dolgoznak benne az elemi kapuk.
Title: Re: NICK
Post by: Zozosoft on 2011.December.29. 21:46:33
István!
Itt pontosan mit is csinálnak,és miért is jobb így?
[attachthumb=1]
Title: Re: NICK
Post by: IstvanV on 2011.December.29. 23:43:43
Itt pontosan mit is csinálnak,és miért is jobb így?

Az LPT VBLANK részét teszik "szabványosabbá", amint az a dokumentációban olvasható is. A módosítás előtt:
Code: [Select]
>BCD0  FD 10 3F 00 00 00 00 00  00 00 00 00 00 00 00 00
>BCE0  FC 10 06 3F 00 00 00 00  00 00 00 00 00 00 00 00
>BCF0  FF 10 3F 20 00 00 00 00  00 00 00 00 00 00 00 00
>BD00  FC 12 06 3F 00 00 00 00  00 00 00 00 00 00 00 00
>BD10  DE 13 3F 00 00 00 00 00  00 00 00 00 00 00 00 00
Utána:
Code: [Select]
>BCD0  FD 10 3F 00 00 00 00 00  00 00 00 00 00 00 00 00
>BCE0  FE 10 06 3F 00 00 00 00  00 00 00 00 00 00 00 00
>BCF0  FC 10 3F 1C 00 00 00 00  00 00 00 00 00 00 00 00
>BD00  F0 12 06 3F 00 00 00 00  00 00 00 00 00 00 00 00
>BD10  EB 13 3F 00 00 00 00 00  00 00 00 00 00 00 00 00
Tehát rövidebb lesz a VSYNC (a szabványos TV adásban 2.5 sor a hossza), utána van még 3.5 sor VBLANK (azaz összesen 9 sor blank/sync, az interlace módú TV adásban ez 2.5+2.5+2.5=7.5 sor, de interlace nélkül szabványosnak mondható a 3+3+3 sor, ezt használják pl. a Commodore gépek is), majd 4 helyett 16 fekete sor. Így 287 sor marad a hasznos kép információ számára, illetve valójában csak 286, mert az első keret sor még fekete marad a margó beállítások miatt. Ezeknek a változtatásoknak általában nincs észrevehető hasznos hatása, de lehet, hogy a régebbi TV-k egy részén az eredeti LPT nem eredményezett stabil képet. A BRD ROM automatikusan elvégzi ezt az LPT módosítást (ha jól emlékszem, megszakításban folyamatosan :)).
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 03:02:22
A BRD ROM automatikusan elvégzi ezt az LPT módosítást (ha jól emlékszem, megszakításban folyamatosan :)).
Igen, az szívatott a ZT óra fejlesztésekor  :oops:

Lenne értelme, hogy az EXOS 2.32 eleve ilyen LPT-t csináljon?
Title: Re: NICK
Post by: lgb on 2011.December.30. 10:48:53
Az LPT VBLANK részét teszik "szabványosabbá", amint az a dokumentációban olvasható is. A módosítás előtt:

Hmm, na itt lenne egy kerdesem, ami regota foglalkoztat. Ha jol tippelek az egesz LPT masodpercenkent 50-szer "fut vegig" tekintve hogy 50 half-frame-bol all a kep PAL szabvany eseten. A legtobb 8 bites gep uazt a half-frame-et nyomja ki egy teljes frame (25/masodperc) eseten, azaz a paros es paratrlan sorok tartalma ugyanaz. Igazabol en azon gondolkodtam, hogy ossze lehet-e hozni olyan LPT-t, hogy ahol igazi interlaced van, azaz a ket felkep tartalma nem azonos. Azaz nincs vege az LPT-nek a vsync utan, hanem leir meg egy felkepet, us utana van vege. Ez azert erdekes szamomra, mert ugye igy a fuggoleges felbontas a duplajara no. Ha nincs is erre szukseg, pl erdekes lehet arra hasznalni, hogy pl valami "szinkeveres" technikaval egy pixel szine "atlagolodik" az egymas folott levo paros/paratlan felkepbol szarmazo info alapjan. Igy pl 16 szinu uzemmodban is tobb "kvazi-szin" lenne, ami azert jo, mert 256 szinu mod horizontalis felbontasa mar igen alacsony, es dupla akkora felbontas lehet 16 szinu modban, ahol viszont esetleg a szinek szama nem eleg egy szep kephez: a kevereses modszerrel megoldhato lenne, hogy 16 szinnel tobbet lassunk ugymond, amde a horizontalis felbontas ne csokkenjen olyan karcsura, mint 256 szinu mod eseten.

Mondjuk abban egeszen biztos vagyok, hogy ezt valaki mar megcsinalta (ha lehetseges), nyilvan nem gondolom, hogy en talaltam fel a spanyol viaszt, engem csak az erdekelne, hogy egyaltalan megoldhato-e, es hogyan (konkretan az LPT-ben mi van, eleg tenyleg ha van ket vsync/blank es csak a masodiknal van beallitva h vege az lpt-nek?).

Thx!
Title: Re: NICK
Post by: IstvanV on 2011.December.30. 11:06:04
Igen, megoldható az interlace EP-n és például az IVIEW használja is. Egyszerű színkeveréshez elég, ha több félképből áll az LPT (mint például a Zozolace esetében). Kétszeres függőleges felbontáshoz az kell, hogy az egyik félképben a VSYNC fél sorral el legyen tolva; normál LPT-nél sor elején kezdődik, és sor közepén ér véget, az interlace módban az egyik félképnél sor közepén kezdődik és sor végén ér véget.

Egy példa interlace módra a bdlvdisp.lua scriptből (a paramétererk sorban: LPB hossza (sorokban), video mód, bal margó, jobb margó), ez csak a két VBLANK rész:
Code: Lua
  1.   writeBlankLPB(3, 0x00, 63, 0)
  2.   writeBlankLPB(2, 0x00, 32, 63)
  3.   writeBlankLPB(1, 0x00, 63, 56)
  4.   writeBlankLPB(4, 0x00, 63, 0)
  5.   writeBlankLPB(9, 0x02, 6, 63)
  6.  
  7.   writeBlankLPB(3, 0x00, 63, 0)
  8.   writeBlankLPB(2, 0x00, 6, 63)
  9.   writeBlankLPB(1, 0x00, 63, 32)
  10.   writeBlankLPB(3, 0x00, 63, 0)
  11.   writeBlankLPB(9, 0x02, 6, 63)
Az első után következik az alsó, a második után pedig a felső félkép (2*294 sor, összesen 625 sor a teljes kép).
Title: Re: NICK
Post by: IstvanV on 2011.December.30. 11:10:48
Lenne értelme, hogy az EXOS 2.32 eleve ilyen LPT-t csináljon?

Talán igen, legalábbis nem rosszabb, mint az eredeti :) De a végén a fekete sorok számát esetleg csökkenteni lehetne, hogy ne 286, hanem 288 sor maradjon.
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 11:24:49
Igazabol en azon gondolkodtam, hogy ossze lehet-e hozni olyan LPT-t, hogy ahol igazi interlaced van, azaz a ket felkep tartalma nem azonos. Azaz nincs vege az LPT-nek a vsync utan, hanem leir meg egy felkepet, us utana van vege. Ez azert erdekes szamomra, mert ugye igy a fuggoleges felbontas a duplajara no.
Igen, ezt már gyárilag így tervezték, a különbözõ ismertetõkben így is adták meg a maximális felbontást.
A géphez adott demókazettán rajta is volt egy Interlace program, amivel IS-BASIC-bõl lehetett kihasználni ezt. (Laci! A Utilok közül hiányzik ez!)
Ennek használatával követtem el anno ezt. (http://ep128.hu/Ep_Demo/Leiras/Interlace_Demo.htm)

Quote
Ha nincs is erre szukseg, pl erdekes lehet arra hasznalni, hogy pl valami "szinkeveres" technikaval egy pixel szine "atlagolodik" az egymas folott levo paros/paratlan felkepbol szarmazo info alapjan.
Ilyesmin én is gondolkodtam, itt (http://ep128.hu/Ep_Demo/Leiras/Zozolace.html) egyszerûen a plusz paletta színekkel játszottam, a fekete közös, így összesen 7 szín van 4 színû felbontásban. Az általad leírt keveréses módszerre is gondoltam, gyakorlatban még nem lett megvalósítva.

Az Interlace jelenlegi csúcsát az István féle képkonvertáló (http://wiki.enterpriseforever.com/index.php/Epimgconv_le%C3%ADr%C3%A1s) adja, ami azt is kihasználja, hogy soronként más paletta lehet, így gyakorlatilag fényképszerû kép (http://ep128.hu/Ep_Demo/Pic/Interlace3.png) érhetõ el!
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 11:32:02
És még egy apróság: lehet akár sok-sok félkép is (amennyi a VRAM-ba befér), így lehet CPU független animációt készíteni, ezt használja ki pl több NASA&GUY demó, de más programokban is van ilyen.
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 11:40:11
Hamár Interlace: a német újságban karattyolnak valamit, majd Szipucsu elárulja, hogy mit  :)
Talán arról van szó, hogy a BRD ROM-ból likvidálják a folyamatos LPT átíró részt?
[attachthumb=1]
[attachthumb=2]
Title: Re: NICK
Post by: Lacika on 2011.December.30. 12:03:48
(Laci! A Utilok közül hiányzik ez!)

Arra a programra gondolsz, ami a Német demokazettán (http://ep128.hu/Ep_Demo/Prg/Ep128_Demonstration_Kassette_DE.rar) volt? Rakjam be az Util programcsokorba is? Ez a program hogyan mûködik? (csak az ismertetõ miatt kérdezem, ne írjak hülyeséget...)
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 12:05:04
Arra a programra gondolsz, ami a Német demokazettán (http://ep128.hu/Ep_Demo/Prg/Ep128_Demonstration_Kassette_DE.rar) volt? Rakjam be az Util programcsokorba is?
Igen.
Title: Re: NICK
Post by: szipucsu on 2011.December.30. 13:17:47
Hamár Interlace: a német újságban karattyolnak valamit
A következõt karattyolják, hirtelen, egyszerû fordítással. A "löschen" szó törlést és berakást is jelent, nem tudom, ebben a szövegkörnyezetben mire vonatkozik, a hardveres dolgokhoz nem nagyon értek.

Interlace

A köv. cikket H.Güldenagel küldte be.

Akinek 2.1-es Basic-je van, hamar rájöhet, hogy az Interlace Driver nem fut.

A számítógép bal oldalán a Cartridge-ben van egy 16K-s ROM (ami az angol Basic-et tartalmazza) és egy 16K-s EPROM (ez a német hibaüzeneteket, egy német editor- és billentyûzetdrivert, egy komplett német WP-t és a :VDUMP, :VSAVE, :VLOAD, :BRD bõvítéseket tartalmazza, és a 4-es szegmensre nyomul), amelyben egy rutin található, ami minden egyes 50Hz megszakításnál 5 byte-ot beleír a Nick chip Line-Parameter táblájába azért, hogy megváltoztassa a függõleges visszatérést/(Austastung?). Minthogy az Interlace-video-drivernek a Line-parameter táblája teljesen másképp van felépítve, ez az 5 byte megzavarja az Interlace mûködését, merthogy az interlace-be is beleír.

Mivel az Enterprise cég az Enterprise-EXOS forrást nem tette elérhetõvé, körülményesen kellett elõbányásznom a rutint. Van egy címdekódolóm, amely az 5 cím közül az egyikre volt felrakva, a buszhoz illesztve. Ez minden 50. másodpercben egy impulzust továbbított, amikor a processzor (a keresett szubrutinban) erre a területre írt. Ezzel az impulzussal "megkínáltam" az oszcilloszkópot, és a következõ parancsnál (M1 ckilus) kerestem. A következõ rutint találtam a 4-es szegmensen az E4F7 címtõl:

Minthogy egy Eprom törlésénél (berakásánál?) minden Bit 1, és ez az égetés által 0 lesz, meg lehet csinálni a változtatást ANÉLKÜL, hogy az Epromot elõre törölnénk (beraknánk?) és újraírnánk. Az én Böhm u-Promommal ez egy másodpercig sem tartott.

Röviden összefoglalva: egy 00-nak az IFC2 - IFC4 Eprom címre égetésével jó lesz a német Basic Interlace.

A következõ telefonszámon lehet kérdezni: (elavult szám)
Title: Re: NICK
Post by: Zozosoft on 2011.December.30. 13:29:44
A következõt karattyolják, hirtelen, egyszerû fordítással. A "löschen" szó törlést és berakást is jelent, nem tudom, ebben a szövegkörnyezetben mire vonatkozik, a hardveres dolgokhoz nem nagyon értek.
Köszi! Itt a törlés a megfelelõ.

Nem semmi, amit a rutin megkeresésérõl ír, manapság ep128emuval "kicsit" egyszerûbb  :ds_icon_cheesygrin:
Title: Re: NICK
Post by: Tuby128 on 2012.January.22. 12:49:38
Ez az LPT "átírós rész" miben nyilvánult meg?
 Nekem német EP-m volt, TV-vel használtam antenna kimenettel, késõbb SCART csatlakozóval, én nem tapsztaltam semmilyen problémát.
Title: Re: NICK
Post by: Tuby128 on 2012.February.03. 14:11:03
Elkezdtem dolgozni (még csak papíron) egy külsõ NICK chip-en, amely külsõ memóriával rendelkezik.
- Elsõdleges szempont a kompatibiltás, tehát mindent kell tudnia amit a Nick-chip, ami a megjelenítéssel kapcsolatos.
- A szabvány felbontások miatt arra jutottam, hogy egyszerûbb lenne, elhagyni a sorparaméter tábla függõleges szinkroziációhoz tartozó részt, és automatikusan végezné a hardver
- Elõször 800x600-as felbontást akartam, de ahhoz 50Mhz-es pixel órajel kellne 72Hz-en, nekem csak 25Mhz áll rendelkezésre
- 640x480-as felbontás esetén elégséges 25Mhz pixel órajel, amely kb. 60hz-es függõleges szinkront ad.
Ennek hátránya, hogy csak 80 karakter széles képernyõt képes megjeleníteni, noha az eredeti nick max. 88 karaktet tudott. (Text 80 méretûre gondolok)
 Egyelõre a keretszínt hanyagolom, még nem tartok ott.

 Nagyon nehezen boldogulok a Sorparaméter Tábla kiolvasásával, elég bonyolult hardverrutin kell a feldolgozásához. Fõleg a legfontosabb, a karakteres képernyõ jelent gondot a bonyolult címzés miatt.

 Ami igazán problémás az az idõzítés. Azt akarom, hogy ugyanolyan sebességgel tudja írni a külsõ memóriát a Z80 miközben a külsõ Nick is ugyanúgy hozzáfér, de ez utóbbi jóval többször akarja elérni. Bufferelni fogom a Z80 memória írási mûveleteit, és a vízszintes szinkronjel ideje alatt fogom az adatokat elhelyezni a külsõ memóriában. Ehhez viszont átmeneti tároló kellene, de olyan ami az adatokkal együtt a címet is megjegyzi. Ezt próbálom meg fejben összerakni.

Félek nem úszom meg, hogy drágább hardvert kell beszereznem a munkához, amelyben van beépített órajel sokszorozó, de akkor elvesztem az egyszerûség és olcsóság adta elõnyöket.
Title: Re: NICK
Post by: Zozosoft on 2012.February.03. 16:32:31
- 640x480-as felbontás esetén elégséges 25Mhz pixel órajel, amely kb. 60hz-es függõleges szinkront ad.
Ennek hátránya, hogy csak 80 karakter széles képernyõt képes megjeleníteni, noha az eredeti nick max. 88 karaktet tudott. (Text 80 méretûre gondolok)
Ez egy olyan nagy hátrány, hogy így nem is érdemes belevágni, hiszen már egy EPDOS is használhatatlan lenne vele!
Függõlegesen is nagyon kevés, 300 sorig el lehet menni, azaz interlace-ban 600-ig. Vagyis 800x600-nál alább nem kéne adni!
Title: Re: NICK
Post by: lgb on 2012.February.03. 19:41:54
Elkezdtem dolgozni (még csak papíron) egy külsõ NICK chip-en, amely külsõ memóriával rendelkezik.
- Elsõdleges szempont a kompatibiltás, tehát mindent kell tudnia amit a Nick-chip, ami a megjelenítéssel kapcsolatos.
- A szabvány felbontások miatt arra jutottam, hogy egyszerûbb lenne, elhagyni a sorparaméter tábla függõleges szinkroziációhoz tartozó részt, és automatikusan végezné a hardver

Ez nem vili: nem kene ilyet tenni az LPT-be? Az fura lenne, mert akkor hogy lesz kompatibilis? Amugy meg interlaced stb trukkoknel ez nem jelent problemat? Amikor vsync van, de lpt reload nem. Vagy ugy erted, hogy maga a vsync mode az persze ott lenne, csak nem a parameterei alapjan csinalja (ize, ezt hulyen fogalmaztam meg)?

Quote
- Elõször 800x600-as felbontást akartam, de ahhoz 50Mhz-es pixel órajel kellne 72Hz-en, nekem csak 25Mhz áll rendelkezésre
- 640x480-as felbontás esetén elégséges 25Mhz pixel órajel, amely kb. 60hz-es függõleges szinkront ad.
Ennek hátránya, hogy csak 80 karakter széles képernyõt képes megjeleníteni, noha az eredeti nick max. 88 karaktet tudott. (Text 80 méretûre gondolok)
Egyelõre a keretszínt hanyagolom, még nem tartok ott.

Imho, amit a nick amugy kepes megjeleniteni, azt jo lenne latni :) Az mas kerdes, hogy vannak erdekessegek: amire a nick "fizikailag" kepes pl horizontalis felbontasban, azt nem szokas hasznalni maxra: mivel a tv-knel van ugye az overscan, azaz amit a videojel hordoz informaciot, az nem mind "fer bele" a kepbe (legalabbis klasszikus tv-n, pl lcd-ken vannak ilyen beallitasok, hogy mutassanak mindent). Ez amugy filmeknel is erdekes, allitolag van arra pelda, hogy filmben belog valami oda nem illo, de mivel az overscan tartomanyban volt, senki nem figyelt ra, aztan kesobb tunt fel az embereknek :)

Ha (ismetlem, ha!) jol szamolom, tudom: 57 slot van egy soron belul, ebbol az elso nyolcban olvassa az lpt-t (ugye minden slot-ra ket byte-ot kepes a nick olvasni), az utolso haromban pedig hsync van. Ez elvileg igy 46 slot, ami max felbontas mellett (mondjuk pixel) 736 pixel. Ugye itt jon az overscan a kepbe, hogy bar a nick ezt mar pl tudja, ezt volt szokas kihasznalni, tekintve, hogy egy resze a legtobb (?) tv-n nem latszott. Most epp nem lelek nick doksit, de emlekeim szerint 42 slot-ot volt szokas kihasznalni, ezt ajanlottak, ez pedig 672 pixel. Szoval az a gond, hogy meg ez is tobb mint az altalad emlitett 640, es akkor meg hol van a keret, ami majd szinten jo, ha latszana a teljes feeling kereteben :) Sorry, ha valahol tevedtem volna, emlekezetbol irtam az ertekeket, csak a 16-al valo szorzasnal vettem igenybe a szamitogep segitseget :)

A fuggoleges felbontassal kapcsolatban most hirtelen passz, de wikipedia szerint a PAL szabvany szerint: 313 sor (felkepenkent marmint), es ebbol 288 latszik (ez talan megint az overscan?), egy kep paros/paratlan sorokbol all ugye, tehat akkor lesz a fuggoleges felbontas az elmeleti 625, illetve a "latszik"-os 576.

Quote
Nagyon nehezen boldogulok a Sorparaméter Tábla kiolvasásával, elég bonyolult hardverrutin kell a feldolgozásához. Fõleg a legfontosabb, a karakteres képernyõ jelent gondot a bonyolult címzés miatt.

Ezek azert erdekes dolgok, mert nyilvan anno a Nick tervezesenel is szempont volt, hogy ne legyen tul bonyolult. Ergo biztos van benne vmi trukk, amivel egyszeruen megoldhato, legalabbis kevesbe bonyolultan :) Amennyire tudom (de fixme) a Nick is vmi programozhato hw elem (ULA szeruseg, oszinten nem ertek ehhez annyira), tehat nem biztos, hogy filozofiailag annyira mas lenne pl egy FPGA-val megoldani ugyanezt a "mai idokben", ha ezt regebben is megoldottak ugymond "primitivebb" eszkozokkel :)


Quote
Ami igazán problémás az az idõzítés. Azt akarom, hogy ugyanolyan sebességgel tudja írni a külsõ memóriát a Z80 miközben a külsõ Nick is ugyanúgy hozzáfér, de ez utóbbi jóval többször akarja elérni. Bufferelni fogom a Z80 memória írási mûveleteit, és a vízszintes szinkronjel ideje alatt fogom az adatokat elhelyezni a külsõ memóriában. Ehhez viszont átmeneti tároló kellene, de olyan ami az adatokkal együtt a címet is megjegyzi. Ezt próbálom meg fejben összerakni.

Milyen memoria lenne az? Valami DRAM? Oszinten, en mindig SRAM-ban szoktam gondolkodni, nekem a DRAM bonyolult :) Bar elvbol hallottam rola, de gyakorlatban ... hmm. Meg SRAM eseten is inkabb vmi dual port tarat hasznalnek, akkor nem gond a konkurens hozzaferes. Vagy, esetleg van olyan memoriavezerlo dram-hoz ami "emulal" dp tarat, bar nyilvan ezt mindenfele "halt"-jellegu signalok "postazasaval" eri el vagy hasonlo, vmi xt alaplapon volt ilyen szornyetegem egyszer az inteltol :) Vagy ezt ugy kepzeled, hogy DRAM, es maga a memoriavezerlo minden stb az FPGA-ban van? Mondjuk gondolom a DRAM olcsobb mint az SRAM :)

Quote
Félek nem úszom meg, hogy drágább hardvert kell beszereznem a munkához, amelyben van beépített órajel sokszorozó, de akkor elvesztem az egyszerûség és olcsóság adta elõnyöket.

Imho (ismetlem: imho!) azert van egy-ket dolog ami alapveto, hogy azt tudja amit a nick tudott, felbontas stb. Az mas kerdes h "nick+" cimszoval lehet plusz dolgot is belevinni, de imho ne a kompatibilitas rovasara.
Title: Re: NICK
Post by: IstvanV on 2012.February.03. 20:51:21
Ha (ismetlem, ha!) jol szamolom, tudom: 57 slot van egy soron belul, ebbol az elso nyolcban olvassa az lpt-t (ugye minden slot-ra ket byte-ot kepes a nick olvasni), az utolso haromban pedig hsync van.

Az utolsó 3 slot DRAM frissítés. Ha itt nem keret van beállítva, akkor az utolsó video byte ismétlődik (erről valahol a fórumon van is egy régebbi, TV kártyával készült screenshot). Az utolsó slot talán már HBLANK, de ebben nem vagyok biztos. Az első 8 slot viszont (amikor az LPB olvasása történik) valóban HBLANK, és a HSYNC talán egy slottal ez után kezdődik, a kép vízszintes pozíciója alapján.

Quote
Ez elvileg igy 46 slot, ami max felbontas mellett (mondjuk pixel) 736 pixel. Ugye itt jon az overscan a kepbe, hogy bar a nick ezt mar pl tudja, ezt volt szokas kihasznalni, tekintve, hogy egy resze a legtobb (?) tv-n nem latszott. Most epp nem lelek nick doksit, de emlekeim szerint 42 slot-ot volt szokas kihasznalni,

Jó lenne megvalósítani a 46-ot, mert pl. TV kártyával, vagy olyan monitorral, amelyen állítható a kép mérete, mind látható, és újabb, emulátorra írt programok is kihasználják.

Quote
A fuggoleges felbontassal kapcsolatban most hirtelen passz, de wikipedia szerint a PAL szabvany szerint: 313 sor (felkepenkent marmint), es ebbol 288 latszik (ez talan megint az overscan?), egy kep paros/paratlan sorokbol all ugye, tehat akkor lesz a fuggoleges felbontas az elmeleti 625, illetve a "latszik"-os 576.

Valóban 576 a "szabványos" felbontás, bár TV-ken az overscan miatt gyakran kevesebb. Mindenesetre az 576-ot érdemes támogatni.
Title: Re: NICK
Post by: Zozosoft on 2012.February.03. 21:45:14
Már egy 20-25 éves RGB CRT monitoron is be lehetett állítani úgy a képet, hogy minden beleférjen, anno az Iview fejlesztésekor nézegettem a Philipsemen, hogy a 46 karakter x 300 pixel (600 interlace) képbõl szemmel észrevehetõen nem hiányzott semmi. Ezzel a monitorral a TV adásból is többet kapok, lehet látni a teletext bitjeit is, pl az oldalszámláló tök jól látható :-) (ezeket az adatokat az átlag TV-n nem látható sorokban küldik).

Mivel a projekt felvetése onnan indul, hogy VGA monitorral kompatibilis EP legyen, így a legkisebb szóba jöhetõ felbontás a 800x600. Viszont már ez is igen idejétmúlt :-( a CRT monitorokkal együtt lényegében kihalt, a szintén már sok éve eltûnt hagyományos 4:3-as LCD monitorok natív felbontása 1280x1024 vagy 1024x768 volt.
Manapság az idióta szélesvásznú felbontások használatosak: 1280x720,1366x768,1920x1080

Nem értek a modern technikához, de én két IC-vel képzelném el a dolgot: egy ami a NICK dolgát végzi, pontosan úgy mint az eredeti (persze majd plusz tudás lehet), de az eredmény, ahogy az emulátorban is egy VGA puffer memóriába kerül, és van egy VGA megjelenítõ ami ezt a memóriát olvasva állítja elõ a VGA képet, és ezt lehetne programozni a különbözõ felbontásoknak megfelelõen.
Mivel kismillió olyan eszköz létezik, ami VGA monitorra tud képet kiadni, ezért az is lehetséges, hogy ez utóbbi feladatra lehet is kész IC-t kapni.
És ha menni fognak a szélesvásznú felbontások, akkor az új Nickben meg is lehetne oldani, hogy 64 (128 TEXT 80-ban) látható karakter legyen, ez az EXOS minimális módosításával kihasználható lenne.
Title: Re: NICK
Post by: lgb on 2012.February.03. 22:32:15
Már egy 20-25 éves RGB CRT monitoron is be lehetett állítani úgy a képet, hogy minden beleférjen, anno az Iview fejlesztésekor nézegettem a Philipsemen, hogy a 46 karakter x 300 pixel (600 interlace) képbõl szemmel észrevehetõen nem hiányzott semmi. Ezzel a monitorral a TV adásból is többet kapok, lehet látni a teletext bitjeit is, pl az oldalszámláló tök jól látható :-) (ezeket az adatokat az átlag TV-n nem látható sorokban küldik).

Mivel a projekt felvetése onnan indul, hogy VGA monitorral kompatibilis EP legyen, így a legkisebb szóba jöhetõ felbontás a 800x600. Viszont már ez is igen idejétmúlt :-( a CRT monitorokkal együtt lényegében kihalt, a szintén már sok éve eltûnt hagyományos 4:3-as LCD monitorok natív felbontása 1280x1024 vagy 1024x768 volt.
Manapság az idióta szélesvásznú felbontások használatosak: 1280x720,1366x768,1920x1080

Nem értek a modern technikához, de én két IC-vel képzelném el a dolgot: egy ami a NICK dolgát végzi, pontosan úgy mint az eredeti (persze majd plusz tudás lehet), de az eredmény, ahogy az emulátorban is egy VGA puffer memóriába kerül, és van egy VGA megjelenítõ ami ezt a memóriát olvasva állítja elõ a VGA képet, és ezt lehetne programozni a különbözõ felbontásoknak megfelelõen.
Mivel kismillió olyan eszköz létezik, ami VGA monitorra tud képet kiadni, ezért az is lehetséges, hogy ez utóbbi feladatra lehet is kész IC-t kapni.
És ha menni fognak a szélesvásznú felbontások, akkor az új Nickben meg is lehetne oldani, hogy 64 (128 TEXT 80-ban) látható karakter legyen, ez az EXOS minimális módosításával kihasználható lenne.

En se mondom, hogy ismerem a LCD/TFT/stb monitorok lelki vilagat kulonosebben, de amennyire tudom: ezeknek van egy nativ felbontasa, amit hasznalni kell, mert ha nem az megy, az igen csunyan nez ki, par monitor meg idiota modon sikit is, es pl szeeeeeep feliratot biggyeszt a kepernyore h rossz a felbontas ... Remek. Csak akkor ugye tenyleg nincs fix adat, hiszen minden monitorra mast kene kuldeni :( Tenyleg nem tudom, meg lehet-e uszni "egyben", lehet tenyleg az a jarhato otlet, hogy Nick+ (v mi a neve) renderel ugymond egy "frame bufferbe" (memoria), aztan onnan masok cuccos szepen olvassa a videojel eloallitasahoz, es max ott lehetne monitor felbotast stb amihez szepen felskalazza, vagy tudomisen. Szoval ahogy Zozo irta. Ha jol ertettem :)

Amugy ja, ami elott ulok tft az epp 16:9 es 1920x1080. Es nem orul, ha vmi mast kap, eleg pocsek meg egy karakteres kep is rajta (bios-nal pl szanalmasan ronda). Amint megkapja a "nativ" jeleg, csodalatosan szep, meg amugy DVI-al vannak osszekotve.
Title: Re: NICK
Post by: Zozosoft on 2012.February.03. 22:49:47
En se mondom, hogy ismerem a LCD/TFT/stb monitorok lelki vilagat kulonosebben, de amennyire tudom: ezeknek van egy nativ felbontasa, amit hasznalni kell, mert ha nem az megy, az igen csunyan nez ki, par monitor meg idiota modon sikit is, es pl szeeeeeep feliratot biggyeszt a kepernyore h rossz a felbontas ...
Igen, ezért írtam, hogy a számunkra ideális 800x600 sajnos kihalt :-(
Azzal nem lennénk sokkal elõrébb, ha a 10 éves CRT TV helyett 10 éves CRT VGA monitort lehetne használni. Az emberek pont az ilyenektõl akarnak szabadulni, és a szép új lapos TV-t, monitort használni.
Title: Re: NICK
Post by: lgb on 2012.February.03. 23:06:14
Igen, ezért írtam, hogy a számunkra ideális 800x600 sajnos kihalt :-(
Azzal nem lennénk sokkal elõrébb, ha a 10 éves CRT TV helyett 10 éves CRT VGA monitort lehetne használni. Az emberek pont az ilyenektõl akarnak szabadulni, és a szép új lapos TV-t, monitort használni.

Ertem en, csak igy van az a rossz erzesem, hogy mindig "kullogas" van a technika mogott :( En orulnek egy HDMI/DVI-os EP-nek, ami mehet a 120"-os szupertv-re :) Nem mintha lenne olyanom most , majd :) Persze ennek megvalositasa teny, hogy akkor nem egyszeru ....
Title: Re: NICK
Post by: lgb on 2012.February.03. 23:16:33
Az utolsó 3 slot DRAM frissítés. Ha itt nem keret van beállítva, akkor az utolsó video byte ismétlődik (erről valahol a fórumon van is egy régebbi, TV kártyával készült screenshot). Az utolsó slot talán már HBLANK, de ebben nem vagyok biztos. Az első 8 slot viszont (amikor az LPB olvasása történik) valóban HBLANK, és a HSYNC talán egy slottal ez után kezdődik, a kép vízszintes pozíciója alapján.
Ahaa, koszi a korrekciot!

Quote
Jó lenne megvalósítani a 46-ot, mert pl. TV kártyával, vagy olyan monitorral, amelyen állítható a kép mérete, mind látható, és újabb, emulátorra írt programok is kihasználják.
Valóban 576 a "szabványos" felbontás, bár TV-ken az overscan miatt gyakran kevesebb. Mindenesetre az 576-ot érdemes támogatni.
Na varj, en ugy tudtam a 625 az, es az overscan miatt szokas a 576-ot elfogadni. Vagy ezt rosszul tudom es/vagy a sorok egy resze az valojaban a vsync-re kell? Bar olyan remlik h az csak vmi 2 es fel sor vagy mi (marmint idoegysegben). Aztan lehet, rosszul remlik :)
Title: Re: NICK
Post by: IstvanV on 2012.February.04. 00:12:56
Ahaa, koszi a korrekciot!
Na varj, en ugy tudtam a 625 az, es az overscan miatt szokas a 576-ot elfogadni. Vagy ezt rosszul tudom es/vagy a sorok egy resze az valojaban a vsync-re kell? Bar olyan remlik h az csak vmi 2 es fel sor vagy mi (marmint idoegysegben). Aztan lehet, rosszul remlik :)

A VSYNC valóban csak 2.5 sor, illetve előtte és utána van még további 2.5 sor bevezető jel, ahol a szabvány szerint kétszeres a vízszintes frekvencia (31.25 kHz), bár ezt a NICK nem tudja, tehát összesen 7.5 sor. Nem interlace módban ez 3x3 sor is lehet. Azonban a további 10-15 sor még fenntartott a függőleges visszafutáshoz, illetve itt található még pl. a teletext is. Tehát a 288 sor/félkép az overscan nélkül értendő, ebből a TV-k még levághatnak egy keveset.
Title: Re: NICK
Post by: lgb on 2012.February.04. 17:01:20
Nem értek a modern technikához, de én két IC-vel képzelném el a dolgot: egy ami a NICK dolgát végzi, pontosan úgy mint az eredeti (persze majd plusz tudás lehet), de az eredmény, ahogy az emulátorban is egy VGA puffer memóriába kerül, és van egy VGA megjelenítõ ami ezt a memóriát olvasva állítja elõ a VGA képet, és ezt lehetne programozni a különbözõ felbontásoknak megfelelõen. Mivel kismillió olyan eszköz létezik, ami VGA monitorra tud képet kiadni, ezért az is lehetséges, hogy ez utóbbi feladatra lehet is kész IC-t kapni.
És ha menni fognak a szélesvásznú felbontások, akkor az új Nickben meg is lehetne oldani, hogy 64 (128 TEXT 80-ban) látható karakter legyen, ez az EXOS minimális módosításával kihasználható lenne.
Btw, es meg egy erdekesseg: ha van egy belso "frame buffer" amibe a "renderelunk" (es amibol a VGA jel hmm eloallito dolgozik) annak megvan meg az az elonye is, hogy bele lehet modositani a normal LPT-s feldolgozason es kepeloallitason kivul; pl "rarajzolni" ugymond meg mast, kvazi C64 sprite szeruen, vagy hasonlo feature-ok.
Title: Re: NICK
Post by: Tuby128 on 2012.February.04. 19:34:01
Nem teketóliázok. Elõvettem az erõsebb hardvert. 2 x 200Mhz-en fog ketyegni, így kiszolgálja idõben a Z80-at is. 100Mhz-es memóriát fogy kapni 1MByte mérettel. Írható-olvasható lesz a teljes memória a Z80 számára.

A definiálatlan videomódra a következõt találtam ki:

 A sorparaméter tábla marad ugyanúgy, ahogy van. A nem használt mód olyan lesz, mint a graphics hires 2, azzal a különbséggel, hogy minden pont 256 színû lehet. Ehhez legalább fél mega video-memóriára lesz szükség, amit a hardverem bõven meg is tud adni.


- 1Mbyte memória címzéséhez 20bitre van szükség
- a spec videomódban sorparaméter tábla a elsõ címe a 20 bit felsõ 16 bitjét fogja megadni. (más szóval: 16-tal osztható címen kezdõdhet csak)
- nem lesz függõleges szinkron értelmezés, mert úgy gondolom ha szabvány VGA kimenethez illesztem az EP-t akkor a szoftver ne kapjon szabad kezet a kimenet "vezérlésében"
- Amikor azt mondjuk, hogy 800x600, akkor azt úgy kell érteni, hogy a látható tartomány lesz ennyi azon kívül pedig fekete. Ha a program kihasználja a teljes területet, akkor tegye. Ha nem, akkor keretszínû lesz.
- A hardverem csak addig fogja olvasni a sorparaméter-táblát, amíg érvényes megjelenítendõ videomód van. Tehát pl. ezeket a standard LPT végén már nem veszi figyelembe:
F2 92 3F ...
FD 10 3F ...
FE 10 06 3F ...
FC 10 3F 1C ...
F0 12 06 3F ...
EB 13 3F ...

További (késõbbi) tennivalók:
- Mindenféle képfelbontást tud majd támogatni, a kiolvasott képadatokat majd széthúzza annyira, hogy illeszkedjen a mindenkori felbontáshoz.
- DVI csatlakozó és szabvány támogatása (ezen keresztül átalakítóval HD tévére is csatlakoztatható lesz)
- PC-billentyûzetcsatlakozó (PS/2) kialakítása a bõvítõben, I/O hívásokra válaszolva.
Title: Re: NICK
Post by: IstvanV on 2012.February.05. 13:47:19
Érdekességként itt van néhány screenshot az EP video kimenetéről, amelyen a vízszintes szinkront "szabálytalan" beállításokkal láthatóvá tettem. A karakteres módú sorban a margókat 8-ra és 56-ra állítottam (az utolsó karakternek 6-nak kellene lennie, de ott már DRAM frissítés történik). A képen látható még egy második VBLANK/VSYNC is.

[attachthumb=#]
[attachthumb=#]
[attachthumb=#]
Title: Re: NICK
Post by: Tuby128 on 2012.February.05. 17:40:18
Két kérdésem lenne:

1. Mit szeretnél szemléltetni az ábrákkal?
2. A Gépi Kódú programozás c. könyv szerint bal:9 és jobb:53 lehet a maximum margótávolság. Ami azon kívül van, az nem jelenik meg. Te mégis nagyobb szélességet adtál meg. Ez hogy lehet?
Title: Re: NICK
Post by: Zozosoft on 2012.February.05. 17:50:40
Ami azon kívül van, az nem jelenik meg.
Szerintem a saját TV-jükbõl indultak ki.
Title: Re: NICK
Post by: IstvanV on 2012.February.05. 18:57:24
1. Mit szeretnél szemléltetni az ábrákkal?

A vízszintes időzítést, a ténylegesen megjeleníthető margókat, és a VBLANK/VSYNC mód hatását a video kimenetre.

Quote
2. A Gépi Kódú programozás c. könyv szerint bal:9 és jobb:53 lehet a maximum margótávolság. Ami azon kívül van, az nem jelenik meg. Te mégis nagyobb szélességet adtál meg. Ez hogy lehet?

Hasznos video információ a 8 és 54 között jelenthető meg (46 karakter). De amint az ábrákon látható, az első karakternek valamivel több, mint a fele elveszik (RGB kimeneten talán nem így van). A 47. karakter a 46. ismétlése, mert itt a NICK már DRAM frissítést végez, és nem tudja olvasni a video adatot (az adatbuszon maradt "szemét" jelenik meg).
Title: Re: NICK
Post by: Tuby128 on 2012.February.05. 19:22:25
Tehát a Nick 46 (text 40-es) karaktert képes kijelezni, ami 16*46=736 képpont szélesség.

 Azt tudom, hogy az IS-BASIC editorja 24 soros+ 1 (statussor), ezen felül még 4-5 további sor jeleníthetõ meg az utolsó sor után.
 A nagyobbal számolva 24+1+5=30 sor. Egy sor 9 pixel magas így 30*9=270 pixel a szélesség. Interlace módban kétszerese, így 540 képpont a magasság.

 Én mint külsõ Nick készítõ, azt szeretném kérdezni, hogy van-e olyan szoftver EP-re, amely interlace módban 270 képpontnál többet jelenít meg függõlegesen. Ha igen, akkor szeretném megvizsgálni az általa gyártott sorparaméter táblát.
Title: Re: NICK
Post by: IstvanV on 2012.February.05. 20:44:14
Azt tudom, hogy az IS-BASIC editorja 24 soros+ 1 (statussor), ezen felül még 4-5 további sor jeleníthetõ meg az utolsó sor után.
 A nagyobbal számolva 24+1+5=30 sor. Egy sor 9 pixel magas így 30*9=270 pixel a szélesség. Interlace módban kétszerese, így 540 képpont a magasság.

A TV kártyák 576 (2x288) sort jelenítenek meg, ami szabványosnak tekinthető (overscan nélkül). Legalább ennyit érdemes támogatni.

Quote
Én mint külsõ Nick készítõ, azt szeretném kérdezni, hogy van-e olyan szoftver EP-re, amely interlace módban 270 képpontnál többet jelenít meg függõlegesen.

IVIEW :)
Title: Re: NICK
Post by: Tuby128 on 2012.February.05. 21:31:24
Igen látom, az IView egy új szoftver.
Máshogy kérdezem: Az EP-s felhasználói programok 98%-a nem használ interlace technikát, ugye?
A maradék 2% (mint pl. az IView) pedig igen.
Title: Re: NICK
Post by: Ep128 on 2012.February.05. 23:25:16
Igen látom, az IView egy új szoftver.
Máshogy kérdezem: Az EP-s felhasználói programok 98%-a nem használ interlace technikát, ugye?
A maradék 2% (mint pl. az IView) pedig igen.

De jelzem, ez nagyon fontos 2%! :lol:
Szóval kalkulálnod kell a létezésével!
Title: Re: NICK
Post by: lgb on 2012.February.05. 23:25:37
2. A Gépi Kódú programozás c. könyv szerint bal:9 és jobb:53 lehet a maximum margótávolság. Ami azon kívül van, az nem jelenik meg. Te mégis nagyobb szélességet adtál meg. Ez hogy lehet?

"Nem jelenik meg XYZ TV-n", max igy erdemes felfogni :) Modern megoldasokkal (lcd/stb tv, tuner kartya) meg minden megjelenik kb ami elvileg lehetseges. Imho azt kene nezni hogy mi az a max amit a Nick tud, nem azt hogy anno mire irtak hogy "megjelenik", hiszen az meg analog tv-s dolgokkal operalt overscan stb keretein belul, itt meg vga jel, modern tv-k stb kerulnek elo ... Ha valamit a Nick tud (meg ha azt ir irjak: nem fog megjelenni bla-bla) azt egy kompatibilis megoldasnak is tudnia kell, imho (azt hogy valami "nem jelenik meg abbol" az a tv korlataibol fakad es nem a nick-ebol, tehat nem nick oldalon kene "lefaragni").
Title: Re: NICK
Post by: lgb on 2012.February.05. 23:28:50
De jelzem, ez nagyon fontos 2%! :lol:
Szóval kalkulálnod kell a létezésével!

Arrol nem is beszelve, hogy sok ember "ramozdulna", ha lenne ilyesmi, azaz beindulnanak a "maxot kihozo" programok irasa EP-re talan, ha lenne modern megoldas amivel szepen meg is jelenitheto :)
Title: Re: NICK
Post by: szipucsu on 2012.February.05. 23:37:53
Arrol nem is beszelve, hogy sok ember "ramozdulna", ha lenne ilyesmi, azaz beindulnanak a "maxot kihozo" programok irasa EP-re talan, ha lenne modern megoldas amivel szepen meg is jelenitheto :)
Ezt sajnos kizártnak tartom, pár emberen kívül nem nagyon írnak EP-ra programokat. Vagy lehet, hogy ez is változna?
Az Iview kompatibilitás valóban fontos lenne.
Title: Re: NICK
Post by: Tuby128 on 2012.February.05. 23:41:47
Az a bajom az Interlace sorokkal, hogy nem egymás után következnek, tehát nem tudom egyszerû rutinnal soronként kiolvasni/betölteni.

Ha tényleg csak egy-két program van, akkor érdemesebb volna talán kiegészíteni õket, hogy ha detektálja a külsõ Nick-et, akkor ne interlace módban próbálja megjeneníteni a képet.
Interlace mód helyett ajánlom a kihasználatlan videomódot. (ott azonban még nem tartok)
Title: Re: NICK
Post by: IstvanV on 2012.February.05. 23:58:22
Az a bajom az Interlace sorokkal, hogy nem egymás után következnek, tehát nem tudom egyszerû rutinnal soronként kiolvasni/betölteni.

Az ilyen jellegű problémák elkerülhetők a NICK tényleges működésének az emulációjával, amire az ep128emu is törekszik (a TV emulációját, függőleges szinkronnal és interlace móddal együtt, külön megoldva), és lényegesen jobb kompatibilitást lehet elérni, mint a "magas szintű" megvalósítással (ami elsősorban akkor előnyös, ha nem lényeges a kompatibilitás, és a továbbfejlesztés az elsődleges cél).
Egyébként nem fontos, hogy egymás után következzenek az interlace módú sorok, ha jobban nem lehet megoldani, elég az is, ha a félképek felváltva jelennek meg, az egyiket fél sorral eltolva (valójában a CRT TV-k és monitorok is így működnek).
Title: Re: NICK
Post by: Tuby128 on 2012.February.06. 00:46:34
Fontos kiemelni az alapvetõ célt, hogy külsõ Nick feladata az, hogy végre szakítson a TV-s hagyománnyal, és legyen "szép" kép a monitoron. Tehát a videomemória tartalma pixelre pontosan jelenjen meg a képernyõn. Ne villogjon, és ne legyen szellemképes.
 Én a 800x600-as felbontást választottam, mert abba biztosan minden korábban írt EP program el fog férni.

- Nem emulálok Nick-et, ez egy teljesen új HW lesz, de kompatibilis a sorparaméter táblával
- Azokat a szabályokat fogom alkalmazni amelyeket a NICK betartott, kivéve a szinkroninformáció
- Vízszintes szinkront a HW-em elvégzi, ami a 800-as vízszintes felbontáson túlnyúlik, az nem fog megjelenni
- Függõleges szinkront is elvégzi, ami nem fér bele a 600-as függõleges felbontásba, az nem jelenik meg

A hardverem ezt a szabályt követi:
1. Minden megjelenítendõ sor elõtt kiolvassa a hozzá tartozó sorparaméter-blokkot, ez alapján határolja be a megfelelõ memóriaterületet.
2. A pixelhez tartozó byte-ot (a pixel kirajzolása elõtt) beolvassa.
3. Minden kirajzoláskor egyazon idõben a következõ pixelt olvassa ki.

Mivel a legtöbb EP-s program non-interlace volt, ezért úgy döntöttem minden sor kétszer lesz kirajzolva.

Ha valaki nagyobb függõleges felbontást akar, jelzi a HW-nek (In/Out utasítással), és nem 27 soros lesz a sorparaméter táblája hanem 54. Esetleg nem 9 pont magas lesz egy sorparaméter-blokk, hanem 18.
Title: Re: NICK
Post by: Zozosoft on 2012.February.06. 08:56:13
Ha valaki nagyobb függõleges felbontást akar, jelzi a HW-nek (In/Out utasítással), és nem 27 soros lesz a sorparaméter táblája hanem 54. Esetleg nem 9 pont magas lesz egy sorparaméter-blokk, hanem 18.
Akkor ezek szerint már nem teljesül ez a feltétel: kompatibilis a sorparaméter táblával
Így gyakorlatilag csak a BASIC programok fognak futni rajta.
Title: Re: NICK
Post by: Zozosoft on 2012.February.06. 09:21:12
Ha valamit a Nick tud (meg ha azt ir irjak: nem fog megjelenni bla-bla) azt egy kompatibilis megoldasnak is tudnia kell, imho (azt hogy valami "nem jelenik meg abbol" az a tv korlataibol fakad es nem a nick-ebol, tehat nem nick oldalon kene "lefaragni").
Egyetértek, úgy érdemes belevágni, ha mindent tudni fog amit az eredeti.
Title: Re: NICK
Post by: lgb on 2012.February.06. 11:13:33
Ha valaki nagyobb függõleges felbontást akar, jelzi a HW-nek (In/Out utasítással), és nem 27 soros lesz a sorparaméter táblája hanem 54. Esetleg nem 9 pont magas lesz egy sorparaméter-blokk, hanem 18.

Na ezt most vegkepp nem ertem: a Nick szepsege szamomra abban all, hogy LPT-vel mindent meg lehet neki mondani, I/O port max arra kell hogy hol van az LPT (ok, tudom van meg mar funkcio pl color bias vagy mi is volt - de a lenyeg ez) es minden _mas_ kovetkezik mar az LPT-bol. Pont ez volt az erossege, hogy mas video hw-tol elteroen nem volt egyeb "globalis" regiszter stb, hanem lpt, ami egyreszt szerintem hihetetlenul elegans, masreszt nagyon sok trukkot lehetove tesz. Ha most te extra I/O portot akarsz bedobni, hogy ezt/azt kulon lehesen kozolni vele, akkor egyreszt nem lesz kompatibilis, masreszt ezt a "szepseget" fogja pont elvesziteni a dolog.

Amikor sajat emulator kezdemenyemmel jatszottam ezzel, es csak ugy unalmamban "felturboztam" akkor ott max olyan volt plusz I/O portra, hogy slot/byte sokszorozas: az alap 2 byte/slot memoria olvasast lehetett sokszorozni, igy pl 256 szinu mod lehetett nagyobb felbontasban is (mellekhataskent igy az olvasott lpt is "hosszabb" lett pl lehetne 16 szinu modban a maradek 8 szint is akkor belevenni, vagy egyeb plusz infot bele-encode-olni, stb). Amde ugye ez nem kompatibilis az eredeti hw-vel, mindazonaltal ott ez nem is volt gond: ha ez nem volt beallitva, siman ment mint a "regi", tehat nyilvan kompatbilitasi gondot nem okoz, max persze nyilvan az uj feature csak uj software-rel hasznalhato. Amde az mas kerdes, ha te meglevo, eredeti Nick-el beallithato dolgot akarsz ugy megoldani, hogy az maskepp megy, mint az eredeti Nick-en: ekkor viszont megszunik a mar meglevo nick feature-ok kompatibilitasa is.

Van par dolog, ami az lpt-s szemlelet miatt nagyon tuti szerintem, ilyen peldaul hogy elvileg nem kotott karakteres modban a karakter "magassaga", hanem tetszoleges lehet, mert pl ezt is az lpt irja le. Az lpt-s szemleltbol fakad tovabba az, hogy felbontasok keverhetoek egy kepernyon belul, mivel extrem esetben akar per scanline tudsz mast es mast megadni, stb stb, lehetne folytatni.
Title: Re: NICK
Post by: Tuby128 on 2012.February.06. 12:09:30
Látom Zozo nem vagy hajlandó túllépni azon a problémán, hogy "Szoftver ne vezéreljen függõleges szinkront". Én is szerettem a Nick-kel játszani, jó volt, szép volt, de most ideje tovább lépni.
Nem szabad majmolni a televíziós megjelenítést, volt belõle elég probléma a múltban, a számítástechnika túllépett a váltott soros megjeleníten, jelenleg a számítástechnikai eszközeink elég gyorsak ahhoz, hogy elvégezzék a megjelenítést vibrálás nélkül. Nem butítom le a Nicket, még nagyobb felbontást kínálok mint az eredeti.
A függõleges szinkronnal csak a gond van. Minden szempontból.

- Különben is, mi a csudát csináljon egy SVGA monitor a televíziós szinkronjelekkel?
- Semmit! Az nem neki szól. Ezért nem veszem figyelembe.


Title: Re: NICK
Post by: lgb on 2012.February.06. 13:23:43
Látom Zozo nem vagy hajlandó túllépni azon a problémán, hogy "Szoftver ne vezéreljen függõleges szinkront". Én is szerettem a Nick-kel játszani, jó volt, szép volt, de most ideje tovább lépni.

Ha tovabb akarsz lepni, akkor azt mondod, hogy az EP/Nick-rol kell tovabblepni, az miert jo? Ez a forum pont arrol szol, hogy az EP szep es jo (es nem csak "volt", hanem jelen idoben is az). Lehet olyat is, amit akarsz, de akkor az mar egy EP 2.0, ami viszzamenolegesen nem (vagy nem teljesen) kompatibilis, megha ezzel sok pluszt is nyujthat mondjuk.

Quote
Nem szabad majmolni a televíziós megjelenítést, volt belõle elég probléma a múltban, a számítástechnika túllépett a váltott soros megjeleníten, jelenleg a számítástechnikai eszközeink elég gyorsak ahhoz, hogy elvégezzék a megjelenítést vibrálás nélkül.

Igen, tullepett, ilyen elven hasznaljunk PC-t, es felejtsuk el az EP-t, hiszen azon mar a technika tullepet. Ez objektiv technikai nezopontbol amugy igaz is.

Quote
Nem butítom le a Nicket, még nagyobb felbontást kínálok mint az eredeti.

Szerintem inkabb _SEMMI_ plusz ne legyen (se nagyobb felbontas, se semmi!), de legyen kompatibilis a Nick/EP-vel, ahogy az megteremtetett. A plusz extra feature-ok mar csak bonusz dolgok, az egesznek az lenne az ertelme, hogy a kompatibilitas teljes legyen, es csak _utana_ jojjenek az esetleges extra feature-ok, mint a nagyobb felbontas.

Quote
A függõleges szinkronnal csak a gond van. Minden szempontból.

Ahogy az EP-vel is "csak a gond van", ha megkerdeznel egy modern hw-t programozot, hogy mit szol hozza, hogy 8 bites CPU, meg 64K address bus a CPU szempontjabol legalabbis stb, az o valasza is az lenne: ezzel csak a gond van, a technika ezen tullepett, szep volt, jo volt, de ideje haladni; tessek 32 vagy inkabb 64 bites cpu-kban es gigabyte-nyi memoriakban gondolkodni :)

Quote
- Különben is, mi a csudát csináljon egy SVGA monitor a televíziós szinkronjelekkel?
- Semmit! Az nem neki szól. Ezért nem veszem figyelembe.

Az SVGA monitor ne is csinaljon vele semmit, igazad van! Lasd lentebb.

A nick "TV-hez" keszult, ezt ne felejtsuk el :) Ha ezt el akarod felejteni, akkor ez nem "Nick v2" lesz, hanem valami tok mas.

Amugy nezz meg egy enterprise-128 emulatort (pl ep128emu): a "kimenet" ott sem TV ugye, tekintve, hogy egy ablakban latod. Megis le van emulalva, hogy van szinkronjel, stb. Nem is mondta senki, hogy a szinkronjelet az SVGA monitornak kell ertelmezni. De alapvetoen az egesz Nick az TV signalt allit elo, es ehhez meg jobban is kotodik mint mas 8 bites gepek video hw-je: ha nezed pl a C64 VIC-II-jet, ott van globalis video mod, oszt' csokolom (ok, raster interrupt, miegymas: elvileg ott is modosithatod persze "menet kozben" a dolgokat, de nem olyan egyszeru es elegans mint a Nick-nel), ott pl sokkal egyszerubb azt mondani, hogy epitek egy VIC-II v2.0-at, amde a Nick eseten eleg kemeny fuggosegek vannak a tv szabvany egyes dolgaival, hiszen jovan nagyobb reahatasod van egyszeru LPB-kkel az LPT-n belul, hogy mit csinaljon, mig VIC-II eseten ugye mindent a hw csinal, nem a te dolgod a szinkronjelek eloallitasa. Viszont pont ezert is szep a Nick.

Elvileg egy software emulator is ugy csinalja, es imho egy Nick v2.0-nak is ugy kene, amit Zozo is javasolt: van egy privat memoriaterulet (kulon memoriakent realizalva) amit nevezzunk "frame buffernek". Ebbe "renderel" a Nick kvazi. Ezt meg folyamatosan olvassa egy masik entitas, aminek a feladata a VGA videojel eloallitasa. Igy a ketto tobbe/kevebe fuggetlen, sot, extrakent akar itt is meg lehet oldani a "TV signal"-t a VGA melett, hogy menjen azzal is, ha valakinek ez az alma :) Ilyenkor ugye a Nick szempontjabol a fuggoleges szinkronjel annyi lesz, hogy mikor kezdi elolrol a framebuffer irasat, es hasonlok, paros/paratlan sor, stb, tehat kvazi minden kezelheto, amit csak el lehet kepzelni. Plusz akkor az sem gaz, hogy egy monitornak mondjuk kotott felbontas es frissitesi frekvencia kell, aminek lehet, SEMMI DE SEMMI koze nincs ahhoz, ahogy a Nick mukodik.
Title: Re: NICK
Post by: Tuby128 on 2012.February.07. 14:34:42
A TEXT 80-as szövegmódot ugyanúgy generálja a NICK mint a TEXT 40-est? Tehát adatcím és hozzá a karakterlap? Vagy a Z80 helyezi el grafikus módban?
Title: Re: NICK
Post by: Zozosoft on 2012.February.07. 14:36:48
Vagy a Z80 helyezi el grafikus módban?
Igen, az két színû grafikus, pluszban játszva a spéci bitekkel, hogy ne csak két szín legyen.
Title: Re: NICK
Post by: lgb on 2012.February.07. 14:57:54
A TEXT 80-as szövegmódot ugyanúgy generálja a NICK mint a TEXT 40-est? Tehát adatcím és hozzá a karakterlap? Vagy a Z80 helyezi el grafikus módban?

Szerintem a TEXT80 az valojaban nem TEXT hanem pixel mode, mivel normal karakteres felbontasnal egy karakterhez kell olvasni "chargen" adatot meg a charater kodot, azaz egy slot-ra kimerult a ket byte, igy persze 80 szolopos - valodi - karakteres mod nem lehetseges igy. Az szerintem sima pixel mode valojaban, hiszen igy nincs szukseg karaktergenerator infora, es a 2 byte / slot read rate egy slot-ra 16 pixelt eredmenyez 1 bpp modban, ergo igy mar lehetseges 80 "karakter", persze, ha oda lett "renderelve" cpu altal mint plain pixel adat aztan :)
Title: Re: NICK
Post by: Tuby128 on 2012.February.07. 16:22:21
Akkor szerintem úgy fogom megcsinálni a külsõ Nick-et, hogy ezt õ fogja kiolvasni és megírni. Az a baj, hogy mivel nincs ilyen mód a paramétertáblában nem tudom mi módon fogja felismerni, hogy az szöveg vagy grafika.
Title: Re: NICK
Post by: Zozosoft on 2012.February.08. 10:14:44
Akkor szerintem úgy fogom megcsinálni a külsõ Nick-et, hogy ezt õ fogja kiolvasni és megírni. Az a baj, hogy mivel nincs ilyen mód a paramétertáblában nem tudom mi módon fogja felismerni, hogy az szöveg vagy grafika.
Szerintem nem kéne mindenféle kivételeket pakolni belepakolni, abból csak inkompatibilitás lesz. Olvasni kell az LPT-t és végrehajtani ami abban van, úgy ahogy az eredeti is teszi. Új ötleteknek ott van a nem használt üzemmód.
Title: Re: NICK
Post by: Tuby128 on 2012.February.08. 16:45:25
Az a baj, hogy a nem használt üzemmódból csak egy van. Meg kéne nézni, hogy az LPB második byte-jából hogyan lehetne kihozni extra módokat.
PL: A 64 vagy 256 karakter mód esetén a 4, 16 és 256 színû módot szerintem nem nagyon használja semmilyen alkalmazás. Oda betenném mondjuk a TEXT 80-as megoldást TEXT 40 mintára.

Bár a nem használt mód 4 féle színmóddal használható. Ez nagyon izgalmas.

Továbbá arra gondoltam, hogy a kivágás- beillesztés dologhoz (ami nagyon hiányzik nekem az EP-bõl) megcsinálnám úgy, hogy ha a 2. adatmezõ karaktereinek 7.bitje '1' akkor a betû színei invertálva lennének, így könnyebben kijelölhetõvé válna a soron belül a karakter.
 Mivel ezt a NICK automatikusan csinálná, az EP-vel való szövegszerkesztés felgyorsulna. (Nekem legallábbis az Asmon editor nagyon lassúnak hat.)
Title: Re: NICK
Post by: IstvanV on 2012.February.08. 18:40:31
Az a baj, hogy a nem használt üzemmódból csak egy van.

A "nem használt" módban esetleg a paletta byte-ok felhasználhatók más célra ?
Title: Re: NICK
Post by: lgb on 2012.February.09. 08:36:14
Szerintem nem kéne mindenféle kivételeket pakolni belepakolni, abból csak inkompatibilitás lesz. Olvasni kell az LPT-t és végrehajtani ami abban van, úgy ahogy az eredeti is teszi. Új ötleteknek ott van a nem használt üzemmód.

Ahogy mar emlitettem, en azt csinalnam, hogy megengednem, hogy a 2 byte / slot nick olvasasi rate-et duplazni (vagy plane sokszornozni) lehessen. Ez persze nem backward compatible, de ez extra feature, x1 szorzoval pontosan a regi helyzet van az meg a default, hacsak valaki nem allitana at. Pl x2 modban 4 byte-ot tudna olvasni a nick 1 slot-ban, ezt pedig a felbontas novelesre tudna forditani, ergo text40-bol lenne - valodi - text 80 (es nem pixel moddal "hamisitott" text80 hehe), illetve kulonbozo pixel-es modokra is rafer nehol a vizszintes felbontas novelese, kulonosen pl 256 szinu modban :) Raadasul, mivel ekkor 1 slot-ban tobb byte olvashato, ezen beallitas hatasara a beolvasott LPB merete is megno, amiben extra infok lennenek hordozhatoak (pl 16 szinu paletta maradek 8 szine, es egyeb dolgok).

Szerintem ez jar a legkevesebb "filozofia beli" toressel, nem kell uj video mod, semmi. Ez mondjuk tenyleg nem tul LPB-s megoldas, ez imho globalis beallitas lehetne (pl I/O porton at) legyen mondjuk "nick read rate", a default es "original nick compatible" az persze a x1, ami az 1-szeres szorzo a 2 byte/slot eredeti ertekhez. Igy ezzel kb minden videomod mindenfele kulon valtoztatas nelkul novelheto felbontashoz jut, na persze konkretan a 2 szinu pixel modnal sok ertelme nincs, hiszen az a 736 (ha jol irom fejbol) pixel a max :) De pl 4 szinu uzemmodban (2 bpp) x2 rate-el olvasva maradt a 736 pixel felbontas, igy nem felezodik, ahogy amugy tenne. 16 szinu uzemmodban a max elmeleti felbontashoz mar persze x4 szorzo kene, 256 szinu uzemmodban meg x8. Kerdeses, hogy egy adott hw-ban van-e annyi "power", hogy a x8 elerheto legyen, es a timing megmarad-e, nyilvan emulatorban nem gond ilyet osszeheggeszteni, ahogy anno en tettem :)

Aztan meg az volt, hogy plusz I/O porttal volt nalam palette, a 256 "vegso" EP szin (amihez szinten egy palregen vezet az ut pl 16 szinu modban ugye) allithato, 2 byte/color megoldassal (azaz 16 bites szinmelyseg). Nalam a nem hasznalt videomod ez a "nativ" mod lenne, amikor egy pixel tetszoleges 16 bites erteket felvehet :) A felbontas csapnivalo persze! Ilyenkor szinte "must have" a read rate sokszorozas: x8-as rate-el jon elo kb a ~360 pixel, ami mar nem olyan rossz, es hi-color mod :)

Amennyire en latom, a felbontas novelesere sokkal jobban "nick filozofia" az, hogy mindent hagy az ember pontosan ugy ahogy van, es a read rate-et teszi valtoztathatova, ekkor ez kb olyan elemi parameterre valik mint az lpt kezodcim beallitasa (hiszen ez pl valtoztatja egy lpb meretet is akar!), ezert kerulne ez i/o portra. A globalis paletta szinten egy ilyesmi dolog. Mas imho nem nagyon kene hogy legyen ami custom extra I/O portot kivan, x1 read rate folott egy LPB hossza megno: ez felhasznalhato boven az extra infok tarolasara amire esetleg szukseg van! Anno az is felmerult bennem, hogy pl read rate novelese eseten allithato legyen mire forditodik az extra read-ek "idoszelete", logikus a felbontas novelese (amirol eddig szo volt), de az is eszembe jutott anno, hogy nebezetem az LD3 pointer-t, stb, es siman pl egy belso memoriat tolthet, amit mondjuk igy sprite kijelzesre is hasznalhatna, utana. Elonye: az std nick read timing megmaradna (marmint a sokszorozott teny mellett), nem kell extra "sprite DMA" mint c64 VIC-ii eseten ami aztan felborit ott egy csomo dolgot, es pl azert kellett a floppy serial-IEC-et meg jobban belassitani, mert a vic-ii miatt neha a CPU-tol elkerul a control "hosszabb" idore. Vagy stb, nyilvan szamtalan lehetoseg van :) :)
Title: Re: NICK
Post by: lgb on 2012.February.09. 08:39:30
A "nem használt" módban esetleg a paletta byte-ok felhasználhatók más célra ?


Hasonlo "orult" otletem volt egyszer, hogy a harom (?) utolso nem hasznalt nick slot-ot (dram frissites, vagy mi is van ott) egy "nick+"-on lehetne arra hasznalni "custom data" olvasasara, igy pl akar lehetne digital sample lejatszas nulla CPU idovel :-P persze erdekes, hogy a dave "hang" dolgai mellett a nick hogy jon ide, de a nick legalabb kezdemenyezhet memoria olvasast, a dave ugye nem .... Nyilvan ehhez bufferelni kell persze, hiszen nem "folyamatos" az olvasas ahogy kell, hanem minden scanline vegen (?) lehet csak. Stb stb.
Title: Re: NICK
Post by: Zozosoft on 2012.February.09. 09:25:58
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)
Title: Re: NICK
Post by: Tuby128 on 2012.February.09. 19:03:09
Hardveres sprite vezérlõvel lehetõség nyílik a grafikus felhasználói felületen a nyílmutató mozgatására különösebb processzorhasználat nélkül.
 PC-n úgy oldja meg a Windows GUI, hogy: (mondok példát)
Van egy 600x500-as ablak, amiben ki van feszítve egy azonos méretû bitmap, és ez a háttér. Ebben szeretnénk elhelyezni egy piros teli kört, melynek átmérõje 50 képpont. Mivel a kör egy 50x50-es bitkép a körön kívûl esõ (de még az 50x50-es ablakban lévõ) pontok 0-ra vannak megválasztva.
Amikor ezt kirajzolom, akkor ezek a nullák is rákerülnek a képre, és nem kör jelenik meg, hanem fekete négyzet benne egy körrel. Bármilyen módot választottam a kirajzolásra (bitenkénti OR vagy AND vagy XOR), a négyzet akkor is kirajzolva maradt.
 Ezután hosszasan keresgélve találtam egy olyan függvényt, amely a következõket engedte meg:
Ha készítek az 50x50-es bitképhez egy "maszkot", ami ugyanolyan méretû, és ahol azt akarom, hogy kirajzolásra kerüljön ott '1'-ek vannak ahol pedig nem ott nullák. Így akár "lyukas" ábrák is készíthetõk.
 Ehhez már egyre bonyolultabb HW kell, vagy egyre erõsebb CPU.

 Úgy veszem észre, fõleg nálad Zozo, hogy minden perifériális mûveletet hardveresen akarsz megoldani, hogy a Z80-nak a lehetõ legkevesebb mûveletet kelljen végrehajtania.
Title: Re: NICK
Post by: lgb on 2012.February.09. 22:19:38
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)

Sajna a sprite kezeles eleg trukkos. MSX-eknel is valami olyan volt h limitalt mennyi sprite tartozkodhat egy scanline-ba (a veges rendelkezesre allo ido miatt), C64-en meg pl konkretan igen komoly idozitesi gondok adodnak amikor a VIC-II ugy dont, hogy neki tobb ido kell (viszont ott nincs korlat, 8 sprite barhol lehet, nyilvan sprite multiplexinggel tobb is lehetseges pl raster irq-bol allitgatva menet kozben).

De a legfobb problemat ott latom, hogy a sprite milyen olyan mar kevesbe LPT/LPB specifikus, hiszen pont az a lenyege, hogy "barhol" lehet, es egyszeruen oda is rakhato (1-2 reg atirasaval). Szoval ez viszont mar az a tema, amihez tenyleg kulon I/O port kell. Plusz kell Nick v2.0-nak ido hogy olvassa a sprite pixel adatokat kulon ... Esetleg olyan "extra" eljaras, hogy LPB extra byte-jaiba (mondjuk ha x2 uzemmod aktiv, vagy magasabb, akkor oda lehet ilyet is tenni) "encode"-oljuk magat a sprite adatot, igy annyi sprite lehet ami ebbe belefer. Igy viszont egy frame alatt nem valtozhat, ami mondjuk kevesbe is problema imho, mert ugyse lathatoak nagyobb frissitessel :) Plusz akkor maga a sprite pozicionalis is lehetne (elvileg) valahol (hmm vsync mod alatt, hasonlo?), es akkor onnan "felszedi" minden frame elejen, igy nem kell kulon globalis I/O regiszter, hanem az LPT egy kvazi jol definialt helyen vannak benne ezek az adatok is. Esetleg bevezetni egy LD1, LD2 melle egy LD3-at: szinten az extra LPB byte-okba, es az mutat a sprite terulet kezdetere, stb stb, whatever.
Title: Re: NICK
Post by: lgb on 2012.February.09. 22:28:07
Hardveres sprite vezérlõvel lehetõség nyílik a grafikus felhasználói felületen a nyílmutató mozgatására különösebb processzorhasználat nélkül.
 PC-n úgy oldja meg a Windows GUI, hogy: (mondok példát)
Van egy 600x500-as ablak, amiben ki van feszítve egy azonos méretû bitmap, és ez a háttér. Ebben szeretnénk elhelyezni egy piros teli kört, melynek átmérõje 50 képpont. Mivel a kör egy 50x50-es bitkép a körön kívûl esõ (de még az 50x50-es ablakban lévõ) pontok 0-ra vannak megválasztva.
Amikor ezt kirajzolom, akkor ezek a nullák is rákerülnek a képre, és nem kör jelenik meg, hanem fekete négyzet benne egy körrel. Bármilyen módot választottam a kirajzolásra (bitenkénti OR vagy AND vagy XOR), a négyzet akkor is kirajzolva maradt.
 Ezután hosszasan keresgélve találtam egy olyan függvényt, amely a következõket engedte meg:
Ha készítek az 50x50-es bitképhez egy "maszkot", ami ugyanolyan méretû, és ahol azt akarom, hogy kirajzolásra kerüljön ott '1'-ek vannak ahol pedig nem ott nullák. Így akár "lyukas" ábrák is készíthetõk.
 Ehhez már egyre bonyolultabb HW kell, vagy egyre erõsebb CPU.

 Úgy veszem észre, fõleg nálad Zozo, hogy minden perifériális mûveletet hardveresen akarsz megoldani, hogy a Z80-nak a lehetõ legkevesebb mûveletet kelljen végrehajtania.

Na ez erdekes velemeny :) Te mondod, hogy tul kene lepni a vsync-en meg par probleman, erre viszont pont a "tullepesert" panaszkodsz, ha mas temaban mas teszi ezt :) Imho akkor van ertelme vmit hw-esen megoldani, ha az amugy nem tul bonyolult: marpedig sprite nagyon sok 8 bites gepen volt, tehat nem lehetetlen megoldani nyilvan. Plusz, erdekes, hogy modern PC-kben kb mindent "nem a CPU" csinal (lasd 3D grafika, fizikai gyorsitas, stb), az talan nem gaz, ha adsz egy kis pluszt egy regi gepen is (foleg, mivel ott nagyobb szukseg van ra, eleve gyengebb a cpu mint egy mai pc-n!), felteve, ha amugy ez csak extra, amit nem kotelezo hasznalni, es nem hasznalva azt 100% a kompatibilitas.

Masreszt, azert modern PC-re irt, modern GUI-k sok esetben szinten sprite szeru entitasokat hasznalnak, csak ott a vga kartya csinalja. Meg ha csak 2D-only-ban gondolkozunk ott is van hardware-es BES altalaban (Back-End Scaler, esetleg color space koverzioval mint YUV stb, color key), kulonbozo copy/stb muveletek, es hasonlok. Ilyen mar egy viszonylag "oskori" kartyan is van, mint amilyen az S3 Trio pl (na jo, persze egy Trident 8900-ashoz kepest - ha jol remlik h mi is volt nekem anno -, ez mar haladas ...).
Title: Re: NICK
Post by: geco on 2012.February.10. 09:29:11
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)

Igen, MSX, abból is az MSX II lenne érdekes, meg az Amstrad CPC+.
Title: Re: NICK
Post by: Pgyuri on 2012.February.10. 15:04:44
Üdv,

Előre is elnézést kérek a hozzászólásomért, én csak egy egyszerű ZX szoftveres vagyok, tessék figyelembe venni.

Teljesen megértem lelkesedését hardver guruknak a téma iránt és jó is az elmélkedés, de ...

... számomra megfoghatatlan, mire is lenne jó ezt a kedves kis Enterprise-t bővíteni ilyen grafikai és sprite dolgokkal:

1; Először is nem lenne senki, aki írna új játékokat, amelyek kihasználnák.
2; Ha lenne is, akkor se lesz mindenki gépe átalakítva ehhez az újdonsághoz.
3; A régi játékok "tuning"-olásának sincs értelme.

Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bővítés, de az is minek, mikor egyetlen egy program se kérdezi le.

A témához kapcsolódóan idézet egy korábbi hozzászólásból (talán itt lesz a helye Zozo):

"Idézném a Speccyalista napon elhangzott beszélgetés részletét:

 PGyuri: Mire tervezték az EP-t?
 Moldani: A világ legjobb számítógépét akarták megcsinálni!"

Nos ez egyértelműen nem sikerült, mert ha azt szerették volna, akkor egyrészt a SPRITE fogalmát nem hagyták volna ki (mondjuk tervez(het)ték hozzá), de a leglényegesebb elemet akkor se felejthették volna el, mégpedig a

               gyors horizontális scroll lehetőségét !

Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették. Spectrumon sokat gondolkoztam, hogy ottani hardver mestereinket meggyőzöm egy interface készítésével, amely képes a scroll műveletét elvégezni a processzor helyett, de mindig arra jutottam, hogy úgyse lenne rá program, így felesleges még a gondolatával is foglalkozni.

Ettől függetlenül szívesen olvasom Nick úr minden lépését :)

Pgyuri
Title: Re: NICK
Post by: Zozosoft on 2012.February.10. 15:24:37
               gyors horizontális scroll lehetõségét !

Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyõ mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függõleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették.

Igen, ezért is javasoltam korábban:
Quote
Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül.
Title: Re: NICK
Post by: Zozosoft on 2012.February.10. 15:38:51
Amit a NICK gyárilag tud sprite ügyben: van neki 4 bites szín bemenete, ami ki van vezetve a rendszerbuszra. Szintén a buszon vannak a szinkronjelek, és a videóórajel, ennek segítségével lehetne a külsõ sprite hw szinkronban a képpel, hogy a megfelelõ helyen adja a megfelelõ szín információt.
A 80h regiszteren lehet szabályozni, hogy mi történjen a külsõ színekkel:
-mindig a kívül megadott szín jelenik meg
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva, vagy ha 0-7 külsõ színek vannak használva
-a külsõ szín jelenik meg, ha a képen a 8-15 színek vannak használva, vagy ha 0-3, 8-11 külsõ színek vannak használva
(Ezt állíthatjuk a Sprite EXOS változóval.)

Mivel gyakorlatban még nem készült (vagy legalábbis nem jelent meg) ezt kihasználó hw, így nem tudni, pontosan mi is történne enne használatával, különös tekintettel a különbözõ színmódokra. Nem tartom elképzelhetetlennek azt se, hogy esetleg 2 szín módban is legyenek 16 színû sprite-ok.
Title: Re: NICK
Post by: lgb on 2012.February.10. 20:03:04
... számomra megfoghatatlan, mire is lenne jó ezt a kedves kis Enterprise-t bővíteni ilyen grafikai és sprite dolgokkal:

Imho azert, mert ha valaki realizalja a cucot egy FPGA-ban, ami ugye vmi leiro HDL nyelven leirja a hardware-t, akkor a dolgok oroszlanresze az lenne, hogy megcsinalni - lehetoleg pontosan! - azt amit az eredeti Nick tudott, es semmi tobbet. Ez azert nem olyan kis munka, ha belegondolunk. De szerintem legalabbis ezen a szinten az lenne a cel, hogy legyen EP "tokeletes minosegu" videokimenettel pl monitorok szamara, illetve deffektes Nick helyettesitesere stb. Nu, ehhez kepest mar nem olyan nagy szam, ha egy-ket extrat beletesz az ember, ha mar az egesz "vaza" adott. Akkor meg jon a "miert ne" kategoria. Jo peldanak tartom erre a C64DTV-t: ugye az uzleti cel az volt hogy legyen egy kis joystick dimenzioban merheto cucc rajta csomo jatek, C64-es kesz. Erre Jeri Ellsworth csinalt valamit, ami fura dolognak hathat: pl 2Mb memoria van, uj videomodok, kothetsz ra PS/2 billentyuzetet, drive-ot, stb. A kerdes ugyanaz, amit te is emlitesz: ezt minek, ha egyszeruen megvolt a cel azzal is, hogy egy sima C64-et ugy emulalni, ahogy anno ment. A valasz Jeri reszerol is ez volt: nem olyan sok extra plusz megcsinalni ezt, ha mar az erdeti emulacio ugy is megvan, akkor miert ne?

Quote
1; Először is nem lenne senki, aki írna új játékokat, amelyek kihasználnák.
2; Ha lenne is, akkor se lesz mindenki gépe átalakítva ehhez az újdonsághoz.
3; A régi játékok "tuning"-olásának sincs értelme.

Magyaran, nincs ertelme semmi de semmi ujnak. Ertem en, hogy valaki igy latja, en nem :) Szamomra a "8 bit kerdese" nem annyi, hogy nosztalgia, eljuk ujra a multat, pont ugy ahogy volt (kvazi idoutazas), hanem: az uj korban hasznaljuk fel, az uj technikakba integraljuk bele, azaz ne (csak) mint muzeumi targyat kezeljuk, hanem probaljuk megmutatni, hogy modern kornyezetben is jo hobby, pl ethernet illesztes, stb stb. Ezen tovabb haladva: ha megszunt az eredeti CBM ceg (Commodore Business Machines), vagy a Sinlair Ltd stb (marmint abban az ertelemben ahogy anno volt, tudom most is van valami Sinclair nevu ceg), akkor en akkor latom "elonek" a 8 bit scene-t, ha az fejlodik, mintja az azt taplalo cegek meg mindig kiadnak az ujabb es ujabb hw-ket. Mivel ilyen nem tortenik (a C64DTV hatareset - bar sok szempontbol tekintheto egy "hivatalos" uj C64-nek is), ezt magunknak kell elvegezni. Ha ilyen nincs, akkor viszont ez csak a regi idok visszaidezese a jelennel valo kapcsolat nelkul. Na en igy fogom fel, de ismetlem: ez az EN velemenyem, nyilvan nem kotelelzo vele egyet erteni :) Sw oldalrol is: uj OS irasa, tcp/ip networking stb.

Quote
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bővítés, de az is minek, mikor egyetlen egy program se kérdezi le.

Ez nem igaz. Meg a C64-nak is van ugymond belso oraja, mashol is lehet, ha maskepp nem, hat software-esen. Ez anno is letezett. Amiben jo lehet egy realm-time ora: kepes ezt beallitani, hogy nullarol induljon minden bekapcsolaskor. Ez imho mar egy ertelmes cel, ha mast valaki nem is lat bele :)


Quote
A témához kapcsolódóan idézet egy korábbi hozzászólásból (talán itt lesz a helye Zozo):

"Idézném a Speccyalista napon elhangzott beszélgetés részletét:

 PGyuri: Mire tervezték az EP-t?
 Moldani: A világ legjobb számítógépét akarták megcsinálni!"

Nos ez egyértelműen nem sikerült, mert ha azt szerették volna, akkor egyrészt a SPRITE fogalmát nem hagyták volna ki (mondjuk tervez(het)ték hozzá), de a leglényegesebb elemet akkor se felejthették volna el, mégpedig a gyors horizontális scroll lehetőségét !

Ez azert kisse radikalis :) Nyilvan soha nem lehet tokeleteset alkotni. Meg ha vegtelen penz/ido lenne ra, akkor sem. Hat meg ha az eroforrasok nem vegtelenek! Az EP viszonylagosan nem tul nagy nepszerusege annak "koszonheto", hogy tul sokaig keszult a bejelentes es eredeti tervekhez kepest, anno tenyleg durvan hangzott, mire megjelent, akkor sem volt rossz, de megis tul sok ido telt el. Nyilvan huzhattak volna meg tovabb, hogy meg tobb dolgot pakoljanak bele, de meddig? Mar igy is keso volt. Plusz sprite: akartam irni, de latom Zozo megelozott: erre gondoltak, a kezdemenye ugymond benne is van, az EXTCOL dolgok. Ha jol tudom (Zozo imho jobban tudja, majd kijavit, ha nem): ez pont azert keszult, hogy akkor legalabb kesobb lehessen hozza "kivulrol" ilyet lleszteni, ha mar bele nem kerulhetett. Azaz ebbol - szerintem - az kovetkezik, hogy igenis gondoltak ra, csak nem maradt ra ido (?), penz (?), de azt, hogy ezt belepakoltak meg, mutatja, hogy meg akartak hagyni a lehetoseget, hogy utolag legalabb konnyen illeszheto legyen.

Masreszt: azt hogy talalsz egy, ketto, par problemat: igen. Tokeletes dolog nincs, ilyen elven mondj egy dolgot a vilagon, ahol sikerult barmibol a tokeleteset megalkotni :) Imho nincs ilyen, a vilag tokeletlen. Mindenhol van egy kis folt, problema, stb. Meg ha az almok szepek is.

Ne azt nezd, hogy nem sikerult elerni - az amugy is lehetetlen - celt, hogy legyen tokeletes. Hanem azt, hogy mit sikerult elerni, osszehasolitva a hasonlo ar/celkozonseg/stb kategoriaba eso gepekhez kepest. Nos igen, itt csorbul kicsit a dolog, hogy tul sokaig "jott kifele" az uj gep. Meg igy sem rossz azonban szerintem! osszehasonlitas alatt meg teljesitmenyt, tudast, feature-oket, bovithetoseget stb ertek konkretan.

Quote
Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették. Spectrumon sokat gondolkoztam, hogy ottani hardver mestereinket meggyőzöm egy interface készítésével, amely képes a scroll műveletét elvégezni a processzor helyett, de mindig arra jutottam, hogy úgyse lenne rá program, így felesleges még a gondolatával is foglalkozni.

Ertem en a fajdalmadat a horizontalis scroll kapcsan, de imho ez egy igen egyszeru dolog. Nem hinnem, hogy azert hagytak ki, mert ezt annyira nehez lehetett volna megoldani. Talan ido nem volt ra, nem gondoltak bele, stb; az ember nem tokeletes. Ez kisse mas, mint a sprite: imho azt nehezebb megoldani, ott mar konkretan penz/anyag/ido problema sokkal jobban jelentkezhet.
Title: Re: NICK
Post by: Zozosoft on 2012.February.10. 20:50:57
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bõvítés, de az is minek, mikor egyetlen egy program se kérdezi le.
Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.
Title: Re: NICK
Post by: lgb on 2012.February.10. 21:03:00
Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.

Jah, C64-nel pl az IDEDOS stb eseten pont ugyanigy hasznos az ilyen feature. :) Persze, ha valaki csak arra hasznalja, hogy "megnezhetem mennyi az ido", akkor sok ertelme nincs. De akkor PC-n sem, ilyen elven: ott is megnezhetne az ember karorajan/mobiljan stb :)
Title: Re: NICK
Post by: Tuby128 on 2012.February.10. 21:45:38
Az lenne a kérdésem, hogy a sorparamétertáblában "64-es karakterkészlet" mód használata esetén a Nick mely karakterkódtól meddig jelenít meg a képernyõn információt?
Az IS-basic ezt használja egyébként?
Title: Re: NICK
Post by: IstvanV on 2012.February.11. 00:08:36
Az lenne a kérdésem, hogy a sorparamétertáblában "64-es karakterkészlet" mód használata esetén a Nick mely karakterkódtól meddig jelenít meg a képernyõn információt?

A 64 és 128 karakteres módok figyelmen kívül hagyják a karakter kód felső 2 vagy 1 bitjét, tehát a karakterkészlet "ismétlődik".
Azonban az ALTIND0 és ALTDIN1 biteknek nincs ilyen hatása, ezért lehetséges 256 karakteres 4 színű módban, hogy a 0-63 és 128-191, illetve 64-127 és 192-255 karakterek más palettát használjanak.

Quote
Az IS-basic ezt használja egyébként?

Az IS-BASIC 128 karakteres módot használ, 2x2 színű palettával (ALTIND1).
Title: Re: NICK
Post by: Tuby128 on 2012.February.13. 05:07:59
Készítettem egy NICK specifikációt a lábkiosztással. Még hiányos.
Title: Re: NICK
Post by: geco on 2012.February.13. 09:41:20

Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi).
Pgyuri


A 4 pixeles scroll még megoldható gyorsan, minden sorra külön LPT-vel, új nick ezen is javítana :)
Title: Re: NICK
Post by: IstvanV on 2012.February.13. 09:57:14
Megoldható úgy is, hogy nincs külön LPB minden sorhoz, bár így talán valamivel nehezebb. 16 színű módban lehetséges a pixel (1/4 karakter) felbontású scrollozás, de két képernyőt kell tárolni a memóriában, és a belépő pixel byte oszlopot mindkettőre rá kell rajzolni (az egyikre 1 pixel eltolással) - ez viszonylag bonyolult és lassú, de legalább nem kell az egész képernyőt mozgatni, amihez a 4 MHz-es Z80 nem elég gyors.
Title: Re: NICK
Post by: Tuby128 on 2012.February.13. 10:06:52
Használja valamire az 50Hz-es videomegszakítást az IS-BASIC vagy EXOS?
Title: Re: NICK
Post by: Zozosoft on 2012.February.13. 14:31:28
Használja valamire az 50Hz-es videomegszakítást az IS-BASIC vagy EXOS?
Pl abban történik a billentyûzet olvasás. Amúgy kb a programok 99% is ezt a megszakítást használja.
Title: Re: NICK
Post by: Tuby128 on 2012.February.13. 15:27:23
Tehát ha az LPT minden második sorában kiváltok egy videomegszakítást, akkor lesz minimum 600Hz-es a videomegszakítás. Nyilván az EXOS át fogja írni a módokat, de ha mondjuk visszaírom, akkor gyosabban fog villogni a kurzor?

 Most tényleg, pontosan milyen feladatokat lát el az 50Hz-es megszakítás? Az 1Hz-es megszakítás ettõl független, mert kipróbáltam, és az óra ugyanúgy járt.
Title: Re: NICK
Post by: Ferro73 on 2012.February.13. 16:52:06
Tehát ha az LPT minden második sorában kiváltok egy videomegszakítást, akkor lesz minimum 600Hz-es a videomegszakítás. Nyilván az EXOS át fogja írni a módokat, de ha mondjuk visszaírom, akkor gyosabban fog villogni a kurzor?

 Most tényleg, pontosan milyen feladatokat lát el az 50Hz-es megszakítás? Az 1Hz-es megszakítás ettõl független, mert kipróbáltam, és az óra ugyanúgy járt.

Lesz az több is mint 600Hz csak nem folyamatos "01010101010000000...00000001010101...01010101000000"
Az LPT szinkron soroknál nem tudsz szimetrikus megszakítást produkálni.
Az 50Hz a  Keyboard: a Basic Wait x vagy Halt x,  Sound, Get A$ utasítás és még más.
Title: Re: NICK
Post by: Zozosoft on 2012.February.15. 19:22:31
Most tényleg, pontosan milyen feladatokat lát el az 50Hz-es megszakítás?
Abban frissitgeti az az LPT-t a videókezelõ, abban megy a billentyûzet lekérdezés.
Valamint ezt használják CPU független idõzítésre a játékok. CPC programok esetén elõfordul 300Hz (azaz egy képen több videó megszakítás is).
 
Title: Re: NICK
Post by: Z80System on 2012.March.06. 16:51:50
most akkor hogy is allunk ilyen szervatultetesileg ? meg mindig nincs senki, aki negykilences biztonsaggal lenne kepes nick/dave atultetesre ?
Title: Re: NICK
Post by: Tuby128 on 2012.March.06. 16:54:52
Én meg tudom csinálni. Két évig forrasztottam labda-lábú ic-ket (több száz lába volt). Ez a néhány láb nagyon könnyen megvan. Kulcsszó: Tatabánya

Labdalábú alatt ezt értem:
(http://www.pclaunches.com/entry_images/0910/08/samsung_orion-dual-core-mobile-processor-thumb-450x337.jpg)
Title: Re: NICK
Post by: Z80System on 2012.March.06. 17:01:44
na a tatabanyat azt vegkepp nem ertem, a labdalabut meg megtalaltam (Ball Grid Array), ha ez az,

de azert hogy a nicknek csak par laba lenne... hat azert az sem keves, raadasul barmikor eleghet, elhajolhat, osszeerhet, vagy epp le lehet ragasztva a tokozas... ezek neked mind smafu, es meg tudod csinalni, kvazi kockazatmentesen ?

mert egy rossz alaplappal lehet kiserletezni, de ket jo nick- u alaplapon keresztbe cserelni a nickeket ugy, hogy nem vagyunk 99.99% biztosak a skerben, azert az doreseg volna...
Title: Re: NICK
Post by: Z80System on 2012.March.06. 17:03:41
Valahol az hogy ilyen kiallo labu nehezebbe teheti mint ezt a labdalabut, nem ?
Title: Re: NICK
Post by: Tuby128 on 2012.March.06. 17:18:14
A technika amit használok szavatolja, hogy nem hajlanak meg a lábak, pláne nem égnek el. Gyönyörû forrasztás az eredmény.

Itt egy IC (lásd csatolt kép) amit egy winchester panelról szedtem le, és forrasztottam rá az általam készített panelra.

Az IC egy SRAM IC és kifogástalanul mûködik a transzplantáció után is. Hozzáteszem nem ez az egyetlen munkám, csak most ez volt kéznél.

(Tatabánya a hely, ahol ezt csinálom. Tudod itt lakom.)

Azért van a képen 5Ft-os, mert az 1FT-ost bevonta a nemzeti bank.
Title: Re: NICK
Post by: Z80System on 2012.March.06. 17:23:11
Zozo, arrol van info, hogy a nick le van- e ragasztva az alaplapra ?

Vagy arra is van valami magiad, Tuby128 ?
Title: Re: NICK
Post by: Tuby128 on 2012.March.06. 17:34:15
Nincs leragasztva. Nincs olyan HW gyártó aki leragasztana egy IC-t. Tudod milyen drága az ipari ragasztó? De azt sem kell gondolom ecsetelni, hogy a késõbbi szervizelést mennyire megnehezítette volna, ha az alátöltött (ez a hivatalos neve a ragasztásnak) alkatrészt cserélni kell.
Ha nincs rá égetõ oka egy gyártónak, akkor nem tesz bele plusz költséget.
 (Amikor Nokia 3210-es telefonokat kezdték gyártani, a processzor olyannyira felmelegedhetett a használat során, hogy erõsebb rázkódás hatására elengedte a forrasztás, és többet nem kapcsolt be. Na ott úgy döntöttek /A töréstesztek után!!!/ hogy elkezdik alátölteni a processzorokat)
Title: Re: NICK
Post by: Z80System on 2012.March.06. 17:40:04
hmmm... hat igy laikuskent logikusan hangzik amit mondasz, csak valamiert en ugy emlexem, hogy ez a leragasztas dolog mar elojott a temaban ... siman lehet hogy a hutolemez ragasztasara emlekszem csak, ami akadalyoz es le kell torni ha epp eros es nem magatol esik le, de maga az ic is remlik valamiert.

amig cafolata nem erkezik fogadjuk el ezt alapnak. akkor viszont elvileg semmi akadalya nincs a keresztbe cserelesnek. valamikor majd meg kene ejteni egy ilyet, a pixelhibassag vegso bizonyitekakent.
Title: Re: NICK
Post by: Tuby128 on 2012.March.06. 17:51:12
NEM LETÖRNI a lemezt! Kicsit megmelegíteni, akkor elengedi. Persze nem barbár módon, szigorúan 200 Celsiuson csak néhány másodpercig.

Alátöltésnél említettm a 3210-est. Mivel az egyik kedvenc telefonom volt, pont van itthon egy panel. Csináltam egy képet. A "MAD" feliratú alkatrész a processzor. Itt a képen sajnos nem tudtam olyan jól megmutatni, de bizonyos szögbõl látszódik, hogy az IC szélein valami fénylik a panel és az alkatrész között. Nos ez az alátöltõ anyag. Ezt nem lehet cserélni, ha megdöglött, akkor az egész panel megy a zúzdába. Voltak próbálkozások a cseréjére, de felszedéskor a ragasztó feltépi a PAD-eket, és akkor nincs tovább.
Title: Re: NICK
Post by: Zozosoft on 2012.March.06. 20:52:16
Az IC egy SRAM IC és kifogástalanul mûködik a transzplantáció után is. Hozzáteszem nem ez az egyetlen munkám, csak most ez volt kéznél.
Ezért most õszintén szívbõl irigyellek!
Title: Re: NICK
Post by: Zozosoft on 2012.March.06. 20:56:19
Nincs leragasztva. Nincs olyan HW gyártó aki leragasztana egy IC-t. Tudod milyen drága az ipari ragasztó? De azt sem kell gondolom ecsetelni, hogy a késõbbi szervizelést mennyire megnehezítette volna, ha az alátöltött (ez a hivatalos neve a ragasztásnak) alkatrészt cserélni kell.
Szerintem te nagyon mostani technikákban gondolkodsz  :oops:
Én nem szedtem le Nick-et, ami hozzám keveredett leszedett IC, annak az alján kétrétegû ragasztószalagnak tûnõ cucc van.
Mészáros Gyulát kéne faggatni, õ elvileg szedett már le ilyeneket.
Title: Re: NICK
Post by: Z80System on 2012.March.07. 08:08:27
Zozo, ha en allnam a postakoltseget ( ha kell vissza az alaplap, akkor vissza is ), akkor nem postaznal el Tuby128- nak egy rossz alaplapot, hogy megnezze hogy ragasztott- e vagy sem ? ( Termeszetesen csak ha Tuby128 is vevo a dologra ... ) En meg atutalom a postakoccseget.
Title: Re: NICK
Post by: Tuby128 on 2012.March.07. 09:10:36
Ha kétrétegû a ragasztó, akkor semmi baj, mert a melegtõl (150-200 Cels.) el fog engedni, semmi probléma nincs vele. Olyan mintha nem is lenne.
Akkor kellene félni, ha hõre keményedõ ragasztó lenne rajta (tipikusan fekete vagy piros, és folyós állagú) azt fecskendezik az IC köré, és a melegtõl befolyik az IC alá és ott keményedik (és fekedetik).
Title: Re: NICK
Post by: Tuby128 on 2012.March.07. 09:11:38
Ezért most õszintén szívbõl irigyellek!

Nem kell irigyelni. Ha kell felajánlom a segítségemet neked.
Title: Re: NICK
Post by: Tuby128 on 2012.December.04. 21:42:16
Világosbarnák szoktak lenni az ilyen játékok: R=2*G B=0 ahol R<=4 (a 0..7-es skálán)
Mondjuk legyen 4-2-0 akkor binárisan:
R:100
G:010
B:00
És mivel EP-nél a színek (g2)-(r2)-(b1)-(g1)-(r1)-(b0)-(g0)-(r0) (ahol a 0 a legnagyobb színerősség)
Akkor így 00010001 (bin) ami 11 (hex) ami 17 (dec)
Title: Re: NICK
Post by: Lacika on 2012.December.04. 21:57:34
Quote from: Tuby128
Akkor így 00111111 (bin) ami 3F (hex)
Az teljesen világosszürke.
Title: Re: NICK
Post by: Zozosoft on 2012.December.04. 22:07:14
Quote from: Tuby128
És mivel EP-nél a színek (g2)-(r2)-(b1)-(g1)-(r1)-(b0)-(g0)-(r0) (ahol a 0 a legnagyobb színerősség)

Helyesen:


 As described above, the Nick Chip generates a colour byte for each point on the screen, depencing on the video mode, colour mode, palette registers and so on. The 8­bits of this colour value are converted into separate red, green and blue signals which are available on the monitor connector, and are also converted into a PAL encoded, UHF modulated signal which can be fed directly into a television.
 
 Of the eight bits, there are three each for red and green and two bits for blue, thus allowing eight levels of red and green and four levels of blue. The layout of bits is:
  b7 b6 b5 b4 b3 b2 b1 b0
 g0 r0 b0 g1 r1 b1 g2 r2
 The three bits for each colour are combined according to the formulas below. b0, g0 and r0 are the most significant bits of each colour, and the weighting for the blue levels takes into account teh fact that there are only four levels of blue.
 total RED = ( r2 * 4 + r1 * 2 + r0 ) / 7
 total GREEN = ( g2 * 4 + g1 * 2 + g0 ) / 7
 total BLUE = ( b1 * 2 + b0 ) / 3
Title: Re: NICK
Post by: Tuby128 on 2012.December.04. 22:24:59
Látom Zozo ma angolos kedvedben vagy, álljon itt hát a fordítás:

" A Nick chip a képernyő összes pontjához egy színbyte-ot generál a video, szín mód és a palettaregiszterek értékeitől függően. Ezen 8 bites színértékek külön piros, zöld, és kék jelekre konvertálódnak, amelyek a monitor csatlakozón érhetőek el. Innen a PAL átalakítón keresztül az UHF modulátorra jutnak, hogy a TV számára alkalmas jel legyen belőlük.

 A 8 bitből 3-3 a piros és zöld, kettő pedig a kék színt határozza meg, így a piros és zöld 8, a kék pedig 4 árnyalatú lehet (G=zöld, R=piros, B=kék)
/szerk. megjegyzése: Azért a kék a kevesebb mert állítólag arra a legérzéketlenebb az emberi szem/
  b7 b6 b5 b4 b3 b2 b1 b0
 g0 r0 b0 g1 r1 b1 g2 r2  / szerk: ez furcsa az én könyvemben fordítva van ZOZO ez biztos jó amit linkeltél? /

A három bit az alábbi képlet szerint alkotja a színeket. B0, G0, R0 a legértékesebb (legfényesebb) bitje minden színnek, a kék színnek pedig csak négy szintje van.
 egyszínű Piros = ( r2 * 4 + r1 * 2 + r0 ) / 7
 egyszínű Zöld = ( g2 * 4 + g1 * 2 + g0 ) / 7
 egyszínű Kék = ( b1 * 2 + b0 ) / 3
"
 
Title: Re: NICK
Post by: Tuby128 on 2012.December.04. 22:30:14
Valami nem jó ebben a leírásban, mert ha beírom, hogy
SET BORDER 64
Akkor sötétebb pirosat kapok mint
SET BORDER 1
Esetén

Meg is van át kell írni ezt:
"b0, g0 and r0 are the most significant bits of each colour, ..."
erre:
"b0, g0 and r0 are the LEAST significant bits of each colour, ..."
Title: Re: NICK
Post by: Zozosoft on 2012.December.04. 22:44:41
Quote from: Tuby128
Látom Zozo ma angolos kedvedben vagy
Nem, csak az angol EXOS leírás szokott használható lenni, mivel a magyar tele van nyomdahibákkal és félrefordításokkal :-(
Title: Re: NICK
Post by: Tuby128 on 2012.December.04. 22:52:08
Nekem úgy tűnik, hogy most az angol EXOS leírás a hibás, és a magyarban azért volt fordítva, a bitek számozása, mert a fordító észrevette és kompenzálta. Így akkor így igaz lesz az állítás, hogy a 0-val jelzett a legnagyobb helyiértékű bit.
Más kérdés, hogy általában a 0 a legkisebb helyiértékű bit. (Fordítva ült a bilire)
Title: Re: NICK
Post by: Zozosoft on 2012.December.04. 23:06:30
Quote from: Tuby128
Nekem úgy tűnik, hogy most az angol EXOS leírás a hibás
Kiderült nem a leírás a hibás, hanem az angolok által az ősidőkben elkészített html verzióban lett hibás a képlet, valószínűleg úgy gondolta hibás a leírt képlet, mert nem a 0-ás bit szokott nagyobb értékű lenni.
Itt a 11. oldalon látható a jó képlet. (http://enterprise.iko.hu/technical/ET1-3_Nick_Chip_Programmers_Guide.pdf)
Title: Re: NICK
Post by: Tuby128 on 2012.December.04. 23:13:02
Akkor most erre is fény derült. Jól tetted, hogy nem hagytad rám a színekkel való eszmefuttatás dolgot, és bemásoltad az angol szöveget!
 Már csak át kellene helyezni ezt a néhány hozzászólást a megfelelő NICK-es témába.
Title: Re: NICK
Post by: Zozosoft on 2013.May.16. 13:04:49
Elkezdtem nézegetni hogyan működik a videó memória elérése, Nick - Z80 megosztása.

Elsőként vegyük szemügyre ezen terület kapcsolási rajzát. (http://enterprise.iko.hu/schematics/EP64-1-RT.jpg) Mint látható a Nick eleve közvetlenül a dinamikus memória IC-k vezérlésére lett tervezve, önnállóan állítja elő a szükséges RAS, CAS jeleket, valamint a multiplexereket vezérlő MUX jelet is.
Összehasonlításként itt a belső 64K bővítő rajza (http://enterprise.iko.hu/schematics/EP128INTERNALRAMEXPANSION~1.jpg), amelyen látható a DRAM-ok Z80-hoz illesztéséhez további plusz áramkörök kellenek, amik előállítják az emlitett RAS, CAS, MUX jeleket. (Z80-hoz EPROM vagy SRAM illeszthető közvetlenül.)
Amikor a Z80 éri el a videó memóriát, akkor szintén a Nick végzi ezeknek a jeleknek előállítását.

Alapból a Z80-as cím és adatbusz el van szigetelve a Nick és videómemóriák által használt cím és adatbusztól.
Az alaplapon U5, U6, U7 jelű IC-k végzik ezt a feladatot, a főnök pedig a Nick: az ACCESS nevű jellel tud engedélyt adni arra, hogy a Z80-as busz kapcsolódjon a videó buszhoz.
Erre nem csak a videómemória eléréséhez van szükség, hanem a Nick regisztereinek írásakor is.
A dologban jelentős része van még Davenek is, ő dekódolja az egész alaplap számára a címeket, így ő veszi észre, hogy a Z80 valami olyat akar csinálni, amihez a Nicknek is köze van, ezt a VRAM és VIO jelekkel jelzi: "Hé, Nick szomszéd! Ez a Z80 gyerek akar valamit tőled!" :-D
Erre a Nick nagy valószínűséggel azt mondja: "Várjon egy kicsit, most nem érek rá!" Mivel a Nick az erősebb, a Z80 várni fog :-) Gyakorlatban ez úgy néz ki, hogy a rendszer órajelből, ami a Nick 61-es lábára érkezik, a Nick állítja elő a kettővel osztott CPU órajelet a 64-es lábon (alapgépen 8Mhz a rendszer, 4Mhz a CPU órajel). Amikor azt mondja a Z80-nak, hogy várjon egy kicsit, akkor egész egyszerűen nem ad neki órajelet.
Majd amikor már ráér, akkor elsőként "kinyitja a kaput" az ACCESS jellel, hogy a Z80-as cím és adat busz összekapcsolódjon a videó busszal, majd generálja a szükséges RAS/CAS/MUX jeleket a videómemória részére, és végül engedi a Z80-nak, hogy elvégezze a kívánt műveletet.

Következő fejezetben megnézzük mindezt oszcilloszkópos méréseken, hogyan is néz ki a gyakorlatban.
Title: Re: NICK
Post by: Zozosoft on 2013.May.16. 14:05:01
Elsőként lássuk mit csinál a NICK amikor háborítatlanul dolgozik (piros a RAS, sárga a CAS):
[attachimg=1]
Szépen látszik, hogy 2 bájtot beolvas, majd szabadon hagyja a videómemóriát. Gondolom többen sejtik már, hogy ezekbe a szabad lukakba van a Z80-nak esélye hozzáférni a videómemóriához :-)

Első tesztként kinullázva a videómemóriát, NOP-okat hajt végre a CPU, normál 4Mhz-en.
[attachimg=2]
Látható, hogy lassú a proci, minden második luk szabadon marad.

6Mhz-en már minden lehetőséget kihasznál:
[attachimg=3]

Jöjjön egy bonyolultabb feladat:
Code: [Select]
ld hl,4000h
f31 ld (hl),a
jr f31

4Mhz-en egy programciklusban 4 kihasználatlan lehetőség marad:
[attachimg=4]

6Mhz-en már csak 3:
[attachimg=5]

8Mhz-en már csak 2:
[attachimg=6]
Title: Re: NICK
Post by: Zozosoft on 2013.May.16. 16:43:41
Hogyan működik a DRAM címzés?
-ki kell tenni a címbuszra a címet, a memóriákat címző multiplexereket RAS-ra kapcsolni
-kis várakozás után, amikor már biztos, hogy a memóriák címbuszán a RAS cím van ott, mehet a jelzés a RAS vezeték alacsonyra állításával
-várni kell, amíg a memória elraktározza a RAS címet (ennek idejét RAS to CAS delay-nak nevezik a memóriák adatlapján)
-multiplexereket CAS-ra kapcsolni
-kis várakozás után, amikor már biztos, hogy a memóriák címbuszán a CAS cím van ott, mehet a jelzés a CAS vezeték alacsonyra állításával
-várni kell míg a memória készen áll a művelet elvégzésére (access time from CAS néven nevezik)
(Az IC-ken feltüntetett elérési idő az "acces time from RAS", ami lényegében a "RAS to CAS delay" és "acces time from CAS" összege)

Kinagyítva így néz ki a Nick RAS-CAS jelei, jól láthatóan a CAS kicsit később lesz aktív, majd a művelet végén egyszerre kapcsolnak ki:
[attachimg=1]

Itt a MUX jel is, ami ugyanolyan hosszú mint a RAS, csak kicsit el van tolva:
[attachimg=2]

Az időzítésekhez célszerű megnézni a Nick órajelhez való viszonyukat. Az órajelről István kiderítette (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg16964/#msg16964), hogy 14237536.2676056338 Hz, egy órajelciklus tehát 70,236... ns.

Nick órajel és RAS:
[attachimg=3]

Nick órajel és CAS:
[attachimg=4]

Nick órajel és MUX:
[attachimg=5]

Összefoglalva: egy Nick slot 16 órajelből áll. (Mint a Nick leírásból tudjuk egy sorban 57 slot van, abból az első 8 alatt olvassa az LPT-t, 46 a képernyő adat, maradék 3 meg memória frissítés)
3 hosszú a RAS (első bájt beolvasása) tehát kb 210 ns-os memória eléréssel dolgozik a Nick.
2 "pihenő"
3 hosszú a RAS (második bájt beolvasása)
ezután 8 pihenő, majd ebbe jön be a Z80 elérése, majd látni fogjuk, hogy ennek az időnek az első 2 és utolsó 2 ciklusnyi ideje is pihenő, azaz két videó RAM hozzáférés között mindig 2 Nick órajelnyi pihenő van.
A CAS 1 órajellel később követi a RAS-t, és 2 hosszú.
A MUX 0.5 órajellel eltolva követi a RAS-t. Azaz félórajelnyi belenyúl a pihenőbe. Ezután a maradék félórajelnyi lehet a tényleges pihenő, a következő órajelben mehet ki az új cím a címbuszra.
Tehát így nézhet ki:
1. ciklusban kimegy a cím
2. ciklus kezdetén aktív lesz a RAS
2.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
3 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
5 ciklusnál kikapcsol a RAS és CAS
5.5 ciklusnál kikapcsol a MUX
6 ciklusban kimegy a cím
7. ciklus kezdetén aktív lesz a RAS
7.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
8 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
10 ciklusnál kikapcsol a RAS és CAS
10.5 ciklusnál kikapcsol a MUX

Itt jön a Z80 ideje:
[attachimg=6]
Látható, hogy a hozzáférés ugyan az, csak 1 Nick órajelnyivel hosszabb.
Folytatva ez előbbit:
1. ciklusban kimegy a cím
2. ciklus kezdetén aktív lesz a RAS
2.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
3 ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
5 ciklusnál kikapcsol a RAS és CAS
5.5 ciklusnál kikapcsol a MUX
6. ciklusban kimegy a cím
7. ciklus kezdetén aktív lesz a RAS
7.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
8. ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
10 ciklusnál kikapcsol a RAS és CAS
10.5 ciklusnál kikapcsol a MUX
11. ciklusban kimegy a Z80-as cím
11.5 ciklusnál azaz kb 35 ns-al késöbb aktív lesz a MUX
12. ciklus kezdetén azaz újabb 35 ns-al késöbb aktív lesz a CAS
15 ciklusnál kikapcsol a RAS és CAS
15.5 ciklusnál kikapcsol a MUX
Title: Re: NICK
Post by: Zozosoft on 2013.June.11. 21:38:37
A frissen szerzett vadi új Nick:
[attach=1]
[attach=2]
Title: Re: NICK
Post by: dolargaan on 2013.June.11. 21:54:54
Szép. :) Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.
Title: Re: NICK
Post by: Zozosoft on 2013.June.12. 09:08:34
Quote from: dolargaan
Szép. :) Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.
Pontosan :-)
Kár, hogy nem volt belőle még pár darab... meg Dave is jöhetne néhány.
Title: Re: NICK
Post by: Zozosoft on 2013.August.16. 12:00:58
Quote from: lgb
Pl talan a scroll demo volt ilyen amit epp neztem, a debug ablak azzal van teli, hogy: "Reading undecoded port 0x82". Ez mondjuk erdekes, elvileg - tudtommal - nick registerek nem visszaolvashatoak, tehat a scroll demo nem tudom miert akarja azt a portot olvasni, van otletetek, hogy ezzel mit akar elerni?
Na ez egy jó kérdés, eddig én is úgy tudtam felesleges olvasgatni a Nick portjait :oops:

István viszont tudhat valami trükköt, az ep128emuban ez van:
Code: [Select]
 uint8_t Nick::readPort(uint16_t portNum)
  {
    (void) portNum;
    return dataBusState;
  }

A kérdéses helyen azt látom, hogy C0h-t olvas a Scroll Demo (ep128emuban), amiből valami várakozási értéket generál:
Code: [Select]
 1189  DB 82        IN    A, (82)
 *118B  E6 07        AND   07
  118D  3C           INC   A
  118E  47           LD    B, A
  118F  10 FE        DJNZ  118F
Title: Re: NICK
Post by: Z80System on 2013.August.16. 12:06:11
Vagy csak a Laci ( scroll demo szerzoje ) epp reszeg volt ... meg kell tole kerdezni.
Title: Re: NICK
Post by: endi on 2013.August.16. 12:14:10
ezeket ki kell deríteni addig amíg még van működöképes EP a világegyetemben, mert utána már nem tudhatjuk meg :)
Title: Re: NICK
Post by: IstvanV on 2013.August.16. 13:00:29
A NICK portjainak (80h-8Fh) az olvasása azt a byte-ot adja vissza, ami az adatbuszon maradt, azaz amit a NICK utoljára olvasott a memóriából (ezt az ep128emu nem emulálja) vagy a NICK I/O portokra utoljára írt értéket.

Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.
Title: Re: NICK
Post by: endi on 2013.August.16. 13:19:37
Quote from: IstvanV
Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.
hm hm... ez érdekes...
Title: Re: NICK
Post by: IstvanV on 2013.August.16. 13:26:07
Soron belül változó keretszín vagy BIAS pontos időzítéséhez például hasznos lehet.
Title: Re: NICK
Post by: endi on 2013.August.16. 13:34:36
Quote from: IstvanV
Soron belül változó keretszín vagy BIAS pontos időzítéséhez például hasznos lehet.
Egyik demómban csináltam ilyet, de persze nem ezzel az időzítéssel, mert nem is tudtam róla akkor. :)
De amúgy még nem biztos hogy ez jó lehet. Ugyanis a Z80 sebességével sajnos soronként kb 20x lehet megváltoztatni a bordert vagy a biast (vagy 30? nem emlékszem), és ez olyan kevés hogy "ugrálhat" akkor is ha ilyen időzítést használ.
Mindenesetre jó lenne kipróbálni.
Amúgy az Ork megademo 2-ben volt ez az effekt, a biast állítottam így, emuból kép (persze rossz):
Title: Re: NICK
Post by: endi on 2013.August.16. 13:37:35
hülyeséget írtam, lehet hogy csak 10x lehet
Title: Re: NICK
Post by: lgb on 2013.August.16. 15:08:44
Quote from: IstvanV
A NICK portjainak (80h-8Fh) az olvasása azt a byte-ot adja vissza, ami az adatbuszon maradt, azaz amit a NICK utoljára olvasott a memóriából (ezt az ep128emu nem emulálja) vagy a NICK I/O portokra utoljára írt értéket.

Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.

En azt hittem, hogy minden "olvasasra nem dekodolt" portra igaz (pl ahol nincs is semmi, se olvasasra, se irasra), hogy az adatbusz allapotatol fugg, hogy a "semmi" olvasasa mi lesz, illetve az is befolyasolja, hogy milyen hw van a gepre dugva (pl az adatbuszra van-e fel-/lehuzo ellanallasok kapcsolva, stb). Vagy akkor ez itt kulon eset a nick-re ezek szerint egy kisse ...
Title: Re: NICK
Post by: Zozosoft on 2013.August.16. 15:30:45
Külön eset, mert a CPU és videó adatbuszt egy 74LS245 köti össze, ami ez esetben konkrét értéket ad ki, csak a bemenete nincs definiálva, hogy videó adatbuszon mi van ilyenkor, István tapasztalatai alapján az utolsó bájt lebeg még ott.
Más nem létező portoknál az egész CPU adatbusz lebeg (kivéve ha olyan kártya van a rendszerben amin van felhúzó ellenállás).
Title: Re: NICK
Post by: endi on 2013.August.16. 21:12:22
specy border trükk
elég finoman tudja pozicionálni, csak hát attól még elég széles a csík... van ilyen border scroll specyre, az is ilyen, csak arról nem találtam videót

http://www.youtube.com/watch?v=cwpn0GGCYp4
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 17:29:35
FIXBIAS scroll lebegő adatbusz olvasással időzítve:
[attachurl=#]
Csak 4 MHz-es valódi gépen működik. ep128emu-n ez a script javítja az időzítési hibát (így sem egészen pontos, mert igazi gépen nem karakterhatáron változik a szín, hanem egy 16 színű pixellel korábban):
[attachurl=#]
Title: Re: NICK
Post by: endi on 2013.August.29. 17:40:23
bár tudnám hogy kell azt a lua-t használni az emuban...
snapshot esetleg?
marha kíváncsi vagyok!!!
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 17:47:37
A debuggerben be kell tölteni és elindítani (a második lapon a jobb alsó sarokban "Load from file" és aztán "Run"). A snapshot file nem tartalmazhat Lua scriptet, így azzal nem lehetne javítani a hibát.
Title: Re: NICK
Post by: endi on 2013.August.29. 17:57:16
hát ez nagyon király!
ha jól látom kb 3 karakterenkét lehet váltani, de a scroll kb karakteres?
ezt is megértük!!! marha jó :)
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 17:58:20
Felvétel EP-ről:

[attachurl=#]
Title: Re: NICK
Post by: endi on 2013.August.29. 17:59:04
amúgy emut 10% speedre állítva szépen látszik hogy karakteres a mozgás
tök jó :)
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 18:04:33
Quote from: endi
ha jól látom kb 3 karakterenkét lehet váltani, de a scroll kb karakteres?
Igen. 3 karakter (~13.49 Z80 ciklus) a legrövidebb lehetséges időtartam két NICK I/O port írás között. Ez is csak "OUT (C), regiszter" utasításokkal lehetséges OUTI helyett, ezért a scroll csak 6 színű, és a "pixeleket" a kód felülírásával lehet módosítani. Az OUTI egyszerűbb lenne, de csak 4 karakteres felbontást tenne lehetővé.
Az időzítés valóban egy karakter felbontású, így a scroll vízszintes mozgatása is ilyen lépésekben lehetséges.
Title: Re: NICK
Post by: endi on 2013.August.29. 18:08:12
történelmi időket élünk :)
az a baj, hogy egyre kevesebb ilyen lehetőség lesz, és a végén nem marad semmi amit meg kéne valósítan :(
Title: Re: NICK
Post by: endi on 2013.August.29. 18:18:20
volt szó arról a portról ahol a vízszintes pozíciót lehet olvasni
ezt nem lehetne kiküldeni a borderre vagy a biasra?
ha már ennyire benne vagy :)
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 18:39:11
024Ch címre a debuggerben OUT (C), B helyett OUT (C), A-t írva a bal felső sarokban megjeleníthető a kiolvasott vízszintes pozíció változása. Lassítva látható, hogy a szín változik, azonban a program ennek megfelelően állítja be a várakozás mértékét, így stabil lesz a kép.

A program egyébként már kis mértékben "lassú" Z80 esetén sem működik megfelelően. :oops: Az emulátorban 3.989 MHz sebességet beállítva még jó a kép, de 3.988-nál már hibás. Nem tudom, valódi gépeken az alkatrészek véletlenszerű szóródása miatt előfordulhat-e probléma. A "gyors" Z80 kevésbé tűnik problémásnak, 4.1 MHz-nél még nincs hiba.
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 18:49:31
Quote from: IstvanV
024Ch címre a debuggerben OUT (C), B helyett OUT (C), A-t írva a bal felső sarokban megjeleníthető a kiolvasott vízszintes pozíció változása.
Illetve ez nem egészen jó, mert már tartalmazza a vízszintes scrollt is. A scroll azonban megállítható 052Ch címre INC L helyett NOP utasítást írva.
Title: Re: NICK
Post by: Zozosoft on 2013.August.29. 20:20:03
Quote from: IstvanV
FIXBIAS scroll lebegő adatbusz olvasással időzítve:
:smt038 :smt038 :smt038

Quote
Csak 4 MHz-es valódi gépen működik.
Gyorsabb géphez is lehetne időzíteni?

Quote
Nem tudom, valódi gépeken az alkatrészek véletlenszerű szóródása miatt előfordulhat-e probléma.
A rendszer órajel 3 tizedesig pontos kristállyal van generálva, itt nem is találtam nagy szórást szkóppal, ellentétben a Nick órajellel, aminek a generáló áramköre állítható alkatrészt is tartalmaz, itt van bőven eltérés. (Ezeket igyekszem is az általad kiszámolt elméleti órajelre belőni.) A Nick órajel eltérés befolyásolhatja a programot?
Title: Re: NICK
Post by: endi on 2013.August.29. 20:57:55
amúgy ebben az a tök jó, hogy "áttetsző" hatású
és ha még a 8 palettás színnel lenne "fölé" rajzolva, még lehetne fokozni a hatást :)
jó kis demó effekt ez :)
bár lehet hogy valami tök jó játékot is ki lehetne hozni belőle...
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 21:01:19
Quote from: Zozosoft
:smt038 :smt038 :smt038
Gyorsabb géphez is lehetne időzíteni?
Igen, de ahhoz természetesen módosítani kell a kódon (nem hordozható a különböző sebességű gépek között, esetleg a "szabványos" frekvenciákhoz külön meg lehetne írni, és futáskor automatikusan kiválasztani a megfelelő verziót). Viszont 7.12 MHz-es gépen lehetne 2 karakteres felbontás is 3 helyett.

Quote from: Zozosoft
A rendszer órajel 3 tizedesig pontos kristállyal van generálva, itt nem is találtam nagy szórást szkóppal, ellentétben a Nick órajellel, aminek a generáló áramköre állítható alkatrészt is tartalmaz, itt van bőven eltérés. (Ezeket igyekszem is az általad kiszámolt elméleti órajelre belőni.) A Nick órajel eltérés befolyásolhatja a programot?
A NICK és Z80 órajel aránya a lényeges, tehát bármelyiknek a jelentős pontatlansága probléma lehet. Azonban a NICK órajelének elvileg a PAL színsegédvivő kristály az alapja, aminek a szabvány szerint meglehetősen pontosnak kell lennie (talán +/- 50 ppm, de ebben nem vagyok biztos). Az állítható áramkör egy PLL, de ha annyira pontatlan, hogy nem is tud beállni a kristály által meghatározott frekvenciára, akkor lehet hibás a NICK frekvencia (ez képhibát is eredményezhet).
Title: Re: NICK
Post by: IstvanV on 2013.August.29. 21:10:42
Quote from: endi
és ha még a 8 palettás színnel lenne "fölé" rajzolva, még lehetne fokozni a hatást :)
Az OUT (C), C és az OUT (C), 0 utasításokat nem használja, ezért csak 6 színű a scroll. Az OUT (C), 0 használható lenne a fekete (azaz itt teljesen átlátszó) színhez, de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat). Az OUT (C), C is használható lenne fekete színhez, mert a C értéke 80h; ez azonban kikapcsolja a beépített hangszórót, ezért a többi színnél is be kell állítani a 7. bitet (a hangszóró kapcsolgatása zajt eredményez, még akkor is ha egyébként nem lenne hang). A C regiszter valójában lehetne 84h, 88h, vagy 8Ch is, ami további színeket tenne lehetővé.
Title: Re: NICK
Post by: Zozosoft on 2013.August.29. 21:29:07
Quote from: IstvanV
de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat).
CMOS procin FFh-t küld ki. (ezt használja az EXOS 2.4 is a proci típus detektálásra.)
Title: Re: NICK
Post by: endi on 2013.August.29. 21:47:39
Quote from: IstvanV
Az OUT (C), C és az OUT (C), 0 utasításokat nem használja, ezért csak 6 színű a scroll. Az OUT (C), 0 használható lenne a fekete (azaz itt teljesen átlátszó) színhez, de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat). Az OUT (C), C is használható lenne fekete színhez, mert a C értéke 80h; ez azonban kikapcsolja a beépített hangszórót, ezért a többi színnél is be kell állítani a 7. bitet (a hangszóró kapcsolgatása zajt eredményez, még akkor is ha egyébként nem lenne hang). A C regiszter valójában lehetne 84h, 88h, vagy 8Ch is, ami további színeket tenne lehetővé.
nem így értem, hanem úgy hogy olyan graf lenne alatta, ami palettaszíneket is tartalmaz, így azokon a bias trükk nem lenne rajta, azaz "felette" lennének, eltakarnák a scrollt (részben, pl fa ágak stb). látványos lenne, főleg ha az is animálna mondjuk (rasztercsíkok, hullámzás, akármi)
Title: Re: NICK
Post by: lgb on 2014.July.31. 17:21:26
Eszembe jutott egy kisse beteg otlet a Nick bovitese kapcsan, amihez nem kell uj Nick-et csinalni, es talan valamire jo lehetne az eredmeny. Ugye ha jol emlekszem, a Nick-bol kijon 8 bitnyi adat, ami a megfelelo Enterprise szin indexet hordozza, ebbol gondolom vmi D/A-val lesz konkret videojel szin informacio valahol. A kulcs viszont az, hogy akkor a Nick digitalisan adja ezt ki. Vegezzunk egy gondolatkiserletet! Vegyunk egy EPROM-ot,amibe egessuk be sorban a szamokat 0,1,2,..... Tehat elso korben csak 256 byte-ot hasznalunk fel. A nick kimenetet kossuk az EPROM cimbuszara. Az EPROM adatbuszat vigyuk tovabb a video aramkorok fele, az EPROM cimbuszanak felso bitjeit foldeljuk le. Az OE legyen aktiv, hogy mindig van kimenet. Ha jol tippelem, ezzel a bonyolitassal sikerul elerni, hogy semmi ne tortenjen :) Hiszen ugyanaz az adat jelenik meg az EPROM-bol ami cimkent belemegy.

Most jon a csavar. 256 byte-ot elhasznaltunk, ha van egy 64K-s EPROM-unk, akkor meg definialhatunk 255db palettat (most a paletta alatt nem a Nick LPB-ben levo palettat ertem, hanem a 256 fix EP szin kiosztasat, hogy melyik szam felel meg pl a feketnek stb, azaz ami 256 szinu modban is van) tetszes szeint, ahol megkeverhetjuk kisse a standard EP szinfelosztast. Az elobb a foldre kotott cimbusz vezetekeket kossuk egy latch-re, ami egy I/O porton at modosithato erteket szolgaltat. Igy elertuk, hogy programbol 256db kulonbozo kiosztasu palettat hasznalhatunk, ebbol a nulla (ez lenne a reset default a 0,1,... linearis azaz az EP default, ami reset utan  igy be is allna erre, tegyuk fel).

Szerintetek ez megoldhato-e, lenne barmi ertelme? Az mar kicsit advanced (es nehezebb megoldani) hogy EPROM helyett RAM, es minden szin tetszes szerint atvarialhato (akkor viszont inicializalni kene bekapcsolas utan kulonben fura dolog tortenne). Viszont az EPROM-os pelda nem tunik megoldhatatlannak (bar attol is fugg, eleg gyors-e ehhez egy EPROM egyaltalan).

Ez ugy jutott eszembe, hogy a FIXBIAS miatt van sok siras rivas, amde ha a palettaban maskent lennenek a szinek sorrendjei, akkor nagyobb lenne a valasztasi lehetoseg maris, hogy pl 16 szinu modban a felso 8 szin micsoda (bar a mapping jelen esetben eleg komplex, mivel minden EP szint erint, azt, hogy csak a felso 8 szint mappeljuk at, azt nem lehet megoldani "kivulrol" hiszen ahhoz olyan infok kellenek, amik csak a Nick "belsejeben" vannak meg).
Title: Re: NICK
Post by: Zozosoft on 2014.July.31. 17:26:29
Ilyesmin már én is gondolkoztam :-)
Title: Re: NICK
Post by: lgb on 2014.July.31. 17:34:28
Meg tovabb gondolva: ha sikerul "ellopni" a nick FIXBIAS portjara meno erteket (mi is dekodoljuk azt a partot magunknak) es eltaroljuk, akkor elvileg az is megoldhato, hogy a fentebb jelzett szin mappingolas csak akkor jojjon elo, ha a Nick altal kiadott szin informacio a FIXBIAS register altal adott ertek folot van egy 8-as tartomanyban (azaz ha a nick color kimenet felso 5 bitje azonos a FIXBIAS-ba irt ertekkel). Ekkor pl mondhatjuk, hogy csak akkor van mapping, es a 8 erteket kepzi le. Igy meg erdekesebb, habar max annyi baj van, hogy ez az aramkor nem tudhatja, hogy amugy a FIXBIAS van-e hasznalva eppen, vagy olyan videomod van ervenyben ahova nem kell, szoval valszeg azert nem art, ha programbol ki/be lehet kapcsolni (es persze komplex, tobb video modot hasznalno LPT eseten nem mukodne tul jol, hacsak megfelelo VINT-el nem avatkozunk be az adott scanline-nal pl).
Title: Re: NICK
Post by: lgb on 2014.July.31. 17:40:17
Quote from: Zozosoft
Ilyesmin már én is gondolkoztam :-)

Aaaa, pedig mar ugy orultem, hogy milyen okos vagyok :D
Title: Re: NICK
Post by: DrPrery on 2014.July.31. 18:41:17
Quote
Aaaa, pedig mar ugy orultem, hogy milyen okos vagyok (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Hát lehetsz is, nekem az elmélet első bekezdése után már némi füst kezdett el szállingózni a füleimből... :mrgreen: megyek IC-ket cserélni...
Amúgy ProfiEpSaurus-t (Zozo) nem könnyű lenyomni... :ds_icon_cheesygrin:
Title: Re: NICK
Post by: Zozosoft on 2014.July.31. 19:17:44
Quote from: DrPrery
Hát lehetsz is, nekem az elmélet első bekezdése után már némi füst kezdett el szállingózni a füleimből...
Pedig egyszerű!
Nézd a rajzot! (http://enterprise.iko.hu/schematics/EP64-3~1.jpg)
A Nick PC0-7 kimenetén jön ki egy bájtos adatként az aktuális szín. Ha ezt az egy bájtot felhasználjuk egy memória címzésére, akkor annak a 00-FFh rekeszei meg fognak felelni az EP 00-FFh színeinek, ha ezekbe a rekeszekbe eltérő tartalmat írunk, akkor lecseréltük a színeket. Ha a memória a 256 bájt többszöröse, akkor több különböző palettát is lehet tárolni.
Fizikailag meg el kell vágni a PC0-7 kimeneteket és oda bekötni a memória IC-t.
Title: Re: NICK
Post by: endi on 2014.July.31. 19:19:21
Én ezt nem teljesen értem. Hol jelenne meg ez a több szín?
Title: Re: NICK
Post by: DrPrery on 2014.July.31. 19:49:12
Na most akkor mi is lenne a tulajdonképpeni cél?
Gondolok arra, hogy valaha mondtam, de jó lenne 320*200-ban 16 szín vagy ami még jobb lenne, 256! Akkor egy memóriaírással lehetne pixelt állítani NORMÁLIS felbontás mellett.
De ezzel az elméletetekkel mit is lehetne elérni?
Title: Re: NICK
Post by: lgb on 2014.July.31. 20:13:45
Quote from: endi
Én ezt nem teljesen értem. Hol jelenne meg ez a több szín?

Szo sincs tobb szinrol! Csak pl 16 szinu modban kotve vagy a felso 8 szinnel, mivel az a FIXBIAS altal meghatarozott. Ha tudod mappelni a szineket a Nick output-jan, akkor lehetne ezen enyhiteni.

Ettol meg maradna a szin/felbontas, ahogy volt, felreertes ne essek! Tehat a 16 szinu mod max vizszintes felbontasa ettol termeszetesen nem novekszik!

Az mar egy advanced topic, hogy esetleg a Nick kimenetet amolyan "VGA modon" csak indexnek kezelni es barmelyikhez RGB skalabol lehet rendelni szint, ez ugyan erdekes, de ehhez mar a Nick utan legalabbis kene egy kis jatszadozas. Itt csak sima mappingrol van szo, ami se a felbontashoz, se a szinek szamanak novelesehez nem vezet, csak meg lehet oket varialni, ami hasznos lehet bizonyos esetben. Talan :)
Title: Re: NICK
Post by: endi on 2014.July.31. 20:54:16
Az a helyzet, hogy vizuális szempontból a 8 fixbias szín nem igazán nagy korlátozás. Jól kitalálták azt. :)
Title: Re: NICK
Post by: DrPrery on 2014.July.31. 21:07:33
Hááát, lehetek hervasztó...? :twisted:
Ez így lehet, hogy technikailag érdekes, meg sziporkázik az innovációs hajlam, de...
Szóval én maradnék az IGAZÁN "kézzelfogható" előnyök mellett.
Az EP többek közt egyfajta sebességdeficitben szenved pl. grafikánál, mint minden olyan gép, amelyik trükkösen férhet hozzá a pixelekhez, lásd a bitplane félék például.
Érdemleges gyorsításra lenne szükség, ezért kultiválom azt a VGA-szerű módot.
Vagy esetleg tud itt valaki blitter chipet is eszkábálni? :ds_icon_cheesygrin:
(Na jó, ez azért nem egészen ugyanaz, de egyfajta gyorsítás lenne az is.)
Title: Re: NICK
Post by: lgb on 2014.July.31. 21:23:15
Quote from: DrPrery
Hááát, lehetek hervasztó...? :twisted:
em egészen ugyanaz, de egyfajta gyorsítás lenne az is.)

Latom, neked sebesseg maniad van, lasd pl Amigas ertekezes, hogy az is lassu. :) Nos, a "retro computing" marcsak ilyen, modern PC hw-val tudsz gyorsabbat is :) Itt szinte elony is neha a korlatozas, lassusag, mert kihivas igy megoldani barmit, trukkosen stb, nem ugy, hogy lecserelni az egeszet vmi gyorsabbra (az is egy vonal, persze, de szomoru is lenne, ha csak az egyetlen lenne meg 8 bit vonalon is!).
Title: Re: NICK
Post by: lgb on 2014.July.31. 21:24:20
Quote from: endi
Az a helyzet, hogy vizuális szempontból a 8 fixbias szín nem igazán nagy korlátozás. Jól kitalálták azt. :)

Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak :) Furak vagytok azert, nektek sem lehet kedvezni temaval ...
Title: Re: NICK
Post by: Zozosoft on 2014.July.31. 21:30:10
Quote from: lgb
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak :) Furak vagytok azert, nektek sem lehet kedvezni temaval ...
Én mindig utáltam a fixbiast!
Title: Re: NICK
Post by: endi on 2014.July.31. 21:57:06
Quote from: lgb
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak :) Furak vagytok azert, nektek sem lehet kedvezni temaval ...
én sose fikáztam. és asszem egyedül én vagyok grafikus itt :)
ti specy meg cpc konverziók miatt fikáztátok csak :P
Title: Re: NICK
Post by: DrPrery on 2014.July.31. 22:05:27
Quote
Latom, neked sebesseg maniad van,
< poén> Hja, a Speed mellékhatása... :smt042 </poén>

Amúgy meg azért vagyok erre a VGA-szerű dologra "rákattanva" mert baromi egyszerű lett volna eredetileg megcsinálni (félig-meddig sikerült is, csak hát az a 80*200...), legfeljebb a Nick-et kellene gyorsabb működésre sarkallni. Végtére is technikailag nem egy ördöngősség és miért ne lehetne egy architektúrából mindent kifacsarni amit csak lehet?

Erény már majdnem a lassúság...? Akkor az EP-t csak video-rammal kellett volna kiadni, a'la Amiga... de annyi eszük azért volt, hogy nem csak olyan lett gyártva, sőt a 128-as terjedt el jobban. Így legalább elmondhatjuk, hogy az EP-nek alapból volt már úgymond FastRam-ja :)
Ehhez képest a Commodore erre sose jött rá...?
Meg akkor minek turbósít itt bárki is Z80-at? :twisted: Minek a nagyobb sebesség, jól elvan mindenki a 4MHz-el...

Quote
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak (http://enterpriseforever.com/Smileys/phpbb/smiley.gif) Furak vagytok azert, nektek sem lehet kedvezni temaval ...

Ezúttal jó érzés, hogy nem számítok bele ebben a dologban a "mindenkibe" :twisted:

Amúgy a fixbias... először kissé furcsállottam kissé, nem mondom.
Ott van pl. a Sam Coupe, van neki egy 320*200 16 színű módja, egyenként választható színekkel, hagyományos megoldás, ugye. Igaz, a gép későbbi. Ha azt vesszük, hogy az EP-t mikor kezdték el tervezni, akkor ez a fixbias-os dolog talán nem is annyira kiakasztó, bár erre meg azt mondhatnák, hogy volt akkoriban már ST meg Amiga is, azokhoz képest az EP már lemaradóban volt... ki tud itt igazságot tenni... :oops:

Persze nem akarok semmi jó elrontója lenni, ha ez megoldja a fixbias problémát, akkor végtére is lehet értelme...
Title: Re: NICK
Post by: lgb on 2014.August.01. 08:52:58
Quote
Erény már majdnem a lassúság...?

Az lehet. Errol szol a "retro computing", ha sebesseget akarsz, modern PC-t kell venni, vagy hasonlo :) Legalabbis a mai korban aki meg foglalkozik ezzel (ok, magambol indulok ki, nem biztos, hogy mindenki igy gondolja) pl azert teszi, mert elege van a "modern" dolgokbol, ahol egy uj sw-nel kozlik veled, hogy vegyel ketszer gyorsabb CPU-t, meg ketszer annyi RAM-ot, az sw-vel semmi baj nincs, a hw-d gagyi. Regen ez nem igy volt, adott volt a gep, vagy meg tudtad oldani rajta (es akkor jo voltal) vagy nem (es akkor nem voltal jo). Nyilvan ez mara megvaltozott, es atestunk kb a lo tulso oldalara. En a magam reszerol ezert is szeretem ezeket a "regi" dolgokat, ahol meg mas volt a filozofia. Nyilvan, a maga koraban ez nem feltetlenul igy jott le az emberekben, amikor meg nem volt alternativa (pl videot editalni azert nem EP-n kezdenek manapsag, ahogy egy 3D scene-t sem renderelni, mert erre - azert lassuk be - vannak ma mar alkalmasabb eszkozok ...).

Quote
Akkor az EP-t csak video-rammal kellett volna kiadni, a'la Amiga... de annyi eszük azért volt, hogy nem csak olyan lett gyártva, sőt a 128-as terjedt el jobban. Így legalább elmondhatjuk, hogy az EP-nek alapból volt már úgymond FastRam-ja :)
Ehhez képest a Commodore erre sose jött rá...?

Nagyon faj neked ez az Amiga :D Amugy szerintem az EP-nel se volt alapbol, ha szetszeded az EP128-at, latod, hogy a VRAM az alaplapon van, a tobbi 64K ram egy bovito panelen csucsul. Tehat ugy is mondhatjuk, hogy ott is utalogos bovites, csak mar eleve installva arultak :-P

Quote
Meg akkor minek turbósít itt bárki is Z80-at? :twisted: Minek a nagyobb sebesség, jól elvan mindenki a 4MHz-el...

Persze, nyilvan a lo tulso oldalara sem kell atesni, ez is erdekes jatek, hogy CPU-t rubositani, RAM-ot hozzatenni, SD kartya olvasot (ami akkoriban persze tutira nem is letezett) illeszteni, ezeket a dolgokat is szeretem, es erdekelnek, amde vigyazni kell, ha az ember _csak_ erre hajt, akkor elveszti ez a hobby az eredeti gyokereit. Legalabbis szerintem.

Quote
Amúgy a fixbias... először kissé furcsállottam kissé, nem mondom.
Ott van pl. a Sam Coupe, van neki egy 320*200 16 színű módja, egyenként választható színekkel, hagyományos megoldás, ugye. Igaz, a gép későbbi. Ha azt vesszük, hogy az EP-t mikor kezdték el tervezni, akkor ez a fixbias-os dolog talán nem is annyira kiakasztó, bár erre meg azt mondhatnák, hogy volt akkoriban már ST meg Amiga is, azokhoz képest az EP már lemaradóban volt... ki tud itt igazságot tenni... :oops:

A Nick szerintem nagyon "aranyos" es erdekes kis chip, nekem tetszik, az egesz LPT, hogy van kb negy szem regisztere (ha jol emlekszem) a tobbit mind kozben nyalja fel (LPT-bol) ami kell a mukodesehez, ezaltal a CPU-t tehermentesitve olyan trukkok eseten, hogy pl a kepernyo egy resze mas felbontasu es videomodu, stb. A fixbias vegulis termeszetes velejaroja volt. Ha mar van palette minden nem-256 szinu modban, es tudjuk, hogy a nick egy slot alatt 2 byte-ot kepes olvasni, ebbol azert tobbe-kevesbe adodik, hogy LPT filozofia eseten egy LPB-be nem igazan ferne bele a 16 szinu modokhoz kello paletta, ha mas is kell az LPB-be (es nyilvan kell). Persze, lehetett volna meg par Nick regiszter, amivel legalabbis globalisan megoldhato a felso 8 szin kerdese 16 szinu modban, de ez valoszinu aranyiaban joval tobb bonyolitast adott volna, masreszt ismet csak csorbitott volna az LPT szeru mukodes filozofiajan (bar nyilvan inkabb az elobbi a fontosabb limitacio, szerintem). Ha egyszer valaki pl FPGA-ban vagy CPLD-ben vagy tudomisen csinalna uj Nick-et, szerintem ez lenne az egyik elso dolog (most jon az altalad emlitett "bovites" tema ...), hogy beallithato legyen: mondjuk dupla rate-el olvasson a Nick RAM-ot. Ezaltal egyreszt a felbontas is none, masreszt az LPB lehetseges merete is, igy pl beleferne 16 szinu paletta is. Es nem utolsosorban: lehetne olyan szoveges mod (a nem hasznalt helyere? vagy nem tudom) ahol egy karakterhez van szininformacio is. Vegulis erdekes project lenne: fog az ember egy atlagod modern SDRAM-ot (nyiltan SRAM meg egyszerubb de az meg mindig nem feltetlen olyan olcso, es ha mar PLD jellegu aramkor, oda nem gond rittyenteni egy memory controllert hozza), vagy hasonlo, es FPGA ala tolja, SDRAM memory controller project szerintem letezik nem is egy VHDL-ben es Verilogban is pl. Ott aztan lenne eleg savszelesseg, es a parhuzamos bitszam lehet nagyobb is 8-nal, igy a Nick-2 kepes lenne tobb adat felszipkazasara ugyanannyi ido alatt. Sot, azt is lehetne, hogy LD1 LD2 meg az LPT pointer kiterjesztese a teljes cimtartomanyra, es akkor az egesz memoria VRAM is egyben, szerintem elbirna az EP-n talalhato VRAM lassabb jelenseg nelkul is boven egy mai modern memoriaval (max compatibility okokbol a felso 64K-ra lehet "mesterseges" lassitas, hogy az idozites pontos legyen a regi hw-hez igazodva, es lehetne ez pl ki-be kapcsolhato). Nyilvan ekkor mar a VGA-ra kotjuk kerdest is erdemes lehet megoldani vagy akar HDMI stream-et is nyomhatna magabol.

Amugy amit en meg Nick2-be tennek a fentieken kivul (a sprite stb mas kerdes, az kisse elut ettol ettol a tematol, bar azon is lehetne gondolkodni):

* attribute mode ZX Spectrum interpretation bit :) Az attibute infonal speccy modjara ertelmezne az attrib byte-ot. Speccy atiratoknal, sw emulatornal igy egyszerubb lenne a dolog.
* EP 256-os szinpalattajanak globalis atdefinialasi lehetosege mas szinekre egy hi/true-colour RGB palettarol valogatva
* horizontal pixel pontossagu scroll, akar LPB-ben (a "kiterjeszetett hosszu" LPB-ben ...) is megadhato lenne
* ha elegendo memoria savszelesseg meg van: tobb kep megjelenitese egymas felett (atlatszo lehetne a nullas szin stb), mondjuk ilyen perspektiva megoldasoknal utos lehetne a hatterhez

Szoval lehet nagyban is gondolkodni, de azert szerintem nem szabad szem elol vezteni az eredeti hw-t es filozofiat sem, ez azert fontos! Mondjuk a baj a fentiekkel az, hogy erre sok sw nem lenne, mert ugye nem sok embernek van "nem standard" hw-je, lassan mar standard se soknak :( Igy ezek a project-ek sok esetben inkabb onszorakoztato hobby-k, es max par embert erdekelnek az ilyen jellegu bovitesek. Egeszen
addig, amig nem keszul el a C64DTV mintajara pl az EP128DTV, ott is lehetne ahogy a C64DTV-nel a meglevo viszonylag jo kompatibilitas melle rakni plusz dolgokat extrakent! Ha a speccy kompatibilitas eleg jo, akkor talan uzletnek sem lenne rossz, hiszen ez utobbit tobben ismerik, es vennek meg, mar csak a "retro gaming" miatt is, a C64DTV-hez hasonloan (ott is van par ember - pl en - aki a hw, erdeklodes, programozas miatt vette, de azert C64DTV-t legtobb ember nyilvan azert vette mert a regi jatekok "amivel meg fiatal koraban jatszott" ...)

Ezek mellett C64DTV-bol ismert extra megoldasok (DMA, Blitter) is erdekes dolgok lehetnenek. Ha mondjuk ertenek :) az FPGA-khoz, en ilyen projectnek poenbol nekiallnek, meg ha mast nem is erdekelne nagyon.


Quote
Persze nem akarok semmi jó elrontója lenni, ha ez megoldja a fixbias problémát, akkor végtére is lehet értelme...

Nyilvan, az otlet lenyege a viszonylagos egyszerusege. Pont azert vazoltam, hogy lehetne egy tok uj Nick is, hogy az is egy irany, de azert az a joval tobb ember kepessegeit (pl az enyemet is ...) felulmulja, ahhoz kepest, hogy egy ilyen szinatmappeles elemeletben legalabbis ertheto mondjuk szamomra is :)
Title: Re: NICK
Post by: DrPrery on 2014.August.01. 09:58:04
Quote
Nagyon faj neked ez az Amiga (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Bocsi, de mintha te is emlegettél volna valami olyat, hogy inkább az Amiga mint a PC lett volna elterjedve... :oops:
Persze, hogy fájhat, ha ilyen pitiáner egyszerű dolgokon is elcsúszik ilyesmi... :ds_icon_frown:

Quote
Idézet

Quote
Erény már majdnem a lassúság...?
Az lehet. Errol szol a "retro computing", ha sebesseget akarsz, modern PC-t kell venni, vagy hasonlo (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Nem hinném hogy pl. azok az orosz fickók is ezt gondolták, akik mindenféle "turbózott" spectrum-klónokat kezdtek csinálni... :twisted: Ott is "húztak" a CPU-poweren, mégsem az volt a céljuk, hogy 4GHz-es 16 magos Z800000000-t csináljanak... nyilván az adott architektúra keretein belül maradtak valahol. Ugyanez vonatkozik a grafikára is. Nyilván nem akarunk 2048*1920-at 16millió colorral, meg effélék, de azért egy "alap" VGA-szerű dolog már hadd ne legyen felfuvalkodott vágyálom, retro ide vagy oda... Ezen az alapon fenéken lehetne rúgni a C64DTV készítőit is, mert ott már elérték ezt a 256-szín dolgot, de hát minek is... mert az alap C64-et véve ez már "őrültségnek" is hathat, ugye... :twisted:

És hát ezen az alapon el lehet felejteni minden további ábrándozásokat az EP 2-ről is... (Zozo nagyon nem örülne... :ds_icon_cheesygrin::twisted: )
Title: Re: NICK
Post by: lgb on 2014.August.01. 10:24:45
Quote from: DrPrery
Bocsi, de mintha te is emlegettél volna valami olyat, hogy inkább az Amiga mint a PC lett volna elterjedve... :oops:

Valoban, de hogy jon az ide? Retro dolgokrol van szo, a PC nem retro ... Az Amiga es az EP az, mondhatjuk.

Quote
vágyálom, retro ide vagy oda... Ezen az alapon fenéken lehetne rúgni a C64DTV készítőit is, mert ott már elérték ezt a 256-szín dolgot, de hát minek is... mert az alap C64-et véve ez már "őrültségnek" is hathat, ugye... :twisted:

Igen, de pont ezt irtam is, ha nem is most, regen valahol a forumon :) Egy olyan project mint a C64DTV az hatareset. Miert? Mert van rajta egy szem ASIC, es abban van minden (a memoria es flash nem, OK, de a CPU, VIC, SID, CIA, stb). Ez meg ugye kisse olyan feeling, mintha emulatorod lenne, nincsenek meg a konkret diszkret alkatreszek, te szintetizalsz ossze vmit, VHDL-ben vagy Verilogban programozva, es az lesz az ASIC-ben (na jo, ha en csinalnam nyilvan FPGA-ban, de ez most reszletkerdes). Ilyen elven az se sokkal massabb, ha veszel egy rasberry Pi-t, es arra hegyezel ARM-on futo emulatort, amit leprogramozol. Ugyanakkor a fentiek ellenere nem mondanam, hogy a DTV hulyeseg, es nem volt jo otlet. Viszont ott van az az erzes is, hogy orulnek egy olyan "nexgen C64-nek" ami diszkret alkatreszekbol all, legalabb a CPU megvan kulon pl :) Tehat jokat vitatkoznal itt velem, de nincs ertelme: a vilagon sehol nincs olyan (itt se), hogy feher vagy fekete, altalaban a szurke aranyalatit latjuk, mindennek magvan a maga helye, ertelme, stb,.
Viszont total eltertunk megint a targytol (Hardver/Nick "rovat"), szerintem ilyen temakban vmi off-topic alattira kene atmenni, lassan minden topic-ot "beszennyezunk" ugyanis :)

Gyorsan hozza is tennem: a par eve (?) megjelent "uj C64" az viszont baromsag: amikor PC-t tettek egy C64-nek megfelelo kinezetu hazba. Ennek tenyleg semmi ertelme. Az PC, es nem C64. A C64DTV sokkal inkabb C64, annak ellenere, hogy a kulseje alapjan nem igazan :) Ez is embere valogatja: kinek mi a fontos, nekem pl az eredeti haz nem is annyira, a "belbecs" ami azza teszi, ami viszont igen. Tudom, ezzel sokan nem fognak egyeterteni itt, en oket is megertem (pl amikor joystick sapka kell meg ilyenek, na en ilyenre tuti nem koltenek ...).

Quote
És hát ezen az alapon el lehet felejteni minden további ábrándozásokat az EP 2-ről is... (Zozo nagyon nem örülne... :ds_icon_cheesygrin::twisted: )

Akkor nem olvastad amit irtam, pont ott ecseteltem, hogy jo lenne egy EP2. Csak azt tettem hozza, hogy nem kell allandoan sirni, hogy az "alap" EP lassu, mert az ugy szep ahogy van, ugy tortent, ugy van meg a retro feeling stb, ha olyan aron akarunk egy EP2-t, hogy az eredeti EP-t nem is "tiszteli" az ember, vagy allandoan sirdogal rajta, akkor neki EP2 sem valo, inkabb vmi mas gepet kene epiteni, ahol nem feltetel az eredeti EP-vel valo semmilyen foku kompatibilitas. Ezt most bocs, nem flame-kent irtam, ne ugy ertsd, csak nem tudom szebben megfogalmazni.
Title: Re: NICK
Post by: Z80System on 2014.November.15. 22:35:09
Tudjátok, van a donkey kong, mely valami CPC átirat a file neve alapján,

és az LPT -jén van valami nagyon érdekes, gyenge, vízszintes hullámzás jelenség ...

Olyan gyenge, hogy szerintem az EP pixel értelemben ilyen szubpixeles vízszintes elmozdulást jelent.

Namost ez a hullámzás nem csak a CRT monitorokon van, hanem átmegy a SCALER->TFT pipeline -on is ... :)

Tehát TFT -n is EP szubpixel hullámzás van ... :)
Title: Re: NICK
Post by: endi on 2014.November.15. 22:52:10
ezt én is felfedeztem és próbáltam is kihasználni egyik demómban
volt is róla beszélgetés itt valahol már, és zozo asszem kiderítette hogy nem lehet semmire se használni, csak kb arra ami a demómban is van :)
Title: Re: NICK
Post by: Z80System on 2014.November.16. 11:07:16
Van egy IC az alaplapon a bal felső sarokban, LM1889N jelöléssel,
ha annak a hátsó bal oldala felé nyúlkálok kézzel, akkor valami olyan zajokat teszek rá,
ami a mellékelt videóban lévő effektet eredményezi ... :)

Egy (mondjuk printerportra rakott) D/A konverterrel meg némi csatolással nem lehetne ezzel szerintetek egy scroll effektet létrehozni ?

Persze kétoldali villogás nélkül csak olyan monitoron menne, ahol ki tudod húzni a képet vízszintesen olyan szélesre, hogy már ne jelezze ki a kép két szélét,
de ha nincs olyan monitor, még akkor is megérné egy ilyen fínom vízszintes scroll a kép két szélén a scroll -ozás villogó sávját ...

(Hosszabb volt a videó, de csak ennyit enged feltölteni. :()
Title: Re: NICK
Post by: geco on 2014.November.16. 11:17:02
Érdekes, normális LPT-je van a DK-nak, úgy emléxem semmi extra nincs benne, viszont a hullám effekted elég érdekes.
Title: Re: NICK
Post by: Z80System on 2014.November.16. 11:27:54
Quote
Érdekes, normális LPT-je van a DK-nak, úgy emléxem semmi extra nincs benne, viszont a hullám effekted elég érdekes.

És működik minden LPT -n, játékokban is, valszeg valami videójel vízszintes szinkront befolyásolhat, vagy mittomén ...

Lényeg hogy ha megtalálnánk melyik a helyes IC láb, és rendesen videómegszakból időzítve egy D/A konverteren keresztül állítanánk valami kikísérletezett feszültség értékekre,
akkor kapnánk belőle vízszintes scroll -t ... :)
Title: Re: NICK
Post by: Z80System on 2014.November.16. 13:02:01
Már többször csodálkoztam, hogy a NICK -eken miért nincs olyan szép felfestés, mint a DAVE -eken ...

Aztán most láttam a NICK hűtést ... hát ezért:

Title: Re: NICK
Post by: Zozosoft on 2014.November.16. 14:08:46
Már többször csodálkoztam, hogy a NICK -eken miért nincs olyan szép felfestés, mint a DAVE -eken ...

Aztán most láttam a NICK hűtést ... hát ezért:
Ezen azért van (http://ep128.hu/Album/Pic/NICK.jpg), mert gyárilag felejtettek el rá hűtést rakni :-)
Amúgy semmilyen hibát nem produkál. Sőt több más 08-47-esnél sem raktam vissza a leesett bordát, hogy legyen tartalék 08-04-esekhez (több olyan EP64-em is van amiből az idők során elveszett a borda.)
Title: Re: NICK
Post by: Z80System on 2014.November.16. 14:26:56
Úgy döntöttem az egér után rámegyek erre a scroll dologra, hátha tényleg működhet.
Ha valaki tudja hogy miért hülyeség az mondja, ne kínlódjak vele feleslegesen ...

Először majd azzal kezdem, hogy azt az IC -t megismerve síma diszkrét elemekkel megpróbálom egy potival ide-oda mozgatni az EP(LPT) képét,
de ha ez megvan, akkor kell tudni ezt a z80 -nal vezérelni, nyilván időzítve, ehhez kérdezném:



Milyen nehéz a z80- ra rakni egy "új portot", amin figyel egy D/A converter IC ? Tehát hogy írhassak egy portot z80 -nal, és legyen egy arányos analóg jelem ?

Hány IC vagy akármi kellhet egy ilyenhez, kb. ? Vagy egyszerű egy ilyen port IO megvalósítás, és nem is kellene a DAC IC -n kívül más különösebben ?

Igazából megfelelő lehetne a printer port is, és akkor (akár kívül, akár belül) tehetném a DAC -ot arra, mert a printert sztm alig használják a népek bármire is,
viszont azért csak kellene valami kapcsoló, amit a DAC (vagy valami segédelektronika) figyelne, és ha nincs bekapcsolva, akkor azért lehetne a printer portot eredeti céljának megfelelően használni ... szóval le kéne tudjam kapcsolni valami EP -n már meglévő port bit -jét figyelve ezt a scroll működést ...

Van ilyen "felesleges" vagy használható bit már ? Mint amilyen felesleges "bitek" pld. a 10-15 -ös billentyű sorok ...

A printer portot (amíg el nem kezdek nyomtatni) abajgatja egyébként az EXOS csak úgy magától ?

Az igazi az lenne, ha lenne valami bit már az EP -ben, ami lekapcsolná a scroll elektronikámat, és miután egy program már lelőtte az EXOS -t, azután külön engedélyezné, és akkor már lehetne a printer portot scroll -ozásra használni.

Ha így nem megoldható, akkor saját port kéne inkább ... kérdés hogy az kb. mennyire bonyolult ?
Title: Re: NICK
Post by: Z80System on 2014.November.16. 15:00:50
Ha működne ez a vízszintes scroll dolog, akkor kombinálva az LPT függőleges scroll -jával lehetne egész képernyős 4 irányú scroll -okkal nyomulni ...

Akár úgy, hogy 16 színű a grafika, de a scroll akkor is 4 színű üzemmód méretű (vagy még annál is finomabb, ha akarjuk) vízszintesen is ...
Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 11:11:28
Werner Lindnernek köszönhetően:
Nick chip tervrajz 1. oldal (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-1.pdf)
Nick chip tervrajz 2. oldal (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-2.pdf)
Nick chip technikai ismertető (http://enterprise.iko.hu/technical/NICK-Old-VDC-ELITE-description.pdf)
Nick chip belső időzítések (http://enterprise.iko.hu/technical/NICK-Internal-timing-of-VDC-Elite.pdf)
Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 11:39:00
És ami az angol fórumban már elhangzott Wernertől:
Quote
Az IS/Enterprise 1983-ban lépet kapcsolatba az AMI-val. Az AMI képviselője mesélte, hogy ezek az emberek bejöttek az irodába, két kézzel drótozott prototípusának "valaminek", és azt mondták ezeknek az egyedi IC-jét szeretnék.
Nem volt semmilyen konkrét terv vagy rajz ezekhez a chipekhez, vagy a végleges prototípusnak. Nyilvánvalóan az IS emberei még soha nem csináltak hasonlót. Nem tudták, hogy nem lehetséges normál alkatrészekből és IC-kből összerakott áramkört 1:1-ben sziliciumra átrakni. Az AMI embereinek kellet modellezni a prototípus normál alkatrészeit nagyszámú alacsony szintű logikai kapu felhasználásával. Ebben az időben még nem voltak olyan konfigurálható áramkörök mint manapság (FPGY, CPLD,...)

A legelső verziója a Dave-nek (amit ESPRIT-nek neveztek ebben az időben, és az AMI a gyártás során végig megtartotta ezt a nevet) 1983 augusztus/szeptember környékén lett kész. Az első (és hibás) Nick (amit ELITE-nek neveztek) 1983 novemberére. Amikor ez első prototípusok megérkeztek Londonba, kiderült, hogy nagyon nem úgy működnek ahogy várták. 1984 novemberéig a Dave 4 revizión ment keresztül, a Nick pedig 5-en, amíg elértek a végleges változatot.

A Nick terveknél nem tudni mikor váltottak version 1-ről (08-04) version 2-re (08-47), de az E revizó az biztosan a 08-47. A rajzokon sajnos nem látszik változtatás nyoma, valószínűleg apró de fontos változások voltak.
Title: Re: NICK
Post by: Z80System on 2015.March.21. 12:02:29
Quote
Werner Lindnernek köszönhetően:
Nick chip tervrajz 1. oldal
Nick chip tervrajz 2. oldal
Nick chip technikai ismertető
Nick chip belső időzítések

Ez meg a NICK ? ? ? Teljes kapcsolási rajza ? Egy az egyben reprodukálható 100% -ig a NICK innentől ? ? ?

( Hibáktól mentes alkatrészekből ? ? ? Vagy maguk a hibák azok az elvi kapcsolásban vannak ? )
Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 12:27:39
Igen, elvileg ez az utolsó (08-47) verzió rajza.
Innen már a CPLD mágusoké a terep :-)
Title: Re: NICK
Post by: Z80System on 2015.March.21. 12:30:00
Besza- behu! :)
Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 12:30:55
Egy kis érdékesség: a leírásban szó van az NTSC müködésről is!

Egyébként kiváncsi leszek István milyen érdekessegeket talál majd benne. ő már eddig is elég jól kikövetkeztette a Nick müködését.
Title: Re: NICK
Post by: Z80System on 2015.March.21. 12:33:35
Quote
Innen már a CPLD mágusoké a terep :-)

Hát ... vagy aki nem fél a nagy nyákoktól ... :)

Quote
Egy kis érdékesség: a leírásban szó van az NTSC müködésről is!

Ezt most nem vettem le ? Miért érdekes az NTSC mint olyan ? USA miatt, vagy mi ? Hova hiányzott eddig ? Vagy abszolút technikailag érdekesség csak ?

Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 12:47:58
Ezt most nem vettem le ? Miért érdekes az NTSC mint olyan ? USA miatt, vagy mi ? Hova hiányzott eddig ? Vagy abszolút technikailag érdekesség csak ?
érdekesség. Eddig is tudtuk, hogy voltak a CES-en Las Vegasban, tehát gondoltak az amerikai piac meghódítására is.
Csak azt nem tudtuk, hogy USA-ban hogy müködött volna a Nick, hogy ottani tvn is legyen kép :-)
Title: Re: NICK
Post by: Trefe on 2015.March.21. 15:05:39
Biztosan én bénázok valamit, de nem tudom megnézni a rajzokat. Csak valami szaggatott vonalas halvány ábra jelenik meg letöltés után...
Title: Re: NICK
Post by: Zozosoft on 2015.March.21. 16:44:47
Bele kell nagyítani 100%-ig. Eredetileg A0-ás lapokról van szó, kb 18000x13000 a kép nagysága.
Title: Re: NICK
Post by: Trefe on 2015.March.21. 20:07:36
Bocs... Adobe Readerrel már jó. Köszönöm a feltöltést.
Title: Re: NICK
Post by: lgb on 2015.March.21. 22:48:24
Igen, elvileg ez az utolsó (08-47) verzió rajza.
Innen már a CPLD mágusoké a terep :-)

Berosalok :) Bar, hogy ebbol ki vallalkozna pl VHDL-ben megirni a cuccost, az nehez kerdes :D Mert ugye, ha az AMI-nak is az volt a baja, hogy az IS odallitott diszkret IC-kbol allo prototipussal, akkor modern FPGA/CPLD realizaciokor is kb ez lenne a problema: a "kapcsarjzon" konkret kapuk stb vannak, ami alapjan azert eleg nehezkes ezt realizalni mas szinten ... Vagy valaki beviszi kapcsrajzkent kb, elvileg olyat is lehet, aztan majd az alapjan szintetizal maganak cuccost a software, de az meg eleg hmm embertelen munka lenne szerintem :)
Title: Re: NICK
Post by: Ep128 on 2015.March.21. 23:18:11
Most már csak az a kérdés, hogy valóban a legutolsó, tehát a javított, működő adatai e ezek! :-) Ha igen, hatalmas kincs, ha nem, akkor tulajdonképpen ott tartunk velük, ahol ők is agybajt kaptak... :-D
Title: Re: NICK
Post by: Tuby128 on 2015.March.23. 15:46:21
Nekem pont erre van szükségem. Köszönöm a dokumentumokat!
Title: Re: NICK
Post by: Tuby128 on 2015.March.23. 16:26:41
Többször hivatkozik az írás a DPC11.doc-ra. Ezt nem lehetne megszerezni?
Title: Re: NICK
Post by: Zozosoft on 2015.March.23. 16:28:49
Többször hivatkozik az írás a DPC11.doc-ra. Ezt nem lehetne megszerezni?
Ott van az is, az a technikai ismertető.
Title: Re: NICK
Post by: sanyike on 2015.September.24. 09:28:26
Érdekelne egy pár olyan kód amivel meg lehet hülyíteni a NICk-et.
Gondolok itt olyan kódokra, amelyek a képernyő futását, torzulását, hibaszerű reagálását váltják ki.
Természetesen olyan módon, hogy van visszatérésre, helyreállításra lehetőség.
Title: Re: NICK
Post by: lgb on 2015.September.25. 02:36:55
Érdekelne egy pár olyan kód amivel meg lehet hülyíteni a NICk-et.
Gondolok itt olyan kódokra, amelyek a képernyő futását, torzulását, hibaszerű reagálását váltják ki.
Természetesen olyan módon, hogy van visszatérésre, helyreállításra lehetőség.

Mivel sok mas geppel ellentetben EP/Nick-en a VSYNC-et is a user vezereli az LPT-n at, ezert ha random irkalsz dolgokat, vagy csak nem figyel az ember, sokkal nagyobb valoszinuseggel eri el a fentit, mint stabil kepet :) Ez azonban nem bug, hanem feature :)
Title: Re: NICK
Post by: szipucsu on 2015.September.25. 19:30:07
Érdekelne egy pár olyan kód amivel meg lehet hülyíteni a NICk-et.
Endinek volt egy POKE-ja, amivel függőlegesen elmozdul a kép. Kisebb elmozdulásokból képernyőrázást is lehetett.
Title: Re: NICK
Post by: ergoGnomik on 2015.September.25. 20:02:17
Endinek volt egy POKE-ja, amivel függőlegesen elmozdul a kép. Kisebb elmozdulásokból képernyőrázást is lehetett.

Szerintem nem ilyesmire gondol sanyike, hanem olyasmire ami komolyan összekeveri a NICK működését. Pfúj, Commodore-os példák: amikor C64-en lebontják az oldalsó keretet, vagy annak ellenére hogy nincs olyan kényelmes technológiájuk mint az LPT, a maximum 7 képpontos finom görgetésnél nagyobb mértékben mozdítják el a képernyőt, vagy valami más, a megjelenítő lelkivilágát jelentősen megzavaró húzás, ami mégis értelmezhető képet ad, mint például plus/4-en csinálta meg valaki (ha jól tudom), hogy megnövelte az egyébként fix vízszintes felbontást a kép egy részén.

Tudtommal ilyen lehetőségek nem nagyon vannak a NICK esetében, mert olyan regiszterek nem hozzáférhetőek amik a képsor megalkotására közvetlenül hatnak. Lehet próbálkozni az LPT erőszakos újratöltésével a rasztersor közepén (persze halálpontos időzítéssel), vagy ha van a NICK-nek is valamilyen teszt bitje esetleg annak az izgatásával, de mást én nem tudok elképzelni. Bár a fantáziám azért nem mondható dúsnak. :(
Title: Re: NICK
Post by: endi on 2015.September.25. 20:54:22
túl jól megtervezték az EP-t... és ebből a szempontból ez nem jó :)
én elég sokat szórakoztam ilyenekkel, és az említett "elhajlító" effekt kivételével nem találtam ilyet. ez az elhajlító se jó semmire, valszeg csak bizonyos tévéken műxik. már azt se tudom melyik demóban volt. emu alatt úgyse látszik... igazi gépről kéne fotózni egy képet

mások demóiban, programjaiban se láttam ilyet

ja meg esetleg az a trükk hogy a biast soronként többször megváltoztatjuk
erről itt egy régi kép, amikor még az emulátor nem tudta ezt: http://ep128.hu/Ep_Demo/Pic/Orkdemo2.gif

a mellékelt kép meg amikor már tudta :)
bár villog kicsit, de asszem EP-n is villogott
a függőleges csíkokat kell nézni, a bias színek, soronként 8x megváltoztatva
de persze ez se új trükk, borderrel még specyn is csinálták
Title: Re: NICK
Post by: IstvanV on 2015.September.26. 11:35:26
Szerintem nem ilyesmire gondol sanyike, hanem olyasmire ami komolyan összekeveri a NICK működését. Pfúj, Commodore-os példák: amikor C64-en lebontják az oldalsó keretet, vagy annak ellenére hogy nincs olyan kényelmes technológiájuk mint az LPT, a maximum 7 képpontos finom görgetésnél nagyobb mértékben mozdítják el a képernyőt, vagy valami más, a megjelenítő lelkivilágát jelentősen megzavaró húzás, ami mégis értelmezhető képet ad, mint például plus/4-en csinálta meg valaki (ha jól tudom), hogy megnövelte az egyébként fix vízszintes felbontást a kép egy részén.

Szerencsére a NICK ezeket trükkök nélkül is tudja.

Quote
Lehet próbálkozni az LPT erőszakos újratöltésével a rasztersor közepén (persze halálpontos időzítéssel)

Nem működne, mert csak a következő sor elején tölti újra.
Title: Re: NICK
Post by: endi on 2015.October.02. 00:38:29
nem is tudom hova tegyem ezt...
mobilon nagy divat a retró, a pixeles graf. de persze kocka alakú pixelekkel, nem laposakkal :)
na gondoltam kipróbálom hogy nézne ki pár ep játék kocka pixelekkel, íme
persze letöltve, belezoomolva az igaz

nem egy nagy szám az eredmény, úgy értem azt hittem érdekes lesz, (mert szebb biztos nem) de nem :)

amúgy persze ha eleve kocka pixelekkel készül egy játék, akkor az azért szebb, és mobilon elég sok szép példa van erre, akár jóval nagyobb pixelekkel is

Title: Re: NICK
Post by: ssr86 on 2015.October.02. 08:33:14
nem is tudom hova tegyem ezt...
mobilon nagy divat a retró, a pixeles graf. de persze kocka alakú pixelekkel, nem laposakkal :)
na gondoltam kipróbálom hogy nézne ki pár ep játék kocka pixelekkel, íme
persze letöltve, belezoomolva az igaz

nem egy nagy szám az eredmény, úgy értem azt hittem érdekes lesz, (mert szebb biztos nem) de nem :)

amúgy persze ha eleve kocka pixelekkel készül egy játék, akkor az azért szebb, és mobilon elég sok szép példa van erre, akár jóval nagyobb pixelekkel is



I think that you can find better examples of "small resoltion with cubic pixels" on handhelds: 4-color 160x144 gameboy classic games, 16-color (?) atari lynx, also neogeo pocket and wonderswan graphics I guess... And I think that a lot of gameboy ports would be even feasible on the ep...


Wanted to ask one thing... As the "problem" for abusing nick features is the lack of immediate access to all of it's registers and creating the display via lpt which values are fetched from only at the beggining of meach line. Is it possible to make a hardware hack to map the now-unaccesable registers to some free ports... "Nick Unleashed";P. Asking out of sheer curiosity as I guess this would take too much "meddling" with the computer's motherboard...
Title: Re: NICK
Post by: endi on 2015.October.07. 00:43:29
egy nagyon vicces dolgot vettem észre!
EP-n nincsenek szürke színek :D
hát ez poén :)
egyszerűen nem lehet olyan színeket találni amik szürkék. kicsit sárgás, kicsit kékes mind :D
Title: Re: NICK
Post by: lgb on 2015.October.07. 09:02:23
egy nagyon vicces dolgot vettem észre!
EP-n nincsenek szürke színek :D
hát ez poén :)
egyszerűen nem lehet olyan színeket találni amik szürkék. kicsit sárgás, kicsit kékes mind :D

Ez talan azert is van (?) mivel az RGB komponensek nem egyenlo szamu bittel vannak abrazolva, a kek csak 2 bit, a piros/zold meg 3 bit. Mashol olyan megoldas is volt, hogy mivel 8 bit van, 2-2-2 bit legyen a maradek bit meg intenzitas.
Title: Re: NICK
Post by: endi on 2015.October.07. 09:23:08
Ez talan azert is van (?) mivel az RGB komponensek nem egyenlo szamu bittel vannak abrazolva, a kek csak 2 bit, a piros/zold meg 3 bit. Mashol olyan megoldas is volt, hogy mivel 8 bit van, 2-2-2 bit legyen a maradek bit meg intenzitas.

na igen, de nem lehetett volna besúlyozni úgy hogy épp kijöjjön pár jó szürke?
mert azért vicces hogy egy sincs, legalább 1 lenne! :) (oké, a fehér az tökéletes, csak túl világos szürkének)
na jó meg a fekete is ott van :)
persze értem én hogy lineárisan vannak súlyozva valszeg a színkomponensek
az is vicces hogy ennyi idő után veszem észre ezt :)
Title: Re: NICK
Post by: IstvanV on 2015.October.07. 09:54:47
na igen, de nem lehetett volna besúlyozni úgy hogy épp kijöjjön pár jó szürke?

Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.
Title: Re: NICK
Post by: endi on 2015.October.07. 10:27:17
Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.

na de maradnunk kell a meglévő ep-nél :)
Title: Re: NICK
Post by: ergoGnomik on 2015.October.07. 12:39:53
Pont hogy a meglévő Ep-ről beszél IstvanV. Ott van a kapcsolási rajzon is, a harmadik lapon, a C4 szegmensben. U34 17-es, 18-as és 19-es lábak. Ott megyen be az RGB-YCbCr átalakítóba.
Title: Re: NICK
Post by: endi on 2015.October.07. 13:13:47
Pont hogy a meglévő Ep-ről beszél IstvanV. Ott van a kapcsolási rajzon is, a harmadik lapon, a C4 szegmensben. U34 17-es, 18-as és 19-es lábak. Ott megyen be az RGB-YCbCr átalakítóba.

tehát átkötjük minden EP-ben? :)
Title: Re: NICK
Post by: endi on 2015.October.07. 13:28:28
amúgy ez a szürkeség hiány azért érdekes, mert akkoriban, de most is eléggé általános a felhasználói programokban a szürke.
játékban még elmegy, hogy aminek szürkének kéne lennie az kicsit kékes meg sárgás :)

szerk: lehet hogy ezért nem futott be az EP??? :) windóz nem lehetett volna EP-re mert ott szükséges a szürke! :D
Title: Re: NICK
Post by: ergoGnomik on 2015.October.07. 13:48:15
tehát átkötjük minden EP-ben? :)

Bocs, de én a helyedben mégegyszer elolvasnám mit írt István. :)

Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.

Tehát, ha valamilyen TV kimenettel használod a gépet és a vörös és zöld komponenseknek is 0, 2, 5 vagy 7 értéket választasz, akkor szürkét fogsz kapni. Nyilván a kék 0..3 értékei mellett. Hogy a digitális kimenet (és esetleg az emulátor) ettől eltérően viselkedik, az független esemény. Ettől maga az eredeti gép alapkiépítésben tudja. Szerintem.
Title: Re: NICK
Post by: endi on 2015.October.07. 14:04:56
na ez jó kérdés akkor, hogy vajon az igazi gép hogy is csinálja?
az logikátlan lenne számomra hogy a digitális kimeneten másféle súlyozása van a színeknek!

de jobban belegondolva hirtelen nem is tudom hogy lehetne az 1 bittel kevesebb kéket úgy súlyozni hogy ellensúlyozódjon hogy 1 bittel kevesebb...
nyilván ugyanúgy van súlyozva mint a többi szín, és ebből következik hogy nincs igazi szürke
Title: Re: NICK
Post by: ergoGnomik on 2015.October.07. 14:47:48
Még mindig nem olvastad el.

Kék komponens érték (0..3)Kék 3 bit ekvivalens érték (0..7)
00
12
25
37

Digitális kimenet mondjuk  nincs, hülyeséget írtam. RGB van, és ott is van valami súlyozás a kapcsolási rajz szerint.
Title: Re: NICK
Post by: szipucsu on 2015.October.07. 18:26:26
Ettől függetlenül nekem PC-n mindig a barna szín jött elő a legnehezebben, pl. a Painttel. Amikor ki lehet keverni a színeket, akkor nehéz volt belőni, hogy ne legyen túl vöröses. De ez az én problémám. :D
Title: Re: NICK
Post by: endi on 2015.October.07. 19:06:22
Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.

attól hogy 3 bites a konverzió, a forrás még 2 bites...
emulátorban néztem ezeket a szín tekerőket, de a kéket feljebb tekerve a fekete is kék lett... ez így nem súlyozás...
a fő kérdésem viszont hogy ezek szerint az emu nem azt a képet adja mint az igazi EP??
illetve azt se értem miért függhet a kimenetektől a kék súlyozása...
Title: Re: NICK
Post by: IstvanV on 2015.October.07. 19:19:24
attól hogy 3 bites a konverzió, a forrás még 2 bites...
emulátorban néztem ezeket a szín tekerőket, de a kéket feljebb tekerve a fekete is kék lett... ez így nem súlyozás...

Nem a fényerőt kell növelni, hanem csak a kontrasztot, (5/7 - 0.5) / (2/3 - 0.5) = 1.2857... értékre.

Quote
a fő kérdésem viszont hogy ezek szerint az emu nem azt a képet adja mint az igazi EP??
illetve azt se értem miért függhet a kimenetektől a kék súlyozása...

Külön áramkör végzi a D/A konverziót a NICK digitális kimenetéről az RGB és az RF (illetve átalakítással kompozit vagy S-Video) kimeneten. Az előbbi egy egyszerű ellenállásos átalakító, ami nem biztos hogy pontos, az utóbbi pedig egy LM1886 IC, amelynek 3*3 bites digitális RGB bemenete van. Mivel a NICK kék kimenete csak 2 bites, itt így kötötték össze a biteket:
  NICK b0 -> LM1886 b1 (2)
  NICK b1 -> LM1886 b0, b2 (5)
Title: Re: NICK
Post by: endi on 2015.October.07. 19:51:55
ja tényleg a kontrasztot kell :)
bár így se látom hogy több szürke lenne...
na mindegy.
Title: Re: NICK
Post by: endi on 2015.October.17. 00:10:24
amúgy mi akadálya lett volna hardveresen pl olyan karakteres módot csinálni hogy a karakter sorszámától függ a szín 1:1-ben?
tehát 256 szín lehetne egy sorban (persze csak 42, mert karakter, de az is tök jó)
ha meg 4 színű a karaktermód akkor sok színcsoport lehetne, amivel szintén el lehetne érni soronként sok színt...
elég durva játék grafikát lehetett volna így csinálni...
Title: Re: NICK
Post by: lgb on 2015.October.17. 00:22:31
amúgy mi akadálya lett volna hardveresen pl olyan karakteres módot csinálni hogy a karakter sorszámától függ a szín 1:1-ben?

Szerintem a karakteres mod eredeti celja nem ez, hanem szoveg megjelenitese :) Amirol itt szo van, az mar a karakteres mod kreativ felhasznalasa :)
Title: Re: NICK
Post by: endi on 2015.October.17. 00:24:52
Szerintem a karakteres mod eredeti celja nem ez, hanem szoveg megjelenitese :) Amirol itt szo van, az mar a karakteres mod kreativ felhasznalasa :)

hát alapvetően most is ügye van pár szín az alap karakter módban is
aztán kis lpt babrálással még több
de miért ne lehetett volna ezt rendesen kihasználni?
lásd c64, vagy akár a gameboy meg hasonló tile grafika...

persze így is király amit most pl kihozok belőle, és tökre élvezem, sőt, a limitációkat is :)
Title: Re: NICK
Post by: szipucsu on 2015.October.17. 12:49:29
gameboy
Na, azért ne egy játékgéphez hasonlítsuk az EP-t! A C64 még oké.
Title: Re: NICK
Post by: endi on 2015.October.17. 13:25:26
Na, azért ne egy játékgéphez hasonlítsuk az EP-t! A C64 még oké.

az alap gameboy nem sokkal erősebb hw mint a c64, sőt, talán még gyengébb is
Title: Re: NICK
Post by: szipucsu on 2015.October.17. 23:34:40
az alap gameboy nem sokkal erősebb hw mint a c64, sőt, talán még gyengébb is
De akkor is, azt játékhoz tervezték, az EP-t meg nem kifejezetten.
Title: Re: NICK
Post by: endi on 2015.October.17. 23:39:29
De akkor is, azt játékhoz tervezték, az EP-t meg nem kifejezetten.

ok, ez igaz
bár mondjuk a c64-et pont játékra tervezték :)
Title: Re: NICK
Post by: szipucsu on 2015.October.17. 23:51:38
bár mondjuk a c64-et pont játékra tervezték :)
Na igen, és itt felmerül a kérdés, hogy az EP-t mire tervezték. :D Azt hiszem, azt nem sikerült még megfejteni.
Title: Re: NICK
Post by: endi on 2015.October.17. 23:58:40
Na igen, és itt felmerül a kérdés, hogy az EP-t mire tervezték. :D Azt hiszem, azt nem sikerült még megfejteni.

ha jól tudom nem kifejezetten játékra, de azért arra is
mondjuk a karakteres-grafikus módok eléggé hasonlítanak a gameboy-os tile grafikára, úgyhogy igazán megcsinálhatták volna őket jobbra... bár asszem akkoriban az volt a vélekedés hogy a pixeles grafikus mód a jövő, csak hát ügye ahhoz meg nem elég gyors a gép (főleg hogy nincs hw sprite)
Title: Re: NICK
Post by: endi on 2015.October.31. 10:37:47
amúgy létezik más 8 bites gép, aminek van ilyen "egy bájt pixel" módja?
lehet hogy az ep egyedülálló ebben
(más kérdés hogy ilyen felbontással mi értelme van, bár 3d doom-szerű enginhez talán használható lett volna)
Title: Re: NICK
Post by: ergoGnomik on 2015.October.31. 10:44:16
Korabeliek között nem hinném. Modernek, mint például a V6Z80P+ tudhatják. Kérdés, ezt mennyire érdemes 8bitesnek tekinteni, amikor kb. egy proci, némi RAM meg egy FPGA az egész?
Title: Re: NICK
Post by: lgb on 2015.October.31. 13:22:54
Korabeliek között nem hinném. Modernek, mint például a V6Z80P+ tudhatják. Kérdés, ezt mennyire érdemes 8bitesnek tekinteni, amikor kb. egy proci, némi RAM meg egy FPGA az egész?

Attol fugg, mi van az FPGA-ban ... Elvileg a Nick, Dave is kb kapu szinten felepitheto FPGA-ban tehat hivhatjuk "valodi" hardware-nek egy emulatorral szemben (ami teljesen maskepp mukodik persze az implementacio szintjen). Viszont, ha FPGA-ban tesznek hozza nagyon combos co-processorokat, grafikai stb dolgokra, blittert miegymast, akkor nemikepp "nem fair" valoban, mert joval tobbet fog tudni kb, mint akarmelyik 8 bites "klasszikus" konstrukcio ...

Az a baj, hogy ez meg oda vezet, hogy ha lenne ilyen nevezo, akkor elobb ertekelni kell a hw-t is, hogy az mit is csinal, mert hat ja, vegulis egy modern GPU-t is lehet FPGA-ban csinalni (vagy legalabbis vmi hasonlot), es ha azt meghajtod egy 8 bites CPU-val, az nagyon nem fair azert utana az EP-vel osszehasonlitani :)
Title: Re: NICK
Post by: endi on 2015.December.14. 10:54:31
emlékszem az amiga graf processzorát dícsérték, hogy egy 40MHz-s pc-nek felel meg a sebessége, ami abban az időben nagy szó volt

a z80/nick viszonylatban hogy lehet ez? a bias és border soronkénti megváltoztatásáról jutott eszembe :)
Title: Re: NICK
Post by: ergoGnomik on 2015.December.14. 16:54:05
emlékszem az amiga graf processzorát dícsérték, hogy egy 40MHz-s pc-nek felel meg a sebessége, ami abban az időben nagy szó volt

a z80/nick viszonylatban hogy lehet ez? a bias és border soronkénti megváltoztatásáról jutott eszembe :)
Az Amiga esetében ez két dologra vonatkozhatott. Vagy a Blitter kitöltési sebességére, vagy a Copper regiszter írási késleltetésére és sebességére. Mondjuk én inkább az előzőre tippelnék. (Szerinted van bármi ezekkel összemérhető a NICK-ben?)
Title: Re: NICK
Post by: endi on 2015.December.14. 22:37:23
olyasmire gondolok hogy ha a z80 renderelne (állítaná elő a képet), milyen gyorsnak kéne lennie hogy a nick képességét hozza?
persze tudom, ezt így nem lehet teljesen összevetni, de azért érdekes gondolat.
pl a bias vagy border karakterenként megváltoztatható egy sorban, persze biztos a hw korlátozza, kérdés, ha nem korlátozná akkor a z80 milyen sűrűn tudná ezt megtenni?
á hülyeség :)
Title: Re: NICK
Post by: lgb on 2015.December.15. 00:21:37
olyasmire gondolok hogy ha a z80 renderelne (állítaná elő a képet), milyen gyorsnak kéne lennie hogy a nick képességét hozza?
persze tudom, ezt így nem lehet teljesen összevetni, de azért érdekes gondolat.
pl a bias vagy border karakterenként megváltoztatható egy sorban, persze biztos a hw korlátozza, kérdés, ha nem korlátozná akkor a z80 milyen sűrűn tudná ezt megtenni?
á hülyeség :)

Szerintem ez eleg ertelmetlen igy :) Azert is, mert Nick pl az LPB-t beolvassa az elso 8 slot-ban. Z80-ban nem tudnad "hova tenni" azt a 16 byte-ot igazan, hogy utana meg maradjon munkaregiszter is raadasul stb. Ha meg minden alkalommal pixelenkent kene a memoriat turni az LPB miatt is, az persze meg remesen lassabb lenne. A masik, hogy Z80-al tipikusan pl OUT-tal beallitod a bias-t vagy a keret szint ... Az ugye vmi 11 orajelciklus ... Node, ha Z80 lenne a Nick helyen, akkor feltetelezheto lenne, hogy lenne specialis integralt I/O port rajta, amivel meg tudja csinalni rovidebb ido alatt is. Es hasonlok. akkor viszont ez messze nem normal Z80 lenne, tobb szempontbol sem :)

Ha jol tudom, a "slot orajel" (tehat a Nick slot-ok frekvenciaja) 889846Hz. Ha most 4MHz-es Z80-ra nezed, akkor ez azt jelenti, hogy kisse kerekitve 4.5 Z80 CPU t-state megy le, amig a Nick vegez egy slot-tal. Ez kicsivel tobb csak mint a 4 orajelciklus hosszu legrovidebb Z80 utasitasok, hiszen pl a NOP is 4 orajelciklus hosszu. Pl 2 ketszinu pixel modban amig a Z80 egyetlen NOP-ot megcsinal (meg meg egy kb fel ciklus ...), a Nick kozben "kirakott" 16 pixelt :)

Viszont, ha minden igaz, pl a Primo C-nel (vagy a colour primo, nem tudom) volt vmi olyan, hogy egy masodik Z80 volt kotott programmal, ami segitett a kep eloallitasaban, a szinek kornyeken. Vagy valami hasonlo ... Igaz, ott nincs is ennyire szofisztikalt dolog, mint az LPB stb, a felbontas is kisebb, miegymas. Sajna most nem talalom, pedig volt erdekes cikk arrol is, hogy a programja igen specialis, ha jol remlik vmi olyasmi, hogy csak adott hosszusagu utasitasokat lehetett hasznalni benne, hogy az idozites preciz legyen stb, nem egyszeru!
Title: Re: NICK
Post by: endi on 2015.December.15. 05:48:54
na pont erre voltam kíváncsi
szerintem ki hoztad a maxot a témából :)

hanggal egyértelműbb lenne ez amúgy, egy második z80 micsoda király 4 szólamú mod-okat tudott volna lejátszani játék közben :)
Title: Re: NICK
Post by: ergoGnomik on 2015.December.15. 07:23:21
na pont erre voltam kíváncsi
szerintem ki hoztad a maxot a témából :)
Igazából nem hozta ki a maxot. Az akkor lenne meg, ha megírta volna az összes megjelenítési módra a Z80 kódot, ami értelmezi az LPB-t, és ez alapján generálna egy(-két?) portra kiírt bájt sorozato(ka)t, amit be lehetne adagolni a NICK után lévő elektronikának, és abból előállhatna elvileg a NICK által létrehozottal egyenértékű kép. Ekkor már csak vissza kellene számolni a T-ciklusok alapján a szükséges órajelet, és készen is lenne. Te endi, nem akarnád megcsinálni? :D
Title: Re: NICK
Post by: endi on 2015.December.15. 07:30:36
haha :)
na igen.
de most hirtelen még őrültebb ötlet jutott eszembe: a rem1 és rem2. az vajon milyen kép előállítására lenne alkalmas? :D
Title: Re: NICK
Post by: IstvanV on 2015.December.15. 10:16:23
de most hirtelen még őrültebb ötlet jutott eszembe: a rem1 és rem2. az vajon milyen kép előállítására lenne alkalmas? :D

A relék lassúsága miatt nem igazán lenne alkalmas ilyen célra. Egyéb (nem NICK) portokat pedig a 4 MHz-es Z80 3.56 karakter felbontással tud írni OUTI utasításokkal, az OUT (C), r felbontása pedig 2.67 karakter.
Title: Re: NICK
Post by: ergoGnomik on 2015.December.17. 11:55:01
Viszont lehetne zenéknél plusz két béna hangcsatornaként használni őket. A relék csattogása, mint ritmushangszer. :ds_icon_cheesygrin:
Title: Re: NICK
Post by: endi on 2015.December.17. 11:57:42
Viszont lehetne zenéknél plusz két béna hangcsatornaként használni őket. A relék csattogása, mint ritmushangszer. :ds_icon_cheesygrin:

hm vagy a sztereo hangkimenet mint kép előállítási forrás? :)
Title: Re: NICK
Post by: endi on 2015.December.19. 13:41:25
meg megint a hülye ötleteim! :)
mibe került volna azt megcsinálni hogy a nick egy D/A-ra kiadja mondjuk minden lpt sor első byte-ját?
Title: Re: NICK
Post by: balagesz on 2015.December.19. 16:02:58
mibe került volna azt megcsinálni hogy a nick egy D/A-ra kiadja mondjuk minden lpt sor első byte-ját?

Kellett volna hozzá "sok" plusz IC láb. De ez mire lett volna jó? :-D Az LPT sorok első BYTE-ja az, hogy az adott LPB hány rasztersort ír le. Ennek "analógban" milyen jelentősége van? Vagy esetleg az első szín-BYTE-ra gondolsz? Vagy a rasztersorban az LPT valamelyik mutatója által beolvasott első memóriacím tartalmára? Lehetett volna vele digitális hangmintát lejátszani max. 15.625 KHz-cel? :)

De ha már NICK: én meg arra lennék kíváncsi, hogy a FIXBIAS 7-es bitje, amivel most a belső hangszórót lehet kapcsolni, azt eredetileg vajon milyen célra szánták? Logikailag abszolút nem illik hozzá a jelenlegi funkció.
Title: Re: NICK
Post by: Zozosoft on 2015.December.19. 16:11:31
De ha már NICK: én meg arra lennék kíváncsi, hogy a FIXBIAS 7-es bitje, amivel most a belső hangszórót lehet kapcsolni, azt eredetileg vajon milyen célra szánták? Logikailag abszolút nem illik hozzá a jelenlegi funkció.
A külső színbement kikapcsolására. Még a 84-es leírásokban is így van.
Title: Re: NICK
Post by: endi on 2015.December.19. 16:14:45
ja igen, úgy gondoltam hogy lenne egy byte az lpt-ben ami a digi hang lenne :)
15khz az simán jó lehetett volna sokmindenre
Title: Re: NICK
Post by: Zozosoft on 2015.December.19. 16:20:59
ja igen, úgy gondoltam hogy lenne egy byte az lpt-ben ami a digi hang lenne :)
15khz az simán jó lehetett volna sokmindenre
Csak bazi hosszú LPT kéne, hogy értelme legyen :-D
Title: Re: NICK
Post by: balagesz on 2015.December.19. 17:00:51
A külső színbement kikapcsolására. Még a 84-es leírásokban is így van.

Aha. Az már ideillik. Viszont ezt hogy akarták kivitelezni? Lett volna az ECx/EXTC bemenetek előtt valami puffer, amit ez a jel tilt? Mert ezt az egész tiltósdit meg lehetett volna csinálni a NICK-en belül, nem kellene hozzá ezt a jelet kihozni a külvilágba. (Persze nem tudhatjuk, hogy a csipen belül nem fogyott-e el az erőforrás. Ha igazak a mesék, a NICK is valamilyen szinten "programozott" logika.)

ja igen, úgy gondoltam hogy lenne egy byte az lpt-ben ami a digi hang lenne :)
15khz az simán jó lehetett volna sokmindenre

Az már igaz. De ha jobban végiggondolom, az AMIGA volt az első olyan gép, aminél ilyen volt a hanggenerálás. Sanszos, hogy előtte nem is gondolkodott senki ilyenen, mivel:

Csak bazi hosszú LPT kéne, hogy értelme legyen :-D

Az LPT lehet relatíve rövid is, a benne levő D/A-ra szánt adatok csak egy rövid puffernek kellenek. Azt meg töltögetheti a CPU "ritkábban". De összességében azért nem árt ehhez jó sok memória, meg jó gyors CPU. Ebből itt mi van meg? :) (Na jó, a memória az határeset... :-D )
Title: Re: NICK
Post by: lgb on 2015.December.19. 17:16:21
Csak bazi hosszú LPT kéne, hogy értelme legyen :-D

A digi hang kapcsan a leendo (ha egyszer haladni tudok a VHDL-el tovabb, es lesz FPGA board-om is hozza ...) project kapcsan en mar gondolkodtam: ugye minden sorban az utolso 3 nick slot az "semmire" nem kell, jobban mondva, akkor horizontalis visszafutas van generalva meg DRAM refresh. Ez (DRAM refresh) azonban mondjuk egy FPGA implementacional nem feltetlen kell, tehat minden sorban lenne 3 nick slot "szabad", es mivel egy nick slotban 2 byte olvashato, ez 6 byte. Nem szamoltam utana, de ezzel, meg hogy VSYNC mod alatt sem feltetlen kell nagyon 2 byte semmire, az is felhasznalhato. Es akkor LD1, LD2 mellett lehetne pl egy LD3, ami egy pointer a memoriaba, ahonnan a digi hangot olvassa. Tehat nem magaban az LPT-ben lenne azert ... Hogy igy mennyi sampling rate jonne ki, annak nem szamoltam mondjuk utana :) Hatranya, hogy akkor a VRAM-ban lehet csak a hangadat is ... Bar tulkeppen, ha mar FPGA, akkor az LPT cim, LD1, LD2 (es az LD3 ...) -ra is lehetne egy beallitas, hogy a memoria melyik 64K-s "szeletet" tekintse "VRAM"-nak az adott jellegu olvasas kapcsan.

Arrol nem is beszelve, hogy pl lehetne dupla annyi byte-ot olvasni egy slot alatt opcionalisan a Nick2-nek, akar olyan aron is, hogy 16 biten eri el a RAM-ot igaz akkor ehhez a modhoz aligned kell hogy legyen a megfelelo cim. Igy tobb adat jutna digire, nameg a felbontas is novelheto lenne ha csak a videot nezzuk, ami pl 256 szinu modban nem (sem) olyan hatrany :)

Mondjuk ez mar kisse "futurisztikus" EP nextGen otlet lehetne max :)
Title: Re: NICK
Post by: IstvanV on 2015.December.19. 17:39:19
Hogy igy mennyi sampling rate jonne ki, annak nem szamoltam mondjuk utana :)

15611.3336 sor/másodperc * 6 byte = 93668 Hz maximum (8 bites mono hang)

Egyéb lehetőségek:

46834 Hz sztereó 8 bites PCM (vagy 1 csatorna és 16 bites), 6 byte / sor
15611.3336 Hz 4 csatornás mod lejátszás (I/O portokon állítható paraméterekkel), 4 byte / sor
Title: Re: NICK
Post by: lgb on 2015.December.19. 21:01:40
Aztan meg a VSYNC hozza, ahol nem csak az utolso 3 slot hasznalhato :) Bar amugy is kene egy FIFO mar, mert ugye nem igazan egyenletesen "jonnenek" a byte-ok :) Ha az ember radob meg egy hw mp3 dekodert, akkor PCM mellett lehetne "streamlni" a nick altal a memoriabol mp3-at dekodolas celjaira. Olyan szempontbol meg max config kerdese hogy az erkezo stream az PCM izebize, vagy mp3 bitstream stb. Na, ezek melle meg elvenni egy "kis savszelesseget" (a digis olvasos megoldashoz kepest) ami a Nick+ belso RAM-jat tolti, onnan tudna sprite-okat megjelenti, amit azonban igy minden frame soran (attol fugg mennyi sprite adat kell ...) frissit is, es meg kevesbe boritja fel az idozitest, mintha a  sprite-ok miatt kene ugye vmi extra eleres az std 2 byte read / nick slot megoldashoz kepest. Es maris eszrevettem, hogy bilibe log a kezem, es felebredtem :)
Title: Re: NICK
Post by: endi on 2015.December.19. 22:37:41
igazából engem olyan szempontból érdekelnek ezek a kérdések, hogy annak idején lett volna-e lehetőség ilyesmit csinálni az EP készítőinek, mennyi plusz költség lett volna stb...
Title: Re: NICK
Post by: lgb on 2015.December.19. 23:16:22
igazából engem olyan szempontból érdekelnek ezek a kérdések, hogy annak idején lett volna-e lehetőség ilyesmit csinálni az EP készítőinek, mennyi plusz költség lett volna stb...

A digi hang hw-bol kb temara gondolsz? Szerintem akkoriban ez nem volt annyira megszokott tema meg, mint ma azt gondoljuk ... Nem is tudom, volt-e olyan (biztos van amugy) 8 bites gep, ahol ilyen "DMA szeruen" tud hangot lejatszani vmi, es nem a CPU-nak kell nyomnia allandoan. A sprite kerdes erdekesebb, nekem az a gyanum, hogy gondoltak ok arra is, elvegre az EXTCOL bemenetek is talan pont vmi hasonlo kiegeszito miatt kerulhettek anno szoba. Valoszinu, on-chip (magan a Nick-en) tul bonyolult lett volna. Ne felejtsuk, hogy a C64 VIC-II-jenek vmi 2/3 reszet a lapkanak a spritekezeles viszi el ... Az, hogy a Nick esetleg "szabadidejeben" digi lejatszas stb is, az meg inkabb utogondolas a reszemrol (lasd fentebb), nomeg valodi Nick/EP-n amugy se szabad az utolso harom nick slot, mivel DRAM refresh-el ugykodik ... A hanggal kapcsolatos reszek meg amugy is inkabb jellemzoen a Dave-ben vannak, ugye :)
Title: Re: NICK
Post by: Zozosoft on 2015.December.20. 07:44:05
Nem is tudom, volt-e olyan (biztos van amugy) 8 bites gep, ahol ilyen "DMA szeruen" tud hangot lejatszani vmi,
Én kizárt dolognak tartom, nagyon meglepődnék, ha lenne ilyen.

Quote
A sprite kerdes erdekesebb, nekem az a gyanum, hogy gondoltak ok arra is, elvegre az EXTCOL bemenetek is talan pont vmi hasonlo kiegeszito miatt kerulhettek anno szoba.
EXOS 2.1-be már be is került a SPRITE változó.
Title: Re: NICK
Post by: geco 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.
Title: Re: NICK
Post by: endi 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?
Title: Re: NICK
Post by: lgb 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 ...
Title: Re: NICK
Post by: Zozosoft 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.
Title: Re: NICK
Post by: Zozosoft 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 :-)
Title: Re: NICK
Post by: endi 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 :)
Title: Re: NICK
Post by: ergoGnomik 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?
Title: Re: NICK
Post by: lgb 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.
Title: Re: NICK
Post by: endi 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

Title: Re: NICK
Post by: lgb 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 ...
Title: Re: NICK
Post by: endi 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)
Title: Re: NICK
Post by: IstvanV 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.
Title: Re: NICK
Post by: endi 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.
Title: Re: NICK
Post by: balagesz 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.
Title: Re: NICK
Post by: IstvanV 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.
Title: Re: NICK
Post by: lgb on 2016.March.03. 09:44:57
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.

:) Rajottem en is kozben, csak most epp azt neztem hogy kicsit el van bonyolitva ez nalam, atnezem az egeszet inkabb.
Title: Re: NICK
Post by: IstvanV on 2016.March.03. 10:44:20
Még egy kisebb hiba a NICK emulációban: a margókat a valódi hardver nem < és > műveletekkel teszteli (ilyen "bonyolult" aritmetikát nem használtak a tervezésnél, és más gépekben sem, pl. a Plus/4-es TED-ben, stb.), hanem csak az egyenlőséget figyeli:
- ha az aktuális slot == jobb margó, akkor a képernyő inaktív (keret) állapotú lesz (akkor is, ha a bal margó értéke azonos)
- egyébként ha az aktuális slot == bal margó, akkor a képernyő aktív állapotba kapcsol
Ennek általában nincs nagy jelentősége, de előfordulhatnak olyan programok, amelyek "szabálytalan" margókat használnak. A 0-7. és 54-56. slot alatt természetesen nem lehet az LD1 és LD2 címekről olvasni, de a számlálókat a NICK ilyenkor is növeli ha a kép nem keret. DRAM frissítéskor a HBLANK előtt az utolsó olvasott video byte ismétlődik (ezt az ep128emu nem tudja, az "érvénytelen" 47. karaktert egyszerűen 0. paletta színnel tölti fel).

További NICK érdekességek:

Az "érvénytelen" 6-os video mód valójában olyan "karakteres" mód, ahol az LD2 cím mindig FFFFh. Ez ritkán hasznos, de könnyen emulálható.

Az LSBALT, MSBALT, ALTIND0, és ALTIND1 minden video módban működik, akkor is, ha a használatuknak nem sok értelme van. Ezek a paletta színekkel végeznek OR műveletet ha az adott bit 1, aminek azonban nincs látható hatása attribútum és 256 színű módokban. Az ALTIND0/1 mindig az LD1 címről olvasott byte-ot használja, és nem törli a bite(ke)t. Az LSBALT/MSBALT mindig a pixel byte-ot használja, és mindig törli a 0. és/vagy 7. bitet.

Az attribútum mód lényege, hogy a paletta szín 0. bitje alapján választ "papír" vagy "tinta" színt, a többi bitet figyelmen kívül hagyja, és 256 színű módban nem működik (ilyenkor gyakorlatilag 256 színű LPIXEL mód az eredmény, az LD1 helyett LD2 címről olvasva). A 4 és 16 színű attribútum mód ezért csak a felbontást csökkenti, de nem eredményez több színt. Az LSBALT stb. a paletta szín attribútum konverzió előtti értékét módosítja, így ezek sem módosítják láthatóan a színeket, az LSBALT és MSBALT azonban ilyenkor is törli a pixel byte 0. vagy 7. bitjét.

A fentiek alapján tehát ez az algoritmus határozza meg a kimeneti színt, ennek alapján minden lehetséges mód definiált:
- ha LSBALT vagy MSBALT, akkor a pixel byte 0. vagy 7. bitjének a törlése
- paletta szín választása a pixel byte alapján (2, 4, vagy 16 színű mód), felbontás csökkentése ha nem 2 színű mód
- ha ALTIND0 vagy ALTIND1, akkor a paletta szín módosítása az LD1 byte megfelelő bitje alapján (OR 2 vagy 4)
- ha LSBALT vagy MSBALT, akkor a paletta szín módosítása az eredeti pixel byte megfelelő bitje alapján (OR 2 vagy 4)
- ha ATTRIBUTE mód, akkor a paletta szín 0. bitje alapján (a többi elveszik) PAPER vagy INK szín választása
- ha 256 színű mód, akkor a fentiek nem számítanak, kimeneti szín = pixel byte (de törölt 0/7. bittel ha LSBALT/MSBALT)

A VSYNC módban csak két lehetséges kimenet van. Ha a kép aktív (nem keret), akkor szinkron (negatív fényesség), egyébként VBLANK (fekete szint, burst jel tiltva).
Title: Re: NICK
Post by: lgb on 2016.March.03. 11:13:55
:) Hat koszi, hogy atnezted, bar oszinten szolva a nick emulacios resz az olyan ami tenyleg kb "gyors hack" allapotaban leledzik ... Konkretan azt es ugy irtam bele, amit lattam h adott program hasznal, igazabol nem arra ment ki, hogy egy normalis nick emulacio legyen, ahogy meg kene kozeliteni. Mivel a celom az volt, hogy minnel elobb csinaljon valamit legalabb, igy az egeszet ki kene dobni, es nullarol normalisan ujrairni, ezzel tisztaban vagyok. Eleve vannak ott komolyabb gondok is, a vsync, interlace miegymas. Majd egyszer :)
Title: Re: NICK
Post by: IstvanV on 2016.March.03. 12:13:52
Eleve vannak ott komolyabb gondok is, a vsync, interlace miegymas.

Ezeket viszonylag egyszerűen meg lehet oldani, ha nem fontos, hogy a nagyon "szabálytalan" LPT is valódi TV-hez hasonlóan jelenjen meg (lehetséges például a vízszintes szinkront "elrontani" megfelelő margó beállításokkal, ezzel Endi próbálkozott valamelyik régebbi demóban). Az alábbiakkal elfogadható minőségű emuláció érhető el:
- ha egy sor VSYNC módú, akkor az egész sor fekete (a keret is)
- ha a sor elég hosszú része (pl. legalább 20 karakter) nem keret, akkor az a sor VSYNC impulzusnak számít
- egy lehetséges megoldás szinkronizációra: egy számláló növelése minden sorban, és ha elér egy bizonyos maximális értéket, vagy ha egyenlő vagy nagyobb egy minimális értéknél és az adott sor VSYNC, akkor az függőleges visszafutást eredményez (számláló nullázása). A számláló egy bizonyos értéke (312 - látható magasság - 3) nullára állítja az aktuálisan rajzolt sort a képernyőn, ami egyébként egy másik számláló amely ha eléri a látható magasságot, akkor a képernyő frissítését eredményezi (a további sorok az újraindításig nem láthatóak és elvesznek). Így - megfelelő minimális és maximális sor számot választva - minden lehetséges LPT hosszúságnál van használható kimenet a teljes képernyőn, a függőleges frekvencia nem lehet nagyon alacsony vagy magas, és szabálytalan LPT-vel a valódi TV-hez hasonlóan "fut" a kép
- interlace: ha a VSYNC kezdete a sor közepéhez van közelebb, akkor a következő képet fél sorral (illetve 2x nagyításnál 1 sorral) felfelé kell eltolni
Title: Re: NICK
Post by: lgb on 2016.March.03. 22:55:45
Amugy, mar amikor 2000 kornyeken :) csak sajat magam mit sem tudva EP kozossegrol stb, akartam irni emulatort mert nem volt Linux ala :) - vagy en nem tudtam rola -, akkor olvasva a Nick leirasat, az az erzesem tamadt, hogy ez az ALTIND, MSBALT, stb dolgok csak hivatlosan vannak egy-egy videomodhoz "dedikalva", attol csinaljak a feladatukat a tobbi modban is, fuggetlenul attol, hogy van-e tul sok ertelme ott, vagy nincs. Eleve, ezt kizarni, tobb "tranyoba" kerult volna a Nick-en belul, mint hagyni, es csak azt dokmentalni, amire terveztek, es eleg vilagosnak tunt elsore is. En amit osszeemulalgatok _jelenleg_ az viszont nem ebben a filozofiaban irodott, ez igen, hiba is, de ugye az elejen volt, hogy XYZ programnak kellett egy adott videomod, gyorsan beleiram, aztan kiderult kell masik is, stb, igy aztan kialakult, hogy nem globalisan vannak kezelve, ami persze hiba. Ezert is mondtam, hogy ennek szellemeben ujra fogom irni majd az egesz Nick reszt, az teljesen biztos.

Az interlace az nekem mindig kerdes :) Tudom, errol mar volt szo, de tovabbra sem ertem, hogy oszinte legyek :-/ Eleve ez a fel sor hogy jon ki? A PAL signal eseten vmi 312 es fel sor (?) vagy hasonlo felkepenkent, es minden paros v paratlan sor adott half frame-re nezve, tehat 1 sor, miert "fel" akkor? Masik, amirol szerintem mar volt szo, de akkor sem ertettem :) Ha most nem kell interlaced, legtobb LPT-ben egy VSYNC blokk van nyilvan stb. Azt nem tudom, hogy mas gepek video megoldasai (pl TED, VIC-II) is igy csinalja-e, hogy a vsync tok ugyanaz. De ha tok ugyanaz, es nem tolja el egy fel (vagy egy???) sorral, akkor ugye "fesus" lesz a kep, hiszen valahova soha nem jut informacio, ami csak akkor jutna, ha nem interlaced eseten is lenne ket kulon vsync blokk ahhoz hogy mindket "half frame-re" jusson ugyanaz az info. Ok, lehet egy TV ezt elkeni, foleg egy CRT stb. Nade emulatorban ugye ez latszana azert eleg jol. Mert akkor atlag egy VSYNC blokkos LPT-vel ugy nezne ki, hogy egy sor megjelenites, egy sor ures, egy sor megjelenites egy sor ures stb, es csak ha interlaced-et hasznalo LPT van (amiben van ez a "fel" soros dolog) akkor jutna info minden sorba ... Na ezt keptelen vagyok felfogni.
Title: Re: NICK
Post by: lgb on 2016.March.03. 23:31:41
https://github.com/lgblgblgb/xep128/blob/master/doc/vinttest.asm

Oke, kicsit bena teszt program :) Most hasonlo kepet ad ep128emu es Xep128. Itt lathato, hogy milyen a INT1 bit szint Dave-rol olvasva (fekete/zold), illetve, hogy az interrupt mikor kovetkezik be (kek sav), ami ugye az LPB vegen ahol INT bit be van allitva (felteve, ha utana levo LPB-ben INT bit nincs ismet beallitva, mert akkor nem lesz "éle" a signalnak ami kell). Persze, talan anno pont IstvanV tollabol mar olvastam, hogy igy a vegen, stb, de erdekes igy latni "szemmel" is. Gondolom valodi EP-n is igy kene kineznie, foleg, ha ep128emu-ban igy nez ki :)
Title: Re: NICK
Post by: Zozosoft on 2016.March.04. 09:52:28
Hamár itt tartunk...
István te mit tippelsz a külső színbemenet működéséről? Én azt feltételezem, hogy 2 színű felbontásban is elérhető a 16 szín.
Hiszen csak azért nem érhető el több szín, mert nem tud annyi adatot beolvasni.
Viszont jelenleg is ott vannak azok a módosító bitek, amikkel Text 80-ban (ami lényegében hires 2), ott a 8 szín.
Sokkal bonyolultabb lenne azt megcsinálni, hogy mód függően menjen, mint fixen használni a 4 bites adatot.

A másik kérdés dolog, hogy több színű módban vajon csökken a külső bemenet felbontása is, vagy ilyenkor is "hires 2" pixelenként elvégzi a műveletet?
Title: Re: NICK
Post by: lgb on 2016.March.04. 10:07:04
Zozo, bar nem engem kerdeztel, es nyilvan nem is tudom, mi az igazsag :) de eszembe jutott, hogy azert ezt nem lenne tul nehez tesztelni, elvileg, egy valodi EP-n. Ha jol tippelek, a busz boviton eleg lenne az EXTC-t fixen (?) a foldre kotni (mivel elvileg alacsony aktiv), a biztonsag kedveert pl ellenallason at. Ezek utan a 4 EC szin info-t hol a +5V-ra, haol a GND-re kotogetni mas-mas sorrendben, ezzel kulonbozo szineket "betaplalva" igy konstans modon kb egy darab drottal (ismet, lehet azert a biztonsag kedveert egy ellenallason at) ;-) Lehet en latom rosszul, de mar ekkor eleve kikserletezheto lenne, mi tortenik, pl ket szinu mod LPT, es eljatszani az EC bemenetekkel hogy mit latsz a kepernyon.  Persze gondolva meg a 80h port bit 5/6 ertekere is azert. Elvileg talan a felbontas is kikiserletezheto lenne, ha az EXTC fix kotes helyett a pixel clock-ot kapja (hmm vagy annak felet? na most ebbe belekeveredtem, de az elv gondolom ertheto, meg lehetne probalkozni mas frekvenciakkal is esetleg ha valtoztatni kell a minta "surusseget"), a cel az lenne, hogy akkor egy EP "elemi" pixel idejere a kulso EC bemeneteken levo szin, egy idejere meg nem (nincs engedlyezve) stb minta alakulna ki a kepernyon, vagy eppen nem alakulna, ha az adott LPB szerinti felbontas ott mondjuk kisebb a video (lpixel?) es vagy colour mode miatt.

Ez most azert jutott eszembe, mert minden extra bonyi cucc nelkul elvileg ezt tesztelni is lehetne, igaz ilyen konstans kulso szin, vagy max egyszeru "minta" (negyszogjebol eloallo pl) esetere. Nyilvan normalis felhasznalasra erre vmi  olyasmit kene kotni mint egy CPLD, FPGA vagy kelloen gyors MCU stb :) Bar mar a konstans dolog is erdekes lehet.

Tovabba: erdekes lenne tudni, hogy pl 256 szinu modban amikor egy pixel "nagy" es palettat sem hasznal, mi tortenik az EC bemenetek hatasra. Akkor is lehet-e az EC bemenetekkel finom (hires 2-nek megfelelo) "rajzolatot" csinalni, illetve akkor az EC-n kodolt 16 szin mi a fene lesz, kozvetlenul paletta nelkul mert a 256 szinu mod azt hasznalja, vagy a 256 szinu mod "alatta" marad paletta nelkul, de az EC bementekkel kodolt szin az LPB-ben levo palettat hasznalja kozben?
Title: Re: NICK
Post by: IstvanV on 2016.March.04. 11:07:54
En amit osszeemulalgatok _jelenleg_ az viszont nem ebben a filozofiaban irodott, ez igen, hiba is, de ugye az elejen volt, hogy XYZ programnak kellett egy adott videomod, gyorsan beleiram, aztan kiderult kell masik is, stb, igy aztan kialakult, hogy nem globalisan vannak kezelve, ami persze hiba.

Én úgy oldottam meg, hogy a "szabványos" módokhoz külön (optimalizált) renderert írtam, és ezeken kívül van egy általános megvalósítás (NickRenderer_Generic) ami mind az 512 lehetséges szín/mód kombinációt tudja, de lassabb, és ez kezeli a nem dokumentált módokat:
Code: C++
  1.   DECLARE_RENDERER(NickRenderer_Blank);
  2.   DECLARE_RENDERER(NickRenderer_Generic);
  3.   DECLARE_RENDERER(NickRenderer_PIXEL_2);
  4.   DECLARE_RENDERER(NickRenderer_PIXEL_2_LSBALT);
  5.   DECLARE_RENDERER(NickRenderer_PIXEL_2_MSBALT);
  6.   DECLARE_RENDERER(NickRenderer_PIXEL_2_LSBALT_MSBALT);
  7.   DECLARE_RENDERER(NickRenderer_PIXEL_4);
  8.   DECLARE_RENDERER(NickRenderer_PIXEL_4_LSBALT);
  9.   DECLARE_RENDERER(NickRenderer_PIXEL_16);
  10.   DECLARE_RENDERER(NickRenderer_PIXEL_256);
  11.   DECLARE_RENDERER(NickRenderer_ATTRIBUTE);
  12.   DECLARE_RENDERER(NickRenderer_CH256_2);
  13.   DECLARE_RENDERER(NickRenderer_CH256_4);
  14.   DECLARE_RENDERER(NickRenderer_CH256_16);
  15.   DECLARE_RENDERER(NickRenderer_CH256_256);
  16.   DECLARE_RENDERER(NickRenderer_CH128_2);
  17.   DECLARE_RENDERER(NickRenderer_CH128_2_ALTIND1);
  18.   DECLARE_RENDERER(NickRenderer_CH128_4);
  19.   DECLARE_RENDERER(NickRenderer_CH128_16);
  20.   DECLARE_RENDERER(NickRenderer_CH128_256);
  21.   DECLARE_RENDERER(NickRenderer_CH64_2);
  22.   DECLARE_RENDERER(NickRenderer_CH64_2_ALTIND0);
  23.   DECLARE_RENDERER(NickRenderer_CH64_2_ALTIND1);
  24.   DECLARE_RENDERER(NickRenderer_CH64_2_ALTIND0_ALTIND1);
  25.   DECLARE_RENDERER(NickRenderer_CH64_4);
  26.   DECLARE_RENDERER(NickRenderer_CH64_4_ALTIND0);
  27.   DECLARE_RENDERER(NickRenderer_CH64_16);
  28.   DECLARE_RENDERER(NickRenderer_CH64_256);
  29.   DECLARE_RENDERER(NickRenderer_LPIXEL_2);
  30.   DECLARE_RENDERER(NickRenderer_LPIXEL_2_LSBALT);
  31.   DECLARE_RENDERER(NickRenderer_LPIXEL_2_MSBALT);
  32.   DECLARE_RENDERER(NickRenderer_LPIXEL_2_LSBALT_MSBALT);
  33.   DECLARE_RENDERER(NickRenderer_LPIXEL_4);
  34.   DECLARE_RENDERER(NickRenderer_LPIXEL_4_LSBALT);
  35.   DECLARE_RENDERER(NickRenderer_LPIXEL_16);
  36.   DECLARE_RENDERER(NickRenderer_LPIXEL_256);

Quote
Az interlace az nekem mindig kerdes :) Tudom, errol mar volt szo, de tovabbra sem ertem, hogy oszinte legyek :-/ Eleve ez a fel sor hogy jon ki? A PAL signal eseten vmi 312 es fel sor (?) vagy hasonlo felkepenkent, es minden paros v paratlan sor adott half frame-re nezve, tehat 1 sor, miert "fel" akkor? Masik, amirol szerintem mar volt szo, de akkor sem ertettem :)

Fél sor a 312 soros felbontáshoz képest. Mivel CRT-n az elektronsugár folyamatosan mozog lefelé, sor közben is (azaz a függőleges eltérítés nem "lépcsős", hanem fűrészjel), ezért a VSYNC nem egész sorral való késleltetése lehetővé teszi a teljes kép eltolását egy sor tört részével. Az könnyen érthető, hogy ha a VSYNC egy sorral későbbre kerül az LPT-ben, akkor a kép elmozdul egy sorral felfelé, mert egy sorral kevesebb lesz a távolság a VSYNC kezdete és az eredetileg első látható sor között. Azonban a fentiek miatt a VSYNC impulzus egy sornál kisebb mértékű eltolása (a margók állításával) is elmozdítja a képet az időzítésnek megfelelően a sor töredékével. Ha ilyen módon minden második 312 sor/50 Hz-es kép el van tolva fél sorral, akkor azzal kétszeres felbontás illúzióját lehet elérni egy nagyobb felbontású kép páros/páratlan sorait felváltva megjelenítve.

Ha nem fontos valamilyen "deinterlace" algoritmus megvalósítása, akkor elég, ha az emulátor annyit tud, hogy a VSYNC-et bekapcsoló sorban a bal margó pozíciójának megfelelően elmozdítja a következő képet felfelé, amint az alábbi - minden sor végén futó - példában látható (ez nem az emulátorból van, és lehet, hogy bugos, illetve bizonyos részeit jobban is meg lehetett volna oldani, de a működési elv hasonló):
Code: C++
  1. #define MIN_FRAME_LINES         292
  2. #define MAX_FRAME_LINES         342
  3. #define SCREEN_HEIGHT           288
  4.  
  5. static int      vsync_line = 0;
  6. static int      screen_line = 0;
  7. static int      interlace = 0;
  8.  
  9. // ...
  10.  
  11. {
  12.   int     threshold = MAX_FRAME_LINES;
  13.   int     il_flag = 0;
  14.   if (video_mode == 0 && (right_margin - left_margin) >= 20) {
  15.     threshold = MIN_FRAME_LINES;
  16.     il_flag = (left_margin >= 19);
  17.   }
  18.   // 1 extra line for interlace
  19.   if (screen_line <= SCREEN_HEIGHT) {
  20.     draw_line(screen_line);
  21.     if (screen_line == SCREEN_HEIGHT)
  22.       draw_frame(interlace);
  23.   }
  24.   screen_line++;
  25.   if (++vsync_line == (312 - SCREEN_HEIGHT - 4))
  26.     screen_line = 0;
  27.   if (vsync_line >= threshold) {
  28.     vsync_line = 0;
  29.     interlace = il_flag;
  30.   }
  31. }
A draw_frame() itt a 289 sor magasságú pufferből jeleníti meg a képet, ha az interlace 0, akkor egyszerűen az első 288 sort 576-ra nagyítva, egyébként a nagyítás után egy sorral eltolja a képet felfelé (ezért kell a 289. sor).

Quote
Nade emulatorban ugye ez latszana azert eleg jol. Mert akkor atlag egy VSYNC blokkos LPT-vel ugy nezne ki, hogy egy sor megjelenites, egy sor ures, egy sor megjelenites egy sor ures stb

A legegyszerűbb megoldás minden sort ismételni (double scan), az interlace effektus ilyenkor is látható marad, csak kevésbé éles a kép. De emulátorokban gyakran választható a "fésűs" mód is, vagy akár a kettő közötti átmenet (az "üres" sorokba az alsó és a felső sor átlaga kerül valamilyen 0 és 1 közötti értékkel szorozva).
Title: Re: NICK
Post by: Zozosoft on 2016.March.04. 14:28:04
Ha jol tippelek, a busz boviton eleg lenne az EXTC-t fixen (?) a foldre kotni (mivel elvileg alacsony aktiv), a biztonsag kedveert pl ellenallason at. Ezek utan a 4 EC szin info-t hol a +5V-ra, haol a GND-re kotogetni mas-mas sorrendben, ezzel kulonbozo szineket "betaplalva"
Arra gondoltam, hogy rá kéne rakni egy számlálót a video clockra, és annak a kimenetét bevinni EC-nek.
Title: Re: NICK
Post by: lgb on 2016.March.04. 15:22:04
Arra gondoltam, hogy rá kéne rakni egy számlálót a video clockra, és annak a kimenetét bevinni EC-nek.

Igen, ha mar normalisabbat akarsz :) De ugy tippelem hogy vegulis max 5 szem drottal :) a teszt mar elvegezheto, az EXTC fixen foldre, negy masikkal meg EC-ket hol GND hol VCC. Max ugye csak arra jo hogy az egesz aktiv screen resz egyben valtozik :) De arra eleg, hogy pl megnezd, 2 szintu pixel LPB eseten mi tortenik ha kulonbozo EC ertekeket viszel be a negy drottal :) Ha minta stb kell, akkor mar persze egyszeru esetben is szinkronizalni kell az EC valtozasokat a video clock-hoz gondolom, mondjuk ha van egy programozhato frekvenciaoszto akkor "allithato" hogy milyen szeles "csikokat" hozzon letre a kepernyon. Vagy egy binaris counter ja (ami a video clock-al van meghajtva), vegulis, aztan hol melyik kimentet kotod az EXTC-re ... HCT7493 vagy vmi hasonlo? Csak tipp, gyakorlatban sajna kevesbe ertek hozza :-/

Amugy a vicces, hogy lehet, ezt a "drotos tesztet" se probalta soha senki? :) Szoval par szal drottal is az elso lenne, hogy valaki kihasznalja a feature-t, meg ha nem is tul ertelmes celra ebben a formaban? :) Durva ...

Az mar csak hab a tortan, hogy video clock-rol szamlalo binaris, ami ramenne egy eprom cim labaira, adatbuszrol 5 bit (EC 4, EXTC is otodiknek hogy allithato legyen hol jelenjen meg) az EP fele. Elvileg ezzel megfelelo beegetett EPROM adatokkal maris minta jelenne meg vagy vmi hasonlo ... Ha eleg nagy az EPROM :) lehet nem artana osztani a video clock-ot elotte. Ha meg EPROM helyere RAM, foleg ha dual port RAM :) akkor masik portjarol irva az EP felol meg durvabb, mert EP-n par szegmensnek beteve, siman allithato mi jelenjen meg :-) Na persze ez meg nem sprite igy, de biztos vicces. Valahol ... Hmm, felteve ha eleg gyors az EPROM/RAM olvasas az adott frekvencian, gondolom ...
Title: Re: NICK
Post by: lgb on 2016.March.04. 17:35:49
Én úgy oldottam meg, hogy a "szabványos" módokhoz külön (optimalizált) renderert írtam, és ezeken kívül van egy általános megvalósítás (NickRenderer_Generic) ami mind az 512 lehetséges szín/mód kombinációt tudja, de lassabb, és ez kezeli a nem dokumentált módokat:

Hmmm, erdekes otlet :) A modok nekem is tablazatban vannak, csak ugye pl PIXEL2 az egyben ha *BALT, ha nem :) Ezt kulon venni elvileg tenyleg gyorsabb, mar nem tudom mennyi kulonbseget jelent ... Mondjuk ha en majd aritom ugy is, a generic helyett csinalnek inkabb "generic attribute", stb implementaciokat, hogy azert ne kelljen ott is vegignezni modonkent,
hogy most melyik, vagy most meg hibaba esek, hogy emiatt aggodok, amikor mondjuk egy switch/case cuccos ami valszeg ugyis jump table a forditas utan asm szinten ... ?

Quote
Code: C++
  1.   DECLARE_RENDERER(NickRenderer_PIXEL_4_LSBALT);
  2.   DECLARE_RENDERER(NickRenderer_CH64_4_ALTIND0);
  3.   DECLARE_RENDERER(NickRenderer_LPIXEL_4_LSBALT);
  4.  

Ezek miert vannak meg "kulon", amikor talan ez se "standard", es inkabb a generic lenne?
Title: Re: NICK*
Post by: IstvanV on 2016.March.04. 18:12:37
Ezt kulon venni elvileg tenyleg gyorsabb, mar nem tudom mennyi kulonbseget jelent ...

Valószínűleg nem sokat, talán az se lenne nagyon lassú, ha csak a "generic" változat maradna, de egyszerűen megoldható volt, hogy mindegyik külön legyen, általában csak néhány sorosak (inline függvényeket használva) és egy hasonló mód másolásával és módosításával készültek. A switch is jó megoldásnak tűnik, ha nincs 512 külön "video mód" (8 mód * 4 szín * 16 LSBALT/MSBALT/ALTIND0/ALTIND1).

Quote
Ezek miert vannak meg "kulon", amikor talan ez se "standard", es inkabb a generic lenne?

A dokumentáció alapján viszonylag szabványosnak tűntek, legalábbis a CH64_4_ALTIND0, a többi talán kevésbé. :oops: Eredetileg egyébként minden külön volt, a NickRenderer_Generic csak később készült az összes nem dokumentált mód támogatására, de a már meglevő többi NickRenderer-t nem töröltem.
Title: Re: NICK
Post by: lgb on 2016.March.04. 18:25:08
Meg egy kerdes, ami nem is kifejezetten emulator fuggo, bar szerintem errol is lehetett szo mar. Eleg csak egy uj LPB elso scanline-janal felolvasni a dolgokat es eltarolni belso valtozokba? Vagy ugyanazon LPB (ha tobb scanline-ra vonatkozik, nyilvan!) eseten is az elso 8 slot-ban mindig ujraolvassa amugy is az LPB-t? Es ha ujraolvassa, mi van ha megvaltozott par parameter a memoriaban kozben? Foleg a scanline counter az erdekes, de persze mas is, ha video/colour mode valtozik, margin, paletta, vagy akarmi. EP-n ha mindig ujraolvassa a Nick valojaban, es hagyja is ervenyesulni, az ugye elvileg lehetoseget adna bizonyos erdekes trukkokre, bar vegulis ertelme nem sok, mert ugye akkor lehet tobb LPB-t megadni es ott megoldani, nem tudom lenne-e ertelme, illetve barmi kihasznalja-e ezt. Ez meg pl a VINT-re is erdekes hatassal lehet, mert mi van, ha LPB-ben be van allitva a VINT bit, es az LPB vonatkozik 10 scanline-ra, de kozben a CPU az 5. scanline-nal meg kinulazza, akkor a kov scanline-nal Nick ujraolvassa, megvaltozik a Dave fele meno INT1 allapota, igy elobb kovetkezik be az INT1 latch set (es ha engedve van a Z80 fele az interrupt keres ...) mint az LPB vege? Szoval, ugy erzem ez eleg sok mindenre kihatassal birhat, mar ha fontos egyaltalan, hogy ennyire pontos legyen az emulacio egyaltalan ...
Title: Re: NICK
Post by: IstvanV on 2016.March.04. 18:43:37
Meg egy kerdes, ami nem is kifejezetten emulator fuggo, bar szerintem errol is lehetett szo mar. Eleg csak egy uj LPB elso scanline-janal felolvasni a dolgokat es eltarolni belso valtozokba? Vagy ugyanazon LPB (ha tobb scanline-ra vonatkozik, nyilvan!) eseten is az elso 8 slot-ban mindig ujraolvassa amugy is az LPB-t? Es ha ujraolvassa, mi van ha megvaltozott par parameter a memoriaban kozben?

A palettát azt biztosan újraolvassa, ezt teszteltem, a többit valószínűleg csak akkor, ha nem értelmetlen. Az emulátorban így valósítottam meg:
- SC, LD2: ezeket nem olvassa újra
- MB, LM, RM, paletta: újraolvassa minden sorban (ha valamelyik margó 0 vagy 1, az csak a következő sorban lesz érvényes)
- LD1: ez a VRES bit értékétől függ

Az alábbi program teszteli a VINT, LM, RM, és paletta módosítását LPB-n belül:
[attachurl=1]
ep128emu-n így néz ki:
[attachthumb=2]
Title: Re: NICK
Post by: lgb on 2016.March.04. 23:10:29
Az alábbi program teszteli a VINT, LM, RM, és paletta módosítását LPB-n belül:
(Attachment Link)
ep128emu-n így néz ki:
(Attachment Link)

Ez GNU/GPL? Lenyulhatom a tesztjeim koze? Max kene ele vmi copyright/licenc megjegyzes azert.
Title: Re: NICK
Post by: IstvanV on 2016.March.05. 10:10:51
Ez GNU/GPL? Lenyulhatom a tesztjeim koze? Max kene ele vmi copyright/licenc megjegyzes azert.

Szabadon használható bármilyen célra. De az Xep128 már most is azonos eredményt ad az ep128emu-val, csak azt lenne még érdemes megnézni, hogy valódi gépen is ilyen-e.
Title: Re: NICK
Post by: IstvanV on 2016.March.05. 20:40:46
Xep128 interlace hack (nem túl elegáns megoldás, és hibás is, de valamennyire működik):

Code: Diff
  1. diff -rdU4 xep128-orig/nick.c xep128-master/nick.c
  2. --- xep128-orig/nick.c  2016-03-04 21:42:19.000000000 +0100
  3. +++ xep128-master/nick.c        2016-03-05 20:18:18.455640335 +0100
  4. @@ -25,9 +25,9 @@
  5.   * border colour, reading LPB, setting BIAS register) and use
  6.   * those values instead of conversion all the time.
  7.   */
  8.  
  9. -
  10. +int interlace = 0;
  11.  
  12.  static Uint16 lpt_a, lpt_set, ld1, ld2;
  13.  static int slot, visible, scanlines, max_scanlines;
  14.  static Uint8 *vram;
  15. @@ -611,8 +611,10 @@
  16.                         rm = a & 63;
  17.                         //altind1 = a & 64;
  18.                         //altind0 = a & 128;
  19.                         altind = ((a & 128) >> 1) | ((a & 64) << 1);
  20. +                        if (vsync && (rm - lm) >= 20)
  21. +                                interlace = (lm >= 19);
  22.                         break;
  23.                 case 2:
  24.                         a  = NICK_READ(lpt_a++);
  25.                         a |= NICK_READ(lpt_a++) << 8;
  26. diff -rdU4 xep128-orig/screen.c xep128-master/screen.c
  27. --- xep128-orig/screen.c        2016-03-04 21:42:19.000000000 +0100
  28. +++ xep128-master/screen.c      2016-03-05 20:28:50.051617289 +0100
  29. @@ -29,8 +29,10 @@
  30.  static int screenshot_index = 0;
  31.  static Uint32 *osd_pixels = NULL;
  32.  static int osd_on = 0, osd_fade = 0;
  33.  
  34. +extern int interlace;
  35. +
  36.  #include "app_icon.c"
  37.  
  38.  extern const Uint16 font_16x16[];
  39.  
  40. @@ -209,9 +211,21 @@
  41.         } else
  42.                 resize_counter++;
  43.         SDL_UpdateTexture(sdl_tex, NULL, ep_pixels, SCREEN_WIDTH * sizeof (Uint32));
  44.         SDL_RenderClear(sdl_ren);
  45. -       SDL_RenderCopy(sdl_ren, sdl_tex, NULL, NULL);
  46. +        if (!interlace) {
  47. +               SDL_RenderCopy(sdl_ren, sdl_tex, NULL, NULL);
  48. +       }
  49. +       else {
  50. +               SDL_Rect        r1, r2;
  51. +               r1.x = 0;
  52. +               r1.y = 1;
  53. +               r1.w = SCREEN_WIDTH;
  54. +               r1.h = SCREEN_HEIGHT - 1;
  55. +               r2 = r1;
  56. +               r2.h = (SCREEN_HEIGHT - 1) * 2;
  57. +               SDL_RenderCopy(sdl_ren, sdl_tex, &r1, &r2);
  58. +       }
  59.         if (osd_on && sdl_osdtex != NULL)
  60.                 SDL_RenderCopy(sdl_ren, sdl_osdtex, NULL, NULL);
  61.         else
  62.                 osd_fade = 0;

IVIEW képeken látható az effektus, például ezeken:
[attachurl=1]
[attachurl=2]

A Boulder Dash nem működik a 4 színű karakteres mód hiánya miatt. :oops:
Title: Re: NICK
Post by: lgb on 2016.March.06. 21:06:52
Atmasztam a Xep128 topic-ba, ez mar kevesbe Nick/hw specifikus, max igencsak erintolegesen :)
Title: Re: NICK
Post by: IstvanV on 2016.March.07. 11:40:27
De ha tok ugyanaz, es nem tolja el egy fel (vagy egy???) sorral, akkor ugye "fesus" lesz a kep, hiszen valahova soha nem jut informacio, ami csak akkor jutna, ha nem interlaced eseten is lenne ket kulon vsync blokk ahhoz hogy mindket "half frame-re" jusson ugyanaz az info.

Valódi CRT monitoron is többé-kevésbé "fésűs" a kép, amint az például itt (https://enterpriseforever.com/hardver/az-alom-ep-projekt/msg53525/#msg53525) is látható. :) Az ep128emu-ban ez az effektus a "Line shade" paraméterrel állítható azokban a módokban, amelyek támogatják:
- OpenGL / quality 3: ez szoftveresen oldja meg, 2x függőleges felbontású textúrát hoz létre, ahol az "üres" sorokba az alattuk és felettük található sorok RGB értékeinek az átlaga kerül a Line shade értékkel szorozva
- OpenGL / quality 4: itt marad az eredeti (kis) függőleges textúra felbontás, viszont a megjelenített pixeleket egy shader cos() függvénnyel szorozza a függőleges pozíciótól függően (cos(Y * PI * 2) * ((1 - line_shade) / 2) + line_shade, ahol az "üres" soroknál az Y tört része 0.5)

Egy másik effektus ami javíthatja az interlace megjelenítését a "motion blur", ami az ep128emu-ban egyszerűen annyit tesz, hogy a framebufferben eredetileg található RGB értékeket szorozza a motion blur értékkel, és ehhez hozzáadja az új pixeleket (1 - motion blur) értékkel szorozva. Ez csak OpenGL / single buffered módban támogatott.

Probléma még, hogy a jelenleg használt monitorok többségén a függőleges frekvencia 60 Hz, amin az emulált EP 50 Hz-es képe egyenetlenül, akadozva jelenik meg, és ez "elrontja" az interlace képeket is. Erre a lehetséges megoldások:
- a monitor frekvenciáját 50 vagy 100 Hz-re állítani, ha támogatja, akkor ez a legjobb
- ep128emu-n a "resample to monitor refresh rate" mód, ez az 50 Hz-es képet 60 Hz-re próbálja interpolálni, több-kevesebb sikerrel
- az emulált NICK órajelének a növelése 60 * 312.5 * 57 = 1068750 slot/s-re, vagy 120% sebesség beállítása

A fentieket érdemes kipróbálni az il_test.pic képpel, ezen jól látható az emulált interlace minősége.
Title: Re: NICK
Post by: Zozosoft on 2016.March.07. 11:47:49
75Hz-es monitor mennyire jó?
Title: Re: NICK
Post by: IstvanV on 2016.March.07. 12:05:42
75Hz-es monitor mennyire jó?

25 Hz-es képhez (pl. ilyen frekvencián futó játékoknál) jó, de 50 Hz-nél itt is probléma, hogy minden második (fél)kép kétszer jelenik meg. Tehát például interlace módban a félképek aszimmetrikus időzítéssel AABAABAAB... vagy ABBABBABB... mintában jelennének meg ABABABAB... (50 Hz) vagy AABBAABB... (100 Hz) helyett, bár ez talán kevésbé zavaró, mint a 60 Hz-es monitor.
Title: Re: NICK
Post by: Zozosoft on 2016.March.09. 19:23:05
azt lenne még érdemes megnézni, hogy valódi gépen is ilyen-e.
[attach=1]
Title: Re: NICK
Post by: IstvanV on 2016.March.09. 19:29:18
Úgy látszik, ez a program nem talált emulátor hibát. :)
Title: Re: NICK
Post by: endi on 2016.March.09. 19:31:20
(Attachment Link)

mert ez nem valódi gép? ilyen tévére kötöd az emut? :)
Title: Re: NICK
Post by: Zozosoft on 2016.March.10. 13:04:26
mert ez nem valódi gép? ilyen tévére kötöd az emut? :)
???
István korábban berakta az emulátoros képet, én a valódi gépest, és meg lett állapítva, hogy ugyanúgy működik a program emulátoron is, ahogy valódi gépen.
Title: Re: NICK
Post by: endi on 2016.August.13. 18:23:58
mindig a központi procikat szoktuk összehasonlítani teljesítmény szempontból... de pl egy c64 videóchipje hogy aránylik teljesítményben a nickhez?
úgy értem van ügye az nick, ami 1 rasztersor alatt x byte adatot dolgoz fel, persze tudom, ennyi nem elég a teljesítménye meghatározásához, az is számít mit csinál ezekkel az adatokkal közben... de valamennyire össze lehetne pl a c64-el hasonlítani

megint azért jutott ez eszembe, mert elgondolkodtam, hogy miért nem használták ki a dave-ben jobban a karakteres módokoat? pedig pl a c64-ben ezek tök jók... nekünk meg van egy hires 16 felbontású 2*4 színű karakteres módunk ami egyedül használható valami értelmesre, úgy értem grafikai/játék szempontból...
Title: Re: NICK
Post by: szipucsu on 2016.August.13. 20:02:35
miért nem használták ki a dave-ben jobban a karakteres módokoat?
Biztos gondolták, a gyűrűmodulációk mellett nem kell még az is. :D
Title: Re: NICK
Post by: IstvanV on 2016.August.13. 20:28:53
mindig a központi procikat szoktuk összehasonlítani teljesítmény szempontból... de pl egy c64 videóchipje hogy aránylik teljesítményben a nickhez?
úgy értem van ügye az nick, ami 1 rasztersor alatt x byte adatot dolgoz fel, persze tudom, ennyi nem elég a teljesítménye meghatározásához, az is számít mit csinál ezekkel az adatokkal közben... de valamennyire össze lehetne pl a c64-el hasonlítani

A NICK és a VIC-II is 2 byte adatot tud olvasni egy karakter alatt, de az utóbbi használ még egy 4 bites szín RAM-ot is, az adatbusz valójában 12 bites. Tehát a VIC-II "nagyobb teljesítményű" ebben a tekintetben, bár a feldolgozott adatból a pixel információ csak 1 byte lehet, a NICK esetében pedig 2. Ezen kívül amikor a VIC-II a teljes sávszélességet használja, akkor le kell állítani a CPU-t, ez általában egy karakteren belül a 8 sorból csak egyben történik. A sprite adatok olvasására a sor keretszínű részén van lehetőség.

Quote
megint azért jutott ez eszembe, mert elgondolkodtam, hogy miért nem használták ki a dave-ben jobban a karakteres módokoat? pedig pl a c64-ben ezek tök jók... nekünk meg van egy hires 16 felbontású 2*4 színű karakteres módunk ami egyedül használható valami értelmesre, úgy értem grafikai/játék szempontból...

A probléma elsősorban a karakterenként szabadon választható szín hiánya, illetve a C64-en a vízszintes scroll és a sprite támogatás is előnyt jelent a karakteres módú játékoknál.
Title: Re: NICK
Post by: lgb on 2016.August.17. 00:36:41
A VIC-II amugy erdekes egy teremtmeny. Ha visszamegyunk a VIC-I-hez (Commodore VIC20) azt latjuk, hogy nincs grafikus mod, csak karakteres (es sprite sincs). Grafikat ugy csinaltak, hogy egyszeruen telenyomtak a kepernyot karakterkodokkal szepen, es a karakterkeszletet valtoztatgattak :) Erdekes modon van a VIC-I-ben (a II-ben mar nincs!) 16 pixel magas karakter is. Ennek letjogosultsaga azonban nem a karakterek "szepsege", hanem pont az, hogy lefedheto legyen a teljes kepernyo kulonbozo karakterekkel, ami igy kvazi grafikus display-kent is hasznalhato. A VIC-II eseten van "igazi" grafikus mod is, am ennek szervezese igen eros rokonsagot mutat a fenti trukkel, ui nem linearis, grafikus modban az elso byte a bal felso sarok elso 8 pixele, a masodik byte viszont az _alatta_levo_ 8 pixel, es igy tovabb, bar 8 utan "visszaugrunk" a bal felso sarok 8 pixele utani poziciora. Ez valoszinu pont annak tudhato be, hogy nem akartak totalisan megreformalni a dolgot, vagy pedig igy chip feluletet sporoltak, hogy nemikepp hasonlo a grafikus es karakteres mod szervezese bizonyos aspektusokbol. Erdekes modon ez a szervezes meg a VIC-III-ban is megvan (Commodore 65), ahol az uj bitplane alapu modok szervezese is hasonlo, nem csak a "VIC-II compatible" modoke (es VIC-III-on ezek kivul van vegre 80 karakteres mod is amugy, meg hardware attributumok mint a villogas, alahuzas, stb). A teljesseg igenye nelkul, a VIC-iV (ez mar "utanerzes", lasd mega65 project) ezt meg tovabb viszi, ahol lehet karakteres modban is proporcionalis cucc, vagy akar fuggoleges/vizszintes tukrozes per karakter alapon mint attributum, stb). Node, visszaterve: ezen kivul allitolag a VIC-II-nek vmi majdnem 3/4 reszet a sprite kezeles viszi el.

A fenti dologhoz kepest a Nick egy "clean" design, sokkal letilsztultabb. Erdekes modon, lehet pont ez a baj (most a sprite-okat hagyjuk). Pl az, hogy minden uj karaktersornal olvasnia kell dolgokat, ott tovabb kell neki a busz, ami normal allapotban kb kiegyenlitett a CPU/VIC-II "valtott" hozzafereseben az orajel ket fazisara. Ekkor a CPU-nak viszont varakoznia is kell, ezt hivjak "bad line"-nak. Sok erdekes VIC-II trukk azon alapul, hogy ez a logika nem tokeletes, es "atverheto", igy pl el lehet erni a regiszereket megfelelo pillanatban valo irkalasaval, hogy ket karakter sor kozott "res" legyen, aminek persze a magassaga is igy beallithato, stb. Hasonloan, pl a "keret lebontasa" is alapvetoen egy "hibara" epul (igaz, a keret eltuntetese sokat nem segit, de pl sprite-okkal igy lefedheto, amit amugy a keret takarna). Sok esetben az ilyen hibak pont hogy hasznosak tehat, bar nyilvan ezt anno nem tudtak, csak az ido adott erre vegul bizonyitekot :D A Nick-ben nem is tudom, hogy van-e olyan "hiba" ami barmi hasznosra jo lenne.

Ahogy Istvan mar irta, a VIC-II "csal" mert nem 8 bites az adatbusza, hanem 12 ... Ebbol 8 bit a rendszerbuszon van, 4 bit meg fixen 1Kx4bites SRAM-ra van kotve, ez a color RAM. Igy azt eleri parhuzamosan ugymond, egy olvasassal tehat 8 helyett 12 bit informaciot kap. Amugy az is erdekes, hogy a VIC-I-tol orokolt 16Kbyte cimtartomany megvan a VIC-II-nel (sot a VIC-III-nal is, a bitplane-ek meretet ez korlatozza, es sprite-okkal egyutt ez akar "fajdalmas" is lehet, igaz a C65 nem sok vizet zavar sok embernek, gondolom) is, max ezt trukkozik ide/oda, hogy a gep hol latja az adott teruletet. Viszont a 12 bites adatbusznak konszonheto, hogy minden karakterhez lehet sajat szin, ami azert hasznos dolog tud lenni ...

Istvan, abban viszont nem vagyok biztos, hogy csak a keret alatt tud Sprite adatokat olvasni a VIC-II, bar megcafolni sem tudom, konnyen lehet, hogy en tevedek.

Mindenesetre egy erdekes aspektura van az egesznek meg: a serial IEC lassusaga, Commodore floppy tortenet. Eredendoen a Commodore egy hardware-esen megoldott soros protokolt kepzelt el. Csakhogy, a floppy drive-okban alkalmazott VIA chip-nek - mint kiderult - volt egy hardware hibaja, ami problemat okozott. Igy kenytelenek voltak atallni a software-esen megoldott soros rutinokra, szoval eleg lassu lett. Ehhez kepest, VIC20 utana a C64 valojaban *tovabb lassitotta* a floppy elerest, ui mivel az emlitett rutin software-es, es a C64/VIC-II eseten neha a VIC-II-nek tovabb kell a busz (es ezert all a CPU), szandekosan be kellett meg jobban lassitani, hogy minden eseteben garantalhato legyen, miszerint "ne fusson ki" az idokeretbol a rutin amiatt, hogy szegeny CPU meg van eppen allitva :) Kesobbi lemezegysegeknel mar nem VIA van feltetlen (vagy legalabbis nem a hibas szeria? nem tudom igy megmondani most), es C64-ben is CIA van (nem VIA), tehat mar C64-en is at lehetne terni ebben az esetben a hardware-es megoldasra. C128 eseten ez mar hivatalosan megtortent, ez a fast serial cuccos ...
Title: Re: NICK
Post by: IstvanV on 2016.August.17. 08:24:10
Istvan, abban viszont nem vagyok biztos, hogy csak a keret alatt tud Sprite adatokat olvasni a VIC-II, bar megcafolni sem tudom, konnyen lehet, hogy en tevedek.

Úgy értettem, a soron belül olvassa a keret alatt a sprite adatokat. Egy sor 63 karakter PAL gépen, ebből 40 a képernyő, 5 DRAM frissítés, és marad 18 egyéb célra, a sprite olvasás (legfeljebb 8*4=32 byte) 16 karaktert igényel. Itt (http://www.cebix.net/VIC-Article.txt) a 3.6.3-nál lehet részletesebben olvasni az időzítésről.
Title: Re: NICK
Post by: lgb on 2016.August.17. 20:52:03
Úgy értettem, a soron belül olvassa a keret alatt a sprite adatokat. Egy sor 63 karakter PAL gépen, ebből 40 a képernyő, 5 DRAM frissítés, és marad 18 egyéb célra, a sprite olvasás (legfeljebb 8*4=32 byte) 16 karaktert igényel. Itt (http://www.cebix.net/VIC-Article.txt) a 3.6.3-nál lehet részletesebben olvasni az időzítésről.

Na ennyire azert tenyleg nem tudom :-D Csak ami gyanus volt (es meg mindig csak megerzes alapjan mondom): mi van ha 8 sprite esik egy scanline-ra, az 3*8=24 byte info amit olvasni kell, plusz ha meg uj karaktersor is kezdodik (badline), biztos nem fer bele "csak a keretbe". Az meg kulon erdekes, hogy mi van, ha kikapcsolod a keretet, es mondjuk van 8 sprite a jobb kereten meg a bal kereten is (sprite multiplexing-gel talan lehetseges, bar nem tudom hogy az egy scanline-on belul muxik-e). Node, ha csak siman 8 sprite van egy scanline-ban mindenfele idozitett reg atiras nelkul, mar az is erdekes, kerettel meg foleg annelkul. Mondjuk ezekben az FLD, FLI, ez/az VIC-II trukkokben nem vagyok tul nagy mester, finoman szolva :D
Title: Re: NICK
Post by: IstvanV on 2016.August.18. 09:34:48
Egy soron belül a VIC-II legfeljebb 61 karakternél használja az adatbuszt, és a teljes sor 63 (PAL) vagy 65 (NTSC) karakter:
- 5 karakter DRAM frissítés
- 40 karakter képernyő (bad line esetén ilyenkor mindkét fél ciklusban a VIC-II aktív), 40 byte vagy 80 byte + 40 * 4 bit video adat
- 2 (PAL) vagy 4 (NTSC) karakter nem használt (idle)
- 16 karakter sprite olvasás (egy sprite 4 byte, 1 byte mutató (a cím felső 8 bitje) + 3 byte pixel adat), ez a bad line-hoz hasonlóan mindkét fél ciklust használja és leállítja a CPU-t
Bad line vagy aktív sprite esetén a CPU-t 3 karakterrel az olvasás előtt le kell állítani, ez alatt az idő alatt még befejezheti az esetleges írási műveletet (ami legfeljebb 3 egymást követő byte lehet, IRQ elfogadásakor).
Title: Re: NICK
Post by: lgb on 2016.August.18. 19:01:06
:) Oke, ehhez mar tenyleg nem tudok mit hozzatenni :D
Title: Re: NICK
Post by: IstvanV on 2016.September.24. 19:28:42
FIXBIAS scroll lebegő adatbusz olvasással időzítve:
fbscroll.com (https://enterpriseforever.com/hardver/nick/?action=dlattach;attach=9567)
Csak 4 MHz-es valódi gépen működik. ep128emu-n ez a script javítja az időzítési hibát (így sem egészen pontos, mert igazi gépen nem karakterhatáron változik a szín, hanem egy 16 színű pixellel korábban):
nickread.lua (https://enterpriseforever.com/hardver/nick/?action=dlattach;attach=9568)

Ez a program most már működik Lua script nélkül is az emulátor GitHub-on taláható aktuális forrásával, ha nem is tökéletesen, az időzítésen még lehetne javítani.

Egy másik lebegő adatbusszal kapcsolatos újdonság: ha a jobb margó nagyobb mint 54, akkor az ott található karakter a valódi géphez hasonlóan az utolsó olvasott byte-ot ismétli, bár ennek a gyakorlatban ritkán van jelentősége.
Title: Re: NICK
Post by: geco on 2016.September.25. 17:28:09
Egy másik lebegő adatbusszal kapcsolatos újdonság: ha a jobb margó nagyobb mint 54, akkor az ott található karakter a valódi géphez hasonlóan az utolsó olvasott byte-ot ismétli, bár ennek a gyakorlatban ritkán van jelentősége.
Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )
Title: Re: NICK
Post by: IstvanV on 2016.September.25. 20:16:56
Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )

Ezzel a beta verzióval (https://github.com/istvan-v/ep128emu/releases/tag/2.0.10-beta_20160925) ki lehet próbálni, ebben már megtalálhatók a fent említett módosítások, illetve az fbscroll.com is jól működik.
Title: Re: NICK
Post by: geco on 2016.September.25. 20:43:00
Köszi, letöltöttem
Title: Re: NICK
Post by: IstvanV on 2016.September.26. 09:01:30
Ezzel az egyszerű BASIC programmal tesztelhetők a "szabálytalan" margók, 49 karaktert próbál megjeleníteni egy sorban. Érdemes lenne megnézni valódi gépen olyan monitorral, amin beállítható, hogy láthatóak legyenek ezek a karakterek is. Azonban nekem TV kártyával S-video kimenetről az első oszlopban nincs kép, ott még a vízszintes szinkron van.

[attachurl=1]
Title: Re: NICK
Post by: IstvanV on 2016.September.26. 13:01:04
Érdemes lenne megnézni valódi gépen olyan monitorral, amin beállítható, hogy láthatóak legyenek ezek a karakterek is.

Néhány régebbi képen látható a valódi gépen megjeleníthető szélesség itt (https://enterpriseforever.com/hardver/nick/msg24907/#msg24907) és itt (https://enterpriseforever.com/hardver/s-video-kimenet/msg34189/#msg34189). Ezek szerint a 7-es pozíciónál (ami az emulátoron az első oszlop) még nincs kép, és még a 8-asnál is az első "érvényes" karakter kb. fele elveszik. Tehát normál 40 karakteres módban a bal keret csak kb. 2.5 karakter széles. A jobb keret viszont az emulátorral megegyező szélességű, és az 54-es pozíciónál egy oszlop még látható, ahol az utolsó byte ismétlődik. Talán az RGB kimenet eltérő, legalábbis a burst jelet nem tartalmazza a bal oldalon.
Title: Re: NICK
Post by: geco on 2016.September.26. 13:14:14
Akkor az eddigi maximális 46-os képeinkből is valójában csak 45,5 látszik.
Title: Re: NICK
Post by: IstvanV on 2016.September.26. 13:27:02
Akkor az eddigi maximális 46-os képeinkből is valójában csak 45,5 látszik.

Feltéve, hogy ugyanez a probléma monitoron is megjelenik RGB kimenetről, ezt nem tudtam kipróbálni. :oops: Elméletileg lehetne különböző, mert a kapcsolási rajz (http://ep128.hu/Ep_Hardware/Pic/EP64-3.jpg) szerint a NICK /BLANK és /BURST kimeneteit csak a kompozit videót előállító LM1886/LM1889 áramkör használja. Zozosoft már jelenített meg 46x300 méretű IVIEW képeket CRT monitoron. :)
Title: Re: NICK
Post by: IstvanV on 2016.September.27. 13:09:27
Elvileg egyébként lehetséges lenne 47 karakter szélességű módot megvalósítani, az utolsó byte-ot minden sorban megfelelő időzítéssel valamelyik NICK portra kiírva. Természetesen ennek a hasznossága korlátozott, mert folyamatosan használja a CPU-t, és az utolsó oszlopban csak egy byte video adat lehetséges (LPIXEL módok).
Title: Re: NICK
Post by: endi on 2016.September.27. 13:31:58
Elvileg egyébként lehetséges lenne 47 karakter szélességű módot megvalósítani, az utolsó byte-ot minden sorban megfelelő időzítéssel valamelyik NICK portra kiírva. Természetesen ennek a hasznossága korlátozott, mert folyamatosan használja a CPU-t, és az utolsó oszlopban csak egy byte video adat lehetséges (LPIXEL módok).

:mrgreen:
Title: Re: NICK
Post by: endi on 2016.October.02. 18:07:23
van ügye a hires 2 mód. ilyenkor 2x olyan magas a pixel mint széles. grafikus szemmel nézve eléggé használhatatlan ez. bár nem tudom a "vízszintes tégla" miért jobb, biztos van valami oka.
de amiért most ezt írom: van más gép, ami tudott ilyen "függőleges tégla" arányú pixelt? :)
Title: Re: NICK
Post by: ergoGnomik on 2016.October.02. 18:51:32
van ügye a hires 2 mód. ilyenkor 2x olyan magas a pixel mint széles. grafikus szemmel nézve eléggé használhatatlan ez. bár nem tudom a "vízszintes tégla" miért jobb, biztos van valami oka.
de amiért most ezt írom: van más gép, ami tudott ilyen "függőleges tégla" arányú pixelt? :)
Felteszem a CGA 640-szer 200-as felbontása is meglehetősen "függőleges tégla" arányú. Commodore földön, ha NTSC masinád volt, mintha ott is magasabb lenne mint széles egy képpont, legalábbis a PAL gépekhez viszonyítva bizonyosan (4:3 képarány mindkét rendszerben, de szabvány szerint csak ~240 látható sor a ~288-cal szemben).
Title: Re: NICK
Post by: ergoGnomik on 2016.October.02. 19:30:57
Valószínűleg minden CRTC 6845 alapú masinán lehetséges ilyen felbontást előcsalogatni.

/OFF

Vajon hová tűnt a hozzászólás szerkesztése gombocska?

Szerk.: Érdekes, ezen a poszton meg van ilyen. Lehet, hogy attól függ, hogy van-e benne idézet?

/ON
Title: Re: NICK
Post by: Zozosoft on 2016.October.02. 19:34:46
CPC,TVC is, meg bármi más amiben 6845 chip volt.
Atari ST is, csak ott 4 színnel (külön nagy felbontású monochrom monitorral volt 640x400 2 színnel).
Szóval ebben semmi különös nem volt.
Title: Re: NICK
Post by: lgb on 2016.October.03. 02:52:36
A CRTC kapcsan szerintem fontos megjegyezni, hogy - mar amennyire en tudom, ismerem! - az nem vegez semmifele megjelenitest, nem is dolga. Attol fuggetlenul lehet tok mas szinszam, felbontas, akarmi, a CRTC "csak" abban segit, hogy eloallitja a megfelelo szignalokat (pl vsync, hsync), meg mindenfele cimeket general, de az pl tok esetfuggo, hogy egyes gepeken ezeket a cimeket hogy hasznaljak aztan fel, es hogyan lesznek belole memoriacimek, adott szamu pixel, memoriaszervezes, miegymas stb stb. Szoval a CRTC onmagaban sem felbontast, sem szinek szamat vagy hasonlot nem hataroz meg.
Title: Re: NICK
Post by: ergoGnomik on 2016.October.03. 08:08:34
Hát, igen. Ezt mindig elfelejtem. Azonban – érdekes módon – a CRTC alapú rendszerek jellemzően ezt a maximális felbontást produkálták. Biztosan volt ennek valami műszaki oka, vagy csak egy kitalálta, a többi ellopta, mert így volt egyszerűbb.

Viszont volt még ilyen felbontása a C128 VDC-jének is, illetve a soha el nem készült VIC-III-nak is lett volna pl. 1280-szor 200-as vagy 400-as felbontása is.
Title: Re: NICK
Post by: lgb on 2016.October.03. 09:42:23
Hát, igen. Ezt mindig elfelejtem. Azonban – érdekes módon – a CRTC alapú rendszerek jellemzően ezt a maximális felbontást produkálták. Biztosan volt ennek valami műszaki oka, vagy csak egy kitalálta, a többi ellopta, mert így volt egyszerűbb.

Az is vicces amugy, hogy elvileg a CRTC olyat sem hataroz meg, hogy grafikus/karakteres felbontas feltetlen ... Bar _elvileg_ kezel olyan infokat ami karakteres modra 'van kitalalva' (pl hogy melyik scanline-ja egy karakter sornak) ezt szoktak a tobbi cimekkel kombinalni grafikus mod eloallitasahoz, aztan lesz mindenfele gyonyoru non-linear video memoria layout a vegen :D

Quote
illetve a soha el nem készült VIC-III-nak is lett volna pl. 1280-szor 200-as vagy 400-as felbontása is.

Elkeszult - vagy hat mondjuk ugy volt belole ... lehet meg fejlesztgettek volna egy kicsit, bar meg mindig jobban kesz volt mint pl az F011 FDC vagy az F018 DMA controller a C65-ben :) Van belole par - marmint C65-bol meg VIC-III-bol - , igaz vehetsz 20ezer euroert kb egyet :) Mellesleg mivel eppen a VIC-III emulaciot irom ujra a C65 emulatoromban (mivel eddig igen rondan van megoldva), nem kell elmeselned, hogy mukodik, mondjuk eleg nagy rondasag, kulonosen akkor lehet imadni, amikor 320*200-at 256 szinben kipresel magabol 8 bitplane-es modban, hogy szegeny memoria ugy nezi ki, mintha fesu lenne, az egyes bitplane-ek elehelyezkedese miatt, ami nemileg kotott a VIC-III dual data bus design-ja miatt, ha es akkor sprite-oknak sem marad mar igazan eleg memoria a regi VIC-I/VIC-II bank szervezesi elvek miatt. Vicces egy cuccos :) Ja, es van VIC-IV is, igaz az mar nem Commodore, hanem egesz ujkeletu, Mega65 specific :) Amugy 400 pixelt VIC-III is csak interlaced modban tud persze, 1280 modnak meg sok ertelme nincs, es raadasul ilyen bitplane time multiplex alapu cuccos a VIC-III-on. Szerintem amit esszeruen lehet vele hasznalni es normalisan az meg kb a 640*200 (amire van text mod is, hw attributumokkal is, mint villogas, meg ilyesmi csacskasagok, meg persze classic VIC-II bitmap mode es a VIC-III bitplane mod is lehet ilyen).
Title: Re: NICK
Post by: endi on 2016.October.29. 19:29:55
ez vajon igaz gépen is ilyen?
a fel gombbal mozogj egyet fel, ezzel az "M" ikonra lépsz, ami balra eltolja a képet (a játékban így lehetett beállítani a kép hol legyen).
na most ha még egyet balra megy a kép akkor bal oldalt a borderen megjelenik a graf
lehet hogy emu hiba?
Title: Re: NICK
Post by: IstvanV on 2016.October.29. 22:37:35
ez vajon igaz gépen is ilyen?

Valódi gépen ott nincs kép (illetve a TV-k általában le is vágják), tehát valójában annak az oszlopnak mindig feketének kellene lennie. De ez például színes keretnél nem túl jól nézne ki, ezért az emulátor ebben az oszlopban is próbál megjeleníteni valamit: ha nem keretszínű, akkor 00h pixel byte értéket tételez fel. A jobb oldalon viszont az igazi géphez hasonlóan az utolsó olvasott video byte ismétlődik, legalábbis a 2.0.10 verzióban.
Title: Re: NICK
Post by: endi on 2016.October.29. 23:53:00
Valódi gépen ott nincs kép (illetve a TV-k általában le is vágják), tehát valójában annak az oszlopnak mindig feketének kellene lennie. De ez például színes keretnél nem túl jól nézne ki, ezért az emulátor ebben az oszlopban is próbál megjeleníteni valamit: ha nem keretszínű, akkor 00h pixel byte értéket tételez fel. A jobb oldalon viszont az igazi géphez hasonlóan az utolsó olvasott video byte ismétlődik, legalábbis a 2.0.10 verzióban.

áh pedig reménykedtem hogy találtam valami nick bugot amit esetleg ki lehetne használni :)
Title: Re: NICK
Post by: endi on 2016.December.23. 12:46:10
az attr módnak vajon miért nincs lores verziója? érdekes lenne :)
na persze sok értelme nem lenne
Title: Re: NICK
Post by: IstvanV on 2016.December.23. 12:56:23
az attr módnak vajon miért nincs lores verziója?

Van, de nem lesz tőle több szín, csak a felbontás csökken. Tehát például a 4 színű attribútum módban a pixel byte felső 4 bitje lesz 4 kétszeres szélességű pixel, az alsó 4 bit pedig elveszik. Az attribútum mód lényege, hogy az eredeti paletta szín 0. bitje alapján választ papír vagy tinta színt. Ha a 2. és 3. színt nem változtatná, akkor lenne értelme a 4 színű attr módnak, hasonló lenne a C64 vagy Plus/4 többszínű grafikus módjához.
Title: Re: NICK
Post by: szipucsu on 2016.December.23. 13:14:56
Van
Gondolom, basic-ből nem érhetők el ezek a módok a set video mode stb. utasításokkal, csak gépi kódból, poke-okkal.
Title: Re: NICK
Post by: geco on 2016.December.23. 13:23:04
Gondolom, basic-ből nem érhetők el ezek a módok a set video mode stb. utasításokkal, csak gépi kódból, poke-okkal.
Sztem nem eszi, de ha bespókolod BASICből a megfelelő bájtokat az LPT-be, akkor eszi :D
Title: Re: NICK
Post by: IstvanV on 2016.December.23. 14:10:23
[attachthumb=1]

[attachthumb=2]

[attachthumb=3]
Title: Re: NICK
Post by: endi on 2016.December.23. 14:20:45
na ja, ilyenekkel sokat kísérleteztem annak idején, és akkor is megállapítottam, hogy semmi értelme :)

bezzeg ha a karakteres módokkal többet foglalkoztam volna, akkor már annak idején megszülethetett volna a gracha editor :)
Title: Re: NICK
Post by: endi on 2016.December.23. 14:29:43
azon gondolkodtam, lehetséges-e olyan exos bővítőt írni, ami engedélyez ilyen extra módokat, vagy pl lpt soronkénti paletta állítást
Title: Re: NICK
Post by: Zozosoft on 2016.December.23. 14:34:08
azon gondolkodtam, lehetséges-e olyan exos bővítőt írni, ami engedélyez ilyen extra módokat, vagy pl lpt soronkénti paletta állítást
Simán, VIDEO: néven, és akkor az letiltja a gyárit. Így működik a géphez adott Interlace driver is (demó kazettán volt rajta)
Title: Re: NICK
Post by: endi on 2016.December.23. 14:51:25
Simán, VIDEO: néven, és akkor az letiltja a gyárit. Így működik a géphez adott Interlace driver is (demó kazettán volt rajta)

na jó de ez felülírja az egész jelenlegit?
az lenne jó ha bele lehetne nyúlni.
Title: Re: NICK
Post by: endi on 2018.January.21. 19:49:21
attr módban ügye két memcímet lehet megadni az lpt-ben. ez a másik cím karakteres módban is használva van.
a többi grafikus módban miért nem használták ezt valamire a nick tervezői?
Title: Re: NICK
Post by: ergoGnomik on 2018.January.21. 20:26:11
attr módban ügye két memcímet lehet megadni az lpt-ben. ez a másik cím karakteres módban is használva van.
a többi grafikus módban miért nem használták ezt valamire a nick tervezői?
Na jó, de mire lehetett volna használni? Esetleg a felépítés bonyolításával LORES módban lett volna esély valamit kezdeni ezekkel, mivel ilyenkor van még szabad sávszélesség a memória felé, de az megdrágította volna a NICK-et, és még többet késtek volna a piacra dobással.
Title: Re: NICK
Post by: endi on 2018.January.21. 20:33:26
Na jó, de mire lehetett volna használni? Esetleg a felépítés bonyolításával LORES módban lett volna esély valamit kezdeni ezekkel, mivel ilyenkor van még szabad sávszélesség a memória felé, de az megdrágította volna a NICK-et, és még többet késtek volna a piacra dobással.

hát nyilván minden plusz dolog extra idő és pénz... de ötletességgel ki lehetett volna valamit hozni, ami lehet hogy csak valamiféle effektekhez lett volna használható, de az is valami.
Title: Re: NICK
Post by: geco on 2018.January.22. 08:51:50
Talán az extra 8 szín definíciós pointerére, de gondolom az már nem fért volna be a Nick olvasási idejébe se. :)
Title: Re: NICK
Post by: endi on 2018.January.22. 09:27:33
Talán az extra 8 szín definíciós pointerére, de gondolom az már nem fért volna be a Nick olvasási idejébe se. :)

hát nem értek az elektronikához, de vajon ha text80 módban tud két memcímről olvasni hires grafikát akkor miért nincs col2 hires attr mód?
Title: Re: NICK
Post by: ergoGnomik on 2018.January.22. 09:45:13
hát nem értek az elektronikához, de vajon ha text80 módban tud két memcímről olvasni hires grafikát akkor miért nincs col2 hires attr mód?
Ez nem elektronika, csak a NICK működése. Minden képpontsor a NICK számára fel van osztva 57 időszeletre. Minden időszeletben képes elvégezni két olvasási műveletet a videó memóriából, és biztosítani egy olvasási vagy írási hozzáférést a Z80-nak. Ebből az első nyolc időszeletben olvassa az adott sorhoz tartozó LPB-t, az utolsó háromban pedig végzi a memóriájának frissítését (ezért nem tudsz 46/92/184/368/736 karakternél/képpontnál szélesebb képernyőt létrehozni). Nagy felbontású vagy karakteres módokban kihasználja mindkét olvasási hozzáférést az adatok memóriából elhozására, kis felbontású módban csak az egyiket. Vagy legalább is én így tudom. Amit te kérdezel, annak valószínűleg az az oka, hogy a szükséges mennyiségű adat felolvasása már nem fér bele a rendelkezésre álló sávszélességbe, amit pedig nem lehet megváltoztatni.
Title: Re: NICK
Post by: Zozosoft on 2018.January.22. 09:55:01
hát nem értek az elektronikához, de vajon ha text80 módban tud két memcímről olvasni hires grafikát
Éppen ez az, hogy Text 80-ban sem olvas két címről.
A Text 80 a Nick számára nem karakteres, hanem grafikus (Hires 2). A karakterkészletet a VIDEO eszköz olvassa ki karakter kiírásakor, és teszi oda a megfelelő pixel adatot a grafikus területre. Ezért is van ez szoftveres grafikus módnak nevezve. A Text 40 a hardveres grafikus mód.
Title: Re: NICK
Post by: endi on 2018.January.22. 10:00:58
Éppen ez az, hogy Text 80-ban sem olvas két címről.
A Text 80 a Nick számára nem karakteres, hanem grafikus (Hires 2). A karakterkészletet a VIDEO eszköz olvassa ki karakter kiírásakor, és teszi oda a megfelelő pixel adatot a grafikus területre. Ezért is van ez szoftveres grafikus módnak nevezve. A Text 40 a hardveres grafikus mód.

ja igazad van, kevertem azzal hogy lehet színezni a karakter byte-jainak pixeleivel, de ez értelemszerűen nem külön memóriacímről megy

de akkor a következő kérdésem, hogy miért nincs pl c4 vagy c16 módban valamiféle attr lehetőség, akár ezek lores módjában.
persze bizonyára 2 színt "renderelni" kevesebb idő mint több színt, bár az attr módú szín és pixel keverés tuti nem egyszerűbb mint pl egy c16 mód.
Title: Re: NICK
Post by: endi on 2018.June.05. 18:24:11
a fórum leghülyébb kérdése jutott eszembe :D

van ügye ez a "külső színbemenet". na most, hogy lehetett volna ezt úgy kihasználni, hogy maga az ep adjon valami jelet oda, tehát hogy minimális hardverrel (azaz olcsón) valamiféle effektet ki lehessen hozni belőle? :D
Title: Re: NICK
Post by: ergoGnomik on 2018.June.05. 21:18:28
na most, hogy lehetett volna ezt úgy kihasználni, hogy maga az ep adjon valami jelet oda, tehát hogy minimális hardverrel (azaz olcsón) valamiféle effektet ki lehessen hozni belőle? :D
Nem hülye kérdés ez, hanem határozatlan. Azt szeretnéd tudni, hogy milyen módon kell bővítést építeni a kérdéses célból? Vagy azt, hogy mi lenne a lehető legminimálisabb bővítő, ami már működőképes és használja a kérdéses bemeneteket? Vagy esetleg valami mást?
Title: Re: NICK
Post by: endi on 2018.June.05. 21:38:16
Nem hülye kérdés ez, hanem határozatlan. Azt szeretnéd tudni, hogy milyen módon kell bővítést építeni a kérdéses célból? Vagy azt, hogy mi lenne a lehető legminimálisabb bővítő, ami már működőképes és használja a kérdéses bemeneteket? Vagy esetleg valami mást?

1: valamit kivezetni az ep-ből, amit erre a bemenetre kötünk
2: a lényeg hogy totál olcsó legyen, mert ügye más értelme nem lenne :)

a kérdés tehát hogy mit lehetne kivezetni? hangot? csíkok jelennének meg a hangmagasság függvényében? :D
persze nyilván ezt csak valamiféle demo vagy játék effektre lehetne használni, semmi komolyabbra
Title: Re: NICK
Post by: Zozosoft on 2018.June.05. 21:43:08
Sok értelme nincs, de egy 74LS138+74LS74 elég arra, hogy két bitet tároljunk, azaz a külső szín jelző bitjét, és egy színbitet. 74LS138+74LS74+74LS273 esetén már mind a 4 színbit eltárolható. Azaz egy Z80-as portra kiírható a színkód, és az, hogy be legyen-e kapcsolva a külső szín.
Sok proci használattal talán valami ábrát is ki lehetne rajzolni... de a CPU lassúsága miatt nem túl jó felbontással.
Title: Re: NICK
Post by: endi on 2018.June.05. 21:45:13
Sok értelme nincs, de egy 74LS138+74LS74 elég arra, hogy két bitet tároljunk, azaz a külső szín jelző bitjét, és egy színbitet. 74LS138+74LS74+74LS273 esetén már mind a 4 színbit eltárolható. Azaz egy Z80-as portra kiírható a színkód, és az, hogy be legyen-e kapcsolva a külső szín.
Sok proci használattal talán valami ábrát is ki lehetne rajzolni... de a CPU lassúsága miatt nem túl jó felbontással.

ja igen, nyilván sok proci időt se foglaljon. ezért gondoltam a hangra.
amúgy ez amit írtál mennyibe került volna annak idején?
Title: Re: NICK
Post by: szipucsu on 2018.June.05. 22:01:27
csíkok jelennének meg a hangmagasság függvényében? :D
A mididisp ezt csinálja, csak nem a hangmagasság, hanem a hangerő függvényében jelennek meg a csíkok. Bár az sem lenne rossz, ha egyből nyomná kifele a játszott zenét kotta formájában, vagy láthatatlan kéz játszana a zongorabillentyűkön. Ilyenre régebben gondoltam is, hogy ahogy olvassa a zenét a data sorokból a basic, lejátszás közben minden hangmagassághoz hozzá van rendelve X és Y koordináta egy tömbben, és az adott helyre odapöttyent egy karaktert, ahol persze zongorabillentyűk vannak. De basicben ledarálná a pöttyentéseket bőven, mielőtt a zene befejeződne. Csak hogy jó messze elkanyarodjak az eredeti témától.
Title: Re: NICK
Post by: Zozosoft on 2018.June.05. 22:01:46
ja igen, nyilván sok proci időt se foglaljon. ezért gondoltam a hangra.
amúgy ez amit írtál mennyibe került volna annak idején?
Kb 50-100 Ft.

Ha külön címtartományba tesszük a bekapcsoló bitet, akkor rátehetjük a szín biteket a Dave 0Axh portjaira, és akkor villoghat a hangokra :-) , és külön kapcsolható az effekt.
Title: Re: NICK
Post by: endi on 2018.June.05. 22:03:05
Kb 50-100 Ft.
Ha külön címtartományba tesszük a bekapcsoló bitet, akkor rátehetjük a szín biteket a Dave 0Axh portjaira, és akkor villoghat a hangokra :-) , és külön kapcsolható az effekt.

akkor azt hiszem most kitaláltunk valami korszakalkotót, ami annak idején korszakalkotó lehetett volna :)
Title: Re: NICK
Post by: ergoGnomik on 2018.June.06. 10:02:20
Sok értelme nincs, de egy 74LS138+74LS74 elég arra, hogy két bitet tároljunk, azaz a külső szín jelző bitjét, és egy színbitet. 74LS138+74LS74+74LS273 esetén már mind a 4 színbit eltárolható. Azaz egy Z80-as portra kiírható a színkód, és az, hogy be legyen-e kapcsolva a külső szín.
Sok proci használattal talán valami ábrát is ki lehetne rajzolni... de a CPU lassúsága miatt nem túl jó felbontással.
Lehet, hogy nem ábrát kellene vele próbálni rajzoltatni, hanem a külső bemenet színprioritásának használatával valami áttűnési hatásokat létrehozni. De ez nem egy jól kidolgozott ötlet. :(
Title: Re: NICK
Post by: endi on 2018.June.06. 11:06:12
Lehet, hogy nem ábrát kellene vele próbálni rajzoltatni, hanem a külső bemenet színprioritásának használatával valami áttűnési hatásokat létrehozni. De ez nem egy jól kidolgozott ötlet. :(

szerintem alapvetően csak ilyen "csíkokat" meg sávokat lehetne csinálni így. mondjuk totál nem értek a hw dolgokhoz.
de emlékszem annak idején nagyon foglalkoztatott hogy vajon mi lehet ez a funkció :)
Title: Re: NICK
Post by: endi on 2018.June.06. 14:09:13
az is eszembe jutott, hogy ez a dolog úgy lett volna király, ha egy másik EP-t lehetett volna forrásnak használni. ez vajon mennyi plusz pénz lett volna a fejlesztésben?