A gdzież tam :D

Dla wygody i przyjemności?

I jak tu wyjść  psem na spacer...?

Tak, ale niestety patch spowoduje też spory wzrost opóźnień (dla DLI ok 20 cykli, dla VBLK ok 35, dla IRQ ok 25). W przypadku DLI chyba lepiej nie wprowadzać takich delayów? 7 cykli przy samym NMI patch w sumie może byłoby i akceptowalne...
Zrobiłem małą przymiarkę dla wektoryzowania przez NMIVEC i IRQVEC:

nmi:
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3

  asl NMIST
  scc
  jmp (VDSLST)

  pha
  txa
  pha
  tya
  pha
  cld
  jmp (VVBLKI)

irq:
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3

  asl NMIST
  scc
  jmp (VDSLST)

  cld
  smi
  jmp (VIMIRQ)

  pha
  txa
  pha
  tya
  pha
  jmp (VVBLKI)

brkopcode:
  txa
  pha
  tsx
  lda $103,x
  and #$10
  beq ?ret
  pla
  tax
  jmp (VBREAK)

?ret:
  pla
  tax
  pla
  rti

oraz dla VDLST, VVBLKI i VIMIRQ:

vdslst:
  sta NMIRES      ;4
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  ...             ;-------20 cykli

vvblki:
  pla             ;4
  tay             ;2
  pla             ;4
  tax             ;2
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  txa             ;2
  pha             ;3
  tya             ;2
  pha             ;3
  ...             ;-------35 cykli

vimirq:
  bit NMIST       ;4
  spl             ;23
  jmp (VDSLST)    ;5 -----11 cykli

  svc             ;23
  jmp (VVBLKI)    ;5 -----14 cykli

  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  ...             ;-------26 cykli

Na razie teoretyzuję, bo nie uruchamiałem tego. W tym przypadku IRQ w obydwu przypadkach uruchomi 2x obsługę BRK kiedy nie wejdzie mu w drogę ani NMI, ani IRQ.

Edit: 2x wywołanie BRK akurat da się obejść realizując zamiast PHP po prostu LDA #%00100100+PHA.

@Fox @xxl: Dzięki.

NMI jest wymuszane zboczem, więc nie ma szans wejść w to samo NMI po raz drugi. Jeśli chcielibyśmy obsługiwać BRK też i na NMI, to trzeba by odłożyć na stos powrót do obsługi BRK i kontynuować NMI.
Można jeszcze skorzystać z patentów xxla na programowe wywołanie IRQ i spokojnie wyjść z NMI.

Edit: "ASL..." załatwia sprawę, ale nie CAŁKOWICIE, bo jak sam się zgodziłeś potrzebne jest jeszzcze STA NMIRES na DLI :/ albo zmiana ROMu z główną procedurą obsługi NMI (tak, żeby użytkownik nie musiał już robić nic z NMIRES w swoim kodzie).

Edit 2: "Wejść w to samo NMI po raz drugi" - chodzi o podtrzymanie wymuszenia na linii NMI. IRQ jest wymuszane poziomem, więc przerwanie może być odroczone - wystarczy tylko nie obsługiwać go w IRQST (lub innych). W NMI to nie wystarczy, bo po powrocie przez RTI wymuszenia już nie ma.

Ustawiony.

CLD sobie trzeba dodać przed obsługą IRQ, bo SIO liczy np. sumę kontrolną.

Z moich testów wynika, że nie ma jak wykryć wykonania BRK kiedy wraz z nim wystąpiło jakiekolwiek przerwanie sprzętowe (nie może być jak IRQ odroczone). Chciałbym się bardzo pomylić w tej kwestii, bo podoba mi się wołanie funkcji systemowych za pomocą BRK #fn.

Jump if MInus: bmi albo jeśli za daleko to spl + jmp; analogicznie Jump if V Clear.

Edit: No i BRK wykona się przy zapalonym I.

@xxl: Niestety reset NMI jest konieczny przy paczowaniu IRQ.
Dlaczego?
Założenie projektantów OSa było (domyślam się) takie: DLI jest krytyczne czasowo, więc nie robimy tu niczego zbędnego - widać to po tym, że nie robią nawet PHA a przechodzą do DLI najszybciej jak się da. Ponieważ w XL/XE (nie wiem, jak to wygląda w 400/800) przerwania NMI są tylko 2, to nawet jak wystąpi DLI i status w NMIST po jego obsłudze zostanie w rejestrze, to nic się nie stanie, bo następnym przerwaniem NMI będzie i tak tylko kolejne DLI. Aż do momentu wystąpienia VBLK, bo najwyraźniej przy jego wystąpieniu NMIST.7 jest kasowany i dlatego systemowa procedura VBLK ma szansę się wykonać.
Jeśli natomiast po (albo równocześnie z) DLI wystąpi IRQ to bez skasowania NMIST obsługa przerwania IRQ zawsze przejdzie do obsługi DLI i nigdy nie wykona właściwego IRQ.
Dlaczego uważam, że powinien to robić user implementujący DLI? Ponieważ mamy jeden wektor VDLST, który używa NMI i IRQ a obsługa przerwania powinna być IMHO spójna. STx nie zmieniają znaczników więc można to robić tuż przed RTI po zakończeniu krytycznych czasowo rzeczy. Byłaby to więc dobra praktyka pozwalająca działać programowi zarówno w standardowym, jak i spaczowanym środowisku.

Edit: I tak takie DLI opóźnione jest o 7 cykli (CLD+JMP ind), chyba że podpinamy się pod wektor IRQVEC zamiast VIMIRQ, ale wtedy trzeba by zrobić jeszcze CLD przed SVS.

@0xf: Racja - poprawione.

Dzięki Seban.

Aaaaa. To tak - blitter w końcowej fazie robi copy z ekranu wirtualnego to rzeczywistego i jest wyścig z ANITCem. To prawda - załatwi to odpalenie tegoż blita np na VBLKD, ale wtedy nie zobaczę tak ładnie lewego wskaźnika :)

Edit: To też oczywiście da się obejść. Policzyć czas trwania blita w liniach ekranowych i potem namalować wskaźnik w dowolnym miejscu ekranu, ale jak mówiłem - to "demo" ma na celu tylko zobrazowanie możliwości. Nie jest to pełnoprawne ładne demo w prawdziwym tego słowa znaczeniu :)