Adam, problemy typu przesuwanie ekranu o bitplan lub dwa, pionowe pasy, zrywanie overscanu itd ma to samo źródło - zła 'obsługa' SHIFTERa, MMU czy GLUE przez programistę.
Zeby nie zagłębiać się zbytnio w technikalia, SHIFTER ma parę wewnętrznych rejestrów niedostępnych dla programisty, m.in.  "IR" i "RR". Wypełniane są one przez MMU danymi obrazu, pod 'dyktando' GLUE. Jeśli programista zaburzy współpracę tych układów, to te rejestry nie zostaną poprawnie załadowane danymi ekranu i finalnie użytkownik zobaczy kaszankę na ekranie.
O to zaburzenie nie jest w sumie trudno, efekty typu overscan czy spectrum512 polegają na 'bombardowaniu' tych układów nowymi danymi. Tak więc, dla higieny pracy trzeba od czasu do czasu dokonać 'resetu' tych układów. Np. w ST (nie STE), w trybie overscan trzeba to robić co linię (HI/LO stabilizer) ekranu.
Tutaj znajdziecie trochę detali na ten temat: http://www.atari-wiki.com/?title=ST_STE_Scanlines

To o czym piszę to są problemy programowe a nie sprzętowe, nie ma tutaj potrzeby wymieniać chipów na inne.
W sumie to nie wiemy czy dotyczą one Pina i Yerza. Być może w ich przypadku sprzęt jest uszkodzony, w końcu ma swoje lata.

a czy dało by się dodać do Rapidusa jakieś zacne DMA, które po aktywacji (np. co VBL) samo kopiowało by dane z pamięci do rejestrów sprzętowych, np do rejestrów koloru? Dzięki temu CPU mógłby pracować równolegle z "trybem Tebe" :)
Na ST jest taki tryb Photochrome gdzie BLiTTER właśnie kopiuje dane koloru z RAM do rejestrów koloru SHIFTERa

zapodajcie jakieś zdjęcie

dajcie jakieś foto tego rastra z realnego sprzętu

BartoszP no ale i tak smog mamy jak ta lala :)

cacy!

raw zajmie  koło 3TB.
W razie braku ramu można załadować tylko wymagany fragment danych do pamięci.

dobre to

na razie nie pokazali działającego Vampire na ST... czyżby jakieś problemy?

fajne

dorzucę jeden link: http://www.shonyatric.cz/shop/index.php