Posts by mrsid

    Meine zweite Frage wäre wo ist der Einsprungspunkt im Spiel (sonic 1v2) wo der VIC (rasterIRQ, D018 usw) und CIAs auf richtige Werte gesetzt werden.

    $07ff setzt das voraus und 03F8 crashd nach dem entpacken des Spiels.

    Das wird so nicht funktioneren. Der Einsprungspunkt ist bei $0340, aber der Code der das Spiel initialisiert wird später mit anderem Code überschrieben, aus Platzgründen. Damit wirst du also nicht weit kommen. Du müsstest das Hauptprogramm entpacken, patchen und neu packen.

    Könntest du mal ein Interview machen auf Deutsch wie das mit der Toolchain funktioniert.

    Nein, keine Lust.


    "wie hat er all das im Vice und ACME gemacht und vorallem getestet?"

    Ganz einfach nicht ACME verwendet...


    Am Ende war das Programm weit länger und 5x langsamer geworden... Schade

    müsste noch ein Optimizer bauen aber das ist mega Zeitaufwändig...

    Drum hab ich's gleich von Hand gemacht.

    Danke Mr. Sid. - Was ich seit gestern gesehen habe ist das nicht nur das Coolste Spiel am C64 auch eines der komplexesten.

    Aus meinem kleinen test -> "gehts am NeoRam?" ist ganz schön viel arbeit geworden ...
    Bastel noch am REU Emulator. Stress mit pagegrenzenüberschreitung... was mich am meisten wundert ist warum mein Level immer bei dem Totem beginnt (bei der Kugelrinne) seit ich meinen Emulator verwende. Wenn ich auf 03f8 springe beginnt das Spiel wieder dort ?
    wo weiß das Spiel welchen Scrollschirm der Sonic aktuell ist ? Würde gerne ganz links im 1. Schirm beginnen...

    und was macht der 9c00 Bereich genau ?

    Du hast wahrscheinlich die Start position von Sonic überschrieben...$a00d/$a00e ?


    Bei $9c00 liegt eine Tabelle mit den Lo-Bytes für jede Zeile in der REU. Bei Levels die 256 Blöcke breit sind (z.b. Level 1) sind dort nur 00er, aber in anderen Levels schaut das anders aus. D.h. nicht unbenutzt.


    Und ja, das Spiel ist sehr gross und komplex. Ich hab mir eine komplett neue Toolchain basteln müssen, damit ich die Datenmengen gut managen, konvertieren und verwalten kann. Sonst hätt' ich da nicht die Übersicht behalten können...

    Grad einen freien Platz bei 9c00 gefunden 256 byte... und gleich nach sterben wird der Bereich aus dem Georam überschrieben grrrr !

    Dort liegen Tabellen. Wie gesagt, es ist fast kein Platz. Der Bereich bei $a000 ist die Levelbeschreibung. Bei weniger Gegnern im Level ist dort ein wenig Platz, aber auch nicht wirklich. In manchen Levels ist das weniger.

    Der einzige Ort den ich noch nicht verwendet hab ist der untere Teil vom Stack. Ich denke der wächst nicht sehr weit nach unten, d.h. von $0100 bis ca. $01c0 oder so sollte frei sein.

    Also mal eben 12.000 Zyklen (von den ca. 19500 eines Videoframes), wenn der gesamte Bildschirminhalt ausgetauscht wird, also beliebig schnelles Scrolling (Transportation).

    Was aber die Frage offenlässt, wie viel Zeichen man im Worst-Case wirklich schreiben müsste.


    Nicht mal Sonic scrollt so schnell, dass wirklich der gesamte Bildschirminhalt von einem Frame zum nächsten mit Hardwarescrolling neugefüllt werden müsste (dann könnte man im Prinzip gar nicht mehr nachverfolgen, wohin eigentlich gescrollt wird.)

    Guckst du:

    https://youtu.be/NRnDbxvxi-o?t=249

    Hier ein Beispiel Frame:



    Weiss ist Update der Game Entities, also in dem Fall Sonic, der Crabmeat Gegner, der Monitor und die Plattform (da sind auch Interrupts dazwischen, z.b. vom Multiplexer und für die Musik, etc.).

    Rot ist das HUD (in diesem Frame ändert sich keine Zahl, d.h. fast nix zu tun).

    Cyan ist Sprites updaten und sortieren.

    Grün ist Screen Update, also kopieren von REU. Dazwischen sind aber Interrupts vom Multiplexer und dergl.

    Blau ist Charset Update, d.h. kopieren von Animationen aus der REU

    Gelb ist das Kamera Update.

    Lila ist der Check welche Entities im nächsten Frame aktiviert werden müssen, bzw. welche deaktiviert werden können.

    Als DAU/noob kann ich da zwar nicht mitreden, aber da es ja etliche GEORam Nachbauten, Originale und NeoRAM's gibt, wäre so eine "Portierung" ja schon ne feine Sache - was könnte man denn ggf. machen (Abstriche zur REU-Portierung), um es doch per Neo/GEO-RAM zum Laufen zu kriegen?

    Lass dich nicht von dem hier irritieren. Ich würde mir da keine Hoffnung machen...

    Ja klar kann sie ins FarbRAM schreiben (kann ja auch in I/O schreiben, z.b. $d418).

    Allerdings kann das nicht in einem Transfer passieren, d.h. es wird zeilenweise geschrieben, und zwar abwechselnd Video und Farb RAM (damit man immer vor dem Rasterstrahl bleibt, weil oft beginnt das erst kurz vor Rasterzeile 50). Nach jeder Zeile müssen einige Register neu gesetzt werden, dadurch wird etwas an Bandbreite verbraten.


    Der grösste Teil ist allerdings die Logik von Sonic und den anderen Entities, gerade wenn mehrere davon sichtbar/aktiv sind, braucht das gut mehr als ein Drittel vom Frame, u.U. mehr wenn die Gegner alle auch mit der Welt kollidieren können.

    Dann natürlich noch das übliche wie Sprites sortieren, Musik, die REU transfers für die Sonic Sprites, das Zeichnen von Zahlen in die HUD Sprites, das Kamera Update (Bewegung, Interpolation, Clipping, etc.), die Entity Aktivierung/Deaktivierung, die Charset Animationen von Wasser und dergl.,

    ja der Code ist nicht optimiert ich weiss, war ein test zu schauen ob es mit georam auch geht- aber warum geht das Links / Rechts Scrolling eigentlich nicht ? Was ist da anders ? werden die Screens nicht per Index Variable (0 - ff) in den Videoramgeladen wobei der Index angibt in welcher spalte vom Bild wir beginnen ?

    Nein, wozu eine Index Variable? Die REU schreibt ja direkt ins Video RAM, also braucht man das nicht. Das liegt alles in der Berechnung der Adressen in REU und C64 RAM. Und wenn du immer 256 Bytes kopierst, wirst du irgendwo was überschreiben. Und es gibt REU Transfers die länger als 256 Bytes sind, d.h. du musst das ganz anders machen. Und natürlich wird auch in die REU geschrieben, d.h. wenn du das nicht machst wird gar nix lange funktionieren... Wie gesagt, das ganze ist sinnlos, aber viel Spass noch. :)

    So ein Blödsinn... Wie stellst du dir vor das das dann funktioniert, wenn das Spiel jetzt schon fast keine Rasterzeit mehr frei hat?

    Die Kopierschleife in georamreu.asm wird dafür nicht ausreichen, d.h. 25fps vielleicht. Und der Code kann aber noch kleiner sein, da verschwendest du etliche Bytes...

    Wo habe ich im Speicher noch platz für 192 bytes ? egal wo ich schaue alles wird anscheinend permanent überschrieben....

    Habe bei 0200, 8800,e040 usw probiert keine chance.

    Wozu brauchst du 192 bytes? Es ist praktisch nix frei, also das wird schwierig. In der REU ist noch ein wenig Platz, da kann man evtl etwas hin- und herkopieren, aber das ist eher kompliziert...

    Sieht nach wie vor danach aus das Bit 2 in den unteren 4 Banks defekt ist, also würde ich U4 tauschen.