Forum: Compiler & IDEs Retro Programming, Problem mit VASM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bitmontierer (Gast)


Lesenswert?

CPU: 6502

Code liegt in $E000 - $FFFF, (8kB für ein entsprechendes EEPROM 2864).

Wenn ich schreibe:
1
;RAM addresses, zero page:
2
      * = $20 
3
AnodeCounter =*    ; Counter 7seg. LED Anode 1-4
4
VAL2      *=*+1   ; save accu in DELAY loop
5
bitbang_1    *=*+1
6
bitbang_2     *=*+1
Dann wird für mein EEPROM ein 64k File erzeugt, weil der Assembler 
glaubt, eine ROM Section im Bereich $0-$23 anlegen zu müssen.

Wenn ich schreibe:
1
AnodeCounter = $20    ; Counter 7seg. LED Anode 1-4
2
VAL2 = $21   ; save accu in DELAY loop
3
bitbang_1 = $22
4
bitbang_2 = $23
Dann funktioniert der Code und das Binärfile ist wie gewünscht 8kB groß.

Die Frage ist: Wie kann ich dem Assembler abgewöhnen, das er eine 
zusätzliche Code Section die eigentlich RAM wäre, anlegt?

von W.S. (Gast)


Lesenswert?

Bitmontierer schrieb:
> Die Frage ist: Wie kann ich dem Assembler abgewöhnen, das er eine
> zusätzliche Code Section die eigentlich RAM wäre, anlegt?

Ich vermute mal (bin kein 6502 Anwender), daß dein Assembler ein 
gültiges Segment erwartet und sich notfalls eins macht. Abgesehen davon 
sind mir diverse Details deiner Ausdrücke unverständlich:
   VAL2      *=*+1

Sowas würde man in den Gefilden, wo ich unterwegs bin, etwa so 
schreiben:
              SEG  RAM
              ORG  20h
AnodeCounter: DEFS 1
VAL2:         DEFS 1
bitbang_1:    DEFS 1
bitbang_2:    DEFS 1

Und da es Variablen sein sollen, darf dort natürlich nichts stehen, was 
Code erzeugen würde. Also keine Befehlsmnemoniks oder konstante Daten.

W.S.

von Bitmontierer (Gast)


Lesenswert?

Danke für deine Hilfe.
Ich hab das Beispiel
1
VAL2      *=*+1
aus nem uralten Emuf Sonderheft gefunden. Vielleicht ist der Assembler 
an der Stelle nicht kompatibel mit dem damaligen.

Dann ist noch etwas merkwürdig (Syntax).
Beispiel:
1
Mem_1 = $0200 ; 16-bit Adresse
2
; $0200 kann in ein Lo-Byte und in ein Hi-Byte zerlegt werden. Ich kenne die Vorgehensweise mit dem "<" Zeichen und dem ">" Zeichen. 
3
LDA <Mem_1 ; lädt Lo-Byte der Adresse ($00), funktioniert ordnungsgemäß
4
LDA >Mem_1 ; sollte das Hi-Byte der Adresse laden ($02). Stattdessen wird der Inhalt von $0200 geladen.
5
6
;das hier wird disassembliert:
7
00:E222 A500                 619:     LDA <MEM_1
8
00:E224 8504                 620:     STA $04        
9
00:E226 AD0002               621:     LDA >MEM_1      ;hier müsste A502 stehen, stattdessen AD0002
10
00:E229 8505                 622:     STA $05
Leider schweigt sich Manual des Autors auf diesen Syntax aus.

von Bauform B. (bauformb)


Lesenswert?

Leicht OT, aber zu diesem Assembler gibt es über 300 Seiten Handbuch:

http://john.ccac.rwth-aachen.de:8000/as/

von Cartman (Gast)


Lesenswert?

LDA <MEM_1       ; MEMORY DIRECT Pg. 3 - 5
vs.
  LDA #<MEM_1      ; MEMORY IMMEDIATE Pg. 3 - 6

Und ein
  *=*+1

ist nur ein einfaches Increment des jeweiligen Adresszeigers
des Assemblers und kein Voodoo.
Von denen kann es durchaus mehrere geben.
In der Schule haettest du fuer so ausgesprocehn mangelhafte
Kenntnisse des 6502 Assemblers wohl eine 6 bekommen.

Der Leventhal hat uebrigens 633 Seiten.
Fuer mehr als das Vorwort scheint es bei dir nicht gereicht zu haben.

von Peter D. (peda)


Lesenswert?

Cartman schrieb:
> *=*+1
>
> ist nur ein einfaches Increment des jeweiligen Adresszeigers

Nur kenne ich keinen Assembler, wo * ein gültiger Symbolbezeichner oder 
Platzhalter ist. Ein Symbol besteht aus mindestens einem Zeichen und 
darf keine Sonderzeichen beinhalten.
* ist für Multiplikation reserviert.

Auch erlauben Assembler nur eine Aktion je Zeile. D.h. Increment und 
Symboldefinition in der gleichen Zeile sind nicht zulässig.

Schmeißt denn der Assembler keinerlei Warnungen oder Fehler?

von Cartman (Gast)


Lesenswert?

> wo * ein gültiger Symbolbezeichner

Das * wurde spaeter in anderen Assemblern vom $ beerbt :),
und ist quasi der "Instruction Counter" des Assemblers.

von Cartman (Gast)


Lesenswert?

> Increment und
> Symboldefinition in der gleichen Zeile sind nicht zulässig
U.U. fehlten dem Assembler Ausdrucksmittel um Bereiche zu allokieren.
Etwa ein:
  DS

Da kommt dann ein *=*+16 schon handlich.

> keinerlei Warnungen oder Fehler
Vermutlich kennt der Assembler nur 2 Fehler:
- Syntax Error
- Empty input file

von W.S. (Gast)


Lesenswert?

Peter D. schrieb:
> Nur kenne ich keinen Assembler, wo * ein gültiger Symbolbezeichner oder
> Platzhalter ist. Ein Symbol besteht aus mindestens einem Zeichen und
> darf keine Sonderzeichen beinhalten.

Na, da nenne ich dich mal einen Jungspund. Die Verwendung des * für den 
momentanen Stand des Speicherplatz-Zeigers war früher durchaus üblich. 
Allerdings sind solche Ausdrücke wie sie der TO gezeigt hat, nicht 
sonderlich lesefreundlich. Egal ob bei den Daten oder im Code.

Und was die Verwendung von Zeichen für Namen (Symbole, Identifier, 
Marken....) betrifft, da sollte man ins Manual des zuständigen Tools 
schauen, bevor man große Töne spuckt. Tja, bei der ersten Maschine, die 
ich unter den Fingern hatte, waren nur Großbuchstaben und Ziffern 
erlaubt und es durften maximal 4 Zeichen sein. War auch nicht 
berauschend...


Aber für den Bitmontierer wäre mein Ratschlag, auf solche Dinge wie 
"*=*+1" zu verzichten und stattdessen eine Schreibweise zu bevorzugen, 
wie ich sie weiter oben bereits gezeigt hatte - vorausgesetzt, das geht 
bei diesem Assembler überhaupt.

W.S.

von W.S. (Gast)


Lesenswert?

Cartman schrieb:
> In der Schule haettest du fuer so ausgesprocehn mangelhafte
> Kenntnisse des 6502 Assemblers wohl eine 6 bekommen.

Das, wo Bauform B drauf hingewiesen hat, ist kein 6502-Assembler, 
sondern der "Macroassembler AS", also eine auf Multiplattform angelegte 
eierlegende Wollmilchsau, die (angeblich) gefühlte 1000 verschiedene 
Plattformen bedienen kann. Und du rüpelst hier herum.

W.S.

von Cartman (Gast)


Lesenswert?

> Und du rüpelst hier herum.

Nein, es ist der TO der auf einer alten Plattform herumturnen
will und geistig herumruepelt.

Und "das" Standardwerk fuer den 6502 ist nunmal der Leventhal
und der hat offensichtlich ein paar mehr Seiten als die
Doku zum AS.

Den "AS" kenne ich durchaus auch, aber ich benutze dann schon
lieber den "Cross-32 Meta-Assembler". Der u.a. auch den 6502
bedienen koennte.

Nochmal zu der Erguessen des TO:
1
00:E222 A500                 619:     LDA <MEM_1
2
00:E224 8504                 620:     STA $04        
3
00:E226 AD0002               621:     LDA >MEM_1      ;hier müsste A502 stehen, stattdessen AD0002
4
00:E229 8505                 622:     STA $05

Sowohl das ersta "LDA <MEM_1" ist als auch das zweite sind ganz
offensichtlich falsch, da der "immediate" Anteil der Adresse
geladen werden soll. Also eher "A9 00 ... LDA #<MEM_1"
und "A9 02 ....".

Wie man mit solch mangelhafter Kenntnis ernsthaft etwas
"programmieren" will, erschliesst sich mir nicht.
Da fehlen ja schon die "Grundlagen" des 6502.
Von der Beherrschung des Assemblers, Linkers und Lokators
noch ganz abgesehen.

von Bitmontierer (Gast)


Lesenswert?

Cartman schreibte:

LDA <MEM_1       ; MEMORY DIRECT Pg. 3 - 5
vs.
  LDA #<MEM_1      ; MEMORY IMMEDIATE Pg. 3 - 6

Und ein
  *=*+1

Hallo Cartman, aber das ist doch gar nicht der Punkt. Hast du das 
Problem nicht verstanden? Und warum pöbelst du so laut herum? Bist du 
einer dieser nach altem Mann muffelnden Kreaturen die mit einer 
hässlichen Frau veheiratet sind, nichts mit ihrer Zeit anzufangen wissen 
und deshalb wie Stadler und Walldorf aus dem Lehnstuhl heraus jeden 
beleidigen?

von Cartman (Gast)


Lesenswert?

> Hast du das Problem nicht verstanden?

Ich hab schon einiges fuer den 6502 zusammengehackt.
Aber du scheinbar nicht.
Ich werde auch keine weiteren Anstrengungen unternehmen
dich zu erhellen.

von W.S. (Gast)


Lesenswert?

Bitmontierer schrieb:
> Wenn ich schreibe:
> AnodeCounter = $20    ; Counter 7seg. LED Anode 1-4
> VAL2 = $21   ; save accu in DELAY loop
> bitbang_1 = $22
> bitbang_2 = $23
> Dann funktioniert der Code und das Binärfile ist wie gewünscht 8kB groß.
>
> Die Frage ist: Wie kann ich dem Assembler abgewöhnen, das er eine
> zusätzliche Code Section die eigentlich RAM wäre, anlegt?

Ich meine, es ist eher die Frage nach dem Schreibstil. Nun kenne ich 
deinen Assembler nicht, aber das, was du mit deinen Verwendungen von '*' 
da erzeugst, sieht für mich und vermutlich auch den Assembler aus wie 
das Erzeugen von Konstanten aus, die bei Verwendung von * obendrein noch 
irgend ein Attribut "Gehört zu einem Codesegment" abkriegen. Wenn das so 
ist, dann kannst du das dem Assembler überhaupt nicht abgewöhnen, denn 
es ist dann ein gegenseitiges Mißverständnis. Bleibt also nur der Weg, 
es anders zu formulieren.

W.S.

von Volker (vbc)


Lesenswert?

Bitmontierer schrieb:
> CPU: 6502
>
> Code liegt in $E000 - $FFFF, (8kB für ein entsprechendes EEPROM 2864).
>
> Wenn ich schreibe:
>
1
> ;RAM addresses, zero page:
2
>       * = $20
3
> AnodeCounter =*    ; Counter 7seg. LED Anode 1-4
4
> VAL2      *=*+1   ; save accu in DELAY loop
5
> bitbang_1    *=*+1
6
> bitbang_2     *=*+1
7
>
> Dann wird für mein EEPROM ein 64k File erzeugt, weil der Assembler
> glaubt, eine ROM Section im Bereich $0-$23 anlegen zu müssen.

Ja, ist so gedacht.

> Wenn ich schreibe:
>
1
> AnodeCounter = $20    ; Counter 7seg. LED Anode 1-4
2
> VAL2 = $21   ; save accu in DELAY loop
3
> bitbang_1 = $22
4
> bitbang_2 = $23
5
>
> Dann funktioniert der Code und das Binärfile ist wie gewünscht 8kB groß.

Genau.

> Die Frage ist: Wie kann ich dem Assembler abgewöhnen, das er eine
> zusätzliche Code Section die eigentlich RAM wäre, anlegt?

Was für eine zusätzliche Code-Section? Die in der ersten Variante oder 
gibt es auch mit der zweiten ein Problem?

von Volker (vbc)


Lesenswert?

Bitmontierer schrieb:
> Ich hab das Beispiel
>
1
> VAL2      *=*+1
2
>
> aus nem uralten Emuf Sonderheft gefunden. Vielleicht ist der Assembler
> an der Stelle nicht kompatibel mit dem damaligen.

Ist eine eher altmodische Syntax, funktioniert aber mit vasm auch. Aber 
damit wird natürlich die aktuelle Adresse gesetzt.

Gängiger wäre etwas wie
1
VAL2 ds 1

> Dann ist noch etwas merkwürdig (Syntax).
> Beispiel:
>
1
> Mem_1 = $0200 ; 16-bit Adresse
2
> ; $0200 kann in ein Lo-Byte und in ein Hi-Byte zerlegt werden. Ich kenne 
3
> die Vorgehensweise mit dem "<" Zeichen und dem ">" Zeichen.
4
> LDA <Mem_1 ; lädt Lo-Byte der Adresse ($00), funktioniert ordnungsgemäß
5
> LDA >Mem_1 ; sollte das Hi-Byte der Adresse laden ($02). Stattdessen 
6
> wird der Inhalt von $0200 geladen.

Nein, Hi-Byte der Adresse wäre LDA #>Mem_1 und erzeugt Opcode A9.
1
> ;das hier wird disassembliert:
2
> 00:E222 A500                 619:     LDA <MEM_1
3
> 00:E224 8504                 620:     STA $04
4
> 00:E226 AD0002               621:     LDA >MEM_1      ;hier müsste A502 
5
> stehen, stattdessen AD0002
6
> 00:E229 8505                 622:     STA $05
7
>
> Leider schweigt sich Manual des Autors auf diesen Syntax aus.

Das vasm-Manual beschreibt das im Kapitel "6502 cpu module => 
Extensions". Da wird auch beschrieben, welche Bedeutung die Modifier im 
Fall von absoluten Adressierungsarten haben ("force 16bit/zpage 
addressing).

Da vasm verschiedene CPU- und Syntax-Module unterstützt, muss man in der 
Doku in den entsprechenden Kapiteln schauen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.