Posts by Acorn

Gerade so aufgefallen bei Arkanoid, der Ton im Titelmenü startet verspätet bei diesem Spiel. Habe verschiedene Version vom Spiel ausprobiert, aber alle spielen den Ton verspätet ab, wenn man Chamberlin auswählt.

Um mal einige Fragen hier zu beantworten.

Mit einer REU könnte man Boulder Dash beschleunigen, so das zusätzlich das Farb-RAM voll nutzbar ist und es wäre sogar noch viel mehr Rechenzeit für die Original Engine übrig. Meine Meinung nach ist eine REU aber gar nicht notwendig, wenn man eine schnelleren Engine verwendet.

Die Ausmaße des Spielfelds in XY sind nicht entscheiden, sondern die Gesamtanzahl der aktiven Objekte im Cave. Eine schnellere Engine könnte genug Rechenzeit für das Farb-RAM freischaufeln.

Mit VSP und Co kann man das Scrollen nicht beschleunigen, da laufend der Bildschirmspeicher aktualisiert werden muss. Eine Speedcode-Routine könnte den Bildschirmspeicher schneller beschreiben und beim Aktualisieren kann man jedes zweite Frame auslassen.

Für das Programmieren einer BD-Engine braucht man bestimmt kein Professor der Physik, dafür reicht ein schnöder Hauptschulabschluss aus.

Die Engine in Assembler:

Die Original-Engine ist eher auf Speicherplatz als auf Geschwindigkeit getrimmt. Der Atari hat effektive auch (deutlich) mehr Takt als der C64. Beim C64 läuft die Engine schon am Limit und teilweise darüber.

Ausblick:

In der Basic-Version für den Mega65 habe ich die Original-Engine von BD-II nachgebildet, das Verhalten der Cave ist identisch. Im Prinzip ist die Engine auch nicht so komplex wie einige hier meinen, siehe Sourcecode.

Optimierungen der Basic-Version:

Da das Basic selbst auf dem Mega65 extrem langsam ist, sind einige Ideen rund um die Engine entstanden. Z.B. nur alle aktiven Objekte eines Cave zu erfassen und das die Engine von unten nach oben abläuft. Leider kommt es dadurch insgesamt zu Abweichungen beim Ablauf.

Für echte BD-Fans kommt so etwas natürlich nicht in Frage und für mich auch nicht. Also müssen andere Mittel und Wege gefunden werden, wie kompletter Jumpcode, aktive passive Objektwechsel, momentan nur bei der Amöbe. Noch nicht umgesetzt aber angedacht, unmöglich erreichbare Levelbereiche überspringen.

Es ist also durchaus möglich das Farbram mit vier weiteren Farben in vollen Umfang zu benutzen um die Optik stark aufzuwerten.

Wer sich das Basic-Dash mal anschauen will, sollte sich einfach den Mega65 Emulator herunterladen, leider muss man sich das Romfile selbst zusammen fummeln. Bis ROM 920377 kann man einfach per Drag-and-drop das Basicfile auf dem Emulator ziehen, bei neueren Roms ist zurzeit den Umweg über ein D81 Image nötig.

Ich habe leider vom SID 6569 so gut wie keine Ahnung, ich glaube, so geht es den meisten hier. Es ist heute relative selten, das sich ein Coder auch gut mit SID/CO auskennt, umgekehrt die Musik/FX Leute mit dem Coding selber auskennen. Aber BeRo der Programmierer des Micro64 Emulator, könnte bestimmt viel zum Thema schreiben. Hätte damals kurz mit ihm über das Forum hier Kontakt als er noch aktive beim Entwickeln des Emulator war. Dabei ging es unter anderen um die Titelmusik von Wizball, die mit einer späteren Version des Emulator etwas schräg klang. Daraufhin baute er im Emulator die Option SID brightness ein, damit klingt der Tune bei 75% wieder OK. Wenn ich mich nicht irre hat er auch Beruflich mit Musik zu tun, leider ist er nicht mehr aktive. Aber der Coder PiCiJi von Denise hier im Forum, könnte bestimmt etwas dazu schreiben. Verlink doch mal deine Frage hier.

Denise 1.0.x Emulator

Quote from 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.

Quote from 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.

Genau genommen dürfen nicht mehr als 16 Zeichen dieselbe Farbe haben, ansonsten geht das dank der 4-Bit beim Farbram.

Es gibt ja nicht nur die Code-Optimierung, sondern auch noch die Zugriff/Daten-Optimierung. Wenn für die Map nur wenige Zeichen verwendet werden, könnte man die Zeichen auch entsprechend der Farbe im Zeichensatz ablegen. Dann kann man die Farben ohne Tabellenzugriff direkt ins Farbram schreiben, kommt ohne den Illegalen Opcode LAX oder TAX aus und spart so weitere 4 oder 6 Takte pro Zeichen ein. Außerdem sollte man dafür sorgen, dass die Routine in einer Page liegt, sonst kosten CC-Sprünge eventuell ein Takt mehr beim Ausführen.

Die Routine für die Bildschirm / Farbram-Adresse kann man zusammen legen und optimieren.

Es geht auch ohne Kopieren des Programms nach $C000.

Mit seinen 16-Bit Registern kann der Z80 beim Füllen seine Muskeln spielen lassen, in Takte gerechnet ist der Z80 hier schneller als der 6502.

10 Takte -> POP HL

13 Takte -> DJNZ

Schleife

23*500/2 MHz = 5750 Takte

25*250/1 MHz = 6250 Takte

Speedcode

10*500 = 2500 Takte

4*1000 = 4000 Takte

Das ganze zeigt auch, wie man in Assembler ineffektiven 6502 Code schreiben kann. Es ist wie Claus schon geschrieben hat, in der Hauptschleife auf das Y-Register zu verzichten, kostet halt richtig viel Zeit. Im direkten Vergleich benötigt die Routine von Snoopy auf dem C64 26,83 Sekunden und damit genau 12 Sekunden mehr als meine. Ohne den selbst modifizierenden Code wird 1 Takt mehr in der Schleife benötigt, ist aber immer noch 10.7 Sekunden schneller.

Ich vermute der Z80 hat hier auch eher ein bestcase und kann deshalb mit seinen vielen Register besonders gut Punkten. So das der doppelte Takt des Z80 ungefähr ausreicht, um mit dem 6502 gleichzuziehen. Eine vergleichbare ausgerollte Routine wie von gogoMAK auf dem Z80 wäre jetzt mal interessant. Ich glaube, der Abstand zum 6502 wird eher großer als kleiner.

In beiden Routinen hat sich ein kleiner Fehler eingeschlichen, die innere Schleife von 40 stimmt nicht.

Ich versuche mal das ganze vereinfacht zu erklären, was für uns Menschen rasend schnell ist, kann in Wirklichkeit ziemlich langsam sein. Deshalb gibt eine zeitliche Differenz zwischen Ändern (CPU) und Ausführen (VIC-II) auf dem Bildschirm. Das Ändern der Sprite-Koordinaten durch die CPU verändert die Position nur indirekt. Erst wenn der VIC-II mit dem Zeichnen des Sprites beginnt, werden die neuen Registerwerte verwendet. Das gilt für alles, was auf dem Bildschirm angezeigt wird, egal ob Text/Grafik oder Sprites. Ein Text ist auch erst sichtbar, wenn der Rasterstrahl (VIC-II) die Pixel ausgeben hat. Würde der Text vor der Ausgabe auf dem Bildschirm wieder gelöscht werden, wäre auch kein Text zu sehen. Genauso verhält es sich mit allem anderen was direkt auf dem Bildschirm passiert.

Die Lösung für das Problem wurde hier schon genannt, man wartet einfach bis die Ausgabe auf dem Bildschirm abgeschlossen ist.

Nicht böse gemeint, aber das wäre nur ein weiteres drum her rum.

Es wird wahrscheinlich schon ausreichen, wenn es nur -B -W -L zum Überspringen gibt. Die eckige Klammer habe ich nur Vollständigkeitshalber verwendet, damit man alle Fälle abdecken kann. Beim 65816 könnten es sich das noch mehr lohnen mit B / W / L zu arbeiten. Einmal, weil es die Lesbarkeit des Sourcecode erhöht und beim Debuggen hilfreich sein kann.

Quote from Endurion

Selbst mit der [x]-Notation hätte ich glaube ich Probleme mit dem 4510 beim Mega65, da wird die eckige Klammer für 32-Bit-Varianten eingesetzt.

Eventuell ist die geschweifte Klammer noch frei.

Quote from Endurion

Wäre so etwas denkbar, man schreibt quasi Dummy-Werte in der gedachten Notation, das ! nach dem Opcode sagt dann, dass nur das Opcode-Byte selbst eingesetzt wird:

Das ist erstmal alles ein grober Entwurf gewesen, da fehlt noch der Feinschliff.

Quote from Endurion

wobei das noch ohne Berücksichtigung von 65816 ist. Da gibt es dann vermutlich noch ein paar komplexere Varianten, da würde ich dann +B/+W/+L dazunehmen:

Das ist gut möglich, man müsste erstmal schauen was alles für den 65816 gebraucht wird.

Quote from Endurion

LDA-B! LDA ($00)

Damit der Programmierer direkt sieht, das der Akku gerade 16-Bit breit ist, der Opcode ist natürlich identisch.

Mac Bacon

Mir ist natürlich klar das man das nicht so häufig braucht, als Beispiel hätte ich meine optimierte Tastaturabfrage aus meinen Coder-Kernal. Ich hatte aber auch schon einen CC-Code verwendet, um 1 Byte zu überspringen, nur um ein Takt einzusparen und nebenbei kein Flag zu verändern.

Da jetzt die Zeit der vielen Wünsche ist, bin ich mal so unverschämt und hätte davon ein zwei viele.

Vorab C64-Studio gehört zu einem meiner wichtigsten Programme auf dem PC, dafür nochmal ein dickes DANKE Endurion, das kann man gar nicht oft genug wiederholen. Du hast da echt ein tolles Tool entwickelt, damit macht es echt Spaß Programme zu schreiben. Falls diese Wünsche nicht oder nur schwer umsetzbar sind, ist das nicht ganz so tragisch.

Jetzt aber der ungewöhnliche Wunsch.

Es gibt eine Sache, die mich extrem stört, und zwar wenn man mitten in seinen Sourcecode ein !BYTE einbauen muss. Das passiert immer dann, wenn man mit einem Opcode andere überspringen will, in der Regel muss ich dann erst erstmal nachschauen welches Byte dieser Opcode belegt. Dabei gibt es eine ganz einfache Lösung, das sogar ein paar andere Probleme beseitigt und gerade beim 65816 nützlich wäre. Nebenbei könnte auch der Disassembler davon profitieren, weil dieser besser lesbaren Sourcecode erzeugen könnte. Im C64-Studio steckt es praktisch schon drin und müsste nur erweitert werden, damit meine ich das Anhängen von +1 und +2, um die Länge der Folgebytes festzulegen.

Meine Idee:

Am Opcode einfach -1 oder -2 hängen und schon erzeugt der Assembler den Opcode ohne Daten, für den 65816 müsste man das noch auf -+ 3 erweitern. Zusätzlich wäre noch -+B -+W -+L denkbar und gefällt mir Persönlich noch viel viel besser, wäre fast wie beim 68K.

Leider kann man nicht alle Opcodes eindeutig erzeugen, dafür müsste man das noch leicht erweitern. Optional könnte die eckige Klammer zusammen mit einem Buchstaben genommen werden.

Es besteht die Möglichkeit und besonders beim 65816, das noch nicht alles komplett abgedeckt wird.

C64 Kernal -> Disassembler Sourcecode

Rücksprung Meldungen des Betriebssystems ausgeben

Adresse -> $F6FB

Der nächste Wunsch liegt praktisch auf der Hand, natürlich Unterstützung für dem 65816. Die ist schon im 6502-Mode extrem schnell, gerade bei Amica-Paint schlägt das voll durch. Wer weiß was noch alles im Native-Mode mit 16-Bit Register möglich ist.

Habe mal die Einträge von der Registry abgespeichert, vielleicht funktioniert das direkte hinzufügen durch einen Doppelklick auf die Datei.

Ich hatte dasselbe Problem mit den Tasten, müsste alle Tasten neu belegen. Das war gar nicht so einfach, da man die Taste Punkt und Komma nicht zuweisen kann.

Habe die zwei Tasten dann direkt in die Registry eingetragen.

Hier mal meine Config, entspricht der Tastenbelegung von Vice. Einfach in Hoxs laden und dann in der REG abspeichern, Menüpunkt -> Settings -> Save Settings -> Save To Registry.

Eigentlich würde schon alles gesagt, aber wie heißt es so schön, viel hilft viel oder nach fest kommt ab.

Genau genommen verhält sich das Kollisions-Register so. Sobald es beim Zeichnen der Sprites eine Überlappung der gesetzten Pixel gibt, werden die Bits der beteiligt Sprite im Register $D01E vermerkt. Sollten sich viele Pixel der Sprites überdecken, werden auch laufend die Bits im Register $D01E gesetzt! Wenn sich mehrere Sprites in derselben Rasterzeile befinden, kann man selbst in Assembler nicht schnell genug auf die Kollisionen reagieren. Deshalb werden die Bits im Register erst beim Auslesen gelöscht, damit keine der zu diesen Zeitpunkt ausgelösten Kollisionen verpasst wird.

Sind mehr als zwei Sprites im Register eingetragen, kommt man ohne einen Koordinatenvergleich nicht aus. Bei Multiplexer Sprites steigt der Aufwand nochmal weiter an, da kann es sinnvoll sein, nur den Koordinatenvergleich zu verwenden.

Zum Testen könntest du meine Version von Boulderdash nehmen, diese sind für Joystick-Port 2 ausgelegt. Außerdem enthält das Archiv eine Plus-Version, da BD I nicht 100% auf PAL funktioniert.

Boulder Dash

Den Screenshot nach zu urteilen benutzt du einen Emulator. Dadurch hast du direkten Zugriff auf alle Daten vom C64. Das ist ein Riesenvorteil, weil du das Basic Programm zusammen mit dem Zeichensatz und die Sprites einfach mit Exomizer packen kannst.

Die Packzeile für die Eingabeaufforderung (CMD) D:\exomizer.exe sfx basic D:\basic-programm.prg D:\sprites.prg D:\zeichensatz.prg -n

https://bitbucket.org/magli143/exomizer/wiki/Home