Optimierungsgrad KERNAL /BASIC - fiktiver Talk

Es gibt 337 Antworten in diesem Thema, welches 62.637 mal aufgerufen wurde. Der letzte Beitrag (16. September 2017 um 00:34) ist von Boulderdash64.

  • Ein Cartridge kann so viel Speicher haben wie man will, da man per Bankswitching immer wieder neue Bänke einblenden kann. DARAN würde es also nicht scheitern :D .

    Dann könnte man theoretisch wesentlich mehr als die geforderten 16k unterbringen! Allerdings - Vorsicht! - damit verlassen wir dann endgültig das Thema hier. :wink:

    Jedenfalls ginge sich dann ein fast schon erwachsenes Betriebs- und Programmiers-System aus. Wär DAS herrlich! 8o

  • Der advocatus diaboli (-> Bitte melde dich an, um dieses Bild zu sehen. <-) sagt: Selbst wenn man ein wie auch immer geartetes System in das Rom eines Cartridges reinpacken könnte, blieben zwei schwerwiegende Probleme bestehen: 1.) Der RAM-Speicher ist immer noch sehr klein für das Bearbeiten und Kompilieren von längeren Programmtexten. 2.) Der Prozessor wäre immer noch zu langsam, um längere Programme zu übersetzen. Damals[tm] habe ich mir es angetan, Minuten lang auf den Compiler zu warten. Heute kriege ich schon die Krise, wenn die Übersetzung länger als ein paar Sekunden dauert. Daran würde auch ein 50Mhz 6510 nichts ändern.
    Aber nehmen wir mal an, man könnte in das normale Kernal-Rom einen Treiber für ein größeres Rom auf dem Cartridge unterbringen (um wieder näher am Thema zu bleiben): Was genau sollte darin aufgenommen werden? Welche Teile zählst Du zu einem Betriebs- und Programmiersystem?

  • Also dann doch eher einen guten Cross-Compiler unter Windows oder Linux und dann im Emulator testen. Gibbet da schon wat Brauchbares?

  • Gibbet da schon wat Brauchbares?

    Gute Frage. :/ Leider scheint es z. B. auf c64-wiki keine Liste der Programmiersprachen (nicht Assembler) zu geben, die mittels Cross-Compiler Code (6502 oder Bytecode) für den C64 erzeugen können. Spontan würden mir da nur die beiden C-Compiler cc65 und gcc einfallen. Und dann gab es, glaube ich, noch den Port eines Java-Bytecodeinterpreters auf den 6502. (Gab es davon auch eine Version für den C64?) Andere offizielle Quellen sind mir leider nicht bekannt.
    ThomBraxton: Was würdest Du denn als "brauchbar" empfinden?

  • Selbst wenn man ein wie auch immer geartetes System in das Rom eines Cartridges reinpacken könnte, blieben zwei schwerwiegende Probleme bestehen: 1.) Der RAM-Speicher ist immer noch sehr klein für das Bearbeiten und Kompilieren von längeren Programmtexten.

    Cartridges können auch RAM bereitstellen.

    Der Prozessor wäre immer noch zu langsam, um längere Programme zu übersetzen.

    Ein inkrementeller Compiler (der bei der Eingabe direkt compiliert) auf dem C64 wäre wirklich eine Herausforderung. ;)

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Gute Frage. :/ Leider scheint es z. B. auf c64-wiki keine Liste der Programmiersprachen (nicht Assembler) zu geben, die mittels Cross-Compiler Code (6502 oder Bytecode) für den C64 erzeugen können. Spontan würden mir da nur die beiden C-Compiler cc65 und gcc einfallen. Und dann gab es, glaube ich, noch den Port eines Java-Bytecodeinterpreters auf den 6502. (Gab es davon auch eine Version für den C64?) Andere offizielle Quellen sind mir leider nicht bekannt. ThomBraxton: Was würdest Du denn als "brauchbar" empfinden?

    Ich habe auch so einen Java-Versuch in Erinnerung. Allerdings würde ich bei DEN Restriktionen nicht grade auf Java zurückgreifen.

    Ein inkrementeller Compiler (der bei der Eingabe direkt compiliert) auf dem C64 wäre wirklich eine Herausforderung.

    Oh ja, und ein toller dazu! :smile:

    Aber auch eine faszinierende Vorstellung. Man haut einfach eine kleine Funktion rein, die wird sehr schnell in die VM-Sprache übersetzt (halt so schnell wie eine Basic-Zeile übernommen wird), und läuft dann auch viel schneller. Das wäre doch wirklich toll!

  • Der advocatus diaboli (-> Bitte melde dich an, um dieses Bild zu sehen. <-) sagt: Selbst wenn man ein wie auch immer geartetes System in das Rom eines Cartridges reinpacken könnte, blieben zwei schwerwiegende Probleme bestehen: 1.) Der RAM-Speicher ist immer noch sehr klein für das Bearbeiten und Kompilieren von längeren Programmtexten. 2.) Der Prozessor wäre immer noch zu langsam, um längere Programme zu übersetzen. Damals[tm] habe ich mir es angetan, Minuten lang auf den Compiler zu warten. Heute kriege ich schon die Krise, wenn die Übersetzung länger als ein paar Sekunden dauert. Daran würde auch ein 50Mhz 6510 nichts ändern.

    Aber nehmen wir mal an, man könnte in das normale Kernal-Rom einen Treiber für ein größeres Rom auf dem Cartridge unterbringen (um wieder näher am Thema zu bleiben): Was genau sollte darin aufgenommen werden? Welche Teile zählst Du zu einem Betriebs- und Programmiersystem?

    Der Advocatus hat meistens recht. Auch diesmal. :wink:

    Drum auch die Idee von oben: Kleine, überschaubare, leicht compilierbare Portionen. Große Brocken kann man immer noch exportieren oder gleich woanders erstellen und optimierend cross-compilieren. Aber direkt arbeiten geht so viel besser, praktisch interaktiv!

    Welche Teile zähle ich zum Betriebssystem? Ich glaube, das können andere viel besser beantworten. Vermutlich alles was mit grundlegendem I/O und HW zu tun hat? Dazu die virtuelle Maschine (ohne der es nicht geht, wenn teile davon in VM-Code erstellt sind). Alles, wofür man komplizierte Interrupts braucht?

    Programmiersystem: VM, soweit nicht beim OS? Online-Editor (möglichst simpel) und "Compiler", aber natürlich auch alle Cross-Compiler. Libraries. Und das wär ja das Geile: Die Libs könnte man allesamt in beliebigen Sprachen erstellen, und reinkompilieren, wenn so Sachen wie Parameter-Übergabe etc. genormt sind. Es wär möglich, beliebige Libs zu laden, nachzuladen, etc, und recht einfach einen Build draus zu machen. Bloß DLLs wären vielleicht zu viel verlangt. :wink:

  • Könnte man diesen "spinnerten" VM-Kram ;) ab Bitte melde dich an, um diesen Link zu sehen. mal in einen neuen Thread auslagern? Ich seh' überhaupt keinen Zusammenhang mehr zum Ursprungsthema (von Mike's Beiträgen abgesehen, die noch passen, aber dann leider etwas aus dem Zusammenhang gerissen wären).

    Aber wie man Programmiersprachen designt und implementiert, davon verstehe ich schon mehr.

    Das heißt? Nur in der Theorie oder gibt es auch praktische Referenzen?

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Das heißt? Nur in der Theorie oder gibt es auch praktische Referenzen?

    Keine bekannten, ausser einem Haufen von Parsern und Generatoren für berufliche Zwecke (so Sachen wie Grammatik-Transformatoren und Code-Generatoren und so Zeugs). Ansonsten nur entsprechende Spezialisierung und intensive Beschäftigung damit, und meine Spinnereien, von denen ich hoffentlich einmal eine fertig umsetzen werde. Ideen habe ich mittlerweile soviel, dass mir der Hinterkopf zu eng wird. :wink:

    Ja, wenn das nicht mehr in den Thread passt, wäre eine Auslagerung vielleicht wirklich nicht schlecht. Da will ich dem Stil und der Auffassung der Admins hier nicht im Weg sein.

  • Was mich bei Commodore-Code _wirklich_ stürt ist der Effekt, daß jedes Flag ein ganzes Byte für sich beansprucht

    Das kann man ja weniger Commodore anlasten, als der 650x-CPU. Bit7/Negativ-Flag sowie Zero-Flag lassen sich nun mal am leichtesten auswerten/manipulieren.

    und daß jede Routine ihre temporären Variablen fest reserviert- aber selbstverständlich nirgends gescheit dokumentiert ist, wann die jeweils gebraucht werden.

    Ein richtig re-assembliertes KERNAL/BASIC gibt scheinbar wirklich nicht, oder? Mir ist zumindest noch keins untergekommen. Die bekannten ROM-Listings sind irgendwie auch nur recht rudimentär bzw. teils auch noch falsch, aber natürlich i. d. R. ausreichend brauchbar.

    Mein Ansatz wäre hierbei die Subroutinen so zu optimieren, daß weniger Fehlermeldungen auftreten.
    Viele Fehlermeldungen, die zum Programmabruch führen sind ja faktisch überflüssig.

    Die da wären? Wie auch immer: Jedes Abfangen 'dieser' Fehlermeldungen würde einen Rattenschwanz an weiteren Code nach sich ziehen und mindestens ein Fenster-System für die Meldung/Rückfrage erfordern: "FILE OPEN ERROR: CLOSE AND RETRY?"

    Dabei sehe ich den Bedarf vor allen an komfortableren Basic-Befehlen.
    Das kann dem Basic-Programmierer natürlich auch einiges an Code sparen.

    Für großartig mehr Befehle ist definitiv einfach kein Platz bei dem (vor)gegebenen Speicher. Ein paar (oft gewünschte) kleine Verbesserungen hätten/sollten aber irgendwie Platz gefunden haben: RESTORE X / IF-THE-ELSE und ein (kombinierter?) CLS- bzw. FILL-Befehl á la CLS (Screen) bzw. CLS 32768,8192,0 (Bitmap löschen). Die CLS-Routine ist ja leider so blöd gestrickt, dass man da nicht mit einem Wert reingrätschen kann (fest SPACE $20). Mit den Dingern wäre einem schon viel mit geholfen gewesen.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • habe in meinem VC 20 intern ROM Listing nachgeguckt ... zur Erläuterung, bzw. ich hab mir Gedanken gemacht wie die Routine aussehen müsste, damit man eben mit WErten <> $20 "reingrätschen" kann:

    Die Clear Screen Routine ist zumindest im VC 20, vermutlich auch im C64 zunaechst langatmig damit beschäftigt, den Beginn des Bildschirmspeichers zu berechnen, dann werden die Zeilenanfänge nacheinander abgeklappert und je Zeile gesondert ein "Fill" angestoßen; in der Zeilen-Fill-Routine erst wird der neue Farbram-Wert festgestellt und erst im Vorletzten Schritt der Akku mit dem FIll-Byte geladen. Mit LDA #$20 festverdrahtet.

    Das mit den Zeilenanfängen berechnen könnte getrost so bleiben.
    Das Füllbyte sollte aber nicht im vorletzten Schritt, sondern gleich beim Einstieg in die Routine
    mit LDA #$20 geladen werden und sofort per PHA auf den Stack gelegt werden.

    Eine Zusatzbedingung (vielleicht Carry-Flag gesetzt?) beim Aufruf könnte signalisieren, ob das Farbram geändert (geupdated) werden soll oder nicht. Falls ja, käme hier noch ein PHP.

    Den Rest könnte man vielleicht so umstellen:
    1. - Zuerst Videospeicher zeilenweise füllen
    2. - Optional auch Farb-RAM, nachdem die Zusatzbedingung ausgewertet wurde.

    Erst direkt vor Aufruf der Zeilen-Füllroutine könnte das Füllbyte reziprok mit PLA wieder vom Stack geholt werden. Falls der User /Programmierer etwas anderes als SPACE zum Füllen hernehmen will, ruft er einfach die Routine mit PC+2 auf und bringt das Füllbyte im Akku selber mit. - hoffe ich hab das verständlich beschrieben?

    Ebenso ggf. mit PLP die Zusatzbedingung ob Farbram mitbehandeln ja / nein.
    Falls man den Weg mit dem gesetzten Carry nicht gehen will, kann man vor Schritt 2 einfach ein CMP Akku, $20 einfügen. Dann wird bei SPACE automatisch die kompatible bisherige Behandlung aktiviert, bei anderen Füllbytes dagegen wird Schritt 2 übersprungen.

    Geschätzter Mehrbedarf an Bytes:

    minimum 2 Bytes !

    = 1 Pärchen PHA PLA

  • Keine bekannten, ausser einem Haufen von Parsern und Generatoren für berufliche Zwecke (so Sachen wie Grammatik-Transformatoren und Code-Generatoren und so Zeugs).

    O.K., klang für mich, als ob du schon mal eine komplett eigene (bekannte) Sprache aus dem Ärmel geschüttelt hättest ^^ . Wie weit diese Parser/Generatoren davon entfernt sind bzw. überhaupt vergleichbar sind, kann ich natürlich nicht beurteilen, ohne sie zu kennen. Dürfte aber schon eine andere Welt zu sein, als ein Kernal/Betriebssystem.

    Ansonsten nur entsprechende Spezialisierung und intensive Beschäftigung damit, und meine Spinnereien, von denen ich hoffentlich einmal eine fertig umsetzen werde. Ideen habe ich mittlerweile soviel, dass mir der Hinterkopf zu eng wird.

    Sofort aufhören, bevor es dir noch die Ömme sprengt =O:bgdev ! Mir kamen insbesondere deine Beiträge halt genau so vor, wie man z. B. in Spielprogrammierer-Foren oft liest: ICH habe die Mörder-Spiel-Idee und nun braucht es nur noch ein paar Programmierer, Musiker, Grafiker, die das umsetzen (schon oft geposteten Comic-Strip dazu denken). Nicht böse gemeint.

    Für mich sind diese ganzen wilden VM-Ideen halt nur wirres Wunschdenken (wo ich z. T. auch nur vielleicht die Hälfte verstanden hab'), ohne dass das wohl jemals einer umsetzen wird. Bei der Idee der Optimierung (siehe Beitrag Bitte melde dich an, um diesen Link zu sehen. von BladeRunner) von KERNAL/BASIC ging/geht es ja wohl eher/nur darum, an ein paar Schräubchen zu drehen/Code auszutauschen, wobei der Großteil an (BASIC-)Code aber noch lauffähig bliebe, aber schneller liefe bzw. vielleicht auch Platz für Erweiterungen/Code geschaffen würde, die von entsprechenden Programmen genutzt werden könnte. Das fände ich halt spannend.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Bei der Idee der Optimierung (siehe Beitrag Bitte melde dich an, um diesen Link zu sehen. von BladeRunner) von KERNAL/BASIC ging/geht es ja wohl eher/nur darum, an ein paar Schräubchen zu drehen/Code auszutauschen, wobei der Großteil an (BASIC-)Code aber noch lauffähig bliebe, aber schneller liefe bzw. vielleicht auch Platz für Erweiterungen/Code geschaffen würde, die von entsprechenden Programmen genutzt werden könnte. Das fände ich halt spannend.


    Ich hoffe mein o.g. Vorschlag die Schräubchen minimal zu Ändern in deinem Sinne (zur Änderung von CLS) geht in diese Richtung ...

  • Dürfte aber schon eine andere Welt zu sein, als ein Kernal/Betriebssystem.

    Definitiv, und ich wäre alleine dazu sicher nicht fähig, Kernal und Basic so anzupassen, wie es notwendig wäre.

    Nicht böse gemeint.


    Ich nehms nicht böse. Du hast völlig recht mit deiner Einschätzung. Ich denke, dass meine Gedanken dazu grundsätzlich nicht dumm und teilweise machbar wären, aber erstens haben sie mit dem ursprünglichen Thema nicht viel zu tun (die ganze Teildebatte ist einem lauten Nachdenken geschuldet), und zweitens fehlts natürlich am Proof of Concept. Es hat, das gebe ich zu, unglaublich Spaß gemacht, laut drüber nachzudenken, weshalb wir (die drüber spekuliert haben) es ja auch getan haben. Ich verspreche auch nicht, dass niemals was Konkretes draus entstehen kann. Das könnte sogar passieren. Der Mehrwert zur Beantwortung der Einstiegsfrage ist aber sicher eher mager. :wink:

  • Hexworx: Auch Du, mein Sohn Brutus?

    Kann ich jetzt nicht ganz einordnen, Mike :huh: . Ich fand halt genau deine Beiträge zum eigentlichen Thread absolut passend. Oder verstehe ich grad was falsch? Ich schätze deine Beiträge sowas von. :bia

    Das Füllbyte sollte aber nicht im vorletzten Schritt, sondern gleich beim Einstieg in die Routine

    Ich hoffe mein o.g. Vorschlag die Schräubchen minimal zu Ändern in deinem Sinne (zur Änderung von CLS) geht in diese Richtung ...

    Alles richtig! Die Routine wurde leider irgendwie völlig 'verkackt'. Kann ich nicht nachvollziehen, warum die Entwickler sowas nicht in Erwägung gezogen bzw. nicht geblickt haben. Es hätte ja schon ein schnödes LDA $ZP geholfen, um es halbwegs flexibel zu machen (und dann in Verbindung mit $288 und z. B. 8-fachen Aufruf). Wär besser als nix gewesen. Bestenfalls noch mit vier ZP-Adressen (Start/Ende). Nun ja...

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Wir sollten solche Dinge zusammentragen. Vielleicht kommen einem immer mehr Ideen, je mehr man sich damit beschäftigt.
    Am Ende haben wir 50 Unterroutinen "begradigt" und "vielseitiger gemacht" und um zusätzliche Funktionalität bereichert, ohne dass es mehr Platz braucht, und BASIC ist nicht mehr wiederzuerkennen wie es "rennt."

    Mike hatte ja mal eine Arithmetik-Verbesserung vorgestellt mit ähnlichem Aufwands/Ertragsverhältnis. Ich gebe zu das ist weiterhin sehr inspirierend..

  • Nun mischen sich leicht verschiedene Themen.

    "PCode, VM, Sweet16..."
    Also wenn sowas im Computer erstmal drin ist, dann will man da sicher auch als User mal dran...
    Aber eigentlich waren deren Anlass und Versprechen nur, schnellen und großen Maschinensprache-Code durch was kürzeres und langsameres zu ersetzen. Gewinn an Platz war gefragt, um die eigentliche Hochsprache zu optimieren, sei es für mehr Geschwindigkeit, mehr Struktur oder einfach geringeren Platzbedarf für komplexere Programme.

    Nun kann man sich natürlich überlegen, ob man in 16KB ROM nicht lieber Assembler, Compiler oder anderes unterbringen möchte, ob man den Modulbereich nicht auch noch hinzuziehen könnte oder gleich was vom PC cross übersetzen lassen könnte.
    Aber das ist dann eine Frage nach dem "was hätte CBM technisch aus dem C64 machen können", und Cross-PC-Sachen sind nicht mal das.
    Das ist dann keine Vergleichbarkeit mit Bill Gates mehr, was ja irgendwie doch der Kern der Ausgangsfrage war.

    Die Sprache sollte schon so Einsteiger-freundlich wie Basic sein, ähnlich nützlich sein, nach dem Einschalten incl. Editor da sein, keine externen Geräte brauchen und in 8KB (oder von mir aus auch 12 oder 16KB) passen. Halt, für was man Anfang der 80er Geld bezahlt hätte.

    Davon ab sehe ich da gewisse Ähnlichkeiten zwischen diesen Sprachen und Basic.
    Auf jeden Fall wird es einen simulierten ProgrammCounter geben, ein Lesen von Befehlsbytes, Aufruf von Spezialroutinen für diese Befehle, holen von Parametern (wohl auf gleiche Weise)...
    Warum ich Basic für langsam halte:
    -Konzept ohne Register, Befehle mit Parametern. Es ist doch wesentlich verständlicher, wenn es "Poke 53281,0" heißt und nicht an Stelle 1"R1=53281", an anderer Stelle 2 "Poke" und an Stelle 3 im Handbuch "Poke liest Register R2 und schreibt an Stelle R1".
    -Vieles kann erst zur Laufzeit bestimmt werden. Kleines ROM und kleines RAM dürften kaum was für richtige Compiler sein, und 20 Minuten bis zum Programmstart will auch keiner warten.
    -Erst danach kommen meiner Meinung nach Details der Implementierung und die Wahl des Befehlssatzes. Und wenn sich die VMs den oben genannten Bedingungen unterwerfen müssen, dann scheint mir deren Vorteil fraglich.

    "optimiertes Basic"
    -Ich erinnere mich noch schwach an den Speccy, an dem man damals im Kaufhof so schöne Grafikprogrämmchen eintippen konnte.
    Details sind natürlich vergessen, aber irgendwie hatte schon der Editor einen Überblick, ob grad Befehle, Parameter oder sonstwas gebraucht werden. Es war für den Anfänger auch sehr hilfreich, die möglichen Befehle auf der Tastatur lesen zu können. So ein Editor hat es vielleicht einfacher als ein richtiger Parser, Parameter zu erkennen und abzulegen. Zum nachträglichen Bearbeiten war der allerdings nicht so schön.

    -Steht ja nirgends geschrieben, dass die Ausgabe beim LIST den gleichen freien Text wie die Eingabe ergeben muss, Leerzeichen und unnötige Doppelpunkte dürfen weg. Die Intelligenz kann auf die Eingabe einer Zeile und den LIST-Befehl verlagert werden, im Quelltext würden nur noch geprüfte Parameter nach festem Schema gespeichert. Kann nicht soo viel Speicher fressen, im Speccy hat es auch gepasst.

    -Je nach übrigem Platz im ROM könnten auch verschiedene Varianten des gleichen Befehls mit verschiedenen Token abgelegt werden, z.B.
    FOR (Variablenname), (Formel), (Formel), (Formel)
    FOR (Variablenname), (Formel), (Formel)
    FOR (Variablenname), (Formel), (Konstante),
    IF (Formel), (Komparator), (Formel)
    IF (Variable), (Komparator), (Konstante)...
    ...in der Hoffnung, dass manche solcher Fälle deutlich schneller ohne Formelauswertung und Kopiererei von Inhalten abgearbeitet werden können...

    -Eigentlich fände ich ein Basic mit ein paar Registern gar nicht so schlecht, die dann dank fester Adresse schneller nutzbar sind. Neben POKE (Formel), (Formel) könnte es auch ein Poke RW,RB geben. Der Anfänger sieht ganz normale Variablen, der Fortgeschrittene sieht Word- und Byte-Register.

    -Hatte ich damals schon von der Idee gesprochen, Zeilen wie Stringvariablen zu behandeln und zusammen mit allen anderen Variablen zu speichern? Zeilen hätten die "gleichen" 5 Bytes Beschreibung + getrennten Inhalt.
    Heute werden Variablen komplett nach Namen durchsucht, weil sie unsortiert sind. Zeilen wegen der variablen Länge notgedrungen ebenso, immerhin kann früher abgebrochen werden.
    Heute gibt es ein sortiertes Einfügen von Zeilen, aber nur ein unsortiertes Hinzufügen von Variablen.
    Wenn eh alle gleichartig sind, dann könnte 1 Routine alles sortiert einfügen, Zeileninhalte könnten im Rahmen einer leicht modifizierten Garbage Collection zusammenhängend an den Programmstart geschoben werden. Das sollte genug Platz für eine binäre Suche bringen und nebenbei den Programmfluss vereinfachen.

  • Das mit den Zeilenanfängen berechnen könnte getrost so bleiben.

    Wozu? Hat es je eine echte Chance auf ein Gerät gegeben, dessen Bildschirmspeicher kein aufeinanderfolgendes Stück Speicher ist?
    Speicherbereiche mit irgendwas füllen muss es eh schon im ROM geben, um Arrays zu initialisieren.
    Adressen der Screenzeilen werden im Rahmen des Reset auch initialisiert, ich meine, bereits dort nach berechneter Anfangsadresse.
    CLR könnte so schnell und kurz sein...

  • Am Ende haben wir 50 Unterroutinen "begradigt" und "vielseitiger gemacht" und um zusätzliche Funktionalität bereichert, ohne dass es mehr Platz braucht, und BASIC ist nicht mehr wiederzuerkennen wie es "rennt."

    Zum 'Rennen' wird man es aber trotz alledem wohl leider eh nicht bekommen. Aber diese Fill-/Lösch-Funktion wäre eine schöne Sache gewesen, um in BASIC den Bitmap-Mode überhaupt halbwegs brauch-/nutzbar zu machen, ohne eine gähnend lange dauernde Lösch-Orgie vorweg.

    Es wird aber insgesamt aber wohl nicht viel rauszuholen sein aus dem KERNAL/BASIC. Es ist halt doch schon ziemlich durchdacht (Speicherbedarf vs. Geschwindigkeit). Ich/wir können uns wohl kaum anmaßen, die beiden als Mist zu degradieren, ohne was komplett neues/besseres zu liefern. Und das wird schwer möglich. An den paar Schräubchen/vielleicht 1% vom Code seh ich das vielleicht auch, aber viel mehr ist wohl auch nicht drin. Das muss man den Entwicklern einfach lassen.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?