Enterprise Forever

:HUN => Programozás => Assembly => Topic started by: Zozosoft on 2005.December.23. 11:35:37

Title: Assembly programozás
Post by: Zozosoft on 2005.December.23. 11:35:37
Ide jöhet mindenféle kérdés-válasz a témában :)

Elsõként EPROM lebegés vizsgáló Povinak:
[asm]
          ORG 1000H
          LD A,SZEGMENSSZAM
          OUT (0B1H),A
          LD HL,4000H
          LD B,L
LEBEG1    LD A,(HL)
LEBEG2    CP (HL)
          RET NZ
          DJNZ LEBEG2
          INC HL
          BIT 7,H
          JR NZ,LEBEG1
          RET
          END
[/asm]
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.05. 14:43:25
Quote from: "Zozosoft"
[asm]LEBEG1    LD A,(HL)
LEBEG2    CP (HL)
[/asm]

Hivatalosan a címkék után nem kell kettõspont?
Nem errõl ismeri fel a fordító?
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.January.05. 15:23:10
Quote from: "MrPrise"
Nem errõl ismeri fel a fordító?

Az EP-s fordítók szerintem onnan ismerik fel, hogy a sor elsõ karakterén kezdõdõ szó :)
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.05. 15:27:40
Quote from: "Zozosoft"
Quote from: "MrPrise"
Nem errõl ismeri fel a fordító?

Az EP-s fordítók szerintem onnan ismerik fel, hogy a sor elsõ karakterén kezdõdõ szó :)

Hm. Ok. Csak mert most írom a regex-eket ;-)
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.January.05. 18:37:52
Meg is néztem most, Asmon, Fenas, Heass mind így kezeli. Heass-ben lehet kettõspont, de nem kötelezõ.
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.05. 18:39:32
Quote from: "Zozosoft"
Meg is néztem most, Asmon, Fenas, Heass mind így kezeli. Heass-ben lehet kettõspont, de nem kötelezõ.

Ok. Köszi. Már régen volt mikor még assembly-ben programoztam Enterprise-on. Azóta már megszoktam teljesen a PC-s assemblereket.
Title: Re: Assembly programozás
Post by: Povi on 2006.January.05. 18:48:25
Az asmonban és a fenasban is lehet kettõspont, de nem kötelezõ. (mostanság fenas-t használok, de ha lenne heass-om romban, akkor azt használnám...). Az a baj, hogy a heass.ext-tel nem tudok fordítani. (nem tudom, miért)
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.05. 19:08:05
Quote from: "Povi"
Az asmonban és a fenasban is lehet kettõspont, de nem kötelezõ. (mostanság fenas-t használok, de ha lenne heass-om romban, akkor azt használnám...). Az a baj, hogy a heass.ext-tel nem tudok fordítani. (nem tudom, miért)

De a kettõsponttól függetlenól azt nézi, hogy ez az elsõ szó a sorban?
Tehát hiába raksz utána :-ot, ha bentebb kezdõdik akkor nem címkeként értelmezi?
Az assembly forrás kiemelõ miatt kérdem. Hogy hogyan mûködjön.
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.January.05. 20:33:54
Quote from: "MrPrise"
Tehát hiába raksz utána :-ot, ha bentebb kezdõdik akkor nem címkeként értelmezi?

Így van!
Title: Re: Assembly programozás
Post by: hsoft on 2006.January.10. 02:58:15
Quote from: "Zozosoft"
Quote from: "MrPrise"
Tehát hiába raksz utána :-ot, ha bentebb kezdõdik akkor nem címkeként értelmezi?

Így van!


Elnézést a kotnyelességért: Az EP-s asseblerek a sor elsõ karakterét figyelik, mely  megadja hogy mit kell értelmezni a továbbiakban.
Betü után címke jön, mely kettõspont, szóköz, enter határolással csonkolva lesz.
Szóköz és tab után ltrim(utasitás) jöhet.
; után csak megjegyzés várható, tehát a sor maradéka át lesz ugorva.
(kivéve ha idézõjelmódban van)
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.13. 10:44:21
A rendszerszegmensen hol kezdõdik a karakterkészlet? Nem találom ez Enterpress-eimet.
Title: Re: Assembly programozás
Post by: MrPrise on 2006.January.13. 11:07:34
Quote from: "MrPrise"
A rendszerszegmensen hol kezdõdik a karakterkészlet? Nem találom ez Enterpress-eimet.

0x3480-0x38ff Kinyomoztam ;-)
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.January.13. 13:00:27
Itt a "vinyószimulátor" forráskódja:
Code: ASM
  1.                 ORG 0C000H
  2.                 VAR 64,EXDEXT.ROM
  3.                 DB "EXOS_ROM"
  4.                 DW 0
  5.                 LD A,C
  6.                 CP 7
  7.                 JR NZ,NEMRAM
  8.                 LD DE,DARAB*60H+3
  9.                 LD BC,100H
  10.                 RET
  11. NEMRAM          IN A,(0B1H)
  12.                 OR A
  13.                 RET Z
  14.                 LD A,C
  15.                 CP 2
  16.                 JR Z,COM1 ;PARANCSFUZER
  17.  
  18.                 CP 3
  19.                 RET NZ
  20.                 LD A,B
  21.                 OR A
  22.                 JR Z,ALTAL
  23.                 LD HL,EXDEXT
  24.                 CALL KERD
  25.                 RET NZ
  26.                 LD BC,HOSSZ2
  27.                 LD DE,HH2
  28.                 LD A,255
  29.                 EXOS 8
  30.                 LD C,0
  31.                 RET
  32. ALTAL           PUSH DE
  33.                 PUSH BC
  34.                 LD DE,HH2
  35.                 LD BC,HOSSZ1
  36.                 LD A,255
  37.                 EXOS 8
  38.                 POP BC
  39.                 POP DE
  40.                 RET
  41.  
  42. COM1            LD HL,EXDOSFF
  43.                 CALL KERD
  44.                 RET NZ
  45.                 LD A,(IY+0)
  46.                 OR A
  47.                 RET NZ
  48.                 PUSH IY
  49.                 POP DE
  50.                 IN A,(0B2H)
  51.                 LD B,A
  52.                 LD (IY+0),DARAB
  53.                 LD HL,KEZELOP
  54.                 LD (IY+1),L
  55.                 LD (IY+2),H
  56.                 IN A,(0B3H)
  57.                 LD (IY+3),A
  58.                 XOR A
  59.                 LD C,A
  60.                 RET
  61.  
  62.  
  63. KERD            LD A,B
  64.                 CP (HL)
  65.                 RET NZ
  66.                 INC HL
  67.                 PUSH BC
  68.                 PUSH DE
  69.                 INC DE
  70.  
  71. AZONOS          LD A,(DE)
  72.                 CP (HL)
  73.                 JR NZ,NEMA
  74.                 INC HL
  75.                 INC DE
  76.                 DJNZ AZONOS
  77. NEMA            POP DE
  78.                 POP BC
  79.                 RET
  80. KEZELOP         CP 3
  81.                 JR NZ,NEMBOOT
  82.                 LD HL,DISK+0C000H
  83.                 LD BC,512
  84.                 PUSH IX
  85.                 POP DE
  86.                 LDIR
  87.                 XOR A
  88.                 RET
  89. NEMBOOT         CP 4
  90.                 JR NZ,NEMOLVAS
  91.                 DI
  92.                 PUSH BC
  93.                 PUSH IX
  94.                 POP HL
  95.                 EXX
  96.                 LD C,0B0H
  97.                 IN E,(C)
  98.                 INC C
  99.                 IN D,(C)
  100.                 INC C
  101.                 IN L,(C)
  102.                 OUT (C),D
  103.                 EXX
  104.                 INC DE
  105.                 LD A,D
  106.                 LD C,E
  107.                 SLA C
  108.                 RLA
  109.                 SLA C
  110.                 RLA
  111.                 SLA C
  112.                 RLA
  113.                 LD C,A
  114.                 IN A,(0B3H)
  115.                 ADD A,C
  116.                 OUT (0B0H),A
  117.                 INC A
  118.                 OUT (0B1H),A
  119.                 LD H,E
  120.                 SLA H
  121.                 RES 7,H
  122.                 RES 6,H
  123.                 LD L,0
  124.                 LD D,XH
  125.                 LD E,XL
  126.                 SET 7,D
  127.                 RES 6,D
  128.                 SLA B
  129.                 LD C,0
  130.                 LDIR
  131.                 EXX
  132.                 OUT (C),L
  133.                 DEC C
  134.                 OUT (C),D
  135.                 DEC C
  136.                 OUT (C),E
  137.                 EXX
  138.                 EI
  139.                 PUSH DE
  140.                 POP IX
  141.                 POP BC
  142.                 XOR A
  143.                 RET
  144. NEMOLVAS       ;LD A,186
  145.                 RET
  146.  
  147. EXDEXT          DB 6,"EXDEXT"
  148. EXDOSFF         DB 6,"EXDOS",0FFH
  149.  
  150. DARAB           EQU 1
  151.  
  152. HH2             DB "EXDEXT version 1.0",13,10
  153. HOSSZ1          EQU $-HH2
  154.                 DB "ROMDISK EXDOS bovites",13,10
  155. HOSSZ2          EQU $-HH2
  156.                 .PRINTX #$
  157.  
  158. VEGEE           EQU $
  159.                 DF 0C200H-$,255
  160.                 ORG 200H
  161. DISK            MERGE DISKIMG
  162.                 END
  163.  
Érdeklõdés esetén el is magyarázhatom, hogy mit csinál :-)
Title: Re: Assembly programozás
Post by: Povi on 2006.February.05. 21:36:18
Új alkalmazói program indulásakor a funkcióbillentyúkre van valami alapértelmezett string? Azért kérdem, hogy KEYBOARD: eszközzel vajon hogyan lehetne õket olvasni? Ha jól emlékszem, csak az ALT+, és a CTRL+funkcióbillentyúkhöz van ASCII-kód. Vagy marad a portokon lekérdezés?
Title: Re: Assembly programozás
Post by: Povi on 2006.April.24. 21:33:25
Hogyan lehet azt megoldani, hogy saját programból, ha kiadom az exdos parancsot, és abból esc-kel visszatérek, ne tûnjöm el a fél képernyõ (amit az exdos kitakart).
Konkrétabban: az atomixben csináltam egy olyat, hogy ha megnyomom a kettõspontot, elõugorjon az exdos. Ha kilépek, tök jól folytatódik minden ott, ahol abbamaradt, leszámítva azt, hogy üres a képernyõ.
Title: Re: Assembly programozás
Post by: hsoft on 2006.April.25. 08:27:05
Quote from: "Povi"
Hogyan lehet azt megoldani, hogy saját programból, ha kiadom az exdos parancsot, és abból esc-kel visszatérek, ne tûnjöm el a fél képernyõ (amit az exdos kitakart).
Konkrétabban: az atomixben csináltam egy olyat, hogy ha megnyomom a kettõspontot, elõugorjon az exdos. Ha kilépek, tök jól folytatódik minden ott, ahol abbamaradt, leszámítva azt, hogy üres a képernyõ.

Az Exdos parancs egyszerüsítve a következõ lépéseket végzi: Nyit egy videó csatornát, display utasítással kiteszi, ez EXOS hivással történik és a videó sorokat az lpt-ben átcímzi. Kilépésnél bezárja a videó csatornát.
Tehát a képernyõ helyreállítás egyik módja, hogy végrehajtunk egy display hívást. Amikor nem használjuk az operációs rendszer videó csatornáját, vagyis valami direkt video memória kezelést alkalmazunk, akkor két lehetõség van. Ha tudjuk a videó soraink címeit, csak vissza cimezzük az lpt-sorokat. Amikor virtuális, tehát pl. görgetés miatt kiszámíthatatlanná vált a videócím, akkor célszerû lementeni az exdos parancs elötti lpt-t, és visszatéréskor vissza lehet irni.
Title: Re: Assembly programozás
Post by: lgb on 2006.June.14. 09:17:47
Hello! Sajat feljleszteseimet a cc65 (www.cc65.org) stuffokkal szoktam csinalni PC-n, ez 65xx cpu-khoz C fordito, assembler, linker, ennek assembler-et (ca65) szoktam hasznalni, mivel olyan dolgokat tud amit semmilyen mas stuff nem.
Persze, Z80-at nem ismer, ezert meg regebben elkezdtem csinalni egy olyan "pre assemblert" ami Z80 asm forrast megeszi, es kikop magabol olyan asm forrasat, amit a ca65 megeszik :) Ez ugy muxik gyakorlatilag, hogy .BYTE szekvenciakat hoz letre igy persze a ca65-nek onnantol mindegy hogy az milyen CPU-n ertelmezett vagy nem ... Elonye ennek, hogy ca65 meg az ld65 (a linker) minden jo tulajdonsaga igy rendelkezesre all Z80-as fejlesztesekhez is, ami mas altalam ismert eszkozzel nem lehetne biztositani.

Nos ezen projectem kapcsan utkoztem abba a kerdesbe, hogy milyen Z80 syntaxist szokas hasznalni assemblerekben, ugyis tobb fele is van ... Peldaul az sdcc (sdcc.sf.net) olyasmiket hasznal hogy:

ADC A,#12
LD L,12(IX)

Ahol az ADC-nel eleve az "A" el is hagyhato ugye, a # az viszont nem, mert az jelzi hogy nem memoriara hivatkozil (
lasd: LD A,2 - LD A,(2), ami sdcc assemberenel helyesen: LD A,#2 es LD A,(2) ha jol remlik), mig a "12(IX)" az
Offset(IX) formatumban van, de ugye mashol inkabb az (IX+12) a "normalis" jeloles.

Szoval eleg nagy a kavar, sajnos ninvs olyan nagy foku egyettertes mint pl 65xx asm syntax eseten. Ezert szeretnem osszeszedni az osszes koztudatban levo szintaxist, hogy minnel tobb dologgal elboldoguljon. Ha valakinek ez ugyben van tehat megjegyzese, akkor irjon :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.June.14. 09:24:18
Quote from: "lgb"
Peldaul az sdcc (sdcc.sf.net) olyasmiket hasznal hogy:

ADC A,#12
LD L,12(IX)

Ilyet most látok életemben elöször!

Quote
Szoval eleg nagy a kavar, sajnos ninvs olyan nagy foku egyettertes mint pl 65xx asm syntax eseten. Ezert szeretnem osszeszedni az osszes koztudatban levo szintaxist, hogy minnel tobb dologgal elboldoguljon. Ha valakinek ez ugyben van tehat megjegyzese, akkor irjon :)

Szerintem egyetértés van, legalábbis én EP-n meg egyébként is csak egyfajtát láttam, azt amit a hivatalos Zilog leírásokban is látni. Éppen ezért döbbentem meg az extrém elvadult példádon, hogy ki lehet olyan örült, hogy ilyet kitalál :-)
Title: Re: Assembly programozás
Post by: tigrian on 2006.June.14. 12:51:30
Quote from: "lgb"
...szeretnem osszeszedni az osszes koztudatban levo szintaxist

Ez nem ízlés kérdése.
http://www.z80.info/zip/z80cpu_um.pdf

Edit: Hmmm. Még mindig volt mit javítani benne :D
http://www.zilog.com/docs/z80/um0080.pdf
Title: Re: Assembly programozás
Post by: lgb on 2006.June.15. 08:31:12
Quote from: "Zozosoft"
Quote from: "lgb"
Peldaul az sdcc (sdcc.sf.net) olyasmiket hasznal hogy:

ADC A,#12
LD L,12(IX)

Ilyet most látok életemben elöször!

Quote
Szoval eleg nagy a kavar, sajnos ninvs olyan nagy foku egyettertes mint pl 65xx asm syntax eseten. Ezert szeretnem osszeszedni az osszes koztudatban levo szintaxist, hogy minnel tobb dologgal elboldoguljon. Ha valakinek ez ugyben van tehat megjegyzese, akkor irjon :)

Szerintem egyetértés van, legalábbis én EP-n meg egyébként is csak egyfajtát láttam, azt amit a hivatalos Zilog leírásokban is látni. Éppen ezért döbbentem meg az extrém elvadult példádon, hogy ki lehet olyan örült, hogy ilyet kitalál :-)


Naja. De ha pl vki C nyelven akar fejleszteni, akkor Z80 eseten az sdcc az jo valasztas lehet, ami viszont ilyen asm output-ot keszit, tehat attol hogy neked (nekem se amugy!) nem tetszik ezzel is foglalkozni kell ;-( Legalabbis en igy erzem.
Title: Re: Assembly programozás
Post by: lgb on 2006.June.15. 08:32:20
Quote from: "tigrian"
Quote from: "lgb"
...szeretnem osszeszedni az osszes koztudatban levo szintaxist

Ez nem ízlés kérdése.
http://www.z80.info/zip/z80cpu_um.pdf

Edit: Hmmm. Még mindig volt mit javítani benne :D
http://www.zilog.com/docs/z80/um0080.pdf


Amugy, a Z80-at egyebkent ismerem (nem dokumentalt dolgait is) a kerdesem nem is erre vonatkozott, hanem arra, hogy tobbfele syntaxis is hasznalatos assembly forrasokban mint a mellekelt abra mutatja ...
Title: Re: Assembly programozás
Post by: lgb on 2006.June.15. 08:53:32
Quote from: "tigrian"
Quote from: "lgb"
...szeretnem osszeszedni az osszes koztudatban levo szintaxist

Ez nem ízlés kérdése.
http://www.z80.info/zip/z80cpu_um.pdf

Edit: Hmmm. Még mindig volt mit javítani benne :D
http://www.zilog.com/docs/z80/um0080.pdf


Masodsorban pedig IGENIS izles kerdese, mert ha van egy olyan cucc ami _ILYEN es OLYAN_ formatumot ad, akkor hiaba nem hivatalos az, hiaba nem tetszik stb stb, kenytelen vagy vele egyutt elni ha hasznalni akarod, ez ilyen egyszeru :) Most nem mondthatom meg az sdcc (meg az as-z80) keszitoinek hogy "hulyek vagytok sz** a syntaxis" attol valszeg nem lesznek meghatva kulonoskeppen max azt valaszolnak hogy nem kotelezo hasznalni ha nem tetszik. De nekem pont az, hogy szuksegem lenne ra ...

Amugy ez mar eleve nem olyan egyszeru pl x86-on sem, mint ismert ott is ket fo formatum van, az Initel es az AT&T syntaxis, mely utobbit hasznalja pl a gas/gcc is, es elso latasra eleg durva, eleve forditva van a ket operandus, hogy masrol ne is beszeljek):

 __asm__ __volatile__(        
              "1:      mov" "b" " %2,%" "b" "1\n"        
              "2:\n"        
              ".section .fixup,\"ax\"\n"        
              "3:      movl %3,%0\n"        
              "        xor" "b" " %" "b" "1,%" "b" "1\n"        
              "        jmp 2b\n"        
              ".section __ex_table,\"a\"\n"        
              "        .align 4\n"        
              "        .long 1b,3b\n"        
              ".text"        : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
                            (   __gu_addr   )) ), "i"(- 14 ), "0"(  __gu_err  )) ;
              break;      

Ez AT&T syntaxist hasznalno gcc inline assmbler betet volt eppen ;-> Lathato hogy allatira nem trivialis (google-el erdemes rakeresni arra hogy "black magic gcc assembly" ;-)

Amugy ez az AT&T syntaxis pl tobbe kevesbe kvazi standard UNIX vagy UNIX szeru rendszereken, tobbfele CPU-n is (max ofkoz maguk az opcode-ok masok).

Ezt most csak peldanak mondtam, hogy milyen nehez kerdes is az, hogy mi az "izles kerdese" meg mi nem ...

Raadasul, ha mar x86, az sem egyszeru kerdes, hogy kitalalja az assembler, eppen milyen cimzesmodot hasznalna szerencsetlen programozo, nezzunk egy peldat:

mov ax,label

Namost jo kerdes, hogy most az AX regiszterbe a label cimke cimen levo word-ot kell betolteni, vagy magat a cimet. Itt pl total keveredes van x86 assemblereknek. A NASM (Netwide Assembler) pl ezert ilyet nem is enged, es MEGKOVETELI, hogy a programozo egyertelmuen jelezze mit akar, ott pl a fenti forma a CIMRE vonatkozik, a [label] pedig a cimen levo ertekre. Pl 65xx cpu-kon mar eleve a "hivatalos" syntaxis is felkeszult erre, es # jelet hasznalja arra, hogy jelezze ez bizony egy konstans, es nem cim, azaz pl az "LDA #1" 1-es erteket tolti be az akkumlatorba, mig az "LDA 1" az az 1-es cimmel rendelkezo byte tartalmat ( hasonlo lenne az x86-os mov ax,label vagy mox ax,[label], ahol keveres is van mert nehol pl mov ax,offset label syntaxist is hasznalnak az "offset" szoval jelezve hogy a label offsetje kell, mint lathato minden CPU-n kurva nagy kavarodas van, sot assemblerenkent valtozik)!

Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak. Valoszinuleg az scc/as-z80 keszitoi azert akartak egy EGYERTELMU es konnyeben ertelmezheto jelolesrendszert bevezetni (ami amugy nemikepp az 65xx szintaxisra hasonlit, ami azert is gyanus, mert amugy azt is tamogatja az 65xx procikat legalabbis ami a mellekelt assemblereket as-* illeti).
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.June.15. 08:58:16
Quote from: "lgb"

Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak.

Hol nem logikus szerinted?
Title: Re: Assembly programozás
Post by: lgb on 2006.June.15. 09:44:07
Quote from: "Zozosoft"
Quote from: "lgb"

Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak.

Hol nem logikus szerinted?


Globalisan pl. Hogy minden CPU-nak miert kell tok mas asm syntaxis, marmint nyilvan az opcode-ok jeloleset leszamitva? Pl az AT&T syntaxis egyik erdekessege hogy ugyanugy jeloli a cimzesmodokat kulonbozo CPU-n is, meg az egyes CPU gyartok altalaban valami sajat format talalnak ki tok hasonlo dolgokra is, pl MOS 65xx esten LDA #1, mig x86 eseten mov ax,1, az hagyjan hogy LDA !=MOV (mert eleve nem lehet egy cpu-n olyan opcode aminek nincs is kozvetlen megfeleltetese) de a cimzesmod jeloles stb is tok mas. Ezert szoktal valasztani hogy valami konnyebben parse-olhato es egysegsebb format hasznaljanak, hogy ne kelljen az embernek 1234943947db syntaxist megjegyeznie ha mondjuk tobb cpu-ra is programozik assembly-ben (a mar soXor emlitett AT&T szintaxis pl pont ezt akarja behozni, hogy nagyjabol hasonlo legyen meg teljesen kulonbozo CPU-k eseten is, es ne legyen tok mas assember/cpu fuggo).

Na ezzel _NEM_ azt akarom mondani hogy a Zilog altal specifikalt formatum ne lenne jo nekem, csak azt akartam bemutatni, hogy milyen indittatasbol vannak esetleg mas formatumok is, amit en azert akarok tamogatni, hogy mas tool-okkal egyutt tudjak mukodni :) Pont ezert kerdeztem, hogy talalkozott-e valaki mas "extrem" vagy kevesbe kozismert synataxisokkal amit esetleg megfontolas targyava lehetne tenni hogy tudjak "konvertalni" a mar vazolt modszerrel.

Igazabol a konkret esetre valo logikussag kerdese azert jott elo itt nalam, mert a Zilog prezentalt formatum kozel konzisztens, de ha tobb formatumot pl keverni akarod akkor nem az, ami problemakat vet fel, ha mindegyiket tamogatni akarom :) Ez persze nem a Zilog hibaja, nyilvan. Viszont az teny, hogy nekem valahogy meg kell kuzdenem vele, ami egy csomo heurisztikat igenyel emiatt a konverterem reszerol, tehat nem egy egyszeru nota ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.September.07. 09:59:26
Quote from: "Spidermans Friend"
Én sem értem a hívás mûködését, pl. honna tudja a visszatérési címet, meg ilyesmi.

A visszatérési címet a HL tartalmazza, amelyet a hívás elött a hívó JP utánra állítunk be.
Macró nélkül:
Code: [Select]

      LD HL,RETC
      JP rutin
RETC  ...


rutin ...


      JP (HL)


A macro miatt nem lehet cimkét használni, így a fordítási címszámláló segítségével van megadva a visszatérési cím, mivel az LD HL és a JP is 3 bájtos utasítások, így lett az LD HL,$+6 forma. Illetve a másik makroban van még egy JP, így ott $+9

Quote from: "Spidermans Friend"
De úgy általában is érdekelne a Z80 gépi kód, azon belül az EP programozás. PC-n már assemblyztem, utoljára kb. 10 éve... Ha valakinek van türelme válaszolgatni, az Assembly topikban alkalomadtán kérdezgetnék, vagy ajánlhatnátok valami okítóanyagot.

Tessék lehet kérdezgetni :-)

Irodalomból ajánlott a Gépi Kódú Programozás (http://www.ep128.hu/Ep_Konyv/Gepi_kod.htm), meg az Enterpress cikksorozatai. (http://www.ep128.hu/Ep_Konyv/Enterpress_Gepikod.htm)
Title: Re: Assembly programozás
Post by: Spidermans Friend on 2006.September.07. 12:51:59
Köszi, sejtettem, hogy a dollárjel a fõszereplõ. Még egy kicsit így is magas, de ha átnézem, biztos megértem. Most viszont munka...
Title: Re: Assembly programozás
Post by: hsoft on 2006.September.08. 10:13:44
Quote from: "Zozosoft"

A macro miatt nem lehet cimkét használni,

Én úgy emléxem, hogy volt rá valami megoldás...
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.September.08. 10:24:51
Quote from: "hsoft"
Én úgy emléxem, hogy volt rá valami megoldás...

Az jó lenne!
Itt a Heass leírásban (http://www.ep128.hu/Ep_Util/HEASS.htm) nincs szó ilyenrõl :-(
A második használatánál a macronak már azt írja ki, hogy a szimbólum már létezik.
Title: Re: Assembly programozás
Post by: hsoft on 2006.September.08. 19:07:37
Sajnos én sem találtam benne, tehát marad a dolláros kifejezés. Viszont akkor a GEN-bõl emlékeztem ilyenre.
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.September.09. 20:43:28
Quote from: "hsoft"
Sajnos én sem találtam benne, tehát marad a dolláros kifejezés. Viszont akkor a GEN-bõl emlékeztem ilyenre.

És a Heass 1.1.-ben benne lesz? :-)
Title: Re: Assembly programozás
Post by: hsoft on 2006.September.12. 08:30:25
Nem lenne akkora durranás, hogy szükséges  legyen megírni, tehát általam nem lesz benne. :)
Végülis úgy oldják meg, hogy a makró alatti címkének (valamilyen kezdõkarakter jelzi) a végére tesznek egy virtuális stringet, emlékeim szerint a címszámlálót hexában, de lehetne egy inkrementált makró számláló. Ezt csak a makrón belül illik meghívni. mert több makró esetén gond lehet.
Title: Re: Assembly programozás
Post by: gafz on 2006.September.12. 09:01:59
Nem akar valaki - véletlenül - egy mai soros egerekkel kompatibilis :mouse eszközkezelõt írni? Mészáros-féle kártyához... :wink:
Title: Re: Assembly programozás
Post by: hsoft on 2006.September.12. 11:30:32
Remélem, nem célzás volt? :) Zozo nagyon szeretne ilyet :)
Title: Re: Assembly programozás
Post by: gafz on 2006.September.12. 11:34:40
Másik ötletem, hogy kéne egy kártyaismertetõ-sorozatot összehozni, pl. melyik kártya melyik porto(ka)t használja, az adott foglalat vagy ram melyik szegmense(ke)n látszik, stb. Itt elsõsorban a Mészáros-féle kártyákat értem... :)

De igen, célzás akart lenni... :oops:
Title: Re: Assembly programozás
Post by: hsoft on 2006.September.12. 11:52:02
Ez meg a hardveresek dolga :)
Title: Re: Assembly programozás
Post by: gafz on 2006.September.12. 12:16:50
Hm, pedig valaki igazán nekifuthatna ezeknek a dolgoknak :) , én sajnos elég alulképzett vagyok hozzá... :oops:
Title: Re: Assembly programozás
Post by: Lacika on 2006.September.12. 12:36:23
Quote from: "gafz"
Másik ötletem, hogy kéne egy kártyaismertetõ-sorozatot összehozni, pl. melyik kártya melyik porto(ka)t használja, az adott foglalat vagy ram melyik szegmense(ke)n látszik, stb. Itt elsõsorban a Mészáros-féle kártyákat értem... :)


Az Enterpressben jelent meg a témáról egy cikk "Címezzünk Pontosan!" (http://www.ep128.hu/Ep_Konyv/Enterpress_Cikkek.htm#5b) címmel. Nyílván nem öleli fel teljesen a témát, de kiindulásnak nem rossz.
Title: Re: Assembly programozás
Post by: Povi on 2006.November.02. 11:37:28
Lebegõpontos rutinokat keresek Z80 assemblyre... (szorzás, összeadás).

Megcsináltam a Mandelbrot rajzolót 16 színben, Hisoft Pacalban, most már csak kb. 20 perc (feleannyi pixel miatt), amit még 10 percre simán le lehetne csökkenteni, mert szimmetrikus. Viszont 286-oson láttam olyan pár száz bájtos .com file-t, amit kb. 1 mp alatt rajzolt Mandelbrot-halmazt, tehát elvileg EP-n is megvalósítható lenne mondjuk pár tíz mp-ben, ha tiszta gépi kódba lenne. Vagy nem? Az ENTERPRESS-ben megjelent Mandelbrot rajzolót bepötyögte valaki? Az mennyi idõ alatt rajzolt?
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.November.02. 11:52:19
Quote from: "Povi"
Lebegõpontos rutinokat keresek Z80 assemblyre... (szorzás, összeadás).

Az 1-es szegmensben érdemes kutakodni :-)
Title: Re: Assembly programozás
Post by: Povi on 2006.November.02. 13:37:38
Azok nem azok, amiket a BASIC is használ? Szerintem annál vannak gyorsabb rutinok is.
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.November.02. 14:14:28
Quote from: "Povi"
Azok nem azok, amiket a BASIC is használ? Szerintem annál vannak gyorsabb rutinok is.

Na jó, de ha kimarad az a pár száz utasítás amíg a BASIC eljut a konkrét rutin meghívásáig :-)
Meg esetleg nem is meghívva a rutint hanem átemelve a forrást, lehet, hogy még lehetne kidobálni belõle...
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.November.02. 14:17:36
Quote from: "Povi"
Viszont 286-oson láttam olyan pár száz bájtos .com file-t, amit kb. 1 mp alatt rajzolt

És ha ezt disassemblálnád, majd az algoritmus kinyerése után átírni Z80-ra?
Ha 286-oson volt, akkor koprocit nem használhatott (A 287-es igen ritkaság volt, igazából a 486DX-ekkel kezdett általánosan elérhetõ lenni a koproci)
Title: Re: Assembly programozás
Post by: endi on 2006.November.02. 19:53:34
keress rá a neten a 256 bájtos demó versenyek eredményeire
Title: Re: Assembly programozás
Post by: Zozosoft on 2006.November.06. 21:04:56
Floating-Point Math Package for GameBoy or Z80 in Assembler, by Jeff Frohwein (http://www.z80.info/zip/math.zip)
Title: Re: Assembly programozás
Post by: Ferro73 on 2007.April.07. 13:03:59
ugy emlékszam van olyan utasitás ami a port tartalmát közvetlenül a memoriába tölti vagy olvassa
valahogy igy   IN (HL),(C)   OUT (C),(HL)  ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2007.April.07. 13:24:10
INI,INIR,IND,INDR,OUTI,OTIR,OUTD,OTDR
Title: Re: Assembly programozás
Post by: IstvanV on 2007.April.07. 13:31:59
ugy emlékszam van olyan utasitás ami a port tartalmát közvetlenül a memoriába tölti vagy olvassa
valahogy igy   IN (HL),(C)   OUT (C),(HL)  ?

Dokumentált utasítás biztosan nincs ilyen (bár az OUTI/OUTD hasonló, csak változtatja a B és HL értékét). Elvileg az ED 70 és ED 71 lehetne az in (hl), (c) és out (c), (hl), de ezek nem működnek.
Title: Re: Assembly programozás
Post by: Zozosoft on 2007.April.07. 13:59:55
Elvileg az ED 70 és ED 71 lehetne az in (hl), (c) és out (c), (hl), de ezek nem mûködnek.
Azok az IN F,(C) OUT (C),F, mûködnek csak sok értelme nincs :-) (pl az IN-nél a két nem használt flag biten marad meg a beolvasott érték)
Megjegyzem találkoztam már olyan Spectrum játékkal, ami használta az IN F,(C)-t billentyûfigyelésre... (gondolom a visszafejtés megnehezítésére) ezért az Spectrum emu programjába ezt is beletettem.
Title: Re: Assembly programozás
Post by: IstvanV on 2007.April.07. 14:09:31
Elvileg az ED 70 és ED 71 lehetne az in (hl), (c) és out (c), (hl), de ezek nem mûködnek.
Azok az IN F,(C) OUT (C),F, mûködnek csak sok értelme nincs :-) (pl az IN-nél a két nem használt flag biten marad meg a beolvasott érték)
Megjegyzem találkoztam már olyan Spectrum játékkal, ami használta az IN F,(C)-t billentyûfigyelésre... (gondolom a visszafejtés megnehezítésére) ezért az Spectrum emu programjába ezt is beletettem.

Akkor az emulátorban ez a rész valószínűleg hibás:

Code: [Select]
    case 0x070:
      {
        _IN(R.TempByte);
        ADD_PC(2);
        R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
      }
      break;
    case 0x071:
      {
        _OUT(0);
        ADD_PC(2);
        R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
      }
      break;

Az in f, (c) csak a nem használt biteket változtatja meg ?
Title: Re: Assembly programozás
Post by: Ferro73 on 2007.April.07. 17:09:27
Mi lenne a legrövidebb kulcs és idö zx attrib atírására
én valami ilyesmire
push
push
  :
  :    X SZÁMU ismétlés
LD A,(DE)        ; DE=EREDETI ZX ATTRIB
" IN (HL),(C) "  ; HL=EP ATRIB
  :
  :
POP
POP
valami olyasmi ez amit használtak zx átiratokhoz de itt nem szoftveresen számolja hanem hardverszinten az attributokat
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2007.May.26. 10:28:06
Szerintetek a jp (hl) helyett nem lenne helyesebb a jp hl jelölés? miért alakulhatott ez így?
Title: Re: Assembly programozás
Post by: Povi on 2007.May.29. 18:41:47
A zárójellel azt jelölik, hogy memóriacímre ugrik. Szerintem így helyes.
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2007.May.29. 19:03:32
de minden más utasításnál, hl a regiszter értékét használja, (hl) pedig a regiszter által mutatott cím értékét.
Title: Re: Assembly programozás
Post by: MrPrise on 2007.May.29. 21:00:07
Itt (http://www.z80.info/z80info.htm) jelölésbeli furcsaságként beszélnek róla.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.23. 21:13:05
Nem emlexik veletlen valaki, hogy hogyan is lehetett a mar meglevo szoveges csatornakat 80 karakteresre allitani ?

Volt valami hogy "var", vagy "set" meg meg szamok, es akkor pld. meg lehetett csinalni azt hogy az 1.3 -mas asmonban 80 karakteres legyen a kep felso resze, ahol listaz...

Tom hogy a nagyobb verziojuak olyanok, de en 1.3- mat akarok ... :) Regen azzal nyomtam... :)

Title: Re: Assembly programozás
Post by: Z80System on 2007.October.23. 21:58:44
Azert majd olvassatok el az elozo postot is, de ez is erdekelne:

Anno mikor mi programoztunk, egy csipetnyit sem erdekelt bennunket a rendszer, se infonk sem kedvunk nem volt rendszert hivogatni,
ugyhofgy en most ismerkedek az exos- szal, es meglepodve latom (ha jol ertem), hogy igazabol nem letezik olyan hogy "rendszerhez visszateres", tehat ha egy alkalmazas (5-os fejlecu exos modul a fileformatumban) mar atvette a vezerlest, akkor mar nincs visszaut az ot hivo alkalmazashoz, maximum ujraindithatja azt.

Tehat igazabol engem nem erdekel hogy WP- bol vagy BASIC- bol, vagy honnan irtak be a load- ot ami engem betoltott, ha en vigyazok a rendszerre, memoriara stb., szeretnek visszaterni oda, ahonnan engem hivtak. Tehat ha valaki beirt 10 BASIC sort, es meghiv engem, ha vigyazok kapja vissza a basicjet, ugyanaz WP- nel ...

De mintha ez hianyozna az exos- bol, az ember lehet rendszerbovito, azokat meg nem nezegettem, de en nem szeretnek rendszerbovito lenni, ne kelljen kulon :appname parancsokat irkalni.

Szal a kerdes az hogy jol olvasom, ha 5-os alkalmazas vagyok, akkor legfeljebb nullarol indithatom ujra a WP-t BASIC-et, vagy nem gondolom jol, es vissza lehet terni a hivohoz ?


Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.24. 10:27:27
Miután az 5-ös fejlécû "Új Felhasználói Program" már betöltödése során felülírja 100h-tól a nullás lapot, innentõl kezdve már nem lehet vissztérni a hívó programhoz.
Rendszerbõvítõként fordított programmal lehet megcsinálni azt amire gondolsz, és nem is kell :parancs hozzá. Betöltés után meghívja a rendszerbõvítõ inicializálási rutinját az EXOS, így ide akár a programod indulását is be lehet rakni.
Így mûködik pl a Cyrus Chess is.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.24. 23:18:22

De akkor az a rendszerbovito ki is tud lepni teljesen? Tehat miutan lefutottam (akar ennel az inicializalasnal, amit mondasz ...) es ugy gondolom kesz vagyok, akkor az a 2-es fejlecu bovito ki is tud ugy takarodni a memoriabol, mintha ott sem lett volna ? Memoria felszabadul, :help listabol eltunik, stb. ? Mintha be sem toltottem volna ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.25. 18:55:35
a 2-es fejlecu bovito ki is tud ugy takarodni a memoriabol, mintha ott sem lett volna ? Memoria felszabadul, :help listabol eltunik, stb. ? Mintha be sem toltottem volna ?
A 2-es fejlécû igen, de az nem bõvítõ :-) Az áthelyezhetõ felhasználói program, igazából pont ez való arra amit te szeretnél.
Viszont ezt nem az EXOS kezeli teljesen, kell a "LOAD"-ot kiadó program közremûködése is, ami biztosítja a memória területet a program betöltéséhez.
Ezt viszont szerintem csak az IS-BASIC kezeli, igazából nincs is túl sok ilyen fejlécû program, csak 1-2 BASIC bõvítõ.

Visszatérve a rendszerbõvítõkhöz, a bõvítõlistába való belepiszkálással meg lehet csinálni.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.28. 16:07:10

Sziasztok !

Emlexem regrol, hogy lehetett exos hivas nelkul (port olvasassal valoszinuleg) billentyuzetet es joyt olvasni. Melyik doksiban vannak leirva ezek ??? Nem talalom. A Nick,Dave hardveres cuccairol van leiras az exos konyvben, key/joy csak exos alapon van leirva ...


Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.28. 17:02:31
Most igy hirtelen azt javasolnám,hogy az ep.homeserver.hu oldalon nézd meg a Spectrum programok átirása cikksorozatot (SpV-bol), ott jol el van magyarázva a dolog.
Amugy a B5H portrol van szo.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.28. 17:05:25

Megvan, koszi ... De vajon ez exos konyvbol miert maradt ki,
es vajon akkor mikrol nem tudunk meg ???

Vagy hol van egy reerencia szintu hw leiras ep- rol ? Azt hittem az exos konyv szolgal erre a celra is ...
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.29. 00:57:00

Egy furcs jelenseget tapasztaltam az LPT tablam felvetelekor.

Ha 16 szinu grafika mellett 44 "karakternel" (ami 16 szin mellett egyebkent 176 pixel), szelesebbre alitom az LPB bejegyzeseimet (bal margo: 9, jobb margo: 53), akkor a ket szelen (bal/jobb oldal) nem rajzolodik ki a videomemoria tartalma, hanem valoszinuleg 0- as szinnel rajzolja ki, pontosan nem tom mert a palettam osszes szine ugyanarra van allitva scanline- onkent, de biztosan egyertelmuen nem border szinnel, es nem is azzal amit a videomemoria tartalmaz.

Emellett a 44 "karakter" (exos terminologia: "slot") mellett meg jo, de ha ennel nagyobbra veszem pld. 46 (bal margo: 8, jobb margo: 54) vagy ennel nagyobb, akkor fellep a jelenseg! Leharapja a nick a kep ket szelet ?

Ismeritek ezt, vagy csak az emu hibaja ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 09:21:58
Vagy hol van egy reerencia szintu hw leiras ep- rol ? Azt hittem az exos konyv szolgal erre a celra is ...
Sok dokumentáció nem jutott el hozzánk, legalábbis a "nép" körébe...
Mióta ez a fórum létezik, külföldi barátainknak hála több ilyen is elõkerült, pl az Enterprise Application Notes címû sorozat.
Van amit még ma is keresünk, pl az EXDOS technikai dokumentációja, ami igen jól jönne a vinyó projekthez...
És biztos vannak olyanok is, amikrõl még nem is tudunk :-(

Konkrétan a billentyûzetrõl ebben (http://ep.homeserver.hu/PDF/converting.pdf) az anyagban írnak, amit a játékprogram készítõ cégeknek csináltak, hogy ki tudják adni programjaikat EP-re is. Ha jól sejtem ez az anyag képezte az SpV cikk alapját is :-)

Ennek ellenére szerintem az EP a nagyon-nagyon jól dokumentált gépek közé tartozik! Amikor pl CPC-vel ismerkedtem, volt nagyon sok doksi, de rohadt érthetetlen, kusza halmaz az egész...
Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 09:27:03
Emellett a 44 "karakter" (exos terminologia: "slot") mellett meg jo, de ha ennel nagyobbra veszem pld. 46 (bal margo: 8, jobb margo: 54) vagy ennel nagyobb, akkor fellep a jelenseg! Leharapja a nick a kep ket szelet ?
46-nál többet már a dokumentáció alapján se tud a Nick :-)
44-et elvileg tudnia kéne, de a fene se tudja, mert egy átlag tv/monitor jó esetben tudja a 42-t... anno az új tévénkhez azért hívtuk rögtön a szerelõt, hogy az EPDOS 42 karakter széles képe beférjen a képernyõre :-)
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.29. 09:40:24
A 46 az mar nem okes pedig, a 44 meg jo ( az ep128emu2- ben, igazi ep- m ugye meg nincs ... :( :) )

Mellesleg a jozan paraszti esz azt gondolna, hogy akkor ott vagy border colort, vagy esetleg blank feketet jelenit meg, ez meg valamelyik paletta szint jeleniti meg a 44 karakteren kivul eso reszeken, mert szepen rasztercsikos, ahogy beallitottam a palettat. De ha a vidmembe irok valamit, akkor az nem latszik ott meg, csak a 44 es azon belul eso reszeken.


Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 09:53:38
Rakd fel ide a progit, aztán megnézzük igazi EP-n.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.29. 10:09:05

Van olyan monitorod amivel latszik a teljes szelesseg ? Ha van akkor este felrakom.

Hol van info arrol, hogyan lehet ide feltolteni ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 11:12:49
Van olyan monitorod amivel latszik a teljes szelesseg ? Ha van akkor este felrakom.
Még sose próbáltam mit lehet betekerni :-)
Csináld úgy, hogy mondjuk 5 karaktersor 40-es, 5 sor 42-es, 5 sor 44-es, 5 sor 46-os, aztán meglátjuk.
Hol van info arrol, hogyan lehet ide feltolteni ?
MrPrise, van az újoncoknak valami fórum használati tankönyv? :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2007.October.29. 12:07:54
Az ep128emu valóban levágja a 44 karakternél szélesebb képet (pontosabban a <9 és a >= 53 területet), mert ezt a TV-ken általában nem lehet látni, és sok demóban a vízszintes scrolloknál ezen a területen "szemét" jelenne meg. Egyébként a NICK valóban 46 karaktert tud megjeleníteni (8...53), és az ezen kívül eső részeken a NICK adatbuszon található adat jelenne meg (0 és 7 között az aktuális LPB, amit minden sorban újraolvas, 54 és 56 között pedig DRAM frissítés van, de az utolsó byte, ami a DRAM frissítés előtt a buszon volt, lesz látható). Egyébként nem lenne nehéz ezeket pontosan emulálni.
Title: Re: Assembly programozás
Post by: Z80System on 2007.October.29. 19:54:24

Ki tudja hol talalhato informacio olyan dolgokrol mint pld. a ra midozitesek ? Tehat ha valami referenciaban azt olvasom hogy egy ld a,(hl) az pld 3 orajelciklusnyi ido(nem biztos hogy annyi csak valami iylesmi ertekek remlenek), akkor az egy elmeleti minimum ertek, ehhez hozza fog jonni a ramok kesleltetese miatt X orajelciklus, memoriatipusok (video,sima,rom) szerint kulonbozo merteku, de hogy igazabol ezek mekkorak ?

Es hogy meg mik befolyasolhatjak a futasi idot, pld. emlexem amigan az sem volt mindegy hogy milyen kepernyouzemmod volt bevaltva, ilyesmikre gondolok, hogy EP- n ezek mik ?



Title: Re: Assembly programozás
Post by: IstvanV on 2007.October.29. 20:11:26
Ki tudja hol talalhato informacio olyan dolgokrol mint pld. a ra midozitesek ? Tehat ha valami referenciaban azt olvasom hogy egy ld a,(hl) az pld 3 orajelciklusnyi ido(nem biztos hogy annyi csak valami iylesmi ertekek remlenek), akkor az egy elmeleti minimum ertek, ehhez hozza fog jonni a ramok kesleltetese miatt X orajelciklus, memoriatipusok (video,sima,rom) szerint kulonbozo merteku, de hogy igazabol ezek mekkorak ?

Normál (nem video) RAM és ROM között szerintem nincs különbség, és az ezekhez való minden hozzáférésnél 0 vagy 1 Z80 ciklus késleltetés van a 0bfh I/O port beállításaitól függően. Az utasítás első  (vagy ha van CB, DD, ED, vagy FD prefix, akkor az első két) byte-jának az olvasása "M1" hozzáférés, aminél a késleltetést külön lehet szabályozni. Az "ld a, (hl)" normál RAM-ban futva és az alapértelmezett késleltetésekkel 8 ciklus, mert 4+1 az utasítás, és 3 az adatbyte olvasása. A video memória és a NICK I/O portok (080h-08fh) elérésekor a NICK busz órajeléhez kell szinkronizálni (~890 kHz), és ez 1 és 5 Z80 ciklus közötti késleltetést jelenthet; a 0bfh portnak ilyenkor nincs jelentősége.

Quote
Es hogy meg mik befolyasolhatjak a futasi idot, pld. emlexem amigan az sem volt mindegy hogy milyen kepernyouzemmod volt bevaltva, ilyesmikre gondolok, hogy EP- n ezek mik ?

Ennek az EP esetén nincs jelentősége, azaz nem lesz gyorsabb a gép (a video RAM hozzáférés sem) ha az egész képernyőn csak keret van.
Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 20:17:33
A Dave chip leírásában (BFH port).
Az EXOS alapban azt állítja be, hogy minden utasításnál 1 várakozás. Be lehet azt is állítani, hogy minden memória hozzáférésnél legyen 1 várakozás. Saját programban az a célszerû, hogy ne legyen várakozás :-)
A videó RAM-ról nincs pontos adat, az úgy mûködik, hogy a Z80-nak elsõbbségadás kötelezõ táblája van :-)

A Nick minden üzzemódban ugyanannyit olvas, kivétel ha LORES grafikát használsz, akkor feleannyi pixeladat kell.
Title: Re: Assembly programozás
Post by: Zozosoft on 2007.October.29. 20:44:06
azaz nem lesz gyorsabb a gép (a video RAM hozzáférés sem) ha az egész képernyõn csak keret van.
Hmm... az egyszerûség kedvéért a Nick akkor is olvas, amikor nem kell neki az adat?
És mi történik, ha a Nick 83H portjának nullázuk a 6-os bitjét? (b6  Set for normal operation. Clear to inhibit clocking of the line parameter counter.)
Azonkívûl, hogy ilyenkor nincs kép :-) vajon gyorsabb-e a video RAM?
Title: Re: Assembly programozás
Post by: IstvanV on 2007.October.30. 00:46:02
És mi történik, ha a Nick 83H portjának nullázuk a 6-os bitjét? (b6  Set for normal operation. Clear to inhibit clocking of the line parameter counter.)
Azonkívûl, hogy ilyenkor nincs kép :-) vajon gyorsabb-e a video RAM?

Egy egyszerű teszt alapján úgy tűnik, ilyenkor sem gyorsabb.
Title: Re: Assembly programozás
Post by: MrPrise on 2007.November.25. 13:56:22
Itt (http://hup.hu/node/47493)
Érdekessége, hogy elvileg minden Z80 alapú gépen működik.
Title: Re: Assembly programozás
Post by: endi on 2007.November.25. 20:56:02
hogyan mûködhetne minden z80-as gépen, amikor mindegyiken máshogy kell karaktert kiírni?
Title: Re: Assembly programozás
Post by: MrPrise on 2007.November.25. 22:05:40
Ezek szerint nem nézted meg a forrást... Jó, talán nem mindegyiken, de elég sok gépen működik.
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2008.March.12. 02:18:51
hamár előkerült ez a doksi http://ep.homeserver.hu/PDF/converting.pdf (legvége)
el tudnátok mondani pontosan mit csinál az lpt vsync része?
sosem értettem miért kell ez a trükközés a végén, azaz miért ilyen bonyolult?
eltérő módú sorok, különböző margókkal... ?
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2008.April.18. 18:39:19
na ki a nick guru?
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.April.18. 19:03:49
na ki a nick guru?
Tigrian! De õ sajnos mostanában nem jár erre :-(
Végignéztem a Nickrõl általa írtakat, de ez a rész kimaradt :-(
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.August.14. 20:38:17
Egyébként hogyan lehet, hogy a végén úgy indul újra az EP és jelenik meg a villogó ENTERPRISE felirat, hogy nincs elõtte memóriateszt  :?: Vajon igazi EP-n is lehet ilyet?
Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(
Az EXOS lapozórutinján keresztül kell meghívni az 1-es szegmenst, 6-os akciókóddal:
Code: [Select]
                LD A,6
                EX AF,AF'
                LD A,1
                LD HL,0C00DH
                JP 0B217H
Természetesen ekkor a 2-es lapon a rendszerszegmensnek kell lenni.
Title: Re: Assembly programozás
Post by: szipucsu on 2008.August.14. 21:20:26
Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(
Szerintem figyeltem én, csak amikor a valóságban is láttam ilyet, rendkívül meglepõdtem, mert ilyet még nem láttam. :D Elméletben nem döbbent le annyira. :D (Nem mintha értenék hozzá, hogy a kódban szereplõ hieroglifák mit jelentenek, leginkább talán pekingi boltok felirataira hasonlítanak.)
Akkor pl. basicbõl is ki lehetne adni ilyet, HEX és CALL USR utasítások segítségével? (Na jó, ALLOCATE is kell - ezzel ki is merült a gépi kód ismeretem.)
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.August.14. 21:33:02
Akkor pl. basicbõl is ki lehetne adni ilyet, HEX és CALL USR utasítások segítségével? (Na jó, ALLOCATE is kell - ezzel ki is merült a gépi kód ismeretem.)
Persze!
   10 PROGRAM "EPLOGO.BAS"
  100 ALLOCATE 11
  110 CODE E=HEX$("3E,06,08,3E,01,21,0D,C0,C3,17,B2")
  120 CALL USR(E,0)
Title: Re: Assembly programozás
Post by: szipucsu on 2008.August.14. 21:47:44
Persze!
   10 PROGRAM "EPLOGO.BAS"
  100 ALLOCATE 11
  110 CODE E=HEX$("3E,06,08,3E,01,21,0D,C0,C3,17,B2")
  120 CALL USR(E,0)

Ez igen!
Hogyan tudtad ilyen gyorsan megcsinálni? Kívülrõl tudod, hogy melyik utasításnak milyen hex kód felel meg, vagy valami más módszerrel?

(Egyébként azt hittem, véletlenül sikerült egyszer megjegyeznem, hogy a C3 = RET, de akkor ezek szerint nem az a RET, hanem valami JP?)
Title: Re: Assembly programozás
Post by: endi on 2008.August.14. 22:02:37
A Plusz bõvítménnyel marha jól lehet asm-ot tanulni. Simán be lehet írni az asm utasításokat a basic-ba. Asszem én is így tanultam, de lehet, hogy rosszul emlékszem.
Title: Re: Assembly programozás
Post by: nyuzga on 2008.August.14. 22:03:44
Ez igen!
Hogyan tudtad ilyen gyorsan megcsinálni? Kívülrõl tudod, hogy melyik utasításnak milyen hex kód felel meg, vagy valami más módszerrel?

(Egyébként azt hittem, véletlenül sikerült egyszer megjegyeznem, hogy a C3 = RET, de akkor ezek szerint nem az a RET, hanem valami JP?)

http://www.geocities.com/siliconvalley/peaks/3938/z80time.txt
Title: Re: Assembly programozás
Post by: szipucsu on 2008.August.14. 22:22:27
Na, C9 a RET, majdnem eltaláltam! De legközelebbre tuti megint összekeverem. :D
(Akkor a "keret" pl. "keC9".)
(Ja, meg a NOP-ot is tudom, hogy az 0 :D)
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.August.14. 22:31:42
vagy valami más módszerrel?
ASMON tud egybõl BASIC programnak fordítani, azt már csak ki kell egészíteni :-)
Title: Re: Assembly programozás
Post by: geco on 2008.September.15. 17:01:48
Belefutottam egy problémába a most átírás alatt álló programomnál, már egy éve elkezdtem.  :ds_icon_cheesygrin: ,csak mindig félbeszakad valami miatt. A EXOS által használt 0-ás szegmenst kilapozom, és helyére belapozok egy előre kiválasztott memóriaszegmenst, amire felmásolom a 0-ás szegmens tartalmát 0-200H-ig, és átállítom, ha jó emlékszem a BFFCh memóriacímet a megfelelő értékre. EP32 magnós konfig alatt nincsen semmi gondom a file betöltéssel, teljesen jól működik, de EP128 EXDOS-os config alatt CF-es hibaüzenetet ad vissza az EXOS1-es hívás.
A CF-ről nem találtam semmit.
 :?:
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.September.15. 18:29:58
A EXOS által használt 0-ás szegmenst kilapozom, és helyére belapozok egy elõre kiválasztott memóriaszegmenst, amire felmásolom a 0-ás szegmens tartalmát 0-200H-ig, és átállítom, ha jó emlékszem a BFFCh memóriacímet a megfelelõ értékre. EP32 magnós konfig alatt nincsen semmi gondom a file betöltéssel, teljesen jól mûködik, de EP128 EXDOS-os config alatt CF-es hibaüzenetet ad vissza az EXOS1-es hívás.
Ez izgi, mert ez én is csinálom a spectrum átiratos betöltõmben, EP64 esetére. Itt az FF szegmens lesz a nullás lap, betöltõ program, LPT és a rendszer szegmens egyben :-) és mûködik is az EXOS 1 magnóról, floppyról, vinyóról egyaránt! Annyi a fontos, hogyha te is FF szegmenst akarod erre használni, hogy az EXOS határt is be kell állítani, persze elötte kiutaltatni megosztott szegmensként.
A CF-rõl nem találtam semmit.
 :?:
A CF az számításaim szerint 207, az pedig File not found.
Itt vannak az EXDOS hibakódok, az angol EXDOS leírásban. (http://ep.homeserver.hu/Dokumentacio/Konyvek/EXDOS/EXDOSeng.htm#15) (Itt BASIC számmal emlegeti, normálisan értelemszerûen 9000-el kisebb kódok.)
Ill. van pár hibakód amire gyárilag nincs magyarázat, ezek közül jó pár belekerült az általam módosított EXDOS ROM-okba. Ilyen pl a Track not found, FAT error, meg még egy pár de a CF az gyári :-)
Title: Re: Assembly programozás
Post by: geco on 2008.September.16. 09:02:24
Köszi szépen, nem is tudtam, hogy -9000-rel kapható meg a kód.  :) Érdekes, mert úgy emlékszem, hogy az összes file-t felmásoltam a floppy image-re, de majd megnézem újra, a betöltő részt is, pár órám már ráment.  :ds_icon_cheesygrin:
Az FF szegmenst csak a 0-200h, meg az LPT tárolására használom most, a program 128K-s CPC-n, és az egyik memóriszegmensen, ami alapból is belapozódik 0. lapra, 0-200 h érintetlen marad, azt használom erre a célra.  :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.October.22. 11:17:19
el tudnátok mondani pontosan mit csinál az lpt vsync része?
sosem értettem miért kell ez a trükközés a végén, azaz miért ilyen bonyolult?
eltérõ módú sorok, különbözõ margókkal... ?
Én már kezdem érteni, egyszerüség kedvéért nézzünk egy üres LPT-t, ez van alapból az IVIEW-ben:
Code: [Select]
SYNC
            DEFB 106,12H,63,0,0,0,0,0,0,0,0,0,0,0,0,0   ;150 sor
            DEFB 106,12H,63,0,0,0,0,0,0,0,0,0,0,0,0,0   ;150 sor
            DEFB 253,10H,63,0,0,0,0,0,0,0,0,0,0,0,0,0   ;3 sor, a szinkronizacio kikapcsolva
            DEFB 252,10H,6,63,0,0,0,0,0,0,0,0,0,0,0,0   ;4 sor, a szinkronizacio bekapcsolva
            DEFB 255,90H,63,32,0,0,0,0,0,0,0,0,0,0,0,0  ;1 sor, a szinkronizacio a sor felenel kikapcsol
            DEFB 252,13H,6,63,0,0,0,0,0,0,0,0,0,0,0,0   ;4 ures sor
A 2 db 150 soros rész szabadon variálható képmegjelenítésre. Konkrétan az IVIEW esetén a kettõ közé jön a kép, ennek megfelelõen csökkentve ezeknek a hosszát. Ami megmarad ezekbõl a sorokból, az fogja a keretszínt megjeleníteni a kép alatt és felett.
Összesen itt 300 sorunk van, de nagy valószínûséggel egy átlag TV vagy monitor csak olyan 270-280-at tud megjeleníteni, a többi a képernyõn kívülre esik. (Mint ahogy vízszintesen is 46 karakter lehet a kép szélessége, de ebbõl jó ha 42 megjelenik.)
Ezután jön fixen 3 sor keret, ezt még meg kell vizsgálni, hogy kihagyható-e (és akkor 303 sor lesz az elõzõ szakaszban).
A következõ 4 sorral kezdõdik a szinkronizáció. Mivel a PAL szabvány elõírja, a jelszint itt 0-n legyen, ezért van az, hogy rendes margók vannak beállítva a teljes tartományra, és elvileg ugye a 0-ás videócímtõl jeleniti meg a képet, de ez nem számít mivel minden paletta szín fekete.
A következõ sorban a cseles margóval érik el, hogy a sor felénél abba maradjon a szinkronizáció, mint ahogy az a szabványban is van.
És a maradék szintén a szabványnak megfelelõen biztosít további nullás jelszintet a 4 fekete sorral.
Title: Re: Assembly programozás
Post by: Povi on 2008.November.23. 20:44:38
Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(
Az EXOS lapozórutinján keresztül kell meghívni az 1-es szegmenst, 6-os akciókóddal:
Code: [Select]
                LD A,6
                EX AF,AF'
                LD A,1
                LD HL,0C00DH
                JP 0B217H
Természetesen ekkor a 2-es lapon a rendszerszegmensnek kell lenni.


Két probléma van ezzel a módszerrel.
1. a kisebbik: nem szabadítja fel a felhasználónak kiutalt szegmenseket, ezt meg kell tennünk magunknak, ha tényleg elegánsan akarunk kilépni a programból.
2. a nagyobb probléma: nem működik EXOS 2.0-n. Ehhez módosítani kell az utolsó sort, JP 0B21C-re.
Title: Re: Assembly programozás
Post by: Zozosoft on 2008.November.24. 09:11:39
1. a kisebbik: nem szabadítja fel a felhasználónak kiutalt szegmenseket, ezt meg kell tennünk magunknak
Természetesen!
Quote
2. a nagyobb probléma: nem mûködik EXOS 2.0-n. Ehhez módosítani kell az utolsó sort, JP 0B21C-re.
Nem szép de mûködik  :oops: igaz végrehajt pár fölös utasítást  :oops:

De akkor legyen szép:
Code: ZiLOG Z80 Assembler
  1.                 LD A,6
  2.                 EX AF,AF'
  3.                 LD A,(0B21CH)
  4.                 CP 0D3H
  5.                 LD A,1
  6.                 LD HL,0C00DH
  7.                 JP Z,0B21CH
  8.                 JP 0B217H
Title: Re: Assembly programozás
Post by: Tuby128 on 2009.April.05. 19:59:02
Sziasztok!

Lenne egy kérdésem:
 Ha megírok egy programot az Asmon-ban, akkor hogy kell elmentenem ahhoz, hogy gép újraindítása után betöltéskor elinduljon? Milyen org címre kell fordítanom, egyáltalán melyik lapra tölti be?
 Meg ha lehet, kicsit részletesebb leírást kérek ezzel kapcsolatban, hogy az asmon-ban miket állítsak be.

Elõre is köszönöm a választ!
Title: Re: Assembly programozás
Post by: IstvanV on 2009.April.05. 20:31:54
Ha megírok egy programot az Asmon-ban, akkor hogy kell elmentenem ahhoz, hogy gép újraindítása után betöltéskor elinduljon?
Monitor módban a Z billentyű lenyomása után az 'Object file name'-nél meg kell adni a file nevet, az 'EXOS module header'-t YES-re állítani, és az 'EXOS module type' 5 legyen. Utána az A billentyűvel lehet lefordítani a programot. Természetesen a forráskódot sem árt menteni kilépés előtt :)
Quote
Milyen org címre kell fordítanom, egyáltalán melyik lapra tölti be?
100h címre, és a nullás lapra töltődik be a program eleje. Ha hosszabb, mint 15.75K, akkor az EXOS lefoglal legfeljebb két további szegmenst, és azokra töltődik a program többi része. Ezeknek a szegmenseknek a számát az FFh szegmensen a BFFDh és BFFEh címen lehet megtalálni (indításkor nincsenek belapozva). Ezt (http://www.ep128.hu/Ep_Konyv/Exos.htm#41) és ezt (http://www.ep128.hu/Ep_Konyv/Exos.htm#48) célszerű elolvasni.
Title: Re: Assembly programozás
Post by: Tuby128 on 2009.April.05. 22:41:03
Hány processzorütem kell, amíg a DAVE belapoz egy lapot a Z80-nak?
Az asmonban ha írok egy progit, és mondjuk az van benne, hogy OUT (0b2h),0FFh akkor a G végrehajtásával miért nem lapozza be? Csináltam késleltetõ rutint, és úgy sem változott.
 Talán blokkolja a lapozást az Asmon?
 Nem értem.
 Egyébként az In a, (0b2h) utasításra az akkumlátorba mindig 0 kerül. Ha viszont a C regisztert használom a cím megadására akkor bezzeg kiolvassa. Ez meg megint miért van?
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2009.April.06. 10:46:54
P2-t használja az asmon, próbáld P1-en (port 0b1h)
Title: Re: Assembly programozás
Post by: Tuby128 on 2009.April.06. 16:55:35
Hehe. Rájöttem! Szintaktikai hibát vétettem. Az egyik címke elõtt ott maradt egy pontosvesszõ. Nem találjátok ki milyen utasítás volt utána! De bizony! Out 0b2h,a :D Ekkora szégyent.
 Onnan jöttem rá egyébként, hogy elkezdtem disassemblálni a memóriában lévõ lefordított kódot, és feltûnt, hogy hiányzik egy sor.
 Mostmár sikerült kiíratni a státuszsorba, hogy szerény személyem milyen elmés, hogy ilyeneket tud :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.April.20. 15:59:18
EXDOS visszafejtésbõl, a HELP rutinban amikor a parancsok listáját írja ki.
Ha megnézzük a táblázatot, akkor látszik, hogy vannak definiálva olyan spéci "parancsok" amik nem kerülnek kiírásra.
A kiírórutinban zseniálisan egy szem BIT 5,(HL) utasítással megoldották annak eldöntését, hogy kiírandó parancsszóról van szó. Nagyon tetszik  :smt038
Code: ZiLOG Z80 Assembler
  1.         ;használható parancsszavak listájának kiírása
  2.  
  3.         LD      HL,LEC58        ;parancsok táblázata, HL az elsõ hosszbájtra mutat
  4. leb9e:  LD      C,(HL)          ;hosszbájt a C-be
  5.         LD      E,L
  6.         LD      D,H             ;LD DE,HL
  7.         INC     DE              ;DE a szöveg elejére mutat
  8.         XOR     A
  9.         LD      B,A             ;BC=a szöveg hossza
  10.         ADD     HL,BC           ;HL az utolsó karakterre mutat
  11.         BIT     5,(HL)          ;az utolsó karakter vizsgálata
  12.                                 ;normál nagybetûs szövegeknél
  13.                                 ;Z lesz az eredmény
  14.                                 ;a speciális * ill. EXDOS,FDH
  15.                                 ;esetén pedig NZ
  16.         INC     HL              ;végrehajtó
  17.         INC     HL              ;rutin címe
  18.         INC     HL              ;HL a következõ hosszbájtra mutat
  19.         JR      NZ,LEB9E        ;ugrás ha nem nagybetû
  20.         DEC     A               ;A=255, alapértelmezett csatorna
  21.         EXOS    08H             ;szöveg kiírása
  22.         LD      B,20H           ;szóköz
  23.         CALL    LEFD9           ;karakter kiírása
  24.         LD      A,(HL)          ;az új hosszbájt az A-ba
  25.         OR      A               ;=0?
  26.         JR      NZ,LEB9E        ;ciklus elejére, ha van még szöveg
  27.         LD      C,A             ;C=0
  28.         JP      LEFD2           ;ugrás a CR/LF kiírás rutinjára
  29.                                 ;ahonnan a RET-tel az EXOS-hoz tér vissza,
  30.                                 ;nullázott C regiszterrel, tehát a mûvelet
  31.                                 ;elvégezve
  32. LEC58:  DB 2,"**"
  33.         DW LED9A
  34.         DB 2,"CD"
  35.         DW LF27F
  36.         DB 2,"MD"
  37.         DW LF41B
  38.         DB 2,"RD"
  39.         DW LF3BE
  40.         DB 3,"***"
  41.         DW LED9A
  42.         DB 3,"DEL"
  43.         DW LF3BF
  44.         DB 3,"DIR"
  45.         DW LF2AB
  46.         DB 3,"CLS"
  47.         DW LF4DA
  48.         DB 3,"ERA"
  49.         DW LF3BF
  50.         DB 3,"REM"
  51.         DW LED9A
  52.         DB 3,"REN"
  53.         DW LF433
  54.         DB 3,"VAR"
  55.         DW LFB69
  56.         DB 3,"VOL"
  57.         DW LF495
  58.         DB 4,"ATTR"
  59.         DW LECD0
  60.         DB 4,"COPY"
  61.         DW LF4EF
  62.         DB 4,"DATE"
  63.         DW LF90C
  64.         DB 4,"ECHO"
  65.         DW LF4E2
  66.         DB 4,"LOAD"
  67.         DW LFB11
  68.         DB 4,"MOVE"
  69.         DW LF430
  70.         DB 4,"TIME"
  71.         DW LF90B
  72.         DB 4,"TYPE"
  73.         DW LF4E9
  74.         DB 5,"ATDIR"
  75.         DW LECC8
  76.         DB 5,"CHDIR"
  77.         DW LF27F
  78.         DB 5,"ERASE"
  79.         DW LF3BF
  80.         DB 5,"EXDOS"
  81.         DW LEDA3
  82.         DB 5,"ISDOS"
  83.         DW LFA9E
  84.         DB 5,"MKDIR"
  85.         DW LF41B
  86.         DB 5,"MVDIR"
  87.         DW LF42F
  88.         DB 5,"PAUSE"
  89.         DW LFB31
  90.         DB 5,"RMDIR"
  91.         DW LF3BE
  92.         DB 5,"RNDIR"
  93.         DW LF432
  94.         DB 6,"EXDOS",0FDH
  95.         DW LED9C
  96.         DB 6,"FORMAT"
  97.         DW LFA44
  98.         DB 6,"RENAME"
  99.         DW LF433
  100.         DB 6,"ASSIGN"
  101.         DW LED00
  102.         DB 7,"RAMDISK"
  103.         DW LFB3D
  104.         DB 7,"MAPDISK"
  105.         DW LED01
  106.         DB 0
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.May.01. 12:22:26
Szintén EXDOS, aranyos kis trükk, hogyan helyettesítsünk egy bájttal egy két bájtos közeli JR-t! A töltelékbájtokat tessék figyelni :-)
Code: ZiLOG Z80 Assembler
  1. lfd34:  LD      A,(IY-2AH)      ;eddigi paraméter értékek
  2.         OR      (HL)            ;aktuális hozzáadása
  3.         INC     DE              ;következõ szövegkarakter
  4.         POP     HL              ;paramétertábla címe vissza
  5.  
  6.         ;töltelék bájt, hogy az utána következõ XOR A ne fusson le
  7.  
  8.         DB 0EH ;LD      C,0AFH
  9.  
  10.         ;/ paraméterek keresése
  11.         ;DE=szövegpuffer
  12.         ;HL=paramétertáblázat címe, a táblázat két bájtos elemekbõl épül fel
  13.         ;az elsõ a parméter karakter, a második a hozzátartozó érték
  14.  
  15.         ;Z lesz, ha már nem / paraméter a következõ szó
  16.         ;NZ, ha van / paraméter, de az nincs a táblázatban
  17.  
  18. LFD3B:  XOR A                   ;paraméter kezdõérték
  19.         SET     0,A
  20.         LD      (IY-2AH),A      ;RAM terület 53H címe, itt gyûjti a
  21.                                 ;paraméter értékeket
  22.         EXX    
  23.         LD      C,A             ;C'=paraméterérték
  24.         EXX    
  25.         PUSH    HL              ;paramétertábla címe a verembe
  26.         CALL    LFC05           ;szóköz és TAB karakterek átugrása
  27.         LD      A,C             ;a következõ karakter
  28.         CP      2FH             ;="/"?
  29.         JR      NZ,LFD5D        ;kilépés a keresésbõl, ha nem
  30. lfd4d:  LD      A,(DE)          ;A-ba a / utáni karakter
  31.         CALL    LFE31           ;nagybetûsítés
  32.         CP      (HL)            ;összehasonlítás a paramétertábla
  33.                                 ;aktuális karakterével
  34.         INC     HL              ;mutató a paraméterhez tartozó értékre
  35.         JR      Z,LFD34         ;paraméter érték letárolása, ha találat van
  36.         INC     HL              ;táblázat következõ eleme
  37.         LD      A,(HL)          ;karakter az A-ba
  38.         OR      A               ;táblázat vége?
  39.         JR      NZ,LFD4D        ;ha nem, akkor az újabb elem összehasonlítása
  40.         OR      0AEH            ;A-ba az "Invalid parameter" hibakód
  41.                                 ;és egyben NZ flag beállítás
  42.         ;töltelék bájt, hogy az utána következõ DEC DE, XOR A ne fusson le       
  43.  
  44.         DB 0CAH ;JP      Z,LAF1B
  45.  
  46. LFD5D:  DEC DE                  ;mutató vissza az elözõ karakterre
  47.         XOR A                   ;Z flag
  48.         POP     HL
  49.         RET
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.May.01. 18:34:14
gondolom, a túlcsordulást nem veszi figyelembe, és csak az alsó byte-ot használja fel
Igen, itt a bûnös:
Code: ZiLOG Z80 Assembler
  1. lfda3:  XOR     A               ;kezdõ érték 0
  2. lfda4:  LD      C,A             ;aktuális érték
  3.         CALL    LFDD1           ;numerikus karakter?
  4.         RET     C               ;visszatérés, ha nem
  5.  
  6.         PUSH    AF              ;karakter értéke a verembe
  7.         LD      A,C             ;A-ba az eddigi érték
  8.         ADD     A,A             ;A=eddigi érték*2
  9.         LD      C,A             ;C=eddigi érték*2
  10.         ADD     A,A             ;A=eddigi érték*4
  11.         ADD     A,A             ;A=eddigi érték*8
  12.         ADD     A,C             ;A=eddigi érték*10
  13.         LD      C,A             ;C=eddigi érték*10
  14.         POP     AF
  15.         ADD     A,C             ;A=most talált érték+10*eddigi érték
  16.         JR      LFDA4           ;következõ karakter keresése
Mint látható a konvertálást buzgón megcsinálja mindaddig, míg el nem fogynak a szám karakterek, viszont a túlcsordulással nem foglalkozik.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.10. 00:31:21

Sziasztok, par napja egy demo- effekten kuzdok, es nem allitanam hogy nagy sikerrel. Emlekeztem en, hogy anno mikor az EP- t terveztek hiaba csinaltak bele a remek video modokat, ha scroll es sprite HW hianyaban a z80 keptelen megmozgatni azt a memoriat, ami a kepet alkotja. Ez mar anno is nagyon zavart engem, hogy egy C60 csilliard eve meglete, es az amiga hajnalan hogy lehetett ilyen cuccot tervezni, amibol ugy kell kicsikarni, osszesoprogetni, barmi kis teljesitmenymorzsat.

Naszo par napja egy demoeffektel kuzdeok, es kerdeznem, hogy van- e valaki, aki sebessegorientalt kodokat irogatott ( demo, jatek ), es vannak emlekei, vagy most is csinalja ? Egy ket kerdesem lenne, csak ugy aranyaiban az EP sebessegere vonatkozoan, mert meg a vartanal az emlekezettnel is nagysagrendekkel lassabbnak tunik az EP, pontyosabban az emulator, es szeretnem megtudni, vajon tenyleg ilyen rossz- e a helyzet...

Z80System


Title: Re: Assembly programozás
Post by: endi on 2009.September.10. 17:47:07
Scroll tekintetében ajánlom a Scroll demo megnézését.

Az EP videó teljesítménye másban mutatkozik meg, nem scrollban vagy sprite-okban. Nézd meg az újonnan konvertált pc képeket, elég döbbenetesen néznek ki EP-n.

(Ha még nem láttad volna ezeket persze...)
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.10. 22:58:51

scroll alatt teljes kepernyos, jatekhoz valo scrollra gondoltam, es rajta mozgo sprite- okkal, endi. ilyet a scroll demo sem tudott ( ha tudott volna, en is tudnam, vagy megkerdeznem a lacit ), ahol pedig nem csak scroll effekt volt, ott nem is ment frame- esen.

attol meg hogy ki tudunk rakni egy allokepet nekem nem lesz sajna orgazmusom, bar persze erdekes par masodpercig.

en ilyen demo effekteket szerettem csinalni mindig is.

most pld. ilyen animalt csillagakot szeretnek ( nem egy pixeleseket ) amik additivan kerulnek kirakasra, es ugy tunik nem tom megcsinalni... szomorusag hegyek... meg egy napot raszanok valszeg, de tobbet mar csak kis reszletekben, a jovoben.


Title: Re: Assembly programozás
Post by: MrPrise on 2009.September.11. 01:04:50
Amennyire én tudom a demó definíciójában az is szerepel, hogy a gép képességeit minél jobban kihasználó program.
Ezek a képek (ill. a megjelenítő program) amelyeket endi említett elég rendesen kihasználják gépünk grafikai képességeit, szóval akár demónak is tekinthetjük. Sőt, ilyen képekkel bármelyik demót fel lehetne dobni. Annak aki akkor látná először biztos tátva maradna a szája. A demókba egyébként is szoktak képeket rakni, átvezetésnek is. Ezeknek a képeknek a megjelenítése szép teljesítmény gépünktől és persze Istvántól és Zozotól. Pár másodpercnyi érdekességnek semmiképp sem nevezném.
Title: Re: Assembly programozás
Post by: Lacika on 2009.September.11. 09:53:26
Én ugyan érdemben nem tudok hozzászólni a gépi kódú programozás "rejtelmeihez", de talán érdemes megnézni e tárgyban a Wopus (http://www.ep128.hu/Ep_Games/Leiras/Wopus.htm) c. játékot, ahhoz van forráskód is!
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 10:44:23

:) Na jova, ugy laccik jobb lesz, ha csendbe maradok, mer meg kihuzom a gyufat ... raadasul nem is abba az iranyba megyunk amerre szerettem volna, nem a definialgatasok, meg ilyenek lennenek a cel, megha pongyolan fogalmaztam volna, vagy akar tokhulyesegeket is ...

Istvan es Zozo teljesitmenyenek megkerdojelezese meg veletlen sem allt a szandekomban. ( Mint emlitettem az emuban dolgozok, amit a mai napig nem ertek hogyan lehet csak ugy jatekbol, kedvtelesbol elkesziteni ennyire jora, mikozben Zozo a mindenkori helpem, barmi van, mindig tole kerdezek )

Es valo igaz, kihagytam, hogy a felfele scrollt engedelyezi az ep hardware- e, a c64- e meg tulajdonkepp csak a vizszintest, ugyhogy 1-1.

Nem is ezen cirkuszoltam, hanem hogy az ember mikor regen gepet vett, akkor az volt neki, es semmi mas, es azt varta, hogy mindent lehet, csak meg kell neki tanulnia. Es mikozben szepen megtanulta rajott, hogy hat azert nem lehet mindent ...

Es most mikor +15 ev programozas utan ujra probaltam valamit, ujra ledobbentett, hogy milyen marha lassan lehet akar csak par pixelt is szoftverbol (nem nick trukkel) megmozgatni a kepen.


Title: Re: Assembly programozás
Post by: Lacika on 2009.September.11. 10:59:40
Es valo igaz, kihagytam, hogy a felfele scrollt engedelyezi az ep hardware- e, a c64- e meg tulajdonkepp csak a vizszintest, ugyhogy 1-1.

Es most mikor +15 ev programozas utan ujra probaltam valamit, ujra ledobbentett, hogy milyen marha lassan lehet akar csak par pixelt is szoftverbol (nem nick trukkel) megmozgatni a kepen.

A WOPUS-ban függőleges scroll van, nézd meg a forráskódját hátha segít.
A CPC-s Commando (http://www.ep128.hu/Ep_Games/Leiras/Commando.htm)-ban függőleges scroll, az Eggs of Death (http://www.ep128.hu/Ep_Games/Leiras/Eggs_of_Death.htm)-ban pedig vízszintes van, ez utóbbi ráadásul elég gyors!
A Fire (http://www.ep128.hu/Ep_Games/Leiras/Fire.htm) egyik szintjén emlékeim szerint elég gyors függőleges scroll van (nem karakteres), ráadásul osztott képernyőn. De hogy hogy csinálják...???  :oops:

Amikor scanneltem a könyveket viszont pont az feltűnt, hogy a gépi kóddal foglalkozó könyvek megemlítik, hogy a rengeteg bitléptető-, rotáló utasítással nagyon hatékonyan lehet vízszintes scroll-t csinálni.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 11:16:03

A wopus tippedrol ( a keperol ) jutott eszembe, hogy ja tenyleg, a felfele scroll az tamogatott, a nick kepessegeit kihasznalva meg lehet mozgatni egy teljes kepernyonyi grafikat fuggoleges iranyaban. Ennek a kodnak az elemzese azonban nem szukseges, mert ezt tudom hogy kell csinalni.

Csakhogy ha hiszed ha nem, az mar hogy egy par sprite- ot kirakj arra a felfele scrollozodo kepre, foleg ha az 50Hz hataron belul ( legfolyamatosabb mozgasu kep, rangatozas nelkul ) az mar egy z80- t probalo feladat. Sot, ha engem kerdezel, igazabol az en izlesem szerint, el is bukik az EP a megmerettetesben. Pld. sztm az kielegito lehetne, ha mondjuk 4 szinu uzemmodban, 32*32 pixeles sprite- okbol ki lehetne tenni ugy 16 darabot 50Hz- el, ugy kb 50% cpu idovel...

Az viszont erdekelne hol irnak olyat hogy bitleptetesekkel remekul lehet scrollozni... egyreszt sztm a kepernyo felso ket pixelsorat lehetne max megmozgatni ( trukk nelkul! ) z80- al ...

Title: Re: Assembly programozás
Post by: Lacika on 2009.September.11. 11:25:20
Elhiszek én mindent neked a témában, a gépi kódú programozás nekem "kínaiul van"...
Példákat tudtam mutatni, de nem tudom, hogy csinálják. Az Eggs of Death-ban jó gyors vízszintes scroll van, igaz csak két sprite-al.
Viszont pont a Wopus-ban is a háttér előtt elég sok "ketyere" repked egyszerre a képernyőn.
A másik hasonló program a Shoot em' Up (http://www.ep128.hu/Ep_Games/Leiras/Shoot_emUp.htm)
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 11:29:30
Amikor scanneltem a könyveket viszont pont az feltűnt, hogy a gépi kóddal foglalkozó könyvek megemlítik, hogy a rengeteg bitléptető-, rotáló utasítással nagyon hatékonyan lehet vízszintes scroll-t csinálni.

Igaz, csak a képernyő egy kis részén :) Még a legegyszerűbb esetben (2 színű LPIXEL mód) sem lehet bitléptető utasításokkal megoldani egy "Spectrum méretű" képernyő scrollozását másodpercenként 50-szer, csak kb. a felét, és akkor másra már nem is nagyon marad idő.
Vízszintes scrollra fel lehet használni az LPT-ben az LD1/LD2 címek módosítását, bár így csak fél karakteres felbontással lehet mozgatni a képet (PIXEL módban, egyébként csak egész karakterekkel), ami vagy túl gyors, vagy darabos és nem túl jól néz ki. De talán a másodpercenként 25-ször fél karakter elfogadható.

EP-s demo készítésénél az LPT valós idejű módosítására (video cím, paletta, margók) érdemes építeni, mert így sokkal kevesebb adatot kell feldolgozni adott idő alatt, mint maguknak a pixeleknek a változtatásával. Egy nagy, előre kiszámított állóképből ilyen módon érdekes effektusokat lehet létrehozni. Ennél a scrollnál például csak a 8 paletta szín változik:
[attachthumb=#]
Egy kép vízszintes mozgatását vagy "hullámoztatását" meg lehet oldani úgy is, hogy a video cím (és esetleg a margók) állításával fél karakteres mozgatás legyen, és ezen kívül 2 vagy 4 kép legyen a memóriában a fél karakteren belüli fázisokhoz.
Talán a karakteres módokat is fel lehet használni; a karakterek vagy a karakterkészlet változtatásával szintén gyors animációt lehet elérni.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 11:50:59

Stimmel, en is ezekkel operaltam mindig is ( a nagy meltatlankodasok kozepedte, hogy miert nem lehetett kitalalni valamit erre, hogy semmire nincs ido, akik a gepet terveztek sztm ezekkel abszolute tisztaban voltak ), de azert most megis meglepodtem, hogy mikor pld. csinaltam egy pixelsoros lpt- t, es a fuggoleges kb. 150 lpb- jeben atirom a memoriacimet vagyis osszesen atirok kb 300 byte- ot, es kozben novelem a cim erteket, kifejtve, megprobaltam tobbfele maggal, es megis olyan 30 rastersor idot elvisz... hat ez erttenetes ... 10%- at hogy atirom a cimeket ... marha sok ... persze lehet trukkozni dobb frame lpt- be foglalasaval, es akkor meg lehetne sporolni az idot mert nem kell kezzel a cimeket felulirni, de akkor nem lehet valtozo fps- su a cucc, mert az lpt mindig valtani fog, ahogy egyszer lataroltad...

szal nem meglepo hogy olyan nehez volt mindent megcsinalni ... ezzel a cpu teljesitmennyel egy muveszet barmit is csinalni.


Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 11:57:35
Pld. sztm az kielegito lehetne, ha mondjuk 4 szinu uzemmodban, 32*32 pixeles sprite- okbol ki lehetne tenni ugy 16 darabot 50Hz- el, ugy kb 50% cpu idovel...

PIXEL módban ilyenből (egy sprite 8*32=256 byte) szerintem 2-t lehet megoldani, ha fontos, hogy a sprite-ok megfelelően takarják a hátteret, és az eredeti pixeleket vissza is lehessen állítani. Egyszerű XOR művelettel valamivel gyorsabb, de nem sokkal. A byte-ok felülírásával kb. kétszeres gyorsulást lehet elérni.
A karakteres mód, a sprite-oknak a karakterkészlet egy részét fenntartva jobb, mert a háttér mentése/visszaállítása csak a karakterek, és nem a pixelek másolását jelenti. Természetesen a leggyorsabb a karakteres mód takarás nélkül (de a sprite-ok tartalmazhatnak például egyszerű fix hátteret, amely minden karakternél egyforma), így már talán nem probléma a 16 4x4 karakteres sprite.
Title: Re: Assembly programozás
Post by: szipucsu on 2009.September.11. 12:25:35
Ha jól emléxem egyébként, Commodore-on a Timeship (vagy Timeslip?) címû játékban sem az egész képernyõ scrollozik egyszerre, hanem a képernyõ három játéktérre van osztva és abból az egyiken folyik a játék. Jó, persze vannak egész képernyõn scrollozó játékok, pl. a Cauldron úgy tudom, ilyen.
Egyébként EP-n a Zynaps, Uridium, R-type is használ vízszintes scrollt, meg a Raid Over Moscow-ban is van ilyen rész, + Gunrunner. (Az Áttörést direkt nem akartam említeni. :D )
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 12:32:07

Timeslip -ben az volt a lenyeg, harom palya volt, attol meg a c64 hw alapbol az egesz kepet eltolja, idozitessel kell allitani a hw scroll regisztert az osztott scrollhoz, de meg lehet csinalni az a lenyeg, vizszintesen, kb. 0 prociidovel.

Tobbi felsorolt jatek (ha jol emlekszem mind) spectrum atirat, tehat az attributum grafikat scrollozzak /sprite- oljak, sztm nem elegseges performanciaval. ( lassu akadozos cuccok ... :) ) anyam... en leszek az EP fekete baranya ... :)


Title: Re: Assembly programozás
Post by: szipucsu on 2009.September.11. 12:43:53
Na, most erre talán azt tudnám mondani, az EP már egy komolyabb gép, amit nem kifejezetten játékra terveztek.  :ds_icon_cheesygrin:  :lol: Így pl. tovább bõvítve a memóriát már komolyabb adatbázisok feldolgozására lenne alkalmas, amire más 8 bites gépek nem. (Ha nem tévedek.)
A basic is lassú, de jól áttekinthetõ, így pl. pedagógiai célokra, a problémamegoldó készség fejlesztésére jobban megfelel, mint más gépeké. :D (Vagy angoltanulásra, mert meg lehet ismerni a pitch, duration, else, exception, case, handler, stb. szavakat. :D)

Egyébként érdekes, hogy napjainkig egyre nagyobb teljesítményû procikat, gépeket terveznek, de akkora értelme ennek sincs egy hétköznapi felhasználó számára, csak akkor, ha játszani akar. Pl. szöveget szerkeszteni továbbra is teljesen jó lenne a Windows 95. (Jó, én mondjuk videót szoktam tömöríteni, azért ahhoz is jól jön a nagyobb teljesítmény.)
Title: Re: Assembly programozás
Post by: szipucsu on 2009.September.11. 14:47:27
Azt nem lehet gépi kódú programozással megoldani, hogy a képet fordítsa el 90%-kal? Mert ezzel a függõleges scrollból egybõl vízszintes lehetne.
(Másik megoldás, ha a tévét/monitort fordítjuk el 90%-kal. :D )
Title: Re: Assembly programozás
Post by: endi on 2009.September.11. 18:06:00
Most nézem, Z80System az FT Stúdió tagja volt? Mert hogy ott a logó a neved alatt. :) Akkor nem ajánlgatom a Scroll demót. :)))

Amúgy sok Spectrum játék, fõleg amelyekben 4 irányú és 50Hz-n futó scroll volt, nem scrollozott igazából hanem spriteokat rakott ki, azaz pálya elemeket. Minden elemnek megvolt a 8 változata, pixelenként eltolva, így gyorsan lehetett kirakni egész sokat, amelybõl aztán összeállt a pálya.

Csakhogy EP-n 2x akkora memória területet kell mozgatni ha ugyanakkora képernyõterületen akarunk scrollt, és nem lores üzemmódokat használunk. Ehhez pedig már nem elég az a kis z80 plusz sebesség ami van a Specyhez képest...

De azért szerintem lehetne egy elég komoly, elég nagy képernyõs, az említett Specy játékokhoz hasonlót csinálni, szép pixeles scrollal, jópár ellenféllel, nagy pályával. De ez már sosem fog megtörténni. :)
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 19:57:18
Visions Demoban láttam vízszintes gyors scrollt, igaz nem egész képes.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 20:12:53
gyors alatt nem azt ertjuk hogy gyorsan megy, sot, epp az a jo, ha a legkisebb lepessel ( adott mod pixelmeret ) tud lepni, tehat epp lassan folyik, csak a gep kb zero prociidovel tudja csinalni ... szal nem a scroll gyors, az eppen lassu, hanem a modszer gyors= kis prociigeny.
Title: Re: Assembly programozás
Post by: szipucsu on 2009.September.11. 20:22:29
szal nem a scroll gyors, az eppen lassu, hanem a modszer gyors= kis prociigeny.
Végülis az EP 4MHz-es, a C64 1MHz-es, szóval ha pl. 2Mhz "elmegy" a scrollra, még mindig marad 2 MHz másra.  :ds_icon_cheesygrin:
Ha meg C64-en mondjuk 1% prociterhelés volt scroll miatt, akkor is csak 0.99MHz proci maradt a többi dologra.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 20:43:33
hat ugy kb 10-20- szor kene az EP- nek gyorsabbnak lennie ... es mar menne is a dolog ... :)


Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 20:58:13
nem tudja valaki hogy milyen assemply mnemonikra fordul le az exos x hivas assemplyben ?

en most nem EP assemblerrel tolom, es nemtom mit irajak az exos 1, exos 6 satobbi hivasok helyett ...


Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 21:05:24
nem tudja valaki hogy milyen assemply mnemonikra fordul le az exos x hivas assemplyben ?

Code: ZiLOG Z80 Assembler
  1.         rst   30h
  2.         defb  x
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 21:22:40
gyors alatt nem azt ertjuk hogy gyorsan megy, sot, epp az a jo, ha a legkisebb lepessel ( adott mod pixelmeret ) tud lepni, tehat epp lassan folyik, csak a gep kb zero prociidovel tudja csinalni ... szal nem a scroll gyors, az eppen lassu, hanem a modszer gyors= kis prociigeny.

Volt egy ilyen megérzésem. :D Azért is jutott eszembe ez a demó, mert gyors a scroll, és ha az gyors, akkor gyanúsan a rutin is gyors, kevesebb prociidőt eszik, a léptetésre nem emlékszem, de csak nem karakteres. :D
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 21:40:08


nincs defb sem, nem talalom, ilyen kodot irtam, hogy betoltson egy "d00"  nevu file- t. ez jo ? :


   0852 21r49s0B           1683       ld hl,#_g_FileName
   0855 3E 03              1684       ld a,#3
   0857 77                 1685       ld (hl),a
   0858 23                 1686       inc hl
   0859 3E 64              1687       ld a,#100
   085B 77                 1688       ld (hl),a
   085C 23                 1689       inc hl
   085D 3E 30              1690       ld a,#48
   085F 77                 1691       ld (hl),a
   0860 23                 1692       inc hl
   0861 3E 30              1693       ld a,#48
   0863 77                 1694       ld (hl),a
   0864 23                 1695       inc hl
                           1696    
   0865 21r7Cs08           1697       ld hl,#RST00
   0868 3E 01              1698       ld a,#1
   086A 77                 1699       ld (hl),a
   086B 21r86s08           1700       ld hl,#RST01
   086E 3E 06              1701       ld a,#6
   0870 77                 1702       ld (hl),a
   0871 21r8As08           1703       ld hl,#RST02
   0874 3E 03              1704       ld a,#3
   0876 77                 1705       ld (hl),a
                           1706    
   0877 AF                 1707       xor a
   0878 11r49s0B           1708       ld de,#_g_FileName
                           1709    
   087B F7                 1710       rst #0x30
   087C                    1711     RST00:
   087C 00                 1712       nop
   087D 20 0C              1713       jr nz, Continue
   087F 11 00 60           1714       ld de,#0x6000
   0882 01 FF FF           1715       ld bc,#0xffff
                           1716    
   0885 F7                 1717       rst #0x30
   0886                    1718     RST01:
   0886 00                 1719       nop
   0887 20 02              1720       jr nz, Continue
                           1721    
   0889 F7                 1722       rst #0x30
   088A                    1723     RST02:
   088A 00                 1724       nop
   088B                    1725     Continue:
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 21:42:37
 ( mert mukodni nem mukodik :) )

Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 21:52:50
hopsz... muxik...
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.September.11. 21:57:26
nincs defb sem
Akkor kéne keresni egy normális assemblert :-)
DB sincs?

Quote
ez jo ? :
Nem jó mert hiányzik a RST 30 mögül a funkciót definiáló bájt.
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 21:59:03
hopsz... muxik...

milyen assemblert használsz?
Eddig még nem találkoztam olyan PC-s Z80 assemblerrel , ami ne ismerte volna a DEFB-t, és a DB-t.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 22:00:32
de vegulis mukodik, a baj az volt hogy csak "d0"- nak hivom a file- t, es "d00"- t akartam tolteni...

a nop -ok helyere kerul az rst "parametere". hogy kell ide attacsolni ?

Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:01:07
Nem jó mert hiányzik a RST 30 mögül a funkciót definiáló bájt.
Megvan az, csak DEFB hiányában a program tölti fel, én is néztem egy darabig :D
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 22:02:06
ez egy inline assembler, nemtom h melyik, az SDCC nevu c forditoban van benne. lehet van defb, csak en nem talaltam, jo most az a hekk, majd megkeresem.

Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:02:18
a nop -ok helyere kerul az rst "parametere". hogy kell ide attacsolni ?


Ha írsz egy hozzászólást, akkor nyisd le az additional optiont...
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 22:10:45
Na itt a Flying Time Studio legujabb :) demojanak elso effektjenek 0.0 -as verzioja. Nem tom mikor folytatom, de biztos nem fog villamgyorsan keszulni... ez a kis darabka kb. 1 hetig tartott... rendesen egesz nap ... :) vicces ...

Be kell tolteni a "d" nevu file- t valamivel 1000H -ra es lefuttatni. Akik meg nem csinaltak ilyet:

- futtasd az ASMON -t
- nyomj "r" billentyut
- ird be hogy "1000" + enter
- ird be hogy "3000" + enter
- ird be hogy "d" + enter
- nyomj "g" billenytut
- ird be hogy "1000" + enter

space - pause
esc - exit



ha valaki ki tudna probalni igazi gepen az jo lenne, mert az exdosom most nem muxik, massal meg most nem tom betolteni.
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:27:22
Azt kell, hogy mondjam, fasza. :) Nem kellenek ide sprite-ok ;)
Title: Re: Assembly programozás
Post by: endi on 2009.September.11. 22:34:06
légyszi futtatható verziót...
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 22:35:31
hat kene egy dupla sebesseg a ketszer ennyi csillaghoz, kene egy dupla hogy 50Hz -es legyen ne 25Hz  -es, es kene egy dupla ahhoz, hogy ne kelljenek elore letarolt mintak, hanem valos idoben lehessen 3D forgatni.... az tehat nyolcszoros... 4 * 8 = 32Mhz- es z80- u EP- vel mar ki is bekulnek... :)
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:42:37
hat kene egy dupla sebesseg a ketszer ennyi csillaghoz, kene egy dupla hogy 50Hz -es legyen ne 25Hz  -es, es kene egy dupla ahhoz, hogy ne kelljenek elore letarolt mintak, hanem valos idoben lehessen 3D forgatni.... az tehat nyolcszoros... 4 * 8 = 32Mhz- es z80- u EP- vel mar ki is bekulnek... :)
Az emulátoron beállítható. :D Nyomtam már 64 Mhz-is. :D
Nekem tetszik ennyi csillaggal is, és 25hz-en is. ;)
Szerintem a legtöbb demóban előre eltárolt értékekkel operálnak, nem számolgatnak valós időben, az túl sok időt vinne el, még Amigán is.
Title: Re: Assembly programozás
Post by: endi on 2009.September.11. 22:44:19
Igazából a mai pc-k matematikai számolásai is brutális táblázatokat használnak a gyorsításhoz ha jól tudom...
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 22:45:28
Nemtom hogyan kell, endi... Futtathatot regen is csak 2X csinaltam osszesen ... SOMB1, SOMB2 :)  Valahova masik cimre kellett forditani, es valamilyen fejlecet tett ele az EP fordito, es valami masik szegmenseket kellett lapozgatni, mar nem emlekszek, es annyit nem er az egesz, hogy igy vackoljak vele, csak egy effekt, annak is csak az alapja... neked nem lehet gond asmon- ban elinditani ... tenyleg csak annyi mint amit oda leirtam ... elindit asmon, megnyomkod amit odairtam, es kesz...
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:47:49
Igazából a mai pc-k matematikai számolásai is brutális táblázatokat használnak a gyorsításhoz ha jól tudom...
Pedig ott aztán szinte senki nem törekszik arra, hogy gyors kódot írjon. :D
Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 22:51:45
Nemtom hogyan kell, endi... Futtathatot regen is csak 2X csinaltam osszesen ... SOMB1, SOMB2 :)  Valahova masik cimre kellett forditani, es valamilyen fejlecet tett ele az EP fordito, es valami masik szegmenseket kellett lapozgatni, mar nem emlekszek, es annyit nem er az egesz, hogy igy vackoljak vele, csak egy effekt, annak is csak az alapja... neked nem lehet gond asmon- ban elinditani ... tenyleg csak annyi mint amit oda leirtam ... elindit asmon, megnyomkod amit odairtam, es kesz...
nem nagy kunszt, a fejlécben is két hasznos infó van, én a következőképp oldottam meg, hogy PC-s assemblerrel is lehessen mókolni:
Code: [Select]
                ORG 00f0H
db 00,05
dw fillen
db 00,00,00,00,00,00,00,00,00,00,00,00
        startpr
        ...
fillen          EQU $-startpr
Ahol a fillen a file hossza.
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 22:56:53
légyszi futtatható verziót...

[attachurl=#]
Title: Re: Assembly programozás
Post by: endi on 2009.September.11. 23:02:57
húú marha jó :D
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 23:06:30
ez egy inline assembler, nemtom h melyik, az SDCC nevu c forditoban van benne. lehet van defb, csak en nem talaltam, jo most az a hekk, majd megkeresem.

Én PC->Z80 fordításra az SjASM-et használom, amely megtalálható például az EPvideoconv (http://enterpriseforever.com/dlattach.html;topic=358.0;attach=2681) csomagjában is Windowsra és Linuxra fordítva. Ennél biztosan van sokkal jobb is, de mindenesetre használhatónak tűnik, és ismeri a defb-t.
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 23:09:47
Pedig ott aztán szinte senki nem törekszik arra, hogy gyors kódot írjon. :D

Azért néha igen :)
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 23:13:33
IstvanV a nagy varazslo.... hat ezt meg hogy csinaltad ? Voltak a kodban abszolut ugrasok... meg minden ...

De ha mar igy van, akkor azt tudod hogy esc utan miert nem jon vissza a rendszer ? ASMON- ban siman visszater. BASIC- ban miert nem ?


Title: Re: Assembly programozás
Post by: geco on 2009.September.11. 23:18:33
IstvanV a nagy varazslo.... hat ezt meg hogy csinaltad ? Voltak a kodban abszolut ugrasok... meg minden ...

De ha mar igy van, akkor azt tudod hogy esc utan miert nem jon vissza a rendszer ? ASMON- ban siman visszater. BASIC- ban miert nem ?
van egy tippem, kimentette az emulátorral a 100h-a program végéig, és készült elé egy fejléc :)
Az EXOS 5 -ös fejléccel rendelkező programok betöltése után egy melegindítás történik,vagy inicializálás, vagy mi :)
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 23:22:13
Hmmm.... ez igy tenyleg tok egyszeruen hangzik... persze ha ismered az emut es az exost... es az a tomorites dolog ... az mi volt ?... valakinek nincs ep- n helye ... :)  vagy mi ?


Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 23:23:44
Nemtom hogyan kell, endi... Futtathatot regen is csak 2X csinaltam osszesen ... SOMB1, SOMB2 :)  Valahova masik cimre kellett forditani, es valamilyen fejlecet tett ele az EP fordito, es valami masik szegmenseket kellett lapozgatni, mar nem emlekszek, es annyit nem er az egesz, hogy igy vackoljak vele, csak egy effekt, annak is csak az alapja... neked nem lehet gond asmon- ban elinditani ... tenyleg csak annyi mint amit oda leirtam ... elindit asmon, megnyomkod amit odairtam, es kesz...

A geco által leírt fejlécen kívül még arra kell figyelni, hogy a program elején be kell állítani a veremmutatót (pl. 100H-ra), mert egyébként az első EI vagy EXOS hívásnál lefagy :)
Ha a program nem fér el a 100H-3FFFH területen, akkor a második és esetleges harmadik szegmens az FFH szegmens végén található táblázatból olvasható ki (FFH:3FFCH: 0. lap, 3FFDH: 1. lap, stb.); a megfelelő szegmenseket az 1.-3. lapokra be kell lapozni, mert egyébként ezek indításkor meghatározatlanok.
Melegindítási címet resethez az FFH:3FF8H címre lehet beírni, és ennek a 0. lapon kell lennie. A hívásakor hasonlóak a feltételek, mint a program indításakor, és szintén be kell állítani a veremmutatót, lapozást, stb.
Title: Re: Assembly programozás
Post by: Ep128 on 2009.September.11. 23:27:42
Nekem ez nagyon tetszik, abba ne hagyd!!!  ;-)
(Esetleg nem lehetne a piros helyett kék színt használni? A csillagok inkább kékes fehérek, sem mint pirosas fehérek.  :) De ez csak a hülye fejem kötekedése, meg nem is tudhatom, mit szeretnél majd kihozni az egészbõl, szóval ne hallgass rám!  :lol: )
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.11. 23:28:27
van egy tippem, kimentette az emulátorral a 100h-a program végéig, és készült elé egy fejléc :)

Valóban :oops: De kiegészíthettem volna melegindítási cím beállításával, ami a BASIC-hez vagy az EP logóhoz térne vissza; át is írom, és a szegmenseket is rendesen le kellene foglalni.
A memóriát a 100H-7FFFH területről mentettem ki; ebből a hasznos rész valójában csak az 1000H-2127H és 6000H-7FFFH, de ezt a nem túl elegáns megoldást a tömörítés elrejtette :) :oops:
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 23:41:26

Az van a kek szinnel ( persze hogy en is azt szerettem volna ), hogy ep- n abbol osszesen csak 3 arnyalat van, mig pirosbol es zoldbol 7 arnyalat. szal ha kek, akkor kevesebb mint fele annyi szinarnyalat... de kiprobaltam zolddel es sargaval ( piros + zold = sarga ) es erdekes modon az emuban eleg ronda a zold is es a sarga is ...

mintha csak a pirosat hozna szepen az emu ...

aztan lehet h az eredeti EP- nek is ilyen ronda zold es sarga szinei voltak, de nem tom kiprobalni, mert sajna nem tok betolteni vas EP- be...

hat abbahagyni nem akarom, de ( oke- oke fel kellett mindent eleveniteni, de) azert csak majd egy hete irtam mar ezt, es ezzel is szerencsesnek mondhatom magam, hogy megtehettem, de a jovoben azert nem foallasban fogok EP- zni, csak ugy neha- neha, holnaptol visszaterek a regi kerekvagasba, melozok ezerrel, es neha egy kicsit EP fejlesztgetek, de kikerekitem ezt valami kerekebb dologga, es latok neki amajd a kovetkezo effektnek is, de itt nem napokrol, meg csak nem is hetekrol beszelunk ...



Title: Re: Assembly programozás
Post by: Z80System on 2009.September.11. 23:47:38

Es ugy siman visszaterni a basic- be, vagy ahonnan elinditottuk a programot, ugyanugy mint asmonba, nem lehet, IstvanV ?

Ugye egy ret hatasara az asmon csilingel egyet, es visszater siman, es folytathatod vele a munkat, ha figyeltel hogy milyen szegmensekre pakoltal a programodban, akkor az asmon sertetlen marad visszateres utan.

Ezt nem lehet megcsinalni barmivel, csak asmonnal ? ( mer akko nekem asmon a baratom )





Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.12. 00:13:20
Ez már egy remélhetőleg jobb változat:
  [attachurl=#]
A memóriát rendesen lefoglalja, resetre kilép a BASIC-be (ha van ilyen, egyébként az Enterprise logóhoz), és nincs tömörítve.
Forráskód:
  [attachurl=#]
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.12. 00:19:04

esc megnyomasos ( ret - tel visszateres ) kerdes tovabbra is fennall: olyat csak asmonban lehet ?

Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.12. 00:24:08
Es ugy siman visszaterni a basic- be, vagy ahonnan elinditottuk a programot, ugyanugy mint asmonba, nem lehet, IstvanV ?

Ugye egy ret hatasara az asmon csilingel egyet, es visszater siman, es folytathatod vele a munkat, ha figyeltel hogy milyen szegmensekre pakoltal a programodban, akkor az asmon sertetlen marad visszateres utan.

Ezt nem lehet megcsinalni barmivel, csak asmonnal ? ( mer akko nekem asmon a baratom )

EXOS 5 (.com) típusú programból nem lehet "visszatérni", de az egyszerűen megoldható, hogy a program pl. BASIC-be kilépjen:

Code: ZiLOG Z80 Assembler
  1. warmreset:
  2.         ld      sp, 0100h
  3.         ld      a, 0ffh
  4.         out     (0b2h), a
  5.         ld      c, 60h
  6.         exos    0
  7.         ld      de, basiccmd
  8.         exos    26
  9.         ld      a, 01h
  10.         out     (0b3h), a
  11.         ld      a, 6
  12.         jp      0c00dh
  13.  
  14. basiccmd:
  15.         defb    5
  16.         defm    "BASIC"

Itt természetesen a "BASIC" helyett más parancs, pl. EXDOS, ASMON, stb. is használható. Érdemes megfigyelni az exos 26 utáni részt, amely az Enterprise logo képernyőhöz lép ki, ha előtte a BASIC hívás nem volt sikeres.

A fenti rutin automatikusan lefut a reset gombra ezzel a kóddal:

Code: ZiLOG Z80 Assembler
  1.         ld      a, 0ffh
  2.         out     (0b2h), a
  3.         ld      hl, warmreset
  4.         ld      (0bff8h), hl

Esc billentyűre csak akkor, ha azt a program figyeli, és a billentyű lenyomásakor ráugrik. :)
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.12. 00:33:57

aham... valami ilyesmi remlett... es ennek szerinted mi lehet az oka... hogy nem csinaltak ilyen "low level call -t" szamitva arra, hogy a hivott program majd baratsagosan hasznalja a dolgokat, es ret- tel vissza akar terni... az asmon- ban ugye van ilyen... a "g" parancs. namost lenne az exosnak egy ilyen funkcioja, hogy exos 666, ami raugrana call- lal a de- be rakott cimre ... es kesz. es akkor ez a funkcio, akar egy fejlecet is kaphatott volna ( 666 fejlec ), es akkor betoltene a progit es raugrana ugyanugy mintha 5- os lenne, de "varna vissza" a vezerlest... es a basic (ha abbol hivtad) onnan folytatodna ahonnal meghivta a programot ... vagy ha exdos- bol is hasznalnak, akkor az exdos folytatodna... asmonban is mukodne ez is, nem csak a "g"... stb ...

me nincs ilyen ? :)

mint a dos- os progik... azok is visszatertek... a hivashoz ...


Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.12. 00:37:17
aham... valami ilyesmi remlett... es ennek szerinted mi lehet az oka... hogy nem csinaltak ilyen "low level call -t" szamitva arra, hogy a hivott program majd baratsagosan hasznalja a dolgokat, es ret- tel vissza akar terni... az asmon- ban ugye van ilyen... a "g" parancs. namost lenne az exosnak egy ilyen funkcioja, hogy exos 666, ami raugrana call- lal a de- be rakott cimre ... es kesz. es akkor ez a funkcio, akar egy fejlecet is kaphatott volna ( 666 fejlec ), es akkor betoltene a progit es raugrana ugyanugy mintha 5- os lenne, de "varna vissza" a vezerlest... es a basic (ha abbol hivtad) onnan folytatodna ahonnal meghivta a programot ... vagy ha exdos- bol is hasznalnak, akkor az exdos folytatodna... asmonban is mukodne ez is, nem csak a "g"... stb ...

me nincs ilyen ? :)

mint a dos- os progik... azok is visszatertek... a hivashoz ...

Tulajdonképpen meg lehet oldani azt is, hogy a program visszatérjen, de akkor nem 5-ös fejlécű programot, hanem pl. 6-os fejlécű rendszerbővítőt kell írni, ami valamivel bonyolultabb. Így lehet például új EXOS parancsokat is létrehozni.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.12. 00:40:47
tehat akkor azt lazan meg lehet csinalni, hogy vmi elindul ilyen rendszerbovitokent, es akkor lefut, tezsi a dolgat es esc- re meg kiterminalja magat mint rendszerbovitot, es ha mondjuk ez basic- bol lett hivva,  es mindenre vigyaztunk, akkor sertetlen basic jon vissza, programmal, mindennel ?

Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.12. 00:45:18
tehat akkor azt lazan meg lehet csinalni, hogy vmi elindul ilyen rendszerbovitokent, es akkor lefut, tezsi a dolgat es esc- re meg kiterminalja magat mint rendszerbovitot, es ha mondjuk ez basic- bol lett hivva,  es mindenre vigyaztunk, akkor sertetlen basic jon vissza, programmal, mindennel ?

Vissza lehet térni RET utasítással, de a bővítő a memóriában marad (és később újra meg lehet hívni pl. EXOS paranccsal). Törölni és a memóriát felszabadítani csak a ZozoTools :RL parancsával lehet.
Title: Re: Assembly programozás
Post by: Z80System on 2009.September.12. 00:49:57
hat az ugy megint nem tetszik... azert nyomott esc- t mert ki akar lepni... nem akarja rezidens progikent ... de hat van ep- re cp/m, meg ilyesmi... abba tuti nem igy van... az exos fejlesztoi nem ismertek azt a szitut, hogy betolt/futtat/kilep ???

hat hiaba, en ezeket ma sosem fogom megerteni...


Title: Re: Assembly programozás
Post by: Z80System on 2009.September.12. 00:53:36
egyebkent az SDCC az nem egy assembler, hanem C fordito, igy lehet C- ben tolni EP- re... csak iszonyat nagy kodokat general... de mindegy a nagyon unalmas inicializalo reszeket akkor is abba irom, megha 1 szegmens ra is megy az inicializalasi kodokra ... es float- okat hasznalni vegkepp nem szabad, muveletenkent dobja a kilobytokat ra ... :) :) nem is ertem, nincs ebbe az SDCC -be call, vagy mi ???


Title: Re: Assembly programozás
Post by: geco on 2009.September.12. 08:43:26
hat az ugy megint nem tetszik... azert nyomott esc- t mert ki akar lepni... nem akarja rezidens progikent ... de hat van ep- re cp/m, meg ilyesmi... abba tuti nem igy van... az exos fejlesztoi nem ismertek azt a szitut, hogy betolt/futtat/kilep ???

hat hiaba, en ezeket ma sosem fogom megerteni...
Van egy másik megoldás, Basicben is meg lehet írni egy gépi kódú betöltőt, ami betölt egy fejléc nélküli file-t a megadott címre, majd betöltés után meghívni, ha ott térsz vissza RET-tel, akkor simán visszatér  a Basic progidhoz
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.September.12. 09:09:57
Van egy másik megoldás, Basicben is meg lehet írni egy gépi kódú betöltõt, ami betölt egy fejléc nélküli file-t a megadott címre, majd betöltés után meghívni, ha ott térsz vissza RET-tel, akkor simán visszatér  a Basic progidhoz
Ezzel viszont az a gond, hogy akkor csak BASIC-bõl fog mûködni a program, ill. elõfordulhat, hogy bizonyos gép verziókkal fog mûködni. (Sok gyári programmal is ez okozta az angol/német gép problémát!)
Lehetséges még a 2-es fejlécû felhasználói áthelyezhetõ modul, de olyat ember nem írt még a pár gyári programon kívül :-) és ezzel szintén a BASIC-hez láncoljuk magunkat.
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.September.12. 09:30:51
az exos fejlesztoi nem ismertek azt a szitut, hogy betolt/futtat/kilep ???
Akkoriban a számítástechnika aktuális fejlettségi szintje ez volt: betölt, futtat, kikapcsol.
Még reset sincsen a Spectrumon, C64-en és még egy csomó más gépen se. C64-en legalább kikapcsoló volt :-)
Ehhez képest az EP a maga reset gombjával már király :-) különösen, hogy kétféle reset módot ismer, amihez hasonlót én még nem láttam más gépen (kivéve a TVC, de az igen közeli rokon :-) ), még a PC se tudja!
És az EXOS már lehetõséget adott arra, hogy kilépéskor vagy reset gomb megnyomásakor visszatérj pl a BASIC-hez, úgy hogy közben megmaradtak a betöltött bõvítõk, ramdisk, változó beállítások, stb. (gyakorlati használatát bemutatta István)
Kár, hogy az EP-re készült programok 99% nem használta ki ezeket a lehetõségeket, és csak hideg indítással lehetett kilépni belõlük. Ezért is készült az EXOS 2.3 ami jobban ragaszkodik az életéhez, és ha lehet, akkor hidegindítás helyett a bejelentkezõ képhez ugrik.
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.September.12. 11:57:20
Ez már egy remélhetõleg jobb változat:
A JP 1000H helyére kell CALL, és akkor ESC-re rámegy a kilépésre.
Title: Re: Assembly programozás
Post by: Zozosoft on 2009.September.12. 11:58:35
Nekem ez nagyon tetszik, abba ne hagyd!!!  ;-)
Egyetértek, nagyon jó!!!
Title: Re: Assembly programozás
Post by: geco on 2009.September.12. 13:11:47
Akkoriban a számítástechnika aktuális fejlettségi szintje ez volt: betölt, futtat, kikapcsol.
Még reset sincsen a Spectrumon, C64-en és még egy csomó más gépen se. C64-en legalább kikapcsoló volt :-)
Kár, hogy az EP-re készült programok 99% nem használta ki ezeket a lehetõségeket, és csak hideg indítással lehetett kilépni belõlük. Ezért is készült az EXOS 2.3 ami jobban ragaszkodik az életéhez, és ha lehet, akkor hidegindítás helyett a bejelentkezõ képhez ugrik.
Kapott is szegény kikapcsológombom a C64-esen rendesen :D, csoda, hogy nem az adta meg magát, hanem a táp. :D
De hála neked, az új programok/átiratok már EXOS kompatibilisek. ;)
Title: Re: Assembly programozás
Post by: IstvanV on 2009.September.13. 17:34:53
Ezzel viszont az a gond, hogy akkor csak BASIC-bõl fog mûködni a program, ill. elõfordulhat, hogy bizonyos gép verziókkal fog mûködni. (Sok gyári programmal is ez okozta az angol/német gép problémát!)
Lehetséges még a 2-es fejlécû felhasználói áthelyezhetõ modul, de olyat ember nem írt még a pár gyári programon kívül :-) és ezzel szintén a BASIC-hez láncoljuk magunkat.

Esetleg még olyan bővítőt lehetne írni, amely betölt egy megadott nevű file-t a memóriába, és futtatja (melegindítás nélkül) :)

A JP 1000H helyére kell CALL, és akkor ESC-re rámegy a kilépésre.

Javított változat:
  [attachurl=#]
  [attachurl=#]
Title: Re: Assembly programozás
Post by: endi on 2010.May.02. 13:43:01
Volt már szó itt a fórumon arról, hogy bizonyos gépeken az IM2 megszakítás címének vétele hibás eredményt ad, mert az alsó byte-ban valami "zaj" van. (Ilyen volt az én gépem is, nem is futottak az im2-t használó játékok.)
Na most tudna valaki olyat csinálni hogy kiiratja egy file-ba vagy tga/bmp képre ezt a zajt? Tök kíváncsi lennék hogy néz ki. :)
Lehet hogy ezek az EP-k valódi véletlenszám generátorral rendelkeztek. :o)
Title: Re: Assembly programozás
Post by: Attus on 2010.May.02. 20:54:28
Volt már szó itt a fórumon arról, hogy bizonyos gépeken az IM2 megszakítás címének vétele hibás eredményt ad, mert az alsó byte-ban valami "zaj" van. (Ilyen volt az én gépem is, nem is futottak az im2-t használó játékok.)
Az én gépem is ilyen volt, a BAM és janó féle átratokból elég sok nem is futott emiatt a gépemen.
Mondjuk nem ért túl nagy veszteség velük. :mrgreen:
Ezért is csináltam teljes 256 bájtos im2 táblát mindig. A profik által csinált spectrum programok is teljes tabellát csináltak, nem véletlenül.
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.May.02. 21:22:22
Ezért is csináltam teljes 256 bájtos im2 táblát mindig. A profik által csinált spectrum programok is teljes tabellát csináltak, nem véletlenül.
Vagy vissza kell rakni IM1-re, es megsporoljuk a tablat :-)
Title: Re: Assembly programozás
Post by: Attus on 2010.May.02. 21:37:49
Vagy vissza kell rakni IM1-re, es megsporoljuk a tablat :-)
:smt045
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.June.12. 11:11:21
Ez megválaszolta a következõnek szánt kérdésemet: mitõl lassul be brutálisan az LDIR, ha az utasítás kódja a videó memóriába kerül. Naivan eddig azt hittem, csak egyszer olvassa be a Z80  :oops: és így akkor megúszhatóak a várakozások.
De így akkor egyértelmûen az jön ki, hogy minden esetben gyorsabb a kiírt LDI LDI LDI... sorozat, mint az LDIR. Persze bizonyos mennyiség felett elég memória pazarló ez a módszer :-)
És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:
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.                 EXX                  
  36.                 PUSH IY              
  37.                 PUSH IX              
  38.                 PUSH HL              
  39.                 PUSH DE              
  40.                 PUSH BC              
  41.                 LD HL,40              
  42.                 ADD HL,SP            
  43.                 LD (SPCEL2+1),HL      
  44.  
  45. SPKEZD2:        LD SP,4000H
  46.                 POP BC
  47.                 POP DE
  48.                 POP HL
  49.                 POP IX
  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.                 PUSH DE
  64.                 PUSH BC
  65.                 EXX
  66.                 PUSH IY
  67.                 PUSH IX
  68.                 PUSH HL
  69.                 PUSH DE
  70.                 PUSH BC
  71.                 LD HL,80
  72.                 ADD HL,SP
  73.                 LD (SPCEL+1),HL
  74.                 LD HL,(SPKEZD2+1)
  75.                 LD BC,80-20
  76.                 ADD HL,BC
  77. SPCOUNT:        LD A,200
  78.                 DEC A
  79.                 LD (SPCOUNT+1),A
  80.                 JR NZ,SPKEZD
  81. SPSAVE:         LD SP,0
  82.                 RET

Ö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?
Title: Re: Assembly programozás
Post by: IstvanV on 2010.June.12. 11:24:57
És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:

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. Igaz, így bonyolultabb a pixel adatok címzése, és ez a megoldás nem kompatibilis az EXOS videokezelőjével (ha annak a képernyőjét próbálod scrollozni).
Title: Re: Assembly programozás
Post by: IstvanV on 2010.June.12. 11:28:29
És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:

Ilyen megoldást használtak egyébként az ATF-ben is :)
Title: Re: Assembly programozás
Post by: Zozosoft 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 :-)
Title: Re: Assembly programozás
Post by: IstvanV 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.
Title: Re: Assembly programozás
Post by: Zozosoft 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?
Title: Re: Assembly programozás
Post by: Zozosoft 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: )?
Title: Re: Assembly programozás
Post by: IstvanV 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 (http://z80.info/zip/z80cpu_um.pdf) dokumentációban ez olvasható:

[attachthumb=#]

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
Title: Re: Assembly programozás
Post by: Ferro73 on 2010.June.20. 21:42:06
A Z80 (http://z80.info/zip/z80cpu_um.pdf) 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)
Title: Re: Assembly programozás
Post by: IstvanV 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.
Title: Re: Assembly programozás
Post by: Ferro73 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.
Title: Re: Assembly programozás
Post by: IstvanV 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 (http://enterpriseforever.com/emulatorok/lua_scriptek_fejlesztese-t511.0.html;msg19639#msg19639) 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.
Title: Re: Assembly programozás
Post by: Ferro73 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.
Title: Re: Assembly programozás
Post by: endi 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
Title: Re: Assembly programozás
Post by: nt75sw 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.
Title: Re: Assembly programozás
Post by: Lacika on 2010.September.28. 19:43:52
Itt (http://ep128.hu/Ep_Util/Ep_Util.htm) van ASMON 1.3, HEASS, FENAS. Nem csak ROM.
Title: Re: Assembly programozás
Post by: Zozosoft 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 :-)
Title: Re: Assembly programozás
Post by: nt75sw 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...
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.September.29. 15:57:35
Értem amit írsz, de eprom égetõm az bizony nincs
Hozol EPROM-ot és beégetem!
Title: Re: Assembly programozás
Post by: nt75sw on 2010.September.30. 15:08:42
Hozol EPROM-ot és beégetem!

Azt hiszem azt anno gyűjtöttem a géphez. Bár ha jól emlékszem, nem IC foglalatban
van a cartridge-ben a rom, megnézem este.
Aztán majd jelentkezem. Köszi előre is.
Majd írd meg légyszi mennyiért vállalod, lehet PM is.

/OFF
Ui.: Bocs hogy újságírónak gondoltalak először, bár cikkeket tényleg írtál,
de ettől jóval többet is tettél. Azért olvasok ám közben :)
/ON

Egyéb. Srácok, én nem bírok ezzel a FENAS programmal :)

Feladat: Turbo Rudi-ban a 3 életet átírni 5-re. (Tudom van TRN, de most nem ez a lényeg :) )
Probléma: Vagy én csinálok valamit rosszul, ami tuti, vagy baja van a proginak...

HA jól tippelem (de lehet hogy ez rossz PC-s berögződés) a Read Bin File olvassa be nekem a fájlt.
Start 4000, Stop 4000 (szerintem ide nem ennyi kell, de ennyit ír ki, gondolom Ő tudja jobban...)
Aztán start, rudi.com betöltése megtörténik, de utánna semmit nem csinál.

Szóval valaki ezt a részét leírhatná nekem :) Jó lenne már túrkálni benne,
de hogy pont a progival nem bírok, ez csúcs.

Köszi előre is...
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.September.30. 15:30:39
szerintem ide nem ennyi kell, de ennyit ír ki, gondolom Õ tudja jobban...
Rosszul gondolod :-) írj be FFFF-t, és akkor jó lesz, a tényleges végét kiírja a töltés végén, az majd kelleni fog a mentésnél.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.September.30. 16:32:08
Rosszul gondolod :-) írj be FFFF-t, és akkor jó lesz, a tényleges végét kiírja a töltés végén, az majd kelleni fog a mentésnél.

Ezzel csak az a baj, ha END nem ugyanaz mint a START (4000) akkor meghal.
Kb egy órája tölt elvileg. De nem reagál semmire.
Na de pontosabban:

ep128emu 2.0.8.1 (EP_128k_Tape_FileIO.cfg) + FENAS.EXT

"R" Read bin file
START: 4000
END: FFFF
NAME: (ENTER) Ablak nyílik, megadom a fájlt, Rudi.com...
NAME: Innentől itt üres, reakció semmi, és szerintem fagyi...
Nem hiszem hogy egy óra alatt nem bírja betölteni :)

Valamit bénázok...
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.September.30. 16:42:08
FENAS.EXT
Ezt már programként töltötted be?
Title: Re: Assembly programozás
Post by: nt75sw on 2010.September.30. 17:17:59
Ezt már programként töltötted be?

remélem minioperával is megy a válasz...
 
nem igazán értem a kérdést...
ha arra gondolsz... I/O módban közvetlen az ext fájl igen, és nem tap vagy wav...
 
megjegyzés: eredeti gépen is furcsa ez a program. wav fájlt csináltam ebből az ext-ből. betölt ugyan, de a vége lemarad. ott már csak egy sima sípjel van, azt nem tölti már be. de a program az fut végülis. vagy nem lesz jó ez a 320k mp3 módszer...
Title: Re: Assembly programozás
Post by: nt75sw on 2010.September.30. 18:01:28
esetleg nincs meg ez a verzió, vagy újabb, com verzióban? mert gondolom ezt átirni problémás lenne. :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.September.30. 18:15:22
I/O módban közvetlen az ext fájl igen
Ott a probléma, hogy a FENAS nem foglal szabályosan memóriát. Csak úgy puff bele módon rakja be az FA,FB,FC szegmenseket a memóriába. Ha 128-as gépen betölthetõ verziót használsz, akkor az a F9,FA-ra töltõdik be, vagyis amikor elkezdesz 4000-tõl tölteni felülírod a FENAS felét.

Emulátorban használhatod a ROM verziót, és akkor nincs ilyen gond (ott plusz RAM-ot is csak pár kattintás a gépbe rakni :-)
128-as gépen EXT verzióval meg 8000-FFFF területen lehet garázdálkodni.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.September.30. 19:18:24
és valóban, 8000-től rendben működik emuban. remélem rendes gépen is menni fog este, mert elég válogatós a lelkem :)
 
köszönöm a gyors segítséget, ritka jó ez a fórum. esetleg valakinek megvan ez nem ext verzióban hanem com?
 
köszi előre is :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.September.30. 22:37:04
valakinek megvan ez nem ext verzióban hanem com?
Az 1.0-ás verzió volt még COM-os.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.October.03. 19:31:37
üdv mindenki. bár nemigen ebbe a topicba tartozik, de nem is tudom...
 
mivel a programokat telefonról játszom le a gépemnek, felvenni nem tudok vele. jött a ramdisk ötlete. amit meg is találtam az ep128.hu programcsokorban. ez jó is lenne, tudok rátölteni, és szerintem szerkeszteni is lehetne, ha maradna elég memória. a ramdisk.ext ugyanis 64K méretű lemezt hoz létre. szóval a kérdésem, valaki át tudná ezt irni úgy, hogy csak 16K méretű lemezt hozzon létre? vagy esetleg ellátna tippekkel?
 
a létrehozott lemez mérete egész pontosan F000H. elvileg elég lenne egy 3C00H. ezt az F000H értéket már néztem, de nyilván nem egyben köti le, szerintem 16K szeletekben foglalja le. szóval ha valakinek van ilyen, az is jó, ha megnézné valaki az is jó, ha tippeket kapok az is jó :)
Title: Re: Assembly programozás
Post by: Lacika on 2010.October.03. 19:54:53
mivel a programokat telefonról játszom le a gépemnek, felvenni nem tudok vele. jött a ramdisk ötlete. amit meg is találtam az ep128.hu programcsokorban.

Ha jól sejtem, te Alexander Gusev Ramdisk 0.1 programjára gondolsz.
Ennek semmi köze sincs az EXDOS-hoz. A RAMDISK méretét úgy állítja be, hogy mindig 64K szabad memóriát hagy (akkor is, ha memóriabővítést is emulálunk. Az EXDOS ramdisk funkciója lemez nélkül is szintén használható.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.October.03. 20:47:00
Ha jól sejtem, te Alexander Gusev Ramdisk 0.1 programjára gondolsz.
Ennek semmi köze sincs az EXDOS-hoz. A RAMDISK méretét úgy állítja be, hogy mindig 64K szabad memóriát hagy (akkor is, ha memóriabővítést is emulálunk. Az EXDOS ramdisk funkciója lemez nélkül is szintén használható.

így van, erre gondolok! tudom hogy fix 64K méretet köt le. ezen kellene változtatni.  bár találtam benne két dolgot ami nem tudom mire lehet jó. DEF és talán SP vagy PS parancs, nem ugrik be, majd megnézem.
 
nincs ex-dos nekem, csak gyári alapkonf szegény :)
Title: Re: Assembly programozás
Post by: nt75sw on 2010.November.30. 13:08:15
Üdv újra!

Az elmúlt pár héten erõsen tanulom az asm szépségeit, elméleti szinten :)
Nos hát, most már szoftver keresése...

Kérdésem, ki mit használ eredeti gépen, és PC-n (nem emu, hanem win vagy linux alatt)

Találtam egy érdekes hsz-t: IstvanV (http://enterpriseforever.com/other_topics/hi_from_france-t513.0.html;msg17140#msg17140)

Én a Fenas-t preferálnám, de nincs makro, bár késõbbi terveim fõleg csak átírás lenne EP-re,
ott nemigen lesz rá szükségem...
Asmon-t csak párszor néztem, úgy emlékszem gyakran kifagyott nálam.
Heass, na passz...

IstvanV írt valami PC-s assemblerrõl. Néztem a z80.info-t, fogalmam nincs melyik lenne jó...
Linux alatt meg fõleg nem tudom, létezik-e ilyen ami jó ebben a helyzetben.

Ebben a ep128emu2-ben lesz a jövõben vajon assembler?
Mert az lenne a nagy durr szerintem, minden egyben megacsomag :)

Na szóval a kérdés adott, tanuláshoz, késõbb átíráshoz mi a javaslat, EP-re, Win-Linuxra...

Köszi szépen :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.November.30. 13:31:52
Én a HEASS-t használom, PC-n is ep128emu-val :-)
Debuggolásra meg az ep128emu debuggere a legjobb, úgy általában az egész Z80 vonalon!  :smt038
Nem véletlenül kunyeráltuk, hogy legyen Spectrum emulátor is ilyen, már csak egy ugyanilyen TVC emu kéne (ott egyáltalán nincs debugger az emuban :-( )
Title: Re: Assembly programozás
Post by: IstvanV on 2010.November.30. 13:32:01
Kérdésem, ki mit használ eredeti gépen

EP-n a legjobb assembler a HEASS (http://www.ep128.hu/Ep_Util/HEASS.htm).

Quote
IstvanV írt valami PC-s assemblerrõl. Néztem a z80.info-t, fogalmam nincs melyik lenne jó...
Linux alatt meg fõleg nem tudom, létezik-e ilyen ami jó ebben a helyzetben.

Én az SjASM 0.39g6 verziót használom, ezzel fordítható az összes Z80 forráskód, amit kiadtam (kivéve néhány régi file-t). Biztosan van jobb is, de ezt mindenesetre használhatónak találtam. Megtalálható itt a fórumon is a letöltések (http://enterpriseforever.com/letoeltesek_downloads/pc_utils-t358.0.html) között az EPvideoconv és az "EP utilities for Linux" csomagokban (az előbbiben Windowsra és Linuxra fordítva, az utóbbiban csak Linux verzió van), leírással (sjasm.txt) és forráskóddal együtt. A Linux verziót statikusra fordítottam, így elvileg minden disztribúción működik. Javítottam egy hibát is, ami Linuxon lefagyást okozott a MODULE..ENDMOD direktívák használatakor.
Az eredeti változat itt (http://home.wanadoo.nl/smastijn/sjasm.html) található, és van egy újabb 0.42beta8 verzió is, amely azonban nem teljesen kompatibilis a 0.39-el. Létezik még egy továbbfejlesztett és fejlesztés alatt álló SjASMPlus (http://sjasmplus.sourceforge.net/) assembler is.
A használata egyszerű: parancssorban futtatható, és a fordítandó forrás file (ami egyszerű szöveges (.txt) formátumú file, az EP-s assemblerekkel ellentétben) nevét kell paraméterként megadni, illetve (opcionálisan) a kimeneti file-t. Ha ez nincs, és a forrásban nem található OUTPUT direktíva, akkor a kimeneti file neve a bemeneti file neve lesz a kiterjesztést ".out"-ra változtatva. A fordításkor létrehoz egy .lst kiterjesztésű lista file-t is, ami debuggoláshoz hasznos lehet.

Quote
Ebben a ep128emu2-ben lesz a jövõben vajon assembler?

Egyszerű assembler már most is van, amellyel közvetlenül a memóriába lehet utasításokat fordítani. Komolyabb funkciókat (címkék, makrók, stb.) nem tud, de nem is ez volt a célja.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.November.30. 14:16:35
Értem. De a Heass ha jól tudom, csak asm forráskódot tud betölteni (nincs "Read BIN File"), lefordított programot (*.com; *.ext) azt nem. Legalábbis én anno nem tudtam betölteni...

Pedig ez fontos lehet :)
Ha mégis tud akkor bocs, akkor kinyomozom miképp tud.
Ha nem, akkor melyik program a következõ javaslat a sorban?

Ui.: Közben nézem ezt a Heass-t, meglepõen gyors program, tetszik... De tényleg nem látom hogy lehetne bin-t etetni vele.
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.November.30. 14:58:07
De tényleg nem látom hogy lehetne bin-t etetni vele.
És miért akarsz bin-t etetni vele? A Konvertálás/Adatfájl betöltése nem jó?
Title: Re: Assembly programozás
Post by: nt75sw on 2010.November.30. 16:09:04
Nekem az a menüpont nem reagál semmire, sem emuban, sem EP-on...
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.November.30. 16:21:51
Nekem az a menüpont nem reagál semmire, sem emuban, sem EP-on...
Van megnyitott (vagy létrehozott) forrásfájlod a memóriában?
Title: Re: Assembly programozás
Post by: Ferro73 on 2010.November.30. 18:03:16
Én is probáltam a HEASS-t de nekemse sikerült .asm .txt fájlt csak a speciális .H?? engedte volna
jó lehet mert akár 64K assemblert is lelehet forditani ha van elég memoria.
Nekem az ASMEN jön be zxjátékot betöltöm keresek benn testelem a rutinokat editben megirom a változtatásokat EP re igy csak a változtatások kerülnek .asm a többi kod eredeti ZX.
vannak hátrányai az editor ugyan azt a memoriát használja mint ahová tölteném a játkot és a b3 szegmenst semhasználhatom keresztezni kellene a Dtest progival annak csak a kezelése körülményes.
Ezért én maradok az ASMEN-nél
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.December.01. 00:45:21
Én is probáltam a HEASS-t de nekemse sikerült .asm .txt fájlt csak a speciális .H?? engedte volna
Betöltésnél csak HEA. Minden egyebet Konvertálásnál, de ahhoz kell az, hogy legyen megnyitva a szerkesztõben egy HEASS dokumentum.
Title: Re: Assembly programozás
Post by: nt75sw on 2010.December.01. 10:26:11
Betöltésnél csak HEA. Minden egyebet Konvertálásnál, de ahhoz kell az, hogy legyen megnyitva a szerkesztõben egy HEASS dokumentum.

Azzal meg az a baj, hogy elfagy... Illetve nem, csak ezek a csillagok villognak már 37 perce.
Namármost ha speed 400%-on ennyi idõ alatt nem tölti be...
(Emu-ban. Gépen még nem néztem, kínozza a gyerkõc.)

Title: Re: Assembly programozás
Post by: Zozosoft on 2010.December.01. 10:28:44
Hány 100 megás fájlt raktál be neki? :-)
Title: Re: Assembly programozás
Post by: nt75sw on 2010.December.01. 10:32:58
Turbo Rudi (rudi.com 11K), de már rájöttem mi volt a baja...
Lassítva már kiírta hogy nincs szabad szegmens...
Asmon 1.3 (rom verzió) ramból ki, már megy.... Bocs :)

Alakul...
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.December.01. 10:37:36
Alakul...
Helyes :-)

Közben kipróbáltam, egy 32K-s fájlt, valódi floppyról, nem gyorsítva az emulátort 1:45 alatt rakott be.
Title: Re: Assembly programozás
Post by: Zozosoft on 2010.December.01. 10:38:39
És ott a konvertálásban az ASM betöltéssel lehet ASMON és FENAS formátumú forrás fájlt betölteni.
Title: Re: Assembly programozás
Post by: IstvanV on 2010.December.01. 11:21:55
De a Heass ha jól tudom, csak asm forráskódot tud betölteni (nincs "Read BIN File"), lefordított programot (*.com; *.ext) azt nem.

Ha jól értem, valójában monitor funkció kellene, mint az ASMON-ban, és nem a .com vagy .ext file DB-kre konvertálása és forráskódba való beépítése :?:
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.04. 11:05:40
Nem a státusz sor palettaszínei miatt? (az a színpár, ami a kijelzõre van definiálva fekete)

Jó nyomon jársz!
Tehát a megfejtések:
Quote
- miért nem mûködik az áthelyezett status sorban a kijelzõ?
Azért mert a magnókezelõ közvetlenül az EXOS LPT elsõ sorába, azaz az eredeti status sor paletta színet piszkálva éri el a villogást. A saját LPT-nkben mutathat tetszõleges helyen a status sor videó memóriájára, a felíratok (SEARCHING, LOADING, stb) mûködni is fog, a töltésjelzõ téglalap is megjelenik, azonban nem fog villogni, mivel a magnó kezelõ nem a mi LPT-nkben, hanem az eredeti helyén váltogatja a színeket.
Ezt tapasztalhatjuk nagyon sok programban.

Quote
- hogyan lehet megoldani, hogy mûködjön?
Úgy, hogy az LPT táblánkat az EXOS LPT helyére tesszük, az eredeti status sort leíró blokkot megtartva, és beépítve a miénkbe.
Erre jöhet a kérdés, hogy akkor hogyan fog más helyre kerülni a képernyõn?
Nagyon egyszerûen: ki kell használni Nicknek azt a tulajdonságát, hogy az LPT táblának a vége nem kell, hogy egyben a kép vége is legyen. Magyarán lehet a kép közepén is az LPT vége, így akkor az LPT elején lévõ status sor a kép közepére kerül.
Egyetlen probléma, hogy az LPT táblának el kell férnie az EXOS LPT helyén, ezér csak "igazi EP-s" programokban lehet egyszerûen megoldani, Spectrum átiratoknál nem.
Viszont eszembe jutott, hogy hogyan lehet Spectrum átírat esetén is megoldani: a betöltõképet át kell konvertálni sorfolytonosra, ekkor már egy egyszerûsített LPT elfér az EXOS LPT helyén. Majd a betöltés végeztével kell átváltani a rendes Spectrum LPT-re.
Igény esetén megvalósíthatom pár korábbi átiratban :-)

Quote
- melyik programban mûködik?
Z&A Demo
Az ep128.hun igen szûkszavú a leírása, más apróbb trükkök se lettek észrevéve :-(
Title: Re: Assembly programozás
Post by: Lacika on 2011.October.04. 13:24:03
Z&A Demo
Az ep128.hun igen szûkszavú a leírása, más apróbb trükkök se lettek észrevéve :-(

De ha leírod, mit kellene észrevenni egy laikusnak, szívesen kirakom!  :oops:
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.04. 15:53:26
De ha leírod, mit kellene észrevenni egy laikusnak, szívesen kirakom!  :oops:

Elõször is hiányzik az évszám, az utolsó fordítás pontos ideje 1991.08.21 1:11, amúgy aznap lettem 16 éves :-) (Atyaég, ez már több mint 20 éve volt!  :shock: )
Besorolásra pontosabb lenne a "poénkodás, és némi grafika" :-)

Ez volt az éltem elsõ gépi kódú próbálkozása, mintegy 2 évi EP-zés után. Ekkor már két gépünk volt, hálózatba kötve, így úgy ment a fejlesztés, hogy az egyik gépen futott az ASMON, és a NET-re lett lefordítva, ill. a másik gépen betöltve a kipróbálandó program. Az adatfájlokat a saját magnójáról töltötte utána. A fejlesztés közben tettünk szert EXDOS kártyára ennek (mag annak, hogy beállítottam a TIME/DATE-t :-) ) köszönhetõ, hogy meg van a pontos idõpont.
Megjelenítónk ekkor még csak Junoszty tv volt, Kurczu (http://enterpriseforever.com/profiles/kurczu-u202.html)-nak volt színes tévéje, így suli után nála keresgéltem színkódokat a rasztercsíkokhoz.

A program egybõl egy kis poénkodással indul, a névsorból a titokzatos Dr. Préry a padtársam volt 4 éven keresztül, neki Atari ST-je volt ebben az idõben, közremûködött pl a Interlace Demo (http://ep128.hu/Ep_Demo/Leiras/Interlace_Demo.htm) képeinek elõállításában, valamint õ rajzolta a Zozolace (http://ep128.hu/Ep_Demo/Leiras/Zozolace.html) Garfield-os képeit.

A kezdõképernyõ után jön az adatfájlok betöltése, a korábban már kitárgyalt módon a képernyõ közepére áthelyezett, de mégis mûködõ status sorral. (Egyébként ez az LPT-s trükk lett késöbb a ZT órájának a status sor fölé való helyezésére felhasználva.)
Az adatfájlok tömörítve lettek az egyszerû bájtismétlõdéseket kiszûrõ módszerrel, itt még a betömörítés egy külön BASIC programmal történt. Késõbb ez lett tovább fejlesztve a tömörített VS/VL-hez. (Még késõbb meg az egész évfolyamon egyedül *5-ös programozás érettségit írtam, amikor Pascal-ban tömörítõ programot kellett írni. Mindenki más rosszul volt, hogyan lehet ilyen bonyolult feladatot adni  :ds_icon_cheesygrin: )
Visszatérve a demo-hoz, az adatfájlok direkt maradtak sok külön fájlban, hogy jól látszódjon a status sor mûködõ volta.
Betöltés közben is van poénkodás, konfigurációtól függõen, a magnósokat egy lemezes üzenet lepi meg (helyezzünk lemezt az E: meghajtóba :-) ), a lemezeseket pedig kazetta CRC hiba, de EXDOS-os módra Retry/Abort kérdéssel :-)

Töltés végeztével egy figyelmeztetést kapunk, hogy ne Resettel lépjünk ki. Ha nem fogadjuk meg ezt a tanácsot, akkor egy újabb poénos üzenettel búcsúzik a program :-)
Ezután jön a fergeteges Paintbox munkásságom némi scroll és sok rasztercsík effekttel feldobva.
Következõ kép az elsõ Paintbox próbálkozások egyike volt, aminél ott poénkodtunk Apucival, hogy vajon mi a fenét is sikerült rajzolni. A magyarázatot olvashatjátok a képen  :ds_icon_cheesygrin:

A kép alatt egy egy újfajta rasztercsík effekt látható, továbbgondoltam 3D-ben a sima rasztercsíkot, ha úgy néz ki mint egy rúd, akkor félbe is lehet vágni! Ilyen félbevágott rasztercsík látható két darab, a 3D hatás erõsítésére a harmadik sima rasztercsík 8-as alakban kering ezek között.
Kilépéskor a rasztercsíkok valósítják meg a képernyõtörlést. Majd ezután egy poénkodó kérdés következik, miszerint örülnénk-e egy hideg resetnek?
A választól függõen más-más üzenettel búcsúzik a gép, itt ismét egy félbevágott, forgó rasztercsík a fõszereplõ, új effektként a domború felületére van nyomtatva a szöveg.

Ezután úgy tûnik, mintha resetelne a gép, azonban amikor tovább lépünk EP logótól, kiderül, hogy csak átverés volt, mert még fut a program, és megfenyeget minket a következõ résszel.
Ilyen reset szimuláció volt már korábban is egy demóban (most nem jut eszembe a neve, nekem igazából csak az EP logót átrajzoló, zenélõ része tetszett, azt külön ki is vettem EP-KACAJ.COM néven), viszont az csak az alapgép indulását utánozta.
Az enyém az EXOS-tól veszi a RAM listát, így bõvített gépen is annyi RAM-ot tesztel amennyi van, ill. érzékeli a gyorstesztes cartridge-t, így akkor gyorstesztet szimulál (az akkoriban létezõ eredeti Gyányi Sanyi félét, amit most pl. az ep128emu TASMON-os konfigjaiban láthatunk.)
Persze ma már ez is elavult, azóta jöttek újabb EXOS verziók, újabb gyorstesztek...
Ill. az egész program nem EP64 kompatibilis, mivel akkor arról még semmit se tudtam :-(
Igény esetén készülhet javított verzió  :lol:

És végül egy kis poénos üzengetés jut azoknak is, akik a program kódjába néznek bele :-)
 
Title: Re: Assembly programozás
Post by: szipucsu on 2011.October.07. 14:38:55
Nem tudom, ebbe a topikba illik-e leginkább:
Nem lehet, hanem biztos! :-)
A maradék karakterekkel ne foglalkozz, a hoszbájt (05) adja meg az EXOS-nak, hogy mennyit nézzen.
Az miért rontja el a programot, ha a maradék karaktereket egyszerûen kitörlöm onnan, és így pár bájttal rövidebb lesz a file?
(Mivel csak a basic-et ismerem, arra tudok gondolni, hogy így is, úgy is megy sorban az utasításokon a gép, és ha még nem is kell azt a pár karaktert átugrani, még örül is neki.)
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.07. 15:06:24
Nem tudom, ebbe a topikba illik-e leginkább:Az miért rontja el a programot, ha a maradék karaktereket egyszerûen kitörlöm onnan, és így pár bájttal rövidebb lesz a file?
Azért mert a gépi kódú programban minden címkezelés (ugrás, eljáráshívás, "változók") közvetlenül direktben hivatkozik címekre.
Hogy Basicesen mondjam: nincs Renumber :-)
Ha pl valami az 1000. címre hívatkozik, de te elõle kitöröltél 3 bájtot, akkor a hívatkozás az eredetileg 1003. címen lévõ bájtot fogja elérni.
Hogy mûködjön a dolog, ahhoz megkéne keresni a programban minden címhívatkozást, és ami a törlés után van, azoknak az érték hárommal csökkenteni, hogy a helyükre mutassanak.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.07. 15:20:25
Egyébként pont ezzel szenvedek én is. Elkezdtem felboncolni a guruló-fáraós :-) (http://ep128.hu/Ep_Demo/Pic/NasaGuy8.gif) Nasa&Guy demót, hogy majd kiszedjük az SNG lejátszást...
Elsõ lépésként rendbe akartam tenni az LPT kezelést, hogy legyen végre EP64 kompatibilis demó is. Itt sikerült is vagy 160 bájttal rövidebbre venni a kódot. Ekkor derült ki, hogy valahol bujkál egy rejtett direkt hivatkozás a byte_CFB nevû adatkupacra, mert ha az elmozdul az eredeti helyérõl, akkor elromlik a zene... a mellékelt fájlban ezért van egy rakás dw 0, hogy visszatolja a helyére.
Már több órát nézegettem, de még nem találtam meg, hol maradt még direkt hivatkozás.
(Visszafejtéskor a gépi direkt címzéseket az assemblernek szóló címkenevekre cseréljük, így aztán lehet majd betoldani, kitörölni a programból.)

Remélem, hátha valaki friss szemmel rögtön kiszúrja, mit néztem el!  :oops:

Title: Re: Assembly programozás
Post by: geco on 2011.October.07. 15:59:10
Egyelőre nem találtam semmit, pedig néztem, már majdnem megvakultam :D
Az add hl,-es részek végére nem jutottam, meg még ami felmerült bennem, hogy valami bittologatós rész eredménye is lehet.
Title: Re: Assembly programozás
Post by: IstvanV on 2011.October.07. 16:32:42
Szerintem nem a byte_CFB-vel van probléma, hanem az adatfile-okkal, amit ez után tölt be a program. A CFB-s területre nem találtam hivatkozást a debuggerrel a kezdőcím 1000h-val való eltolása után. Viszont egy abszolút címet már találtam a word_B9A címkénél. Érdemes átnézni az adatokat, mert azokban is előfordulhatnak címek.

UI.: Még egy abszolút cím: "ld a, (1009h)". De talán egyszerűbb lenne az adatokat az eredeti fix címre tölteni, és nem a VEGE címkének megfelelően ?
Title: Re: Assembly programozás
Post by: IstvanV on 2011.October.07. 16:43:10
Ha a forráskódban kicserélem a fix 1009h és 100Dh címre való hivatkozásokat VEGE+20Fh-ra illetve VEGE+213h-ra, akkor már jónak tűnik.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.07. 16:49:00
Ha a forráskódban kicserélem a fix 1009h és 100Dh címre való hivatkozásokat VEGE+20Fh-ra illetve VEGE+213h-ra, akkor már jónak tûnik.
Köszi!  :smt038
Title: Re: Assembly programozás
Post by: szipucsu on 2011.October.08. 11:12:08
Azért mert a gépi kódú programban minden címkezelés (ugrás, eljáráshívás, "változók") közvetlenül direktben hivatkozik címekre.
Hogy Basicesen mondjam: nincs Renumber :-)

Akkor csoda, hogy egyáltalán mûködött úgy is a program és csak hang nem volt, nem? :D
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.08. 11:21:53
Akkor csoda, hogy egyáltalán mûködött úgy is a program és csak hang nem volt, nem? :D
Igen  :ds_icon_cheesygrin:
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.08. 23:22:45
VEGE+20Fh-ra illetve VEGE+213h-ra, akkor már jónak tûnik.
Ahhoz, hogy azt megtudjuk, ezek mire is vonatkoznak, ismerni kéne az .SNG fájlok felépítését...
...kb 3 órányi googlézéssal, nem találtam semmit! Pedig mint kiderült, Music Studio nem csak Atarira volt, hanem Apple II-re, Amigara, C64-re, de még PC-re is... de sehol egy nyamvadt fájl formátum leírás  :evil:
Nem elõször gondolom azt, hogy csak az EP-nek és a Spectrumnak van rendes internetes archívuma  :)

Végül véletlenül akadtam egy Ataris gyûjteményre (http://cd.textfiles.com/geminiatari/FILES/MUSIC/00_INDEX.TXT), ahol szerepel egy ilyen
Quote
songdump/   Dump a music studio song, playing the notes as they occur.
Belenézve (http://cd.textfiles.com/geminiatari/FILES/MUSIC/SONGDUMP/) ott egy leírás, amivel meg van fõnyeremény!  :ds_icon_cheesygrin:
Quote
Song file structure

512 byte header structure:
   10 byte header CD,'Mstudio',CD,02
   15*10 byte atari instrument names (null terminated)
   15*8 byte atari instrument settings
   15*10 byte casio instrument names (null terminated)
   15 bytes casio settings
   15 bytes casio settings
   5 pointers (file displacement) to lyric lines
   32 byte null terminated title string

after the 512 byte header (hexadecimal unless noted):

track 1-4 bitmap (4 * 1 word)
   instrument active, [15:14:13...2:1:track enable]
00:80:01:key
   1= C G D A E B F# C# F Bb Eb Ab Db Gb Cb =15
83:time
   1= 2/2 3/2 2/4 3/4 4/4 5/4 6/8 =7
81:tempo
   quarternote = tempo, 57..200
84:01:volume
   0F pianissimo .. fortissimo 7F

music, 00 delimits beginning of column data, 0xff marks end of music info
82
   bar
85:number
   repeat number of times
86
   end repeat

note format
 0 : tie start : tie end : rest(not note) : [instrument:4]
 [0=inkey 1=nat 2=sharp 3=flat :2] : accent : [duration:5]
 pitch in C major midi coding (18(24d)=C2)

  duration: 12d = quarter note, (+2 for dotted(*3/2) , -2 for triplet (*2/3) )
   9d = 1/8th , 6d = 1/16th  15d = half, 18d = whole, etc.
  pitch is always the natural note, later adjusted for key, or explicit sharp,
   natural, or flat.
  d means decimal.  all other numbers in hex.

Ez alapján a programban hivatkozott elsõ érték a tempó, a második pedig zeneadatok elejére mutat.

Amúgy meg ennyit arról, hogy a Google mindent tud  :evil: na majd most jól beindexeli az EP fórumról az Atari .SNG leírást  :ds_icon_cheesygrin:
Title: Re: Assembly programozás
Post by: endi on 2011.October.08. 23:57:55
Ide írom be, jobb topikot nem tudok.
Vannak (voltak) olyan EP-k amiken az IM2 megszakítás nem mûködött rendesen, volt már errõl szó itt valahol a fórumon. Egyik porton ami az IM2 megszakítás rutin címének alsó bájtját adta (valami ilyesmi) random érték volt.
Na most. Tök kíváncsi lennék hogy milyen jelet rögzítenénk, ha kiírnánk ennek a portnak az értékét memóriába. :) Aztán kimentenénk egy file-ba és pc-n is meg lehetne vizsgálni.

Lehet hogy pár EP-nek valódivéletlen-generátora volt? :)
Tök kíváncsi lennék honnan jön az a "zaj" ami ott van.
Title: Re: Assembly programozás
Post by: szipucsu on 2011.October.08. 23:58:54
Az SNG és a MIDI fájlok felépítésének ismeretében távolabbi cél lehet talán, hogy MIDI -> SNG konverter készülhessen. Ez azt jelenti, hogy PC-n kényelmesen midi formátumba lehetne a zenét beírni, amit aztán átkonvertálva EP-n meg lehet hallgatni Dave-es hangzásban. Bár lehet, nem sok haszna lenne már. :D De azért érdekes lenne.
De lehet, hogy már létezik mid->sng konverter, ha az sng annyira elterjedt.
Title: Re: Assembly programozás
Post by: Povi on 2011.October.27. 10:25:29
Van egy játék, ahol külön fájlban van tárolva a hiscore.
Viszont magnóról elég kényelmetlen lenne a fájl használata (a betöltés még nem, de a mentés igen).

Meg lehet-e oldani azt elegánsan, hogy magnós rendszerben ne mentse el a hiscore fájlt, csak ha lemezes / vinyós / file eszköz van?

Én azt találtam ki, hogy "DISK:HISCORE.DAT" nevet adok a fájlnak, így magnóra nem írja ki, csak lemezre (vinyóra nem tudom), de FILE: eszközre se (emulátoron).

Van-e valami megoldás, hogy az EXOS-t megkérdezzük, mi az alapértelmezett eszköz, és ha az nem TAPE:, akkor írjon?
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.27. 10:58:30
Van-e valami megoldás, hogy az EXOS-t megkérdezzük, mi az alapértelmezett eszköz, és ha az nem TAPE:, akkor írjon?
Lenne rá szép megoldás: 3-as EXOS változó értéke 1.
Viszont ezzel felfedeztem egy hibát a FILEIO.ROM-ban: nem fájl-orientált eszköznek mutatja magát. (Azaz marad a 3-as változó értéke 0 mint a TAPE esetén.)
Title: Re: Assembly programozás
Post by: Povi on 2011.October.27. 12:06:02
OK, ez a megoldás tetszik!

EP-zni meg igazin kell, nem emulátoron! :-)

de azért nem lenne rossz frissíteni a file.rom-ot! :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2011.October.27. 16:21:55
Van-e valami megoldás, hogy az EXOS-t megkérdezzük, mi az alapértelmezett eszköz, és ha az nem TAPE:, akkor írjon?

Ha nem is tökéletes megoldás, azt egyszerűen le lehet kérdezni, hogy van-e EXDOS a rendszerben. '"EXDOS", 0FDh' parancsot kell kiadni, és ha sikeres, akkor van EXDOS, tehát menthető a file. Ilyenkor biztosan nem a TAPE: az alapértelmezett, mert vagy a DISK:, vagy a FILE: alapértelmezetté teszi magát a bővítők inicializálásakor (így a program indításakor is). Probléma a FILE: + TAPE: rendszernél van, mert ilyenkor ugyan lehetne menteni ha a FILE: az alapértelmezett, de ez a módszer nem ismeri fel.

Viszont ezzel felfedeztem egy hibát a FILEIO.ROM-ban: nem fájl-orientált eszköznek mutatja magát. (Azaz marad a 3-as változó értéke 0 mint a TAPE esetén.)

Az EXOS leírás alapján nem voltam biztos abban, hogy ezt be kell-e állítani :oops:
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.29. 23:47:15
Felfedeztem egy nagyobb problémát is a FILEIO-val  :oops:
HEASS MERGE-jé nem fut le, *** Call not supported by this device hibával.

Áthidaló megoldás, ha valaki ilyenbe fut bele: egy BAT fájlt kell csinálni, ami a beillesztendõ fájlokat bemásolja RAMDISK-be, majd a forrásszövegben onnan MERGE-zünk.
Title: Re: Assembly programozás
Post by: IstvanV on 2011.October.30. 07:17:17
Felfedeztem egy nagyobb problémát is a FILEIO-val  :oops:
HEASS MERGE-jé nem fut le, *** Call not supported by this device hibával.

Pontosan milyen EXOS hívást hiányol ? A FILE: gyakorlatilag azokat a funkciókat tudja, amiket a TAPE:, csak gyorsabb :) Talán az aktuális file pozíció olvasása és állítása kellene, amit nem valósítottam meg, mert a leírás alapján nem voltam egészen biztos abban, hogy ennek pontosan hogyan kellene működnie (paraméterek, hibák, stb.) :oops:
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.30. 07:50:22
Pontosan milyen EXOS hívást hiányol ? A FILE: gyakorlatilag azokat a funkciókat tudja, amiket a TAPE:, csak gyorsabb :)
EXOS 10-t használ a fájlméret beolvasásához:
Code: ZiLOG Z80 Assembler
  1.                 LD DE,BUFFER
  2.                 LD A,13
  3.                 EXOS 1
  4.                 RET NZ
  5.                 LD A,13
  6.                 LD C,0
  7.                 LD DE,BUFFER
  8.                 EXOS 10
  9.                 RET NZ
  10.                 BIT 1,C
  11.                 RET Z
  12.                 LD HL,(BUFFER+4)
  13. SIZEINC:        EX DE,HL
  14.                 LD HL,(SIZE)
  15.                 ADD HL,DE
  16.                 LD (SIZE),HL
Mondjuk ezt is javítani kéne, hogy 64K-nál nagyobb fájlt ne fogadjon el. (+6,7. bájtok vizsgálata)
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.October.30. 09:33:25
Talán az aktuális file pozíció olvasása és állítása kellene, amit nem valósítottam meg, mert a leírás alapján nem voltam egészen biztos abban, hogy ennek pontosan hogyan kellene mûködnie (paraméterek, hibák, stb.) :oops:
Próbálgattam a funkciót, hogy az EXDOS hogyan kezeli:
-a megadott 16 bájtos puffer visszatéréskor mindig frissitve van, 0-3 a fájlmutató, 4-7 a fájlméret, többi bájt 0
-védelmi bájttal nem sikerült semmit kezdeni, mindig 0 marad, és mindig érvénytelen
-visszatéréskor C=3,azaz mutató és méret érvényes. Nem sikerült érvénytelenséget kiprovokálni.
-fájmegnyitás után (EXOS 1&2) a mutató 0 lesz, a méret megnyitás (1) esetén az aktuális méret, létrehozás (2) esetén 0
-a mutatót szabadon lehet állítgatni, a következõ olvasás vagy írás a megadott pozíciótól fog kezdõdni
-ha a mutatót a fájl vége után állítjuk, akkor olvasáskor értelemszerûen EOF hiba lesz, íráskor a fájl automatikusan megnõ a szükséges mérettel, a beszúrt plusz bájtok tartalma nem definiált. Tehát ha pl létrehozunk egy új fájlt, átállítjuk a mutatót 199999-re, majd beleírunk 1 bájtot, akkor kapunk egy 200000 bájtos fájlt. 
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.01. 10:35:24
Az EXDOS-ban van ez a osztórutin. De hogy mûködik?  :oops: Osztás helyett szoroz...
Code: ZiLOG Z80 Assembler
  1.                 ;DE=DE/C
  2.  
  3. le2af:  PUSH    BC
  4.         LD      B,10H
  5.         XOR     A
  6. le2b3:  SLA     E
  7.         RL      D
  8.         RLA    
  9.         CP      C
  10.         JR      C,LE2BD                
  11.         SUB     C
  12.         INC     E
  13. le2bd:  DJNZ    LE2B3                  
  14.         POP     BC
  15.         RET
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.01. 11:07:46
Az EXDOS-ban van ez a osztórutin. De hogy mûködik?

Egyszerűen :)
    A   |    D   |    E
0000000x|xxxxxxxx|xxxxxxxy
000000xx|xxxxxxxx|xxxxxxyy
00000xxx|xxxxxxxx|xxxxxyyy
0000xxxx|xxxxxxxx|xxxxyyyy
000xxxxx|xxxxxxxx|xxxyyyyy
00xxxxxx|xxxxxxxx|xxyyyyyy
0xxxxxxx|xxxxxxxx|xyyyyyyy
xxxxxxxx|xxxxxxxx|yyyyyyyy
xxxxxxxx|xxxxxxxy|yyyyyyyy
xxxxxxxx|xxxxxxyy|yyyyyyyy
xxxxxxxx|xxxxxyyy|yyyyyyyy
xxxxxxxx|xxxxyyyy|yyyyyyyy
xxxxxxxx|xxxyyyyy|yyyyyyyy
xxxxxxxx|xxyyyyyy|yyyyyyyy
xxxxxxxx|xyyyyyyy|yyyyyyyy
xxxxxxxx|yyyyyyyy|yyyyyyyy

Ugyanúgy működik, mint ahogy 10-es számrendszerben kell osztani (illetve még egyszerűbb is, mert egy számjegy csak 0 vagy 1 lehet). Balról jobbra bitenként megnézi, hogy az ADE felső 8 bitje nagyobb vagy egyenlő-e C-vel, és ha igen, akkor kivonja a C-t és 1 bitet léptet be, egyébként 0 bitet.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.01. 11:58:22
Ezek az IS fiúk tudtak valamit!  :smt038
Title: Re: Assembly programozás
Post by: Attus on 2011.November.01. 18:05:47
Gyönyörû!
 :)
Title: Re: Assembly programozás
Post by: Z80System on 2011.November.01. 19:04:40
annak idejen egy kozeli falubol valo traktoros magyarazta el nekem ennek az osztasi modszernek az elvet, es a szorzaset is.

( azt is lehet hasonlo modon bitek szamatol fuggo idoben elvegezni, nem pedig soxor osszeadni, ahogy itt az osztasnal is lehetne soxor kivonni, csak az az esetek tobbsegeben lassabb ),

de aztan a vegen valahogy megsem lettek hasznalva, az egyszeri demo programozonak altalaban mindig olyan tablazatokat kell epitenie a kello futasi sebesseghez, amiben a szamitasok mar mind benne vannak, sajna ep- n nem engedhette meg maganak az ember az algoritmikus szorozgatast osztogatast valosideju cuccokban

na de visszaterve,

mikor ez meg nem tristalyosodott ki bennem, akkor magamtol persze az osszeadogatos ill. kivonogatos modszerekig jutottam el, es ugye akkoriban ott a halal *szan nem errol szolt az elet, es kepzelhetitek a meglepetesem, mikor ganyehordas kozben, egy erdeklodo kerdesre, hogy halotta hogy en igy "szamitogepezek", gondoltam megpenditem neki a szorzas/osztas problemajat, akkor majd leszall rolam, es nem kezd el traktalni hogy ez az egesz mar mekkora hulyeseg, es akkor a ganesvilla masik oldalarol elkezdi nekem tolni a traktoros, hogy hogyan kell csinalni ... :) !


Title: Re: Assembly programozás
Post by: endi on 2011.November.02. 00:14:44
hehe, ez jó
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.06. 22:26:59
Találós kérdésként egy icipici apróság az EXDOS kódjából:
Mi értelme az ilyen programszerkezetnek? A példában kitalált címekkel, az elv a lényeg.
Code: ZiLOG Z80 Assembler
  1. D000H  JR NZ,0D040H
  2. ...
  3. D040H  JP NZ,0E123H
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.06. 22:37:16
Mi értelme az ilyen programszerkezetnek? A példában kitalált címekkel, az elv a lényeg.

Helymegtakarítás ? A JR utasítás rövidebb, mint a JP, és ha sok egymáshoz közeli helyről kell ugyanarra a távoli címre ugrani (pl. hiba esetén), akkor elég csak egy JP, a többi ugrás pedig lehet JR a JP-re. Ilyen megoldást én is használtam néhány byte megtakarítására :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.06. 23:17:04
Helymegtakarítás ? A JR utasítás rövidebb, mint a JP, és ha sok egymáshoz közeli helyrõl kell ugyanarra a távoli címre ugrani (pl. hiba esetén), akkor elég csak egy JP, a többi ugrás pedig lehet JR a JP-re.
Gyors megfejtés volt!  :smt038
Pontosan így van, itt is funkcióhívások után "kilépés ha hiba" célokra van használva.
Az ember általában végrehajtás szerinti legrövidebb kódra törekszik, ezért nem jut egybõl eszébe ez a bájtfaragó módszer.

Másik gyakran használt módszerük, hogy amikor egy elágazás mindkét ágán valami egyszerû 1-2 bájtnyi utasítás kell végrehajtani, akkor szintén meg lehet spórolni úgy 1 bájtot, hogy az elsõ ág végén nem egy JR-rel ugorjuk át a második ágat, hanem egy töltelék bájttal valami a program szempontjából semleges utasítás paraméter bájtjaivá teszik. Példa:
Code: ZiLOG Z80 Assembler
  1.         BIT     7,L            
  2.         JR      NZ,LC346        ;ugrás, ha írásra kell nyitni
  3.         EXOS    01H             ;csatorna nyitás olvasásra
  4.         DB 01H  ;töltelék bájt, hogy az utána következõ EXOS 2 ne fusson le
  5. LC346:  EXOS    02H             ;csatorna nyitás írásra

Itt ha az olvasás ág fut le, akkor egy
Code: ZiLOG Z80 Assembler
  1. LD BC,02F7H
utasítás fog az EXOS 2 helyett végrehajtódni. Hagyományos kódolással egy JR C348h lenne a DB 01h helyett, ami 1 bájttal hosszabb.
Legtöbbször valamilyen LD utasítással játsszák el ezt, de ha nincs elrontható regiszter, akkor egy feltételes JP kódjai is lehet, ha van olyan feltétel ami tuti nem teljesül, így nem fog elugrani a kapott kamu címre. Erre is egy példa:
Code: ZiLOG Z80 Assembler
  1.         JR      NZ,LE40E        ;ugrás ha igen
  2.         RES     1,E             ;Double stepping kikapcsolása
  3.         DB      0C2H            ;töltelékbájt a RES 2 átugrásához JP      NZ,L93CB
  4. LE40C:  RES     2,E             ;SD lemez
  5. le40e:  SET     0,E


Ezek a trükkök a disassemblerek rémálmai  :ds_icon_cheesygrin:
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.07. 15:30:28
Ezek a trükkök a disassemblerek rémálmai  :ds_icon_cheesygrin:

Én elég gyakran használom :oops:
Title: Re: Assembly programozás
Post by: Z80System on 2011.November.07. 15:40:28
Fu sosem szerettem oket ... en meg a xor a -t is utaltam. Mindig ugy ereztem hogy olyan igazi boostot ( sebessegben, meretben ) nem tesznek hozza a dolgokhoz, hacsak nem obfuszkalni akar az ember. Persze lehet hogy valami rendes koder le tudna vezezni, hogy ezek a sebesseg es meret megtakaritasok mit tudnak jelenteni egy olyan komplex assembly rendszernel mint az exos ( pld. ), es ha 1X bizonyitva latnam, akkor meg tudnam oket bocsajtani, de sztm ezek csak ilyen egyeni firnyaksagok, affele bitbabralas, jatek annak, aki tudja mi az. ( Vagy esetleg olyan kepessegekkel van megaldva, amivel a tobbseg nincs, es jon neki zsigerbol. ) Tipikusan olyan embereknek valok, akik szeretik a fejtoroket. Ertelmuk semmi, de elvezetes megfejteni oket.

Marakinek az.
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2011.November.07. 15:47:10
Tudtok spektrum vagy ep játék forrásokat? Nem visszafejtett kódra gondolok hanem eredetire. Kiváncsi lennék milyen stílusban programoztak a hivatalos gyártók, akár egy codemasters.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.07. 16:27:30
Tudtok spektrum vagy ep játék forrásokat? Nem visszafejtett kódra gondolok hanem eredetire. Kiváncsi lennék milyen stílusban programoztak a hivatalos gyártók, akár egy codemasters.
Ilyenre én is kíváncsi lennék, de nem túl valószínû hogy lehet ilyet találni. Codemasters-tõl biztosan nem, az még 20+ éves játékaik közreadását is letiltotta a WOS-ról.
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2011.November.07. 16:46:24
Csodálom hogy az eredeti exos/exdos forrás nem lett meg.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.07. 16:46:38
Persze lehet hogy valami rendes koder le tudna vezezni, hogy ezek a sebesseg es meret megtakaritasok mit tudnak jelenteni egy olyan komplex assembly rendszernel mint az exos ( pld. )
Akkoriban még nem úgy ment a programozás, hogy semmi nem számít majd max rak még 2 giga ramot a felhasználó gépbe, meg 4 magos procit, és plusz 1 tera vinyót  :lol:
Különösen igaz ez ROM programokra, ahol IC kapacitása külön extra korlátot szab a programozó fantáziájának. És vagy kevesebbet fog tudni a program, mint amit szeretne, vagy ügyesebb lesz, és addig faragja amíg befér. És ilyenkor minden egyes bájtocska számít.
Majd a végén összeszámolom, hogy mennyit spóroltak meg különbözõ trükkökkel az EXDOS-ban, de úgy kb 150 bájtra tippelek. Ez kb két DOS parancs, amit még ki kellett volna hagyni, ha kevésbé ügyesek. Így is látható, hogy a 0.3-as verzió ami már csurig kitöltötte a 16K-t, több parancsot tartalmazott, amik az 1.0-ra már kiszorultak a ROM-ból.
Title: Re: Assembly programozás
Post by: geco on 2011.November.07. 18:34:09
Én elég gyakran használom :oops:

Láttam is :), néztem jó nagyokat amikor először találkoztam vele ;)
Ha jól emléxem az ay utánzó rutinodban is van egy helyen.
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.07. 20:05:19
néztem jó nagyokat amikor elõször találkoztam vele ;)
Ezzel szerintem mindenki így van, amikor elõször látja, aztán csap a homlokára, hogy "ez nekem miért nem jutott eszembe" :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.07. 21:12:22
en meg a xor a -t is utaltam

Az SBC A, A érdekesebb :)
Title: Re: Assembly programozás
Post by: lgb on 2011.November.09. 09:54:34
Fu sosem szerettem oket ... en meg a xor a -t is utaltam.

Ezt vitatnam. Pont a "van egy 3GHz-es quad core CPU-m, fene fog sporolni" dologgal ellentetben az a szep ezekben a regi computerkben, hogy az ember orajelciklusokat sporolgat, es akar egy ejszakat ul a kod felett, hogy vacak par byte-nyi machine code cuccost hogy lehet rovidebb ido alatt futtatni. Itt nagyon jol jonnek az ilyen trukkok, es szerintem pont ez a szepsege a dolognak, ellentetben a mai vilaggal, amikor ugye "nem fut gyorsan? bovitsel gepet, ember! olyan olcso a RAM, meg a CPU is ma mar". Na nem: a regi szep idokben pont ahhoz kellett a tehetseg, hogy a hw adott volt: azon KELL megoldani. Ha meg tudod, oke, ha nem, akkor az ember inkabb ne programozzon :) Sajna manapsag nem igy van.

Az ilyen trukk mint a "xor a" meg egyszeru is, akar lehetne neki uj nevet is adni, hogy vilagosabb legyen, hogy mit csinal pl "RESA" :) vagy tudomisen. Elvegre ne felejtsuk, hogy ami pl "LD" azok kozott telejsen mas jellegu utasitasok vannak (pl register-register transfer, regiser-memory transfer, stb), az csak egy szokas, hogy hogy jeloljuk, sok architekturan nem is mossak ezt egybe, hanem teljesen kulon kezelik (pl: LOAD, STORE, illetve meg valami a register-register transferre). Ez csupan szokas kerdese.
Title: Re: Assembly programozás
Post by: Povi on 2011.November.09. 10:58:09
Különösen igaz ez ROM programokra, ahol IC kapacitása külön extra korlátot szab a programozó fantáziájának. És vagy kevesebbet fog tudni a program, mint amit szeretne, vagy ügyesebb lesz, és addig faragja amíg befér.
És jön az örökös dilemma: gyors kód legyen, vagy rövid?  :) A kettő nem mindig megy egyszerre, a gyorsabb sokszor hosszabb kódot eredményez (kicsit ellentmondásos a dolog, de igaz).
Title: Re: Assembly programozás
Post by: Zozosoft on 2011.November.09. 11:36:16
És jön az örökös dilemma: gyors kód legyen, vagy rövid?  :) A kettõ nem mindig megy egyszerre, a gyorsabb sokszor hosszabb kódot eredményez (kicsit ellentmondásos a dolog, de igaz).
Ez így van! De mondjuk a XOR A az gyors és rövid is :-)
Title: Re: Assembly programozás
Post by: Ferro73 on 2011.November.14. 18:25:53
a DAVE programozása ?
Code: ASM
  1. 0038h push af
  2.    in a,(0B4h)
  3.    bit x,a
  4.    jp z,idõzített megszakítás
  5.    .
  6.    .
  7.    .
  8.    ld a,XX
  9.    Out (0B4h),a
  10.    push af
  11.    ei
  12.    reti
  13.  
  14. idõzített megszakítás
  15.   push de
  16.   push hl
  17.   ld hl,(skálaindex)
  18.   ld de,(hl)      ; idõhossz
  19.   ld a,e                   ?
  20.   or d
  21.   jp z,nincs több
  22.   ld a,1 hang csatorna leállítása
  23.   out (0A7h),a
  24.   ld a,d
  25.   out (0a0h),a
  26.   ld a,e
  27.   out (0A1h),a
  28.   inc hl
  29.   inc hl
  30.   ld de,(hl)      ;hang HZ
  31.   ld a,e
  32.   out (0A2h),a
  33.   ld a,d
  34.   out (0A3h),a
  35.   inc hl
  36.   inc hl
  37.   ld (skálaindex),hl
  38.   ld a,x      ; megszakítás 0-ás csatorna 1-es fúttatása
  39.   out (0A7h),a
  40.    .
  41. nincs több
  42.    pop hl
  43.    pop de
  44.    ld a,XX
  45.    Out (0B4h),a
  46.    push af
  47.    ei
  48.    reti
  49. skálaindex  dw kotta
  50. kotta   dw xx,yy ; xx=a hang hossza (s) yy=hang magasság (herz)
  51.    .
  52.    .
  53.    dw 00            ;vége
  54.  
valami ilyesmire gondoltam
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.14. 19:54:18
a DAVE programozása ?

valami ilyesmire gondoltam

Igen, az ötlet alapvetően működik, de így elég rövid (pár század másodperces) hangokat lehet előállítani ha egy hang csak egy megszakítás, a 12 bites számláló korlátai miatt.
Title: Re: Assembly programozás
Post by: Ferro73 on 2011.November.14. 20:23:07
kár
zenében nem vagy jártas de mennyi lehet a legrövidebb hang hossz egység (xx milisec)?
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.14. 20:50:46
mennyi lehet a legrövidebb hang hossz egység (xx milisec)?

Az változó, egy negyed hang hosszának valamilyen tört része, többnyire a nyolcada elég, de ha a hangok közötti szünetek hosszát is állítani akarod, akkor kisebb időegység előnyösebb. Mindenesetre az biztos, hogy egy hanggenerátor megszakítással (16.4 ms, vagy 24.6 ms a DAVE "lassításával" a BFh porton - ehhez képest egy negyed hang jellemzően néhány tized másodperc) nem lehet zeneileg elfogadható maximális hosszúságot elérni, tehát mindenképpen szükség van a megszakítások számlálására. Így viszont már jobban megéri, ha nincs is hanggenerátor megszakítás, mert akkor a csatorna felszabadul hanggenerálás céljára, és a megszakításhoz pedig használható helyette az 50 Hz-es video-, vagy az 1 kHz-es megszakítás (ha nagyon pontos időzítést próbálsz elérni).
Title: Re: Assembly programozás
Post by: Ferro73 on 2011.November.17. 17:17:39
Akkor ha az 1kHz megszakítást is használom és az 50 Hz lekérhetem  melyik megszakítás volt .
Így a zenei hang idõzítése 1 ms egységekben mérhetõ az a +-0.5 ms csak nem zavaró annyira.
már csak a játékban kell ellenõrizni, a hang elõállításánál nem tiltót a megszakítás.
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.17. 18:47:46
Így a zenei hang idõzítése 1 ms egységekben mérhetõ az a +-0.5 ms csak nem zavaró annyira.

A játékok általában csak 50 Hz-es megszakítást használnak a zene időzítésére, illetve CPC-n néha 300 Hz-et, tehát az 1 kHz több, mint elég.
Title: Re: Assembly programozás
Post by: Ferro73 on 2011.November.18. 16:46:57
De kettõ megszakítást alkalmazható a programban egyszerre ? PL: 50Hz és 1kHz vagy 50Hz és 0.hangcsatorna
Mint ami a példámban írtam.
Átmegyek a spectrum átíratokra
Title: Re: Assembly programozás
Post by: IstvanV on 2011.November.18. 18:49:16
De kettõ megszakítást alkalmazható a programban egyszerre ? PL: 50Hz és 1kHz vagy 50Hz és 0.hangcsatorna

Igen, a B4h port olvasásával dönthető el, melyik történt.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 03:11:49
Regebben beszeltunk itt arrol, hogy ep- n nem letezik a programhoz/programbol valo visszateres fogalma, mikor futtatjuk az exos- sal a programunkat, akkor mittudomen talan meg is szunik az a modul amibol epp futtattuk, tehat a basic/exdos/epdos/akarmi, abban a futo peldany mivoltaban meg is szunik, igy mikor a meghivott program vegzett, akkor mar nincs is "hova" visszaterni, es lehet ujrainditani a gepet, esetleg egy celiranyos modul ( rendszerbovitoket hivom en modulnak itt ) ujrainditassal / peldanyositassal atadjuk annak a vezerlest, de az akkor mar egy uj peldany, reszetelodott tartalommal, barmi is legyen a modul amit inditottunk.

Van persze az a kivetel, mikor a programot magat is rendszerbovitonek irjuk meg, es akkor annak is specialis meghivasi lehetoseget kihasznalva tudunk ilyen "visszatero" programot csinalni exos kompatibilis modon, de ilyenkor meg mivel a programunk rendszerbovito, ezert vegig foglalja a memoriat, nem csak a futtatasanak ideje alatt. ( legalabbis egy szegmenst ha jol tudom, tenyleg ebbol az kovetkezik hogy a :help altal listazott dolgok mind-mind 16 kb- ba kerulnek ... a azt nem hinnem... )

Namost az lenne az en mega oteletem, hogy milyen jo lenne egy ilyen futtatasi protokollt szabvanyositani, ami megjelenhetne kulonbozo programokban nativ funkciokent, es lehetne neki egy dedikalt rendszerbovitoje is, ami csak ezt a funkciot tudna.

Arra gondolok, hogy mondjuk kitalalnak egy modszert, legyen pld. ugyanaz mint az 5- os ( ha jol emlexem ) fejlecu program, ami az atlag program, aminek ugye 100H -ra kell orgolni a kodjat ( de lehet ez 1000H- is vagy akarmi, ami celszerunek latszik nekunk inkabb ), es akkor ez a funkcio az adott 5- os fejlecu cuccot ugyanugy betolti egy ures szegemnsre, rateszi egy lapra ( jelen peldaban nullas ) es call -lal raugrik a cimra ( ami most a 100H ).

Innentol a futtatott program ha respekttel banik az exos- szal, memoriaval, ugyesen atkapcsolja magara a hardvert ( mexakitasok, video, memorialapok, stb. ) aztan fut ahogy o akar, nem erintve olyan szegmenseket, ami mar az exos altal lefoglalt, majd kilepeskor visszaallitja a hardvert amit elallogatott es ret- tel visszaterne a hivoprogramhoz, akkor ebbo la hivo program semmit nem venne eszre. ez az a mechanizmus amit en mondjuk hasznalok akkor ha asmonban fejlesztek. go -val lefuttatom a kodom ( csak ott ugye megmondhatom hova ugorjon ), ami ugy mukodik, ahogy az elobb mondtam, es futas utan visszaterek az asmonba ret- tel. asmon ebbol mit sem vesz eszre, ott folytatja bitre, ahol a hivas elott abbahagyta, minden beallitas, minden allapot valtozatlan.

Akar parameterezni is lehetne a funkciot, hogy megadhassam neki hogy milyen cimre toltse be a cuccot, hogy hova ugorjon, ilyesmi. de jo lenne rogziotetten is, tokmindegy.

Lenyeg hogy ezt a funkciot/protokollt aztan meg lehetne valositani programokban, olyan programokban, mint mondjuk az epdos, lehetne egy funkcio ra. es akkor amelyik program ilyen "szepen megirt, exosra vigyazo program" azt ezzel a funkcioval le lehetne futtatni epdosbol ugy, hogy a program utana az epdosba ( vagy ahol csak meg lett valositva ) visszaterne valos visszateressel, nem ujrainditassal.

Es akkor jonne a slusszpoen: egy sajat rendszerbovitoben meg lehetne implementalni ezt a betoltes/futtatas funkciot, egy olyan ( akar parameterezheto ) rendzser bovito parancs formajaban, amit az elejen emlitettem, ami ugye valami inicializalasnal fut le, es akkor vissza tud terni abba a rendszerbovitobe amibol hivtak.

Vagyis vegul nem kene a programokat rendszerbovitokent irni ahhoz hogy igazi visszateros programok legyenek, hanem csupan egy rendszerbovito lenne, ami megvalositan a futtatasi protokollunkat, a call/ret- es modszerrel.

es akkor innentol kezdve akarmelyik programbol amiben csak van rendszerbovito hivasi funkcio ( basic, exdos, asmon, wp, epdos, gyakorlatilag minden ami szamit ) meg tudna hivodni igazi visszaterosen az a program, ami erre figyelve van megirva.

tehat mondjuk basicban begepelnem:

:run "e:\runprotokollalmukodoprogram.com" -1200H

es akkor lefutna a :run rendszerbovitonek az a resze, ami vissza tud terni ( inicializalo vagy mi ), ami meghivna a XY.com -ot oly modon hogy betolti es raugrik a parameterben megadott 1200H -ra ( ha parameterezhetonek lenne csinalva, nem fixen kikotottnek )

es akkor a mi programunk lefutna, majd visszaterne a run rendszerbovitobe ret- tel ( annak is abba az inicializalo reszebe ), es az meg visszaterne a basicba.


ez persze a programok zomevel nem mukodne egyutt, de lehetne ezentul olyan programokat irni, amik kepesek tetszoleges rendzserbovitobe valos modon visszaterni a :run rendszerbovito segitsegevel, vagy barmi olyan programba ( pld. epdos ) ami ezt a futtatasi funkciot megvalositana a :run rendszerbovito hasznalata nelkul.


az ilyen modon futtathato programoknal akkor lehetove valna a valos visszateres, igy pld. epdosbol ( akar nativan akar :run bovitohivassal lenne hasznalva ) miutan lefutott a program es kileptunk, ugyanott allnank, ugyanazon a programon, es +1X megnyomva az entert, ujra lefutna a dolog, nem lenne reset/navigacio.



vagy basicban lehetne begepelni par sort, aztan lefuttatni egy ilyen modon futo programot, majd kilepes utan folytatni a basic programot.




ha pedig a protokollunkat ugy vennenk fel, hogy siman ellopnank az 5- os fejlecu program tulajdonsagait, tehat fixen 0 lap 100H- n indul, a program max 64K lehetne, es egymas utani szegmensekre toltodne be,
magyarul uyganaz lenne mint az 5- os fejlec, akkor a program normal exos modon futtatva is jo maradna, csak nyilvan a kilepeskor elszallna, mert nyilvan a visszateres csak akkor mukodhet ha "van hova", mert csak sima call- lal lett meghivva, a mi protokollunk szerint, nem pedig az exos ugrott ra.

itt lehetne egy kis csavar a futtatasi protokollunkban, egy nem zavaro regiszterben, vagy valahogy ahol lehet jelezni kene a programnak, hogy o most protokoll szerint ( call -lal ) lett hivva, vagy pedig beepitett exos kod futtatta le.

es akkor sajat protokoll eseten visszalephetne az adott program valos visszateressel, ha meg az exos hivta, akkor vagy nem is jelenitene meg a kilepes funkciot, vagy nem figyelne a kilepes billentyure, vagy kilepeskor a most alkalmazott direkt rendszer bovito elinditast hasznalhatna.


Akar szulethetnenek a "gyari" programokbol olyan verziok, atiratok, amik figyelnek erre a "visszaterhetek- e flag- re" es akkor korekt modon bannanak az exossal, es kepesek lennenek visszaterni esc- re, vagy ilyesmire. Persze nem lenne epp konnyu egy ilyen atirat, sok memoriat hasznalo programoknal esetleg csak bovitett gepeken lehetne megirni hogy az exos altal hasznalt szegmenseket ne bantsak, de hat az emulator vilagaban mar annyi memoriank lehet amennyit csak akarunk.




Na szal valami ilyenen gondolkodtam ... de tul sok volt ebben az allitas, es semmit nem ertek az exos- hoz, szal az lenne az alapkerdesem, attol aki ert hozza, hogy jo gondolom- e en ezeket, megvalosithato lenne- e a barmilyen modulba igazi visszateres olyan programoknal, akik a fentebb emlitett modon torodnek azzal hogy az exossal korrekt modon banjanak indulasnal/futasnal/kilepesnel ?



Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 09:17:27
Erre valók IS-DOS-ban a tranziens programok, komoly munkára ezek lettek szánva. Az 5-ös fejlécû EXOS program végül is ennek (Azaz a IS-DOS / CP/M / MSX-DOS) futtatási funkciónak az egyszerûsített kivitele.
Megoldható még a 2-es fejlécû áthelyezhetõ programmal is, a betöltõ programon múlik.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 11:52:46
Quote
Erre valók IS-DOS-ban a tranziens programok, komoly munkára ezek lettek szánva.

Na de gondolom az is-dos program az is-dos -hoz ter vissza, az is-dos pedig maga is egy rendszerbovito, tehat egy masik rendszerbovitobol eloszor at kell lepjek az is-dos- ba ( ekkor ugye megdoglik az eredeti rendszerbovitom, basic- em, epdos- om, akarmim ),

az altalam felvetett dolognak az lenne a lenyege, hogy minden rendszerbovitoben megvalosithato a visszalepes, meg akkor is, hogy ha nincs is implementalva direktben a funkcio az adott rendszerbovitoben ( basic, epdos ), mert a :run rendszerbovito-t mindegyikbol meg tudjuk hivni, mivel minden fontos rendszerbovitoben meg vana valositva egy masik rendszerbovito hivasa mar jelenleg is.

Quote
Megoldható még a 2-es fejlécû áthelyezhetõ programmal is, a betöltõ programon múlik.

Ez most akkor azt jelenti, hogy jol hadovaltam ossze, es megvalosithato lenne amit mondok, de meg az 5- os melle akar 2- essel is ?

Az 5- os azert lenne celszeru, mert szerintem a jelenlegi ep programok 99%- a 5- os fejlecu, amit akkor ugyanugy futtatni lehetne ezzel a :run rendszerbovitohivassal, igy "at lehetne ra szokni", nem kene azt csinalni, hogy mielott futtatok, akkor vegiggondolom, hogy milyen parancsal inditsak, hanem csak beirnam hogy:

:run batman.com

a megszokott

:load batman.com

helyett.

es akkor ha a batman.com egy sima jatek, akkor ugyanugy viselkedne mint eddig, es nem tudna visszaterni, ha meg egy olyan program ami kepes visszaterni, mert most lett irva, vagy atirtak a batmant olyanra hogy vissza tudjon terni, akkor meg majd vissza tudna terni.

tehat felhasznalonak annyi lenne a kulonbseg hogy :load helyett :run -t ir. ( persze tok jo lenne, ha epdos- ban lenne neki egy mondjuk startRet gomb a jelenlegi start mellett, aminek az implementacioja vagy hivja a :run- t vagy siman tartalmazna az epdos is azt a funkciot, ami a :run -ban is benn van, tehat hogy betolt es call- lal raugrik egy programra )


Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 12:46:37
exos leirasbol angol verzio nincs keznel ? mert egyet nagy nehezen talaltam itt:

http://enterprise.8bit.hu/document/books/exos_2.1_technikal_information/index.html

de ebbol hianyzik a nick/dave leiras, meg ilyesmik ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 14:05:18
exos leirasbol angol verzio nincs keznel ? mert egyet nagy nehezen talaltam itt:

http://enterprise.8bit.hu/document/books/exos_2.1_technikal_information/index.html

de ebbol hianyzik a nick/dave leiras, meg ilyesmik ...
Ne az oldal ezeréves címén nézd, hanem az aktuálison:
http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/index.html
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 14:39:05
Quote
Ne az oldal ezeréves címén nézd, hanem az aktuálison:

Hat azt dobta ki a gugli ... nem pedig az ujat ...

az ep128.hu is valtozott, vagy ez meg a regi cimen aktualis ?



Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 19:19:59
Na jo sokat osszeolvasgattam az exos konyv elso fejezetebol, nem biztos hogy mindent ertek, de lett egy ralatasom a dologra, hatha le tudom irni roveiden, szakszerubben, hogy mit akarok.

Tehat azt szeretnem elerni hogy lehessen olyan uj programokat irni, ill. meglevo programokat atirni ( pld. gyari jatekok, demok, rajzprogramok ), amiket aztan a kulonbozo jelenleg is hasznalt programokbol le lehetne futtatni oly modon, hogy az adott jatekbol ki lehessen lepni, es a program amibol lefuttattuk, ott folytassa a futasat, mintha le sem futtattuk volna az adott jatekot.

Tehat mint megtudtam exos futasa kozben mindig van egy "aktualis alkalmazoi program". A kovetkezoekben ezt AAP -nek hivom majd. Amikor basic- ben vagyunk, akkor a basic az AAP, amikor a wp- ben vagyunk akkor a wp az AAP, amikor az epdos- ban akkor az epdos az AAP.

Namost en ugy szeretnek lefuttatni egy demo vagy jatekprogramot az elobb emlitett programokbol ( tehat mikor valamelyik kozuluk az AAP ), hogy miutan lefuttattam az adott jatekot vagy demot, abbol vissza tudjak lepni abba az AAP- be, amibol lefuttattam.

Ehhez tulajdonkepp az kell, hogy ne valtozzon meg az AAP, maradjon az a program, amibol lefuttattam a jatekot/demot.

Sot meg egy dolog kene hogy teljesuljon, megpedig az, hogy egy ilyen kilepni kepesre megirt/atirt jatek a jelenlegi, hagyomanyos modokon is futtathato legyen, ne csak specialis rendzserbovitovel rendelkezo gepen, vagy ilyesmi. tehat ha nekem van egy kilepni kepes jatekom, azt ugyanugy tolthessem/futtathassom a basic start/load parancsokkal vagy az exdos :load -al, vagy a wp f1- el, vagy barmivel amivel csak programot szoktunk futtatni. A felhasznalo negativat ne tapasztaljon, csak vagy ki tud lepni egy programbol, vagy nem, de ne kelljen fejben tartania, hogy ez egy kilepni kepes program, vagy hogy ezt most maskepp kell inditani, vagy ilyesmi.




Namost ha jol ertettem meg az exos tolteset akkor 2 helyen lehet azt specializalni.

Az egyik hogy az enterprise file formatum modul fejleceben a modul fejlec tipust 31- nel nagyobb ertekre allitom. Ekkor az exos azt nem fogja felismerni tolteskor, es vegig fogja probalni a rendszerbovitoket hogy ezt a fejlec tipust valamelyik be tudja- e tolteni. Ide akkor lehetne irni egy rendszerbovitot, ami felismerne, hogy ez egy ilyen visszateresre alkalmas program, es korrekt modon lefuttathatna, majd mikor a  program hozza visszatert, akkor o is visszaterhetne abba az AAP- be ahonnan a toltes ki volt adva.

Ennek a modszernek az lenne a lenyegi hianyossaga ( azon kivul hogy egy gyari program atirasahoz modul fejlecet is valtoztatni kene ), hogy a mi mostmar sajat modul fejlec tipusu programunkat csak akkor tudnank betolteni, ha meglenne hozza egy rendszeren az a rendszerbovito, ami kezeli a fejlec tipusunkat. tehat egy rendzserbovito nelkuli gepen az adott program nem indulna el. ezt nem szeretnem en, ahogy irtam, egy felhasznalonak legyen mindegy hogy ez most meg "hagyomanyos" program, vagy kilepni kepes program, o csak futtat es ha adottak a feltetelek akkor a program kilephet, ha nem adottak, akkor nem lephet ki, de lefutni mindig fusson le. Nem beszelve arrol, hogy ezeket a fejlec azonosito szamokat hogyan lehet szinkronizali egymashoz, hogy 2 kulonbozo rendszerbovito ne ugyanarra a fejlec azonosito szamra figyeljen, es toltogessek be egymas moduljait ?

A masik lehetoseg az lenne, hogy a modul fejlecet 2- esre allitanank ( ahogy zozo korabban javasolta ) mert ezzel elbanik az exos, nem kell hozza, hogy egy kulon rendszerbovito legen a gepen, a betoltodesehez. Na igen am, de ez csak akkor igaz ( ha jol ertem ), ha az adott AAP kezelni tudna a 2-es fejlecu modult, ugyanis az exos csak formailag banik el ezzel a modultipussal, a betoltesi hely meghatarozasa a hivo felre van bizva ( jelen esetben ugye ez az AAP lenne ). Szoval vegeredmenyben itt meg rosszabb a helyzet, mert itt nemcsak egy rendszerbovito kene jelen legyen az adott gepen, mint az elozo peldaban, hanem az osszes programunkat ( wp, basic, epdos, stb. ) fel kene kesziteni az ilyen alkalmazasok betoltesere, ami sok program csrejet jelenteni, romokban is, szoval teljesen ertelmetlennek tunik.

Nekem ugy tunik, hogy az egyetlen jo lehetoseg az lenne a dologra, ha egy ilyen "kilepni is kepes" program az maradna 5- os fejlecu program, ami akkor nyilvan ugyanugy toltodne es futna hagyomanyos modon futtatva mint eddig, de lenne keszitve egy rendszerbovito, aminek van egy :run vagy :call kommand sztringje, ami egy tetszoleges 5- os fejlecu programot kepes lenne betolteni es lefuttatni oly modon, hogy nem valtja at az AAP- t az aktualis programra.

Ugy gondolnam ezt kivitelezni, hogy mikor meghivodna a :run program.com vagy :call program.com rendszerbovito kommand, akkor a rendszerbovito nem hivna exos "load_module" rendszerhivast, hanem a megnyitott csatornabol o olvasna be a headert, ellenorizne hogy 5- os programrol van szo, es betoltene exos- tol igenyelt szegmensekre, es gepi kodu call utasitassal hivna meg a 100H- as cimet.

Innentol mar a kilepesre felkeszitett megirt/atirt program felelossege lenne a hardvert ( irq, cpu, mamorialapok, minden ) korrekten "lekapcsolni" az exosrol, majd futni, es kilepeskor korrekten mindent visszaadni az exosnak, majd ret- tel visszaterni.

Ennek a modszernek megegy elonye lenne: mivel van egy sajat rendszerbovitonk ehhez, ezert annak lehetnek exos valtozoi, es egy ilyen exos valtozoban jelezni tudjuk a futo programnak, hogy visszatereses modon lett futtatva, nem pedig a hagyomanyos betoltokkel. Igy a program tudja majd azt is, hogy o most kilephet- e, vagy pedig mivel exos futtatta le, nem a :run rendszerbovito, ezert mar "nincs hova" visszaterjen hiszen o lett az AAP.

Ennek a modszernek tahat a vegeredmenye sztm. a kovetkezo lenne:

- egy atiratlan, hagyomanyos 5- os fejlecu program is futtathato lenne a :run rendszerbovito kommandunkkal ( de termeszetesen nem tudna kilepni, hiszen nem ugy lett megirva, de lefutna )
- egy kilepesesre atirt/megirt program is futtathato lenne a normal eddigi osszes betoltesi modunkon ( de termesztesen nem tudna kilepni, hisz hagyomanyos futtataskor "nem lenne hova", hisz megszunt az eredeti AAP ami futtatta )
- ha viszont a :run rendszerbovito kommandunkkal futtatnank egy olyan programot ami fel is lett keszitve ra, akkor a programbol siman visszaterhetnenk abba az AAP- be, amibol kiadtuk a :run- t





Vegeredmenynek pedig mindennemu mas program megvaltoztatasa nelkul pld. a kovetkezo kulonbseg lenne:

epdos- ban benavigalnek egy program konyvtaraba, ha ugye ott az adott konyvtarban beirom hogy:

:load batman.com

akkor a batman futtatasa utan, reszetelnem kell a gepet, ujra elinditanom az epdos- t, es ujra vissza kell navigalnom a batmanra az epdossal, vagy epp a batman utani jatekra

viszont ha el lenne keszitve ez a rendszerbovito, es a batman is fel lenne keszitve ra, akkor mikor a batmant futtattam a

:run batman.com

kommanddal, es kileptem belole, mondjuk esc hatasara, akkor ott talalnam magam az epdosban, ahol beirtam a kommandomat, fellephetnek egy konyvtarral a kovetkezo jatekra.


Ez persze a gyakorlatban nem sokat jelentene, hiszen csak 1-2 ilyen jatek lenne, de az elvi lehetosege meg lenne teremtve a dolognak.



Na hat ha rovidebb nem is lett, de osszeszedettebb es szakszerubb lett remelem.

Most jo lenne akkor ha valami exos guru akkor rabolintana, hogy jol gondolom ezeket, erdemes belekezdeni a megvalositasaba technikailag ertve, mert mukodni fog, vagy pedig valamit nem ertek, es ez nem fog mukodni.




Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 20:46:05
Hát elvileg talán meg lehetne csinálni, de minimum kell lefoglalni egy szegmenst, hiszen az egész nullás lapot el kell menteni. És videó memóriából is kevesebb fog jutni a programnak, hiszen ott vannak a megnyitott videolapok, és egyéb csatornák.

Szerintem egyszerûbb lenne egy autostartos EPDOS-t beraknod a konfigba :-)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 21:06:22

Hat egyreszt be van allitva termeszetesen az epdos autostart, de ott van a navigacio.

De hat nem is ez lenne a lenyeg, a dolog a basicbol is mukodne, 2 basic sor kozott lehetne lefuttatni egy jatekot/demot ily modon, ami szerintem allat lenne, mindig is hianyzott ...



Igen, technikailag mar erdekesebb a memoria szempontjabol, igazabol meg kavarog bennem hogy az exos mikor milyen szegmenseket hova tesz, mit kovetel, mit nyujt, rendszer memoria, alkalmazas memoria, megosztott lap, ilyen bovito, olyan meghajto, szal nem igazan latom at, hogy ilyen memoria szempontjabol hogy lehet majd ugy kavarni egy tetszoleges programmal ( legyen mondjuk batman, cauldron, sorcery, akarmi ) hogy meghagyjon mindent ami az exos, de fusson rendesen, es aztan visszaadjon mindent.

Ugy elvileg gondolkodva ugye lesznek szelsoseges dolgok, pld. egy 256K- s konfig 250K- ja tele van tomve rendszerbovitokkel, akkor nyilvan egy 5- os fejlecu mindent felulbarmolos kod meg mindig kepes lefutni, mig a :run majd nem fog tudni memoriat allokalni a programnak, es kiirja hogy futtasd :load -dal, vagy esetleg automatikusan megiscsak meghivja az load_module- t es akkor meg mindig lefutott, csak nem ugy ahogy vartuk, de hat nem volt ra memoria.

Ha meg ugy gondolkodunk hogy a mindenkori videoszegmensek elmentesehez van eleg exostol allokalhato szabad szegmens, es meg plusszban 1-2 szegmens amit esetleg meg a video szegmensen kivul hasznalt az alkalmazas, akkor meg elvileg atirhato ugy, hogy fusson, es mukodjon ilyen visszaterosen.

En sem gondolom hogy alkalmazasok tomegei lesznek majd ilyenek, de en irok ilyen demoeffekteket azok ilyenek lesznek, meg tervezek irni egy ilyen latvanyos arcade modu tetriszt, amilyenek amigan voltak anno, ha lattal olyat, az is igy tudna majd futni, meg 1-2 dolgot majd biztos atirna meg valaki, aki ert valamelyik hiresebb program lelkivilagahoz, es legfeljebb majd ennek a :run -os futtatasnak lesznek nagyobb rendszerkovetelmenyei.

Osszegeszeben mivel a programok kb 64kb- ot hasznalnak, es feltetelezzuk hogy a masik 64k nincs agyonrendszerbovitozve, akkor a nagyja program szerintem elvileg a maegoldhato kategoriaba kell essen.

Nem ?




Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 21:12:14
Ezt nem tudtam hova irni, es nem talalom search- el, ugyhogy itt kerdezem meg:

A kurzor F1 -re alakitasa a konfigokban huzalozott ? tehat melyik bovito csinalja, es lehet-e opcionalis, vagy ha az a bovito benn van, akkor cursor = F1 ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 21:17:49
A kurzor F1 -re alakitasa a konfigokban huzalozott ? tehat melyik bovito csinalja, es lehet-e opcionalis, vagy ha az a bovito benn van, akkor cursor = F1 ?
EPDOS HFONT-ja csinálja.
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.March.18. 21:46:59
Z80 System!

 Amit te akarsz csinálni, az már kicsit a multitaszkos operációs rendszer felé hajlik. Multitaszkos operációs rendszer esetén van az, hogy az aktuális rendszert megszakítja egy idôzítô, eltárolja a következô utasítás címét, a verem tartalmát és a regisztereket. Ezután kialakítja az új környezetet a korábbi (vagy újonnan induló) másik programnak, betölti a verem/regiszter/utasítást, majd megy a másik program.
 Ehhez az x86-os rendszereknél a processzornak vannak speciális utasításai, amely gyorsítja a folyamatot.

 Nem muszáj, hogy egyszerre több szál fusson, de a vezérlésátadás nagyon jól ki van dolgozva.

 Enterprise 128 esetén talán az a baj, hogy kevés a memória ehhez. Fôleg, hogy az EXOS-t ep64-hez fejlesztették. Ahhoz, hogy vissza tudjon térni az elôzô programhoz mind kettônek el kell férnie a memóriában. 1MByte vagy nagyobb bôvítés esetén már érdemes lenne írni új EXOS-t.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 21:48:45
Sot azon gpndolkodok, hogy meg lehetne azt csinalni, hogy a :run rendszerbovito mar elmenti az exos parametereit elore az alkalmazas betoltese utan, de meg mielott lefuttatna az alkalmazast,
es lehetne mondjuk egy olyan effektet berakni hogy a mindenkori aktualis exos kep feketebe lesotetul, szepen, fade effekttel, aztan lefutna az alkalmazas, es mikor visszaadja az alkalmazas a betoltonek a vezerlest,
akkor a betolto lesz az, aki szepen mindent visszapakol az exosnak ( lapok, megszakitas, lpt, stb. ) es persze elotte felfade- eli a kepet feketebol az exosnak.

Vagyis mivel a nagyja exos elmentest/visszatoltest ( plusz egy jo kis latvanyos exos kepernyo fade- elest ) ezzel a betoltobe raktunk, ezert a futtatando alkalmazasoktol elvart kovetelmeny a kovetkezo egyszeru pontokkal hatarozhato meg:

- fuss ugy, hogy csak exostol igenyelt memoriat mocskolj ossze ( ha neked pont olyan szegmens kell ami mar le van foglalva es nem szabad, akkor mentsd el/vissza oket exostol igenylet szabad szegmensekre )
- mielott visszatersz ret- tel a betoltohoz, a betolto program kod szegmenset tedd vissza a lapjara ( azert igy fogalmazok, mert meg nem tudom hogy melyik lapon is lesz a betolto kodja, ami ugye egy rendszerbovito)

es ennyi. ha egy alkalmazas ezt a 2 egyszeru feltetelt teljesiteni tudja, az futtathato lesz a :run kommandunkkal. raadasull ha valaki ir at/meg egy alakalmazast amit ilyen :run- nal is futtathatonak szeretne, akkor ugye lesz egy exos valtozoja ahhoz, hogy tudja, hogy ot most milyen modon szeretnek futtatni, es futhat ezert ugy, hogy teljesiti a fenti 2 feltetelt, meg ugy is hogy nem erdekli az egesz, es mindent felulir. ez esetben azt lenne ildomos megcsinali, hogy mondjuk olyankor nem is figyeli majd az esc- t igy nem elszallni fog az esc- re, hanem csak nem lep ki.

Jol gondolom azt a 2 pontos feltetelt, Zozo ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 21:53:02
Jol gondolom azt a 2 pontos feltetelt, Zozo ?
Jól.
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 22:03:12
Olyat lehetne még csinálni, hogy az 5-ös fejléc nem használt bájtjait felhasználni, pl. mondjuk eltárolni egy indítási címet, ami ha 0, akkor tudhatja a RUN, hogy ez egy hagyományos 5-ös program, nem lesz kilépés, felesleges erõlködni. Ha pedig nem 0, akkor ezt a pontot hívja meg, nem a 100h-t, így a programokban egyszerûbben lenne megoldani a "hogyan lettem indítva" kérdést, 100h-n indulva hagyományos mûködés, és a végén kilépés az EXOS logóhoz ugrás módon, az új címen indítva pedig kell lapozás, SP mentés, végén pedig kilépés ezek visszaállításával, majd visszatéréssel.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 22:06:46
Tuby128 :

pontosan nem ertem mit akarsz mondani, de nem hinnem hogy az en "vagyaimat" kellene valami jozan megfontolasok koze szoritani ...

egy ep konfig manapsag emulatoros, tetszoleges meretu ram van benne.

es hat vannak memoriabovitos konfigok, aki akarja meg tusja boviteni,
de egyebkent meg siman is sztm jonak kell lennie elvileg sok programnal,
de az mindegy is mert ugysem fogja ehhez atirni oket senki.
max lesz ajd 1-2 es kesz.

viszont a lenyeg az, hogy ha en ep- vel barhol vagyok, pld. basic/epdos/asmon/wp/exdos/heass vagy akarmi, amelyik tud rendszerbovito kommandokat kiadni, akkor az iment emlitett programok minden modositasa nelkul fogom tudni elinditani a demoimat, vagy a korabban emlitett tetrist. tehat mondjuk heassolok, vagy basicelek, es kejes orommel fogom beirni hogy :run eptris.com , ami elindit egy fullextras szines/szagos/digihangos/frames/teljeskepernyos tetrist mint ami amigakon volt, es ha jatszottam vele egyet, akkor nyomok egy esc- et, es irom a kovetkezo heass vagy basic sort... :)

persze mindezt lehetne siman is ugy, hogy azoknak a programoknak, amikek igy akarnek hasznalni, annak keszitenek egy rendszerbovito verziot, es kesz.
ami mar benne van az exosban.
de akkor azoknak a memoriaban kene maradni, vagy zozotools- al kihekkelni.
ez mennyivel jobb mar, hogy betoltodik, lefut, kilep... kvazi barhonnan... mint a nagyok ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 22:24:45
Quote
Olyat lehetne még csinálni, hogy az 5-ös fejléc nem használt bájtjait felhasználni, pl. mondjuk eltárolni egy indítási címet, ami ha 0, akkor tudhatja a RUN, hogy ez egy hagyományos 5-ös program, nem lesz kilépés, felesleges erõlködni. Ha pedig nem 0, akkor ezt a pontot hívja meg, nem a 100h-t, így a programokban egyszerûbben lenne megoldani a "hogyan lettem indítva" kérdést, 100h-n indulva hagyományos mûködés, és a végén kilépés az EXOS logóhoz ugrás módon, az új címen indítva pedig kell lapozás, SP mentés, végén pedig kilépés ezek visszaállításával, majd visszatéréssel.


Aham, ezek tetszenenek, kicsit aggodtam, hogy lehet- e majd kerdezni arra hogy letezik- e X exos valtozo, vagy hogy hogy lesz ez, de ha vannak ilyen nem hasznalt byte- ok, akkor szuper lenne.

Ehhez a fejlec manipulaciohoz vannak toolok, konnyeden megy ? En utoljara asmonnal csinaltattam ilyen fejleceket a file- ok ele, tinektek ez a fejlec manipulalgatas mar megy konnyen ? Vagy ezt valahogy ugy kepzeljem el, hogy lefordittatom majd az 5- os fejlecu vackomat az asmonnal, vagy akarmivel, es akkor egy hex editorban meg atirom az elejeben a byte- okat, es kesz ?

Mer ha igy lenne az kiraly...


Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 22:29:51
Legegyszerûbb, ha fejléc nélküliként fordítod, DB-ben adva meg a fejlécet
DB 0,5
DW programvege-100h
DW runcim
DB 0,0,0,0,0,0,0,0,0,0
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 22:31:05
Quote
EXOS logóhoz

Gondolom ENTERPRISE logo, igaz ? :)

Ja es vegulis az is jo otlet hogy ha a program ( fejlece ) mar tartalmazna a kileptetes modjat, akkor ha a program eredeti program, ami osszebarmolja az exost, akkor nem kell a le/fel fade effekt sem,
ilyenkor a :run egybol hivhatna az exos  load_modul -t, es csak egy wrapper lenne felette, ugyanaz lenne az eredmeny mintha :load -ot hivtunk volna,

viszont ha be van allitva akkor ugy mukodne mint korabban leirtam.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 22:35:39
Kerdes hogy az exos nem sipol- e be, ha nem nullakat teszunk a fejlecbe oda ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 22:41:07
Kerdes hogy az exos nem sipol- e be, ha nem nullakat teszunk a fejlecbe oda ...
Kipróbáltam, nem.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 22:47:32
hat akkor szupi, ezexerint mar "csak" ezt a rendszerbovitot kene megirni, es mar mehet is a :run -t kiszolgalni kepes 5- os fejlecu programok irasa.

namost lattam en hogy van valami "relokalhato rendszerbovito" tipus, ami arrol szol, hogy nem foglal le egy egesz szegmenst, es gondolom ennek a :run vagy meginkabb :call rendszerbovitonek ( nem tok donteni az egyik jobban kezreall a masik kifejezobb technikailag ) ilyen relokalhatonak kene lennie,
mert meretben ugye nagyon kicsi lesz, nem kene egy egesz szegmenst lefoglaljon... igaz ?

es ha igaz, akkor ilyet tudnak forditani az ep-s eszkozok ? neztem azt a relokalhato formatumot, hat nem mondanam hogy megertettem egybol... szoval ez a relokalhato rendszerbovito dolog tamogatott az asmon/heass satobbi ep- s forditok altal ? ezeket ti rendszeresen alkalmazzatok ? tehat egy kiprobalt mukodo dolog ?
Title: Re: Assembly programozás
Post by: endi on 2012.March.18. 22:47:54
én elég sok programom fejlécébe, oda a nullák helyére beírtam hogy ORKSOFT :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 22:54:40
Kicsit macerásan, de lehet az ASMON-nal relokálhatót, írtam errõl anno az Enterpressben. Meg talán még a GEN tud ilyet, de azt sose használtam  :oops:

Mondjuk ha elkészül, és jól mûködik, akkor ROM formában lesz a leghasználhatóbb, ha nem túl nagy, akkor esetleg hozzácsapva valamihez.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 23:01:13
aham... tehat akkor ne is pocsoljek olyasmivel mint a relokalhato rendszerbovito ( es az ahhoz szukseges relokalhato modul bitfolyama ), mert nem igazan hasznaljatok ti sem, hanem legyen mukodo eloszor egy sima abszolut ( vagy hogy is neveztek ) rendszerbovitokent, es majd akkor hozza lesz teve valami nagyobbhoz ?

meretben mit ertesz az alatt hogy "nem tul nagy" ? hat amire en gondolok az par bajt lenne csak, nem ? elmenteni par dolgot/visszamenteni par dolgot, meg az aktualis exos lpt- ben allitani a paletta szineket... gondolom ez majd jo kicsi lesz, nem ?

es egyebkent ha majd ossze kell fuzni valamivel, az majd binarisban lesz csinalva ? tehat mindegy mivel csinalnam ? vagy forras szinten lenne osszefizve ?


Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.18. 23:04:59
Forrás szinten, pl akkor majd nem C00A-ra kell fordítani, hanem ahol majd hely lesz a kiszemelt ROM-ban.
De ezt majd akkor kell kitalálni, hamár elkészültél mûködõ verzióval :)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 23:16:25

Hat ja, csak azt akarom hogy minnel kevesebbet kelljen majd atirni ha kesz lesz.

Igazabol legtobbet azzal fogok vacakolni mire megertem hogy pontosan hogyan is kommunikal az exos a rendszerbovitokkel, stb ...

Szal a rendszerbovito keretkod ...

Title: Re: Assembly programozás
Post by: Attus on 2012.March.18. 23:18:44
Kicsit macerásan, de lehet az ASMON-nal relokálhatót, írtam errõl anno az Enterpressben. Meg talán még a GEN tud ilyet, de azt sose használtam  :oops:

Mondjuk ha elkészül, és jól mûködik, akkor ROM formában lesz a leghasználhatóbb, ha nem túl nagy, akkor esetleg hozzácsapva valamihez.
A GEN az baromi jó!
Én sokat használtam, rekolálhatót is csináltam vele.
Csupán szokás kérdése.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.18. 23:22:33
Quote
A GEN az baromi jó!
Én sokat használtam, rekolálhatót is csináltam vele.
Csupán szokás kérdése.

oks, majd meglatjuk, ha keszen van, es megsem valami mellett fog megjelenni, akkor majd at kell terni relokalhatora ha nem akarunk egy szegmenst adni a betoltonek ( amiben ugye nem lesz grafika, tehat pici lesz ).
Title: Re: Assembly programozás
Post by: lgb on 2012.March.18. 23:43:46
Z80 System!

 Amit te akarsz csinálni, az már kicsit a multitaszkos operációs rendszer felé hajlik. Multitaszkos operációs rendszer esetén van az, hogy az aktuális rendszert megszakítja egy idôzítô, eltárolja a következô utasítás címét, a verem tartalmát és a regisztereket. Ezután kialakítja az új környezetet a korábbi (vagy újonnan induló) másik programnak, betölti a verem/regiszter/utasítást, majd megy a másik program.
 Ehhez az x86-os rendszereknél a processzornak vannak speciális utasításai, amely gyorsítja a folyamatot.

Szerintem ez kisse pontatlan; ilyen szempontbol a DOS (marmint pl MS-DOS) messze van a multitaskingtol, megis ott is adott, hogy pl Volkov Commander vagy barmi alol inditasz el vmit, akkor a program kilepese utan "visszakapod" a Volkov  Commander-t ott, ahol jartal. Sot, ha a VC-t pl command shell-bol inditottad, akkor VC-bol kilepve azt, stb. Imho erre vonatkozott (vagy hasonlora?) a kerdes. Ettol ez meg nem multitask, hiszen egyszerre egy program fut folyamatosan, "csupan" arrol van szo, hogy  mi kapja vissza a vezerelest, ha az eppen futo program vegrehajtasanak vege.

A multitask ezzel ellentetben tobb program kozotti gyors valtogatas (illetve tobb CPU/mag eseten hw szinten is lehet persze mar parhuzamositas!), akkor a user szemszogebol tenylegesen tobb program fut interaktivan is akar egyszerre, ami nem igaz a nem multitask rendszerekre. Bar a timer stb stimmel (mondjuk multitaskbol is van sok fajta, nem mindenhol timer van), ettol meg a fenti MS-DOS szeru pelda nem multitask, megis mondhatni, hogy tobb program van a memoriaban egyszerre, de ebbol csak egy 'fut' egeszen addig, amig az ki nem lep. Ebben mas ugye a multitask.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.19. 17:01:24
Hopp eszembe jutott valami, amitol kb. bukik/bukhat az az egyszerusitett definicio amit egy ujraindithato alkalmazasnak tegnap megfogalmaztunk, hogy azt neki teljesitenie kell. Ugye ez ket dolog volt:

- Oldja meg hogy a mar lefoglalt memoriaszegmensek epen maradjanak, vagy vissza legyenek allitva a visszaterese elott.
- Lapozza vissza a betolto szegmenset a megfelelo lapra. ( a betolto szegmens/lap kombot egyebkent mivel mar lesz sajat belepesi pontja a visszateresre alkalmas futtatasnak a legegyszerubb atadni majd a futtatott programnak regiszterben, es akkor nem kell huzalozni, kesobbiekben a betolto lehet barmely lapon es szegmensen )

De most a lenyeg az, hogy ezt a ket egyszeru feltetelt azert tudtuk meghatarozni, es azert nem kell ugy fogalmazni, hogy az alkalmazas mentsen el minden hardver allapotot amire csak az exos szamot tarthat, es mindent allitson vissza a visszaterese elott, mert ezt az allapot elmentest/visszatoltest a betolto megtenne helyette.

Namost ebbol az kovetkezne hogy mar egy megszakitasletiltott, lefade- elt lpt- ju, satobbi mindenrol lekapcsolt exost kapna az alkalmazas. Na de az alkalmazasok szoktak tolteni, meg esetleg egyeb modokon exost hasznalni, ehhez ahhoz. Ahhoz meg kell ( het ) nekik az exos lpt, meg ugy egyaltalan egy funkcionalo exos. Asszem meg csak ha a megszakitasokat letiltom, az exos akkor sem mukodik rendesen, nem frissul az lpt- je, nem tud tolteni bizonyos eszkozokrol, szal az exos lebenul, ha a betolto lebenitja, mielott az alkalmazast meghivna.

Jol gondolom ezt, zozo ?

Es ha jol gondolom, akkor mi itt a megoldas ? A betolto vegezzen csak egy sima exos hardver allapot elmentest, de ne allitson semmit az exos- on, es akkor igy hivjuk a programot, az majd letiltogat barmit, ha le akar, mi meg a betoltovel csak visszaallitjuk azokat az exos hardver parametereket, amiket elmentettunk es kesz ?

Ekkor mondjuk le kellene mondanunk a le/fel fade- elo exos lpt- rol ...

De egyebkent meg akkor meg nem az lesz a hiba, hogy en elmentek exos parametereket ( pld. stack pointer, lpt, akarmi ), amit meg igazabol a futtatott program elallitgat azzal hogy mindenfele exos funkciokat hiv, es mikor hozzam visszater, akkor en eppen hogy felulirom a lementett ertekekkel a korrekt ertekeket ?

Atlatod te ezt ? Hogy mondjuk nem, azok kozul amiket le kell majd menteni nem tud a felhasznalo program megvaltoztatni olyat, amit nem helyesre allitanek vissza. Vagy eppen hogy: hat igen, eleg ha csak mittomen egy grafikus csatornat megnyit, attol megvaltozik az lpt cime, es maris hulyeseget fog a betolto visszairni az lpt valtozokba, ha azt irja vissza amit a futtatas elott elmentett ?

Mert ha igy van, hogy ezek valos veszelyek, akkor gyakorlatilag vissza kell terni arra a szemleletre, hogy a betolto gyakorlatilag egy exos load_module helyettesito, ami direktben olvassa a csatorna adatokat, es ha a modul parameterei megfeleloek, akkor betolti es call- lal meghivja a belepesi cimet. ( ha meg nem megfeleloek, akkor rahivhat a load_module- ra hogy ne kelljen kezzel begepelni )

De a lenyeg, amirol itt most szo van, hogy akkor vissza kell helyezni minden exos hw allapot mentes/visszatoltest az alkalmazasra, es minden egyes alkalmazas maga kell megbirkozzon a feladattal.

Szal most mi van ? Vissza kell terni erre, vagy atlatod hogy az elmentendo parameterek nem fognak elvaltozni, ha a betoltott program exos funkciokat hiv ? Mert miert ne hivna, hat kell toltenie, vagy epp beleepul a megszakjaba, vagy akarmi.

Es ha esetleg nem is kell visszavaltani a "betoltott program felelos mindenert" szemleletre, az mindenkepp igaz, hogy a fade- rol le kell mondanunk, hisz nem benithatom le az exost a program meghivasa elott, igaz ?


Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.20. 14:11:44
Igen egy LPT mentés se árt (még több RAM kell), fade-t úgy lehetne ha utána nyitsz egy videólapot azt rakod ki 1-27-ig, aztán bezárod, így üres kép lesz az LPT-ben. Mert különben amikor engedélyezed a megszakítást a videókezelõ visszarakná a normál képet.

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.20. 19:37:43

Na tanulmanyozgatom itt az exos mukodeset, hogy minnel reszletesebb valaszt kapjak a korabbi kerdeseimre, es kozben felmerultek kerdesek bennem, leirom ide oket, hatha Zozo majd jol megvalszolja oket.

Az egy alapvetes ugye, hogy az exost ugy terveztek, hogy egyszerre egy alkalmazast szolgaljon ki. Raadasul ezt ugy valositottak meg, hogy nincs egy operacios rendszer shell, vagy ilyesmi, amibol az alkalmazasok elindulnak es ahova visszaternek, hanem az alkalmazasok egymasnak adjak at a stafetat, es valnak "current applications program"- ma, roviditve CAP- pa. Ha mi szeretnenek megis egy olyan CAP- ot ami felepitese vagy hasznalata soran alkalmas erre ( pld. egy basic interpreter CAP- ot, aminek ugye van egy parancsertelmezoje, vagy egy exdos interfeszt, aminek szinten van ), szoval szeretnenek egy ilyen CAP- ot egyfajta shell- kent hasznalni es elinditani belole masik programokat ( olyanokat amik eddig szinten CAP- pa valtak futasuk soran ) akkor azt kell megoldjuk, hogy a lefuttatott program ne valjon CAP- pa, hanem csak sima szubrutinhivassal hivodjon meg, majd terjen vissza az ot hivo CAP- ba. Vegyuk eszre, hogy ugye ezzel a futtatott alkalmazast exos szempontjabol a futtato CAP "reszeve" tettuk, amig a lefuttatott alkalmazas fut, es nem ter vissza az igazi CAP- ba, addig o latja el a CAP szerepet.

Valamilyen uton modon tehat egyutt kell dolgozzon a futtatott program az ot futtato CAP- pal, a futtatott programnak a futtato CAP egyfajta shell- je lesz, abban az ertelemben hogy ugye onnan indul es oda ter vissza, az operacios rendszert o ( azzal szemben mintha o is CAP- pa valna a futtatasakor ) a futtato CAP modositasai, beallitasai utan erzekeli, gondolok itt olyanra, hogy ha az CAP altal vezerelve az exos epp jatszik le egy hangot, akkor azt o mar ugy kapja meg, ha a CAP altal vezerelve az exos kepernyojen meg van jelenitve valami ( pld. basic,wp,epdos ) akkor o azt mar ugy kapja meg, stb.

Erre oly modon lehetne adni valami altalanos megoldast, hogy ha feltetelezzuk hogy a futtatott program egy tipikus demo vagy jatek, ami az elso inicializalasa utan ugyis lekapcsolja majd az exos- t es soha tobbe nem is akarja a futasa soran majd hasznalni. Ekkor lehetne a korabban emlitett exos "ki/be kapcsolo" altalanos funkciot tenni a betolto rendszerbovitobe. De hat egy ilyen visszaterosen lefuttatott program miert ne lehetne egy exos alapu program, aki a futasa soran aktivan hasznalja az exos- t. ( Viszont meg mindig nem egy rendszerbovito, mert visszaterese utan nem marad rezidens ) Arrol nem is beszelve, hogy ezeknek a visszateresre alkalmas programoknak az altaluk lefoglalt memoriakat fel kene szabaditania visszateres elott, kulonben tobbszori futtatas eseten elfogyhat a memoria.

Mindezeket osszeteve arra a kovetkeztetesre jutottam, hogy nem nagyon kell a betoltonket ellatni semilyen funkcioval, a betoltott program a betoltonek es igy a CAP- nak egy sima szubrutinja lesz es kesz. Minden mas dontest az alkalmazas hozhat meg, es meg is kell hoznia. Hogy neki fontos- e, hogy ot most milyen CAP hivta meg ( wp, basic, epdos, vagy mi ), hogy o most hogy akar mukodni, lekapcsolja a hardvert az exosrol, es onmagaban fut, vagy epp exos hivasokkal akar operalni, mondjuk nyitva egy videolapot, es arra dolgozva. Termeszetesen mindent amit lefoglalt, vagy elallitott, vissza is kell adja az exosnak, ill. vissza is kell allitsa, mielott visszater a betoltohoz, es azon keresztul a CAP- hoz.

Azt majd meglatom hogy meg lehet- e oldani, hogy rendszerbovito command string- kent megvalositva lehetseges lesz- e egy altalanos exosrol lekapcsolas/visszakapcsolas funkciot megvalositani, amit majd felhasznalo fele nem hirdetne a betolto rendszerbovito, de vegrehajtani tudna, es ezt arra lehetne hasznalni, hogy a legaltalanosabb esetre megis lenne tamogatas a rendszerbovitoben, es annak ellenere hogy a betolto semmit nem fog csinalni a tenyleges betoltesen es a call- lal torteno meghivason kivul, a meghivott program megteheti majd azt, hogy exos hivasokkal betolti a szukseges tovabbi reszeit/adatait, majd ha ez megtortent, akkor meghivja azt a rendszerbovito kommand stringet, ami majd lefade- eli az exos kepet, es lementi/lekapcsolja az exosrol a hardverallapotot, aztan fut ahogy akar, majd visszateres elott meghivja az exost visszaallito rendszerbovito kommandot, es visszater ret- tel a betoltobe. Egeszen biztos hogy mivel ezek hivasok lesznek, ezert peldaul sp elmentese/visszatolteset nem fogja tartalmazni ez az altalanos kod, es lehet hogy lesz mas ilyen is amit nem lehet majd megoldani, de a nagyja funkcionalitas elerheto lesz. Evvel ugya majd jatek kozben is meg lehet csinalni, hogy mondjuk visszakapcsolja az exost mukodove vele, betolti a kovetkezo palyat, majd ujra lekapcsolja vele az exost, es fut tovabb a jatek. De ez mar csak egy kenelmi funkcio lesz, amit majd vagy hasznal a betoltott program vagy nem, vegeredmenyben, ezzel vagy enelkul, minden a lefuttatott alkalmazas felelossege lesz.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.20. 19:52:41
Na elobb lvileg kerdeseket akartam irni, de aztan eltertem megis a gondolataimra, tervezgetesre. Jojjenek hat a kerdesek:

-A System Reset exos funkcio c regiszterben egy parametert var, ami megadja hogy a rendszer milyen reszei reszetelodjenek, dokumentacioja a kovetkezo:

b0 ... b3
must be zero

b4 - set
Forcibly de­allocate all channel RAM, and re-initialise all devices. User device will be retained.
b5 - set
As bit 4 but also re­link in all built in and extension devices, and re­initialise system extensions. User devices will be lost. Device segments are not de-allocated.
b6 - set
De­allocate all user RAM segments.
b7 - set
Cold reset. This is equivalent to switching the machine off and on again. All RAM data is lost.

Ebbol szamomra az kovetkezne akkor hogy a bitek funkciokat jelolnek, amiket en vagy kapcsolattal kivalaszthatok, es azokat a funkcio majd elvegzi. De a b5- os funkcio leiras szerint tartalmazza a b4- et is. Tehat akkor nem kell a biteket vagykapcsolatba hozni, hanem kulon kulon kizaroan hasznalni. De az exos hasznal pld. 60h- as parametert ami a b5 es b6 egyuttesen. Tehat megis van amelyikeket egymas melle rendelhetunk. Most akkor mi van, bizonosakat kulon kell hasznalni, bizonyosakat meg egymas melle lehet rendelni ? Es melyikek zarjak ki melyikeket ? Miert nem irja le ezt az exos leiras, ha mar egyszer ilyen szepen ledokumentaltak ?
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.20. 20:16:11
Mikor az exos egy "New applications program" modult tolt be, akkor mikor ennek a programnak adja at a vezerlest ( vagyis mikor az uj modul lesz a CAP ), akkor az exos nem olyan system resetet hajt vegre mint amilyet egy rendszerbovitonek kell vegrehajtania a CAP- pa valasakor. Egy rendszerbovitonek 60h -as parameteru system resetet kell vegrehajtania, ha CAP- pa akar valni. Az exos azonban a "New applications program" modul betoltese utan csak egy 20h -as parameteru system resetet fog vegrehajtani azert, hogy a user memoria szegmensek ne szabaduljanak fel ( gondolom azert, hogy azok a szegmensek ne szabaduljanak fel, ahova betoltotte a programot ).

Namost ezt en nem ertem... ha igy tesz, akkor a regi CAP altal lefoglalt user memoriaszegmensek meg le lesznek foglalva azok mellett, amikre a "New applications program" be lett toltve. Tahat a "New applications program" modulbol szuleto uj CAP "hatranyban indul" ahhoz kepest mintha rendszerbovitobol valna CAP- pa, olyan user szegmensek lehetnek lefoglalva, amiket meg a regi CAP hasznalt. De a regi CAP- hoz ugye mar nem lehet visszaterni, tehat teljesen feleslegesen maradnak lefoglalva. Esetleg indulhatna minden olyan CAP, ami "New applications program" modulbol lett betoltve, hogy felszabaditja az elozo CAP user szegmenseit. Ha tudna hogy melyek ezek. De tudtommal nem tudja. Es ha meg tudna is, milyen mar az, hogy az uj CAP- nak ugy kell indulnia, hogy tisztogat a regi CAP utan ?Ezt jol latom ? Ilyen benan lenne ez megtervezve ? Rendszerbovito CAP- pa valasanal nem is igy van ez, de a  "New applications program" modul toltesenel igy van. Ha jol ertem ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.20. 21:45:37
Írja a NAP betöltésnél, hogy amikor a méret alapján foglal RAM-ot, felhasználja az elõzõleg esetleg foglalt User szegmenseket, így innentõl nem lehetséges vissza térni az elõzõ programhoz.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.20. 22:28:18
Quote
Írja a NAP betöltésnél, hogy amikor a méret alapján foglal RAM-ot, felhasználja az elõzõleg esetleg foglalt User szegmenseket, így innentõl nem lehetséges vissza térni az elõzõ programhoz.

Hmmm... olvastam en is, de arra valahogy nem talaltam direkt utalast, hogy a CAP altal mar lefoglalt user szegmenseket felhasznalna, user szegmensekrol van szo, amit o allokal a betolteshez, mar korabban CAP altal allokalt szegmensekrol nem olvastam.

A "nem tud visszaterni" gondolatra meg arra gondoltam, hogy a nullaslap-szegmenst irja felul a betoltesnel ( kiegeszulve a frissen allokalt user szegmensekkel ), amelyek kozul ugye a nullaslapszegmens miatt nem tud visszaterni.

Oks a toltest csak ezek utan irja, de konkretan akkor sem emliti hogy a CAP altal mar foglalt szegmenseket felhasznalna,

arrol nem is beszelve, hogy van nekem egy 16 kilobajtos NAP- om, meg van 64K mar lefoglalt user memoriam, megha fel is hasznalja ( de nem latom a doksiban ) akkor se nagy boldoksag a masik korabbi CAP altal lefoglalt 48K- to lelesni, mikor pedig a korabbi CAP- hoz mar nem terhetek vissza, es mikor majd atvaltok egy rendszerbovitohoz, akkor majd ugyis kinullazodik az is.

Szal en tovabbra sem ertem ezt, hogy egy NAP mer nem ugyanannyi memcsot hasznalhat mint egy rendszerbovito, ha egyszer a NAP is egy teljes erteku CAP- pa valik ...

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.20. 23:18:19
Azt tudja valaki, hogy vannak- e kialakult szokasok arra nezve, hogy egy rendszerbovitot konnyen lehessen rambol futonak es rombol futonak is forditani ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.20. 23:41:23
Azt tudja valaki, hogy vannak- e kialakult szokasok arra nezve, hogy egy rendszerbovitot konnyen lehessen rambol futonak es rombol futonak is forditani ?
Mi ebben a nehéz?
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 07:30:41
Quote
Írja a NAP betöltésnél, hogy amikor a méret alapján foglal RAM-ot, felhasználja az elõzõleg esetleg foglalt User szegmenseket, így innentõl nem lehetséges vissza térni az elõzõ programhoz.

Ezt ugy ki lehetne probalni, hogy futtatunk valami rom extension- os CAP- ot, es azzal lefoglaljuk az osszes szegmenst (peldaul egy bovitos rajzprogramban megnyitunk nagy lapokat, vagy ilyesmi, hogy beteljen a memoria.). Ezutan ha ugy van ahogy mondod, akkor az exos meg be kene tudjon tolteni es elinditani tetszoleges meretu NAP- ot ( mert felhasznalja a CAP mar leallokalt user szegmenseit ), raadasul a NAP amit lefuttatunk szinten olyan kene legyen, hogy tudjon allokalni user memoria szegmenseket, es akkor meg kene szamolni hogy hanyat tud beallokalni.

Igy valaszt kapnank arra is, hogy valoban felhasznalja- e az exos a CAP altal mar lefoglalt szegmenseket,
es arra is, hogy esetleg a tobbit meg valami modon felszabaditja- e ( mikozben mondjuk felhasznal bizonyosakat a betolteshez, a maradekot mondjuk felszabadithatna, es ekkor mar ugyanazokkal a memoria feltetelekkel indulna NAP- bol is egy CAP mint bovitobol ).

Igaz ?

Ha ugyis most megtanulok rendzserbovitot irni, lehet irok is erre egy bovitot ( ami csak siman leallokalja az osszes memoriat ) es egy napot ( ami ugyanezt teszi ), es mindketto kiirja mennyit tudott leallokalni. Es akkor majd jol meglatjuk mi lesz az eredmeny...

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 08:02:12
Quote
Mi ebben a nehéz?

Hat ha nem is nehez, torodni kell vele, az pedig az (ha jol ertem), hogy

a rendszerbovitok irasakor ( ha tudjuk hogy rombol es rambol is futtatni akarjuk ) mar elore gondolni kell erre, es az irhato memoriateruleteket (valtozoteruleteket) akkor kulon kell valasztani a kod tobbi reszetol (kod+csak olvashato memoriateruletek), es egymas melle, egy folytonos memoriablokkba kell szervezni oket ( nem lehetnek osszekeveredve a kod tobbi reszevel ),
es akkor a blokk meretenek megfelelo memoriateruletet leallokalni a rom bovito futtatasakor a rom allokalo akciokodjanal, es ezt majd IY tartalmazni fogja, mikor a romhivasok megtortennek az exos reszerol akkor ha rombol futunk,
ha nem rombol futunk, akkor minden egyes akciokod megerkezesekor az IY- t fel kell tolteni valami ram terulet cimevel, ami mondjuk abszolut ram bovito eseten lehet a kod+adat terulet utanra mutato pointer,
relativ bovito eseten meg most hirtelen nem is tudom, honnan szedjuk majd a memoriat hogy ne egy egesz szegmens lefoglalasaval jarjon, de ez nem is anynira fontos mert ilyet nem is nagyon szandekszok egyenlore.

Namost fentihez ket dolog is kell akkor:

Valtozo teruleten belul ( tehat barmi, amit irni is akarok ) nem szabad semmit sem forditasi idoben eloallt abszolut cimen elerni, hanem mindent a valtozo terulet blokk elejehez kepesti relativ cimmel kell elerni az IY regiszter felhasznalasaval,
masreszt valahogy az assembler forditoban kepezni kell tudnom a valtozoim ( valtozoterulet elejehez kepesti ) offsetjet ugy, hogy maguk a valtozok ne keruljenek bele az object kodba, hisz azok majd vagy itt lesznek, vagy ott lesznek, attol fuggoen, hogy rom vagy ram verzio fut, es mondjuk rom eseteben minek legyen a valtozoterulet a bovito kodjaban, ha ugyis kulon allokaljuk le, tehat ehhez a tenyleges kodba fordulas nelkuli valtozo offset kepzeshez kene valami assembler ficsor, amit en valszeg nem ismerhetek, mert ugye egy db, vagy dw ugyan noveli a cimszamlalot, de a targykodot is noveli, belefordul, nekem meg az kene hogy a cimkek ertekei ugyen kepzodjenek, de a targykodba ne forduljon bele a valtozom. Es jo lenne ha az offseteket nem kene nekem ilyen EQU- kkal kepeznem, mondjuk oly modon hogy szep sorban adogatom a valtozok meretet egymas utan EQU- kkal ossze.

A masik hogy egy rendszerbovito ahhoz hogy az IY erteket felulbiralja akciokod erkezesekor ( leven ha nem rom a rendszerbovito akkor IY erteke undefined ) meg kene tudnom, hogy en most rom rendszerbovito vagyok vagy ram. Ha mondjuk nem rom eseten IY- ban mondjuk specialis ertek lenne vagy ilyesmi akkor nem lenne gaz, de mivel undefined, ezert valahonnan mashonnan kell kitalalni.

Lehetne hogy ketszeri memoria irassal/olvasassal eldontom hogy ram vagy rom vagyok- e, vagy ha csak abszolut rendszerbovitok kozott kell donteni, akkor EXOS_ROM feliratbol lehetne talan donteni ( mert ha jol emlexem ram bovitonel az EXOS_ROM felirat helye fixen ki van nullazva exos altal ), de egyiket sem erzem igazan elegans modszernek, raadasul meg mindig nem tudom hogy ha ramban vagyok, akkor most abszolut vagy relativ vagyok- e ( nezegessem a PC tartalmat, es ha c00ah akkor abszolut, egyebkent meg relativ ? ), marpedig IY feltoltese fugg attol hogy abszolut vagy relativ rendzserbovito vagyok- e, meg akkor is, ha mar legalabb azt tudom, hogy nem rom.

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 09:21:21

Heass -ban szeretnem az auto CAPS -ot is kikapcsolni, de a konfigja azt nem menti el, erre van valami ?

Heass -ban szeretnem a border color- t, es a fejlec color- t allitani. van ra lehetoseg, akar hekkelos modszer ?

Es ez mar eleg off, de van valami tool, ami kiirja az ep szinek kodjait ? Tehat hogy 0-255 szin kozul melyik meylik ? grafikusan ertem, hogy mittomen rajzol egy kockat es beleirja h az a 38- as szin.

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 09:28:21

Meg meg az sem volna rossz, ha allitodna a cursor soranak szine ... tudja valaki hogy az vajon miert nem lett belerakva, vagy nezte mar valaki, van esetleg belole olyan verzio, csak nem pont az ami a romomban van, stb. ?
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 09:40:34
Ha emulatorbol inditok heass- t akkor angol a menum, ha a bovitett gepemrol, akkor magyar. a setupjaban nem latok nyelvi opciot, ez valami ket kulon heass verzio lehet ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 09:54:18
Ha emulatorbol inditok heass- t akkor angol a menum, ha a bovitett gepemrol, akkor magyar. a setupjaban nem latok nyelvi opciot, ez valami ket kulon heass verzio lehet ?
Igen, külön ROM fájlok.
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 09:56:38
Es ez mar eleg off, de van valami tool, ami kiirja az ep szinek kodjait ? Tehat hogy 0-255 szin kozul melyik meylik ? grafikusan ertem, hogy mittomen rajzol egy kockat es beleirja h az a 38- as szin.
Van SZCLXCHR.ROM-ban benne van a színkódkeresõ.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 10:25:30
Quote
Van SZCLXCHR.ROM-ban benne van a színkódkeresõ.

Es ilyen rom hol van ? :) Emuban nincs, kersesre nem talal ...

Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 10:38:57
Es ilyen rom hol van ? :) Emuban nincs, kersesre nem talal ...
ep28.hu Util programcsokor :-)
Title: Re: Assembly programozás
Post by: Povi on 2012.March.21. 12:58:22
Z80 System!

Tetszik ez az elgondolásod, amit kitaláltál, hogy a NAP ne vegye át teljesen az uralmat a gép fölött, hanem csak RET szerűen visszatérjen a hívó (pl. IS-BASIC) alkalmazáshoz, mint pl. PC-n a Norton Commander-hez.

Viszont miért rendszerbővítőben gondolkozol?

Én biztos úgy csinálnám, hogy magát az EXOS-t írnám át úgy, hogy lekezelje ezt az egész dolgot. Ha nincs elég memória, akkor simán, EXOS 2.1 kompatibilis módon futtatná az 5-ös fejlécű programokat, ha viszont van elég memória, akkor pedig a te elgondolásod szerint, CALL-RET szerűen. Persze lehet, hogy bonyolultabb belenyúlni az EXOS-ba, nem tudom, de nekem ez szimpatikusabb. :-)

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 13:40:24
Quote
Viszont miért rendszerbővítőben gondolkozol?

Hat egyreszt eleg tapasztalatlan vagyok exosilag, masreszt az exos az ugye egy rom, technikailag is nehezebb ezert berhelni a belet, de megha nem is lenne ( hanem mittomen az egesz exos rendelkezesemre allna forras szinten ), akkor se ertek en ahhoz elegge, hog nekialljak ilyet bele hekkelni, a kerdeseimbol lathatod, hogy egy csomo dolog nincs meg bennem letisztulva, es nekunk csak annyi kell, hogy az adott CAP tudjon kiadni egy call hivast egy NAP- ra. Az meg az exos rendszerbovito interfeszen keresztul teljesen megoldhato, kenyelmesen forrasbol programozhato.

Az ilyen visszateros, nem feltetlen onallo CAP- pa valni akaro programok szama ugyis elenyeszo lesz, ha az exosba integralnank csupan annyi lenne a tobblet, hogy barhonnan kiadott exos load_module hivas ily modon mukodne. Tehat nem kene begepelgetni egy rendszerbovito parancsot ott, ahol van menupont modul betoltesehez ( epdos,wp,basic,stb. programokban ugye van betolto menupont, billentyufunkcio ).

A rendszerbovitos megvalositas kb. egyetlen hatranya az lesz, hogy ezekben a programokban is be kell majd gepelni a rendszerbovito parancsot. Az elonye ennek meg az, hogy el lesz kulonitve a rendszertol, explicit lehet a normalisat vagy ezt az uj funkciot hasznalni. Tehat ha mondjuk egy programban meg akartak irni a visszateros mukodest, de az mondjuk egy masik konfiguracion nem mukodik, akkor ha exos babralassal lenne megcsinalva, akkor azon a konfigon az a visszaterosre modositott exe mehetne a kukaba, mert az exos mindig felismerne hogy van benne visszateros belepesi pont, es akkor azon probalna futtatni, pedig ezen a msik konfigon ugye rosszul mukodik a visszatereses verzioja a programnak. Szal ilyenkor a rendszerbovitos verzioban egyszeruen nem a rendszerbovitovel toltik majd be, hanem a sima modositatlan exos loaderrel.

Szal az exosba epitett funkcioval valoban frankobb lenne, es egyetlen program felhasznaloi interfeszet sem kellene modositani hogy legyen menupont a visszatereses inditasra, vagy egyetlen programban sem kene kezzel gepelgetni be a rendszerbovito parancsot, viszon egy visszateros exe igy forszolva lenne visszateros inditasra, amelyek pedig igen bizonytalanok teszteletlenek lesznek eloszor, nem beszelve hogy csak elenyeszo szamu lesz beloluk.

Title: Re: Assembly programozás
Post by: Povi on 2012.March.21. 13:54:01
EXOS visszafejtés nincs meg? Könyvben is megjelent. Bár az is lehet, nem a 0. szegmensen van az 5-ös fejlécű program betöltésének kódja... És lehet, hogy nem is férne bele 32kB-ba az új EXOS...

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 14:02:58

De megvan, epp eligertem valakinek, hogy ha hazamegyek elhozom es odaadom neki. Megvan a neten is.

De ha a technikai kerdeseket nem nezzuk, akkor is ott van az elvi kerdes, hogy amint igy modositottuk az exost, nem lehet valsztani hogy milyen modon futtassunk egy programot, amit mindket modon lehet inditani.
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 14:13:44
Ha majd rendben mûködni fog a rendszerbõvítõs verzió, akkor majd belebütykölöm az EXOS 2.4,5,6... valamibe :-)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 14:28:02
Hat tolem igy is lehet, csak akkor ha kompatibilitasi problema lep fel, akkor kell szerezzen az urge egy olyan verziot is, aminek a headerebol ki van torolve a visszateros belepesi pont.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 15:08:41
Valaki dobjon mar meg egy peldaval, hogy kell az "alapertelmezett csatornara kiirni egy sor szoveget" ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 15:56:06
Valaki dobjon mar meg egy peldaval, hogy kell az "alapertelmezett csatornara kiirni egy sor szoveget" ...
Code: ZiLOG Z80 Assembler
  1. LD A,255
  2. LD DE,SZOVEG
  3. LD BC,HOSSZ
  4. EXOS 8
  5.  
  6.  
  7. SZOVEG DB "ABCDEF",13,10
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 16:04:09
hmm... en a 29- es exos valtozobol visszakert csatornaszamra probalkoztam ... most se tom mer nem mukodott ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 16:18:50
en a 29- es exos valtozobol visszakert csatornaszamra probalkoztam
Az a EDITOR videó lapja, ha van olyan megnyitva. Az alapértelmezett csatorna száma a 4-es változóban van. De erre van kitalálva a 255-ös csatorna, hogy ne kelljen ezzel neked foglalkozni :-)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 16:22:59
es mi az az EDITOR ? a WP ?
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 16:26:53
Mi a kulonbseg a db es a dm assembly franctudjamik kozott. ez gondolom nem mnemonik. forditasvezerlo baszas ...

Szal mi a kulonbseg koztuk ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.21. 16:29:53
es mi az az EDITOR ? a WP ?
Editor (http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/editor/)

A WP egy olyan program ami az operációs rendszer alapvetõ szövegbeviteli eszközét használja, azaz az EDITOR csatornát. (Ennek PC-n MS-DOS-ban az EDLIN felel meg.)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 19:08:33
makrohasznalat kene peldaban, tobb parameteres ( legalabb ketto ) ...

hogy hova kell kukac, hova nem kell kukac, ilyesmi ... nem nagyon akar lefordulni ...

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 19:09:29
tehat egy pelda makro felvetel 2 parameterrel, es annak meghivasa ami kene ...
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.21. 20:12:38
Megvan a makro, mar nem kell, nem gondoltam volna, hogy egy cimke fogja azonositani a macrot, indenaron a macro pzseudo utan akartam tolni a macro azonositojat ...

Elenben en ugy tudom hogy a heass a legfejlettebb szerkesztoju ep assembler ... ennep pc- sebb jellegu cucc nincs ep- n ? Mint egy notepad, vagy ilyesmi ? Beszurasok, editalasi funkciok ilyen megszokott pc- s jelleguek ? Szal a heass a maximum ?
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.22. 09:07:15

Az ilyen integer kodokat milyen formaban tartjuk nyilvan, mint pld. a user exos valtozok azonositoja, vagy a file modul azonositok ?

Tehat ha en holnap fel akarok venni egy exos valtozot vagy modul azonositot, nyilvan abban a range- ben amit az exos megenged, akkor vajon honnan tudhatom, hogy olyan azonosito mar nem foglalt masra ?

Mert egy rosszul megvalasztott ilyen id- akkor elkezd terjedni ( akarcsak nalam ) file- ok formajaban, vagy hasznalat formajaban, es nem olyan trivialis megvaltoztatni aztan oket, mert jajj, mondjuk a modul azonositom ugyanaz amit a hea hasznal, vagy valami zeneformatum, vagy akarmi...

Title: Re: Assembly programozás
Post by: Povi on 2012.March.22. 09:38:47
Az ilyen integer kodokat milyen formaban tartjuk nyilvan, mint pld. a user exos valtozok azonositoja, vagy a file modul azonositok ?

Tehat ha en holnap fel akarok venni egy exos valtozot vagy modul azonositot, nyilvan abban a range- ben amit az exos megenged, akkor vajon honnan tudhatom, hogy olyan azonosito mar nem foglalt masra ?

A jelenleg használt rendszerváltozókat Zozo itt gyűjtötte össze:
http://enterprise.iko.hu/variables.htm
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.22. 09:42:35
Fájltípusok is készülõben.
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.22. 09:47:10
Tok jo... :) Verprofik vagytok ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2012.March.22. 10:18:20

Eszembe jutott +1 erdekes aspektusa ennek a visszaterosen lefutos mokanak ... ami lehet hogy exosistaknak trivi, de nekem most jutott eszembe ...

Hogy mikor majd a betolto betolti a visszaterosen lefuttatando programot, akkor majd jol nem hasznalhatja a nullaslap szegmenst, hiszen azon ( es meg opcionalisan masikakon ) a CAP terpeszkedik.

Vagyis vagy azt teszem, hogy betoltesnel atmasolom a nullaslapszegmenst egy exostol allokalt szabad user szegmensre, es akkor mar ratolthetem a nullaslapszegmensre ( es opcionalisan masik user szegmensekre ) az uj NAP- ot ( ami ugye onallo CAP- pa sohasem fog valni, csak egy kicsit a helyere all ), es ugyanez visszafele, a NAP kilepese utan vissza kell menteni a CAP nullaslap szegmens adatait,

vagy esetleg nem masolom le az egesz nullaslapszegmenst, csak az elso 100h byte- ot masolom at arra az exostol allokalt uj szegmensre, amire ratoltom a NAP elso 16K- jat, es aztan erre a szemensre lecserelnem a nullaslapszegmenst a nullas lapon.

Kerdes hogy ez mennyire okozna inkompatibilitast ? Tehat mennyire kovetelik meg a programok hogy igenis a nullaslapszegmens legyen a nullas lapon, ne csak egy olyan masik szegmens, ami tartalmazza azt a 256 byte- ot az elejen ami kell a rendszernek ?

Title: Re: Assembly programozás
Post by: Z80System on 2012.March.22. 11:12:11
Sot, elobbihez meg azt, hogy tulajdonkeppen nem is inkabb a programok mennyire kovetelik meg, mert azok ugyis ugy lesznek megirva/atirva hogy alkalmazkodjanak az uj szabalyokhoz,
hanem maga az exos, mikor hivkodjuk, ilyesmi, piszkalja a nullas lapot ? tehat ugy van vele, hogy ugysem kapcsolja azt el senki, hidegreszetnel beall, es soha tobbet nem bantja se exos, se mas ( altalaban ertve ),
vagy igenis az exos allandoan lapozgatja vissza a nullas lapra a nullaslapszegmenst, es ha en azt lecserelem egy al nullaslapszegmensre, akor mittomen exos hivasok utan az elallitodik onnan, vagy ilyesmi ?

Vagy pedig lecserelhetem, ugysem piszkalja azt majd semmi, foleg nem az exos, a ritka kiveteleknel, mikor az alakalmazasok allogatjak, akkor meg majd at lesz irva az app, ha kell belole kilepos verzio ?

Title: Re: Assembly programozás
Post by: Zozosoft on 2012.March.22. 11:19:55
A csere után BFFC-re be kell írni a nulláslap számát, és akkor az EXOS nem veszi észre. Ezt csinálják az EP64 kompatibilis átirataim 64-es módban, a rendszerszegmens elejére költöztetik a nulláslap szükséges elejét, így a nulláslap felszabadul, meg lesz a szükséges 48K szabad memória. Resetnél meg vissza csinálja a költözést.
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.October.29. 06:01:10
Az EP gépi kódú programokban láttatok-e már olyat, hogy a dinamikus változók tárolására a vermet használja, méghozzá oly módon, hogy az IX vagy IY regiszterek a báziscímek, és ahhoz képest helyezkednek el változók?

PL: (Zárójelben az IX-től való byte távolság van)
0200 00 ; "üres" - SP ide mutat
0201 0A ; 8bites "perc" változó (-3.)
0202 04 ; 8 bites "óra" változó  (-2.)
0203 12 ; 16 bites "év" változó felső byte  (-1.)
0204 20 ; 16 bites "év" változó alsó byte - IX ide mutat (0.)

És akkor a kód
LD L,(IX+0)
LD H,(IX-1) ; "év" változó betöltése a HL regiszterbe
ADD HL,1 ; "év" növelése 1-gyel
LD (IX+0),L
LD (IX-1),H ; "év" változó visszatöltése a memóriába

Azt akarom ezzel kérdezni tehát, hogy a Z80-nál ez a fajta veremhasználat mennyire volt szokásos?

Ha igen, akkor a következő kérdésem, hogy szubrutinhíváskor csinálnak-e ilyet?

 PUSH IX  ;Régi referenciapont eltárolása
 LD IX,SP ; Új referenciapont felvétele a verem következő üres pontjában
 PUSH DE ; néhány subrutin változó átadása
 PUSH HL ; szintén átadás
 CALL subrutin ; Visszatérési pont a verem tetején

;majd visszatérés
 RET
; ezután visszaállítás
 LD SP,IX ; A hívás előtti stack visszaállítása
 POP IX  ; A hívás előtti referenciapont visszaállítása


Na ki mit tud ezzel kapcsolatban mondani? Zozo? István?
Title: Re: Assembly programozás
Post by: lgb on 2012.October.29. 09:32:10
Quote
Az EP gépi kódú programokban láttatok-e már olyat, hogy a dinamikus változók tárolására a vermet használja, méghozzá oly módon, hogy az IX vagy IY regiszterek a báziscímek, és ahhoz képest helyezkednek el változók?

Szerintem ez inkabb magasabb szintu programnyelveknel szokas, bar nyilva jol jon pure asm-ban is, ha olyan trukkos dolgok kellenek mint rekurzio stb. Peldaul a mostani jatszadozasom, ahol az sdcc C fordito (ami tud Z80-ra kodot generalni) kepes legyen EP-re alkotni valamit: ott egy primitiv programnak (mondjuk hasznaljon valami chat/string output-ot meg olvasson billenyuzetet) azt varja, hogy a putchar es getchar rutint implementald, ha ez megvan akkor std printf() stb menni fog csupan ezzel a ket fuggvennyel, amit neked kell megirnod viszont. No, ezt persze assembly-ben csinalom, EXOS hivasokkal, amde itt pl a C fordito miatt tartanom kell magamat a konvekciohoz: azaz pl putchar eseten a kiiradno char a veremben lesz, ami C szinten kb igy definialhato: void putchar (char data). (visszateresi ertek - ami mondjuk putchar-nal nincs, de getchar()-nal igen - meg siman pl az L regiszterben kell atadni, felteve ha az sima byte-ban reprezentalhato ertek.

Quote
...stb...
 LD SP,IX ; A hívás előtti stack visszaállítása
 POP IX  ; A hívás előtti referenciapont visszaállítása

Na egen, pl az altalam implementalt putchar() fuggveny, amit aztan sdcc forditott cucc stdio-ja kepes hasznalni:

        ; THIS IS putchar() function for the C runtime
        .globl  _putchar ; C syms are underscored in assembler
_putchar:
        push   ix ; SDCC uses IX to access params in stack. you must save it
        ld      ix,#0 ; ... and use ix=sp since Z80 lacks of sp relative addressing
        add    ix,sp
        ld      b,4(ix)
        ld      a,#MY_VIDEO_CHANNEL
        EXOS 7
        pop   ix
        ret


Valojaban itt az 'add' azert van igy, mert kiserleteztem a dologgal, es nem akartam az IX+...-nel offset-eket mindig atirni, van ahol meg tobb parameter is van. A +4 se feltetlen igaz a fenti megjegyzessel, azert +4 (es nem +2, a viszzateresi ertek is a stack-ban van mar), mivel a push-al mi is berakunk egy word-ot elotte. Az elejen egy kicsit bele is keveredtem, azert most a mostani kodom kisse kusza tobb helyen is. Az assembly formatum meg fura, mert az sdcc assembler-e igy tudja, azaz pl (ix+4) helyett 4(ix) kell neki.

Amugy van ezzel kapcsolatban azert egy erdekesseg. Alapbol az sdcc is - ahogy te is hozol peldakat, illetve en is irtam - az IX regisztert hasznalja kvazi stack pointer relativ cimzes megvalositasahoz. Amde, ez nem feltetlenul optimalis. Ugyanis kisse "lassu", ha jol saccolom fejbol valami 18 (? vagy 19) ciklus. Ellenben az ld a,(hl) az pl csak 7, igaz nem tudsz offset-et, de meg ha inc-et hasznalod mindig utana (6 ciklus), a ketto meg mindig gyorsabb! Es raadasul nem kell pop/push sem nagyon mert a hl-bol kivonsz a vegen. Ez ranezesre csunyabbnak, es korulmenyesebbnek tunik, de bizonyos felhasznalasi minta mellett meg mindig gyorsabb. Talan ezert is van, hogy ujabban az sdcc-ben talaltam, miszerint az un peephole optimalizatora atirja a C fordito altal generalt assembly forraskodban ilyenre a cuccot es utana ereszti ra csak az assemblert.

Osszefoglalva: imho egy asm only projecnel a stack allando hasznalata parameteratadasra (kovetkezetesen, mindig) nem feltetlenul a leggyorsabb, amde magasabb szintu programozasi nyelvek eseten kevesbe kikerulheto ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.October.29. 09:53:11
Konkrétan ilyet én még nem láttam, inkább ide-oda mozgatott HL-lel való címzés fordul elő.
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.October.29. 10:01:02
Akkor beigazolódott a gyanum, miszerint ez annyira sok órajelet emészt fel, hogy EP-nél túlságosan lassan működne. Most éppen a C nyelv és Assembly utasítás közötti kapcsolatot vizsgálom, és végre meg tudom válaszolni a korábban már nem egyszer feltett kérdést, hogy a gépi kódban hogyan tároljuk a dinamikusan (futás közben) létrehozott változókat. Hát így.
Title: Re: Assembly programozás
Post by: lgb on 2012.October.29. 11:36:42
Quote
Akkor beigazolódott a gyanum, miszerint ez annyira sok órajelet emészt fel, hogy EP-nél túlságosan lassan működne. Most éppen a C nyelv és Assembly utasítás közötti kapcsolatot vizsgálom, és végre meg tudom válaszolni a korábban már nem egyszer feltett kérdést, hogy a gépi kódban hogyan tároljuk a dinamikusan (futás közben) létrehozott változókat. Hát így.

Ha lesz idom "gatyaba razni" akkor igeny szerint kozkincse teszem esetleg munkamat, aminek celja az volt, hogy sdcc C forditoval lehessen EP-re fejleszteni C-ben, annak kapcsan "okositottam" fel magamat a kerdesben en is :) Btw, a Z88DK (z88dk.org) is erdekes, ez egy "C minus" fordito (alapvetoen C de egy-ket dolgot nem tud amit a C standard eloir), es van benne EP support. Mondjuk ahhoz erdemes up-to-date verziot lehuzni toluk, ami pl ubuntu linuxban volt, az "tul regi" ehhez. Viszont toluk lehuzva mukodni latszik, van par peldaprogram is, pl az egyik csupan EXOS hivasokon at mandelbrot halmazt rajzol ha jol emlekszem. Ezt en az sdcc-s jatszadozasom utan talaltam csak meg, kulonben az sem biztos, hogy nekialltam volna magam az scc-vel.
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.October.29. 11:38:12
Quote
es van benne EP support
Na ez meglepett! Vajon ki volt olyan elszánt, hogy ezt megcsinálta?
Title: Re: Assembly programozás
Post by: lgb on 2012.October.29. 11:43:30
Quote
Na ez meglepett! Vajon ki volt olyan elszánt, hogy ezt megcsinálta?

=enterprise]http://www.z88dk.org/wiki/doku.php?id=platform:enterprise&s[]=enterprise (http://www.z88dk.org/wiki/doku.php?id=platform:enterprise&s[)
=enterprise]http://www.z88dk.org/wiki/doku.php?id=library:enterprise&s[]=enterprise (http://www.z88dk.org/wiki/doku.php?id=library:enterprise&s[)

Latom linkeket kicsit elszurja mivel kapcsos zarojel van benne (az meg resze az post-ok markup nyelvenek, gondolom azert), de ha raklikkelek nekem legalabbis a bejonnek az oldalak amiket irtam.

Fri Apr 1 06:50:45 2011 UTC (18 months, 4 weeks ago) by stefano

Amugy. Marmint CSV repository szerint az egyik EP-specifikus file commitoloja, tehat valoszinuleg ez a stefano nevu ember kovette el a jelzett idopontban.
Title: Re: Assembly programozás
Post by: Attus on 2012.October.29. 13:49:12
Miért is kellene a C nyelv "nehézkes" zsákos adatátadási módszerét használni??

Számomra a "változók" fogalma a z80 assembler , mint más "magas" programnyelvek (C, pascal stb.) esetén eléggé megfoghatatlan, hisz csak írható/olvasható memóriarekeszek tartalmáról, vagy z80 regiszterek tartalmáról lehet szó, melyek mind változtathatók és mindig sima binárisak. Hogy mit látunk bennünk, string, oktális, decimális hossú egész, tömb, vagy logikai, vagy bármi más típusú "változót", az csak ezek értelmezésén múlik, mely nem a z80 dolga.

Ezeket a tároló rekeszeket, hogy hogyan szervezzük, használjuk, értelmezzük, szinte teljesen a Z80, sőt i8688 programozó szabadságán múlik.
Persze, hogy lehet a memória egy általunk meghatározott tartományában felépíteni egy adatok átadására használt részt, melyeken aztán különféle címzéssel, akár az SP, vagy indexregiszterek segítségével használunk, módosítunk.
Szerintem a legszebb és leghatékonyabb, melyet a magasabb programnyelvek nem nagyon képesek használni, hogy írható/olvasható memóriában futtatjuk a programkódot és magával a programmal építjük fel a később végrehajtandó program kódját, amire programunk rálép. Ez ROM-ban nem megvalósítható.
Title: Re: Assembly programozás
Post by: lgb on 2012.October.29. 14:11:05
Quote
Miért is kellene a C nyelv "nehézkes" zsákos adatátadási módszerét használni??

Az en reszemrol azert kell hasznalni mivel C forditothoz irtam dolgokat (h az altala generalt kod menjen EP-n is), ott nehez kikerulni :) asm-only projectben nem tennem.

Quote
Szerintem a legszebb és leghatékonyabb, melyet a magasabb programnyelvek nem nagyon képesek használni, hogy írható/olvasható memóriában futtatjuk a programkódot és magával a programmal építjük fel a később végrehajtandó program kódját, amire programunk rálép. Ez ROM-ban nem megvalósítható.

Ez kb az onmodosito kod, bar esetunkben inkabb "oniro" :) Amugy ROM eseten sem elkepzelhetetlen: irhat az a RAM-ba, es atadja ra a vezerlest aztan :) Ilyet "modern" kornyezetben nem szokas hasznalni, hisz ott eleve alap hogy meg "diskrol betoltott" program kodja is read only (a CPU-k lapvedelme vagy egyeb MMU mechanizmusok miatt), tehat ha megprobalod atirni elszall a program (mondjuk UNIX-ok eseten SIGSEGV, windows-nal imho generalis protkos faliora). Ez azert is kell, mert ott pl egy program futthat tobb peldanyban (=multitasking), amikor a kod fizikailag egyetlen peldanyban fut: nyilvan ha a kod atirhato/modosithato, akkor ebbol total kaosz lenne. Nade ez kevesbe Z80 tema, hacsak nem ir az ember vmi advanced OS-t Z80-ra, akkor ott is lehet kerdes ez. Mondjuk Z80-al annyit (meg) nem foglalkoztam, de 6510-en C64-en imadom az onmodosito kodot, magas a "cool" faktor :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.October.29. 14:19:00
Quote
imadom az onmodosito kodot, magas a "cool" faktor :)
Én is! :-)
Title: Re: Assembly programozás
Post by: lgb on 2012.October.29. 17:23:22
Btw, ha valakit erdekel, itt egy kis forumos beszelgetes a Z88DK es az SDCC C/asm parameteratadas kerdeseirol, a ket rendszer kozotti kulonbsegekrol, es hasonlokrol, amirol reszben szo volt itt "nalunk is" az elozo par post-ban. Szerintem erdekes elolvasni: ITT (http://www.z88dk.org/forum/viewtopic.php?pid=7301).
Title: Re: Assembly programozás
Post by: Attus on 2012.October.29. 17:25:57
Quote
Én is! :-)
Egyetértek. :)
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.October.29. 23:55:24
Nekem azért tetszik a zsákos módszer, mert ha a processzor támogatja az eljárást, és gyorsan is végrehajtja a memóriahozzáféréseket (ugyanolyan gyorsan mintha regiszterrel dolgozna) akkor a programfejlesztési idő az átláthatóság miatt töredékére csökken, sőt a kód újrafelhsználhatósága is javul. A legfontosabb pedig, hogy nem kell azzal foglalkozni, hogy visszatéréskor a regiszterek érékeit visszaállítsuk.
 Hátránya az, hogy sajnos csak olyan processzoroknál király ez a megoldás, ahol van cache, mert az elsődleges cache elérési ideje és a regiszter elérési ideje azonos.

 Kedvenc szubrutinom a mintakeresés, amikor van egy adott hosszúságú (jó hosszú) adathalmaz a memóriában, és keressük meg benne a "05 12 04 36 45" mintát. Visszatérési érték: A memóriacím, ahol a minta kezdődik, illetve NULLA ha nem volt benne. Itt jó dolog a zsák.
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.December.07. 18:30:12
Hogy oldanátok meg egy 16 és egy 32 bites egész szám decimális (10-es számrendszerbeli) kiírását? Az egyszerűség kedvéért legyen előjel nélküli.

 Elmondom mi áll rendelkezésünkre.
1. Eset 16 bit:
 Adott egy memóriacím, ahol a szó alsó majd felső bájtja található
0200 B0 B1      ; ahol B0 az legalacsonybb helyiértékű bájt

Írjuk ki ezt a számot egy fájlba decimális formátumban szövegként.

2. Eset 32 bit:
 Adott egy memóriacím, ahol egymás után találhatóak a duplaszó egyes bájtjai
0200 B0 B1 B2 B3    ; ahol B0 az legalacsonybb helyiértékű bájt

Írjuk ki ezt a számot egy fájlba decimális formátumban szövegként.

 A Z80-nak nincs ilyen utasítása, tehát több utasításból kell megoldani, ebben biztos vagyok. Első kérdésem, hogy az EXOS-nak van-e erre saját rutinja? Második pedig, ki hogyan csinálná meg, és hány utasítást igényel a legrosszabb esetben?

 Egyetértetek azzal, hogy nagyon számításigényes a dolog (főleg 32 bites esetben) ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2012.December.08. 20:00:37
Az ilyesmi az tényleg valóban igen számítás igényes, kell egy osztó rutin, és sorban osztogatni, pl 16 bitesnél elsőként 10000-el, a kapott értéket kiírni, aztán az érték x 10000-t levonni az eredetiből, ismételni 1000-el, stb.
32 bitesnél ugyan ez, csak sokkal több értékkel.

Általában ezért el is kerülik az ilyet, és eleve BCD-ben tárolják a nagyobb értékeket, az IS-BASIC is ezt teszi 32768 felett.

EXDOS-ban ahol pl a fájlméreteknél nem lehet elkerülni a dolgot, az említett osztogatós módon csinálja, itt a kérdéses rész:
Code: ZiLOG Z80 Assembler
  1.         ;DE-ben megadott 16 bites érték konvertálása a szövegpufferbe
  2.         ;a bevezető nullákat levágja
  3.         ;HL számpufferre mutat
  4.  
  5. lf1f4:  XOR     A
  6.         LD      (HL),A          ;számpuffer
  7.         DEC     HL              ;felső 16 bitje
  8.         LD      (HL),A          ;nullázva
  9.         DEC     HL
  10.         LD      (HL),D          ;érték
  11.         DEC     HL              ;letárolva
  12.         LD      (HL),E          ;a számpufferbe
  13.         EX      DE,HL           ;DE mutat a számpufferre
  14.  
  15.  
  16.         ;számpufferben megadott 32 bites érték konvertálása a szövegpufferbe
  17.         ;a bevezető nullákat levágja
  18.         ;DE számpufferre mutat
  19.         ;A=bevezető karakter kódja, 00H esetén nem ír ki semmit
  20.  
  21. lf1fd:  EXX    
  22.         LD      E,A             ;0, jelzi, hogy nulla eredmény esetén
  23.                                 ;még bevezető nulláról van szó
  24.         LD      D,30H           ;"0"
  25.         EXX    
  26.         LD      HL,lf233        ;számkonstansok táblázatára mutat
  27. lf205:  LD      A,(HL)         
  28.         DEC     A               ;=1? vagyis a táblázat legkisebb eleme?
  29.         JR      NZ,LF20C        ;ugrás ha nem
  30.         EXX                     ;ha igen
  31.         LD      E,D             ;E="0" mindenképpen kiírja a nulla eredményt is
  32.         EXX                      
  33.  
  34.         ;32 bites osztás (DE)/(HL)
  35.         ;C=az osztás eredménye, (DE)=maradék
  36.      
  37. lf20c:  XOR     A               ;C flag törlése
  38.         LD      C,A             ;C=0
  39.        
  40.         ;az osztást kivonással hajtja végre, amíg negatív nem lesz
  41.  
  42. lf20e:  PUSH    HL
  43.         PUSH    DE
  44.         LD      B,04H           ;4 bájton kell elvégezni a műveletet
  45. lf212:  LD      A,(DE)          ;csökkentendő bájt
  46.         SBC     A,(HL)          ;kivonás
  47.         LD      (DE),A          ;letárolás
  48.         INC     HL              ;mutatók
  49.         INC     DE              ;növelése
  50.         DJNZ    LF212           ;művelet elvégzése a többi bájton
  51.         POP     DE              ;eredeti mutatók
  52.         POP     HL              ;vissza
  53.         INC     C               ;eredmény növelése
  54.         JR      NC,LF20E        ;újabb kivonás, ha még nem negatív az eredmény
  55.         CALL    LF254           ;(DE)+(HL), az utolsó kivonás visszacsinálása
  56.                                 ;így (DE)-ben a maradék lesz
  57.                                 ;HL=HL+4, a következő konstansra mutat
  58.  
  59.         LD      A,C             ;eredmény A-ba
  60.         EXX    
  61.         DEC     A               ;eredmény csökkentése eggyel
  62.                                 ;a visszacsinált kivonás miatt
  63.         JR      Z,LF229         ; (+03h)
  64.         ADD     A,D             ;A+"0", vagyis az eredmény ASCII
  65.                                 ;karakterré konvertálása
  66.         LD      E,D             ;E="0", vagyis ha volt már egy értékes
  67.                                 ;karakter, innentől kezdve kiírja a nulla
  68.                                 ;karaktereket is, a szám elején lévő
  69.                                 ;nullákat levágja
  70.         DB      2EH             ;töltelék bájt az OR E átugrásához
  71. LF229:  OR      E               ;nullás eredmény esetén megvizsgálja, hogy
  72.                                 ;bevezető nulláról, vagy már szám közben
  73.                                 ;lévő nulláról van szó
  74.         CALL    NZ,LF040        ;ha nem bevezető nulla, akkor karakter írása szövegpufferbe
  75.         EXX    
  76.         LD      A,(HL)          ;táblázat következő eleme
  77.         INC     A               ;=255? azaz lista vége?
  78.         JR      NZ,LF205        ;folytatás a következővel, ha még nincs vége
  79.         RET    
  80.  
  81. lf233:  DB      80H,96H,98H,00H ;00989680H=10000000
  82.         DB      40H,42H,0FH,00H ;000F4240H= 1000000
  83.         DB     0A0H,86H,01H,00H ;000186A0H=  100000
  84.         DB      10H,27H,00H,00H ;00002710H=   10000
  85.         DB     0E8H,03H,00H,00H ;000003E8H=    1000
  86.         DB      64H,00H,00H,00H ;00000064H=     100
  87.         DB      0AH,00H,00H,00H ;0000000AH=      10
  88.         DB      01H,00H,00H,00H ;00000001H=       1
  89.         DB      0FFH            ;lista vége
  90.  
  91.         ;32 bites összeadás, (DE)=(DE)+(HL)
  92.         ;HL=HL+4
  93.  
  94. lf254:  PUSH    DE
  95.         LD      B,04H           ;4 bájton kell elvégezni a műveletet
  96.         OR      A               ;C flag törlése
  97. lf258:  LD      A,(DE)          ;növelendő bájt
  98.         ADC     A,(HL)          ;hozzáadás
  99.         LD      (DE),A          ;letárolás
  100.         INC     HL              ;mutatók
  101.         INC     DE              ;növelése
  102.         DJNZ    LF258           ;művelet elvégzése a többi bájton
  103.         POP     DE
  104.         RET    
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.December.08. 20:11:21
Nagyon-nagyon köszönöm a válszt!
 Az osztás a Z80 esetében nagyon sok időt vesz igénybe. Gondolom legfőképpen ezért olyan időigényes. Továbbá, mivel a regiszterek 8 bitesek, fel kell osztani az egészet részekre.
 Valami hasonlóra gondoltam én is, mint ami a kódban van.
 Egy dolog: Az osztás után nem kell visszaszorozni és kivonni, mert egy tisztességes osztó rutin után megkapjuk a maradékot is.

 Rájöttem, hogy a visszafelé történő konverzió is nagyon fontos! Ha felhasználó megadja BASIC-ben, hogy
PRINT 47500+23456 akkor vajon mit csinál ezekkel a tagokkal? BCD-ben számol vagy átalakítja kiszámolja és visszaalakítja?
 
Title: Re: Assembly programozás
Post by: IstvanV on 2012.December.08. 20:28:20
Quote from: Zozosoft
Az ilyesmi az tényleg valóban igen számítás igényes, kell egy osztó rutin, és sorban osztogatni, pl 16 bitesnél elsőként 10000-el, a kapott értéket kiírni, aztán az érték x 10000-t levonni az eredetiből, ismételni 1000-el, stb.
32 bitesnél ugyan ez, csak sokkal több értékkel.
Szorzás valójában nem kell, mert az osztó rutin a maradékot is kiszámítja. Ráadásul használható egyszerű ciklusban kivonás az osztás megvalósítására, mert az eredmény nem lehet nagyobb, mint 9.

Az ASCII->bináris szám konverzió könnyű, mert csak 10-el szorozni és a következő számjegyet hozzáadni kell ciklusban. A konstans 10-el szorzás pedig viszonylag egyszerű és gyors művelet.
Title: Re: Assembly programozás
Post by: Tuby128 on 2012.December.08. 21:25:41
BCD -> BIN-t akartál írni ugye? Mert az ASCII az más, ott az "12"-nek 31 32 a kódja. Bár a felső nibble leharapásával igaz megkapjuk a BCD kódot.

 Ez 10-zel való szorzósdi nem a legjobb ötlet, szorzás híjján változó, hogy hányszor kell összeadnunk, a legjobb eset a csupa nulla lesz a legrosszabb meg a sok kilences. 16-bit esetén is azért kell számolni keményen.
Title: Re: Assembly programozás
Post by: geco on 2013.February.18. 15:55:02
Hogyan kerülhetném el két LPT közötti váltás miatti kép ugrást?
Csak a 82h portot írom, és így csak akkor vált a másik LPT-re, ha az elsőn végigfutott, és mégis ugrik egyet a kép, a két LPT teljesen más felépítésű, az egyik elején van státus sor is, és 200 soros képet definiál 1 LPB-ben, a másik elején nincs státusz sor, és 200 soros képet definiál 25 LPB-ben.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.February.18. 16:00:20
A két LPT-ben azonosnak kell lennie a VSYNC és RELOAD közötti távolságnak.

Csak érdekességként itt egy megoldás a HL-ben található LPT cím bállítására, ami rövid, és minimális az idő a 82h és 83h port írása között:

Code: [Select]
        ld      a, 1ch
.l1:    add     hl, hl
        rla
        jr      nc, .l1
        ld      c, 82h
        out     (c), h
        out     (83h), a
Title: Re: Assembly programozás
Post by: geco on 2013.February.18. 16:04:29
Quote from: IstvanV
A két LPT-ben azonosnak kell lennie a VSYNC és RELOAD közötti távolságnak.
Köszönöm szépen :) Ez mindent megmagyaráz :D az utolsó sor a vsyncben, ahol a RELOAD bit van, eltér, pont Státuss sorbeli különbség miatt :D, de akkor kiiktatom a státusz sort mikor a program elindul, és visszaállítom RELOAD-os sor értékét. Köszi szépen mégeccer :)
Title: Re: Assembly programozás
Post by: geco on 2013.February.18. 16:27:19
Nagyon jóóó :smt041 :smt041 :smt041 :smt041
Title: Re: Assembly programozás
Post by: lgb on 2013.March.20. 11:05:33
Lenne par EXOS-al kapcsolatos kerdesem ... Van egy olyan problemam, hogy egy 5-os fejlecu (sajat fejlesztesu) programnal nekem meg kell valtoztatni a B0 memory mapping I/O register erteket, tekintve, hogy 0x100 alatti dolgokra szuksegem van, es ezen nem tudok valtoztatni. Eloszor is kerdeses, hogy mi az a minimalis dolog ott, aminek ott kell lennie, hogy interrupt-ok letiltasa nelkul ne fekudjon meg a rendszer. Masreszt: mi tortenik, ha kozben valaki megnyomja a RESET gombot? Az EXOS warm reset vectort (0xBFF8) modosithatom, amde nem teljesen vilagos, hogy az ott megadott cim konkretan melyik EP szegmensben ertendo, akkor EXOS visszallitja az eredeti belapozott szegmenseket, es ugy kell nekem ehhez viszonyitani? Tovabba: problema, hogy kene nekem egy kis minimalis terulet, ahol dolgozhatok, es ez VRAM kell hogy legyen. Emiatt viszont kene egy plusz szegmens, amit gaznak erzek, mert amugy kell par masik is. Van az az osztott szegmens dolog, ahol van az EXOS boundary stb, mi van ha en siman a boundary-t figyelembe veve onhatalmulag elkezdem hasznalni, vagy ilyet nem "illik"? Ha kell nekem vmi custom LPT, akkor nekem kotelezo ehhez uj vram szegmenst foglalnom (a szokasos "foglalj szegmenseket amig nem kapsz a vram-bol" algoritmussal), vagy megoldhato, hogy exos altal is hasznalt hasonlo celu teruletre "belepasszirozom" szep csunyan? Maguk a pixel adatok mashonnan jonnek (persze nyilvan szinten vram) szoval az itt nem kerdes.

Nem teljesen biztos, hogy ez "assembly programozas" temaba illik-e vagy kulon EXOS topic lenne, de assemblyben irom legalabb :)

Koszi!
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.20. 11:41:06
Az EXOS a 30h-5Bh területet használja, tehát a 00h-2Fh, 5Ch-FFh a tiéd lehet, ha ez elég, akkor nem is kell piszkálnod a nullás lapot. Ha nem elég, akkor tiltanod kell a megszakításokat.
Resetnél az USR_P0-ba bejegyzett szegmenst lapozza a nullás lapra, célszerű ha ide mutat az újraindítási cím.
Az önhatalmú figyelembevétellel az a baj, hogy ha nem foglaltad le a közös szegmenst, akkor az EXOS nem fogja tudni, hogy te ott ténykedsz, és belemászik a szabálytalanul használt területedbe.
Az EXOS határ az csak egy nyilvántartási érték, amit egyrészt közöl veled amikor osztott szegmenst kapsz, hogy éppen akkor mennyi a szabad terület, másrészt miután beállítottad, hogy az osztott szegmensben mennyi hely kell, a további EXOS memóriaigényeknél ezzel hasonlítja össze, hogy tud-e még terjeszkedni.
Pl, 2000H az EXOS határ, neked 1000H kell, mikor megkapod az osztott szegmenst sikeres az ellenőrzésed, mert van elég hely. Beállítod a felhasználói határt, innentől tudja az EXOS, hogy 1000H-ig terjeszkedhet még.

Az LPT és a karakterkészlet (ha nem kell karakteres mód) helyét használhatod videómemóriának pl LPT-hez, csak ki kell keresni a helyüket, hogy 2.0 és 2.1+ verziókkal is működjön.
Az LPT végét viszont nem érdemes felhasználni, mert pl a német bővítés folyamatosan kijavítja a szinkron részt.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.March.20. 12:38:18
Felhasználható még az EXOS verem nagy része is (AC00h-AFFFh), a megmaradt több mint 500 byte hely elég az EXOS megszakításkezelőjéhez és egyszerű csatorna műveletekhez (pl. file betöltés).
Title: Re: Assembly programozás
Post by: lgb on 2013.March.21. 15:20:10
Koszi az infokat! Most eppen felre teve a nullas lap kerdeset, a kovetkezo a problemam: ha lehet elsore nem akarom megvaltani a vilagot, sajat LPT stb. Megoldhato-e ertelmesen, hogy EXOS-tol szepen kerek adott kello videomodot nekem (exos valtozok beallitasa, majd megnyitom a display channelt, aztan johet a 11-es spec 1-es funkcio, hogy mutassa is meg, ezzel nincs is gondom: mukodik), _AMDE_ azzal a csavarral h pl pixel modban en szeretnem megmondani hogy honnan jojjenek az adatok, magyaran a megfelelo LPB LD1 erteket szeretnem modositani (az nekem tok oke, hogy az LPT-t - a fenti LD1-en kivul - az EXOS-ra bizom). Ezt "kitalalos" alapon kicsit nehez, meg bezavarhat hogy most EXOS milyen verzio stb. Van otletetek, hogy lehetne szepen megcsinalni ezt? Kicsit nagy az overhead, hogy most csak 2 byte miatt (LD1) csinaljak sajat LPT-t, stb stb. Vagy ezt nem fogom tudni kikerulni? Mert a gondom az, hogy ahol maguk a pixel adatok vannak annak a helye kotott, amde ott LPT pl nem is ferne el (ezert is akartam elozo postomban valamire "ralsozni" az LPT-t egy masik szegmensbe).
Title: Re: Assembly programozás
Post by: geco on 2013.March.21. 16:33:14
Quote from: lgb
Koszi az infokat! Most eppen felre teve a nullas lap kerdeset, a kovetkezo a problemam: ha lehet elsore nem akarom megvaltani a vilagot, sajat LPT stb. Megoldhato-e ertelmesen, hogy EXOS-tol szepen kerek adott kello videomodot nekem (exos valtozok beallitasa, majd megnyitom a display channelt, aztan johet a 11-es spec 1-es funkcio, hogy mutassa is meg, ezzel nincs is gondom: mukodik), _AMDE_ azzal a csavarral h pl pixel modban en szeretnem megmondani hogy honnan jojjenek az adatok, magyaran a megfelelo LPB LD1 erteket szeretnem modositani (az nekem tok oke, hogy az LPT-t - a fenti LD1-en kivul - az EXOS-ra bizom). Ezt "kitalalos" alapon kicsit nehez, meg bezavarhat hogy most EXOS milyen verzio stb. Van otletetek, hogy lehetne szepen megcsinalni ezt? Kicsit nagy az overhead, hogy most csak 2 byte miatt (LD1) csinaljak sajat LPT-t, stb stb. Vagy ezt nem fogom tudni kikerulni? Mert a gondom az, hogy ahol maguk a pixel adatok vannak annak a helye kotott, amde ott LPT pl nem is ferne el (ezert is akartam elozo postomban valamire "ralsozni" az LPT-t egy masik szegmensbe).
Módosítsd az LD1 értékeit, 0bff4h megadja az LPT címét, és ez egy fix EXOS változó, minden EXOS-ban ugyanott van.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.21. 17:48:03
Pontosan mit is szeretnél (Milyen méretű, felbontású kép?)
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 20:26:57
Gondolkodok itt fejlesztgetesekben ...

Es az van, hogy az elmult evtizedekben baromira hozzaszoktam a magasabb szintu progrmnyelvekhez (C, C++, C#, java es az osszes tobbi),
es mikor leulok az assembler ele, baromira frusztral, hogy 2 napig szenvedek, es odaig jutottam, hogy "szuper, sikerult osszehasonlitani 2 sztringet" ...

szoval probalnek minnel magasabb szintu programozasi lehetosegeket talalni EP- re (akar oly modon is, hogy elbukom az EP fejlesztest, es valami kereszt fejlesztesi modszert hasznalok, ami ugye az ep128emu- nak hala eleg gyors tud lenni),

masreszrol szeretnem megtartani a kozvetlen z80 assembly kompaktsagat, kis meretet, relokalhatosagat, sebesseget, nem beszelve az EP fejlesztes elmenyerol. tehat hogy tenyleg EP- n lett fejleszteve, nem kereszt fejlesztessel.

kiprobaltam az SDCC- t, ossze is hoztam hogy adjon nekem egy EP- n futathato binarist a vege, C- ben lehet fejleszteni, ami tokeletesen eleg, es a legalapvetobb assembly szenvedestol megszabadit, viszont a forditott kod az SDCC- vel szerintem marha nagy lesz, mikor float- okat szamolok, akkor pedig iszonyatosan nagy ... nem tusom miert haragszik erre, de a float- os szamitasok mintha alkalmazasrol alkalmazasra nonenek ... tehat nem az hogy 1X hozzarakja a float rutinokat, hanem barhanyszor hivom oket a kod no mint a gomba ...

szoval nem tetszett (megha a csillagos effekt framework kodjait abban is irtam).

most azon gondolkodok, hogy ossze kene rakni ASSEMBLER MACRO- kbol olyan library- t, ami legalabb az alapveto valtozohasznalatot, fuggveny parameteratadast, neadjisten vezerlesi szerkezeteket tartalmazna, es regiszterfuggetlenne tenne.

ez is nyilvan nagyobb meretu volna mint az igazi assembly, de sztm korantsem akkora mint egy rendes C - bol forditott kod, vagy legalabbis az SDCC- vel forditott.

tehat arra gondolok, hogy adat strukturakat, es stack frame strukturakat felvennek define- okkal, mezo offsetekkel, mezo meretekkel, es ezekel az ofsetekkel lehetne makrokat hivni, ami valami a makroban rogzitett regiszterekben tarolt cimekhez kepesti offsetkent ertelmezve, kepes lenne tetszoleges szamu valtozon elvegezni az alap muveleteket, add, sub, inc, cmp, 

es mivel ezek a valtozok stack- en felvett memoriaban lennenek, nem regiszterekben, ezert a moder nyelvek konnyedsegevel lehetne programozni. persze kicsit (sokkal) tobb lenne az irogatas, de nem kene azzal bibelodni, hogy hany regiszered van, es azok kozul melyikben eppen mi, hanem a regisztereket stack memoriavaltozok helyettesitenek, mint a C- ben.

termeszetesen nem a putpixel ciklusmagokban kene ezeket alkalmazni, de ugy a programok teruleteinek masik 95%- an sokkal konnyebb lenne haladni, nem igenyelne egyeb forditot, EP assemblerekkel lehetne dolgozni, es a kod sem none meg iszonyuan.

elkezdtem egy ilyen framework- ben gondolkodni, de egyenlore eleg nagy munkanak latom... es arra gondoltam valszeg nem nekem jut eszembe ez eloszor... ez meg ugye nem C, de mar nem is direkt assembly lenne... egy MACRO meta nyelv tulajdonkeppen, z80 assembly- vel leirva ...

szoval nem halott mar valaki ilyenrol ? lehet hogy van mar 50 kulonbozo megvalositas, csak en nem tudok rola ...
Title: Re: Assembly programozás
Post by: lgb on 2013.March.23. 20:55:25
Quote from: Z80System
Es az van, hogy az elmult evtizedekben baromira hozzaszoktam a magasabb szintu progrmnyelvekhez (C, C++, C#, java es az osszes tobbi),
En pont forditva vagyok :) Az, hogy sokat kell munkam soran is foglalkoznom magasabb szintu nyelvekkel, csak megerosit abban, hogy hobbynak assembly az igazi, es akkor erzem igazan az elegedettseget, ha abban sikerult vmit megoldani :)

Quote
kiprobaltam az SDCC- t, ossze is hoztam hogy adjon nekem egy EP- n futathato binarist a vege, C- ben lehet fejleszteni, ami tokeletesen eleg, es a legalapvetobb assembly szenvedestol megszabadit, viszont a forditott kod az SDCC- vel szerintem marha nagy lesz, mikor float- okat szamolok, akkor pedig iszonyatosan nagy ...

Na ezt pl pont en is eljatszottam szorakozasbol, hogy sdcc-hez irtam nemi EP-s crt0-t (valahol emlitettem is a forumon). Mondjuk speciel a float olyan dolog, hogy matematikai dolgokat leszamitva miert kene nekem valaha is? :) Soha nem hianyzott nekem se C64-en se mas gepen a float, sot meg PC-n magas szintu nyelvekben sem hasznalok egeszeken kivul semmit szinte. Persze az is igaz, hogy nekem altalaban nem matematikai problemat kell megoldani, vagy valami szimulaciot, stb.

Van viszont pl a Z88DK, ami ugyan elvileg nem "teljes" C csak "small-C", viszont van EP support is benne, keress ra, bar errol is irtam valahol. Igaz, float support eszembe se jutott, hogy teszteljem. Kulonbozo 65xx (pl C64) CPU-kat hasznalo gepekhez is van C compiler (cc65), na abban pl nincs is float support, bar nem is tudom mire lenne jo. Eleve BASIC kapcsan se ertettem soha, hogy miert float az alaptipus, amikor az pont a leglassabb. En ugy terveztem volna a BASIC-et, hogy defaulte integer only, es spec valtozonevre (mint a string-nel a $) lesz csak float. Bar basic-bol utoljara vagy 20 eve voltam jo c64-en, szoval a basic-kel kapcsolatos meglatasaimat inkabb hagyjuk :)

Quote
szoval nem tetszett (megha a csillagos effekt framework kodjait abban is irtam).

De minek ahhoz float support? :) Ha te meg tudod fogalmazni egeszekkel, tuti gyorsabb lesz mindenkeppen, mintha sw-esen megvalositott float-okat hasznal. Ez kb igaz minden hw-ra, ahol nincs hw szintu float (FPU) tamogatas, es a CPU "nativan" csak egeszekkel szamol.

Amugy, ha BASIC tul lassu, asm meg tul "macera" akkor ott a FORTH, ha mar ugy is top tema mostansag! :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 21:14:45
minek a float ...

hat mer bitbabralas nelkul szeretnel interpolalni egy szamot (pld egy rgb komponenst) minimumbol maximumba, es nincs arra idod, hogy 2 ora alatt anak orulj, hogy sikerult kekbol-lilba atmenetet szamolnod fix pontos szamitasokkal, 3 regiszterben

forth ...

hat raneztem tegnap, ha mar igy elokerult, de hat az is egy interpretalt nyelv, megha gyorsabb is abasic- nel, assembly- vel osszehasonlithatatlan, nem relokalhato, kell neki egy futtato framework, satobbi ...

nekem olyan megoldas kene, ahol egy lpt bekapcsolas nem lesz kilobajtok kodja, relokalhato, tehat kontrollalhatom minden assembly utasitasat, de felszabadit a regiszterhasznalat alol, es a lokalis valtozok esetleg strukturak nem ismeretlen fogalom neki
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 21:17:59
Van egyebkent ep- re C fordito... ?

Tehat hogy az ep- n valami programnak adhatom be a C forrast es futtathato kodot fordit belole ? ha van ilyen van barkinek tapasztalata mennyire sikerult optimalisra csinalniuk ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.23. 21:29:34
Quote from: Z80System
Van egyebkent ep- re C fordito... ?
IS-DOS-ra van HiSoft C, de szerintem azzal sokra nem jutunk :-(
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 21:30:37
valami ilyesmire gondolnek, vagy ha nincs ilyen megoldas, akkor macro- kal kifejezve:

http://en.wikipedia.org/wiki/High_Level_Assembly



High Level Assembly (HLA) is an assembly language developed by Randall Hyde (http://en.wikipedia.org/wiki/Randall_Hyde). It allows the use of higher-level language constructs to aid both beginners and advanced assembly developers. It fully supports advanced data types and object-oriented assembly language programming. It uses a syntax loosely based on several high-level languages (http://en.wikipedia.org/wiki/High-level_language) (HLL), such as Pascal (http://en.wikipedia.org/wiki/Pascal_(programming_language)), Ada (http://en.wikipedia.org/wiki/Ada_(programming_language)), Modula-2 (http://en.wikipedia.org/wiki/Modula-2), and C++ (http://en.wikipedia.org/wiki/C%2B%2B), to allow creating readable assembly language programs, and to allow HLL programmers to learn HLA as fast as possible.




Origins and goalsHLA was originally conceived as a tool to teach assembly language programming at the college/university level. The goal is to leverage students' existing programming knowledge when learning assembly language to get them up to speed as fast as possible. Most students taking an assembly language programming course have already been introduced to high-level control structures such as IF, WHILE, FOR, etc. HLA allows students to immediately apply that programming knowledge to assembly language coding early in their course, allowing them to master other prerequisite subjects in assembly before learning how to code low-level forms of these control structures. "The Art of Assembly Language Programming" (http://oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/toc.html) by Randall Hyde (http://en.wikipedia.org/wiki/Randall_Hyde) uses HLA for this purpose.
[edit (http://en.wikipedia.org/w/index.php?title=High_Level_Assembly&action=edit&section=2)]High vs. low-level assemblerThe HLA v2.x assembler supports the same low-level machine instructions as a regular, low-level, assembler. The difference is that high-level assemblers (such as HLA, MASM (http://en.wikipedia.org/wiki/MASM), or TASM (http://en.wikipedia.org/wiki/TASM) on the x86) also support high-level-language-like statements such as IF, WHILE, and so on, and fancier data declaration directives, such as structures/records, unions, and even classes.
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 21:35:07
Quote from: Zozosoft
IS-DOS-ra van HiSoft C, de szerintem azzal sokra nem jutunk :-(

Mert vacak, vagy mi ? Mar probalta valaki ? Nekem tenyleg csak a legalapvetobb ficsorok kellenenek, de azt a leheto leggyorsabban, legtomorebben forditsa, es mar boldog lennek. Ja... meg hogy relokalhato kodot forditson ... kulonben bizonyos exos boviteseket ugye nem lehetne megirni benne ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.23. 22:00:15
Mert nem EP program, hanem CP/M.
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.23. 22:10:14
hat ja, az SDCC- nel is ugy van, hogy eloallitja a kodot, aztan mindenfele utofeldolgozasokkal kerul a kod arra a cimre, ami az ep- nek kell (100H) ...

de eppenseggel lehet vannak ra opcioik ... hogy nem csak kizarolag a cp/m szabalyai szerint tudnak linkelni ...
Title: Re: Assembly programozás
Post by: lgb on 2013.March.23. 22:25:22
Vissza az assembly-hez/stb: valahol anno volt rola szo, de keptelen vagyok megtalalni: hogy is tudom a statusz sort hasznalni magam? Vilagos, hogy ST_FLAG exos valtozo ha 0 akkor megjelenik. Maga a tartalma meg BFF6-on levo pointerrel elerheto. Valoban, ez mux is, ha tiltva van az interrupt. Ha nincs, akkor nem jelenik meg semmi, gondolom EXOS visszairja az "uresseget" oda? Ez remlik hogy valahol le volt irva a "trukk", hogyan lehet elkerulni ezt, csak epp sehol nem talalom :(

Illetve, ahogy nezem az elejet irja felul, mert ugye a CAPS es hasonlo dolgok ott jelennek meg. A kerdes az, hogy bizhatok-e benne, hogy a tobbi reszet beken hagyja? :) Latszolag igen egy gyors teszt alapjan.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.26. 07:18:31
Tudtok PC-n (lehetoleg forraskod szinten is elerheto) futo normalis Z80 assemblert? Kezdek belefutni az SJasm es hasonlo szintu assemblerek limitaciojaba, nevezetesen az "egy file-os" megoldas hatranyaiba. Amire vagyom az egy pl 65xx CPU-k eseten ismert cc65 toolchain, ahol sajat object formatum van, leforditok akar ezer asm forrast, es a vegen a linkerrel fuzom ossze egy "binarissa", lehetoleg fejlett config lehetosegekkel. Letezik ilyen, vagy irnom kell egy Z8o frontendet a cc/ca65-hoz? :) Azert egy nagy projecten dolgozni egyetlen file-ba surritve mindent kicsit gaz egy ido utan (nem, az include az nem er, attol meg egyetlen file, hiszen egy menetben dolgozza fel!)
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.26. 08:54:15
SDCC -ben van inline assembly, igy meg tudod csinalni azt hogy C fuggvenyekbe irkalod az assembly kodot, akarhany file- ba, es a vegen osszelinkeli egy binarissa.

(Mellesleg ha nem sajnalod ra a memoriat/futasi idot, akkor C- ben is kodolhatsz vele)

es nyilt forrasu is.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.26. 08:59:07
Quote from: Z80System
SDCC -ben van inline assembly, igy meg tudod csinalni azt hogy C fuggvenyekbe irkalod az assembly kodot, akarhany file- ba, es a vegen osszelinkeli egy binarissa.

(Mellesleg ha nem sajnalod ra a memoriat/futasi idot, akkor C- ben is kodolhatsz vele)

es nyilt forrasu is.

Tudom, tekintve hogy irtam hozza mar crt0/lib implementaciot, hogy EP-re lehessen vele forditani :) Amde az asm szintaxisa nekem valahogy nagyon nem jon be. Hat hmm, mind1, lehet hozza kene szoknom megiscsak ... Ha jobb nem vala.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.26. 09:05:31
Ez egyébként mért jó? Én annak örülök tökre, hogy nem kell linkerrel szenvedni, meg, hogy mindent bele lehet tenni egy fájlba, már include se kell :-)
Title: Re: Assembly programozás
Post by: lgb on 2013.March.26. 09:14:06
Quote from: Zozosoft
Ez egyébként mért jó? Én annak örülök tökre, hogy nem kell linkerrel szenvedni, meg, hogy mindent bele lehet tenni egy fájlba, már include se kell :-)

"Egyszeru" projectnel valoban. De probalj valami bonyolultabbat, mondjuk pl a Linux kernel erdekes lenne egy file-ban :) Na jo, ez rossz pelda, mert ugye az nagyreszt C azert, de a lenyegen mondjuk ez nem valtoztat. En mindig makefile-okat is irok stb, igy rebuildnel csak a modositott file-okat forditja ujra, aztan a vegen linkeli ossze. Es akkor meg nem is beszeltem olyan finomsagokrol amikor relocatable kod van. Ok ORG-al lehet nyilvan trukkozni (ahogy csinalom a primo emuben is) am ez egy kis ido mulva elegge atlathatatlanna kezd valni. cc65-nel a linkernek egy egesz bonyi config file-t is adhatsz olyan leirasokkal h szegmens igazitas, load/run cim, meg hasonlok. Bar az teny, hogy egy szimplabb projectnel a kulon link lepes az inkabb nyug sok embernek mint elony, ezt belatom :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.26. 09:33:31
Quote from: Zozosoft
Ez egyébként mért jó? Én annak örülök tökre, hogy nem kell linkerrel szenvedni, meg, hogy mindent bele lehet tenni egy fájlba, már include se kell :-)
Fura, hogy ezt kerded, annyira trivialis, hogy nem ertem nalad hogyhogy maskepp van ...

Egy file- ban keresgetni kell a fuggvenyeket, elemeket, ha file- okba rakod, az egy hierarchia szintet csoportosit a kodok elemein, ha a file- okat meg konyvtarakba is rakod, akkor az meg akarhany szintet is csoportosit a kodok elemein. Igy ha megnyitod az "egypixeles csillagokat kirajzolo kodok" file- jat, akkor abban csak a 32 darab egy pixeles csillagot kirajzolo kod lesz, mig a masikban lesz a 32 darab 4 pixeles kod, stb ... konnyeb navigalni, megtalalni. A modern IDE- k ugye mar meg ettol a hierarchizalastol is igyekeznek elszakadni, es a nyelvi elemek helyet szinte fuggetlenitik magatol a nyelvi logikai elemtol, es a kereseseket nyelvi elemek szintjen igyekszenek nyujtani. Es mar majdnem jol mukodnek, de a c++ vonatkozasaban meg mindig volt valami hiba, es ha az ember nem akar a tokeletlensegekkel, megkotesekkel elni, akkor marad a file szintu hierarchizalasnal. Aztan megszokja, es ezt hozza vissza EP- re is ...
Title: Re: Assembly programozás
Post by: lgb on 2013.March.26. 10:07:43
Quote from: Z80System
Fura, hogy ezt kerded, annyira trivialis, hogy nem ertem nalad hogyhogy maskepp van ...

Mondjuk a masik allaspont is ertheto: ha valaki pl EP-en (vagy C64-en, mind1) fejlesztett, nyilvan nem szokta meg annyira a cross-platform fejlesztesnel eloallo dolgokat, ami "nagyobb" rendszereken mar termeszetes, ezert nem is hianyoznak neki ilyen feature-ok.
Title: Re: Assembly programozás
Post by: PiotrSoft on 2013.March.27. 12:56:44
Így igaz!

Mind addig, ameddig a memória és a háttértároló kapacitás és elérési sebesség gátjaiba ütköztünk, kellett a komplett  egy kódban történt megoldás. Megannyi trükkel subrutinokka, de manapság szerencsére sem a háttértár elérése, sem a gép belső írható olvasható tárkapacitási is gyakorlatilag "végtelen".

Nincs szükség olvashatatlan hosszú, és értelmezhetetlen ide-oda hívásokkal operálni. 

De tény, hogy anno ez nem állt rendelkezésre. 

S nem egy demó és játék programkódja kiemelkedőre sikerült a mai szemmel is!
Title: Re: Assembly programozás
Post by: lgb on 2013.March.28. 16:15:20
Kovetkezo problemam :) Nyitottam egy video csatit, minden mux, tudok ra (EXOS funkcioval) irni, no problem. Most amit probalnek, hogy en "manualisan" irok ra. Tehat kellene a video ram cime. Azt tudom, hol tarolja az LPT-t az EXOS, tehat az alapjan az LD1-bol ki tudnam nyeri, de ez macera. Nem lehet megtudni, hol a video ram valahogy? Amit talaltam az EXOS 11-es hivas, B=3 spec funkcio. Erre azt irja a dox, hogy a visszaadott ertek az nick cim, tehat szepen konvertalom, hogy a kettes lapra belapozva a megfelelo video szegmenst tudjam ott manipulalni a megjelenitett tartalmat. Ez azonban nem akar osszejonni, ha utana irok vmit vagy fagy a gep, vagy semmi nem latszik. Gondolom rossz helyre irok, csak nem tudok rajonni hogy hol a gond. Illetve meg egy dolog: a video ram az keresztezhet szegmens hatart? Mert az kicsit gaz nekem, en szeretnem szep egyben tudni, hogy ne kelljen lapozgatnom, hanem az egesz screen-t meg tudjam cimezni direktben. Raadasul harom lapom mar foglalt, tehat csak egyet tudok erre "aldozni" kozben, az elobb irt poziciotol fuggo lapozgatast viszont elkerulnem (ha lehet). Ezert nem szeretnek sajat LPT-t stb irni, ha egyszer az EXOS remekul alkalmas egy video csatorna/lap letrehozasara es megjelenitesere amugy.

Esetleg erre egy pelda nincs valakinel? Sima, hw text kepernyo, semmi faxni jelen esetben! Koszi elore is!
Title: Re: Assembly programozás
Post by: PiotrSoft on 2013.March.28. 20:10:54
Keress utána text80 módnak. 

Ha nem tévedek nagyot, az is emulált karakteres állapot, valójában grafikus lpt-t használ. Legalábbis valami hasonló emlékeim vannak felőle.

Zozo, tévedek?  Ha igen akkor bocsi.
Title: Re: Assembly programozás
Post by: geco on 2013.March.28. 20:12:27
Sajnos a kép keresztezhet szegmenshatárt, bár sima text módban erre nem hinném, hogy nagy esély van :D
Küldd el a forrást, abból kiderül, hogy hol a gebasz.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.28. 20:24:13
Quote from: PiotrSoft
Ha nem tévedek nagyot, az is emulált karakteres állapot, valójában grafikus lpt-t használ. Legalábbis valami hasonló emlékeim vannak felőle.

Igazad vagyon, amde mint irtam az en esetemben hw text-rol van szo, 40 (esetemben egesz pontosan 42) karakteres vizszintes felbontassal. Amugy nem az LPT a kerdes az igazan, hanem hogy az altala mutatott video memoria hol van, es hogyan lehet "szepen" lekerdezni majd ezt direktben manipulalni. Ahogy nezem, amugy grafikus modban is 9 pixelenkent egy LPB alapu LPT-t allit elo az EXOS, karakteres modban meg nyilvan. De ez nem is erdekes, amig az LD1-ek "folyamatosak", akkor elvileg ugye eleg az elso, es kvazi egyben latom a dolgokat.

Azert erdekes a dolog, mert nem hinnem, hogy minden program EXOS funkciokon at manipulalja a kep tartalmat, az enyhen szolva lassu :) Lasd pl primo emulatoromban, amikor az elejen kirakja azt a text-et (az is hwtext). Viszont nem teljesen vagyok kepben, hogy szokas "szepen" csinalni ezt. Valoszinu, h en szurok el vmit, es elobb vagy utobb rajovok a gondra, de a kerdes tovabbra is all, hogy ettol a megoldasom lehet nagyon "ronda", ezert erdekelne, hogy szokas ezt csinalni.
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.29. 00:41:42
Sztm atloghatnak szegmens hatarokon a videolap teruletek, es szerintem folyamatos a memoriakiosztas. Ha nem az lenne, akkor lenne olyan exos funkcio, amelyikkel soronkent lehet megkapni a cimet, vagy ilyesmi. Lekerdezesre meg tok jo az a funkcio amit mondtal, az a mindenkori csatarnanak megmondja a memoria kezdetet, onnantol az egyeb csatorna parameterek (video mod, szelesseg, mittudomenmivanmeg) alapjan lehet szamolni a video lapon (csatornan) valo cimeket.

Ha az adott lap meg atlog 3 szegmensen, akkor atlog, a te feladatod hogy belapozd oket, es olyan z80 cimeket szamolj hozzajuk, ahova belapoztad.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 07:14:28
Quote from: Z80System
Sztm atloghatnak szegmens hatarokon a videolap teruletek, es szerintem folyamatos a memoriakiosztas. Ha nem az lenne, akkor lenne olyan exos funkcio, amelyikkel soronkent lehet megkapni a cimet, vagy ilyesmi. Lekerdezesre meg tok jo az a funkcio amit mondtal, az a mindenkori csatarnanak megmondja a memoria kezdetet, onnantol az egyeb csatorna parameterek (video mod, szelesseg, mittudomenmivanmeg) alapjan lehet szamolni a video lapon (csatornan) valo cimeket.

Az pedig biztos, hogy 9 pixelenkent van egy LPB by default, mert talalkoztam konkretan vele, elsore meg is lepodtem :) Ami erdekes, hogy raadasul grafikus modban is ilyet hoz letre, ahol fuggolegesen 9 pixelenkent van egy LPB szepen egymas utan. Ezt konkretan ki is hasznalom az emulatoromban peldaul. Amugy hwtext modban meg logikus is, ha jol gondolom hirtelen ott maskepp nem is mukodhetne, minden karakter sorhoz kulon LPB kell, mivel egy karakter magassagat az LPB irja le, igy uj sorhoz uj kell. Azaz ha hwtext modban pl van 25 sorod, akkor az 25db LPB, plusz persze a tobbi (az elso EXOS eseteben ugye a statusz-sor, de nyilvan ott van meg a vegen a tobbi, blank, meg vsync ....).

Itt irja is amugy:

"Initially the ASCII map starts with the top left character of the page and continues across the first line followed by the second line and so on down the page. However once any scrolling operations have been performed the ordering of lines on the page will be different so the first byte of the ASCII map will be the first character of a line but not necessarily the top line. The lines can end up in any arbitrary order and even clearing the page will not re­order them."

En csak abbol indulok ki, hogy a csatorna megnyitasa/ videolap megjelenitese utan _elso_ alkalommal folyamatos es linearis a video memoria kiosztasa, ha kozben nem irok ra, nem scrollozom stb.
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.29. 08:20:12
Igen, 9 pixelenkent van az lpt blokkokra osztva, en anno utaltam, hogy nem 8 pixeles egy sor, milyen hulyeseg mar hogy egy karakter nem 8X8- as hanem 8X9- es, de sokan meg imadtak, de hat ugyis sajat lpt- t hasznaltam mindig, amint megertettem hogy az exos hivasokkal operalas meg nem a teljes sebessegu hasznalata a hardvernek az en celjaimra.

De az hogy hany pixelenkent vannak a blokkok fuggetlen kerdes a memoria kiosztasatol.

Amit pedig irsz a scrollozodasrol, az meg azt jelenti sztm hogy hardverbol scrolloz, tehat mikor scrollozni kell egy lapot, akkor az lpt (9 pixelenkenti, ami 1 karakter karakteres modban) blokkjaiban a memoria cimeket atirva scrolloz, nem a tenyleges lapmemoriaban masol.

Tehat kepes vagy nagyobb video lapokat letrehozni mint a kepernyo, amiket a kepernyore kulon utasitassal teszel ki, es fuggolegesen tetszoleges pozicioba. Azt hogy melyik lap melyik reszletet tetted a kepen hova, azt neked kell nyilvantartani, es a korabban irt cimhez kepest kiszamolni a teruleteit, ha figyelembe kell venni.

Ebbol persze az is kovetkezne, hogy akkor az exos is megteszi ezt a nyilvantartast, tehat valahol fellelheto kell legyen benne, de nem tudom hol van, viszont lehet hogy ez neked nem is kell ...
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 09:08:46
Quote from: Z80System
Igen, 9 pixelenkent van az lpt blokkokra osztva, en anno utaltam, hogy nem 8 pixeles egy sor, milyen hulyeseg mar hogy egy karakter nem 8X8- as hanem 8X9- es, de sokan meg imadtak, de hat ugyis sajat lpt- t hasznaltam mindig, amint megertettem hogy az exos hivasokkal operalas meg nem a teljes sebessegu hasznalata a hardvernek az en celjaimra.

Na igen, nekem is pont ez a bajom. Amde megse szeretnek sajat LPT-t hasznalni, ennek memoria okai vannak: akkor nekem kell kerni egy plusz szegmenst, es mar 128K-s gepen szukeben vagyok ennek pl :( Azert is gondoltam, hogy inkabb az EXOS-ra bizom, gondolvan hogy o nem feltetlen foglal egy karakteres kepernyo miatt uj szegmenst, ha pl a system segmentbe belefer, bar nem tudom igy van-e es pontosan hova pakolja a video ram-ot (az lpt-t a system segmensbe, legalabbis imho, de most a videoramrol van szo). Illetve egyszerubb is, ha nem en "szenvedek" az LPT felepitesevel, es szamolom hogy miket kell irni az LD1-be stb, hanem az EXOS-ra bizom. Ezek utan csak annyi, hogy max kellene nekem a cim hogy vegulis hova rakta a video RAM-ot, es innentol ugyis magam fogok direktbe irkalni, nem az EXOS-on at. Foleg mivel amugy sima hw text, semmi extra, viszont exos-on at irni ra meg igy is keservesen lassunak tunik szamomra :(

Quote
Amit pedig irsz a scrollozodasrol, az meg azt jelenti sztm hogy hardverbol scrolloz, tehat mikor scrollozni kell egy lapot, akkor az lpt (9 pixelenkenti, ami 1 karakter karakteres modban) blokkjaiban a memoria cimeket atirva scrolloz, nem a tenyleges lapmemoriaban masol.

Pontosan! De ezert mondtam, hogy nem lehet arra szamitani - altalanos esetben - hogy a memoriaban direktbe elerve a "video RAM"-ot az folyamatos, mint mas gepnel. Mondjuk ez kevesbe zavar engem, mivel csak en irnek ra, igy az EXOS-nak nincs alkalma, hogy atrendezze pl scroll hatasara, alapbol a videolap letrehozasa utan meg amugy linearis szokott lenni (remelem legalabbis)
Title: Re: Assembly programozás
Post by: geco on 2013.March.29. 09:31:38
Miért nem írod felül az LD1-es értékeit az EXOS LPT-nek? Kérsz egy videólapot, vagy egy user boundaryt az FF szegmensen, és annak megfelelően állítod be a magad kis videólapcímeit, akkor biztos folytonos lesz a címzés.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 09:54:12
Quote from: geco
Miért nem írod felül az LD1-es értékeit az EXOS LPT-nek? Kérsz egy videólapot, vagy egy user boundaryt az FF szegmensen, és annak megfelelően állítod be a magad kis videólapcímeit, akkor biztos folytonos lesz a címzés.

Igen, ez igaz, sot a primo emu primo kepernyo reszenel pl pont ezt csinalom, ott az LD1 ugy van atirva hogy az emulalt primo megfelelo ram poziciojara mutasson. Amugy lehet hogy ez lesz itt is akkor, csak egyreszt erdekelt volna a megoldas, masreszt nem akartam meg egy szegmenst foglalni csak emiatt, ha mar az EXOS amugy is kepes adott videolapot letrehozni, akkor miert duplikaljam le, ami a ROM-ban mar meg van irva? :) Mondjuk abban igazad van h memoria miatt nem feltetlen kene aggodnom: az emu tobb reszenek teljes szegmens kell. Ha el is fogy kozben a memoriam, a shared szegmens meg megkaphato, ott meg ugysem kene teljes szegmens nekem, eleg csak 42*27 byte ugy saccra :)

De amugy biztos en szurok el vmit, mert szerintem az en megoldasom (lekerdezem az exos-tol a video ram cimet) is mukodkepes kene hogy legyen! Kozben rajottem viszont hogy "hulye vagyok" a Z80 bit eltolas/forgatas opcode-okhoz mindig total keverem hogy melyik mit csinal, es van egy jo rakas. Ha pl az a feladat hogy mondjuk az A >> 6 muveletet csinaljam meg, mindig nezek butan egy idore, hogy most akkor melyik utasits is kell a 6 bittel jobbra tolashoz, hogy az uj bejovo bitek balrol 0-ak legyenek pl. Illetve ugyanez a masik iranyba tolasnal. Ez ugyben vki kisegitene? Lusta vagyok elolvasni, Z80 assembly-t meg igazan komolyabban (bezzeg disassemblert tudok irni hozza, hehehehehee) eddig nem probaltam, ez a primo emus cucc az elso :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.29. 09:54:28
Quote from: lgb
 Ahogy nezem, amugy grafikus modban is 9 pixelenkent egy LPB alapu LPT-t allit elo az EXOS, karakteres modban meg nyilvan.
Igen, mert a karakter méretnyi terület az alapegység az EXOS videólap kezelésénél.

Quote
nem teljesen vagyok kepben, hogy szokas "szepen" csinalni ezt.
Leginkább saját videómemóriával és LPT-vel :-)
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.29. 09:59:42
Quote from: Z80System
Ha az adott lap meg atlog 3 szegmensen, akkor atlog, a te feladatod hogy belapozd oket, es olyan z80 cimeket szamolj hozzajuk, ahova belapoztad.
Így van. Annyit még hozzá tennék a dologhoz, hogy bizonyos EXOS műveleteknél el is mozdulhat az adott terület a videó memóriában! Az EXOS igyekszik a szabad területet összefüggően tárolni, így ha pl van két videólap, és a korábbit bezárod, akkor a másodikat felmozgatja, hogy egyben legyen a szabad terület. Ez BASIC-ben néha látható is, hogy egy picit villan a kép.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 10:01:00
Quote from: Zozosoft
Leginkább saját videómemóriával és LPT-vel :-)

Hat jo, tudom en vagyok tul lusta, csak eppen egy szem hwtext sima kepernyo miatt ezt kicsit agyuval a verebre effektnek erzem, de legyen :) Foleg, mivel mas geppel ellentetben az EP-nek van szep es szexi :) oprendszere, akkor szeretnem is azt hasznalni, olyat mar csinaltam regebben is, hogy magam gyartok LPT-t nullarol meg minden.
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.29. 10:09:38
Quote from: lgb
Pontosan! De ezert mondtam, hogy nem lehet arra szamitani - altalanos esetben - hogy a memoriaban direktbe elerve a "video RAM"-ot az folyamatos, mint mas gepnel. Mondjuk ez kevesbe zavar engem, mivel csak en irnek ra, igy az EXOS-nak nincs alkalma, hogy atrendezze pl scroll hatasara, alapbol a videolap letrehozasa utan meg amugy linearis szokott lenni (remelem legalabbis)
Nem ertem a problemadat ezzel...

Amennyire en latom ez ugy mukodik, hogy mikor megkrealsz egy videolapot annak a memoriatartomany(vagy tartomanyai, mert ugye vannak modok ahol 2 memoria tartomany kepzi a kepet) folyamatos. Most mi az elso tartomanyrol beszelunk alapvetoen, ott vannak a karakterek, ill. a pixel adat.

Namost egy lapon belul ez a terulet folyamatos, es az is marad. Tehat mondjuk letrehozol egy video lapot, ami mondjuk karakteres es teljes szelessegu, es 3 kepernyo magas. Akkor te egy exos hivassal megmondhatod, hogy ennek a lapnak melyik soratol kezdve legyen a kepre rakva hany sor a lapbol.

Ha pld. te azt mondod, hogy a lap elso soratol legyen a kepen (kepen=lpt- ben, megjelenitve) egy teljes kepernyonyi sor (elfelejtettem hany karaktersor van a kepen, 24, vagy valami ilyesmi), akkor a 3 kepernyo meretu lapod elso kepernyoje fog latszani, a masik ket kepernyo epp nem latszik (mert nem fer a kepre) de attol meg a memoriaban le lesz neki foglalva a hely, folyamatosan, meg minden. A memoria allokalaa a videolap letrehozasakor megtortenik, es addig meg is marad mig a lap meg nem szunik. Persze maga a cime megvaltozhat az exos- ban rogzitett hivasok soran (mert azok a hivasok is allokacioval jarnak, es az exos atrendezheti a memoriat), de attol meg az, hogy a lapnak le van foglalva a memoriaja (mind a 3 kepernyonyi memoriaja elobbi peldaban) es folyamatosan lesz a memoriaban, az nem fog valtozni. Csak maximum a kezdocim valtozhat.

Namost ha te a 3 kepernyos lapodat nem az elso soratol, hanem a 10. soratol teszed a kepre, szinten teljes kepernyo magassagban, akkor a lapodbol a 10. soratol fog latszani egy kepernyonyi. Ha a lapodbol a 10. soratol teszel a kepernyore 15 sort, akkor a 10. soratol fogsz latni belole 15 sort, es a kepernyo tobi helyen olyan lapok reszeit fogod latni, amiket elotte valaki odarakott.

Mindez azonban nem valtoztatja meg a te lapod memoriajat, annak kezdocimet mindig vissza tudod kerni az exostol es mindig folyamatos lesz a memoriaban.

Akkor is ha valaki a kepen (lpt- ben), akar reszben, akar teljes egeszeben lefedi a te lapodat. A memoriaja ugyanott lesz, ugyanugy folyamatosan, csak epp nem fog latszani, vagy bizonyos darabjai nem fognak latszani.

Tehat ha csinalsz mondjuk egy teljes kepernyonyi memorialapot, fuggetlenul attol hogy a kepen latszik- e vagy sem, memoriaja lesz, el tudod kerni a kezdocimet es folyamatosan (szegmenshatarokat atlepheti a memoriablokk mindig, kezelni kell tudni) elerheted a lapod memoriajat. Es hogy a lap epp latszik a kepen, vagy sem, vagy reszben le van- e fedve a kepen mas lapok altal, az teljesen mindegy. Ha meg meg is jelenited a lapot, akkor hurra, meg latszani is fog, amit a memoriajaban kavarsz.

A videolapok offscreen memoriak, nincsenek direkt osszefuggesben a keppel. Az LPT koti a kepre a darabjaikat.

Ha pedig (pld. valami hardkopihoz, vagy ilyesmihez) teged nem bizonyos lapok memoriatartalma erdekel, hanem a kepernyon levo (lpt- ben levo) dolgok, akkor az lpt analizisevel tudod csak megoldani a dolgot, figyelembe kell venni hogy az lpt soraiban milyen videomodokban, milyen cimekrol van kep generalva. Biztos van valami egyeb nyilvantartasi indormacio is az exosban (pld. lapok elejen vannak ilyen nyilvantartasi adatok, meg nem tudom meg hol), amelyikek magasabb szinten megmondjak, hogy az lpt- ben epp milyen lapok vannak, melyik sorokban, de en ezeket nem ismerem, es sztm neked sem ez kell, vagy igen ?

Siman csinalsz egy lapot, kidobod a kepre, kezdocimet elkered, es irod a memoriajat (szegmenshataratlepes figyelembevetelevel) folyamatosan es kesz. Ha erre valaki rapakol akkor semmi nem fog tortenni azon kivul, hogy valamelyik soraid nem fognak latszani.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.29. 10:15:04
Quote from: lgb
Kozben rajottem viszont hogy "hulye vagyok" a Z80 bit eltolas/forgatas opcode-okhoz mindig total keverem hogy melyik mit csinal
Ha jól tippelem ez kell neked:
Code: [Select]
LD HL,videocim
LD A,0FFH
PUSH HL
RL H
RLA
RL H
RLA
POP HL
OUT (0B2H),A
SET 7,H
RES 6,H
A videócím legfelső két bitjét átforgatjuk az A alsó két bitjére (Carry használatával), A többi bitje 1, így végül megkapjuk a videószegmens számát.
Utána pedig a videócím legfelső bitjét 1-re, alatta lévőt 0-ra állítva 2-es lapra konvertáljuk.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 10:37:15
Quote from: Z80System
Namost egy lapon belul ez a terulet folyamatos, es az is marad. Tehat mondjuk letrehozol egy video lapot, ami mondjuk karakteres es teljes szelessegu, es 3 kepernyo magas. Akkor te egy exos hivassal megmondhatod, hogy ennek a lapnak melyik soratol kezdve legyen a kepre rakva hany sor a lapbol.

Szerintem nem marad folyamatos, ahogy ideztem is, leiras is irja, hogy valtozhat a sorrend pl scroll hatasara. Az mas kerdes, hogy mivel csak en irok ra (exos-on at nem), ezert ez valoszinuleg nem problema :)

Amiket leirtal amugy az mind vilagos, csak valahogy megse mukodik nekem ezek szerint. De majd megszakertem, lehet az emlitett bit eltolasos jatekoknal (nick es z80 cim kozotti "konverzio") szurtam el csupan az egeszet, az meg a jobbik eset :)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.March.29. 10:41:08
Quote from: Zozosoft
Code: [Select]
LD A,0FFH
PUSH HL
RL H
RLA
RL H
RLA
POP HL
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)
Code: [Select]
LD A, H
RLCA
RLCA
OR 0FCH
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.29. 10:42:10
Quote from: IstvanV
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)
Igaz :oops:
Title: Re: Assembly programozás
Post by: Z80System on 2013.March.29. 10:49:24
Quote from: lgb
Szerintem nem marad folyamatos, ahogy ideztem is, leiras is irja, hogy valtozhat a sorrend pl scroll hatasara. 
Szerintem a scroll hatasara csak az lpt soraiban valtoznak a memoriacimek. Errol ir a doksi. Attol meg az adott video lap memoriaja (a mindenkori kezdocimehez kepest) folyamatos es teljes a lap teljes mereteben, szent es sertehetetlen.

Valami tudos szakercse meg a kerdest... Zozo ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.March.29. 10:51:53
Quote from: Z80System
Szerintem a scroll hatasara csak az lpt soraiban valtoznak a memoriacimek. Errol ir a doksi. Attol meg az adott video lap memoriaja (a mindenkori kezdocimehez kepest) folyamatos es teljes a lap teljes mereteben, szent es sertehetetlen.
Így van. Elmozdulni elmozdulhat, de akkor is folyamatos marad.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 11:38:06
Quote from: Zozosoft
Így van. Elmozdulni elmozdulhat, de akkor is folyamatos marad.

Tuti? En ezt olvastam: "The lines can end up in any arbitrary order" Lehet, a fogalmazas rossz, vagy az en angol tudasom de a "tetszoleges sorrend" nekem azt jelenti, hogy nem feltetlen marad folytonos!

Illetve OK, videomemoriaban nem rendezodik at, de a hatas ugyanaz: ha az EXOS megkeveri hogy az egyes sorokhoz tartozo LPB hova mutat a videoramban, ugyanugy bajban vagyok, mivel akkor ugye ha en lineariskent kezelt video memoriaba irok, az megjelenitesben nem feltetlen lesz ugyanolyan sorrendben ami nyilvan nemkivant hatas az en szemszogembol :)

De mint irtam, mindegy is, mivel exos nem fog ra irni (csak en, es kozvetlenul, memoriaba) szerintem ez engem nem zavar, max ha kozben vmi exos hivas van ami "arrebb rakhatja" az egeszet, de olyat nem tervezek csinalni.
Title: Re: Assembly programozás
Post by: lgb on 2013.March.29. 12:59:50
Quote from: IstvanV
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)
Code: [Select]
LD A, H
RLCA
RLCA
OR 0FCH

Aha, koszi! Meg Zozonak is. Valami hasonloan egyszeru elegans peldat tudnal adni ennek forditottjara? Amikor tudom a szegmens szamot, azon belul az "offsetet" es abbol kell nekem nick cimet szamolni. Ezt is megoldottam, csak epp tartok tole, hogy joval bonyolultabb mint az idealis megoldas, orajelciklusokat es utasitasok szamat nezve :)
Title: Re: Assembly programozás
Post by: geco on 2013.March.29. 15:36:44
Quote from: lgb
Aha, koszi! Meg Zozonak is. Valami hasonloan egyszeru elegans peldat tudnal adni ennek forditottjara? Amikor tudom a szegmens szamot, azon belul az "offsetet" es abbol kell nekem nick cimet szamolni. Ezt is megoldottam, csak epp tartok tole, hogy joval bonyolultabb mint az idealis megoldas, orajelciklusokat es utasitasok szamat nezve :)
and 03h
rrca
rrca

a-ban a szegmens száma bemenetnek, és kimenetben a video address high byte-ja lesz a-ban
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 00:18:01
Miért nem lehet vajon 16 bitet tolteni IX+nn címről ?

Szeretnék olyanokat, hogy: ld bc,25(IX), meg ilyeneket ... Ezt csak két lépésből tudom:  ld c,25(IX) ld b,26(IX) ?

Nincs erre valami trükk, amire nem gondolok ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 00:30:09
Én egyébként teljesen azt hittem, hogy PC -s Z80 -as cross fordítókból (legyen az Assembler vagy C) nagy dömping van ... közben egy frászt ... alig van, vagy ha van, akkor szedett- vedett ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 10:20:02
Van valami mód arra, hogy az ember kiolvassa a z80 -ból hogy azok a megszakítások, melyeket a DI/EI utasításokkal kezelünk épp engedélyezve vannak -e ? Tehát olvasni a z80 -ból azt, hogy DI vagy EI utasítást adtunk ki utoljára ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 10:43:48
Igen, az LD A,I vagy LD A,R utasítás a P flagbe teszi az állapotot. Viszont hibásan működik ha pont abban a pillanatban jön megszakítás :-( ez a hiba csak a CMOS Z80-akban lett kijavítva.
Itt ír róla István, hogyan lehet mégis megoldani. (http://enterpriseforever.com/cpc-r337l/pinball-power/msg21294/#msg21299)
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 10:56:51
EXDOS így csinálja:
Code: ZiLOG Z80 Assembler
  1.         ;megszakítási állapot lekérdezése, megszakítások tiltása
  2.         ;C flag=1, ha tiltva volt
  3.  
  4. ldfc5:  XOR     A
  5.         PUSH    AF      ;0 a veremmutató
  6.         POP     AF      ;alá
  7.         LD      A,R     ;IFF lekérdezése
  8.         DI              ;megszakítás letiltása
  9.         RET     PE      ;visszatérés, ha engedélyezve volt
  10.         DEC     SP      ;veremmutató
  11.         DEC     SP      ;vissza
  12.                         ;NMOS Z80 bug ellenőrzés
  13.         POP     AF      ;itt nullának kell A-ba kerülni
  14.                         ;ha volt az LD A,R utasításnál megszakítás
  15.                         ;akkor nem 0 lesz
  16.                         ;ez esetben hibásan volt jelezve a megszakítások
  17.                         ;tiltott állapota
  18.         OR      A      
  19.         RET     NZ      ;visszatérés, ha volt megszakítás közben, C flag törölve
  20.  
  21.         SCF             ;C flag beállítva    
  22.         RET             ;visszatérés
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 11:00:04
Hát nem piskóta ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 11:19:12
És akor a z80 -ban a megszakítások engedélyezettségének állapota a flag ragiszterben van tárolva ?

Tehát nem csak információt nyújt róla, hanem belül a z80 maga is azt a flag -et figyeli ?

Vagyis egy di/ei nem csinál mást a z80 -on belül, minthogy állítja a flag regiszter tartalmát ?

Es akkor:

ei
push af
di
pop af

után a megszakítások újra engedélyezettek lesznek, mert a pop af visszaállítja a flag regisztert is ?

Mert ha meg nem így van, akkor alábbi kódrészlet nem csak olvassa, hanem tiltja is a megszakításokat ... elég durva side effect egy kiolvasáshoz ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 11:32:28
Quote from: Z80System
És akor a z80 -ban a megszakítások engedélyezettségének állapota a flag ragiszterben van tárolva ?
Nem arra van külön belső flag (IFF1 és IFF2), csak ebben a speciális esetben másolódik az F-be, pont azért, hogy le lehessen kérdezni.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 11:53:31
Hát jó, akkor gondolom annyit kell tegyek, hogy az előző rutin visszatérései előtt azokban az esetekben, mikor C flag nélkül térne vissza, akkor a visszatérések előtt nyomok egy ei -t, hogy a detektáláshoz kiadott di -t megszűntessem, igaz ?

Másik: és akkor arra, hogy a nick -től visszakapjuk az lpt címét, arra végképp nincs semmi mód, igaz ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 12:01:51
legegyszerűbb ha a CALL után teszel egy JR C-t ami átugrik egy EI-t.

Igen az LPT-t nem lehet lekérdezni Nick-től :-(
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 13:06:40
Ez van az exos leírásban a 0x38 -as címhez:

38h | Interrupt vector | Soft ISR ad.

Az ok, hogy egy megszakításnál a z80 egyfajta CALL -t hajt vegre a 38h -ra, és ott valami utasításoknak kell lennie, amelyik kezeli a megszakítást, majd visszatér.

Gondolom erre 4 byte -om van, nyilván valami vezérlésátadást kell oda tenni. De ki határozza azt meg hogy ez pontosan 4 byte, és mi az a "Soft ISR ad." ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 14:00:43
Attól függ akarsz-e EXOS-t használni.
A békés megoldás, ha a 3D-3Eh címre leteszed a saját rutinod címét, amit a saját megszakítás kezelése után meghív. (Ez a Soft ISR)
Játékokban, demókban, ahol fontos tényező a végrehajtási idő, megszoktak szabadulni az EXOS megszakításkezelésétől, egy JP utasítást téve 38H-ra, ami a saját rutinra ugrik.
Ugyanez megoldható IM2-re áttéréssel is.
Ekkor használhatóak EXOS hívások, de egyes esetekben gond lehet, pl az EXDOS nem veszi észre a lemezcserét, és írásnál tönkreteszi a betett lemezt.
Ha egyáltalán nem kell EXOS akkor 38H-tól jöhet a saját rutin, felülírva az EXOS közös funkcióhívás/megszakításkezelő rutinját.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 15:13:17
Ha a Soft ISR terület az a user megszakítás rutin, akkor miért van ott JP 0000 (epdos alatt néztem), ez sem egy cím, ami a user megszakítást jelöli, hanem konkrétan lefuttatott kód ? Tehát a 38h és a 3ch az mindkettő egy fix cím, csak az első 4 byte kódot tartalmazhat, míg a második csak hármat, illetve az elsőt a z80 hívja meg hardware megszakítaskor, a másodikat (3ch) pedig az exos hívja meg ? De nem olvas ki onnan semmit, csak ráugrik a 3ch -ra ? És akkor a JP 0000 az mit csinál ? Miért nem száll el ?

És ha úgy vannak, ahogy fent írom, akkor mi ez ? :

 0BFED/Eh - USER_ISR Address of user's interrupt service
 routine, must be in page 0 and can
 be 0000h for no routine.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 15:35:21
Quote from: Z80System
0BFED/Eh - USER_ISR Address of user's interrupt service
 routine, must be in page 0 and can
 be 0000h for no routine.
Jaj igaz :oops:
Ez az amit a megszakítási rutinban hív! (Csak EXOS 2.1-től van ilyen.)
A másikat akkor hívja (ha nem 0), ha szoftveres dolog történik, pl STOP gomb lenyomása, vagy hálózati adat érkezése.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 15:45:31
Ok, akkor tehát a 38h az a hardware megszakítási cím (mindenféle hw dolgok kezdemenyezik), 3ch pedig a szoftver megszakítási cím, amit a szoftver megszakítások kezdeményeznek, egyiknél 4 byte -os kódunk lehet, másiknál 3 byte -os kódunk ... rendben.

De akkor miért JP 0000 kód van a 3ch -n ? Mi van a 0000 -án, hogy mer oda ugrani ?

A másik hogy ilyen szoftver megszakításokból én exos kompatibilis módon nem is részesülhetek, csak a hardware megszakításokból a 0BFED/Eh által ? Mindkettőhöz kéne lennie az exos -nak egy olyan változója, melyen keresztül az alkalmazói program is kezelheti mindkét típusú megszakítást, nem ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 15:58:56
Mind két esetben 0 érték azt jelenti, hogy nincs ilyen rutin, ilyenkor természetesen nem is hívja meg.

Ha BASIC alatt nézed meg, akkor ott már JP 00FFh van a soft isr címen.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 16:03:54
Mind a 38h és 3ch megszakítások esetében a z80 fogja meghívni az iménti címeket, nem ? HW megszakítás hatására z80 hívja 38h -t, és RST mittudoménhány esetén szintén a z80 fogja hívni 3ch -t ... vagyis senki semilyen nullát nem néz ... nem ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 16:11:22
A 38h-t hívja csak a Z80, ez a hardveres.
3Ch-t az EXOS hívja.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 16:20:21
Ha az exos ránéz a 3ch -n lévő JP utasítás operanduszára, hogy az nulla- e, és csak akkor ugrik, ha nem nulla, akkor minek oda a 3ch -n lévő JP utasítás kód ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 16:25:51
Quote from: Z80System
Ha az exos ránéz a 3ch -n lévő JP utasítás operanduszára, hogy az nulla- e, és csak akkor ugrik, ha nem nulla, akkor minek oda a 3ch -n lévő JP utasítás kód ?
Mert így egy fix címet lehet hívni, azaz a 3Ch-t.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 16:28:59
Amit értenék akkor (hogy hasznos), ha nem nézegetné a címet ... de nézegeti ... ha már nézegeti, nem toknyóc neki, hogy fix címet hív, vagy azt amit az imént nézegetett meg, hogy nem zéró ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 16:49:25
Nem fix címet hogyan hívnál meg ROM programból?
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 16:54:07
Hát mittudomén ... pont úgy, ahogy ellenőrizném, hogy zéró- e ... aztán meg push visszatérési cím, és jp (hl), amiben a már ellenőrzött nem zéró cím van ... nem ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 16:56:36
Regiszterekben a visszaállított eredeti értékek vannak.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 17:05:19
Mit kezdjek én azokkal ?

Fut a programom, teljesen mindegy, hogy belehívtam -e exos -ba, vagy nem, es hogy hol következett be a szoftver megszakítás, oké hogy mikor meghívódott az alkalmazói program szoftver megszakításkezelője (3ch) akkor a lapok, ilyesmi magasabb szintű kontextusok helyre vannak állítva ... de mit kezdjek én a megszakításlezelőben a főprogram regisztereivel ?

Tök felesleges ... nem ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 17:09:30
Semmit, neked csak meg őrizni őket.
De a te rutinodból a megszakított programba tér már vissza a vezérlés.
Ahhoz, hogy te meg tud őrizni, az EXOS-nak helyre kell állítani azokat, mielőtt továbbadja a vezérlést.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 17:12:53
Quote
De a te rutinodból a megszakított programba tér már vissza a vezérlés.
Ááááááá, mindíg van valami amit zsigerből másképp gondolnék ...

Miért ? Miért nem hív meg engem, aztán ha visszatértem, korrekt módon visszaadja a főprogramnak a kontrollt ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 17:28:39
Quote from: Z80System
Miért ? Miért nem hív meg engem, aztán ha visszatértem, korrekt módon visszaadja a főprogramnak a kontrollt ?
Ez korlátozná a lehetőségeket, nem lehetne a főprogram regisztereit piszkálni.
Pl láttam már olyat játékban, hogy a billentyű lekérdezés a megszakításban ment, és az eredményt az A' regiszterbe tette.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 17:41:42
Na jó, csináljunk úgy, mintha túltettem volna magam a megrázkódtatásokon, es foglaljuk össze:

- a 38h hardver megszak cím, z80 hívja, nem lehet kinullázva, melyre alapból rá van ülve az exos, amíg az ember ki nem cseréli saját kezelőre. ha lecseréljuk, akkor azt csinálunk amit akarunk, akár még az exos -t ( az eredeti megszakításkezelőt ) is hívhatjuk belőle, ha ügyesek vagyunk, de ha nem cseréljük le, akkor is van lehetőségünk kezelni a megszakításokat a 0BFED/Eh által, viszont INNEN VISSZATÉR a megszakításkezelőnk az exos megszakításkezelőjébe mielőtt visszatérne az exos megszakításkezelője a főprogramba.

- a 3ch pedig szoftver megszak esetén van hívva, az exos által, éppúgy ki lehet nullázva mint a 0BFED/Eh, és ebből már a főprogramba tér vissza a vezérlés, nem az exos szoftver megszakkezelőjébe.

Igy van ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 17:54:52
Igen.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 18:01:18
Namost akkor a 0BFED/Eh -által nyújtott módszerrel vagy nem lehet kommunikalni a főprogrammal regisztereken keresztül, vagy pedig lehet, mert megoldja az exos, de akkor a szoftver megszak esetén éppúgy meg tudná oldani ... nem ?

Az első esetben: ott miért nem lehet ? Miért nem volt fontos, hogy itt is lehessen ?
A második esetben: akkor miér nem oldották meg ott is ugyanúgy mint az elsőben, minek kell a direkt főprogramba visszatérés ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 18:12:31
Az USR_ISR-nél az volt a szempont, hogy minél előbb kapja meg a vezérlést, így még a perifériakezelők meghívása előtt van meghívva.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 18:16:11
Hááát... imígyen elülső hallásra elég nagy kattyvassz ez néköm ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 18:19:59
Quote from: Z80System
Hááát... imígyen elülső hallásra elég nagy kattyvassz ez néköm ...
Játék/demóban úgyis teszel egy JP-t 38h-ra, és kész :-D
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 18:27:10
Ez így van, valóban, de egyrészt régen is az volt a hiba, hogy csak a legalapvetőbb dolgokat tanultam meg ahhoz, hogy aztan hardverből hajtsam a gépet, így hulye maradtam minden rendszerhez kapcsolodó dologhoz, másrészt bár most valóban játék demókat fogok csinálni, de (ha előbb meg nem halok) akkor szándékozok pár rendszerhez illeszkedő dolgot is csinálni, pld. az a betöltő dolog nagyon izgat továbbra is, lévén két program betöltése között marha sok idő elmegy mire megint ugyanoda navigálom vissza magam a rendszer ujraindulása után, de még az előtt egy olyan file managert is terveznék, amelyik program indítás előtt elmenti a helyét, és rendszer indítás után villámgyorsan ujraindul visszatöltve az állapotát, így lehetőséget adva a böngészés folytatására.

Szal szeretném megtanulni mi ez a vas és os, miközben itt demózgatok, hogy aztán majd már azokat is meg tudjam csinálni.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 21:37:55
Ezzel az OUT 191,12 -vel mekkora sebességnövekedést lehet elérni assembly cucc esetén ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 21:57:50
Quote from: Z80System
Ezzel az OUT 191,12 -vel mekkora sebességnövekedést lehet elérni assembly cucc esetén ?
Függ az utasítások hosszától, rövideknél többet, átlag lehet egy 10-15%
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.14. 22:01:05
És mi a gubanc vele ? Miért nem kapcsolja be a zozotools, vagy a fejlesztett exos ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.14. 22:32:45
EXOS 2.4-be megszavazta a nép :-D
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 10:02:14
Ha valakinek az az elborult ötlete támadna, hogy multithread programot ír EP -re, ami ugye technikailag mondjuk azt jelentené, hogy a program bekapcsolna valami nagyobb frekvenciás HW megszakítást, mittudom én egy 500Hz,1KHz,2Khz (vagy tovább felfele) azért legalább kellene, hogy a szálak folyamatosnak tűnjenek a valós időben. Úgy tudom lehet ilyen frekvenciájú megszakításokat bekapcsolni.

Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.

Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.

A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetésével (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 10:18:50
1 kHz-en valószínűleg legalább 10% (12 16 bites regiszter mentése és visszaállítása, megszakításkezelés, és annak az eldöntése, hogy melyik lesz a következő futtatandó szál).
Title: Re: Assembly programozás
Post by: lgb on 2013.April.27. 10:22:56
Quote from: Z80System
Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.

Amit akarsz azt CPU schedulernek hivjak, es altalaban ugye multitask OS-ek fontos resze, es pont igy mukodik :) Ott persze vannak olyan finomsagok, hogy ha egy process "sleep" allapotban van (pl I/O eredmenyere var, vagy a program azt mondja hogy sleep(10) ezert 10 sec-re nem kell futnia, stb) vagy nagyobb prioritast kert, akkor nem feltetlen rr (round-robin) sorrendben, linearisan kapja a cpu time slice-okat.

Amugy a primo emulatoromban is van hasonlo mar :) ha erzekeli hogy megnyomod az F1-et (ez a verzio meg nincs release-elve ...) akkor lementi a regisztereket (az egeszet Int handlerben nezi csinalja) es nem oda ter vissza, igy megkapja az ember a menut, ahol mar CPU allapotat, memoriat is lehet vizsgalni. Es persze vissza lehet terni az emulacio futtatasahoz is. Vegulis ezt is fel lehet ugy fogni, hogy ket program fut parhuzamosan ugymond, csak eppen a valtogatas koztuk user triggerelt es nem automatice :D A gondom csak az vele, hogy neha beall az egesz gep tole, de gyanitom hogy en rontottam el valamit valahol.

Quote
Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.

Ja, std time sharing system, amit anno az uts (unix time sharing) kepeben talaltak fel, es megszulettek a multitask OS-ek :)

Quote
A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetéséhez (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?

Az ezredmasodperccel az a gond, hogy gondold el, van overhead-je a context switchingnek (ha mar multitask OS szeru dolog, hasznaljuk a szakkifejezeseket onnan). Ha tul gyakran van, akkor egyre jelentosebb CPU idot visz el ez a muvelet, viszont annal folyamatosabbnak tunik az egyes szalak futasa. Linux eseten is csak std 100Hz volt anno amugy, most epp nem tudom :) meg az ujabb kernelekben mar dynamic tick stb is van (valtozik hogy mikor jon a kov scheduling interrupt attol fuggoen hogy a run queue-ban varakozo processekrol mit tud a kernel - azert is fontos ez mert ha tobb ideig nem kell egy process-nek sem a CPU akkor tovabb lehet halt-ba tenni vagy mas energiatakarekos modba lokni addig a cpu-t, ez pl notebook eseten nagyon durva kulonbsegeket okoz, hogy mennyire jo ebben az adott OS!). Imho egy Z80 eseten se erdemes 100Hz fole menni, felteve ha altalanos OS-t irsz ugymond, nyilvan ha valami specko celra kell, adott korulmenyek kozott, akkor lehet tobb, de a switching overhead-jere szamitani kell!
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 10:25:52
Hmmm... olyan területeken ahol a többszálúság önmagában megengedhető, és nem kizárt, akkor talan 10% nem is irdatlan áldozat ... Persze ez azt is mutatja, hogy kb. ez a gyakorlati határ, ha 2KHz -re mennénk, akkor ott már 20% lenne, 5KHz -en akkor 50%, és akkor ezek szerint 10Khz környékén már nem is futna a szálak kódja, csak a szálváltóé ... afelett meg ugye már a szálváltó is elnyelne, kihagyna megszakításokat ...
Title: Re: Assembly programozás
Post by: endi on 2013.April.27. 10:45:42
én a book of life játékomba ilyen x Hz-s digi lejátszást tettem megszakításba
arra emlékszem, hogy regiszter lementéssel kb használhatatlan lassúságú volt, ezért úgy oldottam meg hogy egy olyan regisztert használt amit máshol nem használtam a programban :)
mondjuk ez a hang miatt elég magas freki volt, bár hangminőség tekintetében persze gáz volt
ja meg hogy pont ebbe a játékba miért tettem ilyet, az érthetetlen... pont hogy inkább gyors render kellett volna
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 11:10:04
Most nézem, hogy a megszakításkezelő függvényben (C függvény) nem állítottam naked -re a függvényt, vagyis a C generált oda normal RET utasítást a végére, mégis működik a kód ... Miért nem baj az, hogy a megszakítás végén sima RET van, nem pedig RETI ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 11:14:26
Quote from: Z80System
Most nézem, hogy a megszakításkezelő függvényben (C függvény) nem állítottam naked -re a függvényt, vagyis a C generált oda normal RET utasítást a végére, mégis működik a kód ... Miért nem baj az, hogy a megszakítás végén sima RET van, nem pedig RETI ?
EP-n nincs jelentősége, és a RET gyorsabb is. A RETI-nek csak akkor van jelentősége, ha a hardver felsmeri ezt az utasítást, és a megszakításkérés törlésére használja, de EP-n szoftveresen kell törölni a megszakítást a B4h porton.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.April.27. 11:16:09
EP-n (és a legtöbb Z80-as házi számítógépben) teljesen jó a RET is. Akkor kell a RETI, ha rendes Zilog rendszer van kiépítve (SIO, CTC, PIO, DMA), ezek az IC-k észlelik a RETI utasításkódját, és ebből tudják, hogy a megszakításkérésük ki lett szolgálva.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 11:56:13
Igy néz ki a megszak kódom:


Code: [Select]
di

push af

ld a,#0x30
out (0xb4),a

ld a,#1
ld (_g_WasIRQ),a

pop af

ei

még néhany utasítás, aztan

ret



Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,
és van pár utasítás még a ret előtt.

Előfordulhat hogy a pár utasítás közben jön újra megszakítás igény, és rászakít a megszakításra ? Vagy azért az összes RET monitorozva van a CPU által, es megszakban egy RET előtt nincs újabb megszak ? Tehát mintegy kötelezővé van téve a CPU által hogy a megszakot valamilyen RET -tel kell zárni, és barmit is mókolok én a megszakokkal a megszakításkezelőben, RET előtt nem lesz újabb megszak ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 12:03:39
Quote from: Z80System
Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,
és van pár utasítás még a ret előtt.

Előfordulhat hogy a pár utasítás közben jön újra megszakítás igény, és rászakít a megszakításra ?
Ez nem probléma, feltéve, hogy a megszakítások egymásba ágyazása nem végtelen. A Z80 nem kezeli speciális módon a RET utasítást a rutin végén, a megszakításkezelés ugyanolyan, mint egy egyszerű DI + RST 38H utasítás. Arra is lehetőség van, hogy a B4h port törlése és az EI utasÍtás azonnal a rutin elején történjen, így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 12:15:06
Quote
így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.
Hmmm ... na erre még sosem gondoltam ... a megszakításkezelés innentől kezdve tényleg nem más mint egy szubrutinhívás, ami abban különbözik csak a call -tól, hogy nem általunk meghatározott helyen történik a kódunkban, hanem bárhol, ahol a megszak történik.

Csak az átlagfelhasználása az, hogy megszak kezelés első soraként letiltunk megszakokat, és utolsó soraként meg engedélyezzük őket, aminek a hatása akkor az lesz, hogy ultraminimálisra csokkentjuk az esélyét, hogy még a RET előtt bekövetkezzen egy újabb megszakítás, de igazából MEG NEM SZÜNTETJÜK a lehetőségét, elvileg lehetséges hogy az EI után de még a RET előtt megszakból megszakít újra.

Ebből viszont az is következik, hogy még csak nem is kötelező az előbb említett szál kezelő megszakításból előszor RET -et kiadva valami nulláslap szerű helyre rakott kódra ugrani, a stack megfelelő kezelése mellett akkor a megszakításkezelőből egyből ugorhatunk a kiválasztott új szálra, nem ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 12:27:31
Quote
a megszakításkezelés ugyanolyan, mint egy egyszerű DI + RST 38H utasítás
Akkor tök feleslegesen indul minden megszakítás kezelő kód ( amit csak láttam ) azzal hogy DI, mert mire megkapja a vezérlést a CPU által már rég le vannak tiltva ? :)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 12:41:30
Quote from: Z80System
de igazából MEG NEM SZÜNTETJÜK a lehetőségét, elvileg lehetséges hogy az EI után de még a RET előtt megszakból megszakít újra.
A Z80 érdekes tulajdonsága, hogy közvetlenül EI után nem fogad el megszakítást (még akkor sem, ha az EI előtt már engedélyezett volt, tehát például sok egymást követő EI futása közben átmenetileg tiltottak a megszakítások), tehát csak a RET után ugrik újra a megszakításkezelő rutinra.

Quote from: Z80System
Ebből viszont az is következik, hogy még csak nem is kötelező az előbb említett szál kezelő megszakításból előszor RET -et kiadva valami nulláslap szerű helyre rakott kódra ugrani, a stack megfelelő kezelése mellett akkor a megszakításkezelőből egyből ugorhatunk a kiválasztott új szálra ?
Igen.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 12:42:44
Quote from: Z80System
Akkor tök feleslegesen indul minden megszakítás kezelő kód ( amit csak láttam ) azzal hogy DI, mert mire megkapja a vezérlést a CPU által már rég le vannak tiltva ?
A DI nem kell, igaz, nem is árt, csak elfogyaszt néhány ciklust.
Title: Re: Assembly programozás
Post by: Z80System on 2013.April.27. 12:54:47
Quote
A Z80 érdekes tulajdonsága, hogy közvetlenül EI után nem fogad el megszakítást (még akkor sem, ha az EI előtt már engedélyezett volt, tehát például sok egymást követő EI futása közben átmenetileg tiltottak a megszakítások), tehát csak a RET után ugrik újra a megszakításkezelő rutinra.
Hát erre már csak azt tudom mondani, hogy: beszarás. :)

De legalább akkor aki betartja hogy EI,RET -tel zárja a megszakját, annak nem lesz megszakból megszakja, vagyis iskolapélda szerűen tudja használni, aki meg a megszakkezelőjében korábban adja ki az EI -t, az meg magára vessen, nyilván tudja mit csinál.

Egyébként letiltott megszakítások alatt (akkor előbbiek szerint az tökmindeggy, hogy főprogram vagy megszak "alatt" vannak letiltva) bekövetkező megszakok az engedélyezés után ( következő utasítás után ... :) ) egyből kiváltódnak z80 által, vagy pedig azokat a megszakokat már elbuktuk, és csak akkor váltódnak ki, ha a megszak pillanatában a z80 epp EI után van ? Ráadásul ha elbukós, akkor akár zsinórban többet is elbukhatunk ? Vagy nem elbukós, és kiváltódik, de csak 1X, pedig lehet hogy 10X volt már olyan megszak igény ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.April.27. 13:10:38
Quote from: Z80System
Egyébként letiltott megszakítások alatt (akkor előbbiek szerint az tökmindeggy, hogy főprogram vagy megszak "alatt" vannak letiltva) bekövetkező megszakok az engedélyezés után ( következő utasítás után ... :) ) egyből kiváltódnak z80 által, vagy pedig azokat a megszakokat már elbuktuk, és csak akkor váltódnak ki, ha a megszak pillanatában a z80 epp EI után van ? Ráadásul ha elbukós, akkor akár zsinórban többet is elbukhatunk ? Vagy nem elbukós, és kiváltódik, de csak 1X, pedig lehet hogy 10X volt már olyan megszak igény ?
A megszakításkérést (külön az 1 Hz-es, hang, és video megszakítást) a DAVE tárolja a B4h porton, és a törléséig aktív marad. Tehát ha DI és EI között kér megszakítást egy eszköz, az nem veszik el, feltéve, hogy nem érkezik újabb, azonos típusú megszakításkérés az első kiszolgálása előtt, vagy a program nem törli a B4h portot a megszakítás kiszolgálása nélkül.
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.04. 16:02:03
Grafikus ( tehát a kérdés szempontjából RND ) adatot akarok mozgatni pop/push -al, és igénybe venném ehhez az AF regiszterpárt is.

Kérdés hogy F -en keresztül is mozog az adat módosítás nélkül, ha nem teszek a pop és push közé olyan utasítást, ami flag -et állít ?

Mozog alatt azt értem, hogy a pop -al beolvasott byte fog kikerülni az F regiszterből is, illetve nem kuszálja össze a CPU -t semilyen beolvasott F regiszter érték ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.May.04. 16:09:20
Quote from: Z80System
Kérdés hogy F -en keresztül is mozog az adat módosítás nélkül, ha nem teszek a pop és push közé olyan utasítást, ami flag -et állít ?
Igen, az F is használható másolásra, illetve valószínűleg használni is kell (és az AF'-et is) ahhoz, hogy valóban gyorsabb legyen az LDI utasításoknál. A Z80 F regiszterében nincs olyan bit, amelynek az értéke nem változtatható, és egyiket sem használja speciális célra (pl. megszakítások engedélyezésére).
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.04. 16:15:27
jól emlészem hogy vannak valami atombiztosan működő "titkos" z80 opcode -ok, amivel lehet IX és/vagy IY regisztert 8 bitesként kezelni ? van ezekről valahol leírás ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.May.04. 16:22:50
Quote from: Z80System
jól emlészem hogy vannak valami atombiztosan működő "titkos" z80 opcode -ok, amivel lehet IX és/vagy IY regisztert 8 bitesként kezelni ? van ezekről valahol leírás ?
Ha az assembler támogatja, akkor egyszerűen IXL, IXH, IYL, és IYH regisztereket kell használni (egyes assemblereknél I nélkül). Ezek gyakorlatilag az L-t és a H-t helyettesítik. Nem lehet azonban egy utasításban IXL/H és IYL/H is, és az L, H, és HL regiszterekkel sem használhatók együtt, illetve a CBh prefixes utasításoknál sem működnek (ott a DDh/FDh prefixnek más hatása van). Tehát ezek az utasítások hibásak:
Code: [Select]
        LD    IXL, IYL
        LD    IYH, (HL)
        LD    IYL, H
        SLA   IXH
Ez viszont jó (LD L, H + DDh prefix):
Code: [Select]
        LD    IXL, IXH
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.04. 16:37:30
A z80 leírásom ezt írja az LDI -ről:

M Cycles        T States                        4 MHz E.T.
4                  16 (4, 4, 3, 5)                 4.00

ezt meg az egybájtos  PUSH/POP -ról:

M Cycles        T States                        4 MHz E.T.
3                  11 (5, 3, 3)                    2.75


Most akkor az első kérdés hogy ezeket így el lehet hinni, ezek ennyi idő alatt fognak lefutni ?

Mert ha így van, akkor legjobb esetben is 25% -ot lehet megtakarítani a push/pop -pal az ldi -hez képest ... nem biztos hogy első körben megéri szórakozni vele, tekintve hogy SP -t milyen nehéz kezelni a scanline -ok között, és sprite -oknál ráadásul tök rövidek a sorok, sp- nél nehézkes a forrás/cél közötti váltás is ... ha egy dupla sebességért csinálhatnám akkor megérné ... de vacak 25 % -ért már nem egy nagy nyeremény ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.May.04. 16:57:20
Itt beszéltünk (http://enterpriseforever.com/programozas/assembly-programozas/msg19649/#msg19649) ilyen PUSH/POP képmozgatásról.
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.04. 18:24:48
Mi a mák az "M Cycle" meg a "T State" ?
Title: Re: Assembly programozás
Post by: lgb on 2013.May.04. 18:53:40
Quote from: Z80System
Mi a mák az "M Cycle" meg a "T State" ?

Amennyire tudom: m-cycle az a machine cycle, ami Z80 szinten egy muveleti lepest jelent, es tobb orajelciklust (ez lenne a T) foglal magaban, ami 3-6 orajelciklusig tart. Az M-cycles kozul az elsot hivjak - meglepo modon - az elsonek, azaz M1 (az ha minden igaz az opcode fetch lenne, ezt jelzi a Z80 is az M1 laban). Ha esetleg valahol tevedtem volna, javitsatok ki, mar kb egy evtizede volt, amikor Z80 emulatort irtam (vagy hmmm probaltam irni).

Ez a fo kulobseg a Z80 es a 65xx kozott: ez utobbinal nincs kulon, ott egy elemi muvelet (pl memoriaolvasas) pontosan egy "valodi" orajelciklusig tart, ezert ott a memoriat az orajellel engedlyezik es egy RW/RD jel van egyetlen vezeteken "kodolva" a muveletet, mivel az orajel egy szintjen (PHI2) _mindig_ es _mindenkeppen_ memoriamuvelet van. Ezert a 65xx ugyan gyorsabb, amde a memoria sebessege limitalo tenyezo, ezert van, hogy 65xx relative alacsonyabb orajellel mentek mint a Z80 (modern 65xx cpu-k 20Mhz-en is elmennek ma mar, igaz ehhez pl - ha jol szamolom 25ns - realisan nezve mininum 10-20ns - sebessegu RAM kell).

Most megprobaltam rakeresni is, hogy jol irtam-e le a dolgokat, es meglepo modon wikipedian egesz jol ott van meg 65xx 68xx-rol is pont irnak! Itt: https://en.wikipedia.org/wiki/Zilog_Z80#Instruction_execution (https://en.wikipedia.org/wiki/Zilog_Z80#Instruction_execution)
Title: Re: Assembly programozás
Post by: lgb on 2013.May.04. 19:38:29
Quote from: Z80System
jól emlészem hogy vannak valami atombiztosan működő "titkos" z80 opcode -ok, amivel lehet IX és/vagy IY regisztert 8 bitesként kezelni ? van ezekről valahol leírás ?

Szerintem ez egesz jo leiras az "erdekesebb" vagy nem tul jol dokumentalt z80 dolgokrol: http://www.z80.info/zip/z80-documented.pdf (http://www.z80.info/zip/z80-documented.pdf)

Illetve ez is erdekes lehet: http://www.z80.info/decoding.htm (http://www.z80.info/decoding.htm)

Ez utobbi alapjan csinalgattam a disassemblert az epbas projectembe hogy ne kelljen minden opcode-t leirni, legyen vmi logika, ami alapjan talan tomorebben dekodolhato disasm szinten is :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.04. 20:00:40
Alapból kb. mennyi hely van szabadon hagyva az FF szegmensből aza exdos által ? Tehát ha nem nyitottunk meg különösebben semmit, csak úgy elindult a gép, esetleg egy exdos vagy epdos épp fut ?Van mondjuk kb. 2000H üres terület az FF szegmens alsó végén ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.May.04. 20:15:19
Quote from: Z80System
Van mondjuk kb. 2000H üres terület az FF szegmens alsó végén ?
Nincs.
Title: Re: Assembly programozás
Post by: lgb on 2013.May.04. 20:17:40
Quote from: Z80System
Alapból kb. mennyi hely van szabadon hagyva az FF szegmensből aza exdos által ? Tehát ha nem nyitottunk meg különösebben semmit, csak úgy elindult a gép, esetleg egy exdos vagy epdos épp fut ?Van mondjuk kb. 2000H üres terület az FF szegmens alsó végén ?

Tipp: exos 22-es funkcio? Az megmondja, bar ha jol tudom akkor az FF "elfogyasa" eseten folytatodik masik szegmensben a dolog, es akkor a boundary ott ertelmezett, az FF szegmens meg ugye total foglalt. Amugy is, emlekezven Zozo intelmeire: nem illik csak ugy system szegmensbe irni, hanem az exos boundary dolgokra illene odafigyelni. Ezt mondjuk nem tudom, hogy mi van, ha meg lenne szabad szegmens, de en a shared szegmensnek hasznalnam megis pl az FF-et, mert nem akarok "elpazarolni" egy uj szegmenst, hogy allokaljam, ha csak kis terulet kell. Mert ha jol ertem, set exos boundary nem engedelyezett, ha nincs shared szegmens :(

Probaltam osszeszerencsetlenkedni egy ilyen kis egyszerut, ami vegulis az exos 22 es 20 hivas eredmenyet jeleniti meg. Lehet, nincs sok ertelme (vagy akar el is szurtam vmit) de legalabb gyakorlok :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 12:38:33
Á, hát bakker van.

4 byte széles (12 pixel magas) block -ot akarok kimásolni (egy sprite lenne, mindenféle durva megkötéssel, már maga a méret is gyökér, pláne hogy csak simán kimásolni fogom, így majd nem mehetnek 3 pixelnél közelebb egymáshoz), szóval 4 X 12 bájtos block -ot akarok kimásolni a képre, és próbáltam gyorsítani pop/push -al, gyakorlatilag pont ugyanannyi lett, semmit nem gyorsult ... :(

Szóval lehet hogy a pop/push gyorsít, de nem ilyen rövid szakaszokban másolva.

A fenti példában a sima ldi tartja vele a lépést.

Közben a scanline -jaimat meg 100H -s határra tettem a függőleges (scanline) címszámítás egyszerűsítéséhez/gyorsításához, ami azt eredményezi, hogy a scanline -jaim között viszonylag sok "üres" byte van, ahova a sprite/grafikus adatokat szándékozom tenni, viszont így most azok is a video memóriában vannak, tehát a videó memória lassítása a grafikus adat olvasásakor is benne van a képletben, nem csak a képre íráskor.

Komoly overhead lehet a video memória lassítása ... ? Az csak ilyen 10%, vagy pedig videó memóriából fele sebességgel olvas, mint sima memóriából ?

Persze mindíg az a legjobb, ha az ember kipróbálja, de ki tud olyan sok verziót kipróbálni ...
Title: Re: Assembly programozás
Post by: IstvanV on 2013.May.05. 12:44:13
Quote from: Z80System
Komoly overhead lehet a video memória lassítása ... ? Az csak ilyen 10%, vagy pedig videó memóriából fele sebességgel olvas, mint sima memóriából ?
Több egymást követő LDI utasítás átlagos sebessége:
- normál RAM -> normál RAM: 16 ciklus
- normál RAM -> video RAM: ~18 ciklus
- video RAM -> video RAM: ¬22.5 ciklus
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 13:05:09
Kemény volt ez a mikrovilág ... Egyenlőre úgy tűnik, hogy az 50 Hz -es keretekbe majd mondjuk 6-10 ilyen 13X13 ( :) ! ) pixeles ellenség, egy főhős, néhány lövés, meg pár csillag (olyan kevés, hogy még nem is tudom lesz -e csillagfüggöny hatása, vagy csak pár kóricáló pixel lesz) fog kb. beleférni. Max ...

Pedig mindenképp olyan vackot akartam volna, ahol tetszőlegesen beállítható a frame szám, mert képes 50 Hz -en is menni ...

Lehet két edition kell majd belőle, egy olyan ahol fenti paraméterekkel tetszőlegesen állítható az FPS, és egy olyan amit mondjuk 25 FPS -ről indulva lehet csak lassítani majd, de abban akkor már lehet is valami a képen ...

És akor még sehol nincsenek a hangeffektek, pláne hogy valami (nagyon rossz minőségű), de digi hangokat (nem zenét, csak lövéshangok, ilyesmik) gondoltam volna, de ha ezt még beszaggatom valami mittudomén 1- 8Khz -el, hogy valami rekedtmedve hangok lehessenek, azzal sztm le is zúznám ezt a maradékot is ...

Hájjájjájj ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 13:26:43
Na így állunk ...

A kék sáv a "sprite" ideje, ami már tartalmazza a törlést is, meg a kimásolást is.
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 13:29:45
Az az okkeros, sárgás szín meg a billentyűzetbeolvasás 10 port irása/olvasása ... :) Szánalom, komolyan mondom ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 14:47:22
Na, de azért fog ez működni ... majd valahogy összetvíkelem.
Title: Re: Assembly programozás
Post by: Z80System on 2013.May.05. 15:32:42
Érdekes, hogy régről nem emlékszem erre az érzésre, ami most kezd kialakulni a géppel kapcsolatban, hogy az ember (lassan persze, de régen egyáltalán nem) elkezdi érezni, hogy mennyi az a 64Kb, mire elég, mire nem, meg a teljesítmény, meg az egész hardver.

Mikor az ember mikróra programozik az egész vasat használja, ahogy van. Nem csak az ismeretlen nagy teljesítményű rendszer egy kis részét használja 127 áttételen keresztül, egy kisebb feladat megoldására, hanem mint egy citromból, facsarja ki az ember a teljes anyagot, ami benne van.

Ez egész más érzés mint ami most van, és érdekes, hogy régen nem emlékszek erre az "átlátásra", egyrészt az info kevesebb volt, másrészt az ember mindíg azt hitte, hogy csak ő nem tud megvalósítani ezt vagy azt, valahogy nem látta az ember, hogy a 64 ezer az "pontosan mennyi", az olyan őrült soknak tűnt mindíg, aztán mégsem volt elég soha semmire ... :)

Vagy csak már elfelejtettem, hogy is volt ez ...
Title: Re: Assembly programozás
Post by: geco on 2013.May.06. 10:05:09
Quote from: Z80System
Az az okkeros, sárgás szín meg a billentyűzetbeolvasás 10 port irása/olvasása ... :) Szánalom, komolyan mondom ...
A sprite kirakásos kék sáv jónak tűnik nagyon, a billentyűolvasásos sárga egy picit soknak.
Title: Re: Assembly programozás
Post by: lgb on 2013.May.06. 10:57:03
Jut eszembe a fentebb mellekelt idetlen "sysinfo" dolgom kapcsan: van EP-re valami komolyabb cucc sysinfo kategoriaban? Mondjuk lehetne benne CPU sebesseg meres esetleg teszt is (CMOS/NMOS, ami ugye EXOS2.3-ban hmm 2.4-ben? is van), memoria, bovitok listaja, esetlegesen I/O sebesseg teszt mondjuk disk read/write cimszo alatt, stb stb stb.
Title: Re: Assembly programozás
Post by: szipucsu on 2013.August.23. 12:58:39
Az ASMON-ban R gombbal betöltünk file-t. Ha nem tudjuk a file hosszát, pl. BFFF-et adunk meg END-nek, és kiírja End of file-lal az utolsó címet. Mentésig még módosítunk ezt-azt, de addigra eltűnik az utolsó cím a képernyőről, tehát fel kell írni. Nincs valami más lehetőség, hogy később visszanézzük az utolsó címet, hogy meddig kell menteni az S-sel?

(Nem tudom, ebbe a topikba illik-e ez leginkább.)
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.August.23. 13:03:56
Fel kell írni egy darab papírra, akkor vissza lehet nézni :-)
Vagy megnézni az eredeti fájl méretét, és akkor ki lehet számolni.
Title: Re: Assembly programozás
Post by: szipucsu on 2013.August.23. 13:14:27
Quote from: Zozosoft
Fel kell írni egy darab papírra, akkor vissza lehet nézni :-)
Én így a XXI. században papír helyett Printscreen-t használtam. :ds_icon_cheesygrin:
[attachimg=1]
Azt hittem, az Asmon is vissza tudja nézni. Ezek szerint nem.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 18:33:30
Hát a kérdésem alig assembly jellegű, de azért ide írom.

Én ugye most PC -n fejlesztek (imitálom), és egy PC fordítóval fordítok EP binárist, majd azt az emulátorba töltve tesztelem.

Namost a fordítóm egy C fordító, ami tud inline assebly -t ugyan, és a kód nagyja abban fog készülni, de a C -t is használnám, a nem sebesség kritikus részekhez.

Csakhogy mintha valami baromi nagy lenne a fordított kód méretet tekintve.

Tud esetleg valaki valami jó kis C->z80 tárgykód fordítót ?
Title: Re: Assembly programozás
Post by: lgb on 2013.October.26. 20:31:27
Quote from: Z80System
Hát a kérdésem alig assembly jellegű, de azért ide írom.

Én ugye most PC -n fejlesztek (imitálom), és egy PC fordítóval fordítok EP binárist, majd azt az emulátorba töltve tesztelem.

Namost a fordítóm egy C fordító, ami tud inline assebly -t ugyan, és a kód nagyja abban fog készülni, de a C -t is használnám, a nem sebesség kritikus részekhez.

Csakhogy mintha valami baromi nagy lenne a fordított kód méretet tekintve.

Tud esetleg valaki valami jó kis C->z80 tárgykód fordítót ?

Te mit hasznaltal amivel "tul nagy" lett a kod merete? En tudok az sdcc-rol ami Z80-ra tud forditani, meg volt az a z88dk vagy ilyen nevu, de az nem tud mindent, amit elvileg a C nyelvnek kene. Amugy altalanossagban elmondhato, hogy a nagy meretu kod oka altalaban az, hogy hasznalod pl a printf, scanf vagy egyeb hasonlo fuggvenyeket. Ezek altalaban legalabb 4K kod, mivel ugye azok tudnak minden hulyseget, formazast, stb. Probalj ki egy minimalis programot pl egy tok ures main fuggvenyt, minden nelkul, hogy akkor milyen meretu lesz az eredmeny.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 20:40:31
Ja sdcc -vel tolom, de tudni tudok még a z88dk -ról is (bár valamiért az sdcc -t tudtam összelőni, a másikat meg hagytam, pedig abban sokkal jobban hasonlít az assembly mnemonik -ok formája az eredetihez), és igen, ha lehagyom a float -os számításokat (mást nem használok a könyvtár kódjából), akkor nem linkel hozzá egy vagon kódot, de azután sem tetszik a méret ... ahogy a síma kódot írom, pár forciklust bedobok és 100H -kkal nő a kód ... most nem emlékszem a konkrétumokra, de valahogy úgy emlékszem, hogy attól kellett tartsak, hogy írok kis kódot és kicsúszok a 16K -s lapomról ...
Title: Re: Assembly programozás
Post by: lgb on 2013.October.26. 22:03:20
Quote from: Z80System
Ja sdcc -vel tolom, de tudni tudok még a z88dk -ról is (bár valamiért az sdcc -t tudtam összelőni, a másikat meg hagytam, pedig abban sokkal jobban hasonlít az assembly mnemonik -ok formája az eredetihez), és igen, ha lehagyom a float -os számításokat (mást nem használok a könyvtár kódjából), akkor nem linkel hozzá egy vagon kódot, de azután sem tetszik a méret ... ahogy a síma kódot írom, pár forciklust bedobok és 100H -kkal nő a kód ... most nem emlékszem a konkrétumokra, de valahogy úgy emlékszem, hogy attól kellett tartsak, hogy írok kis kódot és kicsúszok a 16K -s lapomról ...

Hat nem tudom ... Esetleg nezd meg amit assembly-be lenyom (vagy -S kapcsoloval, akarmi), es hasonlitsd ossze egy ilyen "novekedes" utan hogy mi valtozott az asm file-ban az elozohoz kepest. Amikor en jatszottam sdcc/EP ugyben akkor belefutottam egy sdcc bug-ba, amit jelentettem is nekik (https://sourceforge.net/p/sdcc/bugs/2089/) (ez is meretnovekedest okoz).

Title: Re: Assembly programozás
Post by: endi on 2013.October.26. 22:04:31
az ilyen méretnövekedésekre a memóriabővítés a megoldás :)
tanulhatnátok a billgatestől :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 22:10:27
Quote
Hat nem tudom ... Esetleg nezd meg amit assembly-be lenyom (vagy -S kapcsoloval, akarmi), es hasonlitsd ossze egy ilyen "novekedes" utan hogy mi valtozott az asm file-ban az elozohoz kepest. Amikor en jatszottam sdcc/EP ugyben akkor belefutottam egy sdcc bug-ba, amit jelentettem is nekik (https://sourceforge.net/p/sdcc/bugs/2089/) (ez is meretnovekedest okoz).

Hát köszi, de elég gáz nekem az EP is, nem akarnék most fordítót analizálgatni PC -n ...

Inkább valami kompakt "megoldásra" gondoltam, hogy "na akkor használd ezt meg ezt, ez működik és ennél sokkal tömörebbet nem lehet".

Most inkább "EP -zek" ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.October.26. 22:26:49
Van egy olyan gyanúm, hogy ami témában te nyomulni szeretnél ott el kell felejteni a magas szintű nyelveket, méret és sebesség okán. Assembly és kész :oops:
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 22:33:27
Quote
Van egy olyan gyanúm, hogy ami témában te nyomulni szeretnél ott el kell felejteni a magas szintű nyelveket, méret és sebesség okán. Assembly és kész (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)

Hát ja, és ennek okán akkor simán el lehetne felejteni a PC -t is akár (bár elég barátságtalannak éltem meg még a HEASS -t is a múltkor, miker ezzel próbálkoztam, pedig mennyivel jobb mint egy sima ASMON), hiszen ha csak assembly, akkor mér ne lehetne egyből EP -n,

de az az igazság, hogy olyan jó lenne az inicializáló részeket, mint LPT legenerálása, betöltés utáni memóriába eltolva letárolások, színtáblák, színusztáblák, objekt mozgatási adatok, ilyesmiket gyorsan C -ben írni meg, és majd a legvégén vagy soha nem optimalizálni le, hogy próbálok vergődni a C - vel ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.October.26. 22:47:04
A mindenféle táblákat adatokat lehetne esetleg úgy, hogy a C program adatfájlba írja ki, amit majd betölt a program.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 22:48:04
A legjobb az lenne, ha valahogy rá lehetne bírni a C fordítót, hogy tudjon lapozni futás közben ... és akkor emuban fel lehetne tolni a memória csúszkát akármeddig, és mehetne az ereszdelahajam C -ben ... De hát álmodozással nem megyünk semmire ugye, akárcsak a nyafogással ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 22:51:31
Quote
A mindenféle táblákat adatokat lehetne esetleg úgy, hogy a C program adatfájlba írja ki, amit majd betölt a program.
Hát persze ... és akkor már nem is kellene EP -re fordítani, hanem futhatna PC -n az adat file kimentő ...

Csak akkor kell annak is egy külön projekt és mindíg végig kell gondoljam mit kell kimentsek/töltsek, így meg lefut ugye az EP program futtatásakor ...

Mondjuk lehet jobban járok vele ha mentek töltök már az elejétől, mert eszetlen lassan számol színuszt az EP ... :) Nem ilyenre van ez kitalálva ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.October.26. 22:59:47
Quote from: Z80System
A legjobb az lenne, ha valahogy rá lehetne bírni a C fordítót, hogy tudjon lapozni futás közben ...
Elvileg létezik ilyen. (http://www.softools.com/scz180.htm) Csak sok pénzért adják :-(
Title: Re: Assembly programozás
Post by: lgb on 2013.October.26. 23:07:19
Quote from: Z80System
Hát persze ... és akkor már nem is kellene EP -re fordítani, hanem futhatna PC -n az adat file kimentő ...

Csak akkor kell annak is egy külön projekt és mindíg végig kell gondoljam mit kell kimentsek/töltsek, így meg lefut ugye az EP program futtatásakor ...

Mondjuk lehet jobban járok vele ha mentek töltök már az elejétől, mert eszetlen lassan számol színuszt az EP ... :) Nem ilyenre van ez kitalálva ...

Ja, hat nem ... Azt is lehet, ami demokban is szokasos technika: amig valami egyszeru dolog van kinn (kezdokepernyo, mittomen') addig kozben kiszamolja (kozben lehet int-bol zene stb), de tarolja is a tablat, aztan kesobb mar csak felhasznalja, amikor tenyleg kell neki. Sinus-ra meg rengeteg optimalizalt megoldas is van (kozelitessel viszonylag kis hiba nelkul minden float/akarmi hasznalata nelkul is - igaz erre 65xx-re tudok hirtelen csak linket (https://plus.google.com/108984290462000253857/posts/X2mzfRHAemP), z80-ra nem), vagy esetleg nem tudom mennyi valosagalapja van annak (Bruce is beszelt errol) hogy BASIC rutinjait meghivni asm-bol pl a sin()-re. Az se lesz gyorsabb persze (sot ...) de ha van ido vmikor kiszamolni akkor imho jo, es a kodmeret verhetetlen lesz majdnem (csakhat kell hozza basic, ami ep-n nem 100% h mindig van, bar altalaban szerintem azert szokott megiscsak - hacsak nem cserlenek cartridge-t, es nincs 64k rom az alaplapon).
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.October.26. 23:26:49
Quote from: lgb
csakhat kell hozza basic, ami ep-n nem 100% h mindig van
A matekrutinok ha minden igaz pont az 1-es szegmensben maradtak.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 23:40:42
 (http://www.softools.com/scz180.htm)
Quote
Elvileg létezik ilyen. (http://www.softools.com/scz180.htm) Csak sok pénzért adják (http://enterpriseforever.com/Smileys/phpbb/ds_icon_sad.gif)

Próbaverziójának nekiugrottam anno, mikor mondtad, de már nem emlékszem hogyan, de rosszabb eredményeket sikerült elérnem vele mint az SDCC -vel.

Inkább hagytam ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.26. 23:41:32
Quote
Sinus-ra meg rengeteg optimalizalt megoldas is van (kozelitessel viszonylag kis hiba nelkul minden float/akarmi hasznalata nelkul is - igaz erre 65xx-re tudok hirtelen csak linket (https://plus.google.com/108984290462000253857/posts/X2mzfRHAemP), z80-ra nem), v
Hát ez marha jó ... Ilyeneket miért most kell megtudjak ...
Title: Re: Assembly programozás
Post by: lgb on 2013.October.27. 07:25:32
Quote from: Z80System
Hát ez marha jó ... Ilyeneket miért most kell megtudjak ...

Hat azt en honnan tudjam :) De az biztos, ogy komolyabb demoknal nagy multja van a matematikai kozeliteseknek, hogy lehet egesz muveletekkel szinten barmit megcsinalni, ugye jol jott ez meg C64 (de csak azert irom ezt, mert errol van tapasztalatom) meg 3D gyorsitokartyas PC-k elotti demok vilagaban, ahol akar egy phong/gouraud shading-et kell megprobalni belezsufolni par gepi kodu utasitasba, kulonben nem fog menni real-time .... stb :)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.October.27. 10:56:29
Ahogy azt lgb mondja. Az ilyen erőforrás hiányos rendszereken a játék~ és demoprogramozás mindig arról szól, hogy valamit elcserélsz valamire. A cserélhető dolgok a memória és a processzor órajel ciklusok. Ha valamit bonyolult kiszámolni, azt táblázatokra cseréled. Ha túl sokáig tart betölteni, legenerálod. A tecsövön vannak is ilyen videók, ahol pl. 64-es demokóderek magyarázzák el viszonylag érhetően, hogyan is működik ezeknek a "trade-off-oknak" a hangolása. Pl.: http://www.youtube.com/watch?v=So-m4NUzKLw&list=PL08C12B1B6ABA3328&index=1 (http://www.youtube.com/watch?v=So-m4NUzKLw&list=PL08C12B1B6ABA3328&index=1)
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.27. 11:08:46
Ebből nem lesz vita, azt azonban mégsem gondoltam volna, hogy mondjuk színusz számolásra ( most nem érdekes hogy mi közelít mihez mennyire ) van pár integer utasításos változat ...

Ami attól még érdekesebb, hogy köröket meg rajzolgattunk ha jól emlékszem pár utasításos verziókkal ...

Mind1.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.27. 17:16:04
Na akkor most 3 napi "megfeszített" munkám eredménye képpen "még jobban" be van kapcsolva egy LPT, és működik a backbuffering ... :)

Viszont ha csak egyik bufferbe rajzolok valamit, az vas EP -n olyan szokott lenni, hogy vibrál és a vibrálásból kifolyólag, mivel a másik képen feketeség van, ezért sötétebb mint ha rendesen ki lenne rajzolva.

Ez emun is látszik, mert villog, de elég összevissza, lárszik hogy nem ugyanannyi ideig van a két kép a képernyőn. Tehát vibrálás közben hol erősebben, hol gyengébben látszik.

Próbáltam a video opcióknál a resample -t is, meg a framebuffereket, meg amit csak találtam, de nem múlt el.

Ez ennyit tud, ne is keressem a megoldást ?

Valószínűleg ha ilyen pontatlanul vannak a képen a dolgok, ez a normál működésen, játékokon is meg kell latszon ... nem ?
Title: Re: Assembly programozás
Post by: szipucsu on 2013.October.28. 12:08:38
Quote from: endi
Én már addigra csináltam egy alap pályaeditort (delphi+asm), régebbi munkáimra alapozva. Mondtam neki hogy azt folytassa inkább. Főnök is mondta neki. De ráhagytuk.
Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte. Átnézni, "visszafejteni", ráhangolódni külön idő. Én a basic programokkal mindig így voltam.
Aztán biztos vannak nagyon penge elméjű emberek, akik csak ránéznek az addig elkészült kódra, mindent átlátnak benne és továbbírják, mintha ők kezdtél volna.
Title: Re: Assembly programozás
Post by: Z80System on 2013.October.28. 12:27:52
Quote
Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte.

Igen, sajnos a 2 dolog eléggé különbözik, mikor te írod a kódot, akkor az egész felől haladsz a részletek felé, míg mikor más kódját érted meg, akkor a részletekből haladunk ugye az egész fele, a részletekből kell összeálljon az egész ...

Míg az elsőnél elég egy analítikus (sokszor ez is hiányzik) gondolkodásmód, "józan paraszti ész" is, addig a másodiknál kicsit zseninek kell lenni. Persze teljesítménytől függően ... Egy for ciklusban lévő részletek azonnali "koncepcióva" gyúrása az én képességeimet sem haladja meg, de mikor az ember kap egy 200 ezer soros programot amit addig még nem is látott, hogy hát ez most ilyen, nekünk meg inkább legyen olyan, ráadásul tegnapra ... hát ott már az átlag ész kicsit szalajtani kezd ...

Én emlékszem, az általános iskolában a hülye táblázatokon mindig bebuktam ... matekórán ... mikor kaptál egy táblázatot, fel kellett ismerd a kitöltött elemek alapján a szabályt, és ki kellett tölteni a maradékot ... sose jöttem rá a szabályra ... persze időre, végtelen idő alatt bármit lehet. Ez sztm ugyanaz mint ismeretlen kódot olvasni, és meglátni az összefüggéseket benne. És ez sztm nem is fejleszthető ... Aki megkapta annak összeáll mint a mátrix, aki nem az meg kaparhat.
Title: Re: Assembly programozás
Post by: endi on 2013.October.28. 12:38:52
Quote from: szipucsu
Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte. Átnézni, "visszafejteni", ráhangolódni külön idő. Én a basic programokkal mindig így voltam.
Aztán biztos vannak nagyon penge elméjű emberek, akik csak ránéznek az addig elkészült kódra, mindent átlátnak benne és továbbírják, mintha ők kezdtél volna.
Persze, viszont ahogy emlékszem a srác kb semmit se kérdezett, értette a kódomat magától is. Pedig csak alap szinten volt felkommentezve.

Amúgy egy 4 szintű parallax scrollos tile grafikás (gameboy advanced ilyesmit tud) editor volt. Valójában az editálás a rajzolóprogramban történt (Deluxe Paint!!!). Ezt a képet töltötte be a programom, detektálta a képen az azonos tile-okat (tükrözést is, mert a gameboy azt is tud hw-ből) és ezek alapján elmentette a megfelelő adatokat (tile-k, pálya stb.)
Szóval ezt láttad az én editoromban, lehetett scrollozni (4 szintű parallax scroll), ugyanakkora képernyő volt mint a gameboyon, mellette meg az editor kezelő gombjai. Itt az editorban a munka az volt, hogy meg kellett adni hogy mivel ütközöl, mi sérít, mindenféle egyéb adatok beállítása stb.
Meg persze meg volt írva egy csomó alap dolog, buttonok, szövegkiírás stb.

De mondom, a srác kb semmit se kérdezett, simán tudta használni a kódomat. Amit aztán ő beleépített az kb ilyesmik hogy ellenségeket lehetett lerakni, megadni milyen útvonalon, területen mozognak meg ilyesmik.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 11:54:44
Jól gondolom, hogy SP regisztert használó memória olvasó/író kódoknál a megszakítás le kell legyen tiltva ( vagy valahogy máshogy kell biztosítani, hogy ott ne legyen megszak ), mert különben a megszak kinyírja az értelmes adatokat ?

Egy kivétel lehet ez alól, mikor csak írok vele, és a megszak mindíg közvetlen elé írna, így nem értékes adatokat felülírva ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.01. 12:23:36
Jól.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 12:28:40
Na még egyszer a memória késlekedéséről ...

Múltkor mikor kérdeztem erről, mindenféle trükkös ábrákat, meg ilyesmiket kaptam válaszul, ami elhiszem, hogy frankón és részletesen leírja az összes esetet, de nekem valami viszonylag gyorsan feldolgozható infóra van szükségem, nem baj, ha nem 100% pontos.

Arról szeretnék képet kapni, hogy standard EP esetében (esetleg megkülönböztetve a 2 RAM típust) mennyire kell figyelembe vennem a RAM -ot igénylő utasításoknál, hogy nem a CPU leírásnál megadott órajelekbe fog az nekem kerülni.

Tehát ha le van írva, hogy az LD r, (HL) 1.75 órajel, akkor az tényleg annyi lesz, tehát az össz ideje ennyi, vagy csak valami ideális, 0 késlekedési idejű memóriával lenne ennyi, és valójában az EP esetében ez 10 órajel ideig fog tartani ?

Vagy egy másik aspektusban, mikor maga az utasításkód van a memóriában (mind ott van, csak az egyik nagyobb, mint a másik), akkor pld. az LD r,n az 1.75 órajel szintén, és akkor ebből az következne, hogy egy EXX és ld a,b az együtt hosszabb lesz, mint az ld a,n, mert az EXX+ld a,b az ugye 2 órajel. Nade az ld a,n esetében az n is memóriában van, és ha annak van egy 10 órajeles memória késlekedése, akkor ez máris nem igaz.

Tehát hogy lehet gondolkodni ezekkel, mekkora nagyságrendű a memóriahozzáférések késlekedése EP -n, mind az operandusok esetén, mind pedig a beolvasott utasításkód esetén ?
Title: Re: Assembly programozás
Post by: endi on 2013.November.01. 12:34:00
ha jól emlékszem vannak táblázatok amikben egzaktul le van írva minde z80 utasítás ideje
Title: Re: Assembly programozás
Post by: endi on 2013.November.01. 12:34:56
megszakításról: ilyenkor a visszatérési cím SP-n tárolódik? tehát nem lehet olyan megszakítást írni amiben nincs SP használat?

már nem emlékszem :) bár azt nem tudom miért akarok emlékezni :D
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 12:48:17
Quote
ha jól emlékszem vannak táblázatok amikben egzaktul le van írva minde z80 utasítás ideje

Jól emlékszel, ezektől a táblázatokról szólnak a kérdéseim.


Quote
megszakításról: ilyenkor a visszatérési cím SP-n tárolódik? 

ja.


Quote
tehát nem lehet olyan megszakítást írni amiben nincs SP használat?

Zozo válasza alapján: ja.

Quote
már nem emlékszem (http://enterpriseforever.com/Smileys/phpbb/smiley.gif) bár azt nem tudom miért akarok emlékezni (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Mert ha nem próbálnál meg visszaemlékezni, akkor nem éreznéd alapját annak, hogy alig vonatkozó butuskásokat kotyoghass ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 14:13:47
Visszakerestem, valójában a régi faggatózásomra ezt a választ kaptam IstvanV -től, nem a táblázatokat, amikre emlékeztem:


Quote
Normál (nem video) RAM és ROM között szerintem nincs különbség, és az ezekhez való minden hozzáférésnél 0 vagy 1 Z80 ciklus késleltetés van a 0bfh I/O port beállításaitól függően. Az utasítás első  (vagy ha van CB, DD, ED, vagy FD prefix, akkor az első két) byte-jának az olvasása "M1" hozzáférés, aminél a késleltetést külön lehet szabályozni. Az "ld a, (hl)" normál RAM-ban futva és az alapértelmezett késleltetésekkel 8 ciklus, mert 4+1 az utasítás, és 3 az adatbyte olvasása. A video memória és a NICK I/O portok (080h-08fh) elérésekor a NICK busz órajeléhez kell szinkronizálni (~890 kHz), és ez 1 és 5 Z80 ciklus közötti késleltetést jelenthet; a 0bfh portnak ilyenkor nincs jelentősége.


De sajnos ebből a régi válaszban szereplő példából nekem még nem következik az, hogy össze tudnám hasonlítai a fenti 2. példában szereplő eseteket ...

De ha azt is összehasonlítaná valaki, lehet hogy a két válaszból már sikerülne leszűrnöm a szabályosságokat, hogy hogyan tudom megállapítani, hogy kb. akkor X utasítás, amire azt írjak, hogy 1.75 ciklus, az akkor mégis miért lesz 8 ciklus ...


Még támpontnak mondom, hogy a doksi ír ilyen értékeket is, hogy:


M Cycles : 1
T States : 4
4 MHz E.T. : 1.00


Ez mondjuk az "inc r" volt.


Tehát ha úgy könnyebb logikát adni a kiszámításra, hogy ezek is rendelkezésre állnak, akkor állnak ...
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.01. 14:16:25
Quote from: Z80System
De ha azt is összehasonlítaná valaki, lehet hogy a két válaszból már sikerülne leszűrnöm a szabályosságokat, hogy hogyan tudom megállapítani, hogy kb. akkor X utasítás, amire azt írjak, hogy 1.75 ciklus, az akkor mégis miért lesz 8 ciklus ...
Az "1.75 ciklus" az valószínűleg 1.75 us, azaz 7 ciklus (T-state) 4 Mhz-es órajelen.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 14:29:27
Quote
Az "1.75 ciklus" az valószínűleg 1.75 us, azaz 7 ciklus (T-state) 4 Mhz-es órajelen.

Oks, lehet marhaságokat irkálok össze, akkor vegyünk konkrétan egy 1.75 -öst:

LD r, (HL)

Operation: r ← (HL)
Op Code: LD
Operands: r, (HL)
Description: The 8-bit contents of memory location (HL) are loaded to register r,
where r identifies register A, B, C, D, E, H, or L, assembled as follows in
the object code:
Register r
A 111
B 000
C 001
D 010
E 011
H 100
L 101

Condition Bits Affected: None

M Cycles : 2
T States : 7 (4, 3)
4 MHz E.T. : 1.75

Az "E.T." az az "estimated time" lehet, nem ?

Kérdés, akkor ezekből az adatokból hogyan számolok én egy olyan "abszolút időt" amivel abszolút értékben jól össze tudom hasonlítani 2 utasítás idejét ?

Mert ha csak az E.T. értékkel simán összehasonlítom őket, akkor abból az jön ki, amit előbb írtam: az EXX+ld a,b az hosszabb idő, mint az ld a,(hl).

Márpedig gyanús, hogy ez durván nem így van ...
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.01. 14:36:15
Quote from: Z80System
Mert ha csak az E.T. értékkel simán összehasonlítom őket, akkor abból az jön ki, amit előbb írtam: az EXX+ld a,b az hosszabb idő, mint az ld a,(hl). Márpedig gyanús, hogy ez durván nem így van ...
Miért ne lenne így ? Az EXX + LD A, B 2 utasítás olvasás (2 * 4 ciklus = 8 ciklus), az LD A, (HL) pedig egy utasítás és egy adat olvasás (4 + 3 = 7 ciklus). Az EP az alapértelmezett beállításokkal az utasítás olvasási (M1) műveleteknél vár 1 ciklust, ezért így az utasítások időtartama 10 (2 * 5), illetve 8 (5 + 3) ciklus lesz; a várakozás azonban letiltható. Video RAM-ban pedig átlagosan ~18 (2 * ~9) és ~13.5 (~9 + ~4.5) ciklus alatt futnak le ezek az utasítások.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 14:47:59
Quote
Miért ne lenne így ? Az EXX + LD A, B 2 utasítás olvasás (2 * 4 ciklus = 8 ciklus), az LD A, (HL) pedig egy utasítás és egy adat olvasás (4 + 3 = 7 ciklus). Az EP az alapértelmezett beállításokkal az otasítás olvasási (M1) műveleteknél vár 1 ciklust, ezért így az utasítások időtartama 10 (2 * 5), illetve 8 (5 + 3) ciklus lesz; a várakozás azonban letiltható. Video RAM-ban pedig ~18 (2 * ~9) és ~13.5 (~9 + ~4.5) ciklus.
Oks, akkor tehát egyrészt szerinted a megadott "4 MHz E.T." értékeimmel igenis összehasonlíthatom az utasításaimat, és azok az EP kiépítésében is viszonylag jól tükrözik az utasítások abszolút idejeit ha nem video ramban fut a kód (és persze hogy nem), pláne ha még az EP "direkt" lassító várakoztatásait is kikapcsoljuk?

(Mert a szent tervezők szentül meg voltak győződve, hogy ha nem tesznek kéziféket a rendszerbe csontig behúzva, akkor a z80 -ban lévő lóerők egyszerűen levetik a gépet az asztalról, így az nem lesz stabil ... :))

Másik meg, hogy hivatkozol itt utasítás és adatolvasási ciklusokra, ezeknek idejei mindíg 4 és 3 órajel, akkor is ha akárhány bájtos az utasítás (hisz sokbájtos utasítások is vannak) vagy az adat (hisz van 8 és 16 bit adat is) ?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.01. 14:54:08
A legegyszerűbb, ha letiltod a várakozást (OUT 191, 12), és kerülöd a video RAM használatát, ha lehetséges. Ilyenkor az utasítások a Z80 dokumentációban megadott "T states" ciklus alatt futnak le (NOP = 4 ciklus, JP = 10 ciklus, stb.).
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 15:26:27
Quote
A legegyszerűbb, ha letiltod a várakozást (OUT 191, 12), és kerülöd a video RAM használatát, ha lehetséges. Ilyenkor az utasítások a Z80 dokumentációban megadott "T states" ciklus alatt futnak le (NOP = 4 ciklus, JP = 10 ciklus, stb.).

Hmmm ... akkor ha ilyet olvasok mondjuk az

LD (IY+d), n

utasításnál:

T States : 19 (4, 4, 3, 5, 3)

akkor ez megválaszolja a korábbi kérdésemet,

vagyis ezekből úgy tűnik, hogy egy bonyolult utasításnál akkor lehet több az olvasási ciklusokból ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 17:24:38
Le tudja valaki írni pár szóban, hogy hogyan kell digitális hangot kelteni az EP -n ?

Valami olyan szintű leírás kéne, hogy "kapcsold ezt a portot erre, annak a portnak meg amazt a bitjét amarra, és akkor írd a sample -t ide meg ide".

Ugyanez kéne a nagyfrekis megszakítás bekapcsolásához is. Hogy mit kell állítani, és hova, hogy mondjuk legyen egy 5KHz -es megszakításom.
Title: Re: Assembly programozás
Post by: Ferro73 on 2013.November.01. 19:02:00
Engem olyan Link érdekelne ahol Z80 rutinok forrás kódjai található. Pl sorrendbe rendező; Hex2Dec; hex2ASCII; (nn)=HL*DE....
A hálón nem találom de lehet rosszul keresem. Emlékszem volt ilyen.
Nekem elveszett  
Esetleg a linkekhez is belehetne tenni. Vagy valahol az oldalon is lehetne gyűjteni a legjobbakat.
Előre is köszönöm
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.01. 19:14:29
Ezekben (http://enterpriseforever.com/programozas/hisoft-pascal/msg35541/#msg35541) az éppen most feltöltött programokban található néhány egyszerű matematikai és grafikai rutin, amelyeknek talán valamennyire hasznát lehet venni:
- 8 * 16 -> 16 bites szorzás (előjel nélkül)
- 16 * 16 -> 32 bites szorzás (előjeles és előjel nélküli)
- 16 bites előjeles sin()/cos() szorzás (a szög felbontása 1.40625 fok)
- 2 színű képernyőn vonal húzása és feltöltés (FILL)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 20:54:20
Annyi lenne a digi hang keltés, hogy a 0xa7 port b3,b4 -ét egybe állítom, aztán meg írom a 0xa8 és 0xac port alsó hat bitjét ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 21:17:17
Miért van a 0xb4 portnak 4 külön kezelhető megszakítása ?

A port bitenként értelmezett:
b0 A hanggenerátor által adott megszakítás engedélyezése. (1 érték által)
b1 A hanggenerátor megszakítás tároló törlése.
b2 Az 1 Hz-es megszakítás engedélyezése.
b3 Az 1 Hz-es megszakítás tároló törlése.
b4 A video-megszakítás engedélyezése.
b5 A video-megszakítás tároló törlése.
b6 A soros vonal megszakításának engedélyezése.
b7 A soros vonal megszakítás tárolójának törlése.

Hiszen az 1Hz,50Hz,1KHz és valami csatornafüggő megszak is (gondolom az kell a 4KHz -hez) ugyanúgy gondolom egy forrásnak számít ...

Tehát elég volna egy video (gondolom ami jon az LPT -ből), egy audio (gondolom az előbbi 4 típus valamelyike) és egy soros vonal megszak bit. Miért van az 1Hz külön ? Az miért külön forrás ?

És amikor én 4KHz megszakot akarok, akkor azzal lefoglalom az egyik hanggenerátor csatornámat, mert kell a megszak frekibeállításához (nekem most nem lenne gáz, csak csodálkozok, hogy mér) ?

Mindenesetre még nem jöttem rá, hogy kell bekapcsolni a 4Khz megszakot.
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 21:44:46
Az 1Hz-es az órához kell, ha jól emléx.
Beállítod az A7-es portot, 40-re, vagy 60h-ra, attól függően, hogy melyik hanngenerátort szeretnéd időzítésre használni , utána a kiválasztott hanggenerátor két frekiportjban megadod a megfelelő értéket, és tolhatod az a8, ac porton a digi értékeket megszakból (frekvencia = 250,000/(n+1) ) , és a végén
ld a,03h
out (0b4h),a
-val aktiválod a hanggenerátor által gerjesztett megszakítást,
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 21:55:32
Quote
Az 1Hz-es az órához kell, ha jól emléx.
Tehát van még egy külön egy herces megszakítás, ami párhuzamosan tud jönni a hang megszakkal ? Tehát az 1Hz -es hang megszak mellett van még egy külön "nem hang" megszak 1 Hz ?


Quote
Beállítod az A7-es portot, 40-re, vagy 60h-ra, attól függően, hogy melyik hanngenerátort szeretnéd időzítésre használni , utána a kiválasztott hanggenerátor két frekiportjban megadod a megfelelő értéket, és tolhatod az a8, ac porton a digi értékeket megszakból (frekvencia = 250,000/(n+1) ) , és a végén 
ld a,03h 
out (0b4h),a
-val aktiválod a hanggenerátor által gerjesztett megszakítást,

Tanx, kipróba.
Title: Re: Assembly programozás
Post by: endi on 2013.November.01. 21:57:56
ezekről megint előjönnek az emlékek :)

emlékszem, az marhára csalódás volt nekem hogy a megszakítás típusokat is nekem kellett lekezelni kódból
plusz a verem használata...
berak az ember 2 féle megszakítást amik semmit se csinálnak, és elég nagy frekin mennek, máris a proci idő nagy % elveszett
totál gáz :(
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:13:30
Quote from: endi
ezekről megint előjönnek az emlékek :)

emlékszem, az marhára csalódás volt nekem hogy a megszakítás típusokat is nekem kellett lekezelni kódból
plusz a verem használata...
berak az ember 2 féle megszakítást amik semmit se csinálnak, és elég nagy frekin mennek, máris a proci idő nagy % elveszett
totál gáz :(
Hát igen, de valahol még ilyen lehetőséged sincs, mert van a videjó, oszt gatter :D
CPC-n is alapból 300 Hz-es megy, és azon belül vizsgálják, hogy melyikben van a videó megszak.
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:15:30
Quote from: Z80System
Tehát van még egy külön egy herces megszakítás, ami párhuzamosan tud jönni a hang megszakkal ? Tehát az 1Hz -es hang megszak mellett van még egy külön "nem hang" megszak 1 Hz ?
Az a hang 1 Hz valójában 1 Khz :D , de ha akarod, akkor pl van a videó 50 Hz -ed mellett egy Dave által generált 50 Hz is, a Net megszakítás nem tudom milyen sűrűn érkezik.
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:25:47
Quote from: Z80System
Tanx, kipróba.
No para :)
Majd  a digi hangokat a lejátszás előtt konvertáld át előjeles 8 bitből előjel nélkülibe, ami wav konvertereket láttam, azok csak előjelesbe tudtak konvertálni, és aztán letolni 6 bitessé.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 22:32:54
Quote
Az a hang 1 Hz valójában 1 Khz (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) , 
De nézdcsaknézdcsak, ez a Dave leírásból van:

"Four latched interrupts are provided, a 1Hz interrupt for time clock applications, an interrupt switchable between 50Hz, 1KHz or the outputs of tone generators 0 or 1"

Vagy ez tulképpen 2 interrupt, csak mindkettőt a Dave generálja, viszont külön forrásnak számít,

és a másik meg, a komplex az csak három féle lehet: 50Hz,1KHz,és beállított ? És akkor a beállított az olyankor tényleg nem tud szólni, mert le van ezzel foglalva ?
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:39:09
Quote from: Z80System
De nézdcsaknézdcsak, ez a Dave leírásból van:

"Four latched interrupts are provided, a 1Hz interrupt for time clock applications, an interrupt switchable between 50Hz, 1KHz or the outputs of tone generators 0 or 1"

Vagy ez tulképpen 2 interrupt, csak mindkettőt a Dave generálja, viszont külön forrásnak számít,

és a másik meg, a komplex az csak három féle lehet: 50Hz,1KHz,és beállított ? És akkor a beállított az olyankor tényleg nem tud szólni, mert le van ezzel foglalva ?
Sztem igen.
Húha, szerintem szólhat, de a hang frekvenciája megegyezik majd a megszakítás számára beállított frekivel.
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:45:04
Leteszteltem, szól a hang is, bár nem tudom mit lehetne kezdeni egy állandó hanggal, vagy egy változó sebességű megszakítással, lehet ezekből is ki lehetne hozni valamit.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.01. 22:50:13
Oksa, ebből már elvileg össze kéne tudjam akkor rakni. Meglátjuk mi lesz.
Title: Re: Assembly programozás
Post by: geco on 2013.November.01. 22:56:22
Menni fog, a múlt hétig nekem se volt gőzöm se, hogy is működik a dolog (a portbeállítások megvoltak, de hogy utána mi a h.nyás...), de aztán letisztult a kép :lol:
Title: Re: Assembly programozás
Post by: lgb on 2013.November.02. 10:18:10
Quote from: geco
Leteszteltem, szól a hang is, bár nem tudom mit lehetne kezdeni egy állandó hanggal, vagy egy változó sebességű megszakítással, lehet ezekből is ki lehetne hozni valamit.

Hat ha meg torzitod meg modulalod akkor erdekes :) mert AFAIK megszakitasnal csak az alap negyszegjel szamit, ha hangkeltesben felhasznalod valami "extra" modon kozben, az nem zavarja az interrupt-ot.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 13:03:32
Ha jól értem, akkor a 0xb4 portot olvasni is lehet, és a megfelelő bitek azt adják meg, hogy most melyik megszakítás vagy mindjárt megszakítások miatt van a megszakítás ?

Viszont törölnöm (mindkét az aktuális megszakításhoz hozzá rendelt bit 1 -be állításával) csak mindíg azt szabad, ami le volt nullázva ?

Tahát ha a 0xb4 -ről olvasva azt kapom hogy csak a video megszak miatt triggerelődött a megszakításom, akkor csak a video megszak funkcionalitását szabad elvégezzem, és a végén csak a video megszak 2 bitjét szabad 1- be állítanom,

de ha mondjuk a video és audio megszak egyben jött, akkor mindkettőt el kell végezzem, és mindkettőnek a bitjeit 1 -be kell állítsam a végén ?

És a két megszakot törölhetem két külön portírással is, vagy csak egyben lehet mindkettőt ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 13:15:15
Az in és out utasítás mechanizmusában nincs ilyen külső hardvertől függő lefutási idő ?

Tehát in/out -nál a proci kiteszi az értéket az adatbuszra, vár egy kicsit, a külső eszköz meg vagy lekapta onnan, vagy nem,

vagy pedig kirakja, és ott vár mindaddig, míg a külső eszköz nem jelez, hogy levette az anyagot ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 17:45:41
Na, nagy nehezen összehoztam, műxik a digi hang, bár igen sokat lassít, ahogy vártuk is. Küzdök a 2 csatorna implementációval, és az lenne a kérdésem,

hogy ugye a nem dokumentált utasításkódok használata többé már nem ajánlott, mióta Zozo az újfajta procik integrálását tűzte ki egyik célul, és azok nem feltétlen támogatják a nem dokumentált utasításokat.

De mi van a magát módosító kóddal. Amennyire tudom, sima z80 alatt az nem igazán probléma, de az újakkal mi a pálya ? Azok is simán bírják a módosuló kódot, vagy ott már belépnek a code cache -ek, meg ilyesmik ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.02. 17:51:41
Quote from: Z80System
De mi van a magát módosító kóddal. Amennyire tudom, síma z80 alatt az nem igazán probléma, de az újakkal mi a pálya ?
Nincs vele gond.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 19:18:27
Na, egyenlőre a következő lett a megszakom.

Lapozással, jobb és bal csatornára két különböző hang írással, 4KHz -en, szemre úgy 25-30% -al visz több időt a főprogram futása ha ez is megy alatta. Ha valahol elnéztem vagy elszámoltam valamit, akkor mégse.

A megszak az összes árnyékregisztert használja.

Igazából azért vettem előre a hangot, és ezért ezt a megszakot, mert ennek sebességéhez kell igazítsam a többit, ha megcsinálom az egészet, és aztán derül ki, hogy a hang miatt mégse jó, félő hogy nem kerülne bele a hang végül.

Szóval ha van tipp, hogy hogyan lehetne felgyorsítani, az nem volna rossz.


Code: [Select]
void IRQ() __naked
{
__asm

di

ex af, af                                  ;csak árnyékregisztereket használunk

in a, (0xb4)                              ;megnézzük, hogy hang megszak jött -e
and #0x2

jr z, IRQ_NoAudio                      ;ha nem hang elugrunk oda, ezzel kizártunk minden zavaró tényezőt a lehető leggyorsabb hang megszakhoz,
                                               ;vagyis a video vackai nem lassítják tovább a hangot

ld a, #D_Ints+ 0x2                    ;tehát akkor hangmegszakunk van itt már
out (0xb4), a                           ;ha már itt van A regiszterben, ilintézzük a 0xb4 sorsát

exx                                        ;még mindíg csak árnyékot használunk, melyben elő van készítve főprogram által:
                                                     ;DE= egyik minta
                                                     ;HL= másik minta
                                                     ;b= egyik minta vége után lévő cím felső bájtja
                                                     ;c= másik minta vége után lévő cím felső bájtja
                                                     ;tehát a hangminták csak 256 -os igazításon és hosszon vannak

ld a, #0xf9
out (D_Page1), a                      ;belapozzuk a hangminta szegmenst

ld a, d
cp b                                       ;ellenőrizzuk, hogy elértük -e már a hangminta végét
jr nc, IRQ_AudioEnd0                 ;ha elértük átugorjuk a minta kezelését

ld a, (de)                                ;betöltjük a mintát
out (0xa8), a                           ;kiirjuk a mintát
inc de                                    ;növeljük a minta címét

IRQ_AudioEnd0:

ld a, h
cp c                                       ;ellenőrizzuk, hogy elértük -e már a másik hangminta végét
jr nc, IRQ_AudioEnd1                 ;ha elértük átugorjuk a minta kezelését

ld a, (hl)                                ;betöltjük a másik mintát
out (0xac), a                           ;kiirjuk a mintát
inc hl                                    ;növeljük a minta címét

IRQ_AudioEnd1:

ld a, #0xfc
out (D_Page1), a                      ;visszatesszük az ellapozott lapunkat

exx

ex af, af

ei

ret                                         ;ez egy audio megszak volt, visszatérünk. azt remélem, hogy ha itt volt video megszak IS az audio mellett,
                                                     ;akkor az a visszatérés után újra kiváltódik majd egyedül, hang megszak nélkül

IRQ_NoAudio:

ld a, #D_Ints+ 0x20                   ;ha ide eljöttünk, akkor ez egy video megszak, és ez már nem számít, mert ez sokkal kevesebbszer fut csak le
out (0xb4), a

ld a, #1
ld (_g_WasIRQ), a

ex af, af

ei

ret

__endasm;
}


Title: Re: Assembly programozás
Post by: endi on 2013.November.02. 19:31:23
minek lapozgatni a hangnál? nem fog a game beleférni 64k-ba? :)
giga game lesz ebből a szempontból is, már látom :)
de ez csak jó! volt egyáltalán olyan EP game ami több mint 64k-t használt?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 20:31:48
Quote
Szóval ha van tipp, hogy hogyan lehetne felgyorsítani, az nem volna rossz.

Hmmm ... lehet, hogy eszembe jutott egy jó ötlet ...

Egy 4K -s megszakítás 80X fut le 2 video megszak között. Tehát ha a hangok mögé teszek mondjuk 100 bájtnyi üreset, akkor tovább futhat a hang és ráérek lekapcsolni a video megszakban ... magyarul így a hang megszak hang kezelésének a felét kidobhatom ... :)

Ez jónak tűnik nagyon ...
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.02. 20:55:19
Segíteni sajnos nem tudok, csak imádkozni érted, hogy Zozo meg ne lássa a fix szegmenscímeket. :ds_icon_cheesygrin:
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 20:58:50
Quote
Segíteni sajnos nem tudok, csak imádkozni érted, hogy Zozo meg ne lássa a fix szegmenscímeket. (http://enterpriseforever.com/Smileys/phpbb/ds_icon_cheesygrin.gif)
Ja, de ha lesz ebből bármi is, akkor a fix címeket simán át lehet írni önmódosító kóddal, mikor EXOS -osítani akarja valaki. Kb. 3 helyen lesz benne lapozás, és forrásállományban rendelkezésre fog állni az egész.

Bárki azt csinálhat vele, amit csak akar.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.02. 21:07:29
Quote from: ergoGnomik
Segíteni sajnos nem tudok, csak imádkozni érted, hogy Zozo meg ne lássa a fix szegmenscímeket. :ds_icon_cheesygrin:
Készültem szóvá tenni :-)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 21:25:08
Na az előző hozzáadásával (most még a videomegszakba nem építettem bele a lekapcsolást, mert az 80X ritkábban fut le, tehát oda bármit is rakok elég gyors lesz), ilyenre módosult a megszak (mostmár nem kommenteztem be, aki az elsőt érti, latni fogja a két EXX közötti marha nagy különbséget):


Code: [Select]
void IRQ() __naked
{
__asm

di

ex af, af

in a, (0xb4)
and #0x2

jr z, IRQ_NoAudio

ld a, #D_Ints+ 0x2
out (0xb4), a

exx

ld a, #0xf9
out (D_Page1), a

ld a, (de)
out (0xa8), a
inc de

ld a, (hl)
out (0xac), a
inc hl

ld a, #0xfc
out (D_Page1), a

exx

ex af, af

ei

ret

IRQ_NoAudio:

ld a, #D_Ints+ 0x20
out (0xb4), a

ld a, #1
ld (_g_WasIRQ), a

ex af, af

ei

ret

__endasm;
}


És igazából ugyanennek akkor lehet készíteni egy ilyen verziót is, ami talán egyetlen hajszálnyival gyorsabb mint az előző:



Code: [Select]
void IRQ() __naked
{
__asm

di

ex af, af

in a, (0xb4)
and #0x2

jr z, IRQ_NoAudio

ld a, #D_Ints+ 0x2
out (0xb4), a

exx

ld a, #0xf9
out (D_Page1), a

ld c, #0xa8
outi
ex de, hl

ld c, #0xac
outi
ex de, hl

ld a, #0xfc
out (D_Page1), a

exx

ex af, af

ei

ret

IRQ_NoAudio:

ld a, #D_Ints+ 0x20
out (0xb4), a

ld a, #1
ld (_g_WasIRQ), a

ex af, af

ei

ret

__endasm;
}



De ami viszont nagyon érdekes. Mindkét verzióra igaz, hogy mégha egymáshoz képest nincs is nagy különbség, de az előzőhöz képest azért komoly különbséget vártam ...

És nincs. Azért jobb, ezeket fogom alkalmazni, nem az elsőt, de csak ha 5% -ra javult ... tehát akkor mostmár mondjuk fix 25% a lassulás az előző 30% -hoz képest ... Persze mindez szemre a raszteridőn, de akkor is ... Többet vártam.

Úgy látszik a többi megszak kód, az exx -ekkel, meg a b4 írással, video megszak megkülönböztetéssel, lapozással és talaán magának a CPU -nak a megszak overhead- jével mindez sokkal nagyobb tétel, mint maga a tényleges hangadás ... így hiába gyorsítottam halálba a hangkiadást, akkor is lassú maradt egészében ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 21:34:14
Viszont ezzel, hogy a video megszakban fogom lekapcsolni a hangot, ezzel akor megszünt a hangokra mind a 256 align limit, mind pedig hogy 256 -al osztható hosszúságú kell legyen,

Az egyetlen megkötés akkor az lesz a hangmintákra (pld 4KHz. megszak esetén), hogy a hangminták után kell legyen mondjuk 90 byte csend.

A video megszak meg majd észreveszi hogy már a csendet játsza, és mielőtt elfogyna a csend a hang mögül, átváltja majd egy külön csend hangra, amit mindíg újra és újra bevált, míg valaki be nem kapcsol igazi (nem csend) hangot.
Title: Re: Assembly programozás
Post by: geco on 2013.November.02. 22:02:17
Mit szólsz ahhoz, ha a videó megszakítást el is hagyod?, akkor nem kell figyelgetni, és egy csomó időt megspórolsz, mivel 50 FPS-es játékot szeretnél, a videó megszakítás részt tedd a főprogramba, pont az 50 Hz-es várakozás után.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:06:35
Quote
Mit szólsz ahhoz, ha a videó megszakítást el is hagyod?, akkor nem kell figyelgetni, és egy csomó időt megspórolsz, mivel 50 FPS-es játékot szeretnél, a videó megszakítás részt tedd a főprogramba, pont az 50 Hz-es várakozás után.

A hangmegszakítás 4KHz -el pörög a digi hanghoz ... Nem értem milyen 50 Hz -es dologra gondolsz, ami nem video ... És milyen 50 Hz -es várakozás ...
Title: Re: Assembly programozás
Post by: endi on 2013.November.02. 22:13:12
én továbbra se értem minek bele a lapozás
Title: Re: Assembly programozás
Post by: geco on 2013.November.02. 22:13:39
Ne legyen videó megszakításod, csak a programozható, ami most videó megszakításos rész, legyen a főprogramban.

főprogram 50Hz -re való várakozás:

Code: [Select]
w50  in   a,(b4h)
     bit  4,a
     jr   z,w50
     call eredetilegmegszakításbanlévő50Hzrutin
.
.
.
a főprogram további része
Így csak a progamozható megszakításod lesz, és nem kell csekkolni semmit, csak egy 03h-t küldeni a b4h portra.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:24:10
Quote
Ne legyen videó megszakításod, csak a programozható, ami most videó megszakításos rész, legyen a főprogramban.

főprogram 50Hz -re való várakozás:
Aham ... tehát azt állítod, hogy a video megszak bit akkor is beállítódik az LPT által, ha a video megszakítás a b4 -en valójában tiltva van,

és z80 -al is simán lehet csekkolni/törölni a megszak igény bitet a b4 portban ?

Ha ez igy van, akkor nagyon királyosnak tűnik !

Nem is gondoltam volna, hogy így van, azt hittem azt a bitet csak a megszakból lehet érzékelni ...

Ill. hát mégis van egy gond ezzel ... Nem 100% -osan leszek 50 FPS. Menni akarok 50 FPS -sel, de menni akarok tetszőleges beállított FPS -sel is ... és akkor ilyenkor a 50 FPS villogtatással kevert színek nem tudnának működni ...

Ennek ellenére lehet hogy mégis alkalmazni fogom. Megnézem mennyit gyorsít a hangképzésen, és ha eleget, akkor hozok egy olyan kompromisszumot, hogy a színvillogtatást külön ki lehet majd kapcsolni (csak olyankor rondább lesz a grafika) viszont akkor továbbra is igaz marad, hogy csontra ugyanolyan (grafika is) verzióban lehet majd összehasonlítani a különböző sebességverziókat.

Szóval baromi jó ötletnek tűnik ... megpróbálom. Tanx!
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:28:58
Quote
én továbbra se értem minek bele a lapozás
Pedig 1Xű. B0 -án van a program (C is) kód, meg a mozgás adatok, főleg utóbbi miatt még szűk is lehet, másik három lapon meg a video ram van, screen meg sprite adatok.

Ezzel kész is. Máris 64K. Ha digi hangot akarok, akkor már mér ne sokat, ami mutat is valamit ? És van még másik 64K kihasználatlanul a legalapabb EP -ben is.
Title: Re: Assembly programozás
Post by: endi on 2013.November.02. 22:32:23
Quote from: Z80System
Pedig 1Xű. B0 -án van a program (C is) kód, meg a mozgás adatok, főleg utóbbi miatt még szűk is lehet, másik három lapon meg a video ram van, screen meg sprite adatok.

Ezzel kész is. Máris 64K. Ha digi hangot akarok, akkor már mér ne sokat, ami mutat is valamit ? És van még másik 64K kihasználatlanul a legalapabb EP -ben is.
jó értem én. tehát giga mennyiségű és minőségű grafika és effekt lesz benne
mert ügye 64k-t egy EP játék se használt ki eddig
(specy128-as igen, de az most más téma)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:33:19
Quote
Ha digi hangot akarok, akkor már mér ne sokat,
Még az is lehet, hogy teljes digi zenét le stream -elek alá az egyik oldalon ... vagy legalább ambienteket ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:34:02
Quote
Még az is lehet, hogy teljes digi zenét le stream -elek alá az egyik oldalon ... 
Kis Metallica -t alá ... :)
Title: Re: Assembly programozás
Post by: geco on 2013.November.02. 22:37:32
Egyszerű a megoldás (nem tökélestes), ha 25fps-t akarsz, akkor két helyre teszel wait50hz-et, csak jól kell kiválasztani a második helyét, ha meg át akarsz térni 50-re, akkor önmódosító kóddal törlöd a 2-dikat.
Úgy vettem észre, hogy a 4. bit 1-be billen, amikor eléri a megszakításbájtot tartalmazó LPB-t a NICK, és törlődik, amikor áttér a következő LPB-re.
Én is ezt használom időzítésre, csak tiltott megszakítás mellett.
Ja, a videó RAM-ból való olvasás, és írás is lassít egy picit.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:38:00
Quote
És van még másik 64K kihasználatlanul a legalapabb EP -ben is.
Persze a 64K gépek buktak ...

Majd vesznek 512K belső bővítést ... :)

Vagy teszek bele opciót, hogy 64K gépen némán megy majd.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.02. 22:39:22
Quote from: Z80System
Az in és out utasítás mechanizmusában nincs ilyen külső hardvertől függő lefutási idő ?

Tehát in/out -nál a proci kiteszi az értéket az adatbuszra, vár egy kicsit, a külső eszköz meg vagy lekapta onnan, vagy nem,

vagy pedig kirakja, és ott vár mindaddig, míg a külső eszköz nem jelez, hogy levette az anyagot ?
Ilyet tud a Z80-as rendszer, de az EP-ben nincs használva.
Azonban a videó portoknál ugyanúgy várnia kell a Z80-nak, mint a videó RAM-nál.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:44:53
Quote
Úgy vettem észre, hogy a 4. bit 1-be billen, amikor eléri a megszakításbájtot tartalmazó LPB-t a NICK, és törlődik, amikor áttér a következő LPB-re.

Hát ezt most nem értem. Beszéljünk video megszakról. Ott 2 bit van, az egyik a 16 a másik meg a 32. A 16 -ot kikapcsoltan kell tartani ezekszerint, hogy az a CPU -t ne szakítsa meg, és te azt állítod, hogy a 32 ettől függően, főprogramban is ugyanúgy kezelhető és ellátja a funkcióját, mintha megszakból birizgálnám, nem ?

Ha egyszer a 32 beallt egyre, akkor az már magától ne törlődjön ! Én majd reszetelem (1 -essel) és addig várok, míg legközelebb be nem áll. De ne törlődgessen magától! (Mondjuk persze elég gyorsan észre fogom venni ... úgyhogy még törlődhet is ... igaz.)

Quote
Én is ezt használom időzítésre, csak tiltott megszakítás mellett.
Hát a videot akkor én is tiltanám. Arra gondolsz, hogy neked egyáltalán nincs semmilyen megszak, hang sem, és az hátha bekavar ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:46:52
Quote
tehát giga mennyiségű és minőségű grafika és effekt lesz benne
Hat 150X150 -es képernyőfelbontásnál nehéz giga mennyiségről beszélni ... de amit találok belekonvertálom. Mit veszíthetek vele.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:49:38
Quote
giga mennyiségű és minőségű
Minőség ... 4KHz hang ... :)

De lesz valami. Az bizti. Ha előbb meg nem halok.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 22:54:46
Quote
Ennek ellenére lehet hogy mégis alkalmazni fogom. Megnézem mennyit gyorsít a hangképzésen, és ha eleget, akkor hozok egy olyan kompromisszumot, ho
Ááááá mégsem ... :(

A hangkeltés épp azon alapul, hogy a hangok végén lesz annyi üres hely, hogy 50 Hz -en belül nem fut ki belőle a lejátszó ...

Most akkor ha le akarnám a játékot tudni lassítani 10 frame -re, akkor tíz frame -nyi csendet kéne tudjak letárolni a hangok mögé ... az már 1 kilóbájt plussz hangonként ... :)

Na ezt végig kell még gondolni ... nagyon sokat kell gyorsítson, hogy ennek ellenére már bevállaljam ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 23:07:38
Quote
Egyszerű a megoldás (nem tökélestes), ha 25fps-t akarsz, akkor két helyre teszel wait50hz-et, csak jól kell kiválasztani a második helyét, ha meg át akarsz térni 50-re, akkor önmódosító kóddal törlöd a 2-dikat.
Nem én 1-5, vagy még jobb lenne 1-10 frame között tetszőlegesen beállíthatót akarok. Úgyhogy ez nem lesz így esetenként megcsinálva. Általános kód lesz, max kisebb kompromisszumokkal ...

De azért mindenesetre megnézem mennyit gyorsítana a gyakorlatban.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 23:11:21
Igazából ezt a három utasítást spórolná meg ...

 
Code: [Select]
in a, (0xb4)
and #0x2

jr z, IRQ_NoAudio


Valszeg nem éri meg ...
Title: Re: Assembly programozás
Post by: geco on 2013.November.02. 23:18:13
Lecsekkoltam, a programozható bekavarna, ha azt várná az ember, hogy mikor törlődik a 4. bit, ugyanis a megszakításban kiadott 03h a b4h portra, tröli a 4. bitet is, majd az visszaáll egybe, addig, amíg vagy nem nullázza újra a megszakítás, vagy el nem érjük a következő LPB-t.
Ez egy jó megoldás lehet így is, ha a videómegszakítást tartalmazó LPB max 3, nagyon max 4 sor hosszú, és ciklusban várakoztatod a cuccot, kb így:

Code: [Select]
     ld   b,0ffh
w50a  in   a,(0b4h)
      bit  4,a
      jr   z,w50a
      di
w50b  in   a,(0b4h)
      bit  4,a
      jr   nz,w50b
      ei
      djnz w50a
Title: Re: Assembly programozás
Post by: geco on 2013.November.02. 23:35:56
Quote from: Z80System
Igazából ezt a három utasítást spórolná meg ...

 
Code: [Select]
in a, (0xb4)
and #0x2

jr z, IRQ_NoAudio


Valszeg nem éri meg ...
Elméletileg ez 500 NOP lenne 1 frame-ben.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.02. 23:55:05
Quote
Elméletileg ez 500 NOP lenne 1 frame-ben.
Ebben biztos vagy ? Az valami 6-8 rasztersor, nem ? És a 60-80 raszterhez képest amit vinne ez egy egész frame esetén az olyan 10 % lenne akkor ...
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 00:10:05
Hát úgy számoltam, hogy a 3 utasítás 11+7+7=25 T-state megszakításonként, ami most másodpercenként 4000, két 50Hz-es megszakítás között 80 programozható esik be, 1 NOP 4 T-state, 80x25/4=500.
Ha jól számoltam, akkor több, mint 7.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 00:17:32
Quote
Ha jól számoltam, akkor több, mint 7.
Ja, én is így számoltam. Csak én már a te 500 NOP -odból indulva.

Hát habozok a dolgon egyenlőre ... meglátjuk mennyi helyem lesz a hangok mögött ...

Még ezzel a gyorsulással is vagy 60 raszterbe kerül a digi hang ... elég súlyos ... lehet még kaparhatnám lefele 3KHz -re, és lehetne inkább csak egy csatorna monóban ...

Meglátom.

De azért tanx, jó kis tweak ...
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 00:18:48
Endinek igaza van, legalább az egyik lapozást meg lehetne spórolni a megszakításban, kevesebb lassulást okoz ha a 3 videólapot lapozgatod két szegmensen, mikor mi kell, az egyik szegmens lehetne fixen a digi hangé, az is kb 300 nopot jelentene.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 00:23:15
Quote from: Z80System
Még ezzel a gyorsulással is vagy 60 raszterbe kerül a digi hang ... elég súlyos ... lehet még kaparhatnám lefele 3KHz -re, és lehetne inkább csak egy csatorna monóban ...
Sztem tök jó a 60 raszter, még marad egy csomó időd, most járok 60 raszternél, és 5 ojjektum mozog a képen, és amilyen ámátőr vagyok, tutter lehetne ezt gyorsabban is, szebben meg mega 1000% :lol:
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 00:30:51
Quote
Endinek igaza van, legalább az egyik lapozást meg lehetne spórolni a megszakításban, kevesebb lassulást okoz ha a 3 videólapot lapozgatod két szegmensen, mikor mi kell, az egyik szegmens lehetne fixen a digi hangé, az is kb 300 nopot jelentene.

Endi nem hinném, hogy gyorsítani akart volna a lapozással,

de igazából ha lecsökkenteném a képet 16 normál rasztersorral (ami a játékban csak 8 raszter valójában a függőleges duplázás miatt) akkor át sem lógna a harmadik szegmensre ... :)

Csak nincs szívem megválni tőle. Inkább még kiraknék, csak akkor vas gépeken már nem biztos hogy látszana.

És pld. a függőleges csillagmozgásnál nem szívesen nézegetném a lapokat csillagonként ... úgyis az is olyan lassú mint a ...

De azért elmélkedek rajta .... lehet hogy ezt akkor most meg kéne tenni ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 00:33:53
Quote
Sztem tök jó a 60 raszter,


Én úgy értettem, hogy a 312 rendelkezésre álló raszterből 60 csak a digi hang lenne, a többi maradna csak meg másra ...



Quote
most járok 60 raszternél, és 5 ojjektum mozog a képen ...


Hát az nem ugyanaz. Én meg akkor így akkor fogok 60 raszternél járni, ha szól a hang és semmit nem csinálok ... :)


Egyébként melyiknek álltál neki ?
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 00:38:45
Én is úgy értettem :D , szerintem az nem rossz.
Hogy csináltad a sorduplázást? Ha jól értem, akkor 2 LPB a két sorra, mert ha jól emléxem, akkor 1 LPB-vel is megoldható a duplázás.
A Gnashernek álltam neki, az olyan kis eccerű, mégis akadtak, és tuti akadnak problémáim :lol: , egy galagába lehet bele is fulladnék :D
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 00:48:40
Quote
Hogy csináltad a sorduplázást? Ha jól értem, akkor 2 LPB a két sorra, mert ha jól emléxem, akkor 1 LPB-vel is megoldható a duplázás.

Nem, két raszterenként van 1 LPB, tehát a szinkronizált raszter soraim száma 272 de csak ennek fele az LPB -k száma (a szinkronokon kívül), meg hát a játékomban is csak a fél felbontás van. :)


Quote
A Gnashernek álltam neki, az olyan kis eccerű, 

Ja, én is akarok olyasmiket is, ha ki van dolgozva jól, akkor frankó az.


Quote
mégis akadtak, és tuti akadnak problémáim (http://enterpriseforever.com/Smileys/phpbb/ds_icon_lol.gif) ,

Ja én technikailag hasonlóba az exorcist -be akarok majd belefogni, de már gondolkodtam rajta, hogy mondtam, hogy így ziccer meg úgy ziccer, oszt mikor belegondoltam rájöttem hogy mégsem lehet pixelművelet nélkül megúszni, mert pikkpakk elfogynak a karakterek amibe a szkrollozott fazisokat tarolna az ember


Quote
 egy galagába lehet bele is fulladnék (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)

Fuldoklás ez mindig ... de egyszer csak átérünk a túlpartra.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 01:00:56
Quote from: Z80System
Nem, két raszterenként van 1 LPB, tehát a szinkronizált raszter soraim száma 272 de csak ennek fele az LPB -k száma (a szinkronokon kívül), meg hát a játékomban is csak a fél felbontás van. :)
Hát, akár meg is érhetné levágni azt a 16-ot a spórolás miatt, emléxem, hogy volt olyan tv-nk, amin a 27 magas basicben nyitott videó lap majdnem kilógott :D (3-4 karakternyi hely volt felül, a 256 magas kép nem jelent volna meg :D )
Quote
Ja én technikailag hasonlóba az exorcist -be akarok majd belefogni, de már gondolkodtam rajta, hogy mondtam, hogy így ziccer meg úgy ziccer, oszt mikor belegondoltam rájöttem hogy mégsem lehet pixelművelet nélkül megúszni, mert pikkpakk elfogynak a karakterek amibe a szkrollozott fazisokat tarolna az ember
Hát igen, 256 karakterbe belefértem volna, de akkor hol vannak a színek ??? Azok meg kellenek, így maradt a többször használatos karakter :D , így jól állok, maradt 8 szabad a 64-ből :D
Quote
Fuldoklás ez mindig ... de egyszer csak átérünk a túlpartra.
vagy nem, de az biztos :lol:
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 01:01:56
Quote
A Gnashernek álltam neki,
És hogy csinálod ? Vason ? Emuban ? ASM, vagy PC -n valami crosscompile ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 01:09:31
Quote
Hát, akár meg is érhetné levágni azt a 16-ot a spórolás miatt, emléxem, hogy volt olyan tv-nk, amin a 27 magas basicben nyitott videó lap majdnem kilógott (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) (3-4 karakternyi hely volt felül, a 256 magas kép nem jelent volna meg (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) )
Francba, én úgy emlékeztem ezt a 272 -t úgy választottam ki, hogy az lett mondva, hogy átlag TV -n az még latszik. Nem minden, nyilván, de a legtöbbet úgy lehet állítani, hogy latsszon ...
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 01:22:14
Quote from: Z80System
És hogy csinálod ? Vason ? Emuban ? ASM, vagy PC -n valami crosscompile ?
Emuban, annyit megy a debugger, hogy beégett már a kijelzőbe :D Asm Sjasm-mal fordítva.
Quote
Francba, én úgy emlékeztem ezt a 272 -t úgy választottam ki, hogy az lett mondva, hogy átlag TV -n az még latszik. Nem minden, nyilván, de a legtöbbet úgy lehet állítani, hogy latsszon ...
Lehet, nem emléxem mi volt a határ, meg azt a tévét, amiről beszéltem, 85-ben vettük :D
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 01:27:18
Quote
Asm Sjasm-mal fordítva.
Egy ilyen assembler támogat már mondjuk lokális változókat, vagy ilyesmiket ?
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 01:36:43
Lokális változókról nem tudok, de vannak lokális címkék, mondjuk azokat se használom :D , meg van benne feltétel is, itt a leírás, ha érdekel:

Sjasm doc (http://home.wanadoo.nl/smastijn/sjasmmanual.html)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 01:44:17
Kacérkodok a gyorsításaiddal, gondoltam csinálok akkor egy minden szempontból audio sebességnek alárendelt verziót,

lássuk mi jön ki sebességnek,

és ugyan nem úgy csináltam a várakozást ahogy mondtad, de nem látom be, hogy ez miért nem kellene működjön:

 WaitForIRQ_Loop:

 in a, (0xb4)
 and #0x20

 jr z, WaitForIRQ_Loop

 ld a, #0x1+ 0x20
 out (0xb4), a
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 02:04:35
Mondjuk ha működne, és mindent be is áldoznék érte ami kell, akkor egy jó kis megszakítás lenne :) :


Code: [Select]
void IRQ() __naked
{
__asm

exx

ld c, #0xb4
ld b, #D_Ints+ 0x2
out (c), b

ld c, #0xa8
outi
ex de, hl

ld c, #0xac
outi
ex de, hl

exx

ei

ret

__endasm;
}


Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 02:19:16
leteszteltem, hacsak nem írtam el valamit, akkor végtelen ciklus lesz.
Ez jó, legalább szabadon lehet használni az af'-t, így mennyi az annyi raszterban?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 02:27:11
Quote
leteszteltem, hacsak nem írtam el valamit, akkor végtelen ciklus lesz.


Ja, de nem értem, hogy miért. Majd holnap megkérdem Zozo -t hogy működhet -e ez egyáltalán ilyen módon. Hogy a z80 -al várok video megszakra.


Lehet, hogy ha van egy olyan port írás, amiben nincs engedélyezve a 16, akkor az a 32 -t is törli. Tehát mi ponthogy nem akarunk 16 -ot, hogy ne legyen video megszak, de a 32 értékét meg meg akarjuk kapni.


Ha a 16 nem beállítása törli a 32 -t is, akkor ez a módszer így nem tud működni ...
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 02:29:37
Quote
Ez jó, legalább szabadon lehet használni az af'-t, így mennyi az annyi raszterban?
Ja, bár nem tudom mire kellhetne ...

Nem tudom, hogy időben mi a pálya ezzel, mert ez nem fog működni, amig végtelen ciklusban van a főprogram. Pontosabban működik, csak az ideje nem látszik a kereten, mert hisz be van fagyva a főprogram.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 02:33:40
jó a 16 , mert az nem azt jelenti, hogy videó megszakítás van, hanem azt jelenti, hogy a Nick elérte azt az LPB-t, amiben a megszakítás bit be lett állítva. A 32 figyelése meg akkor lenne jó, ha a megszakításban 48-at írnál ki a b4h portra, de akkor megint figyelni kéne melyik megszakítás is jött, legalábbis a mostani tesztelgetések során ez jött le.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 02:39:58
Én úgy gondolom, hogy a 16 azt jelöli, hogy amikor van 32, akkor legyen z80 megszakítás.

A 32 meg a tényleges megszakítás megtörténte.

Úgy is mondhatjuk, hogy a 16 -ot te állítod amire akarod, és azt olvasod ki, amit beírtál,

a 32 -t meg al LPB állítja, te meg reszeteled, ha 1 -et irsz rá, és ha te 1 -et írsz rá, akkor utána a következő beolvasások 0 -át fognak rá adni rá, mindaddig, míg az LPB újra be nem állítja.

Csak én úgy sejtem, hogyha egy reszetelésnél a 32 mellé nem adod a 16 -ot, akkor többé valamiért nem műxik ... ezt akarom megkérdezni Zozo -tól.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 09:20:41
Na Zozo, te mit mondasz erre ?

Lehet sztd. z80 -nal figyelni a 0xb4 video megszak bitjét, és így főprogramból várni a megszakra, vagy csak a tényleges megszakításból lehet megbízhatóan detektálni a video megszakot ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.03. 09:52:33
Lehet, ezért tették kiolvashatóvá a Dave INT bemeneteit.
Bit4 (16) jelenti azt, hogy a Nick éppen megszakítás jelet ad.
Bit5 (32) azt jelenti, hogy van eltárolt videó megszakítás, ez csak akkor állítódik, ha engedélyeztük azt a B4 porton. Erre figyelni csak folyamatos DI mellett érdemes, mert egyébként úgyis IRQ lesz, amikor beáll.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 10:02:02
Quote
Lehet, ezért tették kiolvashatóvá a Dave INT bemeneteit.
Bit4 (16) jelenti azt, hogy a Nick éppen megszakítás jelet ad.
Bit5 (32) azt jelenti, hogy van eltárolt videó megszakítás, ez csak akkor állítódik, ha engedélyeztük azt a B4 porton. Erre figyelni csak folyamatos DI mellett érdemes, mert egyébként úgyis IRQ lesz, amikor beáll.
Kicsit akkor még általánosabban:

- Ha írom a 0xb4 bit4(16) -ot, akkor azzal azt adom meg, hogy a z80 -at megszakítsa -e a video, vagy sem.

- Ha olvasom a 0xb4 bit4(16) -ot, akkor azzal azt kapom meg, hogy épp video megszak van -e, nem pedig azt, amit én beleírtam.

- Ha írom a 0xb4 bit5(32) -őt, és mégpedig 1- gyel, akkor törlöm a video megszakot, és az interrupt nem váltódik ki újra a megszak visszatérése után, csak majd mikor újra beállítja az LPT ezt a bitet. Ha 0- val írom, akkor semmi nem történik.

- Ha olvasom a 0xb4 bit5(32) -őt, akkor azzal fene tudja mit kapok meg, de nem is jó az semmire.

Így van ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 10:14:06
Mindebből akkor az következne, hogy egy működő és futó audio interrupt mellett, ha főprogramban ez benne van a loop -omban:

 WaitForIRQ_Loop:

 in a, (0xb4)
 and #0x10

 jr z, WaitForIRQ_Loop

vagy pedig ugyanez de jr nz, -vel (kipróbáltam mindkettőt), akkor az várna a video megszakra. De nem vár. Egy darabig mintha egyáltalán nem akasztaná meg, aztán meg végtelen ciklus.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.03. 10:16:13
A bit4-et olvasva azt tudod meg, hogy éppen generál-e a Nick megszakítást.
Ha a bit4-et írva engedélyezed a videó megszakítást, akkor ha Nick megszakítás történt átkerül a tárolóba, amit a bit5-t olvasva tudsz megnézni. Ez egyben ki is váltja a Z80 megszakítását, és mindaddig 1-ben marad, amíg a bit5-t írva nem törlöd.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.03. 10:22:07
Próbáld ki ezt:
Code: [Select]
        DI
CIKLUS          IN A,(0B4H)
                AND 10H
                OUT (81H),A
                JR CIKLUS
Fenasban futtatva az utolsó sor alatt zöld lesz a keret.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 10:26:10
Nem lehet, hogy a DI kavar be ?

Nálam engedélyezettek a megszakítások, hisz az audio megszakítás megy, miközben én főprogramból akarok várni a video megszakításra.

Ez az audio megszak, abban is van 0xb4 kezelés (nyilván) :



Code: [Select]
void IRQ() __naked
{
__asm

exx

ld c, #0xb4
ld b, #0x1+ 0x2
out (c), b

ld c, #0xa8
outi
ex de, hl

ld c, #0xac
outi
ex de, hl

exx

ei

ret

__endasm;
}



Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 10:53:11
Ez így szerintem rossz, mert elrontja a jelzőbiteket. Kellene EX AF, AF' is.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 10:56:32
Quote
Ez így szerintem rossz, mert elrontja a jelzőbiteket. Kellene EX AF, AF' is.
Fú, az simán lehet, mert azokat a legutolsó optimalizálási lépcsőben "optimalizáltam" ki ... :)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 10:59:05
Quote from: Z80System
Fú, az simán lehet, mert azokat a legutolsó optimalizálási lépcsőben "optimalizáltam" ki ... :)
Valójában nem veszítenél vele időt, mert a kód elején az OUT (C), B helyére egyszerűbb és gyorsabb OUT (0B4H), A kerülhetne.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:04:06
Quote
Valójában nem veszítenél vele időt, mert a kód elején az OUT (C), B helyére egyszerűbb és gyorsabb OUT (0B4H), A kerülhetne.
Hát pedig pont a 2 ex af, af -et optimalizáltam ki, előtte az volt ... :)

Ebből is látszik, hogy nézni kéne a referenciát, nem "érzésre" kéne optimalizálni ...

Mindjárt kiderül az is, hogy ez sem gyorsabb:

 
Code: [Select]
ld c, #0xa8
 outi
 ex de, hl

 ld c, #0xac
 outi
 ex de, hl


ennél:

 
Code: [Select]
ld a, (de)
 out (0xa8), a
 inc de

 ld a, (hl)
 out (0xac), a
 inc hl



Pedig ez is (érzésre) optimalizálás ... :)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:06:30
A második megoldás jobb, mert kis mértékben gyorsabb, és kevesebb regisztert használ. A háttér regiszterek hasznosak lehetnének a főprogramban a grafikai és egyéb rutinokban. :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:09:24
Quote
A második megoldás jobb, mert kis mértékben gyorsabb, és kevesebb regisztert használ. A háttér regiszterek hasznosak lehetnének a főprogramban a grafikai és egyéb rutinokban. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Szuper ... na befejeztem a fejből optimalizálást. Így visszafele haladok ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:15:27
A másik megszak javaslatodat visszavontad ? Mert most nem találom, csak a levelek között van meg ... És az mintha egy stereo hangot játszana le egyrészt,

másrészt meg a többi is túl nagy megkötésnek tűnik nekem, hogy a max 256 byte lehet a sample, meg ilyenek ...
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:16:39
Még egy probléma: a lejátszás így nem tud megállni, legalábbis automatikusan (megszakításból vezérelve) nem. Azaz a hangminták végén megfelelő hosszúságú (legalább 1/50 másodperc) üres helyet kell hagyni, és a főprogramban minden video megszakításnál ellenőrizni, hogy a lejátszás lefutott-e már. A hang szüneteltetéséhez egy csatornán pedig a megfelelő regisztert úgy állítani, hogy 0 (azaz valójában 20h) értékű hangmintára mutasson, és az INC utasítást NOP-al felülírni.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:17:42
Quote from: Z80System
A másik megszak javaslatodat visszavontad ?
Igen, mert tévedésből sztereó hangot játszott le két független mono csatorna helyett.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:22:01
Quote from: Z80System
másrészt meg a többi is túl nagy megkötésnek tűnik nekem, hogy a max 256 byte lehet a sample, meg ilyenek ...
Ez nem igaz, csak 256 byte-os határon érhetne véget (de tetszőleges címen kezdődhetne), és általában +5 ciklust fogyasztana csatornánként (többet a 256 byte-os határok elérésekor, de ez statisztikailag csak ritkán fordul elő). Az előnye az lenne, hogy a megszakítás automatikusan kezelné a lejátszás megállítását, és végtelenített lejátszást is lehetővé tenne.

Azonban a főprogramban ellenőrzés hatékonyabb a CPU fogyasztás szempontjából.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:24:55
Quote
Még egy probléma: a lejátszás így nem tud megállni, legalábbis automatikusan (megszakításból vezérelve) nem. Azaz a hangminták végén megfelelő hosszúságú (legalább 1/50 másodperc) üres helyet kell hagyni, és a főprogramban minden video megszakításnál ellenőrizni, hogy a lejátszás lefutott-e már.
Igen, ez by design van így, pont az optimalizálás jegyében, csak gondolom addig már nem olvastad vissza. Sőt a helyzetet tovább bonyolítja hogy a cuccból most vettem ki a video megszakot, vagyis nem is lesz fix 50 Hz megszak, hanem csak a főprogram tudja majd kezelni ezt körönként, de a főprogramot pedig valójában szabadon lehet majd állítani 1-10 FPS között ...


Quote
A hang szüneteltetéséhez egy csatornán pedig a megfelelő regisztert úgy állítani, hogy 0 (azaz valójában 20h) értékű hangmintára mutasson, és az INC utasítást NOP-al felülírni.

Nem így akarom, mindíg menni fog a hang, folyamatosan, és lesz egy csend hangom, amire mindíg rá lesz váltva, amikor nincs értelmes hang beváltva. Hát ez végülis az amit mondasz, csak az inc -et nem kell piszkálni.

A 20h -ért köszi, én persze 0- ákkal próbáltam volna, és csodálkoztam volna, hogy pattog.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:29:49
Quote
Ez nem igaz, csak 256 byte-os határon érhetne véget (de tetszőleges címen kezdődhetne),
Ezt nem értem ... csak inc c van benne ... az sosem fog kimenni 256 byte -os range -ből. Igen kezdődhetne akárhol, de nem lehetne a hang hosszabb, mint 256 byte. Hisz mikor előszor 0 lenne a c, akkor vége lenne a lejátszásnak. Vagy mit nem értek ?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:34:00
Quote
 Sőt a helyzetet tovább bonyolítja hogy a cuccból most vettem ki a video megszakot,

Hoppá ... most esett le ... mivel a sebességem úgyis meglesz 50 FPS -el, ezért mikor majd épp 10 FPS -sel megyek, nem kell nekem a főprogram loop -ját olyan hosszan befognom, csak arra kell megtanítsam, hogy miután az első frame -ben kész vagyok, a többi frame- ben csak olyanokat csináljon ami nem mozgás ... tehát a hangot nyugodtan tudom még attól kezelni, meg még a színkeverő villogtatást is ...

csuhajj, akkor a legnagyobb probléma elhárult a z80 megszakfigyelés elől.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:36:23
Na, ha jól értem, akkor ez nyert mint leggyorsabb még működő verzio, ha 2 hangot akarok lejátszani, és ráérek a főprogramból lekapcsolni ? :


Code: [Select]
void IRQ() __naked
{
__asm

ex af, af
exx

ld a, #D_Ints+ 0x2
out (0xb4), a

ld a, (de)
out (0xa8), a
inc de

ld a, (hl)
out (0xac), a
inc hl

exx
ex af, af

ei

ret

__endasm;
}


Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:47:57
Ezzel akkor úgy szemre 20% -al kell több idő ugyanannak a feladatnak az elvégzésére, ahhoz képest mintha nem lenne hang ... 10% -nak jobban örülnék, de ha ez hát ez ... :)

A lapozást meg úgy fogom megoldani valószínűleg, hogy a cucc az 64K -n fog futni, és két ellenség között a háttér 64K -ból fogok felmásolni grafika és hang adatokat az aktív 64K -ba. Igy akkor lapozás csak a másolás alatt lesz, amit így csak a csillagmozgással kell összeintegráljak ...

Tehát a másolás is kis részekre bontva, valós időben fog megtörténni, két ellenség közötti kis csillagmozgás szünetben ... reményeim szerint.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:50:38
Egyébként a z80 -nal várakozás akkor simán működik a 0xb4 b4(16) olvasással, csak az ex af, af "kioptimalizálása" borította össze nálam a dolgokat.

geco+Zozo+IstvanV rúlz !
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:50:43
Quote from: Z80System
Ezt nem értem ... csak inc c van benne ... az sosem fog kimenni 256 byte -os range -ből. Igen kezdődhetne akárhol, de nem lehetne a hang hosszabb, mint 256 byte. Hisz mikor előszor 0 lenne a c, akkor vége lenne a lejátszásnak. Vagy mit nem értek ?
Az INC C után feltételes elágazás következik, és ha a C 0, akkor INC B történhet, illetve a B értékének a tesztelése.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 11:52:56
Quote from: Z80System
Na, ha jól értem, akkor ez nyert mint leggyorsabb még működő verzio, ha 2 hangot akarok lejátszani, és ráérek a főprogramból lekapcsolni ?
Még egy keveset lehetne gyorsítani a megszakítást OUT (C), B utasítással törölve (BC' = 03B4h fixen), de egy regiszterpár elvesztése talán túl nagy ár lenne a 6 ciklus gyorsulásért.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 11:58:27
Quote
Az INC C után feltételes elágazás következik, és ha a C 0, akkor INC B történhet, illetve a B értékének a tesztelése.
Fárasztó lehet elmagyarázni ezeket a trivialitásokat ... Kösz ... :)

Most akkor az lehet még kérdés hogy az inc r + jr cc az nem gyorsabb -e mint az inc hl/inc de, amire érzésre megint azt mondanám, hogy nem, de mostmár megnézem majd az órajeleket ...


Quote
Még egy keveset lehetne gyorsítani a megszakítást OUT (C), B utasítással törölve (BC' = 03B4h fixen), de egy regiszterpár elvesztése talán túl nagy ár lenne a 6 ciklus gyorsulásért.

Oks, egyenlőre nem használom a főprogramban az árnyékot semmire, de majd a végén beleírom, ha így is marad.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 12:01:45
Quote from: Z80System
Most akkor az lehet még kérdés hogy az inc r + jr cc az nem gyorsabb -e mint az inc hl/inc de, amire érzésre megint azt mondanám, hogy nem, de mostmár megnézem majd az órajeleket ...
Az INC HL természetesen gyorsabb, mint az INC L + JR Z, de ezt már említettem is.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 12:05:29
Eszembe jutott még egy gyorsítási lehetőség, nem jelent túl sokat, de mégis valami: az inc de-t, és inc hl-t le lehetne cserélni inc e-re, és inc l-re, és a videó megszakítás után csekkolod, hogy elért-e 0f0h közelébe, ha igen, akkor következő 256-os tartományra ugrás, igaz, egy picit helypazarló.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 12:12:46
Quote from: geco
Eszembe jutott még egy gyorsítási lehetőség, nem jelent túl sokat, de mégis valami: az inc de-t, és inc hl-t le lehetne cserélni inc e-re, és inc l-re, és a videó megszakítás után csekkolod, hogy elért-e 0f0h közelébe, ha igen, akkor következő 256-os tartományra ugrás, igaz, egy picit helypazarló.
Ez szerintem nem lenne jó, mert a főprogram nem tudná elég pontos időzítéssel tesztelni a lejátszási pozíciót, ezért akadozna a hang.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 12:18:39
Akkor stornó :), azt gondoltam, hogy 1-2 megszakításbeli (bájtbeli) eltérés lehet csak, és az nem okozna különösebb galibát.
Viszont egy dolog foglalkoztat, hogy lehet az alul/felüláteresztő szűrőt, és a ring modot leprogramozni?
Emléxem a működésüket leírtad, de nem tudtam feldolgozni :lol:
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 12:26:15
Quote from: geco
Viszont egy dolog foglalkoztat, hogy lehet az alul/felüláteresztő szűrőt, és a ring modot leprogramozni?
Ezt nem egészen értem, pontosan mit is kellene elmagyarázni ? :oops:
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 12:39:54
Quote from: IstvanV
Ezt nem egészen értem, pontosan mit is kellene elmagyarázni ? :oops:
Hát mivel a működésüket nem bírtam felfogni :lol:, így a megvalósítása is elég távol áll tőlem, ha nem hosszú kód/bonyolult, akkor azt szeretném, hátha abból felfogom, hogy hogy is műxik ez digi hangok esetén.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 12:43:11
D/A módban nem működnek ezek az effektusok.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 12:49:40
Na, akkor kifejtem, mire gondoltam, ugye ki tudjuk nyerni a SID regiszter értékeit, és D/A módban sikerült is tök egyszerű, pár bájtos samplékkal a fűrészjelet, és a háromszöget létrehozni, és az kezdett el foglalkoztatni, hogy vajon mennyire bonyolult leprogramozni az alul/felüláteresztő szűrő hatást így digi hangokra, elkezdtem utánanézni először itt, aztán meg a neten, de nem sok sikerrel jártam.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.03. 13:09:48
A SID effektusai eltérő módon működnek a DAVE-től, amely egyszerű "bináris" effektusokat használ logikai kapukkal. A SID-ben valódi, feszültségvezérelt analóg szűrő található, amelynek az elfogadható emulációjához egy 4 MHz-es Z80 valószínűleg nem elég. A négyszögjel kitöltési tényezőjének a változtatása viszont megoldható, és talán a gyűrűmoduláció is (bár meg kell néznem, hogy a SID-en a gyűrűmoduláció pontosan hogyan működik).
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 13:15:17
sok idő se maradna rá szerintem, mert 20khz környékén kéne lejátszani a hangot, hogy jó legyen, legalábbis ezt tapasztaltam a tesztelgetés során.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.03. 13:50:45
Belekotty a SID gyűrűmodulációhoz. Emlékeim szerint csak a háromszögjelre működik úgy, hogy amikor a moduláló csatorna amplitúdója eléri a szélső értékeinek valamelyikét (bár lehet, hogy nem bármelyiket, hanem csak a maximumot), akkor vagy 180°-kal elfordítja a jel fázisát, vagy megfordítja a generáló jelet (tehát ha az amplitúdó emelkedő fázisban volt akkor csökkenni kezd és fordítva). Talán inkább az utóbbi az igaz.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.03. 13:59:11
Még egy belekotty. Ha jól értem geco a 20MHz-es lejátszás esetében arról beszél, hogy a szűrő nélküli, de hullámformákat és gyűrűmodulációt figyelembe vevő SID emuláció igényelne ekkora sebességet. Nos, plus/4-en már ezer éve létezik ilyen emuláció. Figyelembe véve a digitális hangreprodukció ottani meglehetősen korlátozott képességeit és a 7501/8501 sebességét, EP-n a hullámforma+ADSR emuláció simán működhetne a jelenlegi hardverrel, a plus/4-hez viszonyítva kifejezetten jó eredménnyel. Ha jól értettem, amiről geco beszélt.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.03. 18:20:15
Valami olyanra én is emlékszek, hogy a +4 -es cimbim egy időben teljesen tűzbe jött, hogy a hangszereket elkezdték digitálisan kelteni, de nem igazi sample -k voltak, hanem kód generálta a mintákat, amiket kiírtak digitálisan. Az ilyen zenéknek (mindíg csak "digi zene" -knek emlegette őket) volt nagyobb processzorigényük azért, de még mindíg be tudták rakni demók, esetleg játékok alá is.

Nekem persze csak egy újabb hangzású, még tompább és torzabb prüntyögésnek tűnt, mint addig ... :)
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 20:53:55
Hát valójában csak azt teszteltem, hogy milyen frekin kell tolni a hangot, hogy ne torzítson, ez lett 20Khz, a gyűrűmodot nem néztem, igaz nem is tudtam volna :D Alacsonyabb sebességű playbacknél egyre rosszabb.
Title: Re: Assembly programozás
Post by: geco on 2013.November.03. 21:11:47
Viszont az bíztató, hogy +4-en valamire sikerült jutni, igaz a processzora nem lassabb, mint az EP-é, de talán a z80 utasításkészletével, + a Dave adottságaival jobb minőséget lehetne kihozni.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.04. 08:05:25
Quote from: Ferro73
Engem olyan Link érdekelne ahol Z80 rutinok forrás kódjai található. Pl sorrendbe rendező; Hex2Dec; hex2ASCII; (nn)=HL*DE....
A hálón nem találom de lehet rosszul keresem. Emlékszem volt ilyen.
Nekem elveszett  
Esetleg a linkekhez is belehetne tenni. Vagy valahol az oldalon is lehetne gyűjteni a legjobbakat.
Előre is köszönöm
http://baze.au.com/misc/z80bits.html (http://baze.au.com/misc/z80bits.html)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 08:16:59
Quote from: geco
Viszont az bíztató, hogy +4-en valamire sikerült jutni, igaz a processzora nem lassabb, mint az EP-é, de talán a z80 utasításkészletével, + a Dave adottságaival jobb minőséget lehetne kihozni.
Valahol valakik egyszer nagyjából konszenzusra jutottak hogy a Z80 2,2-szeres órajel mellett képes a 65XX-szel egyenlő teljesítményt leadni általános feladatok alatt. !!Nem én állítom, nem is óhajtok vitatkozni rajta, csak munkahipotézis!! Ezt és a +4 órajelét figyelembe véve, az EP még előnyben kellene hogy legyen.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 11:45:03
A különbség attól is függ, hogy Plus/4-en engedélyezett-e a képernyő. Ha nem (az egész kép keret), akkor a fenti 2.2-es "Z80 lassulást" feltételezve 3.73 MHz-es (várakozás nélküli) Z80-nak felel meg, egyébként csak 2.51 MHz-esnek.

Egyes programok gyorsulást érnek el azzal, hogy a gépet NTSC módba kapcsolják, amivel 5 / 4 arányú "overclock" lehetséges. Így azonban nincs használható video kimenet, és a szabálytalan órajelet valószínűleg nem célszerű hosszabb ideig használni.

Létezik azonban "lassú" mód is, amelyben a CPU mindig egyszeres sebességgel fut (886723.75 Hz = ~1.95 MHz-es Z80). Ennek kikapcsolt képernyőnél lehet értelme, ha konstans sebességre és pontos időzítésre van szükség (például 1541 "turbó" töltőknél).
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 12:00:04
Quote from: IstvanV
A különbség attól is függ, hogy Plus/4-en engedélyezett-e a képernyő. Ha nem (az egész kép keret), akkor a fenti 2.2-es "Z80 lassulást" feltételezve 3.73 MHz-es (várakozás nélküli) Z80-nak felel meg, egyébként csak 2.51 MHz-esnek.

Egyes programok gyorsulást érnek el azzal, hogy a gépet NTSC módba kapcsolják, amivel 5 / 4 arányú "overclock" lehetséges. Így azonban nincs használható video kimenet, és a szabálytalan órajelet valószínűleg nem célszerű hosszabb ideig használni.

Létezik azonban "lassú" mód is, amelyben a CPU mindig egyszeres sebességgel fut (886723.75 Hz = ~1.95 MHz-es Z80). Ennek kikapcsolt képernyőnél lehet értelme, ha konstans sebességre és pontos időzítésre van szükség (például 1541 "turbó" töltőknél).
Hát, ez az itteni úri közönséget valószínűleg meglehetősen kevéssé érdekli, én meg ismerem ezeket a lehetőségeket. Én csak annyit próbáltam volna kihozni a dologból, hogy ha valakinek van hozzá energiája, akkor szabványos konfiguráció mellett is feltehetően megoldható a "wave converter" stílusú hangkeltés EP-on.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.04. 12:10:23
Quote from: ergoGnomik
Hát, ez az itteni úri közönséget valószínűleg meglehetősen kevéssé érdekli
Engem érdekelnek a szomszéd tábor érdekességei is. Pl. izgi ez a képkikapcsolás, ilyenről eddig csak ZX81-en hallottam.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 13:24:39
Quote from: geco
Hát valójában csak azt teszteltem, hogy milyen frekin kell tolni a hangot, hogy ne torzítson, ez lett 20Khz, a gyűrűmodot nem néztem, igaz nem is tudtam volna :D Alacsonyabb sebességű playbacknél egyre rosszabb.
Az ideális megoldás talán a SID órajelének a 64-ed része lenne, azaz C64 esetén 15394.51 Hz (250000 / 16 = 15625 Hz-es DAVE megszakítás, vagy 259 4 MHz-es Z80 ciklus / hangminta), Plus/4-nél pedig 13855.06 Hz (250000 / 18 = 13889 Hz-es DAVE megszakítás, vagy 288 4 MHz-es Z80 ciklus / hangminta). De ehhez nagyon kevés az idő, ha nem csak nagyon egyszerű emuláció kellene, akkor célszerűbb lenne ennek a felével próbálkozni.

Egy rövid példa (talán jobban is lehetett volna optimalizálni):
Code: ZiLOG Z80 Assembler
  1. .l1:    ld      bc, 0000h               ; * frequency 1 (= SID_freq/4)   10
  2.         add     ix, bc                  ;                                25
  3.         ld      a, ixh                  ;                                33
  4.         ld      l, a                    ;                                37
  5. .l2:    ld      h, high triangleTable   ; * waveform 1                   44
  6.         ld      l, (hl)                 ;                                51
  7. .l3:    ld      h, high volumeTable     ; * amplitude 1                  58
  8.         ld      a, (hl)                 ;                                65
  9.         out     (0a8h), a               ;                                76
  10. .l4:    ld      bc, 0000h               ; * frequency 2 (= SID_freq/4)   86
  11.         add     iy, bc                  ;                               101
  12.         ld      a, iyh                  ;                               109
  13.         ld      l, a                    ;                               113
  14. .l5:    ld      h, high triangleTable   ; * waveform 2                  120
  15.         ld      l, (hl)                 ;                               127
  16. .l6:    ld      h, high volumeTable     ; * amplitude 2                 134
  17.         ld      a, (hl)                 ;                               141
  18.         out     (0adh), a               ;                               152
  19. .l7:    ld      bc, 0000h               ; * frequency 3 (= SID_freq/4)  162
  20.         ex      de, hl                  ;                               166
  21.         add     hl, bc                  ;                               177
  22.         ex      de, hl                  ;                               181
  23.         ld      l, e                    ;                               185
  24. .l8:    ld      h, high triangleTable   ; * waveform 3                  192
  25.         ld      l, (hl)                 ;                               199
  26. .l9:    ld      h, high volumeTable     ; * amplitude 3                 206
  27.         ld      a, (hl)                 ;                               213
  28.         out     (0aah), a               ;                               224

Ez nem elég gyors ahhoz, hogy C64-es SID emulációt megszakításban valósítson meg, Plus/4 esetén pedig közel 100%-os CPU fogyasztása lenne. A főprogramban futtatva azonban elég lenne az idő; a DTM lejátszó is ilyen megoldást használ. Így a paraméterek módosítását kellene (video) megszakításból végezni, ami torzítaná a hangot. Azonban felszabadulna a hanggenerátorok frekvenciája, amit polinom számlálóval zaj emulációra lehetne használni - erre egyébként a fenti kód digitális lejátszással nem lenne képes, vagy legalábbis nem túl jó minőségben.

A mintavételezési frekvencia csökkentésével maradhatna idő effektusokra (szinkron, gyűrűmoduláció), illetve a lejátszó rutin hang megszakításba építésére.
Title: Re: Assembly programozás
Post by: geco on 2013.November.04. 13:54:35
Valami ilyesmire gondoltam én is, hogy főprogramban menne a hangkeltés, a DTM playerhez hasonlóan, és 256 bájton lennének eltárolva a minták, ismétlődve, arra gondoltam még, hogy mind a 15 hangmagassághoz lenne alap háromszög, és fűrészjel is eltárolva, a négyszögjelen még nem gondolkoztam :lol: , és ezeket 50 Hz-es megszakításból birizgálni.
Title: Re: Assembly programozás
Post by: lgb on 2013.November.04. 14:17:32
Quote from: Zozosoft
Engem érdekelnek a szomszéd tábor érdekességei is. Pl. izgi ez a képkikapcsolás, ilyenről eddig csak ZX81-en hallottam.

:) Azert erdekes lenne EP-n is, mert ugye ha a Nick-nek nem kene a videoram (fel lehetne fuggeszteni, hogy hozzaferjen), akkor addig mehetne a CPU-nak teljesen. Tehat EP-nel is okozna kulonbseget azert. ZX81 az mas teszta, ott eleg nagy kulonbseget okozna, mert - ha jol tudom - a video jel generalis felig-meddig (?) software-bol van, ott meg szignifikansabb a kulonbseg talan? Amugy preciz idozites miatt C64-nel is szokas letiltani a kepernyot (sot, defaulte magnorol toltes kozben le is kapcsol = keretszinu lesz az egesz kepernyo). De ugye egy 65xx rendszer busz idozitese nemikepp szorosabb, illetve C64 eseten amugy is macera a sprite-ok es egyeb dolog miatt (sot, valojaban a VIC-II adatbusza 12 bit szeles meglepo modon, 4 bit az kulon SRAM-ra megy ebbol - colour RAM - kulonben nem ferne bele semmifele idozitesbe, hiszen pl Nick-el ellentetben kepes hw text modban karakterenkent kulon szint is kezelni). Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...

(persze a konkret implementacio mas, C64-en orajel ciklusokat "lophat" el a VIC, +4-nel - afaik - viszont az orajel frekvencia van valtoztatva, EP-nel pedig ugye az orajellel jatszanak ismet, csak kisse maskeppen, de ezt Zozo ugyis jobban tudja)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 14:49:35
Quote from: geco
arra gondoltam még, hogy mind a 15 hangmagassághoz lenne alap háromszög, és fűrészjel is eltárolva
A 15 hangmagasság itt pontosan mit is jelent ? :oops: A hangmintákat több változatban tárolni anti-aliasing céljából van például értelme, de elsősorban csak PC-n, egy 8 bites lejátszón a "tökéletes" minőség kevésbé lényeges.

Quote from: geco
a négyszögjelen még nem gondolkoztam :lol:
Négyszögjelnél a kitöltési tényező módosításához (PWM) hasznos lenne több hangmintát tárolni. Például 32 lehetséges értékhez 8 KB területen (a SID ugyan ennél nagyobb felbontást tud, de a 32 is jobb a semminél). Ez a megoldás pazarolja a memóriát, viszont CPU időt takarít meg, amiből meglehetősen kevés van.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 15:02:04
Gondolom geco hangmagasság helyett amplitúdóra gondolt. +4-en a négyszögjel kitöltési tényezőjét azt hiszem úgy modulálták, hogy a szokásos számú minta helyett másfélszer akkora terület volt foglalva és a kitöltési tényezőtől függően máshol (később) kezdték a kiolvasást. Így, bár több terület kell hozzá, mint a másik hullámformáknál, de mégsem annyira pazarló. Egyébként ott a lejátszási frekvencia sem volt ennyire magas, és bár hi-fi minőségről nem beszélhettünk :ds_icon_cheesygrin:, azért nagyjából rá lehetett ismerni mi is volt a 64-es eredeti.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 15:08:06
Quote from: lgb
Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...
A Plus/4 valamivel bonyolultabb:
- teljes, kétszeres sebességű órajelnél 114 ciklus egy 57 karakteres sor (1.7734475 MHz frekvencia)
- ez azonban a gyakorlatban nem lehetséges, mert 5 ciklusra minden sorban szükség van DRAM frissítéshez; így a legjobb esetben marad 109 ciklus (némi trükközéssel "letiltható" a frissítés, de ez adatvesztést eredményez)
- ha a képernyő aktív, akkor 204 sorban (ez 4 sorral a 25 karakter magas látható terület előtt kezdődik) 44 karakter időtartamra csak egyszeres sebességű az órajel
- ez 4 karakterrel a video adat olvasása előtt kezdődik, amit a 40 karakter pixeleinek az olvasása követ, majd végül az 5 karakteres DRAM frissítés; tehát a CPU számára marad 65 ciklus
- mivel nincs külön SRAM a színekhez, karakterenként két sorban történik DMA az attribútumok olvasásához, ebből egy az előző karakter 7. (utolsó) sorában a szín információhoz, egy pedig az aktuális karakter 0. (első) sorában a karakter kódokhoz
- DMA alatt 43 ciklus időre teljesen leáll a CPU, azokban a ciklusokban történik az attribútumok olvasása, amik egyébként egyszeres sebességű módban szabadok lettek volna
- a 43 ciklusból az utolsó 40 a tényleges olvasás, az első 3 azért van, hogy a CPU-nak legyen ideje megállni. Írás közben ugyanis erre nincs lehetőség, és a legrosszabb esetben 3 írási ciklus történik egymás után (PC és állapot regiszter mentése megszakításkor)
- tehát a DMA-s sorokban, amelyekből normál esetben 50 található a képernyőn, további 40-43 (de legyakrabban 43) ciklus veszik el, és marad 22-25
- a kétszeres sebességű módot letiltva minden sorban 57 ciklus áll rendelkezésre a CPU számára, kivéve DMA esetén, amikor csak 14-17 marad
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 15:11:22
Quote from: lgb
... Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...

(persze a konkret implementacio mas, C64-en orajel ciklusokat "lophat" el a VIC, +4-nel - afaik - viszont az orajel frekvencia van valtoztatva, EP-nel pedig ugye az orajellel jatszanak ismet, csak kisse maskeppen, de ezt Zozo ugyis jobban tudja)
Nos ott tényleg nincs külön színmemória, ezért a képernyőmemória mellé direktben van egy dinamikus színmemória rendelve (pl.: default képernyő kezdőcím $0C00 és az ehhez a karakterhez tartozó szín a $0800 címen van). Ennek hála a 8 bites adatbuszán kétszer annyi adatot kell karaktersoronként átrángatni, mint 64-en. Plusz bónusz a rasztersoronként 57(*2) ciklus a 63-mal szemben. Természetesen a TED ugyan úgy lopogatja a ciklusokat, mint a VIC, cak itt két badline van de legalább a sprite-ok nem zavarnak a képbe. Egyébként szerintem nincs két órajel frekvencia, csak a processzor a kereten sokkal kevesebbet van várakoztatva, mint a látható területen. De ezt IstvanV valószínűleg pontosabban tudja.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 15:12:01
Quote from: ergoGnomik
+4-en a négyszögjel kitöltési tényezőjét azt hiszem úgy modulálták, hogy a szokásos számú minta helyett másfélszer akkora terület volt foglalva és a kitöltési tényezőtől függően máshol (később) kezdték a kiolvasást.
Ez valóban kevésbé pazarló megoldás, de Z80 CPU-n valamivel lassabb, mert nem áll rendelkezésre a 6502 hatékony indexelt címzése. Azaz nem lehet egyszerűen csak a H regiszterbe írni a táblázat kezdőcímét, az L-be pedig az aktuális fázist, hanem aritmetikai műveletre lenne szükség. De ha ez a (nem nagy mértékű) lassulás nem probléma, akkor így memória takarítható meg, és az effektus felbontása is nagyobb lehet.
Title: Re: Assembly programozás
Post by: geco on 2013.November.04. 15:12:32
Quote from: IstvanV
A 15 hangmagasság itt pontosan mit is jelent ? :oops: A hangmintákat több változatban tárolni anti-aliasing céljából van például értelme, de elsősorban csak PC-n, egy 8 bites lejátszón a "tökéletes" minőség kevésbé lényeges.
Bocs, a hangmagasság, a hangerőt akarta jelenteni :lol:
Úgy gondoltam, hogy miden hangerőhöz letárolok 1 3szög, egy fűrészjelsort, ami kitölti 256 byte-ot, és az 50Hz-es megszak állítja, hogy melyiket olvassa, a beolvasott hangerő függvényében. A frekvenciát, meg ugyanolyan addolós módón, mint a DTM playerben.
Quote
Négyszögjelnél a kitöltési tényező módosításához (PWM) hasznos lenne több hangmintát tárolni. Például 32 lehetséges értékhez 8 KB területen (a SID ugyan ennél nagyobb felbontást tud, de a 32 is jobb a semminél). Ez a megoldás pazarolja a memóriát, viszont CPU időt takarít meg, amiből meglehetősen kevés van.
A 32 sztem egész jó is lenne, ugyan nem tudom, hogy a white-fülűeknek mennyire lehet feltűnő a hiány, de a hozzám hasonló botfülűeknek sztem nem nagyon :D
Arra gondoltam, hogy valahogy ciklussal szabályozni ezt a dolgot, de mivel ezt nem teszteltem, ezért lehet hülyeségre gondoltam :lol: , és ez a 32 PWM-ű eltárolt négyszögjel szimpatikus ötlet.
Title: Re: Assembly programozás
Post by: lgb on 2013.November.04. 15:37:46
Quote from: IstvanV
Ez valóban kevésbé pazarló megoldás, de Z80 CPU-n valamivel lassabb, mert nem áll rendelkezésre a 6502 hatékony indexelt címzése. Azaz nem lehet egyszerűen csak a H regiszterbe írni a táblázat kezdőcímét, az L-be pedig az aktuális fázist, hanem aritmetikai műveletre lenne szükség. De ha ez a (nem nagy mértékű) lassulás nem probléma, akkor így memória takarítható meg, és az effektus felbontása is nagyobb lehet.

Na ebbe pont beleutkoztem. Mint "gyakorlott" (Z80-hoz kepest legalabbis!) 65xx programozo, hirtelen gondolkodoba is estem a minap, amikor az kellett, hogy egy egy memoriaban tarolt tablazatbol egy register altal (amugy egy byte-ba belefer, sot 7 bitbe is ...) megadott elemet toltsek be. Ez 65xx-n az indexelt cimzes mellett igen egyszeru, Z80-nal viszont eleg kenyelmetlen es lassu, mert csak ugy lehet megoldani, hogy pl 16 bites osszeadassal hozzaadom a tablazat kezdocimet es akkor ugy kiolvasom. Ennel tenyleg nincs jobb/gyorsabb megoldas? :( Gondolkoztam mar az onmodosito kodon is ;) Vegulis vmi (IX+d) eljarassal ha a "d"-nek megfelelo byte-ot atirom, akkor talan megiscsak hatekonyabb lesz (foleg, mivel amugy a tablazat merete 128 byte alatti - mint irtam). Valaki gyakorlottabb Z80 codernek lenne hozzafuznivaloja ehhez? Azt latom, hogy sajna ez Z80-on brutal lassu lesz 65xx-hoz kepest, ha beleszomolom a 16 bites osszeadast is :(
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 15:38:30
Quote from: geco
Bocs, a hangmagasság, a hangerőt akarta jelenteni :lol:
Úgy gondoltam, hogy miden hangerőhöz letárolok 1 3szög, egy fűrészjelsort, ami kitölti 256 byte-ot, és az 50Hz-es megszak állítja, hogy melyiket olvassa, a beolvasott hangerő függvényében. A frekvenciát, meg ugyanolyan addolós módón, mint a DTM playerben.
Én erre külön táblázatot használtam, ami hanggenerátoronként elfogyaszt 14 ciklust. :oops: Viszont kevesebb memória használatával lehet 15-nél több szint (ami a burkológörbe generátorral előfordulhat), és a sok táblázatos PWM emulációval kombinálva nem lesz elfogadhatatlanul nagy a memória igény. Azaz valami ilyesmire gondoltam:
- 2 * 256 byte táblázat a fűrészjelhez és háromszögjelhez
- 1 * 256 byte táblázat rossz minőségű (rövid ciklusban ismétlődő) "zaj" emulációhoz; a másik megoldás a DAVE 17 bites polinom számlálójának a használata
- 16384 byte táblázat 6 bites hangerőhöz (ha az előző táblázatok csak 6 bites értékeket tartalmaznak, akkor valójában 256 byte-onként 192 byte-os "lyukakat" tartalmazna, amelyeket egyéb célra is fel lehetne használni)
- 8192 byte táblázat 5 bites PWM emulációhoz (tulajdonképpen 8448 byte kellene ahhoz, hogy 0 és 1 között 1/32 lépésekben lehessen állítani a kitöltési tényezőt)
- 32 KB területen még marad 7 KB szabad memória további táblázatokhoz

2 belapozott szegmensen a különböző táblázatok lennének, egyen a kód és egyéb adatok/változók, egyen pedig a lejátszandó zene.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 15:43:01
Quote from: lgb
Na ebbe pont beleutkoztem. Mint "gyakorlott" (Z80-hoz kepest legalabbis!) 65xx programozo, hirtelen gondolkodoba is estem a minap, amikor az kellett, hogy egy egy memoriaban tarolt tablazatbol egy register altal (amugy egy byte-ba belefer, sot 128 byte-ba is ...) megadott elemet toltsek be. Ez 65xx-n az indexelt cimzes mellett igen egyszeru, Z80-nal viszont eleg kenyelmetlen es lassu, mert csak ugy lehet megoldani, hogy pl 16 bites osszeadassal hozzaadom a tablazat kezdocimet es akkor ugy kiolvasom. Ennel tenyleg nincs jobb/gyorsabb megoldas? :(
A leggyorsabb az, amit már említettem: 256 byte-os határra kell igazítani a táblázatot, és akkor egyszerűen egy regiszterpár alsó regiszterébe kell tölteni az indexet, a felsőbe pedig a táblázat kezdőcímének a felső byte-ját. Kisebb táblázatokat elég a méretüknek megfelelően igazítani, a lényeg, hogy elkerülhető legyen a 16 bites aritmetika, azaz ne keresztezzenek 256 byte-os határt.
Title: Re: Assembly programozás
Post by: lgb on 2013.November.04. 15:52:16
Quote from: IstvanV
A leggyorsabb az, amit már említettem: 256 byte-os határra kell igazítani a táblázatot, és akkor egyszerűen egy regiszterpár alsó regiszterébe kell tölteni az indexet, a felsőbe pedig a táblázat kezdőcímének a felső byte-ját. Kisebb táblázatokat elég a méretüknek megfelelően igazítani, a lényeg, hogy elkerülhető legyen a 16 bites aritmetika, azaz ne keresztezzenek 256 byte-os határt.

Ok, kossz. Ja es elobb az "1 byte-ba is belefer, sot 128 byte-ba is" az kisse fura fogalmazas volt tolem, termeszetesen ugy ertettem, hogy az index belefer 1 byte-ba, sot 7 bitbe is, azaz a tablazat merete 128 byte alatti. :)
Title: Re: Assembly programozás
Post by: Povi on 2013.November.04. 15:54:34
Quote from: Povi
http://baze.au.com/misc/z80bits.html (http://baze.au.com/misc/z80bits.html)
itt is van egy pár jó rutin:
http://sgate.emt.bme.hu/patai/publications/z80guide/index.html
Title: Re: Assembly programozás
Post by: geco on 2013.November.04. 15:58:39
Quote from: IstvanV
Én erre külön táblázatot használtam, ami hanggenerátoronként elfogyaszt 14 ciklust. :oops: Viszont kevesebb memória használatával lehet 15-nél több szint (ami a burkológörbe generátorral előfordulhat), és a sok táblázatos PWM emulációval kombinálva nem lesz elfogadhatatlanul nagy a memória igény. Azaz valami ilyesmire gondoltam:
- 2 * 256 byte táblázat a fűrészjelhez és háromszögjelhez
- 1 * 256 byte táblázat rossz minőségű (rövid ciklusban ismétlődő) "zaj" emulációhoz; a másik megoldás a DAVE 17 bites polinom számlálójának a használata
- 16384 byte táblázat 6 bites hangerőhöz (ha az előző táblázatok csak 6 bites értékeket tartalmaznak, akkor valójában 256 byte-onként 192 byte-os "lyukakat" tartalmazna, amelyeket egyéb célra is fel lehetne használni)
- 8192 byte táblázat 5 bites PWM emulációhoz (tulajdonképpen 8448 byte kellene ahhoz, hogy 0 és 1 között 1/32 lépésekben lehessen állítani a kitöltési tényezőt)
- 32 KB területen még marad 7 KB szabad memória további táblázatokhoz

2 belapozott szegmensen a különböző táblázatok lennének, egyen a kód és egyéb adatok/változók, egyen pedig a lejátszandó zene.
Na, én ezt a 15 - nél több hangerő szintet nem vettem figyelembe, mondjuk ami adatot ki tudok nyerni, az csak 15 szintű.
Először én is a kinyert zaj sample alkalmazására gondoltam, de aztán arra hutottam, hogy a zajt tök jól le tudnánk játszani a 17 bites polinom számláló beállításával, csak akkor kell egy nagyobb frekvencia konverziós tábla is, vagy eleve a zajnál a konvertált regiszter tartalmat kimenteni, és nem a SID regiszter értékeket.
Ezt a 16k-s hangerő táblázatot nem értem, azt hittem, hogy csak 256 byte-nyi az is
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.04. 16:37:33
Quote from: geco
Először én is a kinyert zaj sample alkalmazására gondoltam, de aztán arra hutottam, hogy a zajt tök jól le tudnánk játszani a 17 bites polinom számláló beállításával, csak akkor kell egy nagyobb frekvencia konverziós tábla is, vagy eleve a zajnál a konvertált regiszter tartalmat kimenteni, és nem a SID regiszter értékeket.
A táblázatos zaj generálás egyszerűbb, mert csak 256 véletlenszerű (a négyszögjel alacsony és magas értéke közötti tartományban) byte-ot kell írni a táblázatba, és a frekvenciát 16-al osztani, illetve az eredeti SID frekvenciához képest 4 helyett 64-el. Azonban az így lejátszott "zaj" zavaróan ismétlődik, és a Plus/4 zajgenerátorához (ami egy 8 bites polinom számláló) hasonló, ha nem is használhatatlanul rossz. Ezt javítaná a DAVE polinom számláló használata, bár annak csak 2 értékű kimenete van, és bonyolultabb a konverzió: fDAVE = 250000 / (fSID * 0.939606) - 1, ha a SID órajele 985249 Hz (PAL C64); a hangerőt is csökkenteni kell, de ez egyszerűen megoldható a "hullámforma" táblázatba 256 fix értéket írva, ami beállítja a helyes hangerőt. Nagy méretű táblázat is jó megoldás lenne, csak túl lassú.

Quote from: geco
Ezt a 16k-s hangerő táblázatot nem értem, azt hittem, hogy csak 256 byte-nyi az is
A táblázat címzése két értékkel történik: az eredeti hangmintával, és a hangerővel. A mérete tehát ezek lehetséges értékei számának a szorzata (pl. 64 * 64, de a 64 * 256 címzése gyorsabb).
Title: Re: Assembly programozás
Post by: lgb on 2013.November.04. 19:12:46
Apropo SID ... Van egy project (http://www.swinkels.tvtom.pl/swinsid/) ami AVR mikrokontrollerrel emulal SID-et - allitolag egesz jol - es hw szinten compatible, azaz pl a C64 SID helyere odarakhato. Persze ez sajna EP-n kevesbe segit, 24MHz-en hajtott RISC CPU-val (ami ugyan 8 bites, de a legtobb utasitasa egyetlen orajelciklust igenyel csak) az EP 4MHz-en futo Z80-a nehezen tudna felvenni a versenyt. Mindazonaltal esetleg mint otlet hasznalhato nehany teruleten legelabbis, ha valaki ert az AVR assembly-hez. En sajna zene teren egy nulla vagyok :(
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 19:37:10
Van is egy német internetes bazár, ahol kb. 13 Euróért lehet vásárolni abból a kivitelből (SwinSID Nano) ami a DIL 28-as tok helyén elfér, 12/9V-ról egyaránt megy és választható hogy 6581-et vagy 8580-at emuláljon. Már ha esetleg valakinek gusztusa támadna hozzábarkácsolni ilyesmit az EP-hoz. Bár szerintem ez még sokkal típusidegenebb dolog, mint a plus/4-et bővíteni SID-del. A Z80-as világban inkább az YM2149/AY-3-8910 volt a jellemző, szóval ha valamit, akkor inkább azt. Szerintem.
Title: Re: Assembly programozás
Post by: endi on 2013.November.04. 19:38:22
ohohóóó, látom fertőző Z80System betegsége, már mindenki komondort akar faragni az EP-ből
:twisted:
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.04. 19:42:22
Nem bátorítok én senkit, csak ha ilyesmire támadna valakinek ingerenciája - fene a gusztusát - akkor legalább könnyen tervezhesse merre rohamozzon. :lol:
Title: Re: Assembly programozás
Post by: geco on 2013.November.04. 20:53:29
Quote from: IstvanV
Ezt javítaná a DAVE polinom számláló használata, bár annak csak 2 értékű kimenete van, és bonyolultabb a konverzió: fDAVE = 250000 / (fSID * 0.939606) - 1, ha a SID órajele 985249 Hz (PAL C64); a hangerőt is csökkenteni kell, de ez egyszerűen megoldható a "hullámforma" táblázatba 256 fix értéket írva, ami beállítja a helyes hangerőt. Nagy méretű táblázat is jó megoldás lenne, csak túl lassú.
A sid playerben van egy 4096 elemű konverziós táblázat, ha a zajhoz azokat az értékeket mentenénk le, akkor csak be kell tolni a Dave-nek, erre gondoltam, Meg az egészet úgy, hogy van két verzióm, az egyik sid player a SID regisztereket menti, a másik meg a Dave ragisztereket lejátszás közben, minden megszakításban, a kettőt összegyúrva, miből mi kell, lehetne talán a legkevesebb lejátszás közbeni adatátalakítással megúszni az egészet. ( a freki, és a hullámforma értékeket a SID regisztereket mentő változatból, a zaj freki, és a hangerő értékeket meg a Dave regisztereket mentő változatból, vagy esetleg csinálni egy 3. verziót, ami azt menti le, amit kell :D ) Ezt összenyomni egy egyszerű, és gyors tömörítéssel, hogy ne legyen nagy a file, az eddigi pár zenénél ezt manuálisan csináltam :D
Quote
A táblázat címzése két értékkel történik: az eredeti hangmintával, és a hangerővel. A mérete tehát ezek lehetséges értékei számának a szorzata (pl. 64 * 64, de a 64 * 256 címzése gyorsabb).
Akkor nem egyszerűbb a 2 hullámformára megcsinálni a 15 volume változatot, ami kevesebb, mint 8k, és azt változó frekivel lejátszani? :ooops:
A négyszögjelnél meg az említett 32-t, és azt a megfelelő volume értékkel lejátszani?
Title: Re: Assembly programozás
Post by: lgb on 2013.November.04. 21:01:38
Quote from: endi
ohohóóó, látom fertőző Z80System betegsége, már mindenki komondort akar faragni az EP-ből
:twisted:

:D Oh, szo sincs rola, max csak arrol, hogy lehet programbol is generalni sample hangmintat, erre egy pelda a SID emulalasa. Nem azt mondtam, hogy pont ez kene EP-be ...
Title: Re: Assembly programozás
Post by: Povi on 2013.November.05. 08:18:03
tud valaki abban segíteni, hogy hogyan kell grafikus lapot létrehozni (nem EXOS-szal)? Arra gondolok, hogy le van foglalva szabályosan egy videoszegmens, és egy szegmensen van az egész videomemória, szegmenshatáron kezdődően. 16 színű, hi-res, 160x240 képernyő kéne. Az lenne a legjobb, ha lennének kommentek, hogy hol lehet palettát, BIAS-t állítani, hol lehet nagyobb (több pixelsort) állítani, színmódot állítani (tudom, hogy az LPT-t kell birizgálni hozzá, de bevallom férfiasan, hogy nem nagyon értem...)
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.05. 08:53:31
Ide raktam be ilyesmi példát. (http://enterpriseforever.com/programozas/asm-ep-n-hogyan-kezdjem/msg22937/#msg22937) Az ugyan 320x200 4 szín, de talán rájössz, hol kell átírni :-)
Nehezítés, hogy a 240 sorhoz már 2 videószegmens kell.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.05. 08:58:24
köszi, ilyenre gondoltam :-)
rémlett is, mintha már lett volna ilyen kód valahol
fölrakhatom az EP-WIKI-re, hogy nem merüljön el a fórumok mélyén?

egyébként valószínűleg elég lesz a 200 pixeles magasság is...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.05. 09:05:41
Quote from: Povi
fölrakhatom az EP-WIKI-re, hogy nem merüljön el a fórumok mélyén?
Nyugodtan!
Title: Re: Assembly programozás
Post by: Povi on 2013.November.05. 09:27:02
Zozo, bocs a béna kérdésért... de:
a VIDCIM1-en eltárolt cím mutatja meg, hol kezdődik a grafikus memória (bal felső pixel címe).
a VIDCIM1-re eltárolt videomemória cím az abszolút Z80 cím? (nem tudom, érthető-e a kérdés...). Mert azt látom, hogy az igényelt videoszegmens a 3-as lapra lesz belapozva. Vagyis VIDCIM1 értéke >= 0C000H? Vagy ez mindig 0C000H lesz?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.05. 09:42:54
A VIDCIM1 az videócím, a kapott szegmens számából van számolva (ahogy a fórum beszámozta, a 44-54 sorokban), tehát változhat.
Mivel a 3. lapra van belapozva, a képernyő memória Z80-as címe az 0C000h, fixen (hacsak nem lesz átlapozva).
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.05. 09:49:08
Quote from: Povi
tudom, hogy az LPT-t kell birizgálni hozzá, de bevallom férfiasan, hogy nem nagyon értem...
Egyébként emlékszem, hogy sok évig nekem is "mumus" volt ez a LPT téma, meg a Z80/videó címek különbözősége. Aztán egyszer beugrik az embernek, és rájön, hogy tök egyszerű :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.05. 12:37:01
Grafikus képernyő kezelésére az itt (http://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35541/#msg35541) található programokban is van néhány egyszerű példa:
- video szegmensek foglalása és a nem használt szegmensek felszabadítása
- egyszerű LPT (az egész aktív képterület egy LPB) létrehozása és a cím beállítása
- BORDER és BIAS állítása EXOS hívással
- vonal rajzolása és terület feltöltése (FILL) 2 színű módban (graph.s)
- 16 színű pixel rajzolás dither használatával (mandel.s)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.05. 12:51:48
Quote from: geco
A négyszögjelnél meg az említett 32-t, és azt a megfelelő volume értékkel lejátszani?
Az is egy lehetséges megoldás, de akkor a lejátszó kódban kell megvalósítani a hangerő szabályozását. Ez lehet egy egyszerű AND utasítás (7 ciklus a hangerű táblázat 14 ciklusa helyett), de akkor kis hangerőnél "kattog" a négyszögjel az indításakor és a kikapcsolásakor (mert például 48 és 16 helyett 32 és 0 értéke lehet fél hangerőnél). Vagy egy kis méretű táblázat csak négyszögjelhez (a többi hullámformánál letiltva), ami helyet takarítana meg (illetve valójában nem, csak nem lenne "szétszórva" a szabad terület, mint a 16K-s táblázatnál, amiből csak 4K ténylegesen használt) a hangerőszabályozás kisebb felbontása árán. Egyébként 16 hangerő szintnél a külön táblázat foglalna kevesebb helyet, és még 32-nél is csak kb. hasonló memória igénye lenne. :)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.05. 13:29:17
Zaj összehasonlítás:

[attachurl=#]

3 különböző frekvencia, az utolsó a legnagyobb, amit a C64-es SID tud. Minden frekvencián a 3 generátor ebben a sorrendben hallható:
- 1.: PC-s véletlenszám generátor 8 bites felbontásra kerekítve (ez az eredeti - jó minőségű - SID zajt prbálja közelítően emulálni)
- 2.: 17 bites polinom számláló (~0.577x hangerővel, hogy ne legyen hangosabb, mint az előző)
- 3.: 256 elemű táblázat véletlenszerű 8 bites értékekkel feltöltve
Title: Re: Assembly programozás
Post by: geco on 2013.November.05. 14:20:34
a polinom számlálós verzió egész jó, alacsony frekin hallottam különbséget.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.05. 15:05:18
Quote from: IstvanV
Grafikus képernyő kezelésére az itt (http://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35541/#msg35541) található programokban is van néhány egyszerű példa:
- video szegmensek foglalása és a nem használt szegmensek felszabadítása
- egyszerű LPT (az egész aktív képterület egy LPB) létrehozása és a cím beállítása
- BORDER és BIAS állítása EXOS hívással
- vonal rajzolása és terület feltöltése (FILL) 2 színű módban (graph.s)
- 16 színű pixel rajzolás dither használatával (mandel.s)
igen, nézegettem azokat is, nekem főleg az LPT-vel voltak gondok, a szabályos szegmensigénylés eddig is ment :-) meg a rajzoló rutinokra gondoltam, hogy föl kéne használni Pascal-ban, és lenne egy übergyors pitpixel, lineto, moveto és floodfill rutin :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.06. 12:27:47
Quote from: geco
a polinom számlálós verzió egész jó, alacsony frekin hallottam különbséget.
Egy probléma azért még van a polinom számlálóval: ez sem kompatibilis azzal, ha 20h a kimenet, amikor nincs hang. Tehát ez is "kattogna" alacsony hangerőnél. Ha minden hullámformánál 00h lenne a kikapcsolt hang, akkor legalább következetesen fordulna elő ez a "hiba". :) Így azonban már lehetséges lenne a hangerő táblázat elkerülése, és AND utasítás használata a négyszögjel és zaj 6 bites hangerő szabályozásához. A fűrészjelnél és a háromszögjelnél külön táblázatokat készítve minden hangerőhoz az 5 bites felbontás még elfogadható memória igényű (2 * 8 KB), és a táblázatokban nem csak lineárisan növekvő hangerő lehet - a logaritmikus jobban kihasználja a korlátozott felbontást. További előny, hogy pont marad még idő gyűrűmodulációra is:

Code: ZiLOG Z80 Assembler
  1. sidSynth:
  2.         di                              ;                                 4
  3. .l1:    ld      bc, 0000h               ; * frequency 1 (= SID_freq/4)   14
  4.         add     ix, bc                  ;                                29
  5.         ld      a, h                    ;                                33
  6. .l2:    and     00h                     ; * 00h/80h: ring mod. off/on    40
  7.         xor     ixh                     ;                                48
  8.         ld      e, a                    ;                                52
  9. .l3:    ld      d, high triangleTable   ; * waveform/volume 1            59
  10.         ld      a, (de)                 ;                                66
  11. .l4:    and     0ffh                    ; * square/noise volume or FFh   73
  12.         out     (0a8h), a               ;                                84
  13. .l5:    ld      bc, 0000h               ; * frequency 2 (= SID_freq/4)   94
  14.         add     iy, bc                  ;                               109
  15.         ld      a, ixh                  ;                               117
  16. .l6:    and     00h                     ; * 00h/80h: ring mod. off/on   124
  17.         xor     iyh                     ;                               132
  18.         ld      e, a                    ;                               136
  19. .l7:    ld      d, high triangleTable   ; * waveform/volume 2           143
  20.         ld      a, (de)                 ;                               150
  21. .l8:    and     0ffh                    ; * square/noise volume or FFh  157
  22.         out     (0adh), a               ;                               168
  23. .l9:    ld      bc, 0000h               ; * frequency 3 (= SID_freq/4)  178
  24.         add     hl, bc                  ;                               189
  25.         ld      a, iyh                  ;                               197
  26. .l10:   and     00h                     ; * 00h/80h: ring mod. off/on   204
  27.         xor     h                       ;                               208
  28.         ld      e, a                    ;                               212
  29. .l11:   ld      d, high triangleTable   ; * waveform/volume 3           219
  30.         ld      a, (de)                 ;                               226
  31. .l12:   and     0ffh                    ; * square/noise volume or FFh  233
  32.         out     (0aah), a               ;                               244
  33.         ei                              ;                               248
  34.         jp      sidSynth                ;                               258

Így (a megszakítások által "ellopott" időt figyelmen kívül hagyva, ami lassítja és torzítja a lejátszást) a mintavételezési frekvencia 15503.88 Hz, ami jól közelíti a PAL C64-es SID órajelének a 64-ed részét (15394.51 Hz), egyszerűsítve a frekvencia konverziót, legalábbis a zaj kivételével. Problémák:
- a paraméterek kezelése megszakításban viszonylag bonyolult a konverziók és a különböző hullámformák eltérő megvalósítása miatt
- "kattogás" a 20h helyett 00h referencia szint miatt
- alacsony frekvencián a polinom számlálós zaj eltér az eredeti SID zajtól (ha nem is nagyon zavaróan); figyelni kell még a zaj hangerejére is, amit csökkenteni kell a többi hullámformához képest, hogy ne legyen túl hangos

Éredekes lenne még egy nagyobb tudású, de lassabb emulátort készíteni, ami turbós gépeken a lehető legjobb minőséget próbálná elérni (szinkron emulációja, nagy táblázatos zaj, nagy frekvenciájú megszakítás jobb burkológörbékhez, stb.).
Title: Re: Assembly programozás
Post by: geco on 2013.November.06. 13:28:42
:smt041 Ez teccik, ha elődolgozott adatokkat használunk, akkor az sokat faraghat a megszakításban futó vezérlés idejéből, pl a zaj hangerejét is előemésztve adni a vezérlés szájába, úgy gondoltam, hogy semmit se kelljen online konvertálni, midnen konvertálnivaló legyen előre lekonvertálva ( zaj frekvencia, esetleg már a 64-gyel való osztás is legyen elrőe elintézve ha nem zajunk van, és a zaj volume értékei is, az egy másik kérdés, hogy ezt a program intézze futás előtt, vagy eleve már a beolvasott fájl így tartalmazza ezeket az értékeket )
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.06. 13:31:52
Quote from: IstvanV
Éredekes lenne még egy nagyobb tudású, de lassabb emulátort készíteni, ami turbós gépeken a lehető legjobb minőséget próbálná elérni
Ezt már én is akartam javasolni!
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 15:19:20
Olyanban gondolkodok, hogy a csillagmozgatásom is teljesen letárolt lesz (amint próbalok bármit számolni, vagy sebessegtáblazatot használni, rögtön duplázódik az ideje), es a letárolt mozgásból pedig pop -al akarok olvasni, ezért a csillagmozgas kirajzolo kodot betennem chunk -okban a 4KHz hangmegszakításba (mert a főprogramban a megszak miatt nem hasznalhatok SP -t) oly módon, hogy mikor lement az az X darab hangmegszak, amelyek a hang mellett a csillagokat is rajzolják, akkor az utolsó átváltja a hangmegszakot a korábban már tárgyalt síma és gyors hangmegszakra, és a csillagrajzolós verziót majd csak a video megszak figyelés után váltja vissza a főprogram.

Így azt akarom elérni, hogy mikor a csillagos verzió fut, az olyan legyen, mintha az főprogramban futna, csak a főprogramnak olyankor egyáltalán nem lesz ideje futni, hanem a hangmegszak töltse ki az összes időt, aztán meg mikor a sima hangmegszak van, akkor az maximális sebességgel pörögjön, és így a főprogram is.

Na most az lenne a kérdés, hogy van -e erre elvben lehetőség ?
Tehát feltételezve, hogy a csillagrajzolás kód szinte semilyen feltételes utasítást nem fog végrehajtani, tehát nagyjából konstans ideje lesz, mondjuk elvben mintha csak NOP -okat tartalmazna,
akkor lehet -e ezt olyan jól kiidőzíteni, hogy kihasználja a 4KHz megszak teljes idejét, majd visszamenjen a főprogramba, gyakorlatilag csak azért, hogy újra hívódhasson a megszakítás ?
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.13. 15:35:04
Quote from: Z80System
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?
Igazából nem pont a "megszakítás ütemezője" miatt, de természetesen bizonyos időzítési pontatlanságra számítanod kell mindenképp. Legalábbis szerintem. Nem tudod semmilyen módon garantálni, hogy a megszakításkezelő órajelre pontosan mikor induljon el, mivel nem fogod tudni, hogy éppen milyen utasítást hajt végre a Z80. Ezen felül mivel a videomemóriát írod, számolnod kell a Nick által lefoglalt buszciklusokkal is. Bár ez utóbbira IstvanV vagy Zozo lehet, hogy tudna rajzolni neked egy táblázatot az egyes rasztersorokban a processzor számára elérhető szabad ciklusokról. A legegyszerűbb valószínűleg az lenne, ha elméleti számítások helyett írnál egy tesztprogramot, és tesztelnéd mennyi idő áll rendelkezésre biztonságosan.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 15:38:52
Quote
A legegyszerűbb valószínűleg az lenne, ha elméleti számítások helyett írnál egy tesztprogramot, és tesztelnéd mennyi idő áll rendelkezésre biztonságosan.


Hát pont ez az, amit meg akarnék úszni a kérdezgetéssel ... Nyilván ha ilyen megoldás mellett döntök, akkor annak kikísérletezésétől, hogy mekkora chunk -okban tudom a csillagaimat kirajzolni, nem ment meg senki.

De ha már most eltántorít valaki attól, hogy az 1/4KHz -es időintervallum méretéhez képest egy komoly méretű lehet az ilyen bizonytalanság miatti ráhagyás vesztesége, akkor megúszok egy csomó felesleges kísérletezést.
Title: Re: Assembly programozás
Post by: lgb on 2013.November.13. 16:29:31
Quote from: Z80System
Tehát feltételezve, hogy a csillagrajzolás kód szinte semilyen feltételes utasítást nem fog végrehajtani, tehát nagyjából konstans ideje lesz, mondjuk elvben mintha csak NOP -okat tartalmazna,
akkor lehet -e ezt olyan jól kiidőzíteni, hogy kihasználja a 4KHz megszak teljes idejét, majd visszamenjen a főprogramba, gyakorlatilag csak azért, hogy újra hívódhasson a megszakítás ?
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?


Hat, nem biztos, hogy igazam van, de: ha Dave-ben nem torlod az adott interrupt-hoz tartozo latch-t, akkor a megszakitasbol valo visszateres utan azonnal ujra megszakitas lesz belole. Elvileg ez amugy tipikus programozasi hiba is, hogy elfelejti vki torolni, de jelen esetben lehet hasznos is. Persze, nem art, ha tenyleg konstans ideje van a megszakitasodnak, ha nem akarod, hogy szoras legyen a sebessegben. Speciel ez erdekes dolog, mert ha turbos gepen futtatod, akkor viszont annyival gyorsabb is lesz, mivel itt akkor a CPU sebessege fogja meghatarozni (mennyi ido alatt fut le az interrupt rutinod - hisz utana azonnal ujra interrupt lesz) a dolog sebesseget egyedul ...

Viszont nem teljesen ertem ez mire jo, ilyen elven ne is terj vissza az interrupt-bol amig a foprogramnak ugysem kell futnia, minek is akkor? Vagy lehet, valamit nem ertek, amugy csak ezt a hozzaszolast olvastam eppen az egesz temabol :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 16:33:11
Quote
Viszont nem teljesen ertem ez mire jo, ilyen elven ne is terj vissza az interrupt-bol amig a foprogramnak ugysem kell futnia, minek is akkor?


Hát pont azért amit írtál ... mert akkor turbós gépen is jó lesz.

Sima gépre kéne becipőkanalazni, ott érdekes hogy mennyit bukok a szórás miatt. Komoly méretű -e a szórás miatti ráhagyás az 1/KHz intervallumok esetén.

Ha a gép meg ennél gyorsabb, akkor lesznek lukak, de az már nem számít, nem kell, hogy turbó gépen gyorsabban menjen. Sőt, az viszont kell a hang miatt, hogy a megszak ne menjen gyorsabban ... :)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.13. 16:40:14
Quote from: Z80System
Hát pont ez az, amit meg akarnék úszni a kérdezgetéssel ... Nyilván ha ilyen megoldás mellett döntök, akkor annak kikísérletezésétől, hogy mekkora chunk -okban tudom a csillagaimat kirajzolni, nem ment meg senki.

De ha már most eltántorít valaki attól, hogy az 1/4KHz -es időintervallum méretéhez képest egy komoly méretű lehet az ilyen bizonytalanság miatti ráhagyás vesztesége, akkor megúszok egy csomó felesleges kísérletezést.
De most komolyan! Tényleg azt várod, hogy valami nem létező kódról itt bárki megmondja neked, hogy tudja teljesíteni a kritériumaidat vagy sem?!

Egyébként tegyük fel egy pillanatra a gondolkodó sapkát! 4kHz-es megszakításnál van 1000 órajelciklusod két megszakításkérés között. Ebből ha levonod a használni tervezett leghosszabb Z80 utasítás órajelciklusainak kétszeresét, akkor nagyjából meg van az az érték, ami garantáltan rendelkezésedre fog állni. 312 soros LPT esetén nagyjából 3,9 soronként fog bekövetkezni megszakítás. Ha lenne információ arról, hogy rasztersoronként mennyi órajel szabad a videomemória írására illetve tudnád, hogy hány ciklusonként akarod írni, akkor valszeg tudnál egy becslést adni arra, hogy átlagosan mennyi késleltetést fog összeszedni a kódod a Nick buszfoglalása miatt a megjelenített képernyő sorokban.

De gondolom te nem ezt szeretted volna itt olvasni, hanem valami "Igen, 332." szerű választ. Félek, ez nem fog menni. Senkinek.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 17:07:25
Quote
De most komolyan! Tényleg azt várod, hogy valami nem létező kódról itt bárki megmondja neked, hogy tudja teljesíteni a kritériumaidat vagy sem?!
írottam vagyon:

"mondjuk elvben mintha csak NOP -okat tartalmazna,"


Quote
Egyébként tegyük fel egy pillanatra a gondolkodó sapkát!

Csak előtte mindenképp olvasd el amit írok.


Quote
4kHz-es megszakításnál van 1000 órajelciklusod két megszakításkérés között. Ebből ha levonod a használni tervezett leghosszabb Z80 utasítás órajelciklusainak kétszeresét, akkor nagyjából meg van az az érték, ami garantáltan rendelkezésedre fog állni. 312 soros LPT esetén nagyjából 3,9 soronként fog bekövetkezni megszakítás. Ha lenne információ arról, hogy rasztersoronként mennyi órajel szabad a videomemória írására illetve tudnád, hogy hány ciklusonként akarod írni, akkor valszeg tudnál egy becslést adni arra, hogy átlagosan mennyi késleltetést fog összeszedni a kódod a Nick buszfoglalása miatt a megjelenített képernyő sorokban.

De gondolom te nem ezt szeretted volna itt olvasni, hanem valami "Igen, 332." szerű választ. Félek, ez nem fog menni. Senkinek.

Most nem idézgetek be magamtól mindent, amitől azt hinni, hogy ezt hiszem, nem állja meg a helyét.

Mondom a lényeget. Újra. A megszakítási rendszer/z80 bizonytalankodásairól kérdeztem. Az lenne a kérdés, hogy van -e bizonytalanító faktor, és ha van, mekkora százalékos arányban lehet az 1/4KHz -hez képest.

Nem ismerem a fent említett NICK -kel kapcsolatos késlekedési szabályokat, de a késlekedés nem baj, ha X csillagnál X -szer van késlekedés, akkor az csak az összidőt növeli.
Ha azonban ez a NICK dolog olyan, hogy lehet hogy minden íráskor lesz, lehet hogy 1X sem, akkor már elképzelhető, hogy nagy lenne a bizonytalanság.
Viszont összegészében memória írásokkor mégsem gondolnám, hogy csupán azoktól komolyabb BIZONYTALAN késlekedés jönne össze ... valahogy úgy hinném, hogy ezek majd jól kioltják egymást, és kisül belőle valami átlag, tehát konstans késlekedés, ami viszont nem bizonytalan.

De ez már egy új dolog az eredeti kérdéshez képest, aminek a viselkedését meg most sem ismerem (pedig hát ez lenne a kérdés, hogy ilyenek vannak -e, és hogy kell velük számolni, milyen mértékben befolyásolnak vajon egy 1/4KHz -es időszeletet), az eredeti kérdés pedig ELVBEN és NOP -okról szólt.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.13. 17:45:41
Juj!

 Megszakítási rendszer bizonytalankodása: igen van, attól függően, hogy milyen utasítás fut éppen és az hol tart, változó számú ciklust késhet a kezelő indulása.

Nick buszkésleltetés:
mind-mind bizonytalansági tényező, ami változó mértékű késleltetést tud okozni. Mármint olyan kód esetében, ami effektíve használja a videomemóriát.

 Elvben mintha csak NOP-okat tartalmazna: egy NOP 4 ciklus, akkor kb. 253-254 NOP-od biztosan van. Még szerencse, hogy nem csinálnak semmit, így a majdani gyakorlati megvalósítás szempontjából semmit sem mondanak a problémáiddal kapcsolatban.

Nézd, én nem akarom azt állítani, hogy te hülye lennél, csak én vagyok helikopter, de még ha nem is olvastam végig és elemeztem részletesen az összes rögzített állításodat, az olvasmány élményeim és más gépen összegereblyézett ismereteim alapján próbáltam felhívni a figyelmed a tényleges gyakorlati megvalósítás során előtted álló problémákra, illetve arra hogy valós tesztekkel gyorsabban eljuthatsz a szükséges tudás megszerzéséig, mintha próbálnál elméleti konstrukciókat gyártani jelenleg nem pontosan ismert bizonytalanságok figyelmen kívül hagyásával. Már ha jól ki bírom magamat fejezni. Sajnos az sem erősségem. :(
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 18:47:06
Quote
Nézd, én nem akarom azt állítani, hogy te hülye lennél, csak én vagyok helikopter,

Hát ez szép tőled ...


Quote
de még ha nem is olvastam végig és elemeztem részletesen az összes rögzített állításodat, az olvasmány élményeim és más gépen összegereblyézett ismereteim alapján próbáltam felhívni a figyelmed a tényleges gyakorlati megvalósítás során előtted álló problémákra,

Hát mégis úgy éreztem, hogy túl nagy az a gondolkodó sapi, és a szemed elé csúszott egy pillanatra.


Quote
illetve arra hogy valós tesztekkel gyorsabban eljuthatsz a szükséges tudás megszerzéséig, mintha próbálnál elméleti konstrukciókat gyártani jelenleg nem pontosan ismert bizonytalanságok figyelmen kívül hagyásával.

Ijesztő számomra, de kezdek hajlani eme igazságra, de azért még van bennem remény, hogy valaki másképp idomul a kérdéshez, és mégis tud valami ennél ügyesebb közelítést ismerni fel és adni, megmentve engem a dolog potyára kipróbálásától.


Quote
Megszakítási rendszer bizonytalankodása: igen van, attól függően, hogy milyen utasítás fut éppen és az hol tart, változó számú ciklust késhet a kezelő indulása.

Hát igen, de azt gondolnám, hogy mondjuk 1-20 BIZONYTALAN ciklus ideje az 1/4KHz -es időhöz képest nem egy nagy eresztes, elhanyagolható ... ennyi jöhetne kb. egy utasításból, gondolom ... ezt sztm be lehetne áldozni. De vajon milyen BIZONYTALAN késlekedések lehetnek még ...

Valahogy nehezen fér bele a világképembe, hogy ha én pld. mást sem csinálok, csak video RAM -ot írok egymás után folyamatosan egy 1/4KHz "időtartamig" (kibontott kód, semmi más), akkor egy komolyan ingadozó idejű kódot kapnék, mondjuk az említett NICK működésből fakadó bizonytalankodás miatt.

Vagy mégis ? És ha igen, akkor mondjuk egy ilyen teoretikus esetben vajon ez mekkora lehet ? A bizonytalankodás ? A minimum és maximum idejű lefutás közötti különbség ?

Quote
[ul]
  • videoszegmensben fut a kódod?
[/ul]
(Hát még persze, hogy) nem.

[ul][/ul]
Ír csak a képre.

Quote
[ul]
  • mindig csak kereten fut a kódod, vagy a képernyő aktív területén is?
[/ul]
Hát eddig nem akartam ezzel vacakolni, de ha ettől lenne stabil, beküzdhetem a keretre.





Egyébként lehet hogy túl erős lépés lenne ez ... túl komplex optimalizálási lépés az eredményhez képest ... Ez az egész megszakításba pumpálás ...

Van pld. egy ilyen verzió, amihez 1 db szegmens (adat) kell, és simán tudna működni a főprogramból (nincs benne SP használat):

 ld d, (hl)
 ld (de), a
 inc l
 inc e

 ld d, (hl)
 ld (de), a
 inc l
 inc e

ez egy csillagot törölne, majd kiírna új helyre, kettő között persze lenne nem csillagonkéni inicializáló kód
ez csak a magot tekintve 11 us -ig tartana,

és ehhez képest lenne a gyorsabb, megszakba kényszerülő verzió, aminek mellesleg 2 szegmens (adat) is kéne :) :

 pop hl
 ld (hl), a

 pop hl
 ld (hl), a


ami 8.5 us lenne ... szoval a 11 -hez képest azért jelentős, de nem biztos, hogy feltétlenül fontos olyan áron, amiket itt beszélünk.

Pláne, hogy eddig 21 us körül volt ... és már azt is elfogadtam lélekben.
Title: Re: Assembly programozás
Post by: endi on 2013.November.13. 19:01:22
tényleg, miért nem próbálgatod ezeket ki? hamarabb megvan mint hogy leírnád ide :)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2013.November.13. 19:03:38
Quote
Ijesztő számomra, de kezdek hajlani eme igazságra, de azért még van bennem remény, hogy valaki másképp idomul a kérdéshez, és mégis tud valami ennél ügyesebb közelítést ismerni fel és adni, megmentve engem a dolog potyára kipróbálásától.
Bárminek a kipróbálása soha sem számít potyára dolgozásnak. Szerintem. Még akkor sem, ha valaki már kipróbálta előtted és bebizonyította hogy működik vagy nem. Mert mi van, ha te még észreveszel valamit, ami vagy jobbá vagy egyáltalán lehetővé teszi a próba tárgyát?

Egyébként gondolod, hogy IstvanV amikor írta az ep128emu-t csak úgy ült és elmélkedett magában, vagy írta az egyre trükkösebb és optimalizáltabb teszt programokat, és időnként meglepődött? Különben ő lenne a legjobb ember erre a feladatra (ahogyan látom), de nem vagyok benne biztos hogy meg akarná írni helyetted a programod legtrükkösebb részeit. :)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 19:10:46
Quote
Egyébként gondolod, hogy IstvanV amikor írta az ep128emu-t csak úgy ült és elmélkedett magában, vagy írta az egyre trükkösebb és optimalizáltabb teszt programokat, és időnként meglepődött?
Ezért is IstvanV egy megaguru aki rúlz, én meg egy szimmepla alkalmazás programozó, aki küzd ...

Quote
Különben ő lenne a legjobb ember erre a feladatra (ahogyan látom),
Vagy Zozo, vagy geco, vagy te, vagy akárki aki ért hozzá ... (kivéve endit persze :))


Quote
de nem vagyok benne biztos hogy meg akarná írni helyetted a programod legtrükkösebb részeit. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)

Hát sajnos ... pedig az lenne a legegyszerűbb. De hát ez a fránya teremtő kitalálta ezt a szabad akarat dolgot ... lennék csak én a helyébe, minden EP guru játékot kódolna ... vagy pedig lenne az EP -be szprá ...
Title: Re: Assembly programozás
Post by: szipucsu on 2013.November.13. 19:33:55
Quote from: Z80System
Vagy Zozo, vagy geco, vagy te, vagy akárki aki ért hozzá ... (kivéve endit persze :))
Én is meg tudnám csinálni, de csak BASIC-ben, sok IF-fel, ami kicsit lassú lenne, de nem baj, mert ott a Zzzzzzzzip! :D
Itt már megint nem az assembly programozásról van szó lassan, de sebaj. :D
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.13. 19:42:23
Quote
Itt már megint nem az assembly programozásról van szó lassan, de sebaj. (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Azért a célt sem veszítjük szem elől.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.13. 19:48:39
Errefelé tettem be méri eredményeket. (http://enterpriseforever.com/hardver/nick/msg32717/#msg32717) És ezek még csak szimpla ismétlődő utasítások voltak... Szerintem is mérd le, egy hosszabb kódra lesz egy átlag.

Ami szóba került, hogy keret - nem keret, az Nicknél nem számít, az se, hogy van-e képernyő vagy nincs, mindig pontosan ugyanolyan ütemben használja a videó memóriát.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.14. 10:05:57
tudtok ajánlani valami jó Z80 dissassembláló programot PC-re?
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.14. 10:09:21
Hát ... az emuban van ... az emu meg PC -n is ... annál kényelmesebbet keresnél ?
Title: Re: Assembly programozás
Post by: Povi on 2013.November.14. 10:18:53
ööö... én olyat keresek, amibe betöltök egy fájlt, megmondom a kezdőcímet (hogy hova dissassemblálja), majd kiírja nekem txt fájlba
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.14. 10:26:37
Aham ... hát ilyet még nem csináltam emuban. Simán lehet hogy nem is tud ilyet. De sajnos nem ismerek direkt PC disassemblert.
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.14. 10:34:19
Quote from: Z80System
Aham ... hát ilyet még nem csináltam emuban. Simán lehet hogy nem is tud ilyet. De sajnos nem ismerek direkt PC disassemblert.
Az emulátor disassemblere file-ba is tud írni, például d "" 100 3fff. Azonban ha fordítható assembler kód kell címkékkel, akkor érdemesebb erre a célra készült külső disassemblert használni.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.14. 10:38:08
köszi
közben találtam ezt: dZ80
egész használhatónak tűnik
http://www.inkland.org.uk/dz80/ (http://www.inkland.org.uk/dz80/)
legközelebb google-zok, aztán kérdezek... :oops:
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.14. 10:38:14
Quote from: Povi
ööö... én olyat keresek, amibe betöltök egy fájlt, megmondom a kezdőcímet (hogy hova dissassemblálja), majd kiírja nekem txt fájlba
Az ilyen fajta disassemblerrel nem mész sokra, max nagyon egyszerű programok esetén. Mindenesetre ilyen a DZ80
IDA-val lehet jobban boldogulni, azzal meg csak az a baj, hogy pl az EXOS hívásokat nem ismeri, kézzel kell mindet szerkeszteni, hogy az RST után DB legyen.
Beszéltünk már sokat arról, hogy kéne egy jó, EP-t ismerő disassembler, de eddig még nincs ilyen :-(
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.14. 10:41:49
Quote from: Povi
köszi
közben találtam ezt: dZ80
Ehhez csináltam EXOS hívás felismerőt.
Title: Re: Assembly programozás
Post by: endi on 2013.November.14. 10:46:03
jó lesz ha abbahagyjátok ezeket a tool fejlesztéseket mert a végén még én is elkezdek megint ep-re programozni
:)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.14. 10:59:05
[attachimg=1]
Title: Re: Assembly programozás
Post by: Povi on 2013.November.14. 11:40:54
Quote from: Zozosoft
Ehhez csináltam EXOS hívás felismerőt.
de jó, köszi! :-)
Title: Re: Assembly programozás
Post by: lgb on 2013.November.14. 14:51:35
Quote from: Zozosoft
Az ilyen fajta disassemblerrel nem mész sokra, max nagyon egyszerű programok esetén. Mindenesetre ilyen a DZ80
IDA-val lehet jobban boldogulni, azzal meg csak az a baj, hogy pl az EXOS hívásokat nem ismeri, kézzel kell mindet szerkeszteni, hogy az RST után DB legyen.
Beszéltünk már sokat arról, hogy kéne egy jó, EP-t ismerő disassembler, de eddig még nincs ilyen :-(

Az epbas projectem kereteben kezdtem el ilyet (http://epbas.lgb.hu/) ugye, csakhat azert messze van attol, hogy igazan jo legyen ... Ez mondjuk disasm mellett tud par mas dolgot is, pl basic (innen a neve az "epbas"), meg kepet is pl.

Itt van par sample kimenet, amiket csinal: http://epbas.lgb.hu/tryit/?storage=index (http://epbas.lgb.hu/tryit/?storage=index), weben at is hasznalhato, nem feltetlen kell letolteni (mert akkor kell ala python, stb)

Itt a tema a forumon (http://enterpriseforever.com/programozas/bas-konverzio-pc-n/), az elejen meg csak basic-rol van szo benne.
Title: Re: Assembly programozás
Post by: szipucsu on 2013.November.14. 19:06:49
Quote from: endi
jó lesz ha abbahagyjátok ezeket a tool fejlesztéseket mert a végén még én is elkezdek megint ep-re programozni :)
Ejnye, mivel te nem programozol EP-re, más se tegye? Miféle sabotage ez? :D
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.14. 19:08:56
Quote
 Miféle sabotage ez? (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)
Saboteur.
Title: Re: Assembly programozás
Post by: szipucsu on 2013.November.14. 19:31:34
Quote from: Z80System
Saboteur.
Igen. Megtalálja a lemezt tele EP programokkal, majd egy helikopterrel lelép a cuccal. :D
Title: Re: Assembly programozás
Post by: Povi on 2013.November.15. 22:04:39
gyöngyszemek a HiSoft Pascal-ból:

1. értékadás HL-nek
2. elmenti HL értékét a memóriába
3. HL-nak más értéket ad
4. csinál vele valamit, tök mindegy mit
5. a memóriából visszatölti a HL értékét
???
a 2. és az 5. pontot ki lehetne hagyni, és az 5. helyére tenni az 1.-t

még az is jobb lett volna, ha a 2. és 5. pont helyett egy PUSH és egy POP van, de annak se lett volna értelme
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.15. 22:06:23
És az 5. pontra nincs ugrás máshonnan?
Title: Re: Assembly programozás
Post by: Povi on 2013.November.15. 22:33:20
nincs :-)
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.16. 00:01:53
PC regiszter valami általánosabb regiszterbe töltésére van valami szép módszer ? Szebb mondjuk ennél :

call addr
addr:
pop hl
Title: Re: Assembly programozás
Post by: IstvanV on 2013.November.16. 09:36:33
Quote from: Z80System
PC regiszter valami általánosabb regiszterbe töltésére van valami szép módszer ? Szebb mondjuk ennél :

call addr
addr:
pop hl

Ebben az esetben (ha a POP HL közvetlenül a CALL után található) egyszerű "LD HL, addr", mert az "addr" fix címre fordítódik, egyébként a CALL nem is működne. Fix címen található, pozíció független kódból több helyről hívható rutin ilyen lehetne:
Code: ZiLOG Z80 Assembler
  1. getPC:
  2.         pop     hl
  3.         jp      (hl)
Ha fontos a sebesség/méret, akkor ezt célszerű RST utasítással hívni.

Hasonló megoldás használható 32 bites x86 kódban is, ezt például a "gcc -m32 -fPIC" kimenetéből másoltam:
Code: [Select]
00000000 <__x86.get_pc_thunk.cx>:
   0:   8b 0c 24                mov    ecx,DWORD PTR [esp]
   3:   c3                      ret
A 64 bites x86 már támogatja az RIP relatív címzést, így ott nincs szükség ilyen trükkre.
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.16. 11:49:15
Igazából úgy tűnik mégsem fog kelleni ilyen PC babrálás, mert megoldódott nélküle.

Nálam ilyen a memória (lap) kiosztás:

F8,FC,FD,FE

Amiből F8 természetesen a kód+mindenféle adat és változó terület (meg az első 100h ugye),
és FC,FD,FE pedig a screen buffer -eim, plussz a sprite adatok, interleave -elve 100h -nként.
Az FE legvégén van üres 6K, az lesz a hangeffekt puffer.

Namost ehhez jön az FF szegmens legelejére tett LPT, de az jelenleg fix, nem animált, így az FF nincs is belapozva, csak addig míg inicializálási időben le van generálva rá az LPT.

Na és akkor ezekre jött rá a csillagmozgás szegmense, ami az F9 -re fog kerülni, és minden frame -ben be fog lapozódni a nullás lapon az F8 helyére, majd ha kirajzolta a csillagokat a másik három lapon lévő aktuális képernyőre, akkor visszakerül az F8 a 0xb0 -ra.

Mindezt úgy valósítom meg jelenleg, hogy az F8 -as normál szegmensemen olyan kód van, ami belapozza az F8 -at a 0xb1 -re is, majd átugrik rá arra a címre ami közvetlenül a lapozó utasítás után van az F8 szegmensen, de már a 0xb1 lapon, és ott pedig olyan kód folytatódik az F8 -on, hogy 0xb0 -ra berakja a csillagmozgás szegmensét (F9), és jp xxxx -szel ráugrik a csillagmozgás kódjára.
A csillagmozgás kódja először visszalapozza az FC szegmenst 0xb1 -re, ami ideiglenesen felülíródott a 0xb0 váltásához, kirajzolja a csillagokat, majd megjátsza az előző lapváltást és visszaugrást fordítva.
Az F8 -on lévő normál kód végül szintén visszalapozza az FC szegmenst a 0xb1 -re, mert ugye most meg az F9 -cel íródott felül a 0xb0 szegmensváltásához.
Ezután a következő csillag kirajzolásig nem változnak a szegmensek.

Na és amiért mindezt leírtam: az ehhez szükséges kódhoz nem volt szükségem sem PC babrálásra mint ahogy először gondoltam, de még módosított kódra sem.
Mindent ki tudtam fejezni fordítási időben, simán a fordítóval.
Mindezt úgy, hogy a F9 szegmensen lévő csillagmozgás kódot és adatot úgy másolom/generálom az F8 -on valahova épp befordult kódokból. De a kód és adat patterneket elég csak simán egymás után pakolgassam, azokban már minden címhelyes lesz a beforduláskor. Semmit nem kell "relokálgassak" rajtuk, és nincs bennük sem semilyen PC szamítgatás megvalósítva.
Title: Re: Assembly programozás
Post by: ergoGnomik 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.)
Title: Re: Assembly programozás
Post by: Z80System 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.
Title: Re: Assembly programozás
Post by: ergoGnomik 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?
Title: Re: Assembly programozás
Post by: Z80System 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.
Title: Re: Assembly programozás
Post by: IstvanV 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).
Title: Re: Assembly programozás
Post by: Z80System 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 ?
Title: Re: Assembly programozás
Post by: IstvanV 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.
Title: Re: Assembly programozás
Post by: IstvanV 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.
Title: Re: Assembly programozás
Post by: Povi 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.
Title: Re: Assembly programozás
Post by: Z80System 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 ?
Title: Re: Assembly programozás
Post by: Zozosoft 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.
Title: Re: Assembly programozás
Post by: Zozosoft 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).
Title: Re: Assembly programozás
Post by: Povi 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.
Title: Re: Assembly programozás
Post by: Zozosoft 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.
Title: Re: Assembly programozás
Post by: Z80System 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 ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.19. 10:47:40
Quote from: Z80System
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 ?

Nincs. Ill. az EXDOS már lefordul, de valahol vannak még benne kód relatív címzések, mert ha bele van írva, akkor már nem működik :oops:
Title: Re: Assembly programozás
Post by: Z80System on 2013.November.19. 10:53:00
Quote
Nincs. 
Pedig ha lenne, akkor sokkal több lehetőség közül választva tudnád hekkelni, nem ? Mikor helyet kell csinálni valaminek, vagy ilyesmi ...


Quote
de valahol vannak még benne kód relatív címzések

Az mi is ? Valami kódból számolt címzésre gondolsz ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.19. 10:57:03
Quote from: Z80System
Pedig ha lenne, akkor sokkal több lehetőség közül választva tudnád hekkelni, nem ?
Igen, ezért is ez a célkitűzés.

Quote
Az mi is ? Valami kódból számolt címzésre gondolsz ?
Igen, pl amikor mondjuk egy LD HL, szám esetén a szám az nem érték, hanem valaminek a címe a kódban. Ezeket mind meg kell találni és becimkézni, ahogy az a eredeti forrásban lehetett.
Title: Re: Assembly programozás
Post by: Povi on 2013.November.19. 15:59:48
Quote from: Zozosoft
Nincs mondjuk Spectrumra olyan, amiben már benne van? Akkor csak azzal kéne összevetni, hogy ott mit fejlesztettek.
ááá, még a CP/M-es változatban sincs olyan... :-)
Title: Re: Assembly programozás
Post by: lgb on 2013.November.19. 21:43:58
Quote from: Zozosoft
Igen, ezért is ez a célkitűzés.
Igen, pl amikor mondjuk egy LD HL, szám esetén a szám az nem érték, hanem valaminek a címe a kódban. Ezeket mind meg kell találni és becimkézni, ahogy az a eredeti forrásban lehetett.

IDA nem tud ilyet? Amikor meg az epbas -al disasm-oltam eppen, ott kerultem olyan helyzetben, hogy linearis code fragment eseten, ha konstansokat teszel regiszterben, akkor adott esetben tudja a disam pl hogy az LDIR-nel a regiszterek tartalma konstans, es az opcode jellegebol persze azt is, hogy ez egy masolas, ha lenne PHASE support benne, akkor pl itt mar ossze lehetne kapcsolni, hogy amutomatice kitalalja _bizonyos_esetekben_, hogy pl egy LD HL, szam eseten az egy memoriacim lesz.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.November.19. 21:51:35
Quote from: lgb
IDA nem tud ilyet?
Leginkább ott is kézzel megadni az ilyeneket.
De az EXDOS az DZ80-al van, mert annak el tudtam magyarázni az EXOS hívásokat, meg a CALL után még adatbájt féle trükköt, amiből kismillió van az EXDOS-ban.
(Nem véletlenül írogattam anno lelkesen milyen disassemblerre vágnyék :oops: )
Title: Re: Assembly programozás
Post by: Povi on 2013.December.10. 09:10:30
Zozo!
AZ EP logóhoz kilépő rutinod (ami az LD c,40h exos 0-val kezdődik) esetében mire kell állítani az SP-t, és az RST_ADDR-t?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.December.10. 22:02:38
Valahova a 0-ás lapra, annyi fontos, hogy maga a bejelentkező kép programja 200h-ra állítja majd a vermet. Ne ott legyen az újraindítás rutinunk :-)
Title: Re: Assembly programozás
Post by: Povi on 2013.December.11. 11:37:49
van egy darab nyitott video-csatornánk, és létrehozunk egy saját lpt-t

miután már nem használjuk saját lpt-t, vissza is adtuk az exos-nak a lefoglalt video-szegmensüket, hogyan tudom visszaállítani láthatóvá a még mindig nyitott video-csatornát? gondolom előtte el kellett volna menteni a video lap lpt címét? és azt kell megmondani a Nick-nek, ugye? na de hogyan?
Title: Re: Assembly programozás
Post by: geco on 2013.December.11. 13:29:31
Quote from: Povi
van egy darab nyitott video-csatornánk, és létrehozunk egy saját lpt-t

miután már nem használjuk saját lpt-t, vissza is adtuk az exos-nak a lefoglalt video-szegmensüket, hogyan tudom visszaállítani láthatóvá a még mindig nyitott video-csatornát? gondolom előtte el kellett volna menteni a video lap lpt címét? és azt kell megmondani a Nick-nek, ugye? na de hogyan?
a BFF4h címen (vagyis az FFh szegmens 3ff4h címén) lakozik az LPT címe 4000h-t hozzá kell adni, és ki kell számolni belőle 82-83h portoknak megfelelő értéket.
Title: Re: Assembly programozás
Post by: Povi on 2013.December.16. 21:47:42
Quote from: geco
a BFF4h címen (vagyis az FFh szegmens 3ff4h címén) lakozik az LPT címe 4000h-t hozzá kell adni, és ki kell számolni belőle 82-83h portoknak megfelelő értéket.
köszi, működik

a BIAS-t hogy állíthatom be?
van ugyebár a 80h port alsó öt bitje, de mire állítsam a b5-b6-ot?
ezt megszakításból fölülírja-e az EXOS (úgy mint a 81h-t)?
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.December.16. 21:53:51
Quote from: Povi
ezt megszakításból fölülírja-e az EXOS (úgy mint a 81h-t)?
Igen, tehát célszerű EXOS változóval állítani, hacsak nem valami demó trükk, de akkor ott úgy sincs EXOS megszakítás :-)

Itt az EXOS rutinja:
Code: ZiLOG Z80 Assembler
  1.         ;50Hz-es videó megszakítás esetén a változók értékének
  2.         ;megfelelően 80h, 81h, és B5h portokra új érték kiküldése.
  3.                
  4. LC516:  LD      HL,(0BFE0H)     ;L-be BORD_VID
  5.                                                         ;H-ba BIAS_VID
  6.                                                         ;változó értéke
  7.         LD      A,L                     ;BORD_VID értéke A-ba
  8.         OUT     (81H),A         ;BORDER - keretszín beállítása
  9.                
  10.         ;A következő részben használt jelölések:
  11.         ; M2           a MUTE_SND változó 2. bitje
  12.         ; B7,B6,...,B0 a BIAS_VID változó 7.,6.,...,0. bitje
  13.         ; S1,S0        a SPRITE változó 1.,0. bitje
  14.         ; X értéke közömbös
  15.        
  16.         LD      A,(0BFD3H)      ;MUTE_SND - belső hangszóró
  17.                             ;engedélyezésének állapota A-ba
  18.                             ;A= X X X X X M2 X X
  19.         XOR     H                       ;BIAS_VID felső 5 bitje A-ba
  20.         AND     07H                     ;00000111b maszk
  21.         XOR     H                       ;A=B7B6B5B4B3M2 X X
  22.                             ;!!!EXOS 2.0-ban nincs:
  23.         LD      HL,(0BFEBH)     ;!!!SPRITE - külső sprite
  24.                             ;!!!szín prioritása L-be
  25.         XOR     L                       ;!!!SPRITE alsó 2 bitje A-ba
  26.         AND     0FCH            ;!!!11111100b maszk
  27.         XOR     L                ;!!!A=B7B6B5B4B3M2S1S0
  28.         RRCA                            ;A=S0B7B6B5B4B3M2S1
  29.         RRCA                            ;A=S1S0B7B6B5B4B3M2
  30.         RRCA                            ;A=M2S1S0B7B6B5B4B3
  31.        
  32.     ;!!!EXOS 2.0-ban itt nullázza a külső szín prioritás bitjeit: 
  33.     ;!!!AND     9FH                     ;A=M20 0 B7B6B5B4B3            
  34.    
  35.         OUT     (80H),A         ;FIXBIAS új értékének kiküldése
  36.         LD      HL,(0BFD1H)     ;TAPE_SND értéke L-be
  37.         LD      BC,0BFF3H       ;PORTB5 változó címe
  38.         LD      A,(BC)          ;változó értéke A-ba
  39.         XOR     L                       ;TAPE_SND változó
  40.         AND     0DFH            ;értékétől függően
  41.         XOR     L                       ;az 5. bit beállítása
  42.         LD      (BC),A          ;új érték letárolása
  43.         OUT     (0B5H),A        ;új érték kiküldése
  44.         RET
  45.  
Akárhogy rakom be, szétdobja :evil:
Title: Re: Assembly programozás
Post by: Povi on 2013.December.16. 22:01:26
Quote from: Zozosoft
Igen, tehát célszerű EXOS változóval állítani, hacsak nem valami demó trükk, de akkor ott úgy sincs EXOS megszakítás :-)

ööö, tényleg, 28-as változó... kicsit szét vagyok esve ma :-)
Title: Re: Assembly programozás
Post by: Povi on 2013.December.17. 17:08:15
Zozo, a alap-példaprogramodban lévő LPT táblát hogy kell módosítani, hogy legyen még egy 36 pixelsor magas szöveges lapom, a grafikus rész alatt, hasonlóan a BASIC graphics parancsához? ha jól számolom, akkor az még pont belefér egy szegmensre, ugye?
Title: Re: Assembly programozás
Post by: Povi on 2013.December.20. 16:55:38
valahonnét (az újabb EXOS-ok esetében) ki lehet olvasni, hány MHz-es a gép? Ha nem, hogyan lehet megállapítani viszonylag egyszerűen?
Title: Re: Assembly programozás
Post by: IstvanV on 2013.December.20. 17:51:18
Quote from: Povi
valahonnét (az újabb EXOS-ok esetében) ki lehet olvasni, hány MHz-es a gép? Ha nem, hogyan lehet megállapítani viszonylag egyszerűen?

Ha nem fontos a nagy pontosság, akkor az 1 kHz-es megszakítások számából egy 50 Hz-es video megszakítás alatt, például így:

Code: ZiLOG Z80 Assembler
  1.         di
  2.         ld    b, 0
  3.         ld    a, 04h
  4.         out   (0bfh), a
  5.         ld    c, b
  6.         call  .l2
  7.         ld    l, b
  8.         call  .l2                       ; L = 1 kHz interrupts per video frame
  9.         ld    a, 25
  10.         cp    l
  11.         ld    a, 03h
  12.         rla
  13.         rla
  14.         out   (0bfh), a                 ; Z80 <= 5 MHz: 0Ch, > 5 MHz: 0Eh
  15.         ...
  16.         ret
  17. .l2:    in    a, (0b4h)
  18.         and   11h
  19.         or    c
  20.         rlca
  21.         and   66h
  22.         ld    c, a                      ; -ON--ON-
  23.         rlca                            ; ON--ON--
  24.         xor   c                         ; OXN-OXN-
  25.         bit   2, a
  26.         jr    z, .l3
  27.         inc   l                         ; 1 kHz interrupt
  28. .l3:    cp    0c0h
  29.         jr    c, .l2                    ; not 50 Hz interrupt ?
  30.         ret
Title: Re: Assembly programozás
Post by: IstvanV on 2013.December.20. 18:10:50
Quote from: Povi
LPT táblát hogy kell módosítani, hogy legyen még egy 36 pixelsor magas szöveges lapom, a grafikus rész alatt, hasonlóan a BASIC graphics parancsához?
A legegyszerűbb az EXOS státusz sor LPB-jét (BFF4h-ról olvasható a címe a 2. lapon) másolni, ez már tartalmazza a karakterkészlet kezdőcímét, és beállítani az LD1 címet, margókat (figyelve az ALTIND0/1 bitekre), és palettát. Természetesen az alsó és felső keretet is rövidíteni kell összesen 36 sorral.
Title: Re: Assembly programozás
Post by: szipucsu on 2013.December.20. 18:11:45
Quote from: Povi
valahonnét (az újabb EXOS-ok esetében) ki lehet olvasni, hány MHz-es a gép? Ha nem, hogyan lehet megállapítani viszonylag egyszerűen?
Valamelyik Spectrum Világ mellékletében volt egy példaprogram, ami kiírja az órajelet. A 12-16. számok között lehetett az egyikben.
Title: Re: Assembly programozás
Post by: Zozosoft on 2013.December.28. 16:31:46
Povi kérdésére az órajelmérés az EXOS 2.4-ből, gyakorlatilag azt számolja, hogy hány INC HL-es ciklus fut le egy videó megszakítás alatt.
38h-n egy JP (IX) utasítás van. A végére a BC-ben az órajel MHz-ben számolt értékének százszorosa van, így lesz kiírva két tizedes pontossággal.
A végén van egy összehasonlítás, a 191-es port kezdőértékéhez, 500 azaz 5Mhz alatt 12, felette 14 (azaz 4 vagy 6 Mhz-es beállítás).
A hívott matematikai rutinok a Hsoft féle MULDIV csomagból vannak.
Code: ZiLOG Z80 Assembler
  1.                 LD A,12
  2.                 OUT (191),A
  3.                 LD HL,0
  4.                 LD IX,IRQ1
  5.                 LD BC,30B4H
  6.                 OUT (C),B
  7.                 EI
  8.                 HALT
  9. IRQ1            LD IX,IRQ2
  10.                 OUT (C),B
  11.                 EI
  12. IRQW            INC HL
  13.                 JP IRQW
  14. IRQ2            DI
  15.                 LD IX,0BD50H
  16.  
  17.  
  18.                 LD BC,HL
  19.                 LD DE,1000
  20.                 CALL MUL_DE_BC
  21.                 LD BC,HL
  22.                 LD A,E
  23.                 LD DE,12485
  24.                 CALL DIV_ABC_DE
  25.                 OR A
  26.                 LD DE,6243
  27.                 SBC HL,DE
  28.                 JR C,NEMKEREKIT
  29.                 INC C
  30. NEMKEREKIT      LD (IX+11),C
  31.                 LD (IX+12),B   ;orajel erteke
  32.                 LD HL,BC
  33.                 PUSH HL
  34.                 LD DE,500
  35.                 SBC HL,DE
  36.                 LD A,12
  37.                 JR C,JO4MHZ
  38.                 LD A,14
  39. JO4MHZ          PUSH AF
  40.  
Title: Re: Assembly programozás
Post by: geco on 2014.February.02. 18:03:50
Van olyan z80 utasítás (nem dokumentált) amivel megtudhatjuk, hogy milyen megszakítási mód van beállítva?
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.February.02. 18:28:01
Quote from: geco
Van olyan z80 utasítás (nem dokumentált) amivel megtudhatjuk, hogy milyen megszakítási mód van beállítva?
Nincs. Az emuba azt csináltam, hogy az I alapból a ROM-ba mutat értelmetlen helyre (tehát nem az FF-ekre), és ha megváltozik, akkor azt IM2-re áttérésnek veszi. Nem tökéletes módszer, de nagy rakás játék működövé vált így.
Title: Re: Assembly programozás
Post by: geco on 2014.February.02. 18:58:39
Quote from: Zozosoft
Nincs. Az emuba azt csináltam, hogy az I alapból a ROM-ba mutat értelmetlen helyre (tehát nem az FF-ekre), és ha megváltozik, akkor azt IM2-re áttérésnek veszi. Nem tökéletes módszer, de nagy rakás játék működövé vált így.
A TAP-ok betöltése miatt kérdeztem, mert van olyan program, ami beállítja az IM2-t, és elkezd tölteni, na nálam ez egy hatalmas fagyi lett :lol: , most le van tiltva az összes megszakítás a TAP egy-egy részének töltése végéig, ezt akartam valahogy elkerülni.
Az 0500h-0600h-ig tartó címre, és az emu állítja is az IM2-t, vagy hagyod a programokra ezt a feladatot? Fél órája néztem pár percet az emut, láttam, hogy az előbb említett tartományban van egy ugrótábla, de van benne kód is, hogy oldottad meg, hogy a kódba ne ugorjon véletlenül? A port hívások is NMI-ből mennek nem? Az NMI-ből a portkezelő, és attributum konvertáló rutinra való ugrás egy plusz JP-n keresztül történik, annak is van valami funkciója?
Én azt csináltam, hogy az LD I,A-kat cseréltem le, és az ugrótáblát minden esetben 3bh-val töltöm fel, és a 3b3bh-n lévő im2-es megszakításrutin végére teszem az ugrótábla eredeti értékét, ha az nem 0ffh, mert ha az, akkor vagy 0fff4h , vagy 0aff3h kerül a végére, ha I értéke 0ffh, vagy kisebb, mint 3fh, akkor a 3e00h-3f00h-ra kerül a tábla, ezért veszti el pár játék a karakterkészletét, ilyen a Heartland is.
Vannak a trükkös programok, amik váltogatják az ugrótáblákat, de nem generálnak semmit, arra az esetre tároltam el az ugrótáblákhoz használt előző értékeket, ezzel megjavult a Wec Le Mans (az SNA verzióm sajnos egyből a megszakításban kezd, ezért oda ugrik , ahová nem kéne, de műxik, csak az elején van egy kis érdekesség), és az Operation Wolf.
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.February.03. 11:09:59
A snapshot mentésnél van egy ilyen lekérdezés az emu-ban:
Code: ZiLOG Z80 Assembler
  1. IMKERD          LD A,30H
  2.                 OUT (0B4H),A
  3.                 LD A,3DH
  4.                 LD I,A
  5.                 XOR A
  6.                 EI
  7.                 HALT
  8.                 DI
  9.                 IM 1
  10.                 PUSH AF
  11.                 LD A,3FH
  12.                 LD I,A
  13.                 POP AF
  14.                 RET
Itt már a 0-ás lap van belapozva, az azon futó IM2 rutinban egy INC A van.
Title: Re: Assembly programozás
Post by: geco on 2014.February.03. 11:33:36
Quote from: Zozosoft
A snapshot mentésnél van egy ilyen lekérdezés az emu-ban:
Code: [Select]
IMKERD          LD A,30H
                OUT (0B4H),A
                LD A,3DH
                LD I,A
                XOR A
                EI
                HALT
                DI
                IM 1
                PUSH AF
                LD A,3FH
                LD I,A
                POP AF
                RET
Itt már a 0-ás lap van belapozva, az azon futó IM2 rutinban egy INC A van.
Na erre nem gondoltam, hogy a 0-ás lapra is csináljak egy saját IM 2 rutint :), ez sokkal jobb, mint amit én csináltam ideiglenesen, a speccy ROM-ban elhelyezett IM 2-mben állítottam :lol:
Title: Re: Assembly programozás
Post by: Povi on 2014.April.08. 08:43:04
Készült-e arról valaha vizsgálat, hogy egy átlagos Z80 program esetében mennyi az egy utasításra jutó átlagos ciklusidő? (ugye érthető? :-) ). Mert hát ugye egy utasítás lehet 4 ciklus is, de akár 23 is. Na de mennyi a sebessége valós körülmények között? Hány MIPS? (Jó tudom, jó közelítéssel 1 MIPS egy 4MH-es Z80, de vajon tényleg annyi? - hiszen ekkor feltételezzük, hogy minden utasítás csak 4 ciklus)
Title: Re: Assembly programozás
Post by: Pgyuri on 2014.April.08. 16:25:41
Üdv,

Ha definiálod az "átlagos Z80 program"-ot, akkor megválaszolom. Kérdésed szerintem nem megfelelő, hiszen programozási technikától függ ki milyen módon építi fel programját.

Utasítások hossza 4T és 23T tartományban van. 486 különböző utasítás van, átlag T értékük ~10,4.

Ha a programod minden utasításból egyet tartalmaz, akkor ez az átlag. Normális programozási elv mentén szerintem kb. 8 körül mozoghat az érték, míg IX és egyéb hosszú utasítások alkalmazásánál 12-14 körül lehet.

De mint említettem, kellene tudni az általad átlagosnak titulált program specifikációját, mert ha csak 8 bites műveleteket kell végezni, akkor gyors utasításokkal lehet dolgozni, de ha rengeteg nagy táblázatra gondolsz és átláthatóbb program a cél, akkor lassú utasítások tolonghatnak. Nézzek meg egy játékot esetleg ?  De akkor melyiket ?

Hiába, nincs klub :)  pedig ott jókat töprenghettünk...

Pgyuri
Title: Re: Assembly programozás
Post by: geco on 2014.April.08. 16:41:29
Hát legyen egy klub :D
Title: Re: Assembly programozás
Post by: Povi on 2014.April.08. 16:43:58
Quote from: Pgyuri
Normális programozási elv mentén szerintem kb. 8 körül mozoghat az érték, míg IX és egyéb hosszú utasítások alkalmazásánál 12-14 körül lehet.

Na, hát pont én is erre lennék kíváncsi... :-)
Vajon az emulátorban van erre mód? Mint ahogy a futási idő kijelzése is lehetséges, jó lenne, ha meg lehetne nézni, hogy a két töréspont között hány darab utasítás futott le, menni T idővel. :-)

Persze közben kicsit továbbgondoltam és bonyolítottam a dolgokat a fejemben. Mert mi van akkor, ha a programom csak 16 bites regiszter értékadásból áll? Akkor az átlagos T időm 10 lesz. Ha ugyanezt a programot 8 bites regiszterekkel írom meg, akkor az átlagos T időm 7 lesz, azt mondhatnánk, hogy így mégis csak több utasítást hajt végre a proci egy adott időegység alatt, mégis 40%-kal több ideig fog futni ugyanaz a program. Vagy ebben az esetben pl. az LD BC,1234 utasítást 2 db utasításnak kéne venni, hogy javítsa a MIPS eredményt? Szóval, nem egyszerű :-)
Title: Re: Assembly programozás
Post by: lgb on 2014.April.09. 10:50:51
Lehetne igy trukkozni, de eleve nem az a lenyeg, hogy "javitsd a statisztikat" (MIPS-et), hanem hogy tenylegesen milyen gyors a programod ugyanazon a hw-n, azaz a ha a feladat pl az hogy a B regiszter erteke legyen 12h, a C meg 34h, akkor az lehet ket LD utasitas, illetve lehet egyetlen, 1234h-val. Az szerintem csak max reklamfaktor, hogy a MIPS az "million instruction per second", attol, hogy tobb utasitast hajtasz vegre 1 masodperc alatt egy masik megoldashoz kepest, nem biztos, hogy az lesz a gyorsabb, mert egyes utasitasok vegrehajtasi ideje nem ugyanaz. A MIPS dolognak tobb ertelme van imho egy RISC CPU-nal ahol nincs olyan nagy szoras az utasitasok vegrehajtasi idejeben, pl lehet tipikus, hogy legtobb utasitas egy orajelciklus, es kesz. Ott akkor tobb ertelme van tenyleg ennek a MIPS dolognak. Ami szerintem viszont fontos, az az, hogy nem ezt kell nezni, hanem azt, hogy adott feladatot minnel rovidebb futasidovel realizald, a MIPS ertektol fuggetlenul, ami egy CISC processornal amugy is nehezebben ertelmezheto fogalom.
Title: Re: Assembly programozás
Post by: Povi on 2014.April.11. 08:55:25
Quote from: lgb
Az szerintem csak max reklamfaktor, hogy a MIPS az "million instruction per second", attol, hogy tobb utasitast hajtasz vegre 1 masodperc alatt egy masik megoldashoz kepest, nem biztos, hogy az lesz a gyorsabb, mert egyes utasitasok vegrehajtasi ideje nem ugyanaz.
És tényleg, most olvasom, hogy tréfásan "Meaningless Information on Performance for Salespeople" (értelmetlen teljesítményinformáció kereskedőknek) is értelmezik a rövidítést... :-)
Title: Re: Assembly programozás
Post by: Povi on 2014.April.11. 09:04:43
Más téma, ami eszembe jutott:
Van-e értelme annak a kifejezésnek, hogy "jól megizzasztom a procit"? Pl. Mandelbrot-halmaz számítással, vagy Small Demo futtatásával... :-)
Hiszen ha épp "nem csinál semmit se" a Z80, akkor is valamilyen ciklusban kell hogy legyen, pl. vár egy billentyűlenyomásra. Vagyis ugyanúgy olvassa be a következő utasítást, és hajtja végre, mintha épp a következő Mersenne-prímet keresné. Egyedül a HALT-tal lehetne megállítani a procit, ha jól gondolom (az első megszakításig), de egyébként mitől "izzadna" jobban, mint ha csak bill. nyomásra várna?
Mert ugyebár laptopoknál pl. lenne értelme erről beszélni, ott alacsonyabb órajelre teszi a rendszer a procit, ha nincs számításigényes feladat, de ugye ez a Z80-nál nem érvényes. Vagy mégis?
Title: Re: Assembly programozás
Post by: szipucsu on 2014.April.11. 14:08:56
Quote from: Povi
"jól megizzasztom a procit"?
Pl. arra kényszerítjük, hogy ha döcögve is és nagyon akadozva, de játsszon le DTM zenét, miközben Iview formátumú videót játszik le, nem?
Title: Re: Assembly programozás
Post by: lgb on 2014.April.11. 20:18:46
Quote from: Povi
Más téma, ami eszembe jutott:
Van-e értelme annak a kifejezésnek, hogy "jól megizzasztom a procit"? Pl. Mandelbrot-halmaz számítással, vagy Small Demo futtatásával... :-)

Szerintem ez inkabb nyelvi fordulat jelen esetben. Modern CPU/operacios rendszereknel tobb ertelme van, ott az OS altalaban az idle task-ot hajtja vegre, vagy hasonlo, ami az altalad is emlitett HALT vagy hasonlo trukkot alkalmazva "altatja" a procit, igy a fogyasztas is csokken, stb. Ennek pl notebook eseten komoly ertelmes jelentese is van, lasd akkurol valo max uzemido. Egy "regebbi" proci eseten (mint pl a Z80) ez azert tenyleg nem egyertelmu. Ott is igaz, hogy azert pl a proci fogyasztasa es atlaghomerseklete (ha mar az "izzasztas" a tema ...) fugg attol is, hogy milyen jellegu utasitasikat hasznal a CPU, azaz pl kb egyenletesen a teljes lapka dolgozik, vagy inkabb csak egy specifikus resze, stb. Ezert itt is lehetsegss (bar imho a kulonbseg kevesbe szignifikans), hogy egy igen jol kioptimalizalt "surru" kod esetleg jobban megdolgoztatja kis CPU-nkat.
Title: Re: Assembly programozás
Post by: Ferro73 on 2014.August.27. 21:38:12
Egy pár rejtet és ismeretlen z80 utasitást nem találok pedig létezik az utasítás neve nem találam sehol az utasítás kódjára nem emlékszem de tudom, hogy van.
Az utasítás hasonló az   SRA   utasításhoz ami 0 -> b7.....b0 -> CY
 csinálja de ez az utasítás                              1 -> b7.....b0 -> CY
Még igazi EP128-on kerestem meg igaz nem használtam soha.
Akkor úgy gondoltam ha 0-t tölthetünk be akkor 1-t is lehet.
Title: Re: Assembly programozás
Post by: Povi on 2014.August.28. 08:51:05
Itt van egy lista a nem dokumentált utasításokról:
http://www.z80.info/z80undoc.htm

Persze lehet, hogy létezik ennél jobb lista is, bővebb magyarázatokkal, de hirtelen ezt találtam.
Viszont mostanában éppen hogy próbáljuk kiirtani a nem dokumentált utasításokat a progikból, hogy Zozo Z180-as EP-projectjén is gond nélkül fussanak a dolgok.
Title: Re: Assembly programozás
Post by: Ferro73 on 2014.August.28. 21:37:25
Nem azért csak eszembe jutott miközben PIC-re alakítom a Z80-as uatsításokat.
Amugy az ASMEN-ben sem jelennek meg pedig a változások észlelheöek.
Bele építhették volna anno és inverz kiírással LIST-ázhatták volna.
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.August.28. 21:47:00
Quote from: Ferro73
Bele építhették volna anno és inverz kiírással LIST-ázhatták volna.
Mivel nem voltak dokumentálva, honnan tudhatták volna? :oops:
Bele telt pár évebe mire felfedezték az emberek.
A FENAS az már ismeri a felezett index regiszteres kupacot.
Haluskának meg én súgtam, így a HEASS az már az összeset tudja fordítani.
Title: Re: Assembly programozás
Post by: Ferro73 on 2014.August.28. 22:09:49
Na igen mert a többségük Basic , Pascal, Lisp, Forth-ban probálgattak.
Igaz én is csak akkor találtam rá mikor kiváncsi lettem mit csinál a proci ismeretlen kodoknál.
Lehet nem voltak olyan kiváncsiak vagy jó volt a szemellenzőjük.
Így talán több is lehettet min 158 utasítás bár lehet a 158 utasítás a Z80-ra vonatkozik nem pedig az utána érkezettekre  A,B,C,H.
Title: Re: Assembly programozás
Post by: Povi on 2014.September.08. 22:45:11
erre van valami elegánsabb megoldás?
Code: ZiLOG Z80 Assembler
  1.     add a,65
  2.     bit 7,a
  3.     call nz,xxxx
  4.  

rémlik, mintha a P státusz bit nézegetésével is lehet valamit trükközni...
Title: Re: Assembly programozás
Post by: geco on 2014.September.08. 22:53:58
Code: ZiLOG Z80 Assembler
  1.     add a,65
  2.     call pe,xxxx
Title: Re: Assembly programozás
Post by: Povi on 2014.September.08. 23:01:03
köszi
Title: Re: Assembly programozás
Post by: IstvanV on 2014.September.09. 10:49:21
Pontosabban: CALL M, xxxx
Title: Re: Assembly programozás
Post by: geco on 2014.September.09. 11:05:51
Quote from: IstvanV
Pontosabban: CALL M, xxxx
Mi a különbség a kettő között, mármint működésügyileg?
Emun teszteltem PE-vel működött, igaz a 00h-s, és a 80h-s összeggel nem teszteltem.
Title: Re: Assembly programozás
Post by: IstvanV on 2014.September.09. 11:48:13
Quote from: geco
Mi a különbség a kettő között, mármint működésügyileg?
Emun teszteltem PE-vel működött, igaz a 00h-s, és a 80h-s összeggel nem teszteltem.
A CALL M feltétele akkor teljesül, ha az eredmény negatív (a 7. bit 1), ami azonos az eredeti BIT 7, A-t használó kóddal.

A CALL PE viszont előjeles túlcsordulást tesztel, és a feltétel akkor teljesül, ha eredetileg pozitív A után negatív az eredmény. Akkor azonban nem, ha már az összeadás előtt is negatív az A. De ha valójában a túlcsordulás, és nem a negatív eredmény tesztelése a cél, akkor ez a jó megoldás.
Title: Re: Assembly programozás
Post by: geco on 2014.September.09. 12:04:30
köszi szépen, ez így már teljesen világos, eddig nem találkoztam részletes leírással.
Title: Re: Assembly programozás
Post by: Povi on 2014.September.09. 12:05:58
köszi, javítottam

igazából ezek a PE, P, M bitek, amit még soha életemben nem használtam, sohasem volt igazán tiszta a használatuk.
Title: Re: Assembly programozás
Post by: Z80System on 2014.September.26. 18:53:17
HEASS -ba akatam beolvasni a pck.hea file -t (hogy ránézzek, hogy van -e esélye, hogy csináljak belőle olyat, amiben van gyorsteszt,

akár a pack funkciók ki is kerülhetnének belőle, nekem csak a FILE funkció kéne + gyorsteszt, mert a super WP az SD -ben nekem nem nagy adomány, szívesebben látnék az SD -ben helytte inkább FILE -t,

ezért az 1.0 -ás HEASS.ext -et használva (melynél valami gáz van a magyar karakterekkel is, alig olvasható a menüje) bele akartam tölteni a pck.hea -t,

aminek az az eredménye, hogy beolvassa a file -t, ki is jelzi hogy valami harmincezer vagy mennyi soros, és lehet a file -ban mászkálni is,

de nem látszanak a karakterek, tök fekete a forrás ablak ... :)
Title: Re: Assembly programozás
Post by: Povi on 2014.September.26. 18:58:21
van memóriabővítésed? mert ha jól emlékszem, akkor szokott ilyet csinálni, ha 128kB-os alapgépen indítod (nem ROM-ból, hanem RAM-ból).
Title: Re: Assembly programozás
Post by: Z80System on 2014.September.26. 19:00:02
Nincs, sima 128k gépen tolom, heass.ext -tel. De hát mi baja lenne, elfoglal egy szegmenst a heass.ext, többibe meg csak befér a pck.hea, nem ?
Title: Re: Assembly programozás
Post by: Povi on 2014.September.26. 19:02:08
szerintem kettőt foglal le alapból az ext, aztán ki tudja még mennyit, amikor elindul - egy videoszegmenst biztosan
Title: Re: Assembly programozás
Post by: Z80System on 2014.September.26. 19:19:53
Hmmm ... hát pedig valami ilyen lesz ...

Szégyen szemre elő kellett vegyem a ronda tepszi EXDOS -t ...

De az EXDOS kártyán lévő rom HEASS persze betölti ... persze az EXDOS kártyán van 512k ram is ...

Na mindegy, legalább kipróbáltam az SD kártya EXDOS kártya együttműködést is ...

Nem olyan rossz az együttműködés, RAM műkszik, SD műkszik, ROM -ok működnek, csak valahogy az EXDOS (és valszeg a BASIC) esetében az EXDOS kártyán lévő üti a cartridge -ban lévőt, mindkettőből csak egy láncolódik be (nem lesz 2 BASIC vagy 2 EXDOS, pedig a tölthető ext -es dolgokból általában több lesz, ha többször töltesz), és pld. abból, hogy a default EXDOS meghajtó az A: lesz nem pedig az F:, ebből gondolom hogy az EXDOS kártyán lévő EXDOS ROM érvényesül, nem a cartridge -os.

De ha átváltok valami SD meghajtóra, akkor megy a dolog ...
Title: Re: Assembly programozás
Post by: Povi on 2014.October.06. 11:12:25
amatőr kérdés, tudom, de nem találom sehol, hogy az SP regiszter értékét ki tudom-e nyerni valahogy?
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.October.06. 11:17:30
Quote from: Povi
amatőr kérdés, tudom, de nem találom sehol, hogy az SP regiszter értékét ki tudom-e nyerni valahogy?
LD (nnnn),SP :-)
Title: Re: Assembly programozás
Post by: Povi on 2014.October.06. 12:04:02
köszi
az LD SP,HL utasitás előtt kell DI, vagy nem?
Title: Re: Assembly programozás
Post by: geco on 2014.October.06. 13:11:15
Quote from: Povi
köszi
az LD SP,HL utasitás előtt kell DI, vagy nem?
Ha nem akarod, hogy a megszakítás bepiszkítson a verem területedre, akkor nem árt, ha biztos vagy benne, hogy nem lesz megszakítás ott, akkor nem kell.
Title: Re: Assembly programozás
Post by: Povi on 2014.October.06. 13:14:38
na igen, ezt értem, csak azt nem értem, hogy tudna belepiszkítani?
mert ugye csak az 50Hz-es int (a 038 címről) futása rondíthatna bele, de akkor se értem, hogyan.
hiszen vagy az utasítás előtt futna le az int rutin, vagy utána, de mindenképpen helyreállítaná az SP-t a hivás előtti értékre

vagy valamit rosszul látok?
Title: Re: Assembly programozás
Post by: geco on 2014.October.06. 16:01:53
Az SP-t helyreállítja, de ha lefut egy megszakítás miközben más veremmutatód van, akkor a megszakítás összes verembe töltése erre az új veremterületre kerül, felülírva a már ott lévő adatokat, igaz a veremmutató visszaáll a megszakítás előtti címre, csak a tartalma változik meg, ez lehet a belepiszkítás, ami akkor okoz problémát, ha ugyanazt a területet olvasásra használod, újbóli feltöltés nélkül.
Title: Re: Assembly programozás
Post by: geco on 2014.October.06. 16:05:58
meg akkor, ha az új veremterületed alján fontos adatod, vagy épp kód van, és a megszakítás az új verembeírás végén, vagy veremolvasás elején jön, így a megszakítás felülírhatja az adatot/kódot.
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.October.07. 10:08:21
Kapitány úr figyelmébe, a HSOFT rutinok.
Title: Re: Assembly programozás
Post by: Kapitany on 2014.October.07. 11:00:00
Szuper, köszönöm! A múltkor már megtaláltam egyszer, igen hasznos... jó móka átbogarászni egy tábla mellett mondjuk, hogy hogyan is kerül kiírásra az a szám, meg át BCD-be.. :)
Title: Re: Assembly programozás
Post by: Povi on 2014.October.07. 22:15:34
van ez a Zozó féle kilépő rutin:
Code: [Select]
kilepes:    DI
            LD      SP,100H
            LD      C,40H
            EXOS    0
            INC     A
            OUT     (0B3H),A
            LD      A,6
            JP      0C00DH
miért nem működik normálisan? ugyan az EP logóhoz jutok, de onnantól szép fagyásokat produkál

van két foglalt szegmensem, az bezavarhat? vissza kell adni az EXOS-nak?
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.October.07. 22:21:38
Ha 60H teszel a EXOS 0-ba, akkor a szegmenseket is felszabadítja. (most nézem a 40H is)

EXOS megszakításba meg ilyenekbe nem túrtál bele?
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.October.07. 22:27:48
És nálam van benne:
                LD A,255
                OUT (0B2H),A
is :-)
Title: Re: Assembly programozás
Post by: Povi on 2014.October.07. 22:34:31
Quote from: Zozosoft
És nálam van benne:
                LD A,255
                OUT (0B2H),A
is :-)
ez hiányzott... :oops:

így már működik!!! :-)
Title: Re: Assembly programozás
Post by: Z80System on 2014.November.17. 21:10:39
Töltött asmon.ext -tel nyomulnék,

és azt tapasztalom 128K gépen, hogy nincs üres szegmens az asmon 1.3 szerint egyáltalan,

az asmon 1.5 szerint meg 1 üres szegmens van ...

És ez fura, mert a basic ugye alig foglal le memóriát ... mire foglal le az asmon az 1-2 szegmensén kívül ?

Nem egyszerű dolog egy asmon -ba Zozo féle gyorstesztet rakni ?

Van olyan asmon.rom amiben egyáltalán nincs semmilyen gyorsteszt, és ezért nem bírálja felül az esetleges (már csippelt) exos rom -ban lévőt ?
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.November.17. 21:30:09
és azt tapasztalom 128K gépen, hogy nincs üres szegmens az asmon 1.3 szerint egyáltalan,

az asmon 1.5 szerint meg 1 üres szegmens van ...
Nem fordítva?

Quote
És ez fura, mert a basic ugye alig foglal le memóriát ... mire foglal le az asmon az 1-2 szegmensén kívül ?
Nullás lap, rendszerszegmens, két szegmens a az Asmon-nak mint rendszerbővítő, 2-t belapoz, ez eddig 6... És akkor még videó lap, stb
Az 1.5-ös van Text 80-ban, abban kéne a kevesebb ramnak lenni.

Quote
Nem egyszerű dolog egy asmon -ba Zozo féle gyorstesztet rakni ?
Nem.

Quote
Van olyan asmon.rom amiben egyáltalán nincs semmilyen gyorsteszt, és ezért nem bírálja felül az esetleges (már csippelt) exos rom -ban lévőt ?
EXOS 2.2-től kezdve nem fut automatikusan a TEST_ROM, csak ha T-t nyomsz.
Title: Re: Assembly programozás
Post by: Z80System on 2014.November.17. 21:44:15
Quote
Nem fordítva?

Érdekes módon nem ... ellenőriztem mégegyszer,

1.3
0 free segment(s)

1.5

1 free segment(s)
Title: Re: Assembly programozás
Post by: endi on 2014.November.18. 00:04:33
Amúgy ki mit használt asm editornak, fordítónak?
Én hamar átszoktam a Fenass-ra, ami brutálisan gyors editor és fordító volt a többihez képest. :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.November.18. 00:19:44
Én hamar átszoktam a Fenass-ra, ami brutálisan gyors editor és fordító volt a többihez képest. :)
A HEASS meg még brutálisabb, ráadásul az összes RAM-ot tudja használni, nem kell INCLUDE fájlokkal szórakozni :-)
Pl a Zozotools 126K .HEA formában, 247K normál TXT-ben.
Title: Re: Assembly programozás
Post by: endi on 2014.November.18. 00:35:19
A HEASS meg még brutálisabb, ráadásul az összes RAM-ot tudja használni, nem kell INCLUDE fájlokkal szórakozni :-)
Pl a Zozotools 126K .HEA formában, 247K normál TXT-ben.

tök jó, átfutottam most mindkettő leírását az ep128-on
de asszem a heass-t én nem ismertem, legalábbis a képekről nem ugrik be
Title: Re: Assembly programozás
Post by: Kapitany on 2014.November.18. 08:13:37
Nekem FENASS sokszor fagyott, ami elég idegesítő volt. A HEASS-ben meg nincsen monitor. :( Maradt a TASMON.
Title: Re: Assembly programozás
Post by: Povi on 2014.November.18. 08:53:21
Én a héten szoktam át erre:
http://www.nongnu.org/z80asm/
Igaz, ez nem EP program, de nagyon tetszik.
EP-n felváltva használtam HEASS-t és ASMON-t. A HEASS nagy hiányossága, hogy nincs benne monitor. Valahogy kombinálni kéne az ASMON-t a HEASS-szal :-)
A HEASS sajnos emulátoron nem hajlandó együtt működni a :FILE eszközzel (nem lehet onnét bináris fájlokat include-olni.
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.November.18. 09:01:34
A HEASS nagy hiányossága, hogy nincs benne monitor. Valahogy kombinálni kéne az ASMON-t a HEASS-szal :-)
Fordítod binárisnak, és betöltöd ASMON-ba :-)

Quote
A HEASS sajnos emulátoron nem hajlandó együtt működni a :FILE eszközzel (nem lehet onnét bináris fájlokat include-olni.
Ez a FILE: eszköz hibája, mert nem fájlkezelő eszköz :-(
Alternatíva: kell egy BAT fájl ami INCLUDE-okat berakja RAMDISK-be, és onnan tölteni ezeket.
Title: Re: Assembly programozás
Post by: Zozosoft on 2014.November.18. 09:38:55
Én a héten szoktam át erre:
http://www.nongnu.org/z80asm/
Igaz, ez nem EP program, de nagyon tetszik.
Ez miben jobb mint az sjasm?
Title: Re: Assembly programozás
Post by: Povi on 2014.November.18. 09:47:40
Ez miben jobb mint az sjasm?
Nem tudom, azt nem ismerem. Lehet, hogy az sjasm jobb.
Title: Re: Assembly programozás
Post by: geco on 2015.January.01. 14:09:22
Érdemes ezt folytatni?
Négy megás gép javasolt az elindításához.
Majd később elmondom a paramétereket.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.01. 14:24:58
Igen. Mi lesz ebből? :-)
Title: Re: Assembly programozás
Post by: geco on 2015.January.01. 14:38:41
Igen. Mi lesz ebből? :-)
Egy 8 bites wav lejátszóra gondoltam, tudom ott az SNDPLAY, de úgy emléxem az 7 bites.
Most ez fix 16 KHz-en játsza le a RAW file-t  arra gondoltam, hogy WAV player lesz belőle, ami 1-25Khz közötti 8 bites WAV lejátszására lesz alkalmas. Ezen a frekvencián 4 megába kb 5 perc adat fér.
Title: Re: Assembly programozás
Post by: endi on 2015.January.01. 14:42:38
betöltöttem a hangot goldwave-be és tényleg 8 bites
de ezt 8 bitesként is játszod le EP-n, valami trükkel? több csatorna együtt? nagyon jó minőségű (jó, persze pc-n a 8 bites lejátszás is minőségjavított)

de amúgy szerintem valami tömörítéssel is lehetne próbálkozni, amit realtime le lehet játszani. pl asszem van olyan ami nem az abszolút, hanem relatív amplitudót tárolja és kevesebb biten. ilyesmit szerintem az EP is le tudna realtime
Title: Re: Assembly programozás
Post by: geco on 2015.January.01. 15:10:41
betöltöttem a hangot goldwave-be és tényleg 8 bites
de ezt 8 bitesként is játszod le EP-n, valami trükkel? több csatorna együtt? nagyon jó minőségű (jó, persze pc-n a 8 bites lejátszás is minőségjavított)

de amúgy szerintem valami tömörítéssel is lehetne próbálkozni, amit realtime le lehet játszani. pl asszem van olyan ami nem az abszolút, hanem relatív amplitudót tárolja és kevesebb biten. ilyesmit szerintem az EP is le tudna realtime
Tudom, én konvertáltam mp3-ból ;)
Igen, 4 csatornán, talán lehetne 8 bites sztereó is, de akkor nem megszakításból menne a lejátszás, és az méretnövekedéssel is járna.
Jó lenne valami tömörítés, és az az eltolásos dolog lehet hatékonyabb is lenne, mint más, zip-et néztem, nagyon minimálisan tömörített, 16KHz-en talán még menne is a kitömörítése on the fly, bár nem ismerem az eljárást.
Title: Re: Assembly programozás
Post by: endi on 2015.January.01. 15:19:33
de hogy tolod ki 4 csatira a 8 bitet? arra gondolok hogy ez ügye több out utasítás, és nem egyszerre történik ügyebár. ez nem okoz gondot? így hallásra persze nem
Title: Re: Assembly programozás
Post by: geco on 2015.January.01. 15:37:07
de hogy tolod ki 4 csatira a 8 bitet? arra gondolok hogy ez ügye több out utasítás, és nem egyszerre történik ügyebár. ez nem okoz gondot? így hallásra persze nem
77 órajelciklus alatt történik meg a 4 out utasítás.
így:
Code: [Select]
        ld     c,(hl)               ;sample érték
        inc   hl
        ld     b,high regval0
        ld     a,(bc)
        out   (0a9h),a
        inc   b
        ld     a,(bc)
        out   (0aah),a
        inc   b
        ld     a,(bc)
        out   (0adh),a
        inc   b
        ld     a,(bc)
        out   (0aeh),a
Title: Re: Assembly programozás
Post by: endi on 2015.January.01. 15:50:22
hát ezt nem teljesen értem
mi az a high regval és mi van a (bc)-n?
Title: Re: Assembly programozás
Post by: geco on 2015.January.01. 16:04:53
hát ezt nem teljesen értem
mi az a high regval és mi van a (bc)-n?
Minden regiszternek megvan a maga 256-os (0-3fh értékkel feltöltve, az egyes táblázatok el vannak tolva egymástól 1-gyel) táblázata egymás után tárolva, és a sample 0-ffh értékének megfelően onnan veszi ki a megfelelő értéket, ami a portra kerül.

Hivatalosan így nézne ki a dolog:


Sample érték:  01 03 08 15 81
port1                 01 01 02 04 21
port2                00 01 02 04 20
port3                00 01 02 04 20
port4                00 00 02 03 20
valójában kicsit eltér 00-03h sample értékig 00h kerül a portokra, és csak onnantól kezdenek el nőni az értékek.
Title: Re: Assembly programozás
Post by: endi on 2015.January.01. 16:07:35
aha tök jó
bedigizve megnézem a hullámformát :) lehet hogy látszana az a pár órajel eltérés
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.02. 15:35:50
Jó lenne valami tömörítés, és az az eltolásos dolog lehet hatékonyabb is lenne, mint más, zip-et néztem, nagyon minimálisan tömörített, 16KHz-en talán még menne is a kitömörítése on the fly, bár nem ismerem az eljárást.

A zip (deflate) tömörítése hasonló az epcompress -m0 algoritmushoz, és EP-n hang lejátszáshoz valószínűleg túl lassú lenne.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.02. 15:46:46
de amúgy szerintem valami tömörítéssel is lehetne próbálkozni, amit realtime le lehet játszani. pl asszem van olyan ami nem az abszolút, hanem relatív amplitudót tárolja és kevesebb biten. ilyesmit szerintem az EP is le tudna realtime

Az epsndconv/sndplay ilyen megoldást használ, egy tömörített hangminta 2, 3, vagy 4 bites lehet, és az előző tömörítetlen 7 bites hangmintához képesti különbséget tárolja 256 lehetséges kódolás valamelyikével. Ezeket a konvertáláskor választható méretű blokkok előtti 1 byte választja, tehát például a 3 bites formátum 16 blokk mérettel gyakorlatilag átlagosan 3.5 bites. A kódoláshoz az epsndconv generálja a 256 táblázatot (elvileg az adott file-ra optimalizálva), és ezeket tömörítve tárolja a fejlécben.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.02. 15:58:50
Egy 8 bites wav lejátszóra gondoltam, tudom ott az SNDPLAY, de úgy emléxem az 7 bites.

Az sndplay csak 7 bites, mert nem használ mono lejátszáshoz két csatornát (illetve mindkét oldalon pontosan ugyanaz a kimenet), és a gyakorlatban elsősorban a kezdetleges veszteséges tömörítés, az alacsony mintavételezési frekvencia, és az EP rossz minőségű analóg kimenete korlátozza a minőséget. Az IRQ rutin így néz ki egy és két csatornás lejátszáshoz:

Code: ZiLOG Z80 Assembler
  1. irqCodeBegin:
  2.         phase 00038h
  3.  
  4. irqRoutine:
  5.         ex    af, af'
  6.         ld    a, (iy)
  7.         rrca
  8.         out   (0a8h), a
  9.   if LEFT_CHANNEL_ONLY == 0
  10.         out   (0ach), a
  11.   endif
  12.         adc   a, 0
  13.         out   (0abh), a
  14.   if LEFT_CHANNEL_ONLY == 0
  15.         out   (0afh), a
  16.   endif
  17.         ld    a, 003h
  18.         inc   iyl
  19.         jr    z, .l1
  20.         out   (0b4h), a
  21.         ex    af, af'
  22.         ei
  23.         ret
  24. .l1:    inc   iyh
  25.         out   (0b4h), a
  26.         and   iyh
  27.         or    high audioBuffer
  28.         ld    iyh, a
  29.         ex    af, af'
  30.         ei
  31.         ret
  32.  
  33.         dephase
  34. irqCodeEnd:
  35.  
  36. irqCode2Begin:
  37.         phase 00038h
  38.  
  39.         ex    af, af'
  40.         ld    a, (iy - 128)
  41.         rrca
  42.         out   (0a8h), a
  43.         adc   a, 0
  44.         out   (0abh), a
  45.         ld    a, (iy)
  46.         rrca
  47.         out   (0ach), a
  48.         adc   a, 0
  49.         out   (0afh), a
  50.         ld    a, 003h
  51.         inc   iyl
  52.         jr    z, .l1
  53.         out   (0b4h), a
  54.         ex    af, af'
  55.         ei
  56.         ret
  57. .l1:    ld    iyl, 080h
  58.         inc   iyh
  59.         out   (0b4h), a
  60.         and   iyh
  61.         or    high audioBuffer
  62.         ld    iyh, a
  63.         ex    af, af'
  64.         ei
  65.         ret
  66.  
  67.         dephase
  68. irqCode2End:

Az IY egy 1024 byte-os pufferre mutat, ahova a főprogram a dekódolt hangmintákat írja.
Title: Re: Assembly programozás
Post by: endi on 2015.January.02. 16:40:16
Olyat nem lenne érdemes csinálni, hogy a megszak rutinban csak egy egyszerű lejátszás megy egy kis bufferből, és egy 50hz-s megszakban pedig ezt a buffert töltjük fel. Így nem kell a gyors megszakba bonyolultabb kódot tenni, hatékonyabb lehet az 50hz-s rutin ami kitömörít és feltölti a buffert.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.02. 23:10:31
Olyat nem lenne érdemes csinálni, hogy a megszak rutinban csak egy egyszerű lejátszás megy egy kis bufferből

Az SNDPLAY így működik, amint az a fenti kódon is látható. Azonban a puffer feltöltését nem 50 Hz-es megszakítás időzíti, hanem a főprogram a puffer olvasási pozíció felső byte-ját (IYH regiszter) figyeli, és ha az írási pozíció növelés után ezzel egyenlő lesz, akkor vár, amíg újra van szabad hely. Tehát a megszakítási rutin gyakorlatilag "szoftveres DMA" lejátszást valósít meg. Így a főprogram időzítése nem fontos, csak azt kell elkerülni, hogy a pufferből elfogyjon a lejátszható hangminta.
Title: Re: Assembly programozás
Post by: endi on 2015.January.02. 23:12:25
szoftveres DMA :) ez jól hangzik
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 14:10:57
A zip (deflate) tömörítése hasonló az epcompress -m0 algoritmushoz, és EP-n hang lejátszáshoz valószínűleg túl lassú lenne.
Csak lustaságom miatt néztem a ZIP-et, azt a leggyorsabb letesztelni, hogy mennyit tömörítene az adaton , hát láttam, szinte semmit :)
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 14:16:29
Az sndplay csak 7 bites, mert nem használ mono lejátszáshoz két csatornát (illetve mindkét oldalon pontosan ugyanaz a kimenet), és a gyakorlatban elsősorban a kezdetleges veszteséges tömörítés, az alacsony mintavételezési frekvencia, és az EP rossz minőségű analóg kimenete korlátozza a minőséget. Az IRQ rutin így néz ki egy és két csatornás lejátszáshoz:

Akkor szerinted nem is érdemes a 8 bites lejátszást erőltetni?
Emulátoron nagyon jól szól a 8bites lejátszás :)
Arra gondoltam, hogy lehetne egy Wav-player belőle.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.03. 14:28:23
A Dave-ből mindenképpen 2x6 bit jön ki, és megy a D/A ellenállásokra :oops:
Wav lejátszó ettől még jól jöhet.
Esetleg meg lehetne építeni végre a külső 8 bites D/A kártyát, amit a DTM is támogat.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 14:36:25
A Dave-ből mindenképpen 2x6 bit jön ki, és megy a D/A ellenállásokra :oops:
De ez csak akkor igaz, ha D/A módban használjuk a 0-ás csatornát , nem?
Tehát ha a pl az összes hangcsatornának a frekvenciáját 0001h-ra állítjuk, akkor egy oldalra már 3x6, és a másik oldalra már 3x6 bit megy, és egy kis trükközéssel, a zajcstorna bevonásával már 2x4x6, nem?
Legalábbis én így gondoltam a bites lejátszóban a D/A kihagyásával.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.03. 14:48:19
Nem, fizikailag jön ki ennyi, lásd bal felső sarok a rajzon. (http://enterprise.iko.hu/schematics/EP64-2~1.jpg)
Belsőleg mixelheti le 6 bitre.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 14:55:05
Akkor szerinted nem is érdemes a 8 bites lejátszást erőltetni?

Annak is van értelme, csak én az SNDPLAY-ben nem próbálkoztam vele, mert elsősorban az volt a cél, hogy alapkiépítésű (128K-s) gépen viszonylag hosszú hangot lehessen lejátszani többé-kevésbé elfogadható minőségen.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 14:57:14
Nem, fizikailag jön ki ennyi, lásd bal felső sarok a rajzon. (http://enterprise.iko.hu/schematics/EP64-2~1.jpg)
Belsőleg mixelheti le 6 bitre.
Akkor parasztvakítás a 2x4 6bites hangerő, mert ha az egyik oldalon van 10, 10, 30, 63 hangerő beállítva, akkor a Dave-ből nagyjából 28-as hangerő jön ki, vagy ki tudja hogy számol pontosan, de ez a lényege, nem?
Tehát ez kb olyan, mintha 2x4 4 bites hangerőnk lenne?
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 14:58:19
Lehetne egyébként olyan módosított/továbbfejlesztett epsndconv és sndplay verziót készíteni, ami a tömörített formátumot 7 helyett 8 bitre dekódolja. Ez a halkabb részeknél javíthatna a minőségen.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 15:03:11
Annak is van értelme, csak én az SNDPLAY-ben nem próbálkoztam vele, mert elsősorban az volt a cél, hogy alapkiépítésű (128K-s) gépen viszonylag hosszú hangot lehessen lejátszani többé-kevésbé elfogadható minőségen.
Ezt teljes sikerrel , de szerintem a viszonylag elfogadhatót is embere válogatja, én úgy emléxem, hogy teljesen jó minőségű volt, amikor teszteltem, ez a nagyfrekvenciás 8bites memóriazabáló lejátszás akkor ötlött fejembe, amikor elkezdtem szórakozni egy speccy program átírásával (le is akadtam a zenénél :D ), és a beeperes zenét akartam Dave-esíteni, ez meg is történt, aztán meg arra gondoltam, hogy Samplékat játszok le a zene alapján, akkor jött ez a 8bites ötlet.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:03:54
Akkor parasztvakítás a 2x4 6bites hangerő

Nem, mert igaz ugyan, hogy a fizikai kimenet csak 6 bites, de a 4 csatorna időosztásos rendszerben működik, így több csatorna használatával lehetséges 6 bitnél nagyobb felbontást elérni. Azonban valódi gépen az analóg kimenetet megvalósító ellenállás hálózat meglehetősen rossz minőségű (pontatlan), ami jelentős torzítást eredményezhet, például előfordulhat, hogy az 1Fh szint magasabb, mint a 20h.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 15:06:41
Lehetne egyébként olyan módosított/továbbfejlesztett epsndconv és sndplay verziót készíteni, ami a tömörített formátumot 7 helyett 8 bitre dekódolja. Ez a halkabb részeknél javíthatna a minőségen.
Én támogatom :) Sőt, esetleg akkor meg lehetne csinálni azt is, hogy támogassa a tömörítetlen Wav fájlok lejátszását is?
A kicsomagolás mennyi időt vesz igénybe ?
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 15:10:05
Nem, mert igaz ugyan, hogy a fizikai kimenet csak 6 bites, de a 4 csatorna időosztásos rendszerben működik, így több csatorna használatával lehetséges 6 bitnél nagyobb felbontást elérni. Azonban valódi gépen az analóg kimenetet megvalósító ellenállás hálózat meglehetősen rossz minőségű (pontatlan), ami jelentős torzítást eredményezhet, például előfordulhat, hogy az 1Fh szint magasabb, mint a 20h.
értem, köszi a leírást, akkor tényleg van értelme a 8bites próbálkozásnak, csak vason nem szól olyan jól ,mint emulátoron, azért kíváncsi lennék, hogy EP-n hogy szól, sajnos lusta vagyok összeszerelni a jó öreg EP konfigom :oops:
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:26:31
Én támogatom :) Sőt, esetleg akkor meg lehetne csinálni azt is, hogy támogassa a tömörítetlen Wav fájlok lejátszását is?
A kicsomagolás mennyi időt vesz igénybe ?
4bites esetén 2 bájt kicsomagolása kb 51 órajelciklus , és ezzel majd feleződik a fájl mérete?

Ez a teljes dekódoló rutin (a csak a lejátszás előtt futó táblázat generálás nélkül) a 3 bites formátumhoz:

Code: ZiLOG Z80 Assembler
  1. decodeBlock_ADPCM3:
  2.         exx
  3.         inc   l
  4.         call  z, readBlock
  5.         ld    a, (hl)
  6.         exx
  7.         rlca
  8.         rlca
  9.         rlca
  10.         ld    h, a
  11.         and   0f8h
  12.         ld    l, a
  13.         xor   h
  14.         add   a, high diffTable
  15.         ld    h, a
  16.         ld    de, decodeTable
  17.         ld    bc, 8
  18.         ldir
  19.  
  20. decodeSamples_ADPCM3:
  21.         ld    h, d
  22.         ld    b, 7
  23.         ld    c, ixl
  24. .l1:    exx
  25.         inc   l
  26.         call  z, readBlock
  27.         ld    a, (hl)
  28.         exx
  29.         ld    d, a
  30.         rlca                            ; sample 0
  31.         rlca
  32.         rlca
  33.         and   b
  34.         ld    l, a
  35.         ld    a, (hl)
  36.         add   a, c
  37.         ld    c, a
  38.         exx
  39.         ld    (de), a
  40.         inc   e
  41.         exx
  42.         ld    a, d
  43.         rrca                            ; sample 1
  44.         rrca
  45.         and   b
  46.         ld    l, a
  47.         ld    a, (hl)
  48.         add   a, c
  49.         ld    c, a
  50.         exx
  51.         ld    (de), a
  52.         inc   e
  53.         inc   l
  54.         call  z, readBlock
  55.         ld    a, (hl)
  56.         exx
  57.         rlca                            ; sample 2
  58.         ld    e, a
  59.         ld    a, d
  60.         rla
  61.         and   b
  62.         ld    l, a
  63.         ld    a, (hl)
  64.         add   a, c
  65.         ld    c, a
  66.         exx
  67.         ld    (de), a
  68.         inc   e
  69.         exx
  70.         ld    a, e
  71.         rlca                            ; sample 3
  72.         rlca
  73.         rlca
  74.         and   b
  75.         ld    l, a
  76.         ld    a, (hl)
  77.         add   a, c
  78.         ld    c, a
  79.         exx
  80.         ld    (de), a
  81.         inc   e
  82.         exx
  83.         ld    a, e
  84.         rrca                            ; sample 4
  85.         rrca
  86.         ld    e, a
  87.         and   b
  88.         ld    l, a
  89.         ld    a, (hl)
  90.         add   a, c
  91.         ld    c, a
  92.         exx
  93.         ld    (de), a
  94.         inc   e
  95.         inc   l
  96.         call  z, readBlock
  97.         ld    a, (hl)
  98.         exx
  99.         ld    d, a
  100.         sla   e                         ; sample 5
  101.         rla
  102.         rla
  103.         rla
  104.         and   b
  105.         ld    l, a
  106.         ld    a, (hl)
  107.         add   a, c
  108.         ld    c, a
  109.         exx
  110.         ld    (de), a
  111.         inc   e
  112.         exx
  113.         ld    a, d
  114.         rrca                            ; sample 6
  115.         rrca
  116.         rrca
  117.         and   b
  118.         ld    l, a
  119.         ld    a, (hl)
  120.         add   a, c
  121.         ld    c, a
  122.         exx
  123.         ld    (de), a
  124.         inc   e
  125.         exx
  126.         ld    a, d
  127.         and   b                         ; sample 7
  128.         ld    l, a
  129.         ld    a, (hl)
  130.         add   a, c
  131.         ld    c, a
  132.         exx
  133.         ld    (de), a
  134.         inc   e
  135.         ld    a, e
  136.         exx
  137. .l2:    and   0ffh                      ; * block size - 1
  138.         jp    nz, .l1
  139.         ld    ixl, c
  140.         ret

A decodeBlock minden blokknál (általában 8, 16, 32, vagy 64 hangminta, kisebb blokk méret jobb minőségű, de nagyobb file-t eredményez, és lassabb a dekódolása) egyszer fut le, a többi pedig 8 hangminta lejátszása. Nem számoltam, pontosan hány ciklus átlagosan egy hangminta, de úgy látom kb. 70 lehet a blokk fejléc nélkül.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.03. 15:31:42
Nem, mert igaz ugyan, hogy a fizikai kimenet csak 6 bites, de a 4 csatorna időosztásos rendszerben működik, így több csatorna használatával lehetséges 6 bitnél nagyobb felbontást elérni.
Trükkös! És ez milyen frekvenciával történik, Dave órajellel?
Elvileg ha a 0-2 csatorna fix 0-ás, az 1-3 meg fix 63-as hangerőre van beállítva, akkor egy mérhető négyszögjel lesz, igaz?

Quote
Azonban valódi gépen az analóg kimenetet megvalósító ellenállás hálózat meglehetősen rossz minőségű (pontatlan), ami jelentős torzítást eredményezhet, például előfordulhat, hogy az 1Fh szint magasabb, mint a 20h.
Elvileg ide lehetne valami jobb D/A-t berakni, meg esetleg az analóg erősítőrészt is felújítani.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:37:54
Trükkös! És ez milyen frekvenciával történik, Dave órajellel?

Ezt nem említi a dokumentáció, de például oszcilloszkóppal talán mérhető lenne.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:46:22
Tehát ha a pl az összes hangcsatornának a frekvenciáját 0001h-ra állítjuk, akkor egy oldalra már 3x6, és a másik oldalra már 3x6 bit megy, és egy kis trükközéssel, a zajcstorna bevonásával már 2x4x6, nem?

A zajcsatornán nehéz folyamatosan magas (nem zaj) kimenetet elérni, nekem ez csak másik csatorna "feláldozásával" sikerült, de akkor már nincs értelme, ha a felhasználható csatornák számának a növelése a cél.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 15:56:32
A zajcsatornán nehéz folyamatosan magas (nem zaj) kimenetet elérni, nekem ez csak másik csatorna "feláldozásával" sikerült, de akkor már nincs értelme, ha a felhasználható csatornák számának a növelése a cél.
Felüláteresztő szűrő a zajral a 0-ás csatornával, nem jó, vagy akkor is bukjuk a 0-ás csatornát?
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:56:36
Még egy, talán csak elméleti jelentőségű megoldás a felbontás javítására a nagyon magas mintavételezési frekvencia (ami önmagában is hasznos) és noise shaping használata, amivel a hallható tartományban 8 bitnél jobb minőséget lehetne elérni. Turbós és bővített gépen ez elvileg működhetne (7.12 MHz-en ~80 kHz-es mintavételezés 6 biten, és 2 MB ~26 másodperc mono hang tárolására elég), de a rossz minőségű D/A konverzió valószínűleg problémát okozna. Viszont normál 4 MHz-es gépen is megoldható a 44.1 kHz-es lejátszás, ha másra nem is marad idő.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.03. 15:58:23
Felüláteresztő szűrő a zajral a 0-ás csatornával, nem jó, vagy akkor is bukjuk a 0-ás csatornát?

A szűrés nem szünteti meg a hallható zajt, csak halkabb lesz, de a lejátszott digitális hang is.
Title: Re: Assembly programozás
Post by: geco on 2015.January.03. 16:01:14
A szűrés nem szünteti meg a hallható zajt, csak halkabb lesz, de a lejátszott digitális hang is.
Szuper, ebből is látszik mennyire értek hozzá :D
Amúgy nézegettem a kicsomagoló rutint, tök jó, és ahogy nézem, emellett 16KHz-es lejátszásnak elméletileg még mennie is kéne.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.03. 16:15:00
Ezt nem említi a dokumentáció, de például oszcilloszkóppal talán mérhető lenne.
Igen, pont ilyen mérésre gondoltam.
Title: Re: Assembly programozás
Post by: endi on 2015.January.05. 00:59:57
off, annak idején egy rövid ideig programoztam amigát asm-ban, írtam rá egy kis demót (sajnos elveszett)
de egyvalamit nem értettem az amigában. attól lefagyott, hogy memóriát olvastam. miért lehetett ez?
Title: Re: Assembly programozás
Post by: lgb on 2015.January.05. 10:39:37
off, annak idején egy rövid ideig programoztam amigát asm-ban, írtam rá egy kis demót (sajnos elveszett)
de egyvalamit nem értettem az amigában. attól lefagyott, hogy memóriát olvastam. miért lehetett ez?

Bar igazan nem vagyok Amiga guru, es inkabb tippelek, valamint a konkret problemat se ismerem, azert megprobalok belepofazni, ha kell ha nem :) Szoval, Amiga nem igazan 8 bites, es van egy sajatossag, hogy nagyobb adatmeretnel (azt nem tudom, hogy 16/32 bit eseten ugyanugy vagy csak pl 32 bitnel) ha az nem "aligned" hozzaferes, az biza problema. Marmint pl 16 bites szo olvasasa paratlan memoriacimrol. Egy Z80 eseten ez kevesbe gond: az is tud ugyan olvasni 16 bitet ugye, de valojaban - mivel 8 bites az adatbusz - "ket darabban" olvassa be (szoval tok mind1, hogy paros v paratlan cimen van pl). Amiga eseten a CPU adatbusz (legalabbis 68000-es CPU-knal, kesobb talan volt mar 32 bites is) 16 bites, igy a 16 bitet egyben akarna. Bocsanat, jobban kevesbe tudom elmagyarazni, de nem is igazan ertek hozza :-D Gyakrolatban sose code-oltam Amigra ugyanis.

http://en.wikipedia.org/wiki/Guru_Meditation (http://en.wikipedia.org/wiki/Guru_Meditation)

Keress ra az unaligned szora az oldalon.

Ez az unaligned access amugy x86-oson is gond, de ott a CPU lekezeli talan, es max annyi a kovetkezmenye, hogy lassabb lesz a vegrehajtasa (plusz orajelciklus stb). Ez viszont remekul ramutat arra, hogy ott is erdemes aligned hozzaferest csinalni, meg ha nem is okoz feltetlen "fagyast", akkor sem optimalis! ...

Z80 eseten viszont total mind1, mivel 8 bitenkent csinalja, tehat ott kb lenyegtelen szerintem. Ezek a gondok ott merulnek fel, ha 8 bitnel nagyobb az elerni kivant adatmennyiseg, es a CPU "nativ" (adatbusz, miegymas) szohossza is nagyobb ennel. IMHO.

Illetve pl: http://en.wikipedia.org/wiki/Bus_error#Unaligned_access (http://en.wikipedia.org/wiki/Bus_error#Unaligned_access)
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.18. 11:53:35
62.5 kHz-es sztereó lejátszó 4 MHz-es gépre:
[attachurl=#]
Sok értelme ugyan nincsen, mert még 4 MB-os gépen is csak kb. fél percet tud lejátszani, és a bemeneti formátum (sndp625.bin file) fejléc nélküli 6 bites hangminta pazarló módon 8 biten tárolva. :oops: A file betöltése hosszabb ideig tart, mint a lejátszás. De megfelelően konvertálva (noise shaping használatával) jó minőségű, legalábbis emulátoron, igazi gépen valószínűleg problémát okozna a D/A konverzió torzítása.
Title: Re: Assembly programozás
Post by: geco on 2015.January.19. 10:01:05
62.5 kHz-es sztereó lejátszó 4 MHz-es gépre:
(Attachment Link)
Sok értelme ugyan nincsen, mert még 4 MB-os gépen is csak kb. fél percet tud lejátszani, és a bemeneti formátum (sndp625.bin file) fejléc nélküli 6 bites hangminta pazarló módon 8 biten tárolva. :oops: A file betöltése hosszabb ideig tart, mint a lejátszás. De megfelelően konvertálva (noise shaping használatával) jó minőségű, legalábbis emulátoron, igazi gépen valószínűleg problémát okozna a D/A konverzió torzítása.
Nem baj, hogy sok értelme nincs, a lényeg (legalábbis az én szemszögemből), hogy mit lehet :D
Amúgy SD kártyával már értelme is lenne, fél perc lejátszás után (jó)pár másodperces várakozás. majd újra fél perces lejátszás :D
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.19. 12:02:46
Nem baj, hogy sok értelme nincs, a lényeg (legalábbis az én szemszögemből), hogy mit lehet :D

Ha valakinek van jó minőségű konvertálható 29-30 másodperces hangmintája, azzal ki lehetne próbálni, milyen az EP-s "hifi" hang, legalábbis emulált "ideális" hardveren. Esetleg még módosítani lehetne a lejátszót 7 bites 41667 Hz-es formátum használatára, ami másfélszer kisebb file méretet tesz lehetővé, de ehhez még optimalizálni kellene.
Title: Re: Assembly programozás
Post by: geco on 2015.January.19. 13:05:43
Ha valakinek van jó minőségű konvertálható 29-30 másodperces hangmintája, azzal ki lehetne próbálni, milyen az EP-s "hifi" hang, legalábbis emulált "ideális" hardveren. Esetleg még módosítani lehetne a lejátszót 7 bites 41667 Hz-es formátum használatára, ami másfélszer kisebb file méretet tesz lehetővé, de ehhez még optimalizálni kellene.
Sztem kipróbálom valami MP3 átalakításával, majd feltöltöm.
A mono 8bit emulátoron jó volt.
Title: Re: Assembly programozás
Post by: endi on 2015.January.19. 13:11:06
olyat nem lehet hogy pl 5 bites, szoftveresen feljavítjuk realtime? :)
pl 5 bit 8 KHz, de szoftveresen közé interpolálunk 6 bites (vagy 8 ) és 16KHz-n játszuk?
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.19. 13:31:42
olyat nem lehet hogy pl 5 bites, szoftveresen feljavítjuk realtime? :)

A 6 bites 62500 Hz-es hang már "feljavított" lehet, mert olyan dither (noise shaping) használatát teszi lehetővé, ahol a zaj nagy része a nem hallható 20000-31250 Hz tartományba kerül, és a hallható zaj alacsonyabb, mint az egyszerű 6 (vagy akár 7-8) bites konverziónál. A legtöbb modern DAC hasonló trükkel ér el akár 20-21 bites minőséget úgy, hogy az analóg kimenet ténylegesen csak néhány bites felbontású, de több MHz-es frekvenciát használ.
Title: Re: Assembly programozás
Post by: endi on 2015.January.19. 14:19:05
A 6 bites 62500 Hz-es hang már "feljavított" lehet, mert olyan dither (noise shaping) használatát teszi lehetővé, ahol a zaj nagy része a nem hallható 20000-31250 Hz tartományba kerül, és a hallható zaj alacsonyabb, mint az egyszerű 6 (vagy akár 7-8) bites konverziónál. A legtöbb modern DAC hasonló trükkel ér el akár 20-21 bites minőséget úgy, hogy az analóg kimenet ténylegesen csak néhány bites felbontású, de több MHz-es frekvenciát használ.

ez ok, de ehhez marha nagy freki kell, amit mi nem bírunk sebességgel z80-on
viszont kevesebb biten tárolva kisebb memória igény lesz, és ha lehetséges, közé interpolálva több bites értéket...?
Title: Re: Assembly programozás
Post by: geco on 2015.January.19. 16:14:42
Konvertáltam egy darabkát, a végén lehet egy kisebb zaj, mert 1,3 KB még az utolsó előtti 16Kb-ból van.
Meghallgatni még nem tudtam, majd otthon.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.19. 17:53:28
Emulátoron előfordulhat, hogy időzítési probléma miatt zajos a lejátszás. :oops: Ez azért fordulhat elő, mert a NICK, DAVE, és Z80 szinkronizációjának a felbontása jelenleg 1 NICK slot, és mivel ez a DAVE mintavételezési frekvenciájának (250 kHz) nem egész számú többszöröse, a hangminták időzítésénél előfordulhat "véletlenszerű" pontatlanság (jitter). De szerencsés esetben - a Z80 és DAVE emuláció órajelének relatív fázisától függően - nincs ilyen hiba, és valódi gépen sem (ott viszont a rossz D/A konverzió okozhat problémát).

Ezzel a módosított verzióval, ami szinkronizálja a lejátszás indítását a DAVE hanggenerátorával, talán elkerülhető a hiba:
[attachurl=#]
Title: Re: Assembly programozás
Post by: geco on 2015.January.19. 18:39:30
Rosszul gondolom, hogy pl egy egybites lejátszásnál (pl Speccy) el lehet érni úgy, vagy hasonlóan 8 bites lejátszást, hogy mondjuk a 8bites 20KHz-es samplét 160 KHz-en játszuk le, és minden sampléban lévő bájtot 8 1 bitesként kezelünk?

pl FFh-t 11111111 ként toljuk ki a beeperre, 8fh.t 10001111-ként, vagy 256 bit kellene hozzá még nagyobb sebességen, vagy ettől azért bonyolultabb?
Hallottam nagyon jó beeper zenét, ami nem volt beeperes, ezt nem tudom jobban megfogalmazni, remélem azért érthető :)
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.19. 18:47:13
Rosszul gondolom, hogy pl egy egybites lejátszásnál (pl Speccy) el lehet érni úgy, vagy hasonlóan 8 bites lejátszást, hogy mondjuk a 8bites 20KHz-es samplét 160 KHz-en játszuk le, és minden sampléban lévő bájtot 8 1 bitesként kezelünk?

pl FFh-t 11111111 ként toljuk ki a beeperre, 8fh.t 10001111-ként, vagy 256 bit kellene hozzá még nagyobb sebességen, vagy ettől azért bonyolultabb?

8-nál több, de 256-nál kevesebb kellene hozzá. Mindenesetre 4 MHz-es CPU-n már a 160 kHz-es lejátszásnál is csak 25 ciklus idő lenne egy hangmintára.
Title: Re: Assembly programozás
Post by: geco on 2015.January.19. 19:03:27
8-nál több, de 256-nál kevesebb kellene hozzá. Mindenesetre 4 MHz-es CPU-n már a 160 kHz-es lejátszásnál is csak 25 ciklus idő lenne egy hangmintára.
Naja, ezt nem számoltam, ez csak arra lenne elég, hogy toljuk az adatokat ki egy hangcsatornára, lapozás már felejtős is :lol:
Meghallgattam a HiFi EP-t, vagyis kb 10 perce szól ugyanaz a fél perc, nagyon jó ,először kb 1 másodperc ment csak, azt hittem rosszul konvertáltam 8bitről 6-ra, aztán rájöttem, hogy váltani kéne a 128-as konfigról :D

Ha meg akarja próbálni más is, itt a befordított verzió:

Lustábbak kedvéért egy snapshot is :D
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.19. 20:00:12
Néhány konvertált hangminta, bár ezeknél talán jobbakat is lehetett volna találni, és a konverzión is lehetne javítani:
[attachurl=#]
Title: Re: Assembly programozás
Post by: endi on 2015.January.19. 20:12:42
az a baj ezekről csak igazi ep-n lehetne eldönteni a minőséget
pc-n ügye a hangkártya feljavítja
Title: Re: Assembly programozás
Post by: szipucsu on 2015.January.19. 20:22:19
Lustábbak kedvéért egy snapshot is :D
play625.ep128s (3809.21 kB - letöltve 254346 alkalommal.)
Ez nagyon jó!
Title: Re: Assembly programozás
Post by: lgb on 2015.January.19. 21:45:21
Bar talan inkabb Z80 topic, de vegulis asm is :) Tudjuk mit csinal a HALT opcode. Mi van azonban akkor, ha le van tiltva a megszakitas? Ket esetet latok: a HALT "orokke beragad" (RESET kell neki vagy NMI - ha van olyan a rendszerben ami NMI-t eloallit persze ...), es ennyi. A masik lehetoseg: bar interrupt nem valtodik ki, a HALT-rol "tovabbmegy" a CPU, tehat letiltott interrupt (pl DI utan) eseten is lehet hatasa egy megszakitaskeresnek bizonyos esetekben. Pl a masodik viselkedesformara jo pelda a 6502 fejlettebb verzioja (65816). A kerdes, hogy Z80 melyik a ket eset kozul? Remelem a masodik mert az igen hasznos tud lenni. Igaz csak ki kene probalnom kb    DI HALT EI vagy hasonlo szekvenciaval (ha VINT amugy generalodik pl), ha a masodik, akkor "nem fagy" a gep, ha az elso, akkor a HALT-nal megall gondolom, es ott ragad. Dehat lusta vagyok, nem probalgatok :) thx
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.19. 21:56:53
Első.

Mondjuk nem is értem, hogy letiltott megszakítás esetén miért kéne megszakításnak bármit csinálni :oops:
Title: Re: Assembly programozás
Post by: lgb on 2015.January.19. 22:03:04
Első.

Mondjuk nem is értem, hogy letiltott megszakítás esetén miért kéne megszakításnak bármit csinálni :oops:

Hat az nagy kar :( Hogy miert kene? Gondold el, tok logikus es nagyon hasznos: kell pl egy nagyon pontos idozites, hogy adott jelre csinalj valamit lehetoleg 1 orajelcikluson belul. Na 65816-ra erre jo a HALT (na jo ott WAI-nak hivjak, de a lenyegen nem valtoztat). Interrupt-ot letiltod, WAI-t kiadod, CPU beall, mint a szeg, de ha jon egy interrupt, akkor folytatja a kov opcode-on a vegrehajtast, azaz 1 orajelciklus pontosaggal (!) tudsz reagalni kulso esemenyre. Szerintem ez azert hasznos. Maskulonben mi ertelme van a HALT utasitasnak letiltott interrupt-okkal hiszen csak "megoli" a CPU-t, nem lehet kihasznalni semmi ertelmesre ... A fenti megoldassal viszont hasznos engedelyezett es tiltott interruptoknal is, csak kicsit mas a viselkedese persze! Pont a fenti tulajdonsagra fentem a fogam, de akkor hiaba, Z80-on nem fog menni :( Ui, az a tizenX T state amig int elfogadva ahhoz sok, amire nekem kene. Szoval az is logikus ertelmezes, hogy az interrupt letiltasa az interrupt _elfogadast_ tiltja (elugras az interrupt vectorra, cimre, stb), de attol meg lehet hatasa mas tekintetben. Na jo, keresek akkor mas megoldast, es nem itt sirankozom, koszi :)
Title: Re: Assembly programozás
Post by: balagesz on 2015.January.19. 23:37:09
Mondjuk nem is értem, hogy letiltott megszakítás esetén miért kéne megszakításnak bármit csinálni :oops:

Gondolom a letiltás alatt a CPU IRQ elfogadás tiltás van értve (DI), a hardver az ettől függetlenül birizgálja a processzor megszakítás bemenetét. Ebben az esetben a "várt" viselkedés az, hogy a HALT esetén a CPU megáll, ezután valamikor jön egy IRQ kérelem a hardver felől, akkor meg a CPU csak simán kilép a HALT állapotból, de nem kezdi el a megszakítási rutint, hanem folytatja a HALT utáni utasítással. Legalábbis ez a tipp. :) Ez szerintem kéne hogy menjen Z80 esetén. Persze a tuti a doksiban lesz.
Title: Re: Assembly programozás
Post by: lgb on 2015.January.20. 01:35:13
Gondolom a letiltás alatt a CPU IRQ elfogadás tiltás van értve (DI), a hardver az ettől függetlenül birizgálja a processzor megszakítás bemenetét. Ebben az esetben a "várt" viselkedés az, hogy a HALT esetén a CPU megáll, ezután valamikor jön egy IRQ kérelem a hardver felől, akkor meg a CPU csak simán kilép a HALT állapotból, de nem kezdi el a megszakítási rutint, hanem folytatja a HALT utáni utasítással. Legalábbis ez a tipp. :) Ez szerintem kéne hogy menjen Z80 esetén. Persze a tuti a doksiban lesz.

Na erre gondoltam en is ... Tesztelni egyszeru lenne, de emulatoron (amit en tudnek max most itt) nem biztos, hogy realis :) Doksi meg hosszu, RTFM-hez kell egy rakas vallalkozokedv - mint mindig :)
Title: Re: Assembly programozás
Post by: balagesz on 2015.January.20. 02:13:42
Doksi meg hosszu, RTFM-hez kell egy rakas vallalkozokedv - mint mindig :)

Na, kerestem FM-et. A zilog Z80 CPU User Manual 2014-es kiadását (http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=UM0080&ft=User%20Manual&f=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2T0RBdmRXMHdNRGd3TG5Ca1pnPT0=) dobta ki elsőnek az internet. A pdf 28. oldalán (is) van erről szó. Egyrészt azt írja, hogy HALT alatt NOP-okat hajt végre a CPU, ami meg nem egy órajel, tehát 1 ciklus pontossággal nem fog tudni ebből az állapotból kilépni. Aztán meg azt is írja, hogy a kilépéshez NMI kell, vagy INT és engedélyezett interrupt. :( Szóval ez alapján mégse működik a "várt" viselkedési mód. (Amúgy az angollal nem vagyok még túl nagy barátságban, :) aki jobban érti, az fordíthatna, hátha valamit elértek.)
Title: Re: Assembly programozás
Post by: lgb on 2015.January.20. 06:54:07
Na, kerestem FM-et. A zilog Z80 CPU User Manual 2014-es kiadását (http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=UM0080&ft=User%20Manual&f=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2T0RBdmRXMHdNRGd3TG5Ca1pnPT0=) dobta ki elsőnek az internet. A pdf 28. oldalán (is) van erről szó. Egyrészt azt írja, hogy HALT alatt NOP-okat hajt végre a CPU, ami meg nem egy órajel, tehát 1 ciklus pontossággal nem fog tudni ebből az állapotból kilépni.

Na ja, tehat max 1 M-state, es nem T ... Meg mindig pontosabb lenne, mint a 13 (vagy mennyi igy fejbol) "normal" interrut eseten.

Quote
Aztán meg azt is írja, hogy a kilépéshez NMI kell, vagy INT és engedélyezett interrupt.

;-(
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.20. 12:13:09
az a baj ezekről csak igazi ep-n lehetne eldönteni a minőséget
pc-n ügye a hangkártya feljavítja

Nem a hangkártya javítja fel, hanem EP-n az egyszerű ellenállásos D/A konverter rontja el. :) Igaz ugyan, hogy EP-n nincs megfelelő aluláteresztő szűrő, de ez 62.5 kHz mintavételezési frekvenciánál nem akkora probléma, mert 31.25 kHz felett kellene szűrni, amit egyébként sem lehet hallani. A szűrő hiányát valamennyire emulálni lehet 192 kHz-es kimeneti frekvenciát beállítva.

Mindenesetre érdemes lenne kipróbálni ezeket (http://enterpriseforever.com/programozas/assembly-programozas/msg44415/#msg44415) a hangmintákat valódi gépen, ha valakinek van 2-4 MB-ra bővített gépe IDE vezérlővel. Emulátoron ezek 8 bithez hasonló minőségűek, de ennek az az ára, hogy nagyon zajosak 20 kHz körüli frekvencián (amit a legtöbben nem vagy csak kis mértékben hallanak). Az EP hangkimenetének a torzítása miatt a zaj egy része a jól hallható tartományba kerülhet.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.20. 12:16:23
Az EP hangkimenetének a torzítása miatt a zaj egy része a jól hallható tartományba kerülhet.
Magyarán az a kérdés, hogy van-e valami jól hallható minőségromlás?
Title: Re: Assembly programozás
Post by: geco on 2015.January.20. 13:10:04
Magyarán az a kérdés, hogy van-e valami jól hallható minőségromlás?
Sztem igen, bár én arra tippelek, hogy a hozzánk hasonló botfülűek nem nagyon vesznek észre semmit :D
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.20. 13:30:46
a hozzánk hasonló botfülűek nem nagyon vesznek észre semmit :D
Én is ettől tartok :oops:
Title: Re: Assembly programozás
Post by: lgb on 2015.January.25. 21:50:39
Van-e vmi "egyszeru" mod arra, hogy "kinyerjem" az EXOS (sw text80 mode) es Nick (hw text40) mod altal hasznalt karakterkeszletet, es sajat celjaimra hasznaljam egy programban? Az eddigi egyeduli kisse suta megoldas, hogy megnezem a $BFF4 cimen az EXOS LPT-t, aztan az elso LPB-bol (az elvileg a statusz sore ha minden igaz pl) kihamozom az LD2-bol a cimet, hogy hova rakta le a vram-ba, ide-oda tologatom, megfelelo vram szegmenst belapozom, aztan vegre masolhatom is (de pl eshet szegmenshatarra? mert akkor arra is kell figyelnem). Ennel egyszerubb megoldas nem letezik? Kene pl arra, hogy sajat karakterkirako rutint irjak (EXOS-on at nemikepp lassu lenne) grafikus modban, es ugy gondoltam, kisebb programmeretet eredmenyez, ha run-time "lenyulom" a karakterkeszletet, mintha a programom tartalmazna egyet, feleslegesen, amikoris az EP-ben ugy is van ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.25. 21:56:09
Csak azt kell megnézni, hogy EXOS 2.0 vagy 2.1+
2.0-ban B680h, 2.1-től B480h a kezdete (ha a rendszerszegmens a 2. lapon van).
Title: Re: Assembly programozás
Post by: lgb on 2015.January.25. 22:08:54
Csak azt kell megnézni, hogy EXOS 2.0 vagy 2.1+
2.0-ban B680h, 2.1-től B480h a kezdete (ha a rendszerszegmens a 2. lapon van).

Hat ez szuper, koszi. Csak ugye en mindig aggodom, ha EP-n fix cimeket akar az ember hasznalni (volt erre rossz pelda mar ...), mert ki tudja nem lesz-e mas, ha pl van EXDOS/nincs EXDOS (vagy rendszegmensbol utana foglal o csak), stb. De ha ez meg nem is all, mi lesz a kesobbi EXOS verziokkal? :) Vagy szerinted kar ennyit rianyalnom, es nyugodt szivvel hasznaljam az altalad adott modszert, es akkor tuti? :) Illetve, ez mindig ott van, akkor is, ha nincs video lap stb megjelenitve (EXOS altal) semmi? Mert en azert is akartam tulbonyolitani, mert felteteleztem, hogy pl video csati nyitas, megjelenites utan foglal csak esetleg memoriat es masolja ki a rom-bol a vram-ba, de akkor ezek szerint ez nem igaz?

Btw, EXOS altal ch256 mod nincs is hasznalatban egyaltalan, tehat csak 128 karakteres keszlet van benne 9 pixel magassaggal, as nem? Nekem ez a feltetelezesem ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.25. 22:16:25
Ez fixen ott van, és igen csak 128-as.
Title: Re: Assembly programozás
Post by: szipucsu on 2015.January.26. 12:13:13
Van-e vmi "egyszeru" mod arra, hogy "kinyerjem" az EXOS (sw text80 mode) es Nick (hw text40) mod altal hasznalt karakterkeszletet, es sajat celjaimra hasznaljam egy programban?
Itt a wikin (http://wiki.enterpriseforever.com/index.php/IS-BASIC_tr%C3%BCkk%C3%B6k) alul van erre egy basic program. Assemblyben is biztos valahogy így kell, csak kicsit másképp. :D
Title: Re: Assembly programozás
Post by: IstvanV on 2015.January.26. 16:53:52
Hat ez szuper, koszi. Csak ugye en mindig aggodom, ha EP-n fix cimeket akar az ember hasznalni (volt erre rossz pelda mar ...)

Csak dokumentált fix címet használó, de kevésbé egyszerű megoldás: a BFF4h címről olvasható az EXOS LPT kezdőcíme a 2. lapon, az első LPB pedig mindig a státuszsor 128 karakteres módban:

Code: ZiLOG Z80 Assembler
  1.         ld      hl, (0bff4h)
  2.         set     2, l
  3.         set     1, l
  4.         ld      h, (hl)
  5.         xor     a
  6.         sra     h
  7.         rra
  8.         ld      l, a
  9.         res     6, h

Ez feltételezi, hogy a karakterkészlet az FFh szegmensen van a 2. lapon.
Title: Re: Assembly programozás
Post by: lgb on 2015.January.26. 20:18:53
Csak dokumentált fix címet használó, de kevésbé egyszerű megoldás: a BFF4h címről olvasható az EXOS LPT kezdőcíme a 2. lapon, az első LPB pedig mindig a státuszsor 128 karakteres módban:

Igen, pont ezt akartam csinalni en is :) Csak szoget utott a fejembe, hogy nincs-e vmi egyszerubb amde dokumentalt mod, ahogy az LPT cimere is van (es amugy ha jol ertem, "elvileg" - persze lehet pont ez a nem dokumentalt! - az LPT elott van a charset pont, tehat csak le kell vonni 9*128=1152 -ot). Bar mondjuk lehet, tulaggodom: valszeg' "hivatalos" uj EXOS kevesbe fog megjelenni, ha meg fog, az pl Zozotol lesz, aki majd figyel ilyenekre, hogy ez maradjon ahogy volt :-P
Title: Re: Assembly programozás
Post by: endi on 2015.January.26. 20:20:09
kéne egy függvény könyvtárat csinálni ami ilyesmi adatokat kiad
basic-hez is jól jönne, már nagyon poke-olni akarok :)
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.January.26. 20:24:14
Itt vannak rendszerszegmens címek kigyűjtve. (http://enterprise.iko.hu/memorymap.htm)
Title: Re: Assembly programozás
Post by: Povi on 2015.February.02. 14:43:50
Na igen. Amugy Z80-ra is van hasonlo trukk, hogy legalabb ne teljesen off-topic legyen. Ha csak ritkan kell veletlenszam,akkor az R regiszter segithet tovabb randomizalni, mivel azt azert nehez megjosolni, hogy mi lesz benne, ha kozben lefut a fel vilagegyetem cimu kodreszlet, meg feltetelek stb vannak benne ... Nyilvan ha mondjuk minden masodik utasitasnal kell veletlenszam akkor az R egesz jol kiszamithato :)

Ja, én  a Spectris-ben (spectrumról átírt 1kB-os Tetris klón) használtam az R-regisztert véletlenszám-generátorként, nem is jött be... :-) Ugye 7 különböző alakzat van, fogtam az R értékét, kinulláztam a felső 5 bitet, és ha nulla volt az eredmény, akkor újra vettem az R-t. Így volt egy "véletlen számom" 1-7 között. Meg is látszik a játékban, hogy baromira nem lett jó így, mert sokkal gyakrabban kapok "Z" formát, aminek 1 a kódja, mint a többi elemet. :-)
Title: Re: Assembly programozás
Post by: IstvanV on 2015.February.02. 20:37:38
Ja, én  a Spectris-ben (spectrumról átírt 1kB-os Tetris klón) használtam az R-regisztert véletlenszám-generátorként, nem is jött be... :-) Ugye 7 különböző alakzat van, fogtam az R értékét, kinulláztam a felső 5 bitet, és ha nulla volt az eredmény, akkor újra vettem az R-t. Így volt egy "véletlen számom" 1-7 között. Meg is látszik a játékban, hogy baromira nem lett jó így, mert sokkal gyakrabban kapok "Z" formát, aminek 1 a kódja, mint a többi elemet. :-)

Ezt a véletlenszám generátort a Boulder Dash átiratomban használtam, viszonylag egyszerű, és elfogadható minőségű. Az A regiszter a kimenet:
Code: ZiLOG Z80 Assembler
  1. dstAddr:
  2. .l1:    ld    hl, 7fffh                 ; * random seed
  3.         ld    a, r
  4.         xor   l
  5.         add   hl, hl
  6.         xor   h
  7.         ld    l, a
  8.         xor   h
  9.         ld    h, a
  10.         ld    (.l1 + 1), hl
  11.         ret
Title: Re: Assembly programozás
Post by: Povi on 2015.February.21. 01:31:12
az LDIR utasításra azt írják, hogy 21 / 16 ciklus a végrehajtási ideje. Gondolom a 21 ciklus egy bájtra vonatkozik, a 16 pedig arra, ha BC == 0?
Title: Re: Assembly programozás
Post by: lgb on 2015.February.21. 02:06:01
az LDIR utasításra azt írják, hogy 21 / 16 ciklus a végrehajtási ideje. Gondolom a 21 ciklus egy bájtra vonatkozik, a 16 pedig arra, ha BC == 0?

Szerintem igen. Ha megnezed, az LDI 16 ciklus. Azaz pont annyi mint az LDIR, ha nem kell "ismetelni" mar (a 21 meg arra, ha kell meg). Nem tartozik a temahoz, de ez regi szivfajdalmam a Z80 kapcsan. Logikusabb lenne _szerintem_ ha az LDI beken hagyna a BC-t, mert pl sok LDI egymas utan trukknel nem rontana el a BC-t. Az LDIR meg megfelelne egy LDI + looping-nak, ahol a looping resz intezne a BC-s dolgot. Ilyesforman lehet, egy sima LDI meg gyorsabb is lenne, mint most. Ehelyett, most maskepp van "felosztva", LDI magaban is butykoli a BC-t.
Title: Re: Assembly programozás
Post by: IstvanV on 2015.February.21. 12:25:40
Logikusabb lenne _szerintem_ ha az LDI beken hagyna a BC-t, mert pl sok LDI egymas utan trukknel nem rontana el a BC-t. Az LDIR meg megfelelne egy LDI + looping-nak, ahol a looping resz intezne a BC-s dolgot. Ilyesforman lehet, egy sima LDI meg gyorsabb is lenne, mint most. Ehelyett, most maskepp van "felosztva", LDI magaban is butykoli a BC-t.

A BC csökkentése a sok LDI-s megoldásnál is hasznos lehet, mert így az LDI-k JP PE utasítással ciklusban futtathatók. 2-nél több LDI esetén ez már gyorsabb, mint az LDIR.

A BC csökkentésének a hiánya valószínűleg nem gyorsítaná az LDI/LDD utasításokat, mert a DE és HL regisztereket továbbra is növelni/csökkenteni kellene (4 + 4 ciklus utasítás olvasás, 3 ciklus (HL) olvasás, 3 (DE) írás, és 2 regiszter módosítás = 16 ciklus).
Title: Re: Assembly programozás
Post by: lgb on 2015.February.21. 13:57:55
Nalam konkretan ott jott elo a problema, hogy fix hosszusagu dolgot masoltam volna jo par LDI-vel egy igen sebessegerzekeny rutinban, amde az azt korulvevo kodnal meg kellett volna meg a B es C masra. Konkretan nem is ertettem, miert nem jo a kodom, mert nem gondoltam ra, hogy az LDI is bizeralja a BC-t, nem csak az LDIR :) Az ep128emu debuggerevel jottem ra erre, ez persze az en figyelmetlensegem nyilvan, hogy nem ismertem elegge a Z80 mukodeset ezek szerint :) Jo persze az EX-es dolgok is nagy segitseget jelentenek azert, ha "keves a regiszter" :) Az mondjuk nem vilagos amit irtal, oke, hogy a DE, HL is modositando az LDI altal, de ha kimaradna a BC nem lenne gyorsabb a csak LDI-t hasznalok jellegu felhasznalasnal?
Title: Re: Assembly programozás
Post by: IstvanV on 2015.February.21. 16:38:20
Az mondjuk nem vilagos amit irtal, oke, hogy a DE, HL is modositando az LDI altal, de ha kimaradna a BC nem lenne gyorsabb a csak LDI-t hasznalok jellegu felhasznalasnal?

Úgy értettem, hogy az LDI nem feltétlenül lenne gyorsabb, mint 16 ciklus, mert a +2 ciklus idő az utasítás végén valószínűleg a DE növelése miatt nem volt elkerülhető. A BC csökkentését pedig más műveletekkel párhuzamosan (pl. (HL) olvasása közben) is el lehet végezni.
Title: Re: Assembly programozás
Post by: lgb on 2015.February.21. 16:49:32
Úgy értettem, hogy az LDI nem feltétlenül lenne gyorsabb, mint 16 ciklus, mert a +2 ciklus idő az utasítás végén valószínűleg a DE növelése miatt nem volt elkerülhető. A BC csökkentését pedig más műveletekkel párhuzamosan (pl. (HL) olvasása közben) is el lehet végezni.

Aha, hat ezt nem tudom ... Az biztos, hogy egy normal 16 bites osszeadas/kivonas az kegyetlen lassu Z80-on, de mint megtudtam valojaban 4 bites ALU-ja van, tehat annyira nem meglepo. Gondolom, azert olyan helyeken ahol vmit eggyel csokkenteni vagy novelni kell (INC/DEC jellegu dolgok) azt nyilvan nem az ALU-n at csinalja, mert kulonben az LDI szuper lassu lenne, arrol nem is beszelve, hogy a PC-t is novelni kell ugye "eleg gyakran" mas opcode-oknal is :) A PC novelesere tenylegesen szoktak kulon inkrementalot beepiteni es az ALU-t nem bizeralni, esetleg INC/DEC op-okra is, de az LDI azert volt nekem gyanus, mert ott azert osszesen harom regiszternel van inc/dec mikozben megcsinalja. Bar akkor ezek szerint, nem kell ezt a harmat egyszerre csinalnia, parhuzamosithatja is oket mas muveletekkel, akkor meg igazad lehet, es sokat nem oszt, nem szoroz. Azert nekem az x86 megkozelites sem tunik tul rossznak, hogy van pl kulon REP "utasitas" es vegulis tobb mindent is moge irhatsz. Igaz, igy a kod lassabb lesz. Lehet az LDIR is lassabb lenne ilyen formaban, abba a 21-16=5 ciklusba valszeg nem ferne bele, a legelemibb utasitas (NOP) is 4 ugye ...
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.04. 09:47:46
Jól látom, hogy a Z80-ban nincsen
CALL HL
CALL IX
CALL IY
utasítások?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.04. 09:50:12
Jól. De könnyen helyettesíthető

CALLHL: JP (HL)
CALLIX: JP (IX)
CALLIY: JP (IY)

És a megfelelő rutinra CALL.
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.04. 16:47:45
Ez igaz, de a helyettesítés esetén kell egy push, ami előtt még a visszatérési címet is számolni kell.
 Ezzel a kódunk megint mozgathatatlan lesz. Másrészt, akkor eggyel több utasítást használtam. Így sokat veszítek.
 Kíváncsi vagyok, hogy a kibővitett Z80-as utasításkészletben (köv. generációs Z processzoroknál) ezt orvosolták-e?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.04. 16:51:34
Mért kéne PUSH?
Title: Re: Assembly programozás
Post by: lgb on 2015.May.04. 16:52:33
Ez igaz, de a helyettesítés esetén kell egy push, ami előtt még a visszatérési címet is számolni kell.

Miert kene push? A CALL a verembe beteszi a cuccost, igy ha majd RET-re fut, akkor az utan fog visszaterni. Igaz, a CALL ezek utan egy pl JP (HL)-re ugrik, ami aztan tovabb, de ez lenyegtelen, a lenyeg, hogy imho, a CALL nn, majd nn: JP (HL) az pontosan azt csinalja amit a CALL (HL) csinalna, ha lenne olyan, nem kell oda egy push ...

Amugy maga a JP (HL) is fura syntaxis, mivel a logikus a JP HL, a (..) altalaban indirekt cimzest jelentene, azaz ugorjon arra a cimre, amit a HL altal megadott memoria cim tartalmaz, de ugye itt nem errol van szo :) En ezert (is) mindig inkabb JP HL-t irok csak, ezt amugy az sjasm el is fogadja.[/quote]
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.04. 17:13:54
Tudtommal a CALL xxx azt csinálja, hogy eltárolja a soronkövetkező memóriacímet a verembe, és az xxx re ugrik.
EP nél nincs CALL HL utasítás.
Zozo szerint ez helyettesíthető JP HL -lel.
Erre mondtam, hogy az nem ugyanaz, mert a JP nem ment a verembe. Ahhoz, hogy CALL HL-t helyettesítsen, kell a PUSH is.
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.04. 17:15:58
Már látom, hogy a gyorsolvasásban elvétettem a "és a megfelelő rutinra CALL" mondatot. Nem láttam elnézést.
De így megint  értékes órajeleket veszítek, mert az ugróutasítás lassabb.
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.May.04. 19:07:50
A nem hivatalos utasítás készletben nincs jelen?

egyébként milyen környezetbe,rutinba kellene a CALL HL, CALL IX, CALL IY?

valami generál egy HL értéket és azt hívja meg PL.:?

Esetleg egy PL.:
   ...
   CALL CALL_HL
IDE
   ....

CALL_HL
    LD HL,12345
    ADD HL,DE
    PUSH HL    ;HL=13000
    RET

org 13000
    ...
    ...
    ...
    RET    ;IDE     tér vissza
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.04. 19:11:29
A nem hivatalos utasítás készletben nincs jelen?
Nincs. Újabb (Z80 kompatibilis) prociban sem.
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.04. 21:10:27

egyébként milyen környezetbe,rutinba kellene a CALL HL, CALL IX, CALL IY?

valami generál egy HL értéket és azt hívja meg PL.:?


 Tegyünk egy gondolatkirándulást:
 Vegyünk egy multitaszkos OP rendszert, mint a sokat emlegetett SymbOS.
 Mondjuk szeretnék futtatni egyszerre több pici programot, amik csak 300 Byte-osak, de nagyon sokan vannak.
 Mindegyik relatív ugrásokkal bír belül. A karakteres kiíráshoz, vagy bill. bekéréshez pedig az OP rendszert hívja RST rutinnal. Tehát semmi abszolut címzés nincsen benne.

 Ugye ilyenkor betöltöm a lemezről a programokat valahova. Meg a másikat megint máshova, míg a végén van 30 segédprogramom a memóriámban. Minden segédprogram helyét eltároltam egy tömbbe.
 Hogy hívjam meg őket gyorsan, és kapjak visszatérési értéket, ha nincs CALL HL utasításom?

 Természetesen újra hallom Zozo hangját, ahogyan javasolja a JR utasítást. De azért vegyük le a kalapunkat, és valljuk be, ez nem az igazi.
Title: Re: Assembly programozás
Post by: lgb on 2015.May.04. 22:55:38
Tegyünk egy gondolatkirándulást:
 Vegyünk egy multitaszkos OP rendszert, mint a sokat emlegetett SymbOS.
 Mondjuk szeretnék futtatni egyszerre több pici programot, amik csak 300 Byte-osak, de nagyon sokan vannak.
 Mindegyik relatív ugrásokkal bír belül. A karakteres kiíráshoz, vagy bill. bekéréshez pedig az OP rendszert hívja RST rutinnal. Tehát semmi abszolut címzés nincsen benne.

 Ugye ilyenkor betöltöm a lemezről a programokat valahova. Meg a másikat megint máshova, míg a végén van 30 segédprogramom a memóriámban. Minden segédprogram helyét eltároltam egy tömbbe.
 Hogy hívjam meg őket gyorsan, és kapjak visszatérési értéket, ha nincs CALL HL utasításom?

 Természetesen újra hallom Zozo hangját, ahogyan javasolja a JR utasítást. De azért vegyük le a kalapunkat, és valljuk be, ez nem az igazi.

Attol fugg. Ha co-operativ multitask akkor onkent lemondanak az idoszeletukrol a process-ek. Ilyen pl a RiscOS. Hatranya, hogy egy "task" siman lezuzza az egeszet, ha ugy dont, hogy o rossz fiu lesz, vagy csak programozasi hiba, es nem adja at a vezerlest. Masik hatrany, hogy ennek tudataban kell irni ala programokat. A preemptive multitask viszont ugy mux, hogy van egy hardware timer, ami eleg surrun (pl masodpercenkent 50-szer) interrupt-ot general. Az interrupt handler fogja, es lementi a regisztereket (a PC is megvan, ha verembol kiveszi hol volt), visszatolti egy masik task elmentett cuccat, es oda ter vissza. Legegyszerubb esetben vmi round-robin szeru "korbe megyunk a task-ok kozott" cuccos. Ezt szokas esetleg megfejelni nemi prioritassal, pl hogy egy adott prioritasu task csak akkor kapja meg a vezerlest, ha egy nagyobb prioritasu nem szeretne szinten futni. Igy mux a SymbOS is pl. Annak felepitese alapvetoen mikrokernel, azaz a kernel (benne az emlitett CPU scheduler, ami csinalja ezt a valtogatast) minimalis, a konkret OS funkciokat is "taskok" latnak el, csak ezek system minositesuek es altalaban magasabb prioritassal rendelkeznek, mint a "user" minositesuek. A masik kernel tipus a monolitkus kernel, ahol a kernel funkciok egyben a kernel reszei.

A lenyeg, nem kell semmi JP izebize ehhez tulsagosan.

Olyannal nem szoktak tokolni, hogy csak relativ cimzes/ugras legyen benne, helyette a betoltheto programokban van egy relokacios tabla, ami alapjan az OS at tudja irni a nem relativ cimzeshez kapcsolodo byte-okat, ami akar adat is lehet (pl egy tablazatban memoriacimek).
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.04. 22:58:56
a betoltheto programokban van egy relokacios tabla, ami alapjan az OS at tudja irni a nem relativ cimzeshez kapcsolodo byte-okat
Erre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).
Title: Re: Assembly programozás
Post by: lgb on 2015.May.04. 23:00:31
Erre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).

Jah, de ez mar implementacio kerdese, hogyan oldod meg, nem feltetlen tabla stb, a lenyeg, hogy nem kell "kerulni" a nem relativ cuccokat, eleg egy megoldas, hogy ezeket a konkret betoltesnel relokalni lehessen a megfelelo helyre :)
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.May.05. 17:21:52
Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.

Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.
Title: Re: Assembly programozás
Post by: lgb on 2015.May.05. 21:17:49
Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.

Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.

Kulonbozo dolgokrol beszelunk. x86-oson (legyen most 8088 az egyszeruseg kedveert, 80286, majd 386-on stb mar egeszen meg van ez kutyulva protected moban) egy "lap" (inkabb szegmensnek hivjak) mindig 64K, az a 16 byte az, hogy minden 16. byte-on kezdodik egy voltakepp. Azaz a fizikai cim egyenlo a szegmens cim szorozva 16-al (azaz balra shift-elve 4-szer, ugyanaz) plusz az offset. 8088 egy darab (64K meretu) szegmenst kepes latni, igaz kulon kodra, adata, veremre, illetve egy extra celra (persze allithato mindegyik uarra). EP-n ugye a 16K-s szegmensekbol lehet 4-et belapozni a Z80 cimtartomanyaba, es nem fugg attol aztan, hogy a hozzaferes celja mi (kod/adat/verem/stb). 286-ostol kezdve egy szegmens merete nem feltetlen fix, hanem 64K-nal kisebb is lehet, es hw szintu hozzaferes korlatozas is van (ie "biztonsagos" oprendszerhez), itt a szegmensek mar 16Mbyte-ban kevereghetnek, es a szegmensregiszterek un szelektorokat tartalmaznak, ami a GDT vagy LDT-ben (globalis/lokalis deszkriptortabla) irja le a szegmenseket. 386 es folotte a szegmensmeret alapjat byte-tol lapra (4K) lehet modositani, igy egy szegmens nagyobb lehet, mint 64K mar, es 32 bites cimzessel persze ezt ki is lehet hasznalni. Hozzatennem, hogy valojaban modern OS-ek nem igazan hasznaljak tul sok mindenre a szegmentalasi modelt, helyette az un lapozas technikat alkalmazzak (ez nem uaz a lap mint a fenti lap, meg a szegmentalas, itt fix meretu 4K-s lapok vannak, meg laptablak, de ebbe ne menjunk bele itt szerintem), ami csak 386-os ota van x86-ban. Mas ISA-kon meg mas dolgok is elfordulnak persze, nem csak x86 letezik.

Szoval x86-oson nem "16 byte-os lapok vannak" :) Max real modban a szegmensek kezdetehez van koze annak a bizonyos 16 byte-nak. Valoban, ha egy "primitiv" OS-t veszel (nem multitask, miegymas) akkor elonyos az x86, lassuk pl a CP/M-bol orokolt stuffokat a DOS-ban: a programok a 100h cimre toltodnek be stb. Remek, mondhatni, mert egy 64K-s szegmens "belulrol" offset szinten "ugyanaz" fuggetlenul attol, hogy a szegmens hol kezdodik, es "majdnem" barhol kezdodhet, max 15 byte memoriat pazarolunk el. Az adott szegmensen belul pedig a 100h mindig 100h, az hogy a fizikai memoriaban ez hol van, az mas kerdes.

Node, amit szerintem te keversz, hogy "hogyan oldottak meg". Tuby128 modern, multitask peldat hozott fel, azt meg relokalni szoktak x86-oson is persze. Ha erdekel megmutatom hogy kell, Linux alatt kozvetlenul assembly-ben is dolgoztam sokaig anno. Az nyilvanvalo viszont, ha nem modern peldat veszel, akkor mas az abra. 8088-on nehez "modern" peldat venni, de Z80/EP-re pl ott a SymbOS. Nyilvan relokalni kell, ha nem akarsz elveszteni egy egesz 16K-s teruletet mert "fix" ertekekkel dolgozol. Ahogy irtam, modernebb x86-osokon is reloaklnak termeszetesen, sot nem is igazan hasznalnak szegmenseket, mert minek: megnehezitik azt, hogy a process-ek (megfelelo engedely birtokaban) pl IPC-t csinaljanak (InterProcess Communication) stb.

Masreszt ezt nem "assemblerben" szoktak megoldani, hanem az adott toolchain object file formatuma hordozza az osszes szukseges infot ami segitsegevel a linker ebbol valamit eloallit. Ami adott esetben lehet PIC (Position Independent Code) jellegu kod is akar. Tehat nem neked kell gondoskodni feltetlen, a relokaciorol, azt majd az OS megteszi. Ehhez persze vmi info kell neki az igaz,

EXOS-nal nyilvan alapvetoen szinte alomnak tunt a 4Mbyte cimtartomany, nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol, stb. De amugy ha mar itt tartunk, ahogy Zozo is emlitette, van am EXOS-ban is ilyesmi, hogy relokacio, ha jol remlik a "relocatable system extension" ami talan a 7-es (?) tipusu az exos file header szerint. Szoval meg csak SymbOS-re sincs feltetlen szukseg, mint "modern" pelda :)

No, remelem igy ertheto.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.05. 21:37:34
nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol,
ROM-nál nem, de RAM-nál igen, erre szolgál az említett 7-es fejlécű áthelyezhető rendszerbővítő, ill (a fájl formátum szinten azonos) 2-es fejlécű felhasználói áthelyezhető modul, amit pl. betölthető a BASIC bővítések használnak.
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.05. 21:41:49
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.05. 21:50:26
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?
Így is lehet mondani... lényegében igen, de nem csak ilyen utasításoknál lehet áthelyezhető cím.

"Amikor a rendszer egy abszolút byte betöltése tételt talál, akkor a soron következő 8 bitet tárolja a címszámláló aktuális címére, és e számláló tartalmát megnöveli eggyel. Amikor egy áthelyezhető szó betöltése tételt talál, akkor beolvassa a soron következő 16 bitet és az aktuális címszámláló tartalmát ezekhez hozzáadja. Az eredményül kapott szót - először az alsó byte-ot beírva - tárolja a címszámláló címére, majd a címszámláló tartalmát megnöveli kettővel."
Title: Re: Assembly programozás
Post by: Tuby128 on 2015.May.05. 21:58:32
És hogyan tesz különbséget data és program közt. Hisz datacsomagban is lehet ugrásnak vagy hozzáférésnek látszódó kód. Hogy nem keveredik meg, ha van egy kis "lyuk" két végrehajtandó rutin közt?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.05. 22:02:48
Így. (http://www.ep128.hu/Ep_Konyv/Exos.htm#45)
Title: Re: Assembly programozás
Post by: lgb on 2015.May.05. 22:15:38
Eltekintve most az EXOS (amugy ugyes) hasonlo formatumatol, "hazilag" amator modon pl lehet csinalni ilyet ugy, hogy leforditjuk az asm projectunket org X-szel, majd org Y-al. Ahol az eredmeny elter, ott nyilvan arrol van szo, hogy pozicio fuggo kod/adat akarmi van. Ha az X egyenesen nulla volt, akkor eleg tarolni azt, es megjegyezni hol kulonbozott a masiktol es hozzaadni annyit, ahova relokalni akarod. Ez persze tulegyszerusitett pelda, es gyakorlatban akkor jo, ha 256 byte-os hataron akarod tartani a cuccost, kulonben kell kulon low/hi byte-kkal is esetleg foglalkozni, stb. Ez persze az "amator" megoldas, fejlettebb assembler-ek tudnak olyan output-ot eleve ami hordot ilyen informaciot, aztan a linker dolga ebbol vmit gyakrtani, ami persze szinten lehet vmi relokalhato formatum persze! Viszont a fenti pelda mutatja, hogy nem kell tul nagy varazslat ide, ha a legegyszerubb esetbol indulunk ki legalabbis :)
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.May.07. 17:23:47
Házilag is egyszerű csak külön értelmezöt kell készíteni.
Az EXOS "7" fejléce? akár az ASMON tud ilyet készíteni.
Csináltam is ilyet mégpedig ha jól emlékszem valami ":color"
bővítményt alakítottam át mert a program nemvolt több mint pár száz bájt de egy teljes szegmenst (16536 bájt) lefoglalt.
Akkor még nem értettem ezekhez a csomagokhoz de mennél több programot értelmeztem annál egyszerűbbnek tűnnek.
Egyébként meg egyszerűbb megoldás is van ha csak 300 bájtos rutinokat gyártanál.
Elemez PL. a fájl tömörítőt. ".DTF" ???
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.May.09. 07:30:15
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?

De nem csak ezeknél még az esetleg "LD HL,xxxx" és társai használatakor is.

Én úgy csinálnám a pogikat, hogy lefordítanám "ORG 0000h" majd azokat az utasítás címeket amelyeket módosítani kell egy táblázatba tenném és a *.bin elejére tenném.
Így betöltés után módosítom azokat amiket kell, szimplán hozzá adva a program kezdőcímét.
És végül másolom a módosított programot a kiválasztott kezdőcímre.
Title: Re: Assembly programozás
Post by: Povi on 2015.May.20. 16:59:03
geco, ez az az oldal, ahol az integer to ASCII konverziós rutin (is) van, erről beszéltem neked a találkozón:
http://map.grauw.nl/sources/external/z80bits.html#5.1
Title: Re: Assembly programozás
Post by: lgb on 2015.May.20. 17:09:27
geco, ez az az oldal, ahol az integer to ASCII konverziós rutin (is) van, erről beszéltem neked a találkozón:
http://map.grauw.nl/sources/external/z80bits.html#5.1

Na, ezt nem garantalom, hogy megy, mar regebben irtam (de en is a fenti otlet alapjan), most epp el kene gondolkodnom, hogy tuti jo-e :) Lenyege, hogy a szam elejen levo nullak helyett szokoz van. A celom az volt, hogy minden szam azonos mennyisegu helyet foglaljon, tehat nem "lenyelem" a kezdo 0-kat, hanem szokozt irok helyette.

Code: ZiLOG Z80 Assembler
  1. ; IX = memory address to write ASCII result
  2. ; HL = number
  3. printdec10:
  4.         LD      DE, $3020 ; leading zero elimination D=must be ASCII code of '0', E = print this if it would print '0' (overriden later to '0' after a non '0' digit, or last digit)
  5.         ld      bc,-10000
  6.         call    .digit
  7.         ld      bc,-1000
  8.         call    .digit
  9.         ld      bc,-100
  10.         ld      A, B ; B set to $FF, faster to transfer to A, than call .digit to set by constant
  11.         call    .div10
  12.         ld      c,-10 ; B is already $FF, no need to set BC, only C (we can do 8 bit math here already as with the next, but I don't need such an "extreme" optimisation)
  13.         LD      A, B
  14.         call    .div10
  15.         ld      a, d ; last digit follows (avoid using the 16 bit stuff here, also zero is printed always, as the last digit!)
  16.         or      l       ; convert to ASCII (always, even with value of zero)
  17.         ld      (ix), a
  18.         inc     ix
  19.         ret
  20. .digit: ld      a, $FF
  21. .div10: inc     a
  22.         add     hl,bc   ; actually this is SUB but BC is "negative", since there is no real 16 bit SUB on Z80 without Carry (only SBC)
  23.         jr      c,.div10        ; based on result of ADD HL,BC
  24.         jr      z, .zero        ; based on result of INC A (ADD HL,BC does not affect Zero flag)
  25.         LD      E, D    ; set conversion mask to ASCII in case of non-zero digit! (further zeroes are zeroes also, not space)
  26. .zero:
  27.         SBC     HL, BC ; "overrun" by the loop, Carry=0 here, ok to use SBC to "roll back" the last ADD
  28.         OR      E ; convert A to ASCII _or_ SPACE
  29.         LD      (IX), A
  30.         INC     IX
  31.         RET
  32.  
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.May.20. 17:11:24
Ilyesmire egyébként ott van a Hsoft féle full extrás NUMSTR rutin gyűjtemény is.
Title: Re: Assembly programozás
Post by: geco on 2015.May.20. 18:52:01
geco, ez az az oldal, ahol az integer to ASCII konverziós rutin (is) van, erről beszéltem neked a találkozón:
http://map.grauw.nl/sources/external/z80bits.html#5.1
Köszi szépen el is tárolom :)
Title: Re: Assembly programozás
Post by: Povi on 2015.June.01. 15:52:49
közben megnéztem, hogy csinálja a HiSoft Pascal az egész szám kiírását, de az is kivonásokkal csinálja a 10-zel osztást:
Code: [Select]
;WRITE(e)       
;writes an INTEGER number
  ;input: e in HL
l05e5:  bit     7,h
        jr      z,l05f5          ;jump, if HL>0
        ld      a,"-"
        call    WriteChar_L0112
        or      a
        ex      de,hl
        ld      hl,0
        sbc     hl,de
l05f5:  ld      iy,l061f
        ld      bc,0530h        ;B=5 C="0"
l05fc:  ld      a,"0"
        ld      e,(iy+00h)
        ld      d,(iy+01h)
l0604:  or      a
        sbc     hl,de
        jr      c,l060c
        inc     a
        jr      l0604
l060c:  add     hl,de
        cp      c
        jr      z,l0614
        call    WriteChar_L0112
        dec     c
l0614:  inc     iy
        inc     iy
        djnz    l05fc
        cp      c
        ret     nz
        jp      WriteChar_L0112
l061f:  dw      10000
        dw      1000
        dw      100
        dw      10
        dw      1
Title: Re: Assembly programozás
Post by: lgb on 2015.June.01. 19:30:05
Nem akarok teljesen hulyenek tunni, de milyen eletkepes alternativa van meg a 10-es kivonogatason kivul? Amire en gondoltam esetleg: logaritmikus kereses alapjan, tehat ugye 4db osszehasonlitassal elvileg meg lehet mondani, hogy melyik szamjegy az. Csak igy a kod lesz csunyan nagy, mert ugye a kulonbozo 10-es helyiertekeknel kulon le kell kodolni. Van mas ertelmes modszer a decimalis kiiratasra, ami hatekony, es osztast nem kivonogatassal csinalja?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.June.01. 20:04:10
Ilyesmire egyébként ott van a Hsoft féle full extrás NUMSTR rutin gyűjtemény is.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.June.01. 20:13:32
Ez meg az EXDOS-é:
Code: ZiLOG Z80 Assembler
  1.                 SUBTTL  D16
  2.  
  3. ;******************************************************************************
  4. D16::
  5. ;
  6. ; Displays the 16-bit number in HL.
  7. ;
  8. ;
  9.                 PUSH    HL              ; Save number.
  10.                 PUSH    IY
  11.                 CALL    @CLIOB          ; HL -> output buffer.
  12.                 LD      C,L
  13.                 LD      B,H
  14.                 POP     HL
  15.                 LD      DE,SIZEE##+3
  16.                 ADD     HL,DE           ; Point to 32-bit number buffer.
  17.                 POP     DE              ; DE=number to print.
  18. DERRN:          XOR     A               ; No leading character.
  19.                 LD      (HL),A          ; Zero most significant word.
  20.                 DEC     HL
  21.                 LD      (HL),A
  22.                 DEC     HL
  23.                 LD      (HL),D          ; Put number into buffer.
  24.                 DEC     HL
  25.                 LD      (HL),E
  26.                 EX      DE,HL           ; DE->number.
  27.                     ;
  28.                     ;
  29.                     ;
  30. ;
  31. ;
  32. ;
  33.                 SUBTTL  D32
  34.  
  35. ;******************************************************************************
  36. D32::
  37. ;
  38. ; Displays a 32-bit number at (DE) in up to 8 characters, using the character
  39. ; in A as the leading character, or A=0 if none required. The number at (DE)
  40. ; is corrupted, as are HL, BC, HL', DE' and AF'.
  41. ;
  42. ; The number is displayed by subtracting reducing powers of ten from a table.
  43. ; This avoids a 32 by 16 divide by ten, and produces the digits in the required
  44. ; order.
  45. ;
  46. ; This routine is used from the DIR command to print the file sizes. In this
  47. ; case, the numbers are always less than 9 decimal digits, so the power of ten
  48. ; table starts with 10,000,000. In other cases, the routine is used from D16,
  49. ; to print a 16-bit number without leading characters. Thus a larger power of
  50. ; ten table is not needed.
  51. ;
  52. ;
  53.                 EXX
  54.                 LD      E,A             ; E=lead char.
  55.                 LD      D,'0'           ; D='0' to save bytes.
  56.                 EXX
  57.                 LD      HL,P10TAB       ; Giant 32-bit power-of-ten table.
  58. ;
  59. D32.10:         LD      A,(HL)          ; LSB from table.
  60.                 DEC     A               ; Last entry ?
  61.                 JR      NZ,D32.20       ; Go if not.
  62. ;
  63.                 EXX                     ; Else force leading char to '0'.
  64.                 LD      E,D
  65.                 EXX
  66. ;
  67. D32.20:         XOR     A               ; Divide by subtraction, Cy clear.
  68.                 LD      C,A             ; Subtraction count.
  69. ;
  70. D32.30:         PUSH    HL              ; Save table pointer.
  71.                 PUSH    DE              ; Save number pointer.
  72.                 LD      B,4             ; Iteration count.
  73. ;
  74. D32.40:         LD      A,(DE)          ; Subtract no. in table.
  75.                 SBC     A,(HL)
  76.                 LD      (DE),A
  77.                 INC     HL
  78.                 INC     DE
  79.                 DJNZ    D32.40
  80. ;
  81.                 POP     DE
  82.                 POP     HL
  83.                 INC     C
  84.                 JR      NC,D32.30
  85. ;
  86.                 CALL    ADD32           ; Add back last iteration.
  87.                 LD      A,C             ; Get iteration count.
  88.                 EXX
  89.                 DEC     A               ; Adjust for last iteration.
  90.                 JR      Z,D32.60        ; Go if possible leading zero.
  91. ;
  92.                 ADD     A,D             ; Else convert to ASCII.
  93.                 LD      E,D             ; Set leading char to '0'.
  94.                 CODE    MVI L           ; Skip to print char.
  95. ;
  96. D32.60:         OR      E               ; Leading char required ?
  97.                 CALL    NZ,OUCH         ; Print it if yes.
  98. ;
  99.                 EXX
  100.                 LD      A,(HL)          ; End of table (FF) ?
  101.                 INC     A
  102.                 JR      NZ,D32.10       ; Print next digit if not.
  103.                 RET                     ; With A=0.
  104. ;
  105. ;
  106. P10TAB:         DEFW    9680H,98H       ; 10,000,000
  107.                 DEFW    4240H,0FH       ; 1,000,000
  108.                 DEFW    86A0H,1         ; 100,000
  109.                 DEFW    2710H,0         ; 10,000
  110.                 DEFW    3E8H,0          ; 1,000
  111.                 DEFW    64H,0           ; 100
  112.                 DEFW    0AH,0           ; 10
  113.                 DEFW    1,0             ; 1
  114.                 DEFB    0FFH            ; End of table.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.June.01. 23:27:06
Nem akarok teljesen hulyenek tunni, de milyen eletkepes alternativa van meg a 10-es kivonogatason kivul?

Én sem akarok teljesen hülyének tűnni, de mit szólnál a helyiérték bitekhez tartozó decimális konstansok iteratív szimbolikus összeadáshoz?
Title: Re: Assembly programozás
Post by: Povi on 2015.June.02. 09:41:00
Ez meg az EXDOS-é:

Zozo, ezt te disassembláltad és kommentezted fől, vagy ez az eredeti IS kód?
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.June.02. 09:47:59
Zozo, ezt te disassembláltad és kommentezted fől, vagy ez az eredeti IS kód?
Ez az eredeti.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.June.02. 09:51:02
Az én verzióm :-)
Code: ZiLOG Z80 Assembler
  1.         ;DE-ben megadott 16 bites érték konvertálása a szövegpufferbe
  2.         ;a bevezető nullákat levágja
  3.         ;HL számpufferre mutat
  4.  
  5. lf1f4:  XOR     A
  6.         LD      (HL),A          ;számpuffer
  7.         DEC     HL              ;felső 16 bitje
  8.         LD      (HL),A          ;nullázva
  9.         DEC     HL
  10.         LD      (HL),D          ;érték
  11.         DEC     HL              ;letárolva
  12.         LD      (HL),E          ;a számpufferbe
  13.         EX      DE,HL           ;DE mutat a számpufferre
  14.  
  15.  
  16.         ;számpufferben megadott 32 bites érték konvertálása a szövegpufferbe
  17.         ;a bevezető nullákat levágja
  18.         ;DE számpufferre mutat
  19.         ;A=bevezető karakter kódja, 00H esetén nem ír ki semmit
  20.  
  21. lf1fd:  EXX    
  22.         LD      E,A             ;0, jelzi, hogy nulla eredmény esetén
  23.                                 ;még bevezető nulláról van szó
  24.         LD      D,30H           ;"0"
  25.         EXX    
  26.         LD      HL,lf233        ;számkonstansok táblázatára mutat
  27. lf205:  LD      A,(HL)         
  28.         DEC     A               ;=1? vagyis a táblázat legkisebb eleme?
  29.         JR      NZ,LF20C        ;ugrás ha nem
  30.         EXX                     ;ha igen
  31.         LD      E,D             ;E="0" mindenképpen kiírja a nulla eredményt is
  32.         EXX                      
  33.  
  34.         ;32 bites osztás (DE)/(HL)
  35.         ;C=az osztás eredménye, (DE)=maradék
  36.      
  37. lf20c:  XOR     A               ;C flag törlése
  38.         LD      C,A             ;C=0
  39.        
  40.         ;az osztást kivonással hajtja végre, amíg negatív nem lesz
  41.  
  42. lf20e:  PUSH    HL
  43.         PUSH    DE
  44.         LD      B,04H           ;4 bájton kell elvégezni a műveletet
  45. lf212:  LD      A,(DE)          ;csökkentendő bájt
  46.         SBC     A,(HL)          ;kivonás
  47.         LD      (DE),A          ;letárolás
  48.         INC     HL              ;mutatók
  49.         INC     DE              ;növelése
  50.         DJNZ    LF212           ;művelet elvégzése a többi bájton
  51.         POP     DE              ;eredeti mutatók
  52.         POP     HL              ;vissza
  53.         INC     C               ;eredmény növelése
  54.         JR      NC,LF20E        ;újabb kivonás, ha még nem negatív az eredmény
  55.         CALL    LF254           ;(DE)+(HL), az utolsó kivonás visszacsinálása
  56.                                 ;így (DE)-ben a maradék lesz
  57.                                 ;HL=HL+4, a következő konstansra mutat
  58.  
  59.         LD      A,C             ;eredmény A-ba
  60.         EXX    
  61.         DEC     A               ;eredmény csökkentése eggyel
  62.                                 ;a visszacsinált kivonás miatt
  63.         JR      Z,LF229         ; (+03h)
  64.         ADD     A,D             ;A+"0", vagyis az eredmény ASCII
  65.                                 ;karakterré konvertálása
  66.         LD      E,D             ;E="0", vagyis ha volt már egy értékes
  67.                                 ;karakter, innentől kezdve kiírja a nulla
  68.                                 ;karaktereket is, a szám elején lévő
  69.                                 ;nullákat levágja
  70.         DB      2EH             ;töltelék bájt az OR E átugrásához
  71. LF229:  OR      E               ;nullás eredmény esetén megvizsgálja, hogy
  72.                                 ;bevezető nulláról, vagy már szám közben
  73.                                 ;lévő nulláról van szó
  74.         CALL    NZ,LF040        ;ha nem bevezető nulla, akkor karakter írása szövegpufferbe
  75.         EXX    
  76.         LD      A,(HL)          ;táblázat következő eleme
  77.         INC     A               ;=255? azaz lista vége?
  78.         JR      NZ,LF205        ;folytatás a következővel, ha még nincs vége
  79.         RET    
  80.  
  81. lf233:  DB      80H,96H,98H,00H ;00989680H=10000000
  82.         DB      40H,42H,0FH,00H ;000F4240H= 1000000
  83.         DB     0A0H,86H,01H,00H ;000186A0H=  100000
  84.         DB      10H,27H,00H,00H ;00002710H=   10000
  85.         DB     0E8H,03H,00H,00H ;000003E8H=    1000
  86.         DB      64H,00H,00H,00H ;00000064H=     100
  87.         DB      0AH,00H,00H,00H ;0000000AH=      10
  88.         DB      01H,00H,00H,00H ;00000001H=       1
  89.         DB      0FFH            ;lista vége
Title: Re: Assembly programozás
Post by: Povi on 2015.July.21. 10:12:04
flag bitekkel kapcsolatban kérdeznék

a CP és SUB utasításoknál a Sign bit ugyanúgy lesz mindig beállítva (vagy törölve), hogy a Carry is, ugye?
Title: Re: Assembly programozás
Post by: lgb on 2015.July.21. 11:24:06
flag bitekkel kapcsolatban kérdeznék

a CP és SUB utasításoknál a Sign bit ugyanúgy lesz mindig beállítva (vagy törölve), hogy a Carry is, ugye?

Ezt hogy erted? Most ugy altalaban (nem Z80 only) de szerintem ha pl 130-bol kivonsz egyet, akkor az eredmeny 129, am ez ugye azt is jelenti, hogy legfelso bit 1, azaz az eredmeny kettes komplemenses abrazolassal nezve negativ. Ugyanakkor carry nem volt. Ha viszont pl 10-bol vonsz ki egyet, akkor az eredmeny pozitiv, es carry ismet nincs. Vagy nem igy ertetted?
Title: Re: Assembly programozás
Post by: Povi on 2015.July.21. 11:35:17
igazad van
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.July.21. 21:22:11
Én másképp közelítem, nem egyesével vonom ki a 10 000, 1 000, 100, 10, 1

 LD IX,tizes számrendsze
 LD HL=nnnn
 LD DE=8000 ;decimális
 LD B,4
ezeres
   IF HL-DE>=0 THEN
     SET 0,(IX)
     HL=HL-DE
     (IX)=(IX)*2
   ENDIF
  DE=DE/2
  DJNZ  ezeres

 INC IX
 LD DE=800 ;decimális
 LD B,4
százas
   IF HL-DE>=0 THEN
     SET 0,(IX)
     HL=HL-DE
     (IX)=(IX)*2
   ENDIF
  DE=DE/2
  DJNZ  százas
  INX IX

 LD DE=80 ;decimális
 LD B,4
tízes
   IF HL-DE>=0 THEN
     SET 0,(IX)
     HL=HL-DE
     (IX)=(IX)*2
   ENDIF
  DE=DE/2
  DJNZ  tízes

 INC IX
 LD DE=8 ;decimális
 LD B,4
egyes
   IF HL-DE>=0 THEN
     SET 0,(IX)
     HL=HL-DE
     (IX)=(IX)*2
   ENDIF
  DE=DE/2
  DJNZ egyes

Még nem minden tiszta de valami ilyesmi
Úgy vélem ez gyorsabb megoldás lenne.
Remélem azért érthető.
Title: Re: Assembly programozás
Post by: Attus on 2015.July.22. 12:47:32
Ez milyen assembler?
A simában nincs osztás, szorzás, "if  then", legfeljebb makrózva.
Ez már egy magasabb szint.
A HL=HL-DE megfelelője is: sbc hl,de.
Title: Re: Assembly programozás
Post by: Povi on 2015.July.22. 13:33:04
Csináltam egy érdekes statisztikát, hogy melyek a leggyakrabban használt utasítások.
Először is megírtam az Intel 8008 emulációt PC-re is. Itt futtattam a SCELBI-t, majd egy nagyon egyszerű BASIC program futása után megnéztem, melyik utasításból hány futott le a "bekapcsolás" óta.

139508 utasítást darált le a proci:

11963 - CAL a16       // CALL
 9874 - LAM              // LD A,(HL)
 9706 - INL              // INC L
 7527 - RET
 6839 - LLI              // LD L, xx
 5010 - DCB           // DEC B

Z80-nál nyílván más lenne az eredmény, főleg az INC L sokkal hátrébb foglalna helyet, de mivel itt nincs INC HL, kénytelenek külön növelni az alsó- és felső-bájtot (ha kell)

Az EP emu-ba érdekes lenne egy ilyen statisztikát számoló részt belerakni...
Title: Re: Assembly programozás
Post by: lgb on 2015.July.22. 15:16:33
Ez milyen assembler?
A simában nincs osztás, szorzás, "if  then", legfeljebb makrózva.
Ez már egy magasabb szint.
A HL=HL-DE megfelelője is: sbc hl,de.

Szerintem ez kb "pseudo-kod" akart lenni, azaz kozvetlenul persze nem fordithato igy le, ilyet csinal az ember, ha pl csak fejben kepzeli el elso lepesben, es meg ki sem probalta :) Gondolom en ....
Title: Re: Assembly programozás
Post by: lgb on 2015.July.22. 15:24:58
Csináltam egy érdekes statisztikát, hogy melyek a leggyakrabban használt utasítások.

Kicsit off, de pl allitolag a 68060 (talan ...) tervezesenel is elemeztek rengeteg software-t, hogy megis milyen opcode-okat hasznalnak, es azt probaltak gyorsabba tenni, amik gyakrabban fordultak elo.
Title: Re: Assembly programozás
Post by: Attus on 2015.July.22. 16:22:53
Szerintem ez kb "pseudo-kod" akart lenni, azaz kozvetlenul persze nem fordithato igy le, ilyet csinal az ember, ha pl csak fejben kepzeli el elso lepesben, es meg ki sem probalta :) Gondolom en ....
Értem.:)
Title: Re: Assembly programozás
Post by: Ferro73 on 2015.July.22. 19:54:19
Ez milyen assembler?
A simában nincs osztás, szorzás, "if  then", legfeljebb makrózva.
Ez már egy magasabb szint.
A HL=HL-DE megfelelője is: sbc hl,de.
Nem is kezdtem ORG -al
Ez vázlat volt főleg az osztás és szorzás miatt  RRA vagy RLA nem mindegy.
Mivel már nem nap mint nap programozok ezek össze mosódnak.
Egyébként szerintem meglehetett értani, hogy mit akartam mondani.


Title: Re: Assembly programozás
Post by: Z80System on 2015.October.05. 23:42:09
Na, megint elolvastam a sjasm doksiját, elkezdett végre derengeni mit mire is szánhattak.

Van valakinek tapasztalata (0.42c -ről) mennyire lehet rajta számon is kérni amit a sjasm doksijában írogatnak ?

Mert a doksi mostani olvasásra egész megtetszett:

- Vannak benne ilyen "link -elésre" alkalmas funkciók, vagyis kívánságra kihagy nem használt kódrészeket, nem kell konfigolgatni, meg feltételesen fordítgatni, csak nem hívsz rá, és már nem is fordul be, meg bináris file -okat vagy azok részeit be tudod fűzni a végső kódba. Tud egy fordítás alatt több binárist is kipökni.

- Lehet benne multipage kódot írni, bármely lap kezdődhet bármely címen és lehet bármilyen hosszú, egy címkéről pedig bármikor megtudhatod hányas indexű lapon van. A kódokat automatizálva is tudja szétszórni a page -ek között.

- Címkéket tud hierarchizálni. Vagyis lehet sok "vissza" nevű címkéd is, ahol annak értelme van, és nem kell feltétlen globális címkeneveket használni, pld: "vissza876734", vagy "SpriteKirako_Atlatszo_MasodikUtem_301"

- Strukturák (és membereik természetesen) méretét és offszetjeit nyilván tarja, itt is van lokális névfeloldás.

- Mindenféle ördöngös makrók, és akár makróra lokális címkék.

- Mindenféle ismétlő funkció, amivel (akár makrókkal kombinálva) feleslegessé válhat a legtöbb esetben a ciklusmagok, egyéb kódok kilóméteres ismételgetése, egyszerűen azért mert fenti dolgokat és ezeket a funkciókat kombinálva ki tudod fejezni akár a módosulgató ismétléseket is. Az egész kicsit mintha el lenne rugaszkodva a direkt ASSEMBLY -től, mikor az ember utasításokat hekkel egymás után mnemonikokkal, inkább amolyan szkripteket írogat az ember, melyek kifejtik az utasításokat. Na nem mintha a pszeudó utasításokat a legegyszerűbb EP assembler is nem ismerte volna, sőt még egyszerűbb makrók is voltak némelyikben, de ezt a gazdagságot nyilván nem érték el.

- Megamitmég kihagytam ... pld. align -olások, meg ilyesmik ...


Szóval tetszik ... ha az ASMON vagy neadjisten a HEASS az egy tüchtig kis kéziszerszámos láda, akkor ez a sjasm egy modern gépesített szerszámműhely, CNC esztergával és maróval ... :)
Title: Re: Assembly programozás
Post by: geco on 2015.October.06. 08:48:27
Már a régebbi verzió is tudta ezek nagy részét, és úgy tudta, hogy nem csak a leírásban :D
Title: Re: Assembly programozás
Post by: lgb on 2015.October.06. 10:13:56
En nem tudok rola, hogy az sjasm tudna linkeleses dolgot, vagy ha igen, nem tudom hogy. Mert ugye a linkeles az lenne, hogy tobb asm forrasbol fordit egyenkent object kodot, az az object kodot tudja aztan linkelni egybe. Ilyet en is szeretnek, de nem tudok rola, hogy sjasm tudna ilyet, marad a fapados amator megoldas, hogy huszmillio include mindenhova :)

Sajna az sjasm doksija nekem kisse misztikus, nem tudom te hol talaltad, de amit weboldalon lattam, nehany oldal kesz sincs, stb ... Pl ez: http://xl2s.eu.pn/sjasmman1.html
Title: Re: Assembly programozás
Post by: sanyike on 2015.October.07. 21:36:21
Gépi kódban, hogy tudok a 254-es szegmensre írni?
spoke 254,n,255 - ezt hogy lehet megoldani?

_S
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.08. 06:56:45
XI. rész: A DAVE-chip programozása (http://www.ep128.hu/Ep_Konyv/Exos.htm#240)

Feltételezem a Z80 assembly megy. Nem kellene megismerkedni először a géppel mielőtt programozni kezdené az ember? Egyéni szoc probléma, de vércikinek találom amikor olyat kérdezek amit saját magam is kideríthettem volna. Bocsi!
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.October.08. 09:36:45
Gépi kódban, hogy tudok a 254-es szegmensre írni?
spoke 254,n,255 - ezt hogy lehet megoldani?
Pl:
Code: ZiLOG Z80 Assembler
  1. IN A,(0B3h)
  2. PUSH AF
  3. LD A,254
  4. OUT (0B3h),A
  5. LD HL,0C000h+n
  6. LD (HL),255
  7. POP AF
  8. OUT (0B3h),A

Ebben az esetben a 3-as lapra lesz ideiglenesen lapozva, ezért ott ne legyen éppen futó kód vagy verem. Természetesen másik lapra is lehet lapozni, értelemszerű módosítással.
Title: Re: Assembly programozás
Post by: sanyike on 2015.October.08. 10:40:18
XI. rész: A DAVE-chip programozása (http://www.ep128.hu/Ep_Konyv/Exos.htm#240)

Feltételezem a Z80 assembly megy.

Nem megy.

A BASIC is csak dereng, kb. 30 éve nem foglalkoztam vele :-)
Csak egy összehasonlítást szerettem volna végezni a végrahajtási sebesség tekintetében;
BASIC spoke - zippelt BASIC spoke - BASIC-be ágyazott gépikód

- , hogy tudjam melyik irányba induljak majd el.
Ez természetesen hobby, amire van napi kb fél. órám...

XI. rész: A DAVE-chip programozása (http://www.ep128.hu/Ep_Konyv/Exos.htm#240)

Egyéni szoc probléma, de vércikinek találom amikor olyat kérdezek amit saját magam is kideríthettem volna.[/s] Bocsi!

Szerintem egy fórumon nem "vérciki" kérdezni, de igazad van; ez az én szoc problémám...
Title: Re: Assembly programozás
Post by: sanyike on 2015.October.08. 10:41:33
Pl:
code=z80

Köszönöm Zozo!
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.October.08. 11:15:23
Szerintem egy fórumon nem "vérciki" kérdezni
Szerintem sem. Én még emlékszem milyen volt kezdőnek lenni.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.08. 16:55:53
Quote
Szerintem egy fórumon nem "vérciki" kérdezni, de igazad van; ez az én szoc problémám...

Á, csak ergoGnomik mindíg morog, fene tudja miért ... már rám is rámpirított párszor, de nem baj, nézzük a jó oldalát: legalább hozzáteszi ő is amije van.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.08. 18:43:32
OFF

Ez tényleg egy rossz szokásom, de néha nem bírok magamba fojtani ilyen kis hülyeségeket. Olvasom sanyike kérdését, ami alapján úgy véltem hogy gépi kódú programozásban azért tudja miről van szó. Na mármost, engem aztán még csak véletlenül sem lehet lángelmének (sőt, igazából még csak hozzá valamicskét konyítónak sem) nevezni, de azért annyit elég minimális energia befektetéssel sikerült már korábban megtudnom hogy mi az eljárás. Ebből sikerült arra az utólag tévesnek bizonyult következtetésre jutnom hogy megint valaki túl lusta.

Aztán persze még ott van az a kérdés hogy pontosan kinek a problémája a pontosan micsoda, de azt már tényleg felesleges feszegetni. Így is sikerült éppen elég felesleges értetlenséget (mivel nem volt világos mi a fene bajom van) és némi rosszallást fakasztanom a társaságban. Egyébként én is voltam "kezdő", és amikor sikerült orbitális hülyeséget vagy teljesen nyilvánvalót kérdeznem, akkor (legalább utólag) bizony elég kényelmetlenül éreztem magamat.

Még egyszer bocsi, bár én magam szoktam mondogatni hogy az emberi nyelvekben a legfeleslegesebb dolgok azok a szavak és kifejezések amivel utólag próbáljuk elsimítani a bántásokat és sértéseket, mivel azok már úgy is megmaradnak a lélekben, azokat a legőszintébb szó sem képes csak úgy nyomtalanul kitörölni.

Remélem legközelebb sikerül leülni egy sarokba és megvárni amíg elmúlik az újabb ilyen késztetés.

/OFF
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.08. 19:08:06
Mindenki mindig morog ... Én azt mondom, nem isznak a népek rendesen ! :)

Deci vörös, vagy 2 deci Ballantines, és máris mosolyog a nép ...
Title: Re: Assembly programozás
Post by: sanyike on 2015.October.08. 21:08:46
Ebből sikerült arra az utólag tévesnek bizonyult következtetésre jutnom hogy megint valaki túl lusta.



Nem lusta csak türelmetlen! :D

Na jó elismerem; ebben azért van egy kis igazad...

:smt006
Title: Re: Assembly programozás
Post by: sanyike on 2015.October.08. 21:11:57
... Én azt mondom, nem isznak a népek rendesen ! :)



Na erre igyunk!

:smt030
Title: Re: Assembly programozás
Post by: IstvanV on 2015.October.12. 19:31:50
Az EP emu-ba érdekes lenne egy ilyen statisztikát számoló részt belerakni...

[attachurl=1]

A debuggerben "Run" és aztán "Step" futtatja, minden 1000000. utasításnál kiírja a 10 leggyakoribb utasítás kódját, és hogy hányszor fordult elő.
Title: Re: Assembly programozás
Post by: Povi on 2015.October.13. 16:06:13
(Attachment Link)

A debuggerben "Run" és aztán "Step" futtatja, minden 1000000. utasításnál kiírja a 10 leggyakoribb utasítás kódját, és hogy hányszor fordult elő.

Hű, nagyon jó! :-)

Messze vezet az OR A!
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 19:30:09
Na, néztem ezt a sjasm -ot tovább.

Érti valaki hogy a cimkék hierarchizálása miért pont három szintű ?

Én eddig azt hittem, hogy akárhány szinten lehet a cimkéket hierarchizálni.

Ehelyett az van hogy vannak a module -ok (melyeket úgy tűnik kizárólag a cimkék hierarchizálásához vezettek be),
ezekhez relatívak (mely nem az értékük kiszámítását jelöli, csak simán a cimke névütközések feloldásával kapcsolatos) az ugynevezett "globális" cimkék,
és vannak a relatív cimkék, melyek pedig az előző globális cimkéhez képest relatívak.

Tehát a modulnevek globálisak, egymáshoz képest NEM! relatívak,
ezekhez relatívak a "globális" cimkék,
és a globális címkékhez képest pedig a lokális cimkék.

És passz.

De miért ? Ha már van relatív cimkenévfeloldás (és nem számítás!), akkor miért nem bízzák rám hány hierarchiaszintet akarok felvenni a cimkéimnél ?!
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 20:23:03
Paraszt ésszel azt gondolnám, hogy ennek valami a fordító felépítésében gyökerező oka lehet. Például a neveket nem valamilyen fastruktúrában tárolja, hanem három vektorban. De miért zavar ez téged? Miféle "perverzióra" készülsz amihez elengedhetetlen a tetszőleges mélységben egymásba ágyazható névminősítés? :) Nekem már az is elég rondának tűnik amikor három mélységben kell egy programban valamilyen objektumra hivatkozni és még esetleg a hivatkozás típusa sem azonos. Mondjuk ez utóbbi az sjasm esetében ki van zárva.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 20:37:12
Quote
Miféle "perverzióra" készülsz

Egyszerűen keresném a megoldást a kényelmes névválasztásra. Szeretnék valami ilyet:



Function0:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret



Function1:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret


Title: Re: Assembly programozás
Post by: geco on 2015.October.15. 20:39:15
Tegyél pontot a functionx alatti címkék elé, és a jr utasításban is a .-tal kiegészített címkét használd.
.Loopint:
.
.
.
   jr .Loopint
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 20:44:51
Quote
Tegyél pontot a functionx alatti címkék elé, és a jr utasításban is a .-tal kiegészített címkét használd.

A . csak relatívvá tesz egy cimket (cimke nevet). A relatív cimke pedig csak az előtte álló globális cimkéhez képest lesz relatív. Az előtte álló relatív cimkéhez képest nem.

Vagyis csak 3 szinten megoldás a module-globaliscimke-relativcimke hierarchikus szerkezet. Én meg nem 3 szinten szeretném szervezni (egyszerűsíteni, nem globálisan adni meg) a cimkéimet, hanem tetszőleges szinten.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 20:48:46
Milyen hulyeség ez a 3 ? Miért pont 3 ? Miért nem 2 vagy 7 ? Hol vagyunk az őskorban ? Biztos van itt vmi okosság, amit nem értek ...

Ha nem akarják megoldani hogy legyenek "névterek" akkor ne oldják meg, legyen minden globális és kész. Értem hogy minden globális.

Ha meg kezelni akarják a névterek kérdését, akkor kezeljék teljes mélységben, a programíró majd eldönti hány szinten akar hierarchizálni (akarja ágyazni a névtereit).

De csinálni névtereket, de csak három szinten ... ezmiarák ?


Kell itt lennie vmi okosságnak amit még nem értek ...
Title: Re: Assembly programozás
Post by: geco on 2015.October.15. 20:53:03
a 3 pont csak a ... akart lenni :ds_icon_cheesygrin:
A lényeg az, hogy a lokális címkéd elé tegyél pontot, az teszi lokálissá, és ha egy globális címke alól akarsz egy másik globális címke lokális címkéjére ugrani, akkor globális.lokális megadással megy az ugrás.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 20:56:09
Quote
a 3 pont csak a ... akart lenni :ds_icon_cheesygrin:

Nem geco, nem gondoltam, hogy a három egymás alá írt pontod jelent bármit is.

Értem, hogy mit mondtál a . -tal kapcsolatban,
és vagy nem igaz amit írok, vagy te nem értetted meg amit válaszként írtam.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 21:04:49
Egyszerűen keresném a megoldást a kényelmes névválasztásra. Szeretnék valami ilyet:



Function0:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret



Function1:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret
Ebben a konstrukcióban pontosan mi a probléma? Az hogy ütköznek a két függvényben a címkék nevei, vagy az hogy nem lehet rájuk pl.: Function0.LoopExt.LoopInt.LoopIntInt-ként hivatkozni?
Title: Re: Assembly programozás
Post by: geco on 2015.October.15. 21:08:29
Nem geco, nem gondoltam, hogy a három egymás alá írt pontod jelent bármit is.

Értem, hogy mit mondtál a . -tal kapcsolatban,
és vagy nem igaz amit írok, vagy te nem értetted meg amit válaszként írtam.
Bocs, nem vettem észre az egyik hozzászólásod, az miért fontos, hogy egy relatív címke az előtte lévő relatív címkéhez képest legyen relatív?
A példádból indultam ki, azt pedig jól lefedi a szimpla relatív címkés megoldás.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 21:21:27
Quote
Ebben a konstrukcióban pontosan mi a probléma? Az hogy ütköznek a két függvényben a címkék nevei, vagy az hogy nem lehet rájuk pl.: Function0.LoopExt.LoopInt.LoopIntInt-ként hivatkozni?

Quote
A példádból indultam ki, azt pedig jól lefedi a szimpla relatív címkés megoldás.

Az ütközés a baj. A példa meg simán lehet nem mutatta mit akarnék.

Ahogy beljebb taboltam a sorokat, azok akarnának lenni az elméleti címterek.
És mivel 4 mélységű, ezért ezt ha jól értam, akkor sjasm -al nem lehet kifejezni.

Tehát ha Function0 az egy sjasm module, és LoopExt az meg egy sjasm globális címke, akkor valójában LoopExt már nem lesz globális, hanem relatív lesz Function0 -hoz képest, vagyis LoopExt -et használhatom egy masik modulomban is (amely a Function1 lesz).

Eddig szupi.

Ha LoopInt -et pedig egy sjasm lokális címkének veszem fel (. -tal) akkor az lokális lesz az előtte álló globális címkéhez (LoopExt ugye), és akkor LoopInt nevet is használhatnám újra egy a pédában fel nem vett LoopExt2 globális címkéhez képest.

Eddig is szupi.

De itt elértük a hierarchiánk alját, mert a LoopIntInt név már megint csak egy sjasm lokális cimke lehet, mely ismét az előtte álló globális címkéhez képest lesz relatív. Ami még mindíg csak LoopExt.

És így hiába vennék fel egy LoopInt2 -t, a LoopIntInt név már el van sütve, LoopInt2 -n belül már nem lehetne újra LoopIntInt -em.
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 21:22:17
Egyszerűen keresném a megoldást a kényelmes névválasztásra. Szeretnék valami ilyet:



Function0:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret



Function1:

    LoopExt:

        LoopInt:

            LoopIntInt:

            jr LoopIntInt

        jr LoopInt

    jr LoopExt

    ret

Ezt most nem ertem. Function0 es Function1 legyen ilyen label, a tobbi ponttal kezdodo. Peldadban utkozes a ket FunctionX "alatt" levo pl LoopExt-ek kozott van, ez megoldodik, ha .LoopExt lenne, es akkor nincs utkozes. Nem vilagos, hogy azzal a megoldassal mi a baj, ui a peldadhoz pont remekul illene. De amugy:

http://xl2s.eu.pn/sjasmman3.html

Lasd "Reusable labels" resz, ha az jobban tetszik. Pl engem idegesit, hogy neha a cel pl csak egy utasitas atugrasa pl, vagy ketto, hasonlo. Itt idegesito, hogy emiatt cimket kell bevezetni, ezek a "reusable labels" dolgok legalabb egyszerubbnek tunnek. Bar az optimalis megoldas az lenne (szamomra, szerintem) ha lenne olyan, hogy pl: "JR Z, +2" vagy "JR Z, -2" (nyilvan csak pelda, a megfelelo szintaxisra nem biztos, hogy pont ez jo, sot ..." ami azt jelentene, hogy "n" darab utasitast ugorjon at elore vagy hatra (fuggetlenul az adott utasitasok hosszatol). Nyilvan ez nagy szamnal mar igen fura (foleg, ha kozben modositani kell a kodot), de pl 1 v 2 eseten szerintem (nekem legalabbis) kenyelmesebb lenne. Meg lehet probalkozni persze pl a "JR Z, $+4" es hasonlo dolgokkal, ezzel az a baj, hogy akkor neked kell szamon tartani, hogy hany byte-nyi kodot kell atugrani, es nem utasitasszamrol van szo.

Pl ami tetsze, az a ca65-ben (de az 65xx assembler, nem Z80 ...) az "unnamed labels":

http://www.cc65.org/doc/ca65-6.html#ss6.5
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 21:31:07
Quote
Ezt most nem ertem. Function0 es Function1 legyen ilyen label, a tobbi ponttal kezdodo.

A válasz egy hsz -al korábban vagyon, csak akkor még nem volt mikor te írtál.

Quote
Reusable labels

Nem akarok számokat használni, neveket akarok adni, valamint szabadon (is) akarok ugrálni, ez a reusable meg csak a közvetlen legközelebbiket keresi meg az ugrásnál.

Quote
Itt idegesito, hogy emiatt cimket kell bevezetni

Az szerintem pont azért idegesítő, mert egy globális nevet kell keresni, ami biztosan nem ütközik semmivel sehol az egész átkos programban (tiszta globális címkékben gondolkodva most), és még kifejezőnek is kell lennie. Ez valószínűleg egy 50 tagos, kilóméter hosszú címke lesz. Azt valóban idegesítő bevezetni egy arrébbugrásért ...
és pont erre keresném a megoldást.

De ha beírhatnád ott lokálisan 600adikra is hogy "loop:" meg "jumpto:" vagy akármi, az ott helyileg tök értelmes, kifejező és frappáns lenne ... csupán végtelenségig ágyazható relatív cimke névfeloldás kellene ... akár mint a C++ névterek ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 21:35:10
sjasm terminológiában beszélve gyakorlatilag a lokális és globális cimke fogalma tök felesleges lenne,
annyi kéne hogy a module az LOKÁLIS legyen (nyilván az előtte álló module -hoz), ne pedig globalis.

ha a sjasm -ban leirod, hogy:

 module kutya
 module macska
 module kutya
 
akkor nem
kutya.macska.kutya
-ban vagy, hanem simán csak a globalis
kutya
- ban, újra, csak közben megjelent a globalis
macska
module is ...
Title: Re: Assembly programozás
Post by: geco on 2015.October.15. 21:41:12
De ha beírhatnád ott lokálisan 600adikra is hogy "loop:" meg "jumpto:" vagy akármi, az ott helyileg tök értelmes, kifejező és frappáns lenne ... csupán végtelenségig ágyazható relatív cimke névfeloldás kellene ... akár mint a C++ névterek ...
Akkor neked az LGB által említett "unnamed labels" lenne a megoldás, és láttam is ilyen megoldást egy z80 disassembly listában, úgyhogy biztos van assembler is ilyen.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 21:46:12
Jó, akkor mindkettő probléma. Az első megoldódott, a másodikat viszont nem teljesen értem. Mi az az elengedhetetlen fontosságú absztrakció, amit egy függvényen belül muszáj ebben a formában megvalósítani?

Egyébként - de lehet hogy félreértelmezem a leírást - a pont karakter lehet része címkének, kitüntetett funkciója csak akkor van, ha a címke első karaktere.

Ha viszont egy függvényen belül újra fel akarsz használni valamilyen címkéket, akkor lehet - bocsánatot kérek, nem akarok csúnyát mondani - hogy nem választasz jól címke neveket, vagy nem jól szervezed a programodat - még egyszer sűrű és zavart bocsánatkérésem.


Viszont az sjasm forrása szabadon hozzáférhető. Lehet hogy mások is örülnének ha fejlesztenél bele teljes értékű névtér kezelést.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 21:56:42
Quote
Akkor neked az LGB által említett "unnamed labels" lenne a megoldás,

Nem. Az egy maszat, még a link is azzal kezdi a magyarázatot.

Nekem az kéne, hogy akkor nyissak egy (beágyazott, hierarchikus) névteret, amikor akarok.

Tehát modjuk, képzeletben csak, mert a sjasm most nem ilyen:






 module func0

entry:   //func0.entry

 module loop   //func0.loop

loop:   //func0.loop.loop

 module loop   //func0.loop.loop

loop:   //func0.loop.loop.loop

 module loop   //func0.loop.loop.loop

loop: //etc

 module loop //etc

 jr loop

 endmodule

 jr loop

 endmodule

 jr loop

 endmodule

 jr loop

 endmodule

 ret

 endmodule





 module func1

entry:   //func1.entry

 module loop   //func1.loop

loop:   //func1.loop.loop

 module loop   //func1.loop.loop

loop:   //func1.loop.loop.loop

 module loop   //func1.loop.loop.loop

loop: //etc

 module loop //etc

 jr loop

 endmodule

 jr loop

 endmodule

 jr loop

 endmodule

 jr loop

 endmodule

 ret

 endmodule





És igen, a példáim nem foglalkoznak most a modulnév és a cimkenév ütközésével, de azt is fel lehetne oldani 50 féle képpen,
pédául úgy, hogy a module neve automatikusan egy cimke neve is lehetne, vagy úgy hogy simán csak nem szabadna azonos modul es cimkenévnek lennie
egy modulban, stb ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:04:37
Mindennek szép formáját már említeni se merném :) :

Code: [Select]

module function0
{
entry:

module loop
{
loop:

module loop
{
loop:

module loop
{
loop:

jr loop
}

jr loop
}

jr loop
}

ret
}

module function1
{
entry:

module loop
{
loop:

module loop
{
loop:

module loop
{
loop:

jr loop
}

jr loop
}

jr loop
}

ret
}

Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:08:17
Ehhez hasonlo cucc kene?

http://www.cc65.org/doc/ca65-11.html#ss11.86
http://www.cc65.org/doc/ca65-7.html#scopesyntax

A "module" szerintem nem illik ide, az nem erre valo mar "filozofiaban" sem igazan.
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:11:35
Mindennek szép formáját már említeni se merném :) :

Code: [Select]
module function0
{
entry:

module loop
{
...

Ezzel szerintem az a baj, hogy ertelmet veszti a modul nev, a "module" utan. Hiszen pont az lenne a lenyege, hogy adott module-ba teszed a kodot, tehat uazt a modul nevet mondod, az nem lesz "kulon" itt meg minden module neve "loop". Ezert is mondtam, hogy ez nem erre valo. Amit te akarsz az tenyleg vmi scope, namespace, tudomisen.

Raadasul akkor a fenti szintaxis (ha letezne ilyen) egyszerusitheto, hogy pl:

module loop { ..... }

helyett egyszeruen csak:

{ ..... }
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 22:15:00
Akkor neked inkább valami Z80-as C fordító kellene ami tud inline assembly-t fordítani.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:15:25
Quote
Ehhez hasonlo cucc kene?

Pontyossan! Egymásba ágyazható névterek, szkópok, amik persze kedv szerint megcímezhetők felfele a hierarchia mentén ...

És ezt a sjasm -ban 3 szinten meg is oldották. Pontosabban lehetne úgy használni. De 3 szint az édeskevés a szabadsághoz.

Quote
A "module" szerintem nem illik ide, az nem erre valo mar "filozofiaban" sem igazan.

Na ha erről a filozófiáról (is) tudnál mondani pár szót azt én nagyon megköszönném,
mert az egész module dologról annyit találtam, hogy a "globális" cimkék a modulokra lokálisak ... :)

Mi a filozófiájuk egyébként ?



De mégegyszer visszatérve az igazi lényegre is: igen, ágyazott névterek kellenének a label nevekhez, "nested scope" -ok.
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.October.15. 22:16:13
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 22:17:11
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:
Nem. :)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:18:16
Quote
Akkor neked inkább valami Z80-as C fordító kellene ami tud inline assembly-t fordítani.

SDCC -vel kezdtem, arról akarok most átállni assembly -re. De a kényelem az kéne, amennyire csak lehet. Ki fogok dolgozni magamnak valószínűleg ilyen HLA makrókészletet, amivel tudok majd (nem sebességkritikus részeket) gyorsabban megírni,

de ez a cimke dolog ez egy tok fuggetlen layer.

Ez nagyon kéne a kényelmes, gyors kódoláshoz, hogy egy újabb címke felvétele ne tartson hat nap hét éjszaka.

És megörültem, hogy a sjasm tud ilyet, erre kiderül hogy csak 3 hierarchia szinten ... :(
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:18:21
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:

En csak probalom kitalalni mire gondolt :) Amugy meg vegulis, mindenkinek meglehet a stilusa, hogy mikepp tud szamara egyszerubbnek es attekinthetobbnek tuno modon kodolni. Meg akkor is, ha masnak ez finoman szolva se optimalis akar :)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:19:22
Quote
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:

Nem minden ember zseni.

Én pedig programozni szeretnék, nem pedig hekkelni.
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:29:39
Nem minden ember zseni.

:) Ez tipikus minden relativ dolog. Nekem a te peldaid alapjan tunik ugy, hogy azt atlatni ahhoz zseninek kell lenni, nekem a namespace ilyen hasznalata tunik eroltetettnek es tulbonyolitottnak, amit en nehezen tudnek kezelni a csopp eszemmel. Erdekes modon ezek szerint te pont forditva vagy ezzel, van ilyen :)

Mondjuk ha mar C++ is szoba kerult, azt en ki nem allhatom (es megtanulnom sem sikerult soha, hiaba alltam neki tobbszor is, eroltetett, tulbonyolitott, szuksegtelenul), sima C for president! :)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 22:30:50
Pedig hidd el, néha üdítő tud lenni egy kis ilyen favágás - mert szerintem ez a hekkeléstől messze esik - jellegű dolog is. Ki akarna mindig csak termelni?
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:32:16
Mi a filozófiájuk egyébként ?

Az sjasm irojat kene megkerdezni :) en max "erzesre" mondom, hogy nem a nesting a lenyeg, legalabbis nem ugy hogy egymas "alatt" vannak, hanem mondjuk mod1 jon innen, eddig, aztan mod2 innen eddig, aztan lehet, hogy mod1 megint de nem ugy, hogy ala van rendelve a mod2 a mod1-nek, csak kozbeekelodik. Legalabbis amennyire en latom ezt, de oszinten szolva, eddig soha nem hasznalta module-okat sjasm-ban (szoval tevedhetek is az ertelmezesben, nyilvan). Szerintem a page-eknek tobb ertelme van, foleg ha pl olyan program kell, hogy tobb EP mem szegmensben van, stb.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:37:31
Quote
Szerintem a page-eknek tobb ertelme van,

Igen, arra is nagy szükségem lesz, remélem nem kell abban is csalódjak.

De ezt a névtér dolgot még nem adtam fel ...

Kell itt lennie vmi okosságnak amit még nem értek ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.October.15. 22:37:41
:) Ez tipikus minden relativ dolog. Nekem a te peldaid alapjan tunik ugy, hogy azt atlatni ahhoz zseninek kell lenni, nekem a namespace ilyen hasznalata tunik eroltetettnek es tulbonyolitottnak, amit en nehezen tudnek kezelni a csopp eszemmel. Erdekes modon ezek szerint te pont forditva vagy ezzel, van ilyen :)

Teljesen egyetértek! :-)
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.15. 22:38:39
Pedig a C++ izgalmas dolog. Főleg amikor találgatod mit sikerült ilyen szépen elcseszni, hogy teljesen jónak néz ki, de a fordító meg ordít hogy na ezt ő aztán nem. A legizgibb dolog a template, főleg amikor valamilyen könyvtárat használsz, és a fordító dob a legjobb ötleteidre 3-4 soros hibaüzenetet, de olyat hogy a hivatkozott objektumokat sem bírod elkülöníteni csak 10 perces szemgúvasztással. :)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:41:52
Quote
Teljesen egyetértek! :-)

Tök jó, csak kár hogy mindkettőtök rendszereket hekkel ...

Amiből nem lesz játék ...

Ha lenne, nézhetném nyugodtan a trónokharcát, és közben mégis lenne nekem játék is ... :)

De úgy látszik akármennyit is várok, magamnak kell nekiveselkednem, mert nincs kedvetek leírni 654356754 darab cimkét, mire összejön a játék ...

Csak ehhez nekem kellene a nested namespace a címkéknél ...
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:42:53
Amugy Z80System problemajat oszinten szolva nem ertem (ez nem kritika akart lenni, egyszeruen nekem nem ilyen a gondolkodasom pl, stb). Az assembly lenyege az lenne, hogy ember szamara emeszheto, de vegulis majdnem gepi kod legyen elotted (csak ne kelljen pl hex-ben begepelni az egeszet, relativ ugrasokat kezzel szamolni stb). Elteroen egy magas szintu nyelvtol mint pl a C vagy C++, ahol az absztrakcios szint magasabb joval. Szoval az assembly egy kicsit emesztheto formaban de a CPU "gondolkodasmodjat" tukrozi, es nyilvan ezzel lehet kiaknazni a legtobbet amit az adott CPU tud (abba most ne menjunk bele, hogy modern RISC CPU-knal egy valag regiszterrel stb lehet, az emberi agy mar rosszabb kodot ir asm-ban mint pl egy C fordito general, maradjunk a Z80-nal es hasonlo CPU-knal). Tehat filozofiai szempontbol nekem kicsit santit, hogy miert akarod itt eroltetni az egeszen absztrakt fogalmakat, mint a nevter, egymasba agyazas stb. "Nem akarsz hekkelni" - ok, de vegulis az assembly pont errol szol, hogy pl nem egy szep pl OOP paradigma alapjan elvi megfontolasok alapjan tervezett nyelvet hasznalsz (aminek esetleg semmi koze mar az adott hw - foleg a CPU - mukodesehez), hanem lemesz kb a CPU szintjere.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 22:49:13
Quote
Tehat filozofiai szempontbol

Mert pont nem érdekel a filozófia.

Játékot akarok (nó filó), leggyorsabban futót, legkisebb méretűt -> KÉNYTELEN vagyok assembly -ben lekódolni, leggyorsabban elkészülőt (zeró idő alatt) ->nem érek rá címkeneveket kitalálgatni és nem vagyok ufó, hogy a visz435435 címkéből egyből értsem hol vagyok és mi az, közben pont letojom mi a gépközeli mi sem ... :)
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 22:57:42
Mert pont nem érdekel a filozófia.

Játékot akarok (nó filó), leggyorsabban futót, legkisebb méretűt -> KÉNYTELEN vagyok assembly -ben lekódolni, leggyorsabban elkészülőt (zeró idő alatt) ->nem érek rá címkeneveket kitalálgatni és nem vagyok ufó, hogy a visz435435 címkéből egyből értsem hol vagyok és mi az, közben pont letojom mi a gépközeli mi sem ... :)

Aha. Akkor lehet neked nem is assembly kene. Van par kisse kevesbe ismert nyelv (bar egyiknek a neve sem jut eszembe, hehe ...) ami sokkal alacsonyabb szintu mint a C, kvazi legtobb esetben tenyleg egy-egy opcode lenne egy adott konstrukcio, am az assembly-nel megis magasabb szintu.

https://en.wikipedia.org/wiki/Action!_%28programming_language%29

Sajna most ezt tudtam csak kiguglizni, ez epp nagyon nem Z80 (hanem 6502), de csak mint elvi pelda. Idezve az oldalrol:

"Constructs were designed to map cleanly to 6502 opcodes, to provide the high performance necessary for game and graphics demos without needing complex optimizations in the compiler."

Szoval a fenti peldat inkabb csak az elv kapcsan irtam le, hogy te boldogabb lehetnel esetleg nem assembly-vel, ami teljesitmenyben nem (vagy nem sokkal) marad el, de megis magasabb szintu programozasi nyelv.

http://www.dwheeler.com/6502/

Itt is ilyesmikrol van szo, sajnos ez is elegge 6502 specifikus, es ismet inkabb csak peldanak szanom ...
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 23:02:00
Pedig a C++ izgalmas dolog. Főleg amikor találgatod mit sikerült ilyen szépen elcseszni, hogy teljesen jónak néz ki, de a fordító meg ordít hogy na ezt ő aztán nem. A legizgibb dolog a template, főleg amikor valamilyen könyvtárat használsz, és a fordító dob a legjobb ötleteidre 3-4 soros hibaüzenetet, de olyat hogy a hivatkozott objektumokat sem bírod elkülöníteni csak 10 perces szemgúvasztással. :)

Az OOP-t sose szerettem, ha mar C++-nal tartunk :) Egyedul Pythoban vagyok el vele, erdekes modon ott nem zavar :) Fura.

Amugy a C++ meg annyi hulyseget tud, hogy sokan (erzesem szerint!) szinte kotelezonek erzik, hogy mindent hasznaljanak, template, operator overloading, objektum orokoltetes, whatever, akkor is, ha a feladat megoldasat ez nem segiti valojaban, sot ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 23:08:05
Quote
Aha. Akkor lehet neked nem is assembly kene.

Akár.

De inkább azon gondolkodok, vajon mennyi idő lehetne a sjasm -ba belehekkelni ezt a hierarchikus module dolgot.

Hogy ne úgy működjön ahogy működik, hanem ahogy én akarom ...


Ugyanis azt már néztem, hogy ez a hierarchia dolog csak a cimke "kiválasztásába" avatkozna bele,
maguknak a cimkéknek az értéke (tehát a befolyása a fordított kódba) az mindíg globális,
egy relatív címke értéke a szimbólum/lista fájlokban globális cím, nem relatív offszet ...

Magyarul magaba a fordított kódba nem kéne belenyúlni, csak valami "module fát" -et kéne fenntartani a fordítás során,
és ebből a module fából kéne kiválasztani a specifikált címkét mikor hivatkozik rá a kód ...

De magának a cimkének az értékének a kiszámolása maradhatna ugyanaz ...

Tehát valami magasabb szintű kódokban kéne ezt csak módosítani ... a sjasm meg nyíltforrású ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.15. 23:10:05
Ezek azért nem olyan gyors fejlesztések ... mikor az ember először nekiáll fejlesztői eszközöket hekkelni ... :)
Title: Re: Assembly programozás
Post by: endi on 2015.October.15. 23:10:21
saját oprendszert kell írni, csak azon lehet profin fejleszteni
sőt, saját hardvert
mert különben sose lesz játék
XD
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 23:13:11
saját oprendszert kell írni, csak azon lehet profin fejleszteni
sőt, saját hardvert
mert különben sose lesz játék
XD

Ez amugy nem hulyeseg, az igen szep hobby, amikor sajat hw-t csinalsz, ra fejlesztoeszkozoket stb. Csak ugye az kisse mas kategoria, mint EP-re jatekot irni mar :)
Title: Re: Assembly programozás
Post by: lgb on 2015.October.15. 23:18:28
Amugy meg azert egy megfontolando felvetes: lehet, azert fura valakinek egy 'atlag' assembler tudasa, mert nem szokta meg, nincs meg benne a gyakorlata stb. Persze, erre lehet az a reakcio, hogy csinaljunk jobb devel toolt, am erdemes feltenni a kerdest: melyik eri meg jobban, mi vezet gyorsabb eredmenyre stb. Az, ha inkabb az ember probal gyakorlatot szerezni a meglevo tool-okkal (es kozben rajon, hogy megse olyan "alien" csak "szokni kell", a vegen meg mar termeszetes lesz szinte!), vagy probal sajat dolgokat irni elobb, ami viszont ki tudja meddig tart, es utana raadasul az o forraskodjahoz mas hozzaszolni sem tud igazan, mert egy nem tul elterjedet assembler/fordito az, ami tud kezdeni vele valamit egyaltalan.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 12:10:39
Quote
azert fura valakinek

ahol fura=gyík.

Quote
egy 'atlag' assembler tudasa

egy átlag assembler -ben vannak relatív cimkék ?
Title: Re: Assembly programozás
Post by: lgb on 2015.October.16. 13:35:46
ahol fura=gyík.

?? Mi az a gyík? Geek? Hat igen az assembly low level, stb, az csak annak valo aki a CPU "fejevel" akar gondolkodni (tehat eleve hw orientalt, es igen kockanak kell lennie hozza valamennyire, ha valaki assembly-zni akar, hisz ez a lenyege, kozvetlenul akarod hw szinten "uralni" a dolgokat). Magasabb absztrakcios szintekre vannak mas nyelvek, pl C stb ...

Quote
egy átlag assembler -ben vannak relatív cimkék ?

Ezt a fogalmat tovabbra se ertem igazan ... A relativ cimke defincio szerint azt jelentene, hogy a cim relativ? Ilyesmi?

Code: [Select]
label1: NOP
label2: NOP
labelREL = label2 - label1

A label2 relativ, erteke 1 lesz. Vagy mihez kepest relativ? Mert ugye az tovabbra sem tiszta, a "local" cimkent (ponttal kezdodo) az pont relativ az elozo global cimkehez kepest. Szoval kb persze ertem mit akarsz, de amikor ilyen rovid kerdesed van hogy "van-e realtiv cimke" akkor ismet elveszettnek erzem magam, hogy mi is itt a kerdes. Mondom, lehet velem van baj, de nem igazan jon le nekem, hogy ez miert is jo, amit te akarsz az nekem tul komplex. Lathatoan te meg forditva vagy vele :) Pont ezert is irtam, hogy ez szokas kerdese, lehet, nekem azert termeszetes ahogy van, mert kb 26 eve assembly-zek, es bar volt 6502, x86 es Z80, kb minden assembler az adott CPU utasitasokon kivul persze hasonlo. Ergo, lehet te is igy lennel vele, ha hajlando lennel elfogadni, hogy az assemblerek ilyenek, es megprobalni megszokni. Nem okoskodni akarok, de nekem ez logikusnak tunik, legalabbis!
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 13:50:27
Quote
Mi az a gyík?

Sovány, vékony, fapados, szutyok.

Quote
az csak annak valo aki a CPU "fejevel" akar gondolkodni

Meg annak, aki kénytelen játékot írni 8 bites platformra.

Quote
kozvetlenul akarod hw szinten "uralni" a dolgokat

Akarja a fene. Kénytelen vagyok.

Quote
Ezt a fogalmat tovabbra se ertem igazan ... A relativ cimke defincio szerint azt jelentene, hogy a cim relativ? Ilyesmi?

Azért nem érted, mert marhaságokat beszélek.
Valójában nem "relatív cimkét" -t kellett volna mondanom, hanem "hierarchikus névterek" -et.
Mentségemre szolgáljon, hogy a sjasm doksi is relatív cimkének hívja őket, pedig valójában a címük abszolút, nem relatív semmihez, egyszerűen csak a névfeloldás szemppontjából "relatívak". Mint ahogy egy path is lehet relatív.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.16. 13:54:05
Szerintem nála a gyík a béna vagy gyenge szinonimája. A relatív címkén pedig talán az egymásba ágyazott hatáskörökben lokális címkéket érti.

Lehet az is megoldás lenne egyébként a problémájára ha egymásba ágyazott makrókat használna a kódjában, mert akkor talán körbe tudná manőverezni a "relatív címkék" problémáját.

Különben nekem sem teljesen világos miért ragaszkodik ezekhez a magas szintű nyelvekre jellemző képességekhez ennyire. Lehet azok nélkül élni. Talán már elég messzire is eljuthatott volna ha ahelyett hogy a szerszámok elégtelenségén problémázna, elkezdte volna használni őket és ténylegesen programot írna. Talán sosem fejtjük meg ezt a rejtélyt.


Közben válaszolt Z80System, úgyhogy tárgytalan.
Title: Re: Assembly programozás
Post by: Attus on 2015.October.16. 14:04:09
Szerintem meg neki kell esni, azzal az assemblerrel, ami kéznél van, nem a relatív címkék hiánya, vagy léte lesz a lagnagyobb probléma.
Létre kell hozni a legjobban testhezálló makrókat és azokat használni.
Én EP-hez a gen/mon -t használtam, magnóval valaha a saját programocskáimhoz.

A DOS alatti EP emulátorhoz meg a tasm -ot.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 14:07:16
Quote
ha hajlando lennel elfogadni, hogy az assemblerek ilyenek,

Miért kellene hogy egy assembler -ben a címkék névtere globális legyen mint az assembler -ek valóban 99 % -ában ?
Miért ne lehetne kényelmesen és könnyen találni elnevezéseket hierarchikus cimke névterekkel ?
Miért kéne ezt elfogadni ? Mai napig nem lenne "BMV", ha elfogadtuk volna hogy a "Trabi" is jó, mer a kocsik azok ilyenek.
Van egy ilyen alaptörvény az assemblereknél: ha a címkék névtere nem globális, akkor az nem assembler ? Puktum.
(Egyébként akkor a sjasm miért próbálkozik ezzel 3 hierarchiai szinten ? Hogy minnél assembly idegenebb és kényelmetlenebb legyen ?)

Quote
es megprobalni megszokni.

Hát én sem a .NET -en szocializálódtam, de attól még szívesen letúrnám magamról az assembly forítók olyan tulajdonságait, melyek nekem űberkényelmetlenné teszik a kódolást.

A globális címke névtér nekem ilyen.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 14:09:27
Quote
Lehet az is megoldás lenne egyébként a problémájára ha egymásba ágyazott makrókat használna a kódjában, mert akkor talán körbe tudná manőverezni a "relatív címkék" problémáját.

Ezen rágódom magam is ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 15:02:48
Na most megáll az eszem:

http://www.ecstaticlyrics.com/electronics/Z80/sarcasm/

Itt van ez az assembler, és ez is 3 szintű névteret biztosít ... ("namespace" -re keressetek)

Gyakorlatilag pont ugyanazt tudja, csak az sjasm "module" az a sarcasm "namespace" ...

Én ezt nem értem ... miért pont 3 ? ? ? Kell itt lennie valami okosságnak ...
Title: Re: Assembly programozás
Post by: geco on 2015.October.16. 15:08:16
Gondolom annyi, hogy egy namespace-en belül már viszonylag könnyű különböző címkéket használni, hacsak megeshet az is, hogyl lehet namespace-be namespace-t ágyazni, mert ebben itt a kánaánod ;)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 15:10:31
Quote
acsak megeshet az is, hogyl lehet namespace-be namespace-t ágyazni, mert ebben itt a kánaánod ;)

Mit akarsz mondani ? Szavadat nem értem ...
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.October.16. 15:11:33
Én ezt nem értem ... miért pont 3 ? ? ? Kell itt lennie valami okosságnak ...

Gondolom nem akarnak szarakodni teljes névtér implementálással. Végül is ha ennyivel is el tudnak evickélni, minek erőltetnék magukat.
Title: Re: Assembly programozás
Post by: geco on 2015.October.16. 15:15:11
Mit akarsz mondani ? Szavadat nem értem ...
ha namespace -be lehet namespace definíciót ágyazni, akkor megoldódott a problémád, de rosszul értelmeztem első átfutásra a leírást, szerintem egy fikarcnyival se vagy előrébb itt, mint a SJASM module, globális címke +lokális címke megoldásával.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.16. 22:55:34
FF szegmens elején mennyi memóriát is lehet elhasználni standard 128K -s gép esetén ?
Title: Re: Assembly programozás
Post by: IstvanV on 2015.October.17. 10:13:41
Ez a megnyitott csatornáktól függ, 128K/EXDOS/FileIO konfigurációnál például az IS-BASIC futása közben az EXOS határ 0A37h, de C=60h EXOS 0 hívás után 1CC0h. File megnyitása a használt eszköztől függően csökkenti a szabad terület méretét. A legbiztosabb megoldás az EXOS 22 és 23 hívások használata. :) Az EXOS veremben is található általában szabad terület (AC00h-AFFFh).
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.23. 21:56:15
Teszem azt IY -ban akarom átadni a mindenkori függvényem stack frame -jét,
mi a leggyorsabb mód arra, hogy egy függvényhívás előtt/után korrektul kezelve legyen ? :

- IY aktuális értéke mentődjön stack -re
- SP = SP - stack freame méret
- IY = SP

- call függvény

- SP = SP + stack frame méret
- IY visszatöltődik a stack -ről
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.23. 23:55:29
Érdekes dolgokat találtam:

http://www.benryves.com/bin/brass
http://www.benryves.com/bin/brass/syntax/modules.htm

Quote
Brass extends the module idea significantly. Rather than a simple bunch of root-level modules, Brass allows you to nest modules inside eachother.

Félve (nem tudom még hogy majd melyik másik feature hiányozhat a sjasm -ból ...) eresztek meg egy nagy:

JUHÚÚÚÚÚÚÚÚÚÚ -t ... :lol: :lol: :lol:

https://youtu.be/SSbBvKaM6sk?t=12
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 00:01:50
És ez messze nem minden (csak ennek nincs direkt win binárisa, és nem nagyon reklámozzák ha multis a kódja):

http://k1.spdns.de/Develop/Projects/zasm/Distributions/
http://k1.spdns.de/Develop/Projects/zasm/Documentation/
http://k1.spdns.de/Develop/Projects/zasm/Documentation/z40.htm#A

Quote
This defines a local scope for normal label definitions. This way you can safely use 'standard' names for jump targets in included files without worrying about name collissions.
#local contexts can be nested.

Bár azt még nem látom, hogy akkor itt tudnék -e szabadon cimkészni, miközben ha akarom mégis bárhonnan elérhetek bármit,
de sokkal gazdagabb címke fícsőrei vannak, mint a sjasm -nak ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 00:30:33
Hmmm ... a brass készítője nem is tűnik éppen szimpla entitásnak, érdemes ráböngészni az oldalára:

http://www.benryves.com/

És mint kiderült a fent linkelt bras mára átadta a helyét a bras3 -nak:

http://www.benryves.com/products/brass
http://www.benryves.com/products/brass3

Csak nem igazán (nyomát sem láttam) nyíltforrású ... persze lehet hogy ez engem most nem kellene zavarjon ...
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 00:43:53
A síma brass -ban még ilyen is van ! :) :

http://www.benryves.com/bin/brass/directives/using.htm

(Jó lenne ha írna dátumokat a release -ekhez, hogy az embernek legyen némi benyomása a fejlesztés üteméről ...)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 01:34:53
Helyesbítek: a brass -okhoz (3 -hoz biztosan) is elérhetőek források.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 03:28:52
Na a brass3 az elijesztett magától azzal, hogy elég körülményes a használata (egy külön kis programot írtak rá, hogy "meg lehessen" hívni és a projektfájlja alapján lefordítson bármit is), valamint a saját mellékelt projektjeinek lefordításától simán csak elszállt ...

Ha valakinek más lenne a tapasztalata, vagy valamit benéztem, akkor szóljon, mert a brass3 -ban nagyon ráfeküdtek arra, hogy (azon kívül hogy nagyon bővíthető legyen minden része) mindenféle ördöngös szkripteket lehessen benne írni, és így pld. színusz táblákhoz, ilyesmikhez ne kelljen külön tool -okat írogatni, hanem le lehessen kódolni az assembler -nek őket.



Ezek a részek még nincsenek benne a síma brass -ban, de a címke névterekkel eddig azt csinálta hálistennek amit vártam tőle, úgyhogy lehet megvan végre a megfelelő assembler ! :)
Nem kényszerítenek rá, hogy a címkék a sor elején kezdődjenek, egymásba ágyazható struktúrákat is ismer, tud exportálni a bináris mellé inklúdolható címke file -t, rendes C file API szerű eszközökkel tudsz hozzáfűzni binárist a kimenetedhez, és szép színezett html lista file -ja van ... gondolom érzitek ... :)



Ahogy néztem makrók tekintetében nyomja le a sjasm a brass -t és a zasm -ot is, de azért vannak itt is, remélem meg tudom csinálni velük amit akarok, azt nem tudom most előre kiértékelni, hogy melyik pontosan mivel tud többet vagy kevesebbet, pláne hogy még azt sem tudom nekem pontosan milyen makró funkciók fognak kelleni. A legalapvetőbb makrófunkciók meg mindegyikben vannak.

Valamint az tetszett még a sjasm -ban, hogy magától képes (szabályok szerint) szétosztogatni a kódokat a lapok között, majd a címkékből képes megmondani (képezni), hogy melyik lapra került végül, melyet a kódban te felhasználhatsz értelem szerűen lapozásra.
Ezekben az újakban ilyen funkciót nem láttam, itt neked kell explicit megmondanod hogy melyik lapra kerüljön a kód, és saját logikával (makrókkal, címkékkel) kell nyilvántartanod , hogy melyik lapot kell lapozd a milyen címkéhez.
De remélem ez sem fog nagyon hiányozni.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 03:37:59
Na jó, úgy nézem egy kis foghíjja azért van a brass címke névtér kezelésének:

Egy gyerek névtérből nem látszanak felfelé a szülő névterek címkéi.

Vagyis ha egy gyerek névtérből egy szülő névtérben lévő címkét akarok elérni,
akkor vagy leírom a teljesen kvalifikált (globális) nevét, vagy pedig a
.using -gal meg kell adjam a címke moduljának a teljesen kvalifikált nevét,
és aztán már a modulban hivatkozhatok az imént .using -olt modul összes címkéjére,
lokális nevükkel. Ütközéseket pedig megadott .using module lista szerint kezeli ...

Há' mos' mér nem lehetett felfele a szülők fele megkeresni az első találatot, ha nincs a címke az adott aktuális lokális modulban ?

Miért kelljen (elvben minden egyes) névteremet (modulomat) úgy kezdenem, hogy visszamenőleg az összes szülő névteret .using -olom a teljesen kvalifikált module nevükkel ?

Legalább valami ".using parent", vagy ilyesmi lenne ... de semmi ...

Hrrrrrrrrrrrrrrrr ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 04:04:19
Kellene írni EP -re egy rendes fordítót, mer ezek gagyik ... :)

Na mindegy, azért ezzel a brass -sal meg tudom végre csinálni, hogy file -onként bevezetek egy module nevet,
pld. sys a sys.asm -hez, lpt az lpt.asm -hez, game a game.asm -hez,
aztán azon (az előbb említett nagyságrendű) az egységen belül bevezetek még egy ágyazott névteret minden "képzeletbeli" függvényemnek,
aztán a függvényeken belül a különböző ciklusoknak ...

Majd ezek szerint meg kell adjam a függvényeknek a file szintű névteret viszonylag sok helyen, ahogy egymást hívják majd a függvények,
valamint a függvény szintűeket meg meg kell adjam a ciklus szintűeknek, ahogy a ciklusok esetleg egymásba ugrálgatnak ...

Csak az a baj, hogy pont az lenne a lényeg, hogy globálisan NE kelljen megadni sehol semmit,
mert amint egy .using -ot megadok globálisan, akkor mikor másolom a kódot, vagy csak átrakom,
struktúrálom a névtereket, akkor állandóan át kell írogatni őket ...

Végre egy assembler -be belerakják, és aztán nem keresnek felfele ... megáll az ész ... :)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 10:24:02
A zasm -ban persze meg van valósítva az automatikus felfele keresés:

Quote
Note: used but locally undefined labels are automatically pushed to the surrounding scope by
#endlocal and will finally reach the global scope, if they were not defined in an intermediate surrounding #local scope. There they can be picked up and resolved by the #include library directive.

Viszont itt meg ha megfigyelitek, a scope -oknak nincsen neve ... vagyis minden a scope -ban lokális lesz, és keresnek is felfele, csak épp elnevezetten nem tudsz a scope -ból egy másik scope -ban lévő lokális cimkét a teljes nevével elérni ...

Aaaaaaaaaaahhhh .... :) (Ami már messze nem juhúúúúú.)
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 16:18:19
Na, megtaláltam a Brass -ban a címkéből page indexet képző módszert, tehát az van.

Viszont közben kiderült, hogy ugyanazt a module -t nem tudom 2X megnyitni, folytatni sem ... túlélem, de akkor is ... :(
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.24. 20:24:08
Király, a struktúrák is tök idétlenek a brass -ban ...

Hiába lehet a struktúrákat ágyazni egymásba, nem találok az inicializálásukra kényelmes megoldást, vagy kódot írsz rá, és akkor eléred a membereket, de akkor az már nem compile/load time dolog, vagy ömlesztett (pld.: .db) bájtokkal inicializálod, de akkor meg nincs struktúrálás, bájt stream -et írsz ...

És ez a kisebbik baj, a nagyobbik, hogy a struktúrák gyakorlatilag lokális modulokat (címke névtereket) hoznak létre, de csak akkor ha a struktúrát instanszolod,
az instanszolt változó neve lesz a "top" modul, és benne a memeber hierarchia a gyerek modulok a primitívekig,

de minden egyes member címke egy abszolút cím lesz (csak trükközéssel lehet összekínlódni a member offszeteket),

és még mindíg nem elég: a struktúrából instanszot (un. "változót") felvenni csak a .var paranccsal lehet, mely nem az aktuális PC -re generálja az anyagot, hanem ilyen külön abszolút címekkel megadott területekre ... szóval struktúra instanszot nem tudsz csak úgy felvenni, mint mondjuk egy .db -t ...

Az élet kemény.
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.25. 13:18:08
Úgy tűnik (nem túl részletes a help) brass -ban ugyanazzal a .varloc -os trükközéssel be lehet rakni egy struktúra instanszot bárhova ... csak az inicializálása marad nyűgös ...
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.October.25. 13:19:49
Amiket írsz, abból már csak a kötőszavakat értem :oops:
Title: Re: Assembly programozás
Post by: endi on 2015.October.25. 13:24:06
Amiket írsz, abból már csak a kötőszavakat értem :oops:

:D

szerk: én is :D
Title: Re: Assembly programozás
Post by: Z80System on 2015.October.25. 13:29:42
Quote
Amiket írsz, abból már csak a kötőszavakat értem :oops:

Addig örülj, mert ha értenéd, akkor el is kezdenének hiányozni ... :)

Ebben az átkos assembly világban semmi nem volt soha kerekre kidolgozva ... mindíg ott voltak az érthetetlen, implementációfüggő, rosszul analizált, kerek logikából kibújó marhaságok ...

Tök dezsavü az egész régről ... :)

A C fordítók egy áldás, a C++ meg az isten ... :)
Title: Re: Assembly programozás
Post by: endi on 2015.October.25. 13:31:27
szerintem amúgy ilyen szuperhiper extra funkciókkal tuti nem lehet a leggyorsabb kódot csinálni asm-ban

azt csak "kézzel" lehet... pont azért, mert nem lehet hiperlogikus
Title: Re: Assembly programozás
Post by: sanyike on 2015.November.24. 23:35:41
[attachurl=1]

...első assembly próbálkozásom...

Még nem jöttem rá, hogy a paletta 2. nyolc színét, hogy kell beállítani, ezért hiányzik egy szín a ruházatból :-)
Title: Re: Assembly programozás
Post by: lgb on 2015.November.25. 00:48:54
Még nem jöttem rá, hogy a paletta 2. nyolc színét, hogy kell beállítani, ezért hiányzik egy szín a ruházatból :-)

Az a FIXBIAS. 0x80 port also 5 bit adja a felso 5 bitjet a masodik 8 szinnek a palettabol. Sajna csak igy "egyben" allithato ez.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2015.November.25. 07:00:20
A C fordítók egy áldás, a C++ meg az isten ... :)
"This is why IMHO handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
Title: Re: Assembly programozás
Post by: Zozosoft on 2015.November.25. 07:19:05
Az a FIXBIAS. 0x80 port also 5 bit adja a felso 5 bitjet a masodik 8 szinnek a palettabol. Sajna csak igy "egyben" allithato ez.
De célszerűbb az EXOS BIAS változóját használni:
-normál színkód használható
-mellékhatásként nem rontjuk el a belső hangszóró kikapcsolt állapotát :-)
-esetleges EXOS műveletnél (fájlbetöltés, stb) az EXOS a jó értéket írja vissza a megszakítási rutinban
Title: Re: Assembly programozás
Post by: sanyike on 2015.November.28. 09:44:30
Sajna csak igy "egyben" allithato ez.

Tehát ha jól értelmezem; színenként nem lehet csak 8-as fix színcsoportonként?
256/8 = 32 variáció ...?

Title: Re: Assembly programozás
Post by: lgb on 2015.November.28. 10:48:38
Tehát ha jól értelmezem; színenként nem lehet csak 8-as fix színcsoportonként?
256/8 = 32 variáció ...?

Amennyire en tudom igen. 16 szinu modban az LPB-ben csak a paletta also 8 szine fer el. A masodiknal azt csinalja a Nick, hogy ha az adott szin a masodik nyolc szinre esik akkor fogja a FIXBIAS erteket az lesz a felso 5 bit, az adott szinnek megfelelo 3 bitje meg az also, igy jon ki a Nick szin, amit oda eloallit. Tehat a FIXBIAS 8 szinenkent adja meg a "csoportot". Ez szokott neha "fajni", hogy igy meg van kotve az ember keze kicsit. Persze az elso 8 szin az szabadon allithato FIXBIAS-tol total fuggetlenul, mivel 8 szinnek megvan a sajat paletta beallitasa magaban az adott LPB-ben.
Title: Re: Assembly programozás
Post by: endi on 2015.November.28. 11:24:51
művészi szempontból amúgy nem okoz sok hátrányt a bias, szóval inkább technikailag. effektekhez, átiratoknál lehetett volna jobban használható a bias mellőzése.
na meg esetleg ha nem csoportokat határozna meg hanem egy 1 byte-os léptékű offsetet, akkor picit jobban hasznható lett volna, pl effektekhez is. persze így 1 byte-on kellett volna tárolni...

a fő gond amúgy inkább a színek sorrendje a 256 színű palettában. na az elég béna :) persze nem tudom más bitkiosztással jobb lett volna-é
Title: Re: Assembly programozás
Post by: geco on 2015.December.27. 15:43:30
Akit érdekel, egy kis program, ami egyszerűbbé teszi színátmenetek kiválasztását a palettáról, irányítás bármilyen joy + qaop space, törlés Erase.
Title: Re: Assembly programozás
Post by: Mayer Gábor on 2015.December.27. 16:12:46
Hello,

A forrást feltennéd valahova?
Title: Re: Assembly programozás
Post by: geco on 2015.December.27. 16:28:44
Hello,

A forrást feltennéd valahova?
Nem valami szép, és nincs agyonkommentelve :D
Title: Re: Assembly programozás
Post by: sanyike on 2015.December.27. 20:24:52
Akit érdekel, egy kis program,

Nagyon jó, nagyon hasznos.
Köszi!
Title: Re: Assembly programozás
Post by: lgb on 2016.March.28. 23:06:22
Valakinek otlete, hogy sjasm-ban (0.42) hogy lehet "eloallitani" egy cimket ugy, hogy ossze akarom rakni a nevet is? :) Na ha nem ertheto, akkor pl:

Code: ZiLOG Z80 Assembler
  1. MACRO stupid subname
  2.      very_long_prefix_for_name_always_seen_ ???? subname = $
  3. ENDMACRO

A kerdes, hogy mi kene a ???? helyere, vagy egyeb megoldas. Az ertelme az lenne, hogy eleg lenne azt irnom, hogy "stupid s1" valahova, es akkor eloallna egy cimke aminek a neve very_long_prefix_for_name_always_seen_s1 vagy hat barmi mas az s1 helyere, ami a "stupid" makro parametere volt. Nem is vagyok biztos benne, hogy sjasm kepes erre amugy, hogy nem konstans modon adok meg egy label-t, hanem "ugy rakom ossze" annak a nevet is. Mondjuk en 65xx cpu vonalon a ca65-hoz vagyok szokva, ott a makrokban akar egy assembler is megirhato, annyira komplex :-P
Title: Re: Assembly programozás
Post by: Povi on 2016.May.10. 02:40:34
valaki tudja, hogy az sjasm miért dob ilyen hibát?
Use of @# not allowed outside loops


pedig repeat - endrepeat blokkban vagyok...
Title: Re: Assembly programozás
Post by: Povi on 2016.May.18. 22:32:12
van valami ötletetek arra, hogy hogyan lehetne gyorsan ellenőrizni, hogy egy 16 bites reg-ben 0x8000 van?

a regiszter tartalmát nem kell megőrizni

és egy ugyanilyen tesz 0x7fff -re?

edit: tehát van-e gyorsabb és elegánsabb megoldás, mint pl.:

Code: [Select]
ld  bc, 0x8000
add hl, bc
Title: Re: Assembly programozás
Post by: Povi on 2016.May.18. 22:44:43
ja és a DE reg-ben van az érték, amit csekkolni kéne, de az A reg-ben is a D van
szóval igazából itt az a kérdés, van-e valami trükk, amivel meg tudom nézni, hogy AE == 0x8000
Title: Re: Assembly programozás
Post by: geco on 2016.May.18. 23:24:20
SUB 80h
OR E
?

A masikra:
SUB 7Fh
INC E
OR E
?
Title: Re: Assembly programozás
Post by: Povi on 2016.May.19. 03:08:47
ez jó, köszi :-)
Title: Re: Assembly programozás
Post by: szipucsu on 2016.May.30. 16:33:28
Nem tudom, milyen topikba illik ez...
Ilyen játékot (https://www.youtube.com/watch?v=O_U65QkH_EU) biztos könnyen lehetne írni EP-ra is. Nagyon egyszerű a grafika.
Title: Re: Assembly programozás
Post by: endi on 2016.May.30. 16:43:35
Nem tudom, milyen topikba illik ez...
Ilyen játékot (https://www.youtube.com/watch?v=O_U65QkH_EU) biztos könnyen lehetne írni EP-ra is. Nagyon egyszerű a grafika.

ilyenekből van sok mobilon, némelyik giga siker :)
de átírni is lehetne, ugyanis van specyre is
http://torinak.com/qaop#128#speed=1#l=https://dl.dropboxusercontent.com/u/3152568/qaop/tapes/InfGame.tap
Title: Re: Assembly programozás
Post by: szipucsu on 2016.May.30. 17:17:49
de átírni is lehetne, ugyanis van specyre is
Érdemesebb lenne egyből EP-ra írni, így az EP képességeihez alkalmazkodna. Olyan veszettül bonyolult nem lehet az a pár scrollozó cucc megvalósítása, már amennyire értek én hozzá. :D
Basicben (főleg a scroll miatt) nagyjából esélytelen, még zzzippelve is.
A Spectrum verzió elég lassúnak tűnik. Pl. a Zynaps bonyolultabb grafika, és talán gyorsabb is. Biztos gyorsabbra meg lehet csinálni EP-ra, és talán a háttérben is lehetne még valami lassú scroll.
Title: Re: Assembly programozás
Post by: endi on 2016.May.30. 17:18:43
Érdemesebb lenne egyből EP-ra írni, így az EP képességeihez alkalmazkodna. Olyan veszettül bonyolult nem lehet az a pár scrollozó cucc megvalósítása, már amennyire értek én hozzá. :D

jaja, sokkal szebbet ki lehetne hozni, és mehetne 60 fps-el is
Title: Re: Assembly programozás
Post by: ergoGnomik on 2016.May.30. 19:39:35
Nem tudom, milyen topikba illik ez...
Ilyen játékot (https://www.youtube.com/watch?v=O_U65QkH_EU) biztos könnyen lehetne írni EP-ra is. Nagyon egyszerű a grafika.
A régi munkakerülő blogon ezt a szemétparaszt kategóriába sorolták volna be.
Title: Re: Assembly programozás
Post by: ergoGnomik on 2016.May.30. 19:40:22
jaja, sokkal szebbet ki lehetne hozni, és mehetne 60 fps-el is
:shock: 60? Hogyan?
Title: Re: Assembly programozás
Post by: endi on 2016.May.30. 19:42:31
:shock: 60? Hogyan?

ja bocs 50 :D
hozzászoktam már a mobilokhoz :D
Title: Re: Assembly programozás
Post by: Povi on 2016.May.31. 19:39:46
van valakinek ötlete osztó rutinra?
32 bites előjeles egészt kell oszatni 16 bites előjeles egésszel

az eredmény 16 bites előjeles (ha nem fér bele, az nem baj)
meg persze kéne a maradék is 16 bites előjelesként
Title: Re: Assembly programozás
Post by: ergoGnomik on 2016.May.31. 22:12:18
van valakinek ötlete osztó rutinra?
32 bites előjeles egészt kell oszatni 16 bites előjeles egésszel

az eredmény 16 bites előjeles (ha nem fér bele, az nem baj)
meg persze kéne a maradék is 16 bites előjelesként
Úgy kell csinálni mint ahogyan mindig. Az előjelek alapján meghatározod az eredmény előjelét, veszed a számok abszolút értékét, az osztót fellépteted addig amíg még kisebb az osztandónál, aztán összehasonlítgatod és szükség szerint kivonogatod a visszaléptetgetett osztót, az elvégzett kivonásokat a hányadosban 1-es bittel jelzed, és minden léptetésnél lépteted a hányados bitjeit is. Amikor visszaállt az eredeti osztó és azzal is elvégezted a kivonást (ha kell), megkaptad a maradékot is. Annyi a kihívás, hogy nem tudod úgy tárolni, hogy a CPU egy utasítással tudja kezelni a 32 bites számodat, ezért az összehasonlításokat az alsó és felső szóra is el kell végezni az eredményük összegzésével, illetve a léptetéseknél a kicsúszó biteket át kell vinni az osztó kiterjesztett dupla szavának alsó és felső fele között.

Szerk.: Annyi jutott még eszembe, hogy nem szokás "felléptetni" az osztót, hanem rögtön a 16 bittel feltolt pozícióból indítanak, így egyszerűbb lesz a kód.
Title: Re: Assembly programozás
Post by: Povi on 2016.August.01. 22:09:28
hogy működik a DAA?
hogyan tudok BCD-ben számolni (összeadni) Z80-on?

ld a, 0x79
add a, 0x88    ; A = 1, Carry = 1
daa

ekkor A=0x67 lesz? (79+88 = 167)

és a Carry meg gondolom beállítva

vagy teljesen máshogy működik?

Title: Re: Assembly programozás
Post by: geco on 2016.August.01. 22:17:35
Ugy emlexem igy muxik, hasznaltam ma r parszor, de csak 99%-ra mondom.
Title: Re: Assembly programozás
Post by: lgb on 2016.August.01. 23:28:40
Nekem a DAA "trukkos" felhasznalasa kapcsan ez tetszett (0-15 konvertalasa hex ertekre ami kirakhato mint ascii karakter):

Code: ZiLOG Z80 Assembler
  1. AND  $0F
  2. ADD  $90
  3. DAA
  4. ADC  $40
  5. DAA
  6.  

Remelem jol emlekeztem ra fejbol :)
Title: Re: Assembly programozás
Post by: Povi on 2016.August.02. 00:04:43
Ugy emlexem igy muxik, hasznaltam ma r parszor, de csak 99%-ra mondom.
ja, úgy tűnik, működik, kipróbáltam... :-)
Title: Re: Assembly programozás
Post by: Povi on 2016.August.02. 00:05:13
Nekem a DAA "trukkos" felhasznalasa kapcsan ez tetszett (0-15 konvertalasa hex ertekre ami kirakhato mint ascii karakter):

Code: ZiLOG Z80 Assembler
  1. AND  $0F
  2. ADD  $90
  3. DAA
  4. ADC  $40
  5. DAA
  6.  

Remelem jol emlekeztem ra fejbol :)

ilyesmi, de egy DAA elég hozzá:
http://zxm.speccy.cz/data/Z80%20Bits.html#5.2
Title: Re: Assembly programozás
Post by: Povi on 2019.March.23. 11:10:15
Sakk program 377 byte-on! http://chesskelet.x10host.com/

Spectrumra, forráskóddal (http://chesskelet.x10host.com/code.html) együtt! Lacika! figyelj! :-)

Monjduk pl. sáncolni nem lehet benne, és az en-passant-ot se ismeri (de ez utóbbit a Cyrus se)
Title: Re: Assembly programozás
Post by: endi on 2019.May.29. 20:42:16
online z80 fordító
http://clrhome.org/asm/
Title: Re: Assembly programozás
Post by: Spidermans Friend on 2019.June.15. 11:38:58
Nemrég belenézegettem a Cyclone-ba és az Exolon-ba, és megtaláltam, hol vannak bennük a sprite-ok, illetve a pályák eltárolva. Ezen sikeremen felbuzdulva szeretném az Exolon-t felderíteni, hogy is működik az egész játék, esetleg módosítgatni ezt-azt. Z80 gépi kódban elég alap szinten vagyok, de nagyon érdekelni kezdett. Milyen segédprogikat ajánlotok ilyesmihez? Spekihez van a Skoolkit, de azzal nem sikerült még boldogulnom. Egyáltalán a Speki vagy az EP változatokat érdemesebb piszkálni?
Title: Re: Assembly programozás
Post by: geco on 2019.June.16. 12:50:23
Ez attól függ, hogy mit szeretsz jobban, EP-n szeretnél dolgozni, vagy inkább PC-n, én SjASMEP-t használom (mégha az új képesságeinek csak töredékét is), a forrásszöveg mókolására meg a Notepad++-t, disassemblyre a dZ80W-t, tömörítésre EPCOMPRESS-t. képkonverzióra EPIMGCONV-ot :D
Attól függ, a maga nemében mind a kettő marha jól néz ki, a Speccy verzió szerintem az egyik legszebb Speccy játék.
Title: Re: Assembly programozás
Post by: endi on 2019.June.16. 16:35:24
exolont szerintem már visszafejtették.
most hirtelen ezt találtam:
https://bitbucket.org/esl/exolon-zx/src/default/

mondjuk exolon úgy lenne jó ha pl kihasználná a 42 karakter széles képet, meg ilyesmik :)
a cpc col16 módú verzió se rossz.
Title: Re: Assembly programozás
Post by: Zozosoft on 2019.June.17. 11:00:01
Én egyszer álltam neki egy egész játéknak: Lirus (https://enterpriseforever.com/enterprise-devcompo-1/konverzio-lirus/)
Ahogy általában, ehhez is az IDA-t használtam disassemblernek, ebben az a jó, hogy folyamatosan tudod alakítani a kódot. Pl elnevezgeted a felismert memória címeket, aztán ahogy sokasodnak, az ismeretlen kódrészletekről is egyre könnyebben látszik mit csinál.
Ami már kezdetnél is nagy könnyebbség: nem ész nélkül disassemblál mindent, hanem megadsz egy belépési pontot, és onnantól "lefuttatja" a kódot, végig menve minden híváson, ugráson. Így már az elején elég jól elválik egymástól, hogy mi kód, mi adat.
Title: Re: Assembly programozás
Post by: geco on 2019.June.17. 11:06:40
Ami már kezdetnél is nagy könnyebbség: nem ész nélkül disassemblál mindent, hanem megadsz egy belépési pontot, és onnantól "lefuttatja" a kódot, végig menve minden híváson, ugráson. Így már az elején elég jól elválik egymástól, hogy mi kód, mi adat.
Na, ez nekem nem tetszett annyira, 6510-es forrást próbáltam megetetni vele, és egy csomó kódot nem talált meg, és a data részt is hiányosnak eléggé véltem :D , és megpróbáltam az adatokat 8-asával grouposítani, nem ment :( Nem tudom z80-ra mennyivel jobb, azt nem próbáltam.
Title: Re: Assembly programozás
Post by: Spidermans Friend on 2019.June.17. 23:28:01
Ez nagyon jó, hogy nem nekem kell tök nulláról. Az lenne az igaz kihívás, de lehet, hogy hamar elmenne a kedvem.

Nekem csak a Spectrum/EP verzió tetszik. A grafika, a színek művésziek, a colour-clash minimális. A CPC-s nekem túl csicsa, a főhős vonaglása különösen nem tetszik. A PC-s remake-ekről ne is beszéljünk.

Title: Re: Assembly programozás
Post by: Ferro73 on 2019.July.19. 21:46:05
Nemrég belenézegettem a Cyclone-ba és az Exolon-ba, és megtaláltam, hol vannak bennük a sprite-ok, illetve a pályák eltárolva. Ezen sikeremen felbuzdulva szeretném az Exolon-t felderíteni, hogy is működik az egész játék, esetleg módosítgatni ezt-azt. Z80 gépi kódban elég alap szinten vagyok, de nagyon érdekelni kezdett. Milyen segédprogikat ajánlotok ilyesmihez? Spekihez van a Skoolkit, de azzal nem sikerült még boldogulnom. Egyáltalán a Speki vagy az EP változatokat érdemesebb piszkálni?
Talán megfelel az elvárásoknak.
Title: Re: Assembly programozás
Post by: Ferro73 on 2019.July.26. 15:53:23
Code: [Select]
  org 1000h
  DEC L
  JR C,NULLAS
  DEC L
  LD E,H
  LD BC,500H
  JR C,EGYES
KETTES
  LD E,5
EGYES
  LD A,E
  INC E
  OUT (0B5H),A
  IN A,(0B6H)
  RRCA
  RL C
  DJNZ EGYES
  JR VISSZA
NULLAS
  LD A,8
  OUT (0B5H),A
  IN A,(0B5H)
  BIT 6,A
  JR NZ,UG
  SET 4,C
UG
  LD A,7
  OUT (0B5H),A
  IN A,(0B5H)
  BIT 3,A
  JR NZ,UG1
  SET 3,C
UG1
  BIT 1,A
  JR NZ,UG2
  SET 2,C
UG2
  BIT 5,A
  JR NZ,UG3
  SET 1,C
UG3
  BIT 2,A
  JR NZ,UG4
  SET 0,C
UG4
  LD L,C
  RET
Ezt BASIC ALLOCATE építeném.
 LET A=USR(JOY,012)
és mint a LET A=JOY(012) értéket adná vissza.
Csak ZZZIP talán gyorsabb.
Ötlet, valamit javítani?
Title: Re: Assembly programozás
Post by: geco on 2019.July.26. 16:13:18
a DEC L nem állítja a C flaget, helyette használhatod a
Code: [Select]
 org 1000h
  DEC L
  INC L
  JR Z,NULLAS
  DEC L
  LD E,H
  LD BC,500H
  JR Z,EGYES
.
.
.
Title: Re: Assembly programozás
Post by: Ferro73 on 2019.July.26. 19:26:28
Code: [Select]
KETTES
  LD E,5
EGYES
  LD A,E
  INC E
  OUT (0B5H),A
  IN A,(0B6H)
  RRCA
  RL C
  DJNZ EGYES
  JR VISSZA
NULLAS

Helyett.
Code: [Select]
KETTES
  LD E,5
EGYES
  LD A,E
  INC E
  OUT (0B5H),A
  IN A,(0B6H)
  RRCA
  RL C
  DJNZ EGYES
  LD A,C
  CPL
  AND 1FH
  LD L,A
  RET
NULLAS
Asmon ban jó
BASIC-ben csak a 0 -ás jó
Title: Re: Assembly programozás
Post by: geco on 2019.July.29. 11:31:33
Az INC E rossz helyen van az OUT után kéne lennie, vagy ha előtte van ,akkor az E bemeneti értéke 0ffh, vagy 04h kellene legyen.
Title: Re: Assembly programozás
Post by: Ferro73 on 2019.July.29. 13:29:22
Az INC E rossz helyen van az OUT után kéne lennie, vagy ha előtte van ,akkor az E bemeneti értéke 0ffh, vagy 04h kellene legyen.
Miért?
Title: Re: Assembly programozás
Post by: geco on 2019.July.29. 13:34:05
Miért?
ja, bocs, nincs rossz helyen :D, a növelés előtt már beteszed A-ba :D
Title: Re: Assembly programozás
Post by: Ferro73 on 2019.July.29. 18:28:00
a DEC L nem állítja a C flaget, helyette használhatod a
Code: [Select]
 org 1000h
  DEC L
  INC L
  JR Z,NULLAS
  DEC L
  LD E,H
  LD BC,500H
  JR Z,EGYES
.
.
.
Ez viszont nem volt rossz ötlet.
Title: Re: Assembly programozás
Post by: endi on 2019.August.02. 10:01:03
van itt pár dolog, hátha nekünk is használhatóak
http://z80-heaven.wikidot.com
Title: Re: Assembly programozás
Post by: Spidermans Friend on 2021.July.09. 22:36:51
Kis segítségkérés. ASM szöveges file-t (PC-n van) szeretnék EP-n (emuban) betölthető, futtatható programmá fordítani.
Mivel tegyem?

SJAsm hibákat dob az egészre, mindent labelnek vesz.

SJAsmEP-ből hol találok Win futtatható verziót?
Title: Re: Assembly programozás
Post by: geco on 2021.July.09. 22:48:29
ugy emlexem itt a forumon van ep verzio futtathato, de ha nem talalod meg, tudok kuldeni. A label problema meg azert van, mert minden az elso oszloban kezdodik, ami nem label, told be legalabb egy space-szel.
Title: Re: Assembly programozás
Post by: Spidermans Friend on 2021.July.10. 12:08:55
ugy emlexem itt a forumon van ep verzio futtathato, de ha nem talalod meg, tudok kuldeni. A label problema meg azert van, mert minden az elso oszloban kezdodik, ami nem label, told be legalabb egy space-szel.
Kösz, így már működik!
Egyelőre próbálkozom a simával. A Hello World már megy. :D
Title: Re: Assembly programozás
Post by: geco on 2021.July.10. 12:53:55
A simában pár kényelmi funkció nincs meg alapból, mint pl az EXOS file header, az EXOS hívás, label export, és még pár hasznos funkció, de ezek nélkül is jól el lehet lenni.
Title: Re: Assembly programozás
Post by: Povi on 2021.November.29. 18:04:35
volt már ez a kérdés, de nem találom...

exos 5 esetében a 0100h alatti területre meddig nyújtózkódhatok?
Title: Re: Assembly programozás
Post by: geco on 2021.November.29. 18:42:04
Nekem a 0080h rémlik.
Title: Re: Assembly programozás
Post by: Zozosoft on 2021.November.29. 18:43:22
exos 5 esetében a 0100h alatti területre meddig nyújtózkódhatok?
005Bh

Valamint saját (5-ös fejlécű) program esetén a 0000-002Fh is szabad préda.
Title: Re: Assembly programozás
Post by: Ferro73 on 2021.November.30. 21:57:02
exos 5 esetében a 0100h alatti területre meddig nyújtózkódhatok?

Ha nem használsz több EXOS xx kódot akkor az egész 00h-FFFFh mindet.
Title: Re: Assembly programozás
Post by: Tuby128 on 2021.December.01. 01:15:21
Ez így nem igaz. A 0x38 vagy 038h a megszakítási vektor. Oda legalább egy C9-et kell akkor írni.
Title: Re: Assembly programozás
Post by: Ferro73 on 2021.December.01. 19:48:15
Ez így nem igaz.
Ez így nem teljesen igaz.
Meg akkor a ??? 0066h NMI  re is kell. Ki tudja milyen harware-ek lehetnek másoknál.
de akkor már felül írtad.
És ha IM2 használsz ?
Akkor már szabadon használhatod.
Title: Re: Assembly programozás
Post by: geco on 2021.December.01. 19:56:28
ha di mellett fut a minden is,akkor a full memoriat lehet :-D , de ugyi akkor a soft reset is buko,
Title: Re: Assembly programozás
Post by: Ferro73 on 2021.December.02. 21:05:46
ha di mellett fut a minden is,akkor a full memoriat lehet :-D , de ugyi akkor a soft reset is buko,
Mivel az EXOS-t kiiktatod.
Title: Re: Assembly programozás
Post by: Zozosoft on 2023.November.30. 10:53:01
Mindenki oda van a ChatGPT-ért, hogy hú micsoda profi programozó, aztán még egy 4 soros Z80 programban se képes észrevenni a hibát... :twisted:

User
Mit csinál a következő programkód:
Code: ZiLOG Z80 Assembler
  1.         ld hl,1000
  2. ciklus  dec hl
  3.         jr nz,ciklus
  4.         ret

ChatGPT
A megadott Z80 gépi kód egy egyszerű programot valósít meg, amely a HL regiszterben tárolt értéket csökkenti 1-gyel, majd ágazik vissza a ciklus címkehez, amíg HL nem lesz nulla. A program végén visszatér (ret).

Itt van a kód részletes elemzése soronként:

ld hl, 1000: Betölti a HL regisztert 1000 értékkel.

ciklus: Címkéz egy ciklust, itt kezdődik a tényleges ciklus rész.

dec hl: Csökkenti a HL regiszter értékét 1-gyel (decrement).

jr nz, ciklus: Ugrás a ciklus címkéhez, ha a NZ (not zero) flag beállítva van (azaz HL nem nulla). Tehát, ha HL nem nulla, akkor az ugrás végrehajtódik, és a program visszatér a ciklus elejéhez.

ret: Visszatér a főprogramhoz, vagyis a program befejeződik.

Ez a kód egy egyszerű ciklust valósít meg, amely a HL regiszter értékét csökkenti egészen addig, amíg el nem éri a nulla értéket, majd visszatér a főprogramhoz.

User
Igen, ez lenne a feladata, viszont hibásan működik, soha nem tér vissza. Felismered hol a hiba?

ChatGPT
Igen, látom a problémát a programkódban. A hiba a következő sorban van:

Code: ZiLOG Z80 Assembler
  1. jr nz, ciklus
Ez a parancs a ciklus címkére ugrana, ha a NZ flag beállítva van, tehát a HL regiszter értéke nem nulla. Azonban, mivel az dec hl után azonnal ellenőrizve van a feltétel, a NZ flag mindig beállítva lesz (mivel a Z flag csak akkor lesz beállítva, ha az érték nulla).

A helyes megoldás az, ha az jr nz, ciklus helyett az jr c, ciklus utasítást használjuk. Tehát:

Code: ZiLOG Z80 Assembler
  1. jr c, ciklus
Ez azt jelenti, hogy az ugrás csak akkor történik meg, ha a carry flag be van állítva, ami azt jelenti, hogy az hl értéke kisebb volt, mint 0 (vagyis nem nulla). Ezzel a módosítással a program helyesen működni fog, és a ciklus végén visszatér a ret utasítással.

User
Nem ez a hiba. A módosított programmal pedig már egyből hl=999 értéknél visszatér.

ChatGPT
Elnézést a korábbi félreértésért. Az általad említett kódban valóban látható egy kis probléma, amely miatt a program soha nem tér vissza. Az jr nz, ciklus utasítás mindig végrehajtódik, mert a dec hl mindig beállítja a Z flag-et (Zero flag), így soha nem lesz az NZ (not zero) feltétel igaz.

A javítás érdekében cseréld le az nz feltételt z-re az jr utasításban. Tehát a következőképpen módosítsd:

Code: ZiLOG Z80 Assembler
  1. ld hl, 1000
  2. ciklus dec hl
  3.       jr z, ciklus
  4.       ret
Ez az jr z, ciklus utasítás azt jelenti, hogy az ugrás csak akkor történik meg, ha a Z flag beállítva van (azaz HL nulla). Így a program végrehajtja a ciklust, amíg HL el nem éri a nullát, és visszatér a ret utasítással.

User
Ez a változat sem jó, ennél is már 999-nél visszatér.

ChatGPT
Elnézést a félrevezető válaszokért. A probléma forrása az, hogy az jr utasítás z feltételével való ugrás csak akkor fog megtörténni, ha a Z flag éppen most váltott értéket, tehát a dec hl után. Ha azonban az hl értéke már nullán van, és a dec hl után a Z flag már be van állítva, akkor az jr z, ciklus nem ugrál tovább, mert a Z flag nem fog újra nullára váltani.

Egy lehetséges megoldás az lehet, hogy használj egy másik feltételt az ugráshoz, például a jp nz, ciklus-t. Így a jp (jump) utasítás mindig a ciklus címkére fog ugrani, kivéve, ha HL nullára csökken, amikor a jp utasítás helyett a ret végzi el a visszatérést. Íme a módosított kód:

Code: ZiLOG Z80 Assembler
  1. ld hl, 1000
  2. ciklus dec hl
  3.       jp nz, ciklus
  4.       ret
Ez a kód addig folytatja a ciklust, amíg HL nem éri el a nullát, és csak akkor tér vissza.

User
Elárulom a megfejtést: Z80-nál a 16 bites INC/DEC utasítás nem állítja a flageket, így nem lehet használni a feltételes utasításokat az eredmény ellenőrzésére. Ennek figyelembevételével el tudnád készíteni a javított programkódot?

ChatGPT
Természetesen, most már megértve a problémát, itt van a javított Z80 gépi kód:

Code: ZiLOG Z80 Assembler
  1. ld hl, 1000   ; Kezdeti érték betöltése HL-be
  2. ciklus dec hl ; HL értékének csökkentése
  3.       ld a, h ; HL magasabb byte betöltése az A regiszterbe
  4.       or l    ; A regiszter összeadása az AL alacsonyabb byte értékével (hasonlóan az OR utasításhoz)
  5.       jr nz, ciklus ; Ugrás a ciklushoz, ha az A regiszter nem nulla
  6.       ret    ; Visszatérés, ha az A regiszter nulla
Ebben a kódban a ld a, h utasítással a HL regiszter magasabb byte-ja kerül az A regiszterbe. Az or l utasítással az A regiszter értéke összeadódik az L regiszter értékével, mivel az or utasítás hatása hasonló az összeadáshoz. Ezután az jr nz, ciklus utasítás csak akkor ugrál vissza a ciklushoz, ha az A regiszter nem nulla.

Ez a módszer segít kijátszani azt a korlátozást, hogy az INC/DEC utasítások nem állítják be a Z flag-et a Z80 processzoron.
Title: Re: Assembly programozás
Post by: gflorez on 2023.November.30. 11:20:04
Az én szemszögemből nézve ezek a mesterséges intelligenciák nem annyira intelligensek. Az összes emberiséggel kapcsolatos információ birtokában vannak, amit mi adtunk nekik ingyen. De az intelligencia felhalmozódik, és szükségük van az új módszerek megtapasztalására, egy bizonyos őrületre.

Azt mondtam, hogy őrültség? Ez nem az a tulajdonság, amit mi akarunk ezektől az eszközöktől...

--------

From my point of view, these AIs are not so intelligent. They have all the Mankind information, that we gave them for free. But intelligence is accumulative and need experiencing new ways of doing things, a certain madness.

Did I say madness? It is not a quality we want on these tools...
Title: Re: Assembly programozás
Post by: pear on 2023.December.01. 08:20:10
In my opinion, it's not about madness, but about making mistakes.
It is mistakes that lead to new solutions.
This won't happen in AIs (unless in quantum computers).
----------
Véleményem szerint nem az őrületről van szó, hanem a hibákról.
A hibák vezetnek új megoldásokhoz.
Ez nem fog megtörténni MI-kben (kivéve, ha kvantumszámítógépekben).
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.06. 21:25:30
Valaki meg tudná nekem mondani, hogy az Indexregiszteres címzés az összeadással mire jó?

PL: LD A, (IX+d)

Nekem az jutott először eszembe, hogy egy dimenziós char (8 bites) tömb elérésére lehet alkalmas. 16 bitesre már nem jó, mert nincs benne szorzás. (habár a 2-vel és 4-gyel való szorzás bit-shift-tel könnyen megoldható lenne)
Viszont aztán rájöttem, hogy a +d egy konstans amit a OP-kód után adunk meg, emiatt nem is lehet vele dinamikusan tömböt indexelni.

 Egyedül azt tudom elképzelni, hogy a memóriába tettünk változókat egy adott címtől kezdve,
pl.
0. cím -> első változó (1 byte-os)
1. cím -> második változó (1 byte-os)
2. cím -> harmadik változó alsó 8 bites értéke (2 byte-os)
3. cím -> harmadik változó felső 8 bites értéke (2 byte-os)

És akkor így is hivatkozik rá:
LD A,0x23
LD (IX+0),A  - elsó változóba töltjük 0x23 értéket

LD HL,0xAB12
LD (IX+2),L
LD (IX+3),H - harmadik változóba töltjük a 0xAB12 értéket

Ugye ez a megoldás akkor kell, amikor egy szubrutinban több lokális változónk van, mint amennyi regiszter elérhető (BC,DE,HL,IX,IY)

Hátránya ennek a megoldásnak, hogy az indexregiszteres utasítások op kódjai 1 BYTE-tal hosszabbak mint a "normál" regiszteres utasítások, emiatt lassabb a végrehajtása ha tömegesen fordul elő.
Valahol olvastam, hogy némelyik Z80 C-fordítóval az a baj, hogy túlságosan sokat használja az indexregisztereket, ezzel hosszabb lesz a programkód illetve tovább tart a végrehajtás.

Visszatérve a hozzászólás elejére. Vajon egy és kétdimenziós tömböt hogyan lehet indexelni Assembly kóddal a legjobban?
Title: Re: Assembly programozás
Post by: geco on 2023.December.06. 21:37:58
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.
Title: Re: Assembly programozás
Post by: geco on 2023.December.06. 21:53:56
Bocs, a 100h-s cimre beallitott tabla kicsit felreertelmezheto volt, a lenyeg az, hogy a tabla alacsony bajtja 00h-n legyen, tehat a tabla kezdocime xx00h legyen, lehet 1300h, 8000h, 9100h, a kodtol fuggoen, szerintem az osszes assemblerben konnyen beallithato, a sjasm-ban pl ha a kododban akarod beloni, akkor a
  defs low -$
tabla_kezdete:
 ezt az igazitast megoldja, egyszerubb megoldas, ha a kodon kivulre helyezed fixen, eleg ennyi:
tabla_kezdete equ 0c000h
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.06. 23:10:04
Írtam papíron egy egyszerű c programot amely egy két dimenziós tömböt manipulál:

Ansi C kód 4x4-es tömb, minden második sorát inicializáljuk 255-tel.
Code: [Select]
{
char x=4;  // ezek csak a tömb mérete miatt vannak deklarálva
char y=4;  // ezek csak a tömb mérete miatt vannak deklarálva
char tomb[4][4]; // nem inicializált
char i;
char j:
for (i=0;i<x;i=i+2)
  {
   for (j=0;j<y;j++)
    { tomb[i][j]=255;}
  }
}





Memóriaszervezés:


Code: [Select]
IndexRegiszter kezdőcím +
0. char x
1. char y
2. base address LOBYTE : char TOMB[i][j] - vegyük úgy, hogy a végrehajtáskor már valahova mutat
3. base address HIBYTE : char TOMB[i][j]
4. char i
5. char j

Assembly code (kézzel írtam index regiszter használatával)
Code: [Select]
INIC_FOR_i:
 LD(IX+4),0   ; for(i=0;.....)
FOR_i:
 LD A,(IX+4)  ;A <- char i
 LD L,(IX+0)  ;L <- char x
 CMP L        ;for(...;i<x;...)
 JR C, END_FOR_i ; elöl tesztelt for_i addig hajtjuk végre a ciklust amíg igaz: i<x
INIC_FOR_j:
 LD (IX+5),0  ;for(j=0;.....)
FOR_j:
 LD a,(IX+5)  ;A <- char j
 LD L,(IX+0)  ;L <- char y
 CMP L        ;for(...;j<y;...)
 JR C, END_FOR_j ; elöl tesztelt for_j addig hajtjuk végre a ciklust amíg igaz: j<y
 LD L,(IX+2)
 LD H,(IX+3)  ; HL <- base address of char tomb[][]
 LD BC,HL   ; BC <- base address of char tomb[][]
; most jön a tömb indexelt címének meghatározása: BASE_ADDR + 4*i + j
; elöször 4*i kiszámolása
 LD A,(IX+4) ; A <- char i
 SLA A
 SLA A ; 2x szorzás 2-vel a tömb 2. dimenziója miatt, itt kicsit megdöbbentem, hogy a Z80 nem kérdi, hányszor akarok léptetni
 LD DE,0
 LD E,A      ; DE <- 4*i
 LD HL,0
 LD L,(IX+5) ; HL <- char j
 ADD HL,DE   ; 4*i + j
 ADD HL,BC   ; BASE_ADDR + (4*i+j)
 LD (HL),255 ; tomb[i][j]=255;
 LD A,(IX+5) ; A <- char j
 INC A      ; A++
 LD (IX+5),A ; for(........;j++)
 JR FOR_j ; for(j... a növelés után visszaugrik elöltesztelésre
END_FOR_j:   ; ciklus vége
 LD A,(IX+4) ; A <- char i
 ADD A,2 ; A=A+2
 LD (IX+5),A ; for(........;i=i+2)
 JR FOR_i ; for(i... a növelés után visszaugrik elöltesztelésre
END_FOR_i:   ; ciklus vége
 RET
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.06. 23:11:05
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?
Title: Re: Assembly programozás
Post by: ergoGnomik on 2023.December.07. 08:01:14
Valaki meg tudná nekem mondani, hogy az Indexregiszteres címzés az összeadással mire jó?

PL: LD A, (IX+d)
Nem tudom megmondani, de nekem úgy tűnik, mintha kifejezetten jól használható lenne felhasználó által definiált, összetett típusok kezelésénél. struct { típus1 mező1; ... };
Title: Re: Assembly programozás
Post by: geco on 2023.December.07. 11:38:15
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ó
Title: Re: Assembly programozás
Post by: geco on 2023.December.07. 11:52:27
itt van egy rövidebb, és index regiszter mentes megvalósítás:
Code: [Select]
tomby   db      04h           ;i
tombx   db      04h           ;j
tombstr defs    tombx*tomby

        ld      hl,tombstr
        ld      bc,(tomby) ;i=4,j=4
        ld      e,b             ;tombx
        ld      d,00h
        ld      a,255
fori    push    bc
forj    ld      (hl),a
        inc     hl
        djnz    forj            ;j--
        pop     bc
        add     hl,de           ;minden páratlan sort átugorjuk
        dec     c               ;i=i-2
        dec     c
        jr      nz,fori
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.07. 12:08:32
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.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.07. 12:22:33
Ez az utasítás mit csinál?

LD HL,(nn)  ;ED 6B nn

Közben megtaláltam:
Title: Re: Assembly programozás
Post by: kvaczko on 2023.December.07. 14:14:43
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)


PUSH HL
POP BC
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.07. 15:42:25
Nézegettem a végrehajtási időket:

PUSH HL - 0xE5 - 11 cycles
POP BC - 0xC1 - 10 cycles

LD B,H - 0x44 - 4 cycles
LD C,L - 0x4D - 4 cycles

A köztes memória hozzáférés teszi lassúvá a veremkezelést.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.08. 16:22:18
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.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.08. 20:49:08
Mi történik akkor, ha a egy valódi z80 egy illegális utasítást kap. Itt most nem a nem-dokumentált utasításra gondolok, hanem egy tényleg nem létező utasításra.
Egy opkódos utasításból nincs ilyen, de pl ED után ha C0 ... FF áll, akkor az nem létezik.
Ilyenkor mi van? Hogyan reagál rá a programszámláló? Átugorja a második opkódot és folytatja tovább a dolgát?
Title: Re: Assembly programozás
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.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.08. 21:25:06
De mi volt pontosan. Emlékszel még?
Title: Re: Assembly programozás
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.
Title: Re: Assembly programozás
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.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.09. 00:56:26
->
Title: Re: Assembly programozás
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.   
Title: Re: Assembly programozás
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.
Title: Re: Assembly programozás
Post by: Ferro73 on 2023.December.10. 13:24:57
Roppant egyszerű ha van eredeti "valós" géped elindítod az ASMON-t
Editbe beírod
Code: [Select]
org 1000h
 ...
 ...
 DB 0EDh,xx
 RET
 RET
 RET
 RET
 END
lefordítod
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.
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.10. 16:56:35
Hogy lehet track-olni asmonban?
Title: Re: Assembly programozás
Post by: Ferro73 on 2023.December.10. 19:50:53
Bocsi régen használtam "TRACE memory"
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.20. 02:19:40
z88dk a következő assembly kódot generálta
Amit nem értek, a ".i_63" alatt 4 sorral a CCF utasítás. Elvégzi a kivonást, majd törli a flaget, végül ugrik, ha Carry=0. Márpedig a Carry a CCF után nulla lesz.

Code: [Select]
ld hl,0 ;const
add hl,sp
inc (hl)
.i_63
ld h,0
ld a,2
sub l
ccf
jp nc,i_62 ;
ld hl,(_Control)
ld h,0
ex de,hl
ld h,0
call l_eq
jp c,i_65 ;
ld hl,(_Control+1)
ld h,0
ex de,hl
ld h,0
call l_eq
jp nc,i_64 ;
.i_65
ld de,_Joy
ld h,0
add hl,de
push hl
ld hl,105 ;const
push hl
ld l,4
add hl,sp
ld l,(hl)
ld h,0
push hl
call _Get_Joy
pop bc
pop bc
pop de
ld a,l
ld (de),a
jp i_61 ;EOS
.i_62
inc sp
ret
Title: Re: Assembly programozás
Post by: ergoGnomik on 2023.December.20. 06:15:55
Nagyon nem vagyok képben a Z80-nal, de véletlenül nem azért van, hogy ne kelljen abszolút ugrást használnia, hanem elég legyen a relatív? Ilyesféle abúzust én is követek el időnként 6502 assemblyben.
Title: Re: Assembly programozás
Post by: Povi on 2023.December.20. 09:00:16
z88dk a következő assembly kódot generálta
Amit nem értek, a ".i_63" alatt 4 sorral a CCF utasítás. Elvégzi a kivonást, majd törli a flaget, végül ugrik, ha Carry=0. Márpedig a Carry a CCF után nulla lesz.
A CCF nem clear carry flag, hanem COMPLEMENT carry flag.
Azaz invertálja a carry-t. Így már van értelme utána a JP NC utasításnak.
Title: Re: Assembly programozás
Post by: Povi on 2023.December.20. 09:01:17
ne kelljen abszolút ugrást használnia, hanem elég legyen a relatív?
A JP az abszolút ugrás, a JR lenne a relatív. (Jump Relative)
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.20. 14:58:33
Miért kell a Carry Flag-et invertálni? Nem elég JUMP NC helyett JUMP C-t használni?
Title: Re: Assembly programozás
Post by: Tuby128 on 2023.December.20. 15:56:31
Közben olvasom valahol, hogy
OR A - törli a CARRY-t
SCF - beállítja a CARRY-t
CCF - Invert Carry

Gondolom azért választottak utóbbinak ilyen hülye nevet a ZILOG-nál, mert ezzel akarták bizonyítani, hogy nem hasonlít az Intel 8080-ra a Z80 :D
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.02. 22:43:09
Egy 76KB-os fájlt szeretnék betölteni a F4-F5-F6-F7-F8 szegmensekre.
Valaki megosztana egy gépi kódot, ezt hogyan tehetem meg?
A program a nullás lapon lenne, és a 1-es lapra lenne belapozva a F4 majd az F5... stb.

Köszönöm!
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.03. 00:51:20
Közben megvan. Kicsit összezavarodtam azon, hogy EXOS 1 vagy 2 kell-e. De aztán azt mutatta a teszt, hogy 1 az olvasáshoz, 2 pedig íráshoz van.
Ezen kívül ki kellett lesnem, hogy a fájl név hossza az hogyan van meghatározva. Hát úgy, hogy az első byte adja meg a hosszát.
Nem ellenőrzök exos visszatérési értéket, mea culpa.

Code: [Select]
                ORG 1000H

                ;open file for read
                LD DE,fname
                LD A,10 ; channel NR 10
                EXOS 1

                ;page segment F4 to 1.page
                LD A,0F4h  ; first segment
chpage          PUSH AF

                LD c,0B1h
                OUT (c),A ; page segments F4..F5..F6.. etc to 1.page

                ;load file to the selected segment
                LD DE,04000H
                LD BC,04000H
                LD A,10
                EXOS 6

                POP AF
                INC A
                CP 0F9h ; until F8
                JR  C,chpage

                LD A,10 ; close channel
                EXOS 3
                RET

                NOP
                NOP
fname           DEFB 11,"TST4_EP.BMP"  ; file name with lenght
                NOP
                NOP
Title: Re: Assembly programozás
Post by: Zozosoft on 2024.January.04. 10:31:25
Quote
                LD c,0B1h
                OUT (c),A ; page segments F4..F5..F6.. etc to 1.page
Így egyszerűbb, és két bájttal rövidebb:
OUT (0B1h),A

További tippek:
0-ás csatorna használata, ezáltal az EXOS hívásoknál az LD A,n utasítás helyett XOR A használható, ami egy bájttal rövidebb.
Ha pedig majd hibakezelés is teszel bele, akkor az EXOS hívás után lesz egy JP vagy JR NZ, ami után (a nincs hiba esetben) 0 lesz az A-ban, tehát azt már nem kell megadni, így a XOR A is megspórolható.
Példa:
Code: ZiLOG Z80 Assembler
  1. XOR A
  2. LD DE,FILENAME
  3. EXOS 1
  4. JR NZ,ERROR
  5. LD BC,LENGTH
  6. LD DE,START
  7. EXOS 6
  8. JR NZ,ERROR
  9. EXOS 3

A másik a ciklus változó használata. Ezt a veremben mented el, így a PUSH/POP kétszer 2 bájtos memória hozzáférést eredményez.
Célszerűbb a háttér A használata, az EX AF,AF' esetén nincs memóriaművelet, csak CPU-n belüli, így jóval kevesebb órajel alatt végrehajtódik.
Másik megoldás, hogy ott van még a HL regiszter szabadon, amit nem érintenek az EXOS hívások, így az L használható ciklusváltozónak. A regiszterek közti LD szintén gyorsabb, és egyet megspórolunk, mert végén lehet közvetlen INC L, így csak az OUT elé kell (a PUSH helyére) kell egy LD A,L, így egy bájttal rövidebb is lesz a programkód.
Code: ZiLOG Z80 Assembler
  1.                 LD DE,fname
  2.                 XOR A ; channel NR 0
  3.                 EXOS 1
  4.  
  5.                 ;page segment F4 to 1.page
  6.                 LD L,0F4h  ; first segment
  7. chpage          LD A,L
  8.  
  9.                 OUT (0B1h),A ; page segments F4..F5..F6.. etc to 1.page
  10.  
  11.                 ;load file to the selected segment
  12.                 LD DE,04000H
  13.                 LD BC,04000H
  14.                 XOR A
  15.                 EXOS 6
  16.  
  17.                 INC L
  18.                 CP 0F9h ; until F8
  19.                 JR  C,chpage
  20.  
  21.                 XOR A ; close channel
  22.                 EXOS 3
  23.                 RET

Összesen 6 bájt megspórolva. Nyilván jelen esetben tök mindegy :lol: de jobb már ez elején rászokni rövidebb és gyorsabb kód írására!
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.04. 15:05:05
Emlékeztet a programozási fogások és melléfogások rovatra az ENTERPRESS-ből :D
Köszönöm a tippeket. Nem is gondoltam volna, hogy 0-ás csatorna van. Basicben is megadhatom?
Title: Re: Assembly programozás
Post by: Zozosoft on 2024.January.04. 15:26:18
Nem is gondoltam volna, hogy 0-ás csatorna van. Basicben is megadhatom?
Már maga a BASIC használja, az EDITOR van 0-ásnak nyitva.
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.04. 16:01:51
Tényleg van már eszembe jutott.
 Akkor visziont figyelni kell, hogy ha a gépi kódot basic-ben hajtom végre, akkor nem fog működni, mert már nyitva van az Editor, ugye?
Title: Re: Assembly programozás
Post by: Ferro73 on 2024.January.04. 20:50:43
Code: ZiLOG Z80 Assembler
  1.                 LD DE,fname
  2.                 XOR A ; channel NR 0
  3.                 EXOS 1
  4.  
  5.                 ;page segment F4 to 1.page
  6.                 LD L,0F4h  ; first segment
  7. chpage          LD A,L
  8.  
  9.                 OUT (0B1h),A ; page segments F4..F5..F6.. etc to 1.page
  10.  
  11.                 ;load file to the selected segment
  12.                 LD DE,04000H
  13.                 LD BC,04000H
  14.                 XOR A
  15.                 EXOS 6
  16.  
  17.                 INC L
  18.                 CP 0F9h ; until F8
  19.                 JR  C,chpage
  20.  
  21.                 XOR A ; close channel
  22.                 EXOS 3
  23.                 RET

Összesen 6 bájt megspórolva. Nyilván jelen esetben tök mindegy :lol: de jobb már ez elején rászokni rövidebb és gyorsabb kód írására!
A 17. és a 18. sor közé nem hiányzik egy LD A,L  ?
Úgy emlékszem a CP 0F9h  C flag=A-0F9h A változatlan.
Title: Re: Assembly programozás
Post by: Zozosoft on 2024.January.04. 21:00:03
A 17. és a 18. sor közé nem hiányzik egy LD A,L  ?
Úgy emlékszem a CP 0F9h  C flag=A-0F9h A változatlan.
Nyertél :oops:
Title: Re: Assembly programozás
Post by: Ferro73 on 2024.January.04. 21:12:55
A 19. sor  JR NZ,chpage esetleg ?
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 00:08:31
Kellene nekem valami, hogy a kép léptetést időzítsem. A video megszakítás 50 Hz-es jele jó lehet alapnak.
Az EXOS-nak nincs valami számlálója a renszerszegmensen, ami minden video megszakítás után eggyel növekszik?
Nekem bőven elég lenne lekérdezni az értékét.
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 00:21:53
Ezek mik a 255-es lapon?
FFF0 kb. 1s inkrementjei
FFEC ? Hz inkrementjei
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 01:44:18
Még egy kérdés. Kicsit hiányosnak érzem a Z80 utasításkészletet. Ha el akarok számolni 1-től 2115-ig, és közben valamit csinálni, akkor hogyan tudom leellenőrizni, hogy elértem az 2115-öt?
CMP (vagy SUB) utasítást használnék alapból, de ahogy látom ezek csak 8 bitre érvényesek.
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 02:43:03
Ha lemezre írni akarok, akkor EXOS 1 vagy EXOS 2 kell? Mi van ha a lemezen a fájl név már létezik?
Title: Re: Assembly programozás
Post by: Ferro73 on 2024.January.05. 07:27:33
Ha lemezre írni akarok, akkor EXOS 1 vagy EXOS 2 kell? Mi van ha a lemezen a fájl név már létezik?
Exos 2
Title: Re: Assembly programozás
Post by: geco on 2024.January.05. 08:54:57
A 19. sor  JR NZ,chpage esetleg ?
Jó a jr c,chpage, ha a számláló eléri az 0f9h-t akkor nem lesz carry, előtte meg de,így az utolsó futás 0f8h-nál lesz.
Title: Re: Assembly programozás
Post by: geco on 2024.January.05. 09:16:19
Még egy kérdés. Kicsit hiányosnak érzem a Z80 utasításkészletet. Ha el akarok számolni 1-től 2115-ig, és közben valamit csinálni, akkor hogyan tudom leellenőrizni, hogy elértem az 2115-öt?
CMP (vagy SUB) utasítást használnék alapból, de ahogy látom ezek csak 8 bitre érvényesek.
Nem hiányos, ha a z80 utasításkészletét érzed hiányosnak, akkor vess egy pillantást a 6502-ére, de akár a 6809-ére is.
egy lehetséges megoldás:
Code: [Select]
        ld bc,2115
loop    push bc
        futtatandó kód
        pop bc
        dec bc
        ld a,c
        or b
        jr nz,loop
Title: Re: Assembly programozás
Post by: ergoGnomik on 2024.January.05. 11:44:52
A Z80 utasításkészletét hiányosnak érezni számomra fundamentális félreértésnek tűnik. Szerintem pontosan kielégíti azokat a tervezési célokat, amit kitűztek a Zilogos fiúk az Intelből történő kiválásuk után. Ha valami hiányos, az az i8080 utasításkészlete. :ds_icon_cheesygrin:
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 16:09:38
Nem hiányos, ha a z80 utasításkészletét érzed hiányosnak, akkor vess egy pillantást a 6502-ére, de akár a 6809-ére is.
egy lehetséges megoldás:
Code: [Select]
       ld bc,2115
loop    push bc
        futtatandó kód
        pop bc
        dec bc
        ld a,c
        or b
        jr nz,loop

Geco ez akkor azt jelenti, hogy 0 tól x-ig felejtsem el a számolgatást, és szokjam meg hogy x-től 0-ig kell visszafelé számolni?
Title: Re: Assembly programozás
Post by: ergoGnomik on 2024.January.05. 16:37:52
Nem muszáj, csak így hatékonyabb. Lehet előre is, de akkor külön kell hasonlítgatni a célérték alsó és felső bájtjához a B és C pillanatnyi értékét, ami több helyet foglal és lényegesen lassabb. Azonban előállhat néhanapján olyan helyzet, amikor a számlált értéket még külön fel is akarod használni. Ilyenkor megtörténhet, hogy az előre számlálás járulékos költségei ellenére is érdemes azt használni. De a gyakorlatban a visszafelé számlálás legtöbbször előnyösebb.
Title: Re: Assembly programozás
Post by: BruceTanner on 2024.January.05. 16:59:49
Eg:
Code: [Select]
        ld bc,0
loop    push bc
        futtatandó kód
        pop bc
        inc bc
        ld hl,2115
        or a         ; Clear carry because there isn't SUB HL,rr
        sbc hl,bc
        jr nz,loop
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.05. 17:03:24
I remember that there was something with 16bit subtraction (CP HL,BC is missing). Unfortunately this code destroys the Value of the HL, but in the case you choosen, its not a problem.
Thanks!

One thing to mention OR A is becasue CCF (Change Carry Flag?) does not clear, it inverts the Carry, so there is no other obtion but "OR A".
By using SBC the carry also plays a role, so must be reseted.
Title: Re: Assembly programozás
Post by: Povi on 2024.January.08. 10:02:51
Még egy kérdés. Kicsit hiányosnak érzem a Z80 utasításkészletet. Ha el akarok számolni 1-től 2115-ig, és közben valamit csinálni, akkor hogyan tudom leellenőrizni, hogy elértem az 2115-öt?
CMP (vagy SUB) utasítást használnék alapból, de ahogy látom ezek csak 8 bitre érvényesek.
Vagy csinálsz egy CompareHLBC rutint:
Or you can create a subroutine:

Code: [Select]
CompareHLBC:
ld   a, h
sub  b
ret  nz
ld   a, l
sub  c
ret

Hátránya, hogy lassú, tönkreteszi az A regisztert, de ugyanúgy működik (ugyanúgy álíltgatja a flag-eket), mint a sima CP utasítás.
Disadvantages: slow, destroys A, but works as an 8-bit CP operation (C and Z flag affects).
SUB helyett lehet CP is kódban, tök mindegy.
Title: Re: Assembly programozás
Post by: Povi on 2024.January.08. 10:04:35
CCF (Change Carry Flag?) does not clear, it inverts the Carry
CCF = Complement Carry Flag
Title: Re: Assembly programozás
Post by: geco on 2024.January.08. 10:11:30
Vagy szimplán, ha mindig ugyanaz a zámláló értéke:
Ha gyorsítani akarsz rajta, akkor a JR NZ-ket le lehet cserélni JP NZ-re, de a leggyorsabb a visszafelé számlálás.

Code: [Select]
        ld bc,0000h
loop    push bc
        futtatandó kód
        pop bc
        inc bc
        ld a,c
        cp 43h
        jr nz,loop
        ld a,b
        cp 08h         ;2115 = 0843h
        jr nz,loop
Title: Re: Assembly programozás
Post by: BruceTanner on 2024.January.08. 11:00:14
This use of "complement" is a bit strange: if you look up "complement" in a dictionary it means "to make complete or whole". This is where "twos complement" arithmetic comes from: the twos complement of a byte is the number that makes the total FFh when added. But applied to one bit (the Carry) it is the number that makes it up to 1 when added.

The same phrase is used for many processors, not just the z80.
Title: Re: Assembly programozás
Post by: Tuby128 on 2024.January.08. 12:00:09
The CCF not only inverts the Carry Flag, it also inverts (or just resets?) the Half-Carry flag, and also resets the N Flag (which is not commonly used).

ICF - Invert Carry Flag would a be better name.
Title: Re: Assembly programozás
Post by: Ferro73 on 2024.January.08. 19:30:22
Geco ez akkor azt jelenti, hogy 0 tól x-ig felejtsem el a számolgatást, és szokjam meg hogy x-től 0-ig kell visszafelé számolni?
Nem a BC az csak a progidat futtatja annyiszor amennyiszer akarod
A BC értékét elmentődik ezért a progin belül használhatod bármire.

Valami példa jó volna miért kell 0-2115 miért nem jó  2115-0.