Welcome, Guest. Please login or register.


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

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #180 on: 2010.June.12. 11:39:52 »
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 :-)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #181 on: 2010.June.12. 13:29:26 »
Ö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
  1. SPSCROLL:
  2.                 LD HL,4000H          
  3.                 LD DE,4000H-9*80+20  
  4.                 LD A,198              
  5.                 CALL SPSCROLL1        
  6.                 LD HL,4000H-9*80      
  7.                 LD DE,4000H+189*80+20
  8.                 LD A,9              
  9. SPSCROLL1  
  10.                 LD (SPCEL+1),DE      
  11.                 LD (SPCOUNT+1),A      
  12.                 LD (SPSAVE+1),SP      
  13. SPKEZD:        
  14.                 LD SP,HL              
  15.                 POP BC                
  16.                 POP DE                
  17.                 POP HL                
  18.                 POP IX                
  19.                 POP IY                
  20.                 EXX                  
  21.                 POP BC                
  22.                 POP DE                
  23.                 POP HL                
  24.                 POP AF                
  25.                 EX AF,AF'            
  26.                 POP AF                
  27.                 LD (SPKEZD2+1),SP    
  28. SPCEL:          LD SP,4000H-9*80+20  
  29.                 PUSH AF              
  30.                 EX AF,AF'            
  31.                 PUSH AF              
  32.                 PUSH HL              
  33.                 PUSH DE              
  34.                 PUSH BC              
  35.                 PUSH IY              
  36.                 PUSH IX              
  37.                 EXX                  
  38.                 PUSH HL              
  39.                 LD HL,40-4            
  40.                 ADD HL,SP            
  41.                 PUSH DE              
  42.                 LD (SPCEL2+1),HL      
  43.                 PUSH BC              
  44. SPKEZD2:
  45.                 LD SP,4000H
  46.                 POP IX
  47.                 POP BC
  48.                 POP DE
  49.                 POP HL
  50.                 POP IY
  51.                 EXX
  52.                 POP BC
  53.                 POP DE
  54.                 POP HL
  55.                 POP AF
  56.                 EX AF,AF'
  57.                 POP AF
  58. SPCEL2:         LD SP,4000H-9*80+20
  59.                 PUSH AF
  60.                 EX AF,AF'
  61.                 PUSH AF
  62.                 PUSH HL
  63. SPCOUNT:        LD A,200
  64.                 PUSH DE
  65.                 DEC A
  66.                 PUSH BC
  67.                 PUSH IY
  68.                 EXX
  69.                 PUSH HL
  70.                 LD (SPCOUNT+1),A
  71.                 PUSH DE
  72.                 LD HL,80-4
  73.                 ADD HL,SP
  74.                 LD (SPCEL+1),HL
  75.                 LD HL,(SPKEZD2+1)
  76.                 PUSH BC
  77.                 PUSH IX
  78.                 LD BC,80-20
  79.                 ADD HL,BC
  80.                 JR NZ,SPKEZD
  81. SPSAVE:         LD SP,0
  82.                 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.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #182 on: 2010.June.12. 22:45:53 »
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?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #183 on: 2010.June.19. 18:58:08 »
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  :oops: )?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #184 on: 2010.June.19. 22:35:43 »
Ez a folyamatos újbóli utasításkód beolvasás le van írva valamelyik Z80 doksiban (és csak nekem nem tûnt fel  :oops: )?

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

Offline Ferro73

  • EP addict
  • *
  • Posts: 1015
  • Country: hu
Re: Assembly programozás
« Reply #185 on: 2010.June.20. 21:42:06 »
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)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #186 on: 2010.June.20. 22:27:03 »
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.

(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.

Offline Ferro73

  • EP addict
  • *
  • Posts: 1015
  • Country: hu
Re: Assembly programozás
« Reply #187 on: 2010.June.21. 19:14:40 »
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.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Assembly programozás
« Reply #188 on: 2010.June.21. 20:47:32 »
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.

Offline Ferro73

  • EP addict
  • *
  • Posts: 1015
  • Country: hu
Re: Assembly programozás
« 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.

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: Assembly programozás
« 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. :D
Vigyázat! Szektás vagyok! :)

Offline nt75sw

  • Beginner
  • *
  • Posts: 48
  • Country: hu
Re: Assembly programozás
« 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.

Offline Lacika

  • EP addict
  • *
  • Posts: 3213
  • Country: hu
    • http://www.ep128.hu
Re: Assembly programozás
« Reply #192 on: 2010.September.28. 19:43:52 »
Itt van ASMON 1.3, HEASS, FENAS. Nem csak ROM.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #193 on: 2010.September.28. 21:01:12 »
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 :-)

Offline nt75sw

  • Beginner
  • *
  • Posts: 48
  • Country: hu
Re: Assembly programozás
« 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...