Trochę się zeszło, ale w końcu przerobiłem temat. Musiałem samemu oprogramować obsługę formatu WFM.

Tematem było obliczenie przesunięć fazowych na nóżce COL względem podnośnej koloru doprowadzonej na nóżkę PAL. Podnośna ma częstotliwość 4433618,75 Hz (ok. 4,43 MHz). Do analizy wykorzystałem pliki:
5v-pal-2.wfm - zrzut sygnałów PAL i COL z linii 32
5v-pal-1.wfm - zrzut sygnałów PAL i COL z linii 33
7v-pal-1.wfm - zrzut sygnałów PAL i COL z linii 32
7v-pal-2.wfm - zrzut sygnałów PAL i COL z linii 33
9v-osc-1.wfm - zrzut sygnałów OSC i COL z linii 32
9v-pal-2.wfm - zrzut sygnałów PAL i COL z linii 33

Po pierwsze, nazwy plików 5v-* były zamienione. Po drugie, brakowało prawidłowego pliku 9v-pal-1.wfm. Na szczęście plik 9v-osc-1.wfm na końcu zawiera zrzut colorbursta z następnej linii - pozwoliło mi to odtworzyć brakujące przesunięcia fazowe.

Oto poglądowy wykres obrazujący jak PAL GTIA opóźnia sygnał PAL:

Oś pozioma to poszczególne chrominancje: e1, e2, ..., eF - chrominancje $1..$f w linii parzystej; o1, o2, ..., oF - chrominancje w linii nieparzystej. Oś pionowa to opóźnienie; jednostką jest tutaj długość pełnego cyklu podnośnej koloru, czyli 1/(4,43 MHz) = ok. 255,55 ns.

Np. wartość 0,6 w kolumnie e7 oznacza, że sygnał na nóżce COL dla chrominancji $7 w liniach parzystych przy napięciu 7V na nóżce DEL jest opóźniony w stosunku do sygnału na nóżce PAL o 0,6/(4,43 MHz) = ok. 135,77 ns.

Na wykresie nie widać, ale opóźnienie sygnału colorbursta jest równe opóźnieniu chrominancji $1: e1 w liniach parzystych, o1 w nieparzystych.

Od razu widać, że GTIA różnie opóźnia sygnały dla tej samej chrominancji w liniach parzystych i nieparzystych. Nie dziwota, tak ma być w systemie PAL.

Ogólny wzór na opóźnienie jest następujący:
PAL_DELAY(hue) = 95,2 ns + ADD(hue)*100,7 ns + MULT(hue)*X
gdzie
ADD(hue) może być 0 lub 1,
MULT(hue) może być 0, 1, 2, ..., 7,
X zależy od napięcia na nóżce DEL.

Przyporządkowanie parametrów ADD i MULT jest z grubsza dowolne - inaczej niż w NTSC, gdzie wzór na opóźnienie wygląda mniej więcej tak:
NTSC_DELAY(hue) = 150 ns + hue*X

Zależność między napięciem na nóżce DEL a opóźnieniem X jest nieliniowa - dla danych punktów pomiarowych wynosi ok.:
17.37 ns dla 5V,
10.60 ns dla 7V,
7.44 ns dla 9V.
Może jest to zależność logarytmiczna, może kwadratowa - nie wiem, elektronikiem nie jestem, nie znam się. Może ktoś z Was kto się zna na tranzystorach, wie, jak takie opóźnienie jest fizycznie zrealizowane, i mi podpowie.

Wygląda to tak, jakby układ miał 7-elementową linię opóźniającą (regulowaną napięciem na DEL) i jeszcze dodatkowy element, który opóźnia sygnał o 100,7 ns (albo o 1/(4,43 MHz) - 100,7 ns; trudno powiedzieć które opóźnienie jest bazowe względem którego). Ciekawostka - na oscylogramach widać, że kształt fali dla chrominancji, które "przechodzą" przez ten dodatkowy element opóźniający, jest inny niż dla pozostałych chrominancji - wygląda jakby był odwrócony w pionie.

Widać że w implementacji kodowania PAL panowie poszli na łatwiznę. Według standardu przesunięcie fazowe między colorburstami w liniach parzystych i nieparzystych powinno być dokładnie 90°. W GTIA zależy ono od napięcia na nóżce DEL. Niesie to za sobą interesujące konsekwencje:
1. Telewizor w każdej linii odtwarza oryginalną podnośną koloru poprzez zsumowanie colorburstów z ostatnich dwóch linii (parzystej i nieparzystej). Jak pamiętamy z matematyki ;-) sumowanie dwóch sinusoid o tej samej częstotliwości i amplitudzie lecz o różnych fazach daje w wyniku sinusoidę, której amplituda jest zależna od przesunięcia fazowego między składowymi sinusoidami. Ponieważ amplituda podnośnej jest używana jako punkt odniesienia dla nasycenia kolorów, efekt jest taki że regulując napięcie na nóżce DEL zmieniamy nie tylko wewnętrzne opóźnienia, ale też nasycenie kolorów.

