Ile osób na 1000 użytkowników A500 ma kartę Z2? Gdyby miało ją 80% ludzi, to temat faktycznie by nie istniał.

O jakim nowym Agnusie piszesz? Jego nie można wywalić, chyba, że spatchujesz cały kickstart i chcesz zerwać całkowicie ze wsteczną zgodnością.

O jakim nowym Agnusie piszesz

Jak projektujesz nową płytę to po co pchać w PLCC starego agnusa który może obsługiwać 512KB CHIP (rev3, rev5), 1MB CHIP (Rev 6A) lub stosunkowo rzadko spotykane 2MB CHIP (rev8A) jeśli można zastąpić FPGA z lepszą funkcjonalnością? No właśnie. Piszesz cały czas o tym co można by zrobić na nowej płycie. Nowe płyty A500 są i żadne nie ma tego rozwiązania z buforowaniem jak A3000 (co nie dziwi, bo iirc wszystkie mają nadal 68000 dla którego byłoby to skrajnie głupie). A jak pisałem wyraźnie - apetyt rośnie w miarę jedzenia. Projektujesz nową płytę i chcesz żeby robiła coś więcej, coś lepiej niż oryginalna to po co uparcie poprawiać to co niewiele wnosi jak można dać to co wnosi wiele. Np. rzeczone RTG, albo SD+FF. Albo wifi. Albo kontroler SD jako ide.device - i można by tak wymieniać to co mogłoby być lepsze gdyby robić nową płytę. I większość z tych pomysłów ma większy sens niż kosmetyczna poprawa dostępu do chipramu.

Nie, ja mówiłem cały czas o czymś co znajduje się między Agnusem, a CHIP i daje bezpośredni dostęp do CHIP procesorowi, więc jest całkowicie od niego niezależne. Żeby zrobić Agnusa w FPGA, to trzeba mieć do tego łeb na pewno sporo większy niż do robienia klasycznych kart turbo (CPU + pamięć). Ale gdyby takiego już robić, to głupim by było chyba ograniczać się i nie zrobić jego szybszej wersji z większą ilością CHIPu jak prototyp Minimig AGA, który miał go 50MB.

Tylko widzisz, między Agnusem a CHIP RAM nie ma nic, to Agnus steruje dostępem do CHIP RAM. Można się zżymać ile się chce i tego nikt nie zmieni. A próba dostania się do chip ramu pomiędzy cyklami agnusa jest najłagodniej mówiąc karkołomna.

Żeby zrobić Agnusa w FPGA, to trzeba mieć do tego łeb na pewno sporo większy niż do robienia klasycznych kart turbo (CPU + pamięć)

Tak, ale w dużej mierze to jest już zrobione. A wstrzeliwanie się między cykle agnusa to nie w kij pierdział (jak mawiał starszy druid w wiedźminie), nie można też zablokować dostępu ustawiając priorytet dla CPU bo się mnóstwo rzeczy rozjedzie. W A3000 dostęp przez CPU do CHIP RAM i tak jest zsynchronizowany przez Agnusa.

To nie jest karkołomna robota, Agnusa traktujesz jak kolejny procesor, który ma priorytet wyższy niż CPU, żądania Agnusa obsługujesz w jak najszybszy możliwy sposób dla zainstalowanej pamięci, czyli np. 60ns i potem znów CPU ma do CHIP dostęp, pomimo tego, że Agnus jest w trakcie swojego powolnego cyklu zapisu/odczytu.

To nie jest synchronizacja, tylko łaskawe umożliwienie dostępu do CHIP, kiedy jest na to możliwość. Nic się nie rozjedzie, tylko będziesz miał kolizję, jak coś zrobisz źle, taka sama relacja jak odświeżanie pamięci i dostęp do pamięci. Z zasady dwukrotnie szybszy dostęp w A3000 już jest rozsynchronizowany, bo do CHIPu trafia 2 razy więcej danych niż powinno.

