30.12.2009 12:40
[#1]
patches dla AOS3.9 + RTG
Nawiązując do ciekawego tematu na amiga.org http://www.amiga.org/forums/showthread.php?t=50876, który jednak dość słabo się rozwija pozwoliłem sobie rzucić temat na ppa.pl
Założenie jest takie, że instalujemy AOS 3.9 (+BB1+BB2+BB3) na Amidze z kartą gfx. Powstaje pytanie, które patche jest sens użyć, tak więc:
1. Blizkick/RemApollo itp. - jest sens mapować kickstart 3.1 do fastu skoro i tak AOS 3.9 ładuje swojego ROM Update?
2. fblit & ftext - na kartach gfx zbędne, chyba, że ma się Retine Z2, wtedy ta karta gfx wrzuca wszystko do fastu (a nie do chipu), testowane, rewelka. ;)
3. Powericons (+iconbefast) - rzekomo przyspiesza nawet standardowe ikonki.
3a. AfaOS - strasznie się tego boję i wygląda to dla mnie jak jeden wielki hack na systemie. Jednocześnie pytanie odnośnie picture.datatype, czy jest sens używać tego z afaos (68k) skoro 3.9 ma swój picture.datatype pod ppc?
4. MCP - ale to to chyba wszyscy używają.
4a. Patchcontrol - potrzebne to to z najnowszymi wersjami MCP?
5. Fastiprefs - potrzebne to to do 3.9?
6. gfxroute - tego nie znam, ale podobno zmusza stare programy do użycia fastu zamiast chipu (ale przecież to samo można zrobić przez MCP?).
7. copymem/oxypatcher/cyberpatcher - ma to sens przy OS 3.9 oraz przy rozwianych HSMathlibs (które są bardzo szybkie)?
8. TLSFMem - ogranicza fragmentację pamięci, używał kotoś?
Założenie jest takie, że instalujemy AOS 3.9 (+BB1+BB2+BB3) na Amidze z kartą gfx. Powstaje pytanie, które patche jest sens użyć, tak więc:
1. Blizkick/RemApollo itp. - jest sens mapować kickstart 3.1 do fastu skoro i tak AOS 3.9 ładuje swojego ROM Update?
2. fblit & ftext - na kartach gfx zbędne, chyba, że ma się Retine Z2, wtedy ta karta gfx wrzuca wszystko do fastu (a nie do chipu), testowane, rewelka. ;)
3. Powericons (+iconbefast) - rzekomo przyspiesza nawet standardowe ikonki.
3a. AfaOS - strasznie się tego boję i wygląda to dla mnie jak jeden wielki hack na systemie. Jednocześnie pytanie odnośnie picture.datatype, czy jest sens używać tego z afaos (68k) skoro 3.9 ma swój picture.datatype pod ppc?
4. MCP - ale to to chyba wszyscy używają.
4a. Patchcontrol - potrzebne to to z najnowszymi wersjami MCP?
5. Fastiprefs - potrzebne to to do 3.9?
6. gfxroute - tego nie znam, ale podobno zmusza stare programy do użycia fastu zamiast chipu (ale przecież to samo można zrobić przez MCP?).
7. copymem/oxypatcher/cyberpatcher - ma to sens przy OS 3.9 oraz przy rozwianych HSMathlibs (które są bardzo szybkie)?
8. TLSFMem - ogranicza fragmentację pamięci, używał kotoś?
30.12.2009 15:02
[#2]
Re: patches dla AOS3.9 + RTG
@radzik, post #1
1. Faktycznie nie ma sensu.
3. Pozbądź się i zainteresuj AfA OS
3a. Nie przeszkadza Ci PowerIcons i inne z tej listy, które w rzeczywistości są hackami a czepiasz się przeportowanego na AOS3 fragmentu AROSA - AFA nie jest hackiem, to raczej aktualizacja dla AOS3
4a Tak.
5. Nie.
6. Jeżeli program jest tak tragicznie napisany, że trzeba go zmuszać, żeby korzystał z FAST zamiast CHIP to ja bym sobie takie "cudo" darował. W ogóle o jakie niby programy chodzi?
7. OXYPatcher to nie łatka na biblioteki matematyczne a "łata" na procesor 68060 (i w mniejszym stopniu 68040), przyspieszająca jego pracę ze starymi, niezoptymalizowanymi, dla niego programami - to tak w dużym skrócie.
8. Swego czasu największy producent GURU na mojej Ami. ;)
3. Pozbądź się i zainteresuj AfA OS
3a. Nie przeszkadza Ci PowerIcons i inne z tej listy, które w rzeczywistości są hackami a czepiasz się przeportowanego na AOS3 fragmentu AROSA - AFA nie jest hackiem, to raczej aktualizacja dla AOS3
4a Tak.
5. Nie.
6. Jeżeli program jest tak tragicznie napisany, że trzeba go zmuszać, żeby korzystał z FAST zamiast CHIP to ja bym sobie takie "cudo" darował. W ogóle o jakie niby programy chodzi?
7. OXYPatcher to nie łatka na biblioteki matematyczne a "łata" na procesor 68060 (i w mniejszym stopniu 68040), przyspieszająca jego pracę ze starymi, niezoptymalizowanymi, dla niego programami - to tak w dużym skrócie.
8. Swego czasu największy producent GURU na mojej Ami. ;)
30.12.2009 20:49
[#4]
Re: patches dla AOS3.9 + RTG
@Korni, post #3
Korni napisał(a):
> 1. Jest.
Banalne pytanie, dlaczego?
> 3. Najlepiej jest bez ikonek ;).
Też fakt. Czyli DOpus 5... niestety do mnie nie przemawia.
#2
APC74 napisał(a):
> 3a. Nie przeszkadza Ci PowerIcons i inne z tej listy, które w
> rzeczywistości są hackami a czepiasz się przeportowanego na
> AOS3 fragmentu AROSA - AFA nie jest hackiem, to raczej
> aktualizacja dla AOS3
Czytałem na różnych forach, że różnie AfaOS działa no i potrafi zamulić 68k.
> 7. OXYPatcher to nie łatka na biblioteki matematyczne a "łata"
> na procesor 68060 (i w mniejszym stopniu 68040),
> przyspieszająca jego pracę ze starymi, niezoptymalizowanymi,
> dla niego programami - to tak w dużym skrócie.
Niby to samo robią szybkie biblioteki matematyczne.
> 1. Jest.
Banalne pytanie, dlaczego?
> 3. Najlepiej jest bez ikonek ;).
Też fakt. Czyli DOpus 5... niestety do mnie nie przemawia.
#2
APC74 napisał(a):
> 3a. Nie przeszkadza Ci PowerIcons i inne z tej listy, które w
> rzeczywistości są hackami a czepiasz się przeportowanego na
> AOS3 fragmentu AROSA - AFA nie jest hackiem, to raczej
> aktualizacja dla AOS3
Czytałem na różnych forach, że różnie AfaOS działa no i potrafi zamulić 68k.
> 7. OXYPatcher to nie łatka na biblioteki matematyczne a "łata"
> na procesor 68060 (i w mniejszym stopniu 68040),
> przyspieszająca jego pracę ze starymi, niezoptymalizowanymi,
> dla niego programami - to tak w dużym skrócie.
Niby to samo robią szybkie biblioteki matematyczne.
30.12.2009 21:13
[#6]
Re: patches dla AOS3.9 + RTG
@radzik, post #4
Oxypatcher i szybkie biblioteki matematyczne robią zupełnie inne rzeczy:
Oxypatcher zajmuje sie obsługą nieobsługiwanych sprzętowo instrukcji w procesorach 68040 i 68060. Instrukcje te pojawiają się w wielu programach skompilowanych dla wczesniejszych wersji 68k (do 68030 włącznie), nie zawsze są wersje dla 040/060, obecność tych instrukcji potrafi bardzo zamulić program na co lekarstwem jest Oxpatcher (i inne podobne łatki). Dają one zauważalny efekt na 68040 i większy na 68060.
Szybkie biblioteki matematyczne są to standardowe biblioteki matematyczne AmigaOS skompilowane pod obsługę koprocesora arytmetycznego (gdyż biblioteki dostarczone z systemem nie korzystają z FPU). Dają korzyść przy obecności FPU (a więc juz od 68EC020+68881/68882).
Oxypatcher zajmuje sie obsługą nieobsługiwanych sprzętowo instrukcji w procesorach 68040 i 68060. Instrukcje te pojawiają się w wielu programach skompilowanych dla wczesniejszych wersji 68k (do 68030 włącznie), nie zawsze są wersje dla 040/060, obecność tych instrukcji potrafi bardzo zamulić program na co lekarstwem jest Oxpatcher (i inne podobne łatki). Dają one zauważalny efekt na 68040 i większy na 68060.
Szybkie biblioteki matematyczne są to standardowe biblioteki matematyczne AmigaOS skompilowane pod obsługę koprocesora arytmetycznego (gdyż biblioteki dostarczone z systemem nie korzystają z FPU). Dają korzyść przy obecności FPU (a więc juz od 68EC020+68881/68882).
30.12.2009 21:16
[#7]
Re: patches dla AOS3.9 + RTG
@radzik, post #4
"Niby to samo robią szybkie biblioteki matematyczne."
nie. biblioteki matematyczne pomoga tylko jezeli cos uzywa bibliotek matematycznych. jezeli programy same uzywaja koprocesora to biblioteki w niczym nie pomoga. biblioteki nie pomoga tez przy innych instrukcjach ktorych nie ma na 060 (sa wolno emulowane)
nie. biblioteki matematyczne pomoga tylko jezeli cos uzywa bibliotek matematycznych. jezeli programy same uzywaja koprocesora to biblioteki w niczym nie pomoga. biblioteki nie pomoga tez przy innych instrukcjach ktorych nie ma na 060 (sa wolno emulowane)
30.12.2009 21:24
[#8]
Re: patches dla AOS3.9 + RTG
@radzik, post #4
1. Patrz post Sir_Lucasa, to samo odnosi się do RemApollo. Ogólnie, kick z FastRamu jest szybszy od tego, który siedzi w kości ROM. Dowolność ładowania modułów, rozpakowujesz "Amiga ROM UPDATE" i wybierasz te moduły, które chcesz.
3. Niekoniecznie DOpus5, dobry jest też DOpus4, do tego KingCON i można działać.
3. Niekoniecznie DOpus5, dobry jest też DOpus4, do tego KingCON i można działać.
30.12.2009 23:12
[#11]
Re: patches dla AOS3.9 + RTG
@radzik, post #4
Czytałem na różnych forach, że różnie AfaOS działa no i potrafi zamulić 68k.
Z wczesnymi wersjami działy się różne rzeczy i AfA np. potrafił powiesić AOSa przy zapisie zmienionych ustawień ikonek png (Tooltypes, Stack itd.). Jednak najnowsza wersja 4.6 ( http://www.ppa.pl/afa.os.4.6,7365;aktualnosci.html ), którą testuję od października, jeszcze nie sprawiła mi żadnego kłopotu. Co do spowolnień to trudno mi powiedzieć - używam AfA pod WinUAE, ale podejrzewam, że jak będziesz miał dużo ikonek png w katalogu, to faktycznie może to spowolnić odczyt katalogu. Poza tym nowe, wypasione skórki na Workbencha też swój haracz pobiorą, jednak jeżeli nie masz ochoty na ich używanie, to możesz wodotryski wyłączyć. Z drugiej strony - jeżeli używałeś Birdie, VisualPrefs i innych upiększaczy na AOS i teraz zamienisz je na AfA to oprócz podniesienia stabilności systemu i rewelacyjnego wyglądu wszystkich okien systemu i różnych programów (chociaż to kwestia gustu, ale jest z czego wybierać), z którymi nawet Birdie sobie nie radziło zauważysz niewielkie przyspieszenie systemu. Tyle z mojej strony o wodotryskach, ale AfA to nie tylko wodotryski - to (wreszcie!) porządny kanał alfa dla picture datatype i obsługa czcionek TTF z antyaliasingiem.
Jeżeli chcesz używać wszystkich funkcji AfAOS to musisz zrezygnować z PowerIcons, Birdie i VisualPrefs itp. jeżeli miałeś je zainstalowane wcześniej, żeby programy się nie gryzły (i nie produkowały GURU) - wydaje mi się, że to najczęstszy powód wieszania się systemu po instalacji AfA. Gdy Birdie i AfA próbują jednocześnie skórować otwierane okienka a do tego VisualPrefs i PowerIcons dorzucają swoje 3 grosze to nieszczęście wisi w powietrzu. ;)
Kurde, ale reklamówkę strzeliłem... :D
Z wczesnymi wersjami działy się różne rzeczy i AfA np. potrafił powiesić AOSa przy zapisie zmienionych ustawień ikonek png (Tooltypes, Stack itd.). Jednak najnowsza wersja 4.6 ( http://www.ppa.pl/afa.os.4.6,7365;aktualnosci.html ), którą testuję od października, jeszcze nie sprawiła mi żadnego kłopotu. Co do spowolnień to trudno mi powiedzieć - używam AfA pod WinUAE, ale podejrzewam, że jak będziesz miał dużo ikonek png w katalogu, to faktycznie może to spowolnić odczyt katalogu. Poza tym nowe, wypasione skórki na Workbencha też swój haracz pobiorą, jednak jeżeli nie masz ochoty na ich używanie, to możesz wodotryski wyłączyć. Z drugiej strony - jeżeli używałeś Birdie, VisualPrefs i innych upiększaczy na AOS i teraz zamienisz je na AfA to oprócz podniesienia stabilności systemu i rewelacyjnego wyglądu wszystkich okien systemu i różnych programów (chociaż to kwestia gustu, ale jest z czego wybierać), z którymi nawet Birdie sobie nie radziło zauważysz niewielkie przyspieszenie systemu. Tyle z mojej strony o wodotryskach, ale AfA to nie tylko wodotryski - to (wreszcie!) porządny kanał alfa dla picture datatype i obsługa czcionek TTF z antyaliasingiem.
Jeżeli chcesz używać wszystkich funkcji AfAOS to musisz zrezygnować z PowerIcons, Birdie i VisualPrefs itp. jeżeli miałeś je zainstalowane wcześniej, żeby programy się nie gryzły (i nie produkowały GURU) - wydaje mi się, że to najczęstszy powód wieszania się systemu po instalacji AfA. Gdy Birdie i AfA próbują jednocześnie skórować otwierane okienka a do tego VisualPrefs i PowerIcons dorzucają swoje 3 grosze to nieszczęście wisi w powietrzu. ;)
Kurde, ale reklamówkę strzeliłem... :D
31.12.2009 00:28
[#12]
Re: patches dla AOS3.9 + RTG
@wali7, post #10
No właśnie też mi się coś tak wydawało, że OXYPatcher jest wydajniejszy.
#11
Ciekawi mnie właśnie różnica między tymi picture.datatype, szczególnie, że wersja z OS 3.9 jest pod PPC (ale czy to cokolwiek przyspiesza oto pytanie) a z AfAOS jest dużo nowocześniejsza. I którą tu wybrać... ;)
Co do TTF z antyaliasingiem pod 68k to raczej to nie ma żadnego sensu.
#11
Ciekawi mnie właśnie różnica między tymi picture.datatype, szczególnie, że wersja z OS 3.9 jest pod PPC (ale czy to cokolwiek przyspiesza oto pytanie) a z AfAOS jest dużo nowocześniejsza. I którą tu wybrać... ;)
Co do TTF z antyaliasingiem pod 68k to raczej to nie ma żadnego sensu.
31.12.2009 09:39
[#13]
Re: patches dla AOS3.9 + RTG
@radzik, post #12
Jesteś pewien, że picture.datatype na płycie z AOS3.9 jest w wersji PPC? Zresztą, nieważne.
Tak sobie poteoretyzuję (przydałoby się, żeby zweryfikował te moje wynurzenia ktoś lepiej obeznany z tematem datatypes i PPC dla klasyka).
Picture.datatype jako superklasa, czy inaczej międzymordzie (interface) pomiędzy programami a datatypami graficznymi nie ma zbyt wiele do roboty (tak mi się przynajmniej wydaje) - czarną robotę odwalają tu ilbm.datatype, png.datatype, jpg.datatype itp. Picture.datatype w tym wszystkim ma jedynie wywoływać odpowiednie datatypy do dekodowania obrazka i dostarczyć wyniki pracy datatypów do programów. To czy wersja PPC picture.datatype przyśpieszy ten proces, w rzeczywistości zależy od tego, jak wiele masz programów pod PPC korzystających z datatype graficznych. Jeżeli większość Twoich programów (odwołujących się do picture.datatype) to programy pod PPC to faktycznie powinno to przyspieszyć współpracę programów z datatypami, bo rzadziej będzie występował "context swich" (przełączanie się karty PPC z trybu pracy PPC na 68k i odwrotnie). W przypadku gdy częściej używasz programów 68k odwołujących się do picture.datatype to chyba lepiej mieć ten datatype w wersji 68k (a tylko jego podklasy w wersji PPC).
Tak sobie poteoretyzuję (przydałoby się, żeby zweryfikował te moje wynurzenia ktoś lepiej obeznany z tematem datatypes i PPC dla klasyka).
Picture.datatype jako superklasa, czy inaczej międzymordzie (interface) pomiędzy programami a datatypami graficznymi nie ma zbyt wiele do roboty (tak mi się przynajmniej wydaje) - czarną robotę odwalają tu ilbm.datatype, png.datatype, jpg.datatype itp. Picture.datatype w tym wszystkim ma jedynie wywoływać odpowiednie datatypy do dekodowania obrazka i dostarczyć wyniki pracy datatypów do programów. To czy wersja PPC picture.datatype przyśpieszy ten proces, w rzeczywistości zależy od tego, jak wiele masz programów pod PPC korzystających z datatype graficznych. Jeżeli większość Twoich programów (odwołujących się do picture.datatype) to programy pod PPC to faktycznie powinno to przyspieszyć współpracę programów z datatypami, bo rzadziej będzie występował "context swich" (przełączanie się karty PPC z trybu pracy PPC na 68k i odwrotnie). W przypadku gdy częściej używasz programów 68k odwołujących się do picture.datatype to chyba lepiej mieć ten datatype w wersji 68k (a tylko jego podklasy w wersji PPC).
31.12.2009 11:36
[#16]
Re: patches dla AOS3.9 + RTG
@kiero, post #14
Ano właśnie, z tym, że w przypadku niektórych datatypów również ditheringiem zajmuje się podklasa a nie picture.datatype - np. akPNG.datatype tak ma (i inne datatypy tego autora).
Multiview robi chyba skalowanie za pomocą datatypu, gdy próbuje się otworzyć zbyt duży obrazek?
Ostatnia modyfikacja: 31.12.2009 11:37:33
Multiview robi chyba skalowanie za pomocą datatypu, gdy próbuje się otworzyć zbyt duży obrazek?
Ostatnia modyfikacja: 31.12.2009 11:37:33