Którego kompilatora C używasz?
Nic mi nie wiadomo gotowych procedurach do muzyki do zawołania z C. Prawdopodobnie będzie trzeba dopisać z 5 linijek asemblera.
RMT łatwo przenieść w dowolne miejsce pamięci, z SAP będzie trudniej.
Czyli w skrócie: bierzesz RMT, ustawiasz mu adres ładowania (przy pomocy RMT lub asapconv), bierzesz player RMT w asemblerze i go kompilujesz.
Masz już własną procedurę VBLK? Muzykę zwykle odtwarza się na VBLK.

Nie zrozumiałem Twojej wypowiedzi. W każdym razie cały kod jest tu: https://github.com/pfusik/numen/blob/ma … /rubik.asx

Inny pomysł:

    opt f-
    org $A000
    opt f+

Kompilator C generuje kod na taki procesor, jaki mu się wskaże.

Ja pytałem, jak zwięźle pisać wspólny kod w asemblerze na różne procesory.

mads poprawiony, STZ wstawione wcześniej, czekanie na SPRSYS usunięte. Dodatkowo tryb adresowania pośredni nieideksowany. Sprawdzisz?

Dziękuję za wyczerpujące wyjaśnienie!

W upkr jest tylko mnożenie 8x8, więc znaki 16-bitowe są bez znaczenia. O akumulacji myślałem, ale najpierw chciałbym wiedzieć, czy działa bez niej. Poza tym niezależność od konfiguracji (znakowości i akumulacji) ma wiele zalet.

Zapis do A lepiej byłoby zrobić STZ, ale xasm nie ma, DTA nie chcę zaciemniać, a w mads blokuje mnie https://github.com/tebe6502/Mad-Assembler/issues/40 :)
Wtedy możnaby całe mnożenie wystartować przed aktualizacją "probs", czyli w trakcie mnożenia robimy 30 cykli potrzebnych operacji na 6502.

218 bajtów.

Opcja 305 bajtów kodu z akceleracją mnożenia dwukilobajtową tablicą. 133 ramki zamiast 214 na testowym obrazku.
Bonus: tę tablicę można potem wykorzystać do mnożenia bez znaku.

Edit:
I mnożenie na Lynxie. Uwaga, nie testowałem.

Uruchom z wiersza poleceń.

Kiedyś napiszę README (prawdziwy programista nie pisze dokumentacji ;)

236 bajtów na kod (może być w ROMie, nie modyfikuje się)
319 bajtów na bufor (najlepiej od granicy strony)
14 bajtów na stronie zerowej, z czego na początku standardowo wskaźniki na spakowane i gdzie rozpakować

Trochę wolne, ale analogicznie jak w Shrinklerze dam dopałkę mnożenia tablicą kwadratów jako opcję.

To wstępna wersja, mogą być błędy. I pewnie da się jeszcze nieco wycisnąć.

Fajnie, że paker ma taki tuning.

-9 = najwyższy stopień kompresji
-b = pobieranie wejścia po bicie, dzięki czemu mamy mnożenie 8x8, bez tego 12x8
--invert-continue-value-bit = oszczędza jeden bajt kodu depakowaczki, nie zmienia rozmiaru spakowanych danych
--simplified-prob-update = upraszcza pewien fragment dekodera, z tego co widzę kosztem kompresji niektórych danych słabszej o promile

Trochę to trwało, ale mamy rANS w wydaniu Upkr: http://www.atari.org.pl/forum/viewtopic … 04#p315204