WARP 9 (Track/DiskCopy for two Drives)

WARP 9

der versuch alt bewährtes ins neue jahrtausend zu bringen.

nachdem ich vor einigen wochen mit hilfe des forum64 meinen c64 wieder zu 100% herstellen konnte,
habe ich mich inzwischen an ein kopierprogramm gewagt und eine erste pre-release fassung fertig gestellt.

ein paar optionen fehlen noch oder sind nur teilweise integriert. auch das error-handling ist noch nicht ganz
vollständig. so kommt es hin und wieder zu programm-aufhängern wenn vorher 'EX-DOS' gestartet wurde
und dieser daten über den iec-bus gesendet hat.

bis auf diese ausnahme ist WARP 9 aber inzwischen recht stabil und voll einsetzbar. die hauptfunktion -
das kopieren von tracks/disketten - ist voll funktionsfähig.

wie ihr schon gelesen habt, handelt es sich bei WARP 9 um ein track/diskcopy-programm für zwei floppy-
laufwerke mit dem sich relativ schnell und sicher kopien von disketten erstellen lassen. es ist bestimmt nicht
das schnellste aber doch sehr sehr fix. daher der name WARP 9

ein schelm der an StarTrek, Scotty & CO dabei denkt!

ich habe bewusst auf alles unnötige verzichtet. mein programm ist weder gepackt noch erschlüsselt. noch wird
ein run-stop/restore unterbunden oder sonst wie versucht es vor unerwünschten einblicken zu schützen. ein patchen
zum anpassen der farben ist auch nicht nötig. dazu gehe ich aber weiter unten noch genauer drauf ein.

benötigt werden wie schon geschrieben: zwei standard-laufwerke 1541 und/oder 1541-II und die entsprechenden
iec-kabel um sie mit dem c64 zu verbinden.

in meiner test-konfiguration habe ich ein 1541-lfwk(id:8) neuerer bauart, also mit knebel und gehäuse-farbe komplett
in beige und eine 1541-II (id:9) angeschlossen. zusatzlich hängt noch ein SD2IEC-lfwk(id:10) an meinen system mit
dem ich das programm in den c64 lade. da ich die komplette entwicklung/assemblierung etc. mittels CBM-Studio auf
einem windows-notebook mache.

ziel und quell-laufwerk (src./dst.) können eingestellt werden. ebenso auch der track-bereich von 1-35 respektive 40.
die tracks 36-40 sind aber in der pre-version noch nicht wählbar, da mir noch einiges an gesicherten informationen
zu diesem track-bereich fehlt.

als weitere optionen stehen noch ein reset für die angeschlossenen laufwerke (src./dst.) zur verfügung
(in der pre-version ist das zur zeit noch ein einfaches 'initialize'-kommando).

ausserdem gibt es später noch eine möglichkeit per software-lösung die ID einzelner laufwerke zu ändern.
(in der pre-version ist das noch nicht implementiert und wird mit einem hinweis darauf auch angezeigt)

ein blick auf den disketten-inhalt für das quell/ziel-laufwerk ist ebenfalls eingebunden und kann zur zeit über
die tasten (+/-) aufgerufen werden. da mir das aber so noch nicht gefällt und auch das error-handling noch
nicht implementiert ist, kann und wird sich da noch einiges ändern. es gibt ausser diesen hier, auch sonst
keinen weiteren hinweis auf diese noch 'hidden'-option.

für die farb-freaks unter euch habe ich die möglichkeit der kreativen farbgestaltung geschaffen. für die fünf
elemente hintergrund, rahmen, text, cursor und applikation lassen sich individuell die farben einstellen und speichern.

die preferences (settings) dafür habe ich einer REM-zeile untergebracht. nach dem einladen des programms und
einem 'LIST' können die werte verändert und mit einem abschliessenden 'SAVE' etc.. dauerhaft gesichert werden.

man sollte nur darauf achten, das sich die länge der aufgelisteten programmzeile nicht verändert, da sonst der
SYS-einsprung nicht mehr stimmt. ich habe bewusst eine zeilenlänge von genau 40-zeichen gewählt, damit beim
editieren sofort zu sehen ist ob sich deren länge verändert hat. in der regel wird man hier aber die werte nur
überschreiben und dadurch die zeilenlänge nicht weiter verändern. diese art der preferences sollte also für einen
versierten c64-hacker kein problem darstellen.

