26

Przestańcie sobie jeździć wzajemnie po ambicji oraz nie łapcie się wzajemnie za słowka - wyjdzie to na lepsze merytorycznemu poziomowi dyskusji.

Dyskusja się skończyła dwa dni temu  :P

KMK
? HEX$(6670358)

27

oczywiscie na C64 istnieje juz taki psudo-multitaskowy system (do 30 procesow) zwie sie Lunix

ciekawe jak oni sie do tego zabierali ze zdolali cos zrobic :)

z ta emulacja Konop ma racje, moze zbyt doslownie go zrozumieliscie, piszac aplikacje nalezaloby zrezygnowac ze wszystkich rozkazow odwolujacych sie do stosu i strony zerowej, przerwania wylaczone koniecznie

czysto teoretycznie wygladaloby to tak: wywolujemy task, jako parametry podajemy mu nowy adres stosu i strony zerowej, odpowiednie procedury modyfikuja procedury emulujace stos i strone zerowa, task rusza

wlasciwie ze strony zerowej moglibysmy zrezygnowac i emulowac tylko stos, MADS udostepnia stos programowy (malej poprawki dotyczyloby tylko wywolanie procedury w MADS), np.

; wywolanie procedury w MADS po nazwie procedury

 nazwa_procki

; MADS wymusza:
;
; JSR NAZWA_PROCKI
;
; a wiec juz korzystamy ze stosu sprzetowego $0100-$01FF
; teraz wystarczy poprawic MADS tak aby wykonywal tutaj makro,
; ktorego parametrem bedzie nazwa procedury (a wiec jej adres),
; np. na takie:
;
; .macro @EXECUTE
;    ldx @stack_pointer
;    lda >:1
;    sta stack,x
;    lda <:1
;    sta stack-1,x
;   
;    txa
;    sec
;    sbc #2
;    sta @stack_pointer
;
;     jmp :1    ; a najlepiej BRA :1 dla 65816 i bedzie relokowalne
;
;  .endm
;

.proc nazwa_procki

.endp

makro @CALL odkladajace parametry procedur na stos programowy moze zostac, natomiast makro @EXITPROC musi zostac poprawione, na np.:

.macro @EXITPROC

 ldx @stack_pointer
 lda stack,x
 sta _jump+1
 lda stack+1,x
 sta _jump+2

 txa
 clc
 adc #2
 sta @stack_pointer

_jump jmp $FFFF

.endm

tak wiec narzedzie jest, do tego konfigurowalne, oprocz nowego sposobu tworzenia aplikacji, musi istniec system udostepniajacy podstawowe komponenty, posredniczacy w komunikacji miedzy sprzetem a aplikacja

niewatpliwie najmilszy jest 65816, zaczalem pisac takie srodowisko wlasnie dla niego, latwiejszy relokowalny kod (skok bezwarunkowy BRA), stos programowy o rozmiarze wiekszym niz 256B, ktory latwo adresowac dzieki rejestrom 16-bitowym

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

28

piszac aplikacje nalezaloby zrezygnowac ze wszystkich rozkazow odwolujacych sie do stosu i strony zerowej, przerwania wylaczone koniecznie

Co do stosu - zgoda, co do strony zerowej - niekoniecznie. Można teoretycznie udostępnić wątkom pewną przestrzeń strony zerowej bez przerzucania jej, albo też większą z przerzucaniem. Przerwania w praktyce musiałby być rzeczywiście wyłączone dla wątku.

Istnieje możliwość podzielenia stosu na części - bez konieczności buforowania go - mam tu na myśli zarządzanie wskaźnikiem stosu (rozkazy TXS, TSX). Ma to sen o tyle, że programy raczej nie korzystają zbyt intensywnie z zagnieżdżeń. Dla paru wykonywanych programów ma to sens, a najlepszym rozwiązaniem jest hybrydowe, czyli do momentu gdy pula stosu $100 bajtów wystarcza można na nim ciągnąć parę stosów dla zadań, a po przekroczeniu tego zakresu zarządzać poprzez buforowanie. Wydaje się to być optymalnym rozwiązaniem.

wlasciwie ze strony zerowej moglibysmy zrezygnowac

Problem polega na tym, że przynajmniej na 6502 rozkazy w trybie pośrednim indeksowanym są dosyć powszechnie używane i funkcjonalne, a zatem rezygnacja z tego trybu byłaby moim zdaniem b. dużym ograniczeniem.

Po zastanowieniu doszedłem też do wniosku, że emulacja kodu 6502 nie byłaby aż tak wolna, jak pierwotnie to wcześniej określiłem. Można napisać szybki kod, odrzucający wstępnie przypadek przekroczenia zakresu i wogóle operować na offsecie strony, a nie pełnym słowie.

Istnieje też inna propozycja założeń - bez ochrony wielu elementów, ale puszczona na max. prędkości. Może będzie okazja później o tym coś napisać, jeśli będzie takie zainteresowanie.

29

z ta emulacja Konop ma racje, moze zbyt doslownie go zrozumieliscie

Dobrze zrozumieliśmy, taki system to czyste zawracanie głowy.

KMK
? HEX$(6670358)

30

a może by rzucić się tak nieco w stronę tego Lunixa, czy jak mu tam? ;)

I Ty zostaniesz big endianem...

31

osobiscie jestem za jednym taskiem (procesem), gdzie cala moc CPU przydzielana jest wlasnie temu jednemu procesowi

wyobrazcie sobie obsluge myszki w multi-taskingu, przy kilku procesach, opoznienia wplyna na plynnosc ruchow myszki ktora jest zalezna wlasnie od czestotliwosci odczytywanie jej koordynat

najlepiej gdyby bylo sprzetowe wsparcie mychy, inaczej najlepszym manipulatorem staje sie JOY odswiezany na VBL'u

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

32

Jeśli zamierzasz robić coś w rodzaju GEOS-a (a zdaje się, że pamiętam taką wzmiankę), to możesz pójść na kompromis. To znaczy, zachować możliwość korzystania na raz z paru programów ale bez wywłaszczania. Nie wiem, jak się to nazywa po polsku, ale po angielsku to jest cooperative multitasking. Dobrym przykładem jest np. Geneva na Atari ST. Działa to całkiem dobrze i daje bardzo duże złudzenie rzeczywistego multitaskingu, póki, oczywiście, nie zapuścisz pętli w rodzaju

jmp *

Działa to na zasadzie pętli zdarzeń, która jest w środku managera aplikacji. Zakłada się, że każdy program czeka na jakieś zdarzenie (w rodzaju: naciśnięcie klawisza, kliknięcie na element okna, upływ określonej ilości czasu, wybranie czegoś z menu, określone ruchy myszą - wejście w zdefiniowany obszar albo wyjście z niego - itp.), reaguje na nie, a potem z powrotem wraca do czekania.

W takim układzie zadanie podziału czasu pomiędzy "procesy" może spełniać pętla zdarzeń. W chwili, kiedy program zadaje jej oczekiwanie na np. naciśnięcie klawisza, a żaden klawisz naciśnięty nie jest, pętla spokojnie może oddać czas do innego programu, który czeka na inne wydarzenie, a to w międzyczasie wystąpiło (np. upływ zadanej ilości czasu).

Efektem jest, jak napisałem powyżej, dość dobre złudzenie wieloprocesowości, a przy tym łatwiejsza jest synchronizacja wszystkich zadań, no i scheduler powieszony na przerwaniu VBL nie zabiera czasu, bo go nie ma wcale.

KMK
? HEX$(6670358)

33

Mutlitasking na malym atari czemu nie ? Kiedys z kuplem zaczelismy cos takiego pisac (zarzadca procesow na timerze pokeya) i nawet dzialalo :-).
Chyba kazdy sie zgodzi ze nie jest raczej mozliwe takie zmodyfikowanie OS aby dzialaly programy obecne. A te przystosowane do multitaskingu nie moga korzystac z rejesterow sprzetowych/pamieci bez allokacji. Ot i cala filozofia. (Oczywiscie generalizujac co nieco)

34

Kurcze, ale żeście się rozwinęli...

Po pierwsze, to po polsku ?multitasking? to "wielozadaniowość", czyli uruchamianie wielu aplikacji na raz. Nie koniecznie wiąże się to z jakąkolwiek architekturą sprzętową, można to zrobić ?lajtowo? - wystarczy, żeby można było uruchamiać kilka aplikacji na raz.

Ochrona pamięci ? super, ale o ile dobrze się orientuję, Amiga tego nie miała (500, 600), i żyła.

Współdzielenie zasobów ? no to właśnie o to by chodziło w tym projekcie pewnie.

?Ręczne przełączanie między zadaniami? ? jeśli tylko o to chodzi, to takie coś to już prawie było na Atari ? patrz soft z Avalonu - można było mieć jakiś kalkulator, notatnik, debugger i system jednocześnie w pamięci.

Co do realnych rozwiązań, to nawet coś takiego jest na nasze skromne 65C02 - Contiki.

http://en.wikipedia.org/wiki/Contiki
http://www.sics.se/~adam/contiki/index.html

Pozdro

I'm not so bad, once you get to know me.

35

a udalo ci sie to odpalic na prawdziwym atari? bo  o ile wiem contiki na atari po prostu nie dziala. wyprowadz mnie z bledu jesli sie myle

36

Oczywiście... że nie. Ale ktoś tam się tym zajmuje i pewnie jesli kto chetny to można się podłączyć do projektu. Z tego co widze, to jest zresztą na SourceForge'u.

Port Atarowski jest troche biednawy, ale to w koncu tylko 400kb kodu w C (wersja międzyplatformowa). Mam w programach pojedyncze moduły tej wielkosci... Jesli komus by zalezalo na takim systemie, prawdziwy port c64 -> atari nie powinien byc niczym trudnym.

Pozdro

I'm not so bad, once you get to know me.

37

No wiec o czym rozmowa? Bedziemy uzywac kulawej protezy, dodatkowo niedokonczonej i niedzialajacej?
IMHO jesli chcemy zrobic _dobry_ multitasking, to sprzetowe wsparcie, chocby minimalne, zarowno ze strony procesora jak i mmu 
jest niezbedne. Wyklucza to istnienie _dobrego_ multitaskingu na 6502. Cala ta gadanina o softwarowym multitaskingu to zadanie czysto akademickie i jak widac ma swoich zwolennikow. Nie przecze ze problem moze byc ciekawy z punktu widzenia czysto teoretycznego. Wierze w twoje dobre checi ale podzielam poglad czesci dyskutantow ze multitasking na 6502 to 'zawracanie glowy'

Pax

ps. wczesniej nie widzialem tego watku dlatego prosze sie nie gniewac ze tak pozno reaguje, dodatkowo moze ktos jeszcze zauwazy ten watek i sie wypowie :) (ah, te trollfesty i flamewary ;)