Software > Software (16-/32-Bit)
HD Treiber für Ataris mit IDE Interface
tuxie:
--- Zitat von: 1ST1 am So 14.08.2016, 15:06:50 ---
--- Zitat von: mfro am Sa 13.08.2016, 18:36:39 ---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.
--- Ende Zitat ---
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...
--- Ende Zitat ---
Genau das ;) Damit könnte man einen Schreibzyklus einsparen und dann natürlich auch jeweils einen Lesezyklus. Zumindest in den RAM
1ST1:
--- Zitat von: Lukas Frank am Sa 13.08.2016, 12:18:11 ---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 ... ?
--- Ende Zitat ---
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.
mfro:
--- Zitat von: 1ST1 am So 14.08.2016, 15:14:21 ---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.
--- Ende Zitat ---
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.
1ST1:
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?
nobox:
--- Zitat von: 1ST1 ---Aber wie sieht es andersrum aus, Speicherbereich immer auf eine Adresse ausgeben? Also IDE schreiben?
--- Ende Zitat ---
--- Zitat von: mfro ---Dafür hat er je ein Source- und ein Destination-Increment Register, das festlegt, wo's jeweils weitergehen soll.
--- Ende Zitat ---
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln