If anyone can help, am trying to debug the n-handler that has been modified to be re-locatable (using .def labels being referenced by a table and a routine that moves the binary in memory while fixing up locations), and get and put are currently failing. I am suspecting that this is because the buffer page isn't aligned.
#Atari8bit Hello, wszyscy. Byłem zajęty przeprowadzką do nowego domu, i nie tylko ustawieniem mojego domu, ale również ponownym uruchomieniem IRATA.ONLINE w nowym domu, jak również ustawieniem mojego laboratorium.
Wszystko jest w większości ustawione w tym momencie, a ja wznowiłem zarówno moją codzienną pracę i pracę nad IRATA.ONLINE i #FujiNet. Reszta tego stanowiska zajmuje się #FujiNetem.
Musiałem dostać kilka zakupów z funduszy, które przyszły z Patreon, dzięki wszystkim, które się przyczyniły:
* Mój laptop rozwojowy (TMA-1) cierpi na rozszerzanie się baterii termicznej, co wypaczyło mój przypadek. 250 dolarów od Patreona zostało wykorzystane na złożenie wniosku o serwis gwarancyjny na miejscu, aby wymienić zarówno moją baterię (co jest cztery lata poza gwarancją), jak i dolną pokrywę baterii, która została uszkodzona. Stanie się to w ciągu kilku następnych dni, gdy tylko mój przedstawiciel firmy Dell potwierdzi moje spotkanie na miejscu.
* Moje urządzenie przechwytujące, które było używane do nagrywania wszystkich różnych filmów #FujiNet, umarło i postanowiłem wymienić je na odpowiednie urządzenie przechwytujące, które można podłączyć do mojego RetroTink 2X upscaler, Elgato HD 60 S+, za 216 USD.
Jestem w trakcie dalszej pracy nad N: rozwój. Kod jest teraz samorelokowalny, dzięki ultradźwiękowemu przykładowi Jona Hallidaya (@flashjazzcat), kod N: działa teraz z powodzeniem pod SpartaDOSem i jest mniejszy niż relokator oparty na ACTION! oraz jest bardziej wydajny.
W tym momencie, N: potrzebuje: * implementacji BINARY LOAD zarówno dla MyDOS jak i SpartaDOS. * Zrobić ?DIR pracę w SpartaDOS * Lista katalogów implementacyjnych dla WEBDAV (HTTP/S) * Wdrożenie reszty z 8.3 do długiego tłumaczenia nazw plików. Jest to trudne, ponieważ musimy zaimplementować pewien rodzaj pamięci podręcznej nazw plików. * (może) poradzić sobie z tym, że SpartaDOS ma górne granice WSZYSTKICH wejść CP. grrr.
Ponadto, N: potrzebuje również funkcjonalnych parserów XML i JSON, które możemy osadzić i z którymi możemy się połączyć. Jest to, w zasadzie, ostatnie 20% rozwoju N:, co zajmie sporo czasu, wraz z debugowaniem każdej możliwej kombinacji DOS/DUP, która może korzystać z urządzenia N:.
Jeszcze więcej, ale chciałem dać wszystkim aktualizację w ciągu ostatnich dwóch tygodni! -Thom
#Atari8bit #FujiNet Dla tych z pierwszej 50 listy, jeśli możesz pomóc hakować na N: urządzeniu, albo po stronie Atari, albo po stronie #ESP32, proszę, skontaktuj się z Thomasem Cherryhomesem, bo osiągam granice tego, co mogę debugować, i mógłbym użyć ludzi mądrzejszych od siebie.
#FujiNet #Atari8bit Pokazany tutaj używa urządzenia N: we wkładce Atari's Music Composer do ładowania/zapisywania kompozycji przez sieć. Jestem teraz w nowym biurze, nie mogę jeszcze znaleźć mojego mikrofonu, więc nie v/o, ALE! Używam mojego nowego Elgato HD 60 S+ do mojego RetroTink 2X, pięknego wideo!
#Atari8Bit #FujiNet works successfully with FoReM XE Pro 5.4, after a few additions to the R: device code. Now I just need to see how to properly set up the file areas, if anyone can help, pls let me know.
#FujiNet #atari8bit Oh patrzcie! Jest Boże Narodzenie w lipcu! Pierwsze 50 płyt produkcyjnych dotarło do miejsca @mozzwald! Dalej, złóżcie na nich konektory! Zapnijcie się, chłopaki! Ci z was, którzy zamawiali w pierwszych 50 partiach, wkrótce będą dostawać wasze!
#FujiNet #Atari8bit Witam wszystkich czytających to, którzy mogą być w stanie zagonić: Próbuję obecnie ponownie przemyśleć niektóre części N: urządzenia, podczas gdy ja nadal mogę (podczas gdy prawie nikt tak naprawdę go nie używa). Istnieją dwie części do N: urządzenia: Handler, na Atari, który konwertuje CIO na SIO. I Firmware, który konwertuje SIO na akcje na ESP32. Jest to zasadniczo ważne, ponieważ SIO jest oparte na blokach, a CIO na znakach. Aby uprościć dyskusję, na razie mówię tylko o warstwie SIO. O SIO LAYER: Polecenia SIO dla urządzenia N: można zobaczyć tutaj: ->link<- SIO to półdupleks. Obsługuje on dane tylko w jednym kierunku naraz i chociaż w strukturze poleceń wysyłanych do Atari znajduje się pole informujące, ile bajtów trzeba przesłać, nie jest ono przekazywane jako część ramki poleceń ani do ani z FujiNet, co jest nam potrzebne do operacji READ i WRITE. Jednakże, dwa bajty AUX1 i AUX2 tak robią. Musimy więc zduplikować to, co jest w polu DBYT w polach AUX1 i AUX2, tak aby pojawiło się jako część ramki poleceń i mogło zostać przechwycone przez firmware. OPEN - tworzy połączenie protokołowe, ładunek przechodzi do FujiNet, a tym ładunkiem jest specyfikacja pliku N:. AUX1 staje się trybem otwartym, co najmniej bity 2 i 3 są zarezerwowane do odczytu i zapisu, odpowiednio przez CIO, więc musimy je mirrorować. W OPEN, AUX2 staje się trybem TRANSLACJI, to znaczy, biorąc pod uwagę sekwencję końca linii, jak ją przetłumaczyć? Obecnie: 0 = brak tłumaczenia, bit 0 tłumaczy CR, bit 1 tłumaczy LF, więc jeśli ustawione są bity 0 i 1, to CR/LF są tłumaczone na i z dwóch punktów końcowych. Wykonanie obu CR/LF komplikuje sprawę, ponieważ albo bajt zostanie DODANY (w przypadku konwersji jednego bajtu EOL na bajt CR/LF), albo bajt zostanie WYKONANY (w przypadku konwersji bajtów CR/LF na jeden bajt EOL). Pamiętajcie, że określiliśmy ile bajtów należy odczytać/zapisać z wyprzedzeniem? :) Gdy wysyłana jest komenda STATUS, zwracane są cztery bajty. BL BH CO ER, BL i BH są małymi i dużymi bajtami # dostępnych bajtów (do 65535), podczas gdy CO jest połączone (1 = połączone, 0 = odłączone), a ER jest kodem błędu, który jest przekazywany do CIO handlera. Powiedzmy więc, że odczytujemy dane z punktu końcowego HTTP: OPEN N:HTTP://www.google.com/ i w pętli: ``` STATUS(); while (status.bytesAvailable>0) { READ(buf); // Decrements # of bytes available. proces(buf); STATUS(); } ``` Więc w ramach pętli, robimy status, aby sprawdzić, ile bajtów jest dostępnych. Sposób, w jaki obecnie zajmuję się tłumaczeniem, to dosłownie zamrażanie go, zachowując ten sam # bajtów: Jeśli CR, to EOL zostaje przetłumaczone na CR, CR zostaje przetłumaczone na EOL. Jeśli LF, to EOL dostaje tłumaczenie na LF, LF dostaje tłumaczenie na EOL. Jeśli CR/LF, wówczas bufor nadawczy zostaje powiększony o 1 (i długość bufora nadawczego zwiększona o 1), a EOL staje się CR, z LF wstawionym natychmiast po, podczas gdy na odbiorze, CR staje się SPACE, a LF staje się EOL. Dzięki temu nie ma potrzeby zmiany rozmiaru bufora odbiorczego. Czy to zły pomysł? Odmianą tego, jest tłumaczenie danych katalogowych dla sieciowych punktów końcowych systemu plików. Możesz określić w wywołaniu OPEN, czy chcesz odczytać katalog (aux1=6), ale każdy protokół sieciowy robi katalog z plikami inaczej, przedstawiając to, co jest koncepcyjnie listą obiektów w dziko różnych tablicach składni. Podczas gdy w niektórych przypadkach możemy wyświetlić dane tak jak są (np. z FTP), wiele programów Atari (np. (AtariWriter) oczekuje czegoś, co wygląda jak katalog na dysku Atari DOS. Dlatego nawet DOS-y takie jak SpartaDOS domyślnie wyświetlają listę katalogów, które wyglądają jak Atari DOS. Oznacza to, że w firmware'ie znajduje się obecnie kod do tłumaczenia danych katalogowych, które wracają z protokołu na coś, co wygląda jak katalog DOS 2. Obecnie oznacza to również, że AKTUALNY odczyt danych katalogowych odbywa się w wywołaniu STATUS, opróżniając dane do bufora odbiorczego, podczas gdy READ opróżnia bufor RECEIVE do Atari, a następnie oczyszcza go do następnego wywołania statusu. Tak więc pojawia się pytanie: Czy jest lepszy sposób? Obecnie CIO handler na Atari to około 1000 bajtów kodu, z 256 bajtami bufora na górze (czyli 1.3K w całkowitym zużyciu pamięci). Jest mały, ponieważ wszystko dzieje się na ESP, a handler przechodzi przez wszystko (z kilkoma małymi wyjątkami). Tłumaczenie CR/LF może być przeniesione do Atari w programie obsługującym CIO, na przykład dodając około 40 bajtów kodu, ale jak mamy radzić sobie z takimi rzeczami jak tłumaczenie katalogów plików? Czy obsługa w wywołaniu statusu jest jedynym rozsądnym sposobem, aby naprawdę to zrobić? Myśli?
#atari8bit #FujiNet Podczas gdy opcje tłumaczenia tekstu mogą być przekazywane poprzez parametr AUX2 w OPEN, NTRANS daje możliwość ustawienia tego parametru np. podczas dostępu do plików sieciowych, co pozwala na łatwą konwersję formatów tekstowych pomiędzy Atari a innymi komputerowymi formatami tekstowymi.
#FujiNet #Atari8bit Tutaj widzimy, że program CONFIG został przerobiony na coś znacznie łatwiejszego do utrzymania i odczytu. Zanurzam się trochę w kodzie i pokazuję co się zmienia i dlaczego.
#Atari8bit Przeróbka na #FUJINET CONFIG zbliża się do końca i obsługuje teraz paginację katalogów oraz montaż długich nazw plików! Teraz, aby wdrożyć resztę...
#Atari8bit #FujiNet W tym (wprawdzie bardzo długim) wideo robię głębokie nurkowanie przez CONFIG 2.0 i decyzje podjęte podczas przepisywania, aby pokazać, dlaczego zostały zrobione i aby pokazać wynikające z nich korzyści.
#FUJINET #ATARI8BIT Ponieważ wywołanie Read Directory może określać długość w AUX1, możemy nadać mu podwójną funkcję wyświetlania listy plików głównych i widok dla dłuższych nazw plików.
#Atari8bit #FujiNet patrz, co się dzieje! @mozzwald włączył do firmware'u pierwszą przepustkę obsługi MIDIMAZE! Wykorzystuje on port UDP 5004, a my musimy znaleźć najlepszy sposób na obsługę wielu graczy...
Oscar Fowler ciężko pracował wdrażając obsługę obrazu dysku ATX dla tytułów chronionych przed kopiowaniem! Pliki ATX są buforowane w całości ze swojego źródła (sieciowego lub lokalnego), dzięki czemu czasy są dokładne.
#Atari8bit tutaj widzimy narzędzia #FujiNet Command używane ze SpartaDOS X, i działają doskonale. Tak, w przyszłości będzie istniał sterownik jądra zapewniający jeszcze lepszą integrację. :)
#FujiNet #Atari8bit z @omf's latest commit fixing sector length for missing/partial sectors, all of the tests on DJayBee's ATX test suite now pass! Dzięki temu kompatybilność wynosi 99%, pozostawiając tylko błędy ochrony. Niech to naprawdę zatonie, #Atari8bit może teraz załadować doskonale zachowane oprogramowanie chronione przed kopiowaniem, OVER THE INTERNET.
#Atari8bit #FujiNet - @jeffpiep pomyślnie przetransportował kod kasetowy z napędu SDrive, i dostał go do uruchomienia gry! Teraz musimy podłączyć go do automatu wrzutowego, aby stał się użyteczny.
#Atari8bit #FujiNet ma wbudowany parser XML i jest używany do parsowania odpowiedzi WEBDAV z lokalnego serwera WWW, aby zapewnić użyteczną listę katalogów!
#Atari8bit #FujiNet ponieważ urządzenie N: może tłumaczyć końcówki linii, jak również mówić WEBDAV, może być używane do modyfikacji plików na serwerach internetowych! Tutaj pokazuję jak używać programu AtariWriter do modyfikowania stron internetowych!
Jestem w pełni świadomy, że SIO nie jest najszybszą opcją.
Ale ci z nas, którzy pracują nad #FujiNet celowo wybrali go na kompatybilność z najbardziej dostępnym 8-bitowym sprzętem Atari, a także całą pomoc zapewnioną przez system operacyjny, aby ułatwić komunikację z jak największą liczbą programów.
Nic nie stoi na przeszkodzie, aby ktoś wziął to, co zrobiliśmy, i dostosował to do PBI.
...lub dla kogokolwiek na jakiejkolwiek innej platformie (C64, AppleII, itp.), aby spojrzeć na to, co zrobiliśmy i używać go.
jeszcze są 2 porty joya i cart ;] ale zdecydowanie SIO robi robotę i dla casuala jak ja obecnie wystarczy. a rozbudowanie fujinet o PBI/cart faktycznie wydaje się relatywnie łatwe. widzę to w przyszłości jak rozszerzenia do C64, gdzie masz złączkę do dwóch portów (równoległego i szeregowego), żeby mieć na życzenie szybkość a generalnie kompatybilność ze "wszystkim".
może się oczywiście zdarzyć, że ktoś bardzo duży nie doczyta powyższego napisu i stwierdzi, że chcę bootować z portu joya. cały "pomysł" polega na dodaniu do FJN (FujiNet == Front Jedności Narodowej) interfejsu PBI, który nie zmieni obecnej funkcjonalności, ale tylko ją rozszerzy.
@pirx: w jaki sposob zabootujesz atari z portu joya?
tylko SIO zapewnia 100% kompatybilnosc z istniejacym oprogramowaniem - zaden z wymienionch przez Ciebie interfejsow I/O na to nie pozwala (PBI rowniez).
bez patchowania kazdy program (nawet te starusienkie z konca lat 70) maja mozliwosc wymiany informacji z "internetami"... Twoje "pomysly" tu sie wykladaja.
Dosłownie patrząc na ostatni film, który opublikowałem, właśnie zredagowałem stronę internetową w AtariWriter.
(na wcześniejszym etapie zapisałem też piosenkę z kartridża Music Composer na serwerze HTTP...)
kilka rzeczy na mojej płycie do wdrożenia:
* Wsparcie SSH (tak, możliwość zdalnego dostępu do skrzynek z Linuksem) * Obsługa SMB (udziały w plikach Windows) * Obsługa programu NFS (uniksowe akcje w plikach) * Parsery JSON i XML (posiadają parser przychodzący #FujiNet, a Atari może zapytać o drzewo wynikowe i pobrać dane za pomocą CIO lub SIO) * Mam rdzeń emulatora Z80 gotowy do pracy, aby dodać obsługę CP/M.
Więc nie tylko będzie więcej protokołów sieciowych dostępnych w krótkim czasie, ale będą też sposoby na przetwarzanie danych z tych protokołów, aby uczynić to o wiele bardziej dostępnym niż jakiekolwiek inne 8-bitowe urządzenie sieciowe, więc rzeczy takie jak możliwość pisania prawdziwego klienta Twittera lub Facebooka, który mówi po rodzimym API (i to nawet w języku BASIC!).
The goal is to handle the API requests to and from web service APIs.
So the method of action would be something like:
5 DIM A$(128),B$(128) 10 OPEN #1,4,3,"N:HTTP://SOME.WEB.SERVICE.COM/api/v4/endpoint.json":REM 3 is CR/LF translation 20 XIO 128,#1,4,3,"N:":REM TELL FUJINET TO GET AND PARSE JSON 30 XIO 129,#1,4,3,"N:some/path/to/your/object":REM QUERY 40 INPUT #1,A$:REM GET VALUE 50 XIO 129,#1,4,3,"N:some/path/to/your/otherobject":REM QUERY 60 INPUT #1,B$:REM GET OTHER VALUE 70 CLOSE #1 80 END
This would be for reading values, writing out values and sending the resulting JSON would be similar. The idea for XML parsing would also work the same way.
Not simple to implement, but we have the computing power on the device, so I am slowly working through how to do this.
Kod źródłowy serwera tnfs jest otwarty, protokół jest prosty i dokładnie opisany. Nie powinno być problemu z przeniesieniem tego. Trzeba tylko siąść i zrobić ;)
Ja już dokonałem kilku zmian w kodzie serwera tnfs, które umożliwiają logowanie aktywności. Dzięki temu na stronie serwerka ->link<- można zobaczyć co było ostanio montowane przez użytkowników Fujineta.
