Nie. Chciałem się tylko dokładnie przekonać, czy masz coś wartościowego do powiedzenia na ten temat. Bo widzisz, ktokolwiek zabiera się do budowy stołu, świetnie wie, i nie będzie o tym toczył dysput, ze stół, zeby był stabilny, potrzebuje czterech punktów podparcia co najmniej. TeBe, który rzucił pomysł implementacji multitaskingu, jest koderem, i jak wszyscy koderzy tutaj, świetnie wie, jak działa BRK, że jest to przerwanie IRQ i gdzie ma wektor. Zanim więc zarzucisz mi osobiste wycieczki, zastanów się proszę przez moment, o czym tu w zasadzie rozmawiasz i z kim.

Widzę, że jesteś bardzo przywiązany do koncepcji dosłownie pojmowanej maszyny wirtualnej, to znaczy do emulowania 6502 na 6502. Pozwól mi niniejszym wyrazić wątpliwość, czy zdajesz sobie do końca sprawę ze wszystkich konsekwencji wdrożenia takiego czegoś na Atari.

Na 6502 to się w ogóle nie da, bo nie zaimplementujesz ochrony pamięci.

Muszę stwierdzić, że wypowiadasz się dość mgliście. Czy to, że trzeba napisać od nowa handlery urządzeń, nie było już w tym wątku poruszane?

Wizja apokaliptyczna. Ale jednak trochę przesadzona. "Wyczerpujące API" sprowadza się do interfejsu pozwalającego na komunikację ze sprzętem poprzez sterowniki poszczególnych urządzeń. Sterowników może być wiele, ale ich rodzaje są zasadniczo dwa (znakowe i blokowe), a co za tym idzie, wszystkie urządzenia obsługuje się tak samo. Tak więc nie jest to aż tak totalitarne, jak to przedstawiasz.

Co więcej, w Atari są te dwa rodzaje sterowników, bo urządzenia znakowe obsługuje CIO, a blokowe SIO. Ale ta implementacja niezupełnie nadaje się dla systemu wielozadaniowego.

A mógłbyś jakoś detalicznie (i konkretnie przede wszystkim) objaśnić, na czym ten sam w sobie problem polega?

Poczytaj sobie to, co pisałem wyżej o PMMU.

Znowu DEC?  :D

Posiadają, jest to chyba nawet po prostu przerobione z SIO2PC (albo inspirowane). Tylko że serial w C-64 jest tragicznie wolny, ten komputer nie ma zdaje się żadnego UART-a.

W DracOS można wybrać dowolne miejsce dla strony zerowej. W momencie wystąpienia przerwania (w trybie natywnym) albo w chwili wywołania dowolnej funkcji systemu (za wyjątkiem tego cholernego pakietu FP), strona zerowa jest przestawiana pod adres $000000, a potem przywracana.

Co do stosu, nie widzę potrzeby. Cały system "chodzi" na stosie zdefiniowanym przez użytkownika. Poza tym przy tradycyjnych wywołaniach (przez JSR) OS i tak trzeba wywoływać w trybie emulacji. Z trybu natywnego przez JSR może się coś uda zrobić, ale jak już się jest w trybie natywnym, to lepiej skorzystać z przerwania COP #$00, wtedy wszystko powinno gładko działać.

[ Dodano: 07.05.2005 22:52:17 ]

Nie bardzo pojmuję, gdzie w tym widzisz problem.

No właśnie, sam mechanizm przełączania tasków to jeszcze jest najmniejszy problem.

Mimo twojego optymizmu co do szybkości przełączania na 6502, nie sądzę, żeby to było ogólnie takie proste. Przede wszystkim, system z wielozadaniowością nie mógłby być zgodny z systemem dotychczasowym, a to ze względu na deskryptory plików (każdy proces musi mieć oddzielne, podczas gdy obecnie jest osiem globalnych deskryptorów). Rozdzielenie tego wymusza poświęcenie dodatkowych cykli na przekopiowanie bloków IOCB; oczywiście, trzeba byłoby napisać DOS, który brałby to pod uwagę, bo zrobienie takiego numeru któremukolwiek z obecnych DOS-ów spowoduje jego malownicze sypnięcie się.

Druga rzecz, zapobieżenie temu, o czym piszesz powyżej, to znaczy, żeby uruchomienie 50 programów nie spowodowało, ze przełączenia tasków następują co sekundę (zamiast co 1/50 sekundy). Procesy trzeba podzielić według ich statusu, czas dostają tylko te, które "działają" (to znaczy, wykonują swój kod np. w pętli). Proces, który czeka na dane np. z klawiatury albo RS-232, albo SIO, nie dostaje czasu CPU, póki te dane się nie pojawią.

Pociąga to za sobą konieczność przekonstruowania handlerów urządzeń oraz powiązania ich z przerwaniami tak, żeby pojawienie się danych z klawiatury budziło proces, który na nie czeka. Dodatkowy problem: ma to być tylko jeden proces, to znaczy np. edytor tekstu, z któorym pracuje uzytkownik, a nie wszystkie, które wywołały funkcję odczytu danych z klawiatury.

Następna sprawa, która się z tym wiąże: programów mażących po ekranie może być wiele, ale tego, co produkują, nie mogą sobie zamazywać nawzajem. W związku z tym każdemu trzeba przydzielić oddzielny ekran, pomiędzy którymi to ekranami użytkownik będzie mógł się przełączać. Oczywiście, żeby to działało w miarę ładnie, programy muszą mazać na ekranie przez system operacyjny (albo przynajmniej wykorzystując wskaźnik w rodzaju SAVMSC $58), i nie mogą w tym celu odwoływać się bezpośrednio do sprzętu, bo efekt będzie taki, jak w twoim przykładzie (a nie o to chodzi).

To jest multitasking bez wywłaszczania. Do tego nie trzeba bardzo ingerować w przerwania ani w nic. Wystarczy przekopiowywać cały obszar pamięci programu. To nie jest trudne i mogłoby być nawet użyteczne. Ale oczywiście program, który jest "w tle", nie działa, stoi.

Zauważ, że w ogóle scheduler dobrze jest podłączyć pod VBL deferred, wtedy operacje krytyczne czasowo oraz przerwania IRQ automatycznie blokowałyby przełączanie tasków.

Nie przeznaczymy 64k na strony zerowe i stosy dla wszystkich aplikacji, zgadza się. Dlatego myślałem o tym, żeby w systemie dla 65c816 (z dodatkową pamięcią liniową) wykorzystać na stosy i strony zerowe banki pamięci 130XE. Im więcej banków, tym więcej aplikacji.

Kto chętny ... nie wiem, czy naprawdę jest sens pisania tego pod 6502. Będzie to chodzić, jakby chciało a nie mogło (z powodu kopiowania sporej ilości danych co ramkę), a na 65c816 nie będzie wykorzystywać wsparcia dla multitaskingu, jakie ten procesor ma.

Znam, ale nie na tym procesorze :P  :P

Fintik, w BASIC-u string typu S$ musisz deklarować przed użyciem przez np. DIM S$(3). Potem porównania typu IF S$="TAK" THEN cośtam powinny już działać. To tak tytułem przypomnienia  ;)

Patrząc na niektóre programy dochodzi się do wniosku, że nie ma takiej prostej rzeczy, której nie można byłoby spieprzyć.

Macgyver, akurat Lizard ma rację. "Specyfika gęstości" 360k zależy od stacji. XF-551 ma tak, jak napisałeś. TOMS w gęstości 360k ma tak samo, jak XF-551, dla zgodności, ale w gęstości 720k zmienia najpierw strony, a nie najpierw ścieżki, bo tak jest lepiej.

Karinka natomiast wszystkie gęstości dwustronne robi tak samo, jak TOMS robi gęstość 720k. Wniosek: dyskietkę 720k sformatowaną na Karin odczyta się na TOMS-ie, dyskietkę 360k sformatowaną na Karin można odczytać tylko na Karin.

Z tego co mi wiadomo, separator ">" jest wspólny dla MyDOS-a i wszystkich wersji SpartaDOS.