Argh. Nie przewidziałem, że niektórzy mogą z tym mieć problem.
Interpreter perla jest domyślnie zainstalowany w każdej dystrybucji Linuxa (czy w ogóle w każdym systemie unix-like). Skrypt perla można uruchomić tak:

perl nazwa_pliku.pl [opcje]

Tym plikom, które załączyłem można też nadać atrybut 'wykonywalny' i uruchamiać jak normalny program (np. pod Linuxem). Dla Windows perl też jest dostępny w postaci gotowych instalatorów, np. Strawberry Perl, Indigo Perl czy ActivePerl. Moje skrypty nie wykorzystują żadnych dodatkowych bibliotek spoza głównego pakietu perla, nie powinno więc być potrzeby dociągania czegokolwiek.
Najgorzej dla windziarzy jest z dostępnością programu ecasound. Prawdopodobnie jak by się udało skompilowac pod Cygwinem lub MingW to by działał (przetwarzanie nie musi być w czasie rzeczywistym), ale Google mówi, że nikt do tej pory się tego nie podjął. Zresztą - komu to potrzebne, każda szanująca się dystrubucja Linuxa ma ecasound wśród dostępnych pakietów :P. W razie czego można spróbować użyć jakiejś dystrybucji Live uruchamianej z płyty CD, np. 64 Studio czy Musix.

EDIT: drobna poprawka w wyświetlaniu helpu skryptów perlowych (teraz wyświetla po uruchomieniu bez żadnych parametrów): wav-square-cas.zip

Blizzard.
Look'enełem w handler
- deklaracja na bufor nazwy to $4c.
- deklaracja na bufor rekordu to $403.

Zabezpieczane było Turbo 2000.
Najczęściej przez niestandardowe długości rekordów. Bez loadera (w normalu czy w turbo - zmieniało handler w "locie") nic nie skopiowałeś.
No sposoby na skopiowanie były, ale robota także.

Czasami dawano brak "zakończenia".
Gra startowała przez $2E2/3 a dalsza część była na podpuchę, albo by wystąpił "load error" przy kopiowaniu.
W turbo to nic innego (chyba) nie było (warte uwagi).

....jest i handlerek tam, może pomoże rozpoznać po co te bity 0 przed/po. Jak pamiętam, było coś tam w kodzie o tym (wcyklowanie się czy co, niepamiętam - 10 lat temu się w to bawiłem)

#define FSK_TONE_MARK       5327            /* Frequency of mark tone       */
#define FSK_TONE_SPACE      3995            /* Frequency of space tone      */

A to nie pod Atari Dos?   :lol:

To i ja się polansuję.

Opublikowałem właśnie nowe narzędzie do konwersji kaset, o którym tu wcześniej wspominałem - projekt nazywa się A8CAS. Znajdziecie tam:

- liba8cas - biblioteką współdzieloną, zapewniającą zapis i odczyt taśm w formacie CAS, HEX, WAV, Ogg/Vorbis, FLAC ...
- a8cas-tools - programiki używające liba8cas, m.in. program a8cas-convert, który ma lepiej radzić sobie z konwersją kaset niż WAV2CAS
- patch do emulatora Atari800, w celu wykorzystania liba8cas do emulacji magnetofonu.

Na razie są tylko źródła dla Linuxa, jak starczy czasu to skompiluję i wersję pod Windows. A może ktoś z Was mógłby mi w tym pomóc? Nigdy jeszcze nie kompilowałem pod MinGW czy Cygwinem.

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?

Nie ma żadnego libecasound. Programu ecasound używam w zasadzie jako hosta dla wtyczek LADSPA. A  ecasound dlatego, że świetnie się daje wykorzystać z commandline-a. Tak naprawdę jedynym elementem oferowanym przez ecasound, którego nie udało mi się znaleźć w postaci plugina LADSPA, jest fitr bandreject (używany do odfiltrowania sygnału mark lub space, żeby lepiej się skupić na tym drugim), a ten filtr można by zastąpić parą highpass-lowpass. Jeżeli chcesz wykorzystać wtyczki LADSPA, to jak najbardziej jest to możliwe (czyli a8cas-convert działał by niejako zamiast ecasound). Na dole strony LADSPA, do której link jest w moim pierwszym poście, jest link do SDK i do pliku nagłowkowego opisującego API. Nie mam pojęcia, czy trudno się w to wgryźć, nie próbowałem i raczej nie będę próbował.

Ta gra to jeden z największych oryginałów. Nie dość, że poza loaderem ma tylko jeden długi blok (43kB czy coś koło tego), to jeszcze nie widać, żeby była jakakolwiek suma kontrolna - sam loader chyba nie kontroluje, co się tam wczytuje :(. Można losowo pozmieniać bajty, a i tak nie pojawi się "load error". Problem z konwersją jest taki, że dump jest kiepskiej jakości, w trakcie trwania nagrania zmieniają się częstotliwości sygnałów mark i space (w zakresie do 200Hz), bo pewnie taśma była bardziej lub mniej rozciągnięta. Oznacza to, że zmieniają się  szerokości bitów, a nie bardzo jest jak je korygować bez markerów.

To nie do końca tak. Nie ma potrzeby rozdzielania bloków 'zero' (które ostatecznie miałem nazwać 'fsk0') bardzo krótkimi IRG. Po prostu takie przypadki się nie zdarzają, a jeżeli się  zdarzają, to jest to zbędny szum. Po drugie - jak wiadomo zwykły atarowski magnetofon nie jest w stanie wyciągnąć więcej niż 1400 bodów (jak ktoś ma szczęście). Przy tej prędkości szerokość jednego bitu to okolice 0.7 ms. Oznacza to, że coś, co mogło by posłużyć za zabezpieczenie, praktycznie nie może być krótsze niż 1 ms. Jeżeli jest coś krótszego, to raczej zostanie potraktowane jako szum, który pewnie jakiś kondensator w magnetofonie zniweluje. Przykład - "Polskie Logo" - po pierwszym bloku drugiej części nagrania są w pewnym odstępie cztery bajty 0. Tuż przed nimi jest jeszcze bardzo krótki sygnał (zapewne niezamierzony), którego obecność lub brak nijak nie wpływa na działanie tego zabezpieczenia.
Ale to wszystko tylko gwoli wyjaśnienia piszę, ogólnie nic nie mam przeciw robieniu czegoś na zapas, jeżeli nie wprowadza to niepotrzebnych komplikacji. A to nie wprowadza komplikacji i podoba mi się.

Właściwie w ogóle nie widzę się w roli jakiegokolwiek programisty :P, choć od czasu do czasu zdarza mi się dodać parę bugów tu i ówdzie. Nie odmawiam pomocy, ale też nie mogę niczego obiecać, również ze względu na brak czasu (czytaj - ze względu na priorytety). Sygnał turbo tak naprawdę jest banalny do przetwarzania, jest znacznie czystszy niż ten standardowy i wystarczy wykrywać jego kolejne zbocza. Przeszkodą może być natomiast znacznie większa podatność na uszkodzenia, bo każdy jeden okres fali niesie konkretną informację.

Hmmm... w oryginalnej dokumentacji tak jest opisany, bo inne możliwosci nie były przewidziane. Tymczasem blok 'data' mówi tylko, że oto mamy tyle i tyle bajtów danych poprzedzonych przerwą trwającą tyle i tyle. Nie ma tam nic o częstotliwościach i rodzaju modulacji. Ale upierać się nie będę.

A to już w wav-ie, a nie w pliku .cas, a wynika to z interpretacji bloku 'data' przez aplikację, a nie z samej zawartości bloku 'data'.
Ale  się nie upieram.

Erm... Bo w jednym pliku .cas nie będzie kilku turb naraz ? (choć może być loader w standardzie i reszta w turbo) Albo bardziej - bo jedno turbo przy takim podejściu może mieć 2-3 typy bloków ? Ja miałem na myśli blok 'form' jako "przełącznik", który informuje aplikację, co ma robić z blokami 'data', które napotka za blokiem 'form'...
Ale tu też się nie upieram. Hmmm... czyli bloki 'bliz', 't2k ' itp. + legenda w README ? Albo blok 'tur ' + typ turba w bajtach aux ? Można popróbować, choć mnie z kolei jakoś nie przekonuje mnożenie różnych typów bloków.

A sprawdzanie typu bloku to nie porównywanie stringów :P ? I tak to trzeba robić.

No cóż, jest piątek, do tego prawie północ, korci mnie, żeby podwyższyć poziom abstrakcji teoriami o neutrinach przelatujących przez powierzchnię twardego dysku :D.

...

(bierze się w garść)

...

Sam się nie uszkodzi, ale może się uszkodzić np. przy przesyłaniu przez internet, albo może go uszkodzić jakiś złośliwiec i rozprowadzić wśród nieświadomych atarowców-amatorów, tudzież doczepić tam wirusa, który zainfekuje Outlooka (skup się, skup się... - to do siebie).
(i tu próbowałem zanleźć jakieś inne argumenty, ale ponieważ z genów jestem kiepskim mówcą, to nie znalazłem. 'csum' wypada z gry.)

Dobranoc.

@pavros:

Ad. 2: To raczej emulator należało by poprawić, żeby był bardziej zgodny z oryginałem. Z biblioteką Krótkiego każdy emulator powinien sobie radzić (prawie) tak dobrze, jak atari z magnetofonem.

Ad.1: Już zasypiam, więc wybacz jeżeli majaczę. O jakich plikach "binarnych" piszesz i w jakim celu chcesz je oddzielać od całości cas-a, który jest jedną całością ? A BTW - zamierzam swój nowy skrypt perlowy (który ma połączyć te dotychczasowe i nowe w jeden) wyposażyć w różne funkcje do manipulacji plikami cas, w tym np. podział na pojedyncze rekordy do oddzielnych plików i składanie ich do kupy (na razie nie piszę po co, choć to tylko jedno zdanie), tudzież xex<-> cas dla nagrań typu "z wykrzyknikiem", więc jestem otwarty na dziwne propozycje (bez skojarzeń proszę). A w przypdku turbo, które z reguły zawierają coś, co można nazwać xex, to ja tworzę xex mimochodem przy okazji tworzenia cas-a.

Dobranoc.

Krótki, Fuji - mogę się założyć, że Dely Was ozłoci jak skończycie swoje projekty :)

Ja będę także wdzięczny - tym bardziej za wersję pod Winde.

OK, dzięki.

Masz sporo racji. Jednakże w systemach turbo baudrate bywa wyższy, więc możliwość zapisania "śmieci" w takiej sytuacji się przyda. Można potem w pliku HEX poprawić kilka wartości i ponownie wywołać a8cas-convert, żeby wygenerować już poprawny plik.

Rozumiem. W takim razie - liczę na Twoją aktywność w Atariki, może kiedyś wykorzystam Twoje informacje.

Ale przy konwersji do WAV upraszcza to sprawę - oto mam blok data, więc wiem że ma być 3995 i 5327 i bity startu i stopu.

Jestem za takim rozwiązaniem. Niech typ bloku determinuje wszelkie informacje dodatkowe, takie jak częstotliwości czy obecność bitów startu/stopu.

Ale rozpoznawanie typu bloku (czyli porównywanie stringa zawsze 4-bajtowego) i tak musi być. Po co robić coś na 2 sposoby, skoro można na jeden?

Złośliwiec mógłby zaktualizować sumę kontrolną :P
A jeżeli już, to miejsce takich sum kontrolnych jest w osobnych plikach do ściągnięcia z witryny, na której hostowane są pliki CAS. Tak np. robią wydawcy Linuxów - wrzucają na serwer wielkie obrazy ISO a obok małe pliki md5.

Ciekawa propozycja. W skrócie proponujesz możliwość przechowywania "katalogu" programów w pliku CAS? Format CAS niby to wspiera - w pliku może być wiele plików FUJI zawierających opis następnej części nagrania. Jednak nie implementowałem tego u siebie. Na pewno przydałby się feature w a8cas-convert, umożliwiający wybór rekordów od-do, na których powinna być przeprowadzona konwersja. Albo automatyczne wykrywanie długich IRG.

W tej kwestii zgadzam się z FUJI.

Niespodzianka, dobre wieści :) Zauważyłem że KK nie wczytuje się pod emulem (zarówno zwykłym, jak i tym zpaczowanym przeze mnie). Tzn. wczytuje się, ale zaraz po tym atari się wiesza.

Potraktowałem więc KK moim a8cas-convert. Wynik nadal nie wczytuje się pod zwykłym emulem (emul się w ogóle wysypuje - to dlatego, że nie umie obsłużyć bloków o długości dłuższej niż ~12000 bajtów, a takie właśnie długie rekordy generuje a8cas-convert), ale wczytuje się pod spaczowanym Atari800 (które nie ma ograniczenia na długość rekordów). I nie ma żadnych śmieci w grafice. Powinien zatem wczytać się też na real sprzęcie (po zrobieniu a8cas-convert -fs plik.cas plik.wav - bo nie wiem, czy WAV2CAS też nie wysypuje się na długich blokach).

Download ze strony projektu A8CAS.

EDIT: Zupdate'owałem właśnie liba8cas i patcha do Atari800 w związku z obsługą Turbo 2600.

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.

Aaaaa...  no to tego argumentu mi brakowało. I mam nawet u siebie kandydata do testów.

