C128 Portierungen

Zitat von ZeHa

Hat nicht Rocky Horror Picture Show auf dem C128 farbigere Grafik usw? Nutzt das irgendwelche C128-Features aus? Oder hatten die die C64-Version voreilig rausgebracht und dann einfach ein bisschen aufgehuebscht fuer die C128-Version? Weiss da jemand was genaueres?

Zitat von https://en.wikipedia.org/wiki/The_Rocky_Horror_Show_(video_game)

There were separate versions of the game released for C64 and C128. The former was a straight ZX Spectrum port while the latter featured completely reworked graphics with more detailed characters and more colourful backgrounds. In the game itself there were a few new locations to be found.

Zitat von sparhawk

Und wenn ich mir das so ansehe, dann sollte es doch vergleichsweie einfach sein, seine C64 ASM Programme auch auf dem C128 zum Laufen zu bringen, oder sehe ich da was falsch?

Der IO Bereich z.B. liegt ja auch auf $D000 und ist weitgehend kompatibel.

Der Meinung war ich auch, bevor ich angefangen habe, mal auf der Kiste ein paar "Gehversuche" in Assembler zu machen. Bei $D000 liegt RAM, wenn man ein Assembler-Programm startet.

Wenn man bei $D000 I/O haben möchte, muss man die MMU so programmieren, dass bei $D000 auch wirklich I/O eingeblendet wird. Selbiges gilt auch für die ROM Routinen: ohne MMU läuft da nicht viel. Wenn Du also was im C128 Modus machen willst, musst Du mit der MMU anfangen.

Und die "Bibel", die Du suchst, ist das "C128 Programmer's Reference Guide". Gibt's als PDF im Netz.

Es ist nicht sehr schwierig, ein C64-Programm auf den 128er-Modus zu portieren. Allerdings muss man sich fragen, was das bringen soll. Im C128-Modus steht viel mehr Speicher zur Verfügung, die Floppy ist viel schneller. Das sind zwei konkrete Vorteile. Aber man braucht sowieso einen Fastloader für den C64, und wenn man sowieso einen Fastloader für den C64 schreiben muß, ist dieser Vorteil für den C128 verloren. Überreste, mehr Speicher. Das kann durchaus nützlich sein, zum Beispiel kann man mehr mit Bitmaps machen oder ein größeres Spielfeld in ein Spiel einbauen. Aber das erfordert harte Arbeit, und das ist die eigentliche Aufgabe der Unterstützung der C128.

Es ist viel einfacher, ein C64-Spiel mit C128-Fähigkeiten zu verbessern, der 2MHz-Modus, die Tastatur und der VDC sind alle im C64-Modus verfügbar und erforderen daher keine Portierung.

Meiner Meinung nach gibt es noch einen weiteren Vorteil des C128 und zwar, dass C128-Code oft kürzer ist als C64-Code, und für die C128-Entwicklen daher Zeit spart. Aber... Auch hier ist es keine Option, den C64 nicht zu unterstützen, also kann man nicht ausschließlich für den C128-Modus entwickeln.

Zitat von dmantione

dass C128-Code oft kürzer ist als C64-Code

Erkläre das bitte mal genauer. MMn ist dem nicht so.

Bezüglich C128 "an sich", da hatten meine Computerkumpels damals in der Schule gemeint als der C128 rauskam, "Schön, aber blöd daß die 2 CPUs nicht parallel arbeiten können".

Zitat von SvOlli

Bei $D000 liegt RAM, wenn man ein Assembler-Programm startet.

Ähhh... nein. Genau wie beim C64 ist der Default "ROMs und I/O aktiv". Beim 128er heißt diese Konfiguration "BANK 15". Wenn man allerdings "BANK 0:SYS wasauchimmer" eingibt, oder im eingebauten Monitor eine Adresse ohne führendes F (für Bank 15) anspringt, ja, dann ist "BANK 0" aktiv und dann sind die I/O-Chips ausgeschaltet.

Das ist aber keinen Deut schwieriger als beim C64, nur schaltet man eben die Konfiguration nicht über Speicherstelle $01, sondern über Speicherstelle $ff00 um.

Zitat von m6502

Zitat von dmantione

dass C128-Code oft kürzer ist als C64-Code

Erkläre das bitte mal genauer. MMn ist dem nicht so.

Es gibt viele kleinere Beispiele, ich gebe dir eines: Versuche es zum Beispiel eine Datei an der Adresse $D000 in Code zu laden, der an der Adresse $F000 läuft.

Auf dem C128 ist das ein Kinderspiel: JSRFAR auf LOAD in Bank 15.

Auf dem C64 hat man das Problem, daß man von $F000 aus nicht das KERNAL aufrufen kann und dann das Problem, daß die LOAD-Routine nicht nach $D000 schreiben kann. Man muß auf dem C64 ein Trampolin schreiben, das die KERNAL sichtbar macht, dann LOAD aufrufen und die Datei in einen temporären Puffer laden und dann nach $D000 kopieren.

Ein weiteres Beispielchen: Cartridge-Initialisierungscode auf dem C128 ist viel einfacher als auf dem C64:

Beim Coden für den C128 bin ich immer ambivalent.

Einerseits gilt: C128 > C64

Andereseits habe ich immer das Gefühl, ein C128er-Programm muss Features verwenden die am C64 nicht möglich wären. Und dann ist man ziemlich eingeschränkt und plagt sich mit VDC oder Z80 ab. Am besten ist er eigentlich für Anwendungsprogramme geeignet, wäre die optimale Plattform für Zeichenprogramme, Kopierprogramme, Packer, Textverarbeitungen oder Entwicklungsumgebungen die Compiler, Quellcode und Compilat gleichzeitig im Speicher haben. Aber dafür haben wir jetzt Cross-Development-Tools auf Windoof und Linux...

Naja also ich hab nie einen C128 besessen, von daher bin ich da vielleicht auch etwas voreingenommen, aber wenn Spiele auf dem C128 eigentlich exakt gleich aussehen wie auf dem C64, und allenfalls von etwas mehr CPU-Power und Speicher profitieren koennten, dann wuerde ich als Spieleprogrammierer wohl trotzdem versuchen, mein Spiel fuer den C64 zu schreiben, weil ich dann einfach eine viel groessere Zielgruppe habe (4 Mio vs 18 Mio verkaufte Einheiten?). Je nach Spiel koennte man optional eine C128-Version anbieten, die z.B. weniger nachladen muss oder in der ein paar Dinge fluessiger laufen, aber grundsaetzlich saehe ich keinen Sinn darin, ein Spiel speziell fuer den C128 zu machen, wenn es am Ende trotzdem "nur" wie ein C64-Spiel aussieht.

Dementsprechend wird es nicht mal wirklich viele "C128 enhanced"-Versionen von C64-Spielen geben, weil es nicht viel zu "enhancen" gibt. Haette der C128 mehr Farben, mehr Sprites, weniger Farb-Limitierungen oder sowas in der Richtung, dann wuerde es vielleicht mehr Spiele geben, die diese Features nutzen.

Ich denke in erster Linie wären beim C128 Anwendungen sinnvoller als Spiele.

Z.B. Dateimanager, Textverarbeitung usw. Programme bei dem der VDC und

die zusätzlichen 64K Sinn ergeben.

Eine Entwicklungsumgebung fuer C64-Spiele waere evtl auch eine feine Sache.

Zitat von ZeHa

aber grundsaetzlich saehe ich keinen Sinn darin, ein Spiel speziell fuer den C128 zu machen, wenn es am Ende trotzdem "nur" wie ein C64-Spiel aussieht.

Ich verstehe genau, was Du meinst, und ich habe nochmal an das C128-Spiel "Volley For Two" (2020) gedacht, dass ich im anderen Thread vor ein paar Tagen angesprochen habe. Die Frage ist: Was ist hier grundsätzlich anders als bei einem C64-Game? Was kann man auf einem C64 nicht so leicht schaffen?

Ich behaupte mal, dass der Entwickler sich sehr viel Mühe gegeben hat, beim Laden des Spiels schon zu einem möglichst frühen Zeitpunkt Intro-Bilder mit Credits und Fade-Effekten zu bieten. Ja, ok, das macht wahrscheinlich Sam's Journey genauso gut und andere C64-Spiele auch. Aber die ganze verpackte "Experience" des Spiel-Ladens am C128 ist eher "modern" und man sieht keine typischen C64-Lade-Artefakte wie einen halb gefüllten Screen, wo noch Daten im Bildschirmspeicher gepuffert werden. Man sieht anständige Fortschrittsbalken, man kriegt Vorspann-Screens. Auf dem zweiten Screen gibt es schon eine Infozeile, der liegt nicht brach. Und über eine 1571 kann man mit dem 1571-Image wahrscheinlich das Spiel autobooten oder mit "boot" starten.

Das hat natürlich nichts mit dem Spielspaß des Spielprinzips direkt zu tun, aber das Coole ist, es wirkt so selbstverständlich, wenn man zuschaut, und das, obwohl es auf dem C128 sonst kaum Spiele-Releases gibt. Man kann nur hoffen, dass so ein Loading-System dann für zukünftige C128-Releases des Entwicklers weiterverwendet wird.

