letzter Beitrag von darkvision am
Hallo in die Runde.......
WIC64, C128DCR im 64er Modus, SCPU64 auf 20MHZ + Geos MP3.
Habe eben erfolgreich das WIC Geosdemo gestartet. Funktioniert bei mir ohne Probleme.
Ein Internetsystem unter Geos MP3 Benutzeroberfläche wäre schon genial.
Liebe Grüße,
Jojo
Evtl. kann GEOS dann sogar nicht mehr nur lokal auf dem C-64 laufen, sondern als "Internet Betriebssystem", daß auf einem Server bereitgestellt wird. Der Benutzer logt sich dann ein und hat seine grafische Benutzerumgebung.
Einfach Klasse........
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.
Liebe Grüße,
Jojo
ich muss ja gestehen das ich mich bis dato nie mit Geos auseinander gesetzt habe - Aber das wird jetzt wohl mal echt Zeit ! Tolle Arbeit - ein echter Mehrwert !
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?
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 
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 ....
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...
Mit der SSL Verschlüsselung hat der C64 nichts zu tun, das managt der ESP.
Denn dieser holt sich die Daten und leitet Sie dann für den C64 passend weiter.
Ups, dann kann ich also auch bald bei Amazon mit dem C-64 auf Shoppingtour gehen, oder meine Steuererklärung abgeben? Ja geili.
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... 
Das downloaden macht langsam richtig Spaß 
(wenn da nicht die lästigen kleinen nervigen Bugs wären...)
Auf RAM-Laufwerken werden die GEOS-Routinen verwendet, das geht dann deutlich schneller.
Das heißt, es muss wirklich ein RAM-Laufwerk sein? Eine RAMLink-Partition reicht da nicht?
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
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... 
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.
