!00% wykrywalność błędów by wystarczyła :)

Racja. Niech blok będzie wyglądał tak: FUJI <nazwa>
Sądzę że nie ma potrzeby zapisywania długości bloku, tak jak w blokach "data" / "fsk ". Prawdę mówiąc, noszę się z zamiarem usunięcia zapisywania długości także z bloków "data"/"fsk ", i przeniesienia tej wartości do komentarza na końcu linii (po ";"). Dzięki temu nie trzeba będzie pamiętać o zmianie długości bloku w przypadku ręcznego poprawiania HEX-a. Masz coś przeciwko?

Jak działa nie gorzej niż w "oryginalnym" Atari800, to jest dobrze. Może Spy vs Spy ma custom loader albo jakieś zabezpieczenie. Widziałem w Green Beret takie coś: po wczytaniu program sprawdza wartość RTCLOCK - jeśli jest za mała (gra z patchem wczytuje się parę sekund, więc wartość wychodzi za mała), to wpada w nieskończoną pętlę. Moze w SVS też coś namieszali - w każdym razie dzięki.

A nawiasem mówiąc, Spy vs Spy to błędny dump - na końcu rekordów kończących części nagrania, znajdują się nadmiarowe śmieci. Nie przeszkadza to we wczytywaniu, ale ja jestem pedant. Dely, załączam poprawioną wersję CAS-a:
http://students.mimuw.edu.pl/~tk197881/ … vs_spy.cas
Od dawna leży tam też poprawione Kissin' Kousins (wersja w TPP ma błędy):
http://students.mimuw.edu.pl/~tk197881/ … ousins.cas

Przydają się, żeby zapisać IRG dłuższe niż 65,535 sek.

Masz magnet przerobiony na AST? Rób foty do Atariki! :)

Ale jak wczytywałem na emulatorze, to np. Tiger Attack wczytywał się z błędami przy polaryzacji "najpierw zbocze opadające, potem rosnące". Rozumiem że to błąd emulacji?

Co do moich doświadczeń z TurboROM... ten system używa dość krótkich impulsów aby uzyskać dużą szybkość transmisji... pasmo które musi przenieść magnetofon jest spore. To co widać w przypadku górnej próbki to problem z pasmem magnetofonu, wysokie częstotliwości nie są prawidłowo przenoszone... problemem jest złe ustawienie głowicy... Turbo-ROM jest na to cholernie wrażliwy. Obejrzyj zgrane nagrania w domenie częstotliwości (spectal view) zobaczysz że problemem było złe ustawienie głowicy i brak przenoszenia wysokich częstotliwości...

Nie wiem jak dokonujesz dumpów z taśm, jakiś deck? Bo o ile możesz liczyć na prawidłowe ustawienie głowicy w jakimś fabrycznym decku, to nie masz pewności co do ustawienia głowicy w magnetofonie który nagrywał kasetę w systemie Turbo-ROM.

Wyglądu AST i tego co jest w środku:

http://atariarea.krap.pl/forum/viewtopi … 841#p76841
http://atariarea.krap.pl/forum/viewtopi … 072#p77072

pozdrawiam
Seban

Dziękóweczka, już podmieniłem pliki.

Znalazłem na forum tutaj dump jednej z wersji cartridge-a Turbo Rom. Przy pomocy atari800 przeanalizowałem procedury odczytu i zapisu, w związku z czym na Atariki są uzupełnione informacje o tym systemie. Dzięki temu udało mi się też wreszcie odpowiednio dostroić konwerter, można się zapoznać z przykładem na stronie z przykładami.

Emulator świetnie obsługuje uidealnione nagrania Turbo Rom, pomimo dużej szybkości transmisji działa bezbłędnie, jak widać zależności czasowe są bardzo wiernie zachowywane.

Dałem sobie siana z zabawą z filtrami dla Turbo Rom (patrz poprzedni post). Niby można coś przez to zyskać, ale niestety dla każdego nagrania trzeba się było mocno namęczyć z dopasowaniem parametrów. Stwierdziłem, że jednak regulacja skosu głowicy jesty łatwiejsza i pewniejsza ;). Widać głowice w magnetofonach komputerowych są bardziej tolerancyjne (czyli mniej dokładne ?). Oczywiście czasem takie filtry pomagają naprawić uszkodzone nagrania (patrz poprzedni post).

Przy okazji chyba wyjaśniła się sprawa z nieczułością AST na odwracanie fazy sygnału. Jeżeli tak jak w przypadku Turbo Rom mierzone są czasy trwania tylko jednego poziomu sygnału, to ponieważ w AST szerokości obu poziomów prawie zawsze są równe, nie ma znaczenia, który wystąpi pierwszy (znaczy czy pierwsze jest zbocze narastające czy opdające).  Oczywiście zdarzają się  wyjątki. W wolnej chwili przeanalizuję procedury AST pod debuggerem atari800 (całkiem przyjemny jest).

Aha, Krótki nie informował o tym tutaj, ale wypuścił parę dni temu wersję 1.0 swojego dzieła :).

Development version TURGEN DEV(8.2) should support Turbo blizzard. It was tested using A8CAS extended emulator and worked fine. It is unknown whether it works on real system. You can download that development
version from here: http://www.baktra.wz.cz/software/turgen/english.html

Takie pytanko do wszystkich (Fuji, Krótki). Użyszkodnik widny (czyli ja) potrzebuje ciut pomocy. Gdzie znajdę helpa do A800? , bo np. nie mogę wyłączyć FullScreena.

No proszę, też niedawno trafiłem na coś takiego, konkretnie kasetową wersję systemu Turbo 2000 (do pobrania z sekcji przykładów na mojej stronie). W tym przypadku wystarczyło zapisanie niestandardowych części w postaci bloków "fsk ", mało eleganckie, ale działa. W przypadku "Mieczy Valdgira 2" coś nie bardzo zadziałało. Siadłem więc również do przepisywania kodu, w pewnym momencie udało mi się dostać nawet lepszy efekt niż Twój (wszystkie niestandardowe bloki w identycznej postaci, długości kolejno 15, 16, 101), ale za to inne tasiemki przestały się konwerować, więc kombinuję dalej. Jak byś mógł udostępnić oryginalnego dumpa to był bym wdzięczny. W zamian ;) udostępnię inną tasiemkę, która też sprawia pewne problemy (obu konwerterom), chociaż w zasadzie wcale nie jest aż taka niezwykła.

Po analizie procedur obsługi turbo (tych z loaderów i kartridży) wydaje mi się, że jednak na potrzeby emulatorów dobrze by było dodać informację (sugestię), jak należy interpretować sygnał, ponieważ w pliku CAS nie ma informacji, jaki konkretnie zapis turbo przechowuje. Do odtworzenia sygnału audio jest to zbędne, ale emulator magnetofonu musi wysyłać bezpośrednio zera i jedynki w odpowiedniej kolejności. Jeżeli się nie pomyliłem, to czasem zbocze opadające wyzwala jedynkę, a czasem zero. Czasem nie ma to znaczenia (np. AST), ale czasem ma. Dodałem więc miejsce na odpowiednią informację w bloku 'pwms' (opis na stronie).
Kontynuując rozmowę o zmianach w HEX - myślę, że ze wszystkich rodzajów bloków dobrze usunąć długość z początku i przenieść do komentarzy - przy ręcznych poprawkach to się daje we znaki, jak się zapomni zmienić. Choć z drugiej strony można po prostu ignorować pierwszą liczbę przy konwersji z HEX na coś innego. Dobrze by było się zdecydować na jednolity format...

W zamian moje narzędzie wzbogaciło się m.in. o obsługę czeskiego Turbo 2000, po tym jak zgłosił się chętny zza gór... ;)

Ach. Znaczy się, że jak konweruję cas do hex to a8cas-convert po drodze jak gdyby przerabia go na wav i potem dopiero na hex od nowa badając długość bitów ? Myślałem, że w hex pojawia się  dokładnie to, co jest w cas, po co od nowa przekodowywać ?

E tam, się nie da. Wszystko jest kwestią włożonego wysiłku, który się opłaca lub nie (w tym przypadku pewnie raczej nie ;)). Zapewne również da się automatycznie rozpoznawać typy turbo :P.

