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

Zozosoft · « **Reply #180 on:** 2010.June.12. 11:39:52 »

Quote from: IstvanV on 2010.June.12. 11:24:57

Képernyõ scrollozására gyorsabb megoldás lehetne az LPT-ben átírni a video címet, és akkor csak a belépõ pixeleket kell a memóriába írni az egész mozgatása helyett.

Ez kétségtelen, de nem véletlenül írtam félképernyõt

IstvanV · « **Reply #181 on:** 2010.June.12. 13:29:26 »

Quote from: Zozosoft on 2010.June.12. 11:11:21

Önmagában a POP-PUSH kb 2x gyorsabb mint az LDIR, viszont gyakran kell variálni az SP-el, ami elviszi a megtakarítás nagy részét Nem tudom, lehetne-e ezen még optimalizálni valamit?

Egy keveset sikerült gyorsítani az utasítások sorrendjének a megváltoztatásával (a video RAM hozzáférés miatt ennek van jelentősége):

Code: ZiLOG Z80 Assembler

SPSCROLL:
                LD HL,4000H           
                LD DE,4000H-9*80+20   
                LD A,198              
                CALL SPSCROLL1        
                LD HL,4000H-9*80      
                LD DE,4000H+189*80+20 
                LD A,9               
SPSCROLL1   
                LD (SPCEL+1),DE       
                LD (SPCOUNT+1),A      
                LD (SPSAVE+1),SP      
SPKEZD:         
                LD SP,HL              
                POP BC                
                POP DE                
                POP HL                
                POP IX                
                POP IY                
                EXX                  
                POP BC                
                POP DE                
                POP HL                
                POP AF                
                EX AF,AF'             
                POP AF                
                LD (SPKEZD2+1),SP     
SPCEL:          LD SP,4000H-9*80+20   
                PUSH AF               
                EX AF,AF'            
                PUSH AF               
                PUSH HL               
                PUSH DE               
                PUSH BC               
                PUSH IY               
                PUSH IX               
                EXX                  
                PUSH HL               
                LD HL,40-4            
                ADD HL,SP             
                PUSH DE               
                LD (SPCEL2+1),HL      
                PUSH BC               
SPKEZD2:
                LD SP,4000H
                POP IX
                POP BC
                POP DE
                POP HL
                POP IY
                EXX
                POP BC
                POP DE
                POP HL
                POP AF
                EX AF,AF'
                POP AF
SPCEL2:         LD SP,4000H-9*80+20
                PUSH AF
                EX AF,AF'
                PUSH AF
                PUSH HL
SPCOUNT:        LD A,200
                PUSH DE
                DEC A
                PUSH BC
                PUSH IY
                EXX
                PUSH HL
                LD (SPCOUNT+1),A
                PUSH DE
                LD HL,80-4
                ADD HL,SP
                LD (SPCEL+1),HL
                LD HL,(SPKEZD2+1)
                PUSH BC
                PUSH IX
                LD BC,80-20
                ADD HL,BC
                JR NZ,SPKEZD
SPSAVE:         LD SP,0
                RET

A futásidő ~178770 ciklusról ~173300-ra csökkent. De turbós gépen vagy várakozással már nem biztos, hogy ez lenne a gyorsabb.

Zozosoft · « **Reply #182 on:** 2010.June.12. 22:45:53 »

Quote from: IstvanV on 2010.June.12. 13:29:26

Egy keveset sikerült gyorsítani az utasítások sorrendjének a megváltoztatásával (a video RAM hozzáférés miatt ennek van jelentõsége):

Ilyen esetben mire érdemes figyelni?

Zozosoft · « **Reply #183 on:** 2010.June.19. 18:58:08 »

Quote from: IstvanV on 2010.June.11. 23:02:00

Az LDIR idõzítése azonos az LDI-vel, ha a végrehajtásával a BC értéke 0-ra csökken. Egyébként még a fent leírt 16 ciklus után van további 5 ciklus, ami gyakorlatilag relatív ugrást végez vissza az LDIR utasításra, amelyet aztán a Z80 újra beolvas a memóriából.

Kipróbáltam, hogy mit csinál, ha az LDIR felülírja a saját utasítás kódját, és tényleg kiszabadul a ciklusból, amikor az EDH bájtja felülíródik. Ebbõl szerintem érdekes visszafejtés elleni trükköt lehetett volna csinálni anno

Ez a folyamatos újbóli utasításkód beolvasás le van írva valamelyik Z80 doksiban (és csak nekem nem tûnt fel

)?

IstvanV · « **Reply #184 on:** 2010.June.19. 22:35:43 »

Quote from: Zozosoft on 2010.June.19. 18:58:08

Ez a folyamatos újbóli utasításkód beolvasás le van írva valamelyik Z80 doksiban (és csak nekem nem tûnt fel )?

A Z80 dokumentációban ez olvasható:

[ Guests cannot view attachments ]

Ezt talán lehet úgy is értelmezni, hogy az utasítás újraolvasása a memóriából nem történik meg, de amit írnak, az alapján az tűnik ésszerűnek:
- minden byte másolása után a PC két byte-al csökken, és ilyenkor megszakítás is történhet (ami után természetesen folytatódik az LDIR)
- két memóriafrissítési (M1) ciklus történik minden byte másolása után
- az LDIR időzítése ha van még újabb byte (4, 4, 3, 5, 5) csak annyiban tér el az LDI-től, hogy van még a végén 5 ciklus a PC csökkentésére

Ferro73 · « **Reply #185 on:** 2010.June.20. 21:42:06 »

Quote from: IstvanV on 2010.June.19. 22:35:43

A Z80 dokumentációban ez olvasható:

(Attachment Link)

Ezt talán lehet úgy is értelmezni, hogy az utasítás újraolvasása a memóriából nem történik meg, de amit írnak, az alapján az tûnik ésszerûnek:
- minden byte másolása után a PC két byte-al csökken, és ilyenkor megszakítás is történhet (ami után természetesen folytatódik az LDIR)
- két memóriafrissítési (M1) ciklus történik minden byte másolása után
- az LDIR idõzítése ha van még újabb byte (4, 4, 3, 5, 5) csak annyiban tér el az LDI-tõl, hogy van még a végén 5 ciklus a PC csökkentésére

Majdnem csak a frisités nem a bájt másolása után hanem az utasítás beolvasásakor történik meg
(3T opcode0 + 1T RFSH)=4, (3T opcode1 + 1T RFSH)=4, (3T adat,(HL) )=3, (3T (DE),adat + 2T BC ell)=5, (5T PC=PC-2, HL=HL+1, DE=DE+1)

IstvanV · « **Reply #186 on:** 2010.June.20. 22:27:03 »

Quote from: Ferro73 on 2010.June.20. 21:42:06

Majdnem csak a frisités nem a bájt másolása után hanem az utasítás beolvasásakor történik meg

Természetesen a byte másolás utáni frissítést már a következő byte-hoz (ha van ilyen) tartozó utasítás beolvasására értettem. Máshogy nem is lenne értelme.

Quote from: Ferro73 on 2010.June.20. 21:42:06

(3T opcode0 + 1T RFSH)=4, (3T opcode1 + 1T RFSH)=4, (3T adat,(HL) )=3, (3T (DE),adat + 2T BC ell)=5, (5T PC=PC-2, HL=HL+1, DE=DE+1)

A HL és DE növelése nem az utolsó 5 ciklusban (ami LDI-nél, vagy ha nincs újabb byte, nincsen) történik, de ennek kevés jelentősége van. Az M1 ciklusoknál nincs 3 ciklus az utasításkód olvasására; éppen azért is van olyan mód, amikor csak M1-hez generálódik várakozás, mert ott 2.5 helyett már 2 ciklus után megtörténik az olvasás a normál memóriaműveletekkel ellentétben, és a második 2 ciklus a frissítés.

Ferro73 · « **Reply #187 on:** 2010.June.21. 19:14:40 »

Quote from: IstvanV on 2010.June.20. 22:27:03

A HL és DE növelése nem az utolsó 5 ciklusban (ami LDI-nél, vagy ha nincs újabb byte, nincsen) történik, de ennek kevés jelentõsége van. Az M1 ciklusoknál nincs 3 ciklus az utasításkód olvasására; éppen azért is van olyan mód, amikor csak M1-hez generálódik várakozás, mert ott 2.5 helyett már 2 ciklus után megtörténik az olvasás a normál memóriamûveletekkel ellentétben, és a második 2 ciklus a frissítés.

Részben igaz
(3T opcode0 + 1T RFSH)=4, (3T opcode1 + 1T RFSH)=4, (3T adat,(HL) )=3, (3T (DE),adat + 2T HL=HL+1, DE=DE+1,BC ell)=5, (5T PC=PC-2?

??)
A másik M1 és M1 közöt mit értesz mert van *M1 CPU láb amihez igazitják a WAIT(várakozást) meg van blokdiagram M1 ciklus ami 4T alap esetben.
Továbbá neked van igazad vagy a Zilog blokdiagramja hazudik ezért kismedve , én a Zilog dokumentáció után mentem.

IstvanV · « **Reply #188 on:** 2010.June.21. 20:47:32 »

Quote from: Ferro73 on 2010.June.21. 19:14:40

Részben igaz

Mi részben igaz ?

Quote

5, (5T PC=PC-2???)

Ez miért meglepő ? A relatív ugrás, és általában a 16 bites cím + 8 bites előjeles eltolás számítása mindig 5 ciklus (JR, DJNZ, (IX+n), (IY+n), stb.).

Quote

A másik M1 és M1 közöt mit értesz mert van *M1 CPU láb amihez igazitják a WAIT(várakozást) meg van blokdiagram M1 ciklus ami 4T alap esetben.

Az utóbbit. Az itt található, a Z80 dokumentációból másolt képen látható, hogy a 4 ciklusból az első 2 az utasításkód olvasása (a 2. ciklus végén történik az adatbusz mintavételezése), a második 2 pedig a DRAM frissítés.

Ferro73 · « **Reply #189 on:** 2010.June.22. 16:52:03 »

igazad van valamit nagyon el néztem lehet összezavart a memoria olvasás irás 3T ciklusa de minel az M1 lábon levö vezérlés jóval elöbb jön mint az MREQ/esetenként 100ns/ igy van elég elérési idö a lassu memoriáknak ezért elég a 2T

Más
Enterprise ECO ?
szoftweresen lehet csökkenteni a fogyasztást.

endi · « **Reply #190 on:** 2010.July.10. 14:15:08 »

Kitaláltam egy jó random generátort.

EP-n vagy specy128-on mûködik: a hang kimenetet rá kell kötni a bemenetre (ahol a magnó jel jön), ki kell adni zaj hangot és kiolvasni a bemenet port érték.

nt75sw · « **Reply #191 on:** 2010.September.28. 19:31:41 »

Üdv!

Bocs a kérdésért, mert nyílván le van már írva, csak nincs most időm keresgetni.
Olyan assembler/editor programokat keresek, amelyek nem ROM-ból futnak, hanem betölthető.

Köszi előre is.

Lacika · « **Reply #192 on:** 2010.September.28. 19:43:52 »

Itt van ASMON 1.3, HEASS, FENAS. Nem csak ROM.

Zozosoft · « **Reply #193 on:** 2010.September.28. 21:01:12 »

Quote from: nt75sw on 2010.September.28. 19:31:41

Olyan assembler/editor programokat keresek, amelyek nem ROM-ból futnak, hanem betölthetõ.

És ez miért is jó? Ha emulátorhoz kell, ott gyorsan be tudod rakni a konfigurációba a szükséges ROM-okat. Igazi gép ROM bõvítése se megoldhatatlan

nt75sw · « **Reply #194 on:** 2010.September.29. 15:50:55 »

Üdv Zozosoft!

Eredeti géphez kellett igen, nem PC-hez

Az most nincs, elhalt. Még jó hogy itt a szülőknél van gép, el tudom vinni ha kell valami mp3-ban

Értem amit írsz, de eprom égetőm az bizony nincs, valamikor régen tervbe volt véve
de valahogy elmaradt, ma meg már... Nem igen állnék neki.
Most az a terv hogy esetleg veszek egyet majd.

De addig is marad a telóról betöltés (*) - magnóra mentés

Viszont még sokat kell foglalkoznom ezekkel a programokkal...
Az ASM még hagyjuk, de a PC nagyon elvitt rossz irányba már látom,
még egy program betöltése is problémás ezekben az editorokban nekem

Na de majd...

* mp3 320K, ezt megeszi, wavot nem játszik még az az asztali dvd player sem sajna...

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

Zozosoft

Re: Assembly programozás

IstvanV

Re: Assembly programozás

Zozosoft

Re: Assembly programozás

Zozosoft

Re: Assembly programozás

IstvanV

Re: Assembly programozás

Ferro73

Re: Assembly programozás

IstvanV

Re: Assembly programozás

Ferro73

Re: Assembly programozás

IstvanV

Re: Assembly programozás

Ferro73

Re: Assembly programozás

endi

Re: Assembly programozás

nt75sw

Re: Assembly programozás

Lacika

Re: Assembly programozás

Zozosoft

Re: Assembly programozás

nt75sw

Re: Assembly programozás