Posts by BlondMammuth

    Ich habe Python ausprobiert, und es ist in der Tat eine interessante und nützliche Sprache. Witzigerweise komme ich dann aber psychologisch in der heutigen Welt an, in der ich gleich die Auswahl aus x Sprachen habe, und dann zieht es mich gleich nach Prolog etc. Es ist nicht mehr dasselbe, obwohl ich zugeben muss, dass in der heutigen Welt von der Rolle her Python ziemlich sicher dem damaligen BASIC ähnlich ist. Und ja, mich überfordert diese Fülle an "was man tun muss um drauflosprogrammieren zu können" auch etwas, obwohl ich kein Anfänger bin. Aber ich tu mir schwer damit, mir solche Details zu merken. Ich muss mich jedesmal neu einschulen. :LOL

    Läuft das auch auf dem Pi4B? So einen hätt ich nämlich zufällig untätig herumstehen. Oder geht das nur auf dem Pi400?

    Ja, läuft auf jedem Raspberry Pi seit der ersten Version. Die sind auch sehr intensi in Kontakt mit der Rasberry Pi Foundation damit das OS ab dem Release einer neuen Hardware gleich direkt darauf läuft.

    Danke!!!

    Dann probier ich das echt einmal aus. :-D

    Dazu fallen mir spontan der Mega65 ein, und der Color Maximite 2.


    Ich finde das auch gut was du beschreibst. Eine Frage, die mich schon länger beschäftigt: wieviel Power benötigt man wirklich?


    Ein Pi mit Commodore-Zuckerguss könnte schon genau die Lösung sein. Oder eben eins der eingangs genannten Geräte :-)

    Ich muss sagen, ich schwanke dann immer zwischen der Idee, eine Plattform auszuwählen (und ich hätte Vorliebe für ein RISC-V-System), oder es auf allen Plattformen zu implementieren. Dann wärs aber nicht binärkompatibel, oder man würde eine CPU emulieren. Dann wär wieder so eine Schicht drin. Hm. Vielleicht RISC-V und alle anderen emulieren ihn? Irgendsowas.


    Ganz faszinierend die Frage, wie man dann moderne Graphic-HW programmiert. Leicht ist das nicht. Man müsste wohl auch da wohlwollend unterstützen.

    Wahrscheinlich ist das, was ich hier jetzt schreibe, nicht grade passend in einem Forum über antike 8-Bitter.


    Ich liebe die Dinger. Wer hier nicht? Ich werde wieder jung, wenn ich in einem 64er blättere. Es versetzt mich in alte Zeiten. No Na. Deshalb sind wir ja alle da.


    Jetzt kriege ich diese wunderbare Diskussion rund um ein neues OS für den C64 mit. Ich lerne viel draus, und in manchen Aspekten würde ich mich gar nicht trauen, irgendwas hinzuschreiben, weil ich viel zu wenig Ahnung von der Technik habe, die da debattiert wird. Ich bin mehr so der abstrakte Typ, habs mehr mit Programmiersprachen und so Zeugs. Drum kann ich, was OS betrifft, bedingt was beitragen, was HW betrifft, gar nichts.


    Ich erinnere mich noch, wie ich mir in den 80ern, wohl wissend, dass die HW-Entwicklung exponentiell weiter geht, die Zukunft vorgestellt habe. Ich habe damals keine Ahnung von GUIs gehabt, von Menüs, von Fenstern, etc. Das ist erst mit der nächsten Generation richtig gekommen. Ich habe vor mir, seit sehr kurzem, einen Homecomputer gehabt, der genauso funktioniert hat wie jeder Computer der Konkurrenz und auch die großen Dinger im Fernsehen: Per Kommandozeile, und manche Programme haben dann halt den Bildschirm ganz gut benutzt. Aber das wars.


    Also hab ich mir unter der Zukunft ungefähr das vorgestellt: Hardware x-tausendmal so gut, also tausendmal so schnell, und nicht 38911 basic bytes free sondern

    63.99 basic gigabytes free oder so ähnlich, weil der Interpreter muss ja auch noch wo sitzen. Vielleicht mehr und bessere Basic-Befehle oder so.


    Ich brauche wohl nicht dazu sagen, dass ich auf diese Maschine mittlerweile 40 Jahre lang warte. :LOL Allerdings vermehren sich die Anzeichen: :Pi:. Obwohl .. :org:. Ja, ist es nicht, aber neu und mit exakt dem damaligen Feeling ausgestattet. Und was man nicht mehr sagen könnte: :teur:. Soweit halt meine Hirn:hand soweit.

    So ein richtiges Barebone-Gerät, mit einem Interpreter (oder Compiler, muss man sich überlegen) der direkt auf einem nano-OS auf der Maschine sitzt. Wär das nicht total geil? Man stelle sich vor, wie tief man DA reinprogrammieren könnte, was man damit alles aufführen könnte, bevor ernsthaft der Speicher zu knapp wird. :sabber:


    Und wäre das nicht die glatte Inversion des anderen Konzepts, nämlich eines OS so modern wie nur irgendwie möglich auf der alten Hardware?


    Ich finde beide Konzepte geil! :prost::ilikeit::applaus:

    Ich hab einen Raspi 4B mit 8GB Hauptspeicher zum Arbeits-PC umfunktioniert, unter Linux Mint, funktioniert hervorragend. Bloß muss man ihn kühlen, und zwar aktiv.

    Dein Konzept wäre dann schon die Super-Luxus-Variante meines Gedanken. :thumbup: So weit hätt ich es noch nicht bedacht gehabt. :D

    Ich überlege grade, ob dasselbe auch für Fragen der Speicheraufteilung, des Virtuellen Speichers, etc. gelten könnte. Kann man ein OS theoretisch so flexibel gestalten, dass es mit mehreren alternativen Hardware-Lösungen (einschließlich der klassischen) zurecht kommt?

    Sicherlich. Aber virtueller Speicher gehört bestimmt nicht dazu. :)

    Wieso? Wenn jemand mit einer MMU daherkommt, wäre auch das auf dem Tisch, oder nicht?

    Aber ja, häufig wärs nicht. :thumbsup:

    Ich habe noch einen allgemeinen Gedanken dazu, der einiges, wenn auch sicher nicht alles, entspannen könnte. Aber zumindest die GUI. Das sollte doch durch das entschieden werden, was man einen "Window Manager" nennt (was irreführend ist, man sollte es eher einen "GUI"-Manager nennen, weil es ja nicht zwangsläufig um Windows geht, wie bereits mehrfach hier gut argumentiert zu lesen). Es ist also für das OS, zumindest theoretisch, eigentlich völlig egal, wie die Oberfläche aussieht. In der Praxis wird das OS durch das UI natürlich massiv beeinflusst. Allerdings wäre es dann vernünftig, alle Faktoren zu isolieren, die genau das tun, ein entsprechendes Interface des OS bereitzustellen, und ansonsten das OS mit solchen Fragen, wie das UI im Detail aussieht, nicht weiter zu befassen. Das UI wäre austauschbar, solange es sich an bestimmte Vereinbarungen hält.


    Ich überlege grade, ob dasselbe auch für Fragen der Speicheraufteilung, des Virtuellen Speichers, etc. gelten könnte. Kann man ein OS theoretisch so flexibel gestalten, dass es mit mehreren alternativen Hardware-Lösungen (einschließlich der klassischen) zurecht kommt?

    Ich denke, das müsste die primäre Design-Direktive so eines OS sein: So viele Aspekte wie möglich aus ihm herauszulagern und es daher so unabhängig und flexibel wie möglich zu machen. Dafür die Spezifikation des/der Interface(s) zu entwickeln.

    Die weiteren Details könnte man dann in aller Ruhe unabhängig betrachten und vor allem mehrere Alternativen problemlos verwirklichen. Auch die Diskussion um die GUI könnte man teils durch mehrere funktionierende Implementierungen interessanter machen.

    Herrlich, danke für die Erläuterung! :thumbsup: Von so nahe am Geschehen Antwort zu kriegen hätt ich gar nicht erwartet. :thumbup:


    Den letzten Absatz verstehe ich nicht ganz. Ein Port des Compilers auf MS-DOS? Mir würds ja um die Codegeneriereung für 6510 gehen, nicht um den Compiler selbst? Oder was verstehe ich grade falsch?

    Das geht nicht? FPC kann wohl LLVM-IL generieren https://wiki.freepascal.org/LLVM , llvm-mos.org sollte das wiederum nach 6502-Maschinencode übersetzen können. Muss man halt schauen, wie das alles funktioniert und was mit den Runtime-Libs ist und so weiter.

    Ich bin dir grade echt dankbar, dass du mir die Möglichkeit beschreibst. Wär ja toll! Und was mit den Runtime-Libs ist .. äh .. ja, so tief bin ich in Free Pascal nicht drin, das jetzt beurteilen zu können.

    Ja, der Thread ist bereits ein wenig angegraut, aber er passt mir trotzdem, ihn zu kapern: Free Pascal ist eine grandiose Idee und ein tolles Projekt.

    Das Einzige, was fehlt, ist ein Backend für den 65xx und für den C64 sowieso. Und das hat mich vor ein paar Tagen echt erschüttert, denn das wär einmal ein wirklich geiler Cross-Compiler!

    Pipes sind etwas Tolles, aber nichts wozu ich zwingend Multitasking brauche. Output von Anwendung A zwischenspeichern, an Anwendung B als Input weiterreichen - das geht problemlos auch sequentiell.


    Ist aber ein guter Punkt, eine Batch-fähige Shell wäre natürlich etwas sehr feines.

    :thumbsup:

    Auch Cut+Paste braucht kein Multitasking, das macht sogar GEOS schon. Clip zwischenspeichern (aus Platzgründen auf dem Datenträger) und nach Start der nächsten Anwendung auf Wunsch wieder zurückholen.

    Stimmt, und nein, ich hab die darauf bezogen, dass grundsätzlich mehrere Tasks zugleich offen sein können, mit jeweils dem im Vordergrund laufend. Die müssen dazu nicht unbedingt reentrant zugleich laufen.

    Ja, so würde ich das auch lösen, wenn genug Hauptspeicher vorhanden ist. Aber jetzt überleg mal, wie viel Speicher dann nur für solche Puffer draufgeht - zwei Bildschirme (oder Fenster, die den Bildschirm ausfüllen), brauchen dann im Bitmap-Modus an die 16 KB Pufferspeicher - das ist ein Viertel des RAMs, nur um die Anzeige von zwei Anwendungen zu puffern.

    Das war ein Mißverständnis. Ich habe über LoRes-Fenster gesprochen, also über Puffer deutlich unter 1kb. Und soweit es um reine Text-Fenster geht, kann man so auch für HiRes billig puffern. Nur wirds ein wenig langsamer, weil diese Puffer dann jeweils in HiRes übersetzt werden müssen. Bloß für echte Graphik würden diese Puffer echt groß.

    Retrofan und ich sind uns ja selten einig, aber was Fenster angeht kann ich ihm nur zustimmen. Fenster machen auf einem C64 keinerlei Sinn, weil…
    …auf dem Schirm extrem wenig Platz vorhanden ist → Fensterrahmen fressen Platz, Fenster nebeneinander anordnen ist sowieso kein Anwendungsfall
    …der Code für die Fensterverwaltung wieder RAM frisst, das sowieso extrem knapp ist
    …Anwendungen immer nur ein Projekt im Speicher halten, nicht mehrere
    (…immer nur eine Anwendung gleichzeitig läuft)

    Jedes Android-Smartphone implementiert eine moderne Benutzeroberfläche ganz ohne Taskleiste und Fenster - sogar mit Multitasking. Es geht also, und es geht auch ergonomisch. Daran sollte man sich orientieren, wenn man eine GUI plant. "GUIs haben Fenster" war noch nie zwingend richtig, inzwischen starrt jeder von euch täglich zwei Stunden auf ein fensterloses Display ;)

    Gut, mit einem File Commander bräuchte man 2 nebeneinander. Oder meinst du nur Fenster mit Rahmen und Bedienelementen? Dann stimmts. Und ja, die Argumentation ist plausibel. Es wäre also eventuell gescheiter, zwischen Bildschirmen umzuschalten, oder sie maximal vertikal anzuordnen. Es ist ein wenig schade - ja, weil ich mich von einer alten Idee verabschieden muss. :LOL

    Nenne doch erst mal einen Einsatzzweck für Multitasking, das hat bisher immer noch niemand gemacht, meine ich? Du hast 40 KB freien Hauptspeicher, einen Massenspeicher auf den immer nur ein Programm gleichzeitig zugreifen kann, eine CPU mit 1 Mhz und (mindestens) ein Smartphone direkt neben dir liegen - welche zwei Anwendungen würdest du in dem Szenario gleichzeitig auf dem C64 laufen lassen?

    Ja schon. Z.B. wenn man UNIX-ähnliche Pipes hat, dann sind die nur sinnvoll, wenn mehrere laufende Tasks durch sie verbunden sind. Das können ja auch mehrere Threads in einem Programm sein. Ist z.B. eine VM im Einsatz die dichten Code erlaubt (langsamer aber auch kürzer als Assembler, z.B. FORTH), dann ist es denkbar, mehrere sinnvolle Programme laufen zu lassen. Allerdings kann man da natürlich auch argumentieren, dass es ausreicht, wenn nur ein Programm im Vordergrund läuft. Dann gibt es aber noch mehr Gründe. C&P zwischen verschiedenen Programmen z.B.

    Die UI-Elemente sind noch nicht mal das Problem: die könnte das System ja theoretisch selbst neu zeichnen - was allerdings wieder einen (kleineren) Cache pro Anwendung voraussetzt. Der sonstige Fensterinhalt - also die Grafik, der Text oder der Song der in der jeweiligen Anwendung gerade geladen ist - sind der Knackpunkt: Diesen Fensterinhalt muss die Anwendung selbst neu zeichnen. Das können wir ihr aber nur (mit vertretbarem Aufwand) mitteilen, wenn sie gerade untätig ist und auf Benutzereingaben wartet.

    Ich habe die Idee gehabt - und wie weit die gut ist, lässt sich sicher ausdiskutieren - dass jedes Fenster seinen eigenen Buffer enthält, der zwischengespeichert wird, solange die Fenstergröße sich nicht ändert. Dann wäre es reines schnelles Kopieren des gesamten Fensters aus dem Buffer auf den Bildschirm, und darum bräuchte sich ein Programm überhaupt nicht kümmern. Natürlich, bei Veränderung der Fenstergeometrie müsste das Programm neu zeichnen.

    Was HiRes betrifft: Vielleicht könnte man das den Programmen freistellen, die halt den entsprechenden Buffer-Speicher dann zur Verfügung stellen müssen (bzw. der würde den entsprechenden Tasks halt zugeordnet). Der ist dann im Hi-Res-Mode entsprechend umfangreicher als der LoRes Buffer-Speicher.

    Wobei ich mir irgendwie denke: Bei dem Speicher ist es vielleicht sowieso gescheiter, bei HiRes-Programmen auf Multitasking zu verzichten. Wäre das ein Kompromiss, HiRes optional ohne Multitasking und reine ASCII-Graphik mit? Oder vielleicht wäre das gar nicht notwendig, sondern würde sich als Erfahrungswert für die User eh auch so ergeben.

    Ja, noch was: Die grundsätzlichen Routinen für Textmanipulation könnten eigentlich sowieso den Graphik-Modus verstecken. Mit anderen Worten: Ein Programm, das nur Text ausgibt, bräuchte gar nicht wissen, in welchem Modus es das grade tut. Bloß wenn es Graphik-Befehle ausführen will, kriegt es im ASCII-Modus eine Fehlermeldung zurück. Also kann es den Modus abfragen, wenn es will, und ihn verlangen, wenn es will. Braucht aber nicht. Kanns auch drauf ankommen lassen, ob der Modus grade passt. Das Dumme dabei: Wenn ein Programm HiRes-Modus braucht, brauchen es alle, auch wenn es nur Text-Applikationen sind, und dann wirds sehr zäh.

    Auch da könnte man sich überlegen, Buffer im Text-Modus zuzulassen, die dann automatisch in HiRes übersetzt werden, wenn Programme nur Textfenster brauchen. Das würde massenhaft Buffer-Speicher sparen helfen, aber dafür auch ganz schön bremsen, weil das Zeichnen umständlicher und langsamer wird.

    OK .. ich glaube, jetzt fällt mir nichts mehr ein. :-D

    Mir scheint die Entscheidung über notwendige UI-Elemente (und auch andere OS-Funktionen) meisten recht wenig reflektiert – man baut einfach nach, was es "immer schon" gab.

    Vielen Dank für die Klarstellungen! Jetzt begreife ich schon besser.

    Wobei du recht hast: Ich scheine da auch sehr phantasielos zu sein. Ich will dich nicht dazu drängen, es neu zu verfassen: Hast du einen Link auf deine Kritik dran? Weil ich mir grade eher wenig drunter vorstellen kann, allerdings entnehme ich deinen enthusiastischen Worten schon, dass du dir seit Längerem was dabei gedacht hast.

    Nachtrag: C64-OS angeschaut, tatsächlich bemerkenswert. Danke für den Einwurf!

    Stimmt, so weit habe ich das noch nicht bedacht gehabt. Ich meinte eher das Grundsätzliche. Dass es funktioniert. Optisch ist es mir eher nicht so wichtig (da unterscheiden wir uns sicher, kann ich mir vorstellen :D). Allerdings, bez. Win95: Wenns ein Menü gibt, eine Taskleiste und Fenster, scheint mir das für 8 bit ausreichend komplex. Wie sonst sollts beschaffen sein? Oder meintest du wieder mehr die Optik als die Funktionalität? Und C64-OS muss ich mir überhaupt erst einmal ansehen, um mitreden zu können. ;-)