Hardware > Hardware (Classic 16-/32-Bit)

c´t IDE Interface ...

<< < (6/27) > >>

czietz:
Die Steuersignale, die durch den (immer aktiven) 74HCT244 laufen, erfahren nur dessen Durchlaufzeit, typisch 11 ns. Der 74HCT245 für die Daten hingegen muss vom GAL via Output-Enable (/OE) erst aktiviert werden. Die Verzögerungszeit von /OE = low bis die Daten auch wirklich durchkommen, ist durchaus größer, maximal 30 ns.

Wenn nun tatsächlich bei einem Schreibzugriff /IOWR vor den Daten anliegt, knallt's. Im Gegenteil müssen (je nach PIO-Mode) die Daten sogar 20 ns - 60 ns vor /IOWR -> low da sein. Das Timing auf IDE-Seite prüft man am besten mit dem Scope.

Lukas Frank:
Der 244iger macht ja keinerlei Probleme. Es ist sogar so das ohne diesen oder einem LS Typ die ganze Sache nicht mehr funktioniert.

Ich vermute das Timing stimmt nicht wann die 245iger freigeschaltet und/oder auch die Richtung festgelegt wird. Wie man aus dem GAL Listing für das "G" Signal sehen kann wird da wahrscheinlich nur freigeschaltet wenn der IDE Port auch angesprochen wird, ganz anderes als bei dem Interface von ppera, oder ?



--- Zitat von: czietz am Do 30.06.2016, 19:17:28 ---Der 74HCT245 für die Daten hingegen muss vom GAL via Output-Enable (/OE) erst aktiviert werden. Die Verzögerungszeit von /OE = low bis die Daten auch wirklich durchkommen, ist durchaus größer, maximal 30 ns.

Wenn nun tatsächlich bei einem Schreibzugriff /IOWR vor den Daten anliegt, knallt's. Im Gegenteil müssen (je nach PIO-Mode) sogar 20 ns - 60 ns vor /IOWR -> low. Das Timing auf IDE-Seite prüft man am besten mit dem Scope.

--- Ende Zitat ---

Und was soll man da genau messen und wie kann man dann da etwas ändern ?

czietz:

--- Zitat von: Lukas Frank am Do 30.06.2016, 19:21:32 ---Und was soll man da genau messen

--- Ende Zitat ---

Kurzfassung: Die Einhaltung der IDE-Timings.  ;)

Du kannst z.B. mit meiner Hypothese anfangen, dass /IOWR bei Schreibzugriffen auf den IDE-Bus zu früh kommt. Trigger auf fallende steigende Flanke von /IOWR (am IDE-Bus, nicht am GAL!) und dabei eine (oder bessere mehrere) Datenleitungen  (D0-D15) auf der IDE-Bus-Seite angucken, wieviel Nanosekunden vor und nach der fallenden steigendenFlanke von /IOWR sie vom 74HCT245 getrieben werden.

EDIT: Blick in die IDE-Specs zeigt, dass die Daten erst bei der steigenden Flanke auf /IOWR übernommen werden.


--- Zitat ---und wie kann man dann da etwas ändern ?

--- Ende Zitat ---

Wenn man den Fehler gefunden hat, durch Korrektur des Timings. Im obigen Fall z.B. /IOWR verzögern.

czietz:
PS: Vielleicht reicht es auch schon, den 74HCT245 früher und länger im MC68000-Buszyklus zu aktivieren. ppera macht das [1] bereits, wenn nur die Adresse anliegt und damit ca. 60 ns früher und 60 ns länger als das c't-Interface.

Das hieße übersetzt für's c't-Interface:

   G        =  /A17 & /A18 & /A19 & A20 & A21 & A22 & A23;

[1] http://atari.8bitchip.info/t206ide.gal

SolderGirl:
Ich habe gerade genau dieses Problem.

Ich habe im Mega einen VoFa Adapter und einen c't-IDE Adapter.

wenn die 245er auf dem IDE überbrückt sind (Drahtbrücken im Sockel), dann funktioniert das Interface problemlos und zuverlässig. Stecke ich aber gleichzeitig eine VGA-Karte in den VoFa, startet der Rechner nichtmehr. Vermutlich ist dann einfach die Last für die Ausgänge des Prozessors zu hoch. Auch wenn das IDE-Kabel länger als ein paar cm wird, läuft nichts mehr.

Stecke ich aber die HCT245er in die Sockel, dann funktionieren auch längere Kabel. Allerdings produziert die Platte dann beim Schreiben sehr oft Datenmüll. Ich hab zwar keinen direkten Dateivergleich gemacht, aber Dateinamen mit ungültigen Zeichen die sich nichtmehr löschen lassen sprechen wohl für sich.

Naiv wie ich bin, habe ich einfach mal angenommen das das Interface in dieser Form schonmal irgendwann funktioniert haben muß, und bin davon ausgegangen, das früher die IDE-Platten selbst noch langsamer waren und mit etwas ungenauerem Timing besser klar gekommen sind.
Mein Gedanke war dann, einfach schnellere Chips zu nehmen wie VHCT oder so.

Aber wenn ich so darüber nachdenke, es macht schon Sinn was @czietz schreibt. Wenn die Steuerleitungen deutlich weniger Verzögerung haben, weil da der GAL nicht "mitredet", dann kommen natürlich die Daten zu spät.

Leider habe ich selbst kein Oszi und kann das nicht überprüfen.

Ich hatte auch schon überlegt das DIR-Signal der 245er direkt mit R/W vom Prozessor zu verbinden, aber da sehe ich die Gefahr von Kollisionen mit anderen Karten. Es besteht dabei ja die Gefahr das mehrere Chips gleichzeitig auf den Bus schreiben wollen.

Wäre es nicht eigentlich besser die Schaltung gleich mit "normalen" ICs aufzubauen, und auf den GAL zu verzichten? Da könnte man bei entsprechender Auswahl der IC-Typen auch etwas geringere Latenzen hinkriegen, was dann mehr Spielraum für Beschleunigungen bringt. Jetzt nicht unbedingt in dem Sinn, das man höhere Datenraten bekommt, aber ich könnte mir vorstellen das die HCT-Chips irgendwann Probleme machen, wenn solche Sachen wie Bus-Übertaktung oder PAKs ins Spiel kommen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete