Przyznaję szczerze że ta gra od zawsze doprowadzała mnie do szewskiej pasji :) W czasach kiedy w tę grę próbowałem grać , przejście zaledwie kilku początkowych poziomów było dla mnie sukcesem ;) Ale nie wyobrażam sobie abym mógł próbować dotrzeć do poziomu 29 czy 30 ;) Chyba bym osiwiał :D

Jeżeli ktoś ma cierpliwość to może tą grę uruchomić nawet na emu i to na dwa sposoby:

1. Obraz z carta z bankowaniem Blizzard32K
2. wersja XEX

Na realnym sprzęcie również można uruchomić wersję XEX bez problemu, po czy gdy pojawi się:

Wciskamy klawisz OPTION i odpala się gra Nexuss.

Jeżeli ma ktoś cierpliwość, czas i ochotę aby to sprawdzić grając poziom po poziomie byłoby super... Ja mogę spróbować zrobić jakiegoś cheat-a do przechodzenia po poziomach (ale nie wiem czy coś nie jest wbudowane przez autora... coś mi się po głowie kołacze... ale nie pamiętam dobrze tego faktu... sprawdzę zatem!)

EDIT1: o kurde... u fandala jest jakaś wersja z pozmienianymi napisami :( jeszcze "filed by"... jakiś ktoś... ja miałem wersję identyczną z tą na carcie, tzn. w takim sensie że napisy były nie pozmieniane.

EDIT2: sprawdziłem wersję XEX, po 28 levelu który ma "?" jako układ bloków do rozbicia... następuje level 29 z dwoma rzędami klocków u góry, po czym odpala się level 30 i to jest już kaszana i śmiecie na ekranie. sprawdzę zatem oryginał na carcie. Sprawdziłem oryginał na carcie, odpalony na real sprzęcie. Gra zachowuje się dokładnie tak samo... sieczka na 30-levelu.

Czyżby autor założył że nikt nie dotrze tak daleko?

EDIT3: LOL... autor popełnił błąd w kodzie ;) zakładał że poziomów będzie 49... jednak poziomów w grze umieścił 29... poziom 30 faktycznie nie istnieje... po poprawce w kodzie gry po przejściu 29 poziomu... gra po prostu startuje od nowa tzn. od poziomu nr 1 :) nie ma żadnego zakończenia, nawet napisu "congratulations" :D

Hej!

Dzięki za drugi dump! Wygląda na to że ten się uruchamia! Sprawdzę go dokładniej wieczorem i dam znać czy nie znalazłem jakichś problemów.

Gdyby podczas testów okazało się że coś jeszcze nie działa lub zobaczę jakąś sieczkę w kodzie, to będę dawał znać i wtedy mogę zgrać karta u siebie... przy okazji mógłbym go doprowadzić do stanu działania :)

Czyli wychodzi na to że ten cart który mam opisany Turbo 2001 v.2.1 (którego zawartość udostępniłem wyżej) to znowu jakiś piracki klon? ;) ew. nie jest to wersja 2.1 jak głosi napis na obudowie carta... a jakaś inna wersja... niestety w zawartości carta nie ma żadnej dodatkowej informacji o wersji. W sumie to nawet dobrze że to klon/pirat, bo już myślałem że TOMS sprzedawał taką prowizorkę.

Byłoby super. Następny cart byłby zarchiwizowany.

Rzuciłem dokładniej okiem (bo wcześniej do deasemblacji to zgrałem sobie po prostu wynikowy kawałek pamięci zawierający turbo, czyli w tym wypadku $700-$EFF) ... i spokoju mi nie dawało że ten plik .xex jest czymś potratowany... no i okazało się że był w końcu mi sie przypomniało ... jest taki program "super copy" (zresztą jest też w paczce Blukiego) który możliwa konwersję BOOT<-->XEX ... właśnie tym softem został potraktowany plik boot i zamieniony na postać "Atari DOS binary file". Oryginalnie był to zatem program typu BOOT ładowany z kasety, nawet zachował się oryginalny nagłówek typu boot:

00 10 F8 06 1A 0E 18 60

^^^ a więc 16 rekordów ładowanych od adresu $6F8 do adresu (+16*128) czyli $EF7.

swoją drogą na końcu pliku widać:

0EE8: D0 F6 4C 3C 36 20 8F 3B 44 75 70 6C 69 63 61 74 |..L<6 .;Duplicat|

nie wiem skąd się wzięło to "Duplicat" ;-) tzn .mogę się domyślić iż wylądowało to tam zamiast 8 bajtów nagłówka cartridge, który formalnie w przypadku tego carta jest ulokowany pod adresami $BFF8-$BFFF.

Więc droga tego pliku udostępnionego przez Blukiego była taka: EPROM -> BOOT -> XEX :)

Patrząc jeszcze trochę na kod, widać że w miejscach w których w oryginalnym cartridge były procedury kopiujące obszar $B000-$B7FF na miejsce docelowe (czyli $700-$EFF) pojawiły się nowe procedury udające uruchomienie cartridge (np. ustawienie memtop na $A000, potem otwarcie ekranu, etc.). Dokonując porównania obu plików widać dokładnie, że zmian dokonano tylko w tej części odpowiedzialnej za start i uruchomienie:

Reszta pliku jest identyczna, tak więc to co jest na cartridge który posiadam jest dokładnie tym co było źródłem do powstania pliku BOOT/XEX udostępnionego przez Blukiego. Szkoda że autor tej konwersji (Cart --> BOOT) mieszał w oryginalnym obrazie carta... ja robiąc dumpy/loadery zawsze zachowuję plik w oryginalnej postaci... nawet w przypadku wersji XEX zachowuję strukturę oryginału, tak aby dało się ją wydobyć z pliku, ale widać czasy były takie że nikt nie myślał w kategoriach zachowania oryginału :) Na szczęście zachowały się oryginalne carty :) W przeciwnym wypadku trzeba byłoby "odkręcać" zmiany ręcznie, ale to już nie byłby oryginał :)

To chyba wyczerpuje temat Turbo 2001 na chwilę obecną? Zapewne wrócimy do niego jak dostanę w swoje ręce wersje 2.2 cartridge. No chyba że jeszcze ktoś ma jakieś pytanie/sugestie co do dalszych działań w tym temacie?

EDIT: zobaczyłem że w "paczce" softu od Blukiego jest jeszcze jeden plik opisany jako "Turbo 2001C":

Sprawdziłem i okazało się że jedyna różnica to zastąpienie napisu "Wylacz Cartridge" napisem "TURBO 2001 v. 2.1C":

Edited on 2025.08.18: Updated HTTP links to HTTPS to avoid mixed content issues.

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.