#38 – Doctor V64 – IV – saving

Ding! Ding! Ding! Auf geht’s in die vierte Runde! 😉

Ein weiteres Thema, welches wir beim letzten Mal noch komplett ausgeblendet haben, ist das Speichern von Spielen. In Artikel 32 haben wir ja bereits gelernt, dass N64-Spiele sehr unterschiedliche Speichertypen besitzen!

In folgender Grafik habe ich versucht, die verschiedenen Speichermethoden etwas aufzuzeigen:

a

Der Großteil der N64-Spiele speichert seine Spielstände auf das Controller Pak (Memory Card). Im Controller Pak ist ein SRAM-Chip enthalten, welcher mit Hilfe einer Knopfzelle die Spielstände der unterschiedlichen Spiele behält. Das ist clever, denn so muss im Modul keine zusätzliche Hardware verbaut werden! Populäre Vertreter sind z.B. „Diddy Kong Racing“ oder „Mario Kart 64“. Hier ein Bild vom Controller Pak-Menü aus „Mario Kart 64“:

b

Weiterhin gibt es zahlreiche Spiele, welche Spielstände intern in ihrem Modul auf EEPROMS (und vereinzelt sogar auf FlashRam) in unterschiedlichen Ausführungen speichern. Diese benötigen keine Batterie, allerdings steht der gespeicherte Spielstand dann logischerweise auch nur auf dem Modul zur Verfügung. Populäre Vertreter sind z.B. „Super Mario 64“ oder „Banjo-Kazooie“. Hier ein Bild eines typischen Speichervorgangs, nachdem man einen Stern in „Super Mario 64“ eingesammelt hat:

c

Zusätzlich gibt es eine Hand voll Titel, welche ihren Spielstand intern auf SRAM speichern. Das ist so ziemlich der schlechteste Fall, denn hierbei muss in jedem Modul eine Knopfzelle vorhanden sein, welche den Spielstand behält. Populäre Vertreter sind z.B. „Legend of Zelda: Ocarina of Time“ oder „Super Smash Bros.“. Im Bild der Speicherbildschirm von „Legend of Zelda: Ocarina of Time“:

i

Zuletzt gibt es noch ein paar vereinzelte N64-Spiele welche keine „physikalische“ Speicherfunktion anbieten. Meistens sind das sehr einfache Spiele, die tatsächlich keinen Spielstand benötigen. Einige Hersteller haben auch den Weg über die Eingabe von Passwörtern gewählt. Hier z.B. der Speichermechanismus via Passwort aus „Gex 64: Enter the Gecko“:

Fun Fact: Ich möchte jedoch den Entwicklern von „Gex“ nicht Unrecht tun, denn sie bieten neben der Passworteingabe auch das Speichern auf Controller Pak als alternative Option an! 😉

e 

Kommen wir nun zur eigentlichen Frage: Wie geht der Doctor V64 nun mit den unterschiedlichen Technologien zum Speichern von Spielständen um?

Das hängt natürlich von der Methode ab. Spiele, die auf das Controller Pak gespeichert werden, sind selbstverständlich kein Problem und speichern unabhängig davon, ob sie mit oder ohne Doctor V64 gestartet wurden.

Bei Spielen, welche ihre Spielstände selbst im Modul auf EEPROMS, SRAM oder FlashRam speichern sieht das schon anders aus. Da die Spiele ja vollständig aus dem RAM gestartet werden, gibt es keine Möglichkeit seinen Fortschritt auf das – nicht vorhandene – Modul zu sichern. Oder doch? Auch hierfür hat Bung mehrere „kreative“ Lösungen gefunden.

Es wird nochmal unterteilt, ob ein Modul mit SRAM (eigene Batterie) oder EEPROM/FlashRam (ohne Batterie) speichert. Für den Fall, dass im Originalmodul des zu ladenden Spiels eine eigene Batterie (Speichertyp SRAM) verbaut ist, hat Bung ein spezielles DS1 Modul entwickelt.

Fun Fact: Ein ganz schöner Aufwand, wenn man bedenkt, dass nur ca. zehn Spiele diesen Speichertyp verwenden!

f

Ich konnte es natürlich nicht lassen, das Ding mal testweise aufzuschrauben. Im Endeffekt beinhaltet es auch nur eine CR2032-Knopfzelle, welche den Spielstand auf eigenen SRAM-Chips vor dem Verfall sichert.

g

Das DS1-Modul wird anstatt des Emulationsadapters zwischen Konsole und Überbrückungsmodul gesteckt:

h

Bei einem Speichervorgang wird dann der Spielstand auf den SRAM des DS1-Moduls geschrieben. Das funktioniert in der Praxis sogar sehr gut, zum Testen habe ich einen Spielstand in „The Legend of Zelda: Ocarina of Time“ angelegt. Dieser war nach Neustart der Konsole (bzw. Neuladen des Spiels) auch noch vorhanden:

Fun Fact: Wie wir ja bereits im letzten Artikel gelernt haben, müssen wir „The Legend of Zelda: Ocarina of Time“ über den Bootemulator (unterschiedlicher CIC-Typ) starten!

i

Als kleiner „Bonus“ kann sogar der Spielstand auf dem SRAM des DS1-Moduls auf sechs weitere Speicherbänke übertragen werden. So können mehrere Spiele auf dieser einen Karte gespeichert werden! Hierfür wird allerdings ein Tool namens „DS1 Manager“ benötigt. Dieses wird einfach als ROM-Datei an den Doctor V64 (via CD-Laufwerk oder Parallelport) geschickt. So sieht die Software aus:

Fun Fact: Das Bild ist schwarz/weiß, da die Software für die NTSC-Region konzipiert wurde! 😉

j

Hier habe ich testweise den „Zelda-Spielstand“ aus dem SRAM auf eine weitere Speicherbank kopiert. Somit könnte ich die DS1 z.B. für „Super Smash Bros.“ verwenden und bei Bedarf den „Zelda-Spielstand“ einfach zurückladen.

k

Neben der grauen Version der DS1 habe ich auch noch ein DS1-Modul in schwarzem Gehäuse:

Fun Fact: Ist jemand der Schreibfehler auf dem Etikett des grauen DS1-Moduls aufgefallen? Anstatt „CARD“ haben die Kollegen von Bung einfach „CADE“ geschrieben! 😀

l

Rein technisch scheinen diese sich nicht zu unterscheiden (zumindest scheinen beide gleich zu funktionieren). Allerdings sieht es so aus als wurden bei der schwarzen Version einige Lötstellen auf der Platine mit Kabeln überbrückt. Ich will es gar nicht wissen… 😀

m

Neben den wenigen Modulen mit internem Batteriespeicher (SRAM) gibt es eine Vielzahl an Modulen, welche intern (im Modul selbst) auf EEPROMs (und teilweise sogar FlashRam) speichern. Möchte man Spiele dieser Art mit dem Doctor V64 sichern, muss ein Modul mit gleichem Speichertyp (4Kbit EEPROM, 16Kbit EEPROM oder 1Mbit FlashRam) wie das in den RAM geladene Spiel im Emulationsadapter stecken. So kann z.B. zum Speichern von „Super Mario 64“ einfach z.B. „Mario Party“ als Überbrückungsmodul verwendet werden. Im Endeffekt wird dabei der Spielstand von „Super Mario 64“ einfach in dem EEPROM des Überbrückungsmoduls („Mario Party“) abgelegt – krass! 😀

Fun Fact: Wer Artikel 37 gelesen hat weiß, dass der CIC-Typ nicht übereinstimmen muss, da dieser ja mit Hilfe des Bootemulators ausgetrickst werden kann. Lediglich der Speichertyp des Überbrückungsmoduls muss gleich sein!

n

Das Ganze konnte ich sogar in der Praxis nachstellen. Eins konnte ich damit jedoch ganz klar feststellen: Diese Lösung ist mit Abstand die umständlichste. Letztendlich bedeutet das, dass man durch die Speicherform wieder eine Abhängigkeit zum Überbrückungsmodul hat – unschön! Gibt es denn wirklich keine bessere Lösung für die Spiele, welche auf EEPROMs speichern? Diese Frage hat sich wohl auch Bung gestellt, denn einige Monate nach der Veröffentlichung des Doctor V64 haben sie die DX256 entworfen!

o

Auch wenn die DX256 ähnlich wie die DS1 aussieht, ist die Funktionsweise komplett unterschiedlich zur DS1. Mit ihr kann man die Spielstände von Modulen mit EEPROM-Speicherung auf eigenen EEPROMs in der DX256-Karte speichern. Mit den zwei roten Rädchen (links A-P, rechts 1-16) können insgesamt 256 Speicherbänke (A1-F16) eingestellt werden.

Fun Fact: Lustigerweise benötigt die DX256 im Gegensatz zur DS1 tatsächlich den Emulationsadapter (oder alternativ eine DS1) zwischengeschalten. Ich vermute Bung hat das mit Absicht so konzipiert, sodass die DX256 auch ohne Doctor V64 verwendet (bzw. verkauft) werden kann. So konnten damals Spielstände zwischen Freunden getauscht oder alternativ gesichert werden, wenn man ein ausgeliehenes N64-Spiel wieder an einen Freund zurückgeben musste! 🙂

p

Na das wollen wir doch gleich mal probieren. Über den Doctor V64 laden wir „Super Mario 64“ von CD. Selbstverständlich ist beim ersten Start noch kein Spielstand angelegt:

q

Jetzt müssen wir nur schnell König Bob-Omb besiegen und einen Powerstern ergattern, damit wir unseren Spielfortschritt speichern können.

r

Geschafft! 🙂

s

Und siehe da, sobald wir das N64 aus- und einschalten ist unser Spielstand mit einem Stern noch vorhanden! Die DX256 verrichtet ihren Dienst einwandfrei! 🙂

t

Man merkt definitiv, dass Bung die DX256 primär für den Doctor V64 entwickelt hat. So gibt es sogar einen eigenen Menüpunkt zur Übertragung von Spielständen auf den PC und umgekehrt.

u

Wichtig dabei ist, dass die DX256 direkt auf den Doctor V64 gesteckt wird um diese während der Übertragung mit Strom zu versorgen. Anschließend kann der Übertragungsvorgang gestartet werden.

Fun Fact: Obwohl „Uploading Data“ auf dem Bildschirm erscheint, ist damit die Übertragung von DX256 in Richtung PC gemeint – nicht verwirren lassen! 😀

v

Zugegeben etwas umständlich ist, dass alle Speicherstände in einer einzigen Datei (128 kByte) an den PC übertragen werden. Möchte man jetzt die Savegames einzelner Spiele haben, muss man diese erst extrahieren. Mutige Abenteurer machen das mit einem Hexeditor (Speicherbank A1 entspricht z.B. dem Offset 0x01DC00, O15 dem Offset 0x000000, …). Für alle anderen gibt es ein Tool namens „Smart Saver 256“.

w

Mit Hilfe des Tools lässt sich der komplette Inhalt der DX256 katalogisieren und einzelne Spielstanddateien (*.SAV) können im- und exportiert werden. So habe ich z.B. meine alten Spielstände (wurden vor vielen Jahren mal auf einem Emulator gezockt) einfach in das *.256er-Datenbank-File importieren können. Anschließend habe ich dieses zurück auf die DX256 übertragen.

Fun Fact: Man kann den Transfervorgang sogar direkt über den „Smart Saver 256“ (ohne die entsprechenden Menüpunkte im Doctor V64) durchführen!

x

Um zu testen, ob die Spielstände übertragen wurden stelle ich die DX256 auf Position A12 ein, denn dort müsste mein perfekter Super Mario 64 Spielstand liegen. Und siehe da, alle 120 Powersterne eingesammelt – vier Mal! 😉

y

Ich denke das reicht für einen groben Überblick über die Speichermechaniken. Wenn ich es mir recht überlege, könnte ich eigentlich einen Spielstand löschen um Mario erneut bei seinem Abenteuer zu begleiten. Prinzessin Peach – wir kommen!!! 🙂

2 Comments

Write a comment to Sascha Antworten abbrechen