ATARI 130XE Web-Server
1234567891011

2023.05.26 / pin.lv

Serdecznie wszystkich (chętnych) zapraszam na najbliższy live. Transmisja odbędzie się 27.05.2023, miejsce kuchnia ... tak więc wbijajcie na "Strumień z kuchni". Jeśli nic się nie pokutwasi, to transmisję znajdziecie pod poniższym linkiem (oknem, czy co to tam ;) ).


2023.05.23/2 / PeBe

Słów kilka o...

Retro komputery przeżywają swój renesans i razem z nim, ciekawi ludzie przekraczają granice tych epokowych sprzętów. Wyciskanie siódmych potów stało się swego rodzaju normą. Częściowo za sprawą niekonwencjonalnego podejścia do tworzonych programów/gier - powiedzenie "Nie wiedział, że się nie da i zrobił..." to klasyk :), a częściowo za sprawą dostępnej obecnie technologii i możliwości realizowania projektów, które w epoce były niezmiernie trudne do realizacji, a niekiedy nawet nie możliwe (przyp. to subiektywna ocena epoki)

Jednym z takich projektów jest karta sieciowa dla 8-bitowego komputera Atari, dająca jakże dziś powszechny dostęp do zasobów wiedzy (i nie tylko) w sieci ogólnie zwanej Internetem. Jednakże, czym jest karta sieciowa bez oprogramowania - kawałkiem elektroniki, podpiętym do komputera, pochłaniającym prąd i zasoby. To się jednak zmienia, gdy takie urządzenie zostanie oprogramowane.

Contiki...

O samym projekcie Contiki niewiele wiem, więc zmyślać bajek nie będę, jednak wiem, że ten pakiet oprogramowania został przeportowany na małe Atari przez niejakiego Olivera Schmidta. To właśnie dzięki niemu, Nasz poczciwy komputerek dostał nowych możliwości, m.in:

  • tekstową przeglądarkę WWW
  • klienta IRC
  • program WGET, do pobierania plików przez protokół HTTP
  • serwer HTTP
  • serwer TELNET

Ja osobiście zainteresowałem się dwoma z nich. Serwer HTTP oraz program WGET.

WGET

Tego programu przedstawiać nie trzeba fanom systemu Linux. Dzięki niemu, możliwe jest pobieranie plików z sieci, wprost z linii komend (Shella). I tak też jest na małym Atari. Jednak program miał kilka niedogodności, które właśnie ja (PeBe) postanowiłem zmienić.

Podstawowymi problemami były:

  • podawanie adresu URL i pliku wyjściowego z "palca"
  • brak możliwości wyjścia z programu (nie wliczając klawisza RESET)
  • brak obsługi przekierowań
  • brak obsługi najbardziej znaczących statusów HTTP
  • mała "gadatliwość" - często program milczał, co użytkownik mógł potraktować jako zwis

i chyba najbardziej drażniące (mnie): kasowanie ekranu przed i po zakończeniu działania programu.

Na sam początek postanowiłem (za namową Pina :D) sprawić, aby program był nieco bardziej samodzielny. Wprowadzenie pliku konfiguracyjnego w którym określało się rzeczone URL i plik wyjściowy, wstępnie wystarczyły, by ten cel osiągnąć. Początkowo miał on ściśle określoną nazwę WGET.CFG. Plik taki, jest zwykłym plikiem tekstowym, a na jego zawartość składały się dwa wiersze tekstu, zakończone RETURNem (EOL) Wszystko fajniusio działało, jednak mnie to nie do końca zadowalało. Doczytałem w źródłach WGET, że można przekazywać parametry z linii komend. Pierwsza próba była nieudana i trzeba było znaleźć winowajcę. Tym okazał się kompilator CC65, który nie wiedzieć czemu, blokował (mimo implementacji) taką funkcjonalność - w każdym jakoś tak to było :P Po modyfikacjach, kolejna próba była już udana. Czas wprowadzić kolejną modyfikację - przekazanie nazwy pliku konfiguracyjnego jako parametr. Pełen sukces. :) Większym wyzwaniem było wprowadzenie możliwości wyjścia z programu.

Contiki to system wielozadaniowy!

Tak, odnalezienie się w zawiłościach wielozadaniowości nie było łatwe, ale ostatecznie, po przeglądnięciu kilkuset linii kodu, odnalazłem upragnione rozwiązanie. Kolejna niedogodność została zlikwidowana. Od tej pory można wychodzić z programu kombinacją CTRL+C. Czad.

Na brak obsługi przekierowań, zwrócił mą uwagę fakt, że podczas testów korzystałem z adresu URL, który mimo usilnych prób, nie dawał sobie rady z ustaleniem właściwej "ścieżki podejścia". Debbuging wykazał, że obsługa nie składała właściwie ścieżki, tj. od serwera przychodził komunikat, że następuje zmiana "katalogu", ale oprogramowanie tego w ogóle nie uwzględniało. Tak więc, wziąłem się do działania i... już działa. Nieco koślawo, ale działa. :P

Obsługa statusów HTTP, a raczej jej brak, powodował, że program po prostu stawał w miejscu i milczał. Dodanie obsługi 400, 404, 408 znacznie poprawiło efektywność wyjścia z programu :D

Ostatni problem (kasowanie ekranu przed i po zakończeniu działania programu) był najbardziej inwazyjny, gdyż problem nie leżał w pakiecie Contiki, a w źródłach CC65 dla platformy Atari. Okazało się (po przeczytaniu dokumentacji :D) że CC65, na potrzeby zachowania liniowości pamięci, przenosi adres pamięci ekranu tuż przed program (czyli tuż za MEMLO, tj. w okolice $2000) Oczywiście, aby tego dokonać, ustalane było nowe APPHI i MEMLO po czym, wywoływana była procedura systemowa inicjująca ekran w trybie GR.0. Dla kompilatora było to swoistego rodzaju wybawienie, gdyż dostawał on liniowy obszar pamięci od $2400 do $CFFF. Jednak dla programów konsolowych to niedopuszczalne (i upierdliwe).

Zabrałem się więc, za "wyłączanie" kodu który to powodował. Rozwiązanie to ma swoje wady i zalety. Zaletą jest oczywiście, niekasowanie ekranu, ale i mniejsze MEMLO. Program można było skompilować już od adresu $1400. Dodatkowo, dla użytkowników VBXE lub XEP80 (do jakich klasyfikuje się też Pin i jego serwer Atari) pozwala w ogóle zrezygnować z usług Antica, co raz, przyspiesza działanie serwera, dwa daje dodatkowe 2KB RAMu dla aplikacji, bo nie tylko pamięć ekranu odpadła ale i definicja zestawu znaków :)

Podsumowanie WGETa.

Ostatecznie, program WGET stał się pełnoprawnym programem wiersza poleceń z możliwością konfigurowania:

~~~shell wget [file.cfg][url file.out] ~~~

  • z palca, gdy w aktualnym katalogu nie znajduje się plik WGET.CFG i nie został podany żaden parametr;
  • gdy w katalogu jest obecny plik WGET.CFG;
  • poprzez podanie URL i nazwy pliku wyjściowego - niestety, SDX ma dość spore ograniczenie pod kątem ilości znaków (64) wiersza poleceń :( co skutecznie ogranicza długość podawanego URL jak i ścieżki pliku wyjściowego;
  • gdy jako parametr, podana jest nazwa pliku konfiguracyjnego.

Użytkownik widzi pełny postęp działania programu i jego wynik, gdy program kończy działanie. Miodzio lodzio :D

HTTPD(emon)

Kolejnym programem wziętym na tapetę jest serwer HTTP. Choć nie jest to usługa systemowa, czy też demon (z Linuxa) działający w tle, jest to całkiem wartościowy program pozwalający utworzyć "prosty" serwer HTTP na małym Atari. W standardowym wydaniu (tym z Contiki) pozwala na udostępnianie plików dla maksymalnie 4 użytkowników jednocześnie. W trakcie jego działania na ekranie konsoli, wyświetlane są informacje o procesach serwera, tj. dostęp przez użytkownika, przetwarzany plik, dokonana akcja serwera (np. status 404) itp. Na mój gust, super sprawa, jednak... te informacje przepadają, a stanowią bardzo ważne źródło danych. Więc...

Plik dziennika HTTPD

...trzeba tę sprawę ogarnąć :) Szczegóły modyfikacji polegały na tym, że w pakiecie Contiki jest przewidziana opcja logowania, jednak ona wyświetla tylko informacje na konsoli. Korzysta ona z pewnej definicji, która jest uzależniona od "dyrektywy", która normalnie nie jest wykorzystywana. Ta dyrektywa (HAVE_LOGSCR) normalnie jest niezdefiniowana, co skutkuje wykorzystaniem makra, które wciela w życie następującą konstrukcję: write(STDERR_FILENO, msg, len) W momencie ustanowienia dyrektywy HAVE_LOGSCR, tworzona jest deklaracja funkcji void logscr(const void*msg, unsigned len) którą wykorzystałem, do jednoczesnego wyświetlania treści dziennika na ekranie, jak i zapisywanie ich w pliku. Małym problemem w tej sytuacji okazał się fakt, że ciągłe otwieranie, zapisywanie i zamykanie pliku, dość mocno obciążało serwer, co skutkowało zmniejszoną wydajnością. Owszem, miało to swój niebagatelny plus, jakim jest bezpieczeństwo istnienia pliku. Cóż... Jak się okazało, nie zawsze jest to dobre wyjście. Więc zmienione zostało to, że plik dziennika otwierany jest do zapisu (APPEND) tylko raz - tuż przed główną pętlą procesu webserver_process i tylko zapis jest dokonywany, wtedy, gdy jest on wymagany. Zamknięcie pliku ma miejsce, gdy zakończony zostanie główny proces, czyli naciśnięcie klawiszy CTRL+C (wykorzystana została wiedza z WGET :D) Wieść niesie, że SDX dokonuje zamknięcia wszystkich otwartych plików w momencie naciśnięcia klawisza RESET. Nie zostało to stwierdzone w warunkach testowych, jednak Pin mówi, że tak własnie jest i u niego to działa. A skoro działa u niego, to to jest najważniejsze - może ja mam jakąś starszą wersję SDXa w emulatorze(?)

Tak, plik dziennika jest od teraz elegancko tworzony na dysku, jednak jest on na sztywno zdefiniowany (jego nazwa). To też uległo zmianie w kolejnej wersji demona na Atari. Przekazany może być parametr, zawierający nazwę pliku dziennika, lub (biorąc przykład z WGET) w katalogu bieżącym, jeżeli znajduje się plik HTTPDLOG.CFG, brana jest z niego ścieżka z nazwą pliku dziennika (niezakończona RETURNem!)

W ten oto sposób, konfiguracji stało się zadość i jest ona już możliwa do ustanowienia przez użytkownika. Ale?

W pewnym momencie, dostrzegłem takie "tycie" niedociągnięcie. Nie sposób ustalić, kiedy dane zdarzenie (wpis w dzienniku) zostało wygenerowane. Hańba mi. A jak wiadomo, SDX genialnie wręcz obsługuje zegar czasu rzeczywistego. Szczęście mi sprzyja, gdyż CC65 też implementuje tą właściwość (z SDX) Więc... Wziąłem się za dodawanie informacji o dacie i czasie powstania wpisu w dzienniku.

No... Teraz to się nazwya dziennik zdarzeń :) Jeszcze tylko odrobinka formatowania, gdyż do tej pory, data i czas oraz wiadomość, były w odzielnych liniach i log jak malowany.

Spadek po WGET

HTTPDemon również stał się pełnoprawnym programem konsolowym, dzięki modyfikacjom dokonanym w trakcie usuwania problemów w WGET.

Niema róży bez kolców - jak mawia powiedzenie. Przy pisaniu plusów związanych ze zmianami w CC65, powstał niebagatelny problem. Kompilacja aplikacji korzystających z prostego GUI jakie oferuje Contiki, niepozwala na uruchomienie tychże, tak jak to było możliwe do tej pory. Powodem takiego stanu rzeczy jest fakt, że interfejs użytkownika korzysta z bezpośredniego dostępu do ekranu. Skutkuje to nadpisywaniem pamięci, przez procedury piszące do pamięci ekranu, co skutkuje zwisem (często spektakularnym) Tak na marginesie. Mimo iż CC65 wykorzystuje bezpośrednie pisanie po ekranie, wydaje się nie mieć kompletnie przełożenia na szybkość. GUI działa bardzo wolno, co pozostawia wiele do życzenia w kwestii użytkowania tegoż. Nad tym problemem pochylam się w tym momencie i mam nadzieje rozwiązać go, pokazując jednocześnie, że Atari Rulez i nie ma na nim rzeczy niemożliwych ;)

Ciekawostki

W trakcie analizowania kodu Contiki, kilka rzeczy przykuło moją uwagę. O tym, że Contiki jest prawdziwie wielozadaniowe, już wspomniałem. Zostały zaimplementowane takie rozwiązania jak: procesy, wątki, zdarzenia. Godne uwagi, gdyż jest to implementacja wieloplatformowa (na bazie API)

Przyglądając się serwerowi HTTP, dostrzegłem też możliwość uploadowania plików. Rozwiązanie to jest w stanie przyjąć nadchodzące informacje jednak, nie są one zapisywane na dysku (czy innym nośniku) Są tylko wyświetlane na ekranie - heh, dzięki dziennikowi zdarzeń z automatu są doń zapisywane. Teraz Tylko poznać nagłówki, rozpoznać je i zapisywać gdzieś na dysku.

Jednak, tak zgromadzone dane na nic się zdadzą, jeśli nie zostaną jakoś przetworzone. I tutaj Contiki też zaskakuje.

Jest zaimplementowany prosty system CGI w formie zaszytych w programie procedur, które zostają wykonane w momencie napotkania na taga w skrypcie shtml - bo tylko shtml ma "pozwolenie" na uruchamianie CGI. W domyślnej kompilacji zostały zaimplementowane funkcje takie jak:

  • import pliku html %!: {path/filename.ext}
  • statystyka pliku %! file-stats {path/filename.ext}
  • wyświetlenie tablicy uruchomionych procesów %! processes
  • tablica połączeń %! tcp-connections
  • adres IP %! adresses
  • Neighbors %! neighbors (nie bardzo wiem, OCB)
  • Routes %! routes
  • Sensors %! sensors

Smutek kala moje serce, gdyż nie jestem w stanie pobawić tymi rozwiązaniami. Jest to związane z faktem wykorzystania emulatora Altirra, w której jest możliwość dodania, jako sprzętu karty DragonCard, jednak nijak nie mogę zmusić Altirry, aby przyjmowała połączenia przychodzące. Co za tym idzie, wszelki usługi jak rzeczony demon HTTP czy TELNET, które nasłuchują na portach, nie przyjmują żadnych informacji. Kompletnie nie mam pojęcia, czy to zamierzone - nie zaimplementowane, czy jakiś błąd konfiguracji, czy też kwestia tego, że korzystam z Altirry pod Wine (pod Linuxem) To ogranicza mocno testowanie wprowadzanych rozwiązań, które w większości wychodzą dopiero, gdy trafią pod skrzydła Pinka.

Cóż... Może się to kiedyś zmieni - Trzeba Czekać.

Tym optymistycznym akcentem, pragnę podziękować za uwagę. Mam nadzieję, że powyższa lektura czytała się lekko i przyjemnie. Nie wdawałem się w szczegóły, gdyż... podobno jest problem z dużymi plikami HTML w serwerze Atari - ten problem to kolejna rzecz, nad którą warto się pochylić.


2023.05.23 / pin.lv

Uwaga: Dzięki uprzejmości kolegi PeBe otrzymałem kolejny update oprogramowania dla serwera. Tym razem chodzi o ilość jednoczesnych połączeń z różnych adresów IP. Było 4 jest ich teraz 8. Oprócz tego reorganizacja pamięci ze względu na stosunkowo niskie MemLO pod Sparta DOS X, log z zapisem do pliku ze wsparciem dla RTC i znów poprawki do WGET. Dodana obsługa parametrów z linii poleceń oraz obsługa plików konfiguracyjnych.

Uwaga2: Prawdopodobnie od środy do piątku mogą występować dłuższe przerwy w działaniu serwera, związane jest to z "burzliwą" aurą pogodową i brakiem zabezpieczeń od strony zasilania. Za utrudnienia przepraszam.


2023.05.22 / pin.lv

Cuda się jednak zdarzają. Odzyskałem kilka dni temu praktycznie 100% danych z mojego zablokowanego konta "pin.tristesse", wrzucam więc powoli cenny content. Zaczynamy od zapisu seta wykonanego przez dj. Wacka na Lost Party 2021.

smacznego ;)


2023.05.15 / kroll

Atari ST Harddisk Menu

Główną atrakcją najbliższego live'a (27.05.2023, kuchnia) i najważniejszym punktem programu będzie prezentacja najnowszej wersji programu o którym do niedawna chyba bardzo niewiele osób w Polsce wiedziała. Mowa o programie Atari ST Harddisk Menu, autorem jego jest SSB z grupy Paradize (strona WWW grupy http://paradize.final-memory.org/index.shtml) Ostatnia wersja jest do pobrania z powyższej strony i została wypuszczona z okazji zeszłorocznej letniej edycji Silly venture SV2k22SE. Pierwotnie program ten był pisany w GFA Basicu, w chwili obecnej głównie w C ze wstawkami w asemblerze. Zrzut ekranu przedstawiający wersje z sierpnia zeszłego roku widać na tym poniższym ekranie.

(Rys.1). Zrzut ekranu wersji z z letniej edycji SV.

Od tego czasu zgodę i źródła do tego programu dostał kolega TheNameOfTheGame i postanowił go w dalszym ciągu rozwijać, a w chwili obecnej trwają ostatnie testy najnowszej bardzo rozbudowanej wersji programu o której chciałbym wam opowiedzieć i pokazać w działaniu na natywnym sprzęcie. Z końcem lutego zdecydowałem się dołączyć do ekipy betatesterów - czytając na anglojęzycznym forum o jego dalszym rozwoju wspieranym właśnie przez mojego kolegę z USA o nicku TheNameOfTheGame. W chwili obecnej jestem jednym z pięciu oficjalnych testerów na świecie. Od tego momentu prace nad tym programem bardzo przyspieszyły :). Kilka słów, do czego służy ten program. Przede wszystkim jest to program, który w łatwy i przyjazny sposób pozwala uruchamiać, gry, dema bezpośrednio z menu bez konieczności uruchamia systemu (TOS), a co za tym idzie szukania danej gry/dema na określonej partycji i itp. :). W najnowszej odsłonie tego programu pisze tylko w dużym skrócie, że np. umożliwia pokazanie zrzutu ekranu z danej gry, odczyt pliku txt (informacje zawarte przez producentów/twórców), wszystko odbywa się sterując zarówno z klawiatury jak i joysticka. Wygląd prawie ostatecznej wersji pokazany jest na dwóch poniższych zrzutach ekranu (Rys. 2 oraz Rys. 3.). Ponadto co jest nowością umożliwia kategoryzację, wybór lubionych tytułów, informacje o danej grze/dema.

Rys. 2. Wybór gry z ogólnego Menu.

Rys. 3. Dodatkowe informacje o grze/demie

Z premedytacją nie wspominam w tej krótkiej notce o wszystkich nowych opcjach, żeby wszystkich zachęcić do oglądania streamu, jednak w trakcie prezentacji postaram się wszystkie te szczegóły, dodatkowe funkcje pokazać w działaniu. Pragnę nadmienić, że plik tekstowy w którym przedstawiony jest opis programu zajmuje bagatela ponad 20 KB czystego tekstu. Na koniec live'a, kilka słów o planach na przyszłość, czyli co chcemy zaimplementować w następnej wersji programu. Program ten działa na każdym dużym Atari.

Piotr Kroll Mietniowski


1234567891011