Juergen Johannes Cool! Dann erkennt GUI64 also auch andere Geräte als 15(4/7/8)1-Laufwerke korrekt. ![]()
GUI64 Fortschrittsthread
-
WebFritzi -
August 12, 2024 at 6:17 PM -
Thread is Unresolved
There are 892 replies in this Thread which has previously been viewed 107,032 times. The latest Post (
-
-
Moin,
finde ich auch Super dass Dein GUI64 auch “Fremdformate“ kennt.....

Übrigens, die Firma CMD hatte sich auch schon mal an einer CBMDOS
Oberfläche mit Maussteuerung versucht (Menuette 64). Sehr umfangreich, mit “Modulen“. Nicht so schön kompakt, wie bei GUI64, aber auch funktionell. Vielleicht kann man davon, das Eine oder Andere, als Idee noch nutzen......

Das Programm ist ja auf meiner angehängten Disk in der:
Liebe Grüße,
Jojo
-
- Interesting post
Logbuch 09.12.24
- Durch Kopieren von Zeichensätzen und Sprites unter den Kernal sowie Verlegen des Bildschirmspeichers dorthin Speicher frei gemacht
- File-Viewer implementiert (es fehlt nur noch die Implementierung der Scroll Bar), siehe Bilder
- Diverse Bug Fixes
Wenn der File-Viewer fertig ist, aktualisiere ich das GitHub-Repository und nenne die Version v 1.1.
Please login to see this attachment. Please login to see this attachment.
Please login to see this attachment. Please login to see this attachment.
-
- Interesting post
Logbuch 18.01.25
- Geräteadressen (8 - 30) jetzt kofigurierbar*
- Mouserad-Scrolling für Hex-View von Files
*) Korodny Du hattest recht mit den Settings. Ich habe die Konfiguration dort wieder rausgenommen und sie ins Disk-Menu ausgelagert.
Please login to see this attachment.
Memory Map sieht jetzt so aus:
Code
Display More------------------------------------------------------ $033c - $5f00 : Program code (z.Zt. bis ca. $5500) ====================================================== $5f00 - $6000 : FREEMEM, used, e.g., for copying files ------------------------------------------------------ $6000 - $a000 : 16 KB free for one GUI64 app ------------------------------------------------------ $a000 - $a100 : 16 window structs $a100 - $a800 : 112 control structs $a800 - $ab70 : Buffer for desktop data $ab70 - $ac00 : Buffer for taskbar data $ac00 - $b000 : Buffer for color data $b000 - $c000 : String list for drive A (128 entries) $c000 - $d000 : String list for drive B (128 entries) ------------------------------------------------------ $d000 - $e000 : I/O area permanently mapped in ------------------------------------------------------ $e000 - $e800 : Char set (desktop) $e800 - $ec00 : Char set (taskbar) $ec00 - $f400 : Sprites (z.Zt. bis $f0c0) $f400 - $f800 : Screen memory $f800 - $ffff : 2 KB buffer for file viewer content ------------------------------------------------------Nächste Schritte:
- Endlich SD2IEC-Support (hab mir extra eines dafür gekauft)
- Weiter am Viewer arbeiten (was gar nicht so einfach ist)
-
- Interesting post
Logbuch 26.01.25
- Endlich SD2IEC-Support (siehe Video (mit schlechter Qualität*))
Ich bitte alle Interessierten, den SD2IEC-Access der neuen GUI64-Version (siehe Anhang) auf ihren Geräten zu testen.
Please login to see this media element.
*) Aus der Video-Beschreibung:
QuotePlease excuse the bad video quality. Vice can unfortunately not emulate SD2IEC devices. So, I could not capture a video off my PC screen. Instead, the video was recorded with my phone and shows the screen display of my Ultimate 64 with an SD2IEC device (as device no #10) attached.
-
Quote
Please excuse the bad video quality. Vice can unfortunately not emulate SD2IEC devices.
Falls du ein xum1541 Gerät besitzt (Zoomfloppy oder ähnlich), dann kannst du mit dessen Hilfe evtl. in VICE das sd2iec als "Real Device (OpenCBM)" ansprechen. Dazu in den Einstellungen unter Peripheral devices -> Drive auf der gewünschten Laufwerksseite "IEC device" aktivieren und unter "IEC device type" entsprechend auswählen. OpenCBM muss natürlich installiert sein.
Das unterstützt grundsätzlich nur das original CBM DOS Protokoll (also keine Schnelllader oder ähnliches), dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.
-
dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.
Genau. Interessante Info. Ich schau's mir mal an - scheint mir aber ein bisschen zu viel Aufwand zu sein nur um ein paar Videos von GUI64 zu machen.
-
Das Video ist doch voll ok.
-
dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.
Genau. Interessante Info. Ich schau's mir mal an - scheint mir aber ein bisschen zu viel Aufwand zu sein nur um ein paar Videos von GUI64 zu machen.
Den eigentlichen Nutzen würde ich auch eher darin sehen, dass du damit in VICE debuggen kannst.
-
dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.
Genau. Interessante Info. Ich schau's mir mal an - scheint mir aber ein bisschen zu viel Aufwand zu sein nur um ein paar Videos von GUI64 zu machen.
Den eigentlichen Nutzen würde ich auch eher darin sehen, dass du damit in VICE debuggen kannst.
Ja, da ist was dran.
-
Ich bitte alle Interessierten, den SD2IEC-Access der neuen GUI64-Version (siehe Anhang) auf ihren Geräten zu testen.
Das mit den Laufwerksadressen ist Top
Damit kann ich meine beiden SD2IEC 8 und 11 nutzen.Könntest Du mal testen was passiert wenn Du ein SD2IEC-Verzeichnis mit mehr als 144 Dateien öffnest (Hier: 40 Ordner, 160 Dateien) oder wenn Du ein D81 am SD2IEC öffnest? In beiden Fällen stürzt hier mein C64 ab... Grafikmüll, Bunter Bildschirm... kleinere Verzeichnisse und D64 haben aber funktioniert.
-
darkvision Danke für's Testen!
Könntest Du mal testen was passiert wenn Du ein SD2IEC-Verzeichnis mit mehr als 144 Dateien öffnest (Hier: 40 Ordner, 160 Dateien) oder wenn Du ein D81 am SD2IEC öffnest? In beiden Fällen stürzt hier mein C64 ab... Grafikmüll, Bunter Bildschirm... kleinere Verzeichnisse und D64 haben aber funktioniert.
Ich teste bisher nur auf ".D64". ".D71" und ".D81" sind noch nicht implementiert. Kommt noch.
Nach wie vor sind auch nicht mehr als 127 Dateien in einem Verzeichnis bzw. auf einer Diskette supportet. Ich weiß momentan nicht, wo ich dafür noch den Speicher herholen soll. Das hier ist die Memory Map:
Code
Display More------------------------------------------------------ $033c - $5f00 : Program code ====================================================== $5f00 - $6000 : FREEMEM, used, e.g., for copying files ------------------------------------------------------ $6000 - $a000 : 16 KB free for one GUI64 app ------------------------------------------------------ $a000 - $a100 : 16 window structs $a100 - $a800 : 112 control structs $a800 - $ab70 : Buffer for desktop data $ab70 - $ac00 : Buffer for taskbar data $ac00 - $b000 : Buffer for color data $b000 - $c000 : String list for drive A (128 entries) $c000 - $d000 : String list for drive B (128 entries) ------------------------------------------------------ $d000 - $e000 : I/O area permanently mapped in ------------------------------------------------------ $e000 - $e800 : Char set (desktop) $e800 - $ec00 : Char set (taskbar) $ec00 - $f400 : Sprites (currently - $f0c0) $f400 - $f800 : Screen memory $f800 - $ffff : 2 KB buffer for file viewer content ------------------------------------------------------Und nachladen will ich nicht. Das hat mich an GEOS immer so gestört. Die Directories sind in $b000 - $c000 bzw. $c000 - $d000 gespeichert. Man könnte sicher einiges umarrangieren um diese Bereiche jeweils z.B. um $800 Bytes (also 64 Datei-Einträge) zu vergrößern, aber das möchte ich lieber am Ende der Entwicklung von v1.1 machen. Wer weiß, wie lang der Programmcode noch wird...
-
Nach wie vor sind auch nicht mehr als 127 Dateien in einem Verzeichnis bzw. auf einer Diskette supportet.
Wäre ja auch OK, abstürzen sollte das Programm aber bei großen Verzeichnissen trotzdem nicht. Da sollte schon ein Test rein ob der Speicher voll ist und wenn ja, dann das einlesen eines Verzeichnisses beenden. Das Verzeichnis einer 1541 erlaubt z.B. schon bis zu 144 Dateien, bei einer D81 sind es schon 288.
Eine Testdiskette für D81 mit mehr als 127 Dateien findest Du z.B. hier. Das ist die GoDot-Programmdiskette, die ist Randvoll. Und da stürzt GUI64 ab, weil es den Speicher ab $D000 mit Verzeichnisdaten überschreibt (Laufwerk 9=1581):
Code(C:$d020) io VIC-II: >C:d000 03 00 20 20 20 22 4d 4f 44 2e c2 4c 55 52 20 c8 .. "mod.Blur H >C:d010 49 47 91 d1 00 20 e0 20 51 f9 f7 0c 00 00 3f 0b ig.Q. . q.....?. >C:d020 f0 f0 f1 f0 f3 f4 f0 f0 f1 fe fe f1 f0 f7 fc ff ................ >C:d030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................Hier sieht man das im I/O-Bereich ab $D000 noch Verzeichnisdaten gespeichert wurden. Da ist klar das hier das System irgendwann abstürzt.
Verzeichnisse mit mehr als 127 Dateien sind also nicht unüblich. Ein Absturz sollte man aber vermeiden.
P.S. Für die Disk/Info-Anzeige addierst Du scheinbar für die "Blocks belegt"-Info die Dateigrößen der Dateien im Verzeichnis, d.h. die Anzeige wäre dann ggf. unvollständig. Für "Speicher frei" kommt ggf. die letzte Zeile im Verzeichnis mit "Blocks free" zur Auswertung. D.h. Du müsstest wenn der Speicher voll ist die nächsten Dateinamen ignorieren bis die letzte Zeile erreicht ist.
Ich teste bisher nur auf ".D64". ".D71" und ".D81" sind noch nicht implementiert. Kommt noch.
Ah, OK. Dann aber vielleicht auch DNP unterstützen. DNP ist wie D64/D71/D81, bietet aber Unterstützung für Verzeichnisse, wie z.B. auch im SD2IEC-Verzeichnis. D.h. da könntest Du ".." auch anzeigen und der Wechsel in ein Unterverzeichnis bei "DIR" wäre dann auch möglich:
QuoteDisplay MoreIt is not required that you include the colon before the subdirectory name, as
long as the subdirectory name is preceded by a slash.
Here are some examples of the Change Directory command:
OPEN15,12,15:PRINT#15,"CD:TEMP":CLOSE15
OPEN15,12,15:PRINT#15,"CD//:TEMP":CLOSE15
OPEN15,12,15:PRINT#15,"CD//TEMP/:TEMP2":CLOSE15
OPEN15,12,15:PRINT#15,"CD<-":CLOSE15
OPEN15,12,15:PRINT#15,"CD/TEMP/TEMP2":CLOSE15
JiffyDOS Examples:
@"CD:TEMP",12
@CD//TEMP
@CD//TEMP/TEMP2
@CD<-
@CD/TEMP/TEMP2
D.h. Du müsstest eigentlich für DNP schon alles an Bord haben.
-
darkvision Hast du evtl. ein Beispiel einer DNP-Datei?
Anbei die neueste Version mit d71- und d81-Support.
-
Anbei ein Test-DNP (geht aber nur mit SD2IEC, nicht mit VICE selbst).
Da sind ein paar Test-Verzeichnisse und leere Dateien drauf.
-
So, jetzt ist der Dateimanager von GUI64 fast fertig, wann kommt der Desktop??

-
Anbei ein Test-DNP (geht aber nur mit SD2IEC, nicht mit VICE selbst).
Da sind ein paar Test-Verzeichnisse und leere Dateien drauf.
Danke dir. Läuft jetzt auch mit DNP, siehe Anhang.
-
So, jetzt ist der Dateimanager von GUI64 fast fertig, wann kommt der Desktop??

Der soll so aufgeräumt bleiben, wie er ist.

-
Hab vorhin ein bisschen hin und her kopiert.
Hab das GUI64 PRG File aus dem D64 kopiert und direkt von der SD2IEC aus dem Hauptverzeichnis der SD Karte geladen und: funktionierte 1a !

Dann bisschen von SD2IEC auf 1581 und 1541 auf SD2IEC ausprobiert :Please login to see this attachment.
Die Startleiste verschwindet während des kopieren.
Aber klappt alles wunderbar

Bin dann auf diesen Fehler gestoßen:Please login to see this attachment.
Wollte auf 1541 kopieren und das wollte irgendwie nicht… lag nicht an der Quelle - sondern auf der 1541 Diskette war kein Platz mehr.
Evtl. hilft Dir das WebFritzi beim abfangen der Fehlermeldung !
-
Die Startleiste verschwindet während des kopieren.
Muss sie. Denn im "Normalbetrieb" feuert da unten ein Interrupt, der den Zeichensatz, den Grafikmodus und die Hintergrundfarbe ändert. Wenn aber eine Kernal-Methode Disk-Access hat, schaltet sie Interrups andauernd an und aus. Wenn ich den Interrupt also nicht ausschalte, flackert das schrecklich.
Wollte auf 1541 kopieren und das wollte irgendwie nicht… lag nicht an der Quelle - sondern auf der 1541 Diskette war kein Platz mehr.
Das ist interessant. Ein klarer Bug. Ich kümmere mich darum.
-