Mit dem Einverständnis von Uwe Seimet ...
Das schrieb er mir ->
Hierzu aus aktuellem Anlass ein Hinweis: Es hat hat mich nicht viel mehr
als 2 Tage gekostet, einen SCSI-Treiber für Hatari (Linux) zu schreiben,
so dass HDDRUTIL und HDDRIVER nun *nativ* auf Massenspeicher zugreifen
können, die an irgendeiner Schnittstelle eines Linux-PCs hängen. Auch
DISKUS kann so auf Geräte über Schnittstellen zugreifen, die es bei
Ataris eigentlich gar nicht gibt. Und vermutlich kann mit dieser Lösung
ExtenDOS CDs unter Hatari lesen und brennen. Roger Burrows wird das
demnächst ausprobieren.
Neue Versionen von HDDRIVER, HDDRUTIL oder DISKUS waren dafür nicht
erforderlich. Funktioniert alles dank SCSI-Treiber-Unterstützung mit der
vorhandenen Software. Auch CBHD müsste laufen.
Ich habe dieses Experiment u. a. deshalb gemacht, weil ich wissen
wollte, wie viel Aufwand es wirklich ist, einen SCSI-Treiber für
Schnittstellen zu schreiben, für die der Low-Level-Code bereits existiert.
Mein Fazit: In wenigen Tagen sollte es den FireBee-Entwicklern möglich sein,
dasselbe für die FireBee zu implementieren. Eben weil sie ja bereits wissen,
wie man die vorhandenen Schnittstellen anspricht.
Würde ich FireBee-Support (oder Unterstützung für andere Schnittstellen) in
HDDRIVER einbauen hieße das:
1. Es würde sehr viel mehr Zeit brauchen, bis so etwas fertig und
getestet ist.
2. Mit jeder neuen Schnittstelle würde das HDDRIVER-Binary immer
umfangreicher, würde immer mehr Speicher verbrauchen etc.
3. Die Low-Level-Routinen würden doppelt implementiert, und müssten
doppelt gewartet werden. Einmal für die FireBee selbst, und dann nochmal
zusätzlich für HDDRIVER.
Macht halt alles keinen Sinn, und deshalb hat ja auch jedes halbwegs
aktuelle Betriebssystem eine Treiber-Schicht wie den SCSI-Treiber.
Mehr Infos unter
http://hddriver.seimet.de/forum/viewforum.php?f=7.
Danke, aber das hatte ich ja bereits dankend abgelehnt. Die
FireBee-Entwickler sollten untersuchen, warum Software auf Ihrer Hardware
nicht läuft. Eventuell gibt es Probleme bei der 68K-Emulation. Welche
Instruktion in einem solchen Fall zu einem Fehler führt sollten die
Entwickler leicht herausfinden können. Entweder verbessern sie dann Ihre
Emulation, oder aber sie setzen sich mit mir in Verbindung und sagen mir,
welche Opcode problematisch ist. Eventuell kann ich das dann ändern, aber
das hängt ganz davon ab.
1. Probleme bei der 68k-Emulation. Hier müsste dann die Emulation verbessert
werden, oder ich müsste genau wissen, welcher Opcode ein Problem macht. Dann
könnte ich das vielleicht ändern.
2. Probleme beim Zugriff auf nicht vorhandene Hardware-Adressen. Hier müsste
ich wissen, um welche Adresse es sich handelt. Ganz allgemein sollte man bei
der FireBee sicher stellen, dass sie sich beim Zugriff auf nicht vorhandene
Adressen so verhält, wie es auch ein ST tun würde. Beispiel: Beim Zugriff
auf Register des SCSI-DMA-Chips, wie es ihn nur beim TT, nicht aber beim ST
gibt, sollte sich die FireBee so verhalten wie ein ST, also den Zugriff in
der Regel mit einem Busfehler beantworten. Andernfalls würde Software wie
HDDRIVER davon ausgehen, dass diese Hardware vorhanden ist, was dann zu
weiteren Zugriffen mit weiteren Fehlern führt.
3. Man sollte zunächst sicher stellen, dass HDDRUTIL funktioniert. HDDRUTIL
ist in C geschrieben, lediglich der ID-Check benutzt auch
Assembler-Routinen. Bevor HDDRUTIL nicht fehlerfrei läuft macht es wenig
Sinn, sich um HDDRIVER zu kümmern. Und bei vorhandenem XHDI- und
SCSI-Treiber lassen sich ja alle Wartungs-Funktionen, die HDDRUTIL anbietet,
auch ohne HDDRIVER nutzen.
Thema: FireBee und HDDriver 9.02 ... (Gelesen 16873 mal)