Pytanie spowodowało, że popatrzyłem na listę na Twojej stronie, i widzę, że niczym nie zaskoczę. Chodzi o "Special Forces" czyli "Operation Blood II". No i popróbowałem z bit-deviation w a8cas-convert i wtedy poszło bez problemów :cool:. Mimo to - obiecane linki: strona A (cas, tu nie ma niczego niezwykłego), strona B (niestandardowe długie rekordy z niestandardową prędkością zapisu): cas, flac.
Jeszcze ciekawostka. Byłem ciekawy, czy Twój algorytm radzi sobie z tym, z czym mój obecny roboczy z założenia sobie nie poradzi. Mnie się nie udało dobrać parametrów dla a8cas-convert, ale ja nie znam go zbyt dobrze. Spróbuj przekonwertować ten hex na cokolwiek i z powrotem i otrzymać taki sam hex (np. bezpośrednio hex->hex).

Cóż - dla mnie to w zasadzie rybka czy taka informacja będzie czy nie. Wydawało mi się, że to może się jednak przydać, a tu niespodzianka - poprzednio to ja się opierałem... Na pewno masz lepsze rozeznanie w tym, jak działa emulator, więc zdam się na Twój osąd.

:o A zdawało mi się, że to akurat coś prostego. No nic, tymczasem będę sobie dalej konwertował hex do cas przed użyciem (ja wtedy prawie od razu pozmieniałem).

Głównie chodzi o szerokości i tolerancje szerokości impulsów oraz sposób liczenia sumy kontrolnej. Jeśli chodzi o same impulsy, to na pewno się da wykryć ich szerokości i dewiację tychże, podobnie jak dla bitów w sygnale fsk. Które zbocze jest pierwsze też w sumie dało by się wykryć (choć pewnie nie zawsze). Z kolejnością bitów w bajcie już może być gorzej, bo trzeba by analizować otrzymane dane. Sama suma kontrolna (zwłaszcza xor) może nic nie  powiedzieć, nawet nie wiadomo na początku, jaki jest algorytm jej liczenia (albo czy  w ogóle jest).  Konkretny format można by rozpoznawać na podstawie długości bloków i ich nagłówków, ale tu już potrzebny jest zestaw parametrów, który trzeba przechowywać i próbować dopasować, dlaczego więc nie przechowywać również "wykrywalnych" parametrów. Czeski program w turbo 2000, na którym ćwiczyłem, nie miał bloku nazwy, a na podstawie zawartości nic by się nie dało wywnioskować, bo dopiero loader (w standardzie) tę zawartość rozszyfrowuje w locie podczas wczytywania, po podaniu właściwego "hasła". Jak dla mnie na razie prościej jest podać format w linii poleceń i poprzestać na stałych ustawieniach.

Dzięki.

Jeżeli człowiek go nauczy, to będzie umiał :P. Ja swój komputer już nauczyłem, choć się na początku dziko opierał. Screenshot ;):

a8cas-util.pl conv Miecze\ Valdgira\ 2.flac Miecze\ Valdgira\ 2.hex
Starting ecasound... started.
SUMMARY: Data blocks: 940, std: 31 (0 E), nonstd: 0 (0 E), multibaud: 303 (0 E), analysed 41122816 samples.
1553 HEX blocks stored in file new_Miecze Valdgira 2.hex.

Działa ze wszystkimi (sprawdzonymi do tej pory) dumpami kaset bez konieczności zgadywania szerokości i dewiacji. W sumie nic skomplikowanego, tyle że trochę upierdliwe było rozpatrywanie poszczególnych przypadków. Najśmieszniejsze, że jak już mi zaczęło działać, to się zorientowałem, że trochę wcześniej w ramach testów dodałem do kodu fragment, który mi zniekształcał dane wejściowe :/. Tym większa satysfakcja. Znaczy - da się. Update w sekcji download będzie niedługo.
Teraz się wyjaśniły problemy z konwersją "Kissin' Kousins" - pod koniec dwa razy trochę zmienia się prędkość.

U mnie sie już da, I to nawet przy 5 sygnałach (rekord złożony z 3 bajtów $80 lub $cc). Widzę, że dla $cc w a8cas-convert też już jest dobrze.

Super, zwłaszcza że biblioteka i emulator też już uaktualnione. Dzięki. W wolnej chwili dodaj może jeszcze 'FUJI' do hex (o ile nie kłóci się to z Twoimi założeniami).

Przy okazji bug report - jak a8cas-convert konwertuje tego oryginalnego dumpa to powstają nieprawidłowe bloki fsk, a jak się konwertuje wav-a utworzonego z tego cas-a to wszystko wychodzi dobrze.