ale to znaczy ze atari moze wygenerowac niezidentyfikowane przez os przerwanie irq ?

---
wyglada na to ze tak. co mogloby byc zrodlem takiego przerwania?

przerwanie pbi obslugiwane jest tu:

$C047  lda $D1FF
$C04A  and $0249
$C04D  beq $$C052
$C04F  jmp ($020A)
$C052  ...

ale sluszna uwaga, czyli jesli urzadzenie pbi moze zglosic przerwanie irq ale sterownik tego urzadzenia podczas inicjalizacji nie zglosi do systemu ze urzadzenie ma taka mozliwosc to os atari zawsze wyladuje tu: $C0C9 ? jakis czas sie to wykonuje, czyli przyspawamy 2 kabelki z pokretlem zmianiajaca czestotliwosc generowania takich niezidentyfikowanych przerwan i mamy mozliwosc recznego sterowania szybkosci dzialania programow ???

no powiedzmy ze tak... ale podobna procke nierozpoznanego przerwania maja wszystkie atari, nie wiem, czy atari np. 400 lub atari5200 tez ma pbi?

zalozmy ze tak bylo. czy nie rozsadniej by bylo zastosowac dokladnie ten sam schemat jak w calej procedurze obslugi przerwania niemaskowalnego i skoczyc przez wektor (powiedzmy wektor przerwania niezidentyfikowanego) do procki opuszczajacej przerwanie? to by mialo sens, bo z OSa mozligysmy takie 'dziwne' urzadzenie obslugiwac. nie jest to zadne zabezpieczenie bo uzywajac OS nic z tym nie mozemy zrobic, ani oprogramowac ani nawet wykryc takiej sytuacji (bez odlaczania OS).

czy oprocz zle zdefiniowanego urzadzenia PBI cos moze wygenerowac takie niezidentyfikowane przerwanie?

Byłoby rozsądniej (tak jest np. w ST). W ogóle to nie wiem, dlaczego jest tam to PHA/PLA/RTI, chyba wystarczyłoby RTI zamiast tego. Ale może chodzi o pozostawienie 3 bajtów miejsca na JMP () przez wektor użytkownika (który jak sobie doda urządzenie generujące "niezidentyfikowane" przerwanie, to może sobie i OS spaczuje). Albo po prostu o pozostawienie miejsca na przyszłe rozszerzenie o taki wektor.

No ja właśnie o tym mówię, że nie wiem, po co jest PHA/PLA/RTI, a nie, po co jest LDA. Zamiast PHA można byłoby dać RTI i chyba wyszłoby na to samo (tylko zaoszczędziłoby się 7 cykli).

Zważywszy, jak już zauważył Fox, że linia IRQ jest wyprowadzona na PBI/ECI, tym źródłem może być cokolwiek, co sobie skonstruujesz i tam podepniesz (choćby to były dwa druty z przełącznikiem).

jeszcze to:

$C0A2  bit $D302
$C0A5  bpl $C0AD
$C0A7  lda $D300
$C0AA  jmp ($0202)
$C0AD

i niby wszystko jasne i wlasciwie zgodne z tym co jest w literaturze i atariki, ale pierwszy port PIA ma dwie linie do portu SIO, ta procka wyzej bada przerwanie na jednej z nich. w dokumentacji PIA jest, ze druga linia tez moze byc zaprogramowana jako wejscie przerwania i zglasza to bitem 6 czyli w powyzszej procedurze brakuje rozkazu:

BVC

no i wlasnie to jest niezgodne z literatura bo np na atariki mozna przeczytac ze sa to kombinacje nieuzywana (w takim razie po co jest inicjowana tak, ze zostaje programowo wylaczona).
czy po wlaczeniu atari zacznie przyjmowac przerwania dwoma niezaleznymi liniami na porcie A? caly czas mowie o porcie A a nie porcie B!!!

jesli to prawda, to procka rozpoznania przerwania IRQ w atari ma co najmniej dwa bledy.

a moze sie myle i faktycznie na atari to jest jakos sprzetowo zablokowane. moze to ktos zweryfikowac przynajmniej teoretycznie?

tylko, z czego pamiętam ZX Spectrum jest komputerem na tyle prostym w budowie, że "spowalniacz" nie jest trudnym do zaprojektowania "urządzeniem" ;)-

Tia, sformułowania w literaturze sugerują, że te bity nie są wykorzystywane przez PIA. Jeśli jest inaczej, trzeba to rzecz jasna poprawić.

Natomiast nie wiem, czy brak obsługi tego w OS-ie to jest taki znowu "błąd". Ostatecznie wszystkie "nieobsługiwane" przerwania można obsłużyć przez vimirq (jak już parę postów temu zauważył mono). Ten wektor właśnie po to m.in. jest.

Jeśli Motor Control można użyć jako wejścia przerwań tylko po wypruciu z Atari tranzystora, to oznacza, że to przerwanie jest, jak sam wyżej napisałeś, sprzętowo zablokowane i OS nie ma potrzeby go obsługiwać. Jeśli ktoś zmodyfikuje Atari, to i pod vimirq się spokojnie może podwiesić z obsługą.

Ogólnie, to fajnie, że na SIO może być 1 albo 2 sygnały IRQ więcej, niż jest ich tam "oficjalnie". Tyle że chyba nawet tych dwóch, o których wszyscy wiedzą, nikt nie używa.

Ogólnie 2, to w Atari OS jest parę błędów rzeczywistych, tzn. takich, które powodują jakieś problemy. Brak obsługi przerwań, które i tak nie występują, to jest raczej szczegół.

Panowie, jak tak was czytam to się boję że zaraz w GTIA akcelerator 3D znajdziecie ;)

@Adam, to zalezy od Electrona :D http://atariarea.krap.pl/forum/viewtopic.php?id=8378

@Krótki: nie wydaje mi sie, jesli masz 4 stacje podlaczone jednoczesnie to taka sytuacja wystepuje caly czas i nic zlego sie nie dzieje. zeby uruchomic jakas akcje musi byc wspolpraca PIA i POKEYA po stronie atari.
ale pobujajmy troszke: zalozmy, ze napiszemy sobie bios dla stacji np.2001 w ktorym damy mozliwosc stacji dyskow samodzielnego nawiazywania kontaktu z inna stacja w systemie? dzieki bitowi PBCTL moglibysmy wykryc takie urzadzenie w lancuszku SIO ;-)

> Podczas współpracy komputera z 4 stacjami dysków wszystko się dzieje zgodnie z protokołem SIO, więc stwierdzenie "taka sytuacja występuje cały czas" wygląda na oderwane zarówno od rzeczywistości jak i od tej dyskusji.

jesli komputer wysyla komende do stacji numer x to COMMAND jest zwarty a 3 pozostale stacje nie szaleja. to normalna sytuacja.

> A w jaki sposób ...

no to podlaczmy kilka komputerow i kilka stacji dyskow w siec. jak moglaby wygladac siec zbudowana w oparciu o SIO? sprobujmy. mamy do dyspozycji 3 bity statusu linii przerwan. mozemy je dowolnie programowac jako wejscie i wyjscie wiec z dowolnego kompa w sieci mozemy ustawiac bity w PIA na kazdym innym komputerze w sieci. dowolny komputer aby przeprowadzic jakas operacje sprawdza status jednego z tych bitow (odpowiedzialnego za zajeta siec) jesli siec jest wolna ustawiamy bit i przeprowadza komunikacje, skonczyl, uwalnia siec. pomysl na szybko. moze to tak dzialac?