Welcome, Guest. Please login or register.


Author Topic: NICK (Read 230725 times)

Offline Tuby128

  • EP addict
  • *
  • Posts: 1487
  • Country: hu
Re: NICK
« Reply #105 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)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #106 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 (ebben "ET1/1" a NICK leírás).
Pontosan milyen információt keresel egyébként ?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #107 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). 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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #108 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
« Last Edit: 2011.January.25. 13:19:50 by IstvanV »

Offline Zozosoft

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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #110 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.

Offline Ferro73

  • EP addict
  • *
  • Posts: 1016
  • Country: hu
Re: NICK
« Reply #111 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 ?

Offline Ferro73

  • EP addict
  • *
  • Posts: 1016
  • Country: hu
Re: NICK
« Reply #112 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/?

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: NICK
« Reply #113 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
Vigyázat! Szektás vagyok! :)

Offline Tuby128

  • EP addict
  • *
  • Posts: 1487
  • Country: hu
Re: NICK
« Reply #114 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)
« Last Edit: 2011.January.27. 07:04:47 by tubybb »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #115 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.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1487
  • Country: hu
Re: NICK
« Reply #116 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 található

Offline vizor

  • EP fan
  • *
  • Posts: 238
  • Country: hu
Re: NICK
« Reply #117 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  :)

Offline Zozosoft

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

Offline vizor

  • EP fan
  • *
  • Posts: 238
  • Country: hu
Re: NICK
« Reply #119 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  :)