To co piszesz miałoby może jakiś sens gdyby wywalić całą otoczkę DRAMową i zastosować np. 10ns SRAM jako CHIPRAM (albo trochę wolniejszy dual port SRAM) i przełączać wedle żądania z priorytetem na agnusa (ale znów trzeba by dekodować w locie z DDRA adres od strony agnusa) raz dane na D[0:15] jeśli procesor miał dostęp, raz na DDRD[0:15] jeśli agnus miał dostęp. A biorąc pod uwagę, że w trybach o wyższej rozdzielczości chipset kradnie cykle CPU to ma to tym bardziej sens.

tylko łaskawe umożliwienie dostępu do CHIP, kiedy jest na to możliwość

Musisz wygenerować DDRA oraz RAS i CAS. To robi Agnus. Czy na podstawie sygnałów samego procesora da się wyciągnąć kiedy będzie najbliższy dostęp do pamięci realizowany przez agnusa na rzecz chipsetu ze 100% poprawnością? Bo jeśli nie to właśnie jest czynnik limitujący.

Nic się nie rozjedzie, tylko będziesz miał kolizję, jak coś zrobisz źle, taka sama relacja jak odświeżanie pamięci i dostęp do pamięci

Więc twierdzisz, że jeśli w high res chipset nie otrzyma danych wtedy kiedy powinien podczas rysowania ramki to nic się nie rozjedzie? DRAM ma to do siebie, że po całym cyklu adresowania dane na DQ są prawidłowe dopiero po określonym czasie i przez określony czas.

Chipset zawsze otrzyma dane, na tym polega priorytet, a sprawdzić, czy Agnus te dane chce możesz śledząc linię RAS, od tego momentu masz przynajmniej 80ns (takie kostki są w A600, musiałbym posprawdzać jak wyglądają cykle Agnusa) na wstrzymanie dostępu przez CPU lub anulowanie cyklu CPU. Jak szybkie kostki by były potrzebne, to właśnie zależy od tego po jakim czasie od wystawienia RAS AGNUS czyta dane z szyny CHIP.

Podobno można też sprawdzić po liniach RGA co robi Agnus, na EAB Toni Willen kiedyś zasugerował, że mechanizm w FPGA śledzący te linie i zapamiętujący wskaźniki mógłby posłużyć do rozszerzenia ilości obsługiwanej pamięci CHIP przez stare Agnusy, ale to już wyższa szkoła jazdy.

Zauważ jedną ciekawostkę, starsze Indivision ECS posiada tylko szynę danych, sygnał CCK i linie RGA, żadnych adresów, ani nawet pinu, który określałby, czy jest akurat zapis, czy odczyt, już nie mówię o chip_select, a jednak możesz uaktualnić oprogramowanie Indivision, konfigurować, a także przełączyć w tryb "framebuffer" i ładować grafikę w chunky, niestety, tylko Adoom to obsługiwał.



Ostatnia aktualizacja: 26.07.2020 18:27:58 przez WyciorX

Raczej nie możesz zatrzymać dostępu CPU "w pół cyklu", a reakcja fpga na zbocze RAS też zajmie ileś ns. Wystawienie nowych sygnałów też. Itp. itd. Zasadniczo roboty dużo a efekt słaby. Dlatego zdecydowanie lepszym rozwiązaniem w takiej sytuacji jest nowy agnus (o czym wielokrotnie pisałem) bo nie trzeba robić tyle rzeczy "naokoło" - cała logika wewnątrz też jest dostępna i można ją modyfikować by pasowała do tego co chcemy zrobić, a nie trzeba dobudowywać do istniejącej logiki hacków na zewnątrz. Tylko znów jest kwestia - po co się ograniczać do agnusa... a jak przestaniemy się ograniczać to ostatecznie wyjdzie vampire v4. Myślę, że zdrowiej wyjdzie każdemu jak skupi się na tym co jest dla niego najważniejsze. Jeśli granie na chipsecie to zostawmy ten chipset w spokoju. A jak chipset nie jest ważny to można zupełnie go olać, dać fajną grafikę, kontroler SPI, może I2S i jakieś lepsze audio... do wyboru, do koloru. W każdym razie coś co w danej sytuacji się rzeczywiście przyda i przyniesie zamierzony efekt.

Procesor można zatrzymać, bo on będzie wrzucał sobie stany oczekiwania tak długo jak nie dostanie sygnału zwrotnego (dtack w 68000), że cykl został skończony. Każdy ma prawo podążać za swoją ideologią i pomysłami, a ten wątek i tak skończy się tylko na polemizowaniu, jak wiele innych.

Tak, możesz zahaltować i co to da skoro dane na linii nie będą już prawidłowe ;)

Będzie trzeba powtórzyć cykl pamięci.

Myślę ze zbyt duza role przypisujemy do duetu chip RAM - Fat Agnus.
Chip RAM zasadniczo pełni rolę bufora danych dla kontrolera DMA ktory posiada Agnus
To port dla danych pomiedzy przetwornikami cyfrowo-analogowymi a procesorem
Procesor powinien wysylac tam kompletne dane dla przetwornikow końcowych, ktore zaserwuje im sensownie Agnus. W tym obszarze nie ma po co juz przyspieszac bo koncowe przetworniki się przeciez nie zmieniaja np Audio&Video oraz I/O. Tu jest ok. Moc i predkosc przesyłu equal. Przerwaniami zawiaduje Paula.
Gary pelni role systemowego kontrolera HostBusu. Jezeli chcemy powaznej zmiany w wydajnosci
i wykonac turboboost hostbusu, trzeba zacząć od FATgary, ale na szczęście jest komplet kosci w A3000, ktora trzeba gdzieś dorwac.
To najlepsza wersja ECS.
Dalej zostaje AGA i A4000, pochodne klony tej Amigi, i dalej custom computers, czyli składaki.



Ostatnia aktualizacja: 27.07.2020 02:24:06 przez mrcha_67

Nie ma co ukrywać
Większość obecnie idzie za custom computers, tylko udaje _sympatii_ resztki za sprzętem retro.

Glowny powod audio&video. Jakosc tych przetwornikow juz prawie nikogo nie interesuje.
Co dopiero mowic o mocach obliczeniowych

..........................................................................

Z drugiej strony czemu nie?
Takie rzeczy jak 24 bit obraz, 16 bit dźwięk to już było w czasach Commodore.
Może nie w najtańszych sprzętach, ale też nie w super drogich.
Tak samo MPEG, czy sprzętowe 3D.
Dlaczego tego nie dodać do Amigi?

Zależy ktorej Amigi. Pisz model choćby w skrocie np A1200
Co do dawania sprzetu to zalezy czy wewnetrzne rozszerzenie masz na mysli, karta do duzej amigi na I/O
czy zwenetrzne na jakis port.
MPEG najpelniejsza postac ma w DVR. Digital Video Recorder. Cyfrowy magnetowid
Jedną z lepszych przystawek swego czasu bylo urzadzenie AVer Media. MPEG wizzard.
Zakladane na port rownolegly wciąga filmy z kompresja mpeg o jakosci standardu mpeg1
dla plyt kompaktowych VCD.
To bylo dawno. Urzadzenie opisano w recenzji Secret Service nr 81.
Chcialoby sie więcej. Np PLAYER I RECORDER na port rownolegly.
In/Out.
Mogliby jeszcze dodać DivX 3.11 alpha o oznaczeniu fourCC mp43
Tzw low motion na bazie kodeka microsoftowego z Windows Media Encoder.
Niezle efekty daje tez fast motion kodek DivX ,ale szybciej leci klocem,
tzn przy obnizaniu bit rate'u. Moja propozycja to MPEG 1 i DivX (mpeg-4). Bitrate maja podobny a ten low
motion nawet nizszy od mpeg 1 vcd. To na port rownolegly wejdzie.
Trzeba sprzetowych chipow poszukac.

Ostatnia aktualizacja: 28.07.2020 03:39:10 przez mrcha_67

Tu jest link do testow Windows98
http://codecs.necromancers.ru/download/divx_31alpha.exe