WinTVC 1.0.5

[Gaia]

Tegnap feltettem a WinTVC 1.0.5-öt. A szokásos háromféle verzióban letölthető itt:

http://gaia.atilia.eu/content/view/3/4/

Újdonságok:

- pixel alapú rasztermód kiterjesztése a teljes képernyőre
- video mentése AVI állományba
- hangfelvétel rögzítése WAV (16 bit PCM) állományba
- opcionális jobb hangminőség (teljesítmény rovására)
- hibajavítások (monitor, I/O, GUI)

[teki]

Mennyire pontos a pixel alapu megjelenites? Tesztelted valamivel ? Tervezem irni egy EMUDIAG progit, amivel ilyesmiket lehetne ellenorizni, csak nekem nincs mihez hasonlitani.

[Atka72]

A monitorban mik lettek javítva? Szoktam használni hibakeresésnél lépésenkénti összehasonlításra. Úgy vettem észre LDIR utasítás egyel több lépés volt mint ahogy vártam, ill a jelzőbitek állítása se a leírások alapján módosult. Ettől függetlenül persze a legjobb TVC emu amit eddig láttam
Ötletként esetleg egy log fájl a regiszterekről megvalósítható lenne benne?
/Eddig csak úgy tudtam megoldani hogy egy progi mindíg küld egy entert, és ocr-el beolvassa a monitor ablak tartalmát, ami működik, de nagyon lassú sajnos/

[Gaia]

teki: na, tesztelni azt nem volt időm igazi vason, de még nagyobb gond hogy nem is tudnék transzferálni a magnót kivéve, ami hát nem az igazi. Ezért nagyon gyúrok az új SD kártyára, de ez egy sokparaméteres egyenlet (vagy inkább egyenlőtlenség), ahol a hely és a szabadidő igen korlátos. A clock stretching sem az igazi még, úgyhogy inkább kikapcsoltam egyelőre, tehát ez azt jelenti, hogy a video sem pixelre pontos, de már legalább pixel alapú. A tied mintha más "koordináta-rendszert" használna, legalábbis az egyik raszter demód az enyémen máshol "riceg" (C= plus/4-es szleng arra, ha ha nem stabil a raszter). Még ellenőrizni kell ezt is. Most a horizontal count az a jobb keret szélén nulla nálam, de valójában szinte biztosan nem ott van, hanem a window area bal szélén.

Egyébként azt hiszem az interlace-elt video módom sem jó még, mert alapból a páratlan sorokat rajzolja és a valódi vason páros sorok jelennek meg (legalábbis a a legtöbb 8 bites mikrón ez a helyzet, ahol oszcilloszkóppal is ellenőrizve lett a VBLANK szignál). Szóval van még teendő bőven... elég nehezen is szántam rá magamat éppen ezért.

Egy szó, mint száz, ez a szokásos 80-20-as problémakör: az idő/erőfeszítés 80%-a elmegy a munka utolsó 20%-ára

Attila: köszi a dícséretet a monitorban egy olyan hiba lett javítva, hogy ha volt Windows message (jellemzően billentyűleütés vagy ilyesmi), akkor még lépett egyet. Ez a majdani "run to cursor" módban (lett volna) zavaró. Ami még javítva lett, az az ha felfele lapozol a nyilakkal, akkor okosan kitalálja milyen utasítás lehetett ott és annyit lép, nem csak bután megy egy byte-ot visszafele. Az LDIR az akkor CPU bug lenne, ezt jó hogy mondod, mert pont a TVC miatt írtam át anno (2005?), hogy közben is lehessen interrupt, elképzelhető, hogy becsúszott  egy hiba, majd megnézem, köszi. Log: milyen regiszterekre gondoltál? CPU vagy CRTC?

[Gaia]

Attila: aha, értem mire céloztál az LDIR-rel. Eddig valahogy fel sem tűnt, de eggyel több iterációban megy (visszalépteti a PC-t), ami csak a debuggerben látszik, mert a ciklusszám az jó. 2004. november 21-én írtam át, megtaláltam a "patch"-et

Köszi

[Atka72]

Alapvetően a CPU regiszterekre gondoltam, már az is jó lenne. De ha még a CRT ill a most főként érdekes 1793 regiszterek is láthatóak lennének  és mindehez még egy PC-t figyelő töréspont kezelő is lenne, azzal nagyon nagy segítségünkre volnál a fejlesztésben. Remélem nem vagyok túl szerénytelen

A raszter demo nálam nem csíkozza a betűket , egyben villog az összes színe. Ezek szerint ti minden sor rajzolása előtt megnézitek a palettaregiszter tartalmát. Erre nem gondoltam. A képkezdést hogyan /melyik regiszterrel/ lehet a legegyszerübben mefigyelni?

[teki]

> A clock stretching sem az igazi még, úgyhogy inkább kikapcsoltam egyelőre, tehát ez azt jelenti, hogy a video sem pixelre pontos, de már legalább pixel alapú.

Clock stretching meg nekem is hatra van, de ahhoz mar tenyleg gep kell.

> A tied mintha más "koordináta-rendszert" használna, legalábbis az egyik raszter demód az enyémen máshol "riceg" (C= plus/4-es szleng arra, ha ha nem stabil a raszter). Még ellenőrizni kell ezt is. Most a horizontal count az a jobb keret szélén nulla nálam, de valójában szinte biztosan nem ott van, hanem a window area bal szélén.

Hat a megjelenites az 6845 szerint megy. A raszter demok fuggenek a helyes irq es a helyes kesleltesesektol. Nem hiszem hogy pontosak nekem, de ahhoz teszt progik kellenek, ahhoz alltam neki flopyy+assembler megvalositasahoz eloszor. (+ c, mert asm kicsit lassu [irni], s sdcc eleg jonak tunik)

> Egyébként azt hiszem az interlace-elt video módom sem jó még, mert alapból a páratlan sorokat rajzolja és a valódi vason páros sorok jelennek meg (legalábbis a a legtöbb 8 bites mikrón ez a helyzet, ahol oszcilloszkóppal is ellenőrizve lett a VBLANK szignál). Szóval van még teendő bőven... elég nehezen is szántam rá magamat éppen ezért.

Azt egyenlore nem is tervezem.

> Egy szó, mint száz, ez a szokásos 80-20-as problémakör: az idő/erőfeszítés 80%-a elmegy a munka utolsó 20%-ára

Teny. En is csak heti par orat irogatom a dolgot. Sajna vatera-val es tarsaival nincs szerencsem, igy eleg eselytelennek tuni hogy tudjak valodi TVC-t szerezni.

Jo moka amugy emut irni, imadnivalok ezek a specifikaciok.

[Gaia]

Atka72:

Már értem. A CPU loggolás az alapesetben drága móka, mert pillanatok alatt több 100 megabyte méretű lesz. Ezért jobb, ha mondjuk mindig csak az utolsó 100 utasítás lenne loggolva. Ehhez valami fix méretű láncolt listában (vagy ring bufferben) lehet gondolkodni és a WinTVC architektúrája olyan, hogy ezt plusz performance penalty nélkül tudná is... meglátjuk

Raszter: nem elég minden sor elején megnézni, de ettől még sok emulátor így csinálja. Sajnos ez már igazából egy olyan módszer ami a gépek sebességének növekedésével meghaladottá vált. Ha belegondolsz ez egyfajta alulmintavételezése a video regisztereknek, aminek elkerülhetetlenül artifact-jei lesznek, mint bármi másnak.  Vannak gépek, ahol nem lehet a raszter írni/olvasni így szinte semmi módja nincs annak, hogy a képgenerálásba beavatkozzunk (pl. a Primo-nál elég elszántnak kell lenni).

Először is be kell vezetned raszterszámlálókat (ideális esetben a gépre és a TV-re is). Ez az alap. Innentől kezdve két architektúra lehetséges. Az első, egyszerű de bombabiztos megoldás az, ha a video pixel órajel köré szervezed az emulátor működésést a CPU utasítások helyett, és onnan hívod meg mikrokód szinten a CPU emulációt (tehát M1, M2 stb mind külön ág lesz).

A másik, sokkal bonyolultabb mód esetén marad a CPU alapú rendszer, de az utasítások végrehajtását előre "programozott" események szakíthatják félbe. Ilyen pl. az ha a diszk megszakítást generál, vagy változik mondjuk a keretszín, esetleg  a hangregiszterek értéke stb. Én ezt a módszert követem a WinTVC-vel. A CRTC regiszterek értékei alapján előre tudni mikor lesz pl. a képernyő vége (leegyszerűsítve: sorok száma × 200 CPU ciklus - aktuális pozíció), ez egy visszatérő esemény. Természetesen ha változik egy CRTC regiszter értéke, akkor újra kell számolni. Minden CPU ciklus számolásnál egy ciklusszámra rendezett láncolt listában megnézzük esedékes-e valami, és ha igen meghívunk egy ún. callback függvényt (nem muszáj callback, lehet egy nagy switch/Select Case is, csak akkor kevésbé generikus a kód).

[Atka72]

Hát igen a loggolás valóban sok helyet foglalhat, de sebaj ráfér a hdd-re. Viszont a hibakeresést nagyon megkönnyíti.
A legkissebb hiba is egyből kiderül és nem kell végigmenni több száz utasításon manuálisan.

A CRT emulációm eddig nagyon le volt egyszerűsítve, most írom át hogy legalább a képméret beállítások működjenek.
valószínűleg sosem lesz pixel alapú mert sztem nagyon lelassítaná a megjelenítést, és igazából eddig csak tesztprogramokat láttam amik ki tudják használni a spéci effekteket. De a tiédbe legalább ki tudom majd próbálni ha demót írok:)

Az űrszektor végre jó lett:) Viszont van több cartridge játék is ami nem akar elindulni és ugyanabba a memóriarészbe szorul be mint a floppy vezérlő. Na egy ilyet leloggolok és hátha kiderül a turpisság, legalábbis remélem.

Pár éve egyébként pont a te emulátoraidat látva gondoltam hogy nekem is meg kéne próbálni. A primó volt az első azt szerettem nagyon egyszerű és nincs benne memórialapozás:) . A HT is működik de a programok betöltésénél a legtöbb valamiért eltolódott a memóriában, ezért nem futnak. Ha a TVC-t sikerül rendbe tenni akkor előveszem azokat is.

[teki]

jstvc-ben a crtc a kov keppen mukszik:
cpu_time_diff = cpu_run(); // 1 utasitas ideje
6845_run(cpu_time_diff);
draw_screen();

A 6845_run kimenete az egy stream (ringbuffer), amibe irja az epp aktualis memoriacim tartalmat, vagy a bordert. En 16-biten tarolom, az extra 8 bit jol flageknek (hsync,vsync).
A draw_screen olvassa ezt a stream-et, es rajzol a bitmap-be:
26 scanline-al a vsync kezdete utan kezdi a rajzolast, 288 sort rajzol.
16 karakterrel a hsync kezdete utan kezdi rajzolni a sort es 76 karakternyit rajzol.

A TVC sajatossaga, hogy a vsynv vege az a cimregiszter 9-edik bitjere van kotve.
Nem is ertem miert a vsync kezdetetol kezdem a szamlalast, bar azt se tom mit csinal a CRT ha valaki megvaltoztatja a vsync kezdetet? (hosszu vsync-et letrehozva ezzel)

A vizszintes sync jelnek a kezdete programozhato, de a hossza nem, azt az aramkorok felulbiraljak, igy en annak kezdetehez idozitettem a rajzolast.

[Atka72]

Hadd kérdezzem meg hogy a gyors Boot hogy működik nálad , a rom-ot módosítod és kihagyod az ellenőrzéseket, vagy az emu trükköz? Jó lenne egy ilyen gyorsított rom hibaellenőrzéskor, mert a kezdő memóriatesztekre sokat kell várni mire végre elindulnak a lényegi folyamatok. TVC emuba nekem egy kicsit hiányzik hogy nem tudom lecserélni a rom tartalamat csak a beépítettekre, ezt nem tervezted beépíteni? 

Ami eddig kiderült nálam: a  Halt utasítás kezelését hibás logika szerint csináltam, javítottam de még vannak gondok.

[Gaia]

Most fejből írok, mert nincs előttem a forrás. Emlékeim szerint az 1.2-ben a ROM-ot patch-eltem meg a könyvben kommentált ROM lista segítségével, a 2.2-esben viszont már vannak rendszerváltozók, amikbe bizonyos értéket írva kihagyja a teszteket, meg a bejelentkező képernyőt. A ROM csereberélő user interface jó ötlet, a legtöbb emulátoromban megcsináltam, de mindig nagy tortúra dialógusablakokat tervezgetni ezért amíg lehet halogatom... Vannak ilyen módosított ROM-ok?

[Atka72]

Egyenlőre nincs csak tervezem a ROM módosításokat. A loggolás miatt kérdeztem hogy van e ilyen megosztható gyorsított ROM tartalmad. Kicsit gyorsítottam a logoló progimon így már kibírható végülis a sebessége. Ha nem gond fel is raktam ide hátha más is fel tudja használni.
Mint kiderült az Interruptokat se jól kezeltem, nem csoda hogy nem jól ment sok program. Renbe kell előbb tennem a hibákat hogy izgalmasabb dolgokkal tudjak foglalkozni.

[teki]

En aszittem a gyors boot az csak egy snapshot. A memoria ures, szal tuti jol tomoritheto, s nem tartha sokaig kitomoriteni.

[Atka72]

Én is Spapshot-ból csináltam a gyors bootolást, csak tömörítés nélkül , de jó ötlet.
Érdekes hogy nálatok az in(5)  és in(89) teljesen más eredményeket ad, de ettől függetlenül minkettő emu teljesen jól működik.
Ahogy látom a WinTVC  nem írt portjai nem FF-et adnak vissza hanem 0-át a JSTVC-ben viszont ok.