426 Temat przez Krótki

(42 odpowiedzi, napisanych Bałagan)

:)

A` propos, jak na polski przetłumaczyć pojęcie "revision" używane w systemach kontroli wersji? Bo jakiś czas temu w firmie zastanawialiśmy się nad tym całkiem poważnie,... i zostaliśmy przy "rewizja" właśnie.

Idź do forum: Bałagan

427 Odpowiedź przez Krótki

(152 odpowiedzi, napisanych Sprzęt - 8bit)

Dobre!

Na wkładkach w moim posiadaniu nie ma słówka CNTR, i czcionki są inne. Były dwie rewizje? ;)

Idź do forum: Sprzęt - 8bit

428 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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ć ?

Bo dzięki temu możliwe jest debugowanie plików HEX, o którym pisałem tu. Ale dobrze by było, żeby konwersja z CAS/HEX do CAS/HEX nie psuła zawartości kasety - pomyślę nad tym w wolnym czasie.

FUJI napisał/a:

E tam, się nie da.

No pewnie - skoro człowiek umie, to komputer też by mógł ;P

A całkiem serio, trudno jest "zwyczajną" nieregularność w sygnale na kiepskiej jakości taśmie od zmiany baudrate'u w środku bloku. Albo pozwalamy na nieregularności i ryzykujemy przeoczenie zmiany baudrate'u, albo dokładnie wykrywany zmianę lecz zmniejszamy tolerancję błędów, co powoduje że słabszej jakości bloki przestają się konwertować.

FUJI napisał/a:

Mimo to - obiecane linki:

Rzeczywiście - nic nadzwyczajnego ;)

FUJI napisał/a:

Spróbuj przekonwertować ten hex na cokolwiek i z powrotem i otrzymać taki sam hex (np. bezpośrednio hex->hex).

Nie da rady, ale tylko dlatego, że wewnętrzny bufor sygnałów ma na sztywno ustawiony rozmiar 50 - a w twoim pliku żeby dobrze rozpoznać baudrate, trzeba wczytać ze 100 początkowych sygnałów.

Ale nie zrażam się, oto wersja eksperymentalna, w której bufor sygnałów jest przydzielany dynamicznie, wiec możesz ustawić --header-length=100 i będzie OK.

Przy okazji załatwiłem kwestię niezapisywania długości bloków 'data'/'fsk ' w HEX.

Idź do forum: Sprzęt - 8bit

429 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

Przecież mój dump ma dokładnie takie parametry. Zapewne użyłeś a8cas-convert z domyślnymi parametrami. Ustaw --stop-bit-deviation=0.1.

FUJI napisał/a:

ale za to inne tasiemki przestały się konwerować, więc kombinuję dalej.

Automatu który bezbłędnie skonwertuje wszystkie taśmy _bez ingerencji użytkownika_ stworzyć się nie da. Ja u siebie rozwiązałem problem tak, że w szczególnie wrednych przypadkach użytkownik będzie musiał dostroić parę parametrów.


FUJI napisał/a:

Jak byś mógł udostępnić oryginalnego dumpa to był bym wdzięczny.

Wieczorkiem.

FUJI napisał/a:

W zamian ;) udostępnię inną tasiemkę, która też sprawia pewne problemy (obu konwerterom), chociaż w zasadzie wcale nie jest aż taka niezwykła.

A co to będzie?

FUJI napisał/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.

Wiesz co? Sprawa jest śliska. Skoro do odtworzenia oryginału jest to zbędne, to można by przyjąć założenie, że ta informacja nie powinna być w pliku CAS. Proponuję taką "granicę abstrakcji": w pliku CAS znajdują się tylko informacje niezbędne do odtworzenia oryginalnej kasety (można wtedy się kłócić, czy opisy w blokach FUJI są zgodne z tym podejściem, ale na razie to pominę). Taka granica jest w jakiś sposób naturalna.

Poza tym, emulator i tak musi sam podjąć decyzję, jak interpretować dane z taśmy. Mamy przecież taki przypadek użycia:
- kaseta nagrana w Turbo A
- magnetofony w Turbo A tłumaczą zbocze opadające na sygnał 1 DATA_IN
- user wczytuję kasetę na magnetofonie dla Turbo B i oprogramowaniu, które pozwala na magnetofonie Turbo B wczytywać programy z kaset w Turbo A
- magnetofony w Turbo B tłumaczą zbocze opadające na sygnał 0 DATA_IN
Wtedy bit sugestii w CAS jest nie tylko niepotrzebny, ale i dezorientujący.

FUJI napisał/a:

Dobrze by było się zdecydować na jednolity format...

Z jakichś powodów technicznych jeszcze tego nie zrobiłem - ale jakby co, to chcę po prostu usunąć informację o długościach bloków z formatu HEX (czyli drugą liczbę z linii "data" i "fsk "). A co sobie każdy z nas będzie zrzucać do komentarzy, to już oczywiście bez znaczenia. Acha, i znak komentarza ";" ma nie być wymagany, jeśli komentarza nie ma w ogóle.

FUJI napisał/a:

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

Rozumiem że zmiana polegała wyłącznie na zdefiniowaniu parametrów (częstotliwości, długości) tego turba? Ciekaw jestem, czy nie dałoby się tego jakoś zautomatyzować.

EDIT: Już. Konwertujemy z --stop-bit-deviation=0.3.

Idź do forum: Sprzęt - 8bit

430 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

DOC/USAGE, sekcja "Keyboard, joystick and other controllers" (szczególnie "SDL keyboard, joystick and other controllers").

Idź do forum: Sprzęt - 8bit

431 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

A bo nie zrobiłem nic spektakularnego, czym możnaby się pochwalić.

Dziś natomiast wypuściłem wersję 1.1, z dodaną możliwością dostrajania parametrów konwersji WAV->CAS z poziomu wiersza poleceń. Zostało to wymuszone przez jedną wredną kasetkę o nazwie Miecze Valdgira 2. Jest ona zabezpieczona za pomocą rekordów, w których środku zmieniany jest baudrate! Żeby poprawnie obsługiwać takie rekordy, musiałem przepisać na nowo spory kawałek kodu.

Idź do forum: Sprzęt - 8bit

432 Odpowiedź przez Krótki

(26 odpowiedzi, napisanych Bałagan)

Lt_Bri napisał/a:

Strona programowa wygląda "troszku gorzej" (niby nawet spod basica jest to wykonalne** - ale przy moich "zdolnościach" tylko i wyłącznie niby...).

Strona programowa już jest - wystarczy użyć Koali albo Atari Artist z paddlami zamiast tabliczki graficznej.

Idź do forum: Bałagan

433 Odpowiedź przez Krótki

(26 odpowiedzi, napisanych Bałagan)

BartoszP napisał/a:

na nieograniczonej powierzchni

To chyba będzie wymagać rozszerzenia RAM.

Idź do forum: Bałagan

434 Odpowiedź przez Krótki

(2 odpowiedzi, napisanych Bałagan)

W pakiecie WAV2CAS jest wielki referat na temat zapisu/odczytu kaset. Jak przebrniesz, to wiesz już wszystko.

Idź do forum: Bałagan

435 Odpowiedź przez Krótki

(8 odpowiedzi, napisanych Fabryka - 8bit)

Gdzieś ktoś pisał.

Idź do forum: Fabryka - 8bit

436 Odpowiedź przez Krótki

(6 odpowiedzi, napisanych Bałagan)

Książka już jest u Kaza - tytuł i zawartość zgadzają się z pozycją "Atari Basic. Język programowania i obsługa mikrokomputera Atari" wydaną przez NOT ODKTRS.

Idź do forum: Bałagan

437 Odpowiedź przez Krótki

(22 odpowiedzi, napisanych Programowanie - 8 bit)

A do sprawdzenia że DOS się załadował, to nie wystarczy sprawdzić flagi BOOT? ($09) ?

Idź do forum: Programowanie - 8 bit

438 Odpowiedź przez Krótki

(22 odpowiedzi, napisanych Programowanie - 8 bit)

nosty napisał/a:

Nie wiem jaka jest roznica miedzy "No disk" a "Off" w AtariWin800 ale widocznie jakas istotna jest.

No Disk to stacja włączona, ale bez dyskietki. Na prawdziwym sprzęcie jak zostawisz włączoną stację bez dyskietki to też będziesz dostawał boot errory do końca świata.

nosty napisał/a:

A to juz jest zagadka, bo koncowka carta Action! jest bez sensu. Sprawdzalem kilka wersji.

+---------------------------------------------------------------------------+
| Type 15: OSS 'M091' 16 KB cartridge                                       |
+---------------------------------------------------------------------------+

This is the simpler one of OSS schemes. It uses only A0 and A3 address
lines:
A3=0, A0=0 - $A000-$AFFF: bank 1, $B000-$BFFF: bank 0
A3=0, A0=1 - $A000-$AFFF: bank 3, $B000-$BFFF: bank 0
A3=1, A0=0 - disable cartridge
A3=1, A0=1 - $A000-$AFFF: bank 2, $B000-$BFFF: bank 0

Zatem ostatnie bajty leżą na końcu banku 0, czyli pod offsetem 0ffa-0fff.

Idź do forum: Programowanie - 8 bit

439 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

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

FUJI napisał/a:

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 ?

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?

FUJI napisał/a:

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.

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

FUJI napisał/a:

Generalnie takie bloki nie są potrzebne

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

FUJI napisał/a:

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

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?

Idź do forum: Sprzęt - 8bit

440 Odpowiedź przez Krótki

(5 odpowiedzi, napisanych Software, Gry - 8bit)

Soft się tworzy.

Idź do forum: Software, Gry - 8bit

441 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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 ?

W AST to może i działa, ale pamiętam, że nierzadko zdarzało się, że program w BUT wczytywał się bez widocznych oznak błędu do samego końca, po czym program leciał w krzaki. Zupełnie jak Hacker pod emulatorem.

FUJI napisał/a:

Jak zatem chcesz osiągnąć 100% weryfikowalność ?

Liczę na to, że w którymś momencie konwersja do CAS będzie potrafiła przynajmniej pokazywać miejsca, gdzie dane nie są 100% pewne. Wtedy będzie można zajrzeć do WAVa oczami :) i odgadnąć właściwe dane.

FUJI napisał/a:

Nawiążę od razu do Turbo Rom-u. (...) Najprawdopodobniej próbkowanie na normalnym magnetofonie nie daje tego samego wyniku co odtwarzanie na magnetofonie atari i stąd problemy.

Nie rozumiem. Czy chcesz przez to powiedzieć że obrazy WAV które posiadasz są nieprawidłowo zgrane? Zawierają inne dane niż fizyczne kasety?

FUJI napisał/a:

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.

Wiesz w którym miejscu? Możesz podać numer sampla? Przyjrzę się temu dokładniej.

FUJI napisał/a:

Blinky chyba jednak ma jakąś kontrolę parzystości

Blinky ma jakiś custom loader, więc to prawdopodobne.

Dzięki za przekonwertowanie plików, zajmę się nimi i tym Humanoidem jak będę miał czas. Na razie chcę się skupić bardziej na dokończeniu feature'ów dot. wczytywania w normalu (SIO patch itp.)

EDIT: A oto i nowa wersja A8CAS. Nowości:
- obsługa SIO patcha do wczytywania i zapisu kaset (na razie tylko w formatach CAS i HEX);
- obsługa WAV-ów z falą prostokątną;
- nowa opcja "Turbo system->Blizzard".

FUJI, weź zobacz czy nowa wersja działa z blokami "data" długości 0. Wygląda na to że poprawiłem, ale to Ty ten błąd znalazłeś :)

Poza tym, wrzuciłem na serwer kilka nowych plików AST. Miłej zabawy ;)

Idź do forum: Sprzęt - 8bit

442 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

A cóż to ma do rzeczy?

Idź do forum: Sprzęt - 8bit

443 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

Dzięki. Aczkolwiek efekt jest dla mnie raczej bezużyteczny - chodziło mi o to, żeby mieć w ręku plik BUT ze 100% zweryfikowaną zawartością, który ładuje się poprawnie pod emulatorem, żeby na jego podstawie usprawnić proces wczytywania oryginalnego WAV-a. Teraz w sumie mogę sam go sobie przygotować, bo po ostatniej aktualizacji a8cas-tool zaczął działać bez problemu.

FUJI napisał/a:

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.

Brak weryfikacji podczas odczytu to jedna z bolączek systemu AST.

FUJI napisał/a:

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

Trochę się zmieniło od tamtego czasu - dorobiłem coś na kształt twojego latch - zmiana sygnału wykrywana jest dopiero gdy różnica między kolejnymi samplami jest większa niż "x" (konfigurowane przez użytkownika). Jednak efekty są nadal mierne - o ile pozwala to czytać AST oraz "prostokątnego" Blizzarda, to w przypadku Blizzardowych WAV-ów jitter jest nadal za duży (bo Blizzard ma krótsze impulsy niż AST). Muszę wymyślić mniej naiwne rozwiązanie. Aczkolwiek chcę uniknąć odwołać do ecasound i ladspa w źródłach liba8cas.

Prawdopodobnie skończy się to tak, że użytkownik będzie najpierw konwertował WAV do pliku CAS (podczas zapisu do CAS można dokonać bardziej dokładnej analizy) i używał emulatora tylko z CAS-ami, a wczytywanie z WAV-ów pozostanie kiepawe.

Idź do forum: Sprzęt - 8bit

444 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

Przecież "zmiana polaryzacji bez zmiany interpretacji" jest w 100% równoznaczna ze "zmianą interpretacji bez odwracania sygnału". Arkanoid z AST tak właśnie się wczytuje - działa niezależnie od interpretacji i polaryzacji (aczkolwiek inne pliki AST już się rypią).

Z Blizzardem widzę, że to nie zadziała - test głowicy pokazuje śmieci w przypadku zmiany polaryzacji/interpretacji. Ale i w tym przypadku dla software'u nie ma znaczenia wzrost czy opadanie sygnału, ale to czy jeden bit składa się z 1 i 0, czy z 0 i 1.

FUJI napisał/a:

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.

Dobra, spróbuję odwrócić interpretację. Ale zauważ, że sam plik morky.wav przy tej samej konfiguracji emulatora wczytuje mi się bez problemów.

Idź do forum: Sprzęt - 8bit

445 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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

OK.

FUJI napisał/a:

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 ?

Problem w tym, że nie mamy jak zdecydować o poprawnej wartości "bitu sugestii", nie wiedząc czy nasze magnetofony odwracają fazę czy nie. Najlepszym wyjściem byłaby analiza hardware'u każdego systemu turbo - tylko to pozwoli zweryfikować, czy na początku sygnału zbocze narasta czy opada.

FUJI napisał/a:

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

Mówiąc całkiem poważnie, nie mogę zacząć mówić o wierności danych w chwili gdy sam nie wiem, czy mój magnetofon odwraca fazę czy nie.

FUJI napisał/a:

Nie gniewaj się, ale na razie działanie emultora nie może być wyznacznikiem działania rzeczywistego sprzętu ;)

Wręcz przeciwnie. Udało mi się zweryfikować, że programy AST wczytują się "lepiej" (mniej błędów), gdy "pierwsze" zbocze sygnału jest interpretowane jako 1 (celowo użyłem słowa "pierwsze", a nie "narastające" czy "opadające"). Kaseta z Arkanoidem działała przy obu interpretacjach chyba tylko przez przypadek.

FUJI napisał/a:

Ale skoro cas MUSI zawierać to co HEX, to trudno.

Nie musi, po prostu było to dotychczas wygodne.

FUJI napisał/a:

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

Działa (po uprzednim zhackowaniu Atari800 żeby wspierał fale prostokątne). Tylko nie wiedzieć czemu, po zakończeniu ładowania ml25-t.wav, Atari robi zimny start. Muszę coś specjalnie ustawić w emulatorze?

Więc zamiast robić 2 pierwsze kroki, użyłem po prostu Microloadera z cartridge'a Phoenix Hurka.

FUJI napisał/a:

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

Nie działa:

$ ./a8cas-util.pl conv -t ast Arkanoid.wav Arkanoid.cas
Argument "Usage: ecalength [-ahtsfmbcru] FILE1 [FILE2] [FILEn]" isn't numeric in numeric eq (==) at ./a8cas-util.pl line 1592.
Starting ecasound... started.
SUMMARY: Data blocks: 0, checksum errors: 0, non-standard data blocks: 0, long zeros: 0, read 251 input bytes.
Can't close input stream. at ./a8cas-util.pl line 1550.

A "./a8cas-util.pl --man" wyświetla mi całą zawartość pliku źródłowego, a nie instrukcję.

Wrzuciłem na stronę A8CAS więcej plików AST - zarówno w formacie AST, jak i BUT. Większość AST-ków wgrywa się pod emulatorem, ale nie wiedzieć czemu z żadnym BUT-em nie osiągnąłem sukcesu. Czy mógłbyś użyć swojego skryptu na jednym z plików BUT i podrzucić mi plik z prostokątną falą, analogiczny do Twojego morky.wav? Miałbym wtedy materiał do dalszych testów.

Idź do forum: Sprzęt - 8bit

446 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI napisał/a:

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.

Jak? Opis tych 2 bitów nie mówi jak to zrobić. Powinieneś w takim razie opisać te bity tak:

aux1 - dwa najmniej znaczące bity (1 i 0) określają rodzaj impulsu:
01 - szerokość impulsu określa czas trwania sekwencji zbocza rosnącego i malejącego fali dźwiękowej (długość obu zboczy jest równa)
10 - szerokość impulsu określa czas trwania sekwencji zbocza malejącego i rosnącego fali dźwiękowej (długość obu zboczy jest równa)
00 i 11 - w rezerwie

lub na odwrót. Wtedy rzeczywiście będzie można powiedzieć, że orygnalna postać zapisu może być odtworzona.

FUJI napisał/a:

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.

Fizycznie posiadasz te kasety z nagraniami, czy tylko zgrane pliki WAV? Bo spotkałem się z magnetofonami które miały odwróconą polaryzację - być może część plików WAV była zgrywana na takim magnetofonie.

FUJI napisał/a:

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 ?

Szczerze wątpię, aby producent turba pozwalał sobie na wprowadzenie takiej niekompatybilności bez powodu. Jeśli zmieniała się interpretacja zboczy w hardware'rze, to na pewno zmieniała się też w software'rze. Cart z magnetofonem tworzą niejako nierozerwalną parę.

FUJI napisał/a:

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.

W sumie masz rację - sygnał można nazwać zerem lub jedynką dopiero po przetrawieniu przez hardware w magnetofonie. Wyobrażam sobie teoretyczną sytuację, gdzie biorę taśmę z Turbo 2000 i wgrywam ją na magnetofonie AST (używając programu "AST->Turbo 2000 Konwerter", był kiedyś taki). Gdyby założyć że Turbo 2000 ma odwrotną polaryzację niż AST, to nasza informacja o polaryzacji zachowana w CAS tylko utrudniałaby sprawę.

Zatem zgoda. Ale w takim razie pojęcia '0' i '1' nie mogą się pojawić w specyfikacji CAS.

FUJI napisał/a:

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

Ja już bym wolał po prostu dostosować polaryzację źródłowego WAV-a tak, żeby działała z dostępnym oprogramowaniem (np. z tym Blizzarda które obecnie znamy), niż wprowadzać taki przełącznik, bo to zawsze komplikuje interfejs użytkownika. Ale zobaczymy.

BTW. Nie wiem jak to jest zrobione, ale system AST nie zwraca uwagi na kolejność zboczy w sygnale - łatwo sprawdzić pod emulatorem.

FUJI napisał/a:

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.

Obstawiam, że jedyna różnica w sofcie 1010 i XC12 leży w sposobie przełączania magnetofonu normal<->turbo.

FUJI napisał/a:

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.

To czekam. Wrzuć gdzieś może także ten plik Blizzarda utworzony z CAS-a, który Ci działał pod emulatorem.

FUJI napisał/a:

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.

Zaraz, jak zbędne, przecież Ci tłumaczyłem, że to służy do debugowania bloków z dużym baudrate.

FUJI napisał/a:

Do celów debugowania przy konwersji można zapisywać coś takiego do hex, ale czy trzeba do cas ?

HEX zawsze = CAS - w obu formatach można zapisać dokładnie te same dane. Tak było w WAV2CAS Schreursa, tak jest u mnie i chcę żeby tak pozostało.

FUJI napisał/a:

A może zapisywać częstotliwość próbkowania nie w samplach na sekundę, tylko w setkach sampli na sekundę ? (...)

Sam mówisz, że załadowałeś z Blizzarda przy częstotliwości 48000. Więc może nie ma o czym mówić na razie.

Idź do forum: Sprzęt - 8bit

447 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

A właśnie: w bloku "pwms" brakuje informacji, czy logiczna 1 jest wtedy, gdy zbocze sygnału opada, czy gdy się wznosi. Bez tego nie da się z CAS-a odtworzyć oryginalnego WAV-a.

Idź do forum: Sprzęt - 8bit

448 Odpowiedź przez Krótki

(5 odpowiedzi, napisanych Software, Gry - 8bit)

W U.S. Tour trzeba przejechać przez wszystkie miasta.

Idź do forum: Software, Gry - 8bit

449 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

O! teraz jest prościej i elastyczniej. Podoba mi się.

FUJI dzięki za bugreporty. Z tym flacem prostokątnym to wynika z naiwnej wersji dekodera PWM:

sygnał = (sample > poprzedni_sample)

czyli jest źle jak 2 próbki pod rząd mają tę samą wartość.

Chciałbym niebawem zacząć dodawać obsługę nowych typów bloków do A8CAS. Czy sądzisz że obecna postać jest w miarę ostateczna? Zajrzałeś jeszcze to tego Turbo ROM-a? Tak mi chodzi po głowie - być może w przyszłości zamiast rozszerzać blok 'pwms' pod dziwactwa w stylu Turbo ROM bardziej elegancko byłoby stworzyć nowy typ bloku, taki 'pwms' tylko dla Turbo ROM?

Uwaga dot. zapisu częstotliwości próbkowania. Zauważyłem podczas moich prób z emulacją odczytu Blizzarda, że przy częstotliwości 48kHz bardzo zauważalne są wahania w długościach sygnałów (jitter), i że raczej nie wyjdzie emulacja, jeśli nie spróbuję podbić częstotliwości sygnału dźwiękowego do np. 96kHz (nie trzeba nagrywać w takiej częstotliwości, wystarczy dobrej jakości upsampling). Ale ponieważ bloki 'pwmi' mają być wykorzystywane do debugowania kaset podczas konwersji, to wydaje się sensowne, żeby w nich także była możliwość ustawienia takiej wysokiej częstotliwości próbkowania. Ale 96000 w 2 bajtach w bloku 'pwms' się nie zmieści. Może więc 4 bajty?

Blok 'pwmc': Hmmm. Nowy blok na każdy sygnał? A może niech blok 'pwmc' przechowuje w sobie dowolną ilość sygnałów?

$70 $77 $6d $63  ; 'pwmc' - PWM cycles
$02 $00          ; długość bloku = 3*ilość sygnałów
$LL $MM          ; (aux1,2) IRG, czyli cisza, w ms

i teraz po 3 bajty na każdy nowy sygnał:

$xx              ; szerokość impulsu wyrażona w próbkach
$LL $MM          ; ilość impulsów (cykli 0-1 lub 1-0)
...

Idź do forum: Sprzęt - 8bit

450 Odpowiedź przez Krótki

(119 odpowiedzi, napisanych Sprzęt - 8bit)

FUJI, generalnie się zgadzam. Zastanawiałem się nad tym, i rzeczywiście, możliwość obsługi nowych formatów turbo bez modyfikacji kodu jest zaletą, która ostatecznie mnie przekonała do takiego rozwiązania.

Parę uwag:

1. Patrząc po źródłach Turgena, widzę że Czesi wymyślili system turbo do odczytu z płyt CD, gdzie długość sekwencji "niski-wysoki" wynosi dokładnie 2/44100 s, czyli po prostu 1 próbka < 0 i 1 próbka > 0. Zatem może należałoby nie ustalać odgórnie, że jednostką są setne ms, tylko dodać do bloku "pwms" parametr określający "częstotliwość próbkowania".

Np. mamy Blizzard, gdzie są sygnały 0.5 ms, 0.25 ms i 0.166 ms. Ustalasz "częstotliwość" na 12000 (czyli 1/12 ms) i potem defniniujesz wszystkie długości sygnałów na podstawie tej wartości. Sygnały w Blizzardzie wtedy mają długość odpowiednio 6, 3 i 2 próbek.

A Czesi ustawiają dla tej swojej płyty CD "częstotliwość" 44100 i wszyscy są zadowoleni.

2. Czy w nagraniach turbo występują bity startu i stopu? Jeśli nie zawsze, to przydałby się typ bloku analogiczny do "pwmd", reprezentujący dane bez tych bitów.

3. Wstrzymałbym się z wprowadzaniem do formatu hacków specyficznych dla Turbo ROM (aux1=00 i 11), póki nie rozgryziemy software'u do jego obsługi. Może te nieregularne długości impulsów są wynikiem błędu w procedurze nagrywającej, a software radzi sobie z odczytem nawet gdy zapoda mu się plik ze sztucznie wyrównanymi długościami impulsów?

4. Skoro blok "pwms" będzie występował w obrazie taśmy raczej tylko raz, to może nie warto ograniczać długości pola "liczba impulsów pomiędzy pilotem i danymi" do 2 bitów?

5. Co to znaczy IRG w przypadku bloków "pwmd" i "pwmi"? Chcesz tam trzymać długość ciszy przed rekordem?

6. Długości sygnałów w bloku "pwmi" też trzymałbym nie w setnych milisekund, ale w jednostkach definiowanych przez jakąś liczbę umieszczoną na początku bloku - analogicznie do uwagi nr 1.

A'propos wersjonowania CAS-ów - numer wersji zwiększałbym tylko gdy zachodzi zmiana w formacie bloku. Dotychczas wprowadzamy tylko nowe typy bloków, więc wersja może pozostać 0 - istniejące implementacje obsługi formatu CAS i tak powinny domyślnie ignorować bloki, których typu nie rozpoznają.

Podrzucę inne nagrania AST jak będę miał czas, za parę tygodni - ale generalnie nie należy się spodziewać rewelacji; bloki w AST-owskich formatach AST, BUT i BOT mają taką samą strukturę jak w dostępnym przykładzie.

Mam też kasetę w formacie "jakiegoś" Turbo 2000, to też się podzielę.

Idź do forum: Sprzęt - 8bit