Hello, Guest the thread was called6.7k times and contains 96 replays

last post from darkvision at the

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

  • Mit neuer Firmware:

    176Kb Download auf RAM1541 mit TC64: 11sec

    800Kb Download auf RAM1581 mit TC64: 48sec


    In beiden Fällen konnte ich danach direkt auf das Laufwerk zugreifen und die Dateien öffnen.


    Leider scheinen sich das GEOS-TurboDOS für reale Laufwerke und das WiC64 beim download zu stören, beide verwenden das Register $DD00 und die Bits %4+%2 für die Kommunikation. Das direkte schreiben auf eine 1541-Disk ist zwar dennoch möglich, aber eben nur ohne GEOS-TurboDOS:


    176Kb Download auf C=1541 / Kernal-Mode / 1MHz: 484sec


    Der Flaschenhals ist aber das schreiben auf Disk... hab einen Farbwechsel im Rahmen ergänzt und das schreiben dauert bei der 1541 bestimmt 5x so lange wie der Download.

    Bei einer 1581 dürfte es schneller gehen, aber da mehr Daten geschrieben werden müssen dauert es trotzdem etwas länger.


    Da ist aber noch etwas Luft drinn, denn ich hab zum testen MP3 mit den Kernal-Treibern verwendet. Da gibt es einiges an Overhead beim schreiben der Sektoren auf Disk.


    Im Endeffekt wird es dann drei Schreibmodi geben:

    a) Download to RAMDisk (GEOS-Routinen, schnell)

    b) Download to Disk (Kernal-Routinen, langsam)

    c) Download to File (auf einem SD2IEC als neues DiskImage, noch langsamer)


    Für b) und c) könnte es schneller sein auf eine RAMDisk herunterzuladen und dann per DiskBackup auf eine Disk oder DiskImage zu kopieren, da hier dann TurboDOS wieder möglich ist. Bei c) muss man dann halt die Zeit für das erstellen des DiskImage mit einrechnen, das geht aber evtl. dennoch schneller.


    Das werden weitere Tests zeigen müssen... hab aber zwischenzeitlich auch an einer UI gearbeitet... WIP!

    Download-Links können ja sehr lange werden, da muss ich mir noch was einfallen lassen. Evtl. wird die UI auch nochmal komplett überarbeitet...

  • Einfach Klasse........:thumbsup:


    Ich bin, wie immer, begeistert. Download direkt/indirekt auf Commodore System, mit “vernünftiger“ Benutzeroberfläche. Wer hätte sich das früher nicht auch schon mal gewünscht. Anfänge gab es ja, aber wie ich finde, nie richtig umgesetzt. Dank darkvision sieht seine erste Umsetzung, in Verbindung, mit dem WIC64 schon Super aus.:thumbup::)


    Liebe Grüße,

    Jojo

  • darkvision: Wird es "Copy and Paste" für ellenlange Links geben, oder werde ich sie wie früher Buchstabe für Buchstabe eingeben müssen?

    Schau Dir doch mal den Screenshot genauer an, vor allem den unteren Rand ;)


    Copy&Paste geht aus einem GeoWrite-Dokument -> TextScrap oder aus dem TextManager. Der wird über eines der Icons auch eingebunden, den kann man dann z.B. für ein Bookmark-Textalbum verwenden. Copy&Paste vom PC oder einer HTML-Seite wird aber nicht gehen (ist ja kein Browser).


    Alternativ dazu gibt es die Link-Liste (der Link führt dann zu einer TXT-Datei im Netz mit verschiedenen Links/URLs zu DiskImages die man dann per Cursor auswählen kann). Die AREA6510 wird dann für meine Images so eine Liste anbieten, dann muss man bis auf die Link-URL keine weiteren URLs eingeben. Und die kann man als Bookmark im TextManager speichern. Wie groß die Liste max. sein darf muss ich später testen...


    Das mit den langen Links war für mich von Anfang an ein Thema... daher hab ich die letzten Tage versucht meine Text-Eingabe-Routine zu optimieren. Jetzt kann man URLs zwischen 160 bis 254 Zeichen eingeben (je nach Zeichenbreite). Mit den TextScap-Icons kann man die dann mit dem TextManager austauschen. Das ist aber noch WishList und in der UI noch nicht eingebaut...


    Wenn ich wieder etwas mehr Zeit habe dann will ich das mit den Downloads weiter testen, macht mehr SPaß beim Download zuzusehen als zu programmieren ;) Das einbauen der anderen Funktionen ist ja eher Fleißarbeit, da hab ich schon vieles in meinen anderen Programmen wo ich das eine oder andere ggf. übernehmen kann.

  • So... ein paar Ergänzungen... und Enttäuschungen :(


    Ich hab jetzt via HTTP aus dem Internet ein D64 auf eine 1541 geschrieben. War eine Demo-Disk. BASIC gestartet und dann mit Load von der 1541 geladen/gestartet. so weit, so gut. Download unter GEOS auf RAM und Disk geht, und das nicht nur vom lokalen Server :puhh:


    Leider scheinen einige Downloads nicht zu funktionieren, z.B. die über meine BitBucket-Seite... die Links funktionieren mit wget von der Konsole aus, nur nicht über das WiC64. Ich kann mir nur vorstellen das dies etwas mit https zu tun hat (was wohl beim WiC64 nicht ohne weiteres funktionieren wird). Auch ein http:// am Anfang hilft hier nicht weiter... Schade...


    Dafür sind jetzt Routinen enthalten um eben auch auf eine 1541/71/81 zu schreiben, halt ohne das GEOS-TurboDOS. Auf RAM-Laufwerken werden die GEOS-Routinen verwendet, das geht dann deutlich schneller.


    Man kann aus einer (bisher noch temporären) Liste bereits URLs auswählen und das Ziel-Laufwerk einstellen. Der Download so einer Liste wird dann auch nur von HTTP funktionieren...


    Im Infoblock der GEOS-Datei kann man jetzt einen Standard-Server/URL einstellen. Entweder für die Link-Liste oder für die Download-Adresse. Wird beim Start dann automatisch vorgegeben.


    Hab mir die aktuelle Testversion mit angepasstem Infoblock auf meine Startdisk kopiert. Dann kann ich neue Testversionen von meinem lokalen WebServer direkt auf eine RAM81-Disk unter GEOS kopieren ohne das ich was über die SD-Karte am SD2IEC austauschen muss, Download direkt auf das RAM-Laufwerk geht da wesentlich einfacher.


    Zumindest das ist für mich ein kleiner Lichtblick :)


    Als nächstes steht der Download der Link-Liste, TextManager und Scaps auf dem Plan...

    Schreiben in ein neues Image auf dem SD2IEC häng ich mal hinten an...

  • Https://..., naja, muß ja auch nicht gleich das Onlinebanking gehen. Das kommt später ....

    Da wäre ich mir nicht so sicher... müssen die WiC64-Entwickler was dazu sagen. Ich hab nur HTTP-Requests abgesetzt, die werden dann serverseitig durch eine HSTS-Policy nach HTTPS gewandelt. Und da kommt das WiC64 wohl nicht mir klar. Ich hab da zu wenig Ahnung, aber da geht es wohl auch um SSL-Zertifikate und Verschlüsselte Verbindungen. Dürfte mit dem C64 problematisch werden...

  • Ups, dann kann ich also auch bald bei Amazon mit dem C-64 auf Shoppingtour gehen, oder meine Steuererklärung abgeben? Ja geili.

    Ich hab da so verstanden das der ESP SSL handelt... mehr nicht. Naja, abwarten. HTTPS-Requests gehen jedenfalls nicht, eben nochmals getestet.


    Als nächstes steht der Download der Link-Liste, ... auf dem Plan...

    [X] Check... hat aktuell Platz für +/-100 Einträge... Eine Liste mit 45 Einträgen holt sich das Programm in 1-2 Sekunden inkl. der Anzeige des ersten Eintrags... im 1MHz-Modus des C64... 8o


    Das downloaden macht langsam richtig Spaß :D (wenn da nicht die lästigen kleinen nervigen Bugs wären...)

  • Ich hab da so verstanden das der ESP SSL handelt... mehr nicht. Naja, abwarten. HTTPS-Requests gehen jedenfalls nicht, eben nochmals getestet.

    Das ist aber bekannt. Ist ein Bug vom ESP, dazu gibt es auch einen Bug-Report. Da müssen wir einfach warten.

  • Das heißt, es muss wirklich ein RAM-Laufwerk sein? Eine RAMLink-Partition reicht da nicht?

    Nein, ich muss noch ein paar Tests machen, aber es dürfte jedes MP3/FastMode-Laufwerk funktionieren, vermutlich auch eine CMD-HD mit PP-Kabel. Falls die HD+PP nicht geht dann geht jedes RAM-Laufwerk, auch eine RL.


    Prinzipiell soll jedes Laufwerk funktionieren, nur halt mehr oder weniger schnell. Hab vorhin noch ein D64 auf ein SD2IEC/D64 gespeichert um ein Demo von BASIC aus zu starten. Dauert halt länger aber es geht. Da ist aktuell aber auch noch viel Debug-Code enthalten und viele Routinen bedürfen noch der Strukturierung/Optimierung.


    Das ist aber bekannt. Ist ein Bug vom ESP, dazu gibt es auch einen Bug-Report. Da müssen wir einfach warten.

    Das hatte mir Google auch erklärt, daher hab ich irgendwann auch keine weiteren Versuche mehr unternommen. Macht ja nichts, für meine Tests finden sich auch andere Seiten mit ungepackten D64... und mit dem lokalen python.http Server geht es eh immer.

  • Ich hab nur HTTP-Requests abgesetzt, die werden dann serverseitig durch eine HSTS-Policy nach HTTPS gewandelt. Und da kommt das WiC64 wohl nicht mir klar.

    Ein Redirect auf eine andere URL innerhalb des Protokolls wird vom ESP32 unterstützt - also von https://xxx.de auf htts://sub.xxx.de zb. geht - Aber von http:// auf https:// redirecten wird vom ESP32 IDE nicht unterstützt.


    Es gab auch noch eine https Bug das der ESP32 manchmal nicht mehrfach auf den gleichen Server per https:// verbinden wollte - das ist in der nächsten Firmware aber gefixed.

  • TextScraps & TextManager -> [X] Check


    * Sicherheitsabfrage eingebaut

    * Fehlermeldungen ergänzt

    * Laufwerksmodus prüfen (D81 kann man nicht auf D64 kopieren...)


    Das Programm ist jetzt fast komplett... erstellen eines neuen DiskImages auf dem SD2IEC ist der letzte offene Punkt aus dem ursprünglichen Konzept... Die Zielgerade rückt näher :)


    Wenn man ein DiskImage laden will ohne Kennung (D64, D81...) dann startet der Download trotzdem. An Hand der Transfergröße wird dann geprüft ob der Download zum Laufwerk passt. Falls nicht muss der Download wohl trotzdem beendet werden: Ich hab jetzt keinen Weg gefunden dem WiC64 zu sagen es soll die angeforderten Daten verwerfen.


    NativeMode wird auch möglich sein, aber die Größe des Downloads erfährt man erst nach dem Start. Das dürfte aber so selten vorkommen das ich nicht zu viel an Arbeit reinstecke. Wer DNP downloaden will -> Passendes Laufwerk wählen. Ist das DNP kleiner spielt das keine Rolle, das kann das Programm dann anpassen. VALIDATE wird dann aber trotzdem empfohlen (ist das gleiche wie bei GeoDesk...)

  • Aktueller Zwischenstand: Write-2-SD2IEC funktioniert :D


    Hatte davor erst einmal die Bus-Routinen optimiert. Download eines D64 auf SD2IEC/D64:

    Vorher: 1:58min

    Danach: 1:27min


    25% Schneller :)


    P.S. Bei D64 und D81 sind das nach aktuellen Tests ca. 2Kb/sec. mit JiffyDOS.


    Dann ein D64 vom lokalen Server als neues D64-Image auf dem SD2IEC gespeichert... handgestoppt 1:28min... also genauso schnell/langsam wie das schreiben auf ein vorhandenes Image (alles mit JiffyDOS).


    Zum Vergleich:

    Download to RAM41: 19sec

    Backup RAM41 to D64: 36sec


    Damit ist unter GEOS ein Download auf eine RAMDisk und ein Backup auf eine 1541 mit GEOS-Turbo schneller als der direkte Download auf eine 1541 ohne den GEOS-Turbo.


    Aber immerhin... es geht und mich würde der Unterschied nicht wirklich stören :)


    Damit ist das Progy Feature-Complete... jetzt geht es in die BugFix-Phase... dann wird es Zeit für eine preAlpha-Version zum testen :)

  • das ist in der nächsten Firmware aber gefixed.

    Könnte man dabei auch mal prüfen ob der HTTP/GET-$25-Befehl auch bei Dateien < 64Kb funktioniert ?


    Ich hatte die bescheuerte Idee dem Anwender auch den Download von anderen Dateien zu erlauben, z.B. .CVT (für den Download konvertierte GEOS-Dateien) oder GIF-Dateien. Und weil man ja im Vorfeld nicht weiß wie groß die Datei ist verwende ich für den Download immer HTTP/GET-$25. Die paar Taktzyklen die das länger dauert spielen bei längeren Downloads eh keine große Rolle mehr.


    Eine Datei mit ~10.000 Bytes lässt sich mit HTTP/GET-$01 problemlos herunterladen.


    Die gleiche Datei mit dem $25-Befehl sendet zwar den GET-Befehl an den Server, das zeigt das Log-File an, aber die 4-Längenbytes die da zurückgemeldet werden passen absolut nicht.

    Da ich beim holen der Bytes aus $DD01 warte bis ein Timeout auftritt, bin ich der Meinung da werden gar keine Daten bereitgestellt: das Byte das nach dem Timeout ausgelesen wird ist das letzte Byte das zuvor mit einem GET/$01 korrekt übertragen wurde.

    Natürlich muss ich nach dem Timeout abbrechen... aber dann hätte ich das mit dem letzten Byte eines funktionierenden GET nicht herausgefunden...


    Wenn die die angeforderte GIF-Datei auf dem Server durch ein D64 mit mehr als 64Kb ersetze dann funktioniert der gleiche GET-Befehl. D.h. nur durch serverseitiges ändern der Dateigröße funktioniert der GET-Befehl im clientseitig unveränderten Programm. Die URL ist fest einprogrammiert, ich kann da also keine Tippfehler machen. Der HTTP-Request kommt ja in beiden Fällen an meinem Server an...


    Mit D64/D81 funktioniert der GET/$25 problemlos, hab da jetzt zum testen bestimmt mehr als 100 Images auf verschiedene Laufwerke heruntergeladen, bzw. als Datei gespeichert und mit geoConvert dann auf Disk entpackt. Auch das erstellen eines neuen Images auf SD2IEC klappt problemlos.


    Das sieht für mich so aus als ob der GET/$25-Befehl anders funktioniert als GET/$01... :nixwiss:


    Oder muss ich in so einem Fall nach einem Timeout den Dowload über GET/$01 nochmals anwerfen?

    Wenn ich schon keine Längen-Bytes bekomme weiß ich ja das die URL gültig sein muss, sonst würde ich den Fehlercode "!" zurückbekommen. D.h. wenn gar nichts zurückkommt, auch kein Fehlercode, dann den Download mit dem anderen GET neu starten? Muss ich mal testen... ist mir gerade erst so eingefallen.