Map effizient auf Screen abbilden

1570 · 29. Januar 2023

Zitat von Zirias/Excess

Wenn ich sowohl dem ZP-Pointer als auch meinem Instruction-Argument fürs LDA/STA ein Label verpasse, wieso ist es dann mehr oder weniger fehleranfällig?

Wenn's jetzt nur um das Verändern von Operanden geht, finde ich selbstmodifizierenden Code sogar ab und zu lesbarer (mit entsprechenden Kommentaren) und wartbarer (da kein Heckmeck in der Zeropage nötig).

Aber fehleranfällig ist's schon, wenigstens z.B. sofern RUN/STOP-RESTORE angeschaltet bleibt (z.B. bei Utilities sicherlich üblich) und z.B. der Code fest davon ausgeht, dass die Low-Bytes der Operaden beim Start immer #$00 sind. Da ist mein eigener Code auch häufiger eigentlich kaputt.

Und es ist natürlich unschön, dass man den Code für ROM (auch ggf. in CRTs) nicht benutzen kann.

Zirias/Excess · 29. Januar 2023

Zitat von 1570

Aber fehleranfällig ist's schon, wenigstens z.B. sofern RUN/STOP-RESTORE angeschaltet bleibt (z.B. bei Utilities sicherlich üblich) und z.B. der Code fest davon ausgeht, dass die Low-Bytes der Operaden beim Start immer #$00 sind. Da ist mein eigener Code auch häufiger eigentlich kaputt.

Also der NMI durch RESTORE bringt dir so ziemlich JEDES Programm zum Absturz (oder zumindest unerwünschtem Verhalten falls KERNAL noch eingeblendet ist) wenn du das nicht bedacht hast. Handlen, oder gleich ganz blocken falls du sonst keine NMIs brauchst

Zitat von 1570

Und es ist natürlich unschön, dass man den Code für ROM (auch ggf. in CRTs) nicht benutzen kann.

Zumindest auf dem C64 spielt das heute(!) in der Praxis in aller Regel keine Rolle mehr es sei denn vielleicht man bastelt an seinem eigenen KERNAL. Aber Software aus Cartridges wird fast immer sowieso erst mal ins RAM kopiert.

Aber klar, das ist immer der Pferdefuß. Wenn's direkt aus ROM lauffähig sein muss dann braucht man die ZP-Pointer

WebFritzi · 29. Januar 2023

Zitat von Zirias/Excess

edit: Nur immer NTSC bedenken, falls man das supporten will ... die 20% schnellere Framerate kann heftig in die Suppe spucken
edit2: NTSC war der Grund, warum ich von einer Map mit "Tile-Nummern" weggekommen bin und stattdessen die Map schon beim Level-Laden in Screencodes übersetze, was 4 mal so viel RAM braucht, aber nur so war das Zeichnen auf NTSC noch schnell genug. NTSC is a bitch

NTSC? Oh, da hatte ich gar nicht dran gedacht. Ich habe gerade mal im Vice nachgeschaut, wie mein Programm darunter läuft. Es ist ein wenig glitchier, aber noch im Rahmen. Puh. Ich habe zeitweise viele Rasterzeileneinsprungspunkte in meinem IRQ-Handler, der IRQ ist nicht stabil, und weder BASIC noch KERNAL sind ausgeschaltet.

Acorn Coole Idee, danke. Aber was soll das "EOR #$DC" bewirken? Die low Bytes von Screen und Color sind bei mir ja eh immer gleich. Also habe ich es einfach weggelassen, und es funktioniert hervorragend.

Acorn · 29. Januar 2023

Zitat von WebFritzi

Acorn Coole Idee, danke. Aber was soll das "EOR #$DC" bewirken? Die low Bytes von Screen und Color sind bei mir ja eh immer gleich. Also habe ich es einfach weggelassen, und es funktioniert hervorragend.

Klar stimmt da hatte ich das H-Byte im Sinn und nicht das L-Byte, mit EOR dürfte das so auch gar nicht laufen, sowas passiert, wenn man den Code nicht testet.

ogd · 29. Januar 2023

Zitat von Zirias/Excess

Zitat von Acorn

könnte man die Zeichen auch entsprechend der Farbe im Zeichensatz ablegen.

Funktioniert halt nur so lange wie keine zwei verschiedenen Zeichen die gleiche Farbe brauchen

Aber WENN das wirklich so ist, ist das natürlich eine sehr clevere Optimierung

EDIT: Man kann die Idee auch generalisieren: Das high-nibble der Farbe ist ja unbenutzt -- damit lässt sich das auf fast jedes Szenario ausweiten, WENN man auf die restlichen Zeichen im Charset verzichten kann (kann ich bei Stoneage64 leider nicht, ich brauche da Textzeichen ... aber so im Allgemeinen, coole Idee!)

Alles anzeigen

Zu der Idee habe ich mal hier ein paar Testprogramme geschrieben: Zarch (Virus) auf dem C64 1:1 machbar?

WebFritzi · 30. Januar 2023

Wie ist das gemeint: "die Farbe im Zeichensatz ablegen"? Ich stelle mir das jetzt so vor, dass man z.B. eh nur 8 der 16 Farben verwendet und die 256 Zeichen in 8 Blöcke von 32 Zeichen anordnet. Dann muss man noch in einem Table festlegen, welche der acht Farben das sind und könnte dann sowas schreiben:

Code

colors !byte 0,1,2,4,7,9,11,15
.
.
sta $FFFF,x; fülle screen mem
lsr
lsr
lsr
lsr
lsr
tay
lda colors,y
sta $FFFF,x ; fülle color mem

Alles anzeigen

Das ist zwar nicht schnell, spart aber 256 Bytes (wenn wie in meiner ursprünglichen Routine jedem Char eine Farbe zugeordnet ist) oder sogar noch mehr, wenn man eine oder mehrere Colormaps benutzt. Oder habe ich das jetzt falsch verstanden?

Acorn · 30. Januar 2023

Zitat von WebFritzi

Oder habe ich das jetzt falsch verstanden?

Die Zeichen 0,16,32,48 usw. sind auf der Position für schwarz, 1,17,33 weiß, 2,18 rot usw. im Zeichensatz. Man legt die Zeichen einfach entsprechend ihrer Farbe für das Farbram im Zeichensatz ab. Dann kann man den selben Wert auch direkt ins Farbram schreiben.

Code

LDA MAP
STA SCREEN
STA COLOR

WebFritzi · 30. Januar 2023

Acorn Alles klar, verstehe. Das ist natürlich sehr effizient. Aber 16 Zeichen pro Farbe ist ziemlich mau.

Zirias/Excess · 30. Januar 2023

Hmm, die Idee fand ich jetzt doch faszinierend genug und habe deshalb ein bisschen analysiert...

Bei einem char kann ich die Farbe beliebig (>= 8 )wählen, weil nur eine MC-Farbe verwendet wird. Damit schaffe ich es, dass ich maximal 2 Zeichen mit der gleichen Farbe habe. Und DAS heißt, der Trick wäre sogar umsetzbar obwohl im gleichen Charset noch ein Font mit Text- und Grafikzeichen liegt

Einsparpotential liegt in meinem Fall bei knapp 14000 Cycles, oder mindestens 220 Rasterlines (nur überschlagen). Da Die Spiellogik schon jetzt aus Performancegründen direkt auf den Screencodes arbeiten muss ist DAS natürlich ein kleiner Nachteil, wenn die dann ohne jede "logische" Anordnung liegen ....

Ich denke ich werde trotzdem mal versuchen, das umzusetzen, denn mit etwas Glück ermöglicht es ein Feature, das bisher ebenfalls aus Perforemancegründen nicht machbar war: Schnelleres Scrolling im "sich umschauen"-Modus Wäre echt cool, wenn das hinhaut.

Zirias/Excess · 30. Januar 2023

Hm, ich muss sagen, das rockt (Screenshot auf NTSC)

Natürlich ist JETZT erst mal die komplette Spiellogik kaputt weil die Screencodes komplett durcheinander sind, aber das lässt sich ja fixen. Extraschnelles Scrolling für "sich umschauen" -- scheint jetzt machbar wirklich sehr cooler Trick!

Squidward · 30. Januar 2023

Zitat von Zirias/Excess

Zitat von oobdoo

Was ist das?

Naja, sowas wie eben !for oder .repeat.

Unnötiger Scheiß. Das ist der Grund, warum viele gerade zu Anfang nichts mit Assembler-Beispielen anfangen können und wieder quiten. Das mag Quality of Life Improvement sein, aber Assembler ist das nicht...

Zirias/Excess · 30. Januar 2023

Blödsinn, aber ganz massiv.

Endurion · 30. Januar 2023

Seid lieb, sonst gibt's auf Auge

Squidward · 30. Januar 2023

Ich hab doch schon einen Engel-Smiley gesetzt, mehr kann ich die Fakten nicht verpacken.

Zirias/Excess · 30. Januar 2023

Mit "Fakten" hat das trotzdem nichts zu tun, "Assembler" ist eben mehr als nur n "besserer Monitor". Klar kann man alles von Hand runterhacken, selbst im Monitor, oder meinetwegen sogar mit ner Opcode-Tabelle auf Papier. Auch nur halbwegs bei nem komplexeren Projekt den Überblick behalten ist so aber nicht drin.

Squidward · 30. Januar 2023

Nein. !For steht wahrscheinlich in keinem Assembler Buch, und schon gar nicht in einem Lern-Tutorial. Und kein Anfänger freut sich, wenn er neben der Assembler-Logik gleich noch weitere Prä-Compiler Logik verstehen muss, die dann auch noch "von Compiler zu Compiler" anders sein kann.

Ich habe es oft genug erlebt, dass Anfänger zu Code-Beispielen dieser Art gelinkt werden, mit denen sie dann nichts anfangen können. Meine Aussage von oben stimmt genau. Das kriegt man vielleicht nicht mehr mit, wenn man nur noch unter Veteranen codet...

Endurion · 30. Januar 2023

Musst du den KickAssembler lieben

Zirias/Excess · 30. Januar 2023

Zitat von Endurion

Musst du den KickAssembler lieben

Ganz ehrlich, was DA alles an abgefahrenem Scripting-Krempel drinsteckt finde ich auch grenzwertig, das ist mehr n "Toolkit zur Berechnung von Demo-Tabellen" als n Assembler

Aber die Argumentation bleibt trotzdem unsinnig. Ein brauchbares "Assembler-Buch" erklärt selbstverständlich auch Makros und anderen Präprozessor-Kram inklusive wofür man das sinnvollerweise einsetzt. Natürlich am Beispiel von EINEM Assembler. Aber wenn man das Prinzip mal verstanden hat ist es wirklich keine Raketenwissenschaft, sich mal das Manual von nem anderen Assembler zu Gemüte zu führen ....

Hoogo · 30. Januar 2023

Ich erinnere mich, dass ich das Anfangs schon unverständlich fand: Assembler hat keine Variablen, und dann gibt es "Assembler", und der hat dann doch wieder Variablen... Aber ich glaube nicht, dass das länger als 1 Woche ein Rätsel war.

Aber für den absoluten Einstieg würde ich auch erstmal Monitor nennen.

Btw: Was macht eigentlich Roland?

Squidward · 30. Januar 2023

Zitat von Endurion

Musst du den KickAssembler lieben

Ja, den mag ich wirklich nicht

Map effizient auf Screen abbilden

Ähnliche Themen

XT/DOS Emulator auf C64?