Enterprise Forever

:HUN => Programozás => 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