1
Assembly / Re: Assembly programozás
« Last post by Ferro73 on Yesterday at 19:50 »Bocsi régen használtam "TRACE memory"
Recent Posts
2
Assembly / Re: Assembly programozás
« Last post by Tuby128 on Yesterday at 16:56 »Hogy lehet track-olni asmonban?
3
Assembly / Re: Assembly programozás
« Last post by Ferro73 on Yesterday at 13:24 »Roppant egyszerű ha van eredeti "valós" géped elindítod az ASMON-t
Editbe beírod
Futtatod vagy "track" olod a vissza téréskor ellenőrzöd a változásokat a regisztereknél.
A változásból következtethetsz mi lehetett az utasítás.
Én így kerestem amikor olyan kódot találtam a játékprogram átírásánál.
Editbe beírod
Code: [Select]
org 1000h
...
...
DB 0EDh,xx
RET
RET
RET
RET
END
lefordítodFuttatod vagy "track" olod a vissza téréskor ellenőrzöd a változásokat a regisztereknél.
A változásból következtethetsz mi lehetett az utasítás.
Én így kerestem amikor olyan kódot találtam a játékprogram átírásánál.
4
Assembly / Re: Assembly programozás
« Last post by Tuby128 on 2023.December.09. 22:37:49 »Tegnap olvastam egy weboldalon, hogy a korábban említett illegális opkód, mint a "ED után ha C0 ... FF"
Akkor azt úgy fogja kezelni, mintha 2 nop lenne.
Akkor azt úgy fogja kezelni, mintha 2 nop lenne.
5
Assembly / Re: Assembly programozás
« Last post by Ferro73 on 2023.December.09. 19:37:29 »De mi volt pontosan. Emlékszel még?
Ha a CD xx utasítás készletet nézem emlékeim szerint CD 00- CD 03 van utasítás és CD 04 - CD 07 üres nem dokumentált.
a CD 04 - CD 07 megegyezett a CD 00 -CD 03.
De, hogy melyik CPU Z80A, Z80B vagy Z80C már nem emlékszem.
7
Assembly / Re: Assembly programozás
« Last post by Tuby128 on 2023.December.09. 00:50:08 »Kvaczko, a 8086-os processzornál kezdték használni a
LOAD HL, (SP+dd) utasításokat. Veremnek hívták továbbra is.
Ha jött egy szubrutin, aminek dinamikusan kellett 5 integer változó, akkor SUB SP, 4byte*5, szépen eltolták a SP kezdőcímét visszafelé (a verem mérete visszafelé növekszik). És akkor jött a LOAD HL,(SP+2) ill. LOAD (SP+2),HL meg hasonlók.
Ha visszatért a szubrutin egy RETURN paranccsal akkor az SP-t visszatolta az eredeti helyére ADD SP,4byte *5.
A lényeg, hogy 8086-ostól kezdve már nem csak LIFO volt, hanem egy indirekt elérésű tároló, mint ami az EP-nél az IX regiszterek valósítnak meg.
Ez az eljárás nagyon szépen támogatta a C és PASCAL programnyelveket.
Miért mondod, hogy a processzor cache nem ram? Pont hogy a leggyorsabb statikus ram, ami a processzor órajelén működik. Az a feladata, hogy a memóriából egy szeletet eltároljon, amivel a processzor most éppen nagyon sok műveletet végez. A cache nem egy 65535 x 65535-ös tömb feltöltésére való, hanem arra ha van egy szubrutin, ami dolgozik 20-40 változóval, akkor azokat eltárolja és a végrehajatást gyorsítsa.
A bottlenek problémát értem. FPGA esetén lehetőségem lenne, megnövelni a Z80 adatbuszát 8 bitről 16-ra vagy 32-re. Ezzel a módszerrel egy órajel alatt 2x illetve 4x annyi op-kódot vagy adatot tudnék kiolvasni. Egy 16bites értékadás LD HL,0x335F (opcode 12 nn nn) vagy egy indexregiszeres értékolvasás LD a,(IX+d) (opkód: DD 7E dd) opkódja 3 BYTE hosszú. Kiterjesztve az adatbuszt 32 bitre, mindezt 1 órajel alatt ki tudnám olvasni. Másik 1 órajel alatt végrehajtani, letárolni.
LOAD HL, (SP+dd) utasításokat. Veremnek hívták továbbra is.
Ha jött egy szubrutin, aminek dinamikusan kellett 5 integer változó, akkor SUB SP, 4byte*5, szépen eltolták a SP kezdőcímét visszafelé (a verem mérete visszafelé növekszik). És akkor jött a LOAD HL,(SP+2) ill. LOAD (SP+2),HL meg hasonlók.
Ha visszatért a szubrutin egy RETURN paranccsal akkor az SP-t visszatolta az eredeti helyére ADD SP,4byte *5.
A lényeg, hogy 8086-ostól kezdve már nem csak LIFO volt, hanem egy indirekt elérésű tároló, mint ami az EP-nél az IX regiszterek valósítnak meg.
Ez az eljárás nagyon szépen támogatta a C és PASCAL programnyelveket.
Miért mondod, hogy a processzor cache nem ram? Pont hogy a leggyorsabb statikus ram, ami a processzor órajelén működik. Az a feladata, hogy a memóriából egy szeletet eltároljon, amivel a processzor most éppen nagyon sok műveletet végez. A cache nem egy 65535 x 65535-ös tömb feltöltésére való, hanem arra ha van egy szubrutin, ami dolgozik 20-40 változóval, akkor azokat eltárolja és a végrehajatást gyorsítsa.
A bottlenek problémát értem. FPGA esetén lehetőségem lenne, megnövelni a Z80 adatbuszát 8 bitről 16-ra vagy 32-re. Ezzel a módszerrel egy órajel alatt 2x illetve 4x annyi op-kódot vagy adatot tudnék kiolvasni. Egy 16bites értékadás LD HL,0x335F (opcode 12 nn nn) vagy egy indexregiszeres értékolvasás LD a,(IX+d) (opkód: DD 7E dd) opkódja 3 BYTE hosszú. Kiterjesztve az adatbuszt 32 bitre, mindezt 1 órajel alatt ki tudnám olvasni. Másik 1 órajel alatt végrehajtani, letárolni.
8
Assembly / Re: Assembly programozás
« Last post by kvaczko on 2023.December.08. 21:54:35 »Gondolkodtam, hogy ha a verem a cache-ben lenne akkor mennyivel gyorsulnának fel a dolgok.
Az a baj, hogy a Z80 verem utasításai a 16 bites mozgatásban kimerülnek. Nem lehet a veremből kivenni a 4. elemet hogy feldolgozzuk, aztán visszategyük. Emiatt az az érzésem, hogy rengeteg globális változó esetén inkàbb az indexregiszterek lesznek jól használhatók. Főleg azért mert az indexregiszterek által címzett memória közvetlenül is manipulálható. Pl matematikai utasítások végezhetőek el az ix által címzett memórián lévő érték és az akkuval. Tölthető a címzett memória bármelyik regiszterbe majd onnan vissza. Stb.
Persze lassú a jelenlegi állapotában, de ha kicserélem a Z80-at egy fpga-ra, akkor a cache-be töltöm az indexregiszter által címzett memóriát, és máris minden utasítás csak 2-4 ciklus lesz.
A verem by definition egy LIFO tároló. Innéttől nincs értelme a “kiveszem belőle az x-ik elemet” dolognak. Az a RAM. A processzor cache viszont nem egy RAM, a felhasználó programja nem is férhet hozzá. Ha FPGA-n belül akarsz gyors elérést az indexregiszterek által megcímezhető memóriacímekhez, azt megteheted az FPGA belső RAM-jával. Ugyanakkor meg kell oldanod azt is, hogy ez szinkronban legyen a tényleges RAM-mal, hiszen egy következő utasítással akár direkt címzéssel is hozzá kell tudj férni. A bottleneck (ha az), továbbra is megmarad - hozzá kell nyúlnod a RAM tartalmához. Akkor meg nem vagy előrébb, legfeljebb az “FPGA cache” olvasásakor, ott is leginkább az 1-30ns vs. 70-120ns között van valójában időelőnyöd. Ha az Enterprise 2.0-dat 10ns elérési idejű RAM-mal pakolod tele, akkor ez a kérdés meg eleve okafogyott.
9
Assembly / Re: Assembly programozás
« Last post by Tuby128 on 2023.December.08. 21:25:06 »De mi volt pontosan. Emlékszel még?
10
Assembly / Re: Assembly programozás
« Last post by Ferro73 on 2023.December.08. 21:13:44 »Emlékeim szerint úgy fog reagálni mint a ZX nél az in a,(0FEh) és a in a,(0FCh).
Asmon-ban ellenőriztem. itt leltem a nem dokumentált utasításokra is.
Volt egy A4 lap ZX könyvben ahol fel volt tüntetve mind a 256
DEC HEX AS.CI Z80 utasítás CD xx utasítás ED xx utasítás.
ezeknek a hiányzó részeit próbálgattam.
Asmon-ban ellenőriztem. itt leltem a nem dokumentált utasításokra is.
Volt egy A4 lap ZX könyvben ahol fel volt tüntetve mind a 256
DEC HEX AS.CI Z80 utasítás CD xx utasítás ED xx utasítás.
ezeknek a hiányzó részeit próbálgattam.