Nowa wersja bardzo popularnego cross-compilatora MADS, oznaczona numerkiem 1.9.7, przynosi nam następujące dobrodziejstwa:

• dyrektywa .DEF definiuje etykiety o zasiegu lokalnym, jeśli poprzedzić ją znakiem ':' to globalne
  
• poprawki dla liczb zmiennoprzecinkowych .FL, poprawione kodowane zera, dokonywane zaokrąglenie do 10 miejsc po przecinku
  
• dla bloków Sparta DOS X 'blk reloc' i 'blk empty' dodana możliwość określenia innego typu pamięci niż $00 (main), $02 (extended), np.:
  

  blk reloc $40

• poprawka umożliwiająca użycie dyrektywy .PRINT po 'blk empty'
  
• dodana możliwość definiowania wielowymiarowych tablic .ARRAY, np.:
  

.array scr [24][40]
  [11][16] = "atari"
.enda

  mva #"!" scr[11][22]

• dodana możliwość definiowania tablicy .ARRAY poprzez dyrektywę .DS, np.:
  

tmp .ds .array [5][12][4] .word

• dodana możliwość definiowania tablicy .ARRAY poprzez pseudorozkaz EQU (=), np.:
  

fnt = $e000 .array [128] [8] .byte

• naprawione działanie makrorozkazu ADW w połączeniu z makrorozkazem SCC itp.
  
• poprawki dla .REPT, m.in. komentarz wieloliniowy /* */ jest teraz właściwie rozpoznawany
  
  Narzędzie do pobrania ze strony domowej. Owocnego kodowania!

gorgh 2013-10-02 15:51:24

rok 2023: programy w mads piszą i kompilują się same :)

---

XaVeR 2013-10-02 19:25:39

Ojjj.. to chyba raczej 2123r. Bo 2023 to juz bardzo nieodlegla przyszłość.

---

_Ilmenit 2013-10-03 12:50:07

No, MADS coraz bardziej przypomina język wyższego poziomu.

---

nodez 2013-10-03 20:12:45

ale daje rade

---

gorgh 2013-10-03 21:46:04

co ty nie powiesz?

---

nodez 2013-10-05 17:14:42

no raczej

---

gorgh 2013-10-05 18:17:20

:)

---

Bluki 2013-10-05 20:18:29

Hm. Cóż...

---

candle 2013-10-07 10:02:50

jeszcze Tebe moglby poprawic dzialanie makrorozkazu dew w polaczeniu z bne

---

tebe 2013-10-07 11:32:23

DEW m.in. zmienia akumulator, więc danie tylko BNE bezpośrednio za nim może skończyć się niepowodzeniem, jakieś CMP przed powinno uratować sprawę

DEW $80 to:

LDA $80
SNE
DEC $81
DEC $80

---

0xF 2013-10-07 12:41:22

Celowo nie wprowadziłem DEW do xasm, aby uniknąć tego rodzaju nieporozumień i niejawnego użycia akumulatora.

candle: jeśli chcesz mieć licznik 16-bitowy, to:

a. Licz w drugą stronę (na wartościach ujemnych):
INC cnt
BNE loop
INC cnt+1
BNE loop

b. Wstępnie wprowadź "poprawkę" licznika:
LDA cnt
SEQ:INC cnt+1
i wtedy liczysz tak:
DEC cnt
BNE loop
DEC cnt+1
BNE loop

---

candle 2013-10-07 14:41:25

dalem dew cnt or cnt+1 bne co zalatwilo sprawe, jednakowoz skoro jest to powinno dzialac zgodnie z intuicja, a nie kulawo

---

0xF 2013-10-07 15:01:29

Jeśli masz na myśli:
DEW cnt
ORA cnt+1
BNE target
to skaczesz gdy cnt jest różne od $ff. Gdzie tu intuicja?

---

candle 2013-10-07 15:19:38

gdy cnt or cnt +1 jest rozne od $00

---

candle 2013-10-07 15:36:19

konkretniej, w kodzie mam tak:

dew Program_Required_Sectors_cnt
lda Program_Required_Sectors_cnt
ora Program_Required_Sectors_cnt+1
bne Program_Required_Sectors_L2

prosze nie bic

---

xxl 2013-10-07 15:53:24

np. tak?

dec Program_Required_Sectors_cnt
bne Program_Required_Sectors_L2
dec Program_Required_Sectors_cnt+1
bne Program_Required_Sectors_L2

---

xxl 2013-10-07 15:54:38

ja chcialbym zapytac jak w mads zapisac chcec zaladowania np. do akumulatora wartosci skoku wzglednego

---

0xF 2013-10-07 16:47:58

candle: jak tak to ok.

xxl @15:53:24: patrz mój komentarz @12:41:22

xxl @15:54:38:
bne *
skok
...
gdzie

lda #gdzie-skok
sta skok-1

---

0xF 2013-10-07 19:36:56

Candle: szybciej:
DEW cnt
BNE target
LDA cnt+1
BNE target

---

candle 2013-10-07 21:27:08

Fox, fajnie, doceniam, naprawde
ale optymalizacja nie ma wielkiego sensu tam gdzie calosc trwa chyba 15s (moze bredze)
tam jest jeszcze depakowanie i samo flaszowanie ukladu, co ma swoje wymogi czasowe - generalnie nie ma to tutaj wielkiego znaczenia, ale spoko, skozystam

---

Specta 2013-10-09 10:04:50

Ależ Wy Panowie jesteście magikami :)

---

the fender 2013-10-09 17:07:01

Czy wprowadzanie elementów z jęz. wyższego poziomu nie powoduje spadku wydajności przy kompilacji? Nie znam się, dlatego pytam.

---

mgr_inz_rafal 2013-10-09 20:28:44

@The Fender
Niestety mogą powodować spadek wydajności (nadmiar wygenerowanych opcodów), dlatego bardzo ważne jest, aby koder rozumiał co kryją pod sobą poszczególne "metarozkazy" i umiał dokonać oceny, czy w danym przypadku warto z nich korzystać.

Natomiast zdecydowanie podnoszą czytelność kodu - tak jak wszystkie języki wyższego poziomu.

---

xxl 2013-10-09 20:40:06

a mi utrudniaja optymalizacje... ale moze za jakis czas ogarne.

---

wieczor 2013-10-10 10:18:00

A ja nie używam, bo nie chciało mi się przeczytać manuala :)

---

muffy_ 2013-10-13 22:13:06

taka sytuacja...
dobra na wirusy jest płyta paździerzowa z marketu
zresztą - jest dobra na wszystko

---

xeen 2013-10-13 22:18:47

muffy_ - sorki, twój komentarz stracił kontekst, bo usunąłem poprzednika (wulgaryzmy i przekroczenie granicy). Jeżeli autor usuniętego komentarza ma wątpliwości zapraszam do ich rozwiania na prv - mcora @ tlen . pl

---

xeen 2013-10-13 22:20:30

co do makr i elementów jęz. wyższego poziomu - moim zdaniem rewelacja, dla mnie w pewnych sytuacjach cc65 traci sens ;) Ale tylko w pewnych sytuacjach ;)

---

muffy_ 2013-10-13 22:59:12

@xeen
Dopiero po usunięciu poprzedniego mój koment. nabiera głębszego sensu :)
Co do makr - są dobre o ile w rozpędzie nie zmieniają się nam rejestry (np. akumulator). Bo przy debugowaniu może być kicha.
Wolę podstawowy kod procesora a z makr to chyba tylko mwa i mva stosuję. (no i pseudorozkazy jak "dta" itp.)

---