Częściowo sam sobie odpowiedziałeś - bo w jednym nie mieści się IRG, a staram się jak mogę iść za twoim tokiem myślenia i zostawiać miejsce dla jak największej ilości informacji. W mojej drugiej opcji były tylko dwa typy bloków (choć to może  niewyraźnie widać), czyli tyle samo co w twojej z blokiem ciszy. Niemniej znowu się zgodzę, że blok ciszy może się przydać w przypadku ogólnym, również dla zapisu standardowego - tam też przecież zdarzają się chwile ciszy... Idąc za ciosem -  może by dodać odpowiednik bloku 'fsk ' do przechowywania samotnych, pojedynczych impulsów znalezionych w nagraniu turbo ? 'imp ' wspólny dla wszystkich formatów turbo. I dokładnie w ten sam deseń, czyli w formie sekwencji czasów trwania impulsów, i to jak najbardziej z rozdzielczością 0.1 ms (albo większą). Tu miało by to większy sens, bo pojedynczy impuls o tak krótkich czasach rzeczywiście może oznaczać konkretną informację. A to, że w naturze czegoś takiego się nie używa to inna sprawa ;).
Twoja propozycja bloku blizzarda uzupełniona o blok ciszy wydaje się rozsądna, również dla przypadków niestandardowych rekordów. Co programista, to programista ;).

Prosisz i masz.

Pytanie do Pajero: w opisie Turbo KOS jest coś takiego:

Czy to oznacza, że te skróty nazwy z numerami rekordów były nagrywane w oddzielnych, krótkich rekordach ? Ja ze swoim kartam z KOS jakoś nie mogę uzyskać takiego efektu.

No tak. Ja się bardziej skupiałem na symulacji działania prawdziwego sprzętu (a tam AFAIK standardowo nie ma takich korekt), więc nie przyszło mi to do głowy. Dzięki.

Raczej nie. Jer musiał pisać o jakiejś innej wersji. W tej nie ma żadnego przystanku po trzecim rekordzie, bo według nagłówka ich ilość wczytywana przez OS przed uruchomieniem czegokolwiek wynosi 8. Chyba, że "trzeci sektor" oznaczało coś innego. Przed długim blokiem miejsca jest dość. Przy wczytywaniu z  oryginalnego pliku dźwiękowego dzieje się to samo. Podejrzewam, że to emulacja może być niedoskonała.

EDIT:
Moment. Przecież magnetofony z Blizzardem obsługują też zapis standardowy. To by oznaczało, że jak jest cisza, to na linii szeregowej jest "1". Czyli tak naprawdę jest to sygnał FSK "1". To by oznaczało, że nie jest potrzebny blok ciszy, tylko fsk z wartością 1. Teraz problemem może być  to, że maksymalny czas trwania bloku 'fsk ' to jakieś 6.5 sekundy. Wydaje mi się, że powinno wystarczać, a w razie czego można dać więcej takich po sobie. Edit: Następne pytanie nieaktualne. Czy elektronicy (lutoscenowcy ;)) mogą na schematach zweryfikować, kiedy i na jak długo włącza się obwód blizzarda zamiast obwodu standardowego ?

Znów wyraziłem sie niejasno. Miałem na myśli emulacje komputera, a nie magnetofonu. Przez chwilę myślałem, że może te artefakty to są rzeczywiście artefakty (GTIA), ale jednak to nie wygląda na to. Co prawda po włączeniu artifactingu w emulatorze też pojawiają się śmieci, ale całkiem inne. Może raczej litery rozsypują się w wyniku scrollowania... Tylko dlaczego zawsze tak samo...

Zajrzałem jeszcze raz do handlera. Rzeczywiście wygląda na to, że na data output wysyłany jest sygnał SPACE (10 zer) przed rozpoczęciem transmisji. Czyli cisza dla Blizzarda to co innego niż cisza fsk. Teraz pytanie - czy w takim razie przy tej ciszy na wejściu jes "1" czy "0' czy coś nieustalonego ? To by trzeba wyczytać ze schematu.
Wydaje mi się, że powinna być możliwość wyspecyfikowania w bloku ciszy (proponuję nazwę 'shhh' :D), czy ma być podawana jedynka czy zero. Bez tego wystarczy 'shhh' zbudowane tak jak 'baud', a z tym dodatkiem musi być o bajt dłuższe, chyba, że np. wykorzystać najstarszy bit starszego bajtu czasu trwania do określania stanu ?

No cóz... -> http://atariki.krap.pl/index.php/Rejestry_POKEY-a
W książce Zientary też to się nazywa SPACE... -> http://tajemnice.atari8.info/ksiazki/ppso/dodatki.html

A skoro Blizzard przy ciszy na taśmie daje szum (chodzi o transmisję taśma -> komputer) , to chyba wszystko jedno co jest na wejścu seriala, więc ośmiobajtowy blok ciszy z długością w bajtach aux powinien wystarczyć.

EDIT:
A w ogóle to dzięki seban za informację :).

Przy okazji - jestem w kontakcie z autorem AtariSIO, którego udało się zmotywować do dodania wsparcia dla długich rekordów i do obsługi bloków 'fsk ' (na razie nie ma oficjalnie do ściągnięcia). Ponoć Lasermania z zabezpieczeniem się wczytuje, będę testował wieczorkiem.