Komentowana treść: Zbiórka na MMU dla Vampire v4
22.08 21:51
[#1]
Re: Zbiórka na MMU dla Vampire v4
MMU może dać nam na Vampirkach v4 sensownie działające NetBSD. Zbiórka idzie całkiem nieźle. Dodatkowo bliżej będzie Vampirkowi do prawdziwej, pełnej Motorolki 060.Trzymam kciuki za powodzenie i pewno się dorzucam do zbiórki.
23.08 18:40
[#3]
Re: Zbiórka na MMU dla Vampire v4
Ja bym się chętnie dorzucił do projektu stworzenia implementacji takiego 68080 w postaci układu ASIC pinowo i sygnałowo zgodnego z podstawką dla 68040/68060 :)
Ciekawe ile coś takiego by kosztowało? Zlecenie jakiejś kilkudziesięciotysięcznej serii takiego chipa w którejś z fabryk robiących np. ARMy.... milion USD? Więcej, mniej?
Ciekawe ile coś takiego by kosztowało? Zlecenie jakiejś kilkudziesięciotysięcznej serii takiego chipa w którejś z fabryk robiących np. ARMy.... milion USD? Więcej, mniej?
24.08 11:30
[#4]
Re: Zbiórka na MMU dla Vampire v4
@wali7, post #3
Bujanie w obłokach. Sam koszt masek do fotolitografii to miliony dolców.
Przykładowo:
Ostatnia aktualizacja: 24.08.2025 11:45:11 przez Pinto
Ostatnia aktualizacja: 24.08.2025 11:45:31 przez Pinto
Przykładowo:
Przy 70 mm2 na 14 nm i 15 k sztuk głównym kosztem jest NRE masek. Realistyczny koszt produkcyjny wychodzi ~$290/szt. (rozsądne widełki $220–$360/szt. zależnie od masek, pakowania i yieldu).
Ostatnia aktualizacja: 24.08.2025 11:45:11 przez Pinto
Ostatnia aktualizacja: 24.08.2025 11:45:31 przez Pinto
24.08 22:13
[#10]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #8
PowerPC w amigowych kartach od Phase5 też było podpięte do EDO (a chyba nawet FPM, bo żadna karta amigowa nie działała w trybie EDO), i jakoś potrafił przy tych zegarach 200-300 MHz pokazać pazury. W świecie PC EDO RAM używano w czasach PentiumII/K6-2.
Oczywiście, że wiele pomaga tu cache, ale przecież już od 68020 mamy cache, ma go 68060, to co stoi na przeszkodzie dać kilka MB statycznego cache takiemu 68080?
I żeby nie było, że bujam w obłokach, to nie mam najmniejszych oczekiwań, że ktoś kiedyś podejmie się takiego zadania. Traktuję te rozważania czysto teoretycznie.
Chociaż, czy powiedzmy 30 lat temu ktoś mógł przewidzieć, że za równowartość obiadu w restauracji będę mógł kupić niewielki układ scalony, który po zaprogramowaniu specjalnym językiem opisującym topologię i logikę połączeń będzie mógł robić za dowolny mikroprocesor, czy układ graficzny taktowany nawet kilkaset MHz? Albo że w domu będzie sobie można postawić maszynkę, która w kilka godzin wydrukuje mi trójwymiarowy, w pełni funkcjonalny przedmiot z tworzywa sztucznego... albo taką małą frezareczkę do metalu sterowaną komputerowo, do kupienia za kilka dniówek... Kto wie, co nam przyniesie przyszłość? Może będzie sobie można takiego ASICA tanio wysmażyć w domu :) albo w firmie specjalizującej się w takich zabawach (tak jak dzisiejsze prototypowanie PCB w chińskiej płytkarni za relatywnie małe pieniądze).
Z mojej branży - kilkanaście lat temu edycja DNA i synteza genów w laboratorium to była zabawa za setki tysięcy dolarów, 30 lat temu zaś to było praktycznie science-fiction. Kilka miesięcy temu koledzy z naszego projektu wysłali zaprojektowany przez siebie gen ze stosownymi sekwencjami regulacyjnymi (kilka tysięcy par zasad, czyli jak kto woli liter kodu DNA), w postaci pliku, jako załącznik do maila do firmy syntetyzującej geny. Zapłacili kilkaset zł (tak, tylko tyle) i otrzymali próbówkę z zamówionym DNA, które wszczepili do drożdży. Po wielu próbach uruchomili ten gen, drożdże wyprodukowały białko. Dodali substrat, i po oczyszczeniu przysłali to do mnie - oznaczyłem, sprawdziłem, policzyłem (w projekcie robię za analityka który weryfikuje, to co nasi magicy DNA wysmażą) - wynik: działa. Czyli przerabia CBG-A na THC-A (nawiązanie do konopi nieprzypadkowe ;) ) - nasz sztuczny, zaprojektowany w komputerze gen, zadziałał. Chociaż został stworzony całkowicie sztucznie, wyprodukował enzym, który pozwoli (mamy nadzieję) na tanie produkowanie THC-A do celów medycznych, bez obecnych problemów z koniecznością ochrony plantacji konopi. Synteza zamówionego DNA kosztowała kilkaset zł!
Po co to opisuję? Bo to pokazuje, jak niesamowicie szybki jest rozwój naukowo-techniczny, który nie tylko czyni możliwym to, co kilkadziesiąt lat temu było czystym science-fiction, ale czyni to także niezwykle tanim.
Tak więc, mimo, że obecnie traktuję to jako czystą teorię, to man nadzieję, że za niedługi czas po raz kolejny science-fiction stanie się niedrogą codziennością.
Ostatnia aktualizacja: 24.08.2025 22:19:55 przez wali7
Oczywiście, że wiele pomaga tu cache, ale przecież już od 68020 mamy cache, ma go 68060, to co stoi na przeszkodzie dać kilka MB statycznego cache takiemu 68080?
I żeby nie było, że bujam w obłokach, to nie mam najmniejszych oczekiwań, że ktoś kiedyś podejmie się takiego zadania. Traktuję te rozważania czysto teoretycznie.
Chociaż, czy powiedzmy 30 lat temu ktoś mógł przewidzieć, że za równowartość obiadu w restauracji będę mógł kupić niewielki układ scalony, który po zaprogramowaniu specjalnym językiem opisującym topologię i logikę połączeń będzie mógł robić za dowolny mikroprocesor, czy układ graficzny taktowany nawet kilkaset MHz? Albo że w domu będzie sobie można postawić maszynkę, która w kilka godzin wydrukuje mi trójwymiarowy, w pełni funkcjonalny przedmiot z tworzywa sztucznego... albo taką małą frezareczkę do metalu sterowaną komputerowo, do kupienia za kilka dniówek... Kto wie, co nam przyniesie przyszłość? Może będzie sobie można takiego ASICA tanio wysmażyć w domu :) albo w firmie specjalizującej się w takich zabawach (tak jak dzisiejsze prototypowanie PCB w chińskiej płytkarni za relatywnie małe pieniądze).
Z mojej branży - kilkanaście lat temu edycja DNA i synteza genów w laboratorium to była zabawa za setki tysięcy dolarów, 30 lat temu zaś to było praktycznie science-fiction. Kilka miesięcy temu koledzy z naszego projektu wysłali zaprojektowany przez siebie gen ze stosownymi sekwencjami regulacyjnymi (kilka tysięcy par zasad, czyli jak kto woli liter kodu DNA), w postaci pliku, jako załącznik do maila do firmy syntetyzującej geny. Zapłacili kilkaset zł (tak, tylko tyle) i otrzymali próbówkę z zamówionym DNA, które wszczepili do drożdży. Po wielu próbach uruchomili ten gen, drożdże wyprodukowały białko. Dodali substrat, i po oczyszczeniu przysłali to do mnie - oznaczyłem, sprawdziłem, policzyłem (w projekcie robię za analityka który weryfikuje, to co nasi magicy DNA wysmażą) - wynik: działa. Czyli przerabia CBG-A na THC-A (nawiązanie do konopi nieprzypadkowe ;) ) - nasz sztuczny, zaprojektowany w komputerze gen, zadziałał. Chociaż został stworzony całkowicie sztucznie, wyprodukował enzym, który pozwoli (mamy nadzieję) na tanie produkowanie THC-A do celów medycznych, bez obecnych problemów z koniecznością ochrony plantacji konopi. Synteza zamówionego DNA kosztowała kilkaset zł!
Po co to opisuję? Bo to pokazuje, jak niesamowicie szybki jest rozwój naukowo-techniczny, który nie tylko czyni możliwym to, co kilkadziesiąt lat temu było czystym science-fiction, ale czyni to także niezwykle tanim.
Tak więc, mimo, że obecnie traktuję to jako czystą teorię, to man nadzieję, że za niedługi czas po raz kolejny science-fiction stanie się niedrogą codziennością.
Ostatnia aktualizacja: 24.08.2025 22:19:55 przez wali7
24.08 22:21
[#11]
Re: Zbiórka na MMU dla Vampire v4
@wali7, post #10
Po co ruszać konopie, są ok jakie są 
Nawiasem mówiąc po co modyfikować genetycznie genom drożdży jak można to zrobić na żywym organizmie.
Jest taka technika CRISPR-Cas9 która pozwala podmienić DOWOLNY gen na DOWOLNY inny gen w żywym organizmie. Nobel nawet dali za to.
Na ludziach to Chińczycy eksperymentują od lat. No bo co. Ktoś ma Cukrzycę typu I - bang CRISPR-Cas9 - i ... nie ma.
Haracz koncernów PHARMA zbierany od przewlekle chorych ma się ku końcowi.
BTW planujesz a mi par ty?
Nawiasem mówiąc po co modyfikować genetycznie genom drożdży jak można to zrobić na żywym organizmie.
Jest taka technika CRISPR-Cas9 która pozwala podmienić DOWOLNY gen na DOWOLNY inny gen w żywym organizmie. Nobel nawet dali za to.
Na ludziach to Chińczycy eksperymentują od lat. No bo co. Ktoś ma Cukrzycę typu I - bang CRISPR-Cas9 - i ... nie ma.
Haracz koncernów PHARMA zbierany od przewlekle chorych ma się ku końcowi.
BTW planujesz a mi par ty?
24.08 22:33
[#12]
Re: Zbiórka na MMU dla Vampire v4
@_DiskDoctor_, post #11
Z konopiami nic nie robimy. Tylko z drożdżami. :)
Tak, CRISPR/Cas9 jest rewolucyjny, ale tu mamy gen który rozpoczął się jako sekwencja w komputerze. Dopiero potem synteza od zera. Za kilkaset zł!!!
Dopiero wtedy masz czas na CRISPR, chociaż nie wiem jak to chłopaki zrobili, mogę się zapytać. Możliwe że tak było, bo gdy dyskutowałem z nimi kilka dni temu wyniki, na pytanie, czy to jest w formie plazmidu wewnątrz komórki, powiedzieli mi, że raczej oczekują wbudowania w genom. Więc być może był i CRISP.
To wszystko pokazuje, jak wiele można obecnie zrobić, i za jak niewielkie pieniądze (w porównaniu do tego co było dawniej).
Co do BigPharmy, to badania nad lekami są niezwykle złożone i kosztowne. Pracowałem rok w firmie projektującej nowe leki i miałem okazję przekonać się jak to wygląda od kuchni. Natomiast warto walczyć z patentowaniem i nadmiernym zarabianiem na starych lekach np. odkrytej ponad 100 lat temu insulinie.
Co do AmiParty, to oczywiście, wybieram się. :)
Ostatnia aktualizacja: 24.08.2025 22:36:20 przez wali7
Tak, CRISPR/Cas9 jest rewolucyjny, ale tu mamy gen który rozpoczął się jako sekwencja w komputerze. Dopiero potem synteza od zera. Za kilkaset zł!!!
Dopiero wtedy masz czas na CRISPR, chociaż nie wiem jak to chłopaki zrobili, mogę się zapytać. Możliwe że tak było, bo gdy dyskutowałem z nimi kilka dni temu wyniki, na pytanie, czy to jest w formie plazmidu wewnątrz komórki, powiedzieli mi, że raczej oczekują wbudowania w genom. Więc być może był i CRISP.
To wszystko pokazuje, jak wiele można obecnie zrobić, i za jak niewielkie pieniądze (w porównaniu do tego co było dawniej).
Co do BigPharmy, to badania nad lekami są niezwykle złożone i kosztowne. Pracowałem rok w firmie projektującej nowe leki i miałem okazję przekonać się jak to wygląda od kuchni. Natomiast warto walczyć z patentowaniem i nadmiernym zarabianiem na starych lekach np. odkrytej ponad 100 lat temu insulinie.
Co do AmiParty, to oczywiście, wybieram się. :)
Ostatnia aktualizacja: 24.08.2025 22:36:20 przez wali7
wczoraj 05:46
[#13]
Re: Zbiórka na MMU dla Vampire v4
@Don_Adan, post #9
Nic nie mylę. Żeby wykonać instrukcje to najpierw je trzeba POBRAĆ. Jak myślisz skąd? I trzeba je pobrać z odpowiednim wyprzedzeniem żeby zdążyć je przetworzyć zanim trafią do ALU. Właśnie dlatego istotna była odpowiednio szybka pamięć. Z EDO/FPM szału nie będzie. Ale możesz wierzyć w co tam tylko sobie chcesz.
wczoraj 05:48
[#14]
Re: Zbiórka na MMU dla Vampire v4
@wali7, post #10
Tak, i pod EDO był projektowany. W przeciwieństwie do AC68080... Który z pamięcią EDO nie będzie prawdopodobnie wcale "bezpośrednio" działał tylko jeszcze przez logic level translatora. W przeciwieństwie do DDR3 podłączonego bezpośrednio do FPGA. Ale co ja tam mogę wiedzieć ...
Ostatnia aktualizacja: 25.08.2025 05:50:19 przez abcdef
Ostatnia aktualizacja: 25.08.2025 05:50:19 przez abcdef
wczoraj 08:17
[#15]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #13
Instrukcje sie pobiera albo z pamieci albo z cache procesora.
Cache 68080 jest w FPGA, a nie w zewnetrznej pamieci, dlatego jest limitowany.
Nic tutaj nie ma o szybkiej pamieci, ale o "powerful cache" jest:
link
Dla ciebie to typ pamieci zewnetrznej V4 robi robote, dla mnie nie.
Zewnetrzna pamiec ma znaczenie tylko dla operacji kopiowania danych.
Za to cache ma znaczenie zawsze.
Cache 68080 jest w FPGA, a nie w zewnetrznej pamieci, dlatego jest limitowany.
Nic tutaj nie ma o szybkiej pamieci, ale o "powerful cache" jest:
link
Dla ciebie to typ pamieci zewnetrznej V4 robi robote, dla mnie nie.
Zewnetrzna pamiec ma znaczenie tylko dla operacji kopiowania danych.
Za to cache ma znaczenie zawsze.
wczoraj 09:07
[#16]
Re: Zbiórka na MMU dla Vampire v4
@Don_Adan, post #15
Cache to bufor który trzeba uzupełniać. Cache symulowanego w fpga tej klasy jest relatywnie mało. Dlatego reload kolejki w razie missa jest mniej bolesny jak masz szybki interfejs do pamięci zewnętrznej. I tak właśnie jest z DDR3 które o ile dobrze pamiętam i tak działa wolniej niż może ale o ile pamiętam działa szybciej niż rdzeń. A jak będzie z Edo? No inaczej. Gorzej, nie pudrujmy i nie ukrywamy że byłoby inaczej.
wczoraj 10:49
[#17]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #16
Ja nie twierdze, ze z inna pamiecia byloby lepiej.
Ale zewnetrzna pamiec to nie jest procesor.
Zewnetrzna pamiec do procesora sie zwykle dobiera na podstawie koszt/efekt, i jej dostepnoscia.
Gunnar tez sie pewnie tym kierowal czyli cena i efektem jakie mu dany typ pamieci zapewni.
Choc to raczej nie Gunnar jest autorem Apollo V4, tylko ten drugi inzynier (zapomnialem nazwiska).
Gunnar na pewno doradzal jaka pamiec wybrac dla Apollo V4, i jest autorem kontrolera pamieci w 68080.
Byc moze robili jakies testy, ktora pamiec wybrac dla Apollo V4, ale to raczej normalne jak sie robi karte turbo.
Tutaj masz przyklad karty turbo "na bogato" z 68030, i 256MB SDRAM.
Ta karta bije swoimi osiagami kazda inna karte turbo z 68030.
Tylko to, ze typ uzywanej pamieci ma wplyw na jej osiagi, nie sprawia ze 68030 w tej karcie to jest jakies inne 68030 (lepsze).
link
To samo dotyczy 68080, to jest tylko procesor, z jedna pamiecia bedzie dzialal wolniej z inna szybciej.
Czy Gunnar lub ten drugi inzynier wybral pamiec optymalnie?
Tego nie wiem, nie znam sie na pamieciach.
Ale raczej nie byl to zly wybor.
Ale zewnetrzna pamiec to nie jest procesor.
Zewnetrzna pamiec do procesora sie zwykle dobiera na podstawie koszt/efekt, i jej dostepnoscia.
Gunnar tez sie pewnie tym kierowal czyli cena i efektem jakie mu dany typ pamieci zapewni.
Choc to raczej nie Gunnar jest autorem Apollo V4, tylko ten drugi inzynier (zapomnialem nazwiska).
Gunnar na pewno doradzal jaka pamiec wybrac dla Apollo V4, i jest autorem kontrolera pamieci w 68080.
Byc moze robili jakies testy, ktora pamiec wybrac dla Apollo V4, ale to raczej normalne jak sie robi karte turbo.
Tutaj masz przyklad karty turbo "na bogato" z 68030, i 256MB SDRAM.
Ta karta bije swoimi osiagami kazda inna karte turbo z 68030.
Tylko to, ze typ uzywanej pamieci ma wplyw na jej osiagi, nie sprawia ze 68030 w tej karcie to jest jakies inne 68030 (lepsze).
link
To samo dotyczy 68080, to jest tylko procesor, z jedna pamiecia bedzie dzialal wolniej z inna szybciej.
Czy Gunnar lub ten drugi inzynier wybral pamiec optymalnie?
Tego nie wiem, nie znam sie na pamieciach.
Ale raczej nie byl to zly wybor.
wczoraj 11:36
[#19]
Re: Zbiórka na MMU dla Vampire v4
@Don_Adan, post #17
Sram w fpga jest mało a trzeba go jeszcze odpowiednio skonfigurować. Parcie na cache jest tym większe im większa jest dysproporcja między czasem dostępu pamięci a zapotrzebowaniem na dane rdzenia. Czyli w telegraficznym skrócie więcej instrukcji na cykl = większe obciążenie podsystemu pamięci. Większy zegar rdzenia = większe obciążenie podsystemu pamięci. A tu masz 2w1. Cała magia 68080 w zestawieniu z ppc którą już 5 lat temu Gunnar pokazywał wynika właśnie z tego że 080 MA szybką pamięć operacyjną a 603e nie miało. icache w zeszłym roku mogło wciągnąć 16 bajtów na cykl CPU. 16 bajtów. Jak myślisz czemu? I czy da radę z Edo? Ja uważam że nie. I serio na tym etapie będę jak niewierny Tomasz... Uwierzę jak zobaczę że jednak się da.
wczoraj 13:05
[#20]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #19
Raczej nikt tego nie zrobi, więc Twoja postawa niewiernego Tomasza jest dosyć bezpieczna :)
Ale nie jest możliwe dołożenie zewnętrznego cache (jakiś szybki SRAM) w ilości kilku MB? W epoce CPU popędzanych setkami MHz (Pentium II, Pentium III, K6-2) normą był odpowiedni cache, często zewnętrzny i EDO RAM.
Nie twierdzę, że taki kilkusetmegahertzowy 68080 nie będzie cierpiał przy ograniczeniu do EDO RAM, ale zakładam że osiągi ponad amigowy, koszerny top, czyli 68060@100MHz będą kilka razy lepsze.
Zresztą my tu teoretyzujemy. Bo nie chodzi o użycie obecnego FPGA jako zamiennika 68060, bo takie podejście wymaga dodania odpowiednich układów konwertujących napięcia, a wtedy to już spokojnie można dorzucić kilka kostek z szybkim RAMem. I takie coś jest, nazywa się Vampire
.
My tu teoretyzujemy (w ramach oftopa) o układzie ASIC w którym znajdowałby się rdzeń 68080. W takiej sytuacji przecież można dołożyć całkiem sporą ilość cache, bo ograniczenia FPGA tego przypadku nie dotyczą.
Ale nie jest możliwe dołożenie zewnętrznego cache (jakiś szybki SRAM) w ilości kilku MB? W epoce CPU popędzanych setkami MHz (Pentium II, Pentium III, K6-2) normą był odpowiedni cache, często zewnętrzny i EDO RAM.
Nie twierdzę, że taki kilkusetmegahertzowy 68080 nie będzie cierpiał przy ograniczeniu do EDO RAM, ale zakładam że osiągi ponad amigowy, koszerny top, czyli 68060@100MHz będą kilka razy lepsze.
Zresztą my tu teoretyzujemy. Bo nie chodzi o użycie obecnego FPGA jako zamiennika 68060, bo takie podejście wymaga dodania odpowiednich układów konwertujących napięcia, a wtedy to już spokojnie można dorzucić kilka kostek z szybkim RAMem. I takie coś jest, nazywa się Vampire
.My tu teoretyzujemy (w ramach oftopa) o układzie ASIC w którym znajdowałby się rdzeń 68080. W takiej sytuacji przecież można dołożyć całkiem sporą ilość cache, bo ograniczenia FPGA tego przypadku nie dotyczą.
wczoraj 13:33
[#22]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #19
Masz zle podejscie.
68080 jest szybsze niz 603e przy tym samym zegarze.
Potrzebuje tez mniej instrukcji wykonac do kopiowania danych.
Na 680x0 do kopiowania wystarczy 1 instrukcja, na 603e to 3 lub 5 (nie pamietam, bo PPC mnie nie interesuje).
Do tego 68080 to jest procesor 64 bitowy, a nie 32 bitowy, czyli 2 razy szybciej kopiuje dane.
Ma tez zdecydowanie lepszy cache.
Pamiec ma znaczenie, przy kopiowaniu, ale i z EDO, 68080 bedzie szybsza od 603e.
Wiec to nie magia, tylko 68080 jest po prostu lepszym procesorem niz 603e czy 68060.
I to ci powie kazdy programista, oprocz fanow MMU jak Thor.
No i po co robic karte z pamiecia, ktora schodzi z rynku, lub jest juz prawie nieuzywana?
Lepiej zrobic karte, ktorej skladniki sa tanie i latwe do dostania, cos jak PiStorm.
Zreszta jak masz pytania to sie mozesz Gunnara spytac, dlaczego jest tak a nie inaczej.
68080 jest szybsze niz 603e przy tym samym zegarze.
Potrzebuje tez mniej instrukcji wykonac do kopiowania danych.
Na 680x0 do kopiowania wystarczy 1 instrukcja, na 603e to 3 lub 5 (nie pamietam, bo PPC mnie nie interesuje).
Do tego 68080 to jest procesor 64 bitowy, a nie 32 bitowy, czyli 2 razy szybciej kopiuje dane.
Ma tez zdecydowanie lepszy cache.
Pamiec ma znaczenie, przy kopiowaniu, ale i z EDO, 68080 bedzie szybsza od 603e.
Wiec to nie magia, tylko 68080 jest po prostu lepszym procesorem niz 603e czy 68060.
I to ci powie kazdy programista, oprocz fanow MMU jak Thor.
No i po co robic karte z pamiecia, ktora schodzi z rynku, lub jest juz prawie nieuzywana?
Lepiej zrobic karte, ktorej skladniki sa tanie i latwe do dostania, cos jak PiStorm.
Zreszta jak masz pytania to sie mozesz Gunnara spytac, dlaczego jest tak a nie inaczej.
wczoraj 13:37
[#23]
Re: Zbiórka na MMU dla Vampire v4
@Commodore128D, post #21
Oczywiście masz rację. Ale teraz jest tyle możliwości :)
ASIC jest koszerny. Przynajmniej moim zdaniem :)
A FPGA to już koszernosci trochę mniej. A emulacja np. w ARM jeszcze dalej odbiega od pierwowzoru. Ale oczywiście, nadal można zachować 100% użytkowych zalet oryginału.
Ja sobie polutowałem minimiga 1.97ITX. Cały chipset jest w FPGA, więc poważna utrata amikoszerności jest, ale mamy prawdziwy RAM, prawdziwy CPU, wszystko działa jak w prawdziwej A500.
Potem sobie dałem do niego amigową kartę turbo 68030 128 MB RAM.
A na koniec wrzuciłem Pistorma uznając, że skoro chipset i tak mam w FPGA, to mogę iść na całość i CPU mieć emulowany ARMem. A do tego za darmo RTG, mnóstwo RAM, szybki dysk i wifi. Czy to jest nadal Amiga? Raczej nie, ale trzyma ducha i bardzo lubię ten komputerek.
Zrobiłem o nim dwa filmy:
i
ASIC jest koszerny. Przynajmniej moim zdaniem :)
A FPGA to już koszernosci trochę mniej. A emulacja np. w ARM jeszcze dalej odbiega od pierwowzoru. Ale oczywiście, nadal można zachować 100% użytkowych zalet oryginału.
Ja sobie polutowałem minimiga 1.97ITX. Cały chipset jest w FPGA, więc poważna utrata amikoszerności jest, ale mamy prawdziwy RAM, prawdziwy CPU, wszystko działa jak w prawdziwej A500.
Potem sobie dałem do niego amigową kartę turbo 68030 128 MB RAM.
A na koniec wrzuciłem Pistorma uznając, że skoro chipset i tak mam w FPGA, to mogę iść na całość i CPU mieć emulowany ARMem. A do tego za darmo RTG, mnóstwo RAM, szybki dysk i wifi. Czy to jest nadal Amiga? Raczej nie, ale trzyma ducha i bardzo lubię ten komputerek.
Zrobiłem o nim dwa filmy:
i
wczoraj 17:35
[#26]
Re: Zbiórka na MMU dla Vampire v4
@Don_Adan, post #22
Dobra, zaczynając od początku:
1. pierwsze pokazy nie uwzględniały w ogóle 64b, bo po co? Wiesz po co w procesorach jest 64b? Z pierwszego zasadniczego powodu - żeby obsłużyć więcej RAM, drugi powód jest dość banalny i polega na tym, że jak już liczymy 64b adresy to dobrze byłoby żeby to też był natywny typ danych także dla ALU co zapewnia wsparcie dla typu long long w C. Wiesz jak często ten typ jest wykorzystywany? No generalnie nie aż tak często. Dalej lwia część obliczeń jest na typach 32b. Co jest tłumaczone na rozkazy odnoszące się do 32b rejestrów (nie dziwne). Co oznacza, że 64b w tym zakresie nic nie zmienia. I taki też generalnie był efekt uruchamiania softu 32b na procesorach (i systemach) 64bitowych w x86 oraz ARM. I nie inaczej jest z kodem pisanym pod 040 czy 060. Parę rzeczy może przyspieszyć z innego powodu niż 64b rejestry i magistrale między pamięcią, cache i alu. Ale generalnie zysk z 64b ALU i rejestrów jest dla typów 64b + adresów 64b.
2. zupełnie bez znaczenia, a wiesz dlaczego bez znaczenia? Bo po to wszystkie RISC miały potok (i to wcześniej niż CISC). To ma tylko i wyłącznie znaczenie przy wielkości kodu (CISC oferowało bardziej kompaktowy kod) i co się z tym wiąże zużycie pamięci. Cała reszta (jeśli chodzi o manipulację danymi) to nie zasługa ISA, a kontrolera pamięci i układu prefetch. W przypadku CISC cała instrukcja "MOV" i tak była normalnie wykonywana w iluś tam cyklach (i to wolniej niż kilka instrukcji w RISC) dopiero przetwarzanie w potoku wyrównało szanse (040+). A dlaczego "wyrównało"? Bo generalnie każdą instrukcję można rozbić na takie "operacje atomowe". I RISC generalnie ma 1:1 ;) Więc on już na starcie miał to co CISC wdrożył z implementacją swojej wersji architektury superskalarnej potokowej (to jest powód dlaczego wszystkie CISC w latach 80 i 90 dostawały tęgie baty od RISC jeśli chodzi o wydajność obliczeniową na MHz i efektywność energetyczną).
3. jak @1 - jeśli używasz w większości typów 32bitowych to procesor 64b jeśli kopiuje szybciej to tylko jak ma ładnie ułożone dane w pamięci żeby je jednym burstem wciągnąć. Ale to nie ma wiele wspólnego z byciem 64b bo Pentium II też miał 64b szerokości kontroler pamięci i obsługiwał (a jakże) burst pamięci SDR. A 64b procesory K10 miały aż 128b kontroler (i7 nawet 192b!!).
4 - jeszcze raz - ASIC swoje we wdrożeniu będzie kosztował, jakoś wątpię by celem było ograniczanie się do pamięci na starych kartach turbo, jeśli CPU będzie przetwarzał dane szybciej niż kontroler może zapełniać cache to będzie stalling. I o to mi własnie chodzi, że jest to na ten moment najbardziej prawdopodobny scenariusz. To tak jakbyś wziął teraz ZEN i podłączył jakoś pamięć DDR - no i co, będzie choć porównywalnie wydajny w kodzie do ZEN na DDR4/DDR5? Pewnie, jak cały kod będzie z cache (a ten akurat jest w ZEN zacny). Ale poza tym to będzie efekt jakbyś babę do pługa zaprzągł zamiast pary wołów. Sprawę mógłby załatwić embedded DDRx w ASICu, ale tutaj byłoby to problemem jeśli taki "drop in replacement" miałby działać w sprzętach industrialnych gdzie 060 było popularne i gdzie coś mogło siedzieć na bardzo konkretnych adresach więc umiejscowienie wbudowanej pamięci w liniowej przestrzeni by mieć kompatybilność ze wszystkim mogłoby być wyzwaniem. A możliwość drop-in dla industrial (że o MIL nie wspomnę) jest akurat dobrym pomysłem (bo wbrew pozorom sporo takiego sprzętu dalej gdzieś tam działa!) tylko kto to zwaliduje że się nie wysypie na AC68080? No nikt.
5 - to jest bez znaczenia, bo pod 603 jest soft dla Amigi, a pod 64b 080 jest parę pierdołek + odtwarzarka z AMMX. Więc na ten moment jakiekolwiek nowości jakie wnosi AC68080 sa mocno ograniczone (to samo jeśli chodzi o SAGA i Maggie), szeroko stosowany ASIC i zaktualizowane narzędzia programistyczne mogłyby pomóc, ale wymagałoby to też wsparcia w OS, a tu sorry, ale jednak jak już ktoś ma apollo czy blizza 060 to siedzi albo na 3.9 albo na 3.2, a nie na odpicowanym AROS (nie ujmując nic arosowi!), a potencjalny rynek dla ASIC 080 jeszcze okraja PiStorm i będzie okrajał z każdym SoC, który się będzie dało jakoś interfejsować z Amigą. Na ten moment jest hard stop na Pi4, ale nie oznacza to, że tak musi pozostać.
6 - po ragequit na eab to ja z Gunnarem nie mam o czym dyskutować tak samo jak ze Stephenem po ragequit z ppa. To są niestety osoby, które bardzo personalnie biorą wszystko o czym się dyskutuje no i w porywach namiętności potrafią się obrazić na cały świat. To nie są partnerzy do dyskusji, niezależnie od wiedzy jaką reprezentują. I to było też widać w niektórych tematach na forum apollo. Przy czym przypomnę tylko, że MMU to dla Gunnara nie był wcale priorytet, a MMU kompatybilny z 68k był tylko wymysłem amigowców, bo jego rozwiązanie było lepsiejsze więc po co komu coś innego ;) To teraz co, czekamy na extended precision w 080? I cyk zrzutka od emulujących japko!
Ostatnia aktualizacja: 25.08.2025 17:36:55 przez abcdef
1. pierwsze pokazy nie uwzględniały w ogóle 64b, bo po co? Wiesz po co w procesorach jest 64b? Z pierwszego zasadniczego powodu - żeby obsłużyć więcej RAM, drugi powód jest dość banalny i polega na tym, że jak już liczymy 64b adresy to dobrze byłoby żeby to też był natywny typ danych także dla ALU co zapewnia wsparcie dla typu long long w C. Wiesz jak często ten typ jest wykorzystywany? No generalnie nie aż tak często. Dalej lwia część obliczeń jest na typach 32b. Co jest tłumaczone na rozkazy odnoszące się do 32b rejestrów (nie dziwne). Co oznacza, że 64b w tym zakresie nic nie zmienia. I taki też generalnie był efekt uruchamiania softu 32b na procesorach (i systemach) 64bitowych w x86 oraz ARM. I nie inaczej jest z kodem pisanym pod 040 czy 060. Parę rzeczy może przyspieszyć z innego powodu niż 64b rejestry i magistrale między pamięcią, cache i alu. Ale generalnie zysk z 64b ALU i rejestrów jest dla typów 64b + adresów 64b.
2. zupełnie bez znaczenia, a wiesz dlaczego bez znaczenia? Bo po to wszystkie RISC miały potok (i to wcześniej niż CISC). To ma tylko i wyłącznie znaczenie przy wielkości kodu (CISC oferowało bardziej kompaktowy kod) i co się z tym wiąże zużycie pamięci. Cała reszta (jeśli chodzi o manipulację danymi) to nie zasługa ISA, a kontrolera pamięci i układu prefetch. W przypadku CISC cała instrukcja "MOV" i tak była normalnie wykonywana w iluś tam cyklach (i to wolniej niż kilka instrukcji w RISC) dopiero przetwarzanie w potoku wyrównało szanse (040+). A dlaczego "wyrównało"? Bo generalnie każdą instrukcję można rozbić na takie "operacje atomowe". I RISC generalnie ma 1:1 ;) Więc on już na starcie miał to co CISC wdrożył z implementacją swojej wersji architektury superskalarnej potokowej (to jest powód dlaczego wszystkie CISC w latach 80 i 90 dostawały tęgie baty od RISC jeśli chodzi o wydajność obliczeniową na MHz i efektywność energetyczną).
3. jak @1 - jeśli używasz w większości typów 32bitowych to procesor 64b jeśli kopiuje szybciej to tylko jak ma ładnie ułożone dane w pamięci żeby je jednym burstem wciągnąć. Ale to nie ma wiele wspólnego z byciem 64b bo Pentium II też miał 64b szerokości kontroler pamięci i obsługiwał (a jakże) burst pamięci SDR. A 64b procesory K10 miały aż 128b kontroler (i7 nawet 192b!!).
4 - jeszcze raz - ASIC swoje we wdrożeniu będzie kosztował, jakoś wątpię by celem było ograniczanie się do pamięci na starych kartach turbo, jeśli CPU będzie przetwarzał dane szybciej niż kontroler może zapełniać cache to będzie stalling. I o to mi własnie chodzi, że jest to na ten moment najbardziej prawdopodobny scenariusz. To tak jakbyś wziął teraz ZEN i podłączył jakoś pamięć DDR - no i co, będzie choć porównywalnie wydajny w kodzie do ZEN na DDR4/DDR5? Pewnie, jak cały kod będzie z cache (a ten akurat jest w ZEN zacny). Ale poza tym to będzie efekt jakbyś babę do pługa zaprzągł zamiast pary wołów. Sprawę mógłby załatwić embedded DDRx w ASICu, ale tutaj byłoby to problemem jeśli taki "drop in replacement" miałby działać w sprzętach industrialnych gdzie 060 było popularne i gdzie coś mogło siedzieć na bardzo konkretnych adresach więc umiejscowienie wbudowanej pamięci w liniowej przestrzeni by mieć kompatybilność ze wszystkim mogłoby być wyzwaniem. A możliwość drop-in dla industrial (że o MIL nie wspomnę) jest akurat dobrym pomysłem (bo wbrew pozorom sporo takiego sprzętu dalej gdzieś tam działa!) tylko kto to zwaliduje że się nie wysypie na AC68080? No nikt.
5 - to jest bez znaczenia, bo pod 603 jest soft dla Amigi, a pod 64b 080 jest parę pierdołek + odtwarzarka z AMMX. Więc na ten moment jakiekolwiek nowości jakie wnosi AC68080 sa mocno ograniczone (to samo jeśli chodzi o SAGA i Maggie), szeroko stosowany ASIC i zaktualizowane narzędzia programistyczne mogłyby pomóc, ale wymagałoby to też wsparcia w OS, a tu sorry, ale jednak jak już ktoś ma apollo czy blizza 060 to siedzi albo na 3.9 albo na 3.2, a nie na odpicowanym AROS (nie ujmując nic arosowi!), a potencjalny rynek dla ASIC 080 jeszcze okraja PiStorm i będzie okrajał z każdym SoC, który się będzie dało jakoś interfejsować z Amigą. Na ten moment jest hard stop na Pi4, ale nie oznacza to, że tak musi pozostać.
6 - po ragequit na eab to ja z Gunnarem nie mam o czym dyskutować tak samo jak ze Stephenem po ragequit z ppa. To są niestety osoby, które bardzo personalnie biorą wszystko o czym się dyskutuje no i w porywach namiętności potrafią się obrazić na cały świat. To nie są partnerzy do dyskusji, niezależnie od wiedzy jaką reprezentują. I to było też widać w niektórych tematach na forum apollo. Przy czym przypomnę tylko, że MMU to dla Gunnara nie był wcale priorytet, a MMU kompatybilny z 68k był tylko wymysłem amigowców, bo jego rozwiązanie było lepsiejsze więc po co komu coś innego ;) To teraz co, czekamy na extended precision w 080? I cyk zrzutka od emulujących japko!
Ostatnia aktualizacja: 25.08.2025 17:36:55 przez abcdef
wczoraj 19:25
[#27]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #26
Pewnie na procesorach 64b sie znasz, ale na AC68080 nie.
AC68080 ma tylko 64 bitowe rejestry danych.
Nie ma 64 bitowych rejestrow adresowych (lub przynajmniej nie sa one uzywane), nie ma 64 bitowych instrukcji adresowych.
Czyli w skrocie obsluguje 32 bitowe rejestry adresowe, i 64 bitowe rejestry danych.
Mozesz to porownac z 68000/68010/68EC020 i tylko 24 bitowym adresowaniem tych procesorow.
Nie zrobisz na AC68080 czegos takiego jak:
lea $123456789,A0
Do kopiowania 64 bitowego, wcale nie musisz uzywac 64 bitowych instrukcji.
Wystarcza 32 bitowe polaczone w jedna 64 bitowa wewnetrznie.
I tak to robi AC68080, laczy w jeden 64 bitowy odczyt/zapis instrukcji 32 bitowych.
Zreszta na PPA byl watek o optymalizacji kopiowania, i pare osob probowalo, ale to nic ne dawalo, wyniki kopiowania byly takie same, mimo bardzo roznych procedur kopiujacych, choc nie powinny byc.
Dopiero potem przyszlo mi do glowy, ze tester robil pomiary na 68080, a nie na 68040 czy 68060.
A 68080 ma kopiowanie maksymalnie zoptymalizowane.
Apollo Core 68080 advantages:
Fully Pipelined
Superscalar
Executes up to six instructions per clock cycle
Two address calculation engines
Two integer execution engines
Market leading code density
Optimal cache utilization
Separate data and instruction caches, supporting concurrent fetch/read/write per clock cycle
Automatic memory prefetching
Memory stream detection
Store buffer
Branch prediction
Fully pipelined, 64bit SIMD AMMX Vector unit
Fully pipelined, double precision FPU
AC68080 ma tylko 64 bitowe rejestry danych.
Nie ma 64 bitowych rejestrow adresowych (lub przynajmniej nie sa one uzywane), nie ma 64 bitowych instrukcji adresowych.
Czyli w skrocie obsluguje 32 bitowe rejestry adresowe, i 64 bitowe rejestry danych.
Mozesz to porownac z 68000/68010/68EC020 i tylko 24 bitowym adresowaniem tych procesorow.
Nie zrobisz na AC68080 czegos takiego jak:
lea $123456789,A0
Do kopiowania 64 bitowego, wcale nie musisz uzywac 64 bitowych instrukcji.
Wystarcza 32 bitowe polaczone w jedna 64 bitowa wewnetrznie.
I tak to robi AC68080, laczy w jeden 64 bitowy odczyt/zapis instrukcji 32 bitowych.
Zreszta na PPA byl watek o optymalizacji kopiowania, i pare osob probowalo, ale to nic ne dawalo, wyniki kopiowania byly takie same, mimo bardzo roznych procedur kopiujacych, choc nie powinny byc.
Dopiero potem przyszlo mi do glowy, ze tester robil pomiary na 68080, a nie na 68040 czy 68060.
A 68080 ma kopiowanie maksymalnie zoptymalizowane.
Apollo Core 68080 advantages:
Fully Pipelined
Superscalar
Executes up to six instructions per clock cycle
Two address calculation engines
Two integer execution engines
Market leading code density
Optimal cache utilization
Separate data and instruction caches, supporting concurrent fetch/read/write per clock cycle
Automatic memory prefetching
Memory stream detection
Store buffer
Branch prediction
Fully pipelined, 64bit SIMD AMMX Vector unit
Fully pipelined, double precision FPU
wczoraj 20:31
[#28]
Re: Zbiórka na MMU dla Vampire v4
@Don_Adan, post #27
Podpieram się tym z samej strony Apollo ...
Zakładam, że jest to wielka improwizacja stylizowana na x86-64 gdzie 16bitowe AX, BX (itp) zostały rozszerzone do 32bit EAX, EBX ... a potem do 64b RAX, RBX gdzie dalej pod RBX jest wydzielone 32bit EAX a w nim 16bit AX dla tego typu rozkazów. Natomiast nowe R8-R15 są już tylko 64bit (i jak dobrze kojarzę tylko dostępne w 64bit trybie LONG czyli w 64b systemie) co oznacza, że tutaj jest nieco ciekawsza opcja w AC68080 bo jakoś są dostępne w 32bit OS, tylko coś mi się zdaje, że taki OS nie do końca poprawnie może obsłużyć co się z CPU dzieje ;) Ale to detale
Jeśli już mamy wyjaśnioną sprawę 64bit rejestrów adresowych (chyba, że strona Apollo podaje nieprawdę) to przejdźmy do "64bit manipulacji danymi"
nie pamiętam jak jest zorganizowana pamięć zewnętrzna w Vampire, ale DDR3 obsługuje burst do 8 transferów. Burst polega na tym, że wysyłamy startowy adres, odczytujemy z niego dane, a potem zamiast wysyłać kolejne adresy po prostu licznik sam się przestawia (co zdecydowanie oszczędza czasu) przez co dostajemy kolejne 7 wartości (razem 8, ale może być tylko 4). W FPM burst to było zdaje się max 4 kolejne transfery, przy czasie dostępu rzędu 60-70ns. DDR3 nawet taktowane "zaledwie" w okolicach zegara CPU to nie dość, że 8 transferów w BURST to jeszcze DDR więc transfery na zboczach rosnących i opadających. I to przy zdecydowanie niższych timingach. Innymi słowy nie dość, że więcej danych to jeszcze zdecydowanie szybciej dostępne. I to ROBI ROBOTĘ, bo odciąża CACHE, którego ilość i struktura w FPGA jest mocno ograniczona. Czy w ASICu byłoby super? No kto pamięta Celeron Tualatin vs Pentium Tualatin? 256KB L2 z FSB 100MHz kontra 512KB L2 z FSB133? Właśnie... To samo tylko jeszcze bardziej spektakularne jest tym co bym się spodziewał po AC68080 sparowanym z DRAM z czasów 060. Im szybszy rdzeń tym więcej wymaga od pamięci. I nie, cache wszystkiego nie załatwi.
16 64-Bit Address registers (A0-7/B0-B7)
Zakładam, że jest to wielka improwizacja stylizowana na x86-64 gdzie 16bitowe AX, BX (itp) zostały rozszerzone do 32bit EAX, EBX ... a potem do 64b RAX, RBX gdzie dalej pod RBX jest wydzielone 32bit EAX a w nim 16bit AX dla tego typu rozkazów. Natomiast nowe R8-R15 są już tylko 64bit (i jak dobrze kojarzę tylko dostępne w 64bit trybie LONG czyli w 64b systemie) co oznacza, że tutaj jest nieco ciekawsza opcja w AC68080 bo jakoś są dostępne w 32bit OS, tylko coś mi się zdaje, że taki OS nie do końca poprawnie może obsłużyć co się z CPU dzieje ;) Ale to detale
Jeśli już mamy wyjaśnioną sprawę 64bit rejestrów adresowych (chyba, że strona Apollo podaje nieprawdę) to przejdźmy do "64bit manipulacji danymi"
nie pamiętam jak jest zorganizowana pamięć zewnętrzna w Vampire, ale DDR3 obsługuje burst do 8 transferów. Burst polega na tym, że wysyłamy startowy adres, odczytujemy z niego dane, a potem zamiast wysyłać kolejne adresy po prostu licznik sam się przestawia (co zdecydowanie oszczędza czasu) przez co dostajemy kolejne 7 wartości (razem 8, ale może być tylko 4). W FPM burst to było zdaje się max 4 kolejne transfery, przy czasie dostępu rzędu 60-70ns. DDR3 nawet taktowane "zaledwie" w okolicach zegara CPU to nie dość, że 8 transferów w BURST to jeszcze DDR więc transfery na zboczach rosnących i opadających. I to przy zdecydowanie niższych timingach. Innymi słowy nie dość, że więcej danych to jeszcze zdecydowanie szybciej dostępne. I to ROBI ROBOTĘ, bo odciąża CACHE, którego ilość i struktura w FPGA jest mocno ograniczona. Czy w ASICu byłoby super? No kto pamięta Celeron Tualatin vs Pentium Tualatin? 256KB L2 z FSB 100MHz kontra 512KB L2 z FSB133? Właśnie... To samo tylko jeszcze bardziej spektakularne jest tym co bym się spodziewał po AC68080 sparowanym z DRAM z czasów 060. Im szybszy rdzeń tym więcej wymaga od pamięci. I nie, cache wszystkiego nie załatwi.
dzisiaj 02:01
[#30]
Re: Zbiórka na MMU dla Vampire v4
@abcdef, post #28
Byc moze te rejestry A0-A7 sa 64 bitowe, ale nie ma raczej na pewno instrukcji do ich obslugi typu:
lea (A0,D1.Q),A1
Byc moze, ze AMMX to jakos ogarnia, bo nie znam tych instrukcji.
Moze posrednio da sie takie adresowanie zrobic:
move.q #123456789,D0
move.q D0,A0
Ale na pewno Gunnar pisal, ze jesli chodzi o pamiec to 4 GB jest max.
BTW. 4k Euro zostalo osiagniete.
Ostatnia aktualizacja: 26.08.2025 02:03:50 przez Don_Adan
lea (A0,D1.Q),A1
Byc moze, ze AMMX to jakos ogarnia, bo nie znam tych instrukcji.
Moze posrednio da sie takie adresowanie zrobic:
move.q #123456789,D0
move.q D0,A0
Ale na pewno Gunnar pisal, ze jesli chodzi o pamiec to 4 GB jest max.
BTW. 4k Euro zostalo osiagniete.
Ostatnia aktualizacja: 26.08.2025 02:03:50 przez Don_Adan