Heiß, heißer, FujiNet

Re: Heiß, heißer, FujiNet
14.03.2020 um 19:08 Uhr von tschak909
Status for 2020-03-14:

* @jeffpiep is hard at work implementing the Atari 1020 plotter emulation. This emulation is unique in that the output is not PDF, but an SVG.

* There are a few more testers of ESP32 boards popping up, and bug reports are coming in.

* The TNFS filesystem implementation is accidentally sending back successes when all retries have been exhausted. It comes from an inconsistent mis-match of return values that happened when we ported the code to use the standard Arduino FS API. Whoops.

* In addition, the TNFS retry timings need to be further tuned, as currently there are more retry attempts than there is time for in the SIO timeout allotted by the OS for most disk operations (5 retries, 5000ms, 25 seconds, compared to 15 seconds for the OS.), We need to decrease the time between timeouts, and do more retries. To this end, I have moved timeout values to #define constants in lib/sio/sio.h

* The N: handler is being debugged, lots of work needing to be done there. OPEN works now, after a complete rewrite of the device spec tokenizer. Other operations currently fail due to stack smashing. I need to re-think how buffers are passed between protocol functions. Any insight anyone can offer for this, please check out the code and dip into sio/network* I did write a theory of operation in the wiki, if anyone is interested.

This is the muck of the project, we’ve done the huge flurry of “ain’t it cool?!” demos, and now we’re rolling up our sleeves, and working through the mix of technical debt and functionality testing. Not to mention writing unit tests :)

-Thom

---

Status für 2020-03-14:

* @jeffpiep arbeitet hart an der Implementierung der Atari 1020 Plotter-Emulation. Diese Emulation ist insofern einzigartig, als die Ausgabe nicht als PDF, sondern als SVG erfolgt.

* Es gibt noch einige weitere Tester von ESP32-Boards, und es kommen Fehlerberichte herein.

* Die TNFS-Dateisystemimplementierung sendet versehentlich Erfolge zurück, wenn alle Wiederholungsversuche erschöpft sind. Das kommt von einer inkonsistenten Fehlanpassung der Rückgabewerte, die passierte, als wir den Code zur Verwendung der Standard-Arduino-FS-API portierten. Hoppla.

* Zusätzlich müssen die TNFS-Wiederholungszeiten weiter abgestimmt werden, da es derzeit mehr Wiederholungsversuche gibt, als in der SIO-Zeitüberschreitung, die vom Betriebssystem für die meisten Plattenoperationen vorgesehen ist (5 Wiederholungsversuche, 5000ms, 25 Sekunden, im Vergleich zu 15 Sekunden für das Betriebssystem). Zu diesem Zweck habe ich die Zeitüberschreitungswerte in #define constants in lib/sio/sio.h verschoben.

* Der N:-Handler wird gerade debuggt, es muss noch viel Arbeit geleistet werden. OPEN funktioniert jetzt, nach einem kompletten Neuschreiben des Tokenizers der Gerätespezifikation. Andere Operationen scheitern derzeit aufgrund von Stack-Zerstörungen. Ich muss neu überdenken, wie die Puffer zwischen den Protokollfunktionen übergeben werden. Jeder, der einen Einblick in diese Problematik geben kann, möge sich bitte den Code anschauen und in sio/network* eintauchen. Ich habe eine Theorie der Funktionsweise im Wiki geschrieben, falls es jemanden interessiert.

Das ist der Dreck des Projekts, wir haben die große Aufregung der "Ist das nicht cool?!"-Demos hinter uns gebracht, und jetzt krempeln wir die Ärmel hoch und arbeiten uns durch die Mischung aus technischer Verschuldung und Funktionstests. Ganz zu schweigen vom Schreiben von Unit-Tests :)
Re: Heiß, heißer, FujiNet
17.03.2020 um 06:08 Uhr von tschak909
#Atari8bit #FujiNet one of the newly added features to the #platformio version of the firmware is "Disk Rotate" which rotates disk images into the next contiguous drive slot clockwise.

https://www.youtube.com/watch?v=Bs3mwpqh718

---

#Atari8bit #FujiNet Eine der neu hinzugekommenen Funktionen der #Plattformversion der Firmware ist "Disk Rotate", die Plattenabbilder im Uhrzeigersinn in den nächsten angrenzenden Laufwerksschacht dreht.

https://www.youtube.com/watch?v=Bs3mwpqh718
Re: Heiß, heißer, FujiNet
17.03.2020 um 18:52 Uhr von tschak909
I work out, every day using #Atari's Personal Fitness program. Previously, I had kept my copy of both the program and data disk that I used every day on two separate floppies, because Personal Fitness only supported one disk drive.

With #FujiNet, I can put the program and data disks in the first two drive slots, and rotate them when needed, to run the program entirely from my local file server or from #FujiNet's local file storage.

https://www.youtube.com/watch?v=0KV2aayuSFs

---

Ich trainiere jeden Tag mit #Ataris persönlichem Fitnessprogramm. Zuvor hatte ich meine Kopie des Programms und der Datenplatte, die ich jeden Tag benutzte, auf zwei getrennten Disketten aufbewahrt, da Personal Fitness nur ein Laufwerk unterstützte.

Mit #FujiNet kann ich die Programm- und Datenplatten in die ersten beiden Laufwerksschächte einlegen und bei Bedarf drehen, um das Programm vollständig von meinem lokalen Dateiserver oder vom lokalen Dateispeicher von #FujiNet auszuführen.

https://www.youtube.com/watch?v=0KV2aayuSFs
Re: Heiß, heißer, FujiNet
18.03.2020 um 00:49 Uhr von tschak909
Wenn jemand bei der Leistungssteigerung des Lese-Caches im #FujiNet helfen möchte, sollte man sich dieses Thema ansehen:

https://github.com/FujiNetWIFI/atariwifi/issues/162

Ich glaube, dass der Lese-Cache intelligenter als ein Ringpuffer implementiert werden kann, der beim Herausschieben von Sektoren konsequent angehängt werden kann. Details im Ticket, einschließlich Link zum Quellcode der aktuellen Implementierung.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)
Re: Heiß, heißer, FujiNet
22.03.2020 um 01:18 Uhr von tschak909
#FujiNet verwendet TNFS, das hauptsächlich über UDP kommuniziert. Das bedeutet, dass die Firmware in der Lage sein muss, Netzwerke mit weniger als idealen Bedingungen zu handhaben, was zu Zeitüberschreitungen, Paketverlusten und sogar zu doppelten Paketen führen kann.

Ich habe die letzte Woche damit verbracht, den TNFS-Code zu überarbeiten, um ihn zu vereinfachen und einen einzigen Code-Pfad für das Senden von Paketen, den Empfang von Antworten und die Behandlung von Timeouts bereitzustellen. Dadurch konnte ich besser sehen, was passierte, und die Wiederholungslogik in den letzten anderthalb Tagen ändern, um sie robuster zu machen, indem ich ein Testnetzwerk verwendete, das großzügig von einem Benutzer bereitgestellt wurde, der sein eigenes #FujiNet aufgebaut hat!

Weitere Statusberichte werden bald folgen!
https://www.youtube.com/watch?v=ULk2Vig7Gts
Re: Heiß, heißer, FujiNet
22.03.2020 um 19:50 Uhr von tschak909
Für jeden, der einen Beitrag leisten möchte, ist eine weitere einfache Erweiterung erforderlich, um die TNFS-Netzwerkleistung zu verbessern, wenn der Cache ausgeschaltet ist (z.B. während der Entwicklung):

Angesichts einer Sektornummer, die in sio_read() kommt:
https://github.com/FujiNetWIFI/atariwif ... sk.cpp#L44

Bestimmen Sie, ob der zu lesende Sektor der nächste Sektor ist. Wenn ja, NICHT SEHEN, sonst führen Sie einen Suchlauf durch.

Die Sektorgröße muss ebenfalls berücksichtigt werden (die ersten drei Sektoren sind 128 Bytes groß, 256-Byte- oder 512-Byte-Sektoren werden derzeit nicht berücksichtigt).

Bei TNFS wird dadurch eine Round-Trip-Kommunikation entfernt und der Netzwerkzugang beschleunigt.
Re: Heiß, heißer, FujiNet
22.03.2020 um 22:54 Uhr von tschak909
#FujiNet Currently for development, disk image selection is very simplistic. No subdirectories, and a max of 16 entries returned. What should we do going forward? How should it look to the user? Who can help make a better implementation?

https://www.youtube.com/watch?v=X8JF8twd46M
Re: Heiß, heißer, FujiNet
23.03.2020 um 06:29 Uhr von tschak909
@jeffpiep has been hard at work implementing the unique sideways printing mode present on the Atari 820. Due to the unique orientation, it's implemented as a custom sideways font. Shown here is actual printed output vs the emulated PDF.

https://cdn.discordapp.com/attachments/655893902380761091/686342961222647808/89120424_10216139221173624_6141993861108465664_o.png

https://cdn.discordapp.com/attachments/655893902380761091/691476062886035486/unknown.png
Re: Heiß, heißer, FujiNet
23.03.2020 um 21:37 Uhr von tschak909
#FujiNet - Shown here is a picture of my local TNFS server that I use for my own file storage. While there are internet-accessible public TNFS file servers, this one is for my own files.

It is a Raspberry Pi 3, inside a FLiRC case, with 64GB of flash, running Raspbian Lite, and the tnfsd software as a systemd service. I am powering it off one of the USB connectors on my power strip.

Total setup time: 30 minutes.

Bild

Instructions to set up, are here:
https://github.com/FujiNetWIFI/atariwif ... spberry-Pi
Re: Heiß, heißer, FujiNet
26.03.2020 um 19:38 Uhr von tschak909
Statusbericht 2020-03-26:

für Codierer, die nach einem Projekt oder einer Möglichkeit zur Hilfeleistung jagen: Ich könnte wirklich etwas Hilfe bei der Implementierung der ATX-Unterstützung gebrauchen, da ich damit beschäftigt bin, andere Teile des Codes zu unterstützen.

Ich habe die letzte Woche damit verbracht, den TNFS-Code durchzuarbeiten:

* Entfernen Sie den Re-Caching-Code, da er fehlerhaft war, in Vorbereitung auf den Refactor.
* Die Wiederholungslogik wurde korrigiert, so dass doppelte Pakete keine Probleme verursachen, sondern ignoriert werden.
* Refactor, um Timeouts richtig zu behandeln und nur dann zu scheitern, wenn alle Wiederholungsversuche fehlschlagen.
* Implementierung des SIO-Befehls für Write with Verify (nicht mehr nur ein Alias für P).
* Implementierung der Suchoptimierung, die nur bei Bedarf sucht, wodurch die Anzahl der UDP-Round-Trip-Pakete für lineare Leseversuche erheblich reduziert wird.

Rick Lopez hat am R:-Code gearbeitet, ihn auseinandergenommen, um ihn zu verstehen, und Verbesserungen vorgenommen. Seine aktuellen Experimente nehmen den Altirra R:-Handler und betten ihn in die #FujiNet-Firmware ein, um ihn per Typ-1-Abfrage weiterzugeben. (Wir haben die Erlaubnis von @phaeron)
Verbesserungen der Pufferung werden auch versucht, die charakteristisch kleinen RX-Puffer zu kompensieren, die der Atari während des gleichzeitigen Betriebs der meisten MODEM-Programme angibt, um die meisten Modemprogramme dazu zu bringen, mit höheren Geschwindigkeiten arbeiten zu können.
Eine Idee, die ich hier vorgeschlagen habe, ist, den R:-Handler so zu modifizieren, daß er vor dem STREAM-Befehl einen zusätzlichen Befehl ausgibt, der die Größe der angeforderten IOCB-Pufferlänge zurückgibt. Dieser kann als sekundärer Puffer verwendet werden, der nur gefüllt wird, wenn er geleert wird, um die Verbindung auch bei höheren Baudraten zu drosseln, wenn der Puffer viel zu klein ist, um höhere Übertragungsraten zu bewältigen.

Wir hacken uns weiter durch den Schlamm :)

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

---

2020-03-26 Status Report:

to coders itching for a project or a way to help: I really could use some help trying to implement the ATX support, as I am busy trying to shore up other parts of the code.

I spent the last week working through the TNFS code:

* Remove the re-caching code, as it was buggy, in preparation for refactor.
* Fix retry logic so that duplicate packets don't cause issues, they are ignored.
* Refactor to properly handle timeouts and to only fail outright if all retry attempts fail.
* Implement SIO command for Write with Verify (no longer just an alias for P).
* Implement seek optimization, only seek when needed, thereby reducing the number of UDP round trip packets significantly for linear reads.

Rick Lopez has been working on the R: code, taking it apart to understand it, and making improvements. His current set of experiments are taking the Altirra R: handler and embedding it into #FujiNet firmware to be passed across via Type 1 poll. (We have permission from @phaeron)
Buffering improvements are also being tried to compensate for the characteristically small RX buffers specified by the Atari during concurrent mode by most MODEM programs, in an effort to get most modem programs to be able to work at higher speeds.
An idea I proposed here is to modify the R: handler to emit an additional command before the STREAM command which returns the size of the requested IOCB buffer length. This can be used as a secondary buffer, only filled when drained, to throttle the connection even at higher baud rates when the buffer is much too small to handle higher transmission rates.

We hack onward through the mud. :)
Re: Heiß, heißer, FujiNet
28.03.2020 um 00:09 Uhr von tschak909
#FujiNet @jeffpiep is checking in the last of the #Atari 822 printing emulation, which provides graphics support! The secret? Using SIO command 'P' instead of the usual 'W', which causes the printer to accept 1 bit per pixel monochrome bitmap data in the same format as a GRAPHICS 8 screen. This was previously undocumented.

---

#FujiNet @jeffpiep checkt die letzte der #Atari 822 Druck-Emulation ein, die grafische Unterstützung bietet! Das Geheimnis? Die Verwendung des SIO-Befehls 'P' anstelle des üblichen 'W', der den Drucker veranlasst, monochrome Bitmap-Daten mit 1 Bit pro Pixel im gleichen Format wie ein GRAPHICS 8-Bildschirm zu akzeptieren. Dies war bisher nicht dokumentiert.

Bild
Re: Heiß, heißer, FujiNet
30.03.2020 um 00:42 Uhr von tschak909
The CONFIG program now has an info screen that shows network information, like the FCONFIG program in fnc-tools.

fujinet_config_1280.jpg
fujinet_config_1280.jpg (365.59 KiB) 63-mal betrachtet
Re: Heiß, heißer, FujiNet
31.03.2020 um 17:25 Uhr von tschak909
Thank you all for the wonderful write up in the latest ABBUC newsletter. :)

-Thom
auf ABBUC.de antwortenauf ABBUC.de lesen alle aktiven ABBUC-Forum-Themen zurück zu atarixle.de