SCSI/SASI-Controller für ST506-(MFM-)Festplatten

[Ralf Kiefer]

Hallo!

Bei der Suche nach anderen Controllern kam einer ans Tageslicht, den ich
zu nichts zuordnen kann. Ich habe sogar das EPROM ausgelesen, um zu
schauen, ob lesbare Zeichenketten drinstehen. Nichts, keinerlei
Zeichenkette ASCII-codiert.

Das ist er:
Loading Image...

Am einen Ende sind Anschlüsse, wie sie für MFM-Platten typisch sind. Am
anderen Ende ist eine 50pol. Pfostenfeldleiste. Bei der deuten mehrere
Merkmal auf SCSI: eine Reihe ist bis auf Pin 25 und 13 durchgehend
miteinander verbunden. Pin 25 fällt auf! Gegenüber vom Pin 13 kann Vcc
über eine Steckbrücke angelegt werden, d.h. TERMPWR. In unmittelbarer
Nähe sind steckbare Terminatorwiderstände. Soweit, so gut.

Also: was ist das? Die üblichen OMTIs fallen raus, also die 5000- und
7000-Serie. Als weiteren Name erinnere ich mich an Xebec. Die Fotos bei
Bitsavers sehen allerdings meiner Platine überhaupt nicht ähnlich, also
auch nicht.

Die Platine stammt aus einer Zeit, wo man noch keine integrierten
SCSI-Controller als Ein-Chip-Lösung nahm, sondern ein Gattergrab, was
eher auf SASI deutet. Zudem sind die jüngsten Chips auf der Platine
gemäß Datecodes aus dem Frühling 1986, also aus der Zeit der
Standardisierung vom ersten SCSI-Standard.

Mutig (wie ich bin ;-) ) habe ich den an einen SCSI-Bus von einem Mac
gehängt. Wenn er scheinbar ID 7 hat, stört er den SCSI-Bus überhaupt
nicht. Entferne ich eine Steckbrücke von denen, die ich als
SCSI-ID-Einstellung vermute, dann bleibt der SCSI-Bus vermutlich schon
nach dem ersten Zugriff hängen. D.h. irgendwas funktioniert, der
Controller fühlt sich angesprochen, beherrscht aber kein SCSI-Protokoll
der 1990er Jahre, also eher SASI.

Hinweise willkommen :-)

Gruß, Ralf

P.S.: Hat hier jemand tiefe Erfahrungen mit dem OMTI5200 und der
logischen Ansteuerung von Diskettenlaufwerken?

[Martin Peters]

Hallo Ralf!

Schoenes Teil :)

Ralf Kiefer schrieb:
(...)

Post by Ralf Kiefer
Bei der Suche nach anderen Controllern kam einer ans Tageslicht, den ich
zu nichts zuordnen kann.

Deine Zuordnung war doch hervorragend. Ein SCSI-1- evtl. auch ein
SASI-Controller ;-)

Klar, Typenbezeichnung waere schoen, aber vieles findet man auch durch
Ausprobieren raus. Hast Du nen Uralt-ISA-SCSI-Controller und einen alten
PC? Etwa ein ST-02 oder irgendein TMC-850/950?

Post by Ralf Kiefer
Ich habe sogar das EPROM ausgelesen, um zu
schauen, ob lesbare Zeichenketten drinstehen. Nichts, keinerlei
Zeichenkette ASCII-codiert.

Vielleicht sind die, falls sie ueberhaupt verhanden sind, auch
absichtlich verschleiert um zu verhindern, dass jemand das Ding nachbaut
bzw. die Firmware kopiert und nur die ASCII-Strings austauscht.

Post by Ralf Kiefer
http://www.ralf-kiefer.de/TEMP/Controller.JPG

Leider schlechte Aufloesung, zumindest fiel es mir sehr schwer, zu
entziffern, was auf dem Siemens-Chip steht. Ist das ein 8031-System?
Foto von der Rueckseite?

Wenn man ein paar Tage Zeit hat, koennte man sich dann ja auch mal
den Dump genauer anschauen,... sind ja nur 8 KiB ;-)
Waere vielleicht was fuer die Oster-Feiertage :D

Viele Gruesse,
Martin

[fritzchwolka]

Post by Martin Peters
Hallo Ralf!
Schoenes Teil :)
(...)

Post by Ralf Kiefer
Bei der Suche nach anderen Controllern kam einer ans Tageslicht, den ich
zu nichts zuordnen kann.

Deine Zuordnung war doch hervorragend. Ein SCSI-1- evtl. auch ein
SASI-Controller ;-)
Klar, Typenbezeichnung waere schoen, aber vieles findet man auch durch
Ausprobieren raus. Hast Du nen Uralt-ISA-SCSI-Controller und einen alten
PC? Etwa ein ST-02 oder irgendein TMC-850/950?

Post by Ralf Kiefer
Ich habe sogar das EPROM ausgelesen, um zu
schauen, ob lesbare Zeichenketten drinstehen. Nichts, keinerlei
Zeichenkette ASCII-codiert.

Vielleicht sind die, falls sie ueberhaupt verhanden sind, auch
absichtlich verschleiert um zu verhindern, dass jemand das Ding nachbaut
bzw. die Firmware kopiert und nur die ASCII-Strings austauscht.

Post by Ralf Kiefer
http://www.ralf-kiefer.de/TEMP/Controller.JPG

Leider schlechte Aufloesung, zumindest fiel es mir sehr schwer, zu
entziffern, was auf dem Siemens-Chip steht. Ist das ein 8031-System?
Foto von der Rueckseite?
Wenn man ein paar Tage Zeit hat, koennte man sich dann ja auch mal
den Dump genauer anschauen,... sind ja nur 8 KiB ;-)
Waere vielleicht was fuer die Oster-Feiertage :D
Viele Gruesse,
Martin

Die umlaufenden Bedruckung erinnert mich doch irgendwie ein wenig an
Philips.. ist wahrscheinlich Zufall

Loading Image...

[Ralf Kiefer]

Post by fritzchwolka
Die umlaufenden Bedruckung erinnert mich doch irgendwie ein wenig an
Philips.. ist wahrscheinlich Zufall

Das Platinenfoto von Dir ist aber eine Schaltung auf einer
Lochrasterplatine, die hinten vermutlich gefädelt ist. Bei denen sind
aus naheliegenden Gründen die Koordinaten beidseitig lesbar
aufgedruckt/geätzt.

Meine Platine ist eine 4-lagige Multilayer. Die einzige Kennzeichnung
ist die vermutlich vom Platinenhersteller ("FIXCO").

Gruß, Ralf

[Ralf Kiefer]

Post by Martin Peters
Schoenes Teil :)

Momentan nur optisch, nicht funktional.

Post by Martin Peters
Deine Zuordnung war doch hervorragend. Ein SCSI-1- evtl. auch ein
SASI-Controller ;-)

SCSI 1 hätte der Mac erkannt. Den nehme ich schon mit dem Wissen, daß
der alles erkennt, was irgendwie SCSI 1 spricht. Außer eben, der
Kandidat beherrscht das Protokoll nicht und bleibt da irgendwie drin
hängen.

Post by Martin Peters
Klar, Typenbezeichnung waere schoen, aber vieles findet man auch durch
Ausprobieren raus. Hast Du nen Uralt-ISA-SCSI-Controller und einen alten
PC? Etwa ein ST-02 oder irgendein TMC-850/950?

Uralt-Intel-PCs gibt's hier nicht, aber genügend alte Macs und auch
recht spezielle SCSI-Software-Hilfsmittel.

Post by Martin Peters

Post by Ralf Kiefer
Ich habe sogar das EPROM ausgelesen, um zu
schauen, ob lesbare Zeichenketten drinstehen. Nichts, keinerlei
Zeichenkette ASCII-codiert.

Vielleicht sind die, falls sie ueberhaupt verhanden sind, auch
absichtlich verschleiert um zu verhindern, dass jemand das Ding nachbaut
bzw. die Firmware kopiert und nur die ASCII-Strings austauscht.

Die nächste Maßnahme wäre den Code durch einen Disassembler zu schicken.
Aber das kann beliebig aufwendig werden.

Post by Martin Peters
Leider schlechte Aufloesung, zumindest fiel es mir sehr schwer, zu
entziffern, was auf dem Siemens-Chip steht. Ist das ein 8031-System?

Der Chip-Aufdruck ist schon nicht optimal gelungen, da kann der Scanner
nichts dafür. Ich kann heute Abend ggf. nochmal scannen, aber mit etwas
geringerem Abstand zur Glasfläche. Und ja, es ist ein 8031.


Meine Idee ist einen Hinweis zu erhalten, wer als Hersteller in Frage
kommt und mit Glück ein paar technische Unterlagen zu finden. Ggf. läßt
sich mit den Steckbrücken was machen. Es hat außer für die SCSI-ID und
TERMPWR "nur" 6 weitere Steckbrücken drauf. Es würde mir ggf. schon
reichen zu wissen, daß das ein SASI-Controller ist, denn dann brauche
ich (am Mac) mit SCSI gar nicht weiter zu probieren. Da könnte ich in
1-2 Jahren an einem anderen Rechner weitermachen, der einen
SASI-Anschluß hat, unter OS-9 läuft, und wo ich den SASI-Treiber
vermutlich sogar als Quelltext habe.

Gruß, Ralf

[Martin Peters]

Ralf Kiefer schrieb:
(...)

Post by Ralf Kiefer

Post by Martin Peters
Klar, Typenbezeichnung waere schoen, aber vieles findet man auch durch
Ausprobieren raus. Hast Du nen Uralt-ISA-SCSI-Controller und einen alten
PC? Etwa ein ST-02 oder irgendein TMC-850/950?

Uralt-Intel-PCs gibt's hier nicht, aber genügend alte Macs und auch
recht spezielle SCSI-Software-Hilfsmittel.

Das Schoene an besagten ST-02 und am Future Domain TMC-950 ist, dass die
ziemlich "Low-Level" sind. Ich hatte mir mal in Pascal (irgendwann in
den 90ern) ein kleines "Framework" geschrieben (ich glaube, der Code war
ziemlich gruselig), ueber das ich mich direkt mit der Platte unterhalten
konnte. Der Controller unterstuetzt einem beim Verbindungsaufbau, aber
die Datenuebertragung in den einzelnen Busphasen hatte man selbst in der
Hand, also Messages, Command, Data u.s.w. Damit wuerdest Du vmlt. recht
schnell rausfinden, ob sich der Controller eher wie ein SCSI-1- oder ein
SASI-Target verhaelt.

Beschrieben sind ST-01/02 und TMC-950 in der 3. Auflage von "SCSI-Bus
und IDE-Schnittstelle" von Friedhelm Schmidt (ISBN 3 8273 1417 8), falls
Du doch die Moeglichkeit findest, es mit einem alten PC zu "debuggen".
In der 4. Auflage ist die Doku entfernt worden.

Wie es bei Deinem Apple geht... keine Ahnung. Hatte der nen
5380-Controller?

Von allem, was danach kam, kann ich nur abraten. Dass man das ueberhaupt
ohne Weiteres noch mit SASI-Geratenen zum Laufen bekommen, bezweifle
ich. "Monstern" wie der Adaptec 1540/41 und seinen Verwandten mit EISA,
VLB oder PCI, aber auch SymbiosLogic-Controller aus der 53C8xx-Reihe,
haben das Messaging selbst gemacht, beim 154x z.B. mit einem Z80 oder
8085 auf dem Controller, der 53C8xx hatte eine eigene "Maschinensprache"
fuer die Kommunikation mit SCSI-Geraeten.

Post by Ralf Kiefer

Post by Martin Peters

Post by Ralf Kiefer
Ich habe sogar das EPROM ausgelesen, um zu
schauen, ob lesbare Zeichenketten drinstehen. Nichts, keinerlei
Zeichenkette ASCII-codiert.

Vielleicht sind die, falls sie ueberhaupt verhanden sind, auch
absichtlich verschleiert um zu verhindern, dass jemand das Ding nachbaut
bzw. die Firmware kopiert und nur die ASCII-Strings austauscht.

Die nächste Maßnahme wäre den Code durch einen Disassembler zu schicken.

Das war mein Gedanke ;-)

Post by Ralf Kiefer
Aber das kann beliebig aufwendig werden.

Ja. Wenn man das ganz und nicht nur auszugsweise verstehen will, wuerde
ich so 2 Wochen ansetzen bei 8 KB Code-Groesse auf einem 8031... bt;dt.
Um ein wenig Verstaendnis dafuer zu entwickeln, was da passiert, reich
aber vmtl. das Oster-WE ;-)

[Ralf Kiefer]

Post by Martin Peters
Das Schoene an besagten ST-02 und am Future Domain TMC-950 ist, dass die
ziemlich "Low-Level" sind.

Gut so :-) Mit der berechtigten Annahme, daß da SASI läuft, kann ich
den an einen VMEbus-Rechner hängen, der eine echte SASI-Schnittstelle
hat. Wie erwähnt könnte es sein, daß ich den Treiber dazu als Quelltext
vorliegen habe. "Damals" hing an diesem Anschluß ein QIC02-Streamer. Und
weil der Schnittstellenbaustein ein CIO8536 ist, weiß ich, daß dort
sämtliche Einzelschritte im Protokoll "von Hand" durchgeklimpert werden.
Damit ist das als Projekt auf die "mittlere Zukunft" vertagt, denn
vorher muß die Hardware von diesem Rechner restauriert werden. Zum Glück
habe ich ein paar Ersatzteile für den, u.a. einen WD1002-05-Controller.
Der ist auch so ein Unikum: hängt per Flachbandkabel am Host und blendet
einen ganzen Speicherbereich in den Adreßraum der Wirts-CPU ein.

Post by Martin Peters
Wie es bei Deinem Apple geht... keine Ahnung. Hatte der nen
5380-Controller?

Fast alle Macs hatten einen 5380 für ihren externen SCSI-Anschluß.
Manche hatten für einen internen was schnelleres, sofern es einen
internen SCSI-Bus gab.

Post by Martin Peters

Post by Ralf Kiefer
Die nächste Maßnahme wäre den Code durch einen Disassembler zu schicken.

Das war mein Gedanke ;-)

Schaunmermal :-) Eines meiner Software-Projekte war sowieso der
"universelle 8bit-Disassembler". Den könnte ich anläßlich dieser Aktion
um die Intel-Single-Chipper bereichern.

Post by Martin Peters
Wenn man das ganz und nicht nur auszugsweise verstehen will, wuerde
ich so 2 Wochen ansetzen bei 8 KB Code-Groesse auf einem 8031... bt;dt.
Um ein wenig Verstaendnis dafuer zu entwickeln, was da passiert, reich
aber vmtl. das Oster-WE ;-)

Da ich keinerlei Ahnung von der Hardware dieser Platine habe, wird's
wohl aufweniger. Bei anderen Aktionen dieser Art hatte ich üblicherweise
integrierte I/O-Bausteine, deren Verhalten in Handbüchern steht sowie
Hinweise auf deren Adreßlage. Hier habe ich gar nichts.

Gruß, Ralf

[kay]

Post by Ralf Kiefer
Bei der Suche nach anderen Controllern kam einer ans Tageslicht, den ich
zu nichts zuordnen kann. Ich habe sogar das EPROM ausgelesen, um zu
http://www.ralf-kiefer.de/TEMP/Controller.JPG
Am einen Ende sind Anschlüsse, wie sie für MFM-Platten typisch sind. Am
anderen Ende ist eine 50pol. Pfostenfeldleiste. Bei der deuten mehrere
Merkmal auf SCSI: eine Reihe ist bis auf Pin 25 und 13 durchgehend
miteinander verbunden. Pin 25 fällt auf! Gegenüber vom Pin 13 kann Vcc
über eine Steckbrücke angelegt werden, d.h. TERMPWR. In unmittelbarer
Nähe sind steckbare Terminatorwiderstände. Soweit, so gut.
Mutig (wie ich bin ;-) ) habe ich den an einen SCSI-Bus von einem Mac
gehängt. Wenn er scheinbar ID 7 hat, stört er den SCSI-Bus überhaupt
nicht. Entferne ich eine Steckbrücke von denen, die ich als
SCSI-ID-Einstellung vermute, dann bleibt der SCSI-Bus vermutlich schon
nach dem ersten Zugriff hängen. D.h. irgendwas funktioniert, der
Controller fühlt sich angesprochen, beherrscht aber kein SCSI-Protokoll
der 1990er Jahre, also eher SASI.
Hinweise willkommen :-)

Dann "Hinweise" ich mal so. Für mich sieht der verdammt ähnlich der
Steuerplatine meiner alten Seagate-Festplatte (20 Megabyte, 5.25" MFM)
Ich meine nicht Controller im HBA-Sinne, sondern der der auf der Platte
selbst drauf ist. Willst du ein (Handy)Photo davon zum vergleichen?

Evtl. ist es ja nur Zufall der das am SCSI-Bus "irgendwas" machte. Die
MFM-Platten brauchten jedenfalls IMHO auch Terminatoren - an der letzten
Platte (von zweien).

Kay

[Ralf Kiefer]

Post by kay

Post by Ralf Kiefer
Am
anderen Ende ist eine 50pol. Pfostenfeldleiste. Bei der deuten mehrere
Merkmal auf SCSI: eine Reihe ist bis auf Pin 25 und 13 durchgehend
miteinander verbunden. Pin 25 fällt auf! Gegenüber vom Pin 13 kann Vcc
über eine Steckbrücke angelegt werden, d.h. TERMPWR. In unmittelbarer
Nähe sind steckbare Terminatorwiderstände. Soweit, so gut.

Dann "Hinweise" ich mal so. Für mich sieht der verdammt ähnlich der
Steuerplatine meiner alten Seagate-Festplatte (20 Megabyte, 5.25" MFM)

Mein Controller hat nicht ganz zufällig dieselbe Größe wie eine
5,25"-Festplatte. Denn die Controller wurden seinerzeit meist von unten
an die Festplatte drangeschraubt, wenn diese im Rack seitlich befestigt
war. Daher sind auch kurze ST506-Kabel dran.

Was ein Seagate-Festplattencontroller drauf hat, ist dreibeinige
Leistungselektronik für die Ansteuerung von Motor und Magnete. Mein
(vermuteter) Converter hat nur sehr wenig Analoges drauf, soll heißen
den Teil fürs Datenkabel Richtung ST506, mehr nicht.

Post by kay
Die
MFM-Platten brauchten jedenfalls IMHO auch Terminatoren - an der letzten
Platte (von zweien).

Nur für den durchgeschleiften Steuersignalbus, denn der kann an bis zu 4
Controller angeschlossen werden. Dieser hat 34Kontakte und einen
Card-Edge-Stecker. Der Terminator dafür ist auf meinem Controller fest
eingelötet. Die Terminatoren beim 50pol. Anschluß dagegen sind
gesockelt.

Mit der Idee Seagate suchte ich und fand bei Shugart einen Hinweis im
Product Guide vom April 83: ein Shugart SA1569 ist genau solch ein
Controller zwischen SASI und ST506 für *tusch* den Motorola Versabus.
Blöd nur, daß im Produktkatalog kein Foto dabei ist, und der Controller
auf der Titelseite dieser Shugart-Controller sein könnte, nur leider
ohne Ähnlichkeit mit meinem. Soll heißen: so was gab es, es gab
demzufolge einen Markt dafür, fehlt mir nur noch ein Hersteller und
technische Unterlagen für meinen. Große Hoffnung brauche ich mir eher
keine machen, denn auch dieser Shugart-Controller findet keine weitere
Erwähnung im Netz.

Gruß, Ralf

[Michael Bäuerle]

Post by Ralf Kiefer
[...]
Mit der Idee Seagate suchte ich und fand bei Shugart einen Hinweis im
Product Guide vom April 83: ein Shugart SA1569 ist genau solch ein
Controller zwischen SASI und ST506 für *tusch* den Motorola Versabus.
Blöd nur, daß im Produktkatalog kein Foto dabei ist, und der Controller
auf der Titelseite dieser Shugart-Controller sein könnte, nur leider
ohne Ähnlichkeit mit meinem. Soll heißen: so was gab es, es gab
demzufolge einen Markt dafür,

Den gab es mit Sicherheit. Dieses Prinzip haben später ja diverse
Hersteller verwendet (auch für Tape-Laufwerke).

Post by Ralf Kiefer
fehlt mir nur noch ein Hersteller und
technische Unterlagen für meinen. Große Hoffnung brauche ich mir eher
keine machen, denn auch dieser Shugart-Controller findet keine weitere
Erwähnung im Netz.

Hat SASI eigentlich auch schon MODE SELECT(6) unterstützt? Oder bringt
man solchen Controllern die Geometrie der Platte per Jumper bei?

[Ralf Kiefer]

Post by Michael Bäuerle
Den gab es mit Sicherheit. Dieses Prinzip haben später ja diverse
Hersteller verwendet (auch für Tape-Laufwerke).

Z.B. die OMTI 5000-Serie an SCSI spielt mit bis zu 4 Laufwerken aus den
Kategorien Diskette, MFM-Platte und QIC02-Band. Davon habe ich welche
und werde sie nehmen, um exotische Diskettenformate zu bearbeiten.

Post by Michael Bäuerle
Hat SASI eigentlich auch schon MODE SELECT(6) unterstützt? Oder bringt
man solchen Controllern die Geometrie der Platte per Jumper bei?

Per Steckbrücke geht nicht bei meinem Controller, denn mit genau 6 mir
unbekannten Steckbrücken wäre die Auswahl für zwei anschließbare
Festplatten zu gering. Umkehrschluß: die Geometrie kommt in Datenform
vom Host.

Gruß, Ralf

[Michael Bäuerle]

Post by Ralf Kiefer

Post by Michael Bäuerle
[...]
Hat SASI eigentlich auch schon MODE SELECT(6) unterstützt? Oder bringt
man solchen Controllern die Geometrie der Platte per Jumper bei?

Per Steckbrücke geht nicht bei meinem Controller, denn mit genau 6 mir
unbekannten Steckbrücken wäre die Auswahl für zwei anschließbare
Festplatten zu gering. Umkehrschluß: die Geometrie kommt in Datenform
vom Host.

Ich hatte das mal gemacht mit einem neueren IIRC Omti oder Emulex für
ESDI. Der konnte auf SCSI-Seite auch noch kein INQUIRY, aber er konnte
via ESDI die Geometrie selbst herausfinden und hat einen händisch
gesendeten FORMAT UNIT Befehl akzeptiert.

Bei ST506 kann das so ja nicht funktionieren.
SCSI1 definiert die Parameterliste für MODE SELECT so:
|
| MODE SELECT Parameter List
|
| ==============================================================================
| Byte | MODE SELECT Header |
| ==============================================================================
| 0 | Reserved |
| -----|-----------------------------------------------------------------------|
| 1 | Medium Type |

0 würde bedeuten: Default medium type (currently mounted medium type)

| -----|-----------------------------------------------------------------------|
| 2 | Reserved |
| -----|-----------------------------------------------------------------------|
| 3 | Block Descriptor Length |
| ==============================================================================
| | Block Descriptor(s) |
| ==============================================================================

Im Zweifel einen Blockdescriptor mit 512 Byte für alle Blocks (oder gar
keinen, weil vermutlich sowieso nichts anderes unterstützt wird).

Soweit könnte das bei deinem Controller vielleicht auch funktionieren.

| ==============================================================================
| | Vendor Unique Parameter(s) |
| ==============================================================================
| 0 _ n| Vendor Unique |
| | Parameter Byte(s) |
| ==============================================================================

Die Frage ist was man hier senden könnte. Das war damals noch komplett
herstellerspezifisch. Die Standard Mode Pages wurden erst mit SCSI2
genormt, sowas wie die dort definierte:
|
| Page code Description
| ------------------------------------------------------
| [...]
| 04h Rigid disk drive geometry page

gab es bei deinem Controller sicherlich noch nicht.
Ohne Doku wird da vermutlich keine Freude aufkommen ...

[Christian Corti]

Post by Ralf Kiefer
Mutig (wie ich bin ;-) ) habe ich den an einen SCSI-Bus von einem Mac
gehängt. Wenn er scheinbar ID 7 hat, stört er den SCSI-Bus überhaupt
nicht. Entferne ich eine Steckbrücke von denen, die ich als
SCSI-ID-Einstellung vermute, dann bleibt der SCSI-Bus vermutlich schon
nach dem ersten Zugriff hängen. D.h. irgendwas funktioniert, der
Controller fühlt sich angesprochen, beherrscht aber kein SCSI-Protokoll
der 1990er Jahre, also eher SASI.

Ich tippe auch auf SASI. Anzumerken ist, daß SASI kein INQUIRY-Kommando
kennt, also wird auf dem Bus auch nichts "sichtbar". Man muß wissen, was
da ist. Ich habe irgendwann mal letztes Jahr mit Hilfe eines kleinen
ARM-Evaluationsboards (IDM-SBC von TI/Stellaris) einen Dump einer Platte
angefertigt, die an einem Omti 5200 hängt ...

Post by Ralf Kiefer
P.S.: Hat hier jemand tiefe Erfahrungen mit dem OMTI5200 und der
logischen Ansteuerung von Diskettenlaufwerken?

... daher habe ich etwas Erfahrung mit diesem Controller. Aber alles,
was ich dazu weiß, habe ich aus dem Omti 5000 series reference manual.

Christian

[Ralf Kiefer]

Post by Christian Corti
Ich tippe auch auf SASI. Anzumerken ist, daß SASI kein INQUIRY-Kommando
kennt, also wird auf dem Bus auch nichts "sichtbar".

Das ist ein Kommando auf der oberen SCSI-Ebene. In meinem Fall sieht's
so aus, wie wenn sich der SCSI-Bus vom Mac so verklemmt, daß nur noch
ein Reset hilft. Das deutet für mich auf ein Problem auf der unteren
Ebene vom SCSI-Protokoll.

Post by Christian Corti

Post by Ralf Kiefer
P.S.: Hat hier jemand tiefe Erfahrungen mit dem OMTI5200 und der
logischen Ansteuerung von Diskettenlaufwerken?

... daher habe ich etwas Erfahrung mit diesem Controller. Aber alles,
was ich dazu weiß, habe ich aus dem Omti 5000 series reference manual.

Das hatte ich mir auch schon von den Bitsavers geholt (Januar85- und
August85-Version). Meine Frage ist, inwiefern sich der OMTI an die
gewünschten Geometriedaten hält (Kapitel 5.2), die er vorgesetzt
bekommt. Z.B. im "Sector ID Field" akzeptiert er bei 250kb/s (DD-Format)
bei einer Sektorgröße von 256Byte "01-10" Sektoren, also zwischen 1 und
16. Schade, denn ich hätte gerne 18. Dieselbe Einschränkung hat er beim
500kb/s-Format (HD) bei einer Sektorgröße von 512Byte. D.h. er kann
keine MS-DOS-Disketten im HD-Format, OMTI-Handbuch 16, PC 18. Das
720kB-Format von MS-DOS (DD mit 9Sektoren zu 512Byte) kann er wiederum.

Weißt Du, wie sich der Controller tatsächlich verhält? Sind die Angaben
im Handbuch als "empfohlen" zu betrachten, oder kann er wirklich nicht.

Der Versuch die Verwendung der 50.000 bits einer Spur auf einer
DD-Diskette nachzurechnen, dazu diese Erklärung beantwortet mir
vermutlich meine Fragen:
http://www.moria.de/~michael/floppy/

Der Omti-Controller hat den Inter Sector Gap fix. Und er hat einen
NEC765A als Disketten-Controller.

Gruß, Ralf

[Christian Corti]

Post by Ralf Kiefer
Das ist ein Kommando auf der oberen SCSI-Ebene. In meinem Fall sieht's
so aus, wie wenn sich der SCSI-Bus vom Mac so verklemmt, daß nur noch
ein Reset hilft. Das deutet für mich auf ein Problem auf der unteren
Ebene vom SCSI-Protokoll.

SASI und SCSI sind sich sehr ähnlich, aber es gibt wohl feine
Unterschiede auf Bus- bzw. Protokollebene. Ich hatte für mein
Adhoc-SASI-Adapter die SASI-Spezifikation durchgelesen, zu finden im
ANSI-Dokument X3T9.3.
So kennt z.B. der OMTI keine Arbitrierungsphase und keine "Message
Out"-Phase. Wenn der Host aber das erwartet, wird es vermutlich klemmen.

Post by Ralf Kiefer
August85-Version). Meine Frage ist, inwiefern sich der OMTI an die
gewünschten Geometriedaten hält (Kapitel 5.2), die er vorgesetzt
bekommt. Z.B. im "Sector ID Field" akzeptiert er bei 250kb/s (DD-Format)
bei einer Sektorgröße von 256Byte "01-10" Sektoren, also zwischen 1 und
16. Schade, denn ich hätte gerne 18. Dieselbe Einschränkung hat er beim
500kb/s-Format (HD) bei einer Sektorgröße von 512Byte. D.h. er kann
keine MS-DOS-Disketten im HD-Format, OMTI-Handbuch 16, PC 18. Das
720kB-Format von MS-DOS (DD mit 9Sektoren zu 512Byte) kann er wiederum.

Was passiert, wenn Du mit Byte 5 im Kommando "DEFINE FLEXIBLE DISK FORMAT"
die Anzahl der Sektoren überbügelst?

Post by Ralf Kiefer
Weißt Du, wie sich der Controller tatsächlich verhält? Sind die Angaben
im Handbuch als "empfohlen" zu betrachten, oder kann er wirklich nicht.

Ich denke, er kann es nicht, und zwar weil zuviel Intelligenz dazwischen
steckt. Eine Möglichkeit wäre, die Tabelle in der Firmware zu patchen;
es gibt ja die TRACK FORMAT CODES.
(Ich merke gerade, daß ich das EPROM hätte auslesen sollen ;-) )

Christian

[Ralf Kiefer]

Post by Christian Corti
SASI und SCSI sind sich sehr ähnlich, aber es gibt wohl feine
Unterschiede auf Bus- bzw. Protokollebene.

An so was erinnere ich mich auch. Reselektion u.ä. beherrscht SASI
sowieso nicht.

Post by Christian Corti
So kennt z.B. der OMTI keine Arbitrierungsphase und keine "Message
Out"-Phase. Wenn der Host aber das erwartet, wird es vermutlich klemmen.

Dunkel erinnere ich mich an irgendwas Seltsames im Omti-Treiber im OS-9.
Mein Kollege hat den damals mit dem WD33C93 als Host-SCSI-Controller
versorgt. Es ging. Irgendwie.

Post by Christian Corti
Ich denke, er kann es nicht, und zwar weil zuviel Intelligenz dazwischen
steckt. Eine Möglichkeit wäre, die Tabelle in der Firmware zu patchen;
es gibt ja die TRACK FORMAT CODES.

Wenn der Omti die feste Anzahl der Sektorabstände in der Firmware hat,
dann wäre Firmware-Forschung und -Patchen ein Weg. Aber ich muß nicht
alles mal gemacht haben ;-)

Denn ich habe eine andere Idee, wie ich meine Aufgabe besser lösen kann
als mit dem Omti-Controller. Ich habe eine 68030-CPU-Karte (VMEbus,
Radstone) gefunden, die eine lokale Erweiterungskarte mit einem
WD1772-02 hat. OS-9 V2.3 müßte ich dafür haben, evtl. ein neueres
vielleicht sogar Y2k-taugliches. Den Treiber kann ich disassemblieren,
denn der ist nicht besonders groß, und beim OS-9 kenne ich die gesamte
Logik und Philosophie eines Treibers. Der 1772 hat den riesigen Vorteil,
den ich "damals" als "blöd" empfand: formatieren geht bei dem über das
Write-Track-Kommando, dem man eine komplett aufbereitete Spur vorsetzen
muß, d.h. "wohlsortierte" 6250Bytes mit all den Bytes für die Gaps und
den CRC und für jede Spur erneut. Jetzt ist's von Vorteil, denn damit
kann ich jegliche "Schweinerei" auf die Diskette schreiben und mit dem
gegenläufigen Kommando Read Track eine Spur als Rohdaten lesen. Und weil
die Radstone-Leute teuere Hardware bauen durften, ist die Karte mit
einem optional nutzbaren 1kB-FIFO versehen, der das Zeitverhalten sehr
entspannt. Die Karte kann allerdings kein 500kb/s-Format (HD), vermute
ich.

Daher: das Read Track Kommando eröffnet völlig neue Möglichkeiten
Inhalte von Disketten zu retten, die auf herkömmlichem Weg nicht mehr
lesbar sind.

Wenn ich den WD1772 auf der Radstone-Karte erforscht habe, kann ich den
Treiber vielleicht zum Atari 1040ST mit seinem WD1772 rübernehmen bzw.
umgekehrt, damit auf dem ein bißchen OS-9 läuft.

Aktualisierte To-Do-Liste:
- unbekannte Controller-Karte einmotten bis der Proteus-68010-Rechner
restauriert ist
- vielleicht findet sich bis dahin noch irgendwelche Info, die eine
Grundlagenforschung am Kandidat erübrigt :-)
- vielleicht erübrigt sich eine Inbetriebnahme sowieso, denn meine
MFM-Festplatten sind schon lange überfällig "gerettet" zu werden, aber
am Omti, weil Treiber vorhanden; sollte sich dabei herausstellen, daß
mein Vorrat funktionierender MFM-Platten [1] sehr gering ist, brauche
ich diesen unbekannten SASI-Controller sowieso nicht mehr
- Radstone-Rechner mit dem WD1772 aufbauen und dem zusätzlich noch einen
Teac FC-1 als 5. Diskettenlaufwerk für die HD-Formate spendieren

Gruß, Ralf

[1] Das wird irgendwann meine nächste Frage: wie nehme ich
MFM-Festplatten in Betrieb, die teilweise eine Liegezeit von bis zu
25Jahren haben, ohne daß sie zwischendurch eingeschaltet waren? Da sind
einige Rodimes darunter, die in ihrem 5,25"-Gehäuse ganze 15 oder 20MB
beherbergen.

[fritzchwolka]

Post by Ralf Kiefer
[1] Das wird irgendwann meine nächste Frage: wie nehme ich
MFM-Festplatten in Betrieb, die teilweise eine Liegezeit von bis zu

Ich drücke die Daumen...

Wie ist es hier mit ?
https://www.pdp8.net/mfm/mfm.shtml

Loading Image...

damit kann von der Festplatte eine "Datensicherung" gemacht werden.

Den habe ich hier auch:

Loading Image...


den suche ich noch als 2tes Geraet:

Loading Image...


MfG.

fritz

[Ralf Kiefer]

Post by fritzchwolka
Ich drücke die Daumen...

Danke. Ich hoffe mit meiner Frage eher auf Erfahrungen wie z.B. schlage
zuerst sachte mit einem Gummihammer aufs Gehäuse, damit sich evtl.
festklebende Köpfe lösen oder ähnliche Hausmittel ;-)

Post by fritzchwolka
Wie ist es hier mit ?
https://www.pdp8.net/mfm/mfm.shtml

Davon oder einem ähnlichen Projekt hörte ich schon mal. Muß tief in den
Bookmarks sein. Auffällig in Erinnerung ist mir die Batterie an Elkos.

Post by fritzchwolka
http://oldcomputers.dyndns.org/public/pub/roms/OMTI-5400/OMTI-5400_1.jpg

Ich habe zwei OMTI 5200 gefunden. Einer sollte mindestens funktionieren.
Ansonsten sollte mindestens einer der VMEbus-Rechner mit dem WD1002-05
funktionieren. Ich sehe gerade, daß Dein 5400 nur ein paar Bauteile mehr
drauf hat wie der 5200. Auf der leeren Position sollte sich ein 8kB-SRAM
nachrüsten lassen, was laut Doku besser für den Streamer-Betrieb sein
soll.
Der sieht dem WD1002-05 nicht unähnlich, außer daß dessen Layout im
Bereich rechts oben Lücken hat, die beim WD1002-05 gefüllt sind. Was
kann Dein Controller? Drei MFM-Platten und keine Diskettenlaufwerke? Der
WD1002-05 kann auf jeden Fall noch zusätzlich zu den Platten 4
Diskettenlaufwerke. Was macht denn die 14pol. Pfostenfeldleiste auf der
rechten Seite?

An welcher Sorte Rechner betreibst Du den WD1002?

Gruß, Ralf

[fritzchwolka]

Post by Ralf Kiefer

Post by fritzchwolka
Ich drücke die Daumen...

Danke. Ich hoffe mit meiner Frage eher auf Erfahrungen wie z.B. schlage
zuerst sachte mit einem Gummihammer aufs Gehäuse, damit sich evtl.
festklebende Köpfe lösen oder ähnliche Hausmittel ;-)

Einen Gummihammer habe ich auch vorrätig.

Post by Ralf Kiefer

Post by fritzchwolka
Wie ist es hier mit ?
https://www.pdp8.net/mfm/mfm.shtml

Davon oder einem ähnlichen Projekt hörte ich schon mal. Muß tief in den
Bookmarks sein. Auffällig in Erinnerung ist mir die Batterie an Elkos.

Post by fritzchwolka
http://oldcomputers.dyndns.org/public/pub/roms/OMTI-5400/OMTI-5400_1.jpg

Ich habe zwei OMTI 5200 gefunden. Einer sollte mindestens funktionieren.
Ansonsten sollte mindestens einer der VMEbus-Rechner mit dem WD1002-05
funktionieren. Ich sehe gerade, daß Dein 5400 nur ein paar Bauteile mehr
drauf hat wie der 5200. Auf der leeren Position sollte sich ein 8kB-SRAM
nachrüsten lassen, was laut Doku besser für den Streamer-Betrieb sein
soll.

Der 5400 mach noch streamer.
http://oldcomputers.dyndns.org/public/pub/roms/OMTI-5400/OMTI_5000_Series_Reference_Aug85.pdf


Den OMTI hatte ich mal sichergestellt und er kann eventuell gegen
gleichwertiges getauscht werden.

Post by Ralf Kiefer
Der sieht dem WD1002-05 nicht unähnlich, außer daß dessen Layout im
Bereich rechts oben Lücken hat, die beim WD1002-05 gefüllt sind. Was
kann Dein Controller? Drei MFM-Platten und keine Diskettenlaufwerke? Der
WD1002-05 kann auf jeden Fall noch zusätzlich zu den Platten 4

Genau, der WD1002-H0 ist der WD1002-05 ohne Diskettenlaufwerke.

Aus dem manual: (schnelles OCR nicht korrigiert)
The WD1002-HDO is a depopulated version of the
WD1002-05. All Floppy drive control and associated
circuitry has been deleted from the board, providing a
Winchester Drive Controller board that will drive up
to three 51/4" Winchester disk drives. All parameters,
programming, and timing in this document that
applied to Winchester Drive Controller to the
WD1002-05 and the WD1002-HDO.

http://oldcomputers.dyndns.org/public/pub/rechner/ncr/DMV/manuals/DMV%20External%20HD%20kit/61-031050-0030_WD1002-05_HDO_OEM_Manual_Jul83.pdf

Post by Ralf Kiefer
Diskettenlaufwerke. Was macht denn die 14pol. Pfostenfeldleiste auf der
rechten Seite?

Das ist J9 = Testconnector siehe Handbuch vorletzte Seite.

http://oldcomputers.dyndns.org/public/pub/rechner/ncr/DMV/manuals/DMV%20External%20HD%20kit/61-031050-0030_WD1002-05_HDO_OEM_Manual_Jul83.pdf

Post by Ralf Kiefer
An welcher Sorte Rechner betreibst Du den WD1002?
Gruß, Ralf

Der WD wird am NCR DM-V betrieben.

http://oldcomputers.dyndns.org/public/pub/rechner/ncr/DMV/My_DMV_Monochome/NCR_DMV_with_mfm-emu/0.thumbs.html

wobei ich einige MFM-Festplatten habe, diese aber durch den MFM-Emulator
längerfristig ersetzen werde.

Der im ersten Post gezeigte mfm-emulator auf einem Genie IIIs soll auch
da die mfm-hds ersetzen - Controller ist dabei ein Omti 5510/20
Der Genie IIIs hatte ursprünglich Xebec oder WD MFM-controller für
50/10MB Festplatten vorgesehen.

MfG.

fritz

[Christian Zietz]

Post by Ralf Kiefer
Daher: das Read Track Kommando eröffnet völlig neue Möglichkeiten
Inhalte von Disketten zu retten, die auf herkömmlichem Weg nicht mehr
lesbar sind.

Beachte aber, dass der WD1772 einige böse Bugs beim Read Track Kommando
hat, die in diversen Fällen verhindern, dass Du die Spur damit korrekt
zurücklesen kannst.

Grüße
Christian

[Ralf Kiefer]

Post by Christian Zietz
Beachte aber, dass der WD1772 einige böse Bugs beim Read Track Kommando
hat, die in diversen Fällen verhindern, dass Du die Spur damit korrekt
zurücklesen kannst.

Meinst Du diesen Einwand:
| Because the address mark detector is always on,
| write splices or noise may cause the chip to look for an address mark.
| [Transcriber's Note: I do not know how the programmer can tell that
| the AM detector has found an address mark.] The chip may read gap
| bytes incorrectly during write-splice time because of synchronization.

Beim Write Track gibt's auch so ein paar Merkwürdigkeiten.

Ansonsten erzähl mal!

Ich suche gerade im Web ... und finde ein überarbeitetes Datenblatt
Stand Januar 2015(!) von Jean Louis-Guerin/DrCoolZic, der den
Atari-WD1772 beschreibt, denn:

Erste Auffälligkeit: auf meiner Radstone-Hardware ist ein WD1772-PH02-02
drauf. Laut englischer Wiki wurde der Chip nur für den Atari STE gebaut,
und der konnte im Gegensatz zu den anderen WD1772 sogar 500kb/s, also HD
:-) Dann irrt hier wohl die Wiki, wenn der Chip auch auf
Radstone-Hardware drauf ist.

Jetzt hoffe ich umso mehr, daß diese Hardware noch funktioniert.


Gruß, Ralf

[Christian Zietz]

Post by Ralf Kiefer
| Because the address mark detector is always on,
| write splices or noise may cause the chip to look for an address mark.

Im Prinzip ja, nur dass sich das im Zitat eher harmlos ("write splices
or noise *may* cause [...]") liest. In Wahrheit triggert der oben
genannte Decoder bei Read Track jedoch auch zuverlässig aber falsch auf
bestimmte Bitfolgen, die ebenso in Nutzdaten vorkommen können. Ab diesem
Punkt ist die Synchronisation dahin und man liest für den Rest des
Tracks nur noch Unsinn. Beispielsweise kann man bei der Verwendung der
üblichen Adressfelder den Track 41 niemals richtig mit Read Track lesen,
weil dort bereits im Adressfeld eine der erwähnten Bitfolgen vorkommt.
Etwas näher beschrieben ist das in Abschnitt 4.5 in diesem Dokument:
<http://dmweb.free.fr/files/Atari-Copy-Protection-V1.4.pdf>
Leider gibt es das "Scheibenkleister II"-Buch nicht online; dort werden
die Probleme bei Read Track auf mehreren Seiten behandelt.

Post by Ralf Kiefer
Beim Write Track gibt's auch so ein paar Merkwürdigkeiten.

Ja, gewisse Bytes haben ja eine besondere Bedeutung und werden nicht
unverändert auf die Floppy geschrieben. Wurde auch gerne für
Kopierschutz verwendet.

Post by Ralf Kiefer
Erste Auffälligkeit: auf meiner Radstone-Hardware ist ein WD1772-PH02-02
drauf. Laut englischer Wiki wurde der Chip nur für den Atari STE gebaut,
und der konnte im Gegensatz zu den anderen WD1772 sogar 500kb/s, also HD
:-) Dann irrt hier wohl die Wiki, wenn der Chip auch auf
Radstone-Hardware drauf ist.

Unter Atari-Nutzern ist die Meinung, dass auch der WD1772-PH02-02 nicht
zuverlässig HD unterstützt. Ein Teil verträgt die nötige Übertaktung auf
16 MHz, die anderen nicht, das scheint über die Fertigung zu streuen.
Der STE hatte auch kein HD-Laufwerk; erst im Mega STE gab es eins zum
Nachrüsten. Dafür hatte Atari den AJAX genannten ASIC entworfen,
kompatibel zum WD1772 aber mit garantierter HD-Tauglichkeit.

Christian

[Ralf Kiefer]

Post by Christian Zietz
Unter Atari-Nutzern ist die Meinung, dass auch der WD1772-PH02-02 nicht
zuverlässig HD unterstützt. Ein Teil verträgt die nötige Übertaktung auf
16 MHz, die anderen nicht, das scheint über die Fertigung zu streuen.

Ich habe durch diese Suche etliche Atari-Foren gefunden. Erstaunlich
diese Vielfalt über 20Jahre nach dem Ende :-)

Zunächst verstehe ich noch nicht, wo der Unterschied zwischen
WD1772-PH02-02 (Chip-Aufdruck) und WD1772-02 (Datenblatt) liegt. Die
Atarianer unterscheiden außerdem noch den WD1772 00-00 vom 00-02 vom
02-02.

Bei meiner Radstone-Hardware: Vom Steckverbinder zur CPU-Karte kommt
definitionsgemäß ein 16MHz-Takt. Der verschwindet in einem 74F74, aus
dem wiederum der Takt für den WD1772 herauskommt. Also sieht's nach
einer üblichen Schaltung zur Halbierung des Takts aus, so daß der WD1772
konstant mit 8MHz versorgt wird. Dann werde ich auch im OS-9-Treiber
eher keine weiteren Hinweise und Möglichkeiten finden.

Außerdem ist wohl die Temperatur ein Problem in der Atari-Welt. Diese
Rechner haben mehrheitlich keine Zwangsbelüftung, so daß dort ein
Hitzestau wg. geringer Konvektionskühlung durchaus vorstellbar ist.
Meine Radstone-Hardware steckt in einem gut belüfteten VMEbus-Rack.
Allerdings ist die Radstone-Hardware so kompakt gebaut und im Falle des
Diskettencontrollers auf einer Erweiterungsplatine in der 2. Etage im
Luftstrom direkt hinter dem 68030 und 68882, daß auch bei ordentlicher
Zwangsbelüftung die Chips schon relativ warm werden.

Als Alternative habe ich mir diverse Teac-FC-1-Varianten angeschaut. Die
sind doch nicht so stur, wie ich bisher dachte :-) Bei denen habe ich
"nur" das Problem, daß ich mehr unterschiedliche Versionen habe als es
Handbücher dazu gibt, und die haben Jumper in unterschiedlichen
Varianten ...

BTW danke für die diversen Links.

Gruß, Ralf

[Christian Zietz]

Post by Ralf Kiefer
Ich habe durch diese Suche etliche Atari-Foren gefunden. Erstaunlich
diese Vielfalt über 20Jahre nach dem Ende :-)

Ich habe sogar den Eindruck, dass die Anzahl der Aktiven derzeit
zunimmt. Vielleicht, weil es "hip" ist, sich mit alter Hardware zu
beschäftigen? Vielleicht, weil einem heute Entwicklungs- und
Fertigungsmöglichkeiten offen stehen, die es auch einem einzelnen
Hobbyisten erlauben, ziemlich gutes Zubehör dafür zu erstellen?

Post by Ralf Kiefer
Zunächst verstehe ich noch nicht, wo der Unterschied zwischen
WD1772-PH02-02 (Chip-Aufdruck) und WD1772-02 (Datenblatt) liegt. Die
Atarianer unterscheiden außerdem noch den WD1772 00-00 vom 00-02 vom
02-02.

Etwas Stöbern in alten WD-Katalogen verrät, dass "PH" schlicht die
Gehäusebezeichnung ist -- 28-Pin PDIP -- und dass die Zahl, auf die es
ankommt ("00" oder "02") direkt danach folgt. Zur weiteren Zahl steht da
nichts. Interne Revisionsnummer? Codierung des Herstellungsorts?

Post by Ralf Kiefer
Außerdem ist wohl die Temperatur ein Problem in der Atari-Welt. Diese
Rechner haben mehrheitlich keine Zwangsbelüftung, so daß dort ein
Hitzestau wg. geringer Konvektionskühlung durchaus vorstellbar ist.

Dass das ein mögliches Problem sein könnte, dafür spricht der in einer
HD-Umbauanleitung gegebenen Rat, einen flachen Kühlkörper auf den
Floppycontroller zu kleben. Es mag aber ebensogut sein, dass manche
WD1772 das Timing bei 16 MHz Takt einfach nicht schaffen, egal wie kühl
sie sind.

Christian

[Gerrit Heitsch]

Post by Christian Zietz

Post by Ralf Kiefer
Ich habe durch diese Suche etliche Atari-Foren gefunden. Erstaunlich
diese Vielfalt über 20Jahre nach dem Ende :-)

Ich habe sogar den Eindruck, dass die Anzahl der Aktiven derzeit
zunimmt. Vielleicht, weil es "hip" ist, sich mit alter Hardware zu
beschäftigen? Vielleicht, weil einem heute Entwicklungs- und
Fertigungsmöglichkeiten offen stehen, die es auch einem einzelnen
Hobbyisten erlauben, ziemlich gutes Zubehör dafür zu erstellen?

Post by Ralf Kiefer
Zunächst verstehe ich noch nicht, wo der Unterschied zwischen
WD1772-PH02-02 (Chip-Aufdruck) und WD1772-02 (Datenblatt) liegt. Die
Atarianer unterscheiden außerdem noch den WD1772 00-00 vom 00-02 vom
02-02.

Etwas Stöbern in alten WD-Katalogen verrät, dass "PH" schlicht die
Gehäusebezeichnung ist -- 28-Pin PDIP -- und dass die Zahl, auf die es
ankommt ("00" oder "02") direkt danach folgt. Zur weiteren Zahl steht da
nichts. Interne Revisionsnummer? Codierung des Herstellungsorts?

Das dürfte die Revision sein. Ich kenne das noch vom WD33C93A
(SCSI-Controller-IC). Die Version 00-04 (oft noch mit dem Zusatz
'PROTO') machte eine Menge Ärger, bis zum Absturz der internen
Statemachine, die 00-08 lief deutlich besser und war im Bezug auf
Terminierung toleranter.

Ich hab damal meinen SCSI-HBA extra umgebaut.

Gerrit

[Ralf Kiefer]

Post by Christian Zietz
Ich habe sogar den Eindruck, dass die Anzahl der Aktiven derzeit
zunimmt. Vielleicht, weil es "hip" ist, sich mit alter Hardware zu
beschäftigen? Vielleicht, weil einem heute Entwicklungs- und
Fertigungsmöglichkeiten offen stehen, die es auch einem einzelnen
Hobbyisten erlauben, ziemlich gutes Zubehör dafür zu erstellen?

Letzteres ist auf jeden Fall ein Argument. Wenn ich dran denke, wie
schwierig es war sich damals, als die Geräte in den 1980er Jahren
aktuell waren, mit Wissen und danach mit Chips zu versorgen, dann ist's
heute ein Kinderspiel. Ich war damals stolz drauf einige Dutzend
Datenbücher zu beschaffen und meist Datenblätter für Chips griffbereit
zu haben, die mich am Meisten interessierten. Heute wird kurz
"gegoogelt" und schon hat man die Datenblätter ganz ohne persönliche
Bekanntschaft von Vertriebsleuten der Distributoren. Und dann kann man
auf viel Wissen anderer Bastelwütiger zurückgreifen. Mein Umfeld war
seinerzeit immerhin ein großes, in dieser Richtung aktives
Studentenwohnheim. Damals privilegiert, heute belächelt aufgrund der
"Enge".

Dazu kommen "Umgebungsvariablen" wie freie Platinenlayout-Software,
damals hatte ich noch eines über abenteuerliche Umwege "ausleihen"
müssen und es von der Pflicht befreit jedes Mal beim Start eine
merkwürdig formatierte Diskette einlegen zu müssen, um dann auf
512*384Pixel in schwarz-weiß ein Layout zu zeichnen. Heute hat man dafür
die 10-, eher 20-fache Bildschirmfläche und Farben, dazu KiCAD oder für
Kleinsachen Eagle, frei verfügbar. Die Platinen kommen zum
subventionierten Preis für ein paar Euros aus China, so daß sich schon
fädeln nicht mehr lohnt, wenn man die Zeit hat. Damals kostete mich die
Fertigung einer zweilagigen Platine etwas größer als Europa als
Nullserie mit 11 funktionstüchtigen Exemplaren den Gegenwert von 9
Monatsmieten im Studentenwohnheim. Das ist heute mit rund einem Viertel
einer Monatsmiete zu schaffen.

Post by Christian Zietz

Post by Ralf Kiefer
Zunächst verstehe ich noch nicht, wo der Unterschied zwischen
WD1772-PH02-02 (Chip-Aufdruck) und WD1772-02 (Datenblatt) liegt. Die
Atarianer unterscheiden außerdem noch den WD1772 00-00 vom 00-02 vom
02-02.

Etwas Stöbern in alten WD-Katalogen verrät, dass "PH" schlicht die
Gehäusebezeichnung ist -- 28-Pin PDIP -- und dass die Zahl, auf die es
ankommt ("00" oder "02") direkt danach folgt. Zur weiteren Zahl steht da
nichts. Interne Revisionsnummer? Codierung des Herstellungsorts?

Wie Gerrit schrieb könnte es die Versionsnummer sein, denn beim WD33C93
erinnere ich mich jetzt auch an so komische "Spielchen" und Probleme,
die meine Kollegen anfangs mit dem Chip auf der eigenentwickelten
Hardware hatten.

Post by Christian Zietz

Post by Ralf Kiefer
Außerdem ist wohl die Temperatur ein Problem in der Atari-Welt. Diese
Rechner haben mehrheitlich keine Zwangsbelüftung, so daß dort ein
Hitzestau wg. geringer Konvektionskühlung durchaus vorstellbar ist.

Dass das ein mögliches Problem sein könnte, dafür spricht der in einer
HD-Umbauanleitung gegebenen Rat, einen flachen Kühlkörper auf den
Floppycontroller zu kleben.

Ich fand daneben eine Umbauanleitung, bei der zuerst die Taktleitung vom
WD1772 von der Atari-Hauptplatine abgeklemmt wurde, um diese von einer
obenaufgesetzten Platine zu versorgen. Das ist mal ein wirkungsvoller
Kühlungsverhinderer.


Gruß, Ralf

[Gerrit Heitsch]

Post by Ralf Kiefer
Ich fand daneben eine Umbauanleitung, bei der zuerst die Taktleitung vom
WD1772 von der Atari-Hauptplatine abgeklemmt wurde, um diese von einer
obenaufgesetzten Platine zu versorgen. Das ist mal ein wirkungsvoller
Kühlungsverhinderer.

Wobei die 1772 nicht einmal warm wurden, da war ich von anderen ICs
deutlich höhere Temperaturen gewöhnt (VIC im C64 z.B.). Ich denke eher
der WD1772 war vom internen Timing her bei 16 MHz schon extrem nahe an
seiner Grenze so daß schon eine leichte Erwärmung ausreichte damit er
nicht mehr funktionierte.

BTW: Den 1772 gab es auch von VLSI. Von denen hiess er VL1772-xx wobei
'xx' wohl die Revision war.

Gerrit

[Christian Zietz]

Post by Ralf Kiefer
Erste Auffälligkeit: auf meiner Radstone-Hardware ist ein WD1772-PH02-02
drauf. Laut englischer Wiki wurde der Chip nur für den Atari STE gebaut,
und der konnte im Gegensatz zu den anderen WD1772 sogar 500kb/s, also HD
:-) Dann irrt hier wohl die Wiki, wenn der Chip auch auf
Radstone-Hardware drauf ist.

PS: Ich denke auch, dass der Wikipedia-Artikel hier irrt. Sowohl der
WD1772-00 als auch der WD1772-02 sind im WD-Datenbuch von 1986 [1]
enthalten. Wäre der WD1772-02 nur im Kundenauftrag für Atari gefertigt
worden, wäre er sicherlich nicht im öffentlichen Datenbuch aufgeführt.
Ferner unterstützt auch der WD1772-02 offiziell, d.h. laut Datenbuch,
kein HD. Der dort genannte Unterschied zwischen -00 und -02 bezieht sich
einzig auf den Datenseparator, der im WD1772-02 neu als digitale PLL
implementiert wurde. Ich vermute, damit kommt er besser mit Jitter oder
nicht exakten Bitraten klar. (Das hilft vielleicht, wenn man ihn
entgegen der Spezifikationen für HD übertaktet.)

Christian

[1]
<http://bitsavers.informatik.uni-stuttgart.de/pdf/westernDigital/_dataBooks/1986_Storage_Management_Products_Handbook.pdf>

[Bernd Ohm]

Post by Ralf Kiefer
http://www.ralf-kiefer.de/TEMP/Controller.JPG

Im ersten Moment erinnerte mich deine Platine an
ADAPTEC ACB4070 Controller, die hier aus alten
ATARI-ST-Zeiten immer noch herumfliegen:

Loading Image...

Man brauchte dann nur noch ein kleines Interface, um aus
ATARIs ACSI SCSI herzustellen.

[Christian Zietz]

Post by Bernd Ohm
Im ersten Moment erinnerte mich deine Platine an
ADAPTEC ACB4070 Controller, die hier aus alten
http://www.retrotechnology.com/herbs_stuff/adaptec_4070.jpg
Man brauchte dann nur noch ein kleines Interface, um aus
ATARIs ACSI SCSI herzustellen.

Hach, wie modern. ;-) Der ACB-4070 kann ja schon RLL. In meiner SH-204
werkelt noch ein ACB-4000, die MFM-Version.

Christian

[Ralf Kiefer]

Post by Bernd Ohm
Im ersten Moment erinnerte mich deine Platine an
ADAPTEC ACB4070 Controller, die hier aus alten

Aha, noch einer, der zwischen SASI oder SCSI und MFM konvertiert.

BTW Du hast den EPROM-Inhalt bereits kopiert und gebackupt?

Gruß, Ralf

[Bernd Ohm]

Post by Ralf Kiefer
BTW Du hast den EPROM-Inhalt bereits kopiert und gebackupt?

Nö, soll ich?
Braucht es jemand?
Oder denkst du, dass nichts mehr drin ist?

[Ralf Kiefer]

Post by Bernd Ohm
Oder denkst du, dass nichts mehr drin ist?

Das EPROM ist vermutlich über 30Jahre alt. Ich habe schon jüngere mit
(teilweise) gekipptem Inhalt gesehen [1].

Platinen mit dieser Seltenheit sind nunmal Schrott, wenn in der Firmware
die ersten Bits gekippt sind. Schau mal bei Bitsavers, ob's dort schon
vorhanden ist. Wenn ja, dann hättest Du notfalls ein Backup. Wenn nein,
hinschicken! :-) Vielleicht kann das irgendjemand anderes brauchen.

Gruß, Ralf

[1] Z.B. in einem externen Diskettenlaufwerksgehäuse mit
5,25"-Laufwerken mit SCSI-Controller von Dayna für Macs. Ich habe
immerhin in den USA einen gefunden, der dieses Gerät auch hat, nur mag
der mir keine Kopie schicken. Also habe ich hier einen hübsch
anzuschauenden Briefbeschwerer :-(

[Bernd Ohm]

Post by Ralf Kiefer
Platinen mit dieser Seltenheit sind nunmal Schrott, wenn in der Firmware
die ersten Bits gekippt sind.

Aber wie soll man erkennen, ob da ein Bit gekippt ist?
Hashes hat ADAPTEC damals ja leider nicht draufgeschrieben.
Die Baugruppe muss ja durch ein gekipptes Bit auch nicht
völlig funktionslos sein, sondern produziert eventuell nur
bei bestimmten Betriebszuständen Fehler. Schwierig.

Nichtsdestotrotz hast du mich da auf etwas gebracht.
Ich werde das EPROM jedenfalls mal anschauen.
Bei den Bitsavers gibt es leider nur eine Version "C",
ich habe die Version "D". Ich kann also meinen Dump
nicht verifizieren.
Aber ich habe -glaube ich - irgendwo noch weitere
Controller.

[Gerrit Heitsch]

Post by Bernd Ohm

Post by Ralf Kiefer
Platinen mit dieser Seltenheit sind nunmal Schrott, wenn in der Firmware
die ersten Bits gekippt sind.

Aber wie soll man erkennen, ob da ein Bit gekippt ist?

Das ist einfach... Die EPROMs bitte zweimal auslesen. Einmal normal und
einmal mit einer 1N4148 in Flussrichtung in der Versorgungsleitung des
EPROMs. Liest du beidesmal dasselbe hast du eine sehr gute Chance, daß
die Daten noch OK sind. Liest du unterschiedliches besteht immer noch
eine gewisse Chance, daß die mit Diode gelesenen Daten OK sind.

Grund: Durch die niedrigere Betriebsspannung des EPROMs (ca. 0,7V
weniger) kann es sein, daß die in den Floating Gates verbliebenen
Ladungen doch noch reichen wo sie es bei normaler Spannung nicht mehr tun.

Ich hab mir vor ein paar Jahren extra für sowas einen Zwischensockel mit
Diode gebastelt.

Gerrit

[Bernd Ohm]

Post by Gerrit Heitsch
Grund: Durch die niedrigere Betriebsspannung des EPROMs (ca. 0,7V
weniger) kann es sein, daß die in den Floating Gates verbliebenen
Ladungen doch noch reichen wo sie es bei normaler Spannung nicht mehr tun.

Klingt logisch.
Ist das deine Erfindung und/oder gibt es darüber irgendwo
ein paar Details zu lesen?

[Gerrit Heitsch]

Post by Bernd Ohm

Post by Gerrit Heitsch
Grund: Durch die niedrigere Betriebsspannung des EPROMs (ca. 0,7V
weniger) kann es sein, daß die in den Floating Gates verbliebenen
Ladungen doch noch reichen wo sie es bei normaler Spannung nicht mehr tun.

Klingt logisch.
Ist das deine Erfindung und/oder gibt es darüber irgendwo
ein paar Details zu lesen?

Den Tip gibts schon lange, weiss gar nicht mehr woher ich den habe.
Eprommer machen beim Verify das Gegenteil, sie lesen das EPROM mit
erhöhter Spannung (6V oder so) aus.

Gerrit

[Patrick Schaefer]

Post by Gerrit Heitsch
Den Tip gibts schon lange, weiss gar nicht mehr woher ich den habe.
Eprommer machen beim Verify das Gegenteil, sie lesen das EPROM mit
erhöhter Spannung (6V oder so) aus.

So schaut es aus wenn ein EPROM langsam matschig wird:
Loading Image...

Mit weniger Elektronen im floating gate dauert es länger bis der
Transistor aufsteuert. D.h. die Zugriffszeit geht nach oben. Oft lassen
sich EPROMs im Programmiergerät bei Kilohertz-Takt noch auslesen, die in
der Applikation bei einigen MHz nicht mehr laufen.


Zum Refreshen kann man einfach den originalen Inhalt drüberbrennen.
Löschen ist nicht notwendig, so dass originale Aufkleber etc dranbleiben
können. Dann hält es wieder 25 Jahre.


Patrick

[Christian Corti]

Post by Ralf Kiefer
[1] Z.B. in einem externen Diskettenlaufwerksgehäuse mit
5,25"-Laufwerken mit SCSI-Controller von Dayna für Macs. Ich habe
immerhin in den USA einen gefunden, der dieses Gerät auch hat, nur mag
der mir keine Kopie schicken. Also habe ich hier einen hübsch
anzuschauenden Briefbeschwerer :-(

Ach komm, ich habe eine Daynafile II, und auch das EPROM als Image und
disassembliert. Alte Hasen hier erinnern sich vielleicht noch an meine
Aktion "neulich" (vor ca. 15 Jahren ;-) ), als ich beim Versuch, es
auszulesen, die Bonddrähte für die Versorgungsspannung gegrillt hatte,
und dann das Fenster eingeschlagen hatte, um es mit Hilfe von externer
Kontaktierung mittels Nadeln und Mikroskop doch noch auszulesen (hatte
geklappt!). Das EPROM-Image hatte ich nachträglich noch von einem anderen
hier erhalten.
Siehe Posting hier in dafc vom 12.8.2002:
Message-ID: <***@news.informatik.uni-stuttgart.de>

Christian

[Ralf Kiefer]

Post by Christian Corti
Ach komm, ich habe eine Daynafile II, und auch das EPROM als Image und
disassembliert.

Meins ist ein Daynafile ohne "II". Im EPROM (2764) steht sinngemäß
ziemlich am Anfang "Copyright .. 1985, 1986, 1987", keine größere
Jahreszahl. Der Aufkleber sagt Rev. 3.1.

Post by Christian Corti
Alte Hasen hier erinnern sich vielleicht noch an meine
Aktion "neulich" (vor ca. 15 Jahren ;-) ), als ich beim Versuch, es
auszulesen, die Bonddrähte für die Versorgungsspannung gegrillt hatte,
und dann das Fenster eingeschlagen hatte, um es mit Hilfe von externer
Kontaktierung mittels Nadeln und Mikroskop doch noch auszulesen (hatte
geklappt!).

Dieser Thread ist hier nicht erhalten, klingt aber sehr interessant.

Post by Christian Corti
Das EPROM-Image hatte ich nachträglich noch von einem anderen
hier erhalten.

Probieren könnte ich es, wenn Du es mir schickst :-) Es könnte ggf.
sein, daß mein Daynafile ohne "I" und Deins mit "II" Unterschiede haben,
die relevant für die Firmware sind. Auf meiner Hardware sehe ich den
8031 @12MHz, einen 5380, 2* 8kB SRAM, einen 2793 und TTLs.

Das Teil meldet sich überhaupt nicht am SCSI-Bus, die LED vom
Diskettenlaufwerk flackert eher merkwürdig, nachdem die die erste halbe
Sekunde nach dem Einschalten immerhin normal hell geleuchtet hat.

Gruß, Ralf

[Christian Corti]

Post by Ralf Kiefer
Meins ist ein Daynafile ohne "II". Im EPROM (2764) steht sinngemäß
ziemlich am Anfang "Copyright .. 1985, 1986, 1987", keine größere
Jahreszahl. Der Aufkleber sagt Rev. 3.1.

Paßt schon, auf dem Etikett meines Eproms steht:
DaynaFile
Version 3.1
Dayna(c) 1987

Und am Anfang des EPROMs steht:
(C) COPYRIGHT 1985,1986,1987 BY DAYNA COMMUNICATIONS,INC. SALT LAKE
CITY, UTAH -- ALL RIGHTS RESERVED LDA GEG DCO DDP ECJ MEK PLM

Post by Ralf Kiefer
Probieren könnte ich es, wenn Du es mir schickst :-) Es könnte ggf.
sein, daß mein Daynafile ohne "I" und Deins mit "II" Unterschiede haben,
die relevant für die Firmware sind. Auf meiner Hardware sehe ich den

Ist praktisch identisch, nur daß bei mir 1x 32kB SRAM drauf ist (62256).
Ich habe die Dinge auf unseren FTP-Server gelegt:
ftp://computermuseum.informatik.uni-stuttgart.de/daynafile

Da liegen auch ein Bild meiner Platine und das Listing der Firmware.
Ich sollte auch irgendwo den selbstgezeichneten Schaltplan haben, finde
ihn spontan aber nicht. Ich reiche ihn nach, sobald ich ihn gefunden
habe.

Post by Ralf Kiefer
Das Teil meldet sich überhaupt nicht am SCSI-Bus, die LED vom
Diskettenlaufwerk flackert eher merkwürdig, nachdem die die erste halbe
Sekunde nach dem Einschalten immerhin normal hell geleuchtet hat.

Das ist leider so, die DaynaFile spricht zwar auf dem Bus SCSI, aber
kennt keine üblichen SCSI-Kommandos. Man muß das Ding selber
programmieren, was aber den entscheidenden Vorteil hat, daß man wirklich
alles steuern kann, insbesondere, was den FDC angeht ;-)
Die Kommandoliste ist ebenfalls auf dem Server.

Christian

[Ralf Kiefer]

Post by Christian Corti
Ist praktisch identisch, nur daß bei mir 1x 32kB SRAM drauf ist (62256).

Danke. Und die EPROM-Inhalte sind identisch ...

D.h. ich muß an anderer Stelle suchen, mit Eprommer, mit Oszi, usw.

Post by Christian Corti
Das ist leider so, die DaynaFile spricht zwar auf dem Bus SCSI, aber
kennt keine üblichen SCSI-Kommandos.

Ich kam damals (vor ein paar Jahren) zum Ergebnis, daß sich mein Gerät
gar nicht am Bus meldet. Das hat nicht mal auf einen SCSI-Reset
reagiert. Da hier mittlerweile ein Oszi verfügbar ist, werde ich
reinschauen, ob der 8031 überhaupt mit 5380 oder 2773 redet.

Post by Christian Corti
Man muß das Ding selber
programmieren, was aber den entscheidenden Vorteil hat, daß man wirklich
alles steuern kann, insbesondere, was den FDC angeht ;-)

Ich habe diverse Kontrollfelder und Systemerweiterungen hier, z.B. V4.1
und V2.2 zu System 6.0.

Gruß, Ralf

[Christian Zietz]

Post by Ralf Kiefer
BTW Du hast den EPROM-Inhalt bereits kopiert und gebackupt?

In dem Kontext habe ich mal meine Atari SH204 auseinandergenommen; gar
nicht so einfach aufgrund der üppigen Verwendung von Loctite. Zu meiner
Überraschung ist der Adaptec ACB-4000A darin offenbar eine
Atari-Lizenzfertigung. Gegenüber
<Loading Image...> fehlt der
"Adaptec"-Schriftzug in der oberen Ecke und statt des EPROMs befindet
sich ein PROM/Masken-ROM (zumindest kein Fenster) mit Atari-Teilenummer
im Sockel.

Diese Firmware kann ich natürlich auch auslesen, wenngleich zumindest
ein Masken-ROM nicht so schnell schlecht werden dürfte. Wie reicht man
denn Sachen für Bitsavers ein?

Christian

PS: Auch überraschend finde ich, dass Microsemi (denen gehört Adaptec
jetzt) sogar noch eine Produktseite samt Handbuchdownload für den
Controller haben:
<https://storage.microsemi.com/en-us/support/_eol/acb/acb-4000a/>

[Ralf Kiefer]

Post by Christian Zietz
In dem Kontext habe ich mal meine Atari SH204 auseinandergenommen;

Das sollte ich vielleicht auch tun :-)

Post by Christian Zietz
Diese Firmware kann ich natürlich auch auslesen, wenngleich zumindest
ein Masken-ROM nicht so schnell schlecht werden dürfte.

Das sollte überhaupt nicht schlecht werden. Außer natürlich auf den
Wegen, wie man auch andere ICs himmelt.

Post by Christian Zietz
Wie reicht man
denn Sachen für Bitsavers ein?

Auf der Web-Seite steht unten eine Mail-Adresse. Hinschicken! Ich war
allerdings nach ein paar Aktion im Laufe der vergangenen Monate leider
nicht begeistert vom Ablauf.

Gruß, Ralf

[Christian Zietz]

Post by Ralf Kiefer

Post by Christian Zietz
Wie reicht man
denn Sachen für Bitsavers ein?

Auf der Web-Seite steht unten eine Mail-Adresse. Hinschicken! Ich war
allerdings nach ein paar Aktion im Laufe der vergangenen Monate leider
nicht begeistert vom Ablauf.

Nun, mein Dump hat die gleiche MD5-Summe wie die Firmware
"ACB-4000A_410041-00A", die es schon bei Bitsavers gibt, also hat sich
das erledigt.

Christian

[Volker Borchert]

Post by Christian Zietz
statt des EPROMs befindet
sich ein PROM/Masken-ROM (zumindest kein Fenster)

Es gab seinerzeit Bausteine zur Verwendung als PROM, die einen
normalen EPROM-Chip im normalen Plastik-DIP enthielten.

So brauchte man einerseits keine teuren Masken, andererseits
keine teuren Keramik-DIP mit Quarzglasfenster.

Heutzutage durch (leider eben auch durch Malware) in-circuit
überschreibbare Flash-Speicher nicht wirklich ersetzt.

[Ralf Kiefer]

Post by Volker Borchert
Es gab seinerzeit Bausteine zur Verwendung als PROM, die einen
normalen EPROM-Chip im normalen Plastik-DIP enthielten.

OTP oder OTPROM. Die haben dieselbe Schwäche wie normale EPROMs, außer
daß sie durch UV nicht gelöscht werden. Die heißen genauso 27xx auch im
Plastikgehäuse.


Gruß, Ralf

[Markus Elsken]

Moin!

Post by Volker Borchert
Es gab seinerzeit Bausteine zur Verwendung als PROM, die einen
normalen EPROM-Chip im normalen Plastik-DIP enthielten.

Die billigen OTP-Eproms für kleinere und mittlere Serien, ja. Waren eine
Zeitlang viel auf Festplatten der 1GB-Klasse drauf und in Telefonanlagen
drin. Flash war damals wohl noch zu teuer...

mfg Markus