Kiedyś widziałem ofertę z rozgałązkami SIO - "bolce" wlutowane na płytce drukowanej - więc te piny powinny być gdzieś dostępne - może są wymontowywane z jakichś wtyczek dostępnych w handlu? Obecnie Lotharek ma w sprzedaży bardziej zaawansowane wersje takich rozgałęziaczy oczywiście z pinami - https://lotharek.pl/productdetail.php?id=158.

Wprawdzie to nadal nie instrukcja, ale znalazłem dobrze działający trainerek :cool: - uruchamiamy R

Ciekaw jestem tej instrukcji - teksty na załączonej kartce i pudełku jakieś dziwne (oryginalny tekst z wersji na Atari był o wiele lepszy i lepiej pasował do gry), to co może być jeszcze w ~32 stronicowej instrukcji?

Edit: Doszedłem do C i po chwili...

Wgląda na to że Robbo zainfekował się sam, bo sama gra zapisuje swój plik...

[DOSBox-a zamyka się naciskając Control+F9 i trzeba przywrócić exe-ka]

Edit2: Identyczny efekt jest z poprzednim "fix-em"...

Uszkodzenie polega na tym, że na końcu pliku jest wstawiany tekst? "olume" tworząc wpis "volume" i kolejne 10 Bajtów do końca pliku jest zmodyfikowanych (oprócz tego około 6 jest modyfikowanych, ale nie powodują problemów), może to przypadłość DOSBox-a?

Edit3: Zainstalowałem MS DOS-a pod DOSBox-em i jest tak samo. Uruchomiłem pod Bochs-em i tu zaskoczenie nie działają kody do gry zanotowane podczas gry w DOSBox-ie?! A że całość działa raz szybciej, a raz wolniej to nie udaje mi się przejść nawet do B, gdybym przeszedł dalej to ekran jest ucięty i kodów nie będzie widać, ale bym się przekonał czy się da dalej przejść. Sprawdziłem jedną z angielskich wersji i ta się w DOSBox-ie nie uszkodziła.

Metodą brute-force i patrząc na tekst ulotki odgadłem jeden kod: 29 15 5 ROBOT - wylosował się jako 71 :) więc mało prawdopodobne, żeby słowa były zapisane w całości - prawdopodobnie zapisane są tylko "sumy", a może i długość. Niestety gra uruchomiona kodem pod DOSBox-em również się uszkodziła, więc wygląda na to, że winny jest DOSBox i sama gra.

Dotychczasowe "kody" dotyczyły stron 5-8, 10-22, 24-26, 28-32. Najczęściej dot. właśnie strony 29 (8x). Maksymalny wiersz to 24. A wyraz to 6.

Edit4: Przeczytałem, że do Robbo Millennium "dla prawdziwych fanów dołączona wersja retro.", więc może jest to poprawiona bądź odblokowana wersja, a być może na CD są kody?

Edit5: Poszukałem jeszcze w innym miejscu i kolejny plik - tym razem wraz z cheat-ami (ROBBOTRN.7z) - również ten sam efekt pod DOSBox-em. No i pod Bochs-em też - po przejściu pierwszej planety z C zapisuje exe-ka i go uszkadza. Czyżby ta wersja gry miała buga? Nie chce mi się wierzyć, że twórca trainera go nie przetestował, ale z drugiej strony napisał, że robił go w nocy w pośpiechu...

Sprawdziłem z Omicron Turbo Turbo2000_WZab_2T12.xex działa poprawnie.
Aby w pełni sprawdzić magnetofon potrzebujesz czystej kasety.
Jeżeli nie masz innego magnetofonu, czy innej możliwości, żeby nagrać sygnał z PC możesz użyć adaptera kasetowego. Adapter kasetowy nie potrzebuje sprawnej mechaniki do działania, więc nawet jeżeli pasek jest do wymiany powinno się dać wczytywać programy tym sposobem.

Ponieważ zapisanie nadmiaru kodu pod adresem $0400 (bufor magnetofonu C:) wykluczało możliwość korzystania z normalu, musiałem poszukać wolnego adresu. Na co dzień nie programuję w assemblerze (a ostatnio prawie wcale), więc było to dla mnie podobnie jak cała ta modyfikacja działanie po omacku. Ostatecznie umieściłem nadmiarowe 18 Bajtów pod adresem $17FA wskazywanym przez MEMLO. W Basicu na ogół nie było mi to potrzebne, więc nie wiem czy to dobrze, ale sprawdziłem, że 18 Bajtów tam umieszczonych przetrwa odczyt najdłuższego możliwego do skopiowania przez ten program pliku i umożliwia zapis / odczyt na C:. Program da się uruchomić z MYDOS-a (innych nie sprawdzałem).

Nie lubię jak czegoś nie rozumiem, a w tym przypadku oprócz całości, nawet nie jestem pewien czy dobrze obstawiam jak działa to zabezpieczenie. Co do relokacji to program chyba sam się relokuje, bo nie widzę go pod $2080. Najbardziej mnie zdziwiło, że po wykonaniu skoku do dopisanej części program się zawieszał, kiedy jednak przeniosłem część, która tam była od początku, a w jej miejsce wstawiłem "dopisek", wszystko działa. Na końcu jest RTS, być może coś po drodze zmienia zawartość stosu? A być może chodzi o X? Dołączyłem źródełko, więc może przy okazji ktoś zerknie i coś wyjaśni?

Program może nie jest najwygodniejszy (konieczność pominięcia bloku z loaderem - co jednak może być przydatne gdy loader jest uszkodzony), ale spełnia swoje zadanie, w załączniku paczka - obydwie wersje - odczytujące pliki z AutoCopy 3.0 i 3.1 (w wersji 3.0 zmieniłem napis), oraz wersja standardowa, przerobiony asm, Loadery uzupełnione o te z wersji 3.1 (do porównania) i niezwiązany bezpośrednio z zabezpieczeniem plik do testu Turbo Long Copy (wczytany w normalu na końcu powoduje błąd, wygląda jednak na odczytany prawidłowo - dla bardziej reprezentatywnego testu trzeba by było odczytać np. losowe dane, ale test miał sprawdzić, czy przetrwa program kopiera i to wykazał).

Aby sprawdzić działanie wersji dla AutoCopy 3.1 można użyć emulatora i załączonej powyżej SuperCobry - po znalezieniu nagłówka przewijamy o trzy do przodu i odpowiadamy "T". Można też spróbować odczytać ten plik standardową wersją, która odczyta wyłącznie loadery (wersje dla 3.0 i 3.1 nie czytają standardowych bloków Turbo).

Co do loadera 2 z tzw. AutoCopy 4.0 wygląda to jak jakieś przypadkowe dane... na początku jest fragment, który znalazłem w kilkunastu grach z bazy AOL, ale nie są to gry dedykowane dla K.S.O..

Edit: Optymalizacja - program krótszy o trzy Bajty (dodatkowo nie 18, a 15B), żadnych NOP-ów.

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.

Moim zdaniem najlepiej na znacznik wybrać znak który się jak najczęściej powtarza w ciągach czyli $00 (nie przejmując się jaki sygnał z tego wyjdzie), bo i tak ten znak będzie kompresowany.

Mój programik też wyświetla dane (nieco inaczej przy kompresji i dekompresji) i widać, że te znaczniki występują praktycznie zawsze pojedynczo, więc strata dwóch Bajtów za każdym razem prawie murowana (bo może gdzieś się jednak zdarzy, że wystąpią więcej razy :D).

A ja wyszukałem pliki z takim loaderem u Strykera, jest ich co najmniej 98 - lista w załączniku, zaraz spróbuję je potraktować Twoim narzędziem. Trochę jednak szkoda, że nie obsługuje całych plików cas i nie wyciąga też loadera i danych z niego - jak linijki tytułu i tekstu scrolla... W sumie to i tak super, że zrobiłeś to narzędzie :)

Chyba ta sama wersja, ale plik cas się różni: ftp://ftp.pigwa.net/stuff/collections/s … er_3_4.cas więc do sprawdzenia.

Chyba można użyć konwersji zamiast na cas to "-fr" (raw?).

@Supaplex Interesuję się zabezpieczeniem przez które nie mogłem przenieść pliku na Turbo. Mój kompresor (jeszcze nie udostępniony) kompresuje wszystkie $BF i $CF - przeważnie występują pojedynczo, więc są zamieniane na $CF, $01, $CF lub $CF, $01, $BF, nie sądzę żeby adresy miały znaczenie, bo w pliku SuperCobra Bajty po $FF $FF nie są uaktualnione. Raczej tak jak napisał Seban wszystko jest dekodowane "w locie", więc nieskompresowany adres prawdopodobnie byłby źle zinterpretowany. Może problemem jest gdy adres trafi podzielony między bloki? Sprawdzę jak to wygląda po wczytaniu (i zwieszeniu) w pamięci.

Zastanawia mnie dlaczego w ogóle wybrano $BF i $CF, gdyby wybrać dla $00 właśnie $00 to wtedy mniej Bajtów by się marnowało na przymusową kompresję $BF, gdyż $00 z tego co widzę najczęściej się powtarza. Nie wiem czy dobrze, ale kojarzy mi się to z dalekopisem, gdzie chyba eliminowano $00?

Edit: (Powyższe napisałem zanim zauważyłem odpowiedź Sebana - pisaliśmy w tym samym czasie).

@Seban Dobry wieczór ;) Oczywiście zera i przecinki są nagrane na taśmie i do tego niektóre końcówki są uszkodzone - być może miało to być zabezpieczenie przed kopiowaniem, bo kopiowany plik za danymi zgłasza błąd. Z tego co widać przy SuperCobrze zera są dodane już po kompresji. Nie ma ich w niektórych loaderach.
Myślę, że oprócz tych dwóch kaset mam jeszcze inne zabezpieczone, z tego co pamiętam podpisane Haga Soft.
Dzięki :) Poeksperymentuję, jak coś jeszcze zgram to udostępnię.
Jeżeli adresy mają być pomijane przy kompresji to trochę skomplikuje dekompresję i kompresję :/ - będę musiał liczyć Bajty... i odpowiednio pomijać...
W przypadku Freda na początku jest mnóstwo zer - konwertuje je na ciągi $BF $FF $BF $FF... na emulatorze Atari800 z obsługą turbo nie wyrabiał.
Prawdopodobnie po kompresji żaden osobny program nie będzie w stanie stwierdzić gdzie jest wymagana dłuższa przerwa.

Edit2: Jak się okazuje takie pliki cas są również w cas archive: http://cas-archive.pigwa.net/

Atarex, to samo, może i inne?

Jest nawet ftp://ftp.pigwa.net/stuff/collections/s … ier_34.cas by *EMEK
KSO 1.0 podpisany >Genio< ftp://ftp.pigwa.net/stuff/collections/s … er/kso.cas

Edit3: W załączniku jeszcze wersja kompresująca / dekompresująca cały plik. Program nie zgłasza błędów, plik źródłowy musi się znajdować w podanej ścieżce, inaczej program prosi o podanie nazwy aż do skutku. Return pozostawia ustawienia bez zmian. Podanie innych wartości niż przewidziane nie jest sprawdzane i spowoduje nieprzewidziane działanie programu!!! Nie sprawdzałem czy działa zapis na C, choć taki przewidziałem.

@Sikor Super, fajnie, że rozpoznałeś wkładki, jestem bardzo ciekaw czy też masz zabezpieczone pliki, póki co sprawdziłem, że Fred i Ninja Commando nie potrzebują loadera, a pozostałe tak, jeszcze sprawdzę czy ze standardowymi L1 i L2 pójdą. No i ciekawe co masz na tych kasetach? :) Ja w ogóle miałem ich mało...

@Seban Zauważyłem przy scenach do Karateki - 12672 Bajty przed kopiowaniem i jeszcze ze dwa inne pliki, ale nie pamiętam.

Co do tych kopierów to chyba ich nie ma. Turbo Copy jest kilka, ale żaden mi nie pasuje - dwa do K.S.O. Long Turbo Copy i Turbo Copy ("wbudowany"), jeden z Tajemnic Atari wyłącznie do normalu i jeden, który pyta o plik źródłowy i docelowy, więc też nie wygląda na to. Innych nie zauważyłem.

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?

Ja też tylko emulatora, ROM-ów i programu Long Turbo Copy oraz Kopiarka Turbo, bez nich to nie wiem jak miałbym ten sygnał w samym emulatorze odczytać? A do zgrywania i edycji, gdyby była potrzebna to bym użył Audacity.

Zwykłe programy kopiujące używają handlera zawartego w programie K.S.O., więc nie mają wpływu na generowany sygnał. Dedykowane z wbudowaną obsługą Turbo - jak te których użyłem - tak.

Odpowiedź na pytanie wątku brzmi: NIE

Co do odpowiedzi na dodatkowe pytanie to skoro mamy ustalić jak / czym (software / hardware) był zapisany sygnał informacja o szumie może być istotna.

Edit: jeżeli chcesz ustalić czy to software generuje taki efekt to sprawdź sygnał generowany różnymi wersjami Turbo K.S.O. zapisany zwykłym kopierem, oraz zapisany dedykowanymi narzędziami. Na emulatorze wyeliminujesz wpływ hardware-u. Choć ja bym raczej obstawiał że taki efekt wygenerował hardware. Może odstęp pomiędzy głowicą nagrywającą, a kasującą miał na to wpływ, więc i poprzednia zawartość może mieć wpływ.

Edit2: Tylko wtedy dziwne, że przed pilotem "nazwy" tego nie ma... czyli jednak software?

Edit3: A czy w niewielkim odstępie za ostatnim blokiem nie ma podobnego zniekształcenia na "ciszy" - kiedy wyłącza się głowica kasująca?

@Willy Też już o tym pisałem :)

Co do tych zagięć to niekoniecznie, bo mogłoby się zdarzyć że to zagięcia powstałe po przeciwnej stronie taśmy. A może sygnał jest nieco inaczej zapisany i przerwy są krótsze?

Szkoda, że nie mamy udostępnionego chociaż jednego programu w wav-ie może na słuch ktoś by coś więcej wywnioskował, no i chętnie bym sprawdził na Atari i z innymi programami niż emulator.