lda #%111_0_0000
  sta AUDC1

pozwala szybciej przy przeglądaniu się zorientować co tam się i jak adresuje.
Pewnie, że można sobie podefiniować stałe, ale już w:

  .sword %0000_1111_0100_1001

można by definiować różne tablice czytelniej.

2. Druga rzecz: mamy dyrektywę HEX którą sobie możemy definiować ciąg bajtów następująco:

  .hex 01 23 45 67 89 AB CD EF

Czy można by dodać uniwersalną dyrektywę powalającą w ten sposób definiować ciągi bajtów ale przy użyciu różnych systemów liczbowych? Np.

  .data $0123456789ABCDEF,%011110111101000001110100111,&01230123012301230123,000123547557482983754

i tak dalej, i tym podobnie.

mads 2.1.7
Source: turbodiskloader.asx

<no i tu już kod>

A nie można by dodać też:

Date: 2016-05-28T01:16:17.045+01
Command: mads -l -d:SECLEN=128 -d:DETECTSPEED -o:turbodiskloader.dta turbodiskloader.asx
Directory: /home/mono/

?

  org program
  .word endline
  .word 10
  .byte SYS
  .string start
  .byte 0
endline:
  .word 0

start:
  nop
  ...

to .string start powinno wygenerować ciąg ATASCII np. '2048'.
Przydało by mi się to przy komodorowych nagłówkach.

W ogólniejszym mechanizmie mogłoby się przydać generowanie liczby dziesiętnej, szesnastkowej w ATASCII albo kodach ekranowych. Albo w PETSCII.

potem przestawiam się na:
opt h+f-
i mam fragment jakby xexowy

i chcę wrócić na h+f-

I jak się wyrównać, żeby plik BIN wrócił do tego jednego ciągu. Niestety nie wiem jak wyrównać się bo ciąg xexowy może wychodzić w różnej długości.

1. Czy obok dziesiątkowego, szesnastkowego i dwójkowego mógłbyś dodać do MADS-a system czwórkowy np. z prefiksem '&' ? To ułatwiłoby kodowanie grafiki multicolor, bo wtedy np.

  .byte &0000
  .byte &0010
  .byte &0111
  .byte &0101
  .byte &0111
  .byte &0111
  .byte &0101
  .byte &0000

już byłoby dość czytelne. Może być inny prefiks.

2. Chodzi o rozszerzanie definicji typu wyliczeniowego. Bo dzisiaj np. da się enuma rozszerzać stosując:

.enum DIGIT
  ZERO = 0
.ende

.enum DIGIT
  ONE = 1
.ende

.enum DIGIT
  INF = $FF
.ende

  lda #DIGIT.ZERO
  ldx #DIGIT.ONE
  ldy #DIGIT.INF

wygeneruje listing z poprawnymi wartościami dla LDA, LDX i LDY, ale finalnie zaskutkuje błędem uniemożliwiając wygenerowanie pliku wynikowego.
Czy mógłbyś więc zmienić błąd na zaledwie warning?

mads 2.1.7 build 3 (13 Sep 23)
Source: D:\!Delphi\mads\test3.asm
     1                 .enum bool
     2 = 0000                no
     3 = 0001                yes
     4                 .ende
     5
     6                     org $400
     7
     8 FFFF> 0400-0407> A9 00        lda #bool(no)
     9 0402 A9 01            lda #bool(yes)
    10 0404 A9 00            lda #bool.no
    11 0406 A9 01            lda #bool.yes
    12                 //    lda #no
    13                 //    lda #yes
    14

.enum bool
    no
    yes
.ende

    org $400

    lda #bool(no)
    lda #bool(yes)
    lda #bool.no
    lda #bool.yes
    lda #no
    lda #yes

maluje mi to:

        lda #bool(no)
test.asx (11) ERROR: Undeclared label NO (BANK=0)
        lda #bool(yes)
test.asx (12) ERROR: Undeclared label YES (BANK=0)
        lda #bool.no
test.asx (13) ERROR: Undeclared label BOOL.NO (BANK=0)
        lda #bool.yes
test.asx (14) ERROR: Undeclared label BOOL.YES (BANK=0)

a listing wygląda tak:

mads 2.1.7
Source: test.asx
     1
     2                     opt o+ h- c- ?+
     3
     4                 .enum bool
     5 = 0000                no
     6 = 0001                yes
     7                 .ende
     8
     9                     org $400
    10
    11 0400 A9 00            lda #bool(no)
    12 0402 A9 00            lda #bool(yes)
    13 0404 A9 00            lda #bool.no
    14 0406 A9 00            lda #bool.yes
    15 0408 A9 00            lda #no
    16 040A A9 01            lda #yes
    17
    18
    19                     end

a przecież wg dokumentacji:

Czy to ładnie tak?

Przykład. W głównym pliku jest taka konstrukcja:

;-----------------------------------------------
; variable declarations in RAM (no code)
;-----------------------------------------------
    ORG PMGraph + $0300 - (variablesEnd - variablesStart)
    icl 'variables.asm'

Ma ona za zadanie umieścić zmienne bezpośrednio przed obszarem PMG

plik variables.asm wygląda tak...

variablesStart
TanksNames 
    .ds MaxPlayers*8
;----------------------------------------------------
skilltable   ; computer controlled players' skills (1-8), 0 - human
    .DS MaxPlayers

; .... cośtam, cośtam, tablice zmienne itp.

.align $100
; i tu miejsce na wygenerowanie tablic wymagających umieszczenia na początku strony

; a potem inne deklaracje
variablesEnd

No i tutaj wyznaczenie adresu zmiennych spowoduje zadziałanie .align, co spowoduje zmianę adresu zmiennych, co spowoduję zmianę offsetu w .align itd.
Czyli w sumie 'Infinite loop' ale nie generuje żadnego ostrzeżenia, lecz błędy w innych miejscach (bo adresy zmiennych głupieją). Nie da się tego uniknąć (jeśli programista taki kod stworzy :) ), ale da się poinformować programistę... chyba :)

Pirx postanowił, że takie umieszczenie zmiennych będzie najlepsze (i dobrze), a ja tylko grzebałem w pliku zmiennych, nie mając świadomości, że jego adres jest wyznaczany w taki sposób. I stąd moje problemy, jak po wstawieniu .align zaczęło mi sypać różnymi błędami w najróżniejszych miejscach kodu, w zależności od tego gdzie w pliku znalazł się ten .align .

Mam taki pomysł na wyłapanie tego. Może z dupy, ale co tam :)
Dodać na końcu jeden dodatkowy przebieg, który posłuży tylko sprawdzeniu, czy któraś z etykiet nie zmieniła wartości - jeśli zmieniła, to w jej okolicy jest problem (zapewne) i dodatkowo wiemy, że problem jest.
Jeśli wartość zmieni wiele etykiet to najprawdopodobniej problem jest w okolicy pierwszego wystąpienia w kodzie takiej etykiety.

ogólnie powodem mogą być instrukcje skoków, JPL, JMI, JNE etc. które przybierają postać krótką albo długą, zmiana adresów asemblacji etc.

nie udało mi się tego wyeliminować, próbowałem wielu podejść, wskazana etykieta która powoduje 'infinite loop' może wcale nią nie być

w MadPascal (MP) powodem 'infinite loop' jest etykieta DATAORIGIN, na końcu pliku wynikowego, jej wartość w kolejnych przebiegach potrafi różnić się nawet o $100 bajtów, najnowszym sposobem na jej stabilizację jest to:

    ?adr = *
    ift (?adr < ?old_adr) && (?old_adr - ?adr < $120)
    ?adr = ?old_adr
    eif

    org ?adr
    ?old_adr = *

DATAORIGIN

w innych dużych projektach typu Nibble, Pang, tworzę kod relokowalny RELOC, umieszczam w oddzielnych plikach i linkuję z głównym programem, szybciej sie assembluje i nie wpływa na zmianę adresów

W pozostałych przypadkach, każdy przebieg kompilatora będzie powodował wyznaczenie innego przesunięcia dla .align , a w związku z tym innego adresu dla org i innych wartości dla wszystkich etykiet we wspomnianym bloku przed .align.

Obecnie Mads tego nie sprawdza i generuje błędy w innych miejscach kodu (bo mu się rozsypuje kompilacja i gdzieś tam te błędy się pojawiają). Jest to dość irytujące, bo jak się nie zauważy początkowej przyczyny, to sprawdzanie tych błędów, które Mads raportuje nic nie daje, bo ich nie ma :)

Więc taki "phase error", którego kiedyś nie rozumieliśmy w MAC65, jest tu jak najbardziej na miejscu i bardzo ułatwiłby pracę.
Oczywiście wskazanie prawdopodobnego miejsca takiego błędu by się przydało (MAC65 wtedy nic nie pokazywał), choć rozumiem, że to już nie takie oczywiste.