Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! Aaaaa! Ich könnte gegen die nächste Wand rennen! Ich dachte immer, dass bei CMP das C-Flag immer das N-Flag in invertiert ist, aber nein! Neinneinnein! Jetzt kann ich wohl einen Haufen Code neu schreiben.
Heute so gecodet...
-
syshack -
June 23, 2016 at 3:26 AM -
Thread is Unresolved
There are 2,418 replies in this Thread which has previously been viewed 504,172 times. The latest Post (
-
-
Ich dachte immer, dass bei CMP das C-Flag immer das N-Flag in invertiert ist, aber nein!
Das wäre ja Verschwendung teurer Transistoren.
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
-
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
Stimmt nicht! Das konnte ich jetzt schon irgendwo lesen. Denn:
$7F (127) - $80 (>-128) = $FF (N=1)
$01 (1) - $FF (>-1) = $02 (N=0)
-
Ich habe nach mehr als 10 Jahren auch mal wieder angefangen - es hat einfach zu sehr in den Fingern gejuckt...
Ziel ist ein Heli-Spiel mit 64 Screens (wenn ich ans technische Niveau von 1983 herankomme, bin ich glücklich).Please login to see this attachment.Please login to see this attachment.
Ich habe heute schon auf Papier mein "DrawTile" geschrieben und gerade ausprobiert. Läuft sogar wie geplant.Ein Room besteht quasi aus lauter 2x2 Char-Tiles. Jetzt kommt die Routine zum Zeichnen eines Levels. Dann gehts erstmal ans Sprite- und Charset basteln. Ich bin gespannt, ob alles klappt. Ich habe bestimmt bald Fragen
Zum Beispiel dann, wenn ich bei den Interrupts bin...Es ist echt schwer, wenn man lange lange laaange in Z80 und 80286-Asm programmiert hat.
-
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
Stimmt nicht! Das konnte ich jetzt schon irgendwo lesen. Denn:
$7F (127) - $80 (>-128) = $FF (N=1)
$01 (1) - $FF (>-1) = $02 (N=0)
Ja. Kurz gesagt: Das N-Flag enthält einfach das Vorzeichen des Ergebnisses (also dessen Bit 7), nachdem das Ergebnis auf acht Bits zurechtgestutzt wurde.
Oder anders ausgedrückt: Wenn man das Register mit dem Argument vergleicht, dann ist danach N genau dann gesetzt, wenn das Argument einer der 128 Werte ist, die auf den Registerwert folgen. Ist das Argument aber der Registerwert selbst, oder einer der 127 Vorgängerwerte, dann wird N gelöscht.
Wenn man sich das Verhalten der Flags tabellarisch darstellt, dann bildet N einen diagonalen Streifen, während C ein Dreieck inklusive der Hauptdiagonale belegt.
-
C zeigt das Ergebnis für unsigned-Vergleiche, N zeigt das Ergebnis für signed-Vergleiche.
Stimmt nicht! Das konnte ich jetzt schon irgendwo lesen. Denn:
$7F (127) - $80 (>-128) = $FF (N=1)
$01 (1) - $FF (>-1) = $02 (N=0)
Das liegt daran, das CMP, CPX, CPY das Overflow-Flag nicht entsprechend ändern.
Wenn man einen Signed-Byte-Vergleich haben will, muss man SBC verwenden:
CodeLDA wert1 SEC SBC wert2 BVC kein_overflow EOR #$80 ; Overflow, Vorzeichen ist negiert, also umdrehen kein_overflow: BMI kleiner ; wert1 < wert2 BEQ gleich ; wert1 = wert2 BPL groesser ; wert1 > wert2 -
Please login to see this attachment.
Wird ja langsam.... *Schwitz*
-
Please login to see this attachment.
Wird ja langsam.... *Schwitz*
Neue Version von
? -
<ketzermodus> Das schönste Choplifter ist das am Master System (Z80!) </ketzermodus>
Nein, kein Choplifter. Eigentlich bietet sich das Thema an, weil ich nicht malen kann und es eigentlich in erster Line ums Experimentieren geht.
Ich hatte bisher nie etwas in der Art programmiert - im Screen variable Gegner, die von der Engine im Intrrupt bewegt werden.
Ach ja: Interrupts. Ich möchte eigentlich nur noch den Raster-Interrupt (und die Kollissions-Register) als einzige IRQ-Quelle haben.
Und dann möchte ich das Kernel/BASIC ausblenden und direkt meinen IRQ da reinhängen - weil BASIC brauche ich ja nicht, wenn das Programm läuft.
Muss ich da irgendetwas beachten? Wenn ich das Kernel "aushänge" - klappt dann die JoyPort-Abfrage noch, oder muss ich den CIA dann selbst entsprechend programmieren? Würde das gehen ? Ich brauche nebenbei keine Kernel-Routinen im Game - reicht es, das Kernel über CPU-Port 1 auszuschalten und den IRQ-Vektor vom 6510 ($FFxx) einfach abzuändern?
-
Muss ich da irgendetwas beachten? Wenn ich das Kernel "aushänge" - klappt dann die JoyPort-Abfrage noch, oder muss ich den CIA dann selbst entsprechend programmieren? Würde das gehen ? Ich brauche nebenbei keine Kernel-Routinen im Game - reicht es, das Kernel über CPU-Port 1 auszuschalten und den IRQ-Vektor vom 6510 ($FFxx) einfach abzuändern?
Es schadet nicht, die Original-IRQ-Routine im ROM einmal langzulaufen , zumindest Start und ab $Ea7e.
Wenn Du VIC-IRQs schon mit $314 gemacht hast, dann weißt Du ja schon über den VIC Bescheid.
Fang easy an: Schalte CIA-IRQs ab und nur Raster ein, ignoriere BRK.
Und dann guck erst, welche Steigerungen Du brauchst.
Brauchst Du BRK?
Sollen die IRQs unabhängig von ROM/RAM/IO funktionieren?
CIA und VIC-IRQs zusammen?
Interrupte, die durch andere Interrupte unterbrochen werden sollen? Achte darauf, wie Du vor dem CLI die IRQ-Quelle bestätigst.
Und wie verhalten sich eigentlich die Kollisions-Interrupte genau, wenn Sprites in mehreren Zeilen kollidieren?
-
Vielen Dank für die Infos!
Nein, BRK plane ich nicht zu nutzen. Aber wer weiß
Ich brauche keine andere Interrupts - nur den VIC als quelle - das habe ich ja schon mal gemacht. Nur damals lief Kernel noch nebenher.
Beim ersten Tests vor ein paar Wochen hat es mir auch ständig wieder das Kernel eingeblendet - da hatte ich sicher irgendwo einen (Schreib-)Fehler.
Wie gesagt, ich brauche nach dem Start die ROMs nicht mehr.
Interessanter Punkt mit den Interrupts, die Interrupts unterbrechen! Da muss ich mal nachdenken. Aber ich denke erstmal, das wird sich von der (geplanten) Logik her nicht auswirken. Aber ich betrete hier Neuland und habe noch viel zu lernen...
-
Interessanter Punkt mit den Interrupts, die Interrupts unterbrechen! Da muss ich mal nachdenken. Aber ich denke erstmal, das wird sich von der (geplanten) Logik her nicht auswirken. Aber ich betrete hier Neuland und habe noch viel zu lernen...
Falls Raster- und Kollisions-IRQs in den gleichen Rasterzeilen passieren dürfen, dann wäre auch ich in Neuland
-
Die Frage ist, wie nützlich es überhaupt ist, in der Rasterzeile in der die Kollision passiert gleich einen IRQ zu bekommen. Üblicherweise prüft man einfach manuell das Sprite-Kollisionsregister im VIC-IRQ und braucht sich dann auch nicht mit mehreren IRQs rumzuschlagen. Mit fällt spontan kaum eine Situation ein, in der man in einem Spiel überhaupt mehrere IRQ-Quellen benötigen würde. Ist das nicht eher was für Demos mit Audiosamples etc.?
-
Das könnte sogar passieren. Aber ich vermute, da die Bedingung - z.b. Sprite/Sprite-Kollission weiter besteht, gibt's gleich noch einen Interrupt hinterher. Im Raster IRQ (bei 0) wird bewegt und die Gegner-Logik abgearbeitet. Somit denke ich, da bin ich safe.
-
Du meinst, sowieso immer fix die Kollision checken und die erst gar nicht als IRQ zulassen?
-
Du meinst, sowieso immer fix die Kollision checken und die erst gar nicht als IRQ zulassen?
Exakt!
-
Das werde ich glatt testen
super! -
Ich habe in meinem Disassembler die Auswertung der Steuerbefehle (links im Bild) neu programmiert.
Please login to see this attachment.
Der Code ist gefühlt 100x kleiner und war eben bei einem Testlauf auch sauber zum gesetzten Breakpoint durchgelaufen.
-
Ich habe in meinem Disassembler die Auswertung der Steuerbefehle (links im Bild) neu programmiert.
Wofür ist "Button1"?
-
Ich habe in meinem Disassembler die Auswertung der Steuerbefehle (links im Bild) neu programmiert.
Wofür ist "Button1"?
