Collab: Entwicklung eines TSB-Puzznic-Klons

Es gibt 1.089 Antworten in diesem Thema, welches 110.407 mal aufgerufen wurde. Der letzte Beitrag (1. November 2024 um 23:56) ist von Omega.

  • Huch, tatsächlich. Ich habe den Link mit der rechten Maustaste angeklickt und dann "Ziel speichern unter..." gewählt anstatt den Link mit der linken Maustaste anzuklicken. Aber wer kann mir das verübeln? Das Internet ist ja noch so neu. :whistling:

    Ich verwende GitHub ständig und habe das auch schon mehrfach versehentlich falsch gemacht. Aber so langsam habe ich es, glaube ich...

    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.

  • Hat hier im Forum noch irgendjemand keinen Port von diesem Micro-Compiler gemacht?

    Das war die Aufnahmeprüfung fürs Forum. Wie bist du ohne reingekommen? :schreck!:

    Ich habe dem Türsteher erklärt, dass ich einen "Makro-Compiler" entwickelt habe, der Micro-Compiler überflüssig macht. Er war so verwirrt, dass er mich einfach reingelassen hat. :)

  • EgonOlsen71: Ich habe den Eindruck, dass das originale BASIC-Programm gegenüber dem JavaScript einen entscheidenden Vorteil hat: Es zeigt an, in welcher Zeile ein Problem aufgetreten ist. Beim JavaScript muss man selbst herausfinden, welche Zeile ein Problem verursacht hat. Stimmst du mir da zu? Oder habe ich das jetzt nur zufällig so erlebt?

  • Nein, das macht das Javascript-Programm auch. Man muss dazu "nur" die Javascript-Konsole im Browser öffnen.

    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.

  • EgonOlsen71

    Ich habe die Fallen-Prozedur entwickelt und gleich ein Problem. Das Programm funktioniert im normalen Basic-Interpreter so wie es soll. Kompiliert auch ohne Fehler durch. Aber das Kompilat macht nicht das, was das Basic-Programm gemacht hat.

    Der Code macht folgendes bzw. soll folgendes machen:

    Es werden in einem 12x12 Kacheln großen Grid von unten links nach oben rechts 2x2 Zeichen große Kacheln geprüft. Dabei testet das Programm bei jeder Kachel, ob die obere Kachel ein bewegliches Teil enthält (obere linke Ecke der Kachel hat Bildschirmcode 64-96) und die untere Kachel leer ist (obere linke Ecke der Kachel hat Bildschirmcode 32). Wenn dies der Fall ist, wird vertauscht. D.h. die obere Kachel wird auf die untere Kachel kopiert und die obere Kachel wird gelöscht. In den Zeilen 0-2 wird zu Testzwecken eine Testkachel erzeugt.

    Das kompilierte Programm macht scheinbar gar nichts. So als wenn das Vertauschen nicht abgearbeitet wird. Aber warum? Das Basic-Programm macht es ja richtig. Woran kann das liegen? Hast du eine Idee? :gruebel

  • Ich hab so den Verdacht, dass man GOSUBs möglicherweise nicht verschachteln darf.

    IF darf nicht verschachtelt werden.
    FOR auch nicht.

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Probier mal, die Berechungen aus den PEEKs rauszuziehen. Also y+1 vorher in einer Variablen zu speichern, dann PEEK(var). Im PEEK direkt hat das bei mir auch nicht funktioniert. Bei POKE evtl. auch, da bin ich aber nicht sicher, ob das nötig ist.

    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.

  • Ich hab so den Verdacht, dass man GOSUBs möglicherweise nicht verschachteln darf. Na ja, wie auch immer. Ich geb's für heute auf. Gute Nacht! :zzz:

    Doch, kann man. Sieht man in der Tabelle, wo dargestellt ist, wie das übersetzt wird. Ein GOSUB wird einfach zu einem JSR, ein RETURN ist ein RTS. Das kannst du Schachteln, bis der Stack der CPU voll ist. Das sollte reichen.

    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.

  • Probier mal, die Berechungen aus den PEEKs rauszuziehen.

    Nein, das führt zu einem sehr seltsamen Verhalten des Programms. Und der Compiler meldet beim EXEC schon "Overflow Error in 0" und bricht ab. Mal abgesehen davon ist das resultierende Programm schon jetzt fast 1KB groß und das ist das Maximum, was ich habe. Dabei habe ich noch nicht einmal das Color-RAM beim Vertauschen der Kacheln berücksichtigt. Das wird wohl so nix. :nixwiss:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Dann zieh die Berechnung aus den POKEs auch mal raus. Die Fehlermeldung ergibt ja nur Sinn, wenn der da wild im Speicher rumpoked. Das mit den 1K muss man doch irgendwie hinkriegen...irgendwo muss TSB doch noch was freilassen...!?

    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.

  • Das kompilierte Programm macht scheinbar gar nichts

    Tatsächlich denke ich, dass das Programm richtig läuft. (ich habs bei mir laufen gelassen)

    ABER: nach Ende des Programmes wird der Bildschirm gelöscht und READY angezeigt.

    Versuch mal, dort wo du END machst, noch ein PEEK(197) zu machen (das entspricht GET) und erst dann zu beenden, wenn eine Taste gedrückt wurde.

    Dann sollte der Bildschirm erst gelöscht werden, nachdem eine Taste gedrückt wurde.

    Also zb (13 für Return, glaub ich)

    64 I=PEEK(197): IF I <> 13 then goto 64

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Dann zieh die Berechnung aus den POKEs auch mal raus.

    Dann wird das aber ein ziemlich umfangreiches Vertauschen. Und wenn man dann den gleichen Aufwand auch noch für den Farbspeicher braucht, dann wird's am Ende ziemlich groß. Und das ist ja nur der eine Teil der Geschichte. Der andere Teil ist das Auflösen der Kacheln bei Paarbildung. Das wird dann mindestens genauso umfangreich. Könnte man aber zumindest in ein separates Programm auslagern.

    Ich glaube, ich muss das erstmal genauer klären. GoDot: Wieviel Speicher steht mir bei TSB maximal zur Verfügung? Genau genommen müsste ich wissen, wieviele zusammenhängende Bereiche es gibt und wie groß die sind und an welchen Adressen. (Er kann mir aber nicht antworten. Er sitzt nämlich gerade in Berlin bei einem Max Raabe-Konzert und feiert seinen Geburtstag. :D)

    Tatsächlich denke ich, dass das Programm richtig läuft.

    ABER: nach Ende des Programmes wird der Bildschirm gelöscht und READY angezeigt.

    Nein. Diese Möglichkeit habe ich schon in Erwägung gezogen und getestet. Das kompilierte Programm löscht den Bildschirm nicht ohne Grund. Es wird wohl darauf hinauslaufen, was EgonOlsen71 sagt. Man muss alle Berechnungen irgendwie auseinanderfriemeln. Leider macht das den Programmcode nicht unerheblich größer.

  • Gefühlt hat der Compiler "nur" Probleme mit Berechnungen in PEEK/POKE. Berechungen zur einfachen Zuweisung von Variablen scheinen (im Rahmen der Einschränkungen...) OK zu funktionieren. Klar, macht es das ein wenig länger. Aber sooo viel sollte das nicht ausmachen. 6 Bytes mehr pro Variablenzuweisung. Aber gut...wenn der Platz knapp ist...

    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.

  • Ich glaube, bis das Alles zusammenpassend klappt, hast du vermutlich schon zweimal Assembler gelernt und die Routine selbst in Maschinensprache geschrieben.

    Okay. Mit welchem Buch kann ich Assembler in 'ner halben Stunde lernen?