Mimo, że architektura Agnusa pozostaje ta sama, to efektywność jego wykorzystania przy szybkim dostępie do CHIP rośnie, tak samo jak efektywność w dostępie do pamięci CHIP rośnie do granic możliwości wraz szybkością procesora, pomimo tego, że przepustowość faktyczna pozostaje bez zmian. Przy szybkim dostępie do CHIP i szybkiej karcie turbo możesz zapomnieć o używaniu blittera (fblit, ftext) i wrzucać szybko całe ramki do CHIPu, a nawet operować danymi na CHIPie bezpośrednio, bez większych strat mocy procesora. agnus zajmowałby się wtedy tylko dostarczaniem danych do Denise i Pauli. Szybki CHIP po prostu pozwoli wycisnąć z ECS wszystkie soki, jakie są tylko możliwe. Możliwe, że tryb 16 kolorowy działałby tak samo szybko jak obecnie 4 kolorowy.

Blitter w AGA jest dalej 16-bitowy, tylko nie wiem czy tak samo wolny.

blitter w AGA jest tak samo szybki jak był w 1983 w pierwszym chipsecie.
Dali parę bitów więcej do rejestrów adresowych to działa na 2 MB a nie 0.5 MB jak w 1983.
Nawet na a1200 z fastem 020 jest w stanie rysować szybciej niż blitter.

Najwazniejsza w tym jest VESA
Tak to nazwalem.
Vesa local bus szyna lokalna, podzial na dwie przestrzenie na dwoch oddzielnych szynach
Na szynie, nazwijmy to, lokalnej chip RAM z DMA FatAgnusa, na drugiej Fast RAM procesora.
Nie wiem czy A3000 to zapewnia. Wtedy w jednym synchronuczym takcie moga pracowac na raz kontroler
DMA i procesor. Moze ktorys z dodatkowych ukladow np SuperBuster to zapewnoa wraz z Ramsey i SuperDMACiem. Tak czy siak konstrukcja Amigi 3000 jest lepsza i bardziej wydajna niz 500+ Prawie podobne przetwodniki C/A audio i wideo jednak moc wieksza.

Jak juz wspominalem nikogo nie zatrzymuje w tym temacie. Zycze powodzenia z innymi klonami Amigi zwlaszcza 1200. Traktuje sprawe sympatycznie. Sam pozostaje przy swoim "turbo".

Ostatnia aktualizacja: 25.07.2020 20:51:25 przez mrcha_67

Na szynie, nazwijmy to, lokalnej chip RAM z DMA FatAgnusa, na drugiej Fast RAM procesora.

Byle rozszerzenie fastu do pięćsetki to zapewnia... Nie mówiąc o kartach turbo.

Nie, efektywność wykorzystania Agnusa nie rośnie w miarę przyspieszania dostępu CPU do pamięci. Rozwiązania użyte w A3000 nie przyspieszają dostępu Agnusa do pamięci, bowiem ten zdeterminowany jest prędkością szyny między nim a chip ramem. Magistrala ta zsynchronizowana jest z prędkością działania chipsetu, jest kiepsko podkręcalna, a ewentualne podkręcenie już o kilka procent powoduje brzydkie efekty uboczne w postaci zmiany częstotliwości generowanego dźwięku, zmiany timingów generowanego obrazu, oraz zakłócenia działania interfejsów I/O i nieprawidłowe działanie timerów systemowych (są w CIA).
Zastosowanie szybszego CPU i polepszenie jego dostępu do chip ramu przyspiesza działanie komputera, gdyż dane zawarte w chip ramie szybciej są przetwarzane, jednak sloty dostępu Agnusa do chip ramu pozostają dokładnie takie same. Efekt dałoby przyspieszenie magistrali przez zwiększenie taktowania, lub jej rozszerzenie, o ile pierwszy sposób omówiłem powyżej, to drugi wymaga zaprojektowania nowego Agnusa z 32 bitowym dostępem do pamięci... takim "Agnusem" jest Alice.
Oczywiście użycie szybszego CPU w funkcji blittera odciąża DMA Agnusa, gdyż sloty dostępu normalnie użyte przez blitter mogą być użyte dla innych kanałów DMA (np. dla Denise, dzieki czemu można użyć więcej bitplanów bez silnego spowolnienia). Komputer staje się o wiele bardziej responsywny, jednak nie dlatego że przyspieszyliśmy Agnusa, tylko dlatego, że go odciążyliśmy. Tak działa łatka systemowa FBlit.
Blitter w AGA jest tak samo wolny, ale zdaje się transfery blittera obsługiwane przez 2x szybciej taktowaną magistralę w AGA zużywają mniejszą ilość slotów dostępu, czyli sumaryczne tempo transferu blittera jest takie samo, ale Agnus ma więcej czasu na dostęp dla innych urządzeń, bo obsługa blittera jest krótsza. Poczytaj w jaki sposób Agnus zarządza dostępem do pamięci i arbitrażem między całym tałatajstwem mającym apetyt na chip ram... ciekawa lektura.

