Posts by Claus

    Warum kann man nicht die Anstiegszeit von 0% auf 100% nehmen, die will man doch eigentlich wissen?

    Eigentlich steht es ja genau da :whistling: :D:



    Was nimmst Du überhaupt genau für 100%? Und was, wenn wegen Ungenauigkeit der Wert dann plötzlich genau 0,001 mV darunter bleibt? Also nimmt man lieber etwas weniger, und warum dann nicht 10% weniger ^^...

    Ich hoffe, ich bringe Dich nicht komplett auf den falschen Pfad, da ich vom Mega65 keine Ahnung habe. Aber am C64 (sprich: VIC-II) werden im Multicolormode ja immer Paare aus benachbarten Bits verwendet, um aus den 4 möglichen Farben eines Pixels zu wählen (daher sind die Multicolorpixel auch doppelt so breit). Ein Byte beschreibt also 4 Pixel. Es gibt 4 mögliche Bitpaare: 00, 01, 10 und 11. Nur die letzteren beiden davon lösen eine Kollision mit Sprites aus, die ersten beiden zählen quasi als Hintergrundfarben.

    Ne, die Mehrzahl der Spiele verwendet wohl einen Raster-IRQ, damit Animationen smooth aussehen. Wenn das Spritekollisionsregister überhaupt verwendet wird (und Kollisionen nicht einfach anhand der Koordinaten detektiert werden), dann wird es wohl einfach im selben IRQ gelesen, anstatt einen Extra-IRQ durch die Kollision auszulösen.

    Ein Task ist m.E. dadurch definiert, dass er im wesentlichen unabhängig von anderen Aufgaben läuft. Für den IRQ im Hintergrund von Basic ist das m.E. erfüllt, aber die verschiedenen Aufgaben in einem Spiel sind ja meist alles andere als unabhängig, und oft allesamt durch die Framerate getimed und damit komplett sequentiell. Tatsächlich finden sie ja sogar oft allesamt innerhalb der selben IRQ-Routine statt, während im Mainloop praktisch nix passiert.


    Ein "richtiger" Task erfordert das Speichern und Wiederherstellen des entsprechenden "Zustands". Im einfachen Fall (wie bei Basic mit IRQ) sind das nur Prozessorregister und Flags. Für ein wenig aufwändigere Tasks wäre das noch der Stack, I/O-Zustände etc. Dafür ist zumindest der 6502 (z.B. durch seinen festen HW-Stack) denkbar schlecht vorbereitet (vom Z80 habe ich zu wenig Ahnung um das zu bewerten).

    Ich brauche im Moment ein komplett leeres Charset um den Scrollbereich oben/unten sauber "abzuschneiden", da gäbe es VIELLEICHT auch ne elegantere Lösung, aber so wie es ist tut es ja ;-)

    Könntest Du das nicht durch Umschalten auf einen illegalen Screenmode lösen? Praktischerweise ist Dein Hintergrund ja schwarz (was auch bei illegalen Screenmodes augegeben wird).


    Quote from VIC-II Manual

    3.7.3 Grafikmodi

    Der Grafikdatensequenzer beherrscht 8 verschiedene Grafikmodi, die über die Bits ECM, BMM und MCM (Extended Color Mode, Bit Map Mode und Multi Color Mode) in den Registern $d011 und $d016 ausgewählt werden (von den 8 möglichen Bitkombinationen sind 3 „ungültig” und erzeugen die gleiche Ausgabe, nämlich nur die Farbe Schwarz).

    Wenn man eh schon in Assembler programmiert, finde ich es müßig, sich irgendwelchen philosophischen Einschränkungen zu unterwerfen. Man sollte nichts optimieren und dadurch den Code schlechter lesbar machen, wenn es nicht nötig ist. Fehlen einem aber die entscheidenden Zyklen, sollte man m.E. tun was nötig ist, was selbstmodifizierenden Code und illegale Opcodes einschließt.

    Ich gebs auf. Ich habe einfach zu wenig Ahnung von Bitbucket und der Build Pipeline sowie von MinGW, Wine, Docker etc. Ich schaffe es nicht, cc1541 dort für WIn32 cross-zubauen und die Tests auszuführen. Wenn jemand sich auskennt, gerne mal in die Build Pipeline schauen (meine verzweifelten Versuche sind in der History ab Oktober 2021): https://bitbucket.org/PTV_Clau…r/bitbucket-pipelines.yml


    Mein Verdacht ist, dass die Bitbucket VMs keinen 32 Bit-Code ausführen können, denn wenn ich ein 32 Bit Docker-Image verwende, kann ich zwar cc1541 bauen, beim Ausführen kommt aber: "/usr/bin/wine: 40: exec: /usr/lib/wine/wine: Exec format error".


    Bin für jeden Hinweis dankbar!

    Das ist schon alles gut so wie es ist. Ein bisschen könnte man wohl noch durch Vermeiden der ZP Pointer und selbstmodifizierendem lda ,y und sta ,y im inner loop rausholen, aber viel macht das nicht aus.

    Das liegt aber vor allem daran, dass du das mingw-Binary mit Debug-Symbolen auslieferst und das von Visual Studio erzeugte vermutlich nicht. Eine Behandlung mit strip lässt die cc1541.exe aus Release 4.0 von 582.400 auf 141.824 Byte schrumpfen.

    Huch, das ist nicht beabsichtigt. Seufz, ich werde wohl die Build Pipeline doch noch einmal anschauen :(

    Die 32bit-exe ist ja winzig, im Vergleich zur siebenmal so grossen 64-Bit Version. *lol*

    Das liegt aber vor allem an Visual Studio, das viel kleinere Binaries erzeugt als der gcc, den ich in meiner Bitbucket-Pipeline habe und normalerweise für cc1541 verwende.

    Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

    Ja, leider erlaubt meine Bitbucket Pipeline keine Win32 Binaries mehr und ich habe es nach langen vergeblichen Versuchen aufgegeben, das irgendwie wieder hinzubasteln. Aber weil Du so nett fragst, bau ich Dir heute abend eine Version manuell und häng sie hier an :).

    Hier, mit Liebe gebaut :love:. Habs nicht wirklich getestet, aber ich wüsste nicht, warum es nicht gehen sollte...

    Files

    • cc1541_x86.zip

      (35.87 kB, downloaded 10 times, last: )

    Claus , wäre eine 32bit kompatible Version von cc1541 V4.0 machbar? Die alten Versionen des Programms laufen noch bei mir, die neueren irgendwie nicht mehr, da kommt immer "nicht kompatibel zu meinem Windows".

    Ja, leider erlaubt meine Bitbucket Pipeline keine Win32 Binaries mehr und ich habe es nach langen vergeblichen Versuchen aufgegeben, das irgendwie wieder hinzubasteln. Aber weil Du so nett fragst, bau ich Dir heute abend eine Version manuell und häng sie hier an :).

    Spricht ja nichts dagegen, z.B. eine Website zu basteln, bei der man sich online (ggf. auch per WiC oder so) seine individuellen Onefiler-Sammlungen zusammenstellen und als Transwarp-D64 runterladen/auf Diskette schreiben lassen kann... dann gäbe es vermutlich ein paar Benutzer mehr als nur per cc1541. Aber wer baut's? ;)

    Die Idee finde ich interessant! Leider habe ich Null Ahnung von Web-Entwicklung und würde bei meinen Versuchen vermutlich Sicherheitslücken groß wie Scheunentore erzeugen. Falls ich aber jemanden der sich mit Webentwicklung auskennt mit meinem cc1541-Wissen supporten kann, jederzeit! :).