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.

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

No to skrobnij, bo już mu kazałem czekac na kontakt ;). A jeżeli chodzi o wysyłanie zer (bo z jedynkami to nie problem), oto co pisze:

Wydaje mi się, że najnowszą. Ze starszą to w ogóle nie działało, z tą przy niższej prędkości działą, a przy wyższej nie bardzo. Popróbuję jeszcze później.

Spoko, jeżeli dobrze Cię rozumiem, to w emulatorze też działa jak należy.

A rozdział części według długości przerw między nimi chyba jest wystarczający... Sam nie wiem - zawsze może się trafić program, który między częściami ma przerwy krótsze niż normalnie...  W sumie taki znacznik nie jest głupi, bo mógło by go wykorzystywać oprogramowanie typu AtariSIO, żeby w odpowiednim momencie przerwać wysyłanie cas-a (nie trzeba by pilnowac spacji).

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.

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.

To ja może uporządkuję sprawę podziałów na pliki, części itp. Mój nowy skrypt powoli nabiera kształtów i pokazał mi informacje, które chyba całkowicie wyjaśniły mi koncepcję pavrosa i do niej przekonały. Koncepcja ta jest dość istotna w świetle planowanego CAS2SD. Zobaczyłem mianowicie coś takiego:

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. Przewinięcie do któregoś pliku też jest proste, pliki można wykrywać na podstawie długości IRG (w tym przypadku separatorem było 5s IRG). 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. Rzecz jasna człowiek z tym sobie poradzi, ale software już niekoniecznie. Przykładem jest powyższy Bertyx, który jest jednym programem, ale musiał być podzielony na dwa. No, chyba że się umówimy, że będzie to jakoś odczytywane z odpowiednio sformatowanej nazwy (hehe, prównywanie stringów).
Mam dwie propozycje: pierwsza to przeładowanie definicji bloku 'FUJI', wykorzystanie nieużywanych do tej pory bajtów aux i umieszczenie np. w aux1 strony kasety (A/B), w aux2 numeru pliku, a w danych nazwy pliku w ramach programu ("level 1", "scene 3", "intro" itp). Nie potrzeba dla każdego pliku zapisywac nazwy programu, bo taśmę czyta się sekwencyjnie i wiadomo na którym programie aktualnie jest "kursor" po minięciu bloku 'FUJI' z bajtami aux równymi 0. Jeżeli Krótki będzie konsekwentny, to zaprotestuje przeciwko takiemu nadużyciu bloku 'FUJI' ;). W takim razie zaproponuję dodatkowy typ bloku 'file' (lub 'part' albo 'slic', jak zwał tak zwał), zbudowany analogicznie do bloku 'FUJI', wykorzystujący bajty aux i zawierający nazwy plików a nie programu.
Jak się zapatrujecie na coś takiego ?

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.

Sigh... Powodów "pójścia dalej" można by wymienić przynajmniej kilka (kolejność prawie losowa):
- 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
- 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. 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 ? (żebym mi jeszcze udało się ją  gdzieś znaleźć... ;))
- dla wygody, bo też TYLKO wygodzie służy wprowadzenie kilku nagłówków 'FUJI'. Magnetofon ma taki mały licznik i się zapisuje, przy jakiej wartości licznika zaczyna się interesujący kawałek - przecież tu też można powiedzieć "zapisz sobie w notepadzie, od którego rekordu zaczyna się level 3 i sobie wstukuj w tape management"
- 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ć"
- bo jak zobaczę na ekranie "Rewind to beginning of side B", to chcę zmienić stronę kasety, a nie przewinąć dalej
- żeby zostawić rezerwę na rozbudowę formatu w przyszłości, żeby nie trzeba było czekac następnych 10 lat aż ktoś się zdecyduje na zmiany.
- bo to nie jest trudne do dodania i w niczym nie przeszkadza (zachowuje kompatybilność z obecnymi emulatorami itd.)

Ten wątek nie dotyczy żadnego konkretnego oprogramowania, tylko rozszerzenia formatu cas i możliwości jego użycia. Ja tylko rzucam pomysły (a w zasadzie porządkuję cudze). Jak nikt się nie przychyli, to ja się przy niczym nie upieram. Demokracja jest ;).

EDIT:
Na Atariki jest dodany opis struktury nagrania KSO Turbo 2000  oraz zaczątek tegoż dla Turbo ROM.

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?

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.

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

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.

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.

?!? 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.

Mogę zrozumieć oba podejścia:
a. Chcemy łatwo odnaleźć grę, mieć porządek w plikach, bezproblemowo ją wczytać.
b. Chcemy jak najwierniej symulować rzeczywisty sprzęt - widzieć trójwymiarowy model magnetofonu z licznikiem, wciskanymi klawiszami, odgłosem przewijania taśmy. Podłączanie pliku CAS wygląda jak wkładanie prawdziwej kasety. Widzimy okładkę, na której zapisane są wartości licznika. Powinna jeszcze być operacja czyszczenia głowicy. ;)

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.

Pomysł jest dobry. W ZIPie mogłaby się znaleźć też okładka kasety (PNG lub JPG), oryginalna instrukcja (PDF), itp.

jeśli mnie pamięć nie myli, to do zip-a można dołączyć plik info, który nawet depakery czytają jako "spis treści", a więc jakiekolwiek nazwy i rozszerzenia byście nie wsadzili można je "podlinkować" w pliku info w formacie windowsowego [ini] i dodać do tego jakiekolwiek "description"

No właśnie nie bardzo sobie radzi. Czasem trzeba metodą prób i błędów sprawdzić, co jest "załadowane do stacji", bo w jednym katalogu jest np. 5 plików z nazwami zaczynającymi sie tak samo. Wydawało mi się, że gdzieś coś czytałem o przewijaniu się nazwy w sio2sd, ale to mógł być sen.

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.

A no właśnie z sentymentu. Albo dla wygody, jak to jest w przypadku megaobrazów (1MB) dyskietek z grami. A jeśli chodzi o przewijanie po blokach, to ja jak najbardziej jestem za. Moje propozycje są odpowiedzią na pomysły innych.

Racja, dlatego pliki cas rozdziela się w miejscach, w których magnetofon sie zatrzymuje. Zresztą - tak właśnie do tej pory robiło się z wieloczęściowymi grami w plikach cas (np. Goonies). 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.

Nie, nie o to mi chodzi ! :D
Chodzi o to, że jakakolwiek zmiana w formacie już uznanym w skali światowej będzie się propagować kilka lat, więc lepiej już wcześniej ogłosić propozycję (z praktycznymi przykładami), żeby "świat" się przyzwyczajał.
Ja nie wymagam, żeby obsługę dodatkowych ulepszeń (czy wodotrysków jak ktoś woli) już natychmiast implementować, tylko ewentualnie ująć w rozszerzonej specyfikacji CAS, jeżeli wyglądają rozsądnie rzecz jasna.

Niezupełnie. Według handlera dostępnego na Atariki działa to tak (przy odczycie):
- ustawiana jest początkowa wartość licznika POKEY-a i licznik jest uruchamiany
- w dwóch kolejnych pętlach czeka się, aż miną kolejno stany "0" i "1" na wejściu szeregowym.
- po tym zdarzeniu sprawdza się, czy wystąpiło żądanie przerwania zegara POKEY-a czy nie. Jak wystąpiło, to impuls był długi, czyli była jedynka, jak nie wystąpiło, to impuls był krótki, więc było zero.
Nie jest to więc mierzone tak bardzo dokładnie w cyklach zegara. Jeżeli w emulatorze można wysyłać (i rozróżnić) jedynki i zera na wirtualnym wejściu szeregowym z rozdzielczością 0.05 ms, to powinno chyba działać.

ZIP ? Mnie ani ziębi, ani grzeje. Przy pracy z emulatorem na pewno by było wygodniej. Następnym pokoleniom dodatkowe informacje pewnie też by pomogły (o ile następne pokolenia w ogóle to będzie obchodzić). Do samego formatu CAS nic nie wnosi. W zasadzie to już jest sprawa emulatorów, czyli jednak inny obszar. Umieszczanie obsługi czegoś takiego w bibliotece to jak dla mnie, jak to mówią, overkill. Jeżeli ktoś (Krótki?) coś takiego zrobi, to bardzo fajnie. Jak nie zrobi - też będzie dobrze.

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

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

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

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

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

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

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

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.

Mogę dostarczyć nagrania z Blizzarda, KSO i AST.