zupełnie o tym zapomniałem...  ten cart tak ma... uruchamiając komputer z tym obrazem cart-a trzymaj klawisz OPTION (to wyłączy BASIC) ew. z poziomu BASIC-a napisz komendę "DOS", powinno przejść do KOS-a lub Microloader-a tyle że z włączonym BASIC-em.

Hej!

No wersja powinna być widoczna po uruchomieniu czy to micro-loadera czy to KOS-a, np:

Microloader w wersji 2.7 prezentuje się tak:

a KOS w wersji np. 2.0, tak:

A KOS w starszej wersji, np. tak:

EDIT: Możliwe też jest że w wersji cart-a którą masz nie ma informacji o wersjach, bo ktoś usunął te informacje.

no tak. ale w przypadku np. SuperPacker by Jiri, to dekompresor jest tylko raz osadzony (na początku pliku) a potem tylko małe segmenty znanych zawierające konf. dekompresora dla danego segmentu i segmenty init wywołujące procedurę dekompresującą. Pewnie tak samo jest w przypadku LZ4 i SuperPacker by TeBe, ale już w przypadku użycia EXO (o ile dobrze pamiętam) to dekompresor jest dołączany do każdego segmentu danych. I zapewne wynika to ze specyficznych wymagań exomizera, nie mówię że nie dało by się inaczej tego zrobić, ale pewnie tak było szybciej/prościej, etc. Trzeba by zapytać TeBe.

Dołączanie depackera do loadera, nie wydaje mi się dobrym pomysłem... uwiązujesz loader do konkretnych wersji programów kompresujących czy depackerów, etc. Coś się zmieni w LZ4 czy EXO i zaraz będzie problem że XBIOS w takiej to a takiej wersji nie odczytuje poprawnie plików przygotowanych przez LZ4 v.131321 bo musi być LZ4 v.131313 ... a do kompletu o ile dobrze zrozumiałem tworzysz "nowy" format pliku, niezgodny z AtariDOS binary file. Przecież żaden loader nie odczyta segmentu typu $xxxx-$0000, no chyba że ktoś będzie pisał dedykowany loader do tego typu plików.

No chyba że właśnie taki masz zamiar, tzn. przygotować taki hermetycznie zamknięty system/format pliku, który jeżeli zostanie zastosowany w danej produkcji, to uwiąże ją raz na zawsze do Twojego rozwiązania. Jeżeli takie ma być założenie, to możesz robić oczywiście co zechcesz i osoby decydujące się na Twoje rozwiązanie też będą świadome tego. Dla części osób będzie to wada, dla części osób zaleta. Tutaj zapewne będzie tyle opinii ilu użytkowników.

Niestety nie jestem osobą która będzie w tym przypadku będzie mogła zachować jakąś sensowną neutralność wypowiedzi i nie bardzo umiem tutaj stanąć po jakiejś stronie, bo sami jako Slight robiliśmy produkcje "cało dyskowe" w formacie "żadnym" i uwiązanym do loadera znajdującego się na dysku, czy mechanizmów w nim zaszytych. Oczywiście wtedy wydawało się nam że to jedynie słuszna droga... bo i można sobie robić co chcesz na dysku, czytać jak Ci się podoba... i ograniczyć wpływ czynników zewnętrznych, takich jak rodzaj DOS-a czy systemu z którego nasza produkcja zostanie uruchomiona. Wtedy wydawało nam się to sensownym rozwiązaniem, szczególne gdy działo się coś podczas wczytywania... człowiek nie musiał wnikać co się dzieje pod spodem i jakie figle spłata DOS pracujący niżej.... wszystko było w naszych rekach, nawet system operacyjny był wtedy dla nas złem. W tym samym okresie była też druga strona barykady, która nie przejmowała się ładowaniem z dyskietki poszczególnych efektów czy części... nie przejmowano się loaderem, tylko korzystano z dobrodziejstw systemu operacyjnego czy to SIO czy CIO, a nawet i DOS-a... ładowano wszystko do dodatkowej pamięci i już po załadowaniu całej binarki w odpowiednie miejsca daną produkcję czy program odpalało się tylko z RAM nie przejmując się również tym co siedziało nisko w pamięci.

Jeżeli takie demo czy produkcja było w formacie plikowym to załadować się to dało ze wszystkiego właściwie, jedyne ograniczenie było takie że o ile same efekty nie wymagały dodatkowej pamięci, to EXT RAM był wykorzystany jako swego rodzaju RAM DYSK, nie przeszkadzał już żaden OS czy kosmicznie wolne czasy dostępu do danych z dyskietki. Cześć ludzi posiadających wtedy jakieś stacje równoległe (np. Karin MAXI drive) czy HDD mogła takie produkcja ładować nawet spod DOS-a. Prędkość ładowania produkcji z takich urządzeń była nieporównywalnie wyższa.

Patrząc na produkcję z tamtych czasów, każdy robił jak chciał i jak mu było wygodniej. My jako Slight, mieliśmy jakiegoś świra na punkcie pamięci i chcieliśmy aby nasze produkcje dało się uruchomić na komputerze z 64KB RAM. Poza tym dodatkową pamięć wykorzystywaliśmy podczas tworzenia do innych celów (albo jako ramdysk, albo jako przestrzeń w której Freezer zapisywał aktualny stan maszyny). Np. kompilowaliśmy wszystko do RAM-u na "żywca" z pod QA. Przed uruchomieniem efektu (który niszczył całą pamięć, a więc samo źródło, DOS-a i wszystko co się dało jeszcze zadeptać ;] ) wykonywało się "save state" maszyny z poziomu freezer-a do EXT RAM. Po uruchomieniu i stwierdzeniu gdzie są błędy i co trzeba poprawić odzyskiwało się stan maszyny z punktu ostatniego "zamrożenia" i pisało się kod dalej. Takie rozwiązanie powodowało że 64KB pamięci podstawowej stało się dla nas jakby domyślnym środowiskiem w którym będą uruchamiane nasze produkcje.

Jak więc widzisz trudno mi ocenić Twoje rozwiązanie w dobie obecnych "trendów" panujących na scenie, bo purystą i świętoszkiem nie byłem i orałem cały RAM łącznie z OS-em czy DOS-em ;) Czy dziś patrząc na to wszystko zrobiłbym to inaczej... pewnie tak... ale wtedy pewnie nie powstałoby Bitter Reality czy Overmind w takim kształcie w jakim powstały. A że obecnie ciężko je uruchomić i są produkcjami które stwarzają problemy z uruchomieniem... bo trzeba użyć SIO2PC albo rzeczywistej dyskietki i stacji dysków, i do kompletu nie da się tego uruchomić z SIDE czy HDD, etc. takie są koszty postępu chyba... chociaż wydaje mi się że i ten problem jest trochę sztucznie wygenerowany przez nowo zaprojektowany hardware, w którym pominięto możliwość rozwiązania tej "niekompatybilności", tzn. sądzę że na rzecz tego że te 1% produkcji,które nie ruszą na tym sprzęcie po prostu zignorowano możliwość rozwiązania tego problemu.

Tyle że to to nie był jakiś skomplikowany problem do rozwiązania i zapewne jest już rozwiązany jest od "n" lat, przez różnych ludzi i zapewne nie tylko w mojej szufladzie. Ale sprzęt dziś projektuje się tak aby był tani i mało problematyczny w produkcji... bo po co dodatkowe gniazdo, wtyczka, czy kawałek kodu, który będzie rzadko wykorzystany :P Na rzecz pełnej zgodności z przeszłością w i celu zwiększenia prostoty i komfortu używania nowych urządzeń, zrezygnowano z ciągnięcia za sobą historycznego ogona w postaci SIO.

Jeżeli loader jest dobrze napisany i przetwarza dane strumieniowo, to takie ograniczenie nie ma prawa mieć  miejsca. Nie spotkałem loadera który nakładałby ograniczenia na ilość segmentów INIT. Wiele segmentów RUN nie ma sensu, bo ważny będzie tylko ostatni.

A dlaczego miałoby tak nie być? Przykładowym narzędziem umożliwiającym takie coś jest chociażby Super Packer Jiriego Bernaseka. Z dzisiejszych narzędzi to oczywiście Super Packer od TeBe.

Plik który udostępniłeś bez problemu wczytuje się i działa pod Altirra 3.10. Plik jest niestandardowy nie wiem czy w jakiś sposób "zabezpieczony" przed kopiowaniem i jest zabezpieczony przed kopiowaniem, dwa pierwsze bloki są standardowe i zawierają loader,  który uruchamia się po owych dwóch pierwszych rekordach i przejmuje dalsze ładowanie gry. Jedyne co musisz zrobić aby gra się poprawnie wczytała pod emulatorem to wyłączyć "CIO patch" dla "C:" i wczytywać to wszystko w rzeczywistym tempie :)

UPDATE: szybko rzuciłem okiem na loader, wychodzi na to że po pierwszych dwóch rekordach loader oczekuje określony stan na linii DATA_IN odczekuje chwile a potem przechodzi do ładowania rekord po rekordzie dalszej części pliku, który jest już zwykłym plikiem w formacie binarnym (Atari DOS).

jak skonwertuje się plik CAS który dołączyłeś na format A8CAS-HEX, to widać że po dwóch pierwszych rekordach jest krótki blok FSK, właściwie to zawiera on tylko pisk (być może jest to tylko sygnał SPACE nadany na DATA_OUT przed następnymi rekordami) ... kurczę blade... ja już chyba gdzieś ten kod widziałem (loadera) ... tylko nie mogę sobie przypomnieć gdzie... jak mnie "oświeci" to nie omieszkam poinformować ;-)

A8CAS-HEX
FUJI 
baud 00738
data 21021 55 55 fc 00 01 00 07 50 e4 a2 00 bd 00 04 9d 80 07 e8 10 f7 86 3d ad 0f d2 29 10 d0 f9 a9 06 8d 1c 02 ad 0f d2 29 10 f0 f9 ad 1c 02 d0 e8 20 9d 07 30 65 85 2c 20 9d 07 85 2d 25 2c c9 ff f0 ee 20 9d 07 85 2e 20 9d 07 85 2f a9 ae 8d e2 02 a9 07 8d e3 02 a5 2e c5 2c a5 2f e5 2d 90 10 20 9d 07 30 4e 88 91 2c e6 2c d0 ea e6 2d d0 e6 ad e2 02 c9 ae d0 07 ad e3 02 c9 07 f0 b2 a9 3c 8d 02 d3 20 92 04 ; standard record; length=132, checksum=04 OK
data 00268 55 55 fc 07 a9 34 8d 02 d3 a9 30 8d 1c 02 ad 1c 02 d0 fb f0 99 6c e2 02 a9 3c 8d 02 d3 6c e0 02 a4 3d cc 8a 02 90 03 4c 7a e4 b9 00 04 e6 3d a0 01 60 f3 36 54 6c 9a c1 04 71 76 b3 d5 13 8d af d7 f8 3d b7 d9 22 48 98 c1 f4 12 23 2d 39 53 61 75 89 8b 8d 8f 91 93 95 97 99 9b 9d 9f a1 a3 a5 a7 a9 ab ad af b1 b3 b5 b7 b9 94 94 00 70 70 70 42 40 bc 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 af ; standard record; length=132, checksum=af OK
fsk  00032 1584 ; length=1; duration=158 ms
data 00396 55 55 fc ff ff 2f 02 2f 02 00 ff ff 00 16 fb 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a9 20 8d 08 16 8d 09 16 8d 0a 16 8d 0b 16 a9 03 8d 0f d2 a9 00 8d 08 d2 60 a2 00 bd 00 16 d0 08 e8 e0 04 d0 f6 4c 72 16 a9 00 9d 10 16 bd 00 16 38 e9 01 0a 0a 0a 3e 10 16 0a 3e 10 16 0a 3e 10 16 0a 3e 10 16 18 69 b6 9d 0c 16 bd 10 16 69 16 9d 10 16 a9 00 9d 00 16 9d 08 16 4c 34 16 a2 9c ; standard record; length=132, checksum=9c OK
data 00367 55 55 fc 00 bd 08 16 c9 20 d0 06 e8 e0 04 d0 f4 60 bd 0c 16 85 c8 bd 10 16 85 c9 a0 00 8a 0a aa b1 c8 9d 00 d2 a0 20 b1 c8 9d 01 d2 8a 4a aa bd 0c 16 18 69 01 9d 0c 16 bd 10 16 69 00 9d 10 16 fe 08 16 4c 7b 16 14 1e 28 32 3c 46 50 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4f 4c 4a 48 46 44 42 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b4 ; standard record; length=132, checksum=b4 OK

@cobol: ... nie wszystko musi mieć sens i cel ;) jeżeli komuś takie coś przynosi radość i powoduje że powracają dawne wspomnienia.. to czemu nie? nawet jak to będzie zgrane coś co leży dawno w sieci... to sama chęć archiwizacji swoich dawnych zbiorów może być całkiem dobrym powodem. A może w zbiorach trafi się jakaś nietypowa/niespotykana wersja?

Hej!

Cały ten soft (przynajmniej wszystkie 3 które się uruchomiły) to oprogramowanie do tzw. "Blizzard Turbo".

Wygląda że to jest też jakaś wersja "klonowana". Widzę że część napisów jest usunięta, albo zastąpiona gwiazdkami.

tak powinien wyglądać oryginalny "Phoenix 1.0":

^^^ więcej o tym carcie w tym poście

drugi ekran w innym klonie wyglądał tak:

^^^ więcej o tym klonie w tym poście.

trzecie z ekranów który pokazałeś to też oprogramowanie to blizzarda, możesz odczytać wersje KOS i micro-loadera? Do tej pory trafiłem dwa takie klony w kolekcji uicr0bee, pisałem o nich również tu.

Jeżeli chodzi o przycisk RESET w carcie to działa on tak... uruchamiasz któryś z obrazów, wybierasz jakiś program czy loader... kod zawarty w cartridge odłącza go po przeniesieniu danego programu czy loadera do RAM... i gdybyś nie miał przycisku reset to ponowny start cartridge możliwy były tylko po wyłączeniu i ponownym włączeniu komputera. Jednak gdy naciśniesz przycisk RESET na carcie, a potem reset w komputerze to cartridge powinien się uruchomić ponownie. Bo to tak naprawdę nie jest reset komputera, tylko "reset" przerzutnika w cartridge.

I teraz jedna uwaga co do tego że w jednej pozycji masz self-test... teraz przyjrzałem się temu co masz carcie... "Phoenix 1.0 by Hurek" zajmuje 16KB. Dwa pozostałe carty po 8KB... więc wszystko by się zgadzało (32KB EPROM) ... teraz rozumiem po co te przeróbki na płytce drukowanej... to jest taki multi-cart "3 w 1". Tyle że ktoś kto wykonał sobie ten cart po najmniejszej linii oporu, czyli jedna z pozycji przełączników po prostu nie będzie działać poprawnie.

Dziś na warsztacie kolejny cart z serii "Blizzard", tym razem to cartridge "dwa w jednym", nazwany przez wykonawcę "Blizzard II", zapewne jest to jakiś klon lub giełdowy pirat, wskazują na to usunięte wszystkie informacje o firmie KNS, o której informacji znajdowały się w innych wersjach tego samego oprogramowania. Cartridge tak naprawdę zawiera w sobie dwa zestawy oprogramowania, wyboru oprogramowania które zostanie uruchomione dokonuje się przełącznikiem umieszczonym na obudowie cartridge-a.

Tak naprawdę catridge zawiera w swojej pamięci EPROM dwa niezależne cartridge, jeden zawiera starszy zestaw oprogramowania, czyli:

• Tubro KOS

• Micro Loader 2.2

• Tubro Blizzard Copy

• Tape Test

Skoro już dotarłem do prezentacji screen-shotów, to pozwolę sobie na małą dygresję i w związku z jednym ze screenshot-ów należą się dwa słowa wyjaśnienia... robiłem je używając emulatora Altirra w wersji 3.10 ... w tej wersji została dodana eksperymentalna obsługa systemów Turbo dla magnetofonu... sprawdziłem że emulacja działa bez problemu dla systemów z serii Turbo 2000(F) w różnych wersjach... wszystkie systemy które do odmierzania czasu impulsów używają procesora wydają się działać poprawnie.. jednak w przypadku Turbo Blizzard jest inaczej, ten system używa liczników zawartych w układzie POKEY do odmierzenia czasu i pomiaru długości impulsów... niestety pod emulatorem Altirra oprogramowanie systemu Blizzard nie działa poprawnie... a dlaczego nie działa poprawnie widać dokładnie na ostatnim zrzucie ekranu (z programu Tape Test) ... wychodzi na to że emulacja timerów POKEY-a lub czegoś z nimi związanego mocno szwankuje, sygnał pokazywany przez "Tape Test" ukazuje bardzo małą dokładność pomiaru, sygnał jest postrzępiony i niejednokrotnie przekracza wyznaczone granice dla poszczególnych długości impulsów (0,1 oraz SYNC). Oczywiście ten sam test uruchomiony na realnym sprzęcie daje bardzo spójne i precyzyjne odczyty. Wniosek... na chwilę obecną pod emulatorem Altirra 3.10 system Turbo Blizzard nie jest poprawnie obsługiwany.

Wracając do głównego tematu... drugi zestaw oprogramowania zawiera:

• Tubro KOS 2.0

• Micro Loader 2.7

• Short KOS 1.0

• Looking

Z tego zestawu programów również usunięto wszystkie informacje o autorstwie czy pochodzeniu programów (miejsca w których prawdopodobnie znajdowały się takie informacje zostały wypełnione spacjami). Wersję z informacjami o autorach/firmie jednego z sub-cartów umieszczonego w tym zestawie możemy znaleźć w tym poście o carcie: Turbo Blizzard. Jak widać w tamtej wersji widniały informacje o firmie KNS. A autor tego klona usunął informacje o autorach nawet z programu kopiującego. Wygląda na to że taka była rzeczywistość tamtych czasów... ale, ale... nie ma co dywagować, więc przechodząc już do konkretów:

1) Zawartość pamięci EPROM:

Blizzard2.bin.7z - obraz całego cartridge
Blizzard2_cart1.bin.7z - wyekstrahowany obraz zawierający oprogramowanie "Blizzard Cartridge"
Blizzard2_cart1.bin.7z - wyekstrahowany obraz zawierający oprogramowanie "Turbo Blizzard".

MD5   : adc47ce3c46d9c97ed4f3ab8c733c055
SHA256: 2faa7671b7a827b3027a22293cd9439f85a9de9fef1b1b053b05348fbf7429aa

blizzard2_cart1.bin:

MD5   : c6f1f0c5d9b1ec197c9af9f02e044454 
SHA256: ecce531f1463651f96e2361b5a67a831ff3b7d814c5028cc29394e9e9c4c2516

blizzard2_cart2.bin:

MD5   : 0920fce3b154368b4e5fcacb9ccda841
SHA256: 47d7c9a6f3f60e116b1f26cd014bb60af6fca4d6ecdebccf76e0d8deccd9a4ee

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: Blizzard2.xex.zip

Jak już wspominałem wcześniej, ten cart to tak naprawdę dwa niezależne karty, a wyporu uruchamianego "obrazu" dokonuje się w rzeczywistości przełącznikiem... robiąc wersję XEX należało zapewnić również możliwość wyboru uruchamianego softwareu, dodałem proste menu pozwalające taki wybór uczynić:

Wyboru dokonujemy klawiszem SELECT, a zatwierdzamy go klawiszem START. W przypadku oprogramowania z pozycji #1 menu, czyli "Blizzard II", jeżeli chcemy wyłączyć BASIC należy wraz z klawiszem START przytrzymać klawisz OPTION. To nie mój wymysł, lecz autorów oprogramowania :) klawisz OPTION jest sprawdzany przy starcie obrazu cartridge i na tej podstawie podejmowana jest decyzja czy BASIC zostanie włączony (dzieje się to niezależnie od systemu operacyjnego)

3)  Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).

Jest to standardowa konstrukcja tego typu carta, mapowany jest w obszarze $A000-$BFFF, z możliwością programowego odłączenia przez dowolne odwołanie (odczyt/zapis) do dowolnej komórki z przedziału $D500-$D5FF. Układ odłączenia zrealizowano na prostym przerzutniku RS, zbudowanym z bramek NAND. Dowolne odwołanie do $D5xx powoduje aktywność sygnały ~CCTL, a co za tym idzie wyzerowanie przerzutnika i ustawienie sygnału RD5 w stan 0, co przez system i sprzęt jest postrzegane jako odłączenie cartridge. Ponowne włączenie może nastąpić gdy użytkownik wciśnie przycisk RESET umieszczony w cartridge.

Cartridge zawiera przełącznik umożliwiający zmianę staniu linii A13, a co za tym idzie wybór jednej z połówek pamięci EPROM widocznej w obszarze $A000-$BFFF, co skutkuje wyborem jednego z dwóch 8KB obszarów mapowanych w przestrzeni adresowej Atari (Pamięć EPROM ma pojemność 16KB).

Dodatkowo w cartridge zawarto sprzętowy "układ zabezpieczenia antypirackiego". identyczny z tym umieszczonym w BIG 2.0 by KNS - Blizzard Cartridge. Przejrzałem kod obu zestawów oprogramowania i nie znalazłem fragmentów kodu sprawdzających to "zabezpieczanie". Zrobiłem to jednak dość pobieżnie nie przykładając się zbytnio... potem uruchomiłem kod na emulatorze z ustawioną pułapką (breakpoint) na odczyt z obszaru $D500-$D5FF, jednak takie odwołania nie nastąpiły. Aby mieć pewność że całość działa bez owego układu (a co za tym idzie np. czy wersja XEX będzie działać poprawnie), sprawdziłem całość na realnym hardware... udało mi się wczytać różne gry z każdego z loaderów, KOS-a, i short KOS-a. Przyznam że nie testowałem zapisu, ale tą część pozostawię już osobom zainteresowanym tematem.

Co prawda zastanawia mnie sens stosowania takiego zabezpieczenia, skoro piraci/handlarze/klonerzy kopiowali również układ "zabezpieczający", ale widać robili to dla "świętego spokoju". O ile w kodzie KNS BIG 2.0, można było znaleźć fragmenty sprawdzające obecność układu "zabezpieczającego" to tutaj ich nie widać... być może "piraci" je usunęli razem z napisami, a być może ich nie było wcale. Aby mieć pewność należałoby dokładnie przejrzeć cały kod, w szczególności ten który zawiera nowszą wersję KOS-a (2.0). Należy dodać iż ten KOS 2.0 może zainstalować również RAM-dysk wykorzystujący dodatkowe banki pamięci, jak i również pamięć od OS-em czy też w przypadku użycia BASIC-a pomięć RAM pod BASIC-em.

Ponieważ oryginalny dump (ten mający rozmiar 16KB) trudno w oczywisty sposób uruchomić pod emulatorem, przygotowałem dwa oddziele obrazy pozwalające uruchomić je pod emulatorem  wybierając jako typ cartridge "Phoenix 8K".

I na koniec prezentacja wyglądu owego cartridge:

płytka drukowana, góra:

płytka drukowana, spód:

EDIT: zauważyłem że na schemacie jest różnica w stosunku co do oryginalnego carta, tzn. zamiast oryginalnie zastosowanego 7403 (wyjścia open collector) oznaczyłem bramki jako 7400 (push-pull)... na szczęście w tym wypadku nie ma to większego znaczenia (układ wyprowadzeń ten sam) a w powyższej konfiguracji układ będzie działał zarówno z 7400 jak i 7403. Oczywiście "zabezpieczenie sprzętowe" też będzie działać, bo dioda 1N4148 będzie symulowała wyjście open-collector nawet w przypadku zastosowania 7400. Poprawię to oczywiście w wolnej chwili.

