Dzięki Krótki. Muszę to w takim razie jeszcze raz zweryfikować.

Może pierwsze partie poszły z błędem, który potem poprawiono?

Edit: Stryjek - zgrałbyś swoją wersję i udostępnił?

Ze sprzętem to ja mam zawsze problem przy zakupach, bo kompletnie się tym nie interesuję. Ma działać, ma mieć dużo RAM-u i ma mieć wystarczający dysk. I matowy wyświetlacz :) Więc tu nie pomogę bo modele i numerki pecetów nic mi nie mówią.
Od lat używam Ubuntu, bo nie zamierzam się zajmować ciągłymi updatami i konfiguracjami. No i on mi się całkiem dobrze sprawuje.
Na PC używam emulatorow atari800 i altirra, fuse, vice, fceux. Ale piszę na nim programy tylko dla Atari.
Z kwestiami dumpów na flopa czy konwersjami obrazów się nie stykami, bo do połączenia PC/Atari używam SIO2PC+sio2bsd. Czyli mapuję sobie .atr albo katalog jako urzadzenie SIO.
Tak więc jak widzisz słaby ze mnie retrofan :) i nie za wiele mogę pomóc.

Hmmm, zagadka. Zaopatrzę się w SIO2SD i spróbuję z tym powalczyć.
Po drodze Candle potestował zachowanie SIDE2 z włączonym PBI BIOS-em w Ultimate1M. Wnioski:
0. Player gra bez zacięć z SIDE.
1. Kiedy ustawione jest standardowe SIO player działa bez zacięć z SIO.
2. Kiedy ustawiony jest jakikolwiek patch HSIO lub BT player przycina się na czas komunikacji kiedy gra z SIO. Prawdopodobnie wyłączane są przerwania, ale bez sprawdzenia co tam jest w ROM-ie nie mogę tego na 100% potwierdzić.
Wyszedł jeszcze błąd skutkujący ponownym odtworzeniem zawartości bufora kiedy komunikacja definitywnie się nie powiodła (po kilku próbach).
No to jest co robić :)
Dziękuję za testy i raporty o błędach Panowie.

Pinokio na moją prośbę przeprowadził testy z SIO2SD i z SIDE2. Wnioski są następujące:
1. SIO2SD trzyma prędkość US taką, jak ustawi się magicznymi klawiszami K1..K4 i nie pozwoli się przestawić z poziomu OS na prędkość niższą. To powoduje przycinanie odgrywania. Należy więc eksperymentalnie zejść z prędkością na SIO2SD do akceptowalnego poziomu. Jak już pisałem kiedy HS Index jest niższy niż 8 wtedy SDX wyłącza przerwania podczas komunikacji i player się zatrzyma (do tego poziomu próbuje grać, do momentu kiedy skończą się mu dane w buforze), ale po zakończeniu ładowania powinien kontynuować odtwarzanie. W zasadzie dla użytkownika więc nie ma znaczenia czy NMI są blokowane czy nie - trzeba na SIO2SD zejść z prędkością do poziomu kiedy odtwarzanie będzie już płynne. Ustawienie prędkości 19200 (czyli NORMAL) na pewno nie będzie blokować odtwarzania, ale to przypadek skrajny.
2. SIDE2 działa płynnie z załadowanym sterownikiem SIDE2.SYS (obsługa SIDE2 w Ultimate1M jest wyłączona) - nie ma żadnych przestojów. Chwilowo nie testowano obsługi SIDE2 w Ultimate1M (co uwalnia od konieczności ładowania sterownika SYDE2.SYS), więc na razie nie umiem powiedzieć jak to zadziała w takiej konfiguracji.
Dzięki Pinokio za testy!
Tak czy inaczej w następnej wersji przywrócę ładowanie dumpa do XRAM-u jeśli ten jest dostępny żeby uniezależnić się trochę od konfiguracji sprzętu i prędkości urządzenia.

Edit: Szczególnie interesuje mnie informacja czy program w jakiejś konfiguracji się ZAWIESZA? Bo to nie powinno się nigdy wydarzyć. Odtwarzanie można przerwać klawiszami ESC i BREAK, choć czasem trzeba zaczekać na zakończenie operacji I/O.

