GEOS-Tools für WiC64 - Demo/geoWLoad64/geoWiC64ntp

Um zu verstehen wie das WiC64 programmiert werden kann und was es ggf. für Fallstricke gibt hab ich ein kleines WiC64-Demo für GEOS64 bzw. GEOS64/MP64 entwickelt. Das Programm ist nichts besonderes, sind nur die ersten Schritte in die Programmierung.

Das Programm zeigt den aktuellen WLAN-Status an und erlaubt das starten des Portal-Launchers vom WiC64-Server.

Da einige Programme evtl. nicht richtig mit einer SuperCPU oder einem TC64 im TurboModus funktionieren hab ich noch einen Turbo-Switch eingebaut.

Am Anfang hatte ich die Universal-Routinen angeschaut und die für mich notwendigen Passagen abgetippt. Da sind mir schon ein paar Sachen aufgefallen die ich in meinen GEOS-Routinen dann optimiert habe (Wichtig: *NICHT VERBESSERT*, sondern nur anderes gelöst bzw. erweitert).

Die Routinen sind daher evtl. nicht so schnell wie die UniversalRoutinen, aber das war auch nicht mein Anspruch. Das Programm wird auch nicht weiterentwickelt... die Routinen werden eher in andere Programme eingebunden und dann dort ggf. noch erweitert.

Getestet am MKII mit TC64v2 bzw. am MKII mit SuperCPU/RAMLink und dem WiC64 mit Firmware vom 1.1.2022.

Download hier, Quelltext hier.

Quote from kinzi

Höre ich da "Internet unter GEOS" ... ?

Das einzige was mich in Bezug auf "Internet unter GEOS" interessieren würde, das wäre der Download von DiskImages direkt auf Disk oder ein RAM-Laufwerk. Die notwendige Infrastruktur zum schreiben gibt es ja unter GEOS bereits.

Leider scheint das derzeit am HTTP/GET und max. 256x256 Bytes zu scheitern.

Wenn ich die Zeit hab versuche ich mal die Machbarkeit zu demonstrieren... also 64K downloaden und auf Disk wegschreiben. Bis der HTTP/GET aber nicht auf 256x256x256=$(1)00:0000 erweitert wird bleibt das Wunschdenken.

Serverseitige Aufteilung des D64 sehe ich nicht als Lösung an.

Quote from InsertDisk2

Aehm, der Download ist doch nicht direkt limitiert? Es ist doch lediglich das was du zum Server sendest via GET limitiert.

Die Antwort auf HTTP/GET gibt die Anzahl an Bytes zurück, die gesendet werden. Da sind bisher low/high byte.

Folgt da bei mehr als 64Kb noch ein drittes Byte für die Größe ?

Woher soll man das dann beim Empfang wissen ?

P.S.

Eine mögliche Lösung wäre ein neuer WiC64-Befehl an Stelle von "LOAD/HTTP"=$01.

Beispiel "LOADLONG/HTTP"=$xx und da werden dann als Antwort drei oder mehr Bytes als "Datenvolumen" gesendet.

Quote from InsertDisk2

Sprich du wertest die ersten beiden Bytes nicht aus, nutzt sie lediglich um den Fehler auszuwerten. Danach verwirfst du sie und nimmst die nächsten x Bytes als Länge.

Das wäre eine serverseitige Lösung. Will ich z.B. DiskImages von meiner BitBucket-Website downloaden hilft mir das nichts.

P.P.S.

Grundsätzlich sollte die Rückmeldung die genaue Datengröße beinhalten. Wenn ich eine Datei anfordere weiß ich doch nicht immer wie groß die ist. Die Rückmeldung über die Größe sollte also schon stimmen.

Das würde mir bei DNP auch ersparen zuerst die Daten der ersten Blocks auszuwerten um die genaue Größe des DNP zu ermitteln (DNP=2 bis X*256 Blocks).

P.P.P.S.

Quote from InsertDisk2

Indem du deinen eigenen Header "angängst" und auswertest.

Kannst Du dazu mehr sagen?

Wenn ich beim HTTP-Befehl z.B. ein %skip=65536 anhängen könnte, dann könnte ich ja schon jetzt über mehrere URLs die Daten anfordern. Müsste man trotzdem mal testen ob $0000 = 65536 Bytes beim Empfang entsprechen.

Wo finde ich den generell etwas zu den erweiterten Headern ?

Quote from InsertDisk2

Das funktioniert natürlich nur Serverseitig. Auch Dein Vorschlag an die URL z.B. ein skip=xxx anzuhängen würde ja nur funktionieren wenn du das auf Deinem eigenen Server auswertest.

Da war meine Überlegung das die Firmware das irgendwie auswertet und die ersten 64Kb verwirft...

Quote from InsertDisk2

Einfacher ist es, eigener Server vorausgesetzt

Dann lass ich das ganze lieber bleiben. Wie gesagt, die Machbarkeit teste ich ggf. noch. Aber wenn ein Download mit >64Kb nicht geht dann war es das.

Quote from InsertDisk2

Auszuprobieren wäre natürlich, was das WiC64 liefert wenn die Länge über 64kb geht. Es wäre bei Überlauf möglich, dass bei Files =66 bytes wieder die Fehler Auswertung getriggert wird.

Ich sehe schon mir fehlt da einiges an Doku... momentan tendiert die Motivation da weiterzumachen gegen NULL. Davon hab ich bisher nirgends wo was gefunden. Weder in den UV-Routinen noch in der deutschen Anleitung.

Lediglich ein Fehler bei Low-Byte = "!" hab ich gefunden, dann ist der Server wohl nicht erreichbar.

Naja... hab die nächsten Tage eh keine Zeit... bleibt also sowieso erst einmal liegen...

Quote from InsertDisk2

Aehm, der Download ist doch nicht direkt limitiert? Es ist doch lediglich das was du zum Server sendest via GET limitiert.

Ich hab jetzt etwas getestet... Bei einer Datei >64Kb kommen erst gar keine Daten an. Mit knapp 63Kb dauert der download mit TC64 geschätzt nur ein paar Sekunden (ca.3-4s...)

Quote from KiWi

Nächste Firmware Version kann 2GB Files

Das klingt doch super... werde aber die nächsten Tage da kaum Zeit haben...

Quote from darkvision

Wenn ich die Zeit hab versuche ich mal die Machbarkeit zu demonstrieren... also 64K downloaden und auf Disk wegschreiben.

Eben getestet... die 63Kb auf eine GEOS-RAMDisk/REU werden mit TC64 fast ohne Verzögerung weggeschrieben, d.h. download+write ca. 4-5s. Schreibe ich die Daten direkt auf ein D81/SD2IEC dauert es ca. 15-20s. Die Zeiten sind geschätzt, nicht gestoppt.

Ich hab dazu lokal mit python3/http.server einen kleinen Webserver gestartet, eine 63Kb-Testdatei mit zufälligen Inhalten erzeugt, die Datei am WiC64 heruntergeladen und unter GEOS direkt mit WriteBlock auf Disk geschrieben. Das D81 dann zum PC kopiert, die ersten 63Kb abgeschnitten und mittels MD5 überprüft: Ergebnis stimmt zu 100%. Download erfolgreich.

Also Grundsätzlich kann man unter GEOS die Daten schnell genug wegschreiben. Wenn es wirklich dann auch mit 2Gb geht kann man praktisch alle DiskImage-Formate herunterladen und direkt auf Disk speichern.

Das ganze braucht sicherlich noch weitere Tests... und ich müsste mir meine WiC64-GEOS-Routinen aus dem obigen Demo nochmal genauer anschauen. Für den Anwendungsfall waren die noch nicht gedacht und muss ich da noch etwas optimieren.

P.S. Und natürlich die neue Firmware...

P.P.S. Und ich muss aktuell auch keine Bytes mehr zählen, d.h. ich hab die Anzahl an Bytes aus der Rückmeldung vom WiC64 direkt verworfen und solange heruntergeladen bis der Timeout in meiner Routine gegriffen hat. Das dauert dann mit oder ohne TC64 ca. 4sek. länger (ist in 1/10s einstellbar).