1 i 2.
a) Zapis turbo działa na zupełnie innej zasadzie (PWM) niż normal (FSK). Modulacja PWM jest znacznie prostsza, więc bardziej niezawodna, sygnał jest w znacznie mniejszym stopniu przetwarzany przez magnetofon i w mniejszym stopniu zależy od jakości elektroniki.
b) tak jak napisał mono - bezpośredni związek z bugiem w OS. Procedury odczytu turbo są od niego niezależne.
c) pośredni związek z bugiem w OS - przy pewnych szczególnych prędkościach bug manifestuje się znacznie cześciej
d) pośredni związek z bugiem w OS - przy pewnych szczególnych odstępach pomiędzy blokami danych bug manifestuje się znacznie częściej - tak jak by następowała swoista synchronizacja sygnału z taśmy z wyświetlaniem obrazu, tzn. odstęp pomiędzy ostatnim bitem poprzedniego bloku i pierwszym następnego potęguje efekt do tego stopnia, że błąd może występować zawsze w tym samym miejscu nagrania
e) sposób działania Pokeya - według dokumentacji Pokey potrafi odczytywać dane z prędkością do 5% większą niż aktualnie ustawiona, nie ma słowa o odczytywaniu z prędkością niższą niż aktualnie ustawiona. W związku z tym są pewne szczególne graniczne wartości prędkości, przy których najmniejsze wahnięcie obrotów magnetofonu w dół (czy rozciągnięcie taśmy itp.) może powodować błąd; może się też zdarzać, że obliczana prędkość transmisji jest kwalifikowana do błędnego przedziału i Pokey jest programowany na prędkość wyższą niż powinien być (taka łagodniejsza wersja buga w OS). Nawet 1 baud różnicy w prędkości transmisji może mieć znaczenie. Natomiast zapis turbo nie korzysta ze sprzętowej obsługi transmisji Pokeya, jest od tego niezależny.
3.
a) w normalu - po zgraniu przekonwertować na .hex, w edytorze tekstowym pousuwać śmieci, ustawić modelową prędkość transmisji (594-595 baud, źródła podają równe 600). Po poprawkach przekonwertować na wav. Nawet wtedy będzie od czasu do czasu występował błąd związany z bugiem w OS.
b) w turbo - istotne jest dobre ustawienie skosu głowicy przy zgrywaniu, zwykle trzeba ustawić tak, żeby sygnał był najsilniejszy, jeszcze istotniejsze jest, żeby kształt fali był jak najbardziej zbliżony do fali prostokątnej (choć w przypadku większości nagrań będzie bardziej podobny do sinusa), dobrze też jeżeli amplitudy wąskich i szerokich impulsów są do siebie zbliżone. Prędkość przesuwu taśmy jest dość istotna, bo większość systemów turbo (w tym turbo 2000) nie ma programowej kompensacji zmian prędkości (nie pamiętam teraz, czy poza Blizzardem jakiś system turbo ma - no jest jeszcze Sistema Injektor, ale to jeszcze inny rodzaj zapisu).
c) turbo - po zgraniu przekonwertować na hex, w edytorze tekstowym pousuwać śmieci, poustawiać odpowiednie szerokości impulsów itp. Po poprawkach przekonwertować na wav.
4.
a) W przypadku turbo i adapterów bardzo ważna jest siła sygnału - nie może być ani za mała, ani za duża. Trzeba dobrać eksperymentalnie. Zwykle lepiej ustawić ciszej niż dla normal.
b) Dla wielu systemów turbo istotna jest polaryzacja sygnału, tzn. czy impuls zaczyna się od zbocza narastającego czy opadającego. Nie pamiętam w tej chwili na pewno, ale Turbo 2000 chyba powinno być od tego w jakimś stopniu niezależne, natomiast odwrócenie polaryzacji może w każdym przypadku i tak pomóc lub zaszkodzić. Dość ważna jest szerokość ostatniego półimpulsu przed pierwszym impulsem synchronizującym, która to połówka ma tendencję do bycia skróconą i rozpoznawaną jako pierwsza połowa impulsu synchronizującego. Jak nagranie się nie wczytuje, to warto w edytorze audio spróbować zrobić inwersję sygnału. Polaryzacja może się zmieniać w wielu miejscach (przy zgrywaniu, przy odtwarzaniu z komputera, w adapterze kasetowym, w magnetofonie Atari...)
c) w pewnym stopniu ważna jest prędkość przesuwu taśmy przy zgrywaniu, co za tym idzie wynikowa szerokość impulsów.
5.
a) http://a8cas.sourceforge.net/ (tylko normal, bo a8cas-convert obsługujący turbo mam chyba tylko ja, nie upubliczniałem bo nie dokończyłem przeróbek)
b) http://www.arus.net.pl/FUJI/a8cas-util/ (normal i turbo, tylko pod linuksa)

P.S. Część moich twierdzeń jest wydedukowana na podstawie obserwacji i nie potwierdzona badaniami ;).

Analizowałem takie nagrania TurboROM dawno temu. Wygląda to tak:
- suma kontrolna JEST obliczana i kontrolowana, psucie pliku cas zepsuje wczytywany program, choć przy pewnej dozie szczęścia może nie zepsuć sumy kontrolnej
- suma kontrolna jest liczona ze wszystkich bajtów całego bloku turbo (o ile pamiętam po prostu xor)
- prawidłowa suma kontrolna jest przechowywana w loaderze, nie w bloku turbo
- nie można sumy kontrolnej wyciągnąć wprost z loadera, bo cały loader jest "zaszyfrowany" (o ile pamiętam dwukrotny xor). Ja po prostu uruchamiam wczytywanie pod emulatorem i znajduję odpowiedni bajt pod debuggerem. Pewnie gdzieś na biurku wala mi się kawałek papieru, na którym mam zapisane, który to bajt (spotkałem się z dwiema wersjami loadera)
- blok turbo jest wczytywany jak leci i poza liczeniem sumy kontrolnej nie jest sprawdzane nic innego (np. loader nie wie, ile bajtów ma wczytać)
- warunkiem koniecznym i wystarczającym do zakończenia wczytywania jest wystąpienie błędu odczytu (zbyt długiego lub zbyt krótkiego impulsu)
- po błędzie odczytu sprawdzana jest suma kontrolna. Jeżeli jest OK, to program jest uruchamiany, jeżeli nie, to ponownie uruchamia się odczyt
- w związku z powyższym nagranie idealne, czyli takie, w którym ostatni impuls nagrania odpowiada ostatniemu bitowi danych nigdy nie skończy się wczytywać
- ten typ nagrań był głównym powodem, dla którego przy dorabianiu zapisu turbo w emulatorze atari800 dodałem tworzenie sztucznych zakłóceń na końcu zapisu każdego nagrania turbo (paru niewymiarowych impulsów po wyłączeniu silnika magnetofonu); takie zakłócenia w niczym nie przeszkadzają, a pomagają w tym i w jeszcze jakimś jednym przypadku

Jak by co to ja też mogę pomóc. W zasadzie to może mogę pomóc zaoszczędzić czas na dumpowanie i skanowanie, bo mam sporo kaset i większość jest już zarchiwizowana. @uicr0Bee - masz jakiś spis ? Albo mogę Wam podesłać na priv swój spis.

Wersja nieoficjalna usunięta. Sposób użycia opcji "pilot" został zmieniony ze względu na dodaną możliwość ustawiania opcji dla każdego pliku wejściowego oddzielnie. Od wersji 1.03 trzeba tak:

a8cas-util.pl conv --title Programik loader.bin:pilot=18000 program.xex:pilot=2000 data.bin program.cas

AtariX, jeżeli nie jesteś zainteresowany wypróbowaniem a8cas-util pod linuksem (wbrew temu co napisał voy dekodowanie nagrań turbo to chyba główna funkcja a8cas-util), to się nie będę tu wtrącał ;), w przeciwnym razie też służę pomocą. Dekodowanie Blizzarda jest dobrze przetestowane.

Odpowiadając na wcześniejsze pytania:
1. istniejące narzędzia są rozwijane od lat, więc raczej szkoda poświęcać czas na tworzenie nowych od zera, co nie znaczy że z odpowiednimi umiejętnościami nie można stworzyć czegoś lepszego
2. opis formatu Blizzard (budowy nagrania) na atariki  powstawał m.in. na podstawie analizy kodu handlera (liczyłem cykle zegara dla pętli odmierzających szerokości impulsów). Niemniej, jak tam jest wspomniane, w pewnym zakresie możliwe są odchylenia parametrów czasowych, handler dostosowuje się do rzeczywistej prędkości transmisji używając pierwszego (tego długiego) sygnału pilotującego
3. format z $FFFF na początku chyba nie nazywa się nijak oficjalnie, na atariki nazywa się Binarny plik DOS-u
4. do taśm w normalu narzędzia a8cas Krótkiego, a8cas-util (a jakże), albo legendarny wav2cas do prostych przypadków. Z tego co słyszałem Turgen też w jakimś stopniu obsługuje normal (nie próbowałem).
5. ... czasem mimo wszystko trzeba się pomęczyć.

Szumy w sygnale w przypadku nagrań turbo odgrywają marginalną rolę (w normalu zresztą też), w zasadzie moim zdaniem w ogóle nie trzeba się tym przejmować. Przerobiłem mnóstwo nagrań w normalu i różnych formatach turbo, i praktycznie nie korzystałem z opcji do obcinania szumów, którą dorobiłem na początku zmagań z a8cas-util.

Powody błędów dekodowania mogą być różne:
- uszkodzenia taśmy, miejscowe osłabienie sygnału lub całkowite zaniki sygnału na odcinku pojedynczych bitów
- chwilowe przesterowania sygnału (też na odcinku pojedynczych bitów)
- zbyt duża różnica w prędkości odtwarzania w stosunku do prędkości nagrywania; Turgen jest tu dość elastyczny, bo pozwala łatwo definiować własne zestawy opisujące szerokości impulsów - wystarczy w edytorze audio policzyć sample dla każdego typu ipulsu (pilot, zero, jeden) i utworzyć plik konfiguracyjny
- zniekształcenia sygnału, spowodowane np. różnicą w ustawieniu głowicy przy nagrywaniu i odtwarzaniu (bity "0" odpowiadające wyższej częstotliwości mogą być znacznie osłabione) lub wadami elektroniki; np. zdarza się że szerokie impulsy (pilot, jedynka) zyskują dodatkowe "brzuchy", które mogą być dekodowane jako bity '"zero" (zwykle duże wzmocnienie to kompensuje, ale z drugiej strony duże wzmocnienie może zepsuć coś innego)
- zniekształcenia wytwarzane przez filtry używane przez program dekodujący (np. za duże wzmocnienie, podbicie/wygaszenie niewłaściwych częstotliwości)
- suma kontrolna liczona według algorytmu innego niż standardowy (np. xor zamiast modulo256)

Blizzard jest jednym z najszybszych systemów turbo, przy częstotliwości próbkowania 48kHz różnia w szerokości impulsów "0" i "1"  wynosi tylko kilka sampli, jest to więc dość czułe na nierównomierności prędkości przesuwu taśmy. Samplowanie na 96kHz może dać lepsze rezultaty, ale nie musi, natomiast sam proces dekodowania przy 96kHz działa lepiej niż przy 48kHz (przynajmniej w a8cas-util, jest programowo resamplowane).

Jeśli chodzi o samo zgrywanie kaset do wav to też nie ma uniwersalnej recepty. Czasem lepiej wychodzi, jak się sygnał przesteruje, żeby wyszła fala prostokątna, czasem o wiele lepiej jest zgrać tak, żeby nie tknąć wierzchołków fal, czasem jest lepiej ustawić dość cicho. Każdy przypadek może wymagać użycia różnych filtrów przy dekodowaniu i innych algorytmów przy resamplingu do wyższych częstotliwości (z interpolacją lub bez).

Coś takiego miałem dorobić dawno temu, ale motywacji brak...
Od dzisiaj można tak:

a8cas-util.pl conv --title Programik loader.bin program.xex program.cas

Przerwy na wywołania init (jeszcze) nie są wspierane.

A może to  w załączniku ?

Nie wiem, czy się da tak łatwo przekonwertować, raczej nie automatycznie - albo trzeba zmieniać kod programu, albo podmienić handler C: (o ile program z takowego korzysta) - ale tu z kolei nie wiadomo, gdzie by było bezpieczne miejsce dla handlera. Mam kasetę Blizzarda z grą "Władcy Ciemności", ale też jest zrobione tak, że w turbo ładuje się tylko początek, a to co najdłuższe i tak idzie w normalu.

Z wieloczęściowych rzeczy w  pełni blizzardowych znalazłem tylko "Winter Olympiad". Wygląda tak, jak by było specjalnie przerobione na Blizzarda, nawet dźwięki przy wczytywaniu wydaje trochę inne niż standardowe loadery. Do ściągnięcia tu: http://www.arus.net.pl/FUJI/files/Atares_BL_29_A.wav. Zaczyna się od początku taśmy. Ładuje się microloaderem.

Masz całkowitą rację. Chyba nie tędy droga. przydało by się wcisnąć kilka dodatkowych instrukcji, tylko najpierw miejsce trzeba by na nie znaleźć...

Oj, pod emulatorem by wiele zmieniło :P.

Problem jest przede wszystkim tu:

; Zapisz aktualne VCOUNT i RTCLOK+2 w TIMER1, TIMER1+1
        LDX     VCOUNT          ;vertical line counter
        LDY     RTCLOK+2        ;low byte of VBLANK clock

Gdyby pomiędzy tymi dwoma instrukcjami były inne, których wykonanie zajmie minimum 12 cykli maszynowych, błąd powinien zniknąć. Sądzę, że poprzesuwanie instrukcji tak:

; Zapisz aktualne VCOUNT i RTCLOK+2 w TIMER1, TIMER1+1
        LDX     VCOUNT          ;vertical line counter
        STX     TIMER1
        STA     SAVIO           ;save serial data in
        LDX     #1
        STX     TEMP3           ;set mode flag???
        LDY     RTCLOK+2        ;low byte of VBLANK clock
        STY     TIMER1+1        ;save initial timer value
        LDY     #10             ;10 bits

mogło by pomóc. Pomiędzy "LDX VCOUNT" i "LDY RTCLOK+2" było by 4+4+2+4=14 cykli, a raczej niczego się nie popsuje.

W sumie nie problem sprawdzić....

Edit:
Efekt jest jakby połowiczny, zamiast dwóch różnych błędnych wartości dostaję teraz tylko jedną (8258), więc jak można było podejrzewać, chyba trzeba by też coś zrobić z tym:

; Po 10 zmianach sygnału, zapamiętaj aktualne VCOUNT i RTCLOK+2
        LDA     VCOUNT          ;???
        LDY     RTCLOK+2        ;???

Ale to już nie dzisiaj.

A dlatego (właściwie powninno być "Atar-Hit"):