Przerwania po dekompresji.

[OSH]

Witajcie!
Jak wiecie, lubie sie ":wlamywac": do gier. Ale mam problem.
Problem z gra Army Moves. Otoz po uruchomieniu procedura dekompresujaca przestawia wektor przerwan. Po uzyciu freeze (mam Finala III) i przejsciu do monitora gry nie da sie ponownie uruchomic. Adres startowy znalazlem, ale nic mi to nie daje, bo sa zmienione wektory przerwan. W programie jest pelno rozkazow RTI i stad moje przypuszczenie. Na emulatorze (CCS) wgralem ROM Action Replaya i program wystartowal. Ale w domu nie mam Actiona. Wiem, ze jest mozliwe przywrocenie wlasciwych wartosci wektorom. Ale jak???

[OSH]

Widze, ze zainteresowanie jest duze, ale nikt jeszcze nic nie napisal. Wiec opisze troche dokladniej, o co mi chodzi.
Poniewaz nie znam poprawnych wartosci wektorow przerwan, postanowilem, ze sie tego dowiem i zaczalem analizowac kod procedury dekompresujacej.
I nie rozumiem paru rzeczy. Najpierw przedstawie kod:
0810 SEI
0811 LDX #$FF
0813 TXS
0814 LDY#$00
0816 STY$01
0818 LDX#$CC
081A LDA$0857,X
081D STA$0333,X
0820 LDA $091D,Y
0823 STA$00FF,Y
0826 DEX
0827 BNE$082B
0829 LDX#$01
082B DEY
082C BNE$081A
082E DEC$2E
0830 LDA$2E
0832 CMP#$08
0834 BEQ$0843
0836 DEC$083D
0839 LDA($2D),Y
083B STA$FFFF,Y
083E DEY
083F BNE$0839
0841 BEQ$082E
 
Jest to poczatek kodu procedury dekompresujacej z wyzej wymienionej gry. Nie ma tam zadnego intra, po dekompresji gra sie uruchamia.
Z tego co sie zdazylem zorientowac, na poczatku znajduje sie prosta petla relokujaca dane.
I teraz mam pytania:
Po pierwsze: po co jest rozkaz DEY  komorce $082B? Przeciez do Y zaladowane zostalo 0, wiec co on ma odejmowac?!
Po drugie: jak wiadomo, najwyzszym adresem w C-64 jest FFFF.  Gdzie wiec zostana zaladowane dane z petli w komorkach 0839-083f. Przeskocza do $0000???
A poza tym, wydaje mi sie, ze to wlasnie w tym miejscu ustawia sie te nieszczesne wektory przerwan.
 
Przepraszam za ewentualny brak rozeznania w temacie, ale asemblerem C-64 zaczalem sie bawic niedawno i nie wszystko jest dla mnie jasne.

[Raf]

to DEY sluzy tam za wskaznik petli... jakod $00 odejmiesz jeden to masz po prostu $ff tylko zmienia sie jedna z flag procesora (wynik zerowy) - i na to wlasnie ":czyha": BNE ... gdy bedzie 0 w Y to petla przestanie sie wykonywac (cos jak for w basicu)
 
natomiast tego drugiego nie jestem pewnien ale najwyrazneij tak jest... przeanalizuj opcody typu BRANCH (BNE , BEQ , BCS etc) to sie skapniesz co jest grane

[OSH]

Dzieki Raf za odpowiedz!
No, to teraz wiem, dlaczego DEY bedzie dzialac. Musze sie dalej wgryzac w kod relokatora. Ma ktos jeszcze jakies pomysly??

[Pampam]

Proponuje tobie najpierw przejzec mape pamieci wtedy zauwazysz ze jest zmieniana zawartosc stosu, a nie przerwania nie widze calego kodu i kupe lat nie mialem do czynienia z asm6510 ale na moj gust tak to wyglada, txs ustawia wskaznik stosu a potem sta $00ff,y zapisuje jego zawartos tym co jest pod 091d czy przypadkiem pozniej w kodzie nie ma jakiegos rti/rts przerwania masz pod 0314-0315 irq, 0316-0317 brk i  0318-0319 nmi a w kodzie nie widac raczej niczego co zmienialo by wektory przerwan. Ale tak jak napisalem wczesniej moge sie mylic lata robia swoje i mozliwe ze w tej chwli cos lamie.

