Dzięki wszystkim za propozycje, choć pisałem, że jeżeli kogoś interesują formaty INNE niż wymienione przeze mnie. Próbek Blizzarda i podstawowego Turbo 2000 KSO mi raczej wystarczy, chyba że macie jakieś nietypowe (np. oryginały z zabezpieczeniami). AST może się przydać do testów, najlepiej próbki z różnych kaset. Nie wiem jak jest z różnymi "klonami" Turbo 2000 (F, +, 2001 itd.).
A tak przy okazji - wyszło mi, że różne nagrania w formacie Blizzarda mogą być niekompatybilne na poziomie zapisanego sygnału. Wygląda tak, że na jednych kasetach  bity były kodowane sekwencją sygnałów niski-wysoki, a na innych wysoki-niski. Gdzieś tu na forum ktoś wspominał, że miał problemy z wczytywaniem nagrań z różnych wersji Blizzarda, może właśnie dlatego.

@Krótki:

Ad.1 Też o tym myślałem i też mi to pasuje, tylko się zastanawiałem nad częstotliwością próbkowania używaną jako podstawa. Ja przy zrzucaniu tasiemek sampluję z częstotliwością 48000/s (SB Live tak lepiej działa), a przy konwersji wewnętrznie resampluję do 96000 sampli/s, bo pewniej się rozróżnia jedynki i zera przy dwukrotnie większych różnicach. Ale w sumie przy zapisywaniu do cas można równie dobrze przeliczyć w dół. OK, to spróbuje w ten sposób. Będzie 2 bajty na "częstotliwość", a na szerokości poszczególnych impulsów po bajcie.

Ad. 2 Nie, nie trafiłem na bity startu i stopu. Są tylko "bity" pomiędzy pilotem i danymi. Pomiędzy bajtami nigdy. AST jeszcze dokładnie nie analizowałem - tam są ?

Ad. 3 Sądzę, że rzeczywiście jest tak jak piszesz. Nie chciał bym jednak na wszelki wypadek zmniejszać tego parametru do jednego bitu (0 - 0 pierwsze, 1 - 1 pierwsze), więc najwyżej się usunie komentarze do sekwencji 00 i 11.

Ad. 4 'pwms' w ogólnym przypadku nie musi występować tylko raz, podobnie jak blok 'baud'. Zdarzają się drobne różnice średniej szerokości impulsów (do 2-3 sampli przy 96k sampli/s), co oczywiście znaczenie ma niewielkie, ale jednak... Poza tym nie rozumiem, jaki to ma związek z ilością bitów na zapis impulsów między pilotem a danymi ...? To jest stałe dla wszystkich bloków.

Ad 5. Tak, chodzi o ciszę.

Ad 6. To będzie automatycznie wynikac z 1.

Z numerami wersji CAS masz rację, o to właśnie chodzi.

EDIT: zmiany w bloku 'pwms' (USUNIĘTE - już niepotrzebne)

EDIT2:
Krótki, muszę Cię przeprosić za dezinformację. Otóż są biblioteki libecasound i libcasoundc. Moja ignorancja wynikała z tego, że to biblioteki linkowane statycznie z programem, więc do działania nie potrzeba ich w systemie. Szukałem sposobu na łatwiejsze używanie ecasound w perlu i jak sie okazuje jest odpowiedni moduł korzystający z tych bibliotek. A wystarczyło popatrzeć na drzewo żródeł...

EDIT3:
Bug report: liba8cas zachowuje się dziwnie, jak trafi na blok 'data' z zerową ilością bajtów danych. Wygląda na to, że cała reszta pliku jest interpretowana jako jeden długi blok danych (aż do komunikatu "Can't read from <filename> (code 4)").

EDIT4:
AST trochę pomieszało mi szyki  :/ (chodzi o "pół bajtu" zapisywanego na końcu bloku). Muszę  jeszcze raz przemyśleć, jakie informacje i gdzie przechowywać i pewnie zmodyfikować 'pwms' i być może 'pwmd'.

EDIT5:
Po dzikiej próbie skomplikowania zapisu stwierdziłem, że wolę jednak upraszczać niż komplikować. Szczegóły wkrótce.

Ostatnio edytowany przez FUJI (2010-02-04 22:09:11)

Wiecie, mam inne rzeczy na głowie.

Ale i tak Wam kiboluje (tylko wątek śledzę) czekając finału.  3mam kciuki.....

Na razie szybka odpowiedź, bo trochę nie mam czasu pisać - dobra wieść - Blizzard działa pod emulatorem przy użyciu pliku dźwiękowego utworzonego z cas-a, jak się włączy ręczne turbo :). Jedyna rzecz, którą trzeba uwzględnić, to "polaryzacja" sygnału, tzn. emulator reaguje poprawnie jak kolejność stanów jest jak dla AST, czyli wysoki-niski. Jitter może ci wychodzić właśnie z powodu odwróconego sygnału (programy do regulacji głowicy pokazują śmieci).
Poczekaj jeszcze trochę z ostatecznym dodawaniem nowych bloków, chcę ruszyć jakoś ten Turbo Rom. Generalnie tu niespodzianek nie ma (konwersja działa jako-tako, dość niepewnie). Nawiązałem kontakt z człowiekiem z "Plusa", może się od nich jakieś informacje uda wydobyć.

To właśnie była rzecz, o której nie mogłem sobie przypomnieć. Kontekst znaczenia takiej informacji jest jednak inny. Nie chodzi o prawidłowe odtworzenie zapisu dźwiękowego - bity0 i 1 bajtu aux1 determinują kolejność stanów niskiego i wysokiego tworzących bit, czyli tym samym kolejność zboczy, oryginalna postać zapisu może być na tej podstawie odtworzona. Dochodzi tu jednak kwestia hardware-u, który oryginalnie zapisał dane na taśmie i handlera, który te dane interpretuje przy odczycie. Jak pisałem wcześniej, bazując na handlerze z Atariki i magnetofonie, który posiadam, spotkałem zapisy blizzarda, dla których jedynkę wyzwala zbocze narastające i takie, w których było na odwrót. Jeżeli założyc, że handler zawsze jest taki sam, to konia z rzędem temu, kto ustali, który hardware jest "ten właściwy", a który nie. Nie ma też chyba gwarancji, że handler umieszczony na różnych cartridge-ach był zawsze taki sam - może różne wersje wymagały różnych kolejności stanów 0 i 1 ? Reasumująć - jeżeli chcemy przesłać cas do komputera, czy to po nagraniu na taśmę czy bezpośrednio przez złącze SIO, to trzeba po prostu próbować, czy zadziała. Dodanie informacji o której piszesz wymagało by, żeby ten, kto tworzy plik cas wiedział, jak działa interfejs jego magnetofonu i jak działa handler w jego catridge-u, a użytkownik cas musiał by dostosować swój sprzęt. Wydaje mi się więc, że dodanie takiej dodatkowej informacji jest nadmiarowe i zbędne. Natomiast decyzję, które zbocze co wyzwala można pozostawić np. oprogramowaniu (np. taki przałączniczek w "tape management" do zmiany hardware-u na inny, reagujący odpowiednio na dane zbocza).
Przypomniało mi się coś - programy narzędziowe dla AST rozróżniają magnetofony XC12 i 1010, to przykład, że soft musi się dostosowac do hardware-u, a na taśmie jest pewnie w obu przypadkach to samo.

Wracając do poprzednich tematów - oczywiście Twoja propozycja bloku 'pwmc' jest jak najbardziej słuszna. Po prostu łatwiej jest mi debugować, gdy każdy rodzaj impulsu idzie do oddzielnego bloku, ale docelowo niech będzie jak podałeś.

Jeśli chodzi o Turbo Rom - będę próbował podpytać autorów, jak to z tym jest. Perspektywa debugowania kodu loadera jakoś mnie nie pociąga ;). Podepnę tu (wieczorem) link do pliku cas z tym loaderem. Może ktoś dobry w te klocki i chętny do pomocy zerknie ? W tej chwili widzę 3 możliwe podejścia do tematu: a) samplowanie z częstotliwością 96000 i być może postępowanie jak przy innych formatach, b) założenie, że wykorzystywane są tylko narastające zbocza sygnału, c) impulsy odpowiadające zerom (bardzo słabe w porównaniu do jedynek i "rozmywające się") zignorować, a ilość zer określać na podstawie szerokości przerw między jedynkami.
Tak czy siak - chyba nie ma co czekać z dalszym poszerzaniem CAS - albo Turbo Rom się wpasuje w to co jest, albo rzeczywiście będzie inną opcją.

Do używania samplerate 96000 w plikach cas jak na razie mam taki sam stosunek, jak do zapisywania sygnału FSK z rozdzielczością 0.1 ms - uważam to za zbędne. Do celów debugowania przy konwersji można zapisywać coś takiego do hex, ale czy trzeba do cas ? A może zapisywać częstotliwość próbkowania nie w samplach na sekundę, tylko w setkach sampli na sekundę ? Albo przynajmniej w dziesiątkach sampli na sekundę (żeby można było zapisać 22050, ale poniżej 44100 chyba nie ma sensu schodzić) ? Albo zapisywać symbolicznie: 22,44,48,96 (bleeee) ? Wtedy dwa bajty wystarczą w zupełności i wszyscy będą zadowoleni ;). No, chyba że ktoś chce próbkować z częstotliwością np. 74834...

Ostatnio edytowany przez FUJI (2010-02-08 15:48:25)

Hmmm... Rzeczywiście mój opis był nieprecyzyjny, to skutek używania skrótów myślowych w odniesieniu do konkretnych formatów... Może tak ?

aux1 - dwa najmniej znaczące bity (1 i 0) określają rodzaj impulsu:
01 - impuls rozpoczyna się zboczem opadającym i trwa do następnego zbocza opadającego.
     Odległości pomiędzy kolejno występujacymi zboczami (opadającym,narastającym,opadającym)
     są jednakowe. Czasy trwania kolejnych stanów wyzwalanych zboczem opadającym i narastającym
     są jednakowe (po połowie czasu podanego w blokach cas).
10 - impuls rozpoczyna się zboczem narastającym i trwa do następnego zbocza narastającego.
     Odległości pomiędzy kolejno występujacymi zboczami (narastającym,opadającym,narastającym)
     są jednakowe. Czasy trwania kolejnych stanów wyzwalanych zboczem narastającym i opadającym
     są jednakowe (po połowie czasu podanego w blokach cas).
00 i 11 - w rezerwie

To o czym dyskutowałem, to czy zbocze opadające (i narastające) wyzwoli '0' czy '1' podawane na data-out. A to nie zależy już  od samego sygnału na taśmie, tylko od interfejsu, który go przetworzy. Interpretacja leży już po stronie emulatora (lub hardware-u). I owszem, można by dołożyć sugestię, jak powinno być, zwłaszcza że  w tej chwili nigdzie nie jest zapisywane, jaki format został przekonwertowany na cas. Określenie formatu źródłowego teoretycznie powinno jednoznacznie określić, jakie zbocze co wyzwala. I tu z rozrzewnieniem wspominam blok 'form' z nazwą formatu. Po tych dywagacjach jestem skłonny przeznaczyć następny bit na przechowanie sugestii o relacji 'zbocze' - 'stan data-out' lub do wyboru opisowe określenie formatu (np. w bloku 'pwms' zaraz za bajtami samplerate). To jak ?

Ha, tu mnie może masz. Nie samplowałem wszystkich kaset które mam, poza tym mętlik mi się już trochę zrobił, i bardzo możliwe, że nagrania z odwróconym sygnałem pochodzą tylko ze ściągniętych plików. Co nie musi znaczyć, że mój magnetofon akurat nie odwraca w fazie :P.

Logika rzeczywiście tak podpowiada, o ile był tylko jeden producent danego turba. A  jeśli byli inni, to żeby zapewnić sobie klientów mogli  zmieniać te kilka bajtów w handlerze... W tamtych czasach ochrona praw autorskich kulała...
Ale z tym nierozerwaniem cartridge-a i magnetofonu nie masz racji. Po pierwsze można się obejść bez cartridge-a przy pomocy loaderów na taśmie (patrz niżej). Po drugie - na Atariki na stronie o Blizzardzie jest napisane, że budowa interfejsu zależała tylko od  inwencji jego twórcy, mógł więc być zbudowany tak, że zbocze opadające wyzwalało '0' lub '1' w zależności od widzimisię (i odpowiednio '1' powodowało zapisanie zbocza takiego lub siakiego); wtedy przy korzystaniu z tego samego softu kaseta zapisana na jednym magnetofonie mogła się nie wczytać na drugim. Remedium na coś takiego mogło by być dopasowanie handlera. I wtedy dopiero masz rację - cartridge i magnetofon są nierozerwalne, ale handlery w każdej parze są ciut różne.

