Odpowiedź po roku to może trochę późno, ale lepiej niż wcale. ;) Być może już na to wpadłeś, ale wypada mi sprawę wyjaśnić. Dwa przerzutniki widoczne na schemacie tworzą rejestr przesuwający, który opóźnia sygnał na wejściu szeregowym o dwa cykle bitrate. W tym czasie komputer dokonuje pomiaru prędkości transmisji i ustawia POKEY do odbioru.

Jeśli ktoś chce drogą prostego eksperymentu przekonać się o pochodzeniu prążków, niech przetnie krótką, grubą ścieżkę na spodniej stronie płyty, łączącej 9 nóżkę układu CD4050 (masa) przez przelotkę ze ścieżką masową ANTIC-a i CPU, a następnie krótkim kabelkiem połączy tę nóżkę z polem masy po lewej stronie scalaka (np. górne wyprowadzenie kondensatora C51, albo górne lewe wyprowadzenie potencjometru R38) - i zaobserwuje różnicę w wyglądzie prążków.

Wymiana jest możliwa, ale na stację 360k, a ta, którą wkładasz, to 1.2M.

Od razu dementuję - nie jest to prawda.
Nie jest prawdą, że wersja SECAM produkuje pseudo-kolor z sygnałów luminancji PAL-owskiego GTIA.
W rzeczywistości jest tam inny generator obrazu, FGTIA, zawierający cyfrową część enkodera SECAM. Na płycie znajduje się część analogowa - przetwornik D-A i modulator. Liczba dostępnych kolorów (128) jest mniejsza od wersji PAL (256) za sprawą braku najmłodszego bitu luminancji, wykorzystywanego tylko w tzw. trybach GTIA.

Po mojemu można by było tak:
1. Generator z pętlą fazową 16*4,433MHz
2. Czterobitowy licznik binarny, taktowany sygnałem z generatora i zerowany narastającym zboczem sygnału 4,433MHz
3. Poczwórny przerzutnik typu D, do którego wpisywany byłby stan w/w licznika narastającym zboczem sygnału koloru z GTIA
4. Dekoder przekształcający stany 0...15 na wyjściu przerzutników na odpowiadające im stany linii RGB.
5. Zsumowanie z sygnałem luminancji (+ewentualna synchronizacja)

Wynik trudno przewidzieć, bo o kolorze decydują różnice czasowe na poziomie czasów propagacji układów TTL.

W porządku. Gdzie mam wpłacić?
Pomyślałem o czymś jeszcze - nie ma tam u Ciebie więcej takich "bambusów", mających na zbyciu trochę sprzętu? Jeśli mi wyjdzie to, co planuję (podwojenie częstotliwości linii, czyli standard VGA i to w znacznie prostszym układzie), może znajdzie się jeszcze paru chętnych.

Zrobione. Zdjęcia i schemat układu można sobie pobrać stąd. Wyszły dość kiepsko, bo odbiornik TV LCD wprowadził zbyt dużo własnej inwencji w obróbce sygnału, a z CRT trudno zrobić poprawne zdjęcia. W rzeczywistości wygląda to lepiej, w szczególności jeśli chodzi o odtwarzanie kolorów (zwłaszcza zawierających zieleń). Drobny grzebień, widoczny szczególnie na granicy kolorów czerwonego i niebieskiego, wynika z niedobranych czasów propagacji w torze bezpośrednim i opóźnionym. Na schemacie rolę tę wypełnia układ U12, którego z lenistwa i pośpiechu nie zamontowałem. Ogólnie największy fragment układu to rejestr przesuwny pełniący funkcję pamięci jednej linii koloru. Kto chce, może spróbować to zrealizować przy pomocy mikroprocesora AVR. Trzeba tylko znaleźć kwarc o częstotliwości 1,5*14,31818MHz (dość trudny do zdobycia) lub podwoić częstotliwość kwarcu 10,7MHz (do kupienia bez trudu). To, co wyjdzie wykorzystać wprost do sterowania procesora (6 cykli zegarowych na cykl koloru akurat wystarcza - odczyt z pamięci [2], zapis do portu [1], odczyt z portu [1], zapis do pamięci [2]), a po podzieleniu przez 1,5 - do taktowania FRED-a (żeby było synchronicznie).
Wartości rezystorów w obwodzie matrycowania sygnałów z grubsza obliczyłem i zastosowałem bez eksperymentalnego dobierania. Efekt jest zadowalający, choć pewnie można byłoby to jeszcze nieco poprawić.

