Próbowałem się bawić w regenerację baterii, zlecając to jednej z dużych firm się tym zajmujących (firma z Poznania). Niestety panowie polegli. Co prawda przeprosili, nie wzięli kasy i odesłali baterię po próbie regeneracji na własny koszt, niemniej nie wyszło.
Z tego co wiem, aktualna wersja MorphOS-a obsługuje wewnętrzny moduł WiFi w PowerBookach.
Wymiana pasty to skomplikowana operacja, ale mając doświadczenie w robótkach precyzyjnych i wspomagając się tutorialem z ifixit.com, można sobie poradzić.
Robienie dual boota – najpierw MacOS, potem MorphOS.
Co się będzie działo w przypadku „nie wyrabiamy się w ramce” zależy od organizacji procedury. Do timer.device wysyła się IORequest (wiadomość), która zostaje zwrócona albo po upływie określonego interwału czasowego, albo gdy czas systemowy osiągnie zadaną wartość. W najprostszym przypadku nasza procedura coramkowa wykorzystuje drugi tryb, za każdym razem po narysowaniu wszystkiego dodając te 1/60 sekundy do poprzedniej wartości i ponownie wysyłając request, na który czeka główna pętla. Co się stanie, gdy procedura będzie się wykonywać za długo? timer.device zwróci requesta od razu. Główna pętla nie będzie czekała, tylko będzie non-stop wywoływała naszą ramkową procedurę najszybciej jak się da.
Takie rozwiązanie jest słabe z dwóch powodów. Po pierwsze, jeżeli animację obiektów oprzesz o zliczanie wywołań procedury, to na niewyrabiającym się kompie akcja gry zwolni, podczas gdy zazwyczaj w takiej sytuacji słabego sprzętu chcemy mieć mniej fps, ale rzeczy mają się nadal dziać w czasie rzeczywistym. Po drugie, jeżeli np. w grze chwilowo mamy więcej obiektów i nie wyrabiamy się, ale po chwili robi się luźniej, to nasz mechanizm będzie potem „nadganiał” i gra będzie się toczyła szybciej niż normalnie.
Dlatego lepiej sobie na początku naszej procki odczytać czas rzeczywisty (też timer.device, odczyt jest bardzo tani w sensie czasu CPU) i po pierwsze wykorzystać go do animacji i fizyki, po drugie do zarządzania tempem renderingu (np. jeżeli jesteśmy w niedoczasie to można w ogóle nie wysyłać requesta do timer.device tylko dać na wyjściu flagę „wywołaj mnie ponownie bez czekania”).
Aha, jeżeli sobie odpuścimy kwestię synchronizacji rysowania sceny z odświeżaniem ramki, to zamiast zabawy z przerwaniami można po prostu użyć timer.device i mieć wywołanie co wybrany okres czasu. Zaletą wtedy jest to, że rytm wywoływania procedury nie zależy w żaden sposób od rzeczywistego odświeżania ekranu.
Jak znajdę czas na urlopie, to spróbuję dopisać artykuł, w którym zakręcę tymi trójkątami…
Powinieneś podpiąć procedurę pod przerwanie odświeżania obrazu. Na klasyku dodawałeś (systemowo, a jakże) handler do „ringu” handlerów przerwania VERTB (odchylania pionowego obrazu). Można założyć, że pod MorphOS-em to przerwanie jest co najmniej symulowane i AddIntServer() zadziała zgodnie z oczekiwaniami. A może nawet ono jest faktycznie wyzwalane rzeczywistym przerwaniem VERTB z karty graficznej, chociaż osobiście wątpię… To jest pytanie do Franka Mariaka i Marka Olsena. Jeżeli jest symulowane to możesz nie mieć synchronizacji aktualizacji ekranu z zmianą ramki.
W procedurze obsługi przerwania najprościej wysłać sobie sygnał do swojego procesu. W głównej pętli dodasz wtedy ten sygnał do zasadniczego Wait(). O ile procedura wywoływana po odebraniu tego sygnału zdąży się wykonać w jednej ramce, to będzie wywoływana co ramkę. A jak nie, to nic się nie stanie, wielokrotne ustawienie procesowi sygnału nie ma konsekwencji.
Podbijam, 14 dni.
Przyglądam się tematowi, ale nie chcę na razie nic obiecywać.
Problemów jest kilka:
1. MorphOS jest 32-bitowy. Ponieważ wszystkie procesy pracują w jednej przestrzeni adresowej, oznacza to limit 4 GB.
2. W tej samej przestrzeni muszą się zmieścić wszystkie peryferia, w tym pamięć karty graficznej. To nam zabiera jakieś 0,5 GB.
3. W dawnych czasach, gdy 2 GB wydawało się ilością absolutnie astronomiczną, programiści amigowi nadużywali najstarszego bitu adresu do niecnych celów (robi tak m. in. MUI). To nam odbiera „górne” 2 GB. Były podejmowane próby usunięcia tego ograniczenia, na razie bez większych sukcesów. To, plus punkt 2 zostawia nam 1,5 GB.
4. Ograniczenie do 1 GB jest specyficzne dla G5. Nie znam szczegółów ale to problem z zaprogramowaniem kontrolera pamięci albo tablic MMU i prawdopodobnie jest do rozwiązania, czyli G5 też powinno dojść do pułapu 1,5 GB.
To niestety póki co naturalne. G5 jest pod MorphOS-em ograniczony do 1,0 GB.
Ale poprzednia wersja używała dziurawej wersji OpenSSL.
Ten problem był badany. Serwer plusa online ma niepoprawną (i co gorsza poważnie niebezpieczną) konfigurację połączeń SSL. Ponieważ Odyssey nie ma tylu obejść i łatek na źle skonfigurowane serwery co Firefox, czy Chrome, połączenie się nie udaje.
No, nie takie szczątkowe, masz UCS4_FormatString() w locale.library i sporo innych funkcji, jest też charsets.library do konwersji. Faktem jest, że w MorphOS-ie przyjęto jako główne kodowania unikodu UTF-32 (big endian) i UTF-8, szesnastka jest obsługiwana pośrednio przez charsets.library.
Ja mam coś w swoim prywatnym repozytorium, ale na razie nie spełnia dwóch ostatnich warunków…
Mi się wydaje, że problemem jest w tym momencie SFS. Być może taki plik możesz nawet zapisać w całości oraz sekwencyjnie odczytać w całości (co robi konsolowy tar). Ale na pewno nie zadziała Ci swobodne przemieszczanie się po pliku. Przed zgłaszaniem błędów stworzyłbym testową partycję w IceFS i sprawdził jak wtedy zachowują się oba te programy.
Hmm, albo Ambient próbuje rozpakować archiwum do pamięci (co się z oczywistych powodów nie może udać), albo może ma problem z archiwum większym niż 2 GB. A może to system plików ma ten problem, w jakim systemie masz partycję, na którym leży to archiwum? Tak czy inaczej wysłałbym raport przez systemowe narzędzie (to w okienku „o MorphOS-ie”), jeżeli np. słabo czujesz się w angielskim to wal po polsku (Niemcy ładują raporty po niemiecku i problemu nie ma większego, a paru Polaków w teamie w końcu jest…).
Tak na marginesie, zastanawiam się co to za genialny kod, że kompiluje się pod 4.6.4 a pod 4.4.5 nie…
Copyright 2014 - Wszelkie prawa zastrzeżone MorphOS.pl