ehhh.... zrobił się double post.... to dopiszę w tym drugim jeszcze kilka słów o strukturze tego nagrania.

Pierwszym blokiem danych nagranym w standardowym formacie Turbo 2000 jest loader zawierający procedury ładowania dla turbo UM przerobione tak aby czytały dane z portu JOY-a, a po drugie zmienione tak aby reagowały na długości impulsów adekwatne dla Turbo 2000/KSO. Nie wiem co to miało na celu... bo dwa następne bloki są blokami nagranymi w formacie Turbo UM, tyle że długości impulsów kodujących 1 i 0 są zmienione tak aby pasowały tym które występują w Turbo 2000/KSO. W dodatku turbo UM w przeciwieństwie do KSO koduje bity w bajcie w odwrotnej kolejności, tzn. LSB first. Tak więc blok nazwy i blok zawierający loader w pliku hex, mają odwrócone bity w bajtach bo a8cas-util.pl nie daje możlwiości wymuszenia kodowania lsb_first czy msb_first i dokonuje wyboru na podstawie formatu określonego w parametrach, tzn. opcja "-t turbo2000" wymusza kodowanie msb_first. Można oczywiście sobie odwrócić wartości tych bajtów jakimś prostym skryptem.

Pierwszym blokiem jest blok nazwy, drugi blok to blok zawierający główny loader ładujący pozostałą część nagrania, ten blok jest ładowany od adres $400.

Pozostałe bloki danych są już nagrane w formacie AST tak jak wspominał wcześniej Piguła.

Wracam na chwilę do "The Eidolon"...  loader udało mi się wyłuskać z tego nagrania poprawnie, przynajmniej tak mi się wydaje (w załączniku do tego następnego posta plik .hex zawierający ów loader).

Natomiast z konwersją części AST mam problem... tzn. udaje niby mi się dokonać konwersji... ale mimo że a8cas-util.pl mówi że wszystko jest OK, to w/g mnie wcale tak nie jest (np. zmieniając parametry konwersji uzyskuję różną liczbę bloków wyjściowych) ... powodem takiego zachowania jest to że AST ma prymitywny mechanizm obliczania sumy kontrolnej bazujący na XOR ;-/ tak naprawdę przy tak długich blokach danych trudno mieć pewność dane są poprawne.

Przy moich próbach konwersji bloków AST udaje się maksymalnie wczytać 2-3 poziomy, potem mam błąd odczytu sygnalizowany poprzez cało ekranowe kolor-bary. Piguła, pisałeś że Tobie się udaje konwertować te bloki AST bez problemu... może jak połączysz mojego hex-a zawierającego loader z Twoją konwersją bloków AST to wyjdzie z tego coś sensownego.

Niestety jakość nagrania jest dość kiepska, tzn. wysokie częstotliwości dość słabo się zachowały na kasecie, albo kaseta była nagrywana na magnetofonie ze źle ustawionym skosem głowicy, stąd problem z wyższymi częstotliwościami:

http://seban.pigwa.net/aa/the_eidolon_frq.png

Hej!

Piguła/Shpoon napisał/a:

Za wyjątkiem 3 pierwszych pozycji ze strony A. Jest tam rozwiązanie mieszane Turbo2000 + AST. gra The Eidolon, Ace of Aces oraz MULE.

Rzuciłem "na szybko" okiem na pierwszą pozycję, wygląda na to że loader obsługuje tylko turbo podpinane do drugiego portu JOY-a... w weekend postaram się znaleźć trochę wolnego czasu i spróbuję się temu przyjrzeć dokładniej i dokonać konwersji do CAS (mam nadzieję że się da).

Piguła/Shpoon napisał/a:

Obrobiłem zestaw 18 Studia Spark w T2000

Dzięki WIELKIE! :) Już pobieram i wrzucam do swojego domowego archiwum!

Hejka!

Czyli mam rozumieć że już nie muszę szukać? :D

55

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

Ja również bardzo dziękuję! Sprzęt super!

56

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

OK, czyli wychodzi na to że w pełni "padło na mnie" ;-) ... odezwę się na priv.

57

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

podbijam do 200 za PC.

58

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

Hej!

To ja może zacznę

1) compaq - 100 zł
2) składak - 100 zł

59

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@VLX: przyjrzałem się trochę temu dyskowemu wydaniu Crumbles Crisis, akurat miałem do przećwiczenia parę koncepcji i pomysłów, toteż dzięki temu dało dodać trainer w miarę niewielkim nakładem pracy (w załączniku tego posta wersja dyskietkowa z trainerem). Robiłem ją z obrazu .ATX zawierającego grę oryginalnie wydaną w UK przez Red Rat Software.

Przy okazji przyjrzałem się plikom i dochodzę do wniosku że z użyciem kompresji dało by się zrobić wersję file mieszczącą się w 64kB ze wszystkimi poziomami, i gdyby nie kompilowany BASIC to już bym działał... ale przy kompilowanym BASIC-u to trzeba by zastosować inne podejście i napisać sobie taki handler I/O który dane by zasysał z ram i dekompresował w locie wszystko. Trochę więcej upierdliwej roboty... ale to może kiedyś, bo teraz nie mam ani czasu, ani cierpliwości aby z tym walczyć ;) Zresztą gdy pograłem w inne poziomy tejże gry to mnie to tylko bardziej zniechęciło... do tej pory sądziłem że pierwszy poziom jest upierdliwie trudny, ale porównując go do następnych, to ten pierwszy to bardzo prosty jest ;P

60

(115 odpowiedzi, napisanych Software, Gry - 8bit)

małe info: postanowiłem się przyjrzeć "Crumble's Crisis", wiedziałem że to kompilowany BASIC, ale nie z takimi rzeczami człowiek walczył jak był młody :P grzebiąc w tym "skompilowanym chaosie", udało mi się zrobić "unlimited energy", więc zacząłem sobie grać w wersję plikową (zrobioną przez Tomasza Rolewskiego) ... ale po przejściu pierwszego poziomu okazało się że gra jest owszem w postaci plikowej, jednak zawiera tylko pierwszy poziom i po jego zakończeniu wracamy ponownie do poziomu pierwszego.

W sumie to się kiedyś zastanawiałem jak te wszystkie poziomy udało się T.R. upchnąć w pamięci i własnie poznałem odpowiedź :D Nie udało się, wersja plikowa jest okrojona... w sumie T.R. uznał chyba że gra jest na tyle trudna/nudna/monotonna że nikt i tak nie przejdzie pierwszego poziomu i taka okrojona wersja plikowa w zupełności wystarczy, a nawet jak ktoś zakończy poziom pierwszy to się jedyne wnerwi na autora gry że to jakaś porażka że po przejściu całego labiryntu i pozbieraniu wszystkich "fuzzies" zaczynamy od nowa ;-)

T.R. robiąc wersję plikową "Crumble's Crisis" poszedł drogą stworzenia w pamięci takiego nazwijmy to "mini" ram-dysku, w którym trzyma pliki doczytywane przez grę, jednak nie zrobił on jednego urządzenia powiedzmy "R:" z którego gra czyta pliki, a zastosował nieco odmienne podejście, mianowicie stworzył on listę urządzeń "A, B, G, H, I, J". Każdy z tych handlerów udostępnia jeden plik gry (obrazek, fonty, mapę, etc.). W kodzie gry podmieniono nazwę urządzenia "D:" z której gra oryginalnie czytała pliki (używając nazwy pliku), na inne urządzenia (A-J), więc gra odwołując się do G: zawsze dostanie plik "CRUMBLE.PIC", niestety gra wczytując dany poziom, również dostanie zawsze ten sam plik, niezależnie od nazwy poziomu jaką poprosi.

Myślę że ten zabieg T.R. wykonał celowo aby stworzyć wersję plikową gry mieszczącą się w 64kB pamięci RAM. Założenie pewnie było takie że nikt i tak nie będzie miał tyle cierpliwości aby przechodzić całą grę przy poziomie trudności zaoferowanym przez autorów gry. Czasy  były takie że to mogła być kolejna pozycja do handlu na giełdzie (dla posiadaczy magnetofonów) i pewnie nikt się nie przejmował że gra jest de-facto niepełna.

Przyznaję otwarcie że wcześniej (bez zrobienia nieśmiertelności) nie miałem cierpliwości grać w tę grę, jednak teraz się okazało że mając tę grę nagraną na kasetę to dużo bym sobie nie pograł :P ... ale "do brzegu"... robienie nieśmiertelności do wersji niepełnej mija się z celem, a przerabianie wersji dyskietkowej również chyba nie ma sensu, ponieważ rozumiem że Jaro124 chciał mieć wersję plikową tejże gry. Zastanawiałem się czy spróbować zrobić wersji plikowej zawierającej wszystkie poziomy, np. używając wydajnej metody kompresji poziomów, ale po pierwsze trzeba by oszacować czy aby na pewno dałoby się to skompresować aby to się zmieściło w wolnej przestrzeni RAM którą gra pozostawia nietkniętą, a po drugie to chyba nie mam na to aż tyle chęci i czasu ;-) Zatem "Crumbles Crisis" w wersji plikowej skreślam z listy "TO DO". Zastanowię się nad modyfikacją wersji dyskietkowej, ale to już kiedyś.

Jeżeli ktoś chce sobie zrobić "unlimited energy" z ręki za pomocą monitora w używanym emulatorze to proszę oto przepis; należy zmienić zawartość dwóch komórek pamięci na $20 (rozkaz JSR) na $2C (rozkaz BIT), owe adresy to:

  • $532B - zmiana na $2C spowoduje że nie ubywa energii po zderzeniu z murem czy też nieruchomymi obiektami pola gry

  • $3305 - zmiana na $2C spowoduje że nie będzie ubywać energii przy kontakcie z ruchomymi obiektami w grze (tzw. "przeszkadzajkami")

... i to chyba tyle co miałem do powiedzenia na temat "Crumbles Crisis". Musze przyznać że gdy pograłem trochę bez ubywającej energii gra wydała mi się bardziej przyjazna i bardziej grywalna ;-) Ale ja nie jestem jakimś graczem, dla mnie gry to głównie rozrywka i relaks, ale "przesadzony" poziom trudności mnie wręcz zniechęca. Pewnie stąd zrodziło się kiedyś moje "zamiłowanie" przerabiania gier ;)

61

(115 odpowiedzi, napisanych Software, Gry - 8bit)

i przysłowiowym "rzutem na taśmę", wrzucam również "Super Cobra".

62

(115 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Po długiej przerwie wrzucam kolejny tytuł z listy, tym razem to "Batty Builders". W załączniku .xex do pobrania.

@piguła: no to rewelacja! Cieszy mnie że udało podnieść ten magnet i przywrócić go do sprawności! Kolejny kaseciak uratowany! Niech służy dobrze! :)

@Grzegorz_29_: fajnie że wynajdujesz i udostępniasz takie ciekawostki :) Dzięki temu poszerza się obraz dawnych czasów i rozwiązań stosowanych w konkretnych regionach polski... bez takich "akcji" to bym był przekonany że nie było tak wielu różnorodnych rozwiązań stosowanych nazwijmy to "lokalnie". A to turbo od Pana Sidora to też jest ciekawostka, nie porzuciłem jeszcze prac nad analizą tego systemu, jednak wymagają one więcej czasu niż mi się wydawało... zatem chwilę to potrwa.

Dzięki Panowie za wasz wkład i chęć dzielenia się waszymi zasobami, doświadczeniem i tym że opisujecie to na co napotykacie!

64

(358 odpowiedzi, napisanych Sprzęt - 8bit)

Cześć!

Ja chyba żyję (przynajmniej tak mi się wydaje :P) ... co do SlightSID to jestem na etapie w którym po pewnych przemyśleniach postanowiłem przyjąć  inną strategię... po protu wypuszczę ten projekt w obecnej formie. Pogodziłem się z tym że "dalekosiężne" plany rozwoju i modyfikacji tejże wersji mijają się celem. Zostawię więc mapowanie rejestrów tak jak jest, ponieważ istniejący soft to obsługuje, zmian w CPLD wprowadzać już nie będę, dokładać modułu zapewniającego self-upgrade również nie będę. Skoro tyle czasu przeleżało to bez większych postępów to myślę że dokładanie dodatkowej funkcjonalności której nikt albo prawie nikt nie wykorzysta nie ma najmniejszego sensu. Poza tym jeżeli ktokolwiek będzie zainteresowany jeszcze tym produktem/projektem no wypuszczenie go w obecnej formie pozwoli albo na spokojną śmierć albo dalszy rozwój produktu.

@piguła: jasne. ale to jak ogarnę to co mam w kolejce. dam znać na priv.

@pigłuła: jak zwykle dzięki za kawał dobrze wykonanej roboty!

@Grzegorz_29_: przyjrzałem się plikom które udostępniłeś z programami ze "studia komputerowego" z Ząbkowic Śląskich:

http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/loader_speeder_zabkowice.png

Część pozycji udało się odtworzyć i przekonwertować do plików CAS, niestety fragmenty nagrań na kasecie wydają się być  uszkodzone (zaniki sygnału na taśmie), np. "Pitstop" którego nie udało się odtworzyć wygląda w kilku miejscach tak:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/pitstop_signal_drop.png

Te pliki które udało się poprawnie przekonwertować do formatu CAS udostępniam dla zainteresowanych: Speeder 1400 - Ząbkowice Śląskie

Części nagrań właśnie z powodu wspominanych "zaników" sygnału (szczególnie tym problemem dotknięta jest strona "B" kasety z której robiłeś "zrzut", być może to zagniecenia lub uszkodzenia powierzchni taśmy) nie udało się odtworzyć jednak analizując fragmenty nagrania które to udało się wczytać do pamięci, udało się ustalić co to były za pozycje (używałem bazy AoL z grami do znalezienia ciągów które występowały w uszkodzonych nagraniach, w ten sposób udało się jednoznacznie określić jaki program był na taśmie zapisany), oto lista programów z udostępnionego przez ciebie "zrzutu" kasety:

strona A)

