Posts by ssdsa

    Damit das für die Leser keine blanke Theorie bleibt, habe ich hier mal unseren QR-Code-Screen angehängt. (Ich habe da natürlich wieder unnötig lange dran herumgepixelt – aber der Code sollte sich ja in die restliche Umgebung harmonisch einfügen.) ;)


    Normalerweise würde der Link auf die Monster Buster Scores-Seite bei P1X3L.NET zeigen und den Score als URL-Bestandteil übertragen aber da das natürlich alles noch nicht ganz fertig ist, habe ich erst einmal einen Dummy-Link erzeugt.


    Wow, ich finde echt klasse, dass Ihr QR-Codes erzeugen wollt. Ich habe so etwas auch mal überlegt und wollte es ursprünglich in mein Spiel "Match Buster" einbauen, aber ich habe den Gedanken damals recht schnell wieder verworfen, weil ich davon ausging, dass die dafür nötige Programmcode-Menge auf keinen Fall mit in meine 16K passen würde. Ich bin gespannt, wieviel Speicher Euer Programmcode zum Erzeugen der QR-Code belegen wird.

    Ah! Es liest hier also doch jemand mit ;-)

    Aber natürlich! Ich find's richtig klasse und sehr gut und verständlich beschrieben.


    Per Hardwareregister kann man immer nur die volle Bildschirmbreite scrollen (0-7 Pixel).
    Das kann man auch nicht IN einer Zeile aendern. Selbst wenn ich nur z.B. die linke Haelfte oder um bei Kuru zu bleiben 30 chars scrollen moechte, wackeln die rechten 10 dann trotzem fies hin und her.

    OK, hier muss ich der Vollständigkeit halber anmerken: Doch, man kann das Hardwareregister $D016 auch mitten in der Zeile ändern und die Änderung wird sofort wirksam. Wenn man also in jeder Rasterzeile das Hardwarescrollregister $D016 zweimal beschreiben würde, könnte man damit theoretisch auch die linken 30 Chars soft scrollen und die 10 rechten Chars fest stehen lassen. Das kostet aber so viel Rechenzeit, dass es in einem Spiel nicht sinnvoll nutzbar ist.

    In vielen Threads um Beschreibungen von euren Lieblingsspielen wird immer wieder Rockman als Boulder Dash-Version für den C-16 erwähnt.
    [...]
    Mittlerweile bin ich der Meinung, diese Einordnung ist falsch.
    Bin mal auf eure Meinung dazu gespannt.


    Das sehe ich auch so. Ich verstehe aber, dass es oberflächlich betrachtet in dieselbe große Schublade wie Boulder Dash gesteckt wird, weil es halt Felsen, einsammelbare Diamanten, Erde, Wände und Gänge hat. :roll:


    Für den C-16 Plus/4 sind auch andere Boulder-Dash-orientierte Spiele erschienen, kommerziell und auch innerhalb der Szene.
    Es wurde auch mal einige Versionen von Boulder Dash konvertiert, aber perfekt ist in meinen Augen was anderes. Alles zu finden hier:
    http://plus4world.powweb.com/sl.php?o=1&ptid=113


    Oh, die dort zu findenden Versionen von "Boulder Dash" und "Boulder Dash 2" sind aber doch ziemlich perfekt, oder? Ich wusste gar nicht, dass der Plus/4 so gute Grafikfähigkeiten hat, denn das Scrolling ist doch in alle Richtungen flüssig und sanft und im Gegensatz zur C64-Version ist nicht mal ein dicker schwarzer Balken zwischen Punkteanzeige und scrollendem Spielfeld.

    Ja wird sich zeigen, das Cartridge-gefriemel kommt am Ende :-\. Ich weiß nicht, ob das Compilat dann noch den Basicinterpreter braucht (z.T. vlt.) aber man kann die cartridge ja abschalten, erst sobald alles an seinen Platz ist im Speicher, soweit ich weiß und dann ist Basic und Kernal wieder verwendbar vom Prg. .

    Diese Annahme würde ich an Deiner Stelle am besten als Erstes prüfen. Ich dachte, bei den RGCD-Cartridges hat man 16K ROM ($8000-$BFFF), und wenn man das via $01 abschaltet, dann hat man dort ($8000-$BFFF) stattdessen RAM, also kommt man niemals an das BASIC-ROM.

    Was für den umgekehrten Fall ebenso gilt.


    Ich setze hier mal ein Preisgeld von 100 Euro aus, für den, der ein altes (bereits existierendes) BASIC-Programm findet, das an genau diesem Punkt scheitert und nachweislich nur daran. Dieses Preisgeld gilt für 6 Monate. Viel Glück.

    Ich habe sehr gehofft, dass mein BASIC-Spiel "4k-BASIC-Dash" mit gepatchtem BASIC-ROM die Steine oder Diamanten in den Levels anders zufällig verteilt als mit Original BASIC-ROM, und unter diesem Aspekt habe ich das Spiel jetzt bis zum Level "F/2" zweimal parallel (einmal mit gepatchem BASIC-ROM und einmal mit Original BASIC-ROM) gespielt. Leider gab es dabei bis dahin keine Unterschiede. Noch mehr Levels doppelt durchzuspielen, habe ich jetzt keine Lust mehr. Schade, die 100 EUR hätte ich gerne genommen. :)

    Ich werde am 24.12. wohl keine Gelegenheit haben, hier im Forum etwas zu schreiben oder hochzuladen. Meine 6 Beiträge (3 für C64 und 3 für C128) und eine Beschreibung dazu sind aber alle in der Datei "simonstelling.d64" in dem ZIP-Archiv (siehe Post #97) enthalten. Vielleicht kann einer von Euch diese Datei dann am 24.12. hier der Vollständigkeit halber hochladen?

    Um das Charset nur bei $1000 einzublenden, müsste man in Hardware die beiden Adressleitungen A15 und A14 in der Logik berücksichtigen. Um es bei $1000 und $9000 einzublenden, muss man nur A14 berücksichtigen. Man braucht also ein Logik-Gatter weniger. Vielleicht war das der Grund?

    Wegen VSP/FLD, ich glaube, ich habe eher einen FLD-Effekt. Sprich, wenn alles verrutscht ist, ist die unterste Scrollfeld-Zeile nochmal darunter in der Display-Anzeige zu sehen. Wenn ich richtig begreife (ich begreifstutze grade so schön), dann sollte ich mit dem FLD-Effekt die Anzeige komplett eine Zeile tiefer erzwingen?

    Ziel sollte sein, die feststehende Score-Anzeige immer mit YSCROLL=7 darzustellen.
    Wenn der obere Scrollbereich mit YSCROLL=7 so weit wie möglich per Soft-Scrolling nach unten gescrollt ist, dann kann die feststehende Score-Anzeige direkt (ganz ohne Lücke) daran anschließend dargestellt werden.
    Wenn der obere Scrollbereich mit YSCROLL=N (wobei N<7) weniger weit per Soft-Scrolling nach unten gescrollt ist, dann muss Du dafür sorgen, dass genau N Pixelzeilen Abstand zwischen dem Scrollbereich und der feststehenden Score-Anzeige sind.
    Bei N zwischen 4 und 6 machst Du es so: 1-2 Rasterzeilen vor dem Ende des aktuell sichtbaren Scrollbereichs schreibst Du 7 nach YSCROLL.
    Bei N zwischen 0 und 3 machst Du es so: 1-2 Rasterzeilen vor dem Ende des aktuell sichtbaren Scrollbereichs schreibst Du zunächst den Wert (N+4) nach YSCROLL. Anschließend, so 2 Rasterzeilen nach dem Ende des aktuell sichtbaren Scrollbereichs, schreibst Du 7 nach YSCROLL.
    Ist das so verständlich?

    Folgendes bringt vielleicht die meiste Ersparnis:


    12x dieses Code-Stück wiederholen:

    Code
    1. ldx _scrBuf,y ; --- char
    2. lda _chrCol,x ; --- color
    3. sta _colBuf,y
    4. sta _colBuf,y ; -- das "+40" ist hier absichtlich weggelassen

    Dann in der Init-Routine nur noch die jeweils nötigen Offsets (+0, +40, +80, usw.) auf die Adressen draufaddieren. Da Du exomizer und prepack6502 verwendest, müsste sich das 12x wiederholte Code-Stück ganz prima komprimieren lassen. Es kommt halt drauf an, wie kurz Du die Init-Routine hinbekommst.

    *** Ergebnisse der ersten BASIC Garbage Collection Compo (12.-30.09.2013) im Forum64 ***


    Um allen Teilnehmern und Beiträgen gerecht zu werden, wurden die Beiträge in verschiedene Kategorien eingeteilt.
    Beiträge vom Compo-Organisator (ssdsa) laufen außer Konkurrenz mit.



    Gewinner in der Kategorie "Basic BASIC":


    (Beiträge in dieser Kategorie enthalten nur reinen BASIC-Programmcode ohne eigene Assembler-Routinen, und die Messung läuft im BASIC-Programm ab.)


    • 1. Platz (02:06:47): Claus und Mac Bacon
    • 2. Platz (02:06:46): JeeK
    • 3. Platz (02:06:18): TheRyk
    • 4. Platz (01:55:34): marvin
    • Außer Konkurrenz (02:32:06): ssdsa



    Gewinner in der Kategorie "Basic BASIC Direct":


    (Beiträge in dieser Kategorie enthalten nur reinen BASIC-Programmcode ohne eigene Assembler-Routinen. Die Ausführung und/oder die Messung läuft teilweise im BASIC-Programm und teilweise im Direkt-Modus ab.)


    • Außer Konkurrenz (02:33:04): ssdsa



    Gewinner in der Kategorie "BASIC-GC mit eigener Assembler-Routine":


    (Beiträge in dieser Kategorie enthalten neben dem BASIC-Programmcode auch eine eigene Assembler-Routine, die durch Tricks (aber ohne SYS) aufgerufen wird. Die bei der Messung ausgegebene Zeit entspricht tatsächlich der Zeit, die die BASIC Garbage Collection verbraucht hat.)


    • Außer Konkurrenz (04:22:07): ssdsa



    Gewinner in der Kategorie "Eigene Assembler-Routine":


    (Beiträge in dieser Kategorie enthalten neben dem BASIC-Programmcode auch eine eigene Assembler-Routine, die durch Tricks (aber ohne SYS) aufgerufen wird. Die bei der Messung ausgegebene Zeit wird durch die Assembler-Routine willkürlich beeinflusst und entspricht nicht tatsächlich der Zeit, die die BASIC Garbage Collection verbraucht hat.)


    • 1. Platz (10:00:00): gartenzwerg



    Gewinner in der Kategorie "Originelle Beiträge":


    (Beiträge in dieser Kategorie erfüllen die Compo-Regeln nicht vollständig, sind aber so originell, dass sie einer Erwähnung bedürfen.)


    • gartenzwerg: unendlich lange Laufzeit (durch Assembler-Routine). Allerdings nicht ganz regelkonform, da "am Ende" keine Messung ausgedruckt wird.
    • Mac Bacon: druckt eine sehr lange Laufzeit (23:59:59) durch die Assembler-Routine aus. Der Aufruf der Assembler-Routine ist sehr geschickt verborgen. Leider nicht regelkonform, da länger als 128 BLOCKS.
    • Colt Seavers: startet eine eigene Assembler-Routine, indem das Programm ein komplettes (gepatchtes) BASIC-ROM mit in den Speicher lädt. Die Datei ist so lang, dass beim Laden schließlich am Ende ein Wert in die Speicheradresse 1 geschrieben und so das gepatchte BASIC-ROM aktiviert wird. Leider nicht regelkonform, da wesentlich länger als 128 BLOCKS.
    • marvin: Das BASIC-Programm lässt so wenig Speicher frei, dass der Befehl TE$=TI$ mit einem OUT OF MEMORY ERROR abbricht - dadurch wird die Garbage Collection aber ein zweites Mal ausgeführt. Anschließend soll man manuell NEW und die Befehle zur Messung eintippen. Dann kommt man eine lange Laufzeit 03:51:09 angezeigt, weil die GC 2x gelaufen ist. Leider nicht regelkonform, da die Messung nicht wie vorgeschrieben erfolgt.



    *** Herzlichen Glückwunsch allen Gewinnern und vielen Dank allen, die teilgenommen haben! ***



    Download aller Beiträge:
    Die oben genannten Beiträge habe ich in einem D64-Image zusammengefasst. Ihr könnt es hier als Anhang herunterladen. Viel Spaß beim Anschauen!



    Anmerkungen und Erkenntnisse:


    • Anzahl der Strings: Die Garbage Collection läuft offensichtlich um so länger, je mehr Strings (mit mindestens Länge 1) vorhanden sind. Dabei spielt es für die Laufzeit keine wesentliche Rolle, ob die Strings in normalen String-Variablen (A$, B$, C$, ...), in einem ein-dimensionalen String-Array (DIM A$(5000)) oder in einem mehr-dimensionalen String-Array (DIM A$(50,100)) enthalten sind. Am wenigsten Speicher pro String verbraucht ein ein-dimensionales Array, so dass dies die beste Wahl ist, wenn man möglichst viele Strings erzeugen möchte.


    • Reihenfolge der Strings: Weniger bekannt ist die Tatsache, dass die Garbage Collection länger läuft, wenn die Strings in einem String-Array "in umgekehrter Reihenfolge" erzeugt worden sind. Daher verwendet der am längsten laufende "Basic BASIC"-Beitrag ein ein-dimensionales String-Array und füllt es rückwärts mit 9691 Strings: DIM B$(9690) : FOR I=9690 TO 0 STEP -1 : B$(I)=CHR$(0) : NEXT


    • Nutzen des Direkt-Modus: Aus dem C64-Wiki ist die Tatsache bekannt, dass man im Direkt-Modus des BASIC mehr Speicher frei haben kann und daher ein größeres String-Array erzeugen kann und so eine noch längere Laufzeit der Garbage Collection erzwingen kann. Um programmgesteuert BASIC-Befehle im Direkt-Modus auszuführen, ist folgende Methode üblich: Das BASIC-Programm löscht den Bildschirminhalt, gibt mit PRINT die gewünschten Befehle im geeigneten Abstand auf dem Bildschirm aus und positioniert schließlich den Cursor oben links. Anschließend "legt" es mehrere RETURN-Tastendrücke in den Tastaturpuffer und beendet sich. Gemäß den Compo-Regeln ist aber der Befehl POKE verboten - also wie soll ein BASIC-Programm dann Tastendrücke in den Tastaturpuffer legen? Ganz einfach: Es bringt den Benutzer dazu, während des Programmablaufs die gewünschten Tasten zu drücken!


    • Starten einer eigenen Assembler-Routine: Gemäß den Compo-Regeln ist es nicht verboten, in den Beitrag eine eigene Assembler-Routine einzubetten. Da gemäß den Compo-Regeln jedoch die Befehle POKE, SYS und LOAD verboten sind, gibt es keine offensichtliche Möglichkeit, diese eigene Assembler-Routine auch tatsächlich aufzurufen. Trotzdem ist dies mehreren Teilnehmern auf unterschiedliche Weise gelungen. Respekt! Ich möchte an dieser Stelle noch nicht im Detail preisgeben, auf welche Weise manche Teilnehmer dies geschafft haben, denn vielleicht möchte der eine oder andere dies zunächst durch Studium der Beiträge selber herausfinden. Falls dazu dann im Anschluss Gesprächsbedarf besteht, können wir das hier im Thread aber durchaus nachholen.


    • Eine eigene Assembler-Routine - Unbegrenzte Möglichkeiten: Sobald es einem Teilnehmer in einem Compo-Beitrag unter Einhaltung der Compo-Regeln gelingt, eine eigene Assembler-Routine mitzubringen und zu starten, stehen ihm Tür und Tor offen: Er kann das BASIC-ROM ins RAM kopieren, dort beliebig modifizieren und es aktivieren. Dadurch kann er z.B. eine Verzögerungsroutine in die BASIC-Funktion FRE() einschleusen und so die Ausgabe der "Messung" im BASIC-Programm so hoch wie möglich schrauben. Da TI$ nach einem Tag vom Betriebssystem wieder auf Null zurückgesetzt wird, ist so die Ausgabe von 23:59:59 möglich. Aber auch beliebige andere Ideen sind möglich. Daher ist in der Kategorie "Eigene Assembler-Routine" die Sortierung nach längster Laufzeit nicht besonders aussagekräftig, weil der Teilnehmer die Laufzeit völlig frei bestimmen kann.


    • Eine eigene Assembler-Routine - Noch längere Laufzeit der Garbage Collection: Mit einer eigenen Assembler-Routine ist ja wie gesagt eigentlich alles möglich - und bei dieser Compo geht es darum, eine möglichst lange Laufzeit der BASIC V2 Garbage Collection zu provozieren. In der Kategorie "BASIC-GC mit eigener Assembler-Routine" ist daher ein Beitrag zu finden, der in Assembler eine bestimmte Veränderung am Speicher vornimmt, und dann das normale BASIC-Programm fortsetzt. Dadurch kann folgende BASIC-Zeile ausgeführt werden, ohne dass ein OUT OF MEMORY ERROR auftritt: DIM B$(12724) : FOR I=12724 TO 0 STEP -1 : B$(I)=CHR$(2) : NEXT - Es ist klar, dass die Garbage Collection mit 12725 Strings noch länger läuft als mit den sonst möglichen 9691 Strings. Daher erzielt dieser Beitrag von allen die tatsächlich längste Laufzeit der BASIC V2 Garbage Collection.



    Kommentare:


    Mir hat diese Compo sehr viel Spaß gemacht. Ich freue mich auf Eure Kommentare!
    ssdsa

    Ja, toll ... meine C128-Beiträge sind leider mit keinem Wort erwähnt, obwohl sie in der Datei "simonstelling.d64" in dem ZIP-Archiv (siehe Post #97) durchaus enthalten sind. :böse
    Wofür mache ich mir eigentlich die ganze Arbeit?! :(