Nie jestem pewien w jakim trybie przerwań chodzi ula ULA.
Tryb obsługi przerwań nie ma dla ULA żadnego znaczenia - generuje przerwanie ramki i nic więcej. I w momencie generowania tego przerwania nie wystawia na szynę żadnych wektorów. Dlatego w Spectrum nie da się używać trybu 0 a w trybie 2 trzeba mieć tablicę wektorów przygotowaną w "sprytny" sposób.
W trybie drugim bez problemu obsługuje się wszystkie podłączone urządzenia i podprogramy.
...CIACH opis działania przerwań...
I to wszystko jest bardzo fajne pod warunkiem, że wykluczysz ULA i brak podawania czegokolwiek na szynę oraz fakt, że po podłączeniu jakichś "dzikich" urządzeń może się zdarzyć, że w momencie generowania IRQ przez ULA na szynie znajduje się coś nieprzewidzianego. Albo, że twoje urządzenie pogryzie się z ULA w kwestii generowania samego IRQ.
Jeszcze jedną zasadą jest aby tablicę wektorów przerwań inicjować poleceniem RETI (znaczy się tam gdzie do tej pory nie było obsługiwanych przerwań).
RETI Zajmuje 2 bajty - z tego właśnie wynika zalecenie ustawianie najniższego bitu w wektorze na 0.
Ymmm... Nie ma związku między długością RETI a zaleceniem parzystości wektora (a w każdym razie ja się nigdy nie spotkałem w żdnych materiałach z taką sugestią). Z80 Manual twierdzi, że bit zero wektora ma być zerowy, ale procesor zachowuje się całkowicie poprawnie jeśli nie jest. RETI tak na prawdę jest zwykłym RETem z punktu widzenia programu a jedyna różnica jest taka, że urządzenia zewnętrzne z rodziny Z80 (SIO, CTC etc.) potrafią wykryć wykonanie RETI i przy odpowiedniej konstrukcji sprzętu umożliwiają spięcie kilku takich urządzeń z różnymi priorytetami przerwań.
I wszystko to w zasadzie nie ma praktycznego zastosowania w Spectrum bo... ULA. Sygnał przerwania jest generowany przez ULA w trakcie generowania ramki ekranu co oznacza, że na szynie nie ma "pływających atrybutów" a to oznacza, że procesor odczytuje w takiej sytuacji z szyny wartość 255 - zdecydowanie nieparzystą
Tyle idea przerwań maskowalnych w trybie 2 w Z80 - na ile sprzęt i software w ZXach trzyma się zasad - zobaczymy.
Pobadam sobie w symulatorze jak ULA zachowuje się odnośnie przerwań.
Ale tu nie ma czego "zobaczać" - od "prawie zawsze" wiadomo jak ULA się zachowuje i jak zachowują się przerwania.
Cytat ze stosownego rozdziału ULA Book'a:
The ULA does not place an instruction or vector address on the data bus when it generates the processor interrupt, so interrupt mode 0 cannot generally be used with the ZX Spectrum. Interrupt mode 2, on the other hand, can be used if the vector table is carefully constructed to return the same 16 bit address regardless of which pair of bytes are taken; therefore making the value on the data bus at the time the interrupt was generated irrelevant.
I szczerze mówiąc nie słyszałem o urządzeniach zewnętrznych dla ZXS, które używałyby do czegokolwiek przerwań w trybie 2 - z jednego prostego powodu: jeśli urządzenie ma rozszerzać normalne zastosowanie to musi umieć współpracować z BASICem a co za tym idzie musi umieć pracować w standardowym dla Spectrum trybie 1.
Cała twoja koncepcja zamknie się w tym, że twoje urządzenie musi umieć się dogadać z tym co zastanie a soft musi umieć się do tego dostosować i potrafić odbierać oba przerwania - w tym takie, przy którym stan szyny danych może być niezdefiniowany.
