atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: czietz am Di 06.12.2016, 20:02:55
-
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 (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!
(http://forum.atari-home.de/index.php?action=dlattach;topic=13277.0;attach=12662)
-
Das sieht doch nach einem Bytes-Swap-Effekt aus
- oder kannst Du den sicher ausschließen?
-
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.
-
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.
-
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.
-
_^^_ 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).
-
... 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).
-
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!
-
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.
-
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).
-
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"
-
"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 ...
-
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]
-
Genau und die Geschwindigkeit sinkt dann auf Diskettenlaufwerks Niveau ab ...
Naja, das halte ich jetzt aber auch für etwas zu übertrieben.
-
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.
-
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 ...
-
Wie machen denn das eigtl. Hatari & Aranym, können die auch kein BigEndian?
-
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
-
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.
-
_^^_ 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...
-
Yamaha (via SCSI) ~1800 CF
" byteswapd ~ 820 SD
Was bringt einem Byteswapping auf SCSI?
Ps: Wenn das Shiften auf 68000 so langsam ist: Könnte man das Byteswappen evtl. auf STs mit Blitter beschleunigen? Oder mit drei Byteoperationen Swap=Alow, Alow=Ahigh, Ahig=Swap?
-
5500Kbyte/s byteswap or non byteswap am TT ;)
-
Wie machen denn das eigtl. Hatari & Aranym, können die auch kein BigEndian?
Hatari weiß ich nicht, aber Aranym hat Byteswap als Config-Parameter. Die von mir genutzte ext2-Partition ist zB Little Endian, um sie bei Bedarf einfach von auf Host unter Linux mounten zu können. Einen Geschwindigkeitsunterschied merkt man selbst auf einem Raspberry Pi nicht wirklich.
Linux selbst kann auf x86 und ARM nur Little Endian Dateisysteme.
-
Linux selbst kann auf x86 und ARM nur Little Endian Dateisysteme.
Das stimmt nicht ganz. Ich weiß nicht, ob es das noch gibt, aber man konnte in Linux mal ein Kernelmodul einkompilieren, mit dem man direkt originale AHDI ATARI Partitionen mounten konnte. Das war etwa Ende der 90er und ich habe das damals auch erfolgreich genutzt, um meinen ST zu backuppen. Aber inzwischen scheints wieder Probleme zu geben, scheinbar gibts das Kernelmodul nicht mehr (? - oder war das ein Schalter für den FAT-Filesystem-Treiber? Ich weiß es nicht mehr...), immerhin gibts noch einen Config-Parameter für den Kernel für AHDI ATARI Partitionen und der scheint bei einigen Distributionen zumindestens 2010 noch gesetzt gewesen sein, aber der dann verwendete Dateisystem-Treiber für MS-DOS/FAT Partitionen kommt dann nicht mit Partitionen zurecht, die auf dem ATARI mit 32 Sektor großen Clustern angelegt wurden. Näheres siehe diesen Thread: http://www.atari-forum.com/viewtopic.php?t=18697 Für Partitionen mit kleineren Clustern gibts dort aber einen Ausweg: Partition oder die ganze Platte mittels dd in eine Datei clonen, dd kann per Parameter angewiesen werden, die Bytes zu swappen: dd conv=swab if=<inputfile> of=<outputfile> . Dann danach das outputfile mounten. Man müsste das alles was dort in dem Thread diskutiert wurde mal mit aktuellen Distributionen ausprobieren. Meine einzigen Linux-Rechner sind derzeit zwei Notebooks, dort bekomme ich keine SCSI-Platte dran.
-
Das geht viel einfacher.
Aranym *kann* das Byteswapping übernehmen und es kann (zumindest unter Linux) auf Device- (statt Image-) Files zugreifen.
Wenn ich meine CompactFlash-Karte aus meinem Falcon rausziehe und in meinen Linux-Rechner stecke, kann der zunächst nichts damit anfangen. Konfiguriere ich Aranym aber so, daß (beispielsweise) bei [IDE0]
[IDE0]
Path = /dev/sdb
ByteSwap = yes
...
steht, kann ich Aranym direkt von der CompactFlash-Karte booten und mit dem Aranym-Hostlaufwerk beliebig Dateien hin- und herschaufeln.
-
Aranym *kann* das Byteswapping übernehmen und es kann (zumindest unter Linux) auf Device- (statt Image-) Files zugreifen.
Ersteres schrieb ich ja bereits. Letzteres (direkter Zugriff auf Devices) setzt voraus, dass der Benutzer die Berechtigung hat. Die haben außer root noch die Mitglieder der Gruppe disk.
-
Das stimmt nicht ganz. Ich weiß nicht, ob es das noch gibt, aber man konnte in Linux mal ein Kernelmodul einkompilieren, mit dem man direkt originale AHDI ATARI Partitionen mounten konnte.
Mag sein, dass es das gab. In meinem konkreten Fall ging es um ext2, dafür gibt es das definitiv nicht. Der Trick mit dem Kopieren des DiskImage mit dd und den von Dir beschriebenen Parametern klappt immer noch.
-
Das stimmt nicht ganz. Ich weiß nicht, ob es das noch gibt, aber man konnte in Linux mal ein Kernelmodul einkompilieren, mit dem man direkt originale AHDI ATARI Partitionen mounten konnte.
Mag sein, dass es das gab. In meinem konkreten Fall ging es um ext2, dafür gibt es das definitiv nicht. ...
Das konnte man und kann man immer noch. Bloß nicht mit IDE-Geräten.
Bei ACSI/SCSI kein Problem, wenn man einen passenden Kernel hat (Atari Partition Support muß direkt in den Kernel compiliert werden, Modul iss nich).
Daß es so was jemals im offiziellen Kernel für byteswapped IDE disks gab, halte ich für ein Gerücht.
-
...kann ich Aranym direkt von der CompactFlash-Karte booten und mit dem Aranym-Hostlaufwerk beliebig Dateien hin- und herschaufeln.
Na also @mfro , geht doch! Ist doch in etwa das, was mir vor Augen stand, als ich #5 schrieb. Also kann man grundsätzlich mit der max. TR arbeiten (am Falcon bis zu 2500 kB/sec ohne byteswap), und das ohne Twist. Natürlich, noch schöner wär´s, wenn das auch mit Windows_8 oder Hatari ginge... (mit HDDRIVER?)
-------
Yamaha (via SCSI) ~1800 CF
" byteswapd ~ 820 SD
Was bringt einem Byteswapping auf SCSI?
Deine Frage, @1ST1 , geht leider an der Realität total vorbei. Die ist nämlich so: Der Yamaha ist ein SCSI/IDE-Konverter und die IDE-Seite ist LittleEndian. Der geniale Witz von HDDRIVER besteht nun darin, daß ein am normalen IDE-Port des Falcon mit BigEndian eingerichtetes und mit max. TR laufendes Plättle auch am Yamaha funzt - aber dort eben ´byteswapd´, also lahm, und vice versa dito. Dazu noch zwei Bemerkungen:
1) Die bisher schnellste Möglickkeit zum DatenTransfer war über Windows-partitionierte Plättle am Yamaha (für meine Zwecke völlig ausreichend). Jetzt aber eröffnet sich ein potentiell schnellerer Weg, entweder über Twist oder wie oben skizziert.
2) Wenn ich bootfähige Plättle mit HDDU vom F30-IDE auf den Yamaha clone (die dort dann ebenfalls bootfähig sind) so ist das Clonen erstaunlicherweise nur unwesentlich langsamer, als wenn ich von IDE0 auf IDE1 clone: Was ich angesichts der og. Testergebnisse so nicht erwarten würde!
-------
5500Kbyte/s byteswap or non byteswap am TT ;)
Ganz heiß und innigst erwartet! Aber bootfähig und stabil muß das sein.
-------
PS: Zehn Weise können mehr fragen, als ein Narr beantworten kann (oder so ähnlich ;D )
-
Naja, der Konverter von Yamaha ist aber eher die Ausnahme. Mit einer normalen SCSI-Platte tritt dieses Problem nicht auf.
-
Naja, der Konverter von Yamaha ist aber eher die Ausnahme. Mit einer normalen SCSI-Platte tritt dieses Problem nicht auf.
Du hast es nicht verstanden.
Man kann auch auf eine SCSI- (und jede andere) Platte ein "verkehrtrum"-Image draufschreiben und anscheinend kommt HDDRIVER sogar damit zurecht.
Für mich stellt sich da eigentlich nur eine Frage: warum macht man so was, wozu soll das gut sein, wenn als "Gewinn" nur die reduzierte Performance und ein zu nichts außer sich selbst kompatibles Format rauskommt?
-
_^^_ Das hättest Du vor zwanzig Jahren Atari fragen sollen, als die uns den IDE-Port am Falcon bescherten. Heutzutage ist das bloß eine B/Krücke zwischen den Welten.
-------
Naja, der Konverter von Yamaha ist aber eher die Ausnahme. Mit einer normalen SCSI-Platte tritt dieses Problem nicht auf.
Nee, die Ausnahme ist heutzutage eher SCSI. Ich kenne nämlich keine CF- oder SD-Karten dafür. Aber wenn Du mir welche verschaffen kannst... ;D :P >:D
-
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
-
Aus Japan gibt es einen Hersteller der SCSI CF oder auch SD Adapter anbietet. So ein Teil hatte ich auch mal an meinem Atari TT ...
-> http://www.artmix.com/wordpress/?cat=1
-
_^^_ Wow, das ist ja ein Äquivalent zum Yamaha?! Wooo bekooom und was kostet das, und warum hast Du´s wieder ausgebaut? Auf Japanisch kann ich außer mu und Atari nur noch Honda, Honda, Kawasaki....
-------
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!
-
Hatte mir damals das Teil über Ebay für knapp 130,- Euro inkl. Porto plus Zoll gekauft ...
Da kannst du bestellen und via PayPal bezahlen -> http://www.artmix.com/CF_AztecMonster.html
-
und warum hast Du´s wieder ausgebaut?
Immer wenn ich genug damit gespielt habe fehlt das Interesse und ich verkaufe all meinen Atari Krempel. So wie zur Zeit, gegen Ende Januar ist alles wieder mal weg und ich spiele nur noch mit Hatari und Co ...
-
Und dann rennst du mit dem Kopf an die Tür und klopfst nochmal dagegen weil du alles weggegeben hast.
-
Hatte mir damals das Teil über Ebay für knapp 130,- Euro inkl. Porto plus Zoll gekauft ...
Da kannst du bestellen und via PayPal bezahlen -> http://www.artmix.com/CF_AztecMonster.html
Puh, das ist ja sauteuer, da war mein Yamaha (gebraucht) _deutlich_ billiger.
Aber trotzdem danke für den Link.
-
Offenbar gibt es hier (http://forum.atari-home.de/index.php?topic=13057.40#lastPost) noch einen weiteren Konkurrenten für den Twist?
-
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
-
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?
-
Mit ungepatchtem TOS muss man da in der Tat geradezu zaubern...
-
-^^- also bitte, in welchem _meiner_ Postings habt Ihr denn das gelesen, daß ich _das_ bei DrCoolzic gelesen hätte? >:( Legasthenie? Brille verlegt? Dope? ;D Oder bloß ´Fake News´? >:D
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?
-
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.
-
-^^- Das 1. wäre zu klären.
Vom 2. war nie die Rede.
-
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.
-
Aha, dh. schon im RootSektor müßte die Verzweigung erfolgen wg. Endianess?
Geht das?
-
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.
-
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.
-
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.
-
-^^- also bitte, in welchem _meiner_ Postings habt Ihr denn das gelesen, daß ich _das_ bei DrCoolzic gelesen hätte? >:( Legasthenie? Brille verlegt? Dope? ;D Oder bloß ´Fake News´? >:D
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.
-
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
-
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).
-
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.
-
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 ;)
-
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? ;D Oder bloß ´Fake News´? >:D
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.
-
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...?
-
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 (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.
-
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. 8)
-
[…] 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.
Äh. Praktisch keine, im Vergleich. Gibt’s ’ne Liste?
* 1st Word
* Adimens
* GEMGraph, GEMDraw etc.
-
Du hast den recht genialen Ventura Publisher vergessen. Allerdings ist Calamus besser.