Diskussion:Speicherbelegung (BASIC)
Wäre es nicht besser die Speichadressen in der 1. Zeile senkrecht anzuorden. Dann könnte die Tabelle besser erweitert werden... --Jodigi 06:03, 25. Okt. 2009 (CET)
- Finde ich auch, gehöhrt auf jeden Fall gekippt. Weniger wegen erweitern, mehr dem Platz in den Zellen willen. Außerdem geht das scrollen vertikal leichter ;) --JohannKlasek 08:23, 25. Okt. 2009 (CET)
- Warum nicht die Tabelle übernehmen, die bei Speicherbelegungsplan unter der Überblick-Grafik zu sehen ist? Oder noch besser: Zeropage! --GoDot 10:55, 25. Okt. 2009 (CET)
- Ich hab's mal in eine Definitionsliste umgewandelt, die Tabelle ging ja gar nicht - um das irgendwie verständlich zu machen, gehören pro Eintrag mehrere Zeilen Text dazu, und dafür ist eine Tabelle nicht geeignet. Der Artikelname ist etwas irreführend, "Aufbau (BASIC-Speicher)" z.B. wäre denke ich besser. Schreibt bitte nicht aus AAY64 ab, das ist nur eine Referenz für Profis, keine Erklärung! Nehmt für sowas lieber Mapping the C64 als Ausgangspunkt, da wird auch erklärt, nicht nur präsentiert. -- 1570 11:12, 25. Okt. 2009 (CET)
- Warum nicht die Tabelle übernehmen, die bei Speicherbelegungsplan unter der Überblick-Grafik zu sehen ist? Oder noch besser: Zeropage! --GoDot 10:55, 25. Okt. 2009 (CET)
- Auch hier bitte erst diskutieren bevor etwas umgesetzt wird. Nicht dass jemand sich unnötige Arbeit macht... --
- Auswertung der Abstimmung "Tabelle - Speicheradresse in 1. Spalte": 4 Dafür - 1 Dagegen
- Jodigi 16:15, 25. Okt. 2009 (CET)
- Gut, Moiree hat das glaub ich hübsch umgesetzt. Dennoch noch eine wesentliche Kleinigkeit, um dessen Korrektur ich noch bitte: Zwischen FRETOP und MEMSIZ, also der vom String-Heap belegten Teil entspricht nicht den "Stringvariablen", sondern hier befinden sich lediglich die Werte der Stringvariablen und auch aller vom Interpreter sonst angelegten temporären Zeichenketten (die mitunter niemals mit einer Variable zu tun hatten, z.B. bei
PRINT "123"+"456"). Es sind auch nicht mehr referenzierte Stringwerte enthalten, die irgendwann später von der Garbage Collection weggeräumt werden. Also gehört hier Zeichenketten (ohne Variablen) hin. Zwischen VARTAB und ARYTAB befinden sich nicht nur "numerische Variablen", sondern alle nichtindizierten Variablen, also auch solche vom Typ Zeichenkette (enthält an dieser Stelle allerdings nur einen Descriptor, der dann auf die Zeichenkette, den Variableninhalt, im String-Heap verweist). --JohannKlasek 21:10, 26. Okt. 2009 (CET)
- Gut, Moiree hat das glaub ich hübsch umgesetzt. Dennoch noch eine wesentliche Kleinigkeit, um dessen Korrektur ich noch bitte: Zwischen FRETOP und MEMSIZ, also der vom String-Heap belegten Teil entspricht nicht den "Stringvariablen", sondern hier befinden sich lediglich die Werte der Stringvariablen und auch aller vom Interpreter sonst angelegten temporären Zeichenketten (die mitunter niemals mit einer Variable zu tun hatten, z.B. bei
Möchte loben, dass es die kostbare C64 Wiki überhaupt gibt, aber auch konstruktive Kritik anbringen: Das ganze ließe sich grafisch sicherlich besser darstellen, und wenn gewünscht mache ich mir auch diese Arbeit!
- Die Text-Beschreibung zur Map ist genau verdreht (oben/unten vertauscht).
- Bei den Pointern wäre der Hinweis angebracht, ob die Adresse exakt stimmt, oder +1 / -1 gerechnet wurde. Bspl: MEMSIZ zeigt auf $A000, da fängt aber schon das Interpreter-ROM an. TXTTAB mit $0801 ist gut und schön, aber auf $0800 muss ein Zero-Byte sein.
- Ausserdem finde ich es wichtig, dass auf den Unterschied zwischen statischen Strings (deren Pointer genialerweise direkt in den Basic-Code zeigen, wo eh schon alles dasteht!), und dynamischen Strings (solche die verändert oder zusammengebaut werden) deutlich hingewiesen wird.
Das ist nämlich nicht so selbstverständlich, dass nur die dyn. Strings von oben nach unten wachsen (wie die Stalagtiten), und dass nur der Variableninhalt dort oben hängt, aber von woanders dorthin gezeigt wird.
- Auch wäre eine Ergänzung gut, was beim Ändern der Pointer zu berücksichtigen ist, damit das OS das auch "frisst", also übernimmt. Verlinkung zu CLR-Befehl & FRE(0)-Befehl wäre daher auch noch okay.
-- 17:51, 16. Apr. 2023 84.115.239.106
- Ja, der Artikel ist noch ziemlich verbesserungsfähig. Preisfrage ist nur, wie man das besser machen kann, ohne sich zu verzetteln. Was schwebt dir denn vor? (Anpassung der Reihenfolge, klaro, und sonst?) - Von den Punkten, die Du ansprichst, sind einige im Beispiel ersichtlich bzw. erklärt. Man könnte das auch noch direkt bei der ersten Nennung der Pointer irgendwie einbauen, müsste man halt schauen, wie das mit Layout und Platz auch auf Mobilgeräten ist. - Vorgehen bei Änderung der Pointer, klingt gut. Vielleicht erstmal einfach als Auflistung von Punkten? Im Forum64 gibt es zum Thema etliches, u.a. glaube ich auch, wie man den Variablenspeicher nach C000-CFFF verlegen kann und so weiter. -- 1570 (Diskussion) 23:27, 16. Apr. 2023 (CEST)
Tja, die deutsche Wiki-Seite hier ist im Vergleich zur englischen "so lala". Übrigens wer von MEMSIZ spricht sollte auch von MEMSTR sprechen! Und wenn schon, dann auch richtig wenn´s geht: MEMSIZ (Basic-Obergrenze, SIZ steht für SIZE) ist in Wahrheit ein Zeiger bei $0283/$0284 und wird von der Routine MEMTOP ($FE25, memory top) verwendet. MEMSTR (Basic-Untergrenze, STR steht für START) ist ein Zeiger bei $0281/$0282 und wird von der Routine MEMBOT ($FE34, memory bottom) verwendet. Wer 100% sauber und korrekt das Basic-RAM verbiegen will, der sollte diese Zeiger mitberücksichtigen! Danach ist das Ausführen des Basic-Befehls NEW anzuraten (das auch ein CLR durchführt), damit alles korrekt übernommen wird. Am besten das Ganze in einer kleinen Maschinenroutine mit abschließendem, korrekten Rücksprung. Wenn du willst, kannst du dieses Wissen in die Wiki übernehmen. Aber pass auf, dass du dich dabei nicht verzettelst und die extrem wichtige Developer-Gruppe der Mobilgerätenutzer vergraulst! ;-) (P.S. Sehr hilfreiches Buch hierzu: C64 für Insider von Florian Müller)