[Pampam]

Tak mi jeszcze przyszlo do glowy ze wlasciwe rejestry przerwan sa chyba na gorze od ffff w dol a na poczatku wylaczane sa chyba romy LDY#$00, STY$01 potem jest DEC$083D wiec chyba dostaniesz zamiast 083B STA$FFFF,Y bedzie 083B STA$FeFF,Y wiec teoretycznie przerwania tez moga byc zmienione.

[OSH]

Zgadzam sie z Toba, ze jest zmieniana zawartosc stosu, ale po dekompresji w programie pojawia sie mnostwo rozkazow RTI i dlatego sadze, ze zmieniony jest wektor NMI/IRQ. jest co najmniej 8 miejsc w pamieci, w ktorych pojawia sie para rozkazow LDA#$, STA $FFFE, LDA#$, STA$FFFF.  
A mape pamieci mam

[Raf]

heh... zreszta freezer z finala ma tendencje do nieprawidlowej pracy - to jest taka moja ogolna uwaga... mam finala 2 i tez nie wszystkie gierki dzialaly... a procedurka ... odtwarza strone zerowa i stos... kto wie , moze sam freezer miesza po stosie cos?  sugeruje iz w momencie freezeowania sama giera moze duzo na stosie trzymac a freezer tez pewnie cosik potrzebuje i to sie moze pieprzyc przy depaku...

[OSH]

Ja tez tak mysle. Dlatego nie da sie zrestartowac gry za pomoca Finala III po freeze, a mozna za pomoca Action Replaya. I dlatego szukam w kodzie gry ustawien wektorow przerwan, bo jak je wlasciwie ustawie, to bede mogl ja zrestartowac.

[przemek_bundy_]

chyba znam odpowiedz na twoje pytanie!
 
ten kawalek kodu ktory przedstawiles kopiuje jedynie tylko inne dane,
pod adres $FFFF i w dol. pozatym kopiuje tez inna procedurke pod adres: $0334
i pod adresem w pamieci (po wczytaniu gry) $0855 jest skok do: $0334
ot i cala filozofia! Taki tok postepowania ma wiekszosc gier. pozatym efekty dzialania
procedurek de-pakujacych mozna obserwowac w wiekszosci gier na ekranie!
gdyz, krotka procedurka z adresu $0800 w zwyz przenosi glowny de-paker
np: pod: $0400 a on pozniej zajmuje sie sie wszystkimi czynnosciami......
 
czy wyjasnilem dosadnie...  
 
pozdrawiam...

[OSH]

Zgadza, sie to jest relokator. Co ciekawe, w programie relokacja nastepuje dwukrotnie. Petla relokujaca konczy sie tak:
LDA#$37
STA$01
JMP$ adres.
Gdzie ":adres":, to poczatek zrelokowanego programu. Za wszelka cene chcialem sie dowiedziec, jak wyglada program po relokacji i w miejsce JMP$ adres wstaiwlem JMP$FE66, co powoduje skosk do BASIC-u. Tak postapilem 2 razy.  Za trzecim razem, pojawil sie wlasciwy adres startowy programu. no to SYS$1930 i... nic. Niestety, zobaczylem ekran dokladnie taki sam, jak po uzyciu freeze z Finala III (czyli gra sie zawiesila przy probie restartu). Wychodzi na to, ze, ze gry sie nie da zrestartowac (albo ja tego nie umiem, predzej to drugie ).
Ale ja sie nie poddam

[Raf]

teraz to bede pierdoly pisal - a nuz do czegos to Ciebie zaprowadzi
 
pewnie juz wiesz ze komorka $01 odpowiada za to co proc przy odczycie w obszarach a000-bfff oraz d000-ffff widzi (ram/rom/IO etc) , przy relokacji kiedy trzeba przeczytac caly ram tez pewnie jest to gdzies podmieniane
 
sproboj w czasie gdy gra jeszcze chodzi zgrac zawartosc stosu spod monitora do jakiegos pliku i go potem przywrocic. najlepiej wypadaloby zapauzowac gre etc... tak zeby za duzo sie nie mielilo ... i zafrezuj a potem po odfrezowaniu wczytaj stan stosu.
 
dalej zycze owocnej zabawy

[przemek_bundy_]

Chyba sie gubie powoli w tym wszystkim!
powiedz mi co chcesz osiagnac, do czego dazysz?!
 
-czy chcesz podejrzec procedurke relokujaca?!
-czy chcesz przerwac gre, pogrzebac w niej a pozniej grac dalej ?!
 
wydaje mi sie ze zgrywanie stosu nie jest za bardzo potrzebne.
przy restarcie kompa czy to z FINAL czy z pod resetu, zawsze utracisz
strone zerowa pamieci (tzn: komorki 0-255) no i dalsza czesc pamieci
az po adres: $0800 plus pare bajtow! czyli tracisz wszystko od 0-$0800.
 
jak wiesz zapewne ram komodorka podzielony jest na 4 banki po 16 KB.
czyli dane spriteow lub bitmap graficznych czy znakowych moga znajdowac
sie i byc widziane tylko w jednym banku!
po restarcie komodorka pracuje bank od adresu: $0000 - do: $3FFF
i np: pamiec ekranu (czyli to co klikamy po ekranie) jest od adresu: $0400 w zwyz.
Czesto i gesto jest tak ze gry nie musza korzystac z banku zero tylko
innego wyzszego np: od $4000 do: $7FFF i co wtedy sie dzieje...
w obszaze normalnie gdzie jest ekran czyli od $0400 moze znajdowac sie kod programu czy gry... wykonanie resetu komodorka ustawia bank o numerze zero.
a pamiec ekranu zostaje kasowana i zarazem kasowany jest kod gry czy programu...
 
uruchomilem emulator VICE i odpalilem gre.
czekalem az pojawi sie glowna plansza gry ":press fire":
po wybraniu monitora z menu wlaczylem okienko z disassembleracja  
kodu programu gry. adres PC (czyli adres aktualnej komorki  0-$FFFF w ktorej wykonuje sie w danym momencie rozkaz przez CPU": byl w moim przypadku ustawiony na: $F921. akurat trafila sie petla opozniajaca, (mozna ja czesto trafic bo wykonuje sie najdluzej)  
czyli mozna przyjac ze gra dziala wlasnie w tym adresie !!!
bynajmniej w tym adresie dziala plansza glowna gry czekajaca na FIRE.
 
Normalnie w tej czesci pamieci C64 ustawiony jest KERNAL jezeli uzywasz basica.
No i pod adresem ekranu tez jest jakis kod !!! ekranu basicowego od: $0400

[przemek_bundy_]

mam kolejne wiadomosci:
 
glowna petla startu oczekiwania na FIRE to adres $F7CB
glowna petla kiedy sie gra to: $0420 do: $05D3 to sie kreci !!!
 
jak widzisz glowny kod gry to pemiec ekranu, a kod glownej planszy to kernal...
z tego wynika ze nieda sie nic zrobic z pod basica!
 
zycze powodzenia.....
pozdrawiam...
 
P.S.  jezeli np niewiesz czy program wykonuje  w danym momencie dany kawalek kodu. mozesz wstawic pulapki tzn...
ja to robie w ten sposob!
 
petla :  inc $D020
            jmp petla
 
wtedy zmienia sie kolor ekranu a ja wiem ze program dochodzi do tego momentu!

[OSH]

Zgadza sie, a adres startowy to $f92c. Tyle, ze dziala to jedynie pod Action Replay\'em. Pod Finalem III restart spod $f92c powoduje zawieszaenie gry. Dlatego wlasnie chce ustawic wektory przerwan wlasciwie, bo wtedy jest mozliwosc powrotu do gry po Freeze. Poza tym, to pozwolilem dwukrotnie grze zrelokowac pamiec, po czym pojawilo sie ustawienie takie, jak po normalnym uruchomieniu. Ale tez nie da sie zrestartowc. Nie wiem, dlaczego...
Petla relokujaca konczy sie tak:
LDA#$37
STA$01
JMP$1930
Po dwukrotnym zrelokowaniu wstawilem przerwe i program powrocil do BASIC-a. Po czym sprobowalem skoczyc pod $1930 i nic... Zawieszenie.
Dlatego chce to zrobic? odpowiedz jest prosta - bo chce Lubie wiedziec