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?

"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) ;-)

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

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

Hej!

Zgraj chociaż jedno nagranie, to będzie można przeanalizować. Nigdy tego systemu turbo nie widziałem, ale ja mało jeszcze widziałem :) tzn. mój wycinek wiedzy okazuje się dość mały, zawsze gdy myślę że nic nowego się nie pojawi to pokazujecie mi jakąś fajną niespodziankę! :D

Hej!

Loader o którym wspomina supaplex pochodzi z programu zgrywus+, a jego autorem jest JBW (Janusz B. Wiśniewski). Zgrywus+ jak i Turbo 2000 plus, znajdują się chociażby w pliku ATR (dyskietka zawierająca listingi z TA 4/93) który można sciągnąć z linku który podawał klopeks.

Za pomocą zgruwus+ można wygenerować zarówno plik .XEX jak i .BOOT, gdy wybierzemy generowanie pliku .BOOT zgrywus+ dołączy ów jedno-blokowy loader.

W "zamierzchłych czasach" każdy z nas (mówię jeszcze o czasach kiedy istniało Code3, XE-Team, etc.) każdy z koderów w ramach "sportu" pisał swój własny loader, odpowiednik koszmarnego "!"... ja w ramach grzebania w starych dyskietkach odkopałem swoją wersję i umieściłem ją na GitHub, można na nią rzucić okiem o tutaj: Code3 Tape Loader. Również zajmuje 1 rekord (128 bajtów). Do kompletu był jeszcze "Code3 Tape Copy", ale tego narzędzia na chwilę obecną nie namierzyłem w swoich archiwach, gdy się jakimś cudem napatoczy to oczywiście udostępnię.

ps) @klopex jeżeli chodzi o narzędzie operujące na plikach typu Atari DOS binary file, to swego czasu (gdy nie używało się jeszcze narzędzi tego typu na PC) ja używałem "Super Packer", obecnie wygodniej używać narzędzia uruchamianego na PC, może być to np. SuperPacker autorstwa TeBe-ego.

No i jest jeszcze DTX Manager autorstwa Baktra.

Dopiero teraz zrozumiałem o co Ci chodzi, tzn. o który plik i jak chcesz go wczytywać. W załączniku poprawiona wersja BOOT/XFD softu z paczki softu od blukiego która powinna się dać uruchomić za pomocą SIO2PC i AspeQT czy też RespeQT.

Sprawdziłem pod Linux/RespeQT i wygląda na to że działa, zakładam zatem że powinno ruszyć też pod Windows/AspeQT.

A jak wczytujesz wersję BOOT z dyskietki? Z tego co mi wiadomo żaden emulator nie potrafi wczytywać plików w formacie .BOOT, jest co prawda jeden sposób aby go oszukać jednak normalnie nie ma (albo nie znam) takiej możliwości.

Na realnym sprzęcie plik BOOT trzeba by nagrać sektorami na dyskietkę w gęstości Single lub Enchanced, a jeżeli bootujesz się z jakiegoś SIO2PC, SIO2SD to trzeba by stworzyć plik ATR w którym należałoby umieścić zawartość pliku również w pierwszych sektorach dyskietki, ale nie jako plik wewnątrz ATR-a tylko nagrać to sektorami lub po prostu używać wersji .XEX i jakiegoś inicjalizera/loadera (np. chaos loader)  czy nawet DOS-a z pod którego należałoby wczytać plik .xex

Hej!

Często wbudowane karty dźwiękowe mają sterowniki które domyślnie mają włączone różne "polepszacze" dźwięku, a to "3d sound", a to "srs", a to "spatial sound", albo jakieś dziwne korekcje czy ustawienia software-owego EQ. To oczywiście ma wpływ (destrukcyjny) na wszystkie generowane pliki audio zawierające dane, bo przejście przez taki sterownik czy tam wbudowane w układ DSP powoduje zniekształcenie tegoż sygnału... prawdę mówiąc nie pomyślałem o tym ja również kiedyś dawno temu się na to nadziałem, nie pamiętam marki/prodycenta laptopa ale miał wbudowany dość popularny chip od RealTek do dźwięku i było w nim domyślnie ustawione jakieś "przestrzenne poszerzanie" (czytaj psucie) dźwięku, było to na tyle dawno temu że dopiero jak opisałeś powyżej swój problem to mi się przypomniało że taka sytuacja miała miejsce.

W moim wypadku wtedy pomogło wyłączenie tych wszystkich niby "polepszaczy" dźwieku w ustawieniach sterownika karty dźwiekowej.

EDIT:

Sprawdziłem na jakimś "nowoczesnym złomie" z chipem RealTek na pokładzie i Windows 11 i być może trudno uwierzyć ale owe "polepszacze" dźwięku nadal tam są ;-) Da się to oczywiście wyłączyć, domyślnie było oczywiście włączone.

@klopeks: z jakim poziomem nagrywasz sygnał na kasetę docelową? dodam tylko że w moim przypadku działają nagrania z poziomami np. 0dB, -1dB, -3dB. Chociaż mam wrażenie że mojemu staremu XC12 bardziej odpowiadają nagrania nieco poniżej 0dB. No i jeszcze jedna sprawa, na którym kanale nagrywasz dane? Normalnie powinien być to kanał prawy, ale nagranie na obu kanałach L,R też nie będzie powodowało problemów. Natomiast nagrania na kanale lewym jest błędem, bo ten kanał jest tylko odtwarzany jako ścieżka audio.

Kolejną sprawą może być kwestia ustawienia głowicy w magnetofonie na którym próbujesz wczytać grę. Zakładam że magnetofon na którym nagrywasz ma fabrycznie ustawioną głowicę.

o dzięki Vidol! Jesteś Wielki! Bo ja już zacząłem deasemblację procedury dekompresującej zawartej w "Miecze Valdgira II", oszczędziłeś mi sporo czasu! Dzięki! :) Nie ma to jak oryginalne źródło z komentarzami autora ;) Jeszcze raz dzięki!

sprawdziłem dwie gry losowo, tzn. "5 wygrywa" oraz "wisielec", metodą którą opisałem (LOAD, LIST, NEW, ENTER, SAVE". Wygląda na to że działają. Dodaję w załączniku. Dodatkowo do "piątka wygrywa" dodałem brakujący zestaw znaków, którego gra oczekiwała pod adresem $8000.

Sądzę że resztę plików można również ogarnąć w taki sposób. Ale to już polecam zainteresowanym tematem :)