Map effizient auf Screen abbilden

Die JSRs sind auch überflüssig und kosten cycles, inlinen.

Und ganz allgemein wann immer möglich auf "generischen" Code verzichten. Lieber eine Routine pro Map-Höhe, die sich dann eine Schleife komplett spart, weil der code "ausgerollt" wird.

Edit: Zustimmung zu self-mod, das ist (in aller Regel?) effizienter als ZP-Pointer zu nutzen.

Zitat von WebFritzi

Wie das, wenn ich Pointer habe?

Wie schon gesagt, Selbstmodifikation. Einfach den Pointer vorher schon in das Argument der Instruction legen.

Als kleine Inspiration hier mal der Code, der in Stoneage64 den Map-Ausschnitt auf den Bildschirm bringt:

Screen0 folgt dann analog (fürs double buffering) und ist bis auf die Zieladressen nochmal der komplett gleiche Code. Spart aber auch wieder ein paar Cycles. Diese .repeat Blöcke fügen wirklich zig mal den "gleichen" Code ein. Also kurz gesagt, der Code wird ganz schön groß, aber an der Stelle lohnt es sich bzw war einfach nötig, das Zeichnen muss halt schnell genug sein, damit mein 8-way scroll auch auf NTSC noch ohne glitch funktioniert

Zitat von WebFritzi

Klar, das wären ca. 180 Cycles bei einer Höhe von 10, also ca 3 Raster Lines. Klar, könnte ich ausschreiben, aber dann wird es unübersichtlich,

Dafür bietet ein anständiger Assembler z.B. Makros. Ein JSR das nur an einer Stelle aufgerufen wird ist IMMER Cycle-Verschwendung

Zitat von WebFritzi

Hier verstehe ich nicht so ganz, was du meinst. Du meinst Code, der von vielen "Variablen" (so wie hier "Expects: ...") abhängt?

Genau das. Lieber dedizierten Code schreiben für genau den Fall, den man braucht. Generisch ist auf dem C64 sehr oft schlicht zu langsam.

Zitat von WebFritzi

Dieses Repeat - geht das auch in ACME-Syntax im C64Studio? Das kannte ich so noch nicht. Sehr praktisch! So sieht es doch sehr übersichtlich aus.

Ein vergleichbares Konstrukt gibt es mit Sicherheit, ein Assembler, der das nicht bietet, taugt wenig. Aber wie das in ACME Syntax aussieht kann ich leider nicht sagen, ich verwende ca65...

Vielleicht noch zur Erklärung des Codes oben: Ich hab ja eine Map, die größer ist als der Bildschirm. Entsprechend stehen in scrxoff und scryoff die "offsets" des gerade darzustellenden Bereichs (sind ZP-Variablen). Um möglichst effizient auf die Map zugreifen zu können hab ich Pointer auf jede Zeile der Map, und zwar verteilt auf 2 Tabellen (low- und highbytes), die liegen bei "boardrowptrl" und "boardrowptrh".

Zitat von muffi

Ist es von den Taktzyklen her nicht egal, ob ich ein

LDA (ZP),Y

oder

LDA $0400,Y

mache? Braucht doch beides 6 Zyklen - AFAIK.

Indirekt (ZP),Y braucht 6 Zyklen. ABS,Y (oder auch ABS,X) braucht 4 Zyklen, bzw 5 wenn n page-boundary überschritten wird. Und ja, in Loops addiert sich das schon verdammt schnell auf.

Edit: Einen Sinn sehe ich in (ZP),Y eigentlich nur für Code, der im ROM läuft wodurch self-mod logischerweise ausscheidet.

Edit2: Wenn man's mal genau wissen will mit Cycles und anderen Fragen, sehr gute Referenz zum 6502/6510 findet sich hier: http://www.oxyron.de/html/opcodes02.html

Zitat von berni

Mit dem illegalen Opcode lax geht noch mehr (leider gibt es stx $0400,y nicht, sonst könnte man den stattdessen benutzen):

Zustimmung (zu beidem, auch dem in Klammern). Und Hinweis, dass man das vielleicht nicht machen will (bzw sich halt überlegen muss). Es gab ja so Maschinen (DTV glaube ich?), die nur die dokumentierten Opcodes unterstützen. WENN es mit solchen Exoten laufen soll dann Finger weg von "illegal opcodes"

Ja, wirklich schade, dass "indiziertes store" nur für den Akku geht. Bin da auch immer mal wieder reingefallen, load geht ja