GUI64 Fortschrittsthread

Es gibt 754 Antworten in diesem Thema, welches 90.302 mal aufgerufen wurde. Der letzte Beitrag (19. November 2025 um 14:35) ist von TD1334.

  • WebFritzi Ist es Absicht, dass beim Wikipedia-Artikel der Screenshot auf dem 1084-Monitor so krisselig ist? Falls nicht, könntest du auch die untere Version nehmen, da sieht es etwas fluffiger aus.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ich habe das Bild jetzt aktualisiert, bin mir aber nicht sicher, ob es auch auf der Seite so angezeigt wird. Ich glaube, er benutzt noch das alte. Auf der englischen Seite ist das auf jeden Fall so. Merkwürdig... Ich verstehe nicht, wie ich die Anzeige beeinflussen kann.

    Hier (Bitte melde dich an, um diesen Link zu sehen.) zeigt er das Bild nun richtig an. Aber wenn ich auf "Weitere Auflösung: 1.009 × 647 Pixel" klicke, kommt wieder das alte. Irgendwas ist da nicht richtig.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Irgendwas ist da nicht richtig.

    Das ist bei Dir im Browser gecached. Ich war zum ersten Mal auf der Seite (und hab daher nichts im Cache) und bei mir passt alles.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Ich verstehe nicht, wie ich die Anzeige beeinflussen kann.

    Die Seite mit gedrückter Shift-Taste aufrufen, dann lädt der Browser sie ausdrücklich neu. :-)

    Und danke für kostenlose GoDot-Werbung im Bild! :saint:

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Irgendwas ist da nicht richtig.

    Das ist bei Dir im Browser gecached. Ich war zum ersten Mal auf der Seite (und hab daher nichts im Cache) und bei mir passt alles.

    Ah ja, alles klar. Hab die Bilder im Cache gelöscht, und jetzt sehe ich es auch. Sieht richtig gut aus goloMAK . Vielen Dank!

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • piratgizmo Sind eigentlich keine besonderen Coding-Tricks dabei. Vieles ist straight forward. War nur ne ganze Menge Arbeit.

    Charmante Tiefstapelei bei so maschinennaher Programmierung und Speicheradressenspielchen auf derart alter und limitierter Hardware wo man um Bits und Bytes feilschen muss und auch die grafische Ausgabehardware gut kennen um das so flüssig/low-latency-mässig hinzubekommen wie ich auf Vids gesehen habe.

    Glaub ich gerne das das viel Arbeit war und viel Disziplin (und natürlich Leidenschaft/Faszination/Durchhaltevermögen) auch erfordert. Herzlichen Glückwunsch zu dieser Leistung. Wirklich sehr beeindruckend.

    Vielen Dank! Aber ganz ehrlich: der Code ist nicht besonders optimiert - weder auf Schnelligkeit noch auf Größe. Und das Fenster-Ziehen (evtl. das, was am meisten beeindruckt) mache ich ganz einfach: bei jedem Ziehen eines Fensters, male ich den gesamten Desktop und alle Fenster darauf inklusive der Steuerelemente darin komplett neu. Ziemlich billig. Beeindruckend dabei ist tatsächlich, dass 6510-Prozessor und VIC II so schnell sind, dass das komplett flickerfrei abläuft. Das hat mich sehr überrascht.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Ich finde beide Versionen super aber ich mag die MAC Version etwas mehr. Ich hoffe, dass du die auch in Zukunft noch parallel mitziehste!
    Es ist für mich nicht das MacOS aussehen im speziellen. Wir haben schon wenig Platz und da kommt mir die "fette" Leiste unten etwas wie Verschwendung vor. Die eine Zeile reicht mir vollkommen aus und oben finde ich auch ganz schick. Fenster haben oben ja auch immer ihre Titelleiste wieso dann nicht der Hintergrund genau so?! Die Zeiger-Farbe wäre mir hier z.B. egal, ob die jetzt zu MacOS passt oder nicht.

    Ich finde das ganze Projekt absolut klasse!

    Ja, ich habe keine Ahnung von Hardware naher Programmierung aber das hält mich nicht davon ab Ideen zu haben! ;)

    Mal eine GUI-Dummie-Frage: Wie wird das eigentlich in GUI64 gelöst, dass man damit Programme laden und starten kann, wenn das geladene Programm in den Speicheradressen liegt, die auch GUI64 verwendet? Wird GUI64 dann nicht (teilweise) überschrieben und kann das Laden gar nicht mehr fertig machen?

    Der "Trick" ist, dass die File-Lade-und-Start-Routinen unterhalb von $0800 liegen (das letzte RTS liegt bei $05C0). Da die meisten Programme nach $0801 geladen werden, gibt es fast nie Probleme. Mit dem Doppelklick lädt GUI64 die Datei auch genau dorthin. Nur dann, wenn das Programm eigentlich weiter unten hingehört und mit ,8,1 geladen werden soll, gibt es Probleme. Dafür gibt es sicher ein paar exotische Beispiele. Manchmal hat man aber auch Glück. GEOS z.B. wird mit ,8,1 nach $0110 geladen (File-->Boot in GUI64). Das liegt aber unterhalb von GUI64 und überschreibt daher nichts.

    Kann man nicht die ersten zwei Byte des Programms auslesen, um zu sehen, wo es hin will, und dann zur Not erst die File-Lade-und-Start-Routinen in einen anderen Bereich verschieben und von dort ausführen, damit sie nicht überschrieben wird? Schlagt mich bitte nicht, wenn ich hier Stuss rede. Ich kann nur BASIC und selbst das nicht besonders gut! ;)

    Für mich sind halt zwei Dinge an dieser GUI besonders wichtig, wenn es mehr als nur ne schicke Demo sein sollen. Für den "Daily-Use" müsste ich in der Lage sein mit dieser GUI "alle" möglichen Programme starten zu können. Das wäre für micht das wichtigste und an zweiter Stelle kommt für mich dann das "File-Management" ... also das Kopieren, Verschien, Erstellen und Löschen von Dateien und Disk-Images bzw. Disketten. Es wäre ein Traum, wenn ich mit dieser GUI auf einem SD2IEC Dateien aus einem Verzeichnis in ein D64-Image in einem anderen Verzeichnis verschieben könnte oder von einer echten 1541 einzelne Dateien in ein Disk-Image auf meiner SD-Karte kopieren könnte. Ihr wisst, was ich meine. Ich wollte mir z.B. für meinen BMC64 ein Disk-Image zusammenstellen mit dieser GUI und ein paar One-Filern zum testen. Wenn ich das nur mit dieser GUI an einem echten C64 mit SD2IEC mal eben machen könnte, wäre das mega. Ja, ich habe vielleicht andere Ansprüche als die meisten aber ich kann hier halt nur von dem sprechen, was mich begeistern würde.

    Habe ich schon gesagt, dass ich immer noch voll begeistert bin?

  • Ich hoffe, dass du die auch in Zukunft noch parallel mitziehst!

    Ja, werde ich, weil ich sie auch besser finde.

    Es wäre ein Traum, wenn ich mit dieser GUI auf einem SD2IEC Dateien aus einem Verzeichnis in ein D64-Image in einem anderen Verzeichnis verschieben könnte oder von einer echten 1541 einzelne Dateien in ein Disk-Image auf meiner SD-Karte kopieren könnte.

    Letzteres kannst du schon. An ersterem arbeite ich.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Ok, das ist interessant. Woher weiß denn C64Studio, welche Startadresse es in das PRG schreiben soll, wenn da einmal *=$0400 und einmal *=$0801 steht?

    Jedes * = irgendwas definiert einen Speicherblock. Sobald da irgendein Byte da drin fest definiert ist (sei es per Code oder !byte o.Ä. (ohne ?) Direktive, dann gilt der Block als gesetzt).
    Alle gesetzten Blöcke werden am Ende in der richtigen Reihenfolge ins Assembly überführt.
    Deshalb kann man ja auch solche Bereiche in beliebiger Reihenfolge anführen:

    * = $4000
      lda #$17

    * = $2000
      jmp $4000

    Erzeugt ein Assembly von $2000 bis $4001.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Kann man nicht die ersten zwei Byte des Programms auslesen, um zu sehen, wo es hin will, und dann zur Not erst die File-Lade-und-Start-Routinen in einen anderen Bereich verschieben und von dort ausführen, damit sie nicht überschrieben wird? Schlagt mich bitte nicht, wenn ich hier Stuss rede. Ich kann nur BASIC und selbst das nicht besonders gut! ;)

    Welche Adressen verwendet werden dafür gibt es bei so maschinennahen Progs keine einfache Auslesemöglichkeit, solche Operationen sind auch weit mehr als die ersten (Kilo)Byte allenfalls verteilt, das ist nicht wirklich machbar müsste jedes Prog oder jede Version davon eigentlich ja analysiert werden.

    Moderne Betriebssysteme verhindern solche kritischen Speicherzugriffe dazu fehlt aber eine Menge am C64 unter Anderem das es so wenig Memory gibt und auch keine echte Memory-Protection.

    Als BASIC-Coder nimmt dir das alles der Interpreter ab das Memory-Management. Das Code der direkt auf Speicheradressen zugreift nicht auch "versehentlich" auf "Nur-per-Konvention" geschützte Speicherbereiche zugreift kannst nicht wirklich verhindern.

  • Logbuch 19.11.2025

    • Scrollbar-Paint-Routine umgeschrieben. Deren Implementierung war vorher auf Listboxen ausgerichtet, wo es nur auf die Zeilen ankommt. In Fenstern mit Text weiß man allerdings vorher nicht, wie viele Zeilen es sind. Die neue Routine funktioniert jetzt sowohl für die FileListBox als auch für die Hex-Variante des File-Viewers.
    • File-Viewer: Hex-Variante zeigt jetzt links die Adresse an (beginnend mit 0000)

    Next:

    • Page-Scroll in Hex-Variante
    • Scrolling in Text-Variante

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

    5 Mal editiert, zuletzt von WebFritzi (19. November 2025 um 01:15)

  • Könnte man das GUI64 eigentlich auch komplett mit Tasten bedienen? Nichts dagegen dass es saucool ist, dass man hier endlich ein richtiges Maus GUI hat, aber ich war immer der Typ user der sich nen Norton Commander (Klon) aufmachte und dann die F-Tasten benutzte, für das wichtigste.

  • Jammet Darum kümmere ich mich evtl. später. Hab‘s auf dem Schirm, will aber nichts versprechen.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Welche Adressen verwendet werden dafür gibt es bei so maschinennahen Progs keine einfache Auslesemöglichkeit, solche Operationen sind auch weit mehr als die ersten (Kilo)Byte allenfalls verteilt, das ist nicht wirklich machbar müsste jedes Prog oder jede Version davon eigentlich ja analysiert werden.

    Als reiner BASIC Tüddler hat man mit sowas ja kaum was am Hut. Hatte nur mal gehört, dass die ersten zwei Bytes die Ladeadresse wären?! Mit ",8" würde automatisch zur BASIC-Startadresse geladen und mit ",8,1" würde zu der Adresse geladen, die in den ersten zwei Bytes angegeben ist. Und die zwei Bytes sind bei BASIC Programmen falsch und deshalb muss man die mit ",8" laden. War diese Info falsch? Ich hab keine Ahnung und hatte das einfach so geglaubt.

  • Welche Adressen verwendet werden dafür gibt es bei so maschinennahen Progs keine einfache Auslesemöglichkeit, solche Operationen sind auch weit mehr als die ersten (Kilo)Byte allenfalls verteilt, das ist nicht wirklich machbar müsste jedes Prog oder jede Version davon eigentlich ja analysiert werden.

    Als reiner BASIC Tüddler hat man mit sowas ja kaum was am Hut. Hatte nur mal gehört, dass die ersten zwei Bytes die Ladeadresse wären?! Mit ",8" würde automatisch zur BASIC-Startadresse geladen und mit ",8,1" würde zu der Adresse geladen, die in den ersten zwei Bytes angegeben ist. Und die zwei Bytes sind bei BASIC Programmen falsch und deshalb muss man die mit ",8" laden. War diese Info falsch? Ich hab keine Ahnung und hatte das einfach so geglaubt.

    Deine Annahme ist schon richtig. Die ersten zwei Bytes eines PRG stellen die Ladeadresse dar die verwendet wird wenn man mit ,8,1 lädt. Wie GUI64 damit umgeht entzieht sich meiner Kenntnis.

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.