2. Dając odpowiednio niskie napięcie na DEL (niższe niż 5V) możemy doprowadzić do tego, że przesunięcie fazowe między colorburstami "parzystymi" i "nieparzystymi" wyniesie nawet 180°. W takiej sytuacji telewizor nie potrafi już odróżnić linii parzystych od nieparzystych - mój odbiornik wtedy przestaje w ogóle interpretować sygnał koloru i wyświetla obraz czarno-biały.

3. Dając jeszcze niższe napięcie możemy doprowadzić do przesunięcia między colorburstami większego niż 180°. Wtedy telewizor zaczyna interpretować kolory "odwrotnie" - linie nieparzyste traktuje jak parzyste i na odwrót.

W każdym razie - analiza pozwoliła dokładnie odtworzyć sposób generowania koloru przez PAL-owski GTIA. Implementacja trafiła właśnie do Atari800. Wyżej wymienione 3 "interesujące konsekwencje" zostały zaimplementowane, ale jednej rzeczy wciąż brakuje - paleta emulatora ma nadal tylko 256 kolorów, uśrednionych na podstawie wyliczeń dla linii parzystych i nieparzystych. Nie da się wyświetlić więcej niż 256 kolorów tak jak potrafi to prawdziwe GTIA. Taka zmiana wymagać będzie poważniejszego przeorania emulatora - nie wiadomo ile to zajmie.

Wielkie dzięki dla Willy'ego!

Dziękuję. Schemat nie będzie potrzebny - Twoje wyjaśnienia są lepsze. Tylko pytanie, czy 5. dostęp pod $D5 powoduje ponowne włączenie kartridża, czy też po 4. dostępie kartridż wyłącza się "na zawsze" i trzeba wyłączać/włączać komputer? Z tego co napisałeś, o ile dobrze rozumiem, wynika to drugie.

EDIT:

Atari800 też wspiera, wzorowałem się na Altirrze. Niedłuo wydanie nowej wersji.

Nie każdy, kto gada o ... piłce nożnej jest namiętnym futbolistą. Ja np. nie uważam Cię za tępego gimbusa tylko dlatego że ripostujesz rodem ze szkolnej ławki.

Bujasz, Sikor. WKC było wydane w jednej tylko wersji, całodyskowej, która nie używała XE RAM. Tak samo IK, które miało jedno wydanie na dyskietce i jedno na kasecie. Reszta to piraty.

Z gier które używają XE RAM ale też działają bez niego, to jeszcze Bop'n'Wrestle (na 130XE nie doczytuje notorycznie grafiki postaci podczas gry), i Artefakt przodków (muzyka na 130XE).

Bry,

Też wpadnę.

Wielkie dzięki! Za parę dni zabiorę się za analizę, i wtedy powiem coś konstruktywnego.

Póki co zwrócę tylko uwagę, że coś chyba pomieszałeś z plikami - 7v-pal-1 i 9v-pal-1 są identyczne.

9 woltów? GTIA.PDF mówi, że napięcie na DEL powinno być od 3 do 8. Albo źle rozumiem, albo coś sobie spalisz :-)

Dziękuję za udostępnienie wyników.

Żadne dziwactwo - z tego co wiem, w PAL faza bursta w liniach z "odwróconą fazą" jest o 90° opóźniona w stosunku do linii "zwykłych" - tylko dzięki temu odbiornik odróżnia linie zwykłe od "odwróconych".

Niezupełnie. W liniach PAL faza chromy jest nie przesunięta o 180°, lecz "odwrócona w czasie" -  w sensie takim, że jej przesunięcie powoduje zmianę barwy w "odwrotną" stronę niż w liniach zwykłych.

To nie tak. Opóźnienie jest zależne od napięcia przyłożonego do nóżki DEL, a w konsekwencji - od ustawienia potencjometru regulacji koloru. Przy czym w service manualach do komputerów NTSC można wyczytać, że prawidłowym ustawieniem jest takie, w którym kolory 1 i 15 są identyczne. Odpowiada to opóźnieniu ok. 19,95ns pomiędzy każdymi dwoma kolejnymi kolorami.

W PAL jest tak samo - potencjometrem reguluje się opóźnienie. Tylko że zależności są bardziej skomplikowane; w szczególności nożka DEL daje różne opóźnienia dla kolorów w liniach parzystych i nieparzystych. Algorytm będący zgrubnym przybliżeniem rzeczywistości wrzuciłem w tym poście (Altirra fazy kolorów wylicza bardzo podobnie).

