Ich denke mal, das SCSI wie SATA und IDE erstmak nur eine Schnittstelle, jedoch mit mehr Protokollen ist. Timings ect. sind "genormt".
Wenn du sowas aber nun emulierst, läuft es nie zu 100% perfekt mit den Timings und Protokollen, da musst du schon ein wenig auf die Eigenheiten der Controller anpassen.
Wo fängt bei einer Hardwareschnittstelle die "Emulation" an? Egal ob das jetzt eine Quantum Atlas Festplatte ist, oder ein Ardiuno, da ist ein Microprozessor und der hat einen IO-Port mit Pins, wo das angeschlossen wird. Und da läuft ein Stück Software, was das SCSI-Protokoll umsetzt.
Ich teste jetzt den BlueSCSI nacheinander und soweit es die Freizeit erlaubt an meinen SCSI-fähigen Rechnern durch und poste hier die Ergebnisse; Infos gehen dann auch an die Entwickler.
PC mit Tekram DC-395 Adapter unter Linux Kernel 5.0 (Ubuntu 18.04)
Gibt es beim BlueSCSI eigentlich eine bekannte Beschränkung der Größe einer Festplatte? Ich habe das Image einer 9GB-Festplatte, welches am Mac mit Mac OS 7.5.3 über RaSCSI anstandslos funktioniert. Wenn ich das gleiche Image auf den BlueSCSI (mit ExFAT) kopiere, startet der Rechner zwar (von der ersten Partition), aber es sind dann nur die ersten beiden Partitionen mit je 2GB zugreifbar, die dritte und vierte werden jedoch offenbar nicht richtig eingebunden und beim Starten bietet mir das System an, die unbekannten Partitionen zu formatieren. Für mich klingt das so, als würden aus den beiden hinteren Partitionen nur Nullen gelesen, aber ganz sicher bin ich mir nicht.
Hat jemand von Euch erfolgreich mit BlueSCSI und Images von "großen" Platten gearbeitet? Gibt es etwas zu beachten?
Vielen Dank und schöne Pfingsten!
Hans
Ich benutze am Mac bisher nur 2GB große "Files" die ich mit DiskJockey erstelle.
Im Prinzip sind das ja eigenständige Festplatten von ID X..Y.
Ich jumper meine Maschinen so, dass ID 5 + 6 dann entweder das SCSI-CDROM oder halt das SCSI-ZIP-Drive sind. Dann kann ich von ID0 bis 4 vergeben, was dann 5x2GB sind. Wie gesagt mehr als 2GB habe ich bisher nicht verwendet.
Ich kann aber vom ersten Test des PM6100 berichten, der zwar 7.5.3 anstandslos installiert hat, bei MKLINUX hagelt es aber Schreibfehler auf der neuen SD-Karte, so dass die Installation abbricht. Ich installiere jetzt am anderen 6100er mit einer anderen SCSI-SD-Lösung mit den gleichen Medien um zu prüfen, ob es meine Installationsdatenträger oder halt der BlueSCSI ist. Am 68K Mac lief der BlueSCSI bisher völlig problemlos.
Ich kann aber vom ersten Test des PM6100 berichten, der zwar 7.5.3 anstandslos installiert hat, bei MKLINUX hagelt es aber Schreibfehler auf der neuen SD-Karte, so dass die Installation abbricht. Ich installiere jetzt am anderen 6100er mit einer anderen SCSI-SD-Lösung mit den gleichen Medien um zu prüfen, ob es meine Installationsdatenträger oder halt der BlueSCSI ist. Am 68K Mac lief der BlueSCSI bisher völlig problemlos.
Nur kurz Erfahrung teilen:
Ich habe im Frühling diesen Jahres einen PM6100 mit BlueSCSI aufgesetzt. CD-ROM ist tatsächlich vorhanden. BlueSCSI simuliert 2 SCSI IDs, 2 und 6, jeweils mit ner 2GB-Platte, jeweils mit mehreren Partitionen. Auf einer Platte ist jeweils ne Partition für 7.1.2, 7.6.1, 8.6 und 9.1 drauf. Auf der anderen Platte sind Partitionen für MkLinux drauf.
Tatsächlich hatte ich auch mit der Installation von MkLinux Heck-Meck, so dass ich schließlich eine ältere Variante (DR3) genommen habe. Damit lief der Installer dann durch. Ob das an BlueSCSI lag, oder dem MkLinux-Image oder sonstwas, weiß ich nicht.
Platte initialisiert habe ich mit HardDiskToolkit. Zumindest findet sich der FWB-Treiber auf beiden Platten...
Viel Glück!
Dolle Nummer ... dachte ich Schlaumeier mir, boah, auf die Dauer wird es etwas teuer, alle ollen SCSI Platten durch BlueSCSI zu ersetzen - warum bestellst Du Dir nicht mal den BlueSCSI Bausatz für extern DB25, der dann immer einfach an den aus dem Regal gefischten Mac angeschlossen wird. Added value: Mehrere SD Karten einfacher zu managen ...
Gesagt, getan .. gestern flugs zusammengelötet.
Und was habe ich nicht bedacht? Terminierung, Baby - scheint, als bräuchte es (logischerweise) am internen SCSI-Flachband einen entsprechenden Terminator. Ohne sit das Verhalten "nicht-terminiertungs-typisch", halber Boot, Bus Error ... ach nee ...
Und dummerweise habe ich sowas nicht rumfliegen. Hat jemand eventuell so Teile über?
Es ist mal wieder eine neue Firmware da. Neben einer besseren Unterstützung für Atari-Systeme bringt diese die Unterstützung von CD-Images mit.
Ich hatte ein externes blueSCSI gekauft was ich hinten am GVP im A2000 betreiben und damit die interne Platte clonen wollte, bevor ich der den Saft abdrehe. Egal wie ich das versucht habe, mit BlueSCSI am externen SCSI Anschluss bootete der A2000 nicht mehr, daher liegt das aktuell auf Eis.
In Sachen Amiga sieht es nicht gut aus, ja...
Hierfür dürfte RaSCSI die bessere Wahl sein.
In Sachen Amiga sieht es nicht gut aus, ja...
Das ist beim Amiga auch nicht so einfach, weil es so viele SCSI-Controller von so vielen verschiedenen Herstellern gab, da verhält sich jeder anders.
wie schnell sind eigentlich die beiden Varianten, verglichen mit einer "schnellen" magnetplatte?
Auch die Controller im Amiga oder Atari TT/Falcon sind nicht (viel) schneller, das passt schon. Der RaSCSI dürfte schneller sein.
Ich will mal meine Leidensgeschichte zum BlueSCSI hier einstellen.
Dazu trage ich meine ersten Beiträge aus dem Thread "Mein neuestes
Etwas" hier ein;
Der BlueSCSI mit System 6.07 läuft, auch das interne und externe
Diskettenlaufwerk macht keine Probleme und das Iomega ZIP100 wird
auch erkannt.
Dann ging die Geschichte weiter:
Da habe ich mich so über den funktionierenden Macintosh SE/30 gefreut.
Der schien mit derBlueSCSI zufrieden und hat vor sich hin gewerkelt.
Aber dann habe ich verschiedene Programme ausgeführt und irgendwie kamen
da reproduzierbare Fehler. Auch beim Starten des Mac war noch nicht alles
perfekt, es kamen immer wieder Fehlermeldungen.
Ob das am Macintosh SE/30liegt? Aber auf dem Macintosh LC II genau das Gleiche.
Auch mit den Systemen 6.0.3 / 6.0.7 / 6.0.8e keine Änderung. Kann der Fehler eventuell
an der SD-Karte liegen? Ich habe zwei gleiche SanDisk Ultra microSDHC UHS-1 32GB
die beide genau gleich reagieren. Immer wieder die verschiedensten Fehlermeldungen
beim Start oder wenn ich eine Programm aufrufe. Aber das komische ist, dass der
Start manchmal gelingt. Dann passiert es auch, dass beim Start die microSDHC nicht erkannt
wird und ich diese Resetten muss.
Hier eine Auswahl der Fehlermeldungen:
zitruskeks Du hast mir dann den Tipp gegeben:
Ich hab mit meinem Bluescsi auch mehrere Tage gekämpft. Sah initial gut aus, dann kamen genau die Fehler. Zum Glück auch ein reproduzierbarer, bei der Install von 7.5.1, immer an der gleichen Stelle.
Mit PiScsi kein Problem. Ich war dran, es darauf zu schieben, dass keine Level Conversion/Bustreiber eingesetzt sind und ein 3.3V Chip direkt an den 5V IO hängt, die also auch nur bis 3.3V treibt.
Wenn man danach sucht liest man von so vielen Leuten die immer diese Probleme haben.
Dann las ich in einem nicht mehr auffindbaren Thread dass einer es lösen konnte, indem er eine dickere (physikalisch!) SD genutzt hat.
Ich hatte auch eine SanDisk, weil ich fast alle SD von Sandisk habe und da nie ein Problem mit auftrat. Ja, die ist nicht gerade dick. Alle meine Geräte durchforstet und eine China Noname SD gefunden -> locker anderthalbmal so dick. Einen allerletzten Versuch gestartet und - läuft. Auch der reproduzierbare Fehler ist weg. Und seitdem alles okay.
Der SD Slot scheint mit normal dicken SD Kontaktprobleme zu haben. Probier das mal aus. Evtl auch einfach einen Shim (klebeband?) hinten auf die SD.
Diesen Tipp habe ich mir gemerkt und dann nach einer Woche angewandt.
Wie schon geschrieben, habe ich dann den SD-Slot mal genauer angeschaut.
Da war vielleicht ein kleiner Spalt von 0.2 mm und ich versuchte mal einen
Kleber anzubringen. Aber auch mit diesem trat keine Änderung ein.
Also habe ich den Verkäufer kontaktiert und ihn nach Rat gefragt. Innerhalb
von Stunden hat er mir geantwortet:
Ich habe auch herausgefunden, dass einige "Bluepills", die sich auf BlueSCSI befinden, nicht stabil sind. Nach der "Component shortage" ist es unmöglich geworden, die originalen STM32-Chips zu bekommen.
Es stellte sich heraus, dass die Stabilität mit der ersten Charge von Bluepills nicht optimal war, aber dieses Wochenende konnte ich bestätigen, dass die neuen Bluepills, die ich erhalten habe, perfekt sind und dieses Problem nicht haben.
Es ist also kein Problem, ich werde Ihnen eine der Karten als Ersatz schicken. Ich entschuldige mich für die Unannehmlichkeiten.
Heute habe ich den neuen BlueSCSI erhalten und dieser funktioniert anstandslos.
Der Einzige Unterschied den ich sehen kann, die nicht funktionierenden BlueSCSI
haben einen STM32 aufgelötet, der neue funktionierende einen STM32F
Ohh da werde ich mal schauen was auf meinem klebt!
Bei mir ist es ein 32F, also von da keine Probleme. Dennoch war die SD ein Faktor.
BlueSCSI läuft bei mir im LC und im 6100/66. Beim 6100/66 gab's mit mklinux ein paar Probleme aber dann ging es.
Leider ist BluSCSI (auch bei exFAT) nur etwa 50% der Performance einer echten SCSI-HDD, aber die Geräuschkulisse ist halt angenehm.
Was für Versionen sind das, die Du da installiert hast? MacWrite, M$Office etc. Danke.
Ich brauche auch noch was für meinen LC mit 608
der hat aktuell nur Games drauf
Da habe ich nur draufgekippt, was damals etwa Stand der Dinge war.
Natürlich alle Programme auf Deutsch.
MacPaint 1.4
MacWrite 1.0
MacDraw 1.9.5
MacProject 1.2
Canvas 3.5.3b
MacWrite Pro 1.0
Claris Works 2.1
FileMaker Pro 2.1
MS Works 3.0a
MS Word 4.0
MS Excel 3.0a
HyperCard 1.1
Und dann noch einege Games, diese ungetestet:
Endlich bin ich mit den BlueSCSI zufrieden. Der Verkäufer war sehr kulant und
hat mir zwei funktionierende BlueSCSI geschickt. Da habe ich ihn gefragt, ob er
bei den beiden BlueSCSI die nicht funktionieren, die BluePill auswechseln kann.
Sein Angebot kam sehr schnell, für jeweils 10.- CHF könne er das machen.
Ich habe ihm dann die beiden BlueSCSI geschickt und 30.- CHF beigelegt.
Und jetzt habe ich 4 BlueSCSI die funktionieren. Jeweils zwei haben einen
SCSI-Anschluss nach oben und nach hinten.
Auf allen sind jetzt diese Systeme drauf:
System 6.0.7 sd
System 6.0.8 e
System 7.0.1 e
System 7.1 sd
System 7.5.3 e
OS 8.1 e
Ich teste gerade meine SCSI Platten durch. Ich nehme de PCI 2940UW und nutze über das Bios die "verify" option,
low-level Formatierung mache ich aus Zeitgründen nicht.
Alles was auch nur einen Fehler in Verify hat fliegt raus.
Da bei bei dem Testen die Geräuschkulisse der Platten meistens deutlich missfällt überlege ich ernsthaft einen BlueSCSI an die Controller zu hängen.
low-level Formatierung mache ich aus Zeitgründen nicht.
Das sollte man bei SCSI-Platten auch nicht wirklich tun. Nullen in alle Sektoren reinschreiben reicht.
Ohne Schreibtest? Unsere bekommen LLF und dann verify. Wenn Verify klingt wie "Random seek" gibt es zuviele "Relocated" Sektoren.
Wenn die im Verify nur 1-2 defekte Sektoren haben (die sich neu zuweisen lassen) wären die aber zu schade zum Wegwerfen
low-level Formatierung mache ich aus Zeitgründen nicht.
Das sollte man bei SCSI-Platten auch nicht wirklich tun. Nullen in alle Sektoren reinschreiben reicht.
Da ich mich erinnerne, dass wir für SCSI-Platten gerne (in Ausnahmefällen) die low-level Formatierung zur "Reparatur", aber auch vor dem ersten Einsatz verwendeten, wollte ich fragen: Was spricht denn gegen die low-level Formatierung, wenn die Platte es unterstützt?
PS: In den letzten Tage habe ich mit BlueSCSI v2 meine NeXT Festplatten direkt an den Workstations gebackupt. Das hat sehr gut funktioniert!
Die meisten SCSI-Festplatten schreiben nur Nullen in die Sektoren und schauen dann nochmal nach ob da wirklich Nullen drin stehen, wenn man ihnen einen Format-Befehl schickt. Richtig neue Sektoren anlegen tun nur die wenigsten.
Ich gucke mir bei SCSI Platten immer nur die Grown Defects List mit EZ-SCSI an.
So lange diese nicht übermässig voll ist und die Platte auch sonst unauffällig ist, gilt die als o.k.
Ich hab allerdings auch noch eine Bananenkist voller Platten mit Zipperlein:
- Failure predicted Meldungen vom Raid Controller
- einzelne Bereiche nicht beschreibbar (wenn man die bei der Partitionierung ausblendet funktionieren die noch)
- extreme Geräuschentwicklung
Was macht man mit solchen Platten sinnvolles?
Vielleicht als ungeprüfte Bastlerware in die Bucht kippen? (Nein, natürlich nicht, die Platten sind ja geprüft)
Blue SCSI ist schon eine interessante Alternative, aber bei dreistelligen Rechnerzahlen und einer ebenso hohen Anzahl von spare SCSI Platten, finanziell im Moment unattraktiv.
Wie sind denn die Erfahrungen mit BlueSCSI und Unix Workstations wie HP/9000, RS/6000 und Sun?
Gibt es da bereits belastbare Testergebnisse?
Vielleicht als ungeprüfte Bastlerware in die Bucht kippen?
Ähm... nein? 
Du kennst die Defekte der Platten ja- wenn du die dann ungeprüft verkaufen willst, ist es zumindest "nicht nett".
