CBM 3040 justieren - original Floppy in Berlin?

Hi!

In Sachen CBM-Unterlagen ist zimmers.net eine, wenn nicht DIE Anlaufstelle. Unterlagen zur 3040 findest du in: http://www.zimmers.net/anonftp…rives/old/4040/index.html

Die Spurlage verstellt man, indem man die Befestigungsschrauben des Steppermotors, der die Rillenscheibe antreibt, von der dann der Kopfschlitten verschoben wird, von unten löst (dazu muss das Laufwerk ausgebaut sein), und dann den Stepper LEICHT verdreht. Auf dem Analogboard kann man am TP1/2 (2040-3040-4040_drive_schematics.pdf, Seite 10) mit dem Oszi messen und die Amplitude maximieren. Dazu am besten ein Basicprogramm schreiben was konstant (einstellbare) Tracks von Diskette liest. (Mittels Block-Read, steht im "CBM 2040-3040-4040-8050 Disk Drive Manual.pdf" auf Seite 49)

Ich hab eine 1541 Demodiskette (von Commodore) als Original genommen. Die gibt's wie Sand am Meer und die 3040/4040 kann die lesen. Die Laufwerke ausgebaut, auf die Seite gelegt, um Zugang zum Stepper zu bekommen und dann ist es eine halbe Stunde rumfummeln und fluchen. Meist reicht schon das festdrehen der Schrauben und das Alignment zu verstellen. Aber ich habs nach der Methode hinbekommen. Bei DEN Drives:

PS:
Im "2040-4040_service_docs.pdf" ab Seite 26 wird die offizielle Methode beschrieben. Prinzipiell gleich und die mechanischen Hinweise (Laufwerk horizontal oder auf der linken Seite liegend etc) sind genau so anzuwenden. Aber das gezeigte Scopepattern bekommt man nur mit einer speziellen Alignmentdisk hin. Und die sind super rar. ALso richtig richtig Goldstaub.

Aber mit der Methode des Maximierens der Amplitude geht es auch. Man KANN es sogar ganz ohne Scope machen. Einfach so lange drehen bis das Laufwerk die Originaldiskette ordentlich liest, dann ist man eh nah am Optimum.

Den Code hatte ich damals geschrieben, allerdings auf einem Basic4 8032-SK mit auf 4040 (DOS2) geupgradeter 3040.
Das läuft nicht ohne Anpassungen auf dem Basic2 eines 3032, weil einige Befehle noch so nicht existieren.

print ds$ in Zeile 260 zum Beispiel.
Weiter unten im Thread hab ich eine Version gepostet die auf einem 3032 zu laufen schien aber noch einen Bug enthielt:

Shugart SA-390/400 (Doppelfloppy CBM 3040) Reparatur
Das FOR aus Zeile 160 sollte nach den open befehlen der beiden nachfolgenden Zeilen kommen.

Beim durchlesen des Threads fiel mir noch was auf.... eine nicht geupdatete 3040 kann noch keine C64 disks lesen.
Shit, das hatte ich komplett vergessen, da meine schon beim Kauf das Dos2 upgrade hatte. (Auch berichten die meisten Seiten dass eine 3040 das 1541er format lesen kann und VICE liefert auch das 2er DOS für die 3040)

Versuch also erst mal das hier:
Rechner resetten, danach eingeben:
10 open 1,8,15:input#1,e,e$,t,s:print e,e$,t,s:close 1

und run
Das ist der Ersatz für den Basic4 Befehlt "print ds$" und liest den Fehlerkanal des Drives aus. Direkt nach dem Start meldet es die DOS-Version.
Ein DOS2 Laufwerk meldet sich dann mit

73 CBM DOS V2 0 0

Was steht bei dir?

Zitat von zitruskeks

Shit, das hatte ich komplett vergessen, da meine schon beim Kauf das Dos2 upgrade hatte. (Auch berichten die meisten Seiten dass eine 3040 das 1541er format lesen kann und VICE liefert auch das 2er DOS für die 3040)

Nur die frühen 3040 wurden mit DOS 1 ausgeliefert. Eine Bekannter von mir hatte so eine.

Die meisten wurden dann mit DOS 2 geliefert.

So ein Versionswechsel innerhalb einer Modellreihe macht Anwender auch nicht glücklich. Zumal wenn das Diskettenformat nicht kompatibel ist.

Mit DOS 2 konnte man DOS 1 Disketten lesen, wenn ich mich richtig erinnere, aber beim Schreiben gab es Chaos.

Ich hoffe ja dass der Satz "dass ich die Floppy einigermaßen zuverlässig lesen kann" auf genau das zutrifft. War im anderen Thread ja wohl nicht so.

wenn

10 open 1,8,15:input#1,e,e$,t,s:print e,e$,t,s:close 1

einen syntax error liefert dann hat das drive wohl noch DOS1, jedenfalls verhält sich in vice eine 2040 ebenso.
probier mal:

10 print"drive:";:input d
20 print"cylinder:";:input c
30 d$=str$(d):c$=str$(c)
40 s=21
50 if c>17 then s=19
60 if c>24 then s=18
70 if c>30 then s=17
100 open14,8,15,"i"+d$
110 open3,8,2,"#"
150 for n=1 to s-1
200 print#14,"u1:",2,d$,c$,str$(n)
210 get#3,a$
230 print"d"+d$+"c"+c$+"s"+str$(n)
250 next
290 open 2,8,15
300 input#2,a,b$,c,d
310 print a,b$,c,d
320 close 2
400 goto 150

das läuft in vice mit einer 2030 an einem 3032. In echt kann ich es leider nicht testen.

Drive fragt übrigens nach 1 oder 0, nicht nach Laufwerks-id (8,9 etc). Nur zur Sicherheit

hier noch ein screenshot aus vice:

Die User-Kommandos (hier U1) fand ich immer etwas suspekt, und habe immer die 'normalen' DOS-Kommandos (wäre hier B-R) verwendet.

Vielleicht gab es die auch bei DOS 1 noch garnicht?

Laut dem 2040 Manual von 1979 gab's das U1 Kommando schon.

Aber wozu man U1 und U2 brauchte, hat mir auch nie eingeleuchtet.

Übrigens, das schlimmst am DOS 1 war, dass man die Disketten nach jedem Diskettenwechsel mit I0 oder I1 initialisieren musste. Sonst war die aöte FAT noch im Speicher und wurde auf die neue Diskette geschrieben. Die war dann hinüber.

Zitat von Toast_r

Die User-Kommandos (hier U1) fand ich immer etwas suspekt, und habe immer die 'normalen' DOS-Kommandos (wäre hier B-R) verwendet.

Vielleicht gab es die auch bei DOS 1 noch garnicht?

B-R liest nur so viele Byte, wie im 1. Byte (0-indiziert) steht.

Wenn also der Block so beginnt:

00: 00 12 01 02 03 04 05 06
08: 07 08 09 0A 0B 0C 0D 0E
10: 0F 10 11 12 13 14 15 16
18: 17 18 19 1A 1B 1C 1D 1E

dann kann man mit B-R nur bis zur Adresse $14, also dem Wert $12 lesen. Danach bricht es ab.

Genauso mit B-W, der legt in dem Byte die Anzahl der geschriebenen Byte ab (und überschreibt den Wert damit).

Für manche Anwendungen ist das nett, für jemanden, der sich die Blöcke aber komplett anschauen will, nicht.

Ja. Und was ist jetzt die Aussage?

U1/U2 tut das nicht? Oder verhält sich genauso? Dann wäre es immer noch überflüssig.

Zitat von detlef

U1/U2 tut das nicht? Oder verhält sich genauso? Dann wäre es immer noch überflüssig.

Ich dachte, das Verhalten von U1/U2 ist bekannt.

Die lesen bzw. schreiben den gesamten Block also alle 256 Byte, komplett unverändert. Man kann sie vom Computer aus auch lesen bzw. schreiben.

