1581-Testbericht aus dem Jahr 1988

Snoopy · Oct 15th 2023

In dem Commodore Welt-Sonderheft "Special - P4/C16/116 - Testjahrbuch 1988" habe ich gerade einen Testbericht der 1581 gelesen.

Ich hänge die zwei Seiten einfach mal hier ein.

Pusti64 · Oct 15th 2023

Hallo,

ich kannte bisher nur den Testbericht aus der 64er und konnte es damals gar nicht erwarten so ein Laufwerk zu besitzen. Wurde dann aber recht schnell von dessen Unzuverlässigkeit gegenüber einer 1541 enttäuscht.

Der "riesige" Speicherplatz war aber gerade unter GEOS mehr als nur willkommen.

Pusti64

kinzi · Oct 15th 2023

Quote from Pusti64

Wurde dann aber recht schnell von dessen Unzuverlässigkeit gegenüber einer 1541 enttäuscht.

Wie hat sich die geäußert?

Wann hast du sie gekauft?

Pusti64 · Oct 15th 2023

An das genaue Jahr kann ich mich gar nicht mehr erinnern. Soweit ich weiß, hatte damals irgendein Händler einen größeren Posten an 1581 aufgekauft und an uns C64-Fans weiterverkauft.

Auf meinen verschiedenen 1581 Laufwerken kam es immer wieder zu Datenverlust. Woran da genau gelegen hat weiß ich aber nicht. Jedenfalls waren immer wieder Dateien verschwunden bzw. nicht mehr lesbar.

Irgendwann später konnte ich für richtig viel Geld mal eine CMDFD 4000 erstehen und von da an gab es solche Probleme nicht mehr.

Pusti64

kinzi · Oct 15th 2023

Quote from Pusti64

Auf meinen verschiedenen 1581 Laufwerken kam es immer wieder zu Datenverlust. Woran da genau gelegen hat weiß ich aber nicht. Jedenfalls waren immer wieder Dateien verschwunden bzw. nicht mehr lesbar.

Schade, dass du das nicht mehr genau weißt. Erhalten sind die Dinger wohl nicht mehr, oder?

Quote from Pusti64

Soweit ich weiß, hatte damals irgendein Händler einen größeren Posten an 1581 aufgekauft und an uns C64-Fans weiterverkauft.

Das hört sich aber eher nach "später" an als gleich beim Erscheinen?

Mike · Oct 15th 2023

Bei der 1581 gab es den Write-Track-Bug. Alle naslang wurde da ein Track beim Schreiben unterbrochen und war dann hin. Passierte das draußen, waren "nur" Dateien betroffen, passierte das beim Schreiben des Directories ... na, ja.

In der 64'er wurde mal gemutmaßt, daß das an einem fehlenden SEI im DOS-Code liegen sollte (mit Patch), woanders gab es aber auch die Vermutung, das es an einem fehlerhaften Floppy-Controller gelegen haben soll.

Ich kann den Bug jedenfalls bestätigen, in der Zeit von 4/1988 (1581 gekauft) bis 2/1991 (Umstieg auf Archimedes) ist er bei meinem Setup mindestens 3x aufgetreten. Zweimal davon auf dem Directory und hat da in einem Fall auf einer meiner Programmierhauptdisketten ein mühevoll geschriebenes Directory-Verwaltungsprogramm für den 128er im 80-Zeichen-Modus geschreddert.

Mehr Details hier: Der Moment... [318045-01 ROM in 1581] - Diskettenlaufwerke - Forum64

Insgesamt war die 1581 aber ggü. der 1571, die ich auch im Einsatz hatte, ein erheblicher Fortschritt. Mehr Speicher, schneller, und im Gegensatz zur 1571 hat sich der Schreib/Lese-Kopf beim Zumachen ohne Diskette nicht nach 6 Monaten verabschiedet.

kinzi · Oct 15th 2023

Quote from Mike

In der 64'er wurde mal gemutmaßt, daß das an einem fehlenden SEI im DOS-Code liegen sollte (mit Patch), woanders gab es aber auch die Vermutung, das es an einem fehlerhaften Floppy-Controller gelegen haben soll.

Ich kann den Bug jedenfalls bestätigen, in der Zeit von 4/1988 (1581 gekauft) bis 2/1991 (Umstieg auf Archimedes) ist er bei meinem Setup mindestens 3x aufgetreten. Zweimal davon auf dem Directory und hat da in einem Fall auf einer meiner Programmierhauptdisketten ein mühevoll geschriebenes Directory-Verwaltungsprogramm für den 128er im 80-Zeichen-Modus geschreddert.

Und genau darum geht es mir - um die genaue Ursache. Das SEI kann es nicht sein, das wurde schon rausgearbeitet. Der Disk-Controller kommt in Frage - das wurde von Fred Bowen selbst so bestätigt. Allerdings liegt der Verdacht nahe, dass es sich nur um eine kleine Charge Controller gehandelt hat - deshalb wären Zeiträume oder noch besser "original erhaltene Diskfresser-1581" so interessant.

[EDIT]

Ich hätte zu gerne so ein (bestätigtes) Ding auf dem Tisch, um das rauszufinden.

Und ich wüsste zu gerne, wie man es verlässlich "provozieren" kann, um es an meinen 1581 nachzustellen.

[/EDIT]

2049 · Oct 15th 2023

Quote from Mike

bis 2/1991 (Umstieg auf Archimedes)

… interessant - aber warum? 1991 musste man sich ja fast schon rechtfertigen, einen Amiga zu eignen… Respekt für die Archi-Entscheidung! Was führte zu diesem Entschluß? Eigensinn? Das würde ich verstehen! :-]

Mike · Oct 15th 2023

Quote from 2049

Was führte zu diesem Entschluß? Eigensinn?

In etwa das, ja.

Genaueres hatte ich dazu mal in den zwei Beiträgen hier geschrieben:

64er und der Archimedes

Euer Umstieg vom C64 zum nächsten/neuen Rechner daaamals™

Viele Grüße,

Michael

Gikauf · Oct 15th 2023

Der Fehler wurde von Commodore durch ein ROM Update beseitigt.

kinzi · Oct 15th 2023

Quote from Gikauf

Der Fehler wurde von Commodore durch ein ROM Update beseitigt.

Nein.

wweicht · Oct 15th 2023

weil es noch nicht erwähnt wurde:

Quote from Pusti64

Wurde dann aber recht schnell von dessen Unzuverlässigkeit

ich bin ja nicht der große Auskenner bezüglich Hardware , aber gab es da nicht auf der 1581-Platine den Jumper J1, der bei einem Floppy-Kontroller WD1770 geschlossen werden mußte ? Soweit ich mich dunkel erinnere, ging es da um das Timing ....

Gruß

Werner

kinzi · Oct 15th 2023

Quote from wweicht

aber gab es da nicht auf der 1581-Platine den Jumper J1, der bei einem Floppy-Kontroller WD1770 geschlossen werden mußte ? Soweit ich mich dunkel erinnere, ging es da um das Timing ....

J1 dient nur der Umschaltung des Stepper-Timings. Sonst zu nix.

Insbesondere hat er nichts mit WD1770/WD1772 zu tun. Auch wenn das überall (inkl. Service Manual) so erzählt wird.

Bazong · Oct 16th 2023

Quote from kinzi

Ich hätte zu gerne so ein (bestätigtes) Ding auf dem Tisch, um das rauszufinden.
Und ich wüsste zu gerne, wie man es verlässlich "provozieren" kann, um es an meinen 1581 nachzustellen.

Eventuell habe ich so ein 1581 Floppy und da wäre es interessant wie man das provozieren kann.

