15.08.2009 01:37
[#61]
Re: Trudne początki z WHDLoad
@OSH, post #54
OSH napisał:
> Po przesiadce na WHDLoad i wyłączeniu cache -
> wszystko koszmarnie zwalnia. Bez wyłączenia cache gra się
> wiesza. Grać się da, ale zdecydowanie mniej dynamicznie. A
> może inni się wypowiedzą na ten temat?
Jakiej WHDLoad wersji wogole uzywasz? Nie zawsze to co najnowsze najlepiej dziala ;) a przedewszystkim jezeli chodzi o starsze installery.
Jezeli chodzi o moja konfiguracje to powiem ze MK2 chodzi na moim 040 Blizzardzie bez zadnych problemow (WHDL10.5). :)
PS; Jezeli masz jakies inne problemy z grami zainstalowanymi w WHDLoad na twoim 040 Apollo, to zerknij na EAB i dolocz do nas ;) a my postaramy sie jakos pomoc.
Ostatnia modyfikacja: 15.08.2009 01:40:29
> Po przesiadce na WHDLoad i wyłączeniu cache -
> wszystko koszmarnie zwalnia. Bez wyłączenia cache gra się
> wiesza. Grać się da, ale zdecydowanie mniej dynamicznie. A
> może inni się wypowiedzą na ten temat?
Jakiej WHDLoad wersji wogole uzywasz? Nie zawsze to co najnowsze najlepiej dziala ;) a przedewszystkim jezeli chodzi o starsze installery.
Jezeli chodzi o moja konfiguracje to powiem ze MK2 chodzi na moim 040 Blizzardzie bez zadnych problemow (WHDL10.5). :)
PS; Jezeli masz jakies inne problemy z grami zainstalowanymi w WHDLoad na twoim 040 Apollo, to zerknij na EAB i dolocz do nas ;) a my postaramy sie jakos pomoc.
Ostatnia modyfikacja: 15.08.2009 01:40:29
15.08.2009 17:08
[#65]
Re: Trudne początki z WHDLoad
@mailman, post #59
Raczej nie, najprawdopodobniej jest to wina samomodyfikującego kodu używanego w sporej ilości gier/dem, który nie jest spatchowany przez slave'a. 68030 ma dużo mniejszy cache od 68040 i dlatego na tym CPU, więcej rzeczy działa niż na 68040+, ale to autor slave'a powinien wyszukać i spatchować cały samomodyfikujący się kod, tyle że większości koderów się nie chce, bo to dużo więcej roboty.
15.08.2009 22:10
[#67]
Re: Trudne początki z WHDLoad
@Don_Adan, post #65
Z tym lenistwem koderów to jest różnie. Ja mam tylko 030. Swego czasu Irek mi przysyłał zrzuty z LastSoldier ze swojego sprzętu i szczerze to mi one nie pomogły, dowiedziałem się tylko, że zostałem gajowym, bo kod poszedł w krzaki ( a może faktycznie z lenistwa mocno nie przenalizowałem zrzutów ). Jakbym miał 040 to pewnie byłoby by mnie to bardziej zmotywowało. Cóż doszedłem do wniosku, że szkoda czasu na LostSoldier i na 040 trzeba użyć NOCACHE.
Ostatnia modyfikacja: 15.08.2009 22:25:24
Ostatnia modyfikacja: 15.08.2009 22:25:24
16.08.2009 01:32
[#69]
Re: Trudne początki z WHDLoad
@mailman, post #66
Ja wlasnie WHDLoad uzywam na drugiej Amidze z Apollo. Trzeba sobie jakos radzic, czasami pomagaja wlasnie tooltypy, czasami inna wersja WHDLoad, czasami lepsza okazuje sie wersja JST, a czasami okazuje sie ze mozna skads wytrzasnac wersje CD32 lub inna HD i odpalac gre za pomoca KillAGA/NoAGA. Opcji jest duzo, trzeba jednak troche pokombinowac. Czasami trzeba wylaczyc Cache z poziomu WB tuz przed odpaleniem gry WHDLoad itd. Ogolnie niekoniecznie trzeba bazowac na wersjach WHDLoad.
WHDLoad, to jeden z pomocnych narzedzi dla starych gier, ale przeciez sa jeszcze inne mozliwosci. :)
WHDLoad, to jeden z pomocnych narzedzi dla starych gier, ale przeciez sa jeszcze inne mozliwosci. :)
17.08.2009 14:33
[#72]
Re: Trudne początki z WHDLoad
@Andrzej Drozd, post #69
Andrzej Drozd napisał(a):
> Czasami trzeba wylaczyc Cache z poziomu WB tuz przed odpaleniem gry WHDLoad itd.
Nie łatwiej dodać na stałe NOCACHE do konfigu lub ikony gry?
> WHDLoad, to jeden z pomocnych narzedzi dla starych gier, ale
> przeciez sa jeszcze inne mozliwosci. :)
Ale jedyne stale rozwijane i supportowane. ;)
> Czasami trzeba wylaczyc Cache z poziomu WB tuz przed odpaleniem gry WHDLoad itd.
Nie łatwiej dodać na stałe NOCACHE do konfigu lub ikony gry?
> WHDLoad, to jeden z pomocnych narzedzi dla starych gier, ale
> przeciez sa jeszcze inne mozliwosci. :)
Ale jedyne stale rozwijane i supportowane. ;)
19.08.2009 12:49
[#74]
Re: Trudne początki z WHDLoad
@asman, post #73
Jeśli chodzi o wyszukiwanie samomodyfikującego kodu to jest to prawie tak proste jak konstrukcja cepa. Najlprościej jest zrobić dwa zrzuty pamięci z danej gry czy programu. Pierwszy, gdy exek jest w pełni zdepakowany i zrelokowany, ja zwykle używam do tego mojego niezawodnego breakpointa, czyli $60FE na początku kodu, który potem pod Actionem podmieniam z powrotem na oryginalny kod (zwykle $48E7), tyle że nie wiem czy z włączonym cachem to będzie działać, ale zawsze możesz go wyłączyć. Drugi zrzut pamięci robisz po jakimś czasie, najlepiej w miejscu gdzie program się wywala lub ma wywalić. Potem porównujesz kod (dane pomijasz) z obu wersji za pomocą jakiegoś programu do porównywania, ja zwykle używam prostej procedury CMP (by Hali/Union) i jeśli jest taki sam to kod nie był modyfikowany, a jeżeli w czymś się różni to sprawdzasz co to jest, i jak kod to szukasz procedury co go zmienia, którą potem patchujesz.
Co do extra waitów, to po prostu 68040 jest szybsza niż 68030, i jakaś procedura może być wykonana zbyt szybko, i przez to mogą pojawiać się problemy. Ja znam dwa typy waitów: DMA wait (do muzyki) i blitter wait (do grafiki), ale pewnie mogą być jeszcze inne. Po prostu musiałbys poszukać procedury, która jest wykonywana zbyt szybko i ją spowolnić. Ale co i jak to już musisz dojść samemu.
Co do extra waitów, to po prostu 68040 jest szybsza niż 68030, i jakaś procedura może być wykonana zbyt szybko, i przez to mogą pojawiać się problemy. Ja znam dwa typy waitów: DMA wait (do muzyki) i blitter wait (do grafiki), ale pewnie mogą być jeszcze inne. Po prostu musiałbys poszukać procedury, która jest wykonywana zbyt szybko i ją spowolnić. Ale co i jak to już musisz dojść samemu.
20.08.2009 12:18
[#75]
Re: Trudne początki z WHDLoad
@Don_Adan, post #74
W amosie to trzeba będzie zrobić zrzut po zrelokowaniu hunków przez wstępną procedure w pierwszym hunku ( o ile się dobrze zorientowałem na podstawie źródeł do amosa kompilatora ). Nie wiem czy już sama próba zrelokowania pozostałych hunków ( albo jednego hunka ) przy włączonym cache nie spowoduje przekłamań ( przydałaby się własna 040 ).
Jeśli chodzi o tą procedurę CMP to jak dobrze rozumiem to prosty komparator pamięci który wywala na wyjście róźnicę w jakimś tam formacie typu offset dana1, dana2. Czy analizuje jeszcze że to poprawny mnemonik 68000 ? Jakbyś mógł to podeślij mi to cudo na kiju.
A co do extra waitów. To jest jeszcze wait klawiatury coby handshake był ok. ( obadaj źródło keyboard.s z WHDLoad/src ). Sporo gier ma żenujące rozwiązania typu move.b $bfec001,d0. Albo niewłaściwe przerwanie PORTS. Najlepsze jakie widziałem to miała gra Ugh. Jakbyś chciał więcej informacji to daj znaka.
Jeśli chodzi o tą procedurę CMP to jak dobrze rozumiem to prosty komparator pamięci który wywala na wyjście róźnicę w jakimś tam formacie typu offset dana1, dana2. Czy analizuje jeszcze że to poprawny mnemonik 68000 ? Jakbyś mógł to podeślij mi to cudo na kiju.
A co do extra waitów. To jest jeszcze wait klawiatury coby handshake był ok. ( obadaj źródło keyboard.s z WHDLoad/src ). Sporo gier ma żenujące rozwiązania typu move.b $bfec001,d0. Albo niewłaściwe przerwanie PORTS. Najlepsze jakie widziałem to miała gra Ugh. Jakbyś chciał więcej informacji to daj znaka.
21.08.2009 12:42
[#76]
Re: Trudne początki z WHDLoad
@asman, post #75
Tak, to jest prosta procedura, która porównuje dwa pliki, ja używam jej do wyszukiwania zmian, kiedyś to były cracki i oryginały, a teraz to głównie gdzie co w pliku jest zmienione lub zwalone. podeślę Ci ją później. Na PC-cie, i być może na Amidze też są na pewno lepsze programy, które otwierają dwa okna i mają inne dodatkowe bajery. Jeśli chodzi o AMOS-a to możesz rozpakować exeka z pomocą xfd, ale wątpię żeby relokacja w AMOS-ie mogła być przyczyną nie dzialania gry pod 68040. Podejrzewam, że jeżeli to jest samomodyfkujący się kod, to raczej to jest jakaś starsza wersja AMOS-a, lub ktoś użył własnych dodatków. Chyba nowsze gry pisane w AMOS-ie Pro, raczej działają na 68040.