Bitman, sprawdziłeś, ile wyniesie wysyłka?

Tydzień temu osobiście kupowałem. Na placu samochodowym, pierwsza alejka patrząc od strony Kasprowicza. Goście, oprócz złącz, handlują koszulkami termokurczliwymi i najłatwiej namierzyć ich właśnie po workach z tymi koszulkami.
Jest jeszcze inna możliwość. Wysyłkowo:
http://www.tme.pl/katalog/index.phtml
Po lewej stronie: złącza>złącza audio,video>złącza din audio

Ale problem konfliktu adresów na magistrali pozostaje, bo ANTIC nic nie wie o tym, że ma przestać odświeżać pamięć i w cyklach odświeżania nadal będzie wysyłał adres.

Nic nie miał zwarte, po prostu testował zapis z SIO2PC, a tam nie ma linii AUDIO.
Przesłuchy między żyłami kabla łatwo zaobserwować po wykonaniu jakiegokolwiek zapisu na kasetę (np. CSAVE z poziomu BASIC-a). Błąd w systemie operacyjnym powoduje pozostawienie po zakończeniu operacji na linii CLOCK OUT sygnału taktującego 595Hz (oprócz oczywiście 5278Hz na linii DATA OUT), którego harmoniczne przenikają na linię AUDIO IN i przy dołączonym do złacza SIO kablu powodują stały przydźwięk aż do zresetowania systemu lub wykonania jakichś operacji na dźwięku. Jednocześnie linia wyjściowa AUDIO z POKEY-a jest najzupełniej czysta. Wystarczy wyciągnąć wtyczkę z gniazda SIO i przydźwięk znika.

Mikrofon nie będzie potrzebny. Sposób generowania dźwięku przez POKEY okazuje się dość prosty. Podczas odczytu z dyskietki, na wyjściu AUDIO (pin37) pojawia się sygnał prostokątny 1Vpp (Voh=~5V, Vih=~4V). Na każdy wysłany lub odebrany bajt - dziesięć okresów (start, 8 bitów danych, stop) o częstotliwości równej prędkości transmisji (sprawdzałem to przy 19200baud). To oczywiście zbyt wysoka częstotliwość, aby była słyszalna. To, co słychać, to krótka (ok. pół bitu) przerwa na synchronizację generatora, pomiędzy bitem stopu bajtu n, a bitem startu bajtu n+1 (czyli ton o częstotliwości ok. 1800Hz), i, oczywiście, dłuższe przerwy między odbieranymi bajtami 'A'ck i 'C'pl. Nie zauważyłem żadnej zależności między zawartością danych, a generowanym dźwiękiem.
Z odczytem z kasety jest bardzo podobnie - najpierw odbiór dwóch bajtów AAh (ustalenie częstotliwości taktowania - brak dźwięku na wyjściu), potem prawie dokładnie tak samo, jak dla dysku, czyli dziesięć okresów częstotliwości taktowania na każdy odbierany bajt, z synchronizacją generatora każdym kolejnym bitem startu. Amlituda sygnału jest o około połowę mniejsza niż przy odczycie z dysku. Dodatkowo pojawia się (prawdopodobnie losowo - nie zauważyłem jakiejś zależności - na oko z prawdopodobieństwem bliskim 0,5 ) modulacja dźwięku podstawowego częstotliwością 31,666kHz o znacznie większej amplitudzie (łacznie 4Vpp) - ale raczej bez znaczenia dla brzmienia. To, co słychać, to ton podstawowy ~600Hz z nałożoną częstotliwością synchronizacji bajt/bajt - ~60Hz. Okresowa (na blok danych) zmiana brzmienia pochodzi stąd, że dla każdego bloku występuje pewna niedokładność określenia częstotliwości taktowania (nieco inna wysokość tonu podstawowego), a ona z kolei powoduje inną długość przerw na synchronizację bajt/bajt.
Na razie nie stwierdziłem przyczyny nieco innego brzmienia pustego bloku.