Welcome, Guest. Please login or register.


Author Topic: NICK (Read 98164 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #420 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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #421 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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #422 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:
* mv.pic (53.92 kB - downloaded 108 times.)
* il_test.pic (3.21 kB - downloaded 104 times.)

A Boulder Dash nem működik a 4 színű karakteres mód hiánya miatt. :oops:
« Last Edit: 2016.March.06. 20:27:59 by IstvanV »

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #423 on: 2016.March.06. 21:06:52 »
Atmasztam a Xep128 topic-ba, ez mar kevesbe Nick/hw specifikus, max igencsak erintolegesen :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #424 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 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.
« Last Edit: 2016.March.07. 11:44:59 by IstvanV »

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13315
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #425 on: 2016.March.07. 11:47:49 »
75Hz-es monitor mennyire jó?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #426 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.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13315
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 44.0 Firefox 44.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #427 on: 2016.March.09. 19:23:05 »
azt lenne még érdemes megnézni, hogy valódi gépen is ilyen-e.
15037-0

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: NICK
« Reply #428 on: 2016.March.09. 19:29:18 »
Úgy látszik, ez a program nem talált emulátor hibát. :)

Offline endi

  • EP addict
  • *
  • Posts: 6997
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 48.0.2564.116 Chrome 48.0.2564.116
    • View Profile
    • Honlapom
Re: NICK
« Reply #429 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? :)
A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13315
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
    • http://enterprise.iko.hu/
Re: NICK
« Reply #430 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.

Offline endi

  • EP addict
  • *
  • Posts: 6997
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 52.0.2743.82 Chrome 52.0.2743.82
    • View Profile
    • Honlapom
Re: NICK
« Reply #431 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...
A diplomás magyar programozó megcsinált egy pacmant egy év alatt, majd lefikázta a világ legjobb játékait. :D

Offline szipucsu

  • EP addict
  • *
  • Posts: 7628
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: NICK
« Reply #432 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
SOUND SOURCE 3,STYLE 16,LEFT 16,RIGHT 64,SYNC 2
SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 2
SOUND PITCH 25,SYNC 2
Videos
OPEL #1:"Audi(o):" ACCESS DENIED

Offline IstvanV

  • EP addict
  • *
  • Posts: 4804
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: NICK
« Reply #433 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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 48.0 Firefox 48.0
    • View Profile
    • http://lgb.hu/
Re: NICK
« Reply #434 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 ...