Welcome, Guest. Please login or register.


Author Topic: Assembly programozás (Read 254508 times)

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re: Assembly programozás
« Reply #720 on: 2013.November.16. 12:40:18 »
Bocsika! Jól értem, hogy a sprite adatokat a videoszegmensekben akarod tárolni? Ha igen, én ellenjavalltnak tartom, mivel akkor nem csak a memória írását, hanem a forrásadatok olvasását is lassítani fogja a Nick. Ha félreértettem, akkor dupla bocsika és nem szóltam semmit. (Nem szorosan ide tartozó megjegyzés: ezért próbálják Amigán a gyorsítókártyáknál a rajzoló algoritmusokat arra optimalizálni, hogy mire a következő Chipmem hozzáférési lehetőség bekövetkezik a következő kiírandó adat is rendelkezésre álljon, és íráson kívül ne kelljen más hozzáférést végezni.)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Assembly programozás
« Reply #721 on: 2013.November.16. 12:56:31 »
Quote
Jól értem, hogy a sprite adatokat a videoszegmensekben akarod tárolni?
Hát sajnos jól ... :(

Az van, hogy nem tudom ez mennyit fog lassítani, még a csillagokkal vackolok mindíg, nem értem még el a sprite -okig, és az eddigi sprite tesztjeim persze "fast" RAM forrással történtek, de (eddig) abban reménykedtem, hogy itt EP -n ez a video RAM olvasás dolog majd nem sokat fog lassítani.

Mivel a kirajzoló kódok gyorsítása érdekében 100H -s képernyő scanline- okkal dolgozok (hogy ne kelljen a függőleges koordinátákat szorozgatni scanline mérettel), ezért a képernyőm megenne 3 szegmenst gyakorlatilag, és muszaly kihasználnom a közöket, nyilván helyfoglalás szempontjából adják magukat a sprite adatok.

Ahhoz hogy ne kelljen a közöket kitöltenem, ahhoz vagy szakítanom kéne a 100H -s scanline- ok módszerével (ami nem 100%, hogy hülyeség lenne, ha ez a video RAM olvasás dolog tényleg sokat lassíthat),
vagy pedig akkor a középső két lapon nem tarthatnám ott fixen a video szegmenseimet, hanem egyik egy forrás "fast" RAM szegmens kéne legyen, de akkor minden kódomat úgy kéne írjam, hogy a lapozgatást kezelni tudja.
Ami azt jelentené, hogy egy sprite egyik felét tudni kéne kirajzoljak mondjuk egyik lapozás mellett a kepernyő felsőbb, másikat másik lapozás mellett az alsóbb részére ... ami részint további bonyolódást jelentene, részint hát ott van a függőleges csillagmozgás is, ahol akkor a direktben tárolt 2 szegmensnyi adatot igénylő verziót kéne alkalmazzam, és egyrészt túlzásnak is tartanám, másrészt akkor már csak egy szegmens maradna mondjuk a grafikának, és már el is fogytak ... pedig egy ilyen kavarásnál már kijárna a hangnak is egy külön állandóan belapozott 16K -s teljes szegmens ...

Vagy pedig még azt lehetne, hogy 128K gépen sem mennék ... hanem kellene a 128K -n felül 1-2 plussz szegmens is ... :)

Szóval egyrészt nem tudom mennyi lesz ez a lassulás a video RAM olvasásból, másrészt nem tudom előzőek közül melyik kezembe harapjak.
Z80 System

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1291
  • Country: hu
  • Stray cat from Commodore alley
Re: Assembly programozás
« Reply #722 on: 2013.November.16. 13:56:59 »
IstvanV és Zozo, a segítségeteket kérném! Próbáltam elméletben számolgatni a videoszegmensek elérésével kapcsolatban egy kicsit, de mivel tudásom parányi, eléggé hihetetlen érték jött ki. Egy videosor 57(*2 - órajel két fázisa) Nick buszciklusig tart. Ebből 8(*2) az LPB beolvasása, 3 memória frissítés vagyis marad 95. Ebből jön le a tényleges képernyőtartalom elérése, ami (RMARGIN-LMARGIN)*[1|2]. 40 oszlopos kép esetében ez lehet 40 vagy 80 félciklus, mely utóbbi esetében csak 15 hozzáférési lehetőség jutna a Z80-nak 256 T ciklusonként (4MHz-es processzor) , ami szerintem elképesztően kevés. Hol a hiba a számolásomban?

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Assembly programozás
« Reply #723 on: 2013.November.16. 14:15:32 »
Quote
Szóval egyrészt nem tudom mennyi lesz ez a lassulás a video RAM olvasásból,
De ha tényleg komolyat szakít a sprite kirakásban, ha a forrás a video RAM, akkor most még egy olyan dolog felötlött bennem, hogy oly módon, ahogy a csillagmozgás is külön, saját szegmensre került és a nullás lap át van rá lapozva,

