26

Odp: CAS2SD, XCAS

Cześć, miłośnicy (i przeciwnicy) kaset.

Przy ostatniej fali tęsknoty za starymi dobrymi czasami mnie też wzięło właśnie na kasety i od jakichś dwóch miesięcy zamiast słuchać muzyki słucham kojącego ;) rzężenia magnetofonu.
Pomysł z obsługą plików .cas przez coś w rodzaju cas2sd niesamowicie mi się podoba i niewątpliwie zasponsoruję kogoś, kto by mi zmontował takie urządzonko jeżeli już wyjdzie z fazy projektów. Swoją drogą wydaje mi się, że dodanie przynajmniej podstawowej obsługi plików .cas na sio2sd chyba nie powinno być zbyt trudne, kupując sio2sd miałem nadzieję, że może kiedyś pojawi się stosowny update...

Kiedy jakiś czas temu przewinął mi się przed oczami tekst o emulatorze Altirra, w którym była deklarowana obsługa tasiemek w formie plików dźwiękowych, nad moją głową zapaliła się żaróweczka. Lubię się bawić dźwiękiem pod Linuxem, więc słowo "bandpass" wywołało natychmiastowe skojarzenie. Celem było przerobienie oryginalnego sygnału z taśmy na falę prostokątną, która by wiernie zachowywała wszystkie zależności czasowe, zabezpieczenia itp., czego klasyczny .cas nie umożliwia. Dodatkowy warunek to zero programowania ;). Po kilku tygodniach prób i błędów (testowanie wyników na żywo niestety wymaga czasu) osiągnąłem co chciałem. Potrzebne jest tylko kilka wtyczek LADSPA i - w moim rozwiązaniu - program ecasound. Konwersja w jedną bądź w drugą stronę w zasadzie wymaga jednej (choć długiej) linijki commandline-a. Efekt wygląda np. tak:

http://www.voila.pl/148/hb1fe/?1

Pliki z wynikową falą prostokątną to zwykłe .wav-y (próbki 8-bitowe), więc zajmują dużo miejsca, ale niesamowicie dobrze się kompresują. Najlepiej ściska je bzip2, który pozwala zmniejszyć rozmiar ponad 300x, a w przypadku idealnych plików, z równiutkimi szerokościami bitów (czyli remasterowanych z plików .cas), nawet 700x. W efekcie taki plik często jest mniejszy niż odpowiadający mu nieskompresowany .cas.

Bez odrobiny programowania jednak się nie obyło. Potrzebowałem poza testami na prawdziwym sprzęcie czegoś, co by pozwoliło szybciej sprawdzać, czy osiągany efekt jest prawidłowy. Powstały zatem dwa skrypty w perlu, które pozwalają konwertować "kwadratowego" wav-a do formatu .cas i z powrotem. Okazuje się, że stary, dobry .cas z niewielkimi przeróbkami świetnie spełnia swoje zadanie dla wszystkich kaset, z którymi się zetknąłem. Jak to było wcześniej wspomniane, oprócz normalnych rekordów z danymi (krótszych bądź dłuższych) i przerw między nimi można się spotkać z "długimi zerami". Zapisuję to w odrobinę inny sposób, niż proponowany wcześniej, mianowicie:

7a 65 72 6f ; nagłówek 'zero'
02 00 ; długoś bloku 2 bajty
xx xx ; długość IRG przed 'zerem' w ms, jak w bloku 'data'
xx xx ; długość sygnału 'zero' w ms

Druga różnica w moich .cas-ach to częstsze zapisywanie bloków 'baud'. Wstawiam taki blok zawsze, gdy jest wykryta zmiana szerokości bitu (w samplach) w kolejnym bloku. Przy ładowaniu programów z prawdziwej kasety rożnice w prędkości są dość dobrze słyszalne (wyższe-niższe buczenie) i te różnice dla podniesienia wierności zapisu chyba warto zachować. Ta konkretna zmiana nawet nie przeszkadza obecnym emulatorom (testowane na atari800).

W kwestii synchronizacji kanału prawego i lewego - jeżeli poprzestać na konwersji do fali prostokątnej, to zależności czasowe zostają raczej wiernie zachowane. Czasem nawet zbyt wiernie i zbyt często pozwalają podziwiać napis "boot error" (dotyczy prędkości większych niż standardowa). Dla plików .cas, przy użyciu odpowiednich współczynników używanych przy konwersjach, najlepsze co się udaje osiągnąć to rozjazd około 0.6 s na 28 min nagrania. Taka różnica niespecjalnie przeszkadza, testowałem na "An Introduction to programming" i "Sammy the Sea Serpent". Nie da rady osiągnąć ideału z powodu zaokrągleń prędkości transmisji do pełnych bodów.

Nie ma specjalnych problemów z konwersją programów nagranych ze zwiększoną prędkością, czyli w przypadku "turbo" dla magnetofonów bez przeróbek. Testowałem do prędkości około 1200 baud.
Zaletą używanych filtrów bandpass, w przeciwieństwie do metody używanej przez wav2cas, jest to, że sygnał nie musi w ogóle przechodzić przez zero, żeby był poprawnie rozpoznany. Możliwe jest więc odczytanie sfatygowanych kaset z miejscowymi sporymi zniekształceniami sygnału (a czasem z miejscowymi prawie-zanikami sygnału, po wzmocnieniu w edytorze audio). Dość chyba powiedzieć, że np. wszystkie pliki dźwiękowe z tpp udaje się przekonwertować na pliki .cas, które po odwróceniu procesu dają się poprawnie załadować na prawdziwym sprzęcie (emu atari800 niestety nie zawsze daje sobie radę, na innych emulatorach nie próbowałem).

Jeżeli to kogoś interesuje - oto obecne wersje skryptów w archiwum zip: wav-square-cas.zip (link wygaśnie za jakiś miesiąc).

W środku znajdziecie:
wav2square.sh - konwersja oryginalnego wav-a na falę prostokątną
square2cas.pl - konwersja otrzymanego wyżej wav-a na plik .cas (+ log w formie czytelnej dla człowieka)
cas2square.pl - odwrotnie niż poprzedni
square2wav.sh - odwrotnie niż pierwszy

Skrypty shella opatrzone są komentarzami, perlowe mają własny help.

Zacząłem się przyglądać formatowi blizzard turbo pod kontem konwersji na .cas. Na razie wydaje mi się, że powinno być jeszcze prościej (wystarczy po prostu liczyć sample...?), ale drugiej strony, to co widzę w edytorze audio nie do końca mi się zgadza z opisem na Atariki. Dam znać, jak coś mi się uda z tym zrobić (a może nie warto tracić czasu ?).

A ze sprzętowych życzeń dotyczących cas2sd - żeby linia "motor control" była wykorzystywana do sterowania wirtualnym silnikiem (pauza/wznowienie odtwarzania .cas-a). Tego mi brakuje w sio2pc.

Ostatnio edytowany przez FUJI (2009-12-19 11:49:58)

27

Odp: CAS2SD, XCAS

Allo.
Blizzard może być żle opisany - pisałem w Atariki z pamięci. Acz jest to system z 50% popularnością (i najlepiej rozwiązany). Więc na pewno warto.
Znajdziesz tam też źródła handlera....

A zielonym w Perlu - jak to zjeść?

28

Odp: CAS2SD, XCAS

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

Ostatnio edytowany przez FUJI (2009-12-19 11:48:59)

29

Odp: CAS2SD, XCAS

Pytanie: czy kasety nagrywane w formatach turbo (blizzard, 2000, 2000F itd.) miewały też jakieś swoje szczególne zabezpieczenia, jak w przypadku formatu standardowego ? Jeżeli nie, to ja nie widzę potrzeby dodawania jakichkolwiek rozszerzeń do formatu .cas uwzględniających turbo. Jako obraz tasiemki może równie dobrze służyć obraz dyskietki, tylko dane trzeba przesyłać do komputera w odpowiedni sposób. Jedynym elementem charakterystycznym jest długa nazwa zbioru, ale z tego co widzę rzadko było stosowane coś dłuższego niż format 8.3.

BTW: na Atariki na stronie o Turbo Blizzard w zakładce 'dyskusja' są pierwsze wyniki hackowania formatu zapisu. Weryfikacja nastąpi, jak skombinuję lepszy magnetofon do samplowania i nagrywania (walkman niestety nie działa tak dobrze, jak przy zapisie standardowym). Na razie ćwiczę na dumpach kaset z tego postu.
Porządnie zsamplowany Blizzard dość prosto się daje przekonwertować na plik binarny (np. xex), rzeczywiście wystarczy liczyc sample (tak na marginesie samplerate 44.1k wydaje się trochę za niskie). Odpowiednie skrypty pojawią się, jak je przynajmniej z grubsza oszlifuję.
Następny będzie KSO Turbo 2000 (ponieważ mam kasety z takimi nagraniami).

