2 CF cards am Falcon?

[tuxie]

@Arthur,

ich weiß ja nicht wie es bei dir Zeitmässig ausschaut. Aber wenn du die Zeit hättest, würde ich dir bei dem GAL Listing helfen und du baust es einfach mal auf. Erstmal auf Lochhraster und dann sehen wir weiter?

[Arthur]

@Ingo, lassen sich nicht alles Singnale einfach per Treiber verstärken oder wozu wird das GAL genau benötigt?

[skul]

Moin,

die Daten laufen bidirektional über den Bus. Deshalb müssen auch bidirektionale Treiber eingesetzt werden (245er oder so), die dann auch entsprechend der Datenrichtung (schreiben/lesen) gesteuert werden müssen. Deshalb ist eine entprechende Logik nötig. Kann sicherlich auch über 'ne TTL-Logik gemacht werden, aber GAL ist gerade im Teststadium einfacher. Die Bustreiber über die vom Falcon bereitgestellten Signale zu steuern finde ich zu wackelig, die Last (2. HDD/CF-Card + Logic) wird für die Steuerleitungen noch größer.
Gruß
skul

[tuxie]

Man muß es sogar über einen weiteren IC machen, ob es nur ein GAL ist oder eine andere Logic spielt hier keine rolle. Durch die Bustreiber entsteht eine Verzögerung die dann zu Problemen führen kann.

So ist es mir zumindest beim IDE Interface am ST gegangen und der hat nur 8MHz.

Ich denke man sollte alle Signale soweit es geht halt Buffern, müßte man mit 3x74F245 hin kommen. Und dann nen GAL 16V8 7ns zur ansteuerung.

wichtigsten Signale
D0-D15

DIOW
DIOR
IORDY
DA2..DA0

Denke die sollten reichen.

[Arthur]

Schau dir mal dieses GAL Listing aus der CT (Allesfresser) Jahrgang 9/93 an.

Hier wird noch folgendes benutzt:
/CS0    geht zur IDE-Platte Pin 37
/CS1    geht zur IDE-Platte Pin 36
Und was ist mit /OCS16 an Pin 32?

In der Wiki wird dafür Pin 37 u. 38 angegeben ist das ein Bug?

// // 16.04.93 Kai Scheffer
// 20.06.93 Kai Scheffer Pinbelegung gem c't Layout abgeändert

