Hej!

Trochę w tym wątku się zrobiło cicho bo walczę trochę z opornymi egzemplarzami albo takimi co mają "security by obscurity" zrobione... i to mnie już trochę zmęczyło, bo dużo bezsensownej roboty jest... zabezpieczania żadne sensowne w sumie, a tylko czas marnują aby zrobić z tego coś sensownie uruchamiającego się. No i dobrze że się zapytałeś bo potrzebowałem przerwy i postanowiłem przeszukać swoje zbiory... okazało się że znalazłem cart do Turbo2001! (nawet nie wiedziałem że takowy posiadam). Zatem zamiast przerabiać plik z pakietu Blukiego, zabrałem się za cart, szczególnie że jest prymitywny na maksa.

Prawdę mówiąc to wcześniej zabrałem się nawet za pełną disassemblację tej wersji którą udostępnił Bluki, właściwie po to aby porównać to z dokładnie Turbo2000F, ale przeanalizowanie i opisanie wszystkiego zajmie trochę więcej niż sądziłem... więc, zmieniłem plany prac i oto efekty pracy z dzisiejszego popołudnia i wieczora...

Sam cartridge to 4KB EPROM 2KB EPROM (w tym wypadku ruski klon typowego 2716) ... i tu ciekawostka... z manualnym odłączaniem, którego dokonuje się za pomocą przełącznika na obudowie! Nie ma nawet prymitywnego układu czasowego ;-) Co ciekawe płytka wygląda na taką na której taki układ był pierwotnie obecny, jednak ktoś usunął go wycinając kawałek płytki i montując wyłącznik i parę kabli. Zatem nie ględząc już dalej...

1) zawartość EPROM:

oryginał: Turbo 2001 v.2.1

wersja poprawiona: Turbo 2001 v.2.1 - auto CCTL OFF patch

wersja dla emulatora: Turbo 2001 v.2.1 - auto CCTL OFF patch (doubled to 4K for emulators)

Turbo2001_v2.1.bin:

MD5   : 6bf691ea1dd4f8384934647755a47e6a
SHA256: ee0f7288c79ecc8ff0f26a98fc9d90992c7a09faf78cce1584bf11c266121d28

Turbo2001_v2.1_auto_off_CCTL_patch.bin:

MD5   : d2ac392ee223e6910e176b12e1081736  
SHA256: a3a1938adf6f6386649af96bedd5ecb4b8bd276b41a402fd5709707d1b56fd51

Turbo2001_v2.1_auto_off_CCTL_patch_(doubled_4K_for_emu).bin:

MD5   : 63aa8fb93812f3ebf4b9c4dd52b005cd  
SHA256: 27a2c63de6611c77c5f5254ce07ac273cb67a6d30032bec49962b19528043c44

2) Wersja XEX -> nie robiłem, chyba nie jest potrzebna skoro jest w pakiecie u Blukiego?

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

Schematu nawet nie ma co komentować za bardzo, 2KB EPROM zawiera oprogramowanie Turbo2001. EPROM mapowany jest w obszar $A000-$BFFF. A ponieważ linie A11 i A12 nie są podłączona (EPROM ma 2K) to w obszarze $A000-$BFFF widać 4x to samo, tzn. $A000-$A7FF, $A800-$AFFF, $B000-$B7FF, $B800-$BFFF są swoimi kopiami.

Jeżeli ktoś chciałby ucywilizować trochę ten cart i zrobić nieco zmodyfikowaną płytkę (wzbogaconą chociażby o prosty układ RC) powinien wykonać sobie cart z opcją nr 2 widoczną na schemacie, tzn. układ opóźniający wyłączenie cartridge oparty o tranzystor i prosty układ RC.

A żeby zrobić to naprawdę jak należy, to polecam wykonanie carta odłączanego na drodze programowej (poprzez dowolne odwołanie do obszaru $D500-$D5FF).  Wtedy należy użyć wersji "Turbo2001_v2.1_auto_off_CCTL_patch" jako wsad do pamięci EPROM. Wersja ta zamiast czekać w nieskończoność na odłączenie karta dokonuje cyklicznych zapisów pod $D500 i gdy TRIG3 ($D013) przyjmie wartość "0", przechodzi sama dalej. Na schemacie układ działający z tą wersją jest narysowany jako opcja nr 3.

Obrazy BIN można uruchomić pod Altirrą. W pierwszym wypadku (Turbo2001_v2.1.bin) proszę wybrać cartridge 8K, a następnie gdy zobaczymy napis "wyłącz cartridge" z menu należy wybrać opcję "Deatach Cartridge" wcześniej oczywiście trzeba w opcjach wyłączyć "reset when changing cartridges".

W drugim wypadku [Turbo2001_v2.1_auto_off_CCTL_patch_(doubled_4K_for_emu)] należy wybrać jako typ cartridge "Blizzard 4K" i zignorować napis "wylacz cartridge", po chwili wszystko uruchomi się dalej samo. Musiałem powielić dwa razy obraz "Turbo2001_v2.1_auto_off_CCTL_patch.bin" ponieważ Altirra nie obsługuje poprawnie obrazów 2K z możliwością odłączenia na drodze programowej.

Przy okazji ... Altirra 3.10 ma chyba błąd w obsłudze cartów 4K (type 58), nawet jak cart jest podłączony to stan $D013 (TRIG3) jest równy 0, to chyba nie jest celowe działanie, wygląda mi po prostu na błąd.

U Uicr0Beeiego czeka wersja 2.2 tego carta (ciekawe czy są jakieś znaczące różnice), ale na chwilę obecną dopiero kończę walkę z aktualną partią cartów (elektroniczną dokumentacją, wersjami XEX, patchami, poprawkami i analizą kodu co ciekawszych przypadków). Wcześniej chciałem to wrzucić tak jak zostało to przeze mnie zgrane już jakiś czas temu, ale doszedłem do wniosku że należy zrobić to raz a porządnie... co prawda teraz żałuję że tyle to przeleżało bo dużo już zapomniałem i koniec końców niektóre rzeczy robię od nowa ;)

na sam koniec pozostało zaprezentować wygląda tego cart-a:

po otwarciu obudowy:

PCB góra:

PCB spód:

EDIT: Późnym wieczorem zdałem sobie sprawę że EPROM w tym cartridge to nie klon 2732 a 2716, a więc nie 4KB a 2KB... po podejrzeniu plików okazało się że wersje które udostępniłem w środku mają powielony dwukrotnie ten sam 2KB obraz. Po poprawkach jednak okazało się że wersja 2K z programowym odłączaniem nie jest poprawnie obsługiwana przez emulator, dlatego też pozostawiłem zdublowaną do 4K wersję z opisem ze działa ona pod emulatorem. Poprawiłem też schemat dorysowując możliwe opcje sterowania wyłączeniem carta i zmodyfikowałem treść posta, aby zamiast odsyłać do innych wątków wszystko było w jednym miejscu. Mam nadzieję że teraz wszystko będzie jasne. Wersję 1.0 schematu można wywalić (jeżeli ktoś zdążył ściągnąć), bo miała wrzucony zły typ pamięci EPROM (2732 zamiast 2716).

A i jeszcze jedna ciekawostka która wniknęła z tego zamieszania, na końcu obrazu cartridge ktoś zostawił swój podpis, widnieje tam mianowicie ciąg znaków "mod. ROBERTM". W wersji którą udostępnił Bluki tego ciągu nie ma.

Ale rzucę jeszcze okiem w tę wersję od Blukiego i dam znać czy to jest mniej więcej to samo i ew. jak sobie poradzić z zamianą na wersję cartridge czegoś takiego.... po pierwszym rzucie oka już mi słabo ;) ten plik wygląda na konwersję pliku BOOT (pewnie kasetowego, który oryginalnie ładował się gdzieś od $700) na plik Atari DOS binary file... użyto gotowego konwertera BOOT->XEX które nazwy już nie pomnę, ale już nie raz się na niego natknąłem (bo np. przepisuje kod po pamięci lokując swoje procedury m.in. od $3C0).

Wygląda na to że ten DOS formatuje dyskietkę w innym przeplocie sektorów niż oryginalna dyskietka. Więcej o przeplocie poczytasz chociażby tutaj.

Niestety DOS-a XL widziałem na oczy ze dwa razy... więc będę zgadywał... Stacja CA-2001 może pracować w trybie turbo Synchromesh. Może wystarczy z dyskietki załadować ten sterownik i potem wykonać kopię dyskietki? (albo wręcz przeciwnie... nie ładować sterownika (może jest ładowany domyślnie? nie pamiętam niestety) i sformatować dyskietkę w przeplocie standardowym?)

czyli przerwy nie ma, więc powinno być OK. Głowica jest uniwersalna, tzn. odczytująca-zapisująca, zmiany trybu pracy (odczyt/zapis) dokonuje switch "SW1" (schemat XC12 od JER-a)... ale skoro widziałeś na oscyloskopie sygnał zapisy to powinno być OK! no chyba że jakiś mega paproch Ci się przykleił na czoło głowy, próbowałeś jej czoło przetrzeć np. wacikiem, albo patyczkiem kosmetycznym nasączonym jakiś spirytusem/izopropanolem/denaturatem?

Z tego co mi przychodzi do głowy, to jeszcze jest możliwe że urwany jest jeden z przewodów od głowicy (np. ten masowy). Nie wiem gdzie miałeś podłączoną masę od oscyloskopu, ale jeżeli gdzieś do masy na PCB i dotykałeś tylko końcem sondy do jednego przewodów przy głowicy to mogłeś widzieć sygnał który faktycznie tam nie docierał bo. np. brakowało wspomnianej masy)

Druga z głowic jest odpowiedzialna za kasowanie i z tego co piszesz to wygląda na to że ona pracuje (z powodzeniem kasuje poprzedni zapis).

Problem może istnieć również w torze tej głowicy zapisująco/odczytującej. Zobacz czy na płytce są poprawnie wmontowane R6 i C3 i jakie mają wartości? może ktoś usuwając/zmieniając C4 (np. przy modyfikacji na turbo 2001) coś uszkodził w torze zapisu?

Masz dostęp do jakiegoś innego magnetofonu? (może być dowolny magnetofon kasetowy, cos typu deck/ mini wieża, etc.)

Ok! Wielkie Dzięki za walkę z cartem :) Dopytywałem się tak bo chciałem mieć pewność że Twój cart nie zawiera nic nowego ;) Jeżeli zawierałaby jakieś dodatkowe informacje lub inną wersję na pewno prosiłbym o wykonanie kopii/zrzutu zawartości.

Warto wyrwać z odmętów historii każdą wersję softu/carta/obrazu która się zachowała :) to w sumie nasza komputerowa historia :)

Jeszcze raz dziękuję za poświęcony czas na sprawdzenie wszystkiego! :)

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?