WIP: cbmHDscsi64 - Neues Management Utility für CMD-HD

Bevor hier aller Kritiker schreien "Das gibt es doch schon!" - Ja... ihr habt recht

Und dazu kommt: Das ganze Projekt brauch ich selbst nicht wirklich, da ich mit 3x SD2IEC wesentlich mehr Spaß habe

Es gibt natürlich die Originalprogramme von CMD um die CMD-HD zu formatieren, aber wenn es um ein extern angeschlossenes SCSI-Laufwerk geht wird es schon komplizierter.

Ja, es gibt die HD-ZIP(AL)-Utilities, es gibt SCSIConnect (das ich schon für den C64 und GEOS adaptiert habe) und irgendwie bekommt man externe Medien vielleicht irgendwie formatiert. Aber hier&da muss man noch Tasten an der CMD-HD drücken... manches läuft nur am C128 oder man muss erst Programm <A> starten um Programm <B> nutzen zu können...

Hab mir extra ein paar neue Original verschweißte ZIP-Disketten bestellt... interessant das es das noch gibt.

cbmHDscsi64 ist jetzt eher ein "proof-of-concept". Ich will einfach mal sehen was man machen kann und wie die CMD-HD funktioniert. Das Programm ist nicht optimiert und daher relativ langsam. Aber mir geht es erstmal um die Funktionen... und mit dem TCv2 geht das einigermaßen.

Hab für mich selbst auch eine SpeicherMap der HD erstellt. Evtl. gibt es da schon andere, müsste ich mal abgleichen. Aber das wichtigste: man muss an der CMD-HD (bis jetzt) keine weiteren Tasten drücken (Installations- oder Konfigurations-Modus). Selbst das formatieren geht ohne den im Handbuch beschriebenen "Installation mode". RAMLink-PP-Kabel ist evtl. noch ein Problem... -> ToDo.

Das Programm ist komplett in BASICV2 geschrieben (Ausnahme etwas ASM-Code der direkt in der CMD-HD ausgeführt werden muss). Am C128 könnte es funktionieren

Ziel ist es einfach eine CMD-HD und ein SCSI-Gerät auszuwählen, das anschließend formatiert wird. Weitere Ziele sind Partitionen erstellen/löschen und Partitionen zwischen SCSI-Geräten am gleichen Bus zu kopieren. Mit dem Wissen das ich in den letzten Wochen gesammelt habe sollte das möglich sein. Vielleicht sogar eine Umsetzung unter GEOS... BASIC ist da, was den Speicher angeht, doch sehr begrenzt.

Nur die Arbeit macht mir da einen Strich durch die Rechnung, gibt wichtigeres als das Hobby. Daher hier nur mal ein paar Samples...

Zum testen gibt es aktuell noch nichts... ist erstmal eine lokale Spielerei...

Aktueller Stand: Formatieren funktioniert auf SCSI2D(intern) und IomegaZIP(extern). Gibt noch ein paar Bugs... aber das "grün" ist geil

Das ist merkwürdig, hab ich "angehängt" und dann per Vorschau eingefügt. Wenn ich angemeldet bin sehe ich die Bilder auch im Text. Aber wenn ich die Seite über einen privaten Tab anonym lade, dann sehe ich die Bilder nicht.

Ich hänge die nochmals dran... ohne Vorschau...

P.S. Jetzt gehts... Evtl. kann ein Mod die Bilder im ersten Post löschen, doppelt muss ja nicht sein, vor allem wenn es nicht geht.

Zitat von skern

Hallo Leute, da kann ich eventuell was dazu steuern.

Hab ja auch ne menge in v2 gemacht,...

Was denn genau? Ich glaube das meiste ist mir zwischenzeitlich klar. Falls Du aber Lücken in der SystemMap füllen kannst...

Zitat von Juergen Johannes

Ein funktionierendes Programm, aus all den vorhandenen Progrämmchen, zu bündeln und die beschriebenen Unzulänglichkeiten zu beseitigen, finde ich "Klasse".

Zitat von C=Mac

Super alles aus einer Hand ohne zuerst Programm xyz zu suchen, welches dann aber nicht mit dem ZIP will oder nur mit Rechner zyx läuft.

Das tut es ja bereits... die ZIP-Diskette glüht hier ja schon fast von den vielen FORMAT-Versuchen

Hab mir aktuell eine WIPE-Funktion eingebaut, die den Anfang der Disk überschreibt. Bei leeren/neuen (internen) Disks muss man die HD in den Installationsmodus schalten, sonst blockiert die leere Disk den seriellen Bus wenn man zwischendurch an der HD einen RESET durchführt.

Hab das gerade nochmal getestet: Wipe der internen SD2IEC... Reset... HD "hängt"... Installationsmodus... cbmHDscsi64 -> AutoFormat... alles gut

Zitat von C=Mac

Bis jetzt ist mir nur der SCSI-Manager bekannt der dies kann.

Dieser benötigt aber ein C128 mit 64 kB VDC und läuft nicht unter MP3.

Da ist meine Idee evtl. eine andere... einen VDC kann ich gar nicht voraussetzen. Ist eh unnützer Kram

Zitat von Larry

Ich hoffe nur, dass am Ende keine Version dabei rauskommt, die nur mit GEOS läuft.

Natürlich habe ich nichts gegen eine zusätzliche Version für GEOS.

Es ist ja aktuell ein BASIC-Programm. Ohne extra Assembler-Code (bis auf Code der in der HD selbst abläuft), kein POKE (nur Bildschirm-Farbe), kein PEEK, kein SYS.

Das einzige Problem ist der Speicher: Unter BASIC geht nicht "All-in-One", unter GEOS schon... da hat man Speicher satt... unter BASIC mach ich da ggf. doch einen Mehrteiler draus: Formatieren, Partitionieren und Kopieren.

Aktuell räume ich den Code auf und ergänze Kommentare...

Das Programm wird aktuell unter Linux mit "GEANY" als Texteditor erstellt. Glaube nicht das es da ein Syntax-Highlighting für C64-BASIC gibt, aber mit dem ASM-Modus komme ich ganz gut zurecht.

Die Text-Dateien werden dann über ein bash-Script zusammengeführt und mit 'petcat' in ein BASIC-Programm umgewandelt. Danach geht es über das SD2IEC zum C64...

Zitat von skern

wiso formatierst Du die beweglichen Medien?

Ich hab selbst mehrmals ein Medium mit unterschiedlichen Offsets "gelöscht". Wenn die HD Überreste gefunden hat -> Dann hängt die HD beim Reset.

Format nutze ich nur um 100% sicherzustellen das auf dem Medium kein Rest von einem früheren OS vorhanden ist. Scheint aber bei SD2IEC evtl. nicht zu funktionieren.

Zitat von skern

Wenn ein bewegliches Medium welches formatiert ist benutzen möchte, muss ich sie einhängen und kann dann nicht auf meine Platte zugreifen.

???

Die hier diskutierte Variante sieht jedes Medium als eigenständiges Laufwerk. Ja, wenn keine ZIP-Disk im Laufwerk liegt und ZIP das aktuelle Laufwerk ist, dann gibt es Fehler. Aber da ist man selber Schuld.

Zitat von skern

Wenn Du Partitionen kopieren möchtest, solltest Du die Daten der Partition mit SCSI kopieren.

Das ist der Plan... "S-C"-Befehle und SCSI READ/WRITE.

Zitat von skern

Die Speichermap ist auf dem Medium? Besitzt Du eine Speichermap des RAM?

Die Speichermap ist eine Karte der Daten auf einem CMD-formatierten Medium/Disk. Da gibt es im Bereich $xx:0400-$xx:05ff einige Adressen die noch "unknown" sind... Es gibt also einige Bytes wo ich nicht weiß was die machen... Die werden aber aktuell analog zu llformat/create.sys initialisiert.

Zitat von Nelson

Tolle Sache! Bin in CMD-HD noch recht neu. Habe die HD erst einmal gegen eine SCSI2SD getauscht. Hat ewig gedauert die richtige Config zu finden und alles einzurichten. Externe Geräte sollen folgen.

War hier relativ einfach (scsi-utils unter LINUX als root starten), danach llformat und create.sys. Aber das drücken der Tasten... nei nei...

Zitat von skern

