Temat: Co jest złego/dobrego w tej procce waitforvbl?

Jest procka by Fox:

w1
    lda $d40b
    bmi w1
w2
    lda $d40b
    bpl w2

Ma ona 10 bajtów i nie obsługuje NTSC, działa z DMACTL=0.

Napisałem inną 10 bajtów. Ona obsługuje NTSC (w teorii, bo nie testowałem). Czy jest tu jakiś haczyk? Czy zawsze zadziała?
Opiera się ona na monotoniczności vcount. Działa z DMACTL=0.

rep
    lda vcount
@
    cmp vcount
    beq @-
    bcc rep

Ostatnio edytowany przez qbahusak (2020-07-02 10:31:07)

2

Odp: Co jest złego/dobrego w tej procce waitforvbl?

co będzie dla vcount=0?

przechodze na tumiwisizm

3

Odp: Co jest złego/dobrego w tej procce waitforvbl?

Candle napisał/a:

co będzie dla vcount=0?

Zawiśnie na pierwszym beq, a następnie zaczeka na moment, gdy vcount się zmniejszy (carry się nie wyzeruje). Nie?

Przy każdej zmianie vcount w górę, bcc skoczy, bo carry się zeruje - odejmujemy większą od mniejszej.
Przy zmianie w dół w acc mamy coś dużego, odejmujemy coś małego, 0, 1 czy cuś, carry zostaje ustawione.

Ostatnio edytowany przez qbahusak (2020-07-02 10:57:09)

4

Odp: Co jest złego/dobrego w tej procce waitforvbl?

vcount się zmniejsza?

ale chyba to wyimaginowany problem
jeśli pod altirrą ustawiona na ntsc to działa, to pewnie działa

Ostatnio edytowany przez Candle (2020-07-02 11:06:18)

przechodze na tumiwisizm

5

Odp: Co jest złego/dobrego w tej procce waitforvbl?

Candle napisał/a:

vcount się zmniejsza?

No... chyba tak raz na vbl?

Chodzi o to, że są jeszcze komputery SECAM, NTSC, PAL, VBXE, z przyspieszeniami etc.
Czy to na wszystkim ma szanse zadziałać? Nie jestem altirowy.

Ostatnio edytowany przez qbahusak (2020-07-02 11:09:30)

6

Odp: Co jest złego/dobrego w tej procce waitforvbl?

Kiedyś też tak kombinowałem. Sprawdźmy taki przypadek:

lda VCOUNT    ;155
cmp VCOUNT  ;156
beq  ;omijamy
bcc  ;skaczemy
lda VCOUNT    ;0
cmp VCOUNT  ;0
beq  ;skaczemy
cmp VCOUNT  ;1
beq  ;omijamy
bcc  ;skaczemy

Zdaje się że taka procedura przy 3MHz potrafi się pętlić w nieskończoność. Ale nawet jeśli nie będzie no to może się okazać, że będzie cię trzymać przez kilka ramek a nie synchronizować z najbliższą. Stosuj Foxową :)

Edit: Co zaś się tyczy NTSC, to trzeba SEI ... CLI.

Edit 2: http://www.atari.org.pl/forum/viewtopic … 42#p101142

Ostatnio edytowany przez mono (2020-07-02 11:32:39)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7

Odp: Co jest złego/dobrego w tej procce waitforvbl?

zróbcie test przed uruchomieniem programu, jeśli nie jest to 6502 1.76 MHz PAL to kończycie program, albo dajecie ostrzeżenie że nie ponosicie odpowiedzialności za szkody które za chwilę zostaną wyrządzone ;)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

8

Odp: Co jest złego/dobrego w tej procce waitforvbl?

  sta nmires
  bit nmist
  bvc *-3

9

Odp: Co jest złego/dobrego w tej procce waitforvbl?

antrykot napisał/a:
  sta nmires
  bit nmist
  bvc *-3

Jeśli to działa zawsze, to jest to najlepsze rozwiązanie, bo do testu jest użyte to, co zostało zaprojektowane w tym celu.
@mono, co o tym myślisz?

10

Odp: Co jest złego/dobrego w tej procce waitforvbl?

To zależy do czego tego potrzebujesz. VBLK jest zgłaszane w 248 linii skanningowej. Jeśli NMI są włączone to metoda nie zadziała, a przy wyłączonych nie sprawdzałem (nie wiem czy bity statusu są wystawiane przy zablokowanych NMI).
Ale skoro tak, no to możesz też:

sei
lda VCOUNT
bne *-3
cli

Edit: Albo analogicznie :D

sei
lda #248/2
cmp VCOUNT
bne *-3
cli

tylko znowu - nie możesz dopuścić obsługi NMI (bo obsługa NMI zajmie parę linii i nigdy w 248 nie trafisz).

Edit 2: A w ogóle to czemu nie zsynchronizujesz się klasycznie?

lda RTCLOK+2
cmp RTCLOK+2
beq *-2

Ostatnio edytowany przez mono (2020-07-02 21:07:29)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

11

Odp: Co jest złego/dobrego w tej procce waitforvbl?

qbahusak napisał/a:

Ma ona 10 bajtów i nie obsługuje NTSC

Masz na myśli NTSC z długą systemową procedurą VBLK?

qbahusak napisał/a:

działa z DMACTL=0.

Nie rozumiem, dlaczego akurat zwracasz uwagę na DMACTL? Czy chodziło o NMIEN?

mono napisał/a:

Jeśli NMI są włączone to metoda nie zadziała

Czasami może zadziałać. Przerwanie nie przerywa wykonywanej instrukcji. Jeśli tą instrukcją jest odczyt NMIST, to odczytamy sygnalizację przerwania i dopiero potem wykona się obsługa przerwania.

mono napisał/a:

a przy wyłączonych nie sprawdzałem (nie wiem czy bity statusu są wystawiane przy zablokowanych NMI).

NMIST nie zależy od NMIEN.

Ostatnio edytowany przez Fox (2020-07-03 14:09:28)

https://www.youtube.com/watch?v=jofNR_WkoCE

12

Odp: Co jest złego/dobrego w tej procce waitforvbl?

@Fox, dzięki za głos.
Jak się pisze z głowy - to zamiast NMIEN wpada DMACTL :)

A mógłbyś tak w formie krótkiego artykułu opisać co i jak? Jak widzisz, jest z tym jakiś-tam problem, dużo procków, dużo wszystkiego.
To, że NMIST nie zależy od NMIEN to jest raczej oczywiste z istoty natury rzeczy.
Podejrzewam na 99%, że procka antrykota zadziała na wszystkim i zawsze chyba, że NMI się wstrzeli i skasuje te bity pomiędzy sta a bit. Ale to raz na tysiąc lat.