Welcome, Guest. Please login or register.


Author Topic: NICK (Read 220728 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #60 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!

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #61 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.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #62 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.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #63 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.

Offline MrPrise

  • Administrator
  • EP addict
  • *
  • Posts: 2764
  • Country: hu
    • Enterprise Forever
Re: NICK
« Reply #64 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

Offline tigrian

  • EP user
  • *
  • Posts: 400
  • Country: hu
Re: NICK
« Reply #65 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
re' mi' do' do sol

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #66 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!

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #67 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.

Offline tigrian

  • EP user
  • *
  • Posts: 400
  • Country: hu
Re: NICK
« Reply #68 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.



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.



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

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



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



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.



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)



(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:


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



[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....
re' mi' do' do sol

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #69 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.

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #70 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.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #71 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.

Offline MrPrise

  • Administrator
  • EP addict
  • *
  • Posts: 2764
  • Country: hu
    • Enterprise Forever
Re: NICK
« Reply #72 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

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: NICK
« Reply #73 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)

Offline tigrian

  • EP user
  • *
  • Posts: 400
  • Country: hu
Re: NICK
« Reply #74 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:
re' mi' do' do sol