úgy a sprite -ok is kerülhetnének egy ilyen saját szegmensre. Csak a sprite adatok, meg a sprite- okat kirajzoló kód. Akkor kb. ugyanannyi hely lenne(kicsit persze kevesebb) azon a saját szegmensen a sprite adatoknak, mint amennyi most maradna nekik a scanline- ok között.

és akkor az F8 szegmensen lévő kód (a főprogram) előállítaná a pozícióikat (meg ugye mindenmást), és lenne az F9 -en a csillagok kód+adat, meg az FA -n mondjuk a sprite -ok kód+adat.

és akkor a video szegmenseken a scanline -ok kozott gyakorlatilag lehetne a hangok háttérpuffere, amhonnan feltoltom a 6K -s hang pufferemet.

és még mindíg maradt akkor az FB szegmens szabadon.
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #724 on: 2013.November.16. 14:52:41 »
A video várakozást közelítően úgy lehet számolni, hogy az előző video hozzáférés óta eltelt Z80 ciklusok számához hozzá kell adni 1.5-öt, és az eredményt felfelé kerekíteni 4.5 legközelebbi egész számú többszörösére. A várakozás annyi, amennyievel ezek a műveletek növelték a ciklusszámot. Ez nem egészen pontos módszer, és az emulátor sem így számolja az időzítést, de eygszerű esetekben (gyakori hozzáférés ciklusban) általában elfogadható eredményt ad.

Figyelni kell arra is, hogy a video hozzáférések pontosan mikor történnek az utasításon belül. A Z80 dokumentációkban megtalálható az utasítások időzítése M-state-ekre lebontva, ezeken belül a tényleges memória vagy I/O művelet időpontja a következő:

M1: 2.0 ciklus a 4-ből
normál memória olvasás/írás: 2.5 ciklus a 3-ból
I/O port ovasás/írás: 3.5 ciklus a 4-ből

Példa: sok LDI utasítás egymás után nem video RAM-ban fut várakozás nélkül, és video RAM-ból video RAM-ba másol. Ennek az utasításnak az időzítése: M1 (4 ciklus) + M1 (4 ciklus) + olvasás (3 ciklus) + írás (3 ciklus) + regiszterek módosítása (2 ciklus). Azaz 4 memória művelet történik 2.0, 6.0, 10.5, és 13.5 ciklusnál, ebből az utolsó 2 video RAM hozzáférés. Ezeknek az időzítése:

10.5 - 13.5 + 16 = 13 ciklus, +1.5 = 14.5 ciklus, kerekítve 4.5*4 = 18 ciklus, a különbség 5 ciklus
13.5 - 10.5 = 3 ciklus, +1.5 = 4.5 ciklus, kerekítve 4.5*1 = 4.5 ciklus, a különbség 1.5 ciklus