Czyli:

1. Kod produktu,
2. Uruchomienie SI2.EXE (o ile człowiek wyrazi chęć),
3. Zdjęcie płyty głównej (o ile człowiek wyrazi chęć) żeby zidentyfikować kwarc

powinno zdać egzamin. Wielkie dzięki za pomoc.

Program powinien sam przełączyć prędkość z turbo na normal. Ale sterownik SIO w SDX ma taki ficzer, że dla HSINDEX <= 8 OIDP wyłącza przerwania NMI. To może być powodem stawania playera (bo gram na VBLKI). Można to przestawić tak, jak napisał x_angel, albo próbować przesunąć próg dla NMI też przez SIOSET, ale chwilowo nie mam jak sprawdzić jak to zrobić - na pewno jest to opisane w manualu (MAN SIOSET).

@gorgh: Przećwiczone i działające (bo akurat potrzebowałem).
Mój plik.dta zawiera w jednym bloku dane i program który docelowo jest w $A000. I to są dane RAW bez żadnych nagłówków (nie używam kompresji raw, bo musiałbym użyć dekompresora strumieniowego, a to mi akurat nie odpowiada tutaj). Dekompresję przeprowadzam z pamięci w miejsce docelowe i ja akurat używam dekompresji wprzód.
Robię:

$ exomizer mem -f -l none -o plik.exo plik.dta@0xa000

A w kodzie wołam procedurę decompress z adresem danych wejściowych w YX:

        ldx #<data
        ldy #>data

decompress:
        stx get_crunched_byte.?addr+1
        sty get_crunched_byte.?addr+2
        jmp decrunch

get_crunched_byte:
?addr   lda $FFFF
        inc ?addr+1
        sne
        inc ?addr+2
        rts

        icl "krilldecr.asx"

data    ins "data.exo"

Dane wylądują w $A000, bo ten adres znajduje się na początku bloku danych (już skompresowanych - wstawia go kompresor).
Uwaga co do krilldecr.asx - adresy na ZPG możesz ustalić jak Ci się podoba.
Exomizer v2.0.11.

Macie rację. Alzheimer.

Edit: Seban mistrz!
To teraz ja z moimi wtórnościami (oryginał Adam Gilmore) :) Dopisałem się do kodu Sikora.

9 GOTO 100
10 MC=MC+MD(MB):IF MC>255 THEN MC=MC-256
11 SOUND 1,MC,10,1:IF MA=0 THEN MB=MB+1:IF MB=13 THEN MB=0
12 MA=MA-1:IF MA<0 THEN MA=255
13 RETURN 

200 REM - part by Sikor & Mono
201 GRAPHICS 31:C=1:GOSUB 3010
202 FOR I=O TO 79 STEP 2:COLOR C:C=C+1:IF C>3 THEN C=1
203 GOSUB 10:PLOT 40+I,90+I:GOSUB 10:DRAWTO 80+I,90-I
204 GOSUB 10:PLOT 80-I,90-I:GOSUB 10:DRAWTO 40+I,90+I
205 FOR P=0 TO 20:GOSUB 10:NEXT P
206 NEXT I
207 GOTO 202

3000 REM - Mono's part data -
3010 DIM MD(13):RESTORE 3010:FOR MA=0 TO 12:READ MC:MD(MA)=MC:NEXT MA:MA=231:MB=11:MC=215:RETURN 
3020 DATA 84,170,187,204,238,52,102,153,100,206,235,221,68
3030 REM --- end of Mono's part data ----

Zrobiłem wersję 1.11, w której rezerwuję nieco więcej pamięci na ekran, bo zdarzało się że na dole pojawiały się śmieci. Nic więcej nie psułem :)

Raczej symultana.

Mógłbyś powiedzieć coś więcej? Jakiś link? .ATR-a, .COM-a? Chętnie bym to zobaczył. Znałem do tej pory tylko XL Frienda od Avalonu.