26

Odp: bugi w mads

Hm, masz racje, zmylil mnie ten adres w binarce. Po wywaleniu ini mads poprawnie ostrzega ze jest petla w definicji.
Takze sorry - nie ma problemu :D

"Was powinny uzbrojone służby wyciągać z domów do punktów szczepień, a potem zamykać do pi* za rozpowszechnianie zagrożenia epidemicznego" - Epi 2021
"Powinno się pałować tylko tych co tego nie rozumieją. No i nie szmatki i nie chirurgiczne tylko min FFP3, to by miało jakiś sens. U mnie we firmie, to jak przychodzi bezmaskowiec, to stoi w deszczu przed firmą" - Pin 2021

27

Odp: bugi w mads

Kod źródłowy (dupa.s):

        blk sparta $0600

start   nop
        rts

krupa   .ds 1
strupa  .ds 1

Wygenerowaną binarkę (mads dupa.s) poddajemy działaniu komendy FSTRUCT DUPA.OBX. Wynik:

Size: $000010 (16) bytes

$000000 Head: $FFFA (StdBlk)
$000006  Seg: $0600-$0601 Len: $0002 (2)
$000008 Head: $FFFE (RelBlk)
$000010  Blk: 1, Mem: $80 Len: $0002 (2) Off: $0602

End of file

Mamy blok tu blok binarny o wielkości 2 bajtów (kod, NOP/RTS), ładowany pod $0600, plus blok alokujący 2 bajty nad memlo dla zmiennych krupa i strupa.

Dyrektywy .ds nie powinny tak zadziałać w tym miejscu. W bloku blk sparta powinny się zachować tak samo jak w normalnym bloku binarnym, czyli po prostu zarezerwować miejsce pod $0602 i $0603 dla obu zmiennych.

Blok rezerwacji pamięci powinny generować tylko wtedy, kiedy są użyte wewnątrz blk reloc.

Ostatnio edytowany przez drac030 (2016-03-15 00:11:17)

KMK
? HEX$(6670358)

28

Odp: bugi w mads

taki kod generuje ostatni mads, jakiej wersji używasz Drac030 ?

mads 2.0.1 build 40 (28 Feb 16)
Source: D:\!Delphi\mads\test4.asm
     1  FA FF                    blk sparta $0600
     2
     3 0600-0601> EA        start   nop
     4 0601 60                    rts
     5
     6 = 0602            krupa   .ds 1
     7 = 0603            strupa  .ds 1
     7 0602 FE FF 01 80 02 06 + BLK EMPTY

p.s.
FSTRUCT gdzie znajdę ten program ?

Ostatnio edytowany przez tebe (2016-03-17 16:34:28)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

29

Odp: bugi w mads

Ja mam wersję 2.0.0, nawet sprawdzałem u Ciebie na stronie, czy jest coś nowszego, ale wyglądało mi na to, że nie.

FSTRUCT powinien być na Toolkicie SDX.

KMK
? HEX$(6670358)

30

Odp: bugi w mads

Wychodzi na to, że sam autor zapomina zrelease'ować, no to są jaja :D

.: miejsce na twoją reklamę :.

31

Odp: bugi w mads

po poprawce, mads 2.0.1 http://mads.atari8.info

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

32

Odp: bugi w mads

1. Dzięki, wszystko działa jak trzeba.

EDIT ad 2: nie, wycofuję, problem źle zdiagnozowany.

Ostatnio edytowany przez drac030 (2016-03-20 15:54:43)

KMK
? HEX$(6670358)

33

Odp: bugi w mads

jeszcze raz poprawka v2.0.3, wg moich testów teraz jest OK

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

34

Odp: bugi w mads

Może ktoś się już natknął na coś podobnego?

Użycie znaku podziału wiersza "\" po wywołaniu procedury z parametrem generuje niespodziewany kod:

Edytor:

 opt l+
 org $600 

 test #$10 \ lda #$20
 
.proc test(.byte y) .reg
 rts
.endp

Kod wynikowy:

mads 2.0.4 build 13 (8 May 16)
     2                  opt l+
     3                  org $600 
     4
     5                  test #$10 \ lda #$20
     5                  TEST #$10 
     5                  LDY# $10\ JSR TEST
     5 FFFF> 0600-0608> A0 10     LDY# $10
     5 0602 20 08 06         JSR TEST
     5 0605 20 08 06         JSR TEST
     6                  
     7 0608            .proc test(.byte y) .reg
     8 0608 60             rts
     9                 .endp
    10

