@sun: no ja mam dokładnie takie same spostrzeżenia, jak jest RetroTink 2x i ma się monitor/tv z wejściem HDMI to nic innego obecnie nie ma sensu :) Reszta to są tylko półśrodki. Nie udało mi się uzyskać lepszej jakości na niczym innym, mówimy oczywiście o sensownym zakresie cenowym (pomijam OSSC czy XRGB-mini Framemeister ze względu na cenę).

I teraz czas na moje przemyślenia i podsumowanie końcowe współpracy RetroTink 2x z Atari 800XL w wersji NTSC.

Po pierwsze wyprułem prawie cały ten koszmarny tor video z 800XL:

Czy naprawdę 800XL w NTSC miało fabrycznie tak fatalnej wyjście video? jeżeli tak to jest jakieś totalne nieporozumienie. Po pozbyciu się modulatora (nie wyprułem go fizycznie z PCB, a tylko odłączyłem sygnały do idące, co widać na zdjęciu), rozdzieleniu obwodów chroma/luma, odfiltrowaniu zasilania dla obwodów video udało się uzyskać akceptowalnej jakości obraz s-video. Co prawda nie ma już w gnieździe monitorowym sygnału composite video, ale zupełnie mi na nim nie zależy, bo z założenia jest on gorszej jakości.

I teraz po podłączeniu tego w następujący sposób:

Atari 800XL NTSC [S-Video] ---> RetroTink 2x ---> [HDMI to VGA] ---> [Dell 4:3], obraz wygląda obecnie tak:

po pozbyciu się przejściówki HDMI--->VGA i podpięciu do BenQ via HDMI obraz wygląda tak:

I teraz jeden wniosek końcowy, obraz na BenQ wyglądał lepiej... wygląda na to że konwerter HDMI/VGA albo "scaler" w monitorze po otrzymaniu takiego sygnału zupełnie zmienia proporcje pikseli, jakby dokonywał jakiegoś skalowania/interpolacji, piksele tracą proporcje i wyglądają nierówno. Auto-Adjust wywołane z menu monitora nie potrafi dobrze sobie z tym poradzić, w dodatku co pisałem wcześniej obraz jest przesunięty mocno w prawo (widać dużo czarnego z lewej, tak że prawy koniec ledwie się mieści na monitorze)

Moim zdaniem stosowanie RetroTink 2x z przejściówką HDMI/VGA mija się totalnie z celem, tracimy po prostu jakość obrazu którą może dać RetroTink 2x. No i taki zabieg działa jedyne w przypadku gdy mamy Atari pracujące w NTSC (odświeżanie 60Hz), w przypadku PAL i monitora VGA który nie potrafi wyświetlać 50Hz (większość nie potrafi) nie uzyskamy obrazu.

@MADRAFi... zatem wydaje mi się że w Twoim wypadku (bez zmiany monitora) na taki z wejściem HDMI, cała inwestycja w RetroTink 2x nie ma najmniejszego sensu, bo nie po to się kupuje nie tak tani znowu scan-doubler aby potem iść na kompromisy i "osyfiać" obraz przejściówką HDMI--->VGA. Co prawda wygląda na to że ktoś dokonał przeróbek w Twoim 800XL że masz już sygnał S-Video w gnieździe monitora, pytanie tylko jakiej jest on jakości, bo widzę że masz również obecny sygnał Composite Video (przejściówka composite--->VGA) więc obraz S-Video będzie gorszej jakości z powodu miksowania chrominancji/luminancji w bebechach Atari. Ja się pozbyłem zupełnie i modulatora i elementów które łączyły w jakikolwiek sposób tory luminancji i chrominancji. Dałoby się jeszcze więcej pewnie wyciągnąć ale nie mam już za bardzo czasu ani chęci aby z tym Atari dalej walczyć.

EDIT: Może sprawdziłby się u Ciebie jakiś konwerter który ma wejście S-Video a nie tylko CVBS (Composite Video) jak to jest w obecnej przejściówce?

ps) zdjęcia są czysto poglądowe, trudno było mi telefonem wykonać je tak aby pokazywały rzeczywistą jakość obrazu. Można odnieść nawet wrażenie że obraz z BenQ jest gorszy, ale w rzeczywistości był bardziej wyrazisty, pixele były proporcjonalne i nie było widać żadnego koślawego skalowania.

@sun: ja rozumiem... ale z 800XL problem jest taki że ona fabrycznie nie ma s-video. Jest tylko "composite video: a.k.a CVBS... w dodatku generowany przez 800XL sygnał CVBS jest podłej jakości. Dlatego chcę w tej NTSC-owej 800XL wykonać S-Video mod aby w niej mieć też sygnał S-Video.

A wszystko wyszło przy okazji testów które obiecałem zrobić dla MADRAFi ;)

EDIT: Sun, tak patrzę na zachowanie się tego monitora samsung po S-Video i zauważam duże podobieństwo zachowanie tego monitora do tego co robił mój LG M228WA, próbowałeś tego rozwiązania: To High Chroma Level. A że działa z RetroTink 2x, ma jak najbardziej szansę, ponieważ układ zastosowany w Retro Tink 2x do próbkowania sygnału video ma wbudowaną "automatyczną regulację wzmocnienia", więc dostosuje się niestandardowych poziomów chrominancji. No ale teraz gdy masz RetroTink 2x to zabawa się w inne kable, etc. chyba już nie ma sensu :)

Zacznijmy może od typu monitora z którym wykonałem test, monitor to naprawdę wiekowy DELL 1907FPVt:

Dodajmy na wstępie że monitor nie potrafi wyświetlać nic o "refresh rate" mniejszym niż 60Hz.

Pierwszy test czyli kabel HDMI ---> DVI, niestety tak jak myślałem monitor nie potrafi zrozumieć strumienia danych "w formacie" HDMI. Retro Tink 2x generuje tylko taki stream i nie potrafi się przełączyć na ramki DVI tak jak to czynią np. zwykłe karty graficzne do Peceta, efekt jest taki że po podłączeniu RetroTink 2x i włączeniu jego zasilania monitor długo "myśli" po czym na ułamek sekundy pokazuje napis:

2: Digital Input
Cannot Display This Video Mode
Optimal Resolution 1280x1024 60Hz

... po czym przez długi czas widać jedynie czarny ekran i znowu na ułamek sekundy pojawia się to co wyżej.

Teraz opcja nr 2 czyli RetroTink 2x + przejściówka HDMI ---> VGA, po włączeniu zasilania efekty są obiecujące bo widać "ekran powitalny" retro tink 2x:

Niestety po podłączeniu Atari które pracuje w PAL monitor się poddaje:

wygrzebałem tą 800XL pracującą w NTSC, niestety ona ma tylko wyjście composite video (nie ma w gnieździe sygnałów luminancji i chrominancji, czyli brak s-video) obraz nie jest zbyt rewelacyjny:

^^^ w dodatku po "auto-adjust" monitor upiera się aby pokazywać dużo prawej czarnej ramki i mało lewej strony. Można kręcić sobie pixel-clock i phase-adjust ręcznie, a to tylko pogarsza jakość obrazu. Być może to wina taniej chińskiej przejściówki HDMI ---> VGA, która nie do końca sobie radzi z sygnałem generowanym przez Retro Tink 2x.

dla porównania zdjęcia z monitora BenQ GL2440 (RetroTink podłączone via HDMI) tych dwóch Atari które podłączałem:

NTSC Composite Video:

PAL S-Video:

Jak widać różnica w jakości jest kolosalna, NTSC via composite video to po prostu porażka. W przypadku NTSC może być też tak że miałem fatalnej jakości kabel "composite" jakaś słabo ekranowana chińszczyzna, ale PAL composite-video tak źle na mim nie wyglądał, więc albo coś z tym moim Atari w NTSC jest nie tak, albo nie wiem co. Będzie trzeba dodać super-video mod do tej NTSC-owej atarki i sprawdzenie tego ponownie, ale to przy jakiejś okazji.

EDIT: Otworzyłem tą Atari 800XL w NTSC... jest strasznie "podłubana" doprowadzę do porządku, zrobię S-Video Mod, odłączę modulator i zrobię jeszcze raz test jakości obrazu RetroTink 2x via S-Video. Ale to potrwa, muszę się zająć innymi sprawami.
Gdy kupię i dotrze do mnie Retro Tink 2xRGB to nie omieszkam zamieścić testów/zdjęć na forum.

A widzisz, teraz jasne... mi na tej samej zasadzie udało mi się zdobyć za naprawdę niewielkie pieniądze z pomocą przyjaciół zza oceanu DVI2PCIe. Oczywiście gołą używkę, bez kabli, bez dodatkowych modułów, tylko gołą kartę, w sumie to ryzykowałem bo myślałem że będzie uszkodzona (opis mówił że "nie testowana" wyjęta z komputera)... no ale się udało, karta okazała się sprawna. Tylko używałem jej do innych celów niż grabowanie obrazu z JIL.

Ten monitor ma tylko wejścia VGA i DVI, jedyne pocieszenie w tym że Twoje Atari to wersja NTSC więc video refresh rate jest 60Hz,  więc albo pozostaje Ci używanie chińskich scan-doublerów które mają wejście RGB, wątek o nich był np. tu: Chińskie scandoublery. Albo faktycznie czekanie na produkt od Lotharka (tylko należy się dopytać czy wspiera on NTSC).

EDIT: przypomniało mi się... kiedyś miał chyba być/był? opracowany rdzeń dla VBXE który generował na wyjściu obraz z H-Sync 31KHz zamiast 15KHz, więc teoretycznie przy użyciu takiego rdzenia plus jakiś sync-separator (LM1881) ew, bez niego o ile monitor potrafiłby łyknąć composite-sync na wejściu H-Sync dałoby się uzyskać obraz na monitorze VGA... z tym że chyba pomysł na rozwój tego rdzenia został porzucony (brak wolnych zasobów w FPGA, czasu, zainteresowanych), ale to trzeba by się dopytać Electrona albo Candle o szczegóły bo ja mogę źle pamiętać, ew. po prostu bredzić :P

cholera... mało czasu mam na wszystko, ale...

To nie taka abstrakcja, bo dawno, dawno temu... zrobiłem coś takiego... wziąłem małego Z8 (nie z80 a mały mikro-kontroler od Ziloga Z8 właśnie). Wpakowałem go do magnetofonu. Po włączeniu komputera jak tylko magnetofon dostawał zasilanie układ przechodził w stan "emulacji" stacji dysków. Umożliwiało to zbootowanie się komputera i uruchomienie obrazu systemu turbo zawartego jako obraz we flashu Z8. Wcześniej też taki eksperyment przeprowadziłem  użyciem PIC16 (jeszcze serii C - nie było wtedy "flaszek") oraz małej zew. pamięci szeregowej EEPROM w której był umieszczony obraz systemu Turbo. Po zbootowaniu się tegoż MCU wyłączał się i stawał się nieobecny do czasu następnego reboot-a albo do wciśnięcia reset na płytce z MCU.

Uznałem to jednak kiedyś za fanaberię, bo w czasach kiedy to robiłem koszt MCU przewyższał koszt zrobienia cartridge, więc nawet tego nie publikowałem :) Ale jeżeli to kogoś zainteresuje, to odgrzebię i opublikuję. Źródła mogły chyba przetrwać, bo były nagrane jeszcze na Philips CDD2000 i płytach CD po 30zł za sztukę :D

Ale w pierwszej kolejności muszę w końcu zacząć wrzucać to co było w magnetofonach od uicr0bee.

Hej!

W tej paczce ze stuffem do Turbo2000 którą kiedyś udostępniłem, a do której linkował QTZ jest coś takiego jak "generator kasety systemowej", chyba się już gdzieś wypowiadałem o genezie powstania tego softu, niemniej jednak teraz to co istotne: tymże generatorem można wygenerować kasetowy plik boot, który załaduje dołączony do niego system turbo 2000F.

Tu masz już gotowego CAS-a zawierającego ładowany w standardzie system 2000F: SYSTEM 2000F - bootable.

Przy ładowaniu i po załadowaniu powinno to wyglądać tak:

do podobnych wniosków doszedłem, tylko + level shifter bo CPLD jest 3.3V.

Hej!

No właśnie niestety nie, wprost przeciwnie seria HCT czy ACT to nowe scalaki wykonane w technologii HCMOS, więc problem z diodami jak najbardziej występuje. To co Jer i ja pisaliśmy o serii TTL dotyczyło układów wykonanych w technologii bipolarnej:

Hej!

Voy dzięki WIELKIE za te linki! :) kawał naprawdę ciekawego materiału! Video Cartridge jest dla mnie podwójnie ciekawy, a to dlatego że kiedyś właśnie zapatrzony na Amigowy Video Backup System zrobiłem sobie coś podobnego do Atari! Widzę że ludzie na drugim końcu świata mieli te same pomysły i to znacznie wcześniej :) Ja wymiękłem na korekcji danych, uparłem się że zrobię jak amigowcy kod korekcyjny "Reed–Solomon", ale nie dałem rady z wydajnością w sensownym czasie, po pewnym czasie dodałem dodatkowy MCU w carcie, ale piętrzące się problemy i brak czasu ubił praktycznie projekt. Kiedyś to odgrzebię i opublikuję (tylko doba za krótka ;/ i za dużo spraw na głowie), chociaż jak patrzę że ktoś to  jednak zrobił to jest to dla mnie super wiadomość! :) Jednak się dało, jedynie wtedy byłem za "cienki w uszach", albo przyjąłem zbyt wygórowane założenia :)

Rzuciłem bardzo szybko okiem na ten Video Cartridge, zachwyca mnie prostota rozwiązań :) Już na pierwszy rzut oka widzę że moje rozwiązanie było po prostu przekombinowane :D

A i owemu "Injecktor-owi" będę musiał się przyjrzeć również! :)

A teraz zmieniając nieco temat, aby nie mnożyć postów, we wcześniejszym poście dotyczącym plików Turbo Copy 3/4 odpowiedziałem i skomentowałem na boje kolegi QTZ w plikami zapisanymi przez Turbo Copy, dostępnymi w cas-archive od Strykera. Przy okazji wrzuciłem aktualną wersję TCX-Tools na GitHUB-a.

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.

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

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

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]:

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

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)