Welcome, Guest. Please login or register.


Author Topic: HW sprite? (Read 1836 times)

Offline gflorez

  • EP addict
  • *
  • Posts: 3607
  • Country: es
    • Támogató Támogató
HW sprite?
« on: 2023.April.12. 10:08:53 »
Álmodni jó...

Azonban egy sprite motor lehetséges a tényleges valós Nick(1.0...).
----

Dreaming is good...

However, a sprite engine is possible with the actual real Nick(1.0...).

Offline Tuby128

  • EP addict
  • *
  • Posts: 1448
  • Country: hu
Re:HW sprite?
« Reply #1 on: 2023.April.12. 11:33:15 »
Nem szakértek hozzá, de... Ebből nem lenne gubanc (itt-ott fagyás) a "lefelé kompatibilitás" témában? Avagy hogy oldanád meg, hogy a memória olyan részeihez férjen hozzá, amik esetleg már egy adott programon belül foglaltak?

Ep128:
 Alapvetően tudni kell, hogy a NICK csak olvas sosem ír. Ez azt jelenti, hogy betekintése bárhova lehet. Ahova pedig lát, onnan képes byte-okat olvasni és a képernyőre tenni.
A nick módosítása nem járhat fagyással, mert nem ír felül semmit, csak olvas.
 Alapvetően ha elindul egy EP a nick 2.0-val akkor ugyanúgy fog működni mint addig. Az újdonság akkor lesz, ha a sorparaméter táblában nem használt biteket átállítunk 1-be.

 Egy dolgot elfelejtettem megemlíteni. Ha kiterjesztem a NICK címbuszát 16-ról 22 bit-re (2^22=4MB), amivel az EP összes szegmensét látni fogja, akkor a videomemória régi címtartománya (0000-FFFF) ami az EP-nél pont az utolsó 4 szegmens (FC-FF) átkerül  a (3F)0000-(3F)FFFF címre. Ez a kompatibilitás miatt nem jó, de ha NICK 2.0-ban letükrözöm ezt a (00)0000-(00)FFFF címtartományra, ahol az EP-ben egyébként a 00.-03. szegmensek vannak (ROM, EXOS etc.) akkor már minden ugyanúgy működik ahogyan eddig. A NICK nem akar hozzáférni a ROM-hoz.

Ergonomik:
 Azért kell a 8bit-nél több adatbusz, hogy minden 2. pixel-órajel (14Mhz/2= 142ns) legyen ott neki az 1 byte. (256 szín).
 Jelenleg a régi Nick kb 6-7 clockpixel után olvas ki 1 byte-ot; Ami 3x-4x lassabb a fenti dolognál, és a régi NICK-nél az is gondot okoz, hogy a Z80 nem akármikor fér hozzá. Ha több bites a NICK adatbusza, akkor a Nick 2.0 egy olvasással több adatot tud betárolni a cache-be (24-32bit), így a memória hozzáférést át tudja adni másnak (pl Z80-nak).

 A dolog nagy kihívása az osztoszkodás a 4MB RAM memórián. Hogy a Z80 is és a NICK 2.0 is időben hozzájusson az információhoz, ahol a NICK 2.0 a legmemóriaéhesebb.

 A közös memóriahozzáférés (Z80 és NICK 2.0) a DAVE lapozó logikáját be kell vinni a Z80-ba.

 Ez EP32 emulátor forráskódját nézegettem. Azt gondolom, módosításokkal le lehetne szimulálni rajta az elképzelésemet. Sajnos Kevin Thacker (a program írója) sok x86 Assembly betétet használt, és alig van komment, ezen előbb át kell rágnom magam, és jegyzetelnem.

Gflorez:
 Nincs hardvare sprite kezelés a NICK-ben. Nem lehet a z80-másolgatás nélkül mozgatni sprite-okat.
 Tanulságos, hogy az Amiga 1000-ben volt Sprite kezelés, de nem használták, mert a beépített memória mező másolás (BLOCK COPY=BLITTER) a video ramba olyan gyors volt, hogy megfelelt a programozóknak. Emiatt én is inkább ebben a második irányban indulnék el.

=EN
 There is no HW based sprite handling in the old NICK. There is no possibility to move a spite without Z80 block copy.
 Interesting thing, that the Amiga 1000 has a Sprite handling, but was rarely used, because the built-in memory field copy (BLOCK COPY=BLITTER) was fast enough, that the programmers used that instead of sprite. I would also go this second way.
« Last Edit: 2023.April.12. 17:01:34 by MrPrise, Reason: Elírás javítása »

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re:HW sprite?
« Reply #2 on: 2023.April.12. 12:00:59 »
Azt értem, hogy a magasabb memória sávszélesség igény miatt kell kiszélesíteni a buszt. És csak a három bájtos szélességet furcsállottam.

A NICK pedig "igenis tud" sprite-ot kezelni. Kicsit nem kézre állóan és a hivatalos bővítő sosem készült el hozzá, de erre valók az External Colour bemenetek (EC0..3 és /EXTC), meg a NICK valamelyik vezérlő regisztere, amiben ennek a prioritás logikáját lehet szabályozni. Pár éve készült egy teszt hardver, amivel balagesz és Zozo elbütykölgettek egy ideig, utána valahogy elhalt a dolog. Talán balagesz élete sűrűsödött be úgy, hogy erre már nem tudott időt szakítani.

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re:HW sprite?
« Reply #3 on: 2023.April.12. 12:03:05 »
Ez EP32 emulátor forráskódját nézegettem.
Nem biztos, hogy azt érdemes nézegetni, mivel az nagyon messze van a tökéletestől. Időzítéseket sem kezeli rendesen, és a Nick összes videómódját sem ismeri rendesen.
Nem is értem miért rángatod folyton elő ezt a régi, kezdetleges emulátort. :oops:

Quote
Nincs hardvare sprite kezelés a NICK-ben.
Ki mondta, hogy van? Azért van rajta a külső színbemenet, hogy odadugod a gép oldalába a sprite kártyát, abban ott izegnek-mozognak a sprite-ok, a Nick meg szépen rákeveri a képre. Ez volt az eredeti terv, csak előbb csődbe mentek, mintsem, hogy ez elkészülhetett volna.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1448
  • Country: hu
Re:HW sprite?
« Reply #4 on: 2023.April.12. 12:16:10 »
Nem biztos, hogy azt érdemes nézegetni, mivel az nagyon messze van a tökéletestől. Időzítéseket sem kezeli rendesen, és a Nick összes videómódját sem ismeri rendesen.
Nem is értem miért rángatod folyton elő ezt a régi, kezdetleges emulátort. :oops:
Ki mondta, hogy van? Azért van rajta a külső színbemenet, hogy odadugod a gép oldalába a sprite kártyát, abban ott izegnek-mozognak a sprite-ok, a Nick meg szépen rákeveri a képre. Ez volt az eredeti terv, csak előbb csődbe mentek, mintsem, hogy ez elkészülhetett volna.

István kilépésével a EP128 emulátor napjai meg vannak számlálva. A fordítása is egy nagyon bonyolult folyamat, amit külön itt a fórumon leírt anno.
Az EP32 emulátor nekem egy virtuális XP gépen van és a visual studio azonnal lefordítja az egészet.
Véleményem szerint az időzítések nem fontosak egy teszt alatt. És ne felejtsük el, hogy új hardver készül. Prezenációra, tesztre, debuggolásra teljesen megfelel.

 A régi nickben nincs hardveres sprite támogatás alatt azt értem, hogy KOMPLETT hardveres támogatás külső eszköz nélkül.
 Olvastam a NICK technikai leírásban a külső színbementről, de én nagyon bonyolultnak tartom, hogy egy külső eszköz figyelje, számolja a Nick által generált elektronsugarat és ha éppen ott van ahol ő azt gondolja, akkor elkezdi a színeket felülírni a 4 bites színbemeneten keresztül.
 Én ezt az utat nem tartom járhatónak.


Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re:HW sprite?
« Reply #6 on: 2023.April.12. 15:07:35 »
...de én nagyon bonyolultnak tartom, hogy egy külső eszköz figyelje, számolja a Nick által generált elektronsugarat és ha éppen ott van ahol ő azt gondolja, akkor elkezdi a színeket felülírni a 4 bites színbemeneten keresztül.
 Én ezt az utat nem tartom járhatónak.
Nyilván nem értek a mögöttes dolgokhoz, amik a tényleges hardverben intéznék az ügyeket, de valamiért nekem nem tűnik ennyire problémásnak. De legfeljebb majd kijavítod mit látok rosszul. A bővítő csatlakozón ott van a NICK órajele és a két szinkronjel is kivezetve. Ezekből azért elég pontosan lehet tudni éppen merre jár a képalkotás.

Egy képpontsor mindig 57*16=912 NICK órajel ciklus. Lehet tudni, hogy a /HSYNC utáni első 8*16=128 ciklusban nem érdemes rajzolni, mert ott olvassa be az LPB-t. Az is tudható, hogy a /HSYNC előtti 3*16=48 ciklusban szintén nem érdemes rajzolni, mert ott a VRAM frissítés folyik. (Úgy kb., mert most nem ugrik be hogyan van pontosan ezeknek az egymáshoz képesti időzítése. :()

Négy regiszterben megadható, hogy a /VSYNC-et követő hányadik sorban (függőleges 0 pozíció) kezdjen sprite-okat szintetizálni és hányadikban fejezze be, illetve a bal és jobb képhatártól mennyivel beljebb legyen a sorban a szintetizálás be- (vízszintes 0 pozíció) és kikapcsolása. Szóval órajelek számolgatásával elég pontosan meghatározható a képalkotás pillanatnyi pozíciója, amit "csak" össze kell vetni a sprite szintézis paramétereivel.

Ha pedig a programozó összevissza alkot az LPT módosítgatásával, akkor legyen szíves erről tájékoztatni a sprite generátort is, mert a megjelenítés menedzselése az ő feladata.

Offline Tuby128

  • EP addict
  • *
  • Posts: 1448
  • Country: hu
Re:HW sprite?
« Reply #7 on: 2023.April.12. 15:22:44 »
Nyilván nem értek a mögöttes dolgokhoz, amik a tényleges hardverben intéznék az ügyeket, de valamiért nekem nem tűnik ennyire problémásnak. De legfeljebb majd kijavítod mit látok rosszul. A bővítő csatlakozón ott van a NICK órajele és a két szinkronjel is kivezetve. Ezekből azért elég pontosan lehet tudni éppen merre jár a képalkotás.

Egy képpontsor mindig 57*16=912 NICK órajel ciklus. Lehet tudni, hogy a /HSYNC utáni első 8*16=128 ciklusban nem érdemes rajzolni, mert ott olvassa be az LPB-t. Az is tudható, hogy a /HSYNC előtti 3*16=48 ciklusban szintén nem érdemes rajzolni, mert ott a VRAM frissítés folyik. (Úgy kb., mert most nem ugrik be hogyan van pontosan ezeknek az egymáshoz képesti időzítése. :()

Négy regiszterben megadható, hogy a /VSYNC-et követő hányadik sorban (függőleges 0 pozíció) kezdjen sprite-okat szintetizálni és hányadikban fejezze be, illetve a bal és jobb képhatártól mennyivel beljebb legyen a sorban a szintetizálás be- (vízszintes 0 pozíció) és kikapcsolása. Szóval órajelek számolgatásával elég pontosan meghatározható a képalkotás pillanatnyi pozíciója, amit "csak" össze kell vetni a sprite szintézis paramétereivel.

Ha pedig a programozó összevissza alkot az LPT módosítgatásával, akkor legyen szíves erről tájékoztatni a sprite generátort is, mert a megjelenítés menedzselése az ő feladata.

Teljesen jól írod le én is ezt olvastam ki a sorokból, így történik ahogyan mondod.

 Semmilyen szoftver nem támogatta soha, mivel hogy nem létezett ilyen eszköz. Ha az EP-vel együtt meg jelent volna, mondjuk az exdos dobozába integrálva, és nem egy vagyon lett volna, akkor biztos lett volna rá fejlesztve. Habár a legjobb az lett volna, ha a nick tartalmazza ezt mint a C64-ben, akkor nem kellene számolgatni a pixeleket.