Ale przecież nieprawda.

Przecież sto razy było wyjaśnione, że obie funkcje umożliwiają cytowanie całości lub fragmentu.

Plotki, plotki, plotki! Zajrzyjcie do następnego numeru MICRO, na stronę 5.

Nie wiem czy jasno się wyraziłem. Chodziło mi o to, że zarówno Reply jak i Quick Quote obsługują sytuację i z zaznaczeniem i bez niego, a różnią się jedynie tym, gdzie "wysyłają" wybrany post lub zaznaczony fragment postu (Reply do nowej strony, QQ do pola pod spodem). Wskazywałem zaś problem w tym, że tłumaczenie (poprzednie, ale obecne również) nie wyjaśnia, czym obie funkcje się różnią, a wręcz sugeruje, że różnią się czymś innym niż w rzeczywistości. Np. "Cytuj cały post"  i "Odpowiedz" sugerować mogą, że:
a) tylko jedna z funkcji pozwala zacytować cały post (nieprawda, jeśli nie zaznaczy się fragmentu postu, Quick Quote również cytuje cały post),
b) jedna z funkcji nie ma nic wspólnego z cytowaniem.
W rzeczywistości funkcje różnią się wyłącznie tym, że jedna z nich nie używa pola "Szybka odpowiedź", i tłumaczenie powinno odzwierciedlać tę właśnie różnicę.

To już zależy od wybranej przez software struktury zapisywanych danych. Sprawdź w Atariki.

A czy ja mówię, że to było jakieś epokowe odkrycie, czy co?

Zgadzam się że nie jest to bubblegum pop, ale pamiętam że bodajże Alley Cat (ale to w innym turbo) miał kilka bardzo rytmicznych sekcji.

A tak na poważnie, to można przyspieszyć częstotliwość zegara na ten moment w którym transmitowane są bity startu/stopu, tak aby zmniejszyć ich długość prawie do zera, ale nie spodziewam się żeby to było praktyczne wyjście. Innego sposobu na usunięcie bitów startu/stopu nie ma.

EDIT: A, i jeszcze można użyć bitu 7 SKCTL, żeby na chwilę wymusić nadawanie logicznego 0 zamiast czegokolwiek, co jest akurat transmitowane (np. bit stopu).

E tam epokowe. W ten sposób już przed ponad 20 laty nagrywała swoje albumy chorzowska kapela Turbo Blizzard.

Akurat wersja, o której mówisz, voy, tych nowości nie zawiera.

Atari, Inc. wpierw pracowało nad wersją OS-a Rev. 4v0, która miała m.in. obsługę szybkiego SIO oraz usuniętą obsługę ładowania handlerów nowych urządzeń podczas startu (Peripheral Handler Loading Facility). IMO dziwna decyzja, skoro system był przeznaczony m.in. dla 1450XLD, który chyba potrzebował tej funkcji do obsługi swoich wbudowanych stacji dysków. W każdym razie tej wersji dotychczas nieodnaleziono.

Potem, już za króla Tramiela, ale pewnie tylko siłą rozpędu, powstała Rev. 5v0, w której wycięto obsługę szybkiego SIO, a także całą obsługę PBI. To miała być wersja dla 900XLF, które, jak wiemy, szyny PBI nie miało. To jest właśnie ta wersja, do której znaleziono źródła.

Koniec końców Atari już Corp. się ze wszystkiego wycofało, a w sprzedawanych 900XLF wylądował OS Rev. 1v2 znany z 800XL.

Ja tam nie wiem, ale może w DOS-ie 4.0 ostały się jakieś ślady obsługi 38400 bps? Tu są źródła do jednej jego rewizji.

Mhm, tylko że nie <edit>firma</edit> Atari i nie w 1977.

Przecież to to samo, tylko podawane w różnych zaokrągleniach. Dokładna wartość to 4433618,75 Hz.

Oho, a ja nawet nie wiedziałem że jest jakiś limit. Nie widzę żeby forum gdziekolwiek mi pokazywało ile zostało do przekroczenia limitu. A przydałoby się.

uicr0Bee, wysłałem Ci testowo PW, nic się nie pokazało, PW wylądował w Wysłanych jako nieprzeczytany.

EDIT: A nie, nieprawda, po "wejściu" w wysłaną wiadomość widnieje komunikat: "The message status is 'sent'. It means that the message has not been delivered yet because either the receiver has not visited forum since you sent this message or receiver's Inbox is overfilled. You can still edit this message or cancel its sending."

Rozumiem z tego, że wiadomości które nie zmieściły się w Inboksie pozostają "nieprzeczytane" póki nie opróżnisz Inboksa, co powinno spowodować dostarczenie ich do Ciebie.

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!