In einigen Maschinen in der Firma hier werden SCSI-Floppy-Laufwerke verwendet, die oben ein gewöhnliches TEAC-Floppy-Laufwerk mit 34pinnigem Anschluß haben und unten eine angeschraubte Adapter-Platine Floppy <-> SCSI 50polig, Typ "TEAC FC-1", auf dem Aufkleber auf dem Blech "TEAC FD-235HS 900". Allerdings kann ich die weder mit einem USB-SCIS-Adapter vom Typ USB2xchange ansprechen, noch mit einer 64bit PCI-Karte (Adaptec-Controller), obwohl SCSI-Platten von 53 MB (nicht GB) bis 8 GB problemlos an dem USB2xchange und der PCI-Karte funktionieren. Bei dem USB2xchange wird einfach nichts angezeigt, so als ob nichts angeschlossen wäre. In dem SCSI-BIOS von der PCI-Karte, per Ctrl-A aufgerufen, hängt der Scan vom SCSI-Bus schon bei der ID 0. Ist es normal das solche SCSI-Floppy-Laufwerke nur an mindestens 25 Jahre alten SCSI-Controllern (und unter obskuren Closed-Source-Betriebssystemen) betrieben werden können?
Rolf F. schrieb: > In dem SCSI-BIOS von der PCI-Karte, per Ctrl-A aufgerufen, hängt der > Scan vom SCSI-Bus schon bei der ID 0. Hast du mal die komplette sync negotiation ausgeschaltet da im BIOS? Kann gut sein, dass der Kram nur async SCSI (3,3 MHz) macht, was ja für die exorbitant hohe Geschwindigkeit so einer Floppy ausreicht. Ich habe sowas das letzte Mal vor 20 Jahren in der Hand gehabt. Das waren 8-Zoll-Floppies zur Steuerung von Webmaschinen, die via SCSI an Workstations von Data General hingen. Mit bisschen Glück hätte ich vielleicht noch einen AHA1540 herumliegen, falls du damit mal testen willst.
20 Jahre kann gut passen... Die Dinger dürte SCSI-1 machen, ob ich sie an einem Adaptec damals dran hatte weiß ich nicht mehr. Sync sollte eigentlich gehen, ASync ist aber sicherer zum Testen. Bei Adaptec alles automatisch aus machen, Terminierung gut beachten, speziell, wenn es ein UW-Host mit Adaptern ist. Möglichst nicht ID 0 und ID 1 nehmen, einige Adaptecs habe da wohl ein Eigenleben (Booten von SCSI). Am Amiga hat sich das Ding als normales Wechsellaufwerk gemeldet und ich konnte damit machen, was ich wollte. Auch 3 Amiga-Partitionen auf einer 1,44MB Disk einrichten und mit FFS formatieren usw. Der Bus-Scan sollte zumindest erstmal durchlaufen. Gruß aus Berlin Michael
tja der Amiga hatte es eben drauf. Habe meine beiden Amiga auch noch. :-))
Also das sync negotiation war die Lösung danke! Allerdings konnte ich das bei dem Adaptec 29160 nicht konfigurieren, so das ich einen älteren AHA-2940/2940U raussuchen musste, mit dem es endlich funktionerte, wobei der das sync negotiation bei dem Controller selber auf yes steht.
Jetzt stellt sich noch die Frage ob es auch USB-SCSI-Adapter gibt, bei denen man Sync Negotiation abstellen kann. Gibt es solche Adapter?
Es gibt neben der SCSI-Version und der Busbreite (8/16/32 Bit, letzteres nicht verbreitet) erhebliche Unterschiede bezüglich der Signalpegel: - SE (single ended) - HVD (high voltage differential) - LVD (low voltage differential) Diese Signalpegel sind nicht zueinander kompatibel. Ursprünglich war eigentlich nur SE gebräuchlich. HVD wurde für räumlich abgesetzte Bandlaufwerke usw. verwendet. Die letzten SCSI-Platten (und Controller) waren aber überwiegend LVD, insbesondere die SCA-Laufwerke für Backplanes in Servern. Sun hat bei etlichen System auch SCSI-Diskettenlaufwerke eingesetzt, z.B. in der E450. Dort befand sich auf demselben Bus auch das CD-ROM-Laufwerk; beide Geräte hingen an einem 8Bit-SE-Bus. Die internen Festplatten wurden durchgängig mit 16Bit LVD betrieben. Achtung: Den SCSI-Controllern sieht man nicht auf den ersten Blick an, ob sie für HVD oder LVD sind! Irgendwann verkaufte mir damals ein Systemhaus einen falschen Controller, was ich aber noch rechtzeitig bemerkte. Warum schreibst Du nicht den ganz konkreten Typ Deines SCSI-Controllers? Nachtrag: Ich habe gerade nachgelesen, dass es SCA-Geräte auch mit HVD gab...
:
Bearbeitet durch User
Andreas Schweigstill schrieb: > Diese Signalpegel sind nicht zueinander kompatibel. Nur HVD ist inkompatibel, ist aber hier eh' nicht das Thema. LVD ist ja eben deshalb erfunden worden, um eine einfache Migration von SE zu ermöglichen. Ist halt nur so, dass man mit dem ersten SE-Gerät am Bus den ganzen Bus auf SE runterzieht, aber das ist hier sicher nicht das Thema. Das Laufwerk wird simples uraltes SE sein, denn das teure HVD hat man dazumals nur (wie du schon schriebst) für abgesetzte Kisten benutzt, bei denen man lange Kabel ermöglichen wollte. (Übrigens ist auch HVD so konzipiert worden, dass die Bustreiber sich abschalten, wenn sie ein SE-Gerät am Bus entdecken.)
Hat mich damals nur ein wenig tangiert. ;-) Für SCA-80 gab es Adapter zum Ranstecken (gerade entdeckt: hat Amazon noch im Angebot: SCA-80 auf 50/68-Pin mit Jumpern für ID usw für 6,78€). So lustige Kombis wie 50-Pin CD-LW, 2x 68-Pin UW-HD, 2x SCA-80 mit Adapter, der UW-Host mittendrin und nach außen noch mit 50->25 polig zum SCSI-Scanner wurden dann schnell zur Herausforderung... Gruß aus Berlin Michael
Michael U. schrieb: > SCA-80 auf 50/68-Pin Mit denen muss man aber vorsichtig sein: die funktionieren nach meiner Erfahrung nicht an Bussen mit höheren Geschwindigkeiten, dafür sind sie zu grottig. Dort gehen nur die SCA-80 auf 68-Pin, die keinen 50er Connector mehr haben, ansonsten hängt sich der ganze Salat genauso schön auf wie beim TE. (Vermutlich belasten die zusätzlichen Pins des 50er Connectors die eine Bushälfte zu stark asymmetrisch.)
Problem ist da vermutlich, daß man das eigentlich nicht sauber terminieren kann. Am Ende eines 50-pol. Busses müßte ein Terminator auf den 68-Pin-Anschluß, sonst sind die oberen Leitungen nicht terminiert und das verstehen einige Laufwerke nicht. Solche Konstrukte gehen eigentlich immer an der SCSI-Norm vorbei, trotzdem spielte das privat meist stabil, wenn man mal die funktionieren Variante gefunden hatte. Naja, mehr als 10MB/s, Wide und Sync war am Amiga Phase 5 Controller sowieso nicht drin. Gruß aus Berlin Michael
Michael U. schrieb: > Am Ende eines 50-pol. Busses müßte ein Terminator auf den > 68-Pin-Anschluß Ich meinte ja, wenn man einen der von dir genannten Adapter versucht, an einem moderneren 68-poligen LVD-Bus zu benutzen. Das geht mit diesen Adaptern schief (zumindest mit den Teilen, die ich noch rumliegen habe). Ersatz des SCA-Adapters durch einen, der auf der anderen Seite nur einen 68er Stecker hat, brachte dann Abhilfe. War natürlich ein 160er oder gar 320er Bus, an dem das laufen sollte.
Jörg Wunsch schrieb: > (Vermutlich belasten die zusätzlichen Pins des > 50er Connectors die eine Bushälfte zu stark asymmetrisch.) Der ganze SCSI-Kram funktionierte meist nur mit der richtigen Terminierung wenn mehr als ein Gerät angeschlossen wurde! Evtl. war der Terminator oder die größere Kabellänge schon ein Fehler?
Rolf F. schrieb: > Jetzt stellt sich noch die Frage ob es auch USB-SCSI-Adapter gibt, bei > denen man Sync Negotiation abstellen kann. Gibt es überhaupt noch USB-SCSI-Adapter? Adaptec hat schon lange aufgehört, so etwas herzustellen, und Ratoc machts auch schon etliche Jahre nicht mehr. So um die Jahrtausendwende herum gab es mal einen "Adaptex USB XChange 2000" (sp?), für den Adaptec aber nie Treiber für ernstgemeinte Betriebssysteme lieferte (auch nicht für das damals aktuelle Windows 2000, obwohl die 2000 im Produktnamen geführt wurde ...). Von Shuttle (SCM) gab es ein ähnliches Produkt, dessen Treiber sich verwenden ließ, aber sehr ... wackelig war; Plug&Play ging gar nicht. Wenn man nur ein Gerät betreiben wollte, und das auch noch Festplatte/CD-/MO-Laufwerk war, dann musste man das als alleiniges Gerät am "Bus" mit ID0 betreiben und konnte ohne Treiber arbeiten, weil in diesem Fall sich das Gerät als "USB Mass Storage Device" verkaufte. Immerhin.
Ja SCSI war schon ne feine Sache, auch wenn es seine Tücken hatte. Die Kombi LVD, UW & 25 pol. SE an einem Controller kann man schon mal vergessen. Das ist zwar prinzipiell abwärtskompartibel, aber vergleichbar mit Fahrrad und Autobahn. Prinzipiell müßte das auch funktionieren... ;-) In diesem Fall habe ich lieber 2 Controller genommen. Für die Problematik, das ein SE Gerät am Bus LVD auf SE runtergebremst hat, gab es 2 Ansätze: - Adaptec baute auf seine Controller eine SCSI-Bridge, die vermittelte. Man mußte dann schauen, wo welcher Anschluss war. - von Symbios gab es Dualchannel LVD Controller. So konnte man an einen Controller alle LVD und an den anderen die SE Geräte hängen. Hatte den Vorteil, das man auf jedem Bus jeweils 15 Dev-ID's hatte. Ich hatte so einen SCA nach 68 pol & 50 pol. zu was anderem "missbraucht". Im SCSI Kabel gibt es neben einem Haufen Masseadern auch +5V Termpower zur Versorgung der Terminatoren am Kabelende. Die griff ich per Jumper ab und ging auf ein kleines SSR, womit ich ein altes AT-Netzteil für ein externes SCSI Gehäuse schaltete. Bis das Mainboard-BIOS durch war, liefen die Platten schon längst, so das sie problemlos erkannt wurden.
Gerald B. schrieb: > Ja SCSI war schon ne feine Sache, auch wenn es seine Tücken hatte. Naja, für die Zeit gab es halt kaum Alternativen, die mit der Geschwindigkeit mithalten konnten. Aber so wirklich schönes Arbeiten war es nie. Es ging schon damit los, daß keine Einheitlichkeit bei den Plattenparametern bestand, d.h. an Controller A formatierte Platte lief nicht (oder noch schlimmer: vorerst unbemerkt nicht richtig) an Controller B. Es setzte sich fort mit dem unsäglichen Terminierungsspektakel über störrische, schlecht zu verlegende Kabel bis hin zu sporadischen, schwer einzugrenzenden Fehlern durch einzelne Geräte am Bus. Ich heule SCSI nicht nach, im Gegenteil. Schnelle SATA-Anschlüsse in Verbindung mit schnellen Festplatten (WD Velociraptor) stehen den Lärm und Hitze produzierenden Dinosauriern in punkto Datenrate und Zugriffszeit kaum nach, verbrauchen nur einen Bruchteil des Stromes und benötigen keine aufwendige Kühlung. Für externe Geräte gibt es USB. Früher war nicht alles besser...
Damals gab es an Datenbussen nicht so viel Auswahl. IDE oder SCSI. Und Für seine Zeit war SCSI sehr fortschrittlich. NCQ beherrschte SCSI nativ, ohne Handstände. Das kam erst später bei SATA. Und mit der Plattenadressierung mußt du was verwechseln. Bei IDE mußte man in der Anfangszeit die Parameter dier Plattengeometrie angeben. Bei SCSI funktionierte es benfalls "einfach so" Genauso stressloses CD-Brennen. Bei einem reinen SCSI Systen war Bufferunderrun ein Fremdwort. Bei IDE brauchte man nur mal die Maus schief angucken. ASPI Treiber für Brenner funktionierten auf einem SCSI System. Bei IDE war das Glückssache und Brennprogramme funktionierten erst Jahre später stressfrei. Ein SCSI Kabel durfte pro Busseite 1,5m lang sein, je nach Norm auch länger. Bei IDE waren die Kabel 40 oder waren es 60? cm lang. Ich will meine SSD auch nicht mehr gegen eine mit 15.000 U/min pfeifende Cheetah, die man nur aktiv gekühlt betreiben konnte, hergeben :-)
Übrigens habe ich auch versucht einen üblichen billigen USB-Floppy-Emulator, der am Floppy-Anschluß eines alten PCs problemlos funktioniert, über dieses "TEAC FC-1" zum Laufen zu bekommen, aber das wird von dem Uralt-Rechner nicht gefunden. Und Alternativen wie ein DTX200* sind teuer und in der Handhabung sehr umständlich.
Jörg Wunsch schrieb: > LVD ist ja eben deshalb erfunden worden, um eine einfache Migration > von SE zu ermöglichen. Tatsächlich? Oder hatte man SE bloss deshalb als Option in LVD eingebaut, weil es zu einem Zeitpunkt definiert wurde, zu dem solche Interfaces bereits vollintegriert implementiert wurden und es folglich einfach möglich war? Ich hatte eher den Eindruck, dass die Forderung nach Durchsatz für LVD eine wesentliche Rolle spielte. LVD lässt sich elektrisch leichter beschleunigen als HVD.
:
Bearbeitet durch User
Gerald B. schrieb: > Damals gab es an Datenbussen nicht so viel Auswahl. IDE oder SCSI. Zunächst eher ST506 oder ESDI v. SCSI. IDE kam erheblich später. SCSI steckt heute in so ziemlich jedem Speichermedium, das keine Festplatte ist (oder so tut als wäre es eine). Nicht elektrisch, aber als Protokoll. Auch in CD/DVD-Laufwerken, egal ob SATA oder IDE.
:
Bearbeitet durch User
A. K. schrieb: > Tatsächlich? Oder hatte man SE bloss deshalb als Option in LVD > eingebaut, weil es zu einem Zeitpunkt definiert wurde, zu dem solche > Interfaces bereits vollintegriert implementiert wurden und es folglich > einfach möglich war? Ja, aber der Dreh war eben, dass du existierende Hardware weiter nutzen konntest (natürlich dann nur auf deren Niveau) – im Gegensatz zu HVD eben. Ansonsten hätte man ja angesichts von HVD LVD gar nicht erst erfinden müssen, die zulässigen Kabellängen sind gleich. Gerald B. schrieb: > ch will meine SSD auch nicht mehr gegen eine mit 15.000 U/min pfeifende > Cheetah, die man nur aktiv gekühlt betreiben konnte, hergeben :-) Ich habe hier noch als primäre Platten zwei 76-GB-SCSI-Platten laufen, eine SATA-Platte dann nur als „Datenmüllhalde“ für alles, wo's nicht so drauf ankommt. Die sind nach wie vor um Welten schneller als SATA, nicht von der theoretischen Geschwindigkeit des Interfaces, aber sehr wohl im praktischen Betrieb. Das hängt weniger mit dem Bus zusammen, sondern mehr mit dem Aufwand, der in den Platten getrieben worden ist (weshalb sie natürlich teurer waren). Klar, eine SSD ist dann nochmal 'ne andere Nummer, wobei die Lebensdauer der rotierenden Platte wohl besser sein dürfte. ;-) Aber das bewegt sich nun schon weit weg vom Thema. Nein, ich habe auch keine Ahnung, wie man das mit der Floppy noch machen könnte. Einen Mikrocontroller nehmen, der auf der einen Seite ein USB mass storage device bildet und auf der anderen Seite einen kleinen ISA-SCSI-Controller bedient. ;-)
Hallo, eigentlich hatte ich nie Probleme meine alten SCSI-Geräte wie Scanner und Festplatten an aktuelleren SCSI-Adaptern (z.B. HA-2940U2W) zu betreiben. Entsprechende Anschlussadapter vorausgesetzt. Wie bereits erwähnt ist jedoch die richtige Terminierung sehr wichtig. Am besten sind hier SCSI-Kabel mit einer Terminierung an einem Ende. Das Andere Ende des SCSI-Kabels kommt in den SCSI-Controller. Alle weiteren SCSI-Geräte dürfen nicht terminiert sein. Noch ein kleiner Hinweis: Ein SCSI-Gerät mit 8 Bit Busbreite kann nicht alle 16 Bit eines 16 Bit Controllers terminieren. Rolf F. schrieb: > In dem SCSI-BIOS von der PCI-Karte, per Ctrl-A aufgerufen, hängt der > Scan vom SCSI-Bus schon bei der ID 0. Dies könnte durchaus ein Terminierungsproblem sein. Mit freundlichen Grüßen Guido PS.: Musste man nicht für alle SCSI-Geräte, die keine Festplatten waren, einen ASPI-Treiber laden?
Guido C. schrieb: > Am besten sind hier SCSI-Kabel mit einer Terminierung an einem Ende. Naja, aber bei den alten asynchronen 8-Bittern wie hier war das alles noch nicht so dramatisch. Da waren auch noch diese einfachen SIP-Widerstandskombinationen teils üblich, die man im Gerät selbst gestöpselt hat. > Musste man nicht für alle SCSI-Geräte, die keine Festplatten waren, > einen ASPI-Treiber laden? Unter Unixen nicht. :-))
:
Bearbeitet durch Moderator
Hallo, Jörg Wunsch schrieb: > Da waren auch noch diese einfachen > SIP-Widerstandskombinationen teils üblich, die man im Gerät selbst > gestöpselt hat. stimmt, von denen habe ich heute sogar noch ein paar herumliegen. Ich fand die Dinger schrecklich, zumal sie nicht bei allen Geräten gleich (breit) waren. Mit freundlichen Grüßen Guido
220/330 Ohm? Müßten hier auch noch in irgendeiner Schachtel rumliegen... Gruß aus Berlin Michael
Jörg Wunsch schrieb: > Ansonsten hätte man ja angesichts von HVD LVD gar nicht > erst erfinden müssen, die zulässigen Kabellängen sind gleich. Der Schritt zu LVD brachte (zunächst) Faktor 2 beim Tempo. HVD und LVD unterscheiden sich im Stromverbrauch, insbesondere je schneller es wird.
:
Bearbeitet durch User
A. K. schrieb: > Der Schritt zu LVD brachte (zunächst) Faktor 2 beim Tempo. Ist aber nicht so, dass man das nicht hätte auch mit HVD haben können.
Gerald B. schrieb: > Bei IDE mußte man in der > Anfangszeit die Parameter dier Plattengeometrie angeben. > Bei SCSI funktionierte es benfalls "einfach so" Eben nicht so ganz. Die Geometrie, mit der die Platten angesprochen wurden, variierte von einem Hersteller zum anderen. So konnte man bspw. einen Adaptec nicht durch einen Future Domain Controller ersetzen (oder umgekehrt), ohne die Platte neu zu partitioniere/formatieren. In Unkenntnis dieser Tatsache habe ich als Frischling mal einen Novell-Server verkackt. Das Volume ließ sich zwar noch mounten, aber nach den ersten Schreibzugriffen ging nix mehr. Zum Glück existierte ein Backup, dessen Restore vom Floppystreamer mich aber eine ganze Nacht kostete.
:
Bearbeitet durch User
Icke ®. schrieb: > Gerald B. schrieb: >> Bei IDE mußte man in der >> Anfangszeit die Parameter dier Plattengeometrie angeben. >> Bei SCSI funktionierte es benfalls "einfach so" > > Eben nicht so ganz. Die Geometrie, mit der die Platten angesprochen > wurden, variierte von einem Hersteller zum anderen. So konnte man bspw. > einen Adaptec nicht durch einen Future Domain Controller ersetzen (oder > umgekehrt), ohne die Platte neu zu partitioniere/formatieren. In > Unkenntnis dieser Tatsache habe ich als Frischling mal einen > Novell-Server verkackt. Das Volume ließ sich zwar noch mounten, aber > nach den ersten Schreibzugriffen ging nix mehr. Zum Glück existierte ein > Backup, dessen Restore vom Floppystreamer mich aber eine ganze Nacht > kostete. Hm, ich hatte von Adaptec angefangen vom 2940UW, den U2W, einen Dualchannel 160 von Iwill und auf einem Asus TR-DLS einen Dualchannel 160 Symbios. Ich habe Platten von einem Controller zum anderen umgezogen, ich hatte da nie Probleme. Ich habe diesbezüglich auch noch nie von Problemen oder einstellbaren Parametern bei den Controllern was gehört oder gelesen. Daher überrascht mich jetzt deine Aussage.
Gerald B. schrieb: > Ich habe diesbezüglich auch noch > nie von Problemen oder einstellbaren Parametern bei den Controllern was > gehört oder gelesen. Einstellbar ist da auch nichts, das machen die Controller (bzw. deren Firmware) intern. Wobei natürlich nicht ausgeschlossen ist, daß es trotz unterschiedlicher Hersteller funktionieren KANN (aber nicht MUSS).
Gerald B. schrieb: > Ich habe diesbezüglich auch noch > nie von Problemen oder einstellbaren Parametern bei den Controllern was > gehört oder gelesen. Daher überrascht mich jetzt deine Aussage. Das war einfach nur eine Frage der Abbildung der SCSI Blocknummer auf die damalige Cylinder/Head/Sector Adressierung durch BIOS und Betriebssystem. Die Partitionierung wiederspiegelte dies. Darin waren anfangs nur die C/H/S Werte relevant und die auch schon immer vorhandene Blocknummer nur Ausschmückung. Später kehrte sich das um. Verschiedene Controller-Hersteller wählten teils verschiedene Algorithmen dafür. Weshalb Plattentausch zwischen Controllern Probleme verursachte. Mancher war auch ganz pragmatisch und hat aus einer vorhandenen Partitionierung den Algorithmus abgeleitet. Der kam folglich mit allem klar. Seit Betriebssysteme im Interface zur Hardware nicht mehr auf Basis von C/H/S arbeiten, sondern ebenfalls Blocknummern verwenden, ist das kein Thema mehr. SSDs und 4K-Disks habe da freilich aufgrund Alignment-Restriktionen wieder neue Akzente gesetzt, gewissermassen die Wiederauferstehung der Disk-Zylinder in neuem Gewande.
:
Bearbeitet durch User
Gerald B. schrieb: > Daher überrascht mich jetzt deine Aussage. Das dürfte etliche Jahre vor Deinen Erfahrungen gewesen sein. Das Phänomen gab es auch eine Zeitlang bei IDE-Platten, als die mit verschiedenen CHS-Mappings angesprochen werden konnten und das BIOS sich selbst eins aussuchte ...
A. K. schrieb: > Darin waren anfangs nur die C/H/S Werte relevant Was der eigentliche Geburtsfehler dieses Prinzips ist. Nur, damit man ein paar Bytes im BIOS spart und statt der (ohnehin vorhandenen) Blocknummern gleich die passenden Register für den BIOS-Aufruf aus der Tabelle popeln kann, hat uns IBM diese Odyssee beschert. Rufus Τ. Firefly schrieb: > Das Phänomen gab es auch eine Zeitlang bei IDE-Platten Dort kenne ich es eigentlich (sicher auch aufgrund des viel größeren Wildwuchses bei den PC-BIOSen – bei SCSI kam das zugehörige BIOS ja vom Adapterhersteller, und das waren nicht viele) deutlich krasser. Plattentausch zwischen zwei Computern war völlige Glückssache. Bei meinen damals aufgesetzten FreeBSDs war ich deshalb Fan davon, die fdisk-Partitionierung komplett wegzulassen, und das OS ab Block 0 beginnen zu lassen – dem einzigen Block der Platte, der konsistent immer auf CHS 0,0,1 übersetzt wird. ;)
Jörg Wunsch schrieb: > Was der eigentliche Geburtsfehler dieses Prinzips ist. Yep. Nur hatte IBM diesen Rechner nie als Mainframe-Ersatz konzipiert. Ganz im Gegenteil. Da waren anfangs auch nur Floppy-Disks drin. Ist auch nicht der einzige Geburtsfehler dieser Technik, die besteht geradezu daraus. > Bei meinen damals aufgesetzten FreeBSDs war ich deshalb Fan davon, > die fdisk-Partitionierung komplett wegzulassen, und das OS ab Block 0 > beginnen zu lassen – dem einzigen Block der Platte, der konsistent > immer auf CHS 0,0,1 übersetzt wird. ;) Dafür hat(te?) der frische Anwender bei den BSDs eine völlig neue Welt der Partitionierung an der Backe. Dessen eigene Subpartitionierung.
:
Bearbeitet durch User
A. K. schrieb: > Ist auch nicht der einzige Geburtsfehler dieser Technik, die besteht > geradezu daraus. Ich habe ja den Verdacht, daß ein paar (gute) Werksstudenten bei IBM sich einen Witz dabei gemacht haben, wieviel man beim Design eines Rechners grundlegend* falsch machen kann, so daß es trotzdem möglich ist, eine Funktion vorzutäuschen ... Und irgendein Vorgesetzter hat das Ding gesehen und für das schickste seit Erfindung von gekochten Nudeln im Glas gehalten. Der Rest ist Geschichte. *) Z.B. flankengesteuerte active-High-Interrupts. Kann man Interruptsharing noch effizienter verhindern?
Rufus Τ. Firefly schrieb: > *) Z.B. flankengesteuerte active-High-Interrupts. Kann man > Interruptsharing noch effizienter verhindern? Deine Werkstudenten haben dann fröhlich weiter gemacht. Beim AT haben sie es geschafft, den Board-Designern einen Bus unterzumogeln, bei dem man eigentlich eine Zeitmaschine braucht. Weil basierend auf den Adressen eine Entscheidung getroffen werden muss, bevor diese Adressen überhaupt anliegen. Wenn man genau nachrechnet. ;-)
:
Bearbeitet durch User
Frei nach Arthur C. Clarke: "Any sufficiently bad technology is indistinguishable from success."
Und angeblich war das originale 5170-Netzteil auch so blöd dimensioniert dass man beim Modell ohne Festplatte einen Heizwiderstand einbaute um dieses nicht zu unterlasten. Anti-Green-IT sozusagen.
Andy D. schrieb: > Und angeblich war das originale 5170-Netzteil auch so blöd dimensioniert > dass man beim Modell ohne Festplatte einen Heizwiderstand einbaute um > dieses nicht zu unterlasten. Anti-Green-IT sozusagen. Das Problem gibt es in verschiedenen Varianten immer wieder neu. Beispielsweise in Form zu langer Überbrückungszeit im Standby, denn da möchte man nach x Sekunden Netzspannungsunterbrechung das die Standby-Spannung auf praktisch Null fällt, damit wenn die Spannung wieder kommt der Rechner automatisch startet (Power on AC loss restart im BIOS). Ein Anwendungsfall ist eine Maschine mit Rechner für X Sekunden aus- und dann wieder einschalten. Ein anderer ist den Recher an einer USV runterfahren bevor der Akku leer ist, denn die USV macht nach dem Netzausfall für y Sekunden unterbrechen der Netzspannung (am Ausgang) um den Rechner aufzuwecken. Daher darf die Überbrückungszeit nicht zu lang sein, sollte maximal 5 s betragen, aber bei einem Netzteil lag die bei einer halben Minute und daher wurde von einer Firma extra ein Widerstand eingebaut, damit der PC in der Maschine richtig funktioniert. Dies ist aber auch ein Schwachpunkt von praktisch allen Netzteil-Tests und Spezifikationen und folglich gibt es viel Murks am Markt.
:
Bearbeitet durch User
A. K. schrieb: > Yep. Nur hatte IBM diesen Rechner nie als Mainframe-Ersatz konzipiert. Genau, sonst hätten wir jetzt nämlich Sektorgrößen von 520 Byte statt 512 Byte. Bei einigen Festplatten kann man diese Sektorgrößenumschaltung durchaus vornehmen, vornehmlich bei solchen, die in Speichersystemen für Mainframes eingesetzt werden (z.B. EMC² Symmetrix). > Ganz im Gegenteil. Da waren anfangs auch nur Floppy-Disks drin. Der Original-PC hatte auch eine Kassettenrekorderschnittstelle... > Ist auch nicht der einzige Geburtsfehler dieser Technik, die besteht > geradezu daraus. Das hatte sicherlich auch eine gewisse Absicht. Man wollte sich nämlich nicht das sehr einträgliche Geschäft mit Rechnern der mittleren Datentechnik (System/34, später AS/400) kanibalisieren und sorgte deswegen dafür, dass der PC eben leistungsmäßig weit dahinter blieb. Ich vermute, dass der IBM-interne Druck zugunsten dieser Missgeburt sogar viel ausschlaggebender war als die echten externen Markterfordernisse. Hinsichtlich der Komplexität war der IBM PC ja durchaus mit den hauseigenen Terminals der 5250-Klasse vergleichbar. Kurz darauf brachte IBM ja auch die für den asiatischen Markt bestimmten 5550 auf den Markt, die einen 8086 beinhalteten und mit DOS liefen. Der "echte" PC hatte leider eine viel zu schlechte Grafik, um darauf asiatische Schriftzeichen darzustellen. Die 5550 waren für den Zwitterbetrieb vorgesehen, d.h. lokale Textverarbeitung und Terminalbetrieb an IBM Mainframes.
Andy D. schrieb: > Und angeblich war das originale 5170-Netzteil auch so blöd dimensioniert > dass man beim Modell ohne Festplatte einen Heizwiderstand einbaute um > dieses nicht zu unterlasten. Anti-Green-IT sozusagen. Als die ersten energieeffizienten PKW-Scheinwerfer auf den Markt kamen, mussten dort auch Heizwiderstände eingebaut werden, da in der StVZO die Leistungsaufnahme für Abblend- und Fernlicht genau vorgegeben war. Ich weiß leider nicht, ob das heute immer noch so ist oder ob statt der Leistungsaufnahme mittlerweile die Lichtabgabe als relevante Größe angesehen wird.
A. K. schrieb: > Dafür hat(te?) der frische Anwender bei den BSDs eine völlig neue Welt > der Partitionierung an der Backe. Dessen eigene Subpartitionierung. Die allerdings konsistent zwischen den BSDs war, egal ob sie nun auf einem PeeZeh laufen, einer Sun oder was auch immer. Mittlerweile nimmt man aber besser GPT und ZFS. :-) Andreas Schweigstill schrieb: > Ich weiß leider nicht, ob das heute immer noch so ist oder ob statt der > Leistungsaufnahme mittlerweile die Lichtabgabe als relevante Größe > angesehen wird. Wird wohl so sein, ist inzwischen sogar bei Fahrrädern angekommen (10 lux in 10 m mindestens).
Braucht wer SCSI Eqipment? SCSI Controller Adaptec AH 2940/2940U,Teak Cd Brenner,Pioneer Slot in DVD für umme?
herbert schrieb: > Pioneer Slot in DVD für umme? Übrigens wunderbare, haltbare Laufwerke. Habe hier zwei mit IDE und hatte damals auch eines mit SCSI für den Mac. Der Mac ist beim Altmetall, deswegen kein Interesse. Aber schöne Drives sind das...
Matthias Sch. schrieb: > Aber schöne Drives sind das... Ja, das Teac hatte ich mal aufgemacht und das Innenleben mit einem heutigen Laufwerk verglichen. Da liegen Welten konstruktiver Art zwischen beiden... das merkt man aber auch schon wenn man die ohne zu öffnen in die Hand nimmmt alleine schon am Gewicht.
Matthias Sch. schrieb: > herbert schrieb: >> Pioneer Slot in DVD für umme? > > Übrigens wunderbare, haltbare Laufwerke. Habe hier zwei mit IDE und > hatte damals auch eines mit SCSI für den Mac. Der Mac ist beim > Altmetall, deswegen kein Interesse. Aber schöne Drives sind das... Hatte ich auch mal für IDE, weil mir das Slot-In sehr gefiel. Leider war das Ding monströs laut.
Reinhard S. schrieb: > Hatte ich auch mal für IDE, weil mir das Slot-In sehr gefiel. Leider war > das Ding monströs laut. Jajaja, da war irgendwas - frag mich nicht, aber ich habe damals eine Firmware eingeladen, die die max. Geschwindigkeit runtersetzte, wimre von 16X auf 8X oder so. Damit war das Wummern beim Laden der Scheibe weg. Und wer braucht schon 16X?
Ich hatte das SCSI DVD von Pioneer. Hat mich 150 Piepen neu gekostet, war aber auch supergut. Mit einer undokumentierten Jumperstellung wurde der Regionalcode nicht gesetzt. Hatte das Teil die ersten Jahre zum DVD "archivieren", seine Rente fristete es dann in meinem Fileserver, weil das Serverboard halt SCSI onboard hatte und ich für System- und Backup Platte auch SCSI nutzte. Das RAID Arry bestand dann aber schon aus SATA Platten :-) Da ich den Server geschlachtet und verkauft habe, habe ich an SCSI noch ein paar neue LVD Kabel und 2-3 Controller und Platten im Schrank, aber aktiv im Einsatz habe ich nix mehr davon. Als ich dienstlich mal bei den Amis drüben war, habe ich bei Fry's Electronic LVD Kabel aus Teflon von Granite gesehen. Goil! Wuße bis da hin garnicht, das es sowas gibt. Teflon hat eine niedrigere Dielektizitätskonstante, als PVC und darum sind die kapazitiven Verluste im Kabel pro Meter Länge nicht so hoch.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.