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.

@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:

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:

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:

gdzieś w tej kamienicy znajdowało się owe studio komputerowe :) Może ktoś coś kojarzy i pamięta:

@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.

@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 ...

@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

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:

góra płytki drukowanej:

dół płytki drukowanej:

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!".

Dzięki WIELKIE! :D

Hej!

Próbowałem wczoraj ściągnąć pierwszy udostępniony plik, ale miałem "odmowa dostępu", tzn. wyskoczyło okno "z prośbą o udzielenie dostępu", niby wysłałem ale nadal nie mogę ściągnąć nawet pierwszego pliku.

Cześć!

Jest szansa że niebawem uda mi się wrócić do tematu. Obecnie za dużo rzeczy się dzieje na raz abym mógł ogarnąć czasowo i ten temat. Ale pamiętam o nim i jak tylko czas pozwoli to na pewno znowu podziałam w tym temacie.

włączenie silnika magnetofonu:

POKE 54018,52

wyłączenie silnika magnetofonu:

POKE 54018,60

właśnie pisząc "o sposobie" miałem na myśli podmianę rozszerzenia na XFD. Tak własnie testowałem pod Altirra.

kurczę faktycznie! teraz sprawdziłem i działa ... nie wiem co robiłem nie tak ale wcześniej miałem komunikat o niemożności załadowania tegoż pliku ("can't load "t2k1.boot"). Nie wiem co było nie tak, dziś ruszyło "od ręki" (Atari800 v. 5.0.0 / Debian). Być może problemem był "shared folder" "podmontowany" via NFS, a dziś odpaliłem lokalnie i po prostu ruszyło. Dzięki za naprowadzenie, bo byłem przekonany że Atari800 plików BOOT nie uruchamia.

Cześć!

Dobra, to może po kolei... co prawda mi się wydawało że już kiedyś to robiłem, ale usiadłem do tego jeszcze raz nie mając czasu na przeglądanie "starych śmieci" ;-) ... w załączniku dodaję zatem wersje plikowe tego carta (Turbo 2001 + Universal Copy II) w formatach BOOT, XEX oraz plik CAS który można nagrać na kasetę i potem wczytać sobie bootując komputer z kasety (OPTION + START).

Ta wersja Turbo 2001 lokuje się pod systemem operacyjnym ma niby MEMLO na poziomie $800, ale cokolwiek się będzie chciało załadować pod OS-ROM ($C000-$CFFF, $D800-$FFFF) zniszczy system turbo tam umieszczony i spowoduje totalny zwis podczas ładowania się takiego programu. Zatem np. wszystkie programy spakowane Cruncherem 5.0 Magnusa, Code3 Cruncherem czy też inne programy umieszczające się pod OS-ROM w trakcie ładowania nie wczytają się z użyciem tejże wersji systemu.

Na razie wrzucam tylko pliki wynikowe, źródła pokazujące "jak to zostało zrobione" mogę oczywiście udostępnić, ale to chyba mało kogo interesuje. Gdy już zrobiłem tę wersję, jak się okazało po raz drugi... zacząłem przeglądać ten mega wątek o systemach turbo i oczywiście okazało się że dobrze mi się wydawało że to już robiłem... dokładnie w tym poście: Turbo 2001 + copy. Ale nie ma tego złego coby na dobre nie wyszło, ponieważ wtedy zrobiłem tylko wersję .XEX, teraz macie do dyspozycji wersję BOOT czy gotowe rozwiązanie w postaci pliku CAS.

Wrócę jeszcze do lokowanie się tej wersji Turbo 2001 pod OS-ROM, dla starych gier, które to nie były w żaden sposób kompresowane, czy też nie ładowały swoich segmentów danych pod OS-ROM to rozwiązanie będzie oczywiście w porządku, jednak dla większości nowszych produkcji będzie to oczywiście problem... ale dla takich przypadków polecam wersję Turbo 2001 lokującą się w obszarze $0700-$199C, zatem MEMLO wynosi $199D. Jak widać sporo wyżej, ale należy pamiętać że Turbo 2000F, KSO Turbo 2000, wymagają 3kB bufora od rekord odczytany z taśmy. Z tą wersją będą działać zatem wszystkie gry które ładują się powyżej adresu $199C, także takie które ładują się pod OS-ROM lub zajmują ten obszar podczas ładowania. Wersja dla cartridge w tym poście: Turbo 2001 v.2.1, natomiast wersja BOOT (wystarczy nagrać na kasetę) znajduje się w arch. Bluki-ego pod nazwą: "T2001C'.

ale przecież zawsze można przez pomyłkę zamienić kable łączące kartę dźwiękową magnetofonem, lub podłączyć sygnał tylko do jednego wejścia (REC-IN) w magnetofonie... możliwości pomyłki są, wspominam o tym tylko po to aby się upewnić że wszystko jest dobrze podpięte i skonfigurowane.