05.08.2017 22:35
[#121]
Re: Vampire V4
@teh_KaiN, post #120
Skoro GLES jest dostępny "na tacy" to nie widzę sensu aby szukać innej drogi. Wszystko pewnie da radę zrobić lepiej, ale trzeba liczyć siły na zamiary. A tutaj mamy prawie zerowy koszt. A skoro jest to standard, to tylko kolejny plus.
PS.
A co do eksperymentowania z 3D w latach 90-tych to ja bym nawet nie oczekiwał rysowania całych trójkątów. Niechby tylko był tryb chunki + metoda scanline była wspomagana sprzętowo (czyli rysowanie poziomego odcinka z podanymi dla obu końców kolorami (dla gouarda) i/lub koordynatami tekstury). Bo to zajmuje najwięcej czasu. I jestem ciekaw jak by potoczyła się historia Amigi.
PS.
A co do eksperymentowania z 3D w latach 90-tych to ja bym nawet nie oczekiwał rysowania całych trójkątów. Niechby tylko był tryb chunki + metoda scanline była wspomagana sprzętowo (czyli rysowanie poziomego odcinka z podanymi dla obu końców kolorami (dla gouarda) i/lub koordynatami tekstury). Bo to zajmuje najwięcej czasu. I jestem ciekaw jak by potoczyła się historia Amigi.
06.08.2017 12:17
[#122]
Re: Vampire V4
@sando, post #121
Bardzo fajnie że Vampirek robi kolejny krok na przód.
Ficzery które mają się pojawić na V4 robią wrażenie i najważniejsze że powstanie tak długo wyczekiwany Vampir do A1200 a wersja standalone to prawdziwa niespodzianka.
Co prawda spodziewałem się że kiedyś w końcu powstanie taka wersja,jednak nie oczekiwałem że tak szybko. Juz wiem że zamiast inwestować w kartę 060,na która mam ochotę od dawna lepiej będzie zainwestować w krwiopijce. Cena i tak będzie raczej mniejsza od obecnych cen turbinek 060 (o PPC nie wspominając) więc względem ceny do możliwości prezentuje się to bardzo atrakcyjnie.
FPGA wciąż się rozwija i układy tanieją więc za kilka lat można się spodziewać kart wydajności 060 o zegarze 1GHz,co prawda to tylko gdybanie ale im większe możliwości sprzętowe tym więcej softu się pojawi na Amigę,zwłaszcza portów.
Być może w kolejnych wersjach pojawią się dodatkowe atrakcje( któs wspominał o dekoderach sprzętowych x264 czy x265, akcelerator 3d, zmiana IDE-> SATA ),a wtedy już bardzo blisko do komfortowego używania Amigi dzisiaj nie tylko do starych gier i programów,ale i jako alternatywę dla peceta.
Dlatego uważam że jest to dobra droga by wprowadzić Amigę w XXI wiek.
Co prawda wątpie, że nastąpi jakiś większy bum na amigę dzięki Vampirom,jednak powinno to zachęcić "kilka" osób na zainteresowanie się platformą 68k
Ficzery które mają się pojawić na V4 robią wrażenie i najważniejsze że powstanie tak długo wyczekiwany Vampir do A1200 a wersja standalone to prawdziwa niespodzianka.
Co prawda spodziewałem się że kiedyś w końcu powstanie taka wersja,jednak nie oczekiwałem że tak szybko. Juz wiem że zamiast inwestować w kartę 060,na która mam ochotę od dawna lepiej będzie zainwestować w krwiopijce. Cena i tak będzie raczej mniejsza od obecnych cen turbinek 060 (o PPC nie wspominając) więc względem ceny do możliwości prezentuje się to bardzo atrakcyjnie.
FPGA wciąż się rozwija i układy tanieją więc za kilka lat można się spodziewać kart wydajności 060 o zegarze 1GHz,co prawda to tylko gdybanie ale im większe możliwości sprzętowe tym więcej softu się pojawi na Amigę,zwłaszcza portów.
Być może w kolejnych wersjach pojawią się dodatkowe atrakcje( któs wspominał o dekoderach sprzętowych x264 czy x265, akcelerator 3d, zmiana IDE-> SATA ),a wtedy już bardzo blisko do komfortowego używania Amigi dzisiaj nie tylko do starych gier i programów,ale i jako alternatywę dla peceta.
Dlatego uważam że jest to dobra droga by wprowadzić Amigę w XXI wiek.
Co prawda wątpie, że nastąpi jakiś większy bum na amigę dzięki Vampirom,jednak powinno to zachęcić "kilka" osób na zainteresowanie się platformą 68k
06.08.2017 13:48
[#123]
Re: Vampire V4
@sando, post #121
Jasne, zaimplementowanie funkcjonalności to jedno, ale jeszcze trzeba tą funkcjonalność udostępnić do aplikacji.. w przypadku rozwiązań systemowych SAGA to tylko rozwinięcie AGA więc jest obsługiwane niejako out of the box, co innego 3D, które będzie wymagało napisania swojego drivera udostępniającego funkcje w ramach standardu (Warp3D na przykład choć lepszy byłby OpenGL; GLES to chyba bardziej do portowania z androida). Druga sprawa - jak się to będzie sprawowało. Riva 128 będąca niejako konkurentem dla VooDoo1 w 3D była zbudowana z 3,5mln tranzystorów. 68060 z ok 2,5mln. Dla tych co kojarzą temat to powinno wyjaśniać wystarczająco wiele, dla tych co nie kojarzą... koszt roboczogodzin w stosunku do tego co otrzymamy sprawia, że już lepiej zrealizować pci i zostawić robotę z 3D dla "big boys". Ewentualnie w przypadku 1200, 3000 i 4000 zostawić 3D dla GFX w mediatorach, g-rexach i prometeusach.
06.08.2017 17:23
[#126]
Re: Vampire V4
@abcdef, post #123
Jeśli jest otwarta implementacja GLES dla fpga to pewnie i są do niej otwarte sterowniki. Więc chyba nie trzeba ich będzie tworzyć od zera.
Alternatywa w postaci PCI też jest bardzo dobra. Plusem byłoby to, że wydajność normalnej karty mogłaby być znacznie większa niż tej w fpga. I w fpga zostałoby więcej miejsca na inne sprawy. Ale dla kart PCI trzeba by też napisać sterowniki, więc ten problem nie odpada.
Plusem 3D w fpga jest jeszcze to, że za kilka lat można by ten wsad cały czas stosować. A w przypadku PCI dzisiejsze karty mogą być dostępne tylko z 2 ręki, więc albo trzeba by polować na nie, albo znów pisać sterowniki do nowych kart. A jak to wygląda w naszym światku każdy wie.
Więc wydaje mi się, że 3d w fpga byłoby mniej problematyczne. Ale 3d z kary przez PCI bardziej wydajne. W sumie to obie opcje mi pasują.
Alternatywa w postaci PCI też jest bardzo dobra. Plusem byłoby to, że wydajność normalnej karty mogłaby być znacznie większa niż tej w fpga. I w fpga zostałoby więcej miejsca na inne sprawy. Ale dla kart PCI trzeba by też napisać sterowniki, więc ten problem nie odpada.
Plusem 3D w fpga jest jeszcze to, że za kilka lat można by ten wsad cały czas stosować. A w przypadku PCI dzisiejsze karty mogą być dostępne tylko z 2 ręki, więc albo trzeba by polować na nie, albo znów pisać sterowniki do nowych kart. A jak to wygląda w naszym światku każdy wie.
Więc wydaje mi się, że 3d w fpga byłoby mniej problematyczne. Ale 3d z kary przez PCI bardziej wydajne. W sumie to obie opcje mi pasują.
06.08.2017 18:16
[#127]
Re: Vampire V4
@sando, post #126
to pewnie i są do niej otwarte sterowniki
A nie sądzi kolega, że gdyby to było takie proste to mielibyśmy od wielu lat bogate galliumowe sterowniki do Radeonów? Nawet dla 3.9? To raz.
Dwa - OpenGL ES to nie OpenGL tylko jego subset, oznacza to mniej więcej tyle, że portowanie tytułów OGL nie będzie wcale takie proste.
Ale dla kart PCI trzeba by też napisać sterowniki
Tak, ale tutaj jest jakiś w miarę ogarnięty standard w postaci openpci zatem jeśli V4 miałby PCI i sterownik do OpenPCI.library to wszystko co z tego sterownika korzystało na np. prometheus powinno działać i na V4 PCI. Prawda? W końcu od tego są standardy że koła na nowo nie wymyślać.
Plusem 3D w fpga jest jeszcze to, że za kilka lat można by ten wsad cały czas stosować
Jasne, że tak, tylko cały czas mówimy o stosunkowo wolnym 3D, a jednym z typowych programów prezentujących przewagę Vampire jest ... odtwarzanie wideo :) Może warto tutaj popracować i wspierać dekodowanie strumieni wideo x.264, h.265, vp8, vp9. Akurat te dwa ostatnie w ramach Youtube i standardu WebM są używane, jest dostępny kod w verilogu, nie pamiętam jaka dokładnie licencja... I owszem, nawet gdyby taką funkcjonalność zaimplementować i tak trzeba się do niej z systemu dostać ;) datatypes i biblioteki trzeba zrobić. Choć to powinno być prostsze niż 3D.
06.08.2017 18:23
[#128]
Re: Vampire V4
@sando, post #126
Minusem zaś to, że to pożre gigantyczną ilość LE w FPGA. Bo to przecież zasuwa na liczbach zmiennoprzecinkowych i to nie na obliczeniach skalarnych, tylko wektorowych lub macierzowych. Plusem będzie skalowalność - mniejsze FPGA dla pojedynczych jednostek shaderów, większe - będzie ich więcej. Tak czy inaczej, trzymałbym to w oddzielnym scalaku.
Przez chwilę myślałem że chlapnąłem na wyrost z tym GLESowym GPU bo coś tam kiedyś czytałem o open source'owym gpu ale jednak znalazłem:
Nyami - projekt badawczy uniwersytetu któregoś, źródeł trzeba poszukać
OpenShader - wspomniany przez publikację Nyami jako drugi projekt otwartego shaderowego GPU.
Jeśli jednak chcielibyśmy coś nie GLESowego a coś bardziej ze stałym pipelinem to:
GPLGPU - w dokumentacji sporo przewija się słowa OpenGL więc stawiam że obsługuje 1.x, bez shaderów raczej
Miaow - tutaj trza by się wczytać co to konkretnego oferuje.
Temat cały czas się rozwija, więc pewnie jak Vampire team pomyśli o akceleracji to na pewno coś już do tego czasu się wykrystalizuje w temacie. Pytanie, czy otworzą się na otwarte rozwiązania.
ED: GLESa bym nie bagatelizował, bo w sumie implementuje to co ważne w OpenGLu (nie mówię o najnowszych usprawnieniach) i wręcz posprzątał API jakie powstawało do tej pory, czyniąc słuszny ruch zrywając kompatybilność z fixed pipeline'em. Teraz jest zauważalna tendencja żeby nawet na desktopach pisać rzeczy w subsecie ES, o ile aplikacja nie wymaga czegoś silniejszego.
Ostatnia aktualizacja: 06.08.2017 18:27:25 przez teh_KaiN
Przez chwilę myślałem że chlapnąłem na wyrost z tym GLESowym GPU bo coś tam kiedyś czytałem o open source'owym gpu ale jednak znalazłem:
Nyami - projekt badawczy uniwersytetu któregoś, źródeł trzeba poszukać
OpenShader - wspomniany przez publikację Nyami jako drugi projekt otwartego shaderowego GPU.
Jeśli jednak chcielibyśmy coś nie GLESowego a coś bardziej ze stałym pipelinem to:
GPLGPU - w dokumentacji sporo przewija się słowa OpenGL więc stawiam że obsługuje 1.x, bez shaderów raczej
Miaow - tutaj trza by się wczytać co to konkretnego oferuje.
Temat cały czas się rozwija, więc pewnie jak Vampire team pomyśli o akceleracji to na pewno coś już do tego czasu się wykrystalizuje w temacie. Pytanie, czy otworzą się na otwarte rozwiązania.
ED: GLESa bym nie bagatelizował, bo w sumie implementuje to co ważne w OpenGLu (nie mówię o najnowszych usprawnieniach) i wręcz posprzątał API jakie powstawało do tej pory, czyniąc słuszny ruch zrywając kompatybilność z fixed pipeline'em. Teraz jest zauważalna tendencja żeby nawet na desktopach pisać rzeczy w subsecie ES, o ile aplikacja nie wymaga czegoś silniejszego.
Ostatnia aktualizacja: 06.08.2017 18:27:25 przez teh_KaiN
06.08.2017 19:08
[#130]
Re: Vampire V4
@teh_KaiN, post #128
GLES aktualnie ma tą przewagę, że jest w smartfonach, tabletach, smart tv, sbc i tak dalej... i to prawda, że aktualnie więcej appsów jeśli z GL korzysta to właśnie dla embedded systems. Problem w tym, że nawet najprostsze appsy z bardzo prostą grafiką korzystają z wersji nie tylko poza zasięgiem Cyclone V, ale nawet kart pokroju Radeon 9xxx.
edit - Vamp z mediatorem ... zobaczymy, wiadomo że akceleratory 3D rozwijały skrzydła dopiero z PPC i ich FPU, tutaj V4 jeśli Apollo dobrze ogarnie 68882 to może równie dobrze działać na 68080. Swoją drogą coraz ciekawsze nazwy kodowe procków, z tego co pamiętam w zamierzchłej przeszłości było 68070 :P
Ostatnia aktualizacja: 06.08.2017 19:10:36 przez abcdef
edit - Vamp z mediatorem ... zobaczymy, wiadomo że akceleratory 3D rozwijały skrzydła dopiero z PPC i ich FPU, tutaj V4 jeśli Apollo dobrze ogarnie 68882 to może równie dobrze działać na 68080. Swoją drogą coraz ciekawsze nazwy kodowe procków, z tego co pamiętam w zamierzchłej przeszłości było 68070 :P
Ostatnia aktualizacja: 06.08.2017 19:10:36 przez abcdef
06.08.2017 19:17
[#131]
Re: Vampire V4
@abcdef, post #127
A czy na dzień dzisiejszy nie dało by to tylko obsługi starszych kart voodoo? Bo chyba tylko do nich są amigowe sterowniki? Jeśli takie rozwiązanie miało by być mało pracochłonne to ok. Ale dla nowszych kart (pci-e) rozumiem, że trzeba by się bardziej narobić (czyli pewnie napisać nowe sterowniki dla dzisiejszych kart i sterowniki do obsługi pci-e)?
07.08.2017 20:12
[#136]
Re: Vampire V4
@maliniak, post #135
Napisałem Im w komentarzu że w 92 C= wprowadziło FPGA w A570. Wchodzę teraz i usunęli, a normalnie jak napisałem pojawił się na stronie.
Bo jak czytam takie newsy, to trochę chce się śmiać... ale załóżmy że tak jest
Rozumie że Ktoś może nie interesować się na tyle Amiga, i nie musi wiedzieć tego że wirtualne chipy serwowało już C=. Po za tym że nie ma żadnego nowego Systemu, no chyba że jakieś nowe .device z Kicka.
Sercem karty Vampire V4 jest wykonany w procesie 28 nm układ FPGA Altera Cyclone V A5, który sprzętowo emuluje nowy amigowy system – wirtualne czipy, które w czasach Commodore były po prostu niemożliwe.
Bo jak czytam takie newsy, to trochę chce się śmiać... ale załóżmy że tak jest
Rozumie że Ktoś może nie interesować się na tyle Amiga, i nie musi wiedzieć tego że wirtualne chipy serwowało już C=. Po za tym że nie ma żadnego nowego Systemu, no chyba że jakieś nowe .device z Kicka.
07.08.2017 21:20
[#139]
Re: Vampire V4
@Vato, post #138
Ale przecież C= stosowało FPGA może jedno z pierwszych ale jednak. Rozumie że co nie którzy mogli wykazywać się nie małym jarankiem
gdy w ich łapki wpadło A570. A gdy teraz się okazało że to implementacja to nagle bee 
Ale pewnie fejm na dzielni pozostał w wspomnieniach gdy to puszczali CD-Audio z Amigi 500
I nie jest to jakaś tajna informacja
Ostatnia aktualizacja: 07.08.2017 21:21:31 przez TechNineWonder
07.08.2017 21:52
[#140]
Re: Vampire V4
@TechNineWonder, post #139
Tak apropos wąpierza vs koszerność to Faza pięć zafejsił dzisiaj rendery kolejnych płytek i oczywiście rozpętał się szitstorm w komentarzach (usuwanych na bieżąco). Zdanie Fazy pięć nt produktów typu Wąpierz:
There does no 68k implementation exist. There exist only unprofessional, incomplete and incompatible 68k software or software core emulation.
07.08.2017 22:04
[#141]
Re: Vampire V4
@tbone, post #140
Ciekawszy jest ten fragment
Może nie robiło to FPGA za CPU bo było by to, może zbyt skomplikowane ale jednak używali.
Ofiarami tej że koszerności są sami twórcy tej że Idei. Tylko krótkowzroczność prowadzi do tego że może jednak tego nie widzą.
Commodore, Amiga and all main third party developers in the last 32 Years never used fpgas that exist since 1985, to emulate 68000 code, for good reasons.
Może nie robiło to FPGA za CPU bo było by to, może zbyt skomplikowane ale jednak używali.
Ofiarami tej że koszerności są sami twórcy tej że Idei. Tylko krótkowzroczność prowadzi do tego że może jednak tego nie widzą.
07.08.2017 22:15
[#142]
Re: Vampire V4
@TechNineWonder, post #139
Nie bardzo rozumiem, ówcześnie i tak dość powszechnie stosowano PAL i GAL. Akurat XC2064 to pierwszy komercyjny FPGA i nawet taka nazwa się wtedy nie pojawiła, bo to taki cross PAL z ASIC był i nikt nie wiedział jako co to sprzedać. GALe były w większości rozszerzeń z ranger mem dla amigi 500, często w przypadku urządzeń na Zorro II i/lub rozszerzeń na złącze krawędziowe A500. To była (i jest) oszczędność miejsca bo zamiast kilku różnych układów logicznych mamy jeden scalak. W przypadku FPGA jest to oszczędność kasy bo można było coś wdrożyć względnie szybko bez zlecania produkcji specyficznego chipu. Pod innym kątem FPGA nie ma żadnych zalet względem fully custom. Może dlatego Akiko powstało jako osobny chip zlepiający funkcje kilku innych, a nie jako FPGA do obsługi cd-rom i chunky to planar.
07.08.2017 22:34
[#143]
Re: Vampire V4
@abcdef, post #142
Nie bardzo rozumiem,
Po to jest właśnie Forum aby rozwiać jakieś domysły. Ale i tak widzę że twierdzisz że nie, że to nie było FPGA.
Pierwszy lepszy cytat z Wiki.
1985: First commercial FPGA : Xilinx XC2064
Nie myślałeś aby napisać do Nich, bo akurat twierdzisz że jest inaczej, albo nie rozumiesz.
Do tego informacje prasowe.
No wiesz ludzie piszą i twierdzą że Ziemia jest, płaska. Może to że XC2064 to nie pierwsze FPGA no kto wie
No ja rozumie, FPGA w C= to obala wszystkie teorie, no ale był i jest.
07.08.2017 22:44
[#144]
Re: Vampire V4
@TechNineWonder, post #143
W przeciwieństwie do kolegi (najwidoczniej) zamiast tekstu napisanego lata po premierze przeczytałem oryginalną informację od Xilinksa dot. pojawienia się tego produktu, nie jest to aż tak trudne do znalezienia. Zatem - nie, w momencie premiery nikt tego FPGA nie nazywał i TYLKO I WYŁĄCZNIE o to mi chodziło, a nie żadne zawracanie kijem rzeki, że to niby nie było FPGA. Zresztą w swoim poście wyraźnie napisałem "pierwsze komercyjne FPGA" dokładnie to samo co kol. zacytował z wikipedii.
Ostatnia aktualizacja: 07.08.2017 22:45:57 przez abcdef
Ostatnia aktualizacja: 07.08.2017 22:45:57 przez abcdef
07.08.2017 22:58
[#145]
Re: Vampire V4
@abcdef, post #144
A można gdzieś o tym przeczytać? Czy nie, możesz zalinkować. Bo ten artykuł pochodzi z Xcell z 1999 roku i jak widzimy nazywano tam już XC2064 jako FPGA.
A jeśli był pierwszym publicznym to musiały być też wcześniej nie publiczne.
Czy mógłbyś napisać do którego roku XC2064 uważano jako nie FPGA, jakiegoś screnna z gazety z tamtych lat. To by było wiarygodne.
Ostatnia aktualizacja: 07.08.2017 22:58:42 przez TechNineWonder
A jeśli był pierwszym publicznym to musiały być też wcześniej nie publiczne.
Czy mógłbyś napisać do którego roku XC2064 uważano jako nie FPGA, jakiegoś screnna z gazety z tamtych lat. To by było wiarygodne.
Ostatnia aktualizacja: 07.08.2017 22:58:42 przez TechNineWonder
i od razu przytaczać źródła. Bo w 92 to C= raczej wiedziało co montuje.08.08.2017 00:24
[#148]
Re: Vampire V4
@TechNineWonder, post #147
Odnośnie wiarygodności
Nigdzie nie twierdziłem zatem w samej swojej wypowiedzi przeinaczasz fakty, a po co? Ano po to żeby później niby żartobliwie, ale w rzeczy samej uszczypliwie (a w zasadzie zupełnie złośliwie) napisać
Doprawdy nie wiem jak kolega sobie wyobraża forum dyskusyjne, ale tego typu dyskusja jest poniżej mojego poziomu. Dobranoc.
Ale i tak widzę że twierdzisz że nie, że to nie było FPGA.
Nigdzie nie twierdziłem zatem w samej swojej wypowiedzi przeinaczasz fakty, a po co? Ano po to żeby później niby żartobliwie, ale w rzeczy samej uszczypliwie (a w zasadzie zupełnie złośliwie) napisać
Nie myślałeś aby napisać do Nich, bo akurat twierdzisz że jest inaczej
Doprawdy nie wiem jak kolega sobie wyobraża forum dyskusyjne, ale tego typu dyskusja jest poniżej mojego poziomu. Dobranoc.
08.08.2017 00:49
[#149]
Re: Vampire V4
@abcdef, post #148
Gdyby to był twój pierwszy post w temacie Vampire. To wtedy co innego.
I w ogóle montowanie tego w A570 jest to przerost formy nad treścią
Do tego jeszcze
Nigdzie nie twierdziłeś ale nawiązałeś do tego że, Xilinx nie wiedział co sprzedaje,
Ale C= wiedziało, i czy ktoś chce czy nie che FPGA było w Historii Amigi już w latach 90.
Do tego stwierdzenie z Wiki było trafne, bo jeśli w Xilinx XC2064 Press Release jest logic cell array. To w wiki powinno też być że układ był opublikowany pod taką nazwą. I data kiedy pojawiała się nazwa FPGA.
Karaluchy pod poduchy
I w ogóle montowanie tego w A570 jest to przerost formy nad treścią
a nie jako FPGA do obsługi cd-rom i chunky to planar.
Do tego jeszcze
Nie bardzo rozumiem
Nigdzie nie twierdziłeś ale nawiązałeś do tego że, Xilinx nie wiedział co sprzedaje,
bo to taki cross PAL z ASIC był i nikt nie wiedział jako co to sprzedać
Ale C= wiedziało, i czy ktoś chce czy nie che FPGA było w Historii Amigi już w latach 90.
Do tego stwierdzenie z Wiki było trafne, bo jeśli w Xilinx XC2064 Press Release jest logic cell array. To w wiki powinno też być że układ był opublikowany pod taką nazwą. I data kiedy pojawiała się nazwa FPGA.
Karaluchy pod poduchy
08.08.2017 08:51
[#150]
Re: Vampire V4
@TechNineWonder, post #149
Gdyby to był twój pierwszy post w temacie Vampire. To wtedy co innego.
Daj cytat z postu, który byłby w tym temacie bez rzeczowych argumentów, opierający się o konfabulacjach dyletanta to przyznam Ci rację.
I w ogóle montowanie tego w A570 jest to przerost formy nad treścią
No to parę faktów:
CDTV - realizacja custom chips
A590 - dedykowany kontroler WD
A570 - urządzenie które weszło gdy A500 wykreślono z produkcji... FPGA do realizacji zadań kontrolera
dalej
A1200, CD32 - custom chips (VLSI*)
Odnośnie tego CD32 to chodziło mi o to, że mając cały kompletny chipset AGA z A1200 można było dodać tylko dodatkową funkcjonalność Akiko (czyli obsługa CD-ROM i konwersję chunky to planar) w FPGA, a używać masowo produkowanych układów... a jednak, zintegrowano budgie, gayle, cia w postaci jednego chipu Akiko dla jednego tylko modelu amigi i wcale nie najbardziej popularnego.
*- VLSI produkowało m.in. semi custom i fully custom chipy, technologia ASIC.
ale nawiązałeś do tego że, Xilinx nie wiedział co sprzedaje,
Nawiązałem i wyraźnie napisałem, że Xilinx nie wiedział JAKO CO to sprzedać, co idealnie widać w notce prasowej do której link udostępniłem (nigdzie nie pada Field Programmable Gate Array choć pada gate array, reszta zaś opisu spokojnie będzie pasowała do CPLD), nigdzie nie pisałem, że Xilinx nie wiedział CO sprzedaje. Czytanie ze zrozumieniem u kolegi to coś widocznie niezbyt dobrze opanowanego (tak, teraz ja sobie pozwoliłem na złośliwość).
Do tego stwierdzenie z Wiki było trafne, bo jeśli w Xilinx XC2064 Press Release jest logic cell array. To w wiki powinno też być że układ był opublikowany pod taką nazwą
Przecież powinien kolega wiedzieć, że wiki jest redagowana przez użytkowników, też poprawiałem błędy gdy natknąłem się na coś rażącego, ale nie mam zamiaru pro publico bono siedzieć i poprawiać wszystko, szczególnie że dyletanci moderujący zmiany czasem odrzucają owe korekty jako "styl nic nie wnoszący" jak to miałem w przypadku mikrokontrolerów Atmela (bo przecież zupełnie fajne są czasomierze i liczniki, a nie układy czasowo-licznikowe *timer/counter*, zupełnie poprawne jest wciskanie kitu że AVR32 są zgodne z AVR).
Dalej... historia Amigi i układów programowalnych
FastATA - AMD Mach CPLD
Mediator - AMD Mach CPLD
BlizzardPPC (iirc) Cypress CPLD
Prometheus - Altera MAX CPLD
CFIDE68k Xilinx CPLD
FastMem A500 - Altera/Atmel/Xilinx CPLD
Slow/ranger mem A500 GAL (PLD)
Nie mam z tym żadnego problemu. Nie jestem fanem kanapkowania, ale już trochę lat mam i nawet na tym portalu trochę spędziłem. I widziałem wypowiedzi (bodajże w czasach "sharka" i "dragona") jak to Amiga staje się zasilaczem i interfejsem klawiatury. I bardzo stanowcze nie dużej części środowiska amigowego. V4 standalone to wyśmienity projekt dla tych co amigi nie mają, którym amiga przestała działać, którzy chcą się dobrze bawić na mocnym amigowym systemie. V4 to właśnie taki SoC, który w sumie wykorzystuje amigę do paru interfejsów (i to częściowo bardziej nostalgicznie niż z potrzeby). I chyba mam pod tym względem prawo być bardziej sceptycznie nastawiony.
BTW użytkownicy Vampire... Intel inside :P
Ostatnia aktualizacja: 08.08.2017 08:53:40 przez abcdef