EmuTOS 0.9.9 released

[mfro]

Ich hab' gerade mal die XFERRATE-Dokumentation studiert.

Xferrate misst den Durchsatz von 192 kB grossen Rwabs()-Lesezugriffen. Wenn HDDRIVER die Möglichkeiten von IDE "multiple sectors" (256 Sektoren) ausreizt, sind das zwei Lesezugriffe.

EmuTOS braucht dafür im besten Fall 12.

Der praktische Nutzen ist aber - bei echten Dateizugriffen - wahrscheinlich eher gering. Die meisten realen Plattenzugriffe dürften deutlich darunterliegen (GEMDOS agiert auf Clustern und muss zwischendurch immer die FAT anschauen).

[czietz]

EmuTOS hat (mindestens) eine Indirektion mehr im Code, weil es das "verschränkte" IDE-Kabel unterstützt.

Das verschränkte/"twisted" Kabel an sich führt zu keiner zusätzlichen if-Bedingung in der Leseroutine. Also eben nicht...

if (is_twisted) {
 read_twisted();
} else {
 read_normal();
}

Das war ja gerade eine Vorbedingung für meine Patch: die Laufzeit der Funktionen für normale IDE-Interfaces sollte sich nicht verlängern.

Das allein erklärt den Faktor >2 aber sicher nicht.

Wie Du tippe ich derzeit auch auf die "multiple sectors"-Leseaufrufe. Leider habe keine Zeit, mal bei mir zu messen.

[Lukas Frank]

Mit HowFast bei minimal 1KB und maximal 100kB Blöcken zeigt das Programm 400kB/s an. Bei maximal kleineren Böcken noch schlechtere Werte. Das Programm von ppera landet auch wie HowFast bei knapp 400kB/s ...

Gefühlt ist  zum Beispiel das speichern der Desktop.inf oder das kopieren von Daten auch langsam. Da wird immer sowas wie eine Gedenk Sekunde eingelegt, meine ich ...

[mfro]

Das verschränkte/"twisted" Kabel an sich führt zu keiner zusätzlichen if-Bedingung in der Leseroutine.

... vielleicht blick' ich ja im Code nicht ganz durch, aber das hier:

Code: [Auswählen]


 796        if (status1 & IDE_STATUS_DRQ) {
 797             if (info->twisted_cable) {
 798                 ide_get_data((volatile struct IDE *)(((ULONG)interface)+1),buffer,xferlen,need_byteswap)     ;
 799             } else {
 800                 ide_get_data(interface,buffer,xferlen,need_byteswap);
 801             }
 802         } else {
 803             rc = EREADF;
 804         }

sieht mir schon ein wenig danach aus? Ja, nicht in der Leseroutine, aber einmal pro DRQ Block.

[1ST1]

Da ist sicher in ide_get_data noch eine Unterscheidung anhand des Übergabeparameters need_byteswap notwendig, und der Byteswap braucht ja auch noch drei Befehle pro Datenwort.

Und wie oben schon angedeutet, macht der Byteswap für ein rein (Emu)TOS/MiNT/Debian68k benutztes Medium (mit (annähernd) AHDI-kompatiblen Partitionsschema) eh keinen Sinn.

[czietz]

Markus, Du hast Recht; ich hatte eine alte Version meines Patchs in Erinnerung, bei der das nicht so war. Aber ein zusätzliches "if" alle x Sektoren macht vermutlich nicht mal einen messbaren Unterschied in der Datenrate und erklärt sicherlich nicht Franks Beobachtung.

[Thorsten Otto]

!!Wichtig!!

Es gab einen Bug im EmuTOS Desktop. Beim löschen von Desktop Icons, konnten unbeabsichtigt auch andere Dateien gelöscht werden, glücklicherweise nach einem Bestätigungs-Dialog. Da dies zu Daten-Verlust führen könnte, wurde ein Hotfix 0.9.9.1 released.

Bitte die Version 0.9.9 nicht mehr verwenden, und stattdessen dieses Update benutzen: https://sourceforge.net/projects/emutos/files/emutos/0.9.9.1/

[czietz]

Bei mir ist die Gesschwindigkeit beim Zugriff auf eine IDE CF Karte mit EmuTOS 0.99 nur 660kB/s. Unter TOS 2.06 ist es 1440kB/s auf dem gleichen Rechner mit gleicher CF Karte. Die 256MB CF ist eingerichtet mit HDDriver als 256MB BGM Partition.

Ich konnte Dein Problem nun reproduzieren. Es ist jetzt in Diskussion auf der EmuTOS-Entwickler-Mailingliste. Ich denke, wir finden eine Lösung, mit der man zumindest sehr nahe an die Leserate von HDDRIVER herankommen sollte. Bitte gib uns etwas Zeit zum Analysieren, Entwickeln und Testen.

[ari.tao]

Ist der Kabel-Twist jetzt der Normalfall?

[czietz]

Was meinst Du mit "Normalfall"? EmuTOS detektiert die Art des Kabels automatisch; insofern gibt's kein normal und nicht-normal. Frank braucht allerdings kein getwistetes Kabel für schnelle Zugriffe, weil er das Medium ja in TOS-Byteorder angelegt hat.

[ari.tao]

Mit Normalfall meinte ich den ohne Soft-ByteSwap, also den schnellsten.
Wie wird das gemacht, die Art des Kabels zu erkennen?

[Lukas Frank]

Ich habe ein herkömmliches HD Modul und AJAX Floppycontroller im Mega ST und mit EmuTOS setzt das HD Cookie Programm die Möglichkeit im Formatieren Dialog nicht auch auf HD 1,44MB. EmuTOS setzt den Cookie default auf 720kB DD und er läßt sich auch nicht durch das HD Cookie Programm überschreiben/ändern.

Unter TOS 2.06 schaltet sich der HD Mode im Formatierdialog frei wenn man HD Cookie Programm startet ...

->   http://www.wrsonline.de/software/HDCOOKIE.LZH

[goetz @ 3rz]

Mit Normalfall meinte ich den ohne Soft-ByteSwap, also den schnellsten.
Wie wird das gemacht, die Art des Kabels zu erkennen?

Man fragt nach bekannten festen Datenmustern ("magic bytes") und sieht an der Art der Antwort, wie die Daten sortiert sind.

[czietz]

Mit Normalfall meinte ich den ohne Soft-ByteSwap, also den schnellsten.
Wie wird das gemacht, die Art des Kabels zu erkennen?

Wenn das Kabel "getwisted" ist, sind auch die IDE-Register vertauscht. EmuTOS guckt einfach, wo es die Register vorfindet => Kabel detektiert.

[ari.tao]

Mit Normalfall meinte ich den ohne Soft-ByteSwap, also den schnellsten.
Wie wird das gemacht, die Art des Kabels zu erkennen?

Man fragt nach bekannten festen Datenmustern ("magic bytes") und sieht an der Art der Antwort, wie die Daten sortiert sind.

Das kann imho nicht funzen - wenn die magic bytes schon mit Twist geschrieben wurden. Du kannst auf diese Weise nur feststellen, ob ein ByteSwap vorliegt, aber nicht, ob die Ursache ein Twist im Kabel oder einfach die Endianess des Mediums ist.

Wenn das Kabel "getwisted" ist, sind auch die IDE-Register vertauscht. EmuTOS guckt einfach, wo es die Register vorfindet => Kabel detektiert.

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?

[goetz @ 3rz]

Mit Normalfall meinte ich den ohne Soft-ByteSwap, also den schnellsten.
Wie wird das gemacht, die Art des Kabels zu erkennen?

Man fragt nach bekannten festen Datenmustern ("magic bytes") und sieht an der Art der Antwort, wie die Daten sortiert sind.

Das kann imho nicht funzen - wenn die magic bytes schon mit Twist geschrieben wurden. Du kannst auf diese Weise nur feststellen, ob ein ByteSwap vorliegt, aber nicht, ob die Ursache ein Twist im Kabel oder einfach die Endianess des Mediums ist.

Ist doch egal, ob das Medium "falsch" (PC-endian) beschrieben wurde (und kein gedrehtes Kabel eingebaut ist), oder ob das Medium "richtig" beschrieben wurde (und ein gedrehtes Kabel eingebaut ist), beide Mal kommen die Daten gedreht am Atari an. Und das kann man erkennen.

Und beim Fall "falsch" beschrieben (PC-endian) und gedrehtes Kabel, muss der Treiber/EmuTOS ja nichts anfassen, da stimmt’s ja dann.

[mfro]

...Und beim Fall "falsch" beschrieben (PC-endian) und gedrehtes Kabel, muss der Treiber/EmuTOS ja nichts anfassen, da stimmt’s ja dann.

Das täuscht. Das "verdrehte" Kabel verdreht ja nicht nur das Datenregister (das ist gewünscht), sondern auch das Cmd- und Statusregister (das ist das dazu notwendige Übel). Insgesamt gibt's also vier verschiedene Möglichkeiten, die der Treiber berücksichtigen muss: Kabel (nicht) verdreht x Daten (nicht) verdreht.

[Johannes]

Bitte hier On-Topic bleiben - es geht um Emutos 0.9.9(.1) und nicht hauptsächlich um die Funktionsweise von IDE, etc.

Die kann man jetzt hier weiterdiskutieren:

http://forum.atari-home.de/index.php?topic=14004.0

Gruß
Johannes

[ari.tao]

Bitte hier On-Topic bleiben - es geht um Emutos 0.9.9(.1) und nicht hauptsächlich um die Funktionsweise von IDE, etc.
Die kann man jetzt hier weiterdiskutieren:
http://forum.atari-home.de/index.php?topic=14004.0
Gruß
Johannes

Hallo @Johannes , hab´ ja nichts dagegen, das Du hier moderierend eingreifst. Aber könntest Du in manchen Fällen doch bitte nicht nur einen Link setzen, wo´s weitergeht, sondern auch einen, wo´s herkommt? Dem neuen Thread fehlt jetzt schlicht die ´Einleitung´. Wie soll sich ein Leser da später zurechtfinden?
Und wenn wir schon dabei sind: Da gibt´s noch einen weiteren Thread, der mal aufgeteilt gehört, sogar unter den festgepinnten: In
   http://forum.atari-home.de/index.php?topic=12352.0
wird seitenlang OffTopic über die Herstellung von Video-Adaptern diskutiert. Der Thread hat aber das Thema "TFT ST-Low Kompatibilitätsliste". Andererseits müßte er mit diesem sehr ähnlichen verlinkt werden:
   http://forum.atari-home.de/index.php?topic=12019.0

Ach, diesen Beitrag solltest Du am Besten nach ´Verbesserung des Forums´ schieben...
Oder einfach nach Kenntnisnahme löschen.
Gruß
ari.tao

[Johannes]

Hallo Ari.Tao, danke für den Hinweis, das ist eine gute Idee ;-)