Hast du dir schon mal diese Ansätze angeschaut? Was davon käme deinen Vorstellungen am nächsten?
Auf den ersten Blick sind GeckOS und LUnix was das ganz grundlegende angeht ziemlich genau das, was ich mir vorstelle
Mehr Infos zu GeckOS: https://www.lyonlabs.org/commodore/GeckOS/
Wieso ist der Softwarenachschub für den C 64 irgendwann versiegt? Hätte er ohne Schwarzkopien kommerziell länger gelebt? Oder lag es einfach an dem technischen Zahn der Zeit?
Bei Software ist es ja auch schon oft, dass man sie nicht mehr kaufen kann, sondern nur noch (im Abo) mieten.
Das Elend fing schon damit an, dass Software aktiviert werden musste. (Windows XP, PC-Spiele, DAWs...) Deshalb kaufe ich solche Software nicht mehr zum Vollpreis.
Formatierungen sollten möglichst einfach und portabel möglich sein – da bietet sich vor allem Markdown an.
Aber schon mit WYSIWYG, schätze ich mal. Welche Formatierungen sollten denn möglich sein? Das ursprüngliche Markdown (https://daringfireball.net/projects/markdown/) zum Beispiel kennt keine Tabellen.
Für welchen Einsatzzweck ist die Sprache gut geeignet? Es gibt ja, soviel ich weiß, auf dem C64 ein Weltraumstrategiespiel, dessen Namen ich immer vergesse, das angeblich in Forth programmiert ist. Aber das war wohl die Ausnahme.
Auch "Worms?" von EA wurde in Forth geschrieben: https://github.com/savetz/worms
Interview mit dem Entwickler: https://ataripodcast.libsyn.co…ard-electronic-arts-worms
der geplanten Abschaffung des Bargeldes
Wer plant das?
Man stelle sich andere Elemente in einer GUI vor, die ihre wahre Funktion erst bei MouseOver preisgeben. Warum macht man sowas?
Vermutlich dachte der Designer sich, dass das dann "sauberer" aussehen würde.
Der ewige Streit, ob "Form follows function" oder "Function follows form"? Bei Software-Ergonomie sollte das keine Frage sein.
Allerdings sollte man solche Sachen später natürlich nicht "zu Fuß" coden müssen, sondern es sollte einen Border- oder besser Window-Befehl geben
Ja, weil man mit Basic Boss keine Interruptroutinen erstellen kann.
Hattest du nicht mal einen Font für einen Programmeditor erstellt? War ein Mockup mit Syntax-Highllighting und Codeergänzung/Intellisense, glaube ich. Finde das auf die Schnelle leider nicht wieder.
Hat jemand dieses Heft und kann mir bitte die Seiten 19 & 20 einscannen? An weiteren Heften wäre ich auch interessiert...
Hier müssten sich alle Ausgaben befinden: https://commodore.bombjack.org…modore/your-commodore.htm
Retrofan müsste ein NaxOS-"Manifest" schreiben, wo in wenigen Worten mal die hier genannten Eckdaten zusammengefasst sind, und in seine Signatur packen.
Das kann ich mal machen, damit man nicht so oft alles wiederholen muss. Dann verweist man auf das Dokument und gut isses.
Existiert so ein Dokument schon?
Ich muss allerdings einschränken, dass evtl. nicht alles ad hoc verfügbar ist
Mach die keinen Stress deswegen. Ein paar "saubere" PNGs ohne PAL-Artefakte reichen fü den Anfang.
Apropos Text: Vorgesehen war/ist die standardmäßige Unterstützung von ISO-Encoding statt PETSCII. Dafür habe ich auch schon Fonts (auch wieder als PNG) vorbereitet. Ich weiß nur (noch) nicht, ob es genau die sind, die ich in den Mockups verwendet habe.
Ein visueller Prototyp hat ja wenig bis gar keine richtige Funktionalität. Ich denke fürs Erste reichen dafür auch vorgezeichnete Bildausschnitte. Fontdateien fürs Textrendering braucht man erst später.
Für das Pulldown-Menü und Dialoge wird der Hintergrund dynamisch gepuffert.
Sind Dialoge statisch oder vom Benutzer verschieb- und in der Größe veränderbar, nachdem sie schon angezeiogt wurden? Und ganz allgemein gefragt: Gibt es GUI-Elemente, deren Breite/Höhe keine Vielfache von 8 Pixel sind? Jetzt mal von (proportionalen) Fonts abgesehen, wo die Glyphenbreiten natürlich unterschiedlich sind. Aber auch die haben dann alle eine Höhe von 8*n Pixel, oder?
Der Text-Editor ist nichts, was man heutzutage umsetzen sollte.
Also ein Minimal-Editor/-Reader sollte schon drin sein.
In welchem Format liegen die Ressourcen vor?
Wie fast immer bei mir: als PNG (auf Wunsch mit indizierten Farben in C64-Reihenfolge).
PNGs mit fixer C 64 Palette müssten wohl reichen.
1:1 Screens ohne CRT-Simulation/Mauszeiger, sowie eine Übersicht über alle GUI-Elemente, gebe ich direkt an ogd,
Falls möglich, bitte die PNGs so:
* Allles Bilder ohne Rand, also max. 320x200 Pixel
* Backdrops, Hires- und Sprite-Layer von Hintergründen zusätzlich als separate PNGs
* Dialoge freigestellt/gecropt, sprich ohne Hintergrund und in richtiger Grösse herausgeschnitten
Wenn das zu aufwendig sein siollte, nehme ich aber auch ein PSD im möglichst altem CS2-Format und schau mal, wie weit ich damit komme 
Hallo, ich habe die ersten 6 Kapitel mit vFlat auf dem Handy erstellt.
Bitte weiterscannen, sieht gut aus.
Das fände ich geradezu wundervoll.
Dazu bräuchte man die Rohdaten. Retrofan: In welchem Format liegen die Ressourcen vor?
Ich habe die Scrollroutine um Finescrolling erweitert und kann das Posten, wenn gewünscht. Der nächste Schritt wäre dann rumfliegen mit verschiedenen Steuerungsarten auszuprobieren. Das wollte ich aber testweise nicht in Assembler machen, sondern in C, weil das für Wegwerfcode sonst zu aufwendig wäre. Komme aber nicht so richtig dazu.
Bin hier nicht jeden einzelnen Beitrag nochmal durchgegangen. Aber wurde schon mal ein (interaktiver) Prototyp zu Retrofans Mockups Neues OS/GUI für den C64 zusammen geklöppelt, um einfach mal das Look & Feel auszutesten?
Hallo, gibt es schon neuigkeiten zum Fortschritt des Scannprojekts?
*hochschieb*
Und daher frage ich mich ein wenig, wieviel RAM bei TeOS noch frei bleibt
Ich wage zu prophezeien: eher wenig...
Der kommt aber sehr schnell auf Augenhöhe mit Symbos.
TEOS wird wie Symbos wohl bald Speichererweiterungen unterstützen müssen, schätze ich mal.
geöffnete Border
So, der Rahmen ist offen.
