Hej!
Tak na szybko odpowiadając na to co napisałeś...
No widzę że wykonałeś kawał roboty! :) 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 :( 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 :/
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ł :P 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!!! :D
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 ;)
update[6]:
"other\whodares2_(pirat).tcx" ... jest tak jak pisałeś :) ktoś zrobił z tego totalny bezsens :) 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ć :)
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).
