xxl: ocb z tym zejsciem ze slonca? ca65 to zly assembler? co ci sie w nim nie podoba? przerasta cie? ma dokladnie to czego potrzebujesz - skladnie latwiej pozwalajaca na wylapanie bledow, o ktorych wspomniales.

xasm, czy mads maja po prostu inny postulat - zgodnosc z qa + dodatki ktorych _autorom_ brakowalo.
ca65 nie ma balastu qa.
nie rozumiem skad to przywiazanie do qa. lokalny patriotyzm?

@jellonek
> ocb z tym zejsciem ze slonca?

moze wtedy przestanie Ci sie wydawac co jest dla mnie lepsze :-)

> ca65 to zly assembler?

gorszy od MADS. pierwszy argument z brzegu: brak w ca65 supportu dla niepublikowanych stabilnych (wszystkich) za to jest czesc niestabilnych ktore jawnie uznaja za stabilne. sorry.

> nie rozumiem skad to przywiazanie do qa. lokalny patriotyzm?

ja tez nie rozumiem, moze po prostu Tebe go lubi. Na szczescie juz zalatwil sprawe kodow jednobajtowych i komentarzy po nich :-)

może dodam jeszcze dla Tych którzy są oburzeni potrzebą użycia znaku $ dla oznaczenia wartości Hex jest alternatywa, mogą użyć 0x, Candle z lubością tego używa

dla Tych którzy są oburzeni potrzebą kończenia bloku .LOCAL czy innego podobnego tworu odpowiednią dyrektywą .ENDL mogą użyć uniwersalnej wersji i o jeden znak krótszej .END

mogą także użyć klamr znanych z C { }, byle tylko te klamry były w osobnych wierszach

.local name
{
 nop 
 nop
}

czyli dla każdego coś miłego ;)

To ostatnie jest niemiłe, miło jest tak:

.local name {
 nop 
 nop
}

:)

nigdzie nie pisalem co jest dla ciebie lepsze. pisalem jedynie co spelnia twoje wymagania...

laoo: nie wiem by jakies wsparcie ktos robil (nie wiem jakie skladnie obsluguje wusdn, ale po screenach wyglada ze to podobnie, moze?), kazdy robi na wlasna potrzebe. tj. zestaw label pod altirre pewnie by sie szybko zrobilo korzystajac z wyniku -Ln linkera przepuszczonego przez maly zaperlony kod... co do skladni - http://www.cc65.org/doc/ca65.html dokumentacja jest spora.

altirra wczytuje etykiety sama, byle by procz xex'a czy obx'a w katalogu byl jeszcze plik lab
a candle sobie z luboscia czegostam uzywa, bo ma troche wiecej assemblerow do uzywania niz mads i 6502, wiec musi wybierac to, co jest wspolne dla wielu, tak aby nie musiec sie zastanawiac jak dzis powinien zaczac pisac wartosci by byly tym co chce

amen

bebe - po co ta wycieczka?

@epi: Proszę bardzo. Nie wiem jak MADS, ale C++ ma z poprzednikiem dokładnie tyle kompatybilności ile trzeba oraz nie zawiera on żadnych nie do końca przemyślanych ficzerów dodanych z powodu braku porozumienia wśród tych, którym na nich zależało, co z kolei implikuje, że nie istnieją żadne rzekome nieoczywiste szczególne przypadki na styku tychże nieistniejących ficzerów. Nie ma również żadnych śladów nieskoordynowanego rozwoju o czym łatwo się przekonać analizując tryb pracy komisji standaryzacyjnej, a mnogość stylów programowania jest pożądaną cechą i oczywistą konsekwencją wieloparadygmatowości języka.

To oczywiście subiektywna opinia i jeżeli jednak uważasz inaczej, to fajnie jakbyś podał jakieś przykłady, do których można byłoby się odnieść, ale to już chyba w jakimś innym wątku, bo głupio tu tak perfidnie offtopikować.

nowy mads 1.9.4 już jest http://mads.atari8.info

najważniejsza zmiana to możliwość nazywania parametrów makr, czyli większa przejrzystość kodu, łatwiej zrozumieć co makro wyczynia z parametrami

.macro SetColor val,reg
 lda :val
 sta :reg
.endm

.macro SetColor2 (arg1, arg2)
 lda #:arg1
 sta arg2
.endm

p.s.
w planach napisanie nowego kodu obsługującego pętle .REPT tak aby można było je zagnieżdżać, aktualnie aby to obejść trzeba posiłkować się makrami

Coś, co wygląda na błąd w madsie. Program przykładowy:

;
LINES = 20

          org $80

dupa    .ds 2

          blk reloc main

start     lda #<(LINES-1)*40
          sta dupa
          lda #>(LINES-1)*40
          sta dupa+1
          rts

Program powinien obliczyć wartość (LINES-1)*40 = 19*40 = 760, oraz umieścić ją jako młodszy i starszy bajt pod adresem "dupa" i "dupa+1".

Przy próbie asemblacji wyskakuje komunikat:

start   lda #<(LINES-1)*40
dupa.s (10) ERROR: Value out of range

Tymczasem Value nie jest out of range, bo operatory '<' i '>' są (albo: powinny być) brane pod uwagę jako ostatnie. Powinno mu zatem wyjść $F8 z pierwszego wyrażenia i $02 z drugiego (mł. i starszy bajt wartości $02F8 = 760).

Ale to nie koniec.

Powyższy program poprawiamy tak, żeby się kompilował, tzn. w linii, gdzie wyskakuje błąd, dodajemy nawiasy:

;
LINES = 20

          org $80

dupa    .ds 2

          blk reloc main

start     lda #<((LINES-1)*40)
          sta dupa
          lda #>(LINES-1)*40
          sta dupa+1
          rts

Błąd nie wyskakuje, co dziwne, bo powinien się pojawić dokładnie taki sam dwie linijki niżej. Listing:

mads 1.9.4
     1                          ;
     2 = 0014                   LINES = 20
     3
     4                                  org $80
     5
     6 = 0080                   dupa    .ds 2
     7
     8 0082 FE FF 01 00                 blk reloc main
     9
    10 0000,0009> A9 F8         start   lda #<((LINES-1)*40)
    11 0002 85 80                       sta dupa
    12 0004 A9 00                       lda #>(LINES-1)*40
    13 0006 85 81                       sta dupa+1
    14 0008 60                          rts

Pierwsza linijka skompilowała się dobrze, jest LDA #$F8. Co do drugiej, co prawda komunikatu o błędzie nie ma, ale kod jest zły, bo zamiast LDA #$02 w kodzie wynikowym jest LDA #$00.

Zamiast bajkopisarstwa - zasugeruj patcha z poprawka. Zrodla sa dostepne.

Tebe, z całym szacunkiem, gdybym chciał używać chorej składni QA, wybrałbym inny asembler.

ad1 = przecież tak robi

  org $2000

2000 A9  dta {lda #0}
2001 AD  dta {lda $100}
2002 A5  dta {lda $10}