Welcome, Guest. Please login or register.


« previous next »
Pages: 1 ... 23 24 25 26 27 28 29 [30] 31 32 33   Go Down

Author Topic: NICK (Read 220078 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #435 on: 2016.August.17. 08:24:10 »
Quote from: lgb on 2016.August.17. 00:36:41
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.

Úgy értettem, a soron belül olvassa a keret alatt a sprite adatokat. Egy sor 63 karakter PAL gépen, ebből 40 a képernyő, 5 DRAM frissítés, és marad 18 egyéb célra, a sprite olvasás (legfeljebb 8*4=32 byte) 16 karaktert igényel. Itt a 3.6.3-nál lehet részletesebben olvasni az időzítésről.
Logged

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #436 on: 2016.August.17. 20:52:03 »
Quote from: IstvanV on 2016.August.17. 08:24:10
Úgy értettem, a soron belül olvassa a keret alatt a sprite adatokat. Egy sor 63 karakter PAL gépen, ebből 40 a képernyő, 5 DRAM frissítés, és marad 18 egyéb célra, a sprite olvasás (legfeljebb 8*4=32 byte) 16 karaktert igényel. Itt a 3.6.3-nál lehet részletesebben olvasni az időzítésről.

Na ennyire azert tenyleg nem tudom :-D Csak ami gyanus volt (es meg mindig csak megerzes alapjan mondom): mi van ha 8 sprite esik egy scanline-ra, az 3*8=24 byte info amit olvasni kell, plusz ha meg uj karaktersor is kezdodik (badline), biztos nem fer bele "csak a keretbe". Az meg kulon erdekes, hogy mi van, ha kikapcsolod a keretet, es mondjuk van 8 sprite a jobb kereten meg a bal kereten is (sprite multiplexing-gel talan lehetseges, bar nem tudom hogy az egy scanline-on belul muxik-e). Node, ha csak siman 8 sprite van egy scanline-ban mindenfele idozitett reg atiras nelkul, mar az is erdekes, kerettel meg foleg annelkul. Mondjuk ezekben az FLD, FLI, ez/az VIC-II trukkokben nem vagyok tul nagy mester, finoman szolva :D
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #437 on: 2016.August.18. 09:34:48 »
Egy soron belül a VIC-II legfeljebb 61 karakternél használja az adatbuszt, és a teljes sor 63 (PAL) vagy 65 (NTSC) karakter:
- 5 karakter DRAM frissítés
- 40 karakter képernyő (bad line esetén ilyenkor mindkét fél ciklusban a VIC-II aktív), 40 byte vagy 80 byte + 40 * 4 bit video adat
- 2 (PAL) vagy 4 (NTSC) karakter nem használt (idle)
- 16 karakter sprite olvasás (egy sprite 4 byte, 1 byte mutató (a cím felső 8 bitje) + 3 byte pixel adat), ez a bad line-hoz hasonlóan mindkét fél ciklust használja és leállítja a CPU-t
Bad line vagy aktív sprite esetén a CPU-t 3 karakterrel az olvasás előtt le kell állítani, ez alatt az idő alatt még befejezheti az esetleges írási műveletet (ami legfeljebb 3 egymást követő byte lehet, IRQ elfogadásakor).
Logged

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: NICK
« Reply #438 on: 2016.August.18. 19:01:06 »
:) Oke, ehhez mar tenyleg nem tudok mit hozzatenni :D
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #439 on: 2016.September.24. 19:28:42 »
Quote from: IstvanV on 2013.August.29. 17:29:35
FIXBIAS scroll lebegő adatbusz olvasással időzítve:
fbscroll.com
Csak 4 MHz-es valódi gépen működik. ep128emu-n ez a script javítja az időzítési hibát (így sem egészen pontos, mert igazi gépen nem karakterhatáron változik a szín, hanem egy 16 színű pixellel korábban):
nickread.lua

Ez a program most már működik Lua script nélkül is az emulátor GitHub-on taláható aktuális forrásával, ha nem is tökéletesen, az időzítésen még lehetne javítani.

Egy másik lebegő adatbusszal kapcsolatos újdonság: ha a jobb margó nagyobb mint 54, akkor az ott található karakter a valódi géphez hasonlóan az utolsó olvasott byte-ot ismétli, bár ennek a gyakorlatban ritkán van jelentősége.
Logged

Offline geco

  • EP addict
  • *
  • Posts: 7218
  • Country: hu
    • Támogató Támogató
Re: NICK
« Reply #440 on: 2016.September.25. 17:28:09 »
Quote from: IstvanV on 2016.September.24. 19:28:42
Egy másik lebegő adatbusszal kapcsolatos újdonság: ha a jobb margó nagyobb mint 54, akkor az ott található karakter a valódi géphez hasonlóan az utolsó olvasott byte-ot ismétli, bár ennek a gyakorlatban ritkán van jelentősége.
Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #441 on: 2016.September.25. 20:16:56 »
Quote from: geco on 2016.September.25. 17:28:09
Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )

Ezzel a beta verzióval ki lehet próbálni, ebben már megtalálhatók a fent említett módosítások, illetve az fbscroll.com is jól működik.
Logged

Offline geco

  • EP addict
  • *
  • Posts: 7218
  • Country: hu
    • Támogató Támogató
Re: NICK
« Reply #442 on: 2016.September.25. 20:43:00 »
Köszi, letöltöttem
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #443 on: 2016.September.26. 09:01:30 »
Ezzel az egyszerű BASIC programmal tesztelhetők a "szabálytalan" margók, 49 karaktert próbál megjeleníteni egy sorban. Érdemes lenne megnézni valódi gépen olyan monitorral, amin beállítható, hogy láthatóak legyenek ezek a karakterek is. Azonban nekem TV kártyával S-video kimenetről az első oszlopban nincs kép, ott még a vízszintes szinkron van.

[ Guests cannot view attachments ]
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #444 on: 2016.September.26. 13:01:04 »
Quote from: IstvanV on 2016.September.26. 09:01:30
Érdemes lenne megnézni valódi gépen olyan monitorral, amin beállítható, hogy láthatóak legyenek ezek a karakterek is.

Néhány régebbi képen látható a valódi gépen megjeleníthető szélesség itt és itt. Ezek szerint a 7-es pozíciónál (ami az emulátoron az első oszlop) még nincs kép, és még a 8-asnál is az első "érvényes" karakter kb. fele elveszik. Tehát normál 40 karakteres módban a bal keret csak kb. 2.5 karakter széles. A jobb keret viszont az emulátorral megegyező szélességű, és az 54-es pozíciónál egy oszlop még látható, ahol az utolsó byte ismétlődik. Talán az RGB kimenet eltérő, legalábbis a burst jelet nem tartalmazza a bal oldalon.
« Last Edit: 2016.September.26. 13:32:11 by IstvanV »
Logged

Offline geco

  • EP addict
  • *
  • Posts: 7218
  • Country: hu
    • Támogató Támogató
Re: NICK
« Reply #445 on: 2016.September.26. 13:14:14 »
Akkor az eddigi maximális 46-os képeinkből is valójában csak 45,5 látszik.
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #446 on: 2016.September.26. 13:27:02 »
Quote from: geco on 2016.September.26. 13:14:14
Akkor az eddigi maximális 46-os képeinkből is valójában csak 45,5 látszik.

Feltéve, hogy ugyanez a probléma monitoron is megjelenik RGB kimenetről, ezt nem tudtam kipróbálni. :oops: Elméletileg lehetne különböző, mert a kapcsolási rajz szerint a NICK /BLANK és /BURST kimeneteit csak a kompozit videót előállító LM1886/LM1889 áramkör használja. Zozosoft már jelenített meg 46x300 méretű IVIEW képeket CRT monitoron. :)
Logged

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: NICK
« Reply #447 on: 2016.September.27. 13:09:27 »
Elvileg egyébként lehetséges lenne 47 karakter szélességű módot megvalósítani, az utolsó byte-ot minden sorban megfelelő időzítéssel valamelyik NICK portra kiírva. Természetesen ennek a hasznossága korlátozott, mert folyamatosan használja a CPU-t, és az utolsó oszlopban csak egy byte video adat lehetséges (LPIXEL módok).
Logged

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: NICK
« Reply #448 on: 2016.September.27. 13:31:58 »
Quote from: IstvanV on 2016.September.27. 13:09:27
Elvileg egyébként lehetséges lenne 47 karakter szélességű módot megvalósítani, az utolsó byte-ot minden sorban megfelelő időzítéssel valamelyik NICK portra kiírva. Természetesen ennek a hasznossága korlátozott, mert folyamatosan használja a CPU-t, és az utolsó oszlopban csak egy byte video adat lehetséges (LPIXEL módok).

:mrgreen:
Logged
Vigyázat! Szektás vagyok! :)

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: NICK
« Reply #449 on: 2016.October.02. 18:07:23 »
van ügye a hires 2 mód. ilyenkor 2x olyan magas a pixel mint széles. grafikus szemmel nézve eléggé használhatatlan ez. bár nem tudom a "vízszintes tégla" miért jobb, biztos van valami oka.
de amiért most ezt írom: van más gép, ami tudott ilyen "függőleges tégla" arányú pixelt? :)
Logged
Vigyázat! Szektás vagyok! :)
Pages: 1 ... 23 24 25 26 27 28 29 [30] 31 32 33   Go Up
« previous next »

SMF 2.0.19 | SMF © 2021, Simple Machines XHTMLRSS
Discord Linode Follow ep4ever_news on Twitter