Aber machen diese Befehlszeilen auch ein "verify" ?
Ja. Zumindest beim CBM Dos und bei den "üblichen" Speeder-Ersatz-ROMs für die 1541.
Eine andere Möglichkeit, das zu prüfen, ist natürlich, mit dem Modul zu formatieren (was ja scheinbar klappt) und dann mit "Master Copy 2.0" aus dem 64'er Sonderheft (Nummer müsste ich naschauen, 92 oder 96 sollte es sein) einen nachträglichen Verify zu machen. Dann bekommt man auch als Übersicht angezeigt, welche Sektoren Fehler haben und welche nicht.
Spockie Hilf mir bitte - wo ist der Konflikt?
Modem im IO1, d. h. $DE00
REU + Command Interface zusammen $DF00-$DF1F, also Teilbereich von IO2.
für mich schaut es so aus, als würden sich die IO-Seitig aus dem Weg gehen.
"if you want to use the 64k REU Buffer. (looks like there may be conflicts)" - habe ich gesehen, weiß aber nicht, ob man den braucht.
Edit: REU + Command Interface haben jedenfalls keinen Konflikt.
Hm, wenn es der Turbo von der/dem Ultimate 64 täte, bräuchte es keine SuperCPU. Die Ultiumate 64 kann 48 MHz, die SuperCPU irgendwas um 16 Mhz herum.
Allerdings die RamLink müsste dazu natürlich schon gehen...
Edit: Ich ahne allerdings, woran es hakt - Kernal Ersatz per Expansionsport... Da hat U64 ja auch Probleme mit anderen Modulen, die das vereitstellen.
Faszinierend.
Es stellt sich nur eine Frage: Klappt das auch mit dem/der Ultimate 64? Und wenn ja, hat dort der Turbomodus ähnlich gute Effekte die SuperCPU beim C64?
Nein, mangels Ramlink kann ich das nicht ausprobieren - in der Frage bin ich auf Berichte angewiesen.
Wobei die zweifarbigen LEDs aus dem genannten Shop ideal sind. Mit passenden Einstellungen bekommt man es hin, dass die alles anzeigen:
1. U64 eingeschaltet.
2. Floppy 1 Aktivitätslampe
3. Floppy 2 Aktivitätslampe
Das sieht dann bei mir so aus:
1. Habe ich durch ein grünes Dauerleuchten realisiert.
2. Blinkzyklus Grün/rot
3. Grün/aus abwechselnd blinkend (Fehler, Aktivität durch Erlöschen der LED).
2.+3. beide Fehler klappt in der Regel auch, weil die nicht exakt synchron blinken und man so wechselnd rot/aus und ggf. grün sieht.
Nicht ganz, das Format ist als Bestandteil von g64conv "dokumentiert":
PS: Der Fall "Killertrack" ist im g64conv noch nicht behandelt, da weiß ich nicht, wie Burstnibbler den im RAM ablegt (und bei der gepatchten Version somit in der REU).
Edit: "unpack ("C", ...) liefert einfach den ASCII-/Unicode des ersten Zeichen des Argumentes.
Edit 2: Vergleiche "sub reutog64" im g64conv.pl.
Ich bin auch schon am Burstnibbler ohne REU am arbeiten. So denke ich, müsste es funkrtionieren.
Die erste von 6 Teildateien wird geladen. Mit einer simplen Getbyte Routine.
Ich tippe mal drauf, dass man aus dem Inhalt der REU (aus der REU Version) jene Dateien generieren kann. Das würde bedeuten: Einmal mit einer Ultimate oder im Emulator (sofern der es denn tut) die Disk einlesen und ein REU Image erhalten.
Dann könnte man daraus am PC die Einzeldateien erzeugen und hätte beide Zielgruppen bedient - die mit Ultimate und die ohne.
Ich habe nämlich bei meiner Anpassung drauf geachtet, dass in der REU alles drin ist. Nicht nur der Trackinhalt an sich, sondern auch die Metainformationen wie Starttrack, Endtrack, Reduce Syncs, Halftracks enabled / disabled etc.
es gibt ja auch noch das XUM1541, in diesem Fall aus UK. Da eh nur eine serielle Verbindungsmöglichkeit besteht......
Die Option, kopiergeschützte Software zurückschreiben zu können, kann man sich damit ja auch offenhalten - nämlich via 1570 / 1571. Von daher st die IMO gut genug. Parallel habe ich mit meiner Zoomfloppy noch nie produktiv genutzt, mit meiner 1571 geht es seriell genauso gut.
Übrigens hat der selbstmodofizierende Code einen guten Grund - je nach erkannter Floppy werden da andere Adressen eingetragen. Bei der 1570/1571 sitzt das Parallelkabel nämlich an anderer Adresse...
Das die da natürlich eine Adresse eingetragen haben, die es "nicht gibt", ist gleichzeitig Verwirrungsstiften und Hinweis, da genauer hinzuschauen.
Das ist ein klassischer Fall von selbstmodifizierenden Code. Die Adressen da sind nur Platzhalter.
Suche in meinem Quelltext nach den Label "a2017" und Du findest Stellen, wo das gepatched wird.
Ein Parallelkabel wird wohl für kopiergeschützte Disks gebraucht
Wohl wahr. Jedoch auch, wen man auf einer leeren Diskette eine kopiergeschützes Spiel/Programm draufschreiben will. Also würde ich eher von den Fall ausgehen, dass man es dafür brauchen könnte.
Hm okay ich hab hier zwei 1541-II. Leider aber nur mit Seriellem Kabel.
Kannst ja wen im Marktplatz suchen, der eine davon für Dich umbaut. Oder alternativ eine 1570 oder 1571 besorgen. Ich fürchte nämlich, dass bei einer 1541 II der VIA fest eingelötet ist, so dass Du das Kabel nicht einfach drunterstecken kannst.
Wo ist dieses ZoomFloppy denn erhältlich ?
Dazu kann ich gerade nicht allzuviel sagen - ich habe meine ZoomFloppy vor ein paar Jahren aus den USA. Geht, aber der Versand inkl. Einfuhrumsatzsteuer ist ziemlich teuer. Da wird jemand anderes sicher mehr wissen.
Ich denke, ich habe den Patch gefunden:
Du hast Adresse $0C58 von $0E nach $0F geändert. Das sieht mir danach aus, als sei es für die Scanroutine.
Nun denn, dazu gehört folgende Quelltextzeile:
662 0c57 a90e sPortInUse LDA #<a0E
dank des Labels ist die sehr einfach zu finden im Quelltext.
Die übrigen Änderungen habe ich direkt mit der Kopierschutzabfrage sowie einer Cheksummenbildung gegen Modifikationen in Verbindung gebracht, so dass ich die ausschließen kann.
würde ich es halt eher in Betracht ziehen, irgendwo ein Gerät mit USB zu kaufen, welches 5,25" Disketten lesen kann.
Dazu nimmt man eine sog. Zoomfloppy https://www.c64-wiki.de/wiki/ZoomFloppy , die man per USB mit dem PC verbindet und an der man die 1541 / 1570 / 1571 anschließt. Im Falle der 1541 idealerweise sowohl seriell als auch parallell. Bei der 157x reicht seriell.
Gestartet wird das Programm ab $0900
Also quasi Burstnibblerstandard. Autostart und Basicstart sind ja nur Komfortfunktionen.
Nun denn, dann hacken wir den Crack...
Kann es sein, das Burstnibbler die Ports $DE00,$DF00 scannt (beschreibt) und deshalb die Daten schrottet?
Kann gut sein. An dieser Stelle ist das Verhalten das des original Burstnibblers. Für eine GeoRAM ist das ggf. ein Problem (hängt von Details ab). Das wäre also auch zusätzlich zu bedenken.
Du hast nicht zufällig die Adressen, die das im original Burstnibbler sind? Dank Listing "im ACME-Spech "report") findet man die Quelltextzeilen dazu dann ja schnell wieder.
Das wäre die Kategorie Änderungen, die per bedingter Assemblierung rein kann, so dass man die dann in die PRG Datei aufnehmen kann, aber nicht muss.
1,2 MB sind da aber nicht drauf. Pro Seite 170 KB.
Mit einer 1541 / 70 / 71 stimmt das natürlich. Mit einer PC Floppy wären da aber schon 180K pro Seite drauf. Und mit einer SFD 1001 hat man 2083 Blöcke pro Seite, also ca. 520 K pro Seite.
Sprich: Der Datenträger selbst gibt mehr her. Das die 1541 das nicht voll ausnutzen kann, ist nicht Schuld des Datenträgers. Dessen Kapazität ist offenbar mindestens 520K pro Seite.
Ich habe es nicht extra erwähnt, aber GeoRAM / NeoRAM statt REU tut es auch, der Code im Burstnibbler 1.9r+ erkennt das selbst.
Bei GeoRAM gibt es das analoge Problem mit dem partiellen Löschen bei der Erkennung jedoch auch...
Ich schaue mal demnächst, dass die Erkennung ohne Datenverlust geht. RAM haben wir ja genug, 12k frei ist ja direkt Luxus.
In der Version ohne Ramerweiterung dagegen ist freier Speicher Mangelware.
Wenn schon nicht mehr die Originale drauf sind, kann man sich ja dann immernoch für eigene Programme weiterverwenden.
Je nach vorhandener Hardware und Kopierschutz lassen sich die Originale auch wieder draufschreiben. Die meisten sind ja bereits archiviert worden.
Punkt zwei kommt selten vor - kann aber bei Vorhandensein eines Magnetfeldes hinreichender Stärke passieren. Dann kann man das neu formatieren und gut.
Auf der anderen Seite kann nichts schlimmes passieren, wenn Du es versuchst. Im schlimmsten Fall darfst Du danach den Schreib-Lesekopf mit Wattestäbchen und Isopropanol säubern. Mehr kann nicht passieren.
Hm, ich denke, eine kleine Abwandlung davon macht Sinn:
Im Emulator liest man das Image ein. Zum REU Inhalt sichern haben wir hier im Forum ja bereits eine Software.
Auf den C64 gibt es zwei Möglichkeiten: Hat man eine 1541 Ultimate oder einen Ultimate 64, so reicht es, Burstnibbler zu laden und dann per Ultimate den REU-Inhalt wiederherzustellen. Anschließend kann man das Image mit "write disk" zurückschreiben.
Hat man das nicht, sondern lediglich eine echte RAM-Erweiterung, so müsste man aus dem Code die Detektion rausnehmen, damit der REU-Inhalt nicht beim Start zerstört wird. Dann würde es reichen, mit besagter Software den REU-Inhalt vorher wieder einzuladen und gut.
Vielleicht sollte ich die Größendetektion mal so anpassen, dass die den REU-Inhalt nicht zerstört. 
Das Problem ist nämlich in der Tat, dass der Code in der Floppy geladen ist, so dass man darauf nicht so direkt zugreifen kann.
Anderseits ist der Programmquelltext frei verfügbar und wir haben auch noch einige Kilobyte an ungenutzten RAM für Programmcode (bis $5D00 ausschließlich darf das Programm groß sein, im Moment gehen wir bis weniger als $2D00 - also haben wir noch 12k zur freien Verfügung).
