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.

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.

O mnie prosze się nie martwić.

Na początek wystarczy brak tonu moralizatorskiego i osobistych wycieczek.

Uważam kwestię wydajności za istotną, a samo zadanie jako sztukę dla sztuki. Moim zdaniem większym wyzwaniem jest zrobić to w dziedzinie takiej jaką dysponujemy, czyli standardowe Atari z procesorem 6502, aniżeli iść na łatwiznę. Równie dobrze można sobie pisać system operacyjny z obsługą wielowątkowości na PC'ta, tyle że nie o to chyba chodzi. Po prostu opieram się na innych założeniach.

Oczywiście. Nie ma żadnych problemów aby na drodze programowej to wykonać.

Z całym szacunkien dla Pańskiej osoby, ale odnoszę wrażenie, że dyskusja zbacza z tematu. Proszę mnie poprawić, ale wydaje mi się, że dyskusja na temat tego czy ja widziałem coś czy nie, ma się nijak do merytoryczności tego wątku, dlatego proszę Pana o całkowite wyeliminowanie elementów osobistych w tym wątku.

Tak samo jak na warstwie sprzętowej, tylko zasymulowane programowo.

Myślałem o implementacji tego na zwykłym 6502...

Co do API, to owszem, może i jest jakaś baza, ale z pewnością nie pełna. Dostęp do pełnego ekranu w trybie ekskluzywnym należałoby dopisać, pewnie na podobnej zasadzie wiele innych elementów związanych ze sprzętem, jak dźwięk, klawiatura. Teoretycznie gdyby zaprojektować coś w stylu bajt-kodu na odpowiednim poziomie integracji z wystarczająco szerokim API systemowym, całość miałaby sens, tyle, że to API musiałoby być naprawdę wyczerpujące, obszerne, zoptymalizowane pod kątem prędkości wykonywania. To raczej nie wchodzi w rachubę...

Co do BRK i przerwań, to widzę to po prostu jako problem sam w sobie. Uważam, że puszczenie wątku na żywioł nie ma sensu, także z tego powyższego powodu. Istnieje wiele powodów, które mogłyby spowodować destabilizację całego systemu podczas wykonywania dowolnego zadania (zawierającego błąd, ale niekoniecznie), dlatego zastanawiam się, czy wogóle to ma sens w takiej formie jak jest proponowane.

Pamiętajcie, że rozkaz BRK powoduje wywołanie przerwania spod adresu przechowywanego pod $fffe, które w praktyce należałoby filtrować. Obawiam się, że wszelkie odwołania do rejestrów sprzętowych, w szczególności te związanie z przerwaniami nmi oraz irq stanowią poważny problem.

Yes.

SubPlayInstrument
    lda    #3
    sta    $d20f
   
    ldy    SampleNumTmp
    lda    Notes+0
    clc
    adc    (InstrCh0Adr),y
    tax
    lda    FreqTbls+FRQ_TBL_INDEX,x
    sta    AUDF1

    lda    (InstrCh1Adr),y
;    lda    #$03
    ora    #DISTORTION
    sta    AUDC1
   
    inc    SampleNumTmp
    rts

Will send also an email.

Sądzę, że miałem identyczny problem. Wpisanie #3 do $d20f rozwiązało moje problemy. Najlepiej jest to robić tuż przed odświerzeniem rejestrów dźwiękowych $d2xx (0-7) $d21x (0-7). Po tym zabiegu wszystko brzmi zawsze tak samo, tzn. takie jest moje odczucie.

Swego czasu miałem dylemat, czemu MPT odtwarzało czyściej dźwięki, aniżeli CMC oraz Delta.

Poza tym polecam lekturę "DeRe Atari", czy coś w tym stylu. Tam jest opisane dokładniej jak działa POKEY, z tego co pamiętam.

Czy ja dobrze się domyślam i dzięki wyprowadzeniu szyny adresowej oraz danych na wyjście cartridge'a można pruć po pamięci Xe?

Cartridge można zamówić przez sieć. Nie trzeba wysyłać sprzętu. Prawdopodobieństwo posiadania zorientowanego elektronika w otoczeniu jest małe.

