Software > Software (16-/32-Bit)

HD Treiber für Ataris mit IDE Interface

<< < (7/11) > >>

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:

--- Zitat von: tuxie am Fr 12.08.2016, 08:51:32 --- "wie könnte das beim TT aussehen ? Was als bootstrap app nutzen, welches dann den hddriver in den Fastram läd "

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

--- Zitat --- Ihr wollt also den UDMA-Modus anstatt des PIO-Modus? Chapeau!
 
--- Zitat ---  Mit dma Zugriff meinte ich nicht udma des IDE interface sondern dma des TT s, 
--- Ende Zitat ---

--- Ende Zitat ---
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 ;)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete