Posts by Spockie

    Sollte es die wirklich gegeben haben, dann wird sich so gut wie nie einer daran gehalten haben: Spätestens als mit TopDesk die Farbe in GEOS eingezogen ist, wären diese Design-Richtlinien ad acta geworden. :-)

    Ich würde es gar nicht an TopDesk aufhängen. Der orientiert sich eh sehr an GEOS. Stichwort Menüzeile, Position der Laufwerksicons, Papierkorb. Ich denke eher an die vielen, vielen GEOS-Apps von Dritten, die sich an gar keine Designvorgabe halten. Das beginnt eigentlich schon mit der GEOS eigenen App "Konfigurieren". Vom Design her eine absolute Katastrophe. Hält sich an nichts, was der Desktop eigentlich verspricht. Und viele kleine Apps von Dritten sind in diesem Sinne entworfen und umgesetzt worden. Es scheint keine einheitliche Designrichtlinie gegeben zu haben.

    Etwas unfair... aber ich hab Wheels mal wieder begutachtet ;)

    Klar, da wurde nicht mehr weitergearbeitet, aber schon damals hätte mir die UI nicht gefallen. Wirkt etwas altbacken... Fast so wie GEOS 2.x ;)

    Ich war ja damals neutral und habe für die GO64! beide Projekte vorgestellt. Und Maurice Randall versteht von Grafik wirklich nicht viel, da hast du schon recht. Nur in einem ist sein Ansatz mehr "GEOS-like" als MP3: GEOS ist von der Art und Weise wie es funktioniert eher wie ein Mac ausgelegt und weniger wie Windows. Das sieht man zum Beispiel an der zentralen Menüleiste oben, die Macs heute immer noch haben. Das sieht man an der vermeintlichen Fensterzeile oben (GEOS ist ja kein windowing System, aber hat den Filenamen ähnlich umrandet). Oder wie nah geoPaint eigentlich MacPaint nachempfunden wurde. Das zentrale Apple-Menü wurde zum "geos"-Menü und die Laufwerke sind im Desktop rechts (bei Windows links), die Uhr rechts oben (Windows: rechts unten) und der Papierkorb ist bei GEOS rechts unten (Windows: links oben).


    geoPaint.jpg


    Insoferne ist Wheels vom Ansatz her vermutlich näher an einem leider niemals verwirklichten "GEOS 3.0" von Berkeley Softworks dran als es MP3 ist, das sich mehr an Windows orientiert. Aber man muss natürlich auch sagen, dass GEOS in sich designmäßig die Sache sehr locker gehandhabt hat. Mir scheint, dass es nie einheitliche GEOS-Richtlinien gegeben hat, wie man Apps designen soll.

    Ich weiß nicht, ob das hier relevant ist, aber ich habe einen SX-64. Versucht man die originale SuperCPU anzustecken, gibt es einen ungewöhnlich langen Weg, bis sie greift. Oft ist man zu weit hinten und die Platine kann nicht greifen (und man sieht es nicht, weil die Expansionport-Klappen des SX-64 im Weg sind). Es fehlt hier - wie bei einem herkömmlichlen Modul - das Plastikgehäuse rundherum, das beim Anstecken dafür sorgt, dass es gar nicht anders geht und die Kontakte der Platine sich leicht in den Expansionsport-Schlitz reindrücken lassen.


    Bei der SuperCPU am SX-64 ist das wie gesagt nicht ganz einfach und man muss etwas probieren. Findet man die Schnittstelle, dann funktioniert es auch. Das ist dann kein loser Kontakt, sondern die SuperCPU greift schon recht fest in den Expansionsport, wenn auch nicht ganz so tief und fix wie bei einem "normalen" C64.

    "Hintenrein" könnte man dann noch seine U2+ (usw...) stecken?

    Ja, genau. Das ist dann einfach der Expansionsport. Und bei Inkompatibilität des Moduls zur SuperCPU muss man diese nicht abstecken, sondern da reicht auch ausschalten (mit dem Schalter auf der SuperCPU).


    Die "Powerkonfiguration" ist natürlich SuperCPU und dahinter die RAMLink (an der dann parallel die CMD HD angeschlossen ist). Die RAMLink hat dann zwei weitere Ports, der hintere für eine allfällige REU und der vordere für alles andere, also zum Beispiel für eine Ultimate II+.

    Ach so, das wurde nie direkt in einer Verkaufversion angeboten, sondern war quasi immer frei erhältlich. Das wusste ich nicht. Dann ist es quasi schon immer ein reine Herzensangelegenheit gewesen für dich, dieses Tool.

    Naja, es war damals (zu Recht) das 64'er Programm des Monats. Dafür gab es natürlich Geld. Aber vertrieben wurde es davon abgesehen soweit ich weiß nie.


    Ich bin so froh, dass GoDot da nicht locker lässt und seit Jahrzehnten das Ding weiterentwickelt. Es wäre schön für die Community, würden das andere (z.B. die ehemaligen Leute von Berkeley Softworks mit GEOS) auch so handhaben.

    Na okay, dann hier mein Ergebnis, natürlich IFLI. Damit die bläuliche Hintergrundfärbung rüberkommt, musste ich hier schon mehr einsetzen, da ist ziemlich viel Dithering drin. Leider flimmert das Bild ein bisschen. Das Buch könnte brauner sein. :-(

    Ich finde, dass deine Konvertierung in diesem Fall die bessere ist. Sie trifft zum einen die Farbwelt besser und sie hat zwei Nachteile nicht:

    1. Im MUIFLI ist der mittlere Schmetterling im Lichstrahl unsichtbar, weil weiß auf weiß. In deiner Version sieht man den Schmetterling.

    2. Die Farbe im Gesicht des Mädchens reißen in der MUIFLI-Version auf, also tendieren (wie der Schmetterling) in Richtung weiß. Bei einer Fotografie würde man "überbelichtet" sagen. In der GoDot-Version passt das aber.


    Ich denke aber, dass das kein grundsätzliches Problem bei MUIFLI ist, sondern nur die eingegangenen Kompromisse.


    Bei dem vorigen Bild "Drowned Lullabies" finde ich die MUIFLI-Version sehr gelungen. Sie schafft vor allem etwas, woran das IFLI scheitert: Die Spiegelung des Helmglases darzustellen. Und die Farben sind da in der Tat sehr stimmig. Außerdem kann MUIFLI hier seinen Auflösungsvorteil vor allem beim sehr feingliedrigen Hintergrund ausspielen.


    Hoffentlich kann Roland wie beim NUFLI-Format dir wieder assistieren, damit du einen Loader für GoDot schreiben kannst. Wäre echt toll!

    Wie gesagt, wenn man den Fokus nicht auf die alten Apps legt, macht das schon Sinn. Weil es ja jetzt nicht anders ist. Wie du selber schreibst, gibt es viele Apps, die die aktuellen 4 Laufwerke nicht unterstützen. Darunter die GEOS-eigenen Apps wie geoWrite oder geoPaint, die extra dafür gepatcht werden müssen (und nicht jeder patcht sie). Andere Apps können überhaupt nur zwei Laufwerke. Auch wenn MP3 bzw. GD aktuell 4 unterstützen.


    Insoferne ändert sich nicht so viel, falls GD mehr Laufwerke unterstützen würde, weil es den Fokus auf Dateiverwaltung legt. Du verwendest 4 für GEOS und mehr als 4, wenn du GD als ultimative Dateiverwaltung einsetzt.


    Der zweite Punkt von dir ist auch einer, der mir am Herzen liegt. GEOS stammt aus einer Zeit, in der man von einem 1541-Laufwerk ausgegangen ist. Damals™ waren Unterverzeichnisse oder Partitionen egal. Weil ohnehin nicht von der 1541 unterstützt. Und weil bei den Dateigrößen sowieso nur eine Handvoll Sachen draufgepasst haben.


    Spätestens mit der 1581 war das ein Stück anders (auch wenn deren "Unterverzeichnisse" eher Partitionen waren). Spätestens mit den CMD-Geräten wäre dann eine Adaption notwendig gewesen, aber Berkeley Softworks war längst vom C64 abgewandert. Und seit damals™ leben wir mit dem Faktum, dass jedes Verzeichnis, jede Partition wie eine Disk behandelt wird. Und dass wir uns durch Unmengen von Konfigurationsdateien (meist geoWrite-Files), Treibern und Fonts durchwühlen müssen, um zu den Apps oder Dokumenten zu kommen, die wir eigentlich wollen.


    Meine Idee war, dass man damit zumindest halbwegs aufräumt, indem man zwei oder drei Standard-Unterverzeichnisse definiert. Zum Beispiel ein Verzeichnis für Fonts. Eines für Konfigurationsdateien. Eines für Treiber und den Desktop. Und dass man GEOS so patcht, dass es bevor die Meldung kommt "bitte Diskette mit ... einlegen", dass diese definierten 3 oder 4 Verzeichnisse durchsucht werden.


    Schöner wäre es natürlich wie bei einem modernen System, dass man frei mit Unterverzeichnissen arbeiten kann. Keine Frage.


    Wobei darkvision hat es schon anklingen lassen: Ihm geht es mehr um eine moderne grafische Dateiverwaltung als um ein runderneuertes GEOS. Und ich sehe die Priorität auch eher dort. Das was am C64 nämlich aktuell wirklich fehlt (und das, wo der PC oder Mac auch nicht einspringen kann) ist ein universelles Tool, mit dem man seine Disketten, seine Diskimages, seine Partitionen und Unterverzeichnissen auf all den verschiedenen Geräten (modern und alt) verwalten kann. Es gibt aktuell nämlich kein Programm, das das kann. Deshalb auch mein Plädoyer für eventuell mehr als 4 unterstützte Geräte. Weil das Programm damit noch ein Stück interessanter wird. Auch für Nicht-GEOS-Fans.

    Ja... Anwendungen würden mit mehr als vier Laufwerken eh nicht umgehen können. Wenn, dann müsste man das gezielt in die Anwendungen reinprogrammieren.

    Man stelle sich mal vor man startet GeoWrite von Laufwerk E: und das Dokument liegt auf Laufwerk F:. GeoWrite würde die Anwendung und das Dokument aber nur auf A: bis D: suchen und nichts finden und Ende...

    Auch in der Dateiauswahl steht ja nur A: bis D: zur Verfügung. Laufwerk E: bis Z: müsste man mit einem neuen Patch nachrüsten, was nicht so einfach sein dürfte wie damals beim 4-Laufwerke-Patch.

    Man müsste jede Anwendung anpassen die auch nur irgendwie auf die Laufwerksregister zugreift.

    Ist nachvollziehbar. Wenn man aber sagt, dass der Fokus dieses Projekts ohnehin nicht auf den alten Anwendungen liegt, sondern, wie du selbst schreibst, eine Oberfläche um Dateien zu verwalten, Images zu kopieren, etc., dann könnte man ja GD aufbohren, damit mehr Laufwerke unterstützt werden. Eben mit dem Kompromiss, dass die GEOS-Apps das nicht ohne Patch können. Ist ja derzeit auch so. Ein ungepatchtes geoWrite kann auch unter MP3 keine 4 Laufwerke.

    Wenn das dann abgeschlossen ist, dann soll es auch möglich sein im Partitions-/DiskImage-Modus auf "Alle anzeigen" zu wechseln. Dann zeigt der Browser alle Partitionen oder DiskImages an, nicht nur diejenigen die zum aktuellen Modus (41/71/81/NM) passen. Man wählt dann einfach das DiskImage oder die Partition aus und GeoDesk passt die Treiber dann entsprechend an.

    Das wäre ja genial. Genau so etwas wünsche ich mir schon seit Ewigkeiten!


    Mich reizt eher die Oberfläche um Dateien auszutauschen oder DiskImages zu kopieren. Man stelle sich nur mal vor GeoDesk verbindet sich über das WiC64 mit einem Server, lädt eine Datei im CVT-Format, konvertiert diese in das GEOS-Format (CVT-Konvertierung ist ja bereits eingebaut) und startet dann die Anwendung. Utopie... Keine Zeit dafür aber denkbar 8o

    Wow, das wäre es.


    Wenn du dich erinnerst, hatten wir vor einiger Zeit einen Thread namens "GEOS heute". Darin wurde darüber diskutiert, was man heute™ mit GEOS noch tun kann. Der Thread ist für 3 Jahre eingeschlafen gewesen und ich habe ihn vor genau einem Jahr mit einem Posting reaktiviert, der ziemlich in diese Richtung geht: Filebrowsing mit modularer Technik. Das suche ich schon lange am C64. Da gibt es bisher ja nur Insellösungen. Das eine mag mit dieser Hardware nicht, das andere nicht mit jener. GEOS stünde da in gewisser Weise etwas drüber. Und das wäre der Ansatz.


    Ich bin auf jeden Fall begeistert!

    Ich glaube darkvision meint GeoDOS, nicht geoDesk, oder Markus?

    Bin jetzt auch nicht der Hardware-Profil, aber der IEC-Bus ist der normale serielle Floppy-Bus. Es gibt ja auch das SD2IEC, wo man an genau diesem Bus ein SD-Karten-Laufwerk anschließt, deswegen auch der Name. Das IEC-Kabel ist damit einfach das serielle Floppy- und Druckerkabel.


    IEEE488 ist dagegen etwas anderes, eine parallele Schnittstelle. Der C64 kann das zum Beispiel über ein Modul:

    https://www.c64-wiki.de/wiki/Interpod


    So wurden andere Commodore-Floppys am C64 angeschlossen, beispielsweise die von mir damals bewunderte SFD1001.

    https://www.c64-wiki.de/wiki/SFD-1001


    IEEE488 ist also ein paralleler Standard, den der C64 über ein Modul beherrscht. Der IEC-Bus ist technisch eine von Commodore entwickelte Untervariante davon und wird auch "serieller Bus" genannt.

    https://www.c64-wiki.de/wiki/Serielle_Schnittstelle

    Please guys, but what are those C65 features for which you think the 3.5 MHz is not enough? That's already more than four times faster than the C64's. Whereas the typical screen resolution is only the double (640x200) and you even have a built-in DMA (which is a game-changer in itself).

    Bitplanes. The Amiga has it. But the Amiga has also Blitter and Copper. The C65 however is too slow to effectively use bitplanes. The Mega65 corrects that:


    Mega65 talk at YouTube (Bitplanes starts at 14:20)

    https://c65gs.blogspot.com/2015/10/ (look at the entry on Oct 16, 2015).

    The Mega65 team has stated several times, that the C65 was actually too slow to show off built in features. Their take on it was to increase the clockspeed, to "repair" this issue.


    We are talking about defaulting to the broken and unfinished state the C65 was in knowing that this is not the C65 but the Mega65 which was built with another clockspeed in mind.

    But yes I understand that the 3.5 MHz might have been underpowered for the C65. Maybe that's why they ditched the project in the end. However, since the C65 is considered to be a successor of the C64, I'd rather have it a bit more similar to the C64 indeed, as opposed to something that beats the Amiga.

    The C64 beats the Amiga hands down by definition anyway. :thumbsup: