276

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

krap napisał/a:

DT Feniks moim drugim domem w mlodosci. Przesiadywalem tam godzinami.

hehe, nieźle... czyli jest szansa że się tam kiedyś widzieliśmy smile miałem tam dość blisko więc też odwiedzałem to miejsce smile Najczęściej z kolegą z podstawówki który często i gęsto kupował tam gry na kasetach, ew. przychodził odebrać nagrane zestawy smile

krap napisał/a:

Zalaczam .casa z "Universal Hero" z tym loaderem.

Dokładnie! To jest ten loader smile Dzięki za złączenie tego, nie dość że ma to wartość historyczną to jeszcze przywołuje wspomnienia.

Pamiętam że pierwsze gry które kopiowałem via audio z kasety na "szpulowca" to były "Fort Apocalypse" oraz "Pole Position". Natomiast pierwsze gry które widziałem w życiu na Atari to były "Boulder Dash" oraz "River Raid", były to oczywiście kasety "piraty" kupione przez kolegę (a właściwie jego matkę) w DT Wars. Wtedy nie miałem jeszcze własnego komputera, i dziś sądzę że właśnie to zetknięcie się Atari i tymi grami, spowodowało że miałem nowe marzenie smile Zapragnąłem mieć komputer, dokładnie taki komputer, żaden inny tylko właśnie taki. Trochę to potrwało, jednak marzenie spełniło pewnego grudniowego wieczoru smile

dely napisał/a:

A wersja audio też tutaj: http://www.atari.org.pl/tape/8/feud-(we … komputera) … komputera)

no zupełnie zapomniałem że to leżało również na AA zgrane przez Ciebie, jak przez mgłę pamiętałem że CAS chyba leżał na cas-archive, co potwierdził szybki google-search. A że zgrywałeś taśmę od Ryszarda, to już wyleciało mi z głowy zupełnie. Niestety na szpulach Feud z radiokomputera się mi nie ostał, bo nadpisałem czym innym ;/ Dobrze że plik przetrwał u kogoś innego w zasobach smile

Ostatnio edytowany przez seban (2020-05-04 11:07:18)

life is complex, it has both real and imaginary components.

277

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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

--
= krap.pl =

278

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

O kurczę! Co za materiał (katalog!) prawdę mówiąc tylko jakieś strzępy obrazów z tamtych czasów w mojej głowie pozostały, katalogu praktycznie nie pamiętałem... te wspomnienia zupełnie się zatarły z upływem czasu! smile Dzięki za udostępnienie! Ożywiasz dawne wspomnienia smile

No i świetną wiadomością jest to że archiwizujesz to co przetrwało!

Ostatnio edytowany przez seban (2020-05-04 13:18:19)

life is complex, it has both real and imaginary components.

279

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Chodziło mi raczej o pliki zabezpieczone przez AutoCopy 3.0 lub podobnie, ale ciekawie, że pojawiły się też inne informacje i katalog smile - 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:

UWAGA!
PRZECHOWYWAĆ Z DALA OD ŹRÓDEŁ
POLA MAGNETYCZNEGO ( głośników,
silników i inn.urzadz.elektrycz)

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

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?

Ostatnio edytowany przez QTZ (2020-05-08 07:07:46)

Post's attachments

NORMAL.7z 79.25 kb, liczba pobrań: 17 (od 2020-05-08) 

Tylko zalogowani mogą pobierać załączniki.

280

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

A masz jakiś skan okładek od brodatego, może warto sprawdzić. Ale to jak magnetofon jakiś sprawny wyczaję.

Sikor umarł...

281

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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

Ostatnio edytowany przez QTZ (2020-05-08 08:07:52)

Post's attachments

TurboKSO_Tape05.jpg 1.27 mb, liczba pobrań: 1 (od 2020-05-08) 

Tylko zalogowani mogą pobierać załączniki.

282

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Tych miałem mało, ale poszukam przy okazji.

Sikor umarł...

283

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Hej!

QTZ napisał/a:

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.

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 smile 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?

QTZ napisał/a:

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?

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.

Ostatnio edytowany przez seban (2020-05-08 10:37:48)

life is complex, it has both real and imaginary components.

284

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@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? smile 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.

Ostatnio edytowany przez QTZ (2020-05-08 11:42:23)

285

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Jeszcze jedno...

QTZ napisał/a:

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

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 wink

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.

Ostatnio edytowany przez seban (2020-05-08 17:31:05)

life is complex, it has both real and imaginary components.

286

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@Qtz: oprócz L1 i L2 był jeszcze jeden loader, nie pamietam teraz nazwy, ale na pewno nie nazywał się L3 tylko jakoś inaczej. Miałem na pierwszej kasecie z KSO, tą kasetę  gdzieś jeszcze mam...

Sikor umarł...

287

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@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 wink 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.

Ostatnio edytowany przez QTZ (2020-05-09 17:14:57)

Post's attachments

pierestry_rle.cas 19.44 kb, liczba pobrań: 5 (od 2020-05-09) 

Super Cobra RLE Decoder.7z 7.34 kb, liczba pobrań: 9 (od 2020-05-09) 

Tylko zalogowani mogą pobierać załączniki.

288

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@QTZ napisałem compressor i oprócz Super Cobry, spróbowałem na kilku plikach: River Raid...

Fajnie że interesujesz się kompresją RLE TYPU  BF-CF. Twój dekompresor nie uwzględnia jednej rzeczy, adresy ładowania nie podlegają kompresji. W przypadku River Raid adresy ładowania to $9FFO, $BFFF, $02E0, $02E1. Na pewno możesz wyobrazić sobie jak twój dekompresor potraktuje adres $BFFF który nie powinien zostać dekompresowany.
P.S.
Osobiście uważam że adresy powinny być kompresowane, ale algorytm jest jaki jest.

289

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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ą tongue ja się nie nim nie znam, więc mogę sobie pozwolić na mówienie takich herezji tongue)

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 tongue

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?

Ostatnio edytowany przez seban (2020-05-10 02:16:11)

life is complex, it has both real and imaginary components.

290

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@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 wink 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 smile Poeksperymentuję, jak coś jeszcze zgram to udostępnię.
Jeżeli adresy mają być pomijane przy kompresji to trochę skomplikuje dekompresję i kompresję hmm - 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/

Oskar and Haga Soft games (...) jest tylko jeden problem z tymi grami z Oskara( te ze skrollowanym loaderem) duża ich ilość po wgraniu ma błędy na ekranie - i teraz niewiem czy robi
to jakieś zabezpieczenie czy owe gry już były takie na taśmie... może ktoś wie jak to rozwiązać ??

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.

Ostatnio edytowany przez QTZ (2020-05-10 10:27:39)

Post's attachments

SCRLE.7z 1.78 kb, liczba pobrań: 4 (od 2020-05-10) 

Tylko zalogowani mogą pobierać załączniki.

291

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Hej!

QTZ napisał/a:

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.

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 smile 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? wink 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.

QTZ napisał/a:

Jeżeli adresy mają być pomijane przy kompresji to trochę skomplikuje dekompresję i kompresję hmm - będę musiał liczyć Bajty... i odpowiednio pomijać...

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

http://seban.pigwa.net/aa/EMEK_TurboCopy_34.png

life is complex, it has both real and imaginary components.

292

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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

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 smile

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

Ostatnio edytowany przez QTZ (2020-05-10 14:35:57)

Post's attachments

scroll.7z 1.12 kb, liczba pobrań: 6 (od 2020-05-10) 

Tylko zalogowani mogą pobierać załączniki.

293

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Hej!

QTZ napisał/a:

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.

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 smile O ile dobrze pamiętam to w grze Microx był ciekawy dekompresor RLE... to był taki znacznik bez wcześniej zdefiniowanego znacznika smile 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 big_smile Bo pomysłów tyle ilu ludzi się tym zajmujących big_smile

QTZ napisał/a:

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

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

QTZ napisał/a:

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

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 smile A na coś tam mamrotałem że mało przykładów smile

QTZ napisał/a:

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.

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

Ostatnio edytowany przez seban (2020-05-10 16:50:18)

life is complex, it has both real and imaginary components.

294

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

https://youtu.be/iI_47bYy0Vg

Nie wiem, czy w dobry wątek wkleiłem.

Ostatnio edytowany przez lemiel (2020-05-10 17:50:42)

295

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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)

life is complex, it has both real and imaginary components.

296

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Trzeba tmp zapytać. Dopiero opublikował. Zobaczyłem, pokazałem.
Być może.

297

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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

life is complex, it has both real and imaginary components.

298

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Ale ten wątek bardzo się przydał. Montezuma go podesłał na AAge.
I tak to emulacja z poziomu Varta.

299

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

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

@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 tongue

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 hmm

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

Ostatnio edytowany przez QTZ (2020-05-12 10:17:12)

300

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Hej!

Tak na szybko odpowiadając na to co napisałeś...

No widzę że wykonałeś kawał roboty! smile Oczywiście przyjrzę się temu co nie działa i nie udało się.
Popatrzę również na czym wysypuje się ten pythonowy prymityw, poprawię oczywiście.
Napiszę też w wolnym czasie konwerter CAS->TCX/XEX.

QTZ napisał/a:

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?

Chyba szybciej będzie napisać taki kopier od nowa... ew. poszukam tych swoich staroci, może znajdę ten swój stary kod gdzieś. Ale to proszę o chwilę cierpliwości kolejka rzeczy do zrobienia trochę ma sad a doba za krótka jest ;/

QTZ napisał/a:

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.

też o tym myślałem ale zdecydowałem że może tak będzie intuicyjnej bo użytkownik bardziej świadomy tego co się dzieje? Mogę zmienić bo to żaden problem, tylko czy to nie zaciemni obrazu sytuacji i nie zmniejszy świadomości użytkownika? Jeżeli chodzi o detekcję śmieci, to to co tam jest obecnie to mega prymityw, przyjrzę się temu co występuje w plikach które wytypowałeś i rozbuduję procedurę wykrywania o coś bardziej "inteligentnego".

QTZ napisał/a:

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 hmm

No ja użyłem Turbo Copy 3/4 by *EMEK i zadziałał bezbłędnie, zgrał całość danych poza loaderem. Robiłem to pod emulatorem z włączonym SIO Patch dla "C:". Dlatego też zapis był tylko w normalu nie był przeszkodą. Ale zajmowałem się nim tylko aby sprawdzić czy działa i czy radzi sobie z tymi plikami.

update[1]:

Preppie... na końcu są oczywiście dodatkowe śmiecie, nie są to niestety zera i 4 następne bajty po segmencie RUN ($2e0,$2e1) układają się w jakimś tam w miarę sensowny nagłówek, co prawda danych jest za mało potem i dlatego python protestuje (index error), widać to o czym mówię na konsoli:

Input file is preppie2(atarex).raw and the file size is 12672 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $2000-$599f
block 001: $02e0-$02e1
block 002: $9a85-$c985
Traceback (most recent call last):
  File "tcx_rle_decoder.py", line 125, in <module>
    if (in_data[i] == 0xbf):
IndexError: bytearray index out of range

po bloku #1, występuje teoretycznie blok #2 niby wiadomo że adres końcowy bloku wykracza poza ram, ale nie chciałem ograniczać skryptu. Można analizować takie przypadki i informować użytkownika że dane zostały porzucone, przepatrzę następne przypadki i pewnie poprawię detekcje takich śmieci. Normanie można by kończyć dekodowanie po napotkaniu segmentu RUN, ale wcale nie ma gwarancji że będzie on ostatnim segmentem danych. Może być równie dobrze i pierwszym.

update[2]:
Kaboom to samo... niezerowe śmieci na końcu, które łapią się jako następne segmenty danych....

Input file is kaboom.raw and the file size is 4352 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $a000-$afff
block 001: $bffa-$bfff
block 002: $9600-$9633
block 003: $02e0-$02e1
block 004: $2c2c-$2c2c
...
...
block 038: $2c2c-$2c2c
block 039: $2c2c-$782c
Traceback (most recent call last):
  File "tcx_rle_decoder.py", line 125, in <module>
    if (in_data[i] == 0xbf):
IndexError: bytearray index out of range

update[3]:

Amaroute(tal-qwerty)... a to jest zmodyfikowany loader, być może inna wersja kopiera. według informacji pliku CAS Rekordy mają po 129 bajtów (nie licząc bajtów nagłówka oraz CRC). W sumie to nie wiem jak to działa bo loader używa standardowego odczytu przez CIO ustawiając długość rekordu na 128 bajtów. Nie bardzo więc wiem czemu to nie kończy się błędem? ... sprawdziłem:

update[3.5]:

QTZ napisał/a:

.\long_blocks\other\amaurote.tcx (plik się różni gdy zostanie zgrany z emulatora)

No różni się bo ROM po prostu ignoruje 129 bajt... i gdy robisz kopię poprzez emulator to zapisujesz 128 bajtowe rekordy, tak przetworzona wersja gry po prostu działa. A8CAS przetwarza to co dostaje z pliku CAS czyli 129 bajtowe rekordy danych.

Można sobie przeanalizować np. pierwszy rekord za loaderem:

irg len: 20000
baud calibration bytes: 55 55
recrord type: fc
record data:
87 87 78 68 87 67 83 87 86 78 6d 87 85 8f 86 c7 7a 07 87 a7 a6 c7 7a 03 83 87 86 c7 7a 07 97 b7
79 c7 87 d0 78 07 87 a7 03 87 84 78 73 85 87 8f 84 c7 7a 07 87 87 a4 c7 7a 43 87 87 86 c7 7a 47
97 87 b7 79 c7 a8 78 47 87 a6 8f 87 84 78 7f b7 79 c7 87 97 84 c7 7a 43 87 87 c4 c7 7a 45 87 87
a4 c7 7a 47 8f 87 85 98 78 47 87 97 8f 87 80 78 75 87 87 97 80 c7 7a 47 87 87 c0 c7 7a 65 87 87
crc: 83
additional spare byte: 07 

; standard record; length=133, checksum=07 OK

procedury w ROM czytają 132 bajty ($55,$55,$fc... 128 bajtów danych rekordu, CRC), jako CRC uznają bajt 0x83 i wszystko się zgadza, ostatni bajt w rekordzie danych ($07) po prostu ginie ignorowany.

No chyba że to jest jakiś źle zgrany CAS??? ale błąd byłby we wszystkich rekordach? Być może tak jest bo rekordy początkowe (loadera) też mają o jeden bajt za dużo. Ale ciekawe jest to że CRC danych dla rekordu 128 bajtów to właśnie $83, a CRC z dodatkowym bajtem CRC wliczanym do rekordu to właśnie $07. Nie wiem jakieś jest źródło tego pliku, i jakim softem był robiony ten CAS ale wygląda to dość dziwnie. Cały czas się zastanawiam czy fizycznie było na kasecie tak nagrane czy jakiś software dokonujący konwersji odwalił coś takiego?

Dodatkową ciekawostką może być fakt że w loaderze widnieje podpis "RK1987". Nie wiem kto się tam podpisał... jedyny RK który robił różne rzeczy (sprzęt, programy) w tamtych czasach to był Robert Kujda. Ale zbieżność może być przypadkowa.

update[4]:

jest_set_willy.cas ... jak zwykle końcówka to jakieś śmieciowe zbędne dane, śmieci fałszywie interpretowane jako block #13, a potem zabrakło danych wejściowych więc index error.

Input file is jet_set_willy.raw and the file size is 35968 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $0c00-$19b4
block 001: $2000-$2975
block 002: $29a0-$2f8c
block 003: $3033-$30ef
block 004: $3105-$31a6
block 005: $3200-$32ec
block 006: $3800-$4f5f
block 007: $02e0-$02e1
block 008: $4f86-$5998
block 009: $59b0-$5cab
block 010: $5cf6-$67ff
block 011: $6f60-$7d25
block 012: $8000-$b87f
block 013: $9235-$9f93
Traceback (most recent call last):
  File "tcx_rle_decoder.py", line 125, in <module>
    if (in_data[i] == 0xbf):
IndexError: bytearray index out of range

Przy okazji, to jest właśnie dobry przykład pliku w którym segment RUN ($2e0,$2e1) występuje gdzieś w środku pliku, pomiędzy innymi segmentami. Muszę się przyjrzeć dokładniej jak na coś takiego reaguje loader, ale jeżeli reaguje tak jak sądzę to może być tak że w tym wypadku ten ostatni "śmieciowy" segment uszkadza dane gdy zawarte w lokacji $9235 do $9235 plus tyle bajtów śmieci ile tam zostało. Loader uruchamia wczytywany plik wtedy gdy napotka błąd typu "End of file".

dobra... teraz jeszcze zauważyłem patrząc na HEX-a że przy w pliku CAS na właściwą grą są jeszcze jakieś 3 rekordy nagrane:

data 00320 55 55 fc 3e 34 35 36 3e 34 35 34 3f 34 3e 34 3c 34 23 34 3e 34 23 34 3e 34 35 34 23 34 3e 34 35 34 23 34 3e 34 23 34 3e 34 23 34 3e 36 1c 31 52 34 20 2e 35 01 05$
data 00320 55 55 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00$
data 00320 55 55 fc a7 a6 aa a6 ac a6 ab a6 b1 a6 ac a5 ab a6 b1 a6 ac a4 a7 a6 aa a6 ac a6 ab a6 b1 a6 ac a6 a7 a5 8e a3 b3 a6 a7 a6 b1 a6 b7 a6 ad a6 ac a6 ae a6 b7 a6 b1$
data 00320 55 55 fc a7 a6 b1 a6 b7 a6 ac a6 b7 a6 b1 a6 b7 a6 a7 a5 8e a3 b3 a6 a7 a6 b1 a6 b7 a6 a7 a4 b7 a6 b1 a6 b7 a6 b1 a6 b7 a6 b1 a6 b7 a6 b1 a6 ab a6 a7 a6 b1 a6 b7$
data 00320 55 55 fc ac a6 a7 a4 ac a6 a7 a6 ad a6 ac a6 ae a6 b1 a6 ac a6 b1 a6 ac a6 a7 a6 b1 a6 ac a6 a7 a6 b1 a6 ac a6 b1 a6 ac a6 b1 a6 ac a4 8e a3 c0 a6 b2 bc a7 93 97$
data 00320 55 55 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00$

które po przetworzeniu przez a8cas-concvert do formatu RAW trafiają jako śmiechiuchy do TCX-a.

po wywaleniu tych rekordów, skrypt sobie nawet poradził tongue i pominął klasyczne zerowe śmiecie (71 bajtów na końcu).
W tym wypadku zwykła kopiowanie "C:"->"D:" np. za pomocą emulatora, pozwoliłoby na pominięcie tych 3 ostatnich śmiecio-rekordów.
w tym wypadku a8cas-convert zrobił co do niego należało i przekonwertował wszystkie rekordy zawarte w pliku .cas to hex, potem po wywaleniu ręcznie loadera, dodatkowe rekordy (niezauważone przeze mnie) trafiły do tcx.

Input file is jet_set_willy.raw and the file size is 35584 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $0c00-$19b4, segment size = $0db5
block 001: $2000-$2975, segment size = $0976
block 002: $29a0-$2f8c, segment size = $05ed
block 003: $3033-$30ef, segment size = $00bd
block 004: $3105-$31a6, segment size = $00a2
block 005: $3200-$32ec, segment size = $00ed
block 006: $3800-$4f5f, segment size = $1760
block 007: $02e0-$02e1, segment size = $0002
block 008: $4f86-$5998, segment size = $0a13
block 009: $59b0-$5cab, segment size = $02fc
block 010: $5cf6-$67ff, segment size = $0b0a
block 011: $6f60-$7d25, segment size = $0dc6
block 012: $8000-$b87f, segment size = $3880

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

Input data processing done, 13 block(s) processed, generating output file...
Output file is jet_set_willy.raw.xex and the file size is 38235 bytes.
Processing done, output file written, IN/OUT file size diff is 2651 byte(s).

update[4]:

oskar\montezumas_revenge.raw --> ten plik jest uszkodzony, brakuje w nim ostatnich 80 bajtów. Struktura pliku jest identyczna z tym u fandala: Montezuma's Revenge!.

Jednak ten plik jest ciekawy z innego powodu... on zawiera 547 segmentów danych!!! big_smile

Header is: $ffff
block 000: $0a00-$0a3c ($003d)
block 001: $02e2-$02e3 ($0002)
block 002: $02e0-$02e1 ($0002)
block 003: $1e00-$3307 ($1508)
block 004: $3316-$3324 ($000f)
block 005: $3334-$3344 ($0011)
block 006: $3354-$3367 ($0014)
block 007: $3374-$3387 ($0014)
block 008: $3391-$33a6 ($0016)
...
...
...
block 529: $b900-$b903 ($0004)
block 530: $b928-$b92b ($0004)
block 531: $b950-$b953 ($0004)
block 532: $b968-$b98f ($0028)
block 533: $b996-$b997 ($0002)
block 534: $b9a0-$b9a3 ($0004)
block 535: $b9ac-$b9ad ($0002)
block 536: $b9be-$b9bf ($0002)
block 537: $b9c8-$b9cb ($0004)
block 538: $b9d4-$b9d5 ($0002)
block 539: $b9e6-$b9e7 ($0002)
block 540: $b9f0-$b9f3 ($0004)
block 541: $b9fc-$b9fd ($0002)
block 542: $ba0e-$ba0f ($0002)
block 543: $ba18-$ba1b ($0004)
block 544: $ba24-$ba25 ($0002)
block 545: $ba30-$ba57 ($0028)
block 546: $baf8-$bfff ($0508)
^^^^^^^^^: unexpected end of data at file segment! [missing $0050 byte(s)]
         : block throwed away, output file may be corrupted.

Trying to cleanup data segments, removing blocks: done.

