Allgemeines zum Thema IDE/Byteswap/MagicBytes

[1ST1]

EDIT JOHANNES: Ursprungs-Thread: http://forum.atari-home.de/index.php?topic=13993.msg223426#msg223426

Danke, darüber muß ich mal meditieren... Leuchtet mir iM. noch nicht ein, denn die IDE-Regs. sind doch _vor_ dem Kabel mit Twist? Oder sind die auf dem Medium?

Vielleicht hilft dir ja die Info weiter, dass IDE (und selbst SATA) eine Art verlängerter ISA-Bus ist.

[mfro]

Danke, darüber muß ich mal meditieren... Leuchtet mir iM. noch nicht ein, denn die IDE-Regs. sind doch _vor_ dem Kabel mit Twist? Oder sind die auf dem Medium?

Die IDE-Register (und nicht nur die, sondern der gesamte Controller) sind (seit Anbeginn der Zeiten) auf der Platte. Auf der Rechnerplatine ist lediglich der Adressdekoder dafür, der die Chip Selects für die Platte liefert. Insofern ist das auch *kein* verlängerter ISA-Bus (der hätte nämlich Adressleitungen).

[1ST1]

Ich habe ja genau deswegen "eine Art verlängerter" geschrieben und nicht nur "verlängerter".

[ari.tao]

Danke für Eure Antworten. Wenn ich das Puzzle jetzt mal zusammensetze, dann ergibt sich folgendes Bild:
  1) Die beiden IDE-Regs. für Cmd & Status sitzen auf dem Medium.
  2) Mit einem Twist (im Kabel oder per Thunder oder auch im Yamaha) ändern sich ihre Adressen.
  3) Greift man auf diese Register zu, gibt´s eine Rückmeldung, also entweder ok oder ko.
  4) Damit weiß man, ob ein Hardware-Twist vorliegt, aber noch nicht, ob ByteSwap nötig ist.
  5) Danach kann man noch eine MagicNumber abfragen & so alle vier möglichen Fälle unterscheiden.
  6) Die Unterscheidung der Fälle kostet nicht viel (Zeit).
  7) Ein nötiger ByteSwap dagegen ziemlich viel.
Damit ist nun so nebenbei auch klar, warum Thunder nicht nur zwei, sondern drei Modes hat - aber warum nicht vier? Und warum klappt das beim Yamaha so wunderschön automatisch, so daß man sich gar nicht darum kümmern muß? Ich hatte ja schon berichtet, daß man am Y. mit HDDRIVER sehr schnell auf PC-Medien zugreift, also ohne ByteSwap (bloß vom IDE noch deutlich übertroffen).
Der Treiber im EmuTOS geht dann wohl genau so vor wie PPERA. Tanzt HDDRIVER inzwischen auch den Twist? (Meine Version 8.45 afaik noch nicht).

[goetz @ 3rz]

Und warum klappt das beim Yamaha so wunderschön automatisch, so daß man sich gar nicht darum kümmern muß?

Wenn du mit "mein Yamaha" den SCSI-IDE-Adapter der Yamaha CRW2200 ff. Laufwerke meinst: jo, das erklärt sich dadurch, dass dein Datenträger für den Atari dann eben _kein_ IDE-Gerät ist, sondern ein SCSI-Gerät. Und das ganze Byteswap-Thema dort nicht existiert.

[1ST1]

Die Hardwaretricks von Thunder werden erst von HDDRIVER 10 unterstützt.

Was für ein Yamaha meinst du? Ein SCSI zu CF/SD/IDE-Adapter? Bitte bedenke, dass SCSI am TT 8 Bit breit ist und daher keinen Byteswap benötigt. Der Yamaha handelt das intern ohne Fallunterscheidung.

Alle Register die für den IDE-Disk-Zugriff benötigt werden, liegen auf der Platte, auch sonst alles, denn das war ja das revolutionäre an IDE, nämlich dass der Controller komplett auf die Platte gewandert ist. Die IDE-Schnittstelle selbst ist wie schon angedeutet, ein abgespeckter ISA-BUS, der nur noch aus den Leitungen besteht, die die Laufwerke brauchen, also Datenbus, zweidrei Adress-Signale und ein bischen Handshake. Das was im PC als "IDE-Controller" bezeichnet wird, ist im einfachsten Fall - wie czietz angedeutet hat - nur ein Adressdecoder und ein paar Puffer für den Datenbus.. Übrigens, wenn neuere IDE-Platten in PCs (Ultra-)DMA-Zugriffe machen, dann wird quasi der Bock zum Gärtner, die Platte steuert dann nämlich den Rechner.

[ari.tao]

... das erklärt sich dadurch, dass dein Datenträger für den Atari dann eben _kein_ IDE-Gerät ist, sondern ein SCSI-Gerät.

Das ist richtig, für den Yamaha_V769970-Adapter, SCSI2IDE.

... Und das ganze Byteswap-Thema dort nicht existiert. ...

Das ist so nicht ganz richtig: Wenn ich ihn mit einem Atari-Medium (ie. BigEndian) füttere, dann wird die Geschwindigkeit ~ halbiert! Also macht HDDRIVER_8.45 den ByteSwap.
Diese Diskussion hatten wir doch schon einmal. Da macht XFERRATE eine klare Ansage.

[1ST1]

BigEndian ist für IDE ja auch eher die Ausnahme. Und ein an einem Atari-IDE-Controller beschriebenes Medium wieder per Yamaha an einem Atari einzulessen ist ja wohl das sinnloseste Szenario was man sich vorstellen kann.

[ari.tao]

... das erklärt sich dadurch, dass dein Datenträger für den Atari dann eben _kein_ IDE-Gerät ist, sondern ein SCSI-Gerät.

Das ist richtig, für den Yamaha_V769970-Adapter, SCSI2IDE.

... Und das ganze Byteswap-Thema dort nicht existiert. ...

Das ist so nicht ganz richtig: Wenn ich ihn mit einem Atari-Medium (ie. BigEndian) füttere, dann wird die Geschwindigkeit ~ halbiert! Also macht HDDRIVER_8.45 den ByteSwap.
Diese Diskussion hatten wir doch schon einmal. Da macht XFERRATE eine klare Ansage.

Ich hatte auch schon mal darauf hingewiesen, daß Endianess eine Aussage darüber ist, wie die Daten auf einem Medium liegen, egal ob das Medium ein RAM oder eine CF oder sonstwas ist, und daß der Übertragungsweg dafür keine Rolle spielt. Daß das Protokoll (also SCSI oder IDE) ebenfalls Einfluß auf die Geschwindigkeit hat, das ist davon unabhängig. Hier mal die Ergebnisse:

Code: [Auswählen]

XFERRATE v1.1 starting
Testing drive K:
  Rwabs() transfer rate: 1100-1240 kb/sec
  XHDI transfer rate: 1250-1230 kb/sec
Testing drive S:
  Rwabs() transfer rate: 1330 kb/sec
  XHDI transfer rate: 1310-1330 kb/sec
XFERRATE exiting with code 0 wobei S mit BigEndian am IDE-Bus des Falcon hängt und K mit LittleEndian über den Yamaha aber an dessen SCSI-Bus. Und nun bei ansonsten unveränderten Bedingungen das gleiche mit vertauschten Medien, also BigEndian am Yamaha und LittleEndian am IDE:

Code: [Auswählen]

XFERRATE v1.1 starting
Testing drive S:
  Rwabs() transfer rate: 490 kb/sec
  XHDI transfer rate: 530 kb/sec
Testing drive K:
  Rwabs() transfer rate: 530 kb/sec
  XHDI transfer rate: 530 kb/sec
XFERRATE exiting with code 0 Wie man an den vier Beispielen sieht, wird die Geschwindigkeit auch halbiert, wenn man ein am PC mit LittleEndian beschriebenes Medium in den BigEndian-IDE-Port des Falcon füttert anstatt in den Yamaha (weil wieder ByteSwap sein muß).
Das machen sicher viele so. Der zuerst beschriebene Fall ist übrigens bei mir nützlich, um Daten zw. TT (mit Y.!) und Falcon auszutauschen.

PS: Aber für beides reicht die Vorstellungskraft eines gewissen Forumsmitglieds ganz offenbar leider nicht.

PS2: Warum breite ich das hier so aus - obwohl doch der Yamaha-Adpt. so selten ist? Weil das Thema sowohl mit dem Thunder als auch mit EmuTOS wieder hochaktuell ist. Darum eben auch meine Frage, ob der Kabel-Twist für EmuTOS jetzt der Normalfall ist (wie es wünschenswert wäre, wg. des dargestellten Szenarios).
Darum hier noch einmal mein Kompliment an die Entwickler des Thunder & des EmuTOS-Treibers! (und damit indirekt auch an PPERA, dem Erfinder des Twists*!)

*Ach was, diesen Tanz hat doch ganz wer anders erfunden?

[mfro]

Ich habe ja genau deswegen "eine Art verlängerter" geschrieben und nicht nur "verlängerter".

Jetzt wirst Du aber (mal wieder) spitzfindig.

Auch wenn's vielleicht in Wikipedia steht: ATA-1 (aka IDE) hat einen fundamentalen Unterschied zum ISA-BUS: ersteres ist asynchron, letzteres synchron. Die Kommunikation über den ISA-Bus funzt nur, wenn alle Karten mit dem gleichen Taktsignal arbeiten, das der Host bereitstellt.

IDE hat keine Taktleitung; die Gültigkeit der Daten auf dem Bus wird durch read/write Strobes angezeigt - komplett asynchron. Das funktioniert völlig anders als ein synchroner Bus (und deswegen kann man ihn auch fast überall - z..B. an alte 8-Bitter - relativ simpel dranhängen).

Wenn Du IDE unbedingt mit "irgendwas verlängertem" vergleichen willst, dann vergleich's mit einer Centronics-Schnittstelle. Die arbeitet genauso.

[1ST1]

Nein, eine Centronics-Schnittstelle hat immer einen IO-Chip mit Daten und Steuerregister davor.

[mfro]

Nein, eine Centronics-Schnittstelle hat immer einen IO-Chip mit Daten und Steuerregister davor.

Aha. Und eine IDE-Schnittstelle hat das nicht?

[1ST1]

Nein, eine Centronics-Schnittstelle hat immer einen IO-Chip mit Daten und Steuerregister davor.

Aha. Und eine IDE-Schnittstelle hat das nicht?

Wir haben weiter oben geklärt, dass diese Register usw. bei IDE auf der Platte liegen...

[mfro]

Nein, eine Centronics-Schnittstelle hat immer einen IO-Chip mit Daten und Steuerregister davor.

Aha. Und eine IDE-Schnittstelle hat das nicht?

Wir haben weiter oben geklärt, dass diese Register usw. bei IDE auf der Platte liegen...

Das ist doch völlig wurscht, wo die liegen.

Bei einer I/O-Karte mit Centronics-Schnittstelle am ISA- (oder sonstwas) Bus liegen sie doch auch jenseits des Bus-Slots.

[1ST1]

Jetzt muss es auf einmal wieder nicht genau formuliert sein? Und das nächste Mal werden wieder sämtliche Wörter auf die Goldwage gelegt.

[ari.tao]

Nein, eine Centronics-Schnittstelle hat immer einen IO-Chip mit Daten und Steuerregister davor.

Aha. Und eine IDE-Schnittstelle hat das nicht?

Wir haben weiter oben geklärt, dass diese Register usw. bei IDE auf der Platte liegen...

Das ist doch völlig wurscht, wo die liegen.
Bei einer I/O-Karte mit Centronics-Schnittstelle am ISA- (oder sonstwas) Bus liegen sie doch auch jenseits des Bus-Slots.

Nee, ist nicht wurscht. Bei IDE liegen die Regs. jenseits der Buchse. Genau diesen Umstand hat ja @czietz ausgenutzte, um die Hardware zu detektieren (ie. den Twist im Kabel).

[mfro]

Nee, ist nicht wurscht. Bei IDE liegen die Regs. jenseits der Buchse. Genau diesen Umstand hat ja @czietz ausgenutzte, um die Hardware zu detektieren (ie. den Twist im Kabel).

Für die Frage, ob IDE ein "verlängerter" ISA Bus sei (und darum ging's), ist es völlig wurscht.

[1ST1]

Nein.

[mfro]

Nein.

Doch.

[1ST1]

Darüber weiter zu diskutieren ist wohl sinnlos, das Ergebnis der Waage ist ungleich, je nach dem ob das Gewicht auf der linken oder rechten Seite liegt.