Założyłem dla PC-Softsyntha repozytorium na gitlabie. Pobawię sie nim jeszcze.

https://gitlab.com/pik33/pc-softsynth2

Mam teraz Propellera 2 - zdążyłem napisac na niego audio driver który potrafi zrobic użytek z plików .s2 i .h2 PC-Softsyntha (przy okazji działa też jak Amigowa Paula) - może uda mi się przeportowac interpreter na Propellerze, tudzież zrobic moduł który umozliwi granie softsynthowymi samplami z klawiatury MIDI.

Tutaj założyłem temat dla projektu: https://forums.parallax.com/discussion/ … h/p1?new=1 - to już nawet gra.

Standard. To się nazywa pipeline. Instrukcje są pobierane i wykonywane z wyprzedzeniem - jmp czyści tę kolejkę, bo musi. Wyczyszczenie kolejki to konieczność jej załadowania od nowa i mnóstwo zmarnowanych taktów zegara. Dlatego nie poleca się tworzenia kodu samomodyfikującego się na współczesnych maszynach.
No a jak się kolejki nie wyczyści, wykona się instrukcja sprzed modyfikacji.

Co innego 6502.

A jak ktoś chce na nowym sprzęcie, Parallax Propeller. On też ma kolejkę ale płytszą i 2 nopy wystarczą. Ale ma też instrukcje manipulujące rozkazami już pobranymi bezpośrednio w kolejce.

Sytuacja bardzo charakterystyczna dla, na przykład Raspberry Pi.

Procedura napisana w Pascalu, skompilowana do natywnego kodu, wykonuje się 20 razy wolniej niż robiąca to samo procedura, ale napisana w żywym asemblerze.

Różnica jest taka, że w procedurze pisanej w asm upchałem ile się da zmiennych w rejestry, wykorzystując nawet R14, na co żaden kompilator się nie odważy. Poza tym procedura, po uprzednim zdjęciu blokady dostępu z RAMu wykorzystuje obszar kodu na zmienne lokalne.

Dzięki temu większość operacji procesor robi na rejestrach, od czasu do czasu ładując coś lub zapisując do RAMu pojedynczymi instrukcjami ldr/str

Ponieważ kompilator nie dotknie nie tylko r14, ale jeszcze paru innych, spora część zmiennych w wersji kompilowanej przechowywana jest w pamięci i to w obszarze danych, co powoduje że na jeden dostęp do zmiennej potrzebne są 2 instrukcje ldr/str.

No i procesor stoi, czekając na dane z pamięci - LDR kosztuje w malinie trójce, tak na oko, jakieś 3 nanosekundy. ALU mogłoby w tym czasie wykonać kilka instrukcji, ale nie robi. Bo czeka.

Tylko kto dziś, w czasach wszechobecnego Pythona i Javascriptu, zwraca na to w ogóle uwagę?

Dziś już nic nie trzeba. Atari 800 kompiluje się ładnie na RPi 3 i 4 z ich githuba. Do Amibiana wystarczy dodać plik binarny plus parę bibliotek. Sam powie przy starciew czego mu brak :) No i dodać do menu (=edycja plików tekstowych z konfiguracją Amibiana)

Mam teraz lepszą zabawkę, Propellera 2. Na tym powinno się dać zrobić całe Atari. Potrzebny mi tylko czas na zabawę, a z tym jest nie najlepiej.

Lama. Nie kupuję chleba, sam piekę, na zakwasie, bez konserwantów i polepszaczy.

Jaka by nie była statystyczna śmiertelność, covid to rosyjska ruletka. U mnie w pracy przechorowało chyba już ponad 10 osób i żyją, ale kolegę z klasy pochowali.

Usiłuję ogarnąć programowanie tego chipa, bo choć ideowo podobny do jedynki, różnic jest cała masa.

Jakośc DACów jest bardzo wysoka, P2 podpięty do wzmacniacza odkręconego pod korek praktycznie nie szumi. Dali dobre stabilizatory LDO na płytce co też robi robotę. Poza tym co ma tam szumieć, jak jest 16 bitów rozdzielczości przy 1.25 MHz częstotliwości próbkowania? Wygląda na marzenie audiofila :) Jeśli ADC jest tak samo dobre, a jeszcze nie testowałem, można mieć coś do audio co ma 32 wejścia, 32 wyjścia i po drodze robi co się da z tym dźwiękiem bo przecież mając 8*150 MIPS można juz coś zrobić.

Do ADC nie znalazłem gotowców, które pewnie są rozproszone na forum, a żeby napisać samemu, trzeba mieć chwilę czasu i świeżą głowę.  Nie miałem czasu w tygodniu na zabawę, choć poczytałem sobie wciąż niepełną doumentację.  No ale spróbuję najprostszą rzecz: ustawić 2 nogi na ADC, dwie na DAC, czytać z ADC, pisać do DAC: kilkanaście linijek kodu.  Jest gotowiec od którego można zacząć - generator sinusa na DAC. Generator używa CORDICa, który też jest genialnym wynalazkiem, bo o ile operacja trwa 56 taktów, o tyle można wywołać go co 8 taktów i również co 8 zbierac wyniki.

Obiecują dla ADC, w trybie który nazwali sinc3, ENOB 18 bitów @ 1.25 MHz, czyli znowu: szumu na audio nie powinno być słychać: eksperyment pokaże. Jutro albo w niedzielę.

Nietypowa konstrukcja generuje nietypowe rozwiązania. Chip ma IO 3V3 natomiast np. pamięci HyperRam są szybsze w wersji 1V8. Jak dopasować logikę 3V3 do 1V8? Proste: użyc DACów. Przy 8 bitach wystarcza im 3 ns, co z zapasem pozwala zorganizować transmisję @ 200 MHz. W drugą stronę natomiast, na wejściu, też użyć DAC i komparator na nóżce. Ta metoda pozwala na zorganizowanie interfejsu na dowolnym napięciu <3v3. Temat do ogarnięcia, na forum parę osób kombinuję. Sam nie pokombinuję z braku płytki z HyperRamem, ale może pokombinuję z maliną zerówką: spróbuję zrobić z niej RAM do Propellera.

Eksperymentowałem z HDMI. Tu ograniczeniem jest częstotliwość procesora bo strumień HDMI wychodzi dokładnie z tą częstotliwością, 1:1. Maksymalnie da się ten układ taktować gdzieś tak do 370 MHz i to ogranicza rozdzielczość HDMI. Wypuściłem 1024x576@50 Hz przy 330 MHz. Do celów atarowo-amigowych spokojnie wystarczy. Jak nie, zawsze jest VGA. Mam parę pomysłów na driver video, w sumie poczytałem sobie instrukcje, więc czas na zabawę w programowanie.

Chip potrafi się podnieść z podpiętego flasha SPI, co trwa niezauważalny ułamek sekundy, albo z karty SD. Karta może być sformatowana na fat32, wtedy Propeller wstaje z pliku o odpowiedniej nazwie, albo moze być niesformatowana, wtedy binarkę wrzucamy w żywe sektory na początek karty. Ze sformatowanej wstaje zauważalnie dłużej niż z flasha, nieformatowanej, z braku narzędzi, nie testowałem.

Idiotyzm. Jest tyle sposobów wywołania eksplozji że musieliby zabronić sprzedaży czegokolwiek i nauczania chemii w szkołach.

Kto wie. chip jest dość mocny a i overclock (masywny, próbowali 370 MHz) jest możliwy. 8 pinów może mieć sporą autonomię pracując niezależnie od CPU i mając własny kod w asemblerze i to jest podstawowa różnica między tym układem a innymi mikrokontrolerami. Szkoda że DACów nie dodali: pozostaje PWM.

Mają być w sprzedaży także i same chipy, więc opcja zrobienia na nim zamiennika innych układów jest możliwa.

Przy liście instrukcji P2 300 MHz powinno spokojnie wystarczyć na emulację 6502 i to stanowczo szybszego niż 1.77 MHz. Pokey, Antic i GTIA porozrzucać po trzech kolejnych rdzeniach, pozostaną 4 rdzenie na obsługę samego emulatora: klawiatura, joysticki, karta SD, ewentualnie SIO.

520 STF zgodnie z obietnicą :

473 mm długość
270 mm głębokość
67 mm wysokość (w najwyższej części)

W końcu muszę się zabrać za jego doczyszczenie...