Zwłaszcza, że MGM-31A wycofali w 1989 roku, a MGM-31B - 2 lata później. 08.11.2017 16:12
[#902]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI) - Uszczypliwość użytkownika A1200
08.11.2017 20:05
[#909]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI) - Uszczypliwość użytkownika A1200
08.11.2017 20:35
[#910]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI) - Uszczypliwość użytkownika A1200
08.11.2017 21:46
[#912]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI) - Uszczypliwość użytkownika A1200
08.11.2017 22:10
[#913]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@michal_zukowski, post #911
Przecież 040/060 też nie są kompatybilne w dół.
Trzeba zawsze jakieś sztuczki stosować aby coś działało.
W piecu kiedy podmieniłem pentium 166 mmx na p2 lub p3 a nawet P4 to wszystko ruszało z kopyta.
Bez odgrywania jakiś tam libsów dla obsługi proca.
Tak samo Vampire działa. A newet jest lepiej bo po prostu działa od strzału. ...
Trzeba zawsze jakieś sztuczki stosować aby coś działało.
W piecu kiedy podmieniłem pentium 166 mmx na p2 lub p3 a nawet P4 to wszystko ruszało z kopyta.
Bez odgrywania jakiś tam libsów dla obsługi proca.
Tak samo Vampire działa. A newet jest lepiej bo po prostu działa od strzału. ...
09.11.2017 00:28
[#915]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI) - Uszczypliwość użytkownika A1200
@] SKOLMAN_MWS ˇ agrEssOr [, post #912
Xenia nie odpala z obrazami gentoo, które znalazłem poprzez free60, a że nie ma menu (bo i pełnej emulacji firmware pewnie też nie) to i nie ma jak inaczej czegokolwiek innego ściągnąć (bo skrypty instalacyjne trzeba odpalać z konsoli wywoływanej w menu ...).
09.11.2017 04:04
[#916]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@waldiamiga, post #900
W koncu rozne ciekawostki mozna sobie teraz poczytac na forach w zwiazku z ta propozycja Gunnara.
1. Wersja 68080 with light FPU potrzebuje FPGA z 40k LE, w wersji 68080 with full FPU potrzebuje FPGA z 50k LE.
2. Full FPU, oznacza wersje z miksowananymi instrukcjami z 68040FPU i 68060FPU (w obu wersjach FPU brakuje roznych instrukcji). Tylko, ze to nie jest prawdziwe full 68882 FPU, bo brakuje chociazby instrukcji trygonometrycznych, ktore dalej bede emulowane przez SoftFPU lub 68080.library. Wiec to jest uzywanie niewlasciwych okreslen, ewentualnie naginanie rzeczywistosci, bo to nie jest full FPU.
3. Troche o kompatybilnosci z 68060 jesli chodzi o instrukcje CPU. Ja jestem z obecnego stanu zadowolony (choc podobno brakuje TAS2, ale nie jestem tego pewien), bo instrukcje typu mnozenie 64 bitowe czy movep, nie sa zewnetrznie emulowane. Czyli 68080 nie jest tutaj kompatybilny z 68060, i wedlug mnie dobrze. Problem jest w tym, ze niektorzy nie rozumieja albo maja inne pojecie "kompatybilnosci" jesli chodzi o procesory. Dla mnie w pelni kompatybilne CPU, oznacza takie CPU, ktore wykonuje wszystkie instrukcje procesorow z danej serii bez potrzeby zewnetrznej (SoftFPU czy 680x0.library) emulacji.
4. Nawet jesli chodzi o normalne instrukcje tez sa roznice w ich wykonywaniu, co widac w benchmarku z FX Painta 2.02. Chodzi o ich szybkosc dzialania. Gunnar czesto pisze o "bablach" (bubbles), w kodzie. I czesciowo ma racje.Ale skoro inzynierowie Motoroli potrafili jakos sobie poradzic w niektorych przypadkach tych babli, to i on powinien sobie z tym poradzic. Bo roznica rzedu 2 razy wolniejsze dzialanie instrukcji niz w 68060, dla tego samego kodu, oznacza, ze cos w core Apollo jest zle zrobione. Dla purystow na pewno oznacza tez, ze 68080 nie jest kompatybilny szybkosciowo z 68060, bo dziala wolniej, a powinien dzialac tak samo lub szybciej. To moze tez tlumaczyc dlaczego przy niektorych programach nie ma widocznej roznicy szybkosci na korzysc 68080, skoro 4 instrukcje moze nawet w 1 cyklu Apollo wykonac. Po prostu w jednym miejscu Apollo zyskuje a w drugim traci. Powinni porobic testy szybkosci bardzo krotkich procedur z bablami i bez na 68060 i 68080 i zobaczyc gdzie jest problem. Gdzie 68060 jest szybsze niz 68080.
5. No i zdaje sie, ze kombinuja jak rozwiazac problem z kompatybilnym wstecz MMU, co sie im chwali.
1. Wersja 68080 with light FPU potrzebuje FPGA z 40k LE, w wersji 68080 with full FPU potrzebuje FPGA z 50k LE.
2. Full FPU, oznacza wersje z miksowananymi instrukcjami z 68040FPU i 68060FPU (w obu wersjach FPU brakuje roznych instrukcji). Tylko, ze to nie jest prawdziwe full 68882 FPU, bo brakuje chociazby instrukcji trygonometrycznych, ktore dalej bede emulowane przez SoftFPU lub 68080.library. Wiec to jest uzywanie niewlasciwych okreslen, ewentualnie naginanie rzeczywistosci, bo to nie jest full FPU.
3. Troche o kompatybilnosci z 68060 jesli chodzi o instrukcje CPU. Ja jestem z obecnego stanu zadowolony (choc podobno brakuje TAS2, ale nie jestem tego pewien), bo instrukcje typu mnozenie 64 bitowe czy movep, nie sa zewnetrznie emulowane. Czyli 68080 nie jest tutaj kompatybilny z 68060, i wedlug mnie dobrze. Problem jest w tym, ze niektorzy nie rozumieja albo maja inne pojecie "kompatybilnosci" jesli chodzi o procesory. Dla mnie w pelni kompatybilne CPU, oznacza takie CPU, ktore wykonuje wszystkie instrukcje procesorow z danej serii bez potrzeby zewnetrznej (SoftFPU czy 680x0.library) emulacji.
4. Nawet jesli chodzi o normalne instrukcje tez sa roznice w ich wykonywaniu, co widac w benchmarku z FX Painta 2.02. Chodzi o ich szybkosc dzialania. Gunnar czesto pisze o "bablach" (bubbles), w kodzie. I czesciowo ma racje.Ale skoro inzynierowie Motoroli potrafili jakos sobie poradzic w niektorych przypadkach tych babli, to i on powinien sobie z tym poradzic. Bo roznica rzedu 2 razy wolniejsze dzialanie instrukcji niz w 68060, dla tego samego kodu, oznacza, ze cos w core Apollo jest zle zrobione. Dla purystow na pewno oznacza tez, ze 68080 nie jest kompatybilny szybkosciowo z 68060, bo dziala wolniej, a powinien dzialac tak samo lub szybciej. To moze tez tlumaczyc dlaczego przy niektorych programach nie ma widocznej roznicy szybkosci na korzysc 68080, skoro 4 instrukcje moze nawet w 1 cyklu Apollo wykonac. Po prostu w jednym miejscu Apollo zyskuje a w drugim traci. Powinni porobic testy szybkosci bardzo krotkich procedur z bablami i bez na 68060 i 68080 i zobaczyc gdzie jest problem. Gdzie 68060 jest szybsze niz 68080.
5. No i zdaje sie, ze kombinuja jak rozwiazac problem z kompatybilnym wstecz MMU, co sie im chwali.
09.11.2017 09:42
[#917]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #916
@1 - a jakie ma to przełożenie na slices Xilinxa?
@2 - bez znaczenia, FPU w Wampie jest tak samo kompatybilne z 68882 jak 040 i 060 - tj. część instrukcji nie będzie w krzemie tylko przez procedury programowe wykonywana. Jak mawiają nihil novi - już 040 robiło podobnie, a wzrost wydajności wszystko wynagradzał.
@3 - z tego co pamiętam FPU nawet w 040 i 060 to (jak x87 w procesorach x86) urządzenie peryferyjne. Procesor jeśli FPU jest w systemie to przekazuje instrukcje F do niego, a jak nie ma to reaguje tak jak sobie zaprojektujemy, albo crash, albo zamknięcie aplikacji, albo komunikat o błędzie, albo wykorzystanie biblioteki f. matematycznych na ALU. Zatem sam rdzeń 68k nie wykonuje i nigdy nie wykonywał operacji zmiennoprzecinkowych.
@4 - tak to niestety bywa, przeładowanie ficzerami oznacza, że synteza fpga musi zabrać więcej bloków logicznych, a skutkiem ubocznym może być to, że w określonych sytuacjach coś może działać gorzej. Dlatego od początku byłem raczej zwolennikiem podejścia małego, szybkiego i kompatybilnego softcore.
@2 - bez znaczenia, FPU w Wampie jest tak samo kompatybilne z 68882 jak 040 i 060 - tj. część instrukcji nie będzie w krzemie tylko przez procedury programowe wykonywana. Jak mawiają nihil novi - już 040 robiło podobnie, a wzrost wydajności wszystko wynagradzał.
@3 - z tego co pamiętam FPU nawet w 040 i 060 to (jak x87 w procesorach x86) urządzenie peryferyjne. Procesor jeśli FPU jest w systemie to przekazuje instrukcje F do niego, a jak nie ma to reaguje tak jak sobie zaprojektujemy, albo crash, albo zamknięcie aplikacji, albo komunikat o błędzie, albo wykorzystanie biblioteki f. matematycznych na ALU. Zatem sam rdzeń 68k nie wykonuje i nigdy nie wykonywał operacji zmiennoprzecinkowych.
@4 - tak to niestety bywa, przeładowanie ficzerami oznacza, że synteza fpga musi zabrać więcej bloków logicznych, a skutkiem ubocznym może być to, że w określonych sytuacjach coś może działać gorzej. Dlatego od początku byłem raczej zwolennikiem podejścia małego, szybkiego i kompatybilnego softcore.
09.11.2017 17:41
[#918]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@abcdef, post #917
1. Nie wiem, nie znam sie na FPGA, musisz poszukac jakie sa zaleznosci miedzy slices a LE.
2. Jak bez znaczenia? Chyba nigdy nie programowales/kodowales. To ze 68040 i 68060 nie maja pelnego 68882 FPU to z powodu kosztow, czyli glownie braku miejsca. A teraz brak miejsca to nie ma takiego znaczenia, porownujac to do gier, nikt teraz nie pisze gier na PCta dzialajacych na 640KB RAM lub 1MB RAM, tylko ilosci ida w gigabajty pamieci, 4GB RAM to jest raczej minimum. A to jest porownywalny czas, paredziesiat lat roznicy. Jak sie cos robi to sie powinno to robic dobrze. Tym bardziej, ze juz teraz to core ma miec 50k LE, czyli bardzo sie rozroslo, jak sie porowna z wersja 8k LE w Vampire 1. Zreszta meynaf pisal, ze tworzenie dobrego procesora pod ilosc wolnego LE jest bez sensu, bo zawsze beda nowsze i wieksze FPGA. Swoja droga to 50k LE raczej zajmuja bardzo skomplikowane projekty.
3. CPU moze dekodowac instrukcje FPU, a nie tylko instrukcje CPU, wtedy mniej LE jest potrzebnych. Do tego pewnie moze tez je wykonywac, zalezy jak jest skonstruowane wewnetrznie. To ze kiedys bylo wywolywane przerwanie linii F, zostalo zmienione juz w 68040, dla czesci instrukcji FPU 68882.
2. Jak bez znaczenia? Chyba nigdy nie programowales/kodowales. To ze 68040 i 68060 nie maja pelnego 68882 FPU to z powodu kosztow, czyli glownie braku miejsca. A teraz brak miejsca to nie ma takiego znaczenia, porownujac to do gier, nikt teraz nie pisze gier na PCta dzialajacych na 640KB RAM lub 1MB RAM, tylko ilosci ida w gigabajty pamieci, 4GB RAM to jest raczej minimum. A to jest porownywalny czas, paredziesiat lat roznicy. Jak sie cos robi to sie powinno to robic dobrze. Tym bardziej, ze juz teraz to core ma miec 50k LE, czyli bardzo sie rozroslo, jak sie porowna z wersja 8k LE w Vampire 1. Zreszta meynaf pisal, ze tworzenie dobrego procesora pod ilosc wolnego LE jest bez sensu, bo zawsze beda nowsze i wieksze FPGA. Swoja droga to 50k LE raczej zajmuja bardzo skomplikowane projekty.
3. CPU moze dekodowac instrukcje FPU, a nie tylko instrukcje CPU, wtedy mniej LE jest potrzebnych. Do tego pewnie moze tez je wykonywac, zalezy jak jest skonstruowane wewnetrznie. To ze kiedys bylo wywolywane przerwanie linii F, zostalo zmienione juz w 68040, dla czesci instrukcji FPU 68882.
09.11.2017 18:32
[#919]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #918
Nie, nie koduję aplikacji amigowych, ale znam się na technice mikroprocesorowej. W momencie kiedy zaczęto używać intensywnie potoku to nie wszystkie rozkazy się ładnie w to wkomponowały. Głębokość potoku też ma znaczenie ... dłuższy pozwala taktować szybciej, ale z drugiej strony zmniejsza IPC. To pułapka w którą wpadł Intel z Netburst oraz AMD z Bulldozer. Ich implementacje x87 też nie przetwarzają każdego rozkazu jednakowo "szybciej" w porównaniu do poprzednich generacji. Niektóre rozkazy są wykonywane niejako z wewnętrzną podprocedurą i zajmują więcej cykli właśnie dlatego, że nie da się ich wykonać tak szybko jak innych. Pewnym rozwiązaniem okazało się SSE i teraz AVX, bo mamy nowe rozkazy, lepsze rozkazy, z bardzo przewidywalną przepustowością jednostek.
Zbudowanie "tłustego" rdzenia niesie za sobą większe skomplikowanie, większe zużycie energii przy tych samych zadaniach i większe ograniczenie taktowania. Jeśli wycięte rozkazy i tak są rzadziej używane lub jeśli mimo programowego wykonywania i tak są szybsze niż stary kawał krzemu to decyzja była i tak słuszna. Pisanie, że wycięte instrukcje to efekt cięć budżetowych jest najprawdopodobniej fałszywe, szczególnie gdy sobie uświadomimy ile powierzchni kosztuje cache, a ile FPU (i tak, w krzemie to powierzchnia się liczy najbardziej, reszta to już kwestia dobrania procesu).
Zbudowanie "tłustego" rdzenia niesie za sobą większe skomplikowanie, większe zużycie energii przy tych samych zadaniach i większe ograniczenie taktowania. Jeśli wycięte rozkazy i tak są rzadziej używane lub jeśli mimo programowego wykonywania i tak są szybsze niż stary kawał krzemu to decyzja była i tak słuszna. Pisanie, że wycięte instrukcje to efekt cięć budżetowych jest najprawdopodobniej fałszywe, szczególnie gdy sobie uświadomimy ile powierzchni kosztuje cache, a ile FPU (i tak, w krzemie to powierzchnia się liczy najbardziej, reszta to już kwestia dobrania procesu).
10.11.2017 02:27
[#920]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@abcdef, post #919
Wyciete rozkazy FPU i CPU z 68060 to kwestia ekonomiczna raczej na pewno. Wyciecie instrukcji 64 bitowych z 68060 nie mialo raczej zadnego innego sensu. Z tego co wiem zarowno mnozenie/dzielenie 64 bitowe jak i funkcje trygonometryczne sa bardzo zasobozerne i oprocz LE potrzebuja tez jeszcze miejsca na tabele, ktorych jest brak. Pisalem o tym kiedys na EAB, ze jak sie dobrze zaprojektuje to wystarczy jedna tabela dla sin/cos, jedna tabela dla tng/ctng itd. Wiec mozna by bylo zuzycie miejsca w FPGA zoptymalizowac.
10.11.2017 08:47
[#921]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #920
Zasobożerne? Może nie aż tak, bo jak pisałem cache potrafi więcej powierzchni zająć, a w nowoczesnych procesorach wystarczy spojrzeć by widzieć że to ponad połowa całej powierzchni kości. Ale owszem, pełna 80bitowa (tak, 68881 i 8087 to 80bitowe fpu) architektura swoje kosztuje. Teraz... czy pamiętasz kiedy ostatni raz użyłeś 80bitowych rejestrów 68881? Nie? A jak często korzystasz z double, atan? Tak... w tym momencie właśnie wychodzą optymalizacje konstrukcji. Czy działania były niepotrzebne? Czy były bezcelowe?
zestawienie z eab.abime.net
68882 fmul 76 cycles
68882 fdiv 108 cycles
68060 fmul 3 cycles
68060 fdiv 37 cycles
Teraz warto by dopisać, że jak najbardziej korzystając z 32bit FPU można użyć double. Kosztuje to więcej instrukcji czyli więcej cykli. Ale nie aż tak dużo więcej. Np. 64bitowe FPU Athlona64 (K8) typy 128bit (SSE) robiło w 2 cyklach. Tak samo 128bitowe FPU Ryzena przelicza 256bitowe AVX2 w 2 cyklach. Ale AMD widocznie jest głupie i w głupi sposób oszczędza, bo nie chce grzać chipów i obniżać zegara bazowego przetwarzając słabo rozpropagowane AVX2 na "pełnych" 256bit jednostkach, które nie mogą być użyte do niczego innego (ergo cały "naddatek" tranzystorów jest wykorzystywany w jednym scenariuszu... przetwarzaniu AVX2). Sam intel w Skylake-S ma aż 512bit SIMD (AVX512 właśnie) i w niższych modelach RÓWNIEŻ są przetwarzane w 2 cyklach. W wyższych modelach jest pełne 512bit przetwarzanie. Przy zwiększonej emisji ciepła i znacznie zmniejszonym zegarze (bo inaczej by się usmażyły).
Zatem proszę nie wychodź z założenia, że takie cięcia to tylko kwestie ekonomiczne. To jak najbardziej kwestie techniczne i funkcjonalne. Jeśli coś kosztuje dużo, a daje mało to tego się nie robi.
zestawienie z eab.abime.net
68882 fmul 76 cycles
68882 fdiv 108 cycles
68060 fmul 3 cycles
68060 fdiv 37 cycles
Teraz warto by dopisać, że jak najbardziej korzystając z 32bit FPU można użyć double. Kosztuje to więcej instrukcji czyli więcej cykli. Ale nie aż tak dużo więcej. Np. 64bitowe FPU Athlona64 (K8) typy 128bit (SSE) robiło w 2 cyklach. Tak samo 128bitowe FPU Ryzena przelicza 256bitowe AVX2 w 2 cyklach. Ale AMD widocznie jest głupie i w głupi sposób oszczędza, bo nie chce grzać chipów i obniżać zegara bazowego przetwarzając słabo rozpropagowane AVX2 na "pełnych" 256bit jednostkach, które nie mogą być użyte do niczego innego (ergo cały "naddatek" tranzystorów jest wykorzystywany w jednym scenariuszu... przetwarzaniu AVX2). Sam intel w Skylake-S ma aż 512bit SIMD (AVX512 właśnie) i w niższych modelach RÓWNIEŻ są przetwarzane w 2 cyklach. W wyższych modelach jest pełne 512bit przetwarzanie. Przy zwiększonej emisji ciepła i znacznie zmniejszonym zegarze (bo inaczej by się usmażyły).
Zatem proszę nie wychodź z założenia, że takie cięcia to tylko kwestie ekonomiczne. To jak najbardziej kwestie techniczne i funkcjonalne. Jeśli coś kosztuje dużo, a daje mało to tego się nie robi.
10.11.2017 09:44
[#922]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@abcdef, post #921
P4:
typ, opóźnienie, ilość cykli
fp add single 4 - 5 1 - 2
fp mul single 6 - 7 2
fp div single 23 - 69 23 - 69
K8:
Pomijam już trygonometrię z LUT, bo to jest osobne zagadnienie. O ile przetwarzanie szerszych SIMD nie jest problemem bo wystarczy z reguły podzielić na kawałki odpowiedniej długości (jak we wcześniejszej wypowiedzi). Double 060 przecież wspiera, a jedynie nie wspiera określonych typów reprezentacji (stąd konieczność przetwarzania na zjadliwy format poprzez bibliotekę)
To wyjaśnia sprawę dość jasno. Żeby nie było intel z amd też już od dekad robią podobnie. Wcale bym się nie zdziwił gdyby za generację czy dwie x87 całkowicie zniknęło z krzemu i zostało przeniesione do biblioteki.
typ, opóźnienie, ilość cykli
fp add single 4 - 5 1 - 2
fp mul single 6 - 7 2
fp div single 23 - 69 23 - 69
K8:
The latency for floating point addition and multiplication is 4 clock cycles. The units are fully pipelined so that a new operation can start every clock cycle. Division takes 11 clock cycles and is not fully pipelined
Pomijam już trygonometrię z LUT, bo to jest osobne zagadnienie. O ile przetwarzanie szerszych SIMD nie jest problemem bo wystarczy z reguły podzielić na kawałki odpowiedniej długości (jak we wcześniejszej wypowiedzi). Double 060 przecież wspiera, a jedynie nie wspiera określonych typów reprezentacji (stąd konieczność przetwarzania na zjadliwy format poprzez bibliotekę)
The MC68060 FPU has been optimized for the most frequently used instructions and data types
To wyjaśnia sprawę dość jasno. Żeby nie było intel z amd też już od dekad robią podobnie. Wcale bym się nie zdziwił gdyby za generację czy dwie x87 całkowicie zniknęło z krzemu i zostało przeniesione do biblioteki.
10.11.2017 10:10
[#923]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@abcdef, post #922
Panie i Panowie naprawdę fajnie się was czyta.
Zrobię offtopa – aż dziw bieżę, że jeszcze Polscy Amigowcy nie wzięli się za ten cały bajzel i sami nie zrobili odpowiednika Vampira.
I całkiem nie złośliwie pytam, po prostu tak czytam często na forum i jestem pełen podziwu dla posiadanej przez ludzi wiedzy.
Mam pytanie brak zaangażowania to - problem w skłóconym środowisku (każdy chce co innego), braku kasy na projekt, czy po prostu brakiem czasu, bo wiadomo każdy ma życie zawodowe i rodzinne.
Jestem ciekaw, bo naprawdę przekonałem się że jest tu wiele mądrych ludzi, ale chętnych do działania znaleźć trudno.
Ps. Przy okazji szukam doświadczonego elektronika który zaglądnie do mojej a1200 – okolice Katowic +100 km , podjadę ;)
Zrobię offtopa – aż dziw bieżę, że jeszcze Polscy Amigowcy nie wzięli się za ten cały bajzel i sami nie zrobili odpowiednika Vampira.
I całkiem nie złośliwie pytam, po prostu tak czytam często na forum i jestem pełen podziwu dla posiadanej przez ludzi wiedzy.
Mam pytanie brak zaangażowania to - problem w skłóconym środowisku (każdy chce co innego), braku kasy na projekt, czy po prostu brakiem czasu, bo wiadomo każdy ma życie zawodowe i rodzinne.
Jestem ciekaw, bo naprawdę przekonałem się że jest tu wiele mądrych ludzi, ale chętnych do działania znaleźć trudno.
Ps. Przy okazji szukam doświadczonego elektronika który zaglądnie do mojej a1200 – okolice Katowic +100 km , podjadę ;)
10.11.2017 10:15
[#924]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Newhousik, post #923
Mam pytanie brak zaangażowania to - problem w skłóconym środowisku (każdy chce co innego), braku kasy na projekt, czy po prostu brakiem czasu, bo wiadomo każdy ma życie zawodowe i rodzinne.Brak czasu. Co do środowiska, to wiadomo, że całego się i tak nie zadowoli, więc wystarczy zadowolić jakąś w miarę istotną grupę. Co do kasy, to przy FPGA wydatki są co najwyżej czterocyfrowe, więc to tak naprawdę żaden problem. Ale właśnie ogrom czasu, jaki zjada taki projekt, jest głównym hamulcem.
Ostatnia aktualizacja: 10.11.2017 10:16:11 przez Krashan
10.11.2017 11:33
[#928]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@pisklak, post #925
Amigowcy to już zawsze będą uprawiać chałupnictwo? 
Przecież Motorola/FreeScale produkuje dalej CPU z serii MC680x0 - nic tylko do nich walić o nowy procesor! 
Poza tym ja zawsze powtarzam - roi się od projektów hardware, a projektów software ni ma. Kto to wszystko oprogramuje? Chyba, że jedynie SysInfo jest Wam potrzebne do życia (no i Doom/Quake).
Na AmigaOS4 jest mało programów. Czy ktoś deklaruje się tutaj jako programista Vampire? (Może oprócz Don Adana i Artura Jarosika).
Przecież Motorola/FreeScale produkuje dalej CPU z serii MC680x0 - nic tylko do nich walić o nowy procesor! Poza tym ja zawsze powtarzam - roi się od projektów hardware, a projektów software ni ma. Kto to wszystko oprogramuje? Chyba, że jedynie SysInfo jest Wam potrzebne do życia (no i Doom/Quake).
Na AmigaOS4 jest mało programów. Czy ktoś deklaruje się tutaj jako programista Vampire? (Może oprócz Don Adana i Artura Jarosika).
10.11.2017 11:54
[#930]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Krashan, post #929
Luzik. Pan ma firmę, więc to Pana nie dotyczy. Ale elektronicy z Apollo-Team nie zarejestrowali swojej działalności.
Moja wypowiedź nie dotyczyła elektroniki (na której się nie znam), ale ogólnej metody działania amigowców takich jak z Apollo-Team itp. Ja, jako konsument mam wybór. I mogę wybrać między profesjonalistami (firmą), a amatorami. Mam do tego prawo.
Amigowcy już sobie jednak założyli, że będą buntownikami (Intel Outside i te rzeczy).
Ostatnia aktualizacja: 10.11.2017 11:56:24 przez Hexmage960
Moja wypowiedź nie dotyczyła elektroniki (na której się nie znam), ale ogólnej metody działania amigowców takich jak z Apollo-Team itp. Ja, jako konsument mam wybór. I mogę wybrać między profesjonalistami (firmą), a amatorami. Mam do tego prawo.
Amigowcy już sobie jednak założyli, że będą buntownikami (Intel Outside i te rzeczy).
Ostatnia aktualizacja: 10.11.2017 11:56:24 przez Hexmage960