Welcome, Guest. Please login or register.


Author Topic: NICK (Read 162927 times)

Offline lgb

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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #406 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).
« Last Edit: 2016.March.03. 10:51:22 by IstvanV »

Offline lgb

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

Offline IstvanV

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

Offline lgb

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

Offline lgb

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

Offline Zozosoft

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

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #412 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?
« Last Edit: 2016.March.04. 11:16:26 by lgb »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #413 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).
« Last Edit: 2016.March.04. 12:01:22 by IstvanV »

Offline Zozosoft

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

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #415 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 ...
« Last Edit: 2016.March.04. 15:36:12 by lgb »

Offline lgb

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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK*
« Reply #417 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.
« Last Edit: 2016.March.04. 18:17:27 by IstvanV »

Offline lgb

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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #419 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:
[ Guests cannot view attachments ]
ep128emu-n így néz ki:
[ Guests cannot view attachments ]
« Last Edit: 2016.March.04. 19:25:53 by IstvanV »