Tehát az LDI utasítások átlagosan 16 + 5 + 1.5 = 22.5 ciklus alatt futnak le (közelítően).

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Assembly programozás
« Reply #725 on: 2013.November.16. 15:02:08 »
Quote
Tehát az LDI utasítások átlagosan 16 + 5 + 1.5 = 22.5 ciklus alatt futnak le (közelítően).
És ha a forrás és a cél is "fast" RAM, akkor meg hozza a megadott (4, 4, 3, 5) = 16 ciklust ?
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #726 on: 2013.November.16. 15:04:46 »
Quote from: ergoGnomik
IstvanV és Zozo, a segítségeteket kérném! Próbáltam elméletben számolgatni a videoszegmensek elérésével kapcsolatban egy kicsit, de mivel tudásom parányi, eléggé hihetetlen érték jött ki. Egy videosor 57(*2 - órajel két fázisa) Nick buszciklusig tart. Ebből 8(*2) az LPB beolvasása, 3 memória frissítés vagyis marad 95. Ebből jön le a tényleges képernyőtartalom elérése, ami (RMARGIN-LMARGIN)*[1|2]. 40 oszlopos kép esetében ez lehet 40 vagy 80 félciklus, mely utóbbi esetében csak 15 hozzáférési lehetőség jutna a Z80-nak 256 T ciklusonként (4MHz-es processzor) , ami szerintem elképesztően kevés. Hol a hiba a számolásomban?
Egy karakteren belül valójában 3 video RAM művelet lehetséges (ellentétben például a Plus/4-el, ahol csak 2, de ezt a TED kevésbé "pazarlóan" használja fel), ebből 2 mindig a NICK számára fenntartott, egy pedig szabad a Z80 számára. Ez teljesen független attól, hogy a képernyőn éppen mi történik, a keretszínű sorokban is lassú a video RAM. A Z80-nak mindig meg kell várnia a következő karaktert (~889846 Hz-es frekvencia), és még el is kell végeznie a memória műveletet, ami így akár 5.5 ciklus várakozást is eredményezhet a legrosszabb esetben. A Z80 várakoztatása 0.5 ciklus (125 ns 4 MHz-es gépen) egységekben történik.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #727 on: 2013.November.16. 15:05:15 »
Quote from: Z80System
És ha a forrás és a cél is "fast" RAM, akkor meg hozza a megadott (4, 4, 3, 5) = 16 ciklust ?
Igen, feltéve, hogy a BFh porton nincs várakozás beállítva.

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: Assembly programozás
« Reply #728 on: 2013.November.19. 09:58:24 »
hülye kérdés, tudom... :-)
ha disassembláltok, akkor milyen címkéket használtok?
az Lxxxx fajtát, amit pl. a dZ80 is generál, vagy ha rájöttök valamire, hogy mit is csinál az adott rész, akkor átnevezitek a címkét (pl. WriteChar)?
csak azért kérdezem, mert egyedi név esetén olvashatóbb lesz a kód, viszont elvesztem azt az információt, hogy eredetileg hol is volt az a rutin, vagy változó programban.
*** Speicherplatz zu klein

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Assembly programozás
« Reply #729 on: 2013.November.19. 10:03:31 »
Quote
ha disassembláltok, akkor milyen címkéket használtok?

Hát én még sosem csináltam ilyet, hogy dissass -al nagyobb kódot hozok fordítható formába, de miért nem jó akkor mindkettő ? :

WriteChar_Lxxxx:

Egyébként te mit csinálsz, milyen feladat megoldásához fordítasz vissza ?
Z80 System

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #730 on: 2013.November.19. 10:04:01 »
Én ilyenkor kommentben írom oda, amikor meg van valami, akkor az egyből az összes előfordulásához.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #731 on: 2013.November.19. 10:06:51 »
IDA-ban meg egy kattintás átnevezni egy címke összes előfordulását (vagy megnézni az értékét).

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: Assembly programozás
« Reply #732 on: 2013.November.19. 10:19:45 »
Quote from: Z80System
Egyébként te mit csinálsz, milyen feladat megoldásához fordítasz vissza ?
A HiSoft Pascal-t fordítom vissza. Értelme nulla, de jól szórakozok vele :-) De izgalmas dolog felfedezni egy fordító működését.
Eredetileg úgy gondoltam (én naiv), hogy majd kibővítem egy STRING típussal. Nem biztos, hogy olyan egyszerű lesz... :-)
Viszont hihetetlenül jó dolog, ha valamire rájön az ember, és egyre tisztábban látja a dolgokat. Pl. amikor rátalálok egy ugrótáblára, és az értelmetlen Z80 utasításokból rendezett memóriacímek lesznek... :-)
Vagy amikor kiderül, hogy egy-egy memóriacímen milyen változó van eltárolva.
Vagy eddig nem ismert trükkökre jön rá az ember (amik nyilván ősrégi trükkök, csak én még nem találkoztam vele), ilyen pl., hogy az utasítások és függvények utolsó karakterén a 7. bit beállított, így jelzik az utasítás végét.
*** Speicherplatz zu klein

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #733 on: 2013.November.19. 10:37:18 »
Quote from: Povi
Eredetileg úgy gondoltam (én naiv), hogy majd kibővítem egy STRING típussal. Nem biztos, hogy olyan egyszerű lesz... :-)
Nincs mondjuk Spectrumra olyan, amiben már benne van? Akkor csak azzal kéne összevetni, hogy ott mit fejlesztettek.

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Assembly programozás
« Reply #734 on: 2013.November.19. 10:43:28 »
Quote
Én ilyenkor kommentben írom oda, amikor meg van valami, akkor az egyből az összes előfordulásához.
Lehet, hogy van már az EXOS/EXDOS kódokból visszafordított, fordítható állomány, csak én még nem hallottam róla ?

Úgy értem, hogy ilyen teljes EXOS/EXDOS ...
Z80 System