Domyślam się, że podczas swoich badań nie dotykałeś się do potencjometru koloru. Szkoda, bo byłoby to dla nas niezwykle pouczające.

Skoro piszesz, że w razie potrzeby możesz powtórzyć analizę, to mam do Ciebie prośbę: tutaj taki oto programik, który wyświetla 2 linie (parzystą i nieparzystą), w każdej wyświetla wszystkie 15 chrominancji. Czy mógłbyś zrobić z tych 2 linii oscylogram taki jak wcześniej załączyłeś? Ale nie jeden, tylko wiele, każdy przy innym ustawieniu potencjometru koloru - od jednego ustawienia krańcowego do drugiego. Pozwoli mi to być może na odtworzenie dokładnego algorytmu generowania kolorów. W NTSC to zostało już zrobione dawno, w PAL jeszcze nie.

10 GRAPHICS 11
20 FOR I=0 TO 14:COLOR I+1
30 PLOT I*5,0:DRAWTO I*5+3,0
40 PLOT I*5,1:DRAWTO I*5+3,1
50 NEXT I
60 GOTO 60

Dlaczego tak jest najlepiej?

Możliwe, że w monitorze dpilawa uśrednianie jest po prostu źle wyregulowane. Service manual opisuje procedurę regulacji PAL delay line, powinno wystarczyć skalibrowanie.

O! A kręciłeś podczas badania potencjometrem? To mnie najbardziej w tym wszystkim interesuje, jak regulacja wpływa na sygnał.

A ja mam na to własną hipotezę:

PAL-owski GTIA generuje różne kolory w parzystych i nieparzystych liniach. Normalnie to nie jest widoczne, bo PAL-owskie telewizory mają układ uśredniający chrominancję każdych 2 kolejnych linii. Wystarczy jednak wyświetlić obraz na którym sygnał chrominancji jest wyłączony w co drugiej linii, aby owo uśrednianie przestało mieć znaczenie.

Polecam Wam uruchomić programik z podlinkowanego postu. Wyświetla on wszystkie 15 chrominancji, z tym że na lewej połowie włączone są tylko nieparzyste linie ekranu, a na prawej tylko parzyste. Barwa niektórych chrominancji jest inna po lewej stronie niż po prawej! Sądzę że będzie to widoczne na każdym telewizorze - ja obserwuję to nawet przy połączeniu przez RF. (Dodatkowo namawiam do pokręcenia potencjometrem regulacji kolorów, tym od spodu, żeby wzmocnić efekt.)

Wracając do PAL-owskiego uśredniania chrominancji - zostało ono wprowadzone aby wyeliminować wadę systemu NTSC, w którym zakłócenia w eterze powodowały zmianę barwy transmitowanego obrazu. Rzecz w tym, że ta funkcja ma sens jedynie przy odbiorze sygnału telewizyjnego "z powietrza" - przy transmisji po krótkim kablu, jak w przypadku połączenia komputer-monitor, takie zakłócenia nie występują.

Możliwe więc hipotetycznie, że np. Twój monitor nie ma wbudowanej funkcji uśredniania chrominancji, bo po co. Dzięki temu na ekranie widoczne są prawdziwe kolory produkowane przez GTIA.

Apropos, czy ma ktoś z Was dostęp do wektorskopu? Chciałbym kiedyś sprawdzić, jak właściwie wygląda sygnał koloru z wyjścia monitorowego, i pomierzyć dokładnie jakie barwy produkuje PAL-owski GTIA.

Dump tego kartridża jest już na mojej "liście wszystkich kartridży", na poz. z CRC 67d2d2e0. Ale dumpa i tak warto zrobić:
1. Nigdy nie wiadomo, czy Twój kartridż nie jest przypadkiem jakąś inną wersją różniącą się niewidocznymi szczegółami,
2. A nawet jeśli jest taki sam, to posiadanie 2 niezależnych dumpów pozwoli zweryfikować ich poprawność.

Zrób dumpa, proszę.

EDIT: Przyjrzałem się skrinszotowi. Twój kartridż jest jednak inny od tego już znanego.

EDIT2: Fota etykiety jest niewyraźna. Tam jest MINI-SOFT, MINE-SOFT, czy MINC-SOFT?

OT: Richard Munns pisał w bejziku. Dokładniej w TBXL, przy czym utwory w postaci źródłowej, odtwarzane pod BASIC-iem, grały wolniej niż docelowo w ASM - najwyraźniej mistrz sobie w głowie je przyspieszał podczas tworzenia :-)