Beiträge von LazyJones

    Mein Starter-Setup 1986 war ein C64 Assy 250466, eine 1531 Datassette mit Adapter und ein Highscreen Grünmonitor. An den habe ich mich so gewöhnt, dass ich mir später keinen Farbmonitor mehr gekauft habe. Ein Jahr später kam ein 1541-Nachbau ins Haus, hart erspart. Es war eine tolle Zeit und die wird der neue C64 Ultimate so nicht zurückbringen, zumal ich jetzt an die UII+ Cartridge gewöhnt bin... Ich persönlich sehe noch nicht den Mehrwert eines C64 Ultimate. Ich warte noch ab.

    Die Zeit wird es nicht zurückbringen, weil wir damals alle viel viel Freizeit hatten und uns in Ruhe mit dieser neuen Welt beschäftigen konnten. Es war alles noch in den Anfängen und Wissen wurde auf dem Schulhof geteilt oder hart in Stadtbibliotheken aus Büchern "erarbeitet".

    Das Geld war knapp und man hat auch mal ein paar Monate sparen müssen um z.B. die von dir erwähnte REX oder OCEANIC Floppy kaufen zu können. Bei mir waren die anderen nachher total neidisch weil die Nachbaufloppy kleiner, leiser und ich glaube sogar einen Ticken schneller war als die originale 1541 :-)

    Wenn ich das richtig verstehe, ist der gesamte Rechner aus bereits einzeln von verschiedenen Herstellern beziehbaren Teilen zusammengestellt oder?


    Das Board in den Videos sieht aber nicht nach dem Ultimate Board aus - Ich vermute dass das als Basis (vor allem die Software) dienen wird, wenn ich das richtig verstehe.

    Der aktuelle Code ist jetzt hochgeladen:

    Hi WebFritzi


    Schon mal vielen Dank - da ich in Assember nicht so gut bin, ist hier immer noch mindesten eine Person von nöten, die das ganze unterstützen möchte von der Assembler Seite aus und dann könnten wir auch ggf. Fragen klären :-)


    Die von dir geplanten weiteren Funktionen, sind hier noch nicht enthalten sind oder?

    Eine Sache hat mir etwas Zeit gekostet: Ich hatte zuerst die Zieladresse zum Ablegen der gelesenen Daten auf $4000 gesetzt und beim Nachschauen mit dem Monitor lagen die Daten nach dem Einlesen auch dort. Nur, wenn das Programm dann in den Subroutines weitergearbeitet hat, kam manchmal Buchstabenquark raus. :gruebel

    Das Thema Static ist ein guter Hinweis. Der wäre aber auch nicht in meinem Erklärvideo vorgekommen, obwohl alle funktionen und subs in meiner Library statisch definiert sind.


    Aber super das du zurecht gekommen bist. Ich werde dir einen Codeschnipsel für den Return in das Portal zukommen lassen.

    Sehr schönes Projekt und für den Einstlieg schon eine anspruchsvolle Aufgabe!

    Die tolle WiC64-Library von LazyJones hat mich zu XC-BASIC geleitet und damit konnte ich meinen Wunsch gut umsetzen.

    Vielen Dank für das Lob! Hattest du dir das Youtube Video zum Thema angesehen und dies hat alle für dich notwendigen Informationen enthalten - oder hattest du Klippen die du umschiffen musstest, die ich ggf. in die Doku oder als Beispiel nochmal einbauen soll?


    Bestens!! Würde ich schon gleich gerne imWIC64 Menü unter Menüpunkt Internet hinterlegt sehen. Superduper sag ich nur!!

    Wenn die finale Version vorliegt und ein Rücksprung ins Portal über die Pfeiltaste eingebaut ist (XC-Basic Code dafür kann ich zur Verfügung stellen) dann steht dem platzieren im Portal bestimmt nichts im Wege :-)

    Hallo WebFritzi,


    Vielen dank für deine positive Rückmeldung :-)

    Ich denke wir warten für die "Internet Erweiterungen" erstmal deine noch geplanten Funktionen ab.


    Parallel kann ich mich ja schon mal mit einer über das Web (WiC64) ladbaren Version beschäftigen.

    Das Coden müsstet ihr aber alleine übernehmen, weil ich mich mit Web-Programmierung null auskenne.

    Da müsste sich mindestens noch ein erfahrener Assembler Programmierer finden, alleine traue ich mir die Erweiterung im GUI Quellcode nicht zu und würde auch sehr lange brauchen im Vergleich zu jemandem der viel in Assembler programmiert.


    Eine weiter Frage wäre, ob wir die GUI auch (z.B. in der jetzigen Version) im WiC64 Portal auch zum download bzw. Start der GUI aus dem WiC64 Menü den Usern anbieten dürften. Ich denke der eine oder andere Internationale User hat von GU64 ggf. noch nichts mitbekommen.


    Dann noch viel Spaß im Urlaub :-)

    Muss die Entwicklungsumgebung auf dem C64 laufen? Ansonsten z.B. https://xc-basic.net/

    Kann ich nur Empfehlen. Ist wie Basic v2 mit vielen Erweiterungen und ist auch anschließend super schnell.


    Ich habe es schon für viele Programme genutzt (auch die Highscore APP im WiC64 ist mit XC-Basic programmiert) und es gibt eine Library mit der es ziemlich einfach ist "Internetfähige" Programme für das WiC64 Modul (welches auch im Vice emuliert werden kann) zu schreiben.

    Anbei die Kombination aus "WiC64 load-and-run example":

    Hallo 5ace ,


    erstmal vielen Dank für deinen Einsatz und die Erstellung eines Programms als Vorlage zum direkten aufrufen der GUI von einem Webserver. Ich hätte das ganze jetzt in XC-Basic umgesetzt, da ich leider nicht sehr sattelfest in Assembler bin. Aber das wäre dann auch von der Übertragungsgeschwindigkeit ggf. ein bis zwei Sekunden langsamer als die reine Assembler Variante. Ich werde versuchen das als Basis zu nehmen und vielleicht komme ich dann auch ein bisschen Übung besser mit Assembler zurecht.


    In die Diskussion möchte ich mich nicht einmischen, sondern nur loswerden, dass ich nicht der Meinung bin, dass ein geändertes GUI64-Programm das "Next-Level-OS" für den C64 sein wird

    Welche existierende Grundlage würdest du denn als Basis in Betracht ziehen? ggf. gibt es ja noch eine andere GUI die als Basis genutzt werden könnte und nicht viele kennen bzw. hier noch nicht genannt wurde?


    Es fehlt also noch jemadn, der das GUI64 anpasst.

    Ja, wenn die GUI als Basis dienen sollte dann auf jeden Fall. Ich hatte mit WebFritzi auch schon mal per PN Kontakt. Ich vermute aber das er kein Interesse/Zeit hat an einer Erweiterung um eine Webfunktionalität - hoffe aber das er nicht gegen ein solches Projekt wäre, wenn sich jemand findet der die GUI an der Stelle erweitern würde. Wenn dem so sein sollte, bitte kurz bescheid geben, dann akzeptiere ich das natürlich und würde das mit der vom Server aufrufbaren Variante auch sofort einstellen.


    Und noch ein Wort zu meinem Beitrag oben mit dem Python-Skript. Ich bin mir sicher, dass man es mit einwenig Aufwand soweit ändern könnte, dass es wirklich brauchbar/nutzbar wäre.

    Ich hatte Idee einen Windows Rechner fern zu steuern unter der Rubrick "ist ne coole Sache und machbar" wie du ja direkt eindrucksvoll innerhalb eines Tages bewiesen hast, bei mir einsortiert. Ähnlich wie Google Maps - welches super cool ist, aber im Prinzip keinen praktischen nutzen hat. Ich glaube niemand schnallt sich einen C64 auf den Beifahrersitz seines Autos und macht damit die Navigation :-) Obwohl .... halt mal mein Bier.

    Die Idee gefällt mir sehr, weil logisch nachvollziehbar und zukunftsträchtig!

    Vielen dank für die Unterstützung in dieser Sache. Ich glaube auch, das das für viele Nutzer ein Vorteil in der Bedienung darstellen würde und man auch zeigen könnte, was alles mit Hilfe der schnellen Datenübertragung und der Vernetzbarkeit möglich ist.


    Hättest du einen Tipp für mich, wer ggf. das Know how hat in assembler GUI64 zu erweitern?

    Im ersten Schritt würde es ja ausreichen ein weiteres Laufwerk zu erstellen, in das man dann die Links zu Ressourcen im Internet ablegen, und per Liste im Fenster auswählen kann.


    Serverseitig könnte ich das Backend zumindest für ein PoC (proove of concept) beisteuern und ggf. das initiale Loaderprogramm schreiben, welches die Gui beim Start in den Speicher pumpt - wenn die Gui nichts von Diskette nachläd, wäre das theoretisch jetzt schon möglich eine Onlineversion die immer auf dem neuesten Stand ist zu realisieren.

    Hier würde ich für die Netzwerkkommunikation das WiC64 als Basis nehmen, weil es im Vice emuliert werden kann und somit auch jemand ohne Modul die Möglichkeit zu testen hat. Obwohl das Modul ansich auch sehr gut verbreitet ist.


    Je nach Interesse durch die Nutzer könnte man das ganze dann Erweitern.

    WENN man heutzutage eine grafische Benutzeroberfläche für den C64 konzipiert, Online-Features integriert werden sollten - und bei entsprechender Geschwindigkeit kann das natürlich auch für die Funktionalität der Benutzeroberfläche genutzt werden (z.B. Speicherauslagerung).

    Natürlich kann das jeder so machen wie er will, aber da es sich bei C64OS z.B. nicht nur um eine GUI für Filehandling sondern um ein eigenes Betriebssystem handelt, hätte ich doch schon gedacht das hier zumindest eine Berücksichtigung der Möglichkeiten das Internet zu nutzen am C64 eingebaut wird - in diesem Punkt gebe ich dir vollkommen recht.

    Hallo Snoopy,


    du kannst die Lib gerne verwenden. Ich habe aber witziger weise eben erst gesehen, das Goodwell da wohl noch eine Verbesserung bei der URL Übergabe gemacht hat.


    Die sollte man noch mit einbauen, denke ich - kannst du das bei deinen Tests mit einbauen?

    Dann würde ich die auch auf Github aktualisieren.

    Deswegen war es von Anfang an auf Modularität (Nachladen von Komponenten) und eine zwingend vorhandene Speichererweiterung ausgelegt. In Kombination mit dem WiC64 hätte dieses die Speichererweiterung ersetzen sollen. Dass man bei einem Datei-Browser möglichst viel Speicher für das Directory frei haben möchte, versteht sich von selbst. Mit einer Speichererweiterung (die auch das WiC64 bei geschickter Nutzung darstellen kann) könnte man Verzeichnisse im erweiterten (Server/Cloud-) Speicher cachen und notfalls häppchenweise bearbeiten.

    Gibt es denn eine Demo von dieser grafischen Benutzeroberfläche? Das würde mich schon interessieren, wie das aussieht wenn das nicht Textbasiert ist.

    Ein grafisches OS, welches von den speziellen Möglichkeiten des WiC64 gebrauch macht und übers WLAN geladen wird (entweder aus dem Internet oder von einem lokalen Fileserver), hatte ich ja schon hier mal grob umrissen und mit anderen diskutiert. Die Grundidee finde ich also durchaus attraktiv.

    Gerade mal deinen Link angesehen - also das ist ja wirklich genau das was ich mir vorgestellt habe... Hatte den Eintrag aber garnicht gesehen bis dato.... Also Liegt das Copyright für die Sache bei dir! :-)

    Wenn sich WebFritzi an die Kernal-Sprungtabelle gehalten hat, dann könnte man das LOAD auch zentral anpassen.

    Ich denke man könnte im Prinzip alle vorhandenen Funktionalitäten weiterhin nutzen und nur eine weitere, die Internetfunktionalität, einbauen. Wie man das auch immer designen würde. Mir würde da ein weiteres Laufwerk vorschweben, welches dann wenn man es öffnet die Internetressourcen anzeigt ähnlich wie die Files auf den Laufwerken angezeigt werden. Hier kann man dann Links zu Programmen im Internet hinterlegen die sich durch Doppelklick starten lassen oder ein "Homelaufwerk" öffen, auf das man Dinge ablegen kann. Nach dem Ordner und Unterordner Prinzip könnte man dort navigieren.



    Aber auch wenn ich die hier von LazyJones angesprochene Kombi-Lösung nicht so "sexy" finde, so hätte ich natürlich nichts dagegen, wenn sie angeboten wird – solange sie optional bleibt und man die bisherigen Lösungen weiternutzen kann. Sicherlich gibt es Fans der Idee und ich bin für Vielfalt bei den Lösungen.

    Bitte nicht falsch verstehen, die Idee soll keinesfalls das WiC64 Portal ablösen und ist komplett losgelöst vom WiC64 Projekt. Mir schwebt da eine im Prinzip Hardware unabhängige Lösung vor. Mit welchem Protokoll die Daten letztendlich übertragen werden, sollte keine Rolle spielen. Auch soll dieser Thread dazu nur dienen um herauszufinden ob es für ein solches Projekt überhaupt Interessenten geben würde.

    OK, Sekundenschnell geht ja jetzt auch schon, wenn man das GUI64-PRG in ein CRT schiebt... das soll ja wohl am Ende auch das Ziel sein. Die aktuellen Testbuilds muss man halt noch manuell laden. Test-CRTs hatte ich aber schon selbst zusammengestellt und das geht wirklich schnell...

    Vorteil wenn's vom Server kommt, man hat immer die aktuellste Version - und dank online zugriff ggf. direkt neue Applikationen.



    Das klingt nach sehr viel Hintergrundwissen und jahrelange Erfahrung, da hast du meinen vollen Respekt!


    Geos war auch nur ein Beispiel um klarzumachen, das man auch eine andere GUI als Basis nehmen könnte. Da gab es z.B. auch schon was vielversprechendes aus Norwegen - aber das ist leider vor der Veröffentlichen eingefroren.


    TEOS - Commodore 64 multitasking char mode OS - Status #7


    Ich denke das GUI durch die bestehenden Funktionalitäten und die Fähigkeit Fenster und Userdialog darstellen zu können, sich wirklich gut als Basis für sowas eignen würde.