Edit: Aha, jeszcze przy okazji anegdotka o atarowskim sygnale FSK (używane wartości z opisu programu wav2cas): jeżeli od częstotliwości sygnału 'mark' odejmiecie częstotliwość sygnału 'space' i podzielicie przez 2, to otrzymacie... liczbę bestii.. :D.

Ostatnio edytowany przez FUJI (2009-12-21 09:14:21)

30

Odp: CAS2SD, XCAS

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).

FUJI napisał/a:

BTW: na Atariki na stronie o Turbo Blizzard w zakładce 'dyskusja' są pierwsze wyniki hackowania formatu zapisu.....

....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)


FUJI napisał/a:

jeżeli od częstotliwości sygnału 'mark' odejmiecie częstotliwość sygnału 'space' i podzielicie przez 2, to otrzymacie... liczbę bestii.. :D.

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

FUJI napisał/a:

Interpreter perla jest domyślnie zainstalowany w każdej dystrybucji Linuxa (czy w ogóle w każdym systemie unix-like)

A to nie pod Atari Dos?   :lol:

Ostatnio edytowany przez pajero (2009-12-22 00:32:15)

31

Odp: CAS2SD, XCAS

A to Atari Dos nie zalicza się do systemów unix-like ? :P

pajero napisał/a:

Blizzard.
- deklaracja na bufor nazwy to $4c.
- deklaracja na bufor rekordu to $403.

No fakt, jest na samym początku. Czyli się zgadza. Resztę handlera też przeanalizowałem i też wygląda, że na taśmie wszystko jest tam, gdzie powinno. Zostaje więc tylko przeliczenie liczb na czasy (na razie wiem, że pierwszy sygnał pilotujący powinien trwać 1.6 s), rekonstrukcja sygnału i testy. Ale to już po świętach.
Tymczasem wesołego Alleluja !

32

Odp: CAS2SD, XCAS

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.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

33

Odp: CAS2SD, XCAS

No pięknie :). Tym piękniej, że na wstępie jest dla Linuxa.
Czuję się zdemotywowany i zwijam interes ;).
Proponuję jako testu użyć "Kissin' Kousins" umieszczone na TPP - to jest nagranie, które sprawiało mi najwięcej problemów przy konwersji i ładowaniu (ładuje mi się przez atarisio i się nie wiesza tak jak wersja z tpp, ale widać po artefaktach, że dane nie do końca są w porządku). Ciekawe, jaki wynik da a8cas-convert (konwertować konwertuje, tylko czy wystarczająco dobrze).
Nie jestem przekonany, że kodowanie jedynek w blokach fsk jest potrzebne, ale od przybytku głowa nie boli i niewątpliwie to rozwiązanie przyszłościowe, może jeszcze pojawią się kasety lepiej zabezpieczone ;).
Ja tymczasem potrafię konwertować z/do formatu Turbo Blizzard (wav/cas) i Turbo 2000, potrzebuję tylko czasu na doprowadzenie skryptu(ów) do ładu.

Moja propozycja na dodatkowy blok opisujący format:

'form' ; nazwa bloku
xx yy ; długość bloku zależna od nazwy formatu
00 00 ; dwa bajty zero
pp qq rr ss ... ; nazwa formatu, np. "standard", "turboblizzard", "turbo2000kso"

Format "standard" byłby domyślny. Dla formatów turbo jak na razie nie widzę potrzeby stosowania poza tym bloków innych niż 'data'.

Poza tym jeszcze jedna luźna propozycja - umieszczanie bloku z sumą kontrolną całego pliku cas, żeby można było zawsze na pewno zweryfikowac, czy posiadany plik cas to ten oficjalnie działający, czy nie.

'csum' ; nazwa bloku
xx yy ; dlugosc bloku zalezna od rodzaju sumy
uu; typ sumy kontrolnej (0 - crc, 1 - crc32, 2 - md5, 3 - sha1 ...)
00 ; zero
pp qq rr ss ... ; suma kontrolna

Miałem odrobinę do czynienia z kompilacją pod MinGW (ale nie z pisaniem programów), i poza ewentualnym problemem ze znalezieniem potrzebnych do zlinkowania programu bibliotek w postaci dll operuje się podobnie jak pod Linuxem.

34

Odp: CAS2SD, XCAS

FUJI napisał/a:

No pięknie :). Tym piękniej, że na wstępie jest dla Linuxa.
Czuję się zdemotywowany i zwijam interes ;).

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).

FUJI napisał/a:

Proponuję jako testu użyć "Kissin' Kousins" umieszczone na TPP - to jest nagranie, które sprawiało mi najwięcej problemów przy konwersji i ładowaniu (ładuje mi się przez atarisio i się nie wiesza tak jak wersja z tpp, ale widać po artefaktach, że dane nie do końca są w porządku). Ciekawe, jaki wynik da a8cas-convert (konwertować konwertuje, tylko czy wystarczająco dobrze).

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.

FUJI napisał/a:

Nie jestem przekonany, że kodowanie jedynek w blokach fsk jest potrzebne, ale od przybytku głowa nie boli i niewątpliwie to rozwiązanie przyszłościowe, może jeszcze pojawią się kasety lepiej zabezpieczone ;).

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.

FUJI napisał/a:

Ja tymczasem potrafię konwertować z/do formatu Turbo Blizzard (wav/cas) i Turbo 2000, potrzebuję tylko czasu na doprowadzenie skryptu(ów) do ładu.

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

FUJI napisał/a:

Moja propozycja na dodatkowy blok opisujący format:
(...)
Dla formatów turbo jak na razie nie widzę potrzeby stosowania poza tym bloków innych niż 'data'.

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).

FUJI napisał/a:

Poza tym jeszcze jedna luźna propozycja - umieszczanie bloku z sumą kontrolną całego pliku cas, żeby można było zawsze na pewno zweryfikowac, czy posiadany plik cas to ten oficjalnie działający, czy nie. (...)

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

FUJI napisał/a:

Miałem odrobinę do czynienia z kompilacją pod MinGW (ale nie z pisaniem programów), i poza ewentualnym problemem ze znalezieniem potrzebnych do zlinkowania programu bibliotek w postaci dll operuje się podobnie jak pod Linuxem.

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

Ostatnio edytowany przez Krótki (2010-01-08 20:08:08)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

35

Odp: CAS2SD, XCAS

Witam,
Mam dwie propozycje rozszerzenie formatu .CAS:
1. Dodanie informacji (markerów) o podziale zawartości pliku .CAS na pliki binarne, jeżeli jest ich więcej niż jeden w jednym pliku .CAS. Chodzi o to, aby przy pomocy jakiegoś narzędzia łatwe było ekstraktowanie plików binarnych z CAS'a oraz dodawanie ich do CAS'a. Teraz jedyne wyjście, to wyszukiwanie długich przerw, ręczny podział pliku na części w miejscach tych przerw i konwersja każdego z osobna na binarny. Do każdego z plików binarnych wewnątrz CAS'a byłaby przypisana również nazwa (długa). W przypadku zapisu Turbo byłaby to ta sama nazwa co zapisana na taśmie.
2. Dodanie informacji (markerów), że pewne końcowe rekordy jednego pliku binarnego należy pominąć przy wczytywaniu i przeskoczyć do następnego pliku binarnego. Kilkakrotnie zdarzyło mi się złożyć plik .CAS wieloblokowej gry z plików binarnych zgranych z kasety poprzez zwykłe kopiowanie i o ile wczytywał się on potem do real Atari przez SIO2CAS o tyle nie działał pod emulatorem. Wynikało to właśnie z faktu, że niektóre pliki składowe były za długie o 1-2 rekordy, które przy wczytywaniu do Atari były pomijane w naturalny sposób (Atari już oczekiwało "rozbiegówki" kolejnego pliku).  Ten marker byłby wykorzystywany tylko przez emulatory.

36

Odp: CAS2SD, XCAS

Krótki napisał/a:

Powiedz lepiej jak te Twoje hacki z ecasound zintegrować ze źródłami w C (inaczej niż przez zrobienie exec() na programie ecasound)?

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ł.

Krótki napisał/a:

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.

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.

Krótki napisał/a:

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.

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ę.

Krótki napisał/a:

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

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ę.

Krótki napisał/a:

Blok 'data' został pomyślany jako blok zaczynający się sygnałem IRG i zawierający dowolną liczbę bajtów,

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ę.

Krótki napisał/a:

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.

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.

Krótki napisał/a:

Dlaczego nie identyfikować typu turba po typie bloku?

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.

Krótki napisał/a:

Jest to znacznie prostsze niż bawić się przy odczycie w porównywanie stringów (...)

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

Krótki napisał/a:

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

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.

37

Odp: CAS2SD, XCAS

Jeśli chodzi o Kissin Kousins to jest bardzo dziwna sprawa, albowiem gra potrafi się raz wczytać, a potem kilka razy nie :) Wykluczam magnetofon ponieważ z innymi grami nie ma problemu - poza tym w tym przypadku nie korzystałem z kasety (z nią są podobne sytuacje) tylko z telefonu ze źródłem w WAV - więc z najlepszą możliwą konfiguracją. Plik jest dobrze zrzucony ponieważ w innym przypadku nie wgrywałby się ani razu :)

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

38

Odp: CAS2SD, XCAS

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.

39

Odp: CAS2SD, XCAS

W Kissin Kousins jest zabezpieczenie polegające nachwilowym zatrzymaniu magnetofonu po bodajże trzecim sektorze, wygaszeniu ekranu i zamknięciu kanału odczytu na chwilę. Powinna tam być dłuższa przerwa między sektorami, ale z nagranym pilotem. Magnet, który się nie zatrzyma od razu (styki!) przejdzie poza pilota i gdy kanał się otworzy - qpa.  Podobnie była zabezpieczona jeszcze jedna gra, chyba Montezuma's Revenge!.

Nikt nam lekkiego życia nie obiecał i słowa dotrzymał.
8bitów ; dereatari
Apple Hadware

40

Odp: CAS2SD, XCAS

FUJI napisał/a:

Nie ma żadnego libecasound. (...)

OK, dzięki.

FUJI napisał/a:

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ę.

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.

FUJI napisał/a:

Właściwie w ogóle nie widzę się w roli jakiegokolwiek programisty :P (...)

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

FUJI napisał/a:
Krótki napisał/a:

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.

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.

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.

FUJI napisał/a:

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.

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

FUJI napisał/a:
Krótki napisał/a:

Jest to znacznie prostsze niż bawić się przy odczycie w porównywanie stringów (...)

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

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?

FUJI napisał/a:

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

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.

pavros napisał/a:

Witam,
Mam dwie propozycje rozszerzenie formatu .CAS:
1. Dodanie informacji (markerów) o podziale zawartości pliku .CAS na pliki binarne, jeżeli jest ich więcej niż jeden w jednym pliku .CAS. Chodzi o to, aby przy pomocy jakiegoś narzędzia łatwe było ekstraktowanie plików binarnych z CAS'a oraz dodawanie ich do CAS'a. Teraz jedyne wyjście, to wyszukiwanie długich przerw, ręczny podział pliku na części w miejscach tych przerw i konwersja każdego z osobna na binarny. Do każdego z plików binarnych wewnątrz CAS'a byłaby przypisana również nazwa (długa). W przypadku zapisu Turbo byłaby to ta sama nazwa co zapisana na taśmie.

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.

pavros napisał/a:

2. Dodanie informacji (markerów), że pewne końcowe rekordy jednego pliku binarnego należy pominąć przy wczytywaniu i przeskoczyć do następnego pliku binarnego. Kilkakrotnie zdarzyło mi się złożyć plik .CAS wieloblokowej gry z plików binarnych zgranych z kasety poprzez zwykłe kopiowanie i o ile wczytywał się on potem do real Atari przez SIO2CAS o tyle nie działał pod emulatorem. Wynikało to właśnie z faktu, że niektóre pliki składowe były za długie o 1-2 rekordy, które przy wczytywaniu do Atari były pomijane w naturalny sposób (Atari już oczekiwało "rozbiegówki" kolejnego pliku).  Ten marker byłby wykorzystywany tylko przez emulatory.

W tej kwestii zgadzam się z FUJI.

dely napisał/a:

Jeśli chodzi o Kissin Kousins to jest bardzo dziwna sprawa, albowiem gra potrafi się raz wczytać, a potem kilka razy nie :) (...)

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.

Ostatnio edytowany przez Krótki (2010-01-09 15:41:09)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

41

Odp: CAS2SD, XCAS

Na wstępie - Krótki, Atari800 z dodatkiem liba8cas działa za-rą-biście ! Problemy z wczytywaniem bezpośrednio z wav na pewno da się jakoś rozwiązać.

Krótki napisał/a:

Jednakże w systemach turbo baudrate bywa wyższy, więc możliwość zapisania "śmieci" w takiej sytuacji się przyda.