Ich meine vom c64 aus ist doch nur ein Gerät da und die firmware kann doch nicht fremde Tabellen auf andere Medien anwenden.

Theoretisch könnte man am Anfang ein Tabelle erzeugen, die verschiedene Laufwerke gleichzeitig einbindet. ??

Ich vermute wir haben hier ein sprachliches Problem, ich beschreibe das mal etwas genauer:

Die "Tabelle" die ich hier erstellt habe beschreibt nur den Aufbau der "System area" der CMD-HD auf dem Laufwerk. Dieser Bereich auf der CMD-HD wird ja durch "CREATE SYS" und "REWRITE DOS" erstellt.

Dort ist auch die Gerätetabelle enthalten ($xx:0500 - $xx:05DF).

Bei der CMD-HD gibt es zwei Möglichkeiten den Speicher zu erweitern:

1) "ADD DRIVE"

Dabei wird der Speicher eines weiteren SCSI-Laufwerks (SCSI-ID 1-6) der internen Festplatte (SCSI-ID 0) hinzugefügt. Das Laufwerk wird dann der Gerätetabelle bei $xx:0500 der 'System area' hinzugefügt.

Nachteil: So wie ich das verstehe kann man ein Wechselmedium später nicht wechseln da Teil des gesamten Speichers. Aus meiner Sicht heute nicht mehr sinnvoll, da selbst eine 1Gb-SD-Karte mehr als genug Speicher bietet. Früher konnte man damit eine 20Mb-Festplatte mit einer zweiten 20Mb-Festplatte auf gesamt 40Mb "erweitern" (in etwa ein "RAID 0").

2) Austausch des aktiven SCSI-Gerätes

Dabei wird temporär das aktive SCSI-Gerät gewechselt. Dabei hängt z.B. ein IomegaZIP am externen DB25-SCSI-Anschluss. Über verschiedene Programme (scsiConnect, HD-ZIP, geoHDscsi) wird die interne Festplatte (SCSI-ID 0) abgeschaltet und das externe Laufwerk (z.B. SCSI-ID 5) eingeschaltet und aktiviert.

Das externe Laufwerk ist für die CMD-HD jetzt eine eigenständige "Festplatte". Man kann dann jederzeit ein anderes Wechselmedium einlegen. Beim ausschalten der CMD-HD wird aber immer die interne Festplatte wieder als Standard eingestellt.

Auch auf dem externen Gerät braucht es jetzt die System area inkl. Partitionstabelle. Ohne die System area verhält sich sonst eine ZIP-Diskette wie eine unformatierte Festplatte im inneren der CMD-HD.

"Formatieren" wäre evtl. nicht notwendig wenn das Medium vorher schon beschrieben war. Die Wechselmedien sind ja in der Regel bereits formatiert. Wer sich die Zeit sparen will kann in meinem Programm das "Manual format menu" verwenden. Da hat man die Möglichkeit das formatieren zu überspringen. Es werden dabei dann aber auch keine defekte Blöcke über SCSI "REASSIGN BLOCKS" markiert (das ist das VERIFY in LLFORMAT).

Das erstellen der Partitionstabelle ist aber erforderlich. Die wird ja auf dem Medium gespeichert. Jedes Wechselmedium hat seine eigenen Partitionen.

Zumindest die Kennung "CMD HD"ff. muss in der System area vorhanden sind, da Programme wie "scsiConnect" prüfen ob es eine gültige System area auf dem Laufwerk gibt, bevor dieses als aktives Gerät angemeldet wird.

Die Gerätetabelle der internen Festplatte wird nicht verändert, d.h. nach einem RESET ist immer wieder die interne Festplatte aktiv.

Das ist alles nichts neues, das Programm "scsiConnect" gab es schon 2003. Ich hab das jetzt nur an den C64/GEOS angepasst und mit cbmHDscsi64 geht es nun darum die externen Wechselmedien so vorzubereiten, das diese wie eine eigene Festplatte genutzt werden können. Und das möglichst einfach.

P.S. Die Wechselmedien werden auch nicht jedesmal formatiert, sondern nur 1x. Danach kann man jederzeit mit scsiConnect oder geoHDscsi zwischen der internen Festplatte und dem externen Laufwerk wechseln. Das geht ja schon seit 2003...

