451

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

FUJI napisał/a:

Ale przecież możesz pliki z jednej dyskietki porozdzielać pojedynczo na kilka dyskietek :P. A w kwestii traktowania CAS - to jest odpowiedni moment, żeby ustalić, jak traktować, więc ustalajmy. Jak by co to ja ginąć za swoje idee nie będę ;), ale większość może się przychylić do tego lub innego rozwiazania.

Sam widzisz, jak na razie nie zgłosił się nikt, komu nie wystarczałyby wielokrotne bloki FUJI.

FUJI napisał/a:

A no właśnie z sentymentu. Albo dla wygody, jak to jest w przypadku megaobrazów (1MB) dyskietek z grami.

No patrz, a ja dla wygody z megaobrazów wyciągnąłem wszystkie pliki i trzymam je osobno na PC. De gustibus...

FUJI napisał/a:

A poza tym np. emulator w każdej chwili można zatrzymać, wymienić cas i puścić dalej, więc tu problemu kilku sekund na zmianę nie ma.

No dobrze, zamiast tego masz problem kilku sekund na zatrzymanie emulatora.

FUJI napisał/a:

Nie, nie o to mi chodzi ! :D (...)

Ja tylko pytałem "po co takie rozszerzenie". Nie rozumiem jak Twój argument o rezerwie na przyszłość się ma do mojego pytania.

FUJI napisał/a:

Niezupełnie. Według handlera dostępnego na Atariki działa to tak (przy odczycie): (...)

Hej, dzięki. Skłoniłeś mnie do przyjrzenia się temu dokładniej - rzeczywiście jest coś na rzeczy. Jak będę miał czas to się tym zajmę.

FUJI napisał/a:

ZIP ? Mnie ani ziębi, ani grzeje. Przy pracy z emulatorem na pewno by było wygodniej.

Nie tylko, np. CAS2SD mógłby też korzystać z informacji zawartych w atari.cfg.

FUJI napisał/a:

Aha! A nie można tego zostawić na później ? Mnie podział według bloków - nomen omen - FUJI na razie zupełnie wystarczy ;).

Jasne, to jest zupełnie osobna sprawa. Po prostu rzucam zawczasu temat do dyskusji, może trafią się jakieś wartościowe przemyślenia.

XML, no psiakrew.

452

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

No, a w przyszłości także definicje 3D pudełek i akcesoriów. Ale to akurat nie jest specyficzne dla Atari, więc wydzieliłbym to na osobny, "ogólnoemulatorowy" projekt.

:)

A tak całkiem poważnie, to może byśmy zaczęli dyskusję nad formatem tego ZIP-a już teraz? W niczym to nie zaszkodzi. Być może powstanie jakaś konkretna specyfikacja formatu, którą będzie można "na sucho" zastosować np. w bazie gier na Atarionline czy Atarimanii, jeszcze zanim dojdzie do implementacji obsługi tegoż formatu w emulatorach.

453

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

maw napisał/a:

czy jak AST to to także blizzard ?

Nie, Blizzard nie. Software do Blizzarda przy odczycie używa przerwań liczników POKEY-a (albo przerwań PIA, nie jestem pewien) i wymaga ich emulacji z dokładnością do cyklu procesora. Atari800 na razie ma ich emulację tylko z dokładnością do skanlinii. Gdyby nie to, mógłbym za jednym zamachem od razu zaemulować odczyt z wszystkich turbów.

Zobacz też.

Fox napisał/a:

Mogę zrozumieć oba podejścia:

Ja też, ale zob. niżej.

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

W ogóle ten problem powinien zostać rozwiązany w sposób jednolity dla dyskietek i kaset - powinna być możliwość jakiegoś grupowania kilku obrazów taśm/dyskietek w archiwa z możliwością łatwego przełączania pomiędzy nimi.

a. Podobne nazwy plików, różniące się końcową cyfrą lub literą. Atari800Win PLus ma komendę łatwego przekładania takich obrazów dysków - wymaga ona aktualizacji, aby działała też na nazwach takich, jak na atarionline (z nawiasami).
b. Atari800 ma opcję zapisu i odczytu "Disk Set" - pliki tekstowe, w każdej linii nazwa pliku. Moim zdaniem chybiony pomysł.
c. Paczkę trzymamy w ZIP.

Do tego zmierzam, problem nie dotyczy tylko CAS, więc nie powinien być rozwiązywany na poziomie formatu CAS.

Pomysł z ZIP-em chodzi mi po głowie już od dawna. Wywaliłbym punkty a. i b., a dodałbym jeszcze
d. W ZIP-ie znajduje się plik tekstowy, powiedzmy "atari.cfg" który zawiera wszelkie informacje o wymaganiach systemu:
- wymagany model Atari(400/800, XL/XE, 1200XL, 5200)
- wymagana wersja OS-a, BASIC-a
- czy program jest (oryginalnie) NTSC, czy PAL
- wymagane rozszerzenie RAM
- rodzaj używanych manipulatorów
- czy wymaga 4 manipulatorów (400/800)
- czy polega na efekcie artefaktów
- dla obrazów cartridge'y - typ cartridge'a
- sposób ładowania (START, OPTION, CLOAD, RUN"D:nazwa")
- a nawet takie rzeczy, jak lista używanych klawiszy (żeby ułatwić emulację na platformach, na których nie ma klawiatury)
Zawiera też informacje o zawartych w ZIP-ie plikach:
- dla każdego pliku jego nazwa user-friendly (np. Goonies strona A, B)
- typ każdego pliku (obraz taśmy, dysku, cartridge'a, plik w BASICU, plik COM)
- czy dany plik używa niestandardowych procedur odczytu/zapisu (innymi słowy czy działa z SIO patchem)
- czy dany plik może być modyfikowany (np. zapisywane jest high score)
- kolejność plików: który z nich jest tym "pierwszym" do załadowania w emulatorze

Wszystko po to, żeby umożliwić wygodne uruchamianie programów - kaset, dysków, czegokolwiek - w emulatorze za pomocą pojedynczego kliknięcia na ZIP-ie, bez konieczności grzebania w konfiguracji.

Jak widzicie, przygotowanie czegoś takiego to dość sporo pracy. Ale ponieważ planuję się tym kiedyś zająć, to nie zamierzam teraz implementować podzbioru opisanej powyżej funkcjonalności w samym formacie CAS. Ograniczę się do obsługi wielokrotnych bloków FUJI.

454

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

FUJI napisał/a:

- jeżeli powstanie cas2sd, to nie będzie miało 14'' ekranu, tylko raczej wyświetlacz 16x2. Jak się załaduje .cas o tytule np. "An Invitation to Programming", to nie będzie można przewinąć do "An Invitation to Programming - Lesson 4", bo będzie i tak widać "An Invitation to", a następny program w kolejności mógł by się nazywać "An Invitation to Grzybsoniada - tape contest" (głupi przykład, ale wiadomo o co mi chodzi). A tak - w górnym wierszu mamy "An Invitation to" a w dolnym "Lesson 4" - to przykład sytuacji, w której soft ma rozróżniać jedno od drugiego

A czemu miałaby się nazwa nie przewijać, np. automatycznie? Przecież urządzenie jakoś musi sobie radzić także z długimi nazwami plików CAS. Jak sobie np. radzi z tym SIO2SD?

FUJI napisał/a:

- bo nie należy zakłądać, że jeden plik cas = jeden program. Kaseta ma dwie strony i np. 30 minut na zapis z każdej. Na jednej dyskietce nie przechowuje się zawsze jednego programu, na jednej kasecie też nie.

Dyskietki nie możesz rozciąć na pół żeby nadal działała, a z taśmą możesz to zrobić. Lepiej traktuj CAS nie jako format archiwizacji kaset, ale jako format archiwizacji programów z taśm.

FUJI napisał/a:

W jednym pliku atr nie przechowuje się zawsze jednego programu, w jednym pliku cas też nie trzeba. Dlaczego mojej ulubionej kasety z programami w basicu nie mam przechowywać w całości w jednym pliku cas ?

A niby dlaczego miałbyś tak robić, skoro zdrowy rozsądek podpowiada inaczej? Chyba tylko z sentymentu, ale skoro tak, to chyba lepiej żebyś nie miał możliwości przewijania inaczej niż po blokach, żeby było to bliższe pracy z rzeczywistym magnetofonem ;)