Jak widać procedura 'test' wywoływana jest bez powodu drugi raz a reszta linii po "\" jest ignorowana.
Z makrami z parametrami to działa ok.

35

Odp: bugi w mads

Szeryf napisał/a:

Użycie znaku podziału wiersza "\" po wywołaniu procedury z parametrem generuje niespodziewany kod:

po poprawce

mads 2.0.5 http://mads.atari8.info

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

36

Odp: bugi w mads

Działa pięknie.

37

Odp: bugi w mads

MADS blednie kompiluje rozkaz DOP #

    14 4000 48                  .byte { DOP #$FF }
    15 4001 EA                  NOP
    16 4002 48 FF             DOP #$FF
    17 4004 48                  PHA

wczesniejsze wersje madsa w tym zakresie dzialaly prawidlowo.

http://atari.pl/hsc/ad.php?i=1.

38

Odp: bugi w mads

wg http://atariki.krap.pl/index.php/Nieudo … kazy_6502C jest coś takiego

Oficjalnie jest wspierane DOP ? http://mads.atari8.info/mads.html#mnemo   
Widzę NPO

Ostatnio edytowany przez pajero (2017-04-12 19:16:12)

39

Odp: bugi w mads

nielegalne rozkazy działają nielegalnie ;P

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

40

Odp: bugi w mads

pajero napisał/a:

Oficjalnie jest wspierane DOP ?

nieoficjalne kody wspierana sa nieoficjalnie ;D

http://atari.pl/hsc/ad.php?i=1.

41

Odp: bugi w mads

Taki kod:

  blk reloc main
table:
?first .word 0
?last .word 0

table2:
  .byte [table.?last-table.?first]/4

generuje mi: "address relocation overload" !
Oficjalna dokumentacja (w historii) mówi: "błąd 'Addres relocation overload' wystąpi teraz tylko gdy wyrażenie będzie dotyczyć więcej niż jednej etykiety relokowalnej, poprzednio każde wyrażenie z udziałem etykiety relokowalnej powodowało wyświetlenie tego komunikatu błędu".
Ale jaki jest właściwie problem z etykietami relokowalnymi _w_jednym_bloku_? Bo ja rozumiem, gdybyśmy mieli etykietki w róznych blokach - wtedy nie wiadomo jaki będzie między nimi dystans, ale w przypadku jednego bloku wszystko przecież wiadomo...
Dałoby się to naprawić?

Edit: A druga choć związana z poprzednim przypadkiem rzecz jest taka - podobny kod;

  blk reloc main
table:
?first .word 0
?last .word 0
?len = [?last-?first]/4

table2:
  .byte table.?len

się kompiluje poprawnie, ale markuje table2 jako _adres_ do relokacji. A to już jest bardzo nieładne, bo:
1. w table2 mam bajt, a loader SDX zmodyfikuje mi tam 2 bajty,
2. table.?len jest jednak interwałem, który da się określić na etapie kompilacji i on się nie zmieni - nie powinien być relokowalny.
Kod wynikowy wygląda tak:

fe ff 01 00 00 00 05 00 
00 00 00 00 00 

fd ff 01 00 00 
fe 01
04 
fc

Edit2: Co myślałbyś o:
1. generowaniu "Addres relocation overload" tylko przy obliczeniach używających etykiet leżących w różnych blokach relokowalnych,
2. rzucaniu warninga kiedy do obliczeń używane są etykiety relokowalne - user ma być świadom tego co robi, a jak user sobie chce zaszkodzić, to niech sobie szkodzi :)

Ostatnio edytowany przez mono (2017-04-25 12:36:57)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

42

Odp: bugi w mads

Przydałoby się dokładniej wyjaśnić różnicę pomiędzy procedurami i makrami, mam taki kod:

ldx bompka
lda bompka+1
ldy #$7F
jsr trompka

Chciałem być mądry i zapisać sobie to w procedurę:

.proc u_trompka ( .word ax .byte y )
     jsr trompka bompka 
.endp

u_trompka bompka #$7F

Dlaczego kod poniżej generując taki sam listing jak kod powyżej, powoduje w gotowym programie skok do nielegala CIM?
Kiedy zapiszę to samo jako makro, wszystko jest w jak najlepszym porządku.
A listing wciąż rozwija się tak samo…

.: miejsce na twoją reklamę :.

43

Odp: bugi w mads

Taki kod:

     opt c+

     blk reloc main

start pea #proc-1
     rts

proc nop
     rts

Program idzie w maliny, bo dla pea # nie jest generowany fixup, mimo że etykieta "proc" wskazuje adres.

To samo dotyczy rozkazów typu lda #$xxxx, ldx #$xxxx, ldy #$xxxx, adc #$xxxx, sbc #$xxxx itd. itp.

KMK
? HEX$(6670358)

44

Odp: bugi w mads

tak, powinien pojawić się komunikat ostrzeżenia albo błędu, relokowalność jest obecnie tylko dla 6502

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

45

Odp: bugi w mads

Mam take kuszi:

    opt o+ h+ ?+ c-

JCIOMAIN = $e456

    org $660
    rts

    org $bff0,$7ff0
    jmp JCIOMAIN

    run $660

    end

I to wyrzuca mi przy kompilacji MADSem 2.0.6 komunikat:

    run $660
orgtest.asx (13) ERROR: Illegal instruction at RELOC block

Kiedy wywalę definicję etykiety JCIOMAIN i żywcem zastąpię ją adresem wtedy wszystko się kompiluje jak należy.

I co tu począć?

Post's attachments

orgtest.asx 104 b, liczba pobrań: 2 (od 2017-08-05) 

Tylko zalogowani mogą pobierać załączniki.
hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

46

Odp: bugi w mads

błąd powoduje RUN, który znajduje się w bloku z przesunięciem adresu ORG $BFF0,$7FF0

aby nie było błędu należy użyć .LOCAL albo .PROC

 org $bff0

.local nazwa,$7ff0
 jmp JCIOMAIN
.endl

 run $660

teraz taki blok z przesunięciem ma swój początek (.local) i koniec (.endl)

p.s.
rezygnacja z OPT ?+ też załatwi sprawę bez potrzeby wstawiania bloku .LOCAL

Ostatnio edytowany przez tebe (2017-08-06 11:53:57)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

47

Odp: bugi w mads

Dziękuję, działa!

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

48

Odp: bugi w mads

     1                     opt c+
     2                     org $010000
     3 FFFF> 010000-010008> +   test    rts
     4 010001 22 00 00 01        jsr test
     5 010005 5C 00 00 01        jmp test

@Tebe: da się coś zrobić, żeby skoki do tego samego banku były asemblowane jako nie-długie?

Ostatnio edytowany przez laoo/ng (2017-09-20 09:19:11)

49

Odp: bugi w mads

Pewnie tak, przyjrzę się temu

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

50

Odp: bugi w mads

Wydaje mi sie ze jest blad w bibliotece colaczonej do mads'a
Chodzio plik: /examples/LIBRARIES/graphics/lib/circle.asm

nie pasuje mi ten fragment:

;og := mo + y + y + 1;

        lda zpage+zp.mo
        sec                     ; ustawienie znacznika przeniesienia C podczas dodawania
        adc zpage+zp.y          ; spowoduje ze wynik takiego dodawania bedzie zwiekszony o 1
        adc zpage+zp.y
        sta zpage+zp.og

;mo := og;

        sta zpage+zp.mo

;ou := og - x - x + 1;

        clc                     ; skasowanie znacznika przeniesienia C podczas odejmowania
        sbc zpage+zp.x          ; spowoduje ze wynik takiego odejmowania bedzie zwiekszony o 1
        sbc zpage+zp.x
        sta zpage+zp.ou

Nie powinno to wygladac mniejwiecej tak?:

;og := mo + y + y + 1;

        lda zpage+zp.mo
        sec                     ; ustawienie znacznika przeniesienia C podczas dodawania
        adc zpage+zp.y          ; spowoduje ze wynik takiego dodawania bedzie zwiekszony o 1
        CLC
        adc zpage+zp.y
        sta zpage+zp.og

;mo := og;

        sta zpage+zp.mo

;ou := og - x - x + 1;

        SEC                     ; skasowanie znacznika przeniesienia C podczas odejmowania
        sbc zpage+zp.x          ; spowoduje ze wynik takiego odejmowania bedzie ZMNIEJSZONY o 1
        SEC
        sbc zpage+zp.x
        CLC
        ADC #1
        sta zpage+zp.ou

Jezeli sie myle to prosze o wytlumaczenie, ale po tych poprawkach wyniki wyszly mi jednakowe do procedury w pascalu z tej strony:

http://www.atari.org.pl/artykul/kurs-as … a-cz.-8/31

btw. Kto jest autorem tej 8 bitowej implementacji tego algorytmu ? ew skad sie wzielo?

w.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477