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

geoWLoad64 v0.02

Anbei wie angekündigt die V0.02 ... Noch keine Beta oder Final... aber es wird

Diese Version kommt ausnahmsweise mit einer Huckepack-Testroutine: Zeitzone vom WiC64 auslesen und die Uhrzeit via NTP-Server abfragen. Bevor ich das in ein eigenes Programm packe wäre Feedback hilfreich ob die angezeigten Angaben korrekt sind.

Die Zeitzone setze ich auf "00" wenn die Rückmeldung vom WiC64 zu Datum/Zeit ungültig ist. Ansonsten wird die Zeitzone nicht geändert. Die Rückmeldung der GMT-Angabe stammt aus dem Programmierbeispiel und das Ergebnis sollte dem entsprechen was man über die WiC-Tools setzen kann.

Wenn das mit Datum+Zeit anzeigen klappt, dann wird das in der nächsten Version entfernt und es wird dafür das geoWiC64rtc geben, das wird dann beim GEOS-Start (nicht rboot) bzw. über den manuellen Programmstart die Uhrzeit setzen.

Änderungen in V0.02:

Im Infoblock gilt jetzt L:http//... für Standard-Linkliste und D:http//... für Standard-Download-URL.

L und D verwende ich ja auch in der UI, daher ist das logischer als +/-....

Neuer Download-Modus "Datei/SD2IEC": Lädt eine Datei in das übergeordnete Verzeichnis auf einem SD2IEC und nicht in das aktuell gemountete DiskImage. Es gibt zwar bereits Dxx/SD2IEC, die beiden Routinen arbeiten aber etwas unterschiedlich.

Die Dxx/-RAM/-Disk/-SD2IEC Routinen arbeiten mit ganzen Blöcken, also muss die Download-Datei ein vielfaches von 256Bytes groß sein. Das reduziert das Zählen der 256-Datenbytes je Block und macht die Routine schneller.

Bei Datei/-RAM/-Disk/-SD2IEC kann die Datei eine beliebige Größe haben, daher muss ich hier die einzelnen Bytes zählen.

Das zählen der Bytes könnte ich theoretisch einsparen wenn ich bis zum Timeout Daten empfange und speichere. Dann weiß man aber nicht ober der Download vollständig war.

SWAPLIST.LST support.

Lädt man eine Datei "SWAPLIST.LST" oder "swaplist.lst" in das Verzeichnis auf einem SD2IEC (Modus "Datei/SD2IEC"), dann wird man anschließend gefragt ob man die Liste aktivieren möchte.

Hat man zuvor die DiskImages in der Liste in das gleiche Verzeichnis geladen, dann sind anschließend die Images über die SWAP-Taste am SD2IEC durchwechselbar...

Ansonsten werden jetzt mehr Fehler abgefangen und der Code wurde optimiert. Zusätzlich gibt es das Programm jetzt auch in (mehr oder weniger schlechtem) Englisch.

Quote from uwe1972

-Uhrzeit wird Korrekt angezeigt

-Die Uhrzeit aktualisiert sich nicht selber

(Ich denke aber mal das ist so) ist ja nur zum Testen

-Nach Beenden und Erneutem Start wird die Uhrzeit wieder aktualisiert

OK, Danke für das Feedback... dann kann ich ja anfangen das Autostart-Programm für die NTP-Abfrage und setzen der Uhrzeit zusammenzubauen, so ganz Falsch scheint der Code ja dann nicht zu sein

Interessant wäre höchstens noch ob jemand von Auswärts (andere Zeitzone) auch die korrekte Uhrzeit sieht. Aber da ich auf die Uhrzeit selbst ja keinen Einfluss habe (und auch nicht auf den GMT-Wert) ist wirklich rein aus Interesse...

geoWiC64ntp v0.1

Nach dem GEOS-WiC64-Demo und geoWLoad64 hier das nächste Utility für das WiC64 und GEOS: geoWiC64ntp - Setzen von GEOS Datum+Zeit beim Systemstart über NTP...

Start vom Desktop aus als Anwendung oder als Autostart-Datei auf der Bootdisk. Tipp: Falls man andere RTC-Autostart-Dateien verwendet (geoCham64RTC), dann geoWiC64ntp als letztes starten.

Download hier oder mit Kurzanleitung hier...

Quote from OliverW.

Quote from darkvision

Ich würde das dann so machen das ich das Format teste, und nur wenn es ungültig ist die Zeitzone auf $00 setze.

Wenn ich das richtig in Erinnerung hatte, muss bei der Sommerzeit eine andere Zeitzone eingestellt werden. Daher sollte das $00 nicht fest im Code vorhanden sein.

Es war die Winterzeit die man anpassen musste... Was mich wundert weil die Winterzeit eigentlich die Normalzeit ist.

P.S. eigentlich muss man für Winter+Sommerzeit im WiC64 was anderes einstellen, den ECT/CET wäre UTC+1, CEST wäre UTC+2. Also aktuell scheint beides nicht zu passen...

geoWiC64ntp hat heute noch die Winterzeit angezeigt. Dann im Infoblock TZN02 eingetragen und manuell gestartet. Zeitzone wurde aktualisiert und die Uhrzeit ebenfalls.

Ich gehe jetzt mal davon aus das sich das WiC64 die Zeitzone merkt. Wenn dem so ist kann man im Infoblock wieder TZNxx eintragen. Das verhindert das die Zeitzone dann bei jedem Start gesetzt wird oder eine Einstellung der Zeitzone über das Portal/WIC-Tools überschreibt.

Im Winter muss man das WiC64 dann wieder umstellen (hoffentlich hat das umstellen irgendwann ein Ende...)

Quote from Stefan_h

Kann es sein das WICc64-Demo nicht mit aktiver SuperCPU richtig funktioniert ?

Evtl. gibt es hier etwas Verwirrung...

Es gibt das WiC64-Demo... das zeigt den Netzwerk-Status an und erlaubt den Start des Portal-Launchers.

Es gibt das Programm geoWLoad64... das erlaubt das herunterladen von Dateien, seit V0.1 auch Batch-Download.

Es gibt zusätzlich geoWiC64ntp... zum setzen den Uhrzeit.

Ich hab das WiC64-Demo eben auch nochmal getestet... das geht mit der SCPU... Danke GuNKeN !

P.S. Könnte ein Mod bitte den Thread Titel ändern in: GEOS-Tools für WiC64 - Demo/geoWLoad64/geoWiC64ntp

P.S. Danke TheRealWanderer

Quote from Stefan_h

Bei mir wird das so angezeigt

Im ersten Screenshot steht WiC64 N.V. = Nicht verfügbar. Ich hab das eben nochmal getestet und hatte an einer Stelle auch mal das Problem.

Kannst Du bitte den C64 mal aus/einschalten, die WLAN-Konfiguration mit wlan-config (wic64.de) aktualisieren und dann nochmal testen? Bei mir hat es dann funktioniert.

Ich schau mir das aber in jedem Fall nochmal an, denn die WIC-Tools haben sich seither stark weiterentwickelt. Evtl. ist da noch ein Fehler enthalten.

Quote from Stefan_h

Interessant mit aktivierter SuperCPU läst sich die Karte nicht einrichten und auch das Portal ist nicht erreichbar. Trotz allem wird aber die Zeit unter GEOS Aktualisiert.

ist so wie es aussieht kein Problem von GEOS

Bei solchen Tests immer auch das WiC64 zurücksetzen und warten bis die IP angezeigt wird. Hier läuft mein zweites WiC64 mit der SuperCPU64 problemlos... ich hab aber eine aufgemozte 64er/V1. Kann also auch an meiner alten SCPU liegen... Und die Firmware ist aktuell ?

Quote from Stefan_h

Da schein es wohl mit meiner Karte und der SuperCPU ein Problem zu geben

Daran will ich noch nicht glauben... auf Deinem Screenshot sieht man ja das die IP ausgelesen wurde. D.h. die Kommunikation an sich funktioniert. Es kommt aber evtl. zu einem Timeout bei der Abfrage von SSID/RSSI was dann zu "WiC64:N.V." führt. Und das kann an meinen schon sehr alten GEOS-Routinen für das WiC64 im Demo liegen... zwischen dem 13.2. und 31.3. hat sich in dem Bereich verdammt viel getan

Ich werde morgen mal das Demo auf den Level von geoWLoad64 bzw. geoWiC64ntp anheben. Stand sowieso auf der ToDo-Liste. Evtl. geht es dann damit besser.

Ich hab eben die v0.2 des WiC64-GEOS-Demo hochgeladen.

Hier hab ich jetzt auf die Code-basis von geoWLoad64 und geoWiC64ntp gewechselt. Hab damit ein paar Tests gemacht, scheint zu funktionieren Ist etwas größer geworden, aber dafür werden Aktualisierungen jetzt einfacher. Neue Funktionen gibt es nicht, nur neue Fehler

Stefan_h : Wie gesagt hatte ich das gestern auch mal das die alte Demo das WiC64 nicht korrekt erkannt hat, egal ob SCPU ein oder aus. Ich vermute aber das mein WiC64 auch einen Wackelkontakt hatte oder nicht richtig gesteckt war, denn ich hatte auch noch andere Probleme mit dem Modul. Nach dem auseinandernehmen des Moduls und wieder zusammenstecken ging jetzt alles.

Die kannst ja mal die v0.20 testen, ob das bei Dir dann besser funktioniert. Hier läuft es mit meiner SuperCPU jedenfalls problemlos.

Quote from Stefan_h

Ja mit der v0.2 ging das gleich auf anhieb

Hattest Du die V0.1 von einer RAMDisk oder von einem Disk-Laufwerk gestartet? Dann hätte ich nämlich eine Idee woran das gelegen haben könnte.

Aber gut zu sehen das sich die Arbeit gestern gelohnt hat