FUJI napisał/a:

- bo można też sprawę zamknąć stwierdzeniem, "ale po co? przecież można każdy kawałek mieć w oddzielnym pliku cas i go sobie podczepić w emulatorze w razie potrzeby zamiast przewijać"

No nie bardzo, bo czasem są programy składające się z kilku części które ładują się jedna po drugiej automatycznie - czyli użytkownik na załadowanie kolejnego pliku CAS miałby kilka sekund zanim ładowanie się wysypie.

FUJI napisał/a:

- bo jak zobaczę na ekranie "Rewind to beginning of side B", to chcę zmienić stronę kasety, a nie przewinąć dalej

To wtedy ładujesz sobie do emulatora plik CAS z obrazem drugiej strony kasety. Tak samo przecież robisz z obrazami dyskietek.

W ogóle ten problem powinien zostać rozwiązany w sposób jednolity dla dyskietek i kaset - powinna być możliwość jakiegoś grupowania kilku obrazów taśm/dyskietek w archiwa z możliwością łatwego przełączania pomiędzy nimi.

FUJI napisał/a:

- żeby zostawić rezerwę na rozbudowę formatu w przyszłości, żeby nie trzeba było czekać następnych 10 lat aż ktoś się zdecyduje na zmiany.

?!? czyli jak nie dodamy nowych typów bloków to będzie mniejsza rezerwa na przyszłość?

Wgrałem właśnie nową wersję A8CAS - poprawiłem m.in. zgłoszony przez FUJI błąd z Feudem. Dodatkowo możecie sobie potestować ładowanie taśm w turbo AST pod emulatorem.
http://students.mimuw.edu.pl/~tk197881/a8cas/ast-loading.png

455

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

FUJI napisał/a:

Cztery programy sa w jednym pliku cas (tak naprawdę to 3, ostatni podzielony na dwie strony). Przewinięcie do początku konkretnego programu nie stanowi problemu.

Stanowiłoby jeszcze mniej problemu gdyby każdy program był w osobnym pliku CAS - taka jest konwencja jak dotychczas.

FUJI napisał/a:

Nie widać natomiast w ogóle, gdzie zaczynają się integralne części gry, np. levele w Phantomie (tudzież strony kasety) czy sceny w Goonies. Oczywiście te informacje muszą być dodane ręcznie. Tradycyjny blok FUJI nie jest wystarczający, gdyż nie pozwoli odróżnić, gdzie się zaczyna część danego programu, a gdzie całkiem nowy program.

A jaka jest różnica między obiema sytuacjami z punktu widzenia użytkownika? W obu sytuacjach użytkownik chce przewinąć do "czegoś". Po co rozróżniać?

FUJI napisał/a:

Przykładem jest powyższy Bertyx, który jest jednym programem, ale musiał być podzielony na dwa.

Bertyx to zły przykład - wszystkie części są ładowane sekwencyjnie, użytkownik nie musi nic przewijać żeby wczytać grę. Inaczej niż Goonies.

FUJI napisał/a:

Mam dwie propozycje: (...)

Ale po co to wszystko? Można to przecież zapisać w opisie w 'FUJI'. Nie wiem po co te dane miałyby być interpretowalne przez software.

FUJI napisał/a:

Z innych wieści - nowy snapshot AtariSIO jest już do ściągnięcia ze strony autora -> http://www.horus.com/~hias/atari/atarisio/. Działa wyśmienicie. Nawet odtwarzanie plików cas po konwersji w locie na bity FSK działa dobrze w przypadku bloków danych o standardowej długości. Teoretycznie są nawet widoki na obsługę formatów turbo wykorzystujących szerokość impulsu do kodowania bitów, ale to na razie tylko teoria.

Trochę nad tym myślałem - odczyt turbo z plików dźwiękowych będzie dość prosty do zrealizowania w bibliotece A8CAS. Jak będę miał czas to do tego przysiądę. Z zapisem będzie trudniej - będę musiał przeorać interfejs biblioteki. Może jesienią...

456

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

pavros napisał/a:

Racja, więc się nie upieram. Faktycznie trzeba poprawić emulatory. W przypadku jednak przyspieszonego wczytywania CASa przez emulator może być z tym pewien problem - emulator musi z góry wiedzieć ile OS przeznacza czasu na sygnał "pilota".

Należy założyć że SIO patch ma prawo działać tylko z oryginalnymi procedurami SIO do obsługi kaset - jeśli jakiś program ma własne procedury odczytu, to SIO patch nie ma nawet jak się o tym dowiedzieć. To chyba sensowne założenie.

Mając takie założenie, myślę że możliwe będzie wykrycie, czy OS czeka swoje 8 sekund na pilota czy nie.

pavros napisał/a:

Nie, nie chodziło mi o przechowywanie "katalogu" programów czyli jak rozumiem np. całej kasety w jednym CASie, niemniej to też w konsekwencji byłoby możliwe. Chodzi o gry wielo-plikowe (czytaj powyżej).
Nie wiedziałem, że CAS może zawierać więcej niż jeden blok FUJI. To by było w sumie wystarczające, choć niezgodne ze sposobem, w jaki gry wielo-plikowe są zgrywane obecnie. Czy którykolwiek emulator to wspiera?

Ja rozumiem. Żaden emulator teraz tego nie wspiera. Ale gdyby był support dla wielu bloków FUJI (z możliwością przewijania do każdego z nich) to byłoby to rozwiązanie wystarczające?

FUJI: sprawdziłem na Feudzie, istotnie coś nie gra w patchu do emulatora. Wgrywa się za to przy baudrate 2500 ;). Zajmę się tym.

A w międzyczasie, na stronie A8CAS dostępna jest już wersja dla Windows.

457

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

FUJI napisał/a:

Zabawy z krótkimi sygnałami FSK w AtariSIO wymagają kombinowania, w zależności od wersji kernela jest to realizowane tak lub inaczej.
A może od strony liba8cas da się stworzyć dodatkowy interfejs "at byte-level" ? W razie czego możecie sobie pogadać jak programista z programistą ;).

No to skrobnę coś do Hiasa, jak będę miał czas. Interfejs na poziomie bajtów i tak zamierzałem stworzyć - na potrzeby wsparcia dla "SIO patcha" w emulatorze. Ale ciekaw jestem, jak Hias chce "at byte-level" wysyłać długie sygnały FSK.

FUJI napisał/a:

Aha, jeszcze jedno, to do Ciebie, Krótki. Czy testowałeś na emulatorze działanie Turbo 2600 przy prędkościach turbo ?

Tak. A którą wersję liba8cas i atari800-a8cas masz? W ostatniej powinno być wszystko w porządku.

458

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

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

459

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

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.

460

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

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.

461

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

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.

462

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

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?

463

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

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.

464

(7 odpowiedzi, napisanych Bałagan)

Ad3: http://www.viksoe.dk/code/adfview.htm

465

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

To Aztec Challenge było na kartridżu?

466

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

Sam tam dopisałem tego Datamarka. We wspomnianym artykule masz link do wątku na AtariAge ze zdjęciami.

467

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

Dzięki za wyjaśnienie.

468

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

seban napisał/a:

Pierwsze słyszę aby jakieś modele magnetofonów nie obsługiwały stereo.

Dobrze wiedzieć. Dawno temu wyczytałem coś takiego bodajże w Bajtku. Zatem pewnie się pomyllili. A może chodziło nie o odczyt, ale o zapis w stereo. Czy wszystkie typy magnetofonów zapisują sygnał tylko na prawej ścieżce?

seban napisał/a:

To że słyszałeś prawą ścieżkę mogło oznaczać tylko jedno, złe ustawienie skosu głowicy, następował przesłuch między kanałami i tyle.

