GoDot: Na gut. Du wirst schon wissen was du tust. Hauptsache du dokumentierst es in der TSB-Bedienungsanleitung. Damit es auch jeder, inklusive mir, versteht. Und ein bis drei Wochen ist schon gut. Das passt. Ich habˋ ja die GHV-Spezial-Version. Damit habe ich immer einen Trumpf im Ärmel, den ich jederzeit ausspielen kann.
Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.
- Omega
- Thread is Unresolved
-
-
Nach ein bisschen Herumprobieren mit MAP: Weglassen der beiden Ortsparameter lohnt sich nicht, denn es wird vom Befehl ja immer nur eine Kachelzeile ausgegeben und nicht der ganze Screen. Die Information, wo diese Zeile senkrecht erscheinen soll, befindet sich aber in Parameter 2.
Auch eine Umstellung auf AT(x,y) ist nicht wirklich schlüssig, denn der Befehl gehört zum Kontext der MOVE-Befehle, die allesamt die gleichen zwei ersten Parameter (Spalte, Zeile) haben. Da ist es konsistenter, auch bei MAP dabei zu bleiben.
MAP ist nicht von vornherein aktiv. Man muss es zunächst "freischalten", indem man in der Befehlsvektorenliste, die zugehörige Adresse einträgt. Solange das nicht erfolgt, wirft die Verwendung des Befehls MAP die (neue) Fehlermeldung "?cmd not active error" aus ("cmd" steht für "command").
Arndt
-
MAP ist nicht von vornherein aktiv. Man muss es zunächst "freischalten"...
Aha! Das habe ich mir schon gedacht. Und wieviel soll die Freischaltung kosten?
-
Hi GoDot,
wäre es nicht besser einen Functions-Befehl einzubauen, statt laufend die bestehende Befehle zu veränderen
So wie in Q-Basic.
Somit kann dann jeder seine eigene Befehle zum Projekt passen selber erstellen. Und du musst nicht laufend am Herzen vom TSB operieren.
-
wäre es nicht besser einen Functions-Befehl einzubauen, statt laufend die bestehende Befehle zu veränderen
Der Befehl PROC ist so etwas Ähnliches, nur dass Variablenwerte eben global sind. Was ich hier neu einbaue, ist ein Befehl, der *auf schnelle Weise* selbstdefinierte Kacheln ausgibt. Omega hat das bisher mit PROCs (was du als FUNCTION bezeichnest) gemacht, was nun mal in Basic ziemlich gemächlich vonstatten geht. Und die bestehenden Befehle werden nur dann verändert, wenn wir daran einen gravierenden Mangel feststellen (worin Omega unschlagbar ist).
Arndt -
wäre es nicht besser einen Functions-Befehl einzubauen, statt laufend die bestehende Befehle zu veränderen
Was ich hier neu einbaue, ist ein Befehl, der *auf schnelle Weise* selbstdefinierte Kacheln ausgibt.
So einen Befehl könnte man in BASIC/TSB, wegen der geringen BASIC-Geschwindigkeit, gar nicht programmieren. Also könnte man schon, aber dann ist es wieder genauso langsam wie vorher. Vielleicht sogar noch langsamer. GoDot baut in TSB nur Befehle ein, die man nicht selbst mit Prozeduren erzeugen kann.
Drachen: So einen Funktionsbefehl, bei dem die aufgerufene Funktion einen Rückgabewert über den Funktionsnamen zurückgibt, fände ich auch sehr schön. Aber das macht relativ wenig Sinn, glaube ich, weil TSB keine lokalen Variablen hat, die nur auf Prozedur- (bzw. Funktions-)ebene gültig sind. In modernen BASICs wie Q-Basic oder VB sind wir so einen Luxus gewöhnt. Und noch vieles mehr. Aber auf dem kleinen C64 geht das wohl, wegen mangelndem Speicher, nicht.
-
Drachen: So einen Funktionsbefehl, bei dem die aufgerufene Funktion einen Rückgabewert über den Funktionsnamen zurückgibt, fände ich auch sehr schön. Aber das macht relativ wenig Sinn, glaube ich, weil TSB keine lokalen Variablen hat, die nur auf Prozedur- (bzw. Funktions-)ebene gültig sind. In modernen BASICs wie Q-Basic oder VB sind wir so einen Luxus gewöhnt. Und noch vieles mehr. Aber auf dem kleinen C64 geht das wohl, wegen mangelndem Speicher, nicht.
Klar geht das. Comal macht das zum Beispiel so.
-
EgonOlsen71: Ja, stimmt. Das habe ich ganz vergessen. COMAL ist ziemlich gut, das habe ich früher in der Schule im Informatikunterricht gelernt als ich noch jung war. Und das hatte auch Funktionsprozeduren. Daran kann ich mich noch erinnern.
EDIT: Dafür hat man in der Diskettenversion von COMAL V0.14 auch deutlich weniger BASIC- bzw. Programmspeicher frei als in TSB. Wenn ich mich richtig erinnere. Hat also beides seine Vor- und Nachteile.
-
EDIT: Dafür hat man in der Diskettenversion von COMAL V0.14 auch deutlich weniger BASIC- bzw. Programmspeicher frei als in TSB. Wenn ich mich richtig erinnere. Hat also beides seine Vor- und Nachteile.
Mit Comal auf Modul hast du etwas über 30K frei. Die Diskettenversion habe ich nie ausprobiert.
-
EgonOlsen71: Bei der Diskettenversion hat man weniger als 10 KB frei. Und die Diskettenversion hat längst nicht alle Features der Modulversion. Das Problem mit der Modulversion ist, wenn man so kleine Spiele schreibt wie ich, dass man dann Probleme mit der Weitergabe hat. Da müsste der Spieler ja erst das CRT-Modul in den Emulator einbinden und dann innerhalb von COMAL das Spiel laden. Und wer einen echten C64 hat, kann gleich nach Hause gehen.
-
, weil TSB keine lokalen Variablen hat, die nur auf Prozedur- (bzw. Funktions-)ebene gültig sind. In modernen BASICs wie Q-Basic oder VB sind wir so einen Luxus gewöhnt. Und noch vieles mehr. Aber auf dem kleinen C64 geht das wohl, wegen mangelndem Speicher, nicht.
Klar geht das. Comal macht das zum Beispiel so.
...und BBC Basic auch, und auch diverse andere Basic-Erweiterungen können das (in unterschiedlichen Ausprägungen). Mit dem verfügbaren Speicher hat das schlicht und einfach nichts zu tun.
Und wenn man auf Rekursionsfähigkeit verzichten kann (was bei real existierenden Programmen oft der Fall ist) und nur getrennte Namensräume haben will, wird es noch einfacher.
-
COMAL ist ziemlich gut, das habe ich früher in der Schule im Informatikunterricht gelernt als ich noch jung war. Und das hatte auch Funktionsprozeduren.
Ihr hattet die Module in der Schule? Wow! Wie habt ihr das denn finanziert gekriegt? Meins hat damals 190 DM gekostet!
Neben der Basis-Einstellung, die der C64 hardwaremäßig mitbringt, läuft Comal komplett im RAM und kann 4 16KB-ROM-Pages, die auf dem Modul liegen (also noch mal 64 KB), für bestimmte Zwecke einblenden (Sound, Sprites, Turtle usw.), erweiterbar um noch mal 2 16-KB-Eproms. Das, damit EgonOlsen71 eine Vorstellung hat, was den Unterschied zwischen TSB und COMAL ausmacht. Das ist mit einer einfachen Basic-Erweiterung wie TSB nicht zu leisten.
Arndt
-
GoDot: Wir hatten die Diskettenversion in der Schule. Die hat der Lehrer an alle Schüler (kostenlos) weiterverteilt. Und wer das offizielle Handbuch dazu haben wollte, durfte sich das auf eigene Kosten beim Herausgeber bestellen. War aber nicht so teuer. Und brauchte man eigentlich nicht, weil der Lehrer seine eigenen Unterlagen mit allen wichtigen Informationen wöchentlich verteilt hat.
EDIT: Die Diskettenversion hatte aber auch Prozeduren, Funktionsprozeduren, Turtle-Grafik, Spritedefinitionen usw. Aber man hatte eben weniger als 10 KB Speicher frei.
Die Spiele, die ich damit geschrieben habe, waren deshalb ziemlich spartanisch. Bei einem ging es darum, mit einem Raumschiff durch einen Meteroitengürtel zu fliegen und den bösen Meteoriten auszuweichen und die guten Meteoriten einzusammeln.
Und bei dem andern ging es darum, Regentropfen, die vom Himmel gefallen sind, mit einem Raumschiff einzufangen damit die Welt nicht überflutet wird.
-
Und bei dem andern ging es darum, Regentropfen, die vom Himmel gefallen sind, mit einem Raumschiff einzufangen damit die Welt nicht überflutet wird.
Das war ja schon damals sehr löblich! Übrigens war für mich das Comal damals ebenfalls einer der Gründe, mich mit Simons' Basic zu befassen. Ich war dann ziemlich entsetzt, was da alles nicht ging bzw. mangelhaft gelungen war. Da *musste* ich mich der Sache ja annehmen!
Arndt
-
-
Retrofan
Changed the title of the thread from “Simon's Basic/TSB: Farben, Zeichensätze, Sprites & Co.” to “Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.”. -
Ich experimentiere schon mal ein bisschen mit dem neuen MAP-Befehl (um zu sehen, was man da noch einbauen könnte). Hier mal ein Screen aus einem Spiel, über das ich sonst keinerlei Informationen habe, es ist nur als Beispiel im CharPad dabei (Cave Adventure, ich hab dazu nichts im Web gefunden). Was in TSB (bzw. überhaupt) benötigt wird, ist der Zeichensatz, die Farben (der einzelnen Zeichen), die Liste der Kacheln und schließlich die Map (die Anordnung der Kacheln auf dem Screen). Dabei fiel mir auf, dass die Farben (anders als bei Omega ) üblicherweise zeichenweise (und nicht kachelweise) abgelegt werden. Ich hab das erst mal so gemacht wie Omega (kachelweise und dann hier und da "nachgefärbt", links das Original):
Man braucht ein bisschen Vorarbeit (mit Endurion s C64Studio) und dann sieht das doch ganz brauchbar aus.
Arndt
-
Ich hab das erst mal so gemacht wie Omega (kachelweise und dann hier und da "nachgefärbt", links das Original):
Du könntest es ja so machen, dass man in dem Farbarray, das man dem Map-Befehl übergibt, entweder einen Farbwert oder vier Farbwerte pro Kachel benutzt.
Ich würde da allerdings nicht übertreiben. Sonst musst du am Ende auch noch Multicolor berücksichtigen.
Ich halte mich da immer an Plato:
"In der Einfachheit liegt die Schönheit."
-
Oder halt so wie in Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co. (1673) beschrieben einfach Strings inkl. Cursor-Steuercodes und Farbcodes ausgeben. Dann spart man sich das Gefrickel mit einem separaten Farbarray und kann den Befehl auch gleich noch wesentlich vielseitiger benutzen. Im Moment ist das ja eher ein GHOSTVIEWMAPPRINT.
-
Oder halt so wie in Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co. (1673) beschrieben einfach Strings inkl. Cursor-Steuercodes und Farbcodes ausgeben.
Das geht schon (einfach String anhängen). Ist aber mit PRINT vergleichbar, also langsam. Man kann damit immerhin im schnellen "GHOSTVIEWMAPPRINT" Akzente setzen.
Arndt
-
Ich würde da allerdings nicht übertreiben. Sonst musst du am Ende auch noch Multicolor berücksichtigen.
Ach du Schreck! Nein, wie gut, dass MAP ein Befehl sein wird, den man erstmal einbinden muss. Da kann dann jeder seine eigene Version basteln, wie er es halt braucht. Mir reicht vorläufig die Hires-Variante, auch als Anschauungsmaterial...
Arndt