Hahahhahahhahaaaaaa! (śmiech szaleńca planującego przejęcie kontroli nad światem) To nie moja, tylko Petera Liepy. Atari Dual Core :D - może PInokio odpalił by to na swoim potworze i zdał re(we)lacje.
Zastanawiałem się, jak by tą muzykę maksymalnie przyspieszyć, bo miałem to na początku w liniach DATA więc nie ma już parsowania danych, ale sam player jest niestety niewiele szybszy :/
Podobał mi się Twój sinus i chciałem okrasić go odpowiednią muzyką - JAK DEMO TO DEMO!

Bardzo proszę o załączanie również listingu w załączniku (najlepiej .LST). Czasu niewiele więc pomoże to bardzo.

Można też nieco inaczej:
Najpierw F1:
1. W Emulator Configuration wyłączyć SIO patch (czasem zakłóca ładowanie z magnetofonu).
2. W Emulator Configuration wyłączyć BASIC.
3. W Emulator Configuration włączyć trzymanie START podczas BOOT.
4. W Tape Management podłączyć plik .CAS i ustawić Position na 1 (to licznik rekordów).
Potem F5 i się powinno ładować.

@Sikor: SDX tak, jak i xBIOS ma swój specjalny interfejs, który daje sporo większe możliwości niż tradycyjny ATARI DOS. Jak chcesz zrezygnować z dobrodziejstw typu: kod relokowalny, TSRy, zarządzanie XRAM, symbole, itp. to możesz pisać samodzielnie wszystko. Analogii zresztą daleko nie trzeba szukać - renegaci odrzucający jakiegokolwiek DOSa (CIO) organizują sobie dysk po swojemu i korzystają z SIO pisząc programy BOOTowalne. Kardridżowcy też. Nie rozumiem co jest niewłaściwego w tym, że powstają programy korzystające z nowych fajnych funkcji, które daje oprogramowanie :/ To oczywiste, że program napisany specjalnie dla xBIOS, jak i napisany specjalnie dla SDX nie będzie działał na ATARI DOS. Zapewnienie kompatybilności wstecznej jest tak dużym krokiem wstecz, a wynikającym z odrzucenia wielu ułatwień, że po prostu szkoda się mordować. Masz pretensje, że program dla MS-Windows nie chodzi pod MS-DOSem :/?

Wychodzi na to, że Sparta jest elitarnym systemem. Ha!

DOSKEY.SYS

Z[TAB][RETURN]

Sugerujesz, że jest to byt pozbawiony świadomości swego istnienia?

Nie zna życia, kto nie pisał w Sparta DOS X.

Piękny kawałek kodu ("Dowód jest elegancki kiedy da się go zapisać na marginesie" haha). Szacun!

Edit: Zastanawiam się czy NEWIOP nie spowoduje, że w pewnych warunkach procedura nie będzie reentrant, ale jeśli przepiszemy IRQMAIN to można go nie używać, albo zapewnić żeby była tam zawsze zawartość .A sprzed wywołania.
Podoba mi się JSR+NOP zamiast odkładania dokładnego powrotu na stos - zgrabne.

Przy takim zdefiniowaniu priorytetów używanie BRK mija się z celem, bo opóźnienia obsługi BRK w pesymistycznym przypadku będą rzędu 250 cykli (przejdzie cała detekcja IRQ zanim zostanie wywołana obsługa BRK). Lepiej użyć JSR/JMP i tablicy skoków. Pewnie dlatego OSowcy zrezygnowali z patchowania i zostawili PLA/RTI (co chyba najsensowniej w takim stanie rzeczy zrobić).
Pytanie dlaczego w ogóle zostawili wektor (i to dopiero w serii XL/XE) skoro wiedzieli, że to nie działa? Może planowali użyć CPU, który wszystko realizuje poprawnie? ;]
Wychodzi na to, że faktycznie sens używania BRK to tylko laboratoryjny debug.

W atariki stoi: "Wystąpienie przerwania podczas wykonywania rozkazu BRK spowoduje, że zostanie on zignorowany". Tylko co to znaczy? Czy to, że błąd leży w procedurze obsługi IRQ, czy że jest to własność processora?

A co jest w F.I na stosie? Bo może warto by zrobić tak:
- jeśli I=1 to IRQ na pewno nie przerwie IRQ, więc jedynymi opcjami są NMI i BRK.
- jeśli B=0 to było BRK więc można od razu wykonać nie uruchamiając detekcji źródeł IRQ.
Widzę jeszcze jeden problem.
Załóżmy, że wykonujemy BRK i CPU wszedł w obsługę przerwania, sprawdza kolejne źródła i w tym momencie przychodzi jakieś IRQ. Zapala się flaga w IRQEN/PxCTL/PDVREG czy gdzie tam i nagle CPU zamiast zrealizować BRK zboczy nam w któreś IRQ. Obsłuży przyjęcie i nie zwracając na stan B na stosie wyjdzie z przerwania. W tym momencie jest po ptakach, bo drugi raz w przerwanie nie wejdziemy (analogicznie jest z NMI, ale to tylko dygresja) :/ Może w OS po prostu źle zrobiono detekcję i BRK powinno mieć najwyższy priorytet?