Rozumiem. Pobawiłem się chwilę programikiem i myślę że pomysł jest jednak całkiem fajny. Jedyne co mi w sumie przeszkadza to konieczność wciskania spacji między częścią setek a częścią dziesiątek (no ale to myślę da się łatwo wyeliminować).
Przyszło mi do głowy, że może pewną pomocą byłoby podpowiadanie gdzieś na obrzeżach ekranu liczby, którą do tej pory wpisaliśmy. Np. wciskamy ctrl+1 i pojawia się "1__", ctrl+2 - "2__", 0-" 0_" itd. Może nie wymagałoby to wielkiej ingerencji w kod programu a widzielibyśmy co się dzieje.
I chyba warto by dodać HELP na wciśnięcie klawisza HELP :) No ale to zupełnie inna bajka.

P.S. Dziękuję za ofertę pomocy, to bardzo miłe i będę o tym pamiętał. W razie potrzeby oczywiście też uderzaj w moim kierunku.

Ctrl+1 ma odzwierciedlenie w SSFLAG ($2FF) na zasadzie odwrócenia wartości (przerwanie klawiatury robi EOR #$FF).

A dlaczego nie przesunąć jedynki w prawo w ramach definicji znaku i użyć jednak trzyznakowych liczb? Coś w guście:

..o. .ooo
..o. ...o
..o. .ooo
..o. .o..
..o. .ooo

Liczba będzie czytelna, bo od poprzedniej kolumny będzie jednak odstęp dwóch pikseli multicolor. Oczywiście 2xx w ten sposób już nie zrobimy :/

Większe pole do popisu daje oczywiście hires co wiąże się z redefinicją zestawu znaków, no i zmianą sposobu reprezentacji niektórych elementów ekranu (może podkolorowanie sprajtami?) oraz podświetlenia kursora (tradycyjny inverse).
Co do wprowadzania liczb - sugerowałbym wtedy wprowadzanie 1..3 cyfr na zasadzie znanej z kalkulatora:
1. Pierwsza cyfra wchodzi w tryb wprowadzania liczby.
2. Cyfry przesuwają się w lewo podczas wprowadzania (intuicyjne).
3. 3 cyfra wychodzi z trybu, aktualizuje pole i przesuwa kursor (albo nie - zależnie od potrzeby).
4. Strzałka lub RETURN wychodzi z trybu i aktualizuje pole.
5. ESC wychodzi z trybu i przywraca poprzednią wartość pola.
6. BKSP połyka cyfrę i przesuwa resztę w prawo.
7. Po połknięciu wszystkich cyfr mamy 0 ale trwamy w edycji.

Mam wrażenie, że markowanie setki kolorem będzie mocno nieintuicyjne szczególnie dla użytkowników mających awersję do dokumentacji.

Uzupełniłem .atr-a o drobne info co jest co, i zmieniłem jednak rozszerzenie zestawu sampli na .DIG. .atr podmieniony w poście 18.

Edit: Dla porównania załączam jeszcze ripa oryginalnej muzyki z BARAHIR-a.

I w CMC+ (zerknij w Atariki).

W załączniku wersja poprawiona.
Poprawek wymagały:
- procedura ładowania sampla (nie przepisywane były $0FF i $1FF bajt sampla),
- procedura zapisu zestawu sampli (zapisywane było $1000 bajtów z obszaru $7E00..$8DFF zamiast $0A00 bajtów z $7300..7CFF).

Dokładny patch:
$9521: $EA $EA
$9548: $0A
$954b: $72
$954e: $72
$9552: $72

Edit: Jeszcze pojedyncze sample wyjęte z CMCSM.

Hmmm. Podejrzewam, że miał być załącznik, ale go gdzieś wcięło... :)

Czy ktokolwiek dysponuje wersjami CMC:
- od Stanley'a - zmodyfikowana tablica basów,
- od Jaskier'a - metrum 3/4 metodą Henryka Karpowicza z Serious#5
i mógłby podesłać?
Uprzejmie proszę o pozytywne ustosunkowanie się do mojej prośby :P

Ale kto, kogo będzie zjadał?

Czy ja dobrze rozumiem, że ustawiasz stały interwał a zmienna LINE odlicza Ci linie w których wykona się kod rastra albo nie? Dlaczego tak?

Czy nie prościej i wydajniej zmieniać wartość AUDF co przerwanie? Mając oczywiście na względzie, że interwał z AUDF jest przepisywany do wewnętrznego TIMER:
- po przekręceniu TIMER,
- po zapisie do STIMER.
Tak więc zgrubsza:

lda intervals
sta AUDF
sta STIMER
lda intervals+1
sta AUDF
lda #2
sta index
...
...
irq:
index = *+1
  lda intervals
  sta AUDF
  rti

intervals .db 0,1,2,3,4,5,6,... i jakie tam interwały nas interesują

Edit: Można też oczywiście uzyskać granulację 1/4 skanlinii albo co do cyklu CPU. No i kod poza przerwaniami powinien być tak skonstruowany, żeby koniec rozkazu przypadał na moment rozpoczęcia obsługi przerwania (żeby sekwencja wejścia w przerwanie nie czekała zbyt długo). Niezależnie jednak od tego timing liczników będzie precyzyjny - jedyne wahania to oczekiwanie na zakończenie cyklu rozkazowego CPU przed rozpoczęciem obsługi IRQ, ale nawet synchronizacja przez WSYNC ma wahania 1, 2 cykle oidp.

Dzięki za wyjaśnienie tej pauzy :) Wrzucę opis do Atariki przy opisie formatu pliku CMS.
Program nazywa się CMC 2000 v 1.02 ale jednak pochodzi z 6.11.1999 - na załączonej dyskietce masz plik CHAOS2K.XEX.
W przykładowej muzyce GRAVE.CM2 na samym początku jest przykładowe użycie rozkazu V:. Po lewej stronie za to przy każdym układzie są 3 wartości głośności. Na dyskietce są też dokumentacje i program do odczytu tychże (nie umiem się nim posłużyć).
Ładowanie muzyki odbywa się analogicznie, jak w SDCMC ale czasem jak program zawiśnie trzeba wcisnąć RESET i ładować jeszcze raz - zazwyczaj się udaje.

Ooooo. Dzięki :)
Są zdaje się dwie wersje tego edytora różniące się sposobem implementacji funkcji głośności i double-play.

Edit: Mogę się za to podzielić instrukcją.

A klawiaturologia w jakimś skrócie (nie znam czeskiego):

Okno song:
- inverse - zmiana trybu normal/double play
- ctrl+e - o pięć linii w górę
- ctrl+d - o pięć linii w dół
- ctrl+c - skok do pozycji 0 (chyba)
- ctrl+n - zmiana nazwy modułu
- ctrl+s - zapis na kasecie w formacie turbo
- ctrl+l - odczyt z kasety w turbo
- shift+esc - wejście do menu dyskowego

Dodatkowe komendy w songu:
- shift+v: zmiana głośności kanału - V: xx ustawia głośność wszystkich kanałów, V: xx yy ustawia głośność wszystkich kanałów pierwszego pokeya na xx, drugiego na yy (wartości podaje się dziesiętnie 00..15)
- shift+m: zmiana trybu odtwarzania - M: 00 to normal, M: 01 to double
- shift+p: pauza - P: xx yy pauzuje odtwarzanie na czas podany w dziesiętych częściach sekundy (ale jak to podać, skoro wartości w polach songu mogą być 00..63?)

W menu narzędzi dyskowych warto uważać na to, co się wciska, bo:
- shift <,> - zmiana napędu
- 1,2,3,4 to fromatowanie, usuwanie, lock, unlock
- space - katalog
- strzałki - przemieszczają kursor po katalogu
- return - ładuje z dysku wybrany utwór

Ale konia z rzędem temu, kto wie, jak ZAPISAĆ utwór na dysk.

No i zauważyłem, że nie lubi się toto z pamięcią rozszerzoną :/ (u mnie zawisa nawet na DOS II/D+).