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

[ari.tao]

HDDRiver erkennt Automatisch ob es sich um ein Swapped drive handelt. Autoboot geht nur nicht. Selbst getestet am TT, da wir dort per Jumper Swapped nicht Swapped wählen kann

Also, das kann ich kaum verstehen, da bei mir Autoboot am Yamaha problemlos funzt! Allerdings hatte ich zunächst auch Probs, das mit HDDU einzurichten - weiß aber nicht mehr genau, woran das lag. Mit dem geclonten (also bytgeswapten) Bootsektor, so., geht´s!

Als ich im Sommer US gefragt habe, ob es nicht möglich sei, HDDRIVER so zu erweitern, daß Plättle  _zugleich_ am Atari-IDE und am Yamaha booten könnten, da ist der schier ausgerastet. Inzwischen habe ich gesehen, daß PPERA just dieses Kunststück hinkriegt:
   -> Lit.: DrCoolzic (Jean Louis-Guerin) in "Atari_HD_File_Sytem_Reference_Guide" 2014

[czietz]

Als ich im Sommer US gefragt habe, ob es nicht möglich sei, HDDRIVER so zu erweitern, daß Plättle  _zugleich_ am Atari-IDE und am Yamaha booten könnten, da ist der schier ausgerastet. Inzwischen habe ich gesehen, daß PPERA just dieses Kunststück hinkriegt:
   -> Lit.: DrCoolzic (Jean Louis-Guerin) in "Atari_HD_File_Sytem_Reference_Guide" 2014

Mit ungepatchtem TOS? Auf welcher Seite in dem o.g. Dokument liest Du das denn?

[1ST1]

Mit ungepatchtem TOS muss man da in der Tat geradezu zaubern...

[ari.tao]

-^^- also bitte, in welchem _meiner_ Postings habt Ihr denn das gelesen, daß ich _das_ bei DrCoolzic gelesen hätte?    Legasthenie? Brille verlegt? Dope?    Oder bloß ´Fake News´? 
Aber, mal als Frage aufgefaßt, können wir das ja zu klären versuchen.
Könnte mal jmd. auf Deutsch und ganz genau beschreiben, wie ein _normales_ TOS 3.05 oder 4.04 auf den diversen Bussen und Primär-Partitionen einen _ausführbaren_ BootSektor sucht?
Ich versuch´s mal (bitte korrigiert mich, wenn ich falsch liege):
Abgesucht werden (in dieser Reihenfolge):
1) Die ersten drei Primär-Partitionen des IDE0 (so vorhanden)
2) Die ersten je drei Primär-Partitionen von SCSI 0 - 7 (so vorhanden)
3) Die ersten je drei Primär-Partitionen von ACSI 0 - 7 (so vorhanden)
4) Die Diskette in Laufwerk A: (so vorhanden)
5) Der RomPort (falls Modul vorhanden)
Wird kein ausführbarer Bootsektor gefunden, bootet TOS einen Default ohne LW.

Was passiert eigtl., wenn auf IDE0 in der ersten Primär-Partition ein BootSektor liegt, der mit LittleEndian ausführbar ist (& folglich (wg. falscher Prüfsumme) mit BigEndian nicht) und auf der zweiten Primär-Partition einer, der mit BigEndian ausführbar ist? Wäre solch ein Plättle sowohl am norm.IDE als auch am Twist per HDDRIVER  bootfähig?

[1ST1]

1. Sicher, dass die ersten 3 primären Partitioonen pro Medium durchsucht werden?
2. Es ist meines Wissens nicht möglich ein Medium gemischt in Litte und Big Endian zu partitionieren.

[ari.tao]

-^^- Das 1. wäre zu klären.
Vom 2. war nie die Rede.

[mfro]

Abgesucht werden (in dieser Reihenfolge):
1) Die ersten drei Primär-Partitionen des IDE0 (so vorhanden)
2) Die ersten je drei Primär-Partitionen von SCSI 0 - 7 (so vorhanden)
3) Die ersten je drei Primär-Partitionen von ACSI 0 - 7 (so vorhanden)
4) Die Diskette in Laufwerk A: (so vorhanden)
5) Der RomPort (falls Modul vorhanden)
Wird kein ausführbarer Bootsektor gefunden, bootet TOS einen Default ohne LW.

Was passiert eigtl., wenn auf IDE0 in der ersten Primär-Partition ein BootSektor liegt, der mit LittleEndian ausführbar ist (& folglich (wg. falscher Prüfsumme) mit BigEndian nicht) und auf der zweiten Primär-Partition einer, der mit BigEndian ausführbar ist? Wäre solch ein Plättle sowohl am norm.IDE als auch am Twist per HDDRIVER  bootfähig?

Für's Booten von HD ist nicht der Boot- sondern der Rootsektor verantwortlich. Und den gibt's pro Device nur ein Mal.

Da drin steckt das Bootprogramm, das den Harddisk-Treiber nachlädt. Ohne den kann gar kein Bootsektor geladen werden.

[ari.tao]

Aha, dh. schon im RootSektor müßte die Verzweigung erfolgen wg. Endianess?
Geht das?

[mfro]

Aha, dh. schon im RootSektor müßte die Verzweigung erfolgen wg. Endianess?
Geht das?

Beim Standard TOS muß der Rootsektor im Big Endian Format geladen und ausgeführt werden können (entweder, weil er "richtigrum" auf der Platte liegt oder ein twisted cable zusammen mit einem gepatchten TOS dafür sorgt).

Die DMA-Routinen im TOS sind nur rudimentär und können nur den physikalisch ersten Sektor einer Platte laden, auf Ausführbarkeit prüfen und anstarten. Wenn das nicht unmittelbar geht: Nada Boot.

EmuTOS kann das. Auch mit Byteswapped-MSDOS Medien. Es braucht auch den HD-Treiber-"Ladetrick" nicht, weil es bereits einen vollwertigen HD-Treiber an Bord hat.

[ari.tao]

Danke für Info.
Wie geht das, wenn EmuTOS nicht im ROM liegt, sondern nachgeladen wird?
Meine vorherige Frage zielte darauf, ob es vielleicht möglich wäre, den ´Patch´ nicht im TOS sondern im Boot-Prg. des Root-Sektors zu machen

Beim Standard TOS muß der Rootsektor im Big Endian Format geladen und ausgeführt werden können (entweder, weil er "richtigrum" auf der Platte liegt oder ein twisted cable zusammen mit einem gepatchten TOS dafür sorgt). 

Wie bereits dargelegt, kann man am Yamaha das TOS von LittleEndian booten! Und mit HDDRIVER ganz normal die BootPartition auswählen.
Das funzt wirklich!! Kein TOS-Patch nötig! Und kein Trick!
Leider habe ich kein ´twisted´ Kabel, sonst würde ich das auch mal damit probieren.

[mfro]

Danke für Info.
Wie geht das, wenn EmuTOS nicht im ROM liegt, sondern nachgeladen wird?

Zaubern kann EmuTOS nicht (also auch nicht das TOS, vom dem aus es gestartet werden soll, plötzlich zum Booten von Byteswapped-Medien bewegen). Du kannst es aber natürlich durchaus von Floppy, einer zusätzlichen SCSI-Platte oder von mir aus auch über NFS laden.

Wie bereits dargelegt, kann man am Yamaha das TOS von LittleEndian booten! Und mit HDDRIVER ganz normal die BootPartition auswählen.
Das funzt wirklich!! Kein TOS-Patch nötig! Und kein Trick!

Auch der Yamaha-SCSI-IDE-Adapter (von dem -  V769970 - redest Du doch, oder?) muß sich entscheiden, ob er den 16-bittigen IDE Bus "richtig" (im Sinne von MSDOS) oder "falschrum" (im Sinne von ATARI) bedient bzw. auf den 8-bittigen SCSI-Bus umsetzt.

Nachdem das kein spezifisches Atari-Zubehörteil ist, würde ich von Ersterem ausgehen. Dann geht (=bootet) eben die ATARI-Variante nicht.

Anders ginge das nur, wenn die Yamaha-Firmware irgendwas auf der Platte (z.B. das MSDOS Media-Byte) auswerten und entsprechend verfahren würde. Dann würden aber "beliebige" Partitionierungen nicht mehr gehen.

[czietz]

-^^- also bitte, in welchem _meiner_ Postings habt Ihr denn das gelesen, daß ich _das_ bei DrCoolzic gelesen hätte?    Legasthenie? Brille verlegt? Dope?    Oder bloß ´Fake News´? 

Wenn ich hier solche Sprüche um die Ohren gehauen bekomme, spare ich mir doch gerne die weitere Diskussion mit dir. Und nein, auch mit Smileys sind die Unterstellungen nicht lustig.

[tuxie]

Die Frage ist zu Klären "Wie funktioniert die Erkennung ob das Medium Bootfähig ist"
Es wird der erste Block des devices in den ST-Ram kopiert und dieser wird ausgeführt. Ist bei dem was ausgeführt wird etwas sinnvolles dabei dann lädt dieser Block den Treiber. Sprich wenn dieser Block Modifiziert gespeichert ist so das der ST/TT/F030 damit was anfangen kann solange spielt es keine Rolle ob Big oder Little (diese Ausführung ist nur ansatzweise und nicht ins Detail erklärt).

Sprich er Fängt mit dem ersten Device am IDE an, kopiert den ersten Block in den ST-Ram und führt in aus. Kommt was sinnvolles raus dann folgt das was in dem Block drin steht an Anweisungen. Kommt nix dabei raus dann geht er zum Nächsten Device und tut es dort gleich.

D.h. Sollange der Treiber damit umgehen kann sollte auch Autboot funktionieren

[mfro]

Die Frage ist zu Klären "Wie funktioniert die Erkennung ob das Medium Bootfähig ist"
Es wird der erste Block des devices in den ST-Ram kopiert und dieser wird ausgeführt. Ist bei dem was ausgeführt wird etwas sinnvolles dabei dann lädt dieser Block den Treiber. Sprich wenn dieser Block Modifiziert gespeichert ist so das der ST/TT/F030 damit was anfangen kann solange spielt es keine Rolle ob Big oder Little (diese Ausführung ist nur ansatzweise und nicht ins Detail erklärt).

Ein klein wenig komplizierter ist es schon: der Rootsektor-Code wird nur ausgeführt, wenn die (16 Bit-) Prüfsumme 0x1234 ergibt. Das tut sie nicht, wenn die Bytes "verdreht" sind (zum Glück, sonst würde der verdrehte Binärcode gestartet, was zu nichts Gutem führen würde).

[1ST1]

Zur Info: Heute ist HDDRIVER 10.01 erschienen. Er beschleunigt IDE nochmal um 15% und ByteSwap zusätzlich auch nochmal. Sollte man mal benchmarken. und mit obigen Messungen vergleichen.

[tuxie]

Hab ich weiter oben schon geschrieben, und es kam gestern schon raus
Hatte ja schon die Beta davon womit ich am TT 5,5Mb/s schaffe

[ari.tao]

Off Topic:

-^^- also bitte, in welchem _meiner_ Postings habt Ihr denn das gelesen, daß ich _das_ bei DrCoolzic gelesen hätte?    Legasthenie? Brille verlegt? Dope?    Oder bloß ´Fake News´? 

Wenn ich hier solche Sprüche um die Ohren gehauen bekomme, spare ich mir doch gerne die weitere Diskussion mit dir. Und nein, auch mit Smileys sind die Unterstellungen nicht lustig.

Jetzt sehe ich mich leider gezwungen, @czietz , doch mal klarzustellen, wer von uns beiden hier Unterstellung betreibt! Du hast in #41 geschrieben:

Als ich im Sommer US gefragt habe, ob es nicht möglich sei, HDDRIVER so zu erweitern, daß Plättle  _zugleich_ am Atari-IDE und am Yamaha booten könnten, da ist der schier ausgerastet. Inzwischen habe ich gesehen, daß PPERA just dieses Kunststück hinkriegt:
   -> Lit.: DrCoolzic (Jean Louis-Guerin) in "Atari_HD_File_Sytem_Reference_Guide" 2014

Mit ungepatchtem TOS? Auf welcher Seite in dem o.g. Dokument liest Du das denn?

_Du_ unterstellst also _mir_, ich hätte bei DrCoolzic etwas von einem ungepatchten TOS gelesen und suggerierst auch noch, ich hätte das kolportiert. Dagegen habe ich mich doch wohl zu Recht verwahrt in #43! Und wenn Du meine Ironie nicht verträgst, dann empfehle ich Dir, künftig auf _Deine_ Unterstellungen zu verzichten.
Ich finde das inzwischen traurig, daß hier im Forum immer wieder Eitelkeiten wichtiger sind als die Sache.
Off Topic Ende.

[ari.tao]

Danke für Info.
Wie geht das, wenn EmuTOS nicht im ROM liegt, sondern nachgeladen wird?

Zaubern kann EmuTOS nicht (also auch nicht das TOS, vom dem aus es gestartet werden soll, plötzlich zum Booten von Byteswapped-Medien bewegen). Du kannst es aber natürlich durchaus von Floppy, einer zusätzlichen SCSI-Platte oder von mir aus auch über NFS laden.

Wenn ich Emutos vom norm.IDE nachladen kann, dann geht´s auch vom Yamaha!

Auch der Yamaha-SCSI-IDE-Adapter (von dem -  V769970 - redest Du doch, oder?) muß sich entscheiden, ob er den 16-bittigen IDE Bus "richtig" (im Sinne von MSDOS) oder "falschrum" (im Sinne von ATARI) bedient bzw. auf den 8-bittigen SCSI-Bus umsetzt.

Nachdem das kein spezifisches Atari-Zubehörteil ist, würde ich von Ersterem ausgehen. Dann geht (=bootet) eben die ATARI-Variante nicht.

Anders ginge das nur, wenn die Yamaha-Firmware irgendwas auf der Platte (z.B. das MSDOS Media-Byte) auswerten und entsprechend verfahren würde. Dann würden aber "beliebige" Partitionierungen nicht mehr gehen.

Nein, der Yamaha_V769970 wertet imho gar nix dgl. aus und entscheidet auch nichts! Es ist einfach so, daß das LittleEndian-Plättle am Y. vom Atari aus wie BigEndian aussieht!
Und wenn das mit einem ´twisted´ Kabel auch geht, kann man sich den Y. sparen und ist auch noch schneller...
-------

Die Frage ist zu Klären "Wie funktioniert die Erkennung ob das Medium Bootfähig ist"

Jaaa! Dazu drei ScreenShots mit RootSektor und zwei BootSektoren im Anhang:
Wie man sieht, wird HDDRIVER nicht vom RootSektor geladen, sondern vom BootSektor auf PrimärPart. C:, während der BootSektor auf PrimärPart. D: fast leer ist. Kann man _den_ nützlich machen? Wenn es gelänge, im RootSektor einen bedingten Sprung einzubauen
   IF LittleEndianMedium GOTO WeiterMitBootSektorVonD
könnte man dann dort mit einem byteswapd BootSektor weiterfahren, HDDRIVER laden und ihm den Rest überlassen...?

[czietz]

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.

Seit dem heutigen EmuTOS-Snapshot wird das oben genannte IDE-Interface übrigens automatisch erkannt. Somit ist sind EmuTOS auch auf Systemen mit "getwistetem" Kabel die IDE-Geräte ohne zusätzlichen Treiber direkt nutzbar.

PS: Anderes Thema: Viel Kritik gibt es ja an den Icons und den Mauscursorn vom EmuTOS. Nun hat sich jemand gefunden, der nicht nur meckert, sondern mithilft. Seine ersten Entwürfe sehen schon sehr gut aus.

[Nervengift]

Viel Kritik gibt es ja an den Icons und den Mauscursorn vom EmuTOS. Nun hat sich jemand gefunden, der nicht nur meckert, sondern mithilft. Seine ersten Entwürfe sehen schon sehr gut aus.

Das sind doch mal sehr schöne und auch positive Nachrichten. Komischerweise fand ich die EmuTOS Icons und auch den Mauscusor ganz ok und hatte keine Probleme damit. EmuTOS ist - soweit ich weiß, ansonsten korrigere man mich - aus den veröffentlichten Quellen von DRI bzw. den Firmen entstanden, die die Rechte an den Sachen von Digital Research hatten bzw. haben. Infolgedessen stammt der GEM Desktop, den man bei EmuTOS immer zu Gesicht bekommen hat, aus diesen Quellen und ist infolgedessen vom Design her identisch mit der OpenGEM PC Version, die ich gerade für ältere (Atari) PCs auch nicht schlecht finde. Nur gibt es weit weniger Software dafür als für den Atari. Ich bin gespannt wie sich EmuTOS weiterentwickeln wird. Da hat sich eine ganze Menge getan und man muss vor den Entwicklern echt den Hut ziehen. EmuTOS ist sicherlich auf dem Wege eine Art eierlegende Vollmilchsau zu werden. Da kann man sich nur drüber freuen.