Most hogy írod LD BC,HL utasításon megint meglepődtem, mint amikor kiderült, hogy bit rotáló útasításnál nem lehet megadni, hogy hányszor végezze el.

Azt olvastam, hogy a HL regiszter, az a 16 bites akkumulátor. Erre kiderül, hogy nincs lehetőség ebből a regiszterből 16 bites értéket másikba tölteni?
Most látom, hogy csak a következő HL utasítások validak:
LD HL,nn
LD HL,(nn)
LD SP,HL
LD (nn),HL

Most ha kiszámolok egy memóriacímet, és LDIR-t akkarok használni, akkor nem tudom áttölteni a BC és DE regiszterekbe az eredményt?
De át tudom, csak 8 bitenként:
LD B,H  (opcode 0x44)
LD C,L  (opcode 0x4D)

Annyiban igazuk van a tervezőknek, hogy mivel az 1 BYTE hosszú opcode-ok beteltek, nincs értelme egy LD BC,HL miatt egy 0xED utáni opcode-ot létrehozni pl: ED 22, mert ugyanúgy két BYTE hosszú lenne, mint amikor végrehajtjuk a 44 4D kódot.

 Megérett már az olyan Z80 FPGA mag, aminek 32 adatbusza van, és ezt a két utasítást egy FETCH utasítással beolvassa, és egy ciklus alatt elintézi.
Ugyanez a véleményem az indexregiszteres címzésre. 32 bites adatbusszal be lehetne olvasni az egész kiterjesztett LD (IX+d),A opkódot egyben, és így visszaírássel együtt 2 ciklus alatt el is intézhető.

 Még annyi finomság lehetne, hogy az indexregiszter által címzett memória a CPU néhány 16 Byte-os CACHE memóriájába lenne töltve, így piszokgyorsan hozzáférne a CPU az adatokhoz. Gyakorlatilag úgy működne mint regiszter. A visszaírás a normál memórába (cache ürítés) lenne problémás - időigényes, amikor az Index regiszter értéket váltana.

Jaa, hogy ilyen kis tömbről van szó, akkor az, amit említettem, fölös, mert nagyon helypazarló, viszont, ha jól látom az ix+4 tárolja az I változót, amit A-ba töltesz, és hasonlítod össze az L-lel, ha A kisebb, mint L, akkor lesz C, így nem hajtódik végre a ciklusod.
JR NC, END_FOR_i ,és JR NC, END_FOR_j    kéne
meg még egy dolgot kiszúrtam a i=i+2-nél:
LD (IX+5),A  helyett LD (IX+4),A kéne.

de a j++ megvalósítható INC (IX+5)-tel
az i=i+2 meg:
INC (IX+4)
INC (IX+4)-gyel

Nem tudom milyen fordítót használsz, van pár, ami nem szereti a LD BC,HL-t, mert ilyen z80 utasítás nincs, ha szereti a fordító, hagyhatod így is, de úgy látom fölösleges is ez az utasítás, mert:
 LD L,(IX+2)
 LD H,(IX+3)  ; HL <- base address of char tomb[][]
 LD BC,HL     ; BC <- base address of char tomb[][]
helyett
 LD C,(IX+2)
 LD B,(IX+3)  ; BC <- base address of char tomb[][]
ez is megadható

Vélelmezzük, hogy az IX regiszter már oda mutat arra a memóriára, ahol a változók lesznek eltárolva.

Tudom, hogy sok utasítás felesleges, vagy gyorsabb megoldással kiváltható. De az átláthatóság miatt így is megfelel.

 Kérdés, hogy a feltételes JR ugrás vajon fog-e működni?
 Meg hogy a kódban van-e más hiba?

Jelenleg nincs semmilyen alternatíva ezek pótlására és/vagy előállítására minthogy kiszeded egy meglévő alaplapból. Így viszont jogosan merül fel a kérdés, hogy minek szétbarmolni egy Issue6 alaplapot, hogy kapjak belőle aztán egy ugyanolyan Issue6 alaplapot?

VK

LIKE  

Az IX, es IY regisztereket hasznalo utasitasok hasznalatanak hasznalhatosagat jol leirtad, annyi a lenyeg meg, hogy sebesseg kritikus helyeken az ld (ix),a , ld a,(ix) hasznalata megfontolando, egyeb hasonlo utasitasoke is, mert nagyon lassuak,ez igaz az iy-ra is, mig pl egy ld a,(hl) 7 t-state, egy jo ld a,(ix) 19 t-state-be faj.
Visszaterve az eredeti kerdesre, en barmelyik normal regiszter part hasznalnam a 2 dimenzios tomb elemeinek megcimzesere, lehet pl a DE, a lenyeg az, hogy a tomb kezdete legyen 100h-s hatarra allitva, igy nem kell miden adat eleresnel 16 bites osszeadast elvegezni, E megadja az x coordinatan levo elemet, D -a tomb kezdete megadja az y-t.