nie wiem czy to posuwa sprawe do przodu bo zalozmy ze nasze urzadzenie bedzie wrazliwe na ktorys bit d1ff

aktywujemy go... po czym wywolujemy inny ND, OS nadpisuje D1ff nasze urzadzneie sie odpina a wlacza inne, robi co trzeba i OS wylacza go na podstawie cienia ale juz nie tego ktore bylo wczesniej tylko swojego z ND i juz naszego urzadzenia nie wlaczy.

pytanie czy w przypadku gdy nasze urzadzneie nie zostanie zidentyfikowana jako ND to i tak bedzie mialo zarezerwowany bit w PDVRS ? (pewnie jest maska jeszcze ktora mowi ktore sa podlaczone do slotow) a my wlaczajac/wylaczajac nasze urzadzenie wykonujemy operacje na PDVRS i D1FF jednoczenie ? - to bedzie dzialac?

---
no i teraz jeszcze zauwazylem problem... a jak podlaczy pamiec niewyzerowana to "jakis" ID bedzie :/

caly czas wracam do tego aby urzadzenie MOGLO byc aktywne tylko jesli d1ff = 0 zeby system ND wogole go nienirpokoil.

nie, nie chce podlaczac 2 urzadzen na jednym bicie :/

caly czas szukalem mozliwosci takiej zeby system ND po uzyciu D8 dla wlasnyc potrzeb (inne urzadzenie) przwrocil stan zastany w d1ff i wszystko wskazuje na to ze tego nie zrobi. jedyna mozliwosc to kombinacja d1ff=0 ktora OS "przywraca".

wszystkie inne kombinacje wiaza sie z podpinaniem wlasnej tablicy przez urzadzneie w d800-d81c (chociazby pustej) na czas np. resetu

i sprawa jest jasna. uzycie systemu ND w tym przypadku jest wykluczone. urzadzenie o ktorym mowie nie moze odpowiadac na jakikolwiek niezerowy zapis do d1ff. moze byc aktywne tylko gdy d1ff = 0. calkowicie omijam system ND.
dodatkowo na d1 musi byc rejestr sterujacy urzadzeniem mowiacy miedzy innymi to czy w przypadku d1ff=0 urzadzenie ma byc aktywne czy nie. warunek aktwnosci na ta chwile powinien wygladac tak: d1.. = 1 AND d1ff = 0

przy okazji sytuacja ujawnia kolejna wade NewDevice... wyobrazmy sobie urzadzenie ktore korzysta z pamieci d8, niech to bedzie pamiec programu uzyta jak cartridge... user w programie wybiera opcje uruchomienia odczytu z dysku nie zdajac sobie sprawy ze ma dysk zainstalowany w systemie jako NewDevice. po wykonaniu operacji system sie zawala bo juz nie ma gdzie wrocic. ;-)

Dlatego wołem przeszło już dwie dekady temu w regulaminach zlotowych stało, by nie używać tego obszaru pamięci w czasie I/O. To nie jest żadna wada chyba, że uważasz za wadę samo istnienie OS i różnych jego mechanizmów.

znowu nie na temat Pin :/ mowa byla o uruchomieniu kodu z tej pamieci ktory wywoluje ND ..

ale poruszyles kolejna wade - to o czym piszesz wynika z niebuforowanego transferu ... podobny problem wystepowal pare lat temu jak sie pokawily multicarty, ale ten problem koderzy rozwiazali szybciej niz mrugniecie oka, i dzis mozna ladowac bezposrednio np. w obszar A000-BFFF mimo ze multicarty kartrdze w tym miejscu podlaczaja swoja pamiec... stuacja analogiczna do tego Twojego "regulaminowego" ale w przypadku car system ladowania zostal dziala. :D

@xxl: Cieszę się, że to latach negowania ND zacząłeś się uczyć do czego to w ogóle w Atari jest i jak działa.

Nie bardzo rozumiem Twoje obiekcje, bo:
1. PDVREG to nie jest żaden rejestr - kiedy CPU zapisuje pod ten adres każde ND sprawdza na magistrali danych stan odpowiadającego mu bitu i się aktywuje bądź nie - urządzenie w sobie ma odpowiednią elektronikę w której zapamiętuje swój stan i udostępnia lub nie swoje rzeczy w przestrzeni adresowej komputera używając sygnałów PBI.
2. PDVINT to nie jest żaden rejestr - kiedy cokolwiek czyta z tego adresu każde urządzenie wystawia status IRQ (o ile w ogóle urządzenie obsługuje IRQ) na odpowiadającym mu bicie magistrali danych.
3. ND nigdy nie aktywuje i nie dezaktywuje się samo z siebie - ZAWSZE robi to programista - czy to będziesz Ty czy OS to nie ma znaczenia.
4. Interakcja OS-a z ND następuje przy:
- RESET - wtedy OS przeprowadza detekcję urządzeń na magistrali i zapisuje sobie maskę PDVMSK żeby potem wiedzieć które urządzenia są obecne a które nie, po czym wywołuje procedurę inicjalizacyjną ND która to ustawia rejestry OS np. informując w PINTMSK czy obsługiwane są przerwania,
- SIO - wtedy OS zanim zabierze się za magistralę SIO odpytuje każde istniejące ND czy przypadkiem nie zajmuje się obsługą danego DEVID, dopiero kiedy żadne z ND się danym urządzeniem nie zajmuje odbywa się komunikacja przez SIO.
- IRQ - OS najpierw sprawdza czy nie nastąpił odczyt z SIO (jako że jest to operacja najbardziej krytyczna czasowo), następnie testuje czy któreś ND nie zgłosiło przerwania, w dalszej kolejności dopiero idzie reszta. Przy inicjalizacji ND ustawia maskę przerwań wskazując OS-owi czy obsługuje przerwania - OS uwzględnia ją czytając PDVINT bo na bitach magistrali danych nie dopowiadających jakiemukolwiek urządzeniu, albo kiedy urządzenie nie obsługuje przerwań są stany nieustalone.
5. Poza elektroniką obsługującą interakcje z Atari ND może mieć elektronikę która coś robi i działa całkowicie niezależnie od tego co się dzieje w Atari, stąd ND może zgłaszać IRQ, albo grać coś przez linię AUDIO. Szkoda, że nie może generować obrazu, ale co zrobić :/
Tak więc jeśli nie korzystasz z OS-a to wszystko leży w Twoich rękach.

W odnośnikach zewnętrznych http://atariki.krap.pl/index.php/PBI znajdziesz trochę informacji.
Polecam również link w http://atariki.krap.pl/index.php/ROM_PBI str. 32.

Edit: PDVINT a nie PDVSTAT.

w tym, że szukasz znowu dziury w całym :)

Rejestr czyli spis, wykaz, lista :)

wyimaginowane device moze zajmowac obszar: d1xx, d800-dfff, 8000-9fff, a000-bfff

zalozm ze ustawilismy (w d1xx) zezwolenie na dzialanie urzadzenia. najpierw kombinacje kiedy moze byc widoczne w obszarze d800-dfff. w przpadku gdy user chce wylaczyc ROM ale zachowac dostep do dev to korzysta z kombinacji na ktora sandardowy mmu atari (rozszerzony tez) nie reaguje

d1ff  /portb
0     1xxx xxx1   - ROM
0     0xxx xxx0   - RAM

przy czym podobno sytuacja w ktorej OS ROM jest wylaczony a d1ff <> 0 nie wystepuje w przyrodzie ale musimy byc na to przgotowani dlatego zawsze d1ff = 0

te kombinacje definiuja mozliwa widocznosc nowego urzadzenia (nie new device) w adresach d800-dfff

z czyms to moze kolidowac?