Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.

Zitat von GoDot

Zitat von Snoopy

Zum umwandeln des Tokenwert in Klartext würde ich versuchen, die Routine von LIST zu "missbrauchen". Eventuell lässt sich damit was relativ Platzsparendes zaubern?

*Ein* Byte? Aber ich schau mal, ob man nicht was ganz anderes damit coden könnte, einen Quelltext-Generator… (Klar, gibt‘s schon, aber das ist doch mal ne schöne Aufgabe!)

Arndt

Was hindert dich daran, die komplette bisherige FIND-Routine zu räumen und mit dem freien Platz deine eigene FIND-Routine zu schreiben? Omega würde sich vermutlich sehr freuen.

Zitat von Snoopy

Was hindert dich daran, die komplette bisherige FIND-Routine zu räumen und mit dem freien Platz deine eigene FIND-Routine zu schreiben?

Die hat (jetzt) 156 Bytes, das ist nicht besonders viel... Ich hab mir nochmal den Detokenizer von TSB näher angeschaut (den hatte ich ja sowieso erst kürzlich unter dem Mikroskop), wegen Quelltext-Generator. Nein, er ist zu sehr mit dem TSB-Bildschirmeditor verwoben (mit PAGE, DELAY und OPTION), da kriege ich durch einfaches Mitbenutzen kein brauchbares Ergebnis. Man müsste das für einen Generator in ein eigenes Programm schreiben, was dem Sinn der Aktion aber widerspräche. Also: ein Generator aus FIND geht so nicht.

Arndt

Ich kenne den TSB-Code so gut wie nicht, aber vielleicht hilft dir folgende Gedankenskizze weiter?

- FIND xyz, der Suchstring xyz wird gespeichert.

- man beginnt mit der erste Zeile des TSB-Programms

- man speichert jedes Zeichen der Zeile in einen Puffer und erhöht den Pufferzeiger um eins, außer es ist ein Token, dann speichert man den daraus ermittelten Klartext in den Puffer und erhöht den Zeiger um die Länge des Klartextes

- man prüft, ob der Suchstring xyz im Puffer vorkommt, falls ja, aktuelle Zeilennummer wird ausgegeben, alternativ wäre auch Prüfen während Pufferaufbau denkbar

- Pufferzeiger wieder auf Anfang und nächste Zeile abarbeiten, bis Programmende erreicht.

Du brauchst für eine TSB-Zeile genug Puffer und für den Suchstring.

Keine Ahnung, ob du das so unterbringen kannst? Omega würde dir sicherlich ein Osterei spendieren.

Ergänzung: Da FIND ja nur ein Direktkommando ist, bietet sich als Puffer auch der Bildschirmspeicher bzw. das Farbram an. Dann kann man vielleicht sogar beim Suchen "zugucken".

Willkommen in der Welt der Tokens.

Zitat von Omega

Für mich als BASIC-Programmierer ist das Programm das, was der LIST-Befehl anzeigt. Wie das intern mit Tokens gespeichert wird interessiert mich nicht.

Ich glaube, dass bei C64-Menschen diese Art von PC-Arroganz nicht gut ankommt... Wer für den C64 brennt, kennt auch die Schwächen und Unzulänglichkeiten des Systems. Gerade darum lieben wir ja unser Baby.

Zitat von Omega

Außerdem würde ich den Suchstring in Anführunsgzeichen einschließen. Also z.B. find "hallo".

Das kannst du gerne jetzt schon tun.

Zitat von Omega

Als Pufferspeicher könnte man im nrm-Modus den Bereich von $cc00-$cfe7 verwenden.

Dann hast du RENUMBER und PLACE plattgemacht und TSB stürzt in Kürze ab.

Und dir scheint immer noch nicht klar zu sein, dass ein Elefant nicht durchs Mauseloch passt. (Das Mauseloch sind 157 Bytes Platz für FIND, der Elefant ist ein O-Mega-FIND.)

Arndt

Arndt

Zitat von Omega

Das ist ja ein richtiges Kunstwerk.

Leider nicht von mir...

Es gilt während des tatsächlichen Lesens und Schreibens. Das Timing im Kernal für das serielle Protokoll ist so knapp, dass die längere Badline durch den Spritezugriff zu einem Deadlock führen kann.

voll rückständig. Eigentlich müsste doch da der Kernal die Sprites selbsttätig abschalten damit der User damit nichts zu tun hat. Kann da mal einer die Disk-Routinen anpassen? *flitz*

Frohe Ostern! Jehova!

Zitat von Claus

Es gilt während des tatsächlichen Lesens und Schreibens. Das Timing im Kernal für das serielle Protokoll ist so knapp, dass die längere Badline durch den Spritezugriff zu einem Deadlock führen kann.

Oder für Omega formuliert: Dein TheC64 mini würde dabei sicherlich in Flammen aufgehen!

Zitat von Omega

Was hat das serielle Protokoll mit Sprites zu tun?

Willkommen in der wunderbaren Welt des Commodore 64!

Zitat von Omega

Gibt es dazu irgendwelche Informationen im Internet, die das belegen?

Du kannst ja mal mein kleines Testprogramm laufen lassen. Friert bei mir (Vice mit True Drive und originale Hardware) zuverlässig ein.

Zitat von Omega

Zitat von Claus

Das Timing im Kernal für das serielle Protokoll ist so knapp, dass die längere Badline durch den Spritezugriff zu einem Deadlock führen kann.

Was hat das serielle Protokoll mit Sprites zu tun? Gibt es dazu irgendwelche Informationen im Internet, die das belegen? Oder ist das so ein Aberglaube wie: "Wenn einem eine schwarze Katze über den Weg läuft, wird man vom Pech verfolgt"?

Wenn du ein serielles Kabel mit Goldkontakten hast und es stets parallel zu einer Wasserader ausrichtest, dann kann dir nichts passieren!

Zitat von Omega

Zitat von Claus

Das Timing im Kernal für das serielle Protokoll ist so knapp, dass die längere Badline durch den Spritezugriff zu einem Deadlock führen kann.

Was hat das serielle Protokoll mit Sprites zu tun? Gibt es dazu irgendwelche Informationen im Internet, die das belegen? Oder ist das so ein Aberglaube wie: "Wenn einem eine schwarze Katze über den Weg läuft, wird man vom Pech verfolgt"?

Natürlich gibt es dazu offizielle Informationen im Internet, hier zum Beispiel: Laden und Speichern von High Score Tabellen in Assembler - Auf was muss ich achten?