01) Gladiatior
02) HardHat Willy
03) Desmod's Dungeon
04) Pitsop [malformed]
05) Gunfight
06) Chimera

Strona B)

01) Diamond Mine (Roklan) [malformed]
02) Arcanoid III
03) Mr. Do!
04) Boulder Dash 8 (Iron Soft)
05) Electrician (Synapse Software, 1984) [malformed]
06) Joe (by Roy York) [malformed]

Na szczęście pozycje których nie udało się odtworzyć nie są białymi krukami ani unikalnymi pozycjami więc straty nie są duże :)

Przyjrzałem się także kodowi loadera, i jest on właściwie tożsamy ze "Speeder 1400", użwa on całej masy "nielegalnych" kodów procesora 6502, a jeżeli chodzi o ten formatu zapisu to przypomniały mi się dwa wątki. Rozmawialiśmy kiedyś o Speeder Tape w tym wtąku Speeder Tape. Potem jeszcze wypowiadałem się na temat programu Speeder 1400 autorstwa K.Polaka o w tym poście: Speeder 1400.

Kaseta która udostępniłeś jest zapisana w formacie Speeder 1400 autorstwa K. Polaka, jednak nie wiem którą dokładnie wersją Speeder-a były tworzone te nagrania, ale sądząc po tym co udostępnił Voy na pigwie, to K.Polak prawdopodobnie tworzył na zamówienie wersje swojego programu zawierające nagłówki reklamujące dane "studio komputerowe". Zapewne tak było i w tym wypadku, tzn. "Studio Komputerowe" z Ząbkowic Śląskich posługiwało się "spersonalizowaną" wersją programu która wyświetlała ich nagłówek podczas ładowania się programów.

A jeżeli chodzi o Ząbkowice Śląskie i adres 1-maja 17, to google maps (street view) dysponuje najstarszymi zdjęciami z lipca 2012:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/Studio_Komputerowe_1_maja_17_Z%c4%85bkowice_%c5%9al%c4%85skie_a.jpg

gdzieś w tej kamienicy znajdowało się owe studio komputerowe :) Może ktoś coś kojarzy i pamięta:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/Studio_Komputerowe_1_maja_17_Z%c4%85bkowice_%c5%9al%c4%85skie_b.jpg

Hej!

Piguła/Shpoon napisał/a:

Mimo wszystko są to dwie nietypowe pozycje w tym Turbo. Bo nie da się ich skopiować kopierem ATT-ATT. W oryginalnym zrzucie do WAV po powiększeniu widać przy obu tytułach 0.4sekundowe bloki ciszy w tych felernych miejscach.

Ja myślę że to nie jest nietypowe, tylko ktoś spierniczył zapis tych pozycji, może kopiował je "na raty" i "podkasował" kawałki tonów synchronizujących, być stąd problemy z kopiowaniem. A loadery do ATT praktycznie nie sprawdzają żadnych błędów, mówiąc brzydko "wczytują na pałę" i odpalają czy wczytało się poprawnie czy też nie. A przerwa pomaga bo szum z taśmy generuje jakieś tam krawędzie, które przez loader są "detektowane" jako kolejne zbocza sygnału, właściwie to pewnie loader czeka na jakąś zmianę która jest impulsem dłuższym niż "0" lub "1", nie wnika czy to jest synchro/stop, etc. Jeżeli kopier tego nie łyka to być może procedura łądująca jest nieco bardziej rozbudowana i oczekuje czegoś więcej niż minimalistyczna procedura w loaderze.

@takron27: a widzisz ... nie byłem świadomy że walczycie w tym wątku jakimiś kasetami :) na AoL zdarza mi się zaglądać, ale ostatnio brak czasu powoduje że na forum nie zaglądałem zbyt często, a tam się widzę dzieje niezła walka :) ... fajnie że walczycie w temacie! Aż miło czytać że archiwizacja i zgrywanie napotkanych kaset idzie jak burza!

btw. w ostatnim poście tego wątku na AoL który podałeś pisałeś, że to co Ci się wczytuje z użyciem magnetofonu wyposażonego w Turbo2000F/2001 nie wczytuje Ci się użyciem softu do KSO Turbo 2000 ... wybacz głupie pytanie, pewnie jesteś tego świadom ... ale wolę się upewnić ... rozumiem że jak używasz softu od KSO Turbo 2000 to używasz także magnetofonu wyposażonego w ten interface bo KSO Turbo 2000 transmituje dane z wykorzystaniem drugiego portu joysticka i software te dane czyta używając PORTA z układu PIA.

W moim wypadku mam taki swój stary magnet XC12 który za wbudowane zarówno Turbo 2000F jak i KSO Turbo 2000 i problematyczne kasety udawało mi się raczej wczytywać pewniej używając interface KSO Turbo 2000 (drugi port JOY) niż minimalistycznego Turbo 2000F. Być może taki egzemplarz XC12 że KSO Turbo 2000 ma większe wzmocnienie czy też inną charakterystykę przenoszenia, która powoduje pewniejszy odczyt. KSO Turbo 2000 ma też chyba nieco inaczej "docyklowane" procedury odczytu, więc np. jeżeli prędkość obrotowa silnika jest inna to np. w Twoim wypadku powoduje to że KSO Turbo 2000 szybciej wywala Ci Error 140 (zła długość zmierzonego impulsu). KSO 2000 było wcześniej niż Turbo 2000F i bazowało na Turbo 2T06 pana W. Zabołotnego. Turbo 2000F/2001 było n-tą iteracją systemu, więc zmieniły się również nieco procedury odczytu (zostały uproszczone), ale nie wydaje mi się aby ktoś modyfikował tablice przechowujące długości impulsów, czy też zmieniał wartości liczników pętli które zliczają długości impulsów z taśmy. Może więc być tak że taśmy zapisane za pomocą softu dla KSO 2000 będą miały inny margines błędu przy odczycie softem dla Turbo 2000F/2001 i vice versa. A ja do tego dodać wiek taśmy i różnice prędkości obrotowych magnetofonów to mimo 100% zgodności formatu, odczyt za pomocą różnych wersji oprogramowania i różnych interfejsów może mieć wpływ na jakość/pewność odczytu.

Dla mnie KSO Turbo 2000 to system który posiadałem jako pierwszy więc jak to się mówi mam niezły "bias" i ten właśnie system jest dla mnie najwygodniejszy i najpewniejszy, do dziś moje stare kasety zapisane w KSO Turbo 2000 czytają się bez problemu :) A mają chyba już ze 30 lat ;D Przez moje ręce przewinęło się sporo innych starych kaset i to własnie z kasetami zapisanymi w innych systemach maiłem najwięcej "zabawy" (czytaj problemów) ... chyba najszybciej sobie radzę z obróbką standardowego formatu KSO Turbo 2000/Turbo 2000F/2001. Ale jak mówię w tym wypadku moja stronniczość (chociaż nie jest to za dobre tłumaczenie angielskiego "bias", być może lepszym słowem byłaby polaryzacja) może mieć kluczowe znaczenie. Nie jest to oczywiście system idealny, bo ma standardowo chociażby owe 3kB bloki przez które robi się problem z miejscem potrzebnym na bufor danych i MEMLO systemu jest dość wysokie, ale przyjdzie kiedyś czas kiedy wyciągnę moje skarby z szuflady i napiszę opowieść o tym jak sobie z tym radziłem :D

I doskonale rozumiem wszelakie starania wasze o zachowanie nagrań w innych systemach, bo są one dla was i dla mnie tak samo ważne ze względów zarówno sentymentalnych jak i historycznych.

@piguła: udało mi się "chyba" poprawnie przekonwertować oba wrzucone przez Ciebie pliki. Piszę chyba to format ATT to jakieś szaleństwo, kiedyś narzekałem na UM że ono ma sumę kontrolna liczoną za pomocą XOR i do powoduje ryzyko dużych przekłamań, ale ATT nie ma sumy kontrolnej wcale!!! To jest czyste szaleństwo! Kogoś kto to wymyślił ... no cóż... może nie chciał reklamacji nagranych kaset :D

Ale wracając to tematu w przypadku "whistler brother" brakowało po prostu kawałka tonu synchronizującego pomiędzy blokami, skleiłem Twoje dwa pliki HEX poprawiając jeden blok i poszło. W przypadku "Amaurote" kaseta musiała mieć już swoje lata więc przetworzyłem ten plik .WAV za pomocą swoich prymitywnych "prostokątuzujących" sygnał python-owych skryptów i po tej operacji użycie "a8cas-util" w trybie ATT dało działającą wersję gry. Przynajmniej na pierwszy rzut oko działającą (bo nie widzę żadnych przekłamań w grafice ani innych początkowo widocznych artefaktów). A to że ramka zostaje czerwona, to już kwestia loadera i samej gry. Loader zostawia ramkę czerwoną, a gra ustawia czarny kolor ramki dopiero po rozpoczęciu gry przez użytkownika. No ale pewności żadnej nie mam ponieważ jak "kwękałem" powyżej nie ma żadnej pewności ponieważ bloki danych systemu ATT nie zawierają żadnych sum kontrolnych! :D Trzeba by porównywać bloki danych z oryginalną wersją gry.

Wspominałeś także że "kopier" z carta "New Cart" zmienia zawsze format z ATT na UM, pewnie własnie dlatego aby mieć chociaż jakąkolwiek sumę kontrolną, nawet XOR jest lepszy niż brak jakiejkolwiek kontroli poprawności odczytania danych ;-)

To chyba wszystko co chciałem napisać, w załączniku obrobione materiały (cas + hex).

ps1) ja pierniczę ... czy ktoś DDoS-uje serwer atari.area ??? Przecież wysłanie posta jest praktycznie niemożliwe ;/ bujam się z tym od dłuższego czasu i cały czas albo timeout, albo connection reset by peer. Za n-tym razem post się dodał bez załączników. No zobaczymy czy teraz się uda.

ps2) pierwotnie miałem napisane nieco więcej o problemie z whistler brother i dlaczego dodanie przerwy Ci działało, ale przez zrywanie połączenia i próbę publikacji postu kilkukrotnie straciłem zawartość tego co pisałem. Przepraszam, ale nie chce mi się pisać tego kolejny raz ;/

ps3) jeszcze jedno... do wczytywania używałem "LOADER 1" z carta "Super Cartridge" by Unerring Master (pozycja A z menu). Używając carta od "JotHa" należy wybrać loader "ATT v.2 (pozycja 5 z menu). Uścislając:

"LOADER 1" z Super Cartridge od UM to jest "Loader V2" z carta "JotHa"
"LOADER 2" z Super Cartridge od UM to jest "Loader V1" z carta "JotHa"

Różnica pomiędzy loaderami jest taka iż "LOADER 1" lokuje się bardzo nisko w pamięci ($100-$1B9, $3FD-$471), natomiast "LOADER 2" lokuje się pod OS-ROM ($CC00, $D800). Zatem jeżeli jakiś program będzie wykorzystywał pamięć pod OS-ROM w trakcie ładowania, to na pewno nie uda się go załadować z użyciem "LOADER 2".

ps4) Walcząc tymi plikami i testując je na EMU, przygotowałem również wersję obrazu carta "JotHa" automatycznie odłączającą się, gdy tylko wybierzemy typ carta "Phoenix 8k" przy podpinaniu obrazu do emulatora. Aby nie mnożyć bytów update w poście powyżej.

takron27 napisał/a:

btw. Seban, czy jest gdzieś dostępny przerobiony na xex cart 'AST multi cartridge' made by AS atari studio, który przed laty robiłeś replikę?

Tego się nie da tak prosto zrobić jak w przypadku innych cartów. AST-Multicart to dość rozbudowana konstrukcja, po odpaleniu instaluje on sobie handler urządzenia "Q:", z którego potem odpalane są poszczególne "pliki" zawarte w pamięci EPROM. Cart jest tak zrobiony że po wyłączeniu, tworzy sobie on "okno" z danymi, a właściwie sektorem pamięci EPROM mapowanym w obszarze $D500-$D5FF, także niby cart jest wyłączony ale można dostać się do dowolnej strony pamięci EPROM. Kiedyś zasadę działania opisałem w tym poście: AST Multicartridge.

Co do przeróbki na .XEX to trzeba by po prostu wszystkie te programy wydłubać z obrazu EPROM i napisać od nowa kod odpalający te wszystkie pozycje z menu z głównej pamięci komputera. Do zrobienia, ale czy to ma sens? tzn. czy istnieje taka potrzeba?

@lemiel: niestety chyba o tego Stanisława chodziło... miejsce się zgadza (Kraków), profil firmy by odpowiadał wcześniejszym hobby Stanisława, "mgr inż." też by pasowało ...

http://seban.pigwa.net/aa/turbo3200.png

@piguła: w przypadku "whistler brother" chyba wiem gdzie jest problem, ale rozwiązanie wrzucę niebawem o ile moje przypuszczenia się potwierdzą.

@takron27: no dokładnie tak, ten cart był opisany w tym poście: ATT/AST/UM Super Cartrige by Atrax

"zapodana" przeze mnie wersja .XEX jest o tyle inna że wygenerowana z jakiegoś mojego skrypto-automatu, który po drodze robi kilka rzeczy... tzn. podczas ładowania ustawia MEMTOP zgodnie z rozmiarem obrazu karta, zamyka i otwiera ponownie edytor ekranowy tak że Display List jest poniżej obrazu carta i nie zostanie "zadeptany" przez ładujący się obraz w obszar $A000-$BFFF, wyświetlany jest durny napis "Loading..." podczas wczytywania, to oczywiście nieistotny dodatek, i nie ma znaczenia dla posiadaczy AVG czy innych cartów... ale przy wczytywaniu z magnetofonu czy wolnej (19200 bps) stacji dysków... napis pewnie uda się zobaczyć... po załadowaniu kod "symuluje" odpalanie obrazu carta tak jak robi to OS, tzn. wywoływany jest wektor INIT a potem RUN.

