101

Odp: Mads Assembler

Właściwie to patrząc na mój poprzedni post sprzed 2 lat, to masz rację :) Nie ma tematu.

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

102

Odp: Mads Assembler

Potrzebuję zorganizować sobie kod dla carta bankowanego.

1. Banki są w obszarze $8000..$9FFF, bank stały (ostatni n.p. 3) jest w $A000..$BFFF.
2. Idea jest taka, że plik wynikowy ma zawierać cięgiem kolejne dynamicznie przełączane banki aż do ostatniego stałego (łączenie 4 w tym wypadku), więc używam bankowania wirtualnego i ustawiam opt h- f+ b-.
3. Dodatkowo, ponieważ nie chcę na piechotę wypełniać resztek banku, to używam .align (nie wiem czy dobrze, bo czytając dokumentację nie wiem czy to .align mówi mi do jakiego adresu będzie wyrównywany kod, czy też do jakiej wielokrotności bajtów będzie równany kod - dajmy na to .align $400 równałoby do najbliższego kilobajta, choć wtedy rodzi się pytanie gdzie jest baza dla obliczania tej wielokrotności - zawsze 0? założyłem że to jednak adres).
4. A na koniec chciałbym jeszcze żeby etykiety we wszystkich bankach były globalne, bo potrzebuję ich używać nie tylko z poziomu banku stałego, ale też i z poziomu tych przełączanych.

Więc robię sobie tak:

    opt o+ h- ?+ c- f+ b-

CARTCTRL = $D500

    org $8000
    rmb
bank0:
    nop
    .align $A000

    org $8000
    nmb
bank1:
    nop
    .align $A000

    org $8000
    nmb
bank2:
    nop
    .align $A000

    org $A000
    nmb
bank3:
start:
    nop
    rts
    .align $BFF0

initialize:
    sta CARTCTRL+[=bank0]
    rts
    .align $BFFA

    .word start
    .byte $00
    .byte %00000100
    .word initialize

    end

Ładnie, elegancko, równo i z wdziękiem.

Lecz, o zgrozo, próba kompilacji tego za pomocą MADS 2.1.3 kończy się tak:

    org $8000
align.asx (11) ERROR: Can't fill from higher ($A000) to lower memory location ($8000)
align.asx (17) ERROR: Can't fill from higher ($A000) to lower memory location ($8000)

I co to się tu stanęło? I czemu nie mogę?

Jeśli ograniczę ilość banków do 2 (czyli zakomentuję banki 1 i 2) to wszystko jest w porządku i generowany jest ładny plik.

Ostatnio edytowany przez mono (2021-12-10 02:11:15)

Post's attachments

align.asx 367 b, liczba pobrań: 2 (od 2021-12-10) 

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

103

Odp: Mads Assembler

Można to rozwiązać stosując sekcje:

        opt f-
        org $8000
        opt f+
        nmb
bank1:
        nop

.if * > $A000
        .print =*,":",*
        .error *
.elseif * < $A000
        .align $9FFF,$FF
        .byte $FF
.endif

i tak dalej aż do ostatniego banku (w pierwszym i ostatnim nie trzeba). Ale ten opt f- opt f+ i .align $9FFF,$FF .byte $FF nie wygląda ani elegancko, ani ładnie.

Da się to jednak ładniej rozwiązać? Zdecydowanie ładniej wyglądałoby n.p.:

        org $8000
        nmb
bank1:
        nop

.if * > $A000
        .error =*,":",*
.else
        .align $A000
.endif

Edit: Nie można by od razu przy .align generować bajtów jeśli f+?

Ostatnio edytowany przez mono (2021-12-10 13:10:33)

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

104

Odp: Mads Assembler

    lmb #1
    org $8000

    .pages 32

    nop

    .endpg


    lmb #2
    org $a000

    .pages 32

    nop

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

105

Odp: Mads Assembler

Tak. Dziękuję. Nadal nie działa.

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

106

Odp: Mads Assembler

https://github.com/tebe6502/Mad-Assembler

.local    , address


.endl

tworzy nowy blok LOCAL o adresie ADDRESS,  w pliku nie generuje nowego bloku

blok taki nie posiada nazwy tylko nowy adres,  przestrzeń jego nazw widziana jest poza takim blokiem

odpowiednik dla 'org r:address' dla którego Mads generuje nowy nadmiarowy blok w pliku wynikowym (Xasm nie generuje nadmiarowego bloku)

Ostatnio edytowany przez tebe (2022-09-10 22:53:27)

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

107

Odp: Mads Assembler

https://github.com/tebe6502/Mad-Assembler

dodana obsługa dyrektywy .BI binary

.bi 110101, 101010, 000*

.bi 1 11 101 11* 10101*

znak '*' na końcu ciągu oznacza EOR #$FF

Ostatnio edytowany przez tebe (2023-04-21 07:40:56)

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

108

Odp: Mads Assembler

tebe napisał/a:

znak '*' na końcu ciągu oznacza invers

OR $80, czy EOR $FF? Pisz jak dla koderów, a nie klikaczy jakiegoś - za przeproszeniem - MadPascala. ;-)

Zawsze mam rację, tylko nikt mnie nie słucha.

109

Odp: Mads Assembler

invers wszystkich bitów, EOR

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

110

Odp: Mads Assembler

kiedy deklaracje stringów ?

txt[100]="c:\dir\"

  .print txt

.ds txt


można opowiadać się i tu: https://github.com/tebe6502/Mad-Assembler/issues/14

Ostatnio edytowany przez pajero (2023-04-23 19:59:03)

111

Odp: Mads Assembler

W związku z tym https://atarionline.pl/forum/comments.p … 13#Item_16 "zdarzeniem" na ostatnim Sztabie w Warszawie rozwinęła się dyskusja z Draco.
No może nie tak dokładnie, bo rozmawialiśmy o MAC65 i błędzie "phase error" :)

Wyszło nam, że brakuje takiego komunikatu błędu w Madsie.

Jeśli kolejne przebiegi generują dla tej samej etykiety różne wartości, to kompilator powinien to zakomunikować, a nie wskazywać różne inne błędy w dowolnych innych miejscach w kodzie (bo oczywiście ta zmiana wartości etykiety ma wpływ na wszystko inne).

Dało by to jasny komunikat w czym tkwi podstawowy problem i oszczędziło programiście poszukiwań.

Czyli, mimo, że lata temu w MAC65 błąd "phase error" wydawał nam się nic nie mówiący i bez sensu.... teraz nam go brakuje :)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

112

Odp: Mads Assembler

nigdy nie byłem użytkownikiem MAC65

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

113

Odp: Mads Assembler

I nie musiałeś :)
Chodzi nam o błąd polegający np. na tym co przytrafiło się mi.
Czyli np. adres (org) dla includowanego pliku z definicjami zmiennych i tablic wyliczany jest na podstawie długości tego obszaru (includowanego pliku). A w obszarze tym znajduje się np. dyrektywa .align .
No i jest przypadek szczególny, kiedy to się prawidłowo skompiluje. Jeśli przy pierwszym przebiegu .align od razu będzie trafiał w swoje miejsce, czyli nic nie będzie musiał wyrównać.

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.

Ostatnio edytowany przez Pecus (2023-07-20 18:10:55)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

114

Odp: Mads Assembler

nie chodzi przypadkiem o 'Infinite loop', kiedy liczba przebiegów osiąga limit, jest generowany komunikat ostrzeżenia, może być z tego multum błędów

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

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

115

Odp: Mads Assembler

Pewnie tak. Jest to 'Infinite loop' , ale w moim przypadku, generuje to tylko errory, zero ostrzeżeń.

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.

Ostatnio edytowany przez Pecus (2023-07-20 20:24:19)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

116

Odp: Mads Assembler

Taki kod:

.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:

mads napisał/a:

Do etykiet wyliczeniowych odwołujemy się przy pomocy składni:
enum_name (field)
lub bezpośrednio podobnie jak w przypadku odwołań do bloków .LOCAL, .PROC, czyli po nazwie typu oddzielone znakiem kropki występują kolejne pola, np.:
lda #portb(rom_off)
dta portb.rom_on, portb.rom_off

Czy to ładnie tak?

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

117

Odp: Mads Assembler

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
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

118

Odp: Mads Assembler

Dziękuję. Bangla pięknie.

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

119

Odp: Mads Assembler

Dwie rzeczy:

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?

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

120

Odp: Mads Assembler

Dobry pomysł z systemem czwórkowym!

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.