Możliwe. Wczytywał wszystko idealnie, mogłem nawet nie wiedzieć.

469

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

Ściągnąłem sobie z TPP program An Invitation to Programming. Utwór ów jest stereofoniczny, prawa ścieżka zawiera dane, na lewej miła pani opowiada.

W teorii wszystko się zgadza. Z prawej ścieżki Atari odczytuje sygnały, a lewa jest wysyłana na Audio Input gniazda SIO i  słyszymy ją w głośniku.

Ale w takim razie, skoro na głośnik jest wysyłana tylko lewa ścieżka, to jak w takim razie mam przed wczytaniem przewinąć taśmę do początku programu, skoro nie słyszę "pisku" (jest on nagrany tylko na prawej ścieżce)? Jak wg producenta powinienem sobie z tym radzić?

Druga sprawa: późniejsze modele magnetofonów nie obsługują stereo. Które konkretnie? Czy na takich magnetofonach słychać w głośniku obie ścieżki, czy np. tylko prawą? (Na moim XCA12 na 100% słychać było prawą ścieżkę, ale magnetofonu już dawno nie mam i nie mogę zweryfikować.)

470

(13 odpowiedzi, napisanych Programowanie - 8 bit)

Candle napisał/a:

na ekranie wciaz wejdzie ci 240 linii - pamietaj ze zajma one wiecej tego ekranu - literki tez sa wyzsze...

Ale na telewizorach NTSC (szczególnie starszych) nie wszystkie są widoczne. Nie bez powodu obraz standardowo ma 192 linie.

pavros napisał/a:

Jesli chodzi o odtwarzanie muzyki stworzonej dla PAL na NTSC, to na przyklad w IK+ dla C64 zastosowano prosta sztuczke polegajaca na tym, ze w co 6-stej ramce VBL nie jest wykonywane wywolanie procedury playera.

Taką samą sztuczkę zapewne zastosowano w World Karate Championship na Atari - ale nie dam głowy. W każdym razie muzyka w WKC jest wolniejsza względem IK.

471

(13 odpowiedzi, napisanych Programowanie - 8 bit)

Oraz http://atariki.krap.pl/index.php/Rejest … C-a#VCOUNT :)

472

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Candle napisał/a:

TeBe, tak, ale dosc od niedawna wiadomo ze liczy (w ntsc) od 0 do 131, a wedle dokumentacji do 130, co daje te 264 linie - czy sa czy ich nie ma, ciezko zgadnac

Candle, a czytałeś ten wątek? Simius miał podobny objaw z Atarką w systemie PAL - VCOUNT zliczał mu do 156 (czyli tak jakby PAL miał 314 linii). Okazało się, że ta wartość 156 pojawiała się w VCOUNT na mniej niż 4 cykle zegara, po czym zmieniała się na 0. Może w Twoim przypadku jest podobnie?

Na emulatorze działa, więc i na prawdziwym Atari powinno.

Czy u Ciebie chociaż "coś" się wczytuje? Tzn. czy po siedmiu rekordach pojawia się na ekranie LOADING ABRACADABRA?

Sprawdź też, czy Twoja wieża nagrywa plik na obu kanałach (lewym i prawym). Jeśli tak, to dobrze.

W tym regulowaniu skosu głowicy to nie chodzi tylko o Twoją wieżę, ale także o magnetofon Atari. Jeśli po wpisaniu POKE 54018,52 i puszczeniu taśmy zauważasz na słuch, że jakość odtwarzania na magnetofonie jest gorsza w porównaniu z wieżą (np. dźwięk jest przytłumiony), to znaczy że trzeba wyregulować magnetofon.

Sprawdź jeszcze, czy dźwięk wychodzący z laptopa nie jest za głośny albo za cichy - to też ma wpływ.

Poza tym, łatwiej nam będzie jak powiesz, z jakiego pliku CAS korzystasz.

475

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

No i z niedzieli zrobił się wtorek. W każdym razie,

Duddie napisał/a:

Nie rozważałem jeszcze w jaki sposób rozszerzyć format .CAS tak, aby możliwe było stosowanie zabezpieczeń zapisu. Może faktycznie będzie to zapis surowych impulsów, chociaż to zajmie więcej miejsca.

Właśnie takie rozwiązanie przyjąłem - do formatu CAS dodałem nowy typ rekordu (obok istniejących 'data' i 'baud'): 'fsk ', który zawiera długości kolejnych impulsów w milisekundach (16 bitów na każdy impuls). Podczas kodowania do CAS  każdy blok którego nie uda się rozpoznać jako 'data', jest zapisywany w formie 'fsk '.

Takie rozwiązanie w zupełności wystarczało w przypadku zabezpieczeń, na które się natknąłem - a natknąłem się tylko na jeden typ: gdy pomiędzy normalnymi rekordami na taśmie znajduje się sekunda albo dwie ciągłego sygnału '0'. Taki sygnał zapisuję w bloku 'fsk ' jak poniżej:

66 73 6B 20 ; nagłówek 'fsk '
02 00 ; długość bloku, 2 bajty
00 00 ; pomijane - każdy nagłówek w CAS ma 8 bajtów
5F 06 ; 1631 milisekund sygnału '0'

Być może to rozwiązanie nie wystarczy dla bardziej zmyślnych zabezpieczeń (rozdzielczość w milisekundach może być za mała), ale jeszcze takich nie widziałem.

Zapis surowych impulsów oczywiście zajmuje więcej miejsca, ale ma tę zaletę, że da się to prosto oprogramować. Praktycznie bowiem nie ma 100% skutecznej metody rozpoznawania typu rekordu ('data' czy jakiegokolwiek innego) - gdy napotkasz na jakiś nietypowy rekord, warto mieć w zanadrzu możliwość zapisania go w formie czystych impulsów.

Zresztą ten wzrost zajmowanego miejsca nie jest tak tragiczny. Np. taka "Misja" Avalonu ma ponad 300 rekordów, po konwersji do CAS zajmuje ok. 40 KB. Ale plik ten zawiera ok. 200000 impulsów, czyli gdyby zakodować go w formie "surowej" po 2 bajty na impuls, to mielibyśmy ok. 400 KB, więc wzrost rozmiaru jest raptem 10x. I ciągle jest to mniej niż choćby nagranie mp3.

Duddie napisał/a:

Do niezabezpieczonych programów może być zwykły .CAS. Odtwarzanie muzyki, która znajduje się na prawej ścieżce? Czemu nie, podłączenie urządzenia do Audio In nie stanowi problemu. Tylko pytanie, jak je przenieść na kartę SD. Bezpośrednio z Atari to się nie uda, kompresja .mp3 odbywałaby się na PC, ale.... jak to później zsynchronizować z lewą ścieżką?

Zastanawiałem się nad tym kiedyś, ale dobrego rozwiązania jeszcze nie mam. Może trzymać w pliku CAS jakieś dodatkowe bloki, informujące o tym ile sampli należy przeczytać, zanim skończy się następny rekord 'data'? Wtedy gdy podczas odtwarzania okaże się, że rekord się "skończył" zanim wszystkie sample zostały odczytane, można by po prostu wstawić dłuższą przerwę IRG. Alternatywnie, gdyby wcześniej skończyły się sample, można by zapewnić, że następny rekord będzie odczytany z prędkością powiedzmy 1.05x szybszą niż oryginalna; albo wstrzymać na chwilę odtwarzanie WAV-a.

Duddie napisał/a:

Całość na pewno sprzętowo będzie dość podobna do SIO2SD. Krótki, czekam w takim razie na Twoje uwagi odnośnie nowego formatu - i oczywiście trzymam Cię za słowo, że zajmiesz się oprogramowaniem tegoż.... :)

Żeby nie było nieporozumień - jestem w stanie przygotować bibliotekę, które będzie odczytywać z formatu CAS/XCAS/Wav pojedyncze impulsy oraz zakodowywać owe impulsy do ww. formatów, ale to jak Ty ten mój kod wciśniesz na płytkę drukowaną to jest osobna sprawa, na tym się zupełnie nie znam.