To jest jakiś hardcore, normalnie pomyślałbym że to sprawka "Zagęszczacza" Dariusza Rogozińskiego, ale nie... procedura zerująca RAM jest ulokowana gdzie indziej i o ile dobrze pamiętam to ona tak nie wyglądała. Sprawdziłem również plik z Atarimania i tam jest dokładnie to samo. Wygląda więc na to że ktoś wpadł na pomysł pomijania zer poprzez generowanie segmentów danych tak aby pozbyć się tychże zer już przed Darkiem Rogozińskim ;-)

update[5]:

Laser Hawk... kolejny przykład uwalonej końcówki pliku, brakuje ponad 4kb danych:

TCX data loaded, checking data...

>>> Data encrypted! Trying to use calculated XOR key 0xE1 <<<

Header is: $ffff
block 000: $02e0-$02e1 ($0002)
block 001: $2000-$a1ff ($8200)
block 002: $a900-$bfff ($1700)
^^^^^^^^^: unexpected end of data at file segment! [missing $1005 byte(s)]
         : block throwed away, output file may be corrupted.

Trying to cleanup data segments, removing blocks: done.

Input data processing done, 2 correct block(s) processed, generating output file...
Output file is laser_hawk.cas.hex.raw.xex and the file size is 33292 bytes.
Processing done, output file written, IN/OUT file size diff is 1804 byte(s).

porównałem z innymi wersjami dostępnymi w sieci, np. na AoL:

chkxex.py "Laser Hawk (1986)(Red Rat Software)(GB)[a2].xex"

Input file is Laser Hawk (1986)(Red Rat Software)(GB)[a2].xex and the file size is 39454 bytes.

Header is: $ffff
block 001: $100d-$102d ($0021)
Header is: $ffff
block 002: $10f1-$11c9 ($00d9)
block 003: $02e2-$02e3 ($0002) ---> INIT $100d
block 004: $02e0-$02e1 ($0002) --->  RUN $2000
Header is: $ffff
block 005: $2000-$a1ff ($8200)
Header is: $ffff
block 006: $a900-$bfff ($1700)

File Laser Hawk (1986)(Red Rat Software)(GB)[a2].xex is OK!

i w tej wersji widać że końcowy segment jest pełny. ten Laser Hawk z oskarowego cas-a jest po prostu uszkodzony. Jedyna różnica jest taka że loader do upadłego czyta sobie bajty i gdy napotka koniec danych w trakcie gdy w danym segmencie powinny być jeszcze dodatkowe dane, to on nic sobie z tego nie robi i po prostu uruchamia program o ile wie gdzie. W tym wypadku wie bo wcześniej był ustawiony adres RUN. Mój pythonowy "demiąchator" po prostu wywala ten segment świadomie do śmieci, bo niby jak ma potraktować takie coś? mógłby teoretycznie zachować się jak loader z TC3/4 ale wyprodukował by w takim wypadku na wyjściu plik który mógłby sprawiać wrażenie działającego, ale koniec końców danych by brakowało.

Poprawiłem zresztą ten skrypt dekodujący, teraz nie powinien się wywalać i robi dodatkowo porządki z danymi na tyle na ile jest w stanie się "domyślić" co wywalić, a co kopiować do pliku docelowego. Jak skończę analizę tych nie dających się konwertować plików to uaktualnię repozytorium na github. przy okazji powstał też taki chkxex, tyle że napisany w pythonie wink

update[6]:

"other\whodares2_(pirat).tcx" ... jest tak jak pisałeś smile ktoś zrobił z tego totalny bezsens smile być może tylko po to aby dodać swoją czołówkę/reklamę. Loader z Turbo Copy 3/4 po prostu ładuje inny loader który to już ładuje właściwe pliki gry, tych plików jak mówiłeś jest kilka. konwersja tego chyba nie ma sensu, bo do jakiej postaci? pozbycie się loadera Turbo Copy 3/4?

Rzuciłem okiem na kod tego loadera który ładowany jest przez loader z TC3/4... oryginalnie to był plik boot który miał 6 rekordów i ładował się w obszar $600-$7FF a potem ów boot-loader uruchamiał i wczytywał resztę plików do pamięci. Ktoś wziął ten loader przerobił na file:

chkxex.py "whodares2_(pirat).cas.hex.raw.xex"

Input file is whodares2_(pirat).cas.hex.raw.xex and the file size is 836 bytes.

Header is: $ffff
block 001: $0100-$0139 ($003a)
block 002: $bd0c-$bfff ($02f4)
block 003: $00b0-$00b7 ($0008)

File whodares2_(pirat).cas.hex.raw.xex is OK!

przeróbka BOOT--->XEX chyba ręczna, bo nie widziałem programu/automatu który by w ten sposób działał. Był co prawda supercopy-cośtam do konwersji BOOT <---> XEX, ale on zdecydowanie więcej śmiecia dokładał, w dodatku umieszczał swoją prockę przepisującą gdzieś w buforze drukarki (chyba $3c0...)

W tym wypadku jest to po prostu zrobione po najmniejszej linii oporu, dało by się krócej/ładniej, etc. ale nie było chyba potrzeby. Zatem patrząc na ten kawałek, można powiedzieć że segment $bd0c-$bfff zawiera oryginalny loader w formacie BOOT, procedura umieszczona nisko na stosie $100-$139 dokonuje przepisania tego loadera we właściwe miejsce, korzysta przy tym z informacji zawartych w lokacji $b0-$b7. Nie ma co prawda segmentów INIT/RUN ale loader od TurboCopy 3/4 w tym wypadku uruchamia plik skacząc do pierwszego załadowanego segmentu danych, czyli w tym wypadku $100.

update[7]:

atarex\river_raid(atarex) ... jak zwykle śmiecie na końcu, cała masa śmieci:

Input file is river_raid(atarex).cas.hex.raw and the file size is 8192 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $9ff0-$b81f ($1830)
block 001: $b838-$b84a ($0013)
block 002: $b865-$b89d ($0039)
block 003: $b8b6-$b8d6 ($0021)
block 004: $b8ee-$b8f2 ($0005)
block 005: $b8ff-$b8ff ($0001)
block 006: $b91c-$ba14 ($00f9)
block 007: $ba1e-$ba1e ($0001)
block 008: $ba27-$ba2a ($0004)
block 009: $ba32-$ba37 ($0006)
block 010: $ba3e-$ba45 ($0008)
block 011: $ba4b-$baf4 ($00aa)
block 012: $bafe-$baff ($0002)
block 013: $bb09-$bb0a ($0002)
block 014: $bb12-$bb2f ($001e)
block 015: $bb37-$bb71 ($003b)
block 016: $bb78-$bb7b ($0004)
block 017: $bb82-$bba1 ($0020)
block 018: $bbaf-$bfff ($0451)
block 019: $02e0-$02e1 ($0002)
block 020: $2c00-$2c2c ($002d)
block 021: $2c2c-$2c2c ($0001)
block 022: $2c2c-$2c2c ($0001)
block 023: $2c2c-$2c2c ($0001)
block 024: $2c2c-$2c2c ($0001)
block 025: $2c2c-$2c2c ($0001)
block 026: $2c2c-$2c2c ($0001)
block 027: $2c2c-$2c2c ($0001)
block 028: $2c2c-$2c2c ($0001)
block 029: $2c2c-$2c2c ($0001)
block 030: $2c2c-$2c2c ($0001)
block 031: $2c2c-$2c2c ($0001)
block 032: $2c2c-$2c2c ($0001)
block 033: $2c2c-$2c2c ($0001)
block 034: $2c2c-$2c2c ($0001)
block 035: $2c2c-$2c2c ($0001)
block 036: $2c2c-$2c2c ($0001)
block 037: $2c2c-$2c2c ($0001)
block 038: $2c2c-$2c2c ($0001)
block 039: $2c2c-$2c2c ($0001)
block 040: $2c2c-$2c2c ($0001)
block 041: $2c2c-$2c2c ($0001)
block 042: $2c2c-$2c2c ($0001)
block 043: $2c2c-$2c2c ($0001)
block 044: $2c2c-$2c2c ($0001)
block 045: $2c2c-$2c2c ($0001)
block 046: $2c2c-$2c2c ($0001)
block 047: $2c2c-$2c2c ($0001)
block 048: $2c2c-$2c2c ($0001)
block 049: $2c2c-$2c2c ($0001)
block 050: $2c2c-$2c2c ($0001)
block 051: $2c2c-$2c2c ($0001)
block 052: $2c2c-$2c2c ($0001)
block 053: $2c2c-$2c2c ($0001)
block 054: $2c2c-$2c2c ($0001)
block 055: $2c2c-$0000 ($-2c2b)
^^^^^^^^^: Invalid block header detected! Processing stoped.

>>> Something is really wrong! File corupted!?! Sorry, I can't do anything more. Exiting.

Po wywaleniu wszytkiego po bloku 019, gra wróci do postaci którą da się uruchomić smile

update[8]:

atarex\playfull_professor(atarex).tcx, jak w poprzednich wypadkach nadmiarowe dane na końcu.

Input file is playfull_professor(atarex).cas.hex.raw and the file size is 32128 bytes.
TCX data loaded, checking data...

Header is: $ffff
block 000: $000a-$000d ($0004)
block 001: $0600-$068f ($0090)
block 002: $02e0-$02e3 ($0004)
block 003: $bf00-$bfff ($0100)
block 004: $3080-$bc1f ($8ba0)
block 005: $0000-$0000 ($0001)
^^^^^^^^^: Invalid block header detected! Processing stoped.

Input data processing done, 5 correct block(s) processed, generating output file...
Output file is playfull_professor(atarex).cas.hex.raw.xex and the file size is 36174 bytes.
Processing done, output file written, IN/OUT file size diff is 4046 byte(s).

update[9]:

\oskar\blue_max.tcx tak jak wyżej, czyli nadmiarowe dane na końcu:

Input file is blue_max.cas.hex.raw and the file size is 22528 bytes.
TCX data loaded, checking data...

>>> Data encrypted! Trying to use calculated XOR key 0x49 <<<

Header is: $ffff
block 000: $b000-$b06a ($006b)
block 001: $02e2-$02e3 ($0002)
block 002: $9900-$992a ($002b)
block 003: $02e0-$02e1 ($0002)
block 004: $2400-$245d ($005e)
block 005: $2580-$25dd ($005e)
block 006: $2600-$2767 ($0168)
block 007: $2800-$28a7 ($00a8)
block 008: $2900-$29b2 ($00b3)
block 009: $2a00-$2a69 ($006a)
block 010: $2b00-$2b47 ($0048)
block 011: $2b80-$2be9 ($006a)
block 012: $2c00-$7687 ($4a88)
block 013: $7770-$79d2 ($0263)
block 014: $7c00-$7fff ($0400)
block 015: $8400-$8adf ($06e0)
block 016: $4949-$4949 ($0001)
^^^^^^^^^: Invalid block header detected! Processing stoped.

Input data processing done, 16 correct block(s) processed, generating output file...
Output file is blue_max.cas.hex.raw.xex and the file size is 23874 bytes.
Processing done, output file written, IN/OUT file size diff is 1346 byte(s).

update[10]:

\oskar\aztec.tcx ponownie nadmiarowe dane na końcu:

Input file is aztec.cas.hex.raw and the file size is 32128 bytes.
TCX data loaded, checking data...

>>> Data encrypted! Trying to use calculated XOR key 0x50 <<<

Header is: $ffff
block 000: $2006-$217f ($017a)
block 001: $02e0-$02e3 ($0004)
block 002: $3d00-$bcff ($8000)
block 003: $5050-$5050 ($0001)
^^^^^^^^^: Invalid block header detected! Processing stoped.

Input data processing done, 3 correct block(s) processed, generating output file...
Output file is aztec.cas.hex.raw.xex and the file size is 33164 bytes.
Processing done, output file written, IN/OUT file size diff is 1036 byte(s).

update[10]:

oskar\arkanoid_3.tcx ponownie nadmiarowe dane na końcu:

Input file is arkanoid_3.cas.hex.raw and the file size is 12672 bytes.
TCX data loaded, checking data...

>>> Data encrypted! Trying to use calculated XOR key 0x19 <<<

Header is: $ffff
block 000: $2000-$2080 ($0081)
block 001: $02e0-$02e3 ($0004)
block 002: $4c00-$5000 ($0401)
block 003: $6500-$6f79 ($0a7a)
block 004: $2800-$318d ($098e)
block 005: $a800-$ab6a ($036b)
block 006: $aba0-$bbc5 ($1026)
block 007: $0480-$04d8 ($0059)
block 008: $0600-$0695 ($0096)
block 009: $2500-$2711 ($0212)
block 010: $5801-$5bb3 ($03b3)
block 011: $5c21-$5e5c ($023c)
block 012: $1919-$1919 ($0001)
^^^^^^^^^: Invalid block header detected! Processing stoped.

Input data processing done, 12 correct block(s) processed, generating output file...
Output file is arkanoid_3.cas.hex.raw.xex and the file size is 13633 bytes.
Processing done, output file written, IN/OUT file size diff is 961 byte(s).

Ostatnio edytowany przez seban (2020-05-16 16:17:34)

life is complex, it has both real and imaginary components.