Die neuen Funtion WIC64_SET_REMOTE_TIMEOUT setzt fuer den naechsten URL fetch das timeout; Der Code dazu ist aber nahezu trivial; wird auch gehen.
Das einzige Programm, das diesen Befehl nutzt ist meines Wissens der Remote Image Viewer, zumindest beim Verarbeiten von PDF-Dateien. Das hat aber auch vorher schon im Vice funktioniert.
Hallo pottendo, danke für die schnelle Umsetzung und sorry, ich bin noch nicht dazu gekommen, einen Testcase zu machen.
Ja, das ist richtig so, wie du es machst.
Googlemaps und der csdb Browser sind eher ein Sonderfall, der Server steht wohl in den USA und es wird https benutzt, beides macht es auch auf dem echten wic ziemlich träge. Ich habe vom Author noch keine Rückmeldung dazu. Beide Programme könnten sehr viel robuster und fixer sein, wenn https aus wäre und wir das ggf. Auf unserem Server hosten würden. Im Moment funktionieren die leider nicht wirklich gut.
Und Programme, die wissen, dass der Request u.U. länger dauert, können den Timeout ja nun dann auch setzen, so wie der Image Viewer das für PDFs macht, das war ja Sinn der Sache.
Ansonsten haben sich die 5s als default bisher eigentlich aus meiner Sicht gut bewährt. Höher will ich den auch aus technischen Gründen ungern setzen wollen.
Ich habe soeben eine neue Firmware-Version veröffentlicht und entprechend auf dem Portal unter "Setup and Config -> Firmware Update" zur Verfügung gestellt.
Mit dieser Version wurden einige Bugs behoben und ein Feature eingebaut, das es Programmen erlaubt, den Timeout für HTTP-Requests zu setzen, damit das WiC64 auch länger auf eine Antwort vom Server warten kann, bevor es den Request wiederholt bzw. letztendlich abbricht. So kann ein Webserver sich dann mehr Zeit nehmen, um Antworten dynamisch zu generieren, z.B. das im Image Viewer von EgonOlsen71 bereits angedachte Feature zur Anzeige von PDF-Dokumenten. Hier nochmal vielen Dank an Egon, der durch diese neue Anforderung an das WiC64 dazu beigetragen hat, die Firmware in dieser Hinsicht weiter zu verbessern.
Weitere Details zu den Bugfixes und Änderungen findet ihr im Changelog auf Github.
Die wic64-library wurde an die neuen Befehle angepasst und einige kleinere Bugs behoben, darunter ein Problem mit wic64_detect, das bei manchen mainboard/CIA-Kombinationen zu timeouts führen konnte.
Auch hierzu finden sich weitere Informationen im Changelog auf Github.
Für diejenigen, die die Bibliothek bereits benutzen (?) und dabei die Konstante WIC64_SET_TIMEOUT verwenden, sei darauf hingewiesen, dass diese nun in WIC64_SET_TRANSFER_TIMEOUT umbenannt wurde, um sie eindeutiger von der neuen Konstante WIC64_SET_REMOTE_TIMEOUT unterscheiden zu können.
Die Dokumentation wurde entsprechend angepasst und im Bezug auf diese beiden Befehle verbessert.
ich kann es leider noch nicht so richtig öffentlich machen, weil dazu die neue WiC64-Firmware "stable" sein sollte.
Ich mache dieses Wochenende noch einen neuen stable Release.
BOM = Bill Of Materials
Ich denke mal nicht, das GMP was dagegen hat, dafür gibt es ja die Gerber-Dateien.
Mann sollte aber die Filter-Kondensatoren auch noch tauschen und die beiden an den Pot-Y und Pot-X haben wohl auch andere Werte und sollten auch getauscht werden.
Ja, die Filter-Kondensatoren müssen schon passen.
Die Kondensatoren für die Potis machen den Bock meiner Erfahrung nach aber wirklich nicht fett, selbst wenn man die für das jeweilige Sid-Modell "falschen" Kondensatoren auf dem Board hat. Man kann in beiden Fällen den gesamten Bereich mit einem herkömlichen Paddle abfahren, was für die meisten Spiele völlig ausreicht.
Nur, wenn man darauf besteht, dass die Mitellstellung des Potis auch genau den Mittelwert 127 liefert, muss man die korrekten Kondensatoren haben. Sonst ist die Mitte halt bei 124 oder 130. Praktisch fällt das kaum in's Gewicht, auch bei Spielen wie Monsterbuster nicht, wo der "Zielpfeil" direkt die Poti-Position wiederspiegelt, auch da ist Mitte gefühlt immer Mitte.
Mit dem MixSID kann man das gut ausprobieren, wenn man beide Modelle drauf hat, da dann nur der jeweils primär geschaltete SID die Messwerte liefert, aber nach wie vor einfach die auf dem Mainboard verbauten Kondensatoren verwendet werden.
Ich habe jetzt mal zum Testen die 2.0.1-8 unstable version über das Portal bereitgestellt.
Hier wird jetzt nur noch ein Retry der Anfrage durchgeführt, falls mindestens noch eine Sekunde Zeit bis zum Ablauf des über WIC64_SET_REQUEST_TIMEOUT ($32) gesetzten Timeouts übrig ist.
Dies sollte für den Fall ausreichen, für den das Retry ursprünglich gedacht ist, nämlich bei zwischenzeitlichem Verlust der persistenten Verbindung (Stichwort keep-alive) automatisch eine neue Verbindung aufzubauen, ohne das der client das selbst handeln müsste. Das habe ich soweit es geht getestet.
In deinem Anwendungsfall sollte also nun kein Retry mehr durchgeführt werden, falls die erste Anfrage auf z.B. ein großes PDF bereits in den Timeout gelaufen ist, bitte teste das vielleicht nochmal.
Ich werde da im Laufe des Tages noch andere Programme testen, um zu sehen, dass alles mit dieser Verhaltensänderung noch so wie vorher funktioniert.
Schön, dass es damit erstmal klappt.
Ich muss allerdings nach dem Kommando $50 noch einmal Daten abholen (und ignorieren). Mir ist nicht ganz klar warum, aber andererseits ist es mir auch ein bisschen egal, solange es funktioniert.
Du musst an der Stelle halt einfach das Protokoll erfüllen. Der Befehl liefert zwar keine Daten, aber dasser keine Daten liefert, musst du noch mitkriegen und quasi quittieren, also konkret muss zumindest noch der Response-Header abgeholt werden, in dem dann halt eine Response-Size von 0 steht. Ansonsten würde der ESP erst nach einer Sekunde (dem Default-Transfer-Timeout) den Befehl auf seiner Seite abbrechen, und wenn du dann davor schon einen neuen Befehl absetzen würdest, würde die Firmware deine Handshakes dann als noch zum alten Transfer gehörend fehlinterpretieren, und beide Seiten wären verwirrt. Die alte Firmware war da nicht so streng, aber die war auch sehr viel einfacher gestrickt. In der neuen konnte (und wollte) ich das nicht umsetzen, da es die ganze Sache auf beiden Seiten extrem verkompliziert hätte, und meiner Meinung nach auch nicht sauber gewesen wäre. Protokoll ist halt Protokoll das sollte einfach klar definiert sein, und keine unnötigen Ausnahmen und Randfälle haben, nur um dem Client die Option zu geben, zwei bytes nicht unbedingt abholen zu müssen. Die machen den Bock ja nicht fett.
In den highlevel-Funktionen der Library ist das auch schon alles gleich mit eingebaut, da kann man das garnicht vergessen.
Eine Frage noch: Wenn der gesetzte Timeout abläuft...ist die Anfrage dann beendet? Oder kommt dann wieder dieser "ich probiere es erneut"-Mechanismus zum Zug? Das wäre...ungünstig
Da hast du recht und das ist mir auch klar. Der ganze Mechanismus ist vielleicht zuviel des Guten, vor allem da man jetzt ja auch mit dem neuen Befehl besser mit langwierigen Anfragen umgehen kann, und die neuen Protokolle auch generell bessere Fehlerbehandlungsmöglichkeiten bieten. Das mit den Retries habe ich recht früh eingebaut, macht vielleicht jetzt gar keinen Sinn mehr. Da ist die Verantworung für eventuelle Retries vielleicht auch generell besser beim client aufgehoben. Ich muss da noch mal gründlich drüber schlafen...
Noch eine Frage. Wenn ich das Ergebnis in den Bildschirmspeicher schreibe, dann habe ich so "komische" Zeichen hinter dem RSSI Wert. Was ist das?
Das ist die Ascii-Zeichenfolge "dbm" gefolgt von einem terminierenden Nullbyte. Das müsstest du zur Anzeige eignetlich noch in Petscii wandeln und dann auch über $ab1e ausgeben, statt es in den Bildschirmspeicher zu poken.
Ich hatte zwischenzeitlich überlegt, ob ich diese textuellen Antworten schon vom WiC64 aus nach PETSCII wandle, aber da das die alte Firmware auch als ASCII geliefert hat, hätte das dann wieder zu Problemen mit älteren Programmen geführt.
Die Antwortformate der Befehle sind aber auch alle in der Doku genau beschrieben, siehe z.B. WIC64_GET_RSSI
SYS 49170,<Pufferaddresse>....maybe?
Ja, das sollte den Befehl an <Pufferaddresse> absetzen, wenn ich das richtig verstehe. Aber ohne Gewähr 
ber ich weiß nicht, wie ich diese Bytefolge da oben übergeben muss...welcher Aufruf ist das?
Ich habe die Universalroutinen leider selbst nie aus Basic heraus benutzt, da bin ich überfragt.
Da kann dir YPS bestimmt viel besser weiterhelfen als ich.
Ports für andere Assembler müsste es gar nicht geben, hätte ich gesagt. Nur eine fertige Binärdatei mit einer Art Jumptable (damit sich die Einsprünge nicht mit jeder neuen Version wild verschieben) und entsprechender Dokumentation zu den Vorbedingungen für den Einsprung und was der macht. Mit würde das völlig reichen und das kann man dann auch von BASIC aus nutzen, wenn man mag.
Ja, das stimmt natürlich, damit würde man sicher beides abdecken. Ist ja auch im Prinzip das, was die Universalroutinen eh schon bieten.
Im Portal habe ich jetzt für dich zum Testen die 2.0.1-4 unstable-Version bereitgestellt.
Diese Version unterstützt einen neuen Befehl $32, der analog zu WIC64_SET_TIMEOUT funktioniert und den Timeout des HttpClients für den jeweils nächsten Request setzt. D.h. der müsste dann auch vor jedem entsprechenden Request durchgeführt werden.
Im Legacy-Protokoll sähe der Befehl dann so aus:
!byte "W", $05, $00, $32, <seconds>
Falls es damit funktioniert mache ich dann auch zeitnah einen neuen stable Release damit fertig.
Woher kommen die Unterschiede zwischen dem Wert im Display und der programmtechnischen Abfrage?
Der Wert im Display wird immer nur dann aktualisiert, wenn das Display durch die Firmware aktiv geändert wird, und das passiert im laufenden Betrieb bisher fast nie. Es ist also im Moment noch nicht wirklich "live". Ich habe dem auch bisher nicht viel Beachtung geschenkt, wenn ich ehrlich bin. Ich könnte mal versuchen, einen low-priority-Task mitlaufen zu lassen, der das Display wenigstens alle paar Sekunden mal anstubst.
Das wäre gut. Es geht ja nicht nur um BASIC, sondern auch um andere Assembler. Ich verwende meinen eigenen Assembler (eben einfach, weil ich den von meinem Compiler aus gewohnt bin), nicht ACME.
Im Repository der Firmware habe ich experimentell eine Konvertierung in's dasm-Format, das ist aber erstmal nur Spielerei. Da dissassembliere ich erst das Binary mit da65 und ersetze im Ergebnis rum, bis es dann dasm-Syntax ist. Allerdings gehen dabei noch die Macros verloren, aber die Funktionalität bleibt zumindest schonmal nutzbar. Dasm, weil ich da mal in Richtung einer XCBasic-Lib unterwegs war. Den Ansatz könnte man ggf noch erweitern, zumindest als Basis für zukünftige Ports für andere Assembler.
Allerdings muss ich auch sagen, dass wir mit acme (und damit auch C64Studio) glaube ich schon einen der populärsten Assembler unterstützen. Ports für andere Assembler sind halt schon ganz schön aufwändig.
aber praktisch eben leider nicht, weil das WiC64 zu hektisch ist...
Noch zu hektisch... 
Wäre cool, wenn man das abschalten könnte. Aber bitte in einer Form, die irgendwie ohne die Library funktioniert...also ein paar POKEs oder gerne auch ein kleines Assemblerlistung. Irgendwas, das zu einem BASIC-Programm passt.
Für diesen Fall füge ich einen Befehl hinzu, den man auch noch mit den Universalroutinen wird absetzen können.
Uns ist übrigens klar, dass es jetzt noch keine für Basic-Programmierer geeignete Variante der neuen Library gibt, das werden wir aber auch noch mal in Angriff nehmen. Bisher hat halt noch keiner danach gefragt. Inwieweit ich die Variante ABI-Kompatibel zu den Universalroutinen hinbekomme, kann ich allerdings noch nicht sagen.
Irgendwie ist mir so, als konnte man bei Universalroutinen einen Timeout einstellen...!? Aber ich finde keine Dokumentation mehr dazu. Ist die noch irgendwo zu finden?
Das wäre auch bei den Universalroutinen nur der clientseitige Timeout. Der bestimmt nur, wie lange der C64 auf einen Handshake des ESP warten soll, bis er annimmt, dass der Transfer abgebrochen wurde.
Dann gibt es noch einen serverseitigen Timeout, mit dem bestimmt wird, wie lange der ESP auf einen Handshake des C64 warten soll, bis er seinerseits den Transfer abbricht. Der ist eher für Situationen gedacht, in denen der C64 länger braucht, um die Daten zu verarbeiten, z.B. Daten auf Diskette schreiben.
Für diesen Fall bräuchten wir noch die Möglichkeit, den Request-Timeout des HTTP-Clients auf dem ESP bei Bedarf vom C64 aus anzupassen. Das würde ich dann über einen entsprechenden Befehl ermöglichen. Ich baue das mal ein und stelle dann eine unstable-Version zum Testen bereit.
Oh Gott, ich lese gerade meinen eigenen code und sehe, dass ich da tatsächlich eine Retry-Logik drin habe. Sorry, da hab ich echt nicht nachgedacht. 
Die Logik hat auch bisher immer gut funktioniert, allerdings war das immer nur in den Fällen, in denen ein Server mal zwischendurch eine Anfrage auf eine statische Resource, die normalerweise sofort beantwortet hat, verzögert hat.
Da es sich um deinen Image-Viewer zu handeln scheint, nehme ich an, dass du das Bild auf dem Server aus dem Netz ziehst und dann konvertierst, oder?
Den Fall habe ich bisher einfach nicht bedacht. Wahrscheinlich müssen wir für solche Fälle noch die Möglichkeit bieten, den Request-Timeout des HTTP-Clients auf dem ESP einstellen zu können.
Sorry, in dem Fall nehme ich alles zurück und gucke mir das mal an. Was heißt denn genau "Wenn der Server nicht antwortet?" Heißt das, er reagiert garnicht auf Anfragen, oder braucht er vielleicht einfach eine Weile, um die Antwort zu generieren? Schickt er schon die Header, und generiert dann erst den Content?
Der Log der Firmware könnte da weiterhelfen. Dabei aber bitte das hier beachten:
https://github.com/WiC64-Team/…-wic64-to-your-pc-via-usb
Wenn das soweit passt, bitte auf VERBOSE stellen, siehe