Pin, spakowane 7z nie z powodu chęci zaoszczędzenia miejsca, ale tylko i wyłącznie z tego powodu aby mieć pewność że sciągnięty plik jest poprawny (7z zapewnia integralność danych, a przynajmniej wiesz jeżeli coś się z archiwum spierniczyło po drodze). Ale ok wrzucę Ci na pigwę wersję .XEX.

Co do sparty... wytłumacz mi proszę jakie ty masz memlo? ;) program się ładuje od $2000, jakim cudem Ci to Spartę rozwala? Mogę go skompilować wyżej... ale też trzeba uważać bo przecież zaraz będziesz narzekał że jak bedzie ponad $a000 to trzeba będzie ładować przez /X czy coś bo tam też sparta... :) powiedz gdzie ma się ładować aby nie robiło "kuku" sprawcie.

i  Ty mówisz na poważnie, że takiego programu:

    $22C0 - $2572 : $02B3
RUN $2473

nie da się normalne załadować spod sparty? serio? ;)

Czy do tak prostej "popierduły" mam dołączyć relokator i relokować dynamicznie w zależności od memlo? czy może jednak
wystarczy ładować nieco wyżej aby Sparta mogła żyć spokojnie?

Jak mi napiszesz co mam zrobić aby zadowolić spartę, chętnie poprawie te $2b3 bajtów kodu ;P

EDIT: Pin, specjalnie dla Ciebie wersja 1.1, ładowana od $8000, i to w formie XEX: Video Latency Test v.1.1.xex

Dodatkowo po wciśnięciu ESC robi WARM START/RESET powinno wrócić do Sparty bez problemu? nie?

Jeszcze raz dzięki za tak rozbudowane informacje na temat konwertera i jego zachowania w różnych trybach pracy. A możesz podpowiedzieć którą dokładnie wersję do super video w swoim Atari posiadasz?

nie przesadzajmy z tą "płodnością"... to naprawdę nie zajęło dużo czasu i napisanie tego nie wymagało zbytniego wysiłku. Na tym forum są ludzie którzy kodują takie rzeczy że jestem przy nich totalnym cieniasem :)

W przypadku zdjęcia które zamieściłem, podłączenie było proste i oczywiste, a to tylko dlatego że komputer testowy miał na pokładzie VBXE... LG dostawał sygnał RGB z VBXE na swoje wejście EURO/SCART... natomiast CRT dostawał tylko sygnał luma (taki kabel miałem pod ręką).

A następne testy robiłem zupełnie niezgodnie ze sztuką ... powinienem był "na prędce" skleić chociaż jakiś wtórnik/bufor do sygnału wideo ale poszedłem na totalną łatwiznę... i zastanawiając się czy ryzykuję obciążyłem wyjście atari dwoma monitorami jednocześnie więc 75ohm impedancji zmieniło się w straszliwe 37ohm... ja się zastawiałem co na to powie Atari i jak długo wytrzyma :) ale radziło sobie dzielnie i efektem ubocznym był spadek amplitudy sygnału video co przełożyło się na delikatne zmniejszenie poziomu jasności...

... wiem, wiem... wypisuje herezje i postępuje krocząc ścieżką zmierzającą ku zagładzie ;P jednak nie zależało mi na jakości ani ostrości obrazu... wszystko miałem podłączone do jednej listwy zasilającej i nie miałem żadnych "ground loops" i prawdę mówiąc nie sądziłem że to zadziała dobrze, a jeżeli zadziała to spodziewałem się o wiele większej degradacji sygnału jednak zdziwiłem się tym co ujrzałem przy innych testach więc szybko przestałem się przejmować ;) naprawdę zwyciężyło lenistwo i nie chciało mi się nic lutować... więc zrobiłem kablową maskarę typu:

[monitor#1]-------\
                  |---------[CVBS signal]-----[Atari]
[monitor#2]-------/

potem się trochę ogarnąłem, i zrobiłem dwa wtórniki na szybkim op-ampie przeznaczonym do tego celu... jednak sądzę że można to wykonać również z dwóch tranzystorów. Teraz przyszedł mi do głowy jeszcze jeden pomysł, ale nie wiem czy zadziała... sprawdzę go i dam znać niebawem :)

I nikomu nie polecam takiego postępowania jakie zaprezentowałem wyżej, ja ryzykowałem na własną odpowiedzialność... ale to nie było mądre... tak naprawdę wystarczy że jakiś TV będzie miał jakiś nietypowy układ wejściowy czy jakąś składową stałą na wejściu video i mogą zacząć się problemy. nie powinno się tak postępować jak to uczyniłem, konsekwencje mogą być różne. Jak napisałem niebawem dam znać jak podłączyć dwa monitory jednocześnie bez większego ryzyka.

no właśnie taki rodzaj pomiaru daje wiele niewiadomych, dlaczego? postaram się pokazać to na przykładzie...

tutaj fota gdzie atari podłączono to taniego monitora LCD przez HDMI z użyciem konwertera który ma minimalne latency (właściwie kilka linii skaningowych)...

jak widać sam monitor przy przetwarzaniu sygnału z zewnątrz wnosi opóźnienie rzędu 2 klatek... ale ten model to taki low-cost all in one... tzn. ma również wejścia EURO/SCART, S-Video, Component, Composite Video. I co się stanie jak podłączymy Atari do tych wejść bezpośrednio?

wyszło na to że konwersja sygnału cvbs zajęła bebechom monitora kolejne dwie klatki, co byłoby dość logiczne, ponieważ konwerter zapewne czeka aż przyjdą do niego dwa kolejne pół-obrazy systemu PAL... po czym składa sobie jedną klatkę obrazu przy okazji robiąc masakrę z sygnału 240p który otrzymał od atari...

i dlatego pisałem wyżej że Twoja metoda pomiaru może (ale nie musi) dawać nieadekwatne testy...

ale dzięki Twojemu wspomnieniu o braku CRT... Kurdę chyba wpadłem na pewnie pomysł jak to zrobić bez CRT :D to ma szansę zadziałać, ale muszę to sprawdzić :)

Wracając na chwilę do tego nieszczęsnego mistrala jak pisałem ten monitor również (tak jak LG) robi istną kaszanę z sygnału 240p... tak będzie robić również większość TV, konwerterów, etc. (u Ciebie też chyba widać na zdjęciu że obraz z prawej strony jest nieprawidłowy i drży o jedną linię co ramkę (no chyba że czas "otwarcia migawki" za długi jest))

Muszę jednak dorobić jakiś test pokazujący/testujący nieprawidłowe przetwarzanie sygnałów 240p przez większość sprzętu obecnego na rynku.

Dlaczego wygłaszam tak pesymistyczną opinię... tylko dlatego że 240p nie jest żadnym standardem, a w stanach FCC zabroniło nadawania w tym formacie, żaden sprzęt studyjny nie wspiera tego formatu. 240p to właściwie "hack" który działał na analogowych TV/Monitorach (stąd też słynne scan-lines jako efekt uboczny).

Jedna uwaga co do elektroniki... zastosowanie fotorezystora jest w tym wypadku wydaje się niewłaściwe, średni czas reakcji fotorezystora jest za wolny do tego testu... noty katalogowe podają czas reakcji na poziomie aż 30ms... radziłbym zastosować fotodiodę lub fototranzystor, wtedy nie będziesz miał dodatkowego opóźnienia wnoszonego przez czas reakcji fotorezystora.

EDIT: jeszcze jedno jeżeli chodzi o pomiar czasu opóźnienia scalerów/graberów/scan-converterów względem CRT to stosuje się zazwyczaj metodologię polegającą na wyświetlaniu tego samego dynamicznego obrazu na dwóch monitorach równocześnie, tzn. CRT robi jako źródło referencyjne, LCD + konweter, up-scaler, etc. jest traktowany jako obiekt mierzony. Uruchamiasz soft testowy, np:

240p test suite <--- a dokładniej chodzi o lag-test z tego pakietu.

i robisz zdjęcie/kręcisz film obu monitorów jednocześnie,test wygląda np. tak: LCD input lag test with and without Framemeister

Myślę że nie jest jakimś dużym wyzwaniem napisanie takiego testu natywnie dla 8-bit Atari.