c´t IDE Interface ...

[tuxie]

Wenn du mir den Schaltplan mal zusenden könntest dann kann ich ihn mir nochmal anschauen und das GAL Listing vergleichen.

[czietz]

Ich gehe mal stark davon aus das der Schaltplan richtig ist und der Fehler in der Quelldatei zum GAL liegt. Das stammt irgendwie aus dem Netz.

Die stammt sicherlich doch nicht "irgendwie" aus dem Netz sondern schon offiziell vom Heise-Server, nehme ich an? (Was nicht heißt, dass dort nicht vielleicht auch eine fehlerhafte Version veröffentlicht wurde...)

[Lukas Frank]

Wie dem auch sei, irgendwo muss der Fehler halt stecken ...

Mit den Treibern wird Datenmüll produziert oder es gibt gleich beim booten 3 Bomben wenn der Plattentreiber geladen wird.

[czietz]

Das spricht aus meiner Sicht eher dafür, dass das Signaltiming grenzwertig ist. Würden die Treiber gar nicht angesteuert (wegen Fehler im GAL/Schaltplan), würde die Platte/CF-Karte wohl schlicht nicht detektiert werden.

[tuxie]

Durch die Treiber in den Steuerleitungen liegen die Signale alle ziemlich gleichzeitig an, aber wenn man sich das Timing des IDE mal anschaut könnte ich mir vorstellen wie czietz schon sagt das es da Probleme gibt. Der 244 wird vom GAL aber gar nicht angesteuert. Schau dir doch mal die Signale nach dem Treiber auf der IDE Seite an.

[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 ?

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.

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

[czietz]

Und was soll man da genau messen

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.

und wie kann man dann da etwas ändern ?

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.

[czietz]

Ich denke nicht, dass man das als TTL-Grab (auch mit modernen ICs) schneller und schon gar nicht zuverlässiger hinbekommt als mit einem GAL oder gar einem modernen PLD. GALs mit es in ziemlich schnell mit einstelligen Nanosekunden als "propagation time".

[tuxie]

vielleicht hilft es die pullup wiederstabdsnetzwerke gegen andere werte zu tauschen. die wind bei einigeb sts bisschen schwach. hatte bei mir damals 4,7k oder gar 3,3k wiederstände rein gemacht da er auch solche zicken gemacht hatte und dannach lief er stabil.

[Lukas Frank]

Du meinst die Pullups an den Adress und Datenleitungen, die hatte ich mit einer PAK68/3 und FRAK und PULA halbiert alle. Lief sehr gut und ohne Probleme. Allerdings hilft das beim IDE Interface und den Treibern nicht weiter.

Bei mir lief das c´t IDE Teil mit VOFA und Magnum ohne Probleme, allerdings hatte ich wie man auf dem Bild sehen kann nur direkt einen Single CF Adapter stecken ohne IDE Kabel dazwischen ...

Das GAL nach der Idee von czietz ist auf dem Weg, mal schauen ob es damit geht oder nicht ...

[czietz]

Das GAL nach der Idee von czietz ist auf dem Weg, mal schauen ob es damit geht oder nicht ...

Ich bin gespannt.

[SolderGirl]

Also ich hab den modifizierten GAL gerade getestet, aber es funktioniert nicht richtig.

Es werden zwar alle Partitionen erkannt und ich kann auch Dateien dazwischen hin- und her kopieren, aber sobald ich versuche ein Programm von der Platte zu starten gibt es Fehler. Mal bleibt der Rechner einfach hängen, ein anderes Mal hagelt es Bomben.

[Lukas Frank]

@Arne ... habe mal gelesen das du ein c´t IDE Interface hast. Kannst du bitte mal schauen ob der Schaltplan stimmt wegen der Pins 1 und 19 jeweils an den 245 Treiber Bausteinen. Falls der stimmt, ist dein GAL Kopiergeschützt ?

[czietz]

@SolderGirl : Schade.  Ich nehme an, das ist nun mit dem 74HCT245? Dann sind meine Ferndiagnosefähigkeiten erst einmal ausgeschöpft. Da müsste man nun die Signale messen. Oder vielleicht hat jemand ja ein IDE-Interface nach pperas Bauart für Dich... Die funktionieren wohl recht zuverlässig.

[SolderGirl]

Naja, das c't Interface ohne VoFa und ohne 245er funktioniert mit dem originalen GAL.

Und es gibt ja berichte, das jemand das schon funktionierend hatte damit.

Ja, nachmessen wäre das beste. Aber ich habe kein Oszi, und ich kann auch meinen Freund nicht nochmal anpumpen vorerst, der hat mir jetzt erst ein neues Handy finanziert weil mein altes S2 leider den Geist aufgegeben hat.

Bin ziemlich sicher das es was mit dem Timing zu tun hat. Sobald ich dazu komme, werde ich es mal mit ACT oder ABT Chips versuchen, die sind deutlich schneller als HCT. Ich habe bei meiner Suche das hier gefunden: http://www.ti.com/lit/ml/scyb004b/scyb004b.pdf
Seltsam, aber obwohl "HCT" für "Highspeed CMOS TTL" steht, sind die hier als das langsamste gelistet was es gibt.
Ich bin mir noch nicht ganz sicher was ich nehmen soll. ABT sind wohl noch schneller als 74F, sollten diese also locker ersetzen können. Die ACT sind etwas langsamer als 74F, haben aber CMOS-Pegel am Ausgang, was wieder besser sein sollte wenn Flachbandkabel ins Spiel kommen.

[neogain]

@SolderGirl : Schade.  Ich nehme an, das ist nun mit dem 74HCT245? Dann sind meine Ferndiagnosefähigkeiten erst einmal ausgeschöpft. Da müsste man nun die Signale messen. Oder vielleicht hat jemand ja ein IDE-Interface nach pperas Bauart für Dich... Die funktionieren wohl recht zuverlässig.

geht morgen zur Post für Soldergirl, habe es leider nicht vor dem Umzug gepackt.

[SolderGirl]

@SolderGirl : Schade.  Ich nehme an, das ist nun mit dem 74HCT245? Dann sind meine Ferndiagnosefähigkeiten erst einmal ausgeschöpft. Da müsste man nun die Signale messen. Oder vielleicht hat jemand ja ein IDE-Interface nach pperas Bauart für Dich... Die funktionieren wohl recht zuverlässig.

geht morgen zur Post für Soldergirl, habe es leider nicht vor dem Umzug gepackt.

Das ist wirklich klasse.
Trotzdem würde ich gerne wissen warum das nicht so funktioniert wie es soll.
Immerhin wurde es damals veröffentlicht und hat wohl auch mit Treiber-Bausteinen funktioniert.
Aber @Lukas Frank hat berichtet das es bei ihm auch nur ohne die Treiber gelaufen ist.
Da stimmt doch irgendwas nicht, und ich würde wirklich gerne herausfinden, was.
Denn im Prinzip ist die Schaltung sehr elegant und würde sich gut eignen, um in andere Projekte integriert zu werden.