1,026

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

rzuciłem okiem na twój eidolon hex... no to na pewno nie jest poprawna konwersja niestety, normalnie jest tam 37 albo 38 bloków danych, w Twojej wersji tych bloków występuje chyba 421... tzn. a8cas-util.pl nie bardzo radzi z konwersją nagrań o mizernej jakości, w dodatku bardzo chętnie konwertuje takie pliki pisząc ze wszystko jest OK, tak jak wspominałem wcześniej sprzyja ku temu sposób wyznaczania sumy kontrolnej bloku (XOR) a w dodatku chyba konwerter nie oczekuje tonu synchronizującego o minimalnej długośći przed rozpoczęciem danego bloku danych i ochoczo dzieli wszystko na bloki o mniejszej długości (co jest zachowaniem niepoprawnym).

ace.hex wygląda lepiej a nie przyglądałem mu się zbyt długo, zostawię sobie to na później. Spróbuje też ponownie siąść do tego "the eidolon", ale przydał by się lepszej jakości dump (w sensie zgrany z lepszym ustawieniem głowicy). Ja do takich akcji używam starego prymitywnego decka w którym nie szkoda mi kręcić głowicą jeżeli wiem że źródłowa taśma była nagrana z innym skosem niż "fabryczny".

Coś mi się chyba przypomina że gdzieś wcześniej wrzucałeś pliki tego "the eidolon" w formacie UM? czy się mylę i pamięć płata mi figle?

1,027

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Wrzucałem pliki w UM Eidolon - ale jak pamiętam, tam też ostatni level był chyba skopany - ucięty. Jest to pewnie ta sama wersja gry - bo Panowie z Łodzi na bank korzystali z kopii w AST.
Dorzucam efekt Twoich prac z tej wersji w UM.
A do katalogu z 31 zestawem - wrzucam jeszcze raz stronę A - w nazwie ma info, że jest wzmocniona. Może z niej uda się to chwycić.

ps. Ace of Aces w AST też obrabiałeś - a to oznacza, że w sumie chyba wystarczy do tej wersji z 4 zestawu studia Empex - dokleić na początek loader AST Ajka pod T2000.

Seban - jeszcze jedno znalazłem kiedyś w sieci archiwum wav'ow w T2000 chyba czeskim i tam jest plik WAV gry Eidolon
dorzuciłem go do katalogu

https://drive.google.com/drive/folders/ … sp=sharing

I jeszcze jedno - widzę, że przy odpowiednim loaderze - te czeskie pliki WAV bardzo fajnie mi się ładują. Czy masz w swoich zbiorach Seban jakiś dobry soft do kopiowania z turbo/dysk dla czeskiego T2000? Znalazłem jeden program Rastera w magazynie Flop, ale on ma bardzo mały buffor.

Ostatnio edytowany przez Piguła/Shpoon (2023-10-30 21:42:00)

Post's attachments

The Eidolon (by UM, broken after level 7).hex 318.25 kb, liczba pobrań: 5 (od 2023-10-29) 

Tylko zalogowani mogą pobierać załączniki.
Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,028

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Piguła/Shpoon napisał/a:

I jeszcze jedno - widzę, że przy odpowiednim loaderze - te czeskie pliki WAV bardzo fajnie mi się ładują. Czy masz w swoich zbiorach Seban jakiś dobry soft do kopiowania z turbo/dysk dla czeskiego T2000? Znalazłem jeden program Rastera w magazynie Flop, ale on ma bardzo mały buffor.

Do konwersji plików Turbo 2000 (czeskie) w kierunku Tape --> Disk  można użyć TCONVERT autorstwa Vladimira Tichy'ego.
http://sdq.czweb.org/old_computers/atar … index.html

1,029

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Dzięki Baktraa - pobawię się i zobaczę jak się tego softu używa :)

Dorzucam jeszcze zestaw 20 studia Sparky
Stronę A pomijam, ponieważ jakiś czas temu dla QTZ'a Seban zajął się pozycją Winter Olympiad 88 i udostępnił w wątku pięknie opracowane pliki CAS wraz z loaderem dla T2001 oraz T2000f. Strona B zestawu przetworzona już przeze mnie.

Update 6.11.2023
Lexx walczył i udało się jednak zdekodować poprawnie te 4 felerne pozycje. Dlatego zaktualizowałem zawartość katalogu na dysku googla. I jest tam już cała strona B z wersjami, które na tym zestawie się znajdowały!!!!

https://drive.google.com/drive/folders/ … sp=sharing

Ostatnio edytowany przez Piguła/Shpoon (2023-11-06 15:35:26)

Post's attachments

Trzy_brakujace_casy_inne_wersje.zip 133.67 kb, liczba pobrań: 2 (od 2023-11-02) 

turbo_2000_okladka_sparky_zestaw20.pdf 830.91 kb, liczba pobrań: 8 (od 2023-11-02) 

Zestaw20_strona B.zip 248.02 kb, liczba pobrań: 2 (od 2023-11-02) 

Tylko zalogowani mogą pobierać załączniki.
Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,030

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Oraz jako kolejny bonusik Zestaw 26 studia Spark. Ten zestaw nie pokrywa mi się z zestawem o takim numerze, który w tym wątku opublilkował Seban. Ponieważ  kaseta zawiera oryginalną wlepkę Studia... obstawiam, że to jest prawidłowa wersja. A Seban zrobił dump zupełnie innego zestawu...

https://drive.google.com/drive/folders/ … sp=sharing

Ostatnio edytowany przez Piguła/Shpoon (2023-11-02 13:06:55)

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,031

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Jeszcze jedna kopiarka do czeskiego Turbo 2000. COPY T/H. Ten działa tylko w emulacji.
https://github.com/baktragh/bkcopyth

1,032

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Dzień dobry!

W dniu dzisiejszym pozwolę sobie powrócić do tematu “The Eidolon”, a powodem do powrotu do tego tematu były ostatnie posty szanownego kolegi Piguły, w których walczył on z kolejnymi taśmami przybyłymi z przeszłości i napotkał on na nich obraz tejże gry, tym razem wersji przeznaczonej dla systemu KSO Turbo 2000, a więc wersji turbo bazującej na transmisji danych z wykorzystaniem interfejsu podłączanego do drugiego portu joysticka.

Tę wersję opracował niejaki “*AJEK”, bazując na wersji zrobionej przez ludzi z “Unerring Masters”, dla która to zaistniała wcześniej na tym forum jako nagranie znajdujące się za zestawie nr. 4 firmy Empex z Łodzi. Podczas prób odtworzenia tamtej wersji okazało się że co prawda udało się poprawnie zdekodować nagrania, ale niestety okazało się również że tamtej wersji brakuje plików z poziomu ósmego gry, zatem mimo usilnych prób przywrócenia tej pozycji wszystkie wysiłki rozbiły się o brak końcowych fragmentów nagrania.

Gdy teraz okazało się że pojawiła się inna wersja tejże pozycji, tym razem przygotowana przez *AJKA pojawiła się nadzieja że tym razem uda się odtworzyć całość! Tym bardziej że wersja *AJKOWA bazowała na wersji od “Unerring Masters”.  Usiadłem więc do roboty i podjąłem kilka prób konwersji nagrań dostarczonych przez Pigułę… niestety część bloków na taśmie okazała się uszkodzona w sposób uniemożliwiający poprawne odtworzenie wszystkich uszkodzonych bloków. Siedząc i analizując rekordy, zastępując część z nich (tych w których sygnał zanikał do takich poziomów które uniemożliwiały dekodowanie) “połatałem” i poskładałem to w całość.

Przyszedł zatem czas na końcowe testy i nie przypuszczając jeszcze co mnie czeka, zabrałem się ochoczo do testów… po dłuższej chwili zabaw we wczytywanie kolejnych poziomów dotarło do mnie że *AJKOWA wersja jest również niekompletna i zabawa kończy się na poziomie szóstym! Normalnie się zagotowałem… tyle walki na nic? Mogę dokleić co prawda brakujące bloki z wersji “UM”, ale i tak będzie brakowało końcowych plików! Myślałem że przysłowiowy szlag mnie trafi… tyle walki i roboty na nic? Prawie pogodziłem się porażką i pomyślałem że opiszę sprawę na forum i być może za jakiś czas ktoś znajdzie kasetę w pełną wersją tejże gry zawierającej wszystkie pliki i jakimś cudem udostępni jej zawartość.

Zacząłem się zastanawiać jakie jednak są szanse na taki obrót sytuacji, stwierdziłem że dość niewielkie. Spokoju jednak mi to nie dawało bo ta wersja gry sygnowana przez “Unerring Masters”, była wersją która nie wymagała żadnej dodatkowej pamięci, a do jej wczytania wystarczało jedynie 64kB RAM. Zacząłem się zastanawiać jak wygląda wersja dyskowa tejże gry i czy nie dałoby się wyłuskać z niej brakujących plików i wygenerować je w formacie których oczekuje loader. Za długo nie myśląc, gdy tylko znalazłem chwilę wolnego czasu zacząłem analizować zawartość obrazu dyskietki z grą. Zastanawiałem się czy gra używa jakichś wyrafinowanych struktur jeżeli chodzi przechowywanie danych poszczególnych poziomów gry.

Jakież było moje zdziwienie gdy przeglądając hex-edytorem zawartość pliku .ATR z obrazem gry natrafiłem na prawie normalne wpisy w miejscu gdzie powinien się znajdować katalog dysku w formacie DOS 2.0:


xxd -g1 -seek 0xb410 -l 0x280 "Eidolon, The v1.1 (1985)(Epyx)(US).atr"
0000b410: 60 01 00 01 00 20 20 20 20 54 68 65 20 20 20 20  `....    The    
0000b420: 60 02 00 02 00 20 20 45 69 64 6f 6c 6f 6e 20 20  `....  Eidolon  
0000b430: 60 03 00 03 00 76 65 72 73 69 6f 6e 20 31 2e 31  `....version 1.1
0000b440: 60 04 00 04 00 20 43 6f 70 79 72 69 67 68 74 20  `.... Copyright
0000b450: 60 05 00 05 00 20 20 20 31 39 38 35 20 20 20 20  `....   1985    
0000b460: 60 06 00 06 00 20 4c 75 63 61 73 66 69 6c 6d 20  `.... Lucasfilm
0000b470: 60 07 00 07 00 20 4c 74 64 2e 20 35 30 39 31 39  `.... Ltd. 50919
0000b480: 00 43 61 76 65 61 74 20 50 65 69 72 61 6e 21 21  .Caveat Peiran!!
0000b490: 42 0b 00 d7 00 50 41 4e 45 4c 20 20 20 53 43 52  B....PANEL   SCR
0000b4a0: 42 09 00 e2 00 54 49 54 4c 45 20 20 20 53 43 52  B....TITLE   SCR
0000b4b0: 42 03 00 eb 00 4c 45 56 45 4c 31 20 20 4d 41 50  B....LEVEL1  MAP
0000b4c0: 42 03 00 ee 00 4c 45 56 45 4c 32 20 20 4d 41 50  B....LEVEL2  MAP
0000b4d0: 42 03 00 f1 00 4c 45 56 45 4c 33 20 20 4d 41 50  B....LEVEL3  MAP
0000b4e0: 42 03 00 f4 00 4c 45 56 45 4c 34 20 20 4d 41 50  B....LEVEL4  MAP
0000b4f0: 42 03 00 f7 00 4c 45 56 45 4c 35 20 20 4d 41 50  B....LEVEL5  MAP
0000b500: 42 03 00 fa 00 4c 45 56 45 4c 36 20 20 4d 41 50  B....LEVEL6  MAP
0000b510: 42 03 00 fd 00 4c 45 56 45 4c 37 20 20 4d 41 50  B....LEVEL7  MAP
0000b520: 42 03 00 00 01 4c 45 56 45 4c 38 20 20 4d 41 50  B....LEVEL8  MAP
0000b530: 42 11 00 03 01 44 52 41 47 4f 4e 31 20 43 45 4c  B....DRAGON1 CEL
0000b540: 42 1a 00 14 01 44 52 41 47 4f 4e 32 20 43 45 4c  B....DRAGON2 CEL
0000b550: 42 14 00 2e 01 44 52 41 47 4f 4e 33 20 43 45 4c  B....DRAGON3 CEL
0000b560: 42 1c 00 42 01 44 52 41 47 4f 4e 34 20 43 45 4c  B..B.DRAGON4 CEL
0000b570: 42 1b 00 5e 01 44 52 41 47 4f 4e 35 20 43 45 4c  B..^.DRAGON5 CEL
0000b580: 42 19 00 82 01 44 52 41 47 4f 4e 36 20 43 45 4c  B....DRAGON6 CEL
0000b590: 42 14 00 9b 01 44 52 41 47 4f 4e 37 20 43 45 4c  B....DRAGON7 CEL
0000b5a0: 42 1e 00 af 01 44 52 41 47 4f 4e 38 20 43 45 4c  B....DRAGON8 CEL
0000b5b0: 42 0f 00 cd 01 44 52 41 47 4f 4e 38 41 43 45 4c  B....DRAGON8ACEL
0000b5c0: 42 10 00 dc 01 44 52 41 47 4f 4e 38 42 43 45 4c  B....DRAGON8BCEL
0000b5d0: 42 10 00 ec 01 44 52 41 47 4f 4e 38 43 43 45 4c  B....DRAGON8CCEL
0000b5e0: 42 1c 00 fc 01 42 49 46 46 20 20 20 20 43 45 4c  B....BIFF    CEL
0000b5f0: 42 1c 00 18 02 42 4e 45 43 4b 20 20 20 43 45 4c  B....BNECK   CEL
0000b600: 42 1d 00 34 02 47 52 45 50 20 20 20 20 43 45 4c  B..4.GREP    CEL
0000b610: 42 18 00 51 02 4d 41 4c 4c 4f 43 20 20 43 45 4c  B..Q.MALLOC  CEL
0000b620: 42 1b 00 69 02 50 4f 4c 59 50 53 20 20 43 45 4c  B..i.POLYPS  CEL
0000b630: 42 10 00 84 02 50 55 46 46 20 20 20 20 43 45 4c  B....PUFF    CEL
0000b640: 42 08 00 94 02 52 4f 54 4f 46 4c 59 20 43 45 4c  B....ROTOFLY CEL
0000b650: 42 17 00 9c 02 54 52 4f 4c 4c 20 20 20 43 45 4c  B....TROLL   CEL
0000b660: 42 0f 00 b3 02 42 42 49 52 44 20 20 20 43 45 4c  B....BBIRD   CEL
0000b670: 80 0e 00 c2 02 4d 49 53 20 20 20 20 20 43 45 4c  .....MIS     CEL
0000b680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

… gdy ujrzałem tę strukturę katalogu przyznam że pojawił się w mojej głowie pewien promyk nadziei. Sprawdziłem na szybko czy aby na pewno wpisy znajdujące się w katalogu mają odzwierciedlenie w rzeczywistości i czy na pewno wskazują na poprawne pliki umieszczone na dysku. Okazało się że faktycznie da się te pliki bezproblemowo odczytać za pomocą DOS-a czy też dowolnego narzędzia do ekstrakcji plików umieszczonych w obrazie ATR, aby jednak taka operacja była możliwa i aby “DOS” czy inne narzędzie widziały całą strukturę wpisów należy podmienić bajt znajdujący się pod offsetem 0xb480 na wartość np. 0x60, tak aby DOS czy inne narzędzie nie uznawały że to ostatni wpis w katalogu dysku. Po tej operacji możemy listować już zawartość dysku a także skopiować wybrane pliki.

Teraz przyszedł czas na zastanowienie się jak wygląda wczytywanie przez grę poszczególnych plików, tzn. jak wygląda struktura danego poziomu i gdzie w kodzie gry określone jest jakich plików potrzebuje dany poziom do poprawnego działania. Oczywiście patrząc na strukturę katalogów można domyśleć się iż do każdego poziomu przypisany jest jeden ze smoków (pliki od “dragon1.cel” do “dragon8.cel”), przy czym widać że ostatni smok przeciwnik składa się wielu segmentów (dragon8.cel, dragon8a.cel, dragon8b.cel, dragon8b.cel). Można się domyśleć że pliki: “biff.cel”, “bneck.cel”, “grep.cel” … “rotofly.cel”, opisują wygląd poszczególnych przeciwników spotykanych podczas eksploracji jaskiń na kolejnych poziomach gry, jasne również staje się co reprezentują pliki z końcówką “.scr” oraz pliki “level1.map”. Przyszło mi do głowy że każdy z plików opisujących poziom (*.map_ powinien mieć w informację również o przeciwnikach i ich wyglądzie zawartą w sobie, zatem moja uwaga skierowała się na plik “LEVEL8.MAP”, i patrząc na wpis w katalogu dotyczący pliku “LEVEL8.MAP” widzimy:

0000b520: 42 03 00 00 01 4c 45 56 45 4c 38 20 20 4d 41 50  B....LEVEL8  MAP

Analizując ten wpis widzimy że plik zaczyna się od sektora 256 i ma długość 3 sektorów, zatem zaglądamy we wskazane sektory:

xxd -g1 -seek 0x8010 -l 0x180 "Eidolon, The v1.1 (1985)(Epyx)(US).atr"
00008010: 00 80 00 00 00 e3 00 e2 80 e0 80 80 80 e0 80 e2  ................
00008020: 00 e3 00 00 00 80 00 40 00 40 00 40 00 40 00 80  .......@.@.@.@..
00008030: 00 80 00 00 00 e3 00 e2 80 e0 80 80 80 e0 80 e2  ................
00008040: 00 e3 00 00 00 80 00 80 00 00 00 40 00 00 00 80  ...........@....
00008050: 00 80 00 00 00 80 80 80 80 f3 00 80 00 f3 80 80  ................
00008060: 80 80 00 00 00 00 00 00 00 00 00 80 00 00 00 00  ................
00008070: 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00  ................
00008080: 00 00 00 00 00 00 00 00 00 00 00 80 00 45 02 7d  .............E.}
00008090: 00 00 00 00 00 00 44 52 41 47 4f 4e 38 20 43 45  ......DRAGON8 CE
000080a0: 4c 44 52 41 47 4f 4e 38 41 43 45 4c 44 52 41 47  LDRAGON8ACELDRAG
000080b0: 4f 4e 38 42 43 45 4c 44 52 41 47 4f 4e 38 43 43  ON8BCELDRAGON8CC
000080c0: 45 4c 18 c8 c8 c8 c8 08 0a 00 00 08 00 0c 00 00  EL..............
000080d0: a0 ff 54 c6 c6 c6 c6 88 84 03 00 00 b8 08 04 04  ..T.............
000080e0: 04 04 04 06 08 0a 40 40 40 40 00 00 00 00 00 00  ......@@@@......
000080f0: 00 00 00 00 00 ff 00 00 ff 80 e0 80 e2 00 e3 00  ................
00008100: 00 00 80 00 80 00 40 00 40 00 40 00 40 44 00 69  ......@.@.@.@D.i
00008110: 38 08 2b 0f 7f 0d 1b 7f 0d fa 00 02 4d 52 57 fa  8.+.........MRW.
00008120: c9 17 59 92 bc fa dd f8 f4 f0 f2 fa f4 ba 38 8c  ..Y...........8.
00008130: 09 60 06 ff fa ea fa 07 00 01 02 02 03 04 00 04  .`..............
00008140: e3 05 0d 00 05 05 06 07 08 00 09 0a 0b 0b 0c 0c  ................
00008150: 0d 5f 4a 06 9a 9a aa ba ca da ea 46 e0 01 4e e0  ._J........F..N.
00008160: 13 4e 02 03 0e 10 4c 02 04 0f 11 4c 0a 14 16 19  .N....L....L....
00008170: 18 05 02 08 09 0a 0b 0d 44 02 07 15 17 52 03 07  ........D....R..
00008180: 24 fe 1f 41 c1 e2 fd a3 e4 f1 ea c5 e9 49 04 7d  $..A.........I.}

… no i wszystko stało się jasne! Plik .MAP opisujący poziom zawiera w środku informacje o plikach które są konieczne do wczytania przed uruchomieniem danego poziomu. Szybka analiza rekordów danych nagranych na taśmie pozwoliła mi ustalić że na taśmie brakuje ostatniego pliku “DRAGON8C.CEL”.

Teraz pozostało tylko skopiować z obrazu dyskietki plik “DRAGON8C.CEL” i spróbować zakodować go w taki sposób aby loader wczytujące poszczególne bloki gry poprawnie wczytał ów plik, a przy odrobinie szczęścia mogło się okazać że jeżeli ta operacja skończy się sukcesem to będziemy dysponowali kompletnym odtworzonym obrazem gry. Szanse na powodzenie niewielkie, jednak warto było spróbować.

Jak się do tego zabrać? Ponieważ pracujemy na plikach .HEX opisujących strukturę nagrania w sposób czytelny dla człowieka, a nagrane na taśmę bloki są zgodne ze standardem AST to wystarczyło napisać prosty skrypt kodujący dany plik jako ciąg liczb hex, dodać to tego segment “PWMD” zawierające odpowiednie długości impulsów, na końcu tego całego ciągu danych dodać sumę kontrolną XOR i jeżeli wszystko będzie się zgadzało to loader gry powinien wczytać brakujący plik bez błędu.

Klepiąc parę skryptów w Pythonie (do konwersji danych, liczenia sumy kontrolnej, etc.) udało mi się tę operację przeprowadzić w miarę bezproblemowo. Brakujące segmenty danych dodałem do pliku .hex zawierającego AJKOWĄ wersję gry… i podczas przejścia na ósmy poziom gry okazało się że loader poprawnie wczytał brakujący plik! :) Poziom ósmy wystartował bez problemu! Jakaż była moja radość gdy okazało się że te wszystkie operacje wykonane wcześniej przyniosły oczekiwany skutek.

Postanowiłem również poprawić zatem wcześniejszą wersję przeznaczoną dla turbo AST/UM. Na początku myślałem że loader ładujące poszczególne segmenty danych znajduje się w segmencie danych który pokazuje czołówkę informującą że tę wersję gry opracował “Unerring Masters”, podmieniłem więc tylko początkowe segmenty, tak aby zostały tylko jak mi się wydawało rekordy zawierające loadery dla systemu AST/UM, jednak moja radość nie trwała długo, ponieważ okazało się że loader danych został umieszczony w głównym segmencie danych zawierającego kod gry (blok danych o długości 24705 bajtów), zatem należało przenieść również ten długi blok z wersji dla AST/UM.

W tym jednak momencie zacząłem się zastanawiać czy aby na pewno skonwertowany wtedy przeze mnie plik był na pewno dobrze przetworzony, miałem wątpliwości ponieważ nagranie było dość wiekowe i miejscami trudno było poprawnie przetworzyć niektóre bloki danych, jednak teraz pojawiła się możliwość porównania obu plików, tzn. wersji AJKOWEJ i wersji UM, postanowiłem dokonać takiego porównania, w różnice powinny były tylko występować w obrębie loadera, gdyż wersja dla “KSO Turbo 2000”, dokonywała odczytu używając odwołań do PORTA ($D300) a wersja AST/UM będzie oczekiwać danych z portu SIO, a dokładniej rzecz biorąc z rejestru $D20F (bit #4 który to odwzorowuje stan wejścia SIO_DATA_IN).

Problem w tym że pierwsze dwa główne bloki gry (czołówka “Lucasfilm” oraz główny kod gry) były zakodowane inaczej niż pozostałe bloki gry odczytywane przez loader. Bloki ładowane w trakcie gry zapisano w standardzie AST, natomiast dwa pierwsze bloki posiadały inny początkowy ton synchronizujący, a długości impulsów były zgodne z Turbo 2000, z tym że kolejność bitów w bajcie była kodowana odwrotnie (LSB first) niż w przypadku KSO Turbo 2000 (MSB first). Moja wcześniejsza próba konwersji nie była doskonała, ponieważ mając świadomość iż użycie a8cas-util.pl z wymuszeniem formatu Turbo 2000 i sumą kontrolą XOR, pozostawiła w strukturze bloku PWMD bajty z odwróconymi bitami, a jako że nie przeszkadzało we wczytywaniu danych, to ten blok zostawiłem w takim stanie. Chcąc jednak porównać teraz zawartość obu plików należało doprowadzić ten segment danych do porządku. Kolejny skrypt w python i szybko udało się przetworzyć wcześniej skonwertowany segment danych, niestety okazało się że przy poprzedniej konwersji oprócz odwrócenia bitów w bajtach całość danych została przesunięta o jeden bit w lewo (konwersja i dekodowanie przez a8cas-util.pl było przeprowadzone nie na tym zboczu sygnału które trzeba) … blah… a więc kolejny skrypt i dane zostały przesunięte o jeden bit w prawo. Można było więc porównać zawartość obu segmentów danych (AJEK vs AST/UM). Kolejny skrypt to porównania danych, XOR aby zobaczyć ew. różnice w bitach i okazało się że mam dużo przekłamań na najstarszych bitach niektórych bajtów… ehhh.

Okazało się że przesunięcie nie przeszkadzało procedurom ładującym dane pod emulatorem, gdyż procedury ładujące dane pod emulatorem miały inne zależności czasowe i one dekodowały sygnał generowany ze strumienia PWMD nieco później, przez co dekodowanie następowało nieco później i to się nawet poprawnie wczytywało.

Co należało więc zrobić… ponownie dokonać konwersji tego bloku, niestety u mnie źródłowy plik .FLAC/.WAV się nie zachował, na szczęście Piguła pozostawiał ten plik w  udostępnionych przez siebie zasobach. Pobrałem plik źródłowy jeszcze raz, wysłuskałem blok który mnie interesował i spróbowałem innego podejścia… początkowo chciałem napisać własny dekoder do tego typu danych jednak po paru eksperymentach z “a8cas-util.pl” udalo się poprawnie zdekodować ten blok danych używając następujących parametrów:

./a8cas-util.pl conv -t lowsil2000 --cksum xor eidolon.blk2.um.wav eidolon.blk2.um.hex

Okazało się że długości impulsów używane w przypadku “Wrocławskiego Turbo 2000” są w miarę zgodne z blokami danych zapisanych w formacie UM, jedynie sposób liczenia sumy kontrolnej się zmienia na XOR. Oczywiście po takiej konwersji kolejność bitów w bajcie jest odwrócona, ale tę sprawę można załatwić dodatkowym skryptem.

Tutaj jeszcze jedna uwaga, Piguła udostępnił zgraną taśmę z próbkowaniem 48KHz (to bardzo dobrze), jednak z jakiegoś powodu a8cas-util, nie radził sobie z tym nagraniem próbkowanym z tą częstotliwością, w tym wypadku konwersja z 48kHz do 44.1kHz pomogła a8cas-util uporać się z dekodowaniem bez najmniejszego problemu.

Pewnie niektórzy z was zastanawiają się po co ja to wszystko opisuje, robię to po to aby opisując swoje doświadczenia zostawić coś w rodzaju poradnika i sposobów postępowania, gdyby ktoś kiedyś zechciał odzyskiwać jakieś nagrania odnaleziona na taśmach.

Wracając do moich zewnętrznych prymitywnych "skrypcików" w python, to ja zdaje sobie sprawę że te wszystkie operacje pewnie dałoby się dopisać do a8cas-util.pl, ale ja kompletnie nie znam się na PERL-u w którym to “a8cas-util.pl” jest napisany. Prościej i szybciej jest mi posługiwać się narzędziami czy językami które znam. A pisanie jednorazowych prymitywnych skryptów przy użyciu chociażby Pythona jest po prostu dla mnie szybsze i efektywniejsze, niźli dłubanie w PERL czy też pisanie tony kodu w C.

Także wracając do głównego wątku, po konwersji tego bloku i porównaniu z AJKOWĄ wersją różnice w plikach występowały tylko i wyłącznie w kodzie loadera, który to czytał z innego portu, w tym momencie mogłem być pewien że blok główny blok danych jest poprawnie zdekodowany. Koniec końców można było przygotować finalne wersje plików .HEX oraz .CAS. Przygotowane pliki sprawdziłem pod zmodyfikowaną przez FUJI-ego wersją atari800 (wsparcie dla systemów turbo). Wszystkie poziomy się wczytują poprawnie zarówno w wersji AST/UM jak i tej przygotowanej przez AJKA. Wspomniane pliki dodaję jako załącznik tego posta i kończę ten jak zwykle przydługi swój wywód.

Miałem napisać jeszcze o dwóch rzeczach… gdy loader gry wykryje błąd to na ekranie pokaże się typowa "atarowska tęcza", po cofnięciu taśmy i wciśnięciu START odczyt zostanie ponowiony. Jeżeli zakończymy grę (ostatni ósmy poziom) to gra będzie chciał wczytać ponownie pierwszy poziom, w tym wypadku należy przewinąć taśmę do tego miejsca, albo przesunąć się w obrazie taśmy w emulatorze do 23 bloku (dane poziomu pierwszego zaczynają się właśnie od tego bloku danych).

Drugą sprawą jest to że zastanawiało mnie dlaczego dwa pierwsze bloki nagrano w formacie UM a resztę niejako w formacie zgodnym AST? (różnica w początkowych tonach sync) … początkowo wydało mi się że zabieg ten był celowy i miał za zadnie chronić przed wczytaniem bloku z grą zamiast danych poziomu (np. gdy użytkownik przewinie taśmę zbyt daleko w tył) … ale nie wiem czy to był rzeczywisty powód zastosowania rekordów w różnych formatach. Być może powodem było coś innego.

W sumie to nie sądziłem że zabawa z tym “The Eidolon” zajmie mi tyle czasu, a po drugie nie sądziłem że mnie to wciągnie na tyle że dociągnę ten temat do końca, sam nie wiem czemu się tak zawziąłem, ale każda kolejna przeszkoda która się pojawiała powodowała że bardziej chciałem sprawę doprowadzić do szczęśliwego finału, tym razem się udało, ale nie wiem czy będę miał jeszcze kiedykolwiek tyle cierpliwości ;)

