Posts by Spockie

  • Screenshots zu GeoDOS Desktop v3

    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.

  • Screenshots zu GeoDOS Desktop v3

    Quote from darkvision

    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.

  • Screenshots zu GeoDOS Desktop v3

    Quote from darkvision

    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!


    Quote from darkvision

    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!

  • Screenshots zu GeoDOS Desktop v3

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

  • Bedarfsabfrage für ein deutschsprachiges Handbuch für den MEGA65 (mit Umfrage)

    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

  • The default speed of the Mega65

    Quote from rosettif

    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.

  • The default speed of the Mega65

    Quote from ZeHa

    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:

  • The default speed of the Mega65

    Quote from ZeHa

    Not far fetched? Well you have to take into account the speed of technical progress here. The mid 90s already had Doom (1993) and Quake (1996). But the C65 was designed in the late 80s. The Super NES came out around 1991 and had a 3.5 MHz 16 bit CPU.

    As you know the C65 was not finished in den late 80s. It was abadonend. Had Commodore finished it it would have probably been delayed to the early 90s to sort out the hardware and software issues. And then we are not that far away from the 20 MHz SuperCPU. That's what I meant.


    I get that you want as close an experience to the C65 as possible. My point is that Commodore hadn't finished the design yet and that you are talking about mimicking a machine which flaws hadn't been addressed so far.

  • The default speed of the Mega65

    The default speed is the one of the Mega65, 40 MHz. Why should it be different? As Snoopy stated: The 40 MHz has been decided long time ago. The Mega65 has a VIC-IV and 40 MHz. That's a fact. Why should it default to something less?


    So: It is a Mega65. That's why it should start in Mega65 mode (40 MHz, VIC-IV). Not in C64 mode (1 MHz, VIC-II). Not in C65 mode (3.5 MHz, VIC-III).

    Quote from Snoopy

    As deft as one of the devolpers of the MEGA65 wrote in the quote above, the 3.5 Mhz in the MEGA65 are "useless". They are too slow for the features of the C65 and especially of the MEGA65. So there is no reason to have the 3.5 MHz at all. They are still there because of using the old original C65 ROMs, but even there the 3.5 Mhz are too slow for using all C65 features.

    That's the other thing I am talking about. 3.5 MHz is too slow to use all the features the C65 actually had. Early reviewers of the prototypes complained about it. This machine should have offered a few nice things, but couldn't show them off, since of this shortcoming. This is why the Mega65 team "finished" this development and found a solution.


    I am sure even Commodore knew of this problem and if they hadn't abandoned the project I am conviced they would have addressed this issues one way or another. Most likely not with 40 MHz, but probably some other way. Maybe with a higher clockrate in combination with a coprocessor.


    The Mega65 team has thankfully addressed it with their own take on it and we should be glad and use this computer as it was designed to. From the default state.


    40 MHz would have been quite much in the early 90s. I know. But as stated several times before, this is NOT a C65. It is the Mega65. And the 40 MHz is the native speed it was build for.


    Those of you who are pleading for 3.5 MHz as default are suggesting to slow this computer down to some unfinished prototypes which had severe and then unaddressed issues showing off the actually built in features.


    And you can see it from this side as well: The CMD SuperCPU ran at 20 MHz with a 16 Bit CPU and up to 16 MB of RAM. It was introduced in the mid 90s. So 40 MHz are not that far fetched.

  • The default speed of the Mega65

    The Commodore 64 runs at 1 MHz.

    The Commodore 65 runs at... wait. The C65 runs at nothing, because it doesn't exist as a product. There are several unfinished prototypes and those had a clockspeed of 3.5 MHz. But those also had an unfinished BASIC and a 50 pin expansion port (not compatible to the C64 cartridges). That's not the Mega65.


    The Mega65 incorporates the 1 MHz of the C64, the 3.5 MHz of the unfinished C65 and it's own 40 MHz and VIC-IV.


    So why should it default to 3.5 MHz? It isn't a C65, it is a "finished C65", it is a Mega65.


    Let's face it: The Mega65 even with 40 MHz is heavily constrained compared to todays standards. So it is still a challenge to code, paint and compose on it. And that's a good thing. That's what we want.


    But there is simply no reason to default it to 3.5 MHz since there isn't even (real) software out there which requires the lower clockspeed. As most people said before: This computer is NOT a C65, it is the Mega65. Which of course is inspired by the C65, but which is also a finished version minus all the wrong choices Commodore made for its prototypes (like the wrong expansion port). The faster clock speed is necessary because the suggested 3.5 MHz of the C65 prototypes would have underpowered the machine considerably.

  • Erste Apple Macs mit ARM-Prozessoren

    Ich habe jetzt seit fast 2 Wochen ein MacBook Pro 16" mit M1 Max und 64 GB. Das Gerät hat meine Erwartungen übertroffen. Ich arbeite ja beim Fernsehen, habe also viel mit Videoschnitt (Final Cut) zu tun und dafür ist das Gerät fantastisch.


    Mir ist jetzt mehrmals passiert, dass ich gedacht habe, der Computer hat etwas nicht gemacht. Und bei genauerem Hinschauen habe ich gesehen, dass er schon fertig ist. So schnell ist das Ding. Zum Beispiel beim Importieren und Reencoden des Videomaterials. Oder beim Rausspielen im Schnittcodec oder im Transcodieren nach H.264 ist der M1 Max im MacBook Pro so schnell fertig, dass ich denke, er hat jetzt nicht den Codec umgewandelt, oder er hat nur einen Clip und nicht das ganze Video rausgespielt.


    An einem anderen Tag habe ich mit Grafikprogrammen rumgetan und ein Buch layoutet. Irgendwann habe ich mir das Notebook auf den Schoß genommen und habe einen Schreck bekommen. Einen Kälteschreck. Das Ding war kalt und hat sich auch so angefühlt (weil Metall und ich in Shorts). Das ist wirklich ungewohnt. Normalerweise sind Notebooks schön warm, wenn nicht heiß. ;)


    Kurz zusammengefasst: Neben den üblichen Dingen wie dem tollen Screen und der ausgezeichneten Tastatur ist das Notebook einfach nur schnell und kühl. Den Lüfter habe ich bislang noch nicht gehört. Und der Akku hält dementsprechend auch lange.

  • Neues OS/GUI für den C64

    Frage in die Runde: Kann WiC64 auch mit eingeschalteten Bildschirm laden? Oder wird der Screen immer abgedreht bzw. Rasterzeilen gezeigt? Wenn der Bildschirm theoretisch anbleiben kann, dann wäre es wie Retrofan schon geschrieben hat, möglich, dass wir blitzschnell jene Speicherteile nachladen, die wir gerade brauchen und damit sind wir nicht mehr wirklich von den 64K limitiert. Oder den langsamen Ladegeschwindigkeiten.

  • Neues OS/GUI für den C64

    Ich finde den Ansatz sehr interessant. Wir haben tatsächlich mit dem WiC64 vielleicht die meisten der grundlegenden Probleme (siehe die letzten 37 Seiten) für ein neues OS am C64 gelöst. Speicher ohne Ende, fantastische Ladezeiten und damit ganz neue Möglichkeiten. Und nebenbei haben wir eine Internetverbindung. Damit machen die Mockups von Retrofan mit Kalender und RSS Feeds auf einmal so richtig Sinn.

  • Bedarfsabfrage für ein deutschsprachiges Handbuch für den MEGA65 (mit Umfrage)

    Quote from Ticker
    Quote from Snoopy
    Quote from ZeHa

    Tja, das ist jetzt halt die Frage, ob man ein Exemplar des am laengsten erwartetsten Computers gekauft hat, oder ob man sich einen von mehreren moeglichen lang ersehnten Computern gekauft hat ;)

    Andere Computer erwarten? Hallo! :bgdev


    1. Gebot: "Ich bin der MEGA65. Du sollst keine anderen Computer neben mir haben." ;)

    außer vielleicht seine beiden Ahnen. :love::saint:

    Die heilige Dreifaltigkeit sozusagen. Mega65, Commodore 64 und Commodore 128. :emojiSmiley-56: