Hallo Besucher, der Thread wurde 897k mal aufgerufen und enthält 9193 Antworten

letzter Beitrag von MC64 am

Der MEGA65-Laber-Stammtisch

    Zitat von Mad Fritz
    Zitat von Targas

    Ich komme darauf, weil im Discord mindestens 25 Nutzer von einem defekten RTC Chip berichtet haben, und nur deshalb ein externer Workaround von Paul gebastelt wurde.

    Ich bin einer dieser Nutzer auf Discord, die das Problem wie gewünscht gemeldet haben.

    Aber für mich gibt es schon einen geringfügigen Unterschied zwischen "Attrappe / nicht vorhanden" und "funktioniert nicht wie erwartet / kaputt" - auch wenn das Endresultat der gleiche Mist ist ;)
    Richtig interessieren würde mich allerdings, wieso meine RTC mit dem Zeigefinger auf einer bestimmten Position am Chip läuft.

    Vorschläge?

    Synchronisierung mittels Pulsschlag? (Herzfrequenz).

    Zitat von Snoopy

    Das sind gerade mal 8 Euro billiger als ein Neugerät. Wieso sollte jemand für die "Ersparnis" ein Gebrauchtgerät kaufen, wenn er es nicht supereilig hat? Er kann es ja immer noch neu vorbestellen.


    Oder wie es ein befreundeter Autohändler meines Vaters mal gesagt hat: "Wenn ich beim Neuwagen die Tür aufmache, verliert er locker 1000 Euro an Wert." :)

    Also, wenn ich bei einem 60.000,-€ Auto die Tür 61 mal öffne, bekomme ich Auto + 1000,-€ vom Händler??

    Zitat von Freddy
    Zitat von Snoopy

    Das sind gerade mal 8 Euro billiger als ein Neugerät. Wieso sollte jemand für die "Ersparnis" ein Gebrauchtgerät kaufen, wenn er es nicht supereilig hat? Er kann es ja immer noch neu vorbestellen.


    Oder wie es ein befreundeter Autohändler meines Vaters mal gesagt hat: "Wenn ich beim Neuwagen die Tür aufmache, verliert er locker 1000 Euro an Wert." :)

    Also, wenn ich bei einem 60.000,-€ Auto die Tür 61 mal öffne, bekomme ich Auto + 1000,-€ vom Händler??

    Nein, nur das erste Öffnen ist so teuer. Danach kannst du sie aufmachen, so oft du willst. :)

    Jetzt mal kurz was anderes

    Habe durch Zufall im Handbuch (deutsch) was interessantes entdeckt.

    Muss ich wohl nie richtig wahrgenommen habe, denn die ersten Seiten habe ich sehr schnell überflogen.

    Code
    1. Es geht um Folgende festgelegten Variabel
    2. T@&(SPALTE,ZEILE)=1: REM ZEICHEN
    3. C@&(SPALTE,ZEILE)=2: REM FARBE

    Habe dann mal auf der schnell ein kleines Programm geschrieben

    Und siehe da, es ist schneller als Poke

    Zeit mit den Variabeln


    Und hier die Zeit mit Poke


    Hier das kleine Programm

    zeit-test.prg


    Die Variabel können auch die Stelle im Bildschirmspeicher / Farbspeicher auslesen

    T& = T@&(SPALTE,ZEILE)

    C&= C@&(SPALTE,ZEILE)


    Snoopy hast du das schon gewußt ?

    Bin jetzt am überlegen ob ich BD danach umschreiben soll. Bin mir aber nicht sicher. Wahrscheinlich nicht. Aber für andere Kurzspiele werde ich das verwenden. Dann ist das Listing nicht mit Pokes und Peeks überfüllt. ^^

    Zitat von Drachen

    Bin jetzt am überlegen ob ich BD danach umschreiben soll. Bin mir aber nicht sicher. Wahrscheinlich nicht. Aber für andere Kurzspiele werde ich das verwenden. Dann ist das Listing nicht mit Pokes und Peeks überfüllt. ^^

    Ich bin gerade unterwegs und kann nicht nachschauen, du hast in deinem BD doch die Zeichen und Farben dazu mit POKE gesetzt?


    Ich würde dir auf alle Fälle raten, statt POKE und PEEK für den Textbildschirm auf die neuen T@& und C@& umzustellen. Zum einen sind sie leicht schneller als POKE und zum anderen funktioniert es dann auch mit dem neusten ROM 920372. In dem wurde ein zusätzlicher Modus 80x50 Zeichen eingefügt und im Rahmen dessen die Farbinfo einheitlich für alle Textmodi auf Adressen ab FF80800 gelegt. Statt POKE $D800,farbe musst du dann POKE $FF80800,farbe verwenden. Sonst hast du keine Farbinfos mehr im Spiel. C@& wird automatisch an die neue Adresse angepasst, da musst du dich um nichts kümmern.

    Zitat von Snoopy
    Zitat von Drachen

    Bin jetzt am überlegen ob ich BD danach umschreiben soll. Bin mir aber nicht sicher. Wahrscheinlich nicht. Aber für andere Kurzspiele werde ich das verwenden. Dann ist das Listing nicht mit Pokes und Peeks überfüllt. ^^

    Ich bin gerade unterwegs und kann nicht nachschauen, du hast in deinem BD doch die Zeichen und Farben dazu mit POKE gesetzt?


    Ich würde dir auf alle Fälle raten, statt POKE und PEEK für den Textbildschirm auf die neuen T@& und C@& umzustellen. Zum einen sind sie leicht schneller als POKE und zum anderen funktioniert es dann auch mit dem neusten ROM 920372. In dem wurde ein zusätzlicher Modus 80x50 Zeichen eingefügt und im Rahmen dessen die Farbinfo einheitlich für alle Textmodi auf Adressen ab FF80800 gelegt. Statt POKE $D800,farbe musst du dann POKE $FF80800,farbe verwenden. Sonst hast du keine Farbinfos mehr im Spiel. C@& wird automatisch an die neue Adresse angepasst, da musst du dich um nichts kümmern.

    Puuuuuuuuuuhhhhhhh

    Alla Gut, werde ich machen. Danke für die Info

    Im direkten Vergleich ist Poke schneller, nur durch die Multiplikation wird die Schleife langsamer. Bei Basic muss man umdenken, je mehr Zeichen der Interpreter einlesen muss, desto langsamer wird das ganze. Deshalb sind auch Programme mit hohen Zeilennummern langsamer. Im Grunde sollten PEEK und POKE gleich schnell sein, aber PEEK ist durch die Klammer zwei Zeichen länger und ist deshalb auch etwas langsamer. Außerdem gibt noch eine blöde Eigenheit vom Interpreter. Bei einem Sprung auf eine niedrigere Zeilennummer muss sich der Interpreter von Programmanfang bis zu der Zeile durchhangeln.

    Zitat von Acorn

    Im direkten Vergleich ist Poke schneller, nur durch die Multiplikation wird die Schleife langsamer. Bei Basic muss man umdenken, je mehr Zeichen der Interpreter einlesen muss, desto langsamer wird das ganze. Deshalb sind auch Programme mit hohen Zeilennummern langsamer. Im Grunde sollten PEEK und POKE gleich schnell sein, aber PEEK ist durch die Klammer zwei Zeichen länger und ist deshalb auch etwas langsamer. Außerdem gibt noch eine blöde Eigenheit vom Interpreter. Bei einem Sprung auf eine niedrigere Zeilennummer muss sich der Interpreter von Programmanfang bis zu der Zeile durchhangeln.

    Ja, habe jetzt mal angefangen das um zu bauen, aber es ist nicht wirklich schneller.

    Ich glaube ich lasse das mal. Denn wenn ich das ändere, muss ich alles in X-Koordinate und Y-Koordinate zerlegen.

    Und ob das dann ein Zeitgewinn ist, da bin ich mir echt unsicher.

    Wie gesagt habe ich mal damit angefangen, den Levelaufbau mit den Variabel T@&(Spalte,Zeile) und C@&(Spalte,Zeile) aus zu statten wo es gut ging.

    Aber den Rest von Acron Engine lasse ich mal so stehen :)


    Habe im Moment eh kleine Probleme mit den Steine und Maueren. Er will einfach nicht stehen bleiben.

    Muss mein Stroh im Kopf noch mehr befeueren damit ich eine Lösung finde. :D


    Zitat von Drachen

    Ja, habe jetzt mal angefangen das um zu bauen, aber es ist nicht wirklich schneller.

    Ich glaube ich lasse das mal. Denn wenn ich das ändere, muss ich alles in X-Koordinate und Y-Koordinate zerlegen.

    Und ob das dann ein Zeitgewinn ist, da bin ich mir echt unsicher.

    Wie gesagt habe ich mal damit angefangen, den Levelaufbau mit den Variabel T@&(Spalte,Zeile) und C@&(Spalte,Zeile) aus zu statten wo es gut ging.

    Aber den Rest von Acron Engine lasse ich mal so stehen :)

    Du musst nur darauf achten, dass die Farbinfos wie gesagt nicht mehr ab $D800 losgehen, sondern ab $FF80800. Also entsprechend die Adresse im Programm anpassen, sonst bleiben die Zeichen "farblos". ;)

    OK werde ich beachten. Danke Snoopy

    Zitat von Mad Fritz

    Richtig interessieren würde mich allerdings, wieso meine RTC mit dem Zeigefinger auf einer bestimmten Position am Chip läuft.

    Vorschläge?

    Es kann auch sein, dass der SMD chip nicht richtig verlötet wurde. Nimm mal einen anderen geeigneten Gegenstand als Fingerverlängerung um die Körpergeschichte ausser Kraft zu setzen und drücke dann mal leicht auf die Stelle. Wenn dann die RTC läuft gehe ich von aus,dass sie nicht korrekt verlötet wurde.