GAL-Listing für IDE-Platten-Adapter am ATARI ST (c't 9/93)

IDE-Register $F00000 bis $F1FFFF
ROM-Breich   $E00000 bis $EFFFFF und ROM2-Select

Erzeugung von:
/DTACK  zum Atari
/CS0    geht zur IDE-Platte Pin 37
/CS1    geht zur IDE-Platte Pin 36
/IORD   geht zur IDE-Platte Pin 25
/IOWR   geht zur IDE-Platte Pin 23
/G      Enable-Signal fr die Datenbustreiber (2x74HCT245)
/INT    Interrupt-Signal zum Atari (DMA-Port Pin 10)

*IDENTIFICATION IDE_ST;
 
*TYPE GAL20V8;
 
*PINS
 /AS = 3,
 RW = 5,
 A5 = 1,
 /ROM2 = 2,
 A17 = 6,
 A18 = 7,
 A19 = 9,
 A20 = 8,
 A21 = 10,
 A22 = 11,
 A23 = 13,
 /LDS = 4,
 /IOCHRDY = 14,
 IRQ14 = 23,

 /INT.T = 19,
 /TOS.T = 20,
 /IOWR.T = 22,
 /IORD.T = 21,
 /G.T = 16,
 /CS1.T = 18,
 /CS0.T = 17,
 /DTACK.T = 15;
 
*BOOLEAN-EQUATIONS

   TOS.E   = VCC;
   IOWR.E  = VCC;
   IORD.E  = VCC;
   G.E     = VCC;
   CS1.E   = VCC;
   CS0.E   = VCC;

  INT.E    = IRQ14;
  INT      = IRQ14;
   
DTACK   = /A17 & /A18 & /A19 & A20 & A21 & A22 & A23 + TOS;
   
DTACK.E = /IOCHRDY & AS & /A19 & A21 & A22 & A23;
       
CS0     = /A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
   
CS1     =  A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
   
G       = LDS & RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23 + /RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
     
IORD    = LDS &  RW & (CS0 + CS1);
       
IOWR    = LDS & /RW & (CS0 + CS1 + TOS); % Signal TOS wegen EEPROMs %

TOS     = ROM2 + AS & A23 & A22 & A21 & /A20 & /A19;
   
*END

Gruß Arthur

[tuxie]

Hi,

ja ist die normale Adressdekodierung für den Angegebenen Adressbereich damit das IDE Interface Falcon Kompatibel ist.

[Arthur]

Hier noch ein paar Zusatzinfos für Leute die gerne mithelfen möchten. Die (roten) Signale werden nicht in allen Fällen unbedingt benötigt. Am Atari wohl erst recht nicht. Wer sich damit auskennt darf es ruhig mal überfliegen und die Fehler hier aufzählen die ihm ins Auge gesprungen sind. Hier noch eine umfangreiche IDE-Beschreibung als PDF-Dokument.

Ein klick ins Bild bringt einen auf die Ursprüngliche Seite.

Arthur

[Arthur]

Hi,

ja ist die normale Adressdekodierung für den Angegebenen Adressbereich damit das IDE Interface Falcon Kompatibel ist.

Wieso bitte ist CS0FX und CS1FX die Adresskodierung? Ein paar Infos mehr könnten bei so einer Thematik nicht schaden.

6.3.1 CS1FX- (drive chip select 0)
This is the chip select signal decoded from the host address bus used to
select the Command Block Registers.

6.3.2 CS3FX- (drive chip select 1)
This is the chip select signal decoded from the host address bus used to
select the Control Block Registers.

Oder meinst Du das die beiden Register damit in den Speicher eingeblendet werden?

Arthur

[Arthur]

Moin,

die Daten laufen bidirektional über den Bus. Deshalb müssen auch bidirektionale Treiber eingesetzt werden (245er oder so), die dann auch entsprechend der Datenrichtung (schreiben/lesen) gesteuert werden müssen. Deshalb ist eine entprechende Logik nötig. Kann sicherlich auch über 'ne TTL-Logik gemacht werden, aber GAL ist gerade im Teststadium einfacher. Die Bustreiber über die vom Falcon bereitgestellten Signale zu steuern finde ich zu wackelig, die Last (2. HDD/CF-Card + Logic) wird für die Steuerleitungen noch größer.
Gruß
skul

Wirklich gut erklärt, ich hab es auch verstanden. Danke.

[Arthur]

Ich baue es auf, wenn wir das Gal und einen groben Schaltplan oder ein Layout zusammen bekommen. Wir können ja erst mal schauen für welche Signale das GAL benötigt wird und welche Signale schon direkt an die 74HCT244 oder/oder 74HCT245 können. Ich hab ja schon einige Infos w.o. zusammengetragen. Evtl. hilft und das dabei.

Falls genügend Bedarf vorhanden ist, dann könnte man auch ein paar Platinchen ätzen lassen. Ich schätze mal mehr als 20€ inkl. aller Bauteile sollte das nicht kosten. Was haltet ihr davon und wer wäre an so einer Schaltung interessiert?

Gruß Arthur

[tuxie]

Hi,

sorry hätte sollen den Bezug zum Thema mit angeben.

Ich versuchs mal kurz zu erklären wie es Funktionieren könnte.

Die 74F245 sind Bidirektionale Bustreiber
Diese werden wenn man so will einfach zwischen BUS und Festplatte zwischen geschaltet werden. Was jetzt der GAL erledigen muß ist die Versorgung des Enable Signals und das DIR Signal (richtungsleitung).

Die kann Theroetisch mit IOR und IOW verknüpft werden um das Signal zu erzeugen, wobei man noch IORDY Generieren sollte, wär vielleicht sinnvoll man schaut sich mal ein Logic Diagramm an.

Wir können einen einfachen aufbau ja erstmal machen, nutzen dazu 2x 74F245 (F Typen verwenden, mit anderen wird es wohl zu Timimg Probs kommen).

Ich denke aber die Steuerleitungen sollten auch Gebuffert werden.

[Arthur]

Die 74F245 sind Bidirektionale Bustreiber
Diese werden wenn man so will einfach zwischen BUS und Festplatte zwischen geschaltet werden. Was jetzt der GAL erledigen muß ist die Versorgung des Enable Signals und das DIR Signal (richtungsleitung).

Hat Skul ja auch schon oben geschrieben.

Die kann Theroetisch mit IOR und IOW verknüpft werden um das Signal zu erzeugen, wobei man noch IORDY Generieren sollte, wär vielleicht sinnvoll man schaut sich mal ein Logic Diagramm an.

Reicht dafür nicht das GAL-Listing aus der C't w.o. aus?

Wir können einen einfachen aufbau ja erstmal machen, nutzen dazu 2x 74F245 (F Typen verwenden, mit anderen wird es wohl zu Timimg Probs kommen).

Immer diese F-Typen. Die sind oft schwer erhältlich deshalb sollte das vorher im Datenblatt nachgeschaut werden ob das wirklich notwendig ist.

Ich denke aber die Steuerleitungen sollten auch Gebuffert werden.

Das finde ich auch, entweder richtig oder wir lassen es ganz.

Gruß Arthur

[tuxie]

Das GAL Listing aus der CT wird doch garnicht benötigt, weil hier doch kein IDE Interface gebaut werden muß.

Wird nur eine einfache Logic benötigt um die Enable und DIR Signale anzusteuern, ist eigentlich nix Kompliziertes und geht eigentlich auch mit normalen Logicbausteinen.

[Arthur]

Mensch Ingo, mach es einem doch nicht so schwer. Also lesen sollte man schon können um zu verstehen was ich mit

Zitat von: tuxie am Heute um 18:49:57
Die kann Theroetisch mit IOR und IOW verknüpft werden um das Signal zu erzeugen, wobei man noch IORDY Generieren sollte, wär vielleicht sinnvoll man schaut sich mal ein Logic Diagramm an.

Reicht dafür nicht das GAL-Listing aus der C't w.o. aus?

gemeint habe.

In dem IDE Allesfresser Projekt aus der C't werden doch die selben Treiberbausteine verwendet so das für die Ansteuerung doch die selben Singnale verwendet werden werden, oder nicht? Das das nicht 100% 1:1 übernommen werden kann sollte jedem logisch denkenden Menschen doch klar sein. Siehe auch hier:

CS0     = /A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
  
CS1     =  A5 & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
  
G       = LDS & RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23 + /RW & /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;
    
IORD    = LDS &  RW & (CS0 + CS1);

Bevor Du jetzt darauf antwortest schau es dir bitte mal komplett weiter oben an. Das kann man ja dann z.B. mit der Schaltung von ppera vergleichen um weitere Informationen zu bekommen. Kann ja wirklich sein das, in dem GAL-Listing, keine hilfreichen Informationen sind. Ich hätte gedacht da könnte man ein paar Informationen oder Ideen adaptieren oder übernehmen.

Wenn Du unbedingt ein Oszi oder Logikanalyzer anschmeissen möchtest kannst Du das natürlich auch tun.

Ich klink mich hier erst mal aus. Würde mich freuen wenn es endlich voran gehen würde anstatt sich an solchen Kinkerlitzchen ewig aufzuhalten.

[tuxie]

Aber wozu den? Du brauchst doch die Dekodierung der Adressen nicht nochmals machen, das erldigt doch schon der Compel!

Das GAL listing was du hier angehängt hast, ob es nun das aus der CT ist oder das von ppera (beides das gleiche) macht doch das was der Compel schon macht. Du brauchst doch nur eine logic um das DIR Signal der Treiber ICs zu steuern, nämlich Lesen/Schreiben da diese ja Bidirectional sind. Du denkst viel zu weit unten, wir brauchen den IDE Bus doch nicht neu ausdekotieren.

Sprich wir müssen den Treiber ICS nur sagen wann sie  in die eine Richtung und wann in die andere Richtung geschalten werden müssen.

Theroretisch genügt es die Daten und die Adressleitungen zu buffern, das heißt du brauchst 3 IC´s.

Also einen Adapter der 1:1 ist, und zwischen den beiden Anschlüssen werden die Treiber IC´s zwischen geschaltet. Dann kommt die DIR und Enable LEitungen an einen GAL ran. Und der GAL wird noch mit den IOR und IOW LEitungen verbunden (jeweils ein Eingang).

Wir bräuchten ein Busprotokoll Diagramm, demnach kann man dann sagen was noch gesetzt werden kann und wie ein Zyklus aussieht.
Mit dem GAL könnte man noch etwas luft machen damit dann bisschen merh Zeit im Timimg bleibt.

Ich schau mir das morgen mal in ruhe an. Und wenn ich paar minuten habe versuch ich mal zu skizzieren.

[tuxie]

Hab nochmal kurz nachgedacht

Eingänge

IOR
IOW
DMACK- (DMA acknowledge)

Ausgänge

Enable
DIR
DMACKA

Enable = IOR + /IOW
DIR = IOR && /IOW (da low Aktiv)
DMACKA = DMACK



DIR wäre dann low wenn /IOW Aktiv ist und High wenn IOR Aktiv ist.
DMACK setzt die Gültigkeit und wird durch das GAL verzögert!

Sollte so eigentlich Funktionieren, kann mich aber auch Täuschen und meine Denkweise total falsch ist.

Nochmals zu den Typen"! Ja die F Typen sind schwer u bekommen, das ist richtig. Aber die F sind die einzigen die dafür in frage kommen, alle anderen sind zu langsam. Der Falcon hat so schon mit dem Timing an allen ecken zu kämpfen. Auch im ST habe ich das IDE Interface nur mit den F Typen sauber zum laufen gebracht. Die F Typen haben eine Schaltzeit von 3,5ns was schon ziemlich schnell ist. Mit den HCT´s lief das IDE Interface fast garnicht, es traten nur fehler auf. Das Schreiben funktionierte, aber das Lesen nicht.

[skul]

Moin,

ich hatte mit den IDE-Interfaces noch nie Probleme, noch nicht mal mit LS-Typen, aber egal.
Zu Puffern des IDE-Ports reichen die Signale, die am Port selber anliegen wohl aus. Ich denke, es geht um die Signale, die der Falcon liefert, die gepuffert werden sollen, das sind ja nur 'ne Hand voll plus Datenleitungen.
Zur Steuerung der bidirektionalen Treiber braucht man ein Signal für die Datenrichtung und ein Freigabesignal (enable).
Für die Datenrichtung lässt sich einfach IOR oder IOW missbrauchen (je nach dem, wie die IC's verdrahtet sind), das Freigabesignal kann mit 'nem Gal oder TTL-Gatter aus den am IDE-Port anliegenden Signalen generiert werden. Ich würde hier aber ein Gal nehmen und es gleich zur Pufferung der Signale missbrauchen.
Bei Einsatz zu schneller Treiber (F-, AS-, ALS-Typen) kann's passieren, dass an den Ausgängen der Treiber nach Verschwinden von "Enable" oder "DIR" zu flott keine gültigen Daten mehr anstehen, dann funktioniert nix. Dann kann man versuchen mit dem Gal die entsprechenden Signale etwas zu modifizieren.
Die ganze Pufferung sollte ohne Eingriff in den Falcon funktionieren. Einfach auf den IDE-Port aufstöpseln.
Ich habe leider keine Zeit mich damit tiefer gehend zu befassen. Aber ich sehe 'mal nach, ob ich noch schnelle Treiber habe.
Gruß
skul

[tuxie]

Ja so dachte ich mir das auch, aber ich habe halt am ST IDE die erfahrung gemacht das es nur mit den F typen lief.

Ich habe heute nacht nur mal schnell überlegt wie man das am besten machen kann. Am ST interface wird ja DTACK gesetzt wenn die Adressen Gültig sind. Jetzt müsste man schauen wie man das am dümmsten hier macht. ich denke das DMACK Signal könnte man dafür verwenden. Damit stellt man sicher das auch die Daten wirklich anliegen wenn ein Arbeitszyklus erfolgt.

[skul]

Moin,

ich hab' noch zwei F245 und vier AS245.
Die DTACK-Erzeugung für die IDE-Daten findet beim Falcon im Combel statt, denke ich. Da wird /IOCHRDY von der Platte eh nicht berücksichtigt, ist beim Falcon wohl nicht nötig ;-) Ein zusätzliches DTACK wird nix nutzen, wenn man das alte nicht irgendwie abgewürgt kriegt.
Also einfach 'mal aufbauen - zwei Bustreiber, ein Gal, und sehen, ob's überhaupt geht.
Soweit ich sie habe, steuer ich die nötigen Bauelemente gern bei.
Gruß
skul

[tuxie]

Hi,

ja nein ein zusätzliches DTACK wollte ich auch nicht erzeugen, aber man könnte es durch den GAL verzögern und somit abwarten bis die Treiber gesetzt sind. Oder macht das so keinen sinn?