Konwersja muzyki z CPC na ZX

[trojacek]

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.

[Abrimaal]

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)?

[trojacek]

OTI, OTIR, OTDR...?

[Abrimaal]

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.

[ZbyniuR]

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.

[ZbyniuR]

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.

[Abrimaal]

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.

[ZbyniuR]

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.

[Abrimaal]

Uhhh... to ja już teraz wiem, dlaczego tak niewiele muzyki jest wyciągnięte z gier na CPC 

[matofesi]

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

[ZbyniuR]

Podałem już wyżej ten adres.   Przełączenie banku to nie procedura a jeden OUT.
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.

[matofesi]

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ą