GEOS MegaPatch V3 Release 2018

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

  • Tja, dann ist das wohl ein Problem mit den älteren GeoPublish...

    Danke... dann muss ich da auch nicht mehr suchen. Leider lag dem ZIP keine README bei, ich hatte nur die erste Disk geöffnet, dort war Publish drauf. Das es noch eine DIsk mit einer neueren Version gab, auf die Idee bin ich nicht gekommen.

    Dann kann ich für die Patches für MP3-US die zweite Disk verwenden...

  • Ich hab jetzt einen ersten r10-SnapShot Bitte melde dich an, um diesen Link zu sehen.... damit hab ich eben am C64mk2 mit TC64 und dem GeoPublish-D1a.G64 GeoPublish erfolgreich installiert. Auch die D0a/1987er-Version.

    Es könnte also sein das die 1987er-Version auch an anderen Stellen noch den Laufwerkstreiber getestet hat und das dann zum Absturz geführt hat. Aber evtl. hatte ich bei meinen aktuellen Tests auch nur "Glück" ;)

    Ach ja... bei der 128er Version hab ich das helle Hintergrundbild jetzt als Standard gesetzt, ist also kein Fehler. Was aber nicht heißen soll das ich beim packen nicht evtl. auch einen Fehler gemacht habe... Fehler passieren... ;)

    Hab ich schon erwähnt das ich für den Test am MK2 alle Test-Images und die neuen Setup-Images "Over-the-Air" übertragen habe? Keine einzige SD-Karte oder Diskette wurde "gewechselt" (Außnahme geoPublish.G64 -> TC64). :thumbsup:

    Echt schade das https nicht geht... sonst könnte man das Update jetzt direkt von bitbucket auf den C64 downloaden...

  • D.h. die Version auf der MP3-de.D64-Disk ist in jedem Fall eine 128er Version

    Stimmt :wink: .

    Habe mal etwas nachgeprüft. Das besondere dieser Version ist der 80-Zeichenmodus. Im Original arbeitet PatchSystem, anders als von mir gedacht, immer im 40 Zeichenmodus. Allerdings habe ich hier bei mir bisher noch keinen entsprechenden Patch-Quelltext oder Patch-Prg gefunden....

    Diese Version ist irgendwie irrtümlich in das Archiv für MP3-64 gekommen.


    Ich hab jetzt einen ersten r10-SnapShot hochgeladen

    Ein erster kurzer Test (MP3-128 deutsch unter WinVICE) zeigt bisher keine Probleme.

    Gruß

    Werner

  • Ich hab jetzt einen ersten r10-SnapShot hochgeladen

    Ein erster kurzer Test (MP3-128 deutsch unter WinVICE) zeigt bisher keine Probleme.

    Ich habe die Version gerade mal auf meinen Ultimate 64 getestet. So weit ich das auf die Schnelle beurteilen kann, lassen sich damit jetzt wirklich alle Berkeley Softworks Originale installieren. Selbst die ganz alten Originale wie US Writers Workshop lassen sich installieren - jene haben noch einen komplett anderen Kopierschutz, nämlich auf Track 36. Allerdings nur mit einer 1541 - was nicht überrascht, weil sich jene Originale auch mit GEOS 2.0 nicht mit einer 1571 installieren lassen (außer man nimmt den 1541 Treiber mit der 1571, jener Trick klappt auch mit dem neuen MP3 Snapshot).

    Wenngleich es also wenig überraschend ist, dass sich jene Originale nicht mit dem 1571 Treiber installieren lassen, so ist die Ursache doch meines Wissens nach offen. Abstützen tut es nicht, es hält die Diskette lediglich für kein Original und verweigert die Installation.

    Ich taste mich mit der 1571 gerade mal weiter vor zu den neueren Originalen...

    ---
    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.

  • Wenngleich es also wenig überraschend ist, dass sich jene Originale nicht mit dem 1571 Treiber installieren lassen, so ist die Ursache doch meines Wissens nach offen. Abstützen tut es nicht, es hält die Diskette lediglich für kein Original und verweigert die Installation.

    Kannst Du mal beschreiben was man da genau installieren muss? Hab den WriterWorkShop64.zip aus der Wolke geladen, evtl. würde es ja helfen den Fix auch auf den 1571-Treiber anzuwenden, der bereits im Original an der Stelle vom 1541-Treiber abweicht. Ich könnte das aber passend modifizieren...

    Ob das aber in MP3 einfließen wird ist fraglich, denn den Publish-Fix musste ich so schreiben das er nur im 1541-Treiber Anwendung findet, weil im 128er-1571-Treiber der Speicher nicht reicht. Für GDOS64 wäre das aber egal...

  • Hm, dann solltest Du eine "WritersWorkshop_s0.deinstalled.g64" vorfinden. Dort ist ein "GeoWrite 2.0" (nicht 2.1) drin vorhanden. Das macht die erwähnten Probleme.

    Kannst aber auch GeoProgrammer Bitte melde dich an, um diesen Link zu sehen. nehmen, da hat Werner sogar dokumentiert, dass es solche Probleme macht. Und mit MP3 3.3R10 Snapshot kann ich bestätigen, dass es unter MP3 genauso ist. Wobei ich unter MP3 lediglich die Installatiuon getestet habe.

    ---
    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.

  • Kannst aber auch GeoProgrammer originale GEOS-Applikationen jungfräulich nehmen, da hat Werner sogar dokumentiert, dass es solche Probleme macht. Und mit MP3 3.3R10 Snapshot kann ich bestätigen, dass es unter MP3 genauso ist. Wobei ich unter MP3 lediglich die Installatiuon getestet habe.

    OK, Danke. Damit kann ich das nachstellen... ich schau es mir mal an.

  • So wie es aussieht, habe ich die 80z-Version vom PatchSystem verbrochen.

    Konnte mich nur noch dunkel daran erinnern und heute nach langem Suchen auf einer 81-Partition meiner HD die folgenden PatchTexte gefunden.

    Aber Achtung!

    Ich gehe davon aus, dass da garantiert noch Fehler drin sind und daher ist die Benutzung auf eigene Gefahr ! ! !

    Habe damals sogar einen MegaAss-Quellcode vom PatchSystem erstellt. Da mir aber keine Genehmigung vorliegt und ich keinen Ärger haben möchte "nur" die PatchTexte zum TESTEN im Anhang.

    Pusti64

  • So wie es aussieht, habe ich die 80z-Version vom PatchSystem verbrochen.

    Kann sein, weiß ich nicht mehr so genau :wink: ...

    ich keinen Ärger haben möchte "nur" die PatchTexte zum TESTEN im Anhang.

    Zumindest die Programme PatchSystem, Checksummer und die komplette Anleitung dazu sind frei verfügbar. Wäre ja auch wenig hilfreich, wenn man für Patches das Programm, das die Änderungen durchführt, nicht mitliefern könnte/dürfte...

    Und die Disketten der GUSS sind auch schon lange frei verfügbar, z.B. in der GUC-Geothek, die auch auf der F64-Wolke liegt.

    Gruß

    Werner

  • ich keinen Ärger haben möchte "nur" die PatchTexte zum TESTEN im Anhang.

    Zumindest die Programme PatchSystem, Checksummer und die komplette Anleitung dazu sind frei verfügbar. Wäre ja auch wenig hilfreich, wenn man für Patches das Programm, das die Änderungen durchführt, nicht mitliefern könnte/dürfte...

    Und die Disketten der GUSS sind auch schon lange frei verfügbar, z.B. in der GUC-Geothek, die auch auf der F64-Wolke liegt.

    Gruß

    Werner

    Ja ich weiß, mir ging es dabei aber mehr um den von mir erstellen Quellcode vom PS.

    Pusti64

  • Kannst aber auch GeoProgrammer originale GEOS-Applikationen jungfräulich nehmen, da hat Werner sogar dokumentiert, dass es solche Probleme macht. Und mit MP3 3.3R10 Snapshot kann ich bestätigen, dass es unter MP3 genauso ist. Wobei ich unter MP3 lediglich die Installatiuon getestet habe.

    So... hab jetzt mal etwas nachgeforscht warum sich geoProgrammer auf einer 1571 nicht installieren lässt.

    Die Installationsroutine liegt EOR-codiert im DatensatzBitte melde dich an, um diesen Link zu sehen.. Dieser Datensatz wird ab $05b1 in den Speicher gelesen:

    Code
    .C:05b1  A9 FF       LDA #$FF
    .C:05b3  85 73       STA $73
    .C:05b5  A9 02       LDA #$02
    .C:05b7  20 E5 04    JSR $04E5

    In $73 steht der zuletzt gelesene Datensatz und damit die allgemeine Laderoutine den Datensatz auch ganz sicher einließt, wird der aktuelle Datensatz mit $ff initialisiert. Hier die Laderoutine.

    Hier passiert noch nichts besonderes, es wird ja nur ein Datensatz eingelesen. Spannend wird es nachdem der Datensatz eingelesen wurde. Als erstes wird der Datensatz EOR-"entschlüsselt":

    Hier findet sich jetzt ab $5c7c der entschlüsselte Installer:

    Code
    .C:5c7c  4C 7F 5C    JMP $5C7F
    .C:5c7f  A5 02       LDA $02
    .C:5c81  8D FC 5F    STA $5FFC
    .C:5c84  A5 09       LDA $09
    .C:5c86  8D FE 5F    STA $5FFE
    .C:5c89  A5 08       LDA $08
    .C:5c8b  8D FD 5F    STA $5FFD
    .C:5c8e  A9 C0       LDA #$C0
    .C:5c90  85 2F       STA $2F
    .C:5c92  20 23 5D    JSR $5D23

    Und ab $5d23 wird dann zuerst die Seriennummer geprüft und falls $0000, dann wird getestet ob sich geoAssembler installieren lässt. Auch das ist wieder etwas "versteckt".

    Ab $5e7a wird ein Datenblock $01/$08 von Disk nach $8000=diskBlkBuf gelesen.

    Die erste Hürde für die 1571 findet sich hier gleich zu Beginn:

    Code
    .C:8002  4C 70 80    JMP $8070
    ...
    .C:8070  A2 0A       LDX #$0A
    .C:8072  AC 89 84    LDY $8489
    .C:8075  B9 86 84    LDA $8486,Y
    .C:8078  29 BF       AND #$BF
    .C:807a  C9 02       CMP #$02     ;1541 ?
    .C:807c  B0 52       BCS $80D0    ; => Nein Fehler $0A = StructMismatch

    Also wird bis auf 1541/1541Shadow jedes andere Laufwerk als "ungültig" markiert... aber nehmen wir mal an man könnte das ignorieren und ändern das entsprechend ab, so das auch eine 1571 hier akzeptiert wird. Dann folgt als nächstes alt bekannter Code:

    Hier wird jetzt auch wieder die Routine NewDisk im Laufwerkstreiber gesucht, dort dann nach dem "STA $8B"-Befehl und die beiden folgenden JSR-Befehle ausgelesen und in den Code integriert.

    Hier mal der Auszug aus der 1541-Routine NewDisk:

    Code
    ;*** Neue Diskette öffnen.
    :xNewDisk
                lda    #> l04dc
                sta    $8c
                lda    #< l04dc
                sta    $8b
                jsr    TurboRoutine_r1
                jsr    GetDiskError
                beq    :52

    Bei der 1571 hatte man damals schon Speicherplatzprobleme und hat den Code "optimiert":

    Code
    :l9854
                ldx    #$05
                lda    #$7e
                jsr    l97e9
                jsr    l991d
                beq    l9877

    Im 1571-Treiber gibt es diesen "STA $8b"-Befehl nicht. Diese "Optimierung" um Speicherplatz zu sparen hatte ich irgendwann in alle Treiber übernommen, was dann dazu geführt hat das dann geoPublish&Co auch mit der 1541 nicht mehr installiert werden konnten.

    Nehmen wir mal an ich hätte im 1571-Treiber die Routine an die 1541 angepasst, damit die Testroutine die beiden JSR-Befehle findet und in den Code integrieren kann. Dann sieht der auszuführende Laufwerkstest so aus:

    Code
    .C:80bf  A9 07       LDA #$07    ;Execute Code im Floppy-RAM ab $0705.
    .C:80c1  85 8C       STA $8C
    .C:80c3  A9 05       LDA #$05
    .C:80c5  85 8B       STA $8B
    .C:80c7  20 99 97    JSR $9799   ;TurboRoutine_r1
    .C:80ca  20 B7 98    JSR $98B7   ;GetDiskError
    .C:80cd  20 5F C2    JSR $C25F
    .C:80d0  60          RTS

    Die Routine startet dann ein Programm das ab $0705 im Speicher liegt. Ab $0700 liegt der zuletzt von GEOS gelesene Datenblock, also noch $01/$08. Der liegt ja auch ab $8000 noch im Speicher des C64. Im Laufwerks-RAM sieht das dann so aus:

    Hier werden dann ROM-Routinen aufgerufen und sehr nahe an den Laufwerksregistern $1c00/$1c01 (Sync/Datenregister) gearbeitet. Die Routine $F510 = ReadHeader gibt es auch im 1571-ROM.

    Bei der 1571 wird die Routine aber mit dem Fehlercode $03 beendet, d.h. es wird gar nicht mehr in die Testroutine zurückgekehrt.

    Das Problem scheint bei $F556 zu liegen, es wird auf ein SYNC gewartet, das scheint aber nicht zu passieren und dann wird der Fehlercode $03 gesetzt:

    Mit einem 1541-Laufwerk wird der Kernal-Aufruf $F510 erfolgreich beendet, d.h. die SYNC-Markierung wird gefunden und die restliche Routine wird abgearbeitet. Bei Erfolg wird der Fehler-Code dann auf $01 gesetzt:

    Code
    .10:073f  20 58 07    JSR $0758
    .10:0742  CA          DEX
    .10:0743  D0 E8       BNE $072D
    .10:0745  E8          INX        ;XReg $00 -> $01.
    .10:0746  86 00       STX $00    ;$01 = Kein Fehler.
    .10:0748  60          RTS

    Der Wert wird dann mit GetDiskError ausgelesen. Dort hatte ich schon vor 20 Jahren $01 = Kein Fehler dokumentiert:

    Hier scheint also ganz gezielt das Timing des Laufwerks dazu benutzt zu werden um eine Originale Disk zu erkennen und das scheint nur bei der 1541 problemlos zu funktionieren. Daher wird explizit auf die 1541 getestet und alle anderen Laufwerke werden abgelehnt.

    Ich hab jetzt "jsr GetDiskError" durch ein "LDX #$00/NOP" ersetzt, also dem System vorgegaukelt das der Test erfolgreich war. Dann hab ich die Meldung "geoAssembler installed" erhalten und geoAssembler lässt sich dann von der Disk starten.

    Dann noch früher eingestiegen und den "JSR $8002" Befehl, der den Test im Block $01/$08 startet, durch ein "LDX #$00/NOP" ersetzt. Installation war auch erfolgreich.

    Und dann war ich mal so dreist und und hab mir von der uninstallierten G64-Disk ein D64 erstellt. Mit einem Hex-Editor dann vier Bytes geändert:

    Bei Offset $0000:0802 $A0,$00,$60

    Das ist Block $01/$08 und der Einsprung wird dann geändert zu:

    Code
    .C:8002  A2 00       LDX #$00   ;Test erfolgreich beendet...
    .C:8004  60          RTS

    Da hier vor dem Aufruf noch eine Prüfsumme erstellt wird, muss man die im gleichen Block ebenfalls anpassen.

    Bei Offset $0000:08ff $CC

    Das ist die Prüfsumme des geänderten Block $01/08.

    Und dann lässt sich auch geoAssembler von einem D64 und der 1571 installieren. Die Seriennummer findet sich dann auch auf Disk, ist aber mit $0C0C EOR-kodiert. Und im BAM-Block wird dann nach Byte $BD(=50 für Hauptdiskette) noch zwei Bytes geändert $1c/$13 -> $57/$2c. Genaue Funktion ist mir jetzt nicht ganz klar.

    Kurz gesagt: Hat nichts mit MP3 zu tun... da kann ich jetzt den Code im 1571-Laufwerkstreiber von GDOS64 wieder zurückändern, die NewDisk-Anpassung braucht es ja für die 1571 nicht, denn die "gepatchte" D64-Disk lässt sich auch unter MP3r10 mit der 1571 installieren, sogar von einem RAM1541-Laufwerk :)

    Ich hab jetzt nichts weiter mit geoAssembler gemacht, hab den ja vor Jahren auch mal gekauft aber MegaAssember war mir da Sympathischer. Ich hab daher nur getestet ob die Installation bis zur Installed-Meldung durchläuft...

    P.S. Bei geoPublish und folgende scheint es ja dann eine Anpassung dieses Schutzes gegeben zu haben, das ist ja hier von markusC64 schon Bitte melde dich an, um diesen Link zu sehen. worden. Dort gibt es ja dann eine Ausnahme für die 1571. Bei geoProgrammer gibt es diese Ausnahme nicht.

  • Danke für die sehr ausführliche Recherche.

    wird ein Datenblock [fest kodierter Sektor] von Disk nach $8000=diskBlkBuf gelesen.

    Interesaanterweise machen das alle Berkeley Softworks Applikationen so, inkl. denen, die M&T veröffemtlicht hat.

    Und im BAM-Block wird dann nach Byte $BD(=50 für Hauptdiskette) noch zwei Bytes geändert $1c/$13 -> $57/$2c. Genaue Funktion ist mir jetzt nicht ganz klar.

    Wenn man ein Geos 2.0 neu installiert, wird gefragt, ob man die Seriennummer von einer Applikationsdiskette übernehmen will (okay, die Fragestellung ist leicht anders, meint aber das). Genau dort schaut jene Übernahme nach, wobei die Seriennumemr da verschlüsselt ist.

    ---
    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.

  • Interesaanterweise machen das alle Berkeley Softworks Applikationen so, inkl. denen, die M&T veröffemtlicht hat.

    Ich hab das mit den vier geänderten Bytes auch mal bei geoPublish versucht.

    Block ist $0b/$0b bei Offset 0000:dd00. Hier die Bytes $4c,$7a,$80 ab $dd02 geändert in $a2,$00,$60 (LDX Bitte melde dich an, um diesen Link zu sehen./RTS). Die Prüfsumme in $ddff geändert von $D7 in $93. Dann funktioniert die Installation auch auf einem D64 und damit wohl auch auf einer RAM1541.

    Theoretisch könnte man dann "Originaldisketten" im D64 Format bereitstellen, man muss ja nur einen Block modifizieren. Einfacher wäre es natürlich die verschlüsselte Stelle für den "JSR $8002"-Befehl zu finden und den direkt durch ein LDX Bitte melde dich an, um diesen Link zu sehen. zu ersetzen.

    Bei geoProgrammer wäre das im D64 bei Offset 0001:0C42 -> $2c $0e $8c ist $20 $02 $80. Ändert man das in $AE $0C $E6, dann funktioniert die Installation auch auf einem D64 und auf einer RAM1541.

  • Theoretisch könnte man dann "Originaldisketten" im D64 Format bereitstellen, man muss ja nur einen Block modifizieren. Einfacher wäre es natürlich die verschlüsselte Stelle für den "JSR $8002"-Befehl zu finden und den direkt durch ein LDX Bitte melde dich an, um diesen Link zu sehen. zu ersetzen.

    Einfacher vielleicht, aber der eine modifizierte Block, den er per absoluter Track/Sektor nachlädt, hat den Vorteil, außerhalb der VLIR-Verkettung zu sein. Daher würde man bei den Patchen des Kopierschutzabfrageblockes eine Installation erhalten, wo die App komplett unverändert erscheint - wenn man davon Arbeitsdisketen macht. Der Vorteil ist also eher bei der ersten Variante und nicht bei der letzten.

    ---
    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.

  • Daher würde man bei den Patchen des Kopierschutzabfrageblockes eine Installation erhalten, wo die App komplett unverändert erscheint - wenn man davon Arbeitsdisketen macht.

    Stimmt... :thumbup: die Veränderung würde dann ja bei jeder Kopie der Anwendung mitwandern. Also muss man den Block suchen, die drei Bytes ändern, eine Prüfsumme berechnen und im letzten Byte im Block speichern.

    Da könnte man bei Bedarf ein Patch-Tool schreiben das alle Sektoren durchsucht, über die Prüfsumme im letzten Byte müsste man den Sektor auch gut identifizieren können... zusätzlich müssen die ersten drei Bytes vermutlich immer $00,$ff,$4c sein... Bytes ändern, Neue Prüfsumme, Fertig. Aber ich glaube das ist den Aufwand nicht mehr Wert :)

  • Und im BAM-Block wird dann nach Byte $BD(=50 für Hauptdiskette) noch zwei Bytes geändert $1c/$13 -> $57/$2c. Genaue Funktion ist mir jetzt nicht ganz klar.

    Wenn man ein Geos 2.0 neu installiert, wird gefragt, ob man die Seriennummer von einer Applikationsdiskette übernehmen will (okay, die Fragestellung ist leicht anders, meint aber das). Genau dort schaut jene Übernahme nach, wobei die Seriennumemr da verschlüsselt ist.

    Gibt es da für jedes Programm den gleichen oder gar einen anderen eor-Wert für die Verschlüsselung?

    Pusti64

  • Gibt es da für jedes Programm den gleichen oder gar einen anderen eor-Wert für die Verschlüsselung?

    Jeweils andere - hier eine nicht ganz vollständige Tabelle (in der BAM ist die Seriennummer nicht EOR, sondern Rotate 1, welche Richtung weiß ich auswendig nicht, ROTATE als 16 Bit Wert, also nicht HI UND LO geterennt rotiert, sondern gemeinsam).

    Paket

    Programm

    Position Seriennummer

    XOR-Wert

    Snr Ram

    Kopierschutzabfrage

     
       

    Track

    Sektor

    Offset

     

    Hex

    Track

    Sektor

     

    Geos 64 2.0

    Bootdisk

    20

    5

    197

     

    9ea7 / d838

    anders implementiert

     

    Geos 64 2.0

    GeoWrite

    14

    8

    95

    DE

    3993

    13

    9

     

    Geos 64 2.0

    GeoMerge

    15

    3

    252

     

    ???

    30

    8

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    GeoChart

    GeoChart

    3

    17

    174

    BD

    2D22

    N/A

    N/A

     

    GeoPublish

    GeoPublish

    15

    1

    152

    65

    2972

    14

    18

     

    GeoCalc 64

    GeoCalc 64

    13

    19

    249

    ad

    4cbd

    12

    4

     

    GeoFile 64

    GeoFile

    16

    6

    77

    de

    4441

    13

    4

     

    GeoFile 64

    GeoMerge

    1

    1

    252

     

    043a

    22

    5

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    Deskpack

    Graphics Grabber

    1

    16

    65

     

    037f

    2

    1

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    Deskpack

    Geodex

    3

    3

    86

     

    085e

    3

    3

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    Deskpack

    GeoMerge

    8

    5

    252

     

    043a

    8

    1

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    Geos 128 2.0

    Bootdisk

    20

    13

    116

     

    9f54 / e7af

    anders implementiert

     

    Geos 128 2.0

    GeoWrite

    10

    12

    116

    de

    3aa6

    9

    0

     

    GeoCalc 128

    GeoCalc 128

    13

    13

    24

    ad

    a40e

    13

    15

     

    GeoFile 128

    GeoFile 128

    14

    13

    170

    de

    43a0

    14

    0

     

    GeoFile 128

    GeoMerge

    1

    3

    252

     

    043a

    22

    6

    überschreibt Kopierschutzabfrage mit BAM bei Installation

    ---
    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.

  • Vielen Dank für die Info bzw. prima Erklärung.

    Pusti64

  • auf einer 81-Partition meiner HD die folgenden PatchTexte gefunden.

    mmhh, 3 Quelltexte und 2 davon von J. Weigt. Seltsam, seltsam, hast Du noch irgendeine Erklärung dafür?

    Soweit ich mich erinnere hatte J. Weigt mehr am C64 gearbeitet....

    oder gar einen anderen eor-Wert für die Verschlüsselung?

    also Ergänzung zu der Liste von markusC64 kann ich noch geoAssembler (Geoprogrammer) liefern:

    eor $0c im VLIR-Datensatz $02 (Zählung beginnt mit DS 0)

    Gruß

    Werner

  • kann ich noch geoAssembler (Geoprogrammer) liefern:


    eor $0c im VLIR-Datensatz $02 (Zählung beginnt mit DS 0)

    Stimmt, habe ich so in Bitte melde dich an, um diesen Link zu sehen. auch vermerkt...

    ---
    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.