Posts by markusC64

Fehlerkorrektur zum Buch: Auf Seite 28 steht:

Nicht erst seit GEOS V1.3 enthält jede GEOS-Originaldiskette eine Seriennummer. ies war auch schon bei GEOS V1.2 der Fall, aber erst seit GEOS V1.3 muß das System installiert werden, und dabei wird die Seriennummer auf die Diskette geschrieben.

Dies ist so nicht richtig. Auch GEOS V1.2 muss installiert werden. Nur ist die Installation ganz unauffällig. Beim ersten Start wird die ohne Bildschirmmeldung im Hintergrund durchgeführt, so dass man u. U. gar nicht bemerkt, dass die Systemdiskette installiert worden ist. Kann leicht mit meinen deinstallierten Versionen aus dem Nachbarthred ausprobiert und überprüft werden.

Quote from ogd

Wurde denn das Buch schon eingeordnet? Falls ja, wo?

Ich fürchte nicht. Bis es soweit ist, nimm mal https://www.hidrive.strato.com/lnk/0EJEjKex - das ist meine Freigabe auf meinen kostenlosen HiDrive-Account.

Edit: Das Interesse an dem Buch scheint ja groß zu sein. Habe gerade den Downloadzähler zurückgesetzt. Aber da ich "nur" die kostenlose HiDrive-Version habe, kann ich nicht mehr als 5 Downloads einstellen...

Interessanterweise hatte damals Data Becker im oben bereits genannten großen Geos Buch, 3. Auflage, Basic-Listings veröffentlicht, die den Kopierschutz der Geos 1.2 und der Geos 1.3 Deutsch Systemdisketten brechen.

Die für Geos 1.3 funktionieren auch mit Geos 2.0.

Die Listings habe ich abgetippt auf eine meiner alten Geos-Disketten wiedergefunden. "Teil 4*" ist dabei nicht aus dem Buch, sondern damals ergänzt, damit die Icons stimmen ohne Eingriffe mit Icon-Editoren etc.

Das schöne an der Data Becker Lösung ist, dass der Fastloader intakt blieb und der optische Eindruck auch unverändert gegenüber dem Original ist.

Sehr interessant. Der Aussschnitt legt nahe, mit Vice in der Floppy einen Breakpoint bei 0652 zu legen - und siehe da, es klappt. Man landet mitten in der Kopierschutzabfrage von Geos 2.0 (C64). Aber auch bei Geos 1.3 (DE + US) klappt das.

Das gibt einen ja mal die Chance, rauszubekommen, was die Geos 1.3 US-Version auf Track 36 eigentlich abfragt.

Und weil bald Ostern ist, noch ein Geos, diesmal Version 1.3 englisch.

Ist deswegen interessant, weil Track 36 noch eine andere Schutzvariante beinhaltet. Jener neuer Inhalt von Track 18 befriedigt unter Vice auch die Kopierschutzabfragen der zuvor geposteten Geos 1.2-Versionen. Umgekehrt aber nicht.

Anbei meine Sammlung von GEOS 1.x-Versionen. Alle deinstalliert.

geos-v1.2a.zip und geos-v1.2b.zip sind mit verschiedenen Kopierschützen auf Track 36 geschützt.
Für Geos 1.3 gebührt der Dank GenerationCBM für die installierte Version.

Ja, da wird viel erklärt. Immerhin 7 Seiten sind nur dem Thema Kopierschutz und dessen Abfrage im Bootvorgang gewidmet.

Trotzdem empfehle ich, mit meinem g64conv eine Geos-Diskette (V2.0 oder 1.3 deutsch) einfach mal auf GCR-Ebene anzuschauen. Man sieht einfach klarer, wenn man die Geos Header- und Tailgaps gesehen hat.

Ein normaler Sektor sieht wie folgt aus (der klaren Darstellung halber habe ich den Sektorinhalt als komplett 00 angenommen und verkürzt dargestellt). Folgende Darstellungen sind g64conv entnommen:

sync 32
; header
gcr 08
begin-checksum
checksum
; sector
gcr 00
; track
gcr 12
; id2
gcr 32
; id1
gcr 31
end-checksum
gcr 0f
gcr 0f
; Trk 18 Sec 0
bytes 55 55 55 55 55 55 55 55 55 ff

sync 32
; data
gcr 07
begin-checksum
gcr 00 00 [...] 00
checksum
end-checksum
gcr 00
gcr 00
bytes 55 55 55 55 55 55 55 55 ff

Beim Geos-Sektor mit Kopierschutz ändern sich die "Füllbytes" zwischen den Sektoren:

sync 32
; header
gcr 08
begin-checksum
checksum
; sector
gcr 00
; track
gcr 12
; id2
gcr 32
; id1
gcr 31
end-checksum
gcr 0f
gcr 0f
; Trk 18 Sec 0
bytes 55 55 55 55 55 67 55 55 67 ff

sync 32
; data
gcr 07
begin-checksum
gcr 00 00 ... 00
checksum
end-checksum
gcr 00
gcr 00
bytes 55 55 55 55 67 55 55 67 ff

Kommt drau an, wie genau es der Fragesteller wissen will. Data Becker hat z. B: noch Infos, wo jeweils der Code wie versteckt ist, der die Abfrage macht.

Und wie man bei Kopien der uninstallierten App-Disk die Kopierschutzabfrage findet und so patcht, dass der Kopierschutz nicht abgefragt wird.
Es geht also schon tiefer ins Detail.

Die Frage hat Data Becker im Buch "Das große Geos Buch, 3. Auflage" sehr ausführlich beantwortet. Inklusive, wie die Kopierschutzabfragen versteckt sind.

Die dortigen Angaben zur Version 1.3 passen im Wesentlichen auch zur Version 2.0.

PS: Einen Scan des Buches habe ich gestern im Incoming der Cloud hochgeladen. Etwas Gedult, nd jeder kommt dran.

Quick testset version 634:

nib usually works. But sometimes it fails. Repeating helps.
nb2 always fails (just like version 613). Version 528 (?, the one from root.org, shows "release 528" when starting) nearly always succeeds in creating nb2.

Thanks for your new binary of nibtools.

I've let git rebase my patches to version 634.

Well, compiling nibconv without compiling opencbm is possible, you just need to copy IIRC 2 files from the opencbm source code repository, version.h and IIRR opencbm.lib. The latter beiing a binary library of opencbm.

This way for compiling nibconv you just need a recent visual studio, not anything more.

That's the whole thing. But clearly that cannot work for nibread, for which 6502 assembler has to be compiled.

Eigentlich hast Du ja sehr Recht.

Aber leider muss nibconv so nebenbei laufen. Daher wollte ich zumindest bis zu den angekündigten Änderungen von Upstream erstmal die Wahrscheinlichkeit von Merge-Konflikten im Git seknken. Und Versionsnummern sowie Namen sind immer ein sehr wahrscheinlicher Kandidat für Konflikte.

Und dummerweise ist die Versionsnummer für das ganze Toolpaket in einem gemeinsamen Source-File. Ich kann also die Versionsnummer von ninbconv nicht bspw. um ein "+" erweitern, ohne dass nibread, nibwrite, ... ebenfalls jene Änderung erfahren.

Blöder Konflikt: Entweder git kann gut mergen (ich hoffe, der Autir passt seine Versionsnummern auch mal an), oder wir haben gute Namensverschiedenheit.

Nachtrag: Noch was: Wenn man nach den o. g. Folien den Ausgabedateinamen anpasst, wird leider nicht die Version der Projektdatei aus den svn/gi angepasst. Microsoft hat die Endungen und die Formate geändert. Man hätte dann also einen Sourcecodestand, der leider nicht die Dateinamen der releasten EXEs erzeugt. Auch unschön.

In diesem Zusammenhang evtl. erwähnenswert: In meinen git-Repository https://github.com/markusC64/nibtools habe ich das ganze svn-Repository als Branch upstream gespiegelt, damit ich ggf. meine Patches besser rebasen kann. Dort kann man also auch die aktuelle Version 633 auschecken - hat dann aber die ganze History lokal vorliegen.

Gut zu wissen, aber das ist jetzt ja ein nibtools-Problem...

Ja, genau da habe ich die Folien auch gefunden. Wobei die an einer Stelle etwas umständlich sind: Wenn man soweit ist, das nibconv im "Debug" übersetzt werden kann, reicht es, aus den Einstellngen den Include-Pfad nach "Release" per Copy & Paste zu übernehmen. Keine Dateien kopieren oder so notwendig.

Ich muss es ja wissen, habe nibconv (nicht die anderen Tools) ja schon mehrfach übersetzt.

Da hast Du Recht. Offensichtlich ganz anderer Schutz. Hat der Test ja auch gezeigt. Sind die Tracks 2 bis 6 vorher defekt, werden jene beim Installieren repariert und umgekehrt.
Nun war aber vorher nicht klar, ob M&T im Zuge der Auslieferungskooperation nicht beim Kopierschutz was beigesteuert hat, aber das hat der Test als wenig plausibel dargelegt.

Außerdem habe ich im g64conv keine GEOS-Tailgaps gesehen beim erneuten Reparieren.

https : // c64preservation.com/svn/nibtools
(remote spacing, inserted to avoid autoformating by the board).
My source: The foils documenting how nibconv67 was build

The really interesting question is: How to compile nibread / nibwrite. I fear my Visual Studio 2010 does not know how to compile 6502 Assembler (the floppy routine for the 1541/1571).

I see. But why does the same disk and the same drive work with the old version of nibread?

Super doll - nibconv zeigt alles ok an, "u1 2 0 10 17" liefert den Fehler. Ich prüfe nochmal.

Habe die Gap im betroffenen Sektorheader jetzt auch angepasst. Jetzt mag VICE den zumindest. "U1"-Test erfolgreich. Außerdem installiert und dann validiert.

No probem any more. I thought I have seen track 1 unreadable yesterday, but I cannot reproduce.

But I have one other problem with nibread / nibwrite:

I have installed http://www.root.org/~nate/c64/xum1541/index.html to work with my zoomfloppy.
Then I updated nibtools with http://c64preservation.com/files/nibtools/ .

Result:

nibread from root.org image works[*][**], updated nibread fails[***]. For nibwrite it is the opposite - the new one is working better than the old one.

[*] of cause this old version needs "-s".
[**] Rarely it fails, too. But that is Rarely. Repeating the job helps in that cases.
[***] at least for nb2. nib sometimes work.

Output is below - I'm adding english translation for german messages in angle brackets:

T:\>d:\opencbm\bin\nibread testdemo.nb2

nibread - Commodore 1541/1571 disk image nibbler
(C) Peter Rittwage and the rest of the C64 Preservation Project team
c64preservation.com
Revision 2014 - Built Jul 5 2015 18:19:58

Drive Version: 73,CBM DOS V3.0 1571,00,00
Drive type: 1571
Bumping...
Initializing
Sending 1571 SRQ support code...
Uploading floppy-side code ($0457 bytes, $300-$757)...done.
Starting custom drive code...Started!
Testing communication...done.
Passed initial communication test.
Testing code upload...done.
Passed code verification test.
Passed all basic port checks.

18.0: (2)
Cosmetic Disk ID: '64'
Format Disk ID: '64'

1.0: (3)
1.0: (0) 1 2 3 4
1.0: (1) 1 2 3 4
1.0: (2) 1 2 3 4
1.0: (3) 1 2 3 4

1.5: (3)
1.5: (0) 1 2 3 4
1.5: (1) 1 2 3 4
1.5: (2) 1 2 3 4
1.5: (3) 1 2 3 4

2.0: (3)
2.0: (0) 1 2 3 4
2.0: (1) 1 2 3 4
2.0: (2) 1 2 3 4
2.0: (3) 1 2 3 4

2.5: (3)
2.5: (0) 1 2 3 4
2.5: (1) 1 2 3 4
2.5: (2) 1 2 3 4
2.5: (3) 1 2 3 4

3.0: (3)
3.0: (0) 1 2 3 4
3.0: (1) 1 2 3 4
3.0: (2) 1 2 3 4
3.0: (3) 1 2 3 4

3.5: (3)
3.5: (0) 1 2 3 4
3.5: (1) 1 2 3 4
3.5: (2) 1 2 3 4
3.5: (3) 1 2 3 4

4.0: (3)
4.0: (0) 1 2 3 4
4.0: (1) 1 2 3 4
4.0: (2) 1 2 3 4
4.0: (3) 1 2 3 4

4.5: (3)
4.5: (0) 1 2 3 4
4.5: (1) 1 2 3 4
4.5: (2) 1 2 3 4
4.5: (3) 1 2 3 4

5.0: (3)
5.0: (0) 1 2 3 4
5.0: (1) 1 2 3 4
5.0: (2) 1 2 3 4
5.0: (3) 1 2 3 4

5.5: (3)
5.5: (0) 1 2 3 4
5.5: (1) 1 2 3 4
5.5: (2) 1 2 3 4
5.5: (3) 1 2 3 4

6.0: (3)
6.0: (0) 1 2 3 4
6.0: (1) 1 2 3 4
6.0: (2) 1 2 3 4
6.0: (3) 1 2 3 4

6.5: (3)
6.5: (0) 1 2 3 4
6.5: (1) USB error in read data(0006DA1C, 8192): libusb0-dll:err
[_usb_reap_async] reaping request failed, win error: Ein an das System
angeschlossenes Gerät funktioniert nicht. <A device connected to the system does not work.>

1 USB error in write cmd: libusb0-dll:err [_usb_reap_async] reaping
request failed, win error: Ein an das System angeschlossenes Gerät
funktioniert nicht. <A device connected to the system does not work.>

USB error in xum1541_ioctl cmd: libusb0-dll:err [_usb_reap_async]
reaping request failed, win error: Das Gerät ist nicht angeschlossen.
<The device is not connected.>

USB error in write cmd: libusb0-dll:err [_usb_reap_async] reaping request failed, win error: Das Gerät ist nicht angeschlossen.
<The device is not connected.>

Resetting drive...
USB error in xum1541_control_msg: libusb0-dll:err [control_msg] sending control
message failed, win error: Das Gerät erkennt den Befehl nicht.
<The device does not recognise the command.>