Optimierungsgrad KERNAL /BASIC - fiktiver Talk

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

  • Vielleicht könnte man diesen Thread mal wieder in diese Richtung zurückbringen. (Ungenutzte) BASIC-Erweiterungen gibt es ja nun zuhauf. Da muss nicht noch eine her. Das Thema dürfte auch ziemlich ausgereizt sein; aber das Standard-BASIC besser machen, fände ich schwer interessant 8o .

    Ich denke man sollte das Thema aus zwei Richtungen betrachten:

    Der 1. Aspekt ist die Frage was man aus den 8/16kB noch hätte herausholen können.
    Der 2. Aspekt die Frage was könnte man bei möglichst vollständiger Kompatiblität verbessern oder fixen.

    Ich persönlich denke das die erste "Aufgabe" eher akademischer Natur ist.
    Sind wir doch mal ehrlich: Wer würde sich das einbauen? Wer würde dafür entwickeln? So gut wie niemand...
    Die Profis arbeiten mit ASM und was nützt mir ein Basic Programm, das nur ich laufen lassen kann?
    Vor 33 Jahren wäre das evtl. noch interessant gewesen. Aber im Jahr 2016 ist es reiner Denksport sowas zu machen.

    Das zweite fänd' ich - wie Hexworks - schon wesentlich interessanter:

    Einen verbesserten (fehlerbereinigten) Kernal, der möglichst kompatibel ist.

    Sowas würde ich mir z.B. auch einbauen "just for the sake of having it" - ohne das ich es wirklich brauche. Einfach
    aus dem Gefühl heraus, das mein CeVi nun ein Stück "perfekter" ist.

    Just my 2 cents!

  • JeeK:

    Du schriebst "was man herausholen kann...BBC Basic". Da ist leider ein wenig der Wurm drin,
    soweit ich lesen konnte, hatten die BBC Micro-Rechner alle mindestens 32 KB ROM.

    Da würden also Äpfel mit Birnen verglichen.

    Im vorliegenden Fall ist es wirklich witzlos, das Basic V2 das incl . Kernal mit 16 KB auskommen musste, mit einem Rechner zu vergleichen der doppelt soviel zur Verfügung hatte.

    Bitte relative Vergleiche nur mit Rechnern vornehmen, die gleiche ROM-Größe haben. Der sportliche Gedanke den du formulierst, wird von mir geteilt - aber bitte ohne Gatter-Doping ;) oder ROM-Bloating ... ;)

    Das war auch nicht als Vergleich in diesem Sinne gedacht. Das Schlachtermesser kann man bitte gleich wieder stecken lassen. :D
    Mir ist schon klar, dass das BBC-Basic 32K ROM hat, wobei da nicht nur mehr BASIC, sondern auch mehr (echtes) Betriebssystem drinnen ist. Und ROM-Größe alleine garantiert noch lange nicht, dass das es zwingend effizienter sein muss. Von "umfangreicher" kann man wohl ausgehen ... wie man beim C128 sieht. Aber um das ging's nicht, sondern, dass bei einem von Null-weg-Ansatz, ganz etwas anderes heraus kommt. Da sind sozusagen keinerlei Anleihen beim CBM-Basic genommen worden (bezüglich Interna). Oder anders gesagt, das Abändern an der bestehenden Codebasis wird vermutlich nicht so viel Potenzial bieten, wie eine kompletter Neuansatz. Was aber jetzt nicht bewerten soll, was besser, praktikabler oder realistischer ist (um den Antwortzerfetzern ein bisschen den Wind aus den Segeln zu nehmen). ;)

  • oh pardon, ich wollte natürlich nicht zerfetzen, wäre ja schade :)
    In der Sache stimmen wir ja wohl überein - und zum von-Grund-auf-Neu-Ansatz sich durchringen ist natürlich mehr (konzeptionelle ) Arbeit...

  • Ich bewundere den ganzen Thread! Er ist faszinierend, und das nicht nur von dem profundem Detail-Wissen, dass einige zeigen, sondern von der ganzen Thematik her.

    Ich möchte ein paar Gedanken beitragen, die ich seit vielen Jahren sporadisch gehabt habe, auch wenn die zunächst ein wenig am Thema vorbeigehen:

    Ich habe mir irgendwann einmal überlegt, was man überhaupt aus dem C64 mit der HW herausholen kann. Dabei ist es mir nicht so sehr um die Optimierung des Kernal gegangen, denn um den zu begreifen, fehlt mir ein wenig die Geduld, den Code tatsächlich zu analysieren, und noch mehr das elektrotechnische Wissen. In beidem gibt es viel Berufenere und Bessere als mich.

    Ich habe mich damals gefragt: Wie könnte man den Sprung in eine viel schönere Programmier-Welt schaffen?

    Das Kernproblem habe ich im Betriebssystem und im Basic-Interpreter gesehen, und zwar insofern, als die fast die gesamte Zero-Page vollkleistern, um funktionieren zu können. Ich habe nicht ganz verstanden, wieso das so sein muss. Immerhin: Der Kernal verwaltet die HW, die IO-Systeme, etc., wenn man also diverse Variablen - ob Kassettenpuffer, Bildschirmverwaltung, etc. - von der ZP raus holt, und in einem "harmloseren" Speicherbereich ganz oben irgendwo unterbringt, könnte das Grundsystem etwas langsamer werden.

    Andererseits geht es uns doch um die weitaus bequemere Programmierung, und die könnte viel angenehmer werden, und viel mehr erlauben, wenn man die ZP systematisch nutzen könnte (mit Ausnahme natürlich von Byte 0 - und auch 1? - also dem Memory Mapping).

    Meine (naive) Vorstellung: Der 6510 ist ja nicht gerade der tollst ausgestattete Prozessor. Ohne die ZP ist man mit dem schnell am Ende mit den Möglichkeiten, will man nicht wirklich elends langen Code und die entsprechend längeren Zugriffszeiten in Kauf nehmen.

    Also wäre es verlockend, einen weitaus komfortableren Prozesser mithilfe der ZP virtuell nachzubilden. Dazu gehört: Ein paar Register, mindestens 16 bit, wenn man so frei sein will, kann man da auch höher gehen. FP-Register gibt es sowieso schon in Form der FP-Akkus. Ein Stack, der nicht gnadenhalber ein paar Bytes für das gesamte System an einer fixen Stelle hergibt, sondern einen echten Stack-Pointer, den man pro Kontext austauschen kann, mit Stacks, die viel größer werden können. Vielleicht ein erweitertes Status-Register. So wäre auch Multi-Threading eine echte Option.Und so weiter und so fort. Mit so einer Grund-Architektur hätte man SW-mässig bereits viel breitere Möglichkeiten.

    Kommen wir zum Code. Den könnte man ähnlich kompakt anlegen, wie z.B. FORTH das tut (nur ein Beispiel, ich wollte keine UPN voraussetzen, da sollte es kein Denkverbot geben!), oder wie einen entsprechen komfortableren Maschinen-Code. Der Interpreter sollte nicht all zu groß sein und irgendwo im ROM-Bereich liegen. Es wäre wesentlich kompakterer Code möglich, sowie auch "kanonisierte" Möglichkeiten der Interrupt-Programmierung etc., und das würde für die meisten Fälle einiges an Code-Länge einsparen. Bei größeren Anwendungen könnte so eine Darstellung um einen guten Teil kürzer werden als reiner Assembler. Trotzdem wäre sie, wählt man die Sprache sensibel, nicht all zu viel langsamer (gefühlsmässig einen einstelligen Faktor langamer?). Das wäre sehr sinnvoll, denn der meiste Geschwindigkeitsverlust entsteht durch den BASIC-Interpreter. Eine Zwischen-Sprache die erheblich komfortabler ist als Assembler, aber trotzdem viel schneller als BASIC, noch dazu kürzeren Code bedeutet, wäre langfristig ein enormer Gewinn.

    Auf die Weise könnte man nämlich auch Teile des Betriebssystems und des Interpreters (wie auch immer der aussieht) in dieser Zwischensprache schreiben, und so einiges an Platz sparen. Die zeitkritischen Teile wären immer noch in Assembler machbar. Vor allem wäre jede Hochsprache viel einfacher compilierbar, so auch BASIC.

    Wenn man das macht, kommt man der Idee z.B. einfacher C-, Pascal-, Java-, oder Python-Versionen auf dieser Plattform schon sehr viel näher (drei davon gibts auch so schon :freude ), noch dazu auf einer gemeinsamen virtuellen Maschine. Es wäre sowas wie das ".net für Arme". Übrigens habe ich nie verstanden, wieso die HC-Designer nicht gleich FORTH eingebaut haben statt Basic, das wesentich schneller und kompakter läuft, und im Endeffekt auch nicht schwerer zu lernen (dann hätten halt alle FORTH statt Basic als erste Sprache gelernt).


    Aber hier gings eigentlich um die Frage, ob man das vorhandene BASIC so realisieren könnte. Ich denke ja. Das ginge ebenso ein wenig kompakter und schneller, eben auch über einen derartigen Zwischencode besser compilierbar. "Einzig" die POKEs und SYSse wären damit natürlich im Eimer, ausser, jemand tut sich die Arbeit an, die semantisch zu übersetzen. Aber das ist erstens nur teilweise möglich, und zweitens auch dann schon recht komplex, und wäre eher was für cross-Übersetzer auf leistungsfähigeren Plattformen. Die Sprache an sich wäre leicht zu realisieren, wenn auch die wenigsten Programme je NUR die Sprach-Features genutzt haben.

    Zusammenfassend: Zwischencode - kompakter - langsamer als Assembler - viel schneller als BASIC - Teile des OS in VM - benutzerfreundlicher, mehrere Sprachen können auf derselben VM interagieren, Multi-Threading und Virtual Memory leichter möglich, SW erheblich leichter zu entwickeln, Libraries ließen sich so viel einfacher kombinieren .. Vorteile sollten eigentlich überwiegen, BASIC V2 wäre so möglich, Kompatibilität im Eimer.

    Gut, das wäre im Grunde bis auf die HW eine ganz neue Maschine, aber vielleicht könnte es im Sinne des Eingangs-Statements so klappen?

    Disclaimer: Könnten gut mehrere Denkfehler drin sein (einen Proof of Concept gibts ja nicht), und ich würde mich über deren Aufklärung echt freuen, um draus zu lernen! :picard:

  • Was Du beschreibst, gab es mehr oder weniger in zweierlei Form auf dem AppleII.
    Zum einen enthielt das ursprüngliche ROM einen SWEET16-Interpreter, der eine 16-Bit-Maschine emulierte, welche u. a. beim damaligen eingebauten Integer-Basic eingesetzt wurde. Zum anderen gab es natürlich UCSD-Pascal, welches mit Ausnahme des Multithreading in etwa das leistete, was Du beschreibst: eine virtuelle Maschine, die auch von anderen Sprachen genutzt wurde (in diesem Fall Fortran). Ein Bytecodeinterpreter emuliert hierbei eine 16-Bit-Stackmaschine (Datenstack und Evaluationsstack werden getrennt), wobei die Größe des Datenstacks der des gesamten ungenutzten Speichers entspricht. Dazu ein System, welches größtenteils auf eben dieser virtuellen Maschine basierte (, dessen Einzelteile wie Editor und Compiler allerdings so groß waren, daß sie von Diskette nachgeladen werden mußten). Hat prinzipiell gut funktioniert, wenn auch aufgrund des Bytecodeinterpreters ein wenig langsam. Es gab sogar ein Spiel ("Wizardry"), das für dieses System geschrieben wurde. Als es auf den C64 portiert wurde, mußte dann jemand aus Lizenzgründen den ganzen Interpreter extra nachprogrammieren, denn leider gab es keine offizielle Portierung des Gesamtsystems, obwohl dies technisch sicherlich möglich gewesen wäre.
    Über die Gründe, warum es damals nicht portiert wurde, kann man nur spekulieren. Vielleicht sah man darin keine Marktchancen. Oder man schreckte vor dem entsetzlich langsamen 1541-Laufwerk zurück, das das Arbeiten mit dem System ohne Beschleuniger zur Qual gemacht hätte. (Der AppleII liest einen Track mit 16 Sektoren in einer Umdrehung,) Wichtig bei diesem System war, daß stark getrennt wurde zwischen Grundsystem, Treiber für externe Geräte und "Applikationen". Das Grundsystem belegte die 16KB-Speichererweiterung (sogenannte Language Card) sowie ein paar KB des Hauptspeichers. Die Treiber für Sondergeräte (80-Zeichenkarte, Drucker, Maus, Festplatte) wurden von deren Herstellern auf speziellen Slotroms mitgeliefert und waren nicht Teil des Systems, wohl die Erkennung und teilweise Handhabung. Editor, Compiler oder Dateibrowser (genannt "Filer") lagen jeweils als umfangreiche, eigenständige Programme vor, die niemals in ein Standard-ROM gepaßt hätten. Ein (schnelles) Diskettenlaufwerk war hierfür also zwingend Voraussetzung.
    All dies lieferte der C64 nicht. Grundidee des C64 war: "Einschalten. Loslegen." und das ohne großen Aufwand, sprich teure Zusatzhardware. Das System des C64 mußte in der Lage sein, allein mit einem Kassettenlaufwerk zusammenzuarbeiten. Das stellte die Designer vor ganz andere Aufgaben: Wie quetsche ich ein Grundsystem mitsamt Basicinterpreter und Zeileneditor in 16KB? Denn ein Nachladen war nicht möglich. Von den Routinen, die vor diesem Hintergrund in den Kernal und das Basicrom wanderten, eignet sich allerdings nur der Zeileneditor eventuell dafür, mit einem Pendant auf einer virtuellen Maschine ersetzt zu werden. Die anderen Routinen im Kernal sind zumeist äußerst zeitkritisch, entweder weil sie genaue zeitliche Vorgaben haben (Protokolle für die Kommunikation mit Datasette oder angeschlossenem Laufwerk) oder sehr schnell abgewickelt werden müssen (Interrupt, Bildschirmausgabe). Richtig einsparen kann man im Kernal nur, wenn man bestimmte Teile wegläßt (keine Datasetten-Routinen mehr o. ä.) Man kann davon ausgehen, daß ein Bytecodeinterpreter, der auch andere Sprachen als Forth unterstützen soll (z. B. Pascal), um die 3KB Speicher benötigt. Soviel Speicher müßte man also erst einmal einsparen, um Platz zu erhalten für den Interpreter. Das dürfte schwierig werden.
    Was zuletzt das Vollkleistern der Zeropage anbelangt, so gibt es dafür eine bewährte Methode: Auf RAM / IO / RAM schalten, eigene Routinen zum Tastaturlesen etc verwenden und den Kernal komplett ignorieren. Das einzige Einsatzgebiet, das ich mir noch für den Kernal vorstellen kann, wäre die Kommunikation mit einem Drucker über den seriellen Anschluß. (Theoretisch könnte man auch dies selber nachbilden, aber dazu wäre ich zu faul.) Wenn man in Assembler programmiert, kann man ansonsten auf den Kernal gut verzichten.

  • Immerhin: Der Kernal verwaltet die HW, die IO-Systeme, etc., wenn man also diverse Variablen - ob Kassettenpuffer, Bildschirmverwaltung, etc. - von der ZP raus holt, und in einem "harmloseren" Speicherbereich ganz oben irgendwo unterbringt, könnte das Grundsystem etwas langsamer werden.

    Es würde nicht nur etwas langsamer werden, es würde überhaupt nicht mehr funktionieren. Indirekte Adressierung funktioniert nur mit der Zeropage und ohne die kann Code im ROM nicht mehr vernünftig auf variable Speicheradressen zugreifen, z.B. um Programme zu laden oder Ausgaben in den Bildschirmspeicher zu schreiben.

    Zitat

    Also wäre es verlockend, einen weitaus komfortableren Prozesser mithilfe der ZP virtuell nachzubilden. Dazu gehört: Ein paar Register, mindestens 16 bit

    Bitte melde dich an, um diesen Link zu sehen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.

  • Danke für eure schnellen Reaktionen. Zumindest habe ich damit die Bestätigung, dass meine Gedanken nicht total absurd gewesen sind. :wink:

    Danke auch für den Hinweis auf Sweet16, und M.J. für die lange Erklärung, das kannte ich so noch nicht.

    Es würde nicht nur etwas langsamer werden, es würde überhaupt nicht mehr funktionieren. Indirekte Adressierung funktioniert nur mit der Zeropage und ohne die kann Code im ROM nicht mehr vernünftig auf variable Speicheradressen zugreifen, z.B. um Programme zu laden oder Ausgaben in den Bildschirmspeicher zu schreiben. Bitte melde dich an, um diesen Link zu sehen.

    Es wäre theoretisch trotzdem machbar, wenn man sie stets davor in die ZP reinschreibt und dann die ursprünglichen Daten wiederherstellt. Allerdings wäre das nicht "ein bisschen" langsamer, sondern gleich um einen ziemlichen Faktor. Insgesamt dürfte sich also abzeichnen, dass so eine Strategie sich vermutlich nicht wirklich auszahlen würde, ausser man macht erhebliche Abstriche.

  • Es wäre theoretisch trotzdem machbar, wenn man sie stets davor in die ZP reinschreibt und dann die ursprünglichen Daten wiederherstellt. Allerdings wäre das nicht "ein bisschen" langsamer, sondern gleich um einen ziemlichen Faktor. Insgesamt dürfte sich also abzeichnen, dass so eine Strategie sich vermutlich nicht wirklich auszahlen würde, ausser man macht erhebliche Abstriche.

    Und man würde einen 2-Byte-Befehl auf mindestens 22 Byte aufpusten

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.

  • Mit Verlaub,es ging hier (eher ) nicht um "Alles-oder-Nichts-Lösungen" bezüglich Zeropage.
    Man könnte darüber nachdenken, den Platzbedarf des Betriebssystems (Kernal) in der ZP einzudämmen, z.b. auf die ersten 128 Bytes. Der Rest kann in die erweiterte Zeropage.

    Gerade die seriellen IEC-Routinen sind NICHT zeitkritisch, abgeshen von dem 1ms-Reaktionszwang am Ende eines Bytes zur Bestätigung. (Data valid - End of byte - EOI). Vielmehr ist der 6502-Prozessor der 1540/41 Floppy zu schnell, sodass wegen des C64 mit seinen Bad scanlines zusätzliche Zeitschleifen zum Verbraten von Rechenzeit eingebaut werden mussten ;)

    Somit sind die IEC-Routinen geradezu prädestiniert dazu , von einem Interpreter (Bytecode? Sweet16?) platzsparend abgehandelt zu werden.

    Auch Tastaturabfrage und das Abklappern der Zeilen und Spalten ist so zeitkritisch nicht, denn es wird nur 50 bzw. 60 mal pro Sekunde durchgeführt. Hier sind sogar besonders elaborierte Techniken zum Zeit- und Platzsparen denkbar (doppelter Interrupt, Strecken der Intervalle auf 18 mal pro Sekunde wie beim PC u.v.m.)

    Bleibt fast nur die Datasette und der serielle Anschluß. Da beides Seriell ist, kann zumindest der Schreibstrom ( die Senderoutinen) zusammengelegt werden, da der C64 der Controller über das Timing ist. Auch dies eignet sich für eine Abarbeitung durch die virtuelle Maschine /Sweet16.

    Lediglich beim Datasette-Lesen und evtl. beim RS232 Empfang braucht man vermutlich "echte" 6502-Programmierung. Aber das ließe sich vielleicht auf die innersten Routinen beschränken.


  • Gut, das macht schon wieder Hoffnung. Also hätte man ev. schon einen gehörigen Fleck der ZP für eine virtuellen Prozessor zur Verfügung, etliches an OP-Routinen in verkürztem VM-Code (dafür müsste man natürlich sorgen, dass der wirklich kompakt ist!), und so wäre das ganze in einem ROM denkbar.

    Es wäre doch wirklich geil, wenn das Betriebssystem auf die Weise Threads switchen könnte! :woot:

    Zusatzbemerkung: Ich würde sogar vorschlagen, einen zweiten - high level - Mechanismus für die Threads einzuführen (der eben nur auf dem VM-Level werkt), der von den harten Interrupt-Routinen unabhängig bleibt und von diesen einfach unterbrochen wird. Allerdings hätte das den Nachteil, dass man damit die HW nicht mehr so gut ansprechen kann. Also bräuchte man zwei Mechanismen. Aber es wäre sauberer.

    Hier könnte meine Signatur stehen, wenn ich eine hätte.

    2 Mal editiert, zuletzt von BlondMammuth (21. Mai 2017 um 15:05)

  • den Platzbedarf des Betriebssystems (Kernal) in der ZP einzudämmen, z.b. auf die ersten 128 Bytes

    Das Kernal ist auf $801 bis $ff beschränkt, warum also verschieben? Ursprünglich war $f0 aufwärts für den User frei, das wurde dann ab dem VC20 für die RS232 benutzt.

    Was mich bei Commodore-Code _wirklich_ stürt ist der Effekt, daß jedes Flag ein ganzes Byte für sich beansprucht, und daß jede Routine ihre temporären Variablen fest reserviert- aber selbstverständlich nirgends gescheit dokumentiert ist, wann die jeweils gebraucht werden. Das hat Sinclair zum Beispiel sehr viel eleganter gelöst- und es liegt nur zu einem geringen Teil am anderen Prozessor.

    Daß der IEC-Bus nicht zeitkritisch sei halte ich für ein Gerücht- der Talker gibt auch den Takt vor, und wenn der Listener nicht mitkommt ist Schicht im Schacht. Das ist aber kein Problem, die Routinen schalten sowieso alles ab und haben den Rechner für sich allein- sie könnten also ihre temporären Register nach Gebrauch wieder freigeben.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Das Basic zu optimieren ist natürlich grundsätzlich möglich.
    Dabei sehe ich den Bedarf vor allen an komfortableren Basic-Befehlen.
    Das kann dem Basic-Programmierer natürlich auch einiges an Code sparen.

    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.

    ....

  • Wer mit der Betriebssystem-Optimierung anfangen will, der braucht nur das Basic/Char/Kernal-Rom ins Ram kopieren und schon kann man mit dem Poke-Befehl alles ändern.

    Quellcode:

    • 150 :rem--rom/ram,bild:52224,satz:53248
    • 151 poke56334,0:poke1,51:fori=88to91:pokei,0:next:poke781,97:poke782,.:sys41971
    • 152 :poke53248+32*8+6,16:rem--zeichen-demo
    • 153 poke1,53:poke56334,1:poke648,204:sys58692:poke53272,52:poke56576,196:return

    ....

  • Was mich bei Commodore-Code _wirklich_ st[ö]rt ist [...] daß jede Routine ihre temporären Variablen fest reserviert- aber selbstverständlich nirgends gescheit dokumentiert ist, wann die jeweils gebraucht werden.

    In der ZP sind z.B. recht viele Bytes in der Anwendung geteilt zwischen Tape und RS232. Neben den 'übllichen Verdächtigen' $FB..$FE sind das im Regelfall eben die Bytes die ich hernehme.

    Ob gerade Tape oder RS232 genutzt werden, kann man ja gut abschätzen. Und eben weil es schon zwei Nutzer gibt, müssen diese selbst davon ausgehen, daß sie erstmal die ZP Bytes mit sinnvollen Werten vorbelegen müssen, bevor sie loslegen.

    Heißt: solange weder Tape noch RS232 aktiv sind, kann man diese Bytes nutzen. Man muß sie vorher nicht retten und nachher auch nicht wiederherstellen. Nur muß man sich im klaren sein, daß die eigenen Werte weg sind, wenn man 'zwischendurch' dann Tape oder RS232 nutzt.

    $03..$06 sind noch vier weitere nützliche Kandidaten. Da stehen zwar zwei Vektoren drin (FAC <-> Integer Umwandlung), nur: keine Routine im Interpreter nutzt diese Vektoren und mir ist auch kein Programm bekannt, das tatsächlich diese Vektoren nutzt und nicht direkt die Routinen anspringt, sprich: diese 4 Bytes sind ebenfalls vogelfrei.

    Beim C64 ist bekanntermaßen dann noch $02 frei, beim VC-20 steht da das High-Byte vom USR()-Sprungbefehl drin und darum nehm' ich das Byte eher selten her.

  • Ob man den C64 durch Poke´s beschleunigen kann?
    Selbstverständlich reicht machmal nur 1 Poke um den C64 zu beschleunigen.

    Beispiel ist z.B., soweit ich mich erinnere, der ASC-Befehl.
    Hier kann man mit nur einem Poke die Fehlermeldung bei Leerstrings ausschalten.

    Das heißt, das man die aufwendige Stringaddition bei Asc sparen kann.
    normal : a=asc(a$+chr$(0))
    geändert : a=asc(a$)

    Das bringt dann natürlich auch schon was an Geschwindigkeit.

    ....

  • Schade. Der Thread war eigentlich ganz gut zu lesen. Jetzt nicht mehr. ;(

    Dann machen wir ihn wieder schön: Aus meiner Sicht sind Pokes, die irgendwas beschleunigen, sicher interessante Beispiele für das, was im Einzelfall bewirkt werden könnte, allerdings wäre mir mehr an systematischen Lösungen gelegen, die keine lebenslange Erfahrung mit den C64-Interna voraussetzen, sondern auch für gelegentliche Programmierer (und User) deutliche Verbesserungen bringen.

    Ich könnte mir z.B. vorstellen, die virtuelle Maschine in Grundzügen zu spezifizieren, und einen cross-Compiler dafür zu schreiben, sobald sie vorhanden ist (mit dem man dann vielleicht sogar via Bootstrapping einen on-board-Compiler implementieren könnte). Ich würde mir nicht zutrauen, sie in allen Details zu spezifizieren oder gar zu implementieren, insbesondere was die Interaktionen mit dem Kernal und der HW betrifft, und schon gar nicht, den Kernal selbst neu zu stricken. Dazu verstehe ich viel zu wenig von den Untiefen des C64. Aber wie man Programmiersprachen designt und implementiert, davon verstehe ich schon mehr.

    Hier könnte meine Signatur stehen, wenn ich eine hätte.

    Einmal editiert, zuletzt von BlondMammuth (21. Mai 2017 um 18:28)