kategorie: A500, A600
[#61] Re: TF 536, MMU i stery video do SS

@san_u, post #60

Cały czas to tłumaczę tutaj ale nadal nie dociera do niektórych ;)

Mapowanie powolnego, 16-bitowego, ROMu do Fastu na TF kompletnie zmienia oblicze tej karty. I do tego jest potrzebny pełny 030 z MMU.
[#62] Re: TF 536, MMU i stery video do SS

@alt_, post #61

W oczach posiadaczy dużych Amig jak A4000, posiadacze A500,A600 to trzeci świat i można nie być świadom ich problemów :)

Szkoda, że karta nie ma sprzętowego mapromu, wtedy każda 030 by mogła na tym skorzystać.
[#63] Re: TF 536, MMU i stery video do SS

@san_u, post #62

posiadacze A500,A600 to trzeci świat


"Pan użył stwierdzenia, które ja panu powiem, że mnie ubodło”.

Szkoda, że karta nie ma sprzętowego mapromu,

Właśnie dlaczego sprzętowa funkcja MapRom jest tak niepopularna.
To takie trudne do zaimplementowania w nowych kartach? Jak to jest realizowane? Przez CPLD karty, aby odwołania do danych obszarów pamięci były przekierowane czy jak? Pytam z czystej ciekawości. Jak używałem karty ACA1233 na A1200 to fajne było wczytywanie ROMu z pliku. Chyba Wicher 500i ma funkcję MapRom, ale nie wiem jak ona tam dokładnie działa. Wiem, że CPLD nie są z gumy i nie wszystko da się zmieścić. Może chodzi o dodatkowe skomplikowanie karty i możliwe nieprzewidziane zachowanie z nietestowanym Romem?
[#64] Re: TF 536, MMU i stery video do SS

@alt_, post #61

A nie da się tego też zrobić komendą CPU? No chyba, że to wymaga MMU.

Patrzę teraz na Aminet i faktycznie nie widzę żadnego programu do kopiowani rom'u do fast'u który by nie wymagał mmu.
[#65] Re: TF 536, MMU i stery video do SS

@jimiche, post #64

Komenda CPU również wymaga MMU żeby zmapować ROM.

Tyle, że mmu.library robi to w bardziej elegancki sposób i zapewnia kompatybilność z innymi funkcjami w obrębie tego pakietu.
mmulib dostarcza też sterownik MuEVD do ShapeShiftera, który jest bardzo dobrą alternatywą dla Savage.
1
[#66] Re: TF 536, MMU i stery video do SS

@snifferman, post #63

Jak to jest realizowane? Przez CPLD karty, aby odwołania do danych obszarów pamięci były przekierowane czy jak?
W przypadku procesora bez MMU właśnie tak. Gdy układ CPLD wykryje dostęp do obszaru Kickstartu, zmienia fizyczny adres i odwołuje się do obszaru pamięci fast na karcie, do którego jest wgrany Kickstart.
3
[#67] Re: TF 536, MMU i stery video do SS

@jimiche, post #64

A taki Skick, Mkick daje rade
[#68] Re: TF 536, MMU i stery video do SS

@Norbert, post #67

Daje, ale on wymaga tablic relokacji - właśnie dlatego, że nie używa MMU musi spatchować obraz wgrywanego ROMu żeby pozmieniać w nim pewne odwołania do konkretnych zdefiniowanych na sztywno adresów. Poza tym tak załadowany kick nie jest niczym zabezpieczony w pamięci Amigi a to proszenie się o kłopoty jest.
[#69] Re: TF 536, MMU i stery video do SS

@snifferman, post #63

"Pan użył stwierdzenia, które ja panu powiem, że mnie ubodło”.


To tylko taka analogia typu "syty nie zrozumie głodnego", tylko bardziej mi podeszła różnica światów.


To takie trudne do zaimplementowania w nowych kartach?


Nie, ale trzeba zacząć projektowanie już z myślą o takiej funkcji (np. trzeba mieć więcej RAMu o ten 1MB dla klasycznych kart w Z2, w Z3 już nie). Problemem może być napisanie programiku do obsługi tej funkcji.

Czy ona jest tak niepopularna? Karty Jensa to mają, Furia to ma, nie wyobrażam sobie, żeby WARPy nie miały (chociażby ładowane automatycznie przez bootrom) i ja też to zawsze stosowałem. Tylko Lukzer i TF nie stosują, Lukzer mógł akurat nie wiedzieć wtedy jak to zrobić (np. od strony programowej), a TF po prostu chciał zrobić kartę, bo cytuję "lubi robić rzeczy", nie mieli też jakiegoś wielkiego nacisku, skoro można to uruchomić za pomocą MMU.

Ostatnia aktualizacja: 04.12.2023 13:17:13 przez san_u
[#70] Re: TF 536, MMU i stery video do SS

@alt_, post #68

Może ktoś by się pokusił o zrobienie testu Skick VS fastrom MMU, to powinno dać jakiś pogląd, ile MMU, jeśli faktycznie to robi, odbiera wydajności i w jakich przypadkach (może pełny test w AIBB coś pokaże).
[#71] Re: TF 536, MMU i stery video do SS

@san_u, post #70

Wypadałoby. W sumie jak się odgrzebię z gratów aktualnie na warsztacie to mógłbym machnąć taki test u siebie.
[#72] Re: TF 536, MMU i stery video do SS

@san_u, post #70

Tutaj jest ciekawy przyklad jak uzycie MMU spowalnia na 68060.

link
[#73] Re: TF 536, MMU i stery video do SS

@Don_Adan, post #72

Co nie znaczy że wszystko i zawsze spowolni. Poza tym uzysk na samym zmapowaniu ROMu może to przewyższyć w większości sytuacji.
[#74] Re: TF 536, MMU i stery video do SS

@Don_Adan, post #72

W pewnym sensie rozumiem teraz o co ci chodzi, choć nie wiedziałem, że jest jakiś cache translacji adresów i czy to znaczy, że MMU trzyma jakąś tablicę w pamięci?

Pewnie jest jakiś tam % spadku wydajności w programach przy MMU (należałoby to rzetelnie przetestować w jakim stopniu), ale sam WB odżywa po włączeniu fastromu na małych Amigach tak jakbyś włożył tam całkiem inną kartę. Z dwojga złego, do klikania w ikonki i lepsze transfery z dysku fastrom jest wręcz pożądany.

Ostatnia aktualizacja: 04.12.2023 23:05:48 przez san_u
[#75] Re: TF 536, MMU i stery video do SS

@san_u, post #74

Oczywiście że pożądany, tym bardziej że ta translacja nie następuje zawsze i cały czas - tylko czasem. I pewnie i tak jej wpływ jest mniejszy niż używanie 16-bitowego ROMu bezpośrednio...
[#76] Re: TF 536, MMU i stery video do SS

@san_u, post #74

Z tego co wiem to MMU uzywa tablic i to czasami bardzo duzych, ktos pisal na EAB, ze OS 3.1.4 lub OS 3.2 zzeral mu pare czy nawet parenascie MB fastu w systemie, ze 128MB dostepnych. A ten ktory testowal szybkosc dzialania to Blizzardzie to robil to dokladnie. Co do mapowania ROM-u to zdaje sie, ze uzywal MapROM-u. Oczywiscie on tez uzywal MMU, ale tylko wtedy kiedy potrzebowal.
[#77] Re: TF 536, MMU i stery video do SS

@san_u, post #74

Zainspirowany tą dyskusją postanowiłem wypróbować MapROM na karcie 68030TK (maprom jest programowy z użyciem dedykowanego programu). Ogólnie karta bez żadnych bibliotek MMU wymiata (w odróżnieniu od TF, które mocno kuleją bez tego), więc nie spodziewałem się cudów...
... ale rzeczywiście, pod WB teraz jest rakieta. Naprawdę śmiga. Teraz rzeczywiście czuć transfer IDE, bo wcześniej niby SysInfo podawało 9,5 MB/s, ale jakoś nie czuło się tego, ale teraz naprawdę wymiata. szeroki uśmiech

Ostatnia aktualizacja: 05.12.2023 01:41:03 przez wali7
2
[#78] Re: TF 536, MMU i stery video do SS

@Don_Adan, post #72

A tutaj kontynuacja. Wersja ze switchem NOMMU, okolo 50% szybsza jest.

link
[#79] Re: TF 536, MMU i stery video do SS

@RokiS, post #25

MuEVD nie testowałem jeszcze ale jutro albo po weekendzie coś tam się pobawię
Niedługo postaram się uzupełnić o kartę A630 z różnymi sterownikami graficznymi..

Trochę mi się zeszło bo najpierw dopadła mnie "przypadłość programistów" czyli choroba a potem padła mi karta w A600 i musiałem odbudować system ale udało się...
Wracając do rzeczy : u mnie na A600 najszybszy jest Savage 030 . Nie lubi się on z MMULib, ma własny plik do przerzucania kickstartu do Fastu ale warty jest swojej ceny . MuEVD jest prawie tak powolny jak sterownik wideo wbudowany w Shapeshiftera (osiąga 0.15)...


Od MuEVD szybszy jest FastECS


i sterowniki wbudowane w Fusion-ie


a TUTAJ LINK do plikopartycji z programem testujacym i wynikami testów

Ostatnia aktualizacja: 17.12.2023 20:34:48 przez RokiS
3
[#80] Re: TF 536, MMU i stery video do SS

@RokiS, post #79

Fusion ma bardzo dobre sterowniki.
[#81] Re: TF 536, MMU i stery video do SS

@michal_zukowski, post #80

Zgadza się, Fusion na dobre sterowniki wideo.
Trochę zawiodłem się na wydajności MuEVD (u mnie na A600).
Na TF360 w sumie nie było różnicy między Savage a MuEVD.
Na pewno jeszcze powalczę z MuEVD - może coś przeoczyłem... coś źle robię... .
[#82] Re: TF 536, MMU i stery video do SS

@RokiS, post #81

a MapROM włączony podczas testowania? Zrób testy z i bez MapROM.
[#83] Re: TF 536, MMU i stery video do SS

@RokiS, post #81

Pobawiłem się dalej z MuEVD i otrzymałem dużo lepsze wyniki (zaktualizowałem plikopartycje z testami) . Jest szybciej niż poprzednio choć Savage nadal nie pokonuje :

i na pewno wymaga więcej ustawień np. w ikonce Shapeshifter trzeba usunąć bądź zanawiasować REMAP8K jak zrobiłem tu:

w sekwencji-startowej trzeba podopopisywac min.
MuMove4k PrepareEmul
MuFastZero..
MuFastRom...
tutaj moja skrócona sekwencja startowa:



a MapROM włączony podczas testowania? Zrób testy z i bez MapROM.
- chodzi Tobie pewnie o funkcje MuFastRom. Potestowałem i z włączonym MuFastRom emulacja działa nieznacznie szybciej:
[#84] Re: TF 536, MMU i stery video do SS

@RokiS, post #83

No i tu właśnie pojawia się kwestia tego czy warto płacić za Savage, kiedy dobrze skonfigurowany MMUlib z MuEVD oferuje to samo + daje też benefity dla AmigaOS
[#85] Re: TF 536, MMU i stery video do SS

@alt_, post #84

Z historii czytanych na forach mmu i pochodne albo przyspieszają albo zwalniają.
[#86] Re: TF 536, MMU i stery video do SS

@alt_, post #84

No ja zrobiłem testy u siebie, opublikowałem wyniki.
MuEVD oferuje to samo
Ja na pewno polecam Savage jako najszybszego i mało problematycznego:), bądź FastECS - niewiele wolniejszego od MuEVD ale też przyjemniejszego w obsłudze.

daje też benefity dla AmigaOS
- a możne widzieć o jakie benefity chodzi? Bo osobiście nie za bardzo je zauważyłem , przynajmniej nie przy karcie z prockiem 030 z FPU na A600. Jednie co że "jesteśmy skazani" na MMULib przy prockach 040 i 060 ze względu na MuRedox-a... (oxypatcher działacego nie udało mi się zdobyć) a i też jakiegoś super przyspieszenia nie zauważyłem... może nie wiem gdzie szukać, na co patrzeć, co porównać... ale to już temat bardziej do tego wątku

w każdym bądź razie system Amigowy jest bardzo elastyczny i nie problem jest używać do tego samego WB różnych sekwencji-startowych, czyli jednocześnie korzystać i nie korzystać z MMULib

Ostatnia aktualizacja: 19.12.2023 16:46:31 przez RokiS
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem