#Atari8bit #FujiNet shown here is an example of what an IMAP adapter for N: would look like, and how it would function, to deal with e-mail boxes at the OS level. ->link<-
Walczę z tym 1.0. Doszło do tego, żeby wykluczyć problemy z ESP32, przelutowałem ich płyteczki. I 1.3 nadal działa (się zupgrejdował za drugim razem, bo za pierwszym wyskoczył błąd przy flaszowaniu po wyczyszczeniu flasha), a 1.0 nadal nie chce.
@Peri Noid - jesteśmy w kontakcie, jak się ociepli, przyjadę na kółku i powalczymy razem :)
SUKCES! Zamieniłem w FN układ CP2102 w obudowie QFN28 - kupiłem przejściówkę RS232 opartą o taki układ ze sklepu modulosy.pl. Na pierwszy rzut oka - na FN od zaxona - oryginał, laserowo wycinany napis, widoczny pod światło - ale nie działa. Na przejściówce w sumie chyba nadruk, zero lasera. Ale DZIAŁA!
Po wymianie układów FujiNet 1.0 zaczęło się aktualizować z wciśniętym przyciskiem A (lewym).
#Atari8bit This video focuses on setting up #VSCode and #PlatformIO under Linux (as an example), so that you can hack on #FujiNet #ESP32 firmware! (or, just get a head start on builds before they reach production!)
Missing link, tkanks :) -----------edit -------------- Following instructions I have set this environment in my MacOsX Mojave succesfully.
The minor problem was missing dir2atr, which I have resolved by slightly changing dir2atr and other tools sources and compiling them.
However, making autorun.atr and copying it to data catalog resulted in unrunnable config tool, it loaded but dark blue screen at the end. Maybe I have messed something, I'll check this again.
Tools are updated by: 1. Platform/Build system image command. 2. Platform/Upload system image command.
---edit --- Fixed by updating to github cc65 2.19.
Uporządkowałem mocno kod fujinet-config - jest na githubie. Proszę tych, co mają możliwość (środowisko VisualStudioCode z działającym uploadem), aby pobawili się konfigiem. To, co porobiłem: - konfig teraz kompiluje się do 19997 bajtów (z ca 22500) - przerobiona procedura obsługi ekranu - teraz jest znacznie szybszy, niemal natychmiastowy - usunięte kilka brzegowych bugów, typu brak kontroli długości wprowadzanego tekstu.
Czekam na taki, który poprawnie w systemie potrafi zainstalować urządzenie N:. Autor projektu wielokrotnie zwracał się z prośbą o pomoc w ogarnięciu tematu i chyba dwukrotnie przekierowałem go do Draco. Z Draco też rozmawiałem w temacie. Niestety do kontaktu najwyraźniej nie doszło, więc zapewne N: nie jest tu istotną sprawą ;)
@Kuba - ooo, piękna robota dla fujinetu, kuurcze, trochę to trwało, ale wreszcie się poprawiają podstawowe rzeczy. Pewnie dałoby się z tego zrobić taką perełkę, jak biosy flazzjazzcata, ale to by raczej wymagało przepisania.
Sorry, yes, I will get in contact with drac030 again to start work on an SDX Kernel driver. I've been taking care of a few things at once. ;)
Meanwhile:
#Atari8bit #FujiNet @BillKendrick is at it again! This time, he has written a visual tracker for the International Space Station! You can run it on atari-apps.irata.online/Networking/iss.xex
chodzi mi o konfigurator do ultimate1Mb i incognito, które wyglądają super hiper jazzy. Ale tak naprawdę teraz, gdy config.com ładuje się szybko i będzie szybko działał z Twoimi zmianami to już nie ma większego znaczenia.
Nie przypuszczałem, że ten projekt będzie się dało tak łatwo przenieść na inne platformy. Oby udało się autorom wciągnąć ten fork do głównego repozytorium.
Arch Linux na Arm6 to jakieś 10 minut na przygotowanie karty i konfigurację Wifi. Konfiguracja distcc zajmuje trochę dłużej, ale działa i bez tego - kompilacja na Raspberry to jakieś 10 minut. Źródła kompilują się bez żadnych warningów (zależnośći są minimalne: gcc, cmake, make i libbsd).
Update: Fujinet daje radę z hsindex=0, ale Debug trzeba przekierować na drzewo: ./fujinet >/dev/null 2>&1 lub do pliku, albo zbudować go z -DCMAKE_BUILD_TYPE:STRING=Release zamiast Debug.
Dużo informacji na terminal via ssh źle wpływa na chyżość maliny Zero :) ale jest jeszcze szansa na dalszą poprawę, bo czasem z czytaniem command nie wyrabia.
Ogólnie - świetny patent, zwłaszcza TNFS i zdalne serwery robią wrażenie, a Raspberry Pi Zero z Arch Linux Arm, szczerze, bajka.
to trzebaby tylko jakiś prosty soluszon do komunikacji po SIO, może za pomocą GPIO. chyba wystarczyłby jakiś bufor 3.3V <--> 5V, resztę można w sofciku zrobić.
Kilka lat temu chciałem zrobić carta na ESP8266 do zastosowania uniwersalnego (internet, koproc, gfx converter, whatever), ale z braku chętnych na napisanie oprogramowania zrezygnowałem. Później pojawił się ESP32, który aż się prosi o wersję równoległą. SIO zabija ten projekt w mojej opinii.
@Alex - że zabija to lekka przesadka mózgowa, jak na razie to największy sukces sprzętowo-programowy ostatnich lat. I to prawda, ilość kodu, jaki trzeba było naskrobać jest powalająca. Jakby nie Thomas, to i z tego projektu nic by nie wyszło.
@Pin - ja osobiście nie miałem problemów, ale też nie jestem takim znowóż heavy userem, poza tym mam gigabitowy światłowzwód. Co do komórwek to chyba problemo jest głównie w tym, że FJNT nie obsługuje IP6.
Zrobiłem dzisiaj aktualizacje FujiNeta do najnowszej wersji i koniec zabawy. Chodzi tylko karta SD. Reszta nie działa , po wybraniu innej opcji wyskakuje na dole ekranu "error mounting host slot" restartuje się i zaczyna od pokazania sieci wifi i tak w kółko. FujiNet od Zaxona 1,5. Jakieś pomysły jak to naprawić ?
@Jerzy72, czy udało Ci się coś dowiedzieć w sprawie tych problemów wspomnianych? Mam dzisiaj od kilku godzin podobne objawy u siebie. Mam takie hosty jak na powyższym zrzucie ekranu u Jerzego72. I u mnie sytuacja jest taka, żee nic nie aktualizowałem, przez jakiś tydzień jak mam zmontowanego FujiNET-a (wersja 1.0) wszystko smigało elegancko. Dziś nagle sobie odpalam i nie działa. Ale host atari-apps.irata.online łączy się i wszystko śmiga elegancko, a pozostałymi dwoma mam przy próbie wejścia na hosta około 30 sekundowy zwis, po czym na dole "error mounting host slot" i wifi się restartuje i łączy na nowo, ale nadal to samo - jeden host łączy, pozostałe nie. Od czasu do czasu na chwilę udaje się połączyć z którymś z pozostałych hostów, ale działa tyo tylko wtedy przez chwilę, po czym znowu zwis.
Sam sobie odpowiem. Choć nie wiem dlaczego tak się dzieje, to dzisiaj wszystkie dolegliwości wczorajsze ustały, a wszystkie serwerki TNFS śmigają mi elegancko.
Jak by ktoś wiedział co może być przyczyną takich jednodniowych perturbacji, to miło by było wiedzieć. Czy to jest wina serwerów, czy łączy internetowych, czy problem leży raczej po stronie hosta, czy po mojej?
Edit: a nie... jednak tylko przez 10 minut było wszystko dobrze i znowu mam z powrotem te same problemy co wczoraj. Dziwne...
Edit2: ciekawe, że problem jest powtarzalny jeśli chodzi o to, których serwerów dotyczy. atari-apps.irata.online chodzi zawsze elegancko i nigdy z nim nie ma problemu, a z pozostałymi dwoma są te kłopoty u mnie cały czas.
Mam windę, więc tracert. Jednak tracert mi nic nie zwraca niestety, same upłynięcia limitów czasu. Ale to na wszelkie serwery jakie próbuję. Ale może to dlatego, że łączę się przez internet komórkowy? Ma to jakieś znaczenie? Raczej słaby ze mnie sieciowiec...
Ma niestety duże. Nie działa shutbox i czasami przy dużych obciążeniach słabo chodzą serwery tnfs z sieci Internet. Osobiście używam łącza T-Mobile w domu a UPC w pracy, różnica kolosalna na plus drugiego rozwiązania. Może jak zadomowi się na dobre 5G, sytuacja ulegnie zmianie.
Hmm... Ja mam w domu ten internet w playu akurat. Z tym że generalnie internet na komputerach śmiga mi elegancko, żadnych przerw, zastojów, filmy z youtube w full hd, ściąganie szybkie, połączenia zdalne z kamerkami itp. też wszystko śmiga dobrze. Ciekawe jest, że serwer atari-apps.irata.online łączy mi się zawsze idealnie, i śmiga bez problemów zawsze. Natomiast fujinet.online i fujinet.pl wykazują te problemy. Czym się różnią te serwery z mojego punktu widzenia między sobą? Może mają różne oprogramowanie te serwery? Albo po ich stronie występują jakieś problemy? Czy ktoś jeszcze ma takie objawy jak moje?
Tak jak Ci pisałem na łączu t-mobile mam podobnie- nie ma znaczenia tutaj serwer tnfs. Są przedziały czasowe, że mogę korzystać tylko z lokalnego własnego.
na "łączach" komórkowych FN leży, gdziekolwiek i na czymkolwiek tego nie sprawdzam to załadowanie nawet pojedynczego "xex'a" stanowi duże wyzwanie wyzwanie.
Ciekawe jest to, że inne urządzenia działające na tym samym module WiFi (a mam w domu takich kilka.... naście ? ) nie sprawiają kłopotów z łączeniem się z czymkolwiek z czym się łączą, tak przez stałe łącze kablowe jak i przez komórkofon.
Pecuś - to nie jest tak, że tylko fujinet na łączach mobilnych się sypie. Osobiście korzystam z wielu rozwiązań vod i tutaj widać wyraźnie lagi podczas uruchamiania i pierwszego buforowania. Na łączach kablowych leci to zdecydowanie szybciej. Ja w miejscu zamieszkania nie mam niestety innej opcji bo Toya, która przygarnęła hajs 2lata temu z UE na położenie światłowodu w terenach podmiejskich nic w tej materii u mnie jeszcze nie zrobiła. Dlatego cicho liczę na małą rewolucję w przypadku 5G. Pinokio ma rację większość rzeczy w fujinet leci po UDP i na sztywno ustawionych portach - a warto dodać, że chyba żadna sieć GSM nie daje klientowi indywidualnemu publicznego adresu IP.
Macie rację UDP tu nie pomaga. I nie twierdzę, że to problem tylko FN. Ale, tak czy inaczej, wydaje mi się, że coś musi być w sofcie "niedorobione". Bo sprzęty oparte na tym ESP, które mam w domu, jak się rezerwowo przepinam na GSMa działają tak samo jak po kablu. Pomijając transfery i pingi same połączenia z serwerami są stabilne.
Ale czy one korzystają z UDP? Druga sprawa to stos sieciowy - jest opcja, że np. ten w FN ma nisko ustawione timout-y albo co i transfer szlag trafia. Ślę raczej obstawiałbym UDP samo z siebie. Ewentualnie specyfikę kombinacji UDP+GSM. Można sprawdzić za pomocą traceroute ustawionego na UDP zamiast ICMP.
Rozumiem, dzięki za informacje. No cóż, to może jakoś przyszłościowo konstruktorzy FujiNET pomyślą jak to ustrojstwo zuniwersalnić, bo ja na przykład korzystam głównie z internetów mobilnych i raczej nigdy się to nie zmieni, a dotyczy to prawdopodobnie bardzo wielu osób, które podobnie jak ja wyprowadziły się z miasta na wiochę. Nie zamienię świeżego powietrza i przestrzeni na kablówkę, a wręcz przeciwnie, mam nadzieję, że jeszcze kiedyś w przyszłości wyniosę się na jeszcze większe zadupie:-)
Jak rozumiem FujiNET korzysta z protokołu UDP - szybko pogooglałem i widzę, że w przeciwieństwie do TCP, UDP ma działać szybciej kosztem niesprawdzania błędów. Czy z tego dobrze rozumiem, że wynika, że po prostu po sieciach komórkowych jest więcej błędów transmisji, przez co protokół UDP się nie sprawdza? Z kolei TCP przeprowadzając kontrolę błędów pewnie przesyła powtórnie błędne pakiety i dlatego internet na komputerze działa normalnie, a już w Fujinet przez UDP są kłopoty, tak? Czy jeśli tak, to jest taka możliwość, żeby Fujinet działał z wykorzystaniem TCP? Czy to kwestia oprogramowania w ESP?
@jhusak :) Chyba przeceniasz moje umiejętności :) Ta klawiatura wirtualna do lr-atari800 to raczej wypadek przy pracy niż reguła :) Poza tym nie mam FN, więc nie ma na czym testować.
miałem takiego pomysła, żeby postawić tnfs-proxy, mam "już" działającego tnfs'a w pytongu3. Może by to bardzo dramatycznie nie pomogło, ale takiego proxiaka możnaby postawić wewnątrz swojej sieci i oprogramować tak, żeby był bardziej uparty w czytaniu z zewnętrznych serwerków.
W sumie to można sprawdzić, czy by to coś pomogło od ręki - ->link<- odpalić python3 tnfs_client.py [<tnfs-server>] [<tnfs-port>] i zobaczyć, czy będzie działać lepiej na PC