Bei meiner 1581 die ich vor ca. 2 Jahren gebraucht gekauft habe ist mir beim herumprobieren am C64 auch immer wieder passiert das ich mittendrin Lesfehler bei z.B. Summergames, Californiagames usw. hatte. Entweder das Spiel ging oder irgendwann beim nachladen eben nicht mehr. Ich hab dann auch onefiler PRG gespeichert und getestet, da ist mir dann nichts aufgefallen. Am Ende wo ich viel ausprobiert habe war mein Verdacht das etwas mit der Floppy nicht stimmt, bin dem aber nicht mehr weiter nachgegangen.

kinzi · Oct 16th 2023

Das hier wäre zumindest ein Ansatz.

Bazong · Oct 16th 2023

Ok danke, das muss ich mir anschauen. Aber da muss ich vorher erst den C64 und die 1581 wieder aufbauen, weiß nicht wann ich das machen kann.

128er-Man · Oct 16th 2023

Mir war das Problem mit der 1581 nicht bewusst... bin aber auch schnell auf JiffyDOS umgestiegen.

Snoopy · Oct 19th 2023

Ich habe das Textdokument von Fred Bowen vom 5. Mai 1989 wiedergefunden, das ich im Bezug zur 1581 im Hinterkopf hatte:

Quote from Fred Bowen

Some people who have used the Commodore 1581 disk drive have reported having

problems such as "trashed" disks (data errors in a file or the system track)

or varying frequencies of "drive not ready" or "drive not present" situations.

While these problems have prompted some folks to avoid the 1581 drive, it must

be noted that MOST problems attributed to the 1581 are in fact user related.

For example, the diskette must never be removed while the drive's activity

light is lit, before the track cache has been completely dumped by the DOS to

the physical diskette. Another very common cause of problems, including drive

not ready errors and even perceived modem problems, is the presence of a device

on the serial bus that is not turned on. It is important that all peripherals

connected to the system be turned on or be disconnected from the system.

Lastly, the use of quality, double sided, double density (DS/DD) diskettes

designed for 1 megabyte data density is necessary. On the other hand, using

diskettes designed for ultra high densities can lead to trouble when used on

the 1581 and therefore should also be avoided.

Commodore has experienced a problem with the WD1770 controller chip (socket U4)

which can result in "trashed" disks and splat files, usually during periods of

heavy disk use such as disk backups or multiple file copies, although the

presence of a WD1770 controller does not mean you can expect a problem. In

light of these difficulties Commodore has notified its service centers to

replace the WD1770 with a WD1772 controller chip. This replacement will be

made under warranty even if the unit has been purchaced more than 90 days

prior to bringing the unit in for service. There is a short program I wrote,

available on most online services, which can tell you what controller chip is

in your 1581. If you think you have experienced a problem like those described

you should take your drive to a local service center for evaluation. The

attempted repair or modification of a system by unqualified persons is not

recommended and will void the warranty.

While reports would appear to indicate the problems are widespread, in fact the

numbers are quite small. Authorized service centers should be aware of any

problems, as the 1581 drive has been well covered by past issues of the service

bulletin "TechTopics". Inquiries should be directed to your local service

center.

Fred Bowen

Commodore

Friday, May 5, 1989 (rev 3)

Display More

Snoopy · Oct 19th 2023

Und hier das erwähnte Testprogramm von Fred Bowen:

Code: 1581.diag

100 REM CHECK 1581 DISK FOR CONTROLLER TYPE & J1 JUMPER
105 REM ASSUMES 60HZ CLOCK, FUNCTIONAL TOD HARDWARE, AND GOOD DISKETTE
106 REM FOR C64 OR C128 (FOR C128 DO BANK15 FIRST)
110 REM 12/09/87 FRED BOWEN
115 :
120 PRINT"INSERT ANY *FORMATTED* DISK IN DRIVE."
121 INPUT"CHECK WHICH UNIT 8<left><left><left>";U: PRINT
125 :
130 OPEN 1,U,15 :L=218: H=1: REM ADDRESS $1DA IN DOS MEMORY
140 OPEN 2,U,2,"#"
145 PRINT#1,"M-R"CHR$(0)CHR$(192)CHR$(1): GET#1,A$
150 IF ASC(A$+CHR$(0))<>192 THEN PRINT"DEVICE"U"IS NOT A 1581.": GOTO360
155 :
160 PRINT#1,"M-R"CHR$(L)CHR$(H)CHR$(5): REM MODIFY CONTROLLER CMDS
170 FORI=1TO5:GET#1,A$:B$=B$+CHR$(ASC(A$+CHR$(0))OR3):C$=C$+A$:NEXT
180 PRINT#1,"M-W"CHR$(L)CHR$(H)CHR$(5)B$
190 :
200 PRINT#1,"U1";2;0;1;0 :GOSUB500: REM SEEK TRACK 1 & RESET TIMER
210 PRINT#1,"U1";2;0;80;0 :GOSUB600: REM SEEK TRACK 80 & READ TIMER
220 :
230 PRINT#1,"M-W"CHR$(8)CHR$(64)CHR$(1)CHR$(0): REM TEST JUMPER J1
240 PRINT#1,"M-R"CHR$(8)CHR$(64)CHR$(1): GET#1,J$
250 :
260 PRINT#1,"M-W"CHR$(L)CHR$(H)CHR$(5)C$: REM RESTORE CONTROLLER CMDS
270 IF VAL(F$)>0 THEN PRINT" SEEK ERROR- CHECK DISKETTE.": PRINT: RUN
285 :
290 PRINT"UNIT"U" CONTAINS A ";: REM REPORT
300 IF T>20 THEN PRINT"WD1770";: E=1
310 IF T<20 THEN PRINT"WD1772";
320 PRINT" AND J1 IS ";
330 IF J$="" THEN PRINT"OPEN": E=E+2
340 IF J$>"" THEN PRINT"CLOSED"
345 IF E=0 THEN PRINT"THIS UNIT IS OKAY."
350 IF EAND1 THEN PRINT"THE CONTROLLER SHOULD BE REPLACED WITH A WD1772."
355 IF EAND2 THEN PRINT"THE JUMPER J1 CAN BE CLOSED FOR FASTER STEP RATE."
360 :
370 CLOSE2: CLOSE1: END
380 :
390 :
500 FORI=11TO8STEP-1: POKE56320+I,0: NEXT: RETURN: REM RESET TOD
600 INPUT#1,F$,R$,E$,D$: T=PEEK(56329)*10+PEEK(56328): RETURN: REM WAIT, READ TOD

Display More

kinzi · Oct 19th 2023

Ja, das wurde alles im 1581-Thread schon durchgekaut.

[EDIT]

Der derzeitige Wissensstand ist:

Ca. 500 Stück aus den ersten Serien hatten ein Problem mit fehlender Masse an U10 (74LS93), Pin 10.
Ca. 2000 Stück aus den ersten Serien hatten ein Problem mit einer schlechten WD1770-Charge. Commodore hat es sich einfach gemacht und den WD1770 einfach generell "für schlecht erklärt" und nur noch WD1772 verbaut, wohl um zu vermeiden, dass die WD1770 aus dieser Charge doch noch irgendwie wieder ihren Weg in die 1581 finden.
WD1770 können problemlos in der 1581 verwendet werden; es liegt kein generelles Problem vor. Bei Chargen mit Datecode '86 oder '87 sollte man vielleicht etwas intensiver testen und beobachten.

Deshalb wäre es interessant, ein Drive mit nachweislich solchen Problemen auf dem Tisch zu haben und zu sehen, ob z. B. ein Controller-Tausch das Problem behebt und welchen Datecode dieser Controller dann hat.

[/EDIT]