anpassen lassen sich neben den 5 farbwerten am ende der REM-zeile auch das quell/ziel-laufwerk und der track-bereich.
alle parameter sind durch ein trennzeichen (-) optisch von einander getrennt.

ein paar farb-beispiele und wie die REM-zeile aussieht ist hier in einigen GIF-bildern zu sehen.

wer auch immer 'WARP 9' regelmässig nutzt, in meiner arbeit an diesem programm also eine sinnvolle investition sieht und das gerne honorieren möchte.
kann dies vorzugsweise gern über PayPal in die wege leiten.

zum schluss noch das PRG: warp9pre.prg

M G und viel spass beim kopieren

rijo...

Zitat von Hucky

wie lange braucht das Programm um eine Seite zu kopieren ?
Passiert das in einem Rutsch, Track für Track, oder mehrere in Speicher und dann auf Zieldisk ?
Werden Sektorfehler einfach mitkopiert ?

Hucky

1.) mit WARP faktor 9 gut eine 1 sek. pro track. summasummarum ca. 41 sek. bei einer standard-diskette mit 35 tracks.

"bei WARP faktor 9,5 fängt scotty an zu meckern weil der gravimetrische feldverschiebungs-antrieb zu heiss wird und eine
WARP-kernschmelze zu befürchten ist. aber ein viel grösseres problem ist die kabel-führung von laufwerk zu laufwerk. wenn
die bits in dieser affenartigen geschwindigkeit durchs kabel sausen, kommt es unweigerlich zu hohen reibungsverlusten an den
innenwänden der kupferleitung. die bits werden ebenfalls zu heiss und verlieren nach und nach an masse. bei zu langen kabeln
kann es dann passieren, das letztendlich nichts mehr am ziel ankommt. das wäre zu blöd!"

2.) in einem durchgang, track für track, von laufwerk zu laufwerk, ohne umweg über den c64. der macht währenddessen
nur das bus-scanning und zählt die blöcke mit um zu sehen wann der kopiervorgang abgeschlossen ist.

3.) ich hoffe nicht und hab es bis jetzt auch noch nicht provoziert. ich sehe zu, das meine disketten alle fehlerfrei sind.
original disketten die aus kopierschutzgründen bewusst mit solchen sektorfehlern versehen sind. werden vorher von mir
geknackt und der kopierschutz aus dem jeweiligen programm entfernt.

Zitat von Meikel

Tolle Arbeit. Gefällt mir.

schönen dank, Meikel!

mfg rijo

@ Hucky

ich mach das auch nur aus eigennutz. hab hier noch mehrere hundert disketten und genügend laufwerke.
schon allein dafür macht dieses programm noch ordentlich sinn und ist gut zugebrauchen.

mfg rijo...

Zitat von CypherXG

Wird es evtl auch 'ne Möglichkeit geben von einem SD2IEC ein D64 Image auf 'ne Disk zu schreiben?

gibt es denn da nicht schon längst was?! hab mich lange nicht mehr darum gekümmert.
die idee hatte ich zwar schon. gerade weil meine ersten konvertierungen mit CBM-command so grotten langsam waren
11 minuten für eine diskette und das im jahr 2016. bin jetzt aber erstmal damit beschäftig aus WARP 9 eine WARP 9.1
version zu basteln. gestern habe ich die letzte noch offene funktion eingebaut (change device-id). die funktioniert jetzt
auch erstmal. damit ist nun alles implementiert, was ursprünlich auch geplant war. ist aber immer noch im pre-release
stadium. denn ich muss mich noch auf die suche nach dem hänger machen der sich hier ab und zu in verbindung mit der
1541-II bemerkbar macht. bin da immer noch total blind und kann mir beim besten willen nicht erklären wo der herkommt.
in der regel hilft dann nur ein radikaler hardreset aller lfwke. ausserdem ist mein gesamtes error-handling noch total
katastrophal. hier muss auch noch einiges getan werden.

dann sind da noch die vielen anderen ideen, wie die filecopy.- und format-funktion aus duplicater-III. die ich
gerne umsetzen und einbauen will. oder track/diskcopy für ein laufwerk, falls nur eins angeschlossen ist.
der 'EX-DOS'-diskdoctor hat auch ein paar schicke features, die man umsetzen könnte, etc...

mal sehen wo es hin driftet...

mfg rijo...

Zitat von GI-Joe

Obwohl es von diesen Programmen ohne verify ja schon tonnenweise gibt, z.T. auch sogar ganz Gute ....

ein paar namen und was deren vor/nachteile sind, wären ganz gut. ich bin da nämlich schon eine weile raus. zu meiner zeit,
also von 1984-1988. waren der turbonibbler V2.2 und V4.0 das einzig wahre. für 'filecopy' kam damals nur der duplicator-iii
in betracht. alles andere war in der regel rausgeschmissene zeit. eine handvoll der einigermassen brauchbaren tools waren
damals unnötig in programm-pakete implementiert. die meisten hacker haben immer GANZ GANZ viel aufwand in ihre bootmenues
inverstiert und es dem gemeinen anwender durch miese tricks richtig schwer gemacht an das geeignete programm zukommen.
da nervte es recht schnell, immer erst irgendein bootmenu laden zu müssen um eins der tools zu starten.

insofern kenn ich nicht viele (wirklich gute tools). bei mir ist noch 'Ultrabyte' im kopf hängen geblieben. 'SirCopy' soll wohl noch
ganz gut sein, das kam aber erst einige jahre nach meiner c64-zeit raus. für ein verfy und einer reparatur von disketten gibt
es auf dem c64 meiner meinung nach nichts besseres als 'EX-DOS'. das hat sich in den letzten knapp 30 jahren hier immer wieder
bei mir bewährt. aber letztendlich bin ich selbst das beste kopierprogamm und '$MON', ' EX-DOS' und 'warp 9' helfen mir nur dabei.

ich hab damals viel viel geld für midi-software ausgegeben und die eine oder andere anwendung auch selbst geschrieben. ich denke dabei
gerade an eine sound-bankverwaltung für den synthesizer yamaha-dx7. von der man, wenn ich sie mir heute ansehe, nicht glauben möchte,
das ich sie schon 1986/87 geschrieben hab. anbei mal ein paar bilder von den beiden hauptseiten und einer hilfe-page dieses programms.

software wie z.bsp. die von Steinberg (Pro16 etc..), war aufgrund ihrer speziellen anwendung eher im professionellen bereich angesiedelt und dementsprechend teuer.
ein paar hundert mark für ein programm war keine seltenheit. daher war ich oft gezwungen mir selbst zuhelfen, denn sowas gab es in der damaligen hacker-scene
so gut wie nie als crack. die darin verwendeten kopierschutz-funktionen waren meistens auch nicht von pappe. da half dann auch kein nibbler. ich hab damals
zur sicherheit, um davon kopien machen zu können, alles geknackt was wir gekauft hatten. damit dem einen oder anderen aus der semiprofessionellen
musik-scene, die hier in berlin in den 80'zigern elektronische musik gemacht haben, vereinzelt auch deren bühnen-auftritt gerettet. weil beim soundcheck auf
der bühne plötzlich der strom genau im richtigen moment ausfiel und danach die diskette nicht mehr lesbar war. mit einem original im laufwerk hätte das ein
blödes ende gegeben, so war nur ein kopie zerschossen. aber ich schweife hier gerade mal so richtig ab. zurück zum thema...

...aus einer solchen situation heraus ist damals der vorgänger von 'warp 9' entstanden. auf der bühne schnell noch eine kopie machen! es geht gleich los!

Zitat von GI-Joe

Macht Dein Programm eigentlich Data-Copy oder Nibble-Copy ?
Bei Data-Copy wäre IMHO noch eine "Format Target"-Option = ON/OFF nicht schlecht

wann und warum wäre das denn sinnvoll? gibt es da ein beispiel, wann ein format nicht sinnvoll ist?

in seiner hauptfunktion ist es ein backup-programm für standard-disketten, also data-copy. durch das trackweise kopieren war es
natürlich einfach auch noch eine option einzubringen, die es erlaubt auch tracks über 35 zu kopieren. es liest sozusagen block für block
und schreibt track für track. dabei wird, bedingt durch das verfahren, auch gleich trackweise formatiert. letztendlich will/wollte ich damit
auch erreichen, das die magnetschicht der diskette gleich mit aufgefrischt wird. insofern finde ich es nicht sinnvoll die format-funktion
abzuschalten. aber vielleicht gibt es ja einen grund, den ich jetzt nicht kenne, wo die abschaltung sinnvoll ist?

mein eigentliches anliegen ist und war es, das ich ein schnelles und mögllichst kleines backup.prg für meine wichtigen
song-disketten habe. das ich ohne viel zip und zap ruckzuck in den rechner laden und nutzen kann .
ich habe relative viel musik in form von midi-recording mit steinbergs pro16 auf dem c64/sx64 gemacht und da
ich lieber musik machen wollte, war das backuppen ein notwendiges übel mit dem man ungern viel zeit verbringt.

mit der zeit stellte sich heraus, das ich mit dem damals noch vorgänger von 'Warp 9' relativ schnell und sicher kopien
erstellen konnte. das verfahren wie ich mache ist dabei immer noch das gleiche wie vor fast 30 jahren. ich kopiere
eine ganze anzahl von disketten mit 'Warp 9' . frische durch das gleichzeitige formatieren die backup-disketten wieder auf
und überprüfe in einem 2'ten gang mit 'EX-DOS' ob die daten gut angekommen sind. in 'EX-DOS' nutze ich dafür die
BAM-funktion und checke mittels 'exttended BAM' das kein track einen fehler hat. das geht extrem schnell und ist
meinem wissen nach soger schneller als jedes verify. bis dato war diese verfahren auch immer erfolgreich und ich
hatte nie irgendwelche nennenswerte fehler beim kopieren. daher auch meine iidee sowas noch in 'warp 9' unterzubringen.

in einem weiteren schritt, der aber nicht mehr unbednigt nötig ist, da die BAM-funktion in der regel die gleichen fehler ausgibt,
rufe ich hin und wieder noch das erweiterte Directory in 'EX-DOS' auf um dort die funktion 'trace' auszuführen. die überprüft
nochmal die verlinkten blöcke der einzelnen dateien auf konsistenz. wenn man also 'ABSOLUT' sicher sein will das die kopie erfolgreich war.

mfg rijo...

Zitat von GI-Joe

Die Dinger als OneFiler zu rippen ist ja nicht gerade die schwierigste Aufgabe (siehe z.B. Anhang)

JA! mit einem abstand von fast 30 jahren und dem heutigen hintergrundwissen, was man sich inzwischen problemlos aus dem netz ziehen kann, sehe ich das auch so!
nur 1985 gab es das alles noch nicht und sein wissen musste man sich mühselig selbst erarbeiten. da war das mit dem rippen und den nötigen tools die man dafür brauchte
noch nicht so einfach.

Zitat von GI-Joe

Bei reinem Data-Copy ist ein Format nicht nur sinnvoll sondern IMHO dringend zu empfehlen, da oft der Zustand/die Magnetisierung der Zieldisk unbekannt ist.

sehe ich auch so! nur verstehe ich dann deinen wunsch nach einer 'format-target-option' nicht so ganz?

Zitat von GI-Joe

Bei Data-Copy wäre IMHO noch eine "Format Target"-Option = ON/OFF nicht schlecht.

wann/wo/warum ausschalten?

PS: was ich noch fragen wollte! sind die von dir angehangenen copy-programme ähnlich schnell wie 'warp 9' und auch ohne hardware umbauten (parallel-kabel etc..) nutzbar?

mfg rijo...

@Ace von Heisenberg
knapp unter 40 sekunden. bei mir sind es 39,7 sek. in verbindung mit einer 1541c und einer 1541-II.
die 1541-II ist hardware-technisch ein kleines bissle träger als die 1541c.

mfg rijo...

@GI-Joe

im 2'ten pre-release von 'warp 9' habe ich den cia2 tod-clock timer zur messung verwendet.
da werden auch die init-zeiten mitgerechnet und nach dem kopiervorgang oben rechts in der kopfzeile von 'warp9' angezeigt.
das sind identische zeiten wie du bei 'maverick 1541_dual_data_copier' ermittelt hast. ca. bei 41,5 sek.

in meiner aktuellen fassung von 'warp 9' startet der timer erst nach dem übertragen der
floppy-routinen und dem initialisieren der floppys. da legen die zeiten bei ca. 39,7 sek.

ich wollte einfach etwas genauer wissen wie lang der eigentliche kopiervorgang wirklich ist.

mfg rijo...