Nie trzeba zakładać, tak właśnie jest :D. Porównaj moje opisy obu formatów na Atariki. Oczywiście w przypadku AST bazuję tylko na jednym Twoim nagraniu.

A co z  wiernością zarchiwizowanych danych ;) ?

Nie gniewaj się, ale na razie działanie emultora nie może być wyznacznikiem działania rzeczywistego sprzętu ;) (również patrz niżej). Może niedługo będę mógł to sprawdzić. A w sumie to software też się może dostosować - AST jest dość wolne i powinno być dużo czasu na takie rzeczy, można przecież badać, która połówka impulsu jest krótsza jako pierwsza za pilotem...

Tak, do debugowania jak najbardziej. Dla użytkownika końcowego jest to zbędne. Ale skoro cas MUSI zawierać to co HEX, to trudno.

No to teraz linki:
1) Przykładowy loader Turbo Rom - do analizy na debuggerze lub inaczej (mnie pod "Bug Hunterem" nie idzie, ten loader wczytuje się na stronę 0 i stos!)
2) gra w formacie blizzard, która U MNIE wczytuje się na emulatorze. Kolejność postępowania jest taka:
- ładujemy normalnie w atari800 plik ml25-s.cas
- jak pojawi się czarny ekran, zmieniamy tasiemkę na ml25-t.wav i włączamy turbo. Po powrocie do emulatora powinien się  załadować microloader
- zmieniamy tasiemkę  na morky.wav, wracamy do emulatora, po sygnale klepiemy "any key" i po zapytaniu o wczytywanie naciskamy "Y".
Dodatkowo w archiwum są pliki turbo w formie cas (jeszcze bez nowych zmian).

UWAGA: wbrew temu co pisałem wcześniej blizzardowe pliki wav są w formie fali prostokątnej. Plik, w którym zbocza były zmienione na łagodniejsze i dodatkowo faza została zamieniona, na jednym komputerze działał, na drugim nie chciał. Ta wersja działa na obu komputerach, tylko jest dość czuła na szerokość zapisanych bitów, jeszcze nie wiem czy chodzi o szerokość jako taką, czy o równość stanów niskiego i wysokiego (oryginalnie wychodziła nieparzysta liczba sampli na bit '1'). Poza tym - pliki wav mają samplerate 44100 i to w tym przypadku też może w jakiś sposób zmieniać efekt. Konwerter jeszcze mi nie przelicza wszystkiego jak należy, więc w zasadzie to 44100 wyszło przypadkiem.

A tu stronka w przygotowaniu. Ot tak, dla zabawy ;).

No właśnie ma znaczenie, czy pierwsze to narastające czy opadające. Jeżeli zmieniasz interpretację bez odwracania sygnału, to oczywiście jedna z nich będzie działać lepiej. Natomiast zdziwił bym się, gdyby wczytywało się tak samo, gdybyś bez zmiany interpretacji zmienił polaryzację. Blizzard na mur tak nie zadziała (na real sprzęcie).

A ja wiedzieć. Typowy objaw właśnie przy ustawieniu odwrotnej polaryzacji sygnału. Zauważ, że jak zamienisz jedynki z zerami to suma kntrolna może się też zgodzić, więc nie będzie błędu 143, tylko komputer spróbuje uruchomić to co wczytał. Spróbuj odwrócić tego wav-a. Jeżeli nie pomoże, to proszę link do plików, który na jednym z komputerów mi się ładowały: altmorky.tgz. Sygnał jest odwrócony, a prostokąt zmieniony w prawie-piłę.

Dwie rzeczy: zapomniałem napisać - twoje pliki wav mają jakiś niestandardowy nagłówek i ecasound nie rozpoznaje prawidłowo częstotliwości próbkowania i ilości kanałów. Ja musiałem wczytać do jakiegoś edytora audio i zapisać na nowo. Druga rzecz - opcja "-t" nie działa (błąd w opisie), użyj --turbo (lub przynajmniej --tu).

To dziwne. Może to kwestia wersji modułu Pod::Usage, albo jego obecności w systemie albo obecności programu pod2html, pod2text...  Niewykluczone, że w niektórych dystrubucjach nie ma go standardowo, choć wydaje mi się, że to powinno być w głównym pakiecie perla.
Dodałem na wszelki wypadek link do manuala na stronie.

Jasne. Trochę później.

Chciałbym się pochwalić przed szanownym gronem kolegów że udało mi się to co niektórzy mówili że jest niemożliwe, a mianowicie to że z TURGENA wygenerowałem plik wave który wczytuje się pod emulatorem w systemie Turbo Blizzard.

Program , a właściwie plugin nie nadaje się jeszcze do publikacji , ale jak czasu starczy to go dopieszczę.

Dzięki FUJI za natchnienie poprzez Twoją dyskusję z Krótkim na temat Turbo.

To tak na szybko.

No właśnie - emulator ładuje podejrzanie dobrze ;).

Pliki dla Krótkiego. Hacker BUT. Niestety, już dziś nie dałem rady przekonwertować dobrze do końca, najdłuższy blok jest rozerwany chyba w 2 miejscach. Ale początek się ładuje, na razie do testów  dekodowania PWM (czy o co tam chodzi) powinno wystarczyć. Swoją drogą  - plik oryginalny niby się ładuje do końca, ale jakieś śmieci mi się na ekranie potem pojawiają.
Przed konwersją musiałem odwrócić fazę sygnału, bo z oryginałem konwersja też idzie, ale dane wychodzą bez sensu. Jeszcze jedna rzecz - nie mam pojęcia, jak w formacie BUT kontrolować  poprawność danych, nie widzę niczego, co mogło by być sumą kontrolną, zresztą loader też się  zachowuje tak, jak by mu było wszystko jedno.

W archiwum są: plik cas, wav z falą prostokątną (nie ładuje się), wav z falą nieco "wygładzoną" (ładuje się, a przynajmniej mocno próbuje), log z konwersji, opcje ustawione przy konwersji. Polecenie wyglądało tak (uwaga - skrypt został odrobinę poprawiony, do ściągnięcia tam gdzie wcześniej):

./a8cas-util.pl conv --turbo ast --noise 0.01 --amplify 1.2 Hacker-t-rev.wav.

Oczywiście początek w standardzie odciąłem.

Plik -> hacker.tgz

Ha! Zdrajco. Zamiast wspierać rodaków w wysiłkach chcesz pracować dla obcego kapitału ?! ;)

Taki plik znajdziesz kilka postów wyżej (gra w formacie blizzard). A opis sygnału Blizzarda jest na Atariki.

@Krótki: A czy przypadkiem, jak sam to nazwałeś, twój prymitywny dekoder PWM nie wyzwala zmian stanów logicznych na szczytach fal zamiast na zboczach ? To by tłumaczyło zarówno niekorzystne efekty (nie działanie fal prostokątnych) jak i nieczułość na odwracanie fazy (przynajmniej dla niektórych kształtów fal). Zerknij na moją funkcję latch(), chyba nie wiele mniej prymitywne podejście, ale na pewno wierniej naśladuje sprzęt. generalnie chodzi o to , że musi być jakaś minimalna różnica w poziomach sygnałów, żeby było wykryte zbocze. Domyślnie różnica u mnie wynosi 10, można regulować opcją --mindiff. Pamiętaj, że działam na próbkach 8-bitowych, więc przy 16-bitowych różnicę trzeba pomnożyć przez 256. Dodam tam chyba jeszcze jakiś kondensator, który przez jakiś czas był obecny w nieco innej implementacji i teraz mi go trochę brakuje.

Ostatnio edytowany przez FUJI (2010-02-11 07:50:02)

FUJI a kto powiedział że pracuję dla obcego kapitału :)

A cóż to ma do rzeczy?