Beiträge von TheRyk im Thema „Unterbrechungsroutinen C64“

    Ich hab zwar nie ein wirklich großes Projekt auf dem C64 gestemmt, aber trotzdem würde ich auch dort versuchen, alles entweder im Interrupt oder im Hauptprogramm laufen zu lassen..


    Letztlich ist es wohl wirklich Geschmackssache und "kommt drauf an", was man alles so gleichzeitig vorhat. Aber ja, zugegeben, GERADE für Großprojekte mit Huppy-Fluppy-Lader und "live" decrunching macht es Sinn. Es gibt aber auch sehr, sehr große Projekte, die völlig ohne IRQ auskommen =)

    Ich lasse eigentlich immer alles im Rasterirq laufen wenn ich denn einen verwende. Da tatsächlich noch ein "Hauptprogramm" mitlaufen zu lassen verkompliziert die Sache ja nur für mich.


    Kann ich bedingt nachvollziehen. Für manche Fälle sogar sinnvoll, es so zu machen, wobei ich die Betonung auf "WENN" legen würde. Vielleicht bin ich auch einfach verblödet oder mega-von-gestern, aber ich nutze (- anders als in der Anfangs-Phase, als man nicht wusste, was man tat, aber "lernte", alles in IRQ zu machen - ) nur noch sehr selten IRQs, weil man einfach sehr, sehr oft das Gleiche genauso gut ohne hinkriegt, wenn man weiß, was man wo im Frame tun will - und (jetzt kommt's) sich keinen Kopp machen muss, ob/wann/wie man laufende IRQs auch vernünftig beenden muss, um gar neue IRQs konfliktfrei aufzurufen, von Double IRQ und ähnlichen Scherzen mal ganz zu schweigen.

    Im IRQ die zeitkritischen Dinge und im Hauptproggi die wenig kritischen Sachen.


    Habe ich auch schon mal so gemacht, z.B. Joystick oder Tastatur-Abfrage "irgendwann" im Hauptprogramm, alles andere in eine IRQ. Aber kann man imho auch halten wie ein Dachdecker. Man kann auch im Hauptprogramm zeitkritische Sachen über $D012-Abfrage machen und per SEI verhindern, dass da eine IRQ dazwischen funkt und irgendwo per CLI dann festsetzen, in welchem Frame-Bereich IRQ-Time vergeben wird.

    Tricks, um die Unterschiede zwischen PAL/NTSC zu kompensieren, gibt es grundsätzlich jede Menge, ich kenne längst noch nicht alle. Manche dieser Tricks sind eher genau, erst dann kann man wirklich von NTSC-Fixing sprechen. Die meisten dieser Tricks (einschließlich meiner stümperhaften Versuche in der Richtung) sind eigentlich Pfusch, der so irgendwie Pi mal Daumen hinhaut mit dem Ziel, dass ein Programm immerhin auf NTSC nicht abstürzt, weil Rasterzeilen abgefragt werden, die es auch auf NTSC immerhin gibt und bestimmte Sachen wie Musik annähernd mit der gewünschten Geschwindigkeit passieren

    Man könnte Dich jetzt irgendwo hin verlinken, wo Du einen Codeschnipsel findest, um PAL vs. NTSC zu ermitteln. Aber Du würdest dem Link ja - erfahrungsgemäß - doch nicht folgen, sondern stattdessen einfach weiterfragen. Und die Frage wäre auch, was Du als nächstes dann mit der Info NTSC/PAL in Deinem Code machen willst. So viele Baustellen, wie Du gerade gleichzeitig auf hast, würde ich wie schon vorgeschlagen, NTSC eher mal geringe Priorität einräumen.

    PS: Und ICs wie zB SIDs sind einfach nur SIDs, egal ob die auf einem NTSC System laufen oder auf PAL ^^