atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: tuxie am So 07.08.2016, 18:54:51
-
Welche Treiber gibt es für Ataris mit IDE Interface ?
Ich fang mal an...
HDDriver
Hushi
Atari AHDI 6
Cecile (Französisch und scheint nur am Falcon zu laufen.... TOS4.XX Optimiert ?)
CBHD ab 5.00
ICD 6.5.5
-
Atari AHDI 6
-
- Cecile
- CBHD ab 5.00
-
Der neueste ICD dürfte auch damit umgehen können.
-
Der Hintergrund warum ich frage ist der, das wir mit unserem IDE Interface für den TT unterschiedliche Datentransferraten erhalten. HDDriver z.b. lässt sich z.b. nicht in den Fastram laden und erhalten dadurch verminderte Leistung (2Mb/s weniger als mit pperas Treiber). PPeras Treiber ist aber nicht so recht nutzbar da man den bigdos treiber braucht und der Bombt bei mir.
Mit Hushi erhalte ich recht gute werte, der lässt sich auch in den Fastram laden der ist damit dann 1,5MB/s schneller als HDDriver. Aber er lässt sich mit dem Modus (wird noch nicht verraten welcher) denn wir eingebaut haben, nicht auf C installieren, kommt dann das keine brauchbare Partition gefunden wurde.
Ich werde heute Abend einmal Testen mit welchem Treiber man die Volle Leistungsfähigkeit des IDE Interfaces ausnutzen kann.
-
Wieso soll der Treiber komplett im TT Ram laufen ?
Der nutzt doch nur das ST Ram, oder?
Es gibt doch nur diesen 64kB Buffer im TT Ram für den Plattentreiber. Wenn du nicht von C:\ booten kannst, ist dein TT TOS denn gepatcht?
Beim 8Mhz ST ist auf dem IDE Bus bei 1200kB bis 1400kB Schluß und beim Falcon mit den 16Mhz das doppelte vielleicht und beim Atari TT das gleiche, oder? Ohne jetzt spezielle eigene Treiber zu benutzen so wie Holger, oder?
-
Holger nutzt auch keine Speziellen Treiber, das eine Foto mit non xhdi war schlicht und einfach ppera mit byteswap..
Hushi gibt sogar eine Meldung aus... "Treiber wurde ins Fastram kopiert"
Doch das geht den Treiber in den Fastram laden. bei hddriver geht es mit hddriver.prg wenn man ihn direkt aus Tos raus startet. Bei einigen anderen geht es auch. Und ja das TOS lädt einen Block in den ST ram und führt in aus. Dieser ausführbare Block definiert aber an welche Stelle des Rams der Treiber dann geladen wird.
Und ja mein TOS ist bereits gepatcht und läuft auch einwandfrei. Wir erreichen datenraten die ein vielfaches des ST´s und auch Falcon ist. Wie gesagt HDDriver im fastram als prg ausgeführt unter Tos erhält man rund 1.2MB/s mehr. Am schnellsten ist pperas Treiber, aber auch der Treiber, der am unbrauchbarsten ist bei großen Partitionen.
-
Bigdos bombt wenn es in einer falschen Startreihenfolge im Autoordner platziert wird. Probiere mal ganz vorne, als erstes, oder gar ganz hinten, als letztes.
Ansonsten mal U.Seimet kontaktieren, mit einem IDE-Prototypen-Board von euch kann der sicher den HDDRIVER noch etwas tunen.
-
Wir stehen schon seit einer weile mit Uwe Seimet in Kontakt, aber auch HD-Driver in aktueller Version erzielt schnelle Ergebnisse. Es würde die Möglichkeit bestehen einen SCSI-Treiber zu Programmieren der einen Optimierten Datentransfer gewährleistet. Darauf würde dann HDDriver und CBHD aufsetzen.
Dokumentantionen dafür gibt es hier. Ich denke auch die CTPCI mit dem IDE Interface würde davon Profitieren.
Jemand hier der dies umsetzen würde ? Haben da Ideen wo man den Transfer steigern kann...
Dokumentation gibt es hier
http://hddriver.seimet.de/de/downloads.html
-
Pera Putnik (Ppera) hat ganz deutlch in seinen Dokumenten zum Ausdruck gebracht, daß seine Treiber nicht gut mit HDDriver zusammenarbeiten - ich bitte das zu bedenken! Eine Kombination, die bei mir keine Probleme zu machen scheint, ist der Treiber von Pera Putnik und HUSHI.PRG im Auto-Ordner! BigDOS sollte als erstes (nach dem Boot-Selektor) im AUTO-Ordner stehen!
-
Wer redet von pperas treiber? Der ist eh ungeeignet da er nur kleine Partitionen unterstützt... Bigdos bombt am TT auch wenn es der einzigste im autoordner ist
-
Bei mir funzt Bigdos wunderbar auf dem TT.
-
Vielleicht hat BigDOS Probleme auf dem Atari TT wenn er mehr als 4MB ST Ram hat ?
-
Da wir pperas Treiber für byteswap und co nicht brauchen, ist das auch vollkommen egal. Klar ist er von allen Treibern am Schnellsten. Aber hushi z.b. ist auch sehr schnell von daher mach ich mir da auch keinen Kopf da hushi ja auch frei im Internet zu erhalten ist.
-
Wer redet von pperas treiber? Der ist eh ungeeignet da er nur kleine Partitionen unterstützt... Bigdos bombt am TT auch wenn es der einzigste im autoordner ist
Du hast selber weiter oben erwähnt, daß Du den Treiber in Verbindung mit HDDriver gretestet hast! Darauf münzte sich mein Beitrag!
Und wenn Du keine großen Partitionen benötigst, kannst Du BigDOS weglassen - das ist sowieso nur zur Unterstützung großer Partitionen von ihm entwickelt und hat nichts mit seinem eigentlichen Treiber zu tun (nach seinen eigenen Treibererläuterungen)! Der Treiber funzt auch ohne - alletrdings dann nur mit Partitioen kleiner 40MB! Bei größeren bist Du generell drauf angewiesen! Das betrifft nach seinen Angaben IDE- gleichwie SCSI-Anlagen!
Könnten Deine Probleme mit BigDOS evtl. auf einen Hardware-Bug zurückzuführen sein?
-
Sorry @Burkhard Mankel , glaubst du wirklich ich weiß das nicht das man HDdriver und ppera nicht zusammen nutzen sollte ? Glaubst du wirklich ich bin so doof und ich weiß nicht wozu Bigdos da ist ? Wir reden hier von einem Rechner wo man locker eine 4 GB CF Karte oder Größer verwenden kann da schon allein wenn man Mint oder Magic nutzen möchte eine 32MB Partition nicht ausreicht. PPera hat den Treiber ausgerichtet für User mit einem ST wo 32Mb schon ausreichen kann. Und hier geht es auch nicht darum herauszufinden wie ein Treiber funktioniert sondern es geht darum Optimierungen anzustellen. Da wir mit HDDriver 3,5Mb/s schaffen und mit pperas Treiber 5,8Mb/s.. und das ist schein ein großer Unterschied. Wobei man mit hushi bei 4 bzw. 5MB/s liegt. PPeras Treiber sind dafür ausgelegt diesen ganzen Twisted misst abzubilden, das brauchen wir aber nicht da wir das Hardwaremässig machen und HDDriver läuft damit super.
-
Vielleicht hat BigDOS Probleme auf dem Atari TT wenn er mehr als 4MB ST Ram hat ?
Meine TTs haben beide 20 MB RAM. 4+16
Bigdos ist auch nüttzlich, um PC-foratierte Wechselmedien zu lesen, z.B. ZIP Disketten.
-
Lesen ist nicht dein Ding, oder ?
Ich schrieb ST Ram ...
Oder BigDOS stört sich an dem gepatchten TOS 3.06 ?
-
Oder BigDOS stört sich an dem gepatchten TOS 3.06 ?
Das Gefühl habe ich langsam auch!
Und @tuxie !
Wenn Du Dich an meinen Beiträgen mit meine Kenntnissen stößt, solltest Du gleich richtig formulieren und nicht erst nachträglich ändern - als ich meinen letzten Post mit Link auf einen entsprechenden Post von Dir setzte, stand da noch was davon drin, daß Du meinst, daß der Ppera Treiber nicht ohne BigDOS arbeitet - und dem habe ich ja mit meinem zweiten Absatz widersprochen! Auf jeden Fall wirst Du wenn Du auch auf dem Atari Zukuntsweisend entwickeln willst, um BigDOS nicht herum kommen!
edit:
Bei mir startet BigDOS in Verbindung mit Pperas Treiber UND SCSI-Tools (HuSHi) unter TOS 1.(0)4 und 2.(0)6 sowie EmuTOS getesteter Maßen einwandfrei!
-
Lesen ist nicht dein Ding, oder ?
Ich schrieb ST Ram ...
Oder BigDOS stört sich an dem gepatchten TOS 3.06 ?
Auf meinen beiden TTs läuft ROMRAM und WinX, das patcht TOS 3.06 das einem schwindlig wird. Außerdem noch an einer ganz anderen Stelle im Adressbereich. Auf dem Falcon übrigens auch, und auch da ist BigDOS immer aktiv.
Apropos Falcon, der hat doch 14 MB ST-RAM... Auch daran stört sich BigDOS anscheinend nicht.
-
Oder BigDOS stört sich an dem gepatchten TOS 3.06 ?
Das Gefühl habe ich langsam auch!
Und @tuxie !
Wenn Du Dich an meinen Beiträgen mit meine Kenntnissen stößt, solltest Du gleich richtig formulieren und nicht erst nachträglich ändern - als ich meinen letzten Post mit Link auf einen entsprechenden Post von Dir setzte, stand da noch was davon drin, daß Du meinst, daß der Ppera Treiber nicht ohne BigDOS arbeitet - und dem habe ich ja mit meinem zweiten Absatz widersprochen! Auf jeden Fall wirst Du wenn Du auch auf dem Atari Zukuntsweisend entwickeln willst, um BigDOS nicht herum kommen!
edit:
Bei mir startet BigDOS in Verbindung mit Pperas Treiber UND SCSI-Tools (HuSHi) unter TOS 1.(0)4 und 2.(0)6 sowie EmuTOS getesteter Maßen einwandfrei!
@Burkhard Mankel erzähl nicht so einen Blödsinn, ich brauche mit HDDriver kein Bigdos Treiber, hast du einen TT ? Ja ? Dann bring Konstruktives rüber, hast du keinen dann halte dich raus, weil ein TT ist ein ganz anderes level als ein ST. Wir haben hier auch Tos3.06 und kein Tos2.06... und mir noch zu unterstellen das ich um dich zu Ärgern die Beiträge änder ist schon ne höhe. Ich glaube ich werde mich hier langsam aber sicher ausklinken und gehen.
-
Lesen ist nicht dein Ding, oder ?
Ich schrieb ST Ram ...
Oder BigDOS stört sich an dem gepatchten TOS 3.06 ?
Auf meinen beiden TTs läuft ROMRAM und WinX, das patcht TOS 3.06 das einem schwindlig wird. Außerdem noch an einer ganz anderen Stelle im Adressbereich. Auf dem Falcon übrigens auch, und auch da ist BigDOS immer aktiv.
Apropos Falcon, der hat doch 14 MB ST-RAM... Auch daran stört sich BigDOS anscheinend nicht.
Ich weiß nicht woran es liegt, erhalte wie gesagt zwei Bomben. Könnte eventuell daran liegen das wir alles in den Fastram schieben. Aber ganz ehrlich hab da keine Lust den fehler zu suchen da mit vernünftigen Treiber es eh nicht gebraucht wird.
-
Ich habe von BigDOS keinen Plan aber ist die Falcon Version nicht eine spezielle extra für den Falcon ?
Muss ja einen Grund haben warum es bei Tuxie nicht läuft, sein Atari TT ist bis auf 10MB ST Ram und das gepatchte TOS 3.06 um von IDE booten zu können völlig original ...
-
Kann das heute Abend gern nochmals Testen. Werde aber dazu meine CF neu Partitionieren müssen da sie momentan DOS Kompatibel Partitioniert ist. Und wenn ich da PPeras Treiber nutze dann zerhaut der das Dateisystem. Muß also unsere Karte anders Jumpern und andere karte verwenden.
-
... Tos3.06 und kein Tos2.06...
Auch das TOS 3.(0)6 basiert im Grunde nach meinen Infos auf den gleichen Grundlagen wie die ST TOSse! Und laut Pera Putnik sollen seine Treiber, wenn mir die Text richtig übersetzt wurden, auch auf TT Maschinen laufen - was auch durch @1ST1 Beiträge hier bestätigt wurde! Darum kann der Fehler eigentlich nur in der Hardware DEINES System begründet sein - bzw eines Patches DEINES TOS 3.(0)6!
Da Du mir aber vorhälst, daß ich KEIN SO SCHÖNES SPILZEUG habe wie Du, will ich Dir in diesem Punkt recht geben und mich zurückziehen! Aber hole mich dann auch nicht mit einem "member" zurück!
-
Es ist überall die selbe BIGDOS Version, man kann die auch immer noch beim Autor in der neuesten Version runterladen. Ich kann BIGDOS nur empfehlen, auch auf einem TT mit HDDRIVER. BIGDOS ermöglicht es mit, auf dem TT 1 GB große BGM Partitionen unter ganz normalen TOS zu benutzen. Das ist für größere Datensammlungen (Midi-Files, Mod-Files, CFNs, Grafiken, ... etc.) sehr praktisch. Bei mir auf dem TT ist nur noch die Bootpartition 512 MB "klein". Außerdem behandelt BIGDOS auf von PCs beschriebenen Medien "Fehler" mit FAT32 langen Dateinamen und Leerzeichen im Dateinamen korrekt (sprich sie werden fehlerfrei ignoriert) und machen erst so manches ZIP-Medium, welches von einem PC formatiert wurde, überhaupt lesbar. Die Mühe lohnt auf jeden Fall.
-
Welche Treiber gibt es für Ataris mit IDE Interface ?
Ich habe da auch noch GE_HDI von GE_SOFT in meiner Sammlung. Wenn ich das richtig verstanden habe, ist der AHDI_5-kompatibel - und dann kann er wohl kein IDE? Andererseits sagt die Doku, daß er mehrere Bussysteme bedienen kann (gibt´s denn Ataris mit mehreren Scsi-Bussen?).
---
HDDriver z.b. lässt sich z.b. nicht in den Fastram laden
Hast Du den HDDRIVER in´s \AUTO\ gepackt? Soweit ich mich erinnere, rät US davon ausdrücklich ab. Vielleicht ist HDDRIVER schneller, wenn er per BootStrap geladen wird?
---
Ansonsten mal U.Seimet kontaktieren, mit einem IDE-Prototypen-Board von euch kann der sicher den HDDRIVER noch etwas tunen.
Gute Idee! Bin mal gespannt auf das Ergebnis... ::)
---
Bei mir funzt Bigdos wunderbar auf dem TT.
Ich wundere mich, daß ihr überhaupt BIGDOS verwendet - wenn es stattdessen doch MiNT gibt. Kann mir mal jmd., ich bitte in aller Demut, dieses Rätsel erklären? (Falls einer Probleme mit MiNT_1.15.9 hat, helfe ich gerne (das sollte auch bei nur 4MB noch gut laufen); es gibt allerdings Zickereien mit SingleGEM, empfehlenswert ist NAES2). Habe ich irgendeine wichtige Eigenschaft übersehen, die BigDOS hat - aber MiNT_1.15.9 nicht? (außer 130k(?) weniger SpeicherBedarf)
wenn Du auch auf dem Atari Zukuntsweisend entwickeln willst, um BigDOS nicht herum kommen!
Nee Burkhard, das ist nicht die Zukunft, das ist echt geile Retro ;).
Ich weise daraufhin, daß US in den ReadMes zu HDDRIVER_7.xx ausdrücklich allen Falknern rät, von BigDOS_8 auf BigDOS_6 zu retardieren. In späteren HDD.-Versionen verschwand diese Warnung wieder - keine Ahnung, warum; darf man spekulieren?
ist die Falcon Version nicht eine spezielle extra für den Falcon ?
Ja, sowieso - ganz unabhängig von meiner vorigen Bemerkung. Könnte ja sein, daß einer der damals Tätigen keinen TT zum Test hatte.
Übrigens, habt ihr alle die gleichen Grafik-Treiber auf den TTs? Ein Bus-Fehler heißt ja, daß auf eine Adresse zugegriffen wird, wo keine HW ist; da muß man imho ganz scharf hinschauen, _wann_genau_ der passiert - vielleicht streiten sich zwei um dieselben Plätze? (Ich habe auf meinem TT mit CrazyDotsGK zwei verschiedene GK-Treiber-Sätze. Es gibt Prge., die sich kreuzweise mit dem einen oder dem anderen schlecht vertragen).
---
Apropo vertragen: "Der hl. Mensch streitet nicht. Niemand im Reich, der mit ihm zu streiten vermag."
(Lao Tse, Tao Te King)
---
Darum kann der Fehler eigentlich nur in der Hardware DEINES System begründet sein - bzw eines Patches DEINES TOS 3.(0)6!
Das scheint mir ein etwas voreiliger Schluß zu sein. Ex falso quodlibet.
-
Hast Du den HDDRIVER in´s \AUTO\ gepackt? Soweit ich mich erinnere, rät US davon ausdrücklich ab. Vielleicht ist HDDRIVER schneller, wenn er per BootStrap geladen wird?
Also, wenn ich hddriver.prg von tos aus Lade dann wird der Treiber auch ins Fastram gepackt, und erhalte auch rund 4,7MB/s Datentransfer speed. Installiere ich ihn als .sys dann lässt er sich nicht in den Fastram laden. Uwe Seimet meint das es nicht geht den Treiber in den Fastram zu laden.
Wie meinst du das mit dem Boostrap ?
Ich wundere mich, daß ihr überhaupt BIGDOS verwendet - wenn es stattdessen doch MiNT gibt. Kann mir mal jmd., ich bitte in aller Demut, dieses Rätsel erklären? (Falls einer Probleme mit MiNT_1.15.9 hat, helfe ich gerne (das sollte auch bei nur 4MB noch gut laufen); es gibt allerdings Zickereien mit SingleGEM, empfehlenswert ist NAES2). Habe ich irgendeine wichtige Eigenschaft übersehen, die BigDOS hat - aber MiNT_1.15.9 nicht? (außer 130k(?) weniger SpeicherBedarf)
Ich nutze auch nur Mint Kernel Version 1.19 oder Magic und habe eine große F32 Partition ohne bigdos. Einen TT Sollte man schon auf Mint oder Magic setzen, 1. ist er Schneller und 2. kann man ihn viel besser fordern.
Wir stehen seit einer weile mit Uwe Seimet in Kontakt, um den Treiber zu Optimieren, und er ist der Meinung das man unter HDDriver einen SCSI Treiber laut Spezifikationen packt um den beschleunigten Zugriff zu gewährleisten. Es gibt zwar aussagen das man es nicht machen soll den Treiber in den Fastram zu laden da es Probleme beim DMA Zugriff geben könnte. Aber der DMA kann ja auch nicht auf das IDE Interface zugreifen daher denke ich spielt das keine Rolle.
-
Wie meinst du das mit dem Boostrap ?
Ich schrieb BootStrap (= Schnürsenkel), nicht Boostrap.
Ist der Begriff inzwischen unbekannt? Im C.-Altertum, also vor etwa 1970, war das die Bezeichnung für das erste Software-Prg., das von der Hardware angesprungen wurde. Damals üblicherweise auf einem kleinen Endlos-Lochstreifen, weil der Lochstreifenleser das erste Peripherie-Gerät war, das abgefragt wurde - ganz analog dazu, wie heutzutage der Bootsektor einer PlattenPartition angesprungen wird (dessen Inhalt wohl auch als BootLoader bezeichnet wird). Ich finde die Metapher sehr schön, sollte man pflegen. Es müßte also dieser BootStrap den HD-Treiber in´s FastRAM anstatt in´s STRAM laden. Das geht sicher nur, wenn das FastRAM sogleich angesprungen werden kann (direkt oder via TOS im ROM), aber wohl nicht, wenn es erst noch per Treiber ´eingebunden´ werden muß (weil dafür der Platz im BootSektor vielleicht zu klein wäre). Mit nachgereichtem FastRAM (wie bei der MAGNUM im F30) geht´s also kaum. Beim TT wäre dann die Frage (an unsere HW-Freaks? oder an unsere TOS-Kosmetiker?) nach der Einbindung - und die, US oder sonst wen dazu zu bewegen, einen BootStrap neu zu programmieren.
Uwe Seimet meint das es nicht geht den Treiber in den Fastram zu laden.
Unser HD-Dr. meint grundsätzlich immer, daß es nicht geht, wenn man ihm etwas vorschlägt :( . Vermutlich eine sinnvolle Strategie der Arbeits-Vermeidung. Soll der Vorschlagende doch erst mal beweisen, daß es doch geht! Also die Arbeit selber machen.
Aber wenn HUSHI, im \AUTO\ gestartet, das kann - warum dann nicht HDDr.?! US´ Argument, wie ich ihn kenne, wäre wohl, daß er unbedingt konform mit der SCSI-Spezifikation bleiben wolle. Ich sehe nicht, warum das ein Widerspruch sein sollte - und wenn doch, welche Relevanz hat das für unsere TTs?! Es ginge also bloß darum, daß US den HDDRIVER analog zu HUSHI für den \AUTO\ und im FastRAM fit macht. Dann kann man sich das oben geschilderte Gehampel mit dem BootStrap sparen. Letztlich ist der Unterschied der beiden Möglichkeiten also ein ästhetisch-ideologischer Streitpunkt. König Kunde? Die Macht liegt beim Macher.
da es Probleme beim DMA Zugriff geben könnte.
Ihr wollt also den UDMA-Modus anstatt des PIO-Modus? Chapeau!
Dann allerdings müßte vmtl. ein nicht unerheblicher Teil des (SCSI-) Treibers (der letzlich immer zu Grunde liegt) neu programmiert werden. Das ist wohl keine kleine Arbeit. Aber imho völlig unabhängig von der oben diskutierten Frage, ob der Treiber im FastRAM laufen kann. Müßte man sich mal die ASM-Befehle für den DMA-Zugriff genauer anschauen. Das kann ich nicht beurteilen, das übersteigt meine Kenntnisse. (Ich habe ASM immer nur so weit betrieben, wie es für meine Projekte unbedingt nötig war).
Gibt es Vorbilder da draußen in der gr.w.Welt für UDMA am 68030er? Apples?
-
@1ST1 , kann man BIGDOS _unter_ MAGX nutzen? Mein MAGX_6.2 hat Probs mit FAT32.
-
Guten Morgen,
Sorry war ein Schreibfehler, natürlich bootstrap und die Technik des bootstrapping ist mir wohl sehr bekannt da auch heute noch gerade in der linuxwelt diese sehr oft verwendet wird. Meine Frage richtete sich mehr in die Richtung "wie könnte das beim TT aussehen ? Was als bootstrap app nutzen, welches dann den hddriver in den Fastram läd "
Dieser von Uwe vorgeschlagener scsi Treiber wäre quasi sowas ähnliches, der scsitreiber würde quasi vom IDE Interface geladen und in den st RAM kopiert, dort wird er ausgeführt und als nächstes wird dann der hddriver geladen der dann ins Fastram geschoben wird (der ist ja beim TT bereits initialisiert und angemeldet ).
Mit dma Zugriff meinte ich nicht udma des IDE interface sondern dma des TT s, denn der hat da soeinen netten Chip der sich dma nennt und Bindeglied von acsi, Floppy und so ist. Er ist der Meinung das da der dma keinen Zugriff auf denn TT RAM hat es zu Datenverlust führen kann. Ich teste wiederum schon seit märz April und hatte noch keinen Datenverlust.
-
"wie könnte das beim TT aussehen ? Was als bootstrap app nutzen, welches dann den hddriver in den Fastram läd "
Das hab ich ja geahnt - und dementsprechend skizziert.
Wenn ich die Doku zum HDDRIVER richtig verstanden habe, hat der ja genau den SCSI-Treiber von St.Engel komplett eingebaut. Und wenn ich das weiters richtig verstanden habe, ist es möglich, einen anderen (verbesserten) SCSI-Treiber hinter HDDRIVER nachzuladen. (Möglicherweise geht´s auch vorweg (sodaß der HDDR. dann nur diejenigen Funktionen des Vorangehenden nutzt, die er selbst nicht hat)). Wenn ihr von IDE booten wollt, könnte man vielleicht in der Boot-Phase auf etwas Geschwindigkeit verzichten - und den/einen Treiber später im AUTO\ oder aus MAGX´ START\ bzw. NAES´ APPS\ nachladen? Den Treiber von St.Engel gibt´s doch, probiert doch mal, den (hinter HDDRIVER) in´s FastRAM zu laden. Oder den HUSHI. Oder einen zweiten HDDRIVER. So müßte man am HDDRIVER gar nix ändern, und am BootStrap auch nicht.
Ihr wollt also den UDMA-Modus anstatt des PIO-Modus? Chapeau!
Mit dma Zugriff meinte ich nicht udma des IDE interface sondern dma des TT s,
Da habe ich einfach mal auf den Busch geklopft... ;)
Der DMA-Bus im TT ist ja, bei vorhandener GK, weit weniger belastet als der im F30. (In meinem Falcon habe ich den Blitter abschalten müssen, damit der ohne Datenverluste lief. Hat viel Blut, Schweiß & Tränen gekostet, bis ich das kapiert hatte). In Frage steht also die Bus-Belastung &-Kontrolle. Mach die Tests mal mit heftigem DMA-Sound zusammen - wenn´s dann immer noch keine Datenverluste gibt, sehe ich imho kein Hindernis mehr. Die Verbesserung des SCSI-Treibers wäre dann ein völlig unabhängiges Item.
-
HDDriver zweimal zu laden, also einmal als hddriver.sys im Autoboot und einmal im Auto Ordner mit Fastram flags habe ich schon versucht. Leider ändert sich da nichts. Ich könnte es jedoch einmal mit hushi versuchen oder umgekehrt erst hushi und dann HDDriver laden lassen.
Ja das mit Sound habe ich auch schon getestet indem ich Demos laufen lassen habe wie beams.tt und das lief einwandfrei.
-
IDE-DMA wird beim TT ohne einen weiteren (zu entickelnden) DMA-Controller nicht machbar sein. Sowohl der ACSI-DMA als auch der SCSI-DMA-Controller können nur mit dem jeweiligen ACSI/SCSI-Bus umgehen. Schaut euch mal den Schaltplan an, diese beiden Chips können DMA nur, wenn die Daten "durch" den Chip durch gehen, beide können kein DMA welches nur auf der CPU-Bus-Seite statt findet, denn sonst wären diese beiden DMA-Controller quasi sowas wie ein Blitter. Beim ACSI-DMA-Controller kommt aus meiner Erinnerung noch hinzu, dass er nur DMA ins ST-RAM machen kann, evtl. sogar nur in die unteren 4 MB, genau wie in einem ST. Der SCSI-DMA-Controller kommt nach meiner Erinnerung überall dran. Also muss auch beim TT PIO reichen, aber da gibts ja auch schnellere Modis als PIO0. Da könnte man ansetzen, in dem man dem HDDRIVER die schnelleren PIO-Modis beibringt, sofern das AHDI-kompatible IDE-Interface diese zulässt.
Am besten mal einen Blitter für den TT entwickeln, der mit auf der RAM-Karte sitzt und den kompletten Adressraum der 68030 abdecken kann. Der müsste dann folgende Modis unterstützen:
1. Kopieren von Speicherbereich zu Speicherbereich, und zwar mit vollen 16 MHz. Evtl. mit Optimierungen für die verschiedenen Videomodis des TT und von Grafikkarten: Bitplanes und RGB-Pixel. Das wäre dann für alle möglichen Grafikkarten und Onboardgrafik interessant. Dazu müsste dann halt noch jemand ein passendes VDI basteln, auch für ET4000 und evtl. Mach32, Matrix und Co.
2. Kopieren von einer fixen Adresse in einen Spreicherbereich, mit optionaler Wandlung Litte/Big-Endian (Byteswap), für IDE-Interface lesen. Dafür müsste dann ein Festplattentreiber geschrieben oder angepasst werden.
3. Kopieren von Speicherbereich auf fixe Adresse, mit optionaler Wandlung Little/Big-Endian (Byteswap), für IDE Interface schreiben. Dafür müsste dann ein Festplattentreiber geschrieben oder angepasst werden.
Ich kann mir vorstellen, dass so ein Chip in VHDL garnicht so schwierig zu implenetieren wäre.
-
Da on hab ich gesprochen ;)
-
Träumerei oder meint ihr das kann jemand umsetzen ?
Das TOS müsste ja auch noch angepasst werden. IDE Transfer über den Blitter beim Atari ST ist recht langsam soweit ich das weiss und beim Falcon ... ?
DMA = Geschwindigkeit stimmt ja so nicht. Beim Atari TT werden die möglichen 5MB am SCSI Bus bei weitem nicht erreicht. Bei 1,9MB ist da Schluß ...
Das SCSI Interface auf dem Atari Transputer Zusatzplatine mit dem DIL L5380 hat einen Motorola DMA Baustein zur Seite !
(http://fglukas.lima-city.de/bilder/atari/scsi.jpg)
-
Der Witz bei den verschiedenen IDE-DMA Modi ist nicht, daß man dafür einen DMA-Controller bräuchte (braucht man nicht unbedingt), der Witz ist, daß IDE-DMA auf beiden Taktflanken Daten überträgt.
Die zugrundeliegende Techik ist damit sehr ähnlich zu der Anbindung von DDR-RAM, das kann kein Atari DMA-Controller (und auch das Motorola Dingens nicht).
Bei opencores.org gibt es einen ATA-Core, der Multiword-DMA beherrscht.
-
Es geht hier überhaupt nicht um ide dma, es geht darum das wenn der hd driver im fastram liegt, es zu übertragungsproblemen kommen kann. Da ja acsi und auch floppy über den dma geht.
-
Es geht hier überhaupt nicht um ide dma, es geht darum das wenn der hd driver im fastram liegt, es zu übertragungsproblemen kommen kann. Da ja acsi und auch floppy über den dma geht.
Eigentlich legt TOS im ST-RAM den _FRB (FastRamBuffer) an, dessen Position auch über den gleichnamigen Cookie erfragt werden kann. Dorthin/Dorther wird ST-DMA gemacht, m.E. völlig egal ob das HDDriver executable im Fast RAM liegt oder nicht.
Wo ist das Problem?
-
Wenn der Plattentreiber nur aus dem ST Ram richtig läuft dann laßt das doch auch so. Geschwindigkeit ist nicht immer alles ...
-
Das gilt ja nicht für _den_ Treiber - sondern für _einen_ der Treiber.
Ist denn die Gegenprobe entsprechend ausgefallen, daß also HUSHI genau so viel langsamer wird, wenn er _nicht_ im FastRAM läuft? Sonst könnte der Unterschied vielleicht darin bestehen, daß der sich nicht exakt an die SCSI-Spezifikation hält und eben deshalb schneller (aber auch unsicherer?) läuft. (Ich kann mich erinnern, daß IDE anfangs einen sehr schlechten Ruf hatte, indem behauptet wurde, es sei wesentlich unsicherer als SCSI; heute redet niemand mehr davon).
-
Ich stoppe das hier mal..........
Ist bei allen Treibern das gleiche verhalten........
Wir sind einen schritt weiter gekokommen, aber mehr werde ich hier nicht erzählen.... im Übrigen wird das gleiche verhalten bei einem CT60 Falcon mit CTPCI exisitieren wenn die CF/HDD an der CTPCI hängt...
-
Wir sind einen schritt weiter gekokommen, aber mehr werde ich hier nicht erzählen....
Ich nehme an, diese ganze "Geheimniskrämerei" wird eines Tages aufgelöst? ;D
-
Wir sind einen schritt weiter gekokommen, aber mehr werde ich hier nicht erzählen....
Ich nehme an, diese ganze "Geheimniskrämerei" wird eines Tages aufgelöst? ;D
Ja sicher.. ;)
-
Der Witz bei den verschiedenen IDE-DMA Modi ist nicht, daß man dafür einen DMA-Controller bräuchte (braucht man nicht unbedingt), der Witz ist, daß IDE-DMA auf beiden Taktflanken Daten überträgt.
Das müsste sich doch geschickt ausnutzen lassen... IDE ist 16 Bit breit. Das RAM-Interface für TT-RAM ist 32 Bit breit. Fallende und steigende Taktflanke auf untere und obere 16 Bit des Datenbusses verteilen...
-
Der Witz bei den verschiedenen IDE-DMA Modi ist nicht, daß man dafür einen DMA-Controller bräuchte (braucht man nicht unbedingt), der Witz ist, daß IDE-DMA auf beiden Taktflanken Daten überträgt.
Das müsste sich doch geschickt ausnutzen lassen... IDE ist 16 Bit breit. Das RAM-Interface für TT-RAM ist 32 Bit breit. Fallende und steigende Taktflanke auf untere und obere 16 Bit des Datenbusses verteilen...
Genau das ;) Damit könnte man einen Schreibzyklus einsparen und dann natürlich auch jeweils einen Lesezyklus. Zumindest in den RAM
-
Das TOS müsste ja auch noch angepasst werden. IDE Transfer über den Blitter beim Atari ST ist recht langsam soweit ich das weiss und beim Falcon ... ?
1. Der Treiber darf gerne im PIO-Modus geladen werden, das ist nicht viel. Der Treiber schaltet dann DMA ein. Dazu wäre keine TOS-Änderung nötig.
2. Der ST-Blitter kann nicht sonderlich schnell sein, weil der immer n zu n kopiert, also immer eine Anzahl Bytes von einem Speicherbereich zu einem anderen. Bei IDE kann der nur effkitv helfen, wenn er nicht n zu n, sondern 1 zu n bzw. n zu 1 transferieren kann. Denn das IDE-Interface liefert seine Daten ja immer auf einer Speicherzelle, bzw. will sie dort haben. Quelle oder Ziel im RAM ist aber ein ganzer Speicherbereich, z.B. ein ganzer Sektor oder Cluster.
-
2. Der ST-Blitter kann nicht sonderlich schnell sein, weil der immer n zu n kopiert, also immer eine Anzahl Bytes von einem Speicherbereich zu einem anderen.
Das ist zwar vehement vorgetragen, aber falsch.
Der Blitter kann durchaus einen Speicherbereich aus einer einzigen I/O-Adresse befüllen oder andersherum. Dafür hat er je ein Source- und ein Destination-Increment Register, das festlegt, wo's jeweils weitergehen soll.
Wenn das "auf einer Seite" mit 0 vorbelegt wird, liest oder schreibt der Blitter immer auf dieselbe Adresse und "die andere Seite" bekommt eben einen entsprechenden Increment.
-
Oh, danke, das wusste ich nicht (mehr). Naja, dann ist er wohl doch besser als gedacht.
Aber wie sieht es andersrum aus, Speicherbereich immer auf eine Adresse ausgeben? Also IDE schreiben?
-
Aber wie sieht es andersrum aus, Speicherbereich immer auf eine Adresse ausgeben? Also IDE schreiben?
Dafür hat er je ein Source- und ein Destination-Increment Register, das festlegt, wo's jeweils weitergehen soll.
-
Wären die Milan SCSI Treiber Quellen nicht als Vorlage für euer IDE Interface zum HDDriver brauchbar -> http://www.ccac.rwth-aachen.de/~michaels/files/milan/