Ja się w zasadzie tylko tam zaopatrywałem, i w zasadzie tylko zestawy na zamówienie. Część ocalała, zrzucam po kawałku właśnie.

Natomiast z sentymentalnych rzeczy może Cię jeszcze zainteresować ten plik w takim razie:

http://zwieracz.krap.pl/feniks-katalog.pdf

Chodziło mi raczej o pliki zabezpieczone przez AutoCopy 3.0 lub podobnie, ale ciekawie, że pojawiły się też inne informacje i katalog :) - nie znałem, ale fajnie coś takiego zobaczyć.

Pliki zabezpieczone *AJEK mają tekst z informacją, że jest to *AJEK, sygnał jest wyraźnie inaczej zapisany, podczas wczytywania są kolorowe pasy, łatwo się zorientować, że będzie problem ze skopiowaniem. Kiedyś udostępniłem kilkanaście takich plików, ale do tej pory został chyba tylko jeden. Krótki zgrał też jeden z loaderów, również zabezpieczony przed kopiowaniem, szkoda, że nie ma wersji xex.
Szczegóły i pliki w tym wątku: atarionline.pl/forum/comments.php?DiscussionID=2848

Swoją drogą to ciekawe zjawisko, pliki prawdopodobnie odbezpieczone, przeniesione na inny nośnik, zostały ponownie zabezpieczone tym razem chroniąc interes kogoś innego...

Te z Loaderami z AutoCopy 3.0 wczytują się pozornie normalnie jak każdy programy z loaderem, nie ma żadnych dodatkowych napisów, nic podejrzanego, uruchomiony program wydaje się, że wczytuje się jak każdy inny. Dopiero przy próbie skopiowania okazuje się że plik jest uszkodzony, nie pomagają wielokrotne próby kopiowania, błąd jest zwracany na każdym kolejnym bloku poza loaderem, na słuch sygnał jest w porządku. Także można być zupełnie nieświadomym, że używa się zabezpieczonych plików, a po próbie skopiowania uznać, że plik jest uszkodzony. No i taki plik jest zapisywany przez standardowe narzędzie.

Ciekaw jestem czy "Brodaty" celowo tak nagrywał, czy nie był tego świadomy? Ja bym obstawiał to drugie. W każdym razie tak jak się spodziewałem na drugiej kasecie też znalazły się zabezpieczone programy, a są to: kaseta 3: Ninja Commando, Fred, Zybex 2, Who Dares Wins II; kaseta 2: Ninja, Robbo, GhostBusters (wszystkie na Atari odczytałem przerobionym Long Turbo Copy 1.1). Zauważyłem też, że nagrywał programy pojedynczo i sprawdzał czy się wczytują, jak nie, to nagrywał w to miejsce ponownie dodając loader, czy używając właśnie AutoCopy 3.0. Spod GhostBusters-a "wystaje" niezabezpieczona wersja, a na kasecie 3 w przerwie jest kilka bloków ze Special Delivery. Tennis, który o ile dobrze pamiętam uruchamia się przed końcem ostatniego bloku ma ten koniec nadpisany następnym plikiem i nie da się odczytać ostatniego bloku, co też może być traktowane jako zabezpieczenie.

Niestety oprócz tych dwóch kaset (trzecia nagrana przeze mnie), znalazłem jeszcze tylko jedną z tej "serii" - "nr 4", prawie całą wykasowaną, póki co nie udało mi się z niej nic odczytać, a zostały na niej tylko 4 programy i jakieś kopie z normalu czy Basic. Znalazłem też kolejną "czerwoną" wkładkę ze spisem programów, w dobrym stanie, ale bez kasety nr 5.

Co do kaset w normalu to z takich które da się przegrać na Turbo została mi tylko jedna, którą właśnie zgrałem. Być może została, bo część programów jest w wersji boot lub ma niestandardowy loader i błedy na końcach*. Prawdopodobnie kaseta pochodzi z Sezamu, lub ktoś kto robił tę kompilację stamtąd skopiował Super Cobrę, bo ta ma specyficzny loader, bez którego gry nie da się uruchomić (ale skopiować na normal można). Ta wersja jest zbliżona do "Super Cobra (1983)(Parker Brothers)[a1].xex" z AOL, jednak bez loadera się zawiesza. *)Większość plików na tej kasecie ma na końcach dodatkowe ciągi Bajtów - zera lub przecinki, a w dwóch przypadkach ostatni zerowy "blok" sygnału jest nieco uszkodzony - w jednym przypadku w dość dziwny sposób - sygnał cichnie i na "wykresie" przemieszcza się zygzakiem w dół, co oczywiście zwraca błąd przy kopiowaniu, ale już za danymi. Kaseta nie ma oryginalnej wkładki, ale została dołączone karteczka z wydrukiem takiej treści:

Reszty kaset, które mam w normalu nie da się skopiować bez odpowiedniego kopiera (o ile taki istnieje), podczas wczytywania mają napisy zachęcające do odwiedzenia domów towarowych centrum - m.in. kaseta, którą Krótki skonwertował na cas-y i dorzucił do bazy AOL: Ixion (1985)(U.S. Gold)(GB)(beta)[cr The Sorcerer][h DT Wars].cas i Spy vs Spy - Arctic Antics (1987)(Epyx)(US)[cr BodzioSoft - Gizmo & K...][h DT Wars].cas
Z tego co sobie przypominam, te kasety dość często podczas wczytywania gubiły sygnał, więc oprócz walorów "copy protection" były dość "awaryjne".

Jak ktoś ma coś w "AJK-u", czy z innym zabezpieczeniem, czy wersje wieloplikowe, czy w ogóle z dawnych kaset to warto pomyśleć o udostępnieniu (niezależnie w jakim turbo, a nawet w normalu) :).

W załączniku kaseta zgrana z normalu. Pliki tak jak opisałem mają na końcach dodatkowe Bajty. Zauważyłem też że wersja cas gry Pharaohs Curse na AOL ma jeden Bajt zmnieniony, nie wiem co to daje (czy to może błąd? - kod kontrolny w cas się zgadza), ale w tej wersji jest taki jak w każdej innej z AOL. Zauważyłem też, że wersja z AOL na emulatorze często zalicza Boot Error, u mnie było lepiej, a zupełnie pomogło ponowne zapisanie pliku cas.

Edit: podmieniłem plik 7z, ale tylko z uwagi na literówkę w pliku txt.

Edit2: Przy okazji zauważyłem, że Universal Copy *EMEK do niektórych plików dodaje jeden Bajt $00 na końcu, czy jest szansa, żeby to poprawić? Seban?

Na poprzedniej stronie są zdjęcia, póki co mam skan kolejnej:

Coś mi świta, że chyba jednak powinienem mieć też i tę kasetę... a przynajmniej kopię części...

Hej!

Ten charakterystyczny loader był generowany przez program kopiujący "Turbo Copy 3", "Turbo Copy 4". Program był takim automatem nagrywającym kasetę po wybraniu plików z dyskietki. Kiedyś go "wysępiłem" od Krzyśka Steca, ale program był oczywiście zabezpieczony przed kopiowaniem :) w dodatku w jakiś porąbany sposób, K.Stec musiał go kopiować jakimiś wynalazkami w stylu "Happy Hacker King III". Mam tę dyskietkę, ale w stanie agonalnym... nie wiem które z uszkodzonych sektorów to wynik działania czasu a które to zabezpieczanie. Będę musiał odszukać i spróbować ponownie się nad tym pochylić No chyba że gdzieś na sieci już to leży?

A to ciekawe. Nigdy tego nie zauważyłem. Mówiąc że "do niektórych" możesz podać jakiś przykład? te "niektóre piki" mają jakąś konkretną długość? tzn. chodzi mi o ustalenie jakichś warunków brzegowych przy których następuje dodanie 'zera" na końcu.

Jeszcze jedno...

Przejrzałem pobieżnie kod loadera... a więc wychodzi na to że to nie jest "zwykły" binary-DOS-file. Otóż loader dekompresuje w locie napływające dane... używa bardzo prostego algorytmu RLE, ale zawsze... czyli wszelacie ciągi powtarzających sie jednostajnie bajtów zostają wyeliminowane na etapie nagrania pliku przez kopier i zastąpione dwoma "znacznikami" (escapce-codes). są to bajty $BF i $CF.

Po  napotkaniu $BF w strumieniu danych loader pobiera następny bajt oznaczający ilość zer które umieści w pamięci na docelowej lokacji, natomiast po napotkaniu $CF loader pobiera zarówno bajt oznaczający ilość powtórzeń jak i kolejny bajt oznaczający jaki bajt należy powtarzać.

Aby taki plik dało się normalnie załadować i uruchomić trzeba by napisać loader który go wczytując będzie dokonywał dekompresji albo napisać narzędzie które przywróci pierwotną formę pliku.

Prawdę mówiąc teraz mi się przypomniało że walczyłem z tym kiedyś jeszcze jako młokos i napisałem nawet jakieś narzędzie do kopiowania plików tym zabezpieczonych, ale to pozostało na moich starych kastach z czasów gdy używałem KSO Turbo 2000, jednak zupełnie nie pamiętałem że ten kopier dokonywał kompresji RLE. Więc albo miałem na kasetach nagrane programy bez kompresji RLE (np. wcześniejszą wersją kopiera) albo było to tak dawno że o tym fakcie zapomniałem ;)

Z tego typu programów, to pierwszy który poznałem to był "Zagęszczacz" Dariusza Rogozińskiego (program był emitowany w Radio-komputerze). On po prostu pozbywał się zer z plików modyfikując nagłówki binarnego programu tak aby pominąć obszary zawierające zera. Na początku programu był dodatkowy segment który zapewniał zerowanie całej pamięci w którą ładował się program, tak aby była pewność że ominięte zera będą domyślnym stanem pamięci RAM po wczytaniu tak "poszatkowanego" programu.

@Seban, napisałem decoder - decompressor w Turbo Basic-u, plik wynikowy wyszedł taki jak ten który wskazałem jako podobny, jednak i w tym przypadku na końcu są zbędne zera. Kompresja dała o 135 Bajtów mniej (226 Bajtów licząc zera na końcu), czyli w praktyce 2 bloki danych. Teraz tylko napiszę koder i będę mógł używać tego loadera z innymi plikami xex ;) Zgrywając pliki widziałem już taki różniący się w podobny sposób, ale uruchamiał się, więc miał zawartą w sobie dekompresję. Może uda mi się odnaleźć. Niektórym plikom taka kompresja by się przydała - np. jednej z wersji Freda (u mnie była zabezpieczona - identyczna jest na AOL), w której ktoś napisał "kompresor oraz poprawki" i zostawił mnóstwo zer... coś jednak tam wygląda jakby się dekompresowało.

@Sikor, na pierwszej kasecie miałem te dwa i kopiery, ale na którejś kolejnej z innego źródła miałem jeszcze nazwane LL1 i LL2 (z menu turbo), sprawdziłem, że można usunąć zera z końca loaderów z AutoCopy 2.0 (3.0 to te same, ale "zabezpieczone") i użyć ich analogicznie jak L2 (nagrać za nim plik bez nazwy). Ale skoro masz jakieś loadery to myślę, że warto porównać, bo L1 na dyskietce różni się od L1, który miałem na kasecie (loadery 8 sztuk - załączyłem na poprzedniej podstronie).

Edit: napisałem compressor i oprócz Super Cobry, spróbowałem na kilku plikach: River Raid, Fred, Preliminary i demie Perestroyka zwanej "Pierestry" - gry się zawieszają po wczytaniu, do tego Fred prawdopodobnie nie wyrabia z dekompresją bo co i raz na emulatorze Atari800 gubi sygnał, nagrałem go z długimi przerwami, wczytał się i na tym koniec. W załączniku jedynie działające demo - kompresja zmniejszyła plik o 3611 Bajtów. Compressor wrzucę jak uporządkuję część dla użytkownika.

Dobry Wieczór!

W celach "naukowych"... a tak naprawdę z czystej ciekawości postanowiłem się trochę dłużej zająć tym problemem, przeglądając te wszystkie łatwo dostępne pliki .cas zawierające ten loader, tzn:

Super Cobra - od QTZ
Universal Hero - od Krapa
Spy vs Spy - z archiwum AoL
Ixion2 - z archiwum AoL

Okazało się (czego już nie pamiętałem) że TurboCopy 3/4 dodatkowo XOR-ował strumień danych przed zapisem na taśmie, był to co prawda prymitywny XOR z jedną wartością, ale wygląda na to że wartość ta była losowana przy zapisie każdego pliku. Wartość XOR była zachowana w kodzie loadera aby ten mógł bezproblemowo odkodować strumień wejściowy.

Tak jak pisał QTZ pliki zawierają na końcu niepotrzebne zera, nie wiem czy to powstało przy konwersji do CAS, czy też było tak na taśmie nagrane, jednak faktem jest że te zera są w każdym z tych plików obecne.

W ramach nauki czegoś nowego postanowiłem napisać prosty kod/skrypt w Pythonie który potrafi taki strumień danych z TurboCopy 3/4 odkodować i przywrócić go do pierwotnej postaci. Dla chętnych źródła są tutaj: TCX Tools.

Na potrzeby tej całej "zabawy" i aby nie komplikować sobie życia poprzez pisanie dodatkowego kodu do obróbki plików CAS, wymyśliłem sobie format TCX który zawiera już binarny stream wyciągnięty z pliku CAS. Do konwersji używałem programu a8-conver z pakiety a8cas od szanownego kolegi Krótkiego.

Jak przebiegał proces konwersji? Konwertowałem plik cas na hex, czyli np:

a8cas-convert -fh spy_vs_spy.cas spy_vs_spy.hex

po czym dokonywałem ręcznej edycji pliku HEX:

A8CAS-HEX
FUJI 
baud 00603
data 19205 55 55 fc 00 06 00 07 2a 07 a2 00 a0 00 fe 2b 07 51 04 59 00 04 48 b9 00 04 99 00 0a 68 e8 c8 d0 ec 8d fc bf ee fc bf cd fc bf d0 02 38 60 a8 30 8c 2f 01 a8 08 8c 30 01 ac fb be 8c 29 08 a1 07 9f a8 1f a3 07 a1 fe 85 47 e7 8d c5 01 8d c7 01 8d 43 01 85 13 a4 13 c8 0f cf f9 e7 85 08 ac b7 08 c8 73 cf 19 1f 0a 08 8c e0 01 a8 2a 8c df 01 1f 7e 06 1f a1 06 1f 95 07 1f 01 08 1f 2a 07 4b 73 e3 a1 eb ; standard record; length=132, checksum=eb OK
data 00264 55 55 fc 0f a8 02 9c 41 02 a8 03 9c 49 02 a8 24 9c 43 02 a8 08 9c 44 02 a8 7f 9c 4a 02 a8 11 8c fb 01 4b 55 e3 1f 3b 07 ac ee 01 cc 82 06 cf ce a4 13 c4 13 ef f9 1f 52 07 a4 42 8c 79 06 a4 43 8c 7a 06 9f ff 1f 0b 07 c8 be cf 0e 1f 0b 07 a9 a8 ff 1f eb 06 c9 cf f9 4b e8 06 c8 ce cf 09 1f 0b 07 a9 1f 0b 07 4b ce 06 1f eb 06 4b bf 06 9f ff 90 42 47 e5 42 cf 01 e5 43 a4 42 c4 44 a4 43 e4 45 8f 80 ; standard record; length=132, checksum=80 OK
data 00264 55 55 fc 28 67 67 67 1f 52 07 2f 21 4b bf 06 89 84 48 a1 0f a8 ff 9c 47 02 9c 48 02 a8 06 9c 41 02 1f 55 e3 2f 09 4c 2b 07 47 a4 48 a9 67 60 af bd 43 04 c9 88 d0 0f 20 96 08 68 68 a0 80 60 a9 ed 48 a9 3c 48 60 a9 53 8d 3b 09 a9 09 8d 3c 09 20 96 08 4c 50 08 20 90 08 20 08 09 20 0c 08 85 43 20 0c 08 85 44 a9 ff c5 44 d0 04 c5 43 f0 e6 a9 fe 85 48 20 0c 08 85 45 c9 e3 d0 02 e6 48 20 0c 08 85 ea ; standard record; length=132, checksum=ea OK
data 00264 55 55 fc 46 c9 02 d0 02 e6 48 e6 45 d0 02 e6 46 a0 00 60 a0 3c 8c 02 d3 60 a2 10 a9 0c 9d 42 03 20 56 e4 a2 e4 a0 5f a9 06 4c 5c e4 ee c4 02 ad c4 02 8d 16 d0 ce 28 09 d0 11 a9 04 8d 28 09 ad c7 02 18 69 10 8d c7 02 8d 19 d0 46 4d ae 29 09 ca 10 29 ee 4e 09 d0 03 ee 4f 09 ad 4e 09 c9 81 d0 18 ad 4f 09 c9 0a d0 11 a9 8f 8d 4e 09 a9 09 8d 4f 09 bd 2b 08 c9 3f d0 f9 a2 07 8e 29 09 8e 04 d4 4c 21 ; standard record; length=132, checksum=21 OK
data 00264 55 55 fc 5f e4 6c e0 02 6c e2 02 20 05 09 a9 2b 8d e2 02 a9 08 8d e3 02 a6 48 30 0b a0 34 20 92 08 86 14 c4 14 d0 fc 60 43 3a 9b 04 07 ff 52 4b 31 39 38 37 70 70 70 70 70 70 70 70 70 46 67 09 70 70 70 70 70 47 7b 09 70 70 70 70 70 70 70 70 56 8f 09 41 31 09 00 00 00 00 00 ec ef e1 e4 00 e5 f2 f2 ef f2 00 00 00 00 00 00 00 24 34 02 37 21 32 33 02 23 25 2e 34 32 35 2d 02 00 00 00 0a 00 33 30 cf ; standard record; length=132, checksum=cf OK
data 00264 55 55 fc 39 00 36 33 00 33 30 39 00 29 29 29 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73 74 75 64 69 6f 40 6b 6f 6d 70 75 74 65 72 6f 77 65 40 64 74 4e 40 02 37 21 32 33 02 00 61 6e 74 72 65 73 6f 6c 61 40 6f 66 65 72 75 6a 65 40 5a 40 64 75 7a 79 40 77 79 62 6f 72 40 70 72 6f 67 72 61 6d 6f 77 40 4c 40 69 6e 73 74 72 75 6b 63 6a 69 40 69 40 6c 69 74 65 72 61 3c ; standard record; length=132, checksum=3c OK
data 00263 55 55 fc 74 75 72 79 40 66 61 63 68 6f 77 65 6a 4e 00 00 0a 00 eb e1 f4 e1 ec ef e7 e9 40 e7 f2 e1 f4 e9 f3 40 0a 00 f7 f9 f3 f9 ec eb e1 40 f0 ef e3 fa f4 e1 40 0a 00 00 3a 21 30 21 2d 29 25 34 21 2a 00 4d 40 64 74 4e 40 02 23 25 2e 34 32 35 2d 02 00 4d 00 02 37 21 32 33 02 00 40 50 50 4d 50 51 57 40 77 4d 77 61 40 75 6c 4e 40 6d 61 72 73 7a 61 6c 6b 6f 77 73 6b 61 40 51 50 54 00 00 00 00 f3 ; standard record; length=132, checksum=f3 OK
baud 01190
data 15437 55 55 ff 20 36 01 ; standard record; length=6, checksum=01 OK
baud 00603
data 00346 55 55 fc 50 50 99 0f e0 0e 60 ac df e1 ff 0e 60 f2 a1 e1 af 1f 60 ce a1 ee 99 0f 10 ff af a9 8f a9 06 99 22 9f ad 06 0f 22 9e ad 8f 8f 5b 06 3b 22 69 ad 06 65 22 6a ad 06 87 22 6b ad cf 10 ab 4d ad 4c ad af a9 ff 0e e0 10 10 51 10 88 2f 10 88 2f 10 89 ad 2f 10 89 ad 2f 10 89 a5 2f 10 89 a5 2f 10 8a 60 ac 05 0f ba bb fa ae fa fa ba 60 a0 fa ef 10 a2 a5 05 05 0f fa bb fa ea fa fa ba 60 a0 fa 2a ; standard record; length=132, checksum=2a OK
data 02853 55 55 fc ef 10 a2 ad 05 05 af fa bb fa ea fa fa ba 60 a0 fa ef 10 a1 05 07 af ff bb fe ea af bb 10 b1 ad 05 0f af ff bb fe ea ff bb 10 b1 ad 05 60 ae 10 53 fe bb fa ae fb bb 60 bf 50 6f 10 a2 a5 2d 60 ae 10 53 fe bb fa af bb bb 60 bf 50 6f 10 a2 a5 af 50 53 fe bb fa fa fb bb 60 bf 50 6f 10 a2 87 af 53 af ff bb fe fa fb bb 10 8f 53 af ff bb ff fa ff bb 10 8f 93 10 8a aa fa 90 90 50 6f 50 ac 4a ; standard record; length=132, checksum=4a OK
data 02856 55 55 fc 50 10 b0 aa fa e0 90 50 6c 50 6c 50 6f 10 b1 ba fa e0 60 ae 60 50 6c 50 6c 50 5f 10 b1 ba af ac 6f 5f a0 6c 5c 6c 5f 10 b1 ba af ac 5f 5f a0 6c 5c 6f 5f 10 b1 aa 10 ad 5f 5f a0 af 5c 6f 5f 10 ba ad 85 8f a7 60 ac 07 10 ad aa ef af 53 5f a0 af 5c 6c 5f 10 ba a7 8f a7 a7 27 07 a7 10 ad ae ef af 93 5f a0 af 5c 50 5f 10 ba a7 8f a7 a7 07 27 a7 10 ad ae ff af 93 5f a0 50 5c 50 6f 10 ba 18 ; standard record; length=132, checksum=18 OK

ręczna modyfikacja polegała na usunięciu rekordów loadera i 6-bajtowego rekordu zabezpieczającego nagranie przed skopiowaniem przez zwykłe kopiery, a więc po wycięciu loadera (pierwsze 7 standardowych rekordów) i 6 bajtowego rekordu "psującego zapis" zostawało coś takiego:

A8CAS-HEX
FUJI 
baud 00603
data 00346 55 55 fc 50 50 99 0f e0 0e 60 ac df e1 ff 0e 60 f2 a1 e1 af 1f 60 ce a1 ee 99 0f 10 ff af a9 8f a9 06 99 22 9f ad 06 0f 22 9e ad 8f 8f 5b 06 3b 22 69 ad 06 65 22 6a ad 06 87 22 6b ad cf 10 ab 4d ad 4c ad af a9 ff 0e e0 10 10 51 10 88 2f 10 88 2f 10 89 ad 2f 10 89 ad 2f 10 89 a5 2f 10 89 a5 2f 10 8a 60 ac 05 0f ba bb fa ae fa fa ba 60 a0 fa ef 10 a2 a5 05 05 0f fa bb fa ea fa fa ba 60 a0 fa 2a ; standard record; length=132, checksum=2a OK
data 02853 55 55 fc ef 10 a2 ad 05 05 af fa bb fa ea fa fa ba 60 a0 fa ef 10 a1 05 07 af ff bb fe ea af bb 10 b1 ad 05 0f af ff bb fe ea ff bb 10 b1 ad 05 60 ae 10 53 fe bb fa ae fb bb 60 bf 50 6f 10 a2 a5 2d 60 ae 10 53 fe bb fa af bb bb 60 bf 50 6f 10 a2 a5 af 50 53 fe bb fa fa fb bb 60 bf 50 6f 10 a2 87 af 53 af ff bb fe fa fb bb 10 8f 53 af ff bb ff fa ff bb 10 8f 93 10 8a aa fa 90 90 50 6f 50 ac 4a ; standard record; length=132, checksum=4a OK
data 02856 55 55 fc 50 10 b0 aa fa e0 90 50 6c 50 6c 50 6f 10 b1 ba fa e0 60 ae 60 50 6c 50 6c 50 5f 10 b1 ba af ac 6f 5f a0 6c 5c 6c 5f 10 b1 ba af ac 5f 5f a0 6c 5c 6f 5f 10 b1 aa 10 ad 5f 5f a0 af 5c 6f 5f 10 ba ad 85 8f a7 60 ac 07 10 ad aa ef af 53 5f a0 af 5c 6c 5f 10 ba a7 8f a7 a7 27 07 a7 10 ad ae ef af 93 5f a0 af 5c 50 5f 10 ba a7 8f a7 a7 07 27 a7 10 ad ae ff af 93 5f a0 50 5c 50 6f 10 ba 18 ; standard record; length=132, checksum=18 OK
...

tak zmodyfikowany plik HEX konwertowałem ponownie do pliku CAS:

a8cas-convert spy_vs_spy.hex spy_vs_spy_ldr_removed.cas

i taki plik CAS, przy użyciu emulatora z odpalonym MyDOS-em, urządzeniem "H:" kopiowałem do postaci binarnej, którą sobie nazwałem .TCX (od Turbo Copy eXecutable).

Teraz mogłem sobie eksperymentować bawiąc się pisaniem bzdur w Pythonie. Na początku chciałem to zrobić jak QTZ, czyli Turbo Basic XL, emulator ustawiony na 21MHz, SIO/CIO patch czytanie bezpośrednio z C: zapis obrobionych danych na H: byłoby pewnie prościej i szybciej... ale postanowiłem się pobawić, trochę rozruszać mózg i nauczyć się czegoś nowego, a że w Pythonie nigdy nie napisałem więcej niż kilkanaście linii... w dodatku nie chciało mi się implementować jakiejś obsługi błędów... i mieć efekty szybki i sprawdzalne od razu, to wybór padł na Pythona... szybkie to być nie musi, Python jest interpreterem więc wszystko można było mieć pod reką... można powiedzieć że to taka obiektowa dość nowoczesna wersja BASIC-a (hahah... już widzę jak mnie ludzie od Pythona zaraz zjedzą :P ja się nie nim nie znam, więc mogę sobie pozwolić na mówienie takich herezji :P)

Z "Super Cobra" szybko poszło, ale potem się okazało że Super Cobra od QTZ ma zmodyfikowany loader (nie oczekuje na ten mały 6 bajtowy rekord, ktoś tam wstawił trochę nop-ów) a także nie ma XOR-owania streamu danych. Pozostałe pliki miały owe "zabezpieczenie" oraz dodatkowo zapisane dane były potraktowane XOR-em z losową wartością zależną od pliku.

Napisanie tego lame-dekodera zajęło mi parę godzin, oczywiście ze sporymi przerwami bo miałem niestety inne rzeczy do roboty, ale większość tego czasu to była nauka tego pythona... nie chciało mi się w C klepać, to mam za swoje :P

Kod dekodera można uruchomić zarówno pod Linux jak i Windows, nie wymaga żadnej kompilacji po prostu należy go wywołać z command-line, okna terminala, etc.

Pisałem wyżej o XOR-owaniu danych przez program TurboCopy3/4... jak się zatem dobrać do klucza skoro wyżej pokazałem jak wywalić loader, a klucz byl w loaderze? Ponieważ XOR jedno-bajtową wartością to żadne zabezpieczenie nie jest, a my znamy w dodatku nagłówek jakiego się należy spodziewać w danych to klucz możemy "zgadnąć", tzn. obliczyć go sobie i program tak też czyni... jeżeli podany plik TCX nie ma odpowiedniego nagłówka program sprawdza strukturę danych i wypisuje klucz:

sbn@debian:~/test$ python3 tcx_rle_decoder.py universal_hero.tcx

Input file is universal_hero.tcx and the file size is 41088 bytes.
TCX data loaded, checking data...

Header is: $4b4b

Not a Atari DOS file header! Wrong file type? Data encrypted?
Maybe the XOR key for data decoding is wrong or not given?

>>> But if I can guess try this XOR key value: 0xB4 <<<

gdy zatem już mu podamy ten klucz, to zajmie sie on już resztą i wygeneruje zdekodowany plik samodzielnie, przy okazji wypisując strukturę pliku:

sbn@debian:~/test$ python3 tcx_rle_decoder.py universal_hero.tcx 0xb4

Input file is universal_hero.tcx and the file size is 41088 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $0586-$06fe
block 001: $02e2-$02e3
block 002: $0c00-$bffe
block 003: $02e0-$02e1

!!! WARNING !!! Bad header data was detected, skipped 87 garbage byte(s).

Input data processing done, 4 block(s) processed, generating output file...
Output file is universal_hero.tcx.xex and the file size is 46478 bytes.
Processing done, output file written, IN/OUT file size diff is 5390 byte(s).

Jeżeli zapytacie po cholerę ten cały cyrk z "projektem" składającym się kilkudziesięciu linii w Pythonie i wrzucaniem tego na github, etc. To pomyślałem sobie że jeżeli będzie potrzeba, zainteresowanie, ew. jakieś nowe pliki do przetworzenia, to może z czasem rozbuduje ten projekt. Napiszę konwerter CAS<-->TCX, wrzucę de-assemblowane źródła loadera, a może nawet jakby było sporo takich kaset do zgrania u kogoś, to może pokuszę się o napisanie programu kopiującego do tego typu nagrań bezpośrednio na Atari. Pytanie tylko czy jest tyle tego typu kaset/plików aby poświęcać temu czas?

A i na koniec gdyby ktoś chciał zebraną w jedno miejsce kolekcję plików CAS,TCX i XEX aby pobawić się tym wszystkim sememu to proszę bardzo: TCX Tools test file set.

Krap, QTZ dzięki WIELKIE za udostępnienie tych plików.

ps) @QTZ ... Supaplex ma rację... nagłówków pliku file nie uwzględniamy w przy kompresji/dekompresji (przynajmniej tak to czyni kod loadera, tzn. nagłówki segmentów danych czyta niezależnie, za dekompresję bierze się dopiero jak czyta napływające bajty z aktualnie wczytywanego segmentu danych). Kompresji RLE podlegają tylko dane które są w danym segmencie danych zawarte. Loader dekompresuje dane bardzo szybko, więc nie ma potrzeby robić długich przerw między rekordami. Turbo Copy 3/4 wydłużał przerwę między rekordami jedynie wtedy gdy wykrył że w danym rekordzie danych znajduje się segment INIT ($2e2-$2e3) robił to dlatego że przed skokiem do INIT zatrzymywał silnik magnetofonu, bo nigdy nie było wiadomo ile czasu spędzi CPU w kodzie uruchomionym przez INIT, być może będzie to ułamek sekundy, a może to będzie jakieś intro które będzie oczekiwało na wciśnięcie klawisza?

Hej!

Na temat kompresji RLE można pewnie by całkiem niezłą książkę, sposobów na wybieranie znaczników, algorytmów i sposobów rozwiązania problemu pt. jaki "znacznik" wybrać napisano masę tekstu :) Jedną z metod wyznaczania "znaczników" oznaczających dla dekompresora potrzebę podjęcia jakiejś innej operacji niż skopiowanie nadchodzącego bajtu na wyjście, jest analiza statystyczna strumienia danych wejściowych. Można np. przeanalizować dane i wybrać te bajty które najrzadziej występują w pliku, tak aby uniknąć właśnie kodowania często powtarzających się bajtów jako 3-bjatowych sekwencji typu [znacznik, liczba_powtórzeń, bajt_to_powtarzania]. Jeżeli wybierzemy jako znacznik taki najmniej powtarzający się bajt to w strumieniu wyjściowym będzie minimalna ilość zamiany bajtu który akurat wybraliśmy na znacznik na 3 bajtowe sekwencje. Tzn załóżmy że mamy jako znacznik wybrany bajt $CF.... gdy teraz w mamy strumień danych:

00 AA 55 DE AD BE EF CF AA 55 00

to kompresor będzie musiał wyprodukować coś takiego:

00 AA 55 DE AD BE EF CF 01 CF AA 55 00

dlatego najlepiej wybrać na ów znacznik najrzadziej występujący bajt w danych wejściowych.

Dlaczego twórca Turbo Copy 3/4 wybrał znaczniki $BF, $CF? Być może przeprowadził jakieś analizy statystyczne i uznał ze te bajty występują nie tak często. A być może uznał że te wartości są fajne? ;) Lub po prostu uznał że to rozwiązanie jest wystarczające?

W tym moim pythonowym kodzie możesz sobie przełączyć w linii #32:

stream_debug_mode = False

na True i wtedy program wypluje na konsolę informacje o występowaniu wszystkich sekwencji RLE. Często widać że następuje to o czym mówiłem, tzn. że za pomocą znacznika $CF są kodowane właśnie pojedyncze wystąpienia bajtów $BF czy $CF.

No będziesz musiał dokonywać analizy pliku i wykrywać w nim segmenty danych, tzn. oddzielnie przetwarzać te bajty nagłówków a potem RLE stosować tylko do danych zawartych w danym segmencie. Tak właśnie robi ten mój pythonowy kod.

Ha! No popatrz to jest program który potrafi skopiować pliki nagrane za pomocą TurboCopy 3/4, przetestowałem go za zabezpieczonym ixion2.cas... dał radę, ale z jedną małą uwagą ;) Program też nie był świadomy że strumień danych może być xorowany, więc dobrze mi się po głowie kołatało że w czasach gdy pisałem swój "Anty Turbo Copy 3/4" też nie widziałem lodadera który by robił "xorowanie" napływających danych, więc mój stary kopier też by nie potrafił sobie poradzić z takimi danymi, zresztą efekt pracy programu "*emka" jest jak widać taki:

A8CAS-HEX
FUJI 
baud 00815
data 19325 55 55 fc 9e 9e 86 1e 51 e1 43 68 69 51 68 61 70 78 79 74 de 63 15 09 04 61 12 0e 13 02 04 13 04 13 9e ae 6b 79 5d 45 45 6d 6d 7d ae 62 79 59 51 51 11 31 71 de 63 67 6f 6f 7d 7d 59 19 91 81 41 41 de 65 62 6e 5e 9d 91 01 21 59 e1 5d e1 a1 ae 62 1e a1 25 e1 f9 e1 21 01 91 9d 5e 6e 62 de 65 41 41 81 91 19 59 7d 7d 6f 6f 67 de 63 71 31 11 51 51 59 ae 62 79 7d 6d 6d 45 45 5d ae 6b 79 61 69 6b 6f bd ; standard record; length=132, checksum=bd OK
data 00268 55 55 fc 6d 6d 7d ae 62 79 59 51 51 61 65 65 66 6e 7f 7d 59 59 11 11 01 de 65 63 67 6e 5e 9d 91 a1 c1 e1 c5 e1 62 ae 62 9f 62 cd e1 8e e1 a1 91 9d 5e 6e 67 63 de 65 01 11 11 59 59 7d 7f 6e 66 65 65 61 51 51 59 ae 62 79 7d 6d 6d 6f 6b 69 61 ae 62 11 a3 61 42 65 e5 ae 75 65 e5 20 b1 e1 61 e0 e0 e2 71 73 75 70 72 74 71 73 75 77 70 72 74 76 71 72 77 70 75 76 73 74 79 78 7a 7c 7b 7d 7f 78 7a 7c 8c ; standard record; length=132, checksum=8c OK
data 00269 55 55 fc 7e 7b 7d 7f 41 78 7d 7e 7b 7c 41 7a 7f 40 43 45 47 42 44 46 43 45 47 49 42 44 46 48 43 44 49 42 47 48 45 46 4b ae 62 11 23 61 42 e3 ae 66 65 e5 63 ae 6c 67 20 24 e0 61 9e de 63 62 9e a1 61 6e 9e 91 61 5e 9e 9d 61 5e 9e 9d 61 ae 62 9e 61 ae 62 9e 61 ae 62 9e 61 ae 62 9e 61 ae 62 9e 61 ae 62 9e 61 5e 9e 9d 61 5e 9e 9d 61 6e 9e 91 61 62 9e a1 de 63 9e de 63 62 6e 5e 5e 9d 9d a2 5d 5e cd ; standard record; length=132, checksum=cd OK
data 00268 55 55 fc ae 62 9e 5e 5e 6e 61 92 ae 60 ae a2 5d 9d 9e 9d 52 ae 63 ae 52 5d ae 63 ae 5e 9e a1 91 9d 9d 9e 5e ad 92 9e 9d a1 51 9d 9d 91 61 6e 5e 9d 9d 91 51 62 51 5d 9d 9e 9e 5e 5e 6e 61 a2 62 61 51 91 9d 91 a1 62 62 de 63 a1 ae 60 ae 6e 5e a1 9d 9e 9e 5e 6d 51 9d 9e 91 a1 51 9d 9d 91 61 6e 6e 91 9d 91 51 62 51 9d 9d 51 61 5d 91 52 62 ae 60 ae 6e 62 52 91 9d 91 a1 6e 6e 62 51 9d 92 ae 60 ae c6 ; standard record; length=132, checksum=c6 OK
data 00268 55 55 fc 5e 61 91 a2 6e 5e 6d 51 9d 5e ad 61 6d 5e 6e ad 61 6e 62 51 91 51 61 62 51 9d 51 de 62 91 52 62 ae 60 ae 62 62 61 51 91 a1 a1 52 62 62 61 51 92 a2 6e 61 a1 62 6e 6d de 63 6d 6e a1 61 6d 62 6d ad 61 6d 62 51 a1 51 61 62 61 a1 51 de 65 52 62 ad 61 62 61 51 de 62 a2 51 62 61 51 62 61 6d 61 a1 62 6d 6d de 63 6d 62 a1 de 63 62 6d a1 de 63 67 6f 63 63 62 e6 e8 ea e9 eb ed e6 e8 ea ec e9 f0 ; standard record; length=132, checksum=f0 OK
data 00269 55 55 fc eb ed ef e6 eb ec e9 ea ef e8 ed ee a1 e1 21 61 a1 e1 21 61 a1 e1 21 61 ae 65 62 ae 65 65 ae 65 64 b9 f1 29 61 99 d1 09 41 ae 65 67 ae 65 66 a1 c4 b4 64 54 04 62 e0 e0 ae 62 e3 60 62 63 61 e1 63 60 62 61 ae 64 9e 64 60 62 9e 68 6c 6a 9e 66 6e 9e 61 6c 7b 46 55 20 2f 3a 09 14 e3 ee fd c8 d7 a2 de 63 60 60 63 60 63 62 62 63 63 62 63 ae 62 60 de 63 9e 9e 9f 9e 9f 9c 9c 9f 9f 9c 9f ae 10 ; standard record; length=132, checksum=10 OK

widać w tym strumieniu danych że zamiast zwykłego nagłówka $ff,$ff występuje sekwencja $9e,$9e zatem wychodzi na to że XOR value to $61.

To by wskazywało na to na fakt że była jeszcze jakaś inna wersja Turbo Copy, bardziej rozbudowana :) Taka w której dodano jakieś dodatkowe mechanizmy zabezpieczające. Widać zarówno *EMEK jak i ja nie trafiliśmy na takie pliki pisząc swoje programy, tyle że *EMEK zrobił to w czasach (patrząc na datę) kiedy to ja jeszcze żarłem błoto... ;-)

Hej!

OK, a jeżeli wybierzemy najczęściej występujący bajt... niech będzie to zero... a plik będzie wyglądał tak:

$00 $aa $00 $55 $00 $xx $00 $yy ... etc.

To zrobi się niezła sieczka z tego :) O ile dobrze pamiętam to w grze Microx był ciekawy dekompresor RLE... to był taki znacznik bez wcześniej zdefiniowanego znacznika :) a powtarzalne sekwencje bajtów były oznaczane poprzez podwójne wystąpienie powtarzającego się bajtu w strumieniu danych, czyli np:

AA AA AA AA AA BB BB BB BB CC CC CC DD DD DD DD DD EE EE

po kompresji wyglądało tak:

AA AA 05 BB BB 04 CC CC 03 DD DD 05 EE EE 02

jak widać straty były tylko na podwójnych wystąpieniach bajtów. Ale jak pisałem wcześniej o RLE to można książkę napisać ew. doktorat zrobić na tym :D Bo pomysłów tyle ilu ludzi się tym zajmujących :D

Jeżeli taka opcja się przyda to mogę dodać dodatkową funkcjonalność, ew. napisać oddzielny kod do obsługi plików CAS... nie będzie z tym większego problemu, a i chyba będzie to wygodniejsze niż zabawa z upierdliwą konwersją na jakiś TCX ;-)

Oczywiście że można, nie doczytałem dokumentacji do a8-convert i zupełnie bez sensu robiłem cas-a a potem kopiowałem z użyciem emulatora, opcja -fr oczywiście generuje już plik odpowiedni do potraktowania pythonowym skryptem.

Faktycznie w kolekcji strykera jest sporo tego typu plików :) A na coś tam mamrotałem że mało przykładów :)

sprawdziłem, mimo że pliki CAS są różne, to binarki (-fr) i są identyczne.

eee, ale napiszesz coś więcej? Czy chodzi o to że obecnie AVG cart emuluje nie dość że SIO to jeszcze systemy turbo? tzn. zapewnia pełną obsługę plików CAS i również bloków PWM w nich zawartych (co właśnie umożliwia obsługę turbo)

Prawdę mówiąc to ja już się pogubiłem w tych wszystkich cartach które powstają ;) Ale dzięki Twojemu postowi i użyciu google właśnie się zorientowałem że myliłem AVG Cart z Ultimate Cart :)

Mam wrażenie, że temat zabezpieczenia XOR z RLE zasługuje już na nowy wątek :)

@Seban Sprawdziłem - z pośród 98 plików z 90 udało się "wypakować" exe-ki.
Okazuje się, że kopiowanie z poziomu emulatora może być konieczne, bo plik uzyskany przez opcję -fr może się różnić od skopiowanego z poziomu emulatora (gdzie powinien być prawidłowo odczytany), plik cas może też zawierać kilka plików.

Aby odczytać plik hex w emulatorze nie potrzeba go jednak konwertować na cas, bo emulator potrafi czytać pliki hex. Jest jednak inny drobny problem, nie każdy plik ma za loaderem sygnał pilota, więc po wycięciu loadera z pliku hex trzeba jeszcze sprawdzić i ewentualnie ustawić pierwszą wartość po data na 20000 (taką wartość zauważyłem w kilku plikach) i wtedy emulator odczyta wszystkie dane. Warto się upewnić, że plik hex został odczytany do końca, bo mogą się tam znajdować kolejne pliki.

Tych plików nie udało się odczytać bezpośrednio skryptem:
.\atarex\preppie2(atarex).tcx
.\haga\kaboom.tcx
.\long_blocks\other\amaurote.tcx (plik się różni gdy zostanie zgrany z emulatora)
.\oskar\jet_set_willy.tcx
.\oskar\landscape.tcx
.\oskar\montezumas_revenge.tcx
.\other\laser_hawk.tcx
.\other\whodares2_(pirat).tcx (zawiera więcej plików z czego wydaje się, ze tylko pierwszy jest z RLE).

Część plików udało się odczytać po ucięciu nadmiarowych danych, które powodowały błąd w tcx_rle_decoder.py.

Nie udało się odkodować - laser_hawk.hex, montezumas_revenge.hex, preppie2(atarex).hex prawdopodobnie również z powodu nadmiarowych danych, ale na oko nie potrafię ocenić gdzie się kończą właściwe dane, a liczyć mi się nie chciało :P

Co do nadmiarowych danych to bardziej lub tylko lekko podejrzane są te pliki (po przetworzeniu):
.\atarex\river_raid(atarex).tcx.xex
.\atarex\playfull_professor(atarex).tcx.xex
.\oskar\blue_max.tcx.xex
.\oskar\aztec.tcx.xex
.\oskar\arkanoid_3.tcx.xex

Ponieważ bezpieczniej użyć kopiowania na Atari (może być emulator), to może mógłbyś uzupełnić program *EM(E)K-a, który można by było używać bezpośrednio?

Wg tego co napisałeś próbuje on zdekodować kompresję RLE na z-XOR-owanym pliku, więc w efekcie plik wynikowy będzie jeszcze bardziej zakodowany...

W Twoim skrypcie myślę, że po odgadnięciu klucza program sam powinien go użyć. No i przydałaby się lepsza detekcja "śmieci" na końcu.

Edit: Pliki zapisywane przez -fr mogą być dłuższe niż skopiowane na Atari. Amaurote zapisany z -fr ma wplecione w plik dodatkowe Bajty.

Edit2: Who Dares Wins II nie udało się wczytać po odkodowaniu, chyba "!" się gryzie z loaderem gry?

Edit3: Próbowałem używać tego programu by *EMEK, ale zgrał tylko loader... i do tego ma wyjście tylko na taśmę w normalu :/

PS. Zrobiłem przegląd i znalazłem jeszcze 13 kaset, które prawdopodobnie będą mieć pliki z takim loaderem.