Kolejny post - już krashan pisał, że każda Ami ma możliwość użycia dwóch niezależnych magistral: jedną do chip ramu zarządzaną przez Agnusa/Alice i drugą do fast ramu z wyłącznym dostępem CPU. To jest znane i używane w Amigach od 35 lat. Ale pomysł dobry

Efektywność, a przepustowość to dwie różne rzeczy, im szybciej władujesz coś do CHIP, tym szybciej możesz zlecić Agnusowi by się tym zajął i w ten sposób likwidujesz luki w slotach DMA, które pozostają niewykorzystane, a raczej w przypadku systemu pozostają. Gra, która wykorzystuje wszystkie sloty DMA Agnusa skorzysta na szybszym dostępie do CHIP, gdy okaże się, że przepustowość CHIP jest na tyle szybka, by podmieniać w niej dane graficzne w czasie rzeczywistym, a im więcej można ich podmienić, tym bardziej złożona graficznie może być gra, np, może mieć więcej klatek animacji głównego bohatera, które są ładowane z fastu do chipu co klatkę.

Oczywiście. Ale nadal nie oznacza to, że Agnus został "wykorzystany efektywniej". Po prostu część zadań Agnusa przejął szybszy CPU, więc Agnus ma mniej obciążone kanały DMA i cały komputer pracuje szybciej... bo ma szybszy CPU. To oczywiste.

Nie mówię o sytuacjach, w których CPU pracuje za Agnusa, tylko takich, gdzie jego dany zasób, np. blitter nic nie robi, bo akurat CPU kopiuje dane do CHIPu, które będą blitowane, efektywne wykorzystanie Agnusa, to wykorzystanie jak największej ilości slotów DMA, do wykonania jak największej pracy w jednostce czasu.

Pamięć CHIP też ma stałą przepustowość, ale na procesorze 68000 7MHz nie masz możliwości wykorzystać jej efektywnie.

Może też użyłem złego sformułowania, szybki dostęp do CHIP pozwoli pracować efektywniej mechanizmom rysującym grafikę, szybszy dostęp do CHIP to także efektywniejsza praca procesora.

Ostatnia aktualizacja: 26.07.2020 00:42:14 przez WyciorX

No ale wciąż poruszamy się w obszarze truizmu "szybki dostęp do CHIP pozwoli pracować efektywniej mechanizmom rysującym grafikę, szybszy dostęp do CHIP to także efektywniejsza praca procesora". Przecież to oczywiste.

Trudno dyskutować na temat efektywności wykorzystania chip ram bez zdefiniowania co to właściwie znaczy. Dla mnie najbardziej harmonijną konstrukcją są Amigi z 68000 7,14 MHz, dlatego że przepustowość pamięci została dobrana tak, że rzadko zdarzają się sytuacje, gdy CPU lub Agnus wzajemnie się blokują. CPU ma korzyść z istnienia blittera, gdyż blitter jest szybszy od niego w przenoszeniu bloków RAM, zaś CPU może zająć się tym do czego został stworzony: wykonywaniem obliczeń.
Idea przerzucenia wiekszości zadań z chipsetu na CPU jest architektonicznym cofaniem się. Ja rozumiem, że szybki CPU dalece przewyższa osiągami agnusowy blitter, ale to trochę tak, jakbyś do domu wchodził przez okno, bo duże i wygodne, zaś drzwi małe i stare. Zamiast zastanawiać jak ulepszyć wchodzenie przez okno, o wiele lepiej ulepszyć drzwi. :)
I tutaj moja idea.... zamiast robić nowego Agnusa, bądź próbować zhackować starego, lepiej dodać zewnętrzny układ blittera (tak jak w Atari ST). Zrobienie blittera w CPLD nie powinno być trudne, przy okazji można by dodać nowe funkcje np. cieniowanie Gourauda, czy jakieś proste funkcje 3d. Zamiast przerzucać zadania na CPU przerzucić je na nowego blittera. Wszystko pozostało by zgodne z duchem Amigi a nie ZX Spectrum (robienie wszystkiego za pomocą CPU).

Ale progu ograniczeń agnusa i tak nie przebijesz. Jeśli ktoś koniecznie chce szybszy chipset to musi zrobić szybszy chipset. Żadnych kokosów z dorobienia szybszego dostępu do CHIP przez procesor nie uzyskasz. Stare produkcje i tak z tego nie skorzystają, bo są napisane pod obsługę przez blitter, nowe jeśli by były to z reguły nie skorzystają, bo są pod rtg. Zasadniczo nie ma to większego sensu. Jak ktoś chce się pozbyć ograniczeń chipsetu to bierze RTG. Jak kogoś interesuje retro to mu ten chipset nie przeszkadza, bo gry są pisane tak by na nim dobrze działać.

Niestety. Odświeżania w realtime w 640x480 256 kolor nie będzie.
Trza by było zrobić chipset od nowa.
Co nie znaczy że klasyk nie potrzebuje jakiejś lepszej grafiki.
Minimum 640x480 16 bit kolor, najlepiej jakby mieszało video z chipsetu z nowym.

Ciekawe czy na zgodność rejestrow i elektrycznie do ecs mozna wkleic Alice zamiast Agnus.
Jak nie moze trzeba by gdzie zamowic modyfikacje kosci Agnes.Agnieszka
Dobre nie?
No bo roztrzygnijmy czy Fat Agnus jest 16bitowy czy 32 jak obiecano za nazwe przedrostka FAT
Po drugie rozsrzygnijmy prędkości blitera.
Należy do chipsetu a więc 28,6MHz myślę. Tylko port na procesor przytaktowany jest 4* nizej.
Ograniczenie raczej sztuczne szybkiego chipsetu dla procesora, ktoremu podaje sie taki zegar.
Jak tylko blitter sięga do chip ramu pracuje na 28,6 MHz. Kości pamieci musza wytrzymywać tą prędkość w tzw czasach dostepu nie zapozniaja. Ograniczenie procesora wydaje sie calkowicie sztuczne. Slabszy komputer musi byc mniejszyvi tanszy, TANSZY. Dlatego przycieli po procesorze. Inaczej nie mogli wyjsc z twarzą. I dac komputer ludziom żeby mogli pograć.
Inaczaj biorąc rura i komóra , dali czadu , wymienili (ooops!) Gary na nowy 32 bitowy FATgary.
I już, obsadzili motorole 68030/25MHz ponoc zeby takt TV ntsc trzymać znaczy USA wita! Tfu znaczy zegna nas biednych EU. Tak bylo kiedyś a ja teraz z USB zrobię USA....



Ostatnia aktualizacja: 26.07.2020 11:10:41 przez mrcha_67

fat agnus jest 16 bit.
blitter jest taktowany od 1983 czyli od zawsze 7 MHz.
tak po a500 robili wszytsko po taniosci.

No bo roztrzygnijmy czy Fat Agnus jest 16bitowy czy 32 jak obiecano za nazwe przedrostka FAT

Wg zalaczonego schematu do manuala do Amigi 500, ktory jest opisany jako:
"Rock Lobster 05.06.86", ukald 8370/8371 nazwany jest Fat Agnus.
Czyli jest 16bit.

Fat Agnus dlatego jest Fat, że adresuje więcej RAM (1 MB) niż oryginalny Agnus (0,5 MB). Idąc wg tej konwencji nazewniczej, Agnusy adresujące 2 MB nazwano "Fatter Agnus". Zaś każdy Agnus, Fat i Fatter jest 16 bitowy.
32 bitowym Agnusem jest Alice, która ma podobne sygnały (chociaż oczywiście inny pinout... chociażby te dodatkowe 16 bitów magistrali danych gdzieś się musiało znaleźć) i podobne rejestry.

Trudno dyskutować na temat efektywności wykorzystania chip ram bez zdefiniowania co to właściwie znaczy.

Jeżeli pamięć ma przepustowość 3.5MB/s, a test prędkości wykazuje ci 1MB/s, to efektywne wykorzystanie tego transferu raczej nie jest. Jeżeli kopiujesz coś do CHIP procesorem 68000 7MHz, to pomiędzy zapisami, są odczyty instrukcji programu, tych instrukcji może być kilka w zależności od jakości pętli, to są też cykle dostępu do CHIP, które są tracone, przy szybkiej karcie turbo stracisz jeden cykl dostępu lub żaden, bo procesor wykona pętlę szybciej.

Przykład:
Cykl procesora 68000 7MHz to 560ns, więc jeśli pętla składa się z 8 instrukcji (jedna idzie na dostęp do chip, więc zostaje 7), to między zapisami do CHIP będziesz miał 3920ns, procesor 4 razy szybszy straci tylko 980ns.



Ostatnia aktualizacja: 26.07.2020 12:43:07 przez WyciorX

Dyskusja dotyczy A3000, czyli automatycznie ECS i ulepszenia konstrukcji do max, jak włożysz AGA to już będzie A4000, CHIP jest kulą u nogi, bo każdy procesor na karcie turbo musi abstrakcyjnie zwalniać do cyklu 68000 7MHz podczas instrukcji dostępu do CHIP, na 060 jest to ogromna strata, a gdyby ktoś chciał robić sobie A3000 w obudowie od A500, to czemu by nie zlikwidować/zminimalizować tego problemu?

Ostatnia aktualizacja: 26.07.2020 12:43:28 przez WyciorX

No ale przecież to co wykazują testy, to wyłącznie wydajność transferu między chip ram a CPU. Agnus zasadniczo nie ma tu wiele do gadania. Chyba że jako efektywność wykorzystania rozumiesz prędkość kopiowania danych przez blitter.
Chip RAM ma wyższą wydajność niż szyna 68000, ponieważ w oryginalnym założeniu CPU i Agnus mają sobie jak najrzadziej przeszkadzać.

Ale ECS korzysta z takich samych magistral co OCS, wydajnościowo też jest praktycznie taki sam. Przecież możesz do A500 rev 6 włożyć Agnusa z A3000 i będzie działać.

Zawsze mnie zastanawialo dlaczego jesli procesor musi dokonac operacji na CHIP RAMie
to musi zwalniac do poziomu 68000. Dlaczego nie zaprojektowali Agnusa/Alice w ten
sposob aby dostep do tej pamieci byl czyms w rodzaju "pass-through".

Chodzi mi o to, że max. przepustowość od procesora do CHIP przez Agnusa przy 16 bitach, to 3.5MB/s, gdyby dało radę wykorzystać wszystkie cykle, 68000 na 7MHz nie jest w stanie wykorzystać w pełni przepustowości do CHIP, więc jest z zasady nieefektywny, jedynie turbiny, ale ich limit to właśnie 3.5MB/s przy WB w 4-ch kolorach, przy 8-miu kolorach spada do 2MB z kawałkiem.

Chip RAM ma wyższą wydajność niż szyna 68000, ponieważ w oryginalnym założeniu CPU i Agnus mają sobie jak najrzadziej przeszkadzać.

Chip RAM w A500, ma wydajność 7MB/s i jest dzielony na pół między CPU i resztę, do czasu kiedy nie włączysz większej ilości kolorów lub rozdzielczości, kiedy grafika zaczyna kraść cykle CPU. Na 68EC020 w 4-ch kolorach bustest wykazuje 3.5MB/s zapisu, w 8-miu kolorach na ClassicWB mam na tej samej karcie 2.4MB/s.

Bo A500 czy A600 nie miały korzystać z lepszego procesora, A1200 w ograniczonym zakresie, a A2000, A3000 i A4000 miały korzystać z RTG na zorro więc dostęp do chip ram nie był niczym krytycznym.
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html
Jak widać A500 z 7MHz ten dostęp do CHIP RAM był z reguły zupełnie wystarczający i trudno byłoby osiągnąć coś zdecydowanie szybszego. Nie wiem jak to wyglądało z 020@14MHz i AGA. Biorąc pod uwagę ile podsystemów było ściśle zależnych od sztywnych cykli dostępu do pamięci to było to na tamte czasy optymalne rozwiązanie. Dziś nic nie stoi na przeszkodzie by wywalić agnusa, dać fpga z translatorami napięć i dobudować 32b CHIP SDRAM i udostępnić to procesorowi jako 32b fast (Z3 fast) z taką prędkością by zaspokoić jego możliwości niezależnie jak by był szybki, a jednocześnie utrzymać otwarte sloty dla wolniejszej reszty chipsetu. Czemu nikt więc tego nie robi? Bo się nie opłaca. Nic konkretnego to nie wniesie.

Pierwsza zasada przy projektowaniu kart turbo: Karta musi emulować cykl procesora, który zastępuje, a więc karta musi się zachowywać jak 68000 7MHz, kiedy następuje dostęp do układów Amigi w A500, chodzi o timingi i czas po jakim pojawią się dane do odczytania.

Czemu nikt więc tego nie robi?

Vampire?

Do klasyka nie robi, bo jest problem z montażem takiego urządzenia, w A600 np. nie obyłoby się bez lutowania, ponieważ musisz wywalić CHIP z płyty i jakoś włożyć ten kontroler zamiast niego, nie wspominając o ciągnięciu szyny do karty turbo, która też by musiała umieć coś takiego obsługiwać. Ale przy projektowaniu płyty głównej, to już takim problemem nie jest.

Nic konkretnego to nie wniesie.

Czy prędkość pamięci CHIP w Vampire nic nie wnosi?

Czy prędkość pamięci CHIP w Vampire nic nie wnosi

A co wnosi do tytułów retro pisanych na chipset? No w zasadzie nic konkretnego. Dla wszystkiego pisanego na RTG jest bez większego znaczenia, bo tutaj jest ważne jak procesor szybko gada z tym co wyświetla ekran, dostęp do chipramu jest tu pomijalny.

Vampire?

Vampire nie robi. Może wciągnąć SAGA w jakiś tam wersjach softcore i na tym SAGA robić co się chce jak się chce. Ale oryginalnego chipsetu to nie przyspieszy. Teraz pozwól że wyprowadzę cię z błędu:

w A600 np. nie obyłoby się bez lutowania, ponieważ musisz wywalić CHIP z płyty i jakoś włożyć ten kontroler zamiast niego

Nie, nie musisz wywalać chip z płyty tylko wkładasz płytkę w socket PLCC a na płytce będzie fpga z implementacją "superfat agnus" ORAZ pamięcią RAM pełniącą rolę CHIP i FAST naraz. Linie DDRD na płycie głównej byłyby nieaktywne, a jedynie linie łączące z nowym CHIP/FAST koło FPGA. Istniejące turbo do A600 i tak mają link lokalny downgrade do cykli 68000 7MHz więc to zupełnie mija się z celem, natomiast gdyby zintegrować turbo z pełnym 32bit procesorem (68020, 68030 i wyżej) to można mieć pełną 32bitową przestrzeń adresową oraz 32 bit datalink do chip/fast sdram. I to jest możliwe od 2 dekad do zrobienia, a nikt tego nie robi. I słusznie.

Ostatnia aktualizacja: 26.07.2020 13:52:02 przez abcdef

A co wnosi do tytułów retro pisanych na chipset?

Do tytułów retro napisanych pod harmonogram chipsetu, to nawet milion razy szybszy chipset nic nie wniesie. Zdecydowana większość gier napisanych na A500 działa tak samo szybko na A1200 z turbiną, która ma szybszy chipset, więc przytaczanie tego argumentu nie ma żadnego uzasadnienie, pod tym względem możemy również dywagować, czy wkładanie karty turbo ma w ogóle jakiś sens, skoro nie widać różnicy w retro gierkach i demkach. Ale ludzie kupują turbo, a różnica jest odczuwalna gdzie indziej, choćby w prędkości rysowania okienek i przesuwania ikonek, czyli istoty amigowania czyż nie?

Może wciągnąć SAGA

SAGA to nawet nie jest chipset, tylko RTG, CHIP na Vampire może istniec tylko wtedy, kiedy cały chipset jest na Vampire.

Dla wszystkiego pisanego na RTG jest bez większego znaczenia, bo tutaj jest ważne jak procesor szybko gada z tym co wyświetla ekran, dostęp do chipramu jest tu pomijalny.

Ile ludzi, którzy mają ECS i turbo mają też RTG? Im to powiedz, że jest pomijalny, przy używaniu ECS do zabawy w WB, gadanie procesora z pamięcią CHIP ma takie samo znaczenie jak w przypadku RTG.

Teraz pozwól że wyprowadzę cię z błędu:

Próba zakończona niepowodzeniem, dalej trzeba coś wylutować i wlutować. Widziałeś żeby Jens sprzedawał jakiś produkt, który wymaga prac lutowniczych w Amidze? Mógłby przecież sprzedawać takie wersje Mini Megi, więc czemu nie sprzedaje?

natomiast gdyby zintegrować turbo z pełnym 32bit procesorem (68020, 68030 i wyżej) to można mieć pełną 32bitową przestrzeń adresową oraz 32 bit datalink do chip/fast sdram.

O Tym pisałem już w poście #44

a nikt tego nie robi. I słusznie.

Ktoś już to robił i udowodnił, że nie ma racji bytu?

To ciekawe, że Cizar myślał nad czymś takim przy budowie Warpa i jest tu nawet wpis na forum, ale zabrakło mu pomysłu jak się za to zabrać, bez powodu chyba nad tym nie myślał?


Ostatnia aktualizacja: 26.07.2020 14:51:36 przez WyciorX

a różnica jest odczuwalna gdzie indziej, choćby w prędkości rysowania okienek i przesuwania ikonek, czyli istoty amigowania czyż nie?

Ale ikonki można przesuwać też na karcie rtg i szybszy chip ram nie jest do tego w żaden sposób potrzebny. Od biedy można kupić ZZ9000 jeśli wcześniejsze rozwiązania byłyby za wolne ;)

Próba zakończona niepowodzeniem, dalej trzeba coś wylutować i wlutować

W A600 tak, w A500 nie.

Ktoś już to robił i udowodnił, że nie ma racji bytu?

Wszyscy co są w stanie to zrobić rozumieją, że zasadniczo gra nie jest warta świeczki. Przykro mi, ale nie prowadzę szkółki by wyjaśniać dlaczego. Chcesz, kup sobie za stówkę dev board z QMTECH podłącz i sprawdź sam. Masz źródła z minimiga. Weź i kombinuj jeśli uważasz, że jest inaczej. Problem z rozbudową jest tylko taki, że apetyt rośnie w miarę jedzenia. Link CPU-CHIP RAM wolny? To zmienimy na fajnego Agnusa. Za słabe tryby Denise? To dodamy Denise do FPGA. Gary'ego wywalmy i zróbmy Gayle w FPGA... oj to teraz to najlepiej cały chipset... I co masz? Vampire V4. Dziękuję, postoję.

To cię oświecę, że Cizar myślał nad czymś takim przy budowie Warpa

Oj ja myślę, że bardzo dużo osób o tym już myślało, dużo osób takich co wiele dobrze sprzedających się produktów ma na koncie. I nie zrealizowało tego nie ze względu na brak możliwości czy zbyt trudne zagadnienie, a po prostu dlatego, że to nawet jak na amigowe warunki jest pozbawione większego sensu.

Ostatnia aktualizacja: 26.07.2020 14:54:49 przez abcdef

No właśnie trzeba mieć ta kartę RTG, ile osób z ECS ma taką kartę?

W A600 tak, w A500 nie.

Niestety, ale adaptery PLCC są już dawno nieprodukowane, więc w grę wchodzi jedynie lutowanie.

Problematyczne i kosztowne jest wszczepianie się w istniejące konstrukcje, w przypadku projektowania płyty A500 od nowa z zintegrowanym turbo, problem przestaje praktycznie istnieć.

Ja już o tym myślałem, ale jako projekt hobbystyczny, ma to niski priorytet względem innych projektów.

Cóż moge powiedzieć, kiedy 8 lat temu rozmawiałem z Jakubem Bednarskiim (minimig, fpga arcade) na temat projektowania kart turbo, zrobił on wtedy sobie przystawkę z procesorem 060 do FPGA Arcade i mówił, że warto stosować buforowany zapis do CHIP, bo to jedyny sposób, by uzyskać najlepszy możliwy zapis do CHIP w ECS, czyli 3.5MB/s przy 16bitach i że widać to w jakichś programach graficznych, a buforowany zapis do CHIP polega tylko i wyłącznie na tym, że zatrzaskujesz adres i dane, a procesorowi dajesz dtack, by procesor działał dalej, podczas, gdy maszyna stanu wykonuje cykl 68000. Jeżeli sam buforowany zapis coś tam daje, to szybszy zapis do CHIP tym bardziej powinien.


Ostatnia aktualizacja: 26.07.2020 15:14:01 przez WyciorX

Bo miało być tanio.

No właśnie trzeba mieć ta kartę RTG, ile osób z ECS ma taką kartę?

Każda z warpem 560? :) Wiele z ZII?

ale adaptery PLCC są już dawno nieprodukowane

Potrzeba matką wynalazku. Potrzebujesz kanapkę laminatów na wymiar socketu z miedzią na bokach. Coś jak boki modułu ESP8266 tylko w kilku warstwach. Wszystko do ogarnięcia w np. pcbway.

w przypadku projektowania płyty A500 od nowa z zintegrowanym turbo, problem przestaje praktycznie istnieć

Tak, tylko po co, skoro równie dobrze możesz olać nowego agnusa a dać po prostu RTG na tą nową płytę? Wbudować scandoubler i inne *uje muje dzikie węże dające coś zdecydowanie lepszego niż nieco szybszy dostęp procesora do chip ramu.