GEOS MegaPatch V3 Release 2018

Es gibt 1.222 Antworten in diesem Thema, welches 218.654 mal aufgerufen wurde. Der letzte Beitrag (2. Juli 2025 um 17:17) ist von darkvision.

  • GeoPublish will sich auch nicht installieren lassen,

    Das muss ich zumindest für MegaPatch 64 mit einer 1541 als Laufwerk 8 bestätigen. Ist es jedoch erst mal installiert (z. B. unter GEOS 2.0), dann tut es in Megapatch anstandslos seinen Job.

    Edit: Selbe Disk mit 1571 unter MegaPatch 64 lässt sich aber installieren.

    Hab 1581 als 8

  • Äh. Die nicht gepaschten Originaldisketten sind nur für Laufwerk 8 oder 9 gemacht. Und da eine 5,25" Disk nur in einer 1541, 1570 und 1571 reinpasst (von den in Frage kommenden Floppies), so braucht es doch eher die Angabe zur 5,25" Floppy.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Äh. Die nicht gepaschten Originaldisketten sind nur für Laufwerk 8 oder 9 gemacht. Und da eine 5,25" Disk nur in einer 1541, 1570 und 1571 reinpasst (von den in Frage kommenden Floppies), so braucht es doch eher die Angabe zur 5,25" Floppy.

    weiss ich nicht mehr, werds mal probieren, muss ja nur die dippser umschalten, ich hoffe mal, MP3 startet auch von 11, 9 und 10 sind RAM Drives und in einem REU Image verewigt bzw. selbiges bekommt Updates, sobald mal wieder was läuft

  • Bei mir läuft MP3 64/128 ohne Probleme.

    Gut, GeoPublish nutze ich auch gar nicht.

    Einziges Manko welches mir bekannt ist, dass meine 1Mb Flash8 nicht unterstützt wird.

    Pusti64

  • Einziges Manko welches mir bekannt ist, dass meine 1Mb Flash8 nicht unterstützt wird.

    Nun ja, die Flash8 wird meines Wissens von nichts außer dem originalen Geos V2.x unterstützt, also kein Wheels oder MP3.... :wink:

    Gruß

    Werner

  • Einziges Manko welches mir bekannt ist, dass meine 1Mb Flash8 nicht unterstützt wird.

    Nun ja, die Flash8 wird meines Wissens von nichts außer dem originalen Geos V2.x unterstützt, also kein Wheels oder MP3.... :wink:

    Gruß

    Werner

    So ist es, leider.

    Pusti64

  • lässt sich immernoch nicht installieren... nervt langsam, geh wohl über vom diskjuggler zum Modul und diskjuggler ... weil unter wheels auf scpu geht alles :(

  • Das muss ich zumindest für MegaPatch 64 mit einer 1541 als Laufwerk 8 bestätigen. Ist es jedoch erst mal installiert (z. B. unter GEOS 2.0), dann tut es in Megapatch anstandslos seinen Job.

    Edit: Selbe Disk mit 1571 unter MegaPatch 64 lässt sich aber installieren.

    Das ist so ziemlich das hilfreichste was ich in den letzten Posts gelesen hab, Danke dafür :thumbup:

    Wenn es mit 1571 geht, mit 1541 nicht, dann verlässt sich Publish wohl nach einem Disk-Zugriff auf undefinierte Werte, entweder in den Registern oder in r0-r15. Das gab es bei anderen Programmen auch schon. Ich müsste nur die Routine finden bei der dann die Installation abbricht. Nicht unmöglich, nur verdammt viel Arbeit...

    lässt sich immernoch nicht installieren... nervt langsam

    weil unter wheels auf scpu geht alles

    Danke, macht mir die Entscheidung einfach den Fehler nicht zu suchen. :thumbsup:

    (Zumal es sich ja vor dem Update auf MP3 unter G2 installieren lässt... und dann ist das Thema durch...)

  • Ich müsste nur die Routine finden bei der dann die Installation abbricht. Nicht unmöglich, nur verdammt viel Arbeit...

    Am Wochende will ich danach mal schnell schauen - Hypothesentest. Die App-Disketten von Berkeley Softworks teilen sich ein grundsätzliches Procedere bei der Installation: Falls die Seriennummer nach Entschlüsselung = 0 ist, dann wird ein fest einkodierter Block nach IIRC $8000 geladen, Prüfsumme kontrolliert und falls die passt, der Block per JMP angesprungen. Dort ist dann die eigentliche Kopierschutzabfrage. Und jene habe ich in Verdacht. Ältere Versionen der Kopierschutzabfrage (in anderen Programmen) wollen z. B. nicht mit dem 1571 Diskettentreiber. Nun, mit einer 1571 kann man in Geos auch den 1541 Treiber nehmen, was man für solche Originale auch muss/musste.

    Mit etwas Übung - und die sollte ich noch haben - findet sich die Stelle per VICE recht schnell (Breakpoint auf Seriennummernabfrage C196, wenn man die richtige davon gesehen hat, dann Breakpoint auf "Block lesen" und man ist nur wenige Instruktionen davon entfernt). Und dann kann ich den Block mal durch eine Routine erstzen, die nichts macht und immer nur "OK" zurückgibt. Wenn dann alles geht, hat man das Ganze auf weniger als 256 Bytes eingeschränkt.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Am Wochende will ich danach mal schnell schauen - Hypothesentest.

    Das wäre auch meine Motivation gewesen... meine Vermutung zu bestätigen.

    Wie gesagt gab es so Probleme schonmal... da hat eine Anwendung nach einer Disk-I/O-Routine im Akku einen bestimmten Wert erwartet, den es aber nur bei einem Treiber gab. Bei anderen Treibern war der Wert immer anders.

    Das Problem kann also an einer ganz anderen Stelle liegen, ggf. muss man von SerialNumber rückwärts suchen.

    Interessieren würde es mich schon, aber ich selbst sehe da kaum die Notwendigkeit dafür. Aber falls Du Zeit übrig hast ;)

  • Kann sein, ist aber unwahrscheinlich. Wie gesagt, nach der Installation geht es ja. Also liegt der Hauptverdacht auf den Programmteil, der nur bei der Installation ausgeführt wird. Und es steht halt erst nach der Seriennummernprüfung fest, ob die Installation ausgeführt wird. In der Tat kannst Du den dazu bringen, nochmal zu installieren, wenn Du in der Nähe der Seriennummernprüfung im VICE-Monitor trickst. Außer bei einigen Applikationen, da wird noch der Block mit der Kopierschutzabfrage bei der Installation überschrieben. Den muss man dann auch noch im Monitor helfen...

    Mehr vernichten tut aber keine einzige Applikation von Berkeley Softworks, mit allein der Seriennummer und den Kopierschutzabfrageblock kann man quasi alles uninstallieren.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Wo wir gerade dabei sind: Ich habe eine alte Aufzeichnung wiedergefunden, in der viele Infos zu den Kopierschutz von GeoPublish drin sind:

    Die Seriennummer ist demnach in Track 15 Sektor 1 ab Byte 152, wobei die mit $65 XOR kodiert ist. Ins Ram wird die nach $2972 eingeladen. Die anschließende Kopierschutzabfrage soll demnach auf Track 14 Sektor 18 sein. Und wie alle Berkey Softworks Kopierschutzabfragen von Applikationen werden die Gaps auf den selben Track überprüft, wie die Kopierschutzabfrageroutine zu finden ist.

    Das sind doch massig Anhaltspunkte, die das angedachte erheblich vereinfachen. :smile:


    Nachtrag: Es ist exakt die vermutete Stelle. Wenn ich Track 14 Sektor 18 durch $00 $FF $A2 $00 $60 $00 $00 ... $00 $02 ersetze, so lässt sich das so gecrackte GeoPublish von D64 installieren unter Geos MP3 von 1541.

    Damit ist das Problem in den 253 Bytes, die in dem Sektor drin sind (die ersten beiden Bytes sind $00 $FF und das letzte Byte ist eine simple Prüfsumme, die durch Addition der Bytes $02 bis $FE entsteht).

    In der Floppy befindet sich vom Laden des Sektors der relevante Teil noch im Speicher und braucht daher nicht übertragen zu werden:

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von markusC64 (4. März 2022 um 21:22)

  • Der Code kommt mir doch im Wesentlichen kannt vor - ja genau, einen sehr ähnlichen Code habe ich schon mal gelesen: Bitte melde dich an, um diesen Link zu sehen. - suche dort nach "start:" - dieses nicht wirklich zu beliebigen Treibern kompatible Verfahren macht Probleme, wie man es erwarten müsste...

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (4. März 2022 um 21:37)

  • Der Code kommt mir doch im Wesentlichen kannt vor - ja genau, einen sehr ähnlichen Code habe ich schon mal gelesen: Bitte melde dich an, um diesen Link zu sehen. - suche dort nach "start:" - dieses nicht wirklich zu beliebigen Treibern kompatible Verfahren macht Probleme, wie man es erwarten müsste...

    Wow... nice catch!:thumbup:

    Ich hab den Code dort mal durchgelesen und mit dem aktuellen Code verglichen... und ja, das dürfte das Problem sein. Aktuell kann die geoPub-Routine den Code-Einsprung in das TurboDOS gar nicht finden, weil die eigentliche Routine vor dem Einsprung bei NewDisk im Speicher liegt. Bei der 1571 wird an der richtigen Stelle gesucht.

    Könnte ich wieder tauschen, aber gab sicher einen Grund das zu ändern.

    Aber selbst dann wird das nicht funktionieren, weil um Speicherplatz zu sparen der STA-Befehl eingespart wurde.

    Ich muss mal testen was beim 1541-Treiber noch an Speicher im Treiber frei ist, evtl. kann man dann ein paar Fake-Bytes einfügen, damit geoPub die richtigen Bytes finden. Für den Treiber wären das Dummy-Bytes ohne Funktion, aber einfacher als den Code umzustricken...

    Wenn ich die Zeit und Lust dazu finde kann man da sicher was machen...

    Danke dafür :thumbsup:

  • Warum kann ich vom Taskmanager aus keine Subdirs öffnen? Oder besser gefragt: Warum werden sie mir nicht angezeigt?

  • Weil GEOS an sich keine UVs unterstützt... und wie an anderer Stelle schon mehrfach ausgeführt ist der Verzeichniswechsel auf OS-Ebene eine ganz schlechte Idee. Partitionen kann man zwar im TaskManager wechseln, aber die Idee ist noch viel schlechter.

    Man stelle sich nur vor man hat geoWrite+Dokument auf Laufwerk A:/CMD-HD geöffnet. Dann öffnet man einen neuen Task und wechselt dabei auf der CMD-HD die Partition. Dann wechselt man zum geoWrite-Task zurück, dort ist jetzt die falsche Partition aktiv. Ganz schlechte Idee! Das ist in etwa so als hätte man auf der 1541 eine andere Diskette eingelegt.

    Jetzt könnte man zwar bei jedem TaskWechsel auf jedem Laufwerk die aktive Partition abfragen und anschließend wieder zurücksetzen. Das zieht dann aber noch weitere Disk-I/O-Aktivitäten nach sich, denn man müsste ja sicherstellen das die BAM auf Disk aktualisiert wird. Aber ist wenn die aktive Anwendung Änderungen an der lokalen BAM ausgeführt hat, die später aber nicht gespeichert werden sollen (z.B. Abbruch der Anwendung)? Das bekommt man nicht in den Griff...

    Bei der RAMLink funktioniert der Partitionswechsel noch (weil wie an anderer Stelle erwähnt greift der Treiber direkt auf die 16Mb-RAM zu, ohne Partitionswechsel), aber tun sollte man das dennoch nicht (gleiches Thema mit der BAM).

    Aus dem Grund kann man auf SD2IEC auch keine DiskImages wechseln (wäre bestimmt die nächste Frage), weil es keine Angabe gibt welches DiskImage gerade aktiv ist. D.h. ich könnte bei einem TaskWechsel nicht auf ein anderes DiskImage zurückwechseln.

    Verzeichniswechsel ist eine Sache auf Anwendungsebene, aber ausser den DeskTops und ein paar Apps (geoDirSelect z.B.) können Anwendungen keine Verzeichnisse wechseln, weil das vor 30Jahren eher die Ausnahme war.

    Der TaskManager ist dazu da um auf den aktiven Laufwerken mehrere Programme zu starten und ggf. Daten untereinander auszutauschen. Ich hab das gestern mit geoWrite2.2 und geoWLoad64 und dem Austauschen von URLs getestet. Das geht.

    Hätte man aber beide Programme auf getrennten Partitionen auf dem gleichen Laufwerk, dann geht das schon nicht mehr (weil das TextScrap dann auf der geoWrite-Partition liegt und geoWLoad64 davon nichts weiß...). Und bei SubDirs wäre es das gleiche (SubDir A mit geoWrite+TextScrap, SubDir B mit geoWload64 findet das TextScrap nicht...)

    Ja, die meisten wollen hier 16Mb-Native mit SubDirs und allen Dateien+Dokumente auf einer Partition halten. Ich wiederhole mich zwar, aber ich halte das für eine ganz schlechte Idee... aber jeder wie er will ;)

  • Ich habe nicht den ganzen Tread gelesenm darum Frage ich ganz Direkt:

    Würde hier ein Publish ohne SerienNR-Abfrage helfen??

    Ich habe bereits einen Man vor Ort, die Sache wird erledigt werden, so wie immer.............

  • Würde hier ein Publish ohne SerienNR-Abfrage helfen??

    Vielleicht... aber das ist ein Fehler der ggf. auch bei anderen Programmen mit der gleichen Installationsroutine vorkommt, daher würde ich eher versuchen den Treiber zu modifizieren.

  • Ich hänge es mal dran.................

    Habs mal kurz gestartet, braucht keine Installation............

    Eingeladen unter GDos..........Scheint aber "Ungepacht" nur A & B.............

    Keine Ahnung, wer das "Verbrochen" hat.......................

    Hoffe es Hilft.............Viel Spaß damit