letzter Beitrag von spider-j am
Manchmal klappen dann irgendwann die einfachsten Sachen nicht mehr 
Aufgabe: im Bereich von $2000 bis $4000 in alle Speicherzellen #$00 schreiben in denen vorher #$ff stand:
Was ist denn nun falsch?!?
Eine Page lang funktioniert das und dann endlos Schleife innerhalb der Page...
In Zeile 13 bei .101b Startest du das Programm Neu, da du nach .1000 und nicht nach 1002 Springst
Der Branch in Zeile 5 sollte nach 100f gehen, da sonst die Abbruchbedingung für die innerste Schleife (X==0) nur geprüft wird, wenn zufällig ein $ff-Byte im Speicher gefunden wurde.
Dann fehlt noch ein lda $100e vor dem cmp #$40 in Zeile 12 (der Akku ist sonst an dieser Stelle dank Zeile 6 immer 0).
Und in Zeile 0 sollte ldx #0, damit auch wirklich immer eine ganze Page geprüft wird.
Der Branch in Zeile 5 sollte nach 100f gehen, da sonst die Abbruchbedingung für die innerste Schleife (X==0) nur geprüft wird, wenn zufällig ein $ff-Byte im Speicher gefunden wurde.
Ja, genau das ist es!!!
Das mit dem lda $1005/$100e hatte ich in meinen Tests selbst schon manchmal eingebaut, weil ich mir nicht mehr sicher war, ob inc auch den Akku beeinflusst oder nicht.-.. aber ohne das Erste gab es natürlich keinen Unterschied...
Nee, alles was so direkt auf den Speicher wirkt ändert nur Flaggen, Inc/Dec ändert N- und Z-Flagge, Asl/Lsr/Ror/Rol auch noch das Carry. Und natürlich wird auch noch der Speicherinhalt an der angegebenen Adresse verändert, sonst wären die Befehle ja ziemlich sinnlos 
Du kannst dann auch etwas kürzer einfach mit inc arbeiten, ist dann ja ff gewesen.
Ich wuerde sogar immer ein inc machen und danach einen BEQ branch.
Wenn es nach INC 0 ist, war es FF und alles bestens.
Ansonsten wieder ein DEC.
Also grob:
loop:
inx
inc 2000,x
BEQ loop
dec 2000,x
jmp loop
Nee ... irgendwie stimmt da was nicht. Die inc's beziehen sich ja aufs Hi-Byte. Also damit 20xx, 21xx, - 40xx gefüllt wird - für das Lo-Byte sorgt ja das X-Register [natürlich nach der Anpassung das zunächst mit #$00 zu laden - das vergess ich immer wieder gerne ... ]
Enthusis Methode passt schon, jedenfalls im Prinzip: Wenn 2000,x = ff war, ists nach dem Inc 0, die Z-Flagge ist gesetzt und der Branch wird genommen, ansonsten wirds wieder auf den ursprünglichen Wert geDec't. Der Branch muss nur noch auf den "Seite fertig" Test verzweigen, der hinter das Dec $2000,x gehört.
Ganz ohne Branch:
lda $2000,x
cmp #$ff
adc #00
sta $2000,x
ja klar, das inc/dec-Beispiel war nur für den "inneren" loop, also innerhalb einer page!
Wieso X wieder auf 0 setzen?
wenn Du einfach dex oder so nimmst, ist es ja von allein wieder auf 0.
Es bietet sich auch an zeropage zu nehmen
also
lda (zp),y
...
sta (zp),y
dann hast Du zwar ein inc zp statt inx aber dafür einheitlich...
Weisst Du wie ich's meine...?
Gruss,
Martin
ahhh. Jetzt ja ... Die Aufgabe ist zwar bereits erledigt, aber ich habe jetzt festgestellt, dass ich den ganzen Kram nochmal "invertieren" muss --- manchmal ist CrossDev echt seltsam. Jedenfalls habe ich noch keine Gesetzmäßigkeit herausbekommen, wie GangED nun eine PC-Grafik "importiert" - ich muss öfters entweder meine Anzeigeroutine oder eben die Grafik neu anpassen.
naja, wenn Du z.B. eine 2-Farb-Grafik hast, weiss der PC ja nicht welche Farbe "gesetzt" also bit 1 und welche 0 sein muss.
GIMP und Konsorten halten sich da gern an schwarz=0 und weiss=1 aber spätestens bei MC muss man dann deutlicher werden...
Solche Sachen (invertieren, alles was FF ist zu 00 etc) würde ich aber immer am PC dann noch machen wenn Du eh am PC mitarbeitest.
Solche Sachen (invertieren, alles was FF ist zu 00 etc) würde ich aber immer am PC dann noch machen wenn Du eh am PC mitarbeitest.
Ja. Ich denke mit dem Hex-Editor Suchen/Ersetzen wäre einfacher gewesen. Weiss auch nicht, warum ich gestern dafür den Vice angeschmissen habe. Wahrscheinlich war der Kopf einfach zu voll gestern Abend, nachdem ich Stundenlang programmiert hatte - einfach die Luft raus.
Aber mit dem invertieren am PC -> wie meinste das? Also ich hab das Bild ja jetzt als Hiresbitmap im .prg Format vorliegen. Und durch die Wandlung FF zu 00 habe ich jetzt überall das gleiche "Farbschema" [kein Pixel = $d021; Pixel = Farbe im Vidram].
Da ich jetzt aber gerne das Bild kurz "aufblinken" lassen würde, will ich das invertieren, weil das einfacher ist mal eben $d021 zu ändern, als das ganze Vidram. Nur wüsste ich jetzt nicht, wie ich das am PC machen sollte - außer mit Emu.
Und durch die Wandlung FF zu 00 habe ich jetzt überall das gleiche "Farbschema" [kein Pixel = $d021; Pixel = Farbe im Vidram].
Da ich jetzt aber gerne das Bild kurz "aufblinken" lassen würde, will ich das invertieren, weil das einfacher ist mal eben $d021 zu ändern, als das ganze Vidram.
Streicht das ruhig wieder aus dem Protokoll. Ist natürlich Quark! Geht ja so gar nicht...
naja, man muesste schon nen kleines Prog oder script am PC schreiben...
Echt Hiresbitmap? 320x200 ?
Das nutzt d021 nicht!
0 bit ist low nibble alos bit 0-3 vom screen Ram
1 bit ist high nibble alos bit 4-7 vom screen Ram
also da hilft das invertieren nicht viel!
Aber Du kannst ein 2. screenram vorbereiten bzw per code berechnen und dann via d018 einfach durchschalten, bzw auch mehr als zwei
0 bit ist low nibble alos bit 0-3 vom screen Ram
1 bit ist high nibble alos bit 4-7 vom screen Ram
also da hilft das invertieren nicht viel!
Ist mir wie oben geschrieben dann auch selbst noch eingefallen.
Screenumschalten verbraucht mir zuviel RAM.
Ich könnte natürlich versuchen nach Charset konvertieren.
Aber ich frage mich, ob das Blinken mit $d021 überhaupt "sauberer" ausehen würde... oder ob ich mich da gerade in etwas verrenne...
