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?
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.
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.
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.
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?
> wo * ein gültiger Symbolbezeichner
Das * wurde spaeter in anderen Assemblern vom $ beerbt :),
und ist quasi der "Instruction Counter" des Assemblers.
> 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
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.
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.
> 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:
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.
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?
> 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.
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.
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?
> 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.
> 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.
