[CA80] Repozytorium zbiorów z interfejsem magnetofonowym, CA80 w architekturze klient-serwer

Kącik dla elektroniki retro - układy, urządzenia, podzespoły, literatura itp.
Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

[CA80] Repozytorium zbiorów z interfejsem magnetofonowym, CA80 w architekturze klient-serwer

Postautor: tasza » czwartek 21 lis 2019, 18:49

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ WidekThere & Beyond ♪ ♩ ♫
https://youtu.be/Yk3chWo2B6Q



Czasami trzeba dla relaksu zrobić coś zupełnie od czapki. Tym bardziej, że pomysł na komunikację klient-serwer via interfejs magnetofonowy CA80 wykluł się na kawałku serwetki podczas ostatnio-piątkowego zespołowego, wieczornego browarka. Szkoda byłoby zaprzepaścić ten owoc ataku kreatywności dlategoż temat podjęłam i powstało coś...dziwnego. Ale działa i to nawet fajnie, niniejszym radością swą się dzielę, może komuś choćby strzępki tego przydatnymi będą.


Jak wiadomo, CA80 wyposażony jest w całkiem skuteczny w działaniu interfejs magnetofonowy. Obsługują go trzy proste zlecenia systemu Monitora - *4,5,6 - zapis zbioru,zapis EOF i odczyt. Oczywiście zlecenia te to tylko przykrywka na systemowe funkcje dedykowane współpracy z magnetofonem - ZMAG, ZEOF oraz OMAG, pisałam już o nich w osobnym wątku.

Przy odrobinie wysiłku można wyobrazić sobie aplikację na CA80, która pobierze od użytkownika komplet danych pozwalających zlokalizować gdzieś żądany zbiór danych, wyśle te dane do repozytorium plików, tam zlecenie zostanie zrealizowane w postaci odesłania zbioru nazat do CA80 lub poinformowania go o braku takowego. No i tu dochodzimy do podziału ról - CA80 wraz ze stosowną aplikacją będzie pełnił rolę klienta. Komunikacja via popiskujący interfejs do kaseciaka, serwerem będzie duży komputer ze swoją kartą dźwiękową i dyskiem, popędzany odpowiednim serwerowym oprogramowaniem. Rzućmy okiem na rysunek poniżej, to szkic jak cała zabawka działa w ujęciu ... no, powiedzmy że UML-owego diagramu sekwencji (jest to pokraka, niemniej jednak akurat ten zestaw aplikacji było mi ciężko bardziej sensownie rozrysować).

zarys ogólny

ca80-magserver.jpg


I już wyjaśniam co do czego. Aktor, czyli ludź podchodzi do CA80 z odpalonym programikiem klienckim (mgsclient) i wprowadza dwa parametry - nazwę (identyfikator) foldera zdalnej maszyny w którym składowany jest jego program (AAAA) oraz nazwę tegoż - wartość NN. Program wysyła te dane interfejsem magnetofonowym w postaci popiskiwań korzystając z procedury ZEOF, która akurat idealnie pasuje do wysłania 2+1 bajtów danych. Na dużym komputerze pracuje programik sox, który po odebraniu sygnału audio zapisuje go do pliku *.wav i przekazuje skryptowi parseCA80eof.py. Pythonowy skrypcik ma za zadanie wykoncypować z pliku *.wav wartości numeryczne zapisane w rekordzie EOF, gdy to zrobi - biorą się za prace instrukcje warunkowe okalającego całość skryptu magserver.sh (dlatego występuje w środku diagramu sekwencji, choć tak po prawdzie koordynuje pracę całej zabawki). Wydłubane z popiskiwań wartości AAAA i NN są traktowane jako odpowiednio - nazwa katalogu z plikami oraz początek nazwy pliku. Następuje weryfikacja czy folder i plik są osiągalne, gdy nie - do CA80 odsyłane są stosowne informacje o błędach (no folder, no file), oczywiście w formie rekordów EOF zakodowanych za pomocą hex2wav i wypiskanych przez sox jako sygnał audio. Oczywiście, gdy wszystko pasuje aplikacja odsyła do CA80 znaleziony w repozytorium plik *.hex, także potraktowany konwerterem na piski. No i w sumie tyle z lotu ptaka.



klient

Komplet plików źródłowych tu: https://github.com/bienata/CA80_sdcc/tr ... ika/client a ja ze swojej strony tylko taki komentarz. Zlecenie *5 systemu CA80 pobiera od użytkownika dwie wartości - adres wejścia (2 bajty) oraz nazwe zbioru (1 bajt). Zachodzę w głowe, dlaczego CA80 pobiera dwa razy liczbę dwubajtową zamiast wykorzystać możliwości procedurki PARAM i ograniczenie na ilość prowadzanych nią cyfr hex... no ale jest jak jest. Ciekawą cechą wykorzystanej w kliencie mgsclient.s procedurki systemowej OMAG jest to, że po odebraniu zgodnego z zadeklarowaną nazwą rekordu EOF wykonuje ona automatycznie skok pod tak nadesłany adres. Skok poprzedza odłożenie na stos adresu za wywołaniem procedurki, stąd gdy nasz załadowany program zakończymy instrukcją RET (0xC9) sterowanie zostanie przekazane nazat do kodu, który wywołał OMAG-a, super. To umożliwia realizację kontekstowej obsługi błędów ze strony serwera - w kodzie klienta, pod znanymi adresami (u mnie np. 0x4150,0x4200) znajdują się procedurki obsługi (prezentacji) błędów, serwer odsyła tylko kody (adresy) tego co ma być wywołane, takie śmieszne prawie jak RPC (remote procedure call).
Aplikacja kliencka działa w trybie ciągłym, to znaczy o ile zażądany od serwera program nie wejdzie w nieskończoną pętlę to ona przejmuje nazat sterowanie, po wykonaniu jednego programiku oczekuje na wskazanie nazwy/foldera dla kolejnego.

serwer

Źródełka tu: https://github.com/bienata/CA80_sdcc/tr ... ika/server
I teraz tak - jak wspominałam całość zabawki koordynuje skrypt magserver.sh. Tu jest kilka fajnych (tak myślę) patentów, po pierwsze uruchomienie aplikacji sox w trybie nagrywania, ale z detekcją sygnału i ciszy. Udało mi się to jakoś okiełznać i uruchomiony sox grzecznie słucha sygnału z wejścia line-in karty dźwiękowej, gdy poziom audio przekroczy wskazaną parametrem wartość - zaczyna nagrywać. A nagrywa tak długo jak mu podają sygnał, po wykryciu spadku poziomu sygnału przez dłuższy niż zadeklarowano czas - zrzuca materiał audio do pliku i kończy pracę. Tak pozyskany plik *.wav bierze do obróbki pythonowy programik parseCA80eof.py. W środku jest jakaś tragikomedia okraszona znanym już stwierdzeniem z tomików MIK - `jak doświadczalnie stwierdzono - JDS`. Nie opisuje detali implementacji, bo zwyczajnie nie jestem z tego dumna, choć skrpt `z reguły` zgaduje poprawnie co mu nagrali na wtyczkę. Dwa słowa: w pierwszym obiegu dane WAV są zamieniane na ciąg 0/1 - tu w grę wchodzi analiza amplitudy i uśrednianie, wykrywanie progowych wartości. Potem ten ciąg 0/1 jest dekodowany (na zasadzie detekcji zboczy i analizie długości sekwencji bitów) do serii bajtów. Zera stanowiące synchronizację odrzucam, z rekordu EOF wydłubywane są - słowo i bajt, to idzie na stdout. W pliku można znaleźć wiele zakomentowanych print-ów - w ten sposób na konsole wyrzucałam sobie serie liczb, zebrane do pliku tekstowego i zapodane do gnuplot pozwoliły ad-hoc stroić wartości typu `JDS`. Dalej jest prosto - warunki sprawdzające plik/folder generują gry potrzeba EOF-y z informacjami dla obsługi błędów, tu w użyciu jest hex2wav w minimalistycznej formie. Jeżeli dane wejściowe są poprawne - konwertowany jest cały plik *.hex i odsyłany do klienta-CA80. Aha, adres wejścia dla odsyłanej aplikacji zaszyty jest w nazwie pliku *.hex, to druga po nazwie, czteroliterowa wartość - ona ląduje jako adres wejścia przy konwersji do audio. No oczywiście do kompletu powstał maleńki zestaw programików testowych, o które klient może poprosić serwer, dostać je i sobie automatycznie uruchomić. Pliki wynikowe (hex) tych programików są w folderach aaaa,bbbb,cccc , a kody źródłowe masowo kompilowane przez all.sh leża w demo-src.

Zabawka na żywo pracuje jak na filmiku, widzimy obsługę błędów oraz poprawne scenariusze pobrania zbioru.

https://youtu.be/n9JLw-8WVTA

No i da się, na podstawie architektury z serwetki.

--edytka--

ps.
ze strony swej temat magnetofonu w CA80 zamykam tym postem, chyba wystarczy już...

#slowanawiatr
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Wróć do „Retro”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 13 gości