Emulator MCSIO-Czyli zapisywanie save'ów na HDD lub USB

[GENERiC]

Pewnie cały czas zastanawiacie się czy jest możliwość zapisywania save'ów w grze bezpośrednio na pamięć przenośną (Pendrive) lub dysk twardy (pod IDE). Oczywiście żadna gra nie potrafi zapisywać stanu gry na powyższych pamięciach (choć jest kilka wyjątków), zaś PS2 Browser nie pozwala ich na nie przenosić . Zapewne byłoby tak nadal gdyby nie romz - autor emulatora modułu MCSIO, który z początku przeznaczony był wyłącznie dla HDD. Dla osób, które nie posiadają dysku twardego (a przy tym drogiego Network Adaptora) nasz rodak ffgriever dodał obsługę USB, zoptymalizował kod (prędkość, zużycie pamięci) i wprowadził szereg usprawnień (o których będzie mowa w dalszej części tutorialu).

Niniejszy tutorial przeznaczony jest wyłącznie dla osób, które potrafią na komputerze zrobić coś więcej niż tylko przeglądać www i grać w pasjansa, sapera itp. To samo tyczy się PS2 - tutorial nie opisuje uruchamiania programów (z czego je uruchomisz to bez znaczenia), nagrywania płyt z grą/programem, ani nawet sposobu przenoszenia danych na poszczególne media (np. uLELFem). Ponadto zakładam u czytelnika znajomość sposobu w jaki bios napędu PS2 weryfikuje nośniki.

Kompatybilność

Wspomniany emulator, emuluje MCSIO, tym samym oszukuje grę, która myśląc, że ma do czynienia ze slotem z kartą pamięci, tak naprawdę zapisuje save na obrazie memorki znajdującym się na Mass:/ (pamięci pod USB) lub HDD0:/ (dysk twardy).

Jest to genialna, niestety nie idealna metoda, która pozwala wyeliminować używanie karty pamięci do zapisywania save'ów. Szczególnie zadowoleni powinni być posiadacze nieoryginalnych lub nielicencjonowanych kart, z którymi w niektórych grach występują problemy - a dzięki emulatorowi, sporo z nich, z powodzeniem współpracuje z emulatorem (np. pierwsza i druga część God of War).

I oczywiście nic na tym [beep] świecie nie jest idealne.Dlaczego? Otóż:

1.)Po załadowaniu modułów do obsługi usb/hdd i systemów plików oraz modułu samego emulatora, niektóre gry nie będą w stanie otrzymać od systemu niezbędnej do działania ilości pamięci. Moduły wraz ze swoimi buforami zajmują około ~100kB, ale jak widać czasami i 100kB to za dużo (niektórym grom brakuje dosłownie kilku kB! Moduły HDD zajmą oczywiście dużo mniej, ponieważ alokują mniej pamięci na swój użytek). To pierwsze primo.

2.)Inny rodzaj to pliki uruchamiające inne pliki. Emu zadziała z pierwszym, ale na drugim zazwyczaj najzwyklej się zawiesi (choć nie zawsze!).To jest drugie primo.

3.)Następne primo to gry korzystające z MC w "dziwny" sposób. Wtedy najczęściej zawiesza się na etapie zwracanych wartości przez SIO2 Command Handler (w module MCSIO).

4.)I wreszcie ostatnie, czwarte primo to niekompatybilne obrazy IOP (*.img) lub niekompatybilność innych modułów (większość homebrew).

Gry, z którymi występują problemy na nieoryginalnych kartach, a które w pełni współpracują z emulatorem:

-God of War 1 i 2
-Gran Turismo 4
-Tekken 5

Gry w których występują problemy z emulacją:

-Ratchet & Clank 2 - Going Commando (brak niektórych dźwięków)

Gry niekompatybilne (które zawieszają się):

-Suikoden 4 (zaraz po logo Konami)

Z pozostałymi pozycjami nie ma problemów (gdzieś kilkaset tytułów) lub nie były wogóle testowane. Kompatybilność emulacji na Mass:/ jest oczywiście trochę mniejsza od tej na HDD0:/.

