Komentowana treść: Technologia SNAP i Amiga
04.09.2004 01:32
[#61]
Re: Technologia SNAP i Amiga
@Konrad Klar, post #58
W odpowiedzi na komentarz #58
Ano właśnie. Niektórzy chyba o tym zapominają. Więc jeśli dla jakiegoś chipsetu są tylko binarne sterowniki dla x86, to na Amidze takie sterowniki się nie przydadzą.
Właśnie. Autor njusa pomieszał dwie sprawy. Temat sterowników, który nie jest nowością, bo o SNAPie dyskutowaliśmy już w lutym 2003, oraz temat emulatora BIOSu, który też nie jest nowy. Bo przecież od dawna można używać pecetowych kart w Pegasosach i w A1 też. Czemu więc ma służyć to odgrzewanie starych kotletów? Celom marketingowym - to jedyna odpowiedź, jaka przychodzi mi do głowy.
Nie. Np. pegazowy OpenFirmware widzi partycje na dysku i potrafi czytać pliki z różnych systemów plików, między innymi FFS, SFS, Ext2, FAT, itd. To pecetowe BIOSy są takie ograniczone, że wymagają boot bloków, trzeba używać LILO itp. badziewia.
Dobrze jeszcze mieć świadomość, że nie zawsze wrapper jest idealnym rozwiązaniem. Co jeśli sterownikowi pisanemu z myślą o innej platformie brakuje jakiś funkcji/trybów dostępnych w systemie na którym ma działać wrapper?
Chyba nie bez powodu powstały "natywne" (nieSNAPowe) sterowniki dla Radeonów dla OS4.
Właśnie!
procesora właściwie
Ano właśnie. Niektórzy chyba o tym zapominają. Więc jeśli dla jakiegoś chipsetu są tylko binarne sterowniki dla x86, to na Amidze takie sterowniki się nie przydadzą.
Nie wiem tylko co to ma wspólnego z BIOS
Właśnie. Autor njusa pomieszał dwie sprawy. Temat sterowników, który nie jest nowością, bo o SNAPie dyskutowaliśmy już w lutym 2003, oraz temat emulatora BIOSu, który też nie jest nowy. Bo przecież od dawna można używać pecetowych kart w Pegasosach i w A1 też. Czemu więc ma służyć to odgrzewanie starych kotletów? Celom marketingowym - to jedyna odpowiedź, jaka przychodzi mi do głowy.
Jeżeli miałby być taki sterownik wczytywany z dysku jeszcze w fazie startu BIOSu to oznacza aktywację filesystemu, wczytanego z RDB, a więc już faktycznie uruchomienie konkretnego OSu czyli AmigaOS w tym przypadku.
Nie. Np. pegazowy OpenFirmware widzi partycje na dysku i potrafi czytać pliki z różnych systemów plików, między innymi FFS, SFS, Ext2, FAT, itd. To pecetowe BIOSy są takie ograniczone, że wymagają boot bloków, trzeba używać LILO itp. badziewia.
i tak potrzebny jest od strony systemu wrapper
Dobrze jeszcze mieć świadomość, że nie zawsze wrapper jest idealnym rozwiązaniem. Co jeśli sterownikowi pisanemu z myślą o innej platformie brakuje jakiś funkcji/trybów dostępnych w systemie na którym ma działać wrapper?
Chyba nie bez powodu powstały "natywne" (nieSNAPowe) sterowniki dla Radeonów dla OS4.
I absurdem jest mieszanie do tego sterowników czy BIOSów
dla x86, jak to zostało zasygnalizowane w temacie.
Właśnie!
05.09.2004 00:37
[#65]
Re: Technologia SNAP i Amiga
@ravek, post #61
W odpowiedzi na komentarz #61
No ale jeśli w RDB będzie siedział inny filesystem niż wyżej wymienione i on będzie używany jako fs partycji startowej to zima.
Ale nie będę się czepiać szczegółów konkretnych rozwiązań Pegasosa czy A1.
Bez urazy, teraz ja polecam Ci ten dokument, do którego sam dostałem link. Każdy system ma swoje odpowiedniki OpenWindow() czy
LockScreen (), nazywają się tam te funkcje różnie, różne przyjmują argumenty, niektóre pojęcia nie występują w pewnych OSach. Wrapper ma przełożyć te wywołania na "język" zrozumiały dla SNAPa, który zajmuje się stroną czysto sprzętową - przełączaniem rejestrów i przerzucaniem danych.
Natywne sterowniki powstawały z oczywistych względów - z braku uniwersalnych - crosssystemowych. Pewnie, że jeżeli SNAPowemu sterownikowi brakować będzie 3D, overlay, czy dodatkowych funkcji, jakich pełno w nowych kartach, przegra w rywalizacji z natywnym. Może jednak w tej chwili wygrać walkoverem, będzie i tak lepszy niż nienapisany (przez Hyperion) natywny.
Z trzeciej strony, jeśli się to przyjmie, pisaniem sterowników zajmą się ATI, NVidia i inni potentaci i odciążą firmy typu Hyperion od niewdzięcznego zadania.
Jeżeli miałby być taki sterownik wczytywany z dysku jeszcze w fazie startu BIOSu to oznacza aktywację filesystemu, wczytanego z RDB, a więc już faktycznie uruchomienie konkretnego OSu czyli AmigaOS w tym przypadku.
Nie. Np. pegazowy OpenFirmware widzi partycje na dysku i potrafi czytać pliki z różnych systemów plików, między innymi FFS, SFS, Ext2, FAT, itd. To pecetowe BIOSy są takie ograniczone, że wymagają boot bloków, trzeba używać LILO itp. badziewia.
No ale jeśli w RDB będzie siedział inny filesystem niż wyżej wymienione i on będzie używany jako fs partycji startowej to zima.
Ale nie będę się czepiać szczegółów konkretnych rozwiązań Pegasosa czy A1.
i tak potrzebny jest od strony systemu wrapper
Dobrze jeszcze mieć świadomość, że nie zawsze wrapper jest idealnym rozwiązaniem. Co jeśli sterownikowi pisanemu z myślą o innej platformie brakuje jakiś funkcji/trybów dostępnych w systemie na którym ma działać wrapper?
Chyba nie bez powodu powstały "natywne" (nieSNAPowe) sterowniki dla Radeonów dla OS4.
Bez urazy, teraz ja polecam Ci ten dokument, do którego sam dostałem link. Każdy system ma swoje odpowiedniki OpenWindow() czy
LockScreen (), nazywają się tam te funkcje różnie, różne przyjmują argumenty, niektóre pojęcia nie występują w pewnych OSach. Wrapper ma przełożyć te wywołania na "język" zrozumiały dla SNAPa, który zajmuje się stroną czysto sprzętową - przełączaniem rejestrów i przerzucaniem danych.
Natywne sterowniki powstawały z oczywistych względów - z braku uniwersalnych - crosssystemowych. Pewnie, że jeżeli SNAPowemu sterownikowi brakować będzie 3D, overlay, czy dodatkowych funkcji, jakich pełno w nowych kartach, przegra w rywalizacji z natywnym. Może jednak w tej chwili wygrać walkoverem, będzie i tak lepszy niż nienapisany (przez Hyperion) natywny.
Z trzeciej strony, jeśli się to przyjmie, pisaniem sterowników zajmą się ATI, NVidia i inni potentaci i odciążą firmy typu Hyperion od niewdzięcznego zadania.
06.09.2004 00:21
[#70]
Re: Technologia SNAP i Amiga
@ravek, post #61
W odpowiedzi na komentarz #61
Przeczytaj ta dokumnetacje najpierw dokladnie poznaj zasade dzialania pozniej sie wypowiadaj bo widze ze nadal nie masz pojecia o zasadzie dzilania SNAP.
Nie wiem czy wiesz ale w programowaniu dazy sie do czegos takiego jak "ponowne urzycie" a SNAP jest tego najlepszym przykladem.
Przeczytaj ta dokumnetacje najpierw dokladnie poznaj zasade dzialania pozniej sie wypowiadaj bo widze ze nadal nie masz pojecia o zasadzie dzilania SNAP.
Nie wiem czy wiesz ale w programowaniu dazy sie do czegos takiego jak "ponowne urzycie" a SNAP jest tego najlepszym przykladem.
06.09.2004 05:32
[#71]
Re: Technologia SNAP i Amiga
@Konrad Klar, post #65
W odpowiedzi na komentarz #65
Racja. Dlatego ta partycja musi być w systemie plików obsługiwanym przez firmware.
Oj, chyba wyraziłem się nieprecyzyjnie. Oczywiście absurdem byłoby pakować tam rysowanie okienek. Chodziło mi tylko niskopoziomowe funkcje graficznie i tryby.
Często sterowniki nie wykorzystują wszystkich funkcji układów, bo po prostu wyższe warstwy systemu ich nie potrzebują.
Właśnie brakuje.
Opieram się na dokumencie, do którego ktoś już tu wcześniej podał odnośnik:
Czego jeszcze brakuje - nie wiem. Zaznaczam, że ja nie krytykuję samej idei separacji kodu odwołującego się do sprzętu od reszty. Bo to też nie jest nowy pomysł.
O, tak, tak. To bardzo prawdopodobne
Sytuacja jest taka, że producenci układów dostarczają binarne sterowniki dla nowych chipsetów i dobrze strzegą swoich tajemnic. Dokumentacja jest dostępna dla słabszych układów, czyli do Radeona 9200 i niższych modeli, i to pod NDA.
Ucieszyłbym się gdyby ATI dostarczyło sterownik zawierający obsługę 2D i 3D dla nowych układów w postaci biblioteki skompilowanej dla PPC. Wtedy mogłyby się pojawić sterowniki dla Morphosa i OS4 z niej korzystające. I żeby to wszystko jeszcze działało stabilniej niż ich linuksowe sterowniki... Niestety ile razy postanawiam przetestować sterowniki producenta dla Linuksa/x86, to szybko wracam do opensourcowych.
No ale jeśli w RDB będzie siedział inny filesystem niż wyżej wymienione i on będzie używany jako fs partycji startowej to zima.
Racja. Dlatego ta partycja musi być w systemie plików obsługiwanym przez firmware.
OpenWindow()
Oj, chyba wyraziłem się nieprecyzyjnie. Oczywiście absurdem byłoby pakować tam rysowanie okienek. Chodziło mi tylko niskopoziomowe funkcje graficznie i tryby.
Często sterowniki nie wykorzystują wszystkich funkcji układów, bo po prostu wyższe warstwy systemu ich nie potrzebują.
jeżeli SNAPowemu sterownikowi brakować będzie 3D, overlay, czy dodatkowych funkcji
Właśnie brakuje.
Opieram się na dokumencie, do którego ktoś już tu wcześniej podał odnośnik:
"SNAP Currently Lacks 3D support
- True. Currently SciTech SNAP Graphics lacks 3D support. SciTech has done much of the groundwork required to remedy this in a future release. However, a great deal of work remains, and will require a significant investment of resources to complete."
"SciTech SNAP lacks XVideo support (hardware overlays).
- True, at the present time SciTech SNAP has not yet implemented this feature. However, much of the foundational work is complete and ready for inclusion at a future date. The primary roadblock at this time is lack of direct customer demand and associated funding."
Czego jeszcze brakuje - nie wiem. Zaznaczam, że ja nie krytykuję samej idei separacji kodu odwołującego się do sprzętu od reszty. Bo to też nie jest nowy pomysł.
Może jednak w tej chwili wygrać walkoverem, będzie i tak lepszy niż nienapisany (przez Hyperion) natywny.
O, tak, tak. To bardzo prawdopodobne
pisaniem sterowników zajmą się ATI, NVidia
Sytuacja jest taka, że producenci układów dostarczają binarne sterowniki dla nowych chipsetów i dobrze strzegą swoich tajemnic. Dokumentacja jest dostępna dla słabszych układów, czyli do Radeona 9200 i niższych modeli, i to pod NDA.
Ucieszyłbym się gdyby ATI dostarczyło sterownik zawierający obsługę 2D i 3D dla nowych układów w postaci biblioteki skompilowanej dla PPC. Wtedy mogłyby się pojawić sterowniki dla Morphosa i OS4 z niej korzystające. I żeby to wszystko jeszcze działało stabilniej niż ich linuksowe sterowniki... Niestety ile razy postanawiam przetestować sterowniki producenta dla Linuksa/x86, to szybko wracam do opensourcowych.
07.09.2004 01:37
[#72]
Re: Technologia SNAP i Amiga
@ravek, post #71
W odpowiedzi na komentarz #71
Zgoda, coś tam musi być obsługiwane w ROMie, aby był jakiś punkt zaczepienia do doczytania reszty z dysku, czy innego "mass storage device". Mam tylko taką wątpliwość, co do pakowania w ROM obsługi jak największej ilości formatów tego czy owego. SFS, który jest na liście obsługiwanych, miał już w swojej historii zmian epizod wymuszający przeformatowanie jego wcześniejszych partycji. No ale, jako się rzekło, nie będę się czepiać szczegółów i jeśli będą w tym czy innym ROMie nadmiarowe procedury, to nic nie szkodzi, niech sobie "leżą i jeść nie proszą".
P.S. ...choć wolałbym aby to "partycja musi być w systemie plików obsługiwanym przez firmware" przybrało postać "kod filesystemu musi znajdować się w RDB, MBR lub innym systemie partycjonowania dysku obsługiwanym przez firmware" w ostatecznym rozwiązaniu.
Wyraziłeś się precyzyjnie. Powinienem raczej podać przykład z graphics.library. Wrapper, o którym mówiłem, byłby dla SNAPowego sterownika właśnie tym czym intuition dla graphics czyli "API nad API". Nie znalazłem dla tego innego zwięzłego określenia, niż właśnie wrapper, choć nie jest onocałkiem precyzyjne w tym wypadku.
Sterownik SNAP byłby (jest) ze swej natury binarny. Jeżeli komuś jest dostarczana dokumentacja, na takiej czy innej licencji, to chyba dlatego, że zależy producentom na innych rynkach niż jedynie słuszny OS. Chyba, że sugerujesz sytuację, w której na opłatach licencyjnych mają większe zyski, niż na sprzedaży kart użytkownikom mniej popularnych systemów - wtedy los SNAPa byłby marny...
No ale jeśli w RDB będzie siedział inny filesystem niż wyżej wymienione i on będzie używany jako fs partycji startowej to zima.
Racja. Dlatego ta partycja musi być w systemie plików obsługiwanym przez firmware.
Zgoda, coś tam musi być obsługiwane w ROMie, aby był jakiś punkt zaczepienia do doczytania reszty z dysku, czy innego "mass storage device". Mam tylko taką wątpliwość, co do pakowania w ROM obsługi jak największej ilości formatów tego czy owego. SFS, który jest na liście obsługiwanych, miał już w swojej historii zmian epizod wymuszający przeformatowanie jego wcześniejszych partycji. No ale, jako się rzekło, nie będę się czepiać szczegółów i jeśli będą w tym czy innym ROMie nadmiarowe procedury, to nic nie szkodzi, niech sobie "leżą i jeść nie proszą".
P.S. ...choć wolałbym aby to "partycja musi być w systemie plików obsługiwanym przez firmware" przybrało postać "kod filesystemu musi znajdować się w RDB, MBR lub innym systemie partycjonowania dysku obsługiwanym przez firmware" w ostatecznym rozwiązaniu.
OpenWindow()
Oj, chyba wyraziłem się nieprecyzyjnie. Oczywiście absurdem byłoby pakować tam rysowanie okienek. Chodziło mi tylko niskopoziomowe funkcje graficznie i tryby.
Wyraziłeś się precyzyjnie. Powinienem raczej podać przykład z graphics.library. Wrapper, o którym mówiłem, byłby dla SNAPowego sterownika właśnie tym czym intuition dla graphics czyli "API nad API". Nie znalazłem dla tego innego zwięzłego określenia, niż właśnie wrapper, choć nie jest onocałkiem precyzyjne w tym wypadku.
Sytuacja jest taka, że producenci układów dostarczają binarne sterowniki dla nowych chipsetów i dobrze strzegą swoich tajemnic. Dokumentacja jest dostępna dla słabszych układów, czyli do Radeona 9200 i niższych modeli, i to pod NDA.
Sterownik SNAP byłby (jest) ze swej natury binarny. Jeżeli komuś jest dostarczana dokumentacja, na takiej czy innej licencji, to chyba dlatego, że zależy producentom na innych rynkach niż jedynie słuszny OS. Chyba, że sugerujesz sytuację, w której na opłatach licencyjnych mają większe zyski, niż na sprzedaży kart użytkownikom mniej popularnych systemów - wtedy los SNAPa byłby marny...
07.09.2004 01:43
[#73]
Re: Technologia SNAP i Amiga
@Sventevith, post #70
W odpowiedzi na komentarz #70
"Masz tu link (...) i poczytaj sobie" było Twoją najbardziej konstruktywną, konkretną wypowiedzią w tej dyskusji. Gdyby nie to miałbym wrażenie, że rozmawiam z czymś w rodzaju boota z IRC (wiem, muszę sobie poczytać o IRC i bootach a dopiero potem się wypowiadać:). Nie chciałem tego mówić wcześniej, ale nastała pora: nie mam wrażenia ale jestem pewien, że Twoje komentarze służą głównie zaspokojeniu potrzeby zaistnienia i wywołaniu ruchu wokół swojej osoby. Jest to tak samo oczywiste, jak smutny jest fakt, że 12 procent ruchu w internecie jest napędzane przez robaki i konie trojańskie, według badań przeprowadzonych przez firmę Sandvine. I mam taką małą prośbę, chyba że chcesz mieć satysfakcję "posiadania ostatniego słowa", nie odpowiadaj na ten wątek. Nie będę Ci dawać następnej porcji pożywki - z powodów jak wyżej.
"Masz tu link (...) i poczytaj sobie" było Twoją najbardziej konstruktywną, konkretną wypowiedzią w tej dyskusji. Gdyby nie to miałbym wrażenie, że rozmawiam z czymś w rodzaju boota z IRC (wiem, muszę sobie poczytać o IRC i bootach a dopiero potem się wypowiadać:). Nie chciałem tego mówić wcześniej, ale nastała pora: nie mam wrażenia ale jestem pewien, że Twoje komentarze służą głównie zaspokojeniu potrzeby zaistnienia i wywołaniu ruchu wokół swojej osoby. Jest to tak samo oczywiste, jak smutny jest fakt, że 12 procent ruchu w internecie jest napędzane przez robaki i konie trojańskie, według badań przeprowadzonych przez firmę Sandvine. I mam taką małą prośbę, chyba że chcesz mieć satysfakcję "posiadania ostatniego słowa", nie odpowiadaj na ten wątek. Nie będę Ci dawać następnej porcji pożywki - z powodów jak wyżej.
07.09.2004 14:35
[#74]
Re: Technologia SNAP i Amiga
@Konrad Klar, post #72
W odpowiedzi na komentarz #72
P.S. ...choć wolałbym aby to "partycja musi być w systemie plików obsługiwanym przez firmware" przybrało postać "kod filesystemu musi znajdować się w RDB, MBR lub innym systemie partycjonowania dysku obsługiwanym przez firmware" w ostatecznym rozwiązaniu.
Byloby to dobre, gdyby sie odciac calkiem od klasycznych amig i dyskow z nich. Bo jak chcialbys rozwiazac wtedy wspolprace z dyskami podpietymi od classica? Na nich filesystem jest w wersji m68k, wiec nie ruszy. A emulator m68k w firmware bylby raczej glupim pomyslem ;).
P.S. ...choć wolałbym aby to "partycja musi być w systemie plików obsługiwanym przez firmware" przybrało postać "kod filesystemu musi znajdować się w RDB, MBR lub innym systemie partycjonowania dysku obsługiwanym przez firmware" w ostatecznym rozwiązaniu.
Byloby to dobre, gdyby sie odciac calkiem od klasycznych amig i dyskow z nich. Bo jak chcialbys rozwiazac wtedy wspolprace z dyskami podpietymi od classica? Na nich filesystem jest w wersji m68k, wiec nie ruszy. A emulator m68k w firmware bylby raczej glupim pomyslem ;).
08.09.2004 05:11
[#75]
Re: Technologia SNAP i Amiga
@marcik, post #74
W odpowiedzi na komentarz #74
Tak, masz właściwie rację, ponieważ ściśle amigowskiego ROMu w A1 czy w Pegasosie nie ma, taki filesystem z RDB nie będzie mieć środowiska do rozruchu (bibliotek dos czy exec). Z czegoś ten bootimage trzeba wczytać i ładnie (a właściwie niezbędnie), że zauważono nieoficjalnego SFS. To chyba wszystko w tym podtemacie?
Tak, masz właściwie rację, ponieważ ściśle amigowskiego ROMu w A1 czy w Pegasosie nie ma, taki filesystem z RDB nie będzie mieć środowiska do rozruchu (bibliotek dos czy exec). Z czegoś ten bootimage trzeba wczytać i ładnie (a właściwie niezbędnie), że zauważono nieoficjalnego SFS. To chyba wszystko w tym podtemacie?