Witam!
Jako, że kręgosłup trochę szwankuje i jestem na przymusowym zwolnieniu postanowiłem zrobić porządki na Ami. Od dłuższego czasu chodziło za mną przetestowanie real AmiKit. Nie będę za bardzo rozpisywał w czym problem, chodzi mianowicie o "#8000003D", przeflancowałem chyba każdy wątek na forach gdzie pojawił się opisany problem. Po zainstalowaniu 3.9 na początku wyskakuje błąd z AmiDock, później większość programów wykrzacza się z błędem #8000003D. Do tej pory używam AmiSYS, żadnych problemów. Zauważyłem, że wiele osób miało/ma podobny problem zaraz po zainstalowaniu OS3.9, pełno jest pomocnych informacji na temat wersji bibliotek 060, pamięci, nawet teorii spiskowych o "podrabianych?" 060, jednak żadne nie pomagają. Co do sprzętu to jest to 1200+Apollo1240 (procek zmieniony na 060 pchnięty na 80MHz), 64MB, FastATA kick mapowany przez RemApollo.

Oczywiście. AmiSYS od prawie roku jest napędzany przez 060. Co ciekawe, jeśli zamontuje płyte z 3.9 pod AmiSYS wyskakuje mi requester z informacją o możliwej aktualizacji do 3.9, nawet wtedy po resecie mam problemy ze stabilnością systemu (#8000003D), zauważyłem też ciekawą rzecz:

Świeżo postawiony 3.9 - ShowConfig - 060/060mmu
AmiSys - ShowConfig - 060/060fpu/060mmu

Dobra znalazłem winowajcę :) Nie wiem tylko od której strony wziąć zaś. Mam też pytanie, czy Kick3.1 ma zaimplementowaną obsługę MMU? Dlaczego pytam Przy Kick3.0 gdy odpalę "whichamiga" pokazuję mi następujące info nt procesora

68060 80MHz
FPU - not available
MMU - not activate

natomiast przy zmapowanym 3.1 MMU jest od razu z informacja "running". To pytanie z kategorii "chciałbym wiedzieć" a teraz to z czym miałem problem. Na zagranicznych forach znalazłem ludzi, którzy mieli dokładnie ten sam problem jaki opisałem, po zainstalowaniu 3.9 na dzień dobry zwis przy Amidock z błędem #8000003D. Dzięki waszym sugestiom instalowałem każde biblioteki 040, 060 jakie znalazłem, niestety efekt zawsze był ten sam. Zrobiłem nawet dyskietkę ratunkową do 3.9 i przy jej pomocy zacząłem eksperymentować. Zlokalizowałem problem w następującym miejscu. Mapuję ROM przy pomocy remapollo do 3.1, domyślam się że problem leży w łatach instalowanych przez Setpatch (wersja 44.17 ta z OS3.9). Po kolei, po zmapowaniu Kicka3.1 odpalam whichamiga: FPU - not available, MMU - running, następnie Setpatch (wersja 43.7 z pakietu AmiSYS) i znowu whichamiga: FPU - 68060fpu, MMU - running, natomiast gdy użyję Setpatch 44.17 zainstaluje poprawki z wyłączeniem scsi.device (mam FastATE), to po ponownym resecie Amigi wystartowaniu bez s-s, jakiej bym nie użył komendy Setpatch, FPU za każdym razem jest "not available".

A czy przypadkiem dla RemApollo nie ma specjalnej wersji 68040.library?
Pamiętać musisz też, że system 3.1 (a taki masz w Kicku podczas inicjalizacji Amigi) rozpoznaje 68060 jako 68040. Po wydaniu komendy Setpatch biblioteka 68040.library zostaje wczytana z dysku. Jeżeli masz na dysku bibliotekę 68060.library, to jest ona wczytywana przez specjalną wersję 68040.libary (czyli kombinacja oryginalnej 68040.library z OS3.1 i 68060.library nie będzie działać poprawnie). Sytuację pogarszają (co już zauważyłeś) nakładki w rodzaju RemApollo, czy MMULib, w przypadku ich używania należy znaleźć 68040.library dedykowanej tym właśnie pakietom.
MMU przez AmigaOS nie jest używany, niektóre programy remapujące uzywają MMU, wtedy programy testujące pokazują "MMU running". FPU i MMU są inicjalizowane dopiero po uruchomieniu SetPatch, więc wcześniej (chyba) system ich nie rozpoznaje. Zresztą nawet jak je rozpoznaje, to i tak nie używa, o MMU już pisałem, FPU wykorzystują dopiero wersje programów skompilowane pod FPU (taka wersja odpalona na systemie bez FPU generuje Software Failure), istnieją tez biblioteki matematyczne, podmieniające te systemowe, których instalacja spowoduje wykorzystanie FPU przez zwykły soft.

Powoli tracę nadzieję, sam nawet patchowałem biblioteki do użytku z remapollo, efekt ten sam, zauważyłem że po zmapowaniu kicka3.1 i wydaniu komendy setpatch (44.17) brak jest następującej linijki: "68040 Support Code Loaded"