Beim Backup geht es dann vorerst nur darum einzelne Partitionen zwischen dem internen und dem externen Laufwerk zu sichern bzw. wiederherzustellen. Es geht nicht um 1:1 Backup des gesamten internen Laufwerks. Das würde ich dann über SCSI READ/WRITE und den internen Puffer der CMD-HD erledigen. Der SCSI-Manager kann das wohl auch, kann ich aber auch nicht testen weil wieder nur für C128 und nicht C64.

Im Prinzip ist das wie ein Backup einer Partition von der internen Festplatte der CMD-HD auf ein anderes Gerät (wie eine CMD-FD oder ein SD2IEC).

Zitat von skern

Eben einhängen von zb. id 6 hängt 0 aus und damit ist der zugriff weg.

Das ist etwas missverständlich. Man wechselt das Medium das am C64 "sichtbar" ist. Ob das Medium ausgeworfen wird hängt vom Programm am. geoHDscsi z.B. macht das nur noch optional. Man kann aber beliebig oft hin und her wechseln.

Zitat von skern

Der Nachteil ist das man nur die vor gegebenen Partitionen verwenden kann. was aber bei mir nie ein Problem war.

Und ich denke das ist der Unterschied: Ein @$=p zeigt nur die Partitionen des aktiven SCSI-Gerätes an. D.h. jedes Medium hat seine eigene Partitionstabelle.

Das ist aber genau das worum es hier geht und alle die z.B. geoHDscsi verwenden auch so kennen.

Man kann aber trotzdem auf beide Laufwerke über die SCSI-Befehle zugreifen. Und da setzt dann der SCSI-Manager an der dann auch Partitionen zwischen beiden Geräten kopieren kann.

Die "S-C"-Befehle der CMD-HD sind da sehr flexibel. Da man hier auch die SCSI-ID angibt kann man da bequem Daten zwischen den Geräten kopieren. Lesen und Schreiben ist hier kein Thema mehr. Den "data-out" Puffer dann zum "kopieren" zu verwenden sollte dann kein Problem mehr sein.

Theoretisch kann man sogar einzelne Dateien zwischen beiden Geräten kopieren. Das halte ich aber auf Grund der vielen Gerätewechsel für wenig sinnvoll.

Deine Vorgehensweise erinnert mich eher an ADD DRIVE. Da werden ja auch Laufwerk der Tabelle hinzugefügt. Jedes Medium "ersetzt" quasi das zuvor eingelegte Medium 1:1. Löscht man aber einmal eine Partition und erstellt eine neue mit unterschiedlichem Format passen die anderen Disketten nicht mehr. Sehe ich das richtig?

P.S. Falls ja, dann kann man zwar Partitionen ohne Zusatzprogramme zwischen den verschiedenen Geräten kopieren, muss dafür aber ein starres Partitionslayout für alle Wechselmedien verwenden.

Kleines Status-Update:

Partitionen anlegen:

Partitionen kopieren:

Brauchbare GUI für beide Aufgaben:

Das war jetzt nur Testcode, und kopieren von 1581(sd) nach 1581(zip) dauert auch knapp 45sek. Ich glaube SCSIManager war da schneller, da hatte mal jemand Zeiten angegeben... Aber ist in BASIC und eher auf lesbaren Code optimiert und sehr rudimentär. Aber es geht. Aber evtl. hat hier auch mein TC64 geholfen und am puren C64 dauert es minimal länger...

SCSI-Source/Target setzen, Partitionen festlegen... starten.... die Daten gehen dabei nur über den internen Buffer der CMD-HD, es wird also nichts zum C64 übertragen.

Das erstellen von Partitionen geht auch auf dem nicht aktiven Laufwerk.

D.h. grundsätzlich scheint jetzt alles zu funktionierten.. ohne Tastendrücken (mit Ausnahme unformatiertes internes Laufwerk nach dem 1sten einschalten). Jetzt muss ich das nur in eine halbwegs brauchbare GUI verpacken

Wenn man nur mehr Zeit hätte... Ich hab da so viele Ideen was man machen könnte.

Leider ist der BASIC-Speicher auch begrenzt. Da lernt man das programmieren unter GEOS mit dem VLIR-Format erst wieder so richtig zu schätzen