Ja osobiście się nie upieram. Uważam, że 65816 wydaje się być rozsądnym kontynuatorem 6502. Nie ma sensu uczyć się nowego, kompletnie odmiennego assembler'a, kiedy ten z 65816 stanowi ~99% zasad pisania programów/składni 6502. Jest to wyważona ewolucja, moim zdaniem.

Osobiście widzę niepodważalny argument na korzyść rozwiązania Pasia, a mianowicie możliwość pracy ze zwiększoną wydajnością dla starych programów. Może się jednak w praktyce okazać, że wcale nie będzie to zaleta, a wada, bowiem wielu programistów, jak się domyślam, może nieprawidłowo dokonywać aktualizacji parametrów ruchu, tzn. w funkcji ilości wyświetlanych klatek, zamiast upłyniętego czasu.

Jeżeli to byłby procesor (typu 65816), to moim zdaniem nie ma sensu się generalnie ograniczać do jakiegoś konkretnego, wąskiego zastosowania. Mogę jednak podać konkretny przykład, jaki mi się nasuwa, a mianowicie mnożenie 8bit * 8bit (128 KB) oraz odwrotność 65536'ciu wartości (128 Kb, lub więcej, w zal. od precyzji). Z pewnością można znaleźć wiele innych zastosowań.

Rozumiem. Do celów, o jakich ja myślałem, byłoby to wystarczające, jak sądzę (demoscena).

Owszem, ale inne rozwiązanie oznacza rozmontowanie malucha. Tego chciałem uniknąć przede wszystkim. Dla mnie rozwiązanie z zewnętrznym modułem (poza komputerem) jest kompromisowe.

Nieporozumienie. Miałem na myśli całkowity brak demontażu komputera. Jakikolwiek.

Nigdzie nie pisałem, że karta zewnętrzna ma mieć możliwości rozszerzenia wewnętrznego i nie było to moją intencją wypowiedzi.

Osobiście nie widzę żadnego sensu ograniczania funkcjonalności procesora do jakichkolwiek operacji, w tym konkretnym przypadku.

Miałem na myśli stworzenie rozszerzenia, a nie rozbebeszenia malucha. Rozkładanie komputera na części sprowadza się niestety do tego, czego tygryski wcale nie lubią najbardziej, czyli do kompletnej abstrakcji, czyli w zasadzie można tam wstawić co się chce... dowolny procesor, dowolne rozszerzenie, a wiadomo, że "prawdziwym atarowcom" nie o to chodzi :> Instalowanie rozszerzenia w oparciu o istniejący mechanizm cartridge'a ma swoje poważne zalety:

a) nie przeprowadzamy operacji na pacjencie
b) bardziej komercyjny charakter/zero transporu całego sprzętu
c) interfejs cartridge'a ma bodajże wyprowadzoną szynę adresową

Co do komunikacji, to wystarczy natywna dla malucha. Potęgę ma tworzyć zewnętrzna w stosunku do 6502 kalkulacja danych. Transfer późniejszy może być wolniejszy/standardowy. Powinno to być satysfakcjonujące.

Oczywiście, formalnie do cartridge'a także można włożyć co się chce, ale wydaje się, że sensowniej/wygodniej jest wprowadzenie procesora oraz układów o architekturze zbliżonej do natywnego 6502, czyli 65816.

Co do dodatkowej pamięci - jak najbardziej. Okolice 0,5MB  1 MB byłyby satysfakcjonujące.

Można nawet pakować teoretycznie tam drugiego POKEY'a zamiast rozbebeszać atarkę do kolejnych zmian. Krótko mówiąc jest to rozwiązanie bardziej elegenckie i w "duchu Atari", naszego małego komputerka. Oczywiście domyślam się, że będzie wiązało się to z pewnymi problemami (zasilanie), ale pewnie je także można obejść (dodatkowe/wewnętrzne zasilanie/akumulatorki). Co o tym sądzicie?

Oczami wyobraźni widzę te silniki 3d generujące grafikę w trybie 2x2 w znośnej ilości klatek na sekundę. Istnieje wiele innych propozycji co do wykorzystania portu cartridge'a, ale na razie na tym zakończę.

Pozdrawiam