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.

Istotnie, otwarcie "E:" implikuje tryb 0, procedura otwarcia edytora w ciemno ustawia rejestr DINDEX na 0, bez patrzenia do ICAX2. Ale CIO kopiuje wcześniej ICAX1/2 na stronę zerową, a to z niej mają korzystać sterowniki w stylu "E:". Sterownik, który jest w ROM-ie nie zagląda pod ICAX2Z, ale nie można przewidzieć, jaki sterownik kto napisze w przyszłości. Zostawienie w ICAX2 i ICAX2Z wartości losowej (czyli nieustawienie ICAX2Z) zmniejsza ilość bajtów IOCB i ZIOCB, jakie mogłyby być wykorzystane dla przyszłych rozszerzeń systemu.

A ponieważ zrobienie LDA #$00 / STA ICAX2 (albo STZ ICAX2) nie kosztuje dużo, wobec tego proponuję mimo wszystko zerować ICAX2 przy otwieraniu edytora. Taka mała wprawka z eleganckiego programowania  ;)

Piguła, sprawa nie tyczyła się interfejsu KMK, tylko dysku Caviar WDC2850. Masz tam wyłożone łopatą, co trzeba zrobić (= co musi zrobić soft inicjujący dysk do pracy), żeby ten dysk działał.

Moim zdaniem zasłużyłem na obiecane pół skrzynki browca, ale dodatkowe browary po koleżeńsku też chętnie przyjmę  ;)

Dokładnie. Ktoś, powodowany chęcią bądź potrzebą posiadania twardego dysku, może się skusić na zakup z zamiarem użytkowania. Wtedy powinien sobie zdawać sprawę w pełni, że sprzęt ma kilka mankamentów, które wymieniłem:

1) napęd małej pojemności

2) napęd nie IDE czy SCSI, ale MFM, czyli przedhistoryczny

3) fakt, że napęd ma bardzo wiele wiosen

Punkt 3 wskazuje, że dysk może paść szybko (o ile w ogóle jeszcze nie padł), punkt 2 natomiast, że znalezienie sprawnego zamiennika może graniczyć z nieprawdopodobieństwem, ergo kwota wydana na ten dysk będą to pieniądze wyrzucone w błoto.

20 MB. Sorry, to nawet jak na małe Atari jest 5x za mało, a co dopiero ST. Poza tym napęd MFM, ma pewnie dobrze ponad 15 lat. Rzęch, i trudno wymienić na inny.