Diskussion:STATUS

mehrteilige Tabelle

Hallo,

Weiss wer, wie im Wiki eine mehrteilige Tabelle gestaltet werden kann?

PS: Wenn es noch keine Vorlage hierfür gibt, sollte eine erstellt werden. --Jodigi 18:43, 3. Mai 2006 (CEST)

Hab hier ne Toolbar für Wikis - da ist es kein Problem. Wenn du magst, kann ich dir eine zurecht schustern. Am Besten Anzahl der Spalten / Reihen mit Überschrift angeben.
ODER:

Du machst nen kleinen Kurs in der Wikisyntax (nicht sonderlich schwer) - und zwar hier mit vielen weiteren hilfreichen Adressen.
ODER: Du installierst dir die Toolbar von hier (nur für Firefox). Es gibt noch eine Erweiterung für den IE 6.x, aber da hab ich zurzeit nicht die URL gespeichert. Aber eins werd ich jetzt machen - die Vorlage für die Tabelle. --Joystick 02:06, 4. Mai 2006 (CEST)

negative Werte ?

sicher das Bit 7 gleichzeitig Vorzeichen-Wechsel und numerischen Wert darstellt ? der Statuswert wäre auch bei +128 eindeutig bestimmbar...

ZITAT:

Diese werden als Bitwerte vom Computerkernal zurückgemeldet und vom BASIC-Befehl Status als ganzer Zahlwert von -128 bis +127 wiedergegeben. Bit-Wert: 6 | Ausgabewert: 64 Bit-Wert: 7 | Ausgabewert:-128

FighterXXS 14:00, 16. Mai 2006(CEST]

Der Wert -128 stimmt, habs grad im nem Commodore-Buch nachgeschlagen, da steht es genauso. (Alles über den Commodore 64) ---Joystick 16:29, 16. Mai 2006 (CEST)

Hat das einen höheren Sinn, dass ST von BASIC als vorzeichenbehaftet betrachtet und ausgegeben wird? --Hobbyist (Diskussion) 16:09, 28. Feb. 2024 (CET)

Nein, natürlich nicht, genau so wenig wie das etwa FRE() einen vorzeichenbehafteten 16-Bit-Wert liefert. Ist einfach passiert. Offenbar passiert die Konvertierung des 8-Bit-Wertes aus dem Status "signed-extented", dass heißt aus %10000000 wird %1111 1111 1000 0000 -> Bit 7 wird auf Bit 8 bis 15 kopiert, was einen korrekten "signed" Wert ergibt. Für das Maskieren mit AND ist das aber egal, also etwa um zu Prüfen, ob Bit 7 gesetzt ist (also AND 128) ergibt 128. Es ist also rein eine Darstellungssache bzw. eine Sache der Zahlenrepräsentation. --JohannKlasek (Diskussion) 16:54, 28. Feb. 2024 (CET)

Danke für die Antwort. Hättest Du noch Zeit und Motivation für Anschlussfragen? :-)

1. Bei FRE() verstehe ich das, das ist ja von vornherein ein 16-Bit-Wert, und BASIC V2 verwendet halt vorwiegend vorzeichenbehaftete 16-Bit-Werte (z. B. Integer-Variablen) - wenn auch nicht immer (Adress-Parameter bei PEEK, POKE, SYS). Aber warum wird das Statusbyte überhaupt nach 16 Bit konvertiert?

Integer-Variablen haben ja nur die Bedeutung, wie sie von bzw. zu Float konvertiert werden. Aber ad FRE(): Meine Vermutung ist, dass es daran liegt, dass BASIC V2 ursprünglich von der PET-Hardware, aber auch beim VC-20, faktisch immer deutlich unter 32 KByte freiem BASIC-Speicher blieb. Da fiel es nicht auf und beim C64 mag das vielleicht aufgefallen sein, aber es war keine wesentliche Funktion, die die Funktion nicht eingeschränkt hätte. Offenbar war es nicht mehr rechtzeitig und passend für die Auslieferung.

Das Statusbyte wird nicht nach 16 Bit direkt konvertiert, es wird ein Byte vorzeichenbehaftet in ein Float umgewandelt. Dazu wird die SGN()-Routine $BC3C verwendet. --JohannKlasek (Diskussion) 22:30, 29. Feb. 2024 (CET)

2. Also das Status-Byte mit gesetztem Bit 7 wird derart in einen 16-Bit-Wert umgewandelt, dass das High-Byte mit Einsen aufgefüllt wird, was Sinn ergibt, wenn das Ursprunbgsbyte als vorzeichenbehaftet betrachtet wurde (denn 111111111 1000000 ist das Zweierkomplement von 00000000 10000000). Aber warum wurde das Statusbyte als vorzeichenbehaftet betrachtet und nicht einfach mit Nullen aufgefüllt?

Das war nur die übliche Sign-Extention wie es Prozessoren oder Hochsprachen bei der Konvertierung machen. So passiert es tatsächlich aber nicht (mit dem Auffüllen). Es wird direkt in Float gewandelt (und nicht zuvor auf 16 Bit expandiert). Wie oben erwähnt, wird (fälschlicherweise) die Konvertierungsroutine von SGN() verwendet, die eben das Vorzeichen berücksichtigt (weil $FF = -1, $01, oder $00 erwartet wird). --JohannKlasek (Diskussion) 22:30, 29. Feb. 2024 (CET)

3. Gibt es da vielleicht eine Routine, die das halt immer so macht bei der Umwandlung von Bytes in 16-Bit-Werte? Wenn ja, wofür findet die noch Verwendung? (Ich habe versucht, da etwas zu finden im ROM-Listing von 64 Intern, aber darin bin ich nicht gut.) --Hobbyist (Diskussion) 12:06, 29. Feb. 2024 (CET)

Einen 8-Bit-Wert vorzeichenlos in ein Float zu verwandeln (so wie bei PEEK() verwendet) ist $B3A2. Die Hätte man auch nehmen können. Keine Ahnung, warum man meinte die SGN()-Umwandlung als gute Idee befand. --JohannKlasek (Diskussion) 22:30, 29. Feb. 2024 (CET)

Danke für die weiteren Ausführungen, da muss ich mich mal in die ROM-Listings zu SGN() und PEEK() vergraben.

Mit Integer-Variablen wird leider mangels einer Integer-Arithmetik im Interpreter (anders als z. B. in BASIC-BOSS-Kompilaten) nicht direkt gerechnet, aber sie haben auch noch die Bedeutungen, dass mit ihnen bitweise logische Operationen durchgeführt werden können (wird das mit Floats versucht, werden diese deshalb nach Integer konvertiert) und als Array pro Wert nur 2 Bytes zu verbrauchen.

Wobei man dazu sagen muss, dass die logischen Operationen nur auf den 16-Bit-Integer Zahlenbereich gelten und funktionieren. Das hat nichts mit den Variablen zu tun, ab gesehen davon, dass beides den gleichen Zahlenbereich verwendet. Die logischen Operatoren brauchen weder die Integer-Variablen noch umgekehrt. Die Argumente werden *immer* als Float ausgewertet, selbst wenn die Quelle eine Integer-Variable ist. Die beiden Operatoren werden dann in 16-Bit-Integer umgewantelt, die logische Operation angewendet und dann wieder in ein Float umgewandelt. Deshalb sind bei solchen Dingen Integer-Variablen sogar noch langsamer in der Auführung. ;) Ich wollt es nur der Vollständigkeit halber erwähnen, auch wenn es bekannt sein dürfte. --JohannKlasek (Diskussion) 12:22, 1. Mär. 2024 (CET)

Hast recht, da hatte ich mich ungenau ausgedrückt; eine Tücke ist noch: Der vorzeichenbehaftete Integer-Wertebereich gilt auch bei Bit-Operationen (auch mit mit Floats), deshalb muss zur Isolierung des 16. Bits mit -32768 undiert werden und nicht mit 32768. Tücke in der Tücke: Im Handbuch wird die Untergrenze fälschlich mit -32767 angegeben. --Hobbyist (Diskussion) 20:14, 1. Mär. 2024 (CET)

In der Tat, ich hab diesen Fehler auch gleich in Bedienungshandbuch Commodore 64 vermerkt.

Die Konvertierung von 16-Bit-Unsigned zu Integer:

IP=32767:IA=65536

DEF FN UI(U)=U+(U>IP)*IA

und von Integer zu 16-Bit-Unsigned:

DEF FN IU(I)=I-(I<0)*IA

--JohannKlasek (Diskussion) 19:46, 4. Mär. 2024 (CET)

Ja, FRE() scheitert an den vormals nicht absehbaren Unmengen an RAM im C64, so kenne ich es auch. --Hobbyist (Diskussion) 00:32, 1. Mär. 2024 (CET)