FUJI, generalnie się zgadzam. Zastanawiałem się nad tym, i rzeczywiście, możliwość obsługi nowych formatów turbo bez modyfikacji kodu jest zaletą, która ostatecznie mnie przekonała do takiego rozwiązania.

Parę uwag:

1. Patrząc po źródłach Turgena, widzę że Czesi wymyślili system turbo do odczytu z płyt CD, gdzie długość sekwencji "niski-wysoki" wynosi dokładnie 2/44100 s, czyli po prostu 1 próbka < 0 i 1 próbka > 0. Zatem może należałoby nie ustalać odgórnie, że jednostką są setne ms, tylko dodać do bloku "pwms" parametr określający "częstotliwość próbkowania".

Np. mamy Blizzard, gdzie są sygnały 0.5 ms, 0.25 ms i 0.166 ms. Ustalasz "częstotliwość" na 12000 (czyli 1/12 ms) i potem defniniujesz wszystkie długości sygnałów na podstawie tej wartości. Sygnały w Blizzardzie wtedy mają długość odpowiednio 6, 3 i 2 próbek.

A Czesi ustawiają dla tej swojej płyty CD "częstotliwość" 44100 i wszyscy są zadowoleni.

2. Czy w nagraniach turbo występują bity startu i stopu? Jeśli nie zawsze, to przydałby się typ bloku analogiczny do "pwmd", reprezentujący dane bez tych bitów.

3. Wstrzymałbym się z wprowadzaniem do formatu hacków specyficznych dla Turbo ROM (aux1=00 i 11), póki nie rozgryziemy software'u do jego obsługi. Może te nieregularne długości impulsów są wynikiem błędu w procedurze nagrywającej, a software radzi sobie z odczytem nawet gdy zapoda mu się plik ze sztucznie wyrównanymi długościami impulsów?

4. Skoro blok "pwms" będzie występował w obrazie taśmy raczej tylko raz, to może nie warto ograniczać długości pola "liczba impulsów pomiędzy pilotem i danymi" do 2 bitów?

5. Co to znaczy IRG w przypadku bloków "pwmd" i "pwmi"? Chcesz tam trzymać długość ciszy przed rekordem?

6. Długości sygnałów w bloku "pwmi" też trzymałbym nie w setnych milisekund, ale w jednostkach definiowanych przez jakąś liczbę umieszczoną na początku bloku - analogicznie do uwagi nr 1.

A'propos wersjonowania CAS-ów - numer wersji zwiększałbym tylko gdy zachodzi zmiana w formacie bloku. Dotychczas wprowadzamy tylko nowe typy bloków, więc wersja może pozostać 0 - istniejące implementacje obsługi formatu CAS i tak powinny domyślnie ignorować bloki, których typu nie rozpoznają.

Podrzucę inne nagrania AST jak będę miał czas, za parę tygodni - ale generalnie nie należy się spodziewać rewelacji; bloki w AST-owskich formatach AST, BUT i BOT mają taką samą strukturę jak w dostępnym przykładzie.

Mam też kasetę w formacie "jakiegoś" Turbo 2000, to też się podzielę.

No, a w przyszłości także definicje 3D pudełek i akcesoriów. Ale to akurat nie jest specyficzne dla Atari, więc wydzieliłbym to na osobny, "ogólnoemulatorowy" projekt.

:)

A tak całkiem poważnie, to może byśmy zaczęli dyskusję nad formatem tego ZIP-a już teraz? W niczym to nie zaszkodzi. Być może powstanie jakaś konkretna specyfikacja formatu, którą będzie można "na sucho" zastosować np. w bazie gier na Atarionline czy Atarimanii, jeszcze zanim dojdzie do implementacji obsługi tegoż formatu w emulatorach.

A czemu miałaby się nazwa nie przewijać, np. automatycznie? Przecież urządzenie jakoś musi sobie radzić także z długimi nazwami plików CAS. Jak sobie np. radzi z tym SIO2SD?

Dyskietki nie możesz rozciąć na pół żeby nadal działała, a z taśmą możesz to zrobić. Lepiej traktuj CAS nie jako format archiwizacji kaset, ale jako format archiwizacji programów z taśm.

A niby dlaczego miałbyś tak robić, skoro zdrowy rozsądek podpowiada inaczej? Chyba tylko z sentymentu, ale skoro tak, to chyba lepiej żebyś nie miał możliwości przewijania inaczej niż po blokach, żeby było to bliższe pracy z rzeczywistym magnetofonem ;)

No nie bardzo, bo czasem są programy składające się z kilku części które ładują się jedna po drugiej automatycznie - czyli użytkownik na załadowanie kolejnego pliku CAS miałby kilka sekund zanim ładowanie się wysypie.

To wtedy ładujesz sobie do emulatora plik CAS z obrazem drugiej strony kasety. Tak samo przecież robisz z obrazami dyskietek.

W ogóle ten problem powinien zostać rozwiązany w sposób jednolity dla dyskietek i kaset - powinna być możliwość jakiegoś grupowania kilku obrazów taśm/dyskietek w archiwa z możliwością łatwego przełączania pomiędzy nimi.

?!? czyli jak nie dodamy nowych typów bloków to będzie mniejsza rezerwa na przyszłość?

Wgrałem właśnie nową wersję A8CAS - poprawiłem m.in. zgłoszony przez FUJI błąd z Feudem. Dodatkowo możecie sobie potestować ładowanie taśm w turbo AST pod emulatorem.

Należy założyć że SIO patch ma prawo działać tylko z oryginalnymi procedurami SIO do obsługi kaset - jeśli jakiś program ma własne procedury odczytu, to SIO patch nie ma nawet jak się o tym dowiedzieć. To chyba sensowne założenie.

Mając takie założenie, myślę że możliwe będzie wykrycie, czy OS czeka swoje 8 sekund na pilota czy nie.

Ja rozumiem. Żaden emulator teraz tego nie wspiera. Ale gdyby był support dla wielu bloków FUJI (z możliwością przewijania do każdego z nich) to byłoby to rozwiązanie wystarczające?

FUJI: sprawdziłem na Feudzie, istotnie coś nie gra w patchu do emulatora. Wgrywa się za to przy baudrate 2500 ;). Zajmę się tym.

A w międzyczasie, na stronie A8CAS dostępna jest już wersja dla Windows.

Niech autor AtariSIO po prostu wykorzysta liba8cas ;) serio! Uodporni się na przyszłe rozszerzenia. Przecież po to robiłem to jako bibliotekę.

Nie tyle chodzi mi o "tak krótkie zabezpieczenia", ale o możliwość zapisania w CAS taśmy z najdzikszymi nawet błędami, żeby potem ułatwić sobie debugowanie. Miałem taką sytuację: konwertowałem WAV do HEX. Rekord był poprawny gdzieś do np. setnego bajtu (100 bajtów zakodowało się do bloku "data"), a potem następował błąd ramki. Reszta bloku zakodowała się do bloku 'fsk'. Po analizie źródłowego plik WAV wydedukowałem, że przyczyną błędu ramki było skasowane kilka bitów w okolicach 100. bajtu. Wystarczyło zatem dopisać/poprawić ręcznie parę wartości na początku bloku "fsk" i wykonać a8cas-convert z HEX do HEX, żeby uzyskać już poprawny plik.

A czym te 3 typy bloków się różnią? Patrząc po tym co napisałeś w Atariki, to do zapisania wszystkich 3 typów wystarczy coś takiego:

$74 $62 $6c $69 ; 'tbli'
$xx $yy ; długość rekordu w bajtach, 0 dla bloku synchro, 78 dla bloku nazwy, 1029 dla bloku danych
$xx $yy ; długość sygnału pilotującego w impulsach (3072 dla bloku synchro, 302 dla pozostałych)
... ; dane

Ewentualnie można by jeszcze zaproponować blok opisujący ciszę na taśmie o długości zapisanej w polu AUX. Taki blok przydałby się nie tylko w Blizzardzie.

Postaraj się napisać na Atariki co nieco o niestandardowych rekordach na jakie już się napotkałeś.

Spróbuj na bieżąco dostosowywać baudrate do danych które napływają podczas trwania bloku. Sumujesz długość sygnałów tworzących 10-bitowy "bajt", i na tej podstawie minimalnie zwiększasz lub zmniejszasz baudrate. Ja tak robię i działa.

Być może wynika to z tego, o czym pisał Jer - że prawdziwy magnetofon nie zatrzymuje się od razu i w konsekwencji przy wczytywaniu następnego bloku pomijane jest kilka jego pierwszych bajtów.
Zaktualizowałem moją wersję pliku .cas wydłużając trochę IRG przed ostatnim blokiem. Wypróbuj tę wersję.

Zgadzam się, WAV jest dobry. Tylko CAS w TPP ma błędy.

Nie zwijaj jeszcze ;) Powiedz lepiej jak te Twoje hacki z ecasound zintegrować ze źródłami w C (inaczej niż przez zrobienie exec() na programie ecasound)? Istnieje jakieś "libecasound" które na to pozwala? Bowiem demodulacja FSK Twojego autorstwa sprawuje się nawet lepiej niż algorytm użyty przeze mnie (wyrżnąłem go z Altirry).

Czy KK ma niestandardowe rekordy? Jeśli konwersja a8cas do formatu HEX nie wykazuje błędów sumy kontrolnej, to najprawdopodobniej będzie wszystko OK.

Jak będę w domu to też rzucę okiem.

Zrobiłem to właśnie ze względów przyszłościowych. Blok fsk jest pomyślany jako ostateczny ratunek, w którym możliwe jest zapisanie wszystkiego co się da. To co go różni od Twojego rozwiązania (czyli sekwencji następujących po sobie bloków zero, rozdzielanych b. krótkimi IRG) to dokładność - w bloku fsk jednostką jest 1/10 ms.

Życzę powodzenia. Czy widziałbyś siebie w roli programisty C współtworzącego projekt A8CAS? ;) Mnie nie starczy czasu na zajmowanie się turbami.

Blok 'data' został pomyślany jako blok zaczynający się sygnałem IRG i zawierający dowolną liczbę bajtów, każdy zakodowany w postaci 10-bitowej (bit startu, 8 bitów danych, bit stopu) - gdzie zera i jedynki mają ściśle określone częstotliwości ~3995 i ~5327 Hz. Nie chciałbym nadużywać typu 'data' do innych celów, mimo że teoretycznie można w nim zapisać także bloki turbo. Dlaczego nie identyfikować typu turba po typie bloku? Jest to znacznie prostsze niż bawić się przy odczycie w porównywanie stringów (bo tak trzebaby to robić w Twojej wersji; nie mówię że to jakieś strasznie trudne, ale po co komplikować sobie życie).

Nie bardzo wiem czemu to miałoby służyć. Przecież jeśli masz plik CAS to nie uszkodzi się on samoczynnie, prawda?

Ja raczej spodziewam się problemów z kompilacją do biblioteki DLL. Miał ktoś doświadczenie?

Ad3: http://www.viksoe.dk/code/adfview.htm

Sam tam dopisałem tego Datamarka. We wspomnianym artykule masz link do wątku na AtariAge ze zdjęciami.

Dobrze wiedzieć. Dawno temu wyczytałem coś takiego bodajże w Bajtku. Zatem pewnie się pomyllili. A może chodziło nie o odczyt, ale o zapis w stereo. Czy wszystkie typy magnetofonów zapisują sygnał tylko na prawej ścieżce?

Możliwe. Wczytywał wszystko idealnie, mogłem nawet nie wiedzieć.

Ale na telewizorach NTSC (szczególnie starszych) nie wszystkie są widoczne. Nie bez powodu obraz standardowo ma 192 linie.

Taką samą sztuczkę zapewne zastosowano w World Karate Championship na Atari - ale nie dam głowy. W każdym razie muzyka w WKC jest wolniejsza względem IK.

Candle, a czytałeś ten wątek? Simius miał podobny objaw z Atarką w systemie PAL - VCOUNT zliczał mu do 156 (czyli tak jakby PAL miał 314 linii). Okazało się, że ta wartość 156 pojawiała się w VCOUNT na mniej niż 4 cykle zegara, po czym zmieniała się na 0. Może w Twoim przypadku jest podobnie?