Jak pisałem, nie będę tu się o nic spierał, bo nie ma o co. Założenia są słuszne. Tak tylko dla porządku dodam, że nie bardzo wierzę w tak krótkie zabezpieczenia. Np. dla baudrate 2600, szerokość jednego bitu wyniesie jakieś 0.38 ms. Czas trwania jednego okresu sygnału 'mark' to w zaokrągleniu 0.19 ms, 'space' - 0.25 ms. Ja tam nadal nie widzę miejsca na wciśnięcie zabezpieczeń trwających ułamki milisekund - albo by wyszło coś, co zostanie zignorowane,  bo jak by było poprawnie rozpoznane, to można by przecież zrobić turbo 3500  na atarowskim sygnale fsk, albo by wyszła po prostu sekwencja zwykłych bajtów (krótki rekord).

Krótki napisał/a:

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

Turbo Blizzard już został opisany z tydzień temu, Turbo 2000 pojawi się niedługo. Wpadła mi też w ręce kaseta opisana "turbo-rom", pomęczę ją niedługo. A kodem ewentualnie bym się zajął, jak by mi zbywało czasu a Ty byś długo nie wypuszczał update-ów.

Krótki napisał/a:

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.

Skoro programista mówi, że tak jest wygodniej, to pewnie tak jest ;).

Krótki napisał/a:

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

No to jak się zapatrujesz na coś takiego:

$74 $62 $20 $30 ; 'tb 0' - turbo blizzard, blok typu 0, pilot
$02 $00         ; długość 2 bajty
$xx $yy         ; IRG przed pilotem w ms
$pp $qq         ; długość sygnału w impulsach (np. $00 $0c na początku normalnego "pliku")

$74 $62 $20 $31 ; 'tb 1' - turbo blizzard, blok typu 1, blok nazwy
$4d $00         ; długość 77 bajtów
$00 $00         ; IRG zwykle równe 0, tuż przed zwykle jest sygnał pilotujący
; tutaj nazwa

$74 $62 $20 $32 ; 'tb 2' - turbo blizzard, blok typu 2, blok danych
$04 $04         ; długość 1028 bajtów (lub inna, zdarza się)
$00 $00         ; IRG zwykle równe zero, tuż przed zwykle jest sygnał pilotujący
; tutaj dane

Idąc Twoim tokiem myślenia zostawiłem możliwość istnienia bloku danych z niezerowym IRG, gdyby komuś przyszło do głowy zabezpieczać kasety blizzardowe i nie zapisywać najpierw pilota. Jednak jeżeli taką możliwość pominąć, to zamiast 'tb 1' i 'tb 2' może być:

$74 $62 $20 $31 ; 'tb 1' - turbo blizzard, blok typu 1, blok danych
$xx $yy         ; długość (np. $4d $00 dla nazwy, $04 $04 dla danych)
$zz             ; typ bloku: $00 nazwa, $01 dane
$00             ; nie używane
; tutaj dane

W tym przypadku też niby można sobie poradzić z blokiem danych bez pilota, zapisując przed nim sygnał pilotujący o długości 0 i z niezerową wartością IRG, ale to już jest kombinowanie. Zresztą - zawsze w razie potrzeby można by dołożyć 'tb 2' - blok danych bez pilota i z irg...?

Krótki napisał/a:

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.

Tu jest też zgoda. Po prostu się rozpędziłem. Przechowywanie sumy w pliku ma sens, gdy taki plik jest bardzo duży i każdorazowe liczenie zajmowało by za dużo czasu.

No i na koniec o Kissin Kousins.  Jest dobrze :). W końcu się wkurzyłem i zastosowałem brute force. Okazało się, że wystarczy sztucznie przyjąć, że baudrate dla tego długiego bloku jest mniejsze niż wykrywane na podstawie wcześniejszych standardowych bloków i dostałem wreszcie stabilny wynik. I to zgadza się co do bitu z tym co produkuje a8cas-convert. Być może muszę coś poprawić w swoim algorytmie, albo sprawdzić obliczenia.
Ale - nadal dzieje się z tym coś dziwnego. Rzeczywiście pod emulatorem śmieci nie ma, ale jak się wczyta na prawdziwym sprzęcie (sprawdzałem na dwóch komputerach, przez atarisio i nawet po nagraniu na taśmę) to na ekranie tytułowym, na najniższym pasku ze scrollem, litery wyglądają na zepsute. Jak bym wcześniej sprawdzał tylko na emulatorze, to pewnie w ogóle nie było by tej sprawy.

dely napisał/a:

Plik jest dobrze zrzucony ponieważ w innym przypadku nie wgrywałby się ani razu :)

Trochę źle się wyraziłem, chodziło mi o to, że zgrywane źródło było kiepskiej jakości. Ale jak widać nie aż tak kiepskiej :).

42

Odp: CAS2SD, XCAS

FUJI napisał/a:

Jak pisałem, nie będę tu się o nic spierał, bo nie ma o co. Założenia są słuszne. Tak tylko dla porządku dodam, że nie bardzo wierzę w tak krótkie zabezpieczenia. (...)

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.

FUJI napisał/a:

No to jak się zapatrujesz na coś takiego:
(...)

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ś.

FUJI napisał/a:

No i na koniec o Kissin Kousins.  Jest dobrze :). W końcu się wkurzyłem i zastosowałem brute force. Okazało się, że wystarczy sztucznie przyjąć, że baudrate dla tego długiego bloku jest mniejsze niż wykrywane na podstawie wcześniejszych standardowych bloków i dostałem wreszcie stabilny wynik. I to zgadza się co do bitu z tym co produkuje a8cas-convert. Być może muszę coś poprawić w swoim algorytmie, albo sprawdzić obliczenia.

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.

FUJI napisał/a:

Ale - nadal dzieje się z tym coś dziwnego. Rzeczywiście pod emulatorem śmieci nie ma, ale jak się wczyta na prawdziwym sprzęcie (sprawdzałem na dwóch komputerach, przez atarisio i nawet po nagraniu na taśmę) to na ekranie tytułowym, na najniższym pasku ze scrollem, litery wyglądają na zepsute. Jak bym wcześniej sprawdzał tylko na emulatorze, to pewnie w ogóle nie było by tej sprawy.

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ę.

FUJI napisał/a:
dely napisał/a:

Plik jest dobrze zrzucony ponieważ w innym przypadku nie wgrywałby się ani razu :)

Trochę źle się wyraziłem, chodziło mi o to, że zgrywane źródło było kiepskiej jakości. Ale jak widać nie aż tak kiepskiej :).

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

A8CAS - narzędzie do 100% archiwizacji kaset Atari

43

Odp: CAS2SD, XCAS

Krótki napisał/a:

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

W takim razie widać, że stary WAV2CAS ssie woreczek i dla pewności należałoby pozostałe pliki również przekonwertować. Dobra robota chłopcy!

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

44

Odp: CAS2SD, XCAS

Krótki napisał/a:

Nie tyle chodzi mi o "tak krótkie zabezpieczenia", ale o możliwość zapisania w CAS taśmy z najdzikszymi nawet błędami (...)

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

Krótki napisał/a:

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:

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 ;).

Krótki napisał/a:

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

Prosisz i masz.

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

Jeżeli w nazwie pliku na czwartej pozycji po dwukropku znajduje się znak kropki, to trzy znaki pomiędzy dwukropkiem a kropka będą traktowane jako skrót nazwy pliku. Będą one nagrywane po każdym rekordzie danych wraz z numerem tego rekordu.

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.

Krótki napisał/a:

Spróbuj na bieżąco dostosowywać baudrate do danych które napływają podczas trwania bloku.

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.

Krótki napisał/a:

Być może wynika to z tego, o czym pisał Jer (...)

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 ?

Ostatnio edytowany przez FUJI (2010-01-11 08:12:38)

45

Odp: CAS2SD, XCAS

FUJI napisał/a:

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.

Też o tym myślałem, i to z tych samych względów co w przypadku bloku 'fsk ' - żeby ułatwić odzyskiwanie kaset.

FUJI napisał/a:

No tak. Ja się bardziej skupiałem na symulacji działania prawdziwego sprzętu (a tam AFAIK standardowo nie ma takich korekt)

Zgadza się, nie ma.

FUJI napisał/a:

Przy wczytywaniu z  oryginalnego pliku dźwiękowego dzieje się to samo. Podejrzewam, że to emulacja może być niedoskonała.

Tak niedoskonała, że aż działa lepiej :) A na serio, to też jestem ciekaw przyczyny.

FUJI napisał/a:

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. Czy elektronicy (lutoscenowcy ;)) mogą na schematach zweryfikować, kiedy i na jak długo włącza się obwód blizzarda zamiast obwodu standardowego ?

Cisza = FSK "1" tylko gdy magnetofon pracuje w Normalu. Gdy zostanie przełączony w tryb turbo (bo podejrzewam, że w Blizzardzie tak samo jak w innych turbach, magnet musi zostać przełączony w tryb turbo, zapewne (jak w AST) za pomocą sygnału wysłanego po jakiejś linii SIO) to interpretacja dźwięku się zmienia.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

46

Odp: CAS2SD, XCAS

Krótki napisał/a:

Tak niedoskonała, że aż działa lepiej :) A na serio, to też jestem ciekaw przyczyny.

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...

Krótki napisał/a:

(...)(bo podejrzewam, że w Blizzardzie tak samo jak w innych turbach, magnet musi zostać przełączony w tryb turbo (...)

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 ?

Ostatnio edytowany przez FUJI (2010-01-11 08:36:02)

47

Odp: CAS2SD, XCAS

FUJI napisał/a:

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.

To ja się wtrącę... bo to nie do końca tak... nie ma czegoś takiego jak sygnał "space"... po prostu na data_out pojawia się zero. To zero na DataOut przełącza interface w magnetofonie na pracę w turbo. Gdy na data_out jest logiczne "1" to magnetofon pracuje w trybie NORMAL. Nie wiem skąd się bierze błędna informacja o sygnale space... ale ustawienie 7 bitu w $d20f po prostu daje zero na data_out. W przypadku AST do przełączenia normal/turbo służyła linia command (i dodatkowy kabel prowadzony właśnie od tej linii w gniazdku SIO do magnetofonu). Twórcy Blizzarda i kilku innych systemów wykorzystali stan lini data_out (oraz możliwość jest bezpośredniego sterownia z poziomu POKEY-a) do przełączenia interface normal/turbo a także do generowania sygnału PWM podczas zapisu w systemie turbo :)

Reasumując ustawienie 7-bitu w $d20f przed rozpoczęciem transmisji to nic innego jak przełączenie interface w magnetofonie na odczyt turbo, a więc pominięcie demodulatora FSK i wykorzystanie własnego toru do zamiany tego co na taśmie na ciąg zer i jedynek. Blizzard jak większość systemów turbo dla atari, c64 czy zx spectrum wykorzystuje nazywając to po imieniu modulację szerokości impulsu (PWM) do kodowania danych :)

cisza dla blizzarda to szum, a wzmacniacz w torze wejściowym blizzarda ma bardzo duże wzmocnienie, więc szum jest traktowany jako "szum" ;) i na końcu wychodzi z ciszy losowy ciąg zer i jedynek w zależności od szumu :)

pozdrawiam
Seban

Ostatnio edytowany przez seban (2010-01-11 12:20:54)

48

Odp: CAS2SD, XCAS

seban napisał/a:

Nie wiem skąd się bierze błędna informacja o sygnale space... ale ustawienie 7 bitu w $d20f po prostu daje zero na data_out

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.

Ostatnio edytowany przez FUJI (2010-01-12 09:54:37)

49

Odp: CAS2SD, XCAS

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

Ostatnio edytowany przez Krótki (2010-01-12 10:46:42)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

50

Odp: CAS2SD, XCAS

FUJI napisał/a:

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

No tak faktycznie, w Atariki był błąd. Ale Zientarę to bym z traktował z dystansem ;) Ja sprawdziłem fizycznie oscyloskopem. Także na 100% pojawia się permanentne zero po ustawieniu 7-bitu w $d20f.

update:

chociaż w książce Zientary napisano tylko:

bit 7 - nadanie sygnału SPACE (1 = włączone)

i patrząc na pierwszą lepszą stronę którą zapodaje google, można doczytać:

The serial port has many pins. We will discuss the transmit and receive pin first. Electrically speaking, whenever the serial port sends a logical one (1) a negative voltage is effected on the transmit pin. Whenever the serial port sends a logical zero (0) a positive voltage is effected. When no data is being sent, the serial port's transmit pin's voltage is negative (1) and is said to be in a MARK state. Note that the serial port can also be forced to keep the transmit pin at a positive voltage (0) and is said to be the SPACE or BREAK state. (The terms MARK and  SPACE are also used to simply denote a negative voltage (1) or a positive voltage(0) at the transmit pin respectively).

Także informacje iż SPACE to 10 zer musiała być jakąś pomyłką lub nadinterpretacją jakiejś informacji (np. że space musi trwać minimum "10 zer" aby został rozpoznany faktycznie jako space. To takie moje małe spekulacje i nie wiem czy prawdziwe ;) ale w sumie to byłoby dość logiczne że zero musi się utrzymać dłużej niż bit startu+8 bitów danych+bit stopu aby uznano to za sygnał SPACE.

pozdrawiam
Seban

Ostatnio edytowany przez seban (2010-01-12 11:10:51)