XXL po prostu pisze dobrze ;-)

Lotharku, jak Twoje testy ? Masz już jakieś wnioski ? Coś umilkłeś ...

No dobra to sprawdź najnowsze przykłady, te z paki, ok ?

Co do Misji, to (jak i niektóre inne przykłady) sprawdza wersję rdzenia czy jest dokładnie 1.20 - a więc nie ruszy na 1.22 chociaż ten rdzeń jest kompatybilny. Problem został rozwiązany na przyszłość przez dokładniejszą specyfikację numeracji i rozpoznawania wersji rdzenia - począwszy od wersji 1.21.

Lotharek dostaniesz dzisiaj wieczorem (mam nadzieję) inną wersję rdzenia do testów, jeżeli nie znajdziesz przyczyny problemów.

Pin: update rdzenia jest obowiązkowy, na 1.20 gwarancja właśnie się skończyła ;-)

Jacques: Mnie i kilku innym osobom zdarzyły się problemy typu mrugający obraz, kaszana na PMG itp. Problem polega na zbyt opóźnionym przechwytywaniu danych z szyny po opadającym zboczu PHI2 - w efekcie w niektórych komputerach np. po rozgrzaniu sprzętu występowały zapisy błędnych wartości do rejestrów emulowanego GTIA czy też rdzenia FX albo VRAM. Problem poprawiłem przez synchronizację z PHI0 zamiast PHI2. PHI0 wyprzedza PHI2 mniej więcej o 40-50ns.

Rdzenie używają palety laoo.act, podrasowanej osobiście przeze mnie (tj. podniosłem nasycenie kolorów i zwiększyłem ich jasność).

Sam nie wiem, od dawna kusi mnie żeby paletę zmienić (np. nie podoba mi się zbyt zielonkawy odcień tła znaków w gr.0) ale nie mam lepszej palety póki co. Paleta Real.act jest dość fajna ale zbyt jasna (nie ma czarnego), musiałbym ją solidnie przerabiać a później i tak by się to komuś nie podobało...

Atmelika ? To już porządnych procesorów nie ma ? Tylko dla bascomowców ?

Tak, odwróć sygnał zegara do Freda i sprawdź.

Gdy w kompie jest rozszerzenie 1M na simm to zniknie ono po załadowaniu rdzenia "R" - zostanie tylko rozszerzenie vbxe.

Candle trochę przesadził ale tak naprawdę to są tam 22 nogi do tego. 22 = 7R+7G+7B+1clock

XXI wiek nie jest ważny, ważne jest to, że aby puścić sygnał video zgodny z najnowszymi trendami czy choćby tylko zgodny z normami trzeba by zrobić urządzenie 2x większe i droższe niż VBXE. I poświęcić pewnie na to 2x więcej czasu.

VBXE generuje tylko obraz RGB, nie ruszając sygnału synchronizacji - ten robi zwykły GTIA tak jak zawsze to robił. Powiem tak: przez te parę lat, w czasie których robiłem VBXE i rdzenie nie dorobiłem się TV LCD (nie mam do dzisiaj) i nie byłem w stanie przetestować tego na LCD. A ogólnie jest z tym różnie jaki widać. Pech polega na tym że do rozwiązania problemu potrzeba po pierwsze rozwiązywacza (czyli ja lub Candle) i nie działającej konfiguracji (czyli ten LCD).

Pozostaje sprawdzić na CRT na razie.

górny rząd TRZECI od lewej

J1 to 2x4 raster 2.0mm

Namieszałem trochę XXL-owi, więc późno bo późno ale zabieram głos w dyskusji.

Odrobina technicznego bełkotu może pomóc zrozumieć jak działają mechanizmy MEMAC i obostrzenia z nimi związane.

-------------------------------------------------------------------------------------
Mechanizm kontroli linii CASINH

Próba dostępu przez CPU / ANTIC do adresów zajętych przez:

- OS ROM (gdy aktywny - sterowanie: PORTB)
- BASIC (gdy aktywny - sterowanie: PORTB)
- Cartridge (gdy aktywny - sterowanie liniami RD4 i RD5 na porcie CART)
- Rejestry sprzętowe ($d000-$d7ff, aktywne zawsze)

Spowoduje wystawienie przez MMU sygnału CASINH, który to sygnał odcina wewnętrzną
pamięć RAM Atari. Dodatkowo CASINH podłączony do VBXE informuje je, że nie należy nawet próbować podłączać VRAM do szyny.
To połączenie CASINH do VBXE to właśnie ten nieszczęsny nowy "kabelek". Jego brak spowoduje, że
w powyższych przypadkach nic nie ostrzeże VBXE i będzie tak:

przy odczycie: dane z VRAM "zderzą się" na szynie danych z danymi z ROM, CARTA lub rejestrów sprzętowych.
w efekcie bufory będą przeciążane (ale raczej nic się nie spali) i CPU / ANTIC odczyta jakieś bzdury
(wygra silniejszy scalak) - mamy tu p.2 z testu XXL-a - komp się wiesza ponieważ obszar romu $f000-$ffff jest
na bieżąco używany a już nie można nic normalnego z niego odczytać.

przy zapisie: dane zapisywane będą jednocześnie do VRAM i ROM (!) lub rejestrów sprzętowych ....
tutaj jest jeszcze jeden zonk który wynika z konstrukcji atari - mianowicie zapis do ROM
powoduje znowu zderzenie na szynie danych ponieważ w uproszczeniu ROM zakłada, że jeżeli coś od niego chcą
to jest to zawsze odczyt niezależnie od stanu linii R/W i wystawia dane na szynę.

Dodanie kabelka do VBXE powoduje, że nie wpycha się ono z pamięcią MEMAC A na siłę tam, gdzie i tak wepchnąć się nie może.

-------------------------------------------------------------------------------------
Mechanizm kontroli linii EXTSEL

New Device wystawia sygnał MPD, który powoduje odłączenie przez MMU ROMu w obszarze
$d800-$dfff. Po odłączeniu nie jest już wystawiany sygnał CASINH dla tego obszaru -
w tym miejscu może się więc pojawić okienko z normalnym RAM Atari. Aby Atari nie podłączyło ani ROM ani RAM
dodatkowo uaktywnia się linię EXTSEL, która niezależnie odłączy wewnętrzny RAM.
Pojawia się więc "dziura" $d800-$dfff w którą można podstawić ROM/RAM NewDevice (KMK).

Sygnał CASINH dla tego obszaru jest więc nieaktywny, jednak VBXE i w tym przypadku
"trzyma rękę na pulsie" monitorując dodatkowo stan linii EXTSEL (z której samo korzysta w celu zmiany normalnego RAM na obszar VRAM)
robi to następująco:

- gdy spełnione są warunki włączenia bufora memac a/b (CASINH nieaktywny, adres zgodny z memac, aktywacja memac)
wówczas sprawdzany jest jeszcze stan linii EXTSEL - jeżeli linia jest aktywna, wówczas VBXE zakłada, że
jakieś nieznane mu urządzenie (np. KMK) zażądało dostępu do szyny danych i "odpuszcza sobie" podłączenie VRAM w tym cyklu
- nieznane urządzenie ma priorytet nad VBXE.
Jeżeli linia EXTSEL jest nieaktywna, wówczas VBXE zakłada, że nic nieznanego mu nie "dobiera się" do szyny sam ją (linię EXTSEL) aktywuje - czyli w tym cyklu podłączany jest VRAM a odłączany RAM Atari.

Popraw może to nadpisywanie dl przy ładowaniu (np. wyłącz kulturalnie DMA) bo latające i migające syfy mnie wkurzają - Drac030 o tym dobrze wie. ;-)