Tak, chodzi o liczbę użytych kanałów POKEYa, czyli mono czy stereo.
Niestety z kawałkami mono TMC, jest problem, mono. ;)
Mianowicie zdarzają się takie, które grają tylko na lewym POKEYu, a na prawym cisza. O ile ktoś ma stereo, to ok. Gorzej, gdy ktoś ma jednego POKEYa, wtedy do niego trafiają wartości przeznaczone dla obu POKEYów i jest kiszka. Miker poprawiał wiele takich kawałków w ASMA, uderz do niego po przykład.

Właśnie nie mam. :) Opierałem się wyłącznie na programie Jagera (jakiś commander), który miał napisane, że obsługuje MPD.
Co to jest subtempo?

Z ogonkami?

Poszukuję teraz przykładowych plików z Falcona: DuneGraph (*.DGU), EggPaint (*.TRP) i IndyPaint (*.TRU). :)

Ciągnący się w tym (i nie tylko tym) wątku flame war sprowadza się do pytania "czy to jeszcze jest Atari" ?

Przygotowując grę na WAP-NIAK mogłem napisać ją tak, aby Pin był zadowolony (powrót do Sparta DOS X) lub zapewnić maksymalną zgodność z fabrycznie produkowanymi komputerami Atari (w tym 400/800 z 48 KB RAM). Wybrałem to drugie, bo dla mnie to jest bardziej Atari, niż maszyna z wymienionym procesorem i chipem graficznym, które mają zajebiste możliwości, ale nie mają oprogramowania, które je wykorzystuje.

Doceniam zapał elektroników do wymyślania rozszerzeń, ale jeśli potrzebuję wypasioną grafikę i procesor, to wyciągam z kieszeni Androida. Co do nabywców rozszerzeń: nikt Wam nie każe ich zakładać, a jeśli dobrowolnie sami zakładacie, to liczcie się z konsekwencjami - niektóre produkcje nie będą działać. A jeśli chcecie, żeby działały, to poproście autorów, tj. "szanowny XXLu, czy znalazłbyś czas, aby..." zamiast "ty głupi XXLu, jak dolutowałem Pentium 4 i GeForce to Twoja gra przestała działać, nie umiesz programować Atari".

HIP, TIP, 9++, 480i i ostatnio tryb Pavrosa to tak samo nieudokumentowane i nielegalne wynalazki, jak te instrukcje 6502. Powiem więcej - opcode-y 6502 są znacznie lepiej udokumentowane, niż te tryby graficzne, jak również są dłużej stosowane (chociażby wspomniany Alley Cat).

Popatrzmy na inne platformy. Scena C64 trzyma się mocno, bo tam nie ma wyścigu w tuningu sprzętu. Na Amidze, Falconie i ZX Spectrum prawdopodobnie dużo energii zużywa się na flejmy takie jak ten.

To dowodzi Twojej ignorancji w tym temacie. Rozkazy są określane jako niestabilne dlatego, że przy niektórych wartościach argumentów dają niepewne wyniki. Przy innych argumentach wyniki są całkowicie przewidywalne, co wielokrotnie było potwierdzane wyczerpującymi testami jak również teorią.

Rzeczywiście przykład nie był praktyczny. Dodatkowo anx jest wg niektórych źródeł niestabilny, a można go tu zastąpić lda #0. Można też pójść w przeciwnym kierunku i użyć nielegalnego opcodu sbc. ;)

Zmniejszenie słowa 16-bitowego:

Standardowo:

 lda word
 sne:dec word+1
 dec word
; abs: 11 bajtów, 13/18 cykli
; zp: 8 bajtów, 11/15 cykli

Nieudokumentowane:

 lda #$ff
 dcm word
 sne:dec word+1
; abs: 10 bajtów, 11/16 cykli
; zp: 8 bajtów, 10/14 cykli

Wartość $ff możemy mieć przypadkiem przed operacją lub potrzebną po operacji - wtedy zyskujemy więcej.

65816:

 rep #$20
 dec word
 sep #$20
; abs: 7 bajtów, 14 cykli (? - proszę o potwierdzenie)
; zp: 6 bajtów, 13 cykli (?)

Zmniejszenie słowa 24-bitowego:

Standardowo:

 lda word
 bne lo
 lda word+1
 sne:dec word+2
 dec word+1
lo dec word

Nieudokumentowane:

 lda #$ff
 dcm word
 bne lo
 dcm word+1
 sne:dec word+2
lo

Zmniejszenie słowa N-bajtowego:

Standardowo:

 ldx #0
 clc
loop lda #$ff
 adc:sta word,x
 bcs exit
 inx
 cpx #N
 bcc loop
 exit

Nieudokumentowane:

 lda #$ff
 tax
loop inx
 dcm word,x
 bne exit
 cpx #N
 bcc loop
exit

Zmniejszenie cyfry ASCII / kod ANTIC (np. liczba żyć w grze):

Standardowo:

 dec:lda lives
 cmp #'0'
 beq gameover

Nieudokumentowane:

 lda #'0'
 dcm lives
 beq gameover

@tebe: akurat nielegale potrafią zapisać do rejestrów sprzętowych mniej więcej to samo co zwykłe instrukcje. Fajnie by było, gdyby ROR $D01B zastąpił suszarkę. ;)

Ja również ciągle aktualny.

Coma Light 13 ma ładną grafikę i kilka dobrych efektów, ale rewelacji tam nie widzę, ani nawet spójnego designu. Już bardziej podobało mi się Biba 3. Na razie widziałem tylko te dwa.

xexy z asapconv możesz odpalać z dowolnego xex loadera, np. prosto z sio2sd.
Możesz hurtem skonwertować całą ASMA do xexów:
Pod Windows:

for /r ASMA %f in (*.sap) do @asapconv -o .xex %f

Pod innym systemem:

find ASMA -name \*.sap -exec asapconv -o .xex {} \;

Dodając --tag po .xex dostaniesz ekran z napisami zamiast czarnego, kosztem większego zużycia pamięci i tym samym większego ryzyka konfliktu z sapem (ale to dotyczy raczej pojedynczych sapów). xexy są kompresowane, więc będą zajmować mniej, niż sapy.
Poza tym temat był już trochę wałkowany.

Brawo za udany eksperyment. :)

Taki tryb ma wadę w porównaniu do połączonych liczników: nie działa synchronizacja z bitem startu - resetuje ona liczniki kanałów (co w tym przypadku nic nie daje), ale nie dzielnik /28. W efekcie każda odchyłka prędkości po drugiej stronie (AspeQt) będzie powodowała błędy. Nawet przy idealnie pasujących prędkościach nie mamy gwarancji, że próbkujemy bity w połowie. Ogólnie oczekiwałbym dużo więcej błędów, niż w standardowym trybie. Ale jeśli to "dużo więcej" to np. jeden błąd na sto sektorów, to można powtarzać transmisję i nie będzie to przeszkadzać.

Ta potencjalnie spora wada jest równocześnie drobną zaletą: równie dobrze można wyłączyć "tryb asynchroniczny" i całą transmisję przeprowadzać na SKCTL=$23 - zyskujemy kilka bajtów kodu ;). Normalnie tylko wysyłamy na $23, a odbieramy na $13. Powiem więcej: aby nie chrzaniła się muza na kanale 3 trzeba używać $23 a nie $13. W przypadku $13 bit nadejście bitu startu resetuje liczniki 3 oraz 4. Mielibyśmy więc "dodatkowy efekt dźwiękowy" na kanale 3 o częstotliwości ok. 3 kHz.