Beiträge von Hexworx im Thema „Freier Speicher“
-
-
Glückwunsch zum 1000. Beitrag.
Schönen Gruß.
um den freien
Variablenspeicher zu ermittelnWäre vielleicht einfacher mit peek.
was wäre mit peek einfacher?Hinter fre(0) steckt ja nicht nur das Auslesen der Speicherstellen, sondern auch noch der Aufruf der Stringaufräumung
...und das ist auch gut so. Ändert aber nix. -
Während bei fre(0) der freie Variablenspeicher angegeben wird
Dann erklär' mal bitte, warum dein sog. "Variablenspeicher" kleiner wird, wenn ich den BASIC-Code verlängere, aber die Variablen gar nicht anfasse?Wie jetzt schon mehr geschrieben und ja auch visuell dargestellt, ist es einfach nur SPEICHER, der für was auch immer verbraten werden kann. Deswegen ist es immer noch KEIN Variablenspeicher!
Der FRE(IE) Speicher liegt nun mal zwischen den Arrays und den Strings (er könnte auch woanders liegen). Wohlbedacht ist das aber eben nicht gemacht worden. Stichwort GBC.
Mehr werde ich meine Tastatur zu dem Thema jetzt auch nicht mehr abnutzen.
Die Idee mit der Speicheranzeige reizte mich aber. Bin dabei. Müsste auch in den Kassettenpuffer passen. Bis später, ähm... Schönen Gruß.
-
Das wäre dann ein Drei- oder Vierfarbbalken.
So was müßte man eigentlich auch alsBasic-Demo programmieren können.
Witzige Idee an sich. Dann aber bitte in Assembler als Screen-Code @$0400
. -
Die Anfangsfrage war meiner Meinung nach warum fre(.) und die Einschaltmeldung zu verschiedenen Ergebnissen kommnen.
Bei der Einschaltmeldung rechnet er $37/38 minus $2B/2C; bei FRE $33/34 minus $31/32. Das ist schon alles. Zack - zwei Bytes verschwunden
. -
Anklicken, staunen und verstehen
"Das wandernde Doppel-Nullbyte"
Nur der Variablenbereich mit Variablen, Strings und fre(0)+Garbage Collection fehlt noch.
Alles da
-
Bitte melde dich an, um diesen Anhang zu sehen.

-
Aber im Prinzip, berechnet fre(0) den freien Variablenspeicher.
NEIN!Der verfügbare(!) BASIC(& Variablen)-Speicher ist und war nie wirklich 38911 Bytes! Durch die drei '00'-Bytes werden immer zwei Bytes 'geklaut' (wobei die aber eben als Flags nötig sind).
Wenn bereits Variablen angelegt worden sind, dann hat fre(0) aber keine Aussagekraft mehr darüber, wie groß das Basic-Programm noch werden kann.
Doch! Siehe oben.Hör' doch auf, den Programm- und den Variablen-Speicher zu trennen. Das ist doch alles eine Wurst.
Menno, BIF

-
Ich denke mal man kann unterscheiden zwischen
freien Basic Speicher
und
freiem Variablen-Speicher.
Wie auch immer du das jetzt gemeint hast...Es gibt halt nur einen Speicher. Ob ich den nun mit einem (BASIC)-Programm verbrate oder mit den (BASIC)-Variablen (z. B. durch zu groß dimensionerte Arrays oder ungenutzte Strings). Speicher bleibt Speicher.
Der Speicher setzt sich ja in dieser Reihenfolge zusammen:
BASIC-Programm | Variablen | Arrays (reserviert) | FRE | Strings
D. h., das BASIC-Programm schiebt die Variablen und Arrays vor sich her, wenn es größer wird. Die Strings kommen von hinten entgegen.
Beispiel:
10 REM
DIM A(100)
B=1
A$="TEST"PRINT FRE(0) + 65536 = 38373
Danach:
$2B/2C: $0801-$0808 (BASIC-PRG.) -> 8 Bytes
$2D/2E: $0809 (Variablen A$ u. B) - zwei Variablen à 7 Bytes -> 14 Bytes
$2F/30: $0817 (Array-Beginn für A) *
$31/32: $0A17 (Array-Ende für A) *
$33/34: $9FFC (String-Speicher-Beginn [A$]) -> 4 Bytes* $0A17 - $0817= $0200 = 512 =7 + (101 x 5) -> 512 Bytes
$9FFC (40956) - $0A17 (2583) = 38373
8 + 14 + 4 + 512 = 538
38911 - 538 = 38373
-
PRINT FRE rechnet ab Ende Arrays ($31/32), was standardmäßig bei $0803 liegt.