Heiß, heißer, FujiNet

Re: Heiß, heißer, FujiNet
19.07.2020 um 03:19 Uhr von tschak909
#FujiNet #Atari8bit Hallo an alle, die dies lesen, und die vielleicht in der Lage sind, sich einzustimmen:
Ich versuche derzeit, einige Teile des N:-Geräts zu überdenken, solange ich das noch kann (während fast niemand es tatsächlich benutzt).
Das N:-Gerät besteht aus zwei Teilen: Der Handler auf dem Atari, der CIO in SIO umwandelt. Und die Firmware, die SIO in Aktionen auf dem ESP32 umwandelt.
Dies ist von grundlegender Bedeutung, da SIO blockbasiert und CIO zeichenbasiert ist. Um die Diskussion vorerst zu vereinfachen, spreche ich nur über die SIO-Schicht.
DIE SIO-SCHICHT:
Sie können die SIO-Befehle für das N: Gerät hier sehen: https://github.com/FujiNetWIFI/fujinet- ... 1-to-%2478
SIO ist Halbduplex. Sie verarbeitet Daten jeweils nur in einer Richtung, und obwohl es in der Befehlsstruktur ein Feld gibt, das an den Atari gesendet wird, um zu sagen, wie viele Bytes übertragen werden müssen, wird dies nicht als Teil des Befehlsrahmens entweder an oder von FujiNet übermittelt, was wir für READ- und WRITE-Operationen benötigen. Die beiden Bytes AUX1 und AUX2 hingegen schon. Wir müssen also duplizieren, was im DBYT-Feld in den Feldern AUX1 und AUX2 steht, so dass sie als Teil des Befehlsrahmens erscheinen und daher von der Firmware abgefangen werden können.
OPEN - stellt eine Protokollverbindung her, die Nutzlast geht an das FujiNet, und diese Nutzlast ist die N: Dateispezifikation. AUX1 wird zumindest zum offenen Modus, Bit 2 und 3 sind für Lesen und Schreiben bzw. durch den CIO reserviert, so dass wir diese spiegeln müssen.
In OPEN wird AUX2 zum Modus TRANSLATION, d.h. wie übersetzen wir eine Ende-der-Zeile-Sequenz? Derzeit: 0 = keine Übersetzung, Bit 0 übersetzt CR, Bit 1 übersetzt LF, wenn also die Bits 0 und 1 gesetzt sind, dann werden CR/LF zu und von den beiden Endpunkten übersetzt. Wenn beide CR/LF übersetzt werden, wird die Sache komplizierter, denn entweder wird ein Byte HINZUFÜGEN (im Falle der Konvertierung eines einzelnen EOL-Bytes in CR/LF-Bytes) oder ein Byte UNTERZIEHEN (im Falle der Konvertierung von CR/LF-Bytes in ein einzelnes EOL-Byte). Erinnern Sie sich, dass wir im Voraus festgelegt haben, wie viele Bytes zu lesen/schreiben sind? :)
Wenn ein STATUS-Befehl gesendet wird, werden vier Bytes zurückgegeben. BL BH CO ER, BL und BH sind die Low- und High-Bytes der Anzahl der verfügbaren Bytes (bis zu 65535), während CO verbunden ist (1 = verbunden, 0 = getrennt), und ER der Fehlercode ist, der an den CIO-Handler übergeben wird.
Nehmen wir also an, wir lesen Daten von einem HTTP-Endpunkt:
OPEN N:HTTP://www.google.com/
und in einer Schleife:
```
STATUS();
while (status.bytesVerfügbar>0)
{
READ(buf); // Verringert die Anzahl der verfügbaren Bytes.
verarbeiten(buf);
STATUS();
}
```
Als Teil der Schleife führen wir also einen Status durch, um zu sehen, wie viele Bytes verfügbar sind.
Der WEG, auf dem ich mich derzeit mit der Übersetzung befasse, besteht darin, sie buchstäblich zu fälschen, wobei die gleiche Anzahl von Bytes beibehalten wird:
Wenn CR, dann wird EOL in CR übersetzt, CR wird in EOL übersetzt.
Wenn LF, dann wird EOL in LF übersetzt, LF wird in EOL übersetzt.
Wenn CR/LF, dann wird der Sendepuffer um 1 vergrößert (und die Länge des Sendepuffers um 1 erhöht), und EOL wird zu CR, wobei LF unmittelbar danach eingefügt wird, während beim Empfang CR zu einem SPACE wird, während LF zum EOL wird.
Dadurch braucht der Empfangspuffer seine Größe nicht zu ändern. Ist dies eine schlechte Idee?
Eine Variante davon ist die Übersetzung von Verzeichnisdaten für Netzwerk-Dateisystem-Endpunkte. Sie können im OPEN-Aufruf angeben, ob Sie das Verzeichnis lesen möchten (aux1=6), aber jedes Netzwerkprotokoll führt ein Dateiverzeichnis anders aus und stellt eine Liste von Objekten in einer völlig anderen Syntax dar.
Während wir in einigen Fällen die Daten so anzeigen könnten, wie sie sind (z.B. von FTP), erwarten eine Reihe von Atari-Programmen (wie z.B. (AtariWriter) etwas, das wie das Atari-DOS-Diskettenverzeichnis aussieht. Aus diesem Grund verwenden selbst DOS-Systeme wie SpartaDOS standardmäßig ein Verzeichnisverzeichnis, das wie Atari-DOS aussieht. Das bedeutet, dass es derzeit Code in der Firmware gibt, um die Verzeichnisdaten, die von einem Protokoll zurückkommen, in etwas zu übersetzen, das wie ein DOS-2-Verzeichnis aussieht. Gegenwärtig bedeutet dies auch, dass das IST-Lesen von Verzeichnisdaten im STATUS-Aufruf erfolgt, wobei die Daten in den Empfangspuffer geleert werden, während READ den RECEIVE-Puffer auf den Atari leert und ihn anschließend für den nächsten Statusaufruf löscht.
Damit stellt sich die Frage: Gibt es einen besseren Weg? Gegenwärtig besteht der CIO-Handler auf dem Atari aus etwa 1000 Byte Code, mit 256 Byte Puffer darüber (also 1,3K im gesamten Speicherverbrauch). Er ist klein, weil alles auf dem ESP passiert, und der Handler alles durchlässt (mit einigen kleinen Ausnahmen). Die CR/LF-Übersetzung könnte z.B. im CIO-Handler auf den Atari verschoben werden, wobei etwa 40 oder so Bytes Code hinzugefügt werden, aber wie sollten wir Dinge wie die Dateiverzeichnis-Übersetzung handhaben? Ist die Handhabung im Statusaufruf der einzig vernünftige Weg, dies wirklich zu tun?
Gedanken?
Re: Heiß, heißer, FujiNet
19.07.2020 um 06:10 Uhr von tschak909
@jeffpiep hat es wieder getan! OkiMate 10-Unterstützung wurde der Druckeremulation hinzugefügt, komplett mit Farbe!

okimate10color1.PNG
okimate10color1.PNG (236.69 KiB) 708-mal betrachtet


-Thom
Re: Heiß, heißer, FujiNet
20.07.2020 um 05:07 Uhr von tschak909
#atari8bit #FujiNet Während Textübersetzungsoptionen über den AUX2-Parameter in OPEN übergeben werden können, bietet NTRANS die Möglichkeit, diesen Parameter z.B. beim Zugriff auf Netzwerkdateien zu setzen, wodurch Textformate einfach zwischen Atari und anderen Computer-Textformaten konvertiert werden können. https://youtu.be/yNanhqns3_g
Re: Heiß, heißer, FujiNet
Benutzeravatar21.07.2020 um 19:33 Uhr von Rockford
Hello Thorn,

this ist a great equipment for our A8! I missed to order one of them in the first run, but I hope there will be soon a next - or somenone here in germany who can build it for persons who can't build it be themselves (like me...)

Keep on the great work for the best computer ever built!

8bit greeetings, Holger

:notworthy:
Re: Heiß, heißer, FujiNet
Benutzeravatar22.07.2020 um 01:26 Uhr von Mathy
Hallo Holger, Leute

Lenore/Dropcheck arbeitet momentan u.A. am "Atari SIO2IO Externally Housed Combo board":

"This project is still in the beta design phase and it’s exact specs will change. In general it will include the MIDI2SIO in/out connections by Mytek, DB25 parallel printer adapter by Supra Microprint, a basic DB9 Rverter serial port and the finished FujiNet wireless hardware project and be self powered. It should be compatible with nearly all Atari 8bit machines and be connected via a single SIO dongle. At this point it should be able to be sold either fully assembled or as a bare board with BOM."

"Kurz" zusammengefasst:

- Ist noch nicht fertig
- Nutzt eine eigene Spannungsversorgung (Hab Ich das richtig verstanden so?)
- Wird über SIO am Rechner angeschlossen
- Hat MIDI In und OUT ports
- Hat ein einfaches Druckerinterface
- Hat eine einfache serielle Schnittstelle (Modeminterface)
- Es ist Fujinet drin
- Wird's wahrscheinlich geben als Fertiggerät und als Platine mit "Zubehörliste"

Tschüß

Mathy
Re: Heiß, heißer, FujiNet
22.07.2020 um 01:30 Uhr von tschak909
I really don't see the point of Dropcheck's device, as there is considerable overlap with what #FujiNet provides.

(I say this out of frustration, as they simply assumed that they knew what FujiNet was, didn't ask what it could do, much less talk to us, at all, didn't watch any of the videos to get an idea, and threw one in as an afterthought)

-Thom
Re: Heiß, heißer, FujiNet
Benutzeravatar22.07.2020 um 02:19 Uhr von Mathy
Hello Thom

Lenore's device is an All-in-One device. Putting a couple of small devices on one PCB (and possibly in one case). None of the separate devices are of her own design. Not Mytek's/HybridArts MIDI, not Supra's Microprint, not the R-Verter.

I like the idea of having lots of small(er) devices in one case/on one PCB. It saves a lot of space and reduces clutter. It also makes it more feasible to use a separate power supply instead of the Atari feeding power to all of them.

BTW if she wants your device included in her All-in-One device, she obviously things enough people will want to have it in there. Heck, if somebody tells all the world they used something I came up with, I'm proud. It makes me feel like I did something useful for somebody (that I might not even know in real life) and they like it. That's a great feeling!

Sincerely

Mathy
Re: Heiß, heißer, FujiNet
Benutzeravatar22.07.2020 um 18:57 Uhr von Montezuma
tschak909 hat geschrieben:I really don't see the point of Dropcheck's device, as there is considerable overlap with what #FujiNet provides.

(I say this out of frustration, as they simply assumed that they knew what FujiNet was, didn't ask what it could do, much less talk to us, at all, didn't watch any of the videos to get an idea, and threw one in as an afterthought)

-Thom


I fully agree.
Lenore's device makes no sense.
Overlapping functionality may only cause conflicts and missunderstanding.
People will complain that things do not work, because of potencial incompatibility of the projects put together without any good reason.
If I were you I would explicitely forbid to build such monsters.
Re: Heiß, heißer, FujiNet
22.07.2020 um 19:05 Uhr von tschak909
I won't forbid anything, it IS a public project, and this is one of the consequences.

I'm more just disappointed and frustrated, because even after we found out that this was happening, and we went to them and tried to impart what we were going to do, they still chose to do it their way, as is their perogative...

(they = Dropcheck and Mytek btw)

-Thom
Re: Heiß, heißer, FujiNet
26.07.2020 um 22:37 Uhr von tschak909
#FujiNet #Atari8bit Hier sehen wir, wie das CONFIG-Programm in etwas umgestaltet wird, das viel einfacher zu warten und zu lesen ist. Ich mache einen kleinen Sprung durch den Code und zeige, was geändert wird und warum. https://www.youtube.com/watch?v=otHcdlx2gBk
Re: Heiß, heißer, FujiNet
27.07.2020 um 16:41 Uhr von JoSch
Mathy hat geschrieben:BTW if she wants your device included in her All-in-One device, she obviously things enough people will want to have it in there. Heck, if somebody tells all the world they used something I came up with, I'm proud. It makes me feel like I did something useful for somebody (that I might not even know in real life) and they like it. That's a great feeling!

Sincerely

Mathy


Mathy,

sie weiß, dass genug Leute das Gerät haben wollen, weil sie eine Abstimmung über ihre Projekte gemacht.
Das All-in-one Board hat halt gewonnen.

Grüße Jochen
Re: Heiß, heißer, FujiNet
10.08.2020 um 02:21 Uhr von tschak909
#Atari8bit The rewrite for #FUJINET CONFIG is nearing completion, and is now supporting directory pagination, and mounting long filenames! Now to implement the rest... https://youtu.be/mw_qp7KIZW8

---

#Atari8bit Die Neufassung für #FUJINET CONFIG steht kurz vor dem Abschluss und unterstützt nun die Paginierung von Verzeichnissen und das Mounten langer Dateinamen! Um nun den Rest zu implementieren... https://youtu.be/mw_qp7KIZW8
auf ABBUC.de antwortenauf ABBUC.de lesen alle aktiven ABBUC-Forum-Themen zurück zu atarixle.de