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
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
3rd Annual Atari Homebrew Awards Rozpoczęła trzecia edycja głosowania na najlepszą produkcję dla ośmiobitowych maszyn Atari
New Year Disk 2021 Już dostępny
done and dusted
kronika polskiej demosceny
Adam Is Me za darmo Święta tuż, tuż, więc czas rozwiązać worek z prezentami...
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
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
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)
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)
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.
Wychodzi na to, że sam autor zapomina zrelease'ować, no to są jaja
po poprawce, mads 2.0.1 http://mads.atari8.info
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)
jeszcze raz poprawka v2.0.3, wg moich testów teraz jest OK
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.
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
Działa pięknie.
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)
nielegalne rozkazy działają nielegalnie ;P
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)
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…
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.
tak, powinien pojawić się komunikat ostrzeżenia albo błędu, relokowalność jest obecnie tylko dla 6502
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ąć?
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)
Dziękuję, działa!
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)
Pewnie tak, przyjrzę się temu
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.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.091 sekund, wykonano 8 zapytań ]