1

Witam.

1. Czy ktoś orientuje się jak działa 16KB cache w Atari Mega STE? Bo tak na schemacie to mi to wygląda na taki, co za jednym razem buforuje dane tylko w ilości 1 słowo / 2 bajty, czyli głównie przydaje się dopiero przy drugim pobraniu danych np. w pętli. Mam rację? Z tego co widzę, to cache w przykładowych aplikacjach x86 buforuje 16 bajtów i to chyba ma większy sens - ciekawe jaki zysk dałoby zrobienia cache z blokami po np. 16 bajtów. Tak dla teorii, bo chyba zrobienie tego byłoby niezłym wyzwaniem.

2. Czytam sobie o MC68000 i Atari - właśnie przeczytałem dwie ciekawe rzeczy. Po pierwsze procesor ma bufor prefetch na dwa słowa, do którego czyta sobie instrukcje z wyprzedzeniem (więc chyba trzeba uważać i np. nie próbować zmieniać mu następnej instrukcji w kolejce, ani dawać na końcu 4MB RAM instrukcji RTS, bo doczytanie do bufora spowoduje wywołanie błędnego adresu, a co za tym idzie błąd - tak przeczytałem). Po drugie MMU dzieli dostęp do pamięci pomiędzy CPU/DMA/BLITTER, a układ graficzny/sound DMA w proporcjach 2 cykle/2 cykle - jeśli procesor zechce pobrać dane w cyklach nie dla siebie, to czeka. Te dwie informacje powodują, że policzenie ile cykli zajmie procedura graniczy chyba z cudem, bo o ile przyjmuje się zasadę zaokrąglania cykli instrukcji do 4 w górę, o tyle ten bufor powoduje, że czasem procesor nie czeka wcale na dostęp do pamięci. Nieźle zakręcone.

3. Dowiedziałem się, że nie jest tak jak całe życie myślałem, tj. że Atari ST ma jedną pamięć i koniec. Okazuje się, że można zrobić tzw. fast ram czyli jak rozumiem pamięć dostępną dla procesora (tylko?), ale już nie dla Shiftera - czyli już nie dzielimy cykli na dwa. Rozumiem, że taką pamięć się robi z pominięciem MMU. Ale jak to widzi TOS, który chyba o czymś takim nie wie i pomyśli, że to "zwykła" pamięć? W ogóle skąd Atari wie ile ma pamięci - gdzieś chyba czytałem, że sprawdza to na początku program z ROMu wpisując dane pod kolejne adresy - i tu pytanie - do ilu szuka tej pamięci i czy zależy to od wersji TOSu (np. czy znajdzie 8, 14MB, a może nawet inne dziwne kombinacje)? Gdzie indziej czytałem, że pamięć wideo ląduje na końcu - czyli w przypadku FAST RAMu byłby problem? No i jak to jest z pamięcią - czy jak jest 1MB to odczyt dalszej pamięci powoduje zapętlenie i odczyt spod dostępnej pamięci, czy raczej błąd.

Wciągnęło mnie to, mam nadzieję, że jak już się utwierdzę w swoich przekonaniach to zwrócę :) część tej wiedzy do jakiejś atariki czy czegoś. Ciekawe teksty:

http://pasti.fxatari.com/68kdocs/68kPrefetch.html
http://pasti.fxatari.com/68kdocs/AtariS … nting.html

Krzysztof [Atari 1040 STE + 65 XE]

2

1. Działa dokładnie tak jak napisałeś. Wszystko co raz zostało wczytane potem odczytuje się z cache-u (chyba, że wyleci). Porównywanie tego cachu z tym co jest w x86 jest trochę bezsensu bo między tymi prockami jest różnica 20 lat. Dodatkowo: magistrala penitum 1 ma 64bity, więc ma sens wczytywanie większych kawałków danych.

Pozatym cache w mega ste jest unified, to znaczy dla instrukcji i danych.

2. Prefetch na dwa słowa wcale nie jest taki straszny. Wiele instrukcji ma dodatkowe słowo rozszerzenia. Ogólnie motorola w swojej dokumentacji nie pisała o wpływie prefetch na ilość cykli w jakiej się instrukcja wykona, za to długość instukcji miała znaczenie. Proponuje sobie zassać manuala ze strony freescale.

3. Po pierwsze shifter nie ma pojęcia co to jest pamięć. MMU adresuje pamięć i wysyła do shiftera sygnał, że na magistrali jest właśnie słowo obrazu.
Co do fast ramu to zależy o jakim TOS-ie mowa. Tylko TOS w TT i Falconie wie co to jest fastram. Wszystkie inne nie. Idea fast ramu jest taka sama jak na amidze. Żeby to był fastram, CPU musi działać na magistrali odciętej od reszty systemu (inaczej dalej musiałby walczyć o dostęp do magistrali i idea fast ramu umiera). Podobnie działa cache w mega st. To takie 16kb  fast ramu przydzielanego dynamicznie.

TOS przy starcie wpisuje do rejestru konfigracyjnego mmu różne wartości ustawień i sprawdza czy pamięć jest ciągła o określonych obszarach. Jeśli nie ma dziury to wpisuje do MMU właśnie takie wielkości banków pamięci.

Pamięć video ląduje na końcu ST ramu. ST nie ma w ogóle żadnego pojęcia o fast ramie. wszelkie wynalazki podłączone do proca potrzebują albo spaczowanego tosu, albo jakiegoś progsa w auto, który to podmontuje jakoś do systemu.  Tutaj pojawia się kolejny problem, bo chyba dopiero tos 3.0 ma rozszerzoną wersję malloca (mxalloc), która pozwala rozróżnić stram od fast ramu.

Jak masz 1MB i chcesz oczytać coś poza tym obszarem to dostaniesz bomby. MMU nie pozwoli na odczyt z takiego miejsca.

Nawiasem mówiąc, "fast ram" na atari nazywa się TT ram. precz z amigową nomenklaturą :P

What can be asserted without proof can be dismissed without proof.

3 Ostatnio edytowany przez jury (2009-08-14 07:27:47)

krzyc, skoro piszez ze wciagnelo Ciebe ST od strony technicznej, to polecam dosc ciekawe linki ( chyba ze juz je znasz na pamiec :) )

http://alive.atari.org/alive9/ovrscn1.php  ( plus kolejne 2 czesci w nastepnych numerach )

http://www.atari-forum.com/viewtopic.php?f=1&t=4357