Hallo Besucher, der Thread wurde 57k mal aufgerufen und enthält 397 Antworten

letzter Beitrag von Boulderdash64 am

BASIC 4.5 für den C64 (BASIC 3.5 + EIGENE BEFEHLE)

  • Als Wert wird 0 angezeigt, aber ein Adressbereich von $1003 bis $1010 (13 Bytes).


    Liegt da ein Fehler bei der Anzeige vor?

    Wow, und das zur späten Nachtzeit. Tatsächlich. Da hat sich ein Fehler eingeschlichen. Hab die falsche Speicherstelle ausgewertet. Wurde korrigiert.
    Danke Snoopy.


    Hier die Version mit der Korrektur.

  • Vielen Dank für die neue Version.


    Warum hast du die "NUMBERS" zu "VALUES" geändert? Numbers fand ich eigentlich ganz passend und gut.


    Stimmt. Und oben in der Überschrift finde ich BYTES aussagekräftiger als VALUE.

  • Noch einige Vorschläge: Also weder NUMBER noch VALUE finde ich ideal. Es beschreibt doch die Größe, den Umfang des Bereichs. Also "SIZE" oder "USAGE" fände ich besser. Und der Adressbereich wäre mit "ADDRESS RANGE" besser beschrieben. Space ist auch hier nicht das richtige Wort. Das verwendet man, wenn man von einem Bereich spricht, aber sagt normalerweise nichts über die Grenzen aus. :)

  • Daran sieht man jetzt, dass die Begriffe doch etwas verwirrend sind, denn jetzt geht es nämlich völlig durcheinander. ;)


    NUMBERS bzw VALUES beschreibt den Typ (als den Bereich der numerischen Variablen).

    VALUE steht für die Größe des Bereichs und da es eben auch KB oder einfach die Anzahl sein könnte, finde ich BYTES eindeutiger. USAGE ist genauso nichtssagend wie VALUE.

  • Hi Leute. Erstmal Riesen Dank für alle Anregungen. Naja, ich hatte „Adressraum“ im Kopf und im Old-School-english ist das halt address space ;). Address range geht natürlich auch.

    Ich habe „NUMBERS“ durch „VALUES“ (Werte) ersetzt, weil es die Verwendung von numerischen Variablen suggeriert. Aber das ist nicht so. Es belegt auch den Platz für die Namen und Vektoren der Stringvariablen. Daher finde ich NUMBERS falsch. Ich bitte um Korrektur wenn ich mich Irre. Bei der Variablenamenvergabe legt Bit 7 des 2. Byte im Namen fest ob es ein String ist. Darauf hin folgt die Vektoradresse und Länge des eigentlichen Inhalts. Dieser Speicherbereich liegt direkt hinter dem BASIC Programm. Dort liegen aber auch FP und INT Variablen mit deren Inhalt. Ich könnte zwar alle Numerischen Variablen raus sammeln und deren Platz ermitteln, aber das ist ne harte Nuss die ja auch wieder Speicherplatz verbraucht. Hier muss ich Nutzen und Speicherplatz gegenüber stellen. Zurück zu NUMBERS, äh VALUES. Dort steht also die Summe des verbrauchten Speicherplatzes für FP und INT Variablen PLUS Stringvariablename +Deskriptoren. Also, was wäre der allgemeine Wunsch? USAGE finde ich ok, Aber ich muß da auch detlef recht geben. Rückblickend ist beides „nicht sagend“.

  • NUMBERS bzw VALUES beschreibt den Typ (als den Bereich der numerischen Variablen).

    VALUE steht für die Größe des Bereichs und da es eben auch KB oder einfach die Anzahl sein könnte, finde ich BYTES eindeutiger. USAGE ist genauso nichtssagend wie VALUE.

    Ich hab da jetzt zwei Sachen vermischt. Eigentlich hab die Spaltenüberschrift "VALUE" gemeint. Das ist einfach die falsche Wortwahl, auch zu generisch. Ich habe das in dieser Verwendung noch nie gesehen und wenn, dann ist es so nicht wirklich die Regelverwendung. Einspruch hinsichtlich "USAGE": Das ist faktisch die übliche Verwendung in allen gängigen Betriebssystemen, wenn es darum geht, eine Quantität hinsichtlich Ressourcenverbrauch zu benennen, egal ob prozentual oder es sich um absolute Beträge handelt. Übersetzt also der "Verbrauch" (einer Ressource), währenddessen "VALUE" mit "Wert" im Vergleich dazu überhaupt nichts aussagt. Ein Wert ... Wert für was? Für belegten oder noch zu Verfügung stehenden Speicher? Usage ist da eindeutig. ;)


    Aber auch als Zeilenbezeichnung ist es einfach falsch. Es ist der Bereich der "Simple Variables" oder nur "Variables". Das sind mitnichten nur "Numbers", sondern dort sind Variablen vom Typ Float, Integer und Strings (die Variable an sich mit dem Descriptor, der auf den Wert im String-Space zeigt). Da ist "NUMBERS" eine Themenverfehlung.
    Die Bezeichnung "VALUES" ist als Begriff zu allgemein und sag überhaupt nichts aus. Gemeint ist eigentlich "VARIABLES" oder in der nicht unüblichen Abkürzung "VARS". Das ist an sich der gängige Begriff. Warum wird dieser nicht verwendet. Da weiß eigentlich jeder, was gemeint ist und ist auch in jeder Dokumentation so benannt. ;)

  • VARIABLES oder VARS in der Zeile finde ich gut. In der Spaltenüberschrift favorisiere ich weiterhin BYTES. ;)

  • Hier mal ein Beispiel, wie Exbasic das macht. Also auch VARIABLES und BYTES.


  • ganz blöde Frage - vielleicht habe ich es beim Lesen auch einfach übersehen?!? - dieses Basic 4.5 - ladet ihr das ausschließlich als Programm? (.prg)

    Oder soll das auch mal irgendwie in den BASIC-ROM, oder als alternativer BASIC-ROM "gebrannt" werden?

  • Also doch nicht übersehen... Habe nämlich nix von nem ROM irgendwo gefunden, aber genau DAS meinte ich mit übersehen, aber ist ja somit geklärt - DANKE!


    Und Schade, das vorab laden einer Basic-Erweiterung finde ich insofern "lästig", weil man a) dadurch weniger Speicher zur Verfügung hat und b) eben immer erst was vorab laden muss - beim plus/4 ist eben das bessere Basic schon "drin" - beim 64er muss man es immer erst laden oder wenn man es besitzt, per Modul stecken (schon besser, als laden), aber immer noch Mehraufwand, gegenüber "beim Einschalten da" :/.


    MEINE persönliche Meinung!!! Fände es nur sehr praktisch, das BASIC fest im Rechner zu haben, oder ggf. nachladbar, wie bei einigen Mehrfach-KERNALs...

  • Ohh, da ist mir offenbar die gesamte Seite "abhanden" gekommen - Danke für den Link.
    Schade, dass es dann doch nicht so "einfach" geht - dann wäre evt. ein Steckmodul ne Alternative... Sofern das umsetzbar wäre?

  • Dafür hab ich zu wenig Ahnung, was genau das bedeutet?!? Ich vermute mal, dass man sie ggf. irgendwo drauf "brennen/packen" kann??

  • Ah okay, muss ich jetzt mal ein bißchen nachschlagen, was das im Detail bedeutet - Danke erstmal für die Aufklärung :D