forum speccy.pl
Komputery z Z80 => AMSTRAD => Wątek zaczęty przez: Abrimaal w 2013.02.01, 20:51:25
-
Mam wiele utworów w formacie .ay/.ym wyciągniętych z gier i dem na CPC.
Gdy robiłem trainer do Dark Fusion, to podesłałem Matofesi'emu muzykę z tej gry z Amstrada wcześniej potraktowaną AYSplitter, który "rozbiera" plik .ay (do odtwarzania na PC itp.) zostawiając czysty kod dla Z80
(usuwa nagłówki - autor, tytuł, info o sprzęcie i inne extra dane dla PC).
Mat przerobił kod pliku tak, że utwór gra na ZX, ale jeszcze trochę za wysoko.
Więcej o tym jest tutaj: http://speccy.pl/forum/index.php/topic,322.msg4854.html#msg4854
a tutaj jeszcze więcej (dodano 2013-02-03): http://speccy.pl/forum/index.php/topic,335.30.html
Z pewnością da się dokładnie przekonvertować, bo słyszałem to już w demo z przełomu lat 80/90
Kassoft (chyba) wyciągnął z CPC muzykę z Great Gurianos i wrzucił ją do demo na ZX.
Czy istnieje jakaś aplikacja, która podmienia dane dotyczące wysokości dźwięku w gotowym kodzie z CPC na ZX?
AYSplittr w załączniku. uruchamia się go z pliku .bat, w który wpisuje się nazwę pliku .ay lub .ym, plik ten powinien być w tym samym folderze co aplikacja.
Do tego jest jeszcze AYMaker, który działa odwrotnie, z pliku binarnego robi plik .ay
Jednak żaden nie ma opcji "dostrojenia" zegara AY.
-
Dokładnie nigdy nie będzie - oba AYgreki są taktowane różnymi częstotliwościami i nie ma fizycznie możliwości, żeby grały tak samo. Można się pokusić o zrobienie przybliżonej tablicy translacji częstotliwości a potem hackować każdą muzyczkę z osobna tak, żeby zamiast do rejestrów pisała gdzieś do pamięci a wynik tego był pransponowany wg tablicy i po transpozycji wysyłany do rejestrów. Możnaby się pokusić o zrobienie automatu do tego, ale automat musiałby robić analizę kodu albo mieć zaszyte wszystkie (albo przynajmniej jak najwięcej) metod zapisu do AYgreka na CPC - miałem kiedyś coś podobnego, choć znacznie prostszego - progrmik modyfikujący kod tak, żeby muzyczki z ZXS128 grały na Unipolbricie. Całość działała w mniej więcej 95 procentach przypadków, ale te brakujące 5, których nie udało mi się przerobić mnie zniechęciły i przerobiłem po prostu Unipolbrita.
Podsumowując - powodzenia ;) Jednostkowo mógłbym się pobawić, ale na pewno nie szarpnę się na rozwiązanie kompleksowe.
-
Co to znaczy że na ZX grają za wysoko i że nie są tak samo taktowane? - Czyli jak?
Obiło mi się kiedyś o uszy że te nowsze Amstradowe ZX-y mają procki na 4MHz a nie na 3,5 jak te starsze. Czy dobrze mówię, czy to jakoś inaczej jest?
-
Koledze chodzi o kwarc taktujacy AY a nie procesor Z80.
-
Mhm, nie miałem pojęcia że AY ma osobny kwarc.
-
AY w Amstradzie chodzi na 1MHz, a na Spectrum około 1.77, czyli połowa zegara Z80. Z kolei na Atari ST chip jest taktowany 2MHz. Nie wiem jak to się przekłada na skalę (ilość oktaw i zakres częstotliwości generowanego dźwięku), ale jeśli Amstrad gra niżej, to chyba można z niego wydobyć niższe dźwięki niż na ZX (?)
-
Mozna sprobowac zaszalec i dorobic programowanie/przestrajanie czestotliwosci w AY :)
EDIT: mam na myśli przestrajanie hardware'owe :)
-
@Abrimaal wpisz w google'a "AY-3-8910 datasheet" - o ile pamiętam są tam podane dokładne parametry (i chyba wzory) częstotliwości dźwięku (zakres, krok itp.) w zależności od częstotliwości taktowania.
-
Na Winampie z każdego z tych komputerów chodzą dobrze. ;)
-
Rozumiem, że masz na myśli odgrywanie muzyczek z plików AY w windowsowym playerze? To oznacza wyłącznie tyle, że używany przez player emulator dostaje informacje o tym jakie ma ustawić parametry AYgreka, które player zgaduje - prawdopodobnie na podstawie informacji o adresach rejestrów, bo nie jest to zapisane w pliku AY - i odgrywa muzykę na AYgreku ustawionym zgodnie z potrzebnymi parametrami. Co nie zmienia faktu, że próba przenoszenia takich muzyczek między fizycznymi komputerami po prostu nie zadziała a przy konwersji nie wystarczy zmienić obsługi portów.
-
Ja osobiście odradzam słuchanie muzyki z 8bitowych kompów na Winamp'ie.
Jest do tego bardziej fachowe oprogramowanie.
Dla utworów z ZX/CPC/ST to jest AY emulator - najlepszy player z możliwością dostrajania wszelkich parametrów -
głośności poszczególnych kanałów, panning (ABC, ACB, mono itp.), częstotliwości CPU i AY,
wyboru chipa (AY 3-891X lub YM 2149F). Można w nim również zapisać wybrany utwór jako .wav
Bardzo dobrze radzi sobie również z utworami na beeper.
Potrafi także szukać (i większość znajduje!) muzyki w grach i demach (o ile nie są skompresowane czy zakodowane)
i ektrahować je do plików .ay
http://bulba.untergrund.net/emulator_e.htm
Przy okazji podam jeszcze linki do najlepszego playera SID (Sidplay 2.5)
http://www.adventurekid.se/sidplay-2-5-c64-music-player-for-pc-and-mac/
i SAP (ASAP)
http://asap.sourceforge.net/
Ja natomiast poszukuję dobrego playera plików .nsf (z Nintendo NES), odtwarza je wprawdzie Audio Overload,
ale mam chyba jakąś niekompatybilną ze swoim systemem versję, która gra tylko pierwszy utwór jeśli w pliku jest więcej.
-
A ja podłubałem chwilę i zrobiłem arkusz, w którym widać wyraźnie jakim problemem jest konwersja muzyki z CPC do Spectrum (plik ODS dla open/libre-office'a w zipie w załączniku).
W pierwszej kolumnie jest wartość zapisywana do rejestru regulującego częstotliwość (12 bitów od 1 do 4095). W drugiej i trzeciej są częstotliwości wynikowe zależnie od zegara (podanego w MHz w drugim wierszu). W trzeciej jest formuła przeliczająca (oczywiście w przybliżeniu) jaka wartość częstotliwości przy zegarze Spectrum daje odpowiednik częstotliwości CPC. Czwarta to faktyczna częstotliwość z jaką będzie grał AY na Spectrum a piąta to różnica częstotliwości między CPC A Spectrum. Dodatkowo formuły mają włączone kolorowanie komórek powyżej wartości 4095, żeby było widać w którym momencie kończy się skala na Spectrum.
Do poprawnej konwersji trzeba by dodać stosowną tablicę przekodowującą wartości z kolumny 1 na te z kolumny 4 i modyfikować wartości przed wysłaniem do rejestrów. Podobnie trzeba by zrobić z częstotliwością szumu i okres obwiedni - tablice trzeba by zmontować analogicznie jak główne częstotliwości.
Problemem nie jest zakres częstotliwości (przynajmniej dla tonów), bo punkt graniczny CPC;2314, ZXS: 4095 to częstotliwość ~27 Hz i raczej w wypadku muzyki częstotliwość poniżej tego punktu ma średnie zastosowanie. Jedyny problem to najwyższe częstotliwości - tam różnica między uzyskanymi częstotliwościami jest największa i jeśli muzyczka na CPC używa takich częstotliwości, to będzie bardzo fałszować. Trochę niżej różnice przestają być już takie duże, ale mimo wszystko przy maszynowej konwersji idealnie nie będzie nigdy - muzyczkę należałoby po prostu przepisać na ZXS, żeby brzmiała dobrze ;)
-
Na jakich portach chodzi AY w Amstradzie?
-
http://www.cpcwiki.eu/index.php/How_to_access_the_PSG_via_PPI
-
hmm, skomplikowane ::) a nie da się bezpośrednio przez OUT, jak w Spectrum? Jeden port to wybór rejestru AY, a drugi zapis do niego?
-
AFAIK nie da się. Po prostu AY jest podłączony nie na szynę procesora, tylko do jednego z portów układu 8255. Fizyki się nie przeskoczy.
-
Nieciekawa sprawa. Włączyłem w emulatorze Win Ape pierwszą lepszą grę z muzyką (Flying Shark),
wyszukałem w debuggerze wszystkie OUT (C),reg i OUT (port),reg za pomocą szablonu szukania OUT (*),?
wstawiłem tam breakpointy, a muzyka dalej grała.
Czy CPC może wysyłać dane do AY za pomocą innych instrukcji? (np. LD)?
-
OTI, OTIR, OTDR...?
-
Też prawda, ale nie ma tego. Nie znam architektury CPC, przeglądnąłem tylko główny RAM, może muzyka umieszczona jest w dodatkowym banku. Ja bardziej miałem na myśli czy CPC może ma jakiś obszar "zmiennych" dla AY, gdzie zapisuje dane przez LD.
Na zasadzie analogii do C64, w którym (podobno - też znam ze słyszenia) dane dla SID można podać w Basic przez POKE.
-
Nie jestem specem od muzy ani bebechów ale z tego co czytałem to w CPC procek nie ma bezpośredniego połączenia z AY a jedynie za pośrednictwem scalaka zwanego PPI (a czasem PIO). Gdzieś czytałem że Basic w CPC ma wszelkie komendy jakie potrzeba do pełnej obsługi dźwięku z wyjątkiem digitalizowanych sampli, bo to wymaga tak częstych modyfikacji portów że Basic nie daje rady. Z tego co gdzieś czytałem komenda OUT to jedyna furtka by się dobrać do rejestrów AYa z tej tabelki http://cpcwiki.eu/index.php/Default_I/O_Port_Summary wynika że do PSG (tak zwą tam układ dźwiękowy) obsługuje się przez porty:
#F4XX %xxxx0x00 xxxxxxxx 8255 PIO Port A (PSG Data) Read Write
#F5XX %xxxx0x01 xxxxxxxx 8255 PIO Port B (Vsync,PrnBusy,Tape,etc.) Read -
#F6XX %xxxx0x10 xxxxxxxx 8255 PIO Port C (KeybRow,Tape,PSG Control) - Write
#F7XX %xxxx0x11 xxxxxxxx 8255 PIO Control-Register - Write
Czyli w Basicu to by było OUT &F600,parametr:OUT &F400,parametr problem w tym że nie wiem jakie parametry a pewnie każdy bit ma jakieś znaczenie, bo tylko przez te dwa porty w PPI czyli port A i C ma się dostęp do 16 rejestrów w AYu. Tyle że zdaje się że port &F7 decyduje o tym czym sterują te porty A i C bo mogą też klawiaturą drukarką lub magnetofonem. A może raczej konkretne bity w tym parametrze wpływają na konkretne z tych urządzeń. Co sugeruje ta tabelka http://cpcwiki.eu/index.php/8255#PPI_Port_C
Tak szczerze nigdy wcześniej się tym nie interesowałem i nie mam cierpliwości by się wczytywać głębiej.
Tu jest o tym coś więcej http://cpcwiki.eu/index.php/How_to_access_the_PSG_via_PPI a w podanym przykładzie w assemblerze też używają OUT &F4 / &F6 i &F7 ale jestem za cienki by to pojąć.
Gdzieś tu przed chwilą czytałem że emulatory PLUSa nie w pełni obsługują te porty jak powinny bo nie ma pełnej dokumentacji do ich bebechów.
Nie wiem co tam kombinujesz, ale jeśli muza gra na przerwaniach to wpisywanie czegoś w te rejestry zatrzyma tylko aktualny dźwięk a za chwile program włączy kolejny. A program z przerwania może być w innym miejscu niż ten główny. Zarówno Basic jak i Assembler mają komendę DI do pauzowania przerwań. Jeśli to jej nie zatrzyma to ja już nie wiem.
Tu też jest coś o programowaniu AYa http://cpcwiki.eu/index.php/AY-3-8912 ale póki się nie zna właściwych parametrów do tego powyżej to się nie przyda.
A może zamiast pisać własny kod wystarczy skorzystać z gotowych procedur w ROMie. Coś o tych procedurach dotyczących dźwięku jest też w opisie kernela w Bajtku 10-87 s14, oraz w 11/12-90 s26. By z nich skorzystać w Basicu piszemy CALL adres_w_tablicy_skoków i ewentualnie po przecinku podajemy parametry jak w opisie procedury, a w kodzie parametry wrzucamy do podanych w opisie rejestrów a potem CALL. Te adresy w tablicy zwykle się zaczynają od &BC... :)
Mam nadzieję że nie namieszałem tylko podsunąłem ci jakiś trop. Jak coś złego to nie ja. ;)
-
POKE-ami muzykę? Hmm, zgaduję że raczej chodziło o jakąś binarkę z linii DATA która włączała brzęczadło, bo pojedynczy POKE tworzący dźwięk to by oznaczało, że cały czas na przerwaniach działa jakiś odtwarzacz i jakieś komórki są czytane i wystarczy tam coś podrzucić by się odezwał. Choć widziałem coś takiego na XE, bo mają w ROMie przygotowane parę dźwięków typu: wystrzał, syrena, pisk opon itp. i można je włączyć paroma POKEami. W CPC co najwyżej gdy w tle gra muza która korzysta z procedur kernela to wpisując &C9 czyli RET w adres skoku można by ją uciszyć mimo że podprogram odtwarzający cały czas chodzi.
Z tego co czytałem to w ZX często muza chodzi tylko jak się ma ekstra RAM (więcej niż 48K), podobne rzeczy spotykałem w Amigach, ale w CPC muza to standard który ma działać na 64K. Jedyny znany mi wyjątek to Digitracker, ale jego modułki mają po kilkadziesiąt KB a nie po kilka. Choć nie wykluczam że istnieje jakaś gra w której muza gra z ramdysku. Uruchom tą grę na emulowanym 464 bez dodatkowej pamięci to się okaże. ;)
-
A może zamiast pisać własny kod wystarczy skorzystać z gotowych procedur w ROMie. Coś o tych procedurach dotyczących dźwięku jest też w opisie kernela w Bajtku 10-87 s14, oraz w 11/12-90 s26. By z nich skorzystać w Basicu piszemy CALL adres_w_tablicy_skoków i ewentualnie po przecinku podajemy parametry jak w opisie procedury, a w kodzie parametry wrzucamy do podanych w opisie rejestrów a potem CALL. Te adresy w tablicy zwykle się zaczynają od &BC... :)
Mam nadzieję że nie namieszałem tylko podsunąłem ci jakiś trop. Jak coś złego to nie ja. ;)
I tu może być pies pogrzebany. Dostęp do ROM też wymaga jakiegoś przełączania pamięci, jeśli RAM zajmuje całe 64k.
-
Gate Array przełącza bloki pamięci pomiędzy taktami procesora więc nie da się tego zauważyć.
http://speccy.pl/forum/index.php/topic,844.msg14502.html#msg14502
Tablica skoków zawsze jest w bloku który zawsze jest pod tym samym adresem, a procedury są tak rozmieszczone w obu podstawowych romach by w odpowiedniej chwili był podłączony akurat ten którego procedury robią coś w innym rejonie pamięci niż zajmuje podłączony w danej chwili ROM. Dlatego korzystając z kernela poprzez tablicę skoków wogóle nie trzeba się martwić tym przełączaniem. Nawet nie trzeba wiedzieć w którym ROMie jest ta procedura. :)
-
Uhhh... to ja już teraz wiem, dlaczego tak niewiele muzyki jest wyciągnięte z gier na CPC :(
-
A może zamiast gdybać i kombinować zajrzelibyście do CPC Wiki... http://www.cpcwiki.eu/index.php/How_to_access_the_PSG_via_PPI
Tam jest przykład jak się pisze do rejestrów AYgreka - robi się to za pośrednictwem PPI a nie jak w ZXach stąd procedury grające muzykę wyglądają trochę inaczej i trochę inaczej trzeba się zabierać do ich szukania.
Choć akurat jeśli breakpointy na OUT (*),* się nie zatrzymują to prawie na pewno coś przeoczyłeś - prawdopodobnie jakieś bankowanie albo coś podobnego.
A prawdopodobieństwo, że gra na ośmiobitówkę będzie używała ROMowych procedur do przełączania banków, grania muzyki czy czegokolwiek poza wysokopoziomowym I/O jest moim zdaniem wysoce zbliżone do zera ;)
-
Podałem już wyżej ten adres. :) Przełączenie banku to nie procedura a jeden OUT. :D
Znam tylko jeden przykład procedury odtwarzającej muzykę w podstawowym ROMie - komenda PLAY w ZX+2+3. Ale do odtwarzania pojedynczych dźwięków to chyba tylko C64 nie ma. Zresztą po to one tam są by z nich korzystać, co bardzo skraca program oraz czas potrzebny na jego napisanie. Czas jak wiemy to pieniądz. A RAM też trzeba oszczędzać. Pamięć ekranu w CPC to aż 1/4 podstawowej pamięci. Każda grafika ma 2 bity na piksel czyli dwa razy tyle co w ZX w zbliżonej rozdzielczości. Kilka KB zajmują zmienne, systemowe tablica skoków oraz bufor stacji dysków, bo stacja w CPC nie ma własnej pamięci. A i zawartość ROMów w CPC ma lepszą opinię niż ta w ZX. Dlatego powiedziałbym że stosowanie procedur z ROMu jest wręcz nagminne. :)
Jedynie te do wyświetlania tekstu i rysowania linii mają opinię wolnych i krążą po dyskach ich zamienniki. :)
-
Dlatego powiedziałbym że stosowanie procedur z ROMu jest wręcz nagminne. :)
Na prawdę? To by tłumaczyło dlaczego gry na CPC są takie jakie są :P ;)