Ostatnio edytowany przez seban (2023-11-04 20:17:21)

Post's attachments

the_eidolon.um.t2k.final.zip 245.36 kb, liczba pobrań: 6 (od 2023-11-04) 

Tylko zalogowani mogą pobierać załączniki.

1,033

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Super. Ale skoro to jest UM, może @galtron coś więcej powie na ten temat? I czy sa inne gry z UM z niepełnymi poziomami? (z ciekawości pytam)?

Sikor umarł...

1,034

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

W archiwum są dwie wersje. Jedna dla magnetofonów z turbo UM/AST/Turbo2000F (odczyt danych przez port SIO) ... druga wersja przerobiona przez AJKA tak aby czytała z portu JOY-a. Myślę że jeżeli chodzi o wersję sygnowaną przez UM to raczej nie pytanie do galtrona a raczej to Piotra Janiszowskiego, który był założycielem firmy UM. Galtron specjalizował się montażu/serwisie czyli bardziej tematy sprzętowe niźli software.

A co do niepełnej wersji gry to pewnie tak została ona nagrana na kasecie firmy Empex... wersja AJKA też pewnie była pełna, zapewne pośrednicy podczas kopiowania tychże nagrań doprowadzili do braku kilku plików. Nie mamy dostępu do oryginalnych wersji więc składamy i odzyskujemy z tego co mamy. Ale skoro w obecnych czasach trudno o kasety z tamtych czasów to należy robić co się da aby odzyskać takie perełki.

Ostatnio edytowany przez seban (2023-11-04 22:20:46)

1,035

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Seban - po prostu mistrzostwo. Tego posta czyta się jak niezłą książkę. Bardzo się cieszę, że opisałeś szczegółowo cały proced odzyskiwania. To bardzo cenne informacje, mogące się przydać przy jakiś perełkach w przyszłości.
Cieszy mnie też fakt, że udało się finalnie złożyć pełną wersję gry dla standardowego Atari z 64KB. Bo takowej w sieci nie było - przynajmniej dla użytkowników magnetofonów. Jeszcze raz bardzo dziękuję!!!

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,036

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Baktraaa widzę, że był jeszcze swojego czasu cart mddos. Nie udało mi się jednak namierzyć nigdzie w sieci romu. Chociaż kiedyś ktoś na pcbway wrzucił projekt tego carta... Udało mi się tylko namierzyć instrukcję do monitora oraz samego dos'a

Ostatnio edytowany przez Piguła/Shpoon (2023-11-05 15:13:18)

Post's attachments

mddos.png 52.99 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,037

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Piguła/Shpoon napisał/a:

Baktraaa widzę, że był jeszcze swojego czasu cart mddos. Nie udało mi się jednak namierzyć nigdzie w sieci romu. Chociaż kiedyś ktoś na pcbway wrzucił projekt tego carta... Udało mi się tylko namierzyć instrukcję do monitora oraz samego dos'a

Niektóre obrazy ROM są dostępne tutaj.
https://a8.jindrou.sh/user_mddos_ok2vcr.html

Notatka. Pobieranie nie jest takie oczywiste, musisz pobrać plik .zip ze wszystkimi obrazami ROM tutaj:
https://a8.jindrou.sh/files/acdp_all_cart.zip

1,038

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

TaK już namierzyłem 3 wersje.
Jest jakiś emulator pod którym on rusza?
Bo widzę, że to typ carta 81
Czyli chyba trzeba będzie zrobić sobie takiego carta
https://www.pcbway.com/project/sharepro … uters.html

Jeszcze opis do niego:

Description
Works as M091 OSS banking scheme, adding bits 5 and 6 for selecting 'subpart'. 4 subparts by 16KBs = 64KB. Also it seems there may be slightly different version which allows to include original OSS carts to be ran from upper banks.

The correct order of banks in a dump is 4 individual M091 OSS carts, ordered backwards in file - first 'cart' starts on 0xC000, second on 0x8000, third no 0x4000 and fourth at 0x0000.

All known cartridges start in Micromonitor, to get from it to MDDOS, press ESC ESC ENTER. You'll be in MDDUP, from there you can do lots of stuff but most interesting is pressing 5 - it lists the content of the romdisk, which behaves as read only double density disk.

So far this info about romdisk was found:

    Sector size is 0x100
    Sectors map in logical order of banks. Sector 0 is thus at 0xC000 in file, sector 0xFF is at 0x3F00.
    The directory is on sector 0x4C, offset 0x80.
    Individual directory records are in the DOS2 format.
    Even the markers at the end of the sectors are the same (6bits for file number, 10 bits for next sector, 8 bits for number of bytes)
    Existing cartridges use sectors 0x60-0x6F and 0x80-0xFF. Totally 36KB. Will need to investigate if more can be used.
    It must be verified if programs can start on any sector, or only on even sectors.

Dodam tylko - że romy śmigają na AVG Cart -> trzeba tylko zmienić typ na AA (DEC 170), bo obrazy ze strony podanej przez Bactraaa mają ustawiony typ jako 81 (HEX 51)

Ostatnio edytowany przez Piguła/Shpoon (2023-11-05 17:02:15)

Post's attachments

2023-11-05 16_15_57-ACDP _ MDDOS — Mozilla Firefox.png 66.77 kb, liczba pobrań: 1 (od 2023-11-05) 

cart1_mddos.png 46.43 kb, liczba pobrań: 1 (od 2023-11-05) 

cart2_mddos.png 55.96 kb, liczba pobrań: 1 (od 2023-11-05) 

MDDOS (laco) (user).car 64.02 kb, liczba pobrań: 5 (od 2023-11-05) 

MDDOS (mikro) (user).car 64.02 kb, liczba pobrań: 5 (od 2023-11-05) 

MDDOS (ok2vcr) (user).car 64.02 kb, liczba pobrań: 6 (od 2023-11-05) 

Tylko zalogowani mogą pobierać załączniki.
Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,039

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Piguła/Shpoon napisał/a:

TaK już namierzyłem 3 wersje.
Jest jakiś emulator pod którym on rusza?

Altirra 4.20-test28

1,040

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Piguła/Shpoon napisał/a:

TaK już namierzyłem 3 wersje.
Jest jakiś emulator pod którym on rusza?

Altirra 4.20-test28

Post's attachments

obrázek_2023-11-05_221436761.png 84.58 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.

1,041

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Co ciekawe, MDDOS obsługuje pliki zapisane w czeskim systemie Turbo 2000, ale głównie w czeskim systemie TURBO TAPE. Turbo Tape, podobnie jak Turbo Blizzard, przechowywała dane w blokach kilobajtowych i obsługiwała wiele prędkości nagrywania. Prędkość została wykryta automatycznie poprzez pomiar długości kilku impulsów tonu pilota. Według dokumentacji MDDOS wspierał także odczyt w systemie Turbo 2000 - kilobajtowych blokach, który był pewnym poprzednikiem TURBO TAPE. Wszystkie systemy opisane są w dokumentacji programu TURGEN. Niestety nie znam polskiego, więc nie dodam opisów na atariki.

1,042

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Dzięki baktraa za pomoc. Już trochę z poziomu AVG softem się pobawiłem. Wiem, że niestety chwyta tylko wersję czeską... ale i tak jest to fajna opcja w kolekcji. Bo na dysku mam ponad 300 wavów w takim formacie, więc będzie okazja się trochę pobawić...

Dorzucam - bez tworzenia nowego posta zrzuconą kolejną kasetę w T2000

Ostatnio edytowany przez Piguła/Shpoon (2023-11-17 20:43:37)

Post's attachments

info.txt 582 b, liczba pobrań: 5 (od 2023-11-17) 

STRONA A.ZIP 383.7 kb, liczba pobrań: 4 (od 2023-11-17) 

STRONA B.ZIP 332 kb, liczba pobrań: 3 (od 2023-11-17) 

turbo-kso-2000(2).jpg 438.22 kb, liczba pobrań: 1 (od 2023-11-17) 

turbo_2000_okladka - Gdansk.pdf 359.67 kb, liczba pobrań: 4 (od 2023-11-17) 

Tylko zalogowani mogą pobierać załączniki.
Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,043

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

baktraaa napisał/a:
Piguła/Shpoon napisał/a:

TaK już namierzyłem 3 wersje.
Jest jakiś emulator pod którym on rusza?

Altirra 4.20-test28

do you have xex file?:)

ATARI 800XE with u1mb, stereo, covox, ramdisk hell led, ultra video 1.0 XE.
SIO2SD, SIDE3, sio2usb, sio splitter, dragon cart, lantronix mss-100, fujinet (lotharek), rverter, A8PicoCart, BT-100, XC12 (T2000), XC12 (SUPER TURBO, TURBO D), both with internal speakers
https://www.youtube.com/@w1katari/

1,044

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

w1k - wersji XEX nigdzie nie namierzyłem... może Seban jak będzie bawił się plikami CAR. To takową skleci.
Ja cieszę się, że owe romy łapie mi AVG:)

Natomiast mnie po zgrywaniu kilkunastu kaset w Turbo2000 w oparciu o magnetofon z T2001 lub T2000f - ten system turbo mocno rozczarował mała kompatybilnością. Masa softu do małego Atari (szczególnie tego, który powstał na finiszu 8bitowego Atari w latach 90 z tym systemem działa słabo. Są problemy, aby go uruchomić z poziomu jakiegokolwiek loadera. Nie mówię, tutaj o sytuacji wynikającej z zagnieceń taśmy. Mam masę plików CAS, które na żywym sprzęcie bez problemu ładują się do bufora programu kopiującego, ale za pomocą loadera nie da się ich wczytać. Po przegraniu na ramdysk lub do pliku ATR uruchamiają się bez problemu. Jest to nagminne przy produkcjach z lat 90. Takich problemów nie mam przy nagrywaniu w systemie Turbo UM. Jednego czego zazdroszczę, to dobrych kopierów Dysk-Turbo. AutoCopy Zabłotnego jest mega fajnym narzędziem - jedyne czego w nim brakuje to możliwości ustawiania czasu przerwy pomiędzy programami. Gdyż program sam z siebie robi jedynie 3sekundy przerwy a to jest niespełna 1 obrót licznika, dla mnie zdecydowanie za mało... bo ciężko potem namierzyć początek na kasecie. Kolejną fajną rzeczą jest handler, który ułatawia przenoszenie danych z taśm na dysk. Takiego handlera bardzo brakuje mi w systemie Turbo UM.
I ostatnia rzecz - dużo trudniej jest mi wykonać backup kasety w oparciu o decka i plik wav całej strony. Z plikami w turbo UM leci to u mnie bez najmniejszych problemów i wszystko potem ładnie się wczytuje... z nagraniami w T2000 mam dużo trudniej.... chyba, że kasetę nagram bezpośrednio na Atari za pomocą autocopy.... wtedy wszystko śmiga od pierwszego strzał'u...

Ostatnio edytowany przez Piguła/Shpoon (2023-11-20 17:57:39)

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,045

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Hej!

Piguła/Shpoon napisał/a:

Natomiast mnie po zgrywaniu kilkunastu kaset w Turbo2000 w oparciu o magnetofon z T2001 lub T2000f - ten system turbo mocno rozczarował mała kompatybilnością. Masa softu do małego Atari (szczególnie tego, który powstał na finiszu 8bitowego Atari w latach 90 z tym systemem działa słabo. Są problemy, aby go uruchomić z poziomu jakiegokolwiek loadera.

Miałem wcześniej o tym napisać, ale zawsze jakoś pojawiały się inne tematy i zapominałem o tym napisać... Zacznę od tego że ja nie znając innych rozwiązań w tamtym czasie, obcowałem tylko z KSO Turbo 2000 i Turbo 2000F i miałem zupełnie przeciwne doświadczenia do Twoich, tzn. bardzo duża kompatybilność tegoż systemu z różnymi narzędziami które pracowały ze stacją dysków, masa użytków które działały pod DOS ze stacją dysków,  działała "od pierwszego strzału" i to bez żadnych przeróbek! Wszelakie programy kopiujące, edytory tekstu, assemblery (w tym niegdyś mój ulubiony MAC/65), przykładów mógłbym mnożyć wiele...

Natomiast jeżeli chodzi o wczytywanie gier to zaraz nawiążę do tego problemu, ale może na początek zapytam, którego softu do obsługi turbo używałeś? Pytam bo prosty podział jest na dwie wersje... jedne z wersji Turbo 2000F/2001 lokowały się pod OS-ROM, a drugie z wersji lokowały się od $0700. KSO Turbo 2000 (Joy Port) spotkałem tylko wersję lokującą się nisko (od $700).

Dlaczego o tym piszę? A już tłumaczę... gdy weźmiesz pod uwagę wersje plikowe gier które były dostępne w tamtych czasach na giełdzie były to gry które często ładowały się bardzo nisko w pamięć, albo takie które to ładowały swoje porcje danych pod OS-ROM, były również takie pozycje które zarówno ładowały się nisko i podczas ładowania umieszczały dane pod OS-ROM komputera.

Teraz zapewne rozumiesz co się działo jeżeli próbowałeś ładować grę która niszczyła jakiś konkretny obszar pamięci podczas wczytywania? Należy również mieć świadomość że w przypadku Turbo 2000F/KSO standardowy blok danych ma rozmiar 3072 bajty, więc pomimo kodu obsługującego system/handler turbo, należało w pamięci mieć miejsce na 3kB bufor przechowujący dane aktualnie wczytywanego rekordu danych.

Tak więc do wyboru miałeś albo KSO/Turbo2000F wersji która miała MEMLO na poziomie ~$1A00, albo wersję która lokowała się co prawda od OS-ROM i jej MEMLO było co prawda na poziomie $800 ale za to zajęta była część przestrzeni pod OS-ROM. Rozwiązań tego problemu było kilka... pominę na razie sprawę loaderów L1 czy L2, bo to była taka proteza raczej niż dobrze napisane loadery. Nie pamiętam już dokładnie co robił L1, ale L2 o ile dobrze pamiętam po prostu relokował sobie ów 3kB bufor na rekord danych pod OS-ROM i dzięki temu obniżał MEMLO 3kB

Przyznam że znając te "ograniczenia" systemu od podszewki to jeżeli z jakąś gra był problem to początkowo sobie albo ją modyfikowałem tak aby wczytywała mi się bez problemów (starałem się nie korzystać z loaderów L1 czy L2), potem ktoś z giełdy poprosił mnie o przerobienie loaderów L1, L2 tak aby bufor danych umieszczały banku dodatkowej pamięci, a jeszcze później zrobiłem sobie cart który oprócz pamięci EPROM miał w sobie 8KB RAM mapowane w $8000-$9FFF i ten dodatkowy RAM wykorzystywałem jako bufor na rekord danych wczytanych z taśmy, więc problem niejako rozwiązał się sam, ale to rozwiązanie przestałem szybko rozwijać bo na horyzoncie pojawiła się możliwość posiadania stacji dysków TOMS 720. Jak czas pozwoli do odkopię moje stare zapiski i przeszukam kartony i może uda się to wyrwać z odmętów przeszłości.

Ale jakie było rozwiązanie dla "szarych" użytkowników? Jednym z rozwiązań było przepuszczenie opornej gry przez jakiś cruncher... w późniejszym czasie mógł być to np. Cruncher 2.69, Cruncher 4.64 czy potem Cruncher 5.0 od Magnusa. Te crunchery co prawda zmieniały strukturę oryginalnego pliku ale za to generowały wyjściowy plik który nie wymagał niskiego MEMLO do wczytania programu.

Natomiast przed nastaniem ery Cruncher-ów powstał jeszcze tzw. "NEW FORMAT" czyli inny format zapisu danych, nie podzielony na rekordy jak standardowy format "Turbo 2000F/KSO", format ten charakteryzował się tym że poszczególne bloki danych ładowały się konkretne/docelowe miejsca pamięci, przez co procedura ładująca mogła być prosta i krótka a do tego nie było potrzebne miejsce na bufor który przechowywałby aktualnie wczytywany rekord danych.

Handlarze giełdowi umieszczali na swoich taśmach/zestawach nagrania w formacie "Speedy 2700", który to był nieco efektywniejszą odmianą "nowego formatu" Turbo 2001.

Należy oczywiście pamiętać ze format danych Turbo 2000F/KSO jest tak naprawdę tym co zaproponował pan Wojciech Zabołotny w swoim systemie Turbo 2T06 i większość softu do cartów czy też ładowanych z taśmy tzw. "KOS-ów" (Kasetowy System Operacyjny) dla Turbo 2000F/KSO jest pochodną bazującą na pracy wykonanej przez W.Zabołotnego.

Część rozwiązań w tym systemie ma swoje pewne ograniczenia i wady, jednak w owym czasie nie pamiętam abym był specjalnie przejęty ograniczeniami tegoż systemu... byłem naprawdę bardzo z niego zadowolony. Mogłem bez problemu użwać chociażby Turbo Basic XL, MAC/65 czy też sporej masy innych narzędzi które nie były przewidziane do pracy z taśmą. A jednak działały bez problemu.

Ładowanie gier które wymagały niskiego MEMLO było jakimś tam wyzwaniem, ale przyznam że dzięki temu bardzo szybko zgłębiłem zarówno tajniki działania tegoż systemu jak i też techniki stosowane przez osoby wykonujące wersje plikowe gier.

Zdaje sobie oczywiście sprawę że na pewno jestem dość mocno "spolaryzowany" jeżeli chodzi preferowanie tego rozwiązania... ale z drugiej strony patrząc na to ile walki musiałem podjąć np. w celu wykonania jakichś dumpów kaset zapisanych w Blizzard czy innych systemach, to w moim przypadku kasety zapisane w Turbo 2000F/KSO szły o wiele lepiej i szybciej ... no chyba że to były nagrania zapisane w Speedy 2700 z którymi to już musiałem się nieco więcej użerać. Być może moje odczucie "łatwiejszego" przetwarzania kaset nagranych w Turbo 2000F/KSO wynika własnie z tego że długo obcowałem z tym systemem w przeszłości i podświadomie omijam pułapki zastawione na mnie przez upływ czasu i starzejące się taśmy.

Znowu wyszedł mi jakiś koszmarnie długi post... a miało być krótko i konkretnie... ale ja chyba tak nie potrafię... miałem co prawda jeszcze kilka myśli i wątków do rozwinięcia, ale prawdę mówiąc tyle razy już zboczyłem z tematu głównego że nie pamiętam o czym chciałem jeszcze napisać. Jak mi się przypomni to nie omieszkam dopisać/uzupełnić.

1,046

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Noooo... Ja pamiętam jak korzystałem z Kyan Pascala w KSO Turbo 2000 ;) Naprawdę fajne doświadczenie ;)

Sikor umarł...

1,047

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

seban napisał/a:

miało być krótko i konkretnie... ale ja chyba tak nie potrafię...

Nikt na to nie narzeka. Wprost przeciwnie :) Ja po poście Piguły to nawet czekałem na ripostę ;)

seban napisał/a:

tyle razy już zboczyłem z tematu głównego że nie pamiętam o czym chciałem jeszcze napisać.

Może kiedy wznowienie odcinków głównego wątku o cartach i płytkach turbo? ;-D

--== Kup Pan/i dyskietkę - jedyna taka oferta w całym InterNetCie - http://www.atari.org.pl/forum/viewtopic.php?id=18887 ==--

<-- Kontakt przez "E-mail" albowiem moja skrzynka "PW" jest pełna i zaprawdę nie mam czego usunąć.

1,048

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@Seban - zgodność T2000 z softem użytkowym nie podlega w ogóle dyskusji. Wybór literki D dla handlera zamiast T jak to ma miejsce w innych systemach jest strzałem w 10.
Ja do wczytywania używam dwóch cartów przekształconych do formy XEX przez Ciebie, jeden Turbo 2001, drugi T2000f.
W obu przypadkach efekty z programami (grami) z lat 90 są podobne... oczywiście zawsze mogę z bazy AOL pobrać inną wersję danego tytułu i doprowadzić do sytuacji, w której jednak się wczyta na żywym sprzęcie. Loadery, które z założenia miały pomóc z takimi produkcjami L1 oraz L2 dotykają raczej czystego Turbo2000 KSO. O ile L2 u mnie działa, to L1 niestety działa tylko z magnetofonem, który używa portu joy'a. Czyli w moim przypadku jest bezużyteczny. Speedy2700 w większości przypadków rozwiązuje sprawę - chociaż jest o tyle niewdzięczny, że nagranie w tym formacie można przygotować jedynie Turgenem - a potem należy go nagrać na jakimś decku. I tutaj jest pies pogrzebany. Bardzo słabo to wychodzi w moim przypadku - mam często problemy z wczytaniem tak dokonanych nagrań. Muszę bardzo często dobierać poziom zapisu dla konkretnego przekształconego zestawu w T2000 plus kręcić głowicą w magnetofonie Atari. Owych problemów nie mam w przypadku Turbo UM lub normalu. Wszystkie nowe zestawy które generowałem sobie w oparciu o deck'a śmigają od pierwszego strzału. Nawet jak przenosiłem nowe produkcje do tego standardu, to z poziomu loadera UM 99,9% z nich bez problemu się wczytuje..
Moje wrażenia i odczucia zapewne wynikają z faktu, że tego systemu używam od lat 90, a T2000 i pochodne są rozwiązaniami, którymi bawię się dopiero od roku. Mam kilka płytek do cartów, na których mogę wykonać repliki i pewnie w wolnej chwili  je wykonam... aby mieć większą bazę loaderów w różnych wersjach z szybkim dostępem, bez potrzeby ładowania ich jeszcze z taśmy... może to zmniejszy chociaż trochę liczbę oprogramowania, którego nie potrafię wczytać z poziomu emulatora lub Atari. Mimo, że sam soft nagrany jest poprawnie.

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,049

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

Czy nie ma kopiarki DISK -> Speedy2700 lub czegoś podobnego, czego można używać z prawdziwym komputerem? Coś musiało być w latach 90.

1,050

Odp: Turbo Tapes, Carts & Hardware - z kolekcji uicr0bee i nie tylko :]

@baktraa - owa kopiarka była na bank.. tylko nigdy nie trafiła do szerokiego obiegu. Seban stworzył jedynie narzędzie do wyłuskiwania plików z takich nagrań. Dzisiaj magnetofonem bawi się już tylko mała grupa wariatów m.in ja :)

Ps. Zamówiłem 5 sztuk pcb dla carta mddos... więc będę robił sobie replike do kolekcji...

Ostatnio edytowany przez Piguła/Shpoon (2023-12-04 06:38:45)

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim