Kurs programowania w asm (dla ZX na początek)...

[trojacek]

Synchronizację co ramkę można też uzyskać przez:

Kod: [Zaznacz]

halt ; czekaj na kolejne przerwanie

Taaa...
Wciskasz jakiś klawisz i już po synchronizacji.
Do tego dziwne zakłócenia tej synchronizacji rytmicznie co kilka sekund.
Trzeba pamiętać, że przerwanie INT to standardowo skok do procedury w ROM, a czas jej wykonania zależy np. od wciśnięcia klawiszy, a co 256 cykli (ok. 4,3 s) nieco więcej taktów zawiera aktualizacja 24-bitowego licznika ramki.
Kod umieszczony po HALT będzie wznowiony dopiero po zakończeniu procedury przerwania w ROM-ie.

[tdu]

To znaczy synchronizacja przez HALT jest ale nie najlepsza.

To może uda się wytłumaczyć, jakoś prostymi słowami jak to zrobić.
W końcu nie trzeba wszystko rozumieć do końca aby używać.

Teraz to mamy taką epokę że mamy raczej małe pojęcie jak co działa, a używamy.
Od telefony do samochodu.
Skończyła się epoka ludzi omnibusów, którzy byli w stanie wiedzieć wszystko o wszystkim.

[Phonex]

Trzeba pamiętać, że przerwanie INT to standardowo skok do procedury w ROM, a czas jej wykonania zależy np. od wciśnięcia klawiszy, a co 256 cykli (ok. 4,3 s) nieco więcej taktów zawiera aktualizacja 24-bitowego licznika ramki.
Kod umieszczony po HALT będzie wznowiony dopiero po zakończeniu procedury przerwania w ROM-ie.

Nie co 256, tylko co 65536 przerwań - czyli 21 i coś MINUT
A naciskanie klawisza czasem nie ma znaczenia, jeśli np. po naciśnięciu program i tak przechodzi dalej.
Mój programik na Wyzwanie #4 w drugiej części synchronizuje się przez HALT w trybie IM1 i jest malinowo
https://www.speccy.pl/forum/index.php?topic=3339.msg51420#msg51420

EDIT: Właśnie sprawdziłem co się dzieje przy naciskaniu klawisza jak nie powoduje to wyjścia z animacji (usunąłem sprawdzanie klawisza). Otóż nic się nie dzieje - dalej chodzi płynnie

[trojacek]

Moim zdaniem najlepiej zrobić własną obsługę przerwań INT.
Po pierwsze, potrzebna jest tablica wektorów dla trybu drugiego (IM 2). Potrzebujemy 2x256=512 bajtów.
O ile mnie pamięć nie myli, działa to tak, że starszy bajt tej tablicy wektorów ładujemy do rejestru I, a młodszy bajt jest odczytywany z szyny danych w momencie przyjęcia przerwania. Jako że Spectrum nie ma żadnych urządzeń wystawiających wektory w ten sposób, młodszy bajt może być z zakresu 0..255, stąd potrzeba takiej tablicy.
Adres pobrany z tablicy (dwa bajty) jest adresem skoku do procedury obsługi przerwań.

Uwaga, żeby procedura była synchroniczna z ramką, nasz kod obsługi przerwania powinien być w "górnej" pamięci (uncontended).

Załóżmy, że nasza procedura zaczyna się od adresu 32768, czyli #8000. Budujemy naszą tablicę wektorów przerwań, dajmy na to, od adresu 49152 (#C000). Poczynając od tego adresu, wypełniamy 512 bajtów wartościami #00 i #80 (naprzemiennie), czyli mamy 256 razy słowo 16-bitowe #8000.

Kod inicjujący obsługę przerwań powinien blokować przerwania (DI), ładować do rejestru I starszy bajt tablicy (#C0), włączać tryb IM 2 i odblokowywać przerwania (EI).

Nasz kod obsługi przerwań pod adresem #8000 powinien (podobno) blokować przerwania rozkazem DI (choć podobno przyjęcie przerwania robi to automatycznie). Dalej mamy kod synchroniczny z ramką, bez skoków/pętli warunkowych. Na koniec skaczemy do ROM pod adres 56 (#38), by odczytać klawiaturę, zaktualizować licznik ramek itp.

Jak ktoś lubi cwaniaczyć, to jako tablicę wektorów może wykorzystać obszar ROM wypełniony wartościami #FF (255) od adresu #386E do #3CFF. Potrzebujemy 512 bajtów, a w podanym zakresie jest ponad kilobajt. Początek tablicy będzie oczywiście pod adresem #nn00, czyli #3900, #3A00, #3B00 lub #3C00. Obsługa przerwania będzie wtedy pod adresem #FFFF, gdzie należy umieścić wartość 24 (#18), czyli kod operacji JR. Następny odczytany bajt, czy adres skoku względnego, będzie pobrany spod adresu #0000 (pamięć ROM), czyli będzie to #F3 (kod instrukcji DI). Instrukcja JR #F3 oznacza skok o -13, czyli od bieżącej wartości licznika PC (#0001) odejmujemy 13 i lądujemy pod adresem #FFF4 (65524). Pod tym adresem robimy skok do naszego kodu obsługi przerwań, np. JP #8000.

EDIT: To co pokreślone, jest nie do końca prawdą zgodnie z tym, co napisał potem Phonex

[trojacek]

Nie co 256, tylko co 65536 przerwań - czyli 21 i coś MINUT

Zajrzałem do ROM-u, i faktycznie - inkrementacja jest na słowie 16-bitowym.

A naciskanie klawisza czasem nie ma znaczenia, jeśli np. po naciśnięciu program i tak przechodzi dalej.
Mój programik na Wyzwanie #4 w drugiej części synchronizuje się przez HALT w trybie IM1 i jest malinowo

"Obsuw" o 4 takty (czyli i tak minimalistycznie) oznacza przeskok o 8 pikseli.
Może akurat Twój efekt tak ma, że nie widać efektu.
Do prostych rzeczy faktycznie styknie, nie trzeba się babrać w IM 2.

[Phonex]

Moim zdaniem najlepiej zrobić własną obsługę przerwań INT.

No pewnie że najlepiej, mówię tylko że nie zawsze trzeba.

A co do trybu IM2:
Skoro młodszy bajt może być z zakresu 0..255, to tablica ma mieć 256+1 bajtów. Dlaczego 257? Bo dla każdej wartości młodszego bajta adresu pobierane są dwa bajty jako adres procedury obsługi!
A ponieważ może przybrać każdą z tych wartości, to nie można jej wypełniać dwoma wartościami, tylko jedną. W efekcie oba bajty adresu muszą być takie same! Np. wstawiamy #80. Zostanie w każdej sytuacji odczytany adres #8080, a pod adresem #8080 wstawiamy skok gdzie nam się podoba, np. JP #8100.

[trojacek]

A co do trybu IM2:
Skoro młodszy bajt może być z zakresu 0..255, to tablica ma mieć 256+1 bajtów. Dlaczego 257? Bo dla każdej wartości młodszego bajta adresu pobierane są dwa bajty jako adres procedury obsługi!

No, sporo jednak zapomniałem przez te >20 lat niedotykania asemblera
Coś mi chodziło po głowie, że ta tablica wektorów jest lekko nierówna, ale nic na ten temat nie znalazłem.
Niemniej rozwiązanie z tablicą #FF jest OK

[Phonex]

Jest OK, sam tak kiedyś zrobiłem, ale ktoś pisał że nie zawsze...
W Spectrum 128 nie ma tam samych #FF-ów. A program działa mimo tego poprawnie (np. mój Start s12).

OK, zajrzałem do ROMU ZX 128, okazuje się że cwaniaki zostawili dwa #FF-y pod adresami #39FF, #3AFF i #3BFF!!!
(#3CFF odpada, bo nawet w ZX 48K jest tam tylko jeden #FF, dalej są już fonty).
Będzie działać jak odczyta z szyny #FF, czyli bez podłączonych interfejsów. Z interfejsem może się wywalić.
Kolejna z 11 tajemnic wyjaśniona

[trojacek]

Szanse są niewielkie, bo żeby się wywaliło, trzeba by mieć interfejs z jakimś układem z rodziny Z80 (CTC, PIO, DMA, SIO, KIO, CIO). Rodzina intelowska (8xxx) raczej nie potrafi wystawiać po przerwaniu wektora na szynę danych. Choć trzeba by to sprawdzić

[steev]

Szanse są niewielkie, bo żeby się wywaliło, trzeba by mieć interfejs z jakimś układem z rodziny Z80 (CTC, PIO, DMA, SIO, KIO, CIO). Rodzina intelowska (8xxx) raczej nie potrafi wystawiać po przerwaniu wektora na szynę danych. Choć trzeba by to sprawdzić

A floating bus nie może czasem wejść tu w paradę?
Muszę się chyba napić, bo na trzeźwo głupoty gadam...

[Phonex]

A to co "akurat już jest" na szynie danych w momencie przerwania nie ma znaczenia?
Np. odczyt joysticka?

Czy ja też głupoty gadam? Chyba tak, bo naciskanie klawiszy nie wywala, a to też odczyt z portu...

[trojacek]

@steev, zadałeś bardzo dobre pytanie, co zatem spowodowało, że je wykreśliłeś?
@Phonex, chyba znam odpowiedź, to się powymądrzam

Otóż cykl potwierdzenia przyjęcia przerwania INT powoduje wystawienie przez CPU aktywnych linii /IORQ oraz /M1 (które w żadnej innej sytuacji nie są aktywne razem). W odpowiedzi na ten stan urządzenie zewnętrzne wystawia swój wektor.
I otóż: ani joystick, ani floating bus, ani żaden inny port I/O żadnego interfejsu nie powinien wystawiać niczego innego, ponieważ linia /RD jest w stanie wysokim.

[steev]

@steev, zadałeś bardzo dobre pytanie, co zatem spowodowało, że je wykreśliłeś?

Bo IIRC INT jest generowany wewnątrz impulsu synchronizacji pionowej.
ULA wtedy nie generuje obrazu.

[trojacek]

Ale INT może też przyjść z zewnątrz komputera...

[steev]

Tak.
Ale nie kojarzę żadnego takiego interfejsu, poza slo-mo.
(choć nie znam na pamięć schematów wszystkich stacji dysków, może któraś z nich też...  )