Coś mi nie chce działać… ;)

Docelowo ma działać też na malinie, ale ta wersja jest na windę. 64-bitową, bo takim kompilatorem akurat skompilowana.  Wymagania spadną, po prostu kod pisany jak leci prawie bez optymalizacji. SID bierze 15% rdzenia @ 4 GHz :(

@Skrzyp: spróbuję skompilować toto także @ OpenSuse :)

Komuś ruszyło?

PS: Na OpenSuse nie ma lekko, chleb po 8 i bez maku. A konkretnie:

- wrośnięte w system pulseaudio robi kuku dla dźwięku. Przy żądanej liczbie sampli=480 zwraca w 'obtained' 240. No ale to jest akurat do ominięcia. Tylko trzeba wylistować drivery itd itp; pod windą chodzi na domyślnych. Próba unieruchomienia PA źle się kończy (brak dźwięku)

- grafika nie działa jak trzeba. Wyświetla się białe okienko. Żeby na nim pojawił się obraz, trzeba zminimalizować i przywrócić. Fullscreen zawiesza X. (ctrl-alt-f2 -> kill -9 project1). Coś nie tak z SDL2, albo po prostu trzeba zainstalować proprietary driver do nvidii.

- windowsowy kompilat startuje spod wine i działa wszystko za wyjątkiem dźwięku.

Szybciej pójdzie mi to na malinie, bo tam mam chodzącą całą tą retromaszynę i nie mam tylko SIDa. Ten SID natomiast nie da się skopiować żywcem do maliny, bo za wolno działa. Trzeba po prostu przetłumaczyć go na asm.

To nie jest mit. To real na malinie, testowany osobiście.

Pętla w fpc, -o1 - 30ns
Z optymalizacją -o3 - 15 ns
Szybki podgląd do wygenerowanego kodu - :(

asm, pierwsze podejście, 6  ns; po optymalizacji (ręcznej) ~4.5 ns

Te 4.5 ns na pętlę oznacza 11000 mikrosekund na ramkę. Mam 16667 mikrosekund.

Czyli kompilator= no way, asm - działa.

To samo będzie z tym sidem. Teraz mam 900 mikrosekund na 5-milisekundową ramkę. Na blaszaku. Malina (wersja 2) jest wolniejsza ~10 razy rdzeń do rdzenia od akurat tego blaszaka (testowane). Więc dostanę na pewno >5 milisekund; nie będzie miało szans zadziałać. W asm jestem w 100% pewny że wcisnę tego sida.

Apropos kompilatora i jego wydajniejszego kodu... to jest nowy mit, wynikający najprawdopodobniej stąd, że zanika sztuka programowania w asemblerze. Warto zdeasemblować i pooglądać co kompilatory generują. Na -o1 to jest katastrofa; -o3 lepiej, ale też ręce opadają. Kompilatory wydają się nic nie wiedzieć o przeplataniu rejestrów i tym podobnych arkanach czarnej asemblerowej magii :) która pozwala przyspieszyć  kod na przykład przez.. dodanie w jego środek nopa (tak... w 6502 to by była herezja:)   )

To błąd nie w pulseaudio, tylko taki misfeature w SDL-owym backendzie dla pulseaudio. Zawsze zwraca 2 razy mniejszy bufor niż zażądano. Walczyłem z tym w Atari800.

Można, ale spróbuj to zrobić w takim opensuse, żeby nie ucichł na zawsze i żeby połowa rzeczy nagle nie zaczęła krzyczeć, że wymaga pulseaudio. Da się, ale nie mam na to po prostu czasu. Chyba żeby postawić tę Zuzię na czysto i dopilnować żeby nie było tam PA od samego początku.

Starczy że raz niechcący zainstalowałem to na malinie razem z czymś innym. Potem to wyrzucałem, bo malina natychmiast przestała grać, a zaczęła skrzeczeć.  Apt-get purge niewiele dało, trzeba było jeszcze pracowicie poszukać plików konfiguracyjnych do których to coś się dopisało, ale się już samo nie odpisało, i wyrzucić ręcznie (sudo nano) jego wpisy.

------------------------
Z drugiej strony jak napiszę coś co ma działać pod współczesnym linuxem to muszę się dostosować: nie napiszę komuś ze ma się pozbyć PA z systemu.. :(

Grajka dostała 6502. A nawet "65032 (?)". Znalazłem gotowca pod nazwą Fake6502. http://rubbermallet.org/fake6502.c Napisany w C - nie mój język ojczysty - ale czytelnie. Przetłumaczyłem na pascala. Oryginał jest czystym 6502 z illegalami. Dopisałem instrukcje 65C02. Illegale pod x3,x7,xB i XF zostały :). Żeby zrobić z tego coś, co skorzysta z większej ilości RAMu, dodałem mu rejestry segmentowe. Są 32-bitowe, ea:=segment shl 8 + ea6502. Więc jest 40 bitów przestrzeni adresowej :). Instrukcje ldc, ldd, stc, std, phc, phd, plc, pld upakowałem ( z wyjątkiem jednej)  pod x2. Duża przestrzeń jest potrzebna jeśli to coś ma na przykład z poziomu 6502 grać "wszystko" (pliki .dmp mają na ogół  >64 KB)

W rezultacie grajka, oprócz plików .dmp ze zrzutami rejestrów SIDa gra teraz także pliki .sid. Póki co, PSID. RSID muszę jeszcze rozpracować. W następnej kolejności do obróbki pójdzie nasz ojczysty .sap. POKEYa muszę spreparować :).

Paczkę z nową wersją grajki wrzucę, jak zrobię w niej porządek. Bo zagrała prawidłowo 5 minut temu, wyświetla na ekranie mnóstwo info niezbędnego do debugowania zamiast tego co trzeba i wciąż nie porusza się po katalogach, co teraz stało się już niezbędne.

PS: ten 6502 działa na blaszaku z "częstotliwością" ~300 MHz. Około 70 milionów instrukcji na sekundę. Zapuściłem na malinie. Jak zwykle, 1:10, ~30 MHz, ~7 MIPS. Pod SID/SAP/co-tam-jeszcze-playera i 7 MIPS wystarczy :) Ale to nie jest czasowo optymalny kod. Za dużo wywołań funkcji.

Nieparzyste są zajęte przez 65C02. Zostało mi 7 miejsc. Dlatego jedną (pld) wpakowałem pod $44. Mam jeszcze parę nopów na rozszerzenia poza zakresem 3/7/B/F - 54, D4, F4 5C, DC, FC - póki co, robia NOP. Żeby było konsekwentnie, zdaje się nie obejdzie się też bez segmentu stosu. Tu push i pull nie ma sensu, trzeba zrobic ld i st. Poza tym chcę kiedyś zrobić instrukcje "g32/go8" - wszystkie opcody i adresowanie zostają bez zmian, tyle że A, X, Y, PC i SP dostają 32 bitów. Nic więcej nie chcę dodawać, to ma być nadal tak proste jak 6502.

PS: klawiszologia: strzałki w górę/dół - poruszanie się po liście, enter - wybór pliku/katalogu , 1-100 Hz, 2-200 Hz, 4-400 Hz, 3 - 150 Hz, 5-50 Hz, f1,f2,f3 - kanał 1..3 on/off,  p-pause/resume, esc - wyjście, i - raster interrupts :) , f - fullscreen on/off, +,- na klawiaturze numerycznej - zmienia subsong

Program prosi kartę dźwiękowa o 96 kHz/16 bitów.

Grajka zagrała na malinie. Tyle że: za pierwszym podejściem procedura się nie wyrabiała. Posiedziałem nad kodem, pooptymalizowałem, JEST! Wyrabia się w ramce. 19.5 milisekundy na 20. Na malinie trójce... Ta sama procedura na blaszaku - 600 mikrosekund...

Ten SID o tyle potrzebuje tej mocy, że po pierwsze działa 1:1, 985 kHz, a po drugie uprzestrzennilem mu wyjście, co spowodowało ze zamiast jednego filtra muszą być 3 niezależne dla każdego kanału, a na koniec mikser. Ale tez i kompilator fpc na ARMa daje mało optymalny kod. Pooglądałem go sobie...

Wylazły też inne kwiatki: kompilowany na platformę x64 kod "wytrzymał" obliczenia na 32-bitowych intach, których wyniki pośrednie nie mieściły się na 32 bitach. Po prostu natywny format jest 64-bitowy... błąd związany z przepełnieniem oczywiście natychmiast wyszedł na 32-bitowej malince.

19 milisekund na Raspberry Pi 3 oznaczało po prostu brak możliwości uruchomienia tej zabawki na malince dwójce. W tej sytuacji wyjścia nie było i  tak jak przewidywałem, w ruch poszedł asembler. Na pierwszy ogień do przepisania poszły filtry. Z 19 milisekund zrobiło się 13. Ciekaw jestem ile jeszcze urwę tych milisekund...

Jak już urwę tyle, że zagra na nie podkręcanej dwójce, wrzucę próbkę. Po czym spróbuje podpiąć do grajki także POKEYa, coby zagrała także nasze rodzime SAPy.

Czyli mniej więcej mocy 1 rdzenia maliny 2/3.

Ale moja emulacja nie jest też dokładna. Z zegarem 1:1 idą akumulatory fazy i generatory poszczególnych fal. Moduł ADSR tez jest 1:1 - działa co próbkę - ale jest tylko zgrubnym przybliżeniem tego, co robi prawdziwy SID (nie mówiąc już o ADSR Bug). Są filtry, ale tutaj to juz w ogóle są schody, bo nie ma dwóch takich samych sidów, więc filtry sa zrobione zgodnie ze specyfikacją: częstotliwośc ~=wartość rejestru*5.8 + 30. Nie ma póki co mozliwości odtwarzania sampli.

Jeśli chodzi o czas, najwięcej czasu da się chyba zaoszczędzić na module ADSR, zwłaszcza, jeśli się zrobi tak jak w SIDzie, czyli licznik inkrementowany co cykl i dane z tabelki.

Najwięcej w tym przypadku daje przejście na asm, bo kod który wychodzi z kompilatora jest kompletnie nieoptymalny. Jak piszę w asm to na przykład wiem jakie wyniki za chwile wykorzystam i trzymam je w rejestrach; raz ładuję do rejestru wskaźnik do struktury, a później dodaję tylko offsety. Albo wiem ze w tym konkretnym miejscu potrzebuję 64 bitów na wynik pośredni wiec wstawiam tam instrukcję smull  a potem koryguje wynik do 32 bitów zamiast deklarować zmienne jako int64. itd, itp.

Apropos FPGA, docelowo to tam pójdzie :) Zresztą, mam ja sida w swojej retromaszynie (temat retromaszyny jest tutaj: http://forums.parallax.com/discussion/1 … 80-enabled a tutaj http://www.par.pl/Archiwum/2015/2-2015/ … -Propeller jest artykuł )  na FPGA, ale tam za niego robi SIDCog na zaszyty w FPGA mikrokontroler Propeller. Od tego SIDCoga w ogóle zaczęło się moje zainteresowanie SIDem. Ten emulator działa tam na 44100 Hz, wraz z ewentualnymi aliasami. A robiąc własny emulator przynajmniej mogę zrozumieć, jak ten chip pracuje w środku, a bez tego nie ma mowy o własnej implementacji SIDa w FPGA.

Niech sobie ekspert woła. Przepisanie samych filtrów na asm urwało 6 milisekund z 19.