Hello, Guest the thread was called57k times and contains 405 replays

last post from max2022 at the

originale GEOS-Applikationen jungfräulich

  • Bin wohl doch schon mal zu gekommen :-) Umso besser. Und es bleibt festzustellen, dass Irren menschlich ist.

  • hier nun "GeoFile" für Geos 64 (Kopie einer originalen MSPI-Diskette).


    Leider existiert kein "Deinstaller" für GeoFile 64.

    Wusstest Du, dass es von GeoFile mindestens noch eine zweite Variante gab / gibt? Nämlich eine, wo man GeoMerge nicht installieren muss?

  • Leider existiert kein "Deinstaller" für GeoFile 64.

    wweicht: Kann es sein, dass man nur die alte ID mit einem Diskeditor löschen/ändern muss, um sie neu installieren zu können.

    Hab da irgendwas im Hinterkopf, dass es bei einer App eigentlich so einfacht war, kann aber auch was anderes gewesen sein - bin leider zu lange raus aus dem Thema...

    ...muss mich irgendwan einmal wieder in GEOS einarbeiten, wenn ich mal meinen 128er wieder ans Laufen bekommen habe...


    ko.ma

  • Bei der Software nicht, beim Installieren schrottet die absichtlich den Kopierschutz. Und GeoMerge zu deinstallieren - ist möglich, aber ergeblich aufwendiger und nur per manuelle Arbeit hinzubekommen.


    Edit: Aber auch nicht notwendig - ich habe frisch ein Exemplar einer originalen jungfräulichen nie benutzten GeoFile bekommen - in der Variante, wo man GeoMerge nicht installieren muss.

  • dass es von GeoFile mindestens noch eine zweite Variante gab / gibt? Nämlich eine, wo man GeoMerge nicht installieren muss?

    Nein, bisher nicht. Die Variante würde ich gern mal sehen.


    GeoMerge nicht installieren müssen kenne ich nur vom Geos 64 - und Geos 128 - System. Das aber nur im deutschen Geos. Die Modifikation stammt von MSPI (also Deutschland), irgendwann in den 1990igern und wurde getätigt, weil es ein Installations-Problem mit irgendeinem 1541-Laufwerk gab.

    Die Version ist am etwas seltsamen Info-Text (Datei - Info) zu erkennen...


    Gruß

    Werner

  • Die Variante würde ich gern mal sehen.

    Hm, ich habe bereits zahlreiche Images angefertigt: Mit Zoomfloppy ein .nib, mit Kryoflux RAW-Streams sowie ein g64 mit zusätzlichen Mastering Information und mit GreaseWeazle ein .scp. Damit ist das seltene Exemplar bestmöglich gesichert.


    Scheint zu funktionieren, vor der Veröffentlichung will ich das Zurückschreiben aber noch genauer testen.


    Nachtrag: wweicht Schau mal, ob Dir an dem GeoFile etwas auffällt. Ja, es ist ein GeoFile von Markt & Technik.

  • Schau mal, ob Dir an dem GeoFile etwas auffällt.

    nicht wirklich.


    Das .nib nach .g64 gewandelt unter unter WinVice in MP3-64 installiert. Dabei unter MP3 vom Dezember 2021 Absturz während Installation, bei MP3 64 R10 (März 2022) Installation problemlos.

    Das geoMerge ist genau das, was schon auf den Geos-Systemdisketten irgendwann in den 1990ern aufgetaucht ist. Wußte bisher nur nicht, daß das auch bei geoFile geändert wurde. Theoretisch müßte ja dann auch geoFile 128 deutsch existieren, wo geoMerge nicht mehr installiert werden muß...


    Gruß

    Werner

  • Dafür ist mir was aufgefallen: Auf den Tracks 1 bis 17 sind außergewöhnlich viele Bits - also ungewöhnlich große Gaps. 7797 Bytes statt 7692 Bytes. Das könnte eine 1541 nur schreiben, wenn man die auf 295,959984 RPM runterregelt.

    Kopiert (Lesen + Schreiben, nicht nur auslesen) man die Disk mit einer 15xx Floppy, so hat die Kopie entsprechend weniger Bits auf den genannten Tracks, eben so viele, wie die Floppy. auf Speedzone 3 mit seiner RPM schreibt.


    Schaut man noch genauer hin (dafür bedarf es eines Dumps auf Fluxebene), so stellt man fest, dass die Zeit pro Bit nicht konstant ist (wie die es sein sollte) - einige Sektoren sind etwas schneller, andere dafür langsamer geschrieben. Aber alles innerhalb dessen, was die Floppy bei Speedzone 3 lesen kann.


    Alles für die Lauffähigkeit nicht relevant, wurde aber gemacht, um Kopierprogramme zu verwirren... bei zu vielen Bits pro Track muss gekürzt werden. Dabei geht aus Sicht der Kopierschutzentwickler hoffentlich was schief.



    Ansonsten funktioniert das GeoFile einfach so, wie es soll. :-)

  • Hallo,


    auch wenn es "erst" ;-) 3 Jahre her ist, hat das originale GEOS-Applikationen jungfräulich inzwischen mal jemand ausprobiert? Es geht hier um "FileBrowser" für Geos unter RamProzess. Es gab da ja leider bisher keine Rückmeldung. Aber ich behaupte, da ist bei der Erstellung (sorry, das war ich ;-) ) etwas schief gelaufen.


    Bevor ich mich erneut daran mache, warte ich mal auf Rückmeldungen ....


    Gruß

    Werner

  • Ich hab die beiden verlinkten DiskImages mal heruntergeladen. Laufwerk (unter VICE) ist eine 1541, REU ist eingestellt. DeskTop hab ich dualTop (weil DeskTop2 mit RAMProccess laut Anleitung einen Fehler hat).


    InstallFB hängt aber irgendwann bei Track36 fest (laut Anzeige VICE). Da wird wohl TurboDOS-Code aufgerufen und dann hängt die Kommunikation.


    Mach ich da noch was falsch? Ich hab ein "nacktes" GEOS 2.0 gestartet, Nur Laufwerk A: 1541 und B:RAM 71, von einer "Originalen" Systemdiskette (also keine Autostarts oder ähnliches vorhanden).


    Nach dem Start dualTop gestartet, dann die FileBrowse-Disk eingelegt, Doppelklick auf InstallFB... das Laufwerk "rattert", aber dann passiert nichts mehr. GeoWrite z.B. lässt sich installieren, also das VICE-Setup an sich scheint schon zu funktionieren.


    RAMProcess selbst konnte ich starten...

  • Hallo,


    zunächst: Danke.

    DeskTop hab ich dualTop (weil DeskTop2 mit RAMProccess laut Anleitung einen Fehler hat).

    ???

    Müßte eigentlich mit DESKTOP auch fiunktionieren.


    Ich weiß nicht, was mich vor über 3 Jahren geritten hat, das als D64 zur Verfügung zu stellen. Genau das scheint das Problem zu sein. Habe jetzt (nachdem ich die originale nicht installierte mir zugeschickte Disk wieder gefunden habe) die Disk als G64 vorliegen und am C128 (sowohl im C64-Modus mit Geos 64 also auch im C128-Mode mit Geos 128) mit den Boot-Disketten aus der Wolke neu probiert.

    Dazu die System- und Sicherheitssystem-Disk und die Disk Applikationen jeweils auf echte Disk geschrieben, das System von Disk installiert, dann FileBrowser installiert, dann RamProzess von der Filebrowser-Disk gestartet, FileBrowser gestartet und mit GeoPaint von der Applikationen-Disk herumgespielt. Neue Auswahl-Box funktioniert fehlerfrei, auch nach mehreren Versuchen. Der originale Geos-Desktop macht auch keine Probleme ;-) .

    Jetzt funktioniert hier bei mir zumindest alles mit der Disk.


    Hänge das neue G64 von FileBrowser hier mal mit an. Wichtiger Hinweis: Installation funktioniert nur auf einem als 1541 konfigurierten Laufwerk. Bei einer 1571 kommt eine Fehlermeldung.


    Auf der Wolke lassen ich das alte Archiv erst tauschen, wenn ich sicher bin, daß es wirklich funktioniert.


    Gruß

    Werner

  • ???

    Müßte eigentlich mit DESKTOP auch fiunktionieren.

    Quote

    Die hier vorhandene letzte je veröffentlichte Version des Programms RamProcess

    (V2.032) hat leider einen Fehler, der erst jetzt entdeckt wurde. Es funktioniert

    nicht, wenn der originale Geos V2.0 Desktop verwendet wird (System-Fehler beim Start

    von "RamProcess").

    Der Systemfehler passiert nicht beim Start, sondern bei der Rückkehr zum DeskTop... RAMProcess wird noch gestartet, aber dann...



    Wenn ich vor dem Start dualTop starte, dann klappt es. Dann starte ich noch den FBrowser und bekomme beim öffnen von geoWrite dann das hier...



    Scheint also zu funktionieren. Das D64 wollte partout nicht, mit dem G64 geht es jetzt.


    Wenn ich dualTop über "C=+X" in Richtung DeskTop2 beende kommt wieder der Absturz... also hat es nichts mit dem Start von RAMProcess zu tun.

  • Und wieder: Danke!!!!

    Der Systemfehler passiert nicht beim Start, sondern bei der Rückkehr zum DeskTop... RAMProcess wird noch gestartet, aber dann...

    Möglich, habe ich jetzt nicht ausprobiert. Muß aber nicht unbedingt am FileBrowser liegen. Verwende mal das RamProzess von der FileBrowser-Disk. Ja, ist älter aber hier funktioniert es. Rückkehr zum Desktop beim Schließen von GeoPaint (mein Testobjekt) mehrmals ohne Fehler probiert. Keine Abstürze .....

    Außerdem: Da ist doch noch etwas im Hintergrund aktiv. Siehe Bild 1. Das ist nicht original Geos ;-) .


    Scheint also zu funktionieren. Das D64 wollte partout nicht, mit dem G64 geht es jetzt.

    Hört sich ja schonmal gut an. Nochmal Danke.


    Gruß

    Werner


    PS: Wer lesen kann ist klar im Vorteil ;-) Sorry

  • Verwende mal das RamProzess von der FileBrowser-Disk. Ja, ist älter aber hier funktioniert es. Rückkehr zum Desktop beim Schließen von GeoPaint (mein Testobjekt) mehrmals ohne Fehler probiert. Keine Abstürze .....

    Damit geht es auch mit DeskTop2... :thumbup:


    ich hab zwischenzeitlich etwas weiter getestet... mit der neueren RP-Version.


    Also DeskTop2 wird gestartet, es wird auch bereits das Menü aufgebaut... ab $5204 folgen dann drei JSR-Aufrufe, der Breakpoint danach wird in VICE nicht mehr erreicht. Da kommt dann der Systemfehler.


    Ich hab ja meinen DeskTop2-SourceCode... mal sehn ob ich das weiter einkreisen kann...


    Ha...! :)

    Das Problem hatte ich vor kurzem in MegaPatch mit dem ollen DeskTop2 auch.


    Der DeskTop2 versucht irgendwann das Laufwerk C: anzusprechen und zwar über SetDevice. SetDevice lädt dann den Treiber aus dem RAM, und wenn es den nicht gibt geht es schief. Wenn das Laufwerk C: nicht installiert ist, dann stürzt DeskTop2 ab weil dann irgendwann als Laufwerkstreiber bei $9000 landet.



    Richtet man ein Laufwerk C: ein (z.B. RAM41), dann funktioniert auch die neue Version. Die funktioniert auch nur mit einem 1541-Laufwerk.

  • Der DeskTop2 versucht irgendwann das Laufwerk C: anzusprechen und zwar über SetDevice. SetDevice lädt dann den Treiber aus dem RAM, und wenn es den nicht gibt geht es schief. Wenn das Laufwerk C: nicht installiert ist, dann stürzt DeskTop2 ab weil dann irgendwann als Laufwerkstreiber bei $9000 landet.

    Klingt für mich etwas seltsam ;-) .


    Dann müsste doch DeskTop immer abstürzen und nicht nur bei diesem RamProzess..... Oder anders: Warum klappt es mit dem neuen RamProzess nicht aber mit der älteren Version schon?


    Gruß

    Werner

  • Klingt für mich etwas seltsam ;-) .


    Dann müsste doch DeskTop immer abstürzen und nicht nur bei diesem RamProzess..... Oder anders: Warum klappt es mit dem neuen RamProzess nicht aber mit der älteren Version schon?

    Bin schon wieder etwas weiter...


    RAMProcess (die neue Version) richtet sich bei zwei Laufwerk in der ersten 64K-Speicherbank bei $9E00 ein, das wäre normalerweise die Adresse für den Laufwerkstreiber Laufwerk C: Dann findet sich der obige RAM-Auszug in der REU ab $9E00.


    Installiere ich ein Laufwerk C:, dann liegt obiger RAM-Auszug bei $AB80 im Speicher, das wäre dann hinter dem dritten Laufwerkstreiber.


    Wenn ich die alte Version installiere, dann findet sich der obige RAM-Auszug irgendwo bei $CC00 in der REU.


    Das ist also erstmal alles logisch. Die neue Version scheint Speicher oberhalb des letzten Laufwerkstreiber zu nutzen, bei zwei Treibern ab $9E00. Dort liegt aber Standardmäßig der gleiche Treiber wie Laufwerk A:. Ob den jetzt CONFIGURE dort ablegt oder DeskTop müsste ich prüfen. Aber weil RPneu nicht davon ausgeht das der DeskTop ein Laufwerk C: aktiviert das es gar nicht gibt (wie gesagt, das hab ich als "Bug" in MegaPatch gefixed) überschreibt es den Speicherbereich "blind" ohne zu wissen das hier ein Treiber auf reserve liegt.


    DeskTop ruft dann das Laufwerk C: auf, SetDevice holt den Treiber aus dem RAM-Laufwerk der von RPneu überschrieben wurde -> Systemfehler.


    Code
    1. :l5a97 lda curDrive
    2. pha
    3. lda #$0a
    4. jsr l1b16
    5. cpx #$0d
    6. beq l5ab5
    Code
    1. :l1b16 jsr l1af1
    2. jmp OpenDisk
    Code
    1. :l1af1 pha
    2. jsr SetDevice
    3. pla

    Man sieht, es wird gar nicht getestet ob ein Laufwerk #10 existiert. SetDevice juckt das dann nicht:

    Da wird einfach FetchRAM ausgeführt, auch wenn RPneu den Bereich überschrieben hat. Irgendwas wurde bei RPneu vs. RPalt im Speichermanagement geändert...


    P.S. Ich hab in VICE einfach eine REU eingerichtet und das REU-Image beim beenden als Datei speichern lassen. Dann kann man sich den Inhalt der REU genau anschauen. Ich nutze die erste Speicherbank in MP3/GDOS64 nur für GEOS selbst, aber ich lade da keinen anderen Code ab. Die Adresse der Laufwerkstreiber ist ja schon immer so gewesen... da dürfte RPneu einfach die Laufwerke zählen und den Rest einfach als "Frei" annehmen.


    Das es zu einem Problem in MegaPatch wurde deutet darauf hin das CONFIGURE den Treiber im RAM ablegt. Das macht MP3 ja nicht, DeskTop ruft dann das Laufwerk C: auf und stürzt dann unter MP3 auch ab... Ich hatte CONFIGURE vor 20Jahren auch disassembliert, müsste ich mal nachschauen. In MP3 jedenfalls testet SetDevice in neueren Versionen das Laufwerk vor FetchRAM und lädt dann keinen Treiber bzw. gibt einen Fehler zurück.

    Das ist die Speicherbelegung wie ich Sie kenne...

  • Wer suchet der findet... im Configure-SourceCode hab ich alles gefunden was den Verdacht von oben bestätigt.

    Configure legt den Treiber für das Startlaufwerk auch an der Position des Treibers für Laufwerk C: in der REU ab.

    Code
    1. ;*** Laufwerke erkennen und initialisieren.
    2. :TestAllDrv jsr ExitTurbo ;Turbo-Modus abschalten.
    3. lda ramExpSize ;Speichererweiterung vorhanden ?
    4. ...
    5. ...
    Code
    1. ;*** Laufwerkstreiber installieren.
    2. :LoadDkDrv lda ramExpSize ;Speichererweiterung vorhanden ?
    3. bne CopyDDrv2REU ;Ja, weiter...

    Bei der Laufwerkserkennung werden bei ":InstDrv" die Laufwerke #8 bis #11 getestet. Dabei wird ":CurrentDrive" gesetzt.

    Dabei wird dann ":LoadDkDrv" aufgerufen was bei einer REU nach ":CopyDDrv2REU" verzweigt.

    Am Ende wird dann bei Label ":l0af8" der im Speicher befindliche Treiber auch für ":CurrentDrive" in der ersten 64K-Speicherbank abgelegt und der im Speicher befindliche Treiber landet dann bei einem Laufwerk #10 (das in CONFIGURE nicht eingerichtet ist) auch in der REU, auch wenn es kein dazugehöriges Laufwerk gibt.


    Das scheint Absicht zu sein, damit beim einlesen eines Treibers aus der REU immer ein Treiber ab $9000=DISKBASE landet und Zugriffe auf den Laufwerkstreiber kein Problem verursachen.


    RP überschreibt hier in der neueren Version den Speicherbereich des dritten, ungenutzten Treibers was dann nur bei DeskTop zu einem Absturz führt. Der aktiviert, warum auch immer, ein Laufwerk C: auch wenn das Laufwerk nicht konfiguriert ist.


    Wenn man RP so ändert das es die Daten erst ab dem vierten Laufwerk im Speicher ablegt (oder besser erst dahinter), dann sollte das auch mit der neuen Version funktionieren. Wenn es da aber keinen SourceCode gibt dürfte das schwierig werden.

  • Wenn es da aber keinen SourceCode gibt dürfte das schwierig werden.

    Der ist zumindest nicht öffentlich verfügbar.

    Nach der letzten RP-Version hat Gerd die C64/128-Szene verlassen und für PC-Geos programmiert. Ob er da noch aktiv ist, weiss ich nicht.


    Eine Anpassung für den "alten" DESKTOP halte ich zumindest für nicht unbedingt nötig. RP läuft ja soweit und wer benutzt wirklich noch den originalen Desktop von Geos. Es gibt ja etliche weitere Oberflächen für Geos 64/128 ......


    Und nun hoffe ich mal, dass sich von den momentan erfolgten 10 Downloads noch der eine oder andere meldet und Feedback gibt. Oder doch alles nur noch Jäger & Sammler hier? ;-)


    Gruß

    Werner

  • Es bleibt noch die Frage wie das mit InstallDriveD harmoniert. Das müsste in jedem Fall vorher starten. Ein nachträgliches starten würde vermutlich auch Probleme machen, egal bei welchem DeskTop.


    Ich hab noch etwas nachgeforscht. RP setzt da einen Anfangswert hinter dem letzten Treiber und addiert den dann später nur noch hoch. Ich hab nur noch nicht die Stelle gefunden wo der Anfangswert gesetzt wird.

  • Es bleibt noch die Frage wie das mit InstallDriveD harmoniert.

    InstallDriveD ist Topdesk und sollte eigentlich funktionieren. Am echten C128 läuft hier diese Kombination schon ewig und 3 Tage nicht mehr. Zuletzt war Laufwerk D unter Geos jahrelang bei mir 64NET. Und ab 1999 läuft hier bei mir fast ausschließlich MP3.


    Habe es gerade in GTK-Vice 3.6.1 (Windows 10; da habe ich auch noch Geos-Bootdisk 1541 und 1581 gespeichert) mit Geos 128 getestet. Funktioniert ohne Probleme. Über InstallDriveD wird eine 1571 als D eingerichtet und FileBrowser funktioniert auch ;-) .


    Gruß

    Werner