FYI: Was ein "twisted" IDE-Kabel wirklich bringt...

[czietz]

Hallo,

es gibt ja von Pera Putnik (ppera) ein IDE-Interface mit verdrehtem Kabel, d.h. obere und untere Datenbushälfte getauscht. (Siehe: http://atari.8bitchip.info/idepc.htm) Das erlaubt einen schnelleren Zugriff auf DOS-formatierte Medien.

EmuTOS unterstützt diese Art von IDE-Interface ohne zusätzliche Treiber (aber nach Neukompilierung). Nun kam gestern auf der EmuTOS-Mailingliste die Frage auf, ob dieses "getwistete" Kabel den Aufwand überhaupt Wert ist bzw. welchen Geschwindigkeitsvorteil es bringt.

Ich habe nun meinen STfm mit IDE-SD-Karten-Leser testweise auf ein normales IDE-Interface (nicht getwistet, d.h. Belegung wie Falcon) umgebaut, um vergleichen zu können. Mit dem Benchmark HOW_FAST der ST-Computer habe ich dann jeweils Lese- und Schreibgeschwindigkeit gemessen. HOW_FAST benutzt GEMDOS-Funktionen, um Dateien verschiedener Größe zu schreiben und zu lesen und spiegelt damit die Performance wieder, die auch andere Programme bei Verwendung des jeweiligen Laufwerks sehen würden.

Ich denke, die Resultate sprechen für sich: Mit aktuellem EmuTOS ist die Lesegeschwindigkeit bei getwistetem IDE-Kabel ca. 3 Mal so hoch!

[Gast160608]

Das sieht doch nach einem Bytes-Swap-Effekt aus
 - oder kannst Du den sicher ausschließen?

[tuxie]

Das ist normales byteswap, Bei der einen Methode liest er ein Word und bei der anderen Methode 2 Bytes einzeln, was zur Folge hat das bei der einen einmal lesen und einmal schreiben und bei der anderen sind es zwei mal lesen und zweimal schreiben. Nimm mal zum messen xferrate von anodyne das ist viel genauer.

[Gast120501]

Wäre es nicht schneller, auch bei Byteswap ein 16 Bit Wort zu lesen und dann im RAM den Byteswap durchzuführen? Würde immerhin einen IDE-Handshake-Vorgang einsparen.

[czietz]

Das sieht doch nach einem Bytes-Swap-Effekt aus
 - oder kannst Du den sicher ausschließen?

Hä? Natürlich ist das der Byte-Swap, den Du dort siehst. Das ist doch gerade Sinn dieses "twisted" Kabels, dass man den Byte-Swap dann nicht mehr in Software machen muss.

Das ist normales byteswap, Bei der einen Methode liest er ein Word und bei der anderen Methode 2 Bytes einzeln, was zur Folge hat das bei der einen einmal lesen und einmal schreiben und bei der anderen sind es zwei mal lesen und zweimal schreiben.

...und...

Wäre es nicht schneller, auch bei Byteswap ein 16 Bit Wort zu lesen und dann im RAM den Byteswap durchzuführen? Würde immerhin einen IDE-Handshake-Vorgang einsparen.

Es werden in beiden Fällen immer 32 Bit (= 4 Byte) am Stück vom IDE-Interface gelesen -- und der Byte-Swap dann im CPU-Register durchgeführt. Schneller lässt sich auf der CPU nicht mehr "swappen". Die Anzahl an Lese- bzw. Schreibvorgängen auf dem IDE-Interface ist identisch. Alleine das "Byte-Swappen" kostet massiv Performance.

[Gast160608]

_^^_ Das ist aber sehr irreführend, wenn Du den Twist dann als 2-3 mal schneller verkaufst. Ein Plättle, das am normalen IDE-Port mit BigEndian eingerichtet ist, das ist genauso schnell wie eines, das mit LittleEndian am Twist hängt.
Wenn mit "DOS&TOS" eingerichtet, dann gibt´s lediglich in der WinDose den Swap-Effekt; die ist aber so schnell, daß Du davon fast gar nichts merkst (und macht den Swap automatisch).

[mfro]

... Wenn mit "DOS&TOS" eingerichtet, dann gibt´s lediglich in der WinDose den Swap-Effekt; die ist aber so schnell, daß Du davon fast gar nichts merkst (und macht den Swap automatisch).

Wie meinst Du das?

Ich wüsste nicht, daß Windows mit Big-Endian partitionierten Medien umgehen könnte. M.E. *muss* das Byte-Swapping *immer* auf der Atari-Seite stattfinden (entweder per getrixtem Kabel und passendem Treiber oder eben per Software).

[czietz]

Wenn mit "DOS&TOS" eingerichtet, dann gibt´s lediglich in der WinDose den Swap-Effekt; die ist aber so schnell, daß Du davon fast gar nichts merkst (und macht den Swap automatisch).

Nein! Windows und DOS können nicht mit aus ihrer Sicht falsch "geswappten" Medien umgehen. Da macht nix "den Swap automatisch".

Du musst immer auf dem Atari swappen, wenn Du Kompatibilität zu DOS/Windows haben willst. Entweder in Software (kostet Performence) oder halt in Hardware (was das Twisted-Kabel macht). Insofern ist es vollkommen korrekt, das "getwistete" Kabel als 2x - 3x schneller zu bezeichnen, weil es das schlichtweg ist!

[tuxie]

Wir haben im TT Ide Interface einen gemixten modus eingebaut wo die Daten selbst die gelesen und geschrieben werden geswappt sind und die commands und commands daten ungewappt wie es im Suska Projekt schon angedacht ist.

[Gast160608]

Ihr habt Recht - und ich auch.
So ganz vollautomatisch geht´s tatsächlich nicht, man braucht den Hitachi-Treiber dafür auf der WinDose. (Habe ich aber nicht selbst ausprobiert).

[czietz]

Ich denke, Du bringst da was durcheinander: Dieser "Hitachi-Treiber" sorgt dafür, dass auf einem Wechselmedium (z.B. einer SD-Karte) von Windows mehrere Partitionen erkannt werden, sodass Du überhaupt Zugriff auf alle Laufwerke darauf bekommst. Beim Byte-Swapping hilft er nicht.

Es bleibt also dabei, bei DOS/Windows-Kompatibilität hast Du aus Sicht des Atari "byte-geswappte" Medien und musst entweder in Hardware (tuxies Lösung ist natürlich die Luxus-Variante) oder in Software die Bytes tauschen.

Wenn Du Markus und mir nicht glaubst, dann vielleicht Uwe Seimet, dem Autor von HDDRIVER. In seiner FAQ schreibt er: "TOS/Windows-kompatible Medien, die am IDE-Bus eines Falcon oder ST verwendet werden, müssen bytegeswappt sein"

[Lukas Frank]

"TOS/Windows-kompatible Medien, die am IDE-Bus eines Falcon oder ST verwendet werden, müssen bytegeswappt sein"

Genau und die Geschwindigkeit sinkt dann auf Diskettenlaufwerks Niveau ab ...

[Gast160608]

Ups, da habe ich anscheinend wirklich etwas durcheinandergebracht, ´tschuldigung.
Gibt´s denn wirklich keinen Treiber, der unter Windows oder Linux oder OS-X mit BigEndian umgehen kann? Da gab´s doch früher Harddisks, die BigEndian waren?
PS1: Euch dreien glaub ich ja, aber US hat doch früher mal auch gemeint, DOS&TOS gehe nicht? & dann hat er´s gemacht.
PS2: Auch byteswaped CFs sind auf dem Falcon noch deutlich schneller als Disketten! /size]

[Gast120501]

Genau und die Geschwindigkeit sinkt dann auf Diskettenlaufwerks Niveau ab ...

Naja, das halte ich jetzt aber auch für etwas zu übertrieben.

[czietz]

Ja, man sieht ja an meiner Grafik, dass mit Byte-Swapping in Software (also dem normalen Kabel) mit EmuTOS noch eine Rate von ca. 200 kiByte/s vom IDE-LW zustande kommt. Eine DD-Floppy hätte mit dieser Rate in ca. 4 Sekunden gelesen oder beschrieben. Daran, dass das in Wirklichkeit deutlich länger dauert, merkt man, dass Disketten noch mal langsamer sind.

Und auf dem Falcon mit seiner schnelleren CPU fällt der zusätzliche Swap-Aufwand weniger ins Gewicht als auf meinem STfm. Der 68000 ist einfach langsam beim Byte-Swap, mangels Barrel Shifter.

[Lukas Frank]

Genau und die Geschwindigkeit sinkt dann auf Diskettenlaufwerks Niveau ab ...

Naja, das halte ich jetzt aber auch für etwas zu übertrieben.

Nein ist es nicht. Wenn ich von einer mit HDDriver TOS/DOS-Windows eingerichteten CF oder SD Karte ein 700kB Programm starte dauert das gefühlt schon so in etwa wie von Floppy auf einem 68000 System ...

[Gast160608]

Wie machen denn das eigtl. Hatari & Aranym, können die auch kein BigEndian?

[Gast160608]

Hier die TransferRate für meinen Falcon, Video abgeschaltet, MAGX,
  gemessen mit xFerRate_1.1, HDDRIVER_8.45, ~1,9GB-Partition, in kB/sec:

     IDE normal                ~2400   CF
     IDE byteswapd          ~ 870   SD
     Yamaha (via SCSI)   ~1400   SD
       "   byteswapd           ~ 720   SD

und für meinen TT (gleiches SetUp, außer GK):

     Yamaha (via SCSI)     ~1800  CF
        "   byteswapd            ~ 820   SD

Wenn ich den CPU-Takt zurückschalte, sinkt die TR nur geringfügig, aber am deutlichsten bei ´byteswapd´ (auf ~770, am F30).

Edit.: Ergänzungen

[mfro]

Wie oben schon angedeutet, gebricht es dem 68000 am Barrel-Shifter.

Das bedeutet daß die Ausführungszeit von Shift- und Rotate-Befehlen von der Shiftweite abhängig sind. Die zwei Rotate-Befehle, die der Byte-Swap braucht, benötigen (weil sie um 8 Bit shiften müssen) auf dem 68000 je 28 Takte (best case).
Der 68030 im Falcon hat den Barrel-Shifter und kann den Rotate-Befehl deswegen in (wieder best case) 5 Takten ausführen, ist also auf dem Papier (doppelte Taktfrequenz berücksichtigt) etwa 10-12 Mal schneller.

Im TT geht's nochmal ungefähr doppelt so schnell.

Beim ColdFire in der FireBee gibt's keinen Rotate-Befehl mehr, der muß stattdessen zwei Shift-Befehle nehmen, die dafür aber in einem einzigen Takt ausgeführt werden. Die 32-fache Taktrate berücksichtigt, ist der ByteSwap damit etwa 450 (!) Mal schneller als im ST und spielt keine wesentliche Rolle mehr.

Noch besser wäre der M54455. Der hat zwar auch keinen ROx-, aber als ISA B+ den BYTEREV-Befehl, der ein Langwort in einem Takt "umdrehen" kann.

[Gast160608]

_^^_ eben deshalb meine Erwartung, daß man auf einer schnellen WinDose kaum noch den Unterschied merkt - aber wenn´s dann keinen Treiber für BigEndian gibt, dann bleibt das natürlich Theorie...