Jest akumulator do podtrzymywania cache-u ? Skoro dało sie ustawić read/wriite 50/50 to chyba jest, ale na wszelki wypadek pytam.
Jeżeli serwer jest nowy, to potrzeba trochę czasu, aż akumulator się naładuje i akceleracja zacznie działać. Zwykle wyświetla się na tę okazje odpowiedni komunikat POST.

Jeden duży plik czy dużo małych pliczków ?

Proponował bym też uruchomić jakiś inny system np. z livecd (jak SystemRescueCD) i sprawdzić, czy to przypadkiem nie wina sterownika freebsd.

Cieszę się, że się podobało :). Nigdy bym nie przypuszczał, że zajrzę do tego po tylu latach (20 z hakiem). W takim razie spróbuję jeszcze podłubać, ale bez obiecywania żadnych konkretnych terminów...

No to specjalnie dla Ciebie, poza konkursem, krótka wersja "Domu w dolinie mgieł" (chyba na podstawie jakiejś opcji koncertowej), którą wieki temu wstukałem do Softsyntha. Dyskietkę
należy zbootować z włączonym basic-em, z menu wybrać Composera, jak pojawi się prompt wpisać:
P#D:BILINSKI.MUS
Chyba ciut lepiej brzmi na prawdziwym sprzęcie niż pod emulatorem.
Niestety nie starczyło zapału, żeby to dopracować :/.

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.

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

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

Podejrzenia są rzeczywiście takie, że coś jest nie tak z nagraniem, ale:
- głowice w magnetofonie turbo i deck-u na którym sampluję (Yamaha KX-W482) wyglądają na zgodnie ustawione, o czym świadczy dolne nagranie
- magnetofon turbo bez problemów wczytuje górne nagranie, a zsamplowane jest niewyraźne i w zasadzie nie powinno się wczytywać
- nie wiem czemu obciąłem podziałkę z czasem - nie widać tego, ale częstotliwość dla tych węższych impulsów wynosi max. 6kHz, czyli niewiele więcej niż dla sygnału 'mark' w sygnale fsk, nie jest to więc częstotliwość, aż tak bardzo wysoka

Myślę, że warto tu przytoczyć wzmiankę, że po upadku współpracy między firmami Plus i Mapasoft wyniknęły problemy z przeróbkami magnetofonów i masowym przegrywaniem kaset na dwukasetowcach w firmie Mapasoft, więc zostały wprowadzone "drobne różnice" w standardach zapisu. Może więc być tak, że sygnał celowo jest "zniekształcony" i trzeba wiedzieć, jak go poprawnie odczytać.

Uprzedzę propozycję fotografowania wnętrza magnetofonu - nie otworzę go, bo stracę gwarancję ;). Piękna plomba jest założona od prawie 20 lat i szkoda ją zdzierać.

EDIT:
Tiger Attack (AST) - flac nagrany na taśmę zachowuje się tak jak pod emulatorem - w postaci oryginalnej wczytuje się za każdym razem, odwrócony albo się wiesza, albo nie wczytuje do końca, albo nawet pierwszy blok nie chce się wczytać. Natomiast po przerobieniu na CAS i ponownie na audio wczytuje się przy obu polaryzacjach i na emulatorze i na magnetofonie. Gratuluję zatem wierności emulacji :). Trzeba jednak pamiętać, że nagranie oryginalnego dumpa na taśmę nie jest miarodajne, np. próbowałem też z Joe Blade i w ogóle nie chciało mi się wczytywać w żaden sposób.

Zgadza się. Jeśli chodzi o Hackera, to uszkodzenia są w okolicach 1'05.500'' (to łatwe do naprawienia przez wzmocnienie) i znacznie gorsze około 2'28.297''. Siedziałem nad tym trochę i niby udało się uzyskać wszystkie bloki w całości, ale teksty w grze, pomimo że niby działa, są nieczytelne.

Pokazuje, natomiast problemem jest właściwe poprawienie, bez sumy kontrolnej to trudne.

Sam zgrywam kasety, na dość porządnym deck-u Yamahy. Teraz nie mam czasu, ale trochę póżniej pokażę na obrazku, o co chodzi.

Ha!, Już się nie mogłem doczekać update-u :). Ja też nie próżnuję. Konwersja turbo działa mi coraz lepiej. Dodałem obsługę plików HEX, w związku z tym jedna propozycja: ponieważ w pliku cas może być wiele bloków FUJI, to zamiast umieszczać nazwę w drugiej linii pliku hex może lepiej zapisywać w nim bloki FUJi tak jak inne ?
Są też początki konwersji do plików binarnych (np. xex). W drugą stronę jeszcze nie, ale nie będzie to trudne, niedługo dodam więc funkcjonalność Turgena.

Działa, ale niestety jeszcze nie za dobrze. Próbowałem wczytać przekonwertowane spyvsspy z tpp, niby się wczytuje, ale na końcu jest crash. Bez sio patch-a działa.

Jest OK. Dzięki za poprawkę, muszę dodać, że spodziewałem się pytania w stylu "a po co bloki data z zerową długością" ;). Generalnie takie bloki nie są potrzebne, można je konsolidować z następnymi blokami data, tyle że jeszcze tego nie zaimplementowałem i bug wyszedł przypadkiem.

Aha, potwierdziłem na prawdziwym sprzęcie, że polaryzacja sygnału nagrań AST (tudzież UM i ATT) rzeczywiście nie ma znaczenia.

No jak to ? TURGEN Pepików jest, nie ? ;) A może Ty zza Tatr jesteś :D ?
(żartuję oczywiście)

A, no to sorry. Nie sprecyzowałeś czego oczekujesz. A spać też trzeba ;).

Hmm... Nie wiem (jeszcze) jak z BUT i BOT, ale w AST "AST" są przechowywane sumy kontrolne. Czy to znaczy, że nie są wykorzystywane pomimo przechowywania ? Jak zatem chcesz osiągnąć 100% weryfikowalność ? Przecież różnice w pojedynczych bitach lub nawet bajtach mogą dla gier nie mieć znaczenia...
Ja nie jestem tak do końca pewien, że weryfikacji nie ma. Drugi blok danych BUT (pierwszy ma 6 bajtów, chodzi mi o ten następny) może zawierać coś w rodzaju bloku informacyjnego formatu "AST"...?

To dziwne. Ja mam wrażenie, że mi z Blizzardem konwertowanie idzie lepiej niż z AST. A może z samym samplowaniem coś nie tak ? A spróbuj np. z -> tym plikiem.
Nawiążę od razu do Turbo Rom-u. Ten system jest najszybszy z wszystkich, którymi się  to zajmowaliśmy. Zdaje się, że podstawową trudnością będzie prawidłowe zgranie sygnału. Dostałem pierwszą garść informacji - zasada zapisu jest ta sama co przy innych systemach, czyli różne szerokości impulsów dla bitów  0 i 1. Sygnał z głowicy jest przepuszczany przez wzmacniacz o troszkę zmienionej charakterystyce niż w oryginalnym (niestety nie wiem na czym ta różnica polega) Potem bramka CMOS zmienia sinus na prostokąt. Najprawdopodobniej próbkowanie na normalnym magnetofonie nie daje tego samego wyniku co odtwarzanie na magnetofonie atari i stąd problemy.

EDIT:
Jeżeli jeszcze się przydadzą, oto sprawdzone, działające, przekonwertowane pliki. 'pwmc' jest już zapisane w zmienionym formacie, opis nowych bloków -> tutaj.
blinky, gremlins, gunfighter
Hacker niestety jest zbyt uszkodzony w przynajmniej jednym miejscu, żeby się z automatu przekonwertował. Myślę, że należało by go zsamplować trochę głośniej.
Blinky chyba jednak ma jakąś kontrolę parzystości - "suma" XOR dla wszystkich bloków (oprócz dwóch pierwszych ładujących loader) wynosi 0, to raczej nie przypadek.

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

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