Hello, Guest the thread was viewed25k times and contains 217 replies

last post from schorsch3000 at the

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" ... ? :-D

    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.

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

    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.

    Code
    1. wic64_pull_strt
    2. ...
    3. jsr read_byte ; dummy byte for triggering ESP IRQ
    4. jsr read_byte ; data length high byte
    5. sta bytes_send+1
    6. sta tmp ; counter Hhigh byte
    7. jsr read_byte ; data length low byte
    8. sta bytes_send+0
    9. ...

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


    Woher soll man das dann beim Empfang wissen ?

    Quote from darkvision

    Woher soll man das dann beim Empfang wissen ?

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

    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.


    Wäre halt die Frage was du vom WiC64 als Länge bekommst wenn sie grösser als $FF $FF ist.

    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 ?

    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.


    Einfacher ist es, eigener Server vorausgesetzt, das du bei der auszuliefernde Datei zuerst die Länge ermittelst und diese dann einfach vor das File setzt.

    WiC64 wird dann zuerst die beiden ersten Bytes der Länge selbst ermitteln und ausgeben, danach kommt dann schon dein "Header" der die ermittelte Länge enthält, wie viel Byte der enthält kannst du ja selbst festlegen und erst dann kommt z.B. die .D64 Datei.


    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.

    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 dragon
    Quote from rm83

    Sehr nice. Jetzt müsste ich nur endlich mein WiC64 zum Laufen bringen.

    Woran hapert es denn?

    Vermutlich an mir :D. Nach Auswahl der SSID und Eingabe des richtigen Passworts scheint sich mein Wic64 einfach aufzuhängen. Nix passiert mehr, weder am CeVie, noch am Display des Wic64. Bei falscher Passworteingabe bekomme ich zumindest eine Fehlermeldung.

    Quote from darkvision

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

    Nächste Firmware Version kann 2GB Files -- kriegst gleich ne PN


    Quote from rm83

    Vermutlich an mir :D. Nach Auswahl der SSID und Eingabe des richtigen Passworts scheint sich mein Wic64 einfach aufzuhängen.

    Auch das aktuelle Startprogramm von http://www.wic64.de im Einsatz ?

    Quote from DJ SID

    Ich habe dann hier geantwortet: WiC64

    Ich auch. 😊


    VG

    Thomas

    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).

    WhoW! OK, was Du hier vorhast ist ja ein echter Gamechanger beim Übertrag und vermeiden von Medienbrüchen. Mega!


    Bin noch immer baff, und werde mich tatsächlich auf den MP3 fokussieren, auch wenn ich mich jetzt trotzdem nochmal mit GeoGopher und dem anlegen eines Repository beschäftigen möchte.


    Mensch, freue mich über weiters in diesem Kontext!