51

Odp: CAS2SD, XCAS

Krótki napisał/a:

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

Niestety, napisał, że nie bardzo się da:

Hias napisał/a:

Thanks for the link! It looks interesting, but I can't use it in
AtariSIO. It's too low level (it provides an interface at bit-level,
not byte-level as needed by serial chips).

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

Aha, jeszcze jedno, to do Ciebie, Krótki. Czy testowałeś na emulatorze działanie Turbo 2600 przy prędkościach turbo ? Jak byś nie miał materiału, to można wykorzystać grę "Feud" z tpp (po poprawnym przekonwertowaniu na cas rzecz jasna). Po konwersji wystarczy zmienić/dodać bloki 'baud' z ustawioną prędkością do 2600 baud. Przez AtariSIO działa, a w atari800 wyskakuje load error.

Ostatnio edytowany przez FUJI (2010-01-12 11:27:22)

52

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez Krótki (2010-01-12 12:24:33)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

53

Odp: CAS2SD, XCAS

FUJI napisał/a:

Ad. 2: To raczej emulator należało by poprawić, żeby był bardziej zgodny z oryginałem. Z biblioteką Krótkiego każdy emulator powinien sobie radzić (prawie) tak dobrze, jak atari z magnetofonem.

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

FUJI napisał/a:

Ad.1: Już zasypiam, więc wybacz jeżeli majaczę. O jakich plikach "binarnych" piszesz i w jakim celu chcesz je oddzielać od całości cas-a, który jest jedną całością ? A BTW - zamierzam swój nowy skrypt perlowy (który ma połączyć te dotychczasowe i nowe w jeden) wyposażyć w różne funkcje do manipulacji plikami cas, w tym np. podział na pojedyncze rekordy do oddzielnych plików i składanie ich do kupy (na razie nie piszę po co, choć to tylko jedno zdanie), tudzież xex<-> cas dla nagrań typu "z wykrzyknikiem", więc jestem otwarty na dziwne propozycje (bez skojarzeń proszę). A w przypdku turbo, które z reguły zawierają coś, co można nazwać xex, to ja tworzę xex mimochodem przy okazji tworzenia cas-a.

Bardzo proszę o podejście do tej kwestii ze zrozumieniem.
Piszę o plikach, jakie widzi Atari np. w programie kopiującym. Przykładem jest właśnie para plików binarnych: "wykrzyknik" i xex, które wchodzą w skład CASa. Przykładem są również gry składające się z kilku plików, takie jak "The Goonies", "Spy vs Spy 2", "Crumbles Crisis", "Winter Olympics". Te gry widziane z punktu widzenia kopiera na Atari są zestawem kilku plików. Chodzi mi o to, żeby była możliwość manipulacji zawartością CASa właśnie na poziomie takich plików składowych. W emulatorach natomiast przydałaby się jeszcze możliwość "przewijania kasety" na początek wybranego pliku (np. scene 0 w The Goonies gdy gramy od nowa). Teraz można przewijać tylko do konkretnego rekordu. Oczywiście manipulacja zawartością CASa na poziomie rekordów, o której wspominasz, też jest potrzebna.
Aha, ważna uwaga. Niemożliwość manipulacji CASem na poziomie plików składowych w emulatorze skutkuje np. tym, że gra wielo-plikowa jak "The Goonies", jest zgrywana do CASa na różne sposoby, czyli całość w jednym CASie oraz podzielona na blok główny i poszczególne sceny, gdzie dodatkowo scene 0 istnieje zarówno jako pojedynczy plik oraz znajduje się również w bloku głównym. Ten drugi sposób zgrania z podziałem na sceny jest robiony dla wygody grania pod emulatorem. Oczywiście taki podział nie jest konieczny, gdy wiemy konkretnie, od którego rekordu zaczyna sie poszczególna scena. Ale skąd mamy to wiedzieć? Potrzebny jest dodatkowy plik z informacją o tym! To oznacza w CASie nie mamy pełnej informacji o grze. Mi zależy żeby całą grę wielo-plikową wraz z pełną informacją można było zapisać w jednym pliku CAS.

Krótki napisał/a:
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.

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?

54

Odp: CAS2SD, XCAS

Krótki napisał/a:

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.

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:

Hias napisał/a:

(częśc 1)

Most serial chips have a feature to set TxD to "space" for an arbitrary
amount of time (this feature is used to transmit a "break", i.e. keep
the data line to "space" for at least a full byte duration).

So, at least theoretically, it's possible to transmit arbitrary bitstreams
via the serial port. In practice this is quite complicated, since the
CPU is responsible for accurate bit-timing. It might be possible using
the high resolution timers on newer computers, on older computers
busy-waiting is the only option (which means 100% cpu load).

(częśc 2)

I implemented two versions: on older kernels (before 2.6.28) it uses
busy-waiting which is not too accurate and will block your PC while
FSK data is transmitted. I tested it on my old 600MHz P3 (running
kernel 2.4.36) and it worked quite fine (at least for Lasermania),

On newer kernels (>=2.6.28) atarisio uses the high resolution timers,
which also worked fine on my main PC (2.66GHz Core2Duo 6750, kernel
2.6.32, 64-bit, with high resolution timer support). You can
also force the kernel driver to use the busy-waiting code with
the "hrtimer=0" module parameter. I also tried this on my new PC
but it resulted in unclean transmissions and errors (this was audible
from the SIO sound). I'm not really sure what was going wrong,
I need to have a closer look into this, it could have to do with
my custom kernel (preemptible, HZ=1000, raid1, HDD blinking every
several seconds, ...).

For FSK code testing I added some code to convert standard CAS data
blocks to FSK code. You can enable this by uncommenting the line
"#define CONVERT_DATA_INTO_FSK" in CasHandler.cpp.

I analyzed the CAS files on kr0tki's liba8cas site and realized that
the FSK block only contained a single (quite long) "space" bit,
the copy protection code only checks if data in is receiving "space"
for several timer ticks, so at least for these files the (subtle)
implementation and timing differences shouldn't matter.

Krótki napisał/a:

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

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.

pavros napisał/a:

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

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

pavros napisał/a:

(...)Mi zależy żeby całą grę wielo-plikową wraz z pełną informacją można było zapisać w jednym pliku CAS.

README w Atari800-a8cas napisał/a:

Is is also possible to rewind a tape loaded into the emulator (by giving a
block number). So tape reading/writing can start in an arbitrary point in a
tape file.

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

Ostatnio edytowany przez FUJI (2010-01-12 13:37:53)

55

Odp: CAS2SD, XCAS

FUJI napisał/a:
pavros napisał/a:

(...)Mi zależy żeby całą grę wielo-plikową wraz z pełną informacją można było zapisać w jednym pliku CAS.

README w Atari800-a8cas napisał/a:

Is is also possible to rewind a tape loaded into the emulator (by giving a
block number). So tape reading/writing can start in an arbitrary point in a
tape file.

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

Rozdział części według długości przerw między nimi jest o tyle niewystarczający, że nie można zidentyfikować która część jest w którym pliku. Można się najwyżej domyślać. Uważam, że przy znaczniku rozdzielającym (rozpoczynającym nowy plik) musi być podana nazwa pliku. Po tej nazwie użytkownik będzie mógł zidentyfikować daną część/plik. Ponadto te nazwy będą przydatne przy extraktowaniu plików z CASa na dysk - nie trzeba podawać nazw dla każdego ekstraktowanego pliku. Poza tym jak sam piszesz, z tymi długościami przerw może być różnie.

EDIT: Chyba nie wspomniałem, ale znaczniki początku nowego pliku byłyby opcjonalne. Po konwersji WAV na CAS w ogóle by ich nie było. Dopiero przy pomocy jakiegoś interaktywnego tool'a można by je dodać i nadać odpowiednie nazwy. Taki tool wykrywałby ewentualne początki nowych plików właśnie na podstawie analizy długości przerw.

Ostatnio edytowany przez pavros (2010-01-12 14:19:47)

56

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez Krótki (2010-01-12 16:13:50)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

57

Odp: CAS2SD, XCAS

Krótki napisał/a:
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.

Tak. Przy takim założeniu jak najbardziej jest to ok.

Krótki napisał/a:
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?

Tak.

58

Odp: CAS2SD, XCAS

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:

Read 1474 blocks from CAS file all.cas.
Information about all.cas
------------------
Programs: 4
Program 1:
  Title: Phantom
  Starts at block 0
  Files: 13
   file 1 start at block 2
   file 2 start at block 12
   file 3 start at block 67
   file 4 start at block 86
   file 5 start at block 94
   file 6 start at block 99
   file 7 start at block 160
   file 8 start at block 203
   file 9 start at block 216
   file 10 start at block 258
   file 11 start at block 271
   file 12 start at block 313
   file 13 start at block 325
Program 2:
  Title: The Goonies
  Starts at block 368
  Files: 12
   file 1 start at block 370
   file 2 start at block 379
   file 3 start at block 541
   file 4 start at block 583
   file 5 start at block 613
   file 6 start at block 662
   file 7 start at block 706
   file 8 start at block 748
   file 9 start at block 803
   file 10 start at block 835
   file 11 start at block 876
   file 12 start at block 914
Program 3:
  Title: BERTYX A
  Starts at block 953
  Files: 4
   file 1 start at block 955
   file 2 start at block 959
   file 3 start at block 1009
   file 4 start at block 1123
Program 4:
  Title: BERTYX B
  Starts at block 1220
  Files: 1
   file 1 start at block 1222
Data records: 1466
All blocks: 1474

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.

Ostatnio edytowany przez FUJI (2010-01-14 10:03:51)

59

Odp: CAS2SD, XCAS

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

Ostatnio edytowany przez Krótki (2010-01-14 14:20:12)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

60

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez FUJI (2010-01-18 21:41:39)

61

Odp: CAS2SD, XCAS

@FUJI: Ja oczywiście jestem po twojej stronie :-). Zapomniałeś tylko dodać, że gdy przy korzystaniu z CAS2SD na ekranie zobaczysz komunikat "Please rewind to scene 0" to przeklikanie się przyciskiem tegoż urządzenia do pliku "scene 0" (po liscie plikow) będzie znacznie łatwiejsze niż podanie docelowego numeru bloku. Po pierwsze, bo się go nie zna. A druga sprawa, że kłopotliwe byłoby ustawianie numeru bloku przy pomocy może dwóch przycisków lub wymagałoby to rozbudowy CAS2SD o klawiaturę numeryczną.

62

Odp: CAS2SD, XCAS

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

Ostatnio edytowany przez Krótki (2010-01-21 04:39:36)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

63

Odp: CAS2SD, XCAS

czy jak AST to to także blizzard ?

___
Press play on tape...

64

Odp: CAS2SD, XCAS

Krótki napisał/a:
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 ;)

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

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.

https://www.youtube.com/watch?v=jofNR_WkoCE

65

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez Krótki (2010-01-21 11:15:43)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

66

Odp: CAS2SD, XCAS

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

https://www.youtube.com/watch?v=jofNR_WkoCE

67

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez Krótki (2010-01-21 13:45:33)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

68

Odp: CAS2SD, XCAS

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"

___
Press play on tape...

69

Odp: CAS2SD, XCAS

Krótki: możemy zacząć, oczywiście w nowym wątku.

https://www.youtube.com/watch?v=jofNR_WkoCE

70

Odp: CAS2SD, XCAS

Krótki napisał/a:

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?

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.

Krótki napisał/a:

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.

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.

Krótki napisał/a:
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

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.

Krórki napisał/a:

No nie bardzo, bo czasem są programy składające się z kilku części które ładują się jedna po drugiej automatycznie

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.

Krótki napisał/a:

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

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.

Krótki napisał/a:

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.

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.

Krótki napisał/a:

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.

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

71

Odp: CAS2SD, XCAS

Krótki napisał/a:

d. W ZIP-ie znajduje się plik tekstowy, powiedzmy "atari.cfg" który zawiera wszelkie informacje o wymaganiach systemu:

Koniecznie XML. :)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

72

Odp: CAS2SD, XCAS

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.

Ostatnio edytowany przez Krótki (2010-01-22 14:28:22)

A8CAS - narzędzie do 100% archiwizacji kaset Atari

73

Odp: CAS2SD, XCAS

Ponieważ za parę dni mógł bym wypuścić konwerter z obsługą turbo<->cas, chciał bym wrócić do sposobu zapisu bloków turbo. Jest to trochę powrót do mojej pierwszej koncepcji. W skali "makro" wszystkie (chyba) formaty turbo oparte na PWM zasadniczo wyglądają tak samo. Mają sygnał pilotujący, ewentualnie impuls(y) oznaczający(e) początek danych, dane złożone z zer i jedynek, ewentualny sygnał kończący blok (jak AST). Niezbyt więc podoba mi się koncepcja dodawania nowego rodzaju bloku dla każdego typu turbo i konieczność uwzględniania każdego formatu w oprogramowaniu. Wydaje mi się, że powinno wystarczyć coś takiego:

1. odpowiednik bloku 'baud' dla formatu standardowego, opisujący parametry sygnału:

$70 $77 $6d $73  ; 'pwms' - PWM settings
$08 $00          ; długość 8 bajtów
$xx              ; aux1 - parametry impulsów
$yy              ; aux2 - liczba i rodzaj impulsów pomiędzy pilotem i danymi
$LL $MM          ; szerokość impulsu pilota w setnych ms
$LL $MM          ; szerokość impulsu dla bitu '0' w setnych ms (aux 1 określa co jest impulsem)
$LL $MM          ; szerokość impulsu dla bitu '1' w setnych ms (aux 1 określa co jest impulsem)
$LL $MM          ; szerokość impulsu sygnału końcowego w setnych ms

aux1 - dwa najmniej znaczące bity określają rodzaj impulsu:
00 - szerokość impulsu określa czas trwania stanu '0' (niskiego)
     (czas trwania następnego stanu '1' nie jest ściścle określony,
      jeszcze nie jestem pewien jak liczyć)
01 - szerokość impulsu określa czas trwania sekwencji kolejnych stanów '0' i '1'
     (po połowie na każdy stan)
10 - szerokość impulsu określa czas trwania sekwencji kolejnych stanów '1' i '0'
     (po połowie na każdy stan)
11 - szerokość impulsu określa czas trwania stanu '1' (wysokiego)
     (czas trwania następnego stanu '0' nie jest ściścle określony,
      jeszcze nie jestem pewien jak liczyć)

aux2 - dwa najmłodsze bity określają liczbę impulsów pomiędzy pilotem i danymi
       (0-3, na razie nie spotkałem innych przypadków niż 0,1,2).
aux2 - bity 2 i 3 -  rodzaj impulsu pomiędzy pilotem i danymi
00 - impulsy '0'
01 - impulsy '1'
10 i 11 w rezerwie, może się trafi coś innego

2. blok danych

$70 $77 $6d $64  ; 'pwmd' - PWM data
$LL $MM          ; ilość bajtów danych + 4
$LL $MM          ; (aux1,2) IRG w ms
$LL $MM          ; ilośc impulsów pilota
$LL $MM          ; ilość impulsów końcowych
DANE

3. ewentualnie blok do zapisu pojedynczych impulsów:

$70 $77 $6d $69  ; 'pwmi' - PWM impulses
$LL $MM          ; długość bloku = 2 x ilość impulsów
$LL $MM          ; (aux1,2) IRG w ms
dwubajtowe dane o długości naprzemiennych stanów
poczynając od '0'
w setnych częściach ms

W ten sposób zawsze powinno być możliwe dodanie nowego formatu turbo bez ingerencję w oprogramowanie, które po prostu musi wysyłac do komputera lub emulatora zera i jedynki z odpowiednią szybkością.

Czekam na krytykę lub ewentualne propozycje poprawek.

Jeżeli kogoś interesuje konwersja innych formatów niż Turbo 2000 KSO, Blizzard, AST (tu mam na razie tylko próbkę ze strony Krótkiego) i Turbo Rom (z tym ostatnim jeszcze nie doszedłem do ładu) to będę potrzebował przykładowych nagrań.

Jeszcze jedna rzecz - niewykorzystane bajty aux w bloku FUJI. Może by tam wrzucić wersję formatu CAS, żeby oprogramowanie mogło sprawdzic, czy jest kompatybilne z plikiem ? Tak na wszelki wypadek, jak by budowa bloków w przyszłości miała się zmienić. Dotąd wersja była 0, nowy cas może mieć np. 1 ($0100 w aux) itd.

74

Odp: CAS2SD, XCAS

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

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

75

Odp: CAS2SD, XCAS

Co do polskiego KSO Turbo 2000 i Turbo 2000F aby wygenerowac nagrania mozna zastosowac Turgen-a

http://www.baktra.wz.cz/software/turgen2.html