Beiträge von atomcode

    Und an dem Beispiel kann man dann auch schön sehen, dass es auch von den konkreten Daten abhängt

    Genau, und bei solchen Dingen wie mit den zu erwartenden Daten muss man beim Programmieren auf jeden Fall selbst mitdenken. Wenn ich z.B. weiß, dass die Daten gar nicht größer als 39 werden können, frage ich das auch nicht ab. Ich denke aber, dass das in der Regel nur der Autor wissen kann. Empirische Daten, und wenn sie auch 1000-mal hintereinander unter 40 liegen, sind keine Sicherheit. Und einer KI würde ich diese Entscheidung, ob ich "< 40" abfragen muss, auch nicht überlassen.


    Diese Überlegungen sind primär das, was ich mit "algorithmischer Optimierung" meinte. Vielleicht sollte man dabei eher von "semantischer Optimierung" sprechen. Es war ja nicht unbedingt gemeint, dass man erst einen komplett neuen Floodfill-Algorithmus oder ähnlich erfindet.

    Ist das nur beim VIC so, oder gibt es diesen Effekt bei den anderen Chips auch?

    • Da nur die Adressleitungen A0-A4 am SID anliegen, wiederholen sich die SID-Register alle 32 Byte (hexadezimal $20) im verbleibenden Adressbereich $D420-$D7FF.
    • Mit Hilfe der Adressleitungen A5-A9 kann dieser verbleibende Bereich für Erweiterungen genutzt werden. Beliebte Adressen für einen zweiten SID sind z.B. $D420 oder $D500.

    Also VIC = $D000 bis $D3FF (16 * 2^6 Byte), SID = $D400 bis $D7FF (32 * 2^5 Byte), dann Farb-RAM ab $D800.

    Gerade den Schlauch für die SpüMa aus der Packstation geholt. Werde ich jetzt noch einbauen.

    Hier noch ein paar Bilder.



    Die Kabelschuhe auf den Stecker zu bekommen, war das schwierigste. Das Kunststoffunterteil der Maschine ist aus einem Guss und lässt sich nicht weiter öffnen, keine Serviceklappen auf der Unterseite, und die Kabel sind so kurz, dass man sie nicht weiter herausziehen kann. Ein paar cm mehr hätte es erleichtert. Die Pumpe sitzt irgendwo mittendrin. Keine Chance, die auszutauschen, wenn die hin wäre. Man merkt es immer wieder: Es soll gar nicht repariert werden.


    So, Blech drauf, noch mal laufen lassen, putzen, Ebay.


    Die neue Maschine lebt übrigens fast von Luft und Liebe. 0,55 kWh pro Eco-Durchgang waren angegeben; gemessen hab ich unglaubliche 0,43 kWh. Randvoll, Töpfe und Glas gleichzeitig, alles nach 2 Std. picobello sauber.

    TD1334 und berni Kann man Eure Geschwindigkeitsmesser irgendwo bekommen? Womöglich mit Quellcode? Wollte so was selbst mal machen, für den Kassettenpuffer, SYS X für Start und SYS Y für Stopp, und mit einem Parameter, der angibt, ob dabei Interrupt und/oder VIC abgeschaltet werden sollen. Ich weiß ja nicht, wie Ihr das gemacht habt.

    Hab gerade bei meiner alten defekten Spülmaschine den Aquastop mal durch eine Lampe ersetzt:


    Einschalten, Abpumpen von vorherigem Wasser, danach leuchtet die Lampe => Aquastop karpott.


    Die größere und teurere Maschine meiner Mutter hatte nach nicht mal zwei Jahren genau das gleiche Problem, innerhalb der Garantiezeit. Leider wurde sie in dem Zustand zum Wertstoffhof gebracht. 500 € in den Sand gesetzt, plus unnötige Müllerzeugung. :(


    So, also werde ich jetzt versuchen, den Aquastop mit einer Säge zu öffnen und schauen, ob das reparabel ist. Ich befürchte eher, nicht. In dem Fall werde ich recherchieren, ob ich was günstig als Ersatz bekomme. Kabel kann man löten, und für den Schlauch gibt es Verbinder.


    Warum macht man den Zulaufschlauch samt Aquastop nicht austauschbar an einen 3/4''-Stutzen mit gut isoliertem zweipoligem Elektroanschluss? Das ist alles von der Maschine bis zum Ende in einem Guss, nichts zum Austauschen. Man kann doch nicht eine komplette, im Prinzip einwandfrei funktionierende Maschine wegwerfen, nur weil am Schlauchende so ein dämlicher Schalter nicht tut.


    Zu meiner neuen Maschine wurde auf der Homepage des Herstellers extra betont, dass der Aquastop dieser Maschine nun angeblich bis zum Ende ihrer Lebenszeit halten würde. Ach, guck mal da, warum hebt man das plötzlich so hervor? Womöglich, weil sich die Reklamationen und Beschwerden häuften?

    Ich kann mich nur noch an das End-Bild erinnern.


    Was aber die Guillotine auf dem Bildschirm zu suchen hat, weiss ich nicht.

    Sieht mir eher nach einem Strafblock aus, auch als Pranger bekannt. Das rote ist sicherlich nur Rost. :whistling:


    Impliziert bei mir eine Art Story, welche die Level unbewusst begleitet? Und der Bösewicht ist am Schluss nun einen Kopf kürzer geworden?

    Die Hintergrundstory war leider etwas oberflächlich, sodass ich nicht mal schlau daraus wurde, womit man es genau zu tun hatte:


    • Eine außerirdische Rasse namens Skryksis hat den Planeten Xamox überfallen und ihn mit Strahlung verseucht. // Anm.: Ok, kann man mal machen.

    • Hawkeye ist ein Cyborg, geschaffen, um die Skryksis zu bekämpfen. // Anm.: Ok, obwohl bei Strahlung ausschließlich synthetisch sicherlich besser wäre.


    Soweit ergibt das noch halbwegs Sinn, und man könnte vermuten, dass die Skryksis die Xamoxianer (Humanoide? Menschen? Man weiß es nicht) auch gefoltert hatten, und das Foltergerät ein Hinweis auf dieses vorherige Martyrium sein soll.


    • Hawkeye soll durch die streng bewachten Strahlungszonen navigieren und Puzzleteile sammeln, um den Planeten zu säubern.


    Tja, und da hat man dann wirklich Fragen ...


    - Wo genau waren jetzt die Skryksis, die bekämpft werden sollten?

    - Wo sind die Xamoxianer? Alle umgebracht und keiner mehr über?

    - Und darum erschießt er jetzt einfach mal Hunde und Gorillas?

    - Er sammelt Puzzleteile, um den Planeten zu säubern? Hä?


    Ich könnte an der Story noch was retten, indem ich annehme, dass die Skryksis Formwandler sind. So wüsste man, wo sie geblieben sind und gleichzeitig, woher die Kreaturen kommen. Dann weiß ich aber immer noch nicht, wofür die Puzzleteile benötigt werden. Ja gut, um nach vier Stück ins nächste Level zu kommen, schon klar, aber leider hat das absolut keinen Bezug zur Story. Man hätte sich irgendwas à la Infinity-Steine oder so ausdenken können. Ich mag es nämlich, wenn alles erklärt wird und schlüssig ist, und sei es noch so an den Haaren herbeigezogen.


    Wenn Ihr dann hier so weit fertig seid, werde ich noch gern erzählen, inwiefern das Spiel für mich daaamals eine ganz große Bedeutung hatte, gewissermaßen sogar nachhaltig bis heute.

    Und mein Eindruck ist, dass hier etliche, die z.B. Spiele in BASIC programmieren, so ähnlich vorgehen. Einfach mal drauf los und schauen, wo die Reise hingeht.

    Nicht immer, aber oft.


    Manchmal ist es auch so ein Zwischending. Also weniger "drauflos programmieren" als "drauflos tüfteln/entwickeln", und eben gern in BASIC. In Assembler könnte ich das nicht so gut.

    Dabei liegt dann bezüglich Algorithmus nur eine grobe Vorstellung vor, aber nichts Genaues. Das Genaue ergibt sich dann so nach und nach erst beim Programmieren, zumal die Theorie oftmals noch Dinge übersieht, auf die man erst später stößt. So war es auch immer bei so kleinen Wettbewerben, z.B. das blaue Kreuz.


    Aber manchmal ist es bei mir auch fürs BASIC-Programm tatsächlich so, wie Snoopy sagt, dass man sich erst mal einen grundsätzlichen Algorithmus überlegen muss. Bei dem von mir erwähnten Pico8-Spiel, von dem ich im Moment nicht sagen will, welches ich meine, weil dann eine riesige Diskussion darum beginnt, werde ich tatsächlich auch erst ganz theoretisch und trocken überlegen, wahrscheinlich mit Bleistift und Karopapier.


    Ein anderes treffendes Beispiel ist zwar nicht in BASIC, sondern in Assembler, aber ansonsten trifft es die Problematik auf den Punkt. Und zwar das bis zu 183-fach beschleunigte RENUMBERn auf dem C64 durch einen grundlegend anderen Algorithmus. Grundidee kam Hoogo, und ich hatte das mal umgesetzt. Also ganz à la Snoopy: erst die Idee, dann coden. ABER: Auch da war es erst nur eine Grundidee, und der Algorithmus wurde während des Programmierens noch weiter verfeinert, vor allem durch die stark beschleunigte Zeilensuche, indem ich den BASIC-Code in bis zu 32 Abschnitte aufgeteilt hatte.


    Allerdings sprachen wir hier ja vom Beschleunigen von BASIC-Programmen. Das hatte ich, genau wie mit den BASIC-Tricks, so verstanden, dass man bereits ein Programm hat, das aber nicht schnell genug läuft, und dann daran eben algorithmisch was beschleunigt, sofern möglich.

    Snoopy Ich verstehe ja wohl, was Du meinst, aber dann solltest Du auch auf das Praktische eingehen, bezogen auf Forum, Threads und meine Beispiele. Das funktioniert hier nämlich so nicht. Kannst gern mal einen Thread aufmachen, wo nur normgerechte Struktogramme erlaubt sind. Jeder, der "BASIC" sagt, fliegt raus. Der Andrang wird sicher groß sein. :D


    Wir sind hier nämlich eben nicht (mehr) in der Uni/FH, und es ist hier auch ganz anders organisiert, insbesondere nicht so streng, sondern so, wie man damit am besten auskommt und es am meisten Spaß macht. Und ja, wenn jemand zu Fuß schnell von A nach B kommen will, sollte er nicht nur passendes Schuhwerk tragen, sondern auch über den kürzesten Weg nachdenken, beides gleichermaßen wichtig für die schnelle Bewältigung des Weges zu Fuß, völlig unabhängig davon, dass der kürzeste Weg die Reise auch bei Nutzung von anderen Fortbewegungsmöglichkeiten beschleunigt.


    ---


    Jetzt mal ernsthaft an alle: Wo müsste denn der Thread hin, wenn man sich eben nicht ausschließlich auf BASIC beziehen will?

    Die Buttons waren schon ok, aber die Möglichkeit, die Farben anzupassen, fehlte mir. Absolut jeden Editor stelle ich (nach Möglichkeit) mit heller Schrift auf dunklerem Grund ein, weil ich mit weißem Hintergrund einfach nicht arbeiten kann. Vielleicht hängt's mit meiner krassen Blendempfindlichkeit zusammen. Das ist mir so wichtig, dass ich dafür auf die Buttons verzichten kann. Man kann aber alles auch per Befehl machen. Linuxer wären stolz auf mich. :emojiSmiley-41:

    Ich erinnere mich daran, wie JeeK und ich mal exzessiv an der Optimierung eines Lotto-Algorithmus' in BASIC herumgedoktert bzw. auf Ausführungszeit optimiert hatten. Dabei ging es hauptsächlich um den Algorithmus. Hätten wir das nur theoretisch getan, hätte es nicht so viel Spaß gemacht. Es gäbe ja nicht mal Messungen, sodass man sicher sein kann, ob das eine oder andere schneller ist. Und wie sinnvoll wäre es gewesen, in einem Thread die Theorie zu besprechen und in einem anderen den BASIC-Code dafür? :gruebel


    <edit> haha, wenn man vom Teufel spricht ;)

    Unter "Optimierungen in BASIC" verstehe ich Tipps, wie ich den konkreten Algorithmus möglichst optimal in BASIC umsetzen kann.

    Er hat ja extra BASIC auch in Klammern gefasst, um etwas Spielraum zu lassen, weil diese Art der Beschleunigung sich eben oft (aber nicht immer) auch auf andere Sprachen übertragen lässt. Aber in irgendeiner Kategorie muss es ja rein. Und das ist jetzt eben BASIC, weil man wissen will, welche prozeduralen Verbesserungen (das ist nicht nur Algorithmik) zunächst in BASIC möglich sind.


    Wie beschrieben unterscheide ich zwischen "einen geeigneten Algorithmus zu finden", was immer der erste Schritt sein sollte, und "die Umsetzung dieses Algorithmus in BASIC".

    Das kann man ja gern unterscheiden, aber hier geht es um dessen Kombination, um ein BASIC-Programm zu beschleunigen. Wenn man noch gar keinen neuen Algorithmus hat, kann man auch nicht darüber reden, wie man ihn in BASIC umsetzt, und wenn man einen hat, will man hier wissen, wie man ihn in BASIC umsetzt, und beides zusammen bildet einen Vorgang, mit dem man BASIC beschleunigen kann.


    Falls man einen Thread aufmacht, wo über die Verbesserung von Algorithmen nur rein theoretisch diskutiert werden soll, obwohl es eigtl. um die Optimierung von BASIC-Programmen geht, dann kann man es doch besser gleich zusammenfassen, anstatt noch einen zusätzlichen Thread aufzumachen, der sich dann jeweils nur auf die BASIC-Umsetzungen der im ersten Thread besprochenen Algorithmen bezieht. Das kann man zwar so mit einer einzigen größeren Idee machen, aber mit vielen unterschiedlichen Beiträgen gibt das nur Chaos. Wir haben nicht zufällig gefühlt 38 ChatGPT/KI-Threads. Also lass uns doch die Dinge etwas zusammenhalten; dann muss man auch nicht alles zehnmal schreiben.


    BASIC steht hier neben Assembler nun mal an erster Stelle. Wer dann einen Algorithmus oder einen Trick wie die terminierende AND-Verknüpfung durch "THEN IF" in eine andere Sprache übertragen will, kann das ja immer noch tun. So mache ich das ja auch mit der Umsetzung von BASIC in Assembler. Dabei ist BASIC für mich einfach nur das bessere Flussdiagramm. Meinetwegen kann der Thread auch verschoben werden, nur wohin?


    Wenn ich ein BASIC-Programm angefangen habe und ich dieses durch Verbesserung der Algorithmik, Logik und Semantik beschleunigen will, dann will ich auch weiterhin wissen, wie das in BASIC aussieht. Zudem muss man in BASIC durchaus einiges anders machen als in Assembler, bspw. wenn man Multitasking simulieren will, so wie ich das beim "Konsumwahn" gemacht habe, wo viele Dinge gleichzeitig geschehen, und es trotz simultanem Zweispieler-Modus immer noch schnell genug ist, in purem BASIC V2, von einer kleinen PRINT-AT- und GOTO-X-Erweiterung abgesehen. Das Ding ist noch nicht mal fertig, da der CPU-Player fehlt, und das soll ebenfalls noch in BASIC passieren. Bei rein theoretischen Ideen fehlt dann aber der Bezug zum (BASIC-) Programm. Wenn ich das einbaue, dann im Zusammenhang mit dem bestehenden BASIC-Programm, also auch direkt auf BASIC und das Programm bezogen.


    Das mit den theoretischen Verbesserungen ist dann oft nur Kategorie "gut gemeint". Nicht selten Vorschläge, die überhaupt nicht in dem Programm möglich oder sogar kontraproduktiv sind.


    Es wird hier doch bei anderen Sachen auch so gemacht. Bspw. beim Mode7-Racer-Thread. Da wurde programmiert, und es wurden für etwaige Beschleunigung Ideen beigetragen. Da wurde ja auch nicht gesagt "Nö so geht das nicht. Wir brauchen einen Thread, wo die Ideen unterbreitet werden und einen, wo es nur um die Umsetzung der Ideen geht". Nein, man fasst das natürlich zusammen, und das berechtigt so einen Thread wie diesen hier, meine ich.

    Deswegen haben diese Tipps für BASIC2-Programm-Optimierung auch weiterhin ihre "Berechtigung". ;)

    Natürlich haben sie das. Ich glaube nicht, dass Berni das bestreiten wollte. Das sind im Prinzip verschiedene Themen, und darum hat er ja auch einen neuen Thread aufgemacht. Es geht bei der Betrachtung einfach nur um die Prioritäten. Also erst mal das Programm nach allen Künsten so schnell gestalten wie möglich, und wenn einem dazu nichts Besseres mehr einfällt, kann man noch den Code (weiter) optimieren. Also zuerst da gucken, ob man noch was verbessern kann und danach die Code-Tricks.


    Die Code-Tricks fallen eher ins Gewicht, wenn sie in einer Prozedur repetitiv zum Einsatz kommen. Wenn man aber einen langwierigen sequentiellen und kaum iterativen Algorithmus hat, dann nutzen darin solche Tricks eher wenig. Dann sollte man schauen, wie man das anderweitig beschleunigen kann. Typisches Beispiel zur Beschleunigung: Vereinfachung von logischen Verknüpfungen.


    Ich kenne ein interessantes Pico8-Spiel, von dem wahrscheinlich jeder zunächst denken würde, dass es auf dem C64 aus Rechenzeitgründen unmöglich sein muss, selbst in Maschinensprache. Ohne es geprüft zu haben, glaube ich, dass es möglich ist, das in gleicher Geschwindigkeit auch auf dem C64 zu realisieren. Das Ziel kann aber eben nur über einen ganz raffinierten Algorithmus erreicht werden, und womöglich sogar unter BASIC V2.


    Und ja gut, das gilt auch für andere Sprachen, aber hier soll es eben um BASIC gehen. Wenn man eine Lösung in BASIC gefunden hat, kann man es ja immer noch in Assembler umsetzen. Ich finde das ein spannendes Thema, zu überlegen, wie man Problemstellungen, die eigentlich für BASIC zu langsam sind, durch ausgeklügelte Vorgehensweise dennoch lösen kann.