Auf der anderen Seite ist die Frage: Wer von den joystick-bereiten Retrogamern hat Volley For Two tatsächlich in der Praxis gespielt? Erstmal braucht man zwei menschliche Spieler, dann braucht man einen C128, am besten einen zweiten Screen am C128 (oder halt Emulator). Wenn man als Spiele-Entwickler gern viel Feedback bekommt, dann entwickelt man halt für den C64, weil da viel mehr Leute das Spiel ausprobieren. Wenn man aber wegen der technischen Herausforderung / um des Lernens willen entwickelt, dann kann es auch mal ein C128-Game werden.

Da ich das Laden des Spiels von 1581 damals gefilmt hat, setze ich zur Illustration nochmal den Youtube-Link dazu.

Zitat von ZeHa

Eine Entwicklungsumgebung fuer C64-Spiele waere evtl auch eine feine Sache.

Das fände ich auch super. Dafür wäre der 128er doch sehr gut geeignet. Programmmodule wie Sprite- und Chareditor in die REU laden.

Man könnte so alles unter einem Hut bringen. Bank 0 für die IDE und Bank 1 für das 64er Game.

Das ganze Bedienbar mit der 1351 und fertig ist DIE C128 Killeranwendung.

Spannende Diskussion. Mein zweiter Computer nach dem C16 war ein C128d und für mich war das Upgrade von BASIC 3.5 zu BASIC 7.0 grandios, besonders die Sprite Routinen haben mir bei meinen ersten eigenen Spielen enorm geholfen.

Vor einiger Zeit hatte ich eines meiner Lieblingsspiele vom C16, Ghost Town, auf den C64 portiert:

http://www.kingsoft.de (ja ich weiss und nein, ich habe keine Sorge vor Abmahnung )

Dabei habe ich auch über das Für und Wider einer C128 Version nachgedacht und kam zu dem Schluss, dass es sich in diesem Fall (Single File) nicht lohnt, was wirklich schade ist, weil sich für mich so ein Kreis geschlossen hätte.

Vielleicht hat ja jemand Lust, Ghost Town auf den C128 zu portieren?

https://github.com/Esshahn/Ghost-Town

Ich glaube was wir brauchen, ist eine Datenbank/Übersicht von interessanten Code Snippets und Konzepten, die eine dedizierte C128 Version aufwerten würden. Dabei muss es nicht immer ein Hardwarefeature sein.

* Durch den Fast Mode im Border spart man z.B. Rasterzeit, welche man in der Folge z.B. für aufwändigere Effekte nutzen könnte, z.B. bessere Gegner-KI, Rasterbars statt einfarbigem Himmel, Digi-Drums usw.

* Den größeren Speicher könnte man nutzen, um zeitkritische Loops auszurollen, was zumindest bei Demo-Effekten nicht unrelevant ist.

* Das Double Buffered Color RAM ist ebenfalls eine feine Sache und beschleunigt Scrolling-Routinen oder erlaubt nette Demo-Effekte, die so deutlich zeitsparender arbeiten (und schon wieder ist weitere Rasterzeit gespart).

Ich glaube man kann schon eine Menge herausholen, nicht mit neuen Features, sondern mehr von dem, was vorher möglich war. Toll wären auch Code Snippets, die zuverlässig einen C128 detektieren und man so andere Subroutinen aufrufen kann. Wenn ich mich recht erinnere, ist der BASIC Start beim C128 nicht bei $0801, daher vermute ich es ist nicht trivial, _ein_ PRG für beide Plattformen zu compilen, aber es wäre natürlich extrem cool, wenn man sich entscheiden könnte, ob man das PRG im C64 oder C128 Modus startet.

Zitat von MC64

Zitat von ZeHa

Eine Entwicklungsumgebung fuer C64-Spiele waere evtl auch eine feine Sache.

Das fände ich auch super. Dafür wäre der 128er doch sehr gut geeignet. Programmmodule wie Sprite- und Chareditor in die REU laden.

Man könnte so alles unter einem Hut bringen. Bank 0 für die IDE und Bank 1 für das 64er Game.

Das ganze Bedienbar mit der 1351 und fertig ist DIE C128 Killeranwendung.

Für mich wäre es irgendwie "witzlos", den C128 zum Entwicklen für C64-Spiele zu benutzen.

Entweder ich entwickle direkt auf dem C64 (wer es so wirklich 100% Retro haben will) oder dann gleich auf einem modernen PC mit allen Vorteilen wie Emulatoren, Entwicklungsumgebung usw..

Das wäre damals^tm vielleicht noch eine "Killeranwendung" gewesen, aber heutztage wohl eher nicht mehr.