Dla niektórych obrazów cartów może mieć to znaczenie, w przypadku akurat tego carta, to chyba akurat nie ma znaczenia. Plik .XEX dodałem bo jest generowany z automatu. W przypadku .XEX który zapodał piguła, jest to chyba goły obraz carta z dodanym segmentem RUN ($2E0) wskazującym na adres uruchomienia carta. A więc DL podczas odpalania .XEX-a od piguły zostanie "zadeptany", przez chwilę mogą pojawić się śmiecie na ekranie, ale poza tym nie będzie chyba innych skutków ubocznych.

Wybór należy do Ciebie, skoro .XEX udostępniony przez pigułę działa to nie powodu abyś musiał używać tego który ja zapodałem :)

struktura pliku .XEX w mojej wersji:

Input file is um_new_cart_JotHa.xex and the file size is 8297 bytes.

Header is: $ffff
block 001: $8000-$8052 ($0053)
block 002: $02e2-$02e3 ($0002) ---> INIT $8000
block 003: $a000-$bfff ($2000)
block 004: $02e0-$02e1 ($0002) --->  RUN $803e

File um_new_cart_JotHa.xex is OK!

Struktura pliku XEX w wersji od piguły:

Input file is New_Cart_AST_ATT_UM.xex and the file size is 8204 bytes.

Header is: $ffff
block 001: $a000-$bfff ($2000)
block 002: $02e0-$02e1 ($0002) --->  RUN $bf00

File New_Cart_AST_ATT_UM.xex is OK!

jak widać w przypadku mojej wersji dodatkowe procki siedzą w obszarze $8000-$8052, właśnie dlatego o tyle + dodatkowy segment INIT ten .XEX jest dłuższy.

I nie krytykuję tutaj roboty którą zrobił piguła, bo zrobił ją dobrze. Każdy po prostu ma inny styl i podejście, mogę zrobić "po swojemu", to robię, szczególnie że wypada z automatu (makefile) ;-)

Wrócę jeszcze na chwilę do cartridge dla systemu AST/ATT/UM który jakiś czas temu prezentował piguła w tym poście: "UM New Cartridge by UD/JotHa".

Tak się złożyło że taki sam cart wpadł w ręce uicr0Bee-iego i można było zweryfikować poprawność zawartości pamięci EPROM z dump-a od piguły, tzn. ustalić czy zawartość pamięci EPROM jest identyczna w obu przypadkach. Uicr0Bee dokonał zrzutu zawartości pamięci carta oraz wykonał parę zdjęć carta, dzięki temu mogę zaprezentować je poniżej.

Na początek zawartość pamięci EPROM znajduje się tutaj: UM new cart by UD/JotHa - EPROM dump

Przygotowałem także wersję XEX, którą  można pobrać  stąd: UM new cart by UD/JotHa - XEX file

dla identyfikacji/weryfikacji skrót SHA256 zawartości pamięci EPROM:

um_new_cart_JotHa.a000.bfff.bin SHA256: 6498d4a1a4c52ecb56f2f3a01dca8bd3dab2e60df89a0a055bca999020e2692e

EDIT:Przygotowałem też wersję obrazu cartridge z drobnym patche-em, można ją uruchomić pod emulatorem wybierając typ carta "Phoenix 8K", ten obraz carta wystartuje sam (odłączając się automatycznie poprzez zapis do $D500). Ten obraz można również wrzucić na cart typu "phoenix" i będzie on sam się odłączał na realnym sprzęcie. Obraz do pobrania tutaj: UM new cart by UD/JotHa (with CCTL patch).

Ale po co ja publikuję to wszystko jeszcze raz skoro dump wcześniej udostępnił piguła? Ano dlatego że okazało się że w pliku który wcześniej udostępnił piguła (.car) dodano nagłówek binarny (6 bajtów: $FF $FF $00 $A0 $FF $FF) i to by jeszcze nie było problemem, ale ostatni bajt pliku został uszkodzony (zastąpiony zerem) jako że był to starszy bajt adresu wektora INIT cartridge, to nawet po usunięciu nagłówka binarnego, taki plik nie uruchamiał się jako obraz carta np. pod emulatorem. Plik XEX uruchamiał się ponieważ adres uruchomienia ustalono na sztywno więc wektor INIT był pomijany.

Mając materiały udostępnione przez uicr0Bee-iego postanowiłem odkurzyć nieco temat i wyprostować zaległą sprawę :) Nie wiem czy pigłuła ten plik .car z Twojego posta robiłeś ręcznie czy jakimś narzędziem, jeżeli ręcznie to rozumiem że ręka mogła się omsknąć i ostatni bajt został nadpisany/skasowany, ale jeżeli używałeś jakiegoś narzędzia do konwersji BIN->Atari DOS file, to to narzędzie ma błąd i niszczy ostatni bajt pliku? A może oryginalny dump tak ma? tzn. ostatni bajt w pamięci EPROM ma wartość zero? Ale raczej gdy zawartość EPROM się uszkadza to tam pojawiają się dodatkowe "1" a nie zera, a u Ciebie w pliku jest $00 zamiast $BF. Co prawda wektor INIT i tak wskazuje na adres $BFF8 gdzie też znajduje się rozkaz RTS, więc to niewiele zmienia... ale teraz chociaż nie ma wątpliwości jak to powinno wyglądać :)

Reasumując... teraz mamy obraz carta z dwóch źródeł i z całą pewnością można powiedzieć iż zawartość pamięci EPROM w obu przypadkach jest identyczna (po naprawieniu ostatniego bajtu w obrazie) zawartość plików jest identyczna.

I na koniec fotki wykonane przez uicr0Bee-iego, sam cart prezentuje się tak:
http://seban.pigwa.net/uicr0bee/carts/um_new_cart_JotHa/photos/um_new_cart_JotHa.jpg

góra płytki drukowanej:
http://seban.pigwa.net/uicr0bee/carts/um_new_cart_JotHa/photos/um_new_cart_JotHa_PCB_top.jpg

dół płytki drukowanej:
http://seban.pigwa.net/uicr0bee/carts/um_new_cart_JotHa/photos/um_new_cart_JotHa_PCB_bot.jpg

ps) schematu carta nawet nie ma co rysować ponieważ jest to najprostszy cartridge o rozmiarze 8kB, lokujący się w przestrzeni $A000-$BFFF, mechanizm odłączania carta jest manualny, tzn. po starcie cartridge należy po prostu wyłączyć ów cart za pomocą przełącznika, gdy tylko na ekranie zobaczymy napis "CARTRIDGE OFF!".

@baktra: to całkiem możliwe iż jest to autor, znalazłem parę innych jego postów na różnych news-grupach, ale żaden z adresów e-mail nie wydaje się być aktualny.

Jestem w trakcie analizy tegoż systemu i niebawem podrzucę trochę więcej informacji na jego temat. Być może obędzie się bez konieczności poszukiwania pomocy u autora rozwiązania, niemniej jednak fajnie byłoby poznać historię powstanie tegoż systemu.

Na pewno wymagany jest dedykowany interface obsługujący tenże system, na pewno zmieniono częstotliwości kodujące 0 i 1. Po bardzo pobieżnej analizie wychodzi na to że wybrano częstotliwości 3,1KHz i 6,2KHz jako kodujące poszczególne stany logiczne. Przeprowadzę parę eksperymentów i dam znać czy udało mi się poprawnie zdekodować ten zapis. Może być też tak że dekoder/demodulator FSK zastosowany w tym systemie turbo nie był wrażliwy na taką odchyłkę częstotliwości kodujących od standardowych 3,9KHz i 5,3KHz ... to z kolei nasuwa myśl że demodulator FSK tego systemu nie był oparty o filtry paskowe, ale zapewne o jakiś dyskryminator częstotliwości czy też jakiś układ PLL.

Podział na rekordy w tym systemie pozostał, każdy program na również nadaną nazwę i wszystko wskazuje na to że każdy z rekordów zawiera nr bloku i nazwę. To bardzo wstępne ustalenia i dam znać jak tylko ustalę nieco więcej.

74

(90 odpowiedzi, napisanych Sprzęt - 8bit)

Dzięki WIELKIE! :D

tak na szybko... po pierwszym rzucie okiem... powiem Ci że trafiłeś perełkę :) To jest system turbo bardzo podobny do Turbo 2600, czyli bazuje na modulacji FSK, tylko zwiększa prędkość w/g informacji z czołówki do 3200bps, oczywiście wymagany jest specjalny dedykowany interface (demodulator FSK, który wyciągnie owe obiecane 3200 :)

Nie ma co prawda żadnej instrukcji i będe musiał się przegryźć przez kod aby zrozumieć jak wczytać programy zapisane w Turbo, bo domyślnie mogę wyświetlić nazwy lub nadać nazwę, o ile wyświetlanie nazw działa, to "nadanie nazwy" powoduje wysypanie się tego systemu, nie wiem co muszę zrobić aby rozpocząć wczytywanie w turbo. Jak mi się uda przez to przegryźć to dam znać oczywiście.

Z analizy nagrań wynika że system nie stosuje zapisu w długim bloku, a nadal jest wprowadzony podział na rekordy danych. Tak samo jak w przypadku Turbo 2600 system turbo lokuje się pod systemem operacyjnym. Nie wiem który z systemów powstał wcześniej, być może powstały niezależnie, a być może ktoś się kimś inspirował, na razie to tylko dywagacje, niczym nie potwierdzone... jak przyjrzę się kodowi systemu to może będę w stanie coś więcej powiedzieć.