Uruchamiamy emulator

A więc programy dla PS2 dzielą się na:
-Te wykonywane przez EE (Emotion Engine)
-Te, które są wykonywane przez IOP (Input/Output Processor).
Te drugie to tzw. moduły (*.irx) i takim też jest cały emulator. Aby uprościć jego uruchamianie i debuging, napisano wiele GUI jak i launcherów (na jednym z nich będziemy pracować) z już wkompilowanym emulatorem.

GUI, launcher czy nawet sam emulator można uruchamiać na kilka sposobów:

Sposób pierwszy:

Uruchamiając launcher przez file manager np. ulELF lub od razu z biosu (np. z płyty) dla każdej gry z osobna należy odpowiednio wyedytować w hexedytorze (dowolnym) dwie linijki kodu maszynowego. Dlaczego? Otóż bowiem program ma przypisany tylko i wyłącznie jeden, z góry ustalony *.elf (pod nazwą DATA_xxx.xx) i obraz *.img (pod nazwą IOPRPxxx.img lub DNASxxx.img), dla tylko i wyłącznie jednej, konkretnej i określonej lokalizacji. Nie mamy też możliwości uruchomić go z parametrami.

Reasumując: uruchamia tylko jedną grę i to pod nią trzeba zmienić wszystkie "wpisy". Jest to kiepska, denerwująca metoda, która wcale nie "opiewa" emulatora.

Opieramy się wyłącznie na launcherze wykonanym przez FFGrievera w wersji emulatora 0.7f

Pod offsetem 0x00009200 należy przypisać ścieżkę (tylko jedną!) na płycie do *.img. Poniżej kilka przykładów:

cdrom0:\IOPRP234.IMG;1
cdrom0:\MODULES\IOPRP300.IMG;1
cdrom0:\JAKISFOLDER\DNAS300.IMG;1
i tym podobne...

Pod offsetem 0x000092D0 należy przypisać ścieżkę (tylko jedną!) na płycie do *.elf. Poniżej kilka przykładów:

cdrom0:\SLPS_250.88;1
cdrom0:\SLUS_54.321;1
cdrom0:\SCES_123.45;1
i tym podobne...

Oczywiście zagnieżdżenie może być większe i w razie braku ilości znaków należy wjechać na 00h. Broń Boże nie wolno dodawać do pliku dodatkowych wartości.

Sposób drugi:

Emulator można uruchomić przez GUI, który sam wyszukuje na płycie wspomnianych powyżej plików. Niestety jest to metoda, co prawda najprostsza, ale i najgorsza. Użytkownik nie ma możliwości uruchomienia emulatora z określonymi parametrami jak też i nie ma wpływu na pliki, których wyszukuje.

Sposób trzeci:

Najlepszy ze wszystkich wymienionych. Umożliwia wprowadzanie parametrów emulatora, definiowanie ścieżek do plików i wybór zapisu save'ów pomiędzy HDD, a Mass. Launcher lub sam emulator możemy uruchomić przez sieć (np. za pomocą PS2Link) lub przez RadShella od razu na konsoli.

Jako, że nie każdy użytkownik posiada Network Adaptor czy nawet dysk twardy, będziemy opierali się na pisaniu skryptów dla RadShella i zapisywaniu save'a na pamięciach przenośnych typu PenDrive.

Obarzy kart pamięci

Emulator zapisuje save'y nie bezpośrednio na Mass czy HDD tylko do obrazu karty pamięci.Wymaga to więc przygotowania takiego obrazu.

Wraz z GUI dołączone są dwa obrazy sformatowanych memorek 8MB:

memorycard0.bin - karta pamięci w pierwszym emulowanym slocie

memorycard1.bin - karta pamięci w drugim emulowanym slocie

To właśnie tych plików będzie poszukiwał emulator i to właśnie na nich będą zapisywane save'y. Jako, że system plików na PS2MC zbliżony jest do FAT32, można używać obrazów nawet wielkości 3.99GB!

Obraz karty niesformatowanej to po prostu plik z ciągiem wartości 00h lub FFh - zależnie od ustawionej w *.mci flagi (np. dla 8MB będzie to 8388608 bajtów samych 00h lub FFh).

Zaleca się stosowanie dla każdej gry oddzielnych karty, ponieważ przy nieumiejętnym obchodzeniu się z emulatorem może dojść do uszkodzenia obrazów (a móiąc ściślej-ich tablic).

Pliki *.mci

Do każdej karty dołączony jest plik memorycardX.mci (gdzie "X" to numer slotu z memorką), który definiuje jej budowę (bez takiego pliku karta zawsze będzie widziana jako niesformatowana i uwaga za każdym razem gra zapyta czy ją sformatować!).

Podglądając zawartość tego pliku, ujrzymy ciąg bliżej nieokreślonych wartości:

4D43 4932 0002 0200 0040 0000 2B00 0000h


4D43 4932h - "MCI2", czyli oznaczenie formatu (tzw. nagłówek).
0002h - wielkość strony (w tym przypadku 512B, może być też 1024B).
0200h - wielkość bloku w stronach, a więc w tym przypadku 2x512B (może być też 1x1024B).
0040 0000h - całkowita ilość stron na karcie, a więc niejako jej pojemność (16384 strony czyli 8MB).
2B00 0000h - flagi - pole bitowe (na jednym bajcie):


0x01 - Karta obsługuje ECC.
0x08 - Karta może posiadać bad blocki (jeśli będzie jakiś bad block to bez tej flagi się nie włączy).
0x10 - Wyczyszczone bloki mają wszystkie bity ustawione na zero (w przeciwnym wypadku na 1) - czyli czyszczenie albo 0x00 albo 0xFF. Większość kart czyści na 0xFF.

Pozostałe nie są znane (ale jak znamy życie z pewnością mają jakiś wpływ).
Cała rzecz polega na sumie logicznej poszczególnych flag. Aby to przedstawić obrazowo, przyjrzyjmy się jak wygląda 0x2B w postaci binarnej:

00101011 - a więc jest to suma liczb 1, 10, 1000 i 100000.

Spójrzmy teraz na te same liczby w postaci hexadecymalnej: 0x01, 0x02, 0x08 i 0x20. Dodając je do siebie otrzymamy właśnie 0000002Bh. Pozostaje już tylko odwrócić całość, aby otrzymać upragnione 2B000000h. A skoro już przy tym jesteśmy: w pliku *.mci wszystkie liczby zapisane są właśnie w Little Endian.

Oczywiście wszystkie te wartości można dostosować do naszych, skromnych potrzeb, chociaż lepiej jednak pozostawić to tak jak jest. Karta jest zdecydowanie szybsza (odczyt/zapis).


Powyższe rzeczy zainteresują pewnie tylko nielicznych. A więc w emulatorze są już gotowe obrazy kart i ich pliki konfiguracyjne (choć w razie braku takowych, emulator sam je wygeneruje).

Radshell.rsh

Uff... teorię na szczęście mamy już za sobą, czas zatem przystąpić do części praktycznej, najciekawszej. Jak już wspomniałem , tutorial opisuje uruchamianie launchera/emulatora z poziomu RadShella, wywołując odpowiedni skrypt - i tym właśnie za chwilę się zajmiemy.

Podczas startu RadShell wrzuca do IOP określone przez użytkownika moduły (*.irx) - określone w pliku radshell.rsh. Jest to zwykły plik tekstowy (ANSI), także jego edycja nie powinna stanowić problemu.

Poleceniami "load rom:" (rom0 lub rom1), "load int:" i "load" ładujemy do IOP określone przez nas moduły. Jest to niezwykle ważne, bowiem ładujemy je względem nośnika, z którego uruchamiamy emulator. Co oczywiste nie można ładować modułu z danego nośnika przed załadowaniem modułu do jego obsługi. Należy też trzymać się kolejności ich dodawania.

Na przykład nie można wrzucać MCMAN (Manager Memory Card) przed SIO2MAN, bowiem ten drugi jest interface'm do obsługi padów i kart pamięci. Jeśli zrobimy to na odwrót, program nie będzie mieć dostępu do tych urządzeń (MCSERV możemy sobie odpuścić, tym już zajmie się później emulator).

Co z CDVDMAN (moduł odpowiedzialny za obsługę napędu i cdfs)? Jest automatycznie ładowany jeśli bootujemy program z płyty. Również możemy go sobie odpuścić w skrypcie.


Czas przejść do wyboru pomiędzy pamięcią na USB, a dyskiem twardym (na IDE). Wyboru należy dokonać względem nośnika, z którego chcemy załadować dany moduł lub program.

Obsługa HDD:

load poweroff.irx
load ps2dev9.irx
load ps2atad.irx
load ps2hdd.irx -o 4 -n 20
load ps2fs.irx -m 4 -o 10 -n 40
mount pfs0: hdd:+MCSIOEMU

Obsługa Mass:

Co prawda RadShell od razu ładuje już swój moduł do obsługi USB (w przeciwnym razie nie dałoby się korzystać z klawiatury ;]), to mimo to nadal nie zawsze widzi pendrive'y (program używa takiego samego, który siedzi w uLELFie, więc jest na pewno kompatybilny skoro działa pod jego kontrolą).

load usbd.irx

Dopiero po załadowaniu interface'u dla USB, ładujesz jeden z dwóch modułów:

load usbhdfsd.irx
load usb_mass.irx


Poniżej znajduje się przykład gotowego startowego skryptu z obsługą kart pamięci i mass:

Kod:

fontsize 0.6
border 2 2
iopreset

load rom0:SIO2MAN
load rom0:MCMAN

load int:iomanx.irx
load int:filexio.irx

load usbd.irx
load usbhdfsd.irx

Uwaga:

Oczywiście można też ładować pliki niekoniecznie z miejsca, w którym znajduje się RadShell, podając do nich pełne ścieżki (np. mc0:BOOT/USBD.IRX). Warunek to oczywiście rozpoznanie urządzenia. Warto też wspomnieć iż jeśli w ścieżce do pliku znajduje się spacja, całość należy objąć cudzysłowem (np. "mass:nazwa folderu/nazwa modulu.irx").


Pozostałe polecenia są bardzo dobrze objaśnione w readme, także nie będziemy sobie tutaj zawracać nimi gitary (do naszych celów nie będą nam potrzebne).

mcemu.rsh

Skrypty, którymi będziemy wywoływać launcher/emulator są niestety trudniejsze. Należy wpisać w nich run, podać ścieżkę do programu i określić parametry. Polecam wrzucić launcher/emulator do folderu RadShella, podobnie ze skryptami - w ten sposób unikniemy wpisywania długich i uciążliwych nazw.

run nazwa_programu parametry

Czym są te straszne parametry? W przypadku opisywanego programu będą to:
- ścieżka na płycie do *.img
- dodatkowe opcje
- ścieżka na płycie do *.elf

Co jest bardzo ważne: właśnie w takiej, a nie innej kolejności!


Aby nieco rozjaśnić tą ciemną sytuację pokażę to na przykładzie Devil May Cry 3 - Dante's Awakening:

run mcemu07f.elf -ioprp=cdrom0:\IOPRP280.IMG;1 -pfs=mass:/ cdrom0:\SLPM_658.80;1


Polecenie "run" oznajmia RadShellowi, że ma uruchomić program *.elf (lub *.irx jeśli został uprzednio załadowany).

"mcemu07f.elf" to nazwa programu, który uruchamiamy poleceniem "run". Jeśli program nie znajduje się w folderze razem z RadShellem to trzeba podać do niego pełną ścieżkę np. mass:folder_jakis/nazwa_programu.elf. Zwróćmy uwagę, że zaraz po zdefiniowaniu urządzenia nie występuje dwukropek i slash tylko sam dwukropek. Kolejna rzecz, o której bezwzględnie należy pamiętać to fakt, że jeśli nazwa programu lub folderu posiada w nazwie znak spacji, całe wyrażenie należy zamknąć w cudzysłów. np. "mass:folder jakis/nazwa programu.elf".


Kolejne wyrażenia są już mocno związane z emulatorem. Dlatego też omówię je oddzielnie i radzę się skupić:


Obowiązkowe:

-ioprp=cdrom0:\
Dokładna ścieżka do IOPRP lub DNAS na płycie. Koniecznie musi być podana jako pierwszy z parametrów i zakończona ";1".

-pfs=
Oznajmia emulatorowi na jakim nośniku i gdzie konkretnie ma szukać i zapisywać obrazów kart pamięci. Dla mass:/ będzie to np. -pfs=mass:/GT4/ (czyli obrazy memorek w folderze GT4 na np. Pendrive). W przypadku dysku twardego sprawa nieco się komplikuje bowiem należy podać dwa parametry: ścieżkę do pliku na dysku i partycję, na której się znajduje np.

Dla hdd0:siabadadadaba/memorki/GodOfWar/ należy podać:


-hdd=hdd0:siabadabadaba -pfs=pfs0:/memorki/GodOfWar/


cdrom0:\
Dokładna ścieżka do *.elf-a na płycie (pliku licencyjnego). Koniecznie musi być podana jako ostatni z parametrów i zakończona ";1".

Dodatkowe:

-bigusb
Użycie alternatywnego modułu usbhdfsd.irx. Jest trochę większy od standardowego (5kB). Niestety niektóre gry go wymagają (jedną z nich jest Final Fantasy X, ale dla tej gry ffgriever dodał go domyślnie z poziomu programu, więc nic już nie trzeba dopisywać). Gdyby jednak były problemy z dostępem do USB, to można wypróbować ten moduł.

-debug
Włączenie trybu debug, czyli wyświetlanie kolorowych ekranów podczas uruchamiania gry. Domyślnie jest włączony i w tej wersji emu nie da się tego wyłączyć.

-fastio
Włącza interface fastio (dodatkowy moduł oraz RPC). Wbrew pozorom nic nie przyspiesza. To po prostu inny sposób dostępu do karty pamięci. Spotkałem do tej pory tylko jedną grę (o ile pamięć mnie nie myli), która wymagała tej opcji. Był to Resident Evil. Polecam nie ruszać tego, chyba że gra wyświetla komunikaty o błędzie zapisu lub odczytu (po tym może nadal wyświetlać błędy, ale powinno się wszystko zapisać i wczytać prawidłowo, przynajmniej tak jest w RE). Zostawienie tego na wyłączonym (domyślnie, czyli nie podawać tej opcji) zaoszczędzi jakieś 3kB w pamięci (to całkiem sporo).

-fullback
Tzw. tryb bezpieczny. Włącza wykonywnie pełnych backupów na wirtualnej karcie pamięci (z pominięciem buforów). Czas w jakim gra zapisywać będzie save na USB, zostanie co najmniej dwukrotnie wydłużony. Nie polecam tego włączać, chyba że gra powoduje w trakcie zapisu uszkodzenie wirtualnej karty pamięci. Jeżeli opcja ta została użyta dla jakiejś gry, to używać powinno się jej ze świeżą kartą i cały czas, ponieważ włączanie i wyłączanie tej opcji w kolejnych uruchomieniach może prowadzić do uszkodzenia wirtualnej karty pamięci (jeśli przy zamykaniu w trybie bez fullback część danych nie zostanie poprawnie zapisana, a następnie zostanie uruchomiona w trybie fullback, może skasować pierwszy sektor na karcie).

-maxfiles=
Maksymalna liczba otworzonych plików. Domyślnie ustawione na 2. Jeśli ustawisz 1, oszczędzi to trochę miejsca w pamięci, ale dostępna będzie tylko karta pamięci w pierwszym slocie.

-maxmount=
Maksymalna liczba zamontowanych partycji. Domyślnie jest jedna.

-nobuf
Wyłącza tworzenie buforów z danymi "ratunkowymi", których koniecznie potrzebują niektóre gry (np. seria God of War, Tony Hawk Pro Skater). Na innych grach nie powinno mieć to wpływu na działanie, ale nie polecam tego wyłączać (może wtedy dojść do uszkodzenia wirtualnej karty pamięci). Zaoszczędza dwie strony pamięci (czyli jeden lub dwa kB). Rada dla niedoświadczonych - "nie ruszać".

-nopatch
Pomija walidację i patchowanie gier, które nie wymagają patchy (oczywiście mowa jest o łatkach pod kątem emulacji MCSIO). W obecnej wersji tylko do jednej gry został stworzony patch (FFX International - SLPS_250.88 lub SLPS_250.26).

-stack=
Wielkość stosu dla wątku poweroff. Domyślnie jest 1kB.

-thpri=
Priorytet wątku poweroff. Opcja ma znaczenie tylko dla posiadaczy HDD. Jeśli konsola nie wyłącza się po wciśnięciu resetu (trzeba trzymać 5-6 sekund, aby się wyłączyła) lub po wyłączeniu wirtualna karta pamięci uległa uszkodzeniu należy zwiększyć wartość (domyślnie jest 1).

Uruchamianie gry przez Emulator MCSIO

Przed nami test nie na inteligencje lecz o naszej, dotychczas zebranej wiedzy i skryptów. Jest to najprostsza część całego tutorialu.

1.) Załączamy RadShella (PS2). Możemy to zrobić w całkowicie dowolny sposób i z dowolnego nośnika. Akurat ja użyłem uLELFa (v4.12) uruchomionego z DEV1, którym uruchomiłem RadShella z mc0:/RadShell/. Sposób w jaki ja to zrobiłem ma sens jeśli posiadamy podróbkę karty pamięci.

Rekomendowana metoda to uruchomienie go z DEV2/3/4 lub za pomocą np. uLELFa z jednego z wymienionych trybów - w końcu nie po to emuluje się memory card, aby jej używać, prawda? To wcale nie jest głupie.


Uwaga:

Jeśli nasz napęd długo weryfikuje nośnik polecam odpalać RadShella przez uLELFa. Dlaczego? Bowiem możemy w nim łatwo sprawdzić kiedy i czy w ogóle nośnik w napędzie został zweryfikowany. Czyli: uruchamiamy uLELFa, wkładamy grę i czekamy na jej weryfikację. Dopiero kiedy będziemy mogli przeglądać zawartość płyty (podgląd dostępny pod cdfs:/) uruchamiamy RadShella.

2.) Myślicie, że program ma super fajne GUI. To muszę was zaskoczyć. Program nie ocieka graficznym przepychem. Przywita nas absolutnie tzw. "spartańskie" menu. Jeśli jeszcze tego nie zrobiliśmy, wkładamy naszą grę do napędu i czekamy aż nośnik zostanie zweryfikowany.

Skrypt uruchamiający emulator wywołujemy poleceniem script i zaraz po nim podajemy ścieżkę do naszego *.rsh.

Wszystkie skrypty są w folderze z RadShellem (tak samo emulator), dlatego też nie musiałem definiować konkretnych ścieżek do plików. Względem powyższego przykładu należy wpisać np. script mcemu_killzone_pal.rsh.

UWAGA:Niezbędna jest kompatybilna klawiatura pod USB (lub z przelotką z np. PS/2 na USB)

3.) Jeśli RadShell nie wypluje żadnego komunikatu o błędzie, po chwili uruchomi się emulator, wyświetlając ekran w kilku kolorach:

Kolor biały oznajmuje nam, że emulator nie znalazł plików *.img lub *.elf. Może to być spowodowane błędną ścieżką w *.rsh lub tym, że napęd nie zdążył zweryfikować nośnika (dlatego też zalecam uruchamiać RadShella i emulator, dopiero po poprawnej weryfikacji płyty).

Kiedy emulator odnajdzie *.img/*.elf, zostaną po sobie wyświetlone ekrany: zielony i czerwony po czym zostanie uruchomiona gra.


Oczywiście może się tak zdarzyć, że gra zawiesi się w momencie sprawdzania kart lub w którymś momencie w grze. Oznacza to, że trzeba pokombinować z parametrami w skrypcie. Oczywiście są gry, które nie są i prawdopodobnie nigdy nie będą współpracować z emulatorem.

Source:konsole.cdrinfo.pl