Oscar Fowler (@jamm) ciężko pracował refaktoryzując firmware #FujiNet, usuwając połączenia do biblioteki Arduino i zastępując je połączeniami do ramki ESP-IDF. Ostatecznie będzie to oznaczać krótszy czas uruchamiania systemu i bardziej efektywne wykorzystanie zasobów w ESP32. Dlaczego to robimy? Początkowo, gdy rozpoczynaliśmy ten projekt, każdy pojedynczy element był napisany jako całkowicie autonomiczny szkic Arduino, jeden szkic dla każdego elementu, który chcieliśmy przetestować. To w końcu pozwoliło nam szybko sprawdzić, czy to, co robiliśmy, było wykonalne. Szybko zebraliśmy prawie czterdzieści szkiców testowych w ciągu dwóch miesięcy. Arduino pozwoliło nam skoncentrować się na wdrożeniu wystarczającej ilości logiki, aby była to dowolna liczba urządzeń peryferyjnych SIO, a także zapewniło bogactwo klas i funkcji, których nie musieliśmy wdrażać. Tymczasem Jeff Piepmeier (@jeffpiep) uznał, że do budowy firmware'u produkcyjnego należy wykorzystać PLATFORM.IO. Przypadek ten opierał się na kilku bardzo solidnych podstawach, a mianowicie na tym, że znacznie łatwiej było rozłożyć różne bity kodu na osobne biblioteki i wykorzystać je z głównego kodu. Dostarczył on również bardzo ładny edytor w postaci VS.CODE, który jest naprawdę miłym ulepszeniem w stosunku do edytora Arduino zarówno pod względem użyteczności jak i skalowalności. Jeff był w stanie wykonać swoją pierwszą pracę nad emulacją drukarki w PLATFORM.IO. Zaczął też pracować nad tym, aby wziąć pracę, która zaczęła się układać pod szkicem Multilatora, i podzielić ją na ładne klasy C++ rozłożone na kilka bibliotek, a także zaimplementować wirtualną magistralę SIO, której potrzebowaliśmy w głównym kodzie, aby połączyć wszystkie te różne urządzenia wirtualne razem. Do końca stycznia wszystkie prace nad Multilatorem ześlizgnęły się do miękkiego lądowania, a my przenieśliśmy się w całości do bazy kodowej PLATFORM.IO. To było wspaniałe zobaczyć D: R: i P: urządzenia pracujące razem pod jednym dachem. Z powodu całej ciężkiej pracy wszystkich zaangażowanych, wszystko to zebrało się w całość i zadziałało prawie całkowicie za pierwszym razem, z pluskwami wypracowanymi w ciągu następnych kilku tygodni, a do lutego, zacząłem pracować nad pierwszymi kawałkami tego, co stanie się urządzeniem N:. Jeff znalazł również czas, aby zakraść się do syntezatora mowy SAM. Znalazłem port SAM do C jakiś czas temu i zapamiętałem go, przekazałem Jeffowi, a w pewien weekend w marcu #FujiNet zaczął mówić. Tymczasem w marcu otrzymaliśmy bardzo potrzebną pomoc od Ricka Lopeza aka 8bitandmore, który zbudował FujiNet na podstawie schematów i zaczął ulepszać i zmieniać R: urządzenie, aby działało jeszcze lepiej, naprawiając błędy. I otrzymaliśmy specjalną niespodziankę od Marcina Sochackiego (@TheMontezuma), który również zbudował ESP32 na płycie chlebowej i wsparł SIO2BT! W miarę zbliżania się marca, powoli zacząłem wykuwać więcej z urządzenia N:, w postaci adapterów protokołu TCP i UDP. Ponieważ zaimplementowałem firmware dla tej części systemu, napisano serię programów testowych, które rozmawiały z #FujiNet przez SIO, aby zweryfikować niskopoziomowe działanie różnych części kodu, które N: handler będzie ostatecznie używał. Zminimalizowało to liczbę punktów debugowania do jednego, a nie dwóch, a funkcje sieciowe zaczęły spadać. W międzyczasie, w kwietniu, zaczęliśmy dostrzegać pomoc i wkład Oscara Fowlera (@jamm), który zaczął przeszukiwać kod i powoli poprawiać go, czyniąc go lepszym. Zaczęliśmy w maju z nową wersją sprzętową, która naprawiła pewne problemy, które omówię poniżej, i zacząłem pracować nad rozszerzeniem N: do obsługi sieciowych systemów plików na poziomie plików. W miarę rozwoju tej funkcjonalności, zaczęliśmy mieć problemy: * Emulacja druku ssała RAM. Również 320K na ESP32, do którego przenieśliśmy się, ponieważ zabrakło nam 80K dostępnego barana na ESP8266, było wyczerpane, powodując zderzenia i problemy ze stabilnością. Do zbudowania pliku PDF potrzeba dużo pamięci RAM! Problem ten został rozwiązany poprzez kolejną zmianę sprzętu, która zwiększyła pamięć RAM do maksimum dostępnego dla ESP32 (8 megabajtów PSRAM). * Emulacja Bluetooth zabierała nie tylko cenną pamięć RAM, ale także przestrzeń flash. Poprawka miała na celu nie tylko zwiększenie pamięci RAM, jak to zrobiliśmy powyżej, ale także zwiększenie ilości pamięci flash do maksimum (16 megabajtów).
* W miarę jak wiązaliśmy wszystko razem, stawało się jasne, że czas rozruchu znacznie się wydłużył, ze względu na dużą ilość wymaganej inicjalizacji. Sytuację pogarszał czas potrzebny do przetestowania PSRAM. Podczas gdy cała inicjalizacja miała miejsce, FujiNet nie mógł odpowiedzieć na nic z Atari w tym czasie, a co ważniejsze, nie mógł się uruchomić. Stało się jasne, że potrzebna jest drobniejsza kontrola nad procesem inicjalizacji, aby nie tylko skrócić czas inicjalizacji, ale także precyzyjnie określić priorytety i odłożyć na później aspekty inicjalizacji, aby wychować na tyle dużo urządzenia, aby mogło ono przynajmniej reagować na uruchomienie programu CONFIG, podczas gdy reszta urządzenia mogła inicjować w tle. * Szeregowe procedury I/O, które ostatecznie wysyłają i odbierają ruch SIO, nie są tak wydajne, jak mogłyby być. Czas na SIO jest absolutnie krytyczny, z oczekiwanym czasem odpowiedzi w mikrosekundach dla takich rzeczy jak potwierdzenie (ACK), a buforowana natura UARTów oznaczała, że musieliśmy przepłukać UART, aby upewnić się, że rzeczy takie jak pakiety potwierdzenia (ACK) zostały wysłane na czas, oznaczało to, że dalsza transmisja danych będzie opóźniona o kilka milisekund, i chociaż nie jest to szkodliwe, oznacza to, że można to zrobić szybciej, ale tylko wtedy, gdy będziemy bezpośrednio kontrolować sprzęt. Oprócz frameworka Arduino (oraz frameworków takich jak Pumbaa i Simbaa, które umożliwiają używanie innych języków, takich jak Python i Lua, do pisania kodu), PLATFORM.IO oferuje możliwość budowania i zarządzania projektami napisanymi dla frameworka ESP-IDF, który jest frameworkiem dostawcy dostarczanym przez Espressif do tworzenia oprogramowania C i C++ na projektach ESP32. Duża część klas Arduino jest w rzeczywistości wdrażana jako owijki wokół ESP-IDF i ta niepotrzebna owijka może być usunięta. Ponadto, wiele elastycznych opcji dostępnych w ESP-IDF (takich jak określenie większej liczby dozwolonych połączeń TCP, ustawienie wielkości bufora, zmiana sposobu uruchamiania i inicjalizacji, itp.), po prostu nie jest dostępnych w Arduino API, musimy się do nich bezpośrednio dostać. Nie wspominając już o tym, że wersja ESP-IDF obecna obecnie w opublikowanym frameworku Arduino jest starsza od najnowszej wersji tego frameworka, która została wydana przez Espressif, a która naprawia szereg błędów, na które natknęliśmy się podczas tworzenia tego oprogramowania, z których najbardziej znanym był domyślny rozmiar nagłówka POST dla transakcji HTTP, który uniemożliwiał naszemu administratorowi sieci poprawną pracę z przeglądarką Chrome. Więc Oscar zaczął brać, zrywając zależności od Arduino.h, i z każdym błędem, który się zdarzył, napisał równoważne funkcje i klasy, aby zastąpić funkcje utracone z Arduino, wzywając do ESP-IDF w razie potrzeby. Był to bardzo powolny proces, wymagający przejścia przez całą bazę kodową (ponieważ każdy z nas aktywnie pracował nad kodem!) i ukradkiem zastąpienia wywołań Arduino przez fnSystem, i tak dalej, wywołań. Oscar dotarł do punktu, w którym kod został gruntownie zawiązany w naszych nowych bibliotekach, a funkcjonalność działała zgodnie z oczekiwaniami, więc zdecydował się stworzyć nowy projekt w ramach katalogu platformowego o nazwie FujiNet_idf, który był projektem łączącym tylko framework ESP-IDF, a nie łączącym Arduino, w ogóle. Po około tygodniu pracy, kod został skompilowany, a dwa dni później uruchomił swój pierwszy dysk. Ciężka praca w infrastrukturze w celu pozbycia się zależności od Arduino opłaciła się, a ilość działającej funkcjonalności po pierwszej udanej budowie zaskoczyła nas wszystkich, na pewno. Więc co dalej? Zabieram kilka tygodni, żeby się zrelaksować, podczas gdy Oscar kontynuuje debugowanie i poprawianie kodu w wersji ESP-IDF, w celu osiągnięcia parytetu funkcjonalności z obecną wersją produkcyjną. Największym problemem jest obecnie radzenie sobie z przerwami na wyjściu szeregowym przy dużych prędkościach. Podejrzewamy problem czasowy, który musimy rozwiązać (teraz, gdy jesteśmy jedną warstwą bliżej gołego metalu) i mamy nadzieję, że zostanie on szybko rozwiązany. Teraz, gdy @Mozzwald oficjalnie wykonał wstępny test produkcyjny w ilości 50 jednostek, nacisk jest na to, aby zapiąć to, co mamy, aby przygotować się do założenia tych jednostek produkcyjnych. Będzie to dokładnie to, co mamy z różnych urządzeń peryferyjnych D, P, R i N, jak również SAM, z naciskiem na naprawianie błędów w CONFIG (w czym pomaga Rick aka 8bitandmore), i będziemy tworzyć płynny sposób na uaktualnienie firmware'u FujiNet, ponieważ więcej funkcjonalności w tym roku i dalej. W oczekiwaniu na dostarczenie tych początkowych 50 jednostek testowych zacząłem pisać plan testów pełen procedur testowych, które nie tylko służą do walidacji, ale także do instruowania funkcjonalności #FujiNet. Chcę podziękować wszystkim, którzy przyczynili się do powstania tego projektu... krwi, potu i łez. To dzięki nam wszystkim mamy jedno z największych urządzeń peryferyjnych, jakie kiedykolwiek udało nam się podłączyć do komputera Atari. Mam nadzieję, że dzięki temu projektowi, który jest realizowany w sposób całkowicie jawny, stworzy atmosferę, która zachęci ludzi do wniesienia wkładu w coś naprawdę zabawnego i niesamowitego. Mam również nadzieję, że dzięki temu wszystkiemu, co robimy w sposób otwarty, nieuchronnie zapewnimy, że urządzenie to pozostanie użyteczne dla przyszłości społeczności Atari i stanie się modelem do przykręcania użytecznego interfejsu sieciowego do platform retrokomputerowych.
#Atari8bit #FujiNet Ponieważ tak szybko wyprzedaliśmy się z początkowego biegu, @mozzwald założył formularz rejestracyjny dla zainteresowanych kupujących #FujiNet, aby ocenić wielkość następnego biegu. Jak poprzednio, $65 z walizką, $55 bez walizki. Dostaniesz e-maila, gdy nastąpi następna runda.
... przez ten Fujinet to ludzie wreszcie wrócą do używania sprzętu, a nie emulatora ;). Mam także nadzieję, że nikt tego do niego nie zaimplementuje :)))
Melduje, że napisałem pierwszą sieciową grę na Atari, wykorzystującą #FujiNet.
Nie jestem może specjalnie oryginalny, bo jest to gra w szachy, ale da się grać przez internet na jednym z najstarszych i największych serwerów sieciowych FICS (Free Internet Chess Server) ->link<-
Gra jest już w pełni funkcjonalna, udało mi się już rozegrać kilka próbnych partii. Dorobię może jeszcze sterowanie joystickiem, ale to jak uporam się z innymi drobiazgami.
Żródła jak zwykle dostępne na moim gitlabie: ->link<-
Grę można uruchomić też bezpośrednio z serwera fujinet.pl /ChessNet.atr
Bo Dragon 2 ze stosem w sobie ma dopiero sens. Coś tam takiego robili chłopaki na Aage, są też prototypy rodzimej produkcji. Choć, do takich zastosowań jak gierki po sieci to ten fujinet będzie jak malina. No i fakt, że jest dobrze oparty o OS to istotnie plus. Możesz się czegoś nauczyć od kolegów, Panie XXL ;)
Inna sprawa to też to, do czego się takich rzeczy używa. Np serwer, który postawiłem na DragonCarcie i Contiki nie dałby się "postawić" na Fujinet. Przyczyna raczej oczywista.
co ciekawe fujinet dałoby się zaimplementować na karcie / PBI / ECI, to nawet nie byłoby takie strasznie trudne od strony software'owej. tylko chyba nie ma sensu - do casualowego odpalania gierek zamiast sio2sd wystarczy sio w turbo.
@pin - prawie dwadzieścia lat, DRAGON CART musiał się sprawdzić. Popełnili krytyczny błąd "jedyne co musimy zrobić, to zaprojektować sprzęt" i nie pomyśleli o tym, co projektują w kontekście "systemu" części, które wszystkie muszą współpracować i być łatwe do zrozumienia.
To żywe piekło do programowania, więc prawie nic nie zostało do tego napisane. (Mówi się jak ktoś, kto dosłownie miał jednego z autorów IP65, przychodzi do niego i próbuje pomóc mu przenieść PLATOTERM do Smoczego Koszyka, tylko po to by się poddał, ponieważ odkryłem, że stos TCP/IP IP65 jest tak opóźniony w połowie, że nawet nie implementuje zmiany rozmiaru okien dla pakietów TCP, co jest rozpaczliwie potrzebne do kontroli przepływu, gdy program kliencki musi zrobić dużo przetwarzania!)
A Atari po prostu nie jest w stanie poradzić sobie z wieloma nowoczesnymi rzeczami w dzisiejszych sieciach. SSL/TLS jest tego wielkim przykładem.
Dodaliśmy już adaptery protokołów dla kilku różnych protokołów, takich jak HTTP/S, FTP i TNFS, a wkrótce pojawi się więcej (SMB, NFS, SSH, itd.). W #FUJINET będą też wbudowane parsery dla XML i JSON, które będą mogły pobierać dane wejściowe i otrzymywać zapytania. Pozwoli to na obsługę klientów, którzy potrzebują skomplikowanego przetwarzania danych, jak np. interakcja z Twitterem lub Facebook API.
Przestańcie też z tym idiotycznym argumentem czystości. Urządzenia peryferyjne Atari są z definicji rozproszonymi urządzeniami obliczeniowymi, po prostu zapewniamy im dużą moc obliczeniową do robienia naprawdę interesujących rzeczy.
Thomas: robisz rzecz przełomową, jak to bywa w takich przypadkach musisz się przygotować na ataki pseudoatarowcow ale nie przejmuj się za niedługo internet w Atari to będzie standard.
#Atari8Bit pierwszą grą dla #FujiNet jest klient Free Internet Chess Server (FICS) o nazwie ChessNet napisany przez @bocianu przy użyciu MAD Pascal! Niesamowita praca!
well... After a thought MULE will be a problem, generally old games with action elements not specifically planned for SIO based communication will be a problem as the transmission halts most of other tasks. Is there a way?
Lucasfilm did a custom SIO routine for BallBlazer that allowed their disk to load while the intro played.. *shrug* so maybe? This is still very new territory.
Oznacza to, że konieczne jest przeprowadzenie pewnych badań na temat tego, kiedy wysłać dane sieciowe, aby zmaksymalizować interaktywność (podejrzewam, że będziemy musieli skłaniać się ku wysyłaniu jak najmniejszej ilości danych). Nie jestem dobrze przygotowany, aby zrobić to samemu i będzie potrzebował ludzi bardziej utalentowanych niż ja, ale myślę, że możemy z powodzeniem robić gry zręcznościowe przez interfejs sieciowy.
Oh, you can do action games as well, you just need to plan for very small number of cycles available during serial transmission. How small a packet can be? Say, I want to send to server 6 bytes and receive other 6 bytes. TNFS is possibly a way to do this(?)
pirx: the network (N:) device (0x71 to 0x78), can read and write data in a huge number of protocols, as well as being able to do pure UDP or TCP. TNFS is meant for file sharing so it isn't a good fit for this, but that's okay. :)
For games, UDP is the best option, as you can quickly switch destinations for packets, and even have the option to multicast (send one packet to multiple destinations simultaneously, depends on the network topology.)
So once you send an 'O'pen command to say, UDP://some.server.pl:2000/
you can then send 'R'ead, 'W'rite, and 'S'tatus commands. The number of bytes specified in both daux and dbyt. Status tells you how many bytes are waiting, and the INTERRUPT/PROCEED lines can tell you if there is data waiting so you don't waste time bombing the SIO bus with status requests.
If we can standardize on a protocol that can be used for games, we can make a protocol on the ESP itself to handle the details and make it REALLY easy to use from the Atari side.
The ESP itself is also powerful enough that not only could it run a local server (for parties), it can handle mDNS to announce games that can easily be queried. Lots of amazing possibilities here.
Thomas: I had similar idea many years ago, but.. never mind :) Did you think about pics converter? Converting JPEG/GIF/PNG files on-the-fly to the desired Atari format? It's easy for ESP and would allow Atari to "see" ;)
I think that for the beginning just a simple 2/4/16 color resizable bitmap would be enough :) There are opensource libraries available you can use to implement this feature in the firmware I think.
I can give chalk talks on how to modify and extend the firmware, and in fact, I WANT to do this, so I can get people making new features we never thought of, or didn't have time to do.
wejdz w link Kaza, przeczytaj. To nie jest lista do zamowienia. Tak $65 to cena za to co na zdjeciu w dowolnym kolorze. Do tego transport. Prosze pamietac ze produkcja nie bedzie w PLa prawdopodobnie Chiny ->USA->Wysylka.
Ja nadal czekam na Chinczyka ktory ma zrobic shielda pod ESP32. Jak przyjda gotowe plytki to zloze urzadzenie i dam znac. Pliki gerbera sa dostepne i darmowe. Mozna sciagnac wersje THT (przewlekane pcb) zamowic i samemu zlozyc.