D.h., die Befehle haben unterschiedliche Anwendungsgebiete: B-R und B-W sind für Daten, die man in Blöcken platzieren will und deren Länge (<= 254) erhalten bleiben soll. U1/U2 hingegen sind dafür die, low-level den Inhalt der Diskette auszulesen.

Das geht sogar soweit, dass in manchen Publikationen zur 1541 behauptet wird, B-R und B-W seien kaputt. Man hat offenbar dafür keinen Anwendungsbereich gesehen (und tatsächlich, das Verhalten von B-R und B-W könnte man mit sehr wenig Aufwand mit U1/U2 nachbilden - umgekehrt aber nicht so einfach, da bräuchte man noch Unterstützung durch M-R und M-W und Manipulationen an internen Strukturen).

Wenn etwas überflüssig ist, dann B-R und B-W, nicht aber U1 und U2.

Zitat von IchBinAlt

Zitat von Toast_r

Die User-Kommandos (hier U1) fand ich immer etwas suspekt, und habe immer die 'normalen' DOS-Kommandos (wäre hier B-R) verwendet.

Vielleicht gab es die auch bei DOS 1 noch garnicht?

B-R liest nur so viele Byte, wie im 1. Byte (0-indiziert) steht.

Wenn also der Block so beginnt:

Code

00: 00 12 01 02 03 04 05 06
08: 07 08 09 0A 0B 0C 0D 0E
10: 0F 10 11 12 13 14 15 16
18: 17 18 19 1A 1B 1C 1D 1E

dann kann man mit B-R nur bis zur Adresse $14, also dem Wert $12 lesen. Danach bricht es ab.

Genauso mit B-W, der legt in dem Byte die Anzahl der geschriebenen Byte ab (und überschreibt den Wert damit).

Für manche Anwendungen ist das nett, für jemanden, der sich die Blöcke aber komplett anschauen will, nicht.

Alles anzeigen

Ja, die B-R und B-W sind nicht als Befehle geeignet um ganze 'Blöcke' im Sinne von Disk Blocks zu lesen oder schreiben - genau aus genannten Gründen mit der Record Lenght. IIRC das folgt der Logik der REL Records des letzten Blocks einer Datei. Insb. Beim Schreiben wird auch in das erste zweite Byte die Länge des Record geschrieben.

U1/U2 sind dann dafür da, ganze Blöcke zu lesen und zu schreiben. IIRC kamen die aber erst in DOS 2 - ich meine in DOS 1 sind die noch nicht drin, kann mich aber auch irren

Edit: ich hab das jetzt nach der Beschreibung von IchBinAlt korrigiert. Aber so richtig will mein Gedächtnis das nicht akzeptieren... ich meine doch dass es das erste Byte das Blocks als Länge nimmt und nicht das Zweite. Aber das muss ich dann mal testen...

Wie ich oben bereits geschrieben hatte, habe ich U1 und U2 in einem 2040-Manual von 1979 gefunden.

Ich habe mal in meine alten Programme reingeschaut und da habe ich auch U1 und U2 verwendet. Also damals kannte ich wohl den Unterschied.

Zitat von fachat

Edit: ich hab das jetzt nach der Beschreibung von IchBinAlt korrigiert. Aber so richtig will mein Gedächtnis das nicht akzeptieren... ich meine doch dass es das erste Byte das Blocks als Länge nimmt und nicht das Zweite. Aber das muss ich dann mal testen...

André, du solltest mir nicht alles glauben sondern selber recherchieren.

Ja, du hast recht: Nur das erste Byte wird als Länge genommen. Da war meine Erinnerung falsch.

Ist so in den Handbüchern von 1540/1541/1571/1581 dokumentiert, andere Laufwerke habe ich mir nicht angeschaut.

Auch die ROM-Dissassemblys von 1541 und 1571 sprechen da eine eindeutige Sprache.

Dein Gedächtnis war richtig, meins falsch.