13.09.2014 21:20
[#181]
Re: Turbo do A3/4000
@sanjyuubi, post #180
Pod to rozwiązanie też trzeba zrobić przeróbki.
Ciekawi mnie też czy nie będzie problemu z szybkością procesora i szybkością złącza ( tak jak np. w twoim turbo ). Ktoś coś wie? Trzeba "zwalniać" procesor powyżej jakiejś prędkości gdy odwołuje się do zasobów amigi przez złącze?
Ostatnia aktualizacja: 13.09.2014 21:21:33 przez bogumil
Ciekawi mnie też czy nie będzie problemu z szybkością procesora i szybkością złącza ( tak jak np. w twoim turbo ). Ktoś coś wie? Trzeba "zwalniać" procesor powyżej jakiejś prędkości gdy odwołuje się do zasobów amigi przez złącze?
Ostatnia aktualizacja: 13.09.2014 21:21:33 przez bogumil
13.09.2014 21:47
[#182]
Re: Turbo do A3/4000
@bogumil, post #181
Taka przeróbka jest prosta do zastosowania o ile DMA nie robi jakichś transferów odczytu z tego obszaru, jeśli puszczasz linie adresowe przez CPLD, to masz wtedy możliwość dowolnej manipulacji.
Ciężko mi odpowiedzieć, to zależy od specyfikacji tego slotu, jak się nakłada kartę na procesor jak w A600, to trzeba emulować cykl 68000 bo pod jego cykle jest zaprojektowana cała płyta główna. W A3k/4k z pewnością będzie to inaczej, procesor i tak będzie zwalniał odwołując się do powolnych elementów płyty głównej, ale czy będzie go do tego trzeba zmuszać, zależy od tego, czy slot, a właściwie chipset został zaprojektowany pod dany typ procesora, czy może jest elastyczny. Trzeba by zajrzeć do źródeł PALi A3640, czasami można tam znaleźć użyteczne komentarze. Przydałaby się jakaś rozpiska timingów tegoż slotu lub chociaż zrzut z analizatora logicznego.
Spoglądając w dokumentację Hayniego odnoszę wrażenie, że slot ten był projektowany głównie pod 030.
Ostatnia aktualizacja: 13.09.2014 21:56:29 przez sanjyuubi
Ciężko mi odpowiedzieć, to zależy od specyfikacji tego slotu, jak się nakłada kartę na procesor jak w A600, to trzeba emulować cykl 68000 bo pod jego cykle jest zaprojektowana cała płyta główna. W A3k/4k z pewnością będzie to inaczej, procesor i tak będzie zwalniał odwołując się do powolnych elementów płyty głównej, ale czy będzie go do tego trzeba zmuszać, zależy od tego, czy slot, a właściwie chipset został zaprojektowany pod dany typ procesora, czy może jest elastyczny. Trzeba by zajrzeć do źródeł PALi A3640, czasami można tam znaleźć użyteczne komentarze. Przydałaby się jakaś rozpiska timingów tegoż slotu lub chociaż zrzut z analizatora logicznego.
Spoglądając w dokumentację Hayniego odnoszę wrażenie, że slot ten był projektowany głównie pod 030.
Ostatnia aktualizacja: 13.09.2014 21:56:29 przez sanjyuubi
14.09.2014 16:44
[#184]
Re: Turbo do A3/4000
@sanjyuubi, post #179
A po co jest ten projekt jak nie po to, zeby sie czegos nauczyc?
No chyba, ze ma trafic do Muzeum Techniki jako eksponat.
To, ze RAM bedzie czekal na CPU jest zdaje sie lepsze niz odwrotna sytuacja, rezerwa (nawet spora) nigdy nie zaszkodzi, taka informacja byla zdaje sie na EAB. Jak ktos bedzie chcial podlaczyc 68060 133/150/200 MHz to mu zadziala. Zdaje sie, ze Strim nie chcial uzywac jakis czesci bo juz nie byly produkowane, tu najprawdopodobniej bedzie tak samo. Mozna uzyc DDR2 zamiast DDR3, tylko ze to sie po prostu nie oplaca. bo DDR3 jest tanszy, co wyjasnial Gunnar dlaczego wybrali DDR3 a nie DDR2, do tego turbo z Apollo core. Tu jest ten modul ze 128 MB pamieci DDR3, co go uzywaja:
http://parts.arrow.com/item/detail/arrow-development-tools/bemicrocv#Rncc
kosztuje 49 USD i o ile dobrze rozumiem to zadne dodatkowe FPGA nie jest do niego potrzebne, bo ma wlasne, no ale moge sie mylic, bo nie znam angielskiego.
Yaqube pokazal, ze sie da uzyc DDR2 do 680x0, wiec nie widze powodu, zeby nie uzyc DDR3.
Mozna sie pewnie Yaqube'a zapytac jak rozwiazal problem debugowania tak szybkiej pamieci.
A to ze to jest trudniejsze niz tamten SDRAM to juz inna sprawa, ale bawienie sie drobnica nie ma nanjmniejszego sensu dla mnie, bo koszty raczej na pewno sa wieksze a efekt raczej na pewno bedzie gorszy.
No chyba, ze ma trafic do Muzeum Techniki jako eksponat.
To, ze RAM bedzie czekal na CPU jest zdaje sie lepsze niz odwrotna sytuacja, rezerwa (nawet spora) nigdy nie zaszkodzi, taka informacja byla zdaje sie na EAB. Jak ktos bedzie chcial podlaczyc 68060 133/150/200 MHz to mu zadziala. Zdaje sie, ze Strim nie chcial uzywac jakis czesci bo juz nie byly produkowane, tu najprawdopodobniej bedzie tak samo. Mozna uzyc DDR2 zamiast DDR3, tylko ze to sie po prostu nie oplaca. bo DDR3 jest tanszy, co wyjasnial Gunnar dlaczego wybrali DDR3 a nie DDR2, do tego turbo z Apollo core. Tu jest ten modul ze 128 MB pamieci DDR3, co go uzywaja:
http://parts.arrow.com/item/detail/arrow-development-tools/bemicrocv#Rncc
kosztuje 49 USD i o ile dobrze rozumiem to zadne dodatkowe FPGA nie jest do niego potrzebne, bo ma wlasne, no ale moge sie mylic, bo nie znam angielskiego.
Yaqube pokazal, ze sie da uzyc DDR2 do 680x0, wiec nie widze powodu, zeby nie uzyc DDR3.
Mozna sie pewnie Yaqube'a zapytac jak rozwiazal problem debugowania tak szybkiej pamieci.
A to ze to jest trudniejsze niz tamten SDRAM to juz inna sprawa, ale bawienie sie drobnica nie ma nanjmniejszego sensu dla mnie, bo koszty raczej na pewno sa wieksze a efekt raczej na pewno bedzie gorszy.
14.09.2014 18:57
[#185]
Re: Turbo do A3/4000
@Don_Adan, post #184
Jak ktos bedzie chcial podlaczyc 68060 133/150/200 MHz to mu zadziala.
Nic tak samo z siebie nie zadziała bo szyna 68060 wygląda zupełnie inaczej niż szyna 68030.
Zdaje sie, ze Strim nie chcial uzywac jakis czesci bo juz nie byly produkowane, tu najprawdopodobniej bedzie tak samo.
Nie wygląda na to, żeby układy SRAMy miały wyjść z produkcji w najbliższej przyszłości
. Te których tutaj używamy bodajże od 2012 są produkowane. Ale nie o to tu chodzi.Yaqube pokazal, ze sie da uzyc DDR2 do 680x0, wiec nie widze powodu, zeby nie uzyc DDR3.
Powód jest prozaiczny: rzucanie się na głęboką wodę nie ma sensu, gdyż jest duża szansa utonięcia. Ja przynajmniej zdaje sobie sprawę ze swojej niewiedzy i braku doświadczenia. Biorąc pod uwagę ciągły brak czasu zarówno mój jak i Jarka, trzeba działać metodą małych kroków. Aby to przedsięwzięcie miało szanse powodzenia, trzeba zacząć od projektu, który jest PROSTY (co podkreślam od samego początku tego wątku) i stopniowo dodawać do niego bardziej zaawansowane elementy.
Jak napisałem wcześniej obecna specyfikacja karty nie jest finalna. To jest na razie specyfikacja pierwszego prototypu, który (mam nadzieję) pozwoli mi i Jarkowi zrozumieć jak dokładnie działa złącze local bus oraz szyna 68030. Bez tej wiedzy nawet nie ma co marzyć o podłączeniu innego procesora.
Mozna sie pewnie Yaqube'a zapytac jak rozwiazal problem debugowania tak szybkiej pamieci.
Jakub zajmuje się takimi rzeczami zawodowo, ja jestem amatorem. Z pewnością zapytam go gdy będę miał jakieś konkretne pytania (tak się składa, że kilka razy już się spotkaliśmy pogadać).
koszty raczej na pewno sa wieksze a efekt raczej na pewno bedzie gorszy
To zależy czego? Nowoczesne SDRAMy są produkowane, pewnie będą przez najbliższych kilka lat. Ich ceny ciągle maleją. Koszt CPLD w którym można zaimplementować kontroler SDRAM jest pomijalny (przeciwnie do ceny FPGA do DDR2/3). Pewnie dlatego Jens stosuje we wszystkich swoich nowych kartach SDRAMy.
14.09.2014 22:11
[#186]
Re: Turbo do A3/4000
@Don_Adan, post #184
A po co jest ten projekt jak nie po to, zeby sie czegos nauczyc?
Właśnie chcemy dowiedzieć się jak działa złącze karty procesorowej.
Najlepiej zacząć od prostych rzeczy jak sam procesor, potem pamięć, potem...
Będą problemy i dlatego trzeba zacząć od prostych rzeczy.
Nie DDR3, nie 68060 200MHz, nie FPGA z poziomem napięć innych niż 5V.
Zobacz że dopiero początek a już są pewne błędy w schemacie, dyskusja i pewnie konieczność skierowania _AS i _DS przez CPLD, czego nie ma w obecnej wersji.
To dopiero początek i podstawy a Ty chcesz STRIMa zniechęcić?
Powoli uparcie do przodu.
I zawsze siły na zamiary.
14.09.2014 22:30
[#187]
Re: Turbo do A3/4000
@Don_Adan, post #184
No to czemu nie pójść na całość i wziąć GDDR5, Intel Core i7, CPLD i zaemulować programowo 060, wydajność z pewnością lepsza niż najszybsza 68060.
Ale... trzeba liczyć siły na zamiary. Każesz strimowi, który opanował najprostszą w obsłudze pamięć SRAM, która nie ma odświeżania, nie potrzebuje inicjalizacji, a jej obsługa może być na wykładana na pierwszej lekcji technikum elektronicznego, rzucić się na głęboką wodę. W przeciwieństwie do Gunnara, strim ma za sobą tylko praktykę programisty i babranie się w sprzęcie bez pewnego zasobu wiedzy, to nie to samo, co bawienie się wirtualnie w optymalizację bibliotek AOS, tutaj najmniejszy błąd może kosztować wywalenie wszystkiego związanego z prototypem i rozpoczęciem prac od nowa, o ile pisanie/debugowanie programu nie kosztuje nic prócz straconego czasu, tutaj do śmieci mogą pójść duże pieniądze. Możesz narzekać i złościć ile chcesz, ale każdy z nas wie ile potrafi, a poświęcając szczątkowe ilości wolnego czasu na hobby, nikt nie będzie się mieszał w projekt, który mógłby ciągnąć się latami. Póki co jedyną aktywność przejawił tutaj programista, nie zgłosił się żaden spec od sprzętu i HDL'a do pomocy, więc nie oczekuj cudów.
W FPGA można zaimplementować analizator stanów logicznych (chipscope), w ten sposób się to debuguje. Do pomiarów zewnętrznych potrzebny jest oscyloskop (za używany 60MHz zapłaciłem 1300zł). Kiedyś się pytałem teoretycznie Yaqube o uruchomienie 68040 na 28MHz w A600 i mówił, że przydałby się do tego dobry oscyloskop.
Dodatkowo w przypadku takich zegarów jak w przypadku DDR3, czyli dajmy na to 533MHz, na bank muszą być brane zjawiska falowe przy projektowaniu płytki, więc trzeba mieć o tym jakieś pojęcie, ja nie mam, strim pewnie też. Yaqube kiedyś mi wymieniał nazwę programu do symulacji takich zjawisk, jednak jego dostępność na "czarnym rynku" była praktycznie zerowa, wiec należałoby go kupić, ceny to nawet nie śmiem sobie wyobrażać. To wszystko nie byłoby problemem, gdyby zgłosił się doświadczony projektant, który takimi narzędziami dysponuje, na razie się nie zgłosił, więc i szału nie ma.
SDRAM można taktować na 66MHz (nie wiem, czy można mniej), jest ich pełno w starych kościach i na pewno są łatwiejsze w obsłudze.
Ostatnia aktualizacja: 14.09.2014 22:43:38 przez sanjyuubi
Ale... trzeba liczyć siły na zamiary. Każesz strimowi, który opanował najprostszą w obsłudze pamięć SRAM, która nie ma odświeżania, nie potrzebuje inicjalizacji, a jej obsługa może być na wykładana na pierwszej lekcji technikum elektronicznego, rzucić się na głęboką wodę. W przeciwieństwie do Gunnara, strim ma za sobą tylko praktykę programisty i babranie się w sprzęcie bez pewnego zasobu wiedzy, to nie to samo, co bawienie się wirtualnie w optymalizację bibliotek AOS, tutaj najmniejszy błąd może kosztować wywalenie wszystkiego związanego z prototypem i rozpoczęciem prac od nowa, o ile pisanie/debugowanie programu nie kosztuje nic prócz straconego czasu, tutaj do śmieci mogą pójść duże pieniądze. Możesz narzekać i złościć ile chcesz, ale każdy z nas wie ile potrafi, a poświęcając szczątkowe ilości wolnego czasu na hobby, nikt nie będzie się mieszał w projekt, który mógłby ciągnąć się latami. Póki co jedyną aktywność przejawił tutaj programista, nie zgłosił się żaden spec od sprzętu i HDL'a do pomocy, więc nie oczekuj cudów.
W FPGA można zaimplementować analizator stanów logicznych (chipscope), w ten sposób się to debuguje. Do pomiarów zewnętrznych potrzebny jest oscyloskop (za używany 60MHz zapłaciłem 1300zł). Kiedyś się pytałem teoretycznie Yaqube o uruchomienie 68040 na 28MHz w A600 i mówił, że przydałby się do tego dobry oscyloskop.
Dodatkowo w przypadku takich zegarów jak w przypadku DDR3, czyli dajmy na to 533MHz, na bank muszą być brane zjawiska falowe przy projektowaniu płytki, więc trzeba mieć o tym jakieś pojęcie, ja nie mam, strim pewnie też. Yaqube kiedyś mi wymieniał nazwę programu do symulacji takich zjawisk, jednak jego dostępność na "czarnym rynku" była praktycznie zerowa, wiec należałoby go kupić, ceny to nawet nie śmiem sobie wyobrażać. To wszystko nie byłoby problemem, gdyby zgłosił się doświadczony projektant, który takimi narzędziami dysponuje, na razie się nie zgłosił, więc i szału nie ma.
SDRAM można taktować na 66MHz (nie wiem, czy można mniej), jest ich pełno w starych kościach i na pewno są łatwiejsze w obsłudze.
Ostatnia aktualizacja: 14.09.2014 22:43:38 przez sanjyuubi
15.09.2014 01:18
[#188]
Re: Turbo do A3/4000
@strim_, post #185
OK. To ucz sie od mistrza Jakuba, tak zebys w miare szybko przeszedl na poziom DDR3 :)
Jak juz osiagniesz ten poziom to wtedy mysle, ze bedziesz w stanie poprawic to,
co schrzanili inzynierowie Motoroli w MC68060. Konkretnie ja uwazam, ze da sie
zrobic taki kontroler pamieci w FPGA np. za pomoca ukladu do ktorego link podalem, ktory
oprocz tego, ze bedzie obslugiwal 512MB DDR3, bedzie tez przechwytywal wszystkie
instrukcje 68040 i 68882, ktore nie zmiescily sie w wykastrowanej MC68060,
i wykonywal je za pomoca np. mikro kodu. Czyli nie bedzie wtedy zadnej zewnetrznej
emulacji niezaimplementowanych instrukcji. Wedlug mnie to rozwiazanie pozwoli
na duzy przyrost szybkosci 68060 dla programow, ktore uzywaja takich instrukcji,
no i w koncu, wtedy to bedzie rzeczywiscie full MC68060, jak razem z tym kontrolerem
pamieci bedzie obslugiwala wszystkie instrukcje 68040 i 68882. Mysle, ze to jest
do zrobienia bo ten uklad ma relatywnie duzo LE, a szkoda zeby sie one marnowaly,
czyli trzeba z nich zrobic taka proteze dla 68060. No i ta metoda wydaje mi sie bardziej
sensowna i szybsza niz tworzenie procesora od podstaw, tak jak to robi Gunnar z Apollo
core, gdyz Apollo ma ciagle za duzo brakow, jesli chodzi o obslugiwane instrukcje
68040, no i na razie ciagle jest bez instrukcji FPU i MMU.
Jak juz osiagniesz ten poziom to wtedy mysle, ze bedziesz w stanie poprawic to,
co schrzanili inzynierowie Motoroli w MC68060. Konkretnie ja uwazam, ze da sie
zrobic taki kontroler pamieci w FPGA np. za pomoca ukladu do ktorego link podalem, ktory
oprocz tego, ze bedzie obslugiwal 512MB DDR3, bedzie tez przechwytywal wszystkie
instrukcje 68040 i 68882, ktore nie zmiescily sie w wykastrowanej MC68060,
i wykonywal je za pomoca np. mikro kodu. Czyli nie bedzie wtedy zadnej zewnetrznej
emulacji niezaimplementowanych instrukcji. Wedlug mnie to rozwiazanie pozwoli
na duzy przyrost szybkosci 68060 dla programow, ktore uzywaja takich instrukcji,
no i w koncu, wtedy to bedzie rzeczywiscie full MC68060, jak razem z tym kontrolerem
pamieci bedzie obslugiwala wszystkie instrukcje 68040 i 68882. Mysle, ze to jest
do zrobienia bo ten uklad ma relatywnie duzo LE, a szkoda zeby sie one marnowaly,
czyli trzeba z nich zrobic taka proteze dla 68060. No i ta metoda wydaje mi sie bardziej
sensowna i szybsza niz tworzenie procesora od podstaw, tak jak to robi Gunnar z Apollo
core, gdyz Apollo ma ciagle za duzo brakow, jesli chodzi o obslugiwane instrukcje
68040, no i na razie ciagle jest bez instrukcji FPU i MMU.
15.09.2014 09:43
[#189]
Re: Turbo do A3/4000
@Don_Adan, post #188
To nie jest takie proste, Jakub siedzi w tym zawodowo, a ja się elektroniką nie zajmuję w pracy.
Masz rację, ten devkit mógłby być pomocny, jeśli ktoś zdecydowałby się go ogarnąć.
Natomiast jeśli chodzi o protezę nieobsługiwanych instrukcji, to byłoby to chyba bardziej problematyczne niż nowy procesor, trzeba by wyłączyć tryb burst instrukcji dla 68060, albo podstawiać w miejsce nieobsługiwanych instrukcji jakieś NOPy lub instrukcje skoku, ponieważ jak proteza zacznie wykonywać instrukcje, to nastąpi rozbieżność pod względem licznika programu, po drugie, na czym taka proteza miałaby wykonywać te instrukcje jeśli nie miałaby dostępu do rejestrów procesora, musiałbyś programowo wpisywać te dane do FPGA, albo implementować w FPGA śledzenie instrukcji ładowania danych do rejestru i wykonywania na nich działań tak jak robi to 68060 aby nie doszło do rozbieżności, w efekcie końcowym otrzymasz procesor w FPGA, który symuluje obsługiwane instrukcje i wykonuje te nieobsługiwane, prawie cały procesor.
Czy czasem 68070 od Natami Team nie miał być właśnie takim cukierkowym procesorem z całą kupą instrukcji?
Ostatnia aktualizacja: 15.09.2014 09:44:22 przez sanjyuubi
Masz rację, ten devkit mógłby być pomocny, jeśli ktoś zdecydowałby się go ogarnąć.
Natomiast jeśli chodzi o protezę nieobsługiwanych instrukcji, to byłoby to chyba bardziej problematyczne niż nowy procesor, trzeba by wyłączyć tryb burst instrukcji dla 68060, albo podstawiać w miejsce nieobsługiwanych instrukcji jakieś NOPy lub instrukcje skoku, ponieważ jak proteza zacznie wykonywać instrukcje, to nastąpi rozbieżność pod względem licznika programu, po drugie, na czym taka proteza miałaby wykonywać te instrukcje jeśli nie miałaby dostępu do rejestrów procesora, musiałbyś programowo wpisywać te dane do FPGA, albo implementować w FPGA śledzenie instrukcji ładowania danych do rejestru i wykonywania na nich działań tak jak robi to 68060 aby nie doszło do rozbieżności, w efekcie końcowym otrzymasz procesor w FPGA, który symuluje obsługiwane instrukcje i wykonuje te nieobsługiwane, prawie cały procesor.
Czy czasem 68070 od Natami Team nie miał być właśnie takim cukierkowym procesorem z całą kupą instrukcji?
Ostatnia aktualizacja: 15.09.2014 09:44:22 przez sanjyuubi
15.09.2014 11:48
[#190]
Re: Turbo do A3/4000
@sanjyuubi, post #189
Nie znam sie za dobrze na technicznym aspekcie procesorow, ale 68060 CPU generuje
stan wyjatkowy jak ma wykonac niezaimplementowana instrukcje, i cos takiego wedlug
mnie musi przechodzic przez kontroler pamieci i wtedy mozna by chyba bylo sprawdzic
co to za instrukcja i w zaleznosci od niej wykonac albo i nie (jakby to byl Illegal
czy podobna instrukcja) wewnetrzny mikrokod lub jakis inny sposob jej implementacji.
Wiem, ze Gunnar rozwazal taki sposob przy Apollo i instrukcjach ktorych w nim brak,
ze jest wywolywany trap a pozniej jakis wewnetrzny ROM (?) w FPGA taka instrukcje wykonuje.
Tylko, ze w przypadku calego procesora w FPGA to jest wedlug mnie bez sensu, bo lepiej
go tak stworzyc, zeby nie bylo takiej potrzeby. Ale te instrukcje podobno maja spowalniac
caly procesor, w co ja watpie, szczegolnie przy dobrej implementacji. No ale Gunnar walczy
o kazdy MHz, i z tego co widac to na razie ma jakies osiemdziesiac pare MHz dla
Cyclone II (ale bez wielu waznych instrukcji), byc moze dla Cyclone V to bedzie dwa
razy wiecej MHz.
Zdaje sie, ze kiedys gdzies czytalem, ze procesory Motoroli sa tak pomyslane,
zeby mogly sie pomiedzy soba komunikowac i chyba do osmiu na raz to jest
mozliwe. Wiec mysle, ze ciekawym (moze lepszym niz emulacja w FPGA) pomyslem
byloby tez podlaczenie szybkiej wersji 68882 do 68060. I tu sa dwie mozliwosci:
podlaczamy 68882 do 68060 w wersji LC/EC (np. 68060FE133) i wtedy wszystkie
instrukcje FPU sa wykonywane przez 68882. Druga opcja to podlaczenie 68882
do pelnego 68060 i wtedy tylko te instrukcje, ktorych jest brak w 68882 w wersji
68060 sa wykonywane przez ten zewnetrzny FPU. Druga opcja bylaby szybsza ze
wzgledu na mozliwa prace rownolegla FPU i CPU, dla wiekszosci instrukcji FPU.
Jesli cos takiego daloby sie zrobic to byc moze w gre moglaby wchodzic np.
taka kombinacja:
68060 (full) plus 68882 (dla niezaimplementowanych instrukcji FPU) plus
68040EC (dla niezaimplementowanych instrukcji CPU).
Byc moze da sie jeszcze MMU (MC68851 ?) w ten sposob podlaczyc, jakby jakis
szybki 68060 byl bez MMU. No i byc moze tez jakies DSP Motoroli da sie dolaczyc
jako bonus dla muzykow/sluchaczy.
No i jest jeszcze cos takiego jak MC68360, tylko ze nie wiem do czego ten
chip sluzy.
Ale zacznij od podstaw tak jak juz wczesniej pisales.
A co do 68070 to chyba to mial byc procesor klasy 68060, o ile dobrze
pamietam, no i chyba go przemianowali pozniej na Apollo core wlasnie. Zajrzyj
na strone Natami (znowu/juz dziala) tam powinny byc informacje o 68070.
stan wyjatkowy jak ma wykonac niezaimplementowana instrukcje, i cos takiego wedlug
mnie musi przechodzic przez kontroler pamieci i wtedy mozna by chyba bylo sprawdzic
co to za instrukcja i w zaleznosci od niej wykonac albo i nie (jakby to byl Illegal
czy podobna instrukcja) wewnetrzny mikrokod lub jakis inny sposob jej implementacji.
Wiem, ze Gunnar rozwazal taki sposob przy Apollo i instrukcjach ktorych w nim brak,
ze jest wywolywany trap a pozniej jakis wewnetrzny ROM (?) w FPGA taka instrukcje wykonuje.
Tylko, ze w przypadku calego procesora w FPGA to jest wedlug mnie bez sensu, bo lepiej
go tak stworzyc, zeby nie bylo takiej potrzeby. Ale te instrukcje podobno maja spowalniac
caly procesor, w co ja watpie, szczegolnie przy dobrej implementacji. No ale Gunnar walczy
o kazdy MHz, i z tego co widac to na razie ma jakies osiemdziesiac pare MHz dla
Cyclone II (ale bez wielu waznych instrukcji), byc moze dla Cyclone V to bedzie dwa
razy wiecej MHz.
Zdaje sie, ze kiedys gdzies czytalem, ze procesory Motoroli sa tak pomyslane,
zeby mogly sie pomiedzy soba komunikowac i chyba do osmiu na raz to jest
mozliwe. Wiec mysle, ze ciekawym (moze lepszym niz emulacja w FPGA) pomyslem
byloby tez podlaczenie szybkiej wersji 68882 do 68060. I tu sa dwie mozliwosci:
podlaczamy 68882 do 68060 w wersji LC/EC (np. 68060FE133) i wtedy wszystkie
instrukcje FPU sa wykonywane przez 68882. Druga opcja to podlaczenie 68882
do pelnego 68060 i wtedy tylko te instrukcje, ktorych jest brak w 68882 w wersji
68060 sa wykonywane przez ten zewnetrzny FPU. Druga opcja bylaby szybsza ze
wzgledu na mozliwa prace rownolegla FPU i CPU, dla wiekszosci instrukcji FPU.
Jesli cos takiego daloby sie zrobic to byc moze w gre moglaby wchodzic np.
taka kombinacja:
68060 (full) plus 68882 (dla niezaimplementowanych instrukcji FPU) plus
68040EC (dla niezaimplementowanych instrukcji CPU).
Byc moze da sie jeszcze MMU (MC68851 ?) w ten sposob podlaczyc, jakby jakis
szybki 68060 byl bez MMU. No i byc moze tez jakies DSP Motoroli da sie dolaczyc
jako bonus dla muzykow/sluchaczy.
No i jest jeszcze cos takiego jak MC68360, tylko ze nie wiem do czego ten
chip sluzy.
Ale zacznij od podstaw tak jak juz wczesniej pisales.
A co do 68070 to chyba to mial byc procesor klasy 68060, o ile dobrze
pamietam, no i chyba go przemianowali pozniej na Apollo core wlasnie. Zajrzyj
na strone Natami (znowu/juz dziala) tam powinny byc informacje o 68070.
15.09.2014 14:55
[#191]
Re: Turbo do A3/4000
@Don_Adan, post #190
A teraz poważnie.
Zajrzyj
na strone Natami (znowu/juz dziala) tam powinny byc informacje o 68070.
Mam wrażenie, że dawno już zajrzał pan do ktorego to kierujesz i zapewne wielu innych. Wniosków z tego co sie stało z tym 070 Natami chyba już nie trzeba dodawać.
Z drugiej strony fajnie to wymodziłeś, możesz taki prototyp zrobić? Bo jak nie możesz tylko tylko tak piszesz bo klawiatura wszystko przyjmie to jakoś słabo. Na pewno dałoby się więcej w tym temacie wymyślić, dajmy na to: 060 full dla systemu plus 060 full by zbierał informacje do kupy i pchał dalej z tego 040EC i 882, coś jeszcze pominąłem? Normalnie taki Cell M68k
A, no i jeszcze tam PPC można dodać po drodze, by szybciej zbierało informacje z 040 i 882 i przekazywalo je do 060 pierwszego by ten tłumaczył z powrotem na assembler 68k i podawał do drugiego 060 tego co już by wszystkimi rządził (Władca Pierścieni or something ; ) ). 15.09.2014 15:40
[#192]
Re: Turbo do A3/4000
@Don_Adan, post #190
Jak chłopaki się ostro poświęcą temu zadaniu, to już za 10lat będziemy mieć super karty turbo, a w międzyczasie obronią doktorat, habilitację i pewnie dostaną profesurę od Prezydenta R.P. z elektroniki i techniki cyfrowej 
Sorry, ale takie propozycje to gruba przesada, trzeba mierzyć siły na zamiary. Bodźmy poważni. Marzenia są spoko, ale bez przesady z ich publikowaniem.
Ostatnia aktualizacja: 15.09.2014 15:41:20 przez flops
Sorry, ale takie propozycje to gruba przesada, trzeba mierzyć siły na zamiary. Bodźmy poważni. Marzenia są spoko, ale bez przesady z ich publikowaniem.
Ostatnia aktualizacja: 15.09.2014 15:41:20 przez flops
15.09.2014 19:29
[#193]
Re: Turbo do A3/4000
@Spoony, post #191
Nie musisz sie dzielic wiedza w dziedzinie w ktorej jak widze masz mniejsza
wiedze niz ja, a ja mam niewielka, bo elektronika to nie moja dzialka.
Ale od podawania blednych/niesprawdzonych informacji jest inny dzial albo inne forum.
Co sie stalo z 68070/Natami -> Phoenix/Apollo core.
Istnieje malo znany specjalizowany system operacyjny dzialajacy na dwoch 68060,
czyli da sie polaczyc dwie (!) MC68060 tak zeby ze soba wspolpracowaly pod tym OS.
Na Amidze to nie ma wiekszego sensu, bo trzeba by system operacyjny przerobic,
zeby mogl korzystac z dwoch procesorow 68k. Na pewno da sie podlaczyc zewnetrzny
MC68882 do MC68060, a ze nikt tego raczej wczesniej nie robil to inna sprawa.
W prototypie karty turbo wystarczy uwzglednic miejsce na FPU, kto bedzie chcial
to sobie dokupi 68882 do tej karty. I tak prototyp jest dla 68030 wiec powinien
uwzgledniac miejsce na koprocesor, a ze ten sam koprocesor moze dzialac z 68060
to tylko plus.
Jak widze nalezysz do ludzi, ktorzy malo wiedza a duzo pisza.
No bo z Twojego tekstu jasno wynika, ze nie wiesz jak dziala koprocesor
dla procesorow 68k. To tyle z mojej strony, bo mi szkoda tracic czas na
edukacje. Mam ciekawsze rzeczy do robienia niz prowadzenie polemiki, ale
jakbys przypadkiem mial rzeczywiscie jakies ciekawe i realne propozycje
czy rozwiazania problemow w temacie karty turbo dla Amigi 3000/4000 to
wtedy sie odezwe, ale pamietaj CIEKAWE i REALNE.
wiedze niz ja, a ja mam niewielka, bo elektronika to nie moja dzialka.
Ale od podawania blednych/niesprawdzonych informacji jest inny dzial albo inne forum.
Co sie stalo z 68070/Natami -> Phoenix/Apollo core.
Istnieje malo znany specjalizowany system operacyjny dzialajacy na dwoch 68060,
czyli da sie polaczyc dwie (!) MC68060 tak zeby ze soba wspolpracowaly pod tym OS.
Na Amidze to nie ma wiekszego sensu, bo trzeba by system operacyjny przerobic,
zeby mogl korzystac z dwoch procesorow 68k. Na pewno da sie podlaczyc zewnetrzny
MC68882 do MC68060, a ze nikt tego raczej wczesniej nie robil to inna sprawa.
W prototypie karty turbo wystarczy uwzglednic miejsce na FPU, kto bedzie chcial
to sobie dokupi 68882 do tej karty. I tak prototyp jest dla 68030 wiec powinien
uwzgledniac miejsce na koprocesor, a ze ten sam koprocesor moze dzialac z 68060
to tylko plus.
Jak widze nalezysz do ludzi, ktorzy malo wiedza a duzo pisza.
No bo z Twojego tekstu jasno wynika, ze nie wiesz jak dziala koprocesor
dla procesorow 68k. To tyle z mojej strony, bo mi szkoda tracic czas na
edukacje. Mam ciekawsze rzeczy do robienia niz prowadzenie polemiki, ale
jakbys przypadkiem mial rzeczywiscie jakies ciekawe i realne propozycje
czy rozwiazania problemow w temacie karty turbo dla Amigi 3000/4000 to
wtedy sie odezwe, ale pamietaj CIEKAWE i REALNE.
15.09.2014 19:51
[#194]
Re: Turbo do A3/4000
@Don_Adan, post #193
Na pewno da sie podlaczyc zewnetrzny MC68882 do MC68060, a ze nikt tego raczej wczesniej nie robil to inna sprawa.
W prototypie karty turbo wystarczy uwzglednic miejsce na FPU, kto bedzie chcial
to sobie dokupi 68882 do tej karty.
Tak sobie czytam i się zastanawiam, 020 czy 030 po spotkaniu operacji zmienno przecinkowej wysyłały ją do kooprocesora lub wywalały błąd jeśli go nie było. Jak chcesz namówić 040 lub 060 aby zamiast użyć własnej wersji wewnętrznego kooprocesora wysyłały dane do zewnętrznego ?
Pozdrawiam
15.09.2014 20:32
[#195]
Re: Turbo do A3/4000
@Don_Adan, post #193
Istnieje malo znany specjalizowany system operacyjny dzialajacy na dwoch 68060,
czyli da sie polaczyc dwie (!) MC68060 tak zeby ze soba wspolpracowaly pod tym OS.
Pod którym OS i kto pisał/mówił, że się nie da?
Jak widze nalezysz do ludzi, ktorzy malo wiedza a duzo pisza.
No bo z Twojego tekstu jasno wynika, ze nie wiesz jak dziala koprocesor
dla procesorow 68k.
Nie ale wiem jak działa dla innych CPU. W 68k FPU działa inaczej? Czyli jak?
Mam ciekawsze rzeczy do robienia niz prowadzenie polemiki, ale
jakbys przypadkiem mial rzeczywiscie jakies ciekawe i realne propozycje
czy rozwiazania problemow w temacie karty turbo dla Amigi 3000/4000 to
wtedy sie odezwe, ale pamietaj CIEKAWE i REALNE.
No przyganiał kocioł garnkowi. Rozumiesz co to sarkazm i ironia, chyba nie bo na pewno też nie rozumiesz o jaki wielkim SF teraz piszesz. Zejdz na ziemie i dopiero możemy pogadać.
Ostatnia aktualizacja: 15.09.2014 20:39:02 przez Spoony
15.09.2014 23:03
[#196]
Re: Turbo do A3/4000
@Don_Adan, post #193
020 i 030 mają interfejs koprocesora, po podłączeniu koprocesora pojawiają się dodatkowe instrukcje, przez co programista nie musi się bawić w jego ręczną obsługę, sam kickstart nawet w przypadku 020, 030 sprawdza czy jest podłączony koprocesor (przez ten mechanizm błąkałem się po omacku, aż mi pomógł Yaqube deassemblując przyczynę wyjątku). W przypadku 040 kickstart nie sprawdza już czy jest podłączony koprocesor, nie wiem, czy 040 i 060 mają w ogóle taki interfejs dla zewnętrznego koprocesora jak 020 i 030, jeśli nie, to pozostaje obsługa ręczna.
040 został zaprojektowany jako procesor do pracy w trybie slave, nie ma więc żadnych przeciwskazań, aby stworzyć system wieloprocesorowy na 040/060. Pod pojęciem "komunikują się ze sobą" nie koniecznie musi stać jakaś skomplikowana idea, a jedynie mechanizm umożliwiający współistnienie kilku procesorów na jednej szynie. Taki system oczywiście trzeba oprogramować.
Tylko, jeżeli się nie mylę, to instrukcje wykonuje się na rejestrach procesora, a taka proteza w fpga jak nie będzie miała dostępu do zawartości rejestrów, to nic nie zrobi. W przypadku procesora w FPGA masz dostęp do każdego fizycznego podłączenia procesora, więc zrobienie apollo core i protezy, która ma w każdym momencie dostęp do zawartości rejestrów jest banalne w porównaniu do fpga i fizycznego 68060. A tak w ogóle, to dlaczego robić protezę obsługującą nieobsługiwaną instrukcję, a nie umieścić ich obsługi w rdzeniu? To przerost formy nad treścią i trzeba ją oprogramować, lepiej gdyby takie działania odbywały się natywnie, niż poprzez wywoływanie wyjątków. Istnieje natomiast inny sposób, można umieścić w jakiejś przestrzeni adresowej FPGA i zapisywać do niego nieobsługiwaną instrukcję, a w następnym cyklu odczytywać wynik, ewentualnie zrobić prosty procesor matematyczny do instrukcji mnożenia i dzielenia.
Ostatnia aktualizacja: 15.09.2014 23:04:52 przez sanjyuubi
040 został zaprojektowany jako procesor do pracy w trybie slave, nie ma więc żadnych przeciwskazań, aby stworzyć system wieloprocesorowy na 040/060. Pod pojęciem "komunikują się ze sobą" nie koniecznie musi stać jakaś skomplikowana idea, a jedynie mechanizm umożliwiający współistnienie kilku procesorów na jednej szynie. Taki system oczywiście trzeba oprogramować.
i cos takiego wedlug mnie musi przechodzic przez kontroler pamieci i wtedy mozna by chyba bylo sprawdzic co to za instrukcja i w zaleznosci od niej wykonac albo i nie (jakby to byl Illegal czy podobna instrukcja) wewnetrzny mikrokod lub jakis inny sposob jej implementacji. Wiem, ze Gunnar rozwazal taki sposob przy Apollo i instrukcjach ktorych w nim brak, ze jest wywolywany trap a pozniej jakis wewnetrzny ROM (?) w FPGA taka instrukcje wykonuje
Tylko, jeżeli się nie mylę, to instrukcje wykonuje się na rejestrach procesora, a taka proteza w fpga jak nie będzie miała dostępu do zawartości rejestrów, to nic nie zrobi. W przypadku procesora w FPGA masz dostęp do każdego fizycznego podłączenia procesora, więc zrobienie apollo core i protezy, która ma w każdym momencie dostęp do zawartości rejestrów jest banalne w porównaniu do fpga i fizycznego 68060. A tak w ogóle, to dlaczego robić protezę obsługującą nieobsługiwaną instrukcję, a nie umieścić ich obsługi w rdzeniu? To przerost formy nad treścią i trzeba ją oprogramować, lepiej gdyby takie działania odbywały się natywnie, niż poprzez wywoływanie wyjątków. Istnieje natomiast inny sposób, można umieścić w jakiejś przestrzeni adresowej FPGA i zapisywać do niego nieobsługiwaną instrukcję, a w następnym cyklu odczytywać wynik, ewentualnie zrobić prosty procesor matematyczny do instrukcji mnożenia i dzielenia.
Ostatnia aktualizacja: 15.09.2014 23:04:52 przez sanjyuubi
15.09.2014 23:23
[#197]
Re: Turbo do A3/4000
@RadoslawF, post #194
Widze, ze nie zrozumiales mojego pomyslu.
Istnieja wersje 68060 EC i LC, dla tych wersji 68882 bedzie dzialal tak samo
jak w przypadku procesorow 68000/68010/68020/68030, bo te procesory nie maja
zintegrowanego FPU.
W przypadku pelnej (z FPU) wersji 68060, wszystkie instrukcje FPU ktore
sa zaimplementowane w wewnetrznym FPU sa przez ten wewnetrzny FPU wykonywane.
Te ktore nie sa zaimplementowane (trygonometryczne itp) wywoluja stan wyjatkowy.
Ten stan jest obslugiwany przez 68060.library, jak ta biblioteka nie jest
zaladowana to masz wtedy Software Failure. Czyli tylko te instrukcje, ktore
sa niezaimplementowane w wewnetrznym FPU beda korzystaly z zewnetrznego
koprocesora. Innej opcji tu byc nie moze, bo nie ma zadnego sensu. Bo nawet
jakby sie dalo przekierowac wszystkie instrukcje tylko do zewnetrzengeo FPU,
to bedzie to dzialac wolniej, gdyz wewnetrzny FPU moze dzialac rownolegle
z CPU, a zewnetrzny juz nie. Ale posiadanie drugiego/zewnetrznego FPU ma swoje
zalety, wszystkie programy ktore dzialaly na 68882 typu Lightwave beda dzialac
duzo szybciej na MC68060, gdyz nie bedzie emulacji niezaimplementowanych
instrukcji FPU przez 68060.library. Do tego taki FPU raczej kosztuje grosze,
wiec kto chce to go sobie zamontuje/kupi, kto nie ten bedzie mial wolna
emulacje niezaimplentowanych instrukcji FPU via 68060.library.
No i takie rozwiazanie daje mozliwosc uzyskania nowych efektow w demach
na Amige. Jak rowniez uzywanie duzo tanszych procesorow 68060 EC/LC na Amidze
bedzie mialo wtedy sens, choc oczywiscie szybkosc takiego konfigu w przypadku
programu/dema, ktore uzywa FPU bedzie raczej mniejsza niz w przypadku pelnej
wersji 68060 z dwoma (wewnetrznym i zewnetrznym) FPU. Choc np. taki konfig
jak MC68060FE 133MHz oraz MC68882 100MHz, moze byc naprawde bardzo szybki.
Na koniec jezeli rzeczywiscie waskim gardlem podkrecania pelnej 68060 jest
FPU (jak twierdzi SP) to majac zewnetrzny FPU, powinno sie dac osiagnac
np. dla CPU 68060LC 150 MHz i dla MC68882 100 MHz.
Istnieja wersje 68060 EC i LC, dla tych wersji 68882 bedzie dzialal tak samo
jak w przypadku procesorow 68000/68010/68020/68030, bo te procesory nie maja
zintegrowanego FPU.
W przypadku pelnej (z FPU) wersji 68060, wszystkie instrukcje FPU ktore
sa zaimplementowane w wewnetrznym FPU sa przez ten wewnetrzny FPU wykonywane.
Te ktore nie sa zaimplementowane (trygonometryczne itp) wywoluja stan wyjatkowy.
Ten stan jest obslugiwany przez 68060.library, jak ta biblioteka nie jest
zaladowana to masz wtedy Software Failure. Czyli tylko te instrukcje, ktore
sa niezaimplementowane w wewnetrznym FPU beda korzystaly z zewnetrznego
koprocesora. Innej opcji tu byc nie moze, bo nie ma zadnego sensu. Bo nawet
jakby sie dalo przekierowac wszystkie instrukcje tylko do zewnetrzengeo FPU,
to bedzie to dzialac wolniej, gdyz wewnetrzny FPU moze dzialac rownolegle
z CPU, a zewnetrzny juz nie. Ale posiadanie drugiego/zewnetrznego FPU ma swoje
zalety, wszystkie programy ktore dzialaly na 68882 typu Lightwave beda dzialac
duzo szybciej na MC68060, gdyz nie bedzie emulacji niezaimplementowanych
instrukcji FPU przez 68060.library. Do tego taki FPU raczej kosztuje grosze,
wiec kto chce to go sobie zamontuje/kupi, kto nie ten bedzie mial wolna
emulacje niezaimplentowanych instrukcji FPU via 68060.library.
No i takie rozwiazanie daje mozliwosc uzyskania nowych efektow w demach
na Amige. Jak rowniez uzywanie duzo tanszych procesorow 68060 EC/LC na Amidze
bedzie mialo wtedy sens, choc oczywiscie szybkosc takiego konfigu w przypadku
programu/dema, ktore uzywa FPU bedzie raczej mniejsza niz w przypadku pelnej
wersji 68060 z dwoma (wewnetrznym i zewnetrznym) FPU. Choc np. taki konfig
jak MC68060FE 133MHz oraz MC68882 100MHz, moze byc naprawde bardzo szybki.
Na koniec jezeli rzeczywiscie waskim gardlem podkrecania pelnej 68060 jest
FPU (jak twierdzi SP) to majac zewnetrzny FPU, powinno sie dac osiagnac
np. dla CPU 68060LC 150 MHz i dla MC68882 100 MHz.
15.09.2014 23:28
[#198]
Re: Turbo do A3/4000
@Don_Adan, post #197
Istnieja wersje 68060 EC i LC, dla tych wersji 68882 bedzie dzialal tak samo
jak w przypadku procesorow 68000/68010/68020/68030, bo te procesory nie maja
zintegrowanego FPU.
Tak myślę że musiały by mieć listę rozkazów taką jak 030 a z tego co wiem nie mają. No chyba że wiesz coś na temat innej listy rozkazów dla wersji EC i LC ? Wiesz ?
Pozdrawiam
16.09.2014 10:36
[#200]
Re: Turbo do A3/4000
@sanjyuubi, post #199
Ogólnie jeżeli nie chcecie stworzyć 68882 na FPGA, to nawet ta rozmowa za bardzo nie ma celu. 68882 w porównaniu do koprocesora z 68040 jest żółwiem, a co dopiero do 68060. Na 50MHz 68882 ma wydajność ~1.4MFLOPS, na 68040 około 8x tyle, na 68060 22x tyle przy tym samym zegarze. Operacje trygonometryczne na 68882 zajmują prawie 400 cykli (to jest masakrycznie dużo) i chyba dlatego Motorola je wyrzuciła, bo liczenie na 68040 i 68060 na piechotę w bibliotece jest szybsze (przynajmniej powinno, nigdy sam nie porównywałem). LightWave i inne programy namiętnie korzystające z koprocesora latają na 68040/68060, w porównaniu do powolnego 68882.
Co do takiego LC/EC jakby był 68882 w formie szybkiego FPGA to by była super sprawa, bo takich procesorów na rynku jest ogrom.
Co do takiego LC/EC jakby był 68882 w formie szybkiego FPGA to by była super sprawa, bo takich procesorów na rynku jest ogrom.
16.09.2014 11:09
[#202]
Re: Turbo do A3/4000
@Don_Adan, post #197
Skoro poruszacie temat wydajności Amigi to zapodaję taki ciekawy watek od przyjaciół z Atari. Dwa fragmenty.
I
I link do tematu --->
wszyscy macie rację
1) konwersja C2P oczywiście jest Kalmsa z Amigi ale zoptymalizowana pod Atari i finalnie jest szybsza ze względu na organizację pamięci ekranu - przeplatane bitplany.
2) wydajniejszą pamięć CT60. Czuba użył nowszej i zdecydowanie szybszej pamięci SDRAM niż w dopałkach do Amigi;
3) wydajniejszą pamięć Falcona, niby tylko 16bitowa szyna ale za to ponad dwa razy szybciej taktowana niż w A1200 (8Mhz vs 3,54MHz a tak naprawdę z punktu widzenia CPU to 4Mhz vs 1.77MHz).
I
Adam, w A1200, Falconie, TT i ST, CPU ma dostęp do pamięci co drugi cykl tej pamięci. Czyli ma tylko w parzyste dostępy, nieparzyste są za to dostępne dla układu graficznego. W przypadku A1200 i Falcona układ graficzny może podkradać również parzyste dostępy procesorowi.
- ST - pamięć taktowana jest 4MHz, CPU ma dostęp 2MHz 16bit;
- Falcon - pamięć taktowana jest 8MHz, CPU ma dostęp 4MHz 16bit;
- A1200 - pamięć taktowana jest 3,54MHz, CPU ma dostęp 1,7MHz 32bit;
- TT - pamięć taktowana jest 4MHz, CPU ma dostęp 2MHz lub 4MHz w przypadku trafienia w cache Funnel;
I link do tematu --->
16.09.2014 15:52
[#203]
Re: Turbo do A3/4000
@RadoslawF, post #198
O jaka liste rozkazow Ci chodzi?
O rozkazy FPU?
Sa dokladnie takie same zarowno dla 68882 zewnetrznego i wewnetrznego.
Tylko, ze wewnetrzny 68882 ma ich troche mniej, ale to tylko (albo glownie)
dlatego, ze inzynierowie Motoroli nie potrafili wszystkich upchnac w 68060,
bo zabraklo im miejsca, pomyslu albo umiejetnosci.
O rozkazy FPU?
Sa dokladnie takie same zarowno dla 68882 zewnetrznego i wewnetrznego.
Tylko, ze wewnetrzny 68882 ma ich troche mniej, ale to tylko (albo glownie)
dlatego, ze inzynierowie Motoroli nie potrafili wszystkich upchnac w 68060,
bo zabraklo im miejsca, pomyslu albo umiejetnosci.
16.09.2014 15:53
[#204]
Re: Turbo do A3/4000
@sanjyuubi, post #199
Jakby sie dalo obslugiwac zewnetrzny FPU bez pomocy wyjatkow to na pewno
bardzo by to przyspieszylo jego dzialanie. Ale nie wiem czy to jest mozliwe,
dlatego mnie zadowolilby sam opcjonalny zewnetrzny FPU. Ale byc moze jakas
kontrola nad icache jest mozliwa z poziomu kontrolera pamieci i przekierowanie
rozkazow FPU do zewnetrznego FPU.
A co do kickstartu to o ile mnie pamiec nie myli exec sprawdza czy jest
FPU w wersji pelnej i wtedy ustawia flagi FPU. Flagi FPU dla 68040/68060
sa ustawiane dopiero przez 68040/68060.library. Co jest nie najlepszym
rozwiazaniem, szczegolnie jak jakis modul ROM-u (np. mathieeesingbas.library)
ma opcjonalny kod dla FPU, bo sie inicjuje wtedy w wolniejszej wersji bez FPU.
A jesli chodzi o rozkazy CPU (glownie mnozenie/dzielenie 64 bitowe, ale nie
tylko) to wydaje mi sie, ze chyba jest jakis sposob na dostep do rejestrow
procesora. Na pewno w Action Replay-u jest taki dostep i mozna sobie
modyfikowac poszczegolne rejestry procesora. Podany chip ze 128 MB ma duzo LE,
wiec pewnie mozliwych opcji ich wykorzystania jest wiele. Ale jesli wiesz jak
umiescic niezaimplementowane instrukcje w rdzeniu procesora to nie mam
nic przeciwko.
bardzo by to przyspieszylo jego dzialanie. Ale nie wiem czy to jest mozliwe,
dlatego mnie zadowolilby sam opcjonalny zewnetrzny FPU. Ale byc moze jakas
kontrola nad icache jest mozliwa z poziomu kontrolera pamieci i przekierowanie
rozkazow FPU do zewnetrznego FPU.
A co do kickstartu to o ile mnie pamiec nie myli exec sprawdza czy jest
FPU w wersji pelnej i wtedy ustawia flagi FPU. Flagi FPU dla 68040/68060
sa ustawiane dopiero przez 68040/68060.library. Co jest nie najlepszym
rozwiazaniem, szczegolnie jak jakis modul ROM-u (np. mathieeesingbas.library)
ma opcjonalny kod dla FPU, bo sie inicjuje wtedy w wolniejszej wersji bez FPU.
A jesli chodzi o rozkazy CPU (glownie mnozenie/dzielenie 64 bitowe, ale nie
tylko) to wydaje mi sie, ze chyba jest jakis sposob na dostep do rejestrow
procesora. Na pewno w Action Replay-u jest taki dostep i mozna sobie
modyfikowac poszczegolne rejestry procesora. Podany chip ze 128 MB ma duzo LE,
wiec pewnie mozliwych opcji ich wykorzystania jest wiele. Ale jesli wiesz jak
umiescic niezaimplementowane instrukcje w rdzeniu procesora to nie mam
nic przeciwko.
16.09.2014 17:10
[#205]
Re: Turbo do A3/4000
@Don_Adan, post #204
Przerabialiśmy ten temat z mathieeesingbas.library :) z biblioteką 68060 Thora jest brak współpracy z Twoimi wersjami bibliotek matematycznych (jego biblioteka współpracuje tylko z oryginalnymi wersjami z rom3.1 albo zewnętrznymi odpowiednikami typu HSMathlibs które są napisane dla FPU i tak czy tak wymuszą jego użycie)
Może zrobisz wersję mathieeesingbas.library oraz mathffp tylko dla FPU żeby same załączały koprocesor? (podobnie jak są zrobione hsmathlibs) (dla użytkowników 040+)
Cosmosa wersja exec'a ma taką zmianę w changelogu:
- disable 060 fpu for the 040/060 adapter (SpeedGeek)
Cosmos odpisał że chodzi o to że: "For the A3640, the 060 fpu must be disable at boot because the exec support only 68040...
...060 fpu must be disable for internal exec 040 reasons...
After, the 68060.library enable the fpu..."
Ostatnia aktualizacja: 16.09.2014 17:14:23 przez Pawelek
Może zrobisz wersję mathieeesingbas.library oraz mathffp tylko dla FPU żeby same załączały koprocesor? (podobnie jak są zrobione hsmathlibs) (dla użytkowników 040+)
Cosmosa wersja exec'a ma taką zmianę w changelogu:
- disable 060 fpu for the 040/060 adapter (SpeedGeek)
Cosmos odpisał że chodzi o to że: "For the A3640, the 060 fpu must be disable at boot because the exec support only 68040...
...060 fpu must be disable for internal exec 040 reasons...
After, the 68060.library enable the fpu..."
Ostatnia aktualizacja: 16.09.2014 17:14:23 przez Pawelek
16.09.2014 17:49
[#206]
Re: Turbo do A3/4000
@Don_Adan, post #203
O jaka liste rozkazow Ci chodzi?
O rozkazy FPU?
Chodzi o rozkazy procesora, procesor 030 po napotkaniu działań zmiennoprzecinkowych szuka kooprocesora, 040 i 060 wysyłają dane do własnego wewnętrznego kooprocesora i nie bardzo rozumiem jak chcesz to zmienić, zaprojektujesz własny procesor 060 który będzie się zachowywał jak 030 w przypadku obliczeń zmiennoprzecinkowych ?
Pozdrawiam
16.09.2014 23:18
[#207]
Re: Turbo do A3/4000
@sanjyuubi, post #199
Jakie szybciej, jakich wyjątków?
Robiłeś kiedyś testy AIBB na 060 z włączonym FPU, albo pod ShapeShifterem, pod Macowym Norton SysInfo? Wewnętrzny FPU to najmocniejszy element tego procesora, absolutnie poza konkurencją w linii 68k.
Swoją drogą - mamy tu jeden z ciekawszych brednioseriali. Tym razem nie emocjonalny a pseudo-merytoryczny.
Ostatnia aktualizacja: 16.09.2014 23:19:44 przez Daclaw
Robiłeś kiedyś testy AIBB na 060 z włączonym FPU, albo pod ShapeShifterem, pod Macowym Norton SysInfo? Wewnętrzny FPU to najmocniejszy element tego procesora, absolutnie poza konkurencją w linii 68k.
Swoją drogą - mamy tu jeden z ciekawszych brednioseriali. Tym razem nie emocjonalny a pseudo-merytoryczny.
Ostatnia aktualizacja: 16.09.2014 23:19:44 przez Daclaw
17.09.2014 01:41
[#208]
Re: Turbo do A3/4000
@RadoslawF, post #206
Procesor Motoroli po natrafieniu na rozkaz FPU ($Fxxx) wykonuje go
jesli posiada wewnetrzny FPU, a jak nie posiada wewnetrznego FPU to
wywoluje stan wyjatkowy (wektor 11, adres VBR+$2C). Czyli 68030
wywoluje zawsze stan wyjatkowy. Po wywolaniu stanu wyjatkowego ten stan
moze byc obsluzony lub nie, jak nie jest obsluzony to jest Software
Failure albo Guru. Obsluga stanu wyjatkowego moze byc programowa
albo hardware'owa. Jak MC6888x jest podlaczony to wtedy jest to obsluga
hardware'owa, jak pod wektor jest podpiety program obslugujacy to wtedy
jest to obsluga software'owa. Na tej zasadzie dzialaja 68040/68060.library
oraz programowe emulatory FPU (np. Software FPU na MacOS). Z powodu
wywolywania stanu wyjatkowego zewnetrzne 68882 jest duzo wolniejsze
od wewnetrznego, dlatego jakby sie dalo obejsc stan wyjatkowy to
dzialanie zewnetrznego FPU byloby sporo szybsze. Choc ja nie sadze,
zeby to bylo mozliwe, choc moge sie mylic, bo nie jestem elektronikiem.
Ale przy bardzo szybkiej pamieci stan wyjatkowy powinien trwac krocej.
Wiec nie trzeba projektowac wlasnego procesora 68060 zeby zewnetrzne FPU
dzialalo. Tylko (?) trzeba je podlaczyc i stworzyc dobry kontroler pamieci.
jesli posiada wewnetrzny FPU, a jak nie posiada wewnetrznego FPU to
wywoluje stan wyjatkowy (wektor 11, adres VBR+$2C). Czyli 68030
wywoluje zawsze stan wyjatkowy. Po wywolaniu stanu wyjatkowego ten stan
moze byc obsluzony lub nie, jak nie jest obsluzony to jest Software
Failure albo Guru. Obsluga stanu wyjatkowego moze byc programowa
albo hardware'owa. Jak MC6888x jest podlaczony to wtedy jest to obsluga
hardware'owa, jak pod wektor jest podpiety program obslugujacy to wtedy
jest to obsluga software'owa. Na tej zasadzie dzialaja 68040/68060.library
oraz programowe emulatory FPU (np. Software FPU na MacOS). Z powodu
wywolywania stanu wyjatkowego zewnetrzne 68882 jest duzo wolniejsze
od wewnetrznego, dlatego jakby sie dalo obejsc stan wyjatkowy to
dzialanie zewnetrznego FPU byloby sporo szybsze. Choc ja nie sadze,
zeby to bylo mozliwe, choc moge sie mylic, bo nie jestem elektronikiem.
Ale przy bardzo szybkiej pamieci stan wyjatkowy powinien trwac krocej.
Wiec nie trzeba projektowac wlasnego procesora 68060 zeby zewnetrzne FPU
dzialalo. Tylko (?) trzeba je podlaczyc i stworzyc dobry kontroler pamieci.
17.09.2014 01:41
[#209]
Re: Turbo do A3/4000
@Daclaw, post #207
Moze to i brednio serial, ale Ty masz problem z rozumieniem napisanego
tekstu, bo jego caly tekst dotyczy procesora 68060 bez FPU, a nie procesora
68060 z wewnetrznym FPU. Wiec Twoje trafne uwagi zawyzaja poziom tego
merytorycznego watku, o przedrostek ktorego sam raczyles uzyc. Ale dzieki
za okazane zainteresowanie i wyrozumialosc, nie spodziewalem sie, ze bedzie
az tak wielkie zapotrzebowanie na karte turbo do Amigi A3000/A4000.
tekstu, bo jego caly tekst dotyczy procesora 68060 bez FPU, a nie procesora
68060 z wewnetrznym FPU. Wiec Twoje trafne uwagi zawyzaja poziom tego
merytorycznego watku, o przedrostek ktorego sam raczyles uzyc. Ale dzieki
za okazane zainteresowanie i wyrozumialosc, nie spodziewalem sie, ze bedzie
az tak wielkie zapotrzebowanie na karte turbo do Amigi A3000/A4000.