HD Treiber für Ataris mit IDE Interface

[tuxie]

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.

[tuxie]

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.

[Lukas Frank]

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 ...

[tuxie]

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.

[Burkhard Mankel]

... 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!

[1ST1]

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.

[ari.tao]

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.

[tuxie]

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.

[ari.tao]

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?

[ari.tao]

@1ST1 , kann man BIGDOS _unter_ MAGX nutzen? Mein MAGX_6.2 hat Probs mit FAT32.

[tuxie]

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.

[ari.tao]

"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.

[tuxie]

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.

[1ST1]

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.

[tuxie]

Da on hab ich gesprochen

[Lukas Frank]

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 !

[mfro]

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.

[tuxie]

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.

[mfro]

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?

[Lukas Frank]

Wenn der Plattentreiber nur aus dem ST Ram richtig läuft dann laßt das doch auch so. Geschwindigkeit ist nicht immer alles ...