Mit Assembler bezeichnet man normalerweise eine Darstellung der Maschinensprache, die einigermaßen standardisiert (d.h. ähnlich auch bei unterschiedlichen Prozessoren) und noch menschlich lesbar ist, und daher eigentlich sehr lehrreich gewesen wäre, wenn sowas in Magazinen mit aussagekräftigen Kommentaren öfter abgedruckt gewesen wäre.
sieht z.b. so aus:
//SCR_SET_MODE 0
__asm
ld a, #0
call #0xBC0E
__endasm;
//PALETE
__asm
ld a, #0
ld b, #0 ;black
ld c, b
call #0xBC32 ;SCR SET INK
ld a, #1
ld b, #12 ;Yellow
ld c, b
call #0xBC32 ;SCR SET INK
ld a, #2
ld b, #25 ;Pastel Yellow
ld c, b
call #0xBC32 ;SCR SET INK
ld a, #3
ld b, #24 ;Bright Yellow
ld c, b
call #0xBC32 ;SCR SET INK
__endasm;
//SCR SET BORDER 0
__asm
ld b, #0 ;black
ld c, b
call #0xBC38
__endasm;
(von
http://www.cpcmania.com/Docs/Programming/2D_Starfield.htm) (ist eigentlich C-Code, aber C kann Inline-Assembler, daher dieses "__asm". C ist übrigens auch nur ein etwas besserer Assembler.)
Wie man sieht, viel Zeremonie, nur um MODE, BORDER und ein paar Farben zu setzen, würd jeglichen Platz sprengen, wie gesagt.
Anderes Beispiel:
http://cpctech.cpc-live.com/source/memcheck.htmlNun kann man beim CPC das eh nativ nicht so eingeben wie gesagt, da wurd kein Interpreter/Compiler mitgeliefert (obwohl es viel einfacher zu interpretieren wäre als BASIC), man bräucht ein eigenes Tool dafür.
All das kann man aber mit den POKE-Befehlen des CPC-Basic abbilden, jedes Fizzel von dem Assembler-Code, den du siehst, würd man im CPC-Basic mit POKE [Adresse],[byte] in den Speicher reinhämmern. [Adresse] startet irgendwo, wo der für sowas vorgesehene Speicherbereich losgeht (steht irgendwo in der Doku), und dann nimmt dann bei jedem nächsten POKE einfach die nächste Speicherzelle, weil Quellcode ist ja in der Regel linear, ne, und [byte] entspricht praktisch 1:1 einem dieser Opcodes (Befehle) bzw Wert, den du da siehst. Ein "ld a" (das ist nur *ein* Befehl, "lade bzw. lese einen Wert in Register A ein") entspräche z.B. dem [byte] 0A oder 1A oder paar andere, je nach Situation. Siehe Z80-Doku/Übersicht:
http://clrhome.org/table/Das wären aber viele POKE-Befehle, darum nimmt man den DATA-Befehl im CPC-BASIC, wo man die [byte]s aneinanderreiht, und dazu gibt's dann eine BASIC-Routine, die diese DATA-Befehle in POKE-Anweisungen umwandelt, findet man auch immer in diesen Listings dazu.
Jegliches Maschinensprachenprogramm besteht also aus sogenannten Opcodes (Befehle, die der Prozessor und andere Chips wie die für Grafik und Sound direkt verstehen, indem es eine Schaltung dafür gibt) und Zahlenwerten.
Die Opcodes bzw. Befehle in Maschinensprache sind sehr primitiv, müssen ja in Hardware als Schaltung implementiert sein, da kann man keine Wunder vollbringen. Daher gibt's nur sowas wie "Leg einen Wert in einen bestimmten Ort im Speicher", "Leg einen Wert in einen Register (ist auch so eine art Speicher, aber nicht das RAM, sondern direkt im Prozessor, sehr schnell, aber gibt es gibt nur sehr wenige solcher Register, d.h. nur eine Hand voll)", "Mach eine arithmetische Operation mit der Zahl in diesem Register sowie der Zahl in jenem Register und schreib dann das Ergebnis da und dortin."
Ein einfaches PRINT $xyz in Maschinensprache ist bereits megakackenaufwändig, eine Zeichenkette ist ja bereits eine dynamisch große liste von Bytes, wieviel Speicher soll man dafür reservieren, das ist schon ziemlich tricky, und wie sieht's mit Zeilenumbruch aus, etc etc.
Das meiste bei typischen Maschinensprache-Programmen ist also wirklich nur Werte und Daten in der Gegend rumschaufeln, und man muss in der Dokumentation eines Geräts nachschaun, an welchen Addressen besondere Funktionen sitzen, die was auslösen, so dass irgendwas passiert, wie das ändern der Rahmenfarbe im Beispiel oben. Neben den unterschiedlichen Befehlssätzen bei unterschiedlichen Prozessoren/Chips ist es vor allem das, was bei jedem Heimcomputer anders ist.
Daher gibt's sowas wie aufwändige Operationen zum "rumzeichnen" gar nicht, das gibt's nur im BASIC (Amstrad hat halt netterweise quasi ein fast ein Malprogramm mitgeliefert mit den Befehlen wie DRAW, FILL etc, aber die waren natürlich kaggnlangsam und für schnelle Games unbrauchbar), Spiele kamen in der Regel einfach mit den Bitmaps für die Sprites und Hintergründe bereits fertig daher. Ausnahmen bestätigen die Regel, und besonders bei 3D-Spielen wurden dann natürlich eigene Routinen implementiert, aber so einfach benutzbar wie im BASIC waren die dann meist auch nicht.
Bei kommerziellen Programmen und Spielen sind die Maschinensprachenprogramme natürlich direkt als .BIN o.ä. bzw. die Bitmap-Grafikdaten als solche straightforward abgelegt (ohne den Umweg über POKEs und DATA-Zeilen im BASIC). (Den reinen Binärcode wiederum kann man aber in Magazinen schlecht abdrucken.)
Hoffe alle Klarheiten sind beseitigt.
Kommentar wurde am 31.07.2020, 00:35 von Grumbler editiert.
vorige Ausgabe
Willkommen bei
