FujiNet Tools für SpartaDOS

[Erhard]

Hallo,

(FujiNet = FN)
(Host: TNFS-Server)
(Host-Slot: das FN erlaubt 8 Einträge für Hosts)
(Disk: man verbindet von einem Host eine Datei auf einen Disk-Slot)
(Disk-Slot: Das FN emuliert 8 Disklaufwerke)


================
Vorwort
================

Wenn ich bedenke, wieviel Arbeit (Testen der FN SIO-Kommandos Geräte-Kennung $70, Fehlersuche, Verschöneren) jedes einzelne der eigentlich sehr kleinen Programme gemacht hat ziehe ich hier ausdrücklich den Hut vor dem immensen Arbeitsvolumen, welches der Author / die Authoren in das FN gesteckt haben müssen und noch jeden Tag hineinstecken. Der Zähler allein für Anfragen bezüglich der Firmware stand auf Github kürzlich bei 600 !


================
Die FN Tools
================

Holger hat vor geraumer Zeit angefangen, für das FN die Tools in 6502 Assembler neu zu schreiben. Ich habe mich dann mit eingeklinkt weil ich ohnehin erstens dabei war, die SIO-Kommandos des FN über einen Debugger auszutesten und für mich Unklarheiten auszuräumen und weil ich ein Tool haben wollte was es mir erlaubt, im FN Laufwerke beliebig zu tauschen.

Ob die neuen Tools sinnvoll sind mag jeder für sich selber entscheiden. Wir sind jedenfalls bei so einigen Stellen mit den mitgelieferten Tools auf Schwierigkeiten gestoßen. Nicht generell, aber hier und da hat vielleicht mal etwas nicht funktioniert.

Da Thom im Forum einmal geschrieben hat, daß es für ihn in Ordnung ist, wenn Tools neu und/oder in anderen Programmiersprachen geschrieben werden ist dies nun auch geschehen.

Bei den Arbeiten sind einerseits Fehler in der Dokumentation zu den SIO-Kommandos aufgefallen. Dergestalt, daß ein Schreibkommando mit "Lesen" beschrieben war oder bei einem Kommando ohne Datenübertragung das Status-Register im DCB für Lesen oder Schreiben definiert wurde. Jetzt darf man nicht vergessen, was für ein riesiges Projekt FN ist und das bei der extrem vielen Arbeit, die die Authoren da hineingesteckt haben und immer noch hineinstecken besonders Flüchtigkeitsfehler bei z.B. Copy'n'Paste Aktionen einfach unausbleiblich sind.

Andererseits machte die Firmware des FN an einigen Stellen einen Strich durch die (unsere) Rechnung.

Vorab erst einmal die globalen Stolpersteine. Ich sage extra Stolpersteine, weil es sich nicht um Bugs handelt aber es sind Dinge, die man im Umgang mit dem FN beachten muß.

1) Pfade und Dateinamen zumindest auf TNFS Servern beachten Groß- und Kleinschreibung. Dies hat zur Folge, daß man Pfade und Dateinamen auch genau so eingeben muß. Die Eingabe wird seitens des FN aber augenscheinlich nicht mit den tatsächlichen Gegebenheiten auf dem entsprechenden TNFS Server geprüft sondern einfach so gesetzt. Man bekommt also ein Okay, hängt aber im Nichts.

2) Diverse CLI-DOS wandeln jede Eingabe einfach in Großschrift um. Dazu gehören SpartaDOS 3.2 und 3.3. Für SpartaDOS 3.3 habe ich mir zwei externe Kommandos geschrieben, die diese Umwandlung aus- beziehungsweise einschalten. Und wenn man dann so in Kleinschrift tippt muß man auch daran denken, daß "d2:" kein bekanntes Gerät ist

3) Wenn man auf einem TNFS Server aus dem Hauptverzeichnis in Unterverzeichnisse wechselt behält das FN diesen Pfad nicht über einen Kaltstart (AUS/AN bzw RESET) nicht.

4) Zugriffe auf TNFS-Server verwenden das Protokoll UDP. UDP hat gegenüber TCP einige wichtige Einschränkungen. Üblicherweise wird UDP dort verwendet, wo das Protokoll schlank sein soll und es nicht darauf ankommt, ob Pakete verloren gehen. UDP hält keine Verbindungsinformationen vor. Pakete im Internet können verschiedene Wege nehmen und können somit in einer anderen Reihenfolge eintreffen als sie angefordert wurden. Mit TCP kann man das "aufräumen", mit UDP nicht. Bei UDP muß also mit der Anforderung des nächsten Pakets gewartet werden bis das vorherige angekommen ist, damit man die Reihenfolge im Auge behalten kann und dieses Warten kostet vor allem Zeit.

Ich denke es ist sinnvoll, jetzt einmal die bislang neu erstellten Tools aufzulisten und dann dort auf Schwierigkeiten einzugehen, wo sie bestehen.

FCD.COM Verzeichniswechsel auf einem TNFS Server
FCONFIG.COM Gibt den Status (WLAN, IP, Firmware) aus
FCOPY.COM Kopiere eine Datei
FDSWAP.COM Tausche 2 beliebige Laufwerke des FN
FHOST.COM Setze eine Serveradresse auf einen Host-Slot oder leere diesen
FLD.COM Liste alle Disklaufwerke
FLH.COM Liste alle Host-Slots
FLS.COM Liste den Inhalt eines Verzeichnisses auf einem Host-Slot
FMOUNT.COM Verbinde eine Datei mit einem Disklaufwerk oder leere es
FNET.COM Stellt die Verbingung mit einem Drahtlosnetzwerk her oder trennt diese
FPWD.COM Gibt den aktuellen Verzeichnispfad eines Host an (print working directory)
FRESET.COM Man könnte das FN natürlich auch über den Knopf zurücksetzen
FSCAN.COM Zeigt erreichbare Drahtlosnetzwerke an

FCD
----------------
Groß- und Kleinschreibung bei Pfaden und Dateinamen muß beachtet werden

FCOPY
----------------
Wenn man sich mit FCD bequem durch die Verzeichnisse hangelt und dann auf eine Datei trifft, die man kopieren möchte so funktioniert dies vom aktuellen Ort aus nicht. Ursache ist, daß das FN dem Pfad einen Schrägstrich voranstellt. Das bedeutet für den TNFS-Host aber das Hauptverzeichnis. Dort ist die Datei aber nicht. (Das Problem ist gemeldet und wird eventuell behoben).

In einem Versuch, ein DOS_25.ATR (130K) zu kopieren habe ich festgestellt, daß dies ca 45 Sekunden gedauert hat. Diese Langsamkeit findet ihre Ursache in den kleinen UDP-Paketen und in der oben genannten Wartedauer zwischen den Paketen. Der Atari erlaubt bei einer Sektorgröße von 256 Bytes 65535 Sektoren im herkömmlichen Standard. Mit aktuellen Versionen von SpartaDosX sogar 512 Byte pro Sektor. Wenn man jetzt auf die Idee kommt, von einem TNFS-Server so eine 16 Megabyte (minus 256 Byte) Datei kopieren zu wollen ergibt sich eine Übertragungsdauer von ca 90 Minuten (16 MB geteilt durch 130 KB x 45 Sekunden). Das maximale Timeout der SIO auf dem Atari beträgt aber 255 Sekunden. Demzufolge könnte man höchstens eine Datei der Größe von 600 KB kopieren. Freilich wird man in der Regel nur kleinere Dateien kopieren aber man sollte es meines Erachtens zumindest wissen. (Das Problem ist gemeldet und wird eventuell behoben).

FDSWAP
----------------
Hier kann man zum Beispiel auf dem FN D4:DOS_25.ATR gegen das "leere" D6: tauschen. Danach enthält dann D6: das DOS 2.5 und D4: ist leer. Während der Entwicklung des Programms kam ein Benutzer auf die Idee, daß wenn auf einem Apple Computer eine Disk ausgeworfen wird das Laufwerk ja nicht ausgeschaltet wird sondern es nur keine Disk enthält. Diese gewünschte Funktion wurde flux in die Firmware übernommen womit ausgeworfene Laufwerke des FN jetzt aktiv bleiben.

Da ich das FN in einer gemischten Umgebung mit anderen Laufwerken betreibe habe ich FDSWAP so geschrieben, daß wenn ein Tausch auf ein leeres Laufwerk erfolgt vorher geprüft wird, ob vielleicht außerhalb des FN ein solches Laufwerk (z.B. eine echte 1050) bereits existiert und wenn dem so ist eben den Tausch mit entsprechender Meldung nicht durchführt. Zwei Geräte mit der gleichen Kennung auf dem Bus funktioniert ja nun einmal nicht.

Ich habe das Problem gemeldet und man entgegnete im ersten Anlauf, wer denn wohl neben dem FN noch andere Geräte meint betreiben zu müssen. Ich habe dann angeführt, daß man ja auf die Idee kommen könnte, von einem Diskettenabbild eine echte Disk in einer 1050 erstellen zu wollen. Mein Vorschlag war, das Kommando so zu erweitern, daß man durch Setzen eines Flags (z.B. AUX2 > 127) übergeben kann, ob nur ausgeworfen wird oder ob das Laufwerk auch "ausgeschaltet" wird. (Ein entsprechender Test-Fix wurde wohl erstellt, aber die Firmware dafür hätte ich selber kompilieren müssen und die Programmierumgebung ist dermaßen umfangreich, daß das meine Fähigkeiten übersteigt).

FMOUNT
----------------
Hier gilt im Prinzip das gleiche wie bei FDSWAP. Laufwerke, aus denen der Datenträger entfernt wird bleiben aktiv. Zumindest bis zu einem Kaltstart des FN, wonach ein leeres Laufwerk auch "ausgeschaltet" ist. Ebenso ist zu beachten, daß man Dateien zwar über einen relativen Pfad verbinden kann. Das funktioniert aber nur bis zu einem Kaltstart, denn dann ist das FN bei allen Hosts wieder im Hauptverzeichnis und dort ist die Datei nicht. Soll das kaltstartsicher (reset proof) sein, muß die Datei über den vollen Pfad verbunden werden. (Darf oder muß man oder darf man hier nicht den führenden Schrägstrich verwenden ???)

FNET
----------------
Während der Arbeiten an FNET wurde die Firmware des FN wie folgt angepaßt: Die Programmiersprache des FN verwendet null-terminierte Zeichenketten. Eine SSID z.B. kann 32 Zeichen lang sein. Vorher wurden nur 32 Zeichen übertragen. Es wurde auf 33 Zeichen erweitert. Alte Atari-Software für das FN funktioniert demzufolge nicht mit neuen Firmwareversionen und umgekehrt.


================
Sonstige Infos
================
Die Programme wurden in 6502 Assembler geschrieben. Die Quellen sind verfügbar.
Der verwendete Assembler ist der "FastAssembler".
Der FastAssembler funktioniert unter SpartaDOS X sowie in einer angepaßten Version mit BW-DOS 1.40.
BW-DOS 1.40 ist eine von Holger erweiterte Version von BW-DOS 1.30.
BW-DOS 1.30 und 1.40 konvertieren nicht nach Großschrift.


================
Quellen
================
BW-DOS 1.40 ist zu finden unter https://github.com/HolgerJanz/BW-DOS
FastAssembler ist zu finden unter https://github.com/HolgerJanz/FastAssembler
FujiNet Tools für SpartaDOS sind zu finden unter https://github.com/HolgerJanz/FujiNetToolsSpartaDOS


Rückmeldungen sind ausdrücklich erwünscht.

Es grüßt das Team Holger und Erhard

[tschak909]

Danke, dass Sie das tun.

Ich hatte die fujinet-config-tools als Beispiele geschrieben, und ja, ich entschuldige mich für Fehler, aber dank der Hilfe von Ihnen und anderen, wir debuggen sie alle

Ich hatte alle Implementierungen in C gemacht, weil ich C programmieren kann, als ob ich atmen würde. So konnte ich alles erledigen, auch wenn das Objekt-Binary etwas größer war.

Ich bin also froh, dass verbesserte Tools geschrieben werden

Nochmals vielen Dank

-Thom

[Erhard]

Hi Thom,

Danke, dass Sie das tun.

I am glad that you are not unhappy with us rewriting the tools and I guess the same is true for Holger.

Holger told me he wants to cope with the networking tools next.

Unfortunately I cannot help looking into the sources because I only understand C in so far that it look a bit similar to ACTION!.

But I can look into how FujiNet behaves and report if there is anything which I guess might not work as intended.

The multi platform FujiNet project is that extensive - I am glad its not a project of mine

Being that knowledgable would be great, but being burdend with all that work most certainly not.

Best, Erhard

[tschak909]

I have put it on apps.irata.online, for now.

Maybe this could instead go into the ABBUC TNFS? (if so, I'll remove mine, and make that the canonical place)

-Thom

[Erhard]

Hi Thom,

Maybe this could instead go into the ABBUC TNFS? (if so, I'll remove mine, and make that the canonical place)

I have no idea if they do that. Some time ago I noticed that ABBUC TNFS didn't run totally smoothly. I guess there were timeouts just going through directories as if a robot tape library had to crawl for another tape and put it into the drive.

However I suggest to put a note along with the tools pointing to the original location at github, because there might be updates to the